AKI H8 3048F

一年以上前(調べたら2005年10月)に、秋月のマイコン評価キットを買っていたのを思い出して、
久しぶりにサンプルを打ち込んで動かしてみた。

オークションで買った当初、本も四冊くらい買って、少し頑張ったんだけど、
どうにもＬＣＤの前処理とか、アドレスの考え方とかアセンブラやらが難しかったので、
しばらくお蔵入りになっていた。
なので、今回も苦戦するかなと思っていたが、結構いろんなことがサクサク理解できた。
なんで前はわからなかったのだろうか？
少し考えた結果、主に使用した本が悪かったと結論が出た。

以前「マイコン技術教科書　Ｈ８編」
今回「Ｈ８ビギナーズガイド」

マイコン技術教科書の方が内容がありそうなんだけども、話がＨ８から離れることが多く、初心者にはきついです。
Ｈ８ビギナーズガイドはアセンブラ一行一行にコメントがついていたので、
とても読みやすかった。
今回、Ａ／Ｄ変換の意味がはじめてわかったし、まだ半分も読めてないんだけども、
前に比べればなかなかの前進だったかな。

次は、ＯＳを使ってみたいが、今のボードのＲＡＭ拡張は面倒な感じなので、
インターフェースに去年ついてたＳＨか、あるいはもっと容量のデカイものを買って遊ぶ予定。
ＬＡＮつきのやつがμLinux本でてたし、ちょっとほしいな。
そのまえに、今の3048Fで一度ＴＯＲＯＮも動かしたいなー。

簡単にできる仕事ってつまらない

開発も後期に差し掛かり、客先のムチャな要求も鳴りを潜めてきたため、
どうにも仕事がつまらないです。
できあがっている仕組みをいじるようなことがないため、
頭を全然つかわない作業ばかり。もう飽きたよ。
とくに不具合もないし、まあドキュメントも要求されないしで作業があまり無くどうにも退屈中。
みっちりテストなんかしちゃてます。

ただ、よりよい仕組みを考えたりする数少ないチャンスなので、
明日から仕事をしてるふりをしつつ、
何が設計上悪いのか、どうすれば改善するのかについて列挙みようかな。
自分が設計する際の抑えるべきポイントが発見できたらいいしね。
取り合えず今思いつくのは、設計とは少し違う問題もあるけども、

・データと処理を分離しないと仕様変更にたいして脆い
・フラグで処理をわけるときに、あちこちフラグを置かずに少ない箇所にまとめるべき。
・よいコメントを付ける（これはできてる）
・わかりやすい設計書をつくる（ソースをみなくても仕様の話ができる程度のもの）

このあたりはコードを修正する際につくづく思う。

ハンガリアン記法

ハンガリアン記法は、昔のWindows本をみると良く出てきたんだけど、
最近はあんまり見ない。
まあ、読んでいる本がLinuxやPerlばっかりのせいもあるかもしれないけども。

ずいぶんまえに、ハンガリアン記法について面白いことが書かれているのをみつけた。
面白かったことだけ覚えていたが、内容が頭から飛んでいたので探して読み直した。
↓ココ

ジュエル・オン・ソフトウェア

そうそう、アプリケーションハンガリアンとシステムハンガリアンの違いで、
型のプレフィクスではなく、意味のプレフィクスをつけることが大事だったんだね。

カメラの台数分ループさせるときは、
int i_count;
ではなく、
int cam_count;
みたいな感じかね。

良さそうなので、家で使うように習慣づけていつか仕事場で使いたい。

TRY!PC C++プログラミングのポイント

「TRY!PC C++プログラミングのポイント」という本の第一章を読んだ。
二部構成で、
第一章　ＳＴＬ，標準ライブラリ
第二章　デザインパターン
となっていて、久々にＳＴＬ関連の文を読んだので面白かった。
第二部が僕にとってのメインだったのだけども、
足りない常識や忘れかけていた事柄を補えて非常に満足。
関数宣言の後ろのthrow()、文字列ストリーム、ストリームイテレータ、
const_cast、仮想基底クラスあたりの知識はすっかり抜けていたし、
STLのアルゴリズムも久々に見た。なんか久しぶりすぎて懐かしい感じすらした。

Ｃ＋＋独学が柴田望洋の本ではじまったので、そこに載ってないものにはどーも苦手意識があったのと、
使う機会がそもそも無いために、なかなかなれることができずに来てしまった。
ちょっと面白く感じているうちに、プライベートでこういう高度なＣ＋＋を使って何か作る時期なのかも。

プログラム構造

私の派遣先では基本的なプログラム構造があり、皆それを前提に設計します。
プロセス間通信で、それぞれのメッセージに対して二次元のテーブルで関数を持たせています。
Ｃ言語なのですがで少しクラスっぽい構造のため設計しやすくなっています。
ただし、この構造自体を設計書に起こしてレビューするので、
クラスのようにバンバン作っている人は居ません。
でも、たくさん作って単一責任をそれぞれ持たせないと
「変化しやすい箇所を閉じ込める」設計にはできないため、
今の担当しているような仕様変更に脆弱なものを設計する羽目になります。
人から揶揄されようとも中規模のプロセスを設計させられた時には
クラスのようにたくさん作ってレビューアのド肝を抜いてやろうと考えています。

また、先日小さいプロセスを設計させられているとき、
プログラムの構造をハックすればスーパークラスのように
似たような処理をまとめておくことに気がつきました。
あとはいかに隠れて実現させるかということだけだったりします。
Ｃでもオブジェクトっぽくできるとは聞いていましたが、本当なんですね。
他にもきっと参考になる事例があるはずなので、今度ネットで調べるつもりです。