GAE (Google App Engine) でgolangのアプリケーション開発する際のベストプラクティス

Google App EnginegolangAPIを開発する際のベストプラクティス

 

現段階でGAE上で手軽なAPIを開発する際のベストプラクティスを記録しておきます。

 

あくまで現段階なので今後変わっていく可能性はありますが・・・more betterな方法しっている方いたら教えてください。

 

ディレクトリ構成

neipis.hatenadiary.com

 

以前の記事の構成で良さそう、しかし、vendorディレクトリの中にsym linkをおいてしまうとdep ensureするたびに消えちゃうのが悩みどころ・・・。

 

deploy周りをシェルスクリプトで自動化すればOKだけど、あんまりイケてない・・・・。このあたりどうするのがベストなんですかね・・・?

 

APIの記述はできるだけnet/httpのhandlerFunc準拠にしておく

これはGCPに限らずgolangAPI開発を行う際は重要なポイント。なんだかんだで公式のnet/httpの出来がいいので、それに則って開発をした方がいいです・・・。

neipis.hatenadiary.com

 で比較して見たけど結局WAFいらなくね・・・・?って気がしています。

 

各種GCPのサービスと連携するには?

各種GCPのサービス (GAEのlog機能やdatastore、cloudstorage) と連携する際には、appengineを利用して生成したcontextを関数の引数として渡す必要があります。例えばロギングではあれば以下のようになります。

gist.github.com

handlerFuncの冒頭でappengine準拠のcontextを生成=>各種ロジックにcontextを渡すという流れの実装がいいかと思います。

 

GAEべったりですが、割り切ったほうがもはや効率が良さそう・・・・。

 

GCPべったりの実装にした場合、Local Development Serverを使う

上記のような実装にした場合、Local Development Serverを利用してローカルでの開発やテストを行う必要があります、

 

Local Development Serverを利用しないと、not an App Engine contextと怒られるので・・・。

 

めんどくさいですが現状割り切ってます・・・。他にいい方法あったら教えてほしいです。


Local Development Sererの起動は以下のコマンド。

dev_appserver.py app.yaml
dev_appserver.py app.yaml --port=1323 //port指定する場合

デプロイは以下のコマンドです。

gcloud app deploy

忘れないうちにメモメモ。

 

GCPのdefault credentialsの設定

新しい環境でgolangGCP、GAEアプリを利用した場合、このようなエラーが発生する場合があります。

$ dialing: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

対処法は以下のコマンド

$ gcloud auth application-default login

以下のコマンドじゃだめっぽい。

$ glouad auth login

メンタルやばい!と思ったときに重要な対策まとめ

本記事では、メンヘラのサラブレッドとも呼ばれたことのある私が、日々の生活でメンタルを守るために気をつけてきたことを書きます。

そもそもメンタルヘルスについて思うこと 

これは個人的な考えなので鵜呑みにしないでほしいのですが、一般にメンタルヘルスというのは、ただの健康管理です。体調不良と一緒です。

 

体の不調に対しては敏感でも、心の不調には気を使わない人がいます。体の不調は熱や咳など、見てわかる症状として現れてくることが多いのに対して、精神的な不調はとらえどころがないからだと思いますが、基本的に両者は同じです。

 

言えることは、疲れたら休む、どうしようもないなら病院にいく。それだけです。職場の人間関係などメンタルの原因だと思われるあれやこれやはひとまずおいてまず休みましょう。それらの解決より休む方が現実的で確実で簡単です。

 

というわけで本記事では、メンタルやばい!と思ったときの休み方と回復するときにいいと思った方法を紹介します。

 

基礎編

やばいと思ったら休む。

すべてを放り出して休む

これが一番大事です。メンタルやばい、つらい、無理、と思ったら。もし本当にやばいと思ったら。すべてを放り出してきっぱり休むことです。

 

ここで休めるかどうかで長い人生でのメンタル面の生存確率が大きく変わります。

 

〇〇しないといけない、〇〇してはいけないという人間の日々の義務感はほとんど全て思い込みです。自分の健康より優先すべき物事はこの世に存在しません。まず休んでから考えましょう。



とにかく寝る 

メンタルヘルスは脳の体調不良です。脳の体調不良はたいてい睡眠不足が引き金です。

 

休んだならすべてを放り出して、上司からの電話もtwitterからの通知もすべて無視して寝ましょう。

 

寝れるだけ寝ましょう。普段のあなたの平均的な睡眠時間以上に眠ることができたら最高です。

 

丸一日休むのが無理でも午前だけでも休む 

丸一日休むのが無理というときでも、なんとか午前休を取ってしっかり寝ましょう。

 

ある程度疲れが取れた状態で仕事に望めば、今までの自分がどれだけ疲れていたのかがわかるはずです。いつもなら頭が混乱して何も進まない作業がいくらか進むかもしれません。

 

その違いがわかれば、それだけでも大きな進歩です。まずは午前だけでもいいので休んでみましょう。そして最近の自分がどれだけ疲れていたのかを自覚しましょう。

 

中級編  

食事・運動・睡眠。

 

睡眠時間を確保する

 とにかく睡眠時間を確保しましょう。ストレス状態の時、寝付きが悪くなったり、夜中や朝早くに目が冷めたりしてしまうことがあるかもしれません。

 

それでもとにかく寝ましょう。普段のあなたの睡眠時間に達するまで寝ましょう。

 

どうしても寝ることができない日が続いた場合は、仕事より睡眠を優先して休んだり遅刻したりしてもいいのではないかと思います。睡眠不足だって続けば立派な体調不良です。

 

そんな事言われてもそもそも眠るのが難しい!という場合は以下のような対策が有用です。どれがあなたに当てはまるかはわかりませんが、試してみると案外気持ちよく眠れるかも知れません。

 

  • 温かいお風呂に入ってみる
  • 部屋の照明を蛍光灯からオレンジの電灯に変えてみる
  • ビタミンサプリを取ってみる
  • 昼休みなどにできるだけ肌を露出した状態で日光にあたる

 

運動の習慣をつける

運動も大事です。単純に継続的な運動の習慣があれば、体力が付き健康になります。

 

健全な精神は健全な肉体からといいますが、あながち嘘ではありません。走ったり歩いたりすることもいいですが、一番のおすすめはジムでの筋トレです。

 

仕事をサボってでもいいので早く切り上げて、ジムに行く習慣をつけましょう。

 

しばらくジムに通えば、ジムに行けばなぜだか気分がスッキリしてストレスが減るように感じるかも知れません。

 

不思議に思うかも知れませんが、筆者の場合本当に気分が変わりました。精神的に筋トレに一番助けられたといっても過言ではありません。

 

嘘だと思っても一度、試してみることをおすすめします。最初のうちは以下のように全身まんべんなくマシントレーニングを試してみるといいでしょう。(特に肩のトレーニングは肩こりに効くので超おすすめです。肩こりに悩んでるなら肩の筋トレだけでもしたほうがいいです。

 

  • チェストプレス
  • ラットプルダウン
  • ショルダープレス
  • レッグプレス

 

食事を自炊してみる

料理を自炊してみることも重要です。普段外食が多いと、食事を自炊に切り替えるだけで驚くほど体調が良くなる場合があります。

 

コンビニのお弁当と自分で作ったご飯ほとんど変わらないだろーーーと思うのに、自分で作るとなぜだか違います。

 

もしかしたらビタミンとかが違うのかも知れません。嘘だと思って試してみるといいでしょう。これは私も謎なんですが、本当に違います。

 

料理アプリならkurashiruがオススメです。簡単に作れて美味しくて失敗しにくいメニューが揃っていて料理動画みてるだけで楽しいです。

 

上級編

ストレスに強い考え方。

認知の歪みを自覚する

人はストレス状態にある時、現実を正しく認識することが難しくなります。本当は嫌われていないのに嫌われていると思ったり、それほど重要でないことなのに絶対に守らなければならないルールだと思ったり。

 

本当は休んだ方がいいのに休まずに頑張り続けてしまうのもその一例でしょう。まず、前提として人間の思考の大半は思い込みです。そして、ストレスの多くも思い込みによって発生します。

 

このような現実と認識のズレを認知の歪みといいます。この歪みにどれだけ自覚的になれるかによってストレス耐性が大きく変わってきます。

 

これに関しては多くの書籍が出ているため、本を読んでみるのもいいでしょう。

こころが晴れるノート:うつと不安の認知療法自習帳

こころが晴れるノート:うつと不安の認知療法自習帳

 

  

解決可能な問題と不可能な問題を切り分ける

認知の歪みにどれだけ自覚的になったとしても、根本的に解決できない大きな問題や不安は存在します。そのような問題にあなたが巻き込まれてしまう可能性もあります。

 

そういう場合には、悲しいことですが、自分の問題と人の問題を切り分けるという考え方も重要です。どれだけ頑張ったところで変えられることと変えられないことがあります。

 

たいていの場合、他人の心の問題はどれだけ頑張っても解決することが困難です。一方で自分の心の問題は自分で責任を取ることができます。

 

半分以上ここまで来てしまうと自己啓発の領域ですが、アドラー心理学などはそのような問題を主題として扱っており、オススメです。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

 

小説などを読んでみる

もはやこれは個人的な趣味の領域ですが、小説などを読むことで癒やされること、考えが整理されることがあります。

 

自分の状況を客観視することもできるかも知れません。文学作品を読んでみるのもいいでしょう。個人的に筆者は一番病んでいる時に遠藤周作の本やエッセイなどよく読んでいました。

 

すごい癒やされるのでオススメです。これは完全な趣味ですが。 

イエスの生涯 (新潮文庫)

イエスの生涯 (新潮文庫)

 
侍 (新潮文庫)

侍 (新潮文庫)

 

 

とはいってもどうしようもない場合

以上いろいろと書きましたが、そんなこと言われてもどうしようもない、解決できない問題がある、という場合は病院にいって医師に相談したほうがいいかも知れません。

一年以上ほぼ毎日仮想通貨トレードしていた僕が引退する理由

昨年のGW前からせっせと毎日仮想通貨トレードをしていたのですが、この度トレードをしばらくお休みすることにしました。

 

理由は以下の通り、

 

  1. 市況が悪すぎて当面の間上昇相場が来る気配がない
  2. ビットコインFXなどもレベルが上っていて勝ち残れない

 

からです。あと、すごく個人的な理由をいうと、昨年取引所においたままにしていたアルトコインを今年のビットコインのFXの原資にしていたのですが、それがすっからかんになってしまったからです・・・。

 

市況が悪すぎて当面の間上昇相場が来る気配がない

 

2017年のビットコインのバブル相場はビットコインを欲しがる新規参入者が爆発的に増えたことが理由でした。

 

でも、今はもう殆ど仮想通貨の話題を目にしません。

 

私は仮想通貨トレードが好きだったので、同じように仮想通貨トレードが好きな人達を多くフォローしていますが、その人達もほとんど仮想通貨のツイートをしなくなったように思います。

 

それほど利益が出ていなかったり参入が遅くて大損を出している人は静かにいなくなり、多くの利益を出していたように思える古参の人たちのみがほそぼそとツイートしているのみです。つわものどもがゆめのあと・・・。

 

昨年度の仮想通貨バブルは取引所の広告費用のバラマキによるところが大きかったように思います。でも今は、規制規制でTVCMなどもってのほかアフィリエイトも費用体効果が悪くほとんど機能しない。で、のぞみ薄いのです。

 

去年活躍したインフルエンサーなどは企業メディアに刈り取られた上に、企業メディアも採算取れずに撤退で仮想通貨関連の検索クエリは屍の山・・・。アフィリエイト単価が多少上がったくらいじゃ誰も嬉しくない状態です。

 

これらが精算されて綺麗な状態に戻らない限り、もう無理ではないでしょうか・・・。

 

googleトレンドというツールを使うと、特定のキーワードのgoogle上での検索回数の上限を計測することができるのですが、「ビットコイン、仮想通貨」という検索ワードの検索回数の推移は以下のようになっています。

 

f:id:nepio:20180812202131p:plain

 

もう、実需が生まれてまともな発展をしない限り先はないと思います。

 

ビットコインFXなどもレベルが上っていて生き残れない

 

これには諸説あるかもしれませんが、段々と仮想通貨FXの難易度は上がっています。

 

少し前だったらトレンドがはっきりしていて、上がるときは上がるし、下がるときは下がるという傾向があったのですが、最近は急にあがったりさがったり非常にランダムに動きます。

 

このあたりは私は知識不足なので嘘を書いてしまうかもしれませんが、長期的にはおらおく下がるはずだけど短期的には上も下も期待値ほぼ同じくらい、って感じの動きに最適化されてきている気がします。

 

ゆるくショートすれば負ける確率は低いのかもしれませんが、昨年みたいに短期で荒稼ぎ!みたいなことはどんどん難しくなっている割に、短期で大損する可能性は上がっているように思います。

 

これだと流行りませんよねぇ・・・。ちなみに私は今年取引所に余っていたアルトコインを現金に変えてFXで遊んでいたのですが、トータル40万円くらい擦りました

 

むしろ40万で済んでよかった・・・。このお金がなくなったら辞めると決めていたので当面手を引きます。

 

 というわけでしばらく仮想通貨トレード辞めるよ!

 

次は別のこと趣味にしよー。昨年モナコインが50円の時点で100万突っ込んでいたのにそれほど利益出せなかったのが唯一の心残りです・・・。あぁ、去年楽しかったなぁ・・・。

golangのWAFのechoで書いたAPIをGAE (Google App Engine) へデプロイする方法

golangのechoで書いたAPIをGAEへデプロイする際に詰まったのでメモ。

 GAE (Google App Engine) は、APIサーバなどをフルマネージドな環境に手軽にデプロイすることができる優れたサービスですが、golangの仕様上、デプロイの方法がわかりにくくなっていたのでメモ。

 フルマネージド:完全運用保守管理代行サービス。googleがサーバが落ちないようにメンテナンスしてくれるってこと。

 ポイント1:GOPATH配下のディレクトリで作業する

通常、~/go/src/github.com/{user_name}/{project_name}に設定されているgopath配下で作業する。

これはgolangでコーディングをするならimportの仕様上不可避かと思います。

  • golangでは import "github.com/{user_name}/{project_name}/test"のようにプロジェクト配下のサブディレクトリを読み込んだ場合、GOPATHに設置してあるファイルが優先的に参照されてしまうため、ホームディレクトリなどにプロジェクトを設置していると、更新したファイルが反映されない!みたいになる

 ポイント2;vendorディレクトリにすべての依存関係を格納する

GAEでは、golangのすべてのソースコードと依存関係をアップロードしてソフトウェアがビルドされます。ここで問題になるのが、ローカルのプロジェクトと同様にGAE上でも依存関係が解決できるようにしてあげること、です。これが結構めんどくさいです。

なぜならばGAEでは、vendorツール(依存関係をプロジェクト配下の/vendorディレクトリにまとめるツール)が利用できないからです。

通常、ローカルでgolangのプログラムを実行する際には、/vendorディレクトリと$GOPATH配下の2つを参照して依存関係は解決されるのですが、GAE上にdeployする際には$GOPATHのみが参照されます。すべての依存関係を$GOPATH配下に格納した状態でdeployコマンドを叩かないとエラーで死にます。クソめんどくさい仕様にしてんじゃねーよ。という心の声をぐっとこらえて以下のような対策を行いましょう。

  • プロジェクト内部にgopathディレクトリを作成して、そこにすべての依存関係が集まるようにシンボリックリンクを張る
  • デプロイコマンドを叩くタイミングで上記のgopathディレクトリが環境変数の$GOPATHに設定されているようにする (direnvというツールを使う)

具体亭には次のようなディレクトリ構成がおすすめです。

.
├── Gopkg.lock
├── Gopkg.toml
├── README.md
├── app
│   └── (プロジェクトのメインのソースコード)
├── gae
│   ├── .envrc (gaeにデプロイする際に$GOPATH=goathになるようにするための設定ファイル)
│   ├── app.go
│   └── app.yaml
├── gopath
│   └── src -> ../vendor (vendorディレクトリへのsymリンク)
├── main.go (gaeに依存しない実行ファイル)
└── vendor
    ├── github.com ── {project_name} -> ../../../app (appディレクトリへのsymリンク) 
    └── (depなどのツールで管理されるその他の依存関係)

main.goを実行する際には通常のvendorディレクトリとGOPATH配下のappディレクトリから依存関係が解決され、 GAEへデプロイする際 (gaeフォルダないでgcloud app deployコマンドを叩く際)には gopath配下のsymリンクからすべての依存関係が解決されます。

具体的なソースコードは下記にあります。

github.com

Unity C#でのJSONの扱い

プログラミングは強い人ほど型のある言語を好む傾向があるような気がしますが、個人的にはJSONの扱いがめんどくさいので動的型付け言語が好きです・・・。

というわけで今回はUnity C#でのJSONの扱い方についてまとめます。

Unityでは、事前に定義したClassにJsonUtilityを利用してデータをmappingする方法が一般的です。

gist.github.com
上記はネストした構造体をパースする例。

GO言語のWAFを大雑把に比較してみた【Gin、Goa、net/http、gorrila/mux、Echo】

こんにちは、

 

最近Go言語でWebサーバを書く機会がありフレームワークをいろいろ試してみていたので触ってみた所感を共有したいと思います。

 

Webサーバとは言ってもフルスタックなWAFではなく、軽量なREST API向けのフレームワークを求めている方向けです。

 

結論から言うとEchoを採用しました。選定理由は、

 

  • 記述すべきコードが最も少なくなりそう
  • ミドルウェアやルーティングの挙動が求めている仕様

だったからです。

 

速度や性能ではなく、個人的なコードの書きやすさやなんとなくいい感じの挙動を元に比較します。

 

それでは順を追って比較していきます。

 

Gin

 

golangで軽量で早いWAFとして有名なGinです。

 

日本語の情報も多くドキュメントやミドルウェアも整理されており、大抵のことは簡単に実現できます。

 

ただし、今回気になったのは下記の点

 

  • ルーティング部分にhttprouterを採用しているがこれの挙動がいまいち

 

そもそもGinが他のフレームワークに比べて早いとされているのはrouting部分に正規表現を利用しておらず軽量なライブラリを採用しているから・・・・らしいのですが、この挙動がイマイチです。

 

例えば下記のようなURLを独立してルーティングすることができません。

 

GET /users/:ID

GET /users/:ID/friends

 

これだとREST APIの実装を行うのに困ります。まあルーティング部分を差し替えれば使えないこともないですが、なんとなくださいのでボツ。

 

上記の問題はhttprouterのissueに上がってたのにずっとメンテされていないのイマイチですし、それに依存し続けるのもどうなのって感じなので・・・。

 

それ以外の点ではすごくコード書きやすいライブラリだなと思いますが今回は不採用。

 

Goa

 

独自のDSLAPIのデザインを記述すると、SwaggerのAPI定義とテンプレートコードを自動生成してくれる神ツール。

 

yamlでswagger書くより数段使いやすいよおおおおおと感動の声を上げましたが、現在v2への移行中&ドキュメント少なくいろいろ機能を実現しようとしてうまく行かなかったためボツ。

 

あと自動生成されるよくわからんコードがたくさんあるってのも個人的にどうなのって気がしたので・・・。でも面白いので一度触ってみることは大変オススメです。

 

net/http

 

とここまで検討して来て、もうライブラリいらないんじゃね?男は硬派にnet/httpじゃ!、と公式のライブラリを利用してみました。

 

  • 認証やCORSなどのミドルウェアをきれいに設定する方法がなくて自分でコード書いて整備する必要がある
  • ルーティングが貧弱

 

前者に関してはまあ書けばいいのですが、そういうコード書きたくないからフレームワークの検討をしているわけで・・・。

 

また後者については他のライブラリを導入して実装するのが定番のようです。

 

gorrila/mux

 

net/httpと組み合わせて使うルーティング向けのライブラリ。使い勝手はよくてかなり定番のツールのようでしたが、結局その他の部分はフレームワーク相当のコードをnet/httpに追加しなければきれいにならないという点は共通だったのでボツ。

 

Echo

 

最後に試したのがこちら、非常にシンプルなフレームワークです。

 

APIはGinに似ています。しかし、EchoではGinで気になったルーティングの問題が存在しません

 

その他に目立って困る部分もなかったので採用することにしました。

 

最後に

 

ざっと触ってみた所感だと完全な定番WAFというのは存在しなさそう。今回は一番無駄なくコードをかけそうだったのでEchoを採用しました。

 

 

でも、開発しながらデプロイ環境を選定する弾になって、GCPのGAEを利用することになり、

 

シンプルなREST APIだけ書くならGAEにnet/httpで書くのが一番ラクだったのではないか・・・と思ったのはここだけの話

 

次回はGAEについてはまった点まとめようと思います。