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

dotkuwaさんのトモダチの日記みんなの日記も見てね。 アカウントを作成して、スラドのモデレーションと日記の輪に参加しよう。

13773056 journal
日記

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

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

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

13667026 journal
日記

dotkuwaの日記: テストと力 1

日記 by dotkuwa

通常、仕様を話し合う時、核心をいきなり言うと、
どんな人でも5割の確率で「だめだ」と言います。
これは人間の根源的な性質だと思います。そして、
その話し相手が権限を持った人なら万事休すです。
 
なので、通常はぼかした了解事項から言質を取っていく
(もちろん双方良し、五分の分かれで有る必要は有ります。)
のが通常です。
 
しかし、
・普通のテストで無い、素晴らしいテストがあり、
・それを初めに書くと、先々が良くなる。
というテストがもし有るとするならば、それは、
・もしそれを否定されたら万事休すどころで無く、それ
 以降、息を吸う事も出来なくなる位の打撃になる
様な知識だと思います。
 
それを「初めに」大っぴらに出来るという事は、すなわち、
・仕様を話し合う必要のある、どの関係する人より権限がある
という事と同義だと思います。
その様な人は、会社なら執行役員以上だと思います。
しかし、執行役員はそれに見合う責務を持っていて、1つのテストに
かまけてなんかいないと思います。
 
つまり、
・素晴らしいテストを書ける人
即ち、
・(会社で言う執行役員程度の)権限を持ち、責務は持たない人
です。
素晴らしくて当たり前だと思います。

13653085 journal
日記

dotkuwaの日記: 思いつく方法 4

日記 by dotkuwa

自分は昔からずっと、「思いつく方法」を教わっていません。
だから、プログラミングでは写経とかでしか学べませんでした。
 
プログラミングは写経で十分だと思いますが、仕様を思いつく方法
はそれでは不十分だと思います。
・まず一般に出回ることが無い。
・プログラミングと違い、大きな全体は小さな部分の集合であると
 割り切る事も出来ない。
・すでに有る(やっと手に入れた)実際に成った仕様を写経しても、
 自分が思いつく足しにならない。
からです。
 
実際の所、
・(一階論理や高階論理を含む論理の)階位を制御する
とか言ってしまいましたが、実際何なのか分かっていませんし、
下手な事を言うと、致命的な事を言ってしまいそうです。
だから、なかなか日記を書けませんでした。
(ただ、プログラミングで命名が重要で困難なのは、これが関係して
 いるとは思います。一階で満たされているプログラミング言語で
 希少に顕れる高階の兆しです。)
 
ですが、あえて言いますと、
・仕様の「思いつく方法」は、階位の固定では無く、階位の変動に
 よって得られる。
・階位の変動に一階を含めないと、思いついたことが接地されず、
 理論倒れに終わりやすいし、高階のみの変動では天才的な何かが
 必要になる。
と思います。
 
試作をした上で、思索し文書化する、を繰り返す。のが、
仕様の「思いつく方法」では無いでしょうか?
とすると、試作が出来ない(プログラミングを書いてテストが出来ない)
人は、仕様を思いつくことが出来ないと思います。
(プログラミング無しに無理やり一階論理を習得した人を知って
 いますが、それが出来た人は外に居ません。一階論理を習得するには、
 プログラミングが最適です。)
 
それっこそ、(仕様のレベルでは)意味の全くないコピペをするしか
無い要員になるのでは無いでしょうか?
(プログラミング無しに無理やり一階論理を習得した人は、思いつくこと
 が出来る人なので、実際には一階論理を習得していさえすれば良いの
 ですが、はっきり言って、その人は自分用のプログラム言語を自分の
 中で作った「だけ」に過ぎない様に見えます。その様なことはなかなか
 出来ないので、やはり早道は既存のプログラム言語でのプログラミング
 の習得です。)
 
いままで、自分の周りでは、
・設計は設計のみから作るべき(階位は固定すべき)
・これは大変だがやり遂げないといけないし、そのチャレンジは、
 成果として認める
というのが主流でした。
でも、あまりに大変過ぎてだれも到達できていません。
ポンチ絵などは、自然と階位の変動を促す技法なので、良いのかも
知れませんが、チャレンジには成り得ません。
 
普通にプログラミングが出来、実務を経た人が、試作しながら、
文書化するではダメなのですかね~。

13615506 journal
日記

dotkuwaの日記: 素晴らしい技術の在り処 4

日記 by dotkuwa

・未分の関数たち(シグニチャに囲われていない関数たち)を
 「上から眺める」プログラムが操作するプログラムを作る。
とか言っても、
たしかに、
・置いてきぼりを食った人間(コボラー)が、自分だけで何とか
 しようとした結果ひねり出した、クレオール。
・たまたまうまく行っただけの職人芸。
だとしても、おかしくありません。
そして、そのやり方は、
・「調査数か月、修正数行」になり得ます。(そうなった事が自分も
 何度も何度も有ります。)
 
しかし、そうではない「素晴らしい」新しい「技術」は、
・出来る、実際に講義を受けて納得した。
という意見と、
・(自分の様に)いくらやっても出来ない、自分の理屈では、
 土台から不可能としか結論付かない。
という意見が有ります。
 
違いは、そしてその魂の在り処は、
・細部まで定義された教材の有無
に有るのでは無いでしょうか?
 
もしそうなら、「素晴らしい」新しい「技術」を
する場合、
・プログラマーに細部まで定義された教材級の文書
 交付しないのは違法
とし、必ず交付する様にした後に新しい
技術を適用するべきです。
 
そういう文書の無い(置いてきぼりを食った)人間には素晴らしい
新しい技術をする余地が無いのです。
(実際に自分はそうです。ですので、テストが出来るのはプログラムが
 半ば組みあがった後です。)
 
大多数の人間は(今、その様な資料にアクセス出来るつて
を持たない人間なら、将来的にまず100%)置き去り側になります。
他人ごとでは有りません!!!!!

13606664 journal
日記

dotkuwaの日記: プログラムの新しいカテゴリー分け 4

日記 by dotkuwa

プログラムは、
・TDD可能プログラムカテ
・TDD不能プログラムカテ
に類別できるのでは無いか?
 
TDDを推進している人でも、TDDが出来ない部分もあるという
のは、自ずからゆっている事ですし。
 
そして、TDD可能プログラムカテは、
・簡単
・現在の教育で、普通に優等生だった人はだれでも、
 トレーニングを積まなくても、TDD可能プログラムカテ
 は理解出来、率先して作り出すことも可能
・だから、TDD可能プログラムカテに関しては、
 トレーニングコースなど不要
なのでは無いでしょうか?
 
トレーニングが必要なのは(陽にどういう分類の物に
なるか不明ですが)TDD不能プログラムカテで有って、
ゆえに、
プログラミングのトレーニングとしてTDDを使うのは
自己撞着ではないか、ないか、ないか!!!

13586739 journal
日記

dotkuwaの日記: 微視のソフトウェアプロセス 4

日記 by dotkuwa

品質マネジメント国際規格なんて、自分らにとっては、
・バブル期に審査員が実務のあらゆる方面に喧嘩を売っただけ
の活動にしか思えません。さらに事実としてそれ以外の影響を
受けていません。
 
休みで暇なので少し調べてみた所、なぜかそういう規格は、
「実際のプログラム作成」の所を測ったように迂回している
事が判ります。
まるで金属の品質を評価するのに、金属の周りの温度、湿度のみ
でしている様なものです。
金属の品質なら、表面を磨いて顕微鏡で見るとかするべきだと
思います。
 
ただ、ソフトウェアの品質を、プログラム自体を微視的に見ても
測ることが出来ないのも歴史的事実です。
「関数当たりの行数」だとか「コメントの文字数÷全体の行数」
だとかです。
 
しかし、ソフトウェアを作成する微視的なプロセスなら
もう少しましになるかも知れません。
・テストを書くプロセスの前に、アーキテクチャーを決める
 プロセスを置く。
だとかです。
#こう考えると、「テストを初めに書け」という提案は、
#微視的なソフトウェアプロセスに関する嚆矢だったの
#かも知れません。
この場合のアーキテクチャーは、
・高給取りがプロジェクト統制の為にする、すごい行為
では無く、
・技術的ネタ(仮想DOMとか)の検証(入力値+1を返すだけ
 とか)の様な卑近な行為
です。
これをするだけでも、テストによる柔軟性(保守性、移行性など)に
対する重大な侵害を防ぐことが出来ると思いますし、
各人がアーキテクチャーに対する理解を持つ事は、プロセス改善に
とって有意義だと思います。

13573487 journal
日記

dotkuwaの日記: 切り捨て 3

日記 by dotkuwa

「駅前のーケーキ屋に。」
「あーあそこ。」
「新製品のケーキがあった。」
「へぇ。」
という会話は、世界を切り捨てています。
駅前のケーキ屋のみを持ち上げて、それ以外を
黙殺しています。
路傍の石のごとくとか、対比できる物質世界の別の
ものとしてどころでは無く、完全な無視です。
 
制御に関するプログラムもまさにそうです。
様々な責務のAPIを参照しつつ、特定の可能性のみを
優遇し他を捨て去ります。
 
全ての可能性を捨て去らない場合、考える手間は
べき乗やそれ以上の耐えられない場合の数になる
でしょう。
それに対して、プログラムの1行1行で可能性を捨て去れば、
考える手間は、対数のべき乗になったりするでしょう。
 
---------------------
 
切り捨てが功を奏するためには、
・世界が広い方が良い。多様な方が良い。
です。
その方が切り捨てた際の効率がアップします。
 
なので、制御に関するプログラムは関数ではダメです。
理由は、
・関数は単一の責務とか、その責務に見合うだけの比較的
 少量の入出力が好まれるが、
 制御に関するプログラムは、多くの責務を参照すれば
 するほどお得だし、その責務に見合うだけの(形の上から
 言うと)億万の相異なる入出力が必要になる。
・多くの責務をまとめ上げる為に、変更に対して開いていない
 といけない。
からです。
 
---------------------
 
失敗に対する早目の切り捨ても重要です。
そのままでは致命的な結果を呼ぶ、人間の誤った入力は、
何一つ処理をする前に、切り捨てるべきです。
それをするためには、単一責務ではない、雑多な責務
(「制御」という責務と言おうとしましたが、自分は、
 プログラムには上位概念も下位概念も無いと言い続けて
 いるので、駄目です。責務が自然言語だったら良かった
 のですが。。。)を、人間の勝手さを面倒見るという
目的だけに、雑多に並べる事になるでしょう。
 
早目の切り捨ての為には、例外も必要でしょうし、nulも
必要でしょう。早目の切り捨てをしないからnulに引っかかって
身動きが取れなくなるのでしょう。

typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...