«前の日(07-12) 最新 次の日(07-14)» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2002-07-13 古い日記からの変換データ

_ 論文

論文(日本語)をなんとか8ページに収めた,と思ったら英語の abstract を書き忘れてて,ちょっと実験的に文章を書き足してみるとあっさり9ページ目にかかった.かなりショック.

_ URL.escape

namazu でインデクシングしてるファイルに,"(", ")" が含まれていることが判明.namazu が内部できちんとURL escape してるか不安になったのでソースをチェック.

mknmz.pl がほとんど事前作業はがんばってるので,そこを見ると NoEscapeURL とかいうフラグがあって,それによって escape 作業の ON/OFF を決めているらしい.えらい.

しかし,今頃になって,bun45 で動かしているカスタマイズした mknmz に追加したオプションが,これら標準オプションとかぶっているような気がしてきた.サーバが復旧次第,確認してみることにする.

_ bun45: default route

サーバが落ちてるので,どうしてかなーと思いながら隣のサーバに traceroute を仕掛けると通るはずのゲートウェイを通過してない.もしかして,今まで通る必要のないゲートウェイを通過しようとしていた?無駄にパケット投げつけるわけだから,一種の攻撃として認識されても文句いえないよなぁ….


2003-07-13 古い日記からの変換データ

_ 読書

マーセデス・ラッキー「女神の誓い」読了.アン・マキャフリィと「旅立つ船」で共同執筆してたので名前を見たから買ってみた.

主人公二人が女性という,わりと珍しい作品.誓約の剣<もとめ>の所有者は女性の助けを断れない,という制限付きの剣を軸に話が進んでいく.

ファンタジーっぽさを演出しているのは,誓いや絆が意味を持つ(何らかの力によって支援される)というあたりかも.シリーズものなので,続きも読んでみたいところではある.


2004-07-13 古い日記からの変換データ

_ [AspectJ][授業] アスペクト指向のレポート採点

AspectJのレポート課題の採点作業をする.課題自体は,特定のメソッドの実行回数を計測するプロファイリングのアスペクトを作るという単純なもの.

仕組みとしては理解できるし,便利というえば便利なのだけど,こんなやり方でいいのか,オブジェクトを外側から書き換えるのは気持ち悪い,可読性が下がりそう,予想外の時点でイベントが発生するのが怖い,バグを作りこんでしまうのでは?など,なんか怪しいなーという感じの印象が多かった.

アスペクトを書くよりは既存のアスペクトを使う,というほうが利点を感じるための課題としては適切だったりするかも?


2005-07-13

_ 日記の古いデータの整理

なんか検索してたら一部変換に失敗している(本文中の余計な改行のせいで,トピックが2つ以上に分かれてしまっている)ものをいくつか見つけたので,ちょっと(2002年〜2003年1月頭あたり)整理.

RSSで読んでる人には,ノイズが混入してしまいますがお許しください.

_ AOSD'06

Call for Contribution が出てました.今回はドイツ.Research Paper は9月23日にAbstract,30日に原稿提出.ワークショップへの投稿はおそらく1月とかのはずなので,その頃までに新しいネタが用意できれば,参加できるかも?


2006-07-13

_ [近況] 講演@UBC

Bjorn Freeman-Benson と Ward Cunningham の2人の講演.せっかくなので聞いてきた.2人で交互に喋るという形で流れるように喋っていく見事なプレゼンテーションだった.

講演のテーマは,協力(collaboration)って大事だね,というもの.2人の経験によると,プログラミングは最初は「自分だけ(me)」からスタートして,us(グループ開発)→you(商用ソフトの開発)→we(顧客と一緒に仕事する)→all(コミュニティでの協力)と進んできている.他人を信頼して協力することで,より良い成果を得ることができるようになっている.

1つのアイディアというのは,技術(technology)と方法論(methodology),アイディアを支えるコミュニティの3つによって成り立つのではないかと考えられる.たとえばJUnitなら,技術的には小さなフレームワークで,背景にはテスト駆動型開発という方法論があり,1つの開発チームが協力してそれを実践することで,より安心してソフトウェアを変更できるようになる,とか.

で,彼らは今は Eclipse Monkey というのに注力しているらしい.サイトはhttp://eclipse.org/dash/.端的には,Eclipse用の「ちょっとした改善」をスクリプトにしちゃおう,というもの.たとえばディレクトリツリーは最初に全部開いてる状態がいい,とかいうのを短いスクリプトで制御できるようにEclipseの環境をオブジェクトモデルとして提供しようというもの.短いスクリプトをみんなで公開して共有すれば,徐々に改良されながら便利な環境になっていくはずだし,「ちょっとした改善」も積み重なってくれば,開発者にとって便利な機能が分かってきて,それがAPIの洗練なんかにも繋がると考えているみたい.技術/方法論/コミュニティには,スクリプティング/リファクタリング/ブログなど,が対応する.

Eclipse の API が複雑化していることについては,開発者が学習する機会を設けるしかない.これについては独習用の教材(experience guide)を提供することが大事なのではないか,と言っていた.Eclipse の API を使うプログラミングの教育を scalable-personal という軸で考えたときに,ペアプログラミングは一番 personal 寄りで密度は高いけれど同時には1人しか相手にできない.パターンは逆に一番 scalable で,書籍なんかにすれば広く伝えられるけど,それだけではプログラムは書けない.wiki での情報交換ならもう少しだけ personal 側に寄るけれど,やはりまだ足りなくて,良い教材をコミュニティ(coach network)が提供して開発者が自分で経験を蓄積できるようにすべきだと考えているらしい.

……といったような感じで講演は1時間ちょっとだった.話された内容はだいたい理解したつもりだけど,多少ニュアンス違ってたりして.講演は,論文と違って,後から内容の正しさを確認できないのが厳しい.

余談: Monkey のスクリプトが Ruby や Python ではなく Java Script ベースなのは,熱狂的信者も強い反感を持った人も特にいなくて無難でしょ,とのこと :)