goで関数変数定数のパッチとモック

最近はGoでのテスト時の値の置き換えのしかたとかすごい悩んでます
最近自分がやった策をメモしておく。ただの所感ポエム。

関数のパッチ

MonkeyPatch最強。悩む必要なし
github.com

  • テストしたい関数
func Hoge(a string, b int) (string, error) {
    return "hoge", nil
}
  • テスト
func TestHoge(t *testing.T) {
    monkey.Patch(Hoge, func(string, int) (string, error) { return "fuga", nil})
    ~~テスト~~
}

ちなみに monkey.Patch() 先生は関数しかパッチできないので無理をしようとすると怒られる。

panic: target has to be a Func [recovered]
    panic: target has to be a Func

定数・変数のパッチ

自分が調べた限り、パッチするようなライブラリはない(あったら教えてください)。
メッチャ苦労するので、設計段階から置き換えやすいIFにしておくのが得策の様子。

苦心した方法は下記。

  1. envに入れる
    os.GetEnv("HOGEHOGE") に格納しておいて、都度そこから引っ張り出す。環境ごとに変更。
    テスト時は os.SetEnv("HOGEHOGE") でどうにかなる
  2. configファイルを用意、上書き
    コンフィグファイルに定数にしたいものを定義しておく。ただし var で。
    テスト時はそこを書き換える。けっこう無理矢理である。

コンフィグファイル

package config

var (
    Hoge = "foobar"
)

テスト

config.Hoge = "piyofuga"

モック

モックをするには interface が必要らしいので、ちょっと関数だけ…なときにはモックを作るほうにめんどうくささが偏っていく。
とりあえず interface があるなら(もしくはこのために作っても良いのなら) mockry とか gomock とか選択肢はある。
ジェネレートするだけ簡単仕様、使い方は色んな人が書いているからどうにかなる。

github.com

github.com


感想、設計がちゃんとしてればテストもラクなんだろうなあって思った(こなみかん)。
テストのしやすさも考えて実装しないと「テストどうやるの…」になって詰む。
Goはその辺試される言語ですね。ザコーダーにはつらい。

Fitbit製品はソニータイマーみたいな壊れ方するから買うべきではない

書かずにはいられなかったよ。

TL;DR

Fitbitは故障対応が最悪なので、購入を検討してここに辿り着いたなら考え直すことを強くお勧めします
特にIonicはダメだ。3万円もするんだぞ。
アキバでやっすい中華ウォッチを買ったほうがマシ

何が起こった

Amazonの日本先行発売で購入したFitbit Ionicを1年10か月使っていました。が、先日故障しました。
原因はおそらく水泳(ちなみに防水モデルですよ!)。

水泳アクティビティ記録モードにして、泳ぎ始めて30分ほど経ったころ、ふと気付くとIonicが再起動状態に。
オヤと思ってプールから上がって様子を見ていると、再起動を繰り返しているようです。
再起動の合間にボタン・パネル操作をしましたが、30秒ほど遅延してやっと操作が反映される状況でした。
とりあえず、時計はそれ以上水に浸けないように腕から外しました。

帰宅後、満充電してみました。
遅延が10秒くらいに減ったがなんかパネル操作がおかしい。左半分の操作が効いていない。
苦戦しつつなんとか設定画面に辿り着き、出荷状態へ初期化しました。

初期化後、遅延はなくなりましたが、やっぱりパネルの左半分はウンともスンとも状態でした。

サポートに連絡したらガッカリ対応だった

f:id:komajou:20191015082950j:plain

サポートに問い合わせるとこんなメールが返ってきた。

要約すると、

  • Fitbitに「修理対応」というものはない
  • 1年の保証期間を過ぎているので なにも対応できません

そんなことある…?
一応3万円するんですよ、Ionic。
3万円あればSwitchやらPS4やら買えます。任天堂ソニーが修理断るなんて想像できます?
機械は機械だから絶対に遅かれ早かれ壊れます。でも愛着持って使いたい人はいるわけで。
それなのに…?「対応をお断りせざるを得ない」…?

呆然。

みんなソニータイマーしてるらしい

https://community.fitbit.com/t5/%E3%83%98%E3%83%AB%E3%83%97/Ionic%E3%81%AE%E9%98%B2%E6%B0%B4%E4%BB%95%E6%A7%98%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/td-p/2835097

https://community.fitbit.com/t5/%E8%AD%B0%E8%AB%96/IONIC-VERSA%E3%81%AF%E6%B5%B7%E3%81%A7%E4%BD%BF%E3%81%A3%E3%81%A1%E3%82%83%E3%81%84%E3%81%91%E3%81%AA%E3%81%84/td-p/2850860

この辺を見ると、みんな同じような壊れ方をしているように思います。
かわいそうな人は1年1か月で故障しているようで…ひどい。

IonicはFitbitの最高級モデルで、1台3万円します。
それなのに、修理サポートもなく壊れたらはいおしまい。
ひどくないっすか。

結論

Fitbitが買収したPebbleが好きでした。
なのでFitbitも何となく好きだったけど今回のことで嫌いになってしまいました。
もうFitbitは買いません。
高い勉強代でした。本当に残念。

go-proto-validatorでis_in_enumを使ったときにコンパイルに失敗する

TL;DR

https://github.com/mwitkow/go-proto-validators の version 0.1.0 で、
ネストされているEnumに対して is_in_enum:True を設定するとエラーになる。 version 0.2.0 で解決された様子?だが、うまくいかない。。。

エラーメッセージ

C:\Go\Project\hoge\fuga\foo.pb.go:18:14: undeclared name: Belong_name
2019/09/25 15:33:54 Loading input failed: loading package failed

問題が発生するprotoファイル

item Person {
  string id = 1 [(validator.field) = {length_gt:0, msg_exists:true, string_not_empty:true}];
  string name = 2 [(validator.field) = {length_gt:0, length_lt:50, string_not_empty:true}];
  enum Belong {
    NONE = 0;
    COMPANY = 1;
    SCHOOL = 2;
    OTHER = 3;
  }
  Belong belong= 3 [(validator.field) = {msg_exists:true, is_in_enum:true}];
}

原因

version 0.1.0がネストされたEnumに対応していないことが原因の様子。 pb.go ファイルを生成するとき、Enumは下記のように NameValue の2つの変数に分けて定義される。

var Person_Belong_name = map[int32]string{
    0: "NONE",
    1: "COMPANY",
    2: "SCHOOL",
    3: "OTHER",
}

var Person_Belong_value = map[string]int32{
    "NONE":     0,
    "COMPANY":  1,
    "SCHOOL": 2,
    "OTHER":    3,
}

ここで変数名に注目して欲しいのだが、変数名は
{親のクラス名}_{自分のクラス名}_{name|value}
命名規則に則っている。

go-proto-validators はこの {親のクラス名} を追えないようで、 {自分のクラス名}_{name|value}
を探しに行ってしまう。そのため、参照エラーになる。

解決法

ネストしない。
ネストしているEnumを親クラスの外側に出す。

version 0.2.0でこの問題が解決したっぽい。 が、いまいちうまく生成できないのでとりあえずネストしない法でやりすごしている・・・

PyConJP2019に当日スタッフとして参加しました

2018年9月から本格的に業務でPythonを使い始めて1年が経ちました。
満を持して!初PyConJPに参加してきました。 しかも当日スタッフとして。 自分の中ではかなりのチャレンジをしました…!

9/15(前日)

事前準備から参加しました。何もないだだっ広い大展示ホールを「会場」にするお仕事。
会議テーブルを展開したりパーテーションを立てたり、あとは同時通訳レシーバーに番号貼り付けたりしてました。
楽しかったですが、普段座りっぱなしの身にはかなりキツかったです。腕力がなさすぎた。テーブル一枚持ち上げられないんじゃ…。
何をやるにも一番大変なのは準備と片付けですね。再認識しました。

9/16(1日目)

朝からバタバタと色々やってました。
託児&ユースコーダー受付とか、外国人参加者さんのサポートとか、小展示ホールのセッション運営とか、コンセントルームの確認とか。
バタバタでしたが超楽しかったです。
良いこともありました。昔お世話になった方に5年ぶりくらいに会えました。完全なる偶然。嬉しかった。
それから、パーティの時間には初めましての方ともたくさんお話ができてとても良い時間が過ごせました。
正直、15日までは知らない人しかいない緊張でガチガチだったのですが、16日になると肩の力も抜けていい感じにお仕事ができていたと思います。

最後に

スタッフになって見えたこと

ボランティアで活動するスタッフの努力がカンファレンスを支えています。
これは言葉にすると簡単で「当然じゃんか〜」って受け取り方になるのですが、自分がその立場になり、かつ他のスタッフを間近で見ると「自分ごと」としてのリアリティがより濃くなりました。
スタッフは本当に全力で運営に向き合っていました。
深夜までネットワーク保守に全力を投じてくださったNOCのみなさん。
夜遅くまで&朝早くから動けるように、会場近辺に宿泊していらしたスタッフの方々。
けっこう早かった朝の集合時間に間に合うために、朝4時起きで来ていた当日スタッフさん。
カンファレンスへの愛と、気合いがないとできないと思います。
本当に、敬意敬意です。

夜のパーティで、参加者の方から「運営ありがとう」って言われた時は嬉しかった。自分なんかでも、PyConにちょっとでも貢献できたなら嬉しいです。

スタッフの皆さまへ

未経験の自分を当日スタッフとして受け入れてくださり、色々と教えてくださったスタッフの皆さまに感謝します。
大変貴重な経験をさせて頂きました。
来年以降もぜひ参加させてください!

Dockerコンテナ内からlocalhostで起動しているアプリケーションに接続する

解決法

Windows環境では http://docker.for.win.localhost:xxxx
Mac環境では http://docker.for.mac.localhost:xxxx へ接続する

参考 https://qiita.com/tatsuya-miyamoto/items/08bd6ea142d02708614f

どういうときに使うの

やむを得ない事情があってlocalhostMySQLを立ててしまったときとか。
docker-composeを2種類用意して、それらを接続したいときとか。

Dockerから http://localhost:xxxx に向けると、localhostって誰って話になって接続ができない。
そういうときは、 localhost を前述の docker.for.xxx.localhost に置き換えてやるとつながる。

簡単なことなのに調べてもなかなか出てこなくてハマった。
一人でも多くの人が安らかな気持ちになってくれることを祈る🙏

GCP Associate Cloud Engineer不合格記

合格記書いてる人はそこそこいるから、不合格記書いてる人がいてもいいでしょ?というコンセプト。
己の浅学を露呈するタイプのプレイである。

tl;dr

落ちました!!!!!!!!
めっちゃ悲しい悔しい!!!!!!!!!!
メッチャむずかった!!!!!!!!!!!

受験したきっかけ

Google Cloud Next '19 に参加して、
Google Cloud 認定資格チャレンジ - 入門 & インフラ 編」のチラシをもらったことがきっかけ。

cloud.google.com

Googleのオンラインコースの決められたカリキュラムを受講すると、
GCP試験の25%オフバウチャーがもらえるというもの。
ついでに、試験に受かると100ドルのGoogleストア用クーポンがもらえる。
そして、勉強のために、普段有料のオンラインコースが1ヶ月間無料で使える。

とりあえずコースを受講して、バウチャーをもらって、模擬試験受けてみたら意外と行けそうだったので申し込んで不合格になって今に至る。

コース受講前のスキル

  • PHPとかPythonとかGoとか使うWebアプリバックエンドのパソコンカタカタおじさん(エンジニア4年目)
  • インフラはDocker Composeまではちょっとだけレベル
  • 普段アプリケーション以外はあまり触らない。障害調査でログ読むくらい
  • AWSクラウドラクティショナーまでなら持ってる

受験までにやったこと

上記の通り、チャレンジで無料開放されたQwiklabsとCouseraのコースを一通りやった。
コースの中でわからなかったコマンドとかはドキュメントを調べつつ。
GCNextの後から始めて、合計約30時間。

試験の感想

めっっっっっっっっっっっちゃむずかった
模擬試験でそこそことれたからいけるっしょって思ったけど模擬試験と難易度が違いすぎる…
試験問題については触れられないので、自分に何が足りなかったかを試験後に考えた結果を書いておくので察してください

  • インフラエンジニアとしての実務経験がなかったこと
    • わからない問題がとことんわからなかった。勘所が効かなかった
    • Webアプリエンジニアは普段やらないことも試験範囲だからそれがきつかった
  • ひとりでGCPを触っていたこと
    • 複数人・組織で触らないとプロジェクト管理/IAM管理の勘所は身につかない
  • ベストプラクティスに関する知識が少なかった
    • Googleが無料開放してくれたコースで学べたのは基礎知識+ベストプラクティスの入り口
    • もっとドキュメント読みこんでおくべきだった

試験に落ちたけど残ったもの

試験自体には落ちてしまったけれど(めちゃくちゃ悲しい。試験料の1万円…)、
勉強前にはできなかったことができるようになった手応えがとてもある。
QwiklabsとCouseraが、とてもわかりやすくて良い学習ツールだったお陰だと思う。
具体的には、GCPを使って以下のようなことはできるようになりました。多分実務でもいける。

  • Webアプリのインフラ構築
    • マルチリージョンにして、ロードバランス入れて、バックエンドはLBからのトラフィックだけ受け入れるVPCにして、冗長化もして、とか一通りのシステム構築をVMとその他フルマネージドサービスで作る
    • VMほど自信ないけどKubernetesでも頑張ったらいけそう
  • StackDriverでロギング・トレース・モニタリング
  • そのほか試験範囲はちょっとだけ

今までGCPナニソレオイシイノ状態だったことを考えると、かなり成長できている。
とりあえず、GCPでWebアプリ運用ができるとこまで来れたということなので。
(Anthosとかはちゃんとわかってないですけどね)

勉強して落ちてダメダッターあー時間無駄にしたーではなく、ダメだったなりにも成果が得られたので、
トータルで「受験してよかった」と今は思えている。悲しいけど。

再受験するの?

心の傷が癒えたら
とりあえずしばらくは受けるつもりはない
秋のIPA試験のこと考えてる

試験をこれから受ける人にいいたいこと

  • Google Cloudのドキュメントは膨大すぎるんだけど、あれ全部読んだほうがいいよ(マジで)
  • バリバリGCPの実務経験があると安心だよ(Webインフラを除く)

カンファレンスで使える英語の質問表現

tl;dr

  • カンファレンスで外国人スピーカーに質問&会話する時の便利な言い回しまとめ
  • 基本的に質問するときは May I know ... の形式で質問すると良い。最も丁寧な言い回し

まえおき

2019年末のRe:Inventに参加することになりました。
ただ英語は全っっ然できないので、準備として EnglishCentral に登録して、ネイティブスピーカーの先生と25分×週2で話すのをここ1ヶ月ほど続けています。

ja.englishcentral.com

レッスンの中で、「カンファレンスでの丁寧な質問の仕方」をいくつか教えてもらいました。
自分的に使い所が多そうだったので&身につけたいので記録に残します。

ポイント

  • Can < Could < May の順で丁寧な言い回しになる
    • とりあえず人に物聞くときは May を使うクセをつける!
  • 質問は May I know... から始め、短く質問する

表現まとめ

セッションで使える表現

  • 挙手して当てられたときの決まり文句

    Okay.. Good morning(時間に合う挨拶) everyone.
    Especially to our speaker(s) for today.

  • 質問の仕方

    • Aについて教えて下さい。

      May I know about A.

    • AとBどちらが良いと思いますか?あなたの意見を教えて下さい。

      May I know your opinion... which is better A or B?

  • 発表後、セッションを称賛する

    • 個人的に感動した時とかに使う
      • 発表お疲れさまでした!とても参考になるセッションをありがとうございます。またお会いできることを楽しみにしています。

        Job well done. Congratulations!
        It has been very useful and informative to us.
        Thank you very much.
        Hope to see you again.

懇親会などでの会話に使える表現

  • 相手の仕事内容について訊ねる
    • あなたのお仕事内容はどんなものですか?

      May I know your job description?

    • あなたの主なお仕事はなんですか?

      What is your main responsibility at work?