個人的な観測範囲内での話ですが、「プログラマ」と呼ばれる人の中には、自分で構造体 (あるいはクラス) を定義することを面倒臭がり、これをしないで済ませようとする人が少なくありません。
彼らは、本来構造体として集約されるべきデータをプリミティブ (組み込み型) と標準ライブラリなどで与えられたコンテナを組み合わせることで表現しようとします。
例えば、地図上の登録地点の情報を 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;
}
};
だからそうじゃねぇだろうが!!
業務アプリケーションの開発をしていると、売上・入金処理など、お金に関するデータを扱う機会が多くあります。
こうしたデータの取り扱い (税込/税抜の別, 端数の処理など) は、法律や社内の規則により厳密に定められているものが殆どあり、開発者側の都合で決めてよいというものではありません。
現在開発を行っているシステムは、顧客からの入金項目に勘定科目の情報を付加し、外部ファイルへの出力を行う、簿記処理用のモジュールを備えています。
私はこれまで経理・簿記の仕組みについて殆ど何も知らなかったため、このモジュールを作成するためには書籍やウェブなどで勉強をしなければなりませんでした。
しかし考えてみれば、こうした手続きはどの会社でも当たり前に行われているもの。
己の生活にも密接に関係する (私の月給だって、これらの手続きを経て支払われているのですから) 事柄について、自分はなんと無知であったことかと恥じ入ることしきりです。
ソフトウェア開発を生業とする者にとって、「知らなくてよいこと」などというものはありません。
例外は、プライバシーに関する事柄くらいでしょう。
特に身近で、普段から当たり前と思っている事柄ほど、「考えてみるとよく分からない」ものが多いものです。
例えば、自動販売機がどのようにして硬貨を識別しているのか説明できる人はどれくらいいるでしょうか。
私も、「こうなっているのではないか」という推測はできますが、本当のところは分かりません。
(もちろん、偽造硬貨の問題があるので、積極的に公開される情報ではありませんし、その手法もどんどん変化していっていることでしょう。)
世の中、まだまだ不思議がいっぱいです。
前の記事 (タマネギ消費作戦) で、エビが高くて諦めた「乾焼蝦仁」に改めて挑戦。
今回はいつもより若干、手間がかかっております。
余っていたタマネギを使って乾焼蝦仁でも作ろうかと思ったのですが、ヨークベニマルに行ってみたら、エビがなかなかのお値段。
そこで予定を変更し、ハンバーグを作ってタマネギの消費を図ることにしました。
自分が作ったソフトウェアやサービスなどを、他人に理解し、使ってもらおうとするならば、それについてきちんとした説明をすることが必要です。
特に、一般ユーザ向けの説明であれば、専門用語の回避、細部の省略、グラフ・図の多用などといった、分かりやすさのための工夫が欠かせません。
競合するの商品との差別化を図るため、パッと見で興味を惹くことができるような個性的・奇抜なデザイン、あるいは多少の誇張やイメージの演出などといった行為が求められる場合もあります。
そうした「分かりやすい」説明を行うことは、自分たちの知識・技術を商品として提示し、売る立場にある技術者にとっても必須のスキルだと言えるでしょう。
しかし、その一方で、私はこの「分かりやすさ」を強く求める社会の在り方に、少なからぬ不安を抱いています。
今日は北塩原村にある会津五薬師のひとつ、北山薬師を訪ねてきました。
本来手間が掛かったり、難しかったりする事柄が、ちょっとした工夫などで簡単に行えてしまう、いわゆる「裏技」。
最近では、テレビや書籍、そしてネット上に、そうした裏技に関する情報があふれています。
この手の情報は需要も高く、「○○を△△する、たった□つの方法」といったタイトルが冠された本やブログエントリなどが人気・注目を集める傾向があります。
しかし世の中、そんな「うまい話」はそうそう転がってはいません。
そうしたノウハウの殆どは、実際に試してみると思ったほどの効果がなかったり、内容が曖昧だったり、ごく一般的な事柄の言い換えに過ぎなかったりと、およそ実用に耐えないようなものです。
それなのになぜ、こうした「裏技」の情報は今日もまた絶えることなく出回り続けているのでしょうか。
プログラマに向いている人と、そうでない人にはものの考え方に大きな差があると感じています。
「では、具体的にどこが違うのか」ということについて、日頃から色々と考えているのですが、最近、面白い記事を読みました。
表にアルファベットや数字が並んでいる4枚のカード。
【母音のカードの裏はいつも偶数】がホントだと確認するには最低どのカードをめくればいい？
この問題ではだいたい3/4の人が間違ってしまう。
ところが…
こういう4枚のカードで
【「18歳未満は飲酒禁止」に違反していない】ことを確かめるにはどのカードをめくればいい？
この問題だと、正答率がほぼ全員になってしまう。
論理的には等価な問題であるにも関わらず、「身近な物事」による比喩が行われると正解率が上がるというのは、なかなかに興味深い現象です。
そしてまた、この記事はプログラミングが不得意な人が抱える「ものの考え方」の問題点を端的に表しています。
日本経済が「不景気」であると言われ、かれこれ10年以上。
事実、それ以前の状況と比較すると、企業活動は収益が上がらず、就職率も低くなっています。
人々は毎年「今年こそ景気が上向いて欲しい」と、半ば祈るような気持ちで経済の先行きを展望しているのでないのでしょうか。
そんな状況で、こう言うのも気が引けるのですが、私個人としては、日本では「景気が良くなる」ということはもうないだろう、と見ています。
そもそも、日本の産業・経済というのは既に発達しきっているのではないでしょうか。
生産力は既に過剰で、そこに住むことのできる人間が生きていくのに必要な量を遥かに上回っています。
この状況において、さらに経済を活発にしようと製造や消費を増大させようとしても、上手くいくはずがありません。
身体のできあがった成人が、さらに身長を伸ばそうとしてドカ食いしたところで、肥満になるか、体調を崩すのがオチです。
また、インターネットをはじめとした情報技術の発達によって起きている、生活スタイルや嗜好の多様化も無視できない要因です。
それ以前の社会では消費者の嗜好のばらつきが (現在と比較して) 少なかったため、供給側は、大多数に好まれるモノをこぞって造っていました。
つまり、レートの高い「メジャ」なターゲットを狙うのが最も効率の良い商売だったわけです。
しかし現在では、あらゆる消費の嗜好が多様化し、消費者の層が分散してしまったため、すべてのターゲットが相対的に「マイナ」になってしまいました。
いまや、「これさえ作れば万人に売れる」というメガヒット商品を開発するのは非常に困難です。
従って、これからの「商売」は、群集としての消費者ではなく、自分たちが提供する商品を理解・支持してくれる個々の顧客を念頭において行うのが原則になるでしょう。
もちろん、それは経済成長期のような「どんどん作れば、どんどん売れる」といった華々しいものではありません。
しかし、それこそが真に「豊かな生活」を支える経済の在り方なのではないか、と私は考えています。
月曜日は有休を貰って、運転免許証の更新手続きへ。
その他、ガス機器の点検をしてもらったり、台所の掃除をしたりして午前中を過ごしたのですが、午後は思いのほか時間が空いてしまいました。
天気も非常に良かったので、どこかへ遊びに行こうかと Google Maps で付近を探索したところ、一箕町松長の東の方に「戸ノ口堰第二発電所」なるものを発見。
発電所マニアとしては、これを見逃すわけにはいきません。
早速、原付に乗って突撃。
