« 2006年9月 | トップページ | 2006年11月 »

2006年10月22日 (日)

技術力とは何か

ソフトウエア・エンジニアの技術力とは何でしょうか。

どうも、この業界では、プログラミング言語の使用経験で、エンジニアの技術力を考えようとしますね。Javaでプログラミング経験が何年、など。つまり、特定の言語が使えるかどうかで判断することが多いと思います。

私は、特定のプログラミング言語で、プログラムが書けることは、「技術力」だとは思っていません。「技能」ではあると思いますけど。これは、例えば建築家で言えば、図面が引けるかどうかのレベルの話だと思います。でも、建築家の技術力は、単に図面が引けるという話ではないですよね。優れた建築物の設計ができるかどうかだと思います。

この業界に関わる人達も、プログラミングができるということと、優れたアプリケーションを開発できるということは、イコールでない、ということには、とうに気づいているのでしょう。そこで、言われ始めたのが、コミュニケーション能力なるもののような気がします。しかしまあ、コミュニケーション能力があれば、優れたアプリケーションが開発できるかというと、これも違うと思いますね。

結局、優れたエンジニアであるかどうかは、その人の作った「作品」を見ないことには、評価できないと思います。優れたものを作る人が優れたエンジニアである、ということにしかならないのではないでしょうか。

この世界では、「図面」の書き方が多種多様で定まった方法がなく、しかも、未だに新しい方法が生まれ続けているような状況ですので、「作品」を持ってこられても、評価できる人があまりいない、というのが問題なのでしょうね。

| | コメント (0)

2006年10月 5日 (木)

ソースとターゲット

通常、コンパイル言語の場合、ソースファイル上でプログラミングを行い、ビルドを行なうことで「ターゲット」となる、実行可能ファイルを作ります。スクリプト言語など、インタプリタ言語では、ソースファイルがそのまま実行できますので、基本的にはソースとターゲットは同じファイルとなります。

ところが、このソースとターゲットを分けるかどうか、はっきりしないものがあります。

Oracleデータベース上で、PL/SQLを使用して開発を行なっていた際、これが問題となりました。

私はテキストファイルの「ソース」上でプログラミングを行い、そのソースを「ターゲット」となる、開発用のデータベース上で、コンパイルする、という方法を考えていました。というか、これが当然と思い、他のやり方があると考えていなかったのですが。

ある人は、Oracleデータベース上で、データベースのディクショナリに格納されている、「ソース」を、直接編集していたのです。ある種のGUIツールを使えば、これが可能なんですよね(親切なことに、このGUIツールには、「デバッガ」までついてました)。そして、その人は、それが「当然」だと思っていたわけです。

で、ここで「どちらの方法が良いか」議論となったわけですが。

私は、以下の点を主張して、説得しました。
--
1)
ソースは別にしないと、ソース管理システムに入れられない。

2)
「ソース」が、おざなりに管理されている、開発用データベースに置かれているのはまずい。開発用データベースは、誰かが「無茶をして」クラッシュさせても良いものだから。

3)
「共有の」開発用データベース上で、複数の人間が「ソース」を編集し始めると、互いの変更が影響しあって、訳がわからなくなる。また、編集中やデバッグ中は、オブジェクトがロックされる。こうしたことで、作業が円滑に進まなくなる。
--

一応、納得はしてもらったのですけど。多少腑に落ちない風でもありました。私自身、ちょっと強引だったように思いまして。結局、これはどうなのでしょうね。

MicrosoftのAccessで開発するような場合も同様ですよね。テキストファイルに書いた「ソース」プログラムを「ビルド」して、AccessのMDBファイルを作る、というのは出来そうですけど、Accessの製品そのものには、そのような機能はなかったと思います。

ファイルの形式については、伝統的に、テキスト派(Unix)とバイナリ派(Windows)の対立があって、それと似た構図は感じるんですけども。ただ、私自身は「絶対テキストでなくては嫌だ」というほどの、こだわりはありません。場合によっては、バイナリ形式でも一向に構わないです。

| | コメント (2)

2006年10月 4日 (水)

GoogleガジェットとWebサービスAPI

Google、マッシュアップ・ダンスのお手並み拝見

以下のように、Googleガジェットがどこからでも利用できるようになったようです。

Googleは、GMailやMapsといったWebサービスで、APIを公開して、誰でもこうしたサービスを利用したWebページを作れるようにしていた訳ですが。こうしたAPIを利用するためには、簡単とはいえ、JavaScriptでプログラミングを行なわなければならず、プログラミングを知らない人間には敷居が高かったでしょうね。

このように、誰もが「プログラミング済み」のガジェットを提供できるようにすることで、「作る人」と「使う人」を、Googleが取り持つ趣旨でしょう。APIの利用が促進されそうです。

| | コメント (0)

Web2.0時代のリテラシ

【警告】Googleカレンダーで情報流出?

ITのリテラシという言葉を思い浮かべました。最近はあまり聞かない言葉ですけども。私もこの言葉で連想するのは、WordやExcelの使い方を教える、という程度で、あまり気にとめたこともなかったのですが。

検索してみると、「ITリテラシ」という言葉は見つからず、以下の3種類が見つかりました。

メディアリテラシー【media literacy】
コンピュータリテラシー【computer literacy】
情報リテラシー【information literacy】

これで言えば、私の思い浮かべたイメージは、「メディア・リテラシ」が一番近いですね。

Googleカレンダーが「メディア」というのは、多少違和感を感じますが。Webというのが、そもそもメディアの一種ですからね。アプリケーションであり、同時にメディアでもある、というのが正しい認識だと思います。

おそらく、Googleカレンダーでプライベートな予定を、全ネットユーザに対して公開してしまっている人は、Googleカレンダーが、「公開メディア」でもある、という認識がないのでしょうね。あくまで、アプリケーションだと考えているのではないでしょうか。

Winnyの件もそうですが、こういうのは「事件」が起きてから、大抵の人はその危険性といいますか、リスクに気づくわけでして。新しい技術というものは、常にリスクを含んでいると思います。

こうしたリスクに気づくことができるよう、啓蒙しなければならない、というのが、「何々リテラシ」という言葉の趣旨なのでしょう。しかし、啓蒙それ自体は根本的解決にはならず、「気休め」程度にしかならないんですよね。「事件」が起きて、ニュースで大々的に報道されたりすると、まさに「啓蒙」されるわけですが。時すでに遅しという感があります。

私自身は正直、プライベートな内容で、こんなにGoogleカレンダーを使うとは、想像もしていませんでした。企業や団体などが、イベントやセミナーなどの予定を告知したり、参加者を募ったりするのに使えそうだな、というのが私の想像だったのですけど。

| | コメント (0)

« 2006年9月 | トップページ | 2006年11月 »