自作Mavenプラグインにヘルプを付けよう
Maven 使ってチーム開発していると、ビルドプロセスで独自の処理が必要になって、プラグインを自作する機会がちょいちょいあります。
ただ、自作したプラグインって、ちょっと使っていないと使い方を忘れることがよくあります。公開されているプラグインだったら、サイトを見に行けばいいんですけど、自作の場合は面倒なので準備しないことが多い。
サイトがなくてもコマンドで確認することはできて、例えば、tomcat プラグインだったらこんな感じ。
$ mvn tomcat:help [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'tomcat'. [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Default Project [INFO] task-segment: [tomcat:help] (aggregator-style) [INFO] ------------------------------------------------------------------------ [INFO] [tomcat:help {execution: default-cli}] [INFO] org.codehaus.mojo:tomcat-maven-plugin:1.1 Tomcat Maven Plugin The Tomcat Maven Plugin provides goals to manipulate WAR projects within the Tomcat servlet container. This plugin has 19 goals: tomcat:deploy Deploy a WAR to Tomcat. tomcat:deploy-only Deploy a WAR to Tomcat witjout forking the package lifecycle tomcat:exploded Deploy an exploded WAR to Tomcat. …
でも、これって自作プラグインだと有効になってない場合が多い。
mvn help:describe -Dplugin=プラグイン名 とか長いコマンド打てば自作プラグインでも見れたりするんですけど、このコマンドを覚えるのが面倒。
じゃあ、どうすればいいかと言うと、HelpMojo を作りましょう。ただ、HelpMojo を自分で実装するのはバカバカしいですね（help:describe で見れるのに）。そこで、便利なプラグインがちゃんとあります。
それは Maven Plugin Plugin ！
使い方は超簡単。自作プラグインの pom.xml にプラグインを追加するだけ。
http://maven.apache.org/plugins/maven-plugin-plugin/examples/generate-help.html
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<version>2.9</version>
<executions>
<execution>
<id>generated-helpmojo</id>
<goals>
<goal>helpmojo</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
...
</build>
...
</project>
これで、使い方をわからなくなっても、mvn プラグイン名:help で使い方を簡単に確認することができますね。
Javaの暴走スレッドを見つける
簡単な方法がJava Obsessionというブログで紹介されていました。
Figure out why is JAVA eating CPU?
psコマンドで、CPU使用率が高いスレッドを見つけて、jstack(もしくは kill コマンド)でスタックトレースを見つけましょうという話です。
大変わかりやすく説明してくれているのですが、若干手作業が多いので、勢いで bash スクリプトを書いてみました。
CPU使用率が95%以上のスレッドのスタックトレースを出力するスクリプトです。CPU使用率の閾値を変更したい場合は ./java-cpu-monitor.sh 99.9 のようにパラメータで渡せます。
watch コマンドと tee コマンドを組み合わせると便利ですかね？
５秒置きに cpu.log に出力する場合は
watch -n 5 './java-cpu-monitor.sh | tee -a cpu.log'
でよいかと思われます。
テキトーなスクリプトなので、好きに使ってください。バグがあったら教えてくれると助かります。自分でも perl や python で書けって思いましたが、スクリプト言語からコマンドを呼び出すのに抵抗があって。。
Clean Coder 読んだ
気分転換に Clean Coder を一気に読んだ。プロのプログラマの心構え的な本。会社に損害を与えたら自分で賠償するとか過激な意見もいくつかあるけど、役に立つ考え方がいろいろ書いてあった。
Clean Coder |
まぁでも、TDDはユニットテストができる範囲でしか有効じゃないし、今回も心を動かされなかった。。要するに単一責任原則とかDDDで設計を複雑にしないってことが重要なんだと理解している。
きつい不具合はたいていコンポーネントを接続する部分にある気がするし、モックは、モック自体が正しい動きしていることを保証できないと積極的に使う気にならないんだよな。そんなことより API レベルや画面レベルで、高レイヤのテストを頑張った方が現実的な気がしてる。
「試してみる」の合意は、「コミットメント」と同じか。
これは気をつけないと。
暗黙的なコミットメントはしちゃいけない。
３点見積もりとかは使ったことないけど、自分の思い込みよりかは正確な数値な出せる気がする。
チームはプロジェクトよりも作るのが難しいっていう意見はなるほど。プロジェクトドリブンでチームを編成するんじゃなくて、チームドリブンでプロジェクトを割り当てた方が効率的か。新しい人と一緒に仕事した方が、自分とは違う視点を学ぶことができて楽しい部分もあるけどね。
本物のプロにはまだまだ遠いな。
デブサミ2012でkintoneの裏側を紹介したけど・・
デブサミ2012で @yo_waka （ブログ）と一緒に kintone の紹介してきました。
来て頂いたみなさんありがとうございました。
他にもセッションがある中、多くの方に来て頂いて大変うれしかったです。
View more presentations from yo_waka
少しでもお役に立てれば幸いです。と言いたいところですが、
裏側のスライドがばっさりなくなってしまいました（＞＜）
ごめんなさい、代わりに一般論を少しだけ。
今の時代なら、スキーマレスなデータを扱うにはMongoDBのようなNoSQLも選択肢として結構ありなんですが、２、３年前だと、NoSQLが認知され始めたところで、利用するにはリスクを負う覚悟が必要だったかと思います。
そんな中で、RDBMSでスキーマレスなデータを扱う手法は様々なところでチャレンジされていました。 ありえるCTOの井上さんが、大変分かりやすくまとめています
今だと、選択肢は本当にいろいろあるのですが、選ぶポイントはいくつかあって、
- スキーマを定義する人は誰か（開発者？、アプリ利用者？）
- スキーマの変更の頻度
- スキーマの数、データの数
- スキーマ間の関連性の有無
- データの変更はリアルタイムに反映されるか
- 検索、整列、集約に制限があるか
- 検索性能、更新性能
- 一貫性、可用性、スケーラビリティのどれを重視するか
- 価格、サポート
ここら辺を考慮しながら、プロダクトにあったデータベースを選択することになるかと思います。
現在の kintone は、スキーマを定義するのがアプリ利用者で、スキーマは頻繁に更新されるが、データ数はそこまで膨大にはならず、データの変更はリアルタイムに反映して欲しいといった特徴があり、friendfeed 的なアプローチでデータを管理しています。
とは言っても、スキーマレスなデータを扱うやり方はこれからもたくさん出てくるだろうし、新しい技術に柔軟に対応できるよう精進していきたいと思っています。
大人数の前で話すのは苦手（＞＜）ですけど、発表する機会を頂いて良かったです。
これからも kintone の開発をがんばります。
