タグ

ossとScalaに関するkuchitamaのブックマーク (5)

  • Scala で実装した社内ナレッジ共有ツールを OSS にして公開しました

    社内の事業部・プロジェクトを跨いで、社員間で技術やノウハウの共有をもっともっと盛んにしたいーそんな社員の声から生まれ、社内で運用中のツールをこの度 OSS にして公開しました。 公開先 GitHub 上に公開しています。 atware/sharedocs README にデモサイトや Heroku ボタンを記載していますので、すぐに試すこともできます。 Sharedocs Markdown で記事が投稿でき、コメントや Like やストックができる、言ってしまうとどこかで聞いたことがある某有名サービスのような情報共有ツールです。 投稿画面 絵文字も入力できますし、さらにはシーケンス図やフローチャートも Markdown で描けます。 レスポンシブにしてあるのでスマホやタブレットでも使えます。 つくるに至った背景など 背景 弊社には以前から、 他のプロジェクトでどんな技術が使われているのかよ

    Scala で実装した社内ナレッジ共有ツールを OSS にして公開しました
    kuchitama
    kuchitama 2017/01/18
    おお!Scala製!!一括インポート/エクスポートあると嬉しいな。なかったらPR送ってみようか…
  • ScalaMatsuri 2016に参加してきました - たけぞう瀕死ブログ

    二日間のScalaMatsuriが終了しました。 http://scalamatsuri.org/scalamatsuri.org 今年は会社としてだけではなく、GitBucketでもスポンサーをさせていただきました。残念ながらCFPは落ちてしまったので一参加者として楽しませていただこうと思っていたのですが、寄る年波には勝てず、体調的に両日とも午後からの参加となってしまいました。 また、二日目はどなたが書いてくださったのか存じませんがアンカンファレンスネタとしてScalaパズルを上げてくださった方がいらしたようで急遽準備をしていたので他のセッションにはひとつも参加することができませんでした。Scala.jsコンパイラの話を聞きたかったのですが無念だ…。 というわけでセッションに参加できたのは初日の午後のみとなりますが、まずは参加したセッションの感想から。 バッチを Akka Stream

    ScalaMatsuri 2016に参加してきました - たけぞう瀕死ブログ
  • Contributing to Scala OSS from East Asia #ScalaMatsuri

    PlayFramework関西ビギナーズ 第1回(2012/11/17開催) にて使用したスライド。 最初にPlayの概要を説明した後、Play1.2.5で簡単なアプリケーションを作成する模様をライブコーディングしながらPlayの仕組みを解説しました。

    Contributing to Scala OSS from East Asia #ScalaMatsuri
  • ScalaMatsuriの応募者を有名ライブラリ作者中心に勝手に紹介 - xuwei-k's blog

    どーも。Scala祭実行委員なのか、実行委員ではないのか、よくわからない立場な人です。 個人的な事情を書いておくと、去年手伝った関係上、今年も一応実行委員のチャットなどには入ってるけど、あまり手伝えてないので、心苦しいのと実行委員の仕事やらないといけない責任から逃れるため(?)と、もう結局あとから多少手伝うことになったとしても個人スポンサー的な意味合いを込めて、普通にチケット買いました。 というわけで、実行委員の立場というよりは、これは一個人として勝手に書いてます。 さてそれはどうでもいいとして、皆さんご存じの通り?今年のScala祭は、招待枠は全くなしでCFPで投票する感じになりました。詳細は以下 「グローバルな技術カンファレンス」と「日のコミュニティの交流」の両立 - ScalaMatsuri運営ブログ] というわけで、これ書いてる時点では、CFP締め切られ、投票開始にむけて絶賛準備

    ScalaMatsuriの応募者を有名ライブラリ作者中心に勝手に紹介 - xuwei-k's blog
    kuchitama
    kuchitama 2015/10/16
    俺得エントリをありがとうございます。
  • Scalaでバイナリ互換を維持しながらのプロジェクト運営 - xuwei-k's blog

    json4sでせらさんが頑張ってくれるらしいけど、どこにも(たぶん英語でも)まとまった知見ないはずなので、とりあえずscalazの知見をもとに、まとめておく 最新開発版のbranchをつくってそちらをメインにしておく それ以外のやり方もありえる(scala体)が、たぶん開発版(バイナリ互換維持しないほう)をメインにしておいたほうがよい。 具体的には、json4s 3.3ブランチがバイナリ互換維持するなら、3.4か4.0ブランチを作っておく scalazだったら、これ書いてる現在 series/7.2.x が開発用 series7.1.x がバイナリ互換維持しつつメンテする用 上記のbranch戦略をREADMEか何かに書いておき、pull reqは基的には開発branchのみで受け付ける(両方で無造作に受け付けるとややこしくなるので) 万が一、間違って互換維持するほうのbranchで、

    Scalaでバイナリ互換を維持しながらのプロジェクト運営 - xuwei-k's blog
  • 1