flint>flint blog
Page: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »

サーバと奮闘中

新しく仕事を始めるにあたっては、どうしてもサーバが必要となります。 そんなわけで、さくらインターネットのVPSを借りることにしました。

OSは、業務でもプライベートでも使い慣れている FreeBSD を選択。 ここに、Apache, Postfix, Dovecot, PostgeSQL 等々のソフトウェアをインストールし、これらを適切に設定しなければならないのですが、これが想像していたよりも大変な作業です。 前の職場にいたときは専門のスタッフが管理するサーバを何気なく利用していましたが、自分でその作業を全部やるとなると、これがいかに大変なことかが分かりますね。

かく言う現在も、Postfix のSMTPまわりの設定に不備があるらしく、メールが上手く送信できないので、目下調査中です。 サーバの設定にばかり時間をかけているわけにもいかないので、さっさと片付けてしまいたいところなのですが...。

Narita (がんばれ!アドミンくん)
このエントリーをはてなブックマークに追加

ごあいさつ!

はじめまして。 今月より、ここ山梨県甲府市でフリーランスで活動を始めた 成田 祥 と申します。

五月末までは、福島県は会津若松市のとあるIT企業で働いていましたが、諸事情により独立することとなりました。

業務としては主に、Microsoft Visual C++ を用いた Windows アプリケーション (サーバ/クライアント型含む) の開発や、Ruby を試用したウェブ (CGI) サービスなどを手掛けてきました。 珍しいところでは、SensAble Technologies 社が提供する触覚デバイス PHANToM の制御プログラムなども書けたりします。 Omni (GHOST: General Haptic Open Software Toolkit) と Desktop (Open Haptic SDK) 両方の開発経験があります。

知人のツテなどの一切ない状態でのスタートですので、これから積極的に営業活動を行っていく予定です。 ソフトウェアの設計・構築の案件がございましたら、是非お声掛けください。 電話番号, メールアドレス等は、こちらに掲載しております。

Narita
このエントリーをはてなブックマークに追加

チョークのマークひとつ

これが問題の個所だ。

私たちが普段行っているソフトウェア・システム開発には、他の製造業と大きく違う点があります。 それは、モノができあがるまでに掛かるコストの殆どが人件費であるということ。 他の製造業において、原材料, 加工に使われる電気, 洗浄のための水など費用が占める割合を考えれば、これはかなり特殊な形態です。 (厳密に考えるならば、そうした費用も最終的には人件費に行き着くわけですが、ここでは措いてください。)

ところで、この「人件費」とはいったい何でしょうか? 辞書的な定義を引くならば、人を雇用することによって発生する費用のことですが、そうした言い換えはあまり実用的とは言えません。 その性質に着目した理解の仕方をするならば、それぞれの被雇用者が有しているエネルギーや知識・技術といった所謂「労働力」を調達するためのコストである、と言えるでしょう。

この労働力のうち、使われたエネルギーあるいは、為された (物理的な) 仕事については、定量的な評価が可能であるため、支払われた賃金に見合っているかどうかということは比較的容易に判断することができます。 その一方で、知識あるいは技術と呼ばれるものについては、それを定量的に計測することは極めて難しく、実際問題としては不可能と言わざるをえないでしょう。 例えば、二人の技術者がいたとき、その知識の差を数値で表すことは可能でしょうか? あるプログラミング言語を習得することによって、どの程度の技術向上が見込めるかについての客観的な評価法は存在するでしょうか? そのような方法論の確立を目指して、これまでも標準化や規格化, 資格・認定制度の導入などが数多く試みられてきましたが、私の見るところでは、そのどれもが技術者の力量あるいは価値を定量的に示す基準として機能しているとは言い難いのが現状です。 また、あるノウハウを手に入れるために必要となる投資 (金額, 時間) はどれほどか、という問題についても、未だ実用に耐える精度を備えた計算方法はありません。

そうした、知識・技術を獲得・評価することの難しさについては、これまでも何度かこの日記で書いてきました。

それ故、私には今や、このテーマについて新しく語るべきことはあまりなかったりします。 その替わりといっては何ですが、個人的に気に入っている、ある古いジョークを紹介したいと思います。

read more >>
Narita
このエントリーをはてなブックマークに追加

Tractor

固定翼の飛行機は、揚力を得たり、舵を利かせるために、その翼に当たる風を必要とします。 この風が得られなくなり、パイロットが機の状態を制御できなくなってしまうのが、いわゆる失速 (ストール) と呼ばれる現象。 このような、コントロールを喪失した状態の発生をいかにして防ぐか、あるいは、そこからどれだけ早く復帰するか、ということは、工学において非常に重要な課題です。

「結局のところ、ストールから抜け出す時間だ」ティーチャは答えた。

散香のようなプッシャ・タイプはプロペラが後ろにある。 一方の翠芽はプロペラが前にあるトラクタ・タイプだ。 プロペラが作った風を、機体で受け止めているトラクタは、メカニズムとしては効率が悪い。 ところが、機体が失速して、頭を下げて落ち始めたときには、速度がある程度まで達しないと舵が利かないけれど、そのとき、トラクタはプロペラが作り出す風を翼の舵に当てることができるから、舵が早く利き始める。 極端な場合、速度がまったくゼロのときだって、プロペラを高速に回して舵を大きく切れば、姿勢を制御できる。

自動車に搭載されているABSもその一例。 フルブレーキをかけても、タイヤをロックせず、ハンドルを切ることで進行方向を制御できる (つまり、舵が利く) ように設計された機構です。

あくまで私の個人的な意見ですが、自動車や飛行機だけでなく、私たち人間の心理・行動の制御についても、この工学の理論を適用することで、見えてくるものがあるのではないでしょうか。

read more >>
Narita
このエントリーをはてなブックマークに追加

求められているもの

東日本大地震発生から5日が経ちました。 各被災地では未だ混乱が続いており、今このときも、被災者の安否情報を求め、いたたまれない思いをしている人々が全国にどれだけいることでしょう。

昨日まで、私もその一人でした。 津波によって壊滅的被害を受けた宮城県気仙沼市に住む弟と、地震発生から4日が経っても、一向に連絡が取れず、現地の被害状況に鑑みて、半ば諦めてもいました。 幸いにして、昨日本人から実家に連絡があり、その無事を確認できたのですが、それまでの4日間は、本当に気が気ではありません。 何でもよいから彼の消息に関する情報が得られないものかと、寸暇を惜しんで情報収集を試みていました。

その際、速報性に優れるメディアとしてテレビに大きく頼っていたのですが、時間が経つにつれて、私はその災害情報の報道の在り方に大きな苛立ちを感じ始めました。 というのも、テレビがそれを観ている多くの人が真に求めているであろう情報、即ち冒頭でも述べた、被災者の安否情報を伝えることについて、とても消極的だからです。

read more >>
Narita
このエントリーをはてなブックマークに追加

抜け落ちるもの

ソフトウェア開発の工程は大きく分けて、要件定義, 設計, コーディングの三段階からなります。 (実際には、その後にテスト, デバッグなどの段階が続きますし、これらも明確に区別されるわけではなく、互いに絡み合っている部分もありますが、「作る過程」の説明としては大きく外してはいないはず。) これらの段階においては、「何を」「どのように」作るかということが順次決定されていきます。 そこで決められた事項は、仕様書設計図として文書化され、開発に携わるメンバの間で共有されることになるわけですが、この共有の際に零れ落ちてしまう、あるいは、作る過程では確かにあったのに、完成品からは抜け落ちてしまうものがあります。

例えば、データベースの仕様書には、各テーブルに属するカラムの名前, データ型や、それらが満たすべき制約については、逐一正確に書き込まれます。 しかし、それらの事項がどのような理由・経緯によって決定されたのかということについては、ドキュメントは何も教えてはくれません。 書きあがったプログラムを眺めても、例えば関数名や引数の並びについて、何故そのようになったのか、ということは分からないようになっているのが一般的です。 それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

けれども、ソフトウェア開発の知識・技術の本質とは、こうした「作る過程」における「瑣末なもの」の中にこそある、と私は考えています。

read more >>
Narita
このエントリーをはてなブックマークに追加

技術と魔法のギャップ

テクノロジーの進歩についての語りにおいて、よく引用されるフレーズに「クラークの三法則」の第三法則があります。

Any sufficiently advanced technology is indistinguishable from magic.
(高度に発達した技術は魔法と区別がつかない。)

近年の映像・音声認識技術の向上や、様々な入力デバイス (タッチパネル, リモートコントローラなど) の普及によって、エンドユーザ層がこれまで抱いていた「コンピュータはとっつきにくいもの」という認識は急速に緩和されているように観察されます。 こうした社会の流れの中にあって、「技術」はその原理や本質をブラックボックスの内部に隠蔽していき、魔法としての装いを強めてきました。 世の中に魔法が満ち溢れ、誰もそれを不思議とは思わない社会は、もはやSFでもファンタジーでもなく、実現のものとなりつつあると言えるでしょう。

とは云え、現実には魔法などというものが存在しないということは、皆様もご存知の通り。 あらゆるモノゴトの振る舞いが例外なく (私たち人間さえも) 物理法則によって支配されている以上、どんな魔法にも必ずタネと仕掛けがあります。 「魔法に見えること」と「魔法であること」は、決してイコールではありません。

read more >>
Narita
このエントリーをはてなブックマークに追加

Words describe you again, and again

近年の Facebook, Twitter に代表される SNS (Social Networking Service) の勢力拡大には目覚しいものがありますね。 周囲を見渡してみても、これらのサービスのアカウントを保有していない人を探す方が大変なほど。 以前、ブログによってインターネット上の「発信者」の数が激増したという話 (参照: 議論の仕方) をしましたが、SNSによってこの増加に拍車が掛かったように思われます。

ところで、これほど多くの人々が情報を発信するようになったことで、インターネットがどう変わったかと改めて考えてみると、私が期待していたのとはだいぶ違った方向へ進んでいるように思えます。 と言うのは、その内容には特に意味のない、「発信者」同士の関係を表すためのだけの情報が、ネット上で交換されるデータの大部分を占めているように観察されるからです。 特にその傾向が強いのが Twitter で、リツイート (Retweet) と呼ばれる機能により、他のユーザの投稿内容を自分の投稿に引用するということが頻繁に行われています。 これは、ユーザの関心が「何を語るか」「何が語られているか」よりも、「誰が言ったか」「誰がそれを読んだか」に向けられていることを示すものでしょう。 もっとも、それがソーシャル・ネットワークの本質であるわけなのですが、個人的には色々な人の多様な考え・意見が読めるようになると期待していたので、ちょっと残念に感じてしまうのかもしれません。

ところで、この頃のネットでは引用が多くなったから、自分の意見を語るまえに、どこかから引用をしようとする。 自分の意見を持たない者も増えた。 「誰某がこんなこと言っているらしいけれど、どうよ?」 「ああ、それなら、こんなこと言っていた奴もいるみたいだよ」 というリンク先を交換するだけで意見交換をしていない。 しかも、原典まで辿らず、伝聞だけの「噂話」に終始する。 こういった情報のシェアが、「親切」の一種だという価値観が生まれたように見えるが、たぶん、昔からあったことだろう。

実は、ネット上に限らず、現実空間における人との係わり合いにおいてもこうした傾向を感じています。 人間は普通、課題や仕事に取り組んだり、本を読んだりすれば、それらに対して何らかの感想や、自分なりの意見を持つのではないでしょうか。 しかし、そうした意見や感想を持たない、あるいはそれを自分の言葉で表現しない・できない人が非常に多いのです。 見たもの・やったことを淡々と説明したり、それに関連するこんな記事を読んだという 「事実」の説明はできるのですが、「それについてあなたはどう感じた・考えたか」を尋ねられると、途端に言葉に詰まってしまうというケースが頻繁に観察されます。

意外に思われるかも知れませんが、特にITの分野では、仕事をする上で自分なりの考え・意見を持つこと、それを表現することは非常に重要な意味を持ちます。 何故ならば、客観的な事実の記録や、外部の情報への接続 (リンク) などの行為は、コンピュータによってほぼ完全に賄われてしまうからです。(参照: 思考の価値) 人間を遥かに凌ぐ記憶精度・容量と演算速度をもつコンピュータによって稼動するシステムの中にあって、それでも人間をそこで働かせる必要があるのは、こうした人間が持つ経験や勘 (と呼ばれるもの) や、そこから生まれるデータ化できないノウハウ、即ち、個人的な考えと判断が不可欠だからに他なりません。 「主観的なものの見方は、ビジネスにおいて害悪である」という考え方は、必ずしも正しくないのです。

そしてまた、そうした考え・意見を、自分の言葉で、他人に分かるように伝えるということも大切。 これをやらずにいると、知らず知らずのうちに「考えること」自体ができなくなってしまいます。 「いざとなればできる」なんて思っていても、普段からある程度の運動をしていないと、実際に走ってみたときに想像以上に身体が鈍っていてびっくりするのに似ているかも知れません。 体重計を気にするのも結構ですが、脳メタボにもご用心、です。

Narita (書くことは考えること)
このエントリーをはてなブックマークに追加

関数分けの効用

通常、プログラムを書くときは、処理をただ順番に書き下すのではなく、いくつかの「関数」に分割します。 これによって各ステップの処理が部品化され、再利用が可能になるわけですが、関数分けの効用はそれだけに留まりません。 たとえ、たった一度しか実行されない処理でも、これらを上手く関数化し、本体から分離することで、プログラムの可読性・保守性を向上させることができます。

例えば、以下のようなフォームからデータを受け取るプログラムを考えてみましょう。

名称
所在地
-
Tel
Fax
▲ソースを隠す
<form action="./" method="post">
    <div>
        <input type="hidden" name="id" value="<%=office.id%>" />
    </div>
    <table>
    <tr>
        <th>名称</th>
        <td><input type="text" name="name" value="<%=escape_html(office.name)%>" /></td>
        </tr>
    <tr>
        <th>所在地</th>
        <td>
            <input type="text" name="postcode-a" value="<%=sprintf('%03d', postcode_a)%>" size="3" /> -
            <input type="text" name="postcode-b" value="<%=sprintf('%04d', postcode_b)%>" size="4" /><br />
            <textarea name="address" rows="2"><%=escape_html(office.address)%></textarea></td>
        </tr>
    <tr>
        <th>Tel</th>
        <td><input type="text" name="tel" value="<%=escape_html(office.tel)%>" /></td>
        </tr>
    <tr>
        <th>Fax</th>
        <td><input type="text" name="fax" value="<%=escape_html(office.fax)%>" /></td>
        </tr>
    </table>
    <div>
        <input type="submit" value="<%=escape_html((office.id != 0) ? ' 更新 ' : ' 登録 ')%>" />
    </div>
</form>
read more >>
Narita
このエントリーをはてなブックマークに追加

猪苗代第一発電所

azure water and blue sky

天気がとても良かったので、磐梯町にある「猪苗代第一発電所」へ。 今回は、以前「猪苗代第二発電所」を訪れたときとは逆に、猪苗代湖側から膳棚山を経由して磐梯町駅方面へ抜けてみました。

read more >>
Narita
このエントリーをはてなブックマークに追加
Page: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »