真のアルファブロガーになるには。。。

ここのGIGAZINEの記事
真のアルファブロガーになるには何をすればいいのか？
http://gigazine.net/index.php?/news/comments/20070508_alphablogger/
によると、いろいろ書いてありますが、結局

真のアルファブロガーになるには
（以下斜体は上記記事より引用）

1.たくさん更新する

2.その中で自分独自の意見と真実を上手に書いて表現していく

3.他者からどんなに非難されようが批判を受けようが人格攻撃されようが無視して書き続ける

4.来たるべき注目される時、すなわち「運」が向いてくるまで上記3つを行い続ける


だそうです。
うーん、たしかに、書き続けるのがたいへんそうですね。
ウィリアムのいたずらも、がんばります！？

ソフトウエア資産は、混乱したままにしておくと、不良債権化する

　以前書いていた、シリーズ「オブジェクト指向分析（開発）の存在理由」、アジャイルは、「修正すると、よくなる」という信念に基づいている というところでとまっていると思います。

　で、そこでは、オブジェクト指向、アジャイルは、修正するとよくなるという考え方に基づいているが、実際は、修正するとわるくなるケースもあるというか、ある一定以上、修正してしまうと、そこからは発散してしまうという話を書きました。

　つまり、未知のシステムなんだけど、システム規模はちいさいようなとき（ベンチャービジネスのようなときや、ある企業の新規事業における開発とか）には、システムを見切れるので、発散しないから、オブジェクト指向でもいいんだけど、
　収拾もつかなくなりそうな大きなものに対して、無防備に、ばーんと突入してしまうと、システムが発散して、収拾がつかなくなると。。

　かといって、DOAにすればいいかというと、そもそも、システムが大きいから、DOAで見切れず、オブジェクト指向にしたわけで。。。ということで、DOAにするだけでは、解決方法にならない。

---

■ただし、理論上は、成立する方法はある。

　ただし、実務上では認められないけど、理論上では、できる方法はある。

　オブジェクト指向で発散する直前に、システムをすべてDOAベースで組みなおす。
　つまり、混乱する前に書いてきたものを捨てる。


　リファクタリングは、インターフェースを同じにするなど、過去に引きずられる。でないと、インターフェースがあわず、いつまでたってもつくりなおしになるから。
　でも、過去にひきづられると結局つじつまが合わず、やっぱりどこかで発散する。

　だから、いったん捨てます。
　混乱したソフトウエア資産は、それを修正すると、新規で作るよりたいへん、
　つまり、不良債権化してしまいます。
　なので、DOAベースでもう一度作り直しきれいにして、そこからスタートしないと、不良債権の山になってしまいます。

　具体的な説明が要りそうだけど、これは、また、このシリーズのつづきで。。。

プログラムやテストデータを自動生成する方法 その３ 雛形ソースの概要

　雛形ソースを作成し、Excelの仕様書を用意すると、プログラムのソースやテストデータを生成する方法について説明するシリーズ、「プログラムやテストデータを自動生成する方法」です。

　前回、インストールしました。
　このシステムでは、
　　・雛形
　　・仕様書
　　・ソースファイルを作るExcelマクロ
　が必要です。

　今回は、そのうち、まず、「雛形ソース」について説明します。

---

■雛形ソースの仕組み

　雛形ソースは、

・繰り返し部分（開始と終了）
・仕様書の値がはいる部分
・条件文の部分

　を示す「タグ」以外は、出力するソースと、同じ内容です。

たとえば、前回、サンプルとして作成したものの雛形である、app_c.txtの初めの部分（全体は長いので初めの部分だけ取り出します）をみると

/*=============================================
FILE: $#$CELL B2$#$.c
==============================================*/
#define	_$#$CELL K2$#$_C
#include "$#$CELL B2$#$.h"

$#$REP 5$#$#include "$#$KETA B$#$.h"
$#$REPEND A$#$

/*=============================================
FUNCTION DEFINITIONS
==============================================*/

となっていますが、青い字の部分が、その「タグ」の部分、それ以外は、そのまま出力される部分です。

---

■タグの書式

　タグは、$#$ではじまり、$#$でおわります。この間に、以下に決められた文字を書くことで、意味を持ちます。

　なお、$#$という文字を直接書き出すことはできません。
　これを書く場合は、$#$CELL セル位置$#$を使うのですが、それについては、話が進んでから書きます。

---

■タグリファレンス

　タグは、これだけしかありません。

●繰り返し部分（開始と終了）
＜＜繰り返しの開始＞＞
$#$REP 行数$#$
　REPがくると、そこから、REPENDタグまでをくりかえします。
　行数は、仕様書の繰り返し開始行数を示し、ここから、REPENDの
　桁で指定されるところが、空白になるまで繰り返します。

＜＜繰り返しの終了＞＞
$#$REPEND 桁$#$
　REPで開始された繰り返しを、ここまでおこなう。
　そして、１行、仕様書のチェック行を上げて、チェック行の(REPENDタグの）
　指定桁が空白だったら、繰り返し終了、そうでない限りREPにもどって、くりかえす

例：
$#$REP 5$#$
あああ
$#$REPEND A$#$
　仕様書の５行目から順番に見ていき、REPENDにきたら、１行あげ
　６行目にして、セルA6が空白でなかったら、REPにもどって、６行目の内容をもとに
　REPENDまで処理、REPENDにきたら、１行あげ
　A桁が空白でなかったら、REPにもどって。。。
　と、空白になるまでくりかえす（結果として「あああ」の行がいっぱいできる）

＊現在入れ子はできません

●仕様書の値がはいる部分
＜＜セルの値を直接入れる＞＞
$#$CELL セル位置$#$
　セル位置の文字を出力する
例：$#$CELL B2$#$　セルB2の値を出力する

＜＜繰り返し中、指定桁を出力する＞＞
$#$KETA 桁$#$
　繰り返し（REPとREPENDの中）でないと意味がありません。
　現在の繰り返しにおける行数において、指定された桁の内容を書き出します。

例：$#$REP 5$#$#include "$#$KETA B$#$.h"
$#$REPEND A$#$

はじめ、REP 5の指定なので、
　５行目をみて、KETA Bのところで、セルB5の内容を書き出します。
　そしてREPEND Aの指定で、６行目にして、A6が空白なら終了、そうでなかったら、
　チェック行を６行目にしてREPまで戻ります。
　６行目をみて、KETA Bのところで、セルB6の内容を書き出します。
　そしてREPEND Aの指定で、７行目にして、A7が空白なら終了、そうでなかったら、
　チェック行を７行目にしてREPまで戻ります。
　７行目をみて、KETA Bのところで、セルB7の内容を書き出します。
　　　　：
　　　　：
と、REPENDで指定される、セルA○行が、空白になるまで、１行ずつチェック行をあげて、繰り返します。


●条件文の部分
＜＜セルの値条件＞＞
$#$IFCELL 指定セル,条件文字列$#$
　指定セルが、条件文字列と一致していたら、$#$IFEND$#$までを書き出し、
　一致しない場合は、書き出しません。

＜＜繰り返し中の値条件＞＞
$#$IFKETA 桁,条件文字列$#$
　繰り返しでないと意味がありません。
　繰り返し中で、現在チェックしている行の、IFKETAで指定された桁が、条件文字列と一致したら、$#$IFEND$#$までを書き出し、一致しない場合は、書き出しません。

＜＜条件の終わり＞＞
$#$IFEND$#$
　条件IFCELL、IFKETAの終わりをしめします。
　利用法は、それぞれのところに書いてあります。

＊現在入れ子はできません


●これ以外の複雑なことをやらせたい場合、仕様書側で、いろいろ処理します
　（計算とか、条件の判断は、仕様書のExcel側で行います）
　詳しいことは、次回の「仕様書」で書きます。

---

　ということで、タグの概要はおしまいです。
　タグについて、実際の詳しい使い方は、一通りの説明が終わり、使用法にはいってからします（さっきの$#$を書き出す問題も、その使用法で行います）

　なので、次回は先に進み、「仕様書」の概要です。

デザインパターンと設計上のレベル

前に書いていた、要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているの話、シリーズ化してしまい、前回、次回のこのシリーズは、デザインパターンの話と書いておきながら、かいてなかったので、これについて書いて、このシリーズを終わらしてしまいたいと思います。

---

■デザインパターンとは

　まず、デザインパターンというのは、ここでは、GoFの、デザインパターンをさします。

簡単な説明と、Javaでの書き方は、ここ
JavaでHello World ＞ デザインパターン
http://www.hellohiro.com/pattern/
が分かりやすいと思います。

---

■で、このパターン化したもののレベルは？

　ということで、このデザインパターンなのですが、問題は、どのレベルのパターンを、パターン化したかということです。そう考えると、

前に、こういう図

業務
　｜＊１
アクティビティ層（＝アクティビティ等）
　｜＊２
入出力と、基本操作群（＝外部設計の世界）
　｜＊３
ＯＳ／言語提供モジュール


　を書きましたけど、ここでの＊３のところ、つまり、プログラムにおけるパターン化といえます。

　たとえば、Stateパターンは、状態の違いによって、処理を変えられます。
　Observerパターンも状態の違いによって、こっちは、それに依存するオブジェクトに通知して処理を行うことができます。

　どっちにしても、これは、状態遷移における、オブジェクト指向言語でプログラムを組むときに有効な手段です。

　ただ、Cで書くんなら、クラス概念はないので、ステータスをつかって、状態遷移を表現し、状態が遷移したイベントがあがったら、ディスパッチするということになります。
　で、Javaでも、そうやって書くこともできます。

---

■設計上には、もっと上位のレベルでのパターン化が必要

　しかし、機能を設計するときには（外部設計に相当するレベルの機能設計）、もう少し汎用的な話、つまり、状態遷移にもっていって、状態遷移図を描いて、その遷移の過程でディスパッチする関数なり、機能内容を記述するように落とし込むということが大事であり、設計のパターンとなります。

　つまり、設計上における考えるパターンというのがあり、そのパターンと、このデザインパターンとは違う（極論言うと、設計は、オブジェクト指向を意識しなくてもできるわけで、その場合、オブジェクト指向に沿ったデザインパターンというのは、違う世界の話になる）わけで、

・設計上におけるパターンをまず考えて、
・それを、デザインパターン＋オブジェクト指向のプログラムで書けるか

という順にかんがえることになります。
（そして、べつにデザインパターンを使わなくても、プログラムが書けるなら、作業上は問題ない）
　

---

■設計上のパターンとは

　で、設計上のパターンは、入出力と、基本機能となり、基本機能を組み合わせてできた機能を、どの条件で動かすかという表現方法の１つとして、状態遷移図を利用した方法があるということです（それ以外にも決定表でかくとかもあるし、そもそも、遷移しない、直線的に進むものなら、わざわざそんなこと考えなくてもいい）

---

ってことで、このシリーズはおしまいとします。