図1.RDBに項目が追加されたときの影響範囲
11/30
Googleはあっという間になくてはならないサイトに変化しました。
なんせ、軽い速い精度は高い。
特にいまの会社での環境みたいな糞パソコンでネットをするのには必需品です。
使わぬ理由はないでしょう。
11/30
うぉー、キン肉マンのノリで、魁男塾格ゲー作りたいぞ。
だれかやる人いませんか？
でも、あのサイズだと、自分のドット絵の技量は役に立たないんだよなぁ…
11/30
最近私が良く見るいがぴょんさんの日記やlemon氏の日記を見るに、通常の一流プログラマの最大出力は一日1000step前後くさいですね。
かくいう私は先月一月で1000stepです。まぁ何を作るか考えなければならない。という問題はあったにせよ（仕事がないのよ）、ひどい数値。
そうとうやる気がないのがわかりますね。
一応自分の見苦しい名誉のために言っておくと、５月のゴールデンウィークあたりに一日１０００ステップは達成してたような気がする。
と、思ったら500行だった。
集中力というパラメータが異常に低いのと、実はそれほどプログラム作成経験がないのが痛いですな。
まだまだ二流というところでしょうか。
いがぴょんさんの日記に書いてあったブラックジャックプログラマの道へは遠く厳しい。
あぁ良い響きだ。ブラックジャックプログラマ。
ブラックジャックプログラマの証言としては、これまた欠かさず見るサイトPG様において、それらしき人物の存在が語られていた記憶があります。
教訓として、ある程度の規模のプログラムを読んで、さらに書いて書いて書きまくる必要性を感じます。
最近は知識偏重だったので、論理思考力等が落ちているような気がします。
あとはどうしても、まだBASIC時代の悪癖が抜けていません。具体的に何かといわれると困るのですが、なんかこうBASICなんですよ。
と、言っても来月の勉強予定は「プログラマの達人」を読んで、たしか13日発売予定の「XP」の本を読む。というところまでは埋まっちゃってるんですよね。
で、家ではSDの新作が控えているので、それほど時間はない。
11/30
こりゃすげぇや。
面白い。
11/30
あーだりー
11/29
今日はlemon氏お勧めだったようなきがする「システム管理者の眠れない夜」の単行本と、「達人プログラマ」を購入。
ごめんなさい。また領収書忘れました。
買う直前に認識してたのですが、「プログラム作法」を今買うか悩んでいたら忘れてしまいました。
11/29
正直な話、会社辞めるのは怖い。
辞めるときのごたごたもいやだし、それなりにお世話になった人達を裏切る形になるのもいやだし、次の仕事の不安もあるし、辞めることは悪という世間の目もいやだ。
何より自分自身が二君に使えるのは恥という悪のJapaneseの無意識レベルの価値観が残っている。
そこの無意識の価値観を捨てられないから悶々として辛いし、辞めるということに中々踏み出せない。
会社を辞めなければ、絶対にただの井の中の蛙の二流SEどまりなのはわかってるし、上に上げたことも全部メリットとデメリットは左脳では理解しているつもりだ。
そもそも動かなければ絶対に駄目だということも。
感情の制御とはなかなか難しいものです。
11/29
突然プロジェクト復活しそうになってきた。
11/28
あー、何事もやる気がおきない。
新作もストップ中
11/28
現在作りなおし版を執筆中なのですが、MMRの没ネタをこっそり公開します。
没の理由は面白くないから。ってだけです。
11/28
あー、どうしてもちょっと見ると悪い方向へ考えて自己嫌悪してしまうね。
11/28
現在のプロジェクトはポシャるのはほぼ確定です。
行く気はないですが、次のプロジェクトは小田原らしい。
次のプロジェクトは同じ顧客なので、そのままメンバーが移るとすると、新幹線で1時間半、普通電車で2時間半かかります。
11/27
hoops遅いなぁ。
当分引越しはしたくないので、とりあえずミラーサーバでも作るかな
11/27
Googleちゅう検索エンジン。超速い。検索結果はまだ検証中だが、「モノーキ」の検索ではなかなか良好な結果。
さすが月20%の増加率を誇るだけのことはある。
11/27
でも、デバッグパターンって今のままだとアンチプログラマパターンだな。
11/26
デバッグパターンの新しいパターンを募集中です。
＜デバッグパターンの定義と項目をもう少し厳密にし、新たな項目を追加しました。＞
11/26
今日はサッカーJリーグの最終節。
最終節になんと一位「かしま」と二位「かしわ」の直接対決。勝った方が優勝。というとんでもない一戦。
見なきゃ駄目でしょ。というほどのものではないが、解説の弟もいるので、観戦。
開始十分後、とりあえず飽きたので後半だけを見ることにする。
後半。おやつを食しながら観戦。
延長前半。眠いので寝る。
延長後半。引き分けなら優勝のかしまが露骨極まりない時間稼ぎでむかつく。もりあがらずそのまま「かしま」がだらだらと優勝。
途中経過は弟曰く、「シュートはなかったが、見所はあった」らしいので、まぁわからない奴は口に出さない。
が、最後の時間稼ぎはなんだ？
Jリーグ低迷と言われて久しい現在、BSで放送とは言え、これだけの条件がそろった好カードで気合の乗らないプレー見せてどうする？
ただでさえ見てて冗談抜きで眠くなる普通の試合見させられてるんだ。
こういうときぐらい男気見せてみろ。
ファンはなんのためにJリーグを見てる、いや、見てやってると思っていやがるんだ？
愛してもらうプレーをしないと、愛してくれないんだぜ。
11/26
黒板消しは何回叩くとチョークの粉が出なくなるのか？
ぜひ、鉄腕ダッシュあたりに実験していただきたい。
11/25
うーん、だめだ。
今日も実りがない一日だった。
どうぢても気が乗らないな。
11/24
今日からフレッツ。
使い放題なり。
11/24
C#のメーリングリストから引用。
case文で
case "gif":
case "jpg":
のようには書けないそうな。変わりにgotoを使うらしい。
ダサいといえばダサいような気がする。
まぁ、文字列で書けるのは大きい利点だが、そもそもこれを多用する時点でかなり問題あり。
swtich(value) {
case "jpg":
Context.Trace.Write("value", "jpg or gif");
break;
case "gif":
goto case "jpg";
default:
Context.Trace.Write("value", "default");
}
11/24
今日も人生を放棄してるかと思わんばかりに無駄に過ごす。
いや、一つだけ有意義なことが合った。
我が家のやっては行けないことリストの一つ、
「我が家に現存するスーファミのゲーム本数を数える」
の禁を犯したのだ。
結果は、発見されたもののみで162本。
一本1000円としても16万を越えてしまう。
一本5800円だったら100万近くする。
さらに変なところに埋まっているものもあると思われるので、手作業で集計しなおせば、もう少し本数は増えると思われる。
まだ、プレステ、サターン、ファミコンもあるが、多分こいつら全部会わせてもスーファミほどの本数はなかったであろう。
やはり、ゲームが一番熱かったのはスーファミだ。
異論はあろうが、訂正しよう。個人的に一番熱かったのはスーファミだ。
ゲームがゲームゲームしていたころの、最高の物が多く発売されていた。
と、言ってもさっぱりわからないだろう。
これも個人的な意見だが、ゲームは大雑把な分類が二種類ある。
コンピュータ的制限に捕らえられたゲームと、そうでないゲームだ。
コンピュータ的制限に捕らえられたゲームってのは、ようするに遅いCPUに少ないメモリで、キャラのアニメーションとかもパラパラしてたころのもの。
そうでないゲームは、そういう制限は少なくなって、思ったようなゲームが作りやすくなったころのもの。
前者のゲームはなんというか、味わいのあるなんというか中毒性を多少なりとも持っていた危険なゲームで、
後者はなんというか、一見重厚そうでも淡白きわまりない。
あー眠くてこれ以上思考できません。
11/23
三国無双やったり、サッカーのつまらねぇ試合見たりして、すげー、ぐーたら休む。
最近一日の貴重さがわかるようになったので、とても無駄な時間のような気がするが、やはり休むのは必要である。
11/22
＜というわけでデバッグパターンの0.05版を追加しました。＞
11/22
SEの仕事って、概念的な本は腐るほどあるのに、具体的な世界に入ると恐ろしく文献が少なくなる。
例えば仕様書のフォーマットとか、典型的な問題に対する解答とか。
まぁ、場合によって違う。といっても、優等生的答えが簡単に検索できる本があると便利なのだが。
11/22
パターンの一種で、デバッグパターンっていうのは作れそう。
プログラムの挙動などから考えられるどのようなバグが出るかというパターン。
と、思って実践してみようとおもったのだが、
・1 hour パターン
現象：一時間以上悩む。
原因：言語に潜む深刻な問題の可能性がある。
対策：FAQを調べよ。
補足：一時間悩む前にFAQを調べること。
・1 day パターン
現象：一日以上悩む。
原因：データの寿命がやたら長いときにどこで何が起こったか捜索が困難。
対策：リファクタリングをしてソースをきれいにしながらデバッグする。
原因2：自分がタッチできないライブラリ等のバグ
対策2：ライブラリの直前のインターフェースまで正しい値が入っているかログを都って確認する。
原因3：単純なタイプミスやうち間違いによるくだらないミスの可能性が高い。（例：全角文字を使っていた。）
対策3：恥ずかしくとも他人にちょっとだけ見てもらうと気がつきやすい。とくに頼もうとして声をかけた瞬間。
くらいしか思いつかなかった。
もしかしたら、面白いかもしれないので、ちょっとまじめに募集。っていうか今からコーナー作ります。
11/22
半年くらい前に買った「かんたんUML」が長らく行方不明だったが、なぜか弟の部屋で発見される。
11/22
派遣会社というのは会社によって、いろいろ違うと思い込んでしまったので、
派遣会社の人にいろいろ質問しまくったら、がんばって資料を作ってくださっているようだ。
しかし、質問しまくって自分で調べないのも悪だ。と思い、昨日今日で派遣社員を使用側の本を読了した。
企業側向けの本と言っても非常に中立的な立場で書かれていたので、派遣社員側としても派遣社員の実態がどういうものかよくわかった。
基本的なことは労働者派遣法で決められていて、業務形態はたいていどこも同じなんですね。
基本的なことはこれで把握してしまったので、
一生懸命作ってくださっている資料の一部は役に立たなくなってしまうかもしれません。
ごめんなさい。
と、いまさら言っても向こうも困るので、ここで謝っておこう。
将来他の人にも役に立つ資料になるし。
11/22
lemon氏に「君は君以上の実力がある人間達に囲まれて初めて使える人材だと思う｡切磋琢磨とかすきなんじゃないかな？」と指摘され、あぁまったく持ってそのとおりと思う。
と、書くだけだと小学生の感動文なので、
結局、一番見えないのは自分自身なのだ。
だから、自分自身の観察ってのは手を抜いちゃいけないんだよね。
それと、自分自身を（良くも悪くも）評価してくれる人間ていうのは大事だ。三国志７で言う評価か。違うか。
最大の問題は最近は実力のある人がなかなか見つからないことだ。
もちろん、部分部分は大抵他人の方がすぐれてはいるが、「げー、こいつは神だ。」という人間はさすがに会えない。
今後の人生はいかに天才に会うかが鍵というのかはわかった。
11/21
ただ、最近思うのは自分はアカデミック系に再び戻った方が能力が生かせるような気がする。
どちらかというと武器は、（具体化能力を押さえつけるほどの）抽象化能力と、それを利用した発想力であるような気がする。
それを生かすには、どちらかというと実現不可能レベルの困難な問題に立ち向かったほうがいいのではないか？
とも、思うが、自分自信の分析というのはさっぱり当てにならないし、
アカデミックな世界は需要が高くないので、自分を望んでいない可能性のほうが高い。
大学時代の楽しいお子様レベルの研究に甘えているという可能性も高い。
というわけで、結局結論はつかないのだ。
11/21
自分の悪い癖の一つとして、物事を慎重になりすぎて時期を逃してしまうことだ。
さらに悪いことにはそれに気がついて、焦って行動を起こしてしまうことだ。（昨日の自分だ）
というわけで、ボーナス支給日か、もうプロジェクトを潰れるのは秒読み段階なので、
それまで落ち着いて、派遣業務について勉強してみよう。
と、行って買ってきた本は何故か派遣社員を雇う会社のための本（間違えた）。
まぁ、視点が変わるだけだし、自分らしくて良いのではないでしょうか？
11/21
システムエンジニアのためのページというものを発見したので仕事をサボって読んで見る。
言っていることは正論である。が、どうやらこのページの作者は私のような素人は嫌いらしい。
上司の決定には逆らわず、やる気をなくすのは自分の責任。なんとかしろ。
上司がだめならGTOよろしく、社内自体を改革しろ。
やめるなんてのは気合の足りない証拠。
残業はあたりまえ。残業品で仕事をするのは不可能。贅沢言うな。
もちろん勉強はおこたるな。
ごめんなさい。いくらなんでも食うに困る生活をは送ってないので、そこまでできません。
っていうか、立場が異様に上司より。もとSEな方でしょうか？
デマルコのデッドラインによると、私は士気を高めて維持するのは管理者の仕事だと思っていたのですが。
たしかにこう言うことは言えばわかる。
僕だって、なれるものならなりたい。
いくら希望にあふれているからって、努力と根性が延々と続く人間はそうはいない。
私だってそうだ。
飽きっぽいから楽をするのだ。楽をして勉強をする。
とあるメールマガジン（日刊デジタルクリエーターズ結構面白い）の後書きで読んだことの受け売りだが、
結局、こう言われたって、私にどうしろというのだ？
ワインバーグの本は非常に実践的だ。何が実践的かというと、我々は凡人だというところまで降りてくれるからだ。
いったん我々のところまで降りてきてくれてから、引っ張ってくれる。
はっきり言って理想の教育法だ。
人が能力を高めていくのは基本的に階段状だ（というのもワインバーグの受け売り）。
階段を上れた人はどうやって登ったかを、まだ上れていない人に示すことで、階段を低くすることが可能だ。
こうすることで、我々凡人も階段を登ってくことができるのだ。
どうだ我々はこんなところまで登ったんだぞ。と自慢されたって、凡人にはどうしようもないのだ。
ですから、いったん我々のとこまで降りてきてから引き上げて欲しいのですよ。
ということは自分も自覚しなくてはいけないのですな。
11/20
はぁ、疲れた。
11/20
さて、やめるというタイミングはいつにするかだ。
口実と利益的にはボーナス直後がいい。
明日言っちゃうかな。
いや、ごたごたした状態で4連休を迎えると有給も取り上げられて、気分良く休めないな。
11/19
冷静に考えてみれば、
例えば、String型というのは役に立たない。
だって、ただの文字列じゃん。
それは住所でも、名前でも、IDでも、なんでもない。
あくまでも文字列なのである。
数値型だってそうだ。
int型はお金でもなければ、郵便番号でもなく、時間でもない。
うかつにこれらの型を製作者側が「この文字列は住所をしめしている」と言っても可読性が悪い。
例えそのオブジェクトに対する操作が文字列型と同じだとしても。
ましてや、DBに入れるような金額は何桁と値が決まっているし、
郵便番号は７桁でないといけない。
だから、こういう型は名前型、住所型、金型を一つ一つ作って、値のチェックはそいつらにさせるのが、実は自然なのだ。
そして、型情報のインターフェースをきっちり明示して、（例えば桁数）統一的に取り出す手法があれば、
11/17の日記のような問題は解決することができる。
つまり個人型の共通インターフェースを作ればいいのか。
問題はこれをどう表現するかだよな。
11/19
会社を辞めるとしても、結局のところ、レベルの低い奴らと仕事をしなくてはならないとか、もろもろの不満は絶対解消しない。
ギアをハイまで高められても、ずっとローのままで運転するのと同じだ。
ろくな仕事がないのも代わりはしないし、むしろさらにひどくなるだろう。
その中で自分がやっていけるか？と言われると自信もない。
満足にやりとげさせてもらった仕事がないんだから。
まともな各種仕様書というものを見たことすらないから、仕様も書けないし、それどころか要件定義書、外部設計書、内部設計書、詳細仕様書の明示的な区別もつかない。
この甘ったれめ。
と言われるとまさしくそのとおりだ。返す言葉がない。自分でもそう思うのだから。
でも、今のままでは何も変われないし、将来はどんな仕事でどんなことやっているのか、大体わかっている。
それじゃ、面白くないから、そろそろ外の世界に出てみたっていいじゃないか。
このままじゃ、失敗だって経験できない。
11/18
祖父の四十九日だった。
が、疲れたので書く気がしない。
11/18
ソフトウェア工学有名人の論文風
「悪いのは魔人か乞食か？」
ソフトウェア開発において、顧客が要求したものと違ったものを作ってしまうことはしばしばある。
というより、そういう開発のほうが多いのが現状だ。
この場合、開発者の言い分は「顧客が要求したものを開発した。」であり、
顧客の言い分は「我々の要求したものを満たしていない。」である。
一見矛盾した言い分であるが、実は両者の言い分は両方とも正しい。
この問題をよりわかりやすくするために、三つの願いをかなえてもらう乞食の話で例えてみよう。
ある乞食が川で拾った壷みると、壷が突然話はじめた。
「私は魔人だ。この壷をあけてくれるならば、三つの願いをかなえてあげよう」
そこで、乞食はふたを空けて、魔人を解放してやった。
乞食は最初は「たくさんのお金が欲しい。」といった。魔人が指をパチンと鳴らすと当たり一面お金に包まれた。
今度は「豪邸が欲しい」と言った。魔人が指をパチンと鳴らすと突然豪邸が現れた。
乞食は最後に「一生働くてもいいようにして欲しい。」と言った。少し考えた後、魔人が指をパチンと鳴らすと回りにあったお金も豪邸も消え、乞食はもとの乞食に戻ってしまった。
この場合、魔人は乞食の要求を完璧に満たしている。しかし、乞食の真の要求とは程遠い。
それに、魔人は願いをかなえるという約束は破ったし、乞食は欲しかったものは手に入らなかった。
このとき悪かったのは真の要求を聞かなかった魔人なのだろうか？真の要求を伝えなかった乞食なのだろうか？
この問題は顧客と開発者の問題にも当てはまる。もちろん乞食が顧客で、魔人が開発者だ。
（顧客がみすぼらしくて、開発者が魔法を使うので凄いという意味ではない）
さて、このすれ違いは誰が悪くて誰がどう直せば双方とも利益が最大の結果が得られるのだろうか？
お、ゲーム理論の世界に入ってきたぞ。
11/17
GMワインバーグのスーパーエンジニアへの道を読んでいるが、
一部を読んだだけで、一個レベルが上がった。
今日、いっぱいかいたのはこいつがきっかけです。
これは凄い本だ。
人間の成長に対しての鋭い視点と考え方が出てます。
これを読んで一つ悟ったのですが、明日行こうに書きます。
11/17
よくプログラミングは建築に例えられるが、建築はたゆまない変化には基本的におこらない。
リフォームなどの技術はあるが。
そこで、たゆまない変化が起こる建築を考えたら、鉄道とか道路交通網などの分野があるではないですか。
さっそく土木関係の本を探して回ったのですが、良いものがありませんでした。
道路関係の本は結構あったのですが、あまり変化に対する対策や、変化を行うときの技術について語ってはいませんでした。
まぁ、変化するというより新しくつなげるだけですから、交通網自体は進化しても道路そのものが変化するということはありませんよね。
というわけで、むしろ動かしながら変化させる鉄道の方がいいのではないか？
と思いましたが、そんなマイナーなジャンルの本は見つかりませんでした。
むしろリフォームの技術を当たったほうがいいかもしれませんね。
オブジェクト指向の欠点として、データの追加変更が大変ということがある。
例えば、RDBの項目に新しく追加すると、間違いなく表示の部分にまで影響がある。
普通はRDBの項目から読みこんでどこかのオブジェクトにぶちこんで、それを加工して、加工して…、表示
という経緯をたどるわけだ。
図1.RDBに項目が追加されたときの影響範囲
図1ではRDBに項目が追加されたときの影響範囲を示している。
RDBに項目を一個追加すれば、DBの１テーブルを表すクラス1に項目を一つ追加する必要がある。
それを表示する画面２、３も変更する必要がある。
クラス１を利用するクラス２は追加された項目に対して処理を追加しなければならない。
それを表示する画面２は変更の必要はないかもしれないし、するかもしれない。
と、このようにちょっと考えただけのオブジェクトだと、変更に対する影響範囲が結局大きくなる。
で、仕様の変更が処理の追加変更だけ、ということは早々なくて、DBの項目追加は結構あることだ（よね？）
つまり、通常のオブジェクト指向では、横の仕様追加に対する影響は楽チン極まりないが、
縦の仕様追加ではつらいことになる。
というのは、僕の腕がしょぼいのでしょうか？
まじで誰かアドバイスしてくれー、会社に誰も知っている人がいないので、チェック機構が働かず、一人で空回りしてる可能性が高いんだよー
閑話休題
ということでこれも可能になる言語使用を考えろ、と無茶な結論付けようと思ったのだが、解決策を思いついた。
全てのデータ項目はinterface MVCを継承する。
インターフェースMVCには、画面表示を行う、draw()メソッド、inputCheck()メソッドなどを持っていなければならない。
で、各データにStringクラスなどは使用禁止にして、
数値を入れるgetsetも廃して、例えば金額クラス、住所クラスなどを全てきちんと作って、MVCクラスを実装する。
最初に戻るが、このMVC項目を継承したものだけを、扱えるようにすることにより、
画面配置などはすべてデータ項目のdraw()メソッドを呼び出すことによって行い、
入力チェックは全て項目のinputCheck()メソッドで行うのだ。
そうすれば、縦の変化も結構楽に対応できるのではないか。
（例えば国際化なんかも住所クラスの変更だけでできたりとか）
まぁ、細かいところで問題点がいっぱい出てきそうな気がしますが。
これで、ザク⇔ザクタンクにおけるプログラムのインターフェース問題について一歩解決へ近づいた。
まぁ下の方でも言ってるようにまともにプロジェクト完成させてもらったことがないので、一般的でなかったらご指摘を。
そういえばRDB関連って、クラス設計の良い方法がいまだに思いつかない。
１クラス１テーブルってイメージでいいのかなぁ。
11/17
しかし、どうしてこうも凄いプログラマというのは凄いんですかね。
気がつくと凄いプログラムが３０分くらいでできている。
過去にスーパーなプログラマは一人しかしらないが、Web上では良く見かける。
でも、実はそこにたどり着くのはそれほど難しいことではないんだよね。
ようは慣れよ。
何回もいろんなプログラム書いてれば、一瞬で実装はできちゃうんだよ。
最近趣味ではプログラムをしてないので、なかなかたどり着けないよ。
11/17
しかし、まだBASICの悪癖は残っている。
（interfaceではなく）インターフェースに対するプログラミングというのが、ようやく身にしみてわかったよ。
今までは、この機能＝こういう実装のシステムが作りたい。
これを実現するにはどのようなインターフェースを作るがいいのか？
という悪のオブジェクト指向プログラマだったことを白状します。
（単純で良いインターフェースは提供できなかったよ。）
まずは、インターフェースと各オブジェクトの繋がりを考えていくんだね（つまりUML）
インターフェースだけだと、実装できるかどうかはわからないので、
テストを書きながら実装ができるか確認していくんだね。
オブジェクト指向スキルレベルアップ
とりあえず、オブジェクト指向のプロという段階までは後少しでたどり着けそうなのだが、まだあと少しが見えない。
11/17
前から思っていたのだが、
しかし、なんでただのコンピュータオタクに見られるんだろう。
家にパソコンが何台もあって、サーバたてて喜んでる風に思われているようだ。
そういう人を否定しないし、むしろいると凄い助かるのだが、私はそういうところにはさほど魅力は感じない。
環境は存在を意識しなくなって初めて環境としての価値があると思うから。
まぁプログラムの環境構築とかは好きなんですけどね。
11/17
人類にわからないことがあるからといって、それをいきなりオカルトに結び付けてしまうのはどうかと思う。
わからないからと言って、自分だけが納得のいく単純な解に行くという行為自体が、
「人間はどんなものでも物事の原因を見つけられる」というおごりであり、仮にオカルト側が正しかったにしてもオカルトに対する冒涜である。
11/17
今日は心調が良いので、仕事するぞと思った矢先。
週定例の資料を見てビビル。
無理なので潰すと言っていた、
「『従来の紙ベースの入力用紙』をスキャナで取り込んだ画像に、文字を入力する。」
という、Webベースじゃなくったって悪夢のような仕様が、遠い星空の世界で決定している。
普段は波風は立てないように悟らせるようにしている自分も、さすがに「正気ですか？」の言葉がついて出るよそりゃぁ。
顧客の要望は「新しいウリになる機能が欲しい」ということらしいのですが、速度が欲しいという要求に完全に矛盾してます。
ユーザインターフェースの研究も怠らない自分としてはそれは自殺行為に等しいです。
その瞬間悟りました。
私にとって、顧客なんざどうでもいいんです。
最高品質のものを実際に使うユーザに提供したい。
そして、それを安く速く提供したいんです。
お願いだからユーザに使ってもらえるシステムを作らせてよ。
これ以上は技術者の魂は譲れないよ。
今までに自分の作ったシステムで、稼動しているのは一個もありません。
正確に言うと、２個ありますが、一個は自分が関わったことを公開するのは恥なシステム。
もう一つは仕様が完璧過ぎて何を作ってるのかわからなかったシステム。（当時それについて文句を言っていたんだから、思えば若かった）
まさに最近聞かない吉野家の「うまい、やすい、はやい」の精神です。
会社の上の人は「うちでは受けない」と言っていても、すでに信用できません。
士気は完全に０になりました。
状況が突然変わらない限り、辞める動きに入ります。
と、言っても今年中は辞め（られ）ないので、助けに行けるのは来年でしょう（その段階で人材が欲しいのかどうかは知らないが）＞lemon氏
今日の午後は、きりの悪いところでもめながら辞めたくないから、今日の交渉が決裂してくれることを祈っていました。
11/16
唐突に自分はビジネスマンにはなれないと悟る。
なぜなら、金にルーズすぎるから。
バンバン使うという意味ではなく、まったく金にこだわらない。（そういう生き方ができる身分だからというのもあるが）
金はあくまでも報酬ではなく、自分がどの程度評価されているかの数値でしかない。
（そのくせそれを他人に取られるのがやなのでけちなのだが）
じゃぁ、どうしたらいいのだろう？
と、なると難しいのだよな。理想を言えばきりがないし。
11/16
独習UMLにRationalERoseがついてくるらしい。
多分体験版で機能制限付きだろうが、万が一の可能性もあるので今度確認してみよう。
11/16
気力が０に近いので、ほとんど仕事をしていない。
まじで通常の人間の半分くらいだろうな。
去年のこの時期もこんな感じだったようなきがする。
ピープルウェアを読了。
噂に違わぬ書籍。
読むだけでレベルが一つ上がります。
三国志７で言えば知力＋１０クラス。
やはりまずは人だよなぁ。
それがいないので困っているのですが。
11/15
プロジェクトが流れる可能性が高まってきた。
そうするとさっさと辞められるな。
11/15
昨日、弟２が九時に帰ってくる。
どこをほっつき歩いていたのか？と問いただすと、
「気がつくとうちの駅を通り越して一時間の駅にいた」
その間寝たのかどうかすら、何も覚えていなかったらしい。
しかも、駅名まで覚えていない。
ぼけーとしてるし、会話に対する反応も鈍い。
さらに気持ち悪いという。
確実に頭がやられてる症状なので、
何かあったのか聞くと、「サッカーで頭ぶつけた」
様子が尋常でなかったので、親が病院につれていってCTをかけた結果、脳震盪だったらしい。
脳震盪が起こると、２４時間近くその後の記憶が無くなったりするそうだ。
現に今日聞くと、昨日の昼休みから何をしてたのか断片的にしか覚えていなかったようだ。
スノーボードでよく起こることだそうだが、場合によっては死にいたることもあるので注意が必要。
11/14
ついにピープルウェア入手。
明日から読みます。
11/14
今日は凶悪に士気が低いので、ほとんど仕事をしませんでした。
普段からそうなんですが、頭脳労働者といえども、やはり思考の空白時間というのが、どうしても多くなりがちです。
それを防ぐために、ペアプログラミング（二人でペアを組んでプログラム）でもやりたいところですが、
絶対にやらせてもらえないだろうな。
士気が低いから仕事をしてないというと、
「甘ったれるな。そんなものは自分で高めろ」
と、言う人はおおいでしょうが、なんで？
プロたるもの常に最高の状態で最高の仕事をするべきというのは簡単です。
でも、それだったら野球の監督、コーチなんていらないですよね？
管理を行う人間の仕事として、管理される側の人間が最高の環境で働けるようにするというのは当たり前じゃないんですか？
まー、自分は頭悪いし、甘ったれなので、
そこを利用するやり方でしか、生きてこれなかったし、生きていけない。（ペアプログラミングがいいのではというのもそのためだね）
だれでもくだらないことを根性で解決なんてできませんよ。
正論じゃないので、そういう人って多いんじゃないですか？
11/13
Servletを楽にしようとしたものだというのは、先日述べたとおりだが、
スコープがSession内のオブジェクト全部である変数を自由に定義したいといいだしたので、
普通の変数のように扱うならJavaの仕様を変更しなきゃ無理だ（Hashtableに突っ込むのとかなら可能）
と言っておいたが、
「つかえねぇ」と呟いていたのを聞き逃さなかったぞ。
できるもんなら、実装してみやがれ。
士気が低いときは地獄耳
11/13
こうも席の遠くの方で「わかんねぇ」とか言われるとさすがにむかつくし、自信もなくすのですが。
まだ未熟者（謙遜無し）なので、フレームワークもまだ納得いかない点はいっぱいあるし、
資料なんざ、一通りのクラスとメソッドの簡単な説明と、チュートリアルを乗っけただけ。（それでも３０ページ越えちゃうのよ。）
クラスなんかもう、実装しらないと意味不明なものもあるしね（簡単なのが一個）
だから、資料ないしはクラスのどちらかが（あるいは両方とも）悪いという指摘は甘んじて受ける。
せめて、どちらが悪いのか、どこが悪いのか指摘してくれ。
今後の人生において改善しようがないだろう。
このフレームワーク使えないとなったら、無駄な苦労をしたくないので、さっさと会社辞めます。
最近はもう考え方について行けなくなった。
11/13
「ペンは剣より強し」というならば、「言論の自由」なぞくそっくらえだとは思いませんか？
ペンによる暴力というのは、何の規制もされていないのは事実。
破壊力は剣よりは強いというのに、銃刀法違反も問われません。
ペンが強いというのはわかっているのだから、ペンを使った暴力には厳罰を処すべきだと思うのです。
それがいやならば、ペンの不始末はペンでつけろ。
ペンによる誤報は、それと同様のスペースを使って不始末をわび、金銭肉体精神のいずれかに損害を与えたなら責任をとって弁償する。
それぐらいの覚悟がないやつに剣を扱う資格は無い。
ましてや、ペンを扱う資格なぞ、あるわけがない。
ということを無責任にペンでつづっても説得力があるわけがない。
っていうか、「ペン派遣より強し」くらいちゃんと変換しろよIME
11/12
レシートにバーコードをつけて、家計簿ソフトがバーコードリーダを使って読みこめるようにすると、家計簿付けが超楽になるよな。
面倒くさがりやだって、家計簿つけたいという意思さえあれば、買い物のときにレシートを財布に突っ込んでおいて、ピ、ピ、ピと読みこむだけでいいんだもん。
アメリカで、画像にあてると自動的にそのURLに飛ぶ機械が、無料で配られているらしいので、
（どう考えてもその会社潰れそうだがな）
日本でもそれをただで配って、付加機能としてレシート用APIを公開して、それを各社に使ってもらえばいけそう。
でも、レジは総入れ替えが必要なので、簡単にはいかないと思うが。
個人向けバーコード読み取りシステムって、こちらで今みたいないろんなAPIを用意すれば、なんか凄い使い道がありそう。
11/12
天より高くを集めているが、なんかもう男塾後日談。
そのほうが面白くていいのだが。
11/12
宮下あきら「天より高く」より
男はいつでも心に一本のドスを呑んでいる
良い言葉だねぇ。
11/11
そういや、モノーキ開設二周年すぎてました。
過ぎれば速いものよ。
そして、よく日記が長続きしてるものよ。
11/11
なんかドラマでインターネットの匿名性の恐怖を使ったドラマがやってたようだ。
内容はどうだったか知らないので触れない。
まぁ、匿名性を利用しての凶悪な個人攻撃などは、倫理的に認められる訳ではないが、
誰かが読んでくれているかもしれない文書を公開できるというのは良い。
実際、自分はそれをやってるしね。
で、そういう人を「現実世界では何も言えないくせに」と言って批判する人は多い。
が、現実世界で発言する価値のない言葉もある。
不特定多数と不確定少数に向けた言葉だ。
この下の日記の赤鼻トナカイ問題を、通常の人間との会話で取り込んで面白いと思われますか？
この日記を読んでくれている方は、ある程度は面白いと思ってくださっているのだろうが、
現実世界では多くの価値観を持っている人がいて、たいていの人は「何いってんの、こいつ？」という反応でしょう。
それに、会話に取り込むとしても、一般ピープルがドラマとスポーツと女の話をしているところのどこに赤鼻トナカイの問題を提案して議論できるのでしょうか？
赤鼻トナカイならまだましですが、「ガンダム世界におけるソフトウェアは、どのような構造になっていて、どのように開発を行ったのか？」という問題なぞ前提知識が多すぎて、わからない人は読み飛ばしてくれるWebじゃないと発表できません。
MSに関するそれなりに深い知識と、オブジェクト指向を含むプログラムの最新技術がわかる人はこの世に１０００人いますか？
さらに深い議論するならば、軍事用ソフトウェアの深い知識も必要になりますが、そこまでいくと僕も付いて行けません。
ごめん。
僕は暗い人間なのでそんな豊かな会話術を持ってませんし、理解を拒む人に無理やり価値観を押し付ける疲れる作業はしたくありません。
この話題だって、普通の「現実世界に何も言えないくせに」にどういう意味があるのか考えたことも無い一般ピープルに語る自信はありません。
持ってたって、自分の考えたことがたかだかまわりにいた人数人しか聞いてもらえないより、興味のある人が検索エンジンで引っかかってくれるのを待ったほうが現実的じゃないですか。記録にも残るし。
自分が提案しているインターネット世界の大きな利点の一つは、普段は他に仲間がいることを知ることすらできないニッチ（絶対数が少ない）な人達が、物理的制約を超えて集合できることにあります。
現に「SD」「ガンダム」「フルカラー」「改造」が好きという４段階の超ニッチな趣味の人達はインターネットがなければ一生会うことはできなかったでしょう。ドット絵、MMRもしかり。
そういう普通の人には興味が持てない（価値がわからない）ニッチな話題はインターネットがあって初めて発言できるです。
そもそも、文章と会話というのを同じ言葉を使っているから同じ物。
と考えることが間違っているちは思いませんか？
11/11
真っ赤なお鼻のトナカイさんに
「暗い夜道に、おまえの鼻は役に立つのさ」
と、言ったサンタクロースは差別に値するのだろうか？
例えが失礼極まりないが、髪の毛の薄い方に言うのと同じ感覚で、
「おまえの鼻は暗いときでも明るくなるから役に立つんじゃない？ギャハハハ」
と言えば、差別になるし、
「君の鼻はたしかに赤いけど、その代わりその鼻が夜、明かりを灯してくれるんだ。これは他のトナカイにはできないことさ。次のクリスマスには君に先導してもらうよ。君がリーダーだ。」
と言えば、短所を長所として生かした例になるだろう。
ただ、良く考えれば赤い鼻は自ら発光しないと考えられるので、実は前者が赤鼻のトナカイの真実かもしれない。
月明かりを反射してという可能性も考えられるが、たかが鼻なので反射量はしれたものでしょう。
この問題の前者の部分を取り上げたダミー告発ページを作って、経過を観察したら面白いだろうな。
馬鹿な人権論者がまじで禁止しそう。
11/11
これは面白い。
１８時間かけて４億円半ほど投入してみました。
多分、重複番号チェックをやってないと思うけど（やってたらメモリ食いすぎ）、億レベルの購入ならさほど影響はないでしょう。
結果は以下のとおり。
スナップショットは３億時点のものだけど、高額のあたりは以降出てないので赤字はさらに膨らんで
２億を越えていた気がする。
これでものすごい勢いで購入していく様を見ていると、個人の金の以下にちっぽけなことか。
このわずかばかりの確率に賭けるくらいなら、つつましくMGでも買ったほうが有意義です。
多分、一生宝くじは買わないでしょう。
ちなみに1/5000000っていうと、
1Mが約１００万だから、1/5M
210で1ｋだから、１Mは220
さらに22は追加されるから、１等の当選確率は大体1/222ってことになる。
正確に言うと1/4194304だが、これがもっとも近似だ。
何が言いたいかって言うと、
現実的に見ればコインを投げて２２回連続で表を出せ
って、言えば以下に困難なことはわかるのではないか？
でも、皆は宝くじ買ってください。
税金をじゃんじゃん国に納めてね。
酒、タバコ、ギャンブルは迷惑をかけない範囲で合法化して、じゃんじゃん税金を収めさせるのが良いと思う。
そうすりゃ、財政赤字も減って良いこと尽くめ。
11/11
やったよ。
ついにピープルウェアがみつかったよ。
現在注文中。
すげぇぜEasySeek
11/11
でも、豪快にServletの概念を覆してるから、中途半端にServletを知ってるとさっぱりわからなくなるというのは事実かもしれない。
11/11
そういえば、機能先輩社員が今作っているフレームワークの仕様を見てゲラゲラ笑っていた。
曰く、
「コンストラクタにクラスを厳密に定義して、戻り値用のgetメソッドを作るのは良くないんじゃないの？」
「結合度が高いから、本当は良くないんだけど、突っ込んだらかわいそうだから辞めた。」
この会話が大声で聞こえてきたので、おそらくそういうことであろうと推測しただけなのだが。
結合度の概念を教えてあげたのはわたしなんですが。
なんで、ここが結合度が高いのかというと、
HTMLの画面を1機能とみなして、１クラスにしているので、
普通のHTMLだと、
画面間の規定を死ぬほど決めなきゃ成りません。
| 画面１ |
| 画面2 |
じゃぁなくて、画面一個を独立させて１機能とさせてしまう。
検索画面ならば、引数なし、戻り値は検索結果一覧
一覧画面ならば、引数は検索結果一覧、戻り値は検索された結果
という風な感じだ。
これの遷移を担当するクラスは内部状態を気にする必要は一切ない。
こうすれば、検索結果をどう利用手段の差し替えが簡単だし、良く使う照会画面なんかも一クラスとして完璧に使いまわせる。
だから、画面の引数と、戻り値に値するものは変化して当然だ。
Hashtableに必要な値をぶち込むという手段も考えられなくはないが、そんなことをしたらどのクラスがどの文字列を使うか一覧表を作って、だれがその値を削除しなきゃならないか一覧が必要になります。
そんなことするんだったら、チェックをコンパイラにやらせてしまえ。
何か間違ってますか？
11/10
さらに問題としては今になってBASIC時代の悪癖にようやく気がつく。
一時変数を多く使いすぎてしまうのだ。
馬鹿な人（断言）みたいに、やたらとスコープが広い変数は使わないものの、「temp」とか名前をつけてもおかしくない変数がいっぱいある。
こういうのを減らせるようにしないとね。
11/10
と、えらそうなことを言っても実のところまだ良くわかっていないところが多い。
いまだにインスタンスは誰が生成するのか、生成メソッドは誰に行わせるのかが、明確に見えてない。
良く考えたら、インターフェースの使い方もまだ未熟だ。
うーむ。とりあえずデザインパターンをきちんと読みなおすかなぁ。
11/10
後輩がプロジェクトを去る。
去り際に次のプロジェクトがCくさいのでCの良い本を知らぬか？
と聞かれたので、Cプログラミング診断室を教えたら
「あぁ、これ知ってますよ。」
もう教えることはなにもない。
11/10
モチベーションが低いので、フレームワークが破綻寸前。
だって、予定外のものが入ってくるんだもん。
そう、要求が増えればフレームワークは破綻するものです。
だって、最初からある程度の拡張性を入れて作ったって、あれもやりたいこれもやりたい。
って、いったらそのうち破綻するに決まってる。
とある難しいことを簡単にするってことは、本来様様な要求を可能にするためのクラス群を機能削減して、その代わり作りやすくする。
ってもんだから、複雑なことをやりたければ、フレームワークの設計からやり直さなければならないのは自明の理。
今回のフレームワークは外部（HTML）への依存を極端に減らすために存在しているので、
外部からあれをやりたい。これをやりたい。と言ったら構成は破綻する。
正確に言えば、当初考えてなかった要求なので、
リファクタリングで構造をより良くして単純化してから作るのが解だ。
と、言ってもテストプログラム作ってないんだよなぁ…
これを作る前にリファクタリングを知っていれば。
11/9
そう考えるとオブジェクト指向によって、再利用性が高まるということは、
著作権が足枷になって、使いまわし再利用が困難になっちゃうよなぁ。
11/9
lemon氏に領収書を頼まれていたことがあったのを、「今回は忘れてた。」と答えたが、
良く考えたら、結構もらうことあったじゃん。「忘れてたことを忘れてた。」と追加します。
すまん>lemon氏
ついでにフレームワーク製作者の立場から言うと、
最初から、使いやすいものを作るのは大変なんですよ。
ある程度時間があればリファクタリングを行って、すっきりさせていけるのですが。
あと、会社辞めたあとも使いまわせるように、あえて大きな改良点や機能追加点を残しておく人もいます。
ただ、パッケージ販売も考えているらしいので、ちょいとリスキーで無理かもしれませんが。
まぁ、使っても使わなくても同じならば、意味は無いですが。
そして、現在こちらは誰も理解できず扱えないという問題にちょくめんしています。
でもさぁ、扱うクラスなんて外部に見えているのは６〜７個で、
そのうち半分は初期化で一度呼び出せばあとはフレームがよしなに計らってくれて、
実際継承して作りこまねばならないのは、２個のクラスでメソッドもコンストラクタ入れても３つなんだがなぁ。
（それをいっぱい作る）
やっぱりマニュアルが悪かったのかなぁ。
ちなみに私が作っているのはServletJSP間での画面の遷移のHTMLからの独立と、画面の結合度を低めて独立性を高めて、画面間のデータの保持に文字列やらDBでがんばらなくても良いというものです。
その代わり普通のWebみたいに戻るボタンが使えたりという便利なことはありませんが。
法的に問題がなければ全部公開しちゃうんだがなぁ。
11/9
というわけで、Rubyを２５６倍扱う本邪悪編（名前うろ覚え）を立ち読み。
Rubyって、ただのオブジェクト指向なスクリプト言語ってわけじゃなかったのね。
評判を聞く限り、言語マニアにはたまらない一品くさい。
これは面白いかも。
そして我々はオブジェクト指向に慢心せず、さらなるソフトウェアの複雑さの軽減に努めなければならないのである。
で、底辺の技術者は永遠に置いていかれる。
11/9
プロジェクト人員削減
どうやら規模も縮小化するようだ。
ま、いっか。
というわけで悪い癖をつける前に、悪い癖を見ぬけるようにしこんでおこうと思っていた新人が去ってしまう。
その新人に「C#はJavaの悪いところとかカバーしてるかもしれないね。」と話して
「Javaの悪いところってなんですか？」と突っ込まれ、
なんだか重大なことを忘れてしまった。
思い出したよ。数値がオブジェクトじゃないんだよ。
かと言って、C#数値はオブジェクトかどうかは知らない。
11/9
アナリシスパターン
記憶ではわけのわからない日本人が書いた本で、名前がコンサルタントの適当につけた用語くさくて、超胡散臭そうだったので、手を出していなかったのだが、
実はマーチンファウラーの書籍だったのね。
しかも実用的なパターンに関する本のようだ。まだ読んでませんが。
つまり、知るや否や速攻購入。ついでにワインバーグのスーパーエンジニアへの道も購入。
二冊で7500円
馬鹿高い。
と、言う人は多いだろうが、どんな職業であれ俺もあんたもプロだろ（学生の方ごめん）。
自分の技術で稼いでるんだよね。
冷静に考えて、天才で１を知れば１０知れる人はともかく、われらのような凡人が、専門書をいままで３冊以下しかよんでなくて、プロを名乗るのはおこがましいと思いませんか？
しかも「はじめてのC」とか「COBOL構造化手法」とか「CプログラマのためのC++入門」とか初心者向けの本（本の名前は適当。でも絶対存在してるな。けどそれらの書籍とは一切関係ありません。）
っていうか、専門書数冊でなれるプロって、プロの価値がありますか？新卒レベルの給料もらう価値ありますか？
経験が得られるっていったって、経験しかないんじゃねぇ。
だから、経験だけでやっていけるのは天才だけだって。
なんで日本人が書いた本を嫌うかというと、日本人の本が一番書かれる時期が、米国で流行っていて、日本では流行る直前の状態のときが一番多くて、そんな時期に本出しておけばOKという、理解の浅い胡散臭い状態で出版されることが多いような気がします(偏見)。
いずれにせよ、わけのわからない日本人の解説書を読むよりも、オリジナルの訳書を読んだほうが手っ取り早いのは事実である。
訳されるほど有名な本ばかり来るのではずれも少ない。
なので、日本人の本はあまり積極的には買わない。
箔をつけるためだけの大学教授が適当に書いた本が多いのは事実だし。
と、言っていると日本人の良書を見逃すので、書評などはときどきチェックしてるが。
11/8
JUNITを使った、あらかじめテストを作るという技法に心酔
今回のプロジェクトではそれを使用する予定。
リーダーは有用性がわからなかったようなので、自分だけ。
11/7
三国志７でいう鍛錬の特殊技能って凄く重要だよな。
現在の実力も大事だが、1年後2年後3年後4年後の実力の方が重要なわけで、それをどうやるかと言ってがむしゃらに何かをやるよりも、勉強方などの基礎的な技術を持ってから効率的に学習したほうが良い。
といっても難しいのだけどね。
11/7
ドラゴンボールの法則
すげぇ人に追いついたと思っても、ふと上を見るといくらでもけた違いの人がいる。
11/7
今日はずっとメール読んでました。
ようやく役割分担がされたので、皆まじめに仕事してる。
今作っているフレームワークの、改良版のドキュメントを書かねばならなくなったので、明日からがんばります。
なんか働くことにあきた。
11/7
フリーのメールソフトEudoraは重くて使えないのでやめた。
次はフリーのメールソフトEdMaxなり。
軽くて軽快、なかなかよい。
11/7
本日、オデッサデイ
未来の戦死者に対し黙祷！！
11/6
久しぶりにインターネットのごみ箱を拝謁
最近のチェーン、SPAMの質の悪さには嘆くばかりだ。
「いたずら」というものは本来崇高なもので、ただの思いつきで即実行するものではない。
きっかけはたいてい思いつきだが、その後1分くらい、周辺にいるはやし立てるだけの共犯者との相談や、自分の中の天使と悪魔とのハルマゲドンにより、緻密に計画が練られ、最終目的までの詳細な手順が決められるのだ。
そして、その緻密な計画に基づき、一歩一歩目的を達成していき、ときには計画の挫折の危機にあいながらも、困難を克服し、ついに最終目標までたどりつく。
その瞬間、全ての計画が正しかったことが証明され論理的な美が形成され、いたずらは芸術にまで昇華される。
つまり、いたずらは無形の芸術なのだ。
その美しさは当事者である加害者と被害者と傍観者にしかわからないものの、それは技巧を駆使して美を創造・表現しようとする人間活動という意味においてはまぎれもなく芸術なのである。
そのような芸術を「殺す」などの、技巧どころか脳みそを使ったと思われる痕跡すらまったく見られないメールを見るのはとても悲しいことだ。
チェーンメールはいわば、「どうやって他人に次のメールを回させるか」ということを競う、素晴らしい表現空間として扱われるべきであって、決してつまらない脅迫文などを回すための場所ではない。「はなげ」をみよ「達磨」をみよ。彼らは初期には何人に回せといわなくとも、自然にみんなに回っていったではないか。「鉄腕ダッシュ」を見よ。あのチェーンを知った瞬間。「うまい、やつらならやりそう。良く考えた。」とうならされたではないか。
人の手を経ることにより、さらに変化していく（退化でもあり、進化でもある）、インターネットという媒体を通してしか表現できないチェーンメール。
それもまたいたずらの一環であり、芸術の一種であり、一つの文化であることを、チェーンメール作家は理解して欲しい。
（私はチェーンメールを観察するのが好きなだけで、出したりまわしたりはしないよ）
11/6
今日は定期を買わねばならぬので、6時までに三和銀行へ向かって、
男らしくスーツでダッシュ
余談ではあるが、実は今日は電車が送れて大遅刻だったので、定時前だということは秘密だ。
6時になれば手数料100円がむしりとられてしまう。
たかが100円と侮ってはいけない。
なぜなら勝負においては、勝負にかかっているものなど問題ではないのだ。
大体、100円ですら、利息が赤字に成りかねない。
いや、勝負にかかっているものなど問題ではない。
先日偶然みつけた近道を通過。
これなら間に合う。と、角を曲がったとき、
「ここはどこだ…。」
11/5
人生はゲームだ。
という言葉を誰がいったのか知らないが、良い言葉だ。
だから、自分のパラメータをある程度把握できると、超リアルタイムRPGが楽しめる。
例えばあるできないことができるようになれば、それは自分のスキルが1ポイントアップしてるのだ。
逆にいえば、スキルを１ポイント上げるには、倒せない敵を倒せるようにならなければならない。
本を読むのはメタルスライム倒しての経験値稼ぎだ。
そういう風に見れば、少しは勉強も楽しくなるかもね。
ただしリセットは不可だ。
11/5
そろそろ自分的にマンネリ化の波が襲ってきたような気がする。
いつか日記に書いた、「切るものはは違っていても切り口が同じ」状態になってきている。
良いエッセイでも読んで、新しい切り口を見つけたいものだ。
こういうことは決して日記を書くためにやるべきではない。
たくさんの切り口を手に入れるということは、それだけ物を見る視点が増えるということで、
視点を増やすのは、やっておけばもう少し若くなくなったときに、きっと役に立つはずだ。
11/5
11/5
ユーザインターフェースに関する勉強の非薦め
人間は知っていいことと、知って悪いことがある。ユーザインターフェースに関する知識も知って悪いことに入るだろう。
なぜなら、現代人の価値観として、「使い方を誤ったのは間違う人が悪い」という悪の価値観があるからだ。
そのため、ユーザインターフェースを勉強して、「ここはこうすべき。そうすれば覚えやすく誤りも減る」ということがわかるようになってしまうと、
必然的に物にあたる。
これが先ほどの価値観とあいまって、他人からは怒られる。
本当にそれでいいのか？人類。
極端な例え話を挙げよう。
新製品のCDプレイヤがあったとする。再生と停止ボタンがあるが、同じ形で何の印もついていない。
マニュアルには
「奇数日は左側のボタンが再生で右側が停止です。偶数日はその逆です」
と書いてある。
という架空の商品だ。
もし、これで操作を誤って、物に当り散らしてる人間がいても「マニュアル読まないのが悪い」
と、あなたは言えますか？
このボタンがCDプレイヤではなく、核のスイッチとトイレのスイッチであった場合、責任を負う人間は「間違えて核のスイッチを押してしまった人間」だと思いますか？
それよりも、こんな間違いやすい、理解に苦しむインターフェースを作った人の責任だと思いませんか？
人間は間違うことは当たり前。
であるからして、物を作る人達はそれを使いやすく作るのは当然のことです。
だから、自分よりも遥かに腕が未熟な人（プロ）が作ったデザインの道具を使わされて、怒っている人がいても、それはクソゲーつかまされて怒っている人と気持ちは同じなのです。
むしろ、われら消費者は当然の権利としてむしろ怒るべきなのです。
11/4
わけあって、日本刀（の模型）をスクラッチ（そのうち公開）
自分で作るとわかるが、日本刀というものは絶妙なバランスで作られているのがわかる。
はっきり言って0.1mm以下の単位でバランスをとらなければ美しくならない。
それくらい、本物の日本刀というものは精巧な作りをしているのだ。
究極の機能美といってもいいだろう。
11/3
すっかり忘れていた目次を更新しようとしてたら、4/6の日記の記述にこんなのがあった。
>そう、ビルは我が家にいるのだ。
>今まで私はなにをやっていたのだ。そこ以外にビルの居場所などないではないか。
>私は電車を駆け下り、家へ向かって小走りに駆けて行った。
>
>ちなみにビルはペット。種別不定。
>さらにそこからでっち上げた始まり。
>
>私はそれにビルという名前をつけた。
>彼女は…、そう実は彼女はメスだったのだが、改めて考えてもこれ以上の名前はないと思う。
>ビルは気がついたときには私のそばにいた。物心ついた頃から側にいたというわけではないが、気がついたときにはいつの間にか私の側にいたのだ。
なんか面白そうだ。続きが見たい。
ちょっと書くか。
ビルは何をやっても不器用だった。いくらしつけても下は家のあちこちに行うし、油断してテーブルに食べ物を置けば気がつくと無くなっている。
ある日、私の大事な「〜（決めてない）」に小便をかけられているのを発見した。私はついに堪忍袋の尾が切れて、ビルに「〜（決めてない）」と言いいはなち、
11/3
昨日、メモリ１２８Mがいつのまにやら税抜き8000円を切っていたので、思わず買ってしまった。
２５６Mの過渡期のような気がしなくも無いが、まぁいいじゃん。
11/3
祝日とはなんだろう？
庶民にとっては祝日は休めて嬉しいので存在は賛成どころか、もっと増やせという感じだ。
が、例えば今日は文化の日だ。
じゃぁ、文化の日だから、日本の文化を見つめなおそうという人はさらさらいない。
ならばあえてなんとかの日とつける必要は無いのではないか？
少なくとも、何か名前を変える必要があるのではないか？
祝日の日付を見なおして、国民的イベントの日であるクリスマスなどを祝日にしたほうが良いのではないか？
本心では変更の必要性は感じていないが、こういうのを機会に祝日というものを、見なおすのもいいだろう。
こういうのを「当たり前じゃん」で済ます人は多いだろうが、例え当たり前が正しいという結論であろうとなかろうと、当たり前を疑う行為というのが、本当の常識を疑うという行為なのですよ。
普段からこれをやらずに、間違った常識を見ぬこうなんて、絶対に不可能だということにちょっと考えればわかりますよね？
11/3
暗黒流れ星最高！！
すげー受けました（炎の転校生）
11/2
部長面接
別段喧嘩を売る気はないので、収支雑談に終わった。
もっとも「COBOLは駄目」はいっぱい言ったが。
11/1
本を買うにはキロ単位
なので、今日は３Ｋｇほど購入
| SEO | [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送 | ||
