オープンソースカンファレンス2019 Tokyo/Fall で発表した 明日から始めるGitLabCIはじめの一歩 https://www.ospn.jp/osc2019-fall/modules/eguide/event.php?eid=60 の資料です。
Findbugsはみなさんご存知の通り、クラスやJARファイルを解析して潜在的な問題を探し出してくれる静的解析ツールです。 今のプロジェクトではこのFindbugsを2つのタイミングで実施しています。 EclipseにFindbugs Pluginをインストールし、ビルドと同時にFindbugsを実行 CIのタイミングでMavenでFindbugsを実行 基本的には開発者は前者だけを意識して、後者は開発リーダなんかがプロジェクトの全体状況を把握しているのに使用しています。 ここでEclipseとMaven2の2箇所でFindbugsを実行しているわけですが、この2箇所で同様の設定(同じFindbugsのルールセット)で実行されるようにしておく必要あります。この設定の方法が色々めんどくさい。というかEclipseのFindbugsがあまりいけていない。 Maven2とEclipseのFind
最近の更新 (Recent Changes)2014-03-13blancoDb 2014-02-14blancoMailAuth Blanco1g 2012-11-26blancoLogC 2012-09-06nlpack 2012-09-05blancofw 最新リリース情報blanco2g (blanco2g-0.6.0)2013-01-09 13:11blancoAnt (blancoAnt-0.1.8)2009-08-16 21:49blancoAntDistribution (blancoAntDistribution-0.0.2)2008-11-24 21:05blancoAntTask (blancoAntTask)2012-05-28 21:08blancoBatchProcess (blancoBatchProcess-0.6.1)2009-08-09 23:16bla
警告を抑止する方法 Eclipse3.1以降でよく警告が出るようになった。 javacコマンドで直接コンパイルするとデフォルトではその手の警告は出ないが、javacのオプションで-Xlintを付けてコンパイルすると これらの警告が出るようになる。 コンパイルオプションによる抑止 アノテーションによる抑止 [/2010-01-09] @SafeVarargs [/2017-09-23] Eclipseの設定による抑止 [/2008-10-25] コンパイルオプションによる抑止 javacのオプションの-Xlintによって警告を抑止できる。(JDK1.5以降) 全ての警告を出す例: > javac -Xlint Test.java > javac -Xlint:all Test.java 全く警告を出さない例: > javac Test.java > javac -Xlint:none Tes
未使用のコードを検出したいと考えたことは無いだろうか。 Androidアプリケーションの配布サイズはそのパッケージ(.apk)に含まれるクラスとリソース(特に画像)に関連があるので、パッケージングする際にできるだけコードサイズはスリムにしておく必要がある。 現在開発中のライブラリィはJFC/Swing時代から使っているコードを多く含んでいるので、かなり無駄なコードがありそうなのだ。 UCDetector UCDetector: Unnecessary Code Detector UCDetector | freshmeat.net (コードリポジトリ) UCDetectorはその名の通り、"Unecessary Code Detector"であり不要なコードを検出してくれる有り難いツールだ。 使い方は簡単。対象のプロジエクトから「UCDetector」→「Detsxt unnecessar
アノテーションプロセシングツール(APT)のまとめとして、テンプレートメソッドパターンの具象クラスを自動生成するアノテーションプロセッサについて書いておこうと思う。 テンプレートメソッドパターンとは? いわずとしれたオブジェクト指向実装設計における、継承関係を利用した抽象->具象実装を利用した汎用的なデザインパターン。※オブジェクト指向設計を学ぶにあたり最も理解しやすいパターンの一つなので、GoF本で紹介される以前から最もメジャーに使用されてきたパターンだ。 Template Method パターン - Wikipedia 抽象クラスを用意する 別に具象クラスでも良いのだが、テンプレートとなるルートクラスはインスタンス化しない抽象クラスで用意することが多い。 今回は対象プラットホームをAndroidとし、サーバからHTTPレスポンスとして取得したストリームからXMLをパースする、XlmPu
Java6で導入されたPluggable Annotation Processor APIとそれを利用するためのAnnotation Processing Tool(以降APT)はJava5の頃よりも格段にその開発が簡略化されているが、通常のコードと違いコンパイル時に動作するため、デバッグの方法は無い(と思っていた)。 EclipseのJDTはaptをサポートしており、コードのビルド時にaptをプラグインして実行出来るが、実はaptのデバッグもできる。 以下、その手順。 1. ブレークポイントを設定する 自らが実装したAnnotation Processorのメソッドにブレークポイントを設定する。通常Annotation Processorを実装する場合はprocessメソッドをオーバライドすることが殆どなので、このメソッドをつかうのが良いだろう。 2. Eclipseワークベンチをデバッ
前エントリで言及したようにAndroidアプリケーションはその内部に「別プロセスで実行する = android:process」を明示した場合はプロセスを分離することができるが、Eclipseで分離したプロセスをデバッグするにはどうすればよいのだろう。 通常Eclipse ADTのデバッグセッションはAndroidのマニフェストに従って生成されたアプリケーションのプロセスにアタッチした状態で開始されるが、この状態でデバッグできるコードは元々のアプリケーション-プロセスに属したコードだけであり、分離したプロセスで実行されている部分はデバッグセッションでは見えないのでデバッグできない。(当然である) では一度分離されてしまったプロセスはデバッグできないのだろうか? 否。 デバッグセッションを開始後、DDMSパースペクティブのDeviceビューを見ると実行されているプロセスの一覧が表示されており
_ コード補完時代にAPIはどうあるべきか? さて(承前)、実は問題は、LogLogのメソッドシグネチャにある。少なくともおれは、そう考える。 おれは常識人だし、みなさんも良識の持ち主だ。 こういう人たちは、以下のようなメソッドをオーバーロードするときに、どう定義するだろうか? エラー用のログ出力メソッド。当然、ログファイルに出力するメッセージは引数に必要。 でも、例外くらった場合は、例外オブジェクトを引数に付けてくれればメッセージとかスタックトレースとかもログするよ。そのほうがいいよね。 それは、もう、こうするだろう。 interface Log { public void error(String msg); public void error(String msg, Throwable t); } なぜならば、Throwable tはあるかないかわからない、つまりはオプションだからだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く