新・日々録 by TRASH BOX@Eel このページをアンテナに追加 RSSフィード

2017-10-30

初めて生PCMを触る人には『WAVプログラミング C言語で学ぶ音響処理 増補版』を推薦します

久しぶりに生のPCMデータを弄る機会があった。生PCMまわりは独学で、割と知識が歯抜けだったので、基本的なところを学び直そうとしたところ、意外とまとまった情報が見つからなかった。

色々と探し回って、ようやくたどり着いたのがこの本だった。

WAVプログラミング―C言語で学ぶ音響処理

WAVプログラミング―C言語で学ぶ音響処理

本書を見せた同僚の感想は「生PCMを取り扱う業務にアサインされた若手・新人に自習用に渡すのにちょうど良い本」だった。

この本は生PCMを触る際のものすごく基本的なことがサンプルコード付きで説明されているというか、むしろサンプルコードで説明されている。そのため、読み解くにはC/C++系統の言語知識が必要となるのだが、逆に考えれば、その辺の言語が分かっている若手のプログラマに参考資料として渡しやすい本だと言える。

内容自体も「ステレオのLとRを反転」とか「モノラル化」とか「16bitから8bitに変換」とか「ボリューム変更」とか、そういう簡単なところから始まっている。意外なことに、この辺の内容がまとまっている資料があまり無いのである。そういう意味では、本書はあまり類書の無い本だと言える(ニッチすぎるのか絶版寸前っぽい感じである)。

おそらく本書の次にやさしい本は『C言語ではじめる音のプログラミング―サウンドエフェクトの信号処理』だが、こちらの本はサウンドエフェクトの入門書なので、生PCM入門書としては厳しいというか、そもそも分野が少々異なるといえる。

本書のサンプルコードはWAVファイルの生PCMを加工するものが大半で、最後の1章のみWAVファイルからPCMを取り出して加工してWindows APIで再生させるものである。

なのでリアルタイム処理まわりはサッパリなのだが、その辺になると各OSマルチメディアAPIによって流儀が全く異なってくるので、1冊の本にまとめるのは厳しいだろう。しかも実のところ、どんなAPIを使おうとも、生PCMを直接加工する部分は、WAVファイルで生PCMを加工する場合と基本的な考え方は同じである(そのAPIに用意されている便利な機能を使う場合は別だけど)。

あとサンプルコードが16bitよりも大きな分解能には対応していないのだが……「8bitがOffset Binaryで16bit以上が2の補数」という点さえ押さえておけば、サンプルコードを片手に自前でコードを書くのは難しくないはずだ。というかサンプルコードは中身を理解してから流用するもの(※ただしライセンス等の問題が無い場合に限る)で、何も考えずに流用しちゃうのはプログラマとしてアウトだ。

ともかく、PCMまわりの知識ゼロの状態で生PCMを触るのなら、1冊目として本書はオススメだ。後は、実際に使うAPIのドキュメントとか、サウンドエフェクト系の作業ならそちらの入門書とか、もう1〜2冊ほど併読すれば何とかなるだろう。

2017-10-18

2017-09-23

分野に関係なく『組込みソフトウェア開発のための構造化プログラミング』を読んでおかなきゃあかん

『組込みソフトウェア開発のための構造化プログラミング』を軽く読んだのだが、この本は組込み系以外の分野でコードを書いている人も読むべきだ。

全部で8章で、そのうちC言語成分が含まれているのは2章と5章だけ。だから残りの6章はC言語とは縁遠い分野のプログラマでも読めるはず。

意外と忘れがちなのだけど、オブジェクト指向プログラミングが必須であるような大規模な開発であっても、分割統治を繰り返した結果として、個々のクラス/モジュールといった粒度においては小規模なプログラミングの世界となる。

で、構造化プログラミングは元々高々3000行程度のプログラムが大規模プログラムと呼ばれていた時代に原典が考案された上で、頭の良い人たちが10年以上もの間に寄ってたかってそういった粒度の世界において高品質なコードを書くにはどうすればよいのかを考えて散々揉みしだいた結果として導き出された結晶な訳だ。

構造化プログラミングに関する文献を探せば分かるが、1968年の最初の論文以降、10年以上もの間、原典を継承・派生させた文献がコンスタントに出現している。それだけ色々な人たちに揉まれているのだ。例えば『ソフトウェア作法』の原著である『Software Tools』が出版されたのは1976年だ。

だから出たばかりの頃と散々揉まれた後では割と別物というか、ダイクストラ本人の論文だって1968年の「Go To Statement Considered Harmful」と1970年の「Structured Programming」とでは随分と内容が異なる。

散々揉まれた後の構造化プログラミングは今でも十二分に通じる。むしろ構造化プログラミングを古臭いと言われると「じゃあ、クラス/モジュールの中身としてメソッドを書くときに、何を指標とすればよいの?」と途方に暮れるものだ。

手続き型の系譜に連なる言語を使っているなら(それがオブジェクト指向プログラミング言語だろうと関数型言語とのハイブリットだろうとも)、現代においても「小規模なプログラミング」――クラスやモジュールの中身を実装する際には非常に有効な技法だ。

構造化プログラミングを軽視するのは、考え方によっては「質の悪い建材で家を建てる」に等しいものだ。設計品質が同じならば、出来上がる家(クラス/モジュールコンポーネント)の品質は建材の質に左右されるものである。

2017-08-29

2017-08-17

優秀なエンジニアは勉強しない

もう1ヶ月経つから、そろそろ書いてもよいだろう。

個人的な好悪より「エンジニア」ではなく「プログラマ」と記述するが、元来プログラマは勉強などしないものだ。

プログラマの三大美徳を思い出すこと。

プログラマは、技術的課題にたいして怠惰・短気・傲慢をもって取り組む*1。このいずれかに触れる何かがあった場合のみ、プログラマは意地になって、ドキュメントを漁り、コードを読み、昼夜を問わず解決方法を探る。

これは傍から見ると、特に職業プログラマの場合、私生活をかなぐり捨てて仕事をしている社畜だと思われがちだ。しかし実態は、単に「筋の悪い力業」で課題を解決することによる気持ち悪さから逃れようとする、プログラマ特有の生理現象に過ぎない。

もとより、課題を無理矢理力でねじ伏せて解決するなど、目先の売上としては正しくとも、技術的には後々に禍根を残すことが多いものだ。今日の「筋の悪い力業」は、明日の死亡フラグ。そのことを身をもって知っているからこそ、もっとマシな解決方法を得るためにプログラマはあがき続ける。

しかし、これらの行為は、決して「勉強」とは言わない。終業間際のコーディング中に何かしら引っかかるものを感じて、帰宅後に一風呂浴びた後に一杯飲みながらデバイスのデータシートを読んだりフレームワークの公式リファレンスを眺めたりしていようとも、プログラマはそれをもって「プライベートに勉強している」とは言わない。

なぜなら、それはプログラマ特有の習性ないし生理現象であり、不快さから逃れようとした結果に過ぎないからだ。気になったからちょっと調べただけで、別段大したことはしていない――というのが、当人の答えだ。

一方で、三大美徳にかすりもしない課題には、プログラマは熱意を抱けない。だから、そんなものをわざわざ勉強しようとなど思わない。

そんなことするぐらいなら、趣味に費やす方がマシだ。

興味深いことに、理由は分からないがプログラマには古い意味でのおたく・マニア的気質の持ち主も多くて、そのためか趣味についても割と深掘りする傾向にあることが多い。英語でいうなら「like to do」よりも「hobby」に近い。どちらかといえば凝り性だ。

ついでに言えば、三大美徳を重んじるプログラマには、プログラミングという行為そのものや、プログラミングから派生した物事を趣味とする人も多い。この辺り、金田一秀穂氏の説に沿うとするなら、おたく気質の人だと割とプログラミング系の趣味しか持たず、マニア的気質の人だとプログラミング関連以外の趣味も持っている。

私の周囲という非常に狭い観測範囲となるが、技術面で一日の長がある人は、割とコンピュータ関連の趣味を持っている(もしくは過去に持っていた)ケースが多い。実際には、並行して他の趣味も持っている人が大半で、コンピュータプログラミング系に趣味が偏っている人は少数派である。

こういった趣味は、その時々の時流と一致すると、職業プログラマの仕事に大いに役立つ。

例えば、私の本業は組み込み系Cプログラマなのだが、趣味で全く畑違いの言語を触ることがある。それらのうち、JavaScriptLuaXSLTあたりは、なぜか数年後に業務で触れることになった。趣味レベルとはいえ事前に経験済みだった点は、仕事にプラスになった。

また、ライトなPC自作も趣味で、しかしお金がないのでOSとしてLinuxディストリビューションを入れている(特に最近は、手間をかけるのが面倒なのでUbuntuに統一している)のだが、これも業務絡みでUbuntu LTSやDebian仮想マシンを構築・運用したり、実験機としてRaspberry Pi(のRaspbian)を使ったりする場合に若干の応用が効くものだ。

こういったケースは、実のところ少ない。趣味の一環でプログラミング言語を30言語近く触ってきたが、その大半は本業では使うことがない。業務で使うことがあったとしても、シェルスクリプトPythonPowerShellのように(私の仕事では)内製ツールや自分用ツールの開発に使う程度であったり、Makefileのように「納品物には含まれるけど、実際のソフトウェア製品そのものではないよね」という具合に留まることが多い。

最近だとちょっとしたArduino用ライブラリを書いたりしたが、これも仕事とはほぼ無関係だ。そもそも仕事でArduinoを使うことなどないし、今のところその予定もない。

あくまでも趣味なのだ。プライベートの趣味は自由だ。だから、趣味がその時々の時流と一致するとは限らない。むしろ「一致しない」という前提で考えるべきだろう。

というか、趣味に無理矢理「仕事のエッセンス」をぶち込まれることほど無粋で興醒めなことはない。

実のところ、「お勉強」という視点では、Windows Serverの構築・運用・管理だとか、Office 365クラウド機能の評価とか、やったほうがよいことは色々ある*2。あるのだが、それは私の趣味に合わないので、手を出していない。

結局、会社的にみて「優秀なプログラマ」というのは、単にその個人の趣味が時々の時流に偶然合致しているに過ぎないのだ。そしておそらく、その会社では偶然にも今までコンピュータ関連の趣味の持ち主が多くて、さらに偶然にも彼らの趣味が会社の方向性と重なる部分がそこそこ多かっただけなのだ。

だから、職業プログラマにたいして「業務時間外に勉強を」云々と述べるのは筋違いだ。アレは趣味なのだ。趣味にケチをつけるな。

よく分からないけど、アメリカのような雇用の流動性が高い地域なら、会社のその時々の方向性と合致する趣味の人を数年単位で雇用するなんてことがあまり無理なく可能じゃないのかしら。ただし方向性の違いで離職したり、逆に方向転換のためにレイオフしたり、なんてことも割とある感じで。

*1:「技術的課題にたいして」という点に留意すること。同僚/チームメンバーといった「人」というファクターにたいしては謙虚・尊敬・信頼をもって臨むのが正しい。

*2:最近、時々自分の本業が分からなくなる。