kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

依存パッケージを更新するサービス「Depfu」で package.json の更新をチェックする

Depfu は依存パッケージの更新を定期的にチェックし,更新があった場合にプルリクエストを作成してくれるサービスで,現時点で「Ruby, JavaScript」をサポートしている.導入企業に Cookpad も載っている.今回 Depfu を JavaScript で試した.

depfu.com

Depfu 以外にも依存パッケージの更新を定期的にチェックするサービスはある.

特に Dependabot はサポートしているプログラミング言語が多いという特徴がある.以下に Dependabot + Dockerfile を試した記事がある.

kakakakakku.hatenablog.com

インストール

Depfu は GitHub Marketplace からインストールできる.パブリックリポジトリなら無料で使えるので,すぐに試すことができる.

github.com

今回は数年前に実装した個人用 Slack Bot (Hubot) のリポジトリに Depfu を適用した.全プルリクエスト(計8個)を merge して,Slack Bot をデプロイしたら問題なく使えた!Slack Bot は Heroku で動かしていて,久し振りに Heroku を使った.

github.com

リポジトリ設定

Depfu では,リポジトリごとに詳細な設定ができる.

  • Update Strategy(アップデート戦略)
    • Individual Updates
    • Security Updates Only
    • Paused
  • Limit of open pull requests from Depfu(プルリクエスト上限数)
  • Customize the pull requests Depfu creates
    • Commit message(コミットメッセージ)
    • Which labels should we use for the PRs?(プルリクエストラベル)
    • Should we assign anyone to the PRs?(プルリクエストアサイン)
  • Environment Variables(環境変数)

f:id:kakku22:20181109112645p:plain

Up-to-date Dependencies

ライブラリごとに Requirement version と Latest version を確認できる管理画面がある.ライブラリによっては GitHub URL と Changelogs URL も載っていて,非常に使いやすく実装されている.

f:id:kakku22:20181109112658p:plain

プルリクエスト

Depfu のプルリクエストは詳細に書かれていて,ライブラリのバージョン比較だけではなく,実際にどのような差分(コミット)があるのかを確認することもできる.

github.com

また Depfu は ChatOps に対応していて,以下のようなコメントでメンションをすると,トリガーすることができる.今回は @​depfu rebase と @​depfu merge を使った.

  • @​depfu rebase
  • @​depfu merge
  • @​depfu reopen
  • @​depfu pause
  • @​depfu pause [minor|major]
  • @​depfu resume

f:id:kakku22:20181109112730p:plain

Depfu バッジ

Depfu では GitHub の README.md などに貼るバッジも用意されている.

Depfu

Depfu

Depfu

まとめ

  • 依存パッケージの更新を定期的にチェックしてくれる Depfu は便利
  • 現時点では Ruby と JavaScript をサポートしている
  • Depfu はどう発音するんだろう?
    • 試しに say をしたら「デェプフ」のように聞こえた!
$ say -v Alex Depfu

関連記事

今回題材にした Slack Bot を実装した2016年に書いた記事は以下にある.今どき CoffeeScript は書かないよなぁー.

kakakakakku.hatenablog.com

iTerm2 のプロファイルを peco で切り替える

普段 iTerm2 でターミナル作業をするとき,Colors は Solarized Dark を使っている.ただし,モブプログラミングをしたり,研修中にデモを見せたりするときに,スクリーンに Solarized Dark で投影すると視認性が悪いため,毎回 Edit Session or Open Profiles で Solarized Light など別の Colors に切り替えていた.

コマンドからプロファイルを切り替える

調べたところ,iTerm2 ではコマンドからプロファイルを切り替えることができる.例えばプロファイル名が Demo だとすると,以下のコマンドでプロファイルを切り替えることができる.

$ echo -ne "\033]1337;SetProfile=Demo\a"

alias と組み合わせる

次は .zshrc などの設定ファイルに alias を登録して,エイリアスから起動できるようにする.今回は demo と打てば,プロファイルを切り替えられるようにした.

alias demo='echo -ne "\033]1337;SetProfile=Demo\a"'

peco と組み合わせる

github.com

プロファイルが複数あると,エイリアスを覚えるのが大変になるし,他のエイリアスとカブる可能性もあるので,peco と組み合わせてインタラクティブにプロファイルを切り替えられるようにした.まず .iterm2-profiles ファイルを作成し,その中にプロファイル名を書いておく(ちなみに,ファイル名は自由に決めて良し).

Default
Demo
Mob

そして,peco と組み合わせたコマンドを alias にして,また .zshrc などの設定ファイルに登録する.今回は p と打てば,プロファイル名を選択できるようにした.便利!

alias p='echo -ne "\033]1337;SetProfile=$(peco ~/.iterm2-profiles)\a"'

f:id:kakku22:20181103134430g:plain

まとめ

  • iTerm2 では,コマンドでプロファイルを切り替えることができる
  • peco と組み合わせると,複数のプロファイルを簡単に切り替えることができる

Markdown を HTML に変換するライブラリ「Showdown」を試した

最近 Markdown で書かれたシンプルなドキュメント(見出し / リスト / コードブロックなど)を HTML に変換する必要があり,Markdown を HTML に変換するライブラリ「Showdown」を試した.今までは「Pandoc」を使う機会が多かったので,他のライブラリを試したかったという背景もあった.

github.com

サクッと Showdown の挙動を確認する場合は Showdown Live Editor を見てみると良いかと.

Showdown CLI とは?

CLI で Markdown を HTML に変換する場合,Showdown CLI を使う.オプションは以下から選べる.

  • -i/--input
    • Markdown ファイル名を指定する
    • 標準入力もサポートしている
  • -o/--output
    • HTML ファイル名を指定する
    • 標準出力もサポートしている
  • -u/--encoding
    • エンコードを指定する
  • -a/--append
    • 追記するときに指定する(どういうときに使うんだろう?)
  • -e/--extensions
    • 拡張ライブラリを指定する

詳細は Wiki に載っている.

Showdown CLI 実行

インストールは 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

![Twitter](https://pbs.twimg.com/profile_images/604918632460656640/FdOmiWZW_400x400.png =200x200)

そして 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 に変換できた.

f:id:kakku22:20181029233236p:plain

CSS を適用する

Showdown では,基本的にシンプルな HTML に変換されるので,CSS などは適用されない.ただし GitHub を見ていたら,Markdown に style タグを書けば,多少はワークアラウンドができることがわかった.あくまで Markdown に style タグを書くだけなので,複雑なスタイルを書くと可読性が下がりそう.例えば,以下のように書ける.

<style>
h1 {
  color: red;
}
</style>

# Sample
This is **Showdown** sample !

サーバサイドで Markdown を HTML に変換する

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>

Showdown Extension

Wiki を読んでいると,Showdown Extension という拡張機能があり,公式には Twitter Extension と YouTube Extension が公開されていた.簡単に言うと「特定の文言を変換する機能」で,例えば Twitter Extension だと @username と書くだけで <a href="http://twitter.com/username">@username</a> に変換できるようになる.また Showdown Extension Boilerplate も公開されているので,独自の変換ルールを実装して拡張することもできそう.

github.com

github.com

github.com

まとめ

  • Markdown を HTML に変換するライブラリ「Showdown」を試した
  • Showdown CLI を使えば,ターミナルから変換ができる
  • Showdown Extension を使うと独自の変換ルールを実装できる
  • 次は Netlify 連携を試してみたいと思う

CPU / メモリ / ディスクに負荷をかける stress コマンド

最近 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 に負荷をかける場合は --cpu オプションを使う.引数にコア数を指定するので,/proc/cpuinfo あたりを見て負荷を調整する.以下は,10秒間 CPU に負荷をかけて dstat で確認している.

$ stress --cpu 2 --timeout 10

$ dstat -c
----total-cpu-usage----
usr sys idl wai hiq siq
  0   0 100   0   0   0
  0   0 100   0   0   0
 73   0  27   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
100   0   0   0   0   0
 26   0  74   0   0   0
  0   0 100   0   0   0
  0   0 100   0   0   0

メモリに負荷をかける

メモリに負荷をかける場合は --vm オプションを使う.1 VM あたりのメモリサイズはデフォルトで 256MB になっているので,変更する場合は --vm-bytes 512M のように --vm-bytes オプションと併用する.また,デフォルトの挙動では「メモリ確保 → メモリ解放を繰り返す」ようになっている.

$ stress --vm 1
$ stress --vm 2
$ stress --vm 2 --vm-bytes 512M

以下は,10秒間メモリに負荷をかけて dstat で確認している.used の値が「増えて → 減って」を繰り返していることがわかる.

$ stress --vm 2 --timeout 10

$ 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 --vm 2 --vm-hang 0 --timeout 10

$ 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 --hdd 1 --timeout 10
$ stress --hdd 2 --timeout 10
$ stress --hdd 2 --hdd-bytes 2G

まとめ

  • サーバに負荷をかける場合は stress コマンドが便利
  • CPU だけではなく,メモリとディスクにも負荷をかけることができる

ストレッチ + リフレクション + エンジョイメント /「経験学習」入門を読んだ

「経験学習」とは,経験から学び成長することで,例えば,難易度の高かった仕事/個人プロジェクトなど,日々何かしらの「経験学習」をしていると思う.自分自身が今後どのように「経験学習」をしていけば良いのか,そして技術講師として学びを伝えるためにどんなことを意識すれば良いのか,そのあたりを知るために,今回『「経験学習」入門』を読んだ.本書の導入部分にも書いてあるけど,もっと成長したい人,育成に悩んでいる人,チームマネジメントをしている人などが読者層かなと.

「経験学習」入門

「経験学習」入門

経験学習モデル

組織行動学者のコルブによって提唱された「経験学習モデル」とは,以下の学習サイクルを繰り返しながら成長するという理論で,個人的には「省察(言い換えると,リフレクション,振り返り)」が特に重要だと思う.

  • 経験 (Concrete Experience)
  • 省察 (Reflective Observation)
  • 概念化 (Abstract Conceptualization)
  • 実践 (Active Experimentation)

ちなみに,最近読んだ「教育研修ファシリテーター」にも「経験学習モデル」の話が載っていて,また出たー!感がある.

kakakakakku.hatenablog.com

3要素

本書では「経験から学ぶ力のモデル」として,以下の3要素が挙がっていた.

  • ストレッチ(挑戦)
  • リフレクション(振り返る)
  • エンジョイメント(楽しむ)

常に挑戦するというのは重要なことだけど,ストイックすぎても続かないため,好奇心を持ち,楽しむことも大切だという意味で「エンジョイメント」が3要素の中に挙がっているのは良かった.そのためには,淡々と仕事を進めるのではなく「なぜこの仕事が必要なのか?」という本質を考えることが必要だと書かれていた.また「内発的動機」に関しても言及があった.「内発的動機」に関しては「モチベーション3.0」に詳しく書いてある.仕事/メンタリング/セルフコーチングなど,どんなシチュエーションでも「ストレッチ + リフレクション + エンジョイメント」を意識すると良さそう.

kakakakakku.hatenablog.com

70:20:10 の法則

成長を決める要素の比率として「70:20:10 の法則」が紹介されていた.

  • 70% : 直接経験
  • 20% : 間接経験(フィードバック)
  • 10% : 間接経験(読書/研修)

比率に異論はないけど,個人的には「フィードバックをもらうこと」をとても大切にしていて,むしろ「フィードバックをもらえなくなったら成長は止まる」とも思っているので,工夫次第では「20%」以上の価値がある要素になると思う.本書には「ポジティブ・フィードバック」も「ネガティブ・フィードバック」もどちらも言及があった.「ポジティブ・フィードバック」は,ただ褒めるだけではなく,良いことを良いと適切に伝えることができる点がポイントで,「ネガティブ・フィードバック」は異なる価値観を気付かせることがポイントだと思う.本書にも「批判にオープンになる」という話があって良かった.

能力的成長と精神的成長

成長を分類すると「能力的成長」と「精神的成長」に分類できると書いてあった.特に「精神的成長」とは,仕事に対する信念/価値観が変わり,自己中心的なものから,他社/社会と繋がり影響を与えていくようになるということで,組織を客観的に見て,組織の課題解決に向き合ったりするのは「精神的成長」に分類されるのかもしれないと感じた.

まとめ

『「経験学習」入門』を読んだ.内容的にはそこまで新しいものはなく,これまで読んできた「自己啓発」関連の本と「メンタリング」関連の本とカブっている部分も多かったけど,改めて「経験学習」のサイクルを学び直せたのは良かった.どこまでもストイックに挑戦していく性格なので,よりエンジョイメントの比率を高くし,もっと間接経験(フィードバック)をもらいながら成長できるように頑張りたいなと!