読者です 読者をやめる 読者になる 読者になる

気の向くままに書き綴る

勉強会参加したメモや日々の思ったことのメモ等

JTF2013: July Tech Festa参加してきた

JTF2013: July Tech Festa 2013
コードの中のインフラ 
Infrastructure as Programming

JTF2013

当日の2時頃?に申し込んで行って来ました

インフラのイベントの参加は初めてかも。

 

少し前のDevsumiは、

全体的のイメージで

Developerは、テスト自動化してコード規約のチェックも自動化

InfrastructureやOperatorは、気合で乗り切る

的な印象をうけていたけど

 

今回JTF2013に参加してInfrastructure・Operatorの印象が変わりました。

流れ的にChefやらPuppetでどんどんインフラの自動化進んできて、

serverspecで自動テストがきてーっとどんどんDeveloperに近づいている印象をうけた。

そのうちserverspecでセキュリティのチェック、社内基準のチェックの自動化、パッケージのインストールテストとかで使われていくんだろうなぁって思いましたー。

 

各セッションのメモ

--

OP
基調講演
A01: Treasure Dataのクラウド戦略

http://www.slideshare.net/treasure-data/treasure-data-cloud-strategy

 

 


連携するシステムは、疎結合であることが必要。 キューを使っておけば、不整合発生時のデータ復元も比較的簡単にできちゃうよ。

http://fb.me/36La3wgc9

AWSは、RDS、S3、EC2、ELBを使っている。EBSはデータが化ける。SQSはトランザクションが無い。EMRはストロングポイントで無い。から使っていない。

 

--

A10: Jenkinsで始める継続的デリバリーと実践の道程

 

プロジェクトA 超大規模案件 

期間:2年10ヶ月 

人数:1200人(ピーク時) 

規模:4MStep

開発言語:Java

開発プロセスウォーターフォール 

結合テストから使い始めた
 テストは手動
 一日4回のデプロイ


■プロジェクトZ 小規模案件(というか、自担当)

期間:5年

人数:5名(ピーク時15名)

開発言語:Python等 

内容:OSSを組み合わせてソリューション展開

Trac

Subversion

Jenkins SeleniumWebdriver(2.0)を使用

 

参考文献

 

−−

A20: ユーザエクスペリエンス・デザイン・ガイド
株式会社コンセント 坂田さん

 
カメラは一番iPhoneが一番普及している
なぜか?
カメラに新しい付加価値
→写真を加工する
→写真を記憶共有する

・ものからことへデザインされている
・問題発見から問題解決へ
・製品中心から顧客中心へ

UXDはニーズを満たす+所有する楽しさ、使用する楽しさ

5W1Hを考えることがUCD・HCD
いつ どこで だれが 何を なぜ どのように

ペルソナによる対象人物を作る
根幹を作ってブレないようにする

シナリオのビジュアライゼーション
http://sprmario.hatenablog.jp/entry/20110908/1315492018
http://www.slideshare.net/vistawalk/userexperiencemap


次にペルソナの作り方。最低限、名前と写真、特徴、欲求と不満があればよい。

ストーリーボードの作り方。最低限、 時間と場所とステークホルダー

ユーザビリティテストの作り方。シナリオの評価(シナリオ)、サイト構造の評価(導線)、画面構成の評価(各画面の構成)。
画面モックでもユーザビリティテストは実施すべき。
→まずはどこに向かっていくかを共有してから進めていくべき
→どうやって、つくる?

→なにを、つくる?
→なぜ、つくる?
→誰のために、つくる?

 

---

A30: serverspec: Chef/Puppetと一緒に使うサーバテストのためのテスティングフレームワーク


→サーバのSystemConfigurationTestTool
serverspecの使い方
gem install serverspec rake
serverspec-init
rake spec
vim spec/spec_helper.rb
spec/localhost/httpd_spec.rb
rake specテスト実行

Chefで更新が多い場合、ServerSpecが必要になる
既存ツールは機能が多すぎたり、特定のツールに依存してたりするのがイヤ
既存ツールに依存しない。テストコードが簡単。テストエージェントが必要なし
テスト以外のユースケースなし!
利用のための敷居が低い

serverspecの応用例
Jenkinsを使ってサーバ構築の継続的インテグレーション→Chef更新したらテスト開始
UkigumoっていうCIツールがあるらしい

宮下さん:まとめ:
・読みやすい、書きやすい、わかりやすい
→以下にそぎ落とすかを気をつけて開発している
・簡潔さは重要
→ビジネス要件は絶えず変化していく。それに伴いシステムも複雑に。継続的なテストが重要。

 

それ以外のセッション資料または参考文献

http://www.slideshare.net/sfunai/jtf13-oss-130710

http://www.slideshare.net/samemoon/20130714julytechfesta

https://speakerdeck.com/yasuhiro/git-falsewakuhurotoakuteibitei

http://www.slideshare.net/yushen/20130714-eucalyptus-habuka036?utm_source=ss&utm_medium=upload&utm_campaign=quick-view

http://www.slideshare.net/namikawa/devsumi2012-pigglife-chef

http://tily.github.io/jtf2013/#43_mysqld_

http://www.creationline.com/category/lab

http://www.slideshare.net/KatokichiSoft/git-flow-16616440

http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

http://inoccu.net/blog/2012/11/27/081021.html