ありがとう

バンド仲間だったドラムの方がお亡くなりになったという知らせを聞きました。

私が就職のために東京に来て間もない頃、1994年ごろから吉祥寺で定期的に練習していたバンドでした。練習といっても半分ジャムセッションみたいなもので、集まってジャズの演奏したい曲を演奏し、練習後はデニーズで一時間ほどだべって解散という活動を2000年くらいまで続けていました。

彼はその後出身地である九州に戻られ、結婚してお子さんも生まれました。

お亡くなりになったという知らせを聞き、当時のバンドの仲間で再び吉祥寺に集まり、彼を偲びました。昔よく集まったデニーズはもうありませんでした。久しぶりにあった仲間たちは見た目あまり変わった様子はなかったのですが、仕事と家庭環境はみなそれぞれ異なるものをもっていました。20代の楽しい時期を一緒に過ごしたバンド仲間がお亡くなりになったという事実に、私は内心かなり動揺していました。

ご冥福をお祈りします。

無題

こんな歌の一節を思い出した。

I scream, you scream, we all scream, for ice cream!

これにはIT業界向けの替歌があって、

I bm, you bm, we all bm, for IBM

(bm = bowel movement)

昔IBMが業界を支配していた頃があって、よくジョークのネタにされたらしい。

(追記)この替え歌をどこで見たのかずっと思い出せなかったのですが、昔読んだSF小説「H・A・R・L・I・E」(デイヴィッド・ジェロルド)の一節だったのを思い出しました。

無題

最初に入った会社でこんな事があったのを思い出しました。

その会社はSIerの下請けで業務システムを開発する会社で、私は出たばかりのWindowsNT3.1をサーバーとしてシステムを開発するプロジェクトにPGとして従事しました。サーバー側にSQL Server4.21を入れ、クライアントにWindows3.1とVB3(英語版)を入れてクライアント/サーバーシステムを構築しました。当時サーバーといえばUNIXワークステーション(特にSunのワークステーション)であって「Windowsをサーバーにするなんてありえない」という時代でした。こういう構成のシステムはかなり珍しかったと思います。

色々とトラブルが発生したそのプロジェクトを終え、社内でプロジェクトの顛末について発表したところ、先輩エンジニアの一人が「信頼性ではWindowsはUNIXに及ばないな」という感想を漏らされていました。

自分はこの言葉に正直反感を感じ、ずっと引っかかっていました。先輩エンジニアのおっしゃった言葉は正しく、信頼性という点では確かに今に至るまでUNIXサーバーはPCサーバーより優れている。しかしこのプロジェクトを終えた頃からWindowsベースPCサーバーの快進撃が始まり、部門システムレベルではほぼUNIXサーバーを駆逐してしまいました。

お客さんにとっては品質も大事ですがコストパフォーマンスはもっと大事だったという事でしょう。少し劣るものが1/10の値段で手に入るなら、ほとんどのケースで少し劣るもののほうが選ばれるのだと思います。

確定申告

今年も確定申告の季節がやってきました。

まず申告の準備として、町田商工会議所の記帳指導の方に弥生でつけている帳簿をチェックしてもらいました。帳簿をチェックしてもらうのは3、4年ぶりくらいです。(青色でつけています。)銀行預金の科目が違っていた他は特に問題はなく、ほっとしました。

さて申告するかという段になって、ICカードリーダーを付けて住基カードを読ませ、申告しようかというところで気が付きました。電子証明書の期限が切れています。公的個人認証サービスの電子証明書は、発行から3年が有効期限で、期限がきれたらもう一度市役所で電子証明書を発行してもらわないとならないとの事。

さっそく町田市役所に行って電子証明書の再発行の手続きをしに行きました。町田市役所は新しい庁舎になったばかりで、非常に綺麗で広々としていました。再発行手続きは30分くらいで終わりました。手数料は500円です。

新しい電子証明書を使ってさきほど確定申告をおこないました。会計ソフトから直接申告データは送れなかったので、まず国税庁の「確定申告書等作成コーナー」というサイトに行って「決算書作成コーナー」で数字をポチポチ入れて決算書を作り、e-tax用の決算書ファイルをダウンロードし、今度はそいつを同じ確定申告書等作成コーナーの「申告書作成コーナー」に食わせて(また去年の申告データも食わせて)それらのデータをベースに申告書を作成、決算書と申告書を一緒に送信して今年の確定申告は完了です。

途中何度かIEがクラッシュして挫けそうになりました。作成途中のデータはこまめにダウンロードしておいたほうが良いかもしれません。

PiO

懐かしいものを見つけた。

http://p6-kei.hp.infoseek.sk/151_Pio/PiO.html

子供の頃、パソコン雑誌というのは自作したゲームプログラムを投稿する雑誌のことでした。私はゲームというものが作れる事がわかると、プログラムを作っては雑誌に投稿する事を繰り返すようになりました。

最初は電波新聞社の「月刊マイコン」という雑誌に2回投稿したがボツになり、3回目は工学社の「PiO」という雑誌に中学生になって投稿してやっと掲載されました。このページのPC-6001用ゲーム「Bug Fire!」がそれです。3ページと6/10ページが掲載され、原稿料は3万6千円でしたが源泉徴収を取られて3万2400円受け取った覚えがあります。

私にとっては、周囲の誰もやっていない、誰も教えてくれないことを一人で調べてプログラミングに熱中した子供の頃の日々は人生の宝物です。

PC-6001にはアスキー社から出ていたSEAM-60というアセンブラの開発環境を乗せて、マシン語でプログラムを開発していました。当時はプログラムの保存手段が音楽用カセットテープという状況だったので、まずプログラミングの前にカセットテープからプログラムを読み込ませ、プログラミングし、テープに保存して、それからプログラムを実行という感じだったと思います。ステップ実行、ブレークポイント、ログ出力なんて高級なことはできないので、「実行 –> 暴走 –> 原因を推測する」という繰り返しだったと思います。

参考になった本は「PC-Techknow 6000」という本で、たしか6001で使えるサブルーチンコールが(今で言うAPI?)に関する資料が充実していた記憶があります。Z-80のマシン語は何かの本で勉強したはずなのですが、どうやって勉強したか思い出せません。

「Bug Fire!」というゲームは元ネタがあり、PC-8001用のゲームとして開発されたものをPC-6001用に作ってみたかったのです。プログラムコードは公開されていましたが、マシン語を逆アセンブルして読むのは大変だったので、ゼロから作ってしまいました。

子供に買い与えてはみたもののまったく未知で理解できないPCなるものに子供が毎日熱中しているのを見て「そんな事ばかりしていないで勉強しなさい」とは一言も言わなかった両親には本当に感謝しています。たしか、まだファミコンのない時代だったと思います。

SyntaxError: Unexpected token ILLEGAL

Javascriptを書いていて、こんなエラーが出た。(Chromeで)

SyntaxError: Unexpected token ILLEGAL

自分のコードは、コード自体がDjangoのテンプレートで動的に変わる文字列の部分があり、ここでエラーが発生していた。

var aaa = ‘{{ my_test_value }}’;

なぜここで?と思ってしばらく悩んだが、my_test_valueには改行コードが含まれることがあり、この改行を取り除くコードがこんなかんじだった。(Python)

my_test_value = aaa.replace(‘n’, ”)

エラーの原因は、aaaに「nr」が含まれていて、「n」だけ除いた結果「r」だけ残っていたのが原因だった。rは出力を見ただけでは気が付かないが、Javascriptインタープリタにはちゃんと見えているので、謎のエラーとなっていた。

 

昔私が新人の頃、ソースに全角スペースが入って謎のエラーになったのを思い出した。人間には見えないが、マシンには見えるのである。

create_login_url raise NotAllowedError

GAEでGoogleAppsにインストールできるPythonアプリを作っていて、OpenIDでシングルサインオンさせようとしているが、users.create_login_urlでNotAllowedErrorが発生する。

なぜだろう?と思って「GAE NotAllowedError」で検索してみるが、このエラーで苦しんだケースは皆2年ほど前の古いケースで、自分の場合にはあてはまらないようだった。

2時間ほど考えて、やっと気がついた。原因は、GAEの管理コンソール「Application Settings」の「Authentication Options」が「Google Accounts API」になっている事だった。正しくは、ここは「(Experimental) Federated Login」でなければならない。

Google Calendar Data APIで「予定の時間枠のみを表示」カレンダーのイベントが読み取れない

Google Calendar Data APIで、通常の共有設定がされているカレンダーのイベントは読み取れるが、「予定の時間枠のみを表示」共有設定がされているカレンダーのデータを読み取ろうとすると「does not have read privileges on the calendar google api」が返されて読めない。

感覚的に「予定の時間枠のみを表示」権限があるのだから、題名や内容は読み取れないにしても時間枠だけの結果が返ってきてもいいのでは?と思ったが、そうではなかった。クエリーのパラメータを調整すれば読み取れるようになるかな?とも思ったがそれも違った。

答えは、クエリーを作るときのProjectionを「full」ではなく「free-busy」にする事だった。

http://code.google.com/intl/ja/apis/calendar/data/2.0/reference.html#Projection

今までProjectionにfull以外の値を入れたことがなかったので、盲点だった。

普通のシステムではデータに対する権限は「読み取り」と「書込み」の2種類しかないことが多いので、「読み取り権限がありません」というメッセージを「データに対するどんな権限もありません」と(無意識に)理解してしまったのも間違いの元だった。

「読み取り」権限はなくても、「時間枠だけの読み取り権限」ならあるのだ。