えいのうにっき

a-knowの日記です

GAE/Go で gomniauth を使う

最近また Google App Engine をやっている。

cloud.google.com

できるだけ面倒なことはしたくないんだけど、作ろうとしているものの性質上、ログイン機能は外せず...。。『Go言語によるWebアプリケーション開発』の学習でも使った stretchr/gomniauth を使って同じように実装してみると、http.DefaultTransport and http.DefaultClient are not available in App Engine. See https://cloud.google.com/appengine/docs/go/urlfetch/ といったエラーが。urlfetch ... あー。

GAEから外部APIへリクエストをするためには、専用パッケージである urlfetch を使う必要がある。

自分で実装してる部分の話なら素直に urlfetch を使えばいいだけなんだけど、今回のエラーは gomniauth の部分で出てるエラーなので、なんとかして gomniauth の使うクライアントを差し替えてやる必要がある。

gomniauth のリポジトリを少し漁ってみたところ、いいコミット(コミットメッセージ)があった。

Support for Google AppEngine urlfetch for OAuth2

To use http in Google AppEngine, you have to use urlfetch, not the normal default http client or RoundTripper. So similar to what one of the forks of goauth2 did, this adds the ability via the now-added common/SetRoundTripper to pass in the specific RoundTripper to use. If unset, the default net/http one will be used. However, by calling this method, you can pass in your own including one created via urlfetch. Here is sample code showing it in use:

https://github.com/stretchr/gomniauth/commit/3e2e23995b035e26bbd58a0f56cb2b2d61dbe993#diff-faa162d8416db3f39bdfe91ca8eea4de

上のコミットメッセージに付記されていた実装例は以下。

import (
  "appengine"
  "github.com/stretchr/gomniauth/common"
)

func SomeGolangFunc([...,] r *http.Request [,...]) {
  c := appengine.NewContext(r)
  t := new(urlfetch.Transport)
  t.Context = c
  common.SetRoundTripper(t)

  // Do something interesting here
}

これを参考に自分の実装も手直ししてみたところ、うまくいった。よかった。

上記のコミットメッセージには、以下のような注意点も加えて書かれていたので、この点は気をつけておいたほうがよさそう。

Note that common.SetRoundTripper may have to be called in the GAE server before every request, versus trying to do it once because of the appengine.Context being passed in. Pretty sure you cannot pass in a nil *http.Request and re-use the context, so you can't make the call during the GAE init() method.

今回の件にあたり、いろいろとググったりもしてみたところ、gomniauth に限らず、いろんな実装でこうした配慮がされてそうなので、このまま安心して実装を続けていけそう。

デブサミ2018で登壇してきました #devsumi

今月15日・16日と二日間に渡って開催された、「デブサミ」こと Developers Summit 2018 にて登壇、発表をしてきました。タイトルは、「自分」をまるごと活かす!私が“CRE”というキャリアを選んだ理由

資料は以下です。

speakerdeck.com

今回の発表で「伝えたい」「これを機に改めて考えてみてほしいな」と思っていたことは、以下のようなこと。

  • 「自分を活かす」とは言うけれど、そもそも「自分」ってどんな存在なんだろうね。考えてみよう
  • 僕が "CRE" という仕事を選び、今もなおその仕事をしている理由は、○○だからです
  • "僕" や "CRE" に限らず、「自分を活かす」ことのできる仕事に出くわすためにできそうなことってなんだろう

また、「今後、僕がやっていきたい・やっていかなければいけないと考えていること」についても、この場を借りて宣言させてもらえたなーとも思ってます。本当にありがとうございます。

"CRE" という職種がはてなに誕生したときのブログ記事( セールスエンジニア 改め Customer Reliability Engineer (CRE) になりました - Hatena Developer Blog )や、CRE職の採用ページ( CRE (Customer Reliability Engineer) 職 採用 - 採用情報 - 株式会社はてな )は、基本的にどちらも僕が書かせてもらったものなんですけど、ちょうど、今回のデブサミの登壇者募集が始まったくらいの時期に、「(これらの)ページに書いてあることを見て、これだ!って思ったんです」と声を掛けてもらえることがあって。これが、うまく言えないんですけど、僕の中の何かスイッチが入った感じがするような、僕にとってすごく大きな出来事だったなぁと思っています。このことがなかったら多分、デブサミに応募してみよう、とも思えなかったはず。

そして今日も、びっくりするくらいのたくさんの方々に、Ask the speaker コーナー(登壇者に質問ができるコーナー)に来ていただいて、そのときと同じような感覚を覚えました。(なんかもうへろへろで、みなさんとうまくお話できなかった......ごめんなさい!) お世辞にもきれいにまとまったとは言えない資料・発表だったとは思うのですが、それでも何かしら感じるところを持ってもらえることができて、とてもうれしいです。

思えば、CRE職の前身であるセールスエンジニア職からの職種の変更のきっかけをくれたのは、上司であり先輩であり同僚でもある id:Songmu さんでした。感謝しきれませんし、この御礼はこの先一緒に仕事をしていく中で返していければと思っています。

また今回、本番に向けた発表の練習をするにあたり、「第三者の目線からの意見が欲しい」という僕のわがままに答えていただき、率直な感想、指摘をくれた id:kakku22 さんには、とても感謝しています。カックさんのおかげで、今回の発表に使った資料の出来は数倍は良くなったと思っています。

そしてもちろん、他にもたくさんの素敵なセッションがあったなか僕のセッションを聞きに来てくださったみなさま、デブサミという場を提供してくださったみなさまにも、心から感謝しています。本当にありがとうございました!

f:id:a-know:20180216091917j:plain

ふりかえり や KPT などのファシリテーターをやるときに意識していること

前職ではスクラムマスター的な立ち回りをしていたり、今でもたまにファシリテーターを頼まれることがあったりするので、そのときに気をつけてることをちょっとメモしてみる。どちらかというと経験則に近いかんじ。

  • その場にいる、できるだけ多くの人に話をしてもらえるようにする
  • ある事象について、「それを知ってそうな・知らなそうな人」「その場にいた人・いなかった人」に意識をフォーカスして掘り下げる
  • 「なぜ・どうして」や「どのようにして」、そして「どうあるべきか」にフォーカスする
  • (そもそもの話)できるだけ当事者じゃない人がファシリテートするのがよい

なんかもっとある気がするので思い出したら追記します。

続きを読む