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

こちらは、dotkuwaさんのユーザページですよ。 みんなの日記の更新状況はTwitterの@sradjp_journalsでもチェックできます。

13818750 comment

dotkuwaのコメント: テストドリブンとは移行星の流儀? (スコア 1) 8

by dotkuwa (#3551067) ネタ元: プログラミング的思考を学ぶべき理由

ソフトを開発していると、小前提は頻繁に
(結合テストをしている時ですら)変更が
有ります。
変更のマネージャーがテストのマネージャーと
連携を取らず、全部こちらのせいにもされたり
しますが、それが実態でした。
そして、オブジェクトのインターフェースは、
小前提単位に切り分けられ、すげ替え可能に
なる様になっている筈です。
 
中前提を変えるなんてなったら、トップレベルの
仕切り直しになるでしょうし、大前提を変えると
なったら、開発側が裁判で勝つでしょうけれど、
その様な事は、自分らとは関係が無いレベルです。
 
そういう背景の元、
・小前提を固定する「テスト」を初めに書く
事を推奨しているのはなぜでしょうか?
 
それは、
・それが移行星の風土に合っている
からでは無いでしょうか?
移行星では、
・モデルは所与で、移行元のシステムも実行可能
です。
そういう風土での最適な手法を、新規開発に持ち
込もうとした結果だとするなら、
理屈に合います。
 
しかし、その様な事は移行星の外では成り立たない
事が多く、特に、初学者が自分で自分のメンタルモデル
と向き合おうという時には、猛毒となるでしょう。
無い、顕在化されていないメンタルモデルから直接テスト
を書こうとするのですから、本当に有害です。

13818360 comment

dotkuwaのコメント: 移行星獣の今後 (スコア 1) 8

by dotkuwa (#3550822) ネタ元: プログラミング的思考を学ぶべき理由

自分は大学時に家でいじっていたマイコン(MZ-80C)の
SP-5030とSP-4010とHu-Basicの知識だけで、会社に入り、
オフコンのコボルプログラムをいじれ言われて、いじった
ら出来てしまったという経緯でコボラーになったので、
伝手とかが有った訳でも無く、ゆえに、
伝手の無い人に対して優越性を持てた事も無かったのですが、
 
何故かコボラーとして非難される側になったのです。
それは今でも続いています。
 
ただ、現状は変わってきています。
本当にコボルを別の言語に移行するのが流行っていた時期は、
★説明・説得が不要
でした。まるで携帯電話か何かの様に、「明白なる運命」として
広まっていきました。
しかし、現在、例えば「Forを排すべきだ」とか、迅速かつ適応的に
ソフトウェア開発するのにこのやり方にそろえろとか、
年中説明・説得がなされています。
それだけで、移行星獣の現状が理解できます。間違いなく
追い詰められています。
 
移行星では、テストにおいて特異な事実(良い事実)が有ります。
同じ入力をして同じ処理をして同じ結果が出れば、テストOKと
出来る点です。
しかも、モデルは既に与えられていて、考える必要が無いのです。
これらの事から、移行星獣は、(ハマれば)大儲けが出来ます。
 
特に移行星獣の内でも、最高にハマっていた時期に、功績から
大学などに進んだ個体はまずいと思います。
移行後のシステムを保守していれば、自分で成員間のメンタル
モデルの再調整を求められたりして、星獣が星人にスキルアップ
出来たかも知れませんが、
現場を離れた移行星獣は、獣のまま、次の移行のネタを探してる
のでしょう。
 
しかし、本当に移行が誰からも望まれる状態では、
★説明・説得が不要
なのです。だから望まれてもいない状態で、第二のどじょうとして
PHPをやり玉に上げようとしてしくじったのだと思います。
 
今後は、時代から取り残された移行星獣の言う事は聞かず、
現行のやり方でもかまわず、小さい事から積み重ねて行き、
成員全員が納得できるメンタルモデルを導き出すのが
肝要だと思います。

13815375 comment

dotkuwaのコメント: Re:コボラーを責めるべきでは無かったのでは無いか (スコア 1) 8

by dotkuwa (#3548585) ネタ元: プログラミング的思考を学ぶべき理由

一度整理してみたいと思います。
 
ここで、「コボラー」だと言って非難する人間の事を
(怪獣つながりで)「移行星獣」という事にします。
(なんでかは後述)
 
COBOLがだめになったいきさつは、
1.大きいPC(サーバー)で、情報処理が出来る事に
  なった。
  (これだけなら、COBOLもサーバーで動く様にしさえ
   すればよかっただけですが、そうはなりませんでした。)
2.RDBが流行るようになったが、COBOLにNull項目など無く、
  各基本項目の直前に1バイトのNullか判定する項目を置け
  だの、頭が痛くなる事ばかりだった。
3.COBOLで無いVB4とかDelphiだとかは、何十万か出しさえすれば
  無制限にRDBアクセス環境をインストール出来た。
  Null項目(As Variant含む)も有った。
4.しかも新しい言語はオブジェクト指向対応だった。
  メモリ直アクセスが原則のCOBOLと違い、
  オブジェクト指向言語は、インターフェースを介さないと
  メモリにアクセス出来なかった。
  これは大違いで、言語を移行するに足る進歩だった。
ですが、
成員全体のメンタルモデル(別名お気持ち)から見て、
何とか納得するモデルは、
既にCOBOLで有りました。
 
ですので、コボラーから破壊的に奪い取って、新システムを
成し遂げた人間は、移行しかしていません。
だから「移行星獣」です。そう考えると、それからの彼ら彼女らの
行動に納得が行きます。
 
--------------
 
成員全体のメンタルモデル(別名お気持ち)から見て、
何とか納得するモデルを作り上げる事は、非常に難しく、
ill condition で有ると言っても過言では無いと思います。
 
MT装置数台とカードリーダとLP装置(と大量の汎用用紙とカード)
だけで、マージソートをしたり、マージをしたり、マッチングを
したり、帳票に出したりする様な、
非常に小規模な頃から、試行錯誤を経た末のモデルです。
 
すぐに思いつく手法が有る訳でも何でも有りません。
(これも、プログラミング的思考の一つだと思います。)
 
--------------
 
なにが言いたいかというと、
★移行星獣たちは、モデルを思いついた事が無い。
★移行星獣たちは、モデルを思いつく事がコボラーの専売特許だと
 思い込んでいる。
★移行星獣たちは、モデルを思いつく事が困難なのは、コボラーのせい、
 あるいは、コボラーが簡単に思いつく方法を隠していると思い込んで
 いる。
★だから移行星獣たちは、コボラーを非難する。
のでは無いでしょうか?
 
もし、そうだとしたら、その非難は的外れです。だれがやっても
それを思いつくのは困難で、初めに正しい事を思いつくのは不可能で、
コボラーにそのill condition をなすりつけるのは不当です。
 
さらに、別のより新しい言語、フレームワークでまた移行をしようと
考えた移行星獣たちは、
★オブジェクト指向とPCサーバー
という新規性と同程度以上の新機軸を見つける事が出来ず、
COBOLより昔で有るに違いない、単なる欠落に過ぎない関数型プログラミング
だなんていう物を持ち出し、移行出来るだけの成果を上げられない
のです。
もうその轍を踏んではいけません。心よりそう思います。

13814260 comment

dotkuwaのコメント: Re:コボラーを責めるべきでは無かったのでは無いか (スコア 1) 8

by dotkuwa (#3547827) ネタ元: プログラミング的思考を学ぶべき理由

>開発者の負担が大きいところにある。
>しくみがしょぼい
というのは、「お気持ち」だと思います。
 
COBOLは、
・NATIONAL項目と言いながら、2バイト文字しか扱わない
・NATIONAL項目で無い項目は、内部コードのBIT単位の操作を
 容認し、後で本当に困る
・(速度を本当に重視する目的での)C言語や、FORTRAN言語
 などと同様に、一直線のメモリをなめる事を許容しており、
 オブジェクトなど、それを許容し得ないやり方と共存が
 困難
だったり、どうしようも無かったですが、それであっても
「お気持ち」で非難されるいわれは有りません。
開発者の負担が大きい根拠はなんでしょうか?
特定の開発者のメンタルモデルと合わないから、合う物に比べて
負担が大きいとしたら、それは当然ですし、ほかの多数の
開発者のメンタルモデルと合っているのでしたら、それで
十分だと思います。
 
マイナンバーも「しょぼい」という「お気持ち」で非難される
べき対象で有るいわれは無いと思います。
特定のアプリケーションの極相として、大多数の開発者から
みて、メンタルモデルに合わない事になってしまう事は、
有り得ます。それを一言、「しょぼい」で切り捨てるのは、
一種のお気持ちやくざだと思います。

13814025 comment

dotkuwaのコメント: コボラーを責めるべきでは無かったのでは無いか (スコア 1) 8

by dotkuwa (#3547658) ネタ元: プログラミング的思考を学ぶべき理由

ソフトウェアに絡む組織の極相がコボラーの世界だった
のでは無いか?
それなのに非難してしまった人間が居る組織は、
その人たちが居なくなるまで、最適化にたどり着けない
事になっているのでは無いか?
 
コボラーとして一番こたえた非難は、
・大げさなコード化
で、次が、
・連番の名前(対応表を引かないと意味が解らない)
でした。
今から考えると、これらは、
・列挙と管理の分離
をやろうとしていたのだと思います。
 
まずマイナンバーを付け、それとの対応表を作り、
対応後のキー項目で管理をするやり方は、非難されまくった
コボラーの世界だと思います。
直感的には、管理する名前=列挙する名前とすれば、
もっとも「判り易い」ですが、長い時間が経ち、
違うメンタルモデルを持った人が管理者となった時、
その人の「判り易さ」を担保するために、
また初めからやり直し、過去との継続性が失われる事
でしょう。
 
コボラーを責めた人間に兵無し!
長い目で見た時に、判り易さ、管理し易さは、制限されざるを
得ません。そうなるのが極相ですし、どうすればそうなるか
を突き詰めていくと、コボラーの世界になると思います。

13813883 journal
日記

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

日記 by dotkuwa

1.プログラミング的思考を学んでいない人は、
  プログラミング的何か(ソフトウェア開発とか)
  に関わる際、自分のメンタルモデル無制限押し付け
  をする。
2.なぜならば、全くの初心者が出来る、初めに思いつく
  事は必ずそれだから。
3.プログラミング的何かについて、それなりに経験を
  積んだ組織は、そういうメンタルモデル無制限
  押し付けに対処するには、ゼロトレランスしかない
  と達観する。なぜならば、最終的にたどり着くのは
  必ずそれだから。
4.そ

13807864 comment

dotkuwaのコメント: 合わないメンタルモデル (スコア 1) 3

by dotkuwa (#3543607) ネタ元: 何でやってみないと思いつかないか?

・丹精込めて作物を作ったり、
・規律を持って運転をし続けたり
する事は、いくら凝りまくっても「オタク」とは言われにくい
と思います。
 
そして、逆に「オタク」は
・育たない、慣性を持たない
ものを対象とすると思います。これらを対象とするのは、
・育つ、慣性を持つ
対象を相手にする際の有利さを捨てる事になるので、
奇異の目を向けられるのかも知れません。
 
さて、
・人は育つが、ソフトウェアは育たない。
 一々事細かに何とかしないといけない。
・物は勢いを付けてやれば動くが、ソフトウェアに慣性は無い。
 一々事細かに何とかしないといけない。
のは客観的事実だと思います。
 
技術者は育たない物、慣性の無い物の面倒を見続ける事で、
間接的に育つのでしょうけれど、
合わない人は、直接的に人を育ててしまい、技術を圧迫し続ける
為、合いません。
 
さらに、そういう人々は、
・初めに大歓迎し、頃合いを見計らって、難題を課す。
行動を取りがちですが、
育つ相手なら良いですが、ソフトフェアはそうでは有りません。
初めの大歓迎は大量の技術的負債となり、育つ相手なら助けになる、
難題はソフトウェアを致命的に壊す事になるでしょう。
 
たとえ強化学習みたいな分野でも、そういう人が思っているような、
育ちは無いと思います。
(この点に付きましても、実際にいじったことが無いので想像です。)

13806687 comment

dotkuwaのコメント: デジタルトランスフォーメーション (スコア 1) 3

by dotkuwa (#3542852) ネタ元: 何でやってみないと思いつかないか?

※前回、「お気持ち」という言葉を使いましたが、これはどう使っても
 揶揄にしかならないと反省し、「メンタルモデル」に言い換えたいと
 思います。(「お気持ちや○ざ」の「お気持ち」ですから当然です。)
 (のそのそはい出して来たり、チチチと言ったりする方では有りません。)
 
今はやりの「デジタルトランスフォーメーション」という潮流には、
歴史があると思います。
 
1.恐ろしく高い汎用コンピュータの頃は、その値段自体が権限だった。
2.オープン化で安くなった所で、ソフトウェア開発に特化した
 メンタルモデルを持った人間(以下おたくと謂う)が、自身の
 メンタルモデルに無批判に設計をした。それがおたくの権力闘争むき出し
 の権力構造になった。
3.権力の専門家の人々が、「コミュニケーション能力」などの、おたくに
 不利な基準を掲げ、おたくを殲滅した。
4.さぁ自分らのメンタルモデルのまま、ソフトウェア開発が出来ると
 思い、「デジタルトランスフォーメーション」などの基準を掲げたが、
 あまりに、ソフトウェア開発から見て、不利なメンタルモデルなので、
成果が上がらない。
5.専門家に参画してもらえば良いのかも知れませんが、専門家は
 おたくなので、見敵なんちゃらの対象となり、出来ない。
です。
 
--------------
 
その意味からも、「テストを初めに書く」のは最悪だと思います。
テストを書いた人間のみのメンタルモデルのまま固定され、テストという
プログラムを書き始めるのですから、上記の歴史を繰り返すだけに
なると思います。
自由自在に、テスト(正しさへの道のり)からすら自由に、今の流行も
取り入れ、まず動くものを作るのが先で、テストは参加者全員の
メンタルモデルから見て妥当な意味のメタな言葉が固まってから
すべきです。テストは何にしてもコストがかかり、コストは固定化に
つながります。
 
--------------
 
初めに書くのは(まず「やってみる」のは)、
「クラス図」だと思います。クラス図のパブリックな名前にはよりメタな、
プライベートな名前にはキャラの被らない、定義された名前が、それぞれ
割り振られ、図全体が矛盾しない様に、それを作れば、
特定の人間のメンタルモデルからそれなりに自由になります。
(もちろん、特定のメンタルモデルで世界を支配しようとしている
 人間にとっては、面白くないものになると思います。彼ら彼女らとの
 闘争は、ソフトウェア開発の一部ですが、ここでは言及しません。)

13800153 comment

dotkuwaのコメント: 数に関して (スコア 1) 3

by dotkuwa (#3538490) ネタ元: 何でやってみないと思いつかないか?

メタな言葉の複数の意味の数ですが、
・滑らかなカーブにフィットさせるやり方の統計処理に
 なじまない。
 有史以来、その様な統計処理がわずかでも功を成した
 事が無い。
・「常識的に考えて」実際にやってみる前に思いつこう
 としても出来ない。
という条件が有ります。
 
多分ですが、
・かなり多いが、空気中の分子の数位の多さでは無い。
 もし、それ位の多さなら統計処理が可能。
・「複数の意味」は「人間のお気持ち」によって出来る。
 だから、設計でやってみる前に思いつこうとした人間
 のお気持ちに反する種類の事は思いつかない。
と思います。
 
もし、「権限」というメタな言葉の種類が10万個だったと
すると、男性の権力志向が1万、女性の権力志向が1万で、
それらの中にオタクの権力志向が、それぞれ幾ばくか含まれて
いる事になるでしょう。
 
もちろん、仕事で使うソフトウェアに性別や性向に関連
した意味を含めるのはまずいでしょうけれども、
実際にやってみる前には、つい、それらを含めてしまう可能性
もありますし、やってみる前に思いつくという点では、
ついそれらを含めてしまっても、許容すべきなのかも
知れません。(もちろん後で修正しないとですが。)
 
-------------
 
さらに、「開発」というメタな言葉の内に、
・失敗を自分のライバルにさせて、自分を優勢にする為の
 作業
という意味を持たせている人間にとって、
英雄的にシステム開発を成功裏に導く人間は、意に反する
事をしてお金を取ろうとしている背任者に見える事でしょう。
さらに失敗をなすりつけられようとしている人間からしても
背任者に見える事でしょう。
 
人間のお気持ちはそれだけ幅広いと思います。
さらに言うと、システム開発とは、「成功したシステム開発の
事である」という意味の数は、逆の意味の数より圧倒的に
少ないと思います。それを考えて、成功したシステム開発を
実現したい人は、謙虚になる必要が有ると思います。
しかも、一度システム開発を成功させてしまうと、次には
さらに多くの謙虚さを求められてしまう事になると思います。
 
ひどい話ですが、こちらの方が現状に合っていると思います。

typodupeerror

人生unstable -- あるハッカー

読み込み中...