Chromeのハードディスクアクセス抑止

　ある日、Chromeを立ち上げたらハードディスクがものすごい音を立てて動きだし、延々と何かやっている…。Google検索すると、フィッシング対策をオフにするという対策がありましたが、どうも効果はなし。
　書き込み状況を追いかけてみると、プロファイルディレクトリの下のDefault/Local Storage の下に、何やら激しく書きこんでいました。




　消してもすぐ復活させられてしまいますが、localstorageとかjournalとか名づけられたこれらのファイルを読み取り専用にしたところ、無事黙らせることに成功。やれやれ。

C87当選

◎貴サークル「浜風もっこす」は、火曜日　西地区“く”ブロック－23a に配置されました。


　3日目の西という、また若干行きづらい配置ではありますが、今年は最終日が大晦日ではないのが救いですね。
　夏はバックアップ体制に不備がある状態で作業していたのに気付かず見事に吹き飛ばしてしまい、予定していたネットワーク本が出せない悲しい事態になりましたが、既にバックアップ体制は整えました。冬はいつものネットワーク本、艦これ攻略本のツートップをしっかり形に出来るよう、制作を進めていきます。ネットワーク本の既刊も、また少し刷って持っていくつもり。

　続報はまた、内容が固まっていき次第新規に投稿します。よろしくお願いします。

歌舞伎座.tech#5「すごいErlangをゆかいに学ぶ会」に参加してきた

いつのまにかAkkaやらErlangやら、並行処理系のフレームワークを扱っているドワンゴさん所の勉強会。今回はErlangということで、ささっと参加申し込みして楽しみにしていました。

公式：  歌舞伎座.tech#5「すごいErlangをゆかいに学ぶ会」 - connpass

発表枠

(以下の表は、現時点での公式イベントページより引用)

発表者	資料
sile@ドワンゴ	「ドワンゴでのホットデプロイ事例」
	「なぜERLANGにしたのか」（前回資料）
mururu@学生	「Elixir 1.0」
shino@Basho	「本番環境を止めずに問題を安全に解析する方法」
voluntas@時雨堂	「Erlang/OTP + Lua」

Elixirが文法や機能説明である以外は、実戦で使われた事例から一般的に使えそうな話を引っこ抜いて話してくれるような、実用性の非常に高い濃い内容でした。Erlang/OTPという存在自体が、実装は枯れていて、いかにシステムを構築するかを考えればよいフレームワークなので、勉強会も自然とそうなるんでしょうね。

実践的だった。Erlangだと、いかに華麗なコードを書くか！！みたいなこと誰も言い出さないのすき
— もっこす＠呉鎮→tktt昼 (@moccos) 2014, 10月 30

LT枠

(以下の表は、現時点での公式イベントページより引用)

発表者	資料
山口能迪@ymotongpoo	「『すごいErlangゆかいに学ぼう』でゆかいなところ」
t_egg	(Comming Soon)「Euler with Erlang」
KOU_CHANG@ドワンゴ	Erlang Utility Library (GitHub Repository)

LTはゆるい雑談な感じで。(感想とくになし)

懇親会

ピザと飲み物(缶アルコールとソフトドリンク)が配給されました。木曜日だというのに、23時まで酒飲みながらgdgdして、みなさん翌日大丈夫だったんでしょうか？
Elixirの講演をされた方を探していくつか聞いてみようかと思ったけれども、うっかり顔を覚えておくのを忘れたので、そのへんで適当に雑談。何の偶然か同業者の方を発見してしまい、Erlangとはあまり関係ないところで楽しかったです。
Erlangはすぐに「他の人がメンテできねえ」に到着してしまって、小さくて若者・精鋭がそろうところか、好き勝手にやれる研究部門でもないと、なかなか難しいですね。Scalaと違って、見た目がカッコよくて人が釣れる言語ならまだ可能性はあるかもしれないですが…

総括

Erlangを実際に使っている人にとっては、非常に実用性の高いイベントです。
Erlangを触ったことがない人の場合は…どうでしょうね。概要説明などせずに実際の問題に入るので、講演の概要くらいしか頭に残らないのでは。それなら家でスライドナナメ読みしたほうがマシｗ 細かい特性差を除くと機能はAkkaに近いので、Actor Modelの使いどころについてはあちらで慣れてくる手もありかも。

Erlang関係の勉強会は半年に一回くらいは開催する、というような話が聞こえてきた気がするので、次回以降にも期待しましょう。個人的にはその頃までに、Elixirで何か小物を作れたらいいなーと目論んでおります。

Scalaの実行コンテキストとFuture, blocking

ScalaのFutureというのは、下から(プロセッサに近い方からの)目線でいえば、処理をスレッドプールに丸投げする仕組みです。.NETにも似たような仕組みがありますね。

参考：Scala公式ドキュメント Futureの項目 (en / jp)

Futureの実行環境として、Scalaではscala.concurrent.ExecutionContext.Implicits.global というものがあり、implicitなExecutionContextとして、デフォルトでよさげなものを用意してくれます。このExecutionContextの挙動を確かめるために、ちょっとしたコードを書きました。

• moccos / FutureBehaviorChecker.scala (Gist)

基本は、第一引数で指定した数のFutureを生成して走らせるだけです。Future内では、実行タイミングとスレッド番号を表示します。

% scala FutureBehaviorChecker.scala 1
Processors: 8
Thread active: 3
Current Thread: 1
Mode: sleep without blocking{}.
Finished: 00 [   27 ->   228] at  10

% scala FutureBehaviorChecker.scala 6
Processors: 8
Thread active: 8
Current Thread: 1
Mode: sleep without blocking{}.
Finished: 00 [   28 ->   228] at  10
Finished: 05 [   31 ->   231] at  14
Finished: 02 [   31 ->   231] at  13
Finished: 03 [   31 ->   231] at  16
Finished: 04 [   31 ->   231] at  17
Finished: 01 [   31 ->   231] at  12

ExecutionContext.Implicits.globalの挙動

スレッドプール内のスレッド数は、プロセッサ数と同じだけの上限を持つようです。

% scala FutureBehaviorChecker.scala 10 
Processors: 8
Thread active: 9
Current Thread: 1
Mode: sleep without blocking{}.
Finished: 00 [   33 ->   234] at  10
Finished: 04 [   37 ->   237] at  14
Finished: 03 [   37 ->   237] at  13
Finished: 05 [   37 ->   237] at  15
Finished: 02 [   37 ->   237] at  12
Finished: 01 [   36 ->   236] at  11
Finished: 06 [   37 ->   237] at  16
Finished: 07 [   37 ->   237] at  17
Finished: 08 [  246 ->   446] at  10
Finished: 09 [  246 ->   446] at  14

9個目以降は、全スレッドがブロックしているので詰まってますね。
まあデフォルトなんてこんなものか。と自前のExecutorContext指定の方法を調べかかりましたが、そこに手を出す前にもっと簡単な方法がありました。

blockingの指定

本家のドキュメント内ではさらりと流されていますが、ブロッキングしてしまうような迷惑なFutureに対しては、明示的にブロッキング動作をするものだと指定できるようです。

参考： multithreading - Asynchronous IO in Scala with futures - Stack Overflow

自作のテストコードでは、第二引数に何か与えると、Thread.sleepをblockingで囲んだコードが走ります。

% scala FutureBehaviorChecker.scala 10 1
Processors: 8
Thread active: 12
Current Thread: 1
Mode: sleep with blocking{}.
Finished: 04 [   33 ->   234] at  15
Finished: 06 [   33 ->   234] at  16
Finished: 07 [   34 ->   234] at  17
Finished: 01 [   33 ->   234] at  11
Finished: 09 [   35 ->   235] at  19
Finished: 05 [   33 ->   234] at  14
Finished: 00 [   29 ->   234] at  20
Finished: 08 [   35 ->   235] at  18
Finished: 02 [   33 ->   235] at  12
Finished: 03 [   33 ->   234] at  13

使用するスレッド数が増えてますね。長くなるのでわざわざここには貼りませんが、100個同時に走らせれば100スレッド生成されるようです。スレッドを立てるので使用するリソースは増えるものの、全体がブロックすることはなくなります。
この大量に生成されるスレッドは、Futureごとにスレッドをひとつ立てるのではなく、あくまでもスレッドプールに増えるものです。Future実行に使用したスレッドは一定時間ごとにじわじわとshutdownされていきます。Futureを使った後、定期的にスレッド数をprintしてみると、じわじわと減っていくのがわかります。

まとめ

• Futureが走るスレッド数は有限
• ブロックする操作 or 時間がかかる操作なら、とりあえずはblockingをつける

ブロッキング操作するFutureが多い場合は、java.util.concurrent.Executors関連調べて、もっとまじめに実行コンテキストの管理をした方が良いのではないかと思います。ブロックする操作の先にある何か(DBやネットワーク接続等)で扱える並列性よりもたくさん並べても、意味ないので…。
プロトタイプや遊びで組むぶんには、blockingに頼ってしまってもいいかな。

Akkaの挙動確認用の小物を作った

AkkaのActorスケジューリング周りの挙動を確認するための、ちょっとしたものを作りました。

• moccos/CheckAkkaBehavior

概要

Actorの数、OSスレッドの数、Actor1個あたりに飛ばすメッセージ数を指定して回し、簡単なレポートを出力します。Actorのメッセージハンドリングが、どのスレッドでどんな順番で実行されたのかが表示されます。
適当に時間がかかるように、Actorはメッセージを受け取るごとにフィボナッチ数を求めています。この実験では別にsleepでも良いんですが、後々試したいことがいくつかあることと、OSやVMによるスレッドのスケジューリングに手を出したくないことから、この方法にしました。

Akkaの設定

参考：Configuration — Akka Documentation

スレッド数の設定

スレッド数は固定値を指定するものではなく「factor」「parallelism-min」「parallelism-max」の3項目と、実行環境で認識されたプロセッサー数によって決定します。まず最初に使われるのがfactorで、(プロセッサー数 * ｆactor)を切り上げた値が用いられます。その後、parallelism-minとparallelism-maxの指定範囲内にない場合は、指定範囲に収まるように値が補正されます。minよりmaxの方が小さい場合、maxが優先されるようです。

あくまでもfactorで計算された値が基本であるため、max設定値だけ大きくしてもスレッドは増えません。
このテストプログラムでは、引数-apf, -apmin, -apmaxによって、この3項目を設定可能です。

スループットの指定

Actorがスレッドを手放すまでに処理するメッセージの数を設定するのが、akkaのthroughputです。パッと見では、用語から挙動を想像するのが難しいような気がします。

AkkaのActorスケジューリングに用いられる単位は、メッセージです。Actorが(receiveで)メッセージを受け取ると、どこかのスレッドに割り当てられ、receiveのブロックから抜けると、Akkaのシステム側に制御を委ねます。以下の例では、Msg1を受信したらdoFoo()を実行して終了、Msg2を受信したらdoBar1()とdoBar2()を実行して終了。

class HogeActor extends Actor {
  override def receive = {
    case Msg1 =>
      doFoo()
    case Msg2 =>
      doBar1()
      doBar2()
  }
}

スレッドを明け渡すまでに、メッセージをいくつ連続で処理するかを示す設定値がthroughputです。メッセージがActorのメールボックスに5個届いていたとして、throughputが5以上あれば、一気に全部処理します。throughputが1であれば、1個処理したところで、Akkaのシステムに一度制御を返します。他にメッセージ処理を待っているActorがいれば、そちらにスレッドを譲ることになります。
スレッド上で走るActorの入れ替えにはコストがかかるので、一気に走り続けた方が性能面では有利です。しかし、あるActorが居座ったままだと、他のActorがいつまで経っても処理を始められないかもしれません。Configuration説明ページのコメントに set to 1 for as fair as possible とあるように、このパラメーターはthroughputとfairnessのトレードオフです。ここまで説明してようやく、パラメーター名の意味がわかります。
throughputパラメーターは、冒頭のテストプログラムでは -at で設定できます。メッセージの数を多めに、スレッドの数をActorの数より少なく設定すると、何がどうなるのか観察できます。

補足

各WorkerActorの始動に1つメッセージを消費しているため、最初の1サイクルはメッセージ1個分ずれます。

なぜ日本の情報技術系Q&Aシステムはクソなのか

現状

 　情報技術に特化した日本語のQ&Aシステム。かの有名なstackoverflowに相当するもの。
少なくともQ&A＠ITとteratailが動いていますが、どうもいまいちですね。Qiitaが「質問もできる」となっていますが、単にそういう内容の書き込みができるだけで、システム上なにかサポートがあるわけではないと思うので、これは除外として。
　他にもあるかもしれませんが、日本語版Stackoverflowが待ち望まれているということは、使えるサービスは無いのでしょう。

原因の推測

• 技術力のあるエンジニアほどstackoverflowで済むからそれ以外しか来ない？

 　最初に思いついたのはこれでしたが、日本語の方が有難い人の方が圧倒的多数だろうし、ローカルな問題も無限にあるはずなので、致命的な問題ではなさそうな気がします。

• 並んでいる質問内容が良くない？

 　多分こっち。投稿者側の質を向上させるのでは難しいことで、そうではなくて不適切な質問を削除するルールが整っているかどうかの問題です。stackoverflowでは、時々ストップがかかっているのが見られます。(→例)

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.

 　議論、投票等々は容赦なくcloseされる仕組み。調べものしたときに「俺はこっちが好き」「これどう思う？」なんて文面のスレッドが検索で引っかかっても解決に至らず、問題解決システムとしての価値を損ねるだけですから…。

・closeされるルールの説明 (stackoverflow)
・全体の仕組みの説明 (stackoverflow)

　 そして、この仕組みの運用。コミュニティが大きくなれば、スコアの高いユーザーが権限を持つ仕組みで回るでしょうが、スタートアップ段階では運営側でそこそこ人を割かないとだめでしょう。さらに日本人は厄介事を止めに入るのが苦手そうなので、定常的に運営介入を継続する必要があるかもしれません。Q&A@ITもteratailも「最低限だけ用意して、当たったら正式に投資しよう」程度のリソース投入度合いに見えますが、見た目だけ用意して適当にプロモすれば最低限かというと、たぶんそうではないです。

ScalaMatsuri 2014 参加記録

ScalaMatsuri。昨年はScala Conference in Japanという普通～の名前だったのに、突飛な名前になっていました。今年は1日目がカンファレンス、2日目がアンカンファレンス。

会場

会場となったサイバーエージェントさんのセミナールームは、電源環境・無線環境とも非常に快適。無理やりケチをつけるならば、どこから辿り着くのかさっぱりわからない点くらいですかね。探せば画像付きの案内図が見つかるものの、カンファレンスのページからは、13Fという情報しか得られないし…

内容

もはや小田好先生となってしまった設計者Martin Odersky氏を筆頭に、今年もかなり実績のある方々が参加。でも個人的にはそっち方面よりも、はてな・LINE・GREE等々最前線企業での使用例が出されて、システムアーキテクチャ・ソフトウェアの選択(ORMやテンプレートエンジン等)・導入の様子などが見られた方にありがたみを感じました。もはや導入 自体が珍しい段階は通りすぎて、使っている人が何かしらの課題・アイデアを抱えて参加している印象を受けました。

英語

海外からのゲストスピーカーを招いているため、一応スライドは英語ですが、発表や案内は日本語を使えない人以外は基本的に日本語。なぜか日本人同士が英語で質疑＆応答を行い全然通じない場面があり失笑を買った場面がありましたが、基本的には各自得意な言語で淡々とやる感じでした。私事ですが今の勤務先では、英語頑張るのは結構だけど、英語を覚えるのと仕事するのは切り離せと釘を刺されております。コミュニケーションの質を下げてはいけない。

英語ネイティブスピーカーのセッションには、なんと文字による同時通訳つき。運営の方々頑張りすぎでは…。進行・質疑応答補助・食事案内等、すごい運営のパワーを感じるカンファレンスでした。もうちょっと力抜いても良いのでは？と心配してしまいます。

総括

覚えるべきこと、Scala周辺に限っても無限にあるなあというのを再実感。
カンファレンスには色々ありますが、ScalaMatsuriは「色々やってみたくなる」「色々覚えなければとプレッシャーがかかる」という、かなりプラス方向の意識が得られました。もちろん意識だけでなくて、知識も業務上のノウハウも得られたはずだ…！(後で資料読み直そう)