javaSpotBugsプラグインの実装方法には公式ドキュメントがありますが、SpotBugsプラグインをSonarQube上で実行するための手法はまだ固まっていません。HelperのSonarQubeプラグインのリリースに動いているので、要点をまとめておきます。SonarQubeプラグイン実装の基本まずSonarQubeの公式ドキュメントに目を通しておきます。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>を入れる。v3.5は初めてSpotBugsを導入したバージョンなのでこれ以降のバージョンを指定するのが良い。SpotBugsプラグインが何らかのライブラリに依存している場合、普通のパッケージとshadedパッケージと両方を用意すると良い。shadedはAntユーザやCLIユーザなど推移的依存が自動的に解決されない場合(プラグイン手配置が必要な場合)に便利。shadedだけ用意すると、推移的依存が自動的に解決される場合に同じライブラリを複数回ダウンロードするリスクや、dependencyReducedPomによって依存先のメタデータが隠匿されてしまう(例えばライセンス管理がやりにくくなる)問題も生じる。rule.xmlを生成するSonarQubeはfindbugs.xmlやmessages.xmlを読まないので、SonarQubeが読める形式でルールに関するデータを提供する必要があります。私はこれをMavenプラグインで自動生成しています。ルールによってタグを変える必要がある大型プロジェクトじゃない限り、これで十分だと思います。コードを書く基本的にはPlugin.javaとRulesDefinision.javaの2つで足ります。GitHub注意点は以下の通りです:Context#createRepository()の第一引数は"findbugs"である必要がある。それ以外の値だと、sonar-findbugsが検知してくれない。Bugが登録されないので、SpotBugsプラグインが解析に使われても結果一覧に出てこなくなる。Centralに公開した上で、SonarSourceコミュニティのフォーラムで申請すれば通るようです。Springに参加してきました。昨年に引き続き、SpotBugsに関する内容です。20名ちょっとのエンジニアに参加いただき、3.1系実装で苦労しているところ、Java9対応が進まない理由などを話しました。Togetterはこちら。Statisticsからもわかっていたことですが、まだFindBugsユーザのほうが多いですね。Java8移行を使っているならSpotBugsの方が安定&高速なので、ぜひ移行を検討いただきたいです。できていると好評のマイグレーションガイドもあります。documentation聴講したものの中では、アンカンファレンスが面白かったです。参加したのですが、様々な立場の方がご自身の経験と考えをもとに意見を交換するのは参加していて楽しく感じます。いう議論をもっと日頃からできると良いですね。自分は参加しませんでしたが、海外登壇経験者のパネルディスカッションも面白かったようです。自分は海外在住なのにあまり参加経験がないので、そのうち行ってみたいところ。SpringにてSpotBugsの話をします。3.1.xの現状と内部実装が抱える問題」、20分枠のセッションとなります。追記タイムテーブルが公開されました。午前11:25〜11:45にLブースでお待ちしています。仕事これ↓読んで、自分の経験をまとめようと思ったのでメモ。www.yutorism.jpチームビルディング、ないし組織・オフィスの改善のためにやってきたことはけっこうある。反面、できていないこともかなりある。董事長と話してやったのがこれ。CS専攻の人を集めたのだし、ポテンシャルある人ばかりなので、彼らが互いに刺激を与え合える機会を作ろうという狙いだった。当時は20名弱だったので、全員にスライドを使って企画意図を説明したのを覚えている。最初は発表者が2,3名に偏ったり、開催時間が固まらなかったり(最初は朝開催を目指したが、結果的には夕方開催に落ち着いた)、発表が数週間連続でなかったりという問題も多かった。結局は、私が異動でいなかった時期(1年間)も含めて6年間続けられている。継続するのが一番難しいので、これは普通に素晴らしいことだと思っている。継続のコツは、やはりイベント自体を楽しいものだと思ってもらうこと、他の人を巻き込んで協力を得ることだと思う。魅力を理解してくれた数名が引き継いでくれたからこそ私が不在でもイベントが回ったし、今は自分が聞き込みや勧誘をしなくても社内交流促進の専門家が代わりに調べてくださっている。最近の私はたまに発表するだけという立場。私が立ち上げ人ということを、新人は認識していないはず。問題共有イベント最近は拠点規模が大きくなって、拠点全体で何が起こっているのかを把握するのが難しくなってきた。異なるチームで似たような問題をバラバラに解いているような状況も散見されるようになってきた。問題解決こそが仕事なのにこの状況は好ましくないだろうということで、従来人事評価時にやってきた成果発表とは別に、プロセスと問題とを拠点内で共有するイベントを立ち上げた。怒らないことを強調しないだけで、前述のイベントとほとんど同じ。部署の壁を超えて数百人巻き込むので、コストが大きいことを個人的には気にしている。毎回アンケートで発表者と聴衆の両方から実際役に立ったのかフィードバックを得ているが、いまのところコストを成果が上回っている認識。今後も成果の評価と改善検討を続けていくつもり。AMAイベントこれについては自分の上長が事業部で実践していたものをパクって上海に持っていっただけ。questionを部長らが匿名(実名付記も可)で集めて一括で答える。文書化されてないルールや、歴史的経緯でそうなっているもの、(中国の)普通の会社でやっているのにやっていないこと(あるいはその逆)とかに関する質問が色々集まる。推測や疑問を検証できる機会を公式に作るだけで、教育やモチベートの切欠を作ることができる。問題回収と整理は非同期でできるので、複数人を一同に集めることもなく開催コストもそんなに高くない。Anythingと呼んでいる。技術交流用WeChatグループWeChatでグループを作り、社員と元社員とでFOSSについて話す場としている。はてブと同じノリでURLをポンポン投稿する感じ。任意参加なので尖った技術者が集まりやすい。RustとかTaigaとかConduitとかはここでキャッチしている情報もある。新人には、興味を感じる分野を探す一助になっていればいいなと思っている。MBO-Sこれに関しては普通に目標管理の教科書を参考にやっている。変わったこともたいしてやってないはず。FooBarとか)ことで、メンバー間交流が促進され挑戦・工夫がしやすい状態になるよう心がけている。自分のMBO-Sフォーマットは社内SNSで公開し、壁に貼って誰でも閲覧できるようにしている。1on1これも初めて6年になる。時間を自由に使って良いことを前提として、聞きたいことリストをこちらから提示(情熱的に働けているか、やりたいことの妨げになっているのは何か、上長に期待しているのは何か、直近の全社集会について質問はあるか等)1on1を受けてこちらがやることを、最後の時間でコミット本当は2みたいな質問の提示は誘導に繋がるのでやらないほうが良いと思っているが、何も持ってこない人が散見されるので補助線として用意している。MANAGEMENTあたり。Feedbackという図式はわかりやすく応用がきく気がしている。できていないこと、継続できなかったことライトニングトークイベント前述の社内勉強会の一環として、30分ずっとLTするようなイベントを考えたことがある。結果、3〜5分という短い時間で話し切ることに慣れさせることができずに終わってしまった。これが定着しない理由は明確で、私自身に成功体験がないから。どこかでちゃんと運営された読書会に参加して、感覚を身に着けたい。今は本を一緒に読む代わりに、おすすめの記事や本を社内SNS等で発信している。今のところはCI/CDやMSAについて語る機会が多いので以下だが、随時アップデートしている。DocsAWS-CloudDesignPattern休祝日のチームビルディングイベントこれは日本で開発合宿経験済みではあるのだが、自分が子持ちということやその他の事情から積極的にやる予定がない。上海の部下はともかく、日本の部下とはかなりやりにくいという事情もある。やる気と関心がある部下に、提案から丸投げている状態。社外の人を巻き込んだ勉強会これは1回だけやったことがあるが、会場と参加者の定期確保に失敗した。そもそも上海で定期的に勉強会を開催しているのがWiredcraftくらいなものなので、潜在市場はありそう。深センほどではないとしても、上海にはGoogleもMicrosoftもeBayもチームラボもサイボウズも色々居るはずなので、ちゃんとツテを作って運用したい。現地日本人コミュニティに顔を出しつつ、上海のMeetup.comで定期的に参加できる勉強会を探していくつもり。GitBookほそぼそと続けているMaven3の入門書「Maven3のはじめかた」ですが、最近はprh入れたり、リポジトリの適当すぎた説明を修正したりといった微修正を行っています。www.gitbook.comで、意外にも年間2万人のユニークユーザがついたようです。以下が2016年12月〜2017年12月のデータです。ChatWork、Teratail、Yahoo!の社内サイトと思しきものがリファラにありました。Maven用語の説明に活用されたようです。今は正直プラグイン実装手法の説明が厚く用語解説が貧弱なので、用語解説系をもうちょっと強化したほうが良さそう。インドやベトナム、ロシアの検索サイトと思われるものもありました。現地で働いている日本人が使っているのでしょうか。Analyticsを入れたので、次回は検索キーワードあたりも調べられるでしょう。国別に見ると日本、米国、シンガポール、オランダ、中国の順です。米国とシンガポールには日本人技術者多い印象でしたが、オランダが入ってくるとは意外でした。ユニークユーザ数は低いのでヘビーユーザがいらっしゃるのかもしれません。この本は今後も継続してメンテしていきます。コードは全てGitHubで公開されていますので、内容へのフィードバックやPRもお待ちしています。travis-ci今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。Wrapperを使うと良いでしょう。CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。オプションを忘れないようにします。このオプションによってMavenはインタラクティブなログを抑制するようになり、ログサイズが激減します。CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。3.3.1SonarCloudによるコード解析FOSSならSonarCloudを使えば無料で解析できます。CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xmlをよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。GitHubなおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。Nexusへのデプロイこれを取り入れるかどうかは意見が別れるところだと思います。Nexusのパスワードをリポジトリにコミットする必要があるのです。Pluginを使うようにしています。SpotBugsのような共同リポジトリの場合、リリース難度を下げ属人性をなくすために使用しています。settings.xmlを暗号化してリポジトリにコミットし、それをデプロイ時に使うだけです。以下のPRが参考になると思います。GitHubGPGのkeyringは以下のようにコマンドで出力できます。リリースの属人性をなくすため、リリース手順書も合わせてコミットしておくと良いでしょう。settings.xmlのテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。Contributorに対するリマインドGitHubはPRやIssueにテンプレートを作成することができます。Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。チェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。個人的には以下のブログで紹介されているProbotに期待しています。大きな問題が無ければ、これが最後のRC版となる予定です。CI整備、Bot管理、パフォーマンス改善、JUnit用test-harness作成、Gradleプラグインの統合テスト作成、などなど色々やらせてもらいました。昨年FindBugsがforkされてからの10ヶ月間で数多くの変更と修正を入れてきましたが、どうにかJava9リリースのタイミングに合わせる形でSpotBugsの安定版をリリースできそうです。BCELメンテナ各位に御礼申し上げます。このバージョンにはMANIFEST.MFに記載されたClass-Pathが間違っているという既知の問題がありますが、MavenやGradle、AntなどのビルドツールあるいはEclipseによってFindBugs/SpotBugsを使っている場合には問題になりません。日頃の趣味開発ないし業務開発で使っていただいて、イシュートラッカーにフィードバックをお願いします。jarコマンドあるいはSpotBugsが提供するスクリプトを利用されている方は、こちらに記載のMANIFEST.MFでjarファイル内のものを置き換えてください。私は今後も個人的にSpotBugs開発に携わっていく予定です。BCEL自体がスレッドアンセーフらしく一筋縄ではいかないようですが、マルチスレッド化を進めていきたいと考えています。今後ともよろしくお願いします。