読者です 読者をやめる 読者になる 読者になる

親指しふたーとさくらとゆずと

例えば、で文章を始めるのが好きだ。

例えば、桜が咲いている。

例えば、小鳥がさえずっている。

例えば、例えばで文章を始めるのが好きなあなただとしよう。

想像してほしい。あなたがもし「例えば」で文章を始めるのが好きなひとりの冴えない20歳だったとして。

例えば、手紙を書いてみたらどうだろうか?

メタファーで一杯になってしまってその手紙はきっと捨てられるだろう。

メタファーにはふつう受け皿が必要だ。

こんなことばっかり書いてるから技術系はQiitaに移動させなきゃなんなくなるんだ

"Team Geek"を読んだ感想

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

HRTについて

一貫して「HRT」が引き合いに出され、それを土台にしたチーム作り/うまくやる技法について書かれている。

内容とは関係のないことだが、最初に鍵となる概念を提示してそれを基本と一貫して話を続けるのは、わかりやすさという点でも、興味を引くという点でもかなり効果的な技法であると思うが、難しいことだと思う。それにそぐわないことの多くは排除しなければならないから。

最初の「実践HRT」でHRTの基本を学んだときは、HRT的なコミュニケーション方法には懐疑的だった。だって「この部分はxyzzyコードパターンを使ったほうがわかりやすい」と言えば良いものを、「この部分の制御フローがよくわからないのですが、xyzzyコードパターンを使えば読みやすくなるでしょうか?」と伝えるなんて、回りくどすぎる! 自分がそういうのが嫌というよりは、そんな伝え方をされた時にイライラしそうな感じがした。

そんな自分の疑問には答えることなく話はどんどん進むのだが、読んでいるうちにだんだんとHRTに洗脳されていく。

もう少し具体的に言えば、「HRTはコードレビューのときのみ効果を発揮するものではない。全ての人間関係に適応されうるものだ」ということが感覚で理解できるようになってくる。

いや、それは明確に最初の方にも最後の方にも書いてあるのだけれど、いくつもの例を考えていくうちに「HRTを使うべきだ」というのが刷り込まれていく、感覚。

すごく情緒的に書いてしまっているんだけれども、本当にそういう感覚が身についていく実感が読んでいる途中にある。

けものフレンズと同じで、人を優しくする本だと思う。

チームリーディングについて

この本は全体的に、基本は「HRTをどう適用するのがいいのか」というのがいろいろな視点から描かれているものなんだけれども、チームリーディングのところで印象に残ったことを適当に書く。

このパートで重要なことは「エンジニアを大人として扱うこと」。

伝統的なマネージャーはどうやって仕事を完了させるか考える。リーダーは何ができるかを考える…(どうやって仕事を完了させるかはチームに考えてもらう)

また、良いチームのために最重要な「文化」も、チームリーダーが作るのではなく、メンバーが作るものだ。

リーダーは一人のメンバーに文化が支配されないように気をつけながら、チームを陰ながら導いていく。

気になったこと

  • 「みんなの友達になる」や「自信をなくす」ことと、HRTは非常に取り違えやすいと思った。確かに「尊重する」という意味では友達になることに近いかもしれないが、もっと重要なことだけ切り出している。友達は失っても、尊重は失ってはならない。
  • 「明確な意思決定をせずに成り行きに任せるチーム」と「合意ベースのチーム」も非常に取り違えやすい、というか見間違えやすいと感じた。とくに「日本的」な文化が見える会議等では、それが本当に全員の合意なのか、成り行きで出た結論なのかわからないということがある。そうでなくとも、全ての決定について独断がないかと考えるとそこは本当に難しいことだと気づく。
  • 設計書は退屈なイメージがある。設計書通りに書くコードも退屈なイメージがある。でも設計せずに書き始めると、何度もスクラッチから書き直すということは起きる。設計書で解決するかはわからないけど。

その他印象的だった文章

  • 自分の意見を主張するときは、その前に相手の話を聞くようにしよう。ころころ意見を変えると、優柔不断なヤツだとおもわれてしまう

  • エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決するのを手伝ってほしいからだ。

  • 簡単にできそうなことをするよりも、できそうもないことに挑戦して失敗するほうが道は開けるはずだ

総括

なんかとんでもなく適当に書いたようなレビュー記事になってしまった。全体的に「方法論」としてかいてあり、部分部分ではいろいろと思うことがあるのだが、全体としてまとめようとするとうまく行かなかった。

結構納得しながらすらすら読むことができる本なのだが、恐らく全部完璧にできている人はいないだろう。なので定期的に読み返し自分の行動を反省していきたいな、と思った本だった。

Go言語でGoogle Cloud SDKを使うときApplication Default CredentialsのJSONファイルをパスではなく文字列で渡す方法

状況

Google Cloud Vision APIをGo言語で使うとき、公式のライブラリがあったのでそれを使っていたら、どんなAPIを叩くにもApplication Default Credentialsが必要だという。Vision APIREST APIから直接叩くにはAPI Keyだけで良いというのに、ライブラリを使うならService Accountが必要。わけわからん(実はライブラリ/依存ライブラリのソースの至るところに"This API is Beta"と書いてあるので今後変更される可能性がある)。

プルリク送ろうとも思ったが、膨大すぎて読みきれなかった/設計の意図を汲み取りきれなかったために断念。おとなしくService Accountを使うことにしたが、Herokuで運用する予定のためJSONファイルをリポジトリ内に置くのはNG。実は先のURLに書いてあるとおり、Application Default CredentialsはキーのJSONファイルのパスを環境変数として指定する方法しかサポートしていない。これは困った。さすがに環境変数で文字列を受け取りそれをファイルに書き込んでからパスで指定するとかしたくない。と思い4時間ソース読んだり試行錯誤したりした先で、やっとこのStack Over Flowを見つけた。

Load GOOGLE_APPLICATION_CREDENTIALS json content via an environment variable instead of a file · Issue #185 · google/google-api-go-client

このページに(ほぼ)内部APIを使ってJSONを変数から読み込みパースし、TokenSource(内部で使われる認証情報を含む構造体)を作るコードが載ってる。

これを参考に(ほぼそのまんまだけど)以下のような感じでいけた。

json := os.Getenv("GOOGLE_APPLICATION_CREDENTIALS_JSON")
ctx := context.Background()
jwtConfig, err := google.JWTConfigFromJSON([]byte(json), vision.Scope)
if err != nil {
    fmt.Println(err)
}
ts := jwtConfig.TokenSource(ctx)
visionClient, err := vision.NewClient(ctx, option.WithTokenSource(ts))

彼はこの世界にいる人間じゃない。

神様は僕達に奇妙な色仕掛けを残していった。…残していったのは、友達だけど。

そんな詩的なのかそうじゃないのかもよくわからない文章をブログの一行目に書きなぐってしまうくらい、今日は複雑な気分でいる。

明るい話題「それは本当に嬉しいことだね」と先輩は言った。嬉しい。

嬉しいけど、正直嬉しくはない。

僕は彼を敵とは思っていない。彼は本当に心から僕といっしょに活動をしてくれているみたいだし、そんなこと思えない。

ただ、でも、明確に諦めている部分もあった。彼はいなくなる運命なのだから、彼に頼んではいけないことと、頼んで良いことをしっかり線引きしてから付き合っていた。

もうひとつある。彼はそのプレゼントを、職人の本性、つまり、ある意味本能的な部分を根源として、原動力として手作りしてくれたということだ。

共感できる。共感できた。

でも共感するとき、不安にならないだろうか? そこに優しさや怒りは本当になかったのか? 誰かのあたたかみがそれに挟まってはいないか? 本当に、本当にそれだけなのか???

本来それは信じられないことなのだ。本来それは物語の中でしか享受できない、僕の人生経験が無いだけと笑われるかもしれないが、そんなことがあって良いのだろうか。というか、あるのか?

信じられるか? 神様を信仰するとき、そこに見返りは無いとしても最後まであなたは手を何の疑問も抱かず手を合わせ続けられるだろうか。ありえない。誰かのメリットや自分の受ける利害を思い描いてこそ、手を合わせ続けられる。

それなしにできた結晶が、そんなに透明なものがこの現実の世界にあると思ってしまって良いのだろうか。

僕は信じられない。嬉しくない。悲しくは…ある。寂しくもある。やるせない。取り返しがつかない。

僕はきっと、その結晶に触れられない。

野獣のように叫びながら、そこに手を伸ばすことさえできずただ涙を流すしか無い。そして

ありがとう。

そう言うんだ。それしか、この涙を形容する方法がないから。

彼は消えたんだ。

コメントを英語で書くときに注意するべきこと

API ドキュメント作成ガイドライン | Rails ガイド」がすごくいい

API ドキュメント作成ガイドライン | Rails ガイド

Rails/Ruby以外にも通用すると思う。

すごく参考になった。

チャットボット開発のためのライブラリをGoで書いた話

Chatroomといいます。

github.com

これはAizu Advent Calendarの16日目の記事です。(遅れてすみません)

動機

これまでだと、リクエストが来るたびに該当ユーザーのState情報を取り出し、今の文脈で条件分岐して返答、State情報の更新という一連の流れを行っていたと思います。

これはチャットボットのバックエンドとして基本的なものであり、大規模なものにも必ず含まれているロジックです。

しかし、チャットボットブームと言える今の時代、ネタや実験的に軽くチャットボットを作成したいという需要もあります。

そういったときに毎度State管理から実装するのはちょっと面倒...ということで、このライブラリを作成しました。

で、具体的には?

こんな感じでチャットボットのロジック部分が書けます。

今までだとState管理が必要だった対話的なUIが、State的な部分を意識せずに書けていることがおわかりでしょうか。

しかし実際のコードはこれだけではなく、もっとあります。

というのも、Chatroomは以下の面倒を見てくれません。

  • ユーザーごとの情報の保存(State)
  • LINEやFacebookといったチャットサービスAPIとの通信
  • ユーザーID等による処理の分岐

話が違うじゃねぇか!という声が聞こえてきそうですが、Chatroomがやってくれるのは以下だけです。

  • トリガとなるメッセージごとのモジュール(Topic)の呼び出し
  • Topicへのメッセージの配送・受け取り

上記以外のことは自分で実装する必要があります。(もう少し詳しいことがREADMEに書いてあるよ!)

まとめ

このライブラリで中規模程度のチャットボットも書いていますのでちょっと使ってみてくださると嬉しいです。

(はやくAPI Reference書かなきゃ)

2016/12/28追記: 書いたよ。

地元の人に聞いた平日夜に熱海で日帰り入浴できる場所3つ

- 大湯温泉

- 駅前温泉

- 福島屋

だけらしい。ホテルはもう宿泊客向けのみになってて、それ以外の日帰り温泉は16時ころで終業。福島屋がよさげだけどその日は休業してたので駅前温泉に行った。

 

すごく熱かった。さすが熱海←

 

ありがとう八百屋のおばさん。