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 (ユーザーへの要求)として、いくつか項目があげられるのがわかると思います。

したがって、 gcloudgoogle-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です。

...なんで awsclibrew なのに、 gcloudbrew 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の中身がよく分からない
・変数を参照するときに後ろから修飾できるやつ、多機能でよく分からない
・標準出力と標準エラー出力をつなぐやつ意味分からない
・関数とコマンドがどうやら違うものらしい
・サブプロセスがよく分からない
1つのことをやるのにやり方が多い気がする。それに、どこまで勉強すべきなの?

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!

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

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

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

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

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

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

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

https://inkdrop-uploads.s3.amazonaws.com/attachments/user-58863d24a941f8d79228116637b079d7/file:UV-mZlyV5/index-public

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

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

自炊漫画を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のサポートが幅広い)

以下は選評です。

f:id:hiroga_cc:20190102104834j:plain
漫画リーダー候補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が最強です。どうぞご参考に。