奴隷法

入管法改正案、衆院を通過
https://www.sankei.com/politics/news/181127/plt1811270039-n1.html

次から次へと、悪法ばかりよくも思いつくものですの。

とりあえず、ヤフコメで見かけた擁護意見への反論を書いておきますの。

・介護や土建など、きつい仕事に日本人が就きたがらないから仕方がない
→就業したくなるまで待遇を改善するのが先
　それでやっていけないような企業は淘汰されたほうがよい。介護など福祉についても、料金そのものを抑えるのではなく、料金の値上げを社会保障で吸収する形にするのがよい。日本人にしろ外国人にしろ、誰かを奴隷にさえすれば済むという発想はもうやめよう。

・高度な技能を持つ人材限定だから、一般の労働者に影響はない
→うそ
　仮に優秀な人材だけを１００人いれたとして、その１００人がいなければその職に付けたはずの１００人があぶれて下層に落ちる。すると、下層でも１００人が職にあぶれて、さらに下の層に落ちる。この連鎖が、最下層で１００人が職にあぶれるまで続く。いれた人材が優秀であればあるほど、かえって全体に与える負の影響は大きくなる。

と書くと、対案は？と言い出す人が多いようなので、いちおう書いておくと、対案はこの改正案の廃止ですの。

なんというか、労働者から見てようやく売り手市場になって、さあこれから賃金が上がっていくぞというときに、どうして？　という気分ですの。経団連の人たちはみんな、正当な賃金を払ったら死んじゃう病気にでもかかっているのかしら？

巨人のあしあと

持っている本のタイトル（ピンク）、著者名、著者紹介　ですの。

とくに流れを感じられるようなリストにはなっていないのですけど、ソフトウェア見積もりとCodeCompleteの著者が同じだったのは驚きましたの。どちらも良書で、とくにCodeCompleteは最高の一冊なので、さすがという感じですの。 


Clean Architecture　達人に学ぶソフトウェアの構造と設計

Robert C. Martin/ロバート・セシル・マーティン(1952～)

コンサルティング会社を経営（Uncle Bob Consulting LLC. と、Clean Coders）

アジャイルソフトウェア開発宣言の共著者、FitNesseの作者

愛称：ボブおじさん 

SOLID原則をまとめた。Clean Architectureの提唱者

ソフトウェア見積り　人月の暗黙知を解き明かす

Code Complete 第2版　完全なプログラミングを目指して

Steve McConnell/スティーブ マコネル(1962～)

ソフトウェア工学教科書の著者

ソフトウェアエンジニアリングとプロジェクト管理の専門家

他に有名らしい本：ラピッドデベロップメント―効率的な開発を目指して

熊とワルツを　リスクを愉しむプロジェクト管理

Tom DeMarco/トム デマルコ（1940～）

70年代の構造化分析と構造化された設計の開発における主要人物の1人

有名な本：構造化分析とシステム仕様

ソフトウェアテスト293の鉄則

Cem Kaner/セム ケイナー

フロリダ工科大学のソフトウェア工学教授

ソフトウェアテスティング協会(AST)を設立

消費者保護擁護者としての立法業務（統一コンピュータ情報取引法、統一電子取引法の草案への参加など）を行った。

ユースケース駆動開発実践ガイド

Doug Rosenberg/ダグ・ローゼンバーグ

Iconixプロセスの提唱者。XPの最も激しい反対者の１人

（↑の本もIconixの本らしい）

レガシーコード改善ガイド

Michael C. Feathers/マイケル・C・フェザーズ

Object Mentor社勤務（コンサルティング系の会社？）

CppUnit、FitCPPのオリジナル開発者 

レガシーソフトウェア改善ガイド
Chris Birchall/クリス・バーチャル
広範なプロジェクトを経験後、ロンドンのガーディアン紙で、
シニアデベロッパとしてWebサイトのバックエンドサービスを担当

巨人の肩が高すぎてのれない

最近読んでいるClean Architectureの著者のRobert C. Martinさんが、Wikiを使ったテストツール FitNesseの作者さんでしたの。びっくり。FitNesseは以前、テストについて調べていたときに見つけて面白いなーと思ったツールだったのですの。

ソフトウェアの世界の有名人なのだから、なにかすごいソフトを作っていても驚くことではないはずなのですけど、いざ遭遇すると破壊力が高いですの。

そういえば、Winnyで有名な（？）金子勇さんを初めて知ったのは、NekoFightの作者さんとしてでしたの。

NekoFight
http://kaneko-isamu.la.coocan.jp/nfight.htm 

あんまり話題になった記憶のないソフトなのですけど、実際、とんでもない作品で。初めてみたとき、世間知らずなわらわは「ネットの世の中にはこんなものを作れる人がごろごろいるのかー」と、ショックを受けた作品でもありますの。

１０年くらい前、AIを作ろうとして、３層ニューラルネット＋バックプロパゲーションを勉強していて、難しすぎてぜんぜんわからなくて困っていたわらわの目に飛び込んできたのが、この文章でしたの。

 AIの方式は単なる３層ニューラルネットで、学習アルゴリズムは私独自のED法（誤差拡散法）です。

ED法は、バックプロパゲーションが実際の神経系のメカニズムとしてはありえないというのが気になって私の方で考え出した学習アルゴリズムですが、 学習速度が非常に速いのと、中間層を増やせば無制限に性能が上がるのが特徴のアルゴリズムです。私の方では、おそらく本物の脳みそ（前頭前野大脳皮質）も こんな学習アルゴリズムなんじゃないかと思ってますがもちろん確証は無し（笑）

ものすごく苦労しても理解できないものを、あっさり（？）超えていってしまう。こんな人がその辺にいるなら、わらわがやってもしょうがないのでは？と思ったものですの。

あとで経歴を知ってびっくり。ぜんぜんその辺にいないレベルの人でしたの。（原子力研究所で働いて、未踏ソフトウェアに参加して、東大大学院で教えてた人）

NekoFightは、そのうち注目されて解説でも出回らないかなと思ってずっと見ていたので、まさかの訃報に別の意味でもショックを受け。。

なんだかうまくまとまらない文章になってしまったのですけど、話を戻すと、技術書の内容自体ではなく、”人”について調べてみるのも面白いかなと思ったのですの。

テスト駆動開発の導入に際しての考え方 メモ

それまで自動テストを導入していない状態から、いきなりフルセットのテスト項目を想定してテスト駆動開発をはじめるのは大変で当然だと思いますの。

そこで思ったのは、次のようなステップで進めていけば始めやすいのでは？ということですの。

1. 要求を実現するための、シンプルなテスト項目だけで開発を進める
2. たいてい訪れる「実装中にうまくいかなくなって動作を検証したくなるとき」が来たら、その内容をテスト項目として追加していく
3. あらかた形が出来てきたら、テスト項目を増やしてフルセットに近づけていく

おそらく、いきなり網羅的なテストとか、異常テストとかを盛り込んで始めるのは、慣れた人でないと難しいのではと思うのですの。

というか、実装前にクラス/メソッドレベルで完璧に設計が出来ているというのは非現実的なので、実装しながら問題点に気づいてあれこれ変えて形を作っていくことを考えると、こういう感じでないとロスが大きいと思うのですの。

ただ、試してみたわけではないので、いまのところ空論ですの。

これまでの議論から必然的に導けるのは、コンポーネントの構造をトップダウンで設計するのは不可能だということだ。コンポーネントの構造は、システム 設計の際に検討するだけのものではなく、その後もどんどん変わっていく。

Clean Architecture 達人に学ぶソフトウェアの構造と設計
第14章＞トップダウンの設計　より