はてな匿名ダイアリー > キーワード > デザインパターン

「デザインパターン」を含む日記

はてなキーワード: デザインパターンとは

2012-02-07

■http://anond.hatelabo.jp/20120206232407

個人的にはアルゴリズムの本に載っていることやデザインパターンぐらいはやれよと思う方なんだが…

あれでもましな方なの？

Permalink | トラックバック(0) | 15:52

2011-03-19

■ドラゴンボールで学ぶオブジェクト指向Z

これは http://anond.hatelabo.jp/20110316202255 の続編です。

GTをやる前に改を書いてくれている人がいてとてもしっかりした内容なのでちゃんと勉強したい人はそっちを見てね！

d:id:ryoasai:20110317 - ドラゴンボールで学ぶオブジェクト指向　改 | 達人プログラマーを目指して

またオブジェクト指向については

d:id:m-hiyama:20080109 いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ | 檜山正幸のキマイラ飼育記

がとても詳しいです。合わせて読むとかなりしっかりと理解出来ると思います。

変な書籍を買うよりこちらがオススメです。

はじめに（いいわけ）

ホットエントリに行くとは思っておらず、皆様ありがとうございます。

「ドラゴンボールをオブジェクト指向にする」というコンセプトではなく、「オブジェクト指向を（無理矢理）ドラゴンボールで説明する」という遊びだったので

プログラマーの方々にはツッコミを受けてしまいましたがここは遊びだと思って楽しんで下さい…。

ドラゴンボールは小さい頃から大好きでしたが流石にうるおぼえ過ぎました。

専門家の方々からも厳しいツッコミを受けました。

それはさておき「説明する題材を決める→好きな漫画から無理矢理当てはまりそうな例を考える」という思考実験なので、気が向いた方は色々考えてみると楽しいと思います。僕は楽しかったです。

・ジョジョの奇妙な冒険で学ぶオブジェクト指向

　スタンドとか波紋法とか色々面白そうです。

・ジャニーズで学ぶオブジェクト指向

　これは難易度が高そうです。

・BLで学ぶオブジェクト指向

　継承＝誘い受け、移譲＝ヘタレ攻めだと思います。

結論

やっぱりドラゴンボールで例えると分かりやすいな！

無理がある！

ドラゴンボールで学ぶオブエジェクト思考Z ドラゴンボールで学ぶデザインパターン

デザインパターンとはドクターゲロが考えた「こうやって設計すれば色々捗るぞ」という例のことです。実際はGoFという人たちが考えたもので23個のよくあるパターンに名前を付けて整理してくれたわけですね。

23個の中にはブルマさんですらわからないものが多いので（さすがドクターゲロですね）良く使う、代表的な物をいくつか紹介します

Singleton パターン

Singletonは世界に一つだけしか存在出来ないようにする方法です。

balls = new DragonBalls(); //これでは誰でもドラゴンボールを作れてしまう！
balls.callShenron();

クラスの中にはいくつかのメソッドがありますが、簡単に言うと外から呼べるもの、外からでは呼べないものの

二種類があります。そうやってメソッドを保護することで世界の崩壊を防ぐわけですね。

基本的な戦闘力をアップさせるには本人の努力が必要になり、外から簡単に挙げられてしまうとジャンプの三本柱が外れてしまいます。

（某漫画などは努力しなくともあがったりしますが）

ただナメック星の最長老や界王神などはかなり偉いので、本人の才能を引き出すことが可能でした。

現実には思いつきのような仕様を後から言われることが多々あります。困ります。

//地球上にひとつだけ存在するドラゴンボールをつくろう
class DragonBalls{
	private DragonBalls(){
	      //ドラゴンボールを作れないように生成メソッドを保護します。
	}
	static function sagasouze(){
		static singleton_dragonball;
		//ドラゴンボールを生成。
		//DragonBallsクラスの中なので、保護してある「new DragonBalls()」を呼べます。
		if(!singleton_dragonball)singleton_dragonball = new DragonBalls();
		return singleton_dragonball;
	}
}

これで界王神から怒られることもありませんね。

プログラマーは神なのでドラゴンボールを作れます。

Proxy パターン

何かの処理を行うためにProxy、代理人を立てる設計です。

地球のみんなは地球語しか話せませんが、ナメック星にいるクリリンを通して願いを叶える必要があります。

クリリンももちろん地球語しか話せませんが、ナメック語を話せるデンデがいるため、地球のみんなは願いを叶えることが出来ます。

class Kuririn{
     private dende = new Dende();
     
     function request( wish1, wish2, wisth3){
		this.dende.request(wish1);
		this.dende.request(wish2);
		this.dende.request(wish3);
     }
}

kuririn.request(
	"ピッコロを生き返らせてくれ",
	"ピッコロをナメック星へとワープさせてくれ",
	"ナメック星にいる孫悟空とフリーザ以外を全員地球へとワープさせる"
);

この場合のメリットはデンデが何をやっているかクリリンをプログラミングした人が知る必要が無いということです。

デンデを通して願いと伝える実装だけ行えば大丈夫です。

地球の人はナメック星にいるナメック星人が「デンデ」であることを知る必要もありません。

それでも願いは叶うんです。

本来であればデンデやクリリンは願いが叶うのを待つ必要がありましたが、地球の人は一気に伝えることが可能なように設計しました。

それでないと不便ですからね。

//デンデクラス。ナメック星人は英語でNamekianらしいです。
class Dende extends Namekian{
	function translate(word){
		namekian = *****//ナメック語に翻訳します。
		return namekian;
	}
	function request(wish){
		static polunga;
		if(!polunga){
			polunga = DragonBalls.spell("タッカラプト ポッポルンガ プリピット パロ");
		}
		polunga.ask(this.trasnlate(wish));
	}
}

Template Method

大まかなアルゴリズムだけ決めておいて、実装はサブクラスに任せる設計がTemplate Methodです。

ナメック星に行く方法を考えた時いくつかの方法がありました。古い宇宙船を探してきて直して載せて…っていちいち書くより同じメソッドでナメック星に行けたほうが便利ですね。

abstract class WayToNamek{
	abstract function prepareSpaceShip();
	abstract function launchSpaceShip( ship ) ; 
	function gotoSU839045YX( people ){
		ship = prepareSpaceShip( );			//船を修理します
		ship.load(people);					//人を載せます
		this.launchSpaceShip(ship);	//船を出発します。
	}
}

ナメック星に行く方法を定義したので「ブルマ、クリリン、悟飯」組と「悟空」をそれぞれナメック星に連れて行きましょう。

way = new WayWithKamisamaShip();
way.gotoSU839045YX( buruma, kuririn, gohan );

way = new WayWithSaiyajinShip();
way.gotoSU839045YX( goku );

と簡単に方位SU83、距離9045YXまで乗員を連れて行くことが出来ます。

二つの方法を実装します。神様の船を修理して行く方法と、サイヤ人の船(悟空が乗ってきた船)で行く方法の二つです。

//神様の船で行きます。
class WayWithKamisamaShip extends WayToNamek{
 	function prepareSpaceShip(){
 		return new KamisamaShip();　//船を準備します。神様の船を使います。
 	}
 	function launchSpaceShip(ship){
 		ship.inputByVoice("ナメック星に出発");	//
 	}
 }
 class WayWithSaiyajinShip extends WayToNamek{
 	function prepareSpaceShip(){
 		return new SaiyajinShip();      //船を準備します。サイヤ人の船(フリーザの船？)を使います。
 	}
 	function launchSpaceShip(ship){
		//audio = new HighSpecAudio();
 		//ship.setAudio(audio);
 		ship.turnOnCenterButton();	//真ん中のボタンを押すだけ
 	}
 }

元になる船も違いますし、発射の仕方も違いますが同じ呼び出し方が出来ます。

オーディオの位置が決まりませんでしたが、今回の運用では不要とのクライアントからのご意見でしたのでだったので

せっかく用意したオーディオも無駄になりましたが、コメントアウトしてあります。

他のパターン

他にもまだまだあります。のんびり紹介していこうと思います。

ではでは。

Permalink | トラックバック(1) | 02:03

2011-03-16

■

http://anond.hatelabo.jp/20110316202255

デザインパターン編を書いてたら99ブクマだと…。なんだかすみません。

あと増田で書くの初めてで記法がちとわかっていなくて見づらくて申し訳ないです。

ブクマ コメントへレス

＞おもしろい。でもJavaとJSとRubyじゃ同じオブジェクト指向でもまったく違った設計と思想になるのでまとめて説明は難しいかも

言語＝世界として、どんな世界がいいか考えましょうという話に持って行きたかったけど難しかったですね。

＞ASしらないけど classが使えるJSっぽいところみるとASなんですかねこれ

＞@shinout 面白い！けどいろいろ間違ってる！！コード動かしてみいや

それっぽい言語なので動きません。JavaとかASとかそのへんですねー。

その割に一部ちゃんと書いてるのが誤解しそうですね。

＞ OOPを習得した PGとそうでないPGとの生産性の差がドラゴンボールで言うところの戦闘力の差という比喩でたとえるとよい。初心者 PGが何人集まってもかなわないところがある。

「ドラゴンボールで学ぶ開発」というタイトルで是非ｗ

＞17号と18号が逆

すいません…直しました。

＞セルはis-aはなくhas-aで実装した方がいいような気がする。

セルってチート臭いですよね。くらった技を覚えるブウの設計と、遺伝子を持っているから技が使えるセルの設計をどうするかは議論になりそうです。

＞なんか、むしろ分かり辛くなってると思うけど、心意気やよし！

＞かりやすいんだかわかりにくいんだか

無理がありました。

＞連載はextendされたけど、主人公の継承には失敗したよね

素晴らしいコメント。設計ミスで主役になれなかったのは運用でカバー出来ましたね。

＞セルはクラスの承継よりもオブジェクトのコンポジションの方がいいのか分からない。

http://anond.hatelabo.jp/20110316215156

で突っ込まれてる内容の方がいいかもしれませんね。

でも悟空やベジータは吸収じゃなくて細胞を合成してる？とかなので17号、18号とは別にする必要があったりします。

＞その他残念とかダメとか誤字とかのコメント

申し訳ありません…。

Permalink | トラックバック(2) | 22:46

2010-11-07

■プログラムを書けない奴は馬鹿

手順を考えて、その手順を書くだけ。

言語もあらかじめ決められた手順に沿って解析されて実行されるから、オートマトンやBNF 記法、構文木などの仕組みを一通り覚えてどういう機構でチューリングマシンが原理的に実行可能なコードへと落とされるかを理解すれば言語自体も覚えるのなんてそんなに難しくない。

手順を考えるなんて、人間が生活する上でいつもやっていること。

プログラムを走らせるためのデータ構造を考えるのに苦労するという話も聞くけど、プリミティブな要素が数値、型へのリファレンス値しかないんだから大体は離散数学で使うグラフの初歩的な知識があれば事足りる。GoFのデザインパターンなんてまさにそう。

これらは、専門用語の知識は知らなくても概念としては理解できて当たり前の事だから書けることもそれほどすごい事ではない。

もう大分前から普通の大学でもC言語を上手く教えてるし、プログラミングは特別なスキルではない事が証明されている。

Permalink | トラックバック(3) | 18:30

2010-07-25

■プログラミングを身に付けるには

http://anond.hatelabo.jp/20100725025127

"どうすればいいか"を教わって、プログラミングが身につく人は多くありません。"なにをやりたいのか"を自分で生み出せないと、詰まってしまうし、なにより楽しくありません。

やりたいことがあれば手段は後からついてきます。これは物作り全般に言えることです。特に学び始めにおいてモチベーションを維持し勢いをつけるのに大事なのは"やりたいことがあるか"、もっと具体的に言うなら"作りたいものは何か"です。これがないと始まりません。それがどうしてもないなら、そういう状況に自分を追い込むのも有効です。仕事でどうしてもやり遂げなければならない状況に追い込まれれば人間 0 からでも身につきます。実際自分がそうでした。

とかく、プログラミングというのは手段さえ知れば、あとはだれがやっても同じ結果が出る生産業だと誤解されがちです。そういう認識で学ぼうとしても楽しくありませんし、本質を掴みにくいので応用が利かなく上達しにくいです。

本質は絵や音楽と同じです。言語を覚えるということは道具の使い方を覚えることでしかありません。音楽の理論や絵筆の使い方を知っているだけで、すぐに素晴らしい音楽や絵ができるでしょうか。殆どの人がそうは思わないはずです。プログラミングもそれと同じです。作りたいものがある人が圧倒的に強いのです。

また、やりたい分野によって向いている言語は違います。

んー、ここまで読んでも｢やりたいことはないけどとりあえず勉強したい｣というなら、すぐに動くものをつくりやすい言語がお勧めかなあ。

Google App Engine で Python をやるとか。 Python のいいところは、明快で作法にあまり迷わなくていいところです。自分がまったく言語やったことない知り合いにすすめるとしたらこれ。

レガシーではないちゃんとした JavaScript (http://www.crockford.com/javascript/ この辺にあるような) もいいです。ブラウザですぐ動きますし、 Firefox 環境なら本格的なデバッガまであります。 JavaScript は非常に誤解の多い言語ですが、悪いものではありません。お手軽にグラフィカルなものを扱える、結果がわかりやすいので初心者向けです。それでいて、拡張性が高く、プログラミングに必要な概念、ロジックの殆ど再現できる底力も秘めています。

Perl はレガシーな作法がいまだに見受けられる (Perl って CGI のことでしょ的な解説が未だにある) のですが、初めから strict に慣れて、 CPAN にあるようなスタイルを参考にして、初めから OOP に突っ走るなら今からやってもいい言語です。 CPAN 等のリソースの豊富さとコミュニティの広さが強いです。ただ、懐の広さ、できることの多さゆえに初心者向きではないところもあります。

PHP はお勧めしません。理由は適当に検索してください。 PHP5 でかなり良くなりましたが、逆に言えば 4 と 5 では別言語と言っても良いほどです。古い考え方と新しいスタイルがごったになりすぎていて、かつて同じような状況にあった Perl に比べても、洗練されたスタイルを学びにくいと思います。また、ロジックの面白さに感動するような部分が PHP にはちょっと足りないです。

MMORPG やそのエミュレーターの中には、 Lua を使って AI やマクロやイベントスクリプトなどを組めるものがあります。すぐに結果が出て自分の役に立つものが作れるので、既にその手のゲームが趣味ならお勧めです。こうした用途では、自分の望む世界を構築するために嫌でも物事をモデル化して考えるので、自然と OOP 的な考え方やデザインパターンが身につきます。

VB は簡単に GUI アプリケーションが作れるのでやる人が多いですが、癖が強いし応用がききにくいのでお勧めしません。また、公開されているソースコードが少ないことも学ぶには不便です。

Ruby はそれほどやりこんでないのでコメントはしないでおきますが、悪くはないと思います。

C++ は何をすればいいのか？を聞いてる人にはすすめにくいです。作りたいものが明確にあり、ロジックを見つけることで応用が利く人ならほっといても覚えるでしょう。自分は、必要に迫られて身につきましたが・・・

個人的には、作りたいものがあってそれにマッチしてるなら、関数型言語を最初にやったっていいと思います。一度ロジックを掴み取る能力がついてしまえば、第二第三の言語は猛スピードで身につくので。

人に見せて使わせてレスポンスをもらうことが大事

作ったものを公開して、人に見せたり使わせたりして、レスポンスを得るというのはモチベーションの維持や上達に非常に有効です。むしろ、早く上達したいなら必須と言ってもよいです。プログラミングの場合はこれがおざなりにされがちです。

絵を上達したいなら、 pixiv を薦められますよね。今下手かどうかは関係ない。上手くなりたい人が沢山投稿してる。歌が上手くなりたいなら、人前で歌う事は避けられない。ニコニコ動画などで公開してる人がいるよね。人の作品をみると刺激をうける。これはすごいパワーだってのはわかると思う。

プログラミングだって全く同じです。なのに、プログラミングは引きこもって一人で勉強する人が多すぎる。絵や歌は公開しても人に害を与えないけど、プログラミングはバグやセキュリティホールがあったら人に害をあたえるかもしれない、といった印象が強いのかもしれません。

それでも、もっとコミュニティに参加したり、作ったものを公開することが学び始めのうちから重視されていいのは事実。そういった面から考えると、バグやセキュリティホールが出来にくく、安全で、危険な動作がしようもない実行環境があり、加えて Web に公開しやすい言語が学びはじめに向いています。

こちらも参考にしてみて下さい

http://d.hatena.ne.jp/Hamachiya2/20090721

http://d.hatena.ne.jp/Hamachiya2/20080131

学校に行く必用があるのか

学校に行けば一人で学ぶよりは後押しや出会いがあるかもしれませんが、”やりたいこと””必用なこと””作りたいもの”が無い限り、殆どの人は身につきません。

また、残念なことに講師にも大変当たり外れが多いです。自分は専門学校にいったことはありませんが、講師の知り合いがいるのでよく学生さんの話を聞きます。結局の所、しっかり身につく人は、家に帰っても色々作りたいものを作って公開したり、著名なプログラマ達のブログを読みまくったり、フォーラムに出入りしたり、ML に入ってたり、 twitter で刺激的な知り合いをつくるとかしていて、そういうところでめっちゃ差がつきます。

学校に行くなとまでは言いませんが、学校いかないで身に付ける人は本当に多いし、学校いって身につかない人も本当に多いということは考えて下さい。

26日追記

ブクマ増えてた！ありがとう。

元増田さんがどの言語をやれば・・という方だったので仕方なくこのような書き方になってしまいましたが、作りたいものが既にある人はあまり”どの言語をやるか”には拘らなくてよいと思います。

そんなことよりも、今必用で/気軽に/すぐ結果がわかることをやるのが、始めてのプログラミングには大事。だから本当は、どの言語をやるかよりも何を作りたいのかを先に見つけてほしい。

目の前の意外なところにプログラミングは生かせます。できるだけ身近な、すぐ効果がわかるところからとりかかった方がプログラミングの楽しさにはやく気付けるはず。

動画編集や MAD 作成が趣味なら、 Avisynth に触れ、AviUtl や NiVE のプラグインを作ってみる
音楽やってるなら、 SuperCollider に触れてみる
ゲームの MOD を作ってみる

みたいな導入口でもいいんだ。

例えば C++ でのプログラミングを初心者が 0 からやるのは難しいだろうけど、既存のアプリケーションのプラグインなら開発のためのテンプレートや目的に近い作例があってコードも短いからそれを改造するところから始められる。需要があるから楽しいよ。

目の前に実用的な目標があるってのが大事。

Permalink | トラックバック(6) | 04:34

2010-02-04

■そして後ろから撃たれる

コンピューターは大好きだった。

学生の頃からサーバーとかプログラムをやってたおかげで、SIの会社に入社してからはちょっとしたヒーローだった。

寝る間も惜しんで働いて、案件を片っ端からざくざく片付けた。

元々スケジュールも厳しいので納期優先だ。みんなそれを望んでた。

適材適所に合わせて効果的な言語、環境、フレームワーク、ライブラリを選んで組み合わせた。

ライブラリやフレームワークにバグがあれば自分で直した。OSS万歳だ。

本もばりばり読んだし、勉強会にもたくさん顔を出した。

結果を残してきたつもりだった。

これがSEの生きる道だと信じてた。

そうして何年かが過ぎて、案件の山が落ち着いてきたころに異変が起きた。

周りが一斉に今まで構築したシステムが保守できないと言う。うわ。顔がマジで怖い。

遊び半分でシステムを作られても困ると言う。デザインパターンやフレームワークは趣味ですか。そうですか。

一から十まで書いてあるドキュメントや、コードの中身も手取り足取り教えてくれないと無理らしい。

技術を自慢したいだけなんじゃないかとか言う。自慢するならもっと別の使ったのになあ。

いやー、さっぱりわかんないんですよねー。という声があちこちから聞こえてきた。

今までがんばってきたことがばからしく思えてきた。

当時彼らは何をしてたんだろうか？

技術を覚えることよりスパゲッティの山と格闘することがお望みか？

標準化？標準生産性？一体「標準」って誰のことだ？

自分が出来ない理由を他人に求めてるようにも思えたが、もう何も言わないことにした。

過労と後ろから撃たれたダメージで病院に通い、ひっそりと会社を辞めた。

今？もちろんコンピューターは好きだ。でもコードはかけなくなった。思考が5分と続かない。

良くできる今年卒業の学生の皆さんへ。どうか出過ぎないように。

頼れる仲間無しで、絶対に一人で本気出してはダメ。絶対。

Permalink | トラックバック(2) | 01:45

2009-12-20

■ビジネス・生活-1

◆日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介

あなたは、日本依存症にかかっていませんか？

日本依存症とは、日本でしか仕事を得られず、

日本でしか生活ができなくなる、危険な病気です。

日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。

●会社依存症の恐ろしさとその回避策

会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。

会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。

また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。

上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。

なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。

このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。

そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。

たとえば、以下のようなものが考えられます。

・要求分析、要求仕様定義、システムアーキテクチャ設計、RDB スキーマ設計、サーバの負荷分散設計、各種サーバのパフォーマンス解析・チューニング、デザインパターン、マルチスレッドプログラミング、システム管理、ネットワーク管理

・マネージメント、プロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル

・普遍性の高いコンピュータサイエンスの基礎

・Unix、RDB、正規表現、Java、Perl、TCP/IP、.NET、C#

日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。

いまいる会社が今後もずっと浮いたままだという保証はありません。

一つの会社に依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。

いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。

●国家に依存する危険性

国家に対しても同じことが言えます。

政府は全ての国民を幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。

ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。

もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。

もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家に投票すべきですが、常に正しい政策を実行してくれる政治家が自分の選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家に投票してくれるとも限らないというのが、世の中の現実です。

だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。

たとえば、金持ちばかりが得をし、平均的な労働者が搾取される最悪の格差社会になってしまうかもしれません。

あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者の所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。

あるいは、少子化対策で、実質的に独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。

あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。

あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。

あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員の自分に酷いしわ寄せが来るかも知れません。

労働者保護や消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。

要するに、投資において、全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。

今までは日本が世界一豊かな国だったので、

この国にずっと住み続けるのが一番賢い戦略でした。

しかし状況は変わりました。

いまや日本よりも豊かな国や都市がどんどん生まれつつあります。

日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。

本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。

いまいる国家が、今後もずっと浮いたままだという保証はありません。

一つの国家に依存しすぎると、その国家が沈んでいくとき、酷い目に会います。

いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1

●国家依存症と愛国心は別の話

こういうことを言うと、「おまえに愛国心はないのか？」と言い出す人間が時々いますが、依存症と愛国心とは別の話です。

これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。

経済的にも精神的にも自立していることと、夫を愛することは両立します。

夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。

むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。

そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。

「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。

むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。

●日本以外にも快適に暮らせる国や都市はたくさんある

日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。

むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。

食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市は世界中にたくさんあります。

どんなところでも、けっこう住めば都なのです。

また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険な地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。

それに、どうせネット環境さえあれば、世界中どこでも、twitterやtumblrやmixiで遊べるし、ブログのコメント欄でクネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像をダウンロードすることもできるし、はてブで脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。

「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。

せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。

●依存症からの脱出は難しい

ギャンブル依存症、アルコール依存症、買い物依存症、恋愛依存症、セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。

簡単に日本依存症を抜け出す方法などありません。

また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。

●資産運用、または、プチ資産運用による脱日本依存

日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)

特定の国家に依存しない収入源を確保するわけです。

これに一番効果的なのが、資産運用で暮らせるようにすることです。

利回りのよい債権や株式に自分の資産を分散投資し、運用することは、どこの国に居住していてもできます。

日本の国債や株式で資産を運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本の国債や株式で資産運用することは可能です。

それどころか、そもそも、日本の国債や日本の株式で資産を運用しなければならないということはありません。

むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分の資産が大きく目減りしてしまうというリスクを抱え込むことになります。

資産は、全世界に分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中に分散投資しておけば、それほどひどいことにはなりません。

だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。

ここで、「日本がキャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか？」という疑問がわく人もいるでしょうが、そうでもありません。

まず、税金の徴収には、属人主義と属地主義の二つの方式があります。

属人主義とは、その人間の国籍のある国に税金を納めること。

属地主義とは、その人間が居住している国に税金を納めること。

日本は属地主義なので、自分が居住している国や地域に税金を納めることになっています。

このため、日本でキャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2

現在、属人主義を採用しているのは、アメリカとフィリピンぐらいなもので、極めて例外的なケースです。

ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。

また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間に国籍を与えてくれる国は、けっこうあります。

日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。

ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。

そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。

資産運用というより、プチ資産運用です。

そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。

●世界標準のITスキルによる脱日本依存

たとえば、前述のUnix、Web、RDB、Java、Perl、.NET、C#など、世界中に普及している技術の場合、そのスキルを身につけることで、日本依存から抜け出すことができます。

また、これらに関連する要求仕様定義、オブジェクト設計技術、デザインパターンを適切に使いこなしたクラス設計、プロジェクトマネージメント、スケジュール管理なども、特定の国家に依存しないスキルです。

これらのスキルを身につけたITエンジニアは、さまざまな国で職を得ることが出来ます。

実際、ボクの知り合いでも海外で働いているプログラマーがいます。

むしろ、日本よりも快適に働いているようです。

もちろん、これらの技術は、会社依存症から脱却するための技術としても有効で、きわめて安全性の高い技術だと言えます。

これらの標準的なITスキルは、このように、会社や国家を超越して有効ですが、それ以上に驚きなのは、かなりの長い時間をも超越する力を持っているということです。

たとえば、unixの基本アーキテクチャはボクが知っているだけでも十数年、ほとんど変わってません。マルチスレッドプログラミングやデザインパターンも十数年前に身につけたスキルは、かなりの部分、いまでもそのまま役に立ちます。はるか昔に覚えた、クロージャや再帰を使ったさまざまなプログラミングテクニックも、RDBのスキーマ設計のスキルも、ほとんどが、いまだに現役です。

TCP、UDP、IP、HTTP、SMTP、POPなどのプロトコル類もいまだに基本はほとんど変わりません。新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。Haskellのような関数型言語ですら、似たようなコンセプトのプログラミングアーキテクチャは昔からあり、十数年前にマスターした技術の延長線上でなんなくマスターできます。

このように、長期的に安定した技術やスキルを選んで身につけるようにすれば、会社、国家、時間を超えて、安定した収入源を確保できるのです。

ただ、注意しなければならないのは人材の需給バランスです。とくに、インドや旧共産圏からのプログラマの大量供給は要注意です。

一方で、ヨーロッパ、BRICs、VISTAなど、世界中で急速に経済が発達しており、ITエンジニアの需要が今後も全世界的に巨大化し続けるのは確実です。

ここでのポイントは、下級エンジニアや中級エンジニアは、需要はそれほど拡大しそうにないのに、供給は膨大になると思われるので、リスクが大きいということです。

つまり、下級エンジニアや中級エンジニアの場合、海外に行くと、日本にいたとき以上に悲惨になる可能性があります。安易に日本から出て行くべきではないでしょう。

一方で、上級エンジニアは技術分野にもよりますが、今後、世界中で爆発的に需要が拡大することが見込まれていますが、供給が不足する可能性は十分に考えられます。

従って、自分が今後上級エンジニアになる可能性があると考えている人たちは、この戦略に沿って日本依存症から脱却しておいたほうが良い可能性が高いです。

あと、もう一つ考慮すべき点は、上級エンジニアになるような人は生産性が高いため、今後、高額所得者になる可能性があるということです。

現在日本では、格差是正の機運が大きく盛り上がっています。

今後、この機運の盛り上がりに押されて、高額所得者を狙い打ちする形で大増税が行われ、酷い搾取の対象にされるリスクもあります。

このリスクに対する保険という意味でも、早めに日本依存症を治療し、いつでも仕事と生活の場を海外に移せるようにしておいた方が安全かもしれません。

●スモールビジネスによる脱日本依存

日本人が海外で暮らしてみると、さまざまな小さなニッチビジネスのチャンスに気がつくことがあります。

たとえば、日本にはあって当たり前なのに、その国にはない商品やサービス。

それは、日本のやり方を現地方式にアレンジすれば、それなりに繁盛する商売ができるかもしれません。

あるいは逆に、その国のおもしろい商品やサービスで、アレンジすれば日本でもウケそうなもの。

もしくは、現地の安い人件費を利用して、何かを作らせ、日本に持ち込むというパターンもあるでしょう。

実際、ネパールに小さな工場をもっていて、そこで自分のデザインした服を作らせ、日本に輸入して販売しているという女性に会ったことがあります。

こういうビジネスのネタをみつけたとき、スモールビジネスを興すスキルを持っていると、そのチャンスを活かして、その国で商売をはじめることができたりします。

とくに、最近急速に豊かになったアジアの国々では、日本がかなりブランドになっています。

とくに富裕層は、日本のさまざまな質の高い品々やサービスを求め、日本の産物に信仰のようなものを抱いています。

これをうまく利用することで、いろいろなニッチビジネスを作り出すことができるかもしれません。

スモールビジネスのスキルとは、小さな会社向けのマーケティング、マネージメント、経理などのスキルです。

たとえば、どんな小さなビジネスでも、どんな商品を、どんな顧客に売るのか、そのために、商品にはどのような魅力がなければならないのか、顧客は、どういう理由でその商品にお金を払うのか、どのようにして利益が出る構造になっているのか、などのビジネスモデルを組み立てなければなりません。

そして、いざ、ビジネスプランが出来たら、場合によっては人を雇い、契約を結び、信頼関係を作り上げ、法律に則って取引しなければなりません。関係者全員が気分良く仕事できるように、win-winの構造を作り出す必要があります。

また、さまざまな法律を調べ、その法律に則ってビジネスを運営する必要があります。

さらに、会社を設立し、会計ソフトで帳簿を付け、経理と資金の管理をする必要があります。

また、予算計画を立て、融資なり出資なりで資金を調達する必要もあります。

こういう小さなビジネスを最小限の規模ではじめてみて、いざ、顧客の反応が上々だったら、しだいに規模を拡大していけばいいのです。

思ったより反応が悪ければ、早期に撤退するか、あるいは、やり方を変えて再度トライしてみたりすればいいでしょう。

そして、スモールビジネスの醍醐味は、たまたま大ヒットしたときのうまみです。

日本のサラリーマンの頂点とも言える、上場企業の社長の年収でも、たかだか4000万円にしかなりません。

これに比べ、スモールビジネスをヒットさせた場合、実質的に年収1億円を優に越えてしまうということは、それほど珍しくないのです。

実際、ぼくの知り合いにもそういう人がいます。

「たかが自営業」とばかにできるようなもんでもないのです。

自営業は、あたると凄いんです。

●共通して必要な日本脱出アイテム

どのようなモデルで日本依存を脱却するのであれ、共通して必要な Permalink | トラックバック(0) | 22:10

2009-10-29

■http://anond.hatelabo.jp/20091029170021

もちろんそういう話は考慮した上で言ってるんです。

だから「使いこなせるかどうかはさておき」とわざわざ前置きしたわけで。

（つまり、「理解する」という言葉の意味を限定しているわけです）

まぁ多態性についてはそれなりに理解してないと話にならないだろうし、

デザインパターンはオブジェクト指向の概念そのものみたいなところがあるので、

オブジェクト指向をそれなりに理解してるなら必然的に理解してることになると思いますが。

（個別のパターンのクラス図を丸暗記したところであまり意味は無いし、それは理解したとは言わないということです）

Permalink | トラックバック(0) | 17:53

2009-09-30

■プログラミングの勉強するならJavaScript

オブジェクト指向言語としてどうとか、実行速度がどうとか、実行環境に依存しないかどうかとか、

そういったことは置いておくとして、初心者がこれからプログラミングを始めて、単なるプログラミングのお勉強にとどまらず、

何か他人とは違うことをしたいという場合には、迷わずオススメしたい言語がある。それはなんだろうか？

ってもう答えは出ている。JavaScript。タイトル見れば分かるじゃんww

なぜJavaScriptが偉大かというと、他の誰もJavaScriptをまともに出来る人なんていないからwwwww

はてな社員のあの人とかあの人みたいなのは別にして、普通にIT業界とか見ていたら分かるんだけれども、

なかなかJavaScriptがまともに出来る人というのが見あたらない。というか、いないんじゃねとツッコミたくなる。

だから、JavaScriptをキッチリね、キッチリが大事ではあるけれども、キッチリお勉強したらば、それはもう他人と大きな差がつくこと間違いない。

これだけAjaxとか言われているわけだから、もう重要な言語であることには間違いないけれども、キッチリできる人がいないので、

キッチリ出来れば、一部の企業からは重宝される。もちろん、一通りの言語は出来ないといけないに決まっているだろう馬鹿、と

言いたくなるような人もいるかもしれないが、とりあえず、JavaScriptマスターしますたと言うだけでかなり魅力的な人材。

とにかく常識的に考えて、JavaScriptくらい、重要でありながら優れた人材がいない言語は無いし、これは勉強するしか無いわけJK。

よくJavaScripterが「JavaScript第5版」について話すのを聞いていると、全部把握していないような人が山のようにいるわけJK。

だからもう基本のところできっちり把握していなくて、こんなもの調べれば分かるんだから覚えなくて良いと開きなおっちゃってる有り様だから、

これはもうどうしようもないと言わざるをえない。みんなJavaScriptを真剣にやっていない。それだけでなく、真剣にやっているとおぼしき

人までもが、ぜんぜん理解が足りていなかったりするからもうどうしようもない。こういう状況だからこそ、まじめにJavaScriptを

やればきっと良い結果がでるのではないかなということを言っているのでおじゃる。繰り返すように、JavaScriptは重要な言語であるし、

いまはそんな人少なくなっていると思うが、言語としておもしろみのないものでは決してない。JavaScriptやるだけで、オブジェクト指向の

いろんなことのさわりだけでもつかめてしまう。というか、俺はデザインパターンまで勉強できてしまった。というと、自慢に聞こえてしまうが、

そうではなくて友人連中もみな勉強した。とにかく、簡単なのだから、できてしまうのである。JavaScriptは確かにブラウザごとの差など

ややこしい部分があったりするが、べつにそんなことは大したことはなくて、実際に、覚える量は大したものではないと思う。

情報がまとまっていないから覚えるのが大変であるかのように錯覚しているだけで、リファレンスをみんなで構築し、仲間うちで利用

するようにしたら、とても効率よく学習できることをここに助言しておく。とそんなことはどうでもよくて、とにかく量としては多くないと。

要するに、JavaScriptは多くなくて簡単だし重要だし強力だしお勉強になるしお仕事になるので勉強したらよい。

それなのにいまだにマトモに勉強していないような人が多いのはどういう了見なのだろうか？これは真剣に知りたい。

トップの人がマトモに勉強していないと、その中で本を書いたりした人がクソな本を出して、それの悪影響を受けるということになる。

これではなかなかマトモな勉強しようにも出来ないという感じになるのではないか。いや実際には、大半の本はクソだと分かるから、

最初から相手にしない感じで良いと思うし、それよりはネットからの情報をもとに先ほども触れたようにリファレンスを社内で構築する。

それで良いのであるから、本など大した問題ではないのだが、それをやっている人がいかに少ないかという現状を嘆いているということである。

つまり、トップの人がマトモに勉強していないと、本もろくな本がないということになるから、けっきょくなかなかスゴイJavaScripterが現れない

という事態がずっと続いているのではないかという気がする。それに拍車をかけているのは、古い作法をいまだに固持しているプログラマが

おおくて、新しいJavaScriptの知識や作法を学ぶための方法が個人の学習意欲と学習工夫にゆだねられているという点にあると思う。

おもうに、ネットなんか便利だけれども、受け身になってしまいやすいから、能動的に情報をどうこうしようという気力のある人が少ないような

感じがしている。だから、なかなかマトモに常に新しいことに取り組むような人が現れなくて、たまにそういう人が現れただけで注目される

という滑稽なことになっている。別にそんなの凄くないよというような人がもてはやされたり、すごくないJavaScript記事がもてはやされたり。

Permalink | トラックバック(3) | 00:09

2009-08-13

■http://anond.hatelabo.jp/20090805183833

2年前、31歳で職業プログラマになって楽しくお仕事してる身としては、何を悲観してるのか全然理解できないのです。

中学でプログラミングに出会ったのは一緒。でもN88-BASIC。Cは大学上がってからかな－。大学と言っても医学部なんですが。

やっぱ自分は医療に全然向いていないという確信を持てたのが研修医3年目というかレジデント1年目の26歳で、しかもそこですぐにはプログラマに転身はしませんでした。

百科事典なんかで見て用語だけ知ってた情報科学のいろんな概念に憧れてて、こういうのわからないまま職業プログラマにはなりたくないと思って、理工学部と院行きました。20代終わりの時間なんて1年だって無駄にしたくはないけど。このへんの学費とかについては研修医時代の稼ぎが有難かった。

情報科学自体は最高におもしろくて無駄な時間じゃなかったけど、まあこれが仕事に直接役に立ったりはしません(笑)。教養ってやつ。Javaとかデザインパターンとかの実用面のスキルもちょっとは手に入れたけど、こういうことは専門学校と特に変わらないレベルでしょう。

年収とか、医学部の同期に比べるといま何分の一なんだろうなー。　って考えると、多少の年収の高低とか全然気になんないですね。

で、質問。26歳って、何をするのにどう遅いんですか？

Permalink | トラックバック(0) | 22:10

2009-08-07

■優秀な女子学生に起こる逆行(退行)現象

あれは私がまだ大学助手をしていたころだから5年ほど前のことだと思う。

私の勤めていた大学(情報系)では「SEX 研究会」みたいなサークル活動が行われていて

SEXの講義を受け持っていた私はそのサークルにちょくちょく顔を見せるようになっていた。

そこにはとびっきりかわいい女子学生が一人いたのだけれど、その子は子供が大好きで

「自分でも子供が作りたい」と一念発起して子作りコンテストに作品を出品することになった。

しかし、彼女は不妊治療の講義を1年くらい受けているものの、

本格的なモノをさわった経験がなく、ひとりでは行き詰まりをみせているようだった。

彼女はひとりでいることが多く、パソコンに向かって黙々とローターを動かしているのをよく見かけた。

それを気にかけていた私はたまに彼女をランチに誘うようになり、彼女の方もしだいに私に打ち解けてきた。

私たちはだんだんと仲良くなっていった。私は彼女のキュートな笑顔に魅了されていった。

ある日、彼女が私のもとにやってきて、もじもじと顔を赤らめながら上目づかいにこう言った。

「先生、頼みごとがあるんですけど・・・」

「なんだい？」

「メッセンジャーのアドレス教えてくださいませんか？」

これから恋の話が始まるのを期待したあなたは別のページを読んだ方がいいかもしれない。

これから始まるのはSEXの話だ。

その日から毎日のように彼女は私にメッセンジャーでSEXの相談を投げかけてきた。

私と彼女は連日のようにSEXについて語り合った。

彼女は大変優秀で、私の教えるSEXテクニックをみるみる吸収していった。

私は彼女の才能に驚き、彼女が将来優秀なビッチになるであろうことを確信した。

しかし、ときおり彼女が優秀であるがゆえの面白い逆行現象が起こったのだった。

ケース1

ある日、私は彼女がフェラチオを意識してSEXをしていないことに気づいた。

子作りではフェラチオを意識する場面というのは少ないが、まったく無いわけではない。

私は彼女にSEXがフェラチオを無駄に使っているということを指摘した。

しかし、よく聞いてみると、彼女はフェラチオ＝オーラルセックスくらいの感覚しか持っていないことがわかった。

驚かないでほしい。

私の経験上、情報学部の学生の半分以上がフェラチオとオーラルセックスの区別がついていない。

それを知っている私は落胆することもなく、落ち着いて彼女にフェラチオの説明をすることができた。

彼女は私の説明を聞き「よくわかりました」と、とびきりキュートな笑顔を見せた。

しかし、翌日、彼女の書いたコードを見てがく然とした。コードが次のように変更されていたのである。

	for (int i = 0; i < MAXHOGE; i++) {
		doSomething(i);
	}
	for (int i = 0; i < MAXFUGA; i++) {
		doSomething2(i);
	}

↓

	int i;
	for (i = 0; i < MAXHOGE; i++) {
		doSomething(i);
	}
	for (i = 0; i < MAXFUGA; i++) {
		doSomething2(i);
	}

彼女はこのコードを私に見せながら、相変わらずのキュートな笑顔でこう言った。

「このほうが使う精子の量が少ないですよね！」

ケース2

子作りコンテストの締め切りが近くなってきて、実際彼女はよく頑張っていたのだが、

どうしても間に合いそうになかったので、私も子作りを手伝うことになった。

とある部分で感じていたとき、重複したコードを見つけたので Template Method パターンを使ってやりなおした。

Template Method パターンというのが何かというと、同じことをする行為がいくつもの場所でばらばらにされないように

一つのコンドームだけ穴を開けて、それを継承して使いまわすという手法(デザインパターンの一つ)だ。

私はこの手法を彼女に教えようとは思わなかった。

なぜなら、彼女は継承だとか委譲だとかポリリズムとかがよくわかってないのだ。

驚かないでほしい。

私の経験上、情報学部の学生の99%が、その、ポリリーなんとかが分かってない。

私は彼女には何も言わずにこっそりコンドームに穴を開けた。

しかし、彼女はそれに気づいていた。

翌日から彼女のSEXのやり方ががらりと変わった。

彼女はいたるところで生SEXを実践するようになっていたのだ。

彼女は私のコンドームを自分で解析し、新たなる発見を独力でしていた。

重複したコンドームがあればそれを徹底して継承で解決しようとしている。

そう、生で中出し SEXだ。

生で中出し SEXの正式な定義は知らないが、彼女は IS-A 関係のない継承を使ってしらみつぶしに

重複コンドームを付け直していた。

そのコンドームを見せながら、天使のような笑顔で彼女はこう言った。

「こうするとコンドームの量が減りますよね！」

まとめ

私がこの文章で言いたいことは、知の高速道路を渡ってきた若い優秀なビッチは

ときおり妙な退行現象を起こすということだ。

それは普通の道を通ってきた古い世代にとっては実にみょうちきりんなことに思えるかもしれない。

しかし、それは彼らなりに理由があってのことであり、馬鹿だからやってるわけではない。

彼らは優秀であるがゆえにそういったことを起こすのだ。

そして彼らは優秀であるがゆえに、自分が間違っていることを理解するのも速い。

もし、あなたのまわりで若いビッチが逆行現象を起こすのに遭遇したとしても、

どうか暖かく見守ってほしい。

ちなみに

上で紹介した2件に関しては、彼女にはそのあと説明をして理解を得ることができた。

彼女は本当に優秀なビッチだ。

しかし我々はそれで油断してはならない。

いつか彼女はその可愛らしい顔をにっこりとほほ笑ませながらこう言うかもしれないのだ。

「屋内SEXより屋外SEXのほうが便利ですよね！」

Permalink | トラックバック(1) | 20:41

■http://anond.hatelabo.jp/20090807172637

これマジ？

俺、未経験（もちろん非情報系専攻）で業界に入ってプログラミングやることになって1年くらい経つ。

その間の学習の軌跡はだいたいこんなもん。

とりあえずK&Rを読まされてCをなんとなく学習。すぐにC++でコード書くことになる。C++も柴田ボウヨウかなんかの本を読む。
メモリ空間のイメージがつかめなくて苦しむ。参照と実体の区別がつかなくてオブジェクトをうまく扱えない。
メモリ空間のイメージを理解した。ここまでくると大体感覚がわかってくる。OOPとかすんなり理解できるようになる(もちろんギークレベルでは決して無い)。
デザパタ系の本をあらためて読むと意味がよくわかるようになっている。継承とかよくないよね。できるだけ集約を使って権限と責任を委譲した方がいいよね、みたいな感じ。
Template Methodとか正直名前を覚えてられないんだけど、今ググったら普通に使ってる手法だった。ていうか普通に考えてそういう設計になるよね、みたいな。（いまここ）

実際にはコード書く以外の仕事してる期間も結構ある（半分くらい）。設計考えたりとかアルゴリズム考えたりとか。

でも俺、ギークとかなんとかみたいな変態的プログラマの人たちには全く追いつける気がしないし、わかんないことだらけで俺センスねーなーと思うことしきり。本当に。

「珠玉のプログラミング」っていう本があるけど、あれみたいにビットレベルでコンピュータの原理を最大限活用してパフォーマンスの高いコードを書く、みたいな考え方がさっぱり身につかない。

でもこのエントリ見ると、俺もちょっとは自身もっていいんじゃね？って気がしたわけだ。

でもやっぱりそんなことは無いのかな。

ちなみにデザパタ関連およびOOP関連では『デザインパターンとともに学ぶオブジェクト指向のこころ』っていう本がマジオススメ。感動的にわかりやすい。

Permalink | トラックバック(1) | 17:52

■優秀なプログラマにたまに起こる逆行(退行)現象

あれは私がまだ大学助手をしていたころだから3年ほど前のことだと思う。

私の勤めていた大学(情報系)では「プログラミング研究会」みたいなサークル活動が行われていて

プログラミングの講義を受け持っていた私はそのサークルにちょくちょく顔を見せるようになっていた。

そこにはとびっきりかわいい女子学生が一人いたのだけれど、その子はゲームが大好きで

「自分でもゲームが作りたい」と一念発起してゲームコンテストに作品を出品することになった。

しかし、彼女はプログラミングの講義(Java)を1年くらい受けているものの、

本格的なモノを作った経験がなく、ひとりでは行き詰まりをみせているようだった。

彼女はひとりでいることが多く、パソコンに向かって黙々とプログラムを書いているのをよく見かけた。

それを気にかけていた私はたまに彼女をランチに誘うようになり、彼女の方もしだいに私に打ち解けてきた。

私たちはだんだんと仲良くなっていった。私は彼女のキュートな笑顔に魅了されていった。

ある日、彼女が私のもとにやってきて、もじもじと顔を赤らめながら上目づかいにこう言った。

「先生、頼みごとがあるんですけど・・・」

「なんだい？」

「メッセンジャーのアドレス教えてくださいませんか？」

これから恋の話が始まるのを期待したあなたは別のページを読んだ方がいいかもしれない。

これから始まるのはプログラミングの話だ。

その日から毎日のように彼女は私にメッセンジャーでプログラミングの相談を投げかけてきた。

私と彼女は連日のようにプログラミングについて語り合った。

彼女は大変優秀で、私の教えるプログラミングテクニックをみるみる吸収していった。

私は彼女の才能に驚き、彼女が将来優秀なプログラマになるであろうことを確信した。

しかし、ときおり彼女が優秀であるがゆえの面白い逆行現象が起こったのだった。

ケース1

ある日、私は彼女がメモリを意識してプログラミングをしていないことに気づいた。

Java ではメモリを意識する場面というのは少ないが、まったく無いわけではない。

私は彼女にプログラムがメモリを無駄に使っているということを指摘した。

しかし、よく聞いてみると、彼女はメモリ＝ハードディスクくらいの感覚しか持っていないことがわかった。

驚かないでほしい。

私の経験上、情報学部の学生の半分以上がメモリとハードディスクの区別がついていない。

それを知っている私は落胆することもなく、落ち着いて彼女にメモリの説明をすることができた。

彼女は私の説明を聞き「よくわかりました」と、とびきりキュートな笑顔を見せた。

しかし、翌日、彼女の書いたコードを見てがく然とした。コードが次のように変更されていたのである。

	for (int i = 0; i < MAXHOGE; i++) {
		doSomething(i);
	}
	for (int i = 0; i < MAXFUGA; i++) {
		doSomething2(i);
	}

↓

	int i;
	for (i = 0; i < MAXHOGE; i++) {
		doSomething(i);
	}
	for (i = 0; i < MAXFUGA; i++) {
		doSomething2(i);
	}

彼女はこのコードを私に見せながら、相変わらずのキュートな笑顔でこう言った。

「このほうが使うメモリが少ないですよね！」

ケース2

ゲームコンテストの締め切りが近くなってきて、実際彼女はよく頑張っていたのだが、

どうしても間に合いそうになかったので、私もコード書きを手伝うことになった。

とある部分を書いていたとき、重複したコードを見つけたので Template Method パターンを使って書き直した。

Template Method パターンというのが何かというと、同じことをするコードがいくつもの場所でばらばらに書かれないように

一つのクラスにだけ書いて、それを継承して使いまわすという手法(デザインパターンの一つ)だ。

私はこの手法を彼女に教えようとは思わなかった。

なぜなら、彼女は継承だとか委譲だとかポリモーフィズムとかがよくわかってないのだ。

驚かないでほしい。

私の経験上、情報学部の学生の99%が、その、ポリホーなんとかが分かってない。

私は彼女には何も言わずにこっそりコードをコミットした。

しかし、彼女はそれに気づいていた。

翌日から彼女のコードの書き方ががらりと変わった。

彼女はいたるところで継承を使うようになっていたのだ。

彼女は私のコードを自分で解析し、新たなる発見を独力でしていた。

重複したコードがあればそれを徹底して継承で解決しようとしている。

そう、差分プログラミングだ。

差分プログラミングの正式な定義は知らないが、彼女は IS-A 関係のない継承を使ってしらみつぶしに

重複コードを書き直していた。

そのコードを見せながら、天使のような笑顔で彼女はこう言った。

「こうするとコードの量が減りますよね！」

まとめ

私がこの文章で言いたいことは、知の高速道路を渡ってきた若い優秀なプログラマは

ときおり妙な退行現象を起こすということだ。

それは普通の道を通ってきた古い世代にとっては実にみょうちきりんなことに思えるかもしれない。

しかし、それは彼らなりに理由があってのことであり、馬鹿だからやってるわけではない。

彼らは優秀であるがゆえにそういったことを起こすのだ。

そして彼らは優秀であるがゆえに、自分が間違っていることを理解するのも速い。

もし、あなたのまわりで若いプログラマが逆行現象を起こすのに遭遇したとしても、

どうか暖かく見守ってほしい。

ちなみに

上で紹介した2件に関しては、彼女にはそのあと説明をして理解を得ることができた。

彼女は本当に優秀なプログラマだ。

しかし我々はそれで油断してはならない。

いつか彼女はその可愛らしい顔をにっこりとほほ笑ませながらこう言うかもしれないのだ。

「ローカル変数よりグローバル変数のほうが便利ですよね！」

Permalink | トラックバック(12) | 17:26

2009-07-16

■http://anond.hatelabo.jp/20090716171659

実際にC++でなんか作ってみてよくわかんなくなったらEffective C++でも読めばいいんじゃないか？

あと作ってみてある程度慣れたら

Code Complete
デザインパターンとともに学ぶオブジェクト指向のこころ

あたりを読むと幸せになれるかも。

Permalink | トラックバック(1) | 17:18

2009-06-18

■単調な職場での退屈しのぎ

http://anond.hatelabo.jp/20090618012903

俺もヘビーなコーディングばっかだった現場から転職して、

あくびが出るような単純なCOBOL プログラムばっか書くような所に来てしまった……。

しかも、コーディングしてる時間なんてほんの少しで、ずっと設計＆テストばっかり。

まあ残業もなくなったし割と収入も増えて極楽なんだけどね。

業務システムとかで高度な技術を要求される事なんてあんまりないと思う。

ぶっちゃけオブジェクト指向なんてほとんどの人が理解してないんじゃなかろうか……。

ライブラリの使い方は分かっていても、

デザインパターンなんかを駆使してクラス設計できる人なんてそういない。

する機会もない。

仕事する上ではそれでまったく不便がないので困ったもんだ。

ただそれだと一度プログラミングの楽しさに目覚めてしまった身にはつまらないし、

職場全体が局所解に陥って楽な方法に全然気づいていない、という事も起きる。

そこで俺は以下のような事をこっそり実行している。

内職する

職場の開発環境を使って、好きなものを作る。

コードを書いていると、傍目には仕事をしているようにしか見えないので安心だ。

ツール作成に血道をあげる

内職の変形版。

古参のプログラマは、実際にリリースするコードに見慣れないものを混入されるのを嫌がる。

だから、どれだけ新技術を身に付けてもなかなか使わせてもらえない。

そこで、最新技術をひたすら投入して内部向けのツールを作成する。

内部で使うだけのツールならレビューやテストがあるわけでもないし、周囲の目も甘くなる。

テスト用仮想サーバとか、独自形式データのビュアー、データ作成ツール、社内用グループウェアなどなど、

凝ろうと思えばいくらでも凝れるものはある。

仕事でのプログラミングは諦めてオープンソース開発に走る

あまりハードな職場でなければ、仕事は仕事と割り切り、

プライベートな時間でプロジェクトを立てたり他人のプロジェクトに参加する。

以上を組み合わせて俺は日々の欲求不満をしのいでいる。

なお、上記を行なって周囲と段違いの技術力を身に付けると、

たまに「こんなこともあろうかと」と得意になれる場面が出てくるが、

それを繰り返していると周囲から非コミュ認定されるので気をつけよう。

飲み会の席で「○○君は技術力あって凄い助かる！」としか言われないような人間になれるぞ！

まあそれでも突き進むのが真のプログラマーだな。

Permalink | トラックバック(1) | 21:53

2009-04-27

■http://anond.hatelabo.jp/20090427180027

は？　普通にSEやりたいのならJAVAとオラクルなんてレイヤーではなく、デザインパターンそのもの勉強しろよ。

つうか、そのパターンだとどちらもコードを書かずに試験用の勉強だけして済ますだろ。

馬鹿野郎。まずコードを書け。書かずに勉強などできないし本質にも近づけんよ。

PHPをやる気があるなら、DBはsqliteでいい。単独でweb アプリケーションを設計／コーディング出来るようになって初めて使える人材だ。以上。

Permalink | トラックバック(1) | 18:08

2009-03-10

■http://anond.hatelabo.jp/20090310095053

はい、プログラマーです。Web系ですけど、結構なんでもやります。

うーん。

たとえ話になって悪いけど、プログラミングって絵を描く事に似てる。

プログラミングわからない人は、｢プログラミングって色々暗記したらできるんでしょ？｣と作業的に思ってる所あるよね。(仕事では作業になることあるけど、それは置いておいて) でも、絵を描くのは、大抵の人が技術を知るだけではできないと知ってる。道具揃えたからって絵が”うまく”描ける訳ではないと誰でもわかる。本質的には、プログラミングもそれと同じなんだけど、誤解されがちかも。

絵をうまくなるには、とにかくデッサン力が必要。どんなに自己流や独特な作風の人でも、一定以上の上手さの人にはデッサン力がある。デッサン力をあげるには沢山デッサンして、良い絵を見ること。

プログラミングでデッサン力に相当するのは、アルゴリズムに落とし込む力。プログラミング言語で、現実をデッサンする力と言っていい。これを伸ばすには、絵と全くおなじ。いろんなものごとをコードにして、良いコードを読むこと。

こうすればデッサンが狂いにくくなるとか、デッサンが速くなるという知識に相当するのが、デザインパターンとか。でもこれは、デッサン力あってのものなわけ。

だから、そういった知識は道具でしなくて、アルゴリズムに落とし込む力そのもの(デッサン力)を自分自身に感じられないと、プログラミングが一気に理解できる最初の壁を越えにくいかもしれない。

デッサン力がしっかりしている人が、漫画風でもリアル風でも大抵どんな絵でもそれなりにこなせるように、プログラミングでもこの基礎的な力を一度つけてしまえば、二つ目以降の言語はさくさく身につくし、作りたいものを表現できる力になる。

最後までたとえ話ですまん。

俺の書いたことが、｢ああそうかも・・・｣と思えるなら、大丈夫じゃないかな。｢まったく何をいいたいのかわからない｣としたら、勉強の仕方が良くないかもしれない。

あーあと、ごく最初のうちは、テンションを維持するために、小さくても動いて結果が得られるものを作った方がいいです。いずれはお行儀の良いコードを書く必要があるけど。最初から完璧を追求すると、一つでも理解できないことがあるといつまでたっても動くものができないってなっちゃう。だから、やる気が維持できないと思ったら、多少手荒でもいいから動くものを作ることは必要だと思う。趣味なら、学び始めのコーディング規約は最小限でいい。

Permalink | トラックバック(3) | 10:23