開発開始当初に社内向けに約束した、11月中β版リリース、12月製品版リリースというスケジュールは何とか守れました。
毎週金曜日の23時40分に、社内の検索対象ディレクトリにある55万ファイルのインデックス更新を動かしているんだけど、翌朝4時前には毎週終わっているし、55万ファイルの巡回時間で4時間20分ってのは、毎日巡回に耐えると言っていいのかなぁ？
でも、これ、うちの会社はファイルサーバもAidexerもギガビット接続だし、100Mbpsでできあがっている所じゃ辛いかもねぇ
まぁ、Aidexerの能率があんまり上がると、ファイルサーバの応答速度を食ってでも全力で巡回しちゃうから、日中に巡回バリバリって状況は避けたいし、やっぱり毎週末の実行がおすすめですね！
そうそう、最初の1回目の巡回は結構時間かかるから、うちぐらいの規模だと、全域サムネイル生成・全文検索インデックス作成が終わるまで、1週間近い巡回が必要になるでしょう。その間も、巡回を終えたところから順に検索は出来るけど、巡回中はやっぱりそれなりに検索は重くなります。
nice値を設定し直して、巡回側プログラムは低いプライオリティで動いてはいるけど、どうしてもディスクI/Oの多さは避けられないし、やっぱ、導入後の最初の巡回を終えてからが、Aidexerの本領発揮って感じでしょうかね！
当初はねぇ、これって社長の個人PCの中がぐっちゃぐちゃで、何をどこに置いたかわかんなくなったから、それを探せる奴作ってよ！って話から始まったんだよね
でも、それじゃGoogleDesktopと同じだし、同じぐっちゃぐちゃな状況の社内ファイルサーバを検索できる方向で、でも、個人PCの中も検索できるようにね！って話になったんだ
だからWindowsPCに入るWindows版で作り始めて、それが十分動く程度になってから、出荷にかかる周辺費用の話が出たら、「やっぱり安く出荷できるLinuxでいこう！」って話になってさ(^^;;
相当部分がLinux対応で作り直し。しかもFedoraCore9で始めてから、途中からCentOS5に切り替えてドタバタ（汗）
で、社内ファイルサーバの検索が一通り出来るようになったら、社外から営業デモ用に直接検索画面が使えないか？って話になって、ゲートウェイ側の設定変更して別ポートから社内Aidexerのポート80へのポートフォワードをして、見えるようにしてみたの
そしたらまたこれが社長のお気に入りになっちゃって、検索できたらファイルが取り出したいよね！って、そりゃそうだよね
かといってSAMBAのGlobal公開なんてあり得ないから、見つけたファイルをメールに添付して送れちゃう仕組みを、オプションとして作っちゃったんだな（＾＾）
@dragon-networks.com宛にしか送れない仕組みにしたし、ある意味セキュア、ある意味「いいのか？これ？」って感じだなぁ
つまんないルールで縛られず、社員が出先でより便利に活動できるならどんどんやれ！って会社にとっちゃ、相当使えるツールだとは思うけどなぁ…..
[2008年7月某日]
プログラムを作り始める前に、先ずはどのようなプロセスでソース解析を行わせるか考えなければなりません。
C言語のソースには、コンパイラ標準の型式と関数、ユーザーが用意した型式と関数が含まれています。解析を進めるとき、通常のコンパイラと同じように全てのインクルードファイルを読んで型式や関数定義を理解出来てしまえばこれ程都合の良いことはないのですが、それだと、例えばLinuxのソースをWindowsで解析するのにコンパイラセットに含まれるヘッダソースまで過不足なく準備してから解析に掛けるということになります。
しかし、業務としてプロジェクトのソースコードを扱う時、コンパイラに含まれるヘッダファイルまで包括して管理することなどは先ず考えられません。 Linuxのフリーのコンパイラは例外としても、Windowsなどの製品版コンパイラに含まれるインクルードファイルまでプロジェクトに含めて受け渡しを行うという行為は、ライセンスの観点からも行われるべきでは無いでしょう。
それよりも何よりも、開発環境の標準インクルードファイルの中身まで見に行くような、本格的なコンパイラのイミテーションを作るつもりもありません (…絶対に作れません…)。
あくまでも人間がソースを眺めて目で追って行く過程を再現し、不足情報は不足として認識し、実在するソースコード内部に限って解析が進められれば十分用途に適うと思われます。
とりあえず、必ずやらなければならない事はソースコード内に含まれる『実体関数の認識』と関数内部から『コールされる関数の認識』です。これさえ出来れば他は全て無視しても問題ないと思われます(…多分)。上では「本格的なコンパイラのイミテーションを作るつもりはない」と書きましたが、この関数検出まではCコンパイラとほぼ同じ仕組みで実装しなければならないでしょう。
プロトタイプとして最低限実装すべきロジックは、
・コメントの除外。(”//”,”/*・・・*/”)
・標準の制御命令の認識。(”for()”,”while()” など)
・実体関数の認識。
・実体関数の引数認識。
・関数呼出の認識。
・関数呼出の引数認識。
・実体関数と関数呼出の関連付け。
…と、しておきます。
[2008年7月某日]
一概にソースコード解析といっても、開発言語には様々な種類が存在します。ツールの雛形を開発するにあたってはとりあえずその中の一つをターゲットにしてプログラムの設計を開始します。
このツールを開発する目的としてどうしても対応したい環境といえば、MFCまでフォローしたWindows用VC++のプロジェクトなのですが、通常のC言語のみ書かれたWIN32_APIのソースならまだしも C++やMFCなどの書式までプロトタイプの段階で対応するのは相当な無理があります。
そういうわけで、当初の野望はあくまでも最終完成系までに実装する最終目標と位置づけて、まず最初は一番単純なgcc用のソース辺りから対応を始めて行きたいと思います。
解析エンジンは C言語を対象とするよりも Java や VB 、PHPの方が技術者人口が多くてニーズが見込めるという意見もありましたが、先ずは自分が一番使い慣れた言語で一通りの機能を作り上げます。
[2008年7月某日]
ソースやプロジェクトの開発支援ツールといえば既に高機能で優秀なツールが数多く市販されています。
しかし、それら製品紹介を幾つか閲覧してみたところ、どうも自分が欲しいと思う解析結果を出力してくれるような商品は見あたりませんでした。個人的には見たい情報というのは極めて限られていて、決して多機能を求めているわけではありません。
…と言うよりも、それ以前に市販商品はどれも価格が高価なので、個人のポケットマネーでポンと購入できるような代物でも無い訳ですが…。
フリーウェアやシェアウェアに目を向けると、市販品とは違う方向性のシンプルで便利そうなソフトが公開されています。ただ、フリーソフトの世界では Doxygen を利用するタイプのものが多いみたいです。
一応説明しておきますと、Doxygen とは CやJavaなどに対応したソースコードの解析・自動ドキュメントを作成してくれるオープンソースのソフトウェアです。予め決まったフォーマットのコメントガイドをソース内に埋め込んでおくと、インクルード・クラス・構造体・変数・関数などの相互関係を高精度に解析して、HTMLのハイパーリンクを利用したドキュメントとして出力してくれます。HTMLファイルで表示されているソースの関数呼び出し部分をクリックすると、その関数のソースにジャンプし、流れを追いかけることが可能です。
【Doxygen 変換サンプル】
私も以前仕事で Doxygen を使っていた事があるのですが、この関数関連付けリンクのHTMLこそがDoxygenの真骨頂で、開発したプログラムからドキュメント起こしする際に大変役に立ちます。日本では余り見かけませんが、海外の技術系サイトで Doxygen を使ったソース閲覧ページは結構沢山あります。
しかし、これは上でも書いたとおり、正しい解析結果を得ようと思ったら規定フォーマットのガイドコメントをソースに埋め込まなければなりません。ガイド無しのソースでも解析は実行できるのですが、スパゲティソースとなるとそのまま解析に掛けても正常な解析結果を得るのは難しいです。特にWindow用ソースは特殊な型式宣言が多く存在するせいか、所々、関数宣言がブツ切れに解釈されてしまう箇所が見られました。これについては、Windowsソース解析モードの実装待ちでしょう。
[2008年7月某日]
私は、プロジェクトで提供されたソースを解析する前に、時々行うことがあります。
ソースコードを紙に印刷して縦長のソースの巻物を作り、それを関数ごとに切り取った後、呼出階層が判る様に並べて一枚の紙になるよう貼り付けるのです。所謂、関数地図を作ります。
その後、関数の呼出位置から関数実体に向けて線を引いてプログラムの流れを追いかけ易いようにします。ネストの深いクラスや構造体なども塊ごとに切り張りしてツリー化しておきます。
下の写真がその紙で作った構造体地図と関数地図の実物です。
大体、構造体地図がA3用紙1枚分、関数地図はA3用紙3枚分ぐらいの大きさです。
このようにソースコードを平面的に並べる事により、関数を座標的に見ることが出来るようになり、只、エディタ上で grep を使いながら一本道にコードを追いかけるよりも、遥かにソースの流れが理解し易くなります……いや、理解し易くなるような気がします。ソースが図面化されて右脳が使われるようになったお陰でしょうか？
もっとも、コレが通用するのはある程度ソース規模の小さなシステムだけで、大規模なソースになるとシステムソース全体の地図を作ることなど到底やっていられません。 Windowsのプロジェクトなどは VisualStudio からトレース実行が出来るので、関数を追いかけながらノートへ手書きで書き込んで済ませることも可能ですが、 Linuxのコマンドラインデバッガではなかなかそれも難しく、理解したい機能に絞って部分的作成を行います。特に fork でプロセスが分岐する箇所は、分岐した先を平行に並べて配置し、それぞれのプロセスが同じ時間軸で動いているプロセスを同時追跡し易いようにします。
私が解析ツールにやらせたい事というのはこの作業の自動化です。
今は仮名称として関数呼出木解析ツールなどと書いていますが、最終的な目標は『関数地図作成ツール』と言った物になるでしょうか？
FunctionMapper プログラム開発メモの掲載を開始します。開発の方が大分先行しているので、過去の開発ノートや勉強メモ、ソースコード内の詳細注釈から文章を起こして、順次書き込んで行きます。
[2008年7月某日]
システムの委託開発という仕事をやっていると、自分で新たにソースを起こすことよりも他人様が作ったソースを引き継いで機能追加したり新システム用にカスタマイズすることが多く、仕事を始める以前のその既存ソースの解析に取られる時間と労力が相当なものになります。
ソフトウェア開発を生業にしている人なら誰でも心当たりがあると思いますが、開発者から開発者へ…何代も引き継がれてきたソースコードの中身を完全に理解するのは、縺れた釣り糸をほどくよりも遥かに厄介なことです。前任者に不明な点を聞こうと思ってもその人は内容をスッカリ忘れていたり、忘れるだけならまだしも、別の仕事に掛かり切りで全く消息が掴めなかったり、いや…捕まらないだけならまだしも、既に別の業界に転職していたり…。スパゲティソースであればあるほど詳細な設計書類が残っている可能性は限りなく低くなりますので、最終的には自助努力で解決しなければなりません。
今までそういった苦難を散々味わってきた経験より、随分前から、「他者が手がけたソースコード解析の負荷を少しでも軽減出来るよう独自のソース解析支援ツールを開発したい」という要望を持っていました。
そんなとき、先の会社の業務内容報告会にて、「何か開発としてやってみたい事があれば各人で発表する」という通達があったので、丁度良い機会とばかりに自分の考える開発支援ツールの簡単な草案を提示してみたところ、「便利そうなツールなので業務の空き時間を利用して雛形を試作してみよう。」といった流れになりました。
下はその時に書いた簡単な概要図です。
以上の経緯より、今後、上図にあるような機能を目指してツール開発を進める事となります。
その開発過程で何か考察することがあれば少しずつ文章を残して行きます。