パスワードを忘れた? アカウント作成

dotkuwaさんのトモダチの日記みんなの日記も見てね。 みんなの日記はここから一覧を見ることができます。

13891282 journal
日記

dotkuwaの日記: ソフトウェアに関する「違う科学」 5

日記 by dotkuwa

博士の権威性を以って、企業活動で「合っている」とされている
科学を、
・古い、誤っている
と主張されると、通常、号を持っていない人間は太刀打ち出来ません。
 
ソフトウェア分野はまだ新しく、その様に主張される論点が
幾つも有ります。もっと古い分野なら、すでに検証され、教科書に
載っていて、ゆめゆめ、
・古い、誤っている
と主張されない様な、
・「違う科学」も、「合っている科学」も、企業の外部で専門的に
 学んでおらず、入社後、その科学に浸って、当たり前としてきた
 人間(職人だといわれれば、その通りです。)
では、思いもしない様な、
基本的な論点を、
・古い、誤っている
と権威性を以って主張され、現場の人間の意志を挫き、結果的に
誤りをスティグマとしてこすり付け、
(多くの場合)始末せずに逃げてしまう、
事が有ります。沢山あります。
 
不善も少ないが、善も少ない「エセ科学」より、「違う科学」の
方がたちが悪いゆえんです。
(時間が経った後で見た)客観的立場から見ると、「違う科学」の
不善は、量も質も隔絶しています。
 
----------------
 
「『違う』かどうか誰が判定するのだ」と当然、疑問に思われる
かと思いますが、それは、
・博士を採用する側
でしょう。
採用する側も、自社で『合っている』科学か、判定する資質は
有る筈です。これを無いと決めつけるのは、博士の見識の欠如です。
さすがに、現在の日本で、これが無いとするのは、時代錯誤です。
 
どの科学に親和し、方向づけて来たか? どこに進むか? は
ポット出の一求人者が決める事では有りません。
また、
本当にその科学を方向性としたら、世の中に貢献できると確信する
ならば、それこそ起業すべきです。
 
----------------
 
では、具体的に何が「違う」のでしょうか? 
自分が知り得る、経験済みの3点を披露します。
 
1番目は、「滑らかなカーブにフィットさせて推論出来るか」、
です。
ソフトウェアの基本単位の関数やオブジェクトなどは、
・それぞれが相異なり、エッジを利かせたり、角度を付けたり
 すればする程、良く
・類似性のある、滑らかなカーブにフィットさせて推論出来る
 様な事柄は、それら類似性を軸に1つにまとめるべきで、
・結果的に、基本単位間は「「「「非常に」」」」異なり、
・たとえばバグの発生を「何とか曲線」で近似する事は、
 ほんの些細な一致すら見ません。
・一々個別に因果推論をし「尽くす」事
がすべてで、事象を説明するどんな滑らかなカーブも存在
しません。根本的にしません。
 
2番目は、「第一原理を持つか」、
です。
ある人の見たシステムの見え方と、他の人の見た見え方は、
矛盾し得ます。
これは、
・調査・考察不足
とかでは無く、原理的な理由です。
ですので、設計書をいくら書いても、
・最終的な正解(様々な角度のテストを経て、得た結果)
とは異なります。
ですので、その「初めに書いた設計書」で合意し、
甲も乙も拘束されるとしたら、裁判が頻発して当然です。
 
3番目は、「表現が豊潤か」、
です。
ソフトウェアは、
・単純でテストが可能
な代わりに、
・文学や仏典(!)などと異なり、表現が豊潤
では有りません。
それゆえ、、表現が豊潤な分野で成功する、
・原典主義(ソフトウェアのプログラム至上主義)
は、破綻します。そうでは無く、
・他の分野から借りて来る、「キャッチーな」スローガン
 と、その時代の流行り廃りを持ちながら、
 (堅実な存在であるプログラムと)共生して、発展
します。見た目上、
・自然言語とプログラム言語の二元性
という風に見えます。一元にまとめる事は出来ず、
なぜ、出来ないかというと、
・プログラムの表現の非豊潤性
に求める事が出来ます。
これを、
・不純である、非科学的である
とするのは、「違う科学」者による侵略行為です。
 
まだ有るかも知れませんが、自分はこの3つしか知りません。

13868121 journal
日記

dotkuwaの日記: 奇妙な悪口を聞きました 7

日記 by dotkuwa

奇妙な悪口を聞きました。それは、
・プログラミングしか出来ない蒙昧な職人のおまえに、
 科学的なデータの作り方を教えてやる。
というものでした。
 
単なる1関数だけを扱うなら兎も角、複数の関数などが
共同して、結果を正しく得るには、
・それら関数などの間にプロトコルを設けて、全体で
 正しい様にしなければならない。
・それのテストは、1関数をテストする様な、きれいな
 形にならない。
ですが、
その「プロトコル」というのと、「科学的なデータ構造」
というのは、かなり同じです。グラフの双つい関係の様で
瓜二つです。ViewModelなどというデータ構造的存在が、
プロトコルの切り口領域に出来るのも、だからだと
思います。
#そしてそれらは、概してたちが悪いです。
 
さて、
プログラミングしか出来ない蒙昧な職人
 (科学的なデータの作り方を知らない)

ですが、
本当に職人として、たちの悪い部分も含めたプログラミングを
やり遂げている人間とは思えません。
 
では、どういう人間でしょうか?
それは、
・1関数のみで成果を得ている人間
です。そうならば、
・複数の関数など間のプロトコルが定まる前に
 手間をかけて、自動テストを初めに作る
事が最善です。
まさに藁職人です。そんなことで職人として報酬は得られません。
 
科学的なデータの作り方を啓蒙してやって、彼らも、
教える方もWinWinの関係になれる相手。
そういう相手と『成り得る人間の要件』こそが、
・1関数のみを始めにテストを書いて作業を進める
 『ことしか出来ない』
人間です。
 
もし、そういう人間(老害の職人)が多数いて、しかも、
職を得て金銭を得ているならば、彼ら彼女らに、
科学的なデータの作り方を教示する職業は成り立ちます。
すばらしい!
しかし、
そういう人間の居る世界を人為的に目指して、そのとば口として、
・初めにテストを書く
事を他人に勧めたのだとしたら、悲しい事です。

13840027 journal
日記

dotkuwaの日記: 例えば 4

日記 by dotkuwa

例えば、微積をおしえるのに、
・i=1から順に足して行く
だけを教えるとしたら、かなりひんしゅくものだと思います。
プログラムをおしえるのに、
・関数
だけを教えるとしたら、同じだと思います。

13826151 journal
日記

dotkuwaの日記: オブジェクト指向の決定的な制限 4

日記 by dotkuwa

オブジェクト指向は、メモリ(データ)を抽象化するためのものに過ぎず
入力・処理・出力(以下関数という)を抽象化しないのでは無いか?
なぜなら関数は状態を持たない為、メモリ(データ)のみを抽象化する
オブジェクト指向は、何の役にも立たない事になるから。
 
むしろ、関数は抽象化し尽くされた存在で、抽象化の余地は無く、
それに対して可能なことは、具体化しか無いと考えるべきかも知れない。
 
そして、具体化のポピュラーな手法として、処理を複数の行に分ける、
手続き指向が有力なのではないか?
 
--------------
 
オブジェクト指向は、データオブジェクトや、ビューモデルで最高の
役割を果たし、画面のウィジット(テキストボックスやチョイスなど)
で最高に美しい構造を示します。
前者はもちろん後者も「データの湧き出しや吸い込み」を表すからです。
 
しかし、サーブレットなど入力・処理・出力は「do」メソッドだけです。
イベント指向でございと言ってみても、必ずメソッド1つ切りというのは、
寂しい限りです。
要するに、そこに着目すべき、要約すべき良い場所は無い、という事です。
関数は、中身の手続きが全てです
#ですから、テストもインターフェース主体で無く、ログ主体にすべきです。
#インターフェースは関数の1断面で、しかもどの断面で切っても大した意味を
#代表しません。
#戻り値も例外も大した意味を代表しません。なので、例外有りでも例外レス
#でも四十九歩五十一歩です。
 
初めのプログラム言語はむしろ、関数型だったはずです。しかし、やって
行く内に、変である事に気づき、破壊的な言語の仕様変更を経て、
手続き指向になったはずです。

13813883 journal
日記

dotkuwaの日記: プログラミング的思考を学ぶべき理由 8

日記 by dotkuwa

1.プログラミング的思考を学んでいない人は、
  プログラミング的何か(ソフトウェア開発とか)
  に関わる際、自分のメンタルモデル無制限押し付け
  をする。
2.なぜならば、全くの初心者が出来る、初めに思いつく
  事は必ずそれだから。
3.プログラミング的何かについて、それなりに経験を
  積んだ組織は、そういうメンタルモデル無制限
  押し付けに対処するには、ゼロトレランスしかない
  と達観する。なぜならば、最終的にたどり着くのは
  必ずそれだから。
4.その段階に達しない組織では、
  ・特定の人間のオタクの権力志向のままに振舞わせ、
   結局、その権力構造が強固でない(その人間が
   飽きたらお終い)事に気づき、
  ・次の段階として、全員が見に回って、一人情シスや
   ゼロ人情シスになってしまい、
  ・その結果、「少し妥協すると、さらに踏み込んで来る
   相手には、何の妥協もすべきでは無い」と組織と
   して経験する
  事になります。
#なにか、別の社会科学的分野でも、同じことが有った
#様な。。。
 
汎用コンピュータを取り入れる様な分野では、自分が
仕事に入った30年前以前から、最終的段階に有ったの
かも知れませんが、
(なので、初めにテストを思いつく事に対して、ずっと
 前から拒否感を経験として覚えていた。)
現在、大抵の組織で、その段階に達したから、
学ばないと、必ずゼロトレランスの憂き目に合うが、
それでは、新人全員が終わってしまい、組織の存続に
良くないから、
では無いでしょうか?
 
#この段階に達していない組織でペアプロをするのは、
#洗脳の様に思える。(個人的意見ですが)

13794154 journal
日記

dotkuwaの日記: 何でやってみないと思いつかないか? 3

日記 by dotkuwa

メタな言葉(科学的なとか、権限とか、処理とか、判り易さとか、テストとか)
は、本質的に一部キャラが被り、一部被っていない複数の意味を持ちます。
だからメタであり、メタな言葉である以上、必ずそうなります。
#プログラム言語はキャラが被ってはならず、上位概念下位概念が有ってはなら
#ない為、メタな言葉は無用です。
 
メタな言葉には、常識的な意味が有ります。大抵は必ず有ります。大抵システム
設計でもそこから始めると思います。しかし常識的な意味は、必ず間違います。もし、
常識的な意味のメタな言葉がそのまま有効なら、それですべてが解けるはずだから
です。
 
では、何で常識的な意味ではないが、合っている意味を初めに思いつけない
のでしょうか?
それは、
「一部キャラが被り、一部被っていない複数の意味」が1個で無く、10個台でも
 無く、10万台とか、無限では無いがかなり多い複数だから

では無いでしょうか?
1個なら、システム設計時にはそれに決め打ちすれば良いですし、10個台なら
それら全てを学校で教えれば済むことです。
しかし10万種類の、すべて別のキャラが立っている意味があるとしたならば、やって
みなければ、どれが正解か判らなくて当然だし、初めに思いついたものが、
必ず間違いだと主張しても、外していないと思います。
 
例えば、「判り易さ」など、
・一生に何回かしかしない場合、手ごたえを感じるのは判り易さにつながるでしょう
 けれど、一日に1000回を毎日、仕事でする人には違う
と思います。
 
「テスト」などはさらに問題です。大抵有る筈の、常識的な意味すら無いからです。
実際に動かすためのモックの筈が、特定の値で青信号だとかになってしまったり、
そういうモックとは、いわゆる開発環境そのものなのに、そうでは無い素晴らしい
別の何かがあるとか言われたりします。
 
もっとも、「常識的な意味すら無い」言葉だったからこそ、おかしい主張には、
初めから「おかしい」と言えたのかも知れません。「常識的な意味が有る」
言葉の場合、それが間違いだと判明するには、少なくとも一世代かかると思います。
・違う科学ではないか
と主張しても、30年前には一顧だにされず、僻みだと言われたでしょう。
 
ただし、メタな言葉を排したらよいかと言うと、そうでも有りません。メタで無い
正しい言葉を思いつくのはさらに大変だからです。
 
さらに、デザインパターンなど、
・アドホックな分類に過ぎない
・(プログラミングで無い別の)科学的でない
とされた手法・分類法も、10万種類の、すべて別のキャラが立っている意味がある
様な場面では、十分(この場面に即した)科学的なやり方だったのでは無いで
しょうか?

13773056 journal
日記

dotkuwaの日記: 上司の要求と依存性逆転の原則 6

日記 by dotkuwa

上司に言われて自分の作業(社内システム管理)のWBSを書きました。
すると、
 
・有る範囲(サーバーのログとか、プロキシのログとか)のアノマリー
 (いつもと違う事)を探す

・問題を見つけたら、対処する。
 
ばかりになりました。それに対して上司は、
・なんで問題を初めに列挙しないんだ。そうで無くては管理にならない。
と言わんばかりでした。
 
アノマリーが何で起きるかというと、外部のせいです。自分の問題では
有りません。サーバーのハードが壊れたり、攻撃が来たり、で全部
外部のせいです。外部要因を内部に抱えた時、アノマリーが起きます。
 
だから、作業者はいつも受け身です。問題は外部から来るので、あらかじめ
列挙することが出来ません。
 
これって、
・依存性逆転の原則にしたがって作った良い設計が破綻する時
と同じでは無いでしょうか?
外部からのライブラリ(典型的にはDBアクセスの部品)を関数の中から
参照する時、依存性逆転の原則は破綻します。
 
でも、「まともな仕事」(自分の責任範囲で、過剰な楽観を捨て、
主体的に問題を摘み取る)をするには、外部要因を内部に引き込む
事が必須です。
でも、そうするとアノマリー(いつもと違う事、あらかじめ列挙できない
事)を抱え込むことになります。これでは「管理」になりません。
 
その点でも、関数型プログラミングの「良い設計」と同じです。
関数型の良い部分は、実用的なプログラムでは、
『本当に些細な枝葉に過ぎなく』なります。
でも責任有る行動のとれるプログラムはそれ以外(UI部や配線部)
が大量に必要になります。
やはり、関数型は古く(COBOL的な)、しかも好い古さでは無い
単なる欠落した存在で、オブジェクト指向はそれを補った結果だと
思います。

13764923 journal
日記

dotkuwaの日記: ライフワークバランスに寄与する一案 2

日記 by dotkuwa

ライフワークバランス(残業しすぎは良くない)について
会議が有りました。
何か案が無いか聞かれました。そこで、昔考えていたことを
思い出しました。
 
自分は一貫してぺーぺーの作業員でしたが、その上にリーダー
が居て、プロジェクトマネージャー(管理職)が居ます。
特にリーダーの残業は昔から問題でした。
 
案ですが、
・作業員が「問題として正式に報告する・一覧に載せる」ほどの
 ことが無い、「ひっかかり」(数分~数時間で解決する)を
 全部ツイートする。

解決したらツイートする。
なにも無くても、順調な様子をツイートする。
・それにより、リーダーの「現場感覚」を補う。
・そうすることで、四六時中リーダーやその補佐が居なくても
 「現場感覚」を損なうことを減らせる。
のでは無いか?
ということでした。
 
昔(五年以上前)に管理職に雑談で提案した時には、
・PM(管理職)としては難しい。その様な大量の情報を正式文書と
 されると、それら全てについて聞き置く以上の対応を迫られるから。
という答えでした。
さらに、
・イントラネットでツイートが出来るサーバー
も有りませんでした。
 
しかし、今日、
・(特にリーダーの残業を管理職が)何とかしないと罰則も
 有り得る。
・その様な記録を残してくれるなら、残してくれた人に少々くらい、
 その内容に応じて有利に取り計らってもバチは当たらない。
・マストドンを使えば、イントラネットでもツイート出来る。
という風に状況も変わったので、やってみる事にしました。
 
メモリ2GBのCentOS7のVMをもらえるそうで、まず(ファイルサーバー
などの管理者の)自分がやります。
その様な「ひっかかり」の記録を数年取れば(1日20ツイート位?)、
ファイルサーバーなどの管理者について、もれぬけの少ない引継ぎ
資料が出来るだろうことを期待しています。

13759751 journal
日記

dotkuwaの日記: 科学や技術や技能 2

日記 by dotkuwa

「もし自分が担当しているファイルサーバーの管理権限を
 移譲するとしたら、条件は何か? お前も若くないの
 だから。」と言われました。
それで即答したのですが、その内容だけでは面白くないので
もう少し考察してみました。
 
★違う科学:
ソフトウェア・プログラムの分野と違う分野で効果を上げて
いる科学だが、この分野に持ち込まれると疑似科学より著しい
害をなす科学。
★科学:
設計。利用。
(設計意図を超えた利用は、後天的な不具合を生み出すので、
 利用も設計と同様に「科学」である必要が有る。
 この様な性質は窮理学的科学には無い。)
★技術:
「自分のやった事を覚えている」事。テストなどをして
「チェックリストを付ける」事が求められる作業をする際には、
これが必要。
(覚えていないのにチェックリストを付けても「自分のやった数」
 を記録しているに過ぎなくなる。
 例えば、現地に行って複数台のPCにWindows7を入れ、指定の
 ソフトを数個入れる作業など、その典型。
 自分のやった事を覚えていないと、グダグダになる。)
これが身につく為には、学んで時に習う事が必要になる。
経験値の有る人は、より少ない労力で習う事が可能なので、
自分の時間で習っておくと、経験値の無い人に対して優位性を
増すことが可能なので、自分の時間を使っても余りある
現世の利得が得られる。
★技能:
「自分のやった事を忘れる」事。タッチタイプなどこれ。
理屈で無い反復練習が要る。
自らを省みる事は不要。ひたすらabcdefghijklmnopqrstuvwxyz。
(中学生のクラブ活動から英文タイプをやっている自分は、
 沢山作業して、トイレに立つ気力すら無くなっている深夜でも、
 かすんだ目でようやく見えるキーボードに向かい、何の問題
 も無く、作業報告をタイプ(だけは)出来る様になっている。)
要するに本邦で通俗的に言われている「プログラマー」というのは、
技術が有るか無いかは別として、技能が有る人ではないか?
技術が無いとパンチャーと言われ、有ると(国際的な意味での)
プログラマーになるのではないか?
(割と海外では(スマホ世代以前の人間は)、タッチタイプの
 技能は「当たり前品質」なので、本邦の「プログラマー」と
 ずれる。)
 
という分類の中で、自分が即答したのは、
・「自分のやった事を覚えている」事
(だけ)でした。
覚えている為には、理屈もかなり知らないとダメで、
それなりに高いハードルです。

13717130 journal
日記

dotkuwaの日記: 違う科学 12

日記 by dotkuwa

統計学やその発達の素となった物理学が見ている世界は、
・全世界で谷が1つ。
・谷の周りの風景が多様。
・なぜか人間は谷の底を、直接降りて調べられない。
・しかし間接的な試しで、谷の周りの風景と谷の底の
 相関を調べる事が可能の様に見え、いままでそれに反する
 事は全く無い。
とします。
 
ソフトウェア科学が見ている世界は、
・場面場面で近傍に有る谷が、少なくともアボガドロ数
 以上ある。
・谷の周りの風景が希薄。
・容認できるコストで人間は谷の底を調べる事が出来、
 容認できるコストで這いあがってくる事も可能。
・ある程度、谷に降りてみないと、正しいかを問うための
 「言語(他人とコラボする為の記号)」すら確定しない。
・谷の周りの風景が希薄なため、谷の底との相関という
 ものを問う事が、そもそもナンセンス。
・「正しい」谷が、外的要因や時間経過で変わる。
とします。
 
なんで、ソフトウェア開発で、
・(比較的)少数のテストを初めに書くと、見通しの良い
 プログラムが自然に導き出される。
などという、
いままでそれに類する事が起きた事が無い事をいう人間が
居るのかという疑問は、
・違う、実際と外れた別の科学からの類推。
だとすると説明が付きます。
これは正しくありません。

似た科学からの類推は歓迎すべきですが、違う科学からの
類推は有害なだけです。

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...