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

柵の倒し方

安全なウェブサイトの作り方 by IPA

コンピュータ・インターネットの世界は日進月歩。 これまで誰も予想しなかった技術・サービスが、あっという間に世界中に広がり、常識が一日ごとに塗り替えられていきます。 そうした環境においては、常に自己を革新することが求められ、新しいことに挑戦する勇気を持たぬものは消えていく運命にある......といったような認識を持っていらっしゃる方も多いのではないでしょうか。 そうした見方は概ね正しいと思います。 挑戦と革新はいつの世も進歩と発展の原動力であったことは間違いなく、またこれからもそうであることでしょう。

その一方で、プログラマの間でよく知られる格言に、

フェンスが建てられた理由が分からないうちは、それを倒してはならない。
Don't ever take a fence down until you know why it was put up.

というものがあります。

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

Hirosaki Exotica

先週の金曜から夏休みを頂いて、青森県弘前市へ行ってきました。

まずは白神山地を観にいったのですが、折からの豪雨で川は増水し、登山道も荒れていたため、最初のチェックポイント (?) である「暗門滝」で引き返すことに。 世界遺産である白神のブナ林を満喫できなかったのは非常に残念でしたが、その手前にあった建設中の津軽ダムのバッチャープラント (コンクリートを作る設備) [参照] を見て興奮してきたので、モトはとれたと思いたいところです。

次なるお目当ては、8/1から開催される弘前ねぷた祭り。 20年ほど前に見たきりなので、本当に久しぶりです。 青森ねぶたと混同されることも多いですが、「ねぶた」が立体的に造形された灯篭 (3Dサーフィスモデルの先駆け!?) なのに対し、「ねぷた」は扇形の平たい灯篭にねぷた絵 [参考] と呼ばれる合戦絵をのせたものが主体であるところが大きく異なります。 (ねぷたの中にも、立体的に作られた「組みねぷた」はありますが。) このねぷたも、途中から雨が降り出してしまい、途中で中止となってしまったのが返す返すも残念でした。

弘前は、日本の他の地方とは独特の文化・風土を持っており、東北地方 (宮城・福島) に住んでいる私から見ても、非常に強い異国情緒を感じさせる街です。 皆様も一度はこのエキゾチック都市・弘前を訪れてみてはいかがでしょうか。

写真左: アップルスナック (ジョナゴールド)
http://www.net24.ne.jp/~applesnack/f-40.html#syohin
写真右: おきな屋『 紅玉天』
http://www.a-okinaya.co.jp/products_06.html
Narita (雨降ればまいねっきゃ。)
このエントリーをはてなブックマークに追加

歩く速さで

以前に書いた知識の集め方 という記事で、「効率的な学習」について意見めいたことを書きましたが、今回はその続きというか補足です。

私がプログラミングを始めたのは10歳くらいのこと。 当時は、何か分からないことに遭遇したら、それに関する情報を集めるだけでも一苦労でした。 なにせ、インターネット接続環境がありませんでしたし、Google もまだ存在してはいなかったのですから。 身近にプログラミングに詳しい人もいなかったため、人に訊くことも能わず。 そのため、一つの問題への取り組みが数ヶ月、時には一年以上に及ぶことも珍しくはありませんでした。 情報源となるのはもっぱら書籍・雑誌ですが、その量や種類も、現在のように充実してはいなかった時代。 (その頃、「コンピュータ」というのはまだまだマイナな趣味だったのです。) 故に、「学習」は常に試行錯誤となり、全然見当違いの方向へ考えを進めては引き返すといったことを繰り返していました。

今思い返してみると、なんと非効率的なやり方。 現在のインターネットでの情報収集を利用した学習と比べると、両者のスピードには徒歩と自動車ほどの隔たりがあるでしょう。 しかしながら、この「歩く速さの学習」の経験の有無は、エンジニアとしての力量に決定的な差を与えるのではないかと考えています。

歩いて目的地へ向かっているときは、好きな時に立ち止まったり、気になる路地を見つけたときにひょいとそこに入ってみることができます。 そうやって、面白そうなお店を見つけたり、道の繋がりに気付いたりした経験のある人も多いのではないでしょうか。 学習の場合もそれと同じで、最短経路からの「横枝」を拡げていくことで、これまで無関係だと思われていた事柄がリンクし、知識に幅が生まれます。 自分のいる場所を俯瞰できるようになり、頭の中に「地図」があがっていく感覚ですね。

ところが、移動 (学習) の速度があがるにつれ、この「横枝」を拡げるチャンスは少なくなっていきます。 自動車で移動する際は路地に入れませんし、列車で移動しているときは駅以外の場所で降りることはできません。 その結果、知識からは広がりが失われ、「地図」というよりは一本の線で綴られた「路線図」のようなものになってしまいます。

ですが、かく言う私も、社会人になってからは、この「効率的」なやり方が学習の軸に……。 やはり、仕事を滞りなく回そうとすると、徒歩での移動には限界があるので、どうしても自動車に頼らざるをえません。 でも、それではエンジニアとしての可能性が先細りになってしまうので、プライベートで徒歩型の学習をして、仕事の方にフィードバックするよう心掛けています。

Narita (道草大好き)
このエントリーをはてなブックマークに追加

ビデオゲームのUI

皆さん、ビデオゲーム (TVゲーム) はお好きでしょうか。 私はかなり好きな方で、休みの日などは一日中やっていることもあったり。 さて、「ビデオゲーム」というと、どうしても格の低い趣味と見なされがちですが、実際にいろいろなソフトをプレイしてみると、いろいろと学ぶ・考えるべき点が見つかります。

特に面白いのがユーザインターフェイス (UI) における工夫です。 ゲームでは「アイテムの選択」や「データの記録」などを何度も繰り返し行うため、これらの操作でユーザにストレスを感じさせるような設計は極力避けなければなりません。 そのためには、項目の配置, 画面遷移, カーソルの移動の仕方, 処理時間の短縮などあらゆる箇所に気を配る必要が出てきます。

例えば、メニューを開くとウィンドウが画面外からスライドインしてくる場合を考えてみましょう。 注意深く設計・実装されたソフトでは、ウィンドウが定位置に止まる前であっても、ユーザはその上でカーソルを動かすことができるようになっています。 逆に、こうした工夫がないゲームでは、ユーザはメニューを開くたびに1~2秒程度操作を中断しなければなりません。 その程度の待ち時間はたいしたことがないように思えるかも知れませんが、ゲーム中にメニューを開く頻度を考えると、プレイ時間全体に対する損失の割合はかなり大きなものになります。

他にも、データの読み込みをバックグラウンドで処理することでシーン切り替えの際のロード時間を短縮する手法など、ユーザに対する「気配り」が見え隠れする部分が多々あります。 ゲームとして長く遊ばれるかどうかは、「ストーリー」や「映像の美しさ」や「システムの斬新さ」だけでなく、こうした開発者の「気配り」の深さ・細かさによって決まることが多いようです。

こうしたユーザのストレスを低減する様々な工夫は、ゲーム以外のソフトウェアやウェブサイトを作る際にも応用できます。 「良いデザイン」に行き詰ったときは、気分転換もかねてビデオゲームをやってみてはいかがでしょうか。

Narita (バイオハザードで学ぶ英会話)
このエントリーをはてなブックマークに追加

知識の集め方

毎週木曜日に開かれる全体ミーティングでは、スタッフが持ち回りで「勉強会」という名目でプレゼンテーションを行っています。 発表の内容はバラエティに富んでおり、「お菓子の作り方」から「インターネットの仕組み」まで様々。 自分が普段触れる機会のない知見に触れることができるイベントであるため、毎週とても楽しみにしています。 その一方で、発表終了後にスタッフが一言ずつ述べるコメントの中で、特に学生からよく出てくる、次のような意見に私は小さな引っかかりを覚えています。

それが何に、どのように役立つかまで話してもらえれば、もっと興味がもてます。

私がこれのどこに引っかかっているのか分かって頂けるでしょうか。 学校や職場で多少なりとも他人にものを教えること、すなわち教育に携わっている方にはピンとくるものがあるかもしれません。

上記の考え方の根元にはおそらく、「学んだことは (そのすべてを) 何かの役に立てたい」という気持ちがあるのでしょう。 そして、その気持ちはともすれば「役に立たない (役に立つという確証がない) ことは学びたくない」という考え方にシフトします。 そこからさらに進んで、話の過程をすっとばして、「結論だけを聞かせて欲しい」という態度に繋がることも少なくありません。

そのような姿勢が、実利を重視した、ドライで合理的な姿勢だと評価されることも少なくないようですが、私はそうは考えません。 何故なら、「考える力」を養うには、多くのモノの見方・考え方に触れる経験が欠かせないからです。 見聞きしたものは、たとえ自分が目的とする事柄に直接の関係はなくとも、その人が何かを考えるための材料としてストックされていくもの。 そして、そうした材料が何かに使えることに「気付く」ことによって初めて、経験が知識として自分の一部になるわけです。 それを集める手間を惜しみ、最短距離で目的とする知見まで一足飛びに到達したとしても、そこからの自分の考えを発展させることは難しいでしょう。 なにせ、材料の手持ちがないのですから。

では何故学生はこうした考え方をするようになってしまうのでしょうか。 個人的に、二つほど思い当たる事柄があります。

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

批判のお手本

高木浩光@自宅の日記

私がよく閲覧するサイトのひとつに、高木浩光@自宅の日記があります。 (この業界の人の間ではかなりの有名ドコロですね。) セキュリティ・プライバシに関する記事が多いのですが、その特徴はなんといっても、未熟・杜撰な技術や論評に対する辛辣な批判・批評。 「バカは死ねと言いたい。」 「儲かるんだからしょうがない。IT弱者から搾取して。」など、なかなかに過激なフレーズが随所に見られます。

筆者である高木氏は斯様に、罵倒ともいえるほど強い調子で批判を展開しますが、ただ声を荒げているだけではありません。 記事の中で、批判の対象と範囲および理由・根拠を明確に示し、必要に応じて技術的・社会的な背景についても詳細に解説してくれています。 同じ対象を批判している別の論者に対して、「その批判は要点がズレている」という旨の批判をするのがしばしば見られるのも、議論の筋道を重視するが故でしょう。 以下に、私が読んで参考になった記事をいくつかあげておきます。

日本のインターネットが終了する日
携帯電話の個体識別番号 (「かんたんログイン」などに使用される) の送信問題について。
オレオレ警告の無視が危険なこれだけの理由
SSL証明書の不適切な運用がもたらす弊害について。
プログラミング解説書籍の脆弱性をどうするか
デタラメなプログラミング技術解説が出版によって広まっている件について。

このような、要点を的確に押さえた切れ味ある批判は、私が範とするところでもあります。

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

拙速を尊ばない

晩夏の駿河湾

プログラミングは非常に専門的な作業であるため、社内の人間であっても、ある人の仕事の内容を正確に理解・評価することは容易ではありません。 そのため、プログラマに対する評価はその成果物、すなわち完成したプログラムの動作や、それができるまでの期間といったものを基準に行われることが多くなります。 そうなると必然的に、指定された要件を満たして「とにかく動くプログラム」を「短い期間」で納品できるプログラマが高い評価を受けることになります。

しかし、動作が同じだからといって、プログラムの「質」が同じだと考えるのは大きな誤り。 何故なら、プログラムの質の良し悪しは、動いているときではなく、何らかの理由でそれが動かなくなったときにこそ問われるものだからです。

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

構造体によるデータ集約

個人的な観測範囲内での話ですが、「プログラマ」と呼ばれる人の中には、自分で構造体 (あるいはクラス) を定義することを面倒臭がり、これをしないで済ませようとする人が少なくありません。 彼らは、本来構造体として集約されるべきデータをプリミティブ (組み込み型) と標準ライブラリなどで与えられたコンテナを組み合わせることで表現しようとします。

例えば、地図上の登録地点の情報を CSV (各列にID, 名前, 緯度, 経度, 解説, … が格納されている) から読み取るコードは以下のようになるわけです。 (csvParseLine は現在開いているCSVファイルから1行分のデータを vector<string> として取ってくる関数だと考えてください。)

class MyApplication {

    //地点データ
    vector<UINT>   m_vID;          //ID
    vector<string> m_vName;        //名前
    vector<double> m_vLatitude;    //緯度
    vector<double> m_vLongitude;   //経度
    vector<string> m_vDescription; //説明

    //地点データの読み込み
    int loadLocationData(){

        m_vID         .clear();
        m_vName       .clear();
        m_vLatitude   .clear();
        m_vLongitude  .clear();
        m_vDescription.clear();

        int nCount =0;

        for (;;){

            vector<string> row =csvParseLine();
            if (row.size < 5) break;    

            m_vID         .push_back(static_cast<UINT>(atoi(row[0])));
            m_vName       .push_back(row[1]);
            m_vLatitude   .push_back(atof(row[2]));
            m_vLongitude  .push_back(atof(row[3]));
            m_vDescription.push_back(row[4]);

            ++nCount;
        } //for (;;)

        return nCount;
    }
};

だからそうじゃねぇだろうが!!

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

Expert of Everything (2)

業務アプリケーションの開発をしていると、売上・入金処理など、お金に関するデータを扱う機会が多くあります。 こうしたデータの取り扱い (税込/税抜の別, 端数の処理など) は、法律や社内の規則により厳密に定められているものが殆どあり、開発者側の都合で決めてよいというものではありません。

現在開発を行っているシステムは、顧客からの入金項目に勘定科目の情報を付加し、外部ファイルへの出力を行う、簿記処理用のモジュールを備えています。 私はこれまで経理・簿記の仕組みについて殆ど何も知らなかったため、このモジュールを作成するためには書籍やウェブなどで勉強をしなければなりませんでした。 しかし考えてみれば、こうした手続きはどの会社でも当たり前に行われているもの。 己の生活にも密接に関係する (私の月給だって、これらの手続きを経て支払われているのですから) 事柄について、自分はなんと無知であったことかと恥じ入ることしきりです。

ソフトウェア開発を生業とする者にとって、「知らなくてよいこと」などというものはありません。 例外は、プライバシーに関する事柄くらいでしょう。 特に身近で、普段から当たり前と思っている事柄ほど、「考えてみるとよく分からない」ものが多いものです。 例えば、自動販売機がどのようにして硬貨を識別しているのか説明できる人はどれくらいいるでしょうか。 私も、「こうなっているのではないか」という推測はできますが、本当のところは分かりません。 (もちろん、偽造硬貨の問題があるので、積極的に公開される情報ではありませんし、その手法もどんどん変化していっていることでしょう。)

世の中、まだまだ不思議がいっぱいです。

Narita (情報蒐集家)
このエントリーをはてなブックマークに追加

乾焼蝦仁

前の記事 (タマネギ消費作戦) で、エビが高くて諦めた「乾焼蝦仁」に改めて挑戦。 今回はいつもより若干、手間がかかっております。

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