さわらブログ

さわら（@xhiroga）の技術ブログ

「あとで読む」を読む @ 2019-06-03

f:id:hiroga_cc:20190529163402p:plain

フォトグラメトリで小笠原

スマホの複数の写真とWindowsの専用ソフトでできるらしい。

React Nativeのテストライブラリ選定

tech.kitchhike.com * グレーボックステストって初めて聞いたけど、要はブラックボックステストを、内部仕様に基づいて改良したものだと思えば良さそうだ。
* avaって初めて聞いた！いつもmochaばっかり使ってるから、次は使ってみようかしら。

Lambda LayersをCIでキャッシュした取り組み

dev.classmethod.jp * そもそもLamdba Layersについてようやくキャッチアップ。要するに、Lambdaの特定のパスに展開するオブジェクトを別途指定できるようだ。

微妙エンジニア

tkot.hatenablog.com "最新のサービスを使うことしか頭にない" サーセン！！！！！コスパもっと意識していこう

コンテナ運用のおすすめの方法

cloud.google.com * 便利なエンドポイントをどんどん生やそう！（メトリクスとかヘルスチェックとか）
* WebPageを作るときにも、本番ページにテスト用のページを追加しておいて、デバッグ時はそこにアクセスしてもらう、とか聞いたことがある。APIサーバーでも同じことか。

あなたの知らない詐欺グラフの世界

note.mu * 棒グラフとはその面積で意味をもたせるグラフです

SAMを通してCodeDeploy

dev.classmethod.jp 本格的なCIの構築ができる！というより、SAMだけでパッとCIまで構築できる！というのが強みと見た。

任意聴取の隠し撮り音声

* 2019年から取り調べの可視化が義務付けられるのをそもそも知らなかった * その対象が重大事件のみ、かつ強制捜査？に限られるのも知らなかった * 全部録音しろよ...

Web系エンジニア

ogihara-ryo.github.io 私の身の回りは、働き方の自由さより、将来起業する上でエンジニア通っておこう、って人が多い気がする。

さわらが「あとで読む」を読んだブログ @2019-05-29

f:id:hiroga_cc:20190529163402p:plain
「あとで読む」を読む

三菱UFJ銀行がIDaaS始める

r.nikkei.com

リアルOAuth2.0じゃん。かっこい〜
ちなみに金融系サービスの本人確認のことをKYC（Know Your Customer）っていうらしい

セッションとトークンの違い

norikone.hatenablog.com

  • セッションはID、トークンはJSON。だからトークンのほうが情報量が多い。
  • セッションを使う場合はサーバー側にセッション情報を持つ。トークンの場合は持たない...これって本質的な違いじゃなくない？トークンでもアプリ側でステート持ち始めたら同じでしょ？

量子コンピューターのアルゴリズムの話

mag.japaaan.com

量子コンピューターってまだ実用化はされてないよね？と思ったら、文中に書いてあって納得した、
これは、「実用的な量子コンピュータができたとしたら」という仮定に基づいた、とても数学的で抽象的な分野の研究です。今はまだ理論のみに留まっていますが、やがて量子コンピュータのハードウェアが実現し、この研究が目に見える形で役立つ日がやってくることを期待しています。

Yahoo!Japanはオンプレなのでk8sが大変ありがたいらしい

speakerdeck.com

  • スライド可愛くない？
  • コンテナオーケストレーションツール、SwarmとMesosがk8sと同じポジションのソフトウェアなのね。理解

AWSの3Dインフラマップ

infrastructure.aws ぬるぬる動いて楽しい！！！

クラメソさんのサーバレス開発部の知見

speakerdeck.com パラメータストアの使い方勉強になる

k8s関連ツールをAWSでいい感じに使う kops編

aws.amazon.com いろんなツールがあるんだね。そのうちお世話になります。

AWS Innovate なんてあったの！？今知った悔しい

dev.classmethod.jp よさげなアーキテクチャの資料をまるっともらえるだけで羨ましい

オーストラリア初のゲーム、Necrobarista

www.4gamer.net ピングドラムっぽいなと一瞬だけ思った

Karate入門

qiita.com もともとRubyでCucumberっていうE2Eテストツールがあって、それのJava実装プラスアルファ、DSLで書けるのが特徴、と。

浅田真央選手のインタビュー

www.asahi.com この人も僕の2コ上だ。こんな大変そうだって思わなかった、本とか読んでみようかな。

macOSにHomebrewでgcloudコマンドをインストールしたらタブ補完が効かなかった時のメモ

TL;DR

こちらのQiita記事を参考にしました。
（記事中にタブ補完について言及がなかったので私もブログを書いている次第です） qiita.com

解説

brew ないし brew cask では、インストールしたパッケージについての情報を参照するコマンドがあります。 例えば awscli だと...

$ brew info awscli
awscli: stable 1.16.130 (bottled), HEAD
Official Amazon AWS command-line interface
https://aws.amazon.com/cli/
/usr/local/Cellar/awscli/1.16.130 (5,272 files, 49MB) *
  Poured from bottle on 2019-04-05 at 18:05:00
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/awscli.rb
==> Dependencies
Required: python ✔
==> Options
--HEAD
    Install HEAD version
==> Caveats
The "examples" directory has been installed to:
  /usr/local/share/awscli/examples

Bash completion has been installed to:
  /usr/local/etc/bash_completion.d

zsh completions and functions have been installed to:
  /usr/local/share/zsh/site-functions
==> Analytics
install: 51,155 (30 days), 172,572 (90 days), 663,663 (365 days)
install_on_request: 48,269 (30 days), 161,871 (90 days), 601,401 (365 days)
build_error: 0 (30 days)

Caveats （ユーザーへの要求）として、いくつか項目があげられるのがわかると思います。

したがって、 gcloud（ google-cloud-sdk ）のinfoを参照すると...

brew cask info google-cloud-sdk
google-cloud-sdk: latest
https://cloud.google.com/sdk/
/usr/local/Caskroom/google-cloud-sdk/latest (20,446 files, 281.3MB)
From: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/google-cloud-sdk.rb
==> Name
Google Cloud SDK
==> Artifacts
google-cloud-sdk/install.sh (Installer)
google-cloud-sdk/bin/bq (Binary)
google-cloud-sdk/bin/docker-credential-gcloud (Binary)
google-cloud-sdk/bin/gcloud (Binary)
google-cloud-sdk/bin/git-credential-gcloud.sh (Binary)
google-cloud-sdk/bin/gsutil (Binary)
==> Caveats
google-cloud-sdk is installed at /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk. Add your profile:

  for bash users
    source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc'
    source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc'

  for zsh users
    source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc'
    source '/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.zsh.inc'

あとは Conveats の記述に従って .bashrc （タブ補完は対話実行に関わる設定だから .bash_profile じゃなくて.bashc ですね。毎回迷う。）を設定すればOKです。

...なんで awscli は brew なのに、 gcloud は brew cask なんだろう...?

BitBucketの"Please make sure you have the correct access rights and the repository exists." と戦うのをやめてHTTPS接続にした

以下のエラーに対してトラブルシューティングを試みたのですが、どうもうまくいかないのでSSH接続を諦めました。

$ git pull
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

やったこと

1. ssh接続の確認

ssh -v git@bitbucket.org
~~~
You can use git or hg to connect to Bitbucket. Shell access is disabled.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to bitbucket.org closed.
Transferred: sent 2988, received 1860 bytes, in 0.4 seconds
Bytes per second: sent 7712.1, received 4800.7
debug1: Exit status 0

2. remoteのurl の形式の確認

× git@bitbucket.org:{USER_NAME}/{REPOSITORY_NAME}.git
× ssh://git@bitbucket.org/{USER_NAME}/{REPOSITORY_NAME}.git

どうにもならなかったので

素直にHTTPS接続にしました。

git remote remove origin
git remote add origin https://{USER_NAME}@bitbucket.org/{USER_NAME}/{REPOSITORY_NAME}.git
git fetch

悔しい...!

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

本当これ。

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

まとめ

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

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

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

それから、ご飯は期待通りめっちゃ美味しかったです！！！！！ f:id:hiroga_cc:20190227221213j:plain

エンジニア歴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アプリケーション 新しいサーバサイドプログラミング

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.

f:id:hiroga_cc:20190124064517p:plain
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のことがちょっと理解できたのでハッピー！

f:id:hiroga_cc:20190124072311p:plain
it works!