2006年4月のアレ

java.lang.IllegalArgumentException: argument type mismatch
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod
	  (PropertyUtilsBean.java:1773)
	at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty
	  (PropertyUtilsBean.java:1759)
	at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty
	  (PropertyUtilsBean.java:1648)
	at org.apache.commons.beanutils.PropertyUtilsBean.setProperty
	  (PropertyUtilsBean.java:1677)
	at org.apache.commons.beanutils.BeanUtilsBean.setProperty
	  (BeanUtilsBean.java:1022)
	at org.apache.commons.beanutils.BeanUtils.setProperty
	  (BeanUtils.java:313)
	at org.apache.commons.digester.BeanPropertySetterRule.end
	  (BeanPropertySetterRule.java:197)
	at org.apache.commons.digester.Digester.endElement
	  (Digester.java:1130)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement
	  (Unknown Source)
	  …以下略…

このログは適当なところで改行してある。

そこで、ちょっと調べてみたら、 converter を登録すればいいらしい、ということが分かった。そこで、次のような DateLocaleConverter を、Digester を new する前に実行してみた。

    protected void configureConverter() {
        DateLocaleConverter converter = new DateLocaleConverter(Locale
                .getDefault(), "EEE MMM dd HH:mm:ss zzz yyyy");
        converter.setLenient(true);
        ConvertUtils.register(converter, java.util.Date.class);
    }

すると、こんな感じ。

org.apache.commons.beanutils.ConversionException: Unparseable date:
     "Sat Apr 29 04:13:00 JST 2006"
	at org.apache.commons.beanutils.locale.BaseLocaleConverter.convert
	  (BaseLocaleConverter.java:231)
	at org.apache.commons.beanutils.locale.BaseLocaleConverter.convert
	  (BaseLocaleConverter.java:195)
	at org.apache.commons.beanutils.ConvertUtilsBean.convert
	  (ConvertUtilsBean.java:428)
	at org.apache.commons.beanutils.BeanUtilsBean.setProperty
	  (BeanUtilsBean.java:1002)
	at org.apache.commons.beanutils.BeanUtils.setProperty
	  (BeanUtils.java:313)
	at org.apache.commons.digester.BeanPropertySetterRule.end
	  (BeanPropertySetterRule.java:197)
	at org.apache.commons.digester.Digester.endElement(Digester.java:1130)
	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement
	  (Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$
	  FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
	  (Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse
	  (Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse
	  (Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.commons.digester.Digester.parse(Digester.java:1685)
	at com.phinloda.blogcrawler.jugem.XmlUtil.read(XmlUtil.java:114)
	　…以下略…

最後のクラスの名前が怪しげですが、いまのところは見逃してください。

どうもうまく parse してくれない。お手上げということで挫折。誰か教えてください。

ちなみに、ソリューションはある。 java.util.Date ではなく、java.sql.Date を使えばこんな問題は発生しない。ということで、プログラム的には解決しているのだが、釈然としない。

2006年4月28日

金曜日の夕方になるとなぜか Norton AntiVirus が全スキャンを始めるのだが、これっでどうすれば禁止できるのだろう?

バッテリーで使っているときに、いきなりそういう重い作業始められるのは迷惑以外の何物でもないのだが。しかもこっそり始まったりするので、しばらく気付かなくてどんどん体力消耗してしまう罠。

スタバでデータを送ろうとしたら、満席。ってことは、ロビー使えばいいのだが、外のカフェテリアを使ったものだから、寒。つまり MZone のスポットに行きたかったのである。

2006年4月27日

実はここのトップページは、真ん中の画像をクリックすると、 forrest で生成したトップ(もっと読みます?のリンク先)にジャンプするのだが、もしかしたら殆どの人が気付いていないのだろうか?

納品締め切りの日。というか過ぎているんですけど、とりあえずバージョン【謎】を CD-R に焼いてもって行ったら、いきなり CD-R が読めない罠。

あっ、そうか、その手が…

じゃなくて、一瞬どうなることかと思ったが、他の pc で読めたので桶。これ、VAIO BX のドライブの問題なのか? Vaio Update の、ファームウェアの更新は行ったのだが、確かあれは作った DVD-R が読めないことがある、という症状に対する修正で、 CD-R には影響ないものだと思っていたのだが、何か勘違いがあるのかも。

まあ実際はそういうことがあるかも、というあたりまで無意識に想定して、 pc とか USB 接続のドライブ、生の CD-R とか、一式持ち込んでいたりするので、本当に読めなくても何とかなったはず。

CNET Japan が前回のリニューアルのトラブル後、かなり不調で、反応も激遅だったりするのだが、画面が出る場合はまだよくて、こんなメッセージが出ることも割とある。

Proxy Error
The proxy server received an invalid response from an upstream server.

The proxy server could not handle the request GET /.

Reason: Could not connect to remote machine: Connection timed out

Apache/1.3.33 Server at www03.japan.cnet.com Port 80

Apache は 1.3.34 がリリースされている。 recommended over all previous 1.3 release だそうですが…。

1.3.34 っていつリリースされたか分からないのだが、 ftp サイトとか見ると 2005年10月17日頃のようだ。半年前である。 recommended という minor version up に対して実際に update していない、ということは、何か問題があって戻したのだろうか?

2006年4月26日

久々に赤坂の某クリエイティブ出版社に行った。いつもと違う道から行ったのだが、坂が急で参ったものだ。

炭鉱本じゃないや単行本出そうよという話なのだが、やはりC言語でしょう、入門書でしょう、という線があって、今時まだCなのか、という声もあるような気はするのだが、確かに COBOL とか Fortran と違って、 C である程度慣れていたら、 C++ とか Java に行くのは簡単というか、表現として酷似した書き方がたくさん出てくるから、プログラミング全体の入門という位置づけでのC言語入門書、というのはアリだと思う。

今でもなぜか「C言語の入門書は何がいいか」と質問されたりして困ることがあるのだが、これだけ多数の入門書があっても、これがおすすめだ、というのは知らない。だって殆ど読んでないし。

というか、全然読んでない訳ではないのだが、やはりある程度プログラミング経験あるし、ビットとかメモリ空間という概念は生まれつき知っていて、アルゴリズムという言葉は学校で習った、みたいな人でないと分からない構造になっているので、本当に分からない人には何もわからない。もう一つは、そういった入門者を書いた人の責任ではないのだが、 C言語の書き方の説明になっていて、「プログラムというのはどうやって作るのか」ということが書いてない。だから、C言語は何となく分かったが、プログラムの作り方がわからない、あるいは我流で、というヘンテコな初心者プログラマーができてしまう。

ということで、そのあたりを踏まえた本を書きたいんですけど、という話をしてきたのだが、書名の話とかあまり出なかった。

・■えるC言語

これは商標とられているからダメなんですよね、多分。いや、■ならいいかもしれないが。

・役に立つC

何の役に立つかというと、啓蒙書というか、人間はこう生きるべきだ、という主張を訴えた画期的な本。

・楽しく書けるC

本当は「もっと気持ちのいいC」みたいなのがイイのだが、ココログのフィルタとか reject してしまうかもしれないので、あまりアダルトに走らない方が…。

・よく分からないC

これは、C言語というのがよく分からないという人に買ってもらって、読んだら分かるかというと、やっぱり分からない、というような本である。

・間違いだらけのC

このようなCのプログラムは間違っている、というような例を多数紹介して、どうすれば正しくなるのかを分かりやすく説明します、とか想像した人はおおはずれ。単にこの本の内容が間違っているだけという恐ろしいのを出そう、という話。なお、「間違いだらけのCプログラミング」という本が既に出版されているが、この本は、間違いをどうすれば正しく修正できるか、という当然のような有益な趣旨に沿った本なので、誤解なきよう。

Note

これってもちろん冗談なのだが、左ページに大嘘書きまくって、右ページに突っ込みというか修正しまくる、というような構成にすると、意外とイケるんじゃないか?

・間違いだらけのCのひみつ

さっきのは、まあこれを出すための伏線というか、気にしないでください。

・C言語によるデザインハターン

デザパタではなくて、破綻しているのである。だんだん入門でなくなってきたしネタ切れなのでここいらでヤメ。

ちなみに、Uちゃんをイラストにしたら女子高生ですよね、というあたりでは、意見は一致したような気がする。

打ち合わせ中に、味噌汁の話を出した。この話、最近よく使うのだが、ネットに書いてなかったような気がするので書いておく。

まあネタの一つでしかない。味噌汁、誰でも作れますよね、という話。単に味噌をお湯で溶いて具を入れるというか、それだけのことだが、おふくろの味になるには結構かかる。しかし、日本のどの家庭でも、味噌汁は作れる人がいる…ってのは甘いか?

プログラミングにもそういう要素があって、特に、要求仕様に沿ったプログラムを作る、という作業にそういう側面がある。言われたとおりのものを作るというのは、あいまいな要求を元にして自分で要求仕様を作り、実現するための部品を選び、システムを構築し…というような創造的活動に比べると、非常に簡単なもののように見える。というか、実際簡単だ。

ただ、それは誰でも即できるかというと、そんなものではない。結構コツみたいなものがあって、味噌汁の習得にどれ位かかると知らないが、言われたものを、特にその通り 作れるようになるには、やはり1～2年は、そういう作業に熟練することが必要なのだ。もしそういう経験がなければ、逆に、前述のようなクリエイティブな作業ができる人でも、言われたものを作ることができない、という奇妙なスキルになってしまうことがある。もっとも、そこから経験を積めば、短期間が習得できるとは思うが。

といった感じの話。

2006年4月25日

国民年金、払ってきました。年金問題も流行を過ぎたようだが、何か最近、受け取りの年まで生きていられるのだろうか、という気がしてきた。何となく。

そういう人に限って100歳まで生きる、みたいなオチならいいのだが。いや、いいのだろうか。

2006年4月24日

地獄少女を DVD-R にダビングした。最近何回か抜けたため、なかなか5回たまらなかったのだ。

基本的に、アニメは5回録画したらうまく1枚のDVD-R に入るので、 5回ためてからダビングするか、 2作品まぜて、3+2回にしてダビングするようにしている。もっと機械的に、古いものから順にやってしまってもいいのだが、とか思ったりする。

ちなみに、うっかり4回ためてしまうと、 5回ためようという力が働くらしい。

固定資産税を支払いに銀行に行く。三井住友限定なので、そこに行くしかないのだが、結構待たされてしまった。

謎の属性! シリーズ。第何回だ?

不明なプロパティ 'ine-height' が使用されています。
ソースファイル: http://www.sankei.co.jp/parts/css/snk-specific.css 行: 49

稲の高さかもしれない。

不明なプロパティ 'vvertical-align' が使用されています。
ソースファイル: http://www.sankei.co.jp/parts/css/snk-specific.css 行: 108

'text-align' プロパティの値をパース中にエラーが発生しました。ソースファイル: http://www.mext.go.jp/style_ns.css 行: 60

justyfy と書いてあるからだ。justify にすればこのエラーは消滅するはず。勉強不足だ > 文部科学省。

なお、フジテレビのトップページで

エラー: uncaught exception: Permission denied to call method Location.toString

と表示されるのがちょっと気になる。

とあるプログラムで、設定情報を外部ファイルに書く必要があって、やはり時代は XML というか、util.Properties とか使ったらダサいよな、とか思いつつ、2～3個の属性を外出しするのにわざわざ digester の出番もないか、とか思ったので、Properties でいくか…とか思ったのだが。

考えてみたら Spring Framework 使っているのに、オブジェクトは IoC していてプロパティだけファイルから読ませるというのは何だかなー、ということで、 applicationContext に beans の設定情報を書けば済むことに気付いた。余計なことをしてしまうところだった。

こういう構造があったと思いねえ。

    hoge() {
        if (大変なことになった) {
            異常時の後始末をする。
            return;
        }
    
        通常の処理
    }

これに、pre-process、post-process をかませたいのである。

    hoge() {
        pre-process();
    
        if (大変なことになった) {
            異常時の後始末をする。
            return;
        }
    
        通常の処理
        
        post-process();
    }

これは誰が見てもダメ。 return したら post-process を通らないのだ。ということで、中身をメソッド化するのが定説。

    hoge() {
        pre-process();
        hogeSubroutine();    
        post-process();
    }

    hogeSubroutine() {
        if (大変なことになった) {
            異常時の後始末をする。
            return;
        }
    
        通常の処理
    }

これはまあうまくいくし、きれいなものだ。ところが、処理の順序の制限があって、通常の処理よりも前に post-process を実行したい、というか、 post-process より後に、通常の処理をしたい、という話になった。通常の処理を上に持ってくるというのは杜撰すぎる。

    hoge() {
        pre-process();
        hogeSubroutine();    
        post-process();
        通常の処理
    }

    hogeSubroutine() {
        if (大変なことになった) {
            異常時の後始末をする。
        }
    }

異常時の場合も、通常の処理を通ってしまうからダメ。こういう時にはどうすると美しい? もちろん、こんな感じには書けるけど。

    hoge() {
        hogeSubroutine();    
        通常の処理
    }

    hogeSubroutine() {
        pre-process();
        if (大変なことになった) {
            異常時の後始末をする。
        }
        post-process();
    }

こんな場所に pre-process とか post-process が出てくるのはちょっとイヤかもしれない。

2006年4月23日

何となく体調がよくない。いろいろ面白い夢を見ているのだが、メモしないうちに忘れてしまう。

ちょっと長めの処理になってきたら、どの程度に分割すればいいとか、どの程度の数になったら別ファイルにした方がいいとか、そのあたりの感覚は、プログラムを数多く書いているうちに自然に身に付くようだが、これだという定量的なものが示せるかというと、なかなか決定打がないような気がする。

大昔の話なら、25行以内にしろという強引な主張をする人もいたのだが、最近はそういう主張は通用しないというか、意味が通じないだろう。 Java の「30秒ルール」のように、時間で区切るという手もある。こちらの方が意外と柔軟に解釈できるので、実践的かもしれない。ただ、バカみたいな所でコケると、3行のプログラムでも30秒ルールに抵触してアウト、のようなこともある。この時に「理解できないオマエが悪い」と言い切れるかどうかが勝敗を分ける。

高松が香川県にある、というのがパッと出てこなかった。

キーボードに落ちたホコリとか吹き飛ばすエアスプレー、最近使っていなかったためか、 VAIO BX の一部のキーが何となくひっかかる感じになってしまった。ということで、プシューしてみたら、何となく快適になったような気がする。

しかし、ホコリが外に飛ばされたように見えないのはどういうことなのだろう?

2006年4月22日

いろいろやることがあるので某所のオフィスへ。その前に、 TSUTAYA に DVD を返却しに行って、ミスタードーナツでドーナツを買って、セブンイレブンでお弁当を買って、ドラッグストアでティッシュペーパーとトイレットペーパーを買う。

巡回順序としては完璧なのだが、セブンイレブンで買う予定だった「チャーハンおにぎり」が無い。買い物にアクシデントはつき物なのだ。ということで、代替機として「ラーメンおにぎり」を買う。

何かやたら黒服の人が多いのだが、サバトでもあるのか?

電車の隣の座席で、お年寄りがお友達らしき人に携帯電話の使い方を説明している。着信履歴がどうとかいう話だが、携帯電話はもはや全員所持の時代になりつつあるのかも。

にしても、大声でバイブ、バイブ と言うのはちょっと違和感が…。「マナーモード」と言って欲しい。

急激にコメントスパムの量が増加している。今日1日で多分500個程度付いたような気がする。

2006年4月21日

相変わらず咳が止まらない。

ソニーの株価が6000円超えた。朝の「とくダネ」という番組で、小倉さんがソニーとαマウントの話をしていたが、カメラ戦略が原因というわけでもないか。

アメリカで PS2 の販売価格を下げるというニュースもあった。全世界で1億台出ているらしい。PS2。

「らんだむCGりんく」をそろそろ再開させたいのだが、データが古くなっているので、リンクのチェックをしてみた。

リンクチェッカーも、何年か前に作ったものではなく、最新の処理を使うように書き直してみた。つまり、apache の HttpClient を使う処理に置き換えた。おおむね問題はないのだが、以前から問題になっていたところはやはり問題である。つまり、

問題1。途中で connection timed out になるようなことがあって、殆どそこで処理時間が決まっている。つまりボトルネック。例えば、 1000サイトのチェックを行うのに900秒かかるが、このうち800秒は、10サイトの timeout にかかった時間。残りの 990サイトのアクセスは 100秒で実行できている。

これはシングルスレッドで順次処理するのではなく、マルチスレッドで実行すれば、ある程度回避できる。今回のテストは意図的にシングルスレッドで行っているが、以前使っていたリンクチェッカーは10スレッド使って実行するものになっていた。

問題2。「閉鎖しました」とか「移転しました」というサイトが多数ある。これらのページはレスポンスコードとして 200 OK を返すので、それで判断することはできない。ページの内容を解釈することが必要。

問題3。 META で指定している charset がおかしいページとか、そもそも指定されていないページとか、 HTML が不正で parse できないページとか、どう処理すればいいか?

2006年4月20日

猫を避けようとした車が事故って2名死亡、という話を「裏の戯言」に書いたが、もしかして黒猫?

VAIO BX だが、最近コミットチャージが 1GB を超えてしまうことが多い。見積もりを誤ったのか、使い方がおかしいのか…。

このシリーズ意外と面白いので勝手に続けてみたりして。 CSS の属性で JavaScript コンソールに出てくるナニをネタにしてしまおう、という話である。名付けて、 謎の属性!。

不明なプロパティ 'boder' が使用されています。
ソースファイル: http://www.nikkansports.com/css/main.css
行: 4046

不明なプロパティ 'matgin-top' が使用されています。
ソースファイル: http://www.nikkansports.com/css/main.css
行: 7479

不明なプロパティ 'font-sigze' が使用されています。
ソースファイル: http://japan.cnet.com/style/2006/c/c_css.css
行: 1567

不明なプロパティ '　font-weight' が使用されています。
ソースファイル: http://japan.cnet.com/news/sec/story/0,2000056024,20102012,00.htm
行: 0

最後のは、「f」の前に空白「　」があるのだ。

電車の中で、たっていた女性が急に床に座り込んだ。誰かが「大丈夫ですか」と言った。私も経験があるが、どうみても大丈夫な訳がない。でも、この女性は「大丈夫です」と言っていた。標準プロトコル通りである。

2006年4月19日

mixi のレイアウトのアンケートの締め切り日なので、とりあえず回答してみた。こういう余計なことを書いたのは私です。

レイアウト云々以前の問題として、不正な CSS を修正した方がいいと思う。でないと、意図したデザインが実現されていない可能性がある。
例えば mixi.css にはborder:1 solid #F2DDB7のような表現があるが、 border:1は CSS としては誤りで、数字の後に px などを付ける必要がある。
うっかりミスは仕方ないと思うが、 JavaScript コンソールを表示させるだけで確認できるようなエラーがいつまでも残っているのは、開発プロセスがおかしい証拠ではないだろうか? 公開前には http://jigsaw.w3.org/css-validator/ などによる CSS の検証を行うのが当然だと思うし、それで修正できない問題ではないと思うのだが。

まあでも私もそう頻繁に CSS の validate なんかしないし。裏裏に書いたように、 So-net のナニには pargin-top というプロパティが出てくるし、あえて書かなかったが 20周年だとかいう某大手プロバイダ(ですよね?)だって、 font-sie とか heigth というプロパティを平気で使っているわけで、開発したら終了、テストも検証もしないで問題が発生してから対応する、というのが現在の日本のWeb開発の真の姿なのかもしれない。

教えてあげないのかって? ええ、言いましたとも!

なぜか知らんけど伝わらないのだよ。あ、でも So-net はまだこういうの連絡したことないから、メール送ってみようかな。

キーパーソンという表現を最近よく見かけるのだが、 English 的には keyman と key person は違う意味を持っているのだろうか?

2006年4月18日

書店に C MAGAZINE を探しに…ってウソだな、ここ数年そんなことした記憶ない罠。

ということで、「あっぱれご意見番」を追加しました。とりあえず月1度書くという習慣はできているのだから、途切れさせないようにしたい。

盗撮の報道とかで、「○○にあるまじき行為」というような責任者のコメントを何度か見かけたのだが、盗撮って別にどういう職業だからあるまじき、とかいう話じゃないような気がする。

昔は聖職とか、公僕といった言葉もあったのだが。って今でもあるか。

蟹は自分の甲羅に合わせて穴を掘るといいますが、何か考えるときに、自分の想定できる範囲内でそれを想像するのは仕方ないとしても、それが全てであるように思い込んでしまうというか、想定外のケースがあることを想定しない、という人が最近は結構多いんじゃないかな。

UI の世界だと「ユーザーはこう使うだろ」とプログラマーが勝手に想像してしまうとか、そういう有名な失敗例があるわけだが。

新庄、今シーズンで引退かぁ。そういえばプロ野球、見てないな、今季は。

2006年4月17日

早朝から大変な騒ぎである。まあ何とかなったが。「5分程度でいきます」というタクシーが30秒で来たのは謎。

パスワードを設定したのでメールで連絡しようとしたが、やはりメールにパスワードを書くのはまずいだろ。

ということで、認証つきの個人サイトにパスワードを書いて、そこを見てくれというメールを出そうとした。でも、そのページを見るにはパスワードが必要だ。ということで、そのページを見るためのパスワードをメールで…

これでは埒が明かないので直接知らせに行った。

2006年4月16日

昼飯は久しぶりに回転寿司へ。自転車で行ったら通り雨に遭遇したのだが、着いたら結構混んでいた。

はまちの注文が1回ロストしたが、おおむねok。

最近のブログの管理ページは JavaScript が on でないと使えなかったりする。 JavaScript を on にしておくと、コメントスパムとかトラックバックスパムの飛び先を見るときに、何か不審なことがあれこれ裏で実行されていて面白すぎるのだが、ココログの場合、JavaScript が off でもコメントを公開する処理ができる裏技がある。

JavaScript が off だと、管理ページのコメント一覧を表示して、チェックボックスをチェックし[公開]ボタンを押しても一向に公開される気配がない。チェックボックスの右の「コメントの内容」のところをクリックすると、コメントを編集する画面が表示されるが (JavaScript がオンだと popup が出るのでこの画面にならない)、画面下の「公開」ボタンを押しても何も起こらない。

そこで JavaScript off のときの裏技。一覧画面で表示されている「コメントの内容」のところのリンク URL をブラウザにコピーする。このURLは、

https://app.cocolog-nifty.com/t/app/weblog/post?__mode=edit_comment&id=xxxxxxxx&blog_id=yyyyyyyy

のようになっているので、この太字の部分を編集して次のようにする。

http://app.cocolog-nifty.com/t/app/weblog/post?__mode=list_comments&confirm_approve=1&confirm_id=xxxxxxxx&blog_id=yyyyyyyy

つまり edit_comment& という文字列を list_comments&confirm_approve=1&confirm_ に置換する。すると、メールで送られてくる承認用の URI と同じ形式になる。

ちなみに、メールが来た承認用 URI をブラウザで開くと、「このコメントをブログで公開しますか」というページが開く。このコメントというのがどれなのかさっぱり分からないが、とりあえず「公開」を押すと、メールで通知されてきたコメントを公開できる。これは JavaScript が off でも ok。

So-net blog もコメント削除のときに JavaScript が off だと消せなかったけど、そっちはどうすればいいのか謎。

近所のスーパーのポイントカードを lost したので、再発行の手続きについて尋ねてみると、再発行の場合 105 円かかるので、もう少し探してみてはどうか、とか言われた。

Thunderbird の fishing mail 判定ってどうやっているのだろう? 割と本物が簡単にひっかかるような気がするのだが。

2006年4月15日

新宿で修理を頼んでおいた時計を受け取って、例によって京プラのラウンジで1000円コーヒーを飲んで一服。高いのだが、おかわり自由というのと、無線LAN が使えるということで、そのあたりのトータルコストで考えるとつい使ってしまう。近くにもう少しお安く使える MZone スポットがありそうなものだが。

あまりお行儀のいい話ではないけど、京プラのラウンジ、隣に座った人の会話を聞くというのも一つの目的で、かなり面白い。特にここのラウンジは、お見合いのカップルっぽい人との遭遇率が高い。笑っちゃいけないが、笑える会話をつい聞いてしまうようなことがある。

そういえばこの前のどう考えても会員権系のセールスの勧誘、あれどうなったのだろ?

2006年4月14日

今日は重要な打ち合わせがあるので休めないのだが、何とか昼飯が食えるあたりまで体力回復したので強行。

2006年4月13日

風邪っぽいのを無理して動いたのが原因だと思われるが、体調は最悪を通り越して、夕食時には「食えない」というような状況に。とにかく茶碗半分程度を腹に入れて、薬を飲んで、寝る。

ロンドンにあるセルフリッジという百貨店が、 85ポンドの高級サンドイッチを発売したというニュースがあった。素材に和牛、ファアグラ、トリュフなどを使用しているという。

和牛って高級食材なのですね。

2006年4月12日

コラムのページに「フィンローダのあっぱれご意見番」 2006年4月分を追加。書店に今出ている分だ。これで連載終了というかC MAGAZINE が休刊だから、次からのスケジュールをどうしよう、みたいな話が発生する。

とりあえず、18日に次の分、という目標で動く予定。

2006年4月11日

咳が止まらない。バグも。

ルータの調子がよくないというので見に行った。負荷かけすぎという説があるのだが、何も検証できていない。とりあえず、負荷をかけると途中で無反応になるのは分かったが、それでどうだ、という話になってしまう。

2006年4月10日

最近、ココログに付くコメントだが、二重に投稿される確率が急増している。投稿されたものを承認するまで表示しない、という設定にしたことが影響しているのは確実だが、「投稿できました」というようなページが表示されていたら、ここまでヒドイことにはならないと思う。

まあ別に二重や三重に投稿されても私はかまわないので、どうでもいいのだが、それよりも、多分コメントそのものが減っているのではないかと。ココログの自動承認機能はまだ動いていないので (登録されているユーザーは無条件で承認するみたいな)、早く完成させたいのだが、ちょっといろいろスタックに積みすぎていてタスク切り替えだけでCPU使い果たしている状態。

阪神の金本選手。 904試合フル出場の世界新記録を昨日達成している。その記事を見て、これは面白いと思った。

究極の目標は、１度途切れた後の１シーズンにフルイニングに出ること

今、「裏の裏ページ」というのが毎日更新中なのだが、これが途切れた後にどれだけ続けられるか、というのを考えてみた。ちょっと想像できない。

昔、NIFTY SERVE というパソコン通信があって、そこにプログラマーズフォーラムというコミュニティがあったのだが、そこで連続発言をしていたときには、途切れた後がバタバタと訳の分からない感じになってしまったような気がする。というか、何日連続で発言したか、よく分からない。

ある程度毎日書いていると、毎日書いているということ自体がモチベーションを押し上げる一つの要因になって、なかなか止められなくなってしまうらしい。

このページだってゴテゴテしているのでキサマに言って欲しくはないと言われそうだが、最近のブログ、バナーとか広告、多すぎると思いませんか? デザイン的に、一番見せたいところが奥に沈んでしまって、何か違うような気がする。

2006年4月9日

4月7日に書いたココログの XHTML invalid の件、 1時頃には直っていた。スタッフのブログにはトラックバックしたが、正式にサポートにメールを送った訳ではないので、そろそろ連絡した方がいいかと思ったら、意外と早く解決したようだ。

裏裏のトップページというか、実際全ページに出てしまうのだが、 w3c のバナー、一時的に削除した方がいいかと思っていたが、直さずに済みそうだ。

mixi の記事に「&」と書く方法。「&」と書いたら確認ページで「&」にされてしまう。そこで、「&amp;」と書いてみたら確認ページで「&」になるのだが、投稿したら「&」になってしまう。ということで、

&amp;amp;amp;

と書いてみたらうまく行った、みたいな。

というか世界が間違っているような気がする。

PMD で system.out.println がエラーとみなされる件。いや、エラーとみなされるのは基本的にはokというか、望ましい。例外時にどうすり抜けるのがいいか、という話。こんなコードがある。

	private void outputResult(String calendar, String title, ArrayList list) {
		System.out.println("<table>\n");
		System.out.print("<tr><td valign=\"top\"><span style=\"font-size: 200%;\">");
		System.out.print(title);
		System.out.println("</span></td>");
		System.out.print(calendar);
		System.out.println("</tr>");
		System.out.println("<tr><td colspan=\"2\"><div>");
		System.out.println("<hr>");
		insertBody(list);
		System.out.println("</div></td></tr>");
		System.out.println("</table>\n");
	}

もちろんこれは結構ものすごい事になる。赤が付きまくる。では全部 // NOPMD を付ければいいのかというと、いいのだが、面倒だということで、こんなことをしたくなる。

	private void outputResult(String calendar, String title, ArrayList list) {
		myPrintln("<table>\n");
		myPrint("<tr><td valign=\"top\"><span style=\"font-size: 200%;\">");
		myPrint(title);
		myPrintln("</span></td>");
		myPrint(calendar);
		myPrintln("</tr>");
		myPrintln("<tr><td colspan=\"2\"><div>");
		myPrintln("<hr>");
		insertBody(list);
		myPrintln("</div></td></tr>");
		myPrintln("</table>\n");
	}

これで myPrintln の中身をこうすれば完成。

    private void myPrintln(String message) {
        System.out.println(message); // NOPMD
    }

この例だと myPrint も用意しないといけないが、ここで問題は、「これって PMD に踊らされている?」ってことだ。明らかに、これは PMD の都合で付けたコードのような気がする。

2006年4月8日

何かしらんけどサーバー死んだよというメールが。

うちの pc としては DELL の電源入らなくなったというのがまだ放置してあるが、それ以降は故障していない。あー、DELL のはそろそろ何とかしないと保証期間が…。いや、もしかしてもう過ぎているのかな?

自分宛に送ったメールを thunderbird がフィッシングメールだと判定した。まあいいんだけど。

2006年4月7日

あー、ココログの話だが、ついにやられたというか、トップページが XHTML invalid にされてしまった。しかも原因はど素人でなけれはよほど疲労が蓄積しているのか、 & と書くべきところを & と書いているとか、 img が閉じていないとか、あからさまに基本的なミスか typo に近いものだ。

メールする気力も出ないが、一応、裏裏のネタにはしておいた。これが続くようであれば、ココログから XHTML valid のロゴを外さないといけないな。

というか、別にアクセス解析なんていらないんですけど。私は。しかも画像埋め込み系解析という、古典的というか、誤差の出まくる集計するとは、どういうソリューションを目論んでいるのかさっぱり分からないのだが。

Note

画像埋め込み解析: 前世紀に流行した裏技的アクセス解析方法。ページの中に見えないサイズの画像データ (webbug) を配置しておき、その画像データのアクセス状況によってページビューを調べる、というものである。ユーザーに知られないような方法でこれを行う場合は、プライバシーの侵害や個人情報の不正な収集とみなされることもあり、最悪の場合、google神の怒りに触れて、検索対象から外されることもあると噂されている禁断の技。

確かにこの手法は、サーバーのログが取得できない場合に別のサイトからカウントを知りたいとか、その種のどうしようもない状況においては多少は意味があるかもしれない、というか、仕方ないのでそのような手法を使うことはありますが、まさか、ココログのアクセスログがココログを提供しているベンダーにない、なんてことはないだろうから、そもそもサーバーに残っているアクセスログを単純に集計すればいいと思うのだが。これなら誤差もないし、正確なページビューが分かる。

わざわざ余計な画像データを参照させてトラフィックを増やしたあげくに、誤差のある集計結果を得るというのは、いまいち芸がない。もしかして、クローラーとか検索ロボット対策にはなるのかな、その種のリクエストが画像を無視する、という前提があればだが。まあでも普通はクローラーはドメインとか IP で振り分けると思うのだが。

とりあえず XHTML valid になってくれたら、画像だろうが何だろうが、気にしないけど。あ、でも google からココログが全てある日突然消滅した、みたいなのはイヤかも。

ココログがどうもナニなので、別のブログをちょっと調べようという気になっていて、 Seesaa ブログに登録してみた。 http://phinloda.seesaa.net/ だ。 URI も分かりやすいし、いいかも。

と思ったのだが、ここも XHTML invalid というか、ココログよりもひどかった。orz

CNET Japan がメンテナンスでトラブルらしい。 05:00 にメンテナンス終了の予定だったが、 10:00 頃に見ると障害発生というページになっていた。

2006年4月6日

Ameba blog の「混雑しています」というページを久しぶりに見たような気がした。リロードしたら表示できたが…。

打ち合わせで西新宿に行ってきた。ジョナサンに入ろうとしたら、混雑時のパソコン利用禁止、とか書いてあって、ビビったのでスルーして、ドトールで待ち時間にメールチェックとかした。

混雑時といわれてもよく分からないので、現在okなのかngなのか、というのを掲示して欲しい。

Java + PMD。次のようなソースに警告が出る。

    Set resultSet = null;
    for (int i = 0; i < list.size(); i++) {
        if (hoge(list.get(i)) {
            if (resultSet == null) {
                resultSet = new HashSet(); // これがいかんみたいな
            }
            resultSet(list.get(i));
        }
    }

警告は、

Avoid instantiating new objects in loops

なのだが、いったいどうしろというのだろう? コードの目的を蛇足しておくと、処理対象がひとつもない場合には new したくないのである。

そのための「// NOPMD」ですか。

Note

// NOPMD
というコメントを書いておくと、PMD が無視してくれるので、そこに限って警告もPMD的エラーも出ない。ただし、PMD はコードのクオリティをナニするために使うのであるから、 NOPMD を多用するのは本来の姿を見失っているような気がする。しかし、例えば画面に何か表示するコンソールアプリケーションを書くときに、「System.(out|err).print is used, consider using a logger.」なんて警告がいちいち出るのもシャクだというか、ここは System.out.print でいいのだぁ、というような時もある。そういうときは堂々と NOPMD を使えばいいのだ。

2006年4月5日

コンビニから出たら、黒人のかなりセクシーな若い女性と目が合った。こういうときは「くろいめの…」というアレを思い出したりするのだが、とりあえず、この女性はニコッと笑って、コンビニの傘立てに立ててあった傘を取ってそそくさとその場を去っていった。

その後をダッシュして追いかける日本人(と思われる)女性、一人。

追いついて何か口論している。傘を奪った。つまり、この黒人は要するに傘泥棒で、それを見ていた持ち主が追いかけていって捕まえたらしい。

今日は午前中、途中から雨が降り出したから、こういう光景もよく見られるのだろう。

次のようなコードがある。なお、Exception の処理とかは省略してある。

        FileOutputStream fos = null;
        ObjectOutput oos = null;
        try {
            fos = new FileOutputStream(fileName);
            oos = new ObjectOutputStream(fos);
            oos.writeObject(someObject);
        } catch (FileNotFoundException e) {
        } catch (IOException e1) {
        } finally {
            IOUtils.closeQuietly(oos);
            IOUtils.closeQuietly(fos);
        }

IOUtils は Jakarta commons IO を使っているのだが、実はこれはコンパイルエラーになる。 IOUtils.closeQuietly() に、ObjectOutput は渡せない、というのだ。そこで、次のようにするとエラーは発生しないし、プログラムとしても正しい。

        FileOutputStream fos = null;
        ObjectOutputStream oos = null;
        try {
            fos = new FileOutputStream(fileName);
            oos = new ObjectOutputStream(fos);
            oos.writeObject(someObject);
        } catch (FileNotFoundException e) {
        } catch (IOException e1) {
        } finally {
            IOUtils.closeQuietly(oos);
            IOUtils.closeQuietly(fos);
        }

これはどうなのか、オブジェクト指向的にどうなのか、うるさい人に聞いてみたいような気がする。

蛇足しておく。 interface ObjectOutput は DataOutput を継承した interface である。 class ObjectOutputStream は、OutputStream を継承している。 closeQuietly に渡せる引数の種類は、 InputStream、OutputStream、Reader、Writer の4種類なので、 ObjectOutput を渡すことはできない。だから、前述のように oos は ObjectOutputStream としておかなければならない。しかし、 ObjectOutputStream としなくても、次のように面倒な書き方をすることはできる。確か、この場合にはエラーは発生しなかったはず。

        FileOutputStream fos = null;
        ObjectOutput oo = null;
        try {
            fos = new FileOutputStream(fileName);
            oo = new ObjectOutputStream(fos);
            oo.writeObject(someObject);
        } catch (FileNotFoundException e) {
        } catch (IOException e1) {
        } finally {
            if (oo != null) {
                try {
                    close(oo);
                } catch (Exception e) {
                }
            }
            IOUtils.closeQuietly(fos);
        }

FAX で送るべき至急の書類があったので送ったのだが、どうもうまく受けられないらしい。送れないものは仕方ないから郵送で送ることにしたが、どうも FAX のインク切れらしい。送信先は機械って何、というレベルなので、別に原因があるかもしれないが。

ココログに upload した画像のサイズが 800x600 になっていると教えてもらった。そんなサイズに変更した覚えはないので、ココログの仕様が変わったのかと思ったのだが、かなりしっかり見たつもりなのに、そういう仕様になったという話は見当たらなかった。ということは、バグじゃないのか?

もしかして、最近のココログの重い原因って、画像を登録するときに無条件に全部リサイズしているからじゃないのか? 【妄想】をっと、さっきノートpcの電源がいきなり切れてしまったのでIMEの辞書が壊れたか。登録したつもりの字が出てこない。

まあ、とりあえずオリジナルサイズの画像を わざわざ手作業で別途 upload して 期待通りの画面になるようにしたが、何でこんな勝手なことをされるのかわからん。というか、これってバグですよね?

So-net のブログの方に、ブログランキングとかいうところからコメントが付いていたのを削除した。興味がない訳ではないのだが、この spam 問題が社会化している昨今、同じコメントを4つも付けてくるような相手にコンタクトするのはリスクが高すぎると判断したのである。

トイレの個室に入ったら携帯電話が置いてあったのだが、何かの罠なのだろうか?

トラックバックを見ていると殺伐とした空気があり、パソコン通信時代の心の温かさがインターネット時代になって失われつつあるのではないかと少し心配

(「さよなら、パソコン通信オフ」が開催。ニフティ社長なども出席より引用)

殺伐としたパソ通のフォーラムというのは、こんなものではござらん。

2006年4月4日

PMD の警告にこういうのがある。

AvoidReassigningParameters: Reassigning values to parameters is a questionable practice. Use a temporary local variable instead.

この警告は、例えばこのようなコードで出る。

    public void hoge(String string) {
        if (string == null) {
            string = "default.value"
        }
        
        foo(string);
    }

警告を消すには、次のように変更すればいい。

    public void hoge(String string) {
        String str = string;
        if (str == null) {
            str = "default.value"
        }
        
        foo(str);
    }

あるいは、こう。

    public void hoge(String string) {
        foo(string == null ? "default.value" : string);
    }

最後のはともかくとして、その前のが問題である。この書き方は、最初のものに比べてどのように優れているのか? 保守性を考えれば明らかだろうか? 可読性を考えると、最初の書き方にもメリットはある。変数の数が増えれば、それだけ readability は低下する。つまり、最初の書き方の方が安全だという考え方もあるはずなのだ。

2006年4月3日

頭痛い。久々に。

先日紹介したデスノート。 Amazon は売り上げが0円の状態が続いているのだが、試しにリンクしてみる。

どういうジャンルなのかというと微妙。死神が出てくるというあたり、ホラーとかオカルトっぽいが、内容的には心理戦なので推理系か、というとそうでもないような気がする。

そもそも、このマンガは、キラという悪(だと思うが異議はあるだろう)と、エルとその後継者という善が戦う、という構図になっているのだが、そもそも、その大前提となっている、「キラを日本の現行法で裁ける」というあたりがいきなり怪しい。もちろんマンガなのだから、そういう細かいところはどうでもいいので、そこにひっかかってしまっては先に進めないわけだが、確か現在の日本の法律では、例えば、「呪い殺す」というのは無罪だったと思う。実際に呪いのわら人形で誰かを殺したとしても、その因果関係が法的には認められないという話だ。

とにかく読んでいて疲れるというか憑かれるマンガである。普通のコミックの3冊読む程度の時間をかけないと1冊を読むことができない。ジャンプ・コミックスというから少年マンガのはずなのだが、これは小学生あたりではなくて、多分もっと上の年齢の人がハマると思う。

2006年4月2日

新宿。時計を受け取りに行ったのだが、結構なお値段かかってしまった。身の回りのものはかなりテキトーなもので揃えているのだが、時計はちょっと高いのでこういうことになる。

2006年4月1日

世の中はエイプリルフールというナニだが、何かありましたか。そうですか。

バレンタインデーとかホワイトデーとか、商売に何とか結びつけようというその種の業界の努力にはすさまじいものがあるが、エイプリルフールには大福を食べようとか、そういう強引な無茶をする業界はまだないか。

任意継続になっていた健康保険が切れるはずなのだが、土日はどういう扱いになっていたのか分からない。とりあえず病院に行くようなことがなければいいはずだ。

この前病院に行って分かったというか当たり前なのだが、病気や怪我というのは曜日を選んでくれないから、基本的に毎日まんべんなく発生するような事象である。しかし、病院は土曜に半休、日曜に全休というところが多い。これは需要と供給を考えるとおかしいのではないだろうか?

逆に、土日だから行きたい、というような需要の方が多いような気もする。特に慢性病の初期症状のような疑いがある場合とか、何となく体調がおかしいというようなのは、平日に会社や学校を休んで行く、というのはなかなか難しいはずだ。