ある技術者の備忘録

最近巷では『最もタメになる「初心者用言語」は？』みたいな話で盛り上がってるようなんで、地味に参戦。元々はMatzさんの記事「初心者向けの言語」から火がついたようですが。

---

最初に書いておきますが僕のプログラミング言語に対する興味の遷移は、
MSX-BASIC → アセンブラ → N88-BASIC → C → VC++ → VB → Perl → PHP → Java
てな感じですんで、これら以外で評価できるとしたら大学の授業で習ったLispとかFORTRANくらいが関の山です。
そこんとこを前提にお願いします。

---

僕が思うに、これって実際のところは言語の技術や思想云々というより政治的な問題があるんじゃないかな？と思います。例えば（ちょっと言語とは違いますが）、日本でよく使われている圧縮形式でLZH形式ってありますよね？
これって圧縮のアルゴリズムが優れているから、日本でよく使われるようになったんでしょうか？
たぶん、アルゴリズムとかあまり関係なくて、ただ単に使い勝手のよいツールがあったからだとか、無料で手軽に使えたからだと思うんです。
そういう意味で、プログラミング言語に対しても、純粋な技術とは少し違った角度から考察してみます。

---

で、初心者のためになる言語たる条件は何か。これは次のようなものなのかなと思います。

• 始めるための敷居が低い（書籍等の資料や無料のツールが充実している）
• 将来に渡って役に立つ（違う言語でもノウハウが流用できる）

この条件に一致する言語ですが…敷居の低さならPHPですかね。なんといっても書いてすぐ実行できますし、言語を使う人口の裾野が広いので、初心者向けの簡単な資料は山ほど手に入ります。Windows上で無料で実行できますし。
将来使える知識を身につけるなら…C言語がいいと思います。JavaとはC#とかC言語に影響を受けた言語は多いですし、Cの知識を身につければ大抵の言語で流用できると思います（オブジェクト指向は別として）。
逆にLispとかHaskellとかは止めといたほうがいいような気がします。言語自体は素晴らしいと思いますが、それを使った仕事があるかどうか…。
もし、そういう言語を使った仕事がたくさんある環境にいる方なら、CとかPHPは止めてそっちをやったほうがいいと思いますけどね。

結局、自身の環境に依存するわけです。…なんか、面白くない結論になってしまいましたね。

かなり久しぶりの投稿になります。技術系ブログなのに、またまた社会系の記事になってしまってすいませんです。

POLAR BEAR BLOG さんの『「地球に優しい」でダマす6つのテクニック』という記事を読んで思うことがあって記事を書いてみました。

最近、関係ないのに「環境にやさしい」だとか、「エコ」だとかいう謳い文句の広告が目につきませんか？私が最近一番気になっているのは、某石油会社のガソリンのCMです。

このCMの中で「車を走らせながら環境に貢献できる」とか、「二酸化炭素を減らせる」ということが語られています。

これっておかしくないですか？

車を走らせるということはガソリンを使うということですし、結果的に環境を破壊することに繋がるはずです。それが、なぜ環境に貢献できるのでしょうか？環境に貢献できるって言葉自体が、よく考えたら意味がわからないですが・・・。環境破壊を防げるってことですかね？もしそうなら、なぜガソリンを使って環境破壊を防げるんでしょうか？？

それから「二酸化炭素を減らせる」ってのも意味がわからないです。たぶん「排出する二酸化炭素が、他のガソリンより少なくなる」ってことだと思いますが。言葉を端折りすぎて、違う意味になってないですかね？

私自身も、そんなに環境について考えているわけではありませんが、このようないい加減な宣伝は止めてほしいものです。 特に、そのCMには私が尊敬している人が出ているのでなおさらショックでした。

特にオチはありませんが、このへんで。

今回は傲慢SE日記さんの「JavaからRubyへ・・・」という記事に影響を受けて私の意見を書いてみたいと思います。あ、私はRuby未経験なので話半分で読んでください(^_^;

---

Ruby on Rails が出てきたころから色々な雑誌やブログで「Ruby（RoR）は生産性が高い」というような記事や、それから派生したと思われる「Lightweight Language は生産性が高い」という記事をよく見かけるようになりました。

けれど本当に生産性が高いんでしょうか？ 確かにRubyは優れた言語かもしれませんし、スキルの高いプログラマが書けば生産性も高くなくかもしれません。けれど、自動生成の恩恵は基本的な画面構成に限られますし、クロージャを使ってコードが短く書けるからといって生産性がそんなに高くなるんでしょうか？例えば（こういう呼び方は好きではないですが）１００人月の仕事を、数十人の派遣プログラマでやらなくてはならないときに、果たしてRoRのほうが生産性が高いのか疑問です。

と、ここまで読んでJava贔屓だと思われるかもしれませんが、確かにJavaよりLLの方が良い部分もあることは分かっているつもりです。プロトタイプを作りやすいとか、レンタルサーバではJavaよりPHPやPerlのほうがサポートしている会社が多いなどです。今後はRubyをサポートする会社も増えることでしょう。

---

ということで、私はRubyはPerlやPHPの代替にはなり得ますが、JavaやC#の代替にはなり得ないのではないかと考えています。

ただ、本当に重要なのは顧客や自身の要望をいかに早く、いかに正確に実現するかということだと思います。そういう意味では言語の生産性だけでなく、その言語が使えるプログラマを必要な人数だけ集めることができるか、保守コストが言語によってどれだけ変わるか、必要なパフォーマンスが出せるか、動作環境やライセンスはどうなっているか等、他にも考えることがたくさんあるはずです。一つの技術や言語にとらわれず、状況を考えて使う言語を選びたいものです。

バッドノウハウの危険性といっても、バッドノウハウが役に立つ／立たないとか、使うべき／使わないべきという話ではありませんので、あしからず。

---

何年か前のことですが、当時サラリーマンをしていた私の近くの席で働いていた新人が、スタイルシートで悩んでいるようでした。隣の社員が相談に乗っていたようなのですが、いつまでも解決できていないようなので思わずアドバイスしてしまいました。その時、そのアドバイスを聞いていた隣の社員に「それはバッドノウハウだな」というようなことを言われたんですが、ちょっと待て！と言いたくなりました。実際には説明が面倒なのでスルーしてしまいましたが（＾_＾；実際のところ、（私の考えでは）それはバッドノウハウではないのです。まぁ、私が教えた知識がバッドノウハウかどうかということは置いておいて、その隣の社員の態度が気になりました。バッドノウハウは知識や技術として邪道だと言いたそうだったんですが、他人からのアドバイスを詳しく考えることはせずに「バッドノウハウだ」と決め付けてしまうことが危険なように思うのです。

他人の知識や意見に接する機会があったときは、例え自分に必要ないと思ったときでも、一旦自分で噛み砕いて必要性や意味を理解したいものです。

・・・自戒の意味を込めて。

いつも読んでいるブログの「おさかなラボ」で、「禁断の快楽・変態キーバインドのお誘い」というのがありました。結構前に読んだ記事なんですが、最近キーバインドを考える機会があったんで思い出しました。

よくよく考えてみると、私はキーバインドを変えていません。いや、色々な人からキーバインドの変更を勧められるのですが、頑なにデフォルトにこだわっています。そういえば、マウスも色々なものが発売されているのに、家のマウスは普通のどこでもあるような２ボタン＋ホイールのマウスです。

で、それはなぜか考えてみました。

結論としては、「私の環境におけるソフトウェア開発の生産性を最大にするため」かな、と思います。皆さんは、逆だろうと思われるかもしれません。確かに、キーバインドを変更したほうが（慣れるまでの苦労は別として）生産性が上がるはずです。マウスも５ボタンとかにしたほうが生産性が上がるのかもしれません。５ボタンマウスは試したことがないんで分からないですが・・・。

では、私がなぜキーバインドを変えないか。それは、キーボードを使う場所（というか作業する場所）が一箇所ではないからです。私はしがないフリーランスエンジニアなんで、お客様の環境で作業したり、出向先の会社で作業したり、もちろん家でも作業します。

そりゃ、家に篭って開発できるのなら好きなキーバインドに変えますよ。しかも東プレのキーボードに５ボタンマウスを使いますよ。って、ただの愚痴になってしまいましたが(^_^;

---

そういえば、新米プログラマの中には特殊な環境に憧れる人も少なくないように思います。 emacsやないとエディタじゃないみたいな。これって、自分なりにアレンジしまくった環境で開発できれば凄いみたいなことなんですかね？確かにスゴいプログラマにはemacsとかマクロ組みまくってキーバインドも変更しまくってバリバリ使っておられる方も多いと思いますが、かといってそれらを上手に使えるから凄いってもんでもないように思うんです。きっと、スゴいプログラマはどんな開発環境でもスゴいんだと思います。それをスタイルだけ真似るのは間違いだと思うのは私だけでしょうか？

技術系のブログですが、酔った勢いで門外漢なのに政治の話題を書いてみます。

最近ニュースを見ていると、安倍首相の退陣の是非が話題の大部分を占めているようですね。前の参議選で自民党が大敗したことが原因なんでしょうが、私は違和感を覚えます。

国民が自民党に「NO」を突きつけた最大の原因は、 社会保険庁を代表する公務員や官僚の怠慢に対する不満が爆発したからだと私は思っています。確かに内閣人事も問題ですが、それは副次的な問題のように思います。

公務員や官僚をしっかり管理すべき政治家が、ちゃんと管理していないばかりか、ここまで増長させてしまった責任は長年与党であった自民党にあるということだと思います。そういう意味では総理大臣が問題なのではなく、族議員に代表される自民党のお偉方に問題があるんじゃないでしょうか？

なぜ、マスコミはこの部分より退陣の話題を取り上げるのかが不思議です。あまりニュースとしては面白くないからですかね？まぁ、どちらにしても役人の不正にメスが入るのであれば大歓迎ですが。

・・・そうそう、今回大勝した民主党ですが、支援団体の一つに例のアホな覚書を要求した「自治労」があるんですよねぇ(^_^;

環境も変わったことですし、新しいブログへ移行することにしました。今度は独自サーバです。暫く更新をサボっていましたが、これからは更新しますので宜しくお願いします。

それから今までの記事ですが、リファレンス的なものは移行していこうと思っています。・・・それにしてもアメブロはエクスポート機能がないんですね・・・

仕事でPHPとJavaを使うことが多いのですが、最近フレームワークに不満が出てきました。
昔は「Strutsを使っとけば大丈夫！」とか無責任に考えていたんですが、今はどれも短所ばかりが気になってしまいます(^^;

PHPは小さなプロジェクトが多いので、適当なフレームワークで（俺様フレームワークでも？）大丈夫なのですが、問題はJavaで作ることが多い、ある程度の規模があるプロジェクトのときです。
数ヵ月後に1～1.5人年程度の規模のプロジェクトを予定しているんですが、アーキテクチャを考え中です。
個人的にはJBossのSeamsやSeaserのChuraに期待しているんですが、どちらもこれからですしね…。

EJBを採用するほどの規模もないですが、かといってStrutsは先が見えてるような気がしています。
とりあえず、JSF(MyFaces) + Faceletes + Spring2.0 + Hibernate (+ Annotations + EntityManager)あたりで趣味に走ってみようかと考えています。

ところで皆さんは、どのようなフレームワークを使われているんでしょうか？

このブログには珍しく、技術関係ではない記事を書いてみます。

インターネットニュースを漁っていてショックを受けた記事がありました。
その記事とは、「中国で「ニセモノの塩」が氾濫 」というものです。
その記事によると、中国には化学工業原料の「亜硝酸塩」を食塩として販売している業者が存在するそうです。この「ニセ食塩」を長期間摂取すると中毒になるそうで、死亡者も出ているそうです。

以前にも同じような記事を見た記憶があったので調べてみたところ、以前のものは「人造卵 」（リンク先は中国語）でした。
私は中国語はさっぱりですが、どうやら中国では人工的に製造された人造卵が存在し、この人造卵を長期間摂取すると大脳にダメージを与えて痴呆症の原因になるようです。

これらのニュースを私たちは「対岸の火事」と思っていてはいけません。
厚生労働省のサイトにある国内における中国産冷凍ほうれんそう違反事例 に見られるように、粗悪な食品が日本に続々と輸入されてきています。
（現在はポジティブリスト制度で農産物に関しては改善されているようですが）

中国を敵視したくはないですが、このような事件があると考えてしまいますね…。

傲慢SE日記さんの「ドキュメントは必要？ 」という記事を見て、私も思うところを書いてみたいと思います。
本当はコメントに書こうと思ったのですが、長くなりそうなので記事にしてみました。

私が以前いた職場ではウォーターフォールで仕事をしていたのですが、たしかに設計者に書かれたドキュメントには抜けや間違いが多く、結局はドキュメンとソースが乖離したものになってしまいます。
ですので私も、傲慢SEさんのように「どうせドキュメントには不備があってソースが正しいのだから、ドキュメントはいらないのではないか」と考えていました。

ですが、初めてプロマネと設計を担当（人数が少ないのでプロマネと設計を兼務しました）し、私のこうした考えを一変させる経験をしました。

そのプロジェクトのメンバは6人で、殆どのメンバがスキルに自信を持ち、殆どのメンバがドキュメントの作成を苦手としていました。
そこで私はメンバと話し合い、アジャイル手法の一つであるXP でプロジェクトを進めることにしました。
これでドキュメントを書く工数や製作工数が削減できると考えたのです。

結果から言うと、これは大失敗でした。
XPの各プラクティスに対して、次のような問題が発生したのです。（ここに挙げている問題点は私たちの未熟さから発生したもので、XPの問題ではありません）

• ストーリーの不備による要求変更の増加
  プロジェクトの終盤にさしかかっても要求変更が相次ぎました。
  これは私が基本設計しているにもかかわらず、私が所属する会社が孫受けだったことが原因だと思います。このような立場では、顧客の常駐どころか対面も叶いません。
  プロジェクトの終わりのほうで知ることになるのですが、私たちが作成したドキュメントやプロトタイプは、プロジェクトの終盤になるまでエンドユーザに見せられていませんでした。定期的に元請のSIerに提出していたにもかかわらずです。
  この結果、プロジェクトの終盤になっても要求が変更され、その結果仕様変更が相次ぎました。
  また、ストーリーが明確でないため、メンバは最後まで仕様を理解しませんでした（理解しようともしませんでした）。
• 反復形開発による仕様変更の増大
  XPではドキュメントで顧客にコミットメントを取らないため、必ずといっていいほどプロトタイプを公開したときに仕様変更を要求されます。これは間違ったことではなく、本来、XPは「仕様変更を受け入れよう」という考えのもとに作られているのだと思います。
  ですが、このプロジェクトでは仕様変更するたびに、「なぜ俺が作ってから仕様変更が発生するんだ」とメンバから不満が続出しました。
• テスト駆動開発の形骸化
  最初はユニットテストをきっちり行っていたのですが、仕様変更がある度に徐々にテストケースと仕様が食い違うようになり、最終的には誰もテストケースを更新しなくなってしまいました。
  結局、メンバは（目先の）工数削減のためにテストを省略してしまったのです。
  その結果、品質は目に見えて低下していきました。
• YAGNIを取り違えたやっつけ仕事の増加
  YAGNIとは、「You Aren’t Going to Need It.（今必要なことだけ行う）」ことです。
  これは私は、「将来必要になるかどうか分からない機能を今作りこむのはやめよう」ということだと思っています。
  これをメンバは、「エラー処理も今は必要じゃないから作るのはやめよう」と考えたようです。このため、ソースコードには大量にTODOとかかれたままでエラー処理を考えられることなく作られていきました。
• ドキュメント工数の削減の失敗
  ドキュメント工数を削減できると考えていたのですが、結局納品物として、基本設計書、画面設計書、テスト成績書等、普段作っているものと同じだけのドキュメントが必要でした。
  それも検収の関係上から、プロジェクトの中盤で完成したドキュメントの提出を求められました。
  結局、「ドキュメントを書かなくてもよい」ということにはなりませんでした。

これらの問題点は、単純にプロジェクトがアジャイルプロセスに即していないだけだったかもしれませんし、私やメンバの力不足があったのは確かです。ですが、私はこれを機に仕事の進め方を考え直すこととなりました。
その後に読んだある本（題名は失念してしまいましたが、確かスティーブ・マコネルの本だったと思います）（Joel Spolsky の「ジョエル・オン・ソフトウエア」でした）に、ドキュメントについての重要性が書かれていました。
内容も詳しくは忘れてしまいましたが、その本に学ぶところがあり、私はウォーターフォールを適用すべきガイドラインと、ウォーターフォールを適用する場合 の注意点を次のように考えています。（これらのポイントは私の中でまだ未完成ですので、これからも変えて行きたいと思っています。）

ウォーターフォールを適用すべきガイドライン

• お客様にアジャイル手法を受け入れてもらえない場合
• 製作者が働いている会社が元請ではない場合（製作者が元請のオフィスに常駐している場合はOK）
• 製作者の技量が低く、また教育するだけの余裕がない場合
• アジャイル手法が理解できていないメンバが半数以上いる場合

ウォーターフォールを適用した場合の注意点

• フェーズごとにお客様に確実にコミットメントを取ること
• 期限だからといって、完成していないのに次のフェーズに移行しないこと
• ドキュメントを書く人はドキュメントを書くスキルを持っていること
• ドキュメントの保守に専任の担当者をつけること

リストの中でも太字にしましたが、ウォーターフォールの中での問題点の一つは、「ドキュメントを書くスキル」の必要性が見過ごされていることだと思いま す。ドキュメントを書いた人はドキュメントの読者が理解できない場合、往々にして「読む人の頭が悪い」のが原因だと考えてしまいがちです。ですが本当にそ うでしょうか？私は、ドキュメントの書き手が悪い場合のほうが多いと思っています。
ちなみに、ウォーターフォールを適用した場合の注意点は、先述の本と「アジャイルソフトウェア開発の奥義」に学ぶところが大きいです。

最後に、私が傲慢SEさんと同じような状況に置かれたときにとった行動は、「ドキュメントを読んで理解できない点や矛盾点をリストアップして送りつける」というものでした。
設計者のプライドを傷つけないよう、文句をつけるというより、単純に分からないとか論理的に矛盾しているというスタンスをとるように気をつけました。
そのリストで相手が非を認めた項目については、早急にドキュメントを修正してもらうようにしました。
この方法が正しいかどうかは分かりませんが、ウォーターフォールの下流工程を担当する上での一つの対策だと思っています。