ポピュリズムに支えられた人間は，批判されると変な笑い方をする。
あれ，すごく不自然に見えるんだけど，なんなんだろ？空気読めない子ちゃんなんだろか。
ともあれ，個人的な答えはもちろん出ていて，あの変な笑いが誰に向けた笑いかといったら視聴者なんだと思う。ポピュリズムに支えられた人間の生命線は有権者の顔色だから，ま，そうなるわなと。
個人的には単にキモいとしか思わないけれども，あれにコロっとやられる人もいるのかもしれないな，とかつらつら。
話を敷衍したくはないけれど，もうね，日本の上流は悲しくなるほどダメだと思うんですよ。
東芝ソリューションではないけれど，某社では，プロマネや設計担当に新卒2年目なんかをアサインして下請けに丸投げしてたりする。で，当たり前のことながら，当のプロマネや設計担当は，システムについて何も知らない。こんなのいつも見る光景で，何も珍しくない。御用仕事では特にそう。素人を相手にしてるのと変わらないから，関わりたがらないベンダもそれなりにあったりする。
今時はこのギョーカイも大手指向みたいだけれども，技術者として10年後・20年後を考えるなら，その選択肢はないと思う。もちろん個人的にだけれども。
もう，そんだけ。あほらし。
こちらを読んでてつらつら。ま，ずいぶん昔から言われていることなんだけれども。
These people—and we’re going to talk about three specific types in a minute—passive-aggressively block innovation from happening and will suck the energy out of any organization.
Three Types of People to Fire Immediately - Businessweek
ここでは，技術刷新を目的とする会社では，次のような人を不必要な人間としているようです。
個人的には，3番目は本当に困ったちゃんだと思う。プログラマを初めとした技術者は，ある程度自分の専門性にプライドを持っているものだけれども，それが行き過ぎて，全てを知っていると思い込んだ状態でいると驚くほど成長しない。開発者は常に自分の技術が発展途上だと思っていないといけない……と，あたしは思っているんだけれども，手持ちの技術を吐き出すだけで開発業務を回せると思っている人は，新人・年配を問わず満遍なくいるような気がしています。そんな手持ちの技術は，1年も経てばあたりまえの技術になり，ひいては過去の技術になってしまうのに。
そして，このような心性は，会社を初めとした開発組織全体を，ゆっくりとしかし確実に侵食する。放置しておくと，その人間だけでなく，組織全体が「オレ様被害者」や「皮肉屋」や「知ったかぶり」ばかりになってしまう。
もっとも，引用記事では，そのような人間は即刻クビにすべきだ，としているけれども，再生することもできると思ったりもする。ひとつの方法は，技術に対する自尊心を徹底的に壊すこと。発展途上であることを思い知らせることです。これは，言葉で「お前はダメだ」とか言うのではなくて（そうすると被害者ぶるから），組織全体の技術水準を上げて，その人を技術の土俵内で明確に下位に位置づけることに尽きるのだと思う。荒療治だけれども，実際にあたしが知っているところでは，それで復活している人もいる。
こゆ面倒なことをしないで，あっさりとクビにするところは欧米流といったところなのだろうか。よく分からないけれど，そんな感じ。
どうでもいいんだけれど，宮根誠司の隠し子話とか。
こんな話、話すタイミングがなかったこともありますが、結婚も含めプライベートを話してこなかったのは、やっぱりA子さんと娘のことがあったからですよね。ぼくがこういう仕事をしている以上、自分が話すことによって、多くの人が知ることとなると、カノジョの人生にデメリットが生じてしまうかもしれない。
宮根誠司 隠し子についてこれまで語らなかった理由とは？ （NEWS ポストセブン） - Yahoo!ニュース
この人は，非嫡出子（婚外子）がどれだけいわれのない不遇を受けるか分かっていない。社会的な差別はもちろんあってこれは，努力次第である程度緩和できるかもしれない。しかし，非嫡出子は法制上も不利益な取り扱いを受けている。
最近，大阪高裁で現行民法における非嫡出子の法定相続分に関する規定が違憲である（民法900条4号但書，憲法14条）旨の判決が出ているみたいだけれども，大法廷が開かれていない現状の法制において非嫡出子（いわゆる隠し子）と嫡出子の間には，生まれながらの差別がいまだにある。
つまり，「非嫡出子として産まれた」という事実だけでもって，「カノジョの人生」にはすでにデメリットが生じている。
以前も書いたけれども，この人は，いろいろな面においてモノを語る上で見識がなさ過ぎる。某所では，「認知しているから隠し子ではない」とも言っているらしい。なぜ人気があるのかいまだに分からない。
ちょっと受動意識仮説について調べていたのだけれども，たまたま弾さんの話を読ませていただいたのでつらつら。引用で扱っている書籍も読んだことがあるのだけれども，おおむねあたしも同じような感想です。ここでは，特に言いたいことも決めずにつらつら。
この受動意識仮説を支持する研究成果に関しては、本書の参考図書の一つでもある「進化しすぎた脳」もあわせて呼んでいただくとして、とりあえずここでは受動意識仮説が正しいものと仮定しよう。
すると、どうなるのか。
「私」は、不要となるのである。
「我思う故に我あり」ではなく、「我あり故に我思う」のであれば、「思う我」は不要というよりも「ある我」があれば自然発生するというわけだ。
404 Blog Not Found:書評 - 脳の中の「私」はなぜ見つからないのか?
受動意識仮説とコギト（cogito, ergo sum）の話。本にそう書かれていたから結びつけたのだと思うのだけれども，こゆのは極めて自己言及的な話だと思うんですね。後に及ぶ刑法の要否についてもそうだけれども，思想は既にこの道を通っている。刑事法学で言うなら，19世紀の終わりくらいからロンブローゾがそんなこと言ってる。ロンブローゾはダーウィニズムに立脚しているけれども，受動意識仮説もダーウィニズムの影響を受けているといっても言い過ぎじゃないと思う。
もう少し考えると，デカルトのコギト（考える我）は，二元論につながるわけだけれども，その前に意味するところは懐疑論との関係で「考えている私の実在は考えていることにのみ依存しているから，それ自体で存在しうる」とゆことだったのでした。で，これが受動意識仮説における「意思」と「行為」の前後関係とどういう関係にあるのか。ここに精緻な論証が必要だと思うんですね。個人的な理解では，コギトはコギトとして何にも依存せず存在しているのだから，（それに意味があるかはともかく）身体的な行為が前後しても影響を受けないと思うんだけれど，どうなんだろ。
ともあれ，こゆのは自己言及的な話だから，あまりいろんなとこに敷衍しない方がいいのだと思う。
自己言及的とゆのは，その答えを既に内包した形で問いを立てているということです。これらの説を受け入れる（あるいは反論する）ということは，その問いと答えの関係性に加担するということだ，と言い換えてもいい。受動意識仮説であれコギトであれ，こうした話の自己言及的な態度について，「読む人」は少なくとも自覚的である必要があるのだと思う。
受動意識仮説は，ロボットを作るための心のモデルを先取りして，後から問いの形を整えた感がある仮説だと思っていたりします。まるで，この仮説のように，答えが問いを作るかのような運動です。そうじゃないならごめんなさいだけど，そうかどうかは誰もわからなかったりする。心と同じように。
あけましておめでとうございます。新年のご挨拶ついでに，正月休みで考えていたこととかつらつら。
某所で，日本伝統のウォーターフォールモデルが複雑なシステム開発のボトルネックになっている，とかいった話があったんだけれども，いかにも SIer さんらしい考え方だなぁ，と思ってしまいました（某所の某氏はもう SIer さんじゃないらしいけれど）。お客さんがいるソフトウェア開発において，要求を実装に落とし込む手法として，ウォーターフォールモデルは論理的に整合性が取れている手法のひとつだと，あたしは考えています。
現在のソフトウェア開発においては，よっぽど自転車操業でやってるとこやお客さんのいない開発でもない限り，ウォーターフォールモデルは一般的な手法として採用されています。そして，これは強調しておきたいのだけれども，失敗したプロジェクトがウォーターフォールモデルでドライブされているのと同様に，問題なく終息している大多数のプロジェクトもウォーターフォールモデルで見積もられ，作られているということです。失敗したプロジェクトがウォーターフォールモデルで作られていることは，必ずしも失敗の原因とはならない。
[more ...]個人的なプログラムの構成方針とかメモ。
ひとつのプログラム（ライブラリ・実行モジュール）は単一の開発言語なりパラダイムになりに則っている必要はないので，適材適所で使い分けるわけだけれども，ある程度使用場面をカテゴライズしておくとすっきりすることがあります。どゆ場面でどゆ開発環境を前提にすればいいのか，ちと検討してみます。
例えば，まともな画像処理のプログラムを作る場合，基本処理を LL（Lightweight Language）で書くようなことは普通しません。ある程度処理内容が固まっている場合（実験的な実装ではない場合）で，パフォーマンスを求める場合は，アセンブリで書くこともある。また，技術者がユーザになる場合の実装（ライブラリになることがほとんど）では，Python や Ruby のバインディングを作っておくと便利になることがあります。.net な環境はアンマネージドな DLL とリンクしやすいので，Windows 環境では C# でインターフェイスを作ることもできる。
[more ...]このサイトも運営を始めてから，9年目を迎えました。毎度のことながら，これもひとえに読んでくださる皆様と，あたしの惰性の賜物でございます。ありがとうございます。
今年の qune は，去年の今頃にも書いた通り，プログラミングネタでは少し業務的な話に重心を置いて書いてきたつもりでした。そこで分かったことは，世の中のリソースには，プロとして実装する技術について書かれたものが，かなり少ないということでした。いや，プロが偉いとか，アマがダメとかいう話ではなく，プロのプログラマなり設計者なりは，それなりに特別な配慮に基づいて実装しているところがあるわけで，そゆものを扱ったリソースが少なかったとゆこと。
あたしは，小さなソフトベンダに勤めているので，技術者と呼ばれる人たちはあまり細かく分化していません。あたしの場合，もちろんプログラムを設計したり実装したりもするけれど，お客さんと話して要件を決めることもあれば，サーバ管理や社内システムの管理（勤怠管理，営業管理等々，社内システムは内作なのです），社内端末や外部ソフトウェアのライセンス管理もしています。新製品のための調査研究もしています。最近は製品開発が主になっているけれども，ぶっちゃけ超忙しい。そゆ忙しいところでは，効率的に仕事を回す工夫が必要です。実装に少し手間がかかるからといってその場で手を抜くと，後々取り返しの付かない大改修になることもある。そゆ場面のノウハウは，少なくともネット上にはあまり蓄積されていない感じがする。そゆことが分かりました。
で，来年はどうするかなんだけれども，今年の方針を進めて業務的な方向で書こうか，それとも趣味的な方面を扱うか，ちょっと迷っているところがある。業務的な話は，現在ネットの技術ネタでボリュームゾーンとなっている趣味プログラミングから外れるところがあるもんで，需要に応えられるか不安なところがある。いずれにしても，あたしもいいオッサンになってきたので，入門的な話は控えめに，ある程度分かっている人を対象にしようかと思っています。
一方で，昨年サイトを再デザインしているといっていたものの，いまだにその目的を達することができないまま，ずるずると書き散らしています。来年こそはどうにかしたい。
なにはともあれ，9年目の qune もどうぞごひいきに。よろしくおねがいいたします。
こちらを読ませていただいて。
なんでこんなことを思うようになったかというと、数年前と比べると意見をガラリと変えるブログやソーシャルブックマーカーをチラホラ見るようになったからです。
20代中盤と比べると30代だと恐らく社内での立場が上昇していてそれまでなかった視点を持ったのだろうとか、「何故できないのか」というような問題の真相を垣間みたりして経験を積んだのかなと思った事例もあります。「以前よりも保守的な表現になったなぁ」と。
その一方で、「ネット上で声が大きい人」というのは、ある程度定着している感があり、「声の大きい人の平均年齢が徐々に上がってないか？」と思います。
Geekなぺーじ:上昇するネットモヒカン濃度
直接名指しされたことはない（と思う）けれど，あたしもいわゆるモヒカン的な位置付けにされていたところがあるので（今もされてるかもしれないが），なんつか，微妙な気持ちになってしまいました。また，このブログで書いてることが以前と比べると保守的な傾向にあることも，自分で認めていることだったりする。ま，こんなところで，クリリン的な内省をしても仕方ないんだけれども，そのことでつらつら。
自己弁護するわけではないけれども，特にソフトウェアに関して論調が変わってきているのは，引用で指摘されている通り，まずもってこれが飯の種として定着しているから，とゆのが大きい気がしています。趣味や遊びなら時間もお金も（あるだけ）かけられるけれども，職業でプログラムを設計したり書いたりしている人は，かなり大きな制限の下で日々の業務をこなしていたりする。時間は自分の給料との折り合いになるし，できるものの良し悪しは自分ではなくお金を払うお客さんが評価する。
あたしは，それでもある程度社内で自由にプログラムを作らせてもらってるし（他の人からは，論文読んだり画像をこねくり回したりして変なことしてる人に見えてるだろうが），趣味でもプログラムを書いているので，このブログで工数的な制限をあまり表に出すことはないと思っています。けれども，納期の厳しい現場では，かなり時間や費用に敏感だったりする。そして，プロではそゆ視点が非常に大切になる。その視点が入ったのが，まず一点。
[more ...]大した話じゃないんだけれども，NPI（Named Parameter Idiom）について少し。NPI というのは，クラスの振る舞いを決定するパラメタにメンバ変数を使って，setter/getter で制御しようとゆイディオムです。普通は，関数の引数で挙動を決めることもあるけれど，メンバ変数を使うとゆわけ。もっとも，こゆのは Command パターンやファンクタなんかを使うときは，大体そんな感じの設計になるわけで，改めて名前をつける必要もないくらい，みんながやってることなんですが。
で，そのイディオムの中で，setter で自分自身の参照を返すイディオムがあります。こんな感じにする。
class some_object {
public:
some_object& x(int x) {
x_ = x;
return *this;
}
some_object& y(int y) {
y_ = y;
return *this;
}
void execute() {
// some executions...
}
private:
int x_;
int y_;
};
こうすると何が便利かというと，次のように値をセットできるんですね。
some_object obj; obj.x(12).y(249).execute();
たしか，boost::program_options もこんな作りだったと思うけれども，要するに戻りを使っていくらでも引数を設定することができて，最後に実行することができる，と。洒落た方法なので，やりたがる人も多いかもしれない。性能的には，通常の setter（戻りが void の関数）と大して違いはないので，単純にセマンティックスの問題です。
もっとも，この方法を採る積極的な理由はあまりないわけで，ま，通常 void 型を戻りにしている setter だったら，折角なので自分を戻してみるか，くらいの理由しかないんだと思う。同様に，この手法を否定する積極的な理由もあまりないわけで，強いて言うなら，setter が例外を投げる時，通常のコードベースでステップ実行するデバッガでは，どこで例外が投げられたか見つけにくい，とゆもんがありそうな感じ。これも，機械語ベースでステップ実行すればいいだけなので，大したディスアドバンテージでもないんだけれども。
個人的には，こゆセマンティックスになったからといって特段便利になった感じもしないので，使うことはないだろうな，とは思う。setter で自分を戻すことが，関数それ自体の「意味」として成り立っているのか微妙なところだし。純粋に好みの問題だとは思うけど。
ま，ただそれだけ。
