DVDでアイアンマンを見た。
主人公トニースタークが、捕虜になり脱出のためにリアクターとスーツを開発、
その後、人工知能を搭載した試作機を経て実用機を完成させ、陰謀に立ち向かうストーリー。
ストーリの感想はまた別の機会として(話や役者さんも個人的には満足でした)
スーツの開発を進めていく、エンジニアとしてのアイアンマンがステキだった。
捕虜の環境で開発した最初のスーツは全て手作業。
組み立ても、装着も、ウェポン発動のギミックも全て。
でもスーツを洗練していくのにあわせて、組み立ても装着も自動化されていく。
組み立ては設計をインプットして5時間後に塗装済みのものが用意され、
複雑な装着もロボットアームが的確にこなしていく。
制御の複雑化には人工知能で対応。
音声制御で、主人公は自分の動きに専念する。
プロダクトの洗練において周辺環境含め、常に自動化、省力化を念頭におく。
これ大事だと思う。
そうでなければ、いつまでたったって本質に注力することなんてできない。
それはトニースタークのような天才的な頭脳でなくても、やり方として使っていけることで、
システム開発でもテスト自動化や継続的デリバリーを使って、本質に注力していけたらなと思うのです。
以上、そんなことを考えさせられたアイアンマンでした。
着陸時の姿勢、かわいいですよね、アイアンマンw
2012年8月12日日曜日
2012年8月11日土曜日
SwimmyStudy #9 Jenkins実践入門 vol.3 に行ってきました
8/8(水)にSwimmyStudy #9 Jenkins実践入門 vol.3 に行ってきました。
書籍「Jenkins実践入門 ~ ビルド・テスト・デプロイを自動化する技術」をもとにした勉強会です。
現在、初級者向け、初中級者向けのグループに分かれてそれぞれが書籍ベース、実践ベースで勉強会を行っています。
自分はAndroid開発で利用経験があるので初中級者向けに参加しています。
以下、主に初中級者向けグループに関する参加レポートです。
1. 初中級者向けグループ(JFK)概要
今回は、JFKでの第一回ということで、上記疑似プロジェクトに基づき、バージョン管理システムとJenkins連携部分を検討しました。
2. 初中級者向けグループ(JFK)実施内容
LT
バージョン管理システムとしてGitとgit-flowを採用するにあたり、以下のLTを行い、前提知識を合わせました。
Git, git-flow実践
サンプルシステムを用いながら、git-flowのフィーチャー、リリース作業を複数人で実践しました。
課題
Jenkins連携の検討
前述の課題を踏まえてJenkins連携の検討を行いました。
以下、構成イメージを示す。
次回
次回は、上記構成を実際に検証してみます。
以下の事前準備を行っておけるとベターです。
3. 所感
Jenkinsとの連携までは今回行けませんでしたが、事前準備としては課題等も見え有意義な会だったと思います。
やはり複数人で実際に行うことで見えてくる課題もあり、それらを(業務のタイムリミット関係なしに)検討することができるのが非常によいです。
あっという間の2時間半でした。待ちきれないので次回からスパンを短めにとることになりましたw
次回は8/29(水)です。
SwimmyStudy #10 Jenkins実践入門 vol.4
Jenkins関連のLT大会もあるので、興味ある方はぜひ!
SwimmyStudy #9 Jenkins実践入門 vol.3
書籍「Jenkins実践入門 ~ ビルド・テスト・デプロイを自動化する技術」をもとにした勉強会です。
現在、初級者向け、初中級者向けのグループに分かれてそれぞれが書籍ベース、実践ベースで勉強会を行っています。
自分はAndroid開発で利用経験があるので初中級者向けに参加しています。
以下、主に初中級者向けグループに関する参加レポートです。
- 初中級者向けグループ(JFK)概要
- 初中級者向けグループ(JFK)実施内容
- 所感
1. 初中級者向けグループ(JFK)概要
- Jenkins経験者が中心となって、Jenkinsとバージョン管理、バグ管理のシステムと組み合わせた効果的な開発環境とルールづくりを模索していく。
- バージョン管理には、Gitとgit-flow、バグ管理にはRedmineを想定しており、複数人の開発者と管理者による疑似プロジェクトとして上記環境構築とルールづくりを検討することとする。
- なお、プロジェクト資産は、CakePHPによるサンプルブログシステムを利用する。
今回は、JFKでの第一回ということで、上記疑似プロジェクトに基づき、バージョン管理システムとJenkins連携部分を検討しました。
2. 初中級者向けグループ(JFK)実施内容
LT
バージョン管理システムとしてGitとgit-flowを採用するにあたり、以下のLTを行い、前提知識を合わせました。
ゼロからわかるgit-flow
Git, git-flow実践
サンプルシステムを用いながら、git-flowのフィーチャー、リリース作業を複数人で実践しました。
課題
- プロジェクトで用いるサンプルブログシステムが主にDB周りで起動できなかったため、急遽、簡易的なテキストファイルを対象としたバージョン管理を行うことになった。
[対策]:次回、DBをMySQLからSQLiteに変更して環境依存部分を極力減らす。
- git-flowまわりの経験不足もあり、複数人でのブランチのマージ、コミットで時間を要してしまった。
[対策]:git-flowまわりのノウハウを増やす(参考:Git-Flow-Example)
[対策]:複数人で行う場合の構成を再度検討する必要がある。(後述)
Jenkins連携の検討
前述の課題を踏まえてJenkins連携の検討を行いました。
- origin/developへ各開発者が直接pushを行うと別開発者とのマージが頻発したため、各開発者ごとにoriginとなるリモートリポジトリを設け、中央originへの集約は管理者が行う。
- git-flowのリリースブランチの開始、終了はmasterへの変更が発生するため、管理者が行う。
- 中央originのdevelopをJenkinsと連動させ、結合テストを定期実行させる。
- 中央originのmasterをJenkinsと連動させることを検討したが、masterへのコミット後のテストとなるため、バグがあった場合にmasterブランチを汚してしまう。
回避策としてgit-flowのリリースブランチに対して受け入れテストを実行させる。
テスト完了後、必要に応じてJenkins側からリリースブランチのfinishを行い、masterへのコミットを行う運用とする。
- JFKではリモートリポジトリ間としてGit、リポジトリ間のやりとりにPullRequestを用いる。
以下、構成イメージを示す。
次回
次回は、上記構成を実際に検証してみます。
以下の事前準備を行っておけるとベターです。
- GitHubのアカウント
- 自端末へのGit, git-flowが動作する環境。
- (できれば)サンプルブログアプリ(CakePHP SQLite)の動く環境。
3. 所感
Jenkinsとの連携までは今回行けませんでしたが、事前準備としては課題等も見え有意義な会だったと思います。
やはり複数人で実際に行うことで見えてくる課題もあり、それらを(業務のタイムリミット関係なしに)検討することができるのが非常によいです。
あっという間の2時間半でした。待ちきれないので次回からスパンを短めにとることになりましたw
次回は8/29(水)です。
SwimmyStudy #10 Jenkins実践入門 vol.4
Jenkins関連のLT大会もあるので、興味ある方はぜひ!
2012年8月9日木曜日
Android Night in Fukuoka vol.28 に行ってきました。
8/6(月)にAndroid Night in Fukuoka vol.28 に行ってきました。
今回は、参加者20名ほど。会場のAIP Cafe がものすごい暑くなりながらのNightとなりました。
内容を一応まとめておきます。
1. 宣伝
今回は、以下の勉強会について宣伝がありました。
2. LT
@kenz_firespeedさん
Android 4.1(JellyBeans)の新機能紹介を行っていただきました。
報告内容はご本人のブログにてまとめられています。
4.1では様々な改良が加えられており、性能面でもかなり改善されているみたいなので楽しみです。
個人的には通知エリアの機能拡張が気になったので別途調べてブログにまとめてみたいなと思っています。
詳細は8/18 GDG九州in宮崎にて行うとのことですので、興味ある方は参加してみてはいかがでしょうか。
@monochromegane
自分からは、以前公開した状態保存のライブラリBundleSaver改めStateSaverの紹介を行ってきました。
GitHubのPullRequestをお待ちしておりまーす。
@yuutoさん
支部長からは、Androidで使える軽量なライブラリ(AQuery)の紹介LTがありました。
AQuery
AndroidのUI操作にまつわる各種記述を単純にするためのライブラリ。
IDを指定してビューを取得、値の設定、リスナー設定といった記述をメソッドチェーンで書くことができます。
その他、非同期通信に関しても簡潔に記載できるので、開発工数削減することができそうです。
リスナー設定等、アノテーションを利用しているので性能面は注意が必要とのこと。
ライセンスはApache2.0でした。
いつも楽しげなライブラリを紹介してくれる支部長さんに感謝。
これもまた今度使ってみたいと思います。
@kenz_firespeedさん
本日2度目のLTです。
福岡と世界をつなぐ「Hello World」プロジェクトについての構想を語っていただきました。
こちらも報告内容がご本人のブログにてまとめられています。
昨年、私もアメリカ行きましたが、やはり英語の必要性を痛感しました。
こういったプロジェクトを通じて世界とつながる機会を持っていきたいですね。
3. 所感
固定の顔ぶれも多いですが、毎回、新しい方も参加しています。
最近感じるのは、業務でAndroidを触ったのがきっかけで参加しているかた(Web界隈の方)が増えてきていることでしょうか。それだけ世間に浸透してきたという証拠なのでうれしいことです。
趣味として個人で触っている方が減ってきた気もするので、次回のLTは、個人作成のアプリでも紹介してみようかなと思っているところです。
毎回所感に書いてますが、色んな人に知り合えるので、情報交換、収集の場にちょうど良い会です。
ここからネットワークが広がることが多いので興味のあるかたは是非参加してみてください。
-----------------------------
次回、Android Night in Fukuoka vol.29 は、9月初旬のはずです。
興味湧いた方は、お気軽にどうぞ!
ではでは。
Android Night in Fukuoka vol.28
今回は、参加者20名ほど。会場のAIP Cafe がものすごい暑くなりながらのNightとなりました。
内容を一応まとめておきます。
- 宣伝
- LT
- 所感
1. 宣伝
今回は、以下の勉強会について宣伝がありました。
- 日程調整中 初心者勉強会
- 8/25(土)Android ドM(次回ペアプロ)
- 毎週月曜日 輪講する会(Andorid高速化プログラミングの輪講)
2. LT
@kenz_firespeedさん
Android 4.1(JellyBeans)の新機能紹介を行っていただきました。
報告内容はご本人のブログにてまとめられています。
Android Nightに参加してきました
4.1では様々な改良が加えられており、性能面でもかなり改善されているみたいなので楽しみです。
個人的には通知エリアの機能拡張が気になったので別途調べてブログにまとめてみたいなと思っています。
詳細は8/18 GDG九州in宮崎にて行うとのことですので、興味ある方は参加してみてはいかがでしょうか。
@monochromegane
自分からは、以前公開した状態保存のライブラリBundleSaver改めStateSaverの紹介を行ってきました。
振る舞いのよいAndroidアプリのために。BundleSaver。
続・振る舞いのよいAndroidアプリのために。StateSaver。
GitHub / monochromegane / BundleSaver
GitHubのPullRequestをお待ちしておりまーす。
@yuutoさん
支部長からは、Androidで使える軽量なライブラリ(AQuery)の紹介LTがありました。
AQuery
AndroidのUI操作にまつわる各種記述を単純にするためのライブラリ。
IDを指定してビューを取得、値の設定、リスナー設定といった記述をメソッドチェーンで書くことができます。
その他、非同期通信に関しても簡潔に記載できるので、開発工数削減することができそうです。
リスナー設定等、アノテーションを利用しているので性能面は注意が必要とのこと。
ライセンスはApache2.0でした。
いつも楽しげなライブラリを紹介してくれる支部長さんに感謝。
これもまた今度使ってみたいと思います。
@kenz_firespeedさん
本日2度目のLTです。
福岡と世界をつなぐ「Hello World」プロジェクトについての構想を語っていただきました。
こちらも報告内容がご本人のブログにてまとめられています。
Android Nightに参加してきました
昨年、私もアメリカ行きましたが、やはり英語の必要性を痛感しました。
こういったプロジェクトを通じて世界とつながる機会を持っていきたいですね。
3. 所感
固定の顔ぶれも多いですが、毎回、新しい方も参加しています。
最近感じるのは、業務でAndroidを触ったのがきっかけで参加しているかた(Web界隈の方)が増えてきていることでしょうか。それだけ世間に浸透してきたという証拠なのでうれしいことです。
趣味として個人で触っている方が減ってきた気もするので、次回のLTは、個人作成のアプリでも紹介してみようかなと思っているところです。
毎回所感に書いてますが、色んな人に知り合えるので、情報交換、収集の場にちょうど良い会です。
ここからネットワークが広がることが多いので興味のあるかたは是非参加してみてください。
-----------------------------
次回、Android Night in Fukuoka vol.29 は、9月初旬のはずです。
興味湧いた方は、お気軽にどうぞ!
ではでは。
2012年8月6日月曜日
SQLiteの高速化:クエリのトランザクションは本当に有効か測定してみた
書籍「Androidアプリ高速化プログラミング」の輪講会に参加しています。
Androidアプリ高速化プログラミング
先日の第1章の輪読の際に、クエリの高速化の項で気になった点があったので検証を行ってみました。
1. 書籍の主張:クエリの高速化
気になった記述は、以下の箇所です。
第1章 Javaコードの最適化 (P.36) 1.7.3 クエリ
2. 書籍の主張:推論
上記、書籍の主張ですが、輪読会でも全レコードを一括で取得するクエリに対して、「すべての行を1つのトランザクションにまとめると」というのがイメージがつかないよねーという話になりました。
推論1:
一回のクエリでもトランザクションを制御することで処理速度が向上する(そんなバカな)
推論2:
Selectクエリでもトランザクションが開始、終了しており、複数回のクエリをひとつのトランザクションにまとめることで処理速度が向上する。
以下、各推論に対して処理速度の計測を行ってみました。
3. 性能測定してみる(条件など)
以下の条件でクエリの性能測定を行ってみました。
環境
Android:2.3.3
機種:エミュレータ
テーブル構造
テーブル名:cheese ※世界のチーズ一覧を格納します。
レコード数:650件
測定パターン
いずれも全件に対するクエリを発行。
取得対象のカラムと、トランザクション制御の違いを検証します。
4. 性能測定してみた
全レコードを一括で取得
全レコードを一括で取得(Where句なしのSelect文)では、トランザクション制御を手動で行った場合のほうが、処理時間が長くなってしまいました。
いずれもクエリ回数は一回であるため、トランザクションを操作するオーバヘッドが差につながったのではないかと推測されます。
推論1は、あえなく崩れました。
それでは、書籍のトランザクションをまとめて扱うとはどういうことなのでしょうか。
おそらく、下記のパターン(推論2)のことを言っているのではないでしょうか。
全レコードを個別に取得
全レコードを個別に取得(Where句にIDを指定し、レコード数だけループで全件取得)では、トランザクション制御をループの前後のみで行った場合のほうが処理時間が短くなりました。
このことからSelect文を複数発行する場合、ひとつのトランザクションとして扱ってあげるほうが性能の向上が見込めることがわかります。
ただし、処理時間自体は、クエリの回数が増えているため、一括で取得する場合に比べて大幅に増加してしまっています。
書籍のような7ミリ秒での実行からは離れてしまいました。
5. まとめ(?)
複数回のクエリに対してトランザクションをまとめることが処理性能に有効だということは確認できました。
ただし、検証の結果、ますます書籍の言っていることがわからなくなってしまうという情けない結果になってしまいました。とほほ…。
書籍でいうような処理速度改善の方法があればアプリに適用したいのですが…。
検証結果、書籍の内容について、アドバイス等いただければ幸いです。
6. 参考(計測に利用したクラス)
性能測定で利用したクラスです。
これらのTaskを別途準備した計測用のクラスに渡して計測を行いました。
こういう計測を行ったほうが効果的だよというのがあればご指摘もらえればと思います。
以上です。
Androidアプリ高速化プログラミング
先日の第1章の輪読の際に、クエリの高速化の項で気になった点があったので検証を行ってみました。
- 書籍の主張:クエリの高速化
- 書籍の主張:推論
- 性能測定してみる(条件など)
- 性能測定してみた
- まとめ(?)
- 参考(計測に利用したクラス)
1. 書籍の主張:クエリの高速化
気になった記述は、以下の箇所です。
第1章 Javaコードの最適化 (P.36) 1.7.3 クエリ
複数のトランザクションを使う場合、iterateBothColumns()は61ミリ秒かかるが、iterateFirstColumn()は23ミリ秒で実行される。すべての行を1つのトランザクションにまとめると、すべての行の処理にかかる時間はさらに短くなる。iterateBothColumns()は11ミリ秒かかるが、iterateFirstColumn()は7ミリ秒で実行される。iterateXXColumn()は、SQLiteデータベースに対してクエリを発行するメソッドであり、それぞれ、カラムを指定しない場合、する場合で処理速度に差が発生するという内容なのですが、それに対する説明で、「すべての行を1つのトランザクションにまとめると」という記載があり、性能がさらに改善する上記の記述があります。
2. 書籍の主張:推論
上記、書籍の主張ですが、輪読会でも全レコードを一括で取得するクエリに対して、「すべての行を1つのトランザクションにまとめると」というのがイメージがつかないよねーという話になりました。
推論1:
一回のクエリでもトランザクションを制御することで処理速度が向上する(そんなバカな)
推論2:
Selectクエリでもトランザクションが開始、終了しており、複数回のクエリをひとつのトランザクションにまとめることで処理速度が向上する。
以下、各推論に対して処理速度の計測を行ってみました。
3. 性能測定してみる(条件など)
以下の条件でクエリの性能測定を行ってみました。
環境
Android:2.3.3
機種:エミュレータ
テーブル構造
テーブル名:cheese ※世界のチーズ一覧を格納します。
レコード数:650件
カラム名 | 型 |
---|---|
id | INTEGER ※インデックスカラム |
name | TEXT |
origin | TEXT |
測定パターン
いずれも全件に対するクエリを発行。
取得対象のカラムと、トランザクション制御の違いを検証します。
取得方法 | トランザクション制御 |
---|---|
全レコード(一括) | AutoCommitあり |
全レコード(一括) | AutoCommitなし |
各レコード | AutoCommitあり |
各レコード | AutoComitなし |
4. 性能測定してみた
全レコードを一括で取得
全レコードを一括で取得(Where句なしのSelect文)では、トランザクション制御を手動で行った場合のほうが、処理時間が長くなってしまいました。
いずれもクエリ回数は一回であるため、トランザクションを操作するオーバヘッドが差につながったのではないかと推測されます。
推論1は、あえなく崩れました。
それでは、書籍のトランザクションをまとめて扱うとはどういうことなのでしょうか。
おそらく、下記のパターン(推論2)のことを言っているのではないでしょうか。
全レコードを個別に取得
全レコードを個別に取得(Where句にIDを指定し、レコード数だけループで全件取得)では、トランザクション制御をループの前後のみで行った場合のほうが処理時間が短くなりました。
このことからSelect文を複数発行する場合、ひとつのトランザクションとして扱ってあげるほうが性能の向上が見込めることがわかります。
ただし、処理時間自体は、クエリの回数が増えているため、一括で取得する場合に比べて大幅に増加してしまっています。
書籍のような7ミリ秒での実行からは離れてしまいました。
5. まとめ(?)
複数回のクエリに対してトランザクションをまとめることが処理性能に有効だということは確認できました。
ただし、検証の結果、ますます書籍の言っていることがわからなくなってしまうという情けない結果になってしまいました。とほほ…。
書籍でいうような処理速度改善の方法があればアプリに適用したいのですが…。
検証結果、書籍の内容について、アドバイス等いただければ幸いです。
6. 参考(計測に利用したクラス)
性能測定で利用したクラスです。
これらのTaskを別途準備した計測用のクラスに渡して計測を行いました。
こういう計測を行ったほうが効果的だよというのがあればご指摘もらえればと思います。
以上です。
登録:
投稿 (Atom)