shigeの投稿 - Crieit

2019年を振り返るポエム

2019-12-19T03:09:13+09:00

この記事はcrieitのなんでも Advent Calendar 2019の19日目の記事です。前日はhammhikoさんによるlocalhost監獄でした。localhostに自分専用のアプリが増殖していくのはプログラマあるあるですね！こういったアプリケーションは世に出ることは無いとしても自分の経験や成長につながりますし、なんていうか、盆栽みたいな感じで自分好みに魔改造していくのが楽しいですよね。

さてさて、本当ならこの記事には今やっているKubernetesとかGoとかPythonがらみのネタを書こうかなーと思ってたけど、どうにも記事が煮詰まらないまま今日を迎えてしまいました。ということで、ここはポエム…というか、今年１年の振り返りをしようかなと思います。

自社は地方都市にあり企業の規模はまぁまぁ大きいWeb系企業です。そんなところで、私はいまは小さいチーム（本当に小さい。メンバーの異動と退職が相次いで今はなんと２人！もはやチームではなくてペアと呼んだほうが正しい）のマネージャーをしている。チームの役割としては、インフラのためのアプリケーションを開発したり運用したりしている。個人としては、これまでのプログラマの仕事に加えて、マネージャー業、特に採用活動もやっている。採用活動というのは本当に大変で、自分のチームにフィットする人というのは予想以上にいなかったりする。また、これまでのプログラマとしての仕事が減ることなく、というかむしろ増え続けていて、振り返ってみるとそれなりに消耗した一年になってしまったように思います。

突然ですが、今って空前絶後の人手不足じゃないですか。それは弊社でも同じで全然人が採用できない！というかそもそも応募が無い！わけあって、外部のリクルーターを使うのをやめてしまったため、自分で候補者を探す必要があるんだけど、ちょっと知り合ったやつの口車に乗って選考に応募する奇特な人など見つかるはずもなく…。自分の個人的な人脈とかを駆使しても、なかなか応募まで至らなかったりする…人望をどこかに置いてきてしまったらしい…

ということで、そもそもなんでこんなに応募が無いのか、あるいは応募してもらうことができてないのかということをここ最近（数ヶ月以上）ずっと考えている。たぶん色々理由はあって、うちに来たらどのくらいのお賃金がもらえるよとか、どういうことをやってもらいたいと思っているよ、とかそういう具体的な話ができないことが多いからということがある。もちろん、ある程度のことは話せるんだけど、なかなか相手に刺さるようなことが言えない。まぁこれは私の会話力が低いからなんだろうけど…

いずれにしてもこのまま採用活動しててもなかなかうまいこといかないなーというのが今年の反省。来年はもっとカンファレンスでの登壇とかを増やして自社の知名度をあげるのと、海外遠征も視野に入れて採用活動をしないといけないかもなーと思っている。なにせ地方には人がいない！地元からの応募があれば嬉しいんだけど、なかなかマッチするひとがいない…

次に技術的な振り返り。去年もそうだったけど、今年もたくさんコードを書いた。なにせ人手不足なものでね…アラフォーですよ、私…35歳定年説はどこいった。まぁそれはおいといて、今年はKubernetesを実戦で使うことができてサービス投入までできたのでそれは良かったなー。まぁ私が関わったのは最初の立ち上げのところまでで、今は別のメンバーが運用しているんだけど…Kubernetesに関しては運用のほうが圧倒的に大変で、だけど、学ぶところが多いのでインフラレイヤーに興味がある人は絶対に触っておいたほうが良い。まぁでも世の中的にKubernetesが必要なサービスってどのくらいあるのか、言うほどKubernetesが必要になることって無いんじゃないかなとは思うけど。もっと簡単に問題が解決できるなら、Kubernetesは無理に使わなくてもいいと思う。Ref: Maybe You Don't Need Kubernetes

多分、今年一番書いたコードはGoだと思う。自分でも意外だったけど、GoでWebアプリケーションを書いたことがあんまりなくって、初めてechoというフレームワークを使った。Flaskとかfalconみたいなマイクロフレームワークを使ったことがある人ならすんなり使えるんじゃないかなと思う。ただ、個人的な感想としては、Goで複雑なモデル操作が必要なアプリケーションは書かないほうがいいんじゃないかなって思う。やっぱりPythonみたいな動的言語と比べると、コード量が増えがちだし、面倒ではある。もちろん型付言語としてのメリットを享受することはできるんだけど。まぁでもGoは楽しい言語だし、使い勝手が良い言語なので、これからもGoをたくさん書くんだろうなーと思う。Goで面白いトピックはなんかあったけなーと思ったけど、面白い話題はだいたいDave Cheneyのブログにあるので、これを暇なときに読んでいれば良いと思う。

えー、次はPythonですかね。Pythonでは別のWebアプリケーションを作った。なんか最近はresponderとかいうWebフレームワークが流行っているらしく、開発者はrequestsとかpipenvを作った人らしい。ということで、まず間違いなく近いうちに主流になってそうなんだけど、色々あってDjangoを使った。というのは別にどうでも良いんだけど、今回はPaste Deploymentを紹介したい。

Paste Deploymentは設定管理のためのソフトウェアみたいなやつで、アプリケーションの設定をスクリプトじゃなくて宣言的に管理することを目的に開発されたもの。また、こいつはDjangoが起動させるWSGIアプリケーションを読み込むことができるんだけど、HTTPリクエストをpipelineで処理させることができる。どういうことか簡単に言うと、自分のアプリケーションに来る前（あるいは後）に別のアプリケーションをフィルターとして置いて、ユーザーからのHTTPリクエストを事前/事後に処理することができる。

これの何が嬉しいのか？それは認証処理のような、本来アプリケーションのビジネスロジックとは無関係なものを自分のアプリケーションから切り出すことができる。それにより、自分のアプリケーションは本来集中すべき処理に集中することができるので、余計なロジックを持たなくて良くなる。これにより、テストが格段に書きやすくなる。認証処理を考慮してテストを書くのは本当に面倒で、OAuth的な認証処理とかだったりするときはこういったやり方がとても便利。フィルターを利用したWebフレームワーク自体はそんなに珍しくないし、むしろ古くからあるんだけど、自分のアプリケーションから切り離して利用することができるのは結構珍しいんじゃないかなと思う。どっかで話すことができたら良いな。

（なんか文字数がこのあたりで2,700を超えてきたので、そろそろまとめに入ろう…）

そんなこんなで技術的には色々挑戦できて学びが多かったけど、いかんせん業務量が多くてつらぽよだった…特に採用活動は本当にどうにかしないといけなくて、来年はどうにか解決したい。あと、せっかくcrieitに記事をポツポツと投稿していることだし、個人開発のビッグウェーブに乗りたいところ。アイデアはボチボチあるけど、時間を作らないと…来年はゆとりある暮らしをしたいですな…

ということで、3,000字を超えそうなので、このへんで終わりにします。明日はきんみさんです！お楽しみに！

手軽にGoのResponse.Bodyを再利用したいとき

2019-11-14T13:34:28+09:00

こんなコードがあるとする。

...
response, _ := http.Get(requestURL)
body, _ := ioutil.ReadAll(response.Body)
body.Close()
...

GoのHTTP Responseをioutil.ReadAllなんかで読み込むと、response.Bodyのコンテンツをどこまで読み込んだかという情報を持つポインタ(Seeker)が最後まで進んでしまうので、もう1度response.Bodyを読み込もうと思っても何も読み込めない。なので、response.Bodyを別の場所にコピーしておく必要があるんだけど、適当にfoo = response.Bodyとかやってもダメ。

そんなときはio.TeeReaderを使って別の場所にコピーする（というかバッファを読み込むためのReaderをもう１つ用意する）。そうすれば新しいSeekerを使って読み込みを行えるので、response.Bodyの再利用が出来る。

var b bytes.Buffer
_ = io.TeeReader(response.Body, &b)
// こんな感じでコンテンツを読み込んでも後続の処理では引き続き`response.Body`を利用することが出来る。
log.Printf("DEBUG: %s", b.String())

おしまい。

パイプで受け取った標準入力を列ごとに読みこんで配列っぽく処理したい

2019-10-11T01:39:47+09:00

最近、古いシェルスクリプトをリファクタリングしたので、そのときに使ったテクニックをここに残しておく。

コマンドをパイプでつないで、最終的に出力を行単位で読み込みたいときがある。例えば、以下のlsコマンドの出力から一番ファイルサイズが大きいやつを選びたいとする。

$ ls /tmp/
total 28
...
drwx------  2 root wheel   64 10  8 01:25 KSDownloadAction.dFCyHsIUZR
-rw-r--r--  1 root wheel    0 10  9 23:35 wetrsmuoutpDmR5aR
-rw-r--r--  1 root wheel    0 10  9 23:36 wetrsmuoutpalIXOW
...

レガシー（というかマナーが悪い）なコードだとこんな感じになる。

#!/usr/bin/env bash

set -eu

OLD_IFS="${IFS}"; IFS=$'\n'
max_size=0
max_filename=
ls_outpu="$(\ls -l /tmp/ | sed -e '1d' | grep -v '^d')"
for output in ${ls_outpu}
do
    filesize="$(echo "${output}" | awk '{print $5}')"
    filename="$(echo "${output}" | awk '{print $9}')"
    if [ "${filesize}" -gt "${max_size}" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi
done
IFS="${OLD_IFS}"

やりたいことはタイトルにあるように「パイプで受け取った標準入力を列ごとに読みこんで配列っぽく処理したい」なんだけど、上のコードはいくつか良くない点がある。

IFSを一時的に置き換えている。
空白区切りの行から特定位置の文字列を取り出すためにawkを使っている。
数字を比較している。

１つずつ説明する。

問題点と解決法

IFSを一時的に置き換えている。

これは古いシェルスクリプトだとよく見かけるけど、このやり方はメンテナンスが非常にやりにくくなり、本当に危ないのでやめたほうが良い。
まず、IFSはshellにおいて、文字列の区切りを示すもの。これを変えることで、文字列の区切りを変えることが出来る。

通常、IFSは半角スペース、タブ文字、改行の３つである。ここではls -lの出力を行ごとに読み込むために文字列の区切りを改行区切りにしている（そうしなければ、出力を１行ごとに列単位で扱うことになってしまう）。そして処理が完了したらIFSを元に戻している。

これ、最初に書いた人は良いけど、別の人がコードを保守するときに、この部分を見落としがちなのでバグが発生しやすくなるんだよね。コードを読む人は途中でIFSが変わったことを常に意識しながら読むことを強いられるので、コードの保守性が著しく悪くなる。

よって、IFSの置き換えは良くないのでやめましょう。ではどうすれば良いのかと言うと、ヒアドキュメントを使ってreadで読み込めば良い。

while read line
do
    ...
done <<< "$(ls -l /tmp/ | sed -e '1d' | grep -v '^d')"

すこし見づらくなるけど、こうすることでIFSの置き換えが不要になり、行ごとに変数lineの中に文字列が格納されるようになる。

もしかしたらこうしたほうが良いかも？と思う人がいるかもしれない。

ls -l /tmp/ | sed -e '1d' | grep -v '^d' | while read line
do
    ...
done

べつにこれでも良いのだけど、パイプで繋がれた処理はサブシェルで起動するということを思い出してほしい。今回のようにwhileのループ文の中で、事前に定義した変数を読み込みたい場合、つまり、以下のような場合、

max_size=0
max_filename=
ls -l /tmp/ | sed -e '1d' | grep -v '^d' | while read line
do
    filesize="$(echo "${output}" | awk '{print $5}')"
    filename="$(echo "${output}" | awk '{print $9}')"
    if [ "${filesize}" -gt "${max_size}" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi

done

ループ文中のmax_sizeとmax_filenameは先に定義したものとは別の変数として扱われる。その上、サブシェルなのでループ文を抜けると、その中にあった変数たちは参照できなくなる。なぜなら、サブシェルはメインのシェルとは違う世界なので。よって、パイプでつなぐのでなく、ヒアドキュメントで入力を受け取るようにしている。

もちろん、サブシェルで起動しても問題なければパイプで繋げばいいと思うけど、ヒアドキュメントを使えばサブシェルの起動を１つ減らせるので、リソースやパフォーマンスの面からもオススメしたいやり方だったりする。

空白区切りの行から特定位置の文字列を取り出すために`awk`を使っている。

awkって便利なのでよく使われているんだけど、大抵の場合、空白切りの文字列の特定の位置の文字を取り出すときに使われることが多い。手元のコマンドラインで使うとかだったら良いんだけど、データ処理とかバッチ処理のスクリプトで使っているとしたら、なるべく次に紹介する方法で置き換えたほうが良い。awkは重いし、思わず色々awkの中に処理を詰め込みがちになってしまうから。

オススメのリファクタリングとしては、setを使うこと。setというのは、よくシェルスクリプトの冒頭でset -euとかやると思うんだけど、そのset。これはbuilt-in関数なのでawkと違って別途にプロセスがforkされることがなくて軽い。

で、どういうふうにsetをawkの代わりに使うのかというと、以下のようになる。

...
    set -- ${output}
    filesize="${5}"
    filename="${9}"
...

これだけ。スッキリしてわかりやすくなったと思う。解説はman setで見れば良いと思うけど、ここに引用しておく。

Any arguments remaining after option processing are treated as values for the positional parameters and are assigned, in order, to $1, $2, ... $n.

--については以下の引用を参考。grepとかでもよく使うので知っている人は多いと思う。

-- If no arguments follow this option, then the positional
parameters are unset. Otherwise, the positional parame-
ters are set to the args, even if some of them begin with
a -.

つまり、set -- foo bar bazとやると、それぞれが$1, $2, $3に格納される。Pythonで言うところの*argsみたいな可変長引数みたいな感じで位置引数として利用することが出来る。これにより、もうawkを使ってわざわざechoしてパイプで…みたいなことをしなくて済む（もちろんIFSを変更していないことが前提である）。

副作用としては、シェルスクリプトに渡された位置引数を上書きすることになるので、そういった引数は事前に別の変数に格納しておくのを忘れないこと。

数字を比較している

これはなんのこっちゃと思うかもしれないけど、-gtや-neは本来は数値を比較するためのものであって数字を比較するものではない。つまり、文字列のままで数字を扱うのは危ないのでやめましょうということ。ではどうするかというと、以下のようにすれば良い。

    if [ $((filesize)) -gt $((max_size)) ]; then

シェルスクリプトで足し算とかするときに$((foo + bar))みたいなことをするとおもんだけど（もしexprを使っているなら即刻書き換えましょう）、上のようにすることで数字を数値にすることが出来る。これの何が良いかと言うと、もし変数の中身がアルファベットのような数字ではない文字だった場合はゼロとして扱われる。

$ a="aaa"
$ echo $((a))
0

状況によるが、変数が数字でなければゼロとして扱って差し支えない場合はこのようにすることで余計な数字判定の式を省くことが出来る。

まとめ

ということで、ここまでの内容をまとめると以下のようになる。

max_size=0
max_filename=
while read -r line
do
    set -- ${line}
    filesize="${5}"
    filename="${9}"
    if [ "$((filesize))" -gt "$((max_size))" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi
done <<< "$(\ls -l /tmp/ | sed -e '1d' | grep -v '^d')"

行数はほとんど変わらないけど、最初の方と比べるとわかりやすくなったかなと思う。特別な処理とかないし。ちなみに、もっとも大きいファイル名を取得するだけならls -S | head -1で一発で取れるので、わざわざこんなことをしなくて良い。

初めて学生インターンを受け入れて感じたこと 2019夏

2019-09-17T01:00:01+09:00

はじめに

先月、初めて学生インターンを受け入れた。会社としては随分前から受け入れていたのだけど、うちのチームでは初めてだった。今年は縁に恵まれて受け入れることになったのだけど、自身にとって初めてだったということもあり、気づきや反省をここに残しておこうと思う。

背景

うちのチームの特徴は以下の通り。

会社はいわゆるWeb系の会社
筆者のチームはインフラサービスのためのソフトウェア開発をしている
筆者のチームは福岡が拠点だが、東京のチームと協働してサービス開発をしている
技術スタックはソフトウェアにPythonを、サービスのインフラにはKubernetesを使っている
日本人は筆者だけで他のメンバーは外国籍で、コミュニケーションには英語を使っている

インターン生にしてもらったこと

簡単に言うと、Chaos engineeringをしてもらった。Chaos engineeringについては以下のQiitaの記事がエントリーポイントとして良さそう。

カオスエンジニアリングと聞いてカオスになった人必見

早い話が「システムに対して、有り得そうな障害を意図的に起こして問題をあぶり出し対策を考える」手法と言える。細かいというか、正確に言うと、多少違うのだけど、実際的な視点で言えば、それほど的外れではないだろう。

で、なぜインターン生にChaos engineeringをしてもらったかというと、以下の考えに基づいている。

Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい
チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった
これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかった

なお、今回はテスト環境での実施となったので、本格的なChaos engineeringとは違うが、利用したソフトウェアや手法は一般的なChaos engineeringと同じものを採用した。

狙い

まず#1 Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい について。Chaos engieeringを行うにあたって、対象システムをある程度把握してもらってから、どこが問題になりそうかという仮説を立てて、どのように障害を起こすかということまでを最初に考えてもらった。これはChaos engieeringを行うにあたっては非常に重要だ。というのも、Chaos engieeringは意図的にシステムを不調にさせるため、何を行うかをチームでレビューして事前に作業内容を周知する必要がある。その後、作業をしてもらって、またレポートを書いてもらい、結果をチームでレビューした。これにより、自然とPDCAサイクルが出来上がってインターン生の状況が把握しやすくなった。また、副次的な効果として、技術文書の書き方の勉強をしたり、チームメンバーとの関わりを自然に増やすことが出来たと思う。

２つ目 チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった は割と重要だと思っていて、チームの誰もChaos engineeringを経験していないのでインターン生がチームでの第一人者となる。よって、周りからマサカリが飛んでくる危険を可能な限り減らして、失敗を恐れずに取り組むための環境を用意できたと思う（希望的な推測）。たとえ失敗したとしても、未経験のチームメンバーにとって全ての結果が貴重な知見となる点も重要だ。

３つ目これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかったはインターン生のためというか、プロダクトのためなんだけど、これまでに障害で発生した問題を解決するために色々な修正や機能開発を行ってきた。しかし、同じ問題には対応できているが、同じ"ような"問題に対応できているかどうか、ということまでは確認できていなかった。類似の状況でも、特にエッジケースで、問題なく動作するかという確信が持てるかどうかはインフラレイヤーのアプリケーションでは非常に重要で、Chaos engineeringが良い機会になるだろうと思っていた。

これらの狙いは（筆者の視点では）概ね成功したと思う。結果的に、大きな問題は顕在しなかったが、それはチームメンバーに自信を、プロダクトには信頼をもたらすことになった。

その他に気を使ったこと

週単位で取り組みや成果物を決めて共有した
- 途中で何をして良いのかわからなくのを防ぐため
途中経過や成果を発表する機会を設けた
- 成果物を発表する機会を設けることで、成果物の品質にも気を使ってもらうようにした
チームメンバー以外の社員と交流する機会を設けるようにした
- 会社の雰囲気を知ってもらうために、チームメンバー以外とコミュニケーションをしてもらった

反省点

筆者がメンター役だったが、インターンの後半では放置気味になってしまった。
- 筆者が色々あって多忙になってしまったが、もっと気を使うべきだった。
- 筆者が成果物の完成度を上げるために出来ることは色々あったが、あまり貢献することが出来なかった
もっと早くチームメンバーとのコミュニケーションの機会を持てるようにするべきだった。
- 筆者以外のチームメンバーが英語話者であったため、意図的に筆者とのコミュニケーションを多めにしていたが、いくつかの事柄に対して筆者が上手く回答できず、チームメンバーに頼ることがあった。
- これが結果としてインターン生の進捗を妨げる要因の１つになっていた。
- インターン生のコミュニケーション能力を信じて早くからチームメンバーと直接コミュニケーションできるようにするべきだった。
筆者も含めてChaos engieeringは（知ってはいたが）未経験だったために適切なフォローができなかった
- 今にして思えば、手当り次第にやってみるのではなく、ある程度こちらで想定される問題や事象を整理するなどして、道筋をつけてからやってもらえば良かった

次回に活かせそうなこと

メンター役は業務上のメンター役と業務外のこと（社内の制度や社内でのコミュニケーションなど）を担当するメンター役などを分けたほうが良いかもしれない
- メンターが１人だと業務の遂行に目が行きがちで、慣れない社内での過ごし方や社内手続きなどに関して疎かになりがち
- メンター役の負荷を分散するため
任せる業務はある程度メンター役の社員が精通しているもののほうが良い
- インターン生が詰まったときに的確にアドバイス出来るようにするため。
- とはいえ、Backlogとかをさせてもつまらないので業務の選定は熟慮しなければならない
R&D的な業務にしたのは良かった。もし次回があるなら、お題を与えてProof Of Concept的なものをやってもらっても良いかもしれない。
- インターン生には挑戦的な業務をしてもらうのが良いと思う。インターンが会社のPRの一環だと捉えると、挑戦的な業務を行えるということは会社の良い面をアピールすることにもなるからだ。
- たとえ失敗したとしても、チームはその失敗から得た教訓を活かすことができるし、インターン生は趣味の範囲では経験できないような失敗をするという経験を得ることができる。
- 余談だけど、許容される範囲で失敗をするというのは学習においてとても重要だ。なぜなら、成功した理由というものは説明が難しいことが多く、かならずしもパターン化できない。しかし、失敗した理由を説明することは（簡単ではないが）可能であり、理由がわかればパターン化できるからだ。よって、失敗したほうが成長機会に結びつけやすい。

まとめ

インターンを受け入れたことで、より多くの学びを得ることができた。また、これまで手つかずだったChaos engineeringを導入するきっかけにもなったし、インターン生だけでなくチームにとっても実りのあるものに出来たと思う。とはいえ、まだまだ反省点は多いので、次回はちゃんと態勢を整えて、より良いインターンを提供できるようにしなければならない。

おしまい。

Goのtime.LoadLocationには外部依存性がある

2019-07-16T00:42:42+09:00

Exective Summary

Goのtime.LoadLocationには外部依存性があるので、引数に空白("")、UTC、Local(time.Localにタイムゾーンを設定している場合)のいずれかではない場合（例えばAsia/Tokyo）は unknown time zoneというエラーがでる場合がある。対策としてはtime.Local = time.FixedZone("Local", 9*60*60)としてからtime.LoadLocation("Local")とすれば良い。

本編

Goではtime.LoadLocationを利用してタイムゾーンの情報を得ることができる。得たタイムゾーンの情報は、例えばtime.ParseInLocationという関数で使うことができる。一連の使い方の例として、公式ドキュメントでは以下のような例が示されている。

package main

import (
    "fmt"
    "time"
)

func main() {
    loc, _ := time.LoadLocation("Europe/Berlin")

    const longForm = "Jan 2, 2006 at 3:04pm (MST)"
    t, _ := time.ParseInLocation(longForm, "Jul 9, 2012 at 5:02am (CEST)", loc)
    fmt.Println(t)

    // Note: without explicit zone, returns time in given location.
    const shortForm = "2006-Jan-02T03"
    t, _ = time.ParseInLocation(shortForm, "2012-Jul-09T01", loc)
    fmt.Println(t)

}

例ではEurope/Berlinがタイムゾーンとして設定されているが、これは実行環境にあるタイムゾーンの設定ファイルなどを参照するために使われている。よって、Alpineのように何も環境下でtime.ParseInLocationを実行して迂闊にタイムゾーンの名前を渡すと、 unknown time zoneというエラーが発生してアプリケーションが実行できなくなる。そんな場合はtime.Local = time.FixedZone("Local", 9*60*60)のように予めtime.Localにタイムゾーンの設定情報を入れておいてtime.LoadLocation("Local")とすることでエラーを防ぎ、かつアプリケーションから外部依存性を取り除くことが出来る。

// https://play.golang.org/p/lRiZxwT1u-U
package main

import (
    "fmt"
    "time"
)

func main() {
    time.Local = time.FixedZone("Local", 9*60*60)
    jst, _ := time.LoadLocation("Local")

    layout := "2006-01-02T15:04:05"
    t, _ := time.ParseInLocation(layout, "2019-07-15T20:21:22", jst)
    fmt.Println(t)  // Print "2019-07-15 20:21:22 +0900 Local"
}

もう少し踏み込んで確認したい場合はソースコードを読んでみると良い。

おしまい。

tmrts/go-patternsのBuilder Patternを日本語に勝手訳した

2019-04-21T23:35:17+09:00

この記事は https://github.com/tmrts/go-patterns/blob/master/creational/builder.md を勝手に翻訳したものです。なので、内容の正確さは全く保証されてません。なので、気になる人はちゃんとオリジナルのコンテンツを読みましょう。（とはいえ、誤訳は指摘してもらえると嬉しい…

Builder Pattern

Builder patternとは、複雑なオブジェクトの表現から生成（コンストラクト）を分離させたものであるので、同じコンストラクトの処理で異なる表現を作成することができる。

Goにおいては、通常、設定用のstructが同じふるまいを達成するために使われる。ただし、builder methodにstructを渡すということはif cfg.Field != nil {...}というチェックのボイラプレートのコードで満たすことができる。

実装

package car

type Speed float64

const (
    MPH Speed = 1
    KPH       = 1.60934
)

type Color string

const (
    BlueColor  Color = "blue"
    GreenColor       = "green"
    RedColor         = "red"
)

type Wheels string

const (
    SportsWheels Wheels = "sports"
    SteelWheels         = "steel"
)

type Builder interface {
    Color(Color) Builder
    Wheels(Wheels) Builder
    TopSpeed(Speed) Builder
    Build() Interface
}

type Interface interface {
    Drive() error
    Stop() error
}

使い方

assembly := car.NewBuilder().Paint(car.RedColor)

familyCar := assembly.Wheels(car.SportsWheels).TopSpeed(50 * car.MPH).Build()
familyCar.Drive()

sportsCar := assembly.Wheels(car.SteelWheels).TopSpeed(150 * car.MPH).Build()
sportsCar.Drive()

所感

（これは訳者、つまりこの記事を書いている人の勝手な意見）
同じコンストラクタを使って、パラメータに応じて異なる動作をする何かを生成するときに使えそう。例えば、異なるDBドライバを利用する何かだったり、コンテナのランタイムに応じて内部的な動作を切り替えるドライバ的な何かとか？サンプルコードの車の例はわかりやすくて理解に役立った。

PythonのEnumのvalueの設定にはauto()をつかい、検索にはEnumのnameを使うのが良い

2019-04-17T21:13:31+09:00

Python3.4ぐらいから導入されて、3.6ぐらいからまともに使えるようになったEnumとかいうのがある。
* https://docs.python.org/ja/3/library/enum.html

Enumが便利なのは、その名の通り、明示的に値を列挙するので、利用可能な値を確実に表現することができる。例えば、利用可能な値として色を表現するときには以下のようにできる。

from enum import Enum

class Color(Enum):
    red = "red"
    blue = "blue"
    green = "green"

このように定義すれば、

>>> print(Color.red)
Color.red

と記述できるので、コードの表現力が高くなるし、通常、ただの定数などで"red"と書く場合に比べて圧倒的にタイポしにくい（IDEなどによる補完が期待できるので）。

で、ある値が上のように定義したColorの中に含まれているかを探したいときがある。その場合、値はEnumの値ではなく名前を使って検索したほうが良い。この辺の感覚、普段からちゃんと（？）Enumを使っていればわかるんだけど、Enumはドキュメントにも書かれているように

列挙型は、一意の定数値に束縛された識別名 (メンバー) の集合

なので、確実に一意が約束されているのは値ではなく名前のほう。なので、以下のように定義することができるため、

from enum import Enum

class Color(Enum):
    red = "ao"
    blue = "ao"
    green = "midori"

以下のような事故が起きる可能性がある。

>>> # Color.blueを探したい
>>> for c in Color:
>>>     if c.value == "ao":
>>>         print(c)

Color.red

また、Enumの値は重複させることができるので、そもそも値で検索しても一意が保証されない。よって、Enumを利用するときはちゃんと名前を利用すること。そうすれば、ある値がEnumの中で定義されているかどうかは簡単に見つけることができる。

>>> # ちゃんとnameで検索すること
>>> "blue" in Color.__members__
True

ということで、値を設定しない場合はenum.auto()が使えるので、コーディング規約として、特別な理由がない限りはEnumに値を設定しないことにしたほうが良さそう。

from enum import Enum, auto
class Color(Enum):
    red = auto()  # 上から連番が振られる
    blue = auto()
    gree = auto()

障害が起きたときに誰が謝るのかという問題（社内サービス編）

2019-04-12T23:52:08+09:00

今は社内の開発者向けにサービス開発をしていて、まぁまぁの人数に使ってもらっている。で、サービスはまだまだ発展途上なので、リリースしてからもたまにシステムメンテナンスなどを行うことがある。まぁそんな感じでちょいちょい本番系をイジることがあるわけだけど、今日はそのメンテナンスをきっかけに障害が発生した。

ここで問題なのは障害が発生したことではなくて（もちろん障害それ自体は問題なのだけど）、障害をどうハンドリングするかっていうこと。ここで言うハンドリングというのは、

障害を調査し、解決すること
障害を拡大させないために作業を指示すること
障害の内容を利用者に説明すること

通常、これらをすべてうまくこなせるのは障害を起こした本人だったりする（もちろんそれなりに技術や知識があることを必要とする）。であるならば、障害を起こした人はどの作業に専念すべきだろうか？これは当然#1である。次に#2で、#3。ということで、対応の優先度は上から順番に行うべき。

とはいえ、実際のところ、それなりにいるユーザーたちからは苦情が上がってくるわけで、障害内容を説明しなければならない。で、この説明を考えるのはそれなりに難しい。もちろん嘘をつくのはダメだけど、とはいえ、どこまで内容を詳らかにするか。そして、正確に問題を説明できるのも障害を起こした本人。そして、なぜ#2を行わなければならないのかを説明できるのも障害を起こした本人。

こんな感じであらゆることが障害を起こした本人にのしかかってくる。ここでようやく本題に入るわけなんだけど、一番やりたくない（というか、やる必要性が無い）し、面倒なのは、問題を説明し謝ることじゃないかなと思う。それに、当事者が謝るべきという考え方だと失敗を責める文化ができてしまって挑戦的な試みができなくなる組織になる。

で、じゃあ他に誰が謝るのかということになる。謝るためには事態を正確に把握し、理解する必要があるけど、実際には無理。解決しようとする人を捕まえて、理解できるまで逐一説明させるとか自己満足でしかない。なので、（良い意味で）ごまかしが出来るセンスが必要になる。自分にはそういった感じのセンスがあるかなと思ってたけど、結局最後には障害を起こした本人に謝らせることになってしまった。まぁそれは本人が自主的にそうしたから、そうなったんだけど最後までちゃんと謝ることができなくて、ふがいないなーと思ったっていう、ただそれだけのために1000文字ぐらいをここに書いた。

dockerをGracefulにreloadできるかどうか

2019-04-11T00:23:13+09:00

TL;DR

出来る。
けど、reloadで反映される設定は限られているので、https://docs.docker.com/v17.09/engine/reference/commandline/dockerd/#miscellaneous-optionsをよく読んで検証すること。

Main

最近知ったんだけど、dockerにはlog-optというオプションがあり、これを使うことで簡易なログローテートを行うことができる。
- https://docs.docker.com/config/containers/logging/configure/#configure-the-default-logging-driver

で、これを適用する必要があるんだけど、そういうときというのは大抵サービスが稼働中であり、サービスを止めずに設定を適用したい。例えばこれがNginxならreloadで（大抵の場合は）安全に設定を読み込ませることができるけど、それがdockerでも可能なのかどうか、ということを確認したい。

対象のdockerはCentOS7の上で動いているので、まずはUnitファイルを見る。

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
...

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H unix://
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
...
[Install]
WantedBy=multi-user.target

ExecReloadが設定されているのでとりあえずsystemctl reload docker.serviceというコマンドを実行することはできそう。じゃあ次は、実際にコンテナが動作している最中に実行したらどうなるかを見てみる。

それっぽい状況を作るためにまず、Nginxのコンテナを立ち上げて外部から毎秒アクセスする。もう１つ適当なコンテナを立ち上げてコンテナ内部で毎秒dateコマンドを実行する。なお、どちらもフォアグラウンドで動かしている。もしdockerがgracefulに設定を読み込むことができるのならば、各コンテナは正常に動作し続けるはず。

まずはreloadする前の状態。

$ sudo systemctl status docker.service

● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-12-05 14:55:37 JST; 4 months 4 days ago
     Docs: https://docs.docker.com
  Process: 27038 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 2432 (dockerd)
    Tasks: 57
   Memory: 632.9M
   CGroup: /system.slice/docker.service
           ├─ 2432 /usr/bin/dockerd -H unix://
           ├─ 2451 containerd --config /var/run/docker/containerd/containerd.toml...
           ├─23228 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8...
           ├─23235 containerd-shim -namespace moby -workdir /var/lib/docker/conta...
           └─26843 containerd-shim -namespace moby -workdir /var/lib/docker/conta...

Apr 10 23:26:23 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:26:51 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:26:51 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:27:09 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:09 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:27 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:27 localhost dockerd[2432]: time="2019-04-10...
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Hint: Some lines were ellipsized, use -l to show in full.

reloadした後。

$ sudo systemctl status docker.service

● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2018-12-05 14:55:37 JST; 4 months 4 days ago
     Docs: https://docs.docker.com
  Process: 30027 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 2432 (dockerd)
    Tasks: 57
   Memory: 632.9M
   CGroup: /system.slice/docker.service
           ├─ 2432 /usr/bin/dockerd -H unix://
           ├─ 2451 containerd --config /var/run/docker/containerd/containerd.toml...
           ├─23228 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8...
           ├─23235 containerd-shim -namespace moby -workdir /var/lib/docker/conta...
           └─26843 containerd-shim -namespace moby -workdir /var/lib/docker/conta...

Apr 10 23:26:23 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:26:51 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:26:51 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:27:09 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:09 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:27 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:38:27 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:44:51 localhost dockerd[2432]: time="2019-04-10...
Apr 10 23:44:51 localhost dockerd[2432]: time="2019-04-10...
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Hint: Some lines were ellipsized, use -l to show in full.

…とくにプロセス番号などは変わっていないし、動作中のコンテナは稼働し続けていて特に問題はなさそうだった。なので、reloadコマンドでプロセスが落ちる心配はしなくて良さそう。が、設定は反映されなかった。調べてみると、reloadで反映される設定は限定されており、log-optsは含まれていなかった…

https://docs.docker.com/v17.09/engine/reference/commandline/dockerd/#miscellaneous-optionsの"CONFIGURATION RELOAD BEHAVIOR"

うーむ…というわけで、log-optsの設定を変更するにはrestartするしかない。めんどいなーとは思うが仕方ないね。

ちなみに、dockerにはlive-restoreという機能があるので、これを使えばダウンタイムをなるべく減らすことができる。ただし、起動に時間がかかるコンテナ、例えばMySQLみたいやつ、だとこれは悪い方向に働く可能性があるので、注意して使う必要がある。

shigeの投稿 - Crieit

2019年を振り返るポエム

手軽にGoのResponse.Bodyを再利用したいとき

パイプで受け取った標準入力を列ごとに読みこんで配列っぽく処理したい

空白区切りの行から特定位置の文字列を取り出すためにawkを使っている。

数字を比較している

初めて学生インターンを受け入れて感じたこと 2019夏

Goのtime.LoadLocationには外部依存性がある

tmrts/go-patternsのBuilder Patternを日本語に勝手訳した

PythonのEnumのvalueの設定にはauto()をつかい、検索にはEnumのnameを使うのが良い

障害が起きたときに誰が謝るのかという問題（社内サービス編）

dockerをGracefulにreloadできるかどうか

空白区切りの行から特定位置の文字列を取り出すために`awk`を使っている。