GAE/Go 2nd genでのFirebase Authの注意点 – timakin – Medium
これは本当に軽微なメモなんですが、GAEでGo1.11を使うために移行をしたことで、認証が動かなくなっていることに気づくのが遅れてしまいました。他の人がそうならないように記録しておきます。 これまで仮にGAE/GoでFirebaseの認証機構を使っていたとして、今までだとGAE/GoでのFirebaseクライアントの初期化はこのようにすればよかった。 もっと詳細に書くと、AppEngineのcontextを含んだ状態でurlfetchを呼び出してさえいれば、Firebaseのサービスアカウントの情報を明示的に指定しなくてもよかった。 opt := option.WithHTTPClient(urlfetch.Client(ctx)) app, err := firebase.NewApp(ctx, nil, opt) if err != nil { ... }これからGAE/Goが2nd
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
エンジニアはどのように他のアプリのUXを参考にすべきか
問題意識エンジニアのタイプを分けるとき、大雑把に「サービス志向」と「技術志向」みたいな分け方をすることが、僕の周りではよくあります。 個人的にはこの分け方は必ずしも良いものとは言えないと思います。少しエンジニアのことをサービスと距離のある人種として捉えてるように感じるからです。 技術志向だからってサービスのことを考えてないということではなく、「よりセキュアな技術を採用する」「効率的で安全なデプロイができるフローを構築する」などなど、技術向上を通じてユーザー体験をよくしよう、としているはずです。 ただ、デザインを良くしたり読み込みスピードを早くしたりなど、「目に見える範囲で改善する施策」を考え、実行しなければ、プロデューサー的な人からすれば「何やってんだろうな〜」と、エンジニアはブラックボックス的な人に見えてしまうこともあると思います。 じゃあ他のアプリをいじってみたりして、サービス勘みたい
Goでサーバーレス動画変換
概要よくGoogle App Engineに関する記事を書くのですが、今回はAWSです。 APIサーバーでGoを使うことももちろんありますが、他にもgo-apexでLambdaファンクションを書く場面というのもあると思います。 以前go-apexのdeployについての記事を書いたので、それは下記を別途ご覧ください。 今回はElastic Transcoder(動画のエンコーダ)を例にサーバーレスにGoが役立つ実例を紹介します。 やりたいことS3に動画をアップロードするアップロードの通知を元にlambdaが呼ばれるElasticTranscoderを呼ぶエンコード結果をS3に保存するというフローです。今回扱うのは、3の部分です。1,2,4の部分は別途AWSの設定が必要で、個人的にはterraformでやるべきだと思っています。 go-apexでのエンコード処理まずlambdaの中で真っ先に
GAEでプロジェクト間 or ローカルにDatastoreのデータをコピーする
ほんの些細な見た目の違いで、「UI良さげだな〜」という思い込みが崩れることがあります。 エンジニアは、最適なユーザー体験を実現するべく、その錯覚をローカル開発の時点から目指すべきです。 以前、自分でGo製のDBレプリケーションツールを作成して、この問題を解決しました。 ですが、最近AppEngineを触ってる自分からすると、果たしてどうやればデータをコピーできるのか、ましてやDatastoreともなるとMySQLとかと違ってインターフェースが違うのでは、困る！と思っていました。 しかし、AppEngineでDatastoreを使っている場合、これは非常に簡単に解消可能な問題でした。 事前準備Remote APIの有効化事前準備として、AppEngineのRemote APIというものに対して、アクセスする窓口を作る必要があります。API経由でDatastoreを叩くためです。 今回はGoの
はじめてのPodcastと、高まり
yatteiki.fmの登場によっていくらかpodcastを始める方を確認していて、元からpodcast形式で何か話すというのをやってみたかったのもあり、k0kubunくんを呼んでやることとしました。 今後も技術ネタに限らず、こういうサービスが流行っているよね、というようなテック業界全般の話をしていければなと思っています。どちらかというと開発者向けと言い切るよりも、業界の人みんなが聞けるようなものにしたいなと思っています。 はじめてのPodcastということもあって、反省や感想等をメモしておくのが今後Podcastをやる方にとっても良いかなと思い、以下に書き連ねていきます。ベースとなるノウハウの面はだいぶr7kamuraさんの記事にまとまっているので、そちらをご参照ください。私が書く内容は、これの追加情報となるところが多いです。
人がやるべきではない仕事。一人のエンジニアとして。
Medium開き。はてなで自分用のブログを持っているけど、urlとかidとかがおかしいし、直したいのに直せないので、こっちに移ることにした。 僕がやるべきではないと思った仕事まず断りを入れておくと、仕事と言っても、職場の話ではない。 GoとかReduxとかReactとか、NodeとかRailsとか、OSSで見ておかなきゃなーと思った公式リポジトリをフォローした時の話。 僕は割とOSSにバンバンコミットするぜ、みたいなことに憧れつつも、なかなか自分だけのソフトウェアを作ってしまう性格で、それを治したいと思っていた。 とりあえず手始めに、各リポジトリをフォローして、各言語やソフトウェアがどんな課題を感じているのか、調べることにしようと思った。 その時に問題が発生して、なんとスパムのようにNotifyメールが来る。どれくらい凄いかというと、特にReduxなんだけど、日本時間で深夜３時くらいに、３
やっぱブロックチェーンダメっぽい
デジタル台帳「ブロックチェーン」が支える仮想通貨ビットコインを何百万人にも紹介したステファン・トーマス氏は、心変わりした。 この記事、最初見たとき釣りかと思ったけど、釣りではなく「まあそうだよね」と言う意見だった。 ここで言われてるのは 金融機関の政治問題合意形成コストの２つが課題でブロックチェーンが実戦に不向き的なこと。 １個目は人の問題なので置いとくとして、２個目が散々。 計算にマシンパワーが必要なのと、その結果を全ノードに等しく伝えるのに何日もかかる & その過程で生じた履歴がもし採用されなかったら破棄される可能性もある。 これらの点から「速くて、堅牢な、低コストの取引台帳」なんてものはないの明らかなので、登壇テーマとして用いた身なのを棚に上げながら言うと、すぐさまこの界隈は沈静化してほしい。 ハッシュ値を最も早く生成し、その結果その解答者以外の履歴はあっていようが間違っていようが場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GAE/Goでdeploy直後500 Server Errorが出た時に見る場所
MediumのポストをMarkdownで書くためのCLIツール、「md2mid」作った