結論、そんなに変わらなかった。　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つ立ち上げることになる

2018-08-26

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

技術

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

kotlin.connpass.com

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

資料はこちら。

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

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

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

plugins.jetbrains.com

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

2018-08-11

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

技術

github.com

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

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

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

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

作り方

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

shiraji.github.io

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

github.com

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

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

インストールの仕方

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

宣伝

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

2018-08-05

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に期待します

参考

Using Scikit-Learn in AWS Lambda -- Serverless Code

2018-08-04

転職の思考法を読んだ

読書

また退職の波動が出てるとか言われそうだけど、一緒に採用に関わっている人が採用戦略を考えるときに読んでいたので買った。

このまま今の会社にいていいのか?と一度でも思ったら読む転職の思考法

作者: 北野唯我
出版社/メーカー: ダイヤモンド社
発売日: 2018/06/21
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

どんな本か

筆者のドヤ顔が浮かぶ偉そうになんか言ってくる系の本かと思ったけど、体裁的にはカイゼンジャーニーに近い。転職するべきか悩んでいる主人公を中心に物語として話が進み、どういう思考で転職を考えるべきかということが説明される。

自分のマーケットバリューをどう捉えるか、どう高めていくか
これから伸びるマーケットを見つける方法
いいベンチャーを見つけるポイント
仕事における「楽しみ」について

などなど。

以下印象に残ったフレーズ。普通に読み物として面白くて1時間くらいで一気に全部読んでしまった。

「いつでも転職できるような人間がそれでも転職しない会社。それが最強だ。」

「意思決定とは、一番情報を持っていて、一番コミットしている人間がやるべきなんだ。」

なるほどなーと思ったこと

TODO型とBEING型

人間には「何をするか」に重きをおくto do型の人間と、「どんな人でありたいか、どんな状態でありたいか」というbeing 型の人間がいる

99％の人間はbeing型らしい。自分も「本当に自分がやりたいことはなんだろう」みたいなことを考えたりしたことがあるけど、これが見つからなくても悲観する必要はないとのこと。

being型の人間が仕事を楽しむ条件としては以下が上げられていてなるほどーという感じがした。

マーケットバリューが高められること
その仕事でつく嘘を最小化すること

他のエンジニアと話していても、「人生をかけてやりたい」みたいなことって見つからねーよなーという話をよくするので、参考になった。何をやりたいかも大切だけど、自分もbeing型なのでどうありたいかをこれからは考えてみようと思う。

転職後の給与について

すでに給与が高い成熟企業と、いまの給与は低いけど今後自分のマーケットバリューが高まる企業とで悩んだら、迷わず後者を選べ

これは自分の感覚的にもそうだと思う。

本当に優れた会社には勝手に人が集まってくる

本当に優れた会社には、勝手に人が集まってくるんだ。社員が自然に評判を作り、新しい社員を呼んでくるんだよ。

メル社とかはまさにそうだよなー。社員が自然と「うちの会社すげー」ってTwitterでこんなに言ってる会社見たことない。メル社に限らず採用がうまくいっている知り合いのベンチャーはどこも、「うちの会社すごい！楽しい！」と素でTwitterで言っている。

正直、自分はまだ今の会社にそこまでの気持ちは全然持ててない。前の会社にもそこまでの感情は持てなかった。ただ前職は最近フルリモートフルフレックスが導入された辺りから、社員のポジティブな反応が増えているなとは思う。

まとめ

転職を考えている人はもちろん、採用に対して課題感を持っている採用担当の人にも参考になる本だと思います。