『ひなた先生が教えるデバッグが256倍速くなるテクニック』を読みました。

ひなた先生が教えるデバッグが256倍速くなるテクニック』を読みました。

この本は先輩プログラマと特別講師が新人プログラマにデバッグの技術を教える話で、初級者から中級車のプログラマが読者の対象になります。
「__LINE__」マクロでソース行を埋め込んだり、コールスタックを調べて関数の呼び出しもとを判定したりするなど、C言語の入門書には書かれていない方法が学べました。
このような方法を知らない方は少なくないのではないでしょうか。

デバッグの技術よりも、バグのないプログラミングの方法についての考察が面白くて参考になりました。
たとえば、「W(x,y-1)+W(x,y+1)+W(x-1,y)+W(x+1,y)」という列挙順はよくないなど。

変数の命名規則についての考察はとても興味深い話でした。

  • 1990年中頃の命名規則は、Windows3.0のSDKは各種ハンドルが同じ型だったため、変数名に型をつけるハンガリアン記法が有効でした。
  • 2000年頃の命名規則は、変数名でメンバ変数であることがわかるように「m_」ではじめたり、アンダーバーを最後につけたりしました。
  • 2005年頃になると、インテリセンスを使うようになり、メンバ変数にアンダーバーをつけなくなります。

開発言語や開発環境・コンパイラなど、さまざまな環境によって、最良の命名規則は異なります。
新しいプログラミング言語やOS・開発環境を使うときは、それまで使っていた方法に固執しないように気を付けたいと思います。

ゾーンを避けろ。ゾーンの集中状態は生産性が高いわけではない。

「フロー」や「ゾーン」というと、意識が集中していて生産性が高い状態、のような印象がある。
誰もがゾーンの状態に入りたいと願っているのではないだろうか。

ところが『Clean Coder プロフェッショナルプログラマへの道』では、「ゾーンを避けろ」とアドバイスしていて興味深い。

ゾーンの集中状態は理論的な能力やスピード感覚が落ちている軽いめい想状態で、ゾーンに入ることの問題は大局観を失うことだ著者は言う。

コードを書くのは速くなるかもしれないが、あとでやり直さなければならなくなる。

著者はゾーンに入ったと感じたら、メールの返信やツイートの閲覧、昼食をとったりして、ゾーンから遠ざかるようにしているそうだ。

Clean Coder プロフェッショナルプログラマへの道』では、次のようなアドバイスもしている。

  • 披露時や注意散漫のときには、コードを書いてはいけない。
  • 心配事があるときは、コードを無理矢理書くよりも、心配事を沈めることに時間を使った方がいい。

プログラミングとは大変な作業である。

『哲学者クロサキのMS-DOSは思考の道具だ』

哲学者クロサキのMS-DOSは思考の道具だ』は、月刊アスキーに1991年8月から1992年8月まで掲載された連載記事を一冊の本にまとめたものです。
20年前の本ですが、参考になる部分がたくさんありましたので紹介します。

この本は、2つの側面があります。

1つはMS-DOSについての入門書的な側面です。
MS-DOSの知識は、今となってはあまり役に立たないかもしれません。

もう一つの側面は、コンピュータがもたらす個人や社会への影響を考察する側面です。
この点では、20年前の本ですが参考になりました。

考えるヒントになったところを抜粋します。

■第3章 思考は<流れ>なのか?

論文の作成方法が、原稿用紙からワープロに変わり、思考と表現の関係が直線的思考法から変化した。
自分にとって本来的なものを、事柄そのものにとって本来的なものと考えてしまっていないだろうか?
人はその時代時代の技術や文化に制約されている歴史的存在である。

古い考え方や昔の成功体験にしがみつかず、あたらしい道具に挑戦することを忘れないようにしたいと思います。

■第4章 物質性を持たない電子文字

プリントアウトしたくなる欲求について。
電子文字は発想や思考と同型の流動性を有している。
プリントアウトすることで思考を固定化して、他者の視点から見ることができる。
※関連:イギリス経験論のロック、ドイツ観念論のヘーゲル、フルボルト

ペーパーレス化を考える時は、プリントアウトの利点も忘れないように。

■第6章 ハードディスク階層構造の構築

あらゆるトラブルを解決するスーパーマニュアルは可能か。

答え:不可能。慣れるしかない。
※フレーム問題

■第8章 CD-ROMは印刷文化を変えるか

これは、ちょうど計算記述源以前に、円周率を一生かかって何千桁も計算した学者に似ています。コンピュータ時代にあっては、残念というか、悲しいというか、彼の一章の努力は、せいぜいパソコンの数十秒でしかなかったのでした。

現代でも、コンピュータに任せたらすぐにできることを、人が時間をかけて行っている場面があります。

■第9章 CD-ROMタンデム走行を目指す

書籍の値段は、本制作費と発行部数の兼ね合いで決められる。
内容の濃さやレベルに応じて、値段が設定されているのではない。
印刷本から電子文字化が進む今後、その価格をめぐって大混乱の起こることが予想される。

日本で電子書籍がなかなか始まらない理由を、ずばり指摘しているように思います。

■第12章 文字表現のカラオケ化

カラオケがプロの伴奏で歌うという行為を大衆に開放したように、パソコン通信がものを書くという行為を大衆に解放した。
人々は、自分について、自分の思いについていっせいに大声で語り始めた。

まるでSNSやツイッターのことを言っているようです。
もちろん20年前には、SNSもツイッターもありませんでした。

プロジェクト管理ツール導入の最初の一冊に。『Trac入門 ソフトウェア開発・プロジェクト管理活用ガイド』

Trac入門 ソフトウェア開発・プロジェクト管理活用ガイド』を読みました。
プロジェクト管理ツールの入門書です。

この本の特に良かった点は、プロジェクト管理ツールを導入することでどのような問題が解決できるのか、どのような点に注意して導入したらいいのか、といったことがわかりやすく説明しているです。
プロジェクト管理ツールの全体像をつかむことができます。

図解・挿絵・漫画・画面キャプチャをたくさん使っているので、読みやすく理解しやすくなっています。

入門書として、とても良くできていると思います。
本書を読むことで、Tracを導入するイメージがつかめるでしょう。

プロジェクト管理ツールを導入する最初の一冊に最適です。

『メイド喫茶でわかる労働基準法』

メイド喫茶でわかる労働基準法』は、予想以上にいい本でした。

ターゲットを若者に絞り込んで、かわいい女の子の表紙やコミカルな物語で、とっつきにくそうな法律の入門書のハードルを低くして、しかし、ちゃんと学ぶことができるところが良かったと思います。
読みやすい本ですので、学生の方はアルバイトや就職の前に一度目を通して、労働者の権利を知っておくといいと思います。

メイド喫茶でわかる労働基準法』の各章は、前半が物語、後半が解説になっています。
物語部分では、主人公が法律の神(猫)の協力を得て、自分や友人の労働問題に取り組みます。
解説部分では、物語部分で起こった労働問題をまじめに解説します。

解説部分だけだと、なかなか読む気にはならないかもしれません。
物語があるおかげで、問題をイメージしやすくなり、学びやすくなっています。

若者に労働基準法を知ってもらうために、制作側が知恵を絞って工夫を凝らして、このような形になったのだと思います。
いい取り組みだと思いました。

コンピュータが仕事を奪う

中流ホワイトカラー職が減少していく時代に良い職を得るには」という記事がはてなブックマークで人気を集めていたようです。
この記事に関心を持った人に『コンピュータが仕事を奪う』をお勧めします。

コンピュータが仕事を奪う』によると、ホワイトカラーの仕事は上下に分断されていきます。

  • 人間であれば多くの人ができるがコンピュータにとっては難しい仕事
  • コンピュータではどうしても実現できず、人間の中でも一握りの人々しか行えない文脈理解・状況判断・モデルの構築・コミュニケーション能力等を駆使することで達成できる仕事

上の記事で言うところの「良い職」とは、「人間の中でも一握りの人々しか行えない文脈理解・状況判断・モデルの構築・コミュニケーション能力等を駆使することで達成できる仕事」になります。
コンピュータに置き換えできない仕事なら何でもいいというわけではありません。
「人間であれば多くの人ができるがコンピュータにとっては難しい仕事」では、十分な給料は得られません。

これからのホワイトカラーに残される最も意味のある仕事は、何でしょうか。
それは、「コンピュータにはできない抽象化作業をし、その結果生じる低レベルの知的作業をコンピュータに代替させる方策を考えること」です。
元の記事では「これはコンピュータシステムで置き換え可能か?業務フローの改善によって不必要になりうる仕事か?アウトソース可能な仕事か?」という問いかけをしていました。
「これはホワイトカラーに意味のある仕事か?」という問いでしょう。

コンピュータが仕事を奪う』では、日本のソフトウェア開発の効率が他国に比べて低い理由とか、コンピュータが得意そうに見えて苦手な仕事とか、ビックデータの鉱山から鉱脈を掘り出すには数学かコンピュータの知識が必要だとか、他にもおもしろい話題がたくさんあります。

これからのホワイトカラーの仕事について関心があるなら、『コンピュータが仕事を奪う』を読んでみてください。
きっと得るものがたくさんあると思います。

新井さんの本は以前にも紹介しています。どの本もおもしろいですよ。

『基礎からわかるMDA (モデル駆動型アーキテクチャ) なぜモデリングするのか?』

■『基礎からわかるMDA (モデル駆動型アーキテクチャ) なぜモデリングするのか?

MDAの目的は、「開発資産の経年劣化の予防」です。

プログラム言語の寿命は短い。フレームワークの寿命はもっと短い。
システム設計を実装技術に依存してしまうと、設計の寿命まで短くなってしまいます。

コンパイラのおかげで、C言語で書かれたプログラムがあたらしいプラットフォームでも動作するので、プログラムを長く使用することができます。

MDAも同じです。
プラットフォームに依存しないことで、実装技術が変化しても開発資産の経年劣化を最小限に抑えます。
データベースの設計を概念設計・論理設計・物理設計に分けることと、よく似ていると思いました。

MDAというと「ソースコードの自動生成」の話題が取り上げられやすいですが、MDAの本質はそこではありません。
本書を読んで、MDAの目的・考え方がよくわかりました。

MDAを短期間で評価することはできないと思いました。
システムをいくつかのプラットフォームに移植して、長い間システムを使い続けて、それでようやくMDAの価値を実感できるのではないでしょうか。

本書の最後の章「第6章 MDAの将来」では、Steve Cook氏のMDA批判の論点と、Mechael Guttman氏の反論が紹介されています。
MDAび長所ばかりでなく、短所・欠点・課題について知ることができ、より広い視点を持つことができるところも良いです。

本書は、MDAに興味関心のある技術者が、MDAの基礎・概要を知るのにおすすめの本です。

■参考

リソースの断面管理

独習データベース設計』を読んで勉強中です。

「リソースの断面管理」
といって何かわかりますか?

私はわかりませんでしたが、テーブルの設計を見ると一目瞭然です。

ある基準日を境にインスタンスを変更する時、断面管理が必要になります。

たとえば商品テーブルがあったとして、

商品コード
商品価格

商品価格の変更ある場合は、主キーに「適用年月日」を追加しして次のようにします。

商品コード
適用年月日
商品価格

商品価格が2011年4月1日から変わる場合は、テーブルのデータは次のような感じになります。

商品コード 適用年月日 商品価格
A001 2010/4/1 800
A001 2011/4/1 1000

データベース設計のデザインパターン本が欲しいです。

■2011年10月4日 追記

もう少し複雑なパターンを教えていただきました。
http://ameblo.jp/hatsanhat/entry-10981349243.html

名前付けの重要性

独習データベース設計』を読んで勉強中です。

独習データベース設計』の第8章は「ネーミング標準」。
名前付けに1つの章を割いて説明しています。
名前づけの重要性を再確認しました。

一口に「顧客」といっても人によって意味が違ってきます。
製造の人は仕入れ先を、営業の人は取引先を顧客と呼んでいるかもしれません。
適切な名前を付けることは、しっかりしたデータベース設計には重要なことです。

ユニークな名前を付けることで、プログラムの変更する時の影響範囲を測定することも容易になります。

データベース設計では、概念モデルのキーはできるだけナチュラルキーを使う。

独習データベース設計』を読んで勉強中です。

データベース設計では、概念モデルのキーはできるだけナチュラルキーを使う。
概念モデルでは人工キーを設定しない。

ナチュラルキーの例

予約

顧客番号
予約年月日時刻

人工キーの例

予約

予約ID(意味なし連番)
予約番号

概念モデルから人工キーを使うと、本来何を持って一意に定まるのかがわからなくなってしまう。
概念設計段階では、意味的に分かりやすいナチュラルキーを使用する。

なお、実装する時は必要に応じてサロゲートキーを使う。

他人のブログを見ていると、概念設計や論理設計と物理設計を区別せずに、ナチュラルキーとサロゲートキーを論じているものがあるので注意が必要すること。