「センスのいらない経営」を読んだ
- 作者: 福島良典
- 出版社/メーカー: 総合法令出版
- 発売日: 2018/09/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Gunosyの元代表取締役社長の本。 経営したい欲があるわけではないのだけれど、経営者と呼ばれる人たちがどんな思想なのかを知れるかなと思って買った。
感想
本の読者層を想定してか、機械学習やエンジニアリングまわりにそれなりの量のページが割かれていて、その辺は知ってる人からすると少し退屈かもしれない。
KPIの追い方とかその辺の話は、WEB系の企業にいれば大体経験のある話だとは思うので、そこまで真新しいことはなかった。
ただGunosyの過去の転換点(CMとか、PF構想とか、別アプリとか・・・)でどのようなことを考えて意思決定をしたか、その意思決定に対する振り返りは面白い。 確かにCM最初はこういう形式だったよなーとか、あの構想は結局ダメだったのかーとか、当時の自分が感じたこと(そこまで深く考えたわけではないけどｗ)への答え合わせになった。
「社内からは反対の声もあったけど、自分としてはもともとの理念からぶれたわけではない」といった表現が何度か出てきた。もちろん本心からだとは思うけれど、一方でそう自分に言い聞かせている部分もあるような気もして、社長として会社を前に進めていくのって大変だなーと思った(小並感)
NETFLIXの最強人事戦略を読んだ
- 作者: パティ・マッコード,櫻井祐子
- 出版社/メーカー: 光文社
- 発売日: 2018/08/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Twitterでよく見かけたので買ってみた。
感想
単純に読み物として面白く、一気に読んでしまった。いろいろと名言の宝庫で、たしかになーとは思うものの、これをいきなり普通の組織に持ち込んでも破綻しそうとも思う。実際、最後のほうでも「重要なのは段階的に実験を行うこと」と書いてある。試行錯誤していきながら、組織を進化させていくことが重要なのだろうな。
- どんなに過去に素晴らしい成果をあげた人材でも会社の目指す方向性の業務に適さない人には辞めてもらう
- 「それ直接いったの？」
- 匿名の調査は「匿名のときに正直になるのが一番だ」と間違ったメッセージを送ってしまう
- データ自体にはなんの意見もない。チームで意思決定をする際にはデータ分析から得た洞察を参考にするが、それに振り回されることはない
- 「データを読み取れるほどスマートで、データを無視できるほど直感力にすぐれた人材を探している」
- 仕事に対する真の揺るぎない満足感は、優れた同僚たちと真剣に問題解決に取り組んだとき、懸命に生み出したサービスを顧客が気に入ったときにこそ得られる
- 組織はいろんなスタイルの人に合わせることができる。カルチャーフィットは双方向に働く。
それでもNETFLIXで働くのはハードだろうなと思う一方で、こんな会社で働いてみたいなとも思った。
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
- 作者: ＲｏｂｅｒｔＣ．Ｍａｒｔｉｎ,角征典,高木正弘
- 出版社/メーカー: ドワンゴ
- 発売日: 2018/08/01
- メディア: Kindle版
- この商品を含むブログを見る
感想
オブジェクト指向プログラミングとは、SOLIDとは、、、みたいなソフトウェアエンジニアやっていれば、耳にしたこともあるし程度はともあれ理解しているだろうということを、改めて説明してくれている。
個人的にはプログラミングパラダイムについての解説が面白くて、関数型・オブジェクト指向プログラミングはプログラマになにかを与えているのではなく、『何をすべきか』を伝えるというよりも、『何をすべきでないか』を伝えている。 という視点での解説が面白かった。考えたことなかったけどたしかに。
あとは、アーキテクチャの良し悪しをどういう指標で図るのかとか。
「わかるー」という話が多くて新たな発見的なものはあまりなかったけど、ソフトウェアアーキテクチャについてこれ一冊読めば大体学べる良い本だと思う。
MBP15インチ買った
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インチで良かった。地味にキーボードも良くなっていて嬉しい。大分ペチペチ感が消えた。
Kotlin Fest 2018でサーバサイドKotlinのテストについて発表してきた #kotlinfest
日本Kotlinユーザグループが運営するKotlin Fest 2018に同僚の @maeharin さんと一緒に登壇してきました。
@maeharin さんが既にブログにたくさん書いてるの自分はサラッと感想書きます。 maeharin.hatenablog.com
資料はこちら。
この規模のイベントに登壇するのもこの長さの資料を作るのも初めてだったのでめっちゃ緊張しましたが、とても温かい雰囲気だったのでリラックスして話すことができました。これもカンファレンスのオープニングで太郎さんが「カンファレンスを盛り上げよう！すごいと思ったら拍手しよう！面白かったら笑おう！」的なことを言ってくれたからなのではないかと思います。太郎さんありがとう。
個人的には自分の作ったプラグインにみなさんが「お〜〜」といって拍手してくれたのがとても嬉しかったです。調子にのって何度もデモしちゃってごめんなさい。 (歓声が上がったデモ動画)
ダウンロードしてくれたらもっと嬉しいのでぜひよろしくおねがいします。
自分の発表が終わった時点で割と力尽きてしまっていたのですが、控室でしらじさんとお話できたり、懇親会ではTwitterだけでつながってた人と実際にお話ができたりして、本当に楽しいカンファレンスでした。運営の皆様、本当にお疲れ様でした！そしてありがとうございました！
Kotlinでコンストラクタをシュッと書くためにIntellijのプラグインを作った
こういう感じのプラグインを作った
クラスのコンストラクタにわたすパラメータが少なければ、こんなもんいらないんだけど、でかいアプリケーションを扱ってるとコンストラクタに大量のパラメータを渡さなければいけないときは稀によくある。
あとはレイヤードアーキテクチャな構成を取っていて、各レイヤーでクラスを用意していると、レイヤー間でマッピングみたいなコードがめちゃくちゃ増える。
同様にテストコードで(ry……といったユースケースでコーディングをちょっとだけ楽にするために作りました。 READMEにも書いたけどGoの fillstruct にインスパイアされています。
作り方
プラグインの作り方、まじで情報が少なくて、shirajiさんのブログが大分参考になりました。
特にコンストラクタに渡すパラメータが足りないときにつく赤線と、それに対してQuick Fixのアクションを足すところは1から作るのがそれなりに大変そうだったので、既存の仕組みに大分乗っかっています。
この辺、特にドキュメントがあったりするわけではなさそうで、上記のソースコード読んで雰囲気で色々試しながら進めていました。
正直実装は大分手探りなので、なんか間違っているところや非効率なところあれば詳しい人シュッとプルリクください。
インストールの仕方
IntellijのPluginのところで「kotlin fill class」 で検索すると出てくると思うので試しに使ってみてください。
宣伝
縁があって登壇することになりました。このプラグインの話もちょっとする予定です。怖い！！！！！！！！！！！！！！ kotlin.connpass.com
AWS Lambda の PythonでShared Library(*.so)を含む外部ライブラリを扱う方法
仕事でPython / Lambdaを触る機会があり、Shared Library(*.so) を扱うライブラリの取扱でめちゃくちゃはまったので、メモっておく。
あと最近エモい記事ばっかり書いていたので、たまにはエンジニアアピールしておく。
Python初心者なので、それxxxでできるよ的な話があれば教えてください。
TL;DR
- Lambdaで外部ライブラリを扱うときにはZIPファイルに固めてアップロードする必要があるが、これに
.soファイルも一緒に固めておく - LD_LIBRARY_PATH はLambda実行時に指定できないので
ctypes.cdll.LoadLibraryでPython実行時に指定して読み込む - MacでビルドするとLambdaで動かなかったりするので、Dockerを使ってAWSのAmazon Linuxなどでpip install など行う
何がやりたかったのか
Lambdaでとある形式のファイルから、画像を抜き出すという処理をPythonでやろうとしていた。Lambdaでは依存する外部ライブラリは実行したいファイルと一緒にZIPで固めてアップロードすればよいらしい(Pythonの場合)。
よく紹介されているのは以下の方法だ。
pip install -r requirements.txt -t .
しかしPythonのライブラリの中には、純粋なPythonだけでなくて、Cなどで作られたライブラリをWrapしてPythonから使えるようにしているものがある。その場合は .py ファイルだけZIPにつめても実行時に以下のようなエラーになってしまう。
ImportError: libgdcmMEXD.so.2.8: cannot open shared object file: No such file or directory
しかし、 *.so を単純にZIPに詰めれば解決するという問題ではない。Lambdaでは *.so の読み込み先を決める LD_LIBRARY_PATH をいじれないからだ。
どうするのか
Lambdaでの実行用にZIPに固める際に、以下のように必要なLibraryをlib配下にまとめてしまう。
# 依存関係を./distにインストール pip install -r requirements.txt -t ./dist # gdcm関連パッケージを./distにコピー cp -r /opt/conda/lib/python3.6/site-packages/*gdcm* ./dist mkdir -p ./dist/lib cp -r /opt/conda/lib/libgdcm* ./dist/lib cp -r /opt/conda/lib/libsocketxx* ./dist/lib # 容量削減のためtestsファイルを削除 rm -rf ./dist/**/tests # メインファイルを./distにコピー cp ./main.py ./dist
その上で、Lambdaで実行するファイルで、明示的に lib 配下のファイルを読み込んでやればよい。
import os import ctypes for d, dirs, files in os.walk('lib'): for f in files: if f.endswith('.a'): continue ctypes.cdll.LoadLibrary(os.path.join(d, f))
TIPSとして、Mac環境でこれをやってもAWSのLambdaが動くLinuxの環境では動作しなかったりするので、LinuxのDockerイメージを用意してそこでZIPファイル作成や依存関係の解決を行うのがおすすめ。自分は雑に公式のAmazon Linuxは使わずに miniconda3 のイメージを使ってパッケージングしたけど問題なくLambda上でも動いた。
まとめと感想
Lambdaまともに使ったのは実は初めてだけど便利だった。Shared Library依存ののものがあると結構面倒だけど、気合でなんとなかる。 サーバーレスで自分のDockerImageをシュッと動かせるようになるとめっちゃ楽になりそうなのでGCPに期待します
