ひげろぐ

最近思うところあって自宅のインフラを整備中。

その一環として安売りで1年前くらいに買った110GeのCPUをもともとついていたCeleronからCore2Quad 9400に上げることに。
このときBIOSのバージョンをアップする必要があった。
そのためにはFDドライブが必要になる。
しかし今時フツーはFDドライブとかついてない。

• NEC Express5800／110Ge – wiki@nothing

上記のサイト（多謝！）で調べてみるにUSBのFDドライブが使えるらしいが、使えないモデルもあるらしい。
で、更にぐーぐる先生に聞いてみると最近売ってるものは、どのメーカーから出てても、ほとんどその使えないモデルのOEMっぽい。
要するに今から新品のものを買ってきても高確率で使えないようだ。

ここで押し入れにしまってあるおたから箱から内蔵のFDドライブを発掘するという手もあったが、最近はパーツ類と格闘するのがちょっと億劫になっているので最後の手段と言うことでひとまずパス。
よく見てみるとアップデートツールにWindows版があるのでそれを使ってみることにした。

このツールはWindows 2003と2008に対応しているとのこと。
それぞれ評価版がダウンロードできるのでそれを使ってみることにした。
Windows 2003はインストール途中にHDDが認識されなかったので終了。こっちはドライバを別途準備する根性も必要だった。
根性はとりあえず出し惜しみしてWindows 2008を入れてみたらちゃんとすんなり入った。

BIOSのアップデートもツールを起動しただけでさくっと終了。
善哉。

せっかく入れたんで2008をちょっとだけ触ってみたけれど、なんか小ぎれいになってますな。
Windows Serverなんて2000以来久しぶりに触りました。
ということなので大した評価はできませんでした。小ぎれいになってる。以上。

しかしそうだひとつだけ。
シャットダウン時にその理由を聞いてくるとか大きなお世話って気がするんですけど。
こういう挙動が固いところで使うにはいいのかな。

さて今回はOS再インストール予定だったのでこういう手段も使えたが、絶賛運用中のもののBIOSを上げることになったらいちいち2008入れるのもめんどくさいですな。
それにこんな使い方してるとMSから怒られそうだ。

先日紹介した本を見つつ作ってみた。
とりあえず閲覧のみのかなりシンプルなやつだけど。
趣味の知り合いなんかだと携帯でしかネットしない人もけっこう多いので、そういう人たちにも使ってもらえるようにと。

実機は手持ちのauでしか確認してないので、何かあれば教えてもらえるとこれ幸い。
（キャリアが公開してるシミュレータとかうんこで使えないですな・・・）

参考

• Outdooritem.net – アウトドア用品の価格情報と口コミ評価。

気がつけば一月ぶりの更新。ちゃんと生きております。

ところで先日MA4の授賞式に行って来てノミネート作品から大いに刺激を受けて来た次第。
その勢いでじゃらんWebサービスを使ってひとつマッシュアップサイトを作った。

厳選された源泉掛け流しの温泉宿

• 温泉あり
• 源泉掛け流し
• 口コミ評価4.0以上

といった条件の宿を温泉別、都道府県別、地域別に検索できるというだけのもの。

「温泉宿で評判のいいところを手っ取り早く探したい。あ、もちろん源泉掛け流しで」

と言う人向けなのでこのブログを読んでる人にはあんまりマッチする人がいないかもしれない。
かくいう自分も普段はキャンプか日帰りで宿に泊まらないのでマッチしない。
ただ温泉旅行の幹事を押しつけられた7月くらいには欲しかった。

MA4触発されたという割に機能的に面白いところは全くなく手習いのようなサイトで申し訳。
まあこれくらいのものでも正味16時間くらいで出来たというのは手の遅い自分にしては上出来と思っている。
ちなみにRails2.1初使用。

以下は今回の開発に関するとりとめのないメモ。
未来の自分のための参考程度に。

設計

まずはいつものごとくペーパープロトタイプを書いた。
一行のコードも書かずに自分のアイデアを形に出来るというのはすばらしいことだ。

あとは作りながら気がつくことも多いので、そういうことに関しても随時メモを追加していく。
ただしその時に余計なことを考えすぎて初期コンセプトとのズレが発生しやすい問題を感じた。
それでもっとよいコンセプトになるのならばいいのだけれど、だいたいはみりんで薄めた酒とか調味料を適当に足した料理みたいな羽目になる。

これを防ぐには誰がどんな使い方をするのかといった簡単な仕様書くらいは書いた方がいいかもしれないと思った。
作ってるうち気がついたことがあればまず仕様書をアップデートする。それで多分だいぶブレなくなる。はずだ。

そういう仕様書のやさしい書き方はジョエルさんが教えてくれる。
『Joel on Software』は何年経ってもいい本。

デザイン

実際のHTMLとCSSと画像による見栄えのデザイン。
最近はヘボなりに楽しくやっている作業のひとつだったりする。

背景とアイコンを作るために以下のサイトのお世話になった。

• 素材画像メーカー
• Background Image Maker

グレート。

それと技術者のためのデザインバイブルと言ってもいいのではないかと思っている本も随時読み返す。

• ノンデザイナーズデザインブック
• XHTML+CSS虎の巻
• CSSベストプラクティス 

感性ではなく理屈で分かるところがいい。

キャッシュとURI設計

まずAPIからのレスポンスを一定時間キャッシュするテーブルを作った。
でも後でページキャッシュを採用したのでAPIレスポンスのキャッシュは正直意味がなくなってしまった。

URLは最初は/searchの後ろにクエリストリングが続く動的なURLでいいやと思っていたものの、それだと検索条件ごとにページキャッシュがうまくできなくて結局はある程度ルーティングした。
そこまでやったらついでなので静的ファイルっぽくした。

ただこれによってちょっとしたバグが出てきたりして対応に手間を取られた。
開発時間の3分の1くらいはこいつらと格闘していた時間だ。

キャッシュ設計とURI設計は後付よりなるべく最初にやっておいた方がよいね。

小生北海道ボケが抜けてませんが皆様いかがお過ごしでしょうか。

さてMashup Award 4thの締め切りが昨日（9/16）でした。
なんか新しく作ろうかとも思ったんですがほどよいネタがなかったのですでにある物を。
アウトドア用品価格比較をそのまま出しました。

利用しているAPIは以下の通り。

• Amazon Web サービス（審査対象外）
• 楽天ウェブサービス 楽天商品検索
• SimpleAPI サムネイルAPI
• Yahoo!ショッピングWebサービス
• Yahoo! 日本語形態素解析Webサービス（メンテ画面でのみ使用）
• Yahoo! JAPAN OpenID
• mixi OpenID

メジャーなAPIばっか使ってるので賞を狙えるかどうかは微妙なところですがまあ出すだけ出すかと。

ちょっと機能とかその中身とかを簡単に説明してみたいと思います。

価格比較

スゲーわかりやすい機能。説明の余地なし。
それでも分からない人に贈る言葉はアウトドア用品版価格コム。

価格情報はYahoo!ショッピングのウェブサービスと楽天商品検索から取得。
あとそういうAPIにデータを乗せていないところは独自にスパイダ（ロボット・クローラー）を作って対応してます。

しかし昔気質のウェブサイトのスパイダリング/スクレイピングは地獄だぜフゥハハハーハァー。
変に今かぶれしたJavaScript使いまくりサイトとかもですけどね。AJAXとハサミは使いどころを選んでくださいよ？
ちなみに古のウェブサイトは古の技が一番よく効きます。正規表現とかすごいですよね。 お上品なパーサーに例外を食らわせるような無頼なページも一撃です。

ところで価格比較サイトなんて作るの簡単だぜ！と思っていたけれど実際取り組んでみると意外とやっかいなのが各ショップで売ってるアイテムを同一のアイテムと判別すること。
例えば次のように販売ページのタイトルとかがショップごとにまちまちなんです。

• ショップA ふーばー ほげほげテント 湯たんぽふたつおまけ！
• ショップB 【送料無料】ふーばーほげほげテント
• ショップC HPとMPがたちまちマックスに！ foobar ほげほげテント

各販売ページのタイトルや商品名のパターンでがんばって判別しようとしてますけど誤判別とかまだあります。
可能ならばメーカーの型番でマッチさせるのがいい感じですが、その型番をデータとして持ってるショップばかりでもないのが困ったものだったりします。

ブログから口コミ収集

ブログ検索から記事を収集したら口コミ情報として使えるのでは。
そんな風に思っていた時期が俺にもありました。

実際やってみて当初の思惑と比べると期待はずれ度80%くらいでした。
ノイズだらけ。
スパムを排除してもなお役に立つ記事は少ないと言う。

一応テキスト解析とかで重み付けをうまくできたりすれば使えるようになるかもしれないので捨ててはいません。
役に立つ情報もあることはありますし。
逆に考えるとこういうノイズを適切にフィルタしたブログ検索とかあると素敵かもしれないですね。
ブログ全体を対象にしたら無理っぽいですがニッチなテーマに絞ったブログ検索とかなら目はありそう。

会員機能

会員機能とかつけても閑古鳥が鳴くだけだぜ！ということは重々承知の上で独自コンテンツが欲しかったので作りました。
基本的に会員がうれしくなるような作りになってます。

• ユーザーレビュー（自分の思いの丈をぶちまけられてうれしい）
• 値下げ通知（お目当てのアイテムが寝下がったらすぐ分かってうれしい）
• 所持品管理（自分の持っている物がなんなのかわかって二度買いとか防止できるのでうれしい）

ね、うれしいでしょう？
今後の盛り上がりに期待したいところです。俺たちの戦いはこれからだ！

今目指しているところ

最初は価格比較のみで行こうと思って始めたサイトですが、最近「アウトドア用品のデータベースっぽくできるんじゃないだろうか？」とか言う考えがふつふつと。
まあ趣味で好きな分野なので長く続けることも苦ではないということでコツコツやっていこうと思ってます。

早速サービスに組み込んでみた。
単に認証に使うだけでマイミク認証とかコミュニティ認証とか特別なモノは使ってないけど。

• ログイン – アウトドア用品価格比較

仕様を見てもわかるがClaimed IdentifierにユーザーIDが含まれているのでRP側に誰が登録したか分かるようになっている。
同じ2.0対応でもこの辺りはそれが分からないようなClaimed IdentifierになっているYahoo!とは違う。

ガイドラインを見るに基本的にmixiのサービスと絡めて使って欲しいということみたいなのでこれはこれでいいんだろう。
OP側の方針次第と言うことで。

ただ一点気になる点はエンドユーザがエイリアスを設定するとClaimed Identifierが変わってしまう点。
これアウトじゃないの？いいのかな。
Claimed Identifier変わってしまったらRP側からそれを知るすべがないので別のユーザーとして扱うしかない、と思うんだけど何か方法あるのかしらん。
OP-Local Identifierに数字のIDが入ってきてるのかとか思って調べてみたけどそれもないようだったし。

ちなみにエイリアスも一回設定したら二度と変えられないようにはなってるみたいだけど、一度だけにしろエイリアス設定前と設定後で変わってしまう可能性がある。
エイリアスあっても別にいいけど最初にOpenID使うときに固定させるべきではなかろうか。

まあユーザー側から見てエイリアス設定する意味もよくわからんので設定する人は少ないと思うけど。プレミアムユーザーのみのオプションだし。
でもいったんエイリアス設定しちゃったらもう数字IDのClaimed Identifierにもどせないっぽいので、OpenID使う人が増えてきたら少ないなりになんか問題起きそうな気もする。

今年もやるっぽいです。また100万円です。

• Drecom Award on rails 2008-開催概要

今回は以下のように応募可能な作品の条件がゆるくなっているので、昨年にもまして応募作品は増えそう。

• ウェブアプリケーションであればRailsに限らない（フレームワークは使わないとダメなのかな？）
• 公開から1年以内のサービスであれば応募可能（基準日が応募開始日なのか締め切り日なのか不明だが）
• 他のコンテストと掛け持ち応募可能（問い合わせて聞いてみた）

昨年の概要が見つからないのでもしかすると昨年からそうだったかもしれないけれど、私の記憶が確かならば条件緩和されている気がする。

掛け持ち可能と言うことでマッシュアップを使ったウェブアプリだったら時期的にMashupAward 4thと両方に出せそうですな。
（Mashup Awardは3rdと同じ方針だったら掛け持ちおｋなはず）
締め切りはMashup Awardの方が9/16でAward on Railsの方が9/30ということで。

さて、今年はどうしようか。

ところで

受賞作ほったらかしなので心が痛いです。

このデザインを「完成品」をイメージするための手助けとしよう。

いうのはつまり先にデザインしとくと助かると言うことで、これはすでにいろんなところで言われていることだが、ここしばらくアウトドア用品価格比較を作っていて確かによいことだと実感した。
具体的にはモックアップのHTMLを作ってデザインを固めてそれに機能を埋め込んでいくと言うアプローチを取ったわけだけど、以下のようなよいことがあった。

機能が出来たときになんだか楽しい

デザインがない状態でも作った物が動くというのは楽しいものだが、デザインがあるともっと楽しい。
都度やる気うｐ。開発が進むたびにより多くのエネルギー補充。

機能が出来ないときになんだか助かる

完成品のイメージが掴みやすいことで疲れてきたりこんがらがってきたときにも道を見失わないですむ。
例えば「ああこの機能めんどくさいな。やっぱ作るのやめるか」って時にモックアップを見て「いや、この機能は動いたらきっと楽しい」という気持ちになったりとか。

デザインで力尽きない

一通りアプリケーションを先に作って後でデザインするというアプローチだと、けっこう途中で力尽きて投げやりになってしまうことが多々ある。
これはひとつにはすでにアプリケーションの機能を一通り作り上げたことで満足して気持ちが途切れてしまうということがあり、もうひとつにはデザイン自体がけっこうパワーを使う作業だということがあるのだと思う。ましてやデザイン素人だし。

しかしすでにデザインが出来ていればこの壁を回避できるので助かる。

というわけで

いろいろとよいことずくめでした。

パワーを使うデザイン作業をやる気が高い開発初期にやって、そのデザインのおかげでモチベーションを高め維持することが出来るってのはかなり賢いんじゃないだろうか。

ところで

デザイナーが他にいる開発だとよくデザインをあとで埋め込むというアプローチが取られるけれど、それをやるとその作業自体がダルイしUI周りのテストが全部やり直しになったりいろいろと面倒。
なのでソロでの開発に限らず、開発者的にはできればデザインは先にあった方がありがたいところ。

まあコンテンツが固まってないとデザインできないし、それからさらにデザイン自体に時間もかかるしで仕方ない面もあるんだけど。
でもそれがちゃんとできたらこれはすごい段取り上手だよね。

参考

• 新サービスを開発するときに気をつけてること : a++ My RSS 管理人ブログ
• Web2.0ナビ: 個人サービスを作るコツ
• これだけは知ってほしいウェブデザインの常識 インターネット-最新ニュース:IT-PLUS

アウトドア用品価格比較

昨年10月末の開発合宿でRailsを使って作ってたサービスをようやくリリースしました。
半年以上経ってから出すのがお約束になってます。すみません。

さて、内容はなんのヒネリもない直球なサイト名の通り、アウトドア用品の価格比較サイトです。
商品の価格比較とブログ検索などから集めた商品に関する記事を口コミ情報として載せています。

価格.comとか既存の価格比較サイトでもアウトドア用品の価格比較はあるのですが、比較対象の商品点数や商品に関する情報が充実しているものがなく不満を感じていたので作りました。
というわけでそんな不満を感じていたユーザーの観点から見てもけっこういいかんじのものができたんじゃないかなぁと思っています。かつまだまだやりたいことがたくさんあったりしてモチベーションは尽きません。

まさに「俺が欲しいから作りました」最強。

仮運用は一ヶ月ちょっとくらい前から行っていて、スパイダを回してデータを集めて、集まってきたデータを見ながらちょこちょこアプリケーションを調整したり、データの選別をしたりしてました。
正直まだ調整し切れてない部分もあるのですが、まあそこそこ形になったということでこのたび正式運用を開始の運びと相成りました。

まだまだこれからのサイトですがどうぞごひいきに。

中身の話とか開発に関する話とか折を見てまた書きます。

関連

• アウトドア用品価格比較

追記

合宿にいっしょに行ったF.Ko-ji氏にレビューしてもらいました！

Ruby on Railsで作られたアウトドア用品の価格比較サイト – F.Ko-Jiの「一秒後は未来」

stepfeed

最初のリリースから半年くらいほったらかしてましたが、今回リニューアルしてのリリースです。
以前のバージョンが0.3くらいだとしたら今回のバージョンは0.8くらいになってると思います。

しばらくまえからひっそりリニューアル公開してたのですが、とりあえず一段落したかんじなのでアナウンスします。

あとコンテンツをいくつか登録したので、興味を引くものがあれば購読してみてください。
読みたいものが見つからなくても新着フィードが出るようになっているので、それを購読してもらえたりすると幸甚です。（タグごとにも新着フィードが出ます）

変更点

ということで変更点は以下。

• タグ機能つけました
• 新着フィード出すようにしました
• もう一度はじめから読む機能つけました
• コンテンツ登録機能を強めました
• いくつかコンテンツ登録しました
• その他

タグ機能つけました

コンテンツのカテゴライズのためにタグ機能をつけました。

猫も杓子もタグの昨今ですが、ゆるやかなカテゴライズにタグはやっぱ便利ですよね。

新着フィード出すようにしました

コンテンツが追加されたら通知するためのフィードを出すようにしました。
これは最新情報をお届けするタイプのごく普通のフィードです。

タグごとの新着フィードも用意してあるので興味あるタグのフィードのみ購読することもできます。

もう一度はじめから読む機能つけました

ステップフィードを購読していて毎日1ページずつ配信されても、結局読み切れず未読が貯まってしまい、結局読まないで終了。
そんな状況の救世主として、最後まで配信されたステップフィードをそのまままた最初から読める機能をつけました。

または繰り返して読み続けたいコンテンツをずっとループし続けるとか言う用途もありかと思ってます。

コンテンツ登録機能を強めました

主に自分が使うために強めました。

リンクの一覧が載っているようなインデックスページのURLから登録できるようにしたほか、本文取得のアルゴリズムをExtractContent＠サイボウズラボを使ったものに変えました。
ExtractContentを公開してくれた方に感謝。

これで幾分コンテンツの登録はしやすくなったと思いますが、自分で利用していてまだ強め方が足りないと感じているので今後も強めていく予定です。

いくつかコンテンツ登録しました

自分がよいなぁ、と思うものをいくつか登録させてもらいました。
今後も継続的に増やしていきたいと思います。

登録に際して許可は基本的に取っていないので、申し訳ないですが何か問題があれば連絡していただければと。
（一応ソースへのリンクは張ってあります）

その他

デザイン変えたりとかバグフィックスしたりとか地味にいろいろ。

今後のフォローアップ

継続的に機能追加やバグフィックスなどのメンテナンスを続けていくほか、コツコツコンテンツを増やしていく予定です。
あとこのブログにも関連記事をちょいちょい書いていくかと思います。

もし何か要望や意見があればフィードバックいただけると幸いです。
よろしくお願いします。

10/28-30の日月火にかけて伊豆の伊東に開発合宿に行ってきました。
メンバーは前の職場で一緒に働いていたF.Ko-ji氏と前の前の職場で一緒に働いていたmoongiftの中の人です。

今回の合宿は退職の時にF.Ko-ji氏に「合宿行きましょう！」とプッシュされたのが始まりで企画。
そしてmoongift氏が「合宿」というキーワードを某所のブログにぽつりと書いていたのを思いだし拉致。

場所は以前から気になっていた山喜旅館に行ってきました。

合宿の環境

山喜旅館。
建物は大分年季が入ってますが、料理はおいしく温泉は見事な掛け流しなのでいいカンジです。
てかお湯の流れ方がかなり贅沢です。
これで宿泊の費用は一泊8400円となかなかリーズナブル。

そして忘れちゃならない無線LAN完備。
ただし暗号化ナシの無線だったのがちょっと怖かったですが。

開発はちゃぶ台と座椅子で各自ノートPCとディスプレイを置いてデュアルディスプレイでやりました。

合宿の様子

朝9:00前に自宅を出てmoongift氏のウィッシュで伊東へ向けて発進。
早く出たおかげで特に目立った渋滞にも遭わずに順調に伊東の手前まで到着。
11:30くらいからご飯を食べつつアイデアを練ったりして1時間ちょっと過ごした後で宿へ。

宿では到着後すぐに環境をセットアップして作業開始。
本来は15:00チェックインのところ、13:00くらいに作業はじめさせてもらいました。

それからはだいたい半日ごとに報告会をしつつ、それ以外の時間は各自黙々と作業。
時々それぞれ飲み物やお菓子の買い出しや風呂、散歩などを思い思いに。

途中の報告会で他の二人の作っているものがどんどん形になっていくのにプレッシャー。
F.Ko-ji氏がタイトルロゴまで作っていたのを見たときには「こいつ！戦い慣れしている！」とか思いました。
ちなみに自分は地味にバックグラウンドを作っていたので途中まで画面とか一切なし。

またMac使いのmoongift氏が早速OSをLeopardにして来ていたのですが、必要なライブラリのコンパイルなどに手こずっており、あやうくLeopard乗りこなし合宿になるのではないかと心配させられました。

全体的にガチッとカンヅメなかんじだったのですが、睡眠は割ときちんと取って徹夜とかはなし。
私自身「このままでは形にならん」と二日目は徹夜しようかと思っていたのですが、気合いを入れたら思いの外作業が順調に進んだので普通に寝ました。
てか初日と二日目の前半はやっぱり体調が本調子でなかったのかなと思います。

そして最終日には全員それなりに形になったものが出来ており、なんとか格好のついた合宿になったようです。

それぞれ作ってたもの

実際のものは今月末くらいにはリリースされるはずなので、だいたいのかんじだけ。

F.Ko-ji氏はPHPで開発。
RSSやAPIを駆使して、とある種類の情報を見える化するツールを作っていました。
どっちかと言うとネタ寄りなかんじのものですが、しっかり作り込めればけっこう面白いものになりそうです。
それにしても各種APIの使いこなしやさくっとデザインを作ってしまう辺りはさすが。

moongift氏はRails。
ベイジアンフィルタを使って何かを作ってました。
ベイジアンフィルタは主にスパム判定に使われていますが、それ以外にも自動のカテゴリ分けなどに使えるものなんですね。
使いどころはいろいろありそうで興味深かった。
というかいろいろと人の知らないライブラリやソフトウェアを知っているところはさすが。

私はRailsで趣味のアウトドアに関するサービスを組んでました。
完成するとけっこう実用的なサイトができあがるはずですが、さてどうなることやらと言ったところ。
技術的にはBackgrounDrbとか使ってバックグラウンドジョブをうまいこと管理する仕組みを試せたのが収穫でした。
そして後半になってやっとエンジンがかかってくるところがさすがと言えましょう。

ふりかえり

よかったこと

• 宿のごはんがよかった
• やはり風呂重要 24時間重要 アイデアもわく
• 平日なのですいててよかった
• 到着後すぐの開始が肝要
• デュアルディスプレイ
• RSSチェックおよびメールチェック禁止（ちょっとだけやってる人もいたけど）
• 開発以外やることのない環境というのは作業がはかどる
• 他の人からすぐに意見をもらえるのはいい（ひとりでやってると投げそう）
• 報告会はよい
• 他の人が黙々と作業しているので、自分もやる気が出る
• 報告会で他の人ができているといい意味でプレッシャー
• 座椅子最高（F.Ko-ji氏）
• 他の人の開発の仕方が見られてよかった（メモ取ることとか）

わるかったこと

• 作るための土台をしっかりしておかないと（ライブラリ等）
• 昼飯の場所とかチェックしておいたらよかった（ちょっとさまよった）
• 座椅子腰痛い（moongift）
• 蚊
• 風呂がぬるい（自分以外）
• 体調不良

今度やるとしたら

• 生活リズムが違うので作業部屋と寝る部屋を分けたい
• 待ち合わせ場所を遠い人に配慮（途中合流とか）

その他

出発の朝の天気が台風一過のやばいくらいいい天気でした。
最近まれに見るクッキリ富士山を見たときには合宿中止を宣言したくなったほどです。

それと先週から引いていた風邪を若干ひきずったまま参加していたのですが、F.Ko-ji氏にそれを移してしまったようで申し訳なかった。
体調管理はしっかりしておきたいものです。こういうときに限らずにですが。

関連リンク

開発合宿レポート＠伊東温泉 – FFTT

Award on Rails 2007のマイクロソフト賞の副賞が届きました。

Microsoft Windows Vista Ultimate 通常版

posted with amazlet on 07.11.03

マイクロソフト (2007/01/30)
売り上げランキング: 337

Amazon.co.jp で詳細を見る

豪華な副賞だ。
予想のひとつには入っていたけど、まさかこれが来るとは思っていなかった。

それに加えて

Expression Studio

posted with amazlet on 07.11.03

マイクロソフト (2007/07/13)
売り上げランキング: 7578

Amazon.co.jp で詳細を見る

も届いた。
うーむ手厚い副賞だ。

ありがとうございます。

しかしながらVistaは現在インストールできそうなマシンを持ってないので、しばらく本棚の肥やしになりそうです。
まあ、持っていたらいずれ役に立つ日が来そうな気がする。

Expression Studioの方はこれをきっかけにSilverlightとかC#とかさわってみようかなーとか思ってますが、思ってるだけに終わる可能性もなきにしもあらず。
なにかやったらまたここに書くと思います。書かなかったらすみません。

ところで審査結果のページに講評が追加されてますね。

講評:
フィードを利用したサービスという点では、今後、いろんな展開があると考えていますが、非常にシンプルで、すぐに利用できるところが良い。
是非、他サイトからの連携を前提にサービス展開を図って、いろんなコンテンツのアーカイブとしてのサイト運営をしていって欲しいです。

シンプルさ、アーカイブとしての利用など評価してもらいたかったところが評価されていてうれしい講評です。

近況

今週は合宿の後にお手伝いさせてもらっているプロジェクトのリリースがあったりして久々に力一杯活動した週でした。
合宿レポは近日書きます。

おかげさまでstepfeed受賞しました。

今回は正直なところ昨年に比べて応募作品数が多く、質の面でも高いレベルにあるものが少なくなかったので受賞できるとは思っていませんでした。
うれしい反面、やばいもう少しマジメにやらんと、という反省に似た気持ちもちょっとあったりします。（コンテンツの充実等、簡単にできることを放置しまくっているので）

ところで何らかの賞を受賞したと言う連絡は事前にもらっていたんですが、それが何かと言うことは表彰式までのお楽しみということでした。
しかしながら情けないことに体調不良で表彰式には行けず。
こちらの審査結果発表のページを見て受賞を知りました。

というわけで、自分の作品がなんで賞に選ばれたのかなどの理由がさっぱりわからず、重ね重ね表彰式に行けなかったのが悔やまれます。
選考理由などを審査結果発表のページに載せてもらえるとうれしいなどと思っているのですが、中の人も忙しそうなのでまあ仕方ないところでしょうか。

ちなみにマイクロソフト賞の副賞がまだ何なのかわからないのでちょっと楽しみです。
今は亡きトラックボールエクスプローラだったりしたらうれしいのですが、それはないだろうなぁ。
むしろ再販のお知らせが副賞とかでもいいんですけど。

で、今は次の新しいサービスを作るために開発合宿に来ています。
これを作ったらしばらく新しいものは作らないつもりです。たぶん。

新しくサービスを作るのもいいが、運用やブラッシュアップもしっかりしていかなければと思う今日この頃だったりします。

開発合宿のレポなどはまた後日上げたいと思います。

そんなわけでAward on Rails 2007の全作品をフィードで毎日ちょっとずつ見られるようにしてみました。

本日10/09分から購読開始のフィードが以下になります。
審査とか関係なくのんびり見たいという人は上の1日1個配信の方を、審査に参加したいので1日10個見たいという人は下の1日10個配信の方を購読してみてください。

• Award on Rails 2007全作品 1日1個配信
• Award on Rails 2007全作品 1日1個配信（実は10個配信）

以下のページでそれぞれのフィードの概要と配信スケジュールが確認可能です。
ちなみに配信順番は適当です。（たまたま作品一覧ページに表示されたのと同じ順番）

• Award on Rails 2007全作品 1日1個配信 購読画面
• Award on Rails 2007全作品 1日1個配信 購読画面（実は10個配信）

なお1日に10個のエントリを配信するフィードはデータベースをいじって無理矢理作ったモノなので、普通にステップフィードを使っている限りはそういうフィードはできません。

本来の購読の流れ

本来は以下のコンテンツの内容を説明するページからそれぞれの購読者専用のフィードを作成して、購読を始めた日に一番最初のエントリから1日1個ずつ配信するというのがステップフィードの特徴です。

Award on Rails 2007全作品 1日1個配信

例えば明日10/10に誰か購読者がこのページからフィードを購読し始めると、10/10から1日1個ずつエントリが配信され、67日間配信が続きます。
11/01から購読を始めれば11/01から67日間、12/01から購読を始めると12/01から67日間といった風に、読者がいつ読み始めても頭から読むことができるフィード。

そんなのがステップフィードなわけです。

Award on Rails 一般審査・投票

応募作品は全部で7067作品。
昨年の20に比べて大分増えた。

これだけ多いと、とりあえずタイトルかサムネイルで釣られないものは説明文すら見もしない。
と言うのも今回は作品の説明文が作品一覧から作品をクリックしないと出てこないので、一般審査しようとする人は70回クリックしないと全作品の概要をつかめない。

これはユーザビリティ的にはNGだよなぁ。
全作品の説明文を見るだけで7067回クリックて。
付き合ってくれるのはいったいどこの暇人だ。

でもまあ、そこをクリアしたとしてもそもそも70作品全部見る人ってどれだけいるのか疑問。
昨年も思ったことだが、この一般審査ってまともな審査になるんだろうか・・・

で、まあとりあえずこのブログを見ているそこの暇な人はstepfeedをよろしくお願いします。

追記

これっていつまで投票受付？
stepfeed使って1日1個ずつ見られるぜ！とかやろうとしたけど、全部つめこむと7067日間かかる計算になる。
どうも今月27日授賞式らしいから7067日間も取れない。
で、分割して出そうにもいくつに割ったらいいのかワカランかった。
式まで一週間見て19日まで、ってなかんじであと10日間くらいかねぇ。

いちいち問い合わせるのもめんどいから適当にやろう。

というわけでドリコムのAward On Rails 2007に応募しました。
なんとかstepfeedリリースです。

これが何かと簡単に言うと、ウェブ上のコンテンツをフィードにのっけて読者にお届けするための仕組みです。
それが普通のフィードと何が違うのかと言うと、基本的には別に変わらないのですが、フィードが更新されるペースと内容がひとりひとりのユーザーごとに合わせたものになっているという点がちょっと変わっています。

例えばたくさんの人がステップフィードのフィードを購読している場合。
今日はそれぞれの人のフィードはどんな状況になっているか。

今日読み始めた人のフィードには1ページ目のコンテンツだけが載っていて、昨日読み始めた人のフィードには2ページ目まで。
一週間前に読み始めた人のフィードには7ページ目か8ページ目までが載っているという状態になります。

各自が本を最初のページから毎日1ページずつ読むみたいなイメージ、というとわかりやすいでしょうか。

詳しくはこちらを読んでみてください。
まあ一番わかりやすいのはいくつかフィードを購読してみることかと思いますが。

と、いくつかといいつつサンプルに登録してあるコンテンツがひとつだけですみません。
もっといろいろ登録しとこうと思ったのですが、ページ本文の自動取得のアルゴリズムが思いの外ヘボくて心がくじけました。
このあたりは早速いろいろ試行錯誤中しつつ修正中です。

そんなわけで作った人も登録にくじけてしまうほどですが、よかったら何かコンテンツ登録してみてください。
2ページか3ページのくらいのコンテンツだったら手で修正しつつなんとかなると思います。
トップページやコンテンツの一覧がカオスになっても気にしません。今のところは。

ちなみにこっそり試してみたいって人は登録時にプライベートモードにすると表の一覧に出てきません。
URLを直で叩かれると見られちゃいますけど。

いずれにせよ触ってもらって何かフィードバックなどもらえると幸甚です。

開発中いろいろやったことなどまた後で書きます。

温泉ランク.comの方も裏の処理とかを地味にメンテしつつ、現在はドリコムのAward On Rails 2007のために半年前に作って寝かしておいたモノを手直ししています。

これはごく狭い範囲でα公開はしていたんだけれども、そこから先モチベーションが続かず放置プレイ。
いやぁ、こういう趣味で作るサービスは勢いが続くうちの短期決戦が重要ですな。
アワードのおかげで第二弾ロケット点火といった状況です。

さてそういったところでモノを半年ぶりに改めて見てみると、ちょっと直したいところたくさんで現在かなり手を入れているところ。
気がつけば締め切りまで一週間切ったので、夏休みの終わりに宿題をまとめて片付ける小学生よろしくラストスパート中です。

と、話は変わりますが、昨年のアワードで受賞したFLotはまことに残念ながらまもなく休止状態にする予定。
改めて手を入れていこうかとも思ったけど普通のブログユーザーとかに自然に使ってもらえるシナリオが思い浮かばない。
思えばフィードのURL張り替えるとか敷居高杉だよね。

何かよいアイデアがひらめいたら再開するかもしれません。
なんかサービス名が気に入ってるので割と再生したい気持ちは強かったりします。

近況とか

ニコ動が俺の時間を吸い取るのを何とかしてください。

本家のWikiにまとまってるページがあった。

HowToRunBackgroundJobsInRails

いろいろ手段があるようだ。

• AP4R
• RunnerScript(script/runner)
• daemon_generator
• RailsCron
• BackgrounDRb
• プロセスをフォークさせる
• ActiveMessaging
• スレッド使う

ここで言われているバックグラウンドのジョブを大きく二つに分けると次のようなかんじだろうか。

• ユーザーのアクションをトリガーにした非同期処理
• 定期的なバッチ処理

定期的なバッチ処理に向くアプローチ

自分のやりたいのはとりあえず後者の方なので次の手段が良さそうだ。

• RunnerScript(script/runner)
• daemon_generator
• RailsCron

RailsCronとかパッと見よさげなんだけど、入手先のサーバが落ちてて試せなかった。
ずっと落ちっぱなしみたい。
とりあえずはRunnerScriptかね。

ただしRunnerScriptを使う場合は以下の点に注意とのこと。

• ジョブごとにスタートアップのコストがすごい
• 同時に複数ジョブを立ち上げるとメモリ消費がすごい
• ジョブの起動や停止をRailsから管理できない

たくさんのジョブを同時に走らせたり、走っているジョブの制御を行いたい場合はRunnerScriptは向かないみたいだ。

あとおまけとしてRunnerScriptでコントローラを使う方法がここにあった。

非同期処理のトリガーを定期的に叩く

または非同期処理のトリガーになるURLをwgetとかで叩くというのもアリかな。

非同期処理で確実なトランザクションをしたいならAP4Rがよさげに見える。
けどウェブサーバ間でリクエストを送るようなので、長い時間のかかるジョブをまかせるとタイムアウトしそう。
あとトランザクションをしっかりしたいニーズはとりあえずないのでこれは今回はパス。

BackgrounDRbはDRbサーバを立てるのでタイムアウトの心配がなく長時間かかる処理にはいいかもしれない。
これ試してみようか。

ActiveMessageはActiveMQを入れて立ち上げたりとかめんどくさそうだなぁ。
ということでひとまずパス。

てかざっとなめただけなので、まだいろいろとわからんことが多いです。

参考

• HowToRunBackgroundJobsInRails
• RailsCronプラグインを使う – Hello, world! 瀧内＠ドリコム研究室のブログ
• [rails]Rails的cronの使い方 – 与太郎プログラマの日記
• How to Execute a Rails Controller Action via. Cron
• AP4R ホームページ
• Asynchronous Messaging with Rails – kiwamu日記
• BackgrounDRbについて調べてみた – I sort my thought
• activemessaging – Google Code

2008/03/22追記

BackgrounDRbに関するエントリを書きました。

BackgounDRbでRailsの非同期処理とかバッチ処理とか

温泉ランク.com

昨日のことになりますが、↑とりあえず出しました。

締め切り直前はひとまずの仕上げとして公開環境をセットアップして、作りかけの見苦しいところを整えたりとかいったことをやってました。
まだまだいろいろやりたかったんだけども、一区切りと言うことで。
区切りがつかずにこういう作業をするタイミングを逃してズルズル行ってお蔵入りとか割とあったりするので、締め切りがあるというのはやっぱ大切ですね。

Mash up Awardは一回出した作品を次も出せるようなので、こういう「とりあえず公開へ」という気持ちの切り替えもしやすかった。
これはMash up Awardのいいところですね。次回以降もこの姿勢は続けていただきたい。
やっぱサービスは運用してなんぼというか、運用を始めると自分の頭だけで考えてたのに比べてほんとにいろいろ出てくるし、 そこから新しい価値が生まれてきたりする。
やっぱサービスは運用してなんぼですね。

今回出した温泉ランク.comに関してはテーマが自分の好きな温泉に関するものなので、運用しつつ今後もちょくちょくいじっていきたいと思ってます。
何よりこのサイトは自分にとってドッグフードを食べるのが苦にならないところが素晴らしい。

こういう自分の欲しいものを作るというのはモチベーションとしてわかりやすくて良いなぁ、と常々思ってます。
「これ作ったら儲かりそう」とか「これ作ったら人気でそう」とかって自分的にはあんまりモチベーションにならないんだよな。
「面白そう」はまだマシだけど「欲しい」よりはやっぱり弱い。「欲しい」一番。

もちろん自分の欲しいものを作って、それが面白くて人気が出てしかも儲かっちゃったりしたらそりゃもうベストです。

script/runnerを使うといいようだ。
これは引数の文字列をRubyスクリプトとして解釈し、Rails環境で実行するというもの。

script/runnerによって

ruby script/runner 'p Onsen.count'

といった具合にコマンドラインからモデルを使った処理を実行できる。
コントローラは使えません。（でした）

対象にする環境は-eオプションを使ってdevelopment,production,testをそれぞれ指定できる。
何も指定しない場合のデフォルトはdevelopment。
ゆえにproduction環境で実行したければ以下のごとし。

ruby script/runner -e production 'p Onsen.count'

ちなみに多少複雑なバッチ処理は当然ファイルに書いたスクリプトから読ませたい。
しかしそのために普通にパイプとか使っても駄目だったりする。

解は以下参照。

ActiveRecord と ActiveSupport を使ってコマンドラインアプリを作る – ma2の日記

ruby script/runner 'eval(IO.readlines("hoge.rb").join)'

それにしてもやっぱhogeは基本。
自分もhoge.rbでファイルから実行するテストをしていたので、サンプルコードまんま実行できたｗ

追記

RailsアプリでActiveRecordを使ったバッチ処理　その３書きました。
みんないろいろ工夫している模様。

定期的にAPIからデータを取得するためのバッチ処理を作成している。

まずやりたいことはActiveRecordを使うこと。
あとデータベースの情報はdatabase.ymlから取得するようにする。いろんなところに分散してしまうのは気持ち悪いので。

それで出来たのが以下のようなコード。

require 'rubygems'
require 'active_record'
require 'yaml'

ConfigFile = File.join(File.dirname(__FILE__), "..", "config", "database.yml")
ds = YAML.load(File.read(ConfigFile))
ActiveRecord::Base.establish_connection(ds["development"])

これでActiveRecordを使うことができる。

ds["development"]の内容を展開すると以下のようなかんじになる。

ActiveRecord::Base.establish_connection(
  :adapter => "mysql",
  :host => "localhost",
  :username => "user",
  :password => "pass",
  :database => "app_dev",
  :socket => "/tmp/mysql.sock"
)

Cronからコマンドラインで実行するものなので、環境を引数で指定できるようにするといいかもしれない。

まあとりあえずこんな風に作ったが、他の人はどういうやり方をしているんだろうなぁ。

参考

Rubyist Magazine – プログラマーのための YAML 入門 (初級編)
Railsレシピ

追記

そいやBackgrounDRbってプラグインがあるって聞いたっけ。
気が向いたらフォローしてみよう。

追記2

script/runnerを使ってやる方法がとりあえず普通みたいです。
RailsアプリでActiveRecordを使ったバッチ処理　その２書きました。

追記3

RailsアプリでActiveRecordを使ったバッチ処理　その３書きました。
みんないろいろ工夫している模様。