https://dev.to/kengotoda にて英語での情報発信をはじめました。宜しければそちらもご購読を。
SpotBugsプラグインを元にしたSonarQubeプラグインを実装する方法
SpotBugsプラグインの実装方法には公式ドキュメントがありますが、SpotBugsプラグインをSonarQube上で実行するための手法はまだ固まっていません。最近Guava Migration HelperのSonarQubeプラグインのリリースに動いているので、要点をまとめておきます。
SonarQubeプラグイン実装の基本
まずSonarQubeの公式ドキュメントに目を通しておきます。特にMarketplaceでの公開を前提としている場合は、Plugin Keyの命名に制約があったり、SonarCloudの利用が必須だったりしますので、制約についてよく読んでおくと良いでしょう。
Mavenプロジェクトを作る
Gradleサポートは公式ではないので、Mavenを選択します。SpotBugsプラグインと同じプロジェクトで管理すると、メタデータ作成(後述)で手間がかからないのでおすすめです。私のプロダクトではSpotBugsプラグインとSonarQubeプラグインとをサブモジュールとして管理するプロジェクトを使っています。注意点は以下の通りです:
- SonarQubeプラグインは
<packaging>sonar-plugin</packaging>
にする。 sonar-packaging-maven-plugin
の設定に<basePlugin>findbugs</basePlugin>
と<requirePlugins>findbugs:3.5</requirePlugins>
を入れる。sonar-findbugs v3.5は初めてSpotBugsを導入したバージョンなのでこれ以降のバージョンを指定するのが良い。- SpotBugsプラグインが何らかのライブラリに依存している場合、普通のパッケージとshadedパッケージと両方を用意すると良い。 shadedはAntユーザやCLIユーザなど推移的依存が自動的に解決されない場合(プラグイン手配置が必要な場合)に便利。 shadedだけ用意すると、推移的依存が自動的に解決される場合に同じライブラリを複数回ダウンロードするリスクや、dependencyReducedPomによって依存先のメタデータが隠匿されてしまう(例えばライセンス管理がやりにくくなる)問題も生じる。
rule.xmlを生成する
SonarQubeはfindbugs.xmlやmessages.xmlを読まないので、SonarQubeが読める形式でルールに関するデータを提供する必要があります。私はこれをMavenプラグインで自動生成しています。ルールによってタグを変える必要がある大型プロジェクトじゃない限り、これで十分だと思います。
コードを書く
基本的にはPlugin.javaとRulesDefinision.javaの2つで足ります。以下がサンプル:
- guava-helper-for-java-8/SonarQubePlugin.java at v1.0.4 · KengoTODA/guava-helper-for-java-8 · GitHub
- guava-helper-for-java-8/SonarQubeRulesDefinition.java at v1.0.4 · KengoTODA/guava-helper-for-java-8 · GitHub
注意点は以下の通りです:
Context#createRepository()
の第一引数は"findbugs"
である必要がある。 それ以外の値だと、sonar-findbugsが検知してくれない。 その結果findbugs-include.xml
にBugが登録されないので、SpotBugsプラグインが解析に使われても結果一覧に出てこなくなる。
リリースする
あとはいつもどおりMaven Centralに公開した上で、SonarSourceコミュニティのフォーラムで申請すれば通るようです。私のプラグインはまだ申請中です:
JJUG CCC 2018 SpringでSpotBugs3.1系実装について話してきました
先週末に開催されたJJUG CCC 2018 Springに参加してきました。昨年に引き続き、SpotBugsに関する内容です。
20名ちょっとのエンジニアに参加いただき、3.1系実装で苦労しているところ、Java9対応が進まない理由などを話しました。Togetterはこちら。
Maven Central Statisticsからもわかっていたことですが、まだFindBugsユーザのほうが多いですね。Java8移行を使っているならSpotBugsの方が安定&高速なので、ぜひ移行を検討いただきたいです。よくできていると好評のマイグレーションガイドもあります。
聴講したものの中では、アンカンファレンスが面白かったです。初めて参加したのですが、様々な立場の方がご自身の経験と考えをもとに意見を交換するのは参加していて楽しく感じます。こういう議論をもっと日頃からできると良いですね。また自分は参加しませんでしたが、海外登壇経験者のパネルディスカッションも面白かったようです。自分は海外在住なのにあまり参加経験がないので、そのうち行ってみたいところ。
JJUG CCC 2018 SpringにてSpotBugsの話をします
月末に開催されるJJUG CCC 2018 SpringにてSpotBugsの話をします。タイトルは「SpotBugs 3.1.xの現状と内部実装が抱える問題」、20分枠のセッションとなります。
追記
タイムテーブルが公開されました。午前11:25〜11:45にLブースでお待ちしています。
チームビルディングのためにやったこと、できていないこと
これ↓読んで、自分の経験をまとめようと思ったのでメモ。
チームビルディング、ないし組織・オフィスの改善のためにやってきたことはけっこうある。反面、できていないこともかなりある。
やったこと、継続していること
社内技術勉強会
上海拠点設立時に董事長と話してやったのがこれ。せっかくCS専攻の人を集めたのだし、ポテンシャルある人ばかりなので、彼らが互いに刺激を与え合える機会を作ろうという狙いだった。当時は20名弱だったので、全員にスライドを使って企画意図を説明したのを覚えている。
最初は発表者が2,3名に偏ったり、開催時間が固まらなかったり(最初は朝開催を目指したが、結果的には夕方開催に落ち着いた)、発表が数週間連続でなかったりという問題も多かった。しかし結局は、私が異動でいなかった時期(1年間)も含めて6年間続けられている。継続するのが一番難しいので、これは普通に素晴らしいことだと思っている。
継続のコツは、やはりイベント自体を楽しいものだと思ってもらうこと、他の人を巻き込んで協力を得ることだと思う。魅力を理解してくれた数名が引き継いでくれたからこそ私が不在でもイベントが回ったし、今は自分が聞き込みや勧誘をしなくても社内交流促進の専門家が代わりに調べてくださっている。ので、最近の私はたまに発表するだけという立場。たぶん私が立ち上げ人ということを、新人は認識していないはず。
問題共有イベント
最近は拠点規模が大きくなって、拠点全体で何が起こっているのかを把握するのが難しくなってきた。また異なるチームで似たような問題をバラバラに解いているような状況も散見されるようになってきた。問題解決こそが仕事なのにこの状況は好ましくないだろうということで、従来人事評価時にやってきた成果発表とは別に、プロセスと問題とを拠点内で共有するイベントを立ち上げた。怒らないことを強調しないだけで、前述のイベントとほとんど同じ。
部署の壁を超えて数百人巻き込むので、コストが大きいことを個人的には気にしている。ので毎回アンケートで発表者と聴衆の両方から実際役に立ったのかフィードバックを得ているが、いまのところコストを成果が上回っている認識。今後も成果の評価と改善検討を続けていくつもり。
AMAイベント
これについては自分の上長が事業部で実践していたものをパクって上海に持っていっただけ。主に新人が持っているであろう疑問や、いわゆるhard questionを部長らが匿名(実名付記も可)で集めて一括で答える。文書化されてないルールや、歴史的経緯でそうなっているもの、(中国の)普通の会社でやっているのにやっていないこと(あるいはその逆)とかに関する質問が色々集まる。推測や疑問を検証できる機会を公式に作るだけで、教育やモチベートの切欠を作ることができる。問題回収と整理は非同期でできるので、複数人を一同に集めることもなく開催コストもそんなに高くない。
最初はQuestion Gathering Eventと呼んでいたが、最近AMAという言葉が身近で流行したので、今はAMAあるいはAsk Us Anythingと呼んでいる。
技術交流用WeChatグループ
WeChatでグループを作り、社員と元社員とでFOSSについて話す場としている。はてブと同じノリでURLをポンポン投稿する感じ。任意参加なので尖った技術者が集まりやすい。RustとかTaigaとかConduitとかはここでキャッチしている情報もある。新人には、興味を感じる分野を探す一助になっていればいいなと思っている。
MBO-S
これに関しては普通に目標管理の教科書を参考にやっている。変わったこともたいしてやってないはず。上長としては部の短期・中期目標(どのProblem Spaceにフォーカスするか)を明確に提示し、それぞれに固有名詞を付ける(Project FooBarとか)ことで、メンバー間交流が促進され挑戦・工夫がしやすい状態になるよう心がけている。自分のMBO-Sフォーマットは社内SNSで公開し、壁に貼って誰でも閲覧できるようにしている。
1on1
これも初めて6年になる。運用上工夫しているのは3点:
- 直接の部下(課長?)とは週次、間接的な部下とは月次で実施
- 時間を自由に使って良いことを前提として、聞きたいことリストをこちらから提示(情熱的に働けているか、やりたいことの妨げになっているのは何か、上長に期待しているのは何か、直近の全社集会について質問はあるか等)
- 1on1を受けてこちらがやることを、最後の時間でコミット
本当は2みたいな質問の提示は誘導に繋がるのでやらないほうが良いと思っているが、何も持ってこない人が散見されるので補助線として用意している。
参考にしている本は複数あるが、最近読んだのはフィードバック入門、マネジャーの最も大切な仕事、HIGH OUTPUT MANAGEMENTあたり。特にフィードバック入門のTeaching + Coaching = Feedbackという図式はわかりやすく応用がきく気がしている。
できていないこと、継続できなかったこと
ライトニングトークイベント
前述の社内勉強会の一環として、30分ずっとLTするようなイベントを考えたことがある。結果、3〜5分という短い時間で話し切ることに慣れさせることができずに終わってしまった。会社を一歩出ればLTの機会がたくさんある東京と違って、勉強会が少ない上海ならではの問題かもしれない。
輪読会、読書会
これが定着しない理由は明確で、私自身に成功体験がないから。どこかでちゃんと運営された読書会に参加して、感覚を身に着けたい。
今は本を一緒に読む代わりに、おすすめの記事や本を社内SNS等で発信している。今のところはCI/CDやMSAについて語る機会が多いので以下だが、随時アップデートしている。
- The Way of the Web Tester: A Beginner's Guide to Automating Tests by Jonathan Rasmusson | The Pragmatic Bookshelf
- Google - Site Reliability Engineering
- Reactive Microservices Architecture: free O'Reilly report by Lightbend CTO Jonas Bonér | @lightbend
- "Reactive Microsystems - The Evolution Of Microservices At Scale": Free O'Reilly Report By Jonas Bonér | @lightbend
- Getting Started with Microservices, Part 1: Advantages and Considerations | Oracle Developers Blog
- Infrastructure as Code: A Reason to Smile | ThoughtWorks
- Home | Scrum Guides
- Cloud Design Patterns | Microsoft Docs
- AWS-CloudDesignPattern
休祝日のチームビルディングイベント
これは日本で開発合宿経験済みではあるのだが、自分が子持ちということやその他の事情から積極的にやる予定がない。上海の部下はともかく、日本の部下とはかなりやりにくいという事情もある。やる気と関心がある部下に、提案から丸投げている状態。
社外の人を巻き込んだ勉強会
これは1回だけやったことがあるが、会場と参加者の定期確保に失敗した。そもそも上海で定期的に勉強会を開催しているのがWiredcraftくらいなものなので、潜在市場はありそう。深センほどではないとしても、上海にはGoogleもMicrosoftもeBayもチームラボもサイボウズも色々居るはずなので、ちゃんとツテを作って運用したい。
とりあえず現地日本人コミュニティに顔を出しつつ、上海のMeetup.comで定期的に参加できる勉強会を探していくつもり。
Maven3電子書籍の利用され具合(2017年)
ほそぼそと続けているMaven3の入門書「Maven3のはじめかた」ですが、最近はprh入れたり、リポジトリの適当すぎた説明を修正したりといった微修正を行っています。
で、意外にも年間2万人のユニークユーザがついたようです。以下が2016年12月〜2017年12月のデータです。
どこからそんなユーザが流入したのか気になるところですが、KDDI ChatWork、Teratail、Yahoo!の社内サイトと思しきものがリファラにありました。どうやらMaven用語の説明に活用されたようです。今は正直プラグイン実装手法の説明が厚く用語解説が貧弱なので、用語解説系をもうちょっと強化したほうが良さそう。
検索サイトはGoogle, Yahoo, Bing, 楽天の順。インドやベトナム、ロシアの検索サイトと思われるものもありました。現地で働いている日本人が使っているのでしょうか。今日Google Analyticsを入れたので、次回は検索キーワードあたりも調べられるでしょう。
国別に見ると日本、米国、シンガポール、オランダ、中国の順です。米国とシンガポールには日本人技術者多い印象でしたが、オランダが入ってくるとは意外でした。ただユニークユーザ数は低いのでヘビーユーザがいらっしゃるのかもしれません。
この本は今後も継続してメンテしていきます。コードは全てGitHubで公開されていますので、内容へのフィードバックやPRもお待ちしています。
Mavenプロジェクト用Travis CI設定(2017年末)
今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。
Mavenのバージョンを固定する
Travis CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。
もっと新しいバージョンを使う、あるいはMavenのバージョンを固定するには、Maven Wrapperを使うと良いでしょう。Travis CIはプロジェクトルートディレクトリにmvnw
スクリプトがある場合はそれを優先的に使います。
mvnコマンド指定時の注意点
script
や install
、deploy
などのフェーズで mvn
コマンドを明示的に実行する場合、 -B
オプションを忘れないようにします。このオプションによってMavenはインタラクティブなログを抑制するようになり、ログサイズが激減します。Travis CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。
グローバルにコマンドラインパラメータを指定する方法
グローバルにコマンドラインパラメータを指定する場合、それがローカルでの実行時にも必要となるパラメータならば、Maven 3.3から導入された .mvn/maven.config
あるいは .mvn/jvm.config
を使うことも可能です。ただし現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。
SonarCloudによるコード解析
FOSSならSonarCloudを使えば無料で解析できます。Travis CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xml
をよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。
なおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。
Travis CIによるSonatype Nexusへのデプロイ
これを取り入れるかどうかは意見が別れるところだと思います。というのもこれをやるには、暗号化済みとは言え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
のテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。
Contributorに対するリマインド
GitHubはPRやIssueにテンプレートを作成することができます。またContributing Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。
ただチェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。ので、個人的には以下のブログで紹介されているProbotに期待しています。