何のために勉強するのか

技術者は何を目指して勉強しているのかにコメントを書こうと思っていたのですが、
アンチスパムフィルタに阻まれたので記事にすることにしました。

ネガティブな内容では無いと思うのですが、
該当箇所がさっぱりわかりませんでした。



んで何が言いたかったのかといいますと、
自分はどれに当てはまるのかな？って話です。

自分の発想はどちらかと言うと画家寄りで、
「自分の生涯の作品を完成させたい」が為に勉強している節があります。

既に基本構想や設計はできていますが、
今の自分には至らないところだらけです。

そんな壮大な夢を妄想しながら日々を送っていますが、
それで有名になりたいかと聞かれると必ずしもそうではないのです。

有名になるのはあくまで副作用であって、
作品を作り上げることそのものに大きな価値があります。

それに万人受けするものより、
むしろごく一部の人に強い感動を与えるような作品のようなものが好みです。

作品が完成すれば自分としてはほぼ満足ですが、
自分以外の誰か一人でも認めてくれたならそれはもう大満足なのです。



そんなことは綺麗事で、
本心ではどれかに当てはまっているのかもしれません。

ですが、自分はその綺麗事を通して生きて逝きたいのです。

才能とは何か

プログラマーは画家と同じように、
希少ではないにしろ才能を求められる職業です。

プログラマーに必要な才能の面白いところは、
既に目に見えて何段階かの才能のポイントが判明しているところです。

• 構造化プログラミング
• 順次
• ポインタ・参照(カテゴライズとして間違っていますがとりあえず)
• 反復
• 分岐
• オブジェクト指向
• オーバーロード
• 継承
• オーバーライド
• ポリモーフィズム
• 隠蔽
• 関数型言語
• 再帰関数
• λ計算
• カリー化(これも微妙ですがとりあえず以下略)

まあ色々羅列していますが、

簡単にまとめる抽象化に必要な技能だということです。

高い次元の抽象化には高い才能が要求され、

下の次元では分かったのに理解できないのでわめき散らす人が現れます。

これもピーターの法則の一種でしょうか。

その人は無能レベルに達したといえるので、

一段階下に降りてもらって上の次元に行ける人から離してあげましょう。

そうすればお互いが幸せです。

って、ピーターの法則の話がしたいんじゃありません。

じゃあ才能が無ければ諦めるしかないのかという話です。

ここがややこしいのですが、

才能がなくても適切な学習を行えば習得できる可能性はあります。

しかし、それがいつになるのかは誰にもわからないのです。

あまりに現実的でないため、

よほど高みを望む意思が無ければ別の道を模索するべきなのです。

どうせすぐに次の壁が登場するでしょうしね。

分かりやすく言うなら、

新たに習得したい技能に１００通りの方法があるとします。

(実際には無限に近い手法があるでしょうが、ここでは絞ります。)

パターンそのものは１００通りでも、

そのうちのどれで習得可能かに大きな個人差があると思ってください。

自分と相性の悪い方法を取ると、

習得に失敗します。

で、才能のある人は１００通りのうちの８０～９０通りくらいで習得が可能です。

よほどひねくれた習得方法を取らない限りは簡単に到達します。

普通の人は４０～７０くらいです。

運が良ければ一発で到達するかもしれませんが、

場合によっては何回も道選びに失敗することもあるでしょう。

才能が無い人は１～３０くらいです。

王道と呼ばれる方法では無理かもしれません。

もしくはまだ人類が発見していない方法でないと習得できないかもしれません。

たまにもの凄く運が良ければ、

壁を乗り越えて習得できるかもしれません。

また選んだ道によって、

他の技能を覚える通りが減ったり増えたりする点にも注意しないといけません。

何事もいくらでもやり直せるというのは間違ってはいませんが、

同じやり直しのように見えて実はルートが変化しているのには要注意です。

それまでは行けたかもしれない道が、

実は消えてしまっているやもしれません。

(COBOLの人がオブジェクト指向を覚えにくい割に、初学者はすんなり入るなど)

ああ、道に罠が仕掛けられている可能性もありますね。

悪書とか誤った知識を持った先輩や上司と最初にぶつかってしまった場合です。

悪書はまだしも、先輩や上司は己の不幸を呪うしかありません。

まとめます。

あなたの進みたい方向にある道は無数にあります。

才能のある人は適当に選んでも前に進めます。

普通の人は道をよく考えて選ぶ必要があります。

才能のない人は本当に進みたい方向なのかをまず考えてください。

才能が分からないのであれば、

あなたが選んだ道の中で、

誤ったと感じたものを挙げてみてはいかがでしょうか。

他の人と比べて転んだ数が多ければ、

ちょっと注意した方が良いのかもしれません。

でも習得の仕方によっては、

前の道が通行可能になることもあります。

あなただけの進み方を見つけるべきでしょう。

あれ？

結局大したこと言ってないですね。

バカになるオブジェクト指向プログラミング講座(ドラフト版)

※この記事を読んでも、OOPについて理解は深まりません。嘘だらけでバカになります。



序章　混沌の時代

その昔、
ソースコードに秩序は無く、
そこにあるのは混沌でした。

少しでも速く、
少しでも小さく、
そのために無数の“goto文”と“グローバル変数”が偏在していました。

このようなソースがそれこそ無数に…
【N88日本語BASIC (無茶苦茶な行数に飛ぶIF命令)】

【N88日本語BASIC (グローバル変数がいっぱい！)】


ああ今の時代、
“Hello, world!”をコンパイルしただけでも何KBになることか…！

“goto文”と“グローバル変数”はプログラマーの理解を阻害し、
ソースコードは誰にも触れないものと化していく…

そんな時代でした。



2章　“構造化プログラミング”の時代

混沌に一筋の秩序をもたらす者が現れました。
その名も、勇者“エドガー・ダイクストラ”。

彼はソースコードの中を、3種類の論理構造に分けました。
そしてその論理構造を意識してサブルーチン化すれば、
ソースコードは理解しやすいものになると発表したのです。

• 順次
  【C言語　(順次改善前)】
  【C言語　(順次改善後)】
  
  
• 反復
  【C言語　(反復改善前)】
  【C言語　(反復改善後)】
  
  
• 分岐
  【C言語　(分岐改善前)】
  【C言語　(分岐改善後)】

“goto文” と“グローバル変数”はサブルーチンという壁に阻まれ、

限られた場合でのみ使われるようになりました。

(後にこの一部は、“例外”とか“静的メンバ変数”とかに名前を変えて姿を現します。
まあ、それはまた別の話です。)

この働きにより、

ソースコードに構造化プログラミングという秩序が生まれたのです。

3章　状態と動作

構造化プログラミングが普及するにつれ、
小さな混沌が芽生えることになりました。

それは引数の数です。

何も考えずにサブルーチン(以降は関数を記載)化すると、

自然と引数の数が増えていくのです。

しかしそれは、大きな問題にはなりませんでした。

引数を構造体にまとめておけば、
簡単に引数の数を減らすことができたからです。

【C言語 (引数を減らすサンプル)】

そしてこの構造体が、
ある種の状態を指していることに気がつく人がいました。

【C言語 (犬サンプル)】

これにより構造体の意味がハッキリしました。

状態(構造体)と動作(関数)が手を取り合った瞬間です。

4章　“関数ポインタ”

状態と動作は、
関数の引数型によって結びついていました。

しかしこのままでは、
状態からどのような動作があるのかまではわかりませんでした。

出力できるのか、
入力できるのか、
はたまたどこかと通信するのか、
それは関数の引数をチェックしていく必要があります。

また動作から同じ状態を使う動作がどれだけあるかもわかりません。

せっかく同じ状態を使うにも関わらず、
動作と動作を組み合わせるにはその動作の存在を*知っている*必要があったのです。

【C言語 (犬サンプル改善前)】

しかしある人は気が付きました。

ある動作を行えることそのものが状態なのではないかと。

つまり動作も状態の延長線上として捉えることができると考えたのです。

関数ポインタを使えば、
状態の中に関数ポインタを入れて動作と一体化させることができます。

【C言語 (犬サンプル改善後)】

今度は、状態と動作が一心同体となったのです。

5章　“オブジェクト指向プログラミング”の時代

※ここからJavaで書く予定。

状態と動作はひとつとなり、
プログラミングに秩序の光が差し込みました。

でもこれはきっかけにすぎません。

これをさらに応用・発展していくことで、

新たな可能性が生まれました。

• オーバーロード
• オーバーライド
• 継承
• ポリモーフィズム
• デザインパターン
• 【とにかくいっぱいサンプルDA！】※優先度を決めてTOP5くらい出せばいいかな。

ここにオブジェクト指向プログラミングという抽象化は、
ひとまずの完成を見せたのです。

終章　そして“関数型言語”の時代へ…

オブジェクト指向プログラミングの抽象化は見事なものでしたが、
それだけでは上手く抽象化できない問題もまだ残っていました。

関数を呼ぶ順序がある程度決まっているものや、
ループ処理の中身だけ後から変更したい場合です。

データベースのオープン・クローズはほとんどセットと言ってもいいですが、
その途中の処理は多岐に渡ります。

オープン～クローズまでの流れを関数化するのは難しかったのですが、
仮にオープンとクローズの間の動作を関数の引数で渡したをしたらどうでしょうか。

今まで複数箇所にあったオープンとクローズが１箇所にまとまります。

オープンやクローズの問題に直面したら、
そこだけに注力すれば修正することができるようになるのです。

ループの場合も、
ループの中身を関数の引数で渡せたら…

仮に超高速ループを誰かが開発し、
中身を引数で渡すだけでその恩恵を受けられるとしたら…

何が言いたいか？

関数に関数を渡せるべきであり、
関数は関数を返せるべきだということです。

これを簡潔に記述できるならば…それが関数型言語の入り口です。

新しい秩序の光が、
あなたにも見えてきませんか？

終わり



※要望があればちゃんと書くかも。…誰もいないよね？

政治がソフトウェアの品質を上げることはあるのか

あるバッチファイルを作っていたときのことです。

そのバッチの要件で多重起動禁止があったのですが、
お客様から提示されたロジック(psで調べる)では満たせないことが分かりました。

(確かflockはまだ無いバージョンだったので)
mkdirで生成に失敗したら起動中のバッチがあるとみなすのはどうかと説明しました。

そのときのリーダーはそれを踏まえた上で、
お客様の面子をとってpsでの不完全な排他の実装を命じました。



いわゆる、
政治的事情による判断というやつです。

ソフトウェアの開発において政治が深く絡むパターンとしては、
論理的に正しいことを“無理が通れば道理が引っ込む”で捻じ曲げるために使われます。

ソフトウェアが論理的に正しくなくなるということは、
動かなくなるか品質が下がるということです。

確かに、
自分自身で使うものを作っているので文句を言うなというのは理解できます。

しかし、
大金を使って作っているソフトウェアの品質を下げてまで通す価値があるものなんでしょうか。



きちんと話せば分かってくれるという意見もありますが、
デッドラインを読み終えた今となっては信じられません。

世の中には自分の思い通りにいかなければ全てNGという人種がいて、
その人種が権力を持っている場合は逃げるか排除する以外の方法は発見されていません。

つまり政治がソフトウェア開発の問題になっている時点で、
そんな人種とぶつかっているということであり、
自分から見たら詰みの状態なわけです。



まとめると、
政治色が強ければ強いほど、
そこに対して開発するソフトウェアの品質は低下します。

パッケージを導入したとしても、
その使い方で政治が発生してパフォーマンスを低下させます、

官公庁に品質の良いソフトウェアを提供することができないのは、
彼らが政治で物事を解決しようとするからではないでしょうか。

エビデンスをいつとるか、今でしょ！

SIerが実施する試験には、
誰も見ずに終わるであろうエビデンスという資料を残す必要があります。

オーソドックスなのは、

• ログファイル(要：該当部分のみ切り取り)
• デスクトップ画面のキャプチャー画像
• データベースのテーブル情報

でしょうか。

まあたまに役に立つこともありますよ？

試験仕様書に操作方法が一切明記されていないアホな場合とか、
エビデンスが試験仕様書の補完になっていたりします。

…いや、これは試験仕様書側に寄せるべきなんですけど。

とにかく何が言いたいのかというと、
エビデンスで発生するコストに対してのメリットが薄すぎるわけなんです。

お客様の精神衛生の値段にしては高すぎないでしょうか。



自分ならもう少しコストが低く、
そしてエビデンスのレベルが高いものを提案できないか考えます。

例えば、アマレココを動かしっぱなしにして試験するなんてどうでしょうか。

これならまずデスクトップ画面のキャプチャー画像を取る作業を軽減できます。

そして常にどこかに時間を表示しておくようにしておくことで、
ログとの整合性を確保します。

試験仕様書に試験の開始時間だけ明記しておけば、
わざわざ切り取って加工しなくとも良いでしょう。

データベースの内容なんかは、
コマンドでSQL打ってデスクトップに表示させて終わりとします。

SQLを実行した時間が正確に分かって信頼性もアップです。



もっとも、
問題点だってあるにはあります。

ひとつはパソコンの要求スペックが跳ね上がることです。

最近のパソコンは性能が上がってきていますが、
前世紀のパソコンを出されるとちょっと…

次にファイルサイズがアホみたいに肥大化することです。

ハードディスクがギリギリの場合にこの方法は使えません。

最後はお偉いさんがなぜか高く見積もる学習コストでしょうか。

ただニコニコ動画のゲーム実況者さんがお手軽に導入するツールです。

ソフトウェア作ったり扱ったりでお金を貰っている自分たちにできない道理はありません。



本当はユーザーインターフェースの検証に使うのが良いのですが、
まあこういうことにも使えるってことで。

LiveTimeBoardで遊んでみた

めもりくりーなーでいつもお世話になっている株式会社クロノスさんから、
LiveTimeBoardなるものが登場しました。

このアプリケーションに対するメタファーとしては、
場所に左右されないホワイトボードって感じでしょうか。

使ってみた感じが以下の通りです。

正面のめもりくりーなーの絵＋ふきだしは自分が描いたものです。

感想としては、
機能をギリギリまでシンプルにした業務用お絵かきチャットでした。

文字の挿入すら無いのは、
そういう意図的なものを感じずにはいられません。

ちょっとでも絵心がある人とない人とでは、
まったく違う印象を受けるのではないでしょうか。

自社のサーバーにログイン機能付きのお絵かきチャットを追加するのとどちらが特なのか、
その辺をご相談の上購入すると損をしないと思います。



ここからは余談ですが、
欲しいのはホワイトボードじゃなくて付箋なんだという方にはTrelloをオススメします。

英語ですが日本語入力も可能です。

FogCreekは相変わらずいい仕事してますね～の一言です。



…そんなこんなでオフィスにある身近なものが、
どんどん仮想環境に進出してきています。

もしもビジネスチャンスをお探しであれば、
まだ仮想化していない何かを探してみてはいかがでしょう？

意外な成功が待っている…ようなそうでもないようなです。

政治をプログラマーらしく考えてみる

今の政治は、
素人目には停滞しているように見えます。

どんなアクションを起こしても抵抗勢力が現れて、
結局本来の効果が失われた状態で動き出しています。

前に進んでいる感じがまったくしないのです。

こういうの何ていいましたっけ？

鶏と卵の問題？

いや違う…

囚人のジレンマ？

なのかなぁ…

デッドロック？

お、これはいけるかも？

抽象化してみよう。

if (policy.hasDeadlock()) {
    for (Deadlock i : policy.getDeadlocks()) {
        Japan.releaseDeadlock(i)
    }
}
policy.execute()

なるほど、
これで考えると皆さんexecuteメソッドに気を取られすぎていませんか。

その前のデッドロックの除去を高速化する方に目を向けるべきじゃないかな？

少なくとも停滞する確率は下がると思います。

外部から最適解は得られない

「「淡路島の電車の運行状況を聞いた話」をシステム開発に置き換えてみる」に対する反応に対する以下略に対して、
あえて本筋から外れたことを記事にしてみます。

よく問題が起こったシステムに関して、

「○○はダメだ。」
↓
「じゃあ答えは何なんだ。」

という問答が繰り広げられることがあります。

おおよその場合、
結局その答えが出ることは無いでしょう。
(答えがあったら最初に答えを併記しているでしょうし。)

それは別に無知であるわけでも意地悪しているわけでもありません。

最適解を得るための情報が少なすぎるのです。

最適解を得るためには、
事細かな情報が公開されるか、
内部の人が気がつくしか無いと思います。

情報公開なんてまずされないでしょうから、
優秀な人が内部にいる必要があるでしょうか。

でも優秀な人が内部にいたら、
そもそも問題が起きないか、最小化されているはずです。

つまり問題を起こしたシステムの持ち主が答えを得ることはないわけです。
情報公開しない限りは…ですが。

ポカを繰り返している企業は、
結局これの堂々めぐりなんじゃないでしょうか。

やっぱり色々あるのかな

ここ最近この記事の閲覧数が妙に増えたな～と思っていたら、
JVNに乗ったことがニュースになっていたのですね。

もう今となっては過去の話なので、
こちらとしてはなつかしいな～というのが率直な感想です。

記念にもう少しつっこんだレポートでも上げたいところですが、
これが入っている派遣先から抜けたのでもう調べることができません。

…でもあの件はどうするのかな？

まだあの件が対応できそうなアップデート情報は見てないのですが、
派遣先から抜けて情報が入っていないだけかな？

派遣先にいる人に今後聞いてみましょうかね。



ヒント

バトルロイヤルだとなぜか勝利できる

遊戯王は2人対戦のゲームなのですが、
人数が中途半端なときはバトルロイヤルルールで遊んだりします。

公式なルールがあるわけではありませんが、
１順目は攻撃不可だったり、
１順目の最後の人だけ攻撃可能だったり、
そのあたりだけ決めれば結構遊べます。

それで何度か戦ったことがあるのですが、
自分のデッキはというと…

【倍プッシュ】
【気まぐれムズムズワンキル】
【マドルチェ(ハイランダー寄り)】

と相当なファンデッキです。

「無理だ…勝てるわけがない…」
と言いながらデュエルしてみたわけですが…



…なぜか勝ち残ってしまうんです。

序盤は弱くて相手にされず、
中盤も弱くて相手にされず、
終盤で一騎打ちになるとなぜか勝つ。

そんなパターンができあがっていました。

確か口八丁で自分へ攻撃するメリットの無さを説いて、
致命傷を避けていたような気がします。

つまり、
自分はデッキが弱いことで心理アドバンテージを得ていたわけです。

心理フェイズ最高！

心理フェイズを楽しみたいなら、
ぜひともバトルロイヤルルールで遊んでみよう！
※友情が破壊されても自分は責任を負いかねます