2006年12月

2006年12月26日

感謝

 新人プログラマーは、
 当然ながら給与が少ない。

 未経験者は一年目は新卒と同じ給与。

 にもかかわらず、勉強と称して書籍を買い漁った私を支えてくれた家族に感謝である。

 そんな気持ちも込めて、
 今夜は少し贅沢。

 奮発してちょっと高めの中華料理を食べに行きました。
 経済的に余裕があるわけではないけど、
 20代も後半にして、転職に踏み切った馬鹿な父と、
 目が開いている限り遊びつくす小さなダイナモな1歳児を抱え込んだ我妻に感謝の気持ちをたまには現さないとバチがあたろうというもの。

 北京ダックに、フカヒレ、アワビ。
 値段だけあって美味しかったです。

 来年は何をしてあげられるだろうか?

2006年12月21日

本の紹介「ソースコードの反逆」

 Linuxが生まれた経緯とを中心として、
 数々のオープンソース開発の話について書かれた本がこの「ソースコードの反逆」である。

 そこには本物のハッカー(多分)と呼ばれる人たちの姿が描かれている。

 ネット上にて、時折ハッカーを目指している人を目にするが、
 結局、ハッカーだクラッカーだという定義合戦に陥るばかりで、彼らがなぜなりたいのか、どうなりたいのかがわからないまま、首をひねることが常の傍観者だったが、

 なるほど、ハッカーに憧れる気持ちもわかる。

 と本書を読んで頷くことができた、
 同時に、彼我の距離も痛いほどわかった。生き方の違いも。

 自分もただ、プログラマーという言葉に憧れて、プログラマーになってしまった人間だから、ハッカーという言葉に憧れる気持ちもわからないでもない。
 自分の場合は、なる前に描いていたプログラマーと、なってみたプログラマーの世界はかなり乖離していた。

 ハッカーになりたい人の言動にも、本書の中のハッカーとは違うものを感じる。それが正しいのかはわからないが、ハッカーになりたい人、ハッカーを知りたい人はこの本を読んでみると何か得るものがあるかもしれない。

 ハッカーについてばかり書いたが、
 Linuxができあがるまで、LinuxとunixそしてGNUの関係。

 Webでシステム開発をする場合にはよくお世話になる、
 sendmailや、samba、そしてPerlなどの開発の逸話も載っており、昔語りの読み物としても面白い。

 個人的にはminixというOSに興味が湧いた。

 本書を読まれた後に、
 Eric S. Raymondの「伽藍とバザール」を読んでみると、尚面白い。

 今なら、Amazonの中古本で400円ぐらいという価格というのもオイシイ。自分は図書館で借りましたが、読んだ後にすぐAmazonで購入しました(中古本)。
 手元においてじっくり読みたい一冊です。
ソースコードの反逆―Linux開発の軌跡とオープンソース革命


2006年12月18日

補足、switch文が無くなるとは?

 オブジェクト指向はプログラムから複雑さを取り去ってくれたり、
 モジュールを少ないインターフェイスだけの弱い結合にしてくれます。

 Webアプリケーションで典型的な、
 コントローラーの形として、

//**********************************************************

 if (文章の投稿なら) {

// 文章を投稿するための処理

 else if (文章の削除なら) {

   // 文章を削除するための処理
 } else {

// 更新するための処理

 }
 共通の処理・・・。
 if ・・・// また条件によって分岐したり

****************************************************//

 というコードを書いたことがあると思います。
 ifの変わりにswicth文にしても同じです。

 私は一度に多くのことを処理するととたんに処理能力が低下するありふれた人間でしたので、このif文やswitch文の構造が嫌いでした。
 この状態による分岐はオブジェクト指向を学ぶことにより、よりスッキリした形になります。
 隠蔽という概念も用いて書くと、実に状態による条件分岐を亡くすことができます。

 簡単にコードを書くと、

//*******************************************************

 $Factory = new Factory();

$State = $Factory->createState(状態);

 $State->setData(処理に必要なデータ); // 必要なデータをセット

 $State->execute(); // 実行

 $State->show(); // 表示

********************************************************//

 こんな感じになります。
 2行目の状態に、投稿や削除、更新を表すフラッグを渡し、次にその処理に必要なデータをセットして、処理を実行、そして表示というシンプルな構造だけを表面に残すことができました。

 $Factory->createStateで$Stateには投稿や、更新の処理を行う各処理が書かれています。それらが同じメソッドで統一して呼び出せること、そしてそれらが一つのソース上に存在しないことはプログラムを読みやすくします。例えば削除ならstateDeleteクラスだけを読めば良いので、これは更新、これは削除、これは投稿とifやswitchの海を掻き分けて泳ぐ必要が無くなります。

 これはオブジェクト指向の中でも私が好きな用法の一つです。

 そんな抽象的なコードでわかるかい!!
 というかたは、デザインパターンやFactoryパターン、Stateパターンなどで検索してください。
 わかりにくいのを覚悟でクラス名をパターンだとわかりやすいようにしました。

 上のようなStateのパターンに近い実装を手続指向の記述でもできる、と感じた人もいると思います。私もできないことはないかなぁと思ったりしますが、大事なのはオブジェクト指向は、上のような書き方の利点や、自然とそういう書き方になるような価値観を伝えてくれるのです。大事なのはパターンを覚えることではなく、パターンの土台となる考え方であり、オブジェクト指向は自然と教えてくれます。

 いや、私も、そんなに理解しているわけでも、使いこなしているわけでも無いのですけど・・・。

2006年12月17日

久しぶりにゲーム機欲しくなった

 PCではしばらく三国志11をしていたのですが、
 それ以外ではゲームしなくなりました。
 大人になったからではなく、それ以外に楽しいことができたからなのです。公私ともにプログラマーなシーラカンスです。

 それでもWeb上で流れる家庭用ゲーム機の情報は興味深く眺めていたのですが、

 http://blogpal.seesaa.net/article/29700170.html

 を読んで、
 丁度ゲーム真っ盛りだった頃のPSの驚きが蘇ってきました。

 あの頃は、SONYの躍進でしたが、
 今のSONYは色々問題を抱えているようですねぇ。
 いや、随分前からなのか・・・。

 とりあえず、グランツーリスモだけは
 PS3でがんばってすばらしい作品を出してくださいなSONYさん。

本の紹介:「Web2.0が殺すもの」

 この本、さっとWebサイトの紹介を眺めた限り中々好評のようです。

 それらサイトがいうとおり、「Web2.0賛歌に一石を投じる」という点では意味のある一冊(最初の一冊として)であり、現状のWebサービスが抱えている問題を知るには良い本だと思います。

 最近のWebコンテンツへの問題提起、
 Web2.0という用語の使われ方や、提唱者への批判、
 そしてGoogle、Google礼賛姿勢への批判、

 これらが入り混じっている上に、著者のバイアスがあるという構成は最悪です。
 Google批判なら、mixiの問題点を書く必要は無いという具合。

 そもそも、Web2.0という言葉に明確な定義をせず(全ての立場を踏まえた定義なんかないのだろうけど)、Web2.0的なものの抱える問題を書きつつ、Googleへの批判を行うというのはどうだろうか?

 全体としての問題は以上のようなことだと思います。

 もう一つの問題である著者のバイアス云々に関しては、上記前置きを読んでもらうことにして、
 この本を読む場合はこれまで書いたようなことを頭の片隅に置いて読んで見てください。必要なものと、不要なものを振り分ける役に立つかなぁと思います。

 

本の紹介:「Web2.0が殺すもの」の感想の前に前置き

 結論からいうと、
 立場が違えば見えるものも違うのかもしれない、という漠然とした終着。

 Web2.0批判というより、
 主にGoogleや、「Web進化論」への批判、話題のサービスへの批判的な本ということなのだろうか。
 最近のWebサービスが抱えている問題の紹介とするならあまりインターネットを利用しないような人には得るものがあるかもしれないけど、それについての著者の感想がバイアスかかりすぎて問題アリ。

 バイアスという点を忌憚無く話すとすると、
 私はGoogleのサービスの発想に関心するし、社内のプログラマーへの待遇や仕組みには羨ましい思いもするけど、擁護する気は無い。
 無いけれど、本文中に書かれているアジャイルな開発には共感するし、アジャイルの手法がケースバイケースであるという程度は理解している人間であり、著者の言及に「良く知らないんじゃないの?」という感想と、「知らないことでもさぞ知っているように話す人なんだ」と不快と警戒を抱いた。これはすくなからず負のバイアスとして本書への感想に働いているはずなので、それを承知の上で聞いていただけるとありがたい。

 アジャイル(俊敏)なプロセスについて彼が言及していることを要約すると、

 インターネットの世界は発展途上で、ビジネス環境がめまぐるしくかわるから仕様変更を余儀なくされるのは日常茶飯事

 アジャイルに関連して話であるなら、仕様変更の理由は、顧客自体も自分の要求を最初の時点で十分に理解していないからです。
 実際に動くものを見て、ないしは開発途中の会議の中で改善案を思いつくことが多いからです。これはインターネットに限らずシステム開発全体についての話なのですが、なぜかネット限定のように語られてしまっています。

 上記状況に応じて、動くものを優先させようという姿勢が登場

 概ね間違っていませんが、先の説明が微妙なので素直に頷けません。

 開発姿勢や概念、思想などに色んな「名称」が付くのがWeb2.0の特徴

 えっ? アジャイルな開発手法の話の中でいきなりWeb2.0が出てくるんですか。アジャイルな開発はWeb2.0と関係ありませんし、何にでも概念に名前をつけるというのは、どんな分野でもそうだと思いますけど。

 何せ、プログラマーは神ですから名前を増やすことぐらい造作も無いことです

 プログラマーですけど、初耳です。
 本書の後半でGoogleは神だから、というような表現も出てきます。自分の気に入らない勝手な行為をする対象を神と揶揄しているのでは? とかんぐる私は考えすぎでしょうか。
 そして、その文は段落も変えず以下のように続きます。

 そしてこの開発姿勢をAgile(アジャイル)といいます

 ・・・酷くないですか?
 顧客の意見を早期にフィードバックするために「段階的に動くものを提供する」というのはあってますけど、それ以外はAjailと関係ないものばかりです。なんだかプログラマーが神として振舞う開発姿勢みたいです。それはそれで楽しそうですけど・・・。

 続いてアジャイルでは「ドキュメントを作らない」ような誤解もしています。仕様が変更されることを前提に「開発時点でのドキュメント作りには重きを置かない」としているのであり、開発後の資料作成や、ドキュメント作りには「より時間のかからない手法をとるべき」としているが、ドキュメントをつくるなとはいっていません。
 ここら辺は、アジャイルや、XPについての本を読まれればより理解いただけると思います。

 上の言及の中でもドキュメントを作らない製作を「職人の勘による」「勘を働かせ」と勘という表現をセレクトするところにも先入観が見え隠れしてなりません。経験という言葉を加える気は無いのでしょうね。
 開発前の仕様策定を最小限にとどめる補強として、オンサイト顧客や、インクリメンタルな開発というプラクティスもあります。

 そして、

 「技術の継承」や「知の蓄積」が社内で行われない

 ということを問題視していますが、
 XPでは2人で一台のパソコンに向かうペアプログラミングを行います。
 先輩が指導しながら、後輩と一つのPCに向かうことの多いペアプログラミングは技術の継承としては今まで以上に効果があると思います。疲れるんですけどねぇ。
 知の蓄積にしても、成果物に対してのドキュメントは残すし、ソースコードをバージョン管理システムで公開するので全員が共有できるように推奨しています。

 アジャイルについての言及はたった2ページですが、
 そこだけでも「よく知らないことでも、安易に話すタイプ」であり「文章の内容ではなく表現の仕方で印象を決めようとするタイプ」という印象を持ってしまいます。

 この時点で、著者に対する見方をある程度決めてしまっているので、
 バイアスがかかっていないとは言えませんが、
 次回はそんな人間から見た本書の感想を書きます。

2006年12月16日

Googleブック検索

 別の場所で、「まるごとPerl! vol1」がWebで読めるんだぁ。と書いたのですが、もっと色々ありました。

 http://d.hatena.ne.jp/kou21058/20061215/p1

 で紹介されているのを見ると、
 インプレス社の本ばかりのようですが、これから増えていくと良いなぁ。

 

2006年12月11日

JavaScriptの良書

 JavaScriptの言語仕様などに詳しい良い本を知りませんか?
 リファレンス的な本でも、どうしても、
 「この表現を実現する方法」
 のような「コピペで使えるJavaScript」風の作りのものが多い。

 それが悪いわけではないのだけど、
 DHTMLとしてJavaScriptを使うのではない身としては、関数などの詳細を載せたリファレンスが欲しい。

 やっぱ動物本か?

 ちなみに今流行のAjaxに使うわけではなく、
 Flashサーバー構築用途というマイナーな利用法です。


 *動物本=表紙が動物のO'REILLY社の書籍です。プログラマーなら目にしたことが無いとモグリ?

足踏みかぁ

 今日結果発表のあった、情報処理試験。
 今回はソフトウェア開発技術者の資格を受験したのですが、

 不合格でした・・・。
 
 内訳を見ると、

 午前が695点
 午後気670点
 午後兇560点

 というもの。各800満点中600点が合格ラインなので、午後兇規定を満たさなかったようです。

 去年からシスアド、基本情報と受けて、午前のマークシート問題は時間さえあればクリアはできる(その時間が社会人には問題なのだが)自信はついた。

 今回は午後気XMLなど業務に近い問題がでたのでラッキーもあったけど、午後兇離▲襯乾螢坤爐量簑蠅派垤膤覆世辰燭里蓮⊃型佑箸呂い┘廛蹈哀薀沺爾箸靴童世ぬができないよねぇ。

 去年の冬からこの一年駆け足で登ってきた感じだけど、
 今年も最後の最後にきて躓いてしまいました。

 奇襲は成功、ただし少々深入りしすぎという所。
 手痛い失敗をする前に、じっくりと来春の再受験に向けて腰を据えましょう。

 でも、来春は午後兇魯▲襯乾螢坤牋奮阿砲靴突澆靴い覆 △隼廚Δ里麓綉い覆鵑任靴腓Δ。一発勝負だもんねぇ午後供

オブジェクト指向と初心者の関係

 前に書くよぉ、と宣言した思うから、
 「オブジェクト指向が初心者にとって難しいのはなぜか?」
 について書いてみようと思う。

 クラスについての書き方や、言語仕様などの覚えることがそうで無い言語より単純に多い(CとC++のように)というのも無いわけではないけど、
 大きな理由は、

 「どこが便利なのかわからない」

 ということに尽きると思う。例えば、

 変数をカプセル化するから、グローバル変数のような意図しない変更などでのバグを防げる。

 といっても、グローバル変数による把握のし辛さは、
 初心者レベルの100行から300行ぐらいのコードでは十分に把握でるから、実感が湧かないと思う。

 オブジェクト指向は、アプリケーションの規模が大きくなるほどに意味をもってくるのだけど、100行ぐらいのプログラムだと、

 「オブジェクト指向でないほうが楽」

 だと私は思う。
 そう、入門書のレベルのソースコードはオブジェクト指向にすると手間がかかるだけだったりする。極端な話、クラスを用いたプログラミングがなんとなくわかる人は、HelloWorld(定番)をクラスを用いて書くことの面倒くささを思ってくれれば良いと思う。

 最初は、非オブジェクト指向言語(これなんていうんだろ、関数型言語、手続指向言語?)の方が楽であり、そもそもプログラミング自体に不慣れな初心者にとって、余計に覚えることがあって、しかも利点の実感しづらいオブジェクト指向は敷居が高くて当然。

 ただし、上記のことが成立するのは、
 プログラムが単純で、短い場合に限る。

 オブジェクト指向は複雑さを軽減してくれる。
 そもそも十分に単純なプログラムにおいては、軽減しようもなく、手間だけが増えるというわけ。

 今後複雑さが増えると絶対オブジェクト指向の方が楽になるから、最初は不毛でもオブジェクト指向を使いなさいよ。というより、

 最初は非オブジェクト指向である程度プログラミングをして、300行ぐらいのコードをリファレンス片手に書けるようになったら、オブジェクト指向を勉強した方が身につけやすいよ、というのがオススメの方針。

 オブジェクト指向は、直感的にとらえにくく、上から下に流れる非オブジェクト指向言語の方が簡単だが、プログラムの規模が直感的にとらえにくくなったら、オブジェクト指向の良さがわかってくるはず。

 書きながら、オブジェクト指向が大規模プログラミングで簡単になるということを前提にしているのは、説明不足だけど、これは後で追々話すとして今は信じてもらいたい(おい・・・)。
 オブジェクト指向を使うと、複雑なswich文などをシンプルにすることができる。といえば、なんとなく良いかなぁと思っていただけるかな、ここら辺の説明も後にゆずるけど、これを聞いて???の方は多分、まだオブジェクト指向をよく理解していない。いや、私も新米なんで、理解している人から見たらまだまだなんですけどね。

 オブジェクト指向の利点をすぐに説明したいところだけど、
 次はもうちょっと上の中級者や、職業プログラマーの視点からオブジェクト指向の難しさを話してみようと思う。

 なんだか、難しいとばかり書いているけど、
 オブジェクト指向を使った方がプログラミングは楽になるんですよ!!

Profile

シーラカンス

Recent Comments
QRコード
QRコード
livedoor Readerに登録
RSS
livedoor Blog(ブログ)