kakakakakku blog

Weekly Tech Blog: Keep on Learning!

ドキュメントにある「リンク切れ」を検知できる「textlint-rule-no-dead-link」

textlint のルール「textlint-rule-no-dead-link」を使うと,ドキュメントにある「リンク切れ」を検知することができる.最近とあるドキュメントをレビューするときに,比較的リンクが多く,作業を効率化するために導入した.インストール手順は GitHub に書いてある.

github.com

正常

以下のようにREADME.md を準備する.

- https://kakakakakku.hatenablog.com

リンク切れはなく,正常に実行できる.

$ textlint --rule textlint-rule-no-dead-link README.md
$ echo $?
0

異常 (404 Not Found)

以下のようにREADME.md を準備する.意図的に誤ったリンクを追加している.

- https://kakakakakku.hatenablog.com
- https://kkkkkkkkkkk.hatenablog.com

実行すると,リンク切れを検知できる.これは便利!

$ textlint --rule textlint-rule-no-dead-link README.md

README.md
  2:3  error  https://kkkkkkkkkkk.hatenablog.com is dead. (404 Not Found)  no-dead-link

✖ 1 problem (1 error, 0 warnings)

$ echo $?
1

異常 (301 Moved Permanently)

以下のようにREADME.md を準備する.意図的にリダイレクトになるリンクを追加している(http → https).

- https://kakakakakku.hatenablog.com
- http://kakakakakku.hatenablog.com

デフォルト設定だとリダイレクトもエラーになる.後述する設定を有効化すると,リダイレクトを許可することもできる.

$ textlint --rule textlint-rule-no-dead-link README.md

README.md
  2:3  ✓ error  http://kakakakakku.hatenablog.com is redirected to https://kakakakakku.hatenablog.com/. (301 Moved Permanently)  no-dead-link

✖ 1 problem (1 error, 0 warnings)1 fixable problem.
Try to run: $ textlint --fix [file]

$ echo $?
1

自動修正 (--fix)

リダイレクトを検知した場合,実行時に --fix オプションを指定すると自動的に修正することもできる.

$ textlint --fix --rule textlint-rule-no-dead-link README.md

README.md
  2:3  ✔   http://kakakakakku.hatenablog.com is redirected to https://kakakakakku.hatenablog.com/. (301 Moved Permanently)  no-dead-link

✔ Fixed 1 problem

設定

「textlint-rule-no-dead-link」は現時点だと計5種類の設定をサポートしている.

  • checkRelative : 相対 URI を確認するかどうか(デフォルト true
  • baseURI : checkRelative と組み合わせて使う基底 URI を設定するかどうか(デフォルト null
  • ignore : 除外する URI を設定するかどうか(デフォルト []
  • preferGET : HEAD メソッドではなく GET メソッドで確認するかどうか(デフォルト []
  • ignoreRedirects : リダイレクトを除外するかどうか(デフォルト false

.textlintrc を以下のように書くと,設定を有効化できる.

{
  "rules": {
    "no-dead-link": {
      "checkRelative": true,
      "baseURI": null,
      "ignore": [],
      "preferGET": [],
      "ignoreRedirects": false
    }
  }
}

UserAgent は?

「textlint-rule-no-dead-link」の実装を読むと,実際に HTTP リクエストを飛ばしていたため,どんな UserAgent なのかを確認した.ローカル環境に nginx を起動して,Markdown に http://localhost を追加したところ,以下のような UserAgent だった.UserAgent を指定できる設定があっても良さそう.

HEAD node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
GET  node-fetch/1.0 (+https://github.com/bitinn/node-fetch)

Method に関しては,基本的に HEAD を使って,エラーになった場合に GET にフォールバックする実装になっている.また .textlintrcpreferGET を有効化した場合は最初から GET になる.

まとめ

  • textlint のルール「textlint-rule-no-dead-link」を使うと「リンク切れ」を検知できる
  • ドキュメントレビューを効率化できる
  • デフォルトだとリダイレクトもエラーになる
    • リダイレクトを自動的に修正できる --fix オプションもある

楽しく成長できるモビングを目指そう /「モブプログラミング・ベストプラクティス」を読んだ

2月に出版された「モブプログラミング・ベストプラクティス」をさっそく読んだ.僕はモブプログラミングの経験があり,例えばインフラ構築など,プログラミング以外の場面でも「モブ」のエッセンスを取り入れてタスクを進めることも多いけど,本書の目次を見て興味を持った部分もあり,読むことにした.本書の読者層は非常に多岐にわたると思う.モブプログラミング未経験者は是非読むべきだと思うし,モブプログラミング経験者でも新たな気付きが得られると思う.日本語で読める貴重な1冊!

目次

  • 第1章 : なぜモブプログラミングなのか
  • 第2章 : モビングの始め方
  • 第3章 : モビングと人
  • 第4章 : モビングの軌道修正
  • 第5章 : 定期的なモビングのための仕事場の改造
  • 第6章 : モビングを定着させるためのチームへの働きかけ
  • 第7章 : フロー重視の考え方
  • 第8章 : モビング定着後の長期的な展望

モブプログラミング関連本

モブプログラミング関連本だと,過去に「Getting Started with Mob Programming」を読んで,書評を書いた.しかし,現在「Getting Started with Mob Programming」は出版停止になっていて,著者の Mark Pearl 氏は新しく「Code with the Wisdom of the Crowd」を出版している.今回読んだ「モブプログラミング・ベストプラクティス」の原著は「Code with the Wisdom of the Crowd」となる.

pragprog.com

よって,本書は「Getting Started with Mob Programming」と同じ内容もあり,部分的に重複するため,以前の書評記事も合わせて読んでもらえればと思う.今回は新たに学ぶことができた点を中心に書評を書きたいと思う.

kakakakakku.hatenablog.com

成功をどのようにして計測するか

第1章に「成功をどのようにして計測するか」という内容があり,重要なのは「短期的にベロシティは下がる可能性がある」ことを理解することだけど,具体的に定量的な指標が紹介されていた.個人的な経験だと,GitHub の Issue など,開発タスクのリードタイムを計測すると,確実に短くなっていることを可視化できた.さらに定量的な計測は難しいけど,モブプログラミングを導入して,プロジェクトがうまく回るようになると,メンバーの表情も大きく変わると思う.デイリースタンドアップのときにメンバーの表情を見渡して,モチベーションを感じるような雰囲気であれば,ある意味では「成功」と言えると思う.

  • マージコンフリクトの解決にかかる時間の短縮
  • 本番システムに入り込む欠陥の数の減少
  • チーム内の経験の浅いメンバーの学習度の上昇
  • チームがモブプログラミングの導入を改善と感じているかどうか

タイムボックス付きの探求

第4章では,新しい技術スタックを採用して,チームにエキスパートがいない状態など,ある程度手探りでモブプログラミングを進める場合に「タイムボックス付きの探求」というテクニックが紹介されていた.今までの経験上,モブプログラミング中に一部のメンバーが調査をすることもあったけど,内容によっては調査が長くなり,モブセッションから離脱したような状況になってしまうこともあった.そこで「モブセッションを調査のために使う」ことにより,全員でドキュメントを読んだり,プロトタイプを実装したりして,気付いた情報を共有することにフォーカスできる.今後「タイムボックス付きの探求」を試してみたいと思う.

リソース効率とフロー効率

第7章では,モブプログラミングの価値を理解するために必要な「リソース効率」「フロー効率」の説明もある.フロー効率の重要さを説明している本はあまり見たことがなく,素晴らしいと思う.去年にプロジェクトリードの事例で登壇したときにも話したけど,無理に1人1人にタスクを分割していたり,今すぐ必要ではないタスクに着手していたりすると,もしかしたら「リソース効率」を優先している可能性がある.

f:id:kakku22:20180619124201j:plain

「さぁ!今すぐプロジェクトリーダーに立候補しよう」の登壇資料は以下にある.

kakakakakku.hatenablog.com

さらに第7章には,個人的に考えさせられる以下の記載がある.

リソース効率を重視すると、スペシャリストとボトルネックが作られるのに対し、フロー効率を重視すると、ゼネラリストが作られ、機能を早く市場に送り出すことに力を入れられるようになる。

観点によっては「モブプログラミングだとスペシャリストを目指せなくなる」と言われる可能性もあるけど,必ずしもそうではなく,スペシャリストは目指せると思う.モブセッション中はメンバー全員のスキルをボトムアップで伸ばしつつ,メンバーごとの得意領域をさらに伸ばせるように新しい技術スタックの採用などを任せるなど.過去には「スキルマップ」を運用したことがある.

f:id:kakku22:20190304131511j:plain

「プロジェクトをリードする技術」の登壇資料は以下にある.

kakakakakku.hatenablog.com

デイケアモブ

第8章には「デイケアモブ」の話題も少し入っている.個人的には「デイケアモブ」という表現はあまり好きではないけど,重要なのは「エキスパートがビギナーの教育にフォーカスしすぎていて,本来のスキルを発揮できていないのでは?」ということで,モブプログラミングに限らず,よくある場面だと思う.良し悪しではなくバランスだと思うけど,メンバーが増える場面など,意識しようと思う.

タイマー

第2章にモブプログラミングで使うタイマーアプリが2個紹介されていた.

ただ過去に紹介記事を書いた Mobster もあるし,単純にポモドーロとしてタイムボックスを決めるならウェブタイマーを使えば良いと思う.個人的には複雑なことはせず,ウェブタイマーを使うようにしている.

kakakakakku.hatenablog.com

オススメ YouTube

「A day of Mob Programming」を観ると,モブプログラミングを実施しているチームの1日の流れを知ることができる.2012年に既にモブプログラミングを実施しているなんて素晴らしすぎる!

www.youtube.com

さらに4年後の2016年に公開された「A day of Mob Programming 2016」も観ることができる.モブプログラミング環境の参考にもなるし,オフィスの様々な場所で並行してモブプログラミングが実施されていることがわかる.壁にある物理カンバンも気になる!

www.youtube.com

モブプログラミングで有名な Woody Zuill 氏の講演も非常に刺激になる.なぜ「Working Together」が必要なのか?など,モブプログラミングの解説もあるし,様々な会社でモブプログラミングを実施している風景の紹介もあるし,参加者との質疑応答もある.オススメ!

www.youtube.com

まとめ

  • 2月に出版された「モブプログラミング・ベストプラクティス」を読んだ
  • モブプログラミング未経験者/モブプログラミング経験者など,本書の読者層は非常に多岐にわたる
  • モブプログラミングに興味があるなら是非読んでみると良いのでは!

関連記事

モブプログラミングの事例は去年「ランサーズ開発ランチ」でも登壇させて頂き,登壇資料を公開している.

kakakakakku.hatenablog.com

Jupyter Notebook に環境変数を設定する

最近 Jupyter Notebook を使って Python コードを実装しているときに,設定値を直接コードに書くのではなく,環境変数から取得する必要があった.小ネタとして「Jupyter Notebook に環境変数を設定する方法」をまとめておく.結論として,今回は direnv を使うことにした.

jupyter.org

Shell 変数を設定する

サンプルとして,環境変数 BLOG_URL を設定することにする.1番お手軽に実現する場合は,Shell 変数を設定して Jupyter Notebook を起動する.設定する環境変数が少なければ,Shell 変数でも良さそう.

$ BLOG_URL='https://kakakakakku.hatenablog.com' jupyter notebook

export で環境変数を設定する

設定する環境変数が多くなる場合は,事前に export してから Jupyter Notebook を起動する.

$ export BLOG_URL='https://kakakakakku.hatenablog.com'
$ jupyter notebook

direnv を使う

繰り返し実行する場合は,自動的に export したくなる.今までもよく使っていたけど,direnv を使うと環境変数の管理が楽になる.もし direnv を使ったことがない場合は,brew から簡単にインストールできる.

$ brew install direnv
$ direnv --version
2.19.2

github.com

今回は .envrc に環境変数を設定した.なお .envrc には認証情報などを設定する場合が多く,誤って GitHub などに push しないように .gitignore に追加しておくこと.他にも awslabs/git-secrets を使うなど,防御策もある.

$ cat .envrc
export BLOG_URL='https://kakakakakku.hatenablog.com'

direnv を使う場合は,そのまま Jupyter Notebook を起動する.

direnv: loading .envrc
$ jupyter notebook

Jupyter Notebook Config に設定する

以下のコマンドを実行すると ~/.jupyter/jupyter_notebook_config.py に Jupyter Notebook 自体の設定ファイルが自動生成される.デフォルトでは全てコメントになっている.

$ jupyter notebook --generate-config

jupyter-notebook.readthedocs.io

Jupyter Notebook の起動時に実行されるため,例えば以下のように書いておくと,環境変数を設定できる.jupyter_notebook_config.py はデフォルトだとホームディレクトリに自動生成されるけど,Jupyter Notebook を起動するディレクトリに置くと優先される.ただし,あくまで Jupyter Notebook 自体の設定ファイルなので,コードのための環境変数を設定する用途は適切ではないと思う.

import os
os.environ['BLOG_URL'] = 'https://kakakakakku.hatenablog.com'

まとめ

今回は「Jupyter Notebook に環境変数を設定する方法」をまとめた.direnv を使うことにしたけど,要件によっては Shell 変数で十分な場合もあると思う.よって,以下のように Python コードで環境変数から設定値を取得できるようになった.

import os
os.environ['BLOG_URL']

せっかくサンプルとして BLOG_URL を取得できるようになったので,Selenium を使って「kakakakakku blog」のトップページをキャプチャして,Jupyter Notebook に表示できるようにして遊んだ.Jupyter Notebook 本当に便利!

f:id:kakku22:20190228185915p:plain

ブログ記事のクオリティに悩む人に読んで欲しい /「理科系の作文技術」を読み直した

2017年12月から「ブログを楽しく習慣化して書く」ことを支援するために「ブログメンタリング活動(完全無料)」をしている.既に1年以上継続していて,現在メンタリング中のメンティを含めると,計20名を超えている.「ブログを楽しく習慣化して書く」ことを支援するとは言え,メンタリング希望者は経験値によって違う課題意識を持っている.例えば「習慣化したい」というライフスタイルに課題意識を持っている人もいれば,「もっと多くの人にブログを読んで欲しい」という自己ブランディングに課題意識を持っている人もいる.その中でも特に多いのが「ブログ記事のクオリティを上げたい」という課題意識だったりする.

「ブログ記事のクオリティ」とは?

ブログ記事に「正解」はなく,誰が書いても違った良さがある.むしろ,ブロガーとしてオリジナリティを追求することも大切だと思う.さらに「ブログ記事のクオリティ」という言葉も定量的に表現しにくく,例えば PV などを指標にすることはできるけど,適切とは言えず,悩ましくもある.そこで「ブログ記事のクオリティ」「情報を適切に伝えられること」と仮に定義するならば,「理科系の作文技術」を読むべきだと思う.現在の何倍もブログ記事のクオリティを上げることができる.

僕がはじめて「理科系の作文技術」を読んだのは,大学時代に論文(情報処理学会など)を書いていた2006年で,当時所属していた研究室の先輩に紹介してもらった.既に10年以上も経過しているけど,今でも定期的にパラパラと読んでいる.そして,今まで本書の書評記事をブログに書いていなかったことに気付き,今回改めて読み直した.よって今回は「ブロガー目線として」書評を書くことにした.

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

目次

  • 第1章 : 序章
  • 第2章 : 準備作業(立案)
  • 第3章 : 文章の組立て
  • 第4章 : パラグラフ
  • 第5章 : 文の構造と文章の流れ
  • 第6章 : はっきり言い切る姿勢
  • 第7章 : 事実と意見
  • 第8章 : わかりやすく簡潔な表現
  • 第9章 : 執筆メモ
  • 第10章 : 手紙・説明書・原著論文
  • 第11章 : 学会講演の要領

「理科系の人が書く仕事の文書」とは?

第1章「序章」では,そもそも「理科系の人が書く仕事の文書」として,大きく2種類の分類が紹介されている.本書の出版は1981年で,当時は「ブログ」という言葉がなかったと思うけど,個人的にはブログは「B 類」に該当すると考えている.特に「B-4」「B-7」などはブログの特性と似ている.よって,ブロガーにとって本書が有用であると言える.

  • A 類 : 自分だけが読むもの
    • A-1. メモ,手帳の類
    • A-2. 実験ノート,野帳(野外観察用の記録帳),仕事日記の類
    • A-3. 講義や講演を聞いてつくるノート,文献のぬき書き
    • A-4. カード類
    • A-5. 講義や講演をするためのノート
  • B 類 : 他人に読んでもらうもの(仕事の文書)
    • B-1. 用件の手紙やメモの類
    • B-2. (所属機関内の)調査報告,出張報告,技術報告の類
    • B-3. 仕様書の類
    • B-4. 答案,レポート
    • B-5. 研究計画などの申請書
    • B-6. (学会誌などへの)原著論文,総合報告
    • B-7. その他の論説,解説,著書の類
    • B-8. 構造説明書,使用の手引

目標規定文

第2章「準備作業(立案)」では,文書を書く前に準備をする必要性が書かれている.特に重要なのが「目標規定文」で,これは「何を目標に文書を書くのか?」を事前に整理することを意味する.目標規定文を準備せずにブログ記事を書いてしまうと,書きながら軸がブレてしまう可能性がある.僕はブログ記事を書く前に,目標規定文(もしくは代替となるマインドマップ)を準備して,Trello タスクに記載するようにしている.さらに目標規定文を準備しておくと,ブログ記事の顔とも言える「タイトル」を決めるときにも役立つ.

パラグラフ

第4章「パラグラフ」では,文章の構成要素として,どのように「パラグラフ」を分割するべきか?という内容が書かれている.本書にはパラグラフの目安として「200-300字」と書いてあるけど,重要なのは「パラグラフの中で何を伝えたいのか?」であり,パラグラフを要約した文章を「トピック・センテンス」と言う.

「トピック・センテンス」を意識することにより,長くなったパラグラフに気付くことができたり,短すぎて不要なパラグラフに気付くことができる.また「トピック・センテンス」はパラグラフを要約した文章と表現することもでき,「目標規定文」と組み合わせることにより,必要最低限な文章構造を築くことができる.「パラグラフ」「トピック・センテンス」を意識しながらブログ記事を書くと,文章が引き締まる.

ブログ記事を声に出して読む

第8章「わかりやすく簡潔な表現」は,本書の中で特に好きな章で,個人的にも1番意識している.章立ては以下となっている.

  • 8.1 : 文は短く
  • 8.2 : 格の正しい文を
  • 8.3 : まぎれのない文を
  • 8.4 : 簡潔
  • 8.5 : 読みやすさへの配慮
  • 8.6 : 文章の中の区切り記号
  • 8.7 : 私の流儀の書き方

まず「格の正しい」とは,言葉の繋がりが適切な文章のことを言う.以下の例文(本書から引用)を見るとわかる.正しそうに見えるかもしれないけど,文末に「私は」に対応する「と思う」を追加しないと,文章として成り立たない.句読点が続く長文を書いてしまったり,主語が曖昧な文章を書いてしまうと,このように「格の正しさ」が失われる傾向が強くなると思う.

私は,この点を考えると○○氏の提出したモデルは現象を単純化しすぎている(と思う)

次に「まぎれのない」とは,曖昧な修飾を避けた文章のことを言う.以下の例文(本書から引用)を見るとわかる.「黒い」「きれいな」など,どこを修飾しているのかが曖昧で,読み間違えてしまう可能性がある.ある程度は文書のコンテキストによって明確になるとしても,できる限り曖昧な修飾を避けないと,読みにくくなってしまう.

黒い目のきれいな女の子がいた

第8章では,他にも以下の内容なども記載されている.個人的には漢字は積極的に使っていて,本書に書かれているような「字面の白さ」は意識していない(「普通 → ふつう」など).

  • 並記(箇条書きを活用する)
  • カッコ(強調をするなど適切に使う)
  • 漢字(字面を白くするために一部の漢字を平仮名にする)

本書にも書いてある通り,レビュー時に実際に文書を声に出して読むと,違和感に気付けるようになる.僕はブログ記事を公開する前に何度も読み直し,何度も声に出して読んでいる.すると,より良く書き直すことができる.

textlint-rule-preset-ja-technical-writing

「理科系の作文技術」とは直接関係はないけど,textlint を使っているなら textlint-rule-preset-ja-technical-writing を合わせて使うと,文書を読みやすく維持できる.例えば,読点の個数を制限することもできる.

github.com

まとめ

「ブログ記事のクオリティ」「情報を適切に伝えられること」と仮に定義するならば,「理科系の作文技術」を読むべきだと思う.今回紹介した内容以外にもたくさん意識するべき内容が書かれている.そして,個人的には「ブログ記事を声に出して読む」ことをオススメする.名著を吟味しつつ,さぁ!今週もブログを書くのだ!

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

Podcast

ブログメンタリングに関しては Podcast でも話してるので,興味があれば是非!

fukabori.fm

WIP プルリクエストの誤った merge を避ける GitHub Apps「WIP」と GitHub 新機能「Draft pull requests」

チーム開発をしていると,プルリクエストを WIP (Work In Progress) として送る場面は多くある.例えば,コードを書く前に設計相談をしたり,レビュー依頼をする前にパッケージ構成など全体感を相談したり,プロトタイプなどを一時的に公開することもある.進捗状況を可視化できたり,根本的な手戻りを減らせるメリットもある.

WIP を制御するツール 3選

WIP を積極的に使うとしても,WIP のまま誤ってプルリクエストを merge してしまう可能性もあり,WIP を制御するツールを使うことが多いと思う.僕自身が使っている(使ってきた)WIP 制御ツールを紹介しようと思う.今後は最後に紹介する GitHub 新機能「Draft pull requests」を積極的に使っていこうと思う.

  • Chrome 拡張「Do Not Merge WIP for GitHub」
  • GitHub Apps「WIP」
  • GitHub 新機能「Draft pull requests」

Chrome 拡張「Do Not Merge WIP for GitHub」

以前は Chrome 拡張「Do Not Merge WIP for GitHub」を使っていた.プルリクエストのタイトルに "WIP" と入っていると「Merge pull request」ボタンを押せないように制御してくれる.比較的長く使っていたけど,自分自身が誤って merge をしないように制御できるだけで,チーム開発の場合はメンバー全員に Chrome 拡張をインストールしてもらう必要があった.

chrome.google.com

GitHub Apps「WIP」

去年頃からは GitHub Apps として公開されている「WIP」を使っている.プルリクエストのタイトルに "WIP" など以下のキーワードが含まれている場合,Checks に該当して「Merge pull request」ボタンを押せないように制御してくれる.

  • wip
  • work in progress
  • 🚧

github.com

サンプルリポジトリに「WIP」を導入して,タイトルに "WIP" と含まれているプルリクエストを用意した.以下のようになる.

f:id:kakku22:20190221200953p:plain

さらに「WIP」では GitHub Marketplace で Pro 契約をすると .github/wip.yml を使って細かく設定を書くことができる.以下のように書くと,対象をタイトル以外に広げることもできるし,独自のキーワードを設定することもできる.

locations:
- title
- label_name
- commit_subject
terms:
- do not merge
- 

github.com

GitHub 新機能「Draft pull requests」

すると今月,GitHub に新機能「Draft pull requests」が追加された.プルリクエストを「ドラフト版」として送ることができる機能で,今までのように明示的に WIP と書く必要がなくなった.本当に必要だった機能と言える.

github.blog

サンプルリポジトリで試したところ,プルリクエストのステータスが「Draft」になった.「Merge pull request」ボタンを押せないように制御してくれる.さらに「ドラフト版」を通常のプルリクエストに昇格する場合は「Ready for review」ボタンを押す.ただし,一度押すと戻すことはできなさそうだった.既存のプルリクエストもあるし,もしかしたら「ドラフト版として送り忘れる」こともありそうなので,GitHub Apps「WIP」と併用しつつ,今後は公式機能を積極的に使っていこうと思う.

f:id:kakku22:20190221212121p:plain

まとめ

  • WIP を制御するツール 3選
    • Chrome 拡張「Do Not Merge WIP for GitHub」
    • GitHub Apps「WIP」
    • GitHub 新機能「Draft pull requests」
  • 今後は GitHub 新機能「Draft pull requests」を積極的に使っていこうと思う
    • 既存のプルリクエストを「ドラフト版」に戻すことができないため,GitHub Apps「WIP」と併用すると良さそう