Archive for 6月, 2006
月曜日, 6月 26th, 2006
なんだか、今日の青椒肉絲（チンジャオロースー）は美味しくできたので、分量をメモしておこうという気になった。
安いコマギレ肉のような牛肉を使ったので、見た目は「絲（スー）」という感じではないですが、美味しかったです。
材料（2人分）
・牛赤身肉 150g
・ピーマン 中4個
・ねぎのみじん切り しろねぎの1/3本くらい
・おろししょうが 大さじ1/2
・オイスターソース 大さじ1
・酒 大さじ1
・醤油 小さじ1
・片栗粉 中さじ１くらい
・塩 ふたつまみくらい
・ゴマ油 ちょっと
中華は下拵えに9割
酒、醤油、塩、オイスターソースを混ぜてソースをつくっておく。
牛肉は細切にして片栗粉を揉み込んで10分ほど置いておく。ピーマンは中綿（？）を取って肉と同じ細さに切る。
一気に炒める
フライパン（中華鍋）に油を熱し、ネギを炒める。しんなりしてきたらしょうがを入れて肉も入れる。
だいたい火が通ったら、一旦、皿に移して、ピーマンを炒める。あまり炒めるとピーマンの食感が失われる。ちょっと火が通ったら、肉を再び加え、ソースをかけて短時間炒める。仕上げに胡麻油を少々。出来上がり。
中学生か高専生の頃に、中華一番! を読んで、ちょっと「特級面点師」になりたかった時期があった。中華鍋と中華料理の本を買って、端から全部作っていた。東坡肉（トンポーロー）と棒々鶏（バンバンジー）とゴマ団子は作ってないけど。あの漫画の中で、主人公の劉昴星（リュウマオシン）が青椒肉絲の隠し味に、熟れた渋柿を入れるエピソードがあって、とても美味しそうに見えた。まだ実際にやってないけど。
いまだにあの漫画を読むと、なぜか幸せな気分になる。
小川 悦司 / コミックス(2003/03)
Amazonランキング：195,573位
Amazonおすすめ度：
Posted in 食す | No Comments »
水曜日, 6月 21st, 2006
Configureオプション。こんなのいれたらどうでしょう。
–enable-suexec
Use this option to enable suexec, which allows you to set uid and gid for spawned processes. Do not use this option unless you understand all the security implications of running a suid binary on your server. Further options to configure suexec are described below.
–enable-ext-filter
Enable the external filter support provided by mod_ext_filter.
–enable-info
Enable the server information provided by mod_info.
–enable-ssl
Enable support for SSL/TLS provided by mod_ssl.
–enable-usertrack
Enable user-session tracking provided by mod_usertrack.
–enable-vhost-alias
Enable mass virtual hosting provided by mod_vhost_alias.
–enable-cgi
–enable-so
–enable-deflate
–enable-logio
–enable-expires
–enable-headers
–enable-unique-id
–enable-http
–enable-rewrite
–with-suexec-caller=www
–with-suexec-docroot=/
これ後で入れる
TangentOrg ＞ mod_layout
レンタルサーバーなどで、広告を自動挿入するときに使える。
Posted in server | No Comments »
日曜日, 6月 18th, 2006
まだ読んでなかったの？という感じですが ハッカーと画家 コンピュータ時代の創造者たち を読みました。これの影響で 翻訳テーマ も How to Be Silicon Valley をおねだりしたのです（自分で読めなかったから…）。
以下、付箋を貼った箇所。
プログラマとシステム管理者は、普通はそれぞれ違った心配を抱えているものだ。
プログラマはバグについて心配するし、システム管理者はインフラについて心配する。
…略…
Webアプリケーションでは、このふたつの異なった責任が一緒にかかってくるんだ。
デスクトップソフトウェア会社では、プログラマはソフトウェアを書きあげればそこでバグ対応まで一旦、一息つけるでしょう。でも、Webアプリケーションでは、
出来上がり→リリース→すぐバグがあがる
ので、大変です。運用し始めたらサーバーのスペックが…とかいう問題にも対処しないといけません。
でも、すぐユーザーに使ってもらえるので、ダイレクトにユーザーの要望やバグが上がってくる。大変だけど、面白い。
まず、自分でも使いたいと思うような、明快で簡単なものから作り始めることだ。
バージョン1.0を素早く出して、それからユーザーの声をよく聞きながらそれを改良してゆく。
「あれがやりたい」と思ったらすぐ作ってしまえ、ということ。なかなか進めないのは意思が足りないからでしょうか。
エリック・レイモンドはエッセイ『ハッカーになろう』の中で、他のいろいろなアドバイスに混じって、
ハッカーになりたい人はどんな言語を勉強すべきかを述べている。
まず Python と Java から始めよ、学ぶのが容易だから。
真剣なハッカーはさらに、Unixをハックするために C を学び、
システム管理者とCGIスクリプトのためにPerlを学ぶべし。
そして本当に真剣なハッカーは Lisp を学ぶことを熟慮すべきだ、と。
と、 Lisp をべた褒めしています。こんど、どんな言語なのか眺めてみよう。
数学者は良い仕事を「美しい」と形容する。
科学者、技術者、音楽家、建築家、デザイナー、作家、画家、
そういった人々も、過去や現在に、「美しい」という形容詞を使ってきた。
そういえば、「美しい」なんて言葉は日常で使わない。日本人は特に。「美しい」と言える仕事は幸せだ。
Paul Grahamさんもそうですが、何か一つに秀でている人は、他の事象についても造詣が深いものだと感じます。
ポール グレアム, Paul Graham, 川合 史朗 / オーム社(2005/01)
Amazonランキング：6,005位
Amazonおすすめ度：
Posted in 読んだ本 | 4 Comments »
金曜日, 6月 16th, 2006
ずっと苦手意識を抱いていたサーバー管理とか、ネットワーク管理を手伝わせて頂ける事になりました。これを機に苦手を克服したいと思います。といいつつ、Perlでの小さいパッケージの仕事が入ってきたので、それ優先か？
OpenSUSE Linux 10.1 で、XをGNOMEでインストールしました。GUIがすごいきれいです。
今日覚えたツールなどをメモ。
・UTF-8 TeraTerm Pro with TTSSH2
UTF-8対応TeraTerm Pro。しばらく見ないうちに TeraTerm がパワーアップしていた。
・linx
テキストブラウザ。
> lynx http://www.yahoo.co.jp/
Posted in server | 2 Comments »
土曜日, 6月 3rd, 2006
※読前メモ。いつにもまして文章がまとまっていません。
ゴールデンウィークの後半から一日も休みなしで、殆ど朝から深夜まで働いていました。でも、変に元気です。後からドッとくるのかも。今日は久々に休日だったのでマッサージに行ってきました。
今回の仕事を終えて（まだ残件はあるけど）改めて思ったことがあります。いい大人が何人、何十人と集まっているのに、何でプロジェクトの進捗は遅れてしまうのでしょうか。これは皮肉でも愚痴でもなくて本当に疑問に思っていることです。これまで「スケジュールは順調です」というプロジェクトは見たことがありません。私のまわりだけだろうか？
「熊とワルツを」に書いている、リスクの多いタスクをこなすことは成長するチャンスだ、というのは同感です。でもリスクにもほどがある場合がある。
何を基準に予定を立て、進捗率を計算すればよいのか。「画面数」という人が多いとおもうけど、単純にそれでは計れないことが多い。「一機能X日といっても、その技術者の技量によるし、その幅は広い。技術について熟知していて、マネージメントもできる人じゃないと、その進捗基準を見極めるのは難しい。でもそんな人はそうそういない。→コーディング、テストする人たちとの認識のズレ。→正確な計画が立てられない。進捗の遅れ
技術検証が十分でない、もしくは技術検証時に想定できない様な問題が起きるとシステムの土台が揺らぐ→基本的な部分の見直し→全体の手直し発生→進捗の遅れ
不思議とそういう基準が定まっているプロジェクトってない。そもそも、そんなもの無い？プロジェクトマネージャやプロジェクトリーダー個人の裁量に任せられるのか？
これについてはまたこの本を読み終わった時に考えた事を追記。
あと、この言葉も面白いと思ったのが、ブルックの法則。
遅れているソフト開発に人員を追加すると、さらに遅れるという法則
どんな現象にも名称がついているのですね。
こういうことを学術的に勉強をしてみたいとも思うけど、やはり現場でソリューションを探るほうが効率がよいのかな？テストケースは身近にゴロゴロしてるし。
これと同じようなことが身近に起こっている。システム作っても現場の流れとか仕組みが変わって、キリが無い。現場の体制を変えるのは、実際、難しい。けど、だらだら続けても双方にメリットが無いと思うのだけど。ああ、なんか愚痴愚痴書いてしまってる気がする。
これって、ソフトウェア開発に応用できるのか？と最近思ってきた。工場のラインのように成果が明確でないし。明確な測定基準を作ればよいのか。
ToDo:これもヨムベシ。Joel on Software
Posted in 開発 | No Comments »
