BLOG.QuelLENcode

RubyKaigi 2015 Day3

ちょっと日が空いてしまいましたが、先日に引き続いて、RubyKaigi の 3 日目について軽くまとめておきます。

Ruby Comiitters vs the World

cf. http://rubykaigi.org/2015/presentations/committers

Ruby コミッタの皆さんが、世界と戦うように見せかけて壇上でトークバトル(?) を繰り広げるというセッションでした。

Ruby を使っていて最近良く思うのは、動的な型システムって本当にいいのかな？という点です。 型推論が究極に賢くて、わざわざ型を書かなくても静的な型システムの恩恵を受けられるのがベストですが、 現実はなかなか難しい。

前に Matz さんが構想している Soft Typing では、そのへんがいい感じになるというウワサですが、 このセッションで進捗がないことが明らかになりました..

It's dangerous to GC alone. Take this!

cf. http://rubykaigi.org/2015/presentations/youngrw_CraigLehmann

先日に引き続き、IBM における OMR での GC テクノロジに関するお話でした。 ちょっとねむたくてよく覚えていないのですが、OMR の GC テクノロジを Ruby に適用してみたよ的な内容だったと思います。

Refinements - the Worst Feature You Ever Loved

cf. http://rubykaigi.org/2015/presentations/nusco

強力すぎるモンキーパッチを、よりお行儀よい形で置き換えることのできる refinements の 基本と使い方についてのお話でした。

refinements、あまり使ったことがなくて理解がフワフワしていたのですが、よく理解することができました。 さすがメタプログラミング Ruby の著者だけあって、説明がわかりやすかったです。

実装には、dynamically scoped refinement と lexical scope refinements があって、 クラスの継承関係があるとややこしみが増えてしまうので、実際には lexical のほうが採用されたそうです。

感覚的には lexical というよりも local と言うほうがしっくりくる感じがしたのですが、 顛末な問題なので気にしないことにしました。

Discussion on Thread between version 1.8.6 and 2.2.3

cf. http://rubykaigi.org/2015/presentations/emorima

Ruby の Thuread を 10000 スレッドでかつミッションクリティカルな環境で使ってみたよというお話でした。

途中で出てきたグラフに単位がなくて困惑しましたが、なんとか話を理解することができました。

Erlang などを使うという選択肢はなかったのですか？という問に、登壇者の方が 「ミッションクリティカルで実績のないものは使えません」とおっしゃったのには、Erlang 好きとしては、 ああ世間ではそういう評価なんだなーとちょっと悲しくなりました..

Plugin-based software design with Ruby and RubyGems

cf. http://rubykaigi.org/2015/presentations/frsyuki

プラグインアーキテクチャを持つ gem を設計するためのテクニカルなお話がメインでした。

プラグインアーキテクチャの概念から、徐々に内容に入っていく感じでわかりやすかったです。 あんなキレイな設計ができるようになりたい..

Request and Response

cf. http://rubykaigi.org/2015/presentations/tenderlove

生まれて初めて tenderlove さんを生で見たのですが、かわいい日本語で発表されていて度肝抜かれました。

比喩を用いた巧妙な表現で、Rails と Rack 周りが何をやっているのかをわかりやすく解説してくれました。 そしてお恥ずかしながら、HTTP2 がバイナリベースのプロトコルなのだと、ここで初めて知りました..

Actor, Thread and me

cf. http://rubykaigi.org/2015/presentations/seki

分散処理におけるアクターモデルと Ruby を絡めたお話でした。

アクターモデルは Erlang ではおなじみの概念で、登壇者の方の Queue と Thread で実装したアクターモデルは、 Thread を Process に置き換えると、Erlang のそれに似ているという印象でした。

そもそもですが、主に処理の並列化による高速化を狙う Thread と、リライアブルな分散処理を実現するための アクターモデルを同じ土俵で比較するのって、何か無理があるなーと思ったりもしました。

Keynote

cf. http://rubykaigi.org/2015/presentations/evanphx

Matz さんが Ruby 3 では 3 倍高速にするという目標を打ち出しましたが、では、それを実際にどうやって 実現していくのかの具体的な提案を述べた発表でした。

登壇者いわくいちばん手っ取り早く効果が出そうなのは JIT らしく、JavaScript の V8 の仕組みや Rubinius が LLVM IR を使っていたりすることに触れ、どうやったら速くなりそうか具体的に提案されていました。

おわりに

RubyKaigi 2015 Day2

昨日に引き続き、RubyKaigi の 2 日目に出席しました。 速報 & 自分用メモとしてザックリ内容をまとめます。

Keynote

cf. http://rubykaigi.org/2015/presentations/kosaki

@kosaki さんの発表です。

Day2 のスケジュールの開始時間を、Day1 と同様の 10:30 からと勘違いしていたため、聴くことができませんでした..

どうやら、カーネル開発のときに使われるデバッガを使いこなす的な内容だったようです（未確認）。

The history of testing framework in Ruby

cf. http://rubykaigi.org/2015/presentations/kou

@ktou さんの発表です。

前々からおさらいしたいと思っていた、Ruby におけるテストフレームワークの変遷について、 順を追っていい感じに聴ける発表でした。

最近ちょっと RSpec に辟易しているフシがあって、一周回って test-unit や minitest が大切にしている、 「Rubyらしく書ける」というコンセプトに惹かれるものがあります。

次に自分で何かを書くときは、test-unit か minitest を使ってみたいと思います。

Turbo Rails with Rust

@@wycats さんの発表です。

cf. http://rubykaigi.org/2015/presentations/wycats_chancancode

Rust でネイティブの Ruby 用 extension を書くためのノウハウが詰まった発表で、かなりためになりました。

Ruby 用に高速なライブラリを書きたいけど、C はあんまり書きたくない。 しかも、わたしは最近 Rust をよく触っていて Rust が推し言語なのでいっそう惹かれるものがありました。

libcruby という Rust 用のライブラリを使うと、Ruby から Rust で書いた関数を呼ぶためのグルーコードを肩代わりしてくれるので、 割と手軽にネイティブ extension が書けそうでした。

Ruby も Rust も大好きなので、Rust で何か gem を作ってみたいなーと思ったり。

Data Analytics Service Company and Its Ruby Usage

cf. http://rubykaigi.org/2015/presentations/tagomoris

@tagomoris さんの発表です。

Treasure Data での顧客のためのビッグデータ処理を、どのようにうまくスケジューリングして ワーカを動かしているかという発表でした。

システムは基本的に Ruby で構築されているそうで、一部 jruby や Java を使って実装しているとのこと。

Ruby を採用しているのは、クエリを組み立てるためのコードをメタプログラミングでうまく書け、 かつ RSpec を使うことでテストしやすいからだそうです。

The future of Ruby is in motion!

@lrz さんの発表です。

cf. http://rubykaigi.org/2015/presentations/lrz

Ruby Motionの話で、登壇者いわく、昔から Ruby が好きで、かつ Apple の OS が好きなのが昂じて、 Ruby Motion に関わっているのだそう。

Ruby のコードを iOS アプリ化するために Ruby の AST を LLVM IR に落としているそうで、 ここでも LLVM 大活躍だなーと思いました。

デモでは、Flappy Sushi という Flappy Bird のクローンを作り、 ひとつの Ruby コードベースが iPhone エミュレータでも Apple TV でも動くというライブコーディングによる デモを披露してくれました。

アプリを作ってみたいなーとぼんやり思っていたこともあって Swift を学ぶかと思っていたのですが、 Ruby Motion が思ってたよりもマトモ(失礼!)なので、選択肢として十分アリな気がします。

Ruby meets Go

@＿mmasaki さんの発表です。

cf. http://rubykaigi.org/2015/presentations/mmasaki

Rust で extension を書く話と打って変わって、こちらは golang で Ruby を拡張する、というお話でした。

c-shared とよばれる golang から C の関数を呼ぶための仕組みを応用して、Ruby のネイティブ extension が作れるそうです。

見た感じ、Rust で作るよりもつらそうでした。 常に golang の世界、C の世界、Ruby の世界でのそれぞれでのデータの持ち方について気を配らなくてはならず、 ストレス無しに書くのは大変そうでした。

Rhebok, High Performance Rack Handler

@kazeburo さんの発表です。

cf. http://rubykaigi.org/2015/presentations/kazeburo

unicorn よりも高速をうたう Rack Handler である Rhebok についての発表でした。

Rack Handler を実装するための基礎から徐々に Rhebok のつくりに入っていくという流れで、非常にわかりやすかったです。 ふんわりとしていた Rack についての理解が深まってためになりました。

Pragmatic Testing of Ruby Core

@hsbt さんの発表です。

cf. http://rubykaigi.org/2015/presentations/hsbt

どのように OSS に貢献したらよいのかという問いから入り、それはテストコードまわりだとやりやすいよ、 というところから話を展開していました。

メインの内容は Ruby のテスト周りのコードの解説でした。 Ruby Core のテストは、実際に Ruby に貢献しようと思ったら避けて通れない道なので、そのときには参考にしようと思いました。

まとめ

最近 Rust が非常にお気に入りなので、Rust でネイティブエクステンションを書く話が刺さりました。

RubyKaigi 2015 Day1

前々から一度行きたいと思っていた、最大規模の Ruby の祭典、RubyKaigi 2015 に行ってきました。 2015-12-11(Fri.)〜2015-12-13(Sun.) の 3 日間構成で、東京の汐留で開催されています。

ザックリ速報として、発表内容を以下にまとめてみました。

Keynote

cf. http://rubykaigi.org/2015/presentations/matz

Ruby のパパ、Matz さんの発表です。

プログラマの三代美徳から始まり、Ruby を作ったきっかけとその発展について軽く触れ、 Ruby 2.3.0 の新機能をザックリとまとめていました。

最終的に Ruby 3 の展望について語っており、Ruby 3 では Ruby 2.0 と比較して 3 倍パフォーマンスを良くするとのことでした。 不可能ではなさそうですが、かなり大変そうだなー.. という印象が。

個人的には Streem の誕生秘話が面白くて、なんとなく実験的に作ってひっそり GitHub に置いていたものが、 いつの間にか情報が拡散されて提案やプルリクがガンガンくるようになったとのこと。

すごい人がおもしろいモノを作ってると、自然に人が集まってきて OSS が発展していくのは、OSS ならではの面白さですね。

Compiling Ruby Scripts

cf. http://rubykaigi.org/2015/presentations/ko1

@ko1 さんの発表です。

Rubyのコンパイル済みコードをシリアライズ・デシリアライズするものを作った、という発表でした。 「Rubyのしくみ」という本を読んでいたおかげで、内容はすんなり理解できました。

聴きながらどこで役に立つかなーと思っていたのですが、@ko1 さんの言うように、 ライブラリをインストールするときにコンパイルしてしまって、ロードにかかるオーバーヘッドを軽減するという用途が 王道なのかなと思いました。

Experiments in sharing Java VM technology with CRuby

cf. http://rubykaigi.org/2015/presentations/MattStudies

@MattStudies さんの発表です。

IBM は最近 Ruby に注目しているようで、Java VM で使っている JIT コンパイラなどの最適化テクニックを cruby にがんばって応用してみたという話でした。

どうやら LLVM と競合するようなものを開発しているらしく、それなら OSS になっている LLVM のほうがこなれてるし良いのでは.. という感想。 ちなみに、「なぜ OSS にしないのか」という問に対して、登壇者いわく「それは IBM だからです HAHAHA」とのことでした。なるほど..

mruby on the minimal embedded resource

cf. http://rubykaigi.org/2015/presentations/shotantan

@shotantan さんの発表です。

mruby が載っていて、Ruby のコードをシュッと実行できるステキな組み込みボードのデモなどが中心でした。

組み込み分野でも、やっぱり C ですべてを書くのはしんどいとのこと。 mruby はそれなりに組み込み分野でも実用的に使えるそうですが、RAM の消費量の問題で、 ROM にメモリを swap するなりして工夫しないといけないそうです。

mruby の成果が今流行の IoT などに応用できうるので、温かく動向を見守っていきたいと思います。

Fast Metaprogramming with Truffle

cf. http://rubykaigi.org/2015/presentations/nirvdrum

@nirvdrum さんの発表です。

jruby と Truffle という仕組みの組み合わせで、メタプログラミングによって生えたメソッドのパフォーマンスが爆上がりしたよ、というのが 話の中心でした。

個人的な感想としては、「カッコいいー！でも、jruby なんでしょう？」というところに尽きました.. あまり jruby に良い思い出がないので..

High Performance Template Engine: Guide to optimize your Ruby code

cf. http://rubykaigi.org/2015/presentations/eagletmt_k0kubun

@eagletmt さんと @k0kubun さんの発表です。

若さにあふれる発表で、パフォーマンス計測・ベンチマークの基本をサッとなぞって、 Faml や Hamlit がどういう風に生まれたのか、そして実装されているのかというテクニカルな話で面白かったです。

こくぶんさんのドギツイ Haml や Slim への dis が入っていましたが、わたし個人としては Syntax 含めて Slim が好みです。 だって % 打つのめんどくさいんだもん..

TRICK 2015: The second Transcendental Ruby Imbroglio Contest for RubyKaigi

cf. http://rubykaigi.org/2015/presentations/trick

TRICK というのは、Ruby で書くヘンなプログラム選手権で、2 回目の開催らしいです。 このセッションは、TRICK の受賞者のコードを鑑賞しましょうという内容でした。

ワンライナーや特徴的な見た目で書かれたキモいプログラムは圧巻で、創作意欲を刺激されました。

セッションが終わってから

すべてのセッションが終わってからは特に予定がなかったのですが、関西にいたころの前職のエンジニアの方にお誘いただき、 ちょっとした飲み会に出ました。

2015年9月いっぱいで、奈良先端科学技術大学院大学、いわゆるNAISTの情報科学研究科の博士後期課程を中退し、就職することにしました。 大学を飛び出して新しい環境で1ヶ月がたち、いろいろと思うところがあったので、ここに書き留めておきたいと思います。

なぜ大学を飛び出したのか

なにか大きな理由があって辞めたのではありません。 それは小さいことの積み重ねで、かつ幸か不幸か、大学を辞めるのに大きな障害がなかったからです。 その理由や思うところをつらつらと書いていきたいと思います。

精神的にまいった

まず一つ目の理由、わたしは大学院での2年半で、精神的にまいってしまいました。

うつ病で何も手につかないほど、とまではいきませんでしたが、その手前くらいまではいってたと思います。 あまり外には出さないようにしているつもりでしたが、論文執筆で忙しかったM2の去年8〜10月頃は、外から見てもわかるくらいには疲弊していたようです。

ずぶずぶの人間関係が面倒くさかったので、適度に距離を置く人付き合いをしていた結果、こんなにもセンシティブな内容を相談できる相手はいませんでした。

そのような生活を送っていたので、ゆっくり、ゆっくりと、心身ともに疲弊していきました。

アカデミアの文化が受け入れられない

大学院を辞めようと考え始めるまでは、漠然と大学の教授になることを考えていました。 ただ、それと同時に、手を動かしてソフトウェアを作り上げたり、UNIXやプログラミング言語を中心とした、ハッカーカルチャーにも傾倒していました。

大学院に通い始めた頃は、アカデミアとハッカーカルチャーは、ひとりの人間の中に共存できると信じていました。 しかし、現実は違いました。 アカデミアの文化とハッカーの文化の間には、大きな溝があるのです。

まず、大きな傾向として、アカデミア文化は上には服従が基本スタイルの縦割り社会、ハッカー文化は議論がすべてオープンでフラットな社会です。 研究室や分野によって差はあれど、アカデミア文化よりもハッカー文化のほうがフラットなのは間違いないでしょう。 わたしにとって、これは受け入れがたいことでした。

以前、論文執筆の効率化のためにGitを使うことを教授に提言してみたのですが、煮え切らない回答で、結局メールでの非効率なやりとりに終始していました。 この例からもわかるように、基本的に上がNOといえばそれでオシマイです。 いい方向に環境をコントロールできないことは、わたしにとって大きなストレスとなっていました。

博士後期課程に進学したら研究テーマを変えるという約束も、有耶無耶のうちになかったことになり、モチベーションは下落の一途をたどりました。

対して、学生の頃のバイト先のIT系の会社では、アルバイトという身分でありながらも、 それなりに責任のある仕事を任されていました。 改善すべきことがあれば、それを提言することを良しとする文化がありました。 ある程度の上限関係はあれど、ソフトウェア開発の議論においては皆がフラットに意見をたたかわせられました。

上の人間に直接言うのが怖いから、ひたすらに飲み会で陰湿に陰口を叩くような文化に、同調するフリをしながらも心底嫌気がさしていました。

最新の技術動向について気軽に話せる人がいない

わたしも一応、ハッカー文化に傾倒するエンジニアのはしくれですから、最近の技術動向に敏感です。 新しいプログラミング言語、新しいフレームワーク、Linuxまわりのミドルウェアの発展、どれもこれも大好物です。

大学院という場所は、そこにこんなにも楽しい話題があるのに、それについて会話できる人が少ないのです。

情報系の学科なので、時にはプログラミングする必要がありますし、教員や学生は概して聡明なので実装力もあります。 つまり、日々コードを書いている人間はいるのですが..

ただ、それだけなのです。

はたして、ErlangやRust、golangの名前を出してピンとくる学生が何人いることでしょうか。 わたしの所属していた研究室では、ひとつ下のただ一人の友人を除いて、ハッカー的な思考を持つ人はいませんでした。 研究室の飲み会などの集まりの場でも、色恋沙汰などの下世話な話に花が咲いたり陰口を言ったり、内心うんざりするような会が多かったです。

研究職が向いていない

この2年半でハッキリと分かったことは、わたしには研究職が向いていないということでした。 大学院を辞める前までは、それを認めるのがイヤだったので意地になっていましたが、M2になったころから薄々気づき始めていたことでした。 いろんな教授や教員を目にして、自分があのようになっている、というビジョンが全く見えないのです。

ただ、コンピュータサイエンス自体は好きなので、結局のところアプローチが逆だったのだと考えています。 大学院への入学当初は、大学教員になって趣味としてオープンソースにコミットすることを考えていました。 それよりも、プロのエンジニアであることを第一にして、趣味でコンピュータサイエンスを学ぶほうが自分に合っているのだと。

逆求人イベント

逆求人イベント。これがわたしの退学への決意を確たるものにした、最後の決定打でした。

サポーターズというサイトで、同じ研究室のひとつ下の友人 （先ほども話にあがった、同じ研究室で、唯一技術動向の話ができる良き友人です）に紹介してもらいました。

そこで、いろんなIT企業の方と1on1で面談できる機会があり、将来のキャリアを真剣に考えるきっかけになりました。

この時点で研究職に対する希望は薄れていたので、博士後期課程を修了するにしても、IT系の企業に就職するつもりでした。 そして、ここで知ったのは、博士号を持っていたとしても、それが初任給に寄与しない、寄与したとしても微々たるものだという現実でした。 つまり、IT系の企業に就職したときの収入という面だけで見れば、博士後期課程で消費する2〜3年というのは、あまりにも割に合わないものなのです。

逆求人イベントを中心とした就活(のようなもの)をしているうちに、縁があって高専時代の後輩に会いました。 彼は前線でバリバリと活躍するエンジニアで、話を聞けば聞くほど、2年3年という時間を研究に費やすことに焦りを感じ始めました。 わたしがのらくらとモラトリアムに甘んじている間に、彼らはどんどんエンジニアとしてたくましく育ち、自分の成果を世に問うているのです。

わたしの腹は決まりました。大学院を辞めて、社会人として、本気でエンジニアリング一本にしぼろうと決意しました。

大学院を辞めるにあたって

わたしがスッパリと大学院を辞めることができたのも、本当に運がよかったとしたいいようがないです。

おかげさまで、結果的に憧れだった株式会社クックパッドに新卒として内定をいただき、かつ10月からアルバイトとして働けることになりました。 これで、大学院を辞めたあとの食いぶちをつなぐことができました。

また、昔からお金のかかる趣味を持っていないこともあり、引っ越しの費用や、新居とそれにかかる諸費用、 家具の購入資金など、それらをまかなえるだけの貯金がありました。

学費も高専の頃から親に一銭も出させていないこともあり、それを理由に辞めることを止められることもありませんでした。

クックパッドで1ヶ月働いてみて

なによりも、晴れやかな気分で毎日を送れることに感謝しています。 コンシューマ向けのサービス開発が初めてということもあり、仕事は決して楽ではありません。 しかしながら、研究室で半分腐りながらゾンビのような生活していた頃よりも、イキイキとした自分を感じられています。

また、毎週ちゃんと土日に休みなのもありがたいです。 大学院にいたころは、平日も土日祝日も分け隔てなく、研究したり生きるために仕事をしたりしていて、週休0日の週もザラでしたので。

ただし、この選択が本当に良かったのかどうかはまだわかりません。 いつか博士後期課程を修了していたほうがよかった、と後悔することがあるかもしれません。 ただし、これはわたしが考えに考えて選んだ道です。 そして、我慢して2年3年と学生を続けていても、それは別の後悔を生むことになると思います。

　Ariete 1.0.3がリリースされました。このリリースは、minitest、test-unitなど、RSpec以外で利用できない問題を修正するものです。

　RubyGems.orgにもアップロードされているので、bundle updateなどでアップデートすることも可能です。

アーカイブのダウンロード

https://github.com/mozamimy/ariete/releases/tag/1.0.3

ソースコード

https://github.com/mozamimy/ariete/tree/1.0.3

修正の内容

　取り込んだ主なPRは以下になります。

Fix NameError in case of using test-unit by stk132 · Pull Request #3 · mozamimy/ariete

Update Gemfile.lock. by mozamimy · Pull Request #6 · mozamimy/ariete

　現在、Ariete内ではRSpecのマッチャー🍵を拡張するコードをベタ書きしています。そのため、RSpecを使わない環境でもRSpecを入れないと動かないという大問題があります。#3のPRは、この問題に対するホットフィックスになります。@stk132さんありがとう!🐰

　この問題を避けるため、ariete gemにはArieteのコア部分だけを含め、RSpecを拡張するコードはariete-rspec gemを新たに作って分離しようと考えています。余裕があれば、ariete-minitestやariete-test-unitも作る予定です。

はじめに

この記事は、DeNA社のインターンシップである、StuDev 2015に 参加してきた顛末を、自分のための記録および、今後のキャリアについて考える学生のために、ゆる〜〜く書き綴るものです。

最終日の懇親会にて、インターンシップの内容について公表してもOKとのことでしたので、 内容も含めてなるべく詳細に書いていきたいと思います。 ちょっと長くなるかもしれませんが、興味があれば読んでいただければ幸いです😆

そして、この場をお借りして、チームメンバーおよびメンターの皆様、そして快適なハッカソンを支えてくださった、 DeNA社の関係者の皆様に深く御礼申し上げます。本当にありがとうございました。

なぜ、DeNA社なのか？

日本に数あるIT企業の中から、インターンシップ先のひとつとして、わたしはDeNA社を選びました。 理由はこんな感じ。

数あるIT企業の中でも大企業であること

有名な企業だしなんとなくスゴそう

優勝したらシリコンバレーツアー(!)が待ってる

(3日間のハッカソンで10万円(!)もらえる)

わたしは現在、学生であるかたわら、大阪にある受託開発やRedmineプラグインの販売を生業とする会社でアルバイトをしています。 仕事を始めてからそろそろ2年半ぐらいになろうかというところで、アルバイトという身分でありながらも、古参メンバーとして 責任を帯びた仕事を任されていたりします。こぢんまりとした会社で、少数精鋭のメンバーで開発にあたっています。

こういう環境で働いていると、自然と知りたい欲求がわき出てくるのですよ。

「先進的な大企業で働くエンジニアって、どういう仕事をしているんだろう？」 「そういう企業ではどんな人がいて、どういうふうに開発しているんだろう？」 「コンシューマ向けにサービスを出してる会社ってどんな感じなんだろう？」

今の会社に不満があるとかそういうのではなくて、単純な興味です。 将来どこかで就職することになるのだから、学生という特権を使っていろいろな環境を見ておいたほうがいい、そういう考えです。

最後の2つは、動機としては少し邪（ヨコシマ）かもしれませんが、キッチリ成果を出してキッチリ報酬を頂けるなら、 それにこしたことはないですよね。

というわけで、迷えるウサギ🐰はStuDev 2015に応募したのでした。

逆求人イベント

ちなみに、DeNA社のインターンシップを知ったきっかけは、サポーターズというサイトでの 逆求人イベントでした。 宣伝っぽくなっちゃいますが、将来IT系のエンジニアを志望するなら、登録しておいて損はないサイトだと思います。

選考

インターンシップの選考にはいろいろなパターンがあるようですが、DeNA社のStuDevに限っては、面接で全て見るといった感じでした。

選考だけで4回程渋谷ヒカリエに足を運びました。 蛇足ですが、さすがに4回もヒカリエに行くと、駅からヒカリエまで雨に濡れずに行く方法覚えちゃうよね！ 雨に濡れない道を知るまで、どうしても渋谷駅から外に出てしまって、悲しい思いをしていました😭

この手の面接の経験がなかったので、特に1回目はものすごく緊張して、アッアッてなっていたように思います。

が！

いざフタを開けてみると、面接というか、雑談に近かったように思います。 曲がりなりにも2年以上現場にいると、学生といえども酸いも甘いも噛み分けるという謎の(?)経験が積み重なっていきます。 いわゆる現場のエンジニアあるあるな話で盛り上がったりして、 「学生というより、現場エンジニアと話しているようだ」と評されたりしました。

そんなこんなで、めでたく面接を通過し、あとは当日を待つばかりとなったわけです。

お題と球場見学ツアー

StuDev 2015のお題ですが、横浜DeNAベイスターズの球場、通称ハマスタに来場するお客さんを増やすサービスを作ろう！ とのことでした。 初めにこのお題を聞いたとき、正直なところ、どうしよう！長らく球場に行ってないから、 どんなもの作ればいいか検討つかないよ😖という感じでした。

おそらくそれもDeNA社内では織り込み済みだったようで、みんなでハマスタでベイスターズを応援しようという イベントを企画していただきました。 問題点を探すために参加した企画のはずが、気づいたらものすごくアツくなってベイスターズを応援しているわたしがいました。 試合は負けてしまったけれども..

蛇足ですが、DB.スターマンくんとDB.キララちゃんかわいいよかわいい。

球場のぬいぐるみ着ておどる仕事したい。

— Moza USANE (@Mozamimy) September 1, 2015

ハッカソン、始動！

制限時間は3日間、説明や資料作成、最終発表会なども加味すると、実質2日間あったかどうかぐらいです。 3日間で企画をして、プロトタイピングまで持っていきます。 そのため、3日間フルパワーで100%全力コミットでした💪

チームメンバーは@naonathanさんと@koooootakeさんでした。 ふたりとも、本当に頭が上がらないくらいイケてるエンジニアでした。 @naonathanさんはRailsでバリバリWebアプリ書けるし、@koooootakeさんはすごくキレイなiOSアプリを書けるし、 ちゃんとサービスとして形になったのも、本当に彼らのおかげです。

ホテルや作業中の飲み物、おやつ、食事もちゃんと用意されていて、バッチリ開発に集中できる環境でした。 🍖叙々苑焼肉弁当おいしいよ叙々苑焼肉弁当🍖

立ち回り

私は主にサーバのセットアップとRailsのサーバサイドを担当しました。 ちょっと残念だったのは、与えられたサーバがAmazon Linuxだったことです。 RHEL系にありがちなミドルウェアのバージョンが古い、ひどければリポジトリにすら用意されていない問題のおかげで、 肝心のアプリの実装にタッチできる時間が減ってしまったのが悔やまれます。 自分でAMIを選択できていれば、無難にArch LinuxかUbuntuあたりで構築していたと思います。 もっとプロビジョニング力を上げないと...

特に今回作ったサービスは、ミドルウェアとしてffmpegや Sound eXchangeといった、ナウでヤングなソフトウェアに依存するものだったので、 自力でビルドしたりなかなかに骨が折れました。

そして徹夜

なにせ3日間という期間なので、当たり前のように徹夜でした..! これが地味に身体にこたえました。齢24にもなると、身体の節々にガタがきて徹夜が体力的にきつくなるものです。 2日目は、メンターの方の差し入れとしていただいたRed Bullを片手に、朝の5時頃まで作業してました。

ただ、このような苦難を乗り越えたからこそ、形になったときの感動、チームの一体感がマシマシになったのだろうなーと 今思います。

できた

そんなこんなで、できました🎉

サービス名はズバリDBCheers！ベイスターズを表すプレフィックスであるDBと、 応援という意味の英単語、Cheerを組み合わせた、至極素直なネーミングです。

アプリのコンセプトは「横浜DeNAベイスターズ 大応援共有サービス」。 球場で撮影したいくつかの応援動画を、球場備え付けの大ディスプレイに同時再生するというものです。 上映される動画の選出には、応援の声の大きさに重みを付けてランダムに抽出、 特に頑張って大きい声で応援している動画は大きなスペースを割いて表示されます。 いくつもの動画が同時再生される様は圧巻で、ワチャワチャ感が出てとても楽しい感じに仕上がったと自負しています。

また、大ディスプレイで再生されている様子を似せたページを、インターネットで共有することで 球場に来たことがない人も取り込もうという工夫も加えています。

肖像権や著作権などの、権利的な関係でスクリーンショットをアップできないのが残念です😣

得られた知見など

1. Amazon Linuxしんどい

見出しのとおりです。Amazon Linuxが、というよりも、RHEL系のディストリで Railsやら、その他先進的なミドルウェアを揃えるのはそこそこしんどいです。

2. ちゃんとスケールするようにつくる

さすがに使える時間が3日間ということで、機能の実装でいっぱいいっぱいでした。 ただ、ちゃんとサービスとして動かすことも考えてて、 ちゃんとitamaeを使ってサーバを増やして スケールできる余地を残した作りにしてました。 あまり表に見える部分ではないのでインパクトは薄いのですが..

3. iOSでカメラで撮った映像を加工するのはしんどい

企画当時、iOSでとった映像を、端末でクロップしたりリサイズしたりするのは てっきり簡単だと思っていました。仮にそれができなくとも、撮影段階で映像のサイズをいじることぐらい シュッとできるものだと思っていたのですが..

@koooootakeさんいわく、なかなか難しい注文だったようでした。 ただ、結果的にはできたので、ノウハウとして蓄積するに値する知見を得られたと思います。

最終選考

ドキドキの最終選考。結果的には優勝はかないませんでしたが、審査員の方々の講評で名前が挙がる くらいにはウケが良かったようです。メンターの方も「惜しかったよ」とおっしゃっていました。

さいごに

本当に短く感じた3日間ですが、とびっきりの濃い時間を過ごさせていただきました。 DeNA社という大企業で働くエンジニアの皆様とお話する絶好の機会になったし、 全国のイケてるエンジニアと知り合うよいきっかけとなりました。

photo credit: my textbook via photopin (license)

　OracleとGoogleがJavaのAPIの著作権を巡って係争中でしたが、とうとう最高裁の判決が下りたようです（Supreme Court denies Google request in Java infringement case | Computerworld）。

　このネタ、2年ほど前からウォッチしていました。ちなみに私は、APIに対する著作権は認めない派でした。なぜならば、著作権保護の対象になれば、あるプログラミング言語Xと、Xに付属する標準ライブラリのオープンな実装ができなくなってしまうからです。

　Googleはここで降りずに、「確かに著作権保護の対象かもしれないが、フェアユースである」という論法に切り替えて、別の案件として審議を開始するようです。

　もしフェアユースであるであることが認められるならば、それが現実的な落としどころとして妥当そうです。

　私は、「ハッカー文化の発展が妨げられるから」という理由で、著作権を認めないのが妥当だと考えていました。実際のところ、APIの設計は深遠な問題で、そこにかかる労力とスキルを考えれば、著作権を認めるべきなのかもしれません。その上で、「フェアユースである」という結論に至れば、最も妥当なのかなと思うわけです。

　とにもかくにも、これで「APIに著作権を認める」という判例ができてしまったので、OSSプロジェクトにも少なからず影響はあるでしょう。OpenJDKはOracle傘下なので大丈夫でしょうが、仮にOpenJDKからフォークしたJavaの処理系とライブラリ群を作って訴えられたら、負ける可能性はグッと高まるでしょう。

ハッシュですら難しい

JavaScriptは本当にエンジニア泣かせなもので、JavaScriptの実装の数があまりにも多すぎて、 多くのブラウザの間で互換性をとるのが大変です。

たとえば、（たかが）ハッシュひとつとっても、罠にハマることがあります。 たとえば以下のコード、FirefoxやChromiumで、エラーも警告も出ずに動いてしまいます。

正しくはこう。

何が悪いのかというと、defaultという予約語を、ハッシュのキーの名前に使ってしまっているのです。 下のコードのように、クォートで囲んで文字列にしてしまえばvalidです。

実は、IE8は上のコードを受け付けません。 「あ〜、またIE8か〜」と思ったのですが、実際のところはECMAScriptの仕様としてクォートが必要なところを、 FirefoxやChromiumがおせっかいをして動いているだけだったのです。

とはいえ、どうにも納得がいかなかったので、ECMAScriptの仕様を拾い読みしてみました。

ECMAScriptの仕様を読んでみる

IE8が登場したのは2009年3月。IE8はECMAScriptのMicrosoftの実装であるJScript 5.8に対応しているそうで、 JScript 5.8はECMAScript 3rd Editionがベースになっているらしい。

というわけで、ECMA-262 3rd Editionの仕様書を見てみましょう。

Microsoft Word - Ecma-262.doc - ECMA-262, 3rd edition, December 1999.pdf

まず4ページ目を見てみましょう。 我々が「連想配列」だとか「ハッシュ」だとか言っているモノは、仕様書の中ではObjectと記述されています。 Objectは、primitive value、object、もしくはfunctionを含むプロパティの順序なし集合である、と。

4.3.3 Object An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method.

ハッシュがObjectであることがわかったので、Objectのシンタックスを見ていくことにしましょう。 41ページ目から、形式的に書かれています。

ObjectLiteral : {} { PropertyNameAndValueList }

PropertyNameAndValueList : PropertyName : AssignmentExpression PropertyNameAndValueList , PropertyName : AssignmentExpression

PropertyName : Identifier StringLiteral NumericLiteral

ObjectLiteralは、ただの{}か、{}の中にPropertyNameAndValueListが入っています。

PropertyNameAndValueListは再帰的に定義されていて、要はプロパティ名:式が、 1個ないし複数個カンマで区切られて並べられている、という意味になります。

問題のPropertyNameは、IdentifierかStringLiteralかNumericLiteralのどれか。 StringLiteralは文字列リテラル、NumericLiteralは数値リテラルなので、 ここで問題になるのはIdentifierです。

Identifierの定義は、9ページあたりにあります。

Identifier :: IdentifierName but not ReservedWord

ここまで追えば十分でしょう。ハッシュのプロパティ名にはdefaultのような予約語が使えないのです！

ちなみに、ECMAScript 5th Editionの仕様も確認しましたが、いわゆるケツカンマの定義が増えているだけで、 3rdと同じく予約語は使えないことになっています。

ブラウザのあるべき姿

さて、ここでひとつ問題提起をしましょう。 ブラウザのあるべき姿として、どちらが正しいのか、という問題です。

仕様にそぐわないスクリプトは厳密に動かさないようにすべきか。 それとも、適当に解釈して、仕様にそぐわなくとも動かせるなら動いたほうがよいのか。

先日、第67回 Ruby関西 勉強会 - Ruby関西 | Doorkeeperに行ってきました。 ささたつ(@sasata299)さんの発表を聞いていて、気になった本がコレ。

O'Reilly Japan - Team Geek

Googleの中の人が著者。 エンジニア集団がチームとしてソフトウェアを開発するときに役立つ読み物です。 リーダ的な立ち回りをする人も、リーダの下で開発をする人も読者の対象です。 絶妙な翻訳による軽妙な語り口で、飽きることなく最後までスイスイ読めました。

全てはHRT（ハート）という言葉に集約されています。 謙虚(Humility)・尊敬(Respect)・信頼(Trust)の略語で、共同作業において忘れてはいけない姿勢として挙げられています。

読んでて気になった部分がひとつあります。 ユーザも人間であるという前置きがあり、その上でHRTを実践して、6.2.6節では 面倒でもユーザにとって使いやすくしよう、と述べられています。 これが、YAGNIの原則から外れる場合があるのです。 YAGNIは、いわゆるYou ain't gonna need it.という原則で、いずれ必要にはならないという格言です。

Webエンジニアとしての経験則ですが、ウェブアプリケーションでユーザの利便性を上げるための小さな改良は、 たいてい大きなコストを伴います。 古いIEをサポートしないといけない場合なんて、暴れ牛に必死に掴まって乗りこなすようなものです。

そして、その小さな改良は、いずれ必要にならない(かもしれない)わけです。 リソースと納期が無限ならば、できるところまでやるべきです。 しかし、現実にはリソースも納期も有限です。

そう考えると、リソースと利便性のバランスを保ちながら、その利得を最大化できるようなジャッジを 感覚的にかつ瞬時にやってのけるエンジニアは、シックスセンスの持ち主だと思うわけです。

photo credit: Start Continue - 80/365 via photopin (license)

　いろいろなコミュニティに所属していて、多くのプロジェクトに関わっていると、 自分の書いたソースコードがいろいろな場所に散らばることになります。

　私の場合、趣味の一環でオープンソースプロジェクトに提供したコード、仕事で作ったプロプライエタリなコード、 大学の研究の一環で作成したデモプログラムなどなど。 いろいろなリポジトリに私の書いたコードが分散しています。

　そのような背景があり、最近思うのは、「私の書いたコードは、果たして誰のものなのか？」という小さな疑問です。 この問題を言い換えると、オープンにしていいコードと、できないコードの線引きです。

　仕事で書いているコードは本当にややこしい。 業務時間中に得られた知見をブログに書こうと思っても、コードをそのままコピーすることは当然ご法度。 なので、紹介したいメタな知見だけを抽出して、コードも抽出・編集することになります。 そのときに、どこまで書いても良いのかの線引きをするわけです。

　結局、私の中での線引きは、ノウハウはエンジニアに、コードは会社に所属している、を基準にしています。 ブログやオープンなコードを書くときは、知識が完全に私自身のものになっているならば、 業務時間中に編み出したノウハウを使っても良い、ということにしています。

　もちろん、業務で書いたコードをコピペしたりはしません。 しかしながら、デザインパターンがあるように、そのノウハウかを基にしたコードは、 一定のパターンとして似てしまうことはあります。

photo credit: Digging via photopin (license)

ターミナルで作業をしていると、カレントディレクトリ以下のファイルをワイルドカードで絞り込んで、 再帰的に全文検索したい場合があります。

そんなときにつかえるちょっと便利なコマンド。.bashrcにでも書いておきましょう。 ftsはFull Text Searchの略です。全文検索。

$ fts "*.rb" "alice"

photo credit: Broken Bus Stop via photopin (license)

Railsでアプリを作っていると、IPアドレスやMACアドレスのバリデーションをしたくなることがあります。 SQLサーバには、IPアドレスやMACアドレスに特化した型はないので、stringで保持してRails側のバリデーションで 整合性を取る必要があります。 そんな場合の、(たぶん)ベストプラクティス。

IPアドレスのバリデーションには、RubyのリゾルバライブラリであるResolvクラスを使うのが良いみたい。 Resolv::IPv6::Regexを使えば、IPv6のバリデーションもできる。

MACアドレスのバリデーションには、Resolv::IPv4::Regexのような便利なものはないので、 正規表現をベタ書きで対処。 システムによっては、デリミタをコロンまたはハイフンのみに統一したい場合もあると思います。 その場合は、正規表現中の-:をコロンのみか、ハイフンのみにすると良いです。

ちなみにどちらも空文字列は許容しないので、もし空文字列は許すならば、 allow_blankを仕込む必要があります。

参考

regex - Rails 3: Validate IP String - Stack Overflow

Redmineでプラグインを開発するときは、Redmine（というよりRails）の流儀に合わせて、 minitest+fixturesの組み合わせでテストを書くことになると思います。

Redmine本体にもテスト用のfixturesがあるものの、プラグインの機能を確かめるためには、 プラグインに特化したテストデータを用意したいものです。 ただし、Redmineのコードを隅々まで知らない状態で、手でペチペチとYAMLファイルを書いていくのは そこそこしんどい作業です。

そこで使えるのが、extract_fixturesというrakeタスクです。

うっかりそのままbundle exec rake extract_fixturesなんてしてしまうと、 10行目を見るとわかるように、Railsのルートディレクトリの直下にYAMLファイルが散らかるので注意。

生成されたfixturesをどこに置くか問題ですが、私は以下のようにしています。

Redmineにもともと入っているfixturesを、(Railsのルート)/tmpに退避する

extract_fixtures.rakeの10行目のファイルパス指定部分を、#{Rails.root}/plugins/(プラグイン名)/test/fixtures/#{table_name}.ymlに変更する

$ bundle exec rake extract_fixtures

(Railsのルート)/test/fixturesにシンボリックリンクを貼る

おいしい！

これで、プラグインに特化したfixturesを使ってテストを書くことができます。

本当は、プラグインのテストを走らせた時に、(Railsのルート)/plugins/(プラグイン名)/test/fixtures以下の YAMLファイルを読み込んでくれると楽なのですが...

(photo credit: フォクすけ via photopin (license))

vimperator-clearly.js 0.0.3リリース

vimperator-clearly.js 0.0.3をリリースしました。 変更点は以下の通りです。

プラグイン読み込み時の不具合修正

vimppmのプラグインマナーに追従

最新版はmasterブランチから、 0.0.3はv0.0.3タグからダウンロードできます。

vimppmなるものを知る

GitHubのアクティビティを眺めていたら、vimperator-clearlyがフォークされているのに気づきました。 @konfooさんが、vimppmなるもので使えるように、 vimperator-clearly.jsに修正を加えてくれていました。 特にプルリクがきていたわけではないのですが、良い修正だと思ったので取り込みました。

photo credit: colorful bleeding via photopin cc

あけましておめでとうございます∩_∩" こんにちは、2015 年です。 心機一転するためにも、昨年の振り返りと今年の目標を掲げたいと思います。

全体的に

とにかく、ストイックさが足りなかった年だったと思います。 何もしていないわけではないけれど、今振り返ると、なんだか密度が低かったような感じ。 先手先手で物事に取り組めなかったからかなぁ.. と思っています。

2015 年は、とにかくストイックに。 だらけたい欲を断ち切って、遊ぶときはしっかり遊び、作業するときは集中して作業するようにしたいと思います。

学業

なんとか国際学会の査読付き論文が受理されたので、2月末に発表に行ってきます。 ここまでの成果としては上々です。ただ、ここまで辿り着くまでにいろいろありました。 もっとああしたら良かったとか、後悔の念をひしひしと感じています。

この先数年、継続して学生として研究することになったので、今まで以上にストイックに頑張りたいと思います。

技術的なこと

相変わらず Ruby 大好きっ子です。 お仕事でもいろいろな案件に関わらせてもらって、いろいろなノウハウが身についた 2014 年でした。

今振り返ると、技術的には平坦な 1 年だったと思います。 @IT で初心者向けの Ruby 記事を執筆したり、AWS 関係の勉強会で発表したり、確かに刺激はありました。 ただ、どこか満たされない思いも継続的に感じています。

正直なところ、私は Ruby だけで、エッジをいく開発者でいれるとは思っていません。Ruby の Java 化は現在進行形で進んでいます。

今年は、もっと広い視野を持って技術を学んでいきたいと思っています。 インフラとか、あまり表には出ないけれど最近アツい Erlang とか、普遍的な C 言語あたりを中心に使いこなせるようになりたい。

趣味とか

2013 年からずっとですが、クックパッドでレシピを探して、それを参考にお料理してます。 かなり経験を積んできてることもあり、味付けを自分好みに調節したりなど、板に着いてきた感じがあります。

今年は、自分でレシピを開発して、クックパッドにレシピを公開するようなこともやってみたいなーと思っています。

私生活とか

食べる量が増えているのかストレスなのか、少々身体に肉がついてきたような気がします.. 帰省したときに家族に指摘されてしまいました。

今年はお昼に炭水化物を抜くようにして、太りにくい体づくりをしようと思ってます。

さいごに

photo credit: gooblyglob via photopin cc

Evernote Clearly を Vimperator から呼び出すプラグイン vimperator-clearly.js を作りました

Vimperator で Evernote Clearly を一発で呼び出すための .vimperatorrc という記事で、 Vimperator から Evernote Clearly を呼び出す方法を紹介しました。

これでも十分なのですが、以下の理由から Vimperator プラグインとしてまとめることにしました。

Vimperator プラグインを作ってみたかった

Clearly の仕様が変わったときに、記事を更新するのはどうも微妙

Clearly 経由で記事を保存するなどの、今後の拡張性

mozamimy/vimperator-clearly.jsから、適当に煮るなり焼くなりしてください。 フィードバックやプルリクエストを投げつけてもらえるととても喜びます。

今は Clearly の画面をトグルするだけのシンプルな機能しかありませんが、Clearly 経由で直接保存するなど、もう少し追加したい機能はあります。

Ariete 1.0.0 リリース

標準出力や標準エラー出力をキャプチャする gem、Ariete をアップデートしました。 1.0.0 では、以下の変更が行われています。

RSpec のカスタム抹茶🍵マッチャーに対応

こんな感じでカジュアルに出力をテストできるようになりました。 （README.md より抜粋）

expect に Proc オブジェクトを渡すと、Ariete が Proc オブジェクトの中身を実行し、期待値と比較してくれます。 1 番目の example は to_proc を使って Proc オブジェクトを生成していますが、2 番目のようにラムダ式を使うなどしてテストすることもできます。 この辺、どう書くかはお好みでどうぞ。

インストール方法などは、以下の GitHub のリポジトリを参照してください。 https://github.com/mozamimy/ariete 基本的に $ (sudo) gem install ariete でインストールできると思います。

実はまだもう少し改良したいところがあって、

テストに失敗したときのエラーメッセージが残念

minitest や test-unit に対応したい

などなど。