今日は「ランサーズ開発ランチ」で登壇をしてきた．依頼を受けたテーマは「プロジェクトリード」だったけど，最近登壇しているものを再演しても，既視感があるかなと思って，今回はあえて「ZenHub」と「モブプログラミング」を詳細に深掘るテーマにした．質疑応答も多くて，素晴らしい雰囲気だった！
モブプログラミングの基礎を学べる「Getting Started with Mob Programming」の書評は別の記事にまとめている．今日見たところ，既に Retiredになっていて，販売中止になっていた！6月まで買えたのに...！
「プロジェクトリード」に関しては，以下の2記事が参考になると思う．
参加してから1週間たってしまったけど「Redash Meetup 3.0.0」のレポートを書く．Redash Meetup のコミュニティ立ち上げを手伝わせてもらったのが去年12月で，早くも6回目のイベント開催を実現できているし，参加者もどんどん増えているし，ああ，大きくなったなぁーとしみじみ感じていた．
今回も受付を担当させてもらった．コミュニティ運営者なら事前に見込んでいると思うキャンセルだけど，今回もそこそこ多かった．とは言え，過去最大の参加者が集まっていて，Redash の盛り上がりを感じることができた．
redash/handlers/api.pyを見るRedash API のエンドポイント一覧が載ったドキュメントがなく，結局 redash/handlers/api.pyを見るというのは，超あるあるで笑ってしまった．Redash のクエリは変更履歴が残らないため，自動抽出して GitHub に残す仕組みは素晴らしいし，会社的に重要なクエリが壊れるとリスクなので，もっと詳細を聞きたかった．とは言え，基本的には他人のクエリを修正できず，フォークを使うので，少人数だからこそ相互編集ができる権限設定にしてる感じかな？
Redash を導入したフェーズから，積極的に運用を回していくフェーズに移行するときに，必ず問題になる「クエリ乱立問題」にどう向き合ったのかという運用 Tips を聞くことができた．ある程度の規模になると，カテゴリなど，命名規則で戦うことになるのは必須で，さらにルールの脱線を見逃さないように誰かしら警察👮になると思う．メタテーブルを活用して「クエリ一覧を取得するクエリ」を作っているあたりは，上手な運用だなと思った．導入フェーズでは，僕の「Redash ハンズオン」を活用して頂いたとのことで，あざます！
マニアックなデータソースの詳細解説で，使ったことがないものもあり，深みがすごかった．Url Results は知っていたけど，実際に仕事で使う場面がなく，もしあれば聞いてみたい．
[公式]マークを付けられる会社の規模が大きくなると，運用も大変だし，Tableau を併用したりするんだなーと，聞いていて感じた．クエリに [公式]マークを付けるという運用は超良さそうで，その視点は今までなかった！あとグラフ線の配色ルールも，デフォルトのまま使うことが多かったので，これも目から鱗だった．
公開された資料，参加レポートなどを見ていて，Speaker Deck の闇がまだ知られていなさそうなので，2記事を貼っておく．タイトルだけじゃなく，Hatena Blog の Embed も最近はうまく動かないので，知っておくと良いと思う！
イベント中に 100 Star 🌟 達成！Redash 導入フェーズで是非活用頂けると！
今月のアップデートで，Mackerel コマンドラインツール mkr の公式 Docker イメージが公開された．
2年前に記事を書いているけど，CircleCI と mkr を組み合わせて Infrastructure as Code にした Mackerel の監視ルールを CI で回している．検証などで，一時的に修正した監視ルールがそのまま残ってしまうことを検知できるので，非常に便利！
ただし，8月末で CircleCI 1.0 のサポートが終了してしまうため，今までの仕組みをコンテナ化して，CircleCI 2.0 に対応させる必要があった．
5月時点では，まだ mkr の公式 Docker イメージが公開されていなかったため，自分で Dockerized して，Docker Hub に公開した．
Dockerfileは非常にシンプルで，Go の Alpine イメージに mkr をインストールしている．
FROM golang:alpine3.7 RUN apk add --no-cache git RUN go get github.com/mackerelio/mkr ENTRYPOINT ["mkr"]
CircleCI 2.0 の設定 .circleci/config.ymlもシンプルで，Dockerized した mkr を実行している．
version:2jobs:mkr-monitors-diff:docker:- image: kakakakakku/mkr steps:- checkout - run: mkr -v - run: mkr monitors diff -e -F monitors/monitors.json workflows:version:2ci:jobs:- mkr-monitors-diff
そこで，今回やっと公式 Docker イメージが公開されたので，自分で Dockerized したイメージを捨てることができる．
なんと言っても，公式 Docker イメージは「19.9MB」という，圧倒的な軽さになっている．
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE mackerel/mkr latest 3ce3d6655439 2 weeks ago 19.9MB kakakakakku/mkr latest 74807be95079 7 weeks ago 538MB
その秘密は Docker の「multi-stage builds」を使っているところで，以下の Dockerfileを見るとわかるように FROMが2個ある．簡単に言うと golang:alpine3.7でバイナリを生成しながら，イメージはバイナリを配置した alpine:3.7になっている．よって，Go 環境を捨てることができ，Alpine + バイナリだけになる．最高！
FROM golang:alpine3.7 RUN apk add --no-cache make git WORKDIR /go/src/github.com/mackerelio/mkr/ COPY . . RUN make build FROM alpine:3.7 RUN apk add --no-cache ca-certificates COPY --from=0 /go/src/github.com/mackerelio/mkr/mkr /usr/local/bin/ ENTRYPOINT ["/usr/local/bin/mkr"]
「multi-stage builds」の詳細は，公式ドキュメントに載っている．
mkr monitors以外にもオペレーションを効率化できる機能がたくさんあるため，公式 Docker イメージの公開は嬉しい！ローカル環境で使うオレオレ証明書を簡単に「保護された通信」に切り替えることができるコマンドラインツール「mkcert」を試した．先月に GitHub Trending に入っていて知ったのと，自分のローカル環境でオレオレ証明書を使っているときに，Chrome で警告が出ていたので（この接続ではプライバシーが保護されません），そのあたりを全て解決することができた．とにかく便利！
今回は brew で Mac にインストールした．既に brew に対応している．
$ brew install mkcert
最近，リリースタグにバイナリが含まれているので，もし Linux 環境で使う場合は，以下のように取得する．
$ wget -O /usr/local/bin/mkcert https://github.com/FiloSottile/mkcert/releases/download/v1.0.0/mkcert-v1.0.0-linux-amd64
詳しくは mkcert の README を読んでもらうとして，ザックリと仕組みを説明すると，単純にオレオレ証明書を作るのではなく，Mac 上にオレオレ認証局を作り，そこで署名をしている．このあたりの面倒な手順を全てコマンドラインツール側でやってくれている点がポイント．Mac で「キーチェーンアクセス」を開くと，確かに「ルート認証局」が追加されていた．
まず，認証局を作る．-installオプションを見て，個人的にはハイフンが1個なのが少し気になるけど...！
$ mkcert -install Using the local CA at "/Users/kakakakakku/Library/Application Support/mkcert"✨ The local CA is now installed in the system trust store! ⚡️
次に，証明書を作る．ドメイン固定でも良いし，サブドメインをワイルドカードにすることもできる．
# ドメイン固定の場合 $ mkcert local.kakakakakku.com Using the local CA at "/Users/kakakakakku/Library/Application Support/mkcert"✨ Created a new certificate valid for the following names 📜 - "local.kakakakakku.com" The certificate is at "./local.kakakakakku.com.pem" and the key at "./local.kakakakakku.com-key.pem"✅ # ワイルドカードの場合 $ mkcert *.kakakakakku.com Using the local CA at "/Users/kakakakakku/Library/Application Support/mkcert"✨ Created a new certificate valid for the following names 📜 - "*.kakakakakku.com" The certificate is at "./_wildcard.kakakakakku.com.pem" and the key at "./_wildcard.kakakakakku.com-key.pem"✅ # キーペアが作られる $ ls-1 *.pem _wildcard.kakakakakku.com-key.pem _wildcard.kakakakakku.com.pem local.kakakakakku.com-key.pem local.kakakakakku.com.pem
Vagrant 上に nginx を構築して，実際にオレオレ証明書（今回はワイルドカード）を試してみた．以下に nginx.confの一部を載せている．
server {
listen 443 ssl;
ssl_certificate _wildcard.kakakakakku.com.pem;
ssl_certificate_key _wildcard.kakakakakku.com-key.pem;
}すると「保護された通信」で接続することができた．
また「証明書」も確認することができた．
とにかく便利！
「misspell」は，Go で実装された typo 検出ライブラリで，手軽に実行できるので，英語のドキュメントに対してよく使っている．例えば，以下のようにワンライナーで "World"の typo を検知することができる．
$ echo'Hello Worls!'| misspell stdin:1:6: "Worls" is a misspelling of "World"
機能は他にもいろいろある．ディレクトリに対して実行することができたり，オートコレクトができたり，検知した結果を CSV 形式で出力することもできる．また，実際に使うときに必要になる除外リストの指定もできる．もし Go の lint で gometalinter を使っている場合，gometalinter から misspell を呼び出すこともできる．
今回紹介したいのは，CircleCI と misspell の組み合わせで，GitHub のリポジトリに対して misspell を実行することで，ドキュメントとコードの typo 検出を CI することができる．すごく便利で，個人的なリポジトリで使っている．既に Docker Hub にイメージが公開されているので，CircleCI の設定 .circleci/config.ymlも簡単で，以下のように書ける．ポイントは -errorオプションで，これを付けないと，エラーが出てもリターンコードが 0 になってしまう．
version:2jobs:misspell:docker:- image: nickg/misspell steps:- checkout - run: misspell -error . workflows:version:2ci:jobs:- misspell
以下に，サンプルでリポジトリを作った．README.mdと main.goにある "World"の typo を検知している．
README.md:3:6: "Worls" is a misspelling of "World" main.go:6:19: "worls" is a misspelling of "world" Exited with code 2
CircleCI + misspell の組み合わせを活用して，自動的に検知できる typo は減らしていきましょ！
最近 GitHub リポジトリに「バッジ」を設定するため「Shields.io」というサービスを使った．README.mdをオシャレにできて，とても便利だったので紹介しようと思う．ただ数年前からあったサービスらしく，今まで使ったことがなかった！
Shields.io の特徴は「バッジの種類の多さ」で，ウェブサイトを見ると，ザッと数えて 350 個以上ある．代表的なものを挙げてみた．
「Shields.io」から生成した URL にアクセスすると，SVG 形式の画像がオンデマンドに生成される．以下の例は指定した GitHub リポジトリの Star 数をバッジにしている．
https://img.shields.io/github/stars/kakakakakku/redash-hands-on.svg
?style=for-the-badgeのようにパラメータを指定することで，バッジスタイルを変更することができる．バッジスタイルは7種類から選ぶことができ，デフォルトは style=flatになっている．
style=plastic
style=flat
style=flat-square
style=for-the-badge
style=popout
style=popout-square
style=social以下の URL パターンで値を設定すると，カスタムバッジを作ることもできる．
https://img.shields.io/badge/<SUBJECT>-<STATUS>-<COLOR>.svg
サンプルとして，以下のようなバッジが作れる．
https://img.shields.io/badge/redash-v4.0.1-ff7964.svg?style=for-the-badge https://img.shields.io/badge/kakakakakku-blog--is--my--life-232f3e.svg?style=for-the-badge
実際に「GitHub / Docker / カスタム」を設定した．良さ！
確認する場合は以下のリポジトリにある．
Docker イメージなら「dockeri.co」も良かった．以下の URL パターンで Docker Hub のイメージ名を設定すると，大きめのバッジを作ることができる．
http://dockeri.co/image/kakakakakku/rubocop.co
「dockeri.co」の実装は以下にある．
「アウトプットを習慣化する」というスローガンを掲げて，これまで5年間以上，継続をしてきた．自分のノウハウを共有するために，イベントで「アウトプット」をテーマに登壇したこともある．
また，去年末から取り組んでいる「ブログメンター（アウトプットメンター）」という活動も，根源的なモチベーションは「習慣化に困っている人をサポートしたい」と言える．一部の人は「習慣化」を「気合で乗り切る」といった感覚で理解しているが，実際は「うまく目標設定をすること」が重要で，その「うまく」という表現は「小さく，定量的に，達成可能なレベルに」とも言い換えられる．目標設定の文脈でよく出てくる「SMART Goals (Specific / Measurable / Achievable / Relevant / Time bound)」に似ている．
そんな「習慣化」をテーマにした書籍「小さな習慣」を読んだ．もともとは洋書で「Mini Habits: Smaller Habits, Bigger Results」というタイトルで2013年に発売されている．内容は比較的シンプルながら，習慣化を実現するためのノウハウが詰まっている．また，個人的に刺さるキーフレーズも出ていたので，紹介したいと思う．習慣化をしようとしても三日坊主になってしまう人などにオススメできる．
まずタイトルにある「小さな習慣」って「どこまで小さいの？」という疑問が出ると思う．本書には，最初に以下のような具体例があり，驚くほどに小さかった．確かに続けられそう．
本書で繰り返し出てくるキーフレーズの中で，個人的に刺さったものを紹介する．本当に「小さい」からこそ，失敗しないというロジックはその通りで，確かに腕立て伏せ「1回」なら10秒あればできる．
Hini Habits 公式サイトに，具体的な「小さな習慣」のサンプルが公開されている．
例えば「Drink 1 glass of water（水をコップ1杯飲む）」や「Laugh once（1度笑う）」など，小ささの粒度として参考になる．「Write 50 words (for blog)（ブログ用に50文字書く）」などもあり，最初から「1記事」書こうとするから大きく感じるのであって，まずは「50文字」から書き始めるというのは，素晴らしい取り組みだと思う．
本書を読んでいて「1歩を踏み出すこと」の難しさが，習慣化できない理由に繋がっていると感じた．言い換えると「腰が重い」とも言える．本書にも「最初のアクションが1番難しい」という話があり「ニュートンの運動の法則」に例えられていた．ダラダラと1日を過ごしてしまうと，区切りがなくなってしまうので，うまく区切りを作って，1歩を踏み出せば，あとは「なるようになる」ことは改めて意識したいと思う．前にツイートした内容も本書の内容と似ている．
「よーし，やってみるかー！」派
— カック@累計10000はてブ超え🎉 (@kakakakakku) August 11, 2018
「課題はこうで，価値があるから，やる」派
習慣じゃないことを習慣化するときに，ロジカルすぎるとスタートまで時間が長くなってしまうので，まずは何も考えず背中を押されてみるっていうのも重要ですね
本書では，目標を管理するツールとして，大きなカレンダーを部屋に貼る方法だけではなく，スマホアプリ，デスクトップアプリなども紹介されていた．詳しくは Hini Habits 公式サイトに載っている．
現在，僕は「ループ習慣トラッカー (Loop - Habit Tracker)」と「習慣の目標 (Habit Tracker)」の2アプリをインストールして，試用している．1ヶ月ほど使ってみて，好きなアプリに決めたいと思う．
「アウトプット駆動学習を習慣化する」という登壇資料にも書いている通り，僕はタイムボックスを1週間に設定した「個人スプリント」を数年間ずっと回している．タスク管理に使っているツールは Trello で，毎週タスクを Done にするために頑張っている．ただし，これはあくまでタイムボックスが1週間なので，1週間で終わらせる（帳尻を合わせる）ようなルールになっている．そこで，今回から「毎日の小さな習慣」も組み合わせることにした．組み合わせる負荷は気にする必要はなく，理由は「小さすぎて失敗すらできない」からと言える．中長期的に運用してみて，どこかで結果をまとめたいと思う．
CircleCI には便利な Auto-cancel redundant buildsがあり，有効にしておくと，同じブランチに対して複数回ビルドがトリガーされた場合に，自動的に過去のビルドがキャンセルされる．繰り返し git pushをして，さらに CI 時間が長いような場合には，無駄な待ち時間を減らせたり，ジョブの詰まりを減らせたりする．この機能は CircleCI 1.0 時代からあったけど，もしかしたらあまり知られていないかも？
ついにWorkflowsでAuto Cancelling Redundant Buildサポートされました(まだPreviewですが)🥳同じブランチで複数のジョブが走った場合、古いジョブを自動でキャンセルしてくれる機能です。これを使うとコミットが多いプロジェクトでもビルド使用量を節約することができます。https://t.co/Kig2713huJ
— CircleCI Japan (@CircleCIJapan) August 20, 2018
最近のリリースで Auto-cancel redundant buildsを Workflows でも使えるようになった（とのこと）．一部注意点はあるものの，公式ドキュメントにも手順が載っていた．
まず Auto-cancel redundant buildsを無効にした状態で，単純に sleepするだけの CI ジョブを作成し，複数回ビルドをトリガーしてみた．すると，以下のように RUNNINGが多く並んだ．こうなってしまうと，ジョブが詰まってしまうので，開発効率も下がってしまう．
次にプロジェクト設定を変更する．Auto-cancel redundant buildsと Enable build processing (preview)を有効にした．
Off→ OnOff→ On
この状態で，複数回ビルドをトリガーしてみた．すると，詰まっているビルドが自動的に CANCELEDになった．便利！
公式ドキュメントに書いてある通り，デフォルトブランチは対象外になる．これは適切な挙動だと思っていて，特に master などは，リリースプロセスに使うため，必ずビルドをしてあげる必要がある．
Projects for which auto-cancel is enabled in the Advanced Settings will have workflows on non-default branches cancelled when a newer build is triggered on that same branch.
公式ドキュメントに書いてある通り，Auto-cancel redundant buildsを有効にする前にビルドのユースケースを考える必要がある．例えば lint 系だけではなく，デプロイもビルドで行っている場合など，自動キャンセルによって不整合などが起きないようになっている必要がありそう．
Notes: It is important to carefully consider the impact of enabling the auto-cancel feature, for example, if you have configured automated deployment jobs on non-default branches. Auto-cancelling workflows requires enabling the preview build processing feature.
textlint はドキュメント用の Lint ツールで，日本語にも対応しているので，簡単に文法や typo などを検出できる．
ドットインストールのレッスン一覧を眺めていたら textlint のレッスンがあり，気になったので，受講してみた．
Node.js をインストールした（というか既に入っていた）．今回試した Mac の環境は以下の通り．
$ node -v v10.8.0 $ npm -v 6.2.0
npm で新規プロジェクトを作成し，textlint を実行できるようにした．今回は v11.0.0になった．
$ npm init -y $ npm install --save-dev textlint $ ./node_modules/.bin/textlint -v v11.0.0
、の個数をチェックできる textlint-rule-max-tenをインストールした．
$ npm install --save-dev textlint-rule-max-ten
次に設定ファイルとなる .textlintrcを作成し，textlint-rule-max-tenを有効にしている．
{"rules": {"max-ten": true}}
実際に textlint を実行し，エラーが出ることを確認した．
$ ./node_modules/.bin/textlint docs/sample.md /Users/kakakakakku/github/sandbox-dotinstall-textlint/docs/sample.md 1:11 error 一つの文で"、"を3つ以上使用しています max-ten ✖ 1 problem (1 error, 0 warnings)
次に .textlintrcを変更し，デフォルトの閾値「3個」を「2個」に変更した．
{"rules": {"max-ten": {"max": 2}}}
実際にエラーの閾値を変更できた．
$ ./node_modules/.bin/textlint docs/sample.md /Users/kakakakakku/github/sandbox-dotinstall-textlint/docs/sample.md 1:8 error 一つの文で"、"を2つ以上使用しています max-ten ✖ 1 problem (1 error, 0 warnings)
実際に日本語の文章をチェックするときは複数のルールを組み合わせたプリセットを使うと良い．今回は textlint-rule-preset-japaneseをインストールし，「助詞の個数」や「ら抜き言葉」などをチェックできるようにした．
$ npm i -D textlint-rule-preset-japanese $ ./node_modules/.bin/textlint docs/sample.md /Users/kakakakakku/github/sandbox-dotinstall-textlint/docs/sample.md 1:11 error 一文に二回以上利用されている助詞 "で"がみつかりました。 preset-japanese/no-doubled-joshi 1:20 error ら抜き言葉を使用しています。 preset-japanese/no-dropping-the-ra ✖ 2 problems (2 errors, 0 warnings)
また，以下のようにプリセットの中で一部のルールを無効化することもできる．
{"rules": {"preset-japanese": {"no-dropping-the-ra": false}}}
次に文章中の表記揺れをチェックする textlint-rule-prhをインストールした．
$ npm i -D textlint-rule-prh
.textlintrcは以下のように書く．
{"rules": {"preset-japanese": {"no-dropping-the-ra": false}, "prh": {"rulePaths": ["rules/dotinstall.yml" ]}}}
rules/dotinstall.ymlを以下のように書くと javascriptという小文字の表記揺れをチェックすることができる．
version:1rules:- pattern: javascript expected: JavaScript
実際に表記揺れのエラーが出た．
$ ./node_modules/.bin/textlint docs/sample.md /Users/kakakakakku/github/sandbox-dotinstall-textlint/docs/sample.md 1:1✓ error javascript => JavaScript prh ✖ 1 problem (1 error, 0 warnings)✓ 1 fixable problem. Try to run: $ textlint --fix[file]
さらに rules/dotinstall.ymlを拡張し，複数の表記揺れを定義した．
version:1rules:- pattern:- javascript - java script expected: JavaScript
正規表現で書くこともできるので，表記揺れのパターンが多いときは助かる．
version:1rules:- pattern: /java\s*script/i expected: JavaScript
また --fixオプションを使うと自動的に文章を修正することもできる．
次は複数ファイルに対して textlint を実行するコマンドを試した．
$ ./node_modules/.bin/textlint docs/*.md /Users/kakakakakku/github/sandbox-dotinstall-textlint/docs/sample.md 1:13✓ error Javascript => JavaScript prh 1:27✓ error JAVAScript => JavaScript prh ✖ 2 problems (2 errors, 0 warnings)✓ 2 fixable problems. Try to run: $ textlint --fix[file]
Atom + textlint を試すレッスンだったけど，僕は Atom を使っていないので，スキップした．実はブログ記事を書くときに VS Code で textlint を使っているので，vscode-textlintで textlint を動かしたキャプチャを貼っておこうと思う．
textlint-rule-preset-japaneseや textlint-rule-prhなど，よく使うルールが紹介されていて良かった試した内容は Lesson ごとに commit している．
Mac / Windows / Linux など，クロスプラットフォームで，コピペができるツールを探していて，Go で書かれた clipboard を試した．clipboard をインストールすると gocopyコマンドと gopasteコマンドが使えるようになる．
サンプルファイルを用意して，簡単に動いた．
$ cat sample.txt | gocopy $ gopaste 112123123412345
ただし，Linux の場合は以下のエラーが出るため，事前にパッケージをインストールしておく必要がある．README にも Requirements として書いてあった．
panic: No clipboard utilities available. Please install xsel or xclip.
ディストリビューションによって違うと思うけど，今回は Amazon Linux で試した．
$ sudo yum install xsel --enablerepo epel $ sudo yum install xclip --enablerepo epel
あまり Windows に慣れていないけど，手元にある Windows 10 環境でも動かすことができた．
$ type .\sample.txt | .\gocopy.exe $ .\gopaste.exe 1 12 123 1234 12345
README にも書いてある通り，コピペ対象はテキストのみだった．png / gif など，画像もコピペできると良いんだけど，画像にも対応したライブラリはあるのだろうか？
pbcopyと pbpasteを実行していたVue School の無料コース「Vuex for Everyone」を受講した．Vue.js 初心者でも受講できるレベルになっているし，今まで Vue.js を書いたことはあるけど，Vuex はまだ使ったことがないという人にもオススメできる．進め方にもよるけど，写経するとしても2,3時間あれば終わる．
今回受講した「Vuex for Everyone」の題材は「shopping-cart」で，ステップバイステップに実装を進めていく．動作確認をしながら，機能を追加したり，リファクタリングをしたりする．
動画を見るとわかるけど，とにかく実装スピードが早いので，写経する場合は何度も戻して見直す必要がある．ただ困ったときは Vue School の GitHub にセッションごとにコミットされているので，それを活用すればオッケー．
（受講画面例）
Vue School のボイラープレートから「shopping-cart」プロジェクトを作成する．
$ npm install -g vue-cli $ npm install -g yarn $ vue init vueschool/webpack-template shopping-cart ? Project name shopping-cart ? Project description A Vue.js project ? Author kakakakakku <y.yoshida22@gmail.com> ? Vue build runtime ? Install vue-router? No ? Use ESLint to lint your code? No ? Setup unit tests with Karma + Mocha? No ? Setup e2e tests with Nightwatch? No vue-cli · Generated "shopping-cart". To get started: cd shopping-cart npm install npm run dev Documentation can be found at https://vuejs-templates.github.io/webpack $ cd shopping-cart $ yarn $ yarn dev
次に Vuex の GitHub にあるサンプルを参考に，ProductList コンポーネントを実装する．API 部分はモックになっている．
const _products = [{"id": 1, "title": "iPad 4 Mini", "price": 500.01, "inventory": 2}, {"id": 2, "title": "H&M T-Shirt White", "price": 10.99, "inventory": 10}, {"id": 3, "title": "Charli XCX - Sucker CD", "price": 19.99, "inventory": 5}]
この時点で，3商品を表示することができる．
（実装画面）
ここで Vuex をインストールする．
$ yarn add vuex
そして，新しく store/index.jsを作成する．ここで，さっそく Vuex で重要なコンセプトが出てくる．
ここでは，実際に mutations を実装する．ハンドラ関数の第一引数として stateを指定し，追加でペイロードとして productsを指定している．
// shopping-cart/src/store/index.js mutations: { setProducts (state, products) {// update products state.products = products }}
getters の実装はシンプルで，ストアからフィルタして取得できる．実際にモックの1商品の在庫を0にして，動作確認をした．
// shopping-cart/src/store/index.js getters: {// = computed properties availableProducts (state, getters) {return state.products.filter(product => product.inventory > 0) }}
（実装画面）
この時点だと，まだコンポーネントから直接 Ajax で API を呼び出しているので，ベストプラクティスではなく，actions を使って解決するとのことだった．最初は，そのまま mutations をコミットすれば良いのではないかと思っていたけど，mutations は同期，actions は非同期なので，ここでは actions を使って，mutations をコミットする必要性を学べた．そして，API を呼び出しているときのローディング画像もここで実装した．
// shopping-cart/src/store/index.js actions: {// = methods fetchProducts ({commit}) {returnnew Promise((resolve, reject) => {// make the call// call setProducts mutation shop.getProducts(products => { commit('setProducts', products) resolve() }) }) }},
actions を呼び出すときは .dispatchを使う．そして actions の中で Promise を実装しているので，ここでは .thenで受けて，ローディング画像を消している．
// shopping-cart/src/components/ProductList.vue created () {this.loading = true store.dispatch('fetchProducts') .then(() => this.loading = false) }
（実装画面）
全てのコンポーネントで store を import しなくても良いように，ルートコンポーネントに注入し，各コンポーネントでは this.$storeで参照できるようにした．
// shopping-cart/src/main.jsnew Vue({ el: '#app', store, render: h => h(App) })
次に商品をカートに入れられるようにストアにカートを実装した．ここまでの理解もあったので actions と mutations の実装も問題なかった．
（実装画面）
Chrome 拡張を使って Vuex の状態を確認した．状態を Time Travel して戻すことができるのは，デバッグするときに便利そうだった．
（実装画面）
Vuex の GitHub から Filters 用の currency.jsをコピーして，カートの実装を追加した．これで，カートの中に何が何個入っていて，総額も確認できるようになった．
（実装画面）
次は，購入できるようにチェックアウトボタンを実装した．実際にチェックアウトはできないので，ボイラープレートに入っている実装で，ランダムで成功したり，失敗したりするようになっている．
buyProducts (products, cb, errorCb) { setTimeout(() => {// simulate random checkout failure. (Math.random() > 0.5 || navigator.userAgent.indexOf('PhantomJS') > -1) ? cb() : errorCb() }, 100) }
actions から，成功時の mutations と 失敗時の mutations を送っている．
// shopping-cart/src/store/index.js checkout ({state, commit}) { shop.buyProducts( state.cart, () => { commit('emptyCart') commit('setCheckoutStatus', 'success') }, () => { commit('setCheckoutStatus', 'fail') } ) }
在庫がないときに商品名が消えてしまうのは微妙なので，Add to cart ボタンを disable にする実装をした．
（実装画面）
ここからは，Vuex のお作法でリファクタリングをしていく．まずは Map Helpers で state / getters / actionsの宣言をシンプルにするために mapState / mapGetters / mapActionsを宣言し，スプレッド演算子とともに，その中に呼び出し名を宣言できる．
// shopping-cart/src/components/ProductList.vue computed: { ...mapState({ products: state => state.products }), ...mapGetters({ productIsInStock: 'productIsInStock'}) }
次は store/index.jsの肥大化を防ぐために，actions だけを store/actions.jsに切り出した．ただし，ここでは切り出せることを学ぶだけで，実際には次に出てくる Vuex Modules で書き直すことになる．
モジュールも Vuex のコンポーネントで，ストアごとに切り出していくようなイメージになる．今回は store/modules/cart.jsと store/modules/products.jsに切り出した．モジュールごとに state / getters / mutations / actionsを持っているので，わかりやすいし，テストコードも書きやすそう．結果的に store/index.jsに実装はなくなり，とにかく薄くなった．
// store/index.jsimport Vuex from 'vuex'import Vue from 'vue'import actions from './actions'import cart from './modules/cart'import products from './modules/products' Vue.use(Vuex) exportdefaultnew Vuex.Store({ modules: { cart, products }, state: {// = data}, getters: {// = computed properties}, actions, mutations: {}})
最後は namespaced で，モジュールで namespaced: trueを指定することにより，コンポーネント側で mapActionsに名前空間を指定できるようになる．メソッド名にストア名を含めて冗長になっている場合など，シンプルに書けるようになる．
過去に受講した Firebase Realtime Database の無料コースも，Firebase Authentication の無料コースも良かった．
「教育研修ファシリテーター」を読んだ．どのように学びのある教育研修を創り出すのか？という講師のためのノウハウ本ではあるけど，サブタイトルに「組織・人材開発を促進する」と書いてある通り，チームビルディングをしたり，メンバーに何かを伝える場面が多い人にも役立つ本だった．例えば，エンジニアリングマネージャー，スクラムマスターなどのポジションを担当する人にもオススメできる．僕自身は技術講師（本書の表現だとファシリテーター）をしているので，実務経験だけでは学べないような，教育研修のノウハウとマインドセットを学ぶために読んだ．
本書では，従来の研修と比較をするために，同じような意味で使われる言葉を明確に表現している．今回の記事も，本書の言葉通りに書いているので，前提として整理しておく．特に「受講者」という表現はよく使っているので，今後は意識的に「参加者」と表現しようと思う（とは言え，組織的に表現が決まっている場合もあると思う）．
従来の研修と比較して，ファシリテーターは「3つのスタイル」と「9つの学習法」を組み合わせるべきと書いてあった．参加して印象に残る研修は，講義だけじゃなく，ディスカッションがあったり，フィードバックがあったりするので，こういう分類があったんだなと理解できた．
研修の構成要素として，3つの要素が紹介されていた．
特に参加者と場をコントロールするための「チーム」は参考になった．まずは参加者の属性（部署，役職など）と研修に参加した経緯などをヒアリングすることにより，期待値を調整することができる．また，参加者の年代によって価値観，スピード感が異なるので，話すスピードを調整したり，比喩を使うにしても時代を意識したり，カジュアルな言葉を使うかどうかを意識したりする必要がある．本書を読んでいて「ファシリテーターのプレゼンテーションにも TPO があるんだな」と気付けたところに学びがあった．
他には，場をコントロールするために，部屋のレイアウトにもこだわると書いてあった．特にレイアウト変更のときには参加者にも手伝ってもらうことで，その単純作業がキッカケになり，チームビルディングに繋がるというのは知れて良かった．あと，研修センターに行くとよく飴などお菓子が置いてあるのも，場をコントロールするためだったんだとわかった．
本書を読んでいると，繰り返し「予定調和にならないように」という表現が出てくる．インストラクターは「予定調和（落語）」で，ファシリテーターは「ライブ（大喜利）」という比喩も出てくる．予定調和という意味は，ただテキストの通りに進めるということだけではなく，例えば，ブレストなどのワークショップをしたときに，チームごとの独自性のあるアイデアを活かさず，事前に用意したテンプレートでフィードバックをすることも予定調和と書かれていた．e-Learning では体験できない学びを創り出すためにも，ライブ感を届けられるようなファシリテーターになりたい．僕の大好きな本「Fearless Change」から引用すると「テーラーメイド」とも言えるかな．
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
本書では，ところどころにワークショップ手法の紹介が入っている．体験したことがあるものも多かったけど，実施する背景だったり，コツなども整理されているので，実施する側として，改めて考え直すことができた．
今回はすぐに使えそうなワークショップを2個紹介したいと思う．
隣同士など，少人数で軽く話をするワークショップで，全員の前だと話にくいけど，少人数なら話せるという心理的安全性を重視したものになっている．自己紹介でも良いし，ミニディスカッションでも良いし，様々な場面で使える．複数日の研修なら，バズの組み合わせを変えたり，人数を徐々に増やしたりするのも良いと思う．
「今の気持ちはどう？」という質問に気軽に答えるというワークショップで，自己紹介とセットで実施しても良さそうだった．研修に対する意気込みを伝えても良いし，もっと身近な例で「朝，満員電車が大変でー」というような体験を話しても良いと思う．参加者の笑いを誘う自己紹介をする人は，チェックインが上手なんだと思う．また，チェックアウトも忘れずに実施することが重要と書いてあった．ポイントは「気軽に今の気持ちを伝える」という点かなと思う．
本書の後半に「フィードバックの4原則」が出てくる．自分のことは自分で気付きにくいので，フィードバックをもらうことは大切だけど，最低限のグラウンドルールを守らないと雰囲気が悪くなってしまう．
「建設的な目的」と書いてあるけど，個人的にフィードバックで大切だと思っているのは，良い点だけではなく悪い点も伝えてあげることなので，だからこそ攻撃的にならないように注意したいところ．そして，ファシリテーターとしては「今はフィードバックの時間ですよ」という雰囲気を作り，参加者同士で深め合ってもらえるようにしたいと思う．やはり「深め合ってもらう」ために場を促進するのがファシリテーターの役割なので，ファシリテーターがドヤ顔でフィードバックしてしまうことも気を付ける必要がある．本書にも「一言多いファシリテーターは要注意」と書いてあり，読んでいて「ウッ」となった．
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない．
論文も公開されている．
SIGKILLシグナルを送り強制停止するのではなく，SIGTERMでコンテナの終了処理を実行できるようにする個人的に経験があるのはログ収集用に使う Fluentd コンテナで，まさに同じユースケースと言える．サイドカーが異常になった場合も，メインコンテナに影響しないというのがポイントだと思う．
ロードバランサーにも似ていて，外部とコミュニケーションをするという関心事をアンバサダーにオフロードしているのがポイントだと思う．他にも Microservices を構築するときに考える Service Mesh (Envoy / Linkerd) での Circuit Breaker もアンバサダーに分類されるかな？
海外旅行で使う電源変換アダプタのイメージと言える．具体的には Prometheus のようなプル型のモニタリングシステムと相性が良さそう．
（構成図を作った）
今まで経験があるのは Consul のリーダー選出（内部的には Paxos？Raft？）ぐらいで，その他は経験がないけど，リーダー選出という複雑な部分をコンテナに押し込めるのはメリットがあると思う．ただし，論文にもあまり詳細は書かれていなかった．
読んでいるときに「一般的なキューとワーカーの組み合わせと何が違うんだろう？」と疑問だったけど，キューからメッセージを受ける部分もコーディネーターにオフロードすることで，キューの種類が変わっても（例えば Kafka, SQS, ActiveMQ, RabbitMQ など）ワーカーは影響を受けない構造になっていて，納得できた．個人的に1番学びのあるデザインパターンだった．
（構成図を作った）
Scatter（散布）と Gather（収集）という意味で，具体的な例で言えば MapReduce と同じ構成と言える．
（構成図を作った）
Coursera で「Cloud Computing Concepts, Part 1」という講義を受講することができる．これは「分散システム」を学ぶ講義になっているので，興味がある人がいたら是非オススメしたい．僕が受講したときのメモは全て以下の記事にまとめてある．
Redash v4 のリリースから約5ヶ月，正式に Redash v5がリリースされた 🎉🎉🎉
約1ヶ月間のベータ期間を経て，現在は Redash v5.0.1 が最新バージョンになっている．デザインの大幅な変更があった v4 から，順当に便利になっていると感じている．特に以下は個人的な目玉機能と言える．
Alt + D : テーブル一覧とクエリエディタを非表示にするAlt + Shift + D : テーブル一覧を非表示にする詳細な Changelog は GitHub のリリース情報にまとまっている．
そして今日「Redash ハンズオン資料 v5 対応」をリリースした 🎉🎉🎉
主な変更点を以下にまとめる．
kakakakakku/mysql-world-database:5.7に変更したDocker Image に関して，今まで使っていた kakakakakku/mysql-57-world-databaseは，バージョンごとにイメージ化していて，さらに Docker Hub のアップロードを手動でやっていたので，運用面で課題があった．今回から使うことにした kakakakakku/mysql-world-database:5.7は，バージョンごとにイメージタグを切って，さらに Docker Hub の AUTOMATED BUILD を使っている．既に MySQL 8.0 も用意しているので，試すこともできる．
ちなみに，長らく最新バージョンとなっていた Redash v4.0.1 に Google OAuth 関連のセキュリティ問題が発覚し，急遽 Redash v4.0.2 がリリースされた経緯がある．詳しくは Arik のブログに書いてある．
それに伴って，Redash ハンズオンも v4.0.2 に対応してある．v4 でハンズオンを試す場合は，是非 v4.0.2 を使って頂ければと！
「Redash ハンズオン資料」を使って Redash v5 を学ぼう！
Dependabotは依存パッケージの更新を定期的にチェックし，更新があった場合にプルリクエストを作成してくれるサービスで，現時点で「Ruby, JavaScript, Python, PHP」など，多くのプログラミング言語がサポートされている．他にも「Go, .NET」などは BETA & ALPHA 版でサポートされている．依存パッケージの更新が重要なのはわかっていても，月に1回など，定期的なイベントとして実施しているチームも多いと思うので，Dependabot を使うメリットがある．
Dependabot 以外だと Greenkeeperや Tachikoma.ioを使っているチームもあるし，CircleCI などと組み合わせて独自実装で実現しているチームもある．あえて自動化はせず「チームメンバーの教育目的で手動で依存パッケージを更新する」というチームの話も聞いたことがある．
Dependabot がサポートしているプログラミング言語の中に「Docker」があり，具体的に何をしてくれるんだろう？と興味があったので，実際に試してみた．結論から言うと「Dockerfile のベースイメージに更新があったら Dockerfile を更新するプルリクエストを作成してくれる機能」だった．これは便利では！？
Dependabot は GitHub Marketplace からインストールし，次にリポジトリを登録しておく．パブリックリポジトリなら無料で使えるので，すぐに試すことができる．あとはチェック設定をするだけで，今回は以下のように Dockerfile を管理しているリポジトリを登録してみた．Docker の場合，以下のオプションを追加で指定することができる．
なお，スケジュールは以下の3種類から選ぶことができる．
以下のように alpine:3.7を alpine:3.8に更新するプルリクエストが作成された．常に最新バージョンを確認しているわけではないので，Dependabot が定期的にチェックしてくれるのは便利だった．常に最新という意味で alpine:latestを指定しているのであれば，プルリクエストは出ないと思う．
Dependabot は ChatOps に対応しているので，プルリクエストのコメントで以下のようなメンションをすると，トリガーすることができる．今回は自分でプルリクエストをマージするのではなく @dependabot mergeを使ってマージした．
@dependabot rebase@dependabot merge@dependabot cancel merge@dependabot reopen@dependabot ignore this [patch|minor|major] version@dependabot ignore this dependency@dependabot use these labels@dependabot use these reviewers@dependabot use these assignees@dependabot use this milestone@dependabot badge meサイトには Flexible monorepo supportと書いてあるけど，実際にディレクトリ /で登録しようとすると Repo must contain a Dockerfile.とエラーが出て使えなかった（なぜ？）．今回はディレクトリごとに登録をした．
Using a monorepo? No problem - you can specify one or many directories within a repo for Dependabot to look for Dockerfiles in.
「経験学習」とは，経験から学び成長することで，例えば，難易度の高かった仕事／個人プロジェクトなど，日々何かしらの「経験学習」をしていると思う．自分自身が今後どのように「経験学習」をしていけば良いのか，そして技術講師として学びを伝えるためにどんなことを意識すれば良いのか，そのあたりを知るために，今回『「経験学習」入門』を読んだ．本書の導入部分にも書いてあるけど，もっと成長したい人，育成に悩んでいる人，チームマネジメントをしている人などが読者層かなと．
組織行動学者のコルブによって提唱された「経験学習モデル」とは，以下の学習サイクルを繰り返しながら成長するという理論で，個人的には「省察（言い換えると，リフレクション，振り返り）」が特に重要だと思う．
ちなみに，最近読んだ「教育研修ファシリテーター」にも「経験学習モデル」の話が載っていて，また出たー！感がある．
本書では「経験から学ぶ力のモデル」として，以下の3要素が挙がっていた．
常に挑戦するというのは重要なことだけど，ストイックすぎても続かないため，好奇心を持ち，楽しむことも大切だという意味で「エンジョイメント」が3要素の中に挙がっているのは良かった．そのためには，淡々と仕事を進めるのではなく「なぜこの仕事が必要なのか？」という本質を考えることが必要だと書かれていた．また「内発的動機」に関しても言及があった．「内発的動機」に関しては「モチベーション3.0」に詳しく書いてある．仕事／メンタリング／セルフコーチングなど，どんなシチュエーションでも「ストレッチ + リフレクション + エンジョイメント」を意識すると良さそう．
成長を決める要素の比率として「70:20:10 の法則」が紹介されていた．
比率に異論はないけど，個人的には「フィードバックをもらうこと」をとても大切にしていて，むしろ「フィードバックをもらえなくなったら成長は止まる」とも思っているので，工夫次第では「20%」以上の価値がある要素になると思う．本書には「ポジティブ・フィードバック」も「ネガティブ・フィードバック」もどちらも言及があった．「ポジティブ・フィードバック」は，ただ褒めるだけではなく，良いことを良いと適切に伝えることができる点がポイントで，「ネガティブ・フィードバック」は異なる価値観を気付かせることがポイントだと思う．本書にも「批判にオープンになる」という話があって良かった．
成長を分類すると「能力的成長」と「精神的成長」に分類できると書いてあった．特に「精神的成長」とは，仕事に対する信念／価値観が変わり，自己中心的なものから，他社／社会と繋がり影響を与えていくようになるということで，組織を客観的に見て，組織の課題解決に向き合ったりするのは「精神的成長」に分類されるのかもしれないと感じた．
『「経験学習」入門』を読んだ．内容的にはそこまで新しいものはなく，これまで読んできた「自己啓発」関連の本と「メンタリング」関連の本とカブっている部分も多かったけど，改めて「経験学習」のサイクルを学び直せたのは良かった．どこまでもストイックに挑戦していく性格なので，よりエンジョイメントの比率を高くし，もっと間接経験（フィードバック）をもらいながら成長できるように頑張りたいなと！
最近 stressコマンドを使って，サーバに負荷をかける方法を紹介する機会があり，よく使っているのに今までブログに書いていなかったなと気付き，今回まとめることにした．CPU に負荷をかけるだけなら yes > /dev/nullをコア数に合わせて並列実行すれば良いけど，stressコマンドならメモリとディスクにも負荷をかけることができるので，シナリオのバリエーションを増やすことができる．
検証環境として CentOS を使った．
$ sudo yum install stress
$ stress --version
stress 1.0.4
以下のような共通オプションが用意されている．よく使うのは --timeoutで，秒数を指定して負荷をかけることができる．他はあまり使ったことがないかも．
-t, --timeout : 負荷をかける秒数を指定する-n, --dry-run : 実際に負荷をかけず，期待値を確認する-q, --quiet : 標準出力を抑制する-v, --verbose : 標準出力にデバッグ情報まで表示するCPU に負荷をかける場合は --cpuオプションを使う．引数にコア数を指定するので，/proc/cpuinfoあたりを見て負荷を調整する．以下は，10秒間 CPU に負荷をかけて dstatで確認している．
$ stress --cpu2--timeout10 $ dstat -c ----total-cpu-usage---- usr sys idl wai hiq siq 001000000010000073027000100000001000000010000000100000001000000010000000100000001000000010000000260740000010000000100000
メモリに負荷をかける場合は --vmオプションを使う．1 VM あたりのメモリサイズはデフォルトで 256MB になっているので，変更する場合は --vm-bytes 512Mのように --vm-bytesオプションと併用する．また，デフォルトの挙動では「メモリ確保 → メモリ解放を繰り返す」ようになっている．
$ stress --vm1 $ stress --vm2 $ stress --vm2--vm-bytes 512M
以下は，10秒間メモリに負荷をかけて dstatで確認している．usedの値が「増えて → 減って」を繰り返していることがわかる．
$ stress --vm2--timeout10 $ dstat -m ------memory-usage----- used buff cach free 97.9M 19.2M 442M 3148M 97.9M 19.2M 442M 3148M 328M 19.2M 442M 2918M 158M 19.2M 442M 3088M 396M 19.2M 442M 2850M 137M 19.2M 442M 3109M 445M 19.2M 442M 2801M 194M 19.2M 442M 3051M 500M 19.2M 442M 2745M 245M 19.2M 442M 3000M 545M 19.2M 442M 2700M 312M 19.2M 442M 2934M 98.4M 19.2M 442M 3147M 98.4M 19.2M 442M 3147M
逆に「メモリ確保を維持する」場合には --vm-hangオプションと併用する．--vm-hangオプションには維持する秒数を指定することができ，0 を指定すると無期限に維持する．以下は，10秒間メモリに負荷をかけて，確保サイズを 512MB で維持している．
$ stress --vm2--vm-hang0--timeout10 $ dstat -m ------memory-usage----- used buff cach free 105M 21.2M 444M 3137M 105M 21.2M 444M 3137M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 617M 21.2M 444M 2625M 105M 21.2M 444M 3136M 105M 21.2M 444M 3136M
stressコマンドではディスク（書き込み）に負荷をかけることができる．その場合は --hddオプションを使う．デフォルトの挙動では「書き込み → 削除を繰り返す」ようになっている．書き込みサイズはデフォルトで 1GB になっているので，変更する場合は --hdd-bytes 2Gのように --hdd-bytesオプションと併用する．あとは dstat -rで IOPS あたりを確認する．
$ stress --hdd1--timeout10 $ stress --hdd2--timeout10 $ stress --hdd2--hdd-bytes 2G
stressコマンドが便利最近 Markdown で書かれたシンプルなドキュメント（見出し / リスト / コードブロックなど）を HTML に変換する必要があり，Markdown を HTML に変換するライブラリ「Showdown」を試した．今までは「Pandoc」を使う機会が多かったので，他のライブラリを試したかったという背景もあった．
サクッと Showdown の挙動を確認する場合は Showdown Live Editor を見てみると良いかと．
CLI で Markdown を HTML に変換する場合，Showdown CLI を使う．オプションは以下から選べる．
-i/--input-o/--output-u/--encoding-a/--append-e/--extensions詳細は Wiki に載っている．
インストールは npm を使う．
$ npm install showdown -g $ showdown -v 1.8.7
次に Markdown を用意する．「`3個」を入れ子にすると表示が崩れるため，Markdown 内部の「`3個」の先頭に本来不要な半角スペースを入れている．
# Sample This is **Showdown** sample ! ## List & Link - A1 - A1-1 - A1-2 - A1-3 - B1 - B1-1 - B1-2 - B1-2-1 - B1-2-2 - B1-2-3 - [kakakakakku blog](https://kakakakakku.hatenablog.com/) ## Code Block ``` package main import ( "fmt" ) func main() { fmt.Println("Hello, playground") } ```## Image 
そして showdown makehtmlを実行する．
$ showdown makehtml -i kakakakakku.md -o kakakakakku.html Enabling option ghCodeBlocks Enabling option encodeEmails ... Reading data from file... Parsing markdown... Writing data to file... DONE!
HTML に変換できた．
Showdown では，基本的にシンプルな HTML に変換されるので，CSS などは適用されない．ただし GitHub を見ていたら，Markdown に style タグを書けば，多少はワークアラウンドができることがわかった．あくまで Markdown に style タグを書くだけなので，複雑なスタイルを書くと可読性が下がりそう．例えば，以下のように書ける．
<style>h1{color: red; }</style># Sample This is **Showdown** sample !
GitHub の README.mdを読んでいると，Showdown の強みはクライアントサイドでもサーバサイドでも Markdown を HTML に変換できるところにありそうだった．実際に Node.js でサンプルコードを動かしてみた．ウェブサービスの実装で Showdown を使うこともできそう．
var showdown = require('showdown'), converter = new showdown.Converter(), text = '# hello, markdown!', html = converter.makeHtml(text); console.log(html);
実行すると HTML に変換できた．
$ node sample.js <h1 id="hellomarkdown">hello, markdown!</h1>
Wiki を読んでいると，Showdown Extensionという拡張機能があり，公式には Twitter Extension と YouTube Extension が公開されていた．簡単に言うと「特定の文言を変換する機能」で，例えば Twitter Extension だと @usernameと書くだけで <a href="http://twitter.com/username">@username</a>に変換できるようになる．また Showdown Extension Boilerplate も公開されているので，独自の変換ルールを実装して拡張することもできそう．
普段 iTerm2 でターミナル作業をするとき，Colors は Solarized Darkを使っている．ただし，モブプログラミングをしたり，研修中にデモを見せたりするときに，スクリーンに Solarized Dark で投影すると視認性が悪いため，毎回 Edit Session or Open Profiles で Solarized Lightなど別の Colors に切り替えていた．
調べたところ，iTerm2 ではコマンドからプロファイルを切り替えることができる．例えばプロファイル名が Demoだとすると，以下のコマンドでプロファイルを切り替えることができる．
$ echo -ne "\033]1337;SetProfile=Demo\a"
次は .zshrcなどの設定ファイルに alias を登録して，エイリアスから起動できるようにする．今回は demoと打てば，プロファイルを切り替えられるようにした．
alias demo='echo -ne "\033]1337;SetProfile=Demo\a"'
プロファイルが複数あると，エイリアスを覚えるのが大変になるし，他のエイリアスとカブる可能性もあるので，peco と組み合わせてインタラクティブにプロファイルを切り替えられるようにした．まず .iterm2-profilesファイルを作成し，その中にプロファイル名を書いておく（ちなみに，ファイル名は自由に決めて良し）．
Default Demo Mob
そして，peco と組み合わせたコマンドを alias にして，また .zshrcなどの設定ファイルに登録する．今回は pと打てば，プロファイル名を選択できるようにした．便利！
aliasp='echo -ne "\033]1337;SetProfile=$(peco ~/.iterm2-profiles)\a"'
Depfuは依存パッケージの更新を定期的にチェックし，更新があった場合にプルリクエストを作成してくれるサービスで，現時点で「Ruby, JavaScript」をサポートしている．導入企業に Cookpad も載っている．今回 Depfu を JavaScript で試した．
Depfu 以外にも依存パッケージの更新を定期的にチェックするサービスはある．
特に Dependabotはサポートしているプログラミング言語が多いという特徴がある．以下に Dependabot + Dockerfile を試した記事がある．
Depfu は GitHub Marketplace からインストールできる．パブリックリポジトリなら無料で使えるので，すぐに試すことができる．
今回は数年前に実装した個人用 Slack Bot (Hubot) のリポジトリに Depfu を適用した．全プルリクエスト（計8個）を merge して，Slack Bot をデプロイしたら問題なく使えた！Slack Bot は Heroku で動かしていて，久し振りに Heroku を使った．
Depfu では，リポジトリごとに詳細な設定ができる．
ライブラリごとに Requirement version と Latest version を確認できる管理画面がある．ライブラリによっては GitHub URL と Changelogs URL も載っていて，非常に使いやすく実装されている．
Depfu のプルリクエストは詳細に書かれていて，ライブラリのバージョン比較だけではなく，実際にどのような差分（コミット）があるのかを確認することもできる．
また Depfu は ChatOps に対応していて，以下のようなコメントでメンションをすると，トリガーすることができる．今回は @depfu rebaseと @depfu mergeを使った．
@depfu rebase@depfu merge@depfu reopen@depfu pause@depfu pause [minor|major]@depfu resume
Depfu では GitHub の README.md などに貼るバッジも用意されている．
sayをしたら「デェプフ」のように聞こえた！$ say -v Alex Depfu
今回題材にした Slack Bot を実装した2016年に書いた記事は以下にある．今どき CoffeeScript は書かないよなぁー．