「エンジニアで有り続けたい」って
大した努力もしていないのになんとなく言い続けてるのって、
夢を追い続けているミュージシャン
と一緒だわな…
本気で一生エンジニアやろうとしている人や、「でも自分はこっちのほうが適正はあると思う」な仕事（人じゃなくて仕事そのもの）に対して失礼極まりない話だ。
…ということに今更ながら気づきました。
どんな道を選んでも努力が必要なことには変わりないので、苦手だで済ませずに面と向かう覚悟が必要だな。
（さもなくば、「それはやらない亅宣言。）
Baseball Play Studyで発表してきたんだけど一応ささやかながら技術的な勉強もしているのよ という記録 #bpstudy
今年も野球バカの発表を
Baseball Play Study 2017 冬 野球振返りスペシャル(BPStudy#124) - connpass
でさせていただきました。
資料はこちら。*1
野球にご興味ある方には、是非内容も見てご一笑いただければ幸いなのですが、このブログでは「一応発表の過程で勉強した」技術的なことを書き残したいと思います。
Java系
クラスってどう切るのが良いですかね
ってな感じで、
taichiw.hatenablog.com
よりも前に書いていたコードを、上記の本の実践によってリファクタする良い機会になりました。
なにせ、元が勢いで書いたコードなんでクソまたクソ。リファクタの題材としては我ながらとても素敵でした。
Parallel Stream たのしー
パラレル処理が威力を発揮するとき
最後に、parallelStreamの速さの実験。YahooFinanceが提供している株価APIを連続でコールして、最も株価が高い銘柄を求めるというものでした。
通信が絡むため繰り返しによるオーバーヘッドが大きい処理です。
これをparallelStreamを使って並列化することでめっちゃ速くなる！という例。以前はこういった処理を記述するためにはマルチスレッドで意図的に書く必要がありましたが、今後は非常にシンプルに書くことができるようになるようです。
これを4年越しで実践…
最近は「何でもかんでもParalellStreamにするものではない。かえって遅くなることもある」といわれているようですが、少なくともスクレイピングを簡単に高速で回すには速かったで！*2
Non-Java系
久しぶりにPython使ってみたぞ
こういうグラフが描きたくてですね
なんか適当なオンラインツールとか無いかな－… と思っていたんですが
と、教えていただきまして、観念して（？）Pythonで書いてみました。
github.com
コードを書くの自体はちょっとググりながらで1～2時間程度だったんですが、きれいなグラフを描くのが予想以上に難しくて。
計算を始めるときのノードの初期位置に結果がかなり依存してしまうようで、実行のたびにグラフの絵が変わってしまう、という状況でした。
そんなわけで上のスライドの右下にもある通り、パラメータいじりながらの、何度も試しながらのの中で得られた、「奇跡の一枚」ですｗ
*1:SlideShareの再アップロード機能がなくなってしまったので、Speaker Deckに引っ越す。（比較表もあるよ） - エンジニア的なネタを毎週書くブログで書いたとおり、Speaker Deckに上げてみました
*2:当然、やりすぎると攻撃になってしまうので程々に…
*3:本当はLTのネタ自体も事前にレビューしてもらってブラッシュアップしたいところなんだけど… レビュアーとして最適な皆さんが、当日の一番の「お客さん」なのが悩みどころｗ
SlideShareの再アップロード機能がなくなってしまったので、Speaker Deckに引っ越す。（比較表もあるよ）
プレゼン資料のアップロード。
もともとSlide Shareを使っていたため、ちょっとイライラする事があったり、「イケてるエンジニアの人のSpeaker Deck率高いなぁ…」と思いつつもSlide Shareを使い続けていたのですが、
何やら技術的な理由*1によって再アップロード機能を廃止したとのこと。
私も技術屋の端くれなんで、
You will still be able delete your older SlideShare files and upload new presentations.
って言いたくなる気持ち、わかります。「更新」って意外とメンドウなんだよね。単なる新規登録に比べて。
…とはいえ、これは利用者としては受け入れられねーわ。
自分が発表した後に、ブログからリンクしてもらったり、埋め込んでもらったものを全く変えられないというのは辛い。
…ということで、Speaker Deckに移行しようと思います。
このタイミングなら誰か検索で来てくれそうな気もするので
自分の目で見たところの比較表でも書いておこうかと。
アカウント
- SlideShare
- 独自アカウント
- LinkedIn アカウント
- facebook アカウント
- Speaker Deck
- 独自アカウント
- GitHubアカウント
どちらもよく使う、覚えているアカウントが使えるのでまぁOK.
SlideShareはFacebookアカウントでログインできるのが地味に便利ではありましたが…。
スマートフォンでの閲覧
- SlideShare
- Speaker Deck
- スマホ対応無し。PCのビューで
以前から、人様のスライド on SpeakerDeckをSNSなどで見つけて見る時にちょっと気になっていた点。見られないほど苦痛ではないけど見やすくもない。*2
一方、SlideShareのアプリはアプリで、結構問題があって、ストレスの一因ではあったのですが…（Webより機能が落ちていたりとか、何故か真っ黒でスライドが全然前表示されない時があったりとか）
アップロード
- SlideShare
- PDFの他、パワーポイントのファイル(pptx)が直接アップロード可能
- Speaker Deck
- PDFのみ
SpeakerDeckはパワポ、上げられないんですね。
とは言え今時は、Windowsのパワポからでも普通にPDFが吐けるので、大して問題ではないです。
強いて言えば、SlideShareはpptxファイルの置き場そのものとしても使えたんだけど、SpeakerDeckの場合は別で管理しなきゃだなーと。
*1:この辺のブログを見ると、以前からSlideShareさんの中では再アップロードが問題になっていた模様です。 http://did2.blog64.fc2.com/blog-entry-396.html
*2:Androidで勝手アプリを発見しましたhttps://play.google.com/store/apps/details?id=com.unosk.speakerdeck&hl=ja
新しいサービスを引き継ぐにあたって「ドメインナレッジ」は必要か
今年の二月ころ、ある会議の中で、
「ドメインナレッジが不要なプロダクトを作りたい」
と発言した。
他の参加者の皆さん（偉い人多め）からは、総じて「ポカーン」とされてしまった。
実は、その時の私は、なぜ「ポカーン」とされているのか、よくわからなかった。
正直に言うと、二月のその会議で、一体自分は何を言いたかったのか、
その時は自分の中でもうまく言語化できていなかった。
それがついさっき、急に、ちょっとだけ分かった気がしたので、忘れないうちに言語化しておきたい。
私は、
ほぼドメインナレッジを持たない状態のエンジニアが
初めてそのプログラムを読んだ時に（あるいはコンポーネント図などシステム全体の構成を知った時に）
システムの設計からドメインナレッジ（どういうビジネスを代行するシステムなのか）を知ることができる
そういうプロダクトを作りたかったのだと思う。
いま同僚と、こちらで紹介されている、オブジェクト指向エクササイズに取り組んでいる。
qiita.com
お題になっている自動販売機のソースはこんな感じ。
https://gist.github.com/i-takehiro/3ccb2ece25c89d4ed41c
（エクササイズのお題として）非常に素晴らしいコードだ。
このコードを見て、
・自動販売機とは何か
・そもそもこのプログラムが何をしたいのか
理解するのはかなり難しいと思う。
「ポカーン」とされた、会議の話に戻る。
当時の私は二年ほど、上記のような「自販機」のメンテナンス（新規の追加機能開発含む）をしている状況だった。
意図が全くわからないコードに対して手を入れなければならなかった。
作った人たちは既にほとんどいなかった。あるいはいらっしゃっても（失礼ながら）元の業務を知らないか、忘れているか だった。
（あるいはご存知なのに私が決めつけて聞かなかった時もあったかも。この点は反省）
業務に詳しい人はいたので、どういうビジネスモデルなのかは教えてもらえた。
しかし、そこから当時のエンジニアが何をどう思って今のコードに至ったのか
そのコードに手を加えるとしたら何が正しいのか
は必死に過去のエンジニアの考えに想像を巡らせる必要があった。
過去に作られたシステムの運用なんて大体そんなもんかもしれない。
とは言えその時私が見ていたシステムはあまりにビジネスそのものとプロダクトが複雑で、自分のキャパを超えていて、正直辛かったし病んでいた。
それでも。
私は、
私が作ったシステムを引き継ぐ人がほぼ背景の知識が０であってもシステムの意図を理解でき、その後変更が加えられる
そんなシステムが理想的だと思う。
当然、そんなシステムを開発するためには
・背景にあるビジネスへの理解
が欠かせなく、
更に、
・そのビジネスを「理解できるシステム」に落とし込むことができる設計力が必要だ。
だから、「ドメインナレッジが要らないシステム開発」のようなことを言って「ポカーン」とされたんじゃないかな、と
今になってみれば思う。
おまけ：当時見ていた「自販機」はこんな感じ
「自販機」はすごく複雑なものだ。
・「喉が渇いたな－ 甘くて冷たいのが飲みたい」というユーザのリクエストを受け…
・まずは原料を調達。香料や砂糖などを生産している会社に在庫を問い合わせ、仕入れる。
・仕入れてきた材料を混ぜ混ぜして製品を作成。コーラとか、ソーダとか、お茶とか いくらかの商品が完成する。
・商品を陳列。ユーザに選んでもらう
というような機能を持っていた。
なお、
・材料を生産・売っている会社
・ジュースを作る会社
・ジュースを販売する会社
は全部違う会社で、それぞれの会社が利益を出すために会社間の取引の際に
・原価に利益率を掛けて卸したり
・販売戦略に合わせて原価割れするくらい値引きしたり
するのだけど、この３社の、そういったお金に関する計算も全部一台の自動販売機がやっている。
「境界づけられたコンテキスト」なんてクソ食らえな、スーパー自販機だ。
※そんな自販機、今日も元気に稼働しています。毎日ぼくのお給料を稼いでくれてありがとう。
そしていまメインで見てくださっている担当者の皆さん、本当に有難うございます。
雑記：MVC「コントローラ」ってコントローラか。
私がMVCモデルという言葉を知ってからかれこれ10年以上経つんですが、「コントローラ」っていうのが長いことずっとしっくり来ていませんでした。
モデルとビューをつなぐ だとか。
ユーザの入力を受けてモデルを呼び出す とか。
Ruby On Railsタイプのフレームワークだと「コントローラ」にロジックがわりと書かれたりとか。
どれもしっくりこないなーと思っていたんですが、そもそも自分が「コントローラ」という単語に持っていたイメージが間違っていました。
私は、アプリケーション内で、様々な機能を呼び出し調律する機能を「コントロール」だと思っていたのです。
オーケストレータとかコンダクタって呼ばれる機能ですね。
そのイメージをずーっと持っていたのですが最近ふと気づきました。
「コントローラ」ってこれじゃん。
「Aボタンを押したらジャンプする」という“UI”があった時に、この「Aボタン」に相当するのがコントローラかと。
これに気づいた時に、今まで抱いていたもやもやが随分スッキリしました。
