TokyoRubyKaigi11に行ってきた

Tokyo RubyKaigi 11

上記のカンファレンスに出席したのでそれについて書く。
メモ書き程度に。

Streem
遅刻で最後の方を効いただけだったが、自作言語を作ることで色々身につくし楽しいぞという話をされていた。
Streemのリポジトリはこちら
Streem


mruby/c

組み込み系の話。
制限された環境下で動作させるruby、mruby/c。
起動速度が短いが、メモリを多く使用するような場面だと通常のrubyなどに劣る。
結局はトレードオフなのだな、と思った。

mruby/c


Rubyに型があると便利か

classチェックを行うと便利かという話。
個人的にはそういったチェックが厳密になると安定につながるので良い。
golangやCrystalの実装を参考にしたという話が何度か出たが、gemを作るのに他言語から着想を得るという考えが興味深かった。

発表の冒頭で紹介があった型システム入門についてはそのうち読みたい。




最速ウェブサーバの作り方
HTTP2の話。
終わり際に司会の方が「発表内容のすべてを理解してる人はいないのでは・・・?」と言っていたが、とにかく高度だった。
終盤までrubyの話が一切なかったが、それはそれで勉強になったので良い。
発表資料とページの表示スピードと売上の相関に関する論文はこちら

http://www.slideshare.net/kazuho/developing-the-fastest-http2-server
http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html


アプリケーションへのRubyインタープリターの組み込み
Cで書かれたアプリケーションにrubyを組み込んだお話。
正直rubyの実装についてはそこまで詳しくないため、割とついていけてなかった気がする。
組み込みを行うのは事例がないため、相当な覚悟が必要とのこと。
最後のQAセッションでは実装手段に関してrubyコミッタ同士の議論が行われていた。
コミッタ達の考え方の一端に触れれた気がする、内容は高度すぎてよくわからなかったが。

発表資料はこちら





Image Recognition and Code that shouldn't exist

ジョークも交えつつ、高度な技術が展開されとても面白かったセッション

自宅にある大量のMtGのカードを売却するために、画像認識で種類を特定し価値判断を行わせるという話。
自分の問題を技術で解決していて、最高のエンジニアリングだと思った。
画像認識はちゃんと使えれば相当日常生活に役に立ちそう。

開発着手の前にググれという話、耳が痛い。

https://twitter.com/makimoto/status/736454687151390720


家訓にしようと思う。







番外:OSS-Gate
同じ建物で行われていたOSS活動の支援団体。
RubyKaigiでも紹介されており、見学OKとのことだったので行ってきた。
OSSコミットに障壁を感じている人を手助けしているそうな。
隔月月末土曜日に定期的に開催されていて、下記リポジトリで活動の記録が見れる。
https://github.com/oss-gate/workshop


総評

rubyコミッタ同士のアツい議論が目の前で展開されたシーンがあったり、天才と噂のエンジニアのセッションを聞けたりととても刺激になった。
知的好奇心を刺激するという点では最高だった。

がんばろう。

エンジニアに必要な技術

エンジニアには純粋にコードを書く力や設計能力も必要だ。
だが、それと同じくらいトラブル時の調査能力というのも必要だと思う。


調査能力とは、問題発生時にどこに問題があるかを把握して、その問題を潰す能力だ。


問題解決時は適切なログを見て、エラーを補足したり、サーバーのログなどを見たりすることが必要となる。


もう少し踏み込むとコードの知識だけではなく、ミドルウェアやそれが乗っているハードウェアに通信プロトコル、さらにはハードウェアの知識も問われるかもしれない。
そのあたりの知識があれば、問題発生時に、どこに問題があるのか当たりをつけて効率的に対処できるだろう。


問題解決に活かせる知識を獲得するにはどうすればいいか?
その辺りは自分も模索中だが、様々な言語や環境に適用できる普遍的な知識こそが、
問題解決に最も寄与する知識なのかもしれない。
エンジニアとして生きていくには必要不可欠な能力なので、調査能力の伸ばし方はこれから模索していきたい。

言われる前に知っておくこと

ちょっと気になったのでメモついでに。

人は、例え事実でも、他人に指摘されたことを受け入れるのは難しい。
指摘されたことが欠点だったりするとなおさらだ。

だが、指摘されたことについて事前に知っていると、それを受け入れるのは比較的容易になる。

人が人と関わるときにやりがちな失敗について書かれた本は古今東西両手の指でも足りないくらいある。
誰か他人にそういったことを指摘される前にそういった本を読んでおくといいかもしれない。

勝つために何をすべきか?

渋谷心療内科・ゆうメンタルクリニック秘密コラム 「HUNTER×HUNTERと徒然草に学ぶ、『勝っちゃダメ』な理由」


この記事を読んでエンジニアにあてはめて考えたことを書いてみます。


よくよく言われていることなんですが、勝つためには2つの方法があると言われます。
ひとつは勝つ条件を達成すること、もうひとつは負ける条件を全て除去すること。


結論から言えば、私は後者を支持しているので、ここにその理由を書いてみます。



まず、上記のブログ記事にも書かれていることなのですが、積極的に勝ちにいくというのは相手をナメて思考停止になっている状態です。
勢いに乗って勝つのも良いかもしれません。
ですがその方法を続けていると必ずどこかで失敗して負けてしまいます。
負ける条件が残っているからです。


対して後者は、最初こそ勝つ確率は低いものの、徐々に勝つ確率を上げていきます。
しかも、このやり方は前者よりも数段安定しています。
負ける要素を排除しているからです。


負ける要素を排除して、後は勝つ条件を満たすだけの状態に持っていければ、長期的に安定して勝ち続けることが出来るでしょう。


ただ、これには長い時間と多大な努力が必要となります。
負けた時は、その負けを分析して同じ事を繰り返さないようにする。
トライアンドエラーをとにかくひたすらに繰り返すわけです。


これは長期に渡るので、そのための工夫が必要となります。
長期的な目標を考えて動くとか、毎日少しずつやるとか、そういった感じでしょうか。


負ける条件を潰すという意味で、先人達の失敗に学ぶのは非常に有効だと思います。
この本はソフトウェア開発に関する様々な失敗について書かれており、非常にためになりました。

アンチパターン―ソフトウェア危篤患者の救出

アンチパターン―ソフトウェア危篤患者の救出


また、こちらの本は長期的な視野で最終的に安定して勝つためのやり方などが書いてあり、非常に参考になります。

勝ち続ける意志力 (小学館101新書)

勝ち続ける意志力 (小学館101新書)



負けない工夫と、それをやり続けるための手法は今後も模索していきたいですね。
それでは。

最近良く聞くことについて

最近聞いた話で、一番心に残っているのは、
「技術者として一番大事にしなくてはいけないのは基礎である」
という話だ。
IT業界はとにかく流れが早く、新しい技術を学んで力にするその速度が重要となる。

新しい技術を素早く学ぶために必要なのは基礎だ。

なので、自分は今後3年以内に基礎の完成を目指して活動していきたい。
今年一年で、基礎としてどこまでの知識を持てばいいのかを見極めるつもりだ。

また、盤石にした基礎はメンテナンスをおろそかにすれば容易に脆くなる。
定期的な復習は必須だ。
復習のためには、要点を抑えたメモ書きなど、自分の中の系統立てた知識を書き記して、読み返せる必要がある。
このブログをそのように使えれば面白い。

学習した事を走り書きのように残して行こうと思う。

書き残すという事

思考を書き残す

思考を書き残すことはとても重要だ。
人間、一日のうちにかなりの量の思考をしているが、その思考は浅いところで止まってしまうことが多い。
その思考を掘り下げれば本人でも思いもしなかった妙案が思いつくかもしれないのにだ。


頭の中でただ考えるだけでは深いところまで考察することはできない。
思考は常に様々な妨害にさらされている。
最悪、せっかくの思考を掘り下げずに忘れてしまうかもしれない。
だから、その思考を忘れないように書き残しておくのだ。


思考を書き残しておけば、それを後から考察できる。
深い考察は自分の思考を豊かにする。
考察して、その過程も文章に起こすことで、文章力の訓練にもなる。


思考を書き残すことには多くのメリットがある。
だから思考を書き残そう。
このブログもそういうことに使ってみようと思う。