2010年3月11日木曜日

devfest2010にボランティアとして参加してきた

Googleがクイズを出したことにより話題になったDevfest2010にボランティアスタッフとして参加してきました。

2月中旬に開催が発表されて、仮登録を済ませた同時ぐらいに、ボランティア募集のメールがボランティアに流れたので、とりあえず応募。
すんなり受け入れてもらい、ボランティアスタッフとして参加することが決まりました。
ちなみにクイズは暗号までやったのですが、なんやかんやで漢字とパッチワークはサボっちゃいました。上記2点を正解できてれば、ボーダラインの点数は超えられていたんですが。

で。3月3日の夜に顔合わせと簡単な説明。前日の3月10日にも下見を兼ねて受付トレーニング。
そして当日を迎えました。

結局、受付のシミュレーションらしいことはできずに本番になったわけですが、特に問題もなく繁盛期を超えられました。
世界初?のQRコード認証とペアリングの方式らしいですが、トラブルもなく、300人をサクっと捌いちゃいましたね。
突貫で作ったアプリとシステムだったそうですが。さすがという感じで。

受付担当意外の時間は自由時間だったので基調講演の後半(及川さんと石原さん)とHTML5(白石さんと波多野さん)を聞くことができました。
最後のLTも前半は聞けたのですが、DevfestQuizの解答が聞けなかったのが残念。

受付やってて、入り口で知り合いと顔を合わすことができたり、スタッフなんで裏から開場にはいれて、関係者席に座れたりなどの特典も。
また、過去に一回程度ですがお話させていただいたGoogleの北村さんや佐藤さんとまたお話ができたり、受付担当だった吉野さんと話込めたり。
ディぺスさんとも何度もお話できましたし。

とにかくエキサイティングな一日でした。
残念なのは、前日の夜から風邪のせいで声がガラガラになったこと。
受付業務もこなせましたが、聞きづらかっただろうなぁ
せっかく来場された方にご迷惑をお掛けしたかも。すみません。

会場準備のメジャーズの皆様や、ボランティアのGoogler & APIExpert & 一般ボランティア皆様、本当にありがとうございました。
またお会いできる日を楽しみにしてます!

#緊張がきれたのか、終わった途端、風邪が進行した。明日も会社を休むわけにはいかないのでがんばる。

2010年2月28日日曜日

オープンソースカンファレンス2010 Spring 二日目

明星大学 日野キャンパスで行われた、オープンソースカンファレンス2010 springに参加してきました。
27日(二日目)にShibuya.tracのコミュニティで参加です。

ブースの配置が春の時とは違い、部屋の真ん中の島。
スペースは長机一つ分で、お客さんと向かい合う形はNG。
正直、これで数時間お客さんを向かい入れるのはしんどかったですねぇ。
秋はよかった。

そんなことはともかく、展示時間が始まるとちょこちょことブースに人が訪れました。
秋の時と同様に、
  1. ブース前に興味ある人が立ち止まる。
  2. チラシ渡しながら「Trac使ってますか?」と声かける。
  3. 「使ってる人」はここで「悩み、要望、希望」を話してくるので、座らせる。
  4. 「興味ある人」は取り合えず画面見せて「プロジェクトでどんなお悩みですが?」と聞く。
  5. 「知らない人」はチラシで説明して興味もったら画面を見てもらう。
の流れ。

今回も「以前・現在使ってる人」が一番多かったと思いますが、みな使ってる機能が偏っているのが印象的でした。
SVNだけ使ってる、チケットをTodo替わりに使っている。等々。

全体的にブースにきた人数は秋の時程ではない気がしましたが、訪れる人の情熱は変わらずっと言う感じ。相変わらずRedmineと比べてくる人もいますね。

みんな悩んだ末にツールを探し辿りついているという感じがあるのですが、ツールで解決する問題ではないことを理解して欲しい。
だからといってXPだAgileだScrumだといきなりススメてもしんどいと思われ。
余計なお世話にならない程度に説明するように心がけました。

印象に残ったのは、Oかもとさんと長く話し込んでいたお姉さんと、中国語版のTracLightningを希望した中国の方でしょうか。

待っている時間等は、相変わらずOかもとさん、かぬさん、Ryuzeeさんから勉強させてもらったり、kaorunさんと悩み相談したり。
新たな出会いもあり、楽しい一日でした。
スタッフの皆様、お疲れ様でした。
ご来場いただきました皆様もありがとうございました。


2010年2月19日金曜日

デブサミ2010 二日目にいってきた。

デブサミ2010にいっていきました。
メモ移しておきます。

●これからのアーキテクチャを見通す
鈴木雄介 [19-C-1] スライド
パラダイムシフトは起きる。なにかを得るには何かを失うことがある。
いかに長く使ってもらえるものを作るか。
オブジェクト指向、アジャイルなプロセスも優秀な手法だがそれだけでは難しい。
動的平衡にはエネルギーを与え続けることが必要。
これからのアーキテクチャはモジュールとプラットフォーム。
プロセスとアーキテクチャは補完しあう。

何かを得れば、何かを失う。そして何も失わずに次のものを手にいれることはできない
− 開高健
-- メモここまで --
遅刻したので最初の方の話は聞けなかったのですが、後半のプロセスとアーキテクチャの補完しあうことに関しては激しく同意で、偏ってはいけない。
また、次のものを得るための自分がなにをしているか、どこに立っているかを問われ、正直どきっとした。少なくてもすでに飛び込んで次を待っている状態ではない。
というか、おそらく傍観している人なんだろう。ぐう。

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス
IBM 玉川憲[19-B-2] (資料
ストーリー 柔軟な「要求」の表現
タスクストーリーを細かくしたもの

開発プロセスの対比
WF
要求=スコープ(固定)→リソースと期日が見積もられる
アジャイル
リソースと期日(固定)→要求を見積もる

アジャイルはもともと10人以下のチーム向き
大規模を扱う企業で真剣に考慮されない傾向があった。
そんなことはない。大規模には実際不向きなプラクティスもあるのは事実。

14のプラクティス
  1. 定義・構築・テストのコンポーネントチーム
  2. レベル計画づくりと追跡
    荒いリリース計画と詳細な反復計画を用いて計画づくりとトラッキングを行う
  3. コンカレントテスト
    すべてテストされている
  4. 継続的インテグレーション
  5. 反復ごとの「ふりかえり」の実施
    定期的間隔でチームはより効率を高めるためにどうするかを考察し、やり方を改善する
  6. 意図的なアーキテクチャ
    自然出現するアーキテクチャもあるけど
  7. リーン要求開発
    素早いコーディングにより形式的な仕様書を避ける
    大規模な場合、共通な要求は前倒しで持っておくべき
    ビジョン(開発構想書)
    ロードマップ
  8. 高度に分散した開発の管理
    ツールの使用とより組織的なアプローチが必要
    各チームはデイリーミーティング
    PMCは週二回のミーティング
  9. アジャイル・リリーストレイン
    リリースを固定され遅らせることのできないスケジュールと考える。
    時間通りに発射する電車のようにリリースを考える。
    リリース・テーマ・品質を守る。
    落とすべきは機能・要求
  10. 顧客とオペレーションへのインパクトへの調整
    リリース情報を垂れ流す。
  11. 組織を変化をさせる。
    ・ボトムアップアプローチ
     それなりの効果はある。
    ・トップダウンアプローチ
     エバンジェリストが必要。
     スポンサーが必要。
  12. ビジネスパフォーマンスを計測する
    横串の情報を上位マネージャに提示できる。
-- メモここまで --
 あれ、2個足りない・・・
 スライドでたら補完する。
 いくつかは初めてキーワードだったが違和感なく、楽しく聞くことができた。
 RTCの宣伝的な部分が多くあったが、実際にいいPJ管理ツールだと思う。
 玉川さんの話を聞くのは2回目なのですが、やっぱり良い講演でした!

● 三周遅れのXP -僕とドワンゴのXP- (資料
ドワンゴ 庄司嘉織【19-B-3】
XPは今、3周目。
1週目はケントベック。
2週目 角谷信太郎。
3周目は僕ら。(※3週目なら2周遅れだよね)
「車輪の再発明」をしないと心がけるべき。しなきゃダメだという人は老害。知る必要性はない。
僕らは「高速道路の設置」をするべきだ。

4つの価値
コミュニケーション
シンプルさ
フィードバック
勇気 → 「勇気」を出しやすい状況を作ることが大事
おやつ神社
気軽に食べれるところがある→XPのプラクティスにある、みんなが集まって話せる場を作る。

TDDの師匠は「角谷信太郎」「和田卓人」
 TDDはTestDrive【Deverpment】つまり開発手法。
 TDDはまず動くものを作り、綺麗にしていく。
 綺麗なソースを最初から書いてもダメだと思う。
 ・自分の解決すべき問題を小さく明白に
 ・すぐにテスト
 ・開発するためにテストを書く
何度も繰り返しそこで得た知見を即反映 → 宮本武蔵 五輪の書
 ・不安をテストする
 ・開発のためのテストであって、品質のためのテストではない。
 ・WebDBPress Vol35を社内で写経会。

ペアプロ
コードの共有。
コードの指摘を人格批判ではない。
新人にブログを書かせているし、返信もブログでトラバ。

CI
最低でも一日一回
   → 少ない
 → 5分に一回まわした。
 → スローテスト問題発生。
いま3時間かかる。
 
見積りと計画
アジャイルな見積と計画づくりを嫁。
ユーザーストーリの作成
  プランニングポーカー
→ ストーリーポイント計測
    → 繰り返すことにより見積もりができるようになる。
一年間で処理できるストーリーポイントとかがわかる
スマイル動画もBacklogを利用している
ホワイトボードに付箋に貼って進捗状況ごとに移動させる。
Tracにも書いてるけどね

  バーンダウンチャート
 突発に発生した作業時間も記入、(右上がりで表記)。
 正直に書く。FF13の発売とか。→ 次からDQ、FF発売も見積りに入れる。

現実がXP、アジャイルに対応できないなら、それをどうやったら対応できるかを考えるのもXP、アジャイル的に考える。

Don't repeat yourself
 DB→Excel、Excel→DB
 Tracから日報
 Tracのマイルストーン一括移動
 IRCの利用
大きなものを把握できるように小さく分けよう。
XP導入がむずかしいのなら個人で行い、波及させる。
チームにやってもらうようにする。
会社にやってもらう。
XP is about social change. 自分が変わることがXP
-- メモここまで --

空き時間だったので飛び込みで入った割には、今回1〜2番の良い話が聞けた。
いろいろと自分に言い聞かせなくちゃいけない内容であった。
それとともに羨ましく思った。そんな自分がくやしい。
あとやっぱりジョジョを読み返さなくてはならないと思う。

●〇〇◯
 つまんなかったので割愛。

Google 日本語入力を支える情報処理技術
グーグル株式会社 工藤拓 19-C-5
GoogleIMEの内部設計
 多くのコンポーネントで構成されていて複雑。
  ローマ字変換、キーバインディング、スペルチェック(おんあのこ→おんなのこ)
  などなど(※メモれないほどいっぱい)

DLLとしての実装の話
OSの制約、辞書はDLLから共有リソースとされる
・絶対クラッシュしてはならない【大事なことなので3回言う】
・絶対セキュリティホールがあってはならない
発想の転換
クラッシュしても良くしよう。
セキュリティホールがあっても良くしよう。
プロセス間通信(IPC)を利用。
旧のIMと違い、IMDLLはStateless化した。
すべての処理は変換エンジンに渡す。
IMDLLの役割
アプリケーションからきたキーイベントをほぼそのまま変換エンジンに送る。
   変換エンジンプロセスが死んでもユーザには影響がでない。
  4秒ごとに殺しても平気。
  リブート不要の自動アップデートが可能

セキュリティの保護
設計まとめ
クラッシュ、セキュリティは陶然とする
クリティカルな状況でも問題ないようにする

辞書の話
インターネットからクロールして辞書を作成する
ウェブからの特徴的な・高頻度で出現する単語・フレーズを抽出する
データの持ち方
   Key-value Storeで実現可能か? → No
 圧縮率が良くない
 一般にexact mache ができない。
 TRIEでしてる
 LOUDS
TRIEのなかでも持っtもスペース効率がよい実装方法
そんなに早くない
 ハフマン圧縮を利用
 辞書は変換エンジンに埋め込まれていて、ファイルサイズは34MBぐらいに収まってる!
理由
辞書のアップデータの複雑性回避
利点:辞書が壊れない。辞書とエンジンの更新作業がアトミックにに行える。
     変換アルゴリズム・圧縮アルゴリズムを日々改善できる。
   辞書フォーマットをきにしなくていい
   頻繁にアップデートができる
辞書の領域のアロケーションをOSにまかせられる
  パフォーマンス低下の要因
 相反するフィードバックがあつまった
 早い←→遅い
 なぜか
エンジンがメモリに乗れば高速に動作
遅い環境ではページフォルトが多発(スワップ)
XP:ページフォワード優先ページング
裏で動くアプリは待避されやすい。
Vista:利用履歴に基づくページング。
XPの解決策
サービスでキャッシュサービスを動かす。
まとめ
IMは複雑なソフトウェア
多くのコンポーネントで構成される
それでいてクラッシュやセキュリティーホールがあってはならない。
機能分離・マルチプロセスアーキテクチャ
Statlessなプロトコル
Playback機能
セキュリティ保護
Googleらしい辞書
Webから辞書作成
ケタ違いの語彙・圧縮率
実行ファイルに辞書を埋込
-- メモここまで --
 とにかく圧巻。Googleの技術力を見せつけられた。
 特別新しい技術の塊というわけではなく、地道に調査研究して、試行錯誤した結果がこうなりました。という感じ。
 個人的に利用していますが、まだ某IMEの方が使ってて気持ちいいと思う。
 けど、今回の話しを聞いて期待せざる得ない。

●次世代Web標準 HTML5 最新動向【19-B-7】
 MITSUE-Links 矢倉眞隆 スライド
 HTML5全体の話。
  HTML5は広義の名称であるが、CSS3や各APIはHTML5と総称して呼ばずに各API名で呼んで欲しい。
  過去の互換性を保ちつつ、新しいことを取り込んでいく。
マークアップ
互換性をとりつつ、定型句はシンプルになった。
Form について。
API
一通り全部紹介してました。
 白石俊平
  未来予想図 − WebMessage
 WebWorkersは革命的。UIを邪魔しない。
    UI層とBL層をつなぐ役目を担うようになる。
    web-messaging-rpc の開発。コミッタ募集。
      
 有限会社futomi 羽田野太巳 (本人BLOG)(資料
  HTML5を利用したサイトの紹介
小松健作さん
WebSocketsを利用したマッシュアップの披露。
      以前作成された食べログのマッシュアップをWebsocketに乗せたやつだと思う。
      たしかにWebSocketを使ったものは世界初なのではないだろうか。
竹迫良範さん
FileAPI
Webアプリだけど、クライアントだけでZipしてくれる。
      こりゃいい。わけわからんけど。
FireFoxだけyieldを使える。
上山智士さん
Gyuque

-- メモここまで --
いつもHTML5の勉強会に出させていただいているせいか、特別目新しい情報はなかったのですが、あのような場面で聞くのも感慨深いものがありました。
竹迫さんや上山さんのデモも面白くて新鮮でした。

2010年2月16日火曜日

JavaのCalendarのsetTimeZone

上のテストがNGで下がOK。
下のソースは上のソースに System.outを追加しただけ。
なんでsetTimeZoneでupdateTimeしないで、getでupdateTimeするんだろ。
直感的じゃないなぁ
おかげではまってしまった。
/**
* NG
*/
public void testSetTimeZoneOnGMT(){
Calendar gmt = new GregorianCalendar(1970,1-1, 1,0,0,0);
gmt.setTimeZone(TimeZone.getTimeZone("GMT"));
assertEquals(gmt.get(Calendar.HOUR_OF_DAY), 15);
}

/**
* OK
*/
public void testSetTimeZoneOnGMT(){
Calendar gmt = new GregorianCalendar(1970,1-1, 1,0,0,0);

System.out.println(gmt.get(Calendar.HOUR_OF_DAY) );

gmt.setTimeZone(TimeZone.getTimeZone("GMT"));
assertEquals(gmt.get(Calendar.HOUR_OF_DAY), 15);
}


Tracのデザイン

TracLightningをバージョンアップしたことにより、Themeプラグインが有効になり、簡単にデザインがカスタマイズできるようになりました。

そこで、簡単にデコレーションしてみました。
方法としては、TRAC_ADMINを持っているユーザでログインして管理画面に。
左のメニューからTheme > Customize:Advancedを選択すると、スタイルシートを入力するテキストエリアがでてくるので、好きなようにスタイルシートを記入しましょう。

サンプルとして、私は以下を記入してみました。
h1 {
border-left: 9px solid #ad2021;
margin-bottom: 0px;
padding-left: 0.5em;
font-size: 120%;
font-weight: bold;
margin-top: 2%;
user agent stylesheet
display: block;
margin: 1em 0px;
}

h2 {
border-bottom: 1px solid #ad2021;
border-left: 5px solid #ad2021;
font-size: 14px;
font-weight: bold;
margin: 0.6em 10% 0px 0.4em;
padding: 0px 0.5em 0.1em;
}

h3 {
border-bottom: 1px solid #ad2021;
font-size: 12px;
font-weight: bold;
margin: 0.6em 10% 0px 0.4em;
padding: 0px 0.5em 0.1em;
}
すると以下のような表示になりました。



h4もつかう人は設定するといいと思いますが、とりあえず。

2010年2月15日月曜日

会社のTracをバージョンアップ

ここ1年懸念してた、会社のTracをやっとこさバージョンアップしました。

とはいえTracLightningなんで、お手軽お気楽なんですけどね。

いままではTracLightning2.2だったところを2.4.2にあげました。
週末の誰もいないであろう時間帯に会社にVPNでつないで作業。

2.2のサービスを落としてからアンインストールして、2.4.2のインストーラーを実行。
特別なにごともなく、バージョンアップできました。
相変わらずすばらしい下位互換。

とおもったら、デフォのtrac.iniを保存しておくの忘れていて、共通に設定してたやつが、全部消えちゃった。
ファイルは以下のファイル。
C:\TracLight\python\share\trac\conf\trac.ini
とはいえ、たいした設定はなかったのですが、影響はでかいので再度設定。
設定しなおした値は、以下の2点。

  • チケットの開始日と終了日を入力するカスタムフィールド
[ticket-custom]
due_assign = text
due_assign.label = 開始予定日
due_assign.order = 1
due_close= text
due_close.label = 終了予定日
due_close.order = 2
complete= text
complete.label = 進捗率(%)
complete.order = 3
  • チケットの変更をメールで送信させるための、共通の設定。
[notification]
admit_domains = hoge.co.jp
always_notify_owner = true
always_notify_reporter = true
smtp_enabled = true
smtp_from_name = Trac
smtp_server = postman.hoge.co.jp

以上で現状問題ありません。

2.2からだとjavascriptも最適してくれているので、表示が速くなったとまずまずの評判です。
個人的にはTraMも気に入っているのですが、以前の一覧になっているのが良いという声もあって悩み中。
たしかにウチの場合、WikiとSCMとしてしか主に利用されていないので恩恵はかなり薄いんですよね。
もったいないけど、自分の伝え方にも問題あることは認識していますです。ハイ。

2010年2月8日月曜日

サイトデザインについて

先日のスケッチボード法にてターゲットとなったサイトデザインなのですが、前回の参加者が再度収集してる時間と場所がなかったので、既存のラフをA4用紙6枚程度にプリントアウトして、各メンバーに廻して付箋でツッコミを入れてもらう形式にした。

デザイナの主メンバの方に最初に記入してもらい、一人ひとりに廻してもらいました。

前回のミーティングの意識が強いのか、「みんなで作り上げる」感覚が共有できてるようで、
比較的すんなりと理解および、記入をしてもらうことができた。

最後にデザイナの方の手元にきてまとめていました。
直接ヒアリングしたら上々の評価でしたが、本音かどうかわかりません。

本当にやりたかったプラクティスは以下に
  1. 2チームに分かれる
  2. チーム別にラフデザインを大きめの紙にプリントアウトして壁に貼る。
  3. いっせいにツッコミを付箋に書いて貼る。
  4. チーム内で各自のツッコミを説明したりして集約・ブラッシュアップする。
  5. 説明者残して、ほかのメンバーをチーム間でスワップ。
  6. 説明してもらい、質疑応答。
  7. 移動した人たちはもとのチームにもどり、説明者にフィードバックをもらう。
という感じ。30分程度でも終われそう。