先週末に開催されたJJUG CCC 2018 Springに参加してきました。昨年に引き続き、SpotBugsに関する内容です。
20名ちょっとのエンジニアに参加いただき、3.1系実装で苦労しているところ、Java9対応が進まない理由などを話しました。Togetterはこちら。
Maven Central Statisticsからもわかっていたことですが、まだFindBugsユーザのほうが多いですね。Java8移行を使っているならSpotBugsの方が安定＆高速なので、ぜひ移行を検討いただきたいです。よくできていると好評のマイグレーションガイドもあります。
聴講したものの中では、アンカンファレンスが面白かったです。初めて参加したのですが、様々な立場の方がご自身の経験と考えをもとに意見を交換するのは参加していて楽しく感じます。こういう議論をもっと日頃からできると良いですね。また自分は参加しませんでしたが、海外登壇経験者のパネルディスカッションも面白かったようです。自分は海外在住なのにあまり参加経験がないので、そのうち行ってみたいところ。
月末に開催されるJJUG CCC 2018 SpringにてSpotBugsの話をします。タイトルは「SpotBugs 3.1.xの現状と内部実装が抱える問題」、20分枠のセッションとなります。
タイムテーブルが公開されました。午前11:25〜11:45にLブースでお待ちしています。
これ↓読んで、自分の経験をまとめようと思ったのでメモ。
チームビルディング、ないし組織・オフィスの改善のためにやってきたことはけっこうある。反面、できていないこともかなりある。
上海拠点設立時に董事長と話してやったのがこれ。せっかくCS専攻の人を集めたのだし、ポテンシャルある人ばかりなので、彼らが互いに刺激を与え合える機会を作ろうという狙いだった。当時は20名弱だったので、全員にスライドを使って企画意図を説明したのを覚えている。
最初は発表者が2,3名に偏ったり、開催時間が固まらなかったり（最初は朝開催を目指したが、結果的には夕方開催に落ち着いた）、発表が数週間連続でなかったりという問題も多かった。しかし結局は、私が異動でいなかった時期（1年間）も含めて6年間続けられている。継続するのが一番難しいので、これは普通に素晴らしいことだと思っている。
継続のコツは、やはりイベント自体を楽しいものだと思ってもらうこと、他の人を巻き込んで協力を得ることだと思う。魅力を理解してくれた数名が引き継いでくれたからこそ私が不在でもイベントが回ったし、今は自分が聞き込みや勧誘をしなくても社内交流促進の専門家が代わりに調べてくださっている。ので、最近の私はたまに発表するだけという立場。たぶん私が立ち上げ人ということを、新人は認識していないはず。
最近は拠点規模が大きくなって、拠点全体で何が起こっているのかを把握するのが難しくなってきた。また異なるチームで似たような問題をバラバラに解いているような状況も散見されるようになってきた。問題解決こそが仕事なのにこの状況は好ましくないだろうということで、従来人事評価時にやってきた成果発表とは別に、プロセスと問題とを拠点内で共有するイベントを立ち上げた。怒らないことを強調しないだけで、前述のイベントとほとんど同じ。
部署の壁を超えて数百人巻き込むので、コストが大きいことを個人的には気にしている。ので毎回アンケートで発表者と聴衆の両方から実際役に立ったのかフィードバックを得ているが、いまのところコストを成果が上回っている認識。今後も成果の評価と改善検討を続けていくつもり。
これについては自分の上長が事業部で実践していたものをパクって上海に持っていっただけ。主に新人が持っているであろう疑問や、いわゆるhard questionを部長らが匿名（実名付記も可）で集めて一括で答える。文書化されてないルールや、歴史的経緯でそうなっているもの、（中国の）普通の会社でやっているのにやっていないこと（あるいはその逆）とかに関する質問が色々集まる。推測や疑問を検証できる機会を公式に作るだけで、教育やモチベートの切欠を作ることができる。問題回収と整理は非同期でできるので、複数人を一同に集めることもなく開催コストもそんなに高くない。
最初はQuestion Gathering Eventと呼んでいたが、最近AMAという言葉が身近で流行したので、今はAMAあるいはAsk Us Anythingと呼んでいる。
WeChatでグループを作り、社員と元社員とでFOSSについて話す場としている。はてブと同じノリでURLをポンポン投稿する感じ。任意参加なので尖った技術者が集まりやすい。RustとかTaigaとかConduitとかはここでキャッチしている情報もある。新人には、興味を感じる分野を探す一助になっていればいいなと思っている。
これに関しては普通に目標管理の教科書を参考にやっている。変わったこともたいしてやってないはず。上長としては部の短期・中期目標（どのProblem Spaceにフォーカスするか）を明確に提示し、それぞれに固有名詞を付ける（Project FooBarとか）ことで、メンバー間交流が促進され挑戦・工夫がしやすい状態になるよう心がけている。自分のMBO-Sフォーマットは社内SNSで公開し、壁に貼って誰でも閲覧できるようにしている。
これも初めて6年になる。運用上工夫しているのは3点：
本当は2みたいな質問の提示は誘導に繋がるのでやらないほうが良いと思っているが、何も持ってこない人が散見されるので補助線として用意している。
参考にしている本は複数あるが、最近読んだのはフィードバック入門、マネジャーの最も大切な仕事、HIGH OUTPUT MANAGEMENTあたり。特にフィードバック入門のTeaching + Coaching = Feedbackという図式はわかりやすく応用がきく気がしている。
前述の社内勉強会の一環として、30分ずっとLTするようなイベントを考えたことがある。結果、3〜5分という短い時間で話し切ることに慣れさせることができずに終わってしまった。会社を一歩出ればLTの機会がたくさんある東京と違って、勉強会が少ない上海ならではの問題かもしれない。
これが定着しない理由は明確で、私自身に成功体験がないから。どこかでちゃんと運営された読書会に参加して、感覚を身に着けたい。
今は本を一緒に読む代わりに、おすすめの記事や本を社内SNS等で発信している。今のところはCI/CDやMSAについて語る機会が多いので以下だが、随時アップデートしている。
これは日本で開発合宿経験済みではあるのだが、自分が子持ちということやその他の事情から積極的にやる予定がない。上海の部下はともかく、日本の部下とはかなりやりにくいという事情もある。やる気と関心がある部下に、提案から丸投げている状態。
これは1回だけやったことがあるが、会場と参加者の定期確保に失敗した。そもそも上海で定期的に勉強会を開催しているのがWiredcraftくらいなものなので、潜在市場はありそう。深センほどではないとしても、上海にはGoogleもMicrosoftもeBayもチームラボもサイボウズも色々居るはずなので、ちゃんとツテを作って運用したい。
とりあえず現地日本人コミュニティに顔を出しつつ、上海のMeetup.comで定期的に参加できる勉強会を探していくつもり。
ほそぼそと続けているMaven3の入門書「Maven3のはじめかた」ですが、最近はprh入れたり、リポジトリの適当すぎた説明を修正したりといった微修正を行っています。
で、意外にも年間2万人のユニークユーザがついたようです。以下が2016年12月〜2017年12月のデータです。
どこからそんなユーザが流入したのか気になるところですが、KDDI ChatWork、Teratail、Yahoo!の社内サイトと思しきものがリファラにありました。どうやらMaven用語の説明に活用されたようです。今は正直プラグイン実装手法の説明が厚く用語解説が貧弱なので、用語解説系をもうちょっと強化したほうが良さそう。
検索サイトはGoogle, Yahoo, Bing, 楽天の順。インドやベトナム、ロシアの検索サイトと思われるものもありました。現地で働いている日本人が使っているのでしょうか。今日Google Analyticsを入れたので、次回は検索キーワードあたりも調べられるでしょう。
国別に見ると日本、米国、シンガポール、オランダ、中国の順です。米国とシンガポールには日本人技術者多い印象でしたが、オランダが入ってくるとは意外でした。ただユニークユーザ数は低いのでヘビーユーザがいらっしゃるのかもしれません。
この本は今後も継続してメンテしていきます。コードは全てGitHubで公開されていますので、内容へのフィードバックやPRもお待ちしています。
今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。
Travis CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。
もっと新しいバージョンを使う、あるいはMavenのバージョンを固定するには、Maven Wrapperを使うと良いでしょう。Travis CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。
script や install、deploy などのフェーズで mvn コマンドを明示的に実行する場合、 -B オプションを忘れないようにします。このオプションによってMavenはインタラクティブなログを抑制するようになり、ログサイズが激減します。Travis CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。
グローバルにコマンドラインパラメータを指定する場合、それがローカルでの実行時にも必要となるパラメータならば、Maven 3.3から導入された .mvn/maven.config あるいは .mvn/jvm.config を使うことも可能です。ただし現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。
FOSSならSonarCloudを使えば無料で解析できます。Travis CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xmlをよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。
なおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。
これを取り入れるかどうかは意見が別れるところだと思います。というのもこれをやるには、暗号化済みとは言えGPG署名に必要なファイルやSonatype Nexusのパスワードをリポジトリにコミットする必要があるのです。
私の場合、個人プロダクトでは使わずに Maven Release Pluginを使うようにしています。ただしSpotBugsのような共同リポジトリの場合、リリース難度を下げ属人性をなくすために使用しています。
作業内容は単純に、GPG public keyring, GPG secret keyring そしてGPG passphaseとSonatype Nexusアカウント情報を含んだ settings.xmlを暗号化してリポジトリにコミットし、それをデプロイ時に使うだけです。以下のPRが参考になると思います。
GPGのkeyringは以下のようにコマンドで出力できます。
$ gpg --export $KEY_ID > .travis/pubring.gpg $ gpg --export-secret-key $KEY_ID > .travis/secring.gpg
またリリースの属人性をなくすため、リリース手順書も合わせてコミットしておくと良いでしょう。settings.xmlのテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。
GitHubはPRやIssueにテンプレートを作成することができます。またContributing Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。
ただチェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。ので、個人的には以下のブログで紹介されているProbotに期待しています。
先日SpotBugsの最新版となる3.1.0 RC6が出ました。大きな問題が無ければ、これが最後のRC版となる予定です。
SpotBugs開発において、私は新マニュアルサイト整備、CHANGELOG整備、Ant廃止、Gradleスクリプト整備、Travis CI整備、Bot管理、パフォーマンス改善、JUnit用test-harness作成、Gradleプラグインの統合テスト作成、などなど色々やらせてもらいました。昨年FindBugsがforkされてからの10ヶ月間で数多くの変更と修正を入れてきましたが、どうにかJava9リリースのタイミングに合わせる形でSpotBugsの安定版をリリースできそうです。
助けていただいた各位、特にドキュメントの日本語訳にコントリビュートしてくださっているKannoさんと、SpotBugsチームの要請に応えてv6.1を出してくださったApache BCELメンテナ各位に御礼申し上げます。
このバージョンにはMANIFEST.MFに記載されたClass-Pathが間違っているという既知の問題がありますが、MavenやGradle、AntなどのビルドツールあるいはEclipseによってFindBugs/SpotBugsを使っている場合には問題になりません。ぜひ日頃の趣味開発ないし業務開発で使っていただいて、イシュートラッカーにフィードバックをお願いします。
なおjarコマンドあるいはSpotBugsが提供するスクリプトを利用されている方は、こちらに記載のMANIFEST.MFでjarファイル内のものを置き換えてください。
なお私は今後も個人的にSpotBugs開発に携わっていく予定です。BCEL自体がスレッドアンセーフらしく一筋縄ではいかないようですが、マルチスレッド化を進めていきたいと考えています。今後ともよろしくお願いします。
このエントリは「Announcing SpotBugs as FindBugs successor」の意訳です。一部、明らかなURLの誤りを修正し、可読性のため強調を施しています。
皆さんこんにちは、
このメールはこのメーリングリストにおける私の最後の投稿であり、また昨年のこちらの投稿の続きです。
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html
TL;DR: FindBugsプロジェクトはプロジェクトリードが管理者権限を移管しないままプロジェクトを離れ、また1年以上応答がなくなったため停止しました。SpotBugsプロジェクトがその後継であり、バージョン3.1.0 RC5を既にリリースしています。ASM6の安定バージョンがリリースされしだい、SpotBugsの3.1.0 RC6そして3.1.0安定バージョンがリリースされる予定です*1。
私が前述のメールを書いてから数名の有志がプロジェクトに参加して、私たちがプロジェクトが生き残るチャンスをものにできるよう助けてくれました。FindBugsという名称は商標であることから他の名称を使う必要が生じたため、新しいプロジェクトはSpotBugsと名付けられました。コードも新しいリポジトリに移され、ホームページ，メーリングリスト，バグトラッカーなどもGitHub上に用意されました。
私たちはASM 6のリリースを待ってSpotBugsの3.1.0 RC6と3.1.0 finalバージョンをリリースします、これは今月中に実現する見込みです。
SpotBugs 3.1.0 RC6がリリースされたら（このバージョンは最後のRC版になるでしょう）、私たちはコマンドライン，Antタスク，Mavenプラグイン，Gradleプラグイン，Eclipseプラグインそして新しいマニュアルを提供します。
FindBugs 3.0.1からの変更点はこちらに一覧化されています：
https://github.com/spotbugs/spotbugs/releases
注目すべき変更点は以下のとおりです（私が何かを忘れていたらすみません）：
我々はすべてのFindBugsユーザが大きな問題なくSpotBugsを使えるよう望んでいます。マニュアルのマイグレーションガイドを見てください。我々はまた皆さんがテストやバグ報告や貢献を通じてSpotBugsプロジェクトを支援してくれることを期待しています。実際のところ、コミュニティの助けがなければ開発を続けることはできません。
もちろん上述のメーリングリストやイシュートラッカーの購読も忘れないでください。
私*4はまたSpotBugsを助けてくれたすべての人々に感謝の言葉を伝えたいです。GitHubの貢献者一覧を見てください。
特にJuan Martín Sotuyo DoderoとKengo TODA*5。彼ら二人がいなければ今日のSpotBugsプロジェクトは存在しなかったでしょう。二人ともありがとう！
これがこのメーリングリストでの最後の言葉です：私はこのようなことが起こるとは想像していなかったし、このようなことを言うことは非常に悲しいのですが……さようならFindBugs！あなたは10年間に渡り、何百万人もの開発者を助けてくれました。Bill、David、こんなに素晴らしいツールをありがとう。こんなアナウンスをしてしまって申し訳ないけど、ショーは続かなければならないんだ。
はじめまして、SpotBugs!
