【IBM sMash】 マッシュアップはサーバでいいんですか。いいんですよ。

　先日、IBM@渋谷マークシティでsMashの話を伺う機会があった。sMashは、RESTful SOAということで、いわゆるWeb2.0的な今どきのコンテナである。sMashの主な特長は以下のとおりだ。（今回はsMashについて説明するが、私の主観がかなり入っており、IBMの戦略や意図とは異なる部分があることをご容赦願いたい。断定的な言い方にはすべて「～のような気がする」を追加して読むぐらいがちょうどよいだろう。）

* JVMで動作するGroovyとPHPをサポート
* 軽量(LightWeight)なコア
* RESTfulなSOA設計。
* サーバサイドMashup
* クライアントはDoJoだが強要するわけではない
* オープンプロセスで開発されている（オープンソースに近い)
* オープンレポジトリ　(by Ivy,Maven2）
* デュアルライセンス（大規模に利用するときに限り有償）

まず、RESTfulについて、URIの設計がリソース中心できれいに設計されている。とてもシンプルで分かりやすい。今流行りつつある、URItemplatesは提案してみたものの、意識すべきかどうか微妙だと思った。必要があればquery parameterを追加すれば十分かな。
クライアントでDoJoを強要するわけではないに同意。リソースから簡単にPDFを作成できる弊社のReflexiTextやクライアント設計モデル（JavaScript版Strutsのようなもの）と組み合わせるといいものができそうだと思った。ivy,maven2レポジトリの採用はとてもいい。
　それから目に付いたのは、JVMで動作するGroovyとPHPのサポート。そして、軽量であること。これには今のLL時代にどう対応するかというIBMの苦悩と戦略を感じる。Project ZEROといわれるように、Web開発のあり方を根本から見直すことで、重厚長大なJava文化を払拭して、スクリプト言語の高い生産性を取り入れる一方、これまで培ったJavaの資産を活用する戦略である。なかには、これまでのJava戦略を覆すとか、SCA・SDOの立場はどうなるとか、疑問・不信を感じられる方もいるかもしれないが、元IBMerである私は、これがとてもIBMらしい一貫した戦略であることが理解できた。なので、ちょっとここで説明させてもらいたい。
　IBMが十数年前から貫いているソフトウェア戦略の一つに、お客様のソフトウェア資産をマルチプラットフォームでサポートするということがある。小さなPCで始めた業務アプリがスケールアップしたときに、メインフレームほどの大きな環境を用意できるのはIBMだけだから、安心してIBMに任せなさいと。しかし、かつてのOS構想(OS/2、OS/400、OS/390)では、統一したAPIでそれを実現しようとしたがうまくいかなかった。ところがJavaはうまくいった。WebSphereとDB2により、すべてのプラットフォームで一度書いたアプリが動くようになった。
　お客様資産の活用とは、お客様自身のデータおよび既存アプリケーションの活用である。それをサクサクとインターネットなどへ適用できれば大きな価値を生み出せる。実際にY社の荷物追跡システムはそうだった。今でこそ一般的に使われているが、当時はお客様自身、その価値に気づいていなかった。これは、お客様資産の活用が困難で、時間やコストがかかっていたなら実現できなかっただろうと思える。
　そこで、さらに一歩すすんだことを考える。マルチプラットフォームでサポートすることがお客様へのコミットメントであるなら何もJavaにこだわる必要はないわけだ。要は、JVMを活用しながら他の言語でもサポートできるようにすることが、お客様資産を活用することにもなる。Javaが敬遠される理由には、納期が長い、融通がきかない（仕様に準拠しないと怒られる）、開発費が高いなどがあるが、LLで解決できるなら、それでよいのではないだろうか。

　また、GroovyとPHPが必要な理由と、サーバサイドWebアプリの否定ではないことを付け加えたい。ブラウザから直接サービスを実行するスタイルが主流になることは認めるが、この記事の後半でも触れているように、XMLを仲介する変換サービスや、ちょっとしたHTMLをサーバサイドで行う必要がどうしてもでてくる。このちょっとしたコーディングはスクリプト言語が最も得意とするところである。

　それから、sMashで最も重要だと思う点は、サーバサイドMashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。
　また、Controlに位置するものは、今どきの言葉でMashupといったが、これには違和感を覚える方もいると思う。私は、Mashupをただの変換・編集とするのは間違いだと考えている。ビジネスロジックを含み、また、マッシュアップしたコンポーネントがさらにリソースと同等になるとさらによい。データ更新にはトランザクション管理を伴い難しいので、現在はまだ変換・編集が多いのも事実だが、今後はビジネスロジック中心に組み込まれていくのは明らかである。私は、Mashupが単なる変換・編集からビジネスロジックを含むControlに役割が変わったときに、本当の意味でオブジェクト指向設計の次の段階に進むことができると信じている。
　これまでにも、ワークフロー設計は、ESBやワークフロー製品で採用されてはきたが、往々にして重厚長大になり、コスト面で引き合わなかった。このような統一したアーキテクチャーのもとではどうしても重厚長大になってしまう。それがRESTful SOAにより疎結合開発が可能になろうとしている。これには統一したアーキテクチャーはいらない。リソースの設計において、コンベンション（規約）を重んじることでインターオペラビリティ向上が図れるからだ。リソースを積み木のように組み合わせて開発する。本当にそれが実現できれば、RESTful SOAは、進化ではなく革命に近いものになるだろう。
　
　最後に当面の課題について触れたい。
　まず、Webアプリ開発者にとっては、どうやってシステムを設計、実装していけばよいか、イメージが伝わりにくい。先に述べたように、Webアプリではそもそもワークフロー的に作る文化がなく、サービス志向、REST志向で作る文化もない。SOAPは古くからあるが少数だ。また、更新系の設計をどうするかも課題だ。コンポーネント間の2phaseコミットは大変かもしれないが、トランザクションスクリプトでシンプルな設計にすべきだと思う。とにかくシンプルにして多くの開発者に支持されないと、SCA、SDO、ESBといったManagedなアーキテクチャスタイルで陥ったように、シュリンクを経験するはめになる。

　Project ZEROは、Incubator Project（将来的に有効に活用できそうな新しいアイディアや技術を模索するプロジェクト）の一つで、Don Fergusonの発案らしい。
Managedなアーキテクチャスタイルに背を向け、IBMを全速力で飛び出してRESTを志向した私であるが、そこで書いた絵はsMashと瓜二つ。お釈迦様（Ferguson）の指に書いた孫悟空、といったところかな。

＜追記＞
こちらに提案を書きました。
ReflexとsMashによるソリューションの提案

【雑記】 くだらない妄想

ジョブズ氏引退後のアップルを考える

ジョブスのいないアップルは、たかた社長のいないジャパネットを想像すればよい。

ジャパネットたかたは日本のスティーブ・ジョブズか？

【本日の嵌り】 いざというときのMySQL関数

売上データ送信プログラムが動かない。原因は仕様漏れ。商品以外の送料やポイントを先方指定のJANに変換すべし、ということをついさっき言われた。先方の「お勝手JAN」に変換してあげないとエラーを起こすそうだ。本日から運用開始なのに、そんな大事なこと、もっとはやく言おうよ～。＞＜；

でも、こんなときに頼りになるのがMySQL。ロジックを修正するんじゃなくてSQLに関数を追加すればよい。

select
case when item_code = '送料' then '0000000000001' when ・・・ else jan_code end as jan_code
from table

これで解決。

【雑記】 iPhoneサービス価格発表！おもてなしで勝負あり？

本当に微妙なところを突いてくるなあ。うーん。
iPhone 3G向けサービスの詳細について

【EC開発体験記-Entity-】 自己完結したデータの集合

　Entityの設計はシステム設計の肝である。だが、構造をどうするかとか、外部参照や冗長をなくすとか、考えだすときりがないし、とにかく時間と労力がかかる。通常は、RDBのERモデル、オブジェクト志向のドメインモデルなどに則って設計することが多い。それぞれ設計ツールも豊富なので利用価値はある。しかし、概念や設計ツールの学習コスト、リレーショナルとオブジェクトの変換コスト、インピーダンスミスマッチは馬鹿にできない。そこで、ここは敢えて頭を空っぽにして、Entityの最低限必要な情報、すなわち、項目および属性とその構造だけに着目して、それらを洗い出すことから始めるとよい。とにかく、最初から難しく考えないで設計を進めていき、問題があればあとで修正する方法をとる。おすすめは、マインドマップの作成だ。（参考：テキストをマインドマップに変換するツール）　
　次に、自己完結した情報となるように項目を括る。とにかく外部参照のないものにするのがコツだ。例えば、カタログ巻末にあるFAX注文書は、受注に必要な情報がすべて記載されており、それだけで自己完結した情報となっている。システム化する際には、１枚の注文書が１インスタンスとなるように、さらには、1インスタンスが1レコードとなるように設計する。こうすれば、Entity＝Tableというイメージとなって都合がいい。そのことを、否定の２として挙げた。

否定の２
２．テーブルは第3正規形まで設計しない

　ここは正規化したい気持ちをぐっとこらえるのがポイントだ。また、Entityの階層を２階層とする一方、Tableの項目名をEntityと同一とする。このような規約で縛ることを、設定よりも規約（Convention over Configuration，CoC）という。こうすると、自由度は下がるが生産性は高まる。また、学習コストは少なく、インピーダンスミスマッチを解決できる。もしかしたら、「こんな設計ありえないだろ！」と正論をかざす頑固なRDBスペシャリストが出てくるかもしれないがスルーでよい。そもそも、設計にエネルギーと時間を使わないための規約なのだから、やらなくてもいい議論はやらない方がいい。ここは議論したい気持ちをぐっとこらえるのがポイントだ。

　話は戻り、ここで実際に、ECにおける「受注」について考えてみる。「受注」とは、「誰が何を注文して、いつどこに届けるか」という情報である。これを思いつくままに書くと、以下のようになる。

受注
　受注日時
　注文主
　　氏名
　　住所
　　電話番号
　　email
　　カード番号
　届け先
　　氏名
　　住所
　商品
　　JAN
　　売価
　お届け日時
　配送方法
　決済方法
　ステータス

以上が、とりあえずのEntity設計であるが、見ての通り、突っ込みどころ満載である。
まず、2階層といったくせに3階層になっている。（受注＞注文主＞氏名）このままではいかんので、規約に則って2階層に修正しなければならない（受注＞注文主氏名）
　それから、何気なく列挙している「ステータス」がある一方で、普通あるはずの「受注番号」などのキーがない。意味不明なものがあって、あるべきものがない、という中途半端なものになっている。また、１受注に複数の商品を購入される方もいるはずで、なんらかの「受注番号」で括る必要がある。さらに商品レコードを示すキーも必要になる。（商品レコードは一品一葉という概念で管理されている。これについては別の機会に説明したい）

　次にステータスを説明する。データが妥当（Valid）かどうかはステータスにより管理する。「ステータス」は、簡単にいうと、「受付られた」、「出荷された」等、データがどういう意味をもっているかということを示すためにある。いわゆる「判（ハンコ）」と同じものだ。
　まず、データがValidであれば、判を押された文書のように、それだけで意味を持つようになる。例えば、「ステータス＝受付」で、その商品が在庫にあり、指定した日に届けられる予定であることを意味し、「ステータス＝出荷」で、商品が出荷され、売上が計上されたことを意味する。

　また、判を押すためには、データの妥当（Valid）を判断するビジネスロジックが別途用意されなければならない。受注を受け付けるための条件は次の通りである。

１）注文主は実在するか
２）商品は存在するか
３）カードの与信はOKか
４）お届け日に配送できるか

　これらビジネスロジックは、サービスとして実装できるものばかりである。Entityを入力値としてサービスを実行し、データが妥当であればステータスを更新すればよい。これは、リソース志向に則った設計でもある。

　ビジネスロジックに関連して、プロジェクトでどうしてもやりたかったことで、否定の１、および１０がある。最後に、これについて説明したい。

１．受注番号等のキーを採番しない
１０．Web受注はブラウザからのプロバイダ通信だけで完結させる

　採番はシステムのあらゆる面でネックになるので、何とか頑張って無くしたかった。そのかわり、「誰がいつ注文したか」を示す、メアド＋受注日時(takezaki@mail.com-20081012010203012)をキーとした。そして、プロジェクトの第一フェーズまでは実際にこれで運用した。

しかし、これはやはり無謀であった。・・・動くものはなんとか作れたが、データ操作が非常に面倒くさくて、とても運用できるものではなかった。大反省（ ＞＜；した末、今では受注番号はキーとして必須であるという結論に至っている。
　採番はシステムのあらゆる面でネックになるといったが、特に心配だったのはスケーラビリティへの影響である。これは採番プロバイダとしてサービス化することでなんとか解決できたと思う。現在の採番プロバイダは受注番号以外にも配送伝票番号や生産番号などのキーを複数発行している。
　また、プロバイダ通信だけで完結させるという案１０は、採番プロバイダの例のように作ることで有効であるように思えた。実際にECシステムでは、商品マスタや受注機能のプロバイダ化ができており、AJAX（JavaScriptによるプロバイダ通信）を駆使すれば、ブラウザとプロバイダだけでECサイトが作れると思った。しかし、セキュリティとSEOの２つの理由で断念せざるを得なかった。まず、カードオーソリのために外部サービスを呼ぶ必要があり、これをクライアントのJavaScriptだけで実行することは不可能であったこと。それから、SEOにおいては、HTMLを出力できることが重要で、どうしても中間にXMLからHTMLを生成させるPHPを介在させる必要があった。
　このように、あまり面白くない結果になってしまったこのECサイトであるが、実はPHPから商品プロバイダや受注プロバイダを呼んでいるし、カート（Flex2）からも同様にプロバイダを呼んでいる。にもかかわらず、外部から見ると普通にDBを検索しているように見えてしまう。まあ、サービス志向でWeb2.0サイトであることを醸し出せないのはちょっと残念ではあるが、それなりに意味のある設計だとは思っている。
これからも無謀と思わずいろいろトライしていきたい。

【雑記】 Firefox3 圧倒的なパフォーマンスで勝負あり

この記事は信じがたいものだったが実際に入れてみたら嘘ではないことがわかった。ひゃ、はやっ！
“史上最速”のFirefox 3が登場へ、「IE7の9.3倍速い」
クライアントプラットフォームの安定化、高速化により、今後はJavaScriptの活用がさらに進むだろう。それを見越しているのか、すべての自社製品をSaaS化しようとしているAdobeもまたすごい。まあ、Adobeに関していえば、Flashを取り込んだ時点で方向性は決まっていたのかもしれないが、アプリがネットワークに依存することのリスクも覚悟しなければならないわけで、大きな決断だったとは思う。また、デスクトップインストール型に比べ、SaaSだと機能に多くの制約が出てくる。Photoshopなどは到底、SaaSにできないだろうとは思っていた。いずれにせよ、ブラウザだけで実現するネットワークコンピュータがより、現実的になった日であることは間違いない。Adobe AIR

【本日の嵌り】 SSHポートフォワードでMySQLにアクセスする

MySQLサーバポート(3306)に直接アクセスできない場合、sshでログインしてポートフォワードするとよい。

「Linuxがクライアントの場合」
ssh -N -f -L 3306:192.168.1.1:3306 work@192.168.1.1

「Windowsがクライアントの場合」
puttyでトンネル＝＞源ポート8081、送り先localhost:8081で追加する
L8081 localhost:8081

これで解決。

【おしらせ】 暮らしのデザイン取締役を退任しました

本日付けで、暮らしのデザイン取締役を任期満了により退任致しました。
プレスでも発表しておりますが、暮らしのデザインは、エディオンからニッセンホールディングスに移ります。暮らしのデザインのサービスは継続しますので、今後も引続きご愛顧賜りますよう、宜しくお願い申し上げます。

【本日の嵌り】 Tomcat common/lib/xxx.jarの内部ファイルを読みこむ

Tomcatのcommmon/lib配下にあるJarファイルの内部のリソースを読めるようにしたい。
それには、Jarファイルの場所を含むurl(以下jarurl）を作成する必要がある。
jarurlは、「jar:file:/C:/･･/common/lib/xxx.jar!/jp/reflexworks/sample.xml」という感じで、!の前がJarファイル名、後がパッケージ名となる。「.」は「/」に置き換わる。
これさえ作れれば、あとはnew URL(jarurl).openStream();とやれば読み込める。

Jarファイルの場所付きurlを作成するには、以下のように、log4jのLoader.getResource()を使うと便利。

URL url = Loader.getResource("jp/reflexworks/sample.xml");
String jarurl = "jar:file:/"+url.getFile().substring(5);

これで解決。

＜追記＞
以下のfile://のように、2回//があると読めなくなるので、ちょっと修正。

jar:file://C:/･･/common/lib/xxx.jar!/jp/reflexworks/sample.xml

URL url = Loader.getResource("jp/reflexworks/sample.xml");
String jarurl = "jar:"+url.getFile();

【雑記】 ソフトバンクがiPhoneを獲得した理由

これは分かりやすい　↓

、iPhone 3GでYahooにアクセスし、Yahoo!オークションやYahoo!ショッピングを利用してもらえれば結果として収益は上がる。すなわちiPhoneを携帯電話ではなくインターネット端末だと考えれば、ソフトバンクにとっては十分魅力的な製品である。これはインターネット全体でビジネスをしている同社の大きな強みだ。

ソフトバンクとiPhoneが日本の携帯を変える--ソフトバンクのiPhone獲得を考える

なるほど・・・。よく考えてみたら、ソフトバンクモバイルは携帯キャリアのひとつではあるが、ソフトバンク本体は通信サービスが本業ではないのだ。全社的な取り組みとしては、通信サービス、すなわち、電波や通信回線の利用料を徴収するビジネスモデルに拘らず、より付加価値の高いインターネットビジネスに誘導する。こんなことは、到底、Docomoには真似できないだろう。

しかし、本業のインターネットビジネスといっても、Yahooぐらいしか思いつかない。ソフトバンクオリジナルは何もないわけで・・・、昔からそうなんだけど、なんとなく気持ち悪い。

【本日の嵌り】 Google先生にエラーコードで聞く

ちょっと恥ずかしいが毎度のごとく嵌るネタをメモしていくことにする。
Googleにエラーコードそのものを入れて検索するとズバリ回答が出てくる。これは便利だ。

嵌り１）昨日、久しぶりにTomcat＋Eclipse環境を使ったのだが、Tomcatプラグインがちゃんと動かない。

java.lang.ClassNotFoundException: org.apache.catalina.loader.DevLoader

と出ているので、Google先生に「org.apache.catalina.loader.DevLoader」と入れて聞いてみた。そしたら、件名：EclipseでTomcatが動かない!!が見つかって、

プロジェクトのプロパティでTomcatを選択すると、
開発用クラスローダの設定がありますが、
「使用する」にチェックされていませんかね？
チェックされていたら、チェックを外してみてください。

それで無事Tomcatは動くようになったが、今度はアプリケーションが見つからないようだ。
maven2の環境だったので、server.xmlのContext docBaseに以下を追加

docBase="・・・・\src\main\webapp"

これで解決

嵌り２）Maven2でデプロイしようとしたら 「\65279 は不正な文字です」と出る。
エディタで見ても先頭には何も文字らしきものは入っていない。そこで、Google先生にコピペして聞いてみたら、\65279 は不正な文字です。が出てきた。
サクラエディタで開いても見れないが、ファイル－＞名前を付けて保存　とすると右下にＢＯＭがチェックされているので、これを外すとうまくいった。

これで解決

【雑記】 iPhoneは売れる？

この２つの記事を読んで売れるか売れないか考えてみた。

iPhoneがなぜそれほどまでに「革命的」なのか
iPhoneは売れない

見事なほど対照的な意見だ。

最近のAppleはたしかにすごい。何年か前に、MSから資本が入ったときは、「生かさず殺さず」などといわれたAppleが、よくもここまで盛り返したものだと思う。ソフトウェア以外にコアテクノロジーがないにもかかわらず、何かすごいものをもっているように感じさせるのはなぜだろう。「おもてなし」とか、後付けの理由はいろいろあるようだが、私の理由は、MSとSONYの自滅だ。その結果、相対的にブランド力が向上しただけじゃなかろうか。「おもてなし」と言い切ってしまうと、私のような鈍いものにとって説明が難しいと思う。（私はiPod nanoの掘り込み印字に気がつかないし、スタバに入ってもドトールと区別がつかない）

　かつてのソニーは技術力によりブランドイメージが作られた。トリニトロンとか、ウォークマンとか、ソニーの独自の技術力は、他社に追随を許さないように思えた。当時はCMもすばらしかったので購買意欲は増幅される。そして、その商品を手に入れたユーザの満足感は非常に満たされた。これがすなわち「おもてなし」。このような好循環になれば多少高くても買ってくれる。ブランド力が向上した結果、安いネタで高く売るというビジネスモデルを確立できる。

　また、MSはWin95,Win2000に尽きる。まるで一人の人間が作ったかのような、統一された出来栄えには非常に驚かされた。一方のOS2は、人が寄ってたかって作ったんだろうなという感じを受けた。OS2には操作に統一感がないので、使うときに「あれ？どうやるんだっけ？」と迷うことがよくあって、私はすぐ忘れるのでメモに残すことをしていた。一方のWin95は、たぶんこうやればできると直感的にすぐわかった。メモはもちろん必要ない。当時の北城社長は95を「ゲームのような、おもちゃOS」と酷評していたが、実は「おもてなしOS」だったというオチ。MSのすごいところは、たぶんこうやればできるという直感的な操作感を、Officeや、さらにはSQLServerにも継承させていること。MSのソフトであれば、いちいち操作を覚える必要はないと想像できた。これもブランド力ではなかろうか。
　（カミングアウト）まだ新人であった私は、非力なPCしか与えられなかったことを理由に95を社内で堂々と使っていた。（北城さんが何ていおうと、「だって僕のマシンではOS2動きませんから」と言い訳して、内心ニヤリ）同期で95ばかり使っていた社員は、たぶん私だけだったろうし、最もOS2が分からない自信があった。それから社内の冷たい視線に絶えること数年、OS2は使われなくなった。

最近は、SONY、MSに陰りが出てきた。一方、追いついたAppleが成長した。Macは私もたしかに欲しいが、その一番の理由はVistaを使いたくないから。現時点で最高なOSはもちろんWin2000。軽くて早くて使いやすい。たぶん、Macに乗り換えるのは時間の問題だろうが、ThinkPad X21のキーボードに慣れた私が乗り換えたときに苦労するのは明らかなのでまだ買っていない。なので、私はいまだにIBM社販で買ったThinkPad X21を愛用している。（2000年に社販購入して償却したところで退社した。）

話は戻る。
iPhone VS ワンセグお財布携帯、どっちが勝つのだろう？

今回の勝負は、「技術力＝ワンセグお財布」　VS　「おもてなし＝ブランド＋使いやすさ」だ。

でも、こんなふうに考えるとぜんぜん面白くないなあ。

私の予想はズバリ、今年に限って言えば、話題性はあるが大ヒット商品にはならない。少なくとも、今年年末のヒット商品の横綱にはならないだろう。でも。iPhoneの背景にある「革命的」なことを考えると、通信業界にとって「大インパクト商品」なんだろうなという気はする。「革命」の流れは止められないと思うので長期的に見るとiPhoneの勝ちだろう。通信業界の変な構造は変革させたい。ガラパゴス化がすすんでいる日本の技術。それを駆逐する「革命的」な技術という意味で、DOS/VがPC98を駆逐していった状況に似ていると思う。

iPhoneの背景にある「革命的」なことについては、こちらの本を参照してほしい。



最後に、電池の寿命は重要。W-ZERO3は電池がすぐ切れるから痛かった。

iPhone とおサイフケータイ

【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト

以前、Modelとはモデリングの成果物であるという説明をした。分かりにくかったかもしれないが、これは要するに「オブジェクト」であり、データおよび、それを操作するメソッドを含んだ「もの」ということだ。オブジェクト志向で何が嬉しいかというと、詳しくは、WEB+DB vol44を見ていただきたいが、一言でいうなら、

オブジェクト志向では、「もの」によって「できること（機能）」が連想できるのです。
　　　　　　　　　　　　　　　　　　　　　　　- WEB+DB vol44 p76 豆蔵 萩本氏 -

普通に作るとModel=Entity+Blogic(業務ロジック)となる。「もの」が持つデータはEntity、「できること（機能）」がBlogicである。これはこれで問題ないように思えるのだが、実際にBlogicを実装していくと多くの問題に突き当たる。その原因の一つが、自分以外のモデルを参照する外部参照である。外部のModelは参照するけれども、主な責務は自分にあるので内部にメソッドを定義している、といったケースはよくある。しかし、そのメソッドが返す値は自分自身のEntityとは関係なかったりする。こうなってくると何でもアリになってくる。そして、「Entity重要」から「Blogic重要」になり、しまいには「あれ？Modelって何だっけ？」という話になる。これではモデリングの意味がないし「Entity重要」を強調するためにも、一旦、Blogicのことは忘れてEntityだけを設計することに注力すべきである。これがオブジェクト設計といえないことは前述したとおりである。なお、Blogicの解決策については、後半部分で触れる（太字で記す）

ここで、「Entity重要」の設計について整理してみたい。

１．分析クラスのEntityをもとにデータの構造体を実装する(entity0)
２．entity0のCRUDを実装する

問題は外部参照だ。Entityは他のEntityとコミュニケートできないとされるので、うかつに関係線を引くとモデラーの先生に叱られることになる。であるなら、関係のない新たなEntityを作成すればよい。（ただし外部参照のEntityへは内包線が引かれることになるので注意する）



Entityを内包するためにControlを使う。

Controlの定義

１．CRUDメソッドの実装部分を受け持つ
２．Blogicや外部参照のEntityを複数呼べる
３．トランザクションを管理する(1UOW)
４．Model内からのみ使用できるメソッドである(private) (修正：2008/09/30)

具体的には、次のような、controlXを追加する形になる。

１．分析クラスのEntityをもとにデータの構造体を実装する(entityX)
２．外部のEntity(entity0,entity1)を参照して内部のEntity(entityX)にマッピングする(controlX)
３．entityXのCRUDを実装する
（省略）

サンプル

　// Entityクラス
　public class EntityX extends ControlX{

　　public String item0; // 要素０
　　public String item1; // 要素１

　}

　// Controlクラス
　public class ControlX {

　　　　private Blogic blogic = new Blogic(); // Blogicクラス(業務ロジック)
　　　　public EntityX retrieve(EntityX entityX) {

　　　　　　　　Entity0 entity0 = (new Entity0()).retrieve(entityX.item0);
　　　　　　　　Entity1 entity1 = (new Entity1()).retrieve(entityX.item1);

　　　　　　　　entityX = blogic.convert(entity0,entity1); // マッピング

　　　　　　　　return entityX;
　　　　}

　　　　public EntityX create(EntityX entityX) {
　　　　　　　・・・
　　　　}

　　　　public EntityX update(EntityX entityX) {
　　　　　　　・・・
　　　　}

　　　　public EntityX delete(EntityX entityX) {
　　　　　　　・・・
　　　　}
　}

また、例のように、外部参照のEntityは複数あっても構わないが、内部EntityのCRUDは1UOWとする必要がある。すなわち、複数の外部参照のEntityをトランザクションで括る必要がある。（この実装はちょっと難しい。内部APIのような密結合であれば、実質的にはSQLになるのでDBMSのトランザクション管理を利用すればよいが、サービスのような疎結合では2phase commitなどを考慮しないとうまく管理できない。いずれにしても、この実装では、ロングトランザクションではなく、Atomicなトランザクション管理が要求されることになる。）

また、convertというBlogicが登場している。これはentity0,1からentityXにマッピングするメソッドであり、entityXのModelに属するものだ。さらにいえば、controlXもentityXのModelに属する。Entityの中にControlが入ることになるが、これも内包として考える。（内包は再帰的に考える）
　そして、convertに限らず、BlogicはすべてEntityを入れてEntityを返すとしてよさそうである。ただし、BlogicにI/Oを持たせてしまうと外部参照となってしまうため基本的にNGである。ResourceへのアクセスはEntityのCRUDメソッドだけが許されるものとし、さらにBlogicからはそれを呼ぶこともできないとする。EntityのCRUDメソッドを呼べるのはControlからだけだ。
Blogicで可能なことは、Entityを元に計算や変換処理を行って、Entityに詰めなおして返すだけ。なんとも制約の多いものだが、これがカプセル化として働くため、非常に安定したシステムとなる。（後ほど説明するがテストも楽になる）
したがって、Blogicの定義は次のようにする。

１．entity = blogic(entity)
２．Blogicは揮発性である(ステートレスでありデータを保持しない。また、外部リソースへのI/Oはない）
３．Model内からのみ使用できるメソッドである(private) (修正：2008/09/30)

このように、「Entity重要」の設計を行っていくと、自然とBlogicが整理されてくる。
Blogicが追加されて最終的に出来上がったものがModelである。そして、そのModelがさらに他の参照元になりえるという再帰的なModelとなる。（Groovyコンファレンスデモの実装の例を記事に書いているので参考にしていただきたい。＝＞リソースの実装）

Controlは、Modelの中に内包されてEntityとしても振舞う。考え方としてMashupに近い。


以上が私の考える「Entity重要」のリソース志向設計である。
独自色が強いのでおすすめはあまりできないが、何か設計の参考になれば幸いである。

【EC開発体験記 -スキーマ開発-】 誂えスキーマを開発してはいけない理由

サービスのAPIを開発しない理由にもつながる話。

自身、TravalXMLとか、いくつかの誂えスキーマに携わったことがあるにもかかわらず、否定するのは筋が通らないかもしれないが、無駄なものは無駄である。まず、以下を読んでいただきたい。

お仕着せスキーマと誂えスキーマ

そして、Tim BrayのBigFiveは、それを強調した話となる。
Tim Bray 「もうXML言語を開発するな」 と、それに対するUche Ogbujiの反応

これらを読むと、XMLではないが、APIを（標準化を見据えて）開発することは無駄なことのように思えてくる。

では何が「お仕着せ」で何が「誂え」なのか。
産業界で普及しているという尺度には議論の余地があるものの重要な判断材料だとは思う。しかし、AtomPubといえども「お仕着せ」に見えて、結果的に不発で終わるかもしれない。
こうなってくると余計、分からなくなってくる。

一方、WikiPediaのタグ化に見られるような語彙は、地味ではあるが、着実に浸透すると思われる。
FavikiとタグとDBpedia

結論は、ユーザが開発するスキーマは野良で、それから、できればWikiPediaのタグを使おうということでＯＫ？

【EC開発体験記 -リソース志向-】 APIをやめデータ構造に着目する

あらかじめ断っておくが、ここで説明するリソース志向は、私自身の開発の経験から必然的にたどり着いた解であって、一般的に説明されているROAとは多くの部分で異なる。ここでは、正確なROAの説明をするつもりはないし、本当のROAとは？などと、不毛な議論もやりたくない。ROAもしくはリソース志向という言葉を便宜上使わせていただいているが、それは、自分の解に一番近いと思われるからである。したがって、私の説明をそのまま世間で使うと痛い思いをするかもしれないので気をつけていただきたい。

まず、リソース（以下Resource）の定義から説明したい。Resourceとは、分析クラスから導き出されるEntityを具現化したものである。噛み砕いていうと、モデリングにより定義された自己完結したデータの集合という感じだ。前記事で、分析クラスのBoundary、Control、EntityをStrutsのMVCモデルに落とせない話をしたが、リソース志向では、EntityがそのままResourceとなる。これは非常に分かりやすい。（Entity設計の責務は誰が負うべきかという課題はあるが、これはまたの機会に説明したい）また、Resourceは、それを指し示すID（URI）をもち、データ構造を公開できる。公開の手段は、XML、JSON、YAMLなんでもいい。これについては、インターオペラビリティの話として後ほど詳しく説明する。それから、ResourceのAPIはCRUDの４つだけとする。トランザクションを管理し、それぞれのAPIは1つのUOW(UnitOfWork)で実行されなければならない。注意していただきたいのは、このAPIはHTTPに限った話ではないということ。言語のAPIにもなりえる概念的なものということだ。また、RESTはステートレスといわれるが私はそうする必要はないと考えている。単純にステートレス＝揮発性と考えると、リソースが揮発性になってしまうのはむしろ不都合になるからだ。リソースは不揮発性だが、トランザクション管理という意味では、不完全なものは破棄するという性質（揮発性）は持たなければならない。ステートレスの話はトランザクション管理に帰結すると思うので、私の定義では1UOWとなった。

＜私が考えるリソース志向＞

１）リソースは自己完結したデータの集合
２）リソースはデータ構造をもち公開できる
３）リソースに対してCRUDで操作する
４）リソースは特定できるアドレス（URI）をもつ
５）リソースに対して１UOWで操作する

ここで話が戻るが、公開するデータ構造は何でもいいという話をしたい。公開用のスキーマ言語は、必要最低限のデータ構造を表現できれば十分。それは、きちんとインターフェースを定義したい方はスキーマ言語を使うだろうが、それでもセマンティクスを十分に定義できないのは同じであり、いずれにしてもデータ長や意味などを説明した資料は必要になるからだ。
　私はかつて、Webサービスの最も重要な性質の一つとして、インターオペラビリティを挙げていた。しかし多くの経験から学んで今ではかなり否定的になっている。数年前になるが、XMLコンソーシアムで、参加企業十数社がそれぞれの製品をもちよってWebサービスの接続実験を行ったことがある。その実験では、たしかに、言語やプラットフォームを越えて接続できるという利点は認められたが、各製品の制約が多すぎて、WSDLを変更しなければならないことがしばしばあった。製品に合わせてWSDLを変更するなんて本末転倒である。実際に接続するには相当な苦労があったわけで、ダイナミックバインディングなんてのは夢の世界。絵に描いた餅であった。そもそも、スキーマ言語でセマンティクスを完全に定義できないことの重要性に早く気づくべきだった。
　インターオペラビリティの問題は本当に難しい。WSDL(XMLSchema)はCORBAにはできなかった言語の壁を越えることができたがセマンティクスの問題は解決できなかった。AtomPubは、この問題を解決できる可能性があるとは思ったが、普及していない現状を見る限りでは難しいように思える。（AtomPubにはすごく興味があって、ReflexではRFC前であるにもかかわらず実装を行った。たしか、2005年頃までのdraft-ietf-atompub-protocol-04.txtの実装を行ったが、自分の感性に合わなくなったことと、インターオペラビリティに疑問を感じたのでやめてしまった。）結局のところ、AtomPubにも同様の困難が待ち受けていると思われる。

そこで得た結論は、否定の３と７

３．各サブシステムで共通のエンティティを使用（最小単位は1品1葉1レコード）
７．サブシステム間を密に結合させない（サービスだけで繋ぐ）

これは要するに、システム共通のentityを定義して、それをやりとりすることだけに注力しようということだ。SOAPやAtomPubなどのAPIを介さないし、そのような共通APIに該当するものを敢えて開発しない。しかし、最低限は必要になるので、先に挙げたリソース志向を踏まえて定義する。具体的には次のような非常にシンプルなAPIを定義することになる。

＜API例（entityはリソースの１インスタンス）＞

entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);

サブシステム内であれば上記APIをそのまま使う。サブシステム外ではHTTPのPOST/GET/PUT/DELETEがそれぞれ対応する。例えば、GETを実行するとシリアライズされたentityが返ってくる。繰り返しになるが、entityの表現はJSONでもXMLでも何でもいい。実際のプロジェクトではReflexによりJSONとXMLの両方を使っている。(Reflexはentityの写像を取るフレームワーク。entityをJSONとXMLにシリアライズできる。）

自己完結したデータの集合が意味するところは、一つは自分から他のリソースへの依存がないということ、もう一つは、外からの影響を受けないこと。例えば、他リソースのインターフェースが変更になっても、スケルトンを取り込みなおす必要がない。
　サービス志向では、インターオペラビリティの問題があって、セマンティクスに関係した部分が不安要素として残っていた。自己完結したデータの集合、すなわち、リソースを中心に設計していくことで、より安定した大規模なシステムを並行開発できるようになる。

【Hadoop】 究極のWebサービス。やられた感いっぱい ＞＜。

AWSとHadoopでiText変換はまさに考えていたところ。ショック大きい＞＜；。
でもこれがWebサービスの究極の姿であり、Virtual Technologyが目指すところ。めげずに頑張ろう・・・。
Self-service, Prorated Super Computing Fun!
解説
Running Hadoop MapReduce on Amazon EC2 and Amazon S3

Hadoop MapReduce
Hadoopアーキテクチャ
Hadoopクイックスタート日本語訳
Hadoopを触る
Hbaseアーキテクチャ
Hadoopいろいろ
Hadoop HDFSのRead/Writeサンプル
それからIBMもHadoopに注目していることが分かった（前記事の発言は撤回しますm(_ _)m）
IBMのBlue Cloudは、ウェブコンピューティングの別名

【EC開発体験記-設計-】 MVCモデルは進化する

アーキテクチャスタイルと重きを置いているレイヤを見ていただきたい。これは2年ぐらい前の絵なので、ちょっと古いし、正直、適切でない言葉が使われていると思う。RESTはSOAと同列に書くとすればROAだろう。SOAなんてカッコつけないで、Webサービスぐらいにしておけばよかった。また、Web2.0をBoundaryに置いているが、広範囲に使われる言葉になった今では違和感がある。当時はAJAXブームもあり、クライアント技術が先行していたので、それほど違和感なく見れたのだが、それにしても、この業界の進化は早い。今これを書き直すとすれば、View、Mashup、Resource、といったところかな。実装技術では、Viewのところが、JavaScript, Flex2 AIR, PHPで、Mashupのところが、PIPES, Plagger, sMash、Resourceのところが、Hadoopやhbase, ネット上のRSS,ATOMとするのがしっくりくる。Reflexはどのレイヤにも当てはまるがResourceに置くのが一番適していると思う。(書き直した絵＝＞RESTful設計におけるレイヤと主な実装技術
　長々とわけ分からん絵の説明をしたが、いいたいことは設計をどうすべきかということ。
　オブジェクト指向設計では、まず、ユースケースの図と記述を作成して分析クラスを導き出す。プロジェクトでも同様にやったのだが、これは非常に有効な手法であった。しかし、分析クラスから、その後の設計クラスをどのように作っていくかについては、モデラーの感性に依存するというか、正直なところ曖昧で、あまり機能していないのではないかと感じている。世の中にはこれを課題と感じないスーパーなモデラーがいるのは承知している。分析クラスをそのままStrutsのMVCモデルに落とし込めないのが分かっていても、彼らは平気な顔して設計クラスをサクサク作っていける。（もしかしたら彼らには分析クラスは必要ないのかもしれない）あるいは、経験を積んだモデラーにとっては(※)モデリングがパターン化されており、単純な工程で済んでいるのかもしれない。
（※ オブジェクトを設計していくことをモデリングという）

分析クラスのBoundary、Control、EntityがそのままStrutsのMVCモデルに落とせない、なんていいだすと、スーパーモデラーじゃなくても異論が噴出するかもしれない。（面倒なので詳細は省略するが）単純にいうと、分析クラスのBoundaryは主に画面（入出力装置）、Entityはデータ、Controlは要求に応じてデータを集めたり加工して返すところとなる。問題は、Strutsに落とし込んだときに、Controlのおき場所に困ることだ。StrutsにおけるControlerはフレームワーク自身を指す（あるいは含んでいる）ので、アプリケーションのControlerの立場はどうするの？といった話になる。多くはModelに集約されることが多いようだが、これはこれで面白くない。なぜなら、せっかく分析クラスで分けたものを設計クラスで一緒にするなんてモデリングの意味ないじゃん、と思うからである。稀に、Controlerのパッケージを作って、きっちり別管理しているプロジェクトもあるようだが、管理に強制力はないため、プログラマーによってグチャグチャにされてしまい、どれがModelでどれがControlerか区別がつかなくなるのが現状のようだ。まあ、ControlerとModelをきっちり分けることで、いいことがあるとすれば、ワークフローを導入してControlerを外だしにするような場合だろう。そんな話は滅多に聞かないから、グチャグチャになっても、それほど大きな問題はないと思われるが・・。
いずれにせよ、Modelの実装はけっこう面倒で工数がかかる。テーブルはRDBの世界であり、一方のEntityはObjectの世界なのでインピーダンスミスマッチを解消するためO/Rマッピングが必要となる。私はこのO/Rマッピングが工数増大の大きな要因と見ている。オブジェクト設計のドメインモデルでは、Entityからテーブルを作成していくのが基本だが、テーブルは非常に重要な部分なので、人によってはテーブル設計から先に始めるかもしれない。（分析クラスがなくてもモデラーが平気な顔して設計できるのはテーブル設計があるからだろう？）しかし、ボトムアップ的にそうやってしまうと、Rの都合により作成されたEntityクラスとなって、モデリングが無視されたオブジェクトになる。そのままだと今度はControlerやViewから使用できなくなるので、O/Rマッピングしたクラスをさらに組立て直して、Modelの形を崩さないよう努力するはめになる。そのような組立直しクラスをDXOと呼ぶそうだが、そんな無駄な処理をモデルの中でゴニョゴニョやっているのである。これはもはやオブジェクト設計ではない。

　そこで、得た結論は、

否定の６．オブジェクト設計をしない

である。正確には、設計クラスのModelをオブジェクトにはしないで、オブジェクトで扱うデータに関心を集めようというもの。Modelとは、モデリングによってできた成果物（※）でありオブジェクトであるから、データとプログラムがくっついている状態。それからプログラムを切り離してデータのみに関心を集めて考える。データだけであればオブジェクトではないのでオブジェクト設計をしないことを意味する。とはいえ、分析クラスまでは設計して論理ビューを作る。論理ビューで定義したサブシステム内であれば、勝手に設計/実装して構わないという感じになる。具体的な実装例の記事を書いているのでこちらを参照願いたい。

ZEROからRESTfulアプリを作成
ビューの実装
リソースの実装
フローの実装

（※ Modelの定義は曖昧で様々な説明が存在する。私はこの説明が一番好きだ。）

しかし、これでも同様にO/Rマッピング問題は存在する。Entityは本来はオブジェクトの視点で設計するが、実際にデータを格納するテーブルの設計とどう整合をとるか。これは次の2点で解決する。要は、設定よりも規約（Convention over Configuration，CoC）をやろうということだ。参考：Entity設計

１．Entityはデータ構造の集まりであるから、これをそのままRDBにマッピングする（Reflexはその機能をもっている）
２．ControlやViewからEntityへのアクセスはCRUDのみとする

Entityの設計では、まず、データ構造を定義して単純なAPIを公開する。公開の手段は、XMLやJSONなどを使って表現する。また、APIはデータ操作だけなのでCRUDのみとする。HTTPであれば、GET/POST/PUT/DELETEの４つだけだ。これはRESTと呼ばれるアーキテクチャスタイルだ。Webサービスであればサービスごとに定義されたインターフェースとなるところを、RESTでは4つのAPIでリソースを操作することになる。

データのみに関心を集めたEntityでは構造化はされているがRのイメージに近い。
テーブルのカラム名がクラスのフィールド名と同一となり、それをシリアライズした、JSON、XMLのタグ名も同じになる。テーブルは、O/Rマッパで隠蔽されているイメージから開放され、語彙が統一できてシステム全体で見通しがよくなる。

あと、忘れてならないのはビジネスロジックの存在だ。これは今までModelの中に実装されていたが、Modelはデータだけになったので、別途管理する必要が出てくる。また、実行時にModelをパラメータとして渡すことになるが、まあ、これはこれでテストが楽になるのでOKかなと思っている。

＜関連＞
RESTfulな新３層アーキテクチャ
ドメインモデル貧血症、サービスと振る舞いについて
３分で分かる設計の話

【雑記】 何やってんだ？

最近オープンしたgeohistサービスは、地図と携帯のマッシュアップブログだ。作者は、あの横井勝商店。目的はいまいち不明だが発想は面白い。中をのぞくと横井さんの行動が全部見れる。そのなかで、もっと面白いものを見つけた。なんと、geohistのティッシュを新宿で配っているではないか。

「ユニクロの袋でティッシュ配りはまずいか」だってさ。心配なのはユニクロの袋じゃないだろ？

腹がよじれるかと思った。

＜追記＞
geohistとGeohashing 座標とハッシュ値でオフ会を組み合わせると超クレイジーなイベントができるかも。集まるまでの途中報告をgeohostで行うことにすればいい。

【JUI Tokyo】 JavaScriptいろいろ、個人的にOpenID

昨日、JUI Tokyoに行ってきた。jQueryのPaul Bakausさんによるプレゼンでは、新機能のデモが印象的だった。次々にインパクトのあるデモが紹介されたがソースは非常に短い。ほとんどがプレゼン１画面に収まっていた。Q/Aでは、経歴とか、チーム開発の困難さとか、いろいろ。彼はJavaScript暦5年だそうだ。チーム開発はあまり困難を感じてないようだった。フルタイムは僕一人だからといっていた。JavaScriptの大規模な開発は私も興味があるところだが、ちょっと拍子抜けした感じ。jQueryの今後に期待したい。その他は、amachanやma.laさんの高速化の話が参考になった。今困っているところなので、こういう話は非常に助かる。

下は懇談会の様子。右からshinichitomitaさん、ma.laさん、amachangさん。

amachangさんは私の困っている話を「ウン、ウン」と聞いてくれたが、ma.laさんは半分あっちの方を向いて聞きたくなさそうだった。でも、「表の項目全部にイベントハンドラーを登録している」というようなことをいったら、「そりゃいかんだろう。数百、数千になると動かなくなるよ。１つで十分」とおもいっきり反応してくれた。（onclickを使え！と返されると思ったのだが本音は違うみたい・・？）その後、shinichitomitaさんがやってきてOpenIDの話をした。OpenIDはなんで流行らないか。特にRP側(*)で流行らない理由がわからないというので、一応、RPを導入する可能性のある立場でもある私の気持ちを率直に伝えた。一番の理由は、必要性を感じていないということだ。がんばって導入したところで効果が今の段階ではよく見えない。あえて挙げるとすれば、ユーザビリティの向上が図れた結果、以下のような効果があることぐらい。

　１） 既存OpenID会員など多くのお客様を呼びこめる。
　２） 機会損失を小さくできるのでリピータを増やせる 。

ちょっと買ってみようと思った「一元さん」は、会員登録とかいろいろ面倒だからすぐに逃げてしまう。たしかに簡単に買える仕組みは必要だろう。でもよく考えてみたら、ECサイトではお客様に商品をお届けしなきゃいけないわけで、最低限、名前と住所などの個人情報の登録は必須となる。（補足すると、OpenIDでできるのは本人確認のみ。例えば、takezakiというIDでログインしていれば、確かにtakezakiだということを確認できるが、それ以上のことはない。本名もわからなければ住所も分からない。また認可は別の仕組みが必要となる）
　こう考えるとなおさらOpenIDの導入は余計なことのように思えてくる。そもそも、OP(*)がRPに個人情報を渡すとは思えないので、RP自身で個人情報を集めなければならない。ユーザビリティの向上は何もOpenID使わなくてもできるし、機会損失だって本当のところどうだかわからない。結局、キラーアプリケーションでも出てこない限り、OpenIDはあまり流行らないんじゃないかなあ、なんてことを懇談会では話した。

　ちょっと宣伝になるが、ここでは、「一元さん」のためにメールアドレスだけで買えるような工夫をしている。お届け先はメールに飛んできたリンクをクリックして登録すればよい。最低限必要な本人確認および、お届け先入力をこのように実現することで、ユーザビリティ向上を図っている。また、メール注文サービスというのもやっていて、k@g.edionjpにカタログの番号をメールするだけで商品が買えるようにもなっている。原理は一元さん購入と同じだ。

　でも今、いいアイデアを思いついた。ポイントをOPで管理するというのはどうだろう。

１）OPでポイントを管理する（RPで購入するとOPのポイントが増える）
２）すべてのRPでポイントを使用できる

ポイントはお金と同じように扱われるから、ECだけじゃなく、いろいろ利用するケースはあるかも。SuicaとかEdyとかに変換できると嬉しい。使えるところが増えれば増えるほどポイントの価値は高くなるので、それであれば自社ポイントはやめてでも導入したい。
それから、すべてのRPの商品情報がOPで検索できるといいなあ。

(*) OPとは. OpenID Providerの事。
RPとは. Relying Partyの事。(要はリクエスタ)

【雑記】 CAPTCHAの話

CAPTCHA絵画　＜＝これ、CAPTCHAが芸術になるなんて面白い話だ。

CAPTCHAは文字などを人間しか認識できないような絵にする。これを逆に機械が読み取って文字にするのはとても難しいという。完全に破るプログラムは人工知能の一つといえるかもしれない。人口知能の定義はたしか「端末越しにやりとりしたときに人か機械か見分けがつかないもの」だったと思う。

面白い話をもうひとつ。アダルトサイトに仕掛けて多くの人にログインを促して裏ではCHAPHA破りに使うという技術がある。破られる側からしたら、あたかも人工知能を使われてるように見えるだろう。これを「エログリッドコンピューティング」というらしい。その命名が笑える。

[ロ]CAPTCHA と「エログリッドコンピューティング」