サピア＝ウォーフの仮説を取り上げていると聞いて。
非常に興味深い本である。大学の教養学部時代に聴いた、ヒトの認識と文化についての「鶏が先か、卵が先か」的な話を思い出した。全くもって専門分野ではないが、こういう話は好みだ。
まあもっとも、プログラマに見られる「サピア＝ウォーフの仮説」的な現象は、あれは本書で取り上げているものとは別の要因が働いているのではないか。個人的には、そう妄想している。
面白そうなので買ったのだが、自分が数学の能力を大幅に欠いていることを忘れていた。とりあえず数式絡みの部分を読み飛ばしてみることにする。
情報処理技術者試験では個々の要素が個別に現れるだけなので、学習者はそれらの要素が何のために存在するのか分からないままだ（なので学習する理由は分からないし、現実のシステム開発との関連性もつかめないので、学習のモチベーションは上がらないし、試験後にはすぐに忘れてしまう）。
私は個人的に興味を持っているので、その辺のことを本格的に知りたいのだが……うーん、まだ基礎知識が足りなかったか。
id:eel3:20130526:1369749091 に引き続き、Cプログラミング強化キャンペーン中。あーでも最近C言語でゴリゴリ書く機会が少ないな。
モダンC言語プログラミング 統合開発環境、デザインパターン、エクストリーム・プログラミング、テスト駆動開発、リファクタリング、継続的インテグレーションの活用
案件次第だが、Cでゴリゴリ書くときは使っていない。WindowsアプリならVisual Studioを、Mac OS XやiOS絡みならXcodeを使う。
いや、EclipseやNetBeansには興味がないわけではないのだ。C言語を使うときはミドルウェア屋さんなことが多いので、Windows上でMinGWと連携できれば済む。EclipseのCDTでMinGWを使うネタは昔からの定番だと思っている。
ただ、Javaを使っている点が……最近、セキュリティ的にNGな雰囲気のあるJavaなので。他によさそうなIDEはないだろうか？
付け加えれば、Visual StudioとXcodeに加えて第三のIDEを学んで併用する自信がない。現状でさえ、デバッガのステップ実行時のショートカットキーをVisual StudioとXcodeとで間違えることが多々あるので。
世の中的には、ライセンスを買ってもらえる or 昔買ってもらえた人なら、HEWとか使っているケースもそこそこあるように思う。
構造体を使ったオブジェクト指向プログラミング的アプローチはよく使う。デザインパターンは学習すらしていないが、興味はあるので本書で勉強する予定。
関数ポインタは非常に強力だ。構造体を使いつつ、動的に仮想関数テーブルの一部を書き換えてしまう、なんて野蛮なこともできてしまう（C++ではなくC言語の話）。
ただし、静的解析ツールとの相性は悪い。実はこの点がオブジェクト指向プログラミング的アプローチの足かせとなっている気がする。
いや、HEWに付いているCall Walkerを使うと静的解析でスタック使用量を計算できるのだが、関数ポインタがあると途中で途切れてしまう訳で。これを手作業で修正しようとすると、Call WalkerのUIがダメ仕様であるがために一大事業となってしまう。Call Walkerが吐いたファイルの仕様さえ分かれば、スクリプト言語で半自動的に修正できる気がするのだけど。
個人的にはTDDには若干懐疑的というか、ひとまず様子見の状態だ。というのも、ソフトウェア工学的に明白なエビデンスがまだ得られていないからだ。
とはいえ、ある程度仕様の固まっている関数については、その関数を書いてから時間が経たないうちにテストするべきだと思っている。それが基盤となる重要な関数であるなら、コードを書いたらまずコンパイルチェック*1や静的解析ツールでのチェックを行い、その次にテストするべきだ。
実は「コードを書いたらすぐコンパイルチェック」や「関数を書き上げたらすぐ単体テスト」を実現するには、TDDのように開発初期の段階からソースコードをビルドする環境が必要となる。この環境は、TDDでは開発初期段階で否応なく準備せざるをえないのだが、非TDDではついつい先延ばししてしまうことが可能だ。このあたり、先延ばしできないTDDはよい仕組みだとは思う。
またTDDで行うようなテスト自動化やモック（スタブ）の採用は好ましい。というか以前より自前で似たようなことをやっている。そういう人は意外といると思う。
TDD抜きにしても、本書のTDDの章には個々に優れた知見が書かれているので、非常に参考になる。
CIのような、ある程度大きなフローにたいする自動化は未経験だ。
個別の部分部分において個人的に自動化している人は多いと思う。まあ、その手段はバッチファイルやシェルスクリプトだったり、スクリプト言語だったり、makeだったりするのだが……。
もし、ある程度規模の大きいシステムの開発にて中堅以上のポジションにいたとするなら、CIのツールには心惹かれて飛びつくと思う。
残念ながら現状は、あまり継続性のない小規模なプロジェクトのみ。makeとシェルスクリプトで何とかなってしまうし、「数年後に再開」というパターンに備えて枯れたツール（まあそれがmakeやシェルスクリプトだったりするのだが）を選択してしまう。
みんな、GitとかSubversionとかRedmineとかJenkinsとか、一緒に動かしているApacheやSQLサーバやサーバサイドの言語処理系を含めて、バージョンアップやデータ移行やツール変更にどう対応しているのだろう？ 運用管理のコストって馬鹿にならないと思うのだが。
買ったものの、読む時間がない（第4版の頃から同じことを言っている）。
インサイドWindows 第6版 下 (Microsoft Press)
それだけWindowsに機能が増えたのか、それとも複雑になったのか……多分、両方だ。BitLockerのようにXPの頃にはなかった機能がある。そのような新機能を加えることによって複雑になった部分もある。本書にはそれらの記述が追加されているようだ。
