October 17th, 2010 | Published in book
10/22 に発売される、 の一部を書きました。
目次 でいうと、
といったあたり。低レイヤ色が濃い… 需要あるのか…
ぼくの書いたところ以外でいうと、アプリの出来を左右する隠し味を加える方法が散りばめられていて良い感じです。 まえがきにもあるように、「ああ、このアプリのこの機能、どうやって実現してるんだろ…」と stackoverflow や Apple の DevForum を探しまわる手間、を少しショートカット出来るのではと思います。あと、全体で180ページとコンパクトにまとまっているので、モビリティもばっちりですね。
主著の sonson さん、 UICoderz のみなさま、長い間おつかれさまでした。慰労会しましょう。
September 15th, 2009 | Published in book
さんと、 という殴ったら人の命がなくなりそうなほどに分厚い本を読む会を始めます ( )。 ・ の原書ですね。
まず方針など決めましょう、ということで第0回のミーティングを、女子ファッションのフロアしかない新宿マルイ上のスタバでやってきました。 最初に、各自のこの本を読むにあたっての目標を明確にして (基礎から CS 学びたい ()、アルゴリズムコンテストで泣きたくない ())、以下のような進め方でやることになりました。
そんな感じで、第1回を 10/1 (木) 19:00-21:00 でやります。 さてさて完全読破なるか。
ぼくは数ヶ月前に 2nd edition を購入したのですが、 さんが 3rd edition を持ってきてたまげた。章立てはぱっと見変わってないけれど、 ChangeLog によると、2章を削って2章加えた、みたいなことが書いてある。
October 28th, 2008 | Published in book
今日、オーム社より復刊された の 復刊あとがきに、Gainer++ と QCGainer をつくったということで名前を載せていただけました。GAINER の小林さん、ありがとうございました!
ここしばらくはずっと iPhone ばっかしいじってたので、 GAINER とはちょっと離れてしまってますが、MAKE: Tokyo Meeting 02 ももうじきなのでまたなにか作ってみたいですね。
July 6th, 2008 | Published in book
その2 に行き、7章を発表してきました。
前日まで、8章が担当だったと思い込んでいたせいもあり、資料をつくれずじまいだったのでホワイトボードにゆるいマインドマップを書いたりしながら話しました。 ホワイトボードに書きながら説明するというのは、うまくやれればとてもインタラクティブで良いと思うんですよね。読書会においてはとくに。
スライドをつくってみんなに発表、というのもいいのですが、せっかく本を持ち寄ってみんなで議論するのだし、発表者はあくまでもガイド役に徹した方がよいのかも。 概念図だけをスライドにしておいて、あとはその場でホワイトボードなりに描きながら議論していくと楽しそうです。
とはいえ今回はうまくできなかったので、もっとホワイトボードテクニックを磨きたいと思います。
ぼくが読書会でやりたいことってなんだろう、と考えてみると、
とかですね。WEwLC読書会は、こうしたことができる、良い場だと思います。
という名のExcelカンファレンス 第0会が行われました。 Excel SUGEEEE な話を4時間くらいぶっとおし。 次の技術的イベントに参加するときには、「Excelから来ました」と言えるくらい技術を見につけていたいと思います。
メモ:
と、大変有意義な会でした。みなさまありがとうございました。
June 2nd, 2008 | Published in book
という洋書のに参加してきました。 読書会は会議室で行われ、事件は現場で起こるのです。
読書会に来ていた人たちが、じっさいにどのようにしてレガシーコードに立ち向かっているのか。 レガシーコードというかレガシーチームとどうやっていくのか。 そういったあたりに興味がありました。
こういうテーマだと議論のときに愚痴のこぼし合いになりそうなものですが、 「こんなレガシーな現場だけど、こういうふうにやってみたよ」といった建設的な意見ばかりだったのが印象的でした。 意識の高いひとたちはあちこちにいるんだ、というのを知って励まされた感じ。
言語がいろいろならターゲットもさまざまと、多様なバックグラウンドを持つ人たちが一同に会して現場について話し合うというのは、なかなか得難い機会だったと思います。
omoさんと8-p.infoの人と話せたのが収穫でした。 サインください! とか言ってた気がする。
id:maedanaさんとVimトークしてました。 東京でもVimの会したいね! とキャッキャしてた気がする。
話してくださったみなさん、ありがとうございました。
次回からは、具体的なレガシーシチュエーションに対してどう取り組むか、についてのお話になります。とっても楽しみですね。
February 17th, 2006 | Published in book
や、は、出版社の抵抗が強いらしくなかなか全開バリバリというわけにはいかないらしい。
そこで考えてみた。
たくさんのひとが、blogである本について書くとしよう。一般的なblogでは、気になったところを引用しつつ、そこについての自分の考えを書くというのスタイルになる。
ならば、その引用部分だけを抽出してつないでいくことができれば、一冊の本が自動的に再構築できるのではないか?
...
ためしに、読み終わったばかりのでできるかやってみた。
書き出し(C)は
情報技術(IT)が社会に及ぼす…
なので、
なんてことをやってみたけれど、やはりそう簡単にはいかない。序章すら再構築できなかった。
とはいえ、この本はいくらベストセラーといってもごく最近出たものなので、まだあまりwebに引用が載っていないということを差し引かないといけないだろう。 多くの人が引用するような興味深い古典だと、実現可能かもしれない。
February 12th, 2006 | Published in book
暗黙的な型変換に注意しようという話。
暗黙的な型変換には、3とおりの方法がある。
operator sometype() const みたいな型変換演算子しかし、暗黙的な型変換は予期せぬ振る舞いに発展する可能性があるので、できれば避けたほうがよい。あなたの意図したものと、コンパイラが解釈した結果は異なる場合があるからだ。
たとえば、ペットショップの犬を表すクラスを考える。 それぞれの犬にはIDが振られている。
class Dog {
public:
void bark();
operator int() const { return id_; }
private:
int id_;
char *name_;
};
いま、犬の名前を表示しようとして、うっかりDogクラスには operator char*()がないことを忘れているとすると、
Dog pochi;
std::cout << pochi << std::endl;
なんてやってしまう。結果は、pochiのIDが表示されるというもの。
経験を積んだC++プログラマは、たいてい型変換演算子を避ける。 たとえば、std::stringにはoperator char*()の代わりに c_str()が存在する。
こいつはよりたちがわるい。
ふつうにクラスを設計していても、こうしたコンストラクタを記述することはままある。そして、こうしたコンストラクタも、暗黙的な型変換に一役買ってしまうことがあり得る。
class Array {
public:
Array(int n); // n個の要素で初期化するコンストラクタ
};
Array a(10);
Array b(10);
for (int i=0; i<10; i++) {
if (a == b[i]) { // ここでミスしている !
...
}
}
なんて風に、a[i] == b[i]と書くべきだったところを書き間違えても、コンパイラは文脈から if (a == static_cast(b[i])) といったように解釈してしまう。意図が正確に反映されていないばかりか、見つけにくいバグになってしまっている。
explicitキーワードをコンストラクタにつける。このキーワードがついたコンストラクタは、暗黙的な型変換には使えなくなる。
もう一つ方法はあるけど、それはトリッキーになるので略 (ヒント: proxy class (see Item 30))。
暗黙的な型変換は、こちらがコーディングをミスったときに、コンパイラがプログラムをコンパイルできるように、都合良く解釈してしまうため、どこで間違いを犯したか分かりづらいことが問題。
既存の大規模プログラムに手を入れたり、バグを発見するような場合を考えると、こうした言語仕様は厄介だ。
自分の意図と異なる振る舞いをプログラムが見せることほど腹立たしいものはない。コードの字面の下で何が行われているかを、正確に把握していないと正しいコードが書けないような言語は人に優しくない。これで大規模なプロジェクトをまともに作ろうという方が無理だと思う。
自分の意図を自然に表現でき、そして書いたとおりのことがストレートにコンピュータに伝わり、実行されることが重要だろうと思う。
February 9th, 2006 | Published in book
デフォルトコンストラクタは大きなお世話な場合があるので、コンパイラに生成させないようにしようという話。
オブジェクトを生成する際に、なんらかの情報が必至であるようなクラスもある。この場合、デフォルトコンストラクタの存在が邪魔だったりする。しかし、デフォルトコンストラクタがないと面倒なことになる場合がある。
たとえば、
class Hoge {
public:
Hoge(int x) : x_(x) {}
private:
int x_;
};
なんてクラスを考える。
オブジェクトの配列を定義する際に、引数を与えることはできない。
Hoge hoges[3]; // NG
Hoge *hoges = new Hoge[3]; // NG
ではどうするか。
Hoge hoges[3] = { // OK
Hoge(0),
Hoge(10),
Hoge(20)
};
しかし、この方法も完全ではない。
Hoge *hoges = new Hoge[3];
の場合を扱えないから。
(Hoge hoges)[10]; // OK
(Hoge *)hoges = new (Hoge *)[10]
この方法にも問題がある。
deleteをかけないといけない2つ目の問題は、placement newを導入すれば解決できる (see Item 8)。しかし、placement newを用いるにも問題がある。
テンプレートを用いたコンテナクラスは、デフォルトコンストラクタを要求する場合が多い。std::vectorみたいに、慎重に設計されたクラスだと問題ないけど、すべてのクラスがそうだとはいえない。
class Hoge {
public:
Hoge(int x) : x_(x);
virtual void some_method();
};
class Fuga : public Hoge { public: Fuga(); // NG Fuga(int x) : Hoge(x) {} // OK void some_method(); };
ある仮想基底クラスから派生したクラスのコンストラクタは、親クラスがデフォルトコンストラクタを持たないことを知っておかないといけないという問題。
class Hoge {
public:
Hoge(int x = DEFAULT_VALUE) : x_(x);
private:
static const int DEFAULT_VALUE;
};
のように、引数にデフォルト値をセットするという方法もある。しかし、これだとちゃんと初期化できているか分からない。なので、このようにコンストラクタを定義しておき、引数が与えられなかった場合は、例外を投げたり強制終了させたりする向きもある。
以上のような問題にうんざりして、コンストラクタにデフォルトコンストラクタをつくってもらいたいと思うかもしれない。しかし、その場合は、メンバがちゃんと初期化されているかをチェックしないといけなくなる。チェックのためのコードが走る時間、コードサイズの増加といったコストを払わないといけない。
なので、初期化しなければいけないメンバをもつクラスで、コンストラクタに引数を与えないと行けないようなものの場合は、デフォルトコンストラクタを使うのは避けよう。そうすることによる弊害を受け入れるのは苦痛かもしれないけれども、ちゃんと初期化されており、無駄なチェックコードが走らないといった利点を享受できるわけだ。
だんだん言語仕様の複雑なところに入り込んできている。
デフォルトコンストラクタを生成させないようにすると、自然なコードが書けないようになる。やっぱりそんな言語はイヤだなぁと思う。
February 5th, 2006 | Published in book
基底クラスの配列を通して派生クラスを多態的に使ってはいけないという話。
基底クラスへのポインタを使って、派生クラスのメソッドを呼べるのが 多態性のうれしいところ。CやC++では、配列とポインタは兄弟みたいなもの。 int a[10]なんて配列があったら、*(a+0)は配列aの先頭の要素のことだ。
でも、
class Base {...};
class Derived : public Base {...};
なんてクラスたちがあったときに、基底クラスの配列を用いて
Base array[10];
for (int i=0; i<10; i++)
{
array[i] = new Derived(); // 派生クラスのオブジェクトをつっこむ
}
for (int i=0; i<10; i++)
{
array[i].someMethod();
}
とするのはまずい。 array[0]からarray[1]までのメモリ上の距離がsizeof(Base)に なってしまう。ちゃんとインクリメントできない。
同様の問題は、基底クラスの配列をdeleteするのにfor文で回すときにも起こる。 基底クラスのポインタを通して派生クラスの配列に対してを.delete[].した ときの動作は不定だというのが仕様。
こうした問題は、実装クラスから実装クラスを継承するといった習慣をやめれば 回避できる。(see Item. 33)
実装クラスから実装クラスを継承しないでいようと自分では思う。 しかし、他人が設計したクラスだと、なかなかそうもいかないので、 そういう部分を読む場合には、特別な注意が必要だと思う。
あるいは、基底クラスへのポインタの配列を使えばいいんじゃないかな。
April 20th, 2004 | Published in book
この前、青山のIDEEに行ったときに買った、仕事のやり方についての本。 ★★★☆☆。
amazonでは酷評されてたりもするけど、なかなか参考になる本だと思う。 少々インタビューしている人に対して肯定的に過ぎるきらいがあったり、カタカナ語が多かったりするけど、インタビューを通しての考察には納得したり共感できるところが多い。 生きていくにはどうせ仕事しなきゃいけないんだから、自分や他人が幸せに仕事できるようにしたいね、と。 僕も状況を良くしていかねば。