2020-12-08

【Docker】Dockerのドキュメントを読んで知らなかったことをメモ_ベストプラクティス編

Docker

雰囲気でDocker, docker-composeを使っているので一度ドキュメントを読んでみて怪しかったところをメモ

docs.docker.jp

コピペ＋所感という内容なので記事としての価値はないです（メモ書き）

イメージを小さく

適切なベースイメージ

適切なベースイメージで始めましょう。たとえば、 JDK が必要なら、一般的な ubuntu イメージに openjdk をインストールするのではなく、公式 openjdk イメージをベースにするのを検討します。

これはわかる。超軽量なイメージをつくる！みたいな記事はたまに見るけど、そっちの方向に頑張ることはあまりしそうもない

レイヤをへらす

RUN命令をまとめることでレイヤを減らす
みんなオシャレでやってるのかと思ってた

RUN apt-get -y update
RUN apt-get install -y python

↓

RUN apt-get -y update && apt-get install -y python

因みにレイヤを増やすのはRUN, COPY, ADD命令だけ

命令における複数行にわたす引数の並びはabc順

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#id13

abc順が作法的に間違えにくく良いらしい。考えたことなかった
パッケージの重複指定の危険が減るとか言われてみれば確かに

RUN apt-get update && apt-get install -y \
  bzr \
  cvs \
  git \
  mercurial \
  subversion

マルチステージ・ビルド

https://docs.docker.jp/develop/develop-images/multistage-build.html

知らなかった
ビルドする環境と実行する環境を分けて最終的なイメージのサイズを小さくできる
多分他にもいろいろやれそう

ビルドコンテクスト

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#understand-build-context

docker build の -f オプションでdockerfileのある場所を指定するんだけど、そのdockerfileがあるところ、現在作業しているディレクトリをビルドコンテクストと呼ぶらしい

以下のように指定すればdockerfileと資材のディレクトリを分けられる

mkdir -p dockerfiles context
mv Dockerfile dockerfiles && mv hello context
docker build context -f dockerfiles/Dockerfile

stdinを通してDockerfileをパイプ

普通のやつ

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#stdin-dockerfile

以下は同じ

echo -e 'FROM busybox\nRUN echo "hello world"' | docker build -

docker build -<<EOF
FROM busybox
RUN echo "hello world"
EOF

docker build -のハイフンでDockerfileのPATHに代わりその内容を渡すような感じ

あんまり使うことはなさそう

gitリポジトリの資材を使う

-f でgitを指定しつつ、そこにハイフンを付け足して -f- とすることで、
gitをcloneしてその資材をstdinで流し込むDockerfile(の構文)の中で利用できる

docker build -t myimage:latest -f- https://github.com/docker-library/hello-world.git <<EOF
FROM busybox
COPY hello.c .
EOF

こんなややこしいことをする機会があるのかわからない
git利用しない方含め、1枚のshellscriptファイルで色々完結させたい時には使うかもしれない

.dockerignore

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#dockerignore

あんまり書いたことないかも
node_modulesあたりは除外するんだろう

ビルドキャッシュ

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#leverage-build-cache

あんま考えてなかった

キャッシュを使いたくない時は

docker build に --no-cache=true を指定

ADD, COPYコマンドはファイルの内容についてチェックサムを計算
それ以外の場合はコマンド文字列そのものがキャッシュの一致判断に利用される（ファイルは見ない）

ということを思うとcurlだのapt-getして取得してくるものが古いとか、そういう時に考えることになりそう

Dockerfile

LABEL

イメージには複数ラベルが設定でき、昔はLABELコマンドで余分なレイヤの追加を避けるために1行で設定していたらしいけど、いまは1行である必要はない
でも1行で書くのはまだサポートされてるし見栄え的にもそっちの方がよさそう

LABEL vendor=ACME\ Incorporated \
      com.example.is-beta= \
      com.example.is-production="" \
      com.example.version="0.0.1-beta" \
      com.example.release-date="2015-02-12"

RUN

apt-get自体のupgradeはダメ

RUN apt-get upgrade や dist-upgrade の実行は避けてください。ベース・イメージに含まれる重要パッケージは、権限が与えられていないコンテナ内ではほとんど更新できないからです。（中略） foo というパッケージを更新する必要があれば、 apt-get install -y foo を利用してください。

知らなかった！

apt-get update と apt-get install は同一RUNで実行すること

RUN apt-get update と apt-get install は、同一の RUN コマンド内にて同時実行するようにしてください。たとえば以下のようにします。

RUN apt-get update && apt-get install -y \
    package-bar \
    package-baz \
    package-foo

知らなかった！

キャッシュの問題。詳しくは直接ドキュメント見たほうがいい

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#apt-get

aptキャッシュを消す

RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    dpkg-sig \
    libcap-dev \
    libsqlite3-dev \
    mercurial \
    reprepro \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \
 && rm -rf /var/lib/apt/lists/*

最後にaptキャッシュを消してイメージサイズを小さくしている

公式のDebianとUbuntuのイメージは自動でこれやってるから明示的にやる必要はなし

パイプを利用する処理でエラーを検知

RUN wget -O - https://some.site | wc -l > /number

※wgetした行数をhoge(ファイル)に吐く

これだとwgetが失敗してもwc -lが成功すればコマンドが失敗とはならずビルドが通ってしまう

パイプ内のどの段階でもエラー即コマンド失敗にするためには set -o pipefail && を使う
(シェルが-o pipefailオプションに対応してないとダメだけど)

RUN set -o pipefail && wget -O - https://some.site | wc -l > /number

CMD

CMDはイメージ内に含まれるソフトウェアを実行するために用いるもの

CMD ["実行モジュール名", "引数1", "引数2" …] の形式
CMD ["apache2","-DFOREGROUND"] みたいな

RUNとの使い分けをあんま考えてなかった！

ENV

環境変数の設定にもPATHの設定にも使うというのはよくある話

ENV PATH /usr/local/nginx/bin:$PATH
ENV PASSWORD="xxx"

アプリケーションのバージョン固定にも使うと便利とのこと

ENV PG_MAJOR 9.3
ENV PG_VERSION 9.3.4
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH

ENVによって中間レイヤが作成されるため、環境変数をセットしたのと別の行でunsetしても値は保持されてしまう
それに対応するには～...というのがドキュメントに書いてあるけどあんまり使う機会はなさそう
迂闊にunsetしてるコードを見たら思い出したい

https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#apt-get

ADDとCOPY

使い分け

COPY：ローカルからコンテナにコピーするだけ
ADD：ローカルでのtar展開やリモートURLサポートもついてる！

ややこしいからCOPYを優先して使う
ADDを使うのはローカルのtarを展開してイメージに書き込むときだけ
ADD rootfs.tar.xz /

複数ステップで異なるファイルをコピー

まとめずに個別にコピーすると、個々のステップのキャッシュのビルドが最低限に抑えられる

# こっちより
COPY . /tmp/
RUN pip install /tmp/requirements.txt

# こっちのほうが望ましい
COPY requirements.txt /tmp/
RUN pip install /tmp/requirements.txt
COPY . /tmp/

上の例だとローカルのコンテクストの中で差分があったら、COPYコマンドのキャッシュが無効化される
下の例ならrequirements.txtに差分があればそこのCOPYだけキャッシュ無効化、それ以外のコンテクストに差分があればそっちCOPYだけキャッシュ無効化
ということになる（はず）

リモートURLからパッケージを取得する場合ADDじゃなくてcurlやwget

イメージサイズの問題

こうしておくことで、ファイルを取得し展開した後や、イメージ内の他のレイヤにファイルを加える必要がないのであれば、その後にファイルを削除することができます

消せばイメージのサイズを小さくできるということだと思う（消さないならどっちでもいいのか？レイヤの問題？）

# だめ
ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
# よい
RUN mkdir -p /usr/src/things \
    && curl -SL http://example.com/big.tar.xz | tar -xJC /usr/src/things \
    && make -C /usr/src/things all

USER

サービスが特権ユーザでなくても実行できる場合は、 USER を用いて非 root ユーザに変更します。
ユーザとグループを生成するところから始めてください。Dockerfile 内にてたとえば
RUN groupadd -r postgres && useradd -r -g postgres postgres

こうしてユーザとグループを作ったあとで、
USER <user>[:<group>] or USER <UID>[:<GID>]を書いておくことで、それから先のRUN, CMD, ENTRYPOINTのコマンドを指定したユーザで実行する

ついでにsudoのインストールと利用は避けよう！とのこと

WORKDIR

絶対パスで書こう！

RUN cd ... && do-somethig みたいなことをせずWORKDIRを使おう！

さぼりがち

ONBUILD

コマンド自体を知らなかった

親側のイメージに処理を仕込んでおくと、
それをFROMとして作られる子のイメージで処理を実行させられる感じ

ここの例がわかりやすい

https://deeeet.com/writing/2014/03/21/docker-onbuild/

自分で書くことはほぼ無いんじゃないかと思うけど、このコマンドを知っておかないと、これが使われてた時に混乱することになりそう

2020-12-04

ソビエトロシアの文学メモ

Муза

私の才は乏しく、声も大きくはない、
だが私は生きており、私の存在も
この地上の誰かにとっては愛しいのだ。
はるか後の人々は、詩の中に
私のことを見出してくれるだろう。
誰が知ろう、私の心が
彼らの心と結びついて、
私が同世代に友を見出し得たように、
後の世代に読者を見出し得ないなどと。
　
E.A.バラティンスキー
https://twitter.com/kyuseisya_/status/1211890434609299457

Мой дар убог, и голос мой не громок,
Но я живу, и на земли мое
Кому-нибудь любезно бытие:
Его найдет далекий мой потомок
В моих стихах; как знать? душа моя
Окажется с душой его в сношенье,
И как нашел я друга в поколенье,
Читателя найду в потомстве я.
　
<1828>
Русские поэты. Антология в четырех томах.
Москва: Детская литература, 1968.
Евгений Баратынский - RUSSIAN POETRY

ロシア語のWikipediaが詳しい
Баратынский, Евгений Абрамович - Wikipedia

これは僕が大変気に入ってる詩で、僕が写真をせっせと撮る理由それそのもの
この詩を知ったときには喜んだものだった！
いつかこの詩を印刷して額に入れて家に飾りたい

Умом Россию не понять

ロシアは頭ではわからぬ
並みの尺度では測れぬ
ロシアならではの特質がある
ロシアは信じることができるのみ
　
フョードル・チュッチェフ
ロシアのアフォリズム5選 - RUSSIA BEYOND

Умом Россию не понять,
Аршином общим не измерить:
У ней особенная стать —
В Россию можно только верить.
　
Умом Россию не понять - Wikipedia

この詩を諳んじるとロシア人に喜ばれるらしい
日本でいう「春はあけぼの」みたいな

いつか役に立つ日がくるはずだ、と心に留めている詩だけど一向にその機会がこない
なんならこれがプリントされたTシャツを持っている

汎スラブ主義色

www.abysse.co.jp

赤：自由のために流された血
白：まばゆく輝く光明・清潔
青：澄みわたる空

※画像を貼るのがめんどくさいのでリンク先（引用元）を見ること

ロシアの国歌を聴く時にこれを知っていると音に深みが出る

2020-11-27

恵比寿住みやすさレビュー

恵比寿の狭いマンションに7年住んだ。で引っ越すのでレビューする

はじめに

恵比寿について、僕はいつも「交通的に便利だけど、所詮それだけ。」と言ってた

大人の街なんて呼ばれてたり、よくデートスポットが紹介されたりしていて...
でもそこは僕がヘヴィメタルのTシャツきて短パン履いて散歩するコースだよ。残念だったね

一方僕はデトロイト・メタル・シティの根岸（渋谷系が好きなポップミュージシャン志望だけどメタルをやっている）みたいな人間なので、案外丁寧な暮らしが好きで、そこそこ気に入った街だったのだ......

いいところ

交通的に便利

超便利。文句一切なし。終電を気にしたことはほぼない

大船まで直通なので輪行して海まで行ったりも気軽

街が洗練されている

行きもしないカフェとか、行きもしないケーキ屋とか、そういうのがある街が良い
歩いていて楽しいし、活気が感じられる

そうでありながらも渋谷・原宿のうるさい雰囲気がないのは流石大人の街というところか...悔しいけど...

※この文章は三鷹の賃貸周辺を見に行った後に書いたもので、
　僕は三鷹の街の凡庸さ（チェーンばっか）、老人の多さに驚き、しょんぼりしたのだった...... 　若者文化は自分とは縁のないものだと思ってたけど、やっぱ大事だった

代官山駅が徒歩圏内

散歩するだけで楽しいし、渋谷まで出ずに東横使えるのは結構便利
代官山蔦屋書店には大量のCDを借りによく行った

土地柄、服屋も多くてセールに一回いって住所とか書いておくとセールの度にDMが届くようになって便利

中目黒も徒歩圏内

中目黒の居酒屋は恵比寿・代官山より気楽な感じが良い。まあ、それだけなんだけど

ついでに目黒も徒歩圏内だけどあんまり行く用事はないかな
カレー屋くらい

東京都写真美術館ほか展示スペースが徒歩圏内

ここまで文化的な意味での生活基盤が揃っていることは中々ないと思う

カメラ屋が徒歩圏内に2件

代官山のGTカメラ、恵比寿の大沢カメラ（現像もできる）
前者は行きつけ

実はカレー屋が豊富

これはどっか別で書きたいけど、実は美味しいカレー屋が豊富
前述の通り中目黒とか目黒にも美味しいところがたくさん！

自転車に乗ると色んなところに行ける

そりゃそうだけど、都心だから東西南北色んなところに行きやすい印象

東は広尾、品川、六本木、頑張って銀座
西は松濤、駒場
北は渋谷、原宿
南はちょっと頑張って自由が丘、頑張って多摩川

ここらへんにはよく足を運んだ

だめなところ

物価が高い

ピーコックストアの高さに辟易して広尾の肉のハナマサ、渋谷のライフまで買い出しに行ってた
ピーコックストアでさえ高いのに無駄に成城石井やザ・ガーデン自由が丘が駅ビルに入っている。バカか？

たまにバカがくる

僕が住んでいたのは閑静な住宅街だけど、まあちょっと歩けば居酒屋街なので迷惑な奴らがたまに迷い込んできて夜中に叫ぶ山から出てくるな

周りのマンションの工事が多い

たまに気が狂うほどうるさい時期が続き、周りに何もない皇居に住みたくなる

名ばかりのラーメン激戦区

笑わせないでほしい。前述の通りカレー屋の方がいいよ

恵比寿横丁と相席屋

僕に言わせると恵比寿の汚点

恵比寿横丁が渋谷横丁として宮下公園に輸出された際の僕の落胆は計り知れないものだった

他、どうでもいいこととか

空自の目黒基地がある
代官山の旧朝倉家住宅ってとこがそこそこ楽しい
恵比寿ガーデンプレイス側は基本的に高地。なのでそこらへんに住むと坂を感じる
高級な美容室が無駄に多い
リキッドルームがある（ライブハウス）
ワニブックス、オーバーラップ、バンダイナムコアーツとかのオフィスがある
ウェスティンホテルにはたまに結婚式の関係で馬車がいる

さいごに

恵比寿に住んだ僕から見た住みたい街は

恵比寿
広尾
白金
麻布十番
代官山
松濤
駒場
中目黒
自由が丘
田園調布

舌が肥えてしまった。なにより街には品位があるべきだと思う

恵比寿はなんだかんだでいい街だったと思う
部屋が狭くていい人、あるいは高所得者は是非住んでください

2020-11-20

長い打ち合わせを短くするためにやったこと

開発組織

はじめに（前提など）

打ち合わせが長くて、すごく辛かったので短くするために頑張った

チーム

僕のチームではスクラム開発をしていて、スプリントの期間は1週間

7人いて、2人は企画、5人は開発

週のスケジュール

まず前提として週のスケジュールはこんな感じ

以前それぞれのイベントにかかっていた時間と（今回の話で書いている努力の結果として）短くなった今の所要時間も書いている

イベント	頻度	予定時間	以前の所要時間	今の所要時間	備考
プランニング	週1	2h	3h	1.5h	短くなった！
レビュー	週1	1h	1h	1h
レトロスペクティブ	週1	1h	2h	1h	短くなった！
朝打ち合わせ(進捗報告)	毎日	15m	1.5h	15m	間延びしなくなった！
夕打ち合わせ(困ってること報告)	毎日	0.5h	0.5h	0.5h	報告内容に依る
突発打ち合わせ(仕様や実装の相談)	週2くらい	決まってない	0.5h ~ 2h	~ 1h	短くなった！

※スクラムイベントとかの用語の雑な説明

スプリント：開発の期間。僕のチームでは1週間
プランニング：スプリントの期間にこなす作業の計画を立てる打ち上わせ
レビュー：スプリントの期間にこなした作業の報告を偉い人にして、フィードバックをもらう打ち合わせ
レトロスペクティブ：スプリントの期間の反省会

やったことの概要

基本的に施策をひたすら打ちまくることでヒットを狙っていった

以下にそれらを列挙するので参考にしてね

打ち合わせのルール、司会として頑張ることの2軸になっている

やったことの詳細

ルール編

チームのルールとして設けてみたこと

打ち合わせの司会なんてものは役割でしかなくて、本来誰かがやればいいし何なら毎回交代でもいい
誰でも司会ができるように（やりやすいように）ルールを構築しておくと良い

他所では暗黙の状態で成立しているであろうモノ（率直に言うと程度が低いモノ...）も多いと思う。正直

会話を被せるのを止めてもらう

喋りやすくなるから

残念ながらうまく定着しなかった

打ち合わせの際に口頭で話を整理しない。テキストエディタに書き出し画面共有する

文章で捉えたほうが絶対に分かりやすい
っていうか社会人なら打ち合わせ中にメモくらいとるでしょ、ということでそれを画面共有する

頭がいい人は時として論理が飛躍するのでその対策
話についていけない人の救済手段
そのまま議事録にもなる
実装の話とか書いておかないと忘れがち
複数人が同じメモをとる手間が省ける

書き出しは自然言語に堪能で、要約・構造可がうまい人がやるといい

※新卒で入ったSIerにいた時は50歳くらいのベテラン部長がやっていた
　辞めた今思えばあの人の書き出しは非常に優れていたし、巨大なプロジェクトを束ねる素養の一部は間違いなくそこにあった

打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく

打ち合わせ直前の資料共有はよしとしない。前もって回覧させる

「持ち帰って確認します」をなるべく事前に解消する

打ち合わせを行う前に共有の場か議論の場か明確にする

共有の場では極力議論をさせない
上に書いたとおり論点はなるべく打ち合わせ前に処理しておく

逆に考えると議論の場ってのはあんまりなくて、実装の相談とかブレストとかになるかな

場の区切りを明確にする

打ち合わせから打ち合わせへのナアナアな移行を許容しない

必ず打ち合わせ一つ一つを打ち切ってから別の議題に進む

例えば「一旦、朝の定例はこれで終わります。続いて定例で出た実装の疑問点についてですが～」

いちいち打ち合わせの場を設けない（打ち合わせにしない）

急いでない場合には打ち合わせじゃなくてチャットだとか、資料の回覧＋コメントで済む場合が多い
前述の「打ち合わせの議題・所要時間、資料を事前に共有する。必要に応じ打ち合わせの前にコメントを投げておく」を進めていった延長線上にあるルールかも

打ち合わせをすると元の作業から打ち合わせに移って、その後元の作業に戻って...と切り替えの手間が発生するというのもあるし（まあこれは打ち合わせタイミングの調整で多少マシになるけど）

※とはいえ、これはチームによってはNGかも、というかアジャイルソフトウェア宣言の以下の内容に反している

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 https://www.ipa.go.jp/files/000065601.pdf

個人的な意見だけど、僕は優れた日本語文章は発話より遥かにまともに情報を伝達すると思っている。適切に日本語が書ければ誤解は生まれにくい。うまくやらないとスピード感はあんまりないかもしれないけど

打ち合わせの決定事項・次のアクションを整理する

新卒みたいな程度の話なので割愛

司会としての努力編

場を仕切るというのは骨が折れるけど、どうしても必要になってくる

僕のチームでは一旦技術を集約させるため司会を二人に固定した

沈黙をなるべく作らない。次に進む

以下のようなシーンが多々ある

「ではこれでいこうと思います。問題ないですか？」
「(...沈黙...)」
「いいですか？」
「(...沈黙...)」

こういう時には沈黙を合意に捻じ曲げる

「では特に異論がなければこれでいきます。問題ないですね？」
「(...沈黙...)」
「ではこれ決定します」

一旦雑に合意しても本当に問題がある場合には「ちょっと待って」とか「(後からになって)そういえばさっきの箇所だけど...」と言ってもらえる

適当な人に「**さん、これで大丈夫だよね？」と聞いてしまってもいい
とはいえちょっと抜き打ちテストみたいになって心苦しさもある

そもそも沈黙しないでよ。と思わないでもない
「人が話していたら頷くなり相槌を打つなりしろ」と僕は少なくとも小学生の時には教えられた

関係ない話が長くなりそうだったら切る

例えば進捗報告の場で難しい実装の話をし始めたら切る

「それ長くなりそうなので後にしましょう」

これを言えるようになるまでなかなかに心労が...

論点のズレに敏感になる

議論が白熱してきたらチームメンバーに喋らせておいて、静観・整理してみる

たまに論点がズレていたり、論点が2つに分裂していたりする

「申し訳ないですが論点ズレてきている気がします。課題は**ですよね？」

これを言えるようになるまでなかなかに心労が... part2

問題が不透明な状態で問題について議論させない

論点のズレに近いかも

例えば、こういう話があったりする

「さっきの会議の中で出た話でAの案件で仕様変更が発生しそう！明日にはわかりそうだけど...」
「明日から着手するBの案件のタスク色々積んでるけど仕様変更の規模が大きいとマズイ！」
「A, Bの作業の優先順位どうする？Bのスケジュールずらさないといけないんじゃない？！」

ここでいう「不透明な問題」は案件Aの仕様変更の内容
それが確定しないまま、それについての話をしたところで当然フラフラした話にしかならない

なので問題の内容が不透明な状態でその問題について議論させるべきではない
※因みに上の例では、話の翌日に仕様変更の規模も小さかったことが判明。全くの杞憂だった

でも、のっぴきならない状況であれば、仮説に基づいて複数の対応パターン考えることになるとは思う

説明を人に委譲する

何でもかんでも司会が喋ればいいわけじゃないので、ある話題について得意な人がいたら任せる

当然といえば当然の話

打ち合わせが長引いてきたら圧をかける

「そろそろお腹が空いてきたので結論を出したいところですが...」

打ち合わせをきちんと終わらせる

だらだら次の話次の話と続いてしまう場合が多い（Slackで済む話が多い）
そういう時は無理やり切る

「あ～～！時間です！時間なのでこの打ち合わせはここまで！ではお疲れ様でした！」

いつも喋りにくそうな人がいたら別途理由を聞く

公の場だと激詰めみたいになりそうだったらコッソリ聞いてみてもいいかも

そういう人に限って案外話をまとめられたり、いい疑問を出してくれるのでなるべく改善を図る
その人のためだけではなく人的リソースを利活用するという意味で

打ち合わせが長いという共通認識をもつ

「打ち合わせ長いよね？！」とコッソリとチームメンバーに聞いてみる

共通認識を確認した上で「僕が打ち合わせを短くするよう頑張ります」と伝えておけば当事者意識を共有できる（巻き込める）

おわりに

人間は自由すぎるし中身に個人差があるので基本的にルールで縛ったほうがいい
ルールは人間を補ってくれる

打ち合わせ時間が短くなってから、「前は打ち合わせが憂鬱でした」みたいな話が出たりする
頑張った甲斐があったなぁ...（でも憂鬱だったなら行動起こしてよ！）

2020-10-30

【Go】sqliteとsqlxをおためしするだけ

概要

おためし用コード

テーブルをSeletctしてEntityにマッピングしたり、その時にフィールドにEnumがあったり、
EntityをそのままInsertしたり...

そういうのを一応動かしてみたかった
ついでにsqliteもお勉強のために使う

というコードを書いたのでせっかくだからのせる

sqlxの使い方は公式のreadmeみたほうがはやい

GitHub - jmoiron/sqlx: general purpose extensions to golang's database/sql

DB系ライブラリでどれ使おうか迷ってsqlxにした話も書きたい気持ちはあるけどまとめサイトみたいな感じにしかならないからまあいいか

構成

main.go
test.db(sqliteが作ってくれる)
enum
- member_type
  - membertype.go

enum周りのフォルダ構成は...どうするのがいいかな

コード

よめば分かる

main.go

package main

import (
    "fmt"
    "log"
    membertype "sqlite_sqlx/enum/member_type"

    "github.com/jmoiron/sqlx"
    _ "github.com/mattn/go-sqlite3"
)

// Driver
// go get github.com/mattn/go-sqlite3
// sqlx
// go get github.com/jmoiron/sqlx

const dbPath = "./db.sql"

const initQuery = `
DROP TABLE IF EXISTS members;
CREATE TABLE members (
  id INTEGER NOT NULL PRIMARY KEY,
  name VARCHAE(20) DEFAULT '',
  type INTEGER DEFAULT NULL -- 1:Human, 2:Beast, 3:Elf
);
INSERT INTO members (name, type) VALUES ("ペコリーヌ", 1);
INSERT INTO members (name, type) VALUES ("コッコロ",   3);
INSERT INTO members (name, type) VALUES ("キャル",     2);
`

type Member struct {
    ID   int                   `db:"id"`
    Name string                `db:"name"`
    Type membertype.MemberType `db:"type"`
}

func main() {
    // ドライバ名 + データソース名(なかったら作ってくれる)
    db, err := sqlx.Connect("sqlite3", "test.db")
    if err != nil {
        log.Fatalln(err)
    }

    // テーブルだけつくる
    db.MustExec(initQuery)

    // データ入れる
    chris := &Member{
        Name: "クリスティーナ",
        Type: membertype.Human,
    }
    transaction := db.MustBegin()
    transaction.NamedExec("INSERT INTO members (name, type) VALUES (:name, :type)", chris)
    transaction.Commit()

    // Select
    members := []Member{}
    err = db.Select(&members, "SELECT id, name, type FROM members")
    if err != nil {
        log.Fatalln(err)
    }

    // 見てみる
    for _, member := range members {
        // Typeは型がMemberTypeでそれらはString()メソッドを実装してるのでいい感じに出してくれる
        fmt.Println(member.ID, member.Name, member.Type)
    }
}

// 出力
// 1 ペコリーヌ ヒューマン
// 2 コッコロ エルフ
// 3 キャル ビースト
// 4 クリスティーナ ヒューマン

membertype.go

package membertype

type MemberType int

const (
    _ MemberType = iota
    Human
    Beast
    Elf
)

func (t MemberType) String() string {
    switch t {
    case Human:
        return "ヒューマン"
    case Beast:
        return "ビースト"
    case Elf:
        return "エルフ"
    case 0:
        panic("Unknown")
    }
    panic("Unknown value")
}

2020-10-12

『カイゼン・ジャーニー』感想

本開発組織

kaizenjourney.jp

公式サイトを見ると登場人物が絵になっててカワイイ！

会社で借りて読んだのでその感想というか、気に入ったとこのまとめ

気に入ったとこ

チームのWorking Agreementを決める

Working Agreementというのはチームの価値観・行動規範という感じのもの
取り決めとかルールって言ったほうがわかりやすい

僕はこの考え方が好き。人間はルールで縛ったほうがいい
でもルールを増やしすぎるとそれが軽い内容でも嫌がられるので難しい

試しにググったら良い取り組みをしている例があった

blog.engineer.adways.net

許可を求めるな謝罪せよ

何かの取り組みを始める時の話として、失敗を恐れず小さなところからやれ！という話が気に入った

「許可を求めるな謝罪せよ(It is easier to ask forgiveness than permission.)」という言葉を胸に。まずは"小さく試みる"ことだ。

いざ新しいことを始めるにあたっては、小さく試みることからスタートすることが大切です。大がかりに始めてしまうと、うまくいかなかったときに失敗の影響が大きくなってしまいます。

僕のチームでは最初から完璧を求めすぎるので、こういうことを大事にするべきだ（後述）

なぜチームで振り返りをするのか

僕はそもそもスクラム開発のチームでの振り返り（レトロスペクティブ）に懐疑的で、
「反省・改善ができる人間は一人でするし必要に応じてチームに展開もできるし、何故わざわざ全員でやるのか？」とか思っていた
（まあ、今でもまだそう思っている節がある）

というところでこの話は多少いい薬になった

そうか、他の人に気づかせてもらうんだ。自分で気づけないのはどうしようもない。だから、他の人に気づかせてもらう仕組みにしないといけないんだ。自分の経験や思考だけだと、自分自身が限界になる。でも、他人の経験や思考を活かす仕組みにすれば、自分の限界は越えられる。

こう考えるとチームの振り返りは他人の動きに対してもっとバシバシ意見が出るような形である方が有意義エンジニアはキツいこと言いがちなので難しいけど

失敗を積み重ねる

頻繁に変わる時代のニーズや市場の変化など、不確定要素が多々ある今日のソフトウェア開発では、プロダクトやプロセスをチームでふりかえりながら、継続的にカイゼンていくことが、より良い選択といえる。その際、Fail Fast(早く失敗する)の精神が、漸進的に開発していくことの後押しになる。

僕のチームではチームとしての取り組み・チャレンジを決める（やるんじゃなくて決めるだけ）にも最初から完璧を求めすぎるきらいがある振り返りの時間がが最たる例でそこで異様に討論して時間をかけすぎだ。というのが僕の意見 ※僕は完璧を求めすぎないという説もある

コードとしてのプロジェクトの根幹の設計とか、そういうとこは徹底的に最初から練るべきだけどそうじゃないところはさっさと試行してダメだったら変える、くらいの方が気が楽だと思う

何のためにアジャイルでやってるの？ウォーターフォールでやりたいの？とかたまに思う

越境する開発チーム

開発チームもプロダクトオーナーも互いの役割を学んでいこうね～、という話

役割を学ぶというと、ハイ学んだ終わり～って感じになりそうだけど、そういうことじゃなくて、
そもそもエンジニア以外にはわかりやすい言葉使うとか、そういう心掛けをこう...と僕も思う

スクラムマスターは役割

スクラムマスターは、役職でも専任でもなく、単なる役割ということを忘れてはならない。

内容はググれば出てくるだろうからいいか

アジャイルな見積もり、アジャイルな計画づくり

初期フェーズで長い期間をかけて、使えない緻密な計画を作成するよりも、現場で活用できる使える計画づくりをし続けることが重要なんです。

初期のリリース計画は、作成したら完成ではないのです。スプリントごとに毎回リリース計画を修正するといっても過言ではありません。むしろ積極的に変更するためにつくっていくのです。

僕のチームではプロダクトオーナーから「いつリリースできるんですか！」と詰められることがあるんだけど、
そもそも当初スケジュール立てた後、ろくに修正してなかった（そりゃわからんわ）

でも修正するのめんどくさいんだよね