自宅警備員兼エンジニアのブログ
タイトルからある程度想像はつくと思うけど、一応書く。
静的 HTML を複数ページ作成するときに、共通部分（ヘッダーとかフッターとか）をコピペしたくない。
「PHP とか使って include とかすればいいじゃん」
ていう意見もあるんだけど、動作確認に web サーバー立てるの面倒だし、単なる HTML で済むなら HTMLで 完結させたい。
gulp-ect を使って、やりたいことは大体実現出来ていたんだけど、以下の2つの理由により、別の方法に切り替えたいと思った。
さきに結論だけ書いておくと、
という方法で実現した。
Scala や Play! framework で Future 使うときに、ExecutionContext を渡せと言われる。よく分からない場合は、とりあえず
import scala.concurrent.ExecutionContext.Implicits.global
とやっておけば、とりあえずコンパイルは通るんだけど、よく分からずにやっている人も多いと思う（ノ）。
今回は、そっから先の話。
Continue reading Scala とか Play の Future と ExecutionContext について
やっぱり、並列コレクションを使うのはやめて、Future 使って、Execution Context とかをちゃんと設定する方法にした。
が、一応、以下の内容はそのまま残しておく。
今、いろんな API からデータを取ってきて、それらを検索可能にするっていう（元々は自分用の）サービスをちょこちょこ作っている。（興味のある方は以下のリンクより使ってみて、是非フィードバックを下さいませ↓）
Track Down Anything on GitHub, Slack or Google Drive | Commet
いろんな API からデータを取ってくるので、直列で実行すると、どっか1箇所の API が不調だったりしてレスポンスが遅いと、それに引きずられてしまうので、並列化しようと思った。
元々のコードは、大雑把にはこんな感じ。
SomeDatabase.findAllApiEndpointsToCall.foreach { apiCall =>
apiCall.execute
}
これを並列化しようとして、以下のコードにした。
# par をつけた
SomeDatabase.findAllApiEndpointsToCall.par.foreach { apiCall =>
apiCall.execute
}
ログをみると、
02:08:35.008 [ForkJoinPool-3-worker-5] INFO xxxxx
という感じで、別スレッドで動くようになったようだけど、スレッド名が常に同じ＝1つのスレッドしか使われていないらしい。
以下のドキュメントを見ると、設定変更出来るらしいので、やってみた。
Parallel Collections – Configuring Parallel Collections – Scala Documentation
val apiCalls = SomeDatabase.findAllApiEndpointsToCall.par
# TaskSupport なるものを作成して、コレクションのプロパティにセット
val taskSupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(4)) # 4並列
apiCalls.tasksupport = taskSupport
apiCalls.foreach { apiCall =>
apiCall.execute
}
これで、とりあえず並列で処理されるようになった。
やりたいことがあまり具体的になってないけど、機械学習を使った自然言語処理をやりたい。大雑把には、日本語のテキストを入力して、それを分類したり、書き手の感情や性格とかを判別したり、そんなの。
最終的には全部自分で実装したいけど、当面は、既存のもので使えそうなのがあればそれを使おうと思う。
以下のものを調べた。
ただ、すべてのものを調べた訳ではない。
あと、API として最初からすぐに使えるようになっているものと、トレーニングしなければいけないものなどが混じっている。
誤り等があった場合は、ご指摘等頂ければ、訂正等を行う予定。
なぜこれをやりたいかは、以下のエントリーを参照。
サイト・webサービスなどのテキストを多言語する方法はいくつかあって、詳細はググってもらうとして、（分類の仕方も色々あるけど）大雑把に以下の2つに分けられると思う。
（言葉で説明すると分かりにくいので、上の説明でピンとこない方は gettext, Java ResourceBundle などで検索してほしい。）
で、今回は後者に関して、キーの命名規則を自分達はこうしてるっていう話を書く。
ネットであまりベストプラクティス的なのが見当たらなかったので、とりあえず今やってる方法を晒して、他の人からの意見とかをもらって改善出来れば良いなあという意図。
GitHub (issue, PR のコメント, wiki ページ), Slack, Google Drive etc. のデータをAPI経由で集めてきて、横串検索出来るようなサービスを作ってる。
こちら → Commet
経緯はこんな感じ。
ということで、もう少し体裁を整えてから、ちょっと宣伝とかしてみようと思ってる。
が、今回の本題は、技術的な話。
色んなサービスからデータを集めるので、当然、色んな API を使わなければならない。現在、以下のサービスのAPIを使って、データを取ってきている。
（その他、webhook 経由で Redmine にも対応しているけど、詳細は省略。）
これだけ色々使ってみると、それぞれの API の癖や、長所・短所などが見えてくるので、そういう事について書いてみる。
Play! framework の JSON ライブラリって、慣れればまぁ普通に使えるけど、ドキュメントがイマイチだし、やりたいことをどう書けばいいかが分からなくて時間を使うことが多い。
今回書くのは、JSONデータである要素が存在しない場合にそれをどう扱うか、という話題。
「なんだ readNullable 使うだけでしょ？」
と思う人もいるかもしれない。まぁ実際にはそうなんだけど、readNullable の挙動が若干分かりにくかったので、それについて。
JSONデータで、ある要素が存在する場合と存在しない場合が考えられるとき、その要素が存在する場合は Some 、存在しない場合は None としてパースしたい。
具体的な例で説明すると、Facebook APIから以下のようなJSONが返ってくるとする。内容はあるFacebookグループへの書き込み。
Suppose we have a table definition like this:
case class T1 (
id: Int,
col1: Option[Int]
)
object FooDb extends Schema {
val t1 = table[T1]("t1")
}
And, we want to execute a query like the following:
select * from t1 where col1 < 10
The correct statement in Squeryl is shown below:
from(FooDb.t1)( t1 => where(t1.col1 lt Some(10)) select(t1) )
This isn’t very intuitive, and actually, it took me a lot of time to get to this answer.
The most intuitive one doesn’t compile:
where(t1.col1 lt 10) // -> doesn't compile
This one causes NoSuchElementException:
where(t1.col1.get lt 10) // -> NoSuchElementException
Another one that causes NoSuchElementException:
where(t1.col1.map(_ lt 10).get) // -> NoSuchElementException
I’ve found some guys that were having the same issue:
I think the Squeryl web site should have an example that uses nullable column in the where clause.