Hatena::Groupdann

dann's blog このページをアンテナに追加 RSSフィード

Fork me on GitHub

2013-02-25

ChefでMacを開発マシンとしてセットアップ

ChefでMacを開発マシンとしてセットアップ - dann's blog を含むブックマーク はてなブックマーク - ChefでMacを開発マシンとしてセットアップ - dann's blog ChefでMacを開発マシンとしてセットアップ - dann's blog のブックマークコメント

boxen, pivotal worktationなど最近Macを開発環境として自動でセットアップするためのツールが幾つかでてきています。

このような実装を幾つか見てみましたが、各会社用に特化しているので個人では少し使いづらいため、chefの既存のレシピを使って個人用の環境をセットアップできるようにしてみました。dotfilesと同じで、個人用の開発環境のセットアップ方法をバージョン管理しながら、少しずつ育てていこうかなと思ってます。

https://github.com/dann/chef-macbox

Mac用に使うChefのレシピとしては、hombrew, mac_os_x, dmgのレシピを使っています。

これらのレシピを使って、次のことをやっています。

  • 必要なアプリをdmgでインストール
  • homebrewレシピで必要なパッケージでインストール
  • mac_os_xレシピでMacの設定を変更
  • dotfilesをgithubから取得してセットアップ

設定そのものは完全に個人に依存しているので、他の人が使えるように作ってはいませんが、少し手をいれれば、汎用の開発者用としても使えます。

macbookがリニューアルされるとつい買ってしまったりと、個人でもMacはセットアップする回数が多いと思うので、Chefで個人用開発環境を育ててみると良いんじゃないかと思います。

Happy hacking!

コメント

2013-02-12

Plack::Middleware::Profiler::KYTProfでプロファイリング

Plack::Middleware::Profiler::KYTProfでプロファイリング - dann's blog を含むブックマーク はてなブックマーク - Plack::Middleware::Profiler::KYTProfでプロファイリング - dann's blog Plack::Middleware::Profiler::KYTProfでプロファイリング - dann's blog のブックマークコメント

Devel::KYTProfでプロファイリングするのも、ミドルウェアになっていると使いやすいかもしれないということで作ってみました。

https://github.com/dann/p5-plack-middleware-profiler-kytprof

What is KYTProf?

onishiさんのDevel::KYTProfは、ネットワークI/O系やDBアクセスなどの、いわゆる重い処理に対してモンキーパッチをあてて、性能を測るということをするモジュールです。I/O系にフォーカスしているところが用途が明確でいいですね。Perl界隈でよく使われるモジュールに対してモンキーパッチをあてているので、useするだけで空気を読んで性能を測ってくれます。LLらしい面白いアプローチのモジュールです。

Plack::Middleware::Profiler::KYTProfの使いどころ

Ganglia, CloudForecast, Zabbixなどのリソースモニタリングツールを使うことで、I/O系の問題があることはすぐにわかります。しかし、I/Oの問題であることがわかっても、アプリケーションのどの箇所でおきているかを特定するのは、アプリの作りにも依存するところで、コードの理解無くして特定することは難しいこともあります。

そういった場合に、このミドルゥエアを使うことになります。使うことで、コードの変更すること無く、SQL、テンプレート、エンドポイントへの通信などを特定することが可能になります。

基本的な性能問題の8-9割は、I/O絡みで発生することが殆どなので、その点で実用的といえるかもしれません。

使い方

基本的な使い方は、以下の通りです。ウェブアプリ用のミドルということで、Template Engineもプロファイリング対象に加えています。

builder {                                                                                                                              
    enable "Plack::Middleware::Profiler::KYTProf";                                                                                     
    $app; 
};

負荷テスト環境や独自のアプリでも使えるようにするために、サンプリングしたいケースや、何をプロファイリング対象にしたいかなどを切り替えられるようにもしてあります。examplesにサンプルをいれてあるので、使ってみてください。

Enjoy!

＃NYTProfのようなマイクロチューニングをするためのモジュールは、使う人が＊モジュールの作者など）かなり限定的になるかなとは思うんですが、こういったI/O系は性能のオーダーはまるで違うので、使いどころは結構ありそうです。

コメント

2013-02-11

Plack::Middleware::Profiler::NYTProfでプロファイリング

Plack::Middleware::Profiler::NYTProfでプロファイリング - dann's blog を含むブックマーク はてなブックマーク - Plack::Middleware::Profiler::NYTProfでプロファイリング - dann's blog Plack::Middleware::Profiler::NYTProfでプロファイリング - dann's blog のブックマークコメント

PlackアプリをプロファイリングするモジュールPlack::Middleware::Profiler::NYTProfを更新しました。

https://github.com/dann/p5-plack-middleware-profiler-nytprof

bayashiさんにパッチをもらって、負荷テスト環境などでも使えるようになりました。ある一定の負荷がかかった環境でしか性能問題がおきないといったケースはよくあるので、負荷テスト環境で、少し負荷をかけた状態で詳細なプロファイリングをしたい場合などに使ってみてください。

プロファリングのオーバーヘッドと負荷を減らすために、サンプリング、プロファイリング対象の限定、レポート機能のoffの3点の機能を追加しています。

サンプリング

全部のプロセスに負荷をかけるのではなく、対象をenable_profileというcallbackで、条件によってプロファイリングを有効にすることができます。特定のプロセスや何回かに1回プロファイリングするなどでサンプリングしながら、プロファイリングするのがおすすめです。

プロファイリング対象の限定

NYTProfは、PerlのVMをhookして測定しているので、オーバーヘッドが他のプロファイラより小さくなっています。

ただ、それでもプロファイリングするレベルがstatementレベルなどと小さいとオーバーヘッドは大きくなってしまいます。

そこで、以下のDevel::NYTProfの文書に書いてあるように、プロダクション環境ではプロファイル対象を限定するのがおすすめです。

http://search.cpan.org/~timb/Devel-NYTProf/lib/Devel/NYTProf.pm#MAKING_NYTPROF_FASTER

これは、env_nytprofにblocks=0, slowops=0などを追加することで実現します。


HTMLレポートの出力をしない

これは単純に元々が開発環境用を目的に作られた機能なので、デフォルトがオンになっているのをオフにできる機能を用意したというだけのことです。負荷テスト環境では、HTMLレポートをそのまま生成するのではなく、NYTProfのプロファイリング結果だけを出力して、後でみられるようにすればよく、HTMLレポートはoffにしておかないといけません。

これは、enable_reporting optionを0に設定することで実現します。

設定のサンプル

まとめると、例えば以下のような設定で使います。

use Mojolicious::Lite;
use Plack::Builder;

get '/' => 'index';

builder {
  enable "Profiler::NYTProf",
    env_nytprof          => 'start=no:addpid=0:blocks=0:slowops=0:file=/tmp/nytprof.out',
    profiling_result_dir => sub { '/tmp' },
    enable_reporting     => 0,
    enable_profile       => sub { $$ % 2 == 0 }
    ;
 
  app->start;
};

__DATA__

@@ index.html.ep
<html><body>Hello World</body></html>

Enjoy!

＃元々は開発環境で使うことを想定して、Plack Hackathon（http://dann.g.hatena.ne.jp/dann/20091129/p1）で3年前につくったものですが、こうしてまた使われるというのも嬉しいものです。bayashiさん、ありがとうございました！

コメント

2012-04-04

dann20120404

Devel::Cover::Report::VimででC0なカバレッジのコードを vim で表示

Devel::Cover::Report::VimででC0なカバレッジのコードを vim で表示 - dann's blog を含むブックマーク はてなブックマーク - Devel::Cover::Report::VimででC0なカバレッジのコードを vim で表示 - dann's blog Devel::Cover::Report::VimででC0なカバレッジのコードを vim で表示 - dann's blog のブックマークコメント

secondlifeさんのsimplecov-vimのエントリ見ていいなと思ってたんですが、perlでもDevel::Coverのreportとして実装されてました！

http://subtech.g.hatena.ne.jp/secondlife/20120312/1331528672

cover -report vim

でreport(cover_db/coverage.vim)を生成してから、vimで

:so cover_db/coverage.vim

を実行すると、以下のようにC0なコードがvim上で表示できます。エディタ上で気軽にカバレッジがみれるのはいいですね。

f:id:dann:20120405021203j:image

coverage.vimをみた感じだと、ちょっとした修正で、rubyやperlに限らず色々と応用できそうなので、今後他の言語でも使っていきたいところです。

コメント

2012-01-26

Software Engineerにお勧めの技術書

Software Engineerにお勧めの技術書 - dann's blog を含むブックマーク はてなブックマーク - Software Engineerにお勧めの技術書 - dann's blog Software Engineerにお勧めの技術書 - dann's blog のブックマークコメント

人に聞かれることも増えてきた昨今ですが、お勧めする本は毎年そう変わりはしないのでまとめてみました。言語に依存する本は、書き出すと多くなってしまうので除いてます。

コンピュータサイエンス関連のおすすめ本

Computer Architecture

大規模なシステムを組む場合、高い性能を要求される場合、省リソースが求められるケースなどは、特に低レイヤへの理解の必要性を実感することになります。

下のレイヤを深く理解しておかなければ、このようなシステムのアーキテクチャデザインやトラブルシューティングは実質できません。

/高性能コンピュータ技術の基礎

    • 最新のプロセッサのアーキテクチャがどのようになっているのかを丁寧に解説しており、最近のプロセッサの全体像を把握するのに役立ちます。
OS/Linux Kernel
Algorithm/Data Structure

設計関連のおすすめ本

Software Architecture

と合わせて読みたい。Architectureという分類に入れるべきかは微妙なところもありますが...

Software Architectureを考える上で、Computer ArchitectureやArchitecture Patternだけではないというのは、企業で物作りをしている方は感じることがあると思います。以下の本は、Software Architectureをどのような視点で評価するのかということに対して、大局観を与えてくれるものです。

Design Pattern

GoFのパターン本以外にも読んでおくべきパターン本はあり、特にConcurrencyに関連する以下の本はおすすめです。

/ 増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

/ Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

Testabilityの高いDesignをするための本

Robert C MartinシリーズとMartin Fowlerシリーズを読んでおくのがおすすめです。

, 実装パターン

OOA/D
Developer Testing
System Design (Scalability)

Scalabilityという切り口でまとめるのがよいか微妙なところもありますが、Web系システムのScalabilityに関しては、

以下の本がおすすめです。

Webシステムのデザインであれば、上記の本を読むのでも十分得られることはあると思います。

この分野は類書は数多くありますが、幾つか上記の本を読んだら、分散システム, OS, Database関連の本やHPCの分野の論文などを良く読んだほうがよいです。

DB Design

データベースは、システム開発をする上では避けて通ることのできない分野です。DBはOSとStorageに強く依存しているため、DBのArchitectureだけでなく、ストレージ/OSのアーキテクチャも良く理解しておく必要があります。

データモデリングは、OOA/D と同じくかなり癖のある分野で、これがベストであるといいきれる本はないのですが、以下の本は総じておすすめではないかと思います。ある程度読んだら、キーとなるドメインの知識獲得のほうを大事にしたほうがよいです。

/達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

      • セルコさんのSQL本。ミックさんの本も系統は似ていて、DBアーキテクチャというよりも、「SQL」を学ぶための本。Webシステム系の人というよりも業務よりの人の方が向いているかもしれません。
  • その他
    • データベース・リファクタリング
      • 若干粒度が細かいといえば細かいのですが、類書はなく一回読んでおいて損はないです。DBエンジニアの人にとっては当たり前なことも多いかもしれないんですが、AP開発者の人がDB設計を改善する際には役に立つと思います。
System Administration

以下の本は、純粋な運用に関する話ではなく、死活監視、測定、配備といった最近のDevOpsに求められる分野を網羅的にまとめている良書です。DevOpsの人だけでなく、AP開発者の人もAPを作る上で運用が可能なアプリケーションとはどのようなものなのかを意識するのにも役立つのではないかと思います。運用も含めた全体のシステムデザインが、昨今の大規模なクラスタではとても重要です。特に、クラウドインフラが増えていき少数のエンジニアがその上でアプリケーションを開発するようになっていく時代には、AP開発者であってもインフラの基礎知識を持っておくことが今後より重要になっていくでしょう。

Software Engineering系のおすすめ本

Agile

Agileの本は色々でていますが、基本的にはMike CohnとJames O. Coplienの本を読んでおけば大体間違いないです。

僕の場合は、Scrumをベースにした開発プロセスで大体のプロジェクトは進めています。

人間系
  • ワインバーグの本一式。
    • 人への深い洞察は、今読んでも得られるものが多いです。デマルコの本などもよいですが、ワインバーグシリーズが個人的には好きです。

# Amazonへのリンクが欲しいというコメントがありましたので、リンクを追加しておきました。和書が出ているものは、和書のほうにリンクを張りました。

コメント

2012-01-07

Test::Perl::Metrics::Liteでコードの”死活”監視

Test::Perl::Metrics::Liteでコードの”死活”監視 - dann's blog を含むブックマーク はてなブックマーク - Test::Perl::Metrics::Liteでコードの”死活”監視 - dann's blog Test::Perl::Metrics::Liteでコードの”死活”監視 - dann's blog のブックマークコメント

複数人で開発していて、コードベースが管理できないくらいに複雑化してしまうというケース、誰もが1回は経験したことがあるのではないかと思います。それを防ぐために、問題のあるコードに対してアラートをあげるのをテストで行うためのモジュールが、Test::Perl::Metrics::Liteです。拙作のPerl::Metrics::Liteを用いたテスト用のモジュールです。　

コードの問題の早期発見に関しては、メトリクスの可視化という手段が有効に機能します。色々な例外ケースを考えると、一律の閾値を設定することは難しいため、閾値によってエラーにするのではなく、可視化のみにするというのは割とよくある運用方法の一つです。これは、Gangliaなどでのシステム状態のモニタリングと似ています。このような用途では、先に紹介したPerl::Metrics::LiteによるJenkins+CheckStyleとの統合がおすすめです。

一方、どうしても認められない限界の許容値というのを設定することで、アラートをあげるという使い方もメトリクスにはあります。多様なレベルの開発者が参加する際には重要です。このような場合は、閾値は若干緩めに設定し、どうしても超えてはいけないラインを設定することで、コードが管理不能にならないようにコードベースを死守するために使います。概念としては、Nagiosなどを使った死活監視の概念と似ています。100行を超えるようなメソッドがコミットされる状況を監視するというのは、コードの死活監視といっても過言ではないからです。

Test::Perl::Metrics::Liteは後者のコードの死活監視を行うためのモジュールで、JenkinsなどのCIシステムとして統合して使うことを想定しています。

使い方ですが、以下のようなテストファイルを作り、これをCIで継続的に実行します。

ex) code_metrics.t

use Test::Perl::Metrics::Lite (-mccabe_complexity => 20, -loc => 100);
BEGIN {                                                                                                                                
    all_metrics_ok();                                                                                                                  
}

上記の例は、コメント抜きの実行数が100行を超えていて、mccable complexityが20以上という条件で多数の分岐のある複雑なメソッドが引っかかることになります。この条件だと、そう簡単に手をつけられる状態ではなく、そのコードはほぼ死にかかっているといっても過言ではありません。このようなケースは、ビルドレベルでエラーにするというポリシーをとっておかないと、後々プロジェクトが崩壊してしまうため、テストケースという形で継続的にビルドするのに向いています。

まとめ

技術的負債を抱え込まないようにするために、メトリクスの可視化だけでなく、メトリクスによるコードの”死活”監視もすると捗るぞ、ということになります。

静的言語では、その言語の性質上このようなツール群はとても充実しているんですが、LL界隈ではあまり充実していないため、少し作ってみました。是非活用していただければ。

コメント

2011-12-23

3分でPerlのプロジェクトをJenkins Readyにする

3分でPerlのプロジェクトをJenkins Readyにする - dann's blog を含むブックマーク はてなブックマーク - 3分でPerlのプロジェクトをJenkins Readyにする - dann's blog 3分でPerlのプロジェクトをJenkins Readyにする - dann's blog のブックマークコメント

こんばんは、着る毛布が届く前に風邪を引いたdannです。

色々な環境やプロジェクトに携わっていて、その度にJenkinsのセットアップやPerlプロジェクト用のモジュールのインストールなどをしていたりしませんか。また、プロジェクトを作るたびに、Job毎にプラグインの設定などを繰り返していたりしませんか？

これらの設定は、完全に自動化することが可能です。Jenkinsのように良く使うツールは、これらのセットアップも自動化していくと捗ります。以下では、その方法を説明します。

以下に、Jenkinsプロジェクトの開始に必要なテンプレートを用意したので、参考にしてみてください。以下では、以下のtemplateを使ったセットアップ方法について説明します。

https://github.com/dann/perl-jenkins-template

Jenkinsのプロジェクトに必要なPluginのセットアップの自動化

Jenkinsでは、GUIだけでなく、jenkins-cliを使うことでCUIでインストールすることができます。

これを使って以下のようなスクリプトで、JenkinsのPluginとJenkinsの統合に必要なPerlのモジュールをインストールします。

これによって、プロジェクトに必要なプラグインやPerlのモジュールは自動でインストールできます。

https://github.com/dann/perl-jenkins-template/blob/master/setup_jenkins_modules.sh

#!/bin/bash

#==================================
# Configuration
#==================================
HOSTNAME=localhost
PORT=8080

#==================================
# Main
#==================================
JENKINS_PLUGINS=(
git
checkstyle
htmlpublisher
clover
plot
)

PERL_MODULES=(
Devel::Cover
Devel::Cover::Report::Clover
Perl::Metrics::Lite
https://github.com/dann/tap-to-junit-xml/tarball/master
)

setup() {
    fetch_jenkins_cli
    install_jenkins_plugins
    install_jenkins_related_perl_modules
    restart_jenkins
    clean_jenkins_cli
}

fetch_jenkins_cli() {
    curl -LO http://${HOSTNAME}:${PORT}/jnlpJars/jenkins-cli.jar
}

jenkins_cli() {
    java -jar jenkins-cli.jar -s http://${HOSTNAME}:${PORT} $@
}

install_jenkins_plugins() {
    for plugin in ${JENKINS_PLUGINS[@]}
    do
        jenkins_cli install-plugin ${plugin}
    done
}

install_jenkins_related_perl_modules() {
    for module in ${PERL_MODULES[@]}
    do
        cpanm $module
    done
}

restart_jenkins() {
   jenkins_cli safe-restart
}

clean_jenkins_cli() {
    rm jenkins-cli.jar
}

setup

Jenkinsのproject-templateを用意しておくと捗るぞ

概要

多くののLLのプロジェクトの場合は、シェルのステップを設定しているか、実行するためのbuild.xmlを用意しておいて、ビルドのステップのセットアップをして使っているかなんじゃないかと思います。こういったプロジェクトのステップの設定やどのプラグインを使うか、プラグインの設定など、そういったプロジェクトの設定を手動でするのって面倒ですよね。

要するに既存Job設定をコピーすることで、既存の設定を使い回せる機能があるので、それを使うということですね。

これによって、Clover用のプラグインでディレクトリでcover_dbのディレクトリを指定したり、Devel CoverのHTMLの結果をHTML Publisherなどでpublishするディレクトリを指定したり、Publish Checkstyle analysis resultsなどの実行するプラグインをチェックしたりといったのを手動ですること無く、自動で設定された状態にすることが可能になります。

Job Templateのインストールの仕方

以下の定義が実際のjobのテンプレートになります。以下に、上記のビルドステップのスクリプトとプロジェクトで必要となるプラグインの設定が有効になるjobテンプレートを用意しておきました。Job定義はXMLでJenkinsのHomeディレクトリ(ex /var/lib/jenkins)以下のjobsディレクトリに保存されているので、既存Jobでよく使う部分はテンプレートのXMLとして定義して保存しておきます。

https://github.com/dann/perl-jenkins-template/blob/master/config.xml

上記のテンプレートを自動インストールするスクリプトは、以下になります。Configセクションの変数を各自の環境にあわせて使ってみてください。

https://github.com/dann/perl-jenkins-template/blob/master/setup_jenkins_job_template.sh

Job Templateの使い方

上記のインストールが終わった後に、新規プロジェクトを作ります。新規プロジェクトを作る場合には、Jenkinsで、New Job -> Copy existing job を選択し、そこで、perl-jenkins-templateを選択することで、jenkins readyなperlプロジェクト用のJobを作ることができます。

Jobテンプレートの適用になり有効になるもの

上記のJob templateをインストールすると、以下のものがデフォルトで有効になります。

  • JUnitとの統合によるテスト実行結果
  • Cloverの統合によるテストカバレッジの可視化
  • Devel::CoverのHTMLレポート
  • Perl::Metrics::LiteによるCheckStyleとの統合

ビルドの結果としては、以下のような形で表示されます。

f:id:dann:20111225002936j:image

このJob Templateによって、プラグインだと次のようにCheckStyle, Clover, JUnitなどのプラグインの設定がされます。

f:id:dann:20111225003308j:image

また、ステップについては、以下のような設定が自動設定されます。

set -ex

#===============================================
# Configuration
#===============================================
export PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:${PATH}"                                                      
export LOG_DIR=$WORKSPACE/logs
export PERL5LIB="$WORKSPACE/lib:$WORKSPACE/t/lib:$WORKSPACE/t/*/lib:${PERL5LIB}"
export PERL_TEST_HARNET_DUMP_TAP=$LOG_DIR
export TEST_VERBOSE=1

#===============================================
# Main
#===============================================
clean() {
    [ -f Makefile ] && make -k realclean
    rm -rf Makefile Makfile.old MANIFEST blib *.tar.gz
    rm -rf $LOG_DIR
    cover -delete
}

setup() {
    perl Makefile.PL
    mkdir -p $LOG_DIR
}
do_test() {
    HARNESS_PERL_SWITCHES=-MDevel::Cover=+ignore,inc prove -lv t 2>&1 | tee -a $LOG_DIR/tests.tap
}

convert_to_junit_xml() {
    tap-to-junit-xml --input=$LOG_DIR/tests.tap --output=$LOG_DIR/tests.xml
}

make_coverage() {
    cover -report clover
    cover
}

measure_metrics() {
    measureperl-checkstyle --max_sub_lines 60 --max_sub_mccabe_complexity 10 --directory lib > checkstyle-result.xml
}

main() {
    clean
    setup
    do_test
    convert_to_junit_xml
    make_coverage
    measure_metrics
}

main

まとめ

まとめると、

  • JenkinsのPluginやプロジェクトに必要なモジュールのインストールを自動化しておくと捗るぞ
  • JenkinsのJobでプロジェクトに共通な設定は、あらかじめJob定義のXMLをテンプレートを用意しておき、Copy existing Jobでコピーすると設定を使い回せて捗るぞ

ということになります。

使うプラグインや設定など、プロジェクトによって異なる点もあると思いますが、このようなベースを用意しておくことで、いわゆる定型作業を減らすことができ、プロジェクト間でのばらつきを抑えることが可能になります。是非、このようなテンプレートをベースにして、各自のプロジェクトに合わせたJenkinsのJobテンプレートを作ってもらえたらなと思います。

これらは、Perlのプロジェクトだけで使える話ではなく、他の言語でも使える話ですので、是非自動化して、プロジェクトレベルでの標準化と自動化を進めてみてください。

Enjoy automating!

Perl::Metrics::LiteのCLIでPerlモジュールのメトリクス測定

Perl::Metrics::LiteのCLIでPerlモジュールのメトリクス測定 - dann's blog を含むブックマーク はてなブックマーク - Perl::Metrics::LiteのCLIでPerlモジュールのメトリクス測定 - dann's blog Perl::Metrics::LiteのCLIでPerlモジュールのメトリクス測定 - dann's blog のブックマークコメント

Perl::Metrics::LiteにCLIを追加しました。FIleとSubroutineのメトリクスを測定できます。簡単にlocやmccableのcomplexityなどを測定できるので、casualに使ってみて頂ければ。

また、Jenkins用に組み込むためのmeasureperl-jenkinsというスクリプトも同梱したので使ってみてください。

CLIでのメトリクス測定

基本的な使い方としてはは、Perlのモジュールの入ったlibディレクトリを指定して使います。

measureperl lib

Metricsの閾値を超えた物だけを表示したい場合は、

measureperl -e lib

として実行します。

閾値のデフォルト値は、slocが60、mccable complexityが10になっています。あまり厳しすぎない程度の値なので、デフォルト値のままで使ってもよいんじゃないかなと思います。

以下は、Perl::Metrics::Liteモジュールの測定結果です。

次のように閾値も変更可能ですので、プロジェクトでの許容範囲にあわせて閾値をっ設定してみてください。

bin/measureperl -e -l 30 -c 6 lib

Jenkinsへの組み込み

CheckStyleに変換するためのReportクラスもあるので、以下のような形でJenkinsには、以下のようにcheckstyleの結果を出力することで統合が可能です。先日のJenkinsへのCheckStyleへの統合を、汎用なツールにしてみました。エラーで引っかかった行数のジャンプもできるようにしてあります ;)

measureperl-checkstyle --max_sub_lines 60 --max_sub_mccabe_complexity 10 --directory lib > checkstyle-result.xml

以下でインストールできるので、試してみてください。

cpanm Perl::Metrics::Lite

Enjoy measuring!

コメント

2011-12-21

Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール - Perl Advent Calendar 2011

Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール - Perl Advent Calendar 2011 - dann's blog を含むブックマーク はてなブックマーク - Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール - Perl Advent Calendar 2011 - dann's blog Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール - Perl Advent Calendar 2011 - dann's blog のブックマークコメント

Perl Advent Calendar Hacker Trackの21日目です。

http://perl-users.jp/articles/advent-calendar/2011/hacker/21

こんばんは。dann です。みなさん、意識は高まっていますか？ 僕は上々です。

今回は拙作の Perl::Metrics::Lite というモジュールを紹介させて頂きます。

開発した動機

Perl::MetricsやPerl::Metrics::Simpleなど、PerlのコードのMetricsを測定するツールがあるのですが、どれも使い勝手の点でいまいちです。

Perl::Metricsは測定項目をプラガブルに追加可能なのですが、APIがプリミティブすぎてMetricsを測定するには使いずらいです。

一方、Perl::Metrics::Simpleは、Perl::MetricsをよりユーザーフレンドリなAPIにして、名前の通りシンプルに使えるように作られているのですが、今度は測定項目が拡張可能になっておらず、特定のメトリックしか測定できませんでした。

Perl::Metrics::Lite - プラガブルなメトリクス測定モジュール

従来のモジュールの問題点を解決するために、Perl::Metrics::SimpleとPerl::Metricsのいいとこどりをして、測定項目をプラガブルに追加できるPerl::Metrics::Simpleのような使い勝手のいいモジュールを作ってみました。

http://github.com/dann/p5-perl-metrics-lite

使い方はPerl::Metrics::Simpleと殆ど同じで、以下のように使います。

use Perl::Metrics::Lite;
my $analzyer   = Perl::Metrics::Lite->new;
my $analysis   = $analzyer->analyze_files(@ARGV);
my $file_stats = $analysis->file_stats;
my $sub_stats = $analysis->sub_stats;

egディレクトリに実行可能な簡単なサンプルをいれてあるので、

是非実行して確認してみてください。

https://github.com/dann/p5-perl-metrics-lite/blob/master/eg/measureperl

測定項目の拡張方法

以下に幾つかFileとSubroutineのMetricsの測定のPluginのサンプルをいれています。

initとmeasureメソッドを実装する必要があります。measureメソッドのfileまたはsubroutineのPPI::Documentを操作して、必要なMetricsの計算を行います。

まとめ

Perl::Metrics::Liteにより、簡単にFileとSubroutineのMetricsを拡張して、測定項目を追加していくことが可能になりました。是非色々なMetricsの測定をしてみてください。

Enjoy measuring!

コメント

2011-12-10

Jenkinsで継続的メトリクス測定のすすめ - Perl Advent Calendar 2011

Jenkinsで継続的メトリクス測定のすすめ - Perl Advent Calendar 2011 - dann's blog を含むブックマーク はてなブックマーク - Jenkinsで継続的メトリクス測定のすすめ - Perl Advent Calendar 2011 - dann's blog Jenkinsで継続的メトリクス測定のすすめ - Perl Advent Calendar 2011 - dann's blog のブックマークコメント

Perl Advent Calendar Test Trackの11日目です

はじめに

こんばんは、家で凍死しそうなので、そろそろセラムヒートでも買おうと思っているdannです

Test Track 11日目です！ ikasam_a さんから「Jenkinsの話を書いて！」と言われたので、ACDD(Advent Calendar Driven Development) という手法で作った、メトリクス測定ツールとJenkinsへのインテグレーションについての話をします。

メトリクスを測定すると捗るぞ

大きなチームで開発する時に、数百行の謎メソッドができたりとかあったりしますよね（涙）

僕は、Working Effectively With Legacy CodeやClean Codeを読んでいること前提にチームの人がコードを書いていると思っていたら、あれ？という場面があったりします。こういうときは、品質の問題を測定できるようにすると、数値レベルで具体的にした共通認識ができ、レビューが捗ります。

今回測定したメトリクス

メトリクスを測定するなんていうと、用語の定義が間違ってる喝！とSoftware Engineeringの専門家に怒られちゃうわけですが、そこは気にせずメトリクスを測定って言うことにします。

今回測定したのは、以下の二つのメトリクスです。

  • メソッドの行数
  • Cyclomatic Complexity

メソッドの行数は、そのまんまですね。Cyclomatic Complexityは10を超えていると複雑すぎなので、分割を検討した方が良いというのが一つ一般的な指標になってます。

これらのメトリクスは、Perl::Metrics::Simpleというモジュールで簡単に取得できます。ではこれをJenkinsに統合しましょう。

Jenkinsでのメトリクス監視の方法

これらのメトリクスの測定結果をどのようにJenkinsに統合するかです。今まで、自分の日記のJenkinsのエントリを読んでもらっている人は、勘のいい方は気づいてるんじゃないかと思うんですが、Javaのツールにマッピングすればいいんですね。

この分野は、静的言語でもあることから、Javaは周辺ツールがとても充実しており、今回はそのうちの一つであるCheckStyleのXMLに測定結果をマッピングしてみました。これにより、チェック結果のViewをそのまま流用できるわけです。

作ってみたマッピングするツール pm-checkstyle は以下の通りです。

https://github.com/dann/p5-app-checkstyle

使い方

上記のスクリプトのconfigurationの設定を最初にします。

CCが10、sub lengthが50行という設定だと、以下のように書きます。

our $MAX_CYCLOMATIC_COMPLEXITY = 10;
our $MAX_SUB_LENGTH            = 50;

以下のようにスクリプトの引数にlibディレクトリを指定します。そうすると、workspaceにcheckstyle-result.xmlが生成されます。

pm-checkstyle lib

後は、Jenkinsにcheckstyle pluginをいれておけば、ビルド時に自動でcheckstyleのViewにメトリクスでの測定結果が表示されます。

check styleでのチェック結果

ビルド結果には次のようにcheck styleでチェックに引っかかった項目がひっかかります

f:id:dann:20111209021107j:image

エラー数はファイル毎に次のようにみることができます

f:id:dann:20111209021106j:image

ファイルをクリックするとエラー詳細は次のように表示されます。

f:id:dann:20111209021105j:image


おまけ

以下のようにPerl::Metrics::Simple::Analysis::Fileを変更することでメソッドの行数を取得することが可能になります。上記のpm-checkstyleでは、line numberは1という固定値になってますが、以下の変更を加えてcheckstyle.plのテンプレートを変更すれば、行数のマッピングも出来ます。そうすることで、check_styleのDetailのレポートから直接ソースコードの該当メソッドにジャンプすることができるようになります。

--- Perl/Metrics/Simple/Analysis/File.pm.orig	2011-12-10 13:49:45.000000000 +0900
+++ Perl/Metrics/Simple/Analysis/File.pm	2011-12-10 13:34:52.000000000 +0900
@@ -327,6 +327,7 @@
             name              => $sub->name,
             lines             => $sub_length,
             mccabe_complexity => $self->measure_complexity($sub),
+            line_number       => $sub->line_number,
             };
     }
     return \@subs;

メトリクス測定の効果

メトリクスの測定をCIに組み込むことの効果には以下のようなものがあります。

  • 継続的にメトリクスをチェックすることができ、問題を早期に発見できる
  • Jenkinsおじさんが自動でチェックしてくれるので、レビューの工数が削減できる
  • 指摘をJenkinsおじさんがしてくれるのでレビュー時に人間関係が悪化しない
  • Jenkinsおじさんに指摘されないように気をつけるため、全員のコードが綺麗になる

まとめ

メトリクスの測定で、レビュー対象を早期に摘出するとコード品質をあげることが可能になります。早期に問題を見つけるのは、テストやビルドだけでなく、こういった静的解析による機械的なレビューによってもあげることが可能なわけです。

これらのメトリクスによる定量評価もCIに組み込むことでその価値を発揮します。性能だけでなく、品質もある一定線は定量評価が可能であり、人感じるのではなく、測定によって定量評価をすすめることで、改善効果を実感することができます。

CheckStyleのチェック項目は数多く存在しますが、Perl::Metrics::SimpleをベースにしてJava版と同じようにモジュール化をすることで、より高度なチェックも可能になります。興味のある方は是非トライしてみてください。

2003年頃からCruise Control -> Continuum -> Hudson (Jenkins) とCIシステムを使ってきたわけですが、当時はJava界隈ではよく使われてましたが、あまりPerlのプロジェクトでは使われていませんでした。今では、Jenkinsの素晴らしいQualityから、Perlのプロジェクトでも大分使われるようになってきていますね。遅筆ではありますが、今後もJava界隈で今までに培ったCIの使い方のノウハウを、Perlのプロジェクトでも活かす方法を書いていきたいところです。

では、Enjoy Jenkins!

次回は、tsucchi さんです！お楽しみに！

# 追記

現在は、拙作のPerl::Metrics::Liteのツールを使うことで、以下のようにJenkinsに統合することが可能になっています。

measureperl-checkstyle --max_sub_lines 100 --max_sub_mccabe_complexity 10 --directory lib > checkstyle-result.xml
コメント

2011-11-28

Javaの標準Collectionフレームワーク代替としてのfastutil/HPPCの使用のすすめ

Javaの標準Collectionフレームワーク代替としてのfastutil/HPPCの使用のすすめ - dann's blog を含むブックマーク はてなブックマーク - Javaの標準Collectionフレームワーク代替としてのfastutil/HPPCの使用のすすめ - dann's blog Javaの標準Collectionフレームワーク代替としてのfastutil/HPPCの使用のすすめ - dann's blog のブックマークコメント

Goな人が最適化しているエントリ(http://blog.golang.org/2011/06/profiling-go-programs.html

)を読んで、ちょっと面白いなと思ったので、元の論文を読んでみました。読んでみたところ、Java 64bit版は標準のC++の5.8倍遅いとなっていたので本当かな？と思い、元のプログラムを見てみました。

http://research.google.com/pubs/pub37122.html

プログラムをざっと見て、オリジナルのJavaの標準のコレクションフレームワークの使用時の罠にはまっていることに気づいたので、以下のチューニングを施してみました。

  • -XX:+UseCompressedOopsオプションを使っても、Integerなどのオブジェクトはプリミティブ型の数倍のメモリ消費量を使ってしまうことから、整数オブジェクトの配列ではなく、プリミティブ型専用のコレクションを使うこと
  • 内部のストレージにダイレクトにアクセスが可能なオーバーヘッドの少ないコレクションを使うこと
  • Iteratorでのアクセスが遅いことから、拡張for文を使うのではなくリストにダイレクトにアクセスすること

たった数十行の修正で、C++のバージョンよりも約2割ほど早くすることができました。また、このコードは、オリジナルのmulti-language-benchmarkプロジェクトのJavaでの最適化バージョン(java-pro)のものよりも1割程度高速です。測定環境(CPU, Memory, Javaのversionなどなど）により性能値は変わるので、測定可能なコードを以下においておきました。

https://github.com/dann/java-multi-language-benchmark

ここで使ったのはfastutilなんですが、fastutil/HPPCは、Javaのコレクションフレームワークに近い（一部互換の）APIを持つ、上記のことを実現するのに適したコレクションフレームワークで、比較的簡単に標準コレクションフレームワークを使ったコードの置き換えが可能です。上記のような理由で、Javaのコレクションフレームワーク使用時に性能が出せない場合にはとてもお勧めできます。

また、Javaで性能を出すためのプログラムをどのように書けばよいのかという点で、とても学ぶことの多いソースであるので、アプリケーションとしてのJavaのコードを読み飽きた方にも非常におすすめです。何故Javaのコレクションフレームワークが遅いのかをJDKのコード、メモリの使用量などを調べながら読み比べてみると面白いです。

# YourKitでプロファイルした感じだと、もう少しチューニングできそうなので、暇な時にもう少しやってみようかと思ってます。

コメント
about
My name is dann. if you like this blog, you should follow me on github or twitter. The opinion expressed in this blog is my personal one and does not necessarily represent the official opinion of company.
最新タイトル
最近のコメント