[勉強会とオフ会]Embedded Technology 2008 - 11/20(木) (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
1 week, 4 days
ago
permalink
Embedded Technology 2008 の 2 日目。 諸事情により 1 日目のレポートはございませんです。目的は、展示会より基調講演とか特別講演で組込み界隈の情報をおおざっぱに得ること。まぁ興味本位で野次馬しにいったようなもんですな。一応俺は Java 屋さんで組込み業界の知識は浅いんで、このレポートは何時にもましてヘンテコなこと書いてる可能性高いので注意してください。 しっかし、Seasar Conference なんかと比べると会場の平均年齢が高いような……展示会の方は見に行ってないんでわかんないけど、今日 2 つのセッションは 30 代後半〜 40 代前半ぐらいが主軸な感じだったし。30 代前半の人が若く感じる勉強会って何気にはじめてな気がする。組み込み業界って何気に少子高齢化が洒落になってない、とか……? 以下、トークセッションの内容について&毎度のお断り文句。自分の所感・意見と登壇者の発言やプレゼン資料の内容ごちゃ混ぜに書くので、読みにくい点が多々あると思います。日本語崩壊してる部分も多々です。自分用の備忘録的な意味合いの強いエントリなので、そのあたりの読みにくさについてはご容赦願います。 ニコンの最新デジタルカメラを支える先端組込み技術 ニコンのカメラ開発とカメラの組込み技術の歴史・概要について簡単に触れていました。俺はカメラにそんなに興味あるわけじゃないんで、へーって思う内容がたくさんありました。ただ、俺はメカとかファームにはぜんぜん詳しくないのもあり、細かいとこはすっとばし、印象に残った箇所でレポート書いてます。 講演者曰く「せっかくの機会ですので、ニコンのカメラについて少し知って頂こう」とか。ニコンのカメラの歴史つーか半分宣伝も兼ねてるであろうムービー流すとか、うまいなぁーとか思ってしまった。創業 90 年とかすげーなー。 History of camera. カメラの原点は 10 世紀頃に発明された巨大なピンホールカメラであるカメラオブ・スキュラ。原理自体は紀元前 4 世紀にあったとかなんとか。現代のカメラの原型は、ルイ・ジャック・マンデ・ダゲール - Wikipedia なる人物が、タゲレオタイプ(銀板写真)を発明した事に端を発しているらしい。写真美術館へようこそ (講談社現代新書) に書いてあったっけなぁ、そういえば。 19 - 20世紀末にカメラはレンズ・フィルムともに急激な進化を遂げる。ポイントはロールフィルムを使用するタイプが主流となっていったこと。コレによりカメラの取り回しがすごい容易になったんだとか。で、今のカメラの原型はこの時点でほぼ固まった、とかなんとか。 ちなみに Nikon のレンズが Canon のカメラに使われてた時期もあった、ってのはその筋では割と有名なエピソードなんだとか。へぇー。 ソニーマビカ(1981)の発売。電気的に写真を保存する技術。デジタルカメラの兆し。コレはカメラ業界に激震が走ったそうだ。で、ニコンもそれに続いて、まずフロッピーに記録するカメラ出してたりとかの歴史があるそうで。 ただ、初期のデジカメはフィルムと比べるとまだまだ画質が悪く、100 万画素を超えることが課題とされていた。'97 年にニコンは 100 万画素を超えるものをなんとか出せるようになり、そんでもってこの頃からデジカメ市場が本格的に立ち上がり始めた。で、この辺から技術革新がバシバシ起こり、時代のニーズに応じて多様化・洗練化がすすんでいる。ケータイ含む←いまここ 写真の持つ社会的な影響力は計り知れないものがあったし、それはこれからもそうは大きく変わらんだろうねーみたいな。 Market マーケットの現状。あんまり興味ないので聞き流してたところ。デジカメの市場は伸び続けたけど、今日でもフィルムカメラ愛好家がゼロになったわけじゃない、ってのが面白いねーとか。今んとこ一眼レフが 1 割で残りがコンパクトカメラ。コレはフィルムカメラの時代もおんなじ構成比だったとか。各社年間 10 機種ぐらい出してるとか結構競走激しいのねーとか。ワールドワイドで見ると日本以外の北アメリカとか BRICs の比率が大きいんだねとか。ふーん。 短いライフサイクル……モデルの更新が半年- 1 年、長くても 2 年のように、フィルムカメラだと 5,10 年だったのを考えるとすごい早くなった。低価格化……すっごい勢いで安くなる。高機能化-高画素化。高画素化競争はちょっと落ち着いたけど今度は差別化・小型化・軽量化の波が。参入障壁の低さ……コンパクトカメラは電子部品のかたまりなので、部品の寄せ集めでなんとかなっちゃう部分もあったりするため、台湾・中国も脅威になるかも的な話。ただし、一眼レフはレンズがあるからちょっと難しいかもみたいな。 Digital Technology 映像素子ーセンサーの進化の歴史。CCD から CMOS ...
[勉強会とオフ会][Java][Flex]知っ得 納得 Webフレームワーク 第一回に行ってきた。 (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
1 week, 4 days
ago
permalink
11/5 に 株式会社フルネス で行われた勉強会に行ってきました。懇親会も行きたかったんだけど諸事情により行けずじまい…… S2Flex2 - AMF3 Gateway with DI Container id:c9katayama によるトーク。 S2Flex2 とは? クライアント側の Flex からサーバ側の Seaser2 上コンポーネントと通信・連携を行って呼び出すためのフレームワーク。通信プロトコルは HTTP(S) で、通信フォーマットには AMF というものを使用する。jdk1.4 以上で動作するけど、アノテーションなどなどの関係で jdk1.5 以降をフツウは使用する。 ちなみに、個人的にフレームワークの概要図が分かりやすくて良かったなーと思いました。 Flex 2 とは。Adobe が提供している RIA の環境を総称して呼んでいるもの。実は俺自身どっからどこまで何を Flex と呼ぶのかは良くわかってなかったりする。Flex 2 の動作環境は Flash Player9 以降。Flex のバージョンはもうすぐ Flex 4 が出るみたいなんだけど、大枠は Flex 2,Flash Player 9 から変わってないみたい。API とか機能の追加とか色々行われてはいるんだけども。 Flex 2 のデモとしては Flex 2 Style Explorer など。 MXML の概要について。コレは XML というか HTML のようなもので UI を書くためのもの。見た目に関しては CSS で切り替えたり、スキンといったものでキレイに出来たりする。 ActionScript 3 の概要。ECMAScript 準拠で javascript っぽい言語。でもクラスとか ...
[書籍感想]Googleを支える技術 巨大システムの内側の世界 (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
2 weeks
ago
permalink
20% ルールやらおかし無料配布やらページランクがどーのやらと話題にことかかない Google について様々な角度から述べているスゴイ一冊。本書は、Google が公開している論文やデータを、著者の見解や分析を交えつつまとめ直したもの。カバーしている範囲はハード面からソフト面まで多岐に渡り、抽象度も低いとこから高いとこまで触れているので、読みこなすのはかなり大変だと思う。実を言うと俺自身がそうで、半分も理解出来ているかどうか……自信がない。そのため、著者の幅広い見識と卓越した文章構築技術には畏敬の念を禁じ得ないです。 本書が触れている範囲を区分するとおおよそ 4 つ。より良い結果を得るための検索エンジンの仕組み、システムがブッとんだり停止しないようにするための分散技術、データセンターとか電力がどうとかの物理的な側面について、一つの生態系と思えるほどの自律的な要素を持つ開発体制。いやもう、膨大な文献を漁っておいてなお、よくこの厚さにまとめたよなぁ、と驚愕する他ありません。 改めてこの本を読むと Google のスゴさが良くわかる。検索エンジンの仕組みや分散技術の解説で出てくる一つ一つの概念/技術/思想は、そのテの大学出てれば誰でも知ってる単純なものが結構出てくる。その、個々はシンプルなモノたちをこうも圧倒的なスケールで組み上げていくと、もうバケモノとしか言いようの無い代物が出来てしまうのか、ってことにもうホント驚くしかない。 そういう意味で、Google はコンピュータサイエンスの最先端を理論面でも実践面でもいってるんだろうな、と思う。情報科学に限らず、まぁ科学ってヤツは何でもそうだと思うんだけど、地道な積み重ね―それもガイキチ染みた勢い―でここまでの高みに至れる、ってのは……驚愕の一言です。 Google ってスゲーよね、って言われるけど実際どうなん? と思う人にオススメの一冊です。是非、コンピュータサイエンスの息吹をご堪能あれ。 Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) 作者: 西田圭介 出版社/メーカー: 技術評論社 発売日: 2008/03/28 メディア: 単行本(ソフトカバー)
[勉強会とオフ会]World Usability Day 2008 に行ってきた (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
2 weeks, 3 days
ago
permalink
先日、HCD-Net 人間中心設計推進機構 主催の World Usability Day 2008 Japan (概要(PDF))に行ってきました。主題はユーザビリティ(Usability)なるもの。日本語だと上手い訳はどうなるかわからないけど……HCD-Japan のページだと人間中心設計って言葉を使ってるね。日本でのユーザビリティの研究分野としては人間工学・認知科学・認知心理学あたりになるのかな? ただ、脳科学・心理学・言語学にも関連があったりと、学際的な側面が大きくもある。とはいえ、日本じゃユーザビリティの研究はまだまだ盛り上がってるとは良いがたい状況でもあるらしい*1。そういやぁ複雑系の領域もそんな感じな気はするね。 それはさておき。俺がこの勉強会に参加した経緯についてちょっと書いておく。現在、俺は要素技術として Flex + Java な Web アプリケーションに興味を持っていて、ちまちまと調べたりしている(最近だと yui-frameworks とか)。Flex とか Silverlight とかって、単純に見た目だけの話だと、今までブラウザだけでやってた Web アプリケーションがちょっと便利になったよね程度の話になりがちなんだけど、もうちょっと奥深いものに結び付けられる気がするんだよね。すっごく端的な言い方すると、最近あちらこちらでチラホラと UX(User Experience) なる怪しげなバズワードっぽい何かを流行らせようと必死な人たちの気持ちわかるなーみたいな。 で、その辺を研究することで、業務アプリケーションの領域でも何か活かせる知見が得られるのではないかなーと。お客様が仕事をたのしくやれる業務アプリケーション作りに何か役立つことが得られないかなー*2、ってのが、この勉強会に行こうと思ったきっかけです。 以下、トークセッションの内容について&毎度のお断り文句。自分の所感・意見と登壇者の発言やプレゼン資料の内容ごちゃ混ぜに書くので、読みにくい点が多々あると思います。日本語崩壊してる部分も多々です。自分用の備忘録的な意味合いの強いエントリなので、そのあたりの読みにくさについてはご容赦願います。 World Usability Day のご紹介と海外イベント参加報告 World Usability Day とは、ユーザビリティの概念を世界に発信していくことを理念としている組織 HCD-Net のイベントの一つ。2008 年の抱負 に書いてあるようなことを語っていました。この分野の研究は、今のところ欧米が中心ではあるが、今後日本でも積極的に活動していこうと考えており、この度の開催に至った、と話してました。 また、CHI2008(イタリア)とUserFriendly2008(中国)など、世界各地でこんなフォーラムやカンファレンスがありましたよ、と行ってきました&こんなことがありました、な参加報告も行われました。 「高齢者を対象とした駅の案内表示のユーザビリティ調査」 産業技術総合研究所 北島宗雄 先生 SHIBUYA とか TOKYO 駅はもはや攻略本が必要なダンジョンだろ常識的に考えて……に対して JR 東日本と産業技術総合研究所(以下、産総研と表記)がガチに取り組んだ研究成果の発表。渋谷・東京・新宿駅マップはネットでネタにされる程複には面妖な能力を有しているのは皆さんご存知の通り。【2ch】ネタちゃんねる m9( ゜д゜)っ もう迷わない!ダンジョンのような駅もこれさえあれば! とか。若者ですらキツイのにお年寄りにとってはもっと難易度高いのは明白。ではどうすればいいのだろう? ってところを人間工学的な方面からアプローチをしてみた、ってのがこの講演の概要。 まず、東京駅のトイレに行きたくなったときを想定して駅の案内表示を見たらどう思う?―コレが言われてみれば確かに分かり辛いw―を切り口に、ナビゲーション支援の局面についての解説があった。ああいった案内表示―ナビゲーション支援―は、目的地への誘導だけでなく、情報・物理空間内への移動支援機能も併せ持っている。つまり、案内表示板は単に状態の途中表示だけじゃない、ということ。このため、初期状態から達成条件にたどりつくためには、いつ誰に何をどんな風に情報を提示するか? という設計が重要になる、とのこと。 Model Human Processor(MHP) の解説。1983 年頃の論文で、人はどのように情報処理を行うか? についてのモデルを論じているもの。すっごく端的に言うと、人間が、何かをしたいと考えて、情報を取得→保持→解釈して、リアルに行動決定するまでには、意外と複雑な認知プロセスを行ってますよ、と言ってるものらしい。 作業記憶と長期記憶の特性。作業記憶は、認知行動を実行するために必要な情報が一時的に格納される場所。マーケティングとかの分野でも出てくる「人間は一度に覚えられるキーワードは 3 つ、気合で 7 つ」ってヤツですな。長期記憶は、知識として定着したもの。重要なのは、作業記憶がキーとなって長期記憶とのマッピングが出来ないと、知識が活用されない、っていう点のようだ。 あと、限定合理性と最大化原理にも話してた。けどまぁ省略。 とゆーような話を踏まえて、高齢者の認知行動特性に基づく駅案内表示の評価。駅案内表示板は、駅側からみると完全で正しく過不足無い情報は提供されている(あのすっごい三次元構造を持った図……例えば 東京メトロ - ...
[書籍感想]チーム・バチスタの栄光 (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
3 weeks
ago
permalink
俺はこれまで一般書のベストセラーってほとんど手を出してなかったんだけど、タクサン売れる本というのはそれだけ面白いということの証左なんだなぁ、と思わせてくれた一冊。食わず嫌いは良くないね。文字ベースのエンターテイメントとしては、極上の部類に入るんじゃなかろうか。なんやかやとイベントが発生しつつ、読後に少しばかりのモヤモヤ感を残しつつハッピーエンドで締めくくる。そういった王道の展開を、高難易度の外科手術―バチスタ―をテーマに高い完成度で書き上げたところが評価高い。 物語は、とある大病院で窓際ってる主人公へ病院長が直々に「貴様にひとつ、重大な任務を託したい」と仕事を依頼するところから始まる。その病院では、連戦連勝だったバチスタ手術のチームが三連続失敗を遂げていた。エースオブエースの人員で構成されるチームでの不可解な連続死。主人公はその実態を探るため、予備調査名目・実質内偵を依頼されるのだが……事故か? 殺人か? 主人公もまた何時しかその構図の中に組み込まれていく。俺はミステリーとやらを全然読んだことが無いんだが、こういうのはいわゆるミステリーというらしい。 それにしても面白いのは登場人物たちがことごとく人間味に満ちた描写をされているところ。権力構造・人間関係構造に敏感なクセに―だからこそ、かもしれないが―自ら望んで閑職に志願した主人公・田口を筆頭に、いろんな意味で濃いキャラクターが目白押し。また、医者というのは何時いかなるときも完璧・完全な技術者ではない、と言うメッセージが込められているのではないか、と勘ぐりたくなるほど泥臭い人物像がこれでもかというほど詳細に書きたてられている。 上記の解釈は、医療崩壊という現状がある以上、まぁあながち間違ってもないと思うけど、本書は「小説は小説」として楽しんだ方が良いと思う。主人公・田口の仙人っぷりとか、白鳥のハイパー空気読まない調査術とか、純粋にたのしく読まないと損でしょう。この本読んだ人は、さぞかし田口センセと白鳥あんちくしょうコンビの続編読みたいと願うだろうこと間違いない。実際、続編出ちゃってるし。 しかし、この人間関係複雑模様+謎解き要素のあるシナリオってどうも既視感あるなぁ、と考えて脳裏をよぎったのはインフィニティシリーズ。Ever17 とか 12Riven とか。あのテのノベルゲーは世間的にはギャルゲ類としてやや肩身が狭い領域なんだけどね。俺的には、シナリオの完成度という点ではどっちも甲乙付けがたい。 そんな訳で、世の中には面白い本ってのはまだまだタクサンあるんだなぁ、と思わせてくれた一冊でした。 チーム・バチスタの栄光 作者: 海堂尊 出版社/メーカー: 宝島社 発売日: 2006/01 メディア: 単行本
[blog論]わたしのはてなダイアリー使用法 (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
1 month
ago
permalink
人によって blog との付き合い方や距離感は十人十色だろうし、別にそれでいいだろうと思う。なので、blog 論みたいなのってアンマリ意味無いかもなぁ、と思いつつ、自分がどんな風に blog のエントリを書いているかをちょっと整理してみたいと思う。 テキストエディタで書く……前に 技術ネタかオフレポか思想みたいな話とか、テーマ設定ごとに若干工程が異なるのだけど。おおよそ共通しているのは、テキストエディタを立ち上げてフレーズをぽんぽんと打鍵していくことから始まる。で、この段階でエントリのタイトルを決定する。エディタの一行目に、このエントリだと「*[blog論]わたしのはてなダイアリー使用法」と、はてな記法込みで書いて、一回デスクトップに保存する。コレで、デスクトップに「[blog論]わたしのはてなダイアリー使用法.txt」ってのを一回作ります。 タイトルは一応仮決定だけど、だいたいこの段階で決めたものがそのまま go になることが多いかな。文言調整したり、長いから短くしよう、とかはモチロン文章見直してる段階で発生するんだけど。 デスクトップ画面はこんな感じです*1。赤線で囲った部分は、下書きの山です。いわゆる「あとでかく」状態で、中身は、書きかけの文章だったり、ワンフレーズが箇条書きみたく書き連ねてるのまで色々です。まとめ切れずにお蔵入りしてるのもありますw ちなみにテキストエディタは秀丸。 アレゲなアイコンがあるけど、あんまりキニシナイでねw テキストエディタで書く理由 はてなダイアリーのエディット画面で何故書かないのか。これは……今のスタイルを変える必要性を別に感じてないというか、変えるのメンドイーとかw そんな理由だったりする。 あとは、見直しながら書くのはやっぱテキストエディタ使った方が良いなぁ、とも思う。 ローカルに保存してないと、なんとなく不安、ってのもある。以前、たまたま ust で、とある人がはてなダイアリーのエディット画面に直で blog 書いてるの見たことがあるんだけど、結構衝撃受けました。その時に「ブラウザで書くの怖くないですか?」と聞いたんだけど「はてなは下書き保存もあるし、Firefox はブラウザがダウンしても書きかけの文章保存してくれてるから、アンマリ怖くないですねー」みたいな発言をしていたのが印象に残っている。 なんちゅーか、blog との付き合い方って人それぞれなのねぇ、と思った瞬間でもありました。 テキストエディタで書く それはさておき、上に載せてるデスクトップ画像のテキストエディタ画面上ではそれなりに文章としてまとまってる部分と、ちょいちょいと書いた文章の切れ端みたいなのが混在してるのが見えますね。ここから、ちょいちょいと書いた文章の切れ端を、文章形態に編集していきます。その途中で、なんか書きたいことを思いついたらパッとエディタの下の方にメモって、また文章形態編集作業に戻る、ということの切り替え・連続で blog のエントリは少しずつ形になっていきます。 基本路線は、まず始めにフレーズをぽんぽんと出して、タイトル決定して、んで文章書き始める、て感じですかね。 ただ、その路線から外れることもあります。冒頭からババーっ書き始めて、その途中で思いついたフレーズをエディタの下のほうに一度ササッと書いて、また文章を書きに戻る、なんて書き方することもする。頭の中にフレーズが溜まっていて、さっさと書き出したい衝動が高まってる時はこういう書き方になるかな? はてな記法の一部はこの段階で入れます。「*」「**」「-」「+」やリンク、書籍感想なら ISBN 記法の detail など。この辺りのシンプルなヤツは、文章書きつつ適宜テキストエディタ上で入れていきます。文章の装飾……太字化・色付けは後回し。 エントリが書き終わったら、一度テキストエディタ上で最初からざっと見直します。文章全体のバランスや、段落の位置や文章量の調節を行います。段落一つは、エディタ上の 80 文字折り返しで 4-6 行分が目安です。それを越えてるなぁちょっと多いかなぁ冗長だなぁ……と思ったら、文章を移動したり要約し直したりバッサリ切ったりします。「……をできるようにする」を「……ができる」や「……をする」に変えたり。 その延長線上で、言い回しを変えたりもしますね。オチャラケたいなぁ、と思ったらムダに凝った言い方にしたり、とか。「調子が良くなった」を「誠に重畳な様子に御座りまする」とか。堅苦しくマジメに語りたい場合は「―です」「―だ」等の統一感の調整をするけど、面倒でやらん事の方が多い気がする。 はてなダイアリー上で最終調整 文章が書き終わったなーと思ったらはてなダイアリーの日記を書く画面を開きます。で、コピペをしてプレビュー。プレビュー画面で上から文章を見直しながら、逐次編集画面に戻って細々とした修正を入れていきます。誤字脱字・ヘンな日本語になってるとこ修正・はてな記法のズレ―引用記法・スーパーpre記法(シンタックス・ハイライト)が閉じてない、とか―をしてきます。 太字や色付けもここでやります。いやまぁ、font-weight とか color とか覚えるのがダルくてですね…… 画像のアップロードもこの段階です。「はてなフォトライフに画像を投稿」をすると、自動で f:id:kagamihoge:20081028083244j:image(:は小文字)を編集画面の文章中に入れてくれるので、それを使います。 コレで「保存する」を押して作業完了、ですかね。 あとは、技術ネタかオフレポか思想みたいな話とか、テーマごとに書き方や時間のかかり方は変わってきます。 書籍感想 まず、書籍感想のエントリはおおよそ 30 分です。長くて 1 時間ですね。最初はもっと時間がかかっていたんだけど、最近はおおよそ 30 分で終わることが多くなってきました。 最近書いた書籍感想…… モモ、3分間 ネットワーク 基礎講座、アメリカの高校生が読んでいる資産運用の教科書、このあたりの文章量で約 30 分ですな。 ただし、プログラミング Microsoft ASP.NET 2.0 (マイクロソフト公式解説書) みたいに超ブ厚いのは例外で、このテのブ厚い技術書の書籍感想の書き方はマチマチです。 みたいに、ひとり wiki ...
[プログラムの設計]わたしがアルゴリズムをまなぶ理由 (1)
share
digg
by
kagamihoge (0)
on
目指せ一人前のプログラマ (0)
1 month
ago
permalink
先日、何時ものように地元の最寄り駅に帰ってきて、駅前のタクシー乗り場を横目に帰路に着こうとしたとき「おやっ?」と思った。最近整理されて稼動し始めたタクシープールはこんな感じになっている。 某駅のタクシープール タクシーは 赤の番号順で、じゅんばんこにお客さんが待っているタクシー乗り場へ出て行く。あとから来たタクシーは、各々いちばん空いてる列に並んでいく。こうすることで、せまっくるしい駐車スペースに出来るだけ多くのタクシーが待機することができ、かつ、ソレナリに公平な順番でタクシーはお客さんを乗せることが出来る。 家に帰りながら↑な感じの図を頭の中で思い浮かべて「なるほどねぇ……」と浸っていたんだけど、更に図をもっと極端に簡略化してしまうと、こういう風にも簡略化できちゃうなぁ、と思った。 某駅のタクシープール、実は一列 タクシープールを見てると、最初に来たタクシーの運ちゃんが最初にお客さんを乗せられるようになってる。ってことは実はタクシーの列は一列なんだなぁ、と。しかし、物理的な駐車スペースは四角い土地だから、タクシーの列も一列にするのは難しい。そこは一工夫して「見た目四角、だけど一列」になるようにしている。これで、四角い土地にタクサンタクシーが待機できる。タクシーの運ちゃん同士、順番でケンカにならないように良く出来てるなぁ、とか余計なことも色々思ったんだけどまぁそれはそれとして。 某駅のタクシープールはキュー 「これってキュー(queue)だよなぁ」と。アルゴリズムの本とか、ネットワークの本とか、OR(オペレーションズ・リサーチ)とかの本で良く出てくる、キュー。タクシーをいっこのパケットみたいに考えてるワケです。 定番なアルゴリズムって、実はふだんのプログラミングだけでなく、実生活にも良く出てくるものがちょくちょくあるんですよ。おそらくタクシー乗り場作った土建屋さんたちの建築業界にもキューみたいな定番設計集みたいなのはあると思う。だからこういう作りになってるんじゃないかなぁ? と思うし、定番設計集が無かったらすっごい苦労してたと思う。 まぁ、もしかしたら設計士の知り合いのネットワーク屋さんが「キューでおk」とアドバイスしてくれたのかもしれないけどw けれども、アルゴリズムの勉強は、特定の問題についての実装法を勉強することではない。 アルゴリズムデザインの夢 - 2008-10-25 - きしだのはてな より抜粋 っていうのはそういうことなんだと思う。 けど、アルゴリズムなんかの勉強って有り難味が分かりにくいんだよね。 大学は奥義を教えてくれるが、それがなぜ奥義なのかは教えてくれない 学生時代にこんな皮肉を聞いたことがあるんだが、さもありなんだなぁ、とw 定番アルゴリズムとかコンピュータ・サイエンスとか、そのままじゃクソの役にも立たないんですよ、いやマジで。 が、実際には現実で奥義を使うべき時があるからこそ「定番アルゴリズム」なわけで。ちょっと良い例えが出てこないんだけど、俺はツマランツマラン言われる業務アプリのプログラミングの下請の仕事がいちばん長いんだけど「お、これはあの定番アルゴリズムでいうところのアレだなぁー」みたいに思うことはちょくちょくある。勘違いしてほしくないのは、ライブラリとして整備されたキューのクラスを使うとかそういうレベルではモチロン無いです。 大学で定番アルゴリズムとかを勉強してたのはもう 10 年は前になるけど、最近やっとこ大学でコンピュータ・サイエンスをカジっといて良かったわーと思うようになった。それなぜ? ってのは……ちょっと上手く文章に出来ないんだけど、タクシープールの例みたいな感覚です。なので、イマイチ文章に落とし込めない…… 奥義を現実の問題に落とし込むのは大変 「奥義」を現実の問題に対する解として落とし込むのはすっごい大変なんですよ。最近だと F1日本GP2008@富士スピードウェイが情報工学的な意味で相当すごかった - GRANADA Hatena @ sotarok が良い例かな、と。これって根本的な問題は↑のタクシーの例とアンマリ変わらないと思う。モチロン、F1 というハイパー大規模イベントに対抗するには、向き合わにゃならん問題はもっと莫大なものになるんだけどさ。 けど、余計なものを削って削って根本的な問題って何なの? ってことを考えていくと、割とシンプルなモデルになっちゃったりもする。モデリングとか見える化とか、そんな感じなんじゃないかな、と思う。実際にそーいう仕事はしたことないけどw 富士スピードウェイの例もそうだけど、当たり前のことを当たり前にやる―フツウのことをフツウにやる―のは大変だったりする。で、その大変をナントカカントカするためには定番アルゴリズムみたいなのが何気に有効だったりする。で、世の中のエライ人たちは定番アルゴリズムみたいなカタチで、ナントカカントカする方法を一般化・抽象化してくれてるわけです。が、一般化・抽象化されてると今度は「何それよくわかんねぇ」「それどう使うの?」みたいな話になるわけで。 そこのギャップを埋める方法は俺には妙案は無いけど、ここはもう「奥義って何で奥義なの?」って考えないとダメな部分はあるよなぁ、とも思います。 「ファインマン物理学を読む」とか「ソフィーの世界の世界」みたいに、「アルゴリズム・デザインを読む」のような本が必要なんじゃないかと思う。 アルゴリズムデザインの夢 - 2008-10-25 - きしだのはてな より抜粋 ある分野ではトーゼンの理論が別分野に活きることも ここから、話はちょっと別の方向に飛んでいきます。 最近 ウィキノミクス マスコラボレーションによる開発・生産の世紀へ を読み出してるんだけど、本の最初の方で、ある金鉱山がある方法で再生を遂げた例が載っていた。詳細は省略するけど、すっごく端的に言うとネットで別分野の人間にヘルプを求めたんです、電車男が「めしどこか たのむ」なノリで。 おもしろいのは、鉱山とはナンも縁が無い人たちの意見によって再生を成し遂げた点。俺にはそれが、規模は違えど、タクシープールでキューを見たようなノリに近く見えた。ある分野では当たり前のことが、他の分野に活きることって結構ある気がするんですよ。OR とかロジスティクスとか言われてるのも元々は兵站から来てるしね。 で、今はネットによって情報だけはカンタンに伝えられちゃうから、ネットワーク屋さんが土建屋さんの設計にアドバイス(たとえば「タクシープール? キューでおk」)、みたいなことはこれから増えてくのかな、とか思う。すごいマッシュアップ、みたいな感じ? だから、俺は定番アルゴリズムみたいな「ある分野でのキホン」を学ぶ意味はこれからもっと重要性が増していくと思う。俺がアルゴリズムをまなぶ理由(今勉強中なワケではないけど)は、そういうことだと思う。フツウのプログラマがフツウに生きていく、って、もしかしてそういうことかな? ってモヤモヤと感じる。 無論、ソレによって既存の分野がカンタンにひっくりかえったりしちゃう問題もあるんだけど…… ウィキノミクス マスコラボレーションによる開発・生産の世紀へ がまだ途中読みなのでこの辺でおわり。