UEIは未踏研究を専門に行う学生プログラマーを募集します
今年のUEIの目標は、15個の新規のネットサービスを考案し、海外進出の橋頭堡を築く事です。
既に、英語の翻訳(和訳・英訳)を専門に行う学生チームを結成し、海外の最新技術情報を定期的に日本語に翻訳して社内で共有したり、社内の研究成果を海外に発表するための論文作りやその他広報活動を行って行く予定です。
さらに、新サービスの研究開発を専門に行う学生プログラマを募集することにしました。
今回の募集はアルバイトです。
これは、社会人だとどうしても責任ある仕事を任せなければならないのと、未踏分野の新規研究に専従するにはそれなりに幅広い知識や発想が必要なのですが、普段会社にこもっていると、どうしてもそういうものに縁遠くなってしまうからです。
そこで大学生のアルバイトを雇い、新分野の研究に専従してもらおうと思います。
仕事内容はクライアントの依頼を受けて何かをするのではなく、基本的には自分で研究テーマを見つけて、研究開発をやっていただきます。
そのために必要な環境、ハードウェア、学習のための資料などを用意し、新サービスを魅力的なものに仕上げるためのデザインや素材づくりは全てサポートします。必要に応じて学会などへの参加費や、渡航費なども会社から支給します。
その他の細かい条件は以下の通りです。
応募資格: 都内近郊の大学生、大学院生または専門学校生
勤務地 : 東京都文京区本郷 (最寄り駅・丸ノ内線本郷三丁目 / 都営浅草線本郷三丁目)
勤務時間: 自由。目安として週4〜8時間程度。10:00〜22:00の間のいずれか。
使用言語: 自由
報酬 : 時給1500〜2500円(能力・実績に応じて変動) / 勤務日数が多い場合は月給制
開発した研究成果が利益を産んだ場合、それに応じたインセンティブを支給
応募方法: 住所・氏名・生年月日・電話番号・ブログがある場合はURL・所属大学名
それと興味のある研究分野とそれまで自分が書いたプログラム(課題等は除く)
のサンプルを添付して、info@uei.co.jpまでメールしてください。
募集期間: 2008年1月31日から2008年2月14日まで
募集人数: 若干名
どんな研究を主にしているかというと、たとえば携帯向けフルブラウザのサイトスニーカーや、立体3DブラウザのSiteSneaker2007のような、すぐにはお金にならないけどインパクトのある研究のほか、感情検索エンジンfeelfind.netや勝手にブログ評論、それにあきば電脳ライフ、そして電脳ホワイトボードのように、流行りものの技術とその組み合わせを試すようなものなどいろいろです。
UEIには電脳空間カウボーイズのメンバーを始め、様々な業界のエキスパートや大家が出入りしており、特に布留川英一くんのように沢山の本を書いている人や、水野拓宏くんや僕のようにIPAの未踏ソフト創造事業で天才プログラマーの認定をもらった人など、刺激的な人が沢山集まっています。
ぜひ熱意のある方の応募をお待ちしております。
チームラボ猪子さん、サルガッソー鈴木健さん、オプト海老根さん新年会
昨夜はメチャクチャ面白い新年会でした。
久しぶりに二日酔いで頭痛するくらい。
場所は浅草橋にある河田邸というリノベーション物件。
屋根が腐り落ちている一軒家をまるごとリフォームしてお洒落な設計事務所に。
と称して毎週の週末にリフォーム。ここまでくるのに二年かかったそうです。
ここに集まったのが、チームラボ
の猪子さんとサルガッソー
の鈴木健さん、そしてオプト
の海老根さんと僕という不思議メンバー。
殆どゲリラの集会みたいな危険な空気がムンムンしてました。
猪子さんたちが発明した「めもデスク」は凄く魅力的な商品
机の天板が丸ごとメモなんです。
次世代コラボレーティブコンピューティングの原点はこれだ!と思いましたね。まさに慧眼。よくこんなの作れるなあ、と思いました。
発想も凄いけど、実際につくっちゃうことも凄い。
家一軒まるごとつくったり、机をつくったり。イノベーティブ過ぎる。
あと、茶室。
これみてもなんだかわからないと思いますが、ゴムの壁でできた茶室なんです。
人呼んでやわらか茶室
中はこんな感じらしい。
このメイドさんは一体なんなのか不明です。
得体が知れないけど格好良過ぎる。
チームラボ凄いなと改めて感心することしきりでした。
なぜ茶室なのか?
この二畳の中になにがあるのか
で、ゴムの壁はなぜ必要なのか
全てに意味がいり、全てが理にかなっているんです。
ゴムの壁はそれをつきやぶって中に入るときに感じるイニシエーションのための演出。
わずか二畳のスペースは、必然的に互いのパーソナルスペース(テリトリー)を侵し、そのことによって心理的な距離が急速に接近します。
猪子さん曰く、「取材に来たはずの人が茶室に入ると、逆に自分の話を、プライベートな話をして返って行く」のだそうです。
「茶室を広めたのは織田信長だ。そうして織田信長は広範囲な情報を得ていた」
と、猪子さんは語ります。
日を言うと僕もオフィスに茶室が欲しいと思っていたところで、これはなかなかいいな、と思ったのでした。
この話って凄く共通性があって、むしろ取材に来た人に逆に自分の話を語らせた方がいい。
なぜかっていうと、人間は自分の話が大好きだからです。
一期一会という言葉がありますが、まさにそのときしかその人に会わないからこそ、通り一遍の
表面的な話ではなく、腹を割った話をしてもらいたい。そうやって情報を得る訳です。
そして、取材に来た人はみんな「こんなに楽しい取材はなかった」と満足して帰って行くのだそうです。
それも凄く重要な話で、要するに自分の話をたくさん聞いてもらえて楽しかった、ということです。
話を聞きに来たはずの人に話をさせて、それで満足させて帰す。まさに現代の千利休のような発想。これこそが真の「おもてなし」です。
この茶室、チームラボさんが売ってるらしいので買おうかと思ったんですが、それもなんとなく悔しいので自分でも会社に茶室をつくってみようかと思います。
そんなことできるかな?
他にもいろんなアートの話やミラノの話、組織の話やコンピュータの話などなど、とても散漫な話をして盛り上がりました。
とりあえず、猪子さんが新しく作る空間デザインのイベントが4月にミラノであるらしいので、僕も行く事にしました。ミラノのホテルが7倍の値段になるそうです。
スクリプト言語の美学
404 Blog Not Found:「PHPなめんな」と「(Perl|Python|Ruby)をなめんな」の違いとか、Matzにっき Attacking PHPとかを見て
「そういえば最近、"結局PHPばかり使っている"という理由でJavaを使うのをやめる方向にしたなあ」
ということを思ったのでメモ。
PHPに関するご批判については全くお二方のご指摘の通りで、ぐうの根も出ません。
まあ一言でいえばPHPはアヤシイ言語です。
他のいろいろな言語と違ってPHPだけはZendという会社が一手に実装している感じがあり、コミュニティが作っているというよりも会社が作っているように見えて、オープンソースなのにイマイチ"参加者がつくっている"感じがしない言語としてもちょっと毛色が違うのかな、と思います。
それでも最終的に僕が商売人としてPHPを選択してしまう理由。
1)最初からインストールされていることが多い
2)教育環境が揃っている
3)他の全ての言語と異なり、Webアプリケーションの記述を主目的として作られた言語である
たとえばPerlで構築した方が都合のいい環境、というのもあるのですが、Perlはやはりもっと汎用的な言語なので、Webアプリケーションを書くときにいくつかのお約束を満たさなければなりません。
Rubyはもう少し複雑です。Railsを使えば良い、という話もあるのですが、Railsのお約束を学ばないといけません。
でもたいていのWebアプリケーションって、そんなに複雑なことはさせないのです。
個別のアプリは単純化されていて、全体として複雑になることはあるかもしれませんが、それでもかつてオブジェクト指向がないと絶対に無理、と言われていたようなことというのは、あまりなく、過去の資産の継承というやつも、同じデータベース構造を使うとか、RESTfulなAPIを実装して粗結合するシステムを作るなどしてたいていのことは解決できてしまうのです。
また、PHPで書かれたソースを見せられて、それを誰かが読み解くのはとても簡単なのですが、JavaやRubyのコード、とりわけ複雑なフレームワークで作られたソースを見て、それが何をしているのか読み解くには言語そのものの知識だけでなくフレームワークの知識も必要になり、何倍も時間が掛かります。そもそもJavaはパッケージによってクラス名が被っていたりとか、名前が死ぬほど長かったりして恐怖感すら感じます。
InputStream is = new BufferedInputStream(new FileInputStream("foo"));
を見てですよ、なぜInputStream = new FileInputStream("foo")ではだめなのか、なぜBufferedInputStreamを介す必要があるのか、理解するだけで数分は浪費します。
こんなの
$fp = fopen("foo");
と書けるPHPの方がラクに決まっています。
HTTP上のリソースにアクセスするために
URL url = new URL("http://www.debian.org/");
HttpURLConnection urlconn = (HttpURLConnection)url.openConnection();
urlconn.connect();
BufferedReader reader =new BufferedReader(new InputStreamReader(urlconn.getInputStream()));
while (true){
String line = reader.readLine();
if(line==null)break;
System.out.println(line);
}
reader.close();
urlconn.disconnect();
と暗号めいたことをやるJava(上記の例はこちら参照)に対し、
$fp = fopen("http://www.debian.org/");
while(!feof($fp)){
echo fgets($fp);
}
fclose($fp);
で済んでしまうPHPはC言語育ちの目から見て実に馴染みやすいわけです。
Rubyだったら格好良く
require 'open-uri'
open("http://www.ruby-lang.org/") {|f|
f.each_line {|line| p line}
}
などと書けるのですが、open{|f|}とか、f.each_line{|line| p line}とかを見て、Rubyを普段使ってない人が理解するまで相当の時間を要します。
QWERTY配列に対するドヴォラック配列というか親指シフトっぽい感じで、効率的なんだけど不気味な感じが否めません。慣れると戻りたくないくらい気持ちいいんですけどね。それは本当に悩みどころです。
でも僕しか使えないとすると、そもそも言語として業務で使えないし、まだ業務でRubyを使うのは、実利というよりも技術者の趣味という感じがするのですよ。とかいうと無数に反論を頂きそうですが。
B2C向けサイト作成がメインのうちの業務で本当にお客様にRubyで作ったシステムを納入して、場合にも依りますがあらゆるオーバーヘッドを差し置いても大丈夫だ、といえる可能性は結構低い気がします。
たとえば「年内に10万人から100万人規模のサービスをやるからシステム規模を出してくれ。けど予算はこれしかない」と言われて、「わかりましたRuby on Railsでやりましょう」とはなかなか言える勇気はありません。よく、「RoRが遅いならサーバを増やした方がいい」と言われるのですが、サーバが増えると純粋に土地代がかかるので、それを補って余りあるメリットって本当にあるの?と言われるとやっぱり「いやあどうなんでしょう」と答えるしかない。Perlとかは「mixiも使ってます」とか、Pythonとかは「googleも使ってます」で逃げることもできますが、Rubyは「twitterも使ってます」「けっこう落ちてるじゃない」と言われてしまう(実話)。
そのうえ、PythonとかRubyとかややマイナーな言語で書くという話をすると、将来的にうちではない別の会社に改良や引き継ぎをしてもらう可能性を考慮すると出来るだけ沢山のベンダーが使える言語で書かれたモノの方が保守コストも安いわけで、PHPで記述するということはそれだけメリットがあるのです。
そういうときに「Rubyじゃないほうがいいんじゃないの?」と言われてもぐうの音も出ないので、JavaやPHPを使うと。まさに事なかれ主義。でもそれが零細企業の現実です。
さらに言えば、PHPの各ファイル(スクリプト)同士はデータベースを介在するか、もしくはRESTfulなやり方で粗結合するとか、とにかく外部的なインターフェースをPHPに依存せずに作るので、極めてどうでもいい処理はPHPで記述して、よほど複雑だったり、よほど違うことをしたりしたい場合に他の言語(たとえばJava)で記述する、といったことが今は簡単なので、PHPで小さいスクリプトを沢山書いた方が、実はかゆいところに手が届いていくのです。
C++がどんなに醜いアヒルの子と言われようと、上品で血統書付きのObjective-Cよりも世間に受け入れられたように、PHPがどんなにマヌケな言語だろうと、受け入れられてしまっているのだと思いますね。結局K&R的というか、見た目のエレガンスさよりもコモンセンスを受け継いでいることが需要、というか。
少なくとも僕みたいに業務でコードを書いてない人間にとってはPHPはちょっとかじったRubyやPerlよりも何倍も便利で使いやすく、結局メインで使っていたC++やJavaよりも手に馴染んでしまいました。
去年趣味で書いたコードは凄く沢山ありますが、殆どがPHPとJavascriptの組み合わせだけです。それぞれのコードは100〜500行前後で、凄く大袈裟な奴でも1000行くらい。
それだけ短いと開発時間は数十分から数時間。
たとえば勝手にブログ評論の最初のバージョンは30分で作って、それをローカルからサーバに転送するのもアップロード一発なわけですが、RubyやらJavaやらだとわりとどんな設定で動かすか考えたりするのがそもそも面倒で、テスト環境から公開環境へのデプロイそのものがなんだか凄く「仕事」然としてしまいます。
後先考えずにノリとスピード感でへんてこなものをバンバンつくれるPHPは、やっぱり楽しい。
PHPの、目を疑いたくなるというか、耐えがたい仕様というのも確かに無数にあるのですが、Webアプリケーションって実は言語そのものよりもデータ構造による制約を受けていることの方が圧倒的に多くて、言語が変わることよりもDBMSが変わることの方が意味が大きかったりします(だからPHPのDB関係の関数の実装は耐えがたいもののひとつではあるのですが)。
PHPってC--かな。デタラメでテキトーなところが。
汚いしテキトーだけど、たいていの欲しい機能は最初から揃っている、というのがPHPの最大の利点かもしれません。
RubyもPerlも、そもそももともとWebアプリケーションのため「だけ」の言語ではないから、ライブラリやフレームワークを必要とする時点でちょっと面倒になってしまいます。
PHPと(Perl|Python|Ruby)の違いは、その主目的ということに尽きるでしょう。
PHPの方がレイヤーが一段上というか、古来からの意味でより"高級"なのです。これを同列に比較してしまうと、そもそも実は違うのではないでしょうか。敢えて比較するとすればPHP vs eRuby、とかでしょうかね。この場合、eRubyの弱点は最初からインストールされていないことくらいです。
「初心者にはとっつきやすいがそのまま上達してもろくなコードが書けない」
という点は、すごくかつてのBASICに似ています。
本来スクリプトって、ラクをするための疑似プログラム言語だったハズなので、ラクであるに超したことはないのです。
脆弱性の問題とかは、プロトタイプを渡されて製品を実装する人が考えるべきことですが、まあそれはJavaで書いていても脆弱なコードはポンポン生まれますからね。しかも時代が進むにつれて攻撃方法や気をつけるべきことも進化してくるので、これはもはや技量の問題ではないかと思います。少なくとも脆弱である原因を言語処理系や言語体系に依ってはいかんのではないかと。
僕みたいなジジイは、連想配列とforeachと正規表現とHTTPストリームが当たり前のように使えるというだけで、あとはJavaやC++の悪いところも含めてマネできます、という言語のほうがやっぱり取っつきやすいし、小回りがきくような気がするのです。
だからPHPをプログラム言語と見なすのはむしろ間違いで、HTML生成スクリプトくらいに思った方が良いのではないでしょうか。
RubyやPerlみたいな高尚な言語と比較するのはちょっと違うのではないかなあ。
PHP,JSP,eRuby vs Java,Ruby,Perl,Python
というのが正しい比較ではないかと。
人間はチューリングマシンに向かっている
Podcast、電脳空間カウボーイズ
の年末特番でホーテンス遠藤こと月刊アスキー編集主幹の遠藤諭さん
がこう仰っていました。
「結局、人類はチューリングマシンとなる方向に行っているよね」
チューリングマシンとはコンピュータの最も根本的な基本原理のこと(wikipedia参照)
なんでまた、と思ってよく聞いてみると、こう続きました。
「だっていまの人間って自分で覚えないでしょう。なんでもネットで検索する。それこそWikipediaとか。そしたら、チューリングマシンと変わらないよね」
つまりWebという巨大なテープの上で、検索キーワードやハイパーリンクといったものを手がかりに計算(思考)を行うチューリングマシンになっているというのです。
脳だけがいろいろなことを記憶していた時代から、Web全体でひとつのテープを共有し、人間の脳細胞には到底収まりきらない、そして一人の人間が一生掛けても決して記憶することのできない膨大な情報量がWebにはあり、知識が共有化され、そして思考が構成されます。
ここで少しだけ心配になるのは、知識や記憶が完全にWebによって同一化してしまったとき、人の思考が均一的になってしまうのではないかということですが、個々のチューリングマシン(人間)はそれぞれ異なる外的体験(ネット以外の社会生活)を送ったり、ネット体験であっても、それぞれが主観的な体験を行う事によって各マシン(人間)の体験に相違が生じ、仮に全く同一の構造(チューリングマシンで言えば状態遷移表)を持つチューリングマシンであったとしても、それぞれが個性を持つ事に成ります。
複雑系の研究でよく使われるマルチエージェントシステムを考えても、それぞれのエージェントは全て同一のごく単純な状態遷移によって動きますが、全体としての動きは複雑怪奇で容易に予想する事が出来なくなります。
人間は考える機械である、という説がなんとなく頭に浮かんできます。
考える機械である人間に浮かぶ感情や心と行ったものは、主観的体験の蓄積による一種の「状態」であることが考えられます。
逆に言えば、人間に感情があるとすれば機械にも感情がある、と考える事も出来ます。
さらに、Webで体験を共有する(たとえばブログやTwitterなどでお互いの思考を交換する)ことで、それぞれの見解を別の角度から見た新しい見解をお互いに提示する事が出来ます。
これはまた、人が単体で生きていては到底得られない重要な相互作用です。
「デジタルディバイド」とは、まさにこの知識・体験の共有が破壊的なほどの格差をもたらすという現象を一言で表現したものかもしれません。
これからは人間=チューリングマシン説に基づいて、それを加速するようなサービスという視点で、SNSやブログなどをとらえていくと面白いかもしれません。
ブログは主観的体験を無制限に交換するメディアで、SNSは限定的に公開するメディアだとすると、SNSの1ホップの友達だけから構成される、別のチューリングマシンを仮想できます。つまりひとつのコミュニティごとに人格があるという考え方です。
そのコミュニティではある知識が共有されていて、その知識が共有されるからこそ、コミュニティ全体を通して共有されるひとつの見解が発生し、それが相互に複雑に絡み合いながら渦のように世界の知識体系を織りなしていると。
もちろんこうしたコミュニティによる仮想チューリングマシンは会社組織、学校、家族、友人、恋人という関係で多層的に存在し、このことがより人間社会を複雑に見せているという考え方もできます。
遠藤さんの「人間=チューリングマシン」論で最も面白いと思ったのは、チューリングがもともと想定していたチューリングマシンはひとつのテープにひとつの機械という前提があったはずですが、それがWebによって共有化されることで、同時並行的にひとつのテープを複数のチューリングマシンが共有するというイメージです。
そして以上のようなことを考えていたら、僕の頭の中には、こんなイメージが浮かびました。
複数のチューリングマシンが記憶や知識をいくつか共有化させながら、しかも多層的な仮想チューリングマシンを(コミュニティといった形で)構成しているわけです。実際には二次元の図では表現できなくて、コミュニティごとに空間的な階層を持っているはずです。
ソーシャルグラフに注目が集まったのは、人間本来が持っているこういう性質を暗示しているからでしょうか。
チューリングマシンはあらゆるチューリングマシンの動作を記述できる万能チューリングマシンというものが発見されて、それが本当の意味で現在のコンピュータの基礎になります。いまのコンピュータはあらゆる計算ができますよね?
でも「人間=チューリングマシン」論における「万能チューリングマシン」とはどんな存在なのでしょう。
あなたがブログ、評論させます
勝手にブログ評論に新機能「おこのみブログ評論」を追加。
これは、ブログ評論テンプレートを編集可能にし、誰でもオリジナルの「勝手にブログ評論」が作れるという新(珍?)サービスです。
たとえば、「である」「だ」を「ざます」に置換するだけで、上記のようにとってもオマヌケな文体に変わります(パーマリンク)。
テンプレートをつくると、パーマリンクにテンプレートが保存されるため、URLを変えて評論することでマヌケなブログ評論を量産できます。
もちろん全くゼロから新しいものを作ってもOK
僕の文章力ではこういう2chネラーっぽい文体は再現できませんでした。
%sのところに適当な名詞が入ります。
リターンで区切られます。
遊んでみてください。
勝手に微調整
やっぱ関連ブログのキーワードを拾ってくると、もとのブログの単語が薄まってしまって全く意味不明になるので、やめてみました。
なんか知らない人の名前が一杯でてくるな、と思ったら、アマゾンの著者の名前もバンバン入れていたのでした。これも消してみた。
関連ページがいつまでもいつまでも沢山でるので、最大五個に絞りました。
やっぱりこうでなくては
非言語型プログラミング言語
非言語型プログラミング、とでもいうべきものになにか可能性はないだろうかと一年以上考えています。
非言語型プログラミングとは、言語的ではないプログラミングです。そのまんまか、というか意味が分からない。
このあたりの話はスノウクラッシュ的な話でもあるのですが、SF小説にもなかなか出てこないのがプログラミングの話題。
- 作者: ニール スティーヴンスン
- 出版社/メーカー: 早川書房
- 発売日: 2001/04
- メディア: 文庫
きっと小説家がプログラムを書く事が少ないのでしょうが、それでもルーディ・ラッカーみたいな数学者兼プログラマ兼小説家みたいな人もいるので、作者が解らないというよりは読者がわからないからないのかもしれません。
- 作者: ルーディ ラッカー
- 出版社/メーカー: 早川書房
- 発売日: 1998/10
- メディア: 文庫
僕が映画、マトリックスで最も驚いたのは、パンフレットにあった「オーストラリアのデザイナーが"日本人のプログラマは縦書きでコードを書くに違いない"という思い込みから、マトリックスは縦書きでカタカナ混じりの文字がキーデザインとして多用されることになった」という下りで、まずそんな発想がネイティブ縦書き文化人間には全くなかった訳で。そもそも最近、縦書きの文章ってあまり読んでない。
森鴎外や福沢諭吉が欧米に遅れをとるまいと、日本のローマ字教育と横書き文化を普及させたおかげで、コンピュータもなんとなく使えているわけですが、エジケンのLingrなんか、最近イランで大流行中らしく、もう読めやしない言語。しかも右から書くタイプの言語でチャットされているわけです。日本人がシリコンバレーに行って、アメリカ人にコードを書かせてイランで大流行。ワールドワイド過ぎる。
そうなると、プログラム言語って凄くて、phpもC++も世界共通なわけですよ。
みんな左から書くし。
ほんと、こればっかりは明治の頃の人たちに感謝しなくてはなりません。
横書きって凄い。
いつの間にか読み方の左右も入れ替わっていて、益々良い感じです。
ところがやっぱり当たり前ですけど、プログラミング言語はプログラマのためのものなわけです。
プログラマ以外は使えない。
けれども、例えば足し算をしたいとか、なにかの平均を出したいとかというときに、プログラムを書く人はいまはあまり居ません。
エクセルを使う人も居ます。エクセルの=SUM(A1:A10)とかももう立派な非言語プログラミング環境だと思う訳です。
プログラムとそうでないものの境目が、特に最近、僕の中で非常に曖昧になってきています。
僕が若い頃は、C言語のような、「自己記述可能」な言語、それこそOSとか作れる勢いのやつが本当のプログラミング言語で、SEDやAWKなんかはCPUの動きとかけ離れた内容を書くので「プログラム言語とは呼べない」と思っていました。そのために「スクリプト言語」という言葉があるわけで。
しかしここ数年、たとえばJavaScriptだとか、ActionScriptだとか(まあこの二つはどちらも同じECMAScriptですが)、PHPだとかPerlだとかRubyだとかいった、いわゆる軽量言語が主流になってきています。
僕にしてみれば驚くべき変化。もう激変といっても差し支えない変化で、「こんなOSも記述できないような言語でなにをするというのだ」と思っていたのですが、実際にWebアプリケーション主体の受注開発ばかりやってみると、「そもそもOSが記述できる必要がどこにあるのだ」という考えにいつのまにか変わっていました。
PHPもPerlもRubyも、僕が昔書いていたようなポリゴンをリアルタイムでゴリゴリ動かすようなプログラムを書くのには全く不適切ですが、Webアプリケーションみたいなものを書くにはこれ以上便利なものはないのではないかというくらいに便利です。
僕のなかにあった、頑な「プログラム言語とスクリプト言語の境界線」が緩やかに崩壊したとき、「そもそもプログラミングってもっと幅広いものなのではないだろうか」と考えるようになりました。
コンピュータを使う事そのものが、殆どプログラムなのではないか。
そこで、プログラムという行為を僕の中で再定義することにして、たとえばこう考える事にしました。
◇プログラムとは、コンピュータに指示して特定の作業を自動化することである。
こうすると、たとえばエクセルの表も、Googleの検索クエリーも、プログラムなのだと言う事が出来ます。
Googleの検索クエリーって、もう誰でもつかるんですけど、そもそも誰でも使えるということ自体が、凄い。
そのうえ、それでもなおgoogleで目的の情報にたどり着くにはテクニックが必要です。
「とは検索」とか、「ダブルクオーテーション付き検索」とかは必須テクニックですが、Googleは他にもいくつかいろいろな検索オプションがあって、使いこなすともっと便利なことがあるのかもしれません。
「なにを検索するか」ということは案外重要なことなのですが、実は特定の単語を検索するとき、知りたいことは限られています。
例えば「布留川英一」を検索するとき、彼の著作を知りたいのか、彼のWebページを知りたいのか、彼の人となりを知りたいのか、彼に言及しているものを知りたいのか、というように目的によって本当に必要なページは変わります。
Googleのような一元的なランキングでは、それをうまく伝える事は非常に難しいわけです。
たとえば「布留川英一 本」と検索するのがいいのか、「布留川英一 著」と検索するのがいいのか、ということです。
さらにいえば、本を買いたいのか、その本の評判を知りたいのかといったことによってもまた順位が変わります。
僕はコンサルタントなので、自分の関わったプロジェクトやサービスが世間にどう認知されているか、ということを随時追跡しています。
僕にとっては例えばうちの社員である布留川英一の新刊の評判を検索したりしたいというのは良くやる事です。
こういうときに役立つのはtechnoratiのようなブログ検索ですが、ブログ検索だと最近つとにスパムブログが目立つようになってきました。
スパムブログとそうでないブログを見分けるのはかなり高度な人工知能がないと難しく、今後改良していかなければならないところだと思います。
また、ブログ検索でブログを見つけても、それが良い印象なのか悪い印象なのか即座に調べるのは難しいのです。
そういう事態に対応するために、試しに海外サーバに作ったのがfeelfind.net。
これはtwitterやjaiku、はてなハイクなどのミニブログを検索してほぼリアルタイムになにかの感想や評判を引き出す事が出来ます。いまはサーバを移転したばかりなのでデータが殆どクロールされていませんが、毎日10万以上の書き込みを記録しているので、思わぬ発見があります。
たとえばmacbookについての反応を知りたかったらこんな結果になります。
実は、どういうやり方で検索キーワードを選ぶと目的とする情報にたどり着くか、ということはかなり高度なノウハウになります。
しかし、例えばそういうノウハウは、僕らのような本職の技術者よりもむしろ実践で鍛えられたOLさん達の方が詳しかったりするのです。
たとえば典型的なWebプログラマはエクセルのマクロを殆ど知らないのではないかと思います。
そういう人があるとき、ピボットテーブルという機能があるということを知り、驚愕したりするのです。
ちょっと詳しいOLの人たちはアクセスやファイルメーカーを縦横無尽に使いこなします。
クエリーの書き方なんか、僕らより上手いんじゃないかと思う事があります。
例えば、何年か前、ある大きなイベントで投票集計の仕事を請け負った事があるのですが、なんと表彰式直前にプログラマのミスで間違った統計結果を表示していたことが解りました。
その投票集計は、グランプリの決定に必要な情報であるため、これがデタラメだと大変困ります。
とはいえあと30分しかない、ということになりました。
いまから投票集計をしなおすプログラムを書いて、その妥当性を検証するとすると、かなり厳しいのではないかと思いました。
かろうじて生データを別に保存しておいたので、集計し直す事は論理的には出来るのですが、なにしろ時間がありません。新たに集計プログラムを作っても、そのプログラム自体がバグってないかどうか、誰にも確認できません。会社にはその新人一人だけ。
当時は僕含めて数人しか居ない会社だったので、クライアントも、「適当でいいよ」という依頼だったのですが、そりゃいくらなんでも適当すぎる。
とはいえ僕はクルマで移動中で、当時はEモバイルなんかなかったですから、船橋あたりで渋滞に捕まっている状態ではとてもコードなんか書けない。電話の向こうの新人プログラマは半泣き。
その時に、総務の女性が横から出てきて「なあんだ、そんなの簡単よ」と、ホイホイっとアクセスに生データを読み込ませてものの数分で再集計を済ませたのです。「そんなことってあるのか」と思った訳です。
そのときは「神業だ」と思った訳ですが、今の定義で改めて考えると、それは彼女がプログラムをしていたということに他ならない訳で、彼女の使っている言語がたまたま「アクセス」だったということなのだろうな、というわけです。
で、アクセスですけど、これのクエリー画面とか、本当に非言語型プログラミングの最たるもので、なにしろデータベースのフィールドを画面上でつないだりして作る訳ですよ。
こういうのを昔「ビジュアルプログラミング」と呼んだりして、そういえば小野さんとかエジケンとかはもともとそういう商品を作って売る人だったわけですが、データスパイダーって凄いナイスネーミングだな。と今更ながらに思う訳です。
データスパイダーとかアステリアとかの画面って、本当にプログラムみたいになっていて、なにかの出力をなにかの入力に繋ぐとデータフローが出来てプログラムができるんですけど、これって言語に依存しないわけです。QuartzComposerもそうですね。
そういう、言語に依存しないけど便利、みたいなものの知識って凄く重要で、たとえば最近はYahoo pipesとかはまさにそうですが、知識というよりも知恵かな。データの集め方と集計の仕方の知恵。
ただ問題は、パイプつなぎ型のプログラムだと、結局プログラマに近いロジックの人しかプログラムできないということです。
あと、意外と面倒。
簡単なようで面倒なんですよね。
QuartzComposerでプログラム書こうとすると解りますけど、まず部品探すところで迷子になります。
さらに、どの部品をどのように繋ぐと何が出来るのか、全く予想できない。
電子ブロックみたいなものですね。
結局マニュアル通りに繋ぐしかない、みたいな。
マニュアル通りにつないだあとのバリエーションで多様性が出にくいというのも問題です。
シンセサイザーとかもまさにそうなんですけど、この手の奴って何でも出来そうで何も出来ないのが多いんですよ。
QuartzComposerはけっこういろいろ出来る方ですが、実際のところ「これは何に使うんだ」というものが多いですし、部品も「これが欲しい」というのが無かったりするので、結局RSSを読んでくるスクリーンセーバー作って終わり、みたいなことになりがち。
ある意味で、Dashcodeはプログラマ寄りでしたけど、LeopardのWebclipは本当に凄い。だってページを切りとるだけだもん。それでもけっこう便利に使える訳です。これがまさに非言語的ということかな。
で、非言語的なのにプログラミング"言語"と付けたのは、たとえばExcelにしろアクセスにしろ、Webclipにしろ、言語というよりも環境なんですよね。
言語というのは交換可能なものだから、要するに、そこから横に広がっていくような方向性が欲しいわけです。
まあたとえばブログで「おれのWebclip術」みたいなのを公開すると間接的にノウハウを交換できますが、なんていうか、それがちゃんとモジュールとして機能してどこかをクリックすると自分のdashboardにインストールされるとか、そのくらいの交換性は欲しい。
yahoo pipesなんかがまさしく見事なのはそういうところですね。
じゃあ結局yahoo pipesなんじゃん、と言われてしまうとそれまでですが、もうひとつの問題はyahoo pipesがパイプ式であるということです。
データフローを表現するには確かにパイプ式は便利。
しかし、データフローでものごとを考えることができるのはかなりコンピュータを解っている人です。
電子回路に逆戻りした感じがするんですよね。パイプって。言語の良さがない。
言語って一次元のものじゃないですか。
見え方は二次元であっても。
だからC言語のようにセミコロンでつなぐととにかく一行になるっていうのは解りやすいんです。
一次元であることは極めて重要で、頭から読んでいくと必ず処理の全貌を追う事が出来ます。それがもう保証されている。
パイプ型は近いものはあるんですけど、そもそもデータフローを中心に考えると、興味対象というか、データの発生源がひとつしかないことはまずなくて、複数のスタート地点があり、しかも途中で複数のプロセスに分岐するんです。そうするとどこがどうなっているのやら解んなく夏てしまう。
むかし、中嶋謙互さんが「並列プログラミングを理解するには通常のプログラミングとは異なるセンスが必要」と言っていたけど、まさにこれは並列プログラミング的な感じ。
関数型言語のコードを読むのが非常に疲れるのと一緒で、処理の流れを一次元で追えないのはいいところであり、わるいところでもあるのかもしれません。
その意味ではgoogleの検索クエリーは素晴らしい。短いし、一次元的です。
でもこの世界ってまだまだ発展する可能性があると思うんですよね。
非言語型プログラミング言語、または環境って、要するにコンピュータと人間との究極のインターフェースになっていくわけですから、ユーザーエクスペリエンスとサービスデザインのコンサルタントとしては、日々考えていかなければならないテーマなのです。
勝手にブログ評論がα版へと無意味にバージョンアップ
勝手にブログ評論はブログの評論を文字通り勝手に行うサービスですが、皆様に愛されて三日で2万評論以上。
調子に乗ってα版へと無意味にバージョンアップしました。
正確に言うと、さっき作ったバージョンをα版と呼ぶ事にしました。
バージョンアップというからには、それなりの新機能があるわけですが、
実は昨日、一昨日も細かくバージョンアップしていて、たとえば最後に文章と関連したamazonの本が一冊だけ紹介されるという機能もそのひとつ。
意外な本を紹介されたりしてけっこう笑えます。
さらに、今回からは分解した名詞(と思われるもの、特徴語)を抽出してデータベースに放り込み、このデータベースから比較して、特徴語を共有する他のブログを探し出し、「似たようなブログ」として末尾で紹介するほか、その似たようなブログからも語を抽出して評論に加えます。
これで、そのブログの単語+似たようなブログの単語によるミックスされた評論が読めるので、もっと新しい驚きや発見があるかもしれません。
このサービス、いま、さらに無意味にバージョンアップしようとしています。
もともとはストップワード認識を効率的にするためのデバッグのために作られたものでしたが、意外に他の実験への応用も効きそうなので、しばらくUEI特殊開発チームの玩具になりそうです。
サーバも増強することにしました。
「勝手にブログ評論」の原理を解説をしたUstreamビデオは↓こちら
勝手にブログ評論の解説を本日18:00からustreamします
さきほど会議の合間にログをみたら、8000評論を超えてました。
というわけで、もっと調子に乗っちゃおうかな。
今年はまだやっていなかったUEI大学で、勝手にブログ評論の原理を解説しようと思います。
御時間のある方はぜひ http://onosendai.jpへ
本日18:00から19:00の予定です。
「勝手にブログ評論」の種明かし
思いがけず多くの人に使ってもらえた「勝手にブログ評論」
昨晩からカウントを取り始めて、既に4000以上の「評論」をさせていただいたようです。
ということで、調子に乗って種明かし。
このスクリプトは、(1)ページ読み込み (2)RSS読み込み (3)ストップワード検索 (4)再構成という段階から成り立っています。
ページを読み込んで、そこからRSSへのリンクを抽出して、その後ストップワード(前項を参照のこと)を検索して名詞らしきものを取り出して、最後に再構成して文章にしているのですが、いくつか工夫したポイントがあります。
その1は、文章が繋がっているように見えるため、語尾の「、」と「。」を認識し、連続して同じテンプレートを選ばないようにすること。
その2は、いかにもスノッブな語り口。
スノッブとは、007シリーズで知られているような、俗物、知識をひけらかす見栄っ張りの気取り屋、ということです。
wikipediaによると、もともとはイギリスで使われていた隠語らしいのですが、こういう語り口で他人のブログを評論するのがいかにも「らしい」し、そもそももともとこういう語り口のブログは少ないので、いかにも他の人が書いてる「っぽい」というところから、このスノッブな語り口を選びました。
だからこの「勝手にブログ評論」では、偉いのは英国と女王陛下。お洒落といえばパリ、イタリアといえば田舎者、けど尊敬すべきはローマ人、アメリカはニューヨーク以外認めない。という、矛盾したスノビズムをもとにテンプレートを構成しています。
まあ実際、1800年代のイギリスにはこういうスノビスト達が沢山いたようです。
評論=俗物的という揶揄ではないのでそのあたり、誤解なきよう。
スノッブ感を出すために、実際の評論家の文章や、海外の言喭を参考にしたり、余興なのにだいぶエネルギーを使ってしまいました。
