全部吐いて楽になろう

(問1)
論理学とは、人間の思考から生まれたものであり、
人間の思考が物理的現象だとするならば、
論理学は物理学に内包されるのだろうか。

(問2)
物理学も、人間の自然界認識と思考から生まれたものであるから、
人間の思考が物理的現象だとするならば、
物理学的現象が自然界そのものを物理しているのだろうか。
同一体系内で自分自身について論ずることによる
矛盾や限界はないのだろうか。

「学習する」ということはどういうことなのだろうか。
かなり「トレーニング」に近いものがあるように思う。

ある意味では、フルートの練習と似たところがある。
姿勢や腹筋や喉のあけかたや顎や首やあれこれ正しく直しているうちに
ふと今までとは違う深みのある音がするのと似ている。

縁あって、学生時代に勉強できなかった、「数理論理学」「数学基礎論」「計算の理論、
計算可能性の理論、スコットの意味論、・・・」などの本を読むチャンスができたのですが、
学生の頃は細部にこだわって全く先に進めなかったのに、歳くった今のほうが、
内容がよくわかるのは、基礎概念をあれこれ耳学問で身についてしまったせいかも
しれない。

人は自然な数概念(1、2、3、・・・)および、実数の概念(連続量の概念。水の量とか。)
をなぜか身につけている。この自然な認識能力が、全てを生んでいるのかもしれない。
本を読むとき、一冊ずつ最初から読むのでなく、関連した数冊(数理論理学、数学基礎論、計算機の計算の理論)の目次をいっぺんにみることで、論理構成の似たところ、
異なるところ、が見えてくるので、何を押さえればいいのか、キーワードが見えてくる。
なかなか面白いと思う。

全くのメモです。
あらゆるプログラムの停止性を判定できる万能プログラムはない。
もしそのようなプログラムfが存在したとしても、あるプログラムgが存在して、
f(g)が停止しない。
なんだか書いてて記述がおかしい気がする。

プログラムの停止する領域を絞ることには、どういう意味があるのか。

まったくのメモです。
ゲーデルの不完全性定理が実際に適用される例。
入力されたプログラムが停止して結論を出すか、停止せず結論を出さないか、
を判定する万能プログラムは存在しない。
つまり、その体系内では、一般に停止するかどうかを判定できない。
よって、そのようなプログラムを作ろうとするのは無意味である。
体系の外部、たとえば、人間がある着眼点により、ある入力プログラムの停止・否を
判定できるかもしれない。その体系からみれば、人間の着眼点は、非計算的と
いえるのではないか。
ペンローズの本に載っていた、「二つの素数の和ではない2より大きい偶数を
みつけよ」という問題に対して1、2、3・・・と調べるプログラムを組んだ場合、
本当に停止するのか、永遠に計算が止まらないのか、結論不可能であり、
とまることを期待してプログラムを組んで動かすのはちょっと愚かであろう。
物理学ではこの辺の事情をうまくあてはめる適用例はないのかもしれない。
それとも物理学にも、現在の理論記述力の体系を超える非計算過程が存在するのかどうか。

最近、「ゲーデルの不完全性定理」というものにはまっている。
誤解を恐れずに要約すると、自然数に元づいた論理体系には、真偽の判定が原理的に
不可能な命題が存在する、ということなのだそうだ。

そこで、オフシャワ、ひいては、異なる言語体系で思考している者同士が、
どのように、どの程度正確に、概念を伝えることができるのだろうか、ということに
たどり着くと思う。
言葉で表現しているかぎり、言っている内容自体が矛盾を含んでいる場合もあろう。
１００％正確に伝わらなくても、出来上がったソフトウェアなりシステムなりが、
誤差範囲内で仕様をみたしていれば、それでよいのかもしれないが、
落ち着いて考えると、同じ言語体系に従う者同士でさえ、確実に仕様を述べないと、
思っていることが違う場合が、おうおうにしてある。

ソフトウェアの仕様というものは、どういうふうに記述されうるのだろうか。
言語で完全に表現できるのだろうか。それとも、記号や図や、言語で表せない
ような内容もあるのだろうか（色づかいなど）。その辺になるともう、デザインの領域かもしれない。

相手に概念を伝えるということは、そのくらい慎重に謙虚に行わねばならない、
という、まあ、何の役にもたたない結論しか、今の自分にはだせないのがくやしい・・・

前回オフシャワについて、愚痴を吐いてしまったが、ちょっと気持ちを改めて別の話。
「ある仕様にもとづくプログラムの作成を他者に依頼するにはどうすればよいか」
内部仕様的な面もあれば、外部仕様的な面もあるだろう。

ものごとを規定するのに、どのくらいの情報が必要なのだろう。

先日、いつもおじゃましている物理のコミュニティサイトで勉強させてもらったのだが、
「実数R上の連続関数をFを一意に規定するには、有理数Q上でのFの値を規定すればよい」
とのことなのである。関数の連続の定義と、有理数Ｑの稠密性から証明可能であろう。

では果たしてソフトウェアの場合はどうなのか？

簡単な例で、「自然数Ｎの階乗の結果を求める」プログラムを依頼した時、
０やマイナス１に対する処理をどうするのか、を規定しないと、発注元が意図した
外部的動作とは異なる結果が生産物として返ってくるのはかなり明らかだ。

同様な話で、あるデータを削除したら、リンクがきれて、不具合がでたことがある。
作成元に上司が確認したら「そういう使い方は実際の業務運用かはらないはずだ」
とのこと。西暦２０００年頃のＶＢ＋ＤＢのプログラムの実体であり、東京大阪と言えど、
この程度なのかと、落胆した。それを全国に撒いているのだそうだ。
今どきの現場からすると論外な話のだが、結局、エンドユーザーはそのような使い方は
するな、ということらしい。
結局、私が（あるいは他の方が既におっしゃっているかと思いますが）三人称の
コンピューシティングにかかわってそれで喰っている多くの人間は（私も含めて）不幸だと
思う。無報酬で対応したいのはやまやまなのだが、しがらみが多くて、結局泣くのは
エンドユーザーである。
そんな状況が続くかぎり、海外オフシャワも国内オフシャワも、近所の下請け派遣ソフトウェア会社にオフシャワするのも、うまくいくはずがなかろう。
結局発注元の認識があまく、単価は安いが思うことが伝わらなく、出来上がったものが
使えない、というのは、請け負った先だけの問題ではなく、発注元の問題も大きいのでは？

王様の耳はロバの耳～、言わずに死ねるか～。

先日知人とちょっと飲みながら話をした。
私が「他国の優秀で単価の安い熱意のあるところに仕事をなげてオフシャワ開発したが
うまくいかなくて、単価が安くて日本語が使えるこっち(○○県)にしりぬぐいが回ってきた」はなし
をしたら、知人が「むしろ、○○県にオフシャワでなげたら、思い通りに上がってこなかった」
という話を、少し感情的になりながら話した。
この話に落ちをつけるならば、東京で生まれ育ってずっと東京で仕事してきた私からみれば
「東京の単価の安い某ソフトウェア会社に仕事をだしたが、おもうように上がってこなかった」
という落ちになるのではないかと思う。

ここで某外国の技術者のできが悪いとか、○○県あるいは、別の□□県のもののあがりが悪い、とか、東京の下請け業者に発注したらだめだった、とか、悪口の言い合いをするつもりはない。

本当の原因は何なのか?  同じ社内で開発していても、出来ばえはさんざんだった、
というプロジェクトもあることだろう。東京だかどこだかで作って全国に売っているソフトが、
内部的にはかなりぼろぼろで、ユーザーの使い方の問題にされているのを目の当たりに
みて、これでよいのだろうか、と思う毎日である。東京や大阪だって、ぼろいところはほろいのである。

言葉の壁もさることながら、他国の開発者との間で、同じことを考えることのできる設計や資料、
仕事の進め方、など、てんでばらばらなので、うまくいくわけがない。

人のことをつかまえて、あそこは単価は安いが出来上がりがよくない、などのことを
言い合っても意味がない。

ソフトウェア開発の本質的なところを議論するべきなのだと思う。
納得できない仕様を顧客から提示されて、無理していることはないのだろうか・・・
最後のしり拭いは結局下流工程がかぶることになる。あるいは仕事をなげられた
オフシャワ部隊を悪者にしてお茶を濁すことになる。(昔はよくあった話だが、
「プロジェクトが進まないのは、現場が働かないせいだ」などと平気で言っている専務さん
がいたりしたものだ。(みんなあきれてましたが・・・私は「管理やプロジェクト遂行をやっている上部の問題だ」と轟然と言っていましたが・・・)

自社内や近所の使えない下請け会社に仕事回して、結局うまくいってない限り、
オフシャワにしたってうまく行くわけがなかろう。

業界の某氏たちが行っていた、「もう、納得のできない仕様をお客様から受け入れるのはやめよう」とかいう主旨の発言をどこかで聞いた。
本当にソフトウェアを成功に納めるのはむつかしい。
そのレベルから頑張らないと、ものごとや、ひいては、オフシャワに限らず、
作成の外部委託の問題は解決しないと私は感じた。

ちょっと物言いがへたで、要点がまとまらなかったけれど、きょうはこのへんで・・・

自宅の公開サーバーでphpPgAdminが動いてうれしいのだが、やはり簡易書籍一覧は
このようなツールでの直ハンドリング(手作業)はしんどい。
かといって、むやみにプログラミングするのは、やればできるのはわかっているが、
金も時間もマンパワーもない一人称のコンピューティングの理念に反する。
より単純な解、ある意味、不動点を求めているようなものなのだと思う。そして、コンベンション(利便)、すなわち、
ちょっとした工夫で、より少ないプログラミングでわかりやすい構造のお手軽なものが
できるはずだ。ちょっとしたアイデアも蓄積すると、単純明解なプログラムの役にたっているようだ！口を動かすより手を動かす、手を動かすより頭を動かす。やみくもに手当たり次第にやらず、納得いくまで考え抜くこと。そんなことも楽しみのひとつだと思う。

漠然とした不安で、自宅作業が先に進めない。
何がネックになっているのか、それを明確にしておくことで、できれば文章や図に書いて
おくことで、もやもやとした不安が明確な到達地点として明瞭に見えてきて、
そして手段(到達手段)、解決方法が思い付く。
はしょって一気に進もうとしても、明確に認識されていない問題点の回りを堂々巡りするだけだ。

ネックポイントを明瞭に把握して、形にして、認識して、対面することが、解決への第一歩！
問題を正しく捉えられたら、それが答えに直結している！答えは、良い答えが複数ある場合もある！

きょうはうれしいことがあった！
実は以前から、愛用しているCanna+gCannaの辞書が壊れているようで、一部の単語変換
がまったくとんちんかんになっていた。しかも、毎日じわじわと壊れが広がっているみたい…
Cannaをインストールしなおしたり、gCannaをインストールしなおしたり、あるいは、
AtokXを起動して一時代替しようとしたが、全てだめ…
公開サーバー側のCanna+gCannaは快調に動いている…

もうクライアントマシンの再インストールをしようと思い始めたころ、案が浮かんだ。
快調に動いている方の、/var/lib/canna/dic/以下の全てを、不調のクライアント側に
まるごとコピッて上書きしたら、うれしいことに、回復してしまった！！！

以前は、とうせん→当千  ※まるでとんちんかん！
現在は、とうせん→当選 

いまどきのX-Windowは、SCIM+Anthyなのかもしれないし、私もそのうち移行を考えたいが
しばらくは、Canna+gCannaに御世話になることだろう。手になれたFEPはやはり快適だ！(Shift+Spaceでの漢字モードON／OFFが身にしみついているからだろう…半角キーでの
漢字モードON／OFFは世間のながれに反して、私にはつらい。ホームポジションからの
逸脱がとても気持ちが悪いのだ…。単なる個人的な嗜好の問題だとは思うが…)
Y(^o^)Y

自宅のサーバーにのせる蔵書管理システムの最初の難関をようやくクリアできた。
Javaで組むWEB＋DBシステムなのだが、フレームワーク自体も自作で、そのテストの意味も
かねているため、だいぶ時間がかかってしまったが、金も時間も何もない一人称の自分に
とっての、手慣れた武器が一つふえたことになる。
わかってしまえば簡単なプログラムだったのだが、その再帰的構造を最後まで見極められなかったのが、時間がかかった理由の一つだろう。
リカーシブコールについては、学生時代に受けた講義で、「リカーシブにしか記述できないクラスのものが実在する(アッカーマン関数など)」「テイルリカージョンはループに還元可能である」などのことは教わったのだが、
現実に、リカーシブなプログラミングが適切な局面に、始めて出会ったような気がする。
これをループで記述すると、たいへん難解なプログラミングになるなと実感した。
実世界では無縁だと思っていたリカーシブコールを、ちょっと今回は見直した思いがする。
(^ ^)

人は歳とともに、扱う情報も多くなり、手帳とかメモに頼らざるを得ないのは、異論のないところだろう。

最近、自分の記憶力のなさに、辟易する。よって、なにがしかの手助けが必要である。
それが、手帳であり、メモであり、そしてコンピュータなのである。
自分が何を持っているか(本、CD、DVD、資料、楽譜、権利書、あれこれ)を、
四六時中覚えているわけではない。
そして、必要な時には、どこにいても思い出したい場合がある。

よって、自宅サーバーなり、レンタルサーバーに、パスワード認証かけながら、
自分の大事な情報を、いつでも取り出し確認できるようにしたい、と思う訳である。
だからこそ、自分のためのコンピューティング、一人称のコンピューティングを
検討する必要があるのだと思う。

漢字入力FEPが手になじんでいると、とても気持ちがいい。
単に、漢字変換効率の問題ではない。(ともすると、多くの人がこの点だけに言及する。)
もっと大事だと思うのは、よどみなく入力できること、ひいては、
英字やら漢字やらのシフトモードが思った通りに変換できるとき、
つっかかる不快感がなくなり、至福の幸せを感じるのだと思う。

シフト制御が最もよく考えられていたのは、やはりF社のOAKだと思う。
LinuxではCanna(+gCanna辞書追加)はわりと手に馴染んでいるが、いまどきはSCIM/Anthyなのかもしれない。私自身は、OAKを使っていたせいか、半角キーでの
漢字オンオフよりも、CannaのShift+Spaceのほうが親指シフトにちょっと感じが似ていて
使いやすい。
私にとって、使っていて一番不快なのは、どうもMSーIMEのようである。
あの２段サイクリック、３段サイクリックは、一々右下のシフト状態をチェックせざるを得ず、
または、数文字うってからシフトが正しくないことに気づき、うち直すという、不快きわまりない
ことを行わねばならず、生産性と心理状態を損なっていると思う。
OAKなどの場合は、親指シフトキーを親指で何回打っても漢字／ひらがなモードだし、
英数シフトキーを小指で何回打っても英数モードだから、モードの頭で無意識に
適切なシフトキーを押すせいか、よどみなく快適にうてるのだと思う。

自分にあったFEPで快適なコンピュータライフをエンジョイしたいものだ。

TomcatのBasic認証は、世間の解説ページの通りにやったらうまく行った！
出費傾向把握ソフト(いわゆる、家計簿やら出納帳みたいなやつのWEB版)には、
これで十分だ。(私が出先や街中のインターネットカフェや自宅から使えればよいだけ！)
しかし、(まだ詳細は言えないが、隠すほどのものでもないのだが…)蔵書管理のほうは、
一般閲覧とOWNERによる更新の２モードを切り分けないといけないので、
そのような認証方法を実現する必要がある。まあある程度、方式案はかたまっている。
いい調子で進んでいる！(^ ^)

うかつなことに、Tomcatには、Form認証以外にも、Basic認証があることが、
きょうネットの情報をみていてわかった。Basic認証のほうが簡単にいけそうなので、
こっちで頑張ってみることにする。Apacheと違って、パスワードがxmlファイルに
暗号化されずに載せなくてはならない模様。まあしょうがない。私以外の人間が
アクセスできなければ、それでよいのだから・・・。

ようやく、WEBプログラムが動作し始めた。要は、出費の傾向把握のためのWEBプログラムである。やはり、飲み代とそれに付随する代行運転やら移動の費用などが家計を圧迫しているのが良くわかる。
プログラムの出来栄えを自宅公開サーバーで公開できるので、みてもらいたいところではあるが、
内情をさらしてしまうので、実データは見せられない。DBインスタンスをもう一つ作って公開し、
みなさまの御意見を仰ごうと思う。いずれにしろ、セッション監視してログイン認証しなければ
とてもWEB上で使う個人プログラムとしては安心して使えない。
TomcatのFORM認証をためしてみたがうまく動かないので、簡単に、ログイン認証とセッション監視、セッション切れでログイン画面強制遷移、というところか…。
ささいなプログラムだが、こういうのをただで欲しい人は結構いると思うので、VECTORに
登録したい。(GPL/LGPL/BSDいずれかのライセンスにしたい。できればGPLだろうが、
もしも結構使われるのであれば、LGPLやBSDあたりがよいのかも。気が早いかな？)

一人称のコンピューティングに言及するのは、既存のJava Web Frameworkでなく、
自分で考案した軽い仕組みの妥当性を訴えるのがそもそもの理由であるが、
その仕組み（フレームワークのようなもの）で開発中のちょっとしたプログラムを、
画面クラス自動生成の際に、誤って上書き消去してしまったのです・・・
ここ数日の結果がパァとなりました。
が、しかし、ソースコードを少々リファインメントする必要もあるし、もう頭の中にパターンは
はいっているので、１日～２日（計３時間くらい）で復旧できる見込み。

きのうの２４時頃、ここのブログのログインが重くて、結局ログインできず、この文章も
書けませんでした・・・（フリープランだからしょうがないか・・・）

概してみな、三人称のコンピューティングで飯を喰っている。
つまり、人・もの・金・時間を提供されて、第三者のためのコンピューティング環境を
作成／保守しているのである。
ここで、一人称のコンピューティング、すなわち「私のためのコンピューティング環境」は
誰が作ってくれるのか、を真剣に考えたい。
人は自分のみ。金も自分の金。時間も自分の時間。すべてのリソースは自分しかないので
やはり、開発ツールには、自分が納得いくものを選びたい。もしくは、自分でそういうツール
をつくり出す必要があるのかもしれない。
そして一人称のコンピューティングは、二人称「あなたのためのコンピューティング」にも
つながっていく。
人・もの・金・時間が比較的潤沢な第三者のためのコンピューティングのツールが必ずしも
一人称／二人称のコンピューティングに有効とは限らない。見極める目をもつ必要がある。