どうも、今まで日本から一歩も外に出たことのない、井の中の蛙の高梨です。

昔から英語は好きで自分なりに勉強していまして、今ではそこそこ喋れるくらいになりましたが、今まで英語圏も含め、外国に行ったことがありませんでした。中学のときに、ある先生が「英語なんてアメリカに住めば簡単に覚えられるよ。」みたいなことを言っていたので、「なら俺は日本にいたまま英語喋れるようになってやる！」と思いたち、現在にいたっております。我ながら素直じゃありませんね。大学の時には留学しようと思っていたら、なんと留年してしまいました。orz

ただまあ、いつかは行ってみたいという希望はずっと持っておりまして、今まではお金があるときには暇がなく、暇があるときにはお金がない、という大変ありがちな状況が続いておりました。

が、今回ある程度両方が見込める状態になったので、ご存じの通り円高ですし、晴れて海外、それもアメリカはニューヨークに行ってみようと思い立ったわけです。そう、あの自由の女神が立っているニューヨーク、です。栄町で入浴するのとはわけがちがいます。w

なんで近場の韓国でもなく、日本人に人気の高いハワイでもなく、いきなりニューヨークかというと、理由は単純で「友人がいるから」です。以前、彼とその一家は鴨川に住んでおり、ALTとして働いていたときに知り合いました。毎年夏になると鴨川に来ていたので、今年は来るのか聞いてみたら「行く予定はない」とのこと。

ならこっちから行こうというわけで、その友人にはホテルの手配をお願いし、私は航空券とパスポートを準備すればいいことになりました。向こうでも色々楽しいところに連れて行ってくれるそうなので楽しみです。

しかし、そうは行っても*初*体*験*なのでやはり不安はあります。ニューヨークなんて一歩間違えたら危ないエリアに踏み込んでいた、なんてことになりそうだし。

まず行ってみたいのはニューヨークからは離れるんですが、スミソニアン博物館。日本に原爆を落としたあのエノラ・ゲイが展示されている有名な博物館です。前の消防旅行で知覧に行ってきましたが、アメリカではエノラ・ゲイがどのように評価されているのか、非常に気になります。

また、アメリカでITというと、西海岸のシリコンバレーが有名ですが、東海岸部にもいくつか有名な大学がありまして、その一つがボストンのマサチューセッツ工科大学(MIT)。実は大学の友人がMITのTシャツをおみやげに買ってきてくれたんですが、その後はからずも体が成長してしまい、今ではパッツンパッツンの上におヘソが出ちゃうようになりました。orz ので、もう少しゆったりめの服を買い直そうと思います。

あと、計算機屋なら誰だって見てみたいのは世界初の「汎用型」コンピュータ “ENIAC”ですよね。

祖国ハンガリーに侵攻するナチス軍に抵抗するために、アメリカに亡命していたフォン・ノイマンはこのENIACの後継機種EDVACの設計・開発に積極的に貢献したというエピソードがあります。この頃、計算機の主な利用用途といえば、真っ先に軍事目的でした。

インターネットも元々は、合衆国に散在する大型コンピュータ同士をリンクして、どこか一ヶ所が核攻撃を受けても他のマシンで対応できるように、という方針のもと整備されました。それが大学機関同士を結び研究者に開放され、その後商用サービスとして企業が提供できるようになり、一般市民も利用できるようになった、という経緯があります。

また、プログラマにとって恥ともいえる「バグ」の語源は、このころのコンピュータでは真空管が多用されており、その光と熱に集まった蛾が、故障の原因になることが多く、その蛾をさして「バグ(虫)」というようになった、という説もあります。

ちょっと離れたニューヨーク「州」には IBM本社がありますし、計算機屋としての見どころはアメリカ東部にもいろいろあります。

コンピュータの歴史を知るという意味では、大変面白い旅になりそうです。

未だMicrosoftプロダクツから脱却できない、しかも諸々の事情により、新バージョンに乗り換えることのできない皆様こんにちは。

弊社のあるクライアントから「ストレージサーバ内のファイルの開きが悪い」との報告を受け、この何日か原因を探っておりました。「悪い」ってのはどういうことかというと、開くのにものすごく時間がかかり、タイムアウトしてしまい、その結果としてExcelが落ちるということでした。

私のVirtualBox内では現象が再現できなかったため、わからずにいたのですが、今日客先でぐぐったら意外な原因であることが判明したのでお知らせしたいと思います。

こちらにあるように、この現象の原因は、最近配布された「Microsoft Office File Validation Add-in (OFV: Office ファイル検証機能)」にあるようです。実際、弊社の環境でもこのアドインをインストールした状態で、共有フォルダ内の .xls を開こうとしたらやはり「開きが悪」くなりました。

さらにM$らしいというか、上記ページに書いてあるレジストリの位置が間違っています。ｗ 大丈夫か、M$ !

誤：HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\

正: HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\

というわけで、この不具合を回避するレジストリを配布させていただきます。

OFV-fix.zip

ご注意！ このレジストリを適用する前にバックアップを取ることを「強く」お勧めします。また、適用したことによる引き起こされた不具合・データ消失・その他いかなる損害についても、弊社は一切責任を負いません。適用はご自身の判断にて行ってください。

というか、M$の尻ぬぐいは勘弁して欲しいっす。。。みんなLinux使ってHappyになろうぜ！

GTDという言葉に耳慣れない方も多いと思いますが、”Get Things Done”の略で、簡単に言えば「タスク管理」「やるべきことをどう管理するか」ってことです。

ご存じの通り、私自身はそういったことに関してあまり成績のいい方ではありませんで、過去、いろいろな方法を試してきました。手書きメモから始まり、PCアプリケーション、スマートフォン、ブラウザ組み込みなどなど。重要なのは

• 嫌でも目に入り
• 参照したいときはいつでもどこでも即座に参照できる

という２点です。メモ帳に書くのは「それを持ち歩く習慣があり、かつ置き忘れない自信も持ち合わせている人」に限られます。PCアプリケーションはそのデータが入ったを持ち歩かなければならず、スマートフォンは他にしたいこと(Twitter, Skype, Facebookなど)がアイコンの形で目に入るので、ついついそちらに誘惑されがち。まあ普通の自制心を持ち合わせている人なら大丈夫なんでしょうが、そもそもそれさえあればGTDなどする必要もないでしょう。

ただ、最近その究極形に近づいたっぽいので、恥ずかしげもなく公表してみたいと思います。それは「モニタのサイド枠に付箋を貼り、かつ(必要ならば)クラウド上に詳細を書き込む」です。

そもそも、ディスプレイ上のスペースというのはPCで仕事をする人にとって貴重な空間です。そこにGTDアプリを常置するくらいなら、いっそ画面の外に出してしまいましょう。付箋なら、さっと書き込め、かつ詳細な情報までは書くスペースはないので、自然と「パッと見てどのタスクのことかわかる」簡潔な書き方になります。それに、終わったタスクを指で揉みくちゃにして捨てると、意外なほど爽快な気持ちになれます。ｗ

また、ここはPCで仕事をする人なら「嫌でも目に入る」場所に他なりません。私は、左側を「やりたいこと、またはオリジナル企画」右側上を「やらなければならないこと」右側下を「出かけたら買ってくるもの」という具合に分けています。

重要なのは、後で見て「えーと、これ何のことだっけ？」と迷うような書き方はしない、ということです。モノの性質上、自分で分かればいい、いやむしろ、自分にだけ分かればいいという点に留意しながら書きましょう。

ネット上に詳細を書き込む場合ですが、私はEvernoteを使っています。弊社の業務の性質上、仕様書や指示書の内容が多岐に渡ることがあり、タスクを補完する意味でも、詳細はどこかに置いておく必要があります。Evernoteであれば、協働者とも共有が簡単ですし、自分自身へのドキュメンテーションにもなります。

これをやっていたところ、家族に「IT企業の社長にしてはずいぶんと原始的だね」と苦笑されました。しかし、それでいいのです。目的さえ果たせれば、手段は原始的でもハイテクでも。

目下の問題は、たぶん100円ショップで買ったものだからでしょうが、「付箋がどんどん剥がれ落ちてしまうこと」です。orz しかし、それを逆手に利用して、時限つきGTDとするハックもあるみたい。。。 とりあえず私は粘着強度高めのしっかりした付箋を買って来ようと思います。

IT配管業の皆様こんにちは。へなちょこ鯖管の高梨です。

さて、既存のWebサービスを新サーバに移管したり、一時的に別サーバで動かしたい、なんていうときは、どうされていますか？

• サービスを止めずに、
• データの整合性を保たなければならず、
• さらにDNSの設定は諸般の事情によりいじれない

という過酷な条件のもと、なんとかしなければならなくなったら、もう泣きたくなっちゃいますよね。

そんなあなたにご紹介したいのが、以下の iptables 2行。ご存じの方も多いかもしれませんが、私的に大きな収穫だったのでお知らせしたいと思います。

以下、1.1.1.1が旧サーバ、2.2.2.2 が新サーバ、HTTP(80/tcp)を移管したい、とします。1.1.1.1上で実行します。

# iptables -A PREROUTING -t nat -p tcp -d 1.1.1.1 --dport 80 -j DNAT --to-destination 2.2.2.2:80
# iptables -A POSTROUTING -t nat -p tcp -d 2.2.2.2 --dport 80 -j SNAT --to-source 1.1.1.1

これだけで、転送用のデーモン(プロキシ)などを立てるまでもなく、旧サーバの80/tcpへのアクセスは新サーバの同ポートに転送されるようになります。もちろん、アクセス元の制限はありません。一旦旧サーバを経由するので、若干アクセス速度は落ちますが、カーネル動作ですし、日本国内での転送であれば、そう遅くはならない、と思います。DNSのキャッシュに悩まされることもなく、大変便利。

キモは２行目の SNAT でして、これでパケットの送信元IPアドレスを旧サーバのものに書き換えています。1行目だけだと、送信元IPが書き換わらないので、帰りのパケットが正しい経路を経て帰ってきません。

私もiptablesは必要に迫られたら調べるクチなので、動作は保証しかねますし、これ以上の説明はできませんが、参考になれば。

ほんとにひさびさの更新になってしまいました。

タイトルの数式、もちろん数学的には間違っています。では何がいいたいか、というと・・・

弊社もついに、「人」を雇うようになりました！＼(^o^)／

一人社長として呻吟しながら、あるいは連絡さえ取れなくなりお客様にご迷惑をおかけしながら、なんとか5年あきらめず頑張ってきましたが、これで弊社の抱える問題の一つが解消されました！今、本当に気が軽いです。

いずれ、このブログにもその方に投稿していただくようになるかもしれませんので、お読みの皆様におかれてはよろしくお付き合いのほどお願い致します。m(__)m

いつだったか「弊社ホームページを見て仕事依頼は、今のところない」ようなことを書きましたが、その方は、なんと「弊社ホームページを見て」エントリーメールを送ってきました。すでに何件かお仕事を依頼し、働いていただいております。

正直な話、仕事の依頼などより、優れた人材を呼び寄せられるほうがどのくらいありがたいかわかりません。特に、当市のような地域においては。

人柄・職歴については申し分なく、技術的にもちょうど私の詳しくないところをよくご存じなので、まさに願ったりかなったりです。

ちょっとこのところすでに請け負っていた仕事でバタバタしていたので、体制は整備中なのですが、まあ少なくとも「一人社長」と卑下しなくてよくなったのかな、と思っています。ｗ

あとは、ちゃんと給料を支払えるよう定常的に仕事を獲得できるか、が問題ですね。今までなら私がガマンすればよかったのですが、これからはそうもいかなくなります。ただ、この点については、最近私自身が多忙だったこともあり、その繋がりはもちろん維持しているので、あまり心配していません。むしろ、「スタッフが増えました」と言えば、より安心しておつきあいいただけるのではないかと思っています。

１人を雇う体制を整えれば、２人、３人と増やしていくのは、たぶん最初のときよりも苦労はないはずで、その準備に取り組んでいます。

世の中は、3.11震災の影響で風評被害やら倒産やらと不景気な話ばかりで、もしかしたらこんな話は不謹慎なのかもしれませんが、弊社としてぜひアナウンスしておきたく、今回の記事を書かせていただきました。

今までは、機械を動かすことを考えていればよかったですが、これからは人を動かすことも勉強もしなければなりませんね。なんて、生意気なことを言っていますが、皆様からのご指導・ご鞭撻をよろしくお願い致します。m(__)m

[2011年4月12日 09:55 追記] リトル・チャロ2にも対応した Ver.0.13 を公開しました。

コメント・メールなどで不具合をお知らせいただきました皆様、また、対応方法をコメントにお寄せいただいた皆様に感謝申し上げます。

キャプチャツール Ver 0.12 Ver 0.13(2011年度&リトル・チャロ2対応バージョン)を下記のリンクよりリリースさせていただきます。

nhk-rtmp-capture-ver0.13

使い方は今までと変わりありません。リトル・チャロ２にも対応しようと思いましたが、今のところ対応できていません。ご了承ください。 リトル・チャロ2のストリーミングダウンロードにも対応しました。また、ダウンロード中にウィンドウを操作しても表示が固まらなくなりました。

2011年度からはFlashの再生プログラム(streaming.swf)に変更が加えられ、毎週、14桁のマジックワード(0077PTLP2BX71C, 0109BSNQVLFRF1など)が埋め込まれるようになり、これを抽出しないとダウンロードできない状態になっておりました。これを解析する方法を探っていたのと、弊社業務、また私自身の体調不良などが重なってしまい、リリースが遅くなりました。申し訳ございません。

このマジックワードの解析方法は人の手を介さず、自動的に解析できる方法を確立ずみです。毎週月曜日に最新のものに更新し、それを本ツールで読みに行く形を取っています。

また、今回は公開方針・および寄付のあり方について、ご指摘をいただきました。

公開方針について

このプログラムは多くのオープンソースソフトウェアを使って構成されています。そのプログラムをクローズド・ソースにして公開しておりましたのは、改変が加えられた場合、私が責任をもてなくなってしまうことを危惧したためです。しかしながら、今回、対応方法など、ユーザー様から多くのご協力をいただきました。この状況を鑑み、Google Project Hosting に全コードと使用バイナリを公開することに致しました。

寄付について

当初、自宅サーバで公開していましたところ、予想を大幅に超えるアクセス数をいただき、とても自前サーバでは対応しきれず、やむなく外部ホスティングサービス(さくらインターネット)を利用することになりました。サーバ代自体は月数百円程度ですので、自前でお支払いしてもよかったのですが、「もしかしたら月1回くらいは寄付があるかもしれない」という予想のもと、任意の寄付をお願いしておりました。が、こちらも予想を大幅に超える善意の寄付をいただくことになりました。

おかげさまで寄付ベースのビジネス(?)に関して充分な経験を積むことができました。コメントなどでご意見もいただいているところですし、これを機に弊社あての寄付は受付を終了とさせていただきたいと存じます。今までご寄付いただきました皆様、誠にありがとうございました。

ただし、皆様ご存じの通り、3月11日に発した東日本大震災には今後も多額の援助が必要となりそうです。日本赤十字社のサイトからは銀行振込・クレジットカード・コンビニ決済など多様な義援金の受付を行っています。

もし、本ソフトが皆様のお役に立ち、その謝意を示すことをご希望される方は、上記リンクより、任意の額の義援金をお申し出いただければと存じます。

今後のTODOなど

先にも書きましたとおり、リトル・チャロ２への対応ができておりません。また、Windowsでの利用を前提としており、Mac対応のリクエストもいただいております。ですので、

• リトル・チャロ対応
• Adobe Airアプリとして作り直し、Mac&Win両方で動作するものにする

を今後の課題とさせていただければと存じます。

今後とも、本ツールへのご理解・ご協力をよろしくお願い申し上げます。

改めて申し上げますが、この度の震災で被災された方々には心よりお悔やみ、お見舞い申し上げます。

さて、私もこの１週間というもの、ネット、マスコミから随時情報を得ていました。その過程でいくつか分かってきたことがあるので、整理しつつまとめてみたいと思います。

ネット、特にツイッターはかなり有効

もちろん、不確かな情報やデマが出回ることもあります。しかし、何分か経つとほぼ例外なく「それはデマだ」という、裏が取れたもっと信頼に足る情報も必ず流れます。

私の場合、フォローしている(こちらから注視している)人は456人、フォローされている(私に注目している)人は400人といずれにせよそんなに多くないのですが、それでも今回は必要充分な情報が回ってきました。

また、今回、「拡散希望!」の類は敢えてリツイートしませんでした。それが本当かどうか、私にはすぐに判断できませんし、裏が取れるツイートが回ってくるころには、すでにもっと大きなメディア(ブログやマスメディア)で取り上げられていたからです。

「じゃあツイッターの意味ないじゃん」と思われるかもしれませんが、それ以外にも、自分なりの意見だったり、日常的なつぶやきなどもあるわけで、それはそれで心を落ち着かせるのに大変有効です。

ツイッターのみならず、Facebookで知り合った海外の友達(地震の前に急に増えました。主にカンボジア)からも応援のメッセージを沢山いただきましたし、また日本人以外とチャットなどしていると一時気が紛れていいものでした。

福島原発については、国内マスコミと併せて海外メディアのWebページも見ていましたが、避難区域、および関東周辺には問題視されるべき量の放射能はないという点で報ずるところはほぼ一致しておりました。もちろん、原発プラントの状況は今なお予断を許されない危機に見舞われてはいますが、ひとまず政府・東電の情報を信頼してもよさそうです。

むしろ今回ひどかったのは・・・

政府当局および東電、またそれを報じるマスコミ各社でした。主なものを挙げてみると

• 原発事故発生当初の情報の混乱。特に内閣・原子力保安院・東京電力それぞれ言うことが違っていた。これでは国民の不安を徒らに煽るだけです。特に保安院の最初の会見はやった意味が全くなかった。
• 記者会見で質問する記者の質。見ているこちらが東電に同情したくなるくらいの高圧的な質問。また会見に臨むまでにできたはずなのに、ろくな勉強もしていないことがまる分かりでした。私たちは記者さんたちも、見ているのですよ。
• 今だに続く政府の情報公開の遅れ。枝野官房長官の冷静で的確な応答には感心させられましたが、それを差し引いても政府の情報公開への煮え切らない態度は不満が募ります。特に野党時代、あれだけ自民党政権に情報公開を求めていた民主党にしては全くその点不足している。

などの点でしょうか。原子力発電所やガスタンクなど、危険性の高い施設を扱う大企業は災害時、現場で復旧にあたる担当者はもちろんですが、それと併せて災害広報担当者を設け、わかりやすく正確な情報を知らせる備えをしておいていただきたいものだと思いました。日本では否定的な意味で使われることの多い「レトリック(修辞学)」ですが、こうしたときには大変役に立ちます。

大切なのは「心のフィルタと理解力」

私の周りには、比較的しっかりした人が多いのでその点安心してはいるのですが、このような時はパニックに陥り、判断力を失うことが一番危険です。自分だけでなく、他の人をも巻き込み、影響を広げることにもなりかねません。

またそうならないためにも、時々刻々と流れる情報を理解し、評価し、判断をくだす能力も必要です。卑近な例で恐縮ですが、一発目の地震が起こってから避難所に避難したのは近所ではうちの母だけでした。幸い、この辺りは被害も少なくて済んだので、取り越し苦労と今になっては笑えます。ただ、もし東北のような大津波になっていたら、笑うことさえできなくなっているわけで、それを思うと背筋が凍ります。そういう意味で、手前味噌ながら、母の判断は正しいと言えるでしょう。

今もなお余震は続いていますし、原発プラントでは懸命の作業が続けられています。復興に向けての生活支援も官民あげて始まっています。また残念なことに義援金詐欺も発生しているようです。まだまだ油断は禁物、とはいえ、的確な判断力を失わず、社会を止めず、復興に向けて一歩ずつ歩んでいきましょう！

お客様各位ならびにおつきあいいただいている皆様

日頃は大変お世話になっております。代表取締役　高梨でございます。
海に近いところに在しております弊社について、ご心配いただいているかと存じｊます。まず、私自身、および家族ともども無事でありますことをお知らせさせていただきます。物質的な被害も被っておりません。

以下、弊社でご提供しておりますサービスにつきまして、状況をお知らせ致します。

メーリングリストをご利用のお客様

メーリングリストが稼働しているシステムは米国にホスティングされております。よって今回の地震による影響はほぼないと存じます。ただし、国内回線事情により、大容量のメールが発信できないなどの事象が発生するかもしれません。回線の復旧をお待ちいただいてから送信いただきますようお願い致します。

Webサイト、ブログ等を弊社でお預かりしているお客様

サイトのデータは東京のデータセンターに保管されております。これを書いている時点で全てのデータに異常は発生しておらず、安全に保管されていることを確認いたしました。

コンピュータ、その他修理などでハードウェアをお預かりしているお客様

物理的な被害は全く被っておりません。引き続き、修理作業を継続させていただきます。

その他、弊社内部の情報・データに関して

地震発生直後、ファイルサーバを安全な場所に退避いたしました。現在復旧作業にあたっておりますが、業務への支障は全くありません。

鴨川市内の状況について

海に面している当市にお知り合いがいらっしゃる方のためにお知らせします。私（高梨）が昨日、消防団で待機中に見聞きした範囲では、一部地域で停電が発生しましたものの、人的な被害および家屋の浸水・倒壊などは起こっておりません。報道されているように、今回の震災の被害は想像を絶する規模になっておりますが、当地では幸いにも比較的被害が少なく済んだ地域と言えます。

最後に、今回の地震により、亡くなった、あるいは被災された方々へ衷心よりお悔やみ、お見舞い申し上げます。皆さま、どうかご無事でいらっしゃいますよう。

Google App Engine が Ruby信者にとっての踏み絵に思えて仕方のない三寒四温の今日この頃、皆さまいかがお過ごしでしょうか。

Chiba.rb の会合をなんと鴨川でやるということになり、迂闊にもこんな発言をしてしまいました。

https://groups.google.com/group/chiba_rb/msg/ff7c6ebb9fe22058?hl=ja

高梨＠鴨川です。
こしばさん、お誘いとご提案、本当にありがとうございます。 m(__)m
鴨川での開催はいつでもウェルカムです。場所取りはなんとかしますので。
あと、わたし的にご提供できるネタとしては

* RoR on GAE (環境は構築したものの未着手w)
* mod_rubinius 構想 (計画段階)

という非常に中途半端なものがあります。(笑 まあ勉強会のために勉強するのが自分のためにもなる、と思っておりますので ご容赦ください。
皆様、これからもよろしくお願い致します。

場所取り云々は知り合いに頼んだのでなんとかなるとして、問題は発表するネタのとこです。

最近、仕事の案件はPHPべったり、ホビープログラミングはGAEのPythonべったりだったので、Rubyからは遠ざかっていました。まあこんな記事もあることだし、ちゃっちゃとできるっぺ、とタカをくくっていました。そんなところが房州天津人の甘いところです。現実はいつも厳しいもの。

ええとまず、ソフトは出来る限り最新の物をというポリシーで生きてますので、/usr/local/bin/ruby -v の出力はもちろん1.9.2-p180でした。でも、これが良くないらしいということに気づいたのが、作業開始から 30分ほど経ってから。

で、rvm というもので複数バージョンのRubyを共存できるらしいと知り、rvm環境内に1.8.7系をインストールするのに20分。

さて、大変なのはここからでした。まず、「10分ではじめる GAE/JRuby (OAuth + Sinatraのサンプル)」という記事の日付ですが 2009年9月3日になっています。つまり、もう1年以上前の情報。そこからたどれるのもそれより前のものです。というわけで、JRuby/GAE にも変更があります。

結果としては以下のような手順になります。

$ rvm install 1.8.7
$ rvm use 1.8.7
$ gem install google-appengine -v "0.0.19"
$ cd /to/your/source/directory/
$ appcfg.rb generate_app appid
$ dev_appserver.rb appid

これで開発用ローカルサーバが立ち上がりますが 、

javax.servlet.ServletContext log: WARNING: no rackup script found. Starting empty Rack application.

という不吉な警告が出ます。http://localhost:8080/にアクセスすると、案の定

Internal Server Error (500)

になります。で、これの原因は　jruby-rack のバージョンが「新しすぎる」ためで、Gemfile 中で1.0.6 未満を指定するとうまくいきます。こんな感じ。

$ cat appid/Gemfile
# Critical default settings:
disable_system_gems
disable_rubygems
bundle_path ".gems/bundler_gems"
# List gems to bundle here:
gem "jruby-rack", "< 1.0.6"
gem 'appengine-rack'

で、改めて dev_appserver を立ち上げて、ブラウザでアクセスすると・・・

Hello

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!　表示されました！

コマンドラインだけ並べるとなんてことないですが、原因追究してもエラーメッセージぐぐっても思うような情報が得られなかったり、でさんざん苦労しました。

つーか最新バージョンでうまく動かないってのはどうなんでしょーね。私の環境を書いておくと

$ uname -a
Linux messarina 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 10.10
Release:	10.10
Codename:	maverick$ java -version
java version "1.6.0_24"Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

こんな感じで特別なわけではないんですが。

Railsまでたどり着くにはまた別の道のりが必要でしょうが、ここまでの作業で私は心が折れました。orz

とりあえず自分がやりたいことにRailsは必要なくて、JRubyが動けばいいだけなので、今日のところはここまでにします。皆さまの健闘を祈ります。

facebookのウォールやTwitterのタイムラインが気になってしかたがないソーシャルモンキーの皆さまこんばんは。無料で使えるAPIやPaaSを日々探索中の高梨です。

さて、私事ですが、以前からこういうのできたらいいなーと思っていたことのひとつに「SNSを通じて知り合った人と本やCD, DVDを貸合えたら」ってのがありました。さすがにP2Pでデータをやりとりとなると著作権法的にアレでしょうけど、現物を貸し借りする分には問題ない、はず。一言で言えば「P2P図書館」です。ちょっと前までは日本でSNSといえばmixiでしたが、ガラケーアプリ開発が必須だったり、時代の流れ的にfacebookかな、と。何より商用利用も可ってのがいいですよね。

まあ実際に貸し借りをしなくても、個人の蔵書データベースをネット上に持てるだけでも、ちょっとステキです。「へー、この人の読んだこの本、面白そう」とかね。中には持ってることを公開したくない物もあるでしょうけど、それは非公開にするか、そもそも登録しなければいいわけで。

実際すでに、似たようなサービスはいくつかありますが、私がやりたかったのは

1. USBカメラに書籍のISBNバーコードを見せて登録 (いちいち検索&登録という2段階の作業をしない)。
2. バルク登録(ISBN一覧データで)も可能。
3. 本を登録したりコメント書くと同時にウォールに書き込まれる。
4. データはいつでもエクスポート可能。
5. 「借りたい」申請が「いいね!」くらい簡単にできる。
6. 本棚でカテゴリ分けできて、RSSで取得できる。

といったものです。ブクログさんなんかはかなり上に近いです。特に、4.の機能は地味だけど大切で、いくら提供側が「クラウドだから大丈夫」といってもユーザさんの安心度が違ってきます。実際、読書メーターさんの機能リクエストを見ても、データのインポート・エクスポートは需要が高いようです。APIを切りだして実装はユーザさんに任せるというのも手ですね。

で、いろいろ調査して以下のようなサービスを材料にすることにしました。

• Amazon Product Advertising API (書籍&商品データ取得。海外の商品も検索できるようにする)
• Google App Engine (Webインターフェース、ビジネスロジック。言語はPython)
• Amazon SimpleDB (いわゆるNoSQLだが、LIKE 検索も可能。GAEのDataStoreではそれができない)

また、使用するライブラリは以下。

• jQuery (AjaxおよびXMLパース)
• ZXing (Flashでバーコード読み取り)
• boto (AWSを使うためのPythonライブラリ)
• Kay (GAE専用？のフレームワーク)

ソースコードのレポジトリはSubversionホスティングをしてくれる unfuddle.com に置くことにしました。

というわけで、材料の調査はだいたい目処がつきました。後はこれを組み合わせてコーディングしていきます。