2012年11月11日 (日)

何を作るべきなのかを決める必要がある

やはり少数精鋭のソフトを開発するしかない。
多くを開発しても製品として武器になるのは少ない。
せいぜい4つくらいだろう。
開発対象を4つくらいに狭めて開発する必要がある。
それは今後10年に渡って商品価値を失わないソフトウェアでなければならない。
今後10年だ。最低でも5年は価値を持って戦える武器でなくてはならない。
現実を見てみれば、ソフトウェアで成功した企業家(プログラマ)
は皆1つか2つの製品でのみ勝負して成功している。
それほどにソフトウェアでの多作というのは無駄になるものなのだ。

| | コメント (0) | トラックバック (0)

矛盾を含んだ思想をインプットすると人間は弱くなる

これは何も思想に限ったことではない。
人生の態度や価値観や生き方でもいい。
とにかくある理論を取り込んだ際に、その理論内に矛盾がある場合、
結果的にはその矛盾を処理しなければならなくなる。
その矛盾が大きな矛盾である場合、その思想はその人間を苦しめることになる。
だから、自分が取り入れた思想や理論の内部に矛盾があるかどうか
を常に注意してチェックしておく必要がある。
矛盾があるかどうかは理論をよく検証しないと分からない場合が
ほとんどなので意識的な注意が必要だ。
思想、理論、態度、価値観、方向性、目的、に矛盾が含まれているか
どうかを検証するのは極めて重要な作業である。
また逆に矛盾を含んだ理論を相手に注入することで相手に将来的な
損傷を与えるという戦略も成り立つ。
理論の矛盾には内部矛盾と外部矛盾がある。
理論の内部での矛盾と、理論と外部世界との間の矛盾だ。
どちらも致命的な問題だが、より致命的なのは内部矛盾の方だ。
外部矛盾は分かりやすくそして外部世界はまだ変わりうるので
矛盾が解消する可能性もある。
しかし内部矛盾は分かりにくくそしてそれが解消する可能性は無い。
そのためには理論の改修が必要であるが、内部矛盾を明らかにする
にはかなりの意識的な検証作業が必要となる。

| | コメント (0) | トラックバック (0)

デスマーチでは正確な見積もりが最大の武器になる

見積もりの正しささえ納得させれば、
・スケジュールの遅れ
・バグの発生率
・発生する工数
全てが正当化されるからだ。
だから、正統な見積もりを出すことが何よりも重要になる。
それを理論的な説明と根拠で納得させる事。
そうすれば、スケジュールの遅れも自動的に正当化されるのだ。
この話が通用しない職場はもはや論理的な話し合いができないと見限ってよい。

| | コメント (0) | トラックバック (0)

商標、ライセンス、ソフトウェア特許、著作権、セキュリティ

ソフトウェアの制限とは、コピーを防止することを最終目的とする。
ソフトウェアを制限する手段として、この5つのツールが使われる。
5つのツールは列挙順に強い権限となる。
オラクルはソフトウェア特許と著作権によってJavaを守ろうとした。
SUNは商標を使用してMSからJavaを守った。
セキュリティは最終手段となる。
この場合のセキュリティとは人間の安全に関係するあらゆる領域を指す。
国家がLINUXやBlackBerryなどに対して暗号化を破る手段として
コードの公開を迫ったり、逆に隠蔽できるのはセキュリティの力である。
オラクルがGoogleに最終決戦を望むのならば、セキュリティの領域に土俵を移すだろう。
どんな勝負でも、セキュリティの領域で勝てれば最終的には勝てる。

| | コメント (0) | トラックバック (0)

オープンソースを身にまとったクローズコードの群れ

Webサービスの多くは、サーバー側のコードを公開していない。
それでいながら、彼らの多くはGPLを信奉してオープンソースを声高に叫ぶ。
Googleにしてもはてなにしても何にしても、サーバー側のコードを公開している
ケースは極めて少ない。
そして、この事に触れられた記事は極めて少ない。
彼らはガチンコでクローズソースを実行しているのに。
Webサービスはサーバー側のソフトウェアを配布しているわけではないため、
GPLのツールを使用してもコードを公開する義務は生じない。
だから彼らはGPLに賛成してそれを進める事で自分が使えるツールを増やす事ができる。
また、サーバー側のソフトは配布されないため、ライセンスや著作権などで
防御する必要がない。
彼らの本質的な矛盾は、自らはGPLなどのオープンソースに賛成しているのに、
自分たちのサーバー側のコードは決して公開しない、という点だ。

| | コメント (0) | トラックバック (0)

オープンはセキュリティに敗れる

だから、Androidはiphoneに敗れる運命にある。
同様にして、GPLなどのオープンソースは最終的には敗れる。
LinuxはついにセキュアブートによってWindowsに敗れてしまった。
Facebookなども実名性から匿名性+公開性になることでセキュリティが
下がっており、独自の特徴と強みが薄れてしまっている。
Facebookなどの実名性のサービスは完全実名性+クローズ性による
セキュアなネットワークの提供が本当は強みのはずである。
iphone の最大の強みは、セキュリティを味方につけていることだ。
携帯端末というセキュリティの中心部を攻略した事がiphoneの最大の強さである。
ipad も macbook もセキュリティ領域ではないので業績はそれほどでもない。
android はセキュリティ領域にもかかわらず、セキュリティが弱いのが致命的なのだ。
ipad がよりパーソナルでクリティカルな領域に進出すれば、
Appleは莫大な成功を手に入れるだろう。
セキュリティよりも上位の権威概念は半世紀近く現れていない。
もし見つかるとしたらそれは人間の安全よりも重要なものという意味になるから、
おそらく人類全体の目的に関係する概念や価値になるだろう。
米国において、NSAが最高権力機関となっているのもそれが国家のセキュリティを
担当しているからである。

| | コメント (0) | トラックバック (0)

あらゆる記事は末尾から読むべし

時間を無駄にしないためだ。
Web上の記事、雑誌、書籍、あらゆる記事について適用できる。
後ろの方に重要な情報が書かれている可能性が高い。
時間泥棒の記事、馬鹿の書いた記事に対しては、特に有効だ。
末尾から読んでも重要箇所が見当たらない場合は構成が悪いので読む価値は無い。
これは同時に最も効率のいい速読になるだろう。

| | コメント (0) | トラックバック (0)

2chは2chによって滅ぶ

2chのまとめサイトをひろゆきが阻止しようとしているが難しい。
法的には著作権という強力な武器を使うしかない。
これをプロバイダを相手に提訴するという戦略である。
まとめサイトを作った個人は特定できないのでプロバイダを脅す、
というわけだ。
日本国内のプロバイダならばこの戦略でOK。
しかし海外のプロバイダならばどうか。
日本の著作権が適用できない国のプロバイダならばどうか。
この戦略は使えないことになる。
しかも、スレッドの完全コピーではなく、抽出なので、
引用という主張する逃げ道も一応はある。
2chが海外のサーバーを使うことで安全を確保しているように、
まとめサイトも海外のサーバーを使うことで安全を確保できる。
2chは自らの戦略を逆用されることには無力だったのだ。
しかもまとめサイトの多くはツールをつかって半自動的にまとめを
生成できるので、生産性がかなり高い。これも2chにとっては痛手だ。
まとめサイトに本当に対抗するにはどうしたらよいか。
まず法的な問題として対応するのは海外サーバー問題があるので無力だ。
実力で戦うしかない。
しかしどうやって? すぐには思いつかない。
2ch側の今後の戦略に大注目である。
このまま放置して諦めるか、何か根本的な手を打つか。
個々のプロバイダを脅すのはほとんど意味が無いので止めるだろう。
根本的な対策としては、Googleと取引するというのがある。
Googleに依頼してまとめサイトを検索でヒットしないようにしてもらうのだ。
問題はどうやってGoogleを動かすかだが、何らかのバーターを使うか、
法的にGoogleを脅すかのいづれかだろう。
バーターは2ch内にGoogleの広告やサービスを取り込むというのがある。
これならばまとめサイトを一網打尽にできる。
まとめサイトのリンク集はできるだろうが、そのようなサイトは少数なので
発見しだいGoogleにアクセスブロックしてもらえばよい。
残るはBingだが、こちらも何とかして検索ブロックをしてもらうようにする。
GoogleとBingさえ検索ブロックしてもらえば、まとめサイト問題は解決可能だ。
水道の元栓を締めるようなことなので、まとめサイト側では簡単に回避が難しい。
これ以外の策でまとめサイトに対抗しようとするとかなり難しいのではないか。
これ以外の戦略で対抗できたとするならば素直に感心する。

| | コメント (0) | トラックバック (0)

GPLはWebに敗れた

サーバーサイドでGPLなプログラムを使われても検知できない。
だからサーバーサイド側に対してはGPLは無力である。
サーバーサイドは完全なブラックボックスだからだ。
AGPLやGPLv3で対応しようとしているが、ブラックボックスに
対して有効な対策になっていない。
つまりWebアプリにおいてはJavaScriptを除いてGPLは無力である。
今後Webアプリが主流になることは間違いないので、GPLは無力化するだろう。
というか、あらゆるソフトウェアライセンスはサーバーサイドには無力なのだ。
Webアプリ企業やコミュニティがオープンソースをいくら主張しても
そこに偽善が混じるのはこの理由による。
彼らは自分たちのソースは公開しないままオープンソースの利益を傍受できるのだ。
やがてGPLやストールマンはWebを敵視するようになっていくだろう。
おそらくWebはセキュリティに問題がある、として攻撃を開始するかもしれない。
セキュリティを口実にした攻撃は現時点において最強の論理だからだ。
しかし、よほどのセキュリティ問題が発生しないかぎり、この戦略も失敗するだろう。
最後に残るのはクローズソースの復活である。
GPLは有料のソースコードを購入してそのコードに対するライセンスになる。
あるいはオープンソースの閲覧の有料化である。
いづれにしてもオープンソースは死ぬ可能性が高い。
オープンソースが死ねばGPLは意味がなくなるので不要となる。
しかしこれは自分たちの哲学や価値観を根本から否定する事になるので
かなり難しいだろう。コードの有料化とオープンソースは両立しない。
私は「敵の最大の武器によって敵を倒す」という思想が強いと思っていたので、
GPLを滅ぼすのはGPLなのではと思っていた。
つまり公開の強制という性質がGPL自身に跳ね返るのではということだ。
しかしGPLはWebにしてやられた。
これはGPLの武器でやられたのではなく、技術の法則で敗れたに近い。
GPLでいくらライセンスを厳しくしても、技術的に鉄壁の防御壁を作られたら
あらゆるライセンスは無効になるということだ。
そうか。ライセンスは技術の壁を破れないのだな。

| | コメント (0) | トラックバック (0)

業務自動化による対応という幻想

自動化が効果を発揮する場面というのは非常に限られている。
また、最も工数を必要とするテストの自動化が難しい。
特にテストケース作成の自動化は難しい。
テストケース作成の難しさは、以下の性質による。
・条件の組合せの網羅ではない(爆発するため)
・書式フォーマットの縛りがきつい
・期待される出力は組合せから導出できない
・テストケースの合否の判断が人間の主観による
だからテストケースの作成を機械的に行う事は難しい。
特に入力条件の機械的組合せによる生成ができないのが痛い。
現実にそれを行おうとすると、組合せ爆発が生じてしまう。
だからパタンを絞り込む必要があるが、そうすると自動化ができなくなる。
書式フォーマットの縛りがきついのも痛い。
大抵はOffice文書で作られるが、フォーマットがプアだと
作成効率が激減してしまう問題がある。
またフォーマットがプアなために表現が難しくなる問題もある。
組合せ爆発、プアフォーマット、主観的基準、これらの要因
により自動化が極めて難しくなる。
テストの実施はある程度の自動化が可能となるが、
それでも画面操作が入るとかなり難しくなる。
またテスト実施の自動化プログラムも複雑になるとそれ自体を
作成する工数もかなり大きくなる。
しかも大抵のテストは1回しか行われないので、実施の自動化
の恩恵は将来に継続する事は無い。

| | コメント (0) | トラックバック (0)

2012年7月19日 (木)

なぜ企業はドキュメントの世代管理システムを導入しないのか

それは企業にとってドキュメントはやはりその程度の価値しかないからだ。
プログラムと違って動作検証もできないし、
バイナリだから世代管理をしても差分が分からない。
だからドキュメントの世代管理をしない。
だからドキュメントが更新されなくなる。
そしてそれらは信用できなくなる。
そして必然的に稼動しているソースコードがドキュメントの代わりになる。

またドキュメントの世代管理システムを入れてしまうと、余剰人員が
判明してしまうというのも企業(特に日本企業)にとっては痛いだろう。
世代管理を始めると余計なドキュメントは作られなくなり、結果として
本当に必要な仕事がだんだんと明らかになってくる。
すると余計な仕事で食ってきた中高年層の仕事が無くなる危険性がある。

また余計なドキュメントを作ることで無駄な仕事を作るというSEの十八番が
できなくなるのも辛い。
開発をしない生粋のSEにとってはドキュメント管理システムは敵であろう。

逆にドキュメント管理システムを導入している企業は優秀な企業なのではないか。
ソースコードの世代管理システムはどうしても必要だから大抵の企業は
導入せざるを得ないが、ドキュメントの世代管理をしている企業は稀である。

| | コメント (0) | トラックバック (0)

コンサルの彼は相変わらずプログラマを否定していたな

それも必死になっていた。
「君がやる仕事は入社4ヶ月の新人がやる仕事だよ」
ととんでもないことを言っていたが、それくらいに必死だった。
おそらく、私がプログラマとして技術を武器に生きているのが
気に食わないのだろう。
実際、じゃあコンサル君は最終的にはどうやって生きていくの
と聞いたところ、俺はしゃべりで生きていくよ、と言っていた。
つまり、技術ではなくコミュニケーションで生きていくということだ。
これはかなり恐ろしい選択なのだが、それがSEというものだから
仕方が無いのだろう。
それでいよいよプログラミングという武器を手放してはならないと
感じたのであった。

| | コメント (0) | トラックバック (0)

クロージャーはクラスやオブジェクトと並ぶ重要概念だ

それだけにクロージャーがJavaで使えないのが悲しすぎる。

JavaScriptでも使えない。使えると言われているけどあれは紛い物だ。
本物のクロージャーではない。

クロージャーの定義は、周囲の環境を自律的に読み取る関数、
というべきだろう。

groovyのクロージャーは本物だ。

| | コメント (0) | トラックバック (0)

既存のソースコードのサンプルサイドがないことが

ソフトウェアの生産性を激減させている。
Webには確かにサンプルソースは転がっているが、一元化
されていないためと、評価機構が伴っていないので
サンプルソースが増えていかない。

これは致命的な事態なのだが、皆が自分のコードを提供するのを
惜しがっているので、このようなサイトが作られないのだろう。

オープンソースとはいうものの、それは利害が一致した場合に
一緒にアプリを作ろうというだけのことをそう呼ぶに過ぎない。

やはり、これは俺がサンプルソースのサイトを作って革命を
起こさなければならない。

| | コメント (0) | トラックバック (0)

人生において重要なのはレバレッジを無駄にしないこと

つまり成功も失敗も必ず次につなげるための肥やしにするというのが要諦だ。
これで失敗がただの失敗ではなくなるからだ。
全てレバレッジを効かすのだ。

| | コメント (0) | トラックバック (0)

しかしそれにしてもH口奴のコードはやはりひどいな

staticブロックの多用(意味不明)

インターフェースを定数の置き場所として使う(バッドパターン)

JavaDocを書いたり書かなかったり(重要なメソッドに書かない)

無限ループの多用(for文の条件部にtrueを書くなど論外)

多重ネスト(なんでというまでのforとwhileのネスト)

コメントの日本語がおかしい(テストケースの日本語もおかしい)

こいつのコードはまじでヤバイというレベルに達している。

悪い意味で格好つけすぎている。

| | コメント (0) | トラックバック (0)

まとめて更新


やっと余裕が出たのでまとめて更新。

●コメントへの返答
特に反論したい意見は無かったので、無しです。

さて、記事を貼り付けるか。。

| | コメント (0) | トラックバック (0)

2011年10月14日 (金)

ふう

コメントには返答をする。
しばし待たれよ。

| | コメント (0) | トラックバック (0)

2011年8月30日 (火)

NoSQLにはポータビリティーを高めるという重要なメリットがある

それは特にJavaのWeb開発において有効なのではないかと思う。
HashMapと配列を使用した簡単なデータベースを使用することで
RDBから離れることができる。
そのメリットは何と言ってもRDBを使用しないことによるデプロイの
容易性と移行の容易性である。

このアーキテクチャは簡単なものだがまだ一般的になっていない。

また重要なのは、このアーキテクチャの場合、マルチスレッドが
必須となるので通常のCGIでは不可能だという点である。

CGIではプロセス空間で区切られてしまうため、メモリ内の
共通オブジェクトにアクセスするという手法が取れない。
ソケット通信を使えば可能だがそれはかなり複雑になってしまう。
またその場合は排他制御が別途必要となりかなり高度な技術が必要となる。

Javaの場合はJEEアーキテクチャによりスレッドで動作するため
個々のリクエスト単位(スレッド単位)で共通のオブジェクトに
アクセスできる。

CGIのプロセスでもスレッドでもRDBを使うのならばそれは
言語の外にあるので違いはなくなるが、インメモリデータベース
を使うとなると両者の違いは大きくなる。

WebアプリにおけるインメモリDBのアーキテクチャが
流行らなかったのは、それがマルチスレッドではなく
マルチプロセスをベースにした技術だったからだろう。

JavaならばJEEがあるので自然とマルチスレッドになり、
インメモリDBを自然に使えるようになる。

ただしインメモリDBの場合はトランザクションは自前で
管理しなければならない。
これは仕方が無いが、これがどれほどのデメリットなのかは
実装してみないと分からないのが正直なところだ。

| | コメント (0) | トラックバック (0)

2011年7月28日 (木)

プロジェクトの健康度

1.情報の隠蔽の有無
2.後だし要求の有無
3.本質と非本質の分別の有無
4.ソースコードの世代管理の有無
5.ドキュメントの世代管理の有無
6.プアフォーマットの有無
7.矛盾的行動の有無
8.スケジュールバッファの有無
9.責任と権限の明確化の有無
10.Tipsデータベースの有無
11.バグデータベースの有無
12.コードレビューの有無
13.作業自動化の有無
14.テスト自動化の有無
15.仕様書と設計書の峻別の有無
16.残業の常態化の有無
17.開発環境の構築手順書の有無
18.ゴールの明確化の有無
19.静かな作業環境の有無
20. コード・ドキュメントへの著名の有無

| | コメント (0) | トラックバック (0)

2011年7月 9日 (土)

やはりDerbyはJavaの宝物だな

何と言ってもインストールの必要が無くWarに含められるというのが大きい。
またJDKに標準添付されているというのも大きい。
DerbyのようにRDBが付属する言語というのは少ないのではないか。
PHPやPythonはSQLITEが標準添付されているがこれはDerbyと同じ意味を
持っているのだろう。
DerbyというDBがJavaで可能なのもJavaがそれだけ堅牢な基盤を持った言語
だからだろう。
TomcatとDerbyを使えばWebアプリはJavaだけで完結できる。
Tomcatのようなアプリケーションサーバーまでならば他の言語でも似たような
ものがあるが、Derbyのような本格的なRDBの例は無いのではないか。
TomcatとDerbyはJavaのWeb開発において超重要なプロダクトである。

| | コメント (0) | トラックバック (0)

Javaの入門本でEclipseを使わないで解説する本は糞だな

JavaとEclipseは一体のものなのにそれを無視してJDKのコンパイラ
でコンパイルする解説しか載せてない本がまだ現役で売られている。
それらの本は本当に糞だな。
学習者にとっては害悪にしかならない。
いづれJavaの開発においてはEclipseが必須になるにもかかわらず、
それを隠して解説するのは犯罪的ですらある。
Eclipse上での解説が載っている本で無い限り信用できないな。

| | コメント (0) | トラックバック (0)

言語の寿命とsh

シェルスクリプトの寿命はUnixの寿命と同じとしていい。
他の言語とは違い、shはUnixと密着しているからだ。
他の言語の寿命はOSとは切り離されているのでOSとは同じではない。
OSを超える場合もあるしそうでない場合もある。
WebサーバーがUnixOSを前提としている時代はまだ10年は続くだろう。
だからシェルスクリプトの有効性も10年は堅いとみていい。
他の言語は10年後は分からない。
RubyやPythonにいたってはすんなりと1.9と3.0に移行できているか不明である。
それらはレンタルサーバーでそれらが使用可能になるかにかかっている。
Javaも10年後は分からないが、おそらくJavaは大丈夫だろう。
JavaにはOracleやIBMやGoogleといった企業がついているからだ。

| | コメント (0) | トラックバック (0)

SSHでのリモート開発

PHPでもPerlでもいい。SSHでのリモート開発ができるのならば。
無論shでもいい。
一番大きいのはやはり開発環境の構築が不要であるという点だろう。
これが非常に大きい。
ただし、そのためにはviエディタやコマンド群などの使い方に習熟
する必要があるが、これは達成可能な目標だし、その価値がある。
といっても基本的にはテキストエディタでの開発なので、それほど
凄い環境を構築するという訳ではない。
端末を複数開いて作業するのが効率的だろう。
またできればTUIアプリでの開発支援ツールも作ってみたい。
DB情報やOS情報やアプリ情報の設定や参照などができるTUIアプリは有益だろう。
またDBとの接続インターフェースのためのshスクリプトがあっても
いいだろう。これをshで作るのは流行の言語に左右されないという意味がある。
SSHでのリモート開発の手法は今後10年は持つという寿命の長さがある。
これは軽量・シンプル・応用が利く、といういみで優れた手法だと確信している。

| | コメント (0) | トラックバック (0)

2011年7月 6日 (水)

RubyとPythonは脱落したかもしれない

両方共に1.9と3.0とで過去の言語との互換性を失ってしまったからだ。
これが与えるマイナスの影響で両方共に元気が無いのだろう。
特にレンタルサーバーが1.9と3.0に対応していないのが痛い。
レンタルサーバーが対応する理由も特別無いのもつらい。
これでLL言語で互換性を失っていないのはPerlとPHPのみとなった。

| | コメント (0) | トラックバック (0)

2011年7月 5日 (火)

ドキュメントヘル

プアフォーマットとドキュメントの世代管理をしないことで
プロジェクトはドキュメントヘルに陥る。

ほとんどのプロジェクトにおいて、ドキュメント作成に
費やされた膨大な労力とエネルギーは全て無駄になる。

仕様書と設計書の違いも判然としないプロジェクトが
ほとんどだ。

仕様書は有益だが設計書は無益だ。

ドキュメントのフォーマットはSEが決める。
大抵は拡張性も柔軟性もないフォーマットなので
真面目に書いても役に立たない。

このようなフォーマットをプアフォーマットと呼ぶ。

| | コメント (0) | トラックバック (0)

レンタルサーバーでのCGI言語の制限は言語の隆盛に大きな影響を与える

無論、ここで問題としている言語はWebアプリ開発のための言語だ。

CGIの開発言語で何が使えるのかはサーバー管理会社が決める。
Apacheの設定を固定してしまえば開発言語は固定できる。

どんなに優れた言語でもレンタルサーバーで規制されれば流行ることは無い。
Python 3.0 が流行るかどうかはレンタルサーバーでそれが使用可能になるかにかかっている。
Ruby 1.9 においても事情は同じだ。

VPSならば完全に自由になるのでどんな言語でも使えるが、
環境構築のコストがかかってしまう。

Javaがレンタルサーバーで使用できることが少ないのになぜ流行ったのかというと、
企業の内部で広く使われたからだ。
そしてこれが同時にJavaの最大の弱点になってしまっている。

その点Rubyがレンタルサーバーに組み入れられたのは僥倖だったはずだ。

| | コメント (1) | トラックバック (0)

2011年6月15日 (水)

ソフトウェアを少しずつでも開発していく方法

・Webで必要な技術情報を集めておく
・技術的にグレーなゾーンだと判明した場合はそちらには進まない
・EXCELで外部デザインの仕様書を書く
・HTMLで簡単なサンプル画面を作る
・部品となるメソッドとクラスを作成しておく
・新しいアイデアや構想をメモに追記していく
・毎日少しずつ。毎日、少しずつ。

| | コメント (0) | トラックバック (0)

2011年6月 7日 (火)

言語なんてなんでもいいという人

まあある一時期はそれが通用する時期もあったかもしれないが、
現状ではほぼ間違っている状況になったね。
企業が安心して10年任せられる開発言語は極めて少数だし、
モバイル、デバイス、OS、アプリ、それぞれに適した開発言語がある。

言語がなんでもいいといえる状況というのは、簡単な文字列処理や
数値処理を処理するのがメインの処理の場合ではないかな。

巨大企業のバッチ処理や、Webアプリのサーバー側は比較的その状況に近い状況だった。
しかし最近のレンタルサーバーでは使える言語は PHP、perl、Ruby、Python、
の4つがほとんどだから、VPSを除くと結構サーバーサイドも限られてきているのが現状だ。

モバイルアプリ、デスクトップアプリに関してはより言語の選択は限られている。

また、VB6の例を見ても分かるが、作った後にサポートが打ち切られる
というリスクもかなり大きなリスクとしてある。

言語には適切な使用分野とメンテナンス限界があり、
その2つがその言語の生存期間を決める。

使用人口が多くMicrosoftという巨大企業がメンテナンスをしていた
VB6でも寿命を迎えてしまった例もある。
VB6はサポートは続けられるだろうが、現役ではないことは事実だ。

こうしてみると、言語の選定には極めて慎重になるべきだ
という結論にならざるを得ない。

言語なんてなんでもいい
という意見に同調するかどうかは、その人のアプリケーション全般に
関する大きな価値観の表明に等しい。

まあこういっては何だが、言語なんてなんでもいい、機能が実現できれば
と言っている人に限って、プログラマではなく生粋のSEやコンサルである
ことが多いように見える。
これは彼ら自身の生存戦略においては譲れない一線なのだろう。

| | コメント (1) | トラックバック (0)

2011年5月19日 (木)

数式が仮説の表明であると解釈すると、数式に対する恐怖心が無くなる


これは私が体験した事実である。
これが数式の自由性であり、数学の自由性なのである。
この自由性が学校教育では決して教えられないタブーとなっている。

しかしこの自由性を獲得することこそが数学を理解するうえでの絶対条件なのである。
数式間の論理関係は数式上には出てこない。
これを表出させようとしたのがヒルベルトの計画であり、彼はこれを超数学と呼んだ。
これ自体は普通の試みではあったが、しかしそれでもそれを表出させるのは人間の役割だった。

数学には2つの領域がある。
それは記号とイメージだ。
記号は数式であり、イメージは幾何学的なイメージとなる。

問題はどのようにして強力で柔軟なイメージを獲得できるかだ。

そして、さらに重要な問題がある。

それはそのイメージと数式の間をどのようにして自由に変換できるかだ。

この部分が数学の最大の奥義となっている。

この部分も学校教育では決して教えられることは無い。

| | コメント (0) | トラックバック (0)

シェルスクリプトというWindowsサーバーにとっての敵


SFUとCygwinがあるが、これらはWindows上に仮想UNIXのファイルシステムを
構築するようなものであり、通常のインタープリタ言語のランタイムとは異なる。
そもそもシェルスクリプト自体がUnixというOSに密着しているため、
仮想OSでUnixを動かすというレベルをしない限りシェルスクリプトの完全な
移植は難しい。

企業が馬鹿高いSolairs、AIX、HP-UX、からWindowsサーバーにリプレイスを
考える場合、もっとも移植に困るのがシェルスクリプト群だろう。

C言語で書かれたネイティブのアプリは無論移植できないが、
そのようなアプリはそもそも少ないと思う。

がしかしシェルスクリプトは別だ。
使われまくっている。
PerlやPythonなどのランタイム型言語ならばOS毎にランタイムが作られているので
移植は容易だ。微修正は必要だろうが。

かといって仮想環境上のUnixを使うというのは単にシェルスクリプトのため
だけに行うというのは馬鹿げている。

現状での答えは、MSが出しているSFUを使うか、それとも別の言語に移植を
するかのどちらかだろう。

その意味からすると、シェルスクリプトという言語はUnix系OSから離れるときに
リスクを抱えている言語ということになる。
そのリスクの根源はシェルスクリプトがUnixOSと密着した言語という性質からきている。

そのことを意識している企業はシェルスクリプトではなく別の言語を
サーバー管理用の言語として使用するのではないか。

とは言ってもそこまで考えている企業は無く、SFUを使うのだろうが、
SFUも今後安定して提供される保証は無い。
それにシェルとの完全な互換性も無い。

いづれにしてもシェルスクリプトはUnixサーバーのロックインの大きな要因となっている。

| | コメント (0) | トラックバック (0)

Perlの謎。なぜPerlはフォークしないのか


Perlはなぜ長い間互換性を保ち続けることができたのか。
それは大きな謎である。
またプロジェクトがフォークしなかったというのも謎である。
ここには未だ公開されていない理由があるに違いない。
一つの理由はCPANによる互換性維持の圧力だろう。
CPANはライブラリであると同時に互換性テストのテストキットでもある。
しかしそれでもそれは本質的な理由にはならない。

たしかにバージョンがあがるたびに多少の互換性は失われてきた。
それでもRuby、PHP、Pythonほどに激しくはなかった。
これも謎である。

一つはLinuxやUnix関係からの互換性維持の圧力があるのかもしれない。
すでに内部でPerlはシェルスクリプトと同じくらいの重要な部品になっているからだ。

Perlがシェルスクリプト化しているのが互換性が保たれている
要因なのではないかというのが現時点の思考の限界。

| | コメント (0) | トラックバック (0)

速読というか、無意識のフィルタリングの利用


問題意識を抱えた状態で文章をトレースして、目に付いたところを
読むようにする。
無意識が重要な箇所を判定するので、目に付いたところ意外は無視する。
これが無意識のフィルタリングを利用した速読。
コツは強い問題意識を保持した状態でトレースをすること。

| | コメント (0) | トラックバック (1)

shはサブシェル問題があるし、OSとの密着性があるので駄目だな


たしかに言語はシンプルで素晴らしいが、サブシェル問題という致命的な
問題点を抱えている。
サブシェル問題とはパイプなどで裏側でプロセスが分岐してしまい
変数も2重にコピーされて存在してしまう問題を言う。
またOSと密着しているためにポータビリティーがない。
またOS毎に微妙に設定や仕様が異なるため動作確認テストが必須となる。

一方、LL言語はどれも致命的な問題を抱えている。
Perl:言語仕様が古過ぎるのとサポート体制が不安
Python:3系への移行が進んでいない
Ruby:2系への移行が進んでいない
PHP:一応は問題なしかな?

このなかでましなのはPythonとPHPだろう。
PythonはGAEが使えるのが大きい。
PHPにはZendが、PythonにはGoogleが裏でバックアップしているのが強い。
開発言語というのはネットワーク性を持っていない限り、
企業がサポートし続けないと死んでしまうのである。

perlは例外だが、あとで仮説を書く。

shは将来はAS400のRPGやメインフレームのJCLと同じく、
OSに密着した言語として定着するだろう。
WindowsのVBAも同じだ。
メインフレーム:JCL
AS400:RPG
Unix:sh
Windows:VBA
これらの言語はOSと密着しているがゆえにOSベンダーから
守られて互換性がほぼ完全に維持されるという強みがある。
だからなくなることは無いがどうしてもニッチな言語になる。

| | コメント (0) | トラックバック (0)

企業内部からの内部革命

プログラマが業務の中核を担うツールを作り、それに業務システムが
依存するような展開にしてしまう。
そして皆の要望をつのってそのツールの改良を続ける。
ただしそのツールは普通のプログラマでは手出しができないレベルの
ツールである必要がある。
やがて、そのツールはプロジェクトに必須のものとなり、
そのプログラマの評価と重要性は上がることになる。
そしてころあいを見て自分の要求を小出しに出していく。
もしそこで待遇が変わらないのならば組織を去ることを脅し文句として使う。
実際に変わらなければ数ヵ月後を目安に去る。
一度うまくいった場合はまた別のツールを作成してそれに皆を依存させるように仕向けさせる。
そのツールは市販には同じものがなく、煩雑な業務を楽にしてくれるものである必要がある。
業務時間中と残業時間を利用して開発をする。

| | コメント (0) | トラックバック (0)

サーバー側のエンジンになりえるソフトウェア

それをサーバーウェアという。
Webサーバーは入り口に過ぎないので除外できるが、
これもサーバー側のエンジンの一種である。
私はそのようなバックエンドで活躍するエンジン部分に相当するソフトウェアを
Javaで作成したい。
その領域がまさにJavaの領域なのである。
Hadoopはそのいい例である。

| | コメント (0) | トラックバック (0)

2011年5月18日 (水)

コメントへの返答


kekyoさんへ

>そうはいっても、MVCをどう近代の開発に生かしていくのかという知識(パターン?)が確立されていないように思います。現場の一部のコードでMVCで必死に書いても、結局そのほかの部分と一貫性が無いです。開発者全員が「高度な技術」に精通していないと、簡単に破たんしてしまいます。PHPのようなスクリプト言語ではなおさらだと思います。

投稿: kekyo | 2011年3月21日 (月) 21時50分


MVCというのはもうバズワードなんです。
意味が無いんです。

Mというのはオブジェクトですよね。
VはそのGUI表示機能で、Cは制御でしょう。
つまりここでは1つのオブジェクトしか想定されていない。

でも現実は2つ以上のオブジェクトが相互作用しているのがほとんどです。
Webアプリなので、画面(V)とデータベース(M)とロジック(C)という
分類は可能ですが、これだとどんなWEBアプリでもMVCなので問題なしになりますね。
でもこんなのは意味ないですよね。

現実は、画面もロジックもデータベースも皆オブジェクトになっています。

データベースをSELECTとして結果を画面上にテーブル形式で表示させます。
次に画面上でテーブルを編集して更新ボタンを押すとデータベースが更新されるようにします。
ここでは画面とデータベースの2つのオブジェクトが相互作用しています。

このような相互作用が並列で起きているのが現実のシステムです。

この処理パターンの命名と分類がまだ為されていません。

これに本気でかかわるとやばいのを察知しているからでしょうが、
このようなことは「無い」ことになっています。

これが現状です。

あまりにも難しい問題は無視されるのが人類の歴史です。
そして解決可能な道具が揃った時点で問題が命名されて解決されます。

| | コメント (0) | トラックバック (0)

LL言語は職場で使えないことの返答


返答が遅れました。

私はかならず返答用の記事を書くので、書かれない場合は、返答の意志がないものと解釈してください。いつ返答するかはわかりません。気が向いたときです。


>のなめさん
SI業界の人やセキュリティに厳しい現場の人じゃないと記事で書いている事の意味はわからないでしょうね。eclipseは「使用が許可されたソフト」だから使えているんですよ。たかが見解の不一致で人を見下すのはよくないですね。

投稿: tks | 2011年4月 3日 (日) 14時09分

私は環境構築まで含めてエンジニアの仕事と考える。
コーディングのみが仕事ではないということは、
十二分にご理解いただけるはずだ。
Eclipseは外部からインストールしたものにも関わらず
「外部からのインストールができない」
というのはなんともおかしな話である。

もう一点、Javascriptは確かにサーバー側からすれば
確実なものかもしれないが、クライアント側からすればそうではない。
ブラウザ毎に動作が違ったり動かなかったりするものが確実だろうか。

傲慢な考えは視野を狭くする。

投稿: のなめ | 2011年2月21日 (月) 00時38分

こんにちは、はじめまして。
記事の内容について、確認させてください。
LL言語が現場では使えない理由は、以下1)もしくは2)のいずれか、と悟られたのでしょうか?
1)インストール作業が煩雑
2)ダウンロードできない環境が多い
3)その他

投稿: みち | 2009年6月24日 (水) 15時52分

うむうむ。

まず、以下の前提があります。
1.セキュリティの厳しい現場で開発作業をしている
2.持ち帰り案件ではないので開発環境は自由に構築できない
3.IBMのRADというEclipseを含む統合開発環境を使っている。


もし持ち帰り案件で、プログラムだけを相手に収めればよい
というのならば、収めるプログラム自体にウイルスやバグが混入していなければ
開発環境は完全に自由ですね。
でも持ち帰り案件自体が現状少ないですし、持ち帰った先の会社でも
開発環境が自由であるというのは少ないのではと思いますよ。
特にセキュリティが厳しくなっている現状では。

私は
「大企業の社内システムを開発している典型的なJavaプログラマ」
を対象に記事を書いています。

その状況下で必ず使えるソフトウェアや技術を見つけ洗練させていくことを目的としています。
ほぼ必ず使えるのは、
1.JDK
2.Eclipse
3.Ms Office
4.秀丸
5.Windows
6.SSHクライアント
7.RDBMS
くらいです。

フリーウェアの類はインストールが禁止されている場合が多いです。
インターネットは繋がっていません。だから本が頼りです。

上記のソフトウェアから使える開発言語は、
1.Java
2.VBA
3.JavaScript
4.バッチファイル
5.秀丸マクロ
6.シェルスクリプト
7.XSLT
8.ANT
9.SQL
10.ストアドプロシージャ
くらいです。

さらにシェルスクリプトはセキュリティ上使えるところが
少なくなってくると予想しています。

世間で流行となっている技術は試せません。

結局頼れるのはJavaとVBAくらいなんです。
あとはそのほかの言語も状況に応じて使いますよ。

それでもやれることは十分にありますよ。
1.Java
2.VBA
3.JavaScript
4.バッチファイル
を組み合わせれば、社内でWEBアプリ開発も可能だし、
できないことの方が少ないでしょうね。


ただ、LL言語(perl、python、ruby、php)は今後も使えないでしょうね。

pythonだけはjythonとしてRADに含まれていますが、いまいち有効な使い道が
わかりません。

| | コメント (0) | トラックバック (0)

失業中の中年男さんへ


コメントありがとうございます。

大地震もあり、私生活もいろいろとあり、面倒臭いというのもあり、
回答が遅れました。

暇なんで書きます。

>ブログ読ませて頂きました、私もVBAは低コストで開発でき,VBS,APIも使える凄い言語だと思います。SQLもモジュユール内で実装できます。VBAを下等な言語と言うSEもいますが大間違いだと思います。因みに私が投稿したVBAのサンプルも
覗いて見て頂ければと思います。
http://89395735.at.webry.info/

VBAは確かに「凄い」ですよ。
一般的な用途の業務プログラムならばほぼ問題なく作成可能です。
MSが切ることは難しいでしょうね。
もしVBAを切ってしまった場合は、MSのOfficeに拘る理由の50%は消失するでしょうからね。
だからVBAは生き残ります。

MSは確かにVBを切りました。
VBRuntimeは生き残っていますが、開発環境はサポート切れています。

しかしVBAはOfficeと一体化されています。
よってVBAを切ることはOfficeの生態系を破壊することになります。
MSがOfficeをクラウド上のOfficeに強制移行させたい野望をもっているのならば
考えられるでしょうが、かなりの反発があるので無理でしょうね。

VBAは生き残ります。

VBAを使えばプロジェクト内の様々な業務を自動化できます。
失業中の中年男さんのBlogを見ましたが、けっこうマニアックな知識を持っているので
十分に可能なことはご承知でしょう。

VBAを下等な言語と思わせておけばいいんです。

またVBAにはコードを非公開にする機能もあります。
これも使うことで自分の技術の漏洩を防げるでしょう。

VBAで高度なアプリケーションを書いて社内で使用してもらうのが一番
自分の身の安全に寄与すると予想します。
テーブル、フォーム、VBA、VB、VBS、Win32API、これらを駆使すれば
業務上の重要なツールを作ることが可能でしょう。
ちなみに私も同じことをしています。

ただVBAの場合、コードが3000行を越えるあたりからリファクタリングが
難しくなります。

| | コメント (0) | トラックバック (0)

2011年3月 3日 (木)

JavaにおけるGUIの重要性

もしJavaが自前のGUIのAPIを持っていなかったのならば、
EclipseやNetBeansは存在できなかっただろう。

クラスを用いた大規模な開発はGUIのIDE環境を必要とする。

それが使えないとなるとテキストベースの開発となるが、
そうなるともはやコード補完や定義参照やリファクタリングが
うまく行うことができなくなる。

結果的にはそうなるとC++がそうであるようにIDEが無いOS上
ではJavaは流行らなかっただろう。

Eclipseが生まれたがゆえにJavaはやっと普及したのだ。
EclipseなどのIDEはJavaの開発に必須であり、これらが無くなると
間違いなくJavaは死ぬ。C++がそうであるように。

テキストエディタではJavaの開発は不可能なのだ。

そうなるとJavaが自前のGUIのAPIを持っていることこそが
Javaにとって最も重要な性質であることがわかる。

サーバーサイドのプログラムが重要なのであってデスクトップ
のGUIプログラムは重要ではないと考えている人たちはJavaの
開発環境とGUIの重要性を分かっていない。

サーバーサイドのプログラムもIDEから生み出されるのであり、
そのIDEはGUIのライブラリに全面的に依存しているのである。

GUIを持たない言語でクラスベースの大規模な開発に耐えられる
言語は存在できない。
それはGUIのIDEを人間が必要とするからだ。
UNIXでのC++の敗因はそこにある。
WindowsでのC++の勝因もそこにある。

もしテキストベースでの開発で人間でもできるようにしたいのならば、
CやJavaScriptくらいが人間にとっての限界だろう。
PerlやPHPくらいには最低でも単純にしなければならない。
それらでもオブジェクトをベースにする開発はきついだろう。
オブジェクトを扱う場合はコード補完が必要となるからだ。
だからCやPHPやJavaScriptのようにオブジェクトではなく関数を
メインに据えた言語のほうがテキストベースに向いている。

Javaを殺すのならばJavaのGUIを殺すのが一番いい。
そうすればIDEが死に、結果的にJavaが死ぬことになる。
GUIのIDEが死ねばJavaはテキストベースの開発には移行できないからだ。

| | コメント (0) | トラックバック (0)

2011年1月25日 (火)

リアルタイム処理の重要性

人生において「すぐに行動する」ということの重要さはいくら強調してもいい。
そして仕事においても「その都度リアルタイムで処理する」という行為の重要性
も同じように強調していい。
リアルタイム処理というのはバッチ処理よりも本質的に優れているのだ。

バッチ処理の方が単純で処理しやすいが、多くの欠点を持っている。
リアルタイム処理は複雑で処理が難しいが、多くの利点がある。

リアルタイム処理においては処理をするエンジンがとても重要になる。
人間においてはそれは概念セットや思考法や感覚などの内面的な
ソフトウェア全般を指す。
これらソフトウェアがリアルタイム処理のエンジンとなる。

リアルタイム処理の能力は常に研鑽し続けることが必要だし、
その見返りは必ずあるので、その価値があるといえる。

リアルタイム処理はフローを扱うが、バッチ処理はフローを一端ストックに
変換して、ストックを処理する。

フローをストックに変換せずに処理をして出力をするのがリアルタイム処理である。

ストックを別のストックに変換するのがバッチ処理だ。

人間に例えると、同時通訳がリアルタイム処理の例で、翻訳家がバッチ処理の例だ。

ジェイソン・ボーンを見れば分かるように、極限の状況ではリアルタイム処理以外は
役に立たない。

| | コメント (0) | トラックバック (0)

2011年1月10日 (月)

コメントへの返答

VBAは便利なのですがVB6の遺物のような気がするのですが。プログラミングも.NETになれるとVBAはあかぬけない感じがしてきて使いづらいし、.NETとVB6が平行して残るのはマイクロソフト的にサポートや開発効率に無駄が多い気がしますが。VBAは将来.NET系に移行していくのではと思うのですが。意見をききたいのですが

VBAは確かに.NETへの移行にとってはレガシーな資産であり問題と言えます。

ただし、MicroSoftはVB6ランタイムのサポートを継続しており、
VBAのサポートも今後も続けるでしょう。

.NETは Windows Phone 7 などのスマートフォン環境の言語環境として
本領を発揮するでしょう。
この領域はネイティブコードでない方が望ましいからです。
そして現時点でまさにそのように使われています。

VBAの問題はその言語仕様の特異性が最大の問題であると言えます。
実はVBAは言語としてはかなり強力なのです。

●VBAの言語仕様の特異性
1.VB6とほぼ同じシンプルな言語仕様
2.Win32APIに透過的にアクセス可能なので高度なアプリが作れる
3.VB6とは異なりコンパイルの必要がない
4.Office内にランタイムと高度な開発環境が含まれる
5.Officeの普及度による高いポータビリティ
6.フォームビルダーによるGUIアプリの構築容易性
7.膨大なマクロ資産があり現在も増大中

もしOfficeが.Netのアプリケーションとして配布されるようになった場合は、
VBAから脱却することになるでしょう。

Officeの.Net化は現時点でも可能でしょうが、MicroSoftがそれを実行するかは
微妙だと思われます。

.Netの実行形式は逆コンパイルによってコード内容が把握される可能性があるからです。
そうなった場合、Officeのコードが公開されることになってしまいます。

そのリスクをMicroSoftが犯すかどうか。微妙です。


●予想
1.MicroSoftはOfficeを.NET化しない
2.VBもVBAもサポートされ続ける
3..NETはスマートフォンの分野で本領を発揮する

まあこんなところですね。

| | コメント (0) | トラックバック (0)

2011年1月 3日 (月)

ハードウェアに密着した言語

ハードウェアを制御できるプログラミング言語こそが最も強いはずだ。

私が思い描くのは、ターミネーターに出てくるサイバーダイン社の技術のイメージである。

あの会社の技術を映画の中で詳細に見ていくと、ハードウェアとソフトウェアとが
完全に融合していることが分かる。

現時点ではそれはC言語ということになるが、Cではサイバーダインは無理だろう。

C++でも駄目で、Objective-Cならばなんとかなるかもと感じる。

なぜObjective-Cは組み込みに使われないのだろうか?

やはりISOやANSIやECMAの標準になっていないのが痛いのだろう。

Cに置き換わるハードウェア層を制御できる高級言語の出現は間違いなく
人類の歴史に大きな影響を与えるはずだが。。。

かといってGO言語やD言語はあまり流行る気配がない。

| | コメント (0) | トラックバック (0)

MVCは死んでいる

WebアプリケーションにおけるMVCパターンはすでに死んでいる。
ページが静的なHTMLから動的なJavaScriptを使用したページになり
状態を保持するようになった時点でMVCパターンは崩壊したのだ。
しかもそれはAjaxを使用することで余計に加速された。

Ajaxを多用するということはページが単なるViewではなく、
オブジェクトになったことを意味する。

サーバー側にもモデルというオブジェクトがあるのだから、
結局はオブジェクト同士の相互作用というのが実態に近い。

MVCとは一つのオブジェクトを3つの部分に分割するというパターンである。
複数のオブジェクト同士の関係については何も言っていない。

このオブジェクト同士の相互作用のパターンというのが現時点でも
未解決のデザイン問題として残っている。

これはかなり複雑な領域であり、容易にモデル化を許さない。
しかも相互に参照しているのではなく、相互に作用しているのである。

実は通常のGUIアプリケーション全般においてMVCは通用しないのだ。
それらは全てオブジェクト同士の相互作用のデザインの問題となる。

| | コメント (2) | トラックバック (0)

2011年1月 1日 (土)

ユニークオブジェクトの概念

システムに必ず1つのみ存在するオブジェクトをユニークオブジェクトという。
ユニークオブジェクトはただ1つのみ存在し、そしてそれ以上増やすことはできない。
生成も消滅もせず、そしてその影響はその言語の全領域に渡る。

だからユニークオブジェクトはそのプログラム言語内のパラダイムからは
ちょっと異なる存在になっている。

ただしこの場合のシステムという言葉の定義は曖昧で、OSであったりVMであったり
あるいは特定のシステム領域であったりする。

ユニークオブジェクトはプログラマが定義することは無く、
最初から存在しているとみなされる。

ExcelのVBAではWorkbookはユニークオブジェクトであり、
JavaではSystemクラスはユニークオブジェクトの例だ。

ユニークオブジェクトが特に繊細な問題として現れるのは
マルチスレッドでユニークオブジェクトにアクセスする場合だろう。

ユニークオブジェクトはプログラマが自身で定義した存在ではないため、
マルチスレッドでの取り扱いについ油断してしまう時がある。

最悪はそれがデッドロックになって現れる。

ユニークオブジェクトは明示的にスレッドでアクセスされることが
わからない場合がある。

デッドロックのバグは最悪で原因不明のハングとなって現れることが多い。

そのような場合はユニークオブジェクトにスレッドがアクセスしていないかを
確認するのも有効な検証方法の一つだ。

| | コメント (0) | トラックバック (0)

オブジェクト指向とオブジェクトという言葉の混乱


・オブジェクトとデータ
状態を持つ対象をオブジェクトという。
状態を持たない対象をデータという。

・オブジェクト指向とデータ構造
オブジェクト指向言語のデータ構造はツリー構造となる。
オブジェクト指向言語がツリー構造になる必然性は無いが、
人間にとって扱いやすいデータ構造のためであろう。
オブジェクト指向とRDBの最大の違いはオブジェクトとデータの
対立にあるのではなく、データ構造の違いにある。
それはツリー構造とテーブル構造の違いである。
RDBは最小単位は状態を持たないデータを格納するが、
テーブルはそれらの集合として状態を持っているためオブジェクトとなる。
ただしオブジェクト指向言語におけるツリーの階層が複数階層が普通
なのに対して、RDBのテーブル構造の階層は1階層のみなので現状では
RDBの方がかなり単純なデータ構造となる。
RDBが複数階層のテーブル構造を実現しないのは人間にとって複雑すぎるからだろう。

・状態指向と生成指向
一つのオブジェクトの状態変化によって対象を表現するか、
それとも複数のデータを生成することで状態を表現するのか
という違い。
後者のスタイルもオブジェクト指向言語には取り込める。
後はどちらが人間の認識にとって自然かという問題になる。
生成指向は関数プログラミングと言われている。
両社は発想が全く異なる。
生成指向では予め生成しておけば状態変化のコストが無くなる。
ただしそのためのメモリを多く必要とする。
状態指向では(以下略)。

| | コメント (0) | トラックバック (0)

2010年12月31日 (金)

シェルスクリプトの最大の弱点

それはDBとの接続インターフェースが無いこと。
ストアドプロシージャを使うことでレコード単位の処理は可能になるが、
それだとDB内に閉じているため、外部リソースとの連携が難しくなる。
同じことはPL/SQLについても言えるが、こちらの場合はパッケージという
仕組みで豊富な機能が用意されている。
仮にストアドを使わないでパイプによってDBからの出力を処理するとしても、
それはテキスト処理となってしまい出力のフォーマット形式に大きく依存
してしまうという欠点を持っている。
SELECTの結果は複雑なテキスト形式のため、それらの形式の違いを全て
シェルによって吸収できなくてはならない。
しかも吸収できたかどうかは人間によって確認するしかない。
無論それはDBベンダー毎に異なるし、DBバージョン毎に異なるだろう。
またダブルバイト文字の有無によってもことなるだろうし、最悪はOS毎に
よっても異なるだろう。

| | コメント (0) | トラックバック (0)

GPLの問題とその検証法

よくGPLのコードを流用するとそれを組み込んだソースコード全体を
公開する義務が生じるから使わない、という主張を見る。

またそれに反してそれはGPLに対する誤解であり、必ずしも公開は義務
ではないという意見もある。

結論は不明であり、結局安全策を取ってGPLコードを使用しないという
流れになるケースが多い。

しかしこれは簡単に検証することが出来るだろう。

意図的にGPLコードを使用してクローズコードの製品としてソフトウェア
をリリースしてみればいいのだ。

それで公開の要求に対して拒否をして見て裁判で白黒を付ければいい。

予めグレーなケースを複数想定して極めて簡単な製品を作ればいい。

そうすれば前例ができてGPLの問題は少なくとも解消の方向に向かう。

手順はこうだ。

1.最低2人の人間が必要。
2.簡単なコードをGPLとして公開する。
3.GPLコードを組み込んだ簡単な製品をリリースする。
4.コードの公開要求を出して拒否する。
5.裁判を起こして白黒付ける。

この手順を複数のケースに対して起こす。

裁判費用と弁護士費用がかかるだろう。

しかしこれはやってみる価値があると思う。

オープンソースの世界に対して根本的な影響を与えるだろう。

逆になぜこれが行われてこなかったのかが謎である。

| | コメント (0) | トラックバック (0)

2010年11月26日 (金)

データ構造の種類

データ構造には抽象的なレベルで種類がある。
テーブル、リスト、マップ、ツリー、集合、など。
これらの中でもテーブル構造は経験的に最も利便性が高いことが分かっている。

現実にはデータ構造なんてものは人間に認識できる静的な構造の一部に過ぎないが。

SQLやRDBが成功したのもこのテーブル形式のデータ構造を専用に扱ったことが大きい。

また将来において、テーブル形式を言語の基本データ型に組み込んだ言語は
成功する可能性が高まるだろう。

C#のLINQはその意味では革命的である。

LINQは隠れた開発言語の革命だったのだろう。

LINQの導入はMicrosoftの偉大な功績になるに違いない。

Javaにも早急にLINQは導入されるべきである。
言語機能ではなく標準ライブラリでいいから。

オブジェクトとは実はツリー形式のデータ構造である。
クラス、メンバー、の階層構造だ。
これはテーブル構造を吸収できなかった。
ツリー構造もテーブル構造と並んで強力なデータ構造である。
オブジェクト指向とはこのツリー構造によって世界を包摂してしまおうという試みだった。
しかしテーブル構造の包摂には残念ながら失敗してしまった。
また逆にテーブル構造からツリー構造を包摂する試みも失敗した。
オブジェクトデータベースの試みがそうだった。

結局、ツリー構造もテーブル構造も互いに吸収できないほど豊かなデータ形式なのだ。
この2つは並存せざるを得ない。
あるいはこの2つを吸収できるようなより柔軟で強力なデータ構造を発見するしかない。
しかしまだそれは発見されていない。

| | コメント (0) | トラックバック (0)

ツールはJavaで作る方がいいか?

VBAは確かに便利で特にExcelのVBAは最強に近い。

お手軽なGUIが実現できるだけでなく、何と言ってもExcelという
テーブル形式のデータ構造が最初から利用できるという点が一番優れている。

テーブル形式のデータ構造は見た目に反して実はかなり複雑なデータ構造である。
そしてそれゆえに汎用性があり非常に便利なのだ。

その点でテーブル形式はリスト形式やマップ形式などのデータ構造に
比べると段違いの価値がある。

他の言語ではテーブル形式のデータ構造を先ず最初に構築して、そこに
データを流し込んでから、テーブルを利用する必要がある。

Excelの場合は最初から土台となるテーブル構造が準備されている。
それも非常に良くできたテーブル構造だ。

HTMLでもSwingでもC#でも皆テーブル構造の部品を作ろうとすると途端に
複雑になるのが分かる。
HTMLのテーブル、SwingのJtable、C#のGrid、どれも複雑である。
そしてそれらは皆大きな価値を持っている部品だ。


さて、Excel VBA は確かに強力であることが分かった。

しかしExcel VBA に全面的に依存していいだろうか。

それはWindowsにロックインされることを意味する。

別にロックインされてもいいのだが、ここはより可搬性があるJavaで作った方が
後々においてはいいかもしれない。

JavaのSwingプログラミングはVBAに比べると生産性では半分以下であるが、
しかし可搬性は段違いだ。

| | コメント (0) | トラックバック (0)

Javaのgenericsはやはり使えない

なんとかして有効活用したいのだが、かなり無理っぽい。
コレクションに対しては一般に語られているのとは逆にほぼ使えない。
参照の代入をコンパイラが見張ってくれないので型制約が破壊されるからだ。

それ以外では、メソッドとクラスに対する型指定があるが、
こちらも使えない。

そもそもどんなときに型パラメータが使えるのかという文法に統一性が
全く無く、genericsの文法面での必然性が普通のプログラマには理解不可能な
レベルである。

C++のテンプレートとは全く異なる。

genericsはやはり現状では失敗している。

ただし最後の希望はある。

それはJavaのコンパイラを強化することだ。

これによってgenericsが強化される可能性は残っている。

幸いにしてgenericsは使用を強制される機能ではない。

もしJavaでテンプレートのようなプログラミングがその半分でも可能に
なったのならば、それだけでもgenericsの価値はある。
しかし現状では1割にも満たないだろう。

| | コメント (0) | トラックバック (0)

C++は死に瀕しているかもしれない

なぜUnixではCが主流なのか。
なぜならばUnixではまともなGUIが使えないから。
だから、GUIの開発環境を必要とするC++は使えないことになる。
CUI画面ではC++は開発できない言語なのだ。
Unixの反GUIという哲学が、C++に対する巨大な防波堤となっている。

なぜC++プログラマはWindowsプログラマなのか。
なぜならば、C++のまともな開発環境を提供しているのはMicrosoftだけだから。
そしてWindowsはGUIが安定しているため、C++のための安定した開発環境を構築できる。

だからC++での開発といった場合、デバイス系とWindows系がほとんどとなる。

しかしデバイス系ではC++よりもCの方が優勢でありそれは今後も覆らないだろう。

C++が優勢なデバイス系はかなり複雑な機能が必要とされる分野となる。

その代表例が携帯電話であった。

しかし最大の頼みの綱であった携帯はiphoneとandroidによって将来はC++を
必要としない方向性になってしまった。

またそれら以上によりハードウェアに近い領域ではC++よりもCの方が優勢になる。
これはCの方がシンプルで少資源なので覆らないだろう。

Windowsではどうか。

以前はVC++が隆盛を誇っていたため、C++は圧倒的な存在感を持っていた。

しかし現在は徐々にC#にアプリケーション開発言語の座を譲ろうとしている。

実際その方が効率がよく言語も開発環境も洗練されているからだ。

ただしWindowsでもよりデバイスよりの領域では相変わらずC++が必要となる。

つまりC++が生き残る領域とは、ハードウェアとアプリケーションの中間領域
となる可能性が高い。

それはOSの領域になるだろう。

オペレーティングシステムに密着した領域だ。
ここだけはC++の生き残れる領域だろう。
より言うならば、WindowsOSのデバイス寄りの領域だ。
さらに携帯電話のOSよりの領域。
この2つくらいだろう。

残念ながらUnixやLinuxではC言語がすでに大規模なアプリも包摂しており、
C++が入り込める領域が無くなってしまっている。
これはUnixがGUIを捨てたために起きたほぼ必然的な展開である。

さらにC++0xが策定されているが、実際のところ、C++のまともな開発環境は
Windowsだけなので、これも影響はWindowsに限られるだろう。

結局、C++はその生き残る領域を確立できなかったと言っていい。

1.言語仕様が複雑すぎたこと、
2.まともな開発環境がWindowsしかなかったこと、
3.C#が出現してしまったこと、
4.携帯電話がiphoneとAndroidに喰われてしまったこと、
5.UnixやLinuxではCに敗北してしまったこと、
6.Javaが出現してしまったこと、

などが複合的に起きた結果だった。

特に痛かったのは、3と4だろう。
Windowsと携帯電話という2つの大きな領域を失ってしまったのは大きい。

将来においてC++がその隆盛を取り戻せるとしたら、以下のケースがある。
1.Windowsの開発がC#からC++に逆流する
2.携帯電話以外の携帯デバイスが隆盛する
3.新しいOSの開発が盛んになる

どれも可能性はかなり低い。

結局、C++の最大の失敗はやはり言語仕様の複雑さだろう。
結果的にその複雑さが受け入れる価値があると判断されなかった面がある。
それを受け入れることによる収支が合わなかった。

| | コメント (0) | トラックバック (0)

企業は安定した言語を求める

少なくとも10年は安定していて欲しい。
開発の投資が無駄になるような言語は嫌われる。
だから、LL言語は大企業に嫌われる。
言語が安定しているとは言えないからだ。
PHPは唯一そのような安定性を獲得しつつある言語であるが。
その他に安定している言語となると実はかなり少ない。

現役で一般的に使用されている言語で安定性を獲得している言語
というと以下のものくらいだろうか。

C、C++、COBOL、sh、Java、VBA、C#、VB.Net、JavaScript、SQL、PL/SQL、PHP

とても少ないことに気付く。

だから、この少ない言語の幾つかに習熟することが現実の生活上は重要となる。

尚、VB6、VC++、も現役ではあるが、廃れつつあるので外している。
この2つの言語は極端な盛衰を体験した代表的な言語である。

私が選んだのは、Java、JavaScript、VBA、SQL、の4つ。
この4つは最低限必要だ。
メインはJavaだ。

他に加えるとしたらshくらいだろうか。

また標準化されているが一般的に使われていない言語も外している。
CommonLisp や SmallTalk はその例である。

また一般性が微妙な言語も外している。
ActionScript、Objective-C はその例である。

| | コメント (0) | トラックバック (0)

ローカルサーバー型アプリの欠点

ローカルサーバーを使うことで、HTMLをGUIとして使用することが出来る。
ただし、以下の欠点を持っている。
・セキュリティのためにローカルサーバーが起動できない可能性がある
・ローカルサーバーにアクセスできるブラウザである必要がある
・ブラウザのシャットダウンを検知できない
・最初にローカルサーバーを起動する必要がある
・ブラウザのシャットダウンとは別にローカルサーバーを落とす必要がある
・Tomcatなどのアプリケーションサーバーをインストールする必要がある
・ファイアウォールアプリが稼動している場合は特にローカルサーバーの起動は難しくなる。

| | コメント (0) | トラックバック (0)

駄目な会社と駄目な技術

auの携帯電話のアプリはBREWといってC++ベースの開発言語の環境だったが、
ついに来年からはJavaアプリをベースに変更するようである。
つまり、技術選択を誤ったのである。

おそらくはC++にすることで技術者の温存と開発環境への参入障壁を高く
することで収入を得ようという考えだったのだろう。

つまり技術的な理由ではなく政治的な理由だった。
そしてそれが見事に失敗に終わったという訳である。
BREWはクアルコムが作った国際規格ではあるが、技術的なメリットはほとんどない。

そしてこのことからやはり開発言語というものがいかに重要なのかがわかる。
開発言語は単に技術者に対してだけではなく、企業や組織に対しても甚大な影響を与える。
どのような言語を選択したのかが後々に極めて大きな影響を与えるのだ。

もし、Javaが存在しなかったのならば、今頃はBrewのようなC++言語が
携帯電話において隆盛となっていただろう。
携帯電話のようなOSを持ったデバイスではCではなくC++が選択されるだろうからだ。

あるいは必然的にJavaのようなサンドボックス機構を持った言語が開発されただろう。

| | コメント (0) | トラックバック (0)

2010年10月20日 (水)

GUIを持っている言語と持っていない言語

プログラミング言語はGUI機能を持っているかどうかできれいに分類できる。

GUIを持っているかどうかはその言語の可能性を大きく規定してしまう。

GUIを持っていると一般的なアプリケーションを作ることができる。

GUIを持っていない言語はCGIでのみ活躍している。

もしCGIというアーキテクチャが無かったら、
いやもしHTMLというGUI層が無かったら、
CGIという方法は発達しなかったろう。

CGIが無かったら、CとC++とshを除いて生き残らなかった可能性が高い。
CGIが無かったら近年のLL言語のブームは来なかった可能性が高い。

全てはHTMLによるテキストデータによるGUIの実現が招いたのである。

GUIを持っている言語
1.Java
2.VBA
3.JavaScript
4.C#
5.VB.NET
6.ActionScript
7.VC++
8.VB
9.Objective-C
10.Smalltalk

GUIを持っていない言語
1.Lisp
2.Ruby
3.Perl
4.Python
5.PHP
6.sh
7.C
8.C++
9.VBS
10.PowerShell

| | コメント (0) | トラックバック (0)

プログラミングにおける理屈と理屈でないこと

プログラミングはどこまでも理屈の世界と思われているが違う。

基本概念、基本文法、アーキテクチャ、など抽象的な部分は理屈の世界である。
しかしライブラリやAPIやフレームワークの世界は理屈ではない。
そこでは単なる慣習やパターンしか存在しない。
それらは理解するのではなく覚えることしかできないものである。
それらを理解しようとするとおかしくなる。

それらは経験をして自分の中に集積していくしかない。
それは開発する経験を通して集積するしかない。

そしてそれらを集積するのに最も効果的なのは、代表的な機能を
網羅したアプリケーションを開発することである。

| | コメント (0) | トラックバック (0)

コメントへの返答

ひまひまさんへ

私の結論から言うと結合試験が重要で単体試験はほとんど必要ない。
単体試験が通用するほどのコードの規模ならば論理デバッグで分析するべき。

結合試験こそが重要でそれを自動化することが本当の意味で効果的なのだが、
その方法はまだ開発されていない。

TDD(テスト駆動開発)という名称は大げさすぎ。
何か裏の狙いがあるの?と勘ぐってしまう。

おそらく、TDDの本当の狙いは、ドキュメントの廃止なのだろう。

テスト駆動開発とは、言い換えればコーディングを開発の最初にするということだ。
テストを書く=コーディングによって開発を駆動するということ。
だから最初にドキュメントを書かない。
普通の開発はドキュメントを最初に書くのでドキュメント駆動開発。
TDDはドキュメントを廃することができる。
これがTDDが声高に叫ばれる本当の理由だろう。

まあ残念ながら失敗しているのだが。

以上。

| | コメント (0) | トラックバック (0)

2010年8月24日 (火)

コメントへの返答

通りすがり
少々古いentryに反応しますが...。
モバイルデバイスでも位置情報や方位を取得できますよ。
詳しくはgeolocationという用語をお調べ下さい。
ローカル資源についてはfile api、
ネットワークが接続していなければ使えない点については
キャッシュやweb storage・web databaseで対応できます。
カメラについては議論がされていますし、
flashでは既に実現されています。

-----------------------------------------

コメントありがとうございます。

以下返答します。

確かにブラウザからでもローカル資源にアクセスするAPIは現在でも
存在しており、今後も増えるでしょう。

1.ブラウザがどの程度までローカル資源のアクセスAPIを実装するか。
2.APIがブラウザ間で互換性を維持できるか。
3.APIがシンプルで使いやすい設計であるか。

これらの点がクリアされればWebアプリはモバイルでも成功することは間違いないでしょうね。

しかしもしブラウザがプラットフォームとして成功してしまった場合、
モバイル端末は逆にブラウザによって機能が規定されてしまうことになります。

新たなハードウェア機能の追加、既存のハードウェア機能の変更はブラウザへの
影響を常に考えて行うことになります。

これはAppleが中間言語を認めることで起こりえるとして恐れていることです。

ですからある一定の段階でブラウザの進歩は停止させられるはずです。

ブラウザによるハードウェアの逆規定という事態だけは避けるように
少なくともAppleは動くはずです。

それはブラウザの機能、デバイスの進化の点からみても正常な対応でしょう。

ですからブラウザが万能のプラットフォームになることはないでしょう。

技術的には可能ですが。

| | コメント (0) | トラックバック (0)

有望な言語とそうでない言語

有望な言語
・PHP
・HTML
・CSS
・JavaScript
・SQL
・C#
・Objective-C
・VBA
・C
・SVG

有望ではないが残る言語
・Java
・ShellScript
・C++
・COBOL
・VB
・ActionScript
・Perl
・Python
・XML
・Visual C++
・PL/SQL
・ストアドプロシージャ

有望でない言語
・Ruby
・XSLT
・CommonLisp
・SmallTalk
・Curl
・Scala

| | コメント (2) | トラックバック (0)

色々な選択肢を考えた

PHPかPythonか
Javaオンリーでいくべきか
NetBeansかEclipseか
ユニケージをやるべきか

結果分かったことがある。
1.技術の盛衰はリアルタイムで展開していること
2.ここ数年で技術の盛衰はかなり表面化するであろうこと
3.有望な技術と落ち目の技術があること
4.技術を現実的に使えるレベルで習得するコストはかなり大きいこと
5.テキスト派とGUI派での戦いはまだ続いてること
6.サーバー環境がUnixであることがかなり大きな影響を与えていること
7.OSメーカーとブラウザメーカーがかなり大きな影響を与えていること
8.Unixが残っている限り、C言語とC++言語は勢力を落とさないこと

| | コメント (0) | トラックバック (0)

残念ながらオブジェクト指向は破綻している

人間にはオブジェクト指向は難しすぎるからだ。
何が難しいって、オブジェクト単体ならばいいんだよ。
問題は複数のオブジェクトを同時に扱うような場合だ。
というか複数のオブジェクトを同時に扱うのがオブジェクト指向な訳だが。
1つの状態の管理ならばいい。複数の状態をその相互作用まで考えて
管理するというのは名人技のテクニックが必要となる。

オブジェクト分析も極めて難しい。
ある対象領域をどういうオブジェクトに分解するのか。
そこに方法論はない。それは分類レベルの問題ですらなく、
オブジェクトの定義と発見の問題となる。
オブジェクトは物理レベルの分かりやすいものから、抽象的なレベルのものまで
様々なレベルで存在し得る。
どのようなオブジェクト分析が正解なのかは経験と直観によって判断される。
人間にとって理解可能な分析であることが第一に必要であるが、
それだけではまだ判断基準としては弱い。

おそらく人間にとって理解可能な世界のモデルはデータ指向の世界までだろう。
データの中にオブジェクトが混じるのならばなんとか理解可能だろう。
人間は複数の対象をデータ、つまり状態を持たない対象として認識しており、
状態をもつオブジェクトとして認識する対象は少数の重要な対象のみとなる。

だから「オブジェクトも使えるデータ指向」が人間にとっての落としどころではないか。

| | コメント (0) | トラックバック (0)

やはりJEEが使えるレンタルサーバーは無くなったか

Java一本で行くとして、少々高くてもいいからJEEを使えるレンタルサーバー
を探してみた。
結果、ほとんど存在しないということが明らかになった。
驚くべきことだが、本当に、ほとんど存在していないのだ。
確かに2,3の有望なところはある。
価格もリーズナブルだ。
しかしそれでもたったの3つの会社しか採用されていないのだ。
その3つの会社がサービスを停止したらもうそれまでだ。
このリスクを回避する術がまた難しい。
専用サーバーを借りてしまえば解決するがかなり高額となる。
またAmazonEC2を使うという選択肢もある。
これがおそらく一番現実的なコストとなるが、それでもAmazonに依存してしまう。
またこれもAmazonしか使えないというリスクが生じてしまう。

だから、残念ながらJEEを安心して使うことが出来るレンタルサーバーというのは
日本には存在していない。
唯一あるのはAmazonEC2くらいだろう。

AmazonEC2を使うとしても、その環境を学習する必要があるし、
何よりもAmazonにロックインされてしまうリスクが発生してしまう。

そこまでしてJEEに固執する必要があるのか。

レンタルサーバ、GAE、AmazonEC2、この3つをJEEの環境としてこれまで検討してきた。

その結果、一番有望なのはAmazonEC2であることが判明した。
というか、EC2以外に有望なところは見つからなかったというべきだ。

その結果として、私は公開WebサービスとしてJEEを採用することを諦めざるを得なかった。

結果としてPHPでのWebサービス開発に舵をきることにした。

ただし、JEE技術自体はまだ捨てていない。

それはイントラネット用の技術基盤として使えないかと検討しているのだ。

| | コメント (0) | トラックバック (0)

今後はインターネットが使えない職場が増えるだろう

セキュリティの必要性からインターネットに繋がらない職場が増えるだろう。
それは大企業ほどに顕著になるに違いない。

仕事に関係するサイトのみを閲覧できるようにインターネット環境を設定する
のはかなり面倒だし閲覧サイトを選ぶのも難しいだろう。
またそれ自体のセキュリティを管理する必要が生じてしまう。

セキュリティと利便性を天秤にかけるとセキュリティを優先する企業は
多いに違いない。特に大企業はそうだろう。

だから今後のフロンティアとして、インターネットでもクラウドでもなく、
イントラネットが脚光を浴びることになる。

これはプライベートクラウドといってもいいだろうが、普通のWebアプリを
イントラネットに展開するだけのものだ。
これがフロンティアとなるだろう。

だからインターネット上に展開するサービスはこのセキュリティの壁があるために
大企業であるほどに利用されなくなる可能性が高い。

インターネットを使うことによる情報流出やウイルス感染の可能性は
当分は解決しない問題として残る。

だから、イントラネット内における小規模なWebサービスという分野が
今後の有望な市場として誕生するだろう。

| | コメント (0) | トラックバック (0)

Paas専用のシンプルな開発言語が作られるだろう

もしPaasの利点を最大限に活かそうとするのならば、専用の開発言語を作る必要がある。
それはJavaやC#などの既存の言語を利用するのではなく、それよりも
遥かに単純なPaasに特化した言語である必要がある。
そうすればPaasの開発生産性という特性をより活かせるだろう。

それを行う最も可能性の高い企業はMicrosoftである。

いずれはAzure専用の開発言語が生み出される可能性がある。
それが良く出来ている場合、MicrosoftはPaasの勝者になる可能性がある。
Paasのサーバー環境はクローズソースのため他社は真似ができないだろう。
また開発環境はVisualStadioを使用するため開発環境も他社は真似できない。
現状のVBやC#ではまだ複雑すぎるしPaasに特化していない。

無論、専用言語を使う以上はロックインが発生する。
しかしその欠点を補うほどの開発生産性が見込めるのならば、
ロックインも受け入れられるだろう。

Microsoftがこの戦略を採用した場合、優れた専用言語が生み出される
可能性が高い。

もしこの戦略が成功した場合、それはクラウド環境のクローズ性と
優れた開発環境という独自性によって、他社が真似をするのは非常に困難になると思われる。

| | コメント (0) | トラックバック (0)

Paasとロックインの問題

クラウドは主に3つに分類できる。
Saas、Paas、Iaas、だ。

GmailなどのSaasサービスは既に成功している。
IaasはAmazonが提供しているサービスだ。
これも成功している。

問題はPaasだ。
Google App Engine、SalesForce、Microsoft Azure などがある。
これはアプリケーションの開発プラットフォームとしてのクラウドである。

Paasの最大の問題点はロックインだ。
それぞれのプラットフォームに特化したコードとなってしまうので、
ロックインが発生する。またデータもロックインされる。
このリスクをどうみるかによって評価が変わってくる。

Paasの開発生産性はかなり高い。
それが最大のメリットとなる。
そのかわりコードとデータのロックインが生じる。

Saasもデータのロックインは生じる。
ただし、Gmailは外部にデータを退避できる。
IaasはOSレベルの仮想環境なのでロックインはほとんど生じない。

Paasはロックインが生じるが、それにもかかわらず投資コストも大きい。
各プラットフォーム毎に専用のコードを書くための学習も必要だからだ。
また大量のデータをクラウドに保管することになるが、それも他所に
移せないデータとなるのもPaasの特徴だ。

このようなリスクがあるPaasを企業は選択するだろうか?

選択する企業はあるだろうが、大企業やクリティカルなデータを扱う
企業は選択しないだろう。

一方、提供する側としてみればPaasはおいしい果実だ。
Paasの欠点は明確に存在しているが、それが克服できればその利益は
膨大なものとなる。

現状のPaasは上記のリスクを受け入れられる用途にのみ使用される
ものとなるだろう。

| | コメント (0) | トラックバック (0)

風呂での長時間学習法

風呂を利用した長時間学習の方法
・お湯の温度を38度程度に下げる
・ipodにサランラップを巻いて防水加工をして音楽を聞く
・学習する本を数冊持ち込む
・ノートとペンも持ち込む
・凍らしたジュースも持ち込む
・タオルを持ち込む
・疲れたらタオルを目に被せて寝る
・風呂に入った状態という究極にリラックスした状態での学習
 によって学習効率が極限にまでアップする
・ipodをipodtouchにすることでWebも見られるようになる
・ipodにビデオを入れておくことで気分転換が可能
・あっという間に4時間ほどが過ぎてしまう
・学習対象の本は別分野に跨って複数冊持ち込む

| | コメント (0) | トラックバック (0)

OracleのAndroid訴訟について

OracleがGoogleをAndroidにおいてJavaの特許を侵害したとして提訴したのは
意外ではあったが論理的にはあり得ることだった。

本来はSunがAndroidの発表直後に行っていたとしても全くおかしくはない。
もし発表直度にSunが提訴していたのならば全く問題視されなかった可能性がある。

なぜSunは提訴しなかったのか。

おそらくそれは Dalvik VM の技術があったからだろう。
そして Google は Java という名称を使用しなかったからだろう。
Javaとは互換性がなくJavaではないとしてしまえばJavaとは別物であるという論法である。
Dalvik VM は Java VM とは別物でありしたがってJavaとは関係ない。

唯一関係があるのは、Javaによって生成されたバイトコードを再度 Dalvik VM によって
変換して利用するという点だろう。
あるいは Dalvik VM の内部機構において Java VM の特許を侵害しているかだろう。
おそらくOracleは後者の理由をもって侵害の理由とするだろう。
これが侵害であると認められてしまった場合、Java VM に類似するあらゆるVM機構は
特許侵害の対象となってしまうだろう。

Sunが提訴するのはJavaでないものがJavaであると自称した場合である。
(※例:マイクロソフトのJava実装)
JavaでないものがJavaの技術特許を侵害しているという場合ではない。
もしそうならば .NetのCLR は提訴の対象になってしまうだろう。
(これは逆提訴による泥沼を防ぐためである)

Sunは JavaFX Mobile によってモバイル端末での地位の確保を狙ったが失敗した。
JavaFX Mobile もAndroid と同様にLinux上にJavaVMを載せたものだった。
だが Android の方が動きが早くそして準備も整っていた。
JavaFX は技術的な狙いとしても既に死んでいると言っていいだろう。
JavaFX Mobile も既に死んでしまっている。

Oracleの狙いは金銭的なものだろうが、Googleの対応によっては最悪の事態も予想される。
最悪の展開とは技術的な特許による逆提訴が起きることである。
どんな会社も他社の技術的な特許に触れざるを得ない状況があるからだ。
これが起きてしまうと両社ともに莫大な損害をこうむるだろう。
それは両社の信頼とイメージを著しく損ねることになる。
既にOracleは今回の提訴によってイメージを悪化させている。

ソフトウェア特許はこの逆提訴が可能であるが故にそれが抑止力となって
特許係争が起きない事態が続いていた。
それが起き得るのは、コードを公開していない会社が公開している会社を訴える場合か、
あるいは経済的に弱い会社を強い会社が訴える場合のみである。

Oracleの製品はクローズソースなので他社から特許侵害の指摘を受ける可能性は低い。
だからOracleは逆提訴の可能性は低いとみて今回の行動に出た可能性はある。
Oracleの失敗は単なるイメージ的な失敗でも信頼性を失うようなレベルでもない。
それは業界全体においてソフトウェア特許による紛争の口火を切ってしまう危険性がある
という意味での失敗だった。

もし今回の提訴がOracle側の要求が小さくとも認められるような結果になった場合、
ソフトウェア業界が受けるマイナスの影響はかなり大きなものになるだろう。

そしてオープンソースは特許侵害の口実を与えてしまうという理由から
リスキーなものとなりクローズソースが逆に主流になってしまうかもしれない。

その場合、オープンソースの体制で開発している企業は大きな脅威にさらされることになる。
それは特許侵害で訴えられるリスクを常に抱えていることになるからだ。
それはソースコードのコピーというレベルではない。
アーキテクチャのレベルやアルゴリズムのレベルにおいて特許侵害とみなされるということだ。
アーキテクチャやアルゴリズムは抽象的なものだから、それを侵害しているかどうか
の判定は極めて難しいものとなる。
そしてそれを侵害していると一旦認めてしまうとあらゆるオープンソースのソフトウェアは
危機にさらされるだろう。

今回のOracleの提訴はオープンソースという開発体制に対して重大な影響を与えるものになる。

そしてOracleという企業は業界全体を敵に回してしまうというリスクが考慮できない企業
であるというイメージを業界に植えつけてしまったのだ。

| | コメント (0) | トラックバック (0)

2010年6月19日 (土)

Javaの生き残る道

Javaはやはり単独で動く複雑なアプリケーションの基盤として生き残るだろう。
そのいい例が、Hadoopであり、OpenOfficeであり、Eclipseであり、そしてAndroidである。
JavaはVMの中で閉じた処理をする時に、その安定性を最も良く発揮する。
だから、Javaで作成されたDerbyやH2などのデータベースもその良い例となる。

逆に言うと、JavaVMの外部と頻繁にやり取りをするような用途においては
Javaの安定性が外部の環境に依存する割合が高くなるため、Javaの利点が目立たなくなってしまう。
特にOS層との通信が多くなると、C言語系のアプリケーションが有利になる。

Javaはあまり単純な処理には向かない。
それにはそれ専用のツールや言語が向いているのだ。
そのような用途においてはJavaはいささかオーバースペックなのだ。

その例が実はWebアプリケーションなのだ。
残念ながら、WebアプリにおいてはJavaを使う必要性はほとんどない。
PHPなどの専用言語の方が向いている領域なのだ。

だから将来においては、Javaのサーバーサイドの基盤となるJEEの技術群は
エンタープライズ領域や金融系のクリティカルな領域以外では不要となるだろう。

ローカルマシン内で複雑な処理を担う領域においては、Javaの強さが徐々に浸透していくだろう。
Hadoopはおそらくそのような例としての始まりになる可能性が高い。

無論、近年から現状にかけて上記の私の認識とは全く逆の見方が一般的なのは承知している。
つまり、Javaはサーバーサイドで強く、クライアントでの普及には失敗したと。

確かにアプレットの失敗は痛かった。
アプレットの普及に失敗したことにより、
Javaは言語としてのネットワーク性を大きく毀損してしまった。

しかしアプレットの失敗は、いやそれが成功するためには、
超えなければならないハードルが複数あり、それはかなり難しいだろう。
Flashはその成功モデルではあるが、Flashもモバイルの領域にはついに進出できなかった。

おそらくアプレットが目指したようなモデルにおいては、プラグインアーキテクチャではなく、
独自のネットワークシステムを構築するようなモデルが必要である。
それはP2Pモデルに近いものではあるが、シンプルな中継サーバーを経由することにして、
独自のプロトコルを介して複数のマシンが強調動作をするようなモデルになるだろう。
それはWinnyのようなアプリケーションの基盤となるようなソフトウェアとなるだろう。

JavaはVMの内部に複雑さを扱う処理においてその安定性によって強さを発揮するだろう。

将来、Javaによるアプリケーションで非常に強いアプリが登場する領域がある。
それは、バージョン管理アプリの領域だ。
CVSやSubversionのようなバージョン管理アプリケーションにおいて、
Javaで作られた強力なアプリケーションが登場する可能性がある。

現状では、CVSやSubversionやGITなどOSに密着したシステムが主流だが、
よりOSから離れて安定した管理システムとしてJavaで実装されたシステムが作成される可能性がある。
技術的には可能なので、いづれ開発されるだろう。

現状に見られるようなJEEによるWebアプリケーションへの過度な投資は将来において無駄になる可能性が高い。
一方、JavaVMにより密着した複雑な処理をする閉じたアプリケーションは将来においてその重要性は増大するだろう。

| | コメント (0) | トラックバック (0)

2010年5月 5日 (水)

TDD(テスト駆動開発)は怪しいな

テストコードを書きながら開発することでバグの発生低下と生産性の増大が見込める
ということだが、かなり怪しい。

1.テストコードの対象はメソッド・関数の単位であること。
 それらのメソッドが複数使われるアルゴリズム全体の流れの検証はできない。
 しかしこれが仕様を満たしているかどうかの最も大切なテストとなる。
 この最も大切なテストについては完全に沈黙しているように見える。
 
2.オブジェクトの状態を制御するようなメソッドの検証の困難性
 単に入力と出力があるメソッドならばテストコードを書くことは可能だろう。
 しかし複数のメソッドで制御されるオブジェクトを触るようなメソッドを
 検証するようなテストコードは難しいだろう。
 しかもそのようなメソッドは決して珍しいものではない。
 
3.テストコードの複雑さについての対処法がない
 複雑なメソッドのためのテストコードは複雑になるだろう。
 その場合のテストコードが正しいという保証はどうするのだろうか。
 そのテストコードをテストするテストコードを書くのか?
 そしてそのような複雑なメソッドや関数のテストこそが最も大切なテストだ。
 そのような場合はどうするのか。
 
4.GUIプログラムなどの状態遷移を持ったプログラムのテストの困難性
 GUIプログラムに対してどのようなテストコードを書くのだろうか。
 GUIプログラムでは実際に画面に表示してみないと検証できないことが多い。
 画面の動き、サイズ、色、位置、などなど。
 それらに対してどのようにテストコードを書くのか。
 
5.結合テストを軽視していないか
 複数の機能を同時に動かす結合テストについてはどうやってテストコード
 を書くのだろうか。
 TDDはユニットテストから派生した技法なのだから、結合テストとは無関係。
 それはその通り。
 でも結合テストの方が単体テストよりも重要。
 なぜならば単体テストでOKでも結合で駄目ということはあるから。
 そしてその逆は無い。
 ならばTDDとは重要で無いユニットテストを強調して重要な結合テスト
 を軽視していることにならないか。
 軽視していないというのならば、TDDなどと名称を付けて強調する意図は何か。

6.TDDの弱点、向き不向きについての情報が無い
 無いとは言い過ぎかもしれないが、TDDのメリットばかりが強調されている。
 そこに政治性を感じる。
 TDDを勧めている人達の特徴として、自分はテストコードを書いており、
 他の人達は書いていないのが信じられない、というような他者への非難の論調が多い。
 単に自分の優位性を示すための道具としてTDDを使っているだけに見える。

極論すると、TDDとは関数的でテキストベースなプログラムにおいて威力を発揮する。
つまり、入力と出力が決まっており、単純な関数やメソッドの集合に分解が容易で、
状態やGUIをほとんど持たないようなプログラムだ。

たとえばWebアプリにおけるサーバーサイドのプログラムはその例だ。
Webアプリのサーバーサイドのプログラムは状態はDBが管理するのでプログラム自体は
状態を持たないことが多い。
そして入力と出力はほとんどがテキストベースなので検証が容易だ。

その観点からすると、TDDの手法がWebアプリを開発する言語において広く
喧伝されていることとも符合してくる。

| | コメント (1) | トラックバック (0)

スピードは全てを駆逐する

これはユニケージ開発での開発者の実感としての言葉である。
つまり開発生産性が高ければ、戻り作業のコスト、開発コスト、開発時間、
これらが総じてコストダウンになり、結果としてこれらに付随する多くの問題が
解決することになる。

開発生産性が如何に重要なのかということだ。

そのためにはプログラミング言語はシンプルで柔軟性があるものでなくてはならない。

またシステム全体のアーキテクチャはシンプルにしなければならない。

そして開発生産性を上げる為に、概念、文法、パターンを日頃からよく整理して
仕込んでおかなければならない。

この「スピードは全てを駆逐する」という言葉は真実だろう。

そしてここから導き出せる教訓がある。

1.シンプルな技術を選択する。
2.シンプルなアーキテクチャを採用する。
3.日頃から知識を整理しておく。
4.テキストベースの動作機構を採用する。
5.必要な箇所でのみ複雑さを受け入れる

| | コメント (0) | トラックバック (0)

2010年2月13日 (土)

Webアプリの時代は来ないだろう

よくこれからはWebアプリがメインとなり、ローカルのアプリケーションは
廃れていくだろうという予測を目にする。
しかしWebアプリはかなり一般的になるだろうが、アプリ作成のメイン
となるまでにはならないだろう。
なぜならばWebアプリには根本的な欠点があるからだ。

1.ローカル資源にアクセスできない
2.ネットワークが接続していなければ使えない

この2つの欠点は決定的な弱点であり、Webアプリの限界点を規定する。
また、ローカル資源にアクセスできないという点は今後大きく響くことになる。
それはモバイルデバイスがメインの端末になるからだ。
モバイルデバイスのGPS機能、カメラ、方位、などのハードウェアAPIに
Webアプリではアクセスできない。
それはHTML5が一般的になっても変わらない。

今のところ、モバイルデバイスにおいてハードウェアAPIにアクセスできる
言語は事実上2つしかない。
Objective-C と Java である。
それぞれはiphoneとandroidの開発言語となる。

おそらく、Windowsのモバイル版が出れば C++が加わるだろうが、
C++ではハードウェアレベルの制御が可能になってしまうため、
Appleと同じように何らかの形での審査機構が必要になってしまうだろう。
KDDIのBREWのアプリケーションが審査制なのも言語がC++だからである。

Javaはサンドボックス機構を備えているため、C++に比べれば安全性が高い。
だから、Javaはモバイル端末に向いているといえる。

| | コメント (1)

むしろJavaこそが自宅サーバーに向いている

winnyと同じだと思った。
winnyも実は自宅でサーバーを立てるアプリだった。
winnyがルーターの設定を必要とするのはそのせいだった。
しかしwinnyがサーバーを立てるというような意識無しに導入できたのは、
ルーターの設定とソフトの少々の設定だけで動くというハードルの
低さがあったからである。

最大の違いは、通常の自宅サーバー(Linuxなど)の場合、
WebサーバーとアプリとDBという3つ(ルーターを含めると4つ)の
ハードルがあるの対して、winnyはそのハードルが2つだけだった。
それも全てGUIで行える簡易な設定だった。

実はJavaもwinnyと同じように簡易に自宅サーバーを実現できるポテンシャルがある。
なぜならばJavaは他の言語とは異なり、Webサーバー、アプリ、DBの3つを
全てJava内に閉じ込めることができるからだ。
だから、Winnyと同じように、Javaアプリを設置するというだけで
Webアプリの環境を整えることが可能となるはずだ。
つまり、Javaアプリの設定とルーターの設定という2つの作業だけで
Webアプリを公開できるようになるはずである。

Javaのこの能力を使うことで、自宅サーバーの敷居がかなり低くなる。
それはwinnyと同じレベルまで下げられることを意味する。
そこまでのレベルになれば、レンタルサーバーではなく、自宅サーバーでの
運用の方が楽だということになるだろう。

なぜそういえるのかというと、Javaの場合、環境依存性が低く、かつ、
レンタルサーバーの場合は環境依存性が高く、多くのスキルを必要とするからだ。
レンタルサーバーの場合、Webサーバー、開発言語、DB、OSという4つの
セグメントの相性や組み合わせを考慮しなければならない。

このような組み合わせの複雑さに対処するために、LAMP構成という固定化が行われた。
LAMPという形でこの組み合わせは比較的固定されているが、しかし
Javaとは異なりそれぞれが独立したソフトウェアであることは変わらない。
そのため、Javaと異なりLAMPを気軽に自宅サーバーで運用することはできない。
そのためにレンタルサーバーが全盛となっている。

実はJavaと同じことは他の言語でも可能ではある。
しかし、他の言語の場合はJavaVMほどのパフォーマンスが発揮できないという点や
スレッドをJavaほど高速に実行できない点、Javaと同等の環境非依存性が無い点、
Webサーバーまでは可能だが、RDBまでその言語のみでは作られていない点、
将来的な互換性保証の問題点、などの理由により、同じことを実現するのは難しくなる。

とりわけ深刻なのはWebサーバーとRDBが言語内で作れない点だ。
どうしてもWebサーバー、アプリ、RDBの3つが並列でOS上に載ることになる。
そのため、Javaやwinnyほどのインストール容易性を実現できないだろう。

| | コメント (0)

2009年11月17日 (火)

C言語は実は既にネットワーク性を獲得している

UNIX系のOS全般について、
C言語のソースをビルドしてソフトをインストールする手法が確立されている。
C言語のソースレベルで各種のOSへの対応を行っている。

だから、各種OSにビルドしたバイナリではなく、
ソースコードがアプリケーションとして流通している。
これはつまりC言語がネットワーク性を獲得していることを意味する。
ネットワーク性は何もスクリプト言語だけの特性ではないらしい。
そしてC言語がネットワーク性を獲得している以上、C言語が互換性を失うことはないだろう。

スクリプト言語だからといってネットワーク性を獲得できるものではない。
たとえばRubyはネットワーク性を獲得していない。
無論、Rubyはスクリプト言語でありコード=アプリなのでその意味ではコードは流通している。
しかし、Rubyの言語世界において、コードが流通することを前提としている仕組みは存在しない。
コードが異なる環境間を「流通」することを前提としていないのだ。
それはRubyインタープリタ上で動くことのみを前提としている。
それらのコードは「動く」ことは期待されても「流通」することは期待されていない。
だからそのような言語は比較的容易に過去との互換性を捨てることが出来る。
インタープリタがコード群に逆規定されるという事態にはなっていない。

C、シェルスクリプト、Emacs Lisp、Perl、JavaScript。
これらは皆ネットワーク性を獲得している。
この中でPerlはちょっと特殊だ。
それはCPANという大規模なライブラリ群の存在によっているといえる。
だからPerlがCPANに頼らなくなったとき、Perlの互換性維持の圧力は無くなるだろう。

JavaやFlashは一見するとネットワーク性を獲得しているようでいて、実は獲得していない。
それらはコンパイルされたバイトコードが流通しているのであり、コードは流通していない。
だからコードレベルでの変更が許されるのである。
しかしバイトコードのレベルでも流通させることは成功しているとは言える。
コードコンパチブルはなくてもバイトコードコンパチブルは機能している。

コードの互換性維持とコードの流通性は密接な関係にある。
CommonLispが標準を規定しても異なる拡張実装が乱立してしまうのはそれらのコードが
流通することを前提としていないからである。
標準で定めても、個人に仕様規定の権限を集中させても、それはあまり互換性維持には役に立たない。
一番いいのはネットワーク性に委ねることだ。

| | コメント (0)

Javaの場合レンタルサーバーが使えないのが痛い

なぜならば、Javaはメモリを大量に食うため、レンタルサーバーでJavaが使えるとことがほとんど無いのが現状だ。
あってもそれは専用サーバーとなりかなり高額でしかも低機能なサービスしかない。

最近になってGAEが出てきたが、GAEを例外として、やはりお手軽な
レンタルサーバーでは使えないのは変わらない。
だから、Javaの場合はレンタルサーバーを使ってWebアプリデビューというのが実はほとんど閉ざされている。
すると残るは自宅サーバーということになる。
しかし自宅サーバーを立てるための技術はレンタルサーバーよりも高く、
そしてリスキーだ。

現状ではJavaで個人がWebアプリを作って公開するとした場合、
自宅サーバーを立てるか、GAEを使うか、それとも高額な専用サーバーを借りるかの3つしかない。
一番お手軽なのはGAEだが、しかしGAEの場合は通常のJavaEEの技術ではなく、GAE専用の技術にロックインされてしまうことを受け入れなければいけない。
結局、JavaでWebアプリを作るのに最も現実的なのは、自宅サーバーということになってしまう。

これはJavaEEが大量のメモリを要求することの結果であり、
残念ながら今後もこの特性は変わらないだろう。
つまり、JavaでWebアプリを立てるのならば、自宅サーバーを立てざるを得ない。

幸いにも現時点においては、光回線とマルチセッションによって自宅サーバーが現実的になっている。
つまりやっと個人がJavaでWEBアプリを立てられる時代になったのである。

| | コメント (0)

ソースレビューの方法

以下の方法が良いことを経験した。

1.仕様書、画面イメージ、SQL、ソースコード、の順番で解説をする。

2.重要な箇所や複雑な箇所には手書きでメモを書いておく。

3.上記を印刷して全員に配る。

4.可能ならばマシンとプロジェクターを使用して解説をする。

| | コメント (0)

UNIXではシェルスクリプトのみが安心できる言語だ

LL言語は無論だが将来的な互換性の問題が解消しないし、
今までも互換性を捨ててきた前科があるし、かつ、
そのようにして進化してきた歴史もある。
しかし性能は高く、使用人口も多いというメリットはある。

一方、マイナーなLL言語である、LispやRexxといった言語は
国際標準を持っており、それなりに安定しているものの、
使用人口が少なく情報も少なく、そしてデフォルトでは決して
インストールされていないという欠点がある。
よってこれらの言語がどこでも使えるという保証は全く無い。

そして最後のシェルスクリプト。
これだけが上記の諸々の欠点を克服している唯一の言語に見える。

しかもシェルスクリプトは Emacs Lisp 以上にネットワーク性を持っている。
それは異なるUNIXのOS間を流通することを前提としており、
事実それらは流通している。

しかしシェルスクリプトにも大きな弱点がある。
それは、言語機能としては貧弱だという点だ。
しかしそれはCGI作成において克服できないほどのものではない。

それさえ克服できれば、シェルスクリプトは正に理想的なCGI用言語
となり得るのである。

| | コメント (0)

emacsはいらないな

bashだけでいい。emacsは正直言って、学習コストの元が取れるとは思えない。
emacsの魅力はemacs lispな訳だが、emacs lispでできることの範囲はbashより狭い。
だから、bashとviだけでいい。
これでemacsのインストールが必要なくなる。
また、bashとviは必ず存在するアプリなので、インストールの心配もいらなくなる。
これにApatchとPostgreSQLがあればいいか。

開発環境としては、極端言えば、bashとviの2つさえあればいい。
そしてこの2つはUNIXにおいてはほぼ必ず存在している。
しかし、Emacsは残念ながらインストールの必要がある。
つまり、Emacsはその必要性の観点からも、普遍性の観点からも頼りにするべきではないということになる。

だから頼りにするべきはbashとviの2つのみなのである。
これがUNIXの奥義なのだろう。

| | コメント (0)

2009年10月19日 (月)

emacsによるポータブルな開発環境

サーバーでemacsを動かすことで、コンソールアプリさえあれば、
OSを問わずに同一の開発環境での開発が可能となる。
無論、これはWebアプリにしか通用しない方法であるが、しかし極めて有効であると思う。

開発環境をポータブルにできるだけでなく、省資源でシンプルだという点が大きい。
標準的なunixとemacsの組み合わせであり、かつ、ネットーワーク上の省資源でポータブルな
開発環境という点で、今後もこの組み合わせが陳腐化することは無いと思われる。

なぜならば、サーバーサイドのOSはunix(linux)が標準となっており、
これが覆る見込みは今後10年は無いと思われる。

また、ネットーワーク上のポータブルな開発環境というのも現時点では存在していない。
Javaやdotnetは高機能な開発環境を持っているが、ローカルPC上のアプリとしての
開発環境であり、ネットワーク上にそれと同一の環境を構築するのは技術的に困難だろう。
それらはかなり複雑なアプリケーションだからだ。

そうなるとunixとemacsの組み合わせに勝てる組み合わせは現時点では存在しないことになる。
開発環境がポータブルになる利点は大きいが、しかし問題点もある。
それはヘルプなどの開発の補助資料は別途用意する必要があるという点だ。
それらは画像や表を含むものなので、理想的にはWeb上に全てがある状態にあるのが望ましい。
それはある程度は現時点でも実現しているので実用上は問題ないだろう。

ただし、unixとemacsの組み合わせには明確な弱点がある。
それはJavaやdotnetなどのIEDを使用するのが前提となっている開発には使用できないという点だ。
逆に、それ以外のLL言語やlispやshellならばemacsでも開発可能だろう。

| | コメント (0)

2009年10月15日 (木)

オブジェクト指向とMVCという矛盾

そもそもMVCはオブジェクト指向ではない。
それは反オブジェクト指向である。
なぜならば、操作とデータを分離してしまうから。
オブジェクト指向ならば、オブジェクトとそれに対するメッセージの2つがあればいい。
データとその操作は全てオブジェクトの内部に隠蔽されなければならない。

もっともこの矛盾は実はかなり歴史的に深いものであり、
オブジェクト指向の元祖であるSmalltalkがMVCを採用したのが始まりだった。
オブジェクト指向とMVCの対立はその誕生の時点から存在していた。

これをどう解釈するのか。
MVCは誤ったデザインパターンとして排除するべきか。
それともオブジェクト指向の限界を認めてMVCを採用するべきか。

もっと難しい問題がある。
それはどのような場合にオブジェクト指向を採用して、
どのような場合はMVCを採用するべきなのか、
その境界をどうするのかという問題だ。

Smalltalkはその点について何も語ってはいない。

おそらく、ある程度のスケールを超えた時点でオブジェクトのパターンが破綻して、
MVCを採用せざるを得なくなるというのが現実なのではないか

ここからオブジェクト指向が万能ではないというのは明らかとなるのだが、
未だにそれが万能であるかのように語られている現実がある。

オブジェクト指向というのは、
データと操作を一つの空間にパッケージしてしまう
というデザインパターンの1つに過ぎない。
MVCと同じレベルのデザインなのである。

| | コメント (0)

2009年10月 6日 (火)

シェルスクリプトによるCGI

シェルスクリプトでおCGIが可能であるということを先日初めて知った。
けっこう衝撃的だった。
これならば、互換性の問題やインストールの問題に捉われることなく、
CGIでのWEBアプリが作れるのではないかと感じたからだ。

おそらく、ユニケージ開発が可能なのは、これがあったからではないかと感じた。
なぜならば、もしperlなどの言語からshellを呼び出すのならば、
全てをperlで書いたほうが効率的だからだ。
しかし、CGIでいきなりshellをキックできるのならば、話は違ってくる。
すべてをshellで書くというユニケージ開発が可能となるのである。

CGIでshellが起動できるということは、ほぼ全てのプログラムが起動可能であるということだ。
ということは、枯れた言語であるREXXでも同様にCGIが可能であるということである。
REXXは私がclisp以外に枯れたスクリプト言語をと探して発見した古のスクリプト言語である。しかしREXXはWEBサーバーを作れない言語なので諦めてしまった経緯があった。
CGIでもREXXが可能ならば、REXXの価値も高まる。

しかしREXXとshellが異なるのは、shellがほぼ絶対に存在しているということである。
REXXはインストールは可能であるかもしれないが、しかしインストールされていない可能性がある。
REXXは十分に枯れた言語なので、CLSPと同じく互換性の問題が生じることはないだろう。
しかし、CLISPやEMACSと同じく、初期状態においてインストールされていない可能性があるという問題点が付きまとっているのは変わらない。

小飼弾がperlを選択したのは、その言語の特性からではなく、それがUNIX全般のOSにおいて、最も普遍的にインストールされている可能性が高いからであった。
perlプログラマがperlを選ぶ最大の理由はこれであろう。

確かに、その点においてperlは未だにそのUNIXにおける第一スクリプト言語としての地位を失っていない。
しかし、perlにも言語の進化とver6.0での互換性の喪失という問題が控えている。
そして、perlが入っていないUNIXも実は存在している。
たとえば、企業内で使われているAIXやSolarisがそうだ。
それらのUNIXにはperlはデフォルトで入っていないのである。
これはemacsやclispについても同様に言えることだ。

しかし、デファクトスタンダードとなっているbashならば、互換性とインストールの問題をほとんど場合においてクリアすることができる。

ただし、シェルからDBに接続する場合、通常のスクリプト言語からの接続よりは遅くなるだろう。
だからユニケージ開発はファイルをデータベースとして使用しているのだと思う。
ファイルを使うのではなく、使わざるを得なかったのかもしれない。

というわけで、
今のところ、Linux上で使用するスクリプトとソフトウェアとしては以下を予定している。
・bash
・emacs
・emacs lisp
・clisp

| | コメント (0)

2009年10月 3日 (土)

Perl、Ruby、PHP、Python、ねえ。。。

これらを使っている会社や技術者が活躍しているように見える。
perlのはてな、RORのRuby、GAEのPython、LAMPのPHP。
どれも現在の旬な技術であり、話題に事欠かない。

それらに比べると、Java、Groovy、Lisp、ActionScriptといった私が選んだ技術は
いささか活発さには欠けているように見える。
しかし、それは裏返せば技術が安定しており、特に話題にしなければならないようなものがないというだけなのだと思う。
事実、これらの技術は安定しているからだ。

そして、LL四天王の言語は、どれも将来的に見た場合の仕様の安定性に欠けている。
RubyはISO標準を目指すらしいが、それでも5年後を目標としている。
しかもver1.8をベースに標準化するというのだから、現在の2.0への流れと逆行する始末。
一番安定しているのはPerlであるが、これも言語仕様が古すぎるという大きな問題点を抱えている。また、ver6.0での互換性破棄の問題も存在している。

PHPはver6.0までにまだまだ言語仕様が大きく変わる予定となっている。
RubyとPythonはそれぞれが自ら言語仕様を大幅に変えてしまったという始末。

LL四天王は自殺しているように見える。

そしてこれらLL四天王を使用しているはてななどの優れた開発者達が、
今後どのような状況になるのかを非常に興味深く見ている。

| | コメント (0)

まずい人と一緒に仕事をする場合に気をつけるパターン

それは、

「問題人物と自分との2人だけで仕事をしなければいけない場合」

その場合、その人の問題点が外部に隠され、かつ、その被害を自分のみが受けることになる。
そうなると、外部に自分の味方が作りにくい。
なにせ、その人の問題点が外部に公開されないので、その人の問題点を外部に訴えても外部の人に承認してもらうことが難しい。

まして、その問題人物が上司に当る場合は余計に厄介である。
その場合、外部に問題を公開するということは、上司による業務上の報復が行われる可能性が生じてしまう。

もし、まずい人物と一緒に仕事をする場合でも、複数人がかかわっている場合は、その人の問題点を知る人が複数いるので、問題点があるという主張も客観性を保証することが容易である。
しかし、2人だけの場合はそれが難しいのだ。

このような場合の対処法について考えてみた。
それは以下のパターンに集約される。

1.外部の人を巻き込む
可能であれば、4人くらいになるまで外部の人間を巻き込みたい。
そうすれば、問題点を知る人が多くなり、問題を外部に公開しやすくなる。
そしてそれを恐れて問題人物も問題的な行動を起こしにくくなるだろう。

2.極力接触を少なくする
業務的な接触点を極力する無くすることで、被害を抑える。
しかしこれは業務的な接触が存在する限り、少なくすることは難しいだろう。
しかし少なくとも自分からのアプローチを最小化することは必要である。

3.外部に問題を公開する
問題点を示す証拠(メールなど)を元に組織の上部に対して問題点を公開する。
これは王道的なアプローチであるが、業務内容を知っているのが2人だけの場合、
自分が公開した問題点が本当に事実なのかどうかを証言する第三者が存在しない。
また、問題の人物は間違いなく問題点を否定するので、議論が平行線となってしまう。
あるいは、問題点を主張した自分の側が逆に問題的人物に仕立て上げられてしまう危険性もある。
この場合は、証拠をできるだけ集めて、組織内で戦う覚悟が必要となる。
それだけのコストとリスクを払う価値があるかどうかを分析する必要がある。

4.組織を抜け出す
最終的にはその組織を抜け出すのも候補に上がるだろう。
特に、以前にも同じパターンで人が辞めている場合は、自分もそれに従うほうが経済的な損失が少なくなると思われる。(つまり無駄な戦いを起こさないで労力を温存する)
問題点を公開しても状況が変わらない場合は、その組織自体が問題のある組織である可能性が高い。

1,2,3の行動を並行して行い、駄目と見たならば4の行動に移るしか無いだろう。

このような対応が必要なのは、
「問題人物と自分との2人だけで仕事をしなければいけない場合」
であることに注意されたい。
この場合のみ、特別な対応が必要なのである。

| | コメント (0)

2009年9月24日 (木)

リアルタイムコーディングという勉強会について

ペアプログラミングが最大の学習効果を発揮するのならば、
プロジェクタを使用した複数人によるリアルタイムコーディングは
効果的な勉強会として威力を発揮するのではないだろうか。

普通勉強会というと、資料を用意してプロジェクタを使用してプレゼンするというものだろう。

しかしこれで私が問題だと思うのは、発表者の負担と受講者の利益とが釣り合っていない点だ。

発表者は情報を提供するが、受講者は全く情報を提供しない。
いやまあ発表することで発表者自身の内部で色々な気付きがあるというのは分かっている。
その意味で発表者も利益を得るのであるが、しかしそれは発表者の自己努力によるものだ。

その点、リアルタイムコーディングならば、発表者と受講者のように情報の一方的な流れに陥らずにすむ。
また、コーディングを全員で行うことで、負担が特定の人に集中することもなくなるだろう。

この勉強法の利点は、おそらく最も濃密な情報の交流が実現できるという点だ。
欠点はプログラマ以外は全く参加・理解することができない点だろう。

また、何らかのコーディングを伴う分野ならば採用できるが、それ以外の分野には適用できないだろう。

| | コメント (0)

プロジェクトをツールで改革する者

優秀なプログラマの絶対的な条件として、
ツールを作成してプロジェクトでの作業を効率化するという点が挙げられる。
これは私の経験からほぼ絶対的な条件であると思っている。

作業を速く正確に行うことは経験を積めばほとんどの人が出来るようになる。
しかしツールを作ってプロジェクトを改革するプログラマはそれほど多くない。

それは何故かというと、作業を行うレベルと、ツールを作るレベルとでは、
技術のレベルが異なるからである。

もちろん、ツールといっても技術レベルはバラバラであることは分かる。

しかし、プロジェクトを改革するレベルのツールというのは、ほとんどの場合、
本格的なアプリケーションであることを要求されるのである。

| | コメント (0)

シェアウェアの作り方

シェアウェアを作るのに、現在参加しているプロジェクトを利用するのは
最も合法的にシェアウェアを作成する方法である。

プロジェクトを改革するツールを作成することで、それを土台にして
シェアウェアとなるソフトウェアに発展させるという戦略だ。

こうすれば、プロジェクトもプライベートの時間も犠牲にしないで
シェアウェアを作成することができる。

たとえツールがシェアウェアほどに練る事が出来なくても、
プロジェクトは効率化できるし、技術も身に着けることが出来る。

この方法の欠点はプロジェクトの改善につながる様なツール以外の
ソフトウェアは作成することができないという点だろう。

またツールを作る余裕の無いプロジェクトでもこの方法は使えない。

これらの欠点はあるものの、しかしこの方法は汎用的に使える戦略であると思う。

自分の製品を持つというのはプログラマとしての最初の一歩になるのだ。

そしてほとんどのプログラマは自分の製品を持つことなく過ごしてしまうのだ。

| | コメント (0)

結局、まともに使えるLL言語って

有名どころで存在しているか?
以下にそれぞれ挙げてみよう。

Perl、PHP、Ruby、Python はどれも今後の互換性の問題が解決していない。

この中で最もまともなのは、おそらく、Pythonだろう。
言語仕様、使用実績、ドキュメント、ライブラリ、を総合的に見て、
Pythonが最も無難であると判断する。
しかし、残念ながらPythonは3.0で過去との互換性を捨ててしまった。

PHPは有望なのだが、残念ながらver5.3で大幅な仕様追加と変更が発生した。
PHPは来るべきver6に対して現在変化している最中のようである。

Rubyはver1.9で過去との互換性を捨ててしまった。
Rubyは来るべきver2.0に向けて変化の最中である。
また、Rubyは残念ながらサンプルコード、ドキュメントが充実していない。
また、ver1.9での変更によって使用できなくなったツールやフレームワークが多すぎる。
米国でもRubyの人気が落ちているようだが、それは互換性が消滅したことが影響しているだろう。

Perlは一応は安定しているが、来るべきver6.0がリリースされると過去との互換性が無くなることになる。
ただしCPANというライブラリの集合が存在する以上、それらライブラリの流通性によって、互換性維持の圧力がかかり、結果としてPerl6.0は受け入れられないと予想される。よってPerlは比較的安全な言語である。
しかしながら、その言語仕様は非常に古く問題点が多い。

これら4つの代表的なLL言語を見ると、Pytohnの互換性問題さえ解決するのならば、
Pythonが最高なのだと思われる。
次点でPHPだろう。

しかしいづれの言語であっても、現時点でコードを大量に書いた場合、
将来においてそれらのコードの互換性が維持されている可能性は低いと思われる。
よって私はそれら4つの言語に手を出すのは止めようと思っている。
おそらく、これら4つの言語は情報も豊富でやると面白いと思う。
しかし、今現時点においては、将来的な互換性問題が解決していない。

実際にやる場合は、おそらくはPHPになる可能性が高い。
なぜならば、この中で互換性維持に最も力を注いでいると見えるのがPHPだからである。しかし、現時点でのPHPはまだレンタルサーバーが5.3に対応していない状況だ。
そして6.0に向けての変化において、まだまだ仕様が変更されていくだろう。
PHPは変更点こそ少ないものの、連続的に仕様が徐々に変化していくのが特徴だ。

Pythonは、Google App EngineがPythonに対応しているのが魅力的ではある。
しかし、それ以外の魅力は互換性を捨てることで大幅に減殺されてしまった。
PythonはLL言語の中では最も汎用的で本格的な言語であるが、その分学習コストも大きい。
そのコストを払うには、過去のものとなるバージョンのPythonはリスクが大きい。

そして最終的に残ったのがCLISPだった。
CLISPならばCGIを使ってWEBアプリが作れる。
また十分に枯れており、ANSI標準に準拠しており、そしてフットプリントも小さい。
また使用実績も十分にある。日本語も問題無いようだ。
ただし、日本語での情報は極端に少ない。
しかし、将来的な互換性の保証の可能性は最も高いと思われる。

よって私はLL言語として、CLISPを選択することを決断した。

Groovyはどうか?
Groovyは確かに魅力的ではある。
しかしGroovyの最大の欠点はJavaに依存しているという点である。
よってJavaに対するセーフベースとは成り得ない。
Javaに対するセーフベースとなるためには、Javaに依存しないことが条件となる。
依存してもよいという条件ならば、Groovyは間違いなく魅力的である。
よって、残念ながら私にとってGroovyはメインの言語にはならないだろう。
ただし、将来的にJavaの開発生産性を改善する手段としては最有力候補としてGroovyが挙げられるだろう。
よって、サブ言語としてGroovyは採用可能ではある。

また、Groovyは将来的にはJavaFXに取って代わられるかもしれない。
JavaFXは表向きはRIAの専用言語のように見えるが、実はGroovyを置き換える正式なポジションの言語を狙っていると思われる。
JavaFXならばSUNの正式なサポートが受けられるだろう。

結論から言うと、現時点で私のメインとなる開発言語は、
JavaとLispということになってしまった。
なんとも味気ない結論である。

おそらく、プログラマがメインとして開発をすることが出来る言語は、3つが上限ではないかと思っている。
メインとして開発をするというのは本格的なアプリケーションを作成するという意味だ。
ちょっとかじったくらいの意味ではない。

JavaとLisp。
あと残りのスロットは1つだ。

| | コメント (0)

2009年7月19日 (日)

混沌を好む業界

LinuxやRubyは混沌を好むがゆえに、これからも安定することはないだろう。
なぜ彼らが混沌を好むのか、いや、なぜ混沌に耐えられるのか。
それは、彼らがC言語という基盤言語を基礎として持っているからである。
C言語という堅固な基盤の上で彼らは遊んでいるのである。
だから、C言語がある限り、その上の構築物がどれだけ混沌とした状態になったとしても、彼らは耐えられるのである。
彼らの本籍地はC言語なのだから。
C言語さえ安定していれば、その上の構築物がどうなろと、最終的に彼ら自身の安定性を脅かすものではないのである。

そして、C言語を安定基盤として採用する言語やシステムは最終的には一般のPCユーザーを本当の意味でのユーザーとしては迎え入れないだろう。
なぜならば、それは最終的にはC言語によるデバッグ可能レベルの知識をユーザーに要請するからである。
だから、C言語の知識を要求するシステム(つまりインストール時にC言語のソースをコンパイルする必要があるもの)は基本的に初心者の参入を明確に拒否しているのである。

C言語のデバッグレベルの知識こそが彼らの最大の武器であり、また防御壁ともなっている。

そう考えると、JavaScriptやMonoをストールマンが否定したというのは面白い。
なぜならば、この2つの技術はバイトコードに変換される技術であり、C言語の知識が通用しないからだ。
つまりデバッグができないので彼らの武器が使えないからだ。

C++に首まで浸かったプログラマがC#を否定したくなるのも同じである。
自らの最大の強みを否定されてしまうのだから当然であろう。
(だからC#というのは従来のVisual C++プログラマにとっては領域を侵犯された気分だろう)

Rubyがもしバイトコード実行環境であるYARVに完全に移行できるのならば、RubyはそのC言語との密着性から離れられるので、最終的には一般ユーザーを獲得できる可能性が高まるだろう。(なぜならC言語の知識を要求することがなくなるから)

言語がC言語との密着性から離れるという基準の一つとして、ライブラリが完全にC言語から離れているかどうかが挙げられるだろう。
ライブラリがC言語で書かれている場合、やはりライブラリを理解・デバッグするためにC言語の知識が要求される。

そう考えると、C言語から離陸できている言語とは何かがより一層明確になるだろう。

| | コメント (0)

あるプログラミング言語を使えるということは

それはどんな場面でどのようなコードを書けばいいのかがある程度頭に入っている状態を意味する。
基本的な文法や概念を抑えているだけでは全然足りない。
そのような基準を適用するのならば、使える言語というのはせいぜい2,3が限度であるということになる。
だから、ターゲットとなる言語を決めるというのはとても大切なことなのだ。

| | コメント (0)

2009年7月 8日 (水)

dotNetとMonoの戦略

dotNetは確かによくできているし、Monoによってマルチプラットフォームも実現されてはいるのだけれど、しかしMonoの将来的な安全性が見えないのが問題だ。
MonoはNovell社によって開発されているのだが、そのNovellはMicroSoftと非常に良好な関係を持っている。
これは一体何を意味するのか?
MSにしてみれば、NovellがMonoを実装してしまうのは敵対的な行為になるはずだ。
なぜならばそれはWindowsからの顧客の離脱を促すからだ。
しかし、両者の関係は良好である。
するとMSにとってMonoの開発は望ましいものなのだという仮説に行き着く。
なぜ、MSにとってMonoは望ましいのか。
それはおそらく、MonoによってLinuxのアプリケーションを間接的に支配できるからではないか。
そして、dotNetは絶対にMonoよりも品質的には上だろうから、常に品質と開発環境の面でLinuxを上回れる。
また、dotNetにのみ存在する肝となるような機能を実現させれば、Linuxの開発者をWindowsに呼び込めるし、LinuxをWindwosに依存させるようにすることができる。
これが、MSによるMonoの戦略なのではないだろうか。
つまり、最終的にMonoがdotNetと同じレベルの完成度を持つことはないだろう。
ただし、現状でもMono上でのASP開発が行われているという事実が有り、これは明らかにMSにとっては損失なのであるが、どうなのだろうか。
もしかしたら、NovellからMSにライセンス料のような契約が交われているのかもしれない。
しかし、ライセンス料のような短期的な利益よりも、長期的にみてWindowsからのユーザーの離脱の方が遥かに損失は大きいだろう。
もしかしたら、MSはdotNetがWindows内に閉じていたならば、このままでは滅びてしまうと感じたのかもしれない。
それならば、ECMAの標準にして、広めた方がいいだろうという判断に出た可能性もある。
MSによるMonoの容認は、いままでのMSの基本戦略からは完全に逸脱した別種の戦略に則っていると見るべきだろう。

| | コメント (0)

現時点での対象言語

・汎用言語
 Java
 CommonLisp
 PHP
 Smalltalk

・専用言語
 JavaScript
 SQL
 ActionScript
 VBA
 Ant
 XSLT
 ShellScript

ふう。
かなりのボリュームがあるな。

| | コメント (0)

マルチセッションと自宅サーバー

マルチセッションというNTTフレッツ光が提供する機能を使用することで、
自宅サーバーのセキュリティ問題が解決される見通しがついた。
これは光回線に2つ以上のIPアドレスを割り当てて、並行して通信ができるという技術である。
これを使えば、それぞれのIPにルーターを割り当てることができ、論理的にも物理的にもセキュリティが実現するように思える。
光回線の端末にスイッチングハブをつなげて、そこに2つのルーターを接続する。
次に、予めプロバイダと契約して取得した接続設定をそれぞれのルーターに設定する。
こうすることで、それぞれのIP内での閉じたネットワークができる。
一方を家庭内のLANとして、一方をWEBサーバーとする。
つまり、家庭内のマシンとWEBサーバーのマシンとが、IPアドレスと、ルーターの段階から論理的・物理的に分断される。
こうすることで、たとえWEBサーバーが不正侵入されたとしても、その影響が家庭内LANに影響する可能性を極めて小さくすることができる。

ただし、このマルチセッションという機能は、まだあまり一般的に知られてないので、自宅サーバーとの兼ね合いで触れられることは少ない。
この機能がNTT光回線にのみ存在しているというのも大きな要因としてある。
マルチセッションというのは例外的なサービスなのである。

また、自宅サーバー構築の際の家庭内LANの安全性の無視という昨今の風潮もある。
このこともマルチセッションへの関心を失わせる原因となっている。

Googleで検索すると、「自宅サーバー」だけだと 2,650,000件ヒットするが、
「自宅サーバー マルチセッション」だと 29,900 件と激減する。

また、2段階ルーターを使う技術よりも、こちらのほうがより単純でかつ安全性が高いといえる。

まさにマルチセッションの技術は、自宅サーバーのためにあると言っても過言ではない。

マルチセッションが可能になってはじめて自宅サーバーのセキュリティのリスクが現実的に低下したのである。

このマイナーな、しかし極めて重要な技術の発見は、自宅サーバー構築において、極めて重要な分岐点となった。

| | コメント (0)

PHPは比較的安全な言語だ

なぜならば、現時点においてはZend社が実質的にPHP言語を管理しているからだ。
そして、Zend社がPHPの技術者認定試験を実施している以上、PHPはZend社という企業によってサポートされているLL言語だと見ていいだろう。
そして、PHPでもWEBサーバーが作れる以上、ある程度の汎用性も持っている。
つまり、LL四天王の中で、現状で最も安全性が高い言語がPHPであると言える。
PHPならば学習しても問題ないだろう。

| | コメント (0)

CLISPについて調べてみた

・Common Lisp のANSI標準の機能は貧弱であり、実装毎の拡張は不可欠。
・実装毎の拡張で各実装の特徴が出てくる。
・CLISPの拡張機能が重要となる。
・CLISPはソケット通信可能。
・CLISPはPostgreSQLとOracleとBerkeley-DBへの接続機能を持っている。
・それ以外のDBへの接続も可能なようだが、
 プリペアステートメントが使えない等、問題があるらしい。
・結局、CLISPでRDBを使う場合は、PostgreSQLの1択となると思われる。
・RDBを使わないで、全てリストとマップでデータを保存するという戦略もある。
・その場合、シリアライズ機能が必須となるが、これは可能なようだ。
・シリアライズではなくてもファイル書き込みでもいいかもしれない。
・Common Lisp Directory というライブラリのサイトがある。
・ライブラリサイトで機能を探すのがとても重要となる。
・CLISPでWEBサーバーを作ることは可能だと思うが、
 どれほどの労力がかかるのかは未定。
・CLISPを使う場合は、WEBアプリ用のサーバー用途がメインとなる。
・CLISPでWEBサーバーを作れれば、
 ブラウザをGUIとしたデスクトップアプリも可能となる。
・CLISPではスレッドが使えないので、まともなCGIが可能かどうか微妙。
・英語で検索してもCLISPの情報は少ない。
・CLISPの情報収集に英語は必須。
・FastCGIというのが拡張機能に存在していた。
・CLISPのFastCGIは、Apache状で動く。
・FastCGIはスレッドではなく、プロセスをメモリ上で使いまわす方式。
・日本語とプラットフォームから考えるとフリーの実装ではCLISPがベスト。

| | コメント (0)

Perl6とはてな

Perl6はPerlをメイン言語に据えているはてなにとって大きな影響を与えるだろう。
はてながPerlをメインに据えたのは、はてな起業時に最も普及していたLL言語はPerlしかなかったからだろう。
もし、その当時RubyやPythonがレンタルサーバーでも広まっていたのならば、Perlは選ばなかったのではないかと思う。
それはともかくとして、歴史的な事情からWEBアプリ専用言語としてPerlを選ぶのは仕方がなかったといえる。
そして、Perlは当時から現在まで後方互換性を崩すことなく安定して存在してる言語でもある。
その意味ではてなはラッキーだったのだろう。メイン言語が安定しているのだから。しかし、Perl6は事情が異なる。Perl5からのドラスティックな変更が行われる。
もう後方互換性は崩れることになる。
はてなとしてはどう対応するのか注目である。
もっとも、Perl6の開発はほとんど停滞に近い状況なので、おそらくPerl5系のまま当分は大丈夫である。
この点からもはてなはついている。
おそらくこのままではPerl6はかりにリリースされたとしても、広まらないだろう。
既存のコード資産を捨ててまでも移行する理由が無いからだ。
もし捨てるのならば別言語も検討されるはずだ。
おそらくはてなのPerlはPerl5で固定化されるだろう。
そういう意味で、はてなの技術基盤はこれからも安泰であり、彼らの強みは消えないだろう。

| | コメント (0)

2009年6月27日 (土)

うーむ。RubyもPythonも仕様が安定しないのならば

やはりCommon Lispに流れるなあ。。
CLISPがより魅力的になってしまう。
PythonもRubyもそろそろ言語が安定してきたというときに後方互換性を捨ててしまった。
ぶっちゃけ、これは痛すぎる。
このようなことをするということは、たとえ新しい仕様が安定したとしても、未来においては再度仕様の変更が生じるというリスクが存在することを意味している。
Perl、Python、Ruby、PHP、これらの代表的なLL言語は、未来において仕様が変化しうるというリスクを抱えており、それが解消される可能性も小さい。
これらは代表的な個人が仕様を策定しており、そしてそれらはソースコードが仕様となっている。
実は、ソースコードそのものが仕様となっていること自体には問題はない。
ソースコードが仕様なのならば、それを解読すれば自然言語で仕様書が作れるからだ。

問題は、それらの仕様が後方互換性を考慮することなく不意打ち的に変わりうるという点だ。つまり、仕様は存在するが、安定し得ない状態にある。
ここから生じるリスクは、言語の処理系が変わってしまうことで、既存のコード資産が動かなくなってしまうということだ。
事実、PythonとRubyという代表的なLL言語は後方互換性を捨てて新しい仕様を起こしてしまった。
このリスクが標準化を経るなどして解消しない以上、これらLL言語には常にコード資産が無駄になってしまうというリスクが存在している。

Javaは後方互換性を維持するポリシーがあり、かつ、仕様が企業間のコミュニティーによって合議制で決められるため、コード資産が無駄になる可能性が少ない。
これがJavaの最大の強みでもある。

Common LispもANSIによる標準化によって、同様の強みを持っている。
ただし、Javaと違うのは、Common Lispの場合は標準化されているのは言語のコアの部分だけなので、それ以外の部分は処理系による独自拡張となってしまうという点だ。
しかしそれでも既存の個々の処理系はLL言語以上の歴史を持って安定しており、今後後方互換性が崩れる可能性は小さい。少なくともLL言語のように既存のコードに対して破壊的な影響を与える心配は少ないと思われる。
これがLL言語として Common Lisp を採用するメリットである。
よく言われるように、Common Lisp が言語的に優れているから、というのではなく、言語仕様が安定しているからというのが最大の理由である。
言語仕様の安定性は、言語の機能性よりも重要である。
図らずも黒田さんと同じことを言うようになってしまった。

PythonやRubyが仕様変更をしなければ、黒田さんの説が説得力を持つことは無かっただろうが、どうも現実にそれが起きてしまったというわけで。。

やはりLL言語は将来性の面で怖いと思うのだが、企業はその辺どう考えているのだろうか。

このような教訓を得ることで、残念ながら流行のLL言語への熱は冷めてしまった。
私は言語仕様の安定性を基準として言語を選んでいこうと思う。

| | コメント (0)

2009年6月26日 (金)

Ruby1.9の空気読まなさは異常

だって、1.8からの変更点がクリティカルすぎる。
ブロック内の変数のスコープを変えてしまった。。。
Rubyの核となるブロックの機能を変えるというこの行動性。
普通、1.8まで安定して進化してきたのだから、これ以上ドラスティックな変更は無いだろうと皆(欧米含む)思っていたと思う。
それが、あろうことか、言語の核心部分を変更してしまうなんて。。
いやあこれは凄いよ。このKYは尋常なKYではない。
欧米での1.9への反応はわからないのだが、かなりのマイナスな衝撃を受けている企業は多いだろう。
なにせ既に業務システムでRubyはバリバリに使われているのだから。
(全体からみて一部の企業であっても)
つまり、Pythonが2.5から3.0で互換性を無くしてゼロスタートを切ったのと同じく、Rubyも1.8から1.9に移る際にゼロスタートを切ったことになる。

これでRubyへの信頼はかなり傷付けられたのだと思う。
なにせ、1.8時代に書かれた膨大なソースが全て動かなくなるのだから。

確かに、PythonもRubyも、言語仕様をよりよくするという目的が有り、
それを実現するために、そして、超長期的な視野で見て、
あえて互換性を犠牲にしているというのはわかる。

これで困るのは言語を作っている作者ではない。
その言語を実践投入している企業や開発者たちである。

おそらく、1.9への移行は既に実践投入されている膨大な資産からして、
ほとんど実行されないだろう。
これはPythonにも言えることだろう。

つまり、PythonとRubyという2つの優れた動的言語は、
それぞれが、2.5と1.8で打ち止めになったとみていいのだと思う。
逆の視点でみれば、そのバージョンでそれぞれ安定版として確立されたのだ。

| | コメント (0)

2009年6月22日 (月)

プロジェクトの成功はほとんどが政治的要因で決まる

だから、技術的要因とか、コミュニケーションとか、モチベーションとか、
そのような部分に焦点を当てている既存のプロジェクトマネジメントは、
残念ながらあまり役に立たない。
それらは全て政治的に健全なプロジェクトでのみ意味を持つからだ。
問題は政治的に健全でないプロジェクトであり、それに対する解決策が無いのである。
政治的に健全であれば、様々な工夫が可能となり、結果的にプロジェクトは成功する。
しかし政治的に健全でないのならば、そもそも色々な工夫が禁じられるので、プロジェクトを正常化できない。
だから、一番大切なのは、プロジェクトの政治的な健全性を保つということなのだが、これに対する対処法は未だ未着手の領域として残されている。

政治的に不健全なプロジェクトからは撤退するか、自己保身に努めるかの2択しかない。
だから、如何にして撤退するか、いかにして自己を保身するかというテーマが浮上しなければならない。

プロジェクトを成功させたいという考えは結構なのだが、現場のプログラマが貢献できるのは、そのプロジェクトが政治的に健全である場合のみである。

たとえば、
意図的にデスマーチを起こすことを企図しているプロジェクトとか、
意図的に失敗させることを狙っているプロジェクトとか、
政治的理由や嫉妬や感情から組織が動いているプロジェクトとか、
そのようなプロジェクトでは、そもそもプロジェクトの成功は目的となっていない。
プロジェクトの成功を誰もが目的としているというのは幻想である。

| | コメント (0)

開発とはマッシュアップだと思う

Javaでの開発で思うのだが、開発する作業というのはまさにマッシュアップだと思う。
そこにおいては、本、Web、人、ライブラリ、IDE、からの情報がマッシュアップされるのである。

| | コメント (0)

LL言語は職場では使えないと悟った

Groovy、Ruby、Python、これらのLL言語は残念ながら職場では使えないと悟った。
なぜならば、これらLL言語でJava開発で必ず存在している言語というのは存在しないからだ。
唯一、最もその可能性が高いのはGroovyだ。
GroovyはEclipse3.4にデフォルトで付いているからだ。
しかし、これもかならず3.4が使えるとはいえないのがつらい。
結局、LLを職場で使おうとしても、どうしても外部からインストールが必要になってしまう。
これがあるがゆえにLL言語は残念ながら職場で活かすことは難しいと思われる。
仮にダウンロードできる職場があったとしても、他の現場では保証されない。

仮に完全に独立して、自宅でのみ作業をするというのならば別だが、
そのようなことは当分はないので、やはり現場で使えるかどうかが肝となる。

すると、本当の意味でどんな現場にもあって使えるLL言語となると、
実はJavaScriptしか存在しないことが明らかとなる。

| | コメント (5)

Junitと生産性

Junitはテストクラスを作成してテストを自動化する仕組みだが、
これによって生産性が上がるとは一概には言えない。
なぜならばテストクラスを作成する工数も発生するからだ。
そして、テストクラス自体にバグが存在する可能性もあるため、
テストクラスの設計と作成にはある程度の技術レベルと経験が必要とされる。
Junitが有効性を発揮するのは、確実なテストによってテストの安全性と網羅性を
上げたいという場合だろう。
だからJunitによってテストの確実性は上がるといえるが、
生産性が上がるとはいえない。
余計に工数と時間がかかることも十分に有り得る。
そして、そのようなデメリットを受け入れるようなプロジェクトとは、
巨大で失敗の許されないプロジェクトとなるだろう。
つまり、それ以外のプロジェクトにおいては必要ないものだといえる。
だから、Junitはその知名度とは異なり、それほど現場では使用されないだろう。

| | コメント (0)

理解という欲望

全てを完全に理解しなければ次へは進めないとしたならば、
私たちは一歩も前へ進めなくなってしまうだろう。

| | コメント (0)

クロージャの定義

周囲の環境を自動的に読み取る実行可能なコードの断片
ということになろうか。
関数に近いが、異なるのは、周囲の環境を自動的に読み取る、
という点だ。

| | コメント (0)

ユニケージ開発手法という古臭いが革新的な開発手法によって

その業務専用のDSLを早く安く作るという手法は確立されたと言っていい。
Common LispによるDSL作成能力は残念ながら否定されてしまったに近い。
ユニケージ開発は、シェルスクリプトと独自コマンド群から成り、
シェルスクリプトはLinux標準のbashを使い、独自コマンド群はそれぞれ
目的にあわせて独自の開発言語を使うという柔軟な手法を提供する。

シェルスクリプトという最高級言語でありながら、独自コマンドによって
詳細な処理の補完と拡張を可能にしている。
シェルスクリプトの最大の欠点は、それが粒度の細かい処理がほぼできない
という点と、関数による拡張性を持たないという点だった。
しかし、独自コマンドの作成という使い古された手法によってそれが
解決されてしまったのである。

さらにユニケージ開発手法はもう一つ重要な主張をしていることになる。
それはシステム開発につきもののRDBを不要であるとしていることである。
データの保存は全てファイルでいいとしている。
これも革新的な主張なのであるが、まだこちらは注目されていない。
むしろこちらの方がインパクトは大きいかもしれない。
RDBを使わずファイルを使用することで、データのポータビリティーがよくなる。
ただし、懸念されるのはパフォーマンスであるが、それは近年のハードの
性能向上と企業内システムという比較的小規模なシステムという2点によって
解消されるとしている。

| | コメント (2)

2009年5月 7日 (木)

OracleによるSUNの買収

OracleがSUNを買った。

組み合わせとしては問題ない。両者ともに欠けている部分を埋めることができる。

問題はSUNの技術の取り扱い方だろう。

1.Javaは当分このままだろう。
OracleがJavaをコントロールしようとした場合、OpenJDKとの軋轢が生じ、結果的にOracleもJavaも衰退するきっかけを作ってしまうだろう。Oracleはそこまで馬鹿な企業ではない。

2.MySQLはこのままの機能で塩漬けにされるだろう。
少なくともOracleDBと勝負するようなハイエンド領域にもってこさせることはしないだろう。当然だ。そしてここが重要なのだが、Oralceで実現しているLinux上でのDBクラスタリングの技術は絶対にMySQLでは実現させないだろう。このLinux上でのクラスタリング能力の実現こそがOracleの真の強みとなっているからだ。

3.Solaris上でのOracleクラスタリング機能を強化するだろう。
今までOralceクラスタリングがLinux上でのみ有名だったのは、Solaris上でのクラスタリングを実現してしまうとSUNに主導権を握られる可能性があったためだと思う。
しかしSolarisがOracleのものになった以上、もはやクラスタリングを強化しない理由はなくなったのである。(ただしDBクラスタリング機能がどこまで需要があり発展性があるのかは未知数だが)

4.SUNのオープンソース製品をどうするか。
クローズソースにした場合、オープンソース版の製品が分岐して派生することになるだろう。これはOpenJDKと同じことになるので、Javaと同様にクローズにはしないだろう。
問題はここからどのように収益を上げるかだ。何もしなければ株主から突き上げを食らうだろう。
Solarisにバンドルさせてオールインワンで売り出す、という手法は使えない。なぜならSolarisはサーバー製品であり、サーバー用途で使えるオープンソース製品は限られるからだ。
だから、無難に行くならばSUNと同じようにサポートで収益を上げるとなるのだが、そもそも無料のものを使うところは経済的に豊かとは言えないので、有料サポートを必要としないケースが多い。これがSUNのジレンマだ。
Java以外のオープンソース製品のサポートを全て打ち切るという可能性もある。これが短期的に見て最も経済合理的だろう。

5.データセンタービジネスについて。
いわゆるクラウドビジネスについてはまだなんとも言えない状況だ。
果たして企業が自社のシステムをクラウドに移行するのか。
移行するとした場合、WEBアプリケーションはより活況を呈するだろう。
そうなった場合、データセンターを持っているベンダーは超強い。
クラウド戦略を実行する上で、Solarisとハードウェアを持っていることはOralceにとっても必定である。クラウドはヒットすれば爆発的に進展する分野だ。
日本のSI屋は当然として、世界規模でSI企業は淘汰されるだろう。

6.OracleDBについて。
現状はOracleを選択する必然性がどんどん減っている。
MySQLで十分というところがほとんどだろう。
ただまだOracleのネームバリューは残っているので、高負荷・高信頼性が求められるところではOracleは使われ続ける。ただし、そのブランド効果がどれだけ長持ちするのかは未知数だ。
RDBという製品分野は既に枯れており、独自性を出すのは難しい。
Oracleのクラスタリング機能は数少ない独自性でありかなりの強みである。
がしかし果たしてクラスタリングだけでこのまま生き残れるかは微妙だ。
SUNのSolarisがLinuxによって衰退してしまったように、OracleのDBも他の無料や安いRDBによって衰退する可能性を持っている。MySQLを支配下に置いたところで、この状況は変わらない。どうするべきなのか。答えはわからない。

まとめ

OracleがSUNの資産で本当に有効活用できるのは、Solarisとハードウェア群だろう。
これでデータセンターを持つことができるようになる。
結局はデータセンタービジネスがどれだけ伸びるのかによってSUN買収の結果が決まるだろう。
オープンソース製品はJavaとSolarisを除いてサポートを停止する可能性が高い。
Solarisはクローズコードに戻る可能性もある。

| | コメント (0)

2009年4月14日 (火)

Javaの優位性はデスクトップにある

サーバーサイドでのJavaの優位性は当初はプロセス単位であったCGIに対して、スレッド単位で動くServletがあったJavaの優位性があった。

しかし、現時点ではハードウェアの進歩と他の言語の進歩によって、Servletの優位性はほとんどなくなってしまっている。
ただし、既存資産の多さとJavaの信頼性から今後もクリティカルな分野においては使われ続けるだろう。しかし優位性はもう無い。

唯一、Javaで優位性を今後も持ち続けるだろう分野がある。
それがデスクトップアプリケーションの分野である。
ここだけはJavaの独壇場であり、他のLL言語やC言語などが入ってくることは当分はないだろう。唯一、AIRを除いて。
だから、JavaとAIRのみは本当の意味でのガチンコ勝負になるだろうが、しかし、それでもJavaの強さは失われないだろう。AIRはまだ歴史が浅すぎるからだ。

しかしAIRにはJavaにはない動画扱えるというキラー機能があるので、今後も無くなるという事は無いだろう。

| | コメント (0)

なぜEmacs Lispは生き残るのか

それは、EmacsLispが異なるOS上のEmacsでも互換性が有り流通可能だったからである。

だから、ある特定のOS上のEmacsで動くEmacsLispは他のOS上のEmacs上でも動くがゆえに、それらは決して無駄にならず、したがって、EmacsLispを書くリスクが最小化されているのである。

リスクが少ないがゆえにそれらは書かれ、流通するようになる。
すると、その膨大な流通量がEmacsLispの仕様の固定化(後方互換性)を促し、結果としてEmacsをより強固にするのである。

Emacsが生き残っているのは、このEmacsLispの流通性によるところが大きい。

ただし、問題はEmacs自体の複雑さだろう。
Emacsの複雑さが将来の存在の存続を難しくて居るかもしれない。
しかし、EmacsLispこそはPerlと同じくらいに安定して使えるUnix上の汎用的言語なのである。

| | コメント (0)

仕様の単純さと生存可能性

ある技術が生き残るかどうかにおいて、
最も重要なファクターは、「仕様の単純さ」だろう。
次に普及度、必要性、標準化、などが続くのだろう。
たとえ現時点において、普及しており、標準化されており、流通していても、その技術の仕様が複雑だった場合は、将来において衰退してしまう危機を常に内包している。
C言語やCOBOL言語が生き残っているのは、その仕様の単純さがかなり大きな要因としてあるだろう。
Lispも同様である。ただし、CommonLispは仕様の単純さを捨ててしまったらしいので、たとえANSIで標準化されていようとも、常に衰退する危険を内包している。
そして、その意味では、JavaもC++も同様に仕様の複雑さゆえに衰退の危機を内包しているのである。

| | コメント (0)

補集合の戦略

補集合が全体集合のどれくらいの割合なのかを知ることで、
補集合を攻めることで対象集合を制することができる場合がある。
それは補集合が対象集合よりもかなり小さいサイズの場合だ。

たとえば、ある集団において、女性の数を知りたい場合、
補集合である男性の数が十分に少ない場合、男性の数を知るという
少ない手間で女性の数を知ることが出来ようになる。
これが補集合から攻めるときの典型的なパターンである。

常に補集合を意識して、補集合によって対象集合を制することができるのかを注意するのが「補集合の戦略」である。

| | コメント (0)

2009年3月21日 (土)

SUNがIBMに買収されるかもしれない

という事態になっているらしい。
GoogleのAndroidといい、いよいよJavaも危なくなってきた感がある。
改めて、概念層を整えることの重要性が身に染みている。

JavaとJavaScriptによって主要な概念群を獲得することが出来る。
Javaによって型あり言語のオブジェクト指向の概念群が得られ、
JavaScriptによって関数型のオブジェクト指向の概念群が得られる。
両者は互いに独立した領域であり、どちらかが優位に立つものではない。

基本的な概念さえ身に着ければ、後は詳細が言語によって異なるだけであることがわかる。
すると、最大の障壁である「学習の壁」がかなりの程度低くなるがゆえに、生産性が向上することになる。

開発において、最大の壁はリソースでも資金でも環境でもなく、学習なのである。
学習の壁さえ取り払われれば、後は純粋に創造性を発揮することが出来るようになる。
学習において最も重要なのは、核心的な概念を理解することである。

詳細な知識も確かに必須のものではあるが、それは言語毎に異なるので、絶対的なものではない。
言語仕様が乱立し、消滅し、生成される中で頼れるのは究極的には概念群のみである。
形のない無形の概念だからこそ、それらは破壊から免れるのである。
もっとも、概念群は実際のコードから抽象化を経て理解を得られるものであり、その意味でコードも概念の理解には必須となる。

もちろん、その言語をターゲットに決めたのならば、概念だけでなく、詳細も勉強する必要がある。
その意味で詳細の勉強も不可欠である。
概念群だけでOKというわけではもちろんない。

私は今JavaScriptを本気で勉強している。
JavaScirptの検証コードを書いている。
当然概念層についてもJavaにはない独創的な概念群が得られている。

一つの技術にしがみ付くのはそれが移り変わる可能性がある限り、危険性を持つものだ。
JavaとJavaScriptの学習が終わったのならば、もう検証コードを書くこともないだろう。
少なくとも高位のアプリケーション層で生きていくのならば。
そういう意味で、この2つの言語の組み合わせはとてもバランスが取れていると感じる。

| | コメント (0)

2009年2月11日 (水)

現場で使えない技術は最終的にはものにならない

いくらLispやRubyが凄いとは言っても、自宅での学習のみではものにはならない。
ここでいうものなるというのは、大体のパターンに習熟してアプリケーションが作れるようになるという意味だ。

職場で使える技術ならば、職場の空き時間を利用して学習することが出来る。
もちろん、実際に業務で使うことの学習効果も大きい。
なにせ職場というのは8時間くらいは費やす場だ。
その場で使わない・使えないというのはかなり大きなマイナスなのである。

そして、現場で使える技術というのは、実はかなり限られている。
特定の現場ではなく、一般的な現場、つまり、Javaプログラマとして参加する現場においてどこでも使える技術はというのはかなり少ないことが分かる。

それは、Java、JavaScirpt、VBA、Ant、シェルスクリプト、SQL、の6個の言語だ。

これ以外の言語は一般的な現場では使えないと見るべきである。

ここに、ActionScirptが加わればほぼ問題はなくなるのだが、残念ながら、FlashをJavaと並行して開発する現場は極めて少ないのが現状だ。

だから、この6つの言語に習熟することが、現場でのパフォーマンスを最大限に押し上げる背景となるのである。

| | コメント (0)

2008年12月30日 (火)

Ajaxによるビューとコントロール層の実装というアーキテクチャ

このアーキテクチャにはやがて適切な名前が付けられるだろう

ちょうど、Ajaxの技術が、「Ajax」という名称が付けられたときに一般に認知されて爆発的に広がったように、

このVとCを完全にクライアント層に委譲する

というアーキテクチャも、将来、おそらく欧米において、より適切な名称が付けられるだろう。
そして、その後に一般にもはっきりと認知され、爆発的に広がると思われる。

たとえば、「AjaxVC」という名称はどうだろうか?

サーバー側はRESTでDB操作だけとなると、ツール化できてしまうんだよね! 
http://blog.goo.ne.jp/xmldtp/e/2bccafa6beabee81d1883514c913da47

上記の記事ではAjaxかFalshがクライアント層においてのコントロールを全て担うという話で進められているが、これも同じアーキテクチャを話題としている。

ただし、FlashはJavaScriptと違ってHTMLを生成することができないので、やはり本命はJavaScriptだと私は思う。

またFlashの場合は携帯電話や、WiiやPSPやPS3などのゲーム機のブラウザにおいて、将来PC上と同じFlashが乗る可能性は現状では低い。
iphoneでもFlashが乗ることは今後もないと思われる。

FlashLiteはまだ携帯やゲームを制していないし、ActionScriptが古いままだ。

だから、それら携帯電話や携帯デバイスやゲーム機のブラウザなども考慮するならば、現状で同一のコードが動くのは唯一JavaScriptということになる。

JavaScriptならば、携帯電話のブラウザでもゲーム機のブラウザでもサポートされているからだ。

このアーキテクチャの凄いところは、RESTサービスを提供するサーバーさえ用意しておけば、あとはJavaScriptで画面とコントロールを作成するだけでWebアプリケーションが完成してしまう点だ。

そのためのRESTサービスを提供するサーバーが必ず出現するだろう

それに先駆をつけるのは、Google以外に考えられない
そもそもGoogleがこのアーキテクチャに気付いていないほうがおかしい。
となると、なぜ今までこのアーキテクチャが現れなかったのかのほうが不思議だな。
もしかしたら、現れないなりの問題があるのかもしれない。

現れないということは、このアーキテクチャは成り立たないのだろうか??

うーむ。

まあいつか自分で実験してみれば済む話だ。

| | コメント (0)

2008年12月26日 (金)

VBAの限界

VBAで2000行くらいのマクロを書いたのだが、いざリファクタリングする段階になってかなり困った。
GREP検索で直していかないといけない。
Eclipseのようなリファクタリング機能はVBEには無かったのだ。
これはかなり痛かった。
メンテナンスというか、改修が極端に難しいのが問題だ。

これはVBAという言語の問題ではなく、VBEという開発環境の問題だ

開発環境の問題ということは、これはEclipseやNetBeansでサポートされていない全ての言語に当てはまってしまう。

いやEclipseやNetBeansが出る以前の全てのコーディングに当てはまってしまう。

実際、このような開発環境が出てくる以前のプログラミングにおいて、リファクタリングや改修はどのように行われていたのだろうか。

リファクタリングや改修しやすいコーディングテクニックが存在したのだろうか。

しかし、そのようなテクニックがあったとしても、解決策とまでは行かなかっただろうと思う。
そのような万能なテクニックがあるとは思えないからだ。

いづれにしても、改修やリファクタリング時においては、統合開発環境の有無はかなり致命的な影響を与えるだろう

その意味で、EclipseかNetBeansでサポートされていない言語(.Netは除く)を使うのは、リファクタリングや改修時のリスクをどう分散させるかが肝となるのではないか。
RubyやLispで開発している人は、統合開発環境無しでの開発ではどのように対処しているのだろうか。

幸いにも、RubyはNetBeansによってサポートされたので、この問題からはかなり開放されたとみていいだろう。

このようにリファクタリングや改修という段階での生産性を考慮すると、統合開発環境でサポートされているかどうかはかなり重要な分岐点となる。

| | コメント (1)

2008年12月19日 (金)

JavaScriptの普遍性

携帯デバイスを制する言語がネットワークを制し、
ネットワークを制する言語がWebアプリケーションを制する。
とまあ大上段に構えないで普通に話すと、

現状、PCと携帯電話で共通で動く唯一の言語がJavaScriptである。

HTMLとCSSもあるがこれらは言語というよりはフォーマット形式だ。

JavaScirpt以外にも携帯電話に進出している言語は多い。
Java、Flash、来年以降はGoogleのAndroidもある。
ただし、これらは皆PC上のそれと携帯電話上のとではコードが異なり互換性は無い。
また今上げた言語は皆ネットワーク性を持っていないのだ。

即ち、JavaScirptのように同一のコードがネットワークを流通するという形態を持っていない。

仮に、JavaやFlashのActionScriptがPCと携帯で同一のコードが動くようになったとした場合、JavaならばAppletが、FlashならばActionScriptがそれぞれネットワーク性を持つようになる。(現状ではそうなっていないが)

しかし、JavaもFlashも現状ではPCと携帯デバイスの物理的なスペックの違いの大きさから、同一の環境を携帯デバイスに移すことに成功していない。
また今後もそれに成功する見込みは薄い。

GoogleのAndroidはまだ不明点が多すぎて何ともいえないが、もし仮に成功した場合は、PC上にAndroidを移植することは可能だろうから、真の意味で携帯とPCとで統一された言語が実現するだろう。

しかし、仮にAndroidが成功したとしても、それがAppletなどのネットワーク性を持っていない限り、常に携帯とPCとの間で互換性が失われる危険性を内包するだろう。
要するに、JavaScriptがPCと携帯とで同一のコードが動くようになったのは、ネットワーク性を持っているという点が大きな要因であると思う。

この同一のコードがネットワーク上を流通することによる互換性維持の圧力は非常に広範囲において有効に機能するように思う。

その意味で、ある言語がネットワーク性を持っているか否かはかなり重要な分岐点となり得る。
しかしほとんどの言語はネットワーク性を持っていないし、それが普通なのだろう。ほとんど言語は単一のPC内部の閉じた世界で機能することを求められるからだ。

JavaScirptはネットワーク性を獲得した数少ない言語の内の一つだろう。

最も通信プロトコルの世界では、TCP/IPやHTTPやTELNETやFTPなどネットワーク性は当たり前の前提にすらならないほどの特性なのであるが。
その意味でこれらプロトコルが将来において互換性を失う可能性は極めて低い。

無論、ネットワーク性があったとしても、ユーザー人口が少ない場合は、切り捨てられる可能性も高い。
しかし、JavaScriptはすでに十分にスタンダードになってしまっているために、無視することは出来なくなるのである。

長い前置きだが、これらの論によってJavaScirptが普遍性を獲得しているのが分かると思う。

PCに限れば、FlashのActionScriptはネットワーク性を持った言語なので普遍性を獲得している。

Appletも同じなのだが、Flashほどの使用人口を持たないため、ネットワーク性を獲得したとは言えないだろう。
これがJavaの大きな失敗の一つである。
Appletとサーバー間の通信を容易にしなかったために、Appletでのデータ永続化が困難になり、結果として廃れていったのである。
その意味で、実はJavaはネットワーク性を獲得していないのである。

SUNのJavaFXはどうだろうか?
この最大の売り文句は、PCと携帯で同一のコードが動くという点である。
JavaFXという共通プラットフォームを使うことで、PCと携帯デバイスで同一のコードを動かそうというのが狙いのようだ。
もしこれが実現したのならば、大きな進歩であり、革命的な変化を生むだろう。
しかし、私にはこんなうまい話が本当に実現するのかかなり疑問視している。
もし、技術的に可能なのならば、別に数年前から同じようなことが可能なはずだったからだ。
JavaFX(特にJavaFX Mobile)は未だに未確定部分が多すぎる。

Android、JavaFX、Flashの新しい携帯版、この3つが来年の秋以降に出揃う予定だ。
どれが成功するのかはまだわからないが、たとえ成功したとしても、ネットワーク性を持っていないことに変わりは無い。

唯一、この3つの中でネットワーク性を獲得しそうなのは、新しい形態版のFlashだが、どうなるのかは全く不明である。

すでにネットワーク性を獲得したJavaScriptについてはこの携帯デバイスでの戦いからは無視されている。

JavaScirptもブラウザのバージョンアップによって、その機能はより豊富になってきている。(僅かな更新量であるが)

しかし、JavaScriptの持っているネットワーク性によって、見えない互換性維持の圧力が常にかかっているので、今後もJavaScriptが互換性を失う可能性はすくないだろう。

それに、以前の記事にあった、次期ECMAScriptの仕様についても、大きく変更はしない方向で決定している。
この決定はかなりの政治的な戦いが背景にあったと思う。
なにせJavaScriptを制することが出来れば、ネットワーク上の言語を制することが出来るのだから。
しかし、結局、現在と変えない方針で行こうということは、どの企業も主導権を誰にも渡したくなかったことの現われと見ている。

| | コメント (0)

Ajaxの真の革命性とは

Ajaxの革命性の本当の意味は、今までサーバー側にあったコントロール層がクライアント側に移動することによって、サーバー側の複雑さが激減し、サーバー側はモデル層のみを担当するようになることにあるのではないか。
これによって、サーバー側はデータの永続化のみを担当することになる。
ページの更新は「全て」JavaScriptのAjax機能によって行う。
こうすることで、サーバー側は純粋に入力に対して応答を返すDBの機能のみでいいことになる。

まあとはいえこれは理想論で、サーバー側にもある程度のロジックは必要となる。
(データチェック、SQL発行、など)
しかしイメージとしては、RDBにクエリーを投げる感覚に近い。

しかし、このビューとコントローラーをクライアント側に全面的に移行するという手法は、これまでのMVCパターンの実装とは全く異なる実装を要求するだろう。
(最も問題となるのはセキュリティだろう)

もし、サーバー側へのデータ入出力が形式化(XMLやJSONなど)されるようになった場合、理想的にはAjaxで実装されたHTMLとJavaScriptをWEBサーバーに置くだけで、Webアプリケーションが完成するようになる可能性がある。
ただし、Ajax専用のデータベース用サーバーをどこかに準備する必要がある。

永続化されるデータは形式化されたAjaxのリクエストによってサーバー側の事前準備なしにデータの追加・更新・削除が可能になるだろう。

この事前準備無しにというのが重要で、現在常識となっているRDBの設計・構築が不要であることが重要だ。
RDBのデータ形式にとらわれないがゆえに、事前準備が不要となる。
ただしデータの格納先としてRDBを利用するのは問題ない。

これは極端にJavaScriptに頼った実装方式のため、どれほどの現実性があるのかは不明だ。
しかし、私の考える一つの理想像ではある。

RDBとの連携を無くすことによって、抽象的で普遍的なデータの永続化手段が使われるようになる。(最も原始的なのはMap形式だ)
これによって、SQLをロジック内で生成するという現在のサーバーロジック層の主な処理を無くすことが出来る。

無論、RDBを使用する現在のアーキテクチャの方がパフォーマンスは1桁以上はいいだろう。

しかし、そのパフォーマンスを犠牲にするとしても、Ajaxによる大幅なアーキテクチャの簡素化は大きな魅力である。

| | コメント (0)

JavaScriptでコントロール層を担えないか?

JavaScriptでMVCの内のVCを担うことが可能なのではないか。
それはAjax技術によって可能となる。

Ajax技術によってJavaScriptでの画面更新が可能になるからである。
つまり、サーバー側はMのみを担うことになる。
といっても、サーバー側にDBのみを置いておくという訳にもいかないので、
最低でもDBへのコネクターとなるプログラムを置く必要がある。
しかし、サーバー側がコントロールを担当しないことで、
かなりシンプルになることだけは確かである。

ただし、これはセキュリティ上の問題を抱える可能性が大きい。
なぜならばコントロール層をオープンにすることで、
どのようなことをすればどうなるかが丸見えになるからだ。
もちろん、本質的に重要なのはデータであってロジックではないのだが、
それでもロジック層を公開することで、データ層へのアクセス経路を
公開することになるのだから、かなり危険だと言っていい。
しかし、そのリスクさえうまく対処できれば、サーバー側からコントロール層をクライアント側に全面的に移すことが可能となる。

| | コメント (0)

2008年11月 3日 (月)

『実録!天才プログラマー』 アスキー出版局

古い本(1987年)だが凄いプログラマーの普遍的な考え方は色褪せていない。

ビル・ゲイツ
P73
最悪のプログラムというのはこういうやつでしょうね。
つまり、それを最初に書いたプログラマーが、
しっかりとした基礎を築くこともなく、
しかも将来それにかかわりをもたない、
という場合のプログラムね。

チームの中の少なくとも一人は、プログラムを真に同化できるだけの
能力の持ち主であると証明済みでなくちゃなりません。

P76
腰を落ち着けてコーディングにとりかかる以前に、
命令の大部分はすでにぼくの頭のをよぎっているわけなんですね。

P81
最良の考え方はこうですね。
グループを小規模にしておくこと。
すごく頭の切れる者だけをグループに入れること。

P82
あるプログラムについて、その制作者と話してみれば、
彼が優れたプログラマーかどうかはたちまちにしてわかりますよ。

P83
プログラミングには、ものすごいエネルギーが必要なんですね。

P84
プログラミングの能力を試す一番いいやり方は、
プログラマーに30ページのコードを手渡して、
彼がどの程度の速さでそれを読み切り、
そしてどの程度理解できたかを調べてみる、ことですね。

-コンピュータ・サイエンスの勉強は、プログラマーになるための準備としては最良の方法でしょうか。
違いますね。最良の方法はプログラムを書くことですね。
それを、人の書いた優れたプログラムを研究することね。

| | コメント (0)

Javaで不要な技術だが重要だと一般に認識されている技術

それは以下の通り
・WEBフレームワーク
 (Struts、Spring、JSF、Seaser、etc...)
・ORマッパー
 (Hibernate、iBatis、JPA、etc...)
・DIコンテナ
 (Seaser、etc...)
・AOP
・デザインパターン
・JUnit
・EJB

特にWEBフレームワークの勉強はほとんど意味の無い勉強の代表例だろう。
これら派手に宣伝されている技術は確かにSI会社を儲けさせるものではあるが、
しかしアプリケーション作成の本質的な技術ではないことに注目したい。

要するに、複雑なフレームワークであるほどにSI会社は儲かるのである。
なぜならば、それによって顧客をロックインすることができるからだ。
ではなぜEJBが排斥されたのかというと、あれはSI会社にとっても複雑すぎたからだった。

それにしてもSI会社の思惑と雑誌やサイトで宣伝される技術がこうも一致しているとは意外な発見だった。

フレームワークはSI会社にとっては現在は金の成る木だろう。
フレームワークによって自分たちの会社に顧客をロックインするからだ。

恐ろしいのは、フレームワークの勉強をして開発をすることは、
個人のプログラマにとっては何の技術的な収穫もないということだ。
顧客にとっても別に特別な機能が実現できるというわけでもないので収穫は無い。
では収穫があるのはどこかというと、これがSI屋さんなのである。
フレームワークを使った開発は、プログラマもエンドユーザーも幸せにはならず、
SI会社のみが幸せになる構図になっている。

このフレームワークのビジネスモデルはまだ業界全体にばれていないが、
いづればれるときが来るだろう。
しかしそれがばれるのはまだまだ先だろう。

いづれにしろ、これでますますSIでのWEB開発をする利点と理由は無くなった訳だ。
考えてみれば現在の職場での開発がすぐにシェアウェア作成に役立たないのも、
NTTDATAのフレームワークを使っていて、根本的な部分が理解できない仕組みに
なっているのが原因ではないか。

フレームワーク依存というビジネスモデル。
技術的に正統で先端を行っており開発効率を上げメンテナンスも楽になる、
という謳い文句。
しかしその実は単にコード層を複雑にしてSI屋に依存させるのが目的なだけの代物。これでは普通の顧客も、いやプログラマも気付かないのは無理ないだろう。

おそらく現時点でこのフレームワーク依存の戦略に気付いているのはSI企業のトップ層のみだろう。

もって恐るべしである。

| | コメント (1)

2008年9月27日 (土)

オブジェクトの属性

・オープン・クローズ
 オブジェクトのメンバーを追加・削除・更新することができるオブジェクトを
 オープンオブジェクトという。
 逆にメンバーの更新が一切できないのをクローズオブジェクトという。
 Javaのオブジェクトはクローズオブジェクト。

・ミュータブル・イミュータブル
 オブジェクトの状態を変更できるオブジェクトをミュータブルオブジェクトという。
 オブジェクトの状態を変更できないオブジェクトをイミュータブルオブジェクト
 という。
 イミュータブルオブジェクトは状態を持たないという点でオブジェクトの定義に
 反しているように見えるが、状態を一切持たないのではなく、オブジェクト生成時に
 指定された状態が固定されているという意味ではオブジェクトなのである。
 これがデータとイミュータブルオブジェクトとの違いとなる。

・アクティブ・パッシブ
 他のオブジェクトの状態を変化させるオブジェクトをアクティブオブジェクトという。
 他のオブジェクトの状態に影響を与えないオブジェクトをパッシブオブジェクト
 という。
 より直接的言うと、スレッドがアクティブオブジェクトであり、それ以外の普通の
 オブジェクトがパッシブオブジェクトということになる。
 この分類の重要性の意味は、スレッドがオブジェクトであることを鮮明に打ち出した
 という点にある。
 確かに、スレッドはある定性的な状態をもっている。
 スレッドの生成、待機、実行、終了、や優先度、などの状態のことである。
 これら状態を持っている以上、スレッドもまたオブジェクトなのである。
 アクティブとパッシブという分類はスレッドとオブジェクトをオブジェクトという
 統一的な観点から扱うことを可能にするのである。

| | コメント (0)

2008年9月 1日 (月)

バカフォーマットについて

PJにおけるドキュメントには大抵はフォーマットが決まっている。
フォーマットが決まっていない、自由なドキュメントというのはほとんど無いと言ってもいいだろう。
そして問題はこのフォーマットの出来にある。
大抵のドキュメントのフォーマットには何らかの問題がある。
ドキュメントのフォーマットにおいて最も重要な特性は「柔軟性」と「拡張性」である。
しかし、大抵の場合はこの2つの要素について真剣に考えられていないフォーマットが採用される。
なぜならば、フォーマットを決める決定権を持つのはいつも大抵は現場で作業をしない管理職の層の人間だからである。
故に彼らは自分が決めたフォーマットがどのような影響を与えるのか実際に体験することはない。そしてその失敗のリスクも負うことがないのである。
なぜならば、大抵の場合はドキュメントのフォーマットについて問題が提起されること自体がほとんどないからである。
今までそのような問題提起をする事例がなかったし、そしてドキュメントのフォーマットの重要性についてほとんどの人が無自覚であるというのも理由である。
このような背景から出来の悪いフォーマットが生み出される。
私はこのような出来の悪いフォーマットを「バカフォーマット」と呼んでいる。
この出来の悪いフォーマットに則ってドキュメント作ると、作る人もバカになるし、それを読む人もバカになるからだ。
バカフォーマットによる悪影響が管理職層の人間にも分かるようになるのは、ドキュメント作成の段階の遥か後のコーディング終了後のテストの段階である。
この時点でテスト結果が思わしくないということに気づく。
しかし、それがドキュメントのフォーマットが影響していると気付く人はいない。
あるいはいたとしても既に後の祭りであるし、なによりもそれを認めることは管理職層にとっては自殺行為である。がゆえにフォーマットについて議論されることはない。

考えてみればみるほどに、PJにおけるドキュメントのフォーマットが及ぼす影響というのは大きなものであることがわかる。
まずはこのドキュメントのフォーマット決定権、あるいはその修正権だけでも現場の人間に委譲させる必要がある。

そしてこれはなぜコーディングがドキュメントを書くよりも楽なのかの説明にもなる。
それはコーディングにはバカなフォーマットがないが故に、そしてバカフォーマットの影響から逃れることが出来るが故に、それはドキュメント作成よりも楽なのである。
無論、PJの中にはコーディングにおいてもバカなフォーマットを強制するような所があるだろう。
そのようなPJからはもう退散するしかない。
そこは既に自由度が限りに無くゼロに近いからだ。

いづれにしても、今後はバカなフォーマットを見過ごすわけにはいかないだろう。
あるいは、政治力の関係でバカなフォーマットに手出しが出来ないのならば、ドキュメントは徹底的に手を抜いて作るしかないだろう。

本当に必要なのは、バカなフォーマットに対する適切な概念・言葉なのである。
それさえあれば、それで相手を追い詰めることが出来るからだ。
たとえばコミュニケーション、たとえばセクハラ、たとえばコスト、などが良い例である。
これら道具としての言葉がない限り、バカフォーマットの問題が表面化されることは今後もないであろう。

| | コメント (0)

2008年8月19日 (火)

ECMAScript4が消える?

ECMAScript4が消える?
http://d.hatena.ne.jp/higayasuo/20080818/1219032946

Flash Player 9 の発表以来、Adobe は ActionScript を ECMAScript 標準第 4 版として提案された ECMA-262 Edition 4 (ES4) に完全準拠させるという目標を公にしてきました。この ES4 は、Adobe, Mozilla, Opera, それから Google を主要なサポーターとして標準化が進められていましたが、一年ほど前に Microsoft と Yahoo! 主導で ECMA-262 Edition 3.1 (ES3.1) のワーキンググループが開始されて以来、2 つの異なる ES3 後継仕様案が並存する状況が続いていました。

先週の発表は、ES4 に関する標準化作業を中止し ES3.1 に集中することが決定されたというもので ECMAScript Harmony プロジェクトと名付けられています。

ES4は、はっきしいって複雑です。仕様的には、Javaをさらに複雑にした感じ。Javaよりも複雑なスクリプト言語ってどうよって気持ちがある。

だから、the Ecma International Technical Committee 39 (TC39) がES3.1に集中するという決定を下したことは、良いことだと思う。

で、Adobeがどうでるか。ここからは想像ですが、ES3.1をベースに機能拡張をしてAS4を作り、ES3.1でもAS4でも、オプションの切り替えで動くようにするのではないでしょうか。いまでも、ES4とAS3のモードを切り替えることできるしね。

残念ながら私の予想は当たる方向に動いているように感じる。
即ち以下の私の直感が実現するのではと感じている。
JavaScriptは消える。
仕様の分裂と仕様の複雑化とで。
これはJavaにも当てはまる。

次期 ECMA Script でJavaScirptは大幅に変わることになる。
そして仕様の分裂と複雑化は避けられない。
なぜならば、MicrosoftなどのOS企業にとって、Javaの次の敵が何を隠そうJavaScriptなのである。
JavaScriptによるブラウザ上の統一言語によってOSの強みと囲い込みができなくなる可能性がある。
そしてJavaScriptは独立した企業が制定している言語ではなく、中立的な団体が制定している言語なのであからさまに敵にはしにくい。
しかしその仕様化団体の中に参加してその仕様を決める立場に立ってしまえば話は別である。
こうしてJavaScriptは死んでいくのである。

Java、JavaScript、ときて次のターゲットはActionScript(Flash)だろう。
JavaとActionScriptはともにここ数年が死ぬか生き残るかの分岐点である。
Javaは既に仕様の複雑化が発生している。
ActionScriptは冒頭の引用にもあるように、JavaScriptにリンクしようとしているが、それができない状態になっている。
JavaScriptの仕様が分裂する以上、その影響はActionScriptにも及ぶだろう。

ふう。
Java、JavaScript、ActionScriptが将来消えるなんてほとんど誰も予測はしていない。
しかし、これらを分裂し、消滅させたがっている勢力は確実に存在している。
そして、それらが消滅した場合のダメージと衝撃はかなり大きなものになるだろう。

これら3つの言語に特徴的なのは、それぞれがネットワーク性をもって互換性の維持へのストレスを常にベンダーにかけているという点である。
これら3つの言語の仕様の分裂を防ぐ最終的な力となっているのはネットワーク性である。
ネットワーク上を同一のコードが流通することによる互換性維持への圧力は最も自然な互換性の維持を促す。これは自然言語の互換性と同じメカニズムが働いていると予測する。
このネットワーク性の持つ力と企業の思惑との衝突が、これからの言語戦略を決めるのである。

| | コメント (0)

2008年8月 1日 (金)

理想的な新人PGの教育メニュー

やはり最も実戦的でありかつ効果的なのは、既存のプロジェクトが完成形としてあり、そのプロジェクトに対して、新機能の追加・既存機能の変更をしてもらうことだろう。
こうすることで、既存のソースコードの理解と新規ソースコードの作成の両方が学べるようになる。
ただし、これをするためには基本文法のほぼ完全な理解が必要となる。
しかし、新人が作成したプロジェクトをCVSで管理することによって、研修の履歴はかなり充実していくはずである。

これは正解がないのがポイントで、正解がないがゆえに様々な方法が可能になるし、任意の機能の追加・更新を発行することで、マンネリ化もかなり防ぐことが出来る。そして、完成形のプロジェクトを様々な種類で用意することで、より効果的に学習範囲を広げていくことが可能となる。
実は何を隠そうこの方法はあのビル・ゲイツが力説していた新人PGを育てる方法なのである。

そして現在はCVSやSVNというバージョン管理ツールがあることによって、この方法はより実践することが容易になっている。
これらがあることによって元のソースからどのように変更が入ったかが差分として表示可能だからだ。これはEclipseの登場によるところも大きい。

また、既存プロジェクトに対して、研修担当が適切な変更以来を新人PGに発行することで、難易度の調整も容易になる。ちなみにこれによって今後メインストリームになるであろう「チケット駆動開発」の経験もすることができるようになる。

また新人が自分でテストメニューを考えてテストをし、エビデンスを取得することで、実践的なテストも経験することが出来るようになる。

またEclipseとCVSを使用することで、これら必須のツールの学習も同時に経験できる。

そう。実はこれはプロジェクトに配属されたばかりのPGが始めて自分の案件を開発する工程そのものなのである。

| | コメント (0)

2008年7月21日 (月)

なぜクラスにまとめるのか

よく言われるオブジェクト指向の説明として、情報をクラスという単位にまとめることの利点が言われる。
クラス=オブジェクトの単位で情報をまとめることにより、扱える情報の粒度を上げることが出来るのがオブジェクト指向言語の最初の利点であろう。

しかしここで疑問としてあがるのは、それはメソッド(関数)ではなぜいけないのかという点である。
メソッドも情報を処理の単位でまとめることができる。
なぜメソッドではなく、クラスの単位でまとめる必要があるのか?

それは、私の回答としては、
メソッドは状態を持たないが、クラスは状態を持てるため、
というのが回答となる。
そしてこのことが私の最初のオブジェクト指向に対する悟りであった。
悟りというと大げさだが、それくらいの衝撃が私にはあったのだ。

ここで初めてクラスが状態を持つことの重要性が理解されることになる。
そして、従来からのパラダイムであった、メソッドとフィールドの2つだけでは状態の分類と制御が難しくなることも理解できるようになる。
ここからクラスの必要性=オブジェクト指向が理解できるようになるのである。
そして同時にオブジェクトの概念も得ることができるのである。
また、何をメソッドとし、何をクラスとするべきなのかを判断できるようになる。

| | コメント (0)

2008年7月 5日 (土)

リーダーの資質と役目

遂にリーダー論などというものを論じるほどに劣化してしまった私のブログであった。

リーダー論。よく論じられ、論じられ続け、もはや胡散臭いイメージしかない。
大体はそれらしいことを言っていれば論にはなる。そして否定も肯定もない。
天気の話のようなものなのである。
だから真剣に聞く価値はないということが誰でもわかるようになる。

さて、そのような天気の話をこれからしたいと思う。
しかし、これは私の結論であり、巷にあるような論とは違うと思っている。
しかし、長い目で見れば、それほどの価値の無い記事になるだろう。

未来を予測するだけでなく、それを公言することは、常に未来に対する最大の防御策なのである。

●リーダーの資質
リーダーの資質とは、「物事の本質を捉える能力」の高さにある。
ある目的を実現するのに、肝となる勘所を捉える能力のことだ。

リーダーの役割とはこのような本質的な部分を把握することだといえる。
そうすることでメンバーの作業のリスクとコストを抑えることが役割だといえる。

これが捉えられると、以下のことが可能となる。

1.部下に適切な作業の指示を出すことができるようになる
2.部下に無駄な作業を指示しないですむようになる
3.部下の仕事をある程度は適切に評価できるようになる
4.状況の変更に対して適切に対応することができるようになる
5.ある人がリーダーに向くかどうかの能力を計ることができるようになる
6.力を入れるところと、力を抜くところのコントロールが可能になる
7.自分がリーダーとして適切かどうかを把握できるようになる

以下詳説してみる。

1.部下に適切な作業の指示を出すことができるようになる
物事の本質を捉えているので、目的の実現に最も重要な作業から指示することができるようになります。つまり、適切な指示が出せるようになります。

2.部下に無駄な作業を指示しないですむようになる
物事の本質を捉えているので、無駄な作業を指示する可能性はかなり低くなります。

3.部下の仕事をある程度は適切に評価できるようになる
物事の本質を捉えているので、部下(だけでなく周りの人)の仕事がどれだけそれに対して貢献したのかを適切に評価できるようになります。

4.状況の変更に対して適切に対応することができるようになる
物事の本質を捉えているので、状況が変化した場合に、どのように振舞えばいいのかという判断が適切になります。
また、本質が変化したり、通用しなくなった場合も、改めて本質的な要素の把握を開始することができるようになります。

5.ある人がリーダーに向くかどうかの能力を計ることができるようになる
物事の本質を捉えているので、ある人が本質的な要素を抑えているかどうか、把握しているかどうかを見極められるようになります。
それによってその人が(少なくとも現時点において)リーダーに向いているかどうかが判定できます。

6.力を入れるところと、力を抜くところのコントロールが可能になる
物事の本質を捉えているので、ここは丁寧に力を入れてやるべき箇所だ、ここはそこまで丁寧にやる必要の無い箇所だ、という判断ができるようになります。

7.自分がリーダーとして適切かどうかを把握できるようになる
物事の本質を捉えていることの重要性を分かっているので、自分が現時点でリーダーとして適切なのかどうかが自分で判断することができます。
また、仮に本質を捉えていると思っていても、それでも上記の項目の効果を得ていないのならば、あるいは得られる可能性がなかったのならば、現時点では向いていないとわかるのです。

ちなみに、上記の項目を満たしていない、あるいは正反対の状況になってしまっている、という場合、そのリーダーには適正がないと判断していいだろう。

ここにはよく言われるような、情熱とか、性格とか、ビジョンとか、姿勢とか、雰囲気とか、コミュニケーションとか、そのような「精神的な要素」は評価対象とはしていないという点に着目して欲しい。

それらの要素はあくまでも普通人のレベルでいいのである。
問題はその人の作業領域において「本質的な要素を捉えているか否か」という1点だけである。

もちろん、「本質的な要素を把握する能力」は個人の仕事においても重要なパラメーターとなる。
これができていない人は仕事の戻りが多かったり、時間配分が悪いだろう。

| | コメント (0)

手順書という罠

今、職場で手順書を求める人がいる。
作業の引継ぎや既存の作業で手順書がないと、とにかく手順書を作らせようとするのだ。
確かに、手順書が必要な作業はあるし、基本的にはあった方がいい。

しかし、全ての作業に手順書を求めるのは愚かである。
なぜならば、プロセスは固定されていないからだ。
もし、ある作業プロセスがほぼ固定されており、今後も変更される可能性は低い、
というのならば、きっちりとした作業手順書を作る意味はある。
しかし、ほとんどの作業プロセスは数ヶ月から数年の単位で移り変わるものである。

それも作業が複雑であればあるほどにその変更可能性は高くなる。
そして、その作業手順書の変更コストも高くなる。
そして、そのような複雑な作業であるほどに手順書のニーズは高くなる。
ではどうすればいいのだろうか。

結局、プロセスの変動性に対して、手順書はしばしば無力なのである。
そして、手順書を覚えることは、残念ながら、手順書を作る能力を与えないのである。
だから、プロセスが変更になった途端に、あるいは、手順書が通用しない場面になった途端に対応ができなくなるのである。
これが手順書に頼ることの大きな弱点である。
手順書は便利ではあるが、それに頼ってしまうのは危険なのである。
だから手順書は罠だと言ってもいいのだ。

大切なのは、「手順書を作る能力」である。手順書そのものではない。
手順書を作る能力や経験を得てしまえば、プロセスの変更や手順書が通用しない場面に対しても対応できるようになる。

そして、残念ながら手順書を作る能力を得るための手順書は存在しないのである。
つまり、手順書を作るための手順書は存在しない
ここで手順書万能の戦略は破綻するのだ。

では、プロセスを変更・設計する能力、手順書を作成する能力はどのようにして得られるのだろうか。
これは大げさに言っているが、普段から我々が行っていることである。
しかしそれについてはあまり意識していないのが現実ではないだろうか。
これはプロセスや手順書をうまく作るための方法論を考えることを意味する。

私が思うに、それは鍵となる概念や目的を捉える事である。
中心となる概念や目的を捉えることで、それを中心にしてプロセスの設計や手順書の作成が可能となる。そしてそれらの変動に対しても対応できるようになる。
そして往々にしてそれら中心となる概念や目的は少数である。
しかし、これらを捉えることは問題の複雑さに比例して難しくなる。

しかし一端それらを捉えてしまえば、それを人に伝えることは可能である。
それを理解させることは容易である場合もそうでない場合もあるだろうが。

だから、本当の意味での引き継ぎというのは、固定された手順書を渡すことではなく、それらの手順書が書かれた背景やプロセス、そして中心となる概念や目的を伝えることを狙わなければ駄目なのだ。

しかし、上記のことを手順書万能観に支配されている人間に言っても、理解されるとは思えないところが現在の問題なのであるが。

そのような人間に対しては、あえて手順書万能観のまま突き進んでもらい、その限界を体験してもらうしかないと思っている。
ただし、極力周りを巻き込まない形で、だ。(それが難しいのがこの種の人の問題点なのだが) その後に、上記の話をすれば理解されるだろうし、そもそも話をする必要性すらなくなっているだろう。

ちなみにこれはプログラミングの学習についても言える。
コードレベルの詳細な知識を溜め込むよりも、概念を捉えた方がより広い言語に対応することができるようになる。

| | コメント (0)

2008年6月10日 (火)

P2Pを制する言語

次世代ソフトウェアのベースは間違いなくP2Pにある。
しかし、現時点ではまだ(未だに!)P2Pで動くソフトウェアは一般的ではない。
もしP2P技術が一般化したらサーバー・クライアントの技術が陳腐化するだろう。
そこではサーバー・クライアントという概念のレベルで陳腐化が起きる。
まだP2Pをある言語が制するということは起きていない。
それがどのような言語になるのか、まだ分からない。
しかし、その言語はブラウザ上で動く言語ではないだろう。
P2Pをどの言語が制するのか。あるいはどの言語も制しないのか。
P2Pを制することが出来た言語は圧倒的なアドバンテージを築くだろう。

| | コメント (0)

2008年6月 3日 (火)

Javaが無くなる日

今はJavaが隆盛であるが、皆Javaがこのまま安定して10年は存在すると思っているのではないか。
私はJavaはここ数年のうちに分裂すると見ている。
またJavaVMの互換性も数年のうちに捨て去られるだろう。
これはSUNの戦略として行われるだろう。
なぜならば、Javaのコモディティ化とSUNの利益とはやはり矛盾するからである。
そして、それはSUNにとってだけでなく、そのほかの有力IT企業にとっても不利益なのである。
GoogleのAndroidはその現れである。

OSメーカーにとってもJavaは天敵である。
Microsoftはいうまでもなく、Appleにとってもそうである。
Appleは32bit版のJavaを切ったのもその現れである。
またIphoneにJavaVMを乗せないのもその現れである。
OSメーカーにとってJavaは敵である

数年後にはその兆しは顕在化し、SUN以外のJavaVMが複数登場しているだろう。
そしてJavaのバージョンアップに伴ってそれらの間のづれが埋められなくなり、
遂にはソースコードの互換性がなくなってしまうだろう。
最終的にはJava1.4くらいのバージョンのコード以外は互換性の問題から使用が控えられるようになるだろう。
そのような状況になっても、互換性を維持したJavaの開発とリリースはされるだろうが、もう収集はつかない状況になっていると思われる。
そして、JavaはCOBOL化するのである。

ざっと、これが次に来る革命のイメージだ。
次の革命はJavaの死によって始まるのである。

今の企業システム、金融システムはJavaに対する信頼を背景に作られている。
その信頼(互換性と安定性)が崩壊する衝撃は大きいだろう。

そして、Javaに対する信頼が崩壊したとき、Javaの時代に一つの区切りがつくのである。そしてそのとき、SUNは自らの手で大ダメージを受けているだろう。

そしてその後の時代はどうなるのか。
VMという手法には頼れないと感じられた後の時代には別の手法が模索されるだろう。
そのときに互換性を維持したまま残っている言語は非常に少ないだろう。
JavaScriptもECMAScript4になることによって互換性を失っている可能性がある。

そのような時代に備えておく必要がある。

| | コメント (0)

Groovyは潰されるだろう

なぜならば、それによってJavaそのものが喰われてしまうから。
要するにGroovyが成功してしまうと、Javaそのものが完全にとはいわないまでもほとんどが置き換わってしまう危険性がある。
だからSunはGroovyを支援していないのだろう。
JRubyなどの別のスクリプト言語はまだJavaと並存できる。
それらはAPIも文法も異なるため、並列している存在だからだ。
しかしGroovyは違う。それはJavaそのものをラッピングしてしまう
JavaのAPIをそのまま使用してしまう。
Javaそのものを置き換えてしまう。
Sunはさすがにこの革命性を感じ取った。
だからSunはJRubyには支援をしても、Groovyには支援をしないのである。

| | コメント (0)

2008年6月 2日 (月)

結局Groovyではないか?

結局、Javaの資産を生かせた上で素直なスクリプト言語となると、
Groovyの一択ではないか?
どう考えてもGroovyがJavaVM上のスクリプト言語としては本命なのだが。

http://www.infoq.com/jp/news/2008/03/jdl_shootout

まだ仕様が固まっていないのが難点だが、もしGroovyがJavaVM上のスクリプト言語としての地位を確立してしまった場合、さらに将来的にはJava言語そのものと並列な地位にまで昇るだろう。

だからGroovyはJavaにとって革命的なのである。
未だその革命性に気づいている人は少ないだろうが、Groovyによって全く新しいJavaの時代が訪れるだろう。

ただし上記のことは無事にGroovyが産まれればという前提であるが。

| | コメント (0)

2008年5月26日 (月)

Javaは着実に自殺に近づいている

http://www.infoq.com/jp/news/2008/05/JSR-308

発表された Java SE 7 をみるつけ思うのは、やはりJavaはこのまま複雑になって死んでいくのだろう。このままいけば間違いなくC++と同じようになる。
最終的には複雑で使いづらい言語になってしまうだろう。
そしてC++からJavaに流れたように、Javaからより簡易な言語にプログラマが流れるだろう。

その有力候補としてRubyがあると思う。
しかしRubyも同じように複雑化を辿るだろう。
既にその兆候は出ている。

結局、JavaにしてもC++にしてもそうだが、皆強がって複雑で分からないとは言えないのが問題なのだ。
逆に複雑だというと、「これが?」というようなおとぼけで返すのが定番になっている。
そしてある瞬間から簡単で理解しやすい言語に流れ込むのだ。
C++からJavaがそうであったように。

Javaは現在でも十分に複雑で分かりにくい言語であるが、そのことを認めることは自らの弱さを認めることになるために絶対に認められないという人が多いだろう。

正直、Java SE 7 はもう限界だと感じる。
現状で必要の無い文法や機能を増やして複雑化する意図がよくわからない。
少なくとも私には限界だ。つきあう義理は無い。

アプリケーションを作成するのに必要最低限の機能を学んだ後は、もう付き合う必要は無い。さっさと別の言語に進んだ方がいいだろう。

| | コメント (0)

2008年5月 5日 (月)

HTTPサーバーの重要性

HTTPサーバーの重要性がわかった。
これはつまり、HTMLとJavaScriptをGUIとするアプリケーションのロジック層を実装するためには、その仲介としてHTTPサーバーが必要になるという次第だ。
つまり、ローカルにHTMLファイルを置いて、その通信先をローカルのHTTPサーバーにしてしまえば、それだけでローカル資源にアクセス可能な簡易的なGUIアプリケーションが構築可能になるということだ。
ここで重要なのは、このHTTPサーバーはあくまでもローカル環境において閉じた使用法を想定されているという点だ。
だから、苫米地も黒田もLispでのHTTPサーバーの開発にこだわったのだ。
だからだったのか。。。
そうか、HTTPサーバーさえOS上で動けばGUIはHTMLとJavaScriptで構築できるのか。。考えてみれば当然だが、あまりにも一般化されていない知識だ。
この観点から考えてみると、JavaとLispはHTTPサーバーを持っていることになる。
他にマルチOS環境に対応した言語でHTTPサーバーを持っているものは?
Rubyは持っていた。webrickというフレームワークで可能になるらしい。
そうか。これがあるがゆえにRubyは究極的には独自のGUIを持たなくても済んでいるわけか。。
ということは、ある言語において、マルチOS対応のHTTPサーバーが書けるかどうかは、その言語がGUIインターフェースを持てるか否かの分岐点となると。。
うーむ。この事実は重大だ。
そうか。だからRubyの人たちやLispの人たちは独自のGUIが無くても泰然としていられたのか。

| | コメント (0)

2008年4月13日 (日)

コード層、概念層、現象層

コードを動かすことで概念が抽出されるが、そのためには動かした結果を見る必要がある。
コードを動かしたことで生じる現象から概念が得られる。
だからこの現象という記号化できない領域も実はコードと概念とセットになって存在している。コード、現象、概念、という流れがある。

コードがどのようにして現象を生み出しているのか、その過程を知ることは出来ない。
その過程は人間には隠されている。
私に出来るのは、コードと得られた現象から、その動きを理論化することのみである。
そこで得られた理論や概念が正しいという保証は無い。
なにせそれは過程そのものではないのだから。
だからそれらの理論や概念は常に破綻の危機を内包している。
しかしそれによってコードの動きが掴めるのならば、それは道具として極めて有効である。

コードと現象のセットのみでとりあえず進むことも出来る。
ある現象を起こすためのコードを丸暗記する方法だ。
これもある程度は有効である。しかし当然ながら応用が利かなくなる。
しかし、ある現象から理論化が難しい場合は、とりあえずこの方法を取るしかない。

通常の学習では、書籍でもWEBでも講義でもいいのだが、理論、コード、現象の順番に学ぶことになる。これが普通なのだが、余りにも天下り的な教え方なので、その理論の由来や必要性が体感できない。また間違った理論や有効性が薄い理論の区別も出来ない。
よって通常の学習の後の習得の過程はそれを逆にたどることになる。
つまり、現象、コード、理論の順番に反芻していくことになる。

現象は絶対的な事実であり、コードも事実であるが、理論は異なる。
また、ある現象に対して、複数のコード群が対応してるのだから、コードの絶対性も現象には敵わない。
だから、間違った理論やコードはあり得る。しかし間違った現象は形容矛盾であり存在しない。
コードの間違いはコンパイラやテストによって明らかになる。
しかしこれも完全に明らかになるのかといったらノーだ。しかし手段はある。
問題は理論の方だ。このフィルタリングが難しい。
間違ったコードを書かせる理論は誤りである。
またコードの理解を得られない理論も誤りである。
このようにある理論が誤っている、有効性がないということは証明できる。
しかし、ある理論が正しいという証明はできない。
ある理論が正しい可能性が高いということまでしか言えない。
そしてそれは正しい理論は唯一であるという制限を課していない。

この理論の層、これを概念層と呼んでいるが、この層を考えることはプログラミングのマイナーな楽しみだと思う。最もこれは私の癖のようなものなのだが。

| | コメント (0)

2008年3月27日 (木)

状態論と生成論

今日はちょっと哲学的な話を。
オブジェクト指向の肝はオブジェクトという概念であり、オブジェクトという概念の肝はオブジェクト=状態を持つ存在、ということだ。

だからオブジェクト指向を論じるということは究極的には状態の切り出し、制御、分類を論じることになる。

一方、哲学的には別の立場が存在し得る。
それが生成論の立場だ。

生成とは、何も無いところから存在が出現することを意味する。
この生成という概念によっても、実は状態と同じような表現を持つことが出来る。

たとえば、信号機。赤、黄、青の3つが並んでいる。
これは実は生成論に近い構造だ。(それぞれが明滅という状態を持つので純粋な生成ではないが)
しかしたとえば、一つのランプが3つの色に光るという装置も考えられる。
これは一つの存在の状態が変わることで表現している。
これは状態論の装置と言えるだろう。

抽象的に言えば、ある表現を、
その表現の種類分生成すればよいという立場(生成論)と、
その表現の種類分状態を変化させればよいという立場(状態論)がある。

そしてプログラミング言語でいうと、C言語の系列に属する言語は状態論であり、Lisp言語の系列に属する言語は生成論であるといえる。(もっともこれは付け焼刃の知識だが)

関数型言語において「副作用が無い」という意味は、状態を気にしなくてよい(生成すればよい)という意味だと思う。

しかし考えてみれば、この2つの立場は実は両立し得る。
状態で表現しても、生成で表現しても、その両方が可能ならばケースによって使い分ければいいのである。

オブジェクト指向(状態論)と関数型言語(生成論)は、確かに言語としては大きく分かれているのだが、その両方の性質を持った言語は理論上も可能だと感じる。

どちらが良いのか悪いのか、という議論は平行線のままだと思う。
両方共に有用だからだ。
だから、両方を備えるのが理想的な言語なのだと思う。

オブジェクト指向の次に目覚めるのは、関数指向なのだろうか。
そこでは生成という概念がキーとなるだろう。
オブジェクト指向において状態という概念がキーとなったように。

| | コメント (1)

2008年3月 9日 (日)

求められる技術の違い

1.資格を取るための勉強と、
2.プロジェクトをまわすための勉強と、
3.プロダクトを作るための勉強

は全く異なっているということを知った。
これらの共通部分はあるにはあるがかなり小さいものだろう。
どれに比重を取るのかというのがまず最初に来る重要な判断箇所だろう。
それによって勉強法から今後のキャリアの方向性までが影響を受ける。

私は今のところ、1と3に比重を置いている。
いや置いてないか。そもそもそんな戦略性は無かったというのが正直なところだ。

1と2はポピュラーなものだが、3の知識と技術についてはまだ一般的にはなっていないのではないかと感じている。

これからは徐々に3にシフトしていこうと考えている。
1はともかく、2に比重を移すことはもう無いだろう。

| | コメント (0)

好奇心を刺激する

今日は私が無意識的に行ってきたある対話の技法を紹介したいと思う。
対話においては、相手を引き込むことが重要だ。
これは交渉事でも同じだと思う。
ではどうすれば相手のひきつけることが出来るか。

まずはじめに断っておくと、この場合の引き込む、引き付ける、とは明確な意味がある。
それは、
・相手が自分の話に集中して聞き、
・話が終わると質問を相手が自分に投げる、
という流れをもって「引き込んでいる」とする。

さて、上記のようなことが起きる限り、その相手は自分の話に引き込まれていると言っていい。
そして私は無意識的にそのようなことが起きるように話していることに気づいた。
もったいぶってごめん。ここまでは前振りだ。

ではずばりそのテクニックとはというと、
・好奇心の刺激
・謎の提示
の2点である。

これだけだと抽象的でわかりにくいだろうから噛み砕く。
好奇心の刺激とは、具体的には相手が関心を持っていたり、人間がそもそも好奇心を抱きやすい話をすることである。重要な情報、誰も知らないけど重要な事実、画期的な話、などは好奇心を刺激する。
好奇心を刺激する話は色々ある。そしてこれを小出しにすることで相手を引き込むことが出来る。

次に、謎の提示である。
話をする中で、重要な箇所は謎のまま伏せておくのである。
そして、その部分を相手に質問する。
たとえば、
「Googleは現在WEBの検索を支配しているが、実はそこには技術的な理由がある」
「その技術的な理由があるからこそ他社が絶対に勝てない構造になっている」
「さて、その技術的な理由だけど、君は何だと思う?」
という感じだ。
こうすると、相手は謎の提示に対して答えるだろう。
そして、それが正解でも不正解でも構わない。
要はこちらの質問に対して相手が真剣に考えたということが大事なのである。
そして真剣に考えさせるためには、重大な謎を提示する必要がある。
その謎が真剣に考えるに値すると相手が感じるからこそ相手は真剣に考える。

だから、「好奇心の刺激」と「謎の提示」は2つで1セットだ。

もちろん、このように話をするためには普段からネタを仕込んでおかなくてはならない。
このテクニックはネタがあることが前提となっている。
ただしネタがあったとしても、その話し方によって相手を引き込むことが出来るかどうかは変わる。

最初から好奇心を刺激せずに凡庸に謎も提示せずに話すことは可能だ。

このテクニックはあれだ、TVが良く使うテクニックである、CM前に次の展開を隠す、
というやつだ。あれも同じで、人間の好奇心を刺激し、次の展開はどうなるのか、という謎を提示している。

好奇心を刺激する話を小出しにして、謎を提示していると、相手から質問が来るだろう。
自分から謎の部分をクローズアップして質問してもよい。

私はずいぶん以前から対話におけるテクニックを研究しているが、この分野は奥が深い。
このテクニックは最近私が意識化に成功した例の一つである。

| | コメント (0)

2008年3月 8日 (土)

ネットワークと互換性

JavaScriptは今後もネットワーク上で使用される限りにおいて、その互換性が保証される。
もちろん、ブラウザによって多少の差異はあるだろうが、基本的には保証される。
Flashも同じだ。HTMLもXMLも同じだろう。Javaもそういえる。

これらに共通しているのは、それらのコードがネットワーク上で流通しているという点である。Javaはアプレットのみであるが。
これらがネットワーク上で流通しているがゆえに、どこかの会社や団体が勝手に仕様を変更しても、それはネットワークの流通性を下げるという弊害によって、否定されてしまうのである。

つまり、ネットワーク性のある言語においては常に「流通性」というバイアスがかかっており、この圧力があるおかげで互換性のない独自規格による独占状態を作り上げるという戦略を阻止しているのである。(このバイアスに堂々と立ち向かったのがマイクロソフトである)(そして現在はGoogleがJavaに対して同じ戦闘を繰り返しているが、これは携帯デバイスではアプレットがないがゆえに流通性が無くなったことの結果であろう)

だから、ある言語がネットワーク性を持っている限り、そしてそのネットワークが活発な生命力を持っている限りにおいて、その言語の互換性は守られるはずだと見ていい、と思う。

逆に、ネットワーク性を持っていない言語(C、C++、Lisp、Ruby、Perl、など)は「流通性を保つ」という圧力が無いが故にその互換性が保証される力が働かない。

CやC++やCommonLispはこれをANCIの仕様によって固定化するという方法で乗り切った。
しかし、それでも各社毎に微妙に実装が異なる部分が存在しており、そしてそれは結果的には許されてしまっている。それらには流通性がないので、そこまで厳しい互換性が要求されないからだ。そういえばSQLもそういう言語の一つだ。

Rubyはどうだろうか。Rubyそのものにはネットワーク性はない。よって過去から将来にわたって互換性を保つという圧力はかなり低いだろう。同じことはPerlやPythonやPHPにもいえる。
しかし、これらは皆ある共通した戦略で対処していることが分かる。
それは、仕様を決めるのを代表的な人物や団体に完全に任せており、他の人物や団体が仕様を定めるのを実質的に禁止していることである。(Ruby=まつもとゆきひろ、Perl=ラリーウォールなど)
こうすることで、その人物や団体が仕様を変えない限り、互換性は保証されることになる。
言い換えれば、仕様を変えられる機会を最小化することによって互換性を出来るだけ維持するという戦略である。

ここまでをまとめてみると、言語の互換性を保つ戦略には大きく3つあることになる。
1.流通性を持たせる
2.中立な団体によって仕様を固定化する
3.限られた人物・団体にのみ仕様化の権限を与える

JavaScriptは、1と2を満たしている例である。
JavaとFlash(ActionScript)は1と3を満たしている。

私個人は1の流通性が結局は一番大きな力になるのではと思っている。
それ以外の戦略は常に破綻してしまう危険性を内包しているように感じる。
思えば自然言語の互換性が保たれているのもそれが流通性を持っているからではないか。

そこで逆に考えてみる。流通性が無くなれば独自の言語は自然に生じる、と。
またこうも考える。ある言語が流通性を持ってしまえばその仕様は自然に守られるようになる、と。

| | コメント (0)

技術をストックするということは

それは究極的には「概念の獲得」と「コードの集積」以外の何物でもないと感じている。

本当の開発者(自分の製品を持っているプログラマ)はきっと自分なりの「概念セット」と「コード群」を持っているに違いない。そしてそれらは彼らの経験から自分で作ったに違いないと思う。なぜならば、それらは自分で作ったものでないと本人にとって使いづらいものになるからだ。

技術をストックすることで初めて明確な生産性の向上が望める。
単に何個ものプロジェクトを経験した、何行のコードを書いてきた、といっても、それらはフローであり、経験であり記憶であるので、ストック化されていない。されていないが故にそれらは生ものであり、時間の経過とともに朽ちてゆく。

単に本を読んでコードを打ち込んで理解する、というだけではこれはまだフローの段階なので、積み重なっていかない。だから記憶ベースの積み重なりとなってしまい、あやふやなもので応用が利かなくなる。
だから本を読んでコードを打ち込んで、さらに使える概念とコードを抽出して保存しておく作業が必要となるのである。そしてここが最も大変でかつ実り多い作業となるのだ。

本やオープンソースのコードは、ある特定の目的のために書かれているのが普通なので、そのままでは部品としては使用できない場合が多い。だから本や既存のソースコードが多くあればいいというものでもないのである。

これらの開発のための道具となる概念セットやコード群は本物の開発者ならば誰もが持っているはずのものであるが、それが表に出てこないのは誰もが自分の努力は無償では他人に渡せないと思っているからだろう。

オープンソースとしてあるソフトウェアでも、それを作る過程で使った道具類は表には出ない。実はそこに最も大切な情報があるのにである。

そしてこのような話がオープンソースの開発者から漏れる事が無いのもまた必然なのである。

| | コメント (1)

2008年3月 6日 (木)

やはり本だね

いやWEBサイトで勉強しようとするんだけど、これがなかなか頭に入らない。
もちろんうまくいくサイトもあるのだが、内容が深くて重要な分野の場合は
なぜかサイトでの勉強というのがうまくいかないと感じる。
そして、やはり本しかないかもと感じている。
思えば、ちゃんとした本で勉強したことってJavaに関してはあっただろうか。
試験勉強のための問題集は別として、無かったんじゃないか。
で、いろいろと自分でコードを書いて実験して体得するような方法を取っていた。
これはおそろしく非効率だが、おそろしく体得できる諸刃の剣だった。
いつまでもこれでいいわけがない。
これはからちゃんとした本で勉強しよう。
本のいいところは、一日にどれだけ進んだのか、全体としてどれだけの量があるのか、
が明確にわかるところだ。そして内容も何重ものスクリーニングを経ている。
それでもgenericsなど5.0の新機能は深く解説した本がないのでサイトに頼ることになるが。
毎日少しずつ」という奥義と本とは相性がいいのである。

| | コメント (0)

百年の言語

数理システムの黒田 寿男が言うように、今後何十年も使われる言語は実装によって仕様が変わってしまうようなものではなくて、変わらない仕様を保証していなければならないという意見は本当にそうだと思う。
Javaしか知らないので言うが、5.0、そして7.0で予定されている言語仕様の大幅な増加と変更は今後何十年というスパンで見たときにはマイナス要因でしかない。
そのような年単位での実験と塗布を繰り返していること自体がJavaに対する信頼性を失わせるのである。
私は密かに陰謀なのではないかと思っている。
Javaは1.4の段階でほぼ完成していた。これは大方の見方だろう。
それなのに5.0で大幅な改変を行った。
そしてそれは今後も続く予定である。
つまり、ベースとなる言語がころころと変わっているのである。
無論後方互換性は保証されているとしているが、仕様が変わるのだからそんな次元の問題ではない。
これはSUNが商売でやっているから仕方がなく変化させているのではないかと疑ってしまう。
また、より便利にするといいながら、結局はより複雑にすることでその分野の主導権を握り続けたいのではないだろうか。

いま心配しているのがJavaScriptだ。
新しい仕様を策定中らしい。大幅に変わるようだ。
なぜ変えるのだろう。JavaScriptはもう十分に完成された言語なのに。
これも陰謀ではないかと疑う。きっとどこかが主導権を握り続けたいのだろう。
だからAjaxなどがでてJavaScriptの技術がコモディティとなってしまうちょうどこの時期に新しい仕様を策定しているのではないか。

Javaが数年の単位で仕様を追加・変更するということは開発者に対する攻撃である。
Javaはおそらくはこのようにして死んでいくのだろう。

そこでじゃあ仕様が安定している言語はとなるとこれが黒田さんのいうように極端に少なくなる。C、C++、CommonLisp、COLOL、FORTLAN、など非常に少ない。
JavaScriptはその非常に少ない例の一つだった。それはECMAが策定した仕様だった。
しかし、そのJavaScriptもどうやら自殺を遂げようとしている。
変わらないことが価値であり、重要なことなのに、変わることでまた多くの人から言語を引き剥がしてしまう。きっと言語をマスターする人間が多くなると困るトップ階層が存在するのだろう。

もし、全ての言語が仕様がなく、数年単位でころころ変わるようになったらどうなるのだろう。そこにおいては学習は意味があることだろうか。
そこにおいて意味があるのはもう概念そのものしかないのではないか。
だから私はそのような事態に対応したいがために今、概念層を追及しているのである。

| | コメント (0)

2008年2月16日 (土)

予想外によかった

新しく勝ったマーブルマウスが予想外に良かった。

Logicool マーブルマウス ST-45UPi Logicool マーブルマウス ST-45UPi

販売元:ロジクール
発売日:2002/06/28
Amazon.co.jpで詳細を確認する

トラックボールの中では一番安い部類のものだが、しかし。
肝心のホイールクリックと画面スクロールの機能を2つのボタンに割り当てることが出来たのがなんといっても大きい。
全部で4つのボタンが付いている。
2つは右と左のクリックとして必須だから、残り2つをどう設定するかが肝となる。
そして、意外にもマウスドライバが良く出来ていた。
結構な数の機能の種類から選べるようになっていた。
そして、その中から、中央ボタン(ホイールクリック)とユニバーサルスクロールをそれぞれに割り当てた。これが大当たり。
現在のタブブラウザではホイールクリックを酷使するのは常識だろう。
それによって別のタブで開くことができるからだ。
しかし、最近のマウスではこの肝心のホイールクリックの感触が良くないものがほとんどだ。
そして、スクロールホイールも酷使するが、これもチープな感触のものが多い。
しかし、マーブルマウスのボタンにホイールクリックとスクロールを割り当てることにより、非常に良好な感触を得られるようになった。
まず、ホイールクリックが独立したボタンになったのが便利だ。
ホイールをクリックするよりはるかに楽である。
そして、スクロール。
マーブルでのスクロールは、ボタンを押して、ボールを動かすことでスクロールする。
つまり、あのスクロールの音、ガラガラ音が無くなり、全くの無音となる。
そして微妙な調整はより楽になった。
スクロールとちがって連続移動なので、調整が繊細に出来る。
期待していなかったが、実によくできた子であった。

| | コメント (0)

2008年2月14日 (木)

モデリング言語の分類

モデリング言語として有望なのは、3つに集約されると見ている。

それは、DFD(データフローダイアグラム)、UML(クラス図)、ER図、である。

この3つの技法は、それぞれが同じ対象を記述できるという点で独立している。

そしてこの3つの関係性が未だに謎なのである。

それを図にしてみた。

Model_lang_2

DFD(処理の流れ)、UML(クラスとその関係)、ER図(集合とその関係)、それぞれが独自の有効性を持っている。 

この3つを並行して使うことで十全な効力を発揮するのではないか。

どれが欠けてもうまくいかない気がする。

| | コメント (0)

オブジェクトと集合の概念

ちょっと気になっているのが、オブジェクトと集合の概念の関係だ。

JavaなどのOO言語におけるObjectと、RDBにおけるテーブルの関係について考えていた。

結論としては、オブジェクトも集合もそれぞれ、「状態」と「集合」の概念を服有しているというものだった。

ここらへんを言葉にすると回りくどいので図にしてみた。

Shuugou_image_7

  Object_image_2

| | コメント (0)

2008年2月13日 (水)

習慣化の技術

1.習慣の内部に組み込む
2.習慣に後付けする
3.習慣に前付けする
4.新たな習慣を追加する
5.新たな行為に複数の意味づけをする

ある行為を長続きさせたいとき、それを習慣化してしまうのが最も効率が良い。
これを習慣化の技術とでも呼ぼう。
そして、習慣化の技術には大きく分けて2つの方法がある。
1つは既存の習慣に組み込んでしまう方法で、もう一つは新たな習慣を加える方法だ。
最も効率が良いのは、既存の習慣に組み込んでしまう方法である。

冒頭に挙げた、1から3は既存の習慣に組み込む、付け加える方法であり、
4、5は新たな習慣を加える方法である。

たとえば、毎日ウォーキングをしたいとしよう。
それを犬の散歩とあわせて行うようにする。
これは犬の散歩という既存の習慣にウォーキングという新たな習慣を組み込んだ例である。

たとえば、日常的に飲まなければならない薬があったとする。
多くの人はそれを食後か食前に飲むだろう。
これは食事という習慣の前後に新たな習慣を付け加えた例である。

既存の習慣を利用することで、意識的な努力を少なくして習慣化を容易にする。

しかし、既存の習慣に組み込む、付け加えるのが難しい行為もある。
たとえば、英語の勉強を毎日行いたいとしよう。
それを意識的に毎日行うのは非常に疲れるので、無意識的な行動である習慣にしたい。
しかし、既存の習慣を利用して英語の勉強の習慣をつけるのは難しい。
既存の習慣でそれに利用できるような習慣がないからだ。
このような場合は、仕方が無いので新たに習慣を付け加えるしかない。
自分の生活に新たな習慣を加えるのである。

さて、全く新しい習慣を付け加えるのだから、それには意識的な努力が必要となる。
このような習慣的な努力が続けるのが最も難しい努力である。
そして往々にして高い目標を達成するためにはこの種の努力・習慣化が必要となる。

で、そのような場合にどうすればよいのかを考えてみた。
そして得た結論は、一つの行為に複数の意味を持たせる、というものだった。

これはどういうことかというと、たとえば、英語の勉強ならば、それに複数の意味づけを行うのである。
たとえば、TOEICでの高得点の取得、外国旅行での会話、英語圏の人とのEmail、英字新聞を読むこと、外資系企業への転職、英語のBlogの開設、などの複数の目的を持たせるようにする。
すると、その行為(英語の勉強)に対する「お得感」が高まって、その行為への「投資欲」が沸いてくるのである

これは思うに、複数の意味をもたせることによって、その努力というリスクヘッジをしているのだとおもう。だから努力が軽くなるのである。
もし、たった一つの目的のための努力だった場合、その努力の成果が実らなければ、その努力は無駄になってしまう。故にそのような努力には潜在的なリスクが生じている
そのようなリスクを伴う努力を要するが故にその努力を放棄してしまう例というは実は多い。

そして、そのような「努力のリスク」を減らす戦略となるのが、「行為に対する複数の意味づけ」なのである。
これを「行為の多目的化戦略」とでも呼ぼうか。
ある行為をシングルな目標のための高リスクな行為から、多目的な低リスクな行為へと変換するのである。ここにおいて必要とされるのは、ある行為に対して、特にその行為が高い労力・努力を必要とする行為であった場合に、その行為の目的を複数化する戦略である。

冒頭の分類に戻ると、4と5はワンセットになっていることになる。

新たな習慣を得たい場合は、

1.既存の習慣に組み込む・付け加える
2.新たに複数の意味を持つ行為を習慣化する

という2つの大まかな戦略があるのである。

| | コメント (0)

2008年2月11日 (月)

本当のプロジェクトはオープンソースのプロジェクトだろう

そして、それらオープンソースのプロジェクトにおいて、SEという職種が存在していないこと、PGのみで構成されていることはよくよく考えてみる必要がある。
SEというポジションが何を意味しているのかを。

| | コメント (0)

プログラマとディベロッパー

悪い意味でのプログラマとはプロジェクトの一部のコードを書く人。
これはSEの下位ランクの職業ポジションとされる。
本当はSEよりも重要なポジションなのだが、SEの方が偉いとしないと多くの中高年が失業してしまう革命がおきてしまうため、ここは譲れない一線となっている。
(その意味で、中高年のSE層が居なくなればSEの方が偉いんだ論はなくなるだろう)

ディベロッパーとは単独、または複数人のPGで、ソフトウェアの製品を製造して流通・販売する人をいう。
プログラマと違うのは、彼らがシステムや製品の全体的な技術に通じていることと、それら作成したソフトウェア製品の所有権を持っていることである。

裕福になれる可能性があるのは、一部の高級PGを除くと、このディベロッパーたちである。
なぜならば、彼らは技術だけではなく、製品というものを持っているからである。
したがって、自分が働かなくても、製品が稼いでくれる構造を持つことが出来る。
これが収益構造の大きな違いとなって現れる。

どんなに技術があっても、製品を持っているかいないかは大きな分岐点となる。

所詮、技術はフローなのである。流れ行くものであり、消え去るものであり、属人的なものである。
最新の技術が常に出るから最高の技術を維持するのが難しい。
コーディングが終わったあとは技術は残らない。技術が発揮されるのはあくまでもコーディングの過程においてのみである。だからそれは時間的に消え去ってしまう。
技術は属人的であり、ある上級者の技術をそのまま他人にコピーして移譲できるものではない。だから技術を売りにする限り、その人自身が働かなくてはならなくなり、そしてその人自身は常に一人なのだから、生産性も限度がある。故に収入は頭打ちになる。

製品はストックである。そしてソフトウェアはコピー可能なので、製品に価値があれば、それをコピーすることで価値をどんどん増やすことが出来る。
ただし、製品を作るのには技術が要る。
技術というフローをストックの形に変えたものが製品である。
そしてこのストックに変えた瞬間からそれらが富を生み出すようになる。

技術は大切だが、フローを売りにするというのは、あまり効率が良くない。
価値あるフローをストックに変えることで富が生み出される。

たとえば、演劇や舞台を実演するだけでなく、それらをDVDというストックに変えて販売する。
これは音楽にもいえる。いろいろなものにいえる。

どうしてもストックにできないフローも存在する。
たとえば、外科医の手術の技術や、床屋や美容院の技術、などなど。
それらはそれで代替不可能な価値として、価値が保証されることになる。
ただしそれらは個人技であり、経験の積み重ねの世界なので才能がものをいう。

というわけで、PGとして生きていくのか、DPとして生きていくのか。
DP(あまり語感が良くないな)となるには、PGの過程が必要で、技術をストックしておく必要がある。

| | コメント (0)

2008年2月 3日 (日)

外資系・金融系ITシステム・コンサルタント

これ最強(w)

| | コメント (0)

2008年1月30日 (水)

genericsとアノテーションによってJavaのプログラミングパラダイムは変化したのである

genericsとアノテーションを利用するプログラミングによってJavaのプログラミングパラダイムは一変する。
今までのOO的なプログラミングのパラダイムからは1つ段階が上がる別のパラダイムが開始されたのである。
genericsとアノテーションは単なるAPIの追加でも便利機能の追加でもなく、Javaのパラダイム変化に等しい衝撃を持っている。

たしかにgenericsもアノテーションも一般的な用途からすると必要性は薄い。
しかし読めるようにしておくことは必要だろう。

そのような意味で Java5.0 の登場はやはり革命だったのかもしれない。

以前の記事(やはりgenericsは失敗だったか)でgenericsが失敗だったと断じたが、それでも無意識の領域ではやはり革命的な変化であり、Javaプログラミングを一新する良い意味での革命的な変化だったのかもしれないと後になって回顧することになるのではないかという予感が私の中にはある。

| | コメント (0)

GUIを持たない言語でも、テキストファイルを使用すれば擬似GUIはできるのかもと思った。

要するに、テキストファイルを標準の入出力とすることで、簡易的なUIを実現する。

| | コメント (0)

2008年1月24日 (木)

プロジェクトにおける理想的なプログラマとは

技術を保持しているのはもちろん、ツールを作ることが出来るかが最大の分岐点だと思う。ツールを作ってしまうことで業務の効率化を勝手に進めてしまう。
これがプロジェクトにおけるプログラマの正しい姿だと思う。
その意味で、ツールを作れない言語のプログラマは辛いだろう。
アセンブラやCやCOBOLとか。

VBAはツールを作るのに最も適している。
後はやはりJavaかということになる。
状態を持たなくてもいいのならば、そしてローカル資源にアクセスしなくてもいいのならば、JavaScriptでもいい。
シェルスクリプトでもいいが、GUIが使えないので使用範囲は狭いだろう。

勝手にツールを作ってしまう(ツールを作ることが出来る)プログラマは少ないのではないか。
一口にツールというが、そのレベルは様々で、スクリプト程度のものから、アプリケーションに近いものまである。
アプリケーションに近いレベルのツールを作れるプログラマが居たのならば、それも数人いるだけでもプロジェクトの生産性は段違いになるだろう。

ではなぜそのようなプログラマは少ないのか。
それは、そのようなツールを作れるようになるまでの技術の蓄積に時間と労力がかかるからである。

しかしプロジェクトの一員として参加する以上、目指すのはツールを作る(作れる)プログラマである。
ツールを作って作業を自動化することこそ、プログラミングの醍醐味ではないか。

というわけで、目下VBAとJavaでツールを作る計画をしているという次第。

| | コメント (0)

2008年1月23日 (水)

職場ではエクセルのVBAでいろいろなツールを組んでいるが

エクセルとVBAのないMACOSやLINUXでは生産性は激減するだろうなと思う。
エクセルとVBAがないとマジつらいよ。
シェルスクリプトでは代わりにならないだろう。
なにしろGUIが使えないのが痛い。
RubyにしてもPerlにしてもGUIが使えないのが痛すぎる。
まあMACOSにしてもLINUXにしてもVBAと同じようなスクリプトが存在しているのかもしれないが、よくわからない。

実はひそかに思っているのだが、Ruby、Perl、Lisp、C、とかここらへんの有名どころの言語でGUIが使えないことって結構タブー?
正直言ってGUIが使えないとツールとか作るとき結構きついんだよね。
まさかとは思うけど、エスケープシーケンスを使ってCUI画面に状態を持たせる??
ま、それも味があって好きだけど、汎用性に欠けるし、柔軟性もない。

もちろん、それらの言語でもTcl/Tkを使ってGUIが構築できるらしいが、それも言語とは別個のものなので、時間的・環境的な安定性に欠ける。

GUIが使えないってかなり本質的な制限だと思う。

GUIにこだわる=子供っぽい=Windowsユーザー
CUIで十分(笑)=大人=UNIXユーザー

というような潜在的な認識があるような文章を見かけるときがある。
これって正直、かなりの強がり&強迫観念&触れちゃいけないところに触れられた、感が強い。

そんな奴らは大好きなUNIXの世界でずっとCUIの世界に住み続けて欲しい。
そしていつの日か、GUIを超えるであろう、TUI(テキストユーザーインターフェース)を確立して欲しい。エスケープシーケンスの利用法が鍵を握るだろう。

| | コメント (0)

2008年1月19日 (土)

OOとRDBの違い

OO:newする
 --> ひとつのクラスから複数の対象を生成する。

RDB:insertする
 --> 対象とレコードは1対1に対応している。

これがOOとRDBの明快な違い。

OOでは複数の対象があっても、それは一つのクラスから生成される。
よって、クラスと対象が一対多の関係にある。

RDBでは対象はそのままで存在している。
よって対象とレコードは常に1対1の関係にある。

OOは状態の変化によって複数の存在を表現できる。

RDBは複数の存在の集合で存在を表現する。

OOは存在の状態変化

RDBは存在の集合

これが状態志向か集合志向かのアプローチの違いだ。

| | コメント (0)

2008年1月14日 (月)

やはりgenericsは失敗だったか

そうか。やはりgenericsの機能追加は失敗だったか。
以下のサイトで言われているのでやはりと確信してしまった。

http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
私の主張はシンプルです。Javaは極めて有効に機能していますが、それは80対20の法則にあたっているからです。私の考えでは、今までで最もわかりや すい80対20の技術の勝利一つです。次の20%を埋めようという試みは、たいてい害の無いものでした。ジェネリクスまでは。ジェネリクスは大失敗でし た。 Javaの習得や理解は難しくなりましたが、それを避けることはできないのです。

http://d.hatena.ne.jp/Kazzz/20071225/p1
ワイルドカードは、JavaのGenericsのワイルドカード(?記号)のことを指してるのだと思います。

 <T extends Object & Comparable<? super T>>
 <V extends Wrapper<? extends Comparable<T>>>

これがとんでもない複雑さを招いてるのは、Java SE 5.0以降のAPI Docを見ても一目瞭然ですよね。
こういう複雑さ(FAQが427ページw)を招く機能が「The Feel of Java」をおかしくしてるとお怒りなんだと思います。

そうだよなあ。使いこなせないもん。普通の人には。あの複雑さはね。
あとAutoBoxingも失敗のようだ。

SJC-Pの勉強をしていて一番きつかったのがgenericsだ。
そしてAutoBoxingもひどかった。
組み合わせることでいくらでも複雑なケースが出来上がるが、その解読の負担は全てプログラマに降りかかる。
これでintとIntegerの変換についてプログラマがつねに脳内キャストを背負わされることになった。

enumも使わないだろう。まあ使っても良いが。
可変長引数は?これは普通に便利そう。いいと思う。
拡張for文は?これは間違いなく便利。これは成功。
アノテーションは?まだ勉強してないので未知数だが、悪い噂は聞かない。

結論。
Java5の新機能で以下の機能は極力使わないようにする。
・generics
・AutoBoxing

以下の新機能は使っても良い。
・enum
・可変長引数
・拡張for文
・アノテーション

genericsとAutoBoxingが致命的なのは、それが言語のほぼ全ての面に影響してしまう点である。しかも非常に微妙な脳内デバッグをプログラマに強いる。しかもAutoBoxingに至っては自動的に機能してしまい、OFFにはできない。そのため基本型とラッパー型の取り扱いに細心の注意が必要になってしまった。
ただし、いちいちintをIntegerに変換しなくてもよくなったのは便利になったが、しかしそれだけだ。それにしてはあまりにリスクが高い。

しかも最悪なことにこの変化は負荷逆だという点だ。
APIならば非推奨のマークをつけることで使用を抑制できる。
JavaVMのバグならば修正すればよい。
しかし言語の仕様に問題が含まれてしまった場合は、もうアウトだ。
あと残された道は仕様を変更して互換性を捨て去るか、仕様を受け入れて人間の側の処理能力を上げるしかなくなる。後者の道をたどったのがC++である。

おそらく将来、JavaもC++のようになるだろう。
そして、おそらく将来JavaのようにVMで動くもっと簡単な言語が出てくるだろう。

このまま複雑化が進めば、Javaは自殺することになるだろう。

| | コメント (0) | トラックバック (0)

2008年1月13日 (日)

そうか Handler という概念がコントロール層に該当するのか

だから Handler という名前のついたクラスにはフィールドがない。
これはオブジェクトを制御するコントロール層なので状態を持たないからだ。
もしそれが状態を持ってしまった場合、それはオブジェクトということになってしまう。

| | コメント (0)

2008年1月 7日 (月)

いまJ2EEの環境を作っている

SJC-WC の勉強のための実験環境を構築中。
Java6、Tomcat6、MySQL で作成している。
JDBC接続の勉強なども並行して実行中。

途中、Java6についてきたPure Java データベース Derby の使用法や、
JDBC接続の実験もやってみた。
Derby は確かにインストールの手間も無く設定も簡単なのだが、
ネット上では性能と機能の面で評判が悪い。
まだ本格的に使用する対象とはなっていないようだ。

また他にも DB2 ver9 Express の無料版や、Oracle 10g XE という無料のデータベースへのJDBC接続も試してみた。
JDBC接続のコーディング自体はデータベースによっては変わらないので便利なのだが、データベースの使用法はそれぞれの製品で全く異なるのでそこが面倒。

Pure Java のデータベースでは、H2 Database が良いらしい。
確かに、実行ファイルが2MB以下というのは凄い。
最低限のGUI管理ツールも付いてくる。
不思議に話題にならないが、面倒なインストールもなく、構成もシンプルなので学習や研修にはかなり便利だと思う。DB2やOracleのように馬鹿のようにメモリを食わないし。

J2EEの何が面倒くさいって、結局JSP、Servlet以外にもTomcatやデータベースなどの環境を勉強しなくてはならないところだろう。JavaだけですんだSJC-Pのときとは違って、JSP、Servlet、Tomcat、データベース、HTML、HTTP、などの総合的な技術の勉強が必要となる。
少なくとも以下の技術について勉強が必要だ。
WEBアプリって奴は。。
・JSP
・Servlet
・Tomcat
・データベース
・HTML
・HTTP
・JavaScript

さらに加えるならば、
・Applet
・CSS
・FLASH(ActionScript)
・AJAX(JavaScript)

もあるだろう。
これらの勉強のためには絶対にそのための実験環境が必要となる。
で、それを作成しているのだが、Ecilpseのプラグインやデータベースのインストールなど、その下準備がまた面倒くさいんだなこれが。

しかし逆に言うと、その環境さえできてしまえば上記の総合的な技術の勉強が可能となるわけで。
環境構築の能力とセンスがかなり問われるとはね。
J2EEの勉強はしんどい。

| | コメント (0)

2007年12月23日 (日)

いやはやVBAよ

うーむ。以前紹介した進捗シートをVBAで武装中。
なかなかうまくいっている。
作業のステータスを変えると行の色が自動的に変わって、自動で更新日が入る。
ただこれだけなのだが、かなり便利だ。
色で分けることで一目で現在の作業状況が分かるようになった。

今回機会あってVBAとは何かをいろいろと調べてみた。
すると次のことがわかった。
・VBE(標準の開発環境)から、VBA、VBS、VB、のオブジェクトにアクセス可能
・つまり、VBAとは、VBA、VBS、VB の3つの言語をカバーする言語である
・市販のVBA本では、VBAの分野のみの解説で終始しており、VBSとVBの機能には触れない
・VBEのヘルプ機能ははVBについてのヘルプとなっている

このうち大きかったのが、3番目のことだ。市販のVBA本では、VBAの範囲しか扱わないため、VBSやVBの便利なオブジェクトについての解説がない。しかもその触れていないということについても触れないため、ユーザーはそれがVBAの限界だと思ってしまうという罠。

今度は作業状況をVBAで分析してグラフやチャートの形で描き出すことを計画している。
タイマー機能による警告も一応はできることを確認した。

VBAに限らないのだが、下記のようなポケットリファレンスのような本は現場では必携の本だね。非常に重宝している。業務中に読んでいても調べ物をしているように見えるのもポイントだ。

Excel VBAポケットリファレンス―Excel97/2000/2002/2003対応 (Pocket reference) Book Excel VBAポケットリファレンス―Excel97/2000/2002/2003対応 (Pocket reference)

著者:前田 智美
販売元:技術評論社
Amazon.co.jpで詳細を確認する

| | コメント (1)

2007年12月12日 (水)

1人プロジェクト

ある計画を立てて、毎日少しずつ実行していくのは、1人でプロジェクトを立ち上げて進めていくのと同じである。
そう。これは実はプロジェクトマネージメントなのである。
自分で自分を管理する。計画を立てて戦略を練り、毎日少しずつ実行していく。
これがプロジェクトでなくてなんだろうか。
そういう意味で言うならば、大概の人はプロジェクトマネージメントを意識的にしろ無意識的にしろしていることになる。
そういう意味で、私も複数のプロジェクトを平行で動かしている。
もう何年も凍結状態のプロジェクトもある。いやそればかりだ。
しかしそれらを「プロジェクト」として再認識することによって、改めて何をやるべきかがわかるのである。そしてそれらをプロジェクトとして認識するというのは素晴らしいことでもある。それらプロジェクトの軌跡を記録して残しておくこと。これ自体が自分にとっての宝物となる。まずは自分の持っているプロジェクトに名前をつけるところからはじめようか。

| | コメント (0)

2007年11月26日 (月)

アプリケーションを作るには

アプリケーションを作るには、実は3つのものが必要である。
1.概念群
2.検証コード
3.サンプルコード

この3つが充実してはじめてアプリケーションを作成する準備が整う。
1,2,3の順に難しくなっている。
この3つを集積していくのだが、これが大変なのだ。
しかし、この3つの集積は間違いなく、生産性に直結する。
だから、手を抜くことは出来ない。しかし短期的に一気にこなすこともできない。
だから長期的にこつこつと増やしていくことになる。
ここでも精神力が問われることになる。
この3つが充実すればするほどに生産性はそれに直線的に比例して上がる。
だから、プログラミングの勉強法は単純なのだ。
この3つをひたすら追求・集積・洗練していけばいい。

サンプルコードは外部から集めた方が効率がいい。しかし、検証コードと概念だけは自分で作っていくしかない。そもそもそれらがなければサンプルコードの理解も進まない。

本当の意味でポータブルな知識は概念である。
だから、概念層が一番重要になる。
しかしこの分野はやわらかく、曖昧で、実証性がなく、正解がない。
だから、ある概念がどこまで有効なのかの判別が難しい。
あるときになって破綻するかもしれない。
オブジェクト指向だっていつかは破綻するだろう。

どこかに魔法の概念があって、それにしたがって文法もコードも容易に理解できるようになるのでは、と思っていた時期があった。しかし違った。これらは3つともに必要なのだ。
あとは如何にしてこれら3つを集積・洗練していくのかという方法論の問題となる。

おそらく優秀な人や要領の良い人は、サンプルコードから文法や概念をつかむことができるのだろう。だから彼らはサンプルを見るだけでどんどん開発が出来るようになる。

しかし私はそれほどではない。だからこの3つを地道に集積・洗練していくだけだ。

| | コメント (0)

2007年11月20日 (火)

VBAはすごい

なにが凄いって、本格的な言語だということ。
それも汎用的な言語だ。
VBAからVBSのオブジェクトとWinAPIにアクセスできる。
ということは、Windowsのアプリケーションに近いレベルのものが作成できる。
これは凄いことだ。こんなに凄い言語が単なるマクロなんて呼ばれて良い訳ない。
多くのVBAの本では、VBSのオブジェクトにアクセスできることも、WinAPIにアクセスできることにも触れていない。しかし、それらが合わさって初めてVBAの凄さがわかるようになる。
VBAだけではEXCELなどの世界に閉じてしまうのだが、先の2つのオブジェクトへのアクセスを持ってVBAは豹変する。
有名な言語でもVBAには勝てないんだ。対抗できるのはJavaくらいじゃないか。
だって、PerlにしてもCにしてもRubyにしてもLispにしてもGUIを持っていないじゃないか。
JavaScriptはGUIを持っているがローカルの資源にアクセスはできない。
それがVBAはGUIをを持っている。そしてアプリケーションのマクロ言語でもある。
これだけでも先の有名な言語たちを負かしてしまっている。それほどのGUIを持っているかどうかの違いは大きい。だから同じくGUIを持っているJavaのみが対抗出来ると言う事になる。しかも、VBAはほとんどの職場で使用できる。Officeにデフォルトで入っているからだ。

VBAで作業の自動化が可能となる。バッチでは無理だ。バッチではファイルの編集ができないので無理だ。バッチで出来ることなんて高が知れている。いや無理をすれば色々出来るのだが、かなりの無理であって言語の使用想定外の無理さが必要となる。

どんなに言語が高性能であってもGUIが使えないのならば、その利便性は大きく劣ってしまう。そのことはDOSとWindowsの違いに等しい。

そりゃあたしかにRubyでもPerlでもGUIは可能だろう。専用の別途GUIシェルとなるソフトをインストールすれば。しかしそんなソフトウェアをインストールできる職場環境なんてこのセキュリティ優先の時代にはもう存在していないのではないか。
そもそも職場のPCに好きなソフトをインストールできる職場は自由というよりはセキュリティに問題がある駄目な職場だろう。
だから、デフォルトに存在していない、あるいは広く広まっていない、マイナーなソフトに頼るようなGUIじゃあ駄目なんだ。
だからRubyやPerlのGUIは存在はしているけど、事実上使えない状態なんだ。

RubyがVMの環境に移行しようとしているのも大きくはこのようなことが原因だろう。
VMの恩絵によってJavaのように標準でGUIが使えるようになることが大きいのだ。
だから彼らはVMにRubyを移すことに必死だ。そしてそれは正しいだろう。

何はともあれVBAだ。VBAができるようなれば世界は大きく広がる。
VBAは力なり。武器なり。とてつもなく実用的な武器だ。

| | コメント (1)

2007年10月27日 (土)

やはり、Javaで標準でGUIが使えるというのは大きい。

なぜならば、これによって状態の表示が可能になるからだ。
これが大きい。
UNIXの場合はエスケープシーケンスによってコマンドラインでも
状態を持たせることが可能だということを知った。
しかし、エスケープシーケンスはハードウェア依存であり、
ポータビリティーに欠けるという欠点があることも知った。
そんな訳でJavaはやはり使える言語である。ということ。

ただし、Javaにも欠点がある。それはコンパイルが必要であるということ。
classファイルをそのまま他の環境に持っていっても動作の保障はない
というのが大きい。その場合はソースをコンパイルする必要があるのだ。
その意味でスクリプト言語は真の意味でポータビリティーを実現している。

ただし、Rubyにしてもそうだが、GUIが使えないので状態を持ったUI
作ることができないのが痛い。
無論、TCL/TKを使えばGUIも可能なことは知っているが、それだと統一性が
失われてしまうのである。

やはり、HTMLのGUIが使えないというのが痛い。
これがローカルのGUIとして使えればJavaの優位性は吹き飛ぶのだが。

JavaScriptは確かに可搬性もあり文法も良く有望な言語であるが、
ローカルPCの資源にアクセスできないという致命的な欠点を抱えている。
このゆえにJavaScriptには本質的な限界が存在している。

結局、本当の意味で職場でツールを作るのに使えるのは以下の言語だ。
・Java
・シェルスクリプト
・VBA

ただこの3つのみがそれぞれ有効な技術となっている。
Rubyは先ほどいったようにGUIがないという本質的な欠点のためにJavaに
その座を譲ってしまっている。

思えば、Javaがそれ自身のうちにGUIとスレッドを取り込めたのは、
JavaがVM上で動いているからだろう。
ここにおいてVMの有効性が存分に発揮されているのである。

シェルスクリプトの欠点は、ファイル単位の取り扱いならば優秀なのだが、
ファイル内の編集、テキストの処理となると一気に能力が下がることだ。
このファイル編集の困難とテキスト処理能力の低さによって、バッチで
バッチを生み出す、いわゆるマクロ・ジェネレーティング・マクロ
できなくなってしまっている。
だから、シェルスクリプトにはかなり本質的な限界が存在している。
それは最小粒度がファイルである場合のみ有効な技術となる。

したがって、テキストの編集などはJavaにやらせることになる。
ファイル単位の処理はシェルスクリプトだ。
そしてエクセルの処理はVBAだ。

この3つ以外にたとえばRubyなどが必要だろうか?

| | コメント (0)

2007年10月 3日 (水)

技術は身を守る

技術というのは武器というよりは自分の身を守るものだという感じがする。知識もそうだ。私のような末端のプログラマにとって技術を使って攻めるというよりは技術によって自分の身を守るという感覚のほうが強い。

技術によって作業をスムーズにし、余計な時間や失敗を極小化する。それは決してコミュニケーションによってではない。私が何とか曲がりなりにもやってこれたのはこれだと思う。

技術のレベルは不連続で段階というか壁があると思っている。あるレベルから次のレベルに上がるのは明確な壁があり、その壁を突破しないといけないようになっている。決して連続的に徐々にレベルアップするというものではない。あるとっかかりというか核心をつかむことで一気に上がる。しかし、それまでの間は進歩が感じられない努力が必要となる。これが苦しみだろう。

オブジェクト指向も壁だし、スレッドも壁だし、色々な壁がある。残念ながら私はまだJavaの基本文法の世界の中の壁しか知らない。

| | コメント (0)

2007年10月 1日 (月)

データフロー図はフローチャートの夢を見るか

データフロー図というのがある。フローチャートと似ているが異なり、処理だけではなくデータと処理の流れをセットで図示できる。

以下は試しに作成してみたデータフロー図の例だ。

Dataflow_2

個人的にはとても分かりやすいと感じている。

しかし設計書でもこのような図を見たことが無い。なぜだろうか。たぶんたまたまそのような現場だったのだろう。

この図のいいところはマクロ的な視点もミクロ的な視点も同様の記述法で記述できるという点だ。図の例はマクロ的な視点だが、ミクロ的な視点とはオブジェクトの操作を図示することになる。

不思議なことに、このデータフロー図はUMLに取り込まれていない。Wikiによるとアクティビティ図に取り込まれたというのだが、アクティビティ図をみるとそれはフローチャートのように見える。

私が無意識的に求めていたのはデータフロー図なのかもと感じた。新人時代にこのような図があればどれだけ理解が進んだことだろうか。ソースコードからデータフロー図のような理解に達するのは結構大変なのだ。

データフロー図はなぜメジャーではないのだろう。フローチャートと同じように害悪視されているのだろうか。少なくともフローチャートよりはいいと思うが。個人的にはUMLよりも直感的でいい。データフロー図の記述の中でも特に矢印の意味は曖昧だと感じる。しかし使えればいい。

| | コメント (0)

2007年9月24日 (月)

オープンオブジェクトとクローズオブジェクト

オープンオブジェクトとは、オブジェクトに対してフィールドとメソッドをオブジェクトの生成後に追加・削除できる機能をいう。

クローズオブジェクトとは、生成後はオブジェクトのフィールドとメソッドの追加・削除ができないことをいう。

クローズオブジェクトにおいては、それを生み出すクラスの変更によって異なるオブジェクトを生成する。

オープンオブジェクトの場合はそれを生成するクラスの変更なしに、そのオブジェクトに固有の属性を付与することができる。

Javaはクローズオブジェクトであり、Rubyはオープンオブジェクトである。

それぞれにメリットとデメリットがある。

クローズオブジェクトの場合はオブジェクトの定義はクラスにあるので明確であり、クラスを通してオブジェクトを管理できる。
しかし、新たなオブジェクトが必要な場合、既存のオブジェクトにそれに近いものがあったとしても、新たにそれ専用のクラスを定義しなければならない。
だから似てはいるが微妙に違うオブジェクトが必要になった場合や、途中で突然必要なオブジェクトが生じた場合はクラスを後から定義しなくてはならなくなる。
コンストラクタで対処する手もあるが、それはあらかじめどのようなオブジェクトが必要なのかを全て把握している場合のみ可能である。

オープンオブジェクトの場合は、途中で新たなオブジェクトが必要になった場合でも、既存のオブジェクトにそれに近いものがあれば、そのオブジェクトに新たな属性を追加することでオブジェクトを手に入れることができる。
その代わり、オブジェクトの管理はクラスとは厳密に対応しなくなるため、どのようなオブジェクトなのかがソースを追わなければ分からなくなる危険性がある。
しかしそれさえちゃんと把握していればクラス定義の手間が省けるのである。
しかしオープンオブジェクトの世界ではクラスはオブジェクトの上位概念とはいえなくなってしまっている。クラスはオブジェクトを生み出す1手段に過ぎない。

| | コメント (0)

努力する以前に努力するための環境を整えることの重要性

確かに努力は重要だ。目的を達成するのに必要不可欠な行動だ。
しかし努力をする以前に努力するための環境を整えることも重要だ。
資料が整理されていなかったり、部屋が雑然としていたり、スケジューリングができていなかったり、計画がなかったり、必要な資源の確保がされていなかったら、努力してもそれは非常に効率が悪くなってしまうだろう。
だから、努力する前にそのための環境を整える必要があるのである。
その環境をどう整えたかによって努力の効率はかなり違ってくる。
本当に身近なものからいうと、座る椅子の座り心地だとか、息抜きの方法とか、他の悩み事などの解消とか、使いやすいPC環境とか、健康とか、いろいろだ。
これらを整える。だからかなり忙しくなる。正直言って、環境を整えるほうにエネルギーを使いすぎるのもよくない。しかしこれがうまくいけばすごいことになる。

| | コメント (0)

2007年9月23日 (日)

MacOS + Parallels + Windows2000 という環境

このアイデアはどうだろうか。
MacOSは驚くべきことに、Parallels によってWindwosをアプリケーションとして取り込んでしまったと見ることができる。
Windows2000 + SP4 は最も安定した環境である。
これをMacOS内部に構築してしまうことで必要なときに十分なパフォーマンスでWindowsが使用できる。
実は私はいまこのアイデアを検討している。
これをMacBook上で実現できればかなり便利だろう。
Windowsを仮想化することで管理が楽になるし、MacOSによってVistaの問題から逃げられる。これもVista問題があったからこそ生じた回避策である。
MacOS + Parallels + Windows2000 という環境が桃源郷であり甘かったとなるかもしれないが、しかし試してみたい。ネット上にはすでにレポートもある。特に問題は無いようである。うーむ。
MacOSはまだ「Vista化」していない。
MacOS + Parallels + Windows2000 がどれだけの威力を有するのかはまだ未知数だが、これがはまればVista問題との相乗効果でかなりダメージをマイクロソフトに与えるだろう。この事態は静かに進行していくだろう。

| | コメント (0)

だからといって他のノートPCがいいとはいえない件について

最初、VaioTZを買おうかと思っていた。いいマシンだからだ。
Vaioはカスタマイズを許さないイメージが強かったので敬遠していた。
Thinkpadがあったし。しかし。Vistaは糞だった。
そして、XPのインストールはどうやらできないらしい。
かなりの工夫をすればできるが、当然サポート対象外。
そしてXPプリインストールのモデルも無いときた。
これはThinkpadを除くほぼ全てのメーカーでVistaのみなっているようだ。
あのDellでさえもだ。
Vistaは必要ない。なんで安定しているXPを捨てなければならないのだ。
Vistaモデルのみにすることで、そしてXPのインストールを不可とすることで
Vistaのシェアは強引に増大していく。しかし強引にだ。
OSだけで1GBのメモリが必要なんて狂っている。
というか、Vistaが生まれる必然性が理解できない。
XPの時にはまだ理由があった。2000の完全版という理由が。
しかしVistaにはそのような理由がない。殺し文句が無い。
Vistaはメモリは最低1GB、HDDは最低10GB必要とする。
これによってハードウェアも買い換えなければならなくなった。
馬鹿げている。しかもVistaに移行することによって得られるメリットの説明はない。
いやどのようなメリットがあるのか不明である。仮にあったとしても
それがXPから移行するのに値するものか不明である。
これはかなりまずい状況である。
完全にニーズがないにも関わらず、強引に売ろうとしている。
かなりユーザーを馬鹿に見ている商法である。
ライトユーザーは簡単に騙せるだろう。
しかしちょっとでも経験のあるユーザーは騙せないだろう。
プリインストールだからそのまま使っているというユーザーはいい。
しかし積極的にVistaを買ってインストールする人はいないだろう。
これはXPのときもそうだったが、しかしXPの時は実は2000にはないメリットがあった。
それがデュアルディスプレイ機能の強化だった。私はこのためだけにXPを買った。
Vistaにはそのようなものがない。それでいてリソースを使いまくる。
ついにWindowsはVistaになって死んでしまった。
次期Windowsは軽量化を殺し文句として登場することだろう。

| | コメント (0)

私がThinkPadを裏切ったのではない。ThnkPadが私を裏切ったのだ

X60。期待して買った。それまでのThinkpadへの信頼があったから。
しかし。裏切られた。それも大きく。なにこのパームレストの熱さは。
しかも全体が熱いのではなく、その パームレストの部分のみ熱い。
キーボードの品質がかなり下がった。液晶の品質もかなり下がった。
全体としては丁寧に作られているが、肝心の部分が駄目駄目だ。
せっかく残り少なくなったWindowsXPのマシンとして買ったのに。
本当のThnkpadはやはりT4xとX3xとT5xシリーズで終わったようだ。
しかも分解写真を見て驚いたが、マザーボードにかなり手を抜いている。
安いものを使っている。だから発熱が対処できていない。
ありがとうThnkpad。そしてさようなら。
Thinkpadはもうこれからも復活はないだろう。

幸いにもT42、X31、R50 が手元にある。
これらを限界まで使い続けるしかないようである。

| | コメント (0)

オブジェクトとデータ集合について

オブジェクトは状態を持つもので、データは状態を持たないものだ。
これは私が勝手に決めた定義であって、一般的な定義ではない。
さて、Rubyのように全てをオブジェクトとして解釈するのならば、
データはどのような存在なのかということになる。
Rubyの場合は、数字の 3 にはそれに対応した時間や日付や単位を持ったオブジェクトとなる。この場合、3 は状態をもつオブジェクトというよりは、データの集合のイメージに近い。
Javaの場合は、Calendarクラスのように、西暦をオブジェクトとして扱う。
しかしCalendarクラスも状態を持っているというよりは、西暦データの集合に近い。
西暦というもの自体がオブジェクトというよりはデータの集合といったほうがいい。
西暦が状態を持って変化するということはないからだ。
そしてJavaでは文字や数字などのデータはそのまま基本型としてオブジェクトとは別の存在になっている。
本来、データを全て基本型とするのならば、西暦などもデータの集合として表現されなければならない。しかしJavaではそこは妥協してオブジェクトとして実装している。
データの集合をオブジェクトの生成をもって表現するのである。
データの集合は「集合」であるがゆえに静態的な存在で、生成したり消滅したりするものではないのであるが、しかしオブジェクトによってそれを表現することも可能であるということである。いってみれば、集合の変わりにある1つの存在の状態変化によって表現する戦略である。これがうまくいった場合、データの集合をオブジェクトとして表現できるようになる。これはオブジェクト概念の優秀性を表すのではないか。
逆に、オブジェクトをデータの集合で表すことも出来る。
両者は可換であるが、現在の流れではデータの集合をオブジェクトとして表現するほうがどうやら優勢である。これは人間の経験や思考が内包的に対象を定義するのであって、外延的に対象を把握することが難しい・稀だからであろう。
本来は記憶域が広ければデータの集合で保持している方がコストは安いはずである。
そもそもデータの集合をオブジェクトに変換するコストは人間が担っている。ここは自動化できないのではないか。クラス設計が人間系なのも本質的には同じ理由だろう。
オブジェクトへの変換がうまくいけば情報を圧縮できる。ただしそのオブジェクトはデータの集合と比べるとかなり複雑になる。ここはトレードオフの関係。

| | コメント (0)

純オブジェクトな世界モデルよりもデータ・オブジェクトの折衷モデルのほうがしっくりくることについて

現実世界の経験においては、やはり状態を持たない原子的なデータ的な存在があるとして世界をみている。たとえば、貨幣や記号などはデータであってオブジェクトではない。文字や数字や規格や単位や色などもデータ的な存在である。
それらが不変のデータ的な存在でいるからこそそれらを使用して科学や文明が発達するというイメージがある。
だから全てがオブジェクトであるという世界観はやはりちょっと強引かなという印象がある。その意味でも基本型とオブジェクト型の分類を残したJavaは保守的なのである。

| | コメント (0)

2007年9月17日 (月)

お気に入りのツール?

よく2chなどでプログラマのお気に入りのツールなどの話が出る。しかし私のようないわゆる派遣のプログラマにとっては自分好みのツールなど無縁の話だ。

なぜなら職場のPCにはフリーソフトのインストールは基本は禁止だからだ。したがってフリーのツールの無い状況でどうするかが我々にとって重要な問題となる。

しかしどの職場でもほぼ共通で存在している環境はある。それはJava、Eclipse、MSOffice、秀丸、くらいである。これらだけが安定して使えるツールである。だからこれらを如何にして使いこなすかが重要となる。

もちろん、これはWindows環境を想定してるが、現場によってはUNIX環境が作業環境であるところもあるかもしれない。その場合は別のツールセットとなる。

| | コメント (0)

風呂本、寝る本、電車本、マジ本、トイレ本、食事本

風呂本、寝る本、電車本、マジ本、トイレ本、食事本。

これらはその時々の状況に応じて読む本を分けている私の工夫である。本というのは読みやすい状況というのがある。堅い本でも電車の中なら読みやすいとか、漫画は食事中が読みやすいとか。これはなぜなのかは不明なのだが確かにそういうのはあるのである。

だから私の場合は本を買うとこれはどこで読むべきものかというのをまずは決めることにしている。ちなみにマジ本というのはマジになって机で読む本という意味である。

意外に重要なのは寝る本、つまり寝る前にベッドに入りながら読む本である。これが意外と難しい。これも自分の感覚に聞いてみるしかない。

また困るのがこのどの分類にも属さないような本だ。意外とあるのである。電車本も重要である。通勤時間は貴重な時間の利用なので電車本は常にストックしておきたい。間違っても家で読んでしまっては駄目だ。

| | コメント (0)

技術をプロセスで埋めることは出来ない

コミュニケーションだとか、CMMだとか、PMBOKだとか、プロジェクトマネージメントだとか、いろいろあるけど、これらプロセスの改善策によっては技術の無さを埋めることはできない。

プロセスをどんなに洗練させてもプログラマに技術がなかったらプロジェクトは失敗する。プロセスのみで有効性が発揮されるのは、実は単純作業の集合に対してのみである。そしてコーディングは単純作業ではないのである。

コミュニケーションもそうである。よく技術よりもコミュニケーションが大切と嘯く輩がいる。そういう奴に限って自分はしっかり技術があるから始末が悪い。まるで自分は金持ちなのに貧乏人に対して「大切なのは金じゃない」と言っているようなものである。だからこのような人は信用しないことにしている。

言うのも悲しいのだが、コミュニケーションで技術の無さは埋まらない。どんなにコミュニケーションがあって、コミュニケーションの達人であったとしても、技術がなければ駄目なのである。

その証拠に例えばプログラマ以外の世界で、専門的な技術が必要な世界でコミュニケーションが大切だなんてはしゃいでいる業界があるか?

医者の世界、ハードウェア技術者の世界、料理人の世界、科学者の世界、芸術の世界、デザイナーの世界、etc・・・。これらの世界で「技術よりコミュニケーションが大切だ」といっている業界があるか?ない。理由は不要だろう。一番大切なのは技術だからだ。それらの専門職に特有の技術がなければ、それはその人の存在価値が否定されてしまうのである。技術職とはそういうものである。

こういうと、予想通りの反論が来る。「技術はあって当たり前であり、それに加えてコミュニケーションが大切なんだよ」というあれである。ではなぜ技術が大切だと強調しないのだろう?技術はあって当たり前?でも技術が無いプログラマなんて大勢いる。そもそもなぜ技術があって当たり前なんだろうか。それは決して当たり前ではない。なぜならばプログラマになるのになんらの国家資格や認定試験もないのだから。

コミュニケーションとプロセスを振りかざす奴らは信用しない。プロセスはまだしもコミュニケーションは特にだ。それらはおそらく技術がないことの防御線なのだろう。しかしそれらでは技術は埋まらないのである。

| | コメント (0)

アジャイルやXPはプログラマにとって福音か

福音だと思う。基本的には。何せソースコードベースなので無用なドキュメントが不要なのがいい。そしてプロトタイプを顧客にレビューさせることで無用な手戻りを避けることが出来る。

そして何よりも重要なのは無用な中間管理職がいなくなることだ。雑用がなくなるのもいい。小規模開発万歳。

| | コメント (0)

CFM理論

CFM理論。

何のことは無いクラス、フィールド、メソッドの頭文字を並べただけである。なぜこんなことに理論なんてつけるのか。それは当時の私はこれを発見した当時にそれほどに感動したからだった。

ちょうど2回目の現場でクラス図を作っていた頃である。あるときにふと気がついたのである。それはJavaのコードはどんなに複雑に見えてもクラスとフィールドとメソッドの3つの構成要素しかないではないかということに。これは大きな発見だった。そして感動した。どんな初心者本でもJavaソースの構成要素がこの3つだけで出来ているのだと教えてはくれなかった。しかしクラス図はそれを教えてくれたのである。

それからはソースコードがどんなに複雑に見えてもCFMによって簡略化して見えるようになった。まさに魔法の眼鏡のようなものだった。そしてそれからはこの理論は私にとって極秘の最極秘事項となった。

実はCFMという分類はあくまでもソースコード上だけで通用するものであって、より抽象度の高い分類方法はこの後も見つかった。ソースコードという目に見えるものの分類には有効だが、ソースコード上で表現されている内容についての分類はまだこれから先だった。そしてそれこそが重要なのだった。

ソースコードは言語によって変わりうる。クラス、フィールド、メソッドというのが有効なのはたまたまJavaがそういうふうに出来ているからであって、他の言語ではそううまくはいかない。だからソースコード層での分類はあまり価値が無いのだということも知った。

たとえばオブジェクトという概念。スレッドという概念。ポインタという概念。これらは他の言語においても有効である。なぜならばそれらが具体的なソースコードなどではなく、抽象的で普遍的な現象に根ざしているからである。他にもこのような普遍的な概念はある。そしてそれら概念こそが言語の実装に左右されない真の意味でのツールなのだと思うようになった。そしてそれからはそのような概念こそが探すべき対象であり、それこそが価値があるものであり、ポータビリティの高いものだと思うようになった。有効で効果の高い概念を発見すると一人で満足して箱にしまったものである。

概念の追求はあまりにも抽象的過ぎてわけがわからなくなってしまうだろう。概念だけを考えてもあまり効果は無い。概念は現実世界からの抽象であり、現実の世界を母体に生み出されるものである。あるいは発見される。だからJavaの場合はソースコードや解説から有効な概念がないかどうかを絶えずチェックすることになる。抽象的で普遍的な概念は知識とは違ってすぐには陳腐化しないし、情報量は僅かだから忘れることもない。概念というと抽象的で言葉だけの存在にみえるかもしれないが、私にとってそれは一つのオブジェのようなものである。作品であり対象である。そして道具だ。

初心者にCFM理論は有効だと思う。これによってJavaのソースコードの見かけの複雑さに惑わされなくなる。大概の入門書では細部から初めてやがてクラスの解説に移るが、逆にクラスから始めて細かい方向に解説していくのもありだと思う。それにはCFMは有効である。

| | コメント (0)

クラス、オブジェクト、インスタンス 再び・・・

あなたたち、オブジェクトとかインスタンスとか…

やはりみんな迷っているかw

だろうな。だってそもそもインスタンスとオブジェクトの概念の正式な定義が存在してないのだから。それでいてみんな微妙に異なる意味で使っていたらそりゃあ混乱するだろう。だからといって無視もできない。なぜならインスタンス、オブジェクトはJavaのコア的な概念だからな。

私自身、かなり苦しんだ口である。でも周りを見回してもここにそんなに悩んでいる人がいないのでおかしいと思っていた。で調べた調べた。でも結局うまい説明には出会えなった。

結局考えた末に自分なりの定義を見つけて自己解決した。インスタンスとはオブジェクトに付けた名前であり、いわゆるポインターである。だからNullPointerExceptionが出るのかと瞬解した。そしてここから無名オブジェクトの概念も理解した。new で生成しただけのインスタンスを持たないオブジェクトを無名オブジェクトと呼ぶことにした。インスタンスを持たないが故に生成直後にGCされることも理解した。

そしてオブジェクトとは状態をもつ存在のことであり、状態を持たない存在はデータであると定義した。ここからクラスから生成したオブジェクトとプリミティブ型のオブジェクトの違いが明確になった。プリミティブ型のオブジェクトはデータなのである。だからクラスから生成したオブジェクトとは統一的には扱えないと。ここからデータとオブジェクトにまつわる思考が発展していった。OOPは存在の変化をあるオブジェクトの状態変化によって表そうとし、RDBはデータの集合によって表現しようとしていると。

やはりJavaにおいてはインスタンスの理解が最初の山になるだろう。これは普通に本を読んで学習していては理解できないだろう。なぜならここら辺を詳しく論じている本はないだろうから。しかし真面目な人ほど迷い苦しむのだから問題だろう。

しかしいづれこの混乱も収束するだろう。解説はされてなくても考察し検証していけばわかるからだ。そしてこの問題をきちんと解説していない本は駄目な本としてマークされるだろう。インスタンスの問題はその指標になりうるものである。

| | コメント (0)

成功したDSLの例

DSL(Domain-Specific Language)とは特定の領域に特化した言語のこと。
DSLはある特定の領域の処理に特化しているのでその領域においては強力な機能を有する。あらためてDSLの一覧を作成しようと調べていたらこれが面白い。注目すべきは意外と汎用言語というのは少なかったということ。
DSLはある領域に特化するため、その領域の陳腐化や領域のフォーカスのミスによって成功か失敗かが極端に出やすい。それでも成功したDSLは結構多い。

成功したDSL
・COBOL(お金の計算)
・FORTRAN(数式の計算)
・HTML(Webページ)
・SQL(RDB専用言語)
・PL/SQL(Oracle専用言語)
・XML(データ保存用)
・VBA(MSOffice専用)
・VB(WindowsGUI専用)
・ShellScript(OSのコマンド言語)
・Emacs Lisp(Emacs環境専用)
・AWK(テキスト処理)
・JavaScript(Webページ専用)
・Ruby(ROR)
・Perl(CGI)
・PHP(CGI)
・ActionScript(Flash専用)
・JCL(IBM汎用機専用)
・REXX(IBM汎用機専用)
・RPG(IBM汎用機(System i)専用)
・PL/I(IBM汎用機専用)
・Tcl/Tk(GUI構築専用)

DSLではない汎用的な言語
・C
・C++
・Java
・Common Lisp(なぜかマイナー)

DSLではないが汎用的でもない言語
・BASIC(絶滅?)
・Perl(かなり汎用性があるらしい)
・Ruby(かなり汎用性があるらしい)
・Python(かなり汎用性があるらしい)
・C#(Windows内では汎用的だが)
・XSLT

なんだかよくわからないけど凄そうな言語
・Smalltalk
・Ada
・D
・C++/CLI
・Objective-C

| | コメント (0)

面白いBlogを書くコツは

一番簡単なのは、正直に書くこと。
飾らないで正直に全てを吐き出すように書くこと。
これだと思う。
でもこれって社会的制約や自己規制や格好付けたい欲望や恐怖や恥ずかしさに負けやすい。だから意外とというか当然ながら難しい。
他人に公開するわけだからどうしても着飾ってしまうし、構えてしまうし、鎧を着てしまう。そうすると面白くなくなるんだ。
大体、正直に書くと自分からみて情けないというか、普段着の自分が出てしまう。
だから自己イメージは傷つけられる。でも外から見たらそっちのほうが面白いんだ。
でも書いてる本人にとっては面白くないし、不快であることがあるんだ。
もちろん、社会的に駄目なこと、他人に迷惑をかけることを書くのはご法度だ。
その最低限のルールを守ってもやはり正直に書くのは自己イメージとの戦いなんだ。
でも書いていて気持ちがいいのは正直に書くほうだと思う。
ああでもこのBlogのようにJavaを中心としたような中心軸があるBlogの場合は軸だけは守った方がいいね。じゃないと日記になってしまう。日記でもいいかもしれないけど、でもBlogという時間軸を前面に押し出したフォーマットの場合はある一つの事柄に焦点を当ててその時間経過を見るという狙いの方がいいと踏んだんだ。

| | コメント (0)

2007年9月13日 (木)

GUIはイベントがキー概念だな

イベントドリブン、というかイベント志向プログラミング。それがGUIプログラミングの本質と見た。これはGUI独特の概念であり、GUIプログラムを作る経験を通して理解するしかない。

イベント制御は魔物であることもわかった。イベントとそれを感受するリスナがあるのだが、イベントを出すコンポーネントとリスナで受け取るコンポーネントの関係がわからない。これは経験を通して実験してわかるしかないのか?

イベントの制御が最も難しく、それさえ使いこなせればGUIの山を越えたといっていいだろう。なによりもやはりGUIというのは動的であり、静的な存在ではないのが本質的な難しさにつながっている。

知識と経験が最も必要であり、そして有効なのがGUIの分野ではないか。そして噂通り、Jtableは難しい。Jtableを制するものはGUIの半分は制したといっていいのではないか。

イベント関係のデバッグをする場合、デバッグ中と通常動作でイベントの動きが異なる場合がある。こうなるとデバッグがかなり困難で、実験をして検証していくしかない。

イベントオブジェクトがコンポーネントのオブジェクト間を飛び交うのだが、これがソースコード中からはわからない。見えない。これが本質的な難しさ。

はあー。イベントオブジェクトがコンポーネント間を飛び交うのが見えるようになればかなり革新的なのだが。。

というのがGUIプログラミングをかじった感想だ。

| | コメント (0)

2007年9月 4日 (火)

NetMeeting を使った研修はどうか

NetMeeting を使った研修はどうかとふと思った。

NetMeetingはWindows2000以降ならばデフォルトでインストールしてあるアクセサリソフトでチャットやファイル送信ができるほか、重要な機能として互いの画面を共有できる機能がある。つまり、私のモニタ画面が相手にみえるようになるのだ。そうすると私がどのような操作をしているのかが全て相手に分かることになる。

さて、この機能を使用すると、例えば、環境構築の方法などをリアルタイムで相手に実演して見せることができる。またコーディングの過程などもリアルで見せることが出来るEclipseの使い方も実演して相手に見せることが可能となる。逆に新人のコーディング過程もリアルタイムで観察できる。

これと音声チャットあるいは音声電話を併用することで、かなりディープな技術の継承が可能となる。なにせ実際の過程を実演して見せることができるのが大きい。社内のLANで使用すれば回線速度も問題ない。

欠点は多人数の教育には向かないこと。どうしても1対1になる。しかし基本能力の高い新人に対してネットミーティングを使用して実演して見せて、その後その新人から他の新人に対してネットミーティングで継承していくというのもありだろう。

PCという操作環境ではどうしても画面を共有してやりかたを見せるというのが難しい。実際に教える段階では口頭やファイルの資料などで終わってしまう場合がほとんどではないか。つまり実際の操作過程をリアルタイムで伝えることは難しい。しかしNetMeetingならばそれも可能なのである。

| | コメント (0)

2007年8月28日 (火)

危機感とハングリー精神

人間を本気にさせるのは、危機感とハングリー精神だと思う。自分の人生を振り返るとそう感じる。そしてそれを楽しむこと。危機的な状況を楽しんでいるときが後から振り返ると充実感がある。ただしそれに対して絶望していないことが条件になる。

確かに高不調の波はある。どうしてもやる気が出ないときもある。やはりというか、その波は交互にくる。何かきっかけがあってそうなるというよりも、時間的にそのような期間が交互にやってくるという感じだ。だから外的な要因というよりは内的なリズムといったほうがいいかもしれない。

私にとって最も充実しているのは行動の方針と計画を決めてそれを地道に実行しているときだ。結果はもちろん出ないのだが、しかしそれを黙々とやっているときが最も充実を感じる。それはおそらく自分の未来を信じているからだろう。

未来を信じられなくなることを絶望という。だから自分の未来は信じなければならない。それが自分に対する礼儀ではないか。それが今まで生きてきた自分自身に対する礼儀である。

自分の未来を信じなければならないとき。それは自分が危機的な状況に追い込まれているときである。だから意識的に自分の未来を作っていこうとする。それが計画や行動となって現れる。計画や行動は未来に対する挑戦である。

そこで出てくるのが方法だ。計画と行動をもって初めて方法が近づいてくる。そこではじめて方法と付き合うことになるのだ。そしてそれはやがて概念などの産物を与えてくれる。

自分自身に対する礼儀をもって生きることが最高の戦略であると信じている。私を真に動かすもの。それは危機感とハングリー精神である。単なる楽しみで動くのではなく、私が本気を出して動くのはいつも危機感とハングリー精神からだった。この2つが私を本気で動かしている。

| | コメント (0)

2007年8月27日 (月)

何から手を付けていいのかわからない

ふう。なんというか、blogに書くときは最近は直接ブラウザ上で書くことにしているんだけど、以前はPCに下書きを書いてから貼り付けていたけど、やはり直に書くと違うね。圧倒的に筆が進む。

それはいいとして、Javaの勉強だ。勉強というか調査というか研究というか検証というか、とにかく対象としたい事柄が多すぎてどこから手を付けていいのか途方に暮れてしまう。

検証コードのテーマが多すぎてまずはその順番を練るところからはじまる。IO、スレッド、リフレクション、ジェネリクス、Enum、GUI、ふう。だからまずは思い浮かぶテーマを一覧に書き出すことからはじめる。それができたら一つづつ片付けていく。

最近まずいなあと思うようになった。このままのペースで勉強しても全然遅すぎることに気づいた。最近疲れて勉強できないのだ。大体業務で1日中コーディングしてたら疲れて勉強できないよ。経験上。それぐらいコーディングは神経をすり減らす。

Javaは勉強の計画と順序を立てるところから既に難しい。範囲が膨大だからだ。がむしゃらにやるというのが通じないのがJavaだと思う。まあもともとがむしゃらにやらないほうだが、それにしてもと思う。

うーん。疲労が溜まっているな。

| | コメント (0)

2007年8月19日 (日)

プログラマという職業は

思うに、プログラマという職業は、女性にも向いたいい職業だと思う。

高収入が得られるかどうかは別として、本来は技術が上がれば仕事がそれに比例して楽になるからだ。そして技術を上げるのは個人の努力と資質に負う所が大きい。これは男女に関係は無い。

だから技術が上がれば上がるほど楽になり高収入にもなりやすいのだ。それがそうなっていないのは、

技術が足りないからか、

技術が生かせない仕事内容だからか、

技術があってもまかないきれないくらいの量の仕事が任されているか

のどれかだと思う。

またはこれらが同時に起きていることもあるだろう。これらの現象が広く起きることで失敗プロジェクトやデスマーチ、ひどい場合は過労入院などが起きるのだろう。

私の経験においても、ひどいプロジェクトの場合はこの3つが揃っていた。だからやっても技術が蓄積されないし、疲れるし、嫌になる。これでは誰でも嫌になるというものである。

とりあえず自分でできるのば技術を上げることだ。忙しい中でもこつこつと少しづつ勉強して上げていくしかない。しかしあとの2つは環境の問題であり自分ではどうしようもない。これはもうしょうがないので仕事場を選ぶしかないだろう。ここで環境を自分で変えてやるなどと思わないほうがいい。よくある精神論で環境は自分で作り変えるべきだという人がいるが個人の力の限度とより現実的な解として職場を変えることを選ぶべきだろう。

結局、技術が伸ばせて技術が生かせる職場を選ばなくてはならない。これは個人の嗜好ではなく技術者として生きるにはそうするしかないと思う。そのような職場を選ぶことは技術者にとって必要なタスクであるとさえ言っていいだろう。

ここでいう技術者とはプログラマを代表とする実装レベルの技術者である。だからSEや設計者はこの話とは特に関係ないと思う。彼らの仕事は顧客との折衝であり仕様の策定である。そこでは技術の向上と仕事の効率の向上は必ずしも比例しないからだ。そこでは何か別のものが仕事のキーファクターとなっている。

やはり重要だと思うのは仕事内容である。勉強は確かに独学が基本だし、基本的な知識や技術は独学で身に着けるしかない。そして職場で発揮するのである。しかし、たしかに勉強は独学が基本だが、それを職場で発揮できないのならば技術は向上しないのである。実際の職場では技術的な不明点を他の技術者と話し合うことができるし、他の人の技術を学習することもできる。互いのコードの相互レビューもできる。これらは独学では出来ない事柄だ。だから仕事を選ぶ必要があるのである。これは我侭ではなく技術者ならばそうするべきだと思う。

よくない職場の例として、雑用が多い、仕様策定や顧客との折衝が多い、専門技術とは異なる技術が要求される、仕事量が多すぎる、などがある。またチーム内で相互レビューがない、熟練者が存在せず技術の継承の機会がない、なども悪い要因だ。複数人で作業していてもそこに相互の学習やレビューがないのならばそれは一人で作業しているのと本質的に同じなのだ。

技術者が育つのに本人の努力と資質はもちろんだが、かなりの割合で仕事環境が与える影響が大きい。本人がどんなに努力家で才能があっても限界がある。そして仕事環境の良し悪しの影響は本人の努力では埋めることが難しいのである。

だからこそ、派遣や請負でプロジェクトを転々とする私のようなプログラマは仕事を選ぶべきなのである。仕事をある程度の範囲で選べること。これが正社員としてその社内でしか働けない人たちと違う大きなメリットなのである。

このメリットが生かせるのは技術者だからだと思う。技術を蓄積して学んでいくのにこのメリットは大きい。プロジェクトを転々とするから蓄積されるのは主に経験と技術だからだ。

そのためには日々の作業や技術や知識はしっかりと記録しておきたい。ほんの些細なことでもけっこう役立つ技術や知識というのはあるものだ。その場で解決しておしまいにするのでなく、しっかりとストックとして残しておく工夫が必要となる。そうでないとなかなか技術は蓄積されない。ここは最も工夫のしがいがあるところだろう。

最後にまとめると、プログラマとして仕事を選ぶ基準としては単に報酬だけではなく仕事内容が極めて重要であるということだ。特に実装技術、チーム内の相互学習、熟練者の存在、これらは要チェックポイントだ。

| | コメント (0)

2007年8月10日 (金)

うーむ。わからん・・・

現在業務でSwingのGUIアプリを書いているのだが、分からん分からん。

いやオブジェクト指向とかフレームワークとかそういう基本ではなくて、純粋にGUI独特の概念がわからない。フォーカス、イベント、モデル、リスナ、エディタ、テーブル、コンポーネント、パネル、など。特に分からないのがJtableの生成に関することとレンダラとエディタ、イベントとリスナとフォーカスだ。

分かりたい。でもこれはやはり本格的にGUIを勉強しないと駄目だな。ここでも問題になってくるのはやはり概念の壁だ。GUI独特の概念の理解ができてない。だから書けないし理解できない。しかたがない。これを機会に勉強するしかないか。

うーん。しかしJavaは勉強しなければならないことが多い。まあそれだけ守備範囲が広いのだろう。しかしあまりにもボリュームがあるとやる気を無くすな。その無力感との戦いだと思う。Javaの勉強ってやつは。

| | コメント (0)

2007年8月 9日 (木)

SJC-Dの認定を取ることを決意する

やはり差別化と本当の意味での専門性をアピールすること、そしてJavaに対する真剣さを表すのに、SJC-Dは無視することはできないという結論に達した。
確かに、これを取得すればどうなるというものでもない。
別に取ろうが取らなかろうが現実はそれほど変わらないだろう。
しかし、やはりJavaの専門職として胸を張れるのはSJC-Dなのだ。
SJC-WCではまだ駄目だ。SJC-Pの055は確かに035よりも遥かに価値があるが、しかしこれでもまだ足りない。SJC-Dを取るためにはこれからさらに膨大な準備が必要となる。
しかし、これで次の目標が出来たというものだ。
SJC-Dを取る人は少ないし、希少性がある。だからアピールできる。
SJC-DはまさにSUNとの真剣勝負だ。真剣勝負しようじゃないか。
こんな試験はおそらくもう現れないだろう。
考えてみればすごい試験だ。SUNのその勇気に感謝する。
まあ受けるのは1年後くらいになるだろうが。
しかも試験期間は1年間って。。

| | コメント (0)

2007年8月 8日 (水)

開発者から創造者へ

開発者から創造者へのステップアップこそが真の意味でのキャリアアップだと思っている。具体的に言えば、自分でアプリケーションやサービスを立ち上げることが創造者になるということだ。

開発者=技術を売る人

創造者=作品を売る人

技術はまだ労働集約型だが、作品は知識集約型だ。

だから作品を売るということはエネルギー効率は抜群なのである。

ただ、創造者になるためには技術が必要で、そのためには開発者にならなければならない。だから開発者は過程なのである。

逆に最も魅力が無いのが開発者から管理職へというよくある道だ。

そして技術を忘れ、高給取りになった段階でリストラになるのが一番怖い。

そういうわけでなんとかして創造者を目指すべきだと思った次第。

現実は厳しいが。

| | コメント (0)

2007年8月 5日 (日)

目に見えないもの。抽象空間での勝利について

例えば資格を取って技術をアピールすることは抽象空間における勝利である。
なぜならば、資格とは具体的には存在しておらず、それは抽象的な存在だからだ
そのような抽象的な存在が存在している空間を抽象空間と呼ぶことにする
資格を取得するということはこの抽象空間において勝利したということだ。
弁護士の資格にしてもそうだ。弁護士の資格それ自体は抽象的で形のないものだ
しかし、それは存在しており、弁護士を目指す人たちはその抽象空間における勝利をまずは目指すことになる。
実はこの考え方は色々な分野に広げられる
たとえば、業務フロー。
業務フローの改善とよく言われる。簡単に言うと仕事のやり方を変えてみて業務を効率よくしましょうということだ。
しかし業務フロー仕事のやり方なんて実際にこれといって差し出すことはできない。
それらは実は抽象的な存在なのである
法律や仕事上での規則慣習などもそうだ。
それらは目に見えず手にも取れないが、しかし抽象的な存在として抽象空間に存在している
そしてここからが重要なのだが、これら抽象空間での変化が実はダイレクトに現実空間に影響を及ぼすのである
たとえば法律の改正などだ。法律や規則やルールや業務フローといった抽象的な存在を変化させることで、実は現実の実際の生活や仕事がダイレクトに変わってしまう
つまり、抽象空間での変化はダイレクトに現実空間に反映される。
これは考えてみれば恐ろしいことだ。抽象的な存在がすごい影響力を持っており、かつ、そんな影響力なんて持ってません、というような顔をしているのだから。
法律、規則、業務フロー、契約、約束、などは抽象的な存在だ。
しかしこれらはまさに存在しており、そして直接現実に影響を与えている。

弁護士や法律家やコンサルタントなどは実は現実世界を相手にしているのではなく、抽象空間を相手に戦っているのである。

生活や組織を変えるのに、物理的な力や経済的な力を持ってするよりも、抽象空間を変えることでそれらを動かすほうがはるかに効率がいい

抽象空間はソフトウェアとか概念の世界ともちょっと異なっているように見える。
それらよりももっと具体的な存在で現実世界への影響力が大きい。

契約交渉にしてもそうだが、それらは抽象空間での戦いであり、勝利を目指しているのである。契約そのものは抽象空間に存在しており、物理的に手で触れるものではない。しかしそれらは存在しており、そして現実世界に大きな影響を与える

抽象空間を動かすことで現実を変える。
抽象空間での勝利を確定させる。
この戦略は極めて重要な戦略である。

逆に現実が変わることで抽象空間が変わるということはあまり無い。
ほとんどは抽象空間から現実空間へという流れなのだ。

これは実用的な考え方であり厳密に詰めた考え方ではないが、しかし有効だと感じている。ここら辺はまだまだ整理が必要だな。
しかし抽象空間。そしてその存在たち。それらが現実を動かしているという現実。
うーん。なんというか、恐ろしくも面白くもあり。

| | コメント (0)

データ構造ってクラス設計のことかな

一昔前(OO以前)に言われていた「データ構造の重要性」って、今で言うならばクラス設計の重要性ってことかな。だとしたらすごく良く分かる。
もともとデータも構造もともに曖昧な言葉だから、データ構造といわれても具体的にどんなものを指すのかわからないよね。
既に私の中ではデータとオブジェクトは別物になってしまっているし。
でも昔のデータ構造が今のクラス設計と同じと考えれば、あれほどに重要だ重要だと言われていたのも納得できる。

と思ったらどうやら違った。

[編集] 基本的なデータ構造
線形リスト
配列
スタック
キュー
グラフ
木構造
ハッシュテーブル
ルックアップテーブル

というのがデータ構造の例。
これらを見ているとなるほどデータというかオブジェクトの構造だなとわかる。

いや待てよ。でもこれらもクラスとして実装されているのだからやはりクラス設計と同じか。

でも基本的なデータ構造とはいうけれど、これらはむしろ、
基本的なオブジェクト構造パターンとでも言ったほうがいいと思うのは俺だけ?

| | コメント (0)

概念の獲得と一回性の出来事あるいは単純作業

PTF、APER、PREREQ、リビジョン、バージョン、差分、全量
これらは単純作業のような泥臭い作業から得られた貴重な概念群だ。
単純作業そのものからは再現性のある技術を得ることはできないが、しかし重要な概念ならば得られる可能性がある。そして気づいたのが、重要な概念は理解するのも易く、余りに当たり前のような存在なのでそれが重要な概念であると気づかれにくいのではないか。

| | コメント (0)

無意識の力を利用する。いや無意識に「してもらう」

無意識に「してもらう」という発想は結構重要かもしれないと思った。
実はそういう場面は溢れている。
実際、自転車に乗るときや、自動車を運転するとき、そしてプログラミングでさえも、最初は意識的に行っていた行為を無意識が行っている。それも無意識が行っていることすら意識されることなしに。
だから無意識にしてもらっているのである。
そして無意識の能力は結構高いものだということがわかる。
しかし無意識が実際にどのように情報を処理しているのかは意識からは見えない。
無意識の能力を利用して、タスクを無意識側に積極的に引き渡すという戦略はどうか。
実はこのことと概念化は関係があるのではないか。
概念化することによって実はタスクを無意識側に投げることができるのでは?
だから概念化と作業効率は比例関係にある。
とりあえずアンカーとして記録しておく。

| | コメント (0)

結局、新人を連れて現場に出れない社員はリーダーとはいえない

なぜならば、新人を現場で育てることがリーダーの最大の義務だからだ。
そうでないと技術者が育たない。
そしてそのためには、リーダーは技術がなくてはならない。
別に資格を持っているかどうかは重要ではなく、現場で通用する技術を満たしていることが前提条件となる。そうでなければ新人を現場で教育することができないからだ。
まず技術があり、次にビジネスマナーなどが来る。
技術がないと新人を連れて現場にいけないのだから、そのような人はリーダーではない。また、技術はあるが現場で新人を連れて行っていない社員もリーダーとは言えない。
なぜならばリーダーの義務としての技術者育成をしていないからだ。
それでも現場を離れて勉強会を開いているのならば、リーダーとしてもいいかもしれない。(これも中途半端では駄目だが)
だから新人を連れて行かない経験者が研修を新人研修を受け持つことでリーダーとなるのはまあ許される線だと思う。

| | コメント (0)

世界、行動、方法

世界と行動とは仲良しで、行動と方法も仲良しである。
方法は危険と仲良しで、また窮地や極限状況とも仲良しである。

| | コメント (0)

2007年8月 4日 (土)

エクセルでの作業管理のその後

その後、実際に職場で使ってみた。
これが結構便利。というかかなり効果的。
今のところ問題は全ての作業を細かい単位で記録する手間をどうするかということ。
さすがに全ての詳細な作業記録を付けることは難しい。
そんなことをしていたらそれ自体が一つの大きな作業になってしまう。
しかし予想以上にいい感じだ。
やはりとりあえずはこれに関数とマクロで機能を充実させる方向で行こう。
また家でも自分の普段の予定管理に使うことにする。
今まではテキストで管理していたのだ。
もっと前からやっておけばすごい効果を発揮したのだろう。
まあ一人で舞い上がっているだけかもしれないが。

| | コメント (0)

進捗シートなるものを作成してみた

といってもこれはまだ単なるエクセルの表に過ぎない。
重要な点は以下。
1.時系列でどんどん記述できること
2.ソート可能であること
3.拡張性があること

これである。
これら3つの特徴はどれも重要で欠かすことができない。
たいていのプロジェクトではスケジュール表をエクセルで作成し、
それでメンバーの進捗を管理しているはずだ。
しかし、これには大きな問題があると密かに思っている。

まず、大抵のスケジュール表では個人の進捗度合いしかわからない。
そのメンバーがどのような問題を抱えており、どのようなアイデアや知識を
獲得しており、どのような状態でいるのか、が見えない
つまり全くディティールの無い情報しか提供しないのだ。
しかも、多くの場合はプロジェクトで定められた成果物の単位で作成されており、
それ以下の粒度のものはスケジュールで表現されないし、
また他の周辺作業はスケジュールに追加することもできない。

なぜならそのようなスケジュール表というのはたいていの場合は
エンドユーザーや顧客に「見せる」ためのものであり、プロジェクトの
状態を把握するということが真の目的ではないからである。

だからスケジュール表からは、この人の進捗が遅れているな、進んでいるな、
くらいしか分からない。
こんなものを大の大人が真剣に作っているのだから笑ってしまう。
そしていつの間にかデスマーチへと近づいていくのである。

必要なのは、正直ベースの進捗表である。
外に見せるためのものではなく、現在の正確な状態を知るための進捗表。
これがない。何故か?
おそらく、今まで存在しなかったのでそのような発想がないか、正直ベースだと困る人がいるからだろう。

しかし全くの個人ならば可能である。
おそらく多くのプログラマはやっているであろう、作業記録の類がそれである。
多くのプログラマやSEは日々の作業を日記のような形式でテキストなどで記録しているのではないか。私もそうしている。そうしないと複数の作業を並列でこなせないからだ。これが実は真の進捗表なのである
もちろんこれでは粒度が細かすぎるだろう。
しかしこれをフォーマット化して共有するのが理想なのではないか。
ただしその際、正直の書くことのリスクは極小化しなければならない
正直な、いや正確な進捗表はそれ自体が価値であると思う。
たとえその内容が芳しくなくてもそれは価値であると思う。
それは信用できるし、問題があるならばそれはまさに事実として問題だからだ。
だからそのような進捗表においては最大の罪は虚偽の進捗を書くことだということになる。現在の問題を正直に書いた人が責められてはならないだろう
(これは組織の健康度を測る目安にもなるだろう)

さて、エクセルで作ることでテキストにはない以下の特徴を持たせることができる。
・ソート可能であること
・拡張性があること
これは先の項目の2と3に当たる。

私のアイデアはまだ稚拙かもしれないが、しかしこの進捗表はたたき台である。
全員が正直ベースで進捗をしたらけっこう面白いし、緊張感も生まれると思うのだがどうだろうか。

以下にそのファイルを置いておく。
時系列、ソート可能、拡張性、を全て満たしている。
これを元にして何かを作る予定。
あるいはこれに関数とマクロを付けて充実させる。

「shinchoku.xls」をダウンロード

| | コメント (0)

2007年8月 3日 (金)

コーディングできないプログラマ

それって存在自体が矛盾?
いや正確に言うと形容矛盾か。

| | コメント (0)

2007年7月29日 (日)

コミュニケーションとはいうけれど、

チームワークとかチームハックスとかいうけれど、それができるのは、基本的に人間的に信頼できるメンバーでの間のみだと思う。

つまり、基本的な部分で問題がある人間、やる気が無い、相手の気持ちを思いやらない、相手の負担を気にしない、人に迷惑をかけても気にしない、自己中心的、勉強する気が無い、基本的な技術が無い、基本的な知識が無い、責任感が無い、このような人間との間では基本的な部分で問題があるために、表面的な工夫が意味のないものとなってしまう

例えば、互いに問題点を共有しようとか、いろいろと工夫をしても、それが効果を発揮するのは、基本的な土台がしっかりしている人たちの間だけだ。
Javaの基本的な技術が無い、基本的な知識が無い、やる気が無い、責任感がない、という人との間ではそれらの工夫が実らない。

そして、問題はまさにそのような場合にどうするのか、ということなのである。

既に基本的な土台ができている人たちの間でのさらに生産性を上げる工夫は確かによいものだろう。しかしそのような場合は現状でも問題ないものがさらに良くなるということであって、そこに切実な問題はないのである

本当に切実なのは、基本的な部分で問題が在る場合である。
そのような場合どうするのか。たとえば上司が精神的に不安定な場合はどうすればいいのかとか。このような解決策こそが実は本当に必要とされていることなのである。
きれいごとはもういい。そしてそのような「本当の問題」においては往々にして解決策は「無い」のである。あるいは「まだ見つかっていない」のである。

そしてそれらの問題はそれらが余りにも深刻で解決策がないがために、「無かったもの」とされているのが現状なのである。つまり議論や話すテーマにもならないのである。

だから重要なのは、「何が議論となっているか」ではなく、「何が議論となっていないか」である。当然議論となるべきことがなっていないとき、それは既にメンバーの間で絶望と諦めが共有されていることを意味するのである。
そしてそれこそが実は本当の解決課題なのだ。

| | コメント (0)

新人研修の学習プラン

検証コードの作成、概念の抽出、この2つを徹底的にやらせたい。
きついだろうけど、本気で育てるならばこうするな。
おそらく普通の人はやらない。だからアドバンテージになりうる。
ま、余計なお世話なんだろう。
できない人ややる気の無い人やまだ機が熟していない人にやっても意味が無い。
結局、ある程度の経験を積んだ段階で話すしかないのだろう。

| | コメント (0)

今後の学習予定

【Tomcat、Oracleを入れたWeb開発環境】
・JSP
・Servlet
・JavaScript
・HTML
・CSS
・SQL
・Strutsフレームワーク
・Springフレームワーク
・上記の検証コード、サンプルコードの集積

【Office、Windowsの自動化】
・VBA
・VBS

【設計知識・設計概念】
・UML
・OMG認定UML技術者資格試験 ファンダメンタル 受験予定

【一般知識】
・XML

【次回の受験予定の勉強】
・SJC-WCの勉強(書籍、問題集)

【ツール類の使用法の勉強】
 JUnit、CVS、Subversion、Maven、Ant、など

【5.0のスレッド追加機能群の勉強】
・JDK5.0に追加されたConcurrentパッケージの学習

【デザインパターンの勉強】
・デザインパターン
・マルチスレッド版のデザインパターン

【GUIアプリ用の勉強】
・Applet

【モデリングとは?】
・オブジェクトモデリング
・データモデリング

【概念層の追及】
・有用な概念の研究

ふう。
これでもまだ実は開発に関係する勉強であって、
ネットワーク、OS、などの周辺は含まれていないんだよな。
あとJava以外の言語もJavaScriptとVBA・VBSしかない。
SJC-WCを受験するのは当分先になりそうだ。
資格以外の勉強は外部にアピールするには無駄かもしれないが、
しかし資格のためだけの勉強は非常に空しいと感じる。
しかしこのボリュームだよ。個別撃破でいくか、全体を少しづつやるか。
ここでもまだ勉強の順序と方法が問題となっているなあ。
しかし気分が乗らないと勉強できない。この波はどうしようもない。
非常に疲れているのに勉強したいときもあれば、とてつもなく暇だが勉強したくないときもある。
とりあえず、Javaの場合は学習する領域の俯瞰図を作成して、その後にどういう順序で学習を進めていくのがいいのか、という計画を練ることが重要だ。
これをやらないと手がつかない。
しかも検証コードと概念の研究はとても時間がかかる。
しかし効果は折り紙つきだ。
しょうがない。毎日少しづつやるか。。

| | コメント (0)

こんなプログラマとは戦わなければならない

Javaの基本文法についてはほとんど理解しておらず、
コーディングでは先行する他人のソースのコピペで乗り切ろうとし、
バグを出しまくって多くの人に迷惑をかけても謝罪も無く、
同じ会社の人に対しても会社のイメージダウンをしたことに対する謝罪もなく、
相手に注意することを自分では平気で破り、
その行動の矛盾には気づいておらず、
相手から馬鹿にされることには極度に敏感で、
同じチーム内で必要な情報を流さずにせき止めてしまい、
部下に間違った指示を出して作業のやり直しが発生しても謝罪もせず、
自分のミスを他人に指摘してもらっても謝罪も感謝もなく、
「・・だと思っていた」「・・のつもりだった」
ということがミスの理由として成立すると思い込んでいて、
メールや文書ではなく、口頭で重要な情報を伝え、
そのことを注意されてメールや文書で伝えるようになると
曖昧な回答や文章で責任を回避しようとし、
他人には役割や地位による責任や義務を要求するが、
自分の役割や地位による義務については放棄し無視して、
それでいて地位や権利だけは手放したくないと公言して、
議論をしても自分の意見だけは最初にまくし立てるが、
相手が反論して自分の都合が悪くなると一方的に話を打ち切ってしまい、
同じ出来事でも相手によって態度が全く異なり、
基本的な問題でも自分で調べもせずに他人に質問をし、
他人に質問をして他人の時間と労力を奪ってもそれについては謝罪もなく、
会議や報告会では部下のミスは報告するが自分のミスは隠して報告せず、
部下に仕事を丸投げしても会議での報告では手伝ってもらっていると嘘を言い、
技術には全く関心がないと公言していながら技術職で転職したいと言い、
部下や自分より弱い立場の人のミスに対しては細かいことまで活き活きと注意し、
このような問題を指摘されても行動が変わらず、
コミュニケーションの問題であると断定してしまい、
互いに問題があるとして自分の側に主要な問題あるとは認めず、
そのままチームリーダーでい続けようとし、
それでいて部下をつれてリーダーとして現場を回ることもせず、
技術面で助けてもらえる人と常に現場を共にしており、
それによって新人教育の機会を奪っていることについての自覚も無く、
現場がきついから退社すると決めていながら、
現場が楽になると退社しないと前言撤回し、
それによって組織を振り回したことについての謝罪も説明もなく、

ふう疲れた。やっぱやらないと駄目だよね。絶対に見逃してはならない。
これを通してしまうと、通した人自身にも問題があるとなってしまうからね。

| | コメント (0)

2007年7月17日 (火)

応用性のある技術と一回性の技術の違い

技術を分類する一つの基準として、応用の利く技術とそうでない技術という基準がある。例えば、Javaの文法知識やAPIの使い方などは応用性のある技術である。
しかし、あるバグを発見して修正したという作業やある新しいアイデアが閃いたというような経験は応用性も再現性もないためにそれは応用性のある技術とは言えない。
ここで「応用性」と「再現性」という言葉を使ったが、応用できるということは再現できるということでもあるからだ。
一般的には応用性のある技術の方がそうでない一回性の技術よりも価値があるとされる。だからJavaの知識や環境設定の知識、ある機能やフレームワークの実現手順などは価値のある技術や知識だということになる。
技術と知識の違いも重要で、あることを実現するのに単に知って記憶すればいいのならばそれは知識であるが、知るだけでなく、何回か実践してみて習熟を必要とするのならばそれは技術といえるだろう。(これは相対的な度合いの違いに過ぎない)

さて。問題は以下に列挙したものではないかと思う。

1.応用性のある技術に重点をおいて習得していくという戦略は正しいのか。

2.一回性の技術の価値は応用性のある技術よりも低いとして、
  しかし一回性の技術にはそれ独特の価値があるのではないか。

3.応用性のある技術でまだ未発見の技術領域があるのではないか。
  (例:仕事のやり方、何気ない工夫、などなど)
 
応用性のある技術が学べないような職場ならば、その仕事が好きでないのならば転職は仕方がないのかもしれない。前回の私の転職もそうだった。
応用性があって、なおかつ需要が高く、それでいて習得者が少ないような技術がその時点では最も価値がある技術なのだろう。まあ当たり前のことだが。
仕事ではそれが応用性がある技術を学べる業務なのかそうでないのかの判断はシビアにやるべきだろう。無論それが一種のセコい行為であることは承知している。
しかし長期的に見て、応用可能な技術を身に付けられるのかどうかはとても重要な分岐点なのである。

| | コメント (0)

やっと受かった

SJC-P 055。長い道のりだった。
やはり本試験は難しかった。問題集にはないタイプのパターンの問題が多かった。
かなり網羅的に勉強したにもかかわらず、70%しか取れなかった。
おそらく試験としては、1.4版の035の方が簡単だと思う。
なによりも試験範囲が055に比べるとかなり狭いからだ。
しかし、それでも055を取る価値があるのは、Java1.4とJava5.0ではJavaの文法面(APIではない)でかなりの変更と追加があったからだ。別物と言っても過言ではないくらいのた。
私が受けた時はenumは出なかった。genericsは出たが問題のコードは短かった。
アノテーションも出なかった。(こちらは全く勉強してなかった)
全体的に問題のコード行数は短かったが、しかし問題はどれも微妙な箇所をついてきたものばかりだった。しかし決してひっかけではなく、微妙な境界を問うような問題ばかりだった。ひっかけではないのでこれは良い問題なのだが、市販の問題集などでは対策は難しいと感じた。やはり自分でこつこつと検証コードで実験してきたのが良かった。
市販の問題集だけを完璧にやってもギリギリだと感じられた。
丁寧にって全部が終わって30分くらい余る感じだった。
残念ながら、微妙な問題の具体的な内容は思い出せない。
それほど微妙で正直いって重要な知識とは感じなかったからだ。

試験時間が3時間と長くかなり疲れる。試験中にもう疲れはじめるという状態だ。
しかしこの試験が一番の山場だ。あとは知識ベースでなんとかなると信じよう。
Javaの場合、一番最初の壁(文法や概念)が一番高い壁となってそびえているのである。だからここを超えれば結構楽になると思っている。というよりここからが本格的なJavaの世界への入り口なのだろう。

正直言って、まだJavaの基本的な部分で納得のいっていない部分がある。
より露骨に言うと概念化できていない部分が残っている。
概念化とはイメージ化といってもいいが、コードをあるイメージに変換できることをいう。だから頭の中ではイメージを使って考えて、それをコードに変換できる。これを概念化という。しかし概念化ができていないとソースコードのまま記憶しておくことになる。
概念化できていないのは以下の領域だ。
 ・インナークラス
 ・generics
 ・スレッド(中途半端な概念化)
この3つはJavaの文法内でもかなり複雑な部類に属するのだが、しかし習熟すればそれだけの見返りがある部分でもある。
enum、IO、コレクション、これらはある程度概念化ができた。
おそらく概念化の困難さとその領域の学習負荷とは比例関係にある
概念化ができないとコードベースの文法の記憶に頼るようになる。
したがってそれは応用が効かず、Java以外の言語での武器にはならない。
だからこれらの分野の概念化が私にとっては当面の課題である。
意外かもしれないが、概念化が困難な順に並べると、インナークラス、generics、スレッドとなる。スレッドは第一義的概念であるのだろうか意外と概念化は容易に進む。(ただし完全にはいかない)genericsになって型という概念の意味が再度問われ始め、インナークラスになってオブジェクトの内部構造が問われ始める、という感じだ。
無論、こんなことを考えるのは不毛であり、ただルールを暗記して使えばいいのだというのは一般的な立場でもある。
しかし概念化の成功は必ずそれ相応の見返りがあるのである。

| | コメント (0)

2007年7月16日 (月)

こいつなかなか・・・

業務知識ではなく、プログラミング技術に関する知識でしたら、やはり実際にプログラムに落とすことをお勧めします。目指している領域が異なる場合ははずしているかもしれませんが、下記のようなステップを参考にしてください。

1.できるだけ小さなプログラムをたくさん書く
 どう動くかを確認し、それを少し変えながら挙動がどのように変わるのか試していくとよいと思います。プログラムについても芋づる的に様々な疑問をコードに書いては試しを繰り返していくとよいでしょう。

2.課題設定
 ある程度のプログラムがかけるようになったら、なんらかの課題を設定し、それに取り組みましょう。まずは課題についてちゃんと動かすことを最大目標とする。少しはプログラム構造に拘る必要がありますが、そこにあまり時間を書けずに、まずは考えていた通りに動くことを目指してください。
課題については、できれば業務より一歩進んだ内容の方が、モチベーションアップのためにもよいかもしれません。

3.プログラムの構造を考える
 課題がちゃんと動くようになった段階で、どのようなコードを書くと分かりやすいのか、クラスの単位、適切なクラス名やメソッド名の名づけ、メソッドの適切な単位、ロジックの分かりやすい表現そして最適化といったプログラム構造をもう一度見直してみましょう。UMLなども使ってみてください。
プログラムの構造を考え、ある程度の方針固めを行うような行為などは、日々の通勤時の合間に、頭で考えたり思いついたことをメモしながら進めると、プログラムイメージトレーニングとして非常に効果があります。プログラムはコードを記憶するのではなく、プログラムの構造(オブジェクト間の関係構造や、ロジックを概念レベルで扱う)としてイメージできることが重要です。

4.業務への応用
 課題で実践したことを業務でどのように活かせるのか、考えてください。

■全体課題「プログラム構造を説明する力を育てる」
 現在のエンジニアに求められているものはプログラム構造を説明できることです。
 この説明は、ユーザ、マネージャー、同僚・部下それぞれの立場に向けて、その立場の人たちが求めてる観点で説明する力です。将来ITアーキテクトを目指しているのであれば、プログラム構造の説明責任を負うことが必須となりますので、このような鍛錬は初心者時代に見につけておいたほうがよいと思います。

以上、簡単ではありますが、少しでも参考になれば幸いです。

                          萩本 順三

なかなか知っているなと感じる。かなり自分と重なる。1の案は検証コードそのものだ。ただ一つだけ異なるのは概念と概念化の重要性について指摘していない点だ。これはけっこう大きな違いだと思っている。

また同じ萩元順三氏の言葉で以下も共感できる。

スキル向上は、単に技術を勉強しながら身につけるだけではだめで、身につける ための自分なりの戦略を考えてみると効果がはっきりと現れます。
つまりスキルを身につけるためのスキルを磨くということが、スキル向上には、 近道だと私は信じております。

同感同感。つまりプログラミングの習得においては、その学習法からして研究の対象となってしまうということ。「どうやって勉強すればいいのだ?」という疑問はとても大切な疑問なのだが、この点について書いている入門書は存在しないのではないか。(あたかもそんな問題は存在していないかのごとく。。)

| | コメント (0)

«とにかくやれることをやること