オブジェクト指向設計実践ガイド by sandi metz の輪読会が終了した

部内の実装設計力向上を目的として、2016/11 から(大体)毎週1回のペースで「オブジェクト指向設計実践ガイド」の輪読会を開催して、2017/02/06 に完了した。


弊部は主に分析基盤の運用とアナリストのサポートをする部署であるため、実装力を身につける機会が少ないメンバが多い。 そのようなメンバ、特に新卒の頃から弊部に所属している若手にとって、設計について考えることは良い機会になったようだ。

オブジェクト指向を教えるにあたって、どの本が良いのかずっと悩んでいたのだが、2016/09に発売されたこの本をさらっと読んでみて良さそうと思ったので、この本を取り上げてみた。 結果としてこの本は良かったと思う。自分の経験からも同意できる内容が多く、基礎として教えるのに良い本であった。(とはいえ、細部まで全て同意できるわけではなかったので、輪読会中の補足は必要だったが...)

最後に、あえて一つ心に残ったものを取り上げると1章の「完全で正確に仕様を満たしており、永久に変化しないアプリケーションであれば設計を気にする必要はない。」という文になる。言い切っているのが面白かったし、変更への対処こそが設計が重要な理由だと述べていて、なるほど確かにと思わされた。 

DeNA TechCon 2017 と Developers Summit 2017 でDeNAの機械学習基盤と分析基盤の講演をしました

2/10 に開かれた DeNA Technology Conference 2017 と 2/17 に開かれた Developers Summit 2017 で講演をしてきたので資料をおいておきます。

DeNA TechCon では、AIレーンでのトークということで、AIに関わりのある機械学習基盤の話にだけ絞って「DeNA AIシステム部におけるクラウドを活用した機械学習基盤の構築」というタイトルで話してきました。

AI、特にディープラーニングの流行により、これから機械学習基盤を構築しなければならなくなっているインフラエンジニアだったり、AIエンジニアだったりが増えていると思います。 そういう方々に参考になれば幸いです。

Developers Summit では、AIに縛らずに、機械学習基盤の話と分析基盤の話をしてきました。

分析基盤の話は「DeNA流データエンジニアリングの極意」とタイトルを付けていて、自分がAIシステム部(旧称 分析基盤部)に来てから得たノウハウを凝縮したものになっていると思っています。

これから分析基盤を構築して、データエンジニアリングを行うような方々の参考になれば幸いです。前半の機械学習基盤の部分は DeNA TechCon でのトークと被るのでアップロードした資料からは除いてあります。

また、Developers Summit では、最近作っている Triglav (トリグラフ)というツールの紹介も行いました。ソースコードは

https://github.com/triglav-dataflow

で公開しています。このツールは、既存のワークフローツールでは解決できないような、分断されたアプリケーション間のワークフロー形成をデータ指向で支援するツールです。

データ指向でつながりを形成するので、古のツールでデータ取り込みが行われていた場合でも、ストレージさえ現役であればつながりを持たせることができます。

複数の Jenkins 間のつながりをもたせるといった課題を解決することもできます。

弊社以外でも類似の状況で困っている方々はいらっしゃると思うので、是非ご確認ください。




おわりに: 今年は DeNA TechCon (こちらはDeNA社員)でも Dev Sumi (こちらは有志)でもグラフィックレコーディングしてもらえてとても嬉しかったです。スゴイ。ありがとうございます╭( ・ㅂ・)و ̑̑




僕がプログラミングを続ける理由

matsumotory さんの 僕がOSSを作り続ける理由 - 人間とウェブの未来 の記事を読んで、自分もたまにはポエム。「僕がOSSを作り続ける理由」というか「僕がプログラミングをする理由」について。

自分は元々、将棋やオセロのようなパズルゲームが好きで、テレビゲームもファイアーエンブレムのようなシミュレーションゲームが好きな子供だった。 プログラミングはそれに通じるものがあると感じていて、問題(パズル)を問くことそのものが楽しい。これが自分のプログラミングに対するモチベーションの根源になっている。 難しい問題をシンプルなコードに落としこめた時や、新しいテクニックを身につけて解決した時などは最高である。

パズルゲームが好きならば、例えば将棋をやっていればいいじゃないか、となるかもしれないが、 プログラミングにはさらに、「成果物が残る」、「誰かに利用してもらえる」という副次的な要素があって(むしろ、ここが根源になっている人もいると思う)、そこも第2、第3のモチベーションになっている。 将棋などは、成績は残るし、自身の能力は高まるが、成果物が残るわけではないので、学生時代にプログラミングをやり始めてからは全くやらなくなってしまった。

この「誰かに利用してもらえる」という点は裏側でも全然問題ないというか、むしろ直接カスタマーに届くレイヤーよりも裏側のミドルウェアであったりとか、基盤の共通的な部分のほうがモチベーションが高まる。 そのほうが、間接的にでも利用される範囲が広がるからである。影響力を持ちたい。

まぁとにかく、こういう人間なので、問題が難しいほどモチベーションが高まる。作ったサービスをカスタマーに「使ってもらう喜び」よりも正直こちらの方が強い。 サービスよりも基盤寄りの人間だと自分を分析していて、もっぱら基盤の部署で問題解決をしている。 他の人には難しいだろ、みたいな問題を解きたいし、解けるようになりたくて日々修行している。

解くのが難しい問題を探しているので、何かあればお声がけください。
自分のユーザーマニュアル(出典: http://logmi.jp/172149)みたいな話になったな。

A Ruby and Fluentd committer working at DeNA. 記事本文および記事中のコード片は引用および特記あるものを除いてすべて修正BSDライセンスとします。 #ruby #fluentd #growthforecast #haikanko #yohoushi #specinfra #serverspec #focuslight
はてぶ人気エントリー

Google