2013年4月21日日曜日

heroku db:push は deprecated

heroku db:push すると「Taps Server Error: PGError: ERROR:  time zone displacement out of range: "2011-10-22 12:00:00.000000+5894056800"」などというエラーになって、ネットで調べると Ruby のバージョンを Heroku に合わせて 1.9.2 にすればいいという情報がいっぱいあるんだが、rbenv で 1.9.2-p320 に下げても同じエラーが出てしまう。

もちょっと調べたら、そもそも db:push 自体が deprecated だったようだ。


というわけで、PG Backups を使うのが正解らしい。


2013年3月24日日曜日

アウトバックに J-Force JF-BTFM2K

うちのアウトバックは2005年5月購入(マイナーチェンジ直前)。センターコンソールのシガーソケットのそばに蓋があるので、この形状じゃ挿さらないかなぁと思いつつ購入した。



結果、挿さったけどぎりぎり。押し込んだら頭部がうまく傾いて、奥の端子に何とか接触した。一応使えそうだ。USB ケーブルは問題なく繋げた。


グローブボックスにある電源取り用のシガーソケットには余裕で挿さった。グローブボックスの蓋と本体の間には USB ケーブルが通るくらいのちょうどいい隙間があって、ケーブルも引き出せた。


レビューを見ると、LED が明るくて目障りだという話もあるので、グローブボックスに収めとくのもいいのかな。周波数を変えるのはちょっと面倒だけど。

どっちに挿した時でも、少し動かすと電源が切れる(シガーソケットなのでしょうがない)けど、すぐに再ペアリングしてくれて再生も再開した。便利だ。

以上、同時期のレガシィ/アウトバックで JF-BTFM2K の購入を検討している人のために。

2013年2月27日水曜日

初めての青色申告

初めての青色申告に行ってきました。相談会場で税理士さんに詳しく見てもらったら、「これは模範になるような帳簿ですね」というお言葉をいただきました (^v^)

営業所得で青色が初めてだっただけでなく、退職所得あり、給与所得あり、雑所得あり、配当所得あり、寄付金控除あり、加えて国民年金も健康保険(任意継続)も自分で申告という、なんだか派手でとてもややこしい申告でした。退職所得を申告するために、確定申告書の第三表を使ったのも初めて。よく乗り切ったと自分を褒めてやりたい。うん。

提出する資料の他に、念のため仕訳日記帳と総勘定元帳を印刷して持っていったら、詳しく見てもらえたし、質問もしやすかった。

帳簿つけと決算には「やよいの青色申告」を使いました。決算書が提出の書式で印刷できるので楽ちん。ただ、確定申告書Bの自動計算のサポートは、国税庁の確定申告書作成コーナーの方がいいみたい。両方でやってみたけど、やよいでは第三表を作るのが大変だった。結局、決算書を「やよいの青色申告」で印刷して、確定申告書Bは国税庁のサイトで作りました。(第三表が不要ならやよいだけで簡単にいけそうな感じ。)



こういうソフトがあると帳簿つけと決算は楽だけど、ソフトさえあれば問題なくできるかって言うとそうでもない。やっぱり、ある程度ちゃんとした簿記の知識と、実務的な知識が必要だったなぁと感じています。何冊か読んだ中からおすすめの本を紹介すると:



この本↑の一つ前の版を読みました。内容はさほど変わらないだろうということで新版へのリンクでご紹介。教科書的な本です。簿記の原理から、具体的な手続き、そして決算まで説明してくれています。決算手続きの理解にはとても助かりました。



図が多い大判の本↑。絵が多いぶん内容が薄いかと思ったら、簡潔にまとまっていて意外と役に立ちました。そして分かりやすかった。



実務系で一冊だけならばこれかな↑。よくまとまっていて分かりやすい。 巻末の必要経費勘定科目の早見表(五十音順)が実例としてとても助かりました。



ちょっとこれ一冊では足りないかなって感じだけど、やさしくて丁寧に書かれている本↑。最初の入門にはよさそう。

今回の確定申告の時期が過ぎればまたこの手の本は新しくなるでしょうが、まあご参考まで。

これらの本を基本に、細かいところが分からなければネットで情報を探す、で乗り切れた1年でした。

あと、税理士さんには、今度からこう帳簿つけたらいいなどの助言もいただきました。ありがたいことです。無料相談、使わない手はありませんね。

2013年2月18日月曜日

フレームワークを理解しようとしてはいけない

久しぶりに自分で iPhone アプリを作ってみた。簡単な機能を持ったものを3日かけて作った。いや、作ってたら3日でできた。意外と早かった。

そこで感じたのは、フレームワークそのものを理解する必要はないってこと。少なくとも、普通のプログラマは。

というかむしろ、フレームワークそのものを理解するのに労力をかけるのは、プログラマとしての生産性を下げるからよくないとさえ言いたい。

フレームワークを熟知するのは、フレームワークの開発者と、それを解説する人だけでいい。プログラマは、そういう人達が書いたサンプルコードから機能を理解し、それを手直しして自分のコードにすればいいのだ。

これはずっと学校で教えてきた自分のスタンスを崩すものだけど、現状では真実だと思うので仕方がない。

学校では、少なくとも私は、言語の文法とフレームワークはできれば熟知するもので、その上で作りたいものをつくるべき、と考えていた。カリキュラムもだいたいそのように組んできた。仕組みは分からなくていいから動くものを作れ、という方針の授業もやっていたけど、あくまで入門向けのやり方としてだった。

だから、学生が授業の課題や卒業研究のためのプログラムを、どこかから見つけてきたようなコードを手直しして作ろうとし、どうも動かないと言っている様を少々苦々しく見ていた。

でも現状ではそれしか手がないんだな。フレームワークは巨大になりすぎた。全体を把握するなんて一介のプログラマには困難。インタフェース通りに動くとも限らないし。それに、日々どんどん変わったりする。覚えたって無駄になりかねない。

ここは前向きに諦めよう。フレームワークを理解しようとしてはいけない。サンプルコードがあれば十分だ。より創造的な作業のために時間を使おう。

2013年2月15日金曜日

メモ:パブーの PDF メールアドレス埋込み

パブーにアップロードした自作 PDF が読者によってダウンロードできないとか、サイズが巨大になるとかいう問題があった。メールアドレス埋込み設定をしなければ大丈夫らしい。その原因、というか回避策が見つかったので書いておく。

特定の PDF 形式だとダメらしい。dvipdfmx で生成したもので問題が出ていた。その PDF ファイルを、一度 OS X のプレビューで開き、別名で保存すると、内容は(多分)一緒だが形式が変わる。その形式だとパブーに登録しても問題なくダウンロードできる。

つまり、dvipdfmx の出す PDF ではダメで、プレビューの出す PDF なら大丈夫。多分、Acrobat とかでも大丈夫なんだろう。

2013年2月14日木曜日

メモ:alltt 環境と \Underline の相性

pTeX で alltt.sty と jumoline.sty を使って
\begin{alltt}
\Underline{Hello, world!}
\end{alltt}
とかしたら、コンマが
! Improper alphabetic or KANJI constant.
というエラーになった。これを
\begin{alltt}
\Underline{Hello{,} world!}
\end{alltt}
としたら(なぜか)回避できたっぽい。

2013年1月28日月曜日

電子マネーはトマト以下

久しぶりに電子決済について書いてみる。

電子マネーの流動性

電子マネーは、流動性が極端に低く抑えられている。

資金決済法第二十条2に、電子マネーは払戻しをしてはいけないとある。一度買ったらお金に戻せない(売れない)のだ。

これはものすごい規制。およそ自分の持っているもので、売ることができないものなんてほとんどない。臓器とか売春とか猥褻物や偽造通貨…とても悪いものばかりしか思いつかない。

つまり流動性について、電子マネーは、トマトにすら劣るってことだ。(別にトマトと比べる必要はないが)

通貨 > 貴金属 > パチンコの換金用の景品 >> トマト >>>越えられない壁>>> 電子マネー

これが電子「通貨」とか、笑っちゃうね。

なんでこんな規制ができたのか。ちゃんとした経緯を知らないけど、よく問題だと聞くのは、クレジットカードからお金を引き出す手段になる(電子マネーをクレジットカードで買ってそれを現金で払い戻す)こと。あと、RMT に使われやすいとかもあるのかな。まあ、クレジットカードからの現金化は、利用条件で定めて、クレジットカードで買った分は払い戻さないようにシステムを実装すればいいだけなので、あまり理由になる気はしない。

で、実は違う理由だろうなと推測している。あくまで推測。

電子マネーで払戻しができると、電子マネーの流動性が、銀行決済やクレジットカード決済を上回る可能性が高い(と私は見ている)。つまり、

電子マネー > 銀行決済やクレジットカード決済 > 現金 > 貴金属 > …

となってしまう恐れがある。これは、銀行やクレジットカード会社にとっては許しがたい。どんな理由をつけてでも、電子マネーの流動性を抑えたかっただろう。

もうひとつは政府。というか財務省なのかな。財務省はきっと、銀行やクレジットカード会社をコントロールし、日本の経済を動かしている(動かしたい)、と思ってるはず。だから、さらに流動性が高く経済に影響を与える可能性があって、今のところコントロールの手段が見つからない電子マネーの出現を嫌がったのでは。

今のところ、それはうまくいっているようだ。Suica や Edy、ウェブマネーや BitCash が、いくら便利なことがあると言っても、それは限られた場面。日常生活での決済の多くは、依然として銀行、クレジットカード、現金だ。

電子マネーは自分の財産?

自分の財産は自分の所有物なので、原則として好きに売ったりすることができる。基本的人権の財産権(所有権)だ。

電子マネーは自分の財産か。法律で一所懸命に保護してくれているところを見ると、そう扱ってもらっているようだ。が、自由に処分することは禁止されている。

何を守ろうとして? 他者の同じくらい重い権利を守ろうとして(=公共の福祉)、ではなさそうだ。

電子マネーの将来

この一方向関門(現実通貨→電子マネー)が維持されたまま電子マネー側の経済が大きくなるためには、現実通貨の機能がそっくり向こう側にもなくてはいけない。例えば、電子マネーを預かる銀行とか。そうやって経済が成長するには、ものすごい時間がかかるだろう。(それよりも、電子マネーを預かる銀行が現れた瞬間、法律で規制されるほうに私は賭けるが。)

それでいいのかな。たしかにそうすれば、銀行やクレジットカード会社の利権は守られるし、政府は楽ができる。でも、電子マネーに本来あるはずの極めて高い流動性を生かしたマイクロペイメントの市場(主としてコンテンツ市場だと思う)は発展しないと思う。

日本でそのように規制すれば、このネット時代、市場を外国に取られるのは火を見るより明らかだと思うんだが。

軽くて場所を取らず、速く移動できるものが通貨の地位を置き換えてきたことを思うに、国家の通貨(のひとつ)が早晩電子通貨になるのは必定だろう。おかしな足掻きはやめて、ちゃんと将来を考えたほうがいいんじゃないだろうか。