2013-09-09

第6回テックヒルズ『Let’s study Jenkins～さまざまなケーススタディ～』

Jenkins セミナー

イベント概要

http://www.techhills.net

第6回目となるテックヒルズ。

今回のテーマは「ビルドやテストを行う際にミスが多発する」という属人的な課題を解決してくれる、

オープンソース継続的インテグレーションツール「Jenkins」。

ビルド、テスト、さらにはデプロイまでを自動化してくれるJenkinsは開発プロジェクトにおける優秀なパートナーです。

しかし、革新的なツールであるJenkinsのナレッジは、ほとんどオンラインで得ることが出来ません。

そこで、今回のテックヒルズでは、現在Jenkinsを活用している企業に、導入の過程とその後の課題、

構築及び運用により培ったケーススタディやノウハウ、またその他Jenkinsの付加価値について余すことなくご紹介いただきます。

所感

技術的な面であまり有用な情報はなかったが、社外の取り組み方を知れてよかった。

参加者は700名程度だが、若手、私服（≠オフィスカジュアル）の人が多かった。

Web屋さんやアプリ屋さんが多かったよう。（主催会社がゲームアプリ開発会社のため？）

全体的に会社のバックアップが非常に大きいのが印象的。

CI環境構築のために内作ツールやフレームワークを導入していたりと、

会社全体で問題解決に取り組んでいる点が非常にうらやましい。

（テスト管理ツールやプロジェクト進捗可視化ツールを単独で作成するのは困難）

紹介されていたプラグインetc

Github pull request builder plugin

Gerrit Trigger

Join Plugin

Build Pipeline Plugin

Priority Sorter Plugin

PHP_CodeSniffer　※Jenkinsのプラグインではない

gitlist ※Jenkinsのプラグインではない

進行中の開発プロジェクトで増えていくテストを自動で回し続けるために行ったいくつかのこと

株式会社Aiming 黒木　慎介

発表スライド

進行中の開発中のプロジェクトで利用。

プロジェクト開発期間は８ヶ月　初期は2人、最終的には10人の開発プロジェクト（企画、デザイナーは除く）

主にテストフェーズに利用

何を解決したかったかというと、増えすぎたテスト件数と実行時間との戦い。

問題点

テスト７０００件越え実行時間１時間越えに →自動テストの重要性が増す。

対策

ジョブ分割・Jenkinsの並列実行

スレーブを２台から６台に増設

テストをカテゴリ別に分割して実行

分割に便利なもの１　ラベル付け

ノードの設定画面でラベルを設定。

ラベル式をで「実行するノードの制限」

分割に便利なもの２　join Plugin

Aが成功したらBとCを実行して、両方成功したらDを実行する

最後にメトリクス計測とか。

ジョイントリガー

分割に便利なもの３ビルドパイプラインプラグイン

ビジュアル的にパイプラインが表示できるので、親子関係がわかりやすい。

Gerritを利用してレビュー

ある変更がレビューを通してどのように変更されたか。

Gerrit Trigger プラグイン

レビュー依頼が提出されたら、Jnekninsのジョブを実行

レビューの対象は全て。

そのため、実行が開発のペースに追いつかない。

差分テストが終了しないうちに修正や再提出が行われてしまう。

→Jenkins（リグレッションテスト）の完了を待たずにマージしてしまうことに。。。

原因

開発人数が増え、ペースが上がっていた。

解決したいこと

無駄な実行をしたくない。無駄なテストはJenkinsを中断したい。（失敗ではダメ）

対応策

成功（青ランプ）　>exit 0 失敗（赤ランプ）　>exit 1 中断（灰色ランプ）　Webから止める。curlで叩いてSleepする

Jenkinsを利用するときの心構え

１　自由度が高い

Jenkinsがやってくれるのは自動化だけ。

自動化する処理は自前だよー。

２　プラグインのドキュメントはちゃんと読もう

wikiに乗っている

それでも挙動がわからない場合は。。。GitHubのソースコードでも読め。

AimingでのJenkinsの利用

ビルドテスト実行デプロイサーバ再起動データチェック　（ゲーム会社なので、定期的にする必要がある、）結果の通知はスカイプとか、パトランプなど。

利用方法の一例

企画の人が作成したマスターデータを取り込んでデプロイすると... データにミスがあるとデプロイがとまって困る。取り込み部分だけをジョブ化。ミスがあっても自動でわかる。

Jenkins + GitHub

株式会社ミクシィ　大塚　弘記

視聴していないので、資料のリンクのみ

Jenkins + GitHub in 第6回テックヒルズ

検索基盤開発の為の結合テスト環境の自動化

楽天株式会社　荻野　恒太郎

Jenkinsを含めて、結合テスト環境の自動化を行った。

利用期間は半年間。

結合テストを自動化した背景

開発で困難なポイント→ コンポーネントの結合が一番困難。

それぞれのコンポーネントの開発担当者はI/Fに仮説を持って開発を進めている。

コンポーネントの結合　=　仮説の検証

開発期間の割合を見ると開発５０％、結合３０％、QAテスト２０％で結合部分が大きく割合を占めていた。

開発プロセス

ローカルでのソースコードの変更

単体テストの追加

↓

ソースコードのマージ

テストの実行、変更のコミット

↓

コミットビルド（ビルド＆自動テスト）

自動デプロイ

↓

二次ビルド（結合テストの自動化）

結合テストは対象コンポーネントが複数、失敗率が高く、複雑

大規模な結合テストを毎日実行するためには、自動化が必要。

結合テスト自動化の課題と解決策

複雑さの解決

テストの基本にのっとり品質を積み上げる。

複雑な内部状態のテストはUT・CTで。

結合テストは原則ブラックボックステスト

実装コストの解決

テストフレームワークを開発することで工数削減。

シナリオベースでテストケースを表現。

仕様変更に対しての保守性もアップする（テストケースの変更も容易になるため）

JSON形式でのテストシナリオを作成(内作ツール：Ngauto)

実行時間の解決

コミットビルドで１０分程度ののSmokeTestをすることで簡易テストを実施。

スモークテストに合格したものだけが結合テストに行く。

結合テストのジョブで１時間を超えるものは分割して並列実行。

５０台のテスト環境で平行実行。

スモークテストの注意

実行時間とカバレッジのバランスが大事

実行時間は１０分程度じゃないと開発者がおっくうようになる。

ドキュメントの登録/削除

日本語処理も行う

平行性などをチェックする

複数のExecutorを配置し、並列にテストジョブを実行

Priority Sorter Pluginにてjobの優先度を設定、主要なテストから実施。

結果の再現性の確保

＃これはただ単に環境の構築方法がダメなだけな気がする。。。

テスト実施時の環境の差異がでてくる。（連続したテスト実行のためのシステムの状態に差異）

ex. 他のテストでできたデーモンが残っている、他のテストがI/O異常を起こしたまま回っているetc...

解決方法→クリーンアップ＋インストール

実際に運用している開発プロセス

システムテストのみが手動テスト。

結合テストまでをCI。

結合テストに成功したビルドバージョンをjsonに記載するのがJenkinsのデプロイゴール。

CIの効果

結合テストのバグを開発当初から見つけることで、開発コストの軽減できた。

初期に障害を潰せるので、QA期間はサービスの高度な付加価値部分のテストに集中できた。

スモークテストでは６％のバグを発見できた。発見率/実行時間的に非常に効率的。

CIの効用

対象プロジェクトの寿命が長い場合は効果が大きい

開発中のコンポーネントが多いほど効果が大きい

要求・使用。設計の変更頻度が多いほど効果が大きい（仕様変更の影響度が翌日にわかる）

＃これは変更頻度が大きいほど再利用性が低くなるので一概に言えないかも。。。

まとめ

結合の検証までを自動化することで、仮説の検証を効率化をすることができた。

CROOZにおけるJenkins活用事例（仮）

クルーズ株式会社　鈴木優一

日々の開発・保守・運用でどのように業務課題を解決しているか。

プロダクト開発スタイルの提案。

CROOSのプロダクトリリーススタイル

・リリースギリギリまでトライアンドエラーを繰り返すこと。

これを実施するためには。。。

コーディングスタイルの共通化（規約の共通化レベルではなく。。。）

運用の共通化

上記を実現する自社フレームワークの構築

この社内プロセスがあるので、チーム間での人的資源の移動が容易。

課題

重要なコーディングスタイルの共通化が行われにくくなっていること。

頻繁に行われる本番へのデプロイの過程で本来不要な

ファイルが誤って更新されてしまうことが発生してしまうこと。

原因

共通化されているルールは複雑すぎる。確かに可読性、パフォーマンスの観点から共通化は大事だが、覚えることが大変で

古株しか良くわかっていない。

事業拡大に伴い、プログラマが急造したいろいろな（会社から来た独学スタイルの）人が増えた

基本的にＰＧ性善説に則っている。 解決のための施策

ルールから外れているものを機械的に検知し、可視化する。・オペミスを引き起こす疑いのあるコードや設定を機械的に設定する Jenkinsのいいところ(選んだ理由)

構築がラク各種プラグインが充実ジョブ管理ツールとして利用できる実装言語によらず、全社横断で利用が可能。（言語ごとにスレーブ・マスターで統括）ドキュメントが豊富

自動テスト・自動ビルドの前に、既存課題の解決が第一！！

活用事例

規約チェックの自動化自動化および可視化　PHP_Code sniffer VenusBase（自社フレームワーク専用のコーディング規約定義リスト）

除外ファイルの更新漏れの自動通知リモートシェル・gitlistによる除外ファイルの更新漏れの自動通知

OSSを活用したソフトウェア開発環境構築

株式会社東芝　山元　和子

山元さん所属のソフトウェア開発センターのミッション

内作ツールの作成、東芝グループの開発プロセスの改善

東芝のスコープは家電やインフラ・Webツールの開発など、組み込みシステムから

Webシステムまで、用途・規模・言語多岐にわたる。

品質確保の質を保つ為に必要なこと。

自動化

可視化（プロジェクト進捗状況の可視化によるPM作業の効率化）

設計部分はスコープによってプロセスが異なるので、定型作業が多い、

効果的な実装～テスト工程むけにツールチェーンの構築した。

ビルドチェーン構成図

構成管理ツール→ビルド管理ツール→ソースコード解析ツール→テスト管理ツール→不都合（障害）管理ツール

基本的にメール通知定量的管理支援ツールでプロジェクト状況は管理者は確認

構成管理ツール：　Git/svn/Mercurial

ビルド管理ツール：　Jenkins

ソースコード解析ツール：　cppCheck、C++Test、FindBugsなどの市販ツールの結果を統合するTCANA（内作）

テスト管理：　内作ツール（テストリンクみたいな）

障害管理：　Redmineと内作ツール

Jnekinsの実行内容

ビルド、ソースコード解析・自動テスト・カバレッジ計測

Jenkinsで便利になったこと。

Webから実行できる、成果物もWebから。（以前は担当者がいないとビルドPCにログインもできない。。。）

バッチ処理スクリプトを書くより簡単

内作ツールでPM向けに各種ツールから以下の情報を収集・可視化している。

ツールに蓄積されたプロジェクト情報を自動収集→集計→可視化

複合メトリクスも表示

ショート・ロングスパンタスク推移

バグ発見改修状況

タスク滞留日数

テストNG結果

Jdepend解析結果

pigとJenkinsと私

株式会社サイバーエージェント丸山　隆司

アメーバピグの開発・運用でJenkinsを利用

アメーバピグでのケーススタディ

コードの品質管理

理想的なCIのカタチ

各自のブランチでコーディング、トランクに突っ込んで、CIサーバでビルドしてIRCに告知」

１１年アサイン当時の現実

ブランチでレビューしてトランクにコミット。

デプロイ手動。

CI環境なし。

テストコード（ほぼ）無し。

改善するためにまず。。。

トランクのプロジェクトにJenkins適用

全PJ合わせて数千個のFindbug警告

どこから手を付けるのか。

改善戦略

CI環境の整備。。。コミット、フック、フィードバック

危ないバグはみんなで修正。。。面倒ごとはある程度強制力を働かせてみんなで対応

その警告本当に必要なの？。。。一部のテストコードは解析対象から除外

ある程度の割り切り。

課題

IRC開いてないと通知に気づかない。

ガイドラインに沿ったコードになっているかのチェックを自動化

　バッチ制御

ピグで稼動するバッチ処理。

５７本のバッチ処理が稼動。

オンライン処理の裏側で稼動

単発の処理がほとんど（不要データの削除、ログ収集）

つぎはぎだらけのバッチ環境

cron起動SpringBatchが混在

新バッチサーバ＆＆旧バッチサーバ

運用上の問題点

ジョブの実行状況が把握しづらい

管理サーバとジョブが同一ＶＭ上で稼動（ジョブごと管理サーバが落ちる）

とりくんできたこと

スプリングバッチを捨てる

ジョブ実行用のシンプルなＦＷを開発

ＦＷに合わせてプログラムは再作成

バッチの制御はJenkinsに委譲

cronもJenkinsで実行

スケジューリング・記録

RemoteAPIでキューイングされているジョブがないか。

同一のジョブの多重実行がないか。

今後の課題

権限の問題（認証していないの無防備）

オペレーションの自動化

前提

ピグは２系統ある本番環境を毎週切り替え（２４時間稼動なので。）

次週の本番環境でテストすることができる。

事例

本番・待機系でリリース物が異なってヒヤリ

管理画面がINternetに大公開

実はサーバ死活監視していなかった。

再発防止策

手動操作の限り、ヒューマンエラーは防げない。

→自動化

Jenkinsでのモニタリングの仕組み

グーグルカレンダーと連携して実行、メール。

リソースの差分チェック　サーバ間差異、本番/待機系間差異

リマインダ（月金が公休の場合、リリース曜日がずれるので警告メール送信）

今後の課題

自動化できる範囲を広げる

デプロイ・リリース

稼動系の切り替えの自動化

メンテナンス切り替えの自動化

最後にひとこと

「途中からJenkins入れるのめんどくさいから、最初からやろうぜ！！！」

2013-09-09

Amzon AWS EC2にRedmine、Jenkins、WordPressを導入する。

Redmine Jenkins WordPress EC2

自宅でのTiDD、TDD開発(とナレッジメモ用ブログ)を目標とした環境構築を行う。
Jenkinsの稼動が土日くらいならば、トラフィックもあがらないし、無料枠ですむはず。

目標

ではサーバを購入するためDELのHPに行く…というわけには行かないので、今回は以下の目標を立てる。
なお、結果としては半日作業。つまらなければ3時間程度で終わる予想。

最短で構築を終了すること
基本的に無料で終了すること
クリックとテキストエディタだけで終わらせる。（コマンドプロンプトの利用は最小限に抑える）

利用ツール

今回、利用するツールは以下のとおり

Amazon AWS EC2 (Windows server 2008 R2 [Japanese])
Jenkins
BitNami RubyStack
BitNami Redmine Module
BitNami WordPress Module
Pleiades All in One Ultimate
その他プッシュ方式の電話とクレジットカードが必要になる。

サーバーを構築

次のリンクのスライドを見ながらがんばる
AWS初級トレーニング
途中で電話とクレジットカードが必要になる。
2012年12月現在、普通に使っていれば1年間無料。
　　

Windows ServerのIEはやたらセキュリティが厳しいので、Chromeあたりを入れておく。
あとサクラエディタあたりいれておかないと文字コード間違えて上書き保存して積む。
その後、サービスで「World Wide Web Publishing Service」を無効にしておく。
EC2のSecurity Group設定はめんどくさいので、Apache用にHTTPプロトコル用のポート80をあけておく。

BitNami RubyStackの導入。

http://bitnami.org/stack/rubystack リモートデスクトップでWinServerにアクセスして上記HPのRubyStack 1.9.3-1.Stackをインストールする。
インストール時の言語はEnglishが無難。
Apacheのポートは80にしておかないとめんどくさい。
使用済みといわれる場合は、上記で説明したサービスの無効化をしてからリトライ。
このときに入れるMySQLパスワードはRedmineなどの導入の際に入れる必要があるので忘れないようにする。
最後にWindowsファイヤーウォールを開いてApacheが外部とアクセスできるように設定しておく。

ここまででRuby, PHP, MySQL, Apacheの環境構築終了。
git、svnも入っているので、PATH通しておくと幸せ
http://Amazon EC2で取得したElastic IPs/にアクセスすれば
APACHE_ROOT/httdocs/index.htmlの内容が表示されているはず。

Redmineを導入する

TiDDを行うためにRedmineを導入する。
http://bitnami.org/ja/stack/redmine
上記サイトからModuleのほうのRedmineをインストールする。
（無駄にApacheを複数入れるのは意味がない。）
その際にStackの場所を聞かれるので、ROOT\BitNami\rubystack-X.X.X-Xを指定する。
MySQLのパスワードはRubyStackを導入した際のパスワード。
このときMySQLが動いていないと認証できないので、サービスで停止していた場合はたたき起こしておくこと。

RedmineのインストールはDBの生成が長いのでここで一回休憩しておくっ！

WordPressを導入する。

WordPress(Blog)は直接開発と関係ないため、飛ばしてもよい。
http://bitnami.org/stack/wordpress
基本的にはRedmineのときと同じ。上記URLのModuleをRubyStack以下にインストールする。

ちなみにWordPressは以下のプラグインを導入

Markdown on Save Improved　(投稿画面の隣のConvert HTML to Markdown (experimental)はよくわからんからチェックはずす。)
SyntaxHighlighter Evolved
Jenkinsを導入する

Jenkinsに関してはRubyプラットフォームのソフトではないため、
BitNamiとは別に入れる。
Windows環境でもJenkins -執事さんとご対面-
上記ページを参考に、ApacheがROOT\BitNami\rubystack-X.X.X-X内にあるので登録しておく。
ただし、Jenkins.xmlを編集するときは以下の記述でOK。

  -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar “%BASE%\jenkins.war” --prefix=/jenkins --ajp13Port=-1 --httpListenAddress=127.0.0.1 --httpPort=8080

わざわざajp13でポートを開く必要はない。

ここまででlocalhost/redmine、localhost/jenkinsが出来上がっているはず。

Eclipseを導入する

あとはJenkinsのビルド環境を整えるだけ。
http://mergedoc.sourceforge.jp/
上記サイトからPleiadesのUltimateをインストール。
CygwinはめんどくさいのでEclipseのAll In OneでJDKとMinGWを一気にダウンロードしておく。
重くて使い物にならなくてもServerではビルドツールとして使うだけなので関係ない。
リソースが十分ならば4.3Keplerで問題なし。

JAVA_HOMEのパス通したり、Pleiades\eclipse\minGW\binにパス通しておけばおしまい。
VisualプロジェクトをJenkinsでビルドしたい場合は、適当なVC++Expressを落として
MSBuild.exeを拾ってくる。

あとは手元のコードをGitHubにでもコミットして、Jenkinsのジョブ作ればおしまい。

できた！

2013-08-07

某IT会社のGeekな先輩から出された問題。

コラム C++ Java

問題

以下の制約を守り、Nの階乗（N!）を返すint computeFactorialN(N)メソッドを実装してください。
制約：if, switch, for, while,比較演算子は利用不可

正解

~~たしかにJavaは思いつかない。Boolean型の仕様が厳しい。~~
ちなみにcomputeFactorialN(0) = 0になるのと、
すぐintがオーバーフローするのはドンマイ。

#include <iostream>;

static int computeFactorialNotOne(int n);

static bool notEqualOne(int n){
    return (bool)(n >> 1);
}

static int computeFactorialOne(int n){
    return 1;
}

static int (*factorials[2])(int) = {computeFactorialOne, computeFactorialNotOne};

static int computeFactorialNotOne(int n){
    return n * factorials[notEqualOne(n)](n - 1);
}


static int computeFactorialN(int n){
    return computeFactorialNotOne(n);
}

int main(){

    for(int i = 1; i &lt; 10; i++){
        std::cout << "computeFactorialN(" << i 
            << ") = " << computeFactorialN((int)i) << std::endl;
    }
    return 0;
}

0!=1の実装はあと２つくらいメソッドを追加すればおっけー。
Javaは0の判断を以下のように行い、メソッドを切り替えればできる

( (n * -1) >>> (Integer.size() - 1) )

2013-08-07

Java Day Tokyo 2013メモ

セミナー Java

下記カンファレンスへの参加メモ。

Java Day Tokyo 2013
2013年5月14日(火)
秋葉原UDX（アキバ・スクエア、UDX GALLERY、UDX GALLERY NEXT）

【KeyNote】

Java7はオラクルとなってから初のリリース。
OSXもサポートしたし、Embeddedにも注力した。

java8は2014、2月正式版リリース予定。
オラクルとしては今後も2年おきのリリースを目指す（2016にjava9）

Java8はコアライブラリ、JVMにも大幅な変更が入る予定。
Lambda式、関数オブジェクト、closureは最もたる特徴。
これまでのコレクションにも変更が入る。
forEachインターフェースなどが追加される。
しかし、Java7以前との対応はしっかりサポートしているので、心配なく。

Test Pilot Wanted
Early Accessはもう公開しているし、DLできるよ。
みんなの感想や意見を聞かせてほしい。
いつDLするべきか？
イツヤルカ？
イマデショ！！

JavaFX2.0
JavaFXはSwingの発展系。
アンサンブルがApp Storeにリリースされている。
オープンソース化することも視野に入っており、確約する。
openJDKでソースコードにアクセスできるようにすることを予定。
LinuxARM上でも動くようになっている。
リリース計画はJava8と同じ予定

JavaFX 3Dデモ
Win8とサーフェスでデモ
3DモデルはMayaで作成している。
3D球(Shape)程度のデモコードならば、５、６ステップで作成できる。

テクスチャフォーマットもいろいろ用意してあるので、凹凸を再現したりできる。
＃モデル自体を凹凸にしているわけではない。
テクスチャをどのようにShapeに貼り付けるのか？
実装ではマテリアルクラスで作るだけで簡単にできる。
光源もクラスで用意してあるので、座標や色を簡単に設定・変更できる。

Java　Embedded
これからはモノ同士がインターネットに接続される時代。
-ユースケース
都市の自動化、交通情報のネット化
交通渋滞や駐車場情報などを管理できる

産業への組み込み
貯蔵タンクなど、デバイス自体がデータを処理してインテリジェンスなデータ処理
自販機の在庫状況や港の貨物情報のモニタリングなども。
医療文化の在宅提供もできる
スマートホームの家電連携もまさにJava Embeddedの出番である。

こういったインフラへの組み込みで重要になるのはセキュリティである。
多くのアーキテクチャがネットワークに接続されている中で、それぞれを切り分けることができるのが大切。
さまざまなI/Oにも対応しなければいけない。
そしてリモートDL、アップデートができなければならない。
日常の小さなデバイスがIT化していけばしていくほど、
それぞれのメンテに要員を出す暇はなくなる。

Java ME
マイコンが入っているのには最適
JAva MEのリリース計画もJDKと同じ。

java embededd suit
ゲートウェイなどに最適

Java EE
エンタープライス向けのリリース
Java EE7ではhtml5、JSONやWeb Sokcketをサポート

それぞれは全てJava8のリリース予定と同様である。

Java Community
Javaの分野を３つで考える
・オラクルスチュアードシップ　オラクルのリーダーシップ
・イノベーション　新しい機能からまた新しい機能が生まれる。
・参加　利用者の声からまた新しい機能が生まれる。

まず最初は学習すること。
オラクルはさまざまな学習・教材を提供している。
Javだけじゃなくて他も学ぼうねー。
学習の次は参加すること。
ツイッターとかで対話すること。そして新しいインスピレーションが生まれる。
jug.orgにみんな参加してねー。

JJUG参加方法

・なぜコミュニティにはいるのか？
デベロッパーとして成長するため。
普段いろいろな情報が公開されている。Javaに詳しい人がいる。
悩みを共有して解決のきっかけにする。
会社にいても古いコードだとかプロジェクトに縛られてしまう。

活動内容
クロスコミュニティカンファレンス　年2回1日イベント
ナイトセミナー　月1回の夜二時間のイベント
週末ハンズオン　週末半日から1日の持込で実装してみる。

JJUG今年の活動内容
Java SE 8/EE7の情報
第４水曜日　オラクル青山でやるよー。

情報の入手方法
ツイッター　@JJUG
java-users.jpでメーリス登録できるよー

JavaOneカンファレンスがあるからきなよー
サンフランシスコ 9/22-26

Javaとは何か
革新そのもの。ただしみなさんの参加があれば。
コミュニティとは何か。それはみなさんです。
みんなで学習し、がんばりましょう。

【B1 Raspberry Pi NightHacking (Java SE / JavaFXを楽しもう)】

シンテリオン（Sintelion？綴りメモできず）
　ワイヤレスネットワークにマウントするチップ。
　Java ME(Micro Edition)で組まれている。
　実用例
　保護区の木一本一本をシンテリオンで管理し、森林伐採を監視したり。。。

　Raspberry PI
　さまざまなI/Oがついている小型コンピュータ。
　USB、GPU、カメラ、タッチパネルさまざまなI/Fを用意している。
　Piの設定方法
　 Linuxをインストールする。
　 Java 8 for ARM EA
　 Javaアプリをデプロイして実行する。
　みなさんできますよね？じゃあ使えるじゃん！

　その後の話は途中おねむで離脱。。。

【E2 Java IDE の最新トレンド】

　マイナビニュースで「イマドキのIDE事情」など執筆している方など。
　あまり表題のテーマの話はせず。
　 Eclipse
なぜ発展したのか？
　ユーザーがプラグインを開発して機能拡張していく、エコシステムがうまく働いた。
　　InteliJ IDEA
無償版もあるけど、英語版しかない。
チェコ発のIDE
InteliJは簡単にGroovy、Scala、PureJavaのハイブリッドプロジェクトを作成できたりできる。
　　NetBeans
　他のIDEと比べ、設定が容易。最少手順で準備・実装ができる。
　JavaEE系の補完は一番対応している。
　JavaEE7などに対応しているのはNetBeansだけ。
html5+javaScript、php作るのに便利！

　---------------------------- 　

【B3 Groovy, Clojure, Scala, VisageでのJavaFX活用】

JavaFX2.0について
リッチGUI、html5、3Dをサポートする。
Early Accessでjava8(JavaFX2.0)つかって3Dをやってみようぜ。
https://jdk8.java.net/download.html

新しい言語を使ってみよう
新しいことに興味をもとう。
新しい言語JVMランゲージは簡単にJavaFXラップできるよ。

以下各JVMランゲージでVanishing circlesデモアプリを実装
LOCなどを比較
Vanishing circlesの詳細、比較内容の詳細はこちらの英文参照。

pure java8の場合
40行、1299文字で実装できる
　利用クラス：circle、Bindings、Duration etc...

GroovyFX
GroovyはなJVMランゲージ
29行、671文字で実装できる。
SceneGraphBuilderで簡略化できるよ
みんなの心を鷲つかみ。アニメでたとえるならばルパンIII世。

Clojure
シンタックスが独特、括弧がおおい。
シンタックスシンボルが少ない、すぐ言語仕様を覚えられるのがClojureの便利なところ。
オブジェクト指向ではないので、オブジェクトに対応するにはファンクションコールしなければならない。
シンプルですごい簡単におわる。アニメでたとえるならば、ワンパンマン

Scala
Haskkelから来ている。
シンタックスルールはXMLなどに近い。
33行　591文字で実装できるよ。
ScalaFXのシンタックスはGrrovyFXと似ているものすごい勢いで機能が充実している。アニメでたとえるならばグレンラガン

Visage
35行 487文字で実装できる。
デフォルトパラメータによって、コード量を少なくできる。
NULLチェックディファレンス、
新しいBindingもサポートしている。
ScalaFX, GroovyFXと似ている。
Visageが実現する未来的ビジュアルは、たとえるならばエヴァだよ

その他、Gosu、Mirah、Fantom（.NETとも連携できる）などでもJavaFXは使えるよ。

でもここは日本だね！ということはRubyでしょ！

jRubyFX
33行 800文字くらい
ボクはあまり得意ではないので、もっと最適化できるはず。
ブログでコード公開するからjRubyハッカーのみんなのコメントを募集しているよ。
http://steveonjava.com/

質問：コーディング量の比較はわかったがパフォーマンスの比較は？
パフォーマンスといえばpureJava。
他でやるとやはり便利なぶん、オーバーヘッドはすごい。
＃どこのオーバーヘッドだったかはメモとれず。。。

質問：javaFX2.0の実行環境は？
Java7のランタイムが入っていれば使える。
やる気ならばハイブリッドプログラミング（html5）もできる。

【E4 帰ってきたJavaパズラー】

Lambda激押しすぎてJava8言語仕様を知らないと答えられないクイズ多し。

【A5 Java The Night】

RICOH & Java™ Developer Challenge Plus 2012の参加者などもいました。
http://www.ricoh.co.jp/javachallenge/result/#2012

その他、パワポではなくJavaFXを利用しているプレゼン多し。

2013-08-07

PM試験午後II対策

試験対策

注意事項

この記事はプロジェクトマネジメントスキルを身につける記事ではありません。
春に行われるPM試験に対する試験対策です。
PM試験の午後IIはひたすら知識・用語の学習と、論述の練習をするしかありません。
今回は可能な限り事前に準備できるものを挙げることで、対策とさせていただきます。

PM試験午後IIの試験方式

PM試験午後IIは120分間です。
3テーマの中から業務経験を踏まえて小論文（2400字以上4000字以下）を記述します。
A-Dの4ランクで採点され、Aランクのみ合格となります。
なお、他の試験に漏れず、午後Iが合格点に達していない場合は採点すらされません。

試験に必要なもの

午後II試験に臨む際に必要なものは以下の通りです。

腱鞘炎にならず、120分キレイな字を書き続けられる利き手

B、HBなどの普段利用するシャープペンシル（鉛筆）

2B、4Bなどの濃い目のシャープペンシル（鉛筆）

消しゴム

600字程度で自分がPMとしてアサインされた（と想定した）一般的なプロジェクトの概要

時計、替え芯など

解説

まず、上記必要なものについての解説から行っていきます。
午後IIはワープロを使えない論述試験であることを強く意識してください。

腱鞘炎にならない手？

1度時間を計って過去問を解いてみてください。言っている意味がわかります。

PM試験午後IIは120分で最低でも2400字以上を書く必要があります。
合格基準や、章構成や箇条書き、図や表を使うことを考慮すると、記述用紙の参考文字数で、3000字ラインまで記述したほうが無難です。
仮に2400字でも単純計算で分速20文字の記述速度を維持する必要があります。文章構成を考えたり、問題テーマを読む時間を引けば、それ以上の記述速度が必要です。
(後述の準備をすることで600字は貯金しておきます。）
IT会社に勤める受験者にとってこの記述速度が大敵になります。

普段文字を書かないので字が汚い

普段PCの変換に頼っているので、漢字が正確に思い出せない

「内容がよければ平気だろ」と思われる方もいらっしゃるでしょうが、採点者は人間です。
当然採点者は何十人の採点を受け持っているでしょう。
読む気にならない汚い字や、漢字の間違いはそれだけで減点、採点者の心証を悪くし、最悪ろくに読まれずD判定になる可能性があります。

なぜ筆記用具が二種類必要なのか？

ワープロソフトなどでいうBold機能を濃い筆記用具で代用します。
繰り返しになりますが、午後IIは人間が記述し、人間が精読し合否が決定する試験です。
午後IIは字数以外の制限はありません。図や表の記載も可能です。可読性を少しでもあげるため、章立ての間に空行を置いたり、箇条書きなどで工夫します。
そこに加えて、筆記用具を替えることで太字を活用します。使い方は普段Wordなどで太字にする箇所を濃い目の筆記用具で書くだけです。論文構成がパっと見でわかるようにセクション名などは濃い筆記用具で記載します。
＃重要な語句や結論を太字にすることも可能ですが、それはさすがにいやらしいかも。。。

プロジェクトの概要について・注意点

午後IIではどの問題テーマでも、必ず設問アで「論述の対象となるプロジェクトとしての特徴と論述するテーマに関わるファクターの説明」を800字以内で記述します。
そのため「プロジェクトとしての特徴」を事前準備しておけば、500字程度は問題に関わらず記述することができます。
これでいくらか時間を貯金することが可能です。

注意点１：PMとしてアサインされた（とする）プロジェクトの特徴を準備する

ここで書くプロジェクトは実体験である必要はありません。
筋が通っていれば、架空のプロジェクトでもかまわないのです。
組み込み開発従事者で特に注意したいのはMLやTLはPMではありません。

私は○○モジュールのモジュールリーダーとしてアサインされた。

私は○○プロジェクトにチームリーダーとしてアサインされた。

モジュールリーダーやチームリーダーはプロジェクトマネージャではありません。
プロジェクトマネージャとしての経験を問われるのが午後IIです。
モジュールリーダーに日程調整・機能調整の権限はありますか？
チームリーダーに予算折衝・アサインメンバ変更の権限はありますか？
上記リーダーの上にはPMや上司が存在します。
プロジェクトの管理権限が不十分なため、論述中に矛盾が生じたり、根本的に「PMとしての立場の記述ではなくプロジェクトメンバの記述」とみなされると、採点の前に失格です。

注意点２：一般的なプロジェクトの特徴を準備する

Webアプリや商用ソフト、社内システム開発などのプロジェクトのPM経験を捏造しておいたほうが汎用性があります。
組み込みシステム開発プロジェクトでは選択できる問題テーマが絞られる可能性があります。

組み込みシステム開発プロジェクトでも、リスクマネジメントや品質マネジメントなどの問題は対応できます。
しかし、調達マネジメントや、コストマネジメント系の設問に対応するのは難しいです。
例をあげると、H21年度の午後II-問3は
「業務パッケージを採用した情報システム開発プロジェクトについて」
という設問でした。
組み込みシステム開発の場合、このような設問を選択肢にするのは難しいと思われます。
また、一般的なプロジェクトオーナーを「設定」するために、無理やり別会社から依頼された外注プロジェクトにしたりする必要もあります。
つまり、3問中1問選べるはずが、2問の中からしか選べないor準備したプロジェクトの特徴を捨て、別のプロジェクトの特徴をその場で書くことになってしまいます。

最後に求められている解答を書く

午後IIは成功体験を記述する試験ではありません。
設問されたことに正しく解答する試験です。「～が失敗したときにした対策を～」という設問の場合は失敗（したことに）した経験を解答します。

例を挙げると以下のような問題です。
H22年度　PM午後II 問３　システム開発プロジェクトにおける進捗管理について
設問ウ
設問イで述べた対策にもかかわらず進捗が遅れた原因と影響の分析、追加で実施した対策と結果について具体的に述べよ。

このような設問の場合は必ず以下のように経験を捏造してください。

対策したにも関わらず進捗が遅れた

対策が不足していたので対策を追加・実施した

ここで求められる解答は
「対策が万全で進捗に影響はなかった。」
「事前対策が十分だったので追加対策は不要だった。」
「私はプロジェクトマネジメントスキルがあるので、そんなヘマしたことがありません」
ではないことを注意してください。

以上のほかは一般的な試験対策などをしておけば十分合格は可能なはず…です。

知識量を示すために文章中にPMBOK、QC七つ道具などキーワードを盛り込む

論文の構成方法などを学習する

文末は常体で終わる(～だ。～である。)

最後は「以上」で終わる(時間内に書き切ったことを明確にする)

参考文献

ポケットスタディプロジェクトマネージャ

情報処理教科書プロジェクトマネージャ

マルオのプロジェクトマネージャ合格対策
http://maruopm.web.fc2.com/pm_prep.html

2013-08-07

PM試験午後I対策

試験対策

注意事項

この記事はプロジェクトマネジメントスキルを身につける記事ではありません。
春に行われるPM試験に対する試験対策です。
PM試験の午後Iは過去問題の学習により、IPAが求めるPM人材像を学習します。

PM試験午後Iの試験方式

PM試験午後Iは90分間です。
4テーマの中から2テーマを選択します。（各テーマ50点）
100点満点中60点以上で合格になります。
ただし、午前IIが合格点に達していない場合は採点すらされません。
午後問題からは記述・論述回答が必要になるので、
正確な自己採点ができないのも特徴です。
最低でも午前IIをパスして午後Iを採点してもらわないと、
次の試験に向けた自分のスキルレベルを測ることができません。
（午前問題は選択問題なので、模範解答なのでどうにでもなる。）

試験に必要なテクニック

午後I試験に臨む際に必要なテクニックは以下の通りです。

短時間で設問プロジェクトの概要と問題を理解する

プロジェクト説明から問題回答に関連する記述をピックアップ

回答候補（発生した状況、リスク・問題・目標、とるべき対応・対策）をイメージする

過去問題から「模範となる対策・原因分析」を学習しておく

文字制限に合った回答を作成する国語力

しっかり全問解答できる時間管理

短時間でプロジェクトの概要と問題を理解する

まず最初の10分程度で、解答するテーマを選択する必要があります。
そのためには4テーマのプロジェクトの概要と問題を理解し、自分の得意分野かどうか、解答できる問題の多さを把握することが大事です。

プロジェクト説明から問題回答に関連する記述をピックアップ

解答する2テーマを絞ったあとは、プロジェクト概要を読み込みます。
プロジェクト概要を熟読する時間はありません。
そのため、問題文を先によみ、問われる内容・解答をイメージ、
概要の中から問題の解答のヒントになる部分を抽出していきます。
具体的には以下のようにして、解答記述の際に再読の必要がないようにしておきます。

会社・プロジェクトチームの関係図などを余白に図示しておく

プロジェクト概要内の人物・会社名などは「請負元のA社」「PMのF課長」など、
一度読んだ後でもなかなか相関関係がイメージしづらい名前になっています。
そこで、少しでも解答をひねり出す時間を稼ぐため、人物・会社体制図を余白に図示しておきます。

臭う記述は下線を引いておく

概要には「？」となるような箇所がいくつか記述されています。
それら大半は問題の発生原因となる行動・対処、つまり解答のヒントになる部分です。
具体的には　・否定的な表現（例：ユーザー部署がシステム導入に難色を示している）
　・解答を限定するような注釈（例：ただしB社に人的余裕はなく、要員追加はできない）
　・不自然な表現（例：機能仕様の不明点については後工程で調整していく。）

離れた記述の中に関連がある場合は矢印で結んでおく

上記のような体制・ヒントは概要のあちこちにちりばめられており、いざ解答するときになると、
再読して解答根拠を探すはめにもなります。
そのため、「○○社員の行動を線で結んでおく」
「○○の行動要因となった事象を線で結んでおく」などをしておくことで、解答の際の再読頻度を下げておきます。

回答候補（発生した状況、リスク・問題・目標、とるべき対応・対策）をイメージする

問題の解答の大半は「状況」「問題・リスク」「対応・対策」のいずれかを求められます。
たとえば以下のように、一部の情報が概要に記載してあり、伏せられた部分の解答を求められるような問題となります。
そのため、抜け落ちている情報を解答するイメージで問題文からヒントとなる部分を抽出・結びつけておくと、解答を考える時間も短縮できます。
例：
　・発生した状況（請負先各社で共通の構成管理がもっていなかった）
　・問題、リスク（問題：今回のプロジェクトで対策が必要となった原因は何か。）
　・対応・対策（PMのD課長は請負先各社横断の構成管理サーバを構築し、その週の結合テストは月曜時点の最新版リビジョンで実施することとした）

過去問題から「模範となる対策・原因分析」を学習しておく

どのような試験でもそうですが、解答の傾向を知ることが一番の近道となります。
現実的にはプロジェクトで発生した問題には多種多様な解決策が存在します。

例：本社とシステム利用部門でプロジェクトに対する利害関係が対立し、プロジェクトの成果目標が定まらない。
　・　双方の合意が取れない限りプロジェクトを進めないという厳格な態度で臨む
　・　担当上司たちの懇親会を設定し、部署間の溝を埋めたり、味方となるステークホルダーを得る。
　・　プロジェクトオーナーである社長からトップダウンの指示を得る
　・　各部門に赴きそれぞれのメリットデメリットを徹底的に議論し、早急に妥協点を探る

このような問題が発生した場合、選択すべき解答は太字の最後の対応になります。
これは過去問模範解答から得られるIPAがPMに求める対応です。
実際に発生した際の最善策を考えるよりも、あくまで、PM人材に求められる理想解答を選択する必要があります。

文字制限に合った回答を作成する国語力

午後Iは記述問題であり、10文字で解答する場合や、30文字で解答を行う必要があります。
内容的に採点者の認識と一致していても、文字制限の8割程度を解答するほうが無難です。
そのため、同じ意図の解答でも、以下のようにある程度字数を調整します。
　・設計工程は最初からやり直しとならないため（20文字）
　・設計工程の手戻りは最初からやり直しとならない場合が多いため（29文字）

しっかり全問解答できる時間管理

こちらも全ての試験に共通することですが、論述試験では配点満点の解答を一つ考えるよりも、
8割程度を狙えるような解答で全ての問題に対して解答しておく必要があります。
場合によっては記述の一問をあきらめて、確実に取れるであろう選択問題を埋めていくというような取捨選択が重要です。

午後問題の出題分野

PM試験午後も傾向があり、頻出分野と比較的出題されない分野があります。
4テーマの中から2テーマを選べばいいわけですし、ある程度学習分野を絞って
限られた時間の中でより得点を取れる可能性をあげていく必要があります。
下記の表のように平成14年度-22年度の過去問題を見るに「品質管理」「人的資源計画」「統合変更管理」は優先的に学習しておく必要があります。

大分類	小分類	出題頻度
プロジェクト統合マネジメント	プロジェクト実行～終結	■
	統合変更管理	■■■
プロジェクトタイムマネジメント	スケジュールコントロール	■■■
プロジェクトコストマネジメント	コストの見積もり・予算化	■
	コントロール	■■■
プロジェクト品質マネジメント	品質管理	■■■
プロジェクト人的資源マネジメント	人的資源計画	■■■
	プロジェクチームの編成～育成■
	プロジェクトチームのマネジメント	■
プロジェクトコミュニケーションマネジメント	コミュニケーション計画～実績報告	■
	ステークホルダーマネジメント	■
プロジェクト調達マネジメント	購入・取得計画～納品者選定	■■
	契約管理～終結	■
	契約の形態とリスク	■■

最後に

午後の問題からは特に時間との勝負になります。
過去問を解く際に大切なのは、「時間内に解けたか」です。時間が限定されると得意分野でも読み落としがあったり、解答のひねり出し時間が足りなくなってきます。かならず過去問を解く際は本番と同じように、ストップウォッチなどで、時間管理をしながら臨みましょう。

参考文献

ポケットスタディプロジェクトマネージャ

情報処理教科書プロジェクトマネージャ

2013-08-07

PM試験午前I対策

試験対策

注意事項

この記事はプロジェクトマネジメントスキルを身につける記事ではありません。
春に行われる某PM試験に対する試験対策です。
午前問題対策に時間をかけず、午後の論述対策の時間を作りましょう。

PM試験午前Iの試験方式

PM試験午前Iは50分間で4択問題30問が出題されます。
午前I合格ラインは6割なので、18問正解する必要があります。

試験対策

午前I免除で受験する。

今から免除資格を得ることはできませんが…
（その他の高度試験を含め、）PM試験は2年以内に応用情報合格、その他高度試験で午前Iパスしていれば、午前I試験は免除で受験することができます。

午前Iを免除すべき理由

午前Iを免除で受けるべき理由は以下のとおりです。

朝ゆっくりできる
午前I免除者のみの試験会場で試験に臨める
午前Iは午前IIに比べて出題範囲が広すぎる。

1.は置いて、2.と3.について言及します。

試験会場について

情報処理試験は申し込みだけして受験しない人、途中であきらめる受験者がよくいます。
PM試験も同様で、途中離脱者が続出します。（いい年したおじさんでも）
免除者のみの会場ならば、ある程度離脱者が少なくモチベーションが保てます。
(それでも最後の時間になると2割くらいの受験者がいなくなっています。)

午前Iの出題範囲について

ここが一番重要です。
下記PDFの17Pの「試験区分別出題分野一覧表」を参照するとわかりますが、午前I試験は共通問題のため、全てのスキル・フレームワーク分野から出題されます。
http://www.jitec.jp/1_13download/youkou_ver1_5.pdf

そのため、午前Iの試験対策を行うためにはかなりの勉強をしなければなりません。
また、午前II以降の出題範囲はPM分野のスキル･フレームワークに絞られるため、その勉強はほとんど意味がありません。
午後の試験対策を行う時間を確保するためにも、午前Iは免除すべきです。

午前I免除無資格で受験する方

とは言え、1月時点で新たに免除資格を得ることは不可能です。
応用情報処理レベルの勉強をすることになります。
午前I試験の出題は共通キャリア・スキルフレームワークのレベル3相当の問題のため、応用情報技術者試験レベルです。

最近ではiOSアプリなどで、試験対策アプリが出ているので、
応用情報技術者向けの試験対策アプリで勉強するのがベストだと思われます。

応用情報技術者午前どこでも問題集2010
https://itunes.apple.com/jp/app/id364250463?mt=8

イベント概要

所感

紹介されていたプラグインetc

進行中の開発プロジェクトで増えていくテストを自動で回し続けるために行ったいくつかのこと

問題点

対策

Jenkinsを利用するときの心構え

１ 自由度が高い

２ プラグインのドキュメントはちゃんと読もう

利用方法の一例

Jenkins + GitHub

検索基盤開発の為の結合テスト環境の自動化

結合テストを自動化した背景

結合テスト自動化の課題と解決策

自動テスト・自動ビルドの前に、既存課題の解決が第一！！

OSSを活用したソフトウェア開発環境構築

pigとJenkinsと私

アメーバピグでのケーススタディ

バッチ制御

オペレーションの自動化

目標

利用ツール

サーバーを構築

BitNami RubyStackの導入。

Redmineを導入する

WordPressを導入する。

Eclipseを導入する

問題

正解

【KeyNote】

【B1 Raspberry Pi NightHacking (Java SE / JavaFXを楽しもう)】

【E2 Java IDE の最新トレンド】

【B3 Groovy, Clojure, Scala, VisageでのJavaFX活用】

【E4 帰ってきたJavaパズラー】

【A5 Java The Night】

注意事項

PM試験午後IIの試験方式

試験に必要なもの

解説

腱鞘炎にならない手？

なぜ筆記用具が二種類必要なのか？

プロジェクトの概要について・注意点

注意点１：PMとしてアサインされた（とする）プロジェクトの特徴を準備する

注意点２：一般的なプロジェクトの特徴を準備する

最後に 求められている解答を書く

参考文献

注意事項

PM試験午後Iの試験方式

試験に必要なテクニック

短時間でプロジェクトの概要と問題を理解する

プロジェクト説明から問題回答に関連する記述をピックアップ

回答候補（発生した状況、リスク・問題・目標、とるべき対応・対策）をイメージする

過去問題から「模範となる対策・原因分析」を学習しておく

文字制限に合った回答を作成する国語力

しっかり全問解答できる時間管理

午後問題の出題分野

最後に

参考文献

注意事項

PM試験午前Iの試験方式

試験対策

午前Iを免除すべき理由

試験会場について

午前Iの出題範囲について

午前I免除無資格で受験する方

１　自由度が高い

２　プラグインのドキュメントはちゃんと読もう

　バッチ制御

最後に求められている解答を書く