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

知識の集め方

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

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

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

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

批判のお手本

高木浩光@自宅の日記

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

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

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

拙速を尊ばない

晩夏の駿河湾

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

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

構造体によるデータ集約

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

例えば、地図上の登録地点の情報を 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;
    }
};

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

Expert of Everything (2)

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

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

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

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

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

乾焼蝦仁

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

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

タマネギ消費作戦

余っていたタマネギを使って乾焼蝦仁でも作ろうかと思ったのですが、ヨークベニマルに行ってみたら、エビがなかなかのお値段。 そこで予定を変更し、ハンバーグを作ってタマネギの消費を図ることにしました。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

本物とは何か

自分が作ったソフトウェアやサービスなどを、他人に理解し、使ってもらおうとするならば、それについてきちんとした説明をすることが必要です。 特に、一般ユーザ向けの説明であれば、専門用語の回避、細部の省略、グラフ・図の多用などといった、分かりやすさのための工夫が欠かせません。 競合するの商品との差別化を図るため、パッと見で興味を惹くことができるような個性的・奇抜なデザイン、あるいは多少の誇張やイメージの演出などといった行為が求められる場合もあります。 そうした「分かりやすい」説明を行うことは、自分たちの知識・技術を商品として提示し、売る立場にある技術者にとっても必須のスキルだと言えるでしょう。 しかし、その一方で、私はこの「分かりやすさ」を強く求める社会の在り方に、少なからぬ不安を抱いています。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

北山薬師

今日は北塩原村にある会津五薬師のひとつ、北山薬師を訪ねてきました。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加

近道を求めない

本来手間が掛かったり、難しかったりする事柄が、ちょっとした工夫などで簡単に行えてしまう、いわゆる「裏技」。 最近では、テレビや書籍、そしてネット上に、そうした裏技に関する情報があふれています。 この手の情報は需要も高く、「○○を△△する、たった□つの方法」といったタイトルが冠された本やブログエントリなどが人気・注目を集める傾向があります。

しかし世の中、そんな「うまい話」はそうそう転がってはいません。 そうしたノウハウの殆どは、実際に試してみると思ったほどの効果がなかったり、内容が曖昧だったり、ごく一般的な事柄の言い換えに過ぎなかったりと、およそ実用に耐えないようなものです。 それなのになぜ、こうした「裏技」の情報は今日もまた絶えることなく出回り続けているのでしょうか。

>> 続きを読む
成田
このエントリーをはてなブックマークに追加
ページ: « 0 1 2 3 4 5 6 7 8 9 10 11 12 13 »