_ libv8 のバージョンについて知る。

久しぶりに少し前のRailsアプリを触ることになって、bundle installしたところ、よくつまづく代表格であるlibv8 のインストールで失敗した。

環境は、

• macOS 10.12.6
• Rails 4.2.8
• Ruby 2.2.2
• libv8 3.16.14.3

である。ここで関係してくるのは、macOSであることとlibv8のバージョンのみ。

調べてみると、いくつかQiitaの投稿やブログを見つけ、それらの手順はこんな感じ。

$ brew uninstall v8
$ brew tap homebrew/versions
$ brew install v8-315
$ bundle config --local build.libv8 --with-system-v8
$ bundle config --local therubyracer --with-v8-dir=/usr/local/opt/v8@3.1.5
$ bundle install

つまり、インストール済みの最新のv8をアンインストールして、古いバージョンをインストールすると、libv8とtherubyracerをインストールできるということだ。

いままで自分が見つけた解決法に関する記事の中から、上の方法でなぜ解決できるのかを書いているものを見つけられなかったので、調べてみた。

で、タイトルにあるように、バージョンの問題ということがわかった。
そして、そんなに深く調べるとか必要なく、libv8のREADMEにちゃんと書いてあった。

Versions of the libv8 gem track the version of V8 itself, adding its own point release after the main V8 version. So libv8 5.0.71.35.5 and 5.0.71.35.14 both correspond to V8 version 5.0.71.35. Another way to think about it would be that 5.0.71.35.14 is the 14th release of the libv8 rubygem based on V8 version 5.0.71.35

つまり、libv8のバージョンは対応しているv8のバージョンと同じということ。
で、それが違う組み合わせになると、動作するかどうかは互換性が維持されてるかどうかになっていて、メジャーバージョンが違ってたりするとそれが顕著に出るということ。実際に、それまでインストールしてたv8のバージョンを調べてみると、

$ brew info v8
v8: stable 5.1.281.47 (bottled)
Google's JavaScript engine
https://github.com/v8/v8/wiki
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/v8.rb
==> Dependencies
Optional: readline ✔
==> Requirements
Build: python ✔, git ✔
Required: macOS >= 10.7 ✔
==> Options
--with-readline
        Use readline instead of libedit

ということで、やはり違うバージョンだったのでエラーが起きていたことがわかった。

もし今後、v8のインストールで失敗した時は、バージョンを確認することでサクッと解決できるかもしれないので、チェックしてみましょう。

_ rakuten_web_service 1.7.0 リリース

楽天の提供するウェブAPI「楽天ウェブサービス」のオフィシャルRubyクライアントであるrakuten_web_serviceの1.7.0をリリースしました。
明日からRubyKaigi 2017ということで、なんとなくそれに合わせてのリリースです。

変更点

• RakutenWebService::SearchResult、RakutenWebService::Response にページングのためのメソッドを追加しました。
• gemspecに定義されている開発用gemから、Visual Studio CodeのためのものをGemfileに移しました。
• README.ja.md の一部内容が古いので直してもらいました。
  • jinco13さん、ありがとうございました！

詳細はCHANGELOG からご確認ください。

参考

• rws-ruby-sdk/CHANGELOG.md at master · rakuten-ws/rws-ruby-sdk
• RubyKaigi 2017

_ Retty Tech Night 2017 に行ってきた。 #Retty_tech_cafe

ユーザー同士で美味しいお店を紹介しあうグルメサービスRettyさんがオフィスを麻布十番に移転したてのほやほやに開催されたRetty Tech Night 2017 に行ってきました。

早く着いて、まだ会場設営中だった。 #安定のぼっち業 #Retty_tech_cafe pic.twitter.com/J9UyabOUad

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2017年9月1日

会場はこんな感じでとてもキレイでした。Wifiや電源もたくさんあるので、普段はオフィスよりもこちらのカフェスペースで仕事する人も多いんだとか。また、PythonやAndroidのもくもく会の会場としても使われているそうです。確かにここは広々としたスペースで集中しやすそう。

会場一番乗り #Retty_tech_cafe pic.twitter.com/Jn6AFr7Vxs

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2017年9月1日

iPhoneのカメラの調子が悪く、ここから写真は撮れなかったので、各発表のスライドと一緒に振り返ってみる。

KotlinとReduxをAndroidアプリに導入したら

@muumuumuumuu さんによる、今絶賛取り組んでいるというRetty のAndroidアプリのKotlin化とRedux導入で見つけた知見の話でした。
発表中に行われた会場アンケートでは、業務でKotlinを使っている方は10名程度、更にReduxを組み合わせているとなるとなんとゼロ！ということで、かなり先進的な取り組みなのかもしれない:: fn 'Androidのことは専門外なのでよくわかっていない' }}。
Reduxは、React.js をさらに被せたフレームワークのようなもので、状態、アクティビティ、ビューを定義し、共通のステートを持つことで、操作に対する一貫した状態の変更を実現するもののようだ。Redux自体はJavaScriptのライブラリであるが、それをKotlinでそれっぽい実装が出来るようにしてくれるのがRedux-ktで、Rettyさん初OSS として公開されている。
まだ、KotolinやReduxを使ったアプリをプロダクションとしてリリースできていないが、その中で出てきた色々な問題（例えばStateはどういう単位にするのか）などが出てきており、設計方針やプラクティスはAndroidのコミュニティでもまだまだこれからのように見えた。きっと、そこら辺がPull-Requestを送るチャンスではあると思うので、OSS化したのはとても良い取り組みだと思う。

バックエンドが異なるサービスの差分を
APIで吸収してみた話

既視感ある登壇者*1による、多国展開した際に各国のアプリケーションとAPIとの間のやりとりを整備した話でした。
現在Rettyさんは日本以外に台湾、シンガポールへ展開しており、各国ごとにモバイルアプリケーションとそのバックエンドのAPIを作っていました。アプリケーションを複数持つのではなく、アプリ自体は1つとして、ユーザーの利用している国を識別し、バックエンドを切り替える方法もありますが、アプリ側に似たような分岐が沢山出て来るのも辛そうなところ。そこで、アプリと通信するAPIサーバーのエンドポイントを統一し、APIが柔軟にユーザーの国に合わせてレスポンスを返す仕組みにしたそうです。
その実装自体は、パブリッククラウドで提供されているサービスを使うのではなく*2、自前でNginx Moduleを作成し、リクエストを振り分けるようにしている。発表後のッ質問でも出ていたのだけれど、今後のさらなる多国展開、もしくは特定の地域からのアクセス負荷で、このNginxがボトルネックになりそう。回答にもあったように、今のところは でNginxを増強して解決するようだ。

Retty のインフラを支える技術

まず登壇者の鈴木さんが、「農家兼書道家兼SRE」というポジションに圧倒されるところから始まった。今は主に仙台でリモートで勤務されており、こういうイベントなど定期的にオフィスに来ているそうです。GoogleがSREを表に出してから、色々な会社でSREというポジションが出来てきている中、RettyさんでのSREは「全体のアーキテクチャの設計、構築、運用」がメインなようだ。サーバーサイドアプリケーションはDockerで運用されるようになっており、開発者は彼ら自身でDockerfileを書き、ElasticBeansへデプロイすることができているので、運用やSREから独立して仕事ができているようだ。SREはそれら以外の、例えば先の発表にあったようなNginxやDB（RDS）の監視や運用などを担当している。最後に鈴木さんが言っていたように、RettyさんでのSREは裁量を持っていて自由に動けているというのは良い。

Rettyの機械学習のこれまでまとめ

スライドがまだ公開されていないようだったので、文章だけ。

Rettyの機械学習基盤といえば、秋葉原で購入したパーツで自作ということで有名。詳しい内容は、QiitaやSoftware Design にも記事があるので読んでみるととてもおもしろい。

• Retty流『2200万ユーザを支える機械学習基盤』の作り方 - Qiita

という機械学習基盤がどのようにして出来てきたのかという経緯の話がメインでした。元々、TensorFlowで出ていたチュートリアルを試して、それがRettyにも活用できそう、という閃きで実際にプロトタイプを作ってみたら上手くいったので、そのまま導入まで話が進んだというのは、スピード感がある。
事例で出てきたのは、ユーザーがアップロードした画像の分類。以前はその作業の殆どが人の手によるものだったのを機械学習で置き換えていった。しかし、機械学習で作成された分類器も万能ではなく、料理は高い精度だけれど、店舗の外観・内装についての精度は低かったそうだ。そこで、料理と判別できたら機械学習の結果をそのまま用い、そうでなかった場合は従来通りに人力で分類することで、人の作業量自体を減らすことに成功している。使えるところで使う、というところで少しずつ導入していくのは、機械学習に限らず、ツールなどの導入で重要なところ。
また、それを色々な分類器を定義できるようにツール化しており、その入力がCSVというのも個人的には良い設計だと思った。なるべく多くの人が扱いやすいインターフェースを採用することで、結果的に、エンジニアの負担を少なくビジネスは早くすることができると思う。スタートアップらしい感じだった。

懇親会

Rettyさんのオフィスのある麻布十番近辺で有名のお店「天のや」さんのたまごサンドが最高でした。

ヒャッハー！ #Retty_tech_cafe pic.twitter.com/YWovd4l2KU

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2017年9月1日

なんか色々聞いたことをメモっとく。

• 現在麻布十番のオフィスには100名くらい。うち40名がエンジニア。
• 基本はオフィスでの勤務。家庭の事情などを考慮してリモートは可能。
• オフィスも見せてもらったけど、6つくらいのデスクで島が作られて、それらが並んでた。それらの間を遮るものが少なくて、とても広い。
• うわさの機械学習基盤も見せてもらえた。基盤むき出しのままで稼働してるものもあって、自作感がすごい。
  • 総工費は100万もしなかったらしい。
  • 電源もオフィスにある通常のものを利用。月の電気代は不明。
• Rettyのユーザーとの交流会を

創業から6年が経ち、ユーザー数も増えて、社員数が増えつつも、拠点を1ヶ所にし、社員同士やユーザーとの繋がりを大事にしている雰囲気があり、スタートアップらしさが残ってて良い雰囲気の会でした！Rettyさん、ありがとうございました！

天のやのたまごサンドによる多幸感の余韻が…

参考

• [増席]Retty Tech Night 2017 @ Rettyオフィス - connpass
• 天のや(麻布十番/甘味処) - Retty

_ 「管理会計の基本がすべてわかる本」を読んでた。

読み終わってたのに記録してなかったので、忘れないうちに書き残しておく。

本のタイトルの通り、管理会計の基本について丁寧に解説されていた。財務会計と管理会計との違いや管理会計の際のキャッシュ・フローの算出方法の基本的な考え方は、そういった勉強を一切してこなかった自分でもとてもわかりやすいと思った。

読んで思うのは、こういうことをビジネスに関わる人達全員が理解しておくと、色々動き方が変わってくるんじゃないかと思った。単に、予算があるのでその予算内であれこれやる、と開発側が考えてしまうのは危ない。それよりも、予算内に収めるは当然として、ランニングコストや販管費がどれくらいで、いつからキャッシュが生まれそうなのか、そのためには何をいまのうちに機能として積むか、リリース前
のコストをどこまで抑えるべきなのか、といったことを開発側も考えながらヒトやモノに投資しないといけないんだと思う。

今調べたら第2版が出ていて、そちらでは「業務改善の効果」という章が加筆されているそうだ。

_ 「小さなチーム、大きな仕事」を読んだ。

37シグナルズの哲学が書かれてた。
自分は、この4月あたりから小さなチームで仕事をしている。メンバーは4人。採用したのは自分ではないけど、ただ頭数だけで集められたわけではなく、同じような感覚を持ったメンバーが集まってる。開発だけでなく、営業のためにユーザーの元へ往訪してデモしたり、自分たちのチームのことを知ってもらうために来客を受け入れて自分たちの取り組みを見せたりと、色々やっている。それ以前の「開発の役割」はガラッと異なるものになった新鮮な経験だった。予算の規模とか人員とか、ビジネスと開発の境界とか、そういう境目が無くなった。無くなった分だけ小さいチームで良くなったような気がしている。というこの4ヶ月くらいを振り返りながら読んでいくと共感できるところが多かった。
それだけでなく、これから何かを始めようと悶々としてる気持ちをくすぐるような内容でもある。いずれ新規サービスや独立しようと考えている人にとって、次のアクションの後押しになる本だと思う。

_ 「プログラマー“まだまだ”現役続行」を読んだ。

• プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマーの定年と言われている35歳を過ぎてから、エンジニアとして今後どうやって生きていくのか度々考えることがある。先日、ふらりと図書館に寄った時に見つけたので借りて読んでみた。

著者の柴田芳樹さんといえば、Java関係の書籍では長く利用されているEFFECTIVE JAVAの訳者として有名。大学を卒業された後から現在までプログラマーとして活躍されている。この本の中でも触れられているが、プログラマーとして専任しているわけではなく、管理職でもあるがプログラマーとしての勉強を続け、後進育成のための勉強会も主催されている。

この本では、柴田さんがこれまでのプログラマーとして生きてきた中で見えてきた「プログラマーとしてキャリアを続けていくために必要な力」ついて書かれている。35歳定年説は、「プログラマーとして活躍できるのは35歳まで」ということではなく、プログラマーとして第一線で活躍するために必要な活動を続けていないために別のキャリアへ行かざるを得ない、というのがこの本で伝えたいことなのだと感じた。35歳あたりで期待されてくるのは、単にプログラマーとして成果を出すだけでなく、若手*1にたいして教育ができることだったりする。しかし、単に仕事をしているだけだと、伝えるスキルが無かったり、伝えられるように技術を体系化できていなかったりするので、プログラマーとしての期待に応えられなくなるのだろう。

柴田さんの言う必要な力とは、プログラマーとしての考え方、勉強の仕方、コミュニケーション、そして英語。特に英語については、いかにして良い情報を取り入れるかと行った時にはやはり英語で書かれたものに触れられることが大切ということを言っている。英語で読む力もまた一朝一夕で身につくものではないので、これもまた地道な勉強が必要で、柴田さんも年単位で英語の技術書を読書会で読んだりしているそうだ。

最近、エンジニアは業務時間外にも勉強すべきかどうかについて色々な議論がなされている。

• エンジニアは業務時間外でも勉強するべきなのか - 株式会社アクシア

それについても本書では、「会社に依存することなく自己のスキルアップのために自分の時間を投資しよう」と言っている。自分も、やはり自身の技術のために必要なことなので、業務時間云々は関係なく勉強する方が良いと思っている。

プログラマーとして今後やっていくにしろ、そうでないにしろ、技術に関する勉強を続けていかないとやっていけないし、そのための勉強の仕方については柴田さんの言うとおりで、いくらでもやりようがあるってことなんだと思った。日々新しいことが出てくるので、それを楽しんでいくしかないよね。

とりあえず、最後の章「30代、40代の人たちへ」は、その世代の人たちが今後管理職として生きる上でも大切なことが書かれてるので、ぜひとも読むのをお勧めします。

_ TokyuRuby会議11でLTしてきた。 #tqrk11

• TokyuRuby会議11 - Regional RubyKaigi

29日の土曜日ということで、今年も開催された肉と酒とRubyの祭典TokyuRuby会議11でしてきました。
これまで、LTに採択されては諸事情によりドタキャンせねばならないことが立て続けにあったので、たぶん3、4年振りくらいにTokyuRuby会議に参加した。

昨年から少しずつAzureで試してたことをサラッとまとめた話をLTしてきた。
要するに、最近になってAzureでもRailsを動かせる可能性はだいぶ高まってきたということです。会場ではAzure使ってる人は少なかったのですが、Microsoftさんの動きはだいぶ面白くなってきてるので是非触ってみてください。

最後に @igaiga555 さんがクロージングで、TokyuRubyは実行委員長や運営が変わりながらも最も長く継続している地域Ruby会議になっているそうだ。コミュニティ運営としてとてもお手本にすべきだと思う。

来年も7月29日が休日らしいので、また参加したいな。

_ 36歳になってた。

本日をもって35歳を満了し、36歳になりました。
この1年の間に、異動したり、新しい事業の立ち上げ*1の中で色々なことをやったり、モブプログラミングを始めたりと、以前とはかなり違うことをやっている。言語も、Rubyから離れ、PHPをメインにNode.jsやC#を書いている。環境もAzure を使うようになって、色々遊べることがあって楽しい限りだ。
定年説の35歳になっても、まだまだ学ぶことはあるし、良い意味で全然落ち着くことは無さそう。これから1年も、おそらくエンジニアとしてはまだ働けそう。

あと、この1年の中で、社外に出ていく機会も以前より増えた。
誘われて、気づいたら壇上に上がってただけなんだけど。

• DevOps Days Tokyo 2017
  • 開発環境もみんなでメンテ‼︎ DevOpsっぽい環境 on Azure をモブプログラミングで作ってみるよ
  • 朝まで生DevOps 〜現場実践者の集い〜 (Panel)
• モブプロディスカッション Registration, Tue, Jul 11, 2017 at 7:30 PM | Eventbrite

これからの1年は、こういう課外活動を増やしていこうと思う。
やっぱり、新しい人との繋がりは良い刺激になるし、それぞれの機会では何かしらチャレンジがある。人前に出るのは、相変わらず苦手ではあるのだけど。

他には、OSS Gate は継続して続けてきた。土曜のワークショップは、家の事情で参加が難しくなってしまったのだけど、平日夜に開催しているミートアップには顔を出せそうなので、OSS開発者同士を繋いでいくのを手助けできたらいいなぁ、なんて思ってる。

とりあえず、36歳も楽しく、価値のあるものを作れるように色々頑張ろうと思う。

最後に、いつものアレを置いときますので、何か贈っていただけると大変喜びます。

• お仕事関連
• 推し事関連
• 筋トレ関連

ということで、今後ともよろしくお願いします。