DIについてあれこれ - tototoshi の日記
Dependency Injectionとはコンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである ってwikipedia先生が言ってました。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita を読んでいろいろ考えたので、なんで今さらって感じのことを書きます。 ScalaでDIというとDIコンテナとかCake PatternとかReader Monadとかって話になっちゃうんですが、これらはいかにかっこよくDIするかの話であって、別にこういった道具やパターンを使わなくてもDIは可能という話です。 Constructor Injection 簡単な例で考えます。今ここにUserRepositoryにべったり依存し
typesafe configの設定パスをscalaのコードで表現する - tototoshi の日記
ScalaMatsuriの感想ブログです ScalaMatsuriでscala.metaの話を2つ聞いて面白そうと思ったので私もやってみました。 typesafe configをscala.metaとscalameta/paradiseのmacro annotationで設定パスを文字列ではなくscalaのコードで表現できるようにしたやつです。 github.com こんな感じで使います。 // src/main/resources/application.conf akka { actor { serializers { akka-containers = "akka.remote.serialization.MessageContainerSerializer" } } } import com.typesafe.config.ConfigFactory import com.gith
アプリケーションに合ったExecutionContextを使う - tototoshi の日記
scalaではFutureなどの裏側ではExecutionContextが動いています。ということはExecutionContextの使い方がいまいちだとFuture周りで問題が起きることになります。 よく起きる問題の1つとして、標準のExecutionContextがいまいちだった、というのがあると思います。 標準のExecutionContextはダメというか、適さないパターンがあるのですが、あまりよく考慮されずに使われてしまう印象があります。 まあ悪いのはコンパイラの親切すぎるエラーメッセージでしょう。 scala> import scala.concurrent.Future import scala.concurrent.Future scala> Future { 1 + 1 } <console>:9: error: Cannot find an implicit Execu
Scalaで型安全Builderパターン - tototoshi の日記
NantokaBuilder().setHoge("hoge").setFoo("bar")...build() のようにプロパティを足していって作る必要がある Nantoka クラスがあったとします。 Java でもたまに見かけますね。チェーンできると使いやすくてうれしい。 ただ、困ったことにsetXXX はいつも自分の型を返しますので、 作ってる途中で我慢できずにbuildしてもコンパイルが通り、不完全なインスタンスが出来上がってしまい、 実行→突然の死！！ということが起こります。 コンパイルが通っているからって正しい使い方をしているとは限らない。 なんとかしたい。 普通の Builder パターン 例として、Moco'sキッチンでラーメンを作ってみます。 MocosRamenBuilder に材料を足していき、最後に #cook を呼ぶとラーメンが出来上がるのですが、 オリーブオイル
Play2.4のプラグインシステムにある欠陥について - tototoshi の日記
私の理解が正しければ、Play2.4のプラグインシステムにはプラグインの起動順が制御できないという大きな欠陥があります。Play2.3以前はplay.pluginsファイルに優先度を記述するというイケてない感が漂うやり方ではありましたが、問題なく制御することができていました。 Play2.4からはプラグインをDIコンポーネントとして記述するようになりました。play.pluginsファイルはなくなり、優先度ではなくコード中に記述してあるコンポーネント間の依存関係を利用して起動順が結果的にうまくいくようになっています。 ただし全てのプラグインがコードを介して依存しているわけではありません。例えばflyway-playのようなデータベースマイグレーションを行うライブラリはscalikejdbc-fixtureのようにデータベースフィクスチャプラグインよりも先に起動する必要がありますが、コード上
Typesafe が社名変えたがってる話 - tototoshi の日記
mixi 社はいつモンスターストライク社に変わるんだろうという冗談を言っていたら、なんと Typesaefe 社が社名を変えたいと言い始めました。最初エイプリルフール的なものかと思いましたが、冗談じゃないようです。冗談じゃないよ。 May 18, 2015 | What’s in a name? | Typesafe 自分は Typesafe 社の人間ではないし、人様の会社の社名変更に口を出すとかも変な話ですが、open process だ、意見をくれと言われたらそりゃ嫌って言うよ、だってめんどくさいもん！！ 実際typesafeの社名とか全く興味ないしopen processとか言ってるけど反対多くても変えるんでしょ。自由に変えてもらってもいいけど、自分としてはめんどくさいだけでメリットないから意見ないかって聞かれたらそりゃ反対って言うよ、って感じ。— Toshiyuki Takahas
個人/社内 Maven Repository を作る - tototoshi の日記
オープンソースの Scala ライブラリは sonatype を経由して Maven Central にデプロイするのが定番となっています。Maven Central のアカウントを持っていない、とかクローズドにしておきたい、などの理由から自前で Maven リポジトリを持ちたくなることがあるでしょう。 Maven リポジトリはなんとなくセットアップが面倒そうに思われていそうですが、実際には Web サーバ上にルールに従ってファイルが配置されているだけです。Artifactory や Nexus などの管理ツールもありますが、それらをインストールしなくとも簡単にセットアップが可能です。 例えば、gh-pages をリポジトリにしている人はたまに見かけます。自分も Sonatype のアカウントを作る前はそうしていました。それから svn リポジトリに jar を突っ込み、それを web 上
IntelliJ IDEA を無料で使う方法 - tototoshi の日記
IntelliJ IDEA は Community Edition であれば無料で使えますが、 Ultimate Edition になると大体初期２万＋維持費１万／年くらいの課金をする必要があります。 機能比較 これをどう見るかは人によると思いますが、自分は Scala はほとんど Emacs で書いてしまって、たまに気分で IntelliJ IDEA を使うくらいのノリなので少し高く感じています。 しかし、実は Ultimate Edition をタダで使う方法が存在します。Open Source License というヤツです。 IntelliJ IDEA 14.x Open Source License Open Source License はオープンソースのプロジェクトの開発に使用できるライセンスです。ライセンスの発行には審査が必要です。 条件は、 プロジェクトのリーダー、または
Scala 2.11.3 が生まれる前に死んでしまった話 - tototoshi の日記
↓に関して、https://gitter.im/scalajp/public で盛り上がってた内容をまとめました。 なぜこんなことになってしまうのだろう（未調査） https://github.com/skinny-framework/skinny-framework/issues/193 これ Skinny 側で何か work around できないですかね https://github.com/skinny-framework/skinny-framework/issues/193#issuecomment-58773130 2.11.3 を指定して build した Scalatra を scalaVersion := "2.11.0" なアプリから利用するのは問題なさそうだった。となると Scalatra に 2.11.3 でビルドした 2.3.1 を出してもらうようお願いするのが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
