2003-06-24
_ Panther ほしい
http://www.apple.co.jp/macosx/panther/
あぁ Panther. かつて使っていたフィルムはエクタクロームパンサー100X. いやまぁどうでもよいのですが。来年こそは OS X の年になるか？
2004-06-24
_ 定型じゃないの？
ThinkPad がヤヴァイので、とりあえず保守マニュアルをゲット。必要な部分を印刷してみようと思ったのだが、、、
なに、この縦長のフォーマット？
しかも妙に小さいし。92 * 216 ? うまくすれば A4 1枚に2ページ分入るけど。。。どうすればいいんだ？ こういうの。
_ 芸が細かい
IBM のサイトはサポート＆ダウンロードだけ favicon の色がちょっと違う。なんでかは知らんけど。
_ ThinkPad を救え
保守マニュアルの必要な部分
| キーボード | p63 - 65 |
| LCD | マニュアル p76 - 77 |
これはマニュアル上に印刷されてるページ番号じゃなくて PDF ファイル上のページ番号。
IBMサービスセンター
| 番号 | 0570-088-787 |
| 時間 | 10:00 - 18:00 |
祝日はやってないけど、第2を除いて日曜はやってる。
他の番号は IBM相談窓口 で。
_ 全然平均じゃないと思うけど
Slashdot JapanやSourceForge.JPに集うユーザーの属性とは？ （ITmedia）
おかしいって。
- 回答者の平均
は、
- アクセスしてくるユーザーの平均
- /.-j アカウント持ってるユーザーの平均
- sf.jp アカウント持ってるユーザーの平均
どれとも違うと思うけど。
なんで /.-j と sf.jp をいっしょくたにしてんだか。
2005-06-24
_ ブロードバンド難民
ADSL の接続事業者を変更しようとした。
接続の切れる期間をいちばん短くしたかったので正確な工事日が分かったら教えてほしいとお願いして、了承された。
変更先の業者の方では日付が分かればその日に合わせて手配します、ということだったのに、何の音沙汰もないまま、いきなり切れた。
マジ困るんですよ、nifty さん。
むー。まぁネタにはなったけど。現在ダイヤルアップ中。
2009-06-24
_ find -mmin で1時間以内に変更のあったファイルを取り出す
ずっと思っていたことがあったんですよ。
なんで find の -Xtime オプションて time と言いつつ日数を引数に取るんだろう？ 数時間以内の変更ファイルとかどうやって抽出すればいいの？
-Xmin で簡単にできました。
例えば
find ~ -mmin -60
ってすればホームディレクトリ以下で 1時間以内に変更のあったファイルが取り出せます。（主にブラウザのキャッシュが引っかかるでしょう。）
2009-06 現在で現役の BSD find も GNU find も同様に動きます。なんてこった。全然知らなかったよ。いつからある機能なんだろ。
関連つぶやき
11:07:34 >wtnabe< find は分とか時間単位で直近のファイルを探せたら便利な
んだがな。その場合は基準になるファイルを用意しなきゃ
いけないのが面倒。
13:09:27 <showchan> @wtnabe -atimeとかじゃだめすか
14:20:17 >wtnabe< @showchan あ。最近のものは単位を与えられるのですか。
14:22:05 >wtnabe< @showchan ん？ GNU find には単位を与える方法はないよ
うな？
14:24:30 <showchan> @wtnabe -atimeとか-aminとかあるみたいですよ。man
find によると
14:26:27 >wtnabe< @showchan あー -amin -mmin か。これは便利そう。ありが
とー。
14:28:57 >wtnabe< 基本的なツールだったり、すでに使い込んでるツールでも
たまに changelog とか man とか読み込まないとダメだなー
2012-06-24
_ 今さら『パターン、Wiki、XP』を読んだ
3年前に買ってそれっきり積んでました。ごめんなさいごめんなさいごめんなさい。読み始めたら一気に読んでしまった。
ざっくり
面白かった。最近こういう本をほとんど読んでいなかったけど、丁寧に資料を集めた丁寧な仕事だ。
これまでパターンという言葉は実はあまり好きじゃなかった。意味がよく分からなかったから。その理由が本書を読んで分かった。要するにソフトウェアの世界で「デザインパターン」というパターンの中のごく限定的なものが有名になりすぎたからだったようだ。
省略せずに「オブジェクト指向における再利用のためのデザインパターン」という言葉を使っていれば「オブジェクト指向」「再利用」「デザイン（設計）」と三つも限定条件が入っていることが分かる。例えば極端な話、再利用性のないものならパターンは無用だ。「デザインパターン覚えてないしソラで書けないし、オブジェクト指向なんか分かってないんじゃないか」とか、変に萎縮する必要もないわけだ。
ちょっと安心した。
第1部 建築
以下、ざっくりと心に残った言葉。
- 「セミラティス構造」
- トップダウンのツリー構造で抜け落ちる様々なものへの気づき
- 「漸進的成長の原理」
- オレゴン大学の実験における建築プロジェクトで適用された原則の中から。
- 親方の仕事はあとで修正がきく
- パタン・ランゲージを引用した言葉の要約だけど、アジャイルとか言わなくても昔からモノを作る仕事のコツは変わらないんだなぁという印象。
- 「パターン形式」
- ノウハウなどの記述形式ってよく悩むことがあるので、フォーマットを決めるときに参考になると思った。フォーマットについては Wiki の話でもモードという言葉で出てくる。
観察からボトムアッププロセスへ繋がっていくアレグザンダーの思考を鮮やかにトレースできて、そうだよなぁと次々に納得が押し寄せてくる。
第2部 ソフトウェア開発
OOPSLA が何か初めて知った。
こういう論文というかアイディアの発表というフォーマットがあり、議論し、そのくり返しによってより良いものを目指すというアプローチがなんというか、プラグマティックな学会のような感じで面白かった。日本だと何になるんだろう、学会そのものとは違うだろうし、各種カンファレンスも何か違うような…。デブサミはいろいろボーダーがないので位置づけとして近いのかもしれないけど、この本で読んだ限りでは OOPSLA みたいな動き方とは違うような気もする。
脱線した。
- デザインパターン
- プロセスパターン
- XP
が見事につながっていき、20世紀最後のソフトウェア開発の英知が具現化されていく歴史を追えるのは単純にとてもわくわくする。XP の解説ではなく、生まれた歴史が読めるのがとても面白い。今さらだけど XP 本読んでみようかな。（できっこないと思って当時スルーしていたのだ。）
またここで、あぁ、デザインパターンに固執しなくていいんだと気が楽になった。
第3部 Wiki
ここまで来ると聞いたことのない言葉でも「パターンブラウザ」が出てくるとキターって思えるようになっている。
そして Wiki の極端な考え方がある意味分かりにくさや使いにくさを生んでいることもよく分かる。
自分の Wiki に対する理解はまだ浅かったというか、運営するという意味においてはやはり「何を目指すのか」を絶えず共有し続けるというとてもつらい作業を通じて、より良い成果を残せるのだろうなぁと、Wiki にハマって 10年経ったいま思う。
振り返ると、WWW を加速させる可能性に興奮した Wiki によって地方のデメリットも強く意識するようにもなった。 自分は「Wikiばな」には一度も参加していない。今、様々な勉強会は Ust ブームを過ぎ、直接会うことによって生まれる何かを最大化させる方向に向いているものが多い。
参加とはなんだろう。難しいんだよなぁ。
まとめ
軽く読める読み物にまとまっているんだけど、これはコンピュータサイエンスの現代史として教科書に採用していいんじゃないかと思う。いやマジで。少なくともいま実際に起きている世の中の動きについてその背景の一端をかなり理解できると思う。
オススメ。は、みんな3年前にしてますね。はい…。