はてなブックマーク

しばらくTwitterでつらつらと書いていたのだけれども，少しまとまったことを書きたかったのでこちらに。 巷でその手の文章を読んでいると，たまに次のような話を目にすることがあります。 大人になると，様々なことに価値的な序列がつけられるようになり，勝ち組になったり負け組になったりする。それに比べて，子供はこれらの価値から自由でいられる。子供ばんざい。子供ばんざい。 あたしゃもうオッサンになって，いわゆるオトナの世界にいるわけですけれど，たしかに，勝ち組とか負け組とか，どっちが優れてるとか，あいつは劣ってるとかいった，ある種の「差」が話題になることがあります。その内容は，仕事の出来不出来であるとか，就いてる職業であるとか，学歴であるとか，年収であるとか，家族構成とか，家はどうしてる，貯金は，趣味は，交友関係は……と，際限がありません。 一方で，それなら子供の世界はそうした価値的な序列から自由か

3月中旬から4月上旬にかけて、SIベンダーやネット系企業を取材し、多くの現場を訪れた。多数のエンジニア（40人以上）に取材して分かったのは、こうしたエンジニアには共通点がいくつかあるということだ。 最大の共通点は、技術や業務面で多くの領域の知識、スキルを兼ね備えているという点。つまり「マルチスキルなエンジニア」である。 しばらくエンジニア業に身を置いていて，そこそこ分かってきたことなんだけれども，理想とされるエンジニア像というのは，今も昔もそんなに変わらないな，とか云々。「マルチスキル」つまるところ，ソフトウェア開発にまつわる技術領域を広く回せるスキルというのは，あたしがこの業界に入った時から言われていました。ソフトウェア技術は，各領域で細分化されているけれども，開発にあたってはそれらを総合して作り上げなくてはいけません。なので，多方面に亘る専門的な知識が各エンジニアに要求されるのは，当た

「共通化 → 継承」という考えは間違っている、と断言する。こんなものはオブジェクト指向でも何でもない。仮想関数を持たないスーパークラスは要注意だ。 これはまさしくその通りで，「共通化 → 継承」のような説明がいまだに堂々とまかり通ってるのには，どうしたもんだろうと思う。それなりに人気のある書籍ですら，そんなこと書いてることがある。 思うのだけれども，「共通化 → 継承」といった発想が産まれる原因は，「差分プログラミング」の実装手段として継承を位置付けてるからなのだと思う。もちろん，差分プログラミングという概念自体，発想としてアリなのは言うまでもありません。同じ処理をあちこちに書かないことは，プログラマの美徳にすらなっている。しかし，それはあくまでも発想であって，具体的な実装手段を伴うものではありません。この点，そこに（実装）継承という実装手段をあてがったバカタレは，ほんとに罪深いと思う。委

仕事でプログラムを書いていると，デバッグ以外に他人のソースコードを読む機会がたくさんあるわけですけれど，大抵の場合，漫然と読んでいるのではなく目的があります。例えば，字句解析する際のバッファ管理の方法を知りたいから GCC を読むとか，ベクタオブジェクトの描画系はどうやってるんだろと思って，Inkscape のソースを読むとかいった具合。もちろん，それらが最適なプログラムとは限らないわけですけれど，他の人の考え方を取り入れるには，下手な能書きが書かれた本を読むよりも，ソースを読む方が手っ取り早かったりします。 で，ま，目的をもってソースを読むわけですけれど，この場合，まずもって目的のソースにたどり着けなくちゃいけません。全然関係ないところを読むのは時間の無駄ですから。この点，巷には，ソースの読み方をあちこちで紹介しているわけですけれど，あたしはあまりこゆ読み方はしていない気がします。例えば

なんでこんなことを思うようになったかというと、数年前と比べると意見をガラリと変えるブログやソーシャルブックマーカーをチラホラ見るようになったからです。 20代中盤と比べると30代だと恐らく社内での立場が上昇していてそれまでなかった視点を持ったのだろうとか、「何故できないのか」というような問題の真相を垣間みたりして経験を積んだのかなと思った事例もあります。「以前よりも保守的な表現になったなぁ」と。 その一方で、「ネット上で声が大きい人」というのは、ある程度定着している感があり、「声の大きい人の平均年齢が徐々に上がってないか？」と思います。 直接名指しされたことはない（と思う）けれど，あたしもいわゆるモヒカン的な位置付けにされていたところがあるので（今もされてるかもしれないが），なんつか，微妙な気持ちになってしまいました。また，このブログで書いてることが以前と比べると保守的な傾向にあることも，

某所にいんすぱいあされたので少し。 昔大学で法律を専攻しておきながら，現在ソフトウェアで飯を食ってる人としては，技術者の様子と法律家の様子のどちらも見えるわけだけれども，技術を知らないままに法律を語る法律家と同様に，法律を知らないままに技術を語る技術者の法律論議が，おっさんの与太話以上の話にならないことに悲劇を感じます。とゆか，「法律家を小馬鹿にする私」なるものに，何かしらの優越感なり技術者としてのアイデンティティを感じているかのようにも見受けられる。もしそうなのであれば，悲しい……とゆか，みっともないからやめた方がいいと思う。おっさん（とゆかガキ）の与太話は相手にされないから。 法律を（ちゃんと）専攻していた人と，そうでない人の違いは，おそらくバランス感覚にあって，それは実際によく感じるところでもあったりします。法律の場合，あるルール（あるいは解釈）によって利益を受ける人がいれば，多くの

某氏……に限らず，巷でドキュメンテーションを嫌がっている向きが典型的に口にすることに，次のような話があります。 以前もこの話を書いたかもしれないけれど，この命題は非常にトリッキーで詭弁的だと思っています。確かにソースコードにはバグも含めてすべてが書かれている。これは間違いありません。 しかし，ソースコードにバグが書かれていることが分かっていたとして，これは開発で必要な情報となりうるのでしょうか。あたしには，意味のない情報としか思えません。というのも，開発に必要なバグに関する情報は，「バグが書かれているか」ではなく「何がバグでソースコード上どう実装されているか」に尽きるからです。 そもそも，プログラムはプログラムした通りにしか動かないのだから，プログラム（ソースコード）の内部に「バグ」という概念はありません。通常，バグは開発者/設計者/ユーザが意図した通りにプログラムが動かないこと言います。

あたしは定番の K&R でC言語を身に付けたので，これまで他の入門書をよく読んでいなかったんですけれど，先日，新人君の教育（春休みにインターンで来ている）で読ませてもらう機会がありました。どんなの読んでたの？てな具合で。 新人君が読んでたのはこちら。割と定評があるそうです。なんでも，入門編やら実践編やらと，複数の書籍に分かれているんだとか。 で，入門編と実践編を一通り読んだんですけれど，率直な印象は「これでプログラム書けるようになるんかいな？」といったものでした。この入門書，C言語の言語仕様は（かなり詳しく）学ぶことができるだろうけれど，プログラムを書けるようになるとは思えない。少なくとも，プログラムを書けるようになるには，本書とは別の経験が必要です。ちなみに，これは入門編も実践編も同じ。くだんの新人君は，別途教育を受けていたので，本書とは別のパスでプログラムを書けるようになったようです。

Fireｆox で GMail の新着メールを通知してくれるアドオン GMail Notifier でログインできないトラブルがあるようなので，メモがてら。なにげに応急処置が本家のページで紹介されているんだけれども，日本語のリソースがないようなので紹介しておきます。 応急処置は簡単で，一旦 GMail Notifier を削除した後，Toshio 'ADAM' Kudo さんのバグフィックス版プライベートビルドと差し替えるだけです。 http://www.nuko.org:4649/addons/temp/gmail_notifier-0.6.4.3.privateBuild1-fx.xpi Toshio 'ADAM' Kudo さんは，ご自身でもアドオンを作成されています。 バグフィックスされたオフィシャルビルドが出る様子がないようなので，GMail Notifier のユーザさんはこち

通信業界にはもちろん、携帯電話メーカーにもソフトウェアを自分で書ける人がいない今の日本の状況を考えれば、世界のトップクラスのソフトウェア・エンジニアを自社で抱えるアップルやグーグルにおいしいところを持って行かれても当然。いままでさんざん「ITゼネコンや下請け」にソフトウェアの開発を丸投げにして来たツケが今になって回って来ただけのこと。 （snip）そろそろ「ITゼネコン」から脱却して、社内に「自分でコードが書ける」ソフトウェア・エンジニアを育成する時期だと思うんだがどうだろう。前にも別のところで書いたが、「コードを自分で書かないエンジニア＝自分で料理をせずにレシピだけ書いている料理人」と同じだと覚えておいて損はない。 まぁ，その通りだな……と。うちの会社は技術者出身の人がほとんどなので，簡単なプログラミングはほとんどの人間ができるんだけれども（営業でも C や Java，VB くらいならい

言うまでもないことですけれど，C++ は静的な型付け言語で，ひとつの配列に複数の型のオブジェクトを格納することができません。これを C++ でやる方法はないもんでしょうか。例えば，配列を '(' と ')' で括り（各要素は ' ' で区切る），文字列を '"' で括る場合，次のような具合に格納したい。 ( 10 "string" ( "inner" 15 2 "hello" ) 123 ) 問題は，配列クラスの作り方で，収め方を工夫することになります。具体的には，配列の要素になるクラスに共通の基底クラス（例えば class Object）を作って，この基底クラスのポインタを配列に収めれば，ひとつの配列（std::vector<Object*>）に収めることができます。 ただ，以前書いたけれども，これでも問題があります。どゆことかというと，配列から値を取り出したとき Object* 型の変

なんか，std::ifstream のバイナリモードでファイルの読むのが，すごくツライんですけど，気のせいだろうか。 #include <fstream> #include <iostream> #include <string> static const ::size_t BUFSIZE = 1024; int parse(const std::string& path) { std::ifstream f; try { char buf[BUFSIZE]; // open() のために例外設定 f.exceptions(std::ios::eofbit | std::ios::failbit | std::ios::badbit); f.open(path.c_str(), std::ios::in | std::ios::binary); // read() のために例外再設定 f.

パソコン本好きが知られたからか，会社（部）の図書係になってしまいました。で，早速，「最近の若いのは C/C++ は書けるけどアセンブリが読めなくていかん。ちょっと入門書を買ってきて。」ということに。図書係というのは，要するに雑用係。若いもんばっかが，アセンブリを読めないわけじゃないと思うんだけど。 たしかに，C/C++ プログラマ，なかんづくプロの C/C++ プログラマは，アセンブリを（書けないまでも）読めた方がいい。比べるもんでもないけど，英語よりも必要性が高いんじゃないかと思うくらい。プログラマが直接アセンブリを書くことは稀だけれども，例えば C/C++ でプログラミングしていて次のような問題に当たった向きは，読めるととても便利です。 リリースビルドとデバッグビルドでアプリケーションの挙動が異なる。 Windows で 0xc000001d（illegal instruction）な

最近の文字コードめぐる状況について，まとまったもんが欲しかったので読んでいます。なお，ここでは符号化方式のことを文字コードと呼ぶことにします。 多バイトコード圏（という言い方も今風ではないが）に暮らしている人にとって，文字コードの話は，プログラミングする上で避けて通れない問題だったりするわけですけれど，その割に，日本語（をはじめとした東アジア文化圏）の文字コードについて実装の側面からまとめている書籍は，あまりなかったりします。ここでは「実装の側面から」というのが重要。これまで，ちゃんと参照できる実装本といったら，『CJKV日中韓越情報処理』くらいしかなかったんじゃないかと思います。しかし，これは高いし重い。 文字コードというと，政治的/文化的にウェットな議論があって，それはそれで議論する意味があるんだとは思います。しかし，こゆもんは，プログラミングする上で実は「どうでもいいこと」だったりす

いや，概念としてはある程度定着していると思うんですけどね。あたしが直接関わっていたわけじゃないけれど，要件聞き（御用聞き）なり要件決めなりが，あまりにもヘタレだと思うことがあったもんで……。 「仕様バグ」というのは，仕様決定の段階で入り込むバグのこと。具体的には，以下のようなものです。 お客さんが言った要求が満たされていない。 仕様上，ユーザの操作方法が矛盾している。使いづらい。 仕様上，物理的にありえないパフォーマンスを要求している。 仕様上，出力結果が一般的なものの見方から外れている。 言ってみれば，作る前から作りこまれてるバグのことです。こゆのは，仕様通りに作るとバグになる。巷では，たまに「このバグは仕様です」な話で盛り上がってるトコがあるけれども，「仕様です」でもみ消せるバグは，仕様バグの場合が多い気がしています。つまり，作る前から分かってるバグ。 一方，プログラマなり SE なり

ここ1ヶ月ばかり，自分の仕事の一部を某氏に頼んで作ってもらっています。あたしにそういう感覚はあまりないんですけど，役職的には部下ということになります。某氏は，問題に対して適切な実装を提供するのが仕事。あたしの仕事は，泥臭いところを整備して（上司と折衝したり他モジュールとのインターフェイスを検討したり），某氏に開発に専念してもらうことです。 一応，上司っぽく振舞っていることとして，こちらで開発方針を立てて内部設計を作ってはいるんですけれど，これも本当は某氏に預けたいところだったりします。手持ちの仕事がいっぱいいっぱいなもんで。 で，その某氏，開発方針や内部設計のあれこれを自分で決められるようになれば，（やや）自由にモノが作れるようになるわけで（もちろん，マイルストーンごとにレビューは行うが），本人のためにもなると思っているんですけれど，なかなか預けられなかったりします。言ったことはかなり正確

先日書いた，「qune: よりそいプログラミングのすすめ」が『WEB+DB PRESS Vol.49』に紹介されていてびっくり。「濃縮還元オレンジニュース」で紹介していただいたのは知っていたんですけど，まさか本誌に載るとは……。記念に一冊買ってしまいました。 で，今日は本誌を同僚とつらつら読んでたんですけど，C の話でちと盛り上がっていました。 今回の特集は DRY（Don't Repeat Yourself）の特集で，要するに，繰り返しや重複するコードをなくしましょうという話。WEB+DB PRESS では，基本的に C/C++ を取り扱わないんですけれど，今回はマクロスイッチを使って宣言の数を減らす参考例が挙げられていました（p46）。次のようなもの。 #ifdef MAIN #define EXTERN #define INITVAL(x) = x #else #define EXT

型は書かないだけでそれなりに意識しなくちゃいけないわけで，そこら辺が文脈を読むというか，空気を読むというか，そういうお作法と重なるところがあるんじゃないかと思ったり。 で，どういうわけだか，この話を読んだ知人から「具体例を示さんとわからん」といったご指摘を頂戴。少し凝った話なんですけれど，具体例を挙げてみます。 OOP にはデザインパターンつのがあって，その中に Strategy というパターンがあります。どういうもんかというと，C++ で書くとこういうもん（あまり厳密ではないけれど）。 #include <iostream> class Calculator { protected: Calculator() throw () {} public: virtual ~Calculator() throw () {} public: virtual int calc(int rhs, in

所用で Unicode に少し首を突っ込むことになったので，実装方法を中心にやりなおしています。 やろうとしていることは，それほど厄介なことではなくて，とりあえず文字コードの変換ライブラリを作りましょう，とかいった話。この頃は，日本語も JIS 第四水準までサポートした JIS X 0213:2004（いわゆる JIS2004）が OS レベルでサポートされるようになったこともあって，周辺のアプリケーションもこれに対応する必要がそれなりに出てきました。今から作るなら，JIS X 0213:2004 は Unicode で実装するのが近道なんですけれど，これまでの JIS X 0208 を実装していた符号体系（CP932 とか EUC-JP とか）とも歩調をあわせる必要が出てきたので，ギャップを埋めるライブラリが欲しいね，ということになったのでした。 ここら辺の話，オープンソース界隈では，i