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

エンジニアの聴力

機械部品の故障は、他の部品との接触や、内部抵抗の増加 (あるいは短絡) によるものが殆ど。 それらの現象によって部品は変形・破壊されて正常に動作しなくなり、結果的にシステム全体が機能不全に陥るわけです。 この変形・破壊の際に生じるエネルギーの一部は「音」として周囲に放出されます。 構造内部で発生した音は、破壊が起こす他の現象 (見た目の変化や熱の発生) よりも早く顕著に外部に伝わるため、システムトラブルの最初の兆候が「音」の異常として現れるケースは少なくありません。

ハードディスクが壊れるときの「キューイ」あるいは「カラカラ」といった音、モニタが映らなくなる前の「プツプツ」といった音がその例。 完全に壊れる前であっても、異常な動作によって失われたエネルギーは音となって私たちの耳へと届きます。 (もちろん、すべてのものが壊れる前に音を出すというわけではありませんが。)

コンピュータに限らず、機械類全般、さらには生き物の身体でも同じことが起こるため、エンジニアや医師は「音」を異常検出のための重要なファクタとして位置付けています。 この音による検知能力は、耳の感度だけでなく、「音を積極的に聴く」「異音がないかに気を配る」といった姿勢に依るところが大きいようです。 集中力や気分を高めるために、仕事中にイヤホン/ヘッドホンで音楽を聴くという人が増えてきていますが、少なくともエンジニアとしてはあまり好ましい習慣ではないでしょう。

Narita (音痴は関係ないっ!!)
このエントリーをはてなブックマークに追加

鶏と卵

プログラミングの技術要素は、データ構造に関するものととアルゴリズムに関するものに大きく分けられます。 前者は主として「設計」の段階で、後者は「実装」の段階で必要になる知識と言えるでしょう。

私の見る限り、プログラミング技術に関する教育の場においては、「アルゴリズム (実装技術)」の習得が重視される一方で、「データ構造 (設計技術)」は非常に軽い扱いとなっています。 アルゴリズム関連の知識は、学校の講義・演習のような短時間かつ散発的な講義・演習でも (ある程度は) 習得可能が可能であるのに対し、「データ構造」を選択・採用する知識 (設計技術) を得るにはプログラムの長期的な開発・運用の経験が必要になる、といったことがその理由だと考えられます。

しかしながら、職業としての「プログラミング」においては、この「データ構造」と「アルゴリズム」の重要性が逆転します。 製品となり年単位の長期的なスパンで運用されるシステムにおいては、実装はむしろ些事であり、設計に起因する保守性・拡張性が評価に直結します。

仕様変更が起こったときに、「ああ、この変更はずいぶん前から要求されそうな気がしていたんだよなぁ…」と思うことはありませんか? やはりここでも設計の善し悪しがものをいいます。 予測される変更を考慮して、それが実際に起こったときの手間を少なくするような設計をしておけば良いのです。 でも現実には、将来への準備を怠っているケースが多いようです。

( 中略 )

どうやら、知恵を使いさえすればしなくても済むはずの苦労が、ソフトウェア開発業界には蔓延しているようです。 これを逆に考えてみると、設計の技術を使いこなしてよけいな苦労を回避できるようになれば、人の何倍も仕事がこなせるようになるということです。

ソフトウェア開発者を目指す人は、「実装」だけでなく「設計」を学んでおくと、実際の業務において大きなアドバンテージを手にすることができるかもしれません。

Narita (コードを書き始める前に10数えろ。)
このエントリーをはてなブックマークに追加

創造力の正体

創造力の源は「直感」や「閃き」と呼ばれるものであると一般的には考えられているようですが、実際のところ、直感によってもたらされる着想の 99% 以上は役に立たないゴミ案です。 むしろ、これら膨大な量のゴミの中から 1% 未満の宝 (有益な何か) をより分ける作業こそが、創造という行為の本質ではないでしょうか。

この「より分け」はつまるところ、自分への駄目出しに他なりません。 自分が出したアイディアをひとつひとつ検証し、短所・欠点を探しては捨てていくわけです。 ゴミと宝の比率を考えると、「宝を探す」というよりは「ひたすらゴミを捨てる」という行為に近い上に、「ゴミを全部捨てたら何も残らなかった (全部ゴミだった)」という結論に達してしまうことも少なくはありません。 かくのごとく、創造というものは「閃き」よりもコツコツと「考える」ことによってなされる非常に地味な行為なのです。

ちなみに、「ゴミ案 (宝の候補) すら出てこない」という状態は、基本的な知識・理解の不足によるものであり、「創造力」云々以前の段階です。

「考える」という言葉を非常に安易に使っている人が多いと思う。 学生に「考えてきたか?」と尋ねると、「考えましたが、ちょっと良い案を思いつかなくて」と言う。 「じゃあ、悪い案を幾つか見せなさい」と言うと、きょとんとした顔で、「いえ、悪い案も思いついていません」と言う。 「考えましたが、まだ、ちょっとまとまらなくて」と言うから、「では、まとまらないものを見せて下さい」と言っても、たいてい見せてもらえない。 こういうのは、僕の場合「考えた」とはいわないのである。

沢山の具体案を考えることは、無駄なようでけっして無駄ではない。 採用されなかった案が、その人の将来の持ち駒になるからだ。

「クリエイティブな仕事」というのは、その言葉が持つイメージとは対照的に、とても地味で陰気で気の滅入る作業。 それでもなお、新しい何かへの期待で己を鼓舞し、ゴミの山を築き、そこへ突撃していける者だけが、クリエータたり得るのです。

Narita (「クリエイティブ」という語を名詞として使う文化に疑問を抱く)
このエントリーをはてなブックマークに追加

配列やハッシュテーブルを構造体の代わりに使う奴はヤキ

Perl, Ruby など多くのスクリプト言語では、1つの配列に異なる型のオブジェクトを格納することができます。 Generics 導入前 (1.4 以前) の Java でも、同じようなことができました。 しかし、このテクニックは基本的に使ってはいけません。 次のプログラムを見てください:

books =[
    [ '神は妄想である', 'リチャード・ドーキンス', 2500 ],
    [ '穴 -HOLES-',   'ルイス・サッカー',       620 ],
]

この例では、配列 books の中の要素 (これまた配列) が各「書籍」のデータを表します。 0番目の要素が「表題」、1番目の要素が「著者名」、2番目の要素が「価格」がそれぞれ格納されるという寸法。 なので、すべての書籍の著者名を出力するコードは次のようになります。

books.each { |b|
    puts b[1]
}

......最低ですね。

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

思考の価値

このところ、「脳開発」がブームになっている模様。 書店へ行けば、

ゲームを買いに行けば、

といった具合に、「頭脳系」の商品がたくさん目に付きます。 人間は、「健康な肉体」と同様、「優秀な頭脳」に憧れるもの。 記憶力・計算力も高いに越したことはありません。

しかし、プログラマである私などは、 「計算とか記憶って、コンピュータにやらせるべき仕事じゃないの?」 なんて思ってしまったり。 人間の思考の価値は、コンピュータにはできない、「ミスをする」「飛躍する」「忘れる」といった特性にあります。 その特性こそが、新しい概念、斬新な発想を生み出す下地に他ならないからです。

コンピュータを速く、正確に、間違わず動かすべくあれこれ知恵を絞ってるソフトウェア開発者から見れば、人間というのは敢えて「論理的正確さから外れる」 = 「(部分的にではあるけれど) 間違う」ことを目的として稼働する非常に贅沢なシステム。 そんな贅沢なシステムに、コンピュータでもできる計算力・記憶力を過剰に詰め込むというのは、少々無粋な気がするのです。 「如何に間違うか」こそが、人間の思考の価値なのですから。

Narita (エクス・マキナ)
このエントリーをはてなブックマークに追加

コウモリ問題

現在、XMLパーサ (構文解析プログラム) を作成しています。 DOMと同様、XMLデータを木構造として扱う仕様なのですが、ここで問題となるのがノードの分類方法。 一見して同じような形式だったり、良く似た名前であっても、実際の分類は全く違うというケースがかなりあります。 例えば、「XML宣言」と「文書型宣言」というものがあるのですが、「『○○宣言』という名前だから同じグループに属するんだろう」と思っていたら、これがまったくの別物とか。

「コウモリは翼を持っているから鳥の仲間だろう」というような誤りに通じるものがあります。 「コウモリは鳥類」という前提で研究を続けていたものの、ある日唐突に真実に気が付き、打ちひしがれる生物学者。 「よく考えたら、こいつ間違いなく哺乳類じゃん……。」

とまぁ、そんなわけで、私のパーサもかなりの部分で書き直しが必要になってしまいました。 ......紛らわしい名前付けんなよチキショー。

Narita (BNFによる定義も、分類のアテにはならない。)
このエントリーをはてなブックマークに追加

蓋沼森林公園

蓋沼の浮島

先週末は会津美里町 (旧会津高田町) にある、蓋沼森林公園へ行ってきました。 冬に行こうとした際は入り口を見つけられず、柳津町の方へ向かってしまいましたが、今回はちゃんとたどり着くことができました。

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

文字の大きさ

ウェブページをデザインする際は、何か特別な事情がない限り、文字の大きさは固定しないようにしています。 見やすい文字のサイズは、人によって違うもの。 例えば、私は普段 Internet Explorer の文字サイズに「小」を指定しているので、標準的な文字を、これくらい↓

「教養」とは学歴のことではなく、「一人で時間をつぶせる技術」のことでもある。

のサイズで見ていますが、私の実家の PC は父の老眼に合わせて、ブラウザのフォントを「最大」サイズ↓

「教養」とは学歴のことではなく、「一人で時間をつぶせる技術」のことでもある。

に設定してあります。

ウェブページというのは一般に、不特定多数の人々を閲覧対象としているため、このようなユーザ環境の変化に対して、可能な限り柔軟であるべきです。

「いや、でも見栄えを良くするには、文字サイズは固定した方が……。」と言う人もいますが、それはあくまでポスタやリーフレットなどの紙媒体でのデザイン手法。 それよりも「文字サイズを可変にしても見栄えがするデザインは何か?」と考えるのが、ウェブデザイナの取るべき姿勢ではないでしょうか。

Narita (スケーラぶるプログラマ)
このエントリーをはてなブックマークに追加

人里離れて

選挙カーが余りにもうるさい (イメージ) ので、人里離れた場所へと避難。 今回はこのあたりまで行ってきました。

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

入力と内部処理

常に新しい技術が現れては廃れていくIT業界。 コンピュータ・エンジニアリングを生業とする者は、日々情報を収集し続けなければなりません。 ニュースサイトをチェックし、雑誌を購読し、市場のトレンドを追う毎日。 (参考: @IT 「がんばれ!アドミンくん 第29話『情報砂漠』」)

その一方で、「手持ちの材料で何ができるか」と考えることに時間を割くことをしない (できない) という環境にも置かれるようになっています。 自分で試行錯誤して作るより、他の誰かが作った流行の技術を Web 上で探してきて、それを組み合わせた方が、早く・安く・品質の高いものができてしまう現状を考えれば、それも仕方がないのかもしれません。

しかし、他人の作ったものをブラックボックスとして使っているだけでは、いつまでたっても自身の技術向上は見込めません。 外部から取り入れた知識・技術を本当の意味で自分のモノにするためには、一度情報の収集をストップした上で、手持ちの材料を吟味・使用していくことが必要なのですが……。

殊にソフトウェア・エンジニアリングの現場では、開発の期間短縮・低予算化によって、こうした「本当の」学習の機会はどんどん減りつつあるのが現状。 現在はそうして短期的に製品開発の効率を上げてる企業が、市場において有利だと考えられているようですが、そんな状況はそう長くは続かないと、個人的には考えています。

Narita (昔気質プログラマ)
このエントリーをはてなブックマークに追加
Page: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »