meguro.rbで「rescueされない例外?!」 というタイトルで LTしてきた

(多分)台風で出社して疲弊していたsuusan2goは、疲れからかQuipper社のEMにMeguro.rbへの参加を勧められてしまう。

というわけでLTしてきました。他にもネタはなくもなかったんですが、風邪引いてて1から作る気力がなかったので、昔ブログに書いた内容をLTにしました。

suzan2go.hatenablog.com

このブログを書くもとになったqsonaさんもたまたま来ていて聞いていただけて何か嬉しかった。自分のLTとは関係ないですが、当日のqsonaさんの「目黒のさんま」は名演でした。

他の方のLTの内容もバラエティに飛んでいてとても楽しかったです。1年ぶりくらいに会う方と話せたり、EM的な話ができたり、若干体調悪かったのですが楽しめました。 やっぱりこういう地域コミュニティがあるの本当によいことだなーと思う。また参加します。

「センスのいらない経営」を読んだ

センスのいらない経営

センスのいらない経営

Gunosy元代表取締役社長の本。 経営したい欲があるわけではないのだけれど、経営者と呼ばれる人たちがどんな思想なのかを知れるかなと思って買った。

感想

本の読者層を想定してか、機械学習やエンジニアリングまわりにそれなりの量のページが割かれていて、その辺は知ってる人からすると少し退屈かもしれない。

KPIの追い方とかその辺の話は、WEB系の企業にいれば大体経験のある話だとは思うので、そこまで真新しいことはなかった。

ただGunosyの過去の転換点(CMとか、PF構想とか、別アプリとか・・・)でどのようなことを考えて意思決定をしたか、その意思決定に対する振り返りは面白い。 確かにCM最初はこういう形式だったよなーとか、あの構想は結局ダメだったのかーとか、当時の自分が感じたこと(そこまで深く考えたわけではないけどw)への答え合わせになった。

「社内からは反対の声もあったけど、自分としてはもともとの理念からぶれたわけではない」といった表現が何度か出てきた。もちろん本心からだとは思うけれど、一方でそう自分に言い聞かせている部分もあるような気もして、社長として会社を前に進めていくのって大変だなーと思った(小並感)

NETFLIXの最強人事戦略を読んだ

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

Twitterでよく見かけたので買ってみた。

感想

単純に読み物として面白く、一気に読んでしまった。いろいろと名言の宝庫で、たしかになーとは思うものの、これをいきなり普通の組織に持ち込んでも破綻しそうとも思う。実際、最後のほうでも「重要なのは段階的に実験を行うこと」と書いてある。試行錯誤していきながら、組織を進化させていくことが重要なのだろうな。

  • どんなに過去に素晴らしい成果をあげた人材でも会社の目指す方向性の業務に適さない人には辞めてもらう
  • 「それ直接いったの?」
  • 匿名の調査は「匿名のときに正直になるのが一番だ」と間違ったメッセージを送ってしまう
  • データ自体にはなんの意見もない。チームで意思決定をする際にはデータ分析から得た洞察を参考にするが、それに振り回されることはない
  • 「データを読み取れるほどスマートで、データを無視できるほど直感力にすぐれた人材を探している」
  • 仕事に対する真の揺るぎない満足感は、優れた同僚たちと真剣に問題解決に取り組んだとき、懸命に生み出したサービスを顧客が気に入ったときにこそ得られる
  • 組織はいろんなスタイルの人に合わせることができる。カルチャーフィットは双方向に働く。

それでもNETFLIXで働くのはハードだろうなと思う一方で、こんな会社で働いてみたいなとも思った。

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

感想

オブジェクト指向プログラミングとは、SOLIDとは、、、みたいなソフトウェアエンジニアやっていれば、耳にしたこともあるし程度はともあれ理解しているだろうということを、改めて説明してくれている。

個人的にはプログラミングパラダイムについての解説が面白くて、関数型・オブジェクト指向プログラミングはプログラマになにかを与えているのではなく、『何をすべきか』を伝えるというよりも、『何をすべきでないか』を伝えている。 という視点での解説が面白かった。考えたことなかったけどたしかに。

あとは、アーキテクチャの良し悪しをどういう指標で図るのかとか。

「わかるー」という話が多くて新たな発見的なものはあまりなかったけど、ソフトウェアアーキテクチャについてこれ一冊読めば大体学べる良い本だと思う。

MBP15インチ買った

www.apple.com

Dockerを動かしたり、IntelliJのpluginを開発したりすると*1、8GBのMBPではとてももっさりするようになったので買い替えることにした。

13インチと15インチで死ぬほどまよったけど、相談したエンジニア全員から15インチにしろと言われ、15インチを購入した。今の所満足している。

Twitterで評判を検索していたところ、自分以外にも結構な数の人が13インチか15インチかで迷っていたようなので参考になればと思って迷っていたポイントと実際どうだったか書いた。なおApple製品が好きなので、MBP以外の検討はしていません。

自分が悩んだポイント

前提として、自分はこれで3台目のMBPになるんだけれども、これまではずっと13インチのMBPを使ってきた。

15インチはデカすぎないか

結論、ちょうどよかった。 むしろ、今までの13インチのMBPの画面めっちゃ小さいなと感じる。作業効率は格段にあがったように思う。それでいて、13インチのときと同じような使い方が苦なく出来ている。

  • ソファーで膝に載せて作業する
  • リビングのテーブルの上で作業す
  • 自分の机の上で作業する
  • カバンにいれて持ち運ぶ

15インチだと結構邪魔に感じてしまうんじゃないかと思ったけど全然そんなことなかった。

15インチは重すぎないか

結論、そんなに変わらなかった。 2014年の13インチMBPと比べると2018年15インチMBPのほうがカタログ的には少し重かった気がするけど、ほとんど体感は変わらない。むしろ2018年のほうが本体が薄いせいか軽く感じるくらい。家の中 / 勉強会などで持ち運ぶのが苦にならないか心配していたけど、今のところ全く問題ない。

Touch Bar有りか・無しか

現状だとTouch Bar無しだと13インチしか選べす、CPUも古い世代のものになってしまう。スペックを重視するならTouch Barありにするしかない。

使ってみてTouch Barに不満というか、そこまでの文句はない。Touch Barはともかく、Touch IDは便利。15インチを勧めてくれたエンジニアの一人も、Touch IDなしはもう考えられないといっていたんだけど、自分も同じ感想。

まとめ

15インチで良かった。地味にキーボードも良くなっていて嬉しい。大分ペチペチ感が消えた。

*1:IntelliJのplugin開発ではIntelliJを2つ立ち上げることになる

Kotlin Fest 2018でサーバサイドKotlinのテストについて発表してきた #kotlinfest

日本Kotlinユーザグループが運営するKotlin Fest 2018に同僚の @maeharin さんと一緒に登壇してきました。

kotlin.connpass.com

@maeharin さんが既にブログにたくさん書いてるの自分はサラッと感想書きます。 maeharin.hatenablog.com

資料はこちら。

この規模のイベントに登壇するのもこの長さの資料を作るのも初めてだったのでめっちゃ緊張しましたが、とても温かい雰囲気だったのでリラックスして話すことができました。これもカンファレンスのオープニングで太郎さんが「カンファレンスを盛り上げよう!すごいと思ったら拍手しよう!面白かったら笑おう!」的なことを言ってくれたからなのではないかと思います。太郎さんありがとう。

個人的には自分の作ったプラグインにみなさんが「お〜〜」といって拍手してくれたのがとても嬉しかったです。調子にのって何度もデモしちゃってごめんなさい。 (歓声が上がったデモ動画)

https://user-images.githubusercontent.com/8841470/44616661-ce042280-a88e-11e8-81fe-b7ce5e7c4871.gif

ダウンロードしてくれたらもっと嬉しいのでぜひよろしくおねがいします。

plugins.jetbrains.com

自分の発表が終わった時点で割と力尽きてしまっていたのですが、控室でしらじさんとお話できたり、懇親会ではTwitterだけでつながってた人と実際にお話ができたりして、本当に楽しいカンファレンスでした。運営の皆様、本当にお疲れ様でした!そしてありがとうございました!

Kotlinでコンストラクタをシュッと書くためにIntellijのプラグインを作った

github.com

こういう感じのプラグインを作った

https://user-images.githubusercontent.com/8841470/42932763-24e15c72-8b7e-11e8-9e60-ee2f8095d6cc.gif

クラスのコンストラクタにわたすパラメータが少なければ、こんなもんいらないんだけど、でかいアプリケーションを扱ってるとコンストラクタに大量のパラメータを渡さなければいけないときは稀によくある。

あとはレイヤードアーキテクチャな構成を取っていて、各レイヤーでクラスを用意していると、レイヤー間でマッピングみたいなコードがめちゃくちゃ増える。

同様にテストコードで(ry……といったユースケースでコーディングをちょっとだけ楽にするために作りました。 READMEにも書いたけどGoの fillstruct にインスパイアされています。

作り方

プラグインの作り方、まじで情報が少なくて、shirajiさんのブログが大分参考になりました。

shiraji.github.io

特にコンストラクタに渡すパラメータが足りないときにつく赤線と、それに対してQuick Fixのアクションを足すところは1から作るのがそれなりに大変そうだったので、既存の仕組みに大分乗っかっています。

github.com

この辺、特にドキュメントがあったりするわけではなさそうで、上記のソースコード読んで雰囲気で色々試しながら進めていました。

正直実装は大分手探りなので、なんか間違っているところや非効率なところあれば詳しい人シュッとプルリクください。

インストールの仕方

IntellijのPluginのところで「kotlin fill class」 で検索すると出てくると思うので試しに使ってみてください。

宣伝

縁があって登壇することになりました。このプラグインの話もちょっとする予定です。怖い!!!!!!!!!!!!!! kotlin.connpass.com