2015年12月1日〜25日の間、プログラミング知識共有サイトQiitaにて、力武健次技術士事務所 所長 力武 健次が、C言語に関するアドベントカレンダーとFreeBSDに関するアドベントカレンダーを開設しました。どちらのカレンダーも多くの参加者と投稿者に恵まれ、有意義な情報が集まって意義あるものになったかと思います。
なお、力武はこの他のアドベントカレンダーにも参加し、期間中22の記事をQiitaに投稿しました。
2015年12月25日
2014年6月20日
祝「すごいErlangゆかいに学ぼう!」刊行
このたび，Learn You Some Erlang for Great Good!の日本語版がオーム社より「すごいErlangゆかいに学ぼう!」（リンクは日本のアマゾン，アフィリエイトはありません）として刊行される．かなり大変なプロジェクトだったと思うが，著者のFréd（敬称略），翻訳者の山口さん，編集者の方々，レビュアーの方々に深く敬意を表したい（私も微力ながらレビュアーとして参加させていただいた）．
この本はとにかく内容が盛りだくさんで，原著者の情熱が伝わってくる文体になっている．教科書らしくはないが，Erlangについて必要なことは一通り網羅してある恐ろしい本である．情熱を量と質で証明するのは容易なことではないが，この本ではそれができている．若くて元気な人達が本を書いたり訳したりすると，ここまで元気になるのかという良い例である．その意味で，Armstrong御大のProgramming Erlang（第2版）とは，まったく別のアプローチの本ということができるだろう．（こちらの翻訳もオーム社より「プログラミングErlang」（第1版の翻訳）として出ている（第2版の翻訳を期待したい）．）
これを機に日本でもErlang/OTPに触れる人達がますます増えることを願う．
2014年5月21日
プログラミングを続けるには
プログラマといえるほどプログラミングをしていないし，できてもいない．その焦燥感が，プログラミングを止めていない最大の理由だろうか．
ともあれ，以下の記事に触発されたので，ちょっとだけ書いてみよう．
体力をつける
プログラミングは本当に精神力を使う．頭の中に非常に多くの事柄を記憶しておく必要があり，間断なく襲ってくる外部からの割り込みに耐えないといけない．記録と記憶の外部化については前述の記事群に述べられているので細かくは書かないが，実際に頭が良く回るようにするには，体力を使わないといけない．年齢が上になればなるほど，これは厳しくなってくる．だから，
- 普通に食べる
- 普通に身体を動かす
- 無駄に体力を使わない
- 良く寝る
というのは基本だと思う．
課題を常に持っておく
プログラミングも所詮は人間の行動の一部でしかない．毎日やるには，理由が必要だ．どんなことでもいいからやるべきことを持っておく．それが今日の生活の糧のためであってもよし，あるいは近未来の夢の実現のためでもよし．その課題を解決するために，プログラミングに取り組む．そういうことを実現できていれば，続くんじゃないだろうか．
他人の視線を感じるようにする
人間は本当に「ええかっこしい」な生き物だ．できなかったことの言い訳をすることが嫌な人にとっては，コミットの件数が目に見える形で出てくる，GitHubのContributionsリストなんかは最高の理由付けになるだろう．毎日1件でいいからコミットするか，新規issueを上げるだけで済むのは，簡単といえば簡単だが，これをpublic repositoryだけに絞ると，結構大変かもしれない．
それでも，コーディングができなくても，新規issueを上げる，あるいは課題を明確にして記録するのは，プログラミングの一部であると考えて良いだろうと思う．
生活の一部に組み込んでしまう
以前はGitHubはUS Pacific Timeで動いていたので，1日が切り替わる時刻（日本だと午後4時か午後5時）になると，プログラミングのことを考えるようになっていた．最近はローカルタイムで記録してくれるようになったので，寝る前，そして起きた後の誰にも邪魔されないであろう時間を，プログラミングにあてている．ちょっと時間を取るだけでyak shavingはできるし，そうでなくとも取り組むべき課題さえ整理できていればいろいろなことができるだろう．毎日やるというのは本当に大事だと思う．
どこでもできるようにしておく
MacBook Airを使うようになってから，ローカルにコーディング環境を持てるようになったので，どこでもある程度のプロトタイピングはできるようになった．別にOS Xでなくてもいいのだが，プロトタイピングの環境はすぐに使えるようにしておいたほうがいいだろう．それに，出先でちょっと時間が余りそうな時は，いつでも何かできるように，環境を持ち歩く習慣をつけることは大事だと思う．そのためには，環境整備を日頃から怠らないのが大事．
2014年4月24日
力武健次技術士事務所 開業のご案内
このたび2014年4月21日に，日本技術士会に技術士登録変更届出書を提出し，「力武健次技術士事務所」を個人事業として営む旨届け出ました．これに伴い，2014年4月24日に，豊能税務署と大阪府豊能府税事務所に，個人事業の開業届他関連書類を提出しました．この開業届の提出をもって，法的に正式に個人事業主としてのスタートを切りました．
開業といっても，やることは今までの技術者と研究者としての活動の延長であることには変わりありません．昨年2013年10月より6ヶ月強の間各種求職活動を行って来ましたが，諸事情勘案の結果，自分ができること，やりたいことをする上で，被雇用者ではない形を取るのが最善の道であろうという判断をしました．その上で，まずは個人としてスタートしようということで，自分の持つ技術士（情報工学部門）のライセンスを活かした形で始めることにしました．
もっとも，世間を賑わせている米国西海岸のスタートアップとは違い，開業に伴う華々しい話は一切ありません．当面の目標としては，まずは借金なしの経営をしつつ，社会に対して微力ながら自分の能力を役立てればと考えています．これは大変難しいことですが，始めた以上は覚悟をもって挑む所存です．
業務内容は情報工学全般，特に過去経験してきた情報セキュリティ，ネットワーク，Erlang/OTP，FreeBSD，モバイルの無線技術関連を主としつつ，これらにこだわることなく何でもやるつもりです．何かお役に立てること，お困りのことがありましたら，遠慮なくご相談ください．連絡の方法については以下のURLを参考にしていただければ幸いです．
力武健次技術士事務所のページ URL:http://rikitake.jp/ （2014年12月にURLを更新）
2014年4月2日
2007年1月の年頭所感より
ふと思い立って，自分の2007年の年頭所感を読み返してみた．面白かったので再掲する．
6年3ヶ月経過して実現できたのは
- 音楽活動のほぼ完全停止
- （アマチュア）無線活動の部分的停止（基本的に10月〜3月のみとし，4月〜9月は休業）
- 外部条件により半ば強制的にカネの稼ぎ方を考え直させられている
…ぐらいでしかない．
人間というのは，恐ろしいほど変わらないものだということを，実感する．そして，今は2007年よりも，世界の状況はさらに悪化していることに，驚くばかりである．
(以下，2007年01月03日 10:44JST の mixi 日記より引用．「今年」という表現は，2007年のことであることに注意されたい．)
人生後半
2004年に親父を亡くして以来，人生後半なのだというのを強く意識するようになった．簡単にいえば，年寄りになったということである．つまり，糾弾する側から糾弾される側に，高齢化社会にとってはリソースを食いまくる迷惑な存在になったということだ．
そろそろ人生のいろいろな活動から撤退して死ぬための準備をしなければならなくなったことを痛切に感じる．
この20年は
- 言論の自由を阻止しようとする政府という悪との戦い
- あらゆる障壁のdeconstructionと徹底した国境開放
- コンテンツ売りでぼろ儲けしようとする連中との戦い
に明け暮れたような気がする．
もっとも，1.については
1.1 政府と役人自身があらゆる分野で責任を放棄するというもっとも凶悪な戦略を実行しているので，いったい誰が悪いのかということが見えなくなってしまった
1.2 私も含め「教師は憎むべき対象」「年寄りは害毒」という考え方が一定世代以下の人たちには十分に行き渡ったせいか，その無謬性を前提にした犯罪が増えてしまった
1.3 本当の悪は政府の裏についている国民全体（もちろん自分も含む）と，政府を裏で動かしているマフィア（圧力団体ともいう）達であることが次第に明らかになりつつある
という問題が見えてきてしまったので，昔ほど単純に主張できなくなってきている．また，自分がかつて敵対していた組織から，禄を食むことを余儀なくされているからかもしれない．好き嫌いや良し悪しだけでは仕事は選べないし，どんな組織の中にもうまくやっていける人間はいるので，簡単に敵味方の論理では語れなくなってきた．
2.については，日本は核攻撃されても国境を開かなかったのだから，私の生きている間には徹底開国は実現しないだろうと思う．もっとも，そうなる前に労働力不足で 移民の導入は必須だろうけど．そうなったらなったで生きていく覚悟はあるが，大半のdomesticatedされた（domesticでないことに注意）日本人にはつらかろうと思う．まあ，彼らがどうなろうと，私は私でやっていくしかないが．
3.については，率直な話コンテンツ産業にかかわればかかわるほど，空しくなってやる気が失せていくのが現実だろう．多くの創作行為が違法とされている中で，本当に面白いものは不法行為の中にしか残らないのではないかと思う．ならばその不法行為を合法化すればいいのだが，どうもコンテンツ産業のお化けたちは死ぬまで吸血鬼でいたいらしい．
一言で言えば，この20年間，無駄な戦いをやっていたなと思う．ヘタに正面切って戦うよりは，食うためのゲリラ戦に徹したほうがずっと良さそうだということに気がついた．原点に返ったともいえるのだが．
今年はとりあえず
- a)音楽活動の一定分野にピリオドを打つ．今までやってきた活動との重複を避ける，残すのはDJとラップだけ
- b)無線活動は極力縮小し，その分のエネルギーは電子工作技術の習得に回す（ハードウェア技術は飯のタネになるだろうから）
- c)コンピュータを好きになってちゃんとコーディングと実験をしよう，仕事をしよう
- d)人間関係としてのインターネットは極力縮小し，くだらない争いには首を突っ込まない
- e)インターネットの前提にあるabstraction technologyの復習をする
- f)カネの稼ぎ方を考え直す
- g)面倒がらずに身体を立て直して世界中動き回る
- h)自宅コンピュータシステムの縮小，アウトソース化
ぐらいのことはしたい．
…これだけ書けば，new year resolutionとしては十分だろう．
（以上で引用終わり）
2013年2月7日
Bashoジャパンにて働き始めました
2013年2月1日より，Bashoジャパン株式会社にて，シニアソフトウェアエンジニアとして働くことになりました． 関係者の皆様には，私の就職にあたり，多大なるご協力とご支援をいただきました．厚く御礼申し上げます． 今後は，自分のソフトウェア開発技術の基礎から叩き直す覚悟で精進致します．どうぞ今後ともご支援のほど，よろしくお願い致します．
Basho TechnologiesにはErlangにおいても分散データベースにおいても世界第一線級のエンジニアたちが集まっており，日々新しいことを吸収していかなければ，自分がついていくことさえ難しいのですが，その分自分が今まで培ってきたものを最大限活用できる可能性のある場所でもあります．その意味で，大変ではありますが，充実した日々を過ごしています．現時点では，少なくとも1990年から2年間外資系企業で働いたことは間違いなく役立っています．
今後，どのような仕事を自分がしていくのかは，まだ予想がつきません．Bashoの分散データベースRiakはすでに各社の最前線で活用されており，多くの機能要求も出ています．これらの要求に対して，迅速な開発と高い品質の維持を持って応えることに貢献しなければならないことは言うまでもありません．そこに自分のネットワーク技術者，OSプログラマ，そしてシステム管理者としての経験がどれだけ活かせるか．そこが勝負です．
2011年5月8日
相互排除問題，際どい部分，そして並行プログラミング
複数の実行中のプログラム（プロセス）が関わる処理では，必ず排他制御が問題になる． 複数のプロセスがあらかじめ許容された同時アクセス数を越えて共有資源を使おうとすれば， どのプロセスにアクセスを許し，どれに許さないかを，決めなくてはならない． これを mutual exclusion problem 日本語では相互排除問題という．
この相互排除問題について，最近岩波書店より 「相互排除問題」（以下「本書」とする） というそのものズバリの本が先月2011年4月に出版された． 著者は土居範久先生．日本におけるこの分野の第一人者である．
本書の参考文献リストを見ると，ほとんどの文献が 1990年以前に書かれている．しかし，内容はいささかも古いものではなく， 現在のマルチコア環境，あるいは分散ネットワーク環境において課題となっている 同期と相互排除に関する問題のほとんどを網羅している． 言い換えれば，現時点の課題の大多数は，20年前に解かれていると 言い切れるかもしれない． （もちろん，アルゴリズムの効率化や，実行環境の速度等に合わせた最適化は 現在も引き続き行われているが．）
本書では，アルゴリズムの説明にPascalに似た疑似コードを使っている． しかし，本書の本文中では逐次処理にとどまらず，HoareのCSPや分散プロセス， メッセージ通信など現在の並行処理や分散処理の基本となる概念が くまなく網羅されており，疑似コードも書籍を読み進めるに従って， 内容が拡張されていく仕組みになっている．そういう意味では，読んでいて楽しい． もっとも，例示されているそれぞれの疑似コードを咀嚼して理解するには， かなりのプログラミングの経験が必要だが．
本書のページ数は256と少ないものの，気軽に片手間で読める本ではない． 本書のテーマである「際どい部分」(critical section)や 「際どい資源」(critical resource)の扱いは， 一歩間違えれば，大変な事故を引き起こしかねないものだからだ． 別の言い方をすれば，この本を一通り理解できるようになったら， ソフトウェアエンジニアとしては一人前と言えるかもしれない． 日本語で並行処理を理解する上で，本書は必読といえるだろう．
2011年4月4日
Erlang Workshop 2011 のご案内
関数型言語の国際会議 ICFP の今年の開催地は東京です．ICFP のアジアでの開催は初めてですね．HaskellもGHCがGitHubに移ったり，OCaml，Scala，F#と，関数型言語も随分増えてきました．そんな訳で関数型言語界隈はこのごろ活気付いて います．
2011年は日本における関数型言語ブレイクの年になるか? なると嬉しいなあ…という方にお知らせです．
ICFP 2011 に併設して Erlang Workshop 2011 が開かれます．Erlang Workshop にはどなたでも参加できます．発表内容の議事録を見ると，コンパイルや形式変換などのプログラミング言語理論だけでなく，テストやライブラリの話など，Erlang/OTP 関連技術の実践応用に至る幅広い論文発表がなされています．
「Erlang，良さそうなんだけど，本当に関数型言語として使えるの?」「Erlang/OTPの上に乗っているCouchDBやRabbitMQは使っているけど，他にどんな使い方があるんだろう?」…そんな疑問を持っている方は是非 Erlang Workshop に参加してください．世界中のErlang経験者が一堂に会して，Erlang/OTPの奥深い技術について聞けるのは，Erlang Workshopだけです．
さて，Erlang Workshopは聞くだけではなく，発表をする場でもあります．特に今年は日本での開催ですので，是非是非日本の皆さんのErlang/OTPによる取り組みをご紹介していただければ，主催者達も大変喜ぶかと思います．
発表の形式は以下の3つです．
- 技術論文: 言語拡張，現状の改善，言語構成要素の形式意味論，プログラム解析と変換，仮想マシンの拡張とコンパイルのテクニック，他言語でのErlangの実装や他言語とのインターフェース，その他新しいツールについて．最大12ページ．
- 実践応用論文: 実世界でのErlangの応用．特定作業のためのライブラリ，特定分野における応用からもたらされた経験，問題解決でのErlangのエレガントな応用．最大6ページ．（ここへの投稿は次のポスター発表に割り当てる可能性がありま す．）
- ポスター発表: 本ワークショップの目的に合致した話題に関する説明．最大2ページの発表の概要(abstract)と要旨．発表は1時間のデモ枠で複数個同時に行われます．
論文投稿の方法の詳細については Call For Papers (http://www.erlang.org/workshop/2011/) を参照してください．
締切等についてですが
- 論文投稿締切: 2011年6月3日
- 論文査読結果通知: 2011年6月17日
- 最終原稿締切: 2011年7月13日
- ワークショップ: 2011年9月23日
実は，私はこのワークショップの実行委員長です．会場でお会いできるのを楽しみにしております．Erlang Workshop 2011へのご支援，ぜひよろしくお願いします．
（CUFP 2011 Tokyoに関する紹介ページ にインスパイアされて（笑）書いてみました．）
2011年3月2日
新卒準備カレンダー2011春のアドベントに向けて: おすすめの本
（新卒準備カレンダー2011春
http://atnd.org/events/13324
向けのエントリーです．）
おすすめの本，といえば，いろいろとありますが
かな．私が読んだのは原著の
の方です．
この本の著者 Chad Fowler が最初にこの本を出した時のタイトルは，"My Job Went To India" （日本語版では「オフショア時代のソフトウェア開発者サバイバルガイド」というタイトルが付いていた）だった．私自身が仕事を探さなければならない状況になっていたこともあり，かなり真剣に読んだ記憶がある．詳しいことは中身を読んでもらうとして，この本の要点を短かくまとめると
おすすめの本，といえば，いろいろとありますが
かな．私が読んだのは原著の
の方です．
この本の著者 Chad Fowler が最初にこの本を出した時のタイトルは，"My Job Went To India" （日本語版では「オフショア時代のソフトウェア開発者サバイバルガイド」というタイトルが付いていた）だった．私自身が仕事を探さなければならない状況になっていたこともあり，かなり真剣に読んだ記憶がある．詳しいことは中身を読んでもらうとして，この本の要点を短かくまとめると
- 常に学び続けていなければ，いつか手持ちの技術だけでは食えなくなる時が来る
- プログラミングという限られた一芸だけではもう食えない（プログラミングに限らないが）
- 燃え尽きないように，そして自分の欠点を知って，定期的に自分を振り返ること
2003年9月13日
Javaが生まれる前の話
1988年12月14日に行われた東京大学大型電算機センター会議室でのBill Joyの講演のメモ
Edited 13-SEP-2003 by Kenji Rikitake 力武 健次
(1988年12月14日に紙に書いた私的メモを編集したもの)
From V7 to Phase-3 (メモ原文ではΦ-3)
The evolution of UNIX
7 from AT&T (Sys V rel 3)
7 from BSD (4.3)
Phase-3: restructured UNIX
20年前とは基本的構造は変わっていない
MULTICSから3つのideaしか使っていない
Processes : "GENIE" / Ken Thompson
File System : KT (Ken Thompsonのことと思われる)
Pipes: McIlroy
Shell以上がけっこう複雑になっている
その後の改造
VAX-11/780
virtual memory
keep PDP-11 model
paging is invisible
→ 3BSD 1979
Local Area Networks
Ethernet
TCP/IP
model of sockets
→ 4BSD 1981
Problems
No "tenex" pmap functionality → mmap() ← 載らず
Communications is asynchronous → select() ← まだ不十分
New technologies -> New system facilities -> Larger O/S
Trends
1. Minis -> WSes & Servers ⇒ NFS
2. Library Complexity ⇒ Dynamic Linkage
-> back to MULTICS
Graphics and Windowing -> complicated
5 kinds of graphics
X11 PHIGS PostScript Renderman & what? (image processing)
Current UNIX:
Applications: Communication が不足
Unix Kernel: networking 1M lines
original 200K lines
Graphics: 1M lines
4 Application Styles
main(): App.
sleep(): Traditional Kernel
Networking
Graphics
⇒ The single paradigm:
No Concurrency/Parallel Programming
Too Complex
New Central Concepts
Mach -> ports & RPC -> first bigger -> next smaller
--> HUGE DEFICITS ("first cut taxes" ではだめ)
⇒ UK(英国)みたいに <first cut spending>
Sun's Approach:
Focus on applications: one programming environment
Concurrency / C++ / Shared memory / Fiber optics
⇒ Making UNIX be an application
Status of the nre project:
Nucleus (wnj: assembler (Microcode)) ... 1 sys call
Language (mitchell, powell... ) ... C++++-=
Services (gingell, ...) ... UNIX, networks...
Key will be success of language
C++ ++ -= ⇒ implemented in ANSI C ⇒ SPARC (microcode)
++: concurrency / parameterized types / garbage collection
-=: general complexity (unsafe function ⇒ ANSI C で書け)
Summary:
Phase 3 is RISC for OS
RISC relative to Applications
Not a OS kernel; applications platform!
This is first public talk -> do work, not promote.
-----
Cross examination or Q&A session
UNIXとのコンパチビリティはどうか?
→上位OSで確保する
C++とObjective-Cは?
→どっちも生産性向上のためのツールである
C++を使っている
フォールト・トレラント性はどうするつもりか?
→オブジェクト指向ならば各オブジェクトのコピーは楽である．
これを利用してシャドウ・ディスクを作れる．
多言語での可能性は?
→ほとんどの言語はinterpreterである．
良いinterpreterはむつかしい．
SPARCの命令は今後拡張されるか?
→固定している．整数乗算や64bit長についてでさえ議論が行われているが，
これからどうなるかはもっと若い人にまかせたい．
5000ゲート＋レジスタ・ファイルでしかないから，改造は楽である．
いずれにせよ，386みたいにやればインテルに告訴されるだろうが，
SPARCではそんなことはせず広めていきたい．
ハードウェア記述言語が米国の大学では開発されており，
それをつかってSPARCを作れる．それにはスーパーコンピュータが
必要であろう．(逐次探索でやるしかない)
SPARCのコンテキストスイッチングはおそい．
→全部レジスタを変える必要があるかどうかは，統計的な問題である．
言語の複雑さにもよるであろう．
OSと言語との関係は?
→UNIXではCのmain()の世界で生きる．しかしこれだけではgraphicsなどには
対応できる環境がない． C++++-= ではこれらに対応できる環境を提供する．
さらに一つでやりたい．
グラフィクス以外の音声などのメディアは?
→リアルタイムOSに近くしたいと思う．
(レスポンスの時間が予測できるようにしたい)
そのためには非常に速いマシンが必要である．
小手先の対応では対処できない．
DVIは見たか?
→あまり好きではない． orphan technology だと思う．
絵が汚い．ISDN用に絵画を圧縮したいんだと思うが，Appleの方が良く
やっていると思う．みんなやっているから，すぐにできるだろう．
机の中にTVが入るだろう(HDTV)
Securityはどう実現するつもりか?
→ simple .vs. diverse
common .vs. complex
単純なものは弱い．
common ⇒暗号を使う必要がある．
モジュール化して，違う組み合わせで違うシステムでやる必要がある．
Cは堅いが，もろい←強固に書く必要がある．
建物と違い，動かす前にテストできない．
暗号はどうするつもりか?
→ DESはどうしようもない．政治の問題だ．
公開鍵暗号は研究されているが，これを広めようとすれば政治問題になる．
その証拠にまだ第3世界はエニグマ暗号を使っている．
トロイの木馬みたいだけど，銀行のシステムを攻撃してやれば
みんなわかるんじゃないだろうか．
Phase-3 では「きれいな」プログラミングを強要されるだろう．
ガベコレなんかがあると， malloc()なんかは使いにくくなる．
→ 古いプログラマの10%が理解してくれればいいと思う．
プログラムは C++++-= ではエレガントになるのか?
→ 今マニュアルがないので例を示すことはできない．
できるだけ変えずにエレガントにするのは，むつかしいだろう．
コンパイラが答えられないような例があるのは情けない限りである．
SunのHardware仕様書がない．
→ 手には入れられるようにしてある．
Sunのソースコードも提供している．
いくつかのドライバはしょうもないだろうが．
680x0 が× SPARC が○となったのはなぜか
→ 自分でデザインするしかなかった．
半導体業界は協調してくれないので大変だった．
SPARCは hybrid chip の核として使われることを予想している．
わずか20000ゲートでしかない(2μmテクノロジ)
そのうち家具同士で通信することもできるようになるだろう．
Nano Technology
Drexler "Engines of Creation"
大容量記憶装置はどうなるか?
→ Audioを見よ．CDプレーヤーは安い容量はでかい．
いわゆるdiskはRAMになり，CDが主流になる．
そのうち原子構造を利用したものになる．
[以下雑談となり終了]
編者注:
- C++++--= (Cプラスプラスプラスプラスマイナスマイナスイコール) はその後 Java となり実用化された言語の祖先であったと考えて良いだろう．
- 1988年末当時，まだSun-4が登場したばかりであり，UNIXあるいはSunOSもソースコードを見るにはAT&Tのライセンスが必要だった．また，当時は米国国務省の認めない暗号技術の輸出は厳に禁じられていた．
[end of memorandum]
2001年3月21日
情報技術者の定義
(初出: Kenji Rikitake's Cyberscope: 21-MAR-2001)
- 情報技術者が技術者たる所以は、ソフトウェアやハードウェアを、必要に応じてチューンアップできる能力を持っているからだ。この能力のない人達は、技術者と呼ぶには値しない。
- プロは言語やOSは選べない。好き嫌いはあっても、与えられた環境で文句を言わず仕事をするのがプロである。Windowsは嫌いだ、メインフレームは嫌いだ、と言っているような人達はプロではない。
- WYSIWYGは誤謬を招く。完全なWYSIWYGは存在しないからだ。だからWYSIWYGのプログラムによる成果を盲目的に信用してはならない。
- WYSIWYG以前の問題: 常に演算結果と、その理論的整合性には注意を払うべきである。誤差解析のできない技術者はプロではない。
- コンピュータの起源は、アングロサクソン文化にある。(ラテン文化ではない。ましてや、アジアやアラブ、アフリカの文化ではない。) 世界最初に計算量理論と自動機械の理論を打ち立てたのは John von Neumann と Alan Turing である。 von Neumann はハンガリーの出身だが、彼はアメリカ合衆国に尽し、その世界戦略に大きな影響を与えた。故に彼は(過去ドイツなどにいたことは無視できないが)アメリカ人として評価すべきである。 Alan Turing は英国人である。この両者の業績に比べれば、他の人々の業績は取るに足らない。
- インターネットもコンピュータと同様アングロサクソン文化の産物であり、その文物である。社会のインターネット化を支持することは、本質的にアングロサクソン文化の一側面を支持していることに他ならない。フランスやイスラム諸国が現在の情報技術の主流に対して異議を示していることは当然の帰結である。しかし、彼等は本流にはなり得ない。
- コンピュータ技術は本質的にアングロサクソン文化の継承物であるため、基本的にその中心言語は英語となる。故に国際化(internationalization)は、問題解決の上での最優先事項にはならない。国際化は、各国の技術者の紛争と権力闘争の結果として、最終的に実現されるものである。始めに国際化ありき、では、現実の技術者同士での意見交換は不可能である。
- 技術者の集団は元々閉鎖的なものである。開発者の仲間に入らずして、外部から批判だけしていても、願望は実現されない。故に、英語中心の開発者の集団で意見を通すためには、その意見は英語で話されるべきである。
- コンピュータが世界各国の言語を処理できるようになるべきだという主張が、現在のコンピュータで仕事をしなくても良い理由にはならない。これを理解していない人は、情報技術のプロにはなれない。
- 英語のできない人は情報技術者の資格はない。言い換えれば、情報技術のプロの中に、英語を正しく解釈できない人はいない。発音は酷いかもしれないが。
- 思考を言語化できない人は、技術者としての適性に欠ける。
- 技術者として独立したいなら、言語表現の能力も技術の一つであると悟り、修練を積む必要がある。
- 2000年問題を過去のプログラマの狭量さのせいだと決めつけるだけの人に、情報技術の本質を論じる資格はない。(意味: 1970年代のコンピュータの主記憶容量と、それで行っていた仕事に最低限必要な情報量を考えてみよ。)
- 技術力の行使は、それ自身武力の行使と同様の意味を持つ。故にその無制限な利用は厳しく戒められなければならない。言い換えれば、それだけの倫理的な規準を持たない人物は、情報技術のプロと呼ぶに値しない。
- 技術を持たない者は、技術を持つ者に対し、本質的に劣位に立っていることを自覚すべきである。他の運動能力や問題解決能力、あるいは芸術的表現能力同様、技術力は特殊能力であり、人類全部に自然に備わっているものではない。
- 技術者は技術力を持ってその思想を証明しなければならない。思想なき技術は存在しない。技術力の裏づけなくして、技術者としての思想は証明できない。
- 技術者としての問題解決能力の高さと、人柄の良さは、全く相互に無関係な問題である。前者で後者を評価してはならない。また、後者で前者を評価することもしてはならない。
- 基礎技術の開発は片手間でできるようなものではない。末端の応用技術の開発ができたからといって、その技術者に基礎技術の開発への適性があるわけではない。
- プロは自分で道具を揃える。道具を自費で賄うのは当然のことであり、他のスポンサーに頼ることは極力慎まねばならない。
- 自分が発明したと思えることの大部分は、すでに発明されているか、無意識のうちにコピーしたものである。既存の技術を使い問題解決を行うことと、既存の技術をあたかも自分が発明したかのごとく偽装することは厳密に区別されなければならない。
登録:
投稿 (Atom)