« 2011年3月 | トップページ | 2011年6月 »

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月 | トップページ | 2011年6月 »