YAPC::Asia Tokyo 2014の感じ方
YAPC::Asia Tokyo 2014、1日目に参加してきました。
僕自身は2012に参加したので、今回が2度目の参加です。
ひとまず、オープニングから聞いたセッションで個人的に勉強になった部分と、感想を書き連ねてみます。
Title:YAPC::Asia 2014 Tokyo - オープニング
Speaker:Yusuke Wada氏
Blogを描くまでがYAPC::Asiaです。今書いてます。やはり大量の情報を一度に詰め込んだので、こうしてブログを書くと消化不良が改善されるように思います。
Title:インフラエンジニア(狭義)は死んだ
Speaker:Satoshi Suzuki氏
コードは問題解決の手段。今目の前にある問題は何かを考え、問題解決に必要ならばコードを書くし、不要ならば別の手段で対応する。
問題解決スキルって大事だなということを再認識。インフラ、というか、どの業種でも現状の課題をしっかりと認識するのは重要なことだと思います。
Title:完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ
Speaker:Kenji Naito氏
システムも人間も完全ではないという前提のもと、Webサービスの創生、成長、安定という各フェーズにおいて重要なことは何かというお話。
創世期
Webサービスを始めるときに大事なこと
１：記録をとること
＝同じ環境をもう一度作れること
２：保険(Insurance)
＝アプリケーションの分散、ユーザ情報のバックアップ
ハードウェアはいつか必ず壊れるし、人もいつか失敗するので
成長期
人が多くなってきたりしたときに必要なスケールアウト時に必要なこと
１：再現性を持つこと
＝どこでも同じものが作れること
２：シンプルさ
＝環境に依存せず、疎結合で作ること。依存関係を持たない。
これで変化に強いシステムが作れる
安定期
サービスの追加時には複雑性が増す。このときに必要なこと
１：再現性を持つこと
２：シンプルさ、簡易性
機能ごとに疎結合であればスケールアップ、スケールアウトが容易
世には予測できる変化と予測できない変化がある。変化に強い状態にしておくこと、人についてもシステムについても。
シンプルさについては、コードを書いていて意識することもありましたが、再現性はあまり意識したことがなかったなと思ったり。
記録を残すというのも、割と忘れがちなのでどんどん書いていかねば。
Title:最近のウェブサービスの検索機能やその先の話
Speaker:Yusuke Yanbe氏
はてなの検索ミドルウェアの変遷について知ったり、Elasticsearchの特徴を学んだり。
はてなの検索も、初期のほうはMySQL LIKE検索だったと知り、驚いた。
より複雑なクエリが必要になったため、SolrからElasticsearchになったそう。
今後の予想で機械学習の機能充実からデータマイニング方向へ行きそうという話があり、そうなると一気に面白くなりそうだなと思った。Elasticsearch触ってみたくなりました。Search::ElasticsearchというCpanモジュールがありElasticsearch,Incで公式にメンテしているというお話なので使ってみよう。
Title:Perl::Lint - Yet Another Perl Source Code Linter
Speaker:Taiki Kawakami氏
Perlの静的解析とperl::Lintのお話。54さんマジイケメン。
Source Code Linter：ソースコードを解析して、バグらしきものを見つけるもの。
きれいなコード≒レビューしやすいコード＝メンテしやすいコード
ちょっと遅いからという理由は一つモジュールを作るのに十分な動機なのだなぁ。
ところどころgrepとanyの要素数による処理速度の差やfileopenメソッドの話など、なるほどそうなのかと思えるお話もあり、なによりトークの仕方が面白かった。
今度遊んでみよう。FB得られるのって大事だなぁ。あるとないとでモチベとかダンチだもんなぁ。
Title:Git を使ったツール開発
Speaker:motemen氏
git help -aで、gitのサブコマンドが全部出るよ
git help -wで、ブラウザ開くよ
やる夫で学ぶ gitcore-tutorial - MOTEMEMO
通勤時に読もう。
Title:継続的翻訳活動をささえる技術
Speaker:Atsushi Kato氏
Perlの翻訳でなにがきついのかというと、翻訳を始めることと、更新をすること。
tranを使えば簡単に翻訳が始められるし、更新も簡単になるよというお話なのだが、個人的にはやはり「Perlが好きだから！」という理由で翻訳をやっているというお話が最初にあって、そこに共感した。好きでいられるって才能だと最近改めて思ったのでなおさらでした。自分もやはり好きだから、今の業務できるもんなー。
Title:WHERE狙いのキー、ORDER BY狙いのキー
Speaker:yoku0825氏
インデクスの動きをPerlのコードで解説してました。今まで経験則と感覚でしか理解してなかった部分について、こうやってコードで示されるとすごく目からうろこというか、わかりやすくてびっくりしました。
入社して2年間で、DBやテーブルの設計をしてレビューされて知ったことの多くをちゃんと改めて説明してもらえた良い機会でした。ほんとになるほど！しかなかった・・・。聞いてよかったこのセッション。
Title:Get a kick out of CPAN
Speaker:Kenichi Ishigaki氏
個人的にはあんまり意識していなかったCpanの中のお話。
perlにもマーケティングをやってる人はいるというのは初めて知った。
CPAN大事。方言がそれなりに揃う。”テストはt/配下にある”とか。
CPAN自体を健全にしておくことも大事。
日本でCPANにリリースされる数が、全体の割合として多くないという危惧をされていた。CPANオーサは結構いるのにあんまり活発にリリースされてないようだ。やはりFBないとモチベが上がらないのかなー。これが見られてる感というものなのかな。
CPAN newというものを知ったのでさっそくフォロー。
CPAN New Modules (cpan_new) on Twitter
あと、↓もあとでじっくり読みたいところ。
http://gihyo.jp/dev/serial/01/perl-hackers-hub
Title:初心者が Web エンジニアのコミュニティに触れてみて感じたこと - ゆとりエンジニアの成長戦略
Speaker:zoncoen氏
最近の若者優秀すぎてコワイ。しっかり発表もして意識も高くてまぶしい。
興味のある分野で有名な人を片っ端からtwitterでフォローしたというのは、ソーシャルネットワークに慣れてる人の使い方だなーと思ったり。
かたや技術ブログの重要性をちゃんと理解してらして、自分ではまったこととか便利だと思うこととか何でもいいから書こうというのを聞きつつ耳に痛い話でした。書かねば・・・。
LT
台湾すげぇ・・・。あと個人的にどう活用していいかわからないけれど、あのLTの雰囲気だけでAcme大全ほしくなってしまった。ラーメン食べたい。
全体を通して
最初に書いた通り、僕は新卒なりたての2012年に初めてYAPC::Asia Tokyoに参加したのですが、2年たって聞いた今回は2年前より楽しかったです。
それはおそらく、いろんな業務をやらせてもらって、遅々としてですがPerlやSQLなどいろんな知識を得ることができたからだと思いました。
2年前よりも圧倒的になるほどとか、知っている単語が増え、スピーカーのみなさんが笑いとして仕込んでる内容も何も考えずに笑うことができました。
年数と回数を重ねることで、より楽しくなっていくのだなと思います。
そしてまた、今日学んだことを業務で生かして、新しい知識を得たうえで来年、再来年のYAPC::Asiaに参加することで理解と楽しみが増える。よい循環だと自分でも思うので、次のYAPC::Asiaをより楽しめるように、業務を楽しもうと思いました。
稚拙ながら、個人的感想でした。
プラモデルの重なり方
０から１にするときに学んだこと。
今までなかったシステムを作るという経験をしているのですが、その中で今思っていることを書きます。
「プログラミング言語は道具でしかない」ってのはなんとなく感覚で理解してたのですが、０からシステムを作っていく上で、なんとなく腹に落ちたのです。
開発って、プラモデルを作るのに似ているなと思います。
作りたいプラモデルの形、説明書、部品、道具、技術（くっつけるだけも含む）。
これらが全部ないと、プラモデルは完成しないわけで。
開発も、同様だと思うんです。
要求、設計、コンポーネント、プログラミング言語、プログラミングスキル。
全部揃わないと、完成しない。
どれかがかけると、思ってたのと違うものができてしまう。
そして、重要度も似ていると思うのです。
道具と技術があっても、どうしようもない。
一番大事なのは、作りたいプラモデルの形、説明書。
これらがないと、どうやったってダメで。
部品と、道具と、技術だけでも、つくれることはあるけど、思ってたのと違うことがある。
開発も、要求と設計がちゃんと出来てないと、思い通りのものはできない。
そこで9割が決まってしまう。
だからプログラミングは道具で、開発の上では重要度は低いものだと、感じました。
でも、だからといってプログラミングが適当で良いわけはなくて。
プログラミング技術を貪欲に得なければならないとも、思います。
僕は、子供の時によくBB戦士や1/144のプラモデルを作っていたんですが、よく違うプラモデルの部品を取り替えて、別のものにしていました。
BB戦士同士の部品をとりかえっこするのは、簡単にできます。
基本的に穴の大きさが一緒だからです。
でも、BB戦士の部品を1/144のプラモデルにうまく付けるには、技術がいります。
例えばBB戦士の頑駄無流星王の肩パーツを1/144のガンダムデスサイズに付けようとするなら、カッターなどを使って切込を入れる必要があります。
プログラミングの技術を得ることは、部品をうまく使うためにカッターという道具を使えるようになることに似ていると思うのです。
たくさんの技術を得て出来ることを増やし、思い描くものをうまく作れるようになる。
そのためには、やはりプログラミング技術も重要なのだと、感じます。
と、今更なことを書いてみましたが、僕にとってはこう、いままでもやがかっていたことがはっきりしたような、そんな気分になったので、書きました。
意思の決め方
二度目だよ（1回目はノーカン）。
最近、まとまって意思決定というものを学んだので、個人的に学んだ部分をつらつらと書いていきます。
・意思決定とは
http://ja.wikipedia.org/wiki/%E6%84%8F%E6%80%9D%E6%B1%BA%E5%AE%9A
答えはない課題、問題、状況において、どのように自分の意思を決定するのか。
その決定に正解はないんだけど、如何に的を外してない意思決定ができるか。
そういうことについて、いろいろなケースについて考えながら、学んで行きました。
いろいろなことを学んだのですが、私の中では、これらは２つに分けられます。
ひとつは、意思決定を行うためのメソッドについて。
もう一つは、どういう心構えであるべきかなどのマインドについて。
個々に、学んだことを書いていこうと思います。
<メソッド面>
・MECE
・IssueTree
・アクションを起こす前に、事実関係(1次データ、例えば決算短信)の確認を行う
→このあたりは基本中の基本らしいですよ。
・その状況、課題について、whyを繰り返し考えること
→問題や状況の本質を見抜かないと、的はずれな決定を行ってしまいます。
・これにだったらこの金額を払えるor払えない の感覚を大事にすること
・ビジネスならば、競合の悪口を考えること
→このあたりは、特にビジネスでの具体的な意思決定の内容を考えるために必要なメソッドですね。ソシャゲーのガチャなんかでも、これには出せる、これは出せないとかありますよね。
・意思決定内容は、1つに絞ること
→意思決定のためにいろいろ考えていると、時々”答え”を探していることがありました。優等生的な答えなんですが、そういうときの答えは総じて「あれもこれもやります」になってて、そりゃ全部できるならいいけど、現実はそうじゃないんですね。リアリティをしっかり考えて、１つ、ないし２つに絞って考えるべきですね。
<マインド面>
・視座を高く、具体的には2段階上の役職の立場で物事を考えること。
→これはメソッドかなぁとも思うんですが、個人的にはマインドに入れときます。常日頃からこういう考えをもつことで、意思決定速度が速くなります。つまり常日頃から考え続けろってことだと思います。マッキンゼーのようだ。
・一度”決めた”ら、あとはそれを信じて走っていくこと
→やるのは自分(たち)なのだから、自分がやらないような決定を行うべきではない。もちろん時には、決定とは異なることを途中からやらなければならないこともあるでしょうが、それもまた意思決定。
結局、意思決定ってのは一朝一夕でできるものではないですね。
だからこそ、一番大事なのは「常に考え続ける」ことだと思います。
自分だけでなく、この人だったらこうではないか、自分がこの人ならどうするか。
そういうふうに、毎日考え続けないとできないんでしょうね。
実際に意思決定が必要な場面では、多くの時間があるわけではないので、スピードも必要になります。
そう言う意味でも、常常考え続けておかなければダメなのだとおもいます。
プログラムも、答えがないというか。
仕様はあるけれど、それをどう作るかは作る人しだいみたいなところありますよね。
Solrの困惑み方
・Solrで悩んだんだよというお話
初めてSolrというものを触り、データの作成からUI作成まで一通り行ったので、そのうえで困ったとか、悩んでうーんうーん言ってたことを書き連ねてみようと思います。
１：Solrドキュメントの少なさ
なんか少ないんですよね。ちゃんと言えば、「日本語ドキュメント」が少ない。海外ではJIRAチケットだったり掲示板だったりで悩み書いてたり情報があったりするんですけど。
技術評論社のApache Solr入門を片手にうーんうーん言ってたりして。でも結局最後には海外で同じようなミスをしてる人の悩みを見てやっとわかったーってなった時には結構な時間割いてたり。
「日本でのドキュメントが少ないのはなんでだろう」って考えたんですけど、実は日本語ドキュメントもそこそこあるんだけど、問題はこう、初心者が悩むような悩みの対処が書いてないからではと思ったりしました。プログラムもあんまよく分からないひとがSolrさわってみよーとかならないんですね、きっと。
だから少しずつ、なんか書いて良ければと思います。
2：optimizeの必要性
Solrの機能の一つ、optimize機能。
Apache Solr入門のP266には「Solrはcommitのたびに一群11個のファイルを作成する。なので、commitを細かくし過ぎるとインデクスとして多くのファイルを使うようになるので、パフォーマンスとかファイルディクリプタに悪影響」と、いう話が書かれています。そのあと、続けて「目安としては5commitに一回optimizeしよう」と書いてます。
僕にとってはApatch Solr入門はバイブルのようなものだったので、へーそうなんだーと思っていました。
ところが、いろいろ見てみると下記サイトでは「optimize自体が高負荷。5commitに一回はインデクスサイズが小さい時ならいいけど、そうじゃないときはもっと頻度下げよう」という話が書いてあります。
http://aoking.hatenablog.jp/entry/20120809/1344507896
optimizeの頻度は結構時と場合によって変えなきゃいけないんだなというのがわかったところで、じゃぁ今のこの僕の検索システムではどれくらいが適切なんだ？と悩みました。
Solrの有識者の方に意見をうかがってみると、以下のようなアドバイスをいただきました。
・インデックスは1日1回更新とか小さいサイズでなければ optimizeしないほうがよい
・少なくとも Solr 4 以降は 通常の セグメントマージ(インデックスのセグメントをmergeFactorの数の中で適当にする)で適当にされるので, optimize は特にしなくていいらしい(https://twitter.com/kojisays/status/197863133119909888)
ということで、今回はoptimizeは明示的に行わない方向で結論となりました。
3：再インデキシング時の罠
schema.xmlについて、あるfieldをtype:Aで定義してました。
<field name="name" type="string" indexed="true" stored="true" />
この定義で、１度インデキシングを行いました。
その後、そのfieldについてtype:Bで定義しなおしました。
<field name="name" type="2-gram" indexed="true" stored="true" />
この時、インデキシングし直すときに、前のインデキシングしたデータを消さずに再インデキシングしてしまうと、このfieldについて検索したときに、トークナイズできないよとか、サーバーに言われます。例えばこんな感じ
SEVERE: java.lang.IllegalStateException: field "name" was indexed without position data; cannot run PhraseQuery (term=210)
僕はこれの原因がトークナイザの設定にあるもんだとばかり思っていたため、トークナイザを変更してはうまくいかない、うーんうーんと言っていたわけです。
しかも、利用していたのがn-gramでのトークナイズを行う NGramTokenizerFactory だったり、WhiteSpaceTokenizer + LowerCaseFilterFactory + NGramFilterFactory だったりしたわけないんですが、こいつらも実は問題を持っていて、そのせいなのかなーうーむと首をかしげる時間が長かったです。
http://moyolab.blog57.fc2.com/blog-entry-90.html
http://sharp-m.hatenablog.com/entry/2013/05/21/014403
しかしいろいろ検索しているうちに、以下の投稿を見つけました。
Did you maybe index the initial data with different field types and then change to the current field types, say "string" and then move to "text_..."?
If so, simply delete the index and re-index.
(意訳)「もしかしてお前、前に別タイプでインデキシングしてないか？それなら消してから再インデキシングしろよ」
そうだ、消して無かったー。
なので、インデクスを消してから再インデキシングされるとちゃんと検索できました。
・終わりに
僕が始めてSolrで全文検索システムを構築したときに悩んだ三つをあげてみました。
同じように悩んでいる人が少しでもすぐに答えを見つけてモヤモヤを脱出できることを願います。
first commit
技術者だもの、常にcommitするよねー
という意識が、インターネットに対しては低かったので、書く場をとりあえず作りました。
今回技術系な内容はないけど近いうちに書きます。
内容はsolr関連で。
言語処理ぽい。
