Netscape--よ、ひさしぶり

ふと、ニュースをみてぶらついていたら、Netscape9が出た事が書いてあった。
ブラウザマニアの僕は反射的にダウンロードしようとしていた。
Firefox２互換だし、FFのアドオンやテーマも使えるそうな。
まあ、あんまり期待せずにダウンロードしてみた。

使用感としては、FFに比べ、起動も動きもサクサクとしていて好感触。
多分、FFと比べてアドオンをまだたくさん入れてない事もあるだろうが、それにしても早い。

ちなみに私はMac使いです。
軽さをもとめてCaminoを入れたりしてみたが、google calenderが使えなかったり
思ったほど軽くなかったり。

シイラの新しいMacらしいUIに引かれたが、これも、googleのサービスを利用できない。

頼みのSafariも非常にサクサクで好感触なのだが、Google Notebookが使えない。

ということで、渋々、もっさりFireFoxを使い続けていたのだ。

ここで現れたNetscape。
非常に好感触なさくさくさの上に、すべてGoogleサービスを使えるという。
これはデフォルトブラウザにするしかないでしょ。

思えば、最初にインターネット体験したのは28KモデムにMacでMosaicだったと思う。
その後はじめて箱のパッケージで買ったのがNetscape2.0だった。
（今の人はブラウザを買うなんてかんがえられんでしょ）
でも、それからずっとネスケ派だったのだ。
久しぶりだけど、立派になって戻ってきたのね。

懐かしいやら、うれしいやら、変な感動のあった夜であった。

バグと言われてもね

自分の会社の案件で、ある一つの音楽サイトを構築していた。
相手はそこそこ大きい会社で、社内SEもいて、技術のわからない担当者の補佐としてミーティングに参加したりしていた。

このプロジェクトがボロボロで、タイムスケジュールの線表をひくひとは一人もおらず、いったい誰が進行役なのかもわからないかんじだった。
その上、複数の会社が課金系とかデザイン系とかデータセンター系とか存在していて、これを行ったいったいどうまとめるんだろうという感じ。

案の定、プロジェクトは遅れに遅れ、プログラミングする時間は半月ほどになってしまった。
不本意であったが引き受けた以上はプロとしてやるしか無い。
結局、pythonで半月で構築した。

この間に色々仕様らしきドキュメントが何通も送られてきているのだが、どれがメインなのかわからん感じ。
あの同席していた社内SE君はこんなときに力を発揮しないんだろうか？？
いっさい、かれは前線に出ばることはなく、ひたすら後ろに隠れ続けた。

そしてオープン前日の夕方から夜に、社内SE君からある一通のエクセルが送られてきた。
「不具合一覧表」
中には色々列挙されていたのだが、分類がほとんど「バグ」になっていた。
俺は切れそうになった。
こいつは一度もプログラミングを仕事でちゃんとやった事もないし、モノを一から作った経験がないんだろうな。

おれはバグと簡単に言うひと、特に技術者以外でバグという言葉を安易に列挙するやつは大嫌いである。
バグとは絶対的なものでなく、あくまで仕様というオブジェクトと相対関係にあるものだ。
ある仕様上はバグとなってもある仕様から見ればバグではないのだ。
そういう事はいっぱいある。

一度も仕様に関して話す事も話し合うこともなく、
そして最後の最後に勝手に物事をバグと判断して送ってきたこのバカちんは俺の中で死刑もんになった。
馬鹿チンよ、それはお前の頭の中のかってな感性が判断したバグと言うものだろ。
まともなバグはまともな仕様があってのこと。
仕様無くしてバグとはあり得ない。

こういうこともしらないで、会社にしがみついている社内SEは、世の中にいっぱいいるんだろう。
もう少し自分の進路とか今後に関して真剣に考えた方がいいよ。
今からならば、他の道はいっぱいあるんだからね！

python-mysql

pythonのMySQLライブラリを使っていたのですが、
MySQLでtimestampのフィールドから値を取る場合、
ちゃんと「datetime.datetime(2007,5,3,9,21,45)」のような形で値が帰ってくるようです。

pythonブラボー！！！！！！！

ちなみにint unsignedのようなフィールドだと「1L」の様にlong値で帰ってきます。

厳密にpython内部で使い安い型に変換されて帰ってくるのですね。
phpの時にすべて文字列で帰ってくるので、時間関係のフィールドは色々加工しなくてはならなくて大変でした。
大違いですね。

やっぱpythonは開発しやすい。
おおざっぱだけど、
インタラクティブシェル（ipython）で詳細設計しながら試しながらアイディアを膨らませて、
その際の裏付けもインタラクティブシェルでやっていて、
モジュールやメソッド毎にテストしやすくて、
デバッグも簡単にできる（pdb）。

さいこーのツールですな、python。

インタラクティブシェルのある環境

プログラミングでインタラクティブシェルのある環境はステキである。

Emacs Lisp、Python、Rubyと僕の周りにはいつもインタラクティブシェルの環境があった。
ちょっとした思いつきや、小さな小さな部品のテストやデバッグ。
インタラクティブシェルはいつもそんな小さな作業を助けてくれた。

大きなシステムや大量のコードを一遍に書くより、インタラクティブシェルで少しずつ確かめながら積み重ねていくのが好きだ。
小さなモジュールをいっぱい作ることが堅牢なシステム作りには欠かせないと個人的には考えている。

PHPにはインタラクティブシェルの環境があまり存在しない。
そこが嫌である。
探してみるといくつか有るようだが、制限が多かったり、使い勝手が洗練していない。
もっとちゃんとしたインタラクティブシェルが有れば、もっとテストファーストでプログラミングできるのにな。

Javaは開発環境＝IDEがその代わりをしていてくれるのかな。
でもそれを立ち上げるより、ipythonを立ち上げる方が軽くて気軽だけどね。

小さな部品をいっぱい作ろう、インタラクティブシェルという砂場で遊びながら。
それを組み立てて大きなものをつくろうよ。

Python再び

サーバサイドJavaなんていってJSFに触り始めているのだが、どうもこちらは業務系システムとか管理画面系向けでコンテンツ向けではないね。ってことで、考えているうちに、会社の仕事の方でPythonを使う可能性が出てきた。

現状、オリジナルPHPフレームワークで運用されている自社サービスだが、フレームワークコアまで手を入れられ、スパゲッティーになりかけているプログラムの拡張性に限界が出てきていることと、DBのスケーラビリティーにかんして、やはりちまたのサービスを見ていると、色々問題あるよね、とか場合によってはプログラム側ががんばってみたり、お金をかけちゃって解決したりするのですよ。

会社では俺ともう一人が改修を期待されているメンバーで、色々面白いフレームワークを考えています。
基本的にはデータベースとWebというここ数年の流れを無視した新しい物になります。
多くはかけないのですが、RubyとPythonとPHPを使う事になります。
基本的にはRuby on Railsは使わないんですが。
合い言葉は「Back to UNIX Basic」
かなり拡張性が考えられる物になる予定です。

ということで俺はPythonをつかって一部を、もう一部をPHPを使って書きます。
久しぶりのPythonで、持っているデスクトップリファレンスから、よく使っていたのは1999年頃だとわかった。
もう8年ぶりくらいである。
その間にも色々Pythonは進化してますな。その一方で後方互換性もよく考えられています。
Pythonの良さは最近LL系はみんなそうなのだが、インタラクティブシェルがある事で、色々プロトタイプから積み重ねで試しながら構築していく事が出来る事です。開発プロセスが言語環境との対話的要素で進む訳である。これが気持ちよい。特にPythonをする人はipythonは入れるべし。インタラクティブ性が一層あがります。
これとEclipse＋PyDevがあればとりあえず完璧でしょう。
最近は、FirefoxにFirebugをいれると、JavaScriptのインタラクティブシェル環境も出来ますね。
時代の流れなのでしょう。

Pythonの良さはシンプルさしょう。
適度にObject指向ですが、JavaScriptににて、ガチガチの静的なObject指向ではありません。
むしろ僕は、Pythonの持つモジュール機能という大規模開発にも耐えうるシンプルな仕組みに注目しています。
僕が勉強し始めた昔はPythonのオブジェクト指向は、中途半端な感じが否めず、関数とか多くて、それゆえRubyとかより純度の高い言語から批判される事もありました。しかし今のPythonはもっとシンプルに組み込みデータ型から関数、メソッド、クラス含め、すべてObjectを継承しているものです。よりObject的整合性は増したようです。

しばらくPythonとJavaScriptにはまる事になるかと思います。

JSFについて

最近再びサーバサイドJavaに触り始めている。
特にJSFである。

Sun Java Studio Creatorを入れていろいろ作ってみているんだが、パンピーの開発者からみてJSFに一言。

JSFはコンポーネントをドラッグアンドドロップでフォームにペタペタと貼付けて作っていく所が特徴。
後はイベントモデルということで、前にSwing等をやったことの有る人の方がわかりやすいだろう。

で、足りないものがあるなーと思っているのは、JSFは基本的に設計時にコンポーネントを固定数だけ貼付けて動く画面のものには非常に有効で作りやすいのだが、例えば、DBから取り出した個数に応じて動的にコンポーネント数がかわるものに関しては、あまり作りやすいように作られていはいないようだ。（間違っていたら識者の方ご教授ください）

基本的にDBの取得数に応じて動的に変化するコンポーネントって、グリッドやドロップダウンリストぐらいしか無い。
けどたとえば、DBの取得数に応じてリンクをリストとしてならべて行くとか、画像を並べていくとかいう時には、それ用のコンポーネントが無いのだ。解決策としは、あらかじめJSPのデザイン時にプレイスホルダーとしてレイアウトパネルかグリッドパネルを設置する。グリッドパネルの方はテーブルとしてレンダリングされるので、単純にDIVとしてレンダリングされるレイアウトパネルの方が好ましいかもしれない。

そして管理Beanの方で、init時にDBからの取得したRowSetをループさせながら動的にHyperLinkクラスのインスタンスを生成して、それをレイアウトパネルの子属性として、ちょうどDOMのように追加していく訳である。具体的にはコンポーネントインスタンスのgetChildren()メソッドして、それに対してadd()メソッドで追加していく訳である。

このように、JSFではこういうコンポーネントが無い為に泥臭くJavaコードを記述しなければならない。
ASP.NETであるような、Repeator(?)のようなものが必要なのではないだろうか。

この他にも単純にJSFの管理ビーンの中からHttpServletRequestなどにアクセスするときも、結構、面倒な手順を2~3行書く必要が合ったりとか、結構、Javaの持っているまどろっこしい所が出てしまっているようだ。

もう少しEoDを極めないと中途半端だと感じた訳である。

那須にてモバイル

現在、那須のペンションに泊まっているのですが、早速、購入した工人舎のノートPCが活躍しており、これでメールチェックとかブログ更新とかしています。

ノートPCもようやくキーボードのタッチになれてきた感じでスムースに文章が書けるようになってきています。

で、通信なのですが、auのPacketWinで接続してるんですが、結構、言っちゃ悪いが那須の山の中の僻地でもPHS以上の快適な通信ができるってことは感動ものです。確かに理論どおりの2.4Mのスピードは東京都心でも出ないけど、こんなところでも安定してネット環境が享受できるということはすばらしいことです。パケ代も、Gmailチェックとmixi更新、vox更新、はてダ更新で500円くらい。（パケット割スーパー）

まあ、こんな感じでユビキタスにネット環境を味わえるのはいい時代が来たものです。
しかし、本当は携帯電話だけでもいいところに、こうやってPCや通信環境を持ってくるところが、俺って携帯世代じゃなくPC世代の価値感の人間なんだなって実感。

ま、那須の山中の僻地でもちゃんとPacketWinは使えるってことで、auはすばらしいねって言いたかったというだけなんですが．．．