ScalaMaturi2014に参加してきた
感想としては、Scala楽しそうですね。
良かった点
- お値段がカンファレンスとしては高すぎず助かった。
- 出てきたお弁当がそれなりにいい物で美味しかった
- 長丁場なのでお菓子とか水が飲み放題なのは助かった。
- 空調とか音声周りの対応が早かった。
- 講演内容が技術寄りで初心者の自分としては為になった。
困ったなあと言う点
- とにかく長帳場でお昼もガチのLTが流れるのでもうちょっと息つく暇が欲しかった。
- ABの2会場あったのですがどちらも聞きたい感じのセッションが多くて辛かったです。
目立った単語
話しを聞いていてよく聞こえてきた単語がこのようになります。
話の内容を大別すると
使用しているライブラリ等
- 並列分散ライブラリ:Akka
- WebFramework: Play
- ORM: Slick
- Twirl: テンプレートエンジン
Akkaはとにかく技術系の話が出るたびにほぼ毎回でてきました。並列・分散のライブラリなのでその辺の需要が高かったんですね。PlayはメジャーなWebFrameworkなのでこちらも何回か見た気がします。ORMはSlickの話しもよくでましたが他にも何件かライブラリが例として上がっていました。
各種発表のメモ
「GitBucket: Perfect Github clone by Scala 」
ScalaとJGitで作られたオープンソースのプロジェクトGitBucketについての紹介でした。githubで開発されていて、現在3000越えのstarをもらっている。開発者もcontributorもそれなりにいるけどまだまだ理想の開発速度を出すには足りないから開発者が欲しい。依存しているテクノロジーとしては、Scalatra, Twirl, Slick, JGit, H2, Jetty, Apache MINAと言った物をしようしています。フロントエンド側は、JQuery, Bootstrap2, jsdifflib, google-code-pretty,AceEditor,DropZone,ZeroClipboardと言った物を使っているようです。
絶えずgithubの開発ブログやデザインなどをキャッチアップしているそうです。開発ではIntelliJ IDEAで開発していて,Gitter,ZenHubを利用しているそうです。最後に質問で、数百人レベルで使用されている事例はありますかという物がありまして、その規模になると現状の実装だと辛いという話しをされていました。
Xitrum Web Framework ライブコーディング
ハイパフォーマンスなScalaのWebFrameworkだそうです。採用事例は国外の方が多くてフランス・ロシア等でよく使われているみたいです。内部アーキテクチャでAnnnotation周りの説明があって、チャットアプリの作成デモをされていました。ScalaとJavaのアノテーションの違いとかAkkaとか初心者の自分には割とその辺が興味を引く話題でした。
ランチLT
ランチLTと書いてあったので、ライトな発表だろうと思って油断していたら
時間が短いだけでガチなLTが多かったのでびっくりしました。
スポンサー企業が発表していきました。全部では無いのですが、
技術的な話が多かった物をメモしていたので残しておきます。
LINE
LINE社はBackendの話しで「Asynchronous Tasks Monitoring Tool」、「Distributed Tracing System」それに絡んでFinagle, Slicck Saddle, Scrooge、Zipkinといったツール群の話しが聞けました。
http://slick.typesafe.com/
https://github.com/saddle/saddle
https://github.com/twitter/scrooge
https://github.com/twitter/zipkin
サイバーエージェント
サイバーエージェント社はDynalystというサービスでScalaをつかっている会社で配信システムのところで使っているとのことでした。
週一でFunctional Programming in Scalaという本で読書会をしているそうです。技術的にはakka,spray,redshiftなどが出てきました。
http://manning.com/bjarnason/
http://akka.io/
http://spray.io/
http://aws.amazon.com/jp/redshift/
DWANGO
DWANGO社はAndroid API Server, New niconico live、その他4つぐらいのサービスでScalaを投入されているそうです。基本的なArchitechtureはScala 2.1、Play, specs, Scala Test, Squerl, ScalalikeJDBC, Twirl, Scalate+ Mustache, Akkaを採用しているようです。
https://www.playframework.com/
https://code.google.com/p/specs/
http://www.scalatest.org/
http://squeryl.org/
http://slick.typesafe.com/
http://scalikejdbc.org/
https://github.com/playframework/twirl
http://scalate.fusesource.org/
http://akka.io/
グリー初のScalaプロダクト!チャットサービス公開までの苦労と工夫
GreeChatのバックエンドをScalaでどう構築したのかという発表でした。ユーザー数が多く、リアルタイム性を要求され、少ないサーバー台数で動作させたい、5年以上はメンテしたいという要件を満たすものを探したときにScalaが浮上してきたそうです。採用の理由としては、平行プログラミングに強い、一プロセスで複数のコネクションを張れる、静的型付けでの保守性、チームにScalaおじさんがいた等があげられていました。ただ、全体数のなかでScalaおじさんの占める割合が低かったので自主学習とチーム学習を使いこなして乗り切ったそうです。実装としてはfinagleを使用したリクエストを受け付けるのに専念するAPIServer,DB等絡む処理でakkaを使用したEventBusServer,ストリーム関連を担当するStreamServerの
紹介していました。実際に開発する際に出てきた問題は、FullCG,Sharding, UIDとInnoDBとの相性の悪さという問題とその対処が語られました。
ID生成機を作成するという話しをされていたのですが、その成果であるコーンフレークという名前だった気がするのですがググっても見つけられませんでした。あとは、ドメイン駆動設計で作成しているという話しをされていました。
https://twitter.github.io/scala_school/finagle.html
http://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88
国技とScala
ドワンゴにおけるScala開発事例で、相撲協会公式アプリのバックエンド開発の話でした。Scala選択の理由として、Type-Safeであること、OOP,Immutable, map/fold,traint,monadといったSkillを強制的に学べることなどを上げられていました。ライブラリの所管としては、ScalalikeJDBC,Twirl,Scaladi,ScalaTestなどを良い面、悪い面をあげてそれぞれ紹介されていました。あとは、得られた知見として ExceptionHandlinでTryを使う、Static Code AnalysisでSCoverageがいいらしい、デプロイ面の話し、Tuningの話しなどをされていました。
macで使ってるmarkdown viewer
メモ書きをmarkdownで作成したり残したりすることが多いのだけど書いてる最中に綺麗に表示してくれると脳味噌的に助かるのでviewer欲しいなぁと思って探してたらharoopadというものを見つけて割といいです。
- 方言とか選べない
- いま自分が編集してる部分に集中できない
など細々気になるところはあるのですがテンポラリの記録を書き留める物としては十分に有効なので割と重宝してます。
何してるのか?
最近プライベートだと仕事とは別の言語使っていることが多い。それはまあ別のことがやりたかったり、読みたいプロダクトが別の言語だったり色んな理由があるんだけど、とてもしんどい。自分の好きな言語で好きなことしてるのになんでこんなにしんどいのか、おそらくは目的に到達するためにもっと早い自分を知っていてその比較から多分いらついていてそれで苦しんでいる。どうにかならないかなぁと考えていたら、そもそも僕は言語を通して何をしていたのかということふと思い至ってそれですごく楽になった。
わかりやすい発表とはどんなものなのか?
つい先日カンファレンスにいって何件か発表を見てきました。どもれ素晴らしい発表でしたが、私の不勉強と認識の問題が大きいかと思いますが、分かりやすいプレゼンとわかりづらいプレゼンがあってなんでだろうな?と考えてしまったのでちょっとメモしておきます。 分かりやすいプレゼンに絞って言うと、これから何を話すかという目的、概念、抽象化されたものが先に来ます。そこからトップダウンで下がっていって具象、詳細に至ります。これは日常の現象に対する認識と逆で、通常の場合現実に起きている具体的な現象を認識してそこから「何が起きているのか?」ということを考えたり、相談したりして結論を得ます。つまり、具象から入ると言うことは見ている人にワンテンポ考えさせてしまうということです。これはこれで使いようによってはいい発表になるときもありますが、難しいことを喋っている、発表している、若しくは分野が広域に広がっているときには逆に混乱してしまいます。なので、何を話すんだよというのを大きく先に提示した上で、つまり結論を先に言った上で詳細を解説するという流れが分かりやすいのではないのかなぁとぼんやり考えてたりしました。あとは、具体例にたいしてしつこく何が起きているのかを述べているのも分かりやすかった気がします。「具体例」-> 「突然のエラー」-> 「つらい」みたい感じかな。見てる人に旨い感じに脳味噌を使わせると言うことが重要じゃないかとも考えました。
正しくレビューをするということが難しいのはなぜだろうか
システム開発をしていると、大体において開発した物に対して識者からレビューという物が発生します。非常にわかりやすく言うと、できあがった物が適正かどうかを判断してもらうわけですね。ところがこのレビューという物、適切に行うのは非常に難しいのです。
- レビューする側が問題領域をきちんと理解してる必要があり。
- さらにそこに使われている技術等が適切かどうかの判断。
- データ量などが将来にわたってどうなるか等を判断
などをしなければいけません。物事の論理に従って理性的に、良い意味で機械的に正しくあるべき姿を提示できるのが理想的かなと思っています。現状自分がいるところはある意味適切という意味で希少な例のところにいるかなとはおもっていますが、ただ、大抵の場合そうはなりません。レビューという名の誰の益にもならない個人たたきになる場合が非常に多かった気がします。上記の3つをきちんと満たすことはもちろんのこと、適切じゃ無いレビューをすることがレビューをする人にも、受ける人にも、会社にも、誰の得にもならないと言うことを理解してなければならないと思います。その上で、将来のために、相手のために、自分自身のために行うことが必要じゃ無いかなとは思います。悪い例を挙げていくと、
- 重箱の隅つつき
- レビュー段階ならないと発覚し得ない情報がある(暗にこめたんですよねとか)
- レビュー者の気分で技術方針がコロコロ変わる
- レビュー者の趣味の押しつけ
などがあげられます。もちろん大抵の人間は神じゃないので完璧じゃ無いのでこれを毎回100%満たすことは無理だと思います。こういうことが起きうる要因って何だろうかと考えたときに、以下のレビューアーが内包するメタデータに起因するのでは無いかと思っています。
- そもそもどうやってレビューするのか不明
- 本人の性格
- 技術レベル
- 体調の良し悪し
- 技術的指向性が開発者と同じ方向性をむいているか
- 交友関係の障害等
- 現在担当している仕事の量
- 開発者が好きか嫌いか
- 社内政治
本人の性格や技術レベル、社内政治や交友関係等は解消しづらい問題では無いかなとは思いますが、対人問題であれば双方にとって気持ちよく終わって問題を起こさないようにするぐらいしか指針が出せませんが(問題領域に詳しくおすすめの書籍等詳しい方は教えて頂きたいです)、こちらが根が深く根本的に解消しづらいところもあるので困難さの一員では無いかと思います。単純にレビューという技術であればぱっとアマゾンやググって見た感じ何件かでてきたので並べておきます。何かおすすめのサイトなり書籍があれば知りたいです。
- 作者: 織田巖
- 出版社/メーカー: ソフトリサーチセンター
- 発売日: 2006/07
- メディア: 単行本
- 購入: 4人 クリック: 125回
- この商品を含むブログ (3件) を見る
- 作者: 森崎修司,日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2013/09/19
- メディア: 単行本
- この商品を含むブログ (1件) を見る
- 作者: Karl E.Wiegers,大久保雅一
- 出版社/メーカー: 日経BP社
- 発売日: 2004/02/28
- メディア: 単行本
- 購入: 7人 クリック: 152回
- この商品を含むブログ (25件) を見る
- http://www.src-j.com/books/pdf/228_pt.pdf
- http://monoist.atmarkit.co.jp/mn/articles/1011/11/news116.html
多岐にわたった知識を総動員し、それぞれに対してかなり詳しく使いこなしているする必要があり、そういった理由から難しい技術なんじゃ無いかなぁと言う気はしてます。関係する領域においてなるべく勉強はしておきたいです。(自戒の念を込めて)
openされたファイルとunlinkについて
tmpfileの挙動でオープンしたと同時にunlinkが発行されて後始末をしなくていいという話だったんですが具体的にどういう挙動なんだということが気になりまして調べてみたら、unlinkはファイルシステム上の名前の削除で、さらにどのプロセスもファイルをオープンしていなければファイルが削除されるという(see man 2 unlink)ことになっていて、tmpfileの挙動はこれを利用した物になっているようです。従って受け取ったファイルディスクリプタをcloseしてしまうとプロセスが起動中でもそのファイルは削除されてしまうようです。
参考
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/unlink.2.html
http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html
- 作者: Michael Kerrisk,千住治郎
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/01
- メディア: 大型本
- クリック: 14回
- この商品を含むブログ (5件) を見る
tmpfileについて調べたこと
Linuxにおいて大体何かを組んでいると一時的に何かに保存したいとかメモリ食べたくないとか様々な理由で一時的なファイルを作成すると思います。一時的なファイルを作成すること自体はそこまで難しくなく/tmp/以下に好きな前をつけて扱えばいいと思うのですが、好きに/tmp以下にファイルを作るのは複数プロセスが立ち上がった場合に同一ファイルを意図せず見てしまう、他のプログラムが同一の名前を意図せず使用してしまう、セキュリティホールなどになってしまう(see man tempnam)などの危険性があります。頑張ればこれらの問題はファイルオープン時におけるオプションのO_EXCL(see man open)とファイル名生成の工夫で大体は解決つくはずですが、これを頑張らなくてやってくれる仕組みがtmpfileです。読み書き用で開いてO_EXCLで他のプロセスが同じ名前で開くことを防ぎます。おまけにオープン直後にunlink実行してて削除してくれるので後始末も安心です。(/tmp以下は大体の場合はtmpwatchというcronによって良きに削除されていくのでそこまで問題にはならないですが)各言語にもtmpfile相当のものが実装されていて似たような挙動をするはず。
例を取ってPerlだとFile::Tempというモジュールがありまして。
tempfileの実行テスト
use strict; use warnings; use File::Temp qw/ tempfile /; my ($fh,$filename) = tempfile( UNLINK => 1); print $filename . "\n";
実行結果
/tmp/T4Yk7WE06m
確認すると削除されています。
デフォルトの挙動でファイルが残るので
UNLINK => 1 をtempfileのオプションとして残すと削除されました。
同様な処理として一時的なディレクトリを作成する処理としてtempdirというものがあるのですが、LinuxProgrammingInterfaceにはこの用語出てこないです。代わりにmkdtempというCライブラリの話が出てくるのでこちらがあたるのでしょうね。
参照
- 作者: Michael Kerrisk,千住治郎
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/01
- メディア: 大型本
- クリック: 14回
- この商品を含むブログ (5件) を見る
https://metacpan.org/pod/File::Temp
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/open.2.html