Friday, July 29, 2011

JGGUG #17 G*ワークショップ に参加した

JGGUG #17 G*ワークショップ

品川NTTソフトウェアでの開催。
今日のお題は、次の二本。
▶「1.4.0.M1 !? 2.0.0.M1 -更新メモ-」 by 山本剛(ニューキャスト)(tyama)
▶「うさみみとJenkinsとG*な開発環境」 by きょんさん(kyon_mm)

内容が私には難しく、理解ができていません。消化不良気味です。
とはいえ、プログラミングGroovyも出たことですし、勉強をするきっかけにはなったかと思います。多分。
以下はメモです。推測や思い違いも入っています。

▶「1.4.0.M1 !? 2.0.0.M1 -更新メモ-」 by 山本剛(ニューキャスト)(tyama)
"プログラミングGroovy"によれば"GrailsはGroovyの言語特性とDSLを徹底的に駆使したWebアプリケーションフレームワークです。"
もともとはRuby On RailsのJava実装だったが、JavaによるRailsライクなフレームワークに実装方針が変更されてきている。
コンポーネントのバージョンは次のとおり
Groovy 1.8
Sprng 3.1
Servlet 3.0
Tomcat 7
Hibernate 3.6
jQuery
ソースコードはGraidleの使い方の勉強にもなる。一度読んでおくといいらしい。
山本さんの会社では100%Grailsで実装とのこと。
2.0からバイナリプラグインの提供が可能になった。

▶「うさみみとJenkinsとG*な開発環境」 by きょんさん(kyon_mm)
きょんさんの開発環境は
Jenkinsを中心に、いくつかのシステムを組み合わせている。
バグトラッキングシステムにRedmine
バージョン管理システムにMercurial
ビルドするのにGradle
テストコードを書くのにGroovy
テスト対象はJava

Groovyを使うようになったきっかけは三つ
Groovyを「やってみたかった」
自動テストを「やってみたかった」
AntとかMavenわからない

きょんさん曰く「GroovyはJavaというUnix哲学の言語をモダンにラップした言語」
人に便利さを説明する場合に5分かかっていてはだめ、3秒でできることが大事。
Groovyは学習コストが低く、機能を満たすコード量が少ないので、書くのに時間はかからない。

適用範囲はテストコードに限定して使っている。
テストコードをJavaを使って30秒かけて書くよりも、Groovyを使って7秒で書くことが大事。
dump()メソッドは便利
PowerAssert使うときれいな表示でわかりやすい。
テストコードのパッケージングをTDD用、ユニットテスト用、システムテスト用に分ける。
Jenkinsでどうなるかが判断基準。おそらくJenkinsの動作に負担を強いるような構成はとっていないと思われる。

RedmineはBacklogsのために入れているとのこと。
入力項目の多いバグトラッキングシステムは「ゆとり」だから使えない、と仰っていたがおこれは同意できる。必要最低限でいいと思う。SIerは意味のわからないメトリクス値を要求するとのこと。これは確かに閉口だ。

きょんさんはうさみみつけてた。びっくりした。

おまけリンク
20110729_第17回 G*ワークショップ(#jggug )
RedmineのBacklogsプラグインを入れてみた

Thursday, July 28, 2011

JJUG 基礎セミナー HTML5&API入門へ行ってきた

JJUG 基礎セミナー HTML5&API入門へ行ってきました。講師は白石俊平さん。内容は初心者向けのHTML5入門といったところ。
HTML5についてはほとんど知らないのでちょうどいい内容でした。
HTML5&APIを使ったウェブページの表現力の豊かさに圧倒されてきました。
明らかにデスクトップアプリケーションとウェブアプリケーションの距離は縮んでいます。

以下は簡単なメモ。思い込みやうろ覚えも含んでいます。

それまでは文書のプラットフォームであったHTMLは、HTML5によりアプリケーションプラットフォームへと進化した。
狭義にはHTML5はHTML文法とDOMに関する仕様のアップデート
広義ではHTML5にJavaScript, CSS3も含められる場合がある
HTML5には3つの意義がある。

1つ目セマンティックWebとアクセシビリティ
"More Readable for Everyone"
健常者だけでなく全ての人に。
HTML4ではセマンティックの表現が乏しくdiv要素とスタイルシートのクラスで表現していた。
HTML5ではheader要素、footer要素、section要素など文書内の文の意味の表現が可能

2つ目互換性の追求
ブラウザの挙動、表現を同じに。
"Pave the Cowpaths"
HTML4で仕様が無かったり曖昧な部分の実装がブラウザ毎に異なっていた。
HTML5では既存のブラウザの実装から仕様を取り込んだ。
"Write at once, Run any Browser"
IE9の提供は評価できる。これでIE6, IE7, IE8とも決別できる。
Microsoft曰く、"IE6は9年前の腐った牛乳だ"

3つ目Rich Internet Application
canvas要素による表現力の強化
起動時に必要とするリソースを全てダウンロードしておくことで、オフラインでも稼働可能に。これにはローカルのデータベースIndexedDBを使う。
参考サイト Sticky Notes
デバイス固有の機能にアクセス可能。これはスマートフォンを意識した仕様。ただしセキュリティには気を使っている。ユーザの許諾無しにアクセスは不可。
例 GPS、マルチメディアファイル、アドレス帳、バッテリー、マシンの傾き、メール送信
これによりネイティブアプリとの機能差が縮小する。
WebSocketを使った高度なネットワーキング
ゲーム業界が注目 HTTPでシェイクハンド!?
ファイアウォールを超えられる
video要素によりマルチメディアの再生が容易
WebWorkersを使って、バックグラウンドでJavaScriptの処理させることが可能になった

まとめ
HTML5でウェブアプリケーションはバージョンアップする。
セマンティックウェブ、リッチインターネットアプリケーション
HTML5ではオープン標準を利用している(W3C, ECMA, など)ので仕様の互換性が保証される。
ベンダーロックインは無い。
CSS3を策定した人(名前は失念)が策定作業を活版印刷技術になぞらえて、「この先500年使われる技術仕様策定に関われて幸せだ」と言っている。

おまけ(質疑応答から)
ウェブアプリケーションの作り方は変わる。
それまではサーバーサイドで処理させていたが、できることはブラウザ側にやらせるようになる。
プログレッシブエンハンスメントというアプローチ
これは、ターゲットを新しいブラウザに置き、古いブラウザでは最低限の動作を提供する、という考え方
以前はどのブラウザでも同じに見えなきゃだめ、だった。
やっちゃいけないのはUSER_AGENTを使った判定処理。Modernizrを使ってブラウザの実装機能を判定するのがいいらしい。
HTML5によりクロスオリジンリソースシェアリングが可能になった。
それまでもJSONPを使ったハックがあったがあまりいいやり方ではない。

# スクラムマスターを雇う時に聞いてみるとよい47個の質問

  # スクラムマスターを雇う時に聞いてみるとよい47個の質問 スクラムマスターへの質問というPDFがあるので、回答してみた。 定期的に自分の回答がどう変わっていくのか楽しみだ。 Scrum Master Interview Questions: Free Download of...