Kotlin助走読本

Kotlinの機能や歴史が簡単にまとめてある無料の本です。後で紹介するKotlinスタートブックの作者やKotlinコントリビュータの方々が執筆しています。

Kotlinの機能が簡潔に書かれているので、助走をつけるにはちょうど良い内容になっています。

Kotlinスタートブック

Kotlin入門書の定番。助走読本と比べて各機能が詳しく説明されています。

第1部は助走読本のようにKotlinの機能が簡単に紹介されています。データ型や制御構文の説明もあるので飛ばさず読みましょう。

第2部では章ごとにKotlinの文法の説明がされています。第2部の最後まで読んだ後にもう一度見返すと、1度目とは違った見方ができるので時間があれば読み返すと良いと思います。

第3部はAndroidのサンプルアプリを作ります。Android固有のコードやライブラリについての説明が多めなのでAndroidアプリ開発経験がある場合はさらっと流す程度でも良いでしょう

KotlinKoans

KotlinReference

最後に

MFI対応について

Google Webマスター向け公式ブログの声明

何故MFI対応が必要なのか？

MFI対応の具体的な流れ

モバイルフレンドリー対応

セパレートURL配信時のデメリット

結局ダイナミックサービングにする必要がある

まとめ

参考

モバイルソリューション事業部の田中です。

ここ数日iOS界隈はiOS11がリリースされたりiPhone Xが発表されたりiOSDCがあったりといろんなイベントがありましたね。
今回はそんな話題とは関係なしにiOSの位置情報取得ライブラリSwiftLocationを紹介したいと思います。

位置情報を取得する場合、CLLocationManagerDelegateプロトコルを宣言しデリゲートメソッドやいろいろコードを書く必要がありますが、SwiftLocationを使えばそんな煩わしい作業をスッキリさせてくれます。

実装

現在位置を取得する処理は以下のようになります。

Location.getLocation(accuracy: .room, frequency: .continuous, cancelOnError: true, success: { request, location in
}, error: { error in
})

accuracyでは位置情報の精度を設定できます。

• - IPScan: IPアドレスで指定


• - any: 1000km


• - country: 100km


• - city: 3km（kCLLocationAccuracyThreeKilometers）


• - neighborhood: 1km（kCLLocationAccuracyKilometer）


• - block: 100m（kCLLocationAccuracyHundredMeters）


• - house: 10m（kCLLocationAccuracyNearestTenMeters）


• - room: 最高精度（kCLLocationAccuracyBest）


• - navigation: ナビゲーションに最適な値（kCLLocationAccuracyBestForNavigation）

Frequencyでは更新頻度を設定できます。
※accuracyがIPScanの時はこの指定は無視され、oneShotが設定されます。

• - continuous: 継続的に更新（Foregroundのみ）


• - oneShot: 一度だけ（Foregroundのみ）


• - deferredUntil: 指定された基準が満たされるまで遅延で位置情報を更新（Foreground/Background）


• - significant: 継続的に更新（Foreground/Background）

これだけのコードで簡単に位置情報を取得することができます。

そしてジオコーディングも簡単に行えます。

private func locationMonitoringAddress() {
    Location.getLocation(forAddress: "京都駅", success: { placemarks in
        print("placemarks = \(placemarks)")
    }, failure: { error in
        print("error = \(error)")
    })
}

ログはこんな感じになります。

placemarks = [京都市, 京都府京都市 @ <+35.01096850,+135.76820130> +/- 100.00m, region CLCircularRegion (identifier:'<+35.09822930,+135.71884765> radius 28727.67', center:<+35.09822930,+135.71884765>, radius:28727.67m)]

いかがでしょうか。

今まで私はPromiseKit/CoreLocationを使っていましたが、こちらもなかなか良さそうなので次に位置情報を使ったアプリを作る際はSwiftLocationを試してみたいと思います。
他に逆ジオコーディングやリージョン監視なども行えますのでなかなか便利そうです。

DroidKaigiとは

What is DroidKaigi?
DroidKaigiはエンジニアが主役のAndroidカンファレンスです。
Android技術情報の共有とコミュニケーションを目的に、2018年2月8日(木)、9日(金)の2日間開催します。
今回は「ニッチな技術とコミュニケーション」を重視する予定です。

全体的な感想とまとめ

• ・How to improve your MVP archtecture and tests


• ・Anko試食会


• ・コードで見るFlutterアプリの実装


• ・開発者が知っておきたい通知の歴史

How to improve your MVP archtecture and tests

Anko試食会

コードで見るFlutterアプリの実装

開発者が知っておきたい通知の歴史

さいごに

経緯

前夜祭

当日

最後に

こんにちわ、モバイルソリューション事業部でサーバーサイドを担当してるアキです
暖くなってきたとともに花粉の季節の到来ですが、いかがおすごしでしょうか。

弊社では週1で持ちまわりで部署の垣根なくエンジニアで集まって技術発表をしております。
今日は先日自分が発表した内容をせっかくなのでブログにも書きたいと思います。

いつも笑いを取ることに力を入れすぎる余り、要約すると内容がないよう。となりますが、沢山しゃべってもこういう場では伝わりきらないので良しとすることにします。良しとしてください。

Q.ちゃんとテスト書いてますか？

そんなタイトルでやりました。

テスト大事なのは当然なんですが、ちゃんと見ればいろんな方法がありますよね。できればフル活用したいですよね。とはいえ、テストって辛い時がありますが、僕だけですか？きっとみんなそうなので、一緒に頑張りましょう！というお話です。

LinterとFormatter

このスライドの一枚を思いついてしまったがタメに今回の題材を決めたといっても過言ではないです。

が、ジェネレーションギャップなのか、全く笑いがおこらなかったのでツライばっかりでした……。

テストコード書いたり、テスト回したりする前にもっとLinterとFormatter活用しましょうよ。というお話。

個人的にJS界隈でのフォーマッタPrettierが良い感じで、さらにES-Lintとの組み合わせが強力で素敵だと思います。ちなみにRubyにもRufoというフォーマッタがありますがイマイチ人気があがってこないですね。でもLinterはRubocopを使わないほうが少ないんじゃないでしょうか。その連携が上手くいくと良いですよね。

エディタでリアルタイムでLintするほか、Pre-commitでフックすると効果的です。Node.js系であればいろいろありますが、一つの例としてhusky + lint-staged、Rubyであればpre-commitというGemがありますので導入も簡単です。Pre-commit時だとキツい場合はPre-pushでも良いかと思います。

要点は、バグを混入させないように自動で防げるものはやったらいいよね、という話。

もう1点、僕が考える運用として「ルールは聖域とする」ことです。WARNINGなどは警告のみで無視できるものも多いです。ただし、無視できるルールを無視してると割れ窓理論的にどんどんルールが無視されていって、結局Lintしてる意味がなくなってきてしまいます。無視していいルールなら、そもそもルール自体の制約を緩めるべきで、検出されたら直しましょう、という意味での「ルールは聖域」です。理想論的な部分もありますが。

ビジュアルリグレッションテスト

視覚的回帰テストですね。そこまでメジャーじゃないものの、BackstopJSなんかは導入が以前より遥かに楽になっててびっくりしました。デザインの変更は意図した変更と意図しないものがあるので、最終的には人の目の判断ですが、それでも転ばぬ先の杖としてかなり有用ですね。

ちなみにコードレベルではなく、見た目レベルでの差分を出すため、例えば同じサイズだけど画像が差し変わってしまった場合なんかも検知できます。モバイルソリューション事業部のサーバーサイドではあまり出番はないですが、使えて損はないですね。

デモをしたんですが、だいぶ私的なものをサンプルに使ってしまったのでここでは残念ながらお見せできません。

ユニットテスト

テストと言えばユニットテストなので、今回はアサーションに絞ったお話です。Rubyのテストツール、Rspecが与えた影響は素晴しいと思います。テストコードがかなり英語と同じ感覚で読めるので、何を意図しているかわかりやすいです。その反面、デフォルトで使ってる限りは、テストに失敗した時に、何が失敗してるかが掴みにくいこともあります。またマッチャが多いため、複雑になってくると相応に学習コストも上がっていきます。

個人的にはテストで詰まった時がツライので、Rspecのような自然言語寄りの思想より、Power-assertを好んでいます。Power-assertの場合、テストをパスしなかった場合の情報がわかりやすく表示されるので何を修正すべきか判断しやすいです。また、マッチャもシンプルなままなのも良いですね。その反面、実装や仕様を把握してないとテストコードからテストの意図を読み取るのはRpec的な自然言語に近いほうが良いかもしれませんね。

余談ですが、RspecでPower-assertを使う方法もあります。

ここもやはりデモをしたんですが、だいぶ私的なものをサンプルに使ってしまったのでまたしても残念ながらお見せできません。

E2Eテスト

Rubyでは既にデファクトスタンダードとなったCapybaraがありますが、今回はササっとサンプルを作ったのでNode.js系のNightwatchでデモをしました。思ったより簡単に書けました。フレームワークやドライバーはたくさんあって書き方も変わりますが、一つ使えると応用が効く範囲ですね。

また、最近特にヘッドレスブラウザの活躍が目覚しいので、CI上で回せる点も良いですね。なお最近ではコーディングなしでテストが作れるような流れもあるので、もはやエンジニアではなくディレクターさんがテストを作ってしまう、ということも可能になりそうな気配です。ここはササっと紹介だけになっちゃいました。

まとめ

いつも業務のテストではRspecばかりですが、今回ビジュアルリグレッションテストを使ってみたり、JESTを触ってみたりしていろいろと知見が増えました。JEST、良いですね。相性もありますがPower-Assertとも組み合わせられますし。ビジュアルレグレッションテストは導入も簡単なので上手く使っていきたいですね。

テストの書き方に困ることはありますが、「どんなテストも無いよりマシ」を胸に、なるべくテストを沢山書いて、安心して開発していきたいと思います。

ドメインの確認プロセス

取得プロセスの実装

ハマったところ

まとめ

それにしてもIT業界人って造語作るの上手いですね！

どのようなプロダクトがあるのか

従来のRDBとどこが違うのか

とても便利そう！だけどやっぱりよく分からなかった

RDBMSとの用語対応表やマニュアル

NoSQL（MongoDB）をお勧めしたい理由

まとめ

新年度ですね。アキです。いや、季節は春なんですが、今回のブログ担当が僕、アキです。どうも。

弊社でも多くの開発現場と同様、Gitでのバージョン管理を行なっています。フレッシュな若者達がうっかり変なコミットをしたり、戻そうとして泥沼にはまったり、勢いでforce pushしてしまったりするんでしょうか。ワクワクしますね！

今回は各種コマンドでどうこう、というお話ではなくそれ以外のGitの話をしてみようと思います。

基本にて王道のコミットメッセージついて再考察してみる

簡単ですが奥が深いと思っているコミットメッセージ。結局のところログなので大切なことは、

1. 可読性を持つこと


2. 被検索性を持つこと

が大前提ですね。後から探すのが楽で、見たらすぐ何かわかる、というのが理想です。

さんざん今まで議論され尽してきた感がありますが、今いちど、このルールを再確認しましょう。
How to Write a Git Commit Message

また、commitizenというプロジェクトがあります。
これはルールにのっとって対話式にコミットメッセージを作成するCLIなんですが、デフォルトの設定が秀逸です。

タイプ(スコープ): タイトル

というフォーマットを使います。
タイプは例えば、fix、feat、doc、build、choreなどが入ります。
スコープはある場合記入し、タイトルのところには先程コミットメッセージのルールにのっとったようなメッセージが続きます。
そしてもちろん必要な場合は3行目から詳細を書きます。

個人的には日本人のみで構成される開発チームの場合は可読性と検索性に考慮していれば日本語コミットでも良いと思っています。ただし、英語の言語特性では動詞、つまり一番核となるものが最初に来ます。そのため分かりやすいメッセージになりますが、日本語の言語特性の場合、最後に来ることが基本になります。
日本語でわかりやすいコミットメッセージにしようと思ったら、英語よりさらにルールを追加するのが良いでしょう。例えば、

修正: ◯◯のバグ

とか

機能: ◯◯の実装

のように。先に動詞をもってくる、体言止めにする、読点はつけない、みたいにすると良さそうです。また同音異義語や同じような意味も多いので使う言葉をあるていど絞ったほうが良いかもしれません。最初に言った被検索性に留意したいですね。

Protected Branchを使う(GitHubの場合)

GitのシステムにGitHubを使っているなら、Protected Branchの設定ができます。これは設定したブランチに対してforce pushが効かなくなるように保護してくれるものです。例えばmasterやproductionブランチが重要な場合、運用コストがかからないので設定しておくのが良さそうです。

その他にもstatus check機能で、PullRequest時にCI上のテストが通らないとマージを行なえない、など設定することも可能です。

Git hooksを活用する

GitHub上でCIによるテストが回るように、ローカルでも特定のGitコマンドをトリガーにして特定の動作を自動でおこなうことができます。これはGitHubではなくGit自体の機能なのでどのような環境でも使うことができます。

例えば、コミット時にLinterやformatterをかける、Push時にテストを回す、など。また、工夫次第では特定のブランチの場合、プッシュをリジェクトなんていうこともできます。

設定の仕方は/.git/hooksにそれぞれのトリガー用のシェルスクリプトを置くだけです。

僕の場合はmaster、もしくはproductionブランチにプッシュしようとすると警告を出して確認するスクリプトが走るようにしています。これは自分ではmasterからトピックブランチ生やして作業していたと思ったら生えてなかった！ ってことがあったからです。上で説明したProtected Branchではforce pushしか防げないので、両方設定するよにしています。
具体的には以下のスクリプトを/.git/hooks/pre-pushとして保存するだけです。
（実行権限の付与が必要です）

#!/bin/bash

while read local_ref local_sha1 remote_ref remote_sha1
do
  for branch in "master" "production"; do
    if [[ "${remote_ref##refs/heads/}" = "${branch}" ]]; then
    echo "警告:重要なブランチにプッシュしようとしています。正気ですか？ [y/N]"
      exec < /dev/tty
      read ANSWER
      case $ANSWER in
        "Y" | "y" ) echo "プッシュします";;
        * ) echo "プッシュをキャンセルしました";exit 1;;
      esac
      exit 0
    fi
  done
done

Git Hooks を活用するための便利なもの

Rubyでは、pre-commit時だけでよければpre-commit、全てのトリガーに対応するならばovercommitなどがあります。
特に後者はカスタムスクリプトも走らせられるので、上で説明した自作のpre-pushなどを併用することができます。

またNode.js系が使えれば、huskyが有名ですね。こちらはpackage.json内にトリガーに応じたコマンドを記述するので|や&&でつなげば自作スクリプトも併用できます。特にlint-stagedと組み合わせることが多いです。

テンプレートを活用する(GitHub)

GitHubを使っているならIssueやPullRequestも使っていると思います。実はこれらはテンプレートを決めて、新規作成時に自動で挿入してくれる機能があります。

使いかたはプロジェクト直下、または/.github内にPULL_REQUEST_TEMPLATE.mdとISSUE_TEMPLATE.mdをそれぞれ置くだけです。

例えば要望のIssueのテンプレートなら

## 要望概要

## ゴール
<!-- この要望を達成したと見なす条件 -->

## タスク
- [ ] タスク1

とか。PullRequestのテンプレートなら

## 概要
FIX or RESOLVE or CLOSE: #

## 内容

## 想定する影響範囲

## 動作に必要なコミットに含まれない変更
<!-- e.g. 環境変数, DBの更新 など -->

## 補足

とか、実はまだ完全に定まってはいないんですが、ちょこちょこ使っています。

テンプレートの効能として、ある一定のクオリティを保った内容になるとともに、ガイドができて内容を書きやすくなるので、積極的に使うほうがいいと思います。特にIssueについては非エンジニアの人が作る開発現場もあると思います。そういう時にテンプレートがあれば、まず状況を確認するの必要な情報が入りやすくなるのでオススメです。

外部サービスのAPIが遅い

実はIPv6の名前解決が遅かった

11:01:42.081559 IP 1.1.1.1.51266 > dummy.jp.domain: 64983+ A? api.service.com. (38)
11:01:42.082310 IP dummy.jp.domain > 1.1.1.1.51266: 64983 2/3/3 CNAME cname.api.service.com., A 2.2.2.2 (187)
11:01:42.082431 IP 1.1.1.1.33833 > dummy.jp.domain: 21547+ AAAA? api.service.com. (38)
11:01:47.085722 IP 1.1.1.1.33833 > dummy.jp.domain: 64983+ A? api.service.com. (38)
11:01:47.086453 IP dummy.jp.domain > 1.1.1.1.33833: 64983 2/3/3 CNAME cname.api.service.com., A 2.2.2.2 (187)
11:01:47.086582 IP 1.1.1.1.58653 > dummy.jp.domain: 21547+ AAAA? api.service.com. (38)
11:01:48.634999 IP dummy.jp.domain > 1.1.1.1.58653: 21547 1/0/0 CNAME cname.api.service.com. (69)

IPv6を無効にするも改善しない

faradayのアダプタを取り替える

まとめ

こんにちわ、アキです。全国的に梅雨シーズン到来ですね。ジメジメして不快指数も上がってくる季節ですが、気分はいつもカラっと行きたいものですね。そしてそんな気分が晴れるように元気にコーディングしていきたい方法として、モブプログラミングなんていかがでしょうか。

モブプロをやってみました

モブプロとは

そもそもモブプロの前にペアプログラミングのお話。ペアプログラミングとは

• 1つの画面


• 1つの端末


• 2人のエンジニア

という構成で、コードを書く人 = ドライバー、書いてなくてサポートする人 = ナビゲーター という役割でプログラミングをしていくスタイルです。イメージとしては車などのラリーのように、ハンドルを握る人とそれを全面的にバックアップしてサポートするところから来てるようです。

モブプログラミングはこれをベースにナビゲーターを複数人にして、みんなで一つのコードをやっつける、という手法です。そうすることにより活発なコミュニケーション、意見交換がされながらコードが発展していきます。

このドライバー、ナビゲーターの役割は一度決めたらそれきりではなくタスクの節目や時間単位を目安に適宜交代していきます。

きっかけ

きっかけは僕がモブプロの勉強会に参加してまるで天啓かのように感銘を受けたから、と言ってしまえばミもフタもないんですが、ちょうど4月から弊部にも新人が入り、チーム的なお作法を共有する場、お互いの理解を深める場、先輩と後輩の垣根を低くする場として上手く活用できそうな気がして試験的に初めてみました。

やってみてわかったこと

モブプロとペアプロは別モノ

ペアプロの場合

ペアプログラミングの場合、技術レベルが同程度なら良いんですが例えば今回のケースのような新人加入時のように技術レベルに差が明確な場合、意外に難しいと思います。

1対1になってしまい、そこに差があると結局先輩の言うとおりに手を動かすだけになってしまいがちです。また後輩側が良い意見がある場合でも遠慮してしまったりでなかったことになってしまうことにもなるでしょう。
モブプロやペアプロが周りの助けを借りながら出来る強力さがある一方、ドライバーは思考停止してもできてしまいます。この場合、先輩は後輩に知見をどんどん伝えていきたいところですが、思考停止してしまうとお互いに良い効果が生まれません。
という理屈で、実力差がある場合のペアプロはなかなか難しいことを痛感しました。

モブプロの場合

ナビゲーターが複数という状況が上手く回るきっかけになります。

複数の視点を持ち、複数の意見が聞ける、コンセンサスを得ながら進む心強さがあります。また心理的にも時間的にも余裕が生まれやすく、実力差や先輩後輩関係があっても必要以上の緊張感を負うことなく取りくめました。

まとめ

• 他の人の強みや弱みを知るきっかけになる
  
  
  • リアルタイムにコードを書いてたり意見を出し合うとレビューよりも如実に相手の考えがわかりました
  
  
  
  


• 楽しい
  
  
  • ただしもちろんコミュニケーション自体を負担に思う人も居るはずなので配慮は必要
  
  
  
  


• ノせる力が必要でした
  
  
  • 特に今回のように自分だけ経験者の場合「モブプロ良いね」って雰囲気まで持っていくのにノせる為の強引さみたいなものは必要でした
  
  
  
  


• 心理的安全性が高い
  
  
  • これが一番大きな効果であり、一番の利点な気がました
    
    
    • 設計やコードの方針のコンセンサスがちゃんと取れていること
    
    
    • みんなで協力する共闘感
    
    
    
    
  
  
  
  

疑問

と、ここまで「モブプロ良いぞ」って説明したところでいくつか質問が出たのでその答えを。

（人的、時間的）リソースもったいなくない？

モブプロがいくら良さそうでも、個々が分担して平行作業したほうがよっぽど効率的に進む気がするという御意見、ごもっともです。
ただし、それはコーディングだけをとってみれば、な実感があります。

通常、開発が進んだらプルリクエストがありレビューする流れというのが一般的だと仮定した時、レビュワーはレビューする段階で初めてコードを見ます。そこからプルリクエストの意図、実装方針や内容の意図、各コードに異常がないかのチェックなどを行なっていくことでしょう。その間、当然レビュワーは自身の別の事は行なえないですよね。

モブプロの場合、意図も方針も納得ずくのコードができあがるため後からレビューする手間もほぼありません。そこまでトータル的に見た場合、決して人的、時間的リソースがもったいないことにはならないでしょう。

全部モブでやったほうが良い？

いえ、モブで解決にするのに適さない課題もあるなあという実感もしました。

• スコープが広かったり腰を据えてやるべき課題
  
  
  • 調査
  
  
  • バグ探し
  
  
  
  


• 実験的な実装

調査やバグなど情報のインプットと整理がメインの作業に関しては、モブでやったから効率が上がるわけでもなさそうです。また、実験的に試行錯誤する場合も同様です。

まとめ

今現在は僕の所属するモバイルソリューション事業部のサーバーサイドで試験的にやってみている状況です。仕掛け人は僕ですが、なんとか他のメンバーの皆さんにも好評をいただき週一ぐらいのペースで時間を設けて続けています。

今回、社内勉強会で他のチームや部の方々にも知見と楽しさは共有できたと思うので徐々にその波が広がっていったら嬉しいなあ、と思う次第です。

ジメジメした季節もワイワイして乗りきっていきたいですね！

梅雨なんて一瞬で過ぎさったかのように明けてしまいまして、毎日暑い日が続きますね。どうもまた僕です、アキです。そしてまたGitの話題です。

以前「Gitにまつわるエトセトラ」ということでGitについていろいろ書きましたがその続きと捕捉のお話になります。

コミットフレンドリー

コミットメッセージには相変わらず悩みますね。前回も触れましたが個人的に以前からcommitizenを導入して使っています。

これはgit commitをgit czなどのコマンドに置きかえて、なおかつ対話的にコミットメッセージを作るラッパーライブラリです。もともとAngularJSなどで制定されているGit Commit Guidelinesに沿ったもののようで、Vue.jsでも同様のものが見られます。

これを使いだして以前よりは楽にコミットメッセージが書けるようになったのと、副次効果としてはこのメッセージでコミットの区分分けをすると逆説的にコミットの粒度や範囲もルールにのっかるようになってきます。コミットメッセージと変更内容の整合性が良い感じになって感じはあります。

これは是非他の人にも使ってもらいたいし、仲間に「貴様のコミットメッセージはわけがわからん！」と面と向かって言えないToo Shy Shy boyなので、ツールで誤魔化す作戦にでることにしました。

といっても単純に対話的に作る部分の質問分と選択肢を日本語に翻訳しただけです。せっかくなのでNPMで公開もしてみました。

cz-conventional-changelog-ja - npm

(実はNPMで公開するのは初なので不備があるかもしれません。自分でも見なおして修正していきたいです。)

使い方はcommitizen - npmを読んでいただきたいんですが、設定を"path": "cz-conventional-changelog-ja"にすれば大丈夫なはずです。

fixなのfeatなの、どっちなの？

実は今まで使ってきて機能追加なのか修正なのか、両方なのか、悩むことがたまにあったんですがこのパッケージをNPMに上げる過程でなんとなくわかってきました。

元であるcz-conventinal-changelogにはsemantic-releaseというライブラリによってリリースバージョンを自動で生成してるんです（便利！）が、仕組みとしてはセマンティックバージョニングに準拠していてfixがあったらpatch、featがあたらminorのバージョンが上がるようになっています。

これも逆説的に考えると今行なった変更がminorバージョンを上げるような機能の変更(or追加)ならfeatだし、patchレベルであればfixだな、と考えることができるようになりました。万事OKなわけではないですが、悩んだときの一助になって良い感じです。

Pre-commitフックをちゃんとする

前回も言及しましたが、僕は基本的にほとんどのプロジェクトでhuskyでhookしてlint-stagedでコミット対象にLintを噛ませてます。

良く紹介される方法でも十分効果的ではあるんですが、対象がファイル単位になるためhunkに分けたい場合でもファイル単位で上がりなおってしまう、ということがありました。lint-stagedのリポジトリをつぶさに見ていたらhunk対応版の方法があがっていたので共有したいと思います。

package.jsonを以下のようにします。

{
  ...（中略）
  "scripts": {
    "cz": "git-cz",
    "precommit": "lint-staged",
    "stash-unstaged": "git stash save -k 'pre-linting-stash' >> /dev/null",
    "lint-staged": "lint-staged || (npm run pop-stash >> /dev/null && exit 1",
    "pop-stash": "git stash && git stash pop stash@{1} && git read-tree stash && git stash drop"
  },
  "pre-commit": [
    "stash-unstaged",
    "lint-staged",
    "pop-stash"
  ],
  "lint-staged": {
    "*.{js}": [
      "eslint --fix",
      "eslint"
    ]
  },
  ...
}

lint-stagedの前後にgit stashによる退避と戻すのを挟む方法ですね。
この方法を導入してからhunkを多用気味な僕としては心に平穏が訪ずれました。

ちなみに業務ではRubyを、プライベートではVue.jsを良く触りますが、lint-stagedを上手くやってやればTypeScriptでもRuby+Rubocopだろうとどんとこいです。
Rails 5.1以降からYarnが正式に使えるようになったので、嬉しい副次作用です。
また、もちろんESlintにはPrettierも同時にかかるように設定してます。

まとめ

lint-stagedまわりはプロジェクトにNode.js系の要素がないとちょっとツライところですが、最初にご紹介したCommitizenはグローバルインストールでもいけるのでどんな言語のプロジェクトにも対応できますね。

もうちょっと上手く拡張してプロジェクトごとにタイプの設定を載せてルール付けるのもアリかもしれませんね。日本人だけのプロジェクトであればタイプとスコープは英語にして、その後のメッセージは日本語でも良いかもしれません。重要なのはある程度決まった型にそろえる、ということですね。

コード中にしろコード外にしろ、フォーマットをある程度揃えるのは本質じゃないところの統一することでノイズをカットして本質を注視しやすくする。そしていろいろサクサクやっていくぞ！ という意気込みです。

tanaka

@msa_uccky

テツ

Ryoth+

baba

アキ

やぎにい (@yaginier)

うすき

seto

むとう(@oddmutou)

@teckl