その後の郵便番号検索

ToDoとしていた項目のうち、URIがイケてない問題は解消。
Apacheの設定弄るとか、普段使ったことのない筋肉だからひどく苦労した。（そもそも最初の時点では、Apacheの設定で解決するのだというところさえ知らなかった）

ついでに、サービスの内容をぼんやりと説明するページを作って、トップに割り当てた。ここ。
http://bagend.sakura.ne.jp/zipcode/


元の住所データが123,400行。

そのうち、330行程は住所が長すぎて書ききれなくって2行以上に分割（！）されていた分。
この郵便番号データ、パっと見カンマ区切りなので、いわゆるcsv型式に見える。が、実際には論理的な1件が物理的な1行になっていない不定型なデータだ。分割された行の中での順序の情報とかも入っていないので、とりあえず上から順番に繋げばいいのだと信じるしかない。これを1行に繋げる処理までは実装済み。

これらを繋いで作った123,100件のうち、1,900件くらいが194-0000みたいな「町田市のその他の地区」の番号。
残りの121,000件が「町田市○○町」みたいな町名とか番地に割り当てられている。

そのうち、800件ほどは「○○町１〜５丁目、△△町」みたいな面倒なことになっている。
全体の1%にも満たない量なんだけどね。

この800件をきれいに整理してみせるのが目標。
自分がこの問題に取りかかった理由であり、一番大きな作業である。

この住所データの整理にとりかかる前に、テストを書こうとしてる。
データベース用のロードデータを作成するバッチ部分だけ。Webでの問合せ部分は、あまり弄る必要性を感じていないので。
肝の部分くらいテストを書いておかなくては……という義務感半分。xUnitやmockの使い方に習熟しておきたいってのが半分。

郵便番号

会社員＠事務系です。


FizzBuzz問題華やかかりし頃、一部で「業務プログラマ的には、むしろ郵便番号のcsvで腕試ししたいよね」的な話が持ち上がっておりました。

FizzBuzz 問題どや顔で解くひとなんかよりも "KEN_ALL.csv" をうまく扱える人の方が社会的貢献度高いhttp://togetter.com/li/352382

とはいえ、未だ実際にその実装例を見ることができていません。しょうがないから、自分で作りました！
…とドヤ顔で言ってやろうと思って、既にもう8ヶ月。他の問題に手を出したり、プラットホームをGoogleAppEngineからレンタルサーバに乗り換えたり、ほとんど開発と関係ない時間でしたが。


郵便番号→住所
http://bagend.sakura.ne.jp/zipcode/index.cgi/zip2adr?code=1940015

住所→郵便番号
http://bagend.sakura.ne.jp/zipcode/index.cgi/adr2zip?pref=福島県&muni=福島市&street=置賜町

問合せの結果はJSONフォーマットで返します。他のサーバから利用してもらう想定なので。

streetは実際に登録されている町名とユーザーの入力の、いずれか短い方を基準に、前方一致したものを複数返す仕様としています。
上記の例だと「置…なんだっけ？」とか、「いきおい余って、丁目まで入れてやったぜ」という場合に対応してます。
streetに入力された町名がデータ上存在しない場合は末番00の「○○町（以下に掲載がない場合）」になるはずです。


ソースはこちら。
https://github.com/morinatsu/ZipCode

郵便局のサイトから圧縮ファイルをダウンロードして加工するバッチ部分と、そうして組み上げたデータベースをもとに問合せに答えるWebサービス部分にわかれています。
これに、データベース(sqlite3を利用しています)にデータをアップロードする部分まで作りこめば、完全自動でいけるはず。
ただ、上記のソースの開発はUbuntuでやりましたが、運用サーバはさくらレンタルサーバのFreeBSDなので、そのままでは動きません。辛かった…。


TODO:

• 「以下に掲載がない場合」とか、問合せ結果として、あまり面白くない文言はそのまま使わないようデータを修正させる。
• 「○○町、△△町、××町」など、町名などが列挙されているものを分解して扱う。
• 「○○町１丁目〜６丁目」とか、連続しているものも分解して扱う。
• テストを書く。
• 意味もなく、パッケージ化を試してみた結果など、意味のなくなったファイルを消す。
• 格好悪いURL /zipcode/index.cgi/ の修正。mod_rewriteの使い方が…。

上3つくらいはちゃんと実装しておかないと実用にならないし、下3つをなんとかしないと「作った」とは言えないよなぁ。
あと、ジェネレータ関数を作っておいて、json.dumpsでうまく使えず結局list化しているのも何とかしたい。

HK 変態仮面

映画『ダークナイト』を、アメリカ人が自らその正義の拠り所を問う映画であるとすれば、日本人にとってのそれがこの映画である。主人公、色丞狂介はバットマンさながらにマスクを被ることで異形の自警市民、変態仮面となり、その恐怖をもって街にはびこる悪を圧倒していくのである。

この映画の一番の見所は『ダークナイト』におけるジョーカーに相当する役柄を演じる安田顕の怪演であろう。
変態仮面には、ヒーロー映画の主役にふさわしい、ある種の均整美がある。対する彼はそのような均整を全く欠いた純粋な怪物として現れる。
異形のヒーローとしての自分と恋する少女との幸せを願う平凡な少年としての自分の間で揺れる狂介。その狂介に、彼はこう問いかける。「お前は果たして本物か」と。
その問いを発するにふさわしい、彼の本物ぶりとその行く末。ぜひ劇場に足を運んで見届けて欲しい。

リスクと向き合う 福島原発事故以降

「福島原発事故以降」とタイトルにはあるが、原発事故について語っている第一章は全体の5分の2ほど。残りは新聞に連載された著者の半生を再構成した第二章。

著者は研究者として諸々の公害問題・環境リスクに取り組んできた人。彼女がこれまでの人生の中で得てきたものを総括しつつ、さらに震災とそれに伴う原発事故という経験を経て、どういう視点で放射線のリスクを捉えるべきかを論じている。

• 化学物質のリスク評価法で放射線のリスクを見るとどうなるか。
• 年間１ミリシーベルトという数字は誰がどうやって出したのか。
• 彼女のがんのリスクに対する考え方。それがどのように変わったか。
• 今、どのような研究に取り組んでいるか。

自分が読んでまず驚いたのは、よく分からないと強調されている、低線量被曝の影響について。それでも大抵の化学物質よりはデータが揃っているのだということ。では、データが少ない場合にどのように判断するか。そこに彼女の取り組みがある。

ニュースを丹念に追っている人なら、個々の事例や議論は聞いたことのあることばかりかもしれない。この本では、それらをリスク評価の専門家の視点で整理するとこうなりますよ、というのがわかりやすく示されている。
不安にかられて情報を集めてはいるものの…という人向け。その前に、そもそも彼女自身が信頼できる人なのか…っていう方は第二章も読んで。

リスクと向きあう 福島原発事故以後

posted with amazlet at 13.04.23

中西 準子
中央公論新社
売り上げランキング: 21,848

Amazon.co.jpで詳細を見る

心が折れそうなビジネスマンが読む本

タイトルから予想されるように、よくある「うつ予防本」。

気をつけなくてはいけないのは、著者および他の人の実体験が元になっていること。ホントに心が折れそうな時に読むと、この本がきっかけで心が折れかねない。

強調されているのは、会社内の非公式な、あるいは会社の外での人間関係の大切さ。それと、兆候のつかみかた。いざ、というときの心構え。

新社会人の時は実感沸かないだろうから、社会人になって2～3年経ったころに読んでおいて、心が折れそうになる前にもう一度読み返すのが正しい読み方なのではないかと思う。

著者の立ち位置か、読者を意識してか、割と会社に対して攻撃的（副業を勧めてたり）なところがある。これがなければ、メンタルヘルスの参考書として会社から社員に勧める本にもなると思うのだけど。

コミックダッシュ！新刊カレンダーのPython2.7対応

久しぶりにDashboard覗いたら、GoogleAppEngineのPythonバージョンが2.7に上がっていて、今使っている2.5が非推奨になっていた。
ちょっと前まで「一部の先行ユーザーで試験的に…」とか言ってたのに。
せっかくだから、今のうちに対応しとくかー。 


コミックダッシュ！新刊カレンダー


久しぶりに、開発用PCのフォルダ開けてみたら、中身がない。一代前の別のPCで開発したのか。
まぁ、こんなときのためのGitHubである。さっそく、cloneして何事もなかったかのように再開だ。 

現バージョンでの稼働確認を取ろうと思ったら、さっそくBeautifulSoup(*1)が見つからないときた。
そりゃ、確かに無いよなぁ。インストールしてないもん。
ただインストールするだけならpipが便利なのだけど、AppEngineに載せるには共用のPython環境ではなく、アプリのフォルダの内側に持ち込む必要がある。
アーカイブをダウンロードし、解凍して、setup.py。懐かしいな、この感覚。

お次はなんだ。findAllメソッドが無いのか。BeautifulSoupのバージョンをPython2.7に対応するものに上げた際、PEP8(*2)に対応していない名前のメソッドが軒並みリネームされたらしい。findAllはfind_allになった。
それでも、やはりfind_allがないと来る。ただし、NoneTypeオブジェクトにはfind_allがないと来た。これはこれは。
BeautifulSoupがバージョンアップしたついでに、動作も変わってしまったようだ。以前は捕まえていたhtmlタグを見つけられなくなっている。

結局、Python2.7対応というよりは、BeautifulSoupと正規表現をいじるのに時間の大半を費やしてしまった。
パフォーマンスとか、取っているのに使っていない要素とか、いろいろ手直ししたいところはあるけれど、疲れたのでやめにした。


*1 説明しよう。BeautifulSoupとは、Webページの内容をPythonで取り扱うためのライブラリとしてメジャーなものである。
*2 説明しよう。PEP8とは、Pythonプログラマなら順守すべきとされているコーディング標準である。逆らっても罰則はない。ソースを読んだ他のPythonプログラマから鼻で笑われるくらいだ。

原発災害とアカデミズム

俺を楽しませるためにがんばれよフクシマ。おそらくは、その３。


惜しい。事故から既に2年が経っている。ここで今さら「とりあえずの解答集」とか出されても困ってしまう。そもそも本書は解答を示してもいない。既存の解答に対する疑問・不満を提示している、というところだ。

この本で描かれているのは、ある日突然に生活者としての戦いを余儀なくされた研究者達の心の声である。彼らの戸惑いとか苛立ちとか憤怒とか恨み節とかが綴られている。
専門外の自分たちには、それどころか専門の研究者にとってさえも「それはまだ分からない」以外の結論がありえない脅威、低線量被曝に対してどう向き合うか。考えあぐねているうちに大学当局は勝手に安全宣言を出してしまった。え？それってアリなの？研究者としてどうよ。


全体の構成とかはなく、12人の著者がそれぞれの問題意識をもとに独自に議論を展開している。紙面の都合で論述が省かれたところも散見される。対象読者は日本語が読める人すべて。（想定した読み手に訴えるより、まずは自分たちの思いを吐露したい、という意識で書かれているように思えた）

とにかく色々と惜しい。研究者にとって拙速や見切り発車が罪であるならば、そう主張する者の本は時間をかけて練り上げられたものであることが望ましいはずだ。逆に今を切り出すリアルタイム性を求めるならば、むしろ紙の本という体裁を選択しなかった方がよかったのではないか。タイミング大事。