Cookpad TechConf 2019に参加したら自社の採用とSREが気になりだした話 #CookpadTechConf

Cookpad TechConf 2019に参加＆社員さんに質問してきました。
社員一人一人がミッション達成のために働いていることが伝わってきて大変良かったです。来年も絶対行きたいぞ...

特に私が気になったのは、前半のプロダクトの仮説検証・デザインの話と、中〜後半のSRE・セキュリティの話です。 どちらもすぐに試したいノウハウばかりで参考になったし、各プロダクト・チャプター（専門性ごとに分かれたエンジニアチーム）のリーダーがユーザーファーストの考え方を持っていることがわかりました。

特に気になったセッションを5つ抜粋します。

生鮮ECクックパッドマート - サービスの立ち上げから拡大に向けて

MVPをコードゼロ行から初めており、私もプロダクトを作ることがあったら真似したいと思いました。

speakerdeck.com

懇親会で喋ったエンジニアの方によれば、アプリを開発するときも、まずはWeb版を作って社内で試し、それからアプリ版を作成した、とのことでした。それ以外にもEC対応店舗側でのラベルの発行をするハードウェアも2周目を作成中だとか。

とにかく興味深かったのが、プロダクトがこれから成長することが分かる点です。もし他のメガIT企業がECサイトを同じようにローンチしたのを聞いても、これほど将来が楽しみになることはなかったはず。
採用でエンジニアを惹きつけるには「プロダクトの将来を楽しみに思わせる」ことだと思いました。

Challenges for Global Service from a Perspective of SRE 2nd season

SREにとってのユーザー = エンドユーザー & プロダクト開発者 って定義が刺さりました。

speakerdeck.com

スピーカーの渡辺さんにセッション後30分くらいひたすら質問させていただきました。いくつかメモ。

• AWSのマネージドサービスを使う場合も自社でソフトウェアを作る場合もある（当たり前だけど）
  • 後者は作った人が抜けた場合にメンテで困る
• 常にリモートワークをしているのはもともと東京で働いてたメンバーで京都に引っ越した人など。つまり、チームの雰囲気を作る前からいきなりリモートは厳しい
• 技術選定はチャプターのリードが先行するが、メンバーが動くものを持ってきてそれで議論することもある
• イギリス人は婉曲表現が好きなので日本人と馬が合う

自社のSREもチームを作って価値観をシェアしたいと思いました（その規模の時に自分がSREをしているかはわかりませんけど）

レシピを解析する！Machine Readable Recipe（MRR: 機械可読なレシピ）の開発

フツーに面白かったです。要因の一つは、間違いなくスピーカーの伊尾木さんのスキルですね！
レシピを木構造に変換してしまえば、そこから無限のビジネスの可能性があるのがわかってワクワクしました。
こういうスケールしそう感がエンジニアを惹きつけるな〜と思いました！

スケーラブルなセキュリティ監視基盤の作り方

AWSマネージドサービスをフル活用したログ基盤について

speakerdeck.com

スピーカーの水谷さんとお話ししたことをメモ書き。

• ログの扱いやすさから、AWSでログ監視体制を構築する上ではS3 + Lambda（など）は一つのベストプラクティスだと思っている
• ログ監視ルールは、複雑なルールを作る時などにも実感するが結局Lambdaで素直にコードで書いた方が楽
  • TerraformがCloudFormationよりも楽、みたいな話ですよね。
• アプリの特定の処理の流れを追いたい、などのニーズがあるのでログ検索基盤は便利
• AWSのマネージドサービスをあえて採用しないケース、たとえば出たばかりのサービス（ex Security Hub）では内製することもある

Re:silience から始めるカオスエンジニアリング生活

「外部サービスのエラーの影響を受けるが、それが自分の中でどうなるかは知らない」から潰していこう、という話。流行に乗ってカオスエンジニアリングをするのではない、という姿勢が素晴らしかったです。

speakerdeck.com

本当これ。

「ただランダムに落とすことは重要ではないからChaos Engineeringについて本気で考えてやってみた」ってめっちゃいい話#CookpadTechConf

— TAKAKING22@FA宣言 (@TAKAKING22) February 27, 2019

自社でもすぐに使えるノウハウはあって、例えばサーバーサイド開発者がボタン一つで外部サービスとのネットワークを寸断できるような仕組みは例外系を実装する上でめちゃ大事ですよね。

まとめ

こちらのTweetの通りだと思います。

いくつものセッションが「ビジネスを意識した優先順位付けや意思決定」や「プロジェクトやプロダクトに対する Ownership」に触れててとても良いカンファレンスだ #CookpadTechConf

— ポジティブな Tori (@toricls) February 27, 2019

会社としてミッションを強く打ち出しているからこそ社員が本質からずれた施策を打たず最速で仮説検証を進められている、こういう風になりたい組織の一つの類型だなと感じました。

自社でも、どんなミッションがしたくて、そのためにこんなプロダクトがあって、その仮説検証に入って欲しいんだ！という姿勢を打ち出して採用したいな、と思いました。

それから、ご飯は期待通りめっちゃ美味しかったです！！！！！

エンジニア歴4年の私が2019年2月に知らないこと

エンジニアとして仕事を始めて4月で4年になるけど、相変わらずなんで動いてるのか分からないものが多い。
次の1年に何を学び、何は魔法で済ますのか、考えるきっかけにする。

ブラウザとサーバーの通信で何が起きているか

HTTPという書式に従った文字列が往復していることは知っている。その中身がメソッドやヘッダー、レスポンスコード、ボディなどからなることも知っている。
でも、TCPのレベルになると全然説明できない。通信を確立するために何往復かしてること、通信の中身をパケットと呼ばれる単位に分割してることは知ってる。でも、絵には描けない。

HTTPS

証明書によってクライアントとサーバーの本人確認らしいことをしていることは知っている。
どういう仕組みで…？今度AWSでドメインとるからそこで学べるかも。野良HTTPSなるものもあるらしいけど、何が野良なの？

ネットワーク系のコマンド全般

多いよ…。

デーモンとは何か

サーバーの起動時に実行されるコマンドを登録しておくものということは知っている。でも、どんな仕組みでそれが起動するの？ 起動時に実行されるものといえば、私にとってはdockerのエントリーポイント。見えないところではデーモンにお世話になっているんだろうか。
何かでちらっと見たけど、デーモンとコンテナには関係があるらしい。これも謎。

「Linuxでは全てがファイル」の意味

すごく賢い設計だと誰かが褒めてたのを見たことがある。でも待って、「全て」って？
ラズパイにビデオを繋いだ時、その接続の設定でファイルパスみたいなのを入力した覚えはある。それがファイルって…逆にファイルじゃないって何？

シェルスクリプト

一応書ける。でも、
・IFの中身がよく分からない
・変数を参照するときに後ろから修飾できるやつ、多機能でよく分からない
・標準出力と標準エラー出力をつなぐやつ意味分からない
・関数とコマンドがどうやら違うものらしい
・サブプロセスがよく分からない
１つのことをやるのにやり方が多い気がする。それに、どこまで勉強すべきなの？

yield文、コレクション型とイテラブルって言われるもの

yeuldの解説はもう10回くらい目にしてる気がするし、サンプルコード書いた気もするけどよく分からない。
そもそも発音がパッと見で分からないので頭の中で考えるときにさえ自信が持てない。
コレクション型はJavaに配列とリストがたくさんあったのであんまり見たくない…

Docker

一応ビルドしてランすればいいことは知ってる。会社でも普通に使う。
でも、Dockerとdocker-composeで似たコマンドがたくさんあって、オプションにも規則性が見えないしいつまでも苦手感がある。
それから内部のDSLもよく分からない。ADDとCOPYの違いとか。

React Nativeの裏側と、ネイティブアプリが動く仕組み

なんだか怖そうで全然知らない。そもそも、アプリの上でJavaScriptが動く、というのがどういうことなのか…（これはブラウザにも言える）

Google Cloud Platform

会社のアカウントでみんながJupyter Notebookを使えるようにしたかったんだけど、アカウントと組織の関係がAWSと違うらしくて、1時間くらいやって諦めた。

まとめ

仕事中に分からないことが出てくることは普通にあるし、全部を調べてると仕事が進まない気持ちになることもある。
でも、放置してるとこうやって苦手意識になってしまう（進研ゼミみたいだ...）

やっぱり分からないことは徹底的に詰める気持ちが大事だなって思います。

JDK10/ Kotlin1.3で黒べこ本（Kotlin Webアプリケーション）のSpring Bootサンプルをビルドする

Kotlinの導入を社内で検討しており、長澤太郎さんの"黒べこ本" を読んでいます。

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

ところが、Intellijの環境構築を黒べこ本よりも前に済ませており、黒べこ本で指定されているのとは違う設定になっていました。
本ではJDK1.8/ Kotin1.1が想定されていますが、現在（2019/01/24）のIntellij IDEAのデフォルトはJDK10/Kotlin1.3のようです。

試行錯誤して動くようになったのでやり方をシェアします。

1. Gradleのディストリビューションのバージョンをあげる

GradleのWrapperではGradleの実行可能バージョンとして3系が指定されていますが、これが内部で呼び出すJavaのバージョンが違うようです。まずはここを5系に合わせます。

旧（gradle/wrapper/gradle-wrapper.properties）

distributionUrl=https\://services.gradle.org/distributions/gradle-3.4.1-all.zip

新（gradle/wrapper/gradle-wrapper.properties）

distributionUrl=https\://services.gradle.org/distributions/gradle-5.1.1-all.zip

参考

エラーメッセージ

Could not determine Java version using executable /Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home/bin/java.

Could not determine Java version using executable /Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home/bin/java.

対策

stackoverflow.com

2. Kotlinのバージョンをあげる

Gradleの5系では、Kotlinのプログラムをビルドする際に利用する kotlin-gradle-plugin および kotlin-allopen のバージョンが1.1だと動きません。これを1.3系にあげます。

旧（build.gradle）

buildscript {
    ext {
        kotlinVersion = '1.1.3'
        springBootVersion = '1.5.3.RELEASE'
    }
...

新（build.gradle）

buildscript {
    ext {
        kotlinVersion = '1.3.11'
        springBootVersion = '1.5.3.RELEASE'
    }
...

参考

エラーメッセージ

Cause: invalid type code: 2F

まとめ

本の通りに進めないズボラはこういうとこで時間を使いますね。笑
でもGradleのことがちょっと理解できたのでハッピー！

it works!

OneDrive for Businessで組織名を変えた後の同期の挙動メモ

OneDrive for Businessでは、ローカルの同期対象フォルダの名前に組織名が入ります。
この組織名を変更した場合、同期の挙動はどうなるかをチェックしました。

1. 単に組織名を変更した場合

同期は問題なく続行します。その場合、ローカルの同期対象のフォルダ名に含まれる組織名は古いままです。

2. 組織名を変更した後にアカウントのリンクを解除＆再接続した場合

OneDriveアプリの設定からアカウント→このMacのリンクを解除、を選択します。
それからOneDriveのアプリを終了し、再起動してからアカウントを追加。

この時点でローカルの同期対象フォルダの名前を新しい組織名に差し替えます。すると、「このフォルダーにはすでにコンテンツが存在します」という警告が発生。

構わず同期を進めると、その後ローカルとクラウド上のファイルの差分チェックが走るようです。
だいたい１秒あたり１件のペース。

結論から言うと、組織名を変更した場合でも、ローカルとの同期を全てやり直すような仕様にはなっていませんでした。

自炊漫画をiPhoneで読むならOneDrive for Business + ComicShareが最強

自炊した漫画のZIPファイルをiPhoneで快適に読む方法を模索した結果、 OneDrive for Business + ComicShare が最強という結論に至りました。 ただし、「年間10000円程度なら出費できる」「必要なストレージのサイズが1TBを超えている」が前提です。そうでない場合はDropBoxの有料プランの方がサポートしているアプリが多くていいかもですね。

NAS vs OneDrive for Business

自前のHDDのメンテにかける時間・費用を考えると、年間10000円程度で全部やってくれるOneDrive for Businessに軍配が上がりました。クラウドストレージは他にもありますが、以下の点でOneDrive for Businessが優勝しました。
1. ローカルHDDとの双方向の同期（これがGoogleDriveにはできない）
2. 年額10000円で2TB（これがDropboxには足りない）
3. そこそこメジャーな漫画リーダーでサポートされている（単にバックアップが前提ならAmazonDriveや中国IT企業の大容量ストレージも対象になりえた。）

漫画リーダー

OneDrive fot Businessを使うならComicShare一択です。複数の主要クラウドストレージのサポート + 漫画リーダーとして必要な機能を兼ね備え、かつ継続的にメンテされています。
ComicGlassも好きなのですが、OneDirve for Businessはニッチだと思うのでサポートしてなくても仕方ない（というか、ComicShareのサポートが幅広い）

ComicShare -（コミック/電子書籍リーダー）

• yoshitaka haneda
• ブック
• ¥480
• 

以下は選評です。

漫画リーダー候補8つ

エアコミックス+

○ OneDrive Businessが接続できる
× ZIPファイルをストリーミングで読み込むとページの順番がバラバラになる

CloudReaders

× iPhone X対応していない

ComicGlass

○ ファイル名が見やすい ○ コミックス表紙のサムネイルが作成できる
× OneDrive Businessに接続できない
メモ: iOSのブラウズ機能をサポートせず、独自の方法で各種クラウドストレージに対応している。

ComicShare

○ OneDrive Businessに接続できる（しかもブラウズのサポートなし）
○ ストリーミングで読み込みできる

Documents

○ OneDrive Businessに接続できる
× ZIPファイルを（少なくとも見た目上は）解凍なしで表示することはできない
× ストリーミング読み込みはできない

MangaStreamCBR

× OneDrive Businessに接続できない

SideBooks

× OneDrive Businessに接続できない

漫画やテキスト

○ OneDrive Businessが接続できる
○ ZIPファイルの読み込みが高速（ストリーミングしているかどうかは謎）
△ ファイル名の表示数上限が少ないので、漫画タイトルが長いと巻数が見えない
× たまにファイルが読み込めない時がある。どうしてなのかはわからないが...
× ページが上下スクロールで固定

まとめ

年額10000円程度で2TBの自炊電子書籍をiPhoneからいつでも読みたいならOneDrive for Business + ComicShareが最強です。どうぞご参考に。

メルカリのみかんを60個バラ売りしてPaypayより現金の方が人気なことがわかった話

Paypayでみかん売ってみた

簡潔に

• コワーキングスペース内でメルカリみかんのバラ売りを始めた
• 2週間でPaypayでは4つしか売れなかったのに現金で61個売れた

あらすじ

justInCaseのメンバーがやたらナッツとかみかんを食べるので、自腹だと破産すると思って値段をつけることにしました。
せっかくなのでコワーキングスペース内でも販売して、しかもPaypayを使ってみた話です。

ちなみになんでPaypayなのか？

個人間送金用のQRコードを時間無制限(?)で出力できるウォレットアプリが観測範囲でPaypayしかなかったからです。
LINE PAYはQRコードに5分間の制限があります。また、PaypalはURLを生成できますが、100円の販売で40円以上の手数料がかかるので少額決済には向いてなさそうでした。
メルペイ〜〜〜！！！早く来て〜〜〜！！！！！

結果

第1ロット

12/12(水)~12/14(金)

みかん

14-16 有田みかん 5kg★家庭用（キズ等）★
* 推定40~50個、1799円
* 甘くて美味しい、おすすめ

売り上げ

• 初期だけ60円で売ってましたが、途中から30円に値下げしました。
  Paypay: 150円（3個）, 現金: 660円（22個）
  

  

  Paypay

現金

第2ロット

期間

12/17(月)~12/21(金)

みかん

減農薬☆ 農家直送♪ 足柄みかん10kg 加工ジュースなどに
* 72個2000円
* ちょっと酸っぱめ

売り上げ

Paypay: 30円（1個）, 現金: 1120円（37個）
* 100円で3つ買ってお釣り取らなかったっての豊田さんが言ってたので誤差はそれです。

分析

なんでPaypayを使わないのか？
ユーザーに聞いた感想は以下のような感じです。

• クーポンの500円が使えると思ったら友達間送金では使えなかったので面倒になって現金で払った(3人以上)
• 楽天銀行に対応していない(1人)
• ないしょ(1人)

もっと手軽に使えるといいんですけど。
ところで、Yahoo!ウォレットはめちゃめちゃ使いやすいですね。なんでわざわざPaypay作ったんだろう...?

まとめ

C2C取引の超少額決済プラットフォームは今のところどれもイマイチってことですね。現金以外。
メルペイ早く使ってみたいな〜〜〜。

おしまい。

AWS ソリューションアーキテクト試験に遅刻した話

「AWS 試験 遅刻」 「AWS 試験会場 間違えた」
これで検索された方、試験開始後15分までならまだ受験できます。もし間に合うなら急いでください！
受験のために15000円(+税)/プロフェッショナルなら30000円(+税)を払っているはずです。タクシー15分なら2000円以内ですから安い安い！

ここからは、私のように試験会場を間違えた人・間違えそうな人のための、ハマりどころ回避策になります。

1. 試験3日前のメールを見逃さない。

AWSの試験では、日時会場の変更が有料になる試験開始48時間前の１日前にメールを送ってくれます。 ここに書いてある受験情報がFix版です。会場までのアクセス方法もあるので読みましょう。

2. 逆に、申し込み時点のメールを目に届く場所に置かない

AWSの資格試験はいつでも日時場所が変更可能です。仕事のスケジュールに合わせて、私は受験まで３度ほど日時・場所を変更しました。この時、Googleカレンダーに登録した試験会場を変更しなかったのが仇になりました。
変更を含む申し込み時点のメールは、メーラーによってはスレッド形式で表示されます。となると、変更前の日時場所の方が目に入ることもありえます。

試験３日前を過ぎたら申し込み時点のメールはピン留めを外す・既読するなどして、確認メールを信頼するようにしましょう。

以上、こんなミスをするのは自分くらいかもしれませんが、これ以上悲しい思いをする人が出ませんように...。