企業内「学校」への期待

ものすごく盛り上がっているみたいですね。

プログラマで、生きている: ググるな危険

はてなブックマーク - プログラマで、生きている: ググるな危険

ブログのコメント欄や、ブックマーク・コメントの反応を読んでいて印象的に思ったのが、日本の企業内教育に対する、若い人たち（？）の期待、あるいは要求の高さでして。職業教育というのは、企業内で行なうもの、という意識は根強いといいますか、むしろ近年、企業内教育に対する要求水準が、より高まっているような感すら受けます。

企業内で職業教育を行ない、人材の育成をはかる、というのは、いわゆる「日本型」の雇用システムの特徴のひとつであるそうで。企業が人材の教育コストを多く負担するがゆえ、新卒一括採用、長期勤続の奨励、といった慣行が存在する、という面があるわけです。

新卒一括採用というのは、多くの人間を同時期に大量採用し、まとめて新入社員教育をおこなうことで、一人あたりの教育費負担を下げられる、という面があります。大手企業であれば、 1 社で大量の人員を採用しますので、スケール・メリットは大きいでしょう。また、中小企業でも、同時期に産業界全体が新人研修をやっているわけですから、親会社・協力会社・取引先の研修に、自社の新入社員を参加させてもらう、あるいは、他社と共同で実施する、といったことができます。

長期勤続の奨励、というのは、せっかく教育コストをかけて育成した以上、せめて投資が回収できる程度 − 5〜10年くらい − は勤続していただきたい、ということでしょう。

結局のところ、日本の雇用流動性の低さ、というのは、こうした労使双方の思惑の上に成り立っている面があるわけでして。一部でいわれているような、「解雇規制」とやらを緩和すれば流動化する、とかいうような単純なものでもないのでしょうね。

参考：

一度しか来ない列車: EU 労働法政策雑記帳

本の読み方を知らない新人さん

新人：「パラメータはコンフィグファイルに記述って仕様に書いてありました」

わたし：「それがどうしてレジストリにつながるの？」

新人：「コンフィグファイルを検索してたらレジストリというのが出てきて、それを理解できないとコンフィグファイルの操作方法が分からないのかと思って...」

プログラマで、生きている: ググるな危険

この話に出てくる「コンフィグファイル」というのは、 おそらく、 .NET Framework での 拡張子 .config のファイルのことなのだろうと推測します。 Windows アプリケーションの場合は app.config 、 Web アプリケーションの場合は web.config というファイルを使うことになっています。 Microsoft の用語では、 「構成ファイル」 になっていますね。

.NET Framework の構成ファイル スキーマ ( MSDN )

.NET には、バインディングと呼ばれる仕組みがありまして、 Visual Studio のデザイナでフォーム上に配置したコントロールのプロパティと、構成ファイルの XML 要素をマッピングしておくと、自動的にプロパティを読み書きしてくれる、という機能があるんですよね。 これは、フォームのコントロールに限らず、任意のオブジェクトのプロパティで使えます。

上の話は、新人さんに、 .NET の入門書と仕様書を渡して、作業を指示した、という話なのではないですかね。入門書には、 app.config 、 web.config の説明ぐらいはあったのではないかと思うのです。つまり、この新人さんは、読むようにと渡された、入門書を読んでいない、ということになりますね。渡された本を読まずに Google で検索していると。¹

入門書が読めない人に、プログラミングの仕事を教える、というのは、かなり厳しいと言わざるをえないですねえ。 Google がどうとか、受身だとか、そういうレベルじゃないと思います。 OJT で読書のやり方から教えるというのは、不可能でしょう。

学生時代、 1 冊も本を読まずに済ませてきたのだとすると、それはそれですごいですね。

---

1. .NET について調べるなら、 Google じゃなくて、 MSDN でしょうね。入門書を読めないレベルですと、 MSDN の資料を読むのは無理でしょうけど。

Divide by zero error

間違い探しの問題ですね。

１＝２？ - 諏訪耕平の研究メモ

「２と１は等しい」　数学界で論議

数学の誤った推論を集めて、分析した書籍というのがありまして：

き弁的推論 ブラジス ほか著 ; 筒井孝胤, 千田健吾訳 -- 東京図書, 1965.9

以前に、 arton さんが紹介していた、 ソビエト連邦の一般向き数学書と、同じシリーズみたいです。

曰く、

ロシア・ソビエト連邦社会主義共和国文部省の指導書 <<第5学年から第10学年における数学教授法について>> （1952年, 41 ページ） には, <<あらゆるき弁は生徒の論証能力を発展させるための補助手段としてきわめて有効である>> ということが述べられている.

ちなみに、代数の章の一番最初の例題は：

(1) 1 / 4 円 = 25 銭 である。

(2) 両辺の平方根をとって、 1 / 2 円 = 5 銭 。

よって、 1 円の半分は 5 銭である。

というものです。

推論の誤りを見抜く能力というのは、プログラミングでのデバッグの能力に関係ありそうですね。

誤りを調べるときには, 無条件に, 完全にすべてをはっきりさせなければならないことをつけ加えておこう. すなわち, 推論の中で見すごされた誤りはどこにあるか, またその誤りをどのように訂正したらよいかということを, 生徒たちははっきり把握しておかなければならない.

昔、新人さんの書いたプログラムを、当の新人さんと一緒にデバッグしていて、

「何でそんなに疑い深いのですか？」

といわれたことを思い出しました。 いや、何でといわれてもねえ。

SQL クエリのスタイル、もしくは、 なぜ SQL クエリは読みにくいのか

しばらくの間、 SQL で書かれた、様々な集計クエリを読んでいたのですが。どうも、クエリが読みにくくていけない、と思いまして、いまさらながらですが、 SQL クエリの書き方について考えました。

SQL クエリの読みにくさの原因というのは、いくつかあるのですが、一番大きいのは、 FROM 句と、 WHERE 句が離れてしまうことにあると思います。クエリを作るときには、テーブル／リレーションごとに条件を考えて、クエリを組み立てていくと思います。これを、 昔ながらのスタイルで SQL に書くと、 FROM 句にリレーションが並び、 WHERE 句にリレーションの条件が並ぶ、という、リレーションと条件とが分離した形になります。

クエリの読み手がクエリを読む際には、 クエリを作るときの手順を逆に行なうことになります。 WHERE 句に並んでいる条件が、 FROM 句のどのリレーションにかかっているのか、 FROM 句のリレーションごとに、 WHERE 句の条件を並べなおして、クエリからどのような結果が出力されるかを読み取ろうとするわけです。

このようなクエリは、例えば、以下のようなものになります ¹ 。

select
  a.A_ID,
  trim(a.A_LNAME) || ',' ||
    trim(a.A_MNAME) || ',' ||
    trim(a.A_FNAME) as a_name,
  ol.OL_QTY
from
  CUSTOMER c,
  ADDRESS ad,
  COUNTRY co,
  ORDERS o,
  ORDER_LINE ol,
  ITEM i,
  AUTHOR a
where
  ad.ADDR_ID = c.C_ADDR_ID and
  co.CO_ID = ad.ADDR_CO_ID and
  co.CO_NAME = 'Japan' and
  o.O_C_ID = c.C_ID and
  o.O_STATUS = 'SHIPPED' and
  ol.OL_O_ID = o.O_ID and
  i.I_ID = ol.OL_I_ID and
  i.I_PUB_DATE >= date '2007-08-01' and
  i.I_PUB_DATE < date '2009-09-01' and
  a.A_ID = i.I_A_ID and
  c.C_DISCOUNT >= 0.1
order by A_ID

このように、いちいち、 WHERE 句と、 FROM 句を頭の中で照合するのは、リレーションの数、条件の数が増えてきますと、やっておれなくなってきます。このため、別途、メモを作成して、リレーションごとに条件をまとめてみたりするわけですが、 無用な手間、という感じなんですよね。

そこで、私がこうしたクエリを書くときにやるのが、 WHERE 句にある条件を、すべて JOIN 句に書く、というやり方です。 さらに、 FROM 句の一番目のテーブルの条件だけは、 WHERE 句に残ってしまうため、あえて、サブクエリにします。

こうしますと、条件がリレーションごとにまとまりますので、かなり読みやすくなるのではないかと思います。

select
  a.A_ID,
  trim(a.A_LNAME) || ',' ||
    trim(a.A_MNAME) || ',' ||
    trim(a.A_FNAME) as a_name,
  ol.OL_QTY
from (
  select C_ID, C_ADDR_ID
  from CUSTOMER
  where C_DISCOUNT >= 0.1) c
inner join ADDRESS ad on
  ad.ADDR_ID = c.C_ADDR_ID
inner join COUNTRY co on
  co.CO_ID = ad.ADDR_CO_ID and
  co.CO_NAME = 'Japan'
inner join ORDERS o on
  o.O_C_ID = c.C_ID and
  o.O_STATUS = 'SHIPPED'
inner join ORDER_LINE ol on
  ol.OL_O_ID = o.O_ID
inner join ITEM i on
  i.I_ID = ol.OL_I_ID and
  i.I_PUB_DATE >= date '2007-08-01' and
  i.I_PUB_DATE < date '2009-09-01'
inner join AUTHOR a on
  a.A_ID = i.I_A_ID
order by A_ID

というわけで、 私は、 WHERE 句ではなく、 JOIN 句に条件を書く、というスタイルを推奨してみたいわけです。

---

1. データベース・スキーマは、 OSDL DBT-1 より。

計算機プログラムの詳細仕様書とは

どのようなものか知りたい人は、 自分の PC に、 TeX システム一式をインストールしてから、 tex.web に対して、以下のコマンドを実行すると良いと思います。

>weave tex.web
>tex tex.tex

これで、 tex.dvi というファイルが出来ます。 Donald Knuth 氏 による、tex プログラムの詳細仕様書です。