A Day In The Boy's Life -202ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

リアルの世界での雑談は、時には思わぬ知識を得られ、時には無駄な時間をすごし、時にはその人との強い結びつきを得られる、というような感じで得られるもの、失うものが混同するよくもあり悪くもあるコミュニケーションです。


雑談は、何かの決まりきった枠を取っ払って情報を共有できるところに良さがあります。

あまり硬くならずに、趣味の話や今日の出来事、社内の噂などなど。

もちろんそれらの全てが自分の血となり肉となるものばかりではありませんが、硬く真面目に一つのことを話し合う視点とは違った良さがあったりもします。

雑談のよさはその異なる視点を得られる事です。

同じ仕事をしている同僚と話しても、どことなく話す事に困ってついつい仕事の話をしてしまったり・・・。


その雑談ですが、リアルな世界だと意外と制約も多いわけです。

雑談できる相手は少なくとも自分と知り合いである人がその対象となります。

そして、まずはその人と出会うところから雑談が始まります。

いや、特にこの人と雑談しよう!なんて事を考えながら会うわけではありませんが、少なくとも会わなければリアルな雑談は始まりません。

このリアルな人間関係が、雑談のコミュニケーションに大きな弊害になります。

まずは、知り合いが少ないと雑談できる対象者も少なく、そこから得られる知識もすくないと、と。


この雑談ですが、ネットを使って同様の異なる視点を得ることは簡単にできます。

自分のブログの読者になってくれた人からのコメントやTBによって・・・、というのは少し敷居の高いネット雑談になりますので、もっと単純化してしまえば良いと思います。

つまりは、誰か知らない人でもその人のブログなんかを読めば異なる視点を得ることはできます。

さほど興味の無いことでも、読んでみると意外と自分が知らなかった知識が得られたりもします。


そこで、出てくる問題がその情報の信頼性という問題。

ただ、このどこかその情報に信頼を置けないという問題は、自分の知っている人と知らない人という違いだけで、どちらの話を信ずるかという違いだけだと感じます。

あの人は良く知っているし、あの人の言う事だから信頼できる(信用できない)だろうと。


しかし、少なくとも雑談レベルと考えれば、そこで得れた情報を鵜呑みにはせず、単純に自分がその情報に興味がわいたかどうかの視点だけで情報を取捨選択してしまえば問題はでません。

「へ~そんな事があるんだ」という関心ごとが起きれば、後は自分なりの視点で調べてみればよいだけの事。

それさえも起きなければ、早々にその場を離れる事もネットではできます。

何でも食いつかない事、何でも鵜呑みにしない事、それがネット雑談する上でのコツかと思います。


ネットに埋もれるたくさんの人の中から無作為に選んでみて、その人のブログを読んでみる、そんな事も時には役立つものではないでしょうか。

ネット上にある無数の情報は、リアルの世界の人間が生み出したものです。

そして、そこにある情報には、自分とは異なる視点の人たちが生み出したものです。

そう考えればリアルな世界で難しい雑談もネットの世界では簡単に同様の事をやってのける事ができると感じます。





ソフトウェアを自由に作り出す事ができるプログラマーですが、そのプログラミングの世界の実体はそれほど自由ではありません。

つまりは、ソースコードを書くこと自体にも色々な制約があるということです。

そういったコーディング規約などの制約は、可読性をあげる、保守性を高める、そういった目的で取り決められたルールです。


確かにそれは遵守すべきルールです。

しかし、それは車の運転ルールを定めた道路交通法ほど厳しくなく、どちらかというと単なる約束事でしかありません。

法律には制限と違反した際の罰則があります。

しかし、プログラマーが遵守すべきコーディング規則は制限はあっても罰則はありません。

理由は、違反して例え事故が起こったとしてもそれはコーディング規則を守らなかった事が原因となることはないからです。

このルールは確かに守る義務がプログラマー側にあります。

もし、そのソースを永遠に自分ひとりで保守するのであれば自分のしいたルールを適用させればよいだけですが、そういったことが仕事をする上でありえるかどうかを考えれば守らなければならないという理由はおのずと見えてきます。


しかし、そういったルールがしかれる事自体が悲しい現実なわけです。

なぜなら、多くのプログラマーはそういったルールがしかれないとそのように書かないからです。


プログラムの保守を容易にするためにはどうすればよいか?

答えは単純で「美しいコードを書けばよい」となります。


この美しさという抽象的な表現は個人によって差が出てしまうために、公平な基準で定めたコーディング規約があったりもするわけですが、少なくとも美しさにこだわったというその人の姿勢は間違ってはいません。

もしそれが本当に美しいものであり、そこから信念を読み取る事ができるまでのクオリティの高いコードであれば誰もが賞賛の声を送ることと思います。

現にコーディング規約は一つではありませんし、自分が中心となってコーディング規約を作り出しそれをプロジェクトチームに展開する事もできます。


しかし、現状そこまで美しいコードというものを少なくとも私は業務の現場で見たことはありません。

それを見ることができるのは、オープンソースのプログラムの世界でのみです。

プログラミングする事を生業としているプログラマーは、多くはその対象のソフトウェアができる事に没頭しています。


プログラムを書くことが結果的にソフトウェアを生み出すという経緯にはなりますが、システムの画面には多少のこだわりを見せるものの、プログラムにはあまりこだわらないというプログラマーもかなりいます。

そういったソフトウェアは、立派なお城を完成させたようにみえて、裏に回れば実はハリボテだったというような事態になっています。(風が吹けば一瞬にして倒壊するかもしれません)


プログラムはプログラマーが作り出す芸術作品です。

その芸術作品の美しさにトコトンこだわってみるというのもプログラマーのなすべきことの一つでは無いだろうかと感じます。




「iPhone Earth」のデモ @ TechCrunch Japanese


Google Earthとかを見てたら、バーチャル地球儀のソフトウェアと言う事自体にはさほど驚きは無いのですが、面白いのはやっぱりiPhoneの操作方法。

いや、iPod touch の頃からありますが、あの操作方法(フリックだっけ?)はかなり楽しい。


友人が持っていたので触らせてもらいましたが、2本の指で画面にタッチして外にスライドさせれば画像が拡大されるし(ピンチアウトというらしい)、2本の指を内側にスライドさせれば縮小される(ピンチアウトというらしい)。

近未来的なディスプレイを手に入れた!って気分に浸ることができます。


そんな画面操作を持ち合わせたiPhoneに、地図サービスのソフトウェアを持ってきたわけですが、この操作方法が何よりも地図サービスをうまく表現できる操作方法なのではないかと感じます。

パソコンの画面に向かってマウスをクリックする方が操作は簡単だと思いますが、この指を使った操作の方がまさに画面を動かしているという感覚が強いのではないでしょうかね。


昔アニメの中で見た、腕時計型の超小型で超多機能なデバイスは、主人公だけが持つことを許された秘密武器という枠を超えて今まさに身近になろうとしている、そんな印象を持ってしまいます。


そのうちリアルタイムに衛星写真を覗くことができて、子供たちはハイレベルなかくれんぼをして遊んだりするのだろうかと思ったり。(もはやスパイゲームだが・・・)