AB開発日記

ここ数日作業が順調に進んでいたので、引き続き、、と考えていたのですが、今日はやめです。さすがに明け方まで没頭していたので、今日はオフにさせてもらいます。ついでに、実家の配達業務を手伝うことになっているので、そいつをやりつつ、リラックスさせてもらいます。

ロイヤルホストはちと高い…

夜はいつも指名している美容師さんを誘って、ロイホに食事に行きました☆服屋も色々ありますが、美容師も色々大変だそうです。考えてみれば、服屋よりもお客さんに接している機会が多いし、資格やテクニックが問われ、仕事が終わってからも勉強をしなければやっていけません。キビシィ〜(><)。

帰り際にアクシデント発生！！

「バイバーイ」と、ちょっとコンビニで買い物をしてから、自宅へ帰ろうとしました。で、車に乗ってバイパスへ…と思ったら、助手席に見慣れない携帯…(゜Д゜)。オネーサーン、携帯忘れとるよ。自宅の場所がわからないので、どうしようもありません。夜なんで、肝心の美容院も閉まっているときた…。で、おいらは市外の自宅へと向かおうとしている。しょうがないんで、最後に別れた場所に戻って待機。人の携帯を見るのは悪いことですが、自宅へ電話してあげないと、おいらも帰るに帰れません。オドオドしていたら、携帯が鳴り出しました。画面には”自宅”と出てます。おそるおそる出たらご本人でした。「ごめーん、車の中に忘れたみたい。今からとりいくよ」と、事件は無事解決。人の携帯って、ヘタなところに忘れられると、連絡のとりようがないので、困ります。

作業してたら、気付かぬうちに明け方4時です/(–)/

自動インデントとコード補完のほう、完了しました。引き続き、コンパイラの最終調整を行いました。「無効な識別子」のエラーメッセージでちょっと不自然な動きとかがあったんで、それを修正。修正しているウチに、ついでにここも、こっちもこっちも…という具合で、連鎖的にコード修正をしてしまいました。んで、こんな時間になってしまったワケです。

明日、明後日はデバッガの改良に取り組みます。

バイトが重なれば疲れもたまるってもんです。昨日、一昨日と、作業はあまり進みませんでした/(–)/。ということで、今日は本気モードで取り組み中。先日思いついた自動インデントによる効率化、ペアステートメントのコード補完機能の追加について書いていきます。

• Class 〜 End Class
• Do 〜 Loop
• Enum 〜 End Enum
• For 〜 Next
• Function 〜 End Function
• Select 〜 End Select
• Sub 〜 End Sub
• Type 〜 End Type
• While 〜 Wend
• With 〜 End With

ABには、上記のように、ペアになっているステートメントが存在します。コーディングを行う際、大概の場合はこれらのステートメント間の領域はインデントを付加し、コードに対して視覚性の向上を行います。ここでポイントになるのは下の2点です。一見、単純なポイントのように見えますが、言語仕様に対して非常に重要な問題です。

1. 人間が読みやすいように、適切なインデントを付加する必要がある
2. ペアステートメントは一区間（ブロック）として捉えることができる

プログラマーがインデントを意識しながらコーディングを行うと、見やすいコードが出来上がります。これは熟練者であればあるほどです。ハードに直接関係の無い点ですが、ソースコードの保守管理という観点から、長期的な目で見ると、「拡張性、保守管理のし易さの向上」「バグの軽減」などに関わってくることは確かなようです。現在の市場において、皆さんの周りにある一般的な開発環境ならば、これらに対して「基本事項」としてサポート機能が搭載されていることと思います。同時に、ABも重視していかなければならない点です。

では、具体的にインデントに対してどのような制御が必要になってくるのでしょうか。これは、人間がいちいち考えて入力する必要が無いコード（前後の構文から予測できるインデントコード）はエディタが自動的に生成やろうというなんすね。ABは以前のバージョンから自動的にインデントを付加してくれる機能がついていましたが、その原理は非常に単純なものであり、まだまだ改良の余地が見られます。今回はそのことはじめとして、インデントの付加により視覚性が向上すると思われるペアステートメント区間内を、プログラマーが一度もインデントを入力せずにコーディングを行える環境というものを考えてみました。単純に、ブロックの初めと終わりのタブ文字の追加と削除を全自動にしてしまおうということなんですな。これが、改良してみると非常に使いやすいです。

今日は同時に、もう一工夫加えることにしました。こいつはBasic言語という代物がどんなに個性的な言語仕様であるか、私自身疑問に感じてきた点でもあります…。

私はC言語のスタイルが好きです（ABのヘビーユーザーさんであれば、薄々勘付いている方もいたのでは…！？）。C言語は扱う記号が多いです。C++ともなれば、私も知らないような仕様があったりと、奥が深いってもんです。単語数が少なく、キー入力の手間が省けるC/C++言語。しかもハードレベルでの制御が可能なその言語仕様は右に出るものはいないときます。逆を返せば、そのオモテヅラに馴染めないなんて場合もあるのかもしれませんが…。

• Basic言語 … 冗長的ではあるものの、確立された単語を利用している。扱う文字数は多いが、視覚性に優れる。
• C言語 … 記号による意味付けを積極的に取り入れている。ある程度の慣れが必要だが、熟練者であれば効率的なコーディングが期待できる。

これらの点を踏まえると共に、Basic言語はその言語仕様が抱える自らの矛盾を直視していかなければなりません。

Function name() As Long

…

End Function

よく考えてみてください。これって、いくらなんでも冗長的ですよね。Functionって、8文字ですよ、8文字！これをC風に書くと、

Long name(){

…

}

となります。カッコという制御記号を加えるという動作で、”Function”は”{“に、最後の”End Function”（なんと12文字）は”}”に収束されています。こればかりは、超えることのできない言語仕様ってもんです。言語仕様から来る入力文字数の違い、私は魔法使いにはなれないので、どうしようもありません。その代わり、「コーディングという事象のみに特化すれば…」という視点から考えると、この問題をチャラにすることはできます。それが今回追加するペアステートメントのコード保管機能です。

コード補完機能というやつは、本来は対象位置の前後のソースコードを解析し、予測できる語句をプログラマーに代わって画面に表示してくれる、更にそいつを入力までしてくれるという、ありがた〜い機能なんです。先ほどの話に戻りますが、ABのエディタにより高度な解析能力を備え付ければそれが可能になり、最終的にはコーディングに必要なキー入力の回数はC言語に限りなく近づくことができると思います。先ほどの、”Function”は8文字って話に戻りましょう。さすがに、打ち込み始めの”Function”ばかりは予測不能ワードなので、ご勘弁いただきたいのですが、”Function”という語句がカーソルよりも上の行に存在すれば、その下には”End Function”が来ることは確かです。

• 数行前に”Function”という記述がある
• 今、プログラマーが”e”という英単語を入力した

これらの2点の事象を掛け合わせ、プログラマーは”End Function”を入力したいのかな？といったことを予測します。と同時に、”End Function”をカーソルのすぐ下にポップアップ表示させ、Enterキーの入力を待ちます。プログラマーがそのポップアップに気付き、Enterを押せば、”End Function”が自動的に入力されると共に、数行前のインデントを自動的に認識し、適切な量のインデントが付加されます。ここまでの手順は、C言語で閉じカッコ”{“を入力するためのキー入力の回数と同等のものです。

とまあ、今日は作業が順調に進んで時間的に余裕があったので、長々と書いてみました。正式リリースに向けて、もう一がんばりです。せっかくなので、AB3から何にも進展していないデバッガについても改良を施したいと思います。これはまた後日…

録画溜めした救命病棟をここ数日で一気に見てます。江口洋介、かっこいいな〜。おいらが住んでいる静岡は大地震がいつ何時起きても不思議ではないので、ビクビクです。これといった対策はしていないので、運を天に任せるといったところでしょうか。ソースデータのバックアップだけは実家PC、Webスペースなどに散らばせてとってあります。たぶん大丈夫(^^。まぁ、本当に起こったら、自分や家族の体の心配が一番なんだと思います。それが確保されれば、他はあってもなくても同じようなもんですな。

今日明日とバイトなのですが、合間を縫って開発作業を進めます。作業内容をチラリと書いておきます。正式リリースが間近なので、ヘルプセンターの作成を一時中断し、AB本体の改良を重点的に進めようと思います。

Basic言語はC言語などと比べると打ち込む単語数が多く、制御文を書くだけでも手間がかかってしまいます。If文を例に挙げてみると、C言語では

if(…){

…

}

で済むところを、Basic言語では

If … Then

…

End If

という記述をしなければなりません。これでは、コーディングの効率が良いとはいい辛いのではないかと感じています。それでは、結局のところC言語が優れているのか？といえば、答えはまだわからない段階だと思います。ABに限って言えば、高級言語でありながら、低レベルの要素までをサポートするC言語同等の記述能力を有していると思いますし、今後の改良でそれは明白にしていく予定です。しかし、「打ち込む単語数が違う」という観点から見ると、仕様を変えるほかどうしようもありません。まさか、大カッコ{}を取り入れてしまっては、Basicと呼んでよいのかどうか、私も疑問に感じてしまいますし、単語区切りのコードは読みやすいものです。

そこで、正式リリースに向けてエディタの改良を進めようと思います。これらのポイントを整理し、下記のような変更を施していこうと考えています。

1. 自動インデントの処理能力が単調すぎるので、もう少し複雑な処理を可能にする
2. ブロック判定の精度を向上させ、{}を入力する間隔で”For〜Next”、”If〜End If”、”Class〜End Class”などのステートメントのコーディングをサポートする

1番目は、例えば”Class”と打ち込んで改行したときに、自動インデントが効かないという問題を解消してくれます。現段階の自動インデントの機能は一つ前の行のインデントをコピーするだけの処理しかしていないので、インデントを新たに増やすステートメントであるかどうかを判定すれば、もっと使いやすくなりそうです。

2番目は、C言語で言う閉じカッコ”}”、ABで言う”Next”、”End If”、”End Class”というブロックの終了要素の補完機能を充実させる機能です。こちらは実際に実現させてみないと雰囲気がつかめないとおもうので、正式版にご期待ください。

今朝は母親の間違い電話から一日が始まりました。どうやら、祖父宅へかけるはずの電話をウチにかけてきたようです。おっちょこちょいですな。おいらはブスッとしたまま二度寝を試みたのですが目が覚めてしまい、そのまま起床しました。昨夜の開発作業を継続して行おうとしましたが、なぜか乗り気になりません。よく考えたら、最近、スケジュールつめつめで徹夜に近い状況もしばしば。

ボーッと座っているわけにもいかないので、まずはコンビニに朝食（昼食？）を買いに外に出ました。しかし、どうもコンビニ弁当を食べたい気分ではありません。うーん、はっきりしないな→俺。コンビニへ行こうと車を走らせたわけですが、音楽を聴きながら道を走っているうちにかなり気分が良くなってる事に気付きます。このまま、実家へ戻って昼食をとればいいじゃないか。そうすれば、タダで家庭料理が食べれるし…。こんなアマーイ考えでドライブがてら実家へUターン。ガソリン価格が急騰中にも関わらず、あまり意味もない移動をしてしまいました。

実家に帰ってからですが、まずは食事。それから、従兄弟とその子供とおばあちゃんと街中へ出かけます（おいらはお抱え運転手の身…）。帰り際に静岡駅前にあるDELIってお店でおやつを食べてきました。ここの店は従兄弟の旦那が店長をやっている店で、先月オープンしたばかり。食パンを使った創作料理がめちゃくちゃ美味しいっす。オススメなんで、静岡駅に立ち寄ることがあったら、探してみてくださいな。「DELI」ってお店です。

昨日はバイトを終えてから、ジョニー先輩とMIC（2人とも服屋仲間）とウチで飲みました。MICは金欠とのことで、あたいのツケにしといてあげました。後がこわいぞぉ〜(w。ジョニー先輩は、私よりも2歳年上のゴッツイ系の兄ちゃん、MICは1歳年上の細身ファッション好き人間です。2人とも個性あふれる濃い人種なんで、明け方まで語り明かしました。この人らと話をできるおいらも少し特殊な人種なのかもしれません。

話の内容なのですが、ジョニー先輩＆MICは「服屋」にプライドを持って取り組んでいる模様。「一企業としての服屋である」という定義以前の問題として「自身を確立するための服屋」という見方を重視しています。なにかあれば、店長と意見がすれ違うわけなんですねぇ〜、困ったことに。店長は、店の売上を第一に考え、その見通しが立った段階で、スタッフの問題に接しています。反対に、大半のアルバイトスタッフは、店の売上は大きな問題ではありません。ある程度儲けているなら、それ以上の売上を作ったところでバイト代は上がりません（固定なので…）。活気が出て、店の雰囲気が良くなるのでは？といった利点もありますが、やはり労働という視点から見ると、アルバイトという立場は一定以上の利益を得るための努力をしてしまうと損をします。私の場合は社会というヤツを知らない未熟な人間なので、「社会勉強」という部分でその損を帳消しにしているのですが、儲けようと思って取り組んでいる人はさっさと辞めるべきです。厳しい意見のようですが、こいつが現実ってやつなので、そこから目をそむけるわけにはいきません。

そこで問題なのは、ジョニー先輩もMICも金儲けを第一に考えていないという点です。自分の感性をこのお店から発信していくぞ！という意気込みが大元にあるんですな。おいらは、そんな人たちと仕事ができるんだから、かなりラッキーです。こんな問題を抱えながらも、店長や周りの環境とうまく溶け込みながら、自分の味を出しているというのは、大人ってやつなんですよね。すれ違いが生じるからこそ店長とは人よりも多く、腹を割って話す場を設けたい、互いのが納得するまで意見を言い合う。こんな場面に遭遇すると、本当の意味で勉強になります。

明け方6時就寝でした。今日、明日は休みです(^^

新しいクレジットカードがウチに届きました。ニコスのオードリヘップバーンデザインのやつです（￣ー￣）。そんなに金持ってないんで、ホイホイ買い物するようなことはないのですが、やはり、オシャレなカードは持っていて気分良さそうです。早速署名して、メインカードとして持ち歩いてみることにします。

ヘルプセンターのほう、JavaScriptと格闘しながらなんとか形になってきました。この調子ですと、今日明日中には試験運用ができそうです。ABに関する公式な仕様情報、しかも最新のものをオンラインで提供することで、ABを配布するだけのWebサイトから、プログラミングツールとしてのWebサイトに成長させたいところです。

ABのヘルプファイルは、自分で言うのも難ですが、とても情報量が多いです。これは、Win32APIを事細かに解説していることが原因なのですが、それにしても、ページ数は800前後と、個人で管理できるレベルを超えています。ヘルプセンターはメニューリストを持たなければなりませんが、一つ一つ手作業でリンクしていくと、本当に数日かかってしまいます。ということで、急遽、バッチ処理プログラムをABで書いてみました。HTMLヘルプ形式（*.chm）のコンテンツリストを解析して読み込み、今回のヘルプセンターで利用するメニューリストの書式としてデータを生成するツールです。半日こいつの製作に費やしました。

それにしても、ABで本気でプログラムを書くと、デバッガの弱さが際立ちます。デバッガと呼べるだけの機能は一応は付いているのですが、もう少し工夫することで、かなり使いやすくなりそうです。例えば、現時点では変数をただ単にリスト表示するだけの機能しか備わっていませんが、ユーザーが任意の数式を入力し、ユニークなウォッチリストを表示できるなどの機能は必要不可欠です。ABはVer4.0になろうとしていますが、まだまだ未熟です。さすがにデバッガに関しては私のウデの見せ所なので、今後の開発に力を入れていこうと思います。

こんな感じで、今日は一日中パソコンでした。お疲れです。キチンとした食事をしたかったので、夜は実家に行きました。夜遅くても、しっかりした食事を出してくれる両親には感謝×感謝です。

ヘルプセンターなるものを作るべく、HTML、スタイルシート、JavaScriptを再習得中です。それにしても、これらのWeb技術って、ちょっと手の込んだことをやろうとするといきなり難しくなります。ヘルプセンターに必要不可欠だと思われる機能の1つ、ディレクトリ構造のフォルダ表示がどうもうまくいきません。クリック1つでフォルダ内のドキュメントを表示したり、格納したりする動きなんですが、onClickイベントにそれぞれのドキュメントIDを指定してやれば、表示/非表示といったことはできます。しかし、このドキュメントは一つや二つではないので、それぞれユニークなIDを考えるのは面倒な作業であり、非効率的であるといえます。こんな風に、ムリヤリやろうとすればできるのですが、どうもスマートに収まらない…。私は正規の手順でWeb技術を学んでいないので、独自の風味が出てしまうのかもしれません(–;;。今夜はもう少し奮闘してみます。