simpleCaptcha on Debian etch

Debian etch上でtomcat 5.5を動かして，SimpleCaptchaを使うには工夫が必要．

implementingを見ながら，普通に使うと以下のようなエラーが出る．

java.awt.HeadlessException
 sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:65)
 nl.captcha.text.imp.DefaultWordRenderer.renderWord(Unknown Source)
 nl.captcha.servlet.DefaultCaptchaIml.createImage(Unknown Source)
 nl.captcha.servlet.CaptchaServlet.doGet(Unknown Source)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

google等で調べると，tomcatの起動時に，

-Djava.awt.headless=true

と指定すれば解決できると書いてある．

具体的には，Debianでは，

/etc/default/tomcat5.5

を，以下のように編集する

# Arguments to pass to the Java virtual machine (JVM)
# "-Djava.awt.headless=true -Xmx128M" is automatically set if CATALINA_OPTS
# is left empty here
CATALINA_OPTS="-Djava.awt.headless=true -Xmx128M -server"

が，実際はこれだけではうまくいかない．
何故かというと，Debian etchのaptを使ってインストールされるJavaが，やや古いために起こる．
Java 1.4.2では，headless modeでJavaを起動しても，sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(...)がheadless exceptionを投げてくるバグがあるのだ．
Running in Headless mode still produces Headless exception with GTK UI

これを回避するために，SimpleCaptchaのコードを少々いじくる．
いじくるファイルは，

$ vi $SimpleCaptchaDir/JavaSource/nl/captcha/text/imp/DefaultWordRenderer.java

で，57-60行目をコメントアウト

 57                 //GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
 58             
 59                 //GraphicsDevice gd = ge.getDefaultScreenDevice();
 60                 //GraphicsConfiguration gc = gd.getDefaultConfiguration();

次に，build.xmlの12行目を正しいj2ee.jarのありかに書き換える．

 vi $SimpleCaptchaDir/build.xml
 12                 <fileset file="F:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1\runtimes\aes_v4\lib\j2ee.jar"/>

最後に，SimpleCaptchaのトップディレクトリで，antを実行．

$ cd $SimpleCaptchaDir
$ ant

すると，dist以下にそれらしきjarファイルが出来上がる．

Windows版

Parallels上のWindows XP SP2だと全然落ちないけれど，実機だと落ちる模様．
うーん，これじゃ，デバッグできない．

IPv4アドレスは枯渇していないのか？

IPアドレスは枯渇していない

現状として，これだけNATだらけの社会でいわれても，あまり納得がいかない．

タイトルは，「理論上IPv4アドレスは枯渇していない」の誤りなのでは．

まぁ，なんとかしてくれ！NAT！
と，P2Pソフトウェアを作っていて思うので，アドレス再分配か，All IPv6化ができればとても幸せなのですけどね．
どちらも，机上の空論で終わって欲しくないものです．

僕もWIDEメンバーの端くれなので，IPv6はP2P@iでも対応したいところです．
対応するにしても，現在のIPv6の普及を見る限り，たぶん，仮想IPネットワークの方からだけど・・・
しかし，おそらく，IPv6なネットワークを即座に構築できるようになれば，IPv6アプリケーションの普及にも役立つのではないかと思う．

安心できる社会

最近，安心してくらせる社会を，などと囁かれることが多い．
それは，インターネットの世界でも例外ではなく，安心して利用できるインターネットの実現に向けて，などといわれる．

しかし，安心，安心，と謳っている割にいっこうに世の中が安心できる世の中になっているとは考えられない．

それでは，この「安心な世界を！」と言うフレーズを，声高らかに言っている人は誰なのだろうか？
じつのところ，こういった人たちは，セキュリティや防衛の人々な気がする．
この人たち，つまり，安心を売る人たちは，それを売って商売をしているわけで，実際，みんなに安心してもらっては困ってしまうのだ．

例えば，
「現在の御社は，セキュリティ管理が非常に甘くなっております」
「我が社のセキュリティソフトを利用すれば，安心してインターネットに接続できます」
などなど，安心を売る人たちは，いかに現状が安心できない社会かを述べて，利益を上げている．
このような人たちが，うようよでてきて，毎度毎度きかされると，現在の社会がとても不安定で，ひどいものであるという気になってしまう．

しかし，一言断っておくと，セキュリティを生業としている人達の中にも，真面目に社会インフラのセーフティネットとしての，セキュリティに関する技術開発や研究を行っている人もいるにはいる．
しかしながら，消防署の方から来ました，などと言うあやしい論法で安心を売っている人も確実に存在する．

話は変わるが，アメリカの国防費は，全世界でトップであるばかりではなく，国防費全世界2位日本との差は7.1倍もある．
http://www.number27.org/work/maps/weapons.jpg
日本も，アメリカも，こんなに国防費を使っているのに，安心できる社会を！と叫んでいるのは，ちょっと滑稽な感じがする．
一体全体，どれだけ国防費をつぎ込めば，安心できる社会になるのだろう．

安心を得ようとして，ますます不安を煽っては居ないのだろうか？
安心を見つけるために，現在どれだけ安心でないかを探してしまっては居ないのだろうか？

そして，安心を売っている人に教えて欲しい，
「いったい，いつになったら，安心できる社会とやらが訪れるのか？」
を．

UPnP NAT Traversal

世の中の大半は，NATで接続しているという，驚愕の事実が発覚したため，至急UPnP NAT Traversal対応版を作成中．

次のリリース0.6では，UPnP対応となる予定．

しかし，このUPnPってやつは，XMLをパースしなければ行けなかったり，ひたすら面倒くさい．
そんなわけで，もう，ライブラリ使ってしまおう．

とりあえず，Linuxは，
http://upnp.sourceforge.net/
Windowsは，
http://www.codeproject.com/internet/PortForward.asp
でいけるかなぁ〜

このページも役に立ちそう．
http://www.bosuke.mine.nu/neta/upnp.shtml

はやく，IPv6オンリーの世界になぁれ！

Windows版 その2

基本的なところは，ほぼ動くように！
あとは，Web UIの部分を移植すればWin32版の移植は一段落．

つづいて，ユーザビリティの向上を行おう．

emacs for BSD style coding

(setq c-default-style "bsd")
(setq c-basic-offset 8)

アフォーダンス

部屋に入って，ボールと椅子があったとき，普通，ボールをけっ飛ばして遊んで，椅子に腰掛ける．
誰も，椅子をけっ飛ばして，ボールに腰掛けようとはしない．

これは，椅子自身が，座るものだということを，人間に思い起こさせ，ボールはけっ飛ばすものだと人に訴えかけているからである．

男子トイレが青色のマークで，女性トイレが赤色のマークなのも，過去の経験などを人に思い起こさせるためだと考えられる．
すなわち，そのマーク自身について，人間が新たに知るべき情報を極力減らすことが出来るので，ユーザは迷うことなくトイレに駆け込むことが出来る．

もしも，引き戸にドアノブがついていたら，とんでもなく使いづらくなってしまう．
これは，過去の経験との相違があり，さらに，その扉について，人間が新たに学習しないという負担を課してしまうためだと考えられる．
学習は楽しいものであるが，主題や目的と外れた学習は，人間にとって苦痛であるのだ．

オブジェクトがどうすればいいか物語らなければ，よいUIとは言えない．
機能が豊富であれば良いように思われるけれど，豊富な機能を学習しなければ，使えないのはあまりよろしくない．
なんでも出来ます，とうたわれているものが，実は何も出来ないのはよくあること．

昔はパソコンさえあれば，何でも出来ますと言われていたけれど，最近は，ネット接続や，マルチメディアなどに的を絞って宣伝している．
何でも出来ますは，実はユーザにとっては何も出来ないことだったのだ．

以上の考察より，

「何ができるのか？」

を，明確にした上で，

「どうすれば．その出来ることを実現できるのか？」

を直感的に人間に分からせるようなインターフェースを実現できると，人間に優しいソフトウェアが出来上がるのではないかと思う．