2004/01/29

ぼちぼち税務申告の準備。毎年、ぎりぎり(4/15日)まで引き延ばしてきたが、今年はひとあじ違う。 GnuCashを導入したからだ。

昔からずぼらで、記録の類をきちんと書くのは苦手。特に、家計簿、小遣い帳の類は、決して残高が合うことがないためすぐに嫌になって、続いたためしがなかった。会社を作った頃、"Accounting for the new business"なる本を買ってきて読んでみたのだが、さっぱり分からなかった。用語が全然わからないから、用語の組合せも全然わからない。

しかしこういうのもプログラミングと同じ、習うより慣れろ、が効くようだ。わからなかったらやり直せばいいやって感じでGnuCashにちくちく入れていったら基本的なところがわかってきた。だいたい、基本的なケースではひとつのtransactionに関係するaccountはふたつだけだし、 GnuCashはaccount画面に直接入力できるので、複式であることを意する必要がほとんどない。金の行き先はどこか、もしくは出どころはどこかを考えておけば済む。

複式簿記は本を読む限りではめんどくさそうだったが、ツールのサポートがあれば、単式よりもずぼらな人間に向いていると思う。単式だと金額があわなくなることがしょっちゅうなんで嫌になるが、複式だとエントリ毎に基本的に帳尻が合ってくれるし。

会社の会計だけGnuCashでやっていたのだが、税理士に持ってゆく書類を用意してる時に、ついでだからと家計の方も別ファイルに入れ始めたらはまって徹夜してしまった。会社はもちろんだが、基本的に個人の方も小切手とカードが中心で現金決裁があまりないので、その点では帳簿付けは楽である。

Tag: 生活

2003/12/18

#permalink

新しいことをする場合、最適な仕様というものが、作ってみるまでわからないということはままある。実際に作って、動かして、使ってみて、直して…と、粘土をこねるみたいにして形を作ってゆかざるを得ない。ただ、どちらに向かうべきかがはっきり見えなくなることが時々ある。こういう作り方をしている時は、テストもコードに合わせてどんどん変化してゆくので、テストドリブンというのも(方向を決めるのには)あまり役に立たない。

そんな時は、ドキュメントを書いてみると役に立つ。ある程度形が出来てきたところで、そのAPIのマニュアルを書き下してみるのだ。すると、自分の中で整理がついていないところは、綺麗に説明が出来ない。不必要に長い説明を必要とする場合は、方向がおかしいと判断できる。逆に、APIをこう変えれば説明しやすい、というアイディアを得ることもある。

最初にちゃんとした仕様を書いて…という形式との違いは、既に動くものが手元にある状態で、それを説明するために書く、ということ。

Tag: Programming

2003/12/11

#permalink

RFC:2822ってまじめに扱おうとするとめんどいなあ。ところでstructured fieldはどうしたってCFGなんだが、誰かがアドレスをパーズするPerlのregexpを書いてたよなあ、どうやったんだろうと思ってぐぐってみたらあった。うーん変態的。でも良く見たら「コメントはあらかじめ取り除いておく」って書いてあるじゃん。コメントはネストするからRGじゃ無理だよな。そうか、残りはgroupがネストすることはないからRGでいけるのか。

Tag: Programming

2003/12/02

#permalink

チュートリアルについて。バカが征くより:

以前、Javaの強みはコミュニティにあるといいましたけど、その特徴の1つが Java Tutorialです。これはSunがやってるのでコミュニティの力というと叱られそうですけど。でも、Java Tutorialがあるおかげで、「何かを作ったらチュートリアルを用意する」というのがJavaの文化として摺り込まれちゃったんですよね。Jakartaを見ても、チュートリアルのないシステムはありませんし。

そうだなあ。布教には重要なのだろうなあ。個人的には、チュートリアルの類は滅多に見ない。チュートリアルというのはどうしても性質上"How to"が中心になりがちな印象があって、でも本当に知りたいのは"Why"なので、読んでていらいらさせられることが多いから。いや、そうでない良いチュートリアルもあるのだろうけど。 "The Unix Programming Environment" みたいに、WhyとHowを絶妙にブレンドしたドキュメントが書ければベストだと思う。

ちなみにその前のCLOSに対する記述は、まさしくそのとおり。

CLOSはとても歴史のあるシステムとは思えません。CLOSが世に出てからもう10 年以上経ってますよね。にもかかわらず、この情報の少なさは一体どういうことですか。
Paul Graham氏の"ANSI Common Lisp"なんて上っ面をなでてるだけ。Web上のチュートリアルもいくつか見ましたが"Common Lisp Cookbook"が、まぁマシかという程度。結局"Common Lisp HyperSpec"を見なきゃなんないなんて状況はおかしいですよ。こっちは仕様書が読みたいんじゃなくて、使い方が知りたいんですから。

似たような状況はCLIMにもある。すごいシステムだと思うんだけど、まともなドキュメントは仕様書しかない（自分も使ったことは無くて、仕様書読んで感心して、部分的に実装したりしただけだけど）。

LISP/Scheme界隈はまだユーザー＝実装者な空気が強くて、仕様書があれば使える&実装できるって状況に甘んじちゃっているんだろうな。それじゃ裾野がひろがらないからダメなんだが。

あー、Gauche-0.7.3ではオブジェクトシステム周りのドキュメントを多少充実させる予定。あくまで予定だけど。

Tags: Programming, Lisp

Comment (1)