その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

Multiple projectなgradleのprojectでcheckstyle pluginを有効にする

Multiple projectなgradle projectだと, apply plugin: "checkstyle" と書いてもそれだけではcheckstyle pluginがうまく動かない.おそらく Unable to create Root Module: config ... などというエラーとともに死ぬであろう.
というのも,gradle checkstyle pluginのデフォルトの状態だと,各sub projectがおのおの checkstyle.xml を持っていることを期待しているからである (つまり[sub-project-path]/config/checkstyle/checkstyle.xml の存在が期待されている).
たいていの場合, checkstyle.xml を各sub projectが持つというのはやってはおれんので,どこかで一括管理をしてそれを各sub projectから利用したいでしょう.というわけでこう書いてやると良い;

subprojects {
    // do something...

    apply plugin: "checkstyle"

    checkstyle {
        // do something...

        configFile = rootProject.file('code_quality/checkstyle/checkstyle.xml') // <= here!
    }
}

subprojects.checkstyle.configFile に所望の checkstyle.xml を指定してやると良い.
この例ではproject rootに配置されている code_quality/checkstyle/checkstyle.xml が各sub projectからも参照されるようになる.
めでたしめでたし.

ミニマルなサンプルを置いておきます.

github.com

checkstyle.xml に誤りがある場合の挙動

それはそうと checkstyle.xml に誤りがあると

Execution failed for task ':your-project:checkstyleMain'.
> Unable to create Root Module: config {/path/to/your/checkstyle.xml}, classpath {...}.

みたいなエラーとともに死んでしまう.このエラーメッセージで checkstyle.xml にエラーがあるとは思うまい.しかしそうなのです.
仕方がないので --stacktrace オプションを有効にして再度 checkstyleMain を実行すると,それらしきstacktraceがゲロッと吐かれるので,それをもとにxmlファイルを修正していくことができるようになります.マジかよ,つらい.
このエラーメッセージは本当に不親切だと思うしなんとかなってほしい…… これに出くわした時,checkstyle.xml に誤りがあるとは全く思っておらず数時間を浪費してしまった.

checkstyle.xml に変数を埋める方法
checkstyle {
    // do something...

    configProperties = [
            'checkstyle.cache.file': "${buildDir}/checkstyle.cache",
    ]
}

みたいな感じで build.gradle で定義してやると, checkstyle.xml 上で

<property name="cacheFile" value="${checkstyle.cache.file}"/>

という感じで変数を利用できるようになる.この build.gradle 側の設定を怠ると不親切なエラーとともに死にます.勘弁してくれ.

Karabiner-Elementsでcolonとsemicolonを入れ替える

[追記]
コメントで指摘がありましたが,Karabiner-ElementsのGUI上で
complex modifications → Add rule → import more rules from the Internet → Exchange semicolon and colon
を選択することで所望の動作の実現が可能なようです.

従って本記事はcolonとsemicolonを入れ替えるというよりも,任意のキーを入れ替える時のためのtipsとなります.
[追記ここまで]

MacのUSキーボードの話です.

Karabinerにはcolonとsemicolonを入れ替えるという項目があり,これが大変便利だったのですが (特にvimを使っているときとかに便利),Karabiner-Elementsではこのオプションがありません.現時点では,macOS Sierra上だとKarabiner-Elementsを使うほかないので,つまりGUI上からcolonとsemicolonをswapする方法がありません.

そもそもcolonとsemicolonを入れ替えて使うというのがアレなので,Sierraに移行したのを機に元に戻すことも考えたのですが,しかし入れ替えた環境に慣れてしまっているので難しい.なんとかしたい.というわけで以下を ~/.config/karabiner/karabiner.json に書き込むと入れ替えができる.

{
    "global": {
      ...
    },
    "profiles": [
        {
            "complex_modifications": {
                ...,
                "rules": [
                    {
                        "description": "Swap colon and semicolon",
                        "manipulators": [
                            {
                                "type": "basic",
                                "from": {
                                    "key_code": "semicolon",
                                    "modifiers": {
                                        "optional": [
                                            "caps_lock"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "semicolon",
                                        "modifiers": [
                                            "left_shift"
                                        ]
                                    }
                                ]
                            },
                            {
                                "type": "basic",
                                "from": {
                                    "key_code": "semicolon",
                                    "modifiers": {
                                        "mandatory": [
                                            "shift"
                                        ],
                                        "optional": [
                                            "caps_lock"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "semicolon"
                                    }
                                ]
                            }
                        ]
                    }
                ]
            },
            ...
        }
    ]
}

profiles.complex_modifications.rules の中身をこのように書くと所望の挙動となる.よかったよかった.

他のキーの入れ替えについてもこれと同様な感じで書き込むといけそうで良いですね.

社内でDDD勉強会をやった

DDD (Domain Driven Design/ドメイン駆動設計) についての学習気運があり,その勉強会を社内でやったのでその経過を記すものです.
DDDに関する詳細な内容には触れません (良い本や資料が巷には溢れています).読書会自体をどうやったか的な話です.

前提

developer.hatenastaff.com

基本的にこのスタイルを真似しました.

読んだ本

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

実践ドメイン駆動設計

エリック・エヴァンスドメイン駆動設計 (青本) を読んでから,実践ドメイン駆動設計 (IDDD/赤本) を読んだという流れです.

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

やっていませんが,続いて上記の本 (黒本) を読むというのもありかも知れないね,という話を会のメンバーとしました.

も良いかもわかりません.

が,とにかく青本をやってから赤本をやるということにしました.理由としてはやはり原典を読んで知識を付けてから実践に行ったほうが良いであろうという考えからです.確かにDDDを形作るエッセンスが青本には記されており,一読しておいて損はないと思いましたが,しかし後になって思い返すと別に赤本だけでも問題ない気もしました (もしかしたら青本の代わりにInfoQのDomain Driven Design Quicklyを読むのでも十分なのかもしれない).読みたい本を読むべきです.

進め方

  • 1週間に1回開催 (やむを得ない場合は開催されないこともある)
  • 1回あたりに1章やる (1章が長い場合は2回程度に分割する.話を忘れてしまうので2回を超えて分割しないほうが良いと思っている)
  • 全員があらかじめ該当する範囲を読んでおく
  • 週替りで当番を決め,当番になった人はその章の中で疑問に思ったことや議論したいことをmarkdownにまとめてGitHubのrepositoryにpull requestとして投げる
    • あくまで疑問点や議論したいポイントをまとめるのであって,内容をまとめるわけではない
    • 当番でない人も,疑問に思ったことや議論したい点についてはpull requestのコメント等で表明していく
    • 当番になった人はその回の司会もやる
  • そのmarkdownをベースとしながら疑問の解消や議論等を行なう (適宜本の内容をなぞっていく)
  • 勉強会が終わったら飲みにいく

重要な点は,「参加する全員が本をしっかり読み込んでおく」という点と「疑問点や議論したい点をまとめる」という点です.
前者が成り立つからこそ,後者も成り立ちます.しかし後者は慣れるまでなかなか難しい.うっかり内容のまとめになってしまいがちなので「全員しっかり本を読んでいる」という事を意識していく必要があると思いました.

そして個人的に重要だと思ったのは「勉強会が終わったら飲みに行く」というものです.これは勉強会の延長のようなもので,ざっくばらんに議論してみたり,あるいは「最近こういうことで困ってるんだけど,今日のこのアプローチでいけないか」などという感じで軽く相談が出来るので,なかなか良かったと思いました.また飲み会が勉強会のモチベーションのひとつにもなる (個人の意見です)。
飲み会が嫌いな人には合わないかもしれませんが,幸いにも今回の勉強会のメンバーはみんな飲み会が好きな人が集まったので,これはよくドライブしたように思います.

なおGitHub使うかどうかとかは重要な問題ではなく,チームや企業に合ったツールを使えば良いと思います.

規模

今回は4人でした.これくらいの人数でちょうどよかったな,という感想です.
勉強会の規模が大きくなっていくとどうしても自分事感が希薄になっていき「俺が読んでなくても大丈夫だろう」「議論に参加しなくても問題ないだろう」という感じになっていきがちですが,この程度の規模感だとそうなりにくく,全員参加型でほどよい緊張感を持って進めていけるので良いと思いました (あとこれくらいの人数だと飲み会の予約も取りやすいし).

困った点

DDDに本当に詳しいエキスパートが不在だったため,「これで本当に合っているのか」などといった疑問に襲われることが何度かありました.
そういう時は一応議論をしつつインターネットで調べながら手探りで答えを探してゆき「まあこういうことなんじゃないか」と全員で認識を合わせることで乗り切っていきましたが,もしかしたら間違えた知識を身につける可能性も孕んでいます.
勉強する分野のプロがいた方が良いな〜というのには首肯するところであります.

所感

なんやかやこういうスタイルで1年近く継続して勉強ができて良かったです.
独習に向く分野もあれば,複数人で学ぶのが向いている分野もあると思っており,DDDは後者に近いと思いました.その理由というのも,DDDには方法論だけではなく,プロジェクトに関わる全員に関係のある組織論に近い要素が含まれていると思ったためです.複数人で議論をし,認識を合わせ,不明な点を少なくしていくというスタイルは実際のDDDにも通じるものであり,その結果このような勉強会のスタイルは上手くマッチしたのではないかと思いました.

今後も何か興味深い分野があったら,このようにやってみたいものです.

私信です

私信ですが転職いたします.以下の通りです.

From: LINE
To: Soracom

関係各位に感謝を申し上げます.ありがとうございました.
以上です.よろしくお願いします.

なお本記事は以下のレギュレーションに従いました.

twitter.com

[追記]
職場崩壊だとか,ネガティヴな方向に持って行きたがる向きが散見されますが,それらに対する回答は以下の通りです.職場崩壊なんて一切無かったし,本当に良い会社及び同僚でした.これ,キラキラレギュレーションに引っかかりますかね? まあいいや!

Kyoto.なんか #3で「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました

kyoto-nanka.connpass.com

「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました.スライドは以下です.

speakerdeck.com

前回開催のKyoto.なんか #2では「そして物語は何度目かのアプリ内通知再実装を迎える」というタイトルで話したのですが,今回はその後日談 (?) の話をしました.

とにかくストレージ周りで苦労をしたくない,そしてできるだけ生に近い状態でデータを取り扱いたい,というモチベーションから,バックエンドのストレージにS3を採用し,RSS (Atom) ファイルをPUT (or PATCH) することで,低い労力でスケーラビリティを確保するというアーキテクチャを提案しました.
実際のS3をバックエンドとしたアプリ通知実装は,個人の趣味アプリでPoC的に実装した程度なので,実際に高い負荷が与えられた時にどうなるのかというのは身をもって体感していませんが,まあある程度はいけるんじゃないでしょうか……という見解でいます (とはいえこれは実際にやってみないとなんとも言えないでしょう).


スライドの後半に出てくる,「onetime tokenを用いたS3からのfetch」については,発表中に「Pre-Signed URLsを用いれば似たようなことができる」という指摘を頂戴しました.ありがとうございます.セキュリティの要件にも依りそうですが,これを使うと対応できそうですね.
またスライドの方のブコメにも付いていましたが,「Amazon STSを使う」という方法でも対処できるようです.知りませんでした.


発表後の懇親会で議論した内容としては,

  • ユーザ数が多いとPUTやGETする為の金銭的コストがばかにならないのではないか
  • 複数の通知を1つに束ねる場合にRSSだと難しいのではないか

というものがあり,確かに……となりました.

前者の「金銭的コスト」については,確かに配膳する対象のユーザが増えれば増えるほどかさんでしまうので,実サービスに投入した時にうっかり破産,という風にならないような工夫が必要だなあと思いました.ここらへんは既存ストレージの管理コストや開発コスト等とのトレードオフになりそうな印象を抱きました.

そして後者の「複数の通知を1つに束ねる」というのはなかなかの難題だと感じました.例えば「Aさんがいいねをしました」という通知と「Bさんがいいねをしました」という通知をそれぞれ独立した1通ずつの通知にするのであれば,素朴に各々を1つのエントリにして,片一方を追記すれば良いので実装は単純ですが,仮に「Aさんがいいねをしました」という通知が来た後に「Bさんがいいねをしました」という通知が発火した際は「AさんとBさんがいいねをしました」という新たな通知文言となって届く,というような要件を満足したい時はそこそこ複雑な実装が求められることとなるでしょう.
こういう場合は追記するだけでは機能を実装できないので,過去の通知を舐めて,同種の通知をまとめて1つの新しい通知エントリにした後に不要なエントリを除去するというような実装になりそうですが,そうすると保持する通知件数に齟齬が生じる (例えば,フィードは10件の通知項目を保持しておいてほしいのにもかかわらず,その10件が同種の通知であった場合は1件にまとめられてしまい,通知画面が寂しくなる) 可能性があり,もう少しひねった実装にする必要がありそうです.なんらか工夫をする必要がありそうですね.大変だ.


という感じでまだまだアプリ内通知の設計・実装についての悩みは尽きないわけですが,ひとまず現状のステータスを更新したという次第です.今後も頑張ります.
なお,自分個人としての思いは「OSに通知機能があるなら,自前実装せずにそれに乗っかったほうが良い」というものです.しかしそうも言ってはおれん時もある.人生のようです.よろしくお願いします.

builderscon tokyo 2017に参加してきた

builderscon.io

参加してきました.
見た中で印象に残ったトークについて感想を少し.

詳細な内容を何も書けないんですがはちゃめちゃに面白かった

ブラウザ拡張のクロスブラウザ対応についての話.いろいろな便利ツールを自作して利用していて格好良かった.とにかくクロスブラウザ対応は大変そうという印象 (特にedge).なんとかなってほしい……

複雑なUIを持つブラウザアプリケーションをどう設計・実装するかという話.毎度のことながら実例や実コードを交えてわかりやすく説明していてよかった.Validation周りのアーキテクチャについてはあまり触れられていない分野だと思っていて,そこに言及されていたのは大変参考になった.
最後に言っていた「いくらきれいな設計に見えても,チーム内で合意が取れていない設計は間違えた設計」は本当に至言だと思う.

分割QRコードは完全に初耳で,その存在を知れただけでも収穫だった.大きなQRコードだと破損確率が上がるから,それを分割して1QRコードあたりの情報量を下げることで破損確率を下げるというのは考えられているな〜と思った.便利.

CIに時間がかかってしまうと開発のテンポが悪くなり結果的にスピードが落ちる.とにかくCIが遅いとつらい.そこで大量の並列数でゴリゴリぶん回して高速化を図るというのは合理的な考え方だと思った.そうした開発の足周りについてしっかりR&D的な活動をしているのは素晴らしい.

ファブレスな環境でキーボードを大量生産するという話.去年のbuildersconではcho45さんがキーボード製作のテクニカルな話で登壇されていたけれど,このセッションはどちらかと言うと製品製造の話で,製品設計や工場選定,部品選定,QAに至るまでのフルスタックなプロセスについて話されていて,とてつもなく濃密なセッションだった.有象無象の工場がどんどん違法行為を働いている様もうっすら明かされており迫力があった.普通にこういうコンサルタントで金を取れそう.しかしファブレスで製品を作るのはとにかく大変そうだ……

PHPの話かと思いきやHHVMの話だった.かつてPHP5で関数 (風) プログラミングスタイルで書かれていたSlackのサーバサイドソフトウェアをHHVMに徐々に移行して,今となってはHHVM + hacklangでPHPコンポーネントの全てが書かれているというのはなかなか先鋭的で面白かった.
「なぜHHVMを使っているのか」という質問に対して「SlackにはHHVMのコントリビュータがいて,知見を持っている人がたくさんいたから」と回答していて,技術選択のポリシーが確立されていてとても良いと思った.
ところで本筋とは関係無いんですが「Surprised type conversion」を「びっくり型変換」と通訳の人が翻訳されていて,非常に良い翻訳だと感心しました (本来は「Unexpected type conversion」とかになるはずなので,元の言葉のニュアンスを踏まえた結果なんでしょうが).

雑感

会場の日吉は程よく都心から遠く,カンファレンスに参加しているという感じがして良い.
慶応日吉キャンパスはHUBがあるので便利な一方,しかしついつい酒を飲みすぎてしまい一長一短あると感じている.毎日体調が悪かった.
それはそれとして今回も前回のbuilderscon同様様々な分野の話を聞けて良かった.次回も参加したい.

YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました

表題のとおりです.話しました.
これは僕が普段の開発中にエラーメッセージと触れあう時に気にしていたり,考えていることを上手いこと言語化したいという試みから始まったものです.

speakerdeck.com

発表中にdan kogaiさんから「『間違えたことを言っているエラーメッセージ』も悪いエラーメッセージじゃないのか」というフィードバックを頂いて,確かに!! と思いました.すっかり抜けていました.おっしゃる通りです.

発表後頂いた質問としては「(セキュリティ的な観点から) エンドユーザ (非開発者) に詳細なエラーメッセージを表示しては駄目な場合とかがあると思うんだけど,そこらへんどうしてるのか」というものがあったんですが,回答としましては:

  • 技術的に詳細なエラーメッセージはエンドユーザに提供しない
    • エラーが出ている場合,エンドユーザに技術的詳細を提供しても基本的に対処不可能 (多くの場合サーバのエラーなので)
    • 非技術的な方法で対処できる場合はその手順をエラーメッセージとして示す (e.g. 「ネットワーク状態の良いところで試してください」)
    • 仮に「エンドユーザの操作・手順がおかしいからエラーが出ている」という場合があったとしても,それはアプリケーション側のバグ (ユースケースを想定してない,あるいは限定しきれていない) ということなので,「ユーザに正しい使い方を提示する」といったエラーメッセージは (基本的に) 提示しない
    • Tracking IDみたいなものを併記すると問い合わせとかに使えて良さそう
  • 何らかの統一的なエラーに統一する,みたいな手法もある
    • 「アプリケーションがおかしいので後でやり直してみてください」みたいなのに全部のエラーを隠蔽するとか……
    • これに関しては賛否あると思いますが
  • 技術的詳細が書かれた「解決」の為のエラーメッセージは開発者向けには出す

という感じでした.このへんは発表時間の都合上,省略してしまったので情報が薄くなってしまいました.反省しています.

あと「moznionを呼ぶボタン」はどういう実装になってるのかという質問もあったんですが,あれはボタンを押すとikachanが発火して僕にチャットでメンションが飛ぶという素朴な仕組みになっています.


今回のスライドに書かれていることは個人の思想が強いので,他にも様々な意見等あることと思います.エラーメッセージに関してはもっと色々な考えや,トピックや,思想があると思うんですがあまり表立ったものが無い気がするので,色々議論したい感じがしています.しましょう!