何を今さら・・・な感じがしなくもないが、ちょっと事情があってMicrosoftのサイトからVisual C++ 2005 Expressをダウンロードして使ってみた。
自分で開発するときはBorland C++Builder 2006を使っているが、会社では未だにVisual C++ 6.0を使っている。Microsoft純正としては事実上最後のWin32開発環境である。それ以降.NETに移行して話がややこしくなってしまった。今でもVisual C++ 6.0が多く使われているのは、過去のWin32プラットフォームで開発された資産が大量に蓄積されているということが大きな理由だろう。新しいバージョンのVisual C++ではうまくコンパイルできなかったりすることがあるのだ。
ところがこのVisual C++ 6.0ってやつはすっごく開発効率が悪い。一応Visualの名は冠しているものの、実態はビジュアルにはほど遠く、ダイアログにコンポーネントを貼り付けられる以外はすべて自分でコードをガシガシと書くしかない。ちょっと気の利いたユーザーインターフェースを作ろうと思ったらそれだけで一苦労である。ええ加減にやめてほしいんだけど、一度慣れ親しんだものはそう簡単に手放せないのか、一生使い続けそうな気配である（笑）。
最新のバージョンであるVisual C++ 2005からは無料のExpress版というものが登場した。一昔前までは安くても2〜3万円したものがタダになったとは画期的なことである。ただし、Express版はデフォルトでは.NET開発しかできず、Win32開発を行うためには別途プラットフォームSDKをインストールする必要がある。しかもMFCは付属しないので、Windowsアプリを開発するためにはWindowsAPIベースでプログラミングしなければならない。もちろんビジュアルプログラミングも一切不可能。実質的にはWin32はコンソールアプリ専用と考えた方がいいだろう。Win32開発がしたければStudio Editionを買えってことか。
さてVisual C++ 2005は.NET開発に関しては名実ともにビジュアルな環境になっており、コンポーネントを貼り付けてプロパティを設定し、イベントハンドラを書くだけで簡単にユーザーインターフェースを作成できる。つまりVisual Basicと基本的に同じ流れでプログラミングができる。Visual C++ 6.0の頃から考えると隔世の感すらある。.NETの仕組みをまったく知らなくてもとりあえず簡単にプログラムができてしまった。コンポーネントの種類も豊富に用意されているし、かなり見栄えのするユーザーインターフェースが作れそうな感じである。これがタダで手に入るとは、改めてすごい時代になったものである。
しかしちょっとヘンなところもある。自動で作成されるイベントハンドラはなぜかヘッダファイルの側にあり、基本的にはクラス宣言のすべてをヘッダファイルで行ってしまうような仕様になっている。これは明らかにJavaやC#を意識したスタイルであり、もはやC++といえるのか？ その方が効率的と言えばそうかもしれないが、かなり違和感の残ることは否めない。
一方、Microsoftに対抗してBorlandも無料のC++開発環境を昨年から提供している。昔懐かしいTURBOの名を冠したTURBO C++ Explorerがそれである。こちらはC++Builder 2006の機能限定版という位置付けだが、自分でコンポーネントを作れないなどの点を除いて制限事項は非常に少ないネイティブのWin32開発環境である。こちらはDelphi以来伝統のビジュアルプログラミングがそのまま使えるし、自動生成されるコードもオーソドックスなC++スタイルでわかりやすい。ちょっとしたフリーソフトを作るくらいならこれだけで十分間に合ってしまうのだ。
それぞれプラットフォームが.NETかWin32かという違いはあるが、目的によって両方を使い分けられるのはありがたいことである。おそらく両者は相当意識し合っているのだろう。どっちが真似したのか知らないが、インターフェースがあまりにもそっくりであるところが笑える（笑）。
自分で開発するときはBorland C++Builder 2006を使っているが、会社では未だにVisual C++ 6.0を使っている。Microsoft純正としては事実上最後のWin32開発環境である。それ以降.NETに移行して話がややこしくなってしまった。今でもVisual C++ 6.0が多く使われているのは、過去のWin32プラットフォームで開発された資産が大量に蓄積されているということが大きな理由だろう。新しいバージョンのVisual C++ではうまくコンパイルできなかったりすることがあるのだ。
ところがこのVisual C++ 6.0ってやつはすっごく開発効率が悪い。一応Visualの名は冠しているものの、実態はビジュアルにはほど遠く、ダイアログにコンポーネントを貼り付けられる以外はすべて自分でコードをガシガシと書くしかない。ちょっと気の利いたユーザーインターフェースを作ろうと思ったらそれだけで一苦労である。ええ加減にやめてほしいんだけど、一度慣れ親しんだものはそう簡単に手放せないのか、一生使い続けそうな気配である（笑）。
最新のバージョンであるVisual C++ 2005からは無料のExpress版というものが登場した。一昔前までは安くても2〜3万円したものがタダになったとは画期的なことである。ただし、Express版はデフォルトでは.NET開発しかできず、Win32開発を行うためには別途プラットフォームSDKをインストールする必要がある。しかもMFCは付属しないので、Windowsアプリを開発するためにはWindowsAPIベースでプログラミングしなければならない。もちろんビジュアルプログラミングも一切不可能。実質的にはWin32はコンソールアプリ専用と考えた方がいいだろう。Win32開発がしたければStudio Editionを買えってことか。
さてVisual C++ 2005は.NET開発に関しては名実ともにビジュアルな環境になっており、コンポーネントを貼り付けてプロパティを設定し、イベントハンドラを書くだけで簡単にユーザーインターフェースを作成できる。つまりVisual Basicと基本的に同じ流れでプログラミングができる。Visual C++ 6.0の頃から考えると隔世の感すらある。.NETの仕組みをまったく知らなくてもとりあえず簡単にプログラムができてしまった。コンポーネントの種類も豊富に用意されているし、かなり見栄えのするユーザーインターフェースが作れそうな感じである。これがタダで手に入るとは、改めてすごい時代になったものである。
しかしちょっとヘンなところもある。自動で作成されるイベントハンドラはなぜかヘッダファイルの側にあり、基本的にはクラス宣言のすべてをヘッダファイルで行ってしまうような仕様になっている。これは明らかにJavaやC#を意識したスタイルであり、もはやC++といえるのか？ その方が効率的と言えばそうかもしれないが、かなり違和感の残ることは否めない。
一方、Microsoftに対抗してBorlandも無料のC++開発環境を昨年から提供している。昔懐かしいTURBOの名を冠したTURBO C++ Explorerがそれである。こちらはC++Builder 2006の機能限定版という位置付けだが、自分でコンポーネントを作れないなどの点を除いて制限事項は非常に少ないネイティブのWin32開発環境である。こちらはDelphi以来伝統のビジュアルプログラミングがそのまま使えるし、自動生成されるコードもオーソドックスなC++スタイルでわかりやすい。ちょっとしたフリーソフトを作るくらいならこれだけで十分間に合ってしまうのだ。
それぞれプラットフォームが.NETかWin32かという違いはあるが、目的によって両方を使い分けられるのはありがたいことである。おそらく両者は相当意識し合っているのだろう。どっちが真似したのか知らないが、インターフェースがあまりにもそっくりであるところが笑える（笑）。
ネットを徘徊していてちょっといいものを発見。ローカルマシン上で動作する非常にコンパクトな無料のデータベース、それがSQLiteだ。
これまでMySQLなどのサーバー型データベースは使ったことがあったが、ローカルマシン上で動作するスタンドアロン型のデータベースは縁がなかった。いや正確に言うとAccessはちょっと触ったことがあったが、市販ソフトであるため自作のアプリケーションに組み込んで配布するような用途には使えない。
業務システムをはじめとしてアプリケーションに何らかのデータベース的機能を持たせたい場合、ある程度規模が大きければOracleやSQLServerなどのサーバー型商用データベースを選択するのが常識だろう。またWebシステムを構築する場合はPHPと相性の良いMySQLやPostgreSQLなどのオープンソースデータベースを使うのが普通である。
しかし利用がごく個人的なもので規模もそれほど大きくない場合、それらのサーバー型データベースはあまりにも大げさすぎる。サーバー型のデータベースはマルチユーザーを前提とし、ユーザー管理や権限設定が必須であるため、いくら無料といえども一般のユーザーが自分でインストールして使えるようにするのはまず不可能である。したがってパッケージソフトとして配布することができないのだ。
そこでスタンドアロンのアプリケーションに組み込みたい場合、自前でデータベースを構築するしかなかった。一応ファイルベースで簡単な「データベースもどき」を作ることはできるが、一般的なリレーショナルデータベースに比べればはるかに貧弱で低機能なものしかできない。かかる工数と機能のバランスを考えると、あまりにも効率が悪すぎる。
必要に迫られて何とか使えるものがないかと探していたらSQLiteが見つかった。今まで名前は聞いたことがあったが、MySQLより劣る低機能なデータベースという認識しかなかった。ところがこれがちょうど目的にピッタリなものだったのだ。
SQLiteはサーバーではなくスタンドアロンで動作し、C言語からライブラリという形で簡単に呼び出すことができる。データベースは単一のファイルだけで構成され非常に単純明快、しかもライブラリ本体はわずか400kB程度という非常に軽量なもので、アプリケーションに組み込むには最適なデータベースなのだ。軽量といってもリレーショナルデータベースとしての基本はしっかり押さえられていてほとんどのSQL文が通るし、文字コードをUTF-8にすればちゃんと日本語も通る。パーソナルなデータベースには必要にして十分な機能を持っているのだ。ファイルサイズは最大2テラバイトと十分で、速度的にもMySQLに比べて遜色はないらしい。
SQLite自体はコマンドラインインタプリタとDLLのほか、ソースパッケージでも配布されている。ソースは非常にオーソドックスなC言語で書かれているので、OSやコンパイラを問わずあらゆるプラットフォームで利用できる。ソースからビルドすればアプリケーションの一部として静的にリンクされるので、他にファイルを配布する必要もなく、インストールも非常に単純になる。
さらに嬉しいことは、ライセンスがパブリックドメインであるということだ。すなわち完全に「公共のもの」とされているため使用条件に一切の制約がなく、商用・無償を問わず誰でも自由に利用して配布できるということだ。まさに自作アプリケーションに組み込むにはうってつけのデータベースである。実際に市販ソフトにも組み込まれている例があるらしい。これをもっと早く見つけていれば自前でデータベースを構築するなど無駄なことを考えずに済んだのであった。
これまでMySQLなどのサーバー型データベースは使ったことがあったが、ローカルマシン上で動作するスタンドアロン型のデータベースは縁がなかった。いや正確に言うとAccessはちょっと触ったことがあったが、市販ソフトであるため自作のアプリケーションに組み込んで配布するような用途には使えない。
業務システムをはじめとしてアプリケーションに何らかのデータベース的機能を持たせたい場合、ある程度規模が大きければOracleやSQLServerなどのサーバー型商用データベースを選択するのが常識だろう。またWebシステムを構築する場合はPHPと相性の良いMySQLやPostgreSQLなどのオープンソースデータベースを使うのが普通である。
しかし利用がごく個人的なもので規模もそれほど大きくない場合、それらのサーバー型データベースはあまりにも大げさすぎる。サーバー型のデータベースはマルチユーザーを前提とし、ユーザー管理や権限設定が必須であるため、いくら無料といえども一般のユーザーが自分でインストールして使えるようにするのはまず不可能である。したがってパッケージソフトとして配布することができないのだ。
そこでスタンドアロンのアプリケーションに組み込みたい場合、自前でデータベースを構築するしかなかった。一応ファイルベースで簡単な「データベースもどき」を作ることはできるが、一般的なリレーショナルデータベースに比べればはるかに貧弱で低機能なものしかできない。かかる工数と機能のバランスを考えると、あまりにも効率が悪すぎる。
必要に迫られて何とか使えるものがないかと探していたらSQLiteが見つかった。今まで名前は聞いたことがあったが、MySQLより劣る低機能なデータベースという認識しかなかった。ところがこれがちょうど目的にピッタリなものだったのだ。
SQLiteはサーバーではなくスタンドアロンで動作し、C言語からライブラリという形で簡単に呼び出すことができる。データベースは単一のファイルだけで構成され非常に単純明快、しかもライブラリ本体はわずか400kB程度という非常に軽量なもので、アプリケーションに組み込むには最適なデータベースなのだ。軽量といってもリレーショナルデータベースとしての基本はしっかり押さえられていてほとんどのSQL文が通るし、文字コードをUTF-8にすればちゃんと日本語も通る。パーソナルなデータベースには必要にして十分な機能を持っているのだ。ファイルサイズは最大2テラバイトと十分で、速度的にもMySQLに比べて遜色はないらしい。
SQLite自体はコマンドラインインタプリタとDLLのほか、ソースパッケージでも配布されている。ソースは非常にオーソドックスなC言語で書かれているので、OSやコンパイラを問わずあらゆるプラットフォームで利用できる。ソースからビルドすればアプリケーションの一部として静的にリンクされるので、他にファイルを配布する必要もなく、インストールも非常に単純になる。
さらに嬉しいことは、ライセンスがパブリックドメインであるということだ。すなわち完全に「公共のもの」とされているため使用条件に一切の制約がなく、商用・無償を問わず誰でも自由に利用して配布できるということだ。まさに自作アプリケーションに組み込むにはうってつけのデータベースである。実際に市販ソフトにも組み込まれている例があるらしい。これをもっと早く見つけていれば自前でデータベースを構築するなど無駄なことを考えずに済んだのであった。
今度はソフトシンセなんぞを作ってみましたが、まあシンセと言っても曲が演奏できるわけでもなく、単に音を出すだけの「シンセもどき」なんですがね・・。原理はとても簡単で、単純な正弦波を倍音ごとに重ねていけば理論的にはどんな波形でも作り出せるわけです。要するにフーリエ変換のまったく逆をやってるわけですね。シンセにもいろんな方式がありますが、いわゆる倍音合成方式と呼ばれる最も基本的な方式です。ハモンドオルガンなんかもこの方式に属するはずです。まあ市販のソフトシンセに比べれば超低機能ですが、やってることはほとんど同じなわけで、シンセの仕組みもだいぶわかってきました。本格的なソフトシンセを作るには様々な課題をクリアする必要がありますが、そんなに難しくないかもという気がしてきました。
しかしこれはどう考えても金になりそうな仕事ではないんですよね。(^_^; こんなのを作ってどうするつもりなのかと疑問ではありますが、まあノウハウの蓄積みたいなもんですかね？ サウンドにはMIDI系とウェーブ系の二種類がありますが、今まではMIDI系が中心でウェーブ系は誰もやってなかったんですよね。だからこれまで社内にそういったノウハウの蓄積がまったくなく、自分が来て初めてウェーブ系に手を出したというところです。自分としてはかなりウェーブ系のエキスパートに近づいてきてほとんど何でもできそうな気はしてきましたが、そのノウハウを不安定な身分のアルバイトが一人で握っているのはいかがなものかと・・(^_^; 仮にですよ、いま自分が辞めたとしたら、そのノウハウはまた失われてしまうのは必至で、ノウハウの継承というものは進んでいかないですね。
早いものでもう契約期間の半分は過ぎたわけで、次の契約更改があるのかないのか気になるところです。まあ自分としてはこの仕事はやめられそうにないと感じておりますが、条件面で何らかの進展があるかということより、辞めてほしくないと思われているかどうかが問題なのです。社員の人らはみんな転職組だし、少なくとも自分と違ってキャリアがあるわけだから、行こうと思えばどこでも行けるはずなんですよね。にもかかわらず、決して高いとは言えない給料で結構長いこといるのはどういうことなのか、その答を知りたい・・
しかしこれはどう考えても金になりそうな仕事ではないんですよね。(^_^; こんなのを作ってどうするつもりなのかと疑問ではありますが、まあノウハウの蓄積みたいなもんですかね？ サウンドにはMIDI系とウェーブ系の二種類がありますが、今まではMIDI系が中心でウェーブ系は誰もやってなかったんですよね。だからこれまで社内にそういったノウハウの蓄積がまったくなく、自分が来て初めてウェーブ系に手を出したというところです。自分としてはかなりウェーブ系のエキスパートに近づいてきてほとんど何でもできそうな気はしてきましたが、そのノウハウを不安定な身分のアルバイトが一人で握っているのはいかがなものかと・・(^_^; 仮にですよ、いま自分が辞めたとしたら、そのノウハウはまた失われてしまうのは必至で、ノウハウの継承というものは進んでいかないですね。
早いものでもう契約期間の半分は過ぎたわけで、次の契約更改があるのかないのか気になるところです。まあ自分としてはこの仕事はやめられそうにないと感じておりますが、条件面で何らかの進展があるかということより、辞めてほしくないと思われているかどうかが問題なのです。社員の人らはみんな転職組だし、少なくとも自分と違ってキャリアがあるわけだから、行こうと思えばどこでも行けるはずなんですよね。にもかかわらず、決して高いとは言えない給料で結構長いこといるのはどういうことなのか、その答を知りたい・・
客先での不具合が解決したかと思ったら、また別の新たな問題が・・。なんとVistaではまったく動かないんだとさ！
原因を突き止めるためにわざわざVistaで環境を構築して半日潰れたけど、結局あるAPIの挙動がXPとは違っているということが判明した。そこのところをプログラム側で吸収してやることにより無事解決はした。
このAPIの挙動というものは仕様には定義されていないもので、いわばプログラマが「暗黙の了解」と思って使っている部分である。プログラマからすればXPではこのように動いていたからVistaでも当然そのように動くべきだと考えているわけだ。しかしMicrosoftとしては仕様に定義されていない挙動はベンダー側が勝手に決めて良いものであって、プログラマがそれに依存したコードを書くこと自体間違っていると主張するだろう。
確かにこのAPIの場合、XPまでの挙動がむしろバグに近く、Vistaの挙動の方が正しいように思える。想像するに、MicrosoftではVistaの開発に当たってXPまでに見つかったバグを徹底的に潰していった結果、仕様に現れない部分のAPIの挙動が微妙に違っているものと思われる。しかし「良かれ」と思ってやったことであっても、APIという最も基本的な部分の動作を勝手に変えてしまって良いものか？ それでもMicrosoftは仕様に定義されない「暗黙の了解」を使う方が悪いと主張するだろうが、事実上このようなコードは無数に使われており、完全にゼロにすることは不可能に近い。
Vistaで動かないソフトがいっぱいある原因の大半は、こういった仕様に現れない部分での挙動の違いによるものだと推測される。Vistaを導入するということは、こういうリスクを一手に引き受けるということだ。何が起こるかはまったく予測がつかない。ソフトを開発している人間からはとても怖くて使う気になれないね。
これだけじゃなくて、Vista絡みでは最近あちこちで不可解な現象に悩まされている。「やりたいことが思うようにできない」、「いちいち警告してくるなよ！」とあまりのタコさ加減にみんな呆れている。下位互換性がないOSなんて欠陥品に近いと思うぞ。史上最悪のカスOSだ！ 僕は2014年に予定されているXPのサポート終了までVistaなんかに乗り換えるつもりはない。もっともその頃には時期Windowsが発売されてるだろうが（笑）。そのうち入手が困難になるだろうから、今のうちにもう一本XP（しかもProfessional版ね）を仕入れておこう！
と言っても今後新規のPCはVistaに置き換わっていくだろうから、Vistaでは動きませんと言うわけにもいかんのだ。操作性が変わることを嫌う企業ユーザーはそう簡単に乗り換えないだろうが、一般ユーザーほど乗り換えは早い。動作確認のためだけにVistaを導入するのもトホホな話ではある。
原因を突き止めるためにわざわざVistaで環境を構築して半日潰れたけど、結局あるAPIの挙動がXPとは違っているということが判明した。そこのところをプログラム側で吸収してやることにより無事解決はした。
このAPIの挙動というものは仕様には定義されていないもので、いわばプログラマが「暗黙の了解」と思って使っている部分である。プログラマからすればXPではこのように動いていたからVistaでも当然そのように動くべきだと考えているわけだ。しかしMicrosoftとしては仕様に定義されていない挙動はベンダー側が勝手に決めて良いものであって、プログラマがそれに依存したコードを書くこと自体間違っていると主張するだろう。
確かにこのAPIの場合、XPまでの挙動がむしろバグに近く、Vistaの挙動の方が正しいように思える。想像するに、MicrosoftではVistaの開発に当たってXPまでに見つかったバグを徹底的に潰していった結果、仕様に現れない部分のAPIの挙動が微妙に違っているものと思われる。しかし「良かれ」と思ってやったことであっても、APIという最も基本的な部分の動作を勝手に変えてしまって良いものか？ それでもMicrosoftは仕様に定義されない「暗黙の了解」を使う方が悪いと主張するだろうが、事実上このようなコードは無数に使われており、完全にゼロにすることは不可能に近い。
Vistaで動かないソフトがいっぱいある原因の大半は、こういった仕様に現れない部分での挙動の違いによるものだと推測される。Vistaを導入するということは、こういうリスクを一手に引き受けるということだ。何が起こるかはまったく予測がつかない。ソフトを開発している人間からはとても怖くて使う気になれないね。
これだけじゃなくて、Vista絡みでは最近あちこちで不可解な現象に悩まされている。「やりたいことが思うようにできない」、「いちいち警告してくるなよ！」とあまりのタコさ加減にみんな呆れている。下位互換性がないOSなんて欠陥品に近いと思うぞ。史上最悪のカスOSだ！ 僕は2014年に予定されているXPのサポート終了までVistaなんかに乗り換えるつもりはない。もっともその頃には時期Windowsが発売されてるだろうが（笑）。そのうち入手が困難になるだろうから、今のうちにもう一本XP（しかもProfessional版ね）を仕入れておこう！
と言っても今後新規のPCはVistaに置き換わっていくだろうから、Vistaでは動きませんと言うわけにもいかんのだ。操作性が変わることを嫌う企業ユーザーはそう簡単に乗り換えないだろうが、一般ユーザーほど乗り換えは早い。動作確認のためだけにVistaを導入するのもトホホな話ではある。
最初のお題はおおよそ目途がついて自分の手を離れました。そろそろ実際の製品に組み込まれてユーザーの評価を待つところです。
それで次なるミッションはやっぱり来たかという感じですが、FFTをやることになりました。FFTってなんじゃらほい？って方がほとんどだと思いますが、「高速フーリエ変換」の略です。って余計わけわからんようになったかもしれませんが、すべての波はサインとコサインの重ね合わせで表すことができるという数学上の定理のことです。う〜ん、ますます意味不明になったか・・(^_^;
もっと平たく言えば、要するにスペクトル分解のことなんですよね。よく知られているように、太陽の光をプリズムに通すと７色のスペクトルに分かれます。空に架かる虹も同じ原理ですね。あれは波長の異なる波に分解されたため色が違って見えるわけです。
音もまったく同じことで、実は人間の声をはじめ自然界に存在するすべての音は基準となる周波数以外にその2倍、3倍、4倍・・・といった倍音成分を多量に含んでいます。その倍音成分の含まれ方によってピアノやバイオリンなどの「音色」が決まるわけです。音をスペクトルに分解するということは音の性質を調べる上で最も基本的な手法といえます。これは何も音だけに限らず、工学的にはあらゆる分野で使われている手法ですね。学生時代にちょっとやって忘却の彼方にあったものを少しずつ思い出しながら・・
元の波形をスペクトルに変換する操作がフーリエ変換ってわけですが、定義通り真面目に計算するとものすごく時間のかかる計算なのでリアルタイムな処理には向きません。そこでもっと効率の良い方法で圧倒的に短時間で計算できる方法として考え出されたのが高速フーリエ変換（FFT）というアルゴリズムです。この方法なら処理時間が十分の１から百分の１程度に短縮されるため、リアルタイムな処理も可能になってきます。
FFTのアルゴリズム自体はかなり複雑ですが、まあ中身を理解しなくてもその辺に転がってるサンプルからパクってくれば済む話です。しかし問題はそこからで、ある程度の周波数分解能を得るためにはできるだけデータ量を多く取らなければなりません。そうなると計算時間が飛躍的に増大することは誰にも理解できる話でしょう。計算時間が長くなるとその間CPUは他の仕事をできなくなるので、音が途切れるなどの問題が出てきます。そこでFFTの計算をバックグラウンドでやらせるというマルチスレッド化が必要になったりします。実はマルチスレッドはまだやったことがないので、チャレンジ課題としては手応え十分といったところです。
最終的な目的はマイクから入力した音の音階を判定するということなんだけど、これが実はかなり難しく奥の深い問題です。ちょっとやってみればわかりますが、人間の声というのは母音によって波形が異なり、当然スペクトルの出方も異なってきます。厄介なことに基本波の2倍が強くなったり、逆に1/2が強くなったりする場合もあり、単純にスペクトルのピークを求めればいいというわけにはいきません。もちろん男性と女性によっても違うし、人によっても違うでしょう。そうなるとテストのしようがないんじゃないかと・・。そういえば「鼻歌をMIDIデータに変換する」なんていうシェアウェアかフリーウェアがあったよなぁ。あれはどういう手法でやってるんだろうか？ 一番肝心なノウハウはどこも出したがらないもんだ・・
・・とまあ、かなりの難題であることには違いないけど、目標が困難であればあるほどやる気も出てくるってもんだ。これが時給○○○○円でやる仕事かっていうのはさておき、これができれば怖いもんなしだぜ！
それにしてもね、これほどアカデミックなことをやったのは大学を卒業して以来初めてだよ。前の会社では一日汗まみれになってひたすら肉体労働だったからね（笑）。学校で習ったことなんてクソの役にも立たなかったね。あんな低級な仕事は正社員にやらせるのがもったいないよ（爆）。それで給料が今の3倍くらいあったんだから、バカらしくてやってられんよな・・
それで次なるミッションはやっぱり来たかという感じですが、FFTをやることになりました。FFTってなんじゃらほい？って方がほとんどだと思いますが、「高速フーリエ変換」の略です。って余計わけわからんようになったかもしれませんが、すべての波はサインとコサインの重ね合わせで表すことができるという数学上の定理のことです。う〜ん、ますます意味不明になったか・・(^_^;
もっと平たく言えば、要するにスペクトル分解のことなんですよね。よく知られているように、太陽の光をプリズムに通すと７色のスペクトルに分かれます。空に架かる虹も同じ原理ですね。あれは波長の異なる波に分解されたため色が違って見えるわけです。
音もまったく同じことで、実は人間の声をはじめ自然界に存在するすべての音は基準となる周波数以外にその2倍、3倍、4倍・・・といった倍音成分を多量に含んでいます。その倍音成分の含まれ方によってピアノやバイオリンなどの「音色」が決まるわけです。音をスペクトルに分解するということは音の性質を調べる上で最も基本的な手法といえます。これは何も音だけに限らず、工学的にはあらゆる分野で使われている手法ですね。学生時代にちょっとやって忘却の彼方にあったものを少しずつ思い出しながら・・
元の波形をスペクトルに変換する操作がフーリエ変換ってわけですが、定義通り真面目に計算するとものすごく時間のかかる計算なのでリアルタイムな処理には向きません。そこでもっと効率の良い方法で圧倒的に短時間で計算できる方法として考え出されたのが高速フーリエ変換（FFT）というアルゴリズムです。この方法なら処理時間が十分の１から百分の１程度に短縮されるため、リアルタイムな処理も可能になってきます。
FFTのアルゴリズム自体はかなり複雑ですが、まあ中身を理解しなくてもその辺に転がってるサンプルからパクってくれば済む話です。しかし問題はそこからで、ある程度の周波数分解能を得るためにはできるだけデータ量を多く取らなければなりません。そうなると計算時間が飛躍的に増大することは誰にも理解できる話でしょう。計算時間が長くなるとその間CPUは他の仕事をできなくなるので、音が途切れるなどの問題が出てきます。そこでFFTの計算をバックグラウンドでやらせるというマルチスレッド化が必要になったりします。実はマルチスレッドはまだやったことがないので、チャレンジ課題としては手応え十分といったところです。
最終的な目的はマイクから入力した音の音階を判定するということなんだけど、これが実はかなり難しく奥の深い問題です。ちょっとやってみればわかりますが、人間の声というのは母音によって波形が異なり、当然スペクトルの出方も異なってきます。厄介なことに基本波の2倍が強くなったり、逆に1/2が強くなったりする場合もあり、単純にスペクトルのピークを求めればいいというわけにはいきません。もちろん男性と女性によっても違うし、人によっても違うでしょう。そうなるとテストのしようがないんじゃないかと・・。そういえば「鼻歌をMIDIデータに変換する」なんていうシェアウェアかフリーウェアがあったよなぁ。あれはどういう手法でやってるんだろうか？ 一番肝心なノウハウはどこも出したがらないもんだ・・
・・とまあ、かなりの難題であることには違いないけど、目標が困難であればあるほどやる気も出てくるってもんだ。これが時給○○○○円でやる仕事かっていうのはさておき、これができれば怖いもんなしだぜ！
それにしてもね、これほどアカデミックなことをやったのは大学を卒業して以来初めてだよ。前の会社では一日汗まみれになってひたすら肉体労働だったからね（笑）。学校で習ったことなんてクソの役にも立たなかったね。あんな低級な仕事は正社員にやらせるのがもったいないよ（爆）。それで給料が今の3倍くらいあったんだから、バカらしくてやってられんよな・・
JavaScriptにおけるクラス定義の方法についてネットを検索していたら偶然見覚えのある名前が目に留まりました。同姓同名はいくらでもいそうなのですが、プロフィールを読むうちにそれは確信に変わり、さらにリンクをたどっていくと友人の方が作ったサイトに行き着きました。
そうです、これはまぎれもなく昨年尼崎で起きた列車事故で亡くなった大学の後輩が作ったサイトでした。彼はかなり早い時期から日本のオブジェクト指向界における先駆者的役割を果たしていたようです。大学時代、彼は週に一度くらいしか研究室に出てこなくて、おとなしくてあまり目立たない存在だったのですが、こんなすごいことやってたなんて、そして多くの人に愛されていたことを今の今まで知りませんでした。それもプログラミングは就職してからやり始めたはずですから大したものです。友人や有志の方が彼の功績を永久に残そうとサイトを引き継ぐことになったようです。
ほんとに偉くなったんだよなぁ・・と感心しきりです。それに引き替え、自分は能なしのプータローで低所得で負け犬のどうしようもないグータラ人間になってしまいました。今生きてたら前に出られないほど恥ずかしいです。
ソフトとまったく縁のない職種に就いてずっと接点がなかったのに、運命のいたずらか今頃になって接点ができてきました。もし彼が生きていたらオブジェクト指向について議論を交わせたのかもしれません。しかしそれは叶わぬ夢となってしまいました。せめて彼の残した遺産を活用させてもらいます。合掌・・・
そうです、これはまぎれもなく昨年尼崎で起きた列車事故で亡くなった大学の後輩が作ったサイトでした。彼はかなり早い時期から日本のオブジェクト指向界における先駆者的役割を果たしていたようです。大学時代、彼は週に一度くらいしか研究室に出てこなくて、おとなしくてあまり目立たない存在だったのですが、こんなすごいことやってたなんて、そして多くの人に愛されていたことを今の今まで知りませんでした。それもプログラミングは就職してからやり始めたはずですから大したものです。友人や有志の方が彼の功績を永久に残そうとサイトを引き継ぐことになったようです。
ほんとに偉くなったんだよなぁ・・と感心しきりです。それに引き替え、自分は能なしのプータローで低所得で負け犬のどうしようもないグータラ人間になってしまいました。今生きてたら前に出られないほど恥ずかしいです。
ソフトとまったく縁のない職種に就いてずっと接点がなかったのに、運命のいたずらか今頃になって接点ができてきました。もし彼が生きていたらオブジェクト指向について議論を交わせたのかもしれません。しかしそれは叶わぬ夢となってしまいました。せめて彼の残した遺産を活用させてもらいます。合掌・・・
GPS関連のソフトを開発してみようと、少しずつ構築を始めています。後で使い回しが効くようにクラス化を目論んでいるんだけど、慣れないポインタとか使ったらえらい苦労する羽目に・・。
最近PHPばっかりやってたら型宣言がないのに慣れちゃって、久々にC++をやるとつまらないミスやエラーだらけなのだ。エラーメッセージが出てくれるのはいいが、何にも言わずに通ってしまうのが一番厄介だ。特に値を入れるべきところにポインタが入ったりするとめちゃくちゃな結果になる。
例えばトラックのデータみたいなものは配列で表すと挿入や削除が厄介になるため、リスト構造で表すのが最適なのだが、これまでやったことがないのですごく苦労した。動的にメモリを確保するやり方は下手をするとメモリリークを起こすので慎重に扱わなければならない。
Javaをやったらクラスの概念はすっきりとわかったような気がしたのだが、C++のクラスは何でこんなに複雑なんだ？ JavaはC++のサブセットと言われる理由がよくわかった。Javaの方が洗練されていてずっとわかりやすい。ポインタというややこしいものがないし、メモリ管理に気を遣わなくていいので本質だけを考えればいいのだ。順序としては先にJavaをやってからC++をやった方がすんなりと理解できるだろう。僕みたいに中途半端にC++をやってからJavaをやって、またC++に戻ってきたら、そういうことだったのかと目から鱗が落ちることしきりである。
C++って完全に理解してる人はどのくらいいるんだろう？ 別に全部わかってなくても使えるんだけどね。オブジェクト指向の考え方から言うとファイルの出力にfprintfを使ったりするのは美しくないけど、CスタイルとC++スタイルをごちゃ混ぜにすることは許されてるわけだし、まあ実用本位です（笑）。やっぱりfprintfは便利なので・・。もともとC++自体がCの上に建て増しされたものだから、Javaなど後発の言語に比べると美しくないのは否めないですね。
最近PHPばっかりやってたら型宣言がないのに慣れちゃって、久々にC++をやるとつまらないミスやエラーだらけなのだ。エラーメッセージが出てくれるのはいいが、何にも言わずに通ってしまうのが一番厄介だ。特に値を入れるべきところにポインタが入ったりするとめちゃくちゃな結果になる。
例えばトラックのデータみたいなものは配列で表すと挿入や削除が厄介になるため、リスト構造で表すのが最適なのだが、これまでやったことがないのですごく苦労した。動的にメモリを確保するやり方は下手をするとメモリリークを起こすので慎重に扱わなければならない。
Javaをやったらクラスの概念はすっきりとわかったような気がしたのだが、C++のクラスは何でこんなに複雑なんだ？ JavaはC++のサブセットと言われる理由がよくわかった。Javaの方が洗練されていてずっとわかりやすい。ポインタというややこしいものがないし、メモリ管理に気を遣わなくていいので本質だけを考えればいいのだ。順序としては先にJavaをやってからC++をやった方がすんなりと理解できるだろう。僕みたいに中途半端にC++をやってからJavaをやって、またC++に戻ってきたら、そういうことだったのかと目から鱗が落ちることしきりである。
C++って完全に理解してる人はどのくらいいるんだろう？ 別に全部わかってなくても使えるんだけどね。オブジェクト指向の考え方から言うとファイルの出力にfprintfを使ったりするのは美しくないけど、CスタイルとC++スタイルをごちゃ混ぜにすることは許されてるわけだし、まあ実用本位です（笑）。やっぱりfprintfは便利なので・・。もともとC++自体がCの上に建て増しされたものだから、Javaなど後発の言語に比べると美しくないのは否めないですね。
BorlandよりDeveloper Studio 2006のバージョンアップ案内が届いた。一年半ほど前から発表はされていたのだが、Delphi2005でも実現されず、ここへ来てようやくDelphiとC++Builderの統合が実現したようだ。
これまでDelphiの方は毎年バージョンアップが行われていたが、C++Builderはバージョン6のままで止まっていたことから、開発終了かという噂も飛び交っていた。しかしこれでC++Builderの方も開発が続けられることになり、正規ユーザとしては一安心である。
今回のバージョンではDelphiとC++Builderの統合に加え、.NET対応のC#Builderも一緒に統合されることになった。一つのパッケージで三つの言語が使えるのだからかなりお買い得感がある。バージョンアップ料金は29,400円か、微妙だなぁ・・。
今どきWin32ネイティブの開発環境なんてだんだん需要がなくなってきているが、MicrosoftがWin32を完全に見捨てたことにより、C++Builderは絶対に生き残ってもらわないと困る。今さら.NETなんてやりたくもないし、C#はいらないからJBuilderと統合してくれればよかったのだが、さすがに主力商品どうしの統合は無理だったようだ。
C++Builder6からもう3年ほど経っているし、最新のライブラリが使えるとなるとバージョンアップする魅力は十分にある。最近Web系開発ばっかりでWin32はご無沙汰になっているが、商売道具だから一応揃えておかないといけないだろう。しかしPhotoshopもバージョンアップしたいし、いろいろ金がかかる。よっぽど儲かるまでお預けだなぁ・・。
これまでDelphiの方は毎年バージョンアップが行われていたが、C++Builderはバージョン6のままで止まっていたことから、開発終了かという噂も飛び交っていた。しかしこれでC++Builderの方も開発が続けられることになり、正規ユーザとしては一安心である。
今回のバージョンではDelphiとC++Builderの統合に加え、.NET対応のC#Builderも一緒に統合されることになった。一つのパッケージで三つの言語が使えるのだからかなりお買い得感がある。バージョンアップ料金は29,400円か、微妙だなぁ・・。
今どきWin32ネイティブの開発環境なんてだんだん需要がなくなってきているが、MicrosoftがWin32を完全に見捨てたことにより、C++Builderは絶対に生き残ってもらわないと困る。今さら.NETなんてやりたくもないし、C#はいらないからJBuilderと統合してくれればよかったのだが、さすがに主力商品どうしの統合は無理だったようだ。
C++Builder6からもう3年ほど経っているし、最新のライブラリが使えるとなるとバージョンアップする魅力は十分にある。最近Web系開発ばっかりでWin32はご無沙汰になっているが、商売道具だから一応揃えておかないといけないだろう。しかしPhotoshopもバージョンアップしたいし、いろいろ金がかかる。よっぽど儲かるまでお預けだなぁ・・。
スタイルシート(CSS)はHTML文書の構造とデザインを分離するために考えられた規格だが、僕はこれまでCSSを積極的に使ったことがなかった。なぜかと言うと、古いブラウザでは正しく表示されなかったり、ブラウザによって解釈が異なったりするのが嫌だからだ。CSSを使わずに二段組みなどの凝ったレイアウトをしようとすると、必然的にテーブルのお世話になることになる。しかし最近ではテーブルを使ったレイアウトというのは「お行儀の悪い」レイアウトらしい。
最近ではHTMLは文書の構造を示すためだけに記述し、実際のデザインはスタイルシートに委ねるという方法が推奨されている。これはSEO（サーチエンジン最適化）の観点からも重要らしい。サーチエンジンは見出しやリストなどのタグを解釈して、ページの価値を判断していると言われる。したがって文書の構造がきっちりできていないサイトは価値が低いと見なされてしまうのだ。最近スタイルシートはブログでよく用いられるようになってきて、身近なものになってきた。ブログがサーチエンジンに拾われやすいのもこれと無関係ではないだろう。
一方これまで作ったサイトはどうかというと、すべてテーブルを多用して作ってあり、完全に「見た目優先」のレイアウトになってしまっている。見出しタグも文字の大きさを変えるためにしか使っていない。まさに「お行儀の悪い」レイアウトの見本のようである。これではサーチエンジンに拾われないのも無理はない。
サーチエンジンに拾われやすくするためには、HTMLの文書構造をきっちり理解し、論理的に矛盾のないように記述しなければならない。つまりHTMLは論理構造だけを記述するのであって、見た目に左右されてはいけないのだ。実際の見た目はスタイルシートによっていくらでも変えられるようになっていなければならない。
今作っているポータルサイトもこれまでの癖ですべてテーブルで作ってしまった。CSSも使っていることは使っているが、どうしてもCSSでなければできない部分だけCSSに任せ、それ以外の部分はすべてHTMLで作るといういわば折衷方式である。これまでいつもこういうやり方でやってきた。この方式の利点は、どんな古いブラウザでも確実に表示できるという点にある。テーブル組みだから絶対に崩れることがない。ブログでよくあるのだが、Netscape4.x系などのブラウザで見るとレイアウトがぐちゃぐちゃになることがある。今どきそんな古いブラウザを使う方が悪いと言ってしまえばそれまでだが、ブラウザに依存してしまうのは気持ちがよくない。それでどうしても昔の方法を採りたくなってしまうのだ。今回もすべてスタイルシートに書き換えてやろうかとも思ったが、当面はこのままにしておこうと思う。お行儀は悪いけれども・・・。
最近ではHTMLは文書の構造を示すためだけに記述し、実際のデザインはスタイルシートに委ねるという方法が推奨されている。これはSEO（サーチエンジン最適化）の観点からも重要らしい。サーチエンジンは見出しやリストなどのタグを解釈して、ページの価値を判断していると言われる。したがって文書の構造がきっちりできていないサイトは価値が低いと見なされてしまうのだ。最近スタイルシートはブログでよく用いられるようになってきて、身近なものになってきた。ブログがサーチエンジンに拾われやすいのもこれと無関係ではないだろう。
一方これまで作ったサイトはどうかというと、すべてテーブルを多用して作ってあり、完全に「見た目優先」のレイアウトになってしまっている。見出しタグも文字の大きさを変えるためにしか使っていない。まさに「お行儀の悪い」レイアウトの見本のようである。これではサーチエンジンに拾われないのも無理はない。
サーチエンジンに拾われやすくするためには、HTMLの文書構造をきっちり理解し、論理的に矛盾のないように記述しなければならない。つまりHTMLは論理構造だけを記述するのであって、見た目に左右されてはいけないのだ。実際の見た目はスタイルシートによっていくらでも変えられるようになっていなければならない。
今作っているポータルサイトもこれまでの癖ですべてテーブルで作ってしまった。CSSも使っていることは使っているが、どうしてもCSSでなければできない部分だけCSSに任せ、それ以外の部分はすべてHTMLで作るといういわば折衷方式である。これまでいつもこういうやり方でやってきた。この方式の利点は、どんな古いブラウザでも確実に表示できるという点にある。テーブル組みだから絶対に崩れることがない。ブログでよくあるのだが、Netscape4.x系などのブラウザで見るとレイアウトがぐちゃぐちゃになることがある。今どきそんな古いブラウザを使う方が悪いと言ってしまえばそれまでだが、ブラウザに依存してしまうのは気持ちがよくない。それでどうしても昔の方法を採りたくなってしまうのだ。今回もすべてスタイルシートに書き換えてやろうかとも思ったが、当面はこのままにしておこうと思う。お行儀は悪いけれども・・・。
最近、約束でもなければ自転車など乗る気もなくなってきた。朝８時に起きたらもうすでに戦意喪失・・・。願わくば誰か海か川で泳ぐプランでも企画してくれんかな？
というわけで仕事三昧なのである。といっても給料が出る保証はない。世間は夏休みだとか言っているが、こんな混んだ時に出かけるのは愚の骨頂。せっせとお仕事を進めておくに限るのである。
現在構築中のポータルサイトはだんだん形が見えてきたけれども、いつものように仕様設計など何もしていない。あまりほめられたことではないけれども、常に設計とコーディングが同時進行している。頭の中にぼんやりとあるイメージを具体化する作業がコーディングなのだ。
ソフト会社などで開発する場合はきっちりと仕様書を作成して詳細設計までしてからコーディングを行うのが普通なのだろうが、僕はそういうやり方が苦手だ。設計通りに作っても完成するまで動くかどうかわからないのは不安でたまらない。僕のやり方はとりあえず最も基本的な機能だけに絞ったプロトタイプを作成して、確実に動くことを確かめながら機能を追加していくという方法だ。とにかく実際に動いているところを見ないとイメージも湧かないし、不安でたまらないのだ。一度基本形さえ作ってしまえばあとは肉付けしていくだけだから簡単なものだ。完成するまでに何度もテストを繰り返すことになるから、その過程でほとんどのバグは落ちる。一見いい加減なようだが、こういうやり方は理にかなっているように思う。設計にかかる時間を省略できる分、開発期間も短くて済むのだ。
当初の予想では３週間くらいでできるかなと思っていたが、実際にやってみるともう少しかかりそうな気がしてきた。というのもある程度アクセス数の見込めるポータルサイトを想定すると、かなりシビアな面が出てくるからだ。これまでのお遊びプログラムなら使うのは自分だけだから、とにかく自分さえわかればいいし、自分が想定したデータしか入力されることはない。それにアクセス数もしれているからサーバ負荷を考慮する必要もない。しかし不特定多数が使うものとなるとそうはいかない。どんな操作をされてもバグが出ないようにしなければならないし、入力データは万全にチェックしなければならない。さらにアクセス数が多くなるとサーバ負荷の軽減まで考える必要がある。あまり頻繁にデータベースにアクセスすると重くなるので、負荷の重いページは静的に生成させるなどの工夫が必要になってくる。
それから仕様変更や機能の追加は必ずあるものだから、メンテのしやすさを考慮して設計しなければならない。特にデザインは頻繁に変更される可能性があるので、デザインにかかわる部分はテンプレートとして分離しておく必要がある。そうでないとデザインを修正するたびにすべてのプログラムを修正しなければならなくなる。あらゆるパーツをできるだけ共通化しておくことが不可欠だ。要するに修正が一箇所だけで済むようにしなければならない。
それともう一つ大変なのがセキュリティー対策だ。特に金が絡む用途になると不正アクセスは絶対に避けなければならない。Webにはセキュリティーホールを生む危険性が多大に存在するので、それらをすべて潰していかなければならない。意外なところからデータが漏れたりすることはある。よく忘れやすいのがReferrer経由でURLが漏れるケースである。URLを誰にも教えたつもりはなくても、リンクが張ってあるとそこから相手のログにReferrerが残ってしまうのだ。管理者用ページなどは完全にパスワードでブロックしておかないと、思わぬところから侵入されてしまう危険性がある。結局のところ、こういったセキュリティーホールを潰していくのに一番時間がかかるのだ。
というわけで仕事三昧なのである。といっても給料が出る保証はない。世間は夏休みだとか言っているが、こんな混んだ時に出かけるのは愚の骨頂。せっせとお仕事を進めておくに限るのである。
現在構築中のポータルサイトはだんだん形が見えてきたけれども、いつものように仕様設計など何もしていない。あまりほめられたことではないけれども、常に設計とコーディングが同時進行している。頭の中にぼんやりとあるイメージを具体化する作業がコーディングなのだ。
ソフト会社などで開発する場合はきっちりと仕様書を作成して詳細設計までしてからコーディングを行うのが普通なのだろうが、僕はそういうやり方が苦手だ。設計通りに作っても完成するまで動くかどうかわからないのは不安でたまらない。僕のやり方はとりあえず最も基本的な機能だけに絞ったプロトタイプを作成して、確実に動くことを確かめながら機能を追加していくという方法だ。とにかく実際に動いているところを見ないとイメージも湧かないし、不安でたまらないのだ。一度基本形さえ作ってしまえばあとは肉付けしていくだけだから簡単なものだ。完成するまでに何度もテストを繰り返すことになるから、その過程でほとんどのバグは落ちる。一見いい加減なようだが、こういうやり方は理にかなっているように思う。設計にかかる時間を省略できる分、開発期間も短くて済むのだ。
当初の予想では３週間くらいでできるかなと思っていたが、実際にやってみるともう少しかかりそうな気がしてきた。というのもある程度アクセス数の見込めるポータルサイトを想定すると、かなりシビアな面が出てくるからだ。これまでのお遊びプログラムなら使うのは自分だけだから、とにかく自分さえわかればいいし、自分が想定したデータしか入力されることはない。それにアクセス数もしれているからサーバ負荷を考慮する必要もない。しかし不特定多数が使うものとなるとそうはいかない。どんな操作をされてもバグが出ないようにしなければならないし、入力データは万全にチェックしなければならない。さらにアクセス数が多くなるとサーバ負荷の軽減まで考える必要がある。あまり頻繁にデータベースにアクセスすると重くなるので、負荷の重いページは静的に生成させるなどの工夫が必要になってくる。
それから仕様変更や機能の追加は必ずあるものだから、メンテのしやすさを考慮して設計しなければならない。特にデザインは頻繁に変更される可能性があるので、デザインにかかわる部分はテンプレートとして分離しておく必要がある。そうでないとデザインを修正するたびにすべてのプログラムを修正しなければならなくなる。あらゆるパーツをできるだけ共通化しておくことが不可欠だ。要するに修正が一箇所だけで済むようにしなければならない。
それともう一つ大変なのがセキュリティー対策だ。特に金が絡む用途になると不正アクセスは絶対に避けなければならない。Webにはセキュリティーホールを生む危険性が多大に存在するので、それらをすべて潰していかなければならない。意外なところからデータが漏れたりすることはある。よく忘れやすいのがReferrer経由でURLが漏れるケースである。URLを誰にも教えたつもりはなくても、リンクが張ってあるとそこから相手のログにReferrerが残ってしまうのだ。管理者用ページなどは完全にパスワードでブロックしておかないと、思わぬところから侵入されてしまう危険性がある。結局のところ、こういったセキュリティーホールを潰していくのに一番時間がかかるのだ。
Calendar
