• 痛いニュース(ﾉ∀`):グリーンピース、“鯨肉横領疑惑の証拠品”として運送会社倉庫から鯨肉を無断で持ち出し、食べる
• 時事ドットコム：宅配荷物紛失で被害届＝環境団体持ち出しの鯨肉か－西濃運輸
• グリーンピースによる宅配便窃盗事件まとめWiki - トップページ
• シー シェパード　海賊 - Google 検索
• カルト - Google 検索

住友電気工業株式会社｜プレスリリース 2008年　社内オフィスソフトに「OpenOffice」を全社レベルで活用

see also:

• OpenOffice.orgを導入してみた (2006/1)

paypalのサイトの日本語版ができたのがたしか2007年3月ごろ。そろそろ「Paypal支払い対応」をうたったECサイトとかが増えてきてもよさそうなころあいなのだが、あんまし見かけない、、、のは気のせい？

取引手数料 - 日本海外支払い - PayPalによると、料率は以下のとおり。 楽天のR-Card Plusの料率は3.6%らしい（※1）から、遜色なさそう。

ドルとかユーロとか通貨変換がからむ決済はさておき、 日本円←→日本円という普通の決済になんかしらの制限てあるんだろうか？ 日本だと銀行法に触れるの触れないのという話は聞いたことがあるようなないような。

アメリカンな小切手文化、カード文化が日本人に合うとか合わないとかいう話はいまさらどうでもいい。

単なる知名度の問題なの？

※1：楽天の出店案内のページのどこをさがしてもクレジットカード決済の料率について記述が無い理由はまあアレだ。(笑)

「@」でエラー抑制すると PHP が遅くなるという噂について(a++ My RSS 管理人ブログ 2008/5)

でもね、よく考えよう。100万回ループさせたら9秒の差が出ました、って、、、 100万回とか1000万回ループするfor文なんてものを書くのは実際の開発現場においてよくあることなんだろうか？（いやもちろん、実験だからそういう数値を使ってることは承知のうえで）

Webシステムの画面として稼動するスクリプトにおいてそんなものすごいループをしなければならない状況になったことは少なくとも筆者はない。もしそうなったとすればそれはその前段階で何かがおかしいと思ったほうがいいんじゃなかろうか。

じゃあやっぱり百万オーダーのレベルでループしなければならない処理なんてありえないよね、というとそうでもない。典型的なのは、バッチ処理だ。全ユーザー／全データ／全ファイル／全商品の情報にアクセスしてなにか定型処理をするとか、そういうの。

でもね、そんな大量処理がたとえば10秒以内といった短い時間で終わることなんてハナから期待してない／期待されてないケースがほとんどだ。それに、大量の処理においてボトルネックになるのは、エラー出力の抑制処理なんかじゃなく、DB上でのSQLによる検索、更新処理とか、もっと単純にファイル読み書きのディスクI/Oスピードとか、そういうのだろう。

そんな状況にあって、「隊長！@マークによるエラー出力抑制を全部書き直したら30分の処理が29分50秒になりました！」なんて言われても、よくやったほめてやる！なんてことにはなりにくい。

PHPにおいて@によるエラー抑制はほどほどに、という論は、処理スピード云々の話ではなくエラー処理はどうあるべきか？の話だ。 javaでtry{}catch{}構文使ってるけどcatch{}の中身が空っぽだったりするソースコードを見かけたとき「せめてそこでエラーログを吐くくらい書かないとあとあとバグ退治しづらいぜ」という話になるのと似たような感じ。

ブログに書いてある箇条書きが額面どおりとは限らない。 日本人が日本語で書いてるブログだろうと 外人が英語で書いたブログだろうとそれは同じ。

本当に大切なことを見失わないことが肝要だ。

要するに、こんなことが多発している（た）のだそうだ。

1. とあるEC系Webサイトのサポート窓口に「おたくからのメールが届いてないんだけど！」とユーザーからクレームがはいる。
2. こっちのメール送信機能は正常稼動していることを確認。そこでエラーバウンスメールのスプールをさらってみると、 案の定、該当者あてのメールが戻ってきている。こんな感じ。

   Hi. This is the qmail-send program at excite.co.jp.
   I'm afraid I wasn't able to deliver your message to the following addresses.
   This is a permanent error; I've given up. Sorry it didn't work out.
   
   <*********@excite.co.jp>:
   user is over quota

   はいはい。over quota ＝ メールボックスが容量一杯。
3. 別なユーザーからまったく同じ苦情が入る。
4. １～３が不定期に延々ずっと繰り返される。

簡単に言うと、上のような状況を打破するために、そのサイトではメールアドレスの入力欄に ***@excite.co.jp と打ち込むとお断りのメッセージを出すようにしてしまったそうだ。「代わりにHotmailがいいですよ」というアドバイスまでつくらしい。笑

大胆な、と思ったけど、そのサイトにおけるexciteメールの利用者数がたいした数じゃなくて売り上げ影響ほとんど無いわりに無駄なサポートコストが大きいので、そうした、とのこと。なるほど、合理的である。

そもそもなんでこんなことが起きるのか？話は簡単だ。

1. exciteメールのメールボックスの容量はたったの4Mバイトしかない。
2. excieメールは「メールボックスの容量が一杯ですよ／もう90%超えてますよ／古いメールは消してくださいね」という風な警告メッセージを表示する機能がとてつもなく貧弱である。

下記が、エキサイトメール　- ヘルプ -の抜粋。40メガか、4ギガの見間違いかと思ったよ。(笑)

どんな機能があるの？

4Mの容量、POPメールの受信、SPAM防止、フィルタリングなど便利な機能をたくさんご用意しております。

ちょっとした写真つきメールをもらったり、メールマガジンを何通か受け取ったりすれば、4メガなんてすぐだ。そのとき、どうなるか？実際にexceiteメールで試してみた。

4メガ中2メガ以上を消費した状態→表面上何も出ない。

添付ファイルつきのメールを何通か送ってみたが、画面上は変化が現れない。

ただし、「メールボックスの管理」というリンクでは容量の状態が一応見れる

さらに何通か送り込んで、容量の95%を消費した状態。

これでも、通常見る受信ボックス画面では何も変化をつかめない。

容量の99%を消費した状態。もうこの状態では何を送ってもエラーで返されてしまう。

しかしそれでも、通常見る受信ボックス画面では変化をつかめるメッセージ等が何も出ない。 あまりにも不親切で、4メガの容量しか持たないWebメールとしては最低最悪なユーザビリティだ。

ちなみにHotmailやYahooメールでは、ユーザーが常に見れる位置にメールボックスの容量メーターが表示される。こんな感じ↓

90%を超えると赤くなる。わかりやすい。↓

そもそも1ギガの容量を使いきるユーザーもまれだろう。(笑)

メール、特にWebメールは、インターネットユーザーにとってごくごく基本的なインフラ的サービスだ。メールサービスを提供する側とそのユーザーという二者間に問題はとどまらない。メールをやりとりする第三者の相手がいての話だからだ。

だから、冒頭に挙げたWebサイトのような事態が発生する。 無料サービスなんだから、などという言い訳が通用するサービス領域ではないのだ。 メールというものは。

いまどきたったの４メガ。しかも容量使い切ったことにものすごく気づきにくい。 そんな中途半端な品質でしかサービス提供できないのなら、むしろ「やめちまえ」と。

基本的なサービスにおける基本的なユーザービリティの軽視が、見えないところで混乱を呼ぶだけでなく、じわりじわりとユーザーを減らしてゆく恐怖、の一例でした。

時刻を表現したい場合は　hh:mm:ss たとえば
11:25:30

日本時間であることをわかりやすく明記したい場合は
11:25:30+09:00
もちろんグリニッジ標準時からの時差がプラス9時間、の意。 (「JST」と書けとかUTCならZだとかそういう細かい話は省略。）

日付と時刻を両方表現したい場合は
2008-05-16T11:25:30+09:00
つまり日付と時刻をTでつなげる。

これが世界的スタンダードとしてISO8601とRFC3339に定められた日付と時刻の表現方法。 有名どころの言語やらデータベースその他ミドルウェアはすべてこれに沿った表記を解釈し入出力できるようになっている。 プログラマのみなさんは覚えておいて損はないというか絶対覚えておいたほうがいい。 できればプログラマに発注する側の人間も覚えておきましょう。

日付がスラッシュ区切り（YYYY/MM/DD）だったりするソフトやらライブラリやらが巷に散見されるが、まったくおすすめできない。実は筆者がいまそういうコードを使う羽目になっているのだが、使いづらいのなんのって。。。

日付と時刻という、どう書いてもよさそうな超基本的データフォーマットであっても、きちんとスタンダードに沿うことが、ソフトを使いやすく＆使われやすくするための第一歩だ。

see also:

• ISO 8601 - Wikipedia
• RFC3339
• 日付の表記に関するノート

追記：

日付と時刻をTで結ぶ方式は普及していない[文系大学的IT系の悲哀]という記事が出ている。 経験則というものは人それぞれなのでそれはそれでかまわないが、「PostgreSQLはYYYY-MM-DDTHH:MM:SS 形式を考慮してない」といった明らかに誤った認識はpgsqlファンとしてはつっこまざるをえない。

ものはついでなので、いくつか例を挙げて説明を加えておこう。

2008-05-16T13:45:23 よりも 2008-05-16 13:45:23 のほうが読みやすくね？

同意である。人間の眼の観点から言うとそう。 しかしここではどっちかいうとコンピュータ視点であり、かつできればの範囲で人間にもわかりやすく、というのが主眼であることをご理解いただきたく。

それから、日付と時刻をTでつなぐということ云々よりも、 年月日は/じゃなくて-でつなぐものだ、ということを知らなかった人のほうが多いんじゃないかと思われる。

なお、「Ｔ」なんてよくわかんねーからやだ、と言っている人のブログのrssフィードには <pubdate>2008-05-16T13:45:23</pubdate>とあったりすることを忘れてはならない。あなたもお世話になっているのだ。

JavaScriptはiso8601形式の日付を理解できない

そうなんですよ。なんでそんなことになったのやら。忘れてたとしか思えん。

var timestamp = Date.parse('2008-05-16T11:25:30+09:00');
window.alert(new Date(timestamp));

var timestamp = Date.parse('2008/05/16 23:59:59"');
window.alert(new Date(timestamp));

でもそれじゃ不便だよねってことで、 [JSAN] Date.W3CDTF - ISO-8601日時フォーマット対応JavaScriptクラスなんてのを作ってる人もいる。 筆者もお世話になってる。

なお、ECMAScript(JavaScriptの仕様の土台？というべきか）の次のバージョンではiso8601形式がサポートされることになっている。

http://www.ecmascript.org/es4/spec/overview.pdf より抜粋

The Date class has been upgraded in several ways. Chiefly, there are methods for producing and consuming ISO-8601 format time strings, and Date instances keep track of their age with nanosecond precision and can be used as low-cost high-precision timers.

EcmaScriptバージョン4を搭載するブラウザが普及するのって何年後よ？とかいう野暮はいわない方向で。

perlの場合

とりあえずHTTP::Date使ってみた。

$ cat test.pl
#!/usr/bin/perl
use HTTP::Date;
my $t = HTTP::Date::str2time('2008-05-16T08:23:45+09:00');
print HTTP::Date::time2iso($t)."\n";

$ perl test.pl
2008-05-16 08:23:45

PHPの場合

$ cat test.php
<?php
echo date('c',strtotime('2008-05-13T02:45:23+09:00'));
?>

$ php test.php
2008-05-13T02:45:23+09:00

M$製品の場合：

Ms-Officeの寡占状態にあるデスクトップのビジネスアプリ市場において標準への準拠なんてされるわけがない(笑)。当然、ExcelやAccessでは2008-05-16T08:23:45+09:00なんてのは入力しても期待通りには動かない。

が、oracleやらmysqlやらpostgresqlに押されっぱなしのサーバー市場においてはMSは標準という錦の御旗に従順である。

ISO 8601 形式 - SQL Server 2005 Books Online (2007 年 9 月)

Microsoft SQL Server 2005 では、ISO 8601 形式を使用して日付と時刻のデータを指定できます。 形式は次のようになります。
yyyy-mm-ddThh:mm:ss[.mmm]

PostgreSQLの場合

testdb=> select cast('2008-05-13T12:04:56+09:00' as timestamp with time zone);
      timestamptz       
------------------------
 2008-05-13 12:04:56+09
(1 row)

mysqlの場合

mysql> select cast('2008-02-03T04:23:45+09:00' as datetime);
+-----------------------------------------------+
| cast('2008-02-03T04:23:45+09:00' as datetime) |
+-----------------------------------------------+
| 2008-02-03 04:23:45                           | 
+-----------------------------------------------+
1 row in set, 1 warning (0.00 sec)

こうしてみると、YYYY-MM-DDThh:mm:ss+09:00の形式の入力には対応しているものの出力には対応していないケースが多いようだ。残念。まあ入力さえできれば出力はどうにでもなるものなのでいいのかな。

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)
• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足 (2007/11)
• Outlook Expressの後継の「Windows Live メール」になるとドコモやauの連続ドット/@直前ドットのメールアドレスに送れない (2008/1)

で、最近こんなことがあったらしいんだが↓

ｉモード生みの親、ドコモを去る　慶大院教授に (Asahi.com 2008/4)

ＮＴＴドコモの携帯電話でのインターネット接続サービス「ｉモード」の生みの親の一人として知られる夏野剛・執行役員（４３）が同社を去り、５月１日から慶応大院の政策・メディア研究科特別招聘（しょうへい）教授に就くことになった。

ぜひとも、メールアドレスの件について村井教授と対談していただきたいものだ。ここまで無視しとおした以上もうやらないだろうけど。

それから、ｉモードの生みの親といった単語は彼ではなくて元リクルートの松永真理氏のものだと思うのだが。

iモード事件

posted with amazlet at 08.05.06

松永 真理
角川書店
売り上げランキング: 128155

Amazon.co.jp で詳細を見る

まあ、彼が苦労人であることは認めよう。そのへんはこの本を読むとわかる。

社長失格―ぼくの会社がつぶれた理由

posted with amazlet at 08.05.06

板倉 雄一郎
日経BP社
売り上げランキング: 3250

Amazon.co.jp で詳細を見る

以上。最近は知らん人多いらしいのであえて古い本を紹介してみた。

AdSense 日本版 公式ブログ: モバイル版コンテンツ向けAdSenseが主要３キャリア対応となりました (2008/5/1)

モバイルサイト運営者の皆様より多くのご要望をいただいておりましたモバイル コンテンツ向けAdSenseが本日より主要３キャリア対応となりました！ 今までは、au、およびソフトバンクモバイルのネットワークのみに対応しておりましたが、本日よりNTTドコモ対応のサイトでもモバイル コンテンツ向けAdSenseがご利用いただけます。

see also:

• ドコモがiモードID通知機能を3月末から提供開始らしい
• ドコモのiモード通知機能はSSL(https://)のページでは通知されない

リキッドデザインにしたかったので、 小粋空間: Movable Type 4.1 テンプレートセット（スタイル対応版）を使わせていただきました。

この法案は、根本的に子供を育てるという視点が欠如している。有害情報の有害性は、それを見たことで発生するのではなく、有害であることを知らずに実行してしまうことで発生する。つまり判断材料としての経験が不足しているから、それを実行した場合の社会的影響や善悪の判断ができないわけだ。従って単に有害情報を見せなくするのは全くの逆効果で、「こういう情報がなぜ悪いか」を分からせることが重要なのである。

see also:

• 子供に尾崎を聴かせると盗んだバイクで走り出してしまうからダメ
• ネットスター社によるURLの分類の精度と鮮度とは
• やっぱりね→フィルタリングソフトなんてろくでもないことは世界的には常識

追記：

MIAUなど12の団体・個人が"青少年ネット規制法案"に反対声明（Internet Watch 2008/4）っていう記事が出たんだが、MIAUはともかく WIDEプロジェクトも、ってのはすごいな。

追記：

ディー・エヌ・エーとネットスター，マイクロソフト，ヤフー，楽天。役者そろい踏み。

ヤフーなどインターネット関連5社が「青少年ネット規制法」に反対声明(ITpro 2008/4)

声明では，「保護者や守られるべき子供が望まない方法で，かつ効果が期待できない方法を国が一方的に押し進めることは誰にとってもメリットはない」とした

そのとおりだ。以下はこのまえ自分が書いた記事のコピペだが、あえてもう一度ここに添えておく。 ↓

1. 実効性の無い技術
2. 運用できない制度

こうしたものを性急過ぎるやりかたで導入すれば悪影響のほうがものすごく大きすぎて無意味かつ金の無駄遣いだということは、 姉歯事件／耐震偽装問題のときの、

1. 構造計算結果を改ざん可能なソフトウェア
2. 「見ちゃいない」建築確認検査機関への届出制度（まともに「見る」ようにしたら住宅着工件数急減で景気懸念材料化、これ事実→ 耐震審査の義務付け、木造２階は見送り・国交省方針）

そういうのでもう実証済みなのである。しかしそれでも、ニュースを流し読みしているだけでそれを現在にあてはめ未来を推し量ることができない単細胞かつ思考停止なオトナたちによって、歴史は繰り返される。

また追記：

JPNICも"青少年ネット規制法案"に懸念表明(2008/4) 包囲網が二重三重に。。。

• ショッピングモールが外部リンクを嫌う理由 (2005/8)
• 「例」を書くときは example.com を使いましょう (2005/8)
• ステータス200なのに「その商品はありません」 (2005/8)
• 専用レンタルサーバーのススメ (2006/2)
• メールの自動処理アプリとメールサーバ設定TIPS (2006/2)
• かつてサーバーサイドJavaScriptは実在した (2006/4)
• ショッピングモールというビジネスモデルの寿命はそろそろ尽きる論について雑感 (2006/4)
• SSLアクセラレータはそれ用のPCIカードをWebサーバに仕込むほうが安価かも (2006/8)
• 集客機能つきのASP＝楽天市場＝の「楽天税」は高いか安いか (2006/9)
• 画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め (2007/8)

なお、他薦というか、客観的な見方での人気（なのか？）の記事については はてなブックマーク - neta.ywcafe.net の人気エントリーなどが参考になると思いますのでそちらもごらんください。

これで携帯３社めでたく似たような機能をそろえてくれたねありがとう！ といいたいところだが、あえて言おう。

SSL使えないじゃん。仕様が中途半端すぎてうんこ。

つまり、https://携帯サイト/hogehoge.jsp?guid=on という風にURLを書いても、 X-DCMGUIDヘッダを受け取れない。

1. そもそものhttps（http over SSL)というものの仕様としては、URLを送り出す前に既にWebサーバとクライアント（携帯端末）の間での暗号化は始まる。
2. ドコモの端末にはそれぞれSSL証明書がプリインストールされているということは、暗号化はドコモのゲートウェイ上で行われるのではなく端末上で行われる。
3. したがって端末とWebサーバとの間の中継点であるところのドコモのゲートウェイサーバはguid=onという文字がurlに付与されているかどうかを判断できないはず。SSL暗号化されているから。
4. したがってhttpsなページでは、https://。。。。/hogehoge.jsp?guid=on とやってもX-DCMGUIDヘッダは受け取れない。

CNET Japanの報道でも次のように書かれている。

「iモードID」が提供開始、一般サイトでもユーザー情報を取得可能に:モバイルチャンネル - CNET Japan

ドコモによれば、URL内にパラメータを記述することでiモードIDを利用できるという。具体的には、「http://xxxx?guid=ON」のように記述する。GET/POSTの両メソッドに対応するという。 ただし、SSL通信時にiモードIDは付与できない。

そこそこ金をかけたサイトであればユーザー認証その他個人情報を含むクリティカルな画面ではSSLくらい使っているだろう。 そのへんの画面がいちばんにiモード機能を使いたい場所なはずなのに、使えないということになる。 それってどうなのよ？＞ドコモの中の人。

なぜ仕様を決める前に、既存のコンテンツプロバイダに意見を求めるということをしないんだろねあそこは？

公式サイト向けには「uid=NULLGWDOCOMO」をつけると同等の機能が使えるというのはあったが、 そのときも同様の問題があったはず。 それを踏まえていれば、こんなことにはならないはずだ。

なお、ソフトバンクとＡＵの場合は、URLに細工などしなくても識別番号を含むヘッダを送り出す仕様のため、こんなことにはなりません。

see also:

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足

追記：

よーーーーく見たら、 「SSL通信時は、iモードIDは付与できません。」って小さく書いてあったよここに。　＿|￣|○

「開発用のサーバ機器届きました」
「んじゃ適当に環境つくっといて」
「ラジャ」
「環境できました。とりあえずメンバーのアカウントも作っときました。」
「んじゃはじめっか」
「ftpd動いてないぞ。データのアップできんやんけ」
「あ、忘れてました。今開けます」

っていう流れというか会話を今でもよく聞くんだが、ftpって必要かっていうと、必要ないんだよ、という話。 だってsshdさえ動いてればscpコマンドが使えるから。

クライアントだって、UNIXコマンドラインではscpって叩くだけだし、Windows端末なら WinSCPとかあるわけで。スクリーンショット見ただけで使い方の想像はつくだろう。

telnetやめてsshにしようという話はもう当たり前になりつつあるのに、ファイル転送手段の話になるといまだに「ffftpで。。。」とか言っている不思議。

運用の手間の節約、リソース節約、セキュリティ確保の意味でも、サーバで動いてるサービスは少ないほうがいい。

開発基盤選定における考慮事項の例
(1) プログラミング言語の選択

1) 例えば、PHPを避ける

短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。

こんなのに反応するのは、こだわりすぎ？あげ足取り？過剰反応？

いいや。こだわらなければならないことだし、「おかしい」と声を上げなければならないことである。 なぜならこれは、そのへんの技術屋さんのブログにメモ的に書いてあることではなく、 IPA＝独立行政法人情報処理推進機構＝の「セキュア プログラミング講座」に書かれていることだからだ。

そもそも「例えば、」とかいうその曖昧さはなぁに？

「曖昧さはできる限り排除しましょう」というのがセキュアプログラミングの基本である

なんていうのはそれこそ釈迦に説法だろうに、よりによって「セキュア プログラミング講座」と題したページ上で そんなあいまいな書き方でミスリードを誘うのはＩＰＡのWebサイトに掲げることではまったくない。ありえない。

これを見たセキュリティ担当者（「にわか」の人含む）がこぞって 「PHPはダメです！(perl|java)です！」とかなんとかトンチンカンな断定をはじめることうけあい。プログラミング言語を変えればセキュアになるよ、といったふうなミスリードを誘いすぎる。何年も前に「SSL入れさえすれば大丈夫」といったSSL催眠術が流行った時期があったけど、それに近いことになるだろう。

だいたい、んなこと言い始めたらなんでもありでしょうが。

「例えば、」

IIS+ASP(ActiveServerPage)で書かれたサイトだって相当おかしなコードが多くてヨワヨワな場合が多いのはこの業界の人なら誰もが薄々わかっていることなわけで。（しかもその手の予想はたいていあたってる）

「経緯」

とか言う単語をこういう形で出すのが許されるんであれば、 何年か前までさかのぼればカカクコム（IIS+ASPで構築されてた）の事件の件とか、 ごく最近で言えば、IIS+ASP(+SQLServer)を狙った攻撃が多発して、トレンドマイクロのウィルス情報のページがウィルス汚染されたというナイス洒落な件をも「経緯」としてひもといたほうがインパクトあるんじゃなかろうか。

ならば、「例えば、IISとActiveServerPageを避ける」とか書きますか？

っていうとそんな書き方はしないわけですよ。よしんば書いたところですぐひっこめなきゃならないことになる。なんでって？そりゃぁあなた．．．（笑）

ニュートラルな立場で啓蒙活動をしなければならないはずの公益目的の団体や組織が、 いつのまにやらevil（邪悪）になっていくサマはspamhaus.orgなんかと同じだ。 そこまで言うのはオーバー？いいや。意外と簡単に落ちてしまうのがダークサイドの誘惑というものである。 用心すべきは用心すべきだし、声を上げるべきは声をあげるべきだろう。 巷のブログ（このブログ含め）などに書き散らかしてあるのとはわけが違うのだから。

ＩＰＡのこのコンテンツの件とはまったく別の記事の話だが、PHP界隈で著名な大垣氏が 「誤解を招く記事 - LAMPセキュリティを強化する4つの方法」という記事を書いている。技術的に見てもかなり納得が行く。なによりも、結びが秀逸だ。その一文を借りてこの記事も終えることにする。

「言語を替える事はセキュリティ問題の解決策にはなりません。」

see also:

• LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠 (yohgaki's blog 2008/3)
• 「例えば、PHPを避ける」ってなぁにその曖昧な書き方？ (yohgaki's blog 2008/3)

Java が使いにくいのは静的だからではない

あと、アクセッサね。いちいち getter と setter を定義しなきゃいけないのがバカバカしい。よく「IDE で自動生成すれば問題ない」という人がいるけど、そんなのが必要な時点で間違ってるとは思わないのだろうか。だいたい、本質的でないコードが何十行もある時点で、ソースコードの readability が下がってしまう。あんなもの、コード行数を水増しするための仕様だ。

あっはっは。同意同意。「IDEで自動生成すれば．．．そんなのが必要な時点で間違ってる」のあたり特に。 どうにかならんもんかねまったく。

とは言っても、大人数でよってたかって開発するときにはその冗長さ（？）が時には必要悪になるといえばなるのかなあ。

see also: Javaジャバ言ってる間にも