http://oss.timedia.co.jp/index.fcgi/kahua-web/show/Zope3/Zope2%a4%c83%a4%ce%b0%e3%a4%a4%a1%a2%bb%a8%b4%b6%a1%a3
Zope3の特徴を列挙。
- Python との親和性が高くなった
- Zope 独自の黒魔術が少なくなった
- ドキュメントがある!
- ファイルシステムベースで開発ができる
- 一貫したコンポーネントアーキテクチャによる抽象化
- テスト機能の充実
- セキュリティ機構の変更
Zope2がPythonで作られた箱庭ソフトであるなら、
Zope3はPythonライブラリ、という感じでしょうか。
全然別物だなあ。
Zope2 では、どんなデータでもオブジェクトとして、
ZODB に格納して、そのオブジェクトにアクセスすることで、
表示や、アプリケーション動作などをやらせる、
というアーキテクチャで、とても格好良い。
でも深くいじるには、そのアーキテクチャをまずちゃんと
理解しないといけなくて、敷居が高かったのかもなあ。
他のアプリケーションフレームワークは、ほぼすべて
ファイルシステムベースなわけだし。
参考) ZODB How-To(日本語訳)
http://wiki.zope.jp/ZODB%20How-To
おそらく Zope の初期の目標は、
DTML と Product という便利なものを使える箱庭を作る、
ちょっとイケてるウェブサーバを作る、
というもので、初期のユーザはその箱庭で遊んで、楽しいねえ、
便利だねえ、と言ってたのが、
意外と流行ってしまったために、ユーザ層が変化して、
- 他のシステムとの親和性をより高く、
- 開発者により優しく、
- CMF としてより使いやすく
- でも Zope 独特の便利さはある程度そのままに、
というような要望が出てきたんだと思う。
要望に答えるためには、アーキテクチャをがらっと変える
必要があった、と。
実際に変えちゃったのはすごいパワーだ。
本家のページを眺めてみたら、そんな記述もあるね。
Zope 3 Project VisionStatement
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VisionStatement
Zope 3 Project WiKi
http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage
拡張ライブラリの呼び方も違う。
Product ではなく Add-on Packages なのね。
http://mk.zansu.com/selenium/index.htm
via http://secure.ddo.jp/~kaku/tdiary/
ウェブテストツールの Selenium は以前取りあげて
ちょっと使ってみたけど、本格的に活用はしていなかったり。
--> [2005-08-16-14]
ウェブをいじることが増えそうなので、
もうちょっと真面目にいじってみるか。
http://www.drk7.jp/MT/archives/000916.html
via http://secure.ddo.jp/~kaku/tdiary/
apache の場合は、付属の rotetelogs で大抵は問題ないけど、
大量のアクセスがあるような場合には、より柔軟な設定ができる
cronolog のほうが重宝。
最近使ってないのでボケ防止にメモ、と。
http://www.otsune.com/diary/2005/09/25/3.html#200509253
うわ、知らんかった。便利。
わたしも make search で調べてた。
http://www.nsug.or.jp/seminar/sympo.html
行ってきた。
会員にもなってみたよ。
実は出席するのは初めてだったりする。
ケルベロスの話から聞いた。
ケルベロスは
- チケットによる管理を行なう
- チケットには有効期限が設定されているので
- 様々なアプリケーションで利用できる
- ネットワークが切断されてても使える
というような魅力的な認証技術なんだけど、
いまいち流行っていない。
その理由は、
- アメリカの暗号規制のせいで普及が遅れた。
- 概念、用語がいまいちわかりにくい。
(まあ認証系のシステムに共通する問題かもしれんけど)
- 実装間の互換性問題がある。
- 実際の運用事例があまりない
というようなことなんだけど、
でも今回の発表資料を見る限り、採用を積極的に
検討しても良いような気がした。
発表者のくろももさんが、スーツコスプレ？だったのが、
ちょっとオカしかった。
レセプションにも出席。
食事が結構豪華。
SUNがちゃんとお金を出してくれてるんだなあ。
ありがたや。
幹事の挨拶、くじびき、砂原先生の語り付きクイズ大会。
そんな感じの流れ。
NSUGは年配の人が多い。
やっぱり歴史ある団体なのね。
日本の初期のインターネットを作った層と重なるんだろうな。
クイズの答にもなってたけど、NSUGの幹事の平均年齢は40を
超えてるらしい。
NSUG に比べると JANOG もまだまだ若い。
ちなみに、若手はどこに行ってるか、と言うと、
単におじさん達のいるところに来ないだけで、
ちゃんと独自にイベントを開いていたりする。
なのでそんなに心配しなくても大丈夫よ、きっと。
たとえば、昨日の WiKi 小話参加者の平均年齢は
多分 30を切ってると思うしね。
終了後、しろぺん氏と雑談をしながら帰宅。
http://picasa.google.co.jp/
via http://akalabo.net/archives/2005/09/google_picasa.html
なんでも Google だな。
インストールして試してみた。
これは良いっすよ。便利!
丁度探してた画像があって、早速役に立った。
Wikiばな系のイベントに行ったのは初めて。
参加者がみんな若い。若いって良いなあ。
発表内容は発表者のたつをさんが書いてくれるらしい。
http://nais.to/~yto/clog/2005-09-21-1.html
なので個人的に面白かったネタだけ。
- イベント会場は漫画喫茶が良いかもね。漫画も読めるし。
- 韓国には Wiki っていう名前のゲームがある。
ゼルダそっくり。
この辺か。
--> http://blog.livedoor.jp/stardom/archives/14511758.html
- Wiki Coffin というマオリ族の人を主人公にした小説がある。
- Yahoo の Y は、山下たつを の Y。(それは言いすぎ)。
- どこでもプレゼンできるプレゼンVAIO 良いかも。
- Pukiwiki.org は今のデザインの方が格好良いよね。
いっそ、今の人に運営もやってもらえば？
- WiKi SPAN、SPAM Blog は困るよねえ。
指南するサイトまであるし。
- Wikipedia のページをコピペして、アサマシ付きで、
毎日発信してるブログなんてのもある。
WWW::Wikipedia モジュールを使えば簡単!
- 「こくばん」すげー
--> http://blackboard.sourceforge.jp/wiki/
http://chasen.org/~taku/software/ajax/hwr/
すげー。
この作者の工藤さんすごい。
面白くて便利なソフトウェアを大量に作ってる。
くどう たく ホームページ
http://chasen.org/~taku/
過去の日記でも沢山取りあげてる。
Ajax を使った日本語 Full IME -->[2005-08-10-3]:
IME + KWIC の合わせ技 --> [2005-03-01-14]
mecab-skk --> [2005-03-18-9]
MeCab --> [2005-09-09-2]
プロフィールを見るとウクレレの人なのね。
たつをバンドなのかな、と思ってウクレレブラザーズの
写真を確認したところ、メンバーではないみたいだ。
ウクレレと私(たつをさん)
http://nais.to/~yto/ukulele/
ひょっとするとウクレレ人口って結構いるのか？
わたしも持ってるだけなら持ってるし。
http://d.hatena.ne.jp/maem/20050920#p1
ユーザ
Microsoft
cisco
物理層
わらった。
でもね、ビジネスをする上ではこういう現状認識はすごく重要。
供給者としてもユーザとしてもね。
http://oss.timedia.co.jp/index.fcgi/kahua-web/show/MySQL%c6%fc%cb%dc%b8%ec%a4%ce%ce%b9
マイコン創世記に BASIC コンパイラを作ったことで
一部マニアに有名な藤原博文さんが、
(まあ本書いたり、他にもいろいろやってるけど)
MySQL の日本語対応で格闘中、というコンテンツ。
MySQL と日本語で悩んでる人は必見ですわ。
えー!、とか、なるほど!、とか思うはず。
http://www.nsug.or.jp/seminar/sympo.html
仕事で行けるなら行くつもり。
禀議が通る確率は1割ぐらいか。
http://www.itmedia.co.jp/enterprise/articles/0509/15/news059.html
http://slashdot.jp/article.pl?sid=05/09/18/0116205&topic=2
ゲストOS に Plan9 が使えるっていうのが楽しそう。
Plan9 は最低3台ないとシステムが組めないので、
リアルに気軽に試すっていうわけいにはいかないのよね。
Plan9 は UNIX を開発したベル研のグループが、
UNIX の問題点を克服するために開発した OS で、
とても格好良いのですよ。
ファイルサーバ、認証サーバ、ターミナル、からなる構成は、
分散環境のアーキテクチャのリファレンスとして良くできている。
ウェブサービスを設計する上でこういう知識を
持っているのと持っていないので大部違ってくると思う。
Plan9 については以下が良くまとまっている
Plan 9
http://plan9.aichi-u.ac.jp/
Xen については、Vmware に似たもの、と思って
そんなに間違いじゃないけど、アーキテクチャはちょっと違う。
各種仮想化技術のアプローチの違いについては、
以下が良くまとまっている。
仮想化技術の各種アプローチ
http://www.atmarkit.co.jp/flinux/special/vm/vm02.html
http://www.geocities.jp/game_orchestra/index.html
エロゲーの音楽を演奏するオーケストラ。
残念ながらメンバー募集は終わっております。
誰か出る人いたりする？
via http://dkiroku.com/2005-09-19-3.html
両方の属性を持つpochiさんにぴったり。
む、誤解があるようだ。
エロの属性もゲームの属性もわずかながら持ってるけど、
エロゲーの属性は持ってないっす。
周囲になぜかエロゲー属性の人は多いのは事実だけど、
まだ毒されておりませぬ。
ちなみにエルフやコナミで有名エロゲを作ってた面白い人が
後ろの席にいたこともある。
その面白い人が最近作った会社
http://agile-people.com/
(おいおい、サーバ落ちてるよ)
http://www.atmarkit.co.jp/farc/rensai2/thinking01/thinking01.html
お金を出すほうと、作るほうが、ちゃんと対話をする、
ということが重要なんだよね。
システムを作るほうは、ユーザが喜ぶことを理解しなきゃいけないし、
ユーザは、システムを作る人の言い分を聞かなきゃいけない。
信頼関係重要。
信頼できないんだったら、そもそも組んで開発すべきじゃない。
万が一の場合っていうのは、契約で担保できるわけだしね。
http://blog.bulknews.net/mt/archives/001807.html
via http://secure.ddo.jp/~kaku/tdiary/
開発におけるフレームワークの選定は、
業務のシステム化に似てるかも。
フレームワークを用いる場合には、フレームワークが
得意なシステムを作るとうまくいく。
業務のシステム化をする場合には、パッケージ等に
合った形で業務プロセスを構築するとうまくいく。
フレームワークの限界を超えることを要求したり、
パッケージを外れた業務を無理矢理組みこもうとしたり、
そんなことをするとまず失敗する。
道具には思想があるので、その思想に合わせて使う、
というのが大事。
竹槍は主に一揆に使う武器。B29は落とせない。
高射砲はB29は落とせるけど、一揆には使えない。
http://mono.kmc.gr.jp/~oxy/hiki.cgi?rtype
via http://secure.ddo.jp/~kaku/tdiary/
Perl6 の Haskell 実装の Pugs のパクリ。
こういう富豪的なものって結構好き。
とてつもなくコンパイルにメモリを消費しますので...
...ぜひRTypeの開発に関わってみませんか！
いい暇つぶしのネタにはなるはずです。
わろた。
似たネタ)
こしみずさんによる Ruby による Forth の実装(obsolete らしいけど)
http://www02.so-net.ne.jp/~greentea/ruby/yong/
http://www.openalexandria.com/item_714.html
via http://secure.ddo.jp/~kaku/tdiary/
パワーポイント嫌いなんだけど、使う機会多いんだよなあ。
WiKi で書いたメモや、テキストで書かれたメモを、
パワーポイントに変換するようなツール、
誰か作ってくれないかのう。
http://d.hatena.ne.jp/higepon/20050915/1126755141
via http://secure.ddo.jp/~kaku/tdiary/
注意点。
- うっかり変なオプションで ldconfig を実行すると、
DLL の情報が全部消えちゃうぞ。
ちょっと詳しくなったら必ずやるミスの1つだと思う。
- ldconfig は OS によってオプション等が全然違うぞ。
- Linux とかではライブラリのバージョン番号が一緒でも、
インターフェイスが変わる、という非常識なことが結構あるぞ。
http://88171.net/UnisonManualJa
ファイルの同期ツール。
結構良さげなツールっぽいので、機会があったら使おう、
と思ってるんだけど、たいていの場合は rsync で充分なので、
まだ使ったことはないんだよね。
特徴。
- UNIX と Windows 両方で動く
- ユーザ権限で動作可能
- 双方向のファイル更新が可能
- GUI で操作もできる
- 転送は rsync と同程度に高速(だと思う)
注意点。
- シングルスレッドで動く。
- 今のところハードリンクを理解しない
- バージョン管理はしない(そういうツールじゃないし)
追記)
otsune さんからコメントをもらった。
- unison はファイルカタログDBを作るのでシンクロ開始が早い
rsyncは起動ごとに舐める
- 転送方法は rsync アルゴリズムなので一緒
- unison はファイルサイズの大きなディレクトリを転送中のときは、
転送終了まで可視にならない。
.#hogehogeという感じの不可視ディレクトリで転送作業をしている。
rsyncはファイルごとに可視になるので、転送途中でも随時作業にかかれる
- rsyncは受信側がメモリを2倍消費する
なるほど。
unison 良いなあ。
シンクロ開始が早い、というだけでもかなり魅力的。
http://mojix.org/2005/09/15/231938
JavaScript で実装した高機能なウェブページって
REST アーキテクチャとの相性が悪い気がするんだけど、
その辺の解決手段とかあるのかしら。
このデモではわからないんだけど、フレームワークレベルで、
解決してるのかなあ。
でもここまですごいと REST なんてどうでも良い気もする。
多分爆発的に流行るんだろうな。
ただ個人的にはちょっと困る。
JavaScript に対応してないブラウザを良く使ってるのよね。
wget とか w3m とか。
w3m を JavaScript に対応させる、というプロジェクトも
あるらしいけど、使いものになってるのかのう。
w3m-js
http://abe.nwr.jp/w3m/w3m-js.html