2008年12月29日月曜日

androidでJUnitを使ってテストケースを書く方法

テストケースは、まぁ書けるとして、どうやってテストを実行するんだ? ってところで詰まったので、調べてみました。

androidにおけるUnitテストの資料

2008/12/28現在では以下のような状況でした。

で、日本語でまとめるとどーよ?

ざっくりまとめるので、詳しくは上記資料を読んでね。

  • まずはApiDemosのテストケースよんどけ
  • テストケースも1つの独立したプロジェクトとしてapkファイルを作ってエミュレータなどに転送する必要がある。要はテスト対象と、テスト本体で2つのプロジェクトを作る必要がある。
  • activityとかservice用のテストケースが用意されているので、それを使うと結構幸せになれる。このへん参照android.test.InstrumentationTestRunner - Android
  • テスト用のAndroidManifest.xmlが必要。書き方はApiDemos/testsのやつを参照
  • テストの実行は、エミュレータからならDevToolsというアプリのInstrumentationから好きなテストを選べば実行できる。
  • このDevTools→Instrumentationの中には既に何個かテストが入っているので、どんなことが出来るか実行してみると良いかも
  • コマンドラインから$ adb shell am instrument -w com.example.android.apis.tests/android.test.InstrumentationTestRunnerなどとしても起動できる。これにはオプションがいっぱいあるのでandroid.test.InstrumentationTestRunner - Android参照
  • テスト結果は$ adb logcatまたはamコマンドでの出力値として返される
  • INSTRUMENTATION_FAILEDとか言われる場合は、エミュレータ内でテスト用パッケージを認識できているか、$ adb shell pm list packagesを使って確認すると良いかも
Android端末間の互換性が問題になりそうな雰囲気なので、テストファーストで開発してテストをたくさん書いておくと、将来幸せになれるかも知れません。

2008年12月28日日曜日

OpenOffice3.0のWriterがひどく使いづらい件について

MS OfficeのWordに慣れた身にとって、ひどく使いづらいと感じた事があるので、ここで文句を言うw

ちなみに、MacOSX 10.5 + OpenOffice 3.0.0での話です。

したかったこと

ブログ読んでいて、「あ、これいいな。印刷しておこう」と滅多に思わないことを思ってしまったので、手持ちのOpenOffice3.0を起動してWriterを選んだ。

HTMLから該当箇所をwriterにコピペする。元HTMLから多少文体が異なってしまったが、まぁいい。

ちょちょこ直した。

さぁ印刷と思ってプレビューを見てみる。

あれ、最後の行が次ページにはみ出てる。

直さなきゃ。

ここから悪夢が始まる

1ページの行数を増やせばいいな、と経験から思ったので、「ファイル」メニューから「印刷設定」を探す。

あれ、そんなメニュー無い。

しょうがないので「ファイル」メニューから「プロパティ」を開いてみる。

ここにも行数の設定画面がない。こりゃファイルシステム上のプロパティを編集する画面か。

じゃあどこだ?

あれれ? それらしいメニューがない。

プレビュー画面ボタンにあるのかな?

・・・プレビュー画面開いたけど、そんなボタンない。

わからん。

機能的には無いと非常に不便だから、無いはずはないんだけど・・・。見たことがある気もするし。

しょうがないから、メニューを1つ1つ開いてみるか。

(しばらく探す)

あ、あった。「書式」メニューの「ページ」ね。もーこんな所に置くなよー。

更に悪夢は続く

んーと、行数の設定は・・・「行数と文字」タブか。

「行数だけ指定」を選んで、「ページ単位の行数」は・・・26行? A4に入る行数ってそんなもんだっけ? まぁいいや。確定。

うがっ、やっぱり行数が少なすぎて3ページまで伸びちゃった。

元の設定画面に戻って・・・と。

でも、26行以上増えないなぁ。

(しばし、がちゃがちゃ)

あれ? 「ルビ文字の最大サイズ」を減らしたら「ページ単位の行数」が31行まで増えた。

えー? 「ルビ文字の最大サイズ」とか「1文字の最大サイズ」を指定してからじゃないと、「ページ単位の行数」を自由に指定できないの?

まじで?

うーめんどくさー。まーいーや、ルビなんて無いし、1文字サイズも使っているフォントサイズまで下げちゃえ。

あれれ? それでもまだ印刷したい文書は1ページに収まらないや。

うー。見た目では、まだまだ行間空きすぎなので、この行間を削りたいんだけどなー。

どこで調節するんだ?

(かなり格闘)

うー、いくら調整しても、「標準の文字数を使う」を選んでデフォルト設定を使った方が収まりがいい・・・。

うがー、わからん。こんなに時間かけてられない。やーめた。

てか、胸くそ悪いから、ブログに書いてやろう。←いまココ

ユーザインタフェース上の問題点まとめ

OpenOfficeはその存在意義として「MS Officeの代替えを無料で目指す。(=MSやっつける)」であったはずですが、このインタフェースじゃあMS Officeから流れてきた人はOpenOfficeのwriterで絶望して「しょうがないからMS Office 2007でも買おうか」となる気がします。

具体的な問題点は以下の点です。

  • MS Officeと同じ機能が同じメニュー構成となっていない。これは、「基本的なメニュー構成や機能は、違うアプリ間においても同じ配置になっているべき」というMS WindowsのUI思想に反していて、元Windowsユーザにとっては非常にフラストレーションが溜まります。(MS Office 2007はここで反感をかったわけですが)
  • 大抵の人のプロセスとして、「適当に文書を書く」→「1ページに収めたいところがあったらページの行数を増やす」→「システムが行数に合った行間隔などの周辺パラメータを適当に設定する」→「まだ気にくわなかったら周辺パラメータを微調整」といった流れで作業するのに対し、OpenOfficeのwriterは「適当に文書を書く」→「システムが行数に合った行間隔などの周辺パラメータを適当に設定する」→「1ページに収めたいところがあったらページの行数を増やす」→「まだ気にくわないので、さらに行間隔などの周辺パラメータを適当に設定する」→「1ページに収めたいところがあったらページの行数を増やす」→「まだ気にくわないので(以下何度か繰り返す)」となっていて、「1ページに文書を収める」という目的達成まで非常に時間を要します。
  • いくらがんばっても目的を達成できず、かつデフォルト設定の方が自分の目的に近い。サイアクです。

MS Officeでは簡単に実現できたことを、OpenOfficeでは色々試して結局実現できなかったという体験は、絶望以外は生まないでしょう。(たぶん自分ももうwriterは使いません)

とか言いつつ、マイナーバージョン上げたら直ってたりしてね。

2008年12月25日木曜日

Web上で1円を決済させる方法

おいら今更ながらウェブ進化論 を読んだんですが、読みながら「そういえば、まだ人々から1円づつ徴収するようなビジネスモデルって出てきてないなぁ。ウェブ進化論っていつ書かれた本だっけ? 景気悪化から広告費が削られるのは目に見えてるんだから、まさに今必要なのに。たとえば、1円決済モデルを行うメソッドさえ実現できるなら、おいらのようなフリーランサーが自分で食べるのに困らないぐらい稼ぐことは簡単だと思えるのに」と思っていた。

てなところで、定額決済の話題がホットになってきたので便乗してみる。

前提

「失敗して当たり前」な有料Webサービスの条件 - インターネットください

「サイト存続のため、アバター買って」 カフェスタが異例の呼び掛け - ITmedia News

「タダが当たり前」の時代は終わる? カフェスタが「お金払って」と呼び掛けた理由 (1/2) - ITmedia News

有料ネットサービスが成功しないたったひとつの理由 - いつか作ります - 断片部

コンテンツで収入を得ていける仕組みをみんなで考えよう - novtan別館

有料サービスが抱える課題 − 少額決済について - この先、しばらく道なりです

ポイント購入制が有力かも!?

有料サービスが抱える課題にある通り「ポイント購入制」が現実解に思える。

コメント欄にある通り、Value-Domain なんかは昔からクレジットカードでサイト内ポイントを購入して、そこから少額決済(といっても数百円単位)してるし。表から見る分には良いモデルだと思う。(飼い囲み的に)

でもValue-Domainはあくまで「ドメイン屋さん」で、よっぽどじゃないと少額決済を広めようという気は起きないと思う。(し実際ムリだと思う)

それに、今から使用額決済システムを作って、市場に受け入れられるかは不明だよね。APIどうすんの?の他にも、そもそも信用問題とかとか。

こんなのどうかな?

で、自分が思うに、OpenIDと絡むのが「少額決済」的にも「OpenIDの発展」的にもいいと思う。

おいらgemspec.infoを作ったときにOpenIDの事をそれなりに調べたんだけど、あれって認証したときにユーザ情報を一緒に渡すことが出来て、かつその付加情報って拡張可能だった気がする。(や、深く調べてないからわかんないんだけど)

要は、OpenIDプロバイダがやる気になって独自拡張すれば、グローバルなIDに紐づけられた決済手段として使えると思うんだよね。

ちなみに、

  • 日本の企業で
  • 有名で
  • 既にユーザが多く
  • かなりの割合の人が既に決済手段を登録済みであり(←超重要)
  • クレジットカード会社側もある程度の少額決済を容認しており
  • もちろんOpenIDプロバイダとして稼働していて
  • 決済手段を登録しているが故に、IDの身元確認もしっかりしている(と期待されている)

という意味で、Yahoo! JAPANがOpenIDを使った決済機能提供元の最有力候補に思えるんだけど。

で、以下はヤフオクユーザを対象に考えていくことにする。

OpenIDを使った決済の流れ(脳内)

あらかじめ設定しておくこと

ヤフオクユーザである時点で決済手段は登録済みなので、後は・・・

  1. 自分のOpenIDを発行する
  2. 自分のOpenIDを使って決済を行うことを許可しておく。この際、デフォルト決済手段も指定しておく。

の2点だけ設定しておく必要がある。

少額を何回も決済されることを、カード会社が嫌うなら(普通嫌だよね)、そこにポイント制を導入しなければならないと思うので、先にポイント購入しておき、自動チャージの設定などもしておくのが理想なんだろうな。

外部サイトで決済するときの流れ

  1. 外部サイトで「決済金額」と「Yahoo! JAPANが発行した自分のOpenID」を入力して決済ボタンをクリック。(ただし、ログイン済み状態ならOpenIDの入力は必要ない)
  2. 外部サイトのシステムがOpenIDをパースし、決済情報と一緒にエントリポイント(Yahoo! JAPAN)へのリダイレクトを行う。もちろんSSLを使う。
  3. Yahoo! JAPANのOpenIDログイン画面が表示されるので、ログインする。(ログイン済みであれば省略)
  4. Yahoo! JAPAN上で決済金額と支払先(外部サイト名)が示され、Yahooに登録済みの決済方法のうち、どれから支払うかを選択する。(確認無しに決済を行う設定になっていれば省略)
  5. Yahoo! JAPAN上での決済が無事完了すれば、外部サイトに再度リダイレクトされる。この際、決済を特定できる決済IDも一緒に渡す
  6. 外部サイト側で、決済IDを保存して完了。または決済できていなければエラー処理を行う。
  7. 決済IDを使って決済状況などを確認することが出来る(ユーザ、外部サイト共に)

2のリダイレクト時に、外部サイト側を確認するため、なんらかの認証手続き(RSA認証とか)を使っておくと良いんじゃないかな。

ちなみに、外部サイトで販売するものは、「物理的な商品」でも良いし、「情報」でも良いし、「一定期間のサービス使用権」でもいいと思う。

整理すると

  • ユーザは(設定と認証状況にも寄るが)、金額を確認して決済ボタンを押すだけ(最短1クリック)で決済完了できる可能性がある。
  • この時の条件は、「外部サイトにOpenIDを使ってログイン済みで、Yahoo!JAPANにもログイン済みで、Yahoo!JAPANにOpenID経由で決済リクエストがあったときのデフォルト決済手段が登録済みであり、決済リクエストがあったときに確認無しで決済を通すように設定されていること」の4点。
  • 外部サイト側で対応すべき事は、OpenIDを使ったログイン処理+αぐらいの処理であり、全然楽。ユーザのパスワードもクレジットカードのナンバーも(手に入らないので)気にすることはない。あー、決済可能なOpenIDプロバイダをホワイトリストでフィルタリングする必要はあるかな。
  • 一方、Yahoo! JAPAN側は、規格の策定から関係団体への折衝からカード会社への説明からAPI公開から保守まで対応する必要があり、結構というか相当大変だとは思うけど、実現できたら「一人勝ち」状態でしょうね。

OpenIDなら、1つのYahoo! IDから「決済画面に進めるOpenID」と「決済できないOpenID」を用途によって使い分けることが出来るしね。(今のYahoo! JAPANの仕組みじゃ出来ないんだろうけど)

OpenID側のメリット

OpenID対応サイトを作ってみて分かったんだけど、今のOpenID界って結構混沌としてて、「あっちのOpenIDプロバイダだとコレができるけどアレができない」「こっちは日本語使えない」とか、OpenID対応サイトもホワイトリスト的に利用可能なOpenIDプロバイダを絞ってるので、結局あちこちのOpenIDプロバイダにIDを2・3個登録して、OpenID対応サイトも複数のOpenIDを登録しちゃうことになってしまう。

同じサイトなのに、別のOpenIDでログインしちゃって、「あれー? おいらのデータはドコいった?」とかね。(実話)

でも、これって当初のOpenIDの目的に反してる。ぜんぜん便利じゃない。便利じゃないからOpenID対応サイトも増えない。

イクナイ。

で、Yahoo! JAPANが少額決済メソッドの実装できたらどうなるか?

  1. 少なくとも日本のECサイトでは「Yahoo! JAPANのOpenIDを使った決済方法」に対応するところが次々に出てくる。(Webマネーに次々に対応したように)
  2. 普通のWebサービスでも「Yahoo! JAPANのOpenIDを使った決済方法」に対応するところが現れる。
  3. いったん「普通のWebサービス」で受け入れられると、決済手法として爆発的に普及する。(だって利用料取りたいもんねぇ)
  4. 「Yahoo! JAPANのOpenIDを使った決済方法」がデファクトスタンダードとなる。
  5. 決済機能に支えられてYahoo! JAPAN発行のOpenID利用者が増える
  6. ユーザシェア拡大に伴い、数多のOpenID対応サイトではYahoo! JAPANのOpenIDをホワイトリストに追加しなければならなくなるので、ユーザはとりあえずYahoo! JAPANのOpenIDを取得し、使うようになる。
  7. Yahoo! JAPAN発行のOpenIDがデファクトスタンダードとなる。

てな具合に、Yahoo! JAPANの商売的にも、OpenIDの普及のためにも、ECサイト運営者にも(決済方法の拡充と集約)、Webサービス運営者にも(広告モデルからの脱却)、ユーザの利便性(OpenIDと少額決済)向上のためにも、みんなにすんごいメリットがある気がする。

こうなったら、おいらも他のOpenID捨ててYahoo!一本に絞るね。

Yahoo! JAPANさん、がんばってくださいよー。

でもマテよ?

あれー?

なんかうまく行きそうじゃねー?

おっかしーなー、なんで今まで生まれてこなかったんだ? どっかに穴があるな、こりゃ。

ツッコミ求む!!

12/26更新

はてブやコメントで指摘いただいたので補足。

「日本では銀行以外が送金業務を行うことは違法」については、これが送金業務に当たるかどうか微妙だけれど、2005年初頭にYahooがあおぞら銀行を傘下におさめて、銀行業務に参入してたみたいなんで、これの流れがあるのかなぁとか。

「オークションを使ってない(相当数の)人たちは使えない」と言うのは視点が違う気がします。全ての人がアカウントを持っている銀行なりクレジットカード会社なんて存在しないので、どんな方法にせよ、新規に「クレジットカードなり銀行引き落としにつなげるための登録」をする必要があるんでしょうけど、ヤフオクを使える人(Yahoo! JAPANプレミアム会員)なら新たに登録しなくてもそのまま使えるよ、って話です。Yahoo! JAPANプレミアム会員ではない人は、新たに会員登録すればいい話なので、マイナス位置じゃなくてゼロ位置ですよね。

「クレジットカードなり銀行引き落としにつなげるための登録」って、ユーザにとってすごく障壁が高い行動なので、(簡単な設定ぐらいで)何もしなくてもそのまま使えちゃうユーザ(Yahoo! JAPANプレミアム会員)が居るのって、超重要だと思うのです。

「決済手数料の問題」については、運営元の判断(直接マネタイズするのか、他社より優位に立てればそれで良しとするか)に寄るんでしょうけど、「ヤフオクはやらなくても、少額決済には使いたい」って人もプレミアム会員に流れるでしょうから、新規に増加する会員の月額利用料(346円)分は売り上げがあがるんじゃないかな。

現実問題として、決済手数料無しで使わせるのは難しいんだろうけど、ポイント制で行くならそんなにバカみたいに高いシステム構築費にはならないと思うから、その分手数料を安くできるだろうし、極端な話手数料が安ければ、定額制にしてプレミアム会員に負担させるとかって話でもいい気がする。外部サイトなどに手数料を負担させることが結局支払い価格に乗ってくることを伝えれば、理解も得られるんじゃないかな。あと、Yahooから外部サイトへの支払いも、「末締め翌月末払いで1万円単位」ぐらいで縛って、ここから数パーセントのマージン取れるんじゃないかなぁ。

・・・でもなんか、もっと現場寄りの泥臭い話が根幹にある気もする。

2008年12月24日水曜日

月刊android周辺にぅす2008年12月版

日本アンドロイドの会北海道支部ができたのはいいけど、どんな活動しよっかなーと思っていたんですが、androidの経験の少ないおいらでも出来そうな事として、毎月(札幌Javaコミュニティの活動日)Android周辺ニュースをおいらなりにまとめて公開しようと思っています。

生い立ちと対象読者

日本では端末さえ出ていないAndroidですが、G1が発売されてからはAndroid界も慌ただしくなってきていて、新たにAndroidに興味を持った人がいたとしても、周辺事情を抑えるのでさえも一苦労かなと。

Androidに興味を持っている(けどよくわからないから手を出していない)Web系プログラマというのは、結構な数存在すると思うのですが、そういう人向けに毎月コンテンツ開発者視点でニュースランキングを配信することには意味があると思ったので、「飽きるまで」やってみようかと思います。

特に、(端末が発売されていない状況なので当たり前なのですが)現状ではコンテンツ開発者よりも、組み込み開発者(このハード構成でAndroid動いたーみたいな)の方が盛り上がっているように見えるので、これをきっかけにAndroidに興味を持ってくれるWeb系プログラマが増えて、コンテンツ開発者間も盛り上がってくれればいいなぁと思っております。

なお、おいら北海道人なので、視点が北海道からのものになっています。前提が札幌Javaコミュでの発表資料なので、この辺は許してくださいね。

公開資料

なお、資料はSlideshareを使って公開していますが、今のバージョンは相当腐っているらしく、Macからアップロードはできないわ、プロフィールやファイルの属性編集もできないわで、酷い状態です。

かなり適当な状態でアップロードされていますが、ご容赦くださいまし。

なお、内容については、(一応android系ニュースは追っているものの)おいらが直感的に確認も取らずてきとーに突っ込んでいるだけなので、もし間違っていてもAndroidの会は無関係です。悪しからず。

なお、11月以前のAndroid周辺事情は(大雑把ですが)android勉強会 in 札幌+android周辺事情のまとめ を推しておきます。

あと、ニュースソースはandroid情報まとめ@ウィキなので、「一ヶ月も待ってらんねー」という方や「何言ってるかわかんねー」という方はそちらをどうぞ。

で、反省

初回なので、あまりうまく行くとは思ってなかったのですが、本当にイマイチだったので、反省しておきます。

  • トップ10である必要はないかも。みんなが知っておくべき大事な要素って、トップ5に収まる気がする。
  • スライド1枚ぐらいの内容で、今月何があったのか、時系列で示しておいたほうが理解しやすいかも
  • コメントがやっつけっぽいよね
  • 札幌Javaコミュ内のAndroidに興味を持っている人のレベルに合わせた方がいいのかな
  • やばい、このニュースだけじゃ呑み会に繋がらない気がする

こんなの欲しいみたいなご要望ありましたら、コメント欄にどうぞー


2008年12月14日日曜日

勉強会配信セットを作ってみました

パチンコで勝ったので、このアブクゼニが無くならないうちに勉強会をUst配信するために必要な機材をバック1つにまとめたセット(以下勉強会配信セット)を作ってみました。

勉強会配信セット

方向性としては、

  • 配信に必要なものがバック1つに収まること
  • 最低限のクオリティを確保しつつ安価であること
  • 勉強会間で貸し借り可能なこと(LOCALで管理する前提でまとめました)
  • ネットワーク回線は調達方法がいろいろあるし、責任問題が付きまとうからセットには含めない

としています。

「ちょっと○○配信したいから貸してよー」「ほーい」と簡単に貸せるセットとして使いたいのです。

以下にセット内容と選定理由と購入価格と短評をまとめてみます。

Webカメラ


"Logicool キューカムプロ9000 QCAM-200S" (ロジクール)

購入価格 : 約8000円

購入理由 : 勉強会配信に関して異常な技術力を誇るRuby札幌がお勧めしてたから。

どうよ? : カメラ性能はWebカメラとしては良い方だと思う。注目すべきはマイクの性能で、質疑応答はマイク無しでもなんとか聞き取れる程性能がよい。ただ、カメラ固定用の穴がないので、三脚などのへの固定には工夫を要する。(ガムテープとかね) Windowsなら高画質モードがあるみたい?(未確認)

参考 : メーカーリンク

三脚


"SLIK 三脚 800G-7 SLIK800G-7" (スリック)

購入価格 : 約4000円

購入理由 : まぁなんでも良かったんだけど、安くて、カメラの高さが地面から1.5m以上にあって、軽いこと(700g)が決定要因だった。

どうよ? : んー。普通に良い。特に困ったことはないなぁ。

参考 : メーカーリンク

三脚を設置する場所が無いとき用の固定器具


"ケンコー カメラ用三脚 JOBY ゴリラポッド 086821" (JOBY)

購入価格 : 約3000円

購入理由 : レイアウト的に三脚が置けない場合があると思うので、ポールや天井への固定用に買ってみた。JOBYゴリラポットSLRかSLR-ZOOMというグレードなら、それぞれ800g/1.5kgまでの加重に耐えられるのだが、一番低いグレードはくにゃくにゃしてて使い物にならないので注意。おいらはSLRを買ったので800gまでだけど、これならスタビライザーを付けても実用十分。

どうよ? : まだ実践未投入。でもまぁ、三脚が使えるならそれが一番かもね。セッティング楽だし。

参考 : メーカーリンク

Webカメラ固定用台座


"Manfrotto カメラスタビライザー 797 Modopoket" (manfrotto)

購入価格 : 約3000円

購入理由 : キューカムプロ9000 QCAM-200Sはカメラ固定用の穴が無いので、三脚にならガムテープでなんとか固定できるものの、ゴリラポットは流石にムリ。汎用性を確保したいならカメラ側に細工をするべきだと思ったので、これを買ってみました。まぁ、固定用の面積稼ぎですわ。

どうよ? : 現状買って正解でした。ただ、まぁ、結局はテープで固定なので、カメラ固定用の穴と同じ山が切ってあるプレートを自作した方が安上がりでしょうね。ちなみに、ゴリラポットと組み合わせた状態はこちら。

QCAM-200S + GorillaPod SLR

USB延長ケーブル


"バッファローコクヨサプライ Arvel USB2.0対応 リピーター ケーブル 5.0M グラファイト AUR09GR" (バッファローコクヨサプライ)

購入価格 : 約2000円

購入理由 : キューカムプロ9000 QCAM-200SはUSB接続なんだけど、ケーブルが1.5mぐらいしかないので、三脚の隣にPCを置く必要があって、レイアウトがかなり制限される。そこでUSB延長ケーブル(オス-メス型)が必要になるんだけど、5m延長するならリピータ機能付きの方がなんとなく安心かなーと思って買ってみた。

どうよ? : うん。普通に使えた。やっぱりケーブル長いと楽だわ。

配信用ソフトウェア

配信中は結構CPU負荷かかるなぁ。理想的には配信専用PC+配信担当者がいた方がいいでしょうね。

  • Ustream 〜言わずと知れた動画配信サービス。Webカメラで撮った動画をライブ中継しながら録画できる。IRCを使ったチャット機能付き。プロジェクタに余裕があればIRCの内容を勉強会にフィードバックできて、盛り上がる。利用は無料。
  • CamTwist 〜Mac用。動画にエフェクトをかけたり、スクリーンキャストできたりする。そもそもドライバがないためMacは標準ではキューカムプロ9000 QCAM-200Sを扱えないが、このアプリを経由すると使えるようになるため必須。詳しくはCamTwist - UstreamまとめWiki 参照。

その他雑多

雑多なので100均を中心に揃えたものです。イヤホン以外必須ではないですけどね。

  • 携帯用バック〜30cm四方ぐらいのバックなら、三脚が飛び出すぐらいで収まる。家に余っていたもの。
  • Webカメラ用ポーチ〜レンズ傷ついたらヤだからね。100円。
  • 固定用テープ〜100均で打ってるガムテープで良いかも。Webカメラの固定の他、あると何かと便利。
  • カッター〜テープを切るためのもの。無いと上手に切れないので。
  • イヤホン〜Ust中継中に画像は簡単に確認できるけど、音声はイヤホンか無いと確認できないので必要。(周りの迷惑になるからね)
  • Windows用ドライバCD〜キューカムプロ9000 QCAM-200Sに標準でついているもの。Windowsの場合はドライバが必要らしいので。Macの場合はドライバはいらないけど別途CamTwistが必要。貸し出す前提なので。
  • 簡易マニュアル〜セット一覧とUstream.tvの簡単な使い方をプリントアウトしたもの。貸し出す前提なので。

その他PCとか電源タップとかLANケーブルとかは当たり前に必要だけど、それは準備できるでしょ。

まとめ

と、いうことで、約2万円ぐらいで勉強会配信セットを作ることが出来ました。

実用十分です。

先日PHP勉強会を配信してきたので、実際どんなもんか確認してみてください。(配信用回線は施設からレンタルしたものです。配信用アカウントも勉強会側から借りたものです)

欲を言えば、ネットワーク越しに勉強会に参加している人のフォロー用に、IRCを投写できる携帯プロジェクターがあれば言うこと無しですね。(このためにわざわざもう一台プロジェクターを用意するのは大変ですし)

あ、そうそう。勉強会をUst中継する場合、配信チャンネルが決まっていることが多いと思うけど、そのチャンネルを使うことが出来るUstreamのユーザ名とパスワードは事前に確認しておいた方が良いかもしれません。


2008年12月13日土曜日

CPIのrootがもらえる格安VPSであるVS-01を試してみた

個人的には「運用やバックアップを考慮して機器構成を考えて、サーバマシンを買って、セットアップして、データセンターに設置、そして保守管理」という作業に嫌気がさしているので、レンタルサーバで済ませることが出来るならそれでいいじゃんと思ってます。

で、費用対効果的に

  • 1万円/月程度でrootがもらえて実用的に使えるamazon EC2
  • 400円/月程度でrootは無いけどRailsが動く(けど共用サーバなので重いときがある)HostingRails.com

の2枚のカードが手元にあり、 使い分けによってどちらもそれぞれ良いサービスなんだけど、この中間にあたる「rootをもらえて月1000〜3000円」というゾーンにもちょっと興味がありました。(あと、上記は英語圏のサービスなので対応にちょっと不安がありました)

格安VPSに求めること

自分の使い方だと以下の点を満足するVPSサービスである必要があります。(EC2とHostingRailsを比較対象とした最低ライン)

  • 技術サポートが日本語
  • 日本からのネットワーク距離が近く速度やレスポンスが良い
  • Railsが実用的に動く(mongrel_cluster+mem_cachedやバッチ処理がちゃんと動く)
  • ネットワーク転送料制限やストレージ容量が極端に少なくないこと
  • それなりにメジャーなディストリビューションを使っている(個人的にCentOSはギリギリ。debian系がいいなー)
  • 共用サーバではないので自分でメンテナンスをしなければならないので、パッケージシステムが便利に使えること。およびディストリビューションがちゃんとパッケージをメンテナンスしていること。

これ以外はrootがもらえるなら、なんとかなるかなと。

CPIという会社が格安VPSサービスを始めた

KDDI系でCPIという会社があるらしい(おいらあまり詳しくない)のですが、そこで2000円/月でrootがもらえるVPSサービスを始めたらしく、期間限定でお試しサーバを貸してくれるらしいので、早速申し込んでみました。

スペックはこちら

CPI | Virtual Private Type Rental Server VPSスケーラブルプラン

試したのは一番安いVS-01プランです。

で、どうだったか?

用意してもらったVS-01のテストサーバにSSHで繋いで色々いじってみましたが、結果的に自分の使い方ではVS-01は採用に至りませんでした。

その理由をざっとまとめておきます。

  • VS-01以外ではコストメリットが低いので検討に値しない(あくまで主観)
  • VS-01のテストサーバは、スペック通り完全に立ち上がった状態で空きメモリが約180MBあるんだけど、このメモリ量ではyumがまともに動かない。yum無しでサーバを管理するのは辛いなぁ。てかこのテストさえまともに出来ない
  • 自分のPCからscpで動画ファイルを転送してみたら、最初は1MByte/secぐらいでるものの、10MB〜30MBぐらい転送したところでストールしちゃった。帯域制限かけてるのかな?(当たり前に使用状況によるのでこんなことがあった程度に捉えてください)

個人的にはyumが使えないのが決定的でした。メモリ180MBって結構小さいんですねぇ。

といっても、マニュアルさえちゃんと見てないので、操作方法間違えてる可能性もあるのですが。

でも、標準状態でapache/PHP/qmail/bind/mysqlあたり動いてるので、特殊なプログラムをコンパイルしてPHPから使うような用途なら十分なのかも知れません。

どちらにせよ、気になるならお試しサーバ使ってみると良いですよ。


2008年12月10日水曜日

gemspec.infoのβ2リリース

gemspec.infoに機能追加しました。

バージョンアップ内容β1→β2

  • 各gemの最新バージョンを対象にRDocを生成しておき、gemspec.info上から表示可能とした。これにより、ユーザは事前にRDocを使ってgem内容を確認できる。ただし、gemからRDocを生成する処理は半手動であり、RDocを生成できないgemも多数存在するため、全てのgemでRDocを表示できるわけではない。テンプレートは Allisonを使っているので標準よりキレイかも。
  • RDoc生成機能に合わせ、クラスダイアグラムも生成しておき、gemspec.info上から表示可能とした。ただし、これもうまく生成できないモノが多数。RDocより数は少ない。
  • これらに関連し、現在のシステム上のデータ量統計を表示した。総gem数、総version数、総spec数(なんでversion数より多いんだ?w)、保持している総RDoc数、保持している総クラスダイアグラム数、最終RDoc更新日時を表示した。
  • トップページの新着gemの表示内容を変更。どうせ新しいモノには付加情報は無いのだから、gem名と概要だけ表示する様にし、興味を引くようにした。
  • HostingRails.com を使ってるんですが、同じHostingRails.com内の別データセンターに引っ越ししました。こちらの方が日本からの回線も、サーバ内のピーク時負荷も軽いので結果として良かったかも。

GitHubサポートの問題点

GitHubのgemリポジトリサポートについては、まだ悩んでます。

末端ユーザとしては最新の機能で最も安定しているバージョンのgemを使いたいはずなんですが、分散バージョン管理であるが故に共通の親を持つ同系列のgemが多数存在し、結局どれを使うべきか判断できないのです。

中央集権的なRubyForgeであれば最新バージョンを追うだけなんですが、GitHubの場合、スクレイピング無しには親子関係さえ判断できない。というかそもそも、Rubygemを使わず直接GitHubにログインしてどれを使うか検討するときでさえも、同系列のgemの内、誰のgemを使うべきか悩ましいですよね。

結局、Subversionのような中央サーバ型でも、Gitの様な分散サーバ型でも、一つのプロジェクトを継続していくためには全体の流れを統括して本流を維持していくコミッタが必要と言うことなんでしょうね。

全文検索機能の問題点

もう一つ付けたい機能が全文検索機能で、これが無いとgemspec.infoは実用にならないと思ってるくらい重要な機能なんだけど、これはacts_as_searchable(エンジンはHyperEstraier)を使おうと思ってるんですが、このHyperEstraierがちょっとくせ者です。

というのは、HyperEstraier自体は国産なので日本語に対する検索性能や日本語の資料がしっかりしてて機能的にも性能的にも良いところが一杯なんですが、どうも作者は既に興味を失っているらしく、メンテされている気配がない+コミュニティも盛り上がってない。(MLを見ている限りでは)

gemspec.infoへの全文検索実装だけ考えればあまり問題ではないんだけど、どうせ使い方をマスターするなら次のサービスや仕事でも使いたいし、それなら将来性があるエンジンを採用したいですよね。

Wikipediaで調べる限りは、機能的にはぶっちぎりで優秀(使いやすい)なので、メンテナさえ居ればしばらく安泰って感じなんだけどねぇ。分かち書き+N-gramのハイブリットって他では無いので。

で、次のタスク

話は逸れましたが、個人的にはandroid に興味が移ってきており、プライベートな時間帯にRubyを触る時間は減りつつあるので、gemspec.infoのコードも、さくっとオープンソースとして公開すべきなんでしょうね。GitHubあたりに載っけちゃいましょうか。


2008年12月9日火曜日

ベンチャー経営者のための資金調達マニュアルを使って独学してみようかと

北から南や西を見て思うこと: スタートアップ指向コンサルティングというビジネススタイルについて考えてみた でもちょっとふれているように、最近おいらは経営層や企画層と対等に話が出来るように、もっと言うとコンサルティングが出来るようになりたいと思っています。

何故そう思うようになったかというと、

  • 人月×単価に代表されるような、製造原価に基づく売価から脱却したいから(今思ってるのは、いくら儲かりそうだから、いくらで買いませんか?と言いたい)
  • 経営者視点で物事を捉えることで、どういうモノをどのタイミングでどこに売り込めば買ってもらえそうか知りたいから(会社での財務イベントに対する知識を含む)
  • Webシステムも世の中に溢れるようになってきたので、作る側もより良いモノを作らなければならない。方向性としては新しいモノと使いやすいモノが考えられるが、後者としては的確なマーケティングが必要となり、体系的なマーケティング手法を学ぶ必要性を感じたから(ただ、マーケティングって、学問っぽさを感じてしまい、実践的じゃない気がするのが嫌なトコなんだけど)
  • ていうか、受注した段階で「これ本当に売れるの?」と思うようなシステムを作らされ、実際サービスインからノーヒットノーランで試合終了、といった案件が非常に多い気がする。「これ本当に売れるの?」と思った段階からコンサルティングを行い、「これなら売れるかも」というところまで持って行けるならいいんだけど。(かつコンサルティング料もらえるし)

といった感じで、「ベンチャー経営したい」というより「(自分の立場はどうであれ)経営層に物言える技術者で居たい」といった感が強いです。

いいもんめっけ

で、これはどんな風に勉強していったらいいのかなぁと思っていたところ、良さそうなページを見つけました。

ベンチャー経営者のための資金調達マニュアルVol.1 というページなんだけど、前提知識の無いベンチャーの社長向けに、事業計画を練ってそれを元にベンチャーキャピタルや銀行から資金を得るために必要だと思われる知識をまとめた、と言った内容です。

本来は対面での教育ありきで、時間節約のため本で済ませれるものは本を読もうといった趣旨らしく、色々な本がずらずらっと紹介されています。

Vol.1Vol.2がリリースされていて、Vol.3は作成中らしい。(といいつつ、もう1ヶ月過ぎてるけど…)

Vol.1は基礎知識+総論編、Vol.2は事業計画書作成編といった位置づけみたい。

早速揃えてみる

これは大筋自分の目的と合致するので、早速中古本を中心に買い揃えてみました。

amazonを中心に中古本を探しましたが、大半は中古本で揃いますね。中古本なので送料無料にならないらしく、購入代金より送料の方が高いくらい。Vol.1分なら、送料含めおおよそ1万円もあれば、大半は揃うと思います。(得られる知識と比べるとりーずなぼー)

あと、amazonの中古本は毎日価格が変わるので、「ちょっと高いかなー」と思ったら数日様子を見るのが良いかもですね。古本販売サイト一括検索 と併用するとか。

時間があるときに読んでみる

ということで、これから暇を見つけては、感想を書いてみます。

まぁ、ベンチャー経営者のための資金調達マニュアルの目的と自分の目的は完全に一致しないであろう点と、そもそもの前提知識が違うので、一部無駄と思われる本もあると思いますが、そこは中古本使うので良しとして。

フォーカスリーディングの教えに則り、読む価値無しと判断した部分はズバズバ飛ばし読みするので、その分評価が良くない本が出てくるかもです。

2008年12月6日土曜日

フリーランスを代表して申告と節税について教わってきましたを読んだ

あーそろそろ年末だし、税金とかどうすっかなー、ってかおれ全然知識無いじゃんヤバイよおれ、と思って速攻amazonで買って、届いたその日に徹夜して読みました。(笑


"フリーランスを代表して 申告と節税について教わってきました。" (きたみ りゅうじ)

フリーランスを代表して申告と節税について教わってきましたを読もうと思った理由

  • もともと税理士の勉強しようかなぁと思ってたので、こういうのに興味があったから
  • フリーランスとしてやってくのと、会社員としてやっていくのは、どっちにどんなメリットがあるんだろうと思ったから
  • amazonの評判が良かったから(結構amazonのコメント見て決めるの多いなぁ)
  • 「フリーランスを代表して〜」なので、立場的にぴったりだったから

フリーランスを代表して申告と節税について教わってきましたってどうよ?

  • タイトル長いよ
  • 基本的に、フリーランサーの著者と、税理士の先生が会話するスタイルで書いてあるので、とても読みやすい
  • 申告とか税理について、現実に即した視点で、仕組みからポイントまでわかりやすく解説している
  • 読みやすい割に、ぶっちゃけが多くて実用的。まぁ、税理の面白い面というか、節税のキモというか
  • 「一人で仕事してます」みたいな規模をターゲットとしているので、立場的においらにピッタリだった
  • 青色申告って何がうれしいのか、どこまでが必要経費?とか、勘定科目はどれにしたらいいの?とか、税務調査って実際どうよ?的な、本当に知りたいところがきっちり書いてあって良い感じ

で、どう思ったか?

  • 考え方とか要点は、この一冊で十分だと思う
  • 細部は省いてあるので、本格的にやるならハンドブックがもう一冊必要だと思う
  • さくっと読めて実用的なので、時間がない人や、本格的に覚える前の総論的な使い方がオススメ
  • 買って良かったです

オススメできるか?

んーと、フリーランサーは間違いなく読んだ方がよいです。

2008年12月5日金曜日

英語嫌いの東大卒が教える私の英語学習法を読んだ

ええと、最近マジメに英語を勉強しているのですが、どう勉強したら効率的なのか疑問に思う部分もあったのでこの本を読んでみました。


"英語嫌いの東大卒が教える私の英語学習法 (アスカカルチャー)" (小川 慶一)

英語嫌いの東大卒が教える私の英語学習法を買おうと思った理由

  • サイトで紹介されていて、結構評価が良かったので興味を持った
  • 実際に本屋で立ち読みしてみて、あーなるほどねーと思う部分があったので買ってみた
  • 特に、うまく勉強時間を確保して、如何に効率的に勉強するかを、科学的に理論立てているのが気に入った

英語嫌いの東大卒が教える私の英語学習法ってどうよ?

  • TOEICで点を取りたいなら、まずはボキャブラリ重視。TOEIC500点ぐらいから文法知識も重要になるけど、最終的にはやはりボキャブラリが重要になる。
  • 覚えたことを忘れないようにするには、まず復習すること。そして覚えるときに強烈なショックを覚えること。でも、極論的にこの二つは同じ事。
  • パッシブ・レビューよりアクティブ・リコール。要は、何度も読み返すより、考えたり書いたりする方が効果的。
  • 人間が一度に覚えられる数は7個まで。これをチャネル・キャパシティーと言う。
  • 効率的に覚えるには、背景事情や理論から覚える、各論より総論から覚える、順番を入れ替えたり、カテゴリー化したり、語呂合わせと音で覚えたりすると良い
  • 単語はコンセプトで覚え、訳は覚えない
  • 「マクドナルド」を聞き取れないとき、日本人は「まー・くー・どー・なー・るー・どー」と同調同長で言うけど、英語圏の人は「ダナーズ」と強弱をより強調して言う。これが日本語と英語の音の違い。
  • ラテン語系の単語は、語源に接頭辞・接尾辞などをつけて機械的に組み立てられたような構造になっているものがある。語源の数は数百だが、そのバリエーションは多く、要点さえ覚えれば理解もしやすい。
  • 語学の勉強では、わかってもわからなくてもいいから、適当にがんばったらさっさと次に進むのが大事
  • 成果 = 環境 × 集中 × 時間

で、どう思ったか?

  • 私の英語学習法と題しているだけあって、効率的な学習法と、学習時間の確保の仕方や、効率的な時間配分など、実践に即した内容に、大きくページを割いている
  • 学習内容はTOEICに絞ってあるので、この通りにやるだけだと、読めるけど、書いたり話したり出来ないと思う。ただ、効率的に学習するには、ちゃんと読めるようになってから、書いたり話す練習をした方が良いと他の本にも書いたあったような。
  • 結構さくっと読めて、それでいて気持ちいい。理解した気になる。
  • やっぱり如何に効率的に勉強するかを、科学的に理論立てているのは、読んでいて気持ちが良い。(プログラマだからなんでしょうねぇ)

オススメできるか?

英語学習に限らず、語学系の学習、もっといえばあらゆるモノの勉強をする前に読んでおくことをオススメします。特に会社員など、時間が限られてしまう方へ。

自分の子供が大きくなっても、機会があれば読ませると思います。

関連すると思われるサイト

ボキャブラリ重視というあたりは、結構核心突いてる気がする。

英語ができないたった1つの決定的な理由

2008年12月4日木曜日

フォーカスリーディングを読んだ

最近色々思うことがあって、年末年始はたくさん本を読もうと思っています。

で、おいらは他人様より本を読むのが遅いので、このまま読むとすごい時間を消費してしまいそうだったので、最近売れているらしいフォーカスリーディングという本を読んでみました。


"フォーカス・リーディング 「1冊10分」のスピードで、10倍の効果を出す いいとこどり読書術" (寺田 昌嗣)

フォーカスリーディングを買おうと思った理由

  • 大量の本を読むための時間を節約しようと思ったから。
  • ソレ系のサイトでとりあげられていて、まぁ、悪くない評判だったので。
  • amazonのコメントなどで、昔の有名な本の焼き直しみたいなことも言われてるけど、逆を言うとそれって結構的を得ていることが書かれているってことだよね?
  • 「10分で本が読める」とは言ってないこと。「1冊10分のスピードで、10倍の成果を出す」と書いてあるだけで。要は妖しげ速読術の本では無いと思ったから。

フォーカスリーディングってどうよ?

結構はっとすることが色々書いてあります。

  • この本は、「本を早く読むための本」では無い
  • この本は、「如何に効率的に読書によって知識を得るか」について書かれた本。要は「本の読み方」について書かれた本
  • 読書の投資対効果 = (著者の力 × 読者の経験値) / 読書にかけたコスト × あなたのビジネス力
  • 本を読む前に、なぜ本を読む必要があるのかを明確にする
  • 全文を読む必要はない。細部を捨て、必要なところだけ読む
  • 1回で全てを読むのは非効率かもしれない。実は浅く数回読んだ本が理解が早いかも知れない。
  • 得るものが少ない本は、途中でも読むのを止める。おいらの場合、本の価格より本を読むための時間コストの方が高い。得るものが少ない本を読むより、プログラミングした方が良い。
  • 本を買わずに、本を読んだ友達をお茶に誘って、ポイントを聞き出した方が効率的かも
  • 狩猟採取型読書と農耕型読書を意識する
  • 一応速読についても書いてあるけど、あまり重点は置いてない。こういうことができたら、読み方に幅が出来るよー程度。でもかなり具体的に書いてある。

で、どう思ったか?

  • どちらかというと、おいらが良く読むような技術書ではなく、ビジネス本を読むときのことを対象に書いてある気がする。技術書だと、前提条件が分からないと以後の話が理解できないので、飛ばし読みできないからね。
  • 全文を読む必要はない、という部分には結構ショックを受けたかも。確かにそうだよねー。読む速度が遅いなら、如何に読む文書量を少なくするか、に重点を置くべき。
  • 速読については、あーそうなんだー程度。おいらにとって速読はやはり嘘臭さがあるので、「全文読まない」の方がインパクトがあって、現実的に思えた。
  • 大事なのは、本を読むことではなく、本から得られた知識を使うこと

オススメできるか?

うん、1100円と安いし、本をたくさん読む必要がある人や、上記で興味を持った人は読んでみると良いと思います。あると思います。

この本を読んだあとに見たら良いと思うもの

本の選び方が参考になりました。。

桁外れの数読むためのインプット&アウトプットする方法

いつもたくさん読んでいる人のノウハウ

読書を単なる知識取得ツールで終わらせるのはモッタイナイ!

中古本の横断検索サイト。有名な本なら結構安く手にはいるかも。

古本販売サイト一括検索

2008年12月1日月曜日

android勉強会 in 札幌+android周辺事情のまとめ

11/28にJavaFesta2008にてandroidに関するセッションが、11/29にandroid勉強会 in 札幌が開かれ、勉強会に関してはスタッフとして参加してきました。

1週間前まではandroidに関してあまり知らなかったのですが、スタッフになった関係もあって今週ちょこちょこと情報を集め始め、勉強会などを通していろんな情報が集まったので、まいむぞうの主観で見たandroid観+勉強会まとめ+ぶっちゃけトーク的に列記してみます。

androidの採用に適した状況

正確にはandroidの採用に適している(とまいむぞうが勝手に思っているもの)です。

  • 外出中に座っている状況以外で使う(=ノートPCは使えない状況。処理能力や表現力はノートPCには敵わない)
  • 常駐アプリを常に起動しておくような使い方(=その場その時に合った情報を提供。秘書アプリなど)
  • 組み込み業務系ハードの制御用フレームワークとして。既存の組み込み向け開発環境は、専用のIDEとCまたはC++の組み合わせであり、独特の進化を遂げてきた(=一般的なJavaの開発環境水準には遠く及ばなかった)が、一気に追いついた(=開発コスト減少)。またフレークワーク部分のソフト代金が不要になるので、一台当たり単価も下がるのでは? これと相まって、今まではハードの調達コストや組み込み用のプログラミング環境を使わざるを得ないので参入障壁が高かったものが、androidであればかなり下がるのでは? 特にタッチデバイス系など。

大事なこと

  • 最初から全世界を狙うべき(日本での展開がどうなるか、受け入れられるのかも含め、防衛戦は張るべき)
  • androidではintentを通して他のアプリに問い合わせが出来る以上、早期にシェアを取ってしまえばその類のデータプロバイダとしてデファクトを取れる可能性が高い(ユーザとしては同種のソフトを複数入れるより、1つで済ませたいはず。容量的アプリ間の相性的に)
  • 携帯用ソフトは無料もあるけど、実用性が高ければ有料でも買う、という風潮がある(=良いモノは販売できる。広告モデルに頼らない。iPhoneはこれでいいが、androidマーケットはちょっと風潮が違う可能性も…)
  • 現状、英語読めないとキビシイ(ドキュメントがほとんど英語)
  • 勉強するならみんな1つづつ作りたいアプリを考えて、コツコツ作っていくのが一番良いのかも。

ぶっちゃけどう?

  • Javaであるための3大要素である「文法」「標準ライブラリ」「バーチャルマシン」のうち、androidは文法しか準拠してないので、Javaとは似て非なるモノとして扱わなければならない。
  • とはいえ、ソースコードレベルでは標準ライブラリもそこそこ同じモノが入っているので、既存のJava用サードパーティライブラリも、とりあえずコンパイルしてみて通れば使えそう。方向性としてswingなどのGUI系ライブラリはごそっと落ちているみたい。(これって結構楽しい未来が待ってる気がしませんか?)
  • 現状のandroidはG1専用のコードも混じっているなど、まだ完成とは言えないレベルのようだ。ぶっちゃけG1発売前は相当厳しかったらしく、ハードメーカーが相当頑張ったらしい。
  • このような事情から、android搭載機が出たての数台は、android間でも互換性問題が浮上するかも? 実際問題、エミュレータでは動作するけど、G1では動作しないアプリケーションが大量にandroid marketに登録されているらしい。(どうすんのコレ?)
  • FlashLiteではなくFlash 10ベースのプレイヤーがandroidに載ったというニュースが流れて居るみたいだけど、ぶっちゃけ完成度は「いまひとつ」らしい。具体的にはFlexはまだ動かないんじゃないかな、みたい。ただ、相当気合い入っているようなので、これらの解決は時間の問題っぽい。

個人的に聞きたかった事

主にネットや本や勉強会など多方面から収集したものです。

  • androidの海外での反応は? 盛り上がってる? →一般ウケのレベルはちょっと把握できてないけど、開発者レベルの話であれば、本家googleグループへの投稿量がハンパ無いことからかなり注目されているのでは? ちなみに日本以外では本家が活動の拠点のようです。(ので、まじめにやるなら追っかけるべき)
  • layoutとstrings.xmlを分けている理由って、多言語に簡単に対応するためだと思うけど、具体的に言語リソースを変えるにはどうすればいい? →本に書いてあったので読めばいい
  • 日本でのandroidリリース情報は? →来春(4月か5月)ぐらいかな?
  • ケータイとしてのandroid以外の状況は? 業務用組み込み機器とか。 →android周辺ではarmadilloが注目を浴びている。実際に展示会などでもかなり手応えがあるみたい。
  • androidでゲームは作りやすい? →良い面と悪い面があるけど、メモリとCPUの分携帯アプリよりは作りやすい。
  • androidはどうやって配布するの? →コンパイルするとapkファイルが出来るので、これをデバッガ経由でインストールするか、HTMLに貼っておいてクリックしてインストールするか、android market経由でインストールする。
  • android marketからアプリをダウンロードしてエミュレータで動かすことは出来る? →現状、G1などの実機でなければandroid marketにはアクセスできない。ただし、今は有料ソフトがないので、手元にapkファイルがあればエミュレータなどにインストールできるかも。
  • QR画像を解析して文字を取り出すようなライブラリは存在する? →Javaの既存のライブラリでそういうのがあるらしい。(未確認)
  • たとえば、新しいセンサーなどをメーカーが作って、それをandroidにくっつけたとして、android用のデバイスドライバを新しく書くのって難しい?(携帯端末としてはあまり出ないだろうけど、armadilloとしてなら需要が高い気がするし、簡単にできるのか、それなりに時間が掛かるのかによっても状況は変わる気がする。 →まず、市販されるandroidはコア部分をいじれないようになっているので、基本的には追加デバイスは扱えない。エミュレータもしくはarmadilloならばこのあたりも可能だが、アットマークテクノさんに聞いてみたところ、まだデバイスドライバの詳細は掴めていないみたい。ちなみにgainerをくっつけるサブプロジェクトが動いているみたい。(というか半分当事者なんですが)
  • activityって一言で言うと何? 一時期にアクティブになれる一単位という理解は正しい? →基本的には画面一枚と思って良いみたい
  • 参考にarmadilloのロット単価知りたい →話を聞くと、色々組み合わせがあるようなので、やはりアットマークテクノさんに直接聞いた方が良さそう。
  • 業務用機器のように、電源入れたら特定アプリだけが立ち上がるようにできるか? →標準のランチャーもいちアプリケーションなので、これを差し替えれば可能かも。(未確認)
  • T-MobileのG1を入手する方法は無い? →ヤフオクで普通に売ってるね。使用上の注意はあるみたいだけど。
  • android marketでの収益性ってどう? →iPhoneのAppStoreとはビジネスモデルが違うし、まだ決まってない部分が多いので、正直分からない。が、有料化開始までにある程度の期間があるため、有用なアプリは無料期間中に出尽くしちゃって、「アプリは買うもの」という文化にならない可能性もある。
  • android marketって登録するのって難しい? →実は簡単らしい。$25払って、登録時に自分の証明書でデジタル署名する必要があるみたい。
  • 赤外線通信ってサポートされてる? →たぶん、ないような気がする。

Macにセットアップするなら

自分でセットアップしたときのメモです。ネット上にMac用の設定が見あたらなかったので。

  • エミュレータ初回起動時にandroid用のデータ格納先を聞かれるので、~/.androidを先に作っておくと良い
  • JDKはSunからじゃなくてAppleから出てる。ソフトウェアアップデートで入る
  • envでJAVA_HOMEがあるか確認。無ければ作っておくと良い。
  • インストール済みJDKは/System/Library/Frameworks/JavaVM.framework/Versions/に置いてあるはず
  • keytoolのパスはwhich keytoolで探すのが早い
  • MacでAndroid API Key用のfinger printを取得するには/usr/bin/keytool -list -keystore ~/.android/debug.keystoreでOK。~/.androidは先に作ったパス

まぁ、あまり重要なことではないのですが。

androidやるなら一度は見ておくべき

市販の本である


Google Android入門 ~携帯電話開発の新技術」で周辺事情を押さえ、


"Google Android完全解説 (アスキームック)" (アスキー)で実際のプログラミングに必要な知識をおさえると良いかも。

これ作ったらどうよ?

個人的に思いついたandroid用アプリのアイデア。(まだまだですな)

  • 絵文字対応メーラー(UTF8で絵文字サポートという流れもあるようですが…)
  • 飲食店の待ち行列の管理(順番が来たらメールで通知)
  • 自分のgoogleカレンダーからのスケジュールを読んでサービス提供&秘書ソフト

今後の予定

「札幌Javaコミュニティ内日本androidの会北海道支部」ぐらいのスタンスで、北海道におけるandroid関係の活動を続けていくことになりそうです。(詳細は検討中)

ただ、いかんせん人前で話せるほど知識量がないので、札幌Javaコミュニティ内でちょっと時間もらって「今こんなアプリ作ってます」とか近況報告し合ったり、北海道のandroid関係者が集まって呑めるような感じにもって行けたらいいなぁというところです。札幌にはアットマークテクノさんやハドソンさんも居ますしね。

札幌Javaコミュ自体も、特定のJava技術に偏るものではなく、参加者の興味対象によって会の性格が変わるものなので、android勉強会に参加した方で、android技術者間のネットワークを持ちたい方は、札幌Javaコミュニティに参加してみてはいかがでしょう?

2008年11月6日木曜日

プログラマに統計学が必要な理由

最近統計学を押さえる必要性を感じて、完全独習 統計学入門(小島 寛之)を読んだ。

どこに統計学を学ぶ必要性を感じたのかと、その必要性に対してこの本はどうだったかというレビューをまとめたいと思う。


"完全独習 統計学入門" (小島 寛之)

統計学を必要と感じた理由

これは2つある。

ひとつの理由は、Webサービスのためのマーケティングをしたいなら、統計学は必要だよなと、Yahoo!リサーチの価格を調べながら思った。自分の質問に対して、何個の回答があれば十分だと言えるのかわからなかったからだ。で、その場でググっても、表面的なものしかわからず、しかもそれが正しいのか、どういう風に使えばいいのががわからなかった。

後日談で言うなら、"完全独習 統計学入門"を読んでも、この回答数をどうすればいいかはわからなかったので、他の本を読む必要がある。(調査は"完全独習 統計学入門"が対象とする話ではないんだと思う。なにか良さそうな本を知ってる人が居たら教えてください)

もうひとつの理由は、レコメンドシステム(推薦システム)を構築するときや、経営判断を行うときに統計学の知識を使いそうだ、ということがわかったから。

と言っても、「基礎理論からしっかり積み上げてきて、その応用として意志決定のために統計学を使う」って話なら遠回りすぎるので、もっと実践的に「このコードで結果を出すことが出来るんだけど、そのままじゃ式の意味がわからなくて応用できないから、考え方を知る上で基礎理論を勉強しよう」って流れなんだけど。

で、一時期ブログで話題になってたし、Amazonでも高評価だったので、"完全独習 統計学入門"を読んでみたという流れ。

完全独習統計学入門ってどうよ?

この本に書いてあることをまとめてみる。

  • 正規分布なデータであれば、平均と標準偏差が重要。
  • なぜなら、正規分布は計算によって標準正規分布と見なすことができ、標準正規分布の特徴については研究が進んでいるので、少量のデータから色々なことが分かる
  • ある条件下で検定(特定の値はあり得るか)や、それを応用した区間推定(x1~x2に値が収まる確率は何%)を使うと、高確率で未来を予測できる
  • 平均については理解が簡単だとして、あまりなじみのない標準偏差についても、深く知れば生活の上での考え方に幅が出てくる
  • 標準正規分布に対する研究が進んだことによって、現在では数個のサンプルを得るだけで、母体を高確率で推定することが可能

で、どう思ったか?

たしかに、確率や微分積分などの数学の知識は必要なく、読みやすい文章(読むのが早い人なら半日ぐらいか)を読むだけで統計とはなんぞやの考え方部分を理解することが出来たし、正規分布だとわかっているだけの状態から数個のサンプルを得るだけで母体を区間推定する方法など、かなり実践的な知識を得ることが出来た。

まぁ、数学部分をはしょってるので、応用は利かないと思っているけど、何かをするとき統計学のエッセンスを使うことはできると思う。

オススメできるか?

本当に区間推定をするまでの最短経路しか触れていないので、短時間で凄い知識量を得た気になる。そういう意味でオススメ。

でも、実際には骨だけで肉が無いわけで、この本だけで統計を使いこなすのはムリだとも思う。

まぁ、統計学の一番の基礎理論は理解できたので、必要なら実践的な知識を付加することもできるだろうし、レコメンドシステムなどの基礎知識としても使えると思う。

2008年11月2日日曜日

第1回北海道情報セキュリティ勉強会に参加しました

第1回北海道情報セキュリティ勉強会(通称せきゅぽろ)へ参加してきました。

今回は第一回ということもあって、がっちりセキュリティというよりは、セキュリティ周辺事情といったノリでしたが、参加費1000円にもかかわらず、50人弱の参加者が集まり、期待の高さを伺わせました。

サイボウズの竹迫さんや、まっちゃだいふくさんのトークは会場を沸かせましたが、もっと突っ込んだ話を聞きたかった人も多かったはず。

東京と比べて札幌は保守要員より開発者が多いらしいので、(勝手に)開発者を代表して、次回聞きたいことをまとめます。

ちなみにおいらサーバも立てれるプログラマ、という立ち位置なので、ちゃんとしたセキュリティの知識があるわけではありません。的外れだったら突っ込みよろしくお願いします。

実践的なセキュリティ対策の要点

まず、実践的なセキュリティ対策の要点って大きく分けると以下の5つなのかなぁって(勝手に)思った。

  1. 不要なサービスやデーモンを停止する
  2. 色々なログを取り警報を出す
  3. セキュリティスキャナで既存のシステムをチェックする
  4. (ログやスキャナやニュースなどで)見つかった穴を埋める
  5. 定期的にバックアップ

で、この5つが正しいと仮定すると、ある程度の所までは定型パターンに落とし込める気がした。

たとえば、RedHatをPHPとMySQLを動かすWebサーバにするならば、デフォルトで起動している○○と××デーモンは不要(1)で、my.confで△△の設定はOnにしてバイナリログやスロークエリーログなどを有効(2)にし、snortやswatchなどの網を張る(2)。その上で完成したシステムに○○スキャナや××攻撃を仕掛けることよってセキュリティをチェック(3)し、見つかったセキュリティホールの原因がデーモンならばパッケージシステムのアップデートやパッチを(4)、構築したアプリケーションが原因ならばその是正措置をとり(4)、ありかじめ打ち合わせ済みのリスクを担保できるよう、LVMでスナップショットを取って丸ごとバックアップするシステムを構築の後テストする(5)。みたいな。

実際はもっともっと細かいんだろうけど、それでもチュートリアル風に落とし込むことは可能で、それだけでそこそこセキュリティは保たれる気がする。しかもここまでの流れって、費用対効果的には抜群なんじゃないかな。ちゃんと出来てない人いると思うし。

もしこれが可能ならば、ぜひ勉強会で共有したいなぁ。

無料でどこまで現実的な対策が出来るか? その閾値は?

おいらのように、1件数百万の仕事をしている人だと、セキュリティ専用のプロプライエタリ製品まで予算が回らない。

じゃあ何もしないとかというと、オープンソースモノである程度まではいけるんじゃないかと。

上の例が既にそうなんだけど、(あまりガチガチにして運用が大変になるようなものは除外して)オープンソース同士の組み合わせでどこまでの事が出来て、「どういうケースだと、プロプライエタリ製品を使うことで、どこまでの問題がクリアされるか」っていうあたりがノウハウになる気がするので、こういった事例を共有できればいいなぁ。

プロプライエタリ製品が嫌いって事じゃあないんだけど、それがなきゃ何も出来ない訳じゃあないだろうし、費用対効果的に、プロプライエタリ製品を使うべき閾値を共有したいだけなんだけど。

システムの性格による使い分け

お金を扱うシステムなのかとか、保守要員は居るかとか、そもそも保守に当てる金はもらってるのか、などなど扱うシステムによってどこまでセキュリティを確保するか異なってくる気がする。

先のチュートリアルにしても、

  • やっべぇので手間を惜しまずガチガチセキュリティ重視
  • 完全自立でヤバイときだけ教えてくださいな運用手間重視
  • 結局は壊れたときに直せれば良いんでしょなバックアップ重視
  • 自社システムなのでリスクは許容するけれどな予算重視

とか、現実的に採用可能な方針ってのは複数ある気がする。

新しい製品やサービスによって今までの世界観が覆るようなもの

たとえば、バックアップシステムなら、深夜にシステムを止めてサーバ毎に接続してあるオートローダのテープにバックアップするんじゃなくて、LVMでスナップショット取ってAmazonS3に転送しちゃうとかね。

保管場所や帯域が許せるなら、AmazonS3は安価なシステムのバックアップ先としてかなり有望だと思うんだ。

で、こういった選択肢に含まれるような製品やサービスの情報を共有できればいいなぁとか。

対象システムによって開催日を分けるとか

そもそも、WindowsなのかLinuxなのかで実際の対策は大きく違ってくる気がするので、概念的な話だけする日、主にLinux関係の話をする日、主にWindows関係の話をする日に分けてもらった方が良い気がする。

個人的には、Windowsを使ったシステムを構築するつもりはないので、Windowsの話ならば参加しないと思う。


そんなこんなで、今後のせきゅぽろに期待!!


2008年10月31日金曜日

gemspec.infoのβバージョンをリリースしました

えーと、札幌Ruby会議01以降あまりいじってないのですが、一応αバージョンからβバージョン扱いに移行しました。

バージョンアップ内容

  • ほぼ全てのバージョンの詳細情報を入力させた(いくつかは機械的に取得することが難しかったので諦めた)
  • サーバサイドのバッチ処理が重くて共用サーバに迷惑をかけたので、処理内容の見直しと、タイムアウト処理や高負荷時にバッチ処理をスキップする機能などを盛り込んだ(もう大丈夫なはず)
  • 細かな表示内容の調整

現在3700弱のgemがあり、それぞれのバージョンを保持しているので、17000弱の詳細情報を管理していることになります。

ごめんなさいな内容

仕様として諦めたものがあります。

  • どういうわけかspecファイルを取り出せないgemがあったけど、実害が無いだろうと思って諦めました。gem開いて左側にNO DATAと表示されていたら(かつ結構前にリリースされていた物だったら)諦めて自分でインストールして内容確認してみてください
  • 途中でRubyGemsの仕様が変わったらしく、以前は大文字小文字を認めていたものが、途中で小文字統一になったようです。よって、同じ内容のgemなんだけど別のgem名になったものがあります。(ANTFARMとantfarmとか、Bangkokとbangkokなど) 幸いdowncaseでまとめれるものばっかりだったのでgemspec.infoでは小文字側に合わせてあります。
  • 環境毎にコンパイルが必要なgemがありますが、gemspec.infoの設計上、全ての環境の分の情報は保持できないので、globして最初に引っかかったgem(windows用が多かった気が…)のspecファイルを使っています

まぁ、数は少ないので実害はないかと思います。

機能拡張予定

札幌Ruby会議01でいろんな方と話をする機会があり、不満点やアイデアを貰えたので機能拡張予定に盛り込みます。

  • gemをインストールする前に、そのgemがどんなものであるかを共有する、というgemspec.infoの方針に合致するので、最新gemからrdocを生成してサイトから見れるようにする予定です。
  • rdocもそうですが、specファイルの取得に関しても、現在は手元の開発マシンでデータ抽出を行って、サーバに転送していることが多いのですが、これをうまく自動化できないかなーと。と言っても、サーバのリソース制限がキツイのでマシンパワーが費用名処理は開発マシンで行うような流れになりそうだけど、データ同期が複雑になるしなぁとか考え中
  • githubなど、RubyForge以外のgemにも対応する。でも、ちょっと問題もあるので、詳細は下記参照
  • 開発はMacOSX10.5+Firefoxでしていて、他のブラウザは一度も開いたことがなかったので、ブラウザ互換性をもうちょっと頑張る。てか現状をIE7で見たらダメすぎて萎えた。githubでソース公開して、みんなに助けてもらうのがいいのかな。
  • うんちくでURL指定したときなどに、相手先のコンテンツを取得するタイミングでトラックバックできないかな? トラックバックURLを取得する標準的な方法ってあるんだろうか?
  • ブラウザ互換性の問題とか、オープンソースの強みを生かすには、早めにgithubとかで公開するのがいいかなーとか。(開発マシン・gitリポジトリ・サーバの3点間でcapistranoでデプロイできるんだろうか)
  • とかとか書き殴ると、自分で管理できなくなってくるので、retrospectiva使おうかと思うんだけど、どっかに無料で使えるサービスとか無いかな?

RubyForge以外のgemリポジトリへの対応に対する問題点

個人的にはgemで提供されている機能を一部改造してプラグインにしたり、別名で管理されたりなどしている現状にちょっと疑問を持っていて、本家にマージされて集約されれば便利なのに、そうならない問題への解決策として、githubのgem対応はとても便利だと思うし、gemspec.infoもすぐにgithub対応したいと思っています。

ただ、ちょっと検討してみるといくつか問題がありました。

gemspec.infoはgem名やその詳細を得るのにgemコマンドを使っており、

  • gem list -raコマンドで全gem名と全バージョンが取得できること
  • gem mirrorコマンド(またはrsync)コマンドなどで、インストールせずにgemファイルが取得可能なこと

の2つをクリアする必要があり(下記の理由によりgem sources -addは使いたくない)、またgithub特有の問題として

  • githubで提供されるgem名はユーザ名+ダッシュ+gem名の形で提供されることから、RubyForgeで提供されるgemと名前が重複する可能性がある このへん参照 InfoQ: GemのソースとしてのGitHub とRubyForgeの長所と短所
  • これを回避するため、gem sources -addコマンドでgithubのリポジトリを追加するのではなく、githubにあるgemをインストールしたいならgem install --sourceオプションを使って明示的に指定した方が良い→gemspec.infoとしてはインストールオプションの表示機能が必要かな
  • 他のgemリポジトリをサポートすることによる既存のデータベース構造への影響。特にGemやバージョンのIDとして文字列を使えるよう、friendly_idというプラグインを使っているので、ここをうまく回避できるかどうか

とか、おそらく他にも野良gemリポジトリはたくさんあるんだろうから、どこまでサポートして、それらにはどんな問題があるのか、とかとか。

gemspec.infoを使用|紹介|協力してくださった方々へ

いつもごひいきにありがとうございます。

moroさんにはrails勉強会で紹介していただいたとか。ありがとうございます。

gemspec.infoの開発自体はおいらの趣味がてらといった感じなので、クリティカルな物以外はこつこつやっていこうと思っているところですが、次の件については一人の力ではどうしようもないかなーと思うので、お手すきの時に助けて貰えると有り難いです。

  • ブラウザ互換性に関すること。今回jQuery使ってみたんですが、まだ慣れてないのと、元々ブラウザ互換性に対する知識が乏しいので、「こうじゃぼけー」と書いたパッチなんぞ送ってくださいましたら、即適用でございます。
  • まずはそのgemで何が出来るか、といった部分をまとめていく必要があると思います。gemspec.infoで言うところの、1行メッセージ(何/良/悪)とか、タグなど。じゃないと、同じようなgemが乱立すると思うので。自分でも分かる範囲で書いているんですが、ここを書けるのはある程度使い込んだ人だと思うので、自分の力だけでは50個ぐらいで限界のようです。(検索機能がまともに動かないとコンテンツを活かせないので、そこはおいらがんばりますです)
  • 最近のおいらがそうですが、gemに関する事をググるとき、検索結果から探している答えの候補をタブでポコポコ開きますよね。で、そのうち何件かが答えになると思うんですが、そのとき残ったタブのURLをgemspec.infoに登録しませんか? メモ代わりとして。たぶん同じ事を検索する人がいると思うので。本当は、ブックマークレットみたいなのがあればいいのかなぁと思ったり。(ブックマークレットのテンプレートないのかな?)

2008年10月30日木曜日

札幌Ruby会議01の感想

てか、おいらはるびま原稿担当で、まだ書ききってないので、おいらにとってのRuby会議01はまだ終わってないぜっ(何?

でも、この調子だといつまで経っても感想を書かなそうなおいらが居るので、ここで簡単に。

いやー凄かったですね、札幌Ruby会議01。おいらRuby界の流れとかエライ人(良い意味で)はあまり知らないのですが、発表内容から察するに相当コアな人ばっかりだったはず。

また、道外からの一般参加者も凄い人ばっかりでしたね。

誰かも言ってましたが、内容や会場設備は3000円ぐらい参加費取ってもおかしくないぐらいだったと思います。

発表内容も良かったと思いますが、Ruby(というかシステム構築全般)に詳しい人と、くだけた場で雑談できたのは凄く刺激的で、ためになりました。ライトニングトークやってよかったー(最近は懇親会まで参加することが少ないのですが、札幌だとあまり濃い話をできる人が集まらないし、LTは話のネタにもなりました)

さて、大成功に終わって満足度も高かった札幌Ruby会議01ですが、改善が必要かなと感じた部分もあったので、感じたことをまとめます。

参加受付開始から1日で定員に達するのは問題だと思います

実際、迷っている内に締め切られたって知り合いが結構居たようです。が、これは運営側の落ち度ではなく、期待が高過ぎたのが原因でしょうね。1回目から需要を読むのは難しいですし。

会場はずっとサテライトを使うのならば、もうちょっと席を増やしても大丈夫な気がしました。(サブスクリーンと音響設備が整っていたので)100席+立ち見も受け入れて良いかもと思いました。スイーツタイム用の机を外に出せばもうちょっと入るかなぁとか。(どこまでが借りられるスペースなのか知らないのですが)

結果論になっちゃうけど、来たいけど(会場スペース的な理由で)来れない人が居たのは、やはり残念でした。

あとは、外部に会場を探すとかでしょうか。この内容なら参加費取るのは全然問題ないと思いますし、回数を重ねて人数が大体読めるようになってから再検討でしょうか。

スイーツタイム

Ruby札幌とか、他のコミュニティのいくつかは、懇親会は設けずに、昼食会を設けていますよね。家族が居て、特に子供がいたりすると、勉強会の後に遅くまで呑めない人が居るので、じゃあ昼間にやろうかって理由だったと思います。実際、おいら最近懇親会に参加したいけど家族の目があって参加できないので、今回のスイーツタイムのような時間はとても貴重です。呑めないと(腹割って)話せないとか、呑んだら(頭が回らなくて)話せないとか、ありますけどねw

おいらスイーツタイムの趣旨を理解しないで(自分で買った物を弁当代わりに自分で食べるんだろうと思っていた)、適当に買っていったんだけど、みんなはどうだったのかな?

(スピーカー向けの交流の場としての打ち上げではなく)一般参加者同士の交流の場としてのスイーツタイムだったと思うんだけど、これはみんなどう思ったんだろう。自分は知り合いも居たし、LTの関係で話しかけられることも多かったので、おいらにとってもすごく楽しかった時間だった。

けれども、知り合いの居ない一般参加者にとっては、本番が始まる前にスイーツタイムがあったため、前提知識がないとスピーカーの方々と話すきっかけが無かったんじゃないかなと思う。(というのを、スイーツタイムに一人で観客席に座っている人を見ながら思った)

時間は1時間だっけ。あまり長くてもだらけるので、ちょうどいいのかも。でも、タイミングはセッションとセッションの間の休憩がてら、とした方が良いのかも知れない。(脳が甘い物を要求してくる頃とか)

前半堅い話、後半砕けた話。間の休憩はスイーツタイム、とかね。

セッション内容は高度な話に偏っていたような印象があります

強烈に興奮を覚えた人が居たのと対照に、全然わからなかった人も居たようです。(自分はよく知らないのですが)Ruby会議ってそんなもの、というのもあるのかもしれませんが、Ruby人口が少なく、全員モチベーションが高いと限らない地方版なのだから、Rubyピラミッドの底辺向けのものがもう少しあっても良かったのではないかな、と思いました。

提案ですが、カジュアルな勉強会の進め方 | IDEA*IDEA みたいに、あらかじめRubyに関する質問を受け付けておいて、雑談会みたいな感じでその解決法についてライブで回答・討論するというのはどうでしょうね?(たまたま記事を読んでこんなのどうかなと思っただけですが)

んーと、要は、話のレベルを落とすのではなく、Rubyをあまり知らない人とか、思いっきりビジネス寄りの人でも参加できるようなイベント(? 仕掛け?)を盛り込んでもいいのかなぁと。せっかく知識豊富な人が揃っているので。

イビキかいてた人居ましたね

まぁ、寝るのは本人の問題なんですが、同じ人が2回ってのはちょっと酷かったですね。(ちょっと見た顔な人なのですが)

5m以内の人はほとんどイビキ聞こえてたみたい。

先の高度な話ってのにちょっと掛かってくるんですが、運営側としての対応は(1 セッション内容の検討 (2 あまりに酷い人が居たなら退場願うとかでしょうか。でも、こういうのって、運営側がどうこうというより、参加者同士の雰囲気とか空気なのかなー。

まぁ、おいらの真後ろの人だったんで、おまえ言う前にやれよって感じですか(汗

個人的要望

おいらの場合、主な興味の対象がRailsなので(Rubyも好きなんですが)、Railsに関する話も聞けると嬉しいなーとかとか。

初学者用のRailsの本やRubyの本はあるんですけど、例えば↓がサポートしてないような大規模・高負荷環境での運用ノウハウとか聞きたいです。みんなが知ってるサイトなら、Twitterはどうやって負荷対策したのか、など。たぶん、知ってて作るのと、知らないで作るのは、見た目が同じでも内部構造が違うと思うので。


"Ruby on Rails 逆引きクイックリファレンス Rails 2.0対応" (大場 寧子, 大場 光一郎, 久保 優子)

最後に

スタッフの方々、本当にお疲れ様でした。次回も一緒に頑張りましょう。

次回は来年の前半でしたっけ?(うろ覚え)

楽しみにしてます。

2008年10月28日火曜日

gemspec.infoに障害発生しました

gemspec.infoがアカウント停止食らいました。

現在gemspec.infoのトップページのHTMLが静的に表示されているようです。

gemspecのbatchがスタックしてリソース馬鹿食いしてたみたいで、共有レンタルサーバで運用していたので、管理者に強制停止されたようです。

現在復旧作業中ですが、アカウント停止なので、ちょっと復旧に時間がかかるかもしれません。

ご迷惑をおかけしまして、申し訳ありません。

10/28 12:30追記

現在復旧しました。

6時間毎に起動するcronジョブが、6時間かけても終わらずにスタックしたようなので、ロジックの見直しが必要かも知れません。

具体的には、新らしくリリースされたgemやversionとspecファイルを、gemコマンドを使って取り込む処理です。

やっぱり、サーバ側での情報収集は最小にして、手元のPCでまとめ終わった情報をサーバ側に流し込むようにしないと、共用サーバではリソースが足りなくなるのかも知れません。

しばらくの間、新らしくリリースされたgemやversionの取り込みを手動で行いますので、更新が遅くなるかも知れませんので、ご承知ください。

2008年10月24日金曜日

gemspec.infoのαテストバージョンをリリースしました

RubyGemsの情報集約サイトである gemspec.info のαテストバージョンをリリースしました。

札幌Ruby会議01までに大きなバグがなければそのままオープンβテスト扱いにします。(と言ってもあと一日ですが…)

このブログはgemspec.infoの開発ブログも兼ねることになります。

実装できた機能

  • OpenIDを使ったログイン(OpenIDだけを使っているってのは珍しいんじゃないだろうか)
  • RubyGemsのspecファイルを利用したGemの基本情報表示機能
  • 一行メッセージ風の評価システム
  • ニコニコ動画を埋め込むGemCasts
  • 普通に書き込みだけじゃなく、URLを指定した参照コンテンツ(コンテンツの内容は参照先サイトの本文と思われる部分を抽出して取得)と、トラックバックを利用した書き込み
  • バージョン毎の障害情報
  • いろんなものへのレーティング
  • タグへのレーティング(使い分けの内容は正しいと思うかなど)
  • お気に入りのGem登録機能

まぁ、情報を集約するって部分は大体できたかなと。

現在未実装の機能

  • specファイルの大半がまだ取得できていない(流石に3700弱のgems/16000弱のバージョンを全てインストールするのは辛い)
  • 投票用のリンクとかはアイコンにしたいなぁ
  • 書き込みはWiki記法とか、入力補助機能付きのものにしたいなぁ
  • コンテンツの全文検索
  • レコメンデーション
  • クローンサイトとの同期機能
  • RSSやサイトマップ生成機能
  • 一応SEOを意識してマークアップしたけど、後半ぐたぐだになったから、効果は疑問(要見直し)
  • jGrowl使ったLPOエンジン(ライブドアのページで同じような仕組みを見た気がする)
  • ユーザプロフィールの編集機能(一応付いてるけど使ってないので適当)
  • オープンソースやCCとしての公開準備

開発資料

既にこのブログで紹介した設計資料です。現在の形と見比べてみてください。

ちなみに、あとで違うサイトに移すかも。てかリリース版と違ってる部分もあるし。後でアップデートします。

その他

  • てゆーか、まだまだバグ多いです
  • サーバがたまに重くなるので、新しいサーバ探すかもです
  • 色々反省点があるので、このブログにまとめるかもです
  • 一端リリースできたので、またブログ更新するとです
  • gemcastsについてはこちらをどぞー
  • gemspec.infoに何か書き込むときはOpenIDが必要ですが、ホワイトリストで縛りをかけているので、これ許可してーというのがあったら、気楽に連絡願います。(あまり厳しくするつもりはないのですが、実際のURLが無いとOP登録も出来ないので)

発表します

10/25(明日)は札幌Ruby会議01でこのサイトについてライトニングトークしてきます。

おそらくこのへん(未確認。違ってたらスマ)で中継されると思うので、どうぞ突っ込んでください。

あと、この会議のレポートも書いて、るびまに載せる予定なので、面白い写真とかスクリーンキャプチャ撮ったら教えてくださいね。

2008年10月10日金曜日

スタートアップ指向コンサルティングというビジネススタイルについて考えてみた

JWDA北海道支部月例ミーティング・拡大版「北海道のウェブビジネスについて・意見交換会」という集まりに行ってきました。

個人的には、技術者メインの勉強会は最近盛んになったのですが、経営者視点の勉強会のようなノリの集まりは無く、おいら元々ビジネスモデルやマーケティングに関する話を聞きたいなぁと思っていたので、もしこの集まりが継続するのであれば、結構期待は大きいです。

どんな集まりだったか

JWDAについてはおいら良く知らないのですが、いつも会員クローズドで集まっているところを、今回は会員以外でも参加OKということで参加してきたのですが、いつも良く行く技術者やデザイナメインの集まりではなく、経営者メインの集まりのように感じました。

具体的には、広告印刷メインでWebサイト制作もやってますというところと、受託業務システムメインでWebシステムもやってますというところが多かった印象があります。

意見交換会の趣旨としては、北海道では「カンパニーサイトなどの受託制作」と「ECサイトの作成・運営」及びその周辺業務が大半であり、これらって最近先細りしてきていませんか? 他に何かできることは無いですか? みたいな流れだったと思います。

討論会の内容については、その性質上おおっぴらにするとマズイのかもなぁと思ったので詳しく書きませんが、参加して思ったことやネタ振りなんぞしてみます。

生き残るビジネススタイル

討論会のスライドのうち、「仮説:生き残るWEBビジネス」では、自らプレイヤーになるスタートアップ系、ニッチなスキルで勝負するクリエーター系、よりコンサル色を強めたインテグレーター系、制作に特化したコーディング系と4つが挙げられていました。

おいらとしてはこの複合スタイルもアリかなと思っていて、この分類で言うとインテグレーター+スタートアップのようなスタイルです。(自分のちょっとだけ知り合いの元某ラボのプログラマが、こんなスタイルで活動しているようです)

ビジネスアイデアを発想する能力

ビジネスアイデアを発想する能力というのは、生活習慣みたいなもので、習慣が身についている人は黙っていてもアイデアが生まれ、それをその場でメモしているならアイデアが集積・洗練されていく物だと思います。

多くの人が、今不便なものは何か、自分の興味のあるモノ何かを組み合わせて新しい物を生み出せないか、という点について「注意を向けていない」のがビジネスアイデアが生まれない原因だと思います。

ビジネスアイデアを発想する能力を備えた人に足りないモノ

で、IT系以外の経営者層でも当然ビジネスアイデアを持っている人がたくさんいて、その実現手段としてIT系の技術を使う話もたくさんあるんですが、アイデアを具体化するための能力(理詰めのビジネスモデル化する為の能力)というのは専門性が高く、経営者層でも備えている人は少ないように思います。

自分の経験でも、ビジネスモデル化検討段階での検討内容が甘く、うまくビジネスモデル化できないままシステム発注、サービススタート、当然行き詰まって頓挫、という流れが多い気がしています。

現状のコンサルティングに足りないモノ

こんなケースでは、もっとコンサルティングが必要なんでしょうけど、資金を出すのも運営するのもお客さんなので、コンサルという立場で接しているとどうしても限界があります。

どうしても、自社への利益率が高い方向へ誘導してしまうでしょうし、使いそうもない機能を作ったり、逆に本当はExcelや他のソフトを使って作業した方が何かと便利な事に関しても、受注金額を上げるという理由で開発する機能に盛り込んだり、もっと低レベルな話になると、お客さんに納得してもらったり説得することに直接的な対価が発生しないので、結局踏み込めない垣根を作るのは自分だったりします。

実際問題、ビジネスモデルに欠陥があるなぁと思いながら作るシステムに情熱は入らないです。

これって双方にとって良いことには思えないのです。

インテグレーター+スタートアップという発想

そこで、インテグレーター+スタートアップという発想が生まれます。コンサル+スタートアップとした方が近いかも知れません。

自分も経営側の一人としてビジネスモデル化検討段階から参加し、うまくモデル化できたならそのままシステム構築を行い、その対価は売り上げ(もしくはキャピタルゲイン)から還元を得るというスタイルです。

大きい会社では難しいかも知れませんが、おいらのようなフリーランサーには結構しっくり来る気もします。

事業計画書を描けるか?

これを行うには、ビジネスアイデアからいくつかのビジネスモデルを立案し、それに対して効率的にマーケティング調査、売り上げ予測、システム構築費用の概算、広告費用や運営費用などを数字として算出し、マイルストーン毎のタイムライン上に収支比率やキャッシュフローを検討を経て財務戦略を立案した上で、事業計画書としてまとめ、必要ならばベンチャーキャピタルなどから資金調達するための仕組みまでを提供できるかどうかにかかっている気がします。

実際には資本比率や戦略上の理由でベンチャーキャピタルから資金提供を受けないケースもあると思いますが、他人が納得できるような事業計画書が作れるかどうかは重要な要素で、スタートアップメンバーだけが納得するような売り上げ予測やタイムライン上での収支計算は、ザルになってしまう気がします。

資本注入ではなく融資を受けたり、逆に足切りするときの判断材料になったりと、経営判断を鈍らせないための指標にもなると思います。

おいら視点で足りないモノを抽出してみる

で、フリーランサーとしてのおいらの立場から見ると、効果的なマーケティング調査方法と広告費用の算出方法、ベンチャーキャピタルとの接点の持ち方、ベンチャーに特化した財務への知識、あとは全体を通しての経験が足りていないと思います。

このうち、広告費用については使い分けとそれぞれの相場感があれば、実際に数字を調べるのは簡単に思えます。

ベンチャーキャピタルとの接点についても、見つける方法と、最初の一つの接点さえあれば、あとは納得してもらえるだけの資料を作る方が重要だと思います。

マーケティングって難しい

問題はマーケティングで、マーケティング結果としての顧客個体数が出ないと、それに客単価を掛け算して売り上げ予測も出来ません。

マーケティングと一口に言っても、インターネット白書のような既存の統計値から上記のような顧客個体数を算出したり、ビジネス上の仮説を検証するためのアンケート調査に類する物や、そもそもビジネス上の仮説を立てるためのインタビュー調査に類する物まで、多岐にわたっており、それぞれ使い分けやコストや要する時間が違ってくる気がします。

本から知識を得るような物ではなく、現場で実際にマーケティングして覚えるようなものかなぁとも思います。

でも、逆にここを押さえてきっちり数字を読めるようになると、かなり色々出来る気がするのですが、いかんせん勉強方法がわかりません。

財務も難しい

目標とすべきは、次の様な内容をぺらぺらと説明できる知識量ですが、ノウハウの世界な気がするし難しいんだろうな。

元ファンドマネージャーのシリコンバレー日記より

こちらは本職の方ですね

これもできると大きい気がするので、中小企業診断士の受験勉強もしてみようかな。

でも、実際に財務担当となるのではなく、事業計画に関わる財務知識という点で見ると、えらい人と一緒にテンプレート作ってそれに倣うって形でもいい気がする。あーでも、思想的な教育は必要だなぁ。

でも結局

これら一式をうまくまとめるための経験が重要なんじゃないかと思います。知識を有機的に結びつけた方針付けが、瞬時に出来るかどうかなど。

うまく行った/行かない、実際に使った/使わないにかかわらず、素振りの感覚で事業計画書を何個作ったかが重要になってくる気がします。

実際にはスタートアップに関われる機会なんてめったに無いし、実際に即した知識を効率的に手に入れるにはゲーム感覚で事業計画書を作ってみるのが一番なのかも知れません。

インテグレーター+スタートアップの問題点

ぱっと見、発注者と受注者の間にあった問題はクリアできるものの、作業の対価を得るのは売り上げが発生する時からなのでかなり先になり、それまでの運転資金をどうしようか、というのが直接的な一番大きな問題でしょうか。

突っ込めば色々問題ありそうですけど、きっと本当に色々あるので、あえてここでは突っ込みません。

まとめ

なんだか書き殴ったらよくわからなくなってきたのでまとめます。

  • 特化だけではなく、組み合わせによっても生き残る道はある気がする
  • Webサイトやシステムの価値を数値化できないまま進める現在のスタイルは、そろそろ限界に思える
  • 数値化するためには、おいらたちはもっと勉強する必要がある
  • みんなで勉強する場所があればいいね

以上。

ネタ振り

話をJWDAに戻して、最後にみんなで集まって話したら面白そうかなと思うネタを列記してみます。

  • アメリカ金融業界の破綻と世界同時株安の、Web業界への影響(特に広告費用は真っ先に削られるでしょうね)
  • (予測の効きそうな限界値である)5年後の業界勢力図のビジュアル化
  • 儲かっている業界と死んでる業界
  • 一般消費者がお金を落としやすいジャンルとそのユーザ層
  • 飽和状態で課金しにくいPC向けサービスと、ここ数年で様変わりし台頭するであろうモバイル向けビジネス
  • 広告費をターゲットとするビジネスと、業務効率化のためのシステム構築費をターゲットとするビジネス(MSさんが強調してましたね)
  • スタートアップを成功させるための人・アイデア・計画・金

面白そうな集まりだけに、良い流れに乗れると良いですねぇ。

2008年10月3日金曜日

IT勉強会カレンダーをうまく加工して効果的な勉強会告知手段にする方法を考え てみた

IT勉強会カレンダーって知ってますか?

※追記 IT勉強会カレンダーのリンクを間違えていたみたいなので、直しておきました

全国のIT系勉強会をgoogleカレンダーにまとめているものなんですが、おいらが予想していたよりずっと勉強会の数が多くて、一目ではどんなイベントがあるのかわからないような状況です。

おいらはプライベートや仕事のスケジューリングをgoogleカレンダー上で行っていて、元の会社では10人規模の進行管理もgoogleカレンダー上で行っていました。他の人のスケジュールを取り込んで、重ねて表示できるので便利なのです。実用的になるのは数人〜10人未満ぐらいの規模の場合ですけど、なにより無料だし、最近だとiPhoneのカレンダーとgoogleカレンダーを同期して使うサービスも出てきましたよね。

でも、上記の通りIT勉強会カレンダーを自分のスケジュールと被せて表示させると、件数が多いため実用にはなりません。一日当たりの登録件数が多く、全国の全IT系勉強会を対象にしているので、しょうがないところではあると思うのですが、せっかくカレンダー同士を重ねる機能があり、それを使うと管理が楽かつ見逃しが無くなるのが見えているだけに残念です。

北海道における勉強会の実情

んーと、勉強会だけじゃなくてイベント全般として考えると、オープンソースカンファレンス、Ruby札幌勉強会、Ruby札幌night、北海道Webコンソーシアム、北海道開発オフ、関数型言語勉強会、他にもJavaとかPHPとかとかがあるのかな。もっともっと増えてくる傾向にあると思います。

まぁ、おいらが知らないだけで他にもたくさんあるんだろうし、たぶん興味ある人なら誰でもwellcomeなイベントが大半だと思うんだけど、流石に札幌ローカルだし、主催者側としても広報に予算をかけているわけでも、マンパワーを投入しているわけでもないので、「本格的にイベントがあるかどうか調べてみよう」と行動に移せる人以外の目には入っていないのが現状なんじゃないかなと思う。大半の人は受動的だよね。

効果的な告知手段が確立してない

前に行政の力をうまく使えないか考えてみたときに、行政側の反応がイマイチだったし、うまーく回すためにはそれなりに大人の根回しが必要っぽい感触を得たので、実現性とか広告効果としては微妙なところかな。

ていうか、世の中勉強会ブーム(?)に沸いているのに、こうしとけば俺様の趣味に合う勉強会の情報はバッチリだぜべいべー的な、デファクト告知手段が確立してないのは問題だと思う。

勉強会に参加するような人は、結構アクティブに情報を収集しているような人だろうから、それなりにイベントの情報も得ているんだろうけど、それでも個々のブログレベルで告知しているようなイベントを100%キャッチするのは無理だと思うのです。

逆に、今一番現実的な手段は、IT勉強会カレンダーだと思います。

ただ、上にあるように現在のIT勉強会カレンダーは日本全国を対象としているので、普通に見るのでさえも不便だし、ましてや自分のスケジュールにオーパラップさせるのは無理です。

なので、IT勉強会カレンダーから「北海道」と「札幌」という文字を含むイベントだけ取り出したカレンダー を作ってみました。

※追記 公開設定になってなかったようなので、直しておきました

てか、おいらのブログで紹介したスクリプトをプロキシ的に噛ませただけだけどね。

※絞り込み文字は好きなものを使えるんで、他に需要があれば作りますよ

で、これをうまく加工して発展させる

コミュニティベースのイベントが一番集まるのはIT勉強会カレンダーだとして、これを勉強会などのデファクト告知手段に据えるには、

  • イベント主催者は、会場押さえたらまずIT勉強会カレンダーに登録。その際、興味範囲が被りそうなイベントが固まるのは避けてね。
  • 上記のような特定キーワードでフィルタリングしたカレンダーを公開する程度ではまだダメで、登録しておいた特定キーワードにマッチするイベント情報とリンクをメールで送りつけてくるぐらいのシステムが欲しい(あ、またアイデアが・・・)
  • こんな感じが当たり前になって、世間一般の認識として、イベント情報が欲しかったらIT勉強会カレンダー(もしくはそれを加工したサービス)という認識をもつまで認知させる

のが必要だと思います。

てか、基本ボランティアのコミュニティベースの勉強会で、かつ技術者らしく「無いものは自分で創る」精神にベストマッチする手段だと思うのですが、どうでしょう?

上記のようなメールで配信するシステムも、1つあれば全国で使えるし、個人で作るのにちょうど良いサイズだと思うんだけどなぁ。

その他googleカレンダー系お役立ちリンク

IT 勉強会カレンダーのFeed紹介しておきます - インフラ管理者の独り言(はなずきん@酒好テム管理者)

地域ごとにフィルタリングしたFeedno-agenda - IT 勉強会カレンダーのFeedを自分向けにしてみた

自分のカレンダーに予定を追加するためのボタンジェネレータGoogle カレンダー

IT勉強会カレンダーへの掲載申し込みIT勉強会カレンダーに情報を下さる方へ - インフラ管理者の独り言(はなずきん@酒好テム管理者)

エリア毎ではなく、イベント全体をキーワードで検索できるカレンダーIT 勉強会カレンダー検索

10/23追加

IT勉強会カレンダーをフィルター - はこべにっき (フィルタリングなどの考え方を参考にしました。自分メモ)

2008年9月27日土曜日

gemspec.infoのER図

gemspec.infoのモック からの続きで、今回はER図を作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのER図がそのページです。

ER図の作図に使ったWWW SQL Designerにはエクスポート機能なんて機能はなく、スクリーンショット取るのもどうかと思ったので、使ったツールのデータファイルをそのままアップロードしてあります。

ER図で検討すべき事

先のエントリで言ったように、そのシステムで何が出来るか、どうやって処理するかはER図で検討すべきです。

まぁ、Webアプリの場合は(言語内の)オブジェクトはリクエスト毎に作り直されるのが普通なので、ユーザが入力したデータは、データベースに全て揃うはずですから、ER図を元に処理の方法を検討するのは道理なのかなと。

Railsの場合はActiveRecordが素晴らしいので、データベースの種類(MySQLなのかPostgreSQLなのかSQLiteなのか)は、あまり意識せずに設計できますが、高負荷になることがあらかじめ予想できたり、位置情報を扱いたい場合などは、設計当初からある程度絞り込んでおく必要がありそうです。

ちなみに、おいらの持っているイメージ(あくまでイメージであって真実ではないかも)

  • SQLiteはぽん付けで設置したい時に使う。性能を期待してはいけない
  • MySQLは最新版以外を使う価値は無いと思う。更新量が大きい場合に有効なクラスタリングのエンジンがあるので、そういう時には必ずMySQLを使う。それ以外ではPostgreSQLとあまり大差無いイメージ。
  • PostgreSQLは必ずしもインストールされているモノではないが、過去のバージョンでもそれなりに使えるイメージがある。単体での性能が良いイメージを持っているので、スケールアウトではなくスケールアップを狙うならこちらかな。PostGISが素晴らしすぎるので、位置情報を扱うなら黙ってこちら。

RailsでERを設計するときの注意点

今まである程度ちゃんとした規模のシステムをRailsで作ったことがなかったんだけど、実際にgemspec.infoの設計をしてみて感じたことがいろいろあるので、 まとめてみます。

コードジェネレータの影響が大きい

まず驚いたことは、プラグインとかgemなどのジェネレータで作られるテーブルやリレーションの影響がかなり大きい事。まぁ、悪いことではなく、歓迎すべき事なんですけど、Rails使うとこんな感じなんだーと思って新鮮でした。

現時点でのgemspec.infoのER図では、7割ぐらいがジェネレータで作られるデータ構造をベースにしています。

うまく言葉にできないけど、データ構造を保持するテーブルではなく、リレーションをうまく使って機能を実現するテーブルの方が、ジェネレータによって作られる比率が高いように思えます。たとえば、ユーザ管理とか、お気に入りとか、タグ関係とか、コメントとか。

逆に、データ構造を保持するテーブル(今回で言えばrubygemsテーブルより右と下側)は、汎用性が無いのでジェネレータで作るのは難しそうです。

ジェネレートするより先にマイグレーション内容を知る必要がある

コードジェネレータの影響が大きいことは事実ですが、これが実作業の流れと反することになるのはちょっと痛かったです。

というのも、コードジェネレータで作られたテーブルも含め、全てのER図に書き出してみて初めて全体像が把握できるので、設計を固めるためには、コードジェネレータを動かしてコーディングを始めるより先に、マイグレーションファイルの内容を把握しておく必要があるからです。

特に上記の通り、よほど特殊なデータ構造でない限り、ジェネレータで作られるテーブルやリレーションの影響は大きいので、これを後回しにしたままERを作ってもあまり実になりません。同じような構造が2つできちゃって、完成時には不思議な構造になってたなんてことも起こる気がします。

おいら的解決法は、ここのようにあらかじめマイグレーションファイルの内容と動作を調べておいて、ER図の部品を作っておくことです。

この観点から見ると、WWW SQL Designerはインポート機能こそないものの、XMLを直接編集することでER図の部品を取り込むことが可能なので、結構使いやすかったです。(他のER作図ツールだとインポートできないモノもあると思います)

ER図を完成させないと全体像が掴めない

ちょっとクドイですが、先にER図を完成させておく必要性についてもうちょっと突っ込んでおきます。

コーディングを始める前にER図を完成させなければならない一番の理由は、先のエントリの通り、モックとER図を付き合わせて設計を煮詰めていくからです。

設計を煮詰めるにあたり、やはり可視化がきちんと出来ていないと漏れが出てしまって、効率的に作業できないように感じます。

ユーザインタフェースを改良したり、ワークフローまで立ち返って検討するって作業は、結構高次元の作業なので、いろんな事がぱっと見でわかることは重要だと思います。

特に、ER図の内容でそのシステムの限界(機能や性能)が決まってしまいますし、プラグインやgemの動作によって画面構成も変わってきますので。(作るのが楽になるような画面構成にするという意味も含む)

また、実際にモックやER図を煮詰める過程で、頭の中では必要なクラスやメソッド、その中で行う処理の概要をイメージしながら煮詰めています。

ER図の部品化とパターン化

さて、こんな感じでER図の設計を進めているのですが、これってRailsの流れからはちょっと外れるので、ER図の部品を作っておく必要があると述べました。

裏を返せばこの部品を作る作業は一人だけで良く、かつ部品は(ツールが同じであれば)みんなで共有できるので、プラグインの情報を扱うサイトとか、gemspec.infoのようにgemの情報を扱うサイトはかなり有用に思えます。(プラグインの情報が欲しい方はRuby on Rails プラグイン まとめ wikiの情報元あたりから調べ始めることをオススメします)

また、このへんを突き詰めていくと、「こういう用途には、このgemとこのプラグインの組み合わせで、ER図はこう、画面構成はこう」といったパターンも出来てくると思います。

ここまで整備できれば、設計はかなり効率化できると思うんですけどね。

個人的には、Railsを使う一番の強みはここなのかなと思っています。正に「設計 on Rails」

設計に使ったツール

最後に使ったツールについての紹介でも、と思ったんですが、これもRubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、リンクを張るに留めます。

極端な話、ツールはあまり重要ではなく、どちらかというと、ジェネレータで作られるマイグレーションファイルの内容をあらかじめ知っておくことの方が、設計作業上は重要な気がします。

あ、そうそう。WWW SQL Designerでポリモーフィック関連を表現するための線を引くには、データファイル(XML)のノードを直接編集する必要があります。このへんもうちょっと改良できればなぁと思います。(作者にソースもらってちょっと改良しようかなぁと思ったり思わなかったり)

2008年9月26日金曜日

gemspec.infoのモック

gemspec.infoのフィーチャモデル からの続きで、Railsアプリケーションの設計を生でお伝えしようという企画(=思い付き)の第3回だか4回だかになります。(←適当)

今回はモックを作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのモック がそのページです。

モックは簡単に画像ファイルにできるので、画像ファイルをペタペタ張った感じでまとめてあります。一応生データもアップロードしてあります。

モックとER図は同時に進める

あー、まずモックモックと言ってますが、これはペーパープロトタイピングレベルの画面設計のことです。正しくはモックの定義から外れるかも知れません。(面倒なのでこのエントリではモックで統一します)

で、Ruby on Rails によるシステム開発をモデリングで効率的に行うにはモック(というか画面設計)の話は出てきてないのですが、なんでコレを必要としたかって話を少し説明します。

まずおいらは、ユーザのワークフロー(「カートに商品を入れてから決済画面に進む」などの作業の流れ)とかユーザインターフェイス(使いやすいかどうか)はモックで検討を行い、そのシステムで何が出来るか、どうやって処理するかはER図で検討を行っています。

具体的にモックで何をするかというと、「その画面でユーザに入力してもらうデータそのものの種類と数」と、「次の画面に移ったり特定の処理を行うために必要なデータがその時点で揃っているかどうかを、その画面に配置された要素と、既に入力されデータベースに格納されて居るであろうデータだけで行うことが可能かどうか」の2つを検討するために使っています。

エントリの都合上、ここではモックの話だけしますが、実際にはモックとERを同時に検討しなければなりません。理由は下記の通り。

「その画面でユーザに入力してもらうデータそのもの」の検討

これは単純で、比較的ユーザインターフェイスが貧弱なWebアプリの場合、画面に出てくる要素の構成が、そのままデータベースの構成(ER図)になることが多いと経験上思っているからです。

これは、たとえばJavaでクラス設計をキチッとした場合は、間に抽象的な構造が入る分、画面=ERにはなりにくいのかなぁと思っています。(や、クラス設計キチッとしたことないから脳内の話なんだけど)

WindowsネイティブのGUIアプリとか、FlashやAjaxアプリなんかも、間に1層入る形なので、画面=ERにはならない可能性が高くなります。特にFlashとかAjaxなんかは、機能毎にもう1画面作ってるのと同じようなもんだし。

上記で「経験上思っている」と言ったのは、そうした方が構造がシンプルで実害もなく、結果として工数が少なくなると思ったから、実務では画面=ERとしたケースが多かったという意味です。(もちろん例外もあります)

逆を返せば、処理の都合上データ構造(ER)が制限され、それが画面インターフェイスに影響する場合があると思いますが、その影響がさほど不便ではなかったり、ユーザインターフェイスを工夫することによって乗り切れる範囲であれば、システム側の都合を優先させる方がいろんな意味(システム構築やデータ入力作業やサーバ負荷解消のためのコスト)で楽になるので、意図的に画面=ERになるような設計をすることも多いです。(あまり良い方法論とは言えないですが、この辺が理想と現実でしょうか)

「次の画面に映ったり特定の処理を行うための必要なデータがその時点で揃っているかどうか」の検討

若干上記と被っていますが、処理の都合上、次の画面へ行くために必要な最低限のデータセットというものがあるとして、

  • その画面に辿り着くまでに入力されていることを期待するデータは何か(今までの必須項目)
  • 次の画面に行くために必須となるデータは何か(処理上の必須項目)
  • その画面で最低限入力しなければならないデータは何か(この画面での必須項目)
  • ワークフロー上、その流れは自然か

というあたり、ワークフロー上の時系列に沿って考えるためにモックを使います。

「どの画面で何を入力できて、どれが必須か」というのは頭の中で管理するのは無理で、ましてや使いやすいかどうかは可視化しなければわからないものだと思います。

おいら的に、その「流れが自然か」「使いやすいか」というところは拘るべきところで、処理の都合上必須なのは仕方ないとしても、その画面のユーザインターフェイスを工夫したり、一つ前の画面で入力できるようにしたり、そもそもワークフローを変えても問題ないのであれば、自然な流れになるように調整したりといった作業が必要になります。

問題点

FlashやAjaxの場合、画面=ERとならない事も多いけど、これをうまく整理する方法がわからない。まぁ、Mockupsを使う分には簡単にモックをコピーできるので、動きの要所要所でもう一枚モックを作ればいいのかもしれないけど、なんかしっくり来ない気もする。

まぁ、ActionScriptとかJavaScriptで無理矢理ER図に合わせた形に加工できれば良いんだろうけど、それもどうかと思うしねぇ。

一つ言えるのは、FlashやAjaxやその技術を使ったリッチアプリケーションが増えてくるのは自然なことで、これら業界的な要求を満たす設計手法が確立してないってことかな。

画面設計するためのツール

さて話変わるんだけど、モックアップを作るために使ったツールを紹介しておきます。

と言っても、RubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、おいら的選定基準など。

  1. 書きながら考えやすいモノが良い
  2. 発注者やプログラマ達などに気軽に確認してもらえるモノがよい
  3. 2の観点からWebアプリで設計出来た方が、常に最新版を提示できるので良さそうだけど、ネットワークがあることが前提となるので、出張先などで開けなかったり、喫茶店で仕事できないのが痛い
  4. 3の観点から、ネイティブアプリ(Windows用とかMac用とかJavaモノとか)か、ローカルで動作可能なWebアプリが現実的かな
  5. 2の観点から作ったモノを簡単に配布できること。画像にエクスポートかけるか、(一般的なアプリで、データをファイルに落とせるなら)生データで展開するのが現実的かな
  6. 5の観点から、モックアップを作るためのツールが無料であること。画像は簡単に確認できるけど、メタ情報が落ちてしまうし、微調整さえも面倒になるので
  7. 素人でも理解できる程度の表現力があること
  8. 1にも準ずるけど、大雑把なものが、簡単に作れること。モックは何度も書き換えることになるので、簡単に作れないと心理的抵抗が大きくなる
  9. 注目すべき点は、デザイン的要素ではなく本質的な要素なので、見た目がキレイなのはいいけど、あまり拘らないこと(特に作り替えるときの心理的抵抗が大きくならないように)
  10. ネイティブアプリを作れるぐらいの表現力があること。この先AjaxやFlashはその高みまで到達すると思う
  11. 可能なら動きも再現可能なこと(でも難しいよね)
  12. データがテキストファイルになっている方が、subversionやgitなどでバージョン管理しやすい(データ量が少なかったり差分が見れたりなど)
  13. データが構造化テキスト(XMLとかYAMLとか)になっていれば、プログラムで解釈させてジェネレータなどを作ることも出来る

まとめると、「見せやすくて」「大雑把に簡単に作れる」ことかな。

候補としては

があるんだけど、ExcelとPowerPointは表現力が乏しいのでダメ、DreamWeaverはどうしてもCSSとかDivなどのブロックを考えなきゃいけないので本質から反れてダメ、となったときbalsamiq mockupsPencil が有力になると思う。

おいら的にはbalsamiq mockups だったんだけど、これはbalsamiq mockups の方が知ったタイミングが早くて、あまりPencil に興味がわかなかったってのが大きい気がする。

Pencil って実際どうなんだろう? ちゃんと使わないと比較はできない気はするモノの、できることはあまり大差がないように思えるので、どっちでもいい気がする。(mockupsは有料なのでPencil有利かな)

ただ、Pencilは気になるものの、balsamiq mockupsに満足しちゃってるので、乗り換えるかどうかは微妙だなぁ。

2008年9月25日木曜日

レコーディング・ダイエットしようかと

みなさんレコーディング・ダイエットって知ってますか?

自分の食べたものを片っ端からメモして、可能ならカロリー計算し、自分がどれくらい食べているかを自覚することでダイエットへのモチベーションを維持させようっていうダイエット法の一種です。

詳しくはこのへん見てみてください。

今話題のレコーディングダイエットを検証! - [話題のダイエット情報]All About

おいら初めてレコーディング・ダイエットをTVで見たとき、「あー、この食事記録してカロリー計算するあたりをWebサービスにしたら人気出るかもなー」と思ってたんですが、すでにその機能が実装されているサービスを発見したのでご紹介します。

カラダカラって?

健康のポータルサイト:カラダカラ

ってサイトなんですが、健康のポータルサイトと冠しているだけあって、ダイエットはあくまでオマケで、睡眠時間とか食事とか精神状態とか病気の治り具合を日記に付けて、仲間交流を深めることで、健康に気をつけましょう、というか辛くても負けないでね的なところを狙っているサイトのようです。

ダイエットダイエットと煽ってない分、信用できるというか、コツコツ続けるには良い環境だなぁと思いました。

で、レコーディングダイエットは?

会員登録すると、カラダカラノートというものに記入できるようになっています。

記録できるノートの種類はたくさんあって、その一つが食事の内容なんですが、実際に見てもらった方がわかりやすいかな。

食事の記入

ちょっと文字が潰れちゃってますが、要はAjaxをバリバリに効かしてるテキストエリアがあって、そこに食べたものを書くと、関連するデータを検索して候補をリストアップしてくれます。

たとえば、「味噌ラーメン」と書くと、「一般的な味噌ラーメン」なのか「まるちゃんのインスタントラーメン」なのか「日新のカップラーメン」なのかといった感じ。一人暮らしに考慮しているのか、インスタントモノが多い気がします。(まぁメーカー公表値がある分データを揃えやすいのかも知れませんが)

んで、リストの中から一つ選んだら、カロリーが自動的に算出されるので、食べた分量(これによってカロリーも増減する)や、時間帯を入力していく流れです。

MacでFirefox3を使うとちょっと表示が崩れますが、ぜんぜん許容範囲です。

で、ここからが凄い

食事内容を記入することで、自分がどれだけ食べているかを自覚させ、意識的に食事量を制限するというレコーディングダイエットの目的(というか記録を支援する目的)はこの時点でクリアできます。

更に、単品毎、一日毎のカロリー量も計算できてしまいます。

ただ、これだけで終わりではなかったところが凄いんです。

これを見てください。

カラダカラノートを使ったカロリー収支グラフ

カラダカラではユーザプロフィールの一環として、「体を動かす仕事の人」「普通」「動かさない仕事の人」程度の区分で基礎代謝量を設定することが出来ます。

また、カラダカラノートでは、「腕立て伏せ」「ウォーキング」「ジョギング」といった運動量も記録することができ、距離・時間・回数ごとの単位消費カロリー量を設定可能なので、これらの基礎代謝+運動量によってどれくらいのカロリーが消費されているかを計算することが出来ます。

で、食事によって摂取されたカロリーから、消費されたカロリーを引き、差し引きでカロリーがどうなっているのかをグラフ化することができるのです。(これが上の図)

実際にカロリー収支が数字として計算されているので、月末時点で差し引きどうなっているのかも知ることが出来ます。

今月は2万kcalのプラスだから、その分脂肪が付いてるんだろうなぁとか、数字として突きつけられるわけです。

で、ここで終わらない

ここまでカロリー収支が明確になってしまうと、逆の考えもできるようになります。

たとえば、

  • 「(上のグラフのように)おおよそ毎日500kcalのプラスなんだから、日々の生活に500kcal消費する運動を取り入れれば、体重は維持できるんだな」とか、
  • 「昨日は飲み歩いてカロリー取り過ぎちゃったから、その分運動しないと…って、取り戻すためには200分もマラソンしなきゃならないの? マジで。やべー呑み会自重しなきゃ」とか、
  • 「やばいよ、○○までにあと5kg痩せなきゃならないじゃん。それって一日当たり1000kcal減らすって事でしょ? こんなの食事だけでは減らせないよね。食事で500kcal減らすとして、残り500kcalを消費する運動はと…」

みたいに、具体的な数字で考えられるんです。

これは効きますよ。雨が降ってもウォーキングは休めませんよ。

なんせ、今までの「何となく、まいっかーで済ませて結局痩せなかった自分」のように漠然としたモノではなく、「○○に××できなかったが為に痩せなかった自分」をリアルに突きつけられるわけで。

まとめ

カラダカラを知ったきっかけは、このレコーディングダイエットのカロリー計算のアイデア(食べ物の名前を解析して候補を示しカロリーを計算する)を前から思いついていたからなんですが、作るの大変そうだなぁ(データ集めるのがね)と思ってたし、良いのがあるなら使おうというスタンスでした。

なので、カラダカラを知ってどんなもんか使ってみて、自分のイメージの上を行くサービスだとわかったとき、結構感動しました。

何が凄いって、仕組み的に完結してるんですよね。ポータルという名に負けてない。

上記カロリー収支の話もそうだし、一緒に運動するための仲間作りや、実際に体の調子がおかしいときの医学事典や自己診断までできちゃう。

よくある「ポータルを目指してるけど上手く回せず力尽きてダメになるパターン」ではなく、うまく回ってる実例を見てる気がして、サービスの企画にもかかわっている身としてスゲーと純粋に思ってます。

…このサービス、人気あるのかな? おいら的にはど真ん中ヒットなんだけど、(おそらく)長くやっている割には名前が知られていない感じがして、もったいないなぁと思いました。

2008年9月20日土曜日

gemspec.infoのフィーチャモデル

gemspec.infoのコンセプト からの続きで、今回はフィーチャモデリングしました。

と言っても、かなり我流ですが。

モデリング結果

まずは設計成果から。

例によってWikiに上げました。

Ruby on Rails プラグイン まとめ wikiGemSpec.infoのフィーチャ がそのページです。

一応FreeMindからTWikiエクスポートかけたテキストとして書いてありますが、正直見にくいと思うので、添付してあるFreeMind用のファイルを開いてもらうのが一番良いかと思います。

GemSpec.infoのフィーチャモデル

全体的な流れ

ええと、前にも書いたかも知れませんが、これらの設計成果物は「設計結果の清書」としてではなく、「考えるために書く」(書きながら設計する)ために作っているものです。よって、これで完成という意味合いではなく、極端に言えばアプリケーションが完成するときにやっと設計成果物も完成するものと捉えています。(まぁ、リリース間近になっても設計資料をメンテしているかは疑問ですが)

実際、おいらの作業はほぼERが完成してモックの細部を詰めているところですが、この段階になっても作りながら新たなアイデアが浮かんで、一部フィーチャモデルにフィードバックが入ることもあります。なので、今アップロードしたものも現在の最新版であって、まだ変更される可能性もあります。

アジャイルやRailsのお作法的には、全体的な方向性を整えるために、全体を通しての設計はすべきだと思いますが、Ruby on Rails によるシステム開発をモデリングで効率的に行う であかさたさんもおっしゃっているとおり、ある程度でレールに乗っちゃった方が効率的だと思います。

なので、ここでは細部まで突っ込んで考えるより、ある程度まとまったらコーディングに移り、問題が浮上したら都度微調整ぐらいに考えています。

コンセプトからフィーチャを起こす

ここからは我流前提で行きます。

例によって内容はWikiを見てもらうとして、ここでは何に注意して作業したかだけ説明します。

まずは、「ログイン」とか「記事投稿」などの主要機能について、「意味合い」「必要機能」「問題点」に分けて書いていきました。

意味合い

  • 何故この機能が必要なのかを明確にする
  • コンセプトと被るものが多いけど、コンセプトよりもっと具体的に書く
  • 「何故」こうしたかを明確にした方がシンプルになって、方向修正もしやすい
  • たとえば機能同士の整合性やユーザインタフェースが不自然になりそうだったら、一度「なんでこの機能が必要なんだっけ?」と気軽に戻れる場所を作っておくのは気分的に楽

必要機能

  • 機能や画面として必要なものを列記する
  • 意味合いと合わせて、何故「こうした」かを明確に対として書く
  • gemやプラグインを使う場合はそれを書いておく
  • でも、どんな時にgemやプラグインを使えばいいかわからないと思うので、前もってgemやプラグインが提供してくれる機能やマイグレーションの内容は知っておく必要がある
  • Ruby on Rails プラグイン まとめ wikiとかgemspec.info使え(再帰的に)

問題点

  • 意味合いとか必要機能を勢いに任せて書き進んだときにふと思いついた「そういえば、こういう場合にこの機能ってちゃんと機能するのかな?」みたいな疑問をメモしておく
  • おおよそ書きたいことを書き終わった後、問題点を潰しに入る
  • もう周りの状況は見えているはずなので、意味合いに立ち返りながら、機能を諦めるのか、機能を活かして問題点をうまく避ける工夫をするのかを考える
  • 機能を諦めることで問題点を解決するなら、マインドマップから両方消す
  • 機能を活かして問題点を上手く避けるなら、具体的にどうするのかを詳しく書く

意味合い→必要機能→問題点→次の項目の意味合いと、がーっと書き進んだ後、書く速度も落ちてきて、もう大体いいかなーと思ったら、もう一度全体の整合性を見直しながらgemやプラグインを使えそうな部分を探し、最後に問題点を潰していく感じでしょうか。

実際にはgemやプラグインの検討を始めたあたりで、モックやER図も描き始めています。おいらの場合、そうしないと全体の流れがうまくイメージできないので。(特にユーザインタフェース上の問題や、データ構造上実現可能/不可能なことがイメージできない)

そうそう

Railsのちゃんとした設計はおろか、業務レベルの実装もしたことはない(業務では管理はしてた。個人レベルで実装はしてた)ので、このへんかなりぐたぐた感ありますが、ご容赦ください。

逆に、効率的な設計手法には興味があるので、突っ込みとかアイデアあればガシガシどぞー。

今後の予定

札幌Ruby会議01でライトニングトークの選考に残ったので、参加予定の方はよろしくです。

もうちょっとで設計が終わるので、来週からはコーディングできるかな。10月上旬には完成したいなぁ。

ただ、今月の北海道は勉強会ラッシュなので、プライベートの時間があまり取れないのです。

勢いで徹夜するのが結局効率的なのかな。

2008年9月18日木曜日

be動詞の疑問形を作れなかった男が感じたiKnowとマイリストのおいしい関係

iKnowやってて、こうすれば効率的に覚えることが出来るかも、と思ったことがあったのでまとめるよ。

マイリスト使ってる?

iKnowをやっていて、初めて出題される単語じゃないけど、毎回忘れてしまうような単語は、1〜2ステップ毎ぐらいにマイリストを作ってまとめておき、定期的に確認すると定着しやすいように思う。

特に定着度75%ぐらいになったときには、簡単にわかる単語と忘れちゃう単語がハッキリするから、iKnowを始める前にさらっとマイリストを見るのがいいかも。(iKnowでおさらいという位置づけにする)

マイリストには

  • スペル
  • 単語の発音(音声)
  • 日本語訳
  • 品詞

が表状にまとめられているので、さらっと確認するのにちょうど良い感じ。

たとえば、おいらの場合、動詞とか名詞はイメージしやすい分すぐ覚えれるんだけど、副詞とか形容詞は基礎英語ステップ1とか2のレベルでなかなか覚えられないものが出てきた。(学生の時にも覚えられなかった気がする)

ステップ2つ分(単語数200)で、マイリストに入った単語は10個ぐらい。だいたいステップ1つを終わらせるのに毎日やっても2週間ぐらいかかると思うから、最短だと1ヶ月で2ステップ消化できて、1つのマイリストづつ増えていくことになると思う。

iKnowアプリケーション内からマイリストに単語を追加できるともっと楽なんだけどね。現状、iKnowやってて「あ、この単語覚えてないや」と思ったときに、別ウインドウでマイリストを追加しながらやってる。

マイリストは将来の自分の時間節約のために作る

マイリストって、他人と共有したり、iKnowアプリに読み込ませて使うイメージが強かったけど、こんな風に苦手な単語を集めて、自分だけが使う方が気楽に使えて良い気がする。一度学習済みの単語だから、表状で見えればささっと確認できるしね。

苦手な単語って、iKnowアプリ上は完了した扱いになっても、いざ実際の英文に出てきたとき「あれ? こういう意味だっけ?」とうろ覚えになっていることに気づく事が多いので、後でまとめて見直せるように準備しておくと、後々幸せになれる気がしてきた。

2008年9月16日火曜日

アジアの一生懸命

嫁に教えてもらったので、みなさんにもお伝えします。

とりあえず50記事程度目を通していただければ、言いたいことは伝わるはずです。

家族団らんにご活用ください。

アジアの一生懸命

※飲食中は周りの人に迷惑をかけますのでご遠慮ください

2008年9月15日月曜日

be動詞の疑問形を作れなかった男がiKnowのdictationってアプリの使い方を考えてみた

イマイチ派手さというか、エンターテイメント性に乏しく、メニューにあるからたまにはやってるけど、何のためにやってるのかイマイチわからん感があるdictationだけど、これこそが英会話には必要な気がしてきたので、効率的に学習する方法を考えてみた。

dictationの学習の流れ

まず、dictationは基本的にこんな流れで出題される。

  • 同じ英語の例文について、穴埋めの範囲が違う問題が2回出題される。
    1. 半数の単語が穴埋めになっている英文が表示され、同時にその音声がながれるので、穴埋め部分を聞き取って正しいスペルを入力→正解の英文と日本語訳が表示される
    2. 全文が穴埋めになっている問題が再度出題されるので、聞き取って全文のスペルを入力→正解の英文と日本語訳が表示される
  • で、全文穴埋めに正解するとその例文はクリアしたことになる。
  • 最初の穴から順に単語を入力していくんだけど、間違っているとすぐに指摘されるので、正解されるまでその単語を再度入力することになる。
  • ただし、一部聞き取れなくても、ヒント機能を使うと、今入力中の単語の正解を約2秒間だけ見せてくれる。全文ではなく、あくまで今カーソルがある単語のみ。
  • で、間違いまたはヒント回数が3回(もしくは4回)に達すると、聞き取れなかったと見なされて次の質問に移り、後でもう一度出題される。

dictationの効率的な学習方法

まぁ、特殊な学習方法ってことじゃなくて、こんなところを押さえながら解くと学習効果が高いんじゃないかなぁと思った点をまとめてみる。

  • まずシャドーイングまたはリピーティングして、単語を聞き取る(口に出すと正確に聞き取れているかどうか解る)
  • いくつかの単語を聞き取れたら、元々表示してあった単語もしくは写真と合わせて意味を推測する(コレ重要)
  • 聞き取れた単語を入力してみる
  • 推測してみた単語を入力してみる。この時文字数などが合わなかったらさっさとヒントを使う
  • 穴埋めが完成したら、日本語訳を見ながら推測が正しかったか確認する

たぶん、この方法を繰り返していくと、道でいきなり外国人に話しかけられても意味がわかるようになるんだと思う。

実際、英語が話せない人って、こっちから何か話しかけても、その返答が聞き取れないから会話が出来ないんだと思う。「I want to なになに」とか、一方的に話すだけなら(相手が理解しようとしてくれるなら)まぁまぁ実用になる程度話せるもんだ。

で、なんで聞き取れないかっていうと、いつもは文字を読んで、主語とか動詞とか副詞の位置関係を何度も目で追いながら意味を考えるんだけど、聞き取りだと、この目で追うっていう動作が出来なくて、単語同士の繋がりを頭の中で解けないからだと思う。

で、dictationの場合は、この「聞いて」「意味を考えて」「穴埋め&日本語訳で復習」という流れがうまく回るので、だんだん聞くだけで意味がわかってくるんだと思う。(残念ながらおいらはまだそこまで辿り着いていないが…)

dictationは1回につき10分以上かかると思うけど、何度も繰り返さない分だけ進行が早いので、1日1回って感じで良い気もする。

iKnowアプリ側がステップ3を進行中ならば、dictationはステップ2をやるのが良いかも。同じステップ3をやってると、知らない単語(iKnowアプリ側でまだ出題されてない単語)が出てきて、学習効率が落ちる気がするので。

同じ理由で、ステップ10をやってる時より、ステップ1をやってる時の方が知らない単語が混じる可能性が高いんだけど、これはしょうがないとして進めるしかない気がする。さすがにステップが低いうちは、学習済み単語が少ないので、例文にならないだろうし。(こういう事情もあって、最初おいら的にdictationはウケが悪かった)

dictationでは、回答欄に何文字入れるのかといったインジケーターが表示されるので、簡単に聞き取れるようになったら何文字はいるかも無視して(見ないようにして)解くと、難易度が上がって良いのかも知れない。

iKnow!で提供されているアプリの位置付け

おさらい的に、各アプリの位置付けと学習効果をまとめてみた。

紛らわしいけど、「iKnow!」と表記するものはサービス全体を指して、実際にFlashアプリとして動く方は「iKnowアプリ」(もしくはiKnowとだけ)と表記してるよ。

iKnow

  • 単語やコロケーション(特定の単語のセットで特別な意味になるもの)を覚えるためのアプリ
  • 単語の意味、スペル、発音など、単語辞書にのっているような内容を扱う
  • レベル毎にまとめられた単語辞書を暗記していくのと同じような学習効果。平たく言うとボキャビリティー向上
  • 定着率という概念があり、単語を覚えるまで最適なパターン・スケジュールで学習可能
  • 携帯版もあるので、場所を問わずちょっとした時間に学習可能
  • iKnowアプリでの効率的な学習方法は、このブログで既にとりあげています

dictation

  • ヒアリング能力向上や、スペルを覚えるためのアプリ
  • 再生される英文を聞き取って、そのままの英文を入力するだけの問題を繰り返す。
  • ニンテンドーDSのえいご漬けみたいな感じ?(や、おいら持ってないからよく知らないんだけど)
  • 耳で聞いて、それを入力することで、聞き取った内容が正しかったかどうかが判断できるため、ヒアラング能力が向上する
  • 聞き取れなかった単語も、全体の意味を考えて聞き取れなかった単語を推測する推測聞きをすることになるので、英語の文脈についての感覚を養うことが出来る(ここには助動詞しか入らないはずだとか、この単語は名詞じゃなくて動詞だとすれば、ここにはこれが入るはずだとか)
  • 耳で聞いて意味を理解できるようになるので、英会話するには重要な気がする(英文を目で見て意味を理解できても、なかなか耳で聞くだけじゃあ理解できないよね)
  • 効率的な学習方法は今回取り上げました

BrainSpeed

  • iKnowアプリなどで既に学んだ単語を、ゲーム感覚で復習するためのアプリ
  • 1秒に1問ぐらいのペースで、瞬間的に簡単な2択の問題を次々に解いていくことで、単語を見た瞬間に意味を思い出せるようにトレーニングする
  • ヒアリングにしても、スピーキングにしても、単語の意味は瞬間的に浮かんでこないとうまく話せないので、一度覚えた単語の復習として使うと良いかも
  • 単純にゲームとしてたまにするぐらいでいい気もする

iKnowアプリを基本としつつ、ヒアリング方面をdictationで補完して、ゲーム感覚での復習にBrainSpeedを使うって感じかな。

2008年9月10日水曜日

gemspec.infoのコンセプト

RubyOnRailsの設計手法もレールに乗せよう からの流れで、これから作る予定のGem情報集約サイト(gemspec.info)について、設計資料からソースコードまでこのブログで晒してみますね。

自分としてもRubyOnRailsの設計手法もレールに乗せよう で煽っておいて、実際にステップを意識して設計をしたことはあまりないので、Ruby on Railsでこの設計手法を採用することは現実的か、問題点はないか、効率的か、といった点も確認してみたいので。

もちろんgemspec.infoのプロモーション活動も兼ねて。

まず始めに

設計とは本質的にケースバイケースだと思います。

ただRailsぐらい作り方が決まっているモノの設計は、ある程度パターンがあるだろうと。

なので、RubyOnRailsの設計手法もレールに乗せよう の流れを基本としつつ、足りないところは付け足して、無駄と思えるところは省けばいいという方針で進めます。

ただ、足したり省いたところには理由は説明しますね。

で、初っぱなから足したモノがあります。

ユースケースとコンセプトの関係

RubyOnRailsの設計手法もレールに乗せよう では「ユースケースがそのアプリケーションの存在意義となる」とか言った記憶がありますが、そもそもコレってユースケースの範疇じゃないよなぁと思い直しました。

ビジネスモデルというか、物事の本質というか、まず実現したいことがあって、それをモデリングすることで具現化したものがユースケースだろうと。このエントリではこの実現したいことを(なんと表現すべきか解らないので)コンセプトとしますが、今までに無いものを作るならば、コンセプトこそが存在意義だろうと思ったのです。(逆に既に存在するモノに対して使い勝手で差別化するならユースケースが大事)

あともう一つ、受託開発など設計者がユーザでは無い場合に、設計者がビジネスロジックを理解し、発注者(や開発チーム)と理解した内容をすり合わせしやすいようにユースケースを作るって意味もあるのかなと。でも、今回はおいらユーザでありGem作者だし、おいら自身が欲しいと思ったシステムを作るので、わざわざユースケースを作る必要はないかなと思ったのです。

なので、今回はコンセプトだけまとめ、ユースケースは省くことにしました。 

gemspec.infoのコンセプト

そもそも設計のような変化していくモノをブログにまとめるのはどうかと思ったので、内容自体はWikiにまとめることにしました。(文書化できる部分だけでも)

これだけのためにWikiを立てるのもなんなので、Ruby on Rails プラグイン まとめ wikigemspec.info特設ページを作りました。

コンセプトに関するモノはgemspec.infoのコンセプトです。(@wikiはURLがイケてない…)

こんな感じ。

GemSpec.infoのコンセプト

コンセプトのアイデア出しとまとめはFreeMindというマインドマップ描画ツールを使っているのですが、さすがにそのまま貼るには適さないので、テキストに書き出しています。Twiki用のエクスポート機能を使ったのでちょっと不自然ですが、FreeMindのデータファイルをアップロードしておいたので、自然な形で読みたい人はそちらをどうぞ。

Wikiと同じ事を解説してもつまらないので、ここでは触れませんが、要は立場によって違うニーズをまとめ、情報をうまく集約できる仕組みを考え、それを効率的に検索できる方法を考える。って感じかなぁ。

コンセプトのまとめ方

まぁ、人それぞれだと思うけど、まいむぞうの場合って感じでまとめておきます。

コンセプトの骨格部分は思いつきでまとめていますが、この初期段階で問題点を洗って、その解決方法(というか補完するアイデア)をフィーチャなどと合わせて時間をかけて煮詰めと肉付けをくりかえしている感じです。

具体的には犬の散歩しながらとか、風呂とかトイレや寝る前にあ、これいいかもとアイデアが浮かぶことが多いですね。浮かんだアイデアはすぐ書き出さないと絶対忘れるので、その場でエディタに書くか携帯メールに溜めました。

この後のフィーチャモデルと違って、調べることは少ないと思うので、(別のアプリやサイトや本などに触れて)いろんな視点からコンセプトを考えると、色々浮かんでくる気がします。ただ、おいらの場合はあまり時間をかけすぎると飽きてくるので、適当なところで切り上げます。

おいらはいつも考えるときにマインドマップを使っていますが、アイデアのようにポツポツと浮かんでくるモノを体系立てて考える時ってマインドマップはいいですよ。おいら漢字や絵を書けない子なので、PC上で書いていって、後で再構成できるFreeMindはかなり気に入ってます。(他にもマインドマップ描画ツールはありますが、自分の知ってる中では一番イイです。特にver0.90イイ)

テンション上げ上げで

忙しさを理由に進まないのは自分的にもマイナスなので、札幌Ruby会議01までには完成して「でけましたー」と叫びたいところ。

自分を追い詰めるためにライトニングトークの申し込みもしておいたので、作業もはかどると思うよ。

コンセプト見て「はにゃ?」とか「ここってこうだと思うでー」ってところがあったら、ブログでもwikiでもいいのでコメントください。

2008年9月7日日曜日

WebコンFESTA2008に参加してきました

WebコンFESTA2008に参加してきたのでレポートしますよー

基本デザイナ向けセッションなんだけど、プログラマにとって重要(とまいむぞうが判断した)なものをピックアップしますよー

Adobeクリエイティブツール最前線! ~アメリカ直送の最新動向ご紹介~

プログラマ寄りのトピック(まいむぞうの判断による)

  • FlashPlayer10RCが夏リリース予定(正式版は2009中にリリース予定)
  • Open Screen Project 携帯用FlashPlayerが無料化される。これによって普及が進み、同じバージョンで横に揃うかも、とのこと。(Adobe的には無料化してでも欲しいところなんだろうね)
  • SWF search optimization for Google & Yahoo Flashを使ったコンテンツの場合でも効率的にインデックスされるように、GoogleやYahooと協業し、Flashの内部構造を示しているみたい

Flash Player 10

  • リアルタイム静止画・動画フィルタが使えるようになる。フィルタはプラグインとして動き、Labから公開される。Adobe Pixel Benderを使ってプラグインを自作することも可能。
  • 標準で3D空間系の関数がサポートされる。デモで見た感じではパフォーマンスも良好。(でもちゃんとオブジェクト作って動かした訳じゃないし、他のサードパーティライブラリとの比較は不明)
  • テキストエンジンの強化。縦書き対応。テキスト流し込みできちんと(横書きと同じように)レイアウトされる。
  • 動画レンダリングエンジンの強化。可変長ビットレートやオープンソースのSpeexコーデックに対応。

DreamWeaver CS4についても話がありましたが、次のセッションにまとめます。

超スピードで進行したので、捉え間違っていたらごめんよう。

質疑応答

Q:KulerやPhotoshop ExplessやShereのインターフェイスは顧客からの評判がよいが、これは何で作られている?

→A:Flexで作られている。

Q:これらのソースは一部でも公開されている?

→A:現状では公開されていない。

公開してくれるとうれしいなーと伝えておきました。

あと、懇親会でMac用のPlayerが未だにBuggyだよーって突っ込み入れておきました。

Webサイト制作の「今」とともに進化するDreamweaver CS4

DreamWeaver CS4

  • リアルタイムHTMLレンダリングエンジンにSafariと同じWebKitを採用。(うん。これ良いね)
  • Webを使ったライブビュー機能では、オンマウスでのCSS切り替えや画像差し替えなどがリアルタイムに確認可能。JavaScriptなどによって書き換わったDOM要素をFireBugのように確認可能。(オンマウス時に画像を切り替えたならimgタグのsrc属性がリアルタイムで書き換わるなど)
  • 特定エレメント(たとえば<h2>タイトル文字</h2>とか)に影響しているCSSの一覧を、コードヒントのような形で表示可能。ただし、FireBugのように最終的になにが有効になっているのか(継承とオーバライト)を考慮したものではなさそう
  • jQueryやPrototype.jsなどの外部JavaScriptライブラリも検知し、エディタ内でコードヒンティング可能
  • subversion(やっと)サポート。ただしignoreなどの属性系機能はサポートされてないみたい。(デモ画面から)

このドリはちょっと便利そうな気はした。でも、テンプレートいじるならドリ使うけど、JavaScriptとかなら他の環境(aptenaとか)使うかもなぁ。

質疑応答

Q:HTMLレンダリングエンジンはWebKitを使っているとのことだが、JavaScriptの実行エンジンは?

→A:JavaScriptの実行エンジンもWebKitと同じ。ただしDreamWeaverチームの方でWebKitをチューニングしているので、Safariとまったく同じ表示ではない。

Q:特定のタグにかかっているCSSをコードヒントを使って表示する機能は、FireBugのように複数のクラスのどの要素が実際に使われているか(継承される過程でどのプロパティがオーバライトされているか)は判断してくれるのか?

→A:コードヒントでは、適用されているクラスなどを列挙するだけ。継承とオーバライトについては実は前のバージョンで実装されていたみたい。CSSのパネル(デフォルトだと右上)内にてFireBugと同じように表示できる。また、優先ポイント付け(クラスだと何点でIDだと何点みたいな)ものもオンマウスで簡単に確認できる。

他何個か質問があったけど忘れちったぃ。

文字コード判定や、erbやsmartyなど、一部サーバサイドスクリプトが組み込まれているHTMLテンプレートをきちんと表示できて、壊さないようにしてくれるような機能が欲しいよね。(時間が無くて言えなかったけど)

懇親会では、(erbとかsmartyとかdjangoなどの)テンプレートファイルをいじりやすくしておいて、サーバにアップする機能と、ドリ内部でIEコンポーネントを起動(コード/デザインの切り替え機能に、ブラウザ経由で表示するモードを追加する)して、サーバからの出力をブラウザを通してスムーズに動作確認できるとプログラマに受けるかも、って話が出てました。

Fireworks as phoenix(おめでとう、Fireworks 10周年!)

ごめん。おいら興味ないので、興味ある人はAdobeのサイトで調べて。(おいらグラフィックツールを使うことはないので)

でもプレゼンターの鷹野さんはすごくプレゼンがとても上手でした。慣れてる感じ。

Fireworksは、フォトショ・イラレなどの画像ツールと、ドリやFlashやFlexなどの開発ツールの間に位置し、マテリアルの加工や配置・プロトタイピング・ボタンなどのちょっとしたマテリアルを作る、みたいな場面で使われていくのではないか、とのこと。(でもビミョー)

質疑応答

Q:HTMLコーディング専門会社から見ると、Fireworksを使いこなせば業務がすごく楽になりそうなので、Fireworksをぜひとも普及させましょう!!

→A:承知しました!!

Adobe AIRで作るRIAのご紹介

AIRの概念とかデモを見せてもらいましたが、あまり目立った情報はありませんでした。(自分の知識ベースでは)

セッション内で紹介されたAIRアプリは、後で資料もらえると嬉しいかも。

AIRの使いどころ(説明を聞いていてまいむぞうが思ったもの)

  • 背景を透明に出来るので、3Dヒューマンインターフェイスを提供できる基盤技術としては有効かも(ただし3Dプログラミングに精通しないと作るのは難しいよねー)
  • SQLiteを使ったクライアントキャッシュを効かせたアプリ(サジェスト系? もしくは、確定できずとも予約受付だけでも意味があるような予約システムとか。ネットワークレスで動くので)
  • ウィジット
  • ブラウザの独自拡張(HTMLをきちんと再現できるところまではコンポーネント化されているので、作りたい独自機能だけのプログラミングで済む。まぁVisualStudioでもあるけどね。レンダリングエンジンの好みの問題)

Adobeとしては、音声や動画を簡単に使うためのサーバサイドミドルウェアがあるので、こっち方面では結構良いんじゃないの?的なスタンスの模様。(懇親会では「あの値段じゃあやっぱり使いづらいなぁ。オープンソース版出ないの?」的な突っ込み入れておきました。まぁRed5とかもあるので、いいっちゃあいいんですが)

あとは3D系エンジンが色々出てるので、VIsualStudioより(サーバパーティ製ライブラリを使わないならば)結構良い物が作れる気がする。特に3Dでマルチタッチインターフェイス(対応できるか知らんけど)とか絡めると、結構面白そう。

時間が無くてあまり質問できなかったのが残念。

(もしAdobeさんがこのエントリを見たなら、「ぶっちゃけ、AIRってどうよ?」というエントリに返信くれると嬉しいです)

ワークショップ

AIRで作ったら面白そうなアプリについて3人一組でグループ使って考えました。

発表されたアイデア

  • サッカー選手のデータベース
  • ドラマなどで出てきた服やインテリアを自分のアバターに着せることが出来るAIRアプリ
  • AIRでの勤怠管理
  • ヤフオク専用AIRアプリ。終了時間通知機能や商品管理機能がついてる

簡単にブラウザ拡張ができそうなので(しかもこの方法ならレンダリングエンジンを限定できるので)、特定用途向け専用ブラウザというアイデアは結構良い気がします。

HTMLの中にどの程度アクセスできるのか(HTTPリクエストをフックできればOK)理解していないので、ダメな理由はありそうですが…

Hokkaido Fresh Flash

Flashでのプログラミングについて

  • ASライブラリは便利。使うべき

おすすめライブラリ

AS2なら

  • Tweener(AS2ではあまり使われてないかも)
  • FuseKit(有名)
  • CASA Framework(有名)

ただし、AS3だとTweenerの利用頻度が高いので、これから使うならTweenerがオススメ

AS3なら

  • アニメーション → Tweener / Go
  • 3D → Papervision3D / Away3D / FlVe3D
  • 物理演算 → Box2DFlashAS4 / APE
  • マップ → GoogleMAP API for Flash(基本Flexだけど非公式版ならcs3でも使える)
  • タスクシステム → Thread
  • フレームワーク → Progression Framework
  • スライド → Slides(プレゼンに便利かも)

Spark projectのページは熟読すると良いよ

実際にセッション内に携帯用抽選アプリを用意しており、賞品付きで抽選アプリケーション(スクリーンにリアルタイムで募集状況がアニメーションしており、当選者は携帯を持って賞品と引き替える)を実演していたので、感覚的におーって感じでした。

次世代型広告コミュニケーション

個人的に一番期待していたセッションです。

いんてぐれーて(rは内容変更のため聞けませんでした。

  • 流行は必ずWebが絡んでくる。発端もしくは結果として。
  • 広告業界の視点で見たWebマーケティングはWebCampaign って本が事例とかに詳しい
  • 広告業界では「広告は消費者へのラブレター」と昔から言われている
  • このセッションでは、このラブレターの作り方から、渡した後でのフォローまでをまとめて、コミュニケーションデザインと定義している
  • 購買行動はAIDMAからAISASへ変化してきている(詳しくはこのへん参照)
  • 広告は消費者とブランドのbuddy化
  • Encounter(出会い)→Interactive(遊び)→Repeat(もう一度)という流れでコミュニケーションデザインするような流れが生まれてきた
  • 新しい広告の形。デジタルサイネージ(ネットから広告を随時更新する大形カンバン)
  • デジタルサイネージ+顔認証。デジタルサイネージにカメラが付いていて、顔認証にて通行人の性別を判断し、内容を変更するような事例あり
  • デジタルサイネージ+携帯。携帯の画面上にコントロール用のインターフェイスがあって、カンバン上の水槽が動く。魚釣りゲームで、釣れると携帯が震える。(サイトの右上のサムネイルをクリックすると、イケスのようにデジタルサイネージが置いてあり、実際に釣っているイメージ画像があるので、それ参照。これオモロー!!)
  • Interactive Everywhere!
  • googleのエンジニアもyahooのエンジニアも、PC上のインターネットユーザ数は頭打ちで、次の爆発はモバイル周辺で起きると思っており、今からこれに備えて色々動いている模様。
  • androidについてgoogleに聞いても根っこ押さえればおれら儲かるからいいんだみたいなノリで進んでるんだって


"Webキャンペーンのしかけ方。 広告のプロたちがつくる“つぎのネット広告”" (渡辺 英輝, 阿部 晶人, 螺澤 裕次郎, 伊藤 直樹)

Planning Method(プランニングする上での留意点)

  • Insight
  • Cultural Trend / Fuel
  • Hurdle
  • Emotion
  • Childhood memories

上記文字だけだったので、話を踏まえて自分なりに整理(で、おいらは横文字苦手)

  • 深層心理を理解する
  • 傾向や動機を理解する
  • 上記を見据えての問題点を把握する
  • 感情に訴える
  • 幼い頃の記憶とダブらせる

心に残った話

  • 子供の頃の思い出を引っ張り出して、再体験するのがいいんじゃない?
  • マトリックスみたいなカメラを360度並べてアニメーションを作るのは、実はデジカメにデータをWiFiで飛ばすスマートメディアのようなもの+シャッターだけ切るように作れば、後は人力の根性でなんとかなるかも。
  • Web広告予算は20%ぐらい?(総予算の20%?ちょっとわかんない)
  • ナイキの社風が「尖っているものを大切に」的な感じなので、ナイキのようなチャレンジングを全ての企業に提案できるわけではない。
  • 飛び抜けた企画を持って行っても、クライアント企業(広告主企業)の協力がなければ実現できない。自分の企画は50%ぐらい? あとはクライアントの社風やクライアント側担当者の熱意が必要。

でも、自己紹介とか自分のプロダクトの事例紹介永杉。上記内容は40分中後半10分で語られた。(途中まで「がっかりだった」的な記事を書きかけていて、後半オモローだったので書き直した。全体としては満足してます)

でも、インサイトをこういう風に見つけて、こういう理由でこういいキャンペーンを張って、このぐらいのスケジュールのこのぐらいの予算で動いたら、このぐらい効果があったよー、みたいな具体的な話が聞きたかったなぁ。紹介された本 にのってんのかな?

全体的に

特徴的だったのは、プレゼンターのほとんどがMacでKeyNoteを使っていた点です。やっぱりインパクトあるからかな。

結構人来てたねー。100人ぐらい集まったみたい。懇親会50人、二次会25人、三次会12人?(これ法則?)

CSS Nite仕切ってる鷹野さんはとってもオモローな人でした。プレゼン上手すぎ。早速モンタメソッド使ってましたね。

Adobeのねーちゃんは結構オモローな人だった。いじられキャラ。

基本大満足。

北海道でFlexユーザグループ?

あ、そうそう。北海道でFlex/AIR関係のコミュニティ作ったら参加したい人なんて居ますか?

人数集まるならコミュニティ作れってお達しが出てるんですが。adobeさん後援かも。(てか、実現すると↓みたいにユーザフィードバックを集めて送れるってのが大きいかも)

興味ある人居たらmaimuzo@gmail.comまでどぞー

Adobeのねーちゃんへ

文句たれたれリスト復習編

  • Mockupsのオンライン版。シングルバイトは入力できるけど、カナは入力できない。ただし、コピペはできる。
  • おいらが常用しているAIRアプリはこのデスクトップ版。Balsamiq Mockupsを使ってみた 参照。こっちは普通にマルチバイト通る。
  • MacのFlashPlayerがBuggyという証言その1。これが悲しいんだ、たぶんmacだけ - mes que un club
  • UstreamのIRCチャットボックスにも入力できなかった覚えが。(これはFlashだったかどうか微妙だけど。ちなみにMacOSX10.5+FireFox使ってます)
  • Mockupsはイイけど、でもこれがAIRである必然性はない気がする。これもおいら何回もバグレポート送ったよ。やっぱりこのクラスだと作りにくいんだと思う。(まだまだbuggyだし)
  • 上記と同じ人。同意。AIRって何に使うの?って話 - mes que un club
  • AIRに関する考察。AIRってどうよ? 参照
  • SQLiteは非同期で使うと非常に使いづらい。同期で使うようにはできないのかな? (サポートしてないのかも知れないけど)トランザクションとかどうやって使うの? それともトランザクションを使うようなクリティカルなモノは対象外ってこと?
  • Flexをベタで書くスタイル(旧来通りのHTMLにonclick="hoge();"とかしといてJavaScriptの関数を呼ぶのに相当)では、ある程度の規模になると保守しづらい。AS3/Flex2 を使い始めて約半年 - 8時40分が超えられない - subtechあたりに深く同意。
  • でもケアンゴームは大げさに感じる。要は中規模で使えるFlexベタとケアンゴームの中間がないように感じる。Flexのフレームワークまとめ あたりではさらっと調べたんだけど、ピンと来るモノは無かった。adobeさん的にどれか一つを推せば、力が集中される気もする。(これは善し悪しか)
  • Flexでの利用を前提としたASのコードジェネレータ欲しいなぁ。Railsのscaffoldみたいな感じのやつ。RailsとかならXMLはちょー簡単に返せるし、定型なのでscaffold作りやすいと思うんだけど。AMI(だっけ?)も簡単に使えるし。
  • いちプログラマの視点で見るとAIRってウィジット以上複雑なシステム(クリティカルなモノとか)には使いづらいと理解している(だったらVisualStudioで作ればいいじゃんと思っちゃう。銀色なものもあるし)
  • 他のアイデアはAIRってどうよ?のまとめとか、このエントリのAIRセッションあたり参照。でもイマイチ「コレ!!」ってのは思いつかない。
  • で、これについてAdobeさんのスタンスは、こんなん(AIR)作ったからどこで使うかはユーザサイドで考えてねみたいに感じた
  • これって堂々巡りで、結局使い分けとして考えていくと、ウィジット系以外に使い道がないとして止まってしまう気がする。ほらこの用途で使えば他と比較してこんなに便利だよー的なエリアって想定できないのかな? このへんはやっぱりMSは理詰めで上手いなぁと思う。(ちなみにおいらMSは嫌い。だけど現状業務アプリならMSを推す)