閑散としてますね。

お盆ですね。
通勤も職場も空き空き。

Ruby on Railsの何か良い本がないかと本屋にいってみましたが、結局購入せず。もうちょっとＷｅｂ情報で頑張ってみるかな。

空の広い場所の効能？

健康診断で視力を検査したら、以前はメガネをつけて1.0程度だったのに、両目とも1.5になっていました。

空の狭いところから、広いところに来て1年余り。その効能かな？

私はなぜフレームワークが嫌いか Part3

データベースのフレームワークのあるべき姿は、

―SQLを隠蔽しないこと。
隠蔽する気持ちは分かるのですが（自分もかつて作ったフレームワークでは、定義ファイルに隠蔽しました）、これで満足するのは、フレームワークの開発側だけです。

設定や規約で隠蔽すると、プログラマは極端に２次情報の少ないものと（下手をすると１次情報も不十分なものと）不毛な格闘をしなければならなくなります。まあ、実際にはほとんどないであろう、ＰＫが１つしかないテーブルを結合もせずに全件検索やＰＫのみでアクセスする以外は。

―データベースの種類に対して、簡易で透過的なアクセスメソッドを提供すること。
PHPのADODBなんかは、良いバランスで作られていると思います。JDBCだと若干水準が低いかなと、もう少し高水準なメソッドが用意されていてもいいかなと。

―EclipseなどのIDEの機能として動作する。
列名のチェックや入力支援、Entityのスケルトン作成など補助的機能の提供があると、DAOの作成が楽になるかなと思います。

こんなところかと、なにしろ今あるフレームワークは頑張る方向性が違ってしまっています。

たら・れば

原爆が落とされなければ、終戦が延びてもっと多くの人が死んだかもしれないという人たちがいる。

そうかもしれないし、そうじゃないかもしれない。「たら・れば」で原爆を正当化するのと、歴史を正しく解釈するのとは違うことだと思う。

原爆を否定することを出発点として、あの時、原爆以外の方法で終戦を早める方法がなかったのかと、考えることが前に進むことなのだと思う。

でなければ、また同じ状況下で同じことを繰り返してしまうでしょう。

PHPフレームワーク Mapleの良いところ１つ

良いところ１つ。
リクエストパラメータの受け渡しが簡単。

【ＨＴＭＬ側】
< input type=text name='req_value' value='内容'> 

【ＰＨＰ（アクションクラス）側】
/* Mapleフレームワークのアクションクラス */
class Sample {
    public $req_value;
    public function execue() {
        echo $this->req_value; /* 「内容」と表示される。*/
        return "success";
    }
}

ＨＴＭＬ上のパラメータ名とアクションクラスのパラメータ名を合わせておけば、そのままインジェクションされるという手軽さ。もちろんリクエストパラメータが配列でもＯＫ。

オブジェクト指向的には、$req_valueをpublicにするのは問題ありかもしれないですが、フレームワークのみが入力すると考えればありかなと思います。

なにしろ、フレームワークに使わすためだけにsetter, getterを用意するのはナンセンスです。

こういう柔軟さ、好きです

SYNフラッド攻撃

ハッキングの勉強のメモみたいなのを「用語」カテゴリにまとめます。

（１）クライアント　→　SYNパケット →　サーバ
（２）クライアント　←　SYN/ACKパケット ←　サーバ
（３）クライアント　→　ACKパケット →　サーバ


いわゆる３ウエイハンドシェイクの接続手順中で（３）のACKパケットをサーバに送信せずに、[SYN_RESEIVED]状態のソケットを滞留させる攻撃。

送信元ＩＰアドレスを色々と偽装してSYNパケットを送信するのが、"みそ"ですね。

検出自体はnetstatコマンドで見れば分かるのですが、まっとうなユーザの接続を犠牲にせずに、防御することは不可能というんですからとんでもないですね。

同一送信元の[SYN_RESEIVED]状態のソケットが一定数以上になった場合は接続拒否だと、一般ユーザが接続できなくなる可能性がありますしね。

なんちゃって川柳

オブジェクト指向
優れたソフトウエア開発指向だけれども
それは目的じゃないんです。

夏の儚空

優秀アルゴリズム賞

とある株ロボコンテストで、優秀アルゴリズム賞などというものを頂いてしまいました。

腕試しという感じで応募したのですが、戦場のようなソフトウエア開発現場で磨いた技が、このような形で賞をもらうことになるとは、なんかちょっと感慨深げ。

「平面いぬ」

乙一（白）さんの作品です。幻想という海の浅瀬にいるような感覚、不思議で、少し切ない感じを味わいたい人におすすめ。

乙一さんの作品は、乙一（白）と乙一（黒）の両方を読むと、その２面性が楽しめます。

「平面いぬ」集英社文庫　乙一著
●石ノ目
●はじめ
この話の透明感がお気に入りです。
●ＢＬＵＥ
●平面いぬ。

失くしてしまった大切なもの

トムおじさんの本にプログラマに大切なことが書いてありました。

引用
「プログラマは皆、最高のものを開発したくて仕事をしているのです。」
「開発者たちはただコードを作る単純労働者ではありません。」

プログラマにとってのプライド（＝ 自尊心 or 職人魂）は、自分の頭を使って最高ものを作ることにあるということです。

ところが、ＩＴ業界に慢性化している短工期、低予算な状態は最低限の仕様を満たすのに精一杯で、高品質なものを作り出すには不十分なリソースであることがほとんどです。

品質よりも速さを求められ、結果納めるソフトはプログラマの自尊心を満たさない低品質なものになる。

稀になら、まだいいのかもしれませんが、毎回がそんな調子ではプログラマの心はどうなるでしょうか？きっと、プライドを失くして何も感じなくなってしまうのではないでしょうか？

プライドを失くしたプログラマは、まさにマシンのように淡々と低品質のソフトを作り出していくだけになるでしょう。

これは、ＩＴ業界にとって由々しき事態のはずです。この状態を打破するために先ず必要なことは、ソフトウエアシステムがどれだけ複雑なものかを認めることです。

そして、業界にはびこる現実逃避的なものの見方（「いざとなれば火事場の馬鹿力でなんとかなるだろう」など）を勇気を持って捨てることです。

それが、失くしてしまった大切なものを取り返すための第一歩になると思います。

ZendFrameworkでちょっと遊んでいます。

WebサービスのRESTのクライアント機能があったので試してみました。RESTでPOSTリクエストを手軽にできる方法がないかなと思っていたので結構ヒットです。

以下ではライブドアの天気情報Webサービスをお借りしています。リクエストパラメータは"city"と"day"です。GETでもPOSTでも使えます。

$resultのアクセスの仕方が、初め分かりづらかったのですが、慣れると楽チンです。

<?php
require_once 'Zend/Rest/Client.php';

$client = new Zend_Rest_Client('http://weather.livedoor.com/forecast/webservice/rest/v1');
$client->city("107"); //リクエスト：地域コード
$client->day("today");//リクエスト：いつの天気か
$result = $client->get();
//$result = $client->post();
echo $result->author() . "<br>";
echo $result->image->title . "<br>";
foreach($result->location->attributes() as $a => $b) {
    echo $a,'="',$b,"\"<br>";
}
?>

普通に引いた

夕飯を作って、さあ食べようと思ったら視界の端で、何か大きくて灰色ものが動いた。

そちらの方をよく見たら、体長10cmぐらいの平らな蜘蛛が。。。うーん、どうしようか。家の中の蜘蛛を殺すのは縁起が良くないというし、といいつつ捕まえて外に出すには大きすぎる。

しょうがないので窓の方に誘導して、窓の近くに来たところで素早く窓を開け、追い込みをかけて退場していただいた。

不思議なのは、あの大きさの蜘蛛が一体どこから入ってこれたのか？う〜ん謎だ。

この前は、部屋の前をクワガタが歩いているし、なんともかんとも

ＬＬフレームワーク

ここのところずっと、PHPフレームワークの「Maple」を扱っていたのですが、何か別のＬＬフレームワークを勉強しようかなと思っているのですよね。

PHPなら「ZendFramework」
Rubyなら「Ruby on Rails」

Rubyは、性能的に実業務で本当に使えるのかなという疑問があったのですが、ここのところ導入例がいくつかでてきていますね。ただ、あまりにももてはやされている感じがするので、ちょっと持ち上げ過ぎでは、という感じも受けます。

「ZendFramework」はマニュアルを読んでみると、色々な機能が用意されているので、おもしろそうです。ただ、Ｗｅｂ上の情報が少ない印象があります。