Blog

開発に関することなので、このカテゴリで。

他のアプリケーション開発でも分かる通り、一度やらなくなると、 また始めるまでにかなりのエネルギーを必要とする事が自明なので とりあえず「全く考えない」という状態にはしない。
前向きに悩むのは「現在の実装に具体的な限界を感じた」時か 「これから取り掛かる部分の作戦に自信が持てなくて、なんか嫌な予感がする」時で、
一生懸命頑張るという方法を取ってうまくいったためしがないので、 参考になるソフトをぼけーっといじくりまわすか 関係ない箇所でもいいから絶対これが正しいと思える方法でプログラムを書くってのが現実的な気分転換の方法。
なんか悩んでる部分の正しい道筋がパッと見つかる瞬間があって、その時にすぐメモっておくのがポイント。

モチベーションをあげる方法としては、同じような関係のすごいアプリケーションを見るのが一番。
逆に誰かに追い越されて(？)自分の作っているソフトの価値が全く無くなる姿を想像したりすると大体いいことない。

住所録入力時のプレビューにも利用するようにした。
とりあえず、デザインでドキュメントを変更したらこちらにもちゃんと反映はされる。
プレビュー時にデザインを変更できるのは問題かな。
解決策としてはビューのコンストラクタにReadOnlyフラグを追加すること。
テンプレートのプレビューにも使っているので気を付けて修正する。
ReadOnly ビューの派生で編集可能なビューを作るのが正しいような気がするが、うまい方法が見当たらない。
あと、差し込みプレビュー機能が必要なので、ビューにプロパティを追加する必要があるな。
できる限り無理が無いように設計／実装しておくけど完璧にはならなそうなので、 こちらもいい方法があれば後でいくらでも修正するってことで。

自宅宛／勤務先を分ける。
個人クラス＝KKAPersonalData
住所クラス＝KKAAddressData を基本として、
自宅宛クラス KKAHomeAddress
勤務先クラス KKAOfficeAddress を KKAAddressData の派生で作る
KKAHomeAddress はメンバに連名用の KKAPersonalData クラスのリストを含む(かリストの派生にする)
KKAOfficeAddress はメンバに会社名、所属、役職を持つ。
KKAContactData は KKAPersonalData の派生で、 メンバに KKAHomeAddress と KKAOfficeAddress を持つか、KKAAddressData のリストを含む(かリストの派生にする)
これで一応既存のWindows用のデータと同じ構造になる。
自宅宛／勤務先という持ち方は制限があるように思えるが、 リストで持つとインターフェースが難しくなるのがなやましいところ。
まぁ、どっちかで実装して、やっぱりあっちにしようと思ったら直そう。

北洋銀行の窓口の女性に「この小切手換金したいんですけどー。」って言ったら、奥のほうから変わりの人が出てきて、
お互いよくわかってなかったけど、何度かどこかに電話で確認してくれながら、言われた通りに書類を書いて手続き完了。
広告収入って貿易なのか？
北洋銀行 の 手数料 は 2000円。
振込まれるのが待ち遠しい！

Google AdSenseの小切手換金は邦銀が良い!!によると、北洋銀行は手数料2000円らしい。
本当ならそれがいいので、あとで確かめに行ってみよう。