オレとrubyと+α (Take the Red Pillの感想)

Take the Red Pill – 日本Ruby会議2009のセッションの感想。

感傷的な文章を書く。

ぼくはひよっこPHPプログラマーだ。
レガシーなコード(テストのないコード)に絶望していて、レガシーなコードしか書けない自分にもっと絶望している。
それはともかく、phpを選んでよかったなと思うこともあれば、失敗したかなと思うこともある。

今日はphpを選んでよかったと思った。phpに興味を持たなかったら、スクリプト言語に興味を持たなかったら、RubyKaigiにいなかったことは間違いないからだ。

ぼくが今やるべきことはその場にいて自分が感じたことを伝えること。これなら今の自分にも出来ること。
ぼくがこれからやるべきことは、その時点でぼくに出来ること。
セッションを通じて思ったこと、それは「ぼくとrubyと今のぼくに出来ること」だ。

●「Take the Red Pill」
角谷さんのプレゼンを残念にまとめると、「オレとRubyとRubyKaigi」だった。
今日のRubyKaigiまでくるのにも、課題と宿題に自分なりにチームなりに答えを出してきた、ということがよく伝わるプレゼンだった。
それと同時に、聞いている側にそれぞれの思いが形になっていった。

「何か質問はありますか?」
ここから、主役が聞いていた側に移り変わる。
場の熱に浮かされて、質問者が質問ならぬ自分語りを始めることになる。
テーマは全員「オレとrubyと+α」だ。
今日までの三日間の文脈がある。答えなんてない質問を投げかける。もやもやを吐き出す。思いを形にするというよりはもっと荒々しくぶつけていく。

「そこに月があれば指はRubyでなくてもよいのでは?」というIRCの書き込みの質問に対して角谷さんが「うん、そうだねえ」とやさしく答えたところで、ぼくは感極まって泣きそうになった。
(実際にはそうは言ってないかもしれないが、ぼくの記憶ではそうなっている 動画で見返すと熱量が下がる気がして書き終わるまでは確認しない)
rubyに限らず、何らかのコミュニティに一歩踏み出している状態であれば泣いていたと思う。

セッション終了の拍手は長く続いた。
終わってみれば角谷さんの30分のプレゼンは壮大な前フリであり導火線だった。
このエントリもまた、その熱に浮かされた状態で書いている。

ustreamの動画や、書き起こしや、twitterの#rubykaigiタグで追いましょう。
スタッフの皆さんありがとうございます。
書き起こしやそれに近いエントリをあげてくれる皆さんありがとうございます。
twiiterやIRCで実況してた皆さんありがとうございます。

以上が「ぼくとrubyと今のぼくに出来ること」のすべてです。

広告

wakameの話を聞いてきた

hbstudy#1に参加してきた。ぼくはインフラエンジニアではないです。インフラわからないの怖いです。

===
2009-07-11 19:00-
@新宿三葉ビル6F会議室
以下@以下は自分の感想

●あくしゅ 山崎
wakame

@バーチャルリアリティおもしれー

大規模インフラに触れる機会
それAmazonEC2で

# gem install wakame

wakameの原理
master1個に対してagentがいっぱい並ぶ
agentだけのインスタンスが立ち上がる
masterを呼ぶ
agentがサービスを立ち上げる

init.dからはサーバ起動をはずす
masterが起動して、agentを起動して、agentがリソースを割り当てする

masterにスケールの計画の指示

アクセス数の予想例
min 週ナカ朝5時
max 週末22時
だいたいみえるよね パターン
キャンペーンも時期はわかるよね
→予想が出来る

yahooニュースからのリンク
言ってくれたら対応できるんじゃね?
急に言われても対応できるようになればすごい

類似のアプリ
RightScale
Vertebra
Scalr
Chef

wakame
現在の対応はEC2のみ
事例はこれから出てくる

何台まで動かした?
→実験ベースで20台
amazonいったん20台limit

今のところec2の場所はまたげない

amazonEC2にインスタンスをおいてS3にイメージを焼く

masterが落ちたときもつつがなく動くが、減ったり増えたりしなくなる
一度落ちたマスターが復旧したときにどうするかはこれから

EC2で動くならEC2クローンといわれているユーカリプタスで動くの?
→これから確認します。

amiがruby、wakameもmatz rubyなのでmatzのrubyのバージョンに影響受ける

masterが別のところにあってもいけるか?
→AMQPがはいってればしゃべれるはず

AMQPのメリット セキュリティとか相互補完とか
XMPPのメリット ログアウトが仕様にある

wakameは「何かをトリガーにして」「何かをする」というものなので、actionという小さな単位まで細分化できれば何でも出来る 何でも決められる
@逆に言えばそういうことできる人前提かな さすがに

masterがagentから集めてくるデータはメモリに貯まっている
@メモリかあ

===
勉強会
Keep
 会場運営ありがとうございました
 1回きちんとまわせたのはすごい
Problem
 時間が余ってた
Try
 聞いてみたい話
 小規模運用で抑えておくべき大規模運用からのフィードバック
 →これこそ懇親会で聞けばいい話だな

じぶん
Keep
 理解しようとした
Problem
 個人名刺を切らした
Try
 ひとみしりするのはしかたないけど、なんとかする
 poken活用しよう

『パターン、Wiki、XP』刊行記念トークセッション聞いてきた

江渡浩一郎
著『パターン、Wiki、XP』(技術評論社)
刊行記念トークセッション

を聞いてきました。

===
2009-07-09 19:00-
@池袋ジュンク堂
以下@以下は自分の感想

●江渡
便利と思って追加した機能が実は悪い機能なことがある
wikiの本質を強化する機能
→wikiの本質とは?

よく見る典型的パーツを組み合わせる「デザインパターン」
ケントベックとカニンガムのデザインパターンのはじめの論文読んだ
おもしろい
今の「デザインパターン」と微妙に違う

XP
XPは理屈はわかるけど…責任の分解点が必要
XPは無理じゃないの感を持っていた

デザインパターンはXPにつながっている
パターンの2回目のトライがXP

XPの土台がwiki
wikiは土台であり、本質である

そしてアレグザンダー
はじめのころの主張
デザインするということ
YesかNoかで切り分けられるように分解すること

途中からの主張
自然都市と人工都市
利用者参加の建築

「無名の質」

形の科学
形を科学の対象にするのは難しい
科学の対象=再現可能なもの、制御可能なもの

wiki
パターンをいかに適用するかを考えている
コミュニケーションの土台

●トークセッション
トークセッションはソフトウェア開発にテーマを絞る
@以下、メモ少なくして聞き入ったので省略形

「サワダマンション」

クリーンコードの前書き コプリン
パターン XP リーン

×2周目かおまえら
○正しい方向へのアプローチ

パターンて名前を捨ててアジャイルじゃね
@テストじゃなくてBDDみたいなことだな

形がどうできるかの力
「インターネットが死ぬ日」

×つくろうとしてつくる
○できちゃった 内側から現れてきちゃった

デザインパターンは今まで見たことあるものに当てはめていくもの という印象になってしまっている
小さい すごく小さい

なんかいいかんじ えもいわれぬよさ
それが無名の質

「Nature of Order」
living
いきいき

どうやるとパタンランゲージかけるのかについては触れられなかった

でもそれをやんなくちゃ

15の属性で考えよう

背後にある力は何なのか

部品があってガチャンコすれば出来るんじゃないぞ

江渡
C++だとイテレータがないので「イテレータはこうすれば実現できるのである」
それをrubyではあたかも所与のように使える
これこそ構造保存変換である

修復の話
全体を見よ

ハッカーが自然に身につけたやり方を
普通の人が集団でそれを出来るようにする それがXP

generative
「wiki way」yomoyomo 絶版

@なんだこのセッションは…無限に本が買いたくなる

江渡
「エクストリームプログラミング」は「気付けよ!」みたいなことがあって
「アートオブ アジャイルデベロップメント」がXPの第3版であるって聞かされてなるほどってなった

アジャイルをはじめるには
角谷「あいさつして朝会やってふりかえりしろ」

おすすめの1冊
懸田「パターンランゲージによる住宅の建設」

●質疑応答
質問1
アレグザンダーの言ってることが変わったって言ってたけどアレグザンダーの考えが変わったの?

答え1
江渡
変わってない
周りの人の受け止め方が180度変わった

要求条件を満たす方法をずっと考えてた
実現する方法が違う

最初
中心となる設計者がいる コンピュータが助けになる

最後
建築を設計するのは利用者である

質問2
サワダマンションのどこに無名の質があるのか
答え2
角谷
wikiばなで聞け!

懸田
ちょっとずつ作ってる
1期2期3期
一部屋出来たら貸してたw
ちょっとずつ作って、リリースして、お金を回収して、次のサイクルへ
アジャイルじゃんこれ

===

トーク
Keep
 会場運営ありがとうございました
 あっちこっち話が飛んでるのにブレなかった
Problem
 3人が薦めてた本があとからだとわからなくなるものがある
Try
 「それ買う」ボタンが座席についてて、薦めてた本をその場で買えるようにすれば
 ジュンク堂がしやわせになれる(催眠商法みたいだがw)

じぶん
Keep
 江渡サイン本をget
 あがったテンションでそのまま本を読みきった
Problem
 受身なところ
Try
 今度は質問しよう

メタデータに活用する・されるためのセマンティックな話を聞いてきた


セマンティックなマーク付けとメタデータ活用~『セマンティックHTML/XHTML』の出版を記念して~
| サイバーガーデンbiz

セミナーに行ってきた。

漠然とマイクロフォーマットのように共通化されたフォーマットの話かなぐらいの感覚で参加。本は買ってない。資料が公開されています。セマンティックHTML?
KISS!

===
2009-07-04 15:00-
@渋谷アジアビル2F
以下@マーク付きの部分はぼくの感想です

●神崎正英

ユニバーサルHTML/XHTMLを書いた理由

セマンティックHTML
「コンピュータに人間を助けることが出来るようにする」

同じHTMLの中に情報を一元化
@RESTfulとかmap.resourceとかみたいなもんか

1
同じ言葉でもことなる文脈で使われる
「コロンビア」コーヒー豆、国の名前
2
固有名詞を与える必要があるのではない
普通名詞を与える必要がある

名前(識別)とタイプ(型)と関係(相互)

URIとRDF
Resource description framework

主語と述語と内容
RDFとRSSはちがうよー

RSSはRDFのボキャブラリー

@JSONみたいなkey-valueじゃだめなの
と思ったらその話が出てきた

暗黙の主語を含めた「トリプル」
CSSのスタイル宣言と同じ

@「自分が何なのか」を知っている という意味で主語が必要というのならわかる

@RSSを書いたことがある人は
→はじめは意味もわからず真似して書く
→意味がわかって書く
→ライブラリに任せる
いままで苦労したとかどうでもよくて、ライブラリに任せるところから高速道路に乗っけるところからやればいいんじゃないの

@「スケーラビリティ」 スケールするかどうかじゃなくて
汎用性可用性の意味か

文書メタデータ
暗黙の主語としての文書

@それ(文書)以外あるの?

メタデータの目的語
メタデータについて、さらにメタデータを持つ場合とそれ以上メタデータを持たない場合
木構造のノードとリーフ
メタデータを持たない場合 リテラル(属性型メタデータ)
メタデータを持つ場合 URI(関係型メタデータ)

RDFa
body要素の中でもメタデータを格納できる

RDFのビジュアルグラフ
まるでかかれたもの URI
しかくでかかれたもの リテラル

余談
クリエィティブコモンズとRDF
licenseは接頭辞無しでできる

@CMSで統一させたりすると、文書のライセンスってサイトで統一した仕様になりそう
このページの内容は明示している部分を除いてcc-byです という涙目展開

ボキャブラリーの分散化

@で、何に使えるのというキラーアプリの不存在
AutoPageRize, LivedoorFullSpeed

メタデータの主語がISBN
@でもISBNってユーザ側からメタデータ引っ張れないよね…
ASINに読み替えてAmazonからメタデータ取るとかしか出来ない

空白ノード
@無名××みたいなもの?

メタデータのチェーン
要素の中に要素があったら外側のプロパティの目的語を内側のプロパティの主語と読み替える

@標準のスケルトンが欲しい

@現在のSEOのように何らかの優遇措置・メリットがないと浸透はしないな
データマイニングにはこれがあれば便利だとは思うけれど、これでないほうのコンテンツのほうが圧倒的多数である以上、それを対応しなければいけない

コンピュータに見せたい内容と中身のデータを分けたいときには
content属性を中身とする

content="2009-07-04"
表示 "7月4日"

インライン要素が黙示的にcontent要素になるが、content要素を明示してやれば、指定が出来る

@→人間と機械に同じものを見せよう それで解釈を分けよう という基本理念と矛盾しない?

@APIでdate型のデータを取り出して、それを変形してやるというようにならなければいけない

@今、サイトのhtmlページ全体を作成する人って大多数なの?
みんなブログやwikiやsnsつかうのでは
ユーザの可編集領域

ドメインのURIをつかってその人のURIとしてしまう その是非というか非

文書URIを利用した間接識別
実際のものとオンライン上のものの区別

@オンライン上のもののURIだって間接識別なんじゃないの?
日付にしても、ファイルの更新日時だったり、
そのURIで表される空間にアクセスできることが可能になった日時だったり、
もっといえば検索に出てこないものは存在しないもの、という概念をとれば
googleがクロールした日時なのかもしれないし、google検索に出てくるようになった日時かもしれない

調理済み編については
明日アップします(神崎)

rel属性は定義済みと名前空間指定のもの以外無視されるので安心
ふやしておk

YahooによるRDFaサポート
なんでもいいから構造化してね いろいろ

GoogleによるRFDaサポート
googleの語彙を使って構造化してね

@RDFaなりなんなりの意味で構造化されたものだけが見られるブラウザがあれば
(あるんだろうけど)、イメージがしやすいように思う
htmlパーサ

●html5
ブラウザを中心としたプラットフォームの標準化
仕様が実装に追いついてくるのであれば好意的・健全にとらえていい

●メタデータが付与されたリソースが増える場所
発見可能にするもの(したいもの)についてメタデータが活用されていく
時間と場所
評判・レコメンデーション
スピーディさがもとめられるもの

●なにがほしい?神崎さん
ネットラジオの番組表

●企業の担当者に納得してもらう方法 説得する方法
たとえばデータがRDBMSにあるならわざわざ出し分けする必要がない
今文字列としてしか扱われていないものを
何らかのルール付けをしてマークアップ→それをマークアップ変換で出力する
文書を作る人が特殊なコストをかけるのは本末転倒

●大きな規模での活用事例
欧米の政府系
RDFに積極的

民間だと、digg, slideshareがそういうのを出してる

サーチエンジンオプティマイズの考え方
商品詳細ページ

●何を何に使う?
カレンダーに取り込んで欲しいとかあるならセマンティックwebの考え方を使おう
マイクロフォーマットで十分ならマイクロフォーマットを使うのがいいよね
ただ、その先を考えたらRDFaだよね

●よりよいメタデータの実装が出てくるか
ふくまれるんじゃね

●「日本のwebは残念」か?
元データに当たってないからわからないけど
「webに日本も外国もない」

文書構造とデータ構造の二重化
@DRYじゃないな

www.kanzaki.comのページ数
アクセスログで確認したら1週間で16000ユニークリソース
@なんだってー

●twitterとセマンティックweb
惜しいのはハッシュタグには文脈がない
セマンティック
===

講演会
Keep
 会場運営ありがとうございました
 そんなにかみ含めて説明しなくてもわかるよ、と思っていてももう一度きくと
 実はわかっていなかったことが残っていて、そのわかっていなかったことがわかったことに気付かされる ふしぎ!
Problem
 懇親会にもっと人呼べばいいのに
Try

じぶん
Keep
 ほぼ時間通りに到着できた ちょっと遅れたけど
 話にちゃんとついていけた(これは講師に依るところが大きいけど)
Problem
 薄い上着を忘れた
 懇親会までいたのに質問しそびれた
 みんな神崎さんの話が聞きたかったと思うのにずっと神崎さんのテーブルにいた ごめんね
Try
 htmlはこわいものじゃない もうちょっとまじめに取り組もうと思った
 と思ってユニバーサルHTML/XHTML読んでる

firefox拡張のワークショップに参加してきた

Mozilla Japan ブログ – 第 1 回 Firefox 出張ワークショップ ~基礎から学べる拡張機能開発~に参加してきた。helloworldはすぐできたけど、成果物は時間内に完成せず…

===
2009-06-28 11:00-
@日本工学院 蒲田キャンパス

●瀧田
mozillaの歴史とコミュニティ

●笠井
サンプル
http://people.mozilla.com/~dynamis/extdev/

firefox
エンジン部分だけc++
XULとjavascript
ズール

javascript
複雑なところはXPCOMがある
css
ui専用のプロパティがある

chrome GUI構成要素やパッケージシステム

./firefox -no-remote -P extdev
(firefox.exe -no-remote -P extdev)

別のプロファイルを作る
設定
javascript.options.showInConsole true
javascript.options.strict true
nglayout.debug.disable_xul_cache true
browser.dom.window.dump.enabled true

extentions以下にディレクトリ作ると開発用に便利 xpi作らなくていい
ポインタファイル名のテキストファイルにパス名を書くと読み込み便利

オレンジ色は見にくい!

chromeのパッケージ
content 本体
locale 多言語
skin デザイン

オーバーレイで本体の子要素末尾に追加される
場所、名前はdominspectorで調べる

イベントハンドラ
onlcickで呼び出すみたいなの

●piro
chrome以下をjarに圧縮して、さらに外側をxpiに圧縮するので(中身はどちらも単なるzip)、それを便利にするシェルスクリプト
http://www.cozmixng.org/repos/piro/make-xpi/trunk/
make_simple.sh

javascriptの本体を書き換える方法
browser.jarの中身がzip圧縮されているので書き換えちゃえ
→なんでも出来るため危険 副作用

イベントリスナを使う

タブ処理が出来るようになる

使いたいときになったらドキュメントを見る
MDC

ソースコードを見る
MXR

OSSライセンスの話
ライセンスの基本的な話

質疑応答
Q.そう書くしかないという部分でもライセンスの影響を受けるのか
 A.イディオムなら受けないと思う APIとの応答レベルでも受けないと思う
 そうでない場合、クリーンルームでなくコード見ちゃったら(いわゆる)汚染されるのは避けられない
Q.firefox拡張のライセンスは本体の影響を受けるか
 A.zipしてるだけだから本体のライセンスには引きずられないと思う
===

ワークショップ
Keep
 会場運営ありがとうございました
 日本工学院さん学生巻き込んでえらい
Problem
 環境構築にかける時間がちょっと多い
Try
 基調講演+島に分かれてチームで開発 みたいなのも試してほしい
 そういう形式に参加したことはないけど

じぶん
Keep
 学生や講師に自分の経歴を話した
Problem
 いくつか話聞きそびれた
Try
 時間内に完成できるものにとりかかろう 見積もり精度向上

CMSの比較を聞いてきた

CSSNite CMSリベンジ編を聞きにいってきました。

===
2009-06-27 14:00-
@ベルサール西新宿

●SOY CMS
カスタムフィールドが柔軟に作れる
管理画面からシームレスに連携

動作環境
apache2
php5.2以降
mysqlとsqlite

URLの思想
ファイル存在があった場合htmlを優先する
あとからリプレースができる

●web release2

デザインとデータの分離
あたりまえじゃないのこれ
→あたりまえじゃないわこれ google sitesとかべた書きだな 結構

CMSサーバ側でファイルを作って静的なwebサーバにFTPで

デプロイ 自動

CMSは「機能」として「使える」ってあって機能あるなし直交表だとマルペケで比較に乗るけど、実際に使い物になるレベルじゃないと意味ないよね

ここで電源力尽きる
===

セミナー
Keep
 会場運営ありがとうございました
 事前に発表を練り上げさせて、CSSNiteの蓄積と響くポイントを活かす繰り返しを主催者側は要求するそうです
 その思想を発表者にも参加者にも植え付けることをぜひ続けてほしい
Problem
 Keepの事情を知らなかったので、主催者が発表者をdisってるようにしか見えない
 disるのがいけないわけじゃなくて、ぼくにはそう見えてしまった、というところが問題と思う みんながそうだったかは知らない
Try
 パネリスト串刺し質問をもっとやってほしい

じぶん
Keep
 「それで僕たち(web制作者)はどう幸せになれるの?」という問いはこれから忘れないでいようと思う
 お客さんとユーザのことは考えるけどその間がすっぽり抜けてることが多い(自分は)
 若干気後れしたけど話しかけることが出来た
Problem
 名刺が豪快になくなってあせった
Try
 名刺もっと持って行かないと

GAEとScalaの話を聞いてきた

 BPStudy#22に参加してきました。


===
2009-06-26 BPStudy 19:00-
@EBISU303 501会議室

●スティルハウス鈴木

ご都合ドットコム Flexクライアント GAE/J

Flexメインに使ってる人 会場にゼロw

Datastoreは使いにくいんじゃない
スケーラブルなwebアプリのためのベストプラクティス環境
Datastore ←→ RDBMS

クラスタリング環境は難易度がとたんに上がる
そこをgoogleが担保

memcacheのデータが消えるタイミング
だいたい大丈夫(まつだ)

ユーザ指定秒数で消える
追い出されて消える 容量

パフォーマンスのためにmemcache
ステートはserverが変わると見れない 変数とか

h2は別のノードに振られたときに見れない memcacheは見える

appserver サンドボックスによる制限
30秒かかるリクエスト 例外発生
時間のかかる処理はcronかtask queueで
レスポンス送出時 チャンクで

strutsはノーサポート

スケールアウト
高負荷時の自動デプロイ 50分ぐらい?
軽いアプリでも分散してる感じある

safety limitはある

1回のクエリで最大1000件まで

startindexでも1000までしか指定できない
なぜなら1300がなめないとわからない

1000をみつけてブックマークして、300番目をする

どうしてもそうしたければ連番振るのもいい パフォーマンスは落ちるけど

どんなクエリでもページングできるライブラリがある python
ページに表示する

「最後のページ数」はフェッチできない
下からなめればいいから「最後のページ」は取れる
ページ数は不明になる

order順を何にするかによって、はまることがある ページングで
日付は同一になる場合があるので キーとプロパティを組み合わせてユニークにしてしまう

クエリ
クエリはインデックス+スキャンで実装

クエリは使ったら負け byひが
リストプロパティとか

イコールフィルターならインデックスジョインは起こらない
イコーリティじゃないフィルターをかけた場合、順番を決めてとってくる場合
ソートにインデックスが必要だから

どうなるか
1個のエンティティに対して5000までしかインデックスが作れない
容量が爆発する

コンポジットインデックス
爆発しやすい 不用意に使わない

RDBの関連をそのまま当てはめるとはまる
部門 1 に従業員 10000だと、1人更新中にほかの人が各自更新しようとすると9999がリトライになる
分散エンティティグループ

個々のエンティティ
更新スピード
1~10回/秒

join出来ない
非正規化して対処する

group by が出来ない
集約したい値は集約用のエンティティを用意

toUpper, toLowerできないのであらかじめした値をプロパティに持っておく

OR !=はそのまま書けない ドモルガンの法則で書き換えが必要

●yuroyoro
Scala

Lift

SDK内のdatanucleus-enhancerを1.1.3に差し替える

JVMで動きます

ファーストクラス関数
静的型付け+型推論

対話型インタプリタある

カリー化 部分適用

パターンマッチ

Lift
h2やmysql使う

controllerない
リクエスト来ると描画を始める
snipetでいろいろ処理する
外にアクセスしたりっていうのはmodelでやる
カスタムタグチック

viewドリブン

レンダリングを保持した関数が実行できる
レンダリングのときに必要なパラメータを
渡した関数オブジェクトを呼び出せる

コード書く側はあまり意識しなくていい

javascriptのarguments.calleeみたいな

動的SQL
s2jdbc的な

create tableとか画面上を流れる

関数型で作るメリット
イベントに対してボタンの割り当て
動的に関数を作れる
===

勉強会
Keep
会場運営ありがとうございました
Problem
途中から急激に冷えた 寒い
Try

じぶん
Keep
 GAEの入門から発展まで聞けたのでよかった
Problem
 もともとの体調不良にいろいろ直撃した
 懇親会キャンセルしてほんとすみません
Try
 大きな部屋は温度調節難しいのが当たり前なので、何か上着を持っていこう
 GAEとDataStoreはごちゃごちゃ考える前に使う

デブラブに参加してきた

世界のすべてをテストせよ。
~Make the world Green by Test !
に参加してきました。テストエンジニアや組み込みの人に話を聞けたのが新鮮でした。

===
2009-06-22 DevLOVE
@芝浦港南区民センター
19:00-

到着したらt-wadaさんの話がほぼ終わってた。
写経しなさい。
→はい。

QAテスト
テストライフサイクル
テストケースを書くことはテスト実装

テストの観点
システムをフローではなくパラメータの組み合わせで見る
補集合を意識する
誰が・誰にを意識する

テスト技法はモデルをテストケースに落とすもの

ワールドカフェ
テーブルごとにテーマを決めて話を展開させていく
ぼくのテーブルは「テストの再利用性」
ほんとに再利用できるの?(懐疑派)とやりようはあるんじゃない(期待派)にゆるく反応が分かれた
「テストツールは信用する」「フレームワークは疑わない」言語文化圏(ぼくはここ)とそれがしにくい言語文化圏の違いだけな気もした(あとから思えば)
必要な場面と時期と必要度に応じて分厚くしたり薄くしたりという調整は常に必要
テストのメンテコストが大きくなりすぎるのは本末転倒

===
デブラブ
Keep
 会場運営ありがとうございました
 段取り、備品小物、交流を促す仕掛け、よくできてる
Problem
 会場の温度寒かった
Try
 ついったーのハッシュタグも考慮する

自分
Keep
 自分なりには頑張って話した
 テストしにくいところをどうするかの話が出来た 自分の場合UIをどうにかしたい
Problem
 遅刻
 酔いすぎ
 懇親会で腰が重い
Try
 wacateはそのうち覗いてみる

モバイルビジネスラボ #3に行ってきた

モバイルビジネス・ラボ2009 Vol.3に行ってきた。

===
2009-06-17 モバイルビジネスラボ #3
@アップルストア銀座3F
17:00-

パネルディスカッション
アイレップ紺野
アイスタイル吉松
グランドデザイン小川和也
モディファイ小川浩

●ひとこと
吉松「リアルとモバイルをどうつなぐか
物販や旧来のマーケティングとモバイルの接続」
小川和也「店舗の支援でCRMですよ ケータイですよ
それはそれで重要だが、それだけで役割を果たせてるのか」
紺野「携帯の検索は市場的にも内容的にもまだ未成熟 これから」
小川浩「インターネットのインターフェイスがようやくモバイルまで降りてきた」

●iphoneやandroidで何が変わる
吉松「リアルはネットにまだ落ちてきてない」
小川和也「リアルやってみた結果 ネットってのはやっぱあるな、と」
小川浩「全員が使うようになるということはないだろうし想定もしてない
アーリーアダプターがオフラインで広めるのでもいいじゃん」
「ネットで全部完結しないだろうし、させなくていい」
小川浩「お金はまだ製作側にしか落ちてない その上で何を表現するかって段階が来つつある」

●日本のモバイル事業はどのように変化するか
吉松「コンテンツサービサーが増える」
小川和也「タイムシェアの奪い合い インターネットとの時間の奪い合い
持ち歩ける端末が触れている時間が長い それが起点になる」
小川浩「それが携帯電話かどうかはいちがいに言えないけど」

===
セミナー中だだらに考えたこと
たとえば、占いなんて中身はいくらでも誰でも作れる
大事なのは見せ方、メッセージ性と物語性 ←誰でも作れない
あとは、「めざましテレビの」占い、「とくダネの」占い、の方向性 話題共有

携帯サービスについて
掛ける人手はどんどん小さくなるが、情報収集からいえば規模が小さいのはきつい
近くにいるようでiphone, androidからこれほど遠い業界はないんじゃないかなと思う
端末固有番号、空メール、キャリアの独自仕様、仕様にないバッドノウハウ、セッションパラメータ、etc
半端な知識はevilだ

===
セミナー
Keep
 会場運営ありがとうございました
 パネラーと司会者のサービス精神とテンポがよい
Problem
 遅れてきた人が入ってくるたびに発表者の気がそがれてた かわいそう
Try
 予備知識の入れ方は課題かなあと思う

自分
Keep
 アウェーに行くのは続けよう
Problem
 いつもどおり遅刻した
 誰にも声を掛けず
Try
 つぎは気後れしない

Redmineの話を聞いてきた

events.php.gr.jp – Redmine勉強会に参加してきました。印象に残った話垂れ流し。

===
2009-06-12 Redmine勉強会
@トライコーン
19:30-

イベント・インシデント管理ツールとしてのredmine
コミュニケーション促進ツールとしてのredmine
楽しむ仕掛けを作る
今なにやってるかをチームで共有しよう

導入はよかった探しで始めてもいい
redmineに全能な新しい管理システムを期待するとダメ当然
ダメなとこ探しをするとすぐ死ぬ当然

今の「管理」って嫌なものだよね 管理されたくないしプログラマを管理したくないよね
ここがもっと生産的になればいい あとは防御的な意味合いの管理システム
上の人や提出させることが目的だけの資料は自動で出来ればいいのに

実用面の話
microsoft officeとの連携 適材適所でやれるとみんなうれしい Excelは悪者じゃないよ
ソースコードレビューに使えるようになってくれるとうれしい

RedmineというよりRailsアプリの課題
RailsのバージョンとRubyのバージョンがガシガシ上がるとRedmineのバージョンアップが…
一度入れたらバージョンそのままになりがち

gitのローカルコミット超便利
redmineも分散型になればいいのにね
===

勉強会
Keep
 会場運営ありがとうございました
 最近増えてる属性カオスな勉強会楽しい
Problem
 しいていえばうまく回りすぎたこと
Try
 第二回たのしみだ

じぶん
Keep
 Pokenはじめて役に立った
Problem
 また遅刻した
 若干斜に話してた?なんでだろ
Try
 自社でgiveするのもひとつのtry