Web2.0をめぐる動きも気になるが、そろそろ次のWebが明らかになってきた色んな現象。
眠いので適当に。
薄ぼんやりとそこに何か見えてはいないか。
なんだか希望がない。
当事者になるということ
http://d.hatena.ne.jp/hyoshiok/20051021#p1
今は希望はあるのか？
http://www.furukawaselect.com/mt/?p=5172
おそらく今後もIT投資はますます減るだろうし、納期もますます短くなるだろう。
PGの復権の続きっぽいが、思うことは２つ。
救いがあるのは、トップダウンだけでなく、ボトムアップアプローチの手段が「公に」ぼちぼちと語り始められていること。
３つのCということでこんなことを考えついてみた。
「コピペ志向、コンフィグ志向、コラボレート志向」
コピペ志向
２つ思うことがあって、一つは「優れた開発フレームワークはコピペで作業がさくさく進む」ということ。
ソースコードをコピーしていって、差分だけちょろちょろと直せばシステムが出来上がるといいますか。
「３行以上同じコードが出てきたら共通化せよ」なんて言葉もあったりして、まぁ眉をしかめられそうな部分も含んではいるのだけども、場合によっては構造が複雑化になるのを避ける為にあえて冗長なモジュール構成のまま残してみるよ、っていう考え方もあるじゃないですか。
そのような冗長化へのアプローチがとられた場合はやはりコピペで「あまり考えずに」作れるのがいいのではないかと。
また、コピペで作れるってことはソースコード生成を自動化することが可能な線も見えてきて、更なる作業効率が図れるかもしれませんしね。
で、もう１つは、ネットで検索すれば今は大概のサンプルコードが見つかるので、それをコピペして利用すれば開発効率上がるよね、って話。
考える力じゃなくて探す力でしょ、今時の開発で必要なのは。
コンフィグ志向
昔出合ったAさんという人は、自分でベタなプログラムを書くより先にその機能を実現する為のフレームワークっぽいところを先に作ってしまい、細かな部分はコンフィグ（設定）ファイルのカスタマイズで済ませてしまう、というアプローチをとっていた。
ユーザから仕様変更がきてもコンフィグの調整で吸収してしまうので、それはそれで一つの賢い方法だな、とは思う。
また、一方で今時の開発って（オープンソースを含めて）何らかのパッケージやフレームワークを利用することが殆どなのだが、わざわざ作りこまなくても設定で吸収できちゃうことって多いでしょう。
っていうか、パフォーマンスの問題とかになると、そのモジュールが稼動するAPサーバとかOSはたまたハードの調整をしようよ、って話になり、アルゴリズムへの知識よりかは設定に対しどこまで知見を持っているか？というのが重要視されたりします。
コピペ志向とも通じるところがあるのですが、無から有を生み出すのではなく、有を有’にする考え方が大事であり、その「’」を考えるにはやはりコンフィグというものが欠かせないのではないかと。
PerlとかPHPなどスクリプト系言語だと、拡大解釈すれば、もしかしてソースコードそのものがコンフィグファイルとも言えるのかな。
とにかく簡単に挙動を変更したり機能を追加できればいいのですよ。
でもって、こういったコピペとかコンフィグ的発想に当てはまらない、トリッキーなプログラミングが要求される場合、仕様がヘンって視点も持つべきじゃないのかなぁ。
（大抵その予感は当たる）
システムの流用で生産性を上げる
コピペ志向、コンフィグ志向が大事だなぁ、と思ったのは、システム流用というアプローチで劇的な生産性向上が見込める為。
これって至極当然な前の話なのだけども、実はそれ程重要視されていない気がします。
毎回１００万貰って１００万の人件費がかかるよりかは８０万で作るけど５０万で作ってしまったほうがいいでしょう？
都度スクラッチでやってしまうよりかは、２度目以降はコピペ、コンフィグどちらでもいいので、流用対応してしまえば、利益率上がるのでないかと。
ってなると大事なのは「システム流用が本当に行えるか否か」という話ですよね。
ライセンス絡むとメンドウだったりするし。
知識を自分（自社）に落とし込むのが如何に重要か？というのはそういうこと。
コラボレート志向
コラボレートというか分からないことはその分野の達人と協力しあうようにして、協力できそうにない状況であれば友達を増やすなりなんなりして日頃から協力体制を作れるように行動しておきましょう。
他人の力を自分の力に変えてしまうことが重要。
必要とされる技術を（どこに配置されていても構わないので）どうやって引き出し可能な状態にしておくか、ということ。
あと自分もやはり「与えるもの」がなければダメですよね。
（とりあえず立場的にダメ）
ってことでお互いに協力し合う、コラボレートなのかなぁ、と。
IPMessenger便利、MSNMessengerさらに便利
コラボレート志向を考える上で大事だなぁと思うのは、ちょろっとしたソースコードの受け渡しをどのように行うか？ということだ。
そりゃあ（コードの場所、URLなど）ポインタを示してくれれば自分でも探せますけど、「知っている人間が」IPMessengerとかに貼り付けて渡してくれたら早いじゃないですか。
もっと広げて考えれば、MSNMessengerとか使えば、全然違う職場で作業中の友達と教えあうことが出来てすごく便利ですよね、と。
プログラマーに対して要求される能力も変わってきている。
昔はアルゴリズムに詳しいやつがエラかったわけだ。
ちょっと昔はAPIに詳しい奴がエラかったわけだ。
今時はライブラリ（とかフレームワーク）に詳しい奴がエラかったりする。
多分、ネットワークが発達すれば、「そのライブラリに精通している人間」を知っている人間がエラくなったりすると思う。
（でも理解する為には当然基本的知識は必要だよ、とエクスキューズ）
TrackBack URL :
Comments (4)どこかで、「別の事柄で３度同じブログに辿り付いたのならば、そのブログの定期購読ユーザになる確率が高い」というエントリーを見た気がします。
どこだっけかなぁ、忘れちゃった。
で、それはそうだと思うし、逆に「３つの異なるブログが同じ事柄を記事として取り上げたのであれば、それは話題になっていると見なされる」ということもあるのではないかとふと思いました。
例えば、「これからのファッション業界で熱いのは赤いステテコだよ！」と３つの異なるブログで書かれたのであれば、まぁ真偽は眉唾だとしても、とりあえずそういうことが話題になっているんだよと認識されるといいますか。
CDでも書籍でも技術でもなんでもいいのですが、ある閾値（５０万とか７０万セールスとか）を突破すると、そこから先はものすごい勢いで伸びて行くって話があると思いますが、ブログが浸透したせいもあり、その閾値が極端に低くなった気がします。
否、別に社会現象ではなくて、セグメント内現象というか、ある属性付けられたコミュニティ内でだけ流行すれば、別に商売するには困らない状況だったりしますので、閾値が低くても大丈夫というか。
ここらへんをきちんと研究する学問ってないですかね。
ちょっと前にmixiのユーザ特性の研究が話題になりましたが（５０％のユーザは確かマイミク３人以下とかそういうやつ）、通常の社会学研究とか全然この辺の動きに追いつけてない気がするのだけども。
マーケ屋さんは頑張って色々調べているのかしら。
「３人いれば世界を変えられる」というのはある話題に同調するブログが少なくても３つは必要だということで、もし３人集まれば流行を作り出せる可能性はあるんじゃねーの？ってことだったりします。
こことかを参考にしつつ（今さら）はてなフォトライフへAtomAPIを使用して画像を投稿する処理をあーでもないこーでもないって悩んでいた。
PEARのHTTP_Requestを使ってどうやらできたみたい。
とりあえずコードはこんな感じ。
function postImage($account,$password,$img) {
$handle = fopen($img, "rb");
$contents = '';
while (!feof($handle)) {
$contents .= fread($handle, 8192);
}
fclose($handle);
$jpegdata = base64_encode($contents);
$created = date('Ymd\TH:i:s\Z');
$nonce = pack('H*', sha1(md5(time())));
$pass_digest = base64_encode(pack('H*', sha1($nonce.$created.$password)));
$wsse =
'UsernameToken Username="'.$account.'", '.
'PasswordDigest="'.$pass_digest.'", '.
'Created="'.$created.'", '.
'Nonce="'.base64_encode($nonce).'"';
$rawdata = '<entry xmlns="http://purl.org/atom/ns#">'.
'<title>Sample</title>'.
'<content mode="base64" type="image/jpeg">'.$jpegdata.'</content>'.
'</entry>';
$url = 'http://f.hatena.ne.jp/atom/post';
$req = new HTTP_Request();
$req>addHeader('Accept','application/x.atom+xml, application/xml, text/xml, */*');
$req>addHeader('Authorization', 'WSSE profile="UsernameToken"');
$req>addHeader('XWSSE',$wsse );
$req>addHeader('ContentType', 'application/x.atom+xml');
$req>setMethod(HTTP_REQUEST_METHOD_POST);
$req>setURL($url);
$req>addRawPostData($rawdata);
$res = $req>sendRequest();
if (PEAR :: isError($res)) {
return $res;
}
return true;
}
にしてもWSSE認証って今後も普及するのかしら？
bloglinesにホットキーの表記が追加されていた。
Hotkeys: j next article k previous article s next sub f next folder A read all r refresh left pane
多分、GoogleのRSSリーダ発表の影響。
Ningはsocial appsを簡単につくるためのPlaygroundだ。
match.comやflikr、del.icio.us、amihotornotのようなWebアプリを開発し、実行することができる場だ。
「作った先に何が待ち受けるのか？」が見えないのがちょっと微妙だけども。
イマイチぴんとこなかったもので。
やはり自分は物事の「集約」よりも「分散」に興味があるからだろうか。
昨日に引き続き、ウインドウ（つーか、DOM Element)のリサイズを色々とやってみていた。
で、どうやらリサイズできるようになったっぽい。
JSのソース（あまりエレガントじゃない）、サンプル
Firefox1.07とIE6.0(両方ともWind)で確認してみたら動いた。Operaとかはちょっと不明。（というか、ブラウザないし）
クラスSd.Resizable の使い方はこんな感じ↓
new Sd.Resizable( 'Elementのid', { minW:40, minH:40, bounds:this.setBounds.bind(this) });
minW、minHはElmentの最小幅、最小高さというのは、まぁよしとして、「bounds:this.setBounds.bind(this)」の部分ではサイズ変更時のコールバック関数を指定する。
例えば、こういう風に使われる。
HogeWindow.prototype = {
craete:funciton(){
this.window=document.createElement('div');
this.window.id='hogehoge';
document.body.appencChild(this.window);
new Sd.Resizable( this.window.id, { minW:40, minH:40, bounds:this.setBounds.bind(this) });
},
setBounds:funciton(l,t,w,h){
this.window.style.left = l + 'px';
this.window.style.top = t + 'px';
this.window.style.width = w + 'px';
this.window.style.height = h + 'px';
}
};
（bindって便利！）
リサイズするので、java.awt.Window#pack的なメソッドを呼び出せなくてはまずいだろーって思ったので。
ちなみにページスクロール補正を気にしてないのは相変わらず。
自分で使う分にはまぁいいかと思うので、気が向いたら修正なのかな。
あと気付いたのだけども、上辺、左辺をドラッグしてウインドウをリサイズした場合、dragdrop.js のクラスDraggableの挙動がちょっとおかしくなる。
Draggableはインスタンス生成時にElementの座標(left、top)を保持しており、再ドラッグ開始時にその値を更新しない為、変な動作をしてしまうような気がする。
この部分は独自組み込みにしてしまうかもしれない。
ところでここにはクラスSd.Lineっていうのがあるけれど、線（どちらかといえばElement同士を結ぶコネクタ）を引くライブラリが欲しいなぁ、と思ってちょっと考え中だったもの。
っていうか、DrawingCanvas使った方がいいのかな。
TrackBack URL :
Comments (1)ちまちまとJavaScriptのウインドウの続きを作っていた。
サイズ変更できるようにしようと。
で、できたのがこれ。
今のところ右辺と下辺と右下隅をドラッグすればサイズ変更ができる。
ソースはちなみにこいつ（一部）↓。ScriptaculousのDraggebleクラスみたいにResizableクラスにDIVを登録すると、そのDIVがリサイズ可能になる（というかDraggableを参考に作ってはみた）。
ちなみにPrototypeとかがないと多分動かない。
上辺と左辺がドラッグできないのがダメ、あと画面のスクロールには対応していないからスクロールするとまともに動かなくなるのがダメとか、まだ全然不完全だったりする。
閉じるボタンとかも欲しいし。
というか、どこかに手頃なUIのフレームワーク転がってないかな？
bindowとかもあるけどタダじゃないでしょ。
xdesktopはIFRAME方式だし、、dojoはサンプルがないからよく分からないし。
つーかこのへんのUI制御って普段は（MFCとか）API使っているんで、あまり得意じゃないのよね。。。
JavaScript得意な人だったら直ぐに作れるのだろうなぁ。
GoogleRSSReader支援Bookmarkletを作った人がいるらしい。
Bookmarklet自体はそんなに難しいものではないといえ、ベータ版提供が10/7だから、下手をすると２４時間たっていないのかもしれない。
自分は10時間前にこんな記事を書いた。
移行するかどうかと聞かれれば、(Firefox拡張とか）周辺のライブラリもまだ未整理だと思うし、もうちょっと様子見ですかね。
多分、このペースだと一ヶ月以内にFirefoxのエクステンションが出てきたり、GreaseMonkeyのユーザスクリプトが出てきたりして、あっという間に周辺ライブラリが出揃うだろう。
外部のユーザがサービスを補完する
Googleの現在の立ち位置が極めて幸運なものだということもあるのだが、外部のユーザがサービスを補完したというよい例となるだろう。
まぁ今に始まったことではなく、何度も見てきた現象ではあるのだが。
発表のタイミングが重要？
金曜日に公開されたということも大事？
週明けにはどれくらいの数の周辺ライブラリが揃うだろうか？
HTML convert time: 0.642 sec. Powered by WordPress ME