トップページ | 全エントリー一覧 | RSS購読

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

プログラマは永遠に知的です

プログラミングは進化した。コンピュータを他人の指示通り制御することそのものに価値があった30年前とは全く違う。今のプログラマは、制御はツールに任せる領域が多くなり、制御のために使う時間は大幅に減った。
しかし、コンピュータの処理能力の向上に伴って、与えたい指示の量は、比較にならないほど増大し複雑になった。変更頻度もあがり、作って終わりではなく作り続けることが求められた。一方で、量と複雑性の増大に対して、ツールと処理性能の向上が、あまり余るほど効果的に補い、作成時間は短縮した。競争環境の進化に伴い、より一層短縮することが求められた。
そこでプログラマの関心は、複雑に依存性だらけの指示を適切に短時間で実現することと、保守性を高めることの2点に移った。プログラミングの価値が変わり、動けば良いという時代は終わった。
時代は常に、巧遅より拙速を求めている。私考える人、あなた作る人。そんな牧歌的な役割分担は終わった。全員が、それぞれの得意な領域で、考え、かつ作る、ことが必要になった。実際そのほうが、要求に対して効果的だった。

設計とは何か。実装とは何か。どちらもその専門において考える内容はある。
なぜ設計が難しいのか。不特定な領域でおこるコンピュータ上の出来事すべてを決めようとするからだ。コードを書けば自明的に分かることを、わざわざ書かずに考えようとするからだ。なぜ日本語で考える。なぜコードで考えない。なぜコード領域が得意でない人が、コードを書けば自明的に実証されることを、書かずに決めたがる。
設計が終わると同時に、実装が終わって、何か不都合か。

事前に方向性の合意に、ラフな絵図を描く。これは必要だ。設計とはどのように作るかを決めることだから、これは設計の一部ではあるが、設計の全てではない。
しかし、絵図の詳細を詰めると、絵に描いた餅であることがわかることがある。なぜできないことをできると思ってしまったのか。人間はコンピュータではないからだ。ヒューマン頭脳のホスト上で、x86のゲストOSは対応してないだけなんだ。
だから、後々に絵に描いた餅が出ることを覚悟して、絵図を書かねばならない。だから、絵図の誤りを後で実証できた段階で、指摘して訂正せねばならない。だれが実証するのか。もちろんコード領域が得意な人だ。コード領域が得意な人は、当然ながらコードを書いて実証する。それが一番効率的だからだ。

だから、いわゆる「実装中に、設計ミスが見つかる」という現象が現れる。実装とは設計の実証であり、設計の一部に他ならない。実証が終わって試作コードを集めて「整理」することは、直接的には外的要求に寄らない設計作業。何のためにそれがあるのか。保守性の高いプログラムを作るためだ。これは機能要件ではないが、非機能要件の高い保守性に合致する。だから、やらねばならない。高い保守性とやらを設計せねばならない。コンピュータ科学やソフトウェア工学に強い人たちや、コード領域の人がやらねばならない。

結局「設計」をしなくていい人はいない。あらゆる活動に「設計」がつきまとう。別に悪い話ではない。それが目的達成にもっとも効果的だからだ。
しかし、30年間のツールの進化は、「設計」が苦手な人でも、下手な「設計」なりに、それなりに「役立つ」ソフトウェアを作ることを可能にした。素晴らしい。だが、高度な「設計」が求められるとき、苦手な人は無力だ。できることが限られる。適材適所が必要だ。高度な設計とは何か。未知の領域が広く、後で絵図がひっくり返る確率が高い設計のことだ。低度な設計とは何か。絵図の想定通りに進む設計のことだ。決定論的な振る舞いをするコンピュータにおいて、想定通りとは、要するに人間が結果を知っている、ということだ。

人間が結果を知っている領域を増やし、人間の頭脳で理解できる状態を共有できたとき、裾野が広がり、技術難度ピラミッドが大きくなり、平均水準が向上する。ピラミッドの一定水準より低い人は、プロフェッショナルの世界から退場を余儀なくされる。プログラミングの歴史は、その繰り返しだった。これからもそうだろう。誰であれ知的な作業はなくならない。知的と言われる対象が変遷し、深化するだけだ。

人が変われない33の理由

変わりたくないから変わらない。

変わりたくない理由を意識的に分析しない限り、

変わりたくないは、論理ではなく感情である。

人間は、感情を論理的にコントロールすることはできない。
(楽しい気分は、楽しい体験からのみ、生み出せる。)


ジェームズ・オトゥールによると、変わりたくない理由は、33に大別できる。

変えたくない、変わりたくないと思ったとき、その何番にあたるか照らして

自分がどんな真因から目をそらしてのか、見つけることができる。


疲れてくると、反射的に、保守的な反論をしてしまうことがあるので、

そうならないよう習慣づけたい。




● ジェームズ・オトゥール:変革を拒む33の憶見

1.ホメオスタシス(恒常性維持)--- 変革は自然な状態ではない。

2.前例主義 --- 現状は容認され、変革を申し出る側に立証責任がある。

3.惰性 --- 進路変更のためには相当の力が必要である。

4.満足 --- たいていの人間は現状を好む。

5.機が熟していない --- 変革のための前提条件がそろっていない。
                  タイミングが悪い。

6.不安 --- 人は未知のものを恐れる。

7.自分にとっての利害 --- 他人にとってはよいことかもしれないが、
                   自分たちにとっては都合が悪い。

8.自信の欠乏 --- 新たな挑戦に耐えられる自信がない。

9.フューチャー・ショック --- 変化に圧倒され、うずくまって抵抗する。

10.無益 --- 変革はすべて表面的であり、見かけ倒しであり、幻想だ。
           そんなものには関わらない。

11.知識不足 --- いかにして変化するのか、
              どのような状態に変わればよいのかがわからない。

12.人間の本性 --- 人間は元来、競争的で、好戦的で、貪欲で、利己的である。
               変革に必要な利他主義に欠けている。

13.冷笑的態度 --- 変革促進者の動機を疑う。

14.つむじ曲がり --- 変革はよさそうに思えるが、
                意図していなかった悪い結果が生じることを恐れる。

15.一人の天才vs大勢の凡人 --- われわれ凡人の頭には変革のための知恵など
                        湧いてこない。

16.エゴ --- 自分たちの間違いを認めることに強い抵抗がある。

17.短期思考 --- すぐに満足できないことはイヤ。

18.近視眼的思考 --- 変革が結局はより広い視点から見ると
                 自分のためになることが理解できない。

19.夢遊病 ---  大半の人間は、よく考えもせずに人生を送っている。

20.スノー・ブラインドネス --- 集団浅慮、あるいは「長いものにまかれろ」的思考。

21.共同幻想 --- 人間は経験から学ぶことなどなく、何事も先入観で見る、
              という考え方。

22.極端な判断 --- 自分たちは正しい。自分たちを変えようとする者は
               間違っている。

23.例外だという幻想 --- よそでは変革が成功するかもしれないが、
                  自分たちの所ではそうはいかない、という考え方。

24.イデオロギー --- 世界観は人それぞれ。価値観というのは
                本質的にバラバラだ、という考え方。

25.制度の固さ --- ひとりひとりの人間は変えられても、
               諸集団を変えることはできない。

26."Natura non facit saltume"という格言 --- 自然に飛躍なし、という意味。

27.権力者に対する独善的忠誠心 --- 現在の方法を定めた指導者に
                           背いてはならない。

28.「変革に支持基盤なし」 --- 多数派が変革に入れ込む以上の利害を
                      少数派が現状維持に対して持っている。

29.決定論 --- 意図的な変革をもたらすことなど誰にもできないと決めつける。

30.科学者きどり --- 歴史の教訓は科学的なものであり、
                そこから新たに学ぶべきことは何もない。

31.習慣

32.慣習第一主義 --- 変革促進者の考えを社会に対する非難であると受け止める。

33.無思慮

(出典:ジョセフ・H・ボイエット、ジミー・T・ボイエット著
『経営革命大全』P.54-55)




ほとんど引用で、中身がないですね。ごめんなさい。。。

今年の目標

2012年の目標を3つ。


① 他者・他業界から学び、提供すること
② 変化を作り、先頭を走ること
③ 人の成長の筋道を作ること



毎年、ブログのサービス会社を変えようかと思ったけど、やっぱりいまいちだった。

HTML5 Fullscreen APIのクラスリファレンス

要約
FullScreen APIの日本での普及を願って、MozillaWikiベースで、FullScreen APIの日本語のクラスリファレンスを作ってみた。
Gecko:FullScreenAPIをベースにしてるので、詳しいことはこっちを見てね。

--以下駄文

HTML5では、今までのWebではFlashの分野とされてきた技術が、次々と実装されている。

その一つが、ページのフルスクリーン表示。

先月ぐらいにhtml5j.orgで、白石さんがFullScreenAPIを紹介していたので、さっそくHTML5 の Webベンチマークに実装してみた。
描画系のベンチマークは、本来フルスクリーンで実行すべきものだったので、渡りに船だった。

MozillaWikiのGecko:FullScreenAPIが仕様に詳しく、WebKit系とMozilla系がこれをベースに実装している。
出遅れたOperaは、今W3Cで提案して必死に努力しているところのようだ。
(なんか一部のメソッド名が違うし、APIも少ないんだけど。)

そんなことはさておき、
Fullscreen APIの文書は、まだまだ英語が多い、というより、ブラウザごとの仕様書も見つけられなかった。
きっと探し方が悪いんだろう。うん。

FullScreen APIの日本での普及を願って、MozillaWikiベースで、FullScreen APIの日本語のクラスリファレンスを作ってみた。
といっても、サンプルがないと、リファレンスだけではちんぷんかんぷん。
後日にでも、サンプルも作るよ!


FullScreen APIの、各ブラウザの実装状況は、
・Safari 5.1は、正式版で有効だった。(8月ぐらいのかららしい)
・Chrome 16は、Stableでは有効ではない。Canaryは15時点で有効だった。BetaとDevは試していない。
・Firefox 7は、有効ではない。Nightlyでは有効らしいと読んだ。
・OperaとIEは、まだ未実装。

まさかのSafariがトップ。


リファレンスは適当意訳と、実装してみて感じたことを基本に書いたので、いろいろ不正確な点があると思います。
誤りに気づいたら、教えていただけると修正します。

Native Objectたちを、JsDoc Toolkitで無理に表現したので、その点は直せないです。。。



HTML5 の Webベンチマークで使った以下のFile APIたちも作成中。今30%ぐらい。
File API
File API: Writer
File API: Directories and System

同期APIは、未実装Web Worker用のようなので、とりあえず記載しないよ。

HTML5 の Webベンチマークのアルゴリズム解説

 HTML5 の Webベンチマークのアルゴリズムを説明します。
CPU、メモリ、描画、ディスクの4種類の測定があります。

使い方の説明はこちら。
HTML5でパソコンの性能を測定する、Webベンチマークテスト

CPU
ALU(整数演算)
ユークリッドの互除法で、2つの値の最大公約数を求める計算を、4000万個の値の組み合わせで行います。
この計算をWebWorkersで8スレッドに分割しています。

FPU(浮動小数演算)
マンデルブロ集合を描くための計算を、4000万個の座標で行います。
この計算をWebWorkersで8スレッドに分割しています。


Memory
Read
配列長が1000万のInt32Arrayオブジェクトの各要素から、値を読み出します。

Write
配列長が1000万のInt32Arrayオブジェクトの各要素に、10という値を書き込みます。

Read&Write
配列長が1000万のInt32Arrayオブジェクトの各要素について、値をインクリメントします。
(要素の値を読み出して、1を足して、要素に書き込みます。)


Draw
Rectangle(矩形)
Canvasに対して、矩形描画メソッドを使用して、4万個の長方形を描画します。
画面に実際に描画するために、やむを得ずJavaScriptのループをメソッド呼び出し100回単位に区切って、400回描画するようにしています。
可能であれば、フルスクリーンにしてから実行します。

Text(文字列)
Canvasに対して、文字列描画メソッドを使用して、4万個のweb-benchという文字を描画します。

Circle(円弧)
Canvasに対して、円弧描画メソッドを使用して、4万個の円を描画します。

BitBlt(ビットマップ転送)
Canvasに対して、画像描画メソッドを使用して、4万個のHTML5のロゴ画像を描画します。


Disk
Read
ローカルファイルシステムに、1MBのテキストファイルを100個作り、それを読み出します。
やむを得ず、OSのディスクキャッシュの影響を受けています。

Write
ローカルファイルシステムに、1MBのテキストファイルを100個作ります。

Copy
ローカルファイルシステムのあるフォルダに、1MBのテキストファイルを100個作り、それを別のフォルダにコピーします。


プロフィール

とむころり

Author:とむころり
24時間システムエンジニア。研究開発など何でも屋を担当。知的でおもてなし精神に満ちたシステム(サービス)が作りたい。
@tomcat_ch

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

検索フォーム

RSSリンクの表示

リンク

ブロとも申請フォーム

QRコード

QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。