外部記憶装置: 2007年05月アーカイブ

2007年05月30日

PerlでUTF-8

Perlの文字コードでちょっと悩んだので、これ以降悩まなくて良いようにメモ。

perlのコードがEUCで、コードの中でUTF-8の文字列をEUCに変換する

use Encode;

Encode::from_to($_, 'utf8', 'euc-jp');

でもコレだとEUCに無い文字が化けたりするので、perlのコードをUTF-8にして全部UTF-8で扱う。
詳細はPerl 5.8でUTF-8の文字コードを扱うを参照

use utf8;

binmode STDIN,  ":utf8";  #標準入力をUTF-8

binmode STDOUT, ":utf8"; # 標準出力をUTF-8

#UTF-8のファイル読み込み

open(IN ,"<:utf8", $_) or die "file not exist";

ちょっとしたプログラムはJavaよりPerlの方がやっぱ楽だな～。
今からやるならPerlよりRubyかなとも思ったけど仕事先の環境だとRubyデフォルトで入ってないからなぁ。残念。

2007年05月28日

台所危機一髪

(下水に関連した汚い描写があるので食事中、食事前の人は読まない事をオススメ)

土曜の夜12時から深夜2時までと言う謎にハードなフットサルのゲームを終え、日曜の昼過ぎまで惰眠をむさぼっていると、家の1階から両親の緊迫した声が聞こえてきた。

「なんだ？父親が機嫌でも悪くしてるのか？」と思ったけどどうやらそうではないらしい。
話を聞くと台所の下水が詰まって水が流れなくなってしまったとのこと。
そして詰まったパイプをどうにかするために金属の太いワイヤーを買ってきたので、今から流しの口からつついて詰まっているモノを押し出すようだ。

家の下水の配管は台所からすぐ横の家の外に出て、そこに小さなマンホールがあり、さらにそのマンホールからお風呂場とトイレと接続している小さなマンホールを経て、家の外のメインの下水に繋がっているらしい。幸い詰まった場所は台所専用の配管でトイレはその先なのでトイレの下水はあふれていない。

台所すぐ横のマンホールを開けてみると、濁った水がたまっていて底は見えない。
詰まっている事はわかるがどこがどう詰まっているのかはわからない。
底に穴があるのか、また深さはどれぐらいなのかを調べようと棒を濁った水に突き刺す父親。
「ん？なんかある！スコップ無い？スコップ」
スコップで濁った水の底をすくうと、なんと白い大きな固まりが出てきた！
「うおっ！脂のかたまりだ!!」
出るわ出るわで大量の脂(ラード)の固まりが取れた。

マンホールの底は掃除できたが、配管はまだ詰まり気味だ。
台所の流しからバケツいっぱいの水を一気に流し、水圧で詰まったモノを押し流そうとやってみる。
詰まってあふれないかな？と心配になりつつも一気に流すと・・・。
「ゴポゴポッ・・・ゴポッ！！」と音とともに500mlのペットボトルを一回り小さくしたような脂の固まりが2本出てきた!!汚ねぇ!!

水を流すと台所横のマンホールの水位が上がり、その小さなマンホールからお風呂場横のマンホールまでのパイプも詰まっていることがわかった。と言うかバケツで押し流した脂が詰まったのかもしれない。
こっちはワイヤーを出し入れしたりして脂を押し出しているうちにスムーズに流れるようになった。

バケツの水を流す作業を続けると、水が綺麗になり、脂の固まりが流れる量が少なくなってきた。
とりあえず一安心と言うところで、奮闘する父親と俺の横で母親が「ご飯できたで～」と声をかけた。
父親&俺「イヤ、脂の固まり見まくったから今食欲無い・・・」

母親曰く、「アブラを流すようなことはしていない」と言っていたが、洗い物やらなんやらで日頃ちょっとずつ流れた脂が15年間たまりにたまっていったんだろうな。

ネットで調べると水酸化ナトリウムやバクテリアを使った詰まりを分解をする薬があるようだ。
バクテリアを使うヤツは即効性が無いかわりに、脂の奥深くまで浸透するらしい。
一度詰まったからにはこういう薬で日頃から予防していかないとダメなんだろう。

詰まって大変だったけど業者さんを呼んだりせずにすんでよかったよかった。
俺だったら「詰まった！大変だ！ネットで業者を調べよう」となるけど、父親は自分でワイヤー買ってきて自分で解決しようとするところがすばらしいな。あまり父親は好きではないけど、頼りになる父親を見直した一日だった。

2007年05月18日

Lisp脳

kenji
00:23
コメント (5)
カテゴリー:Diary

「Lisp脳」の謎に迫る - Schemeプログラマの発想
他の言語のプログラマがSchemeプログラムを書くとき、どうしても発想が手続き的(procedural)になりがちです。
LispプログラマやSchemeプログラマの発想は手続き的な発想とはどうも違うらしい、ということは分かるのですが、具体的に何が違うのでしょうか?

このリンク先のページは、以下のプログラムを実装する場合の手続き型言語使用者と関数型言語使用者の考え方の違いを解説してる。
1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに｢Fizz｣と、5の倍数のときは｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣とプリントすること。

Lisp脳だと1～100のリストに対してmapすると言うのは確かにそうかも。と言うかSICPではそういう考え方のプログラムが多いようだ。
Lisp脳になれきれていない俺の場合だと、1スタートで100まで~~テイルリカージョンしつつ~~条件に一致する値の場合だとそれぞれの文字列を返すって感じで。(全然テイルリカージョンじゃなかったので本当のテイルリカージョンバージョンはコメント欄に)

(define (FizzBuzz start end)

  (cond ((>= start end) '())

        ((= (remainder start 15) 0) (append '("FizzBuzz") (FizzBuzz (+ start 1) end)))

        ((= (remainder start  5) 0) (append '("Buzz") (FizzBuzz (+ start 1) end)))

        ((= (remainder start  3) 0) (append '("Fizz") (FizzBuzz (+ start 1) end)))

        (else (append (list start) (FizzBuzz (+ start 1) end)))))

って感じかな。再帰だけどループを前提に考えてるからまだまだLisp脳には遠いようだ。
あ、'("FizzBuzz")と(list "FizzBuzz")って同じだったっけ？まぁいいや。
再帰でFizzBuzz関数を呼び出す部分が4回も冗長して書かれているので、やっぱりmapを使う方がスマートかな。

このページのまとめで「"データからデータへの変換をしておけばいいじゃん"とだけ考えていたら結果としてモジュール性が高くなってしまった」と言うのは確かにそうだなぁ。考え方の違いでよりよいプログラムになればそれはそれで大歓迎だ。

たとえばJavaもJUnitで自動化テストをしようとMockオブジェクトを使えるようにしたら、結果抽象度が上がり他のクラスとの依存度が下がって柔軟なクラスになると。

Lisp脳に達するにはまだまだかかりそうだけど、その前にJava脳になりきることを先に考える必要があるな。
まだまだ実装クラスと実装クラスが依存してしまうように書いてしまう。interfaceに依存するように書かなくちゃいけないけどやっぱめんどくさいｗ
そもそも「ここは実装クラスに依存するコードで良いか悪いか」をちゃんと考えなくちゃなぁ。今の現場はJavaプログラマが俺だけで、誰も俺のコードを見ない環境なのでついつい「めんどくさいからこんなんでイイや」ってなってしまう。もっと自分に厳しく行かねば！

2007年05月10日

Newton

以前JavaWorldを定期購読していたけど、JavaWorldが廃刊になってしまった。
定期購読している雑誌が無くなり、「なんかの雑誌を定期購読しようかなぁ」と考えて「久々にニュートン読んでみよう」と言うことで科学雑誌のNewtonを定期購読してみた。
1ヶ月1000円で、JavaWorldを毎月買っていた感覚からすると「お、意外と安い」と言う感じ。

そして届いた！

久々に読んだけどやっぱ面白いなぁ。
グラフィックサイエンスマガジンとあるだけに全ページフルカラーで、写真や絵を見ているだけでも楽しい。
絵が多くあまり深いところまで踏み込まないので知識のある人には物足りないかもしれないけど、一般向けとしては十分だ。

このNewton、なぜか小さい頃に家にあった。
そのため物心付いた頃から家に転がってたNewtonを読みふけってた覚えがある。
親は理科や科学系が好きでもないのに何でNewtonがあったんだろうとずっと疑問だったので昨日親に「昔家にNewtonあったけど何であったん？」と聞くと、「あんたのために定期購読してたんやん」と言った。
おいおい、小学校低学年の子供にNewtonを与えるとは・・・。きっと「子供を立派な学者にしたい！」とか希望があったのだろう。残念ながら勉強が嫌いだったので学者にはなれず、"理科や科学が好きなただの人"に成長してしまったが・・・。

Newtonの公式ページには、創刊された1981年からのバックナンバーが置いてあり主要な記事を読むことができる。
昔読んでたNewtonはいつのNewtonだろうと思い調べてみる。
小さい頃家にNewtonが何冊もあったけど、その中で一番記憶に残っているのは表紙に電波暗室のトゲトゲがいっぱい映ってるヤツだ。異様な空間でとても印象に残ってる。
その号を探してみると・・・、1983年12月号(閲覧にはネット会員のIDとパスワードが必要)だ！うおー！俺3歳！
3歳の幼児にNewtonを与えるとは恐ろしい親だ。
ちなみにNewtonは綺麗な絵や写真がいっぱいで文字が読めなくても結構楽しい。

83年12月号の記事は今でも覚えてるなぁ。「ポンペイとヘルクラネウム」とか懐かしい！
突然の火山の噴火で生き埋めになった街を発掘したときの記事なんだけど、家がそのままの形で発掘され焼いたパンが残っていたり、生き埋めになった人の形そのまま出てきたりでインパクトがあった。
なんでパンの形まで残ってるんだろう？と思って今Wikipediaを調べてみると
紀元79年の爆発のとき、逃げ遅れた人々は火山灰の中に埋もれて死んだ。後に発掘されたとき、遺体部分だけが腐ってなくなり、火山灰の中に空洞ができていた。考古学者たちはここに石膏を流し込み、逃げまどうポンペイ市民が死んだときの形を再現した。
とのこと、なるほど。

小さい頃の記憶がよみがえって懐かしいな。

Newtonはやっぱり難しすぎたのか、その後Newtonを定期購読するのはやめて、コペル21って言う子供向け科学雑誌を定期購読するようになっていた。
こっちは完全に子供向けなので、マンガがあったりで面白かったのを覚えてる。でもネットでコペル21を検索しても全然情報がないのでかなりマイナーな雑誌だったんだろうな・・・。

その雑誌の中でも「Dr.オーヤマのドキドキ科学講座」って言うマンガが特に好きだった。
マンガで科学の知識を教えるというコーナーなんだけどその中にハカセが作った友ちゃんという美少女ロボットがいて、今から思えばメイドロボの先駆者的なものだったのかもしれない。
大山哲也と言う人が描いてて、今この人何してるんだろうと検索してもこれまた情報が全然無い。
中学か高校ぐらいの時パソコン雑誌で大山哲也が描いたマンガが連載されてたな。
「あ！この絵はDrオーヤマの人の絵だ！」って感じで感動した記憶がある。
もう今はマンガ描いてないんだろうか。Drオーヤマだけでも単行本化してくれ！

外部記憶装置