  |
はてなキーワード: D言語とは
http://anond.hatelabo.jp/20130830202223
特定を恐れずに、その経験談を書いておこうと思う。
400文字詰原稿用紙のレポートを何度も書かされた。学校までの道案内や入学式の報告といった、無味乾燥としたレポートだ。
その400文字は、先生の厳しい添削で真っ赤になるのが常だった。
まともな文章をたった400文字すら書けない。その現実の中で僕らはもがいた。
本を読んだ。
プラトンから「神々の指紋」まである推薦図書のリストがあって、半分は読んだと思う。（神々の指紋は残念ながら読んでいない）
村上春樹や吉本ばななや江國香織が好きな人が仲間内では多かった。一方で、ラノベばかり読むグループもいた。
その時期いちばん読んで良かったと思うのは、佐藤信夫の「レトリック感覚」「レトリック認識」だった。
ただ、読んで良かった、という気持ちだけが残っていて、内容は詳しく覚えていない。
50枚書くことは難しくなかった。
夏にはもう初稿が提出できて、先生にはそれなりに褒めてもらえた。
しかし、自作が何となく気に入らなくて、勝手に最初から書き直してしまった。
書き直した作品は、生徒みんなの前で罵倒された。（トラウマだ）
合計で7回は書き直したと思うけれど、何度やっても評価はされなかった。
そちらも同じように失敗した。
レポートなども合計すると、2年間で2000枚は書いたと思う。
授業では色々な人から話を聴いた。
某有名ゲームのプランニングをしていた人・女性雑誌の編集長・とある古参ハッカー・ラノベの大御所・今ではずいぶん有名になってしまった当時の新人作家……。
映画や演劇もたくさん見せてもらった。レポートの宿題が必ず付いていたけれど。
民俗学で古事記を読んだり、美術学で有名絵画から聖書のシンボルを読み解いたり、構造主義を応用して物語のプロットを組み立てる授業もあった。
教えてくれる人はみんな（出来る範囲で）熱心で、青臭い自分の言葉もちゃんと聞いてくれた。
ちなみに、小説の先生は往年の一太郎ユーザーで、ESCから始めるショートカットばかり使っていた。
キーシーケンスの組み合わせを暗記していたようで、VimやEmacsに通じるところがある。
日本語IMEについて、ATOKは使い物になるが一番良いのはWnnだ、と言っていた。その真意は定かではない。
提出ファイルにはShift-JISのプレーン・テキストを指定し、タイトルや名前の入れ方も詳しく指示していた。おそらくマクロで処理したのだろう。
ただ、提出メディアがフロッピー・ディスクだった。もう10年以上前の話で、テレホーダイの記憶が鮮やかだった頃だ。
僕が通っていた学校に限れば、環境としてそんなに悪いところだとは思わない。
当初は周囲を見回して傲慢になっていたけれど、その鼻柱は見事に折られてしまった。
客観的に言って、使おうと思えばいくらでも使える環境だったと思う。
ただ、進路が難しい。学校を出た後でどう生活を立てていくかが難しい。
卒業生の進路はそれぞれだった。
定職に就いていない人間もきっと多いだろう。
頭の良い同期は大学に転入した。
プロとして活動していると言えるのは、50人の同期の中で3〜5人だと思う。
おそらく最良の選択は、大学に転入し、標準ルートに戻ることだ。
標準ルートを知ることも大事だし、それから生活を安定させてデビューを目指せば良いと思う。
（ただし金が掛かりそうだが……）
何も知らない自分に大きなトラウマを与えてくれたのは、本当にありがたい事だ。
ただ、自我の捨て方は教えてもらえなかった。
こればかりは、学校の外で年齢を重ねてから、知るほかなかった。
某純文学系の新人賞に一度だけ送って落選した実績しかまだない。
そして、日本語よりJavaを書く時間の方が長く、それよりもD言語を書きたいと思う毎日を、無為に過ごしているのだ。
トラバでも言われてしまったけど、「学んだこと」と言いながら、学んだ技術的な内容をあまり書いていなかった。
多少参考になる部分があるかもしれないので、追記してみたい。
ストーリー構成の教科書としては、シド・フィールドが使われていたようだ。
ただ、当時はろくな翻訳が無かったらしく、教師オリジナルのテキストを使っていた。
ハリウッド流の伝統的な4分割構成が基本で、自分のアイディアをとにかくそれに落とし込み、内的整合性を保って読者に提示する技術を教えられた。
たとえば下記のような点をチェックするよう繰り返し言われた。
他にも色々と細かいテクニックについて教えられた。書くときの気構えであったり、推敲や添削の方法であったり。
今はストーリー構成の良書も多いだろうし、自分で教科書を集めて勉強できる環境も整っているかもしれない。
だから、自分で体系的な資料を集め、先生になってくれる人や切磋琢磨できる仲間を見つけ、継続的に書く環境を整えられれば、わざわざ専門学校に行く必要は無いだろう。
専門学校などという人生を浪費する施設より、週末の教室＋Webでの作品発表・添削という形の方が適しているかもしれない。今の時代はきっとそうだろう。
レベルの高い卒業生の作品を見ると、内的整合性の点では下手なラノベよりしっかりしているものが多かった。
しかし、
「全体的に整合性が取れていて、ちゃんとした盛り上がりがあり、伝統的な構成に従って無駄なく構成できているか？」
という問題と、
「それが商業的に売れるか？」
というのはまったく別の問題だ。
商業的消費はたぶん非体系的な世界で、体系的技術がそれにどこまで寄与できるかは分からない。
とあるデビューした卒業生の処女作は、内的整合性など何も考えていない、次々と新しい要素がひたすら出現する怪作だった。
その一方で、しっかりした技術のある人が、なかなかデビューの糸口を見つけられないでいる。
ちゃんとした構成や一貫性よりも、変に魅力的な脇役が愛されたりするのが商業の世界だ。
特に日本において、消費者は全体よりも部分を好む傾向が強いと思う。
そして、部分で受けることを狙うのはかなり難しい。
部分を愛する文化というのはきわめてハイコンテクストな文化で、普遍的・一般的な技術が原理的に存在できない気がする。
それは様式美に満ちた世界で、日本の文化はそういった様式美の継ぎ足し・連続で出来上がっているようにも思う。
こういった事は加藤修一の「日本文学史序説」に素晴らしくまとまっていて、とても面白かったので、創作に関わる人は序章だけでも全員読んだ方が良いと思う。
マンガもゲームもアニメもラノベも全部これで説明できるし、将来的にどんなものが日本で流行するか判別する目安にもできそう。
以上を要約すると、ちくま学芸文庫から上下巻で出ている加藤修一「日本文学史序説」を3000円で思い切って買おう、それを読めば専門学校に行かなくても大丈夫、場合によってはラノベを書かないで済ませられるかもしれない、ということだ。
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
やがて来る就職活動国際化時代を生き残るための知恵 http://kaigai-shushoku.blogspot.com/2010/06/blog-post_16.html
企業依存症、日本依存症の人が増えています。企業への依存とは、ある特定の企業でしか通用しないスキルばかりを修得してしまったがために、他の会社で通用しなくなってしまうことです。企業へ依存してしまうと、会社が傾き待遇が悪化しても、つまらない仕事ばかりさせられても、人間関係がもつれても、家族がいるのに転勤を強要されても、会社に行くのが心の底から嫌になっても、「不満を抱えて働き続ける」「路頭に迷う」「やりたくない他の仕事をする」「自殺」の四択を迫られてしまいます。
日本依存でも同様のことが言えます。自分自身が気をつけていても、他の人があほな政治家に投票をしてしまい、おかしな政策を打ち出されることもありえます。例えば、スロバキアのように、子供を手当てを行った結果、貧困層が手当て目当てで子供をたくさん作り、財政が逼迫したから、子供を手当てを打ち切った結果、貧困層が路頭に迷い、犯罪が増加し、富裕層が夜一人で出歩けないようなことになってしまうかもしれません（※１）
また、日本が未曾有の不況に襲われることもありえるし、公教育の質が低下して技術者が育たず、お隣の国に車でも電化製品でも負けてしまい、日本そのものの国際競争力が低下してしまい、大勢の従業員を抱えた車やエレクトロニクス産業が低迷し、関連企業や関連産業の雇用が悪化して、自分がクビをきられるかもしれないし、クビを免れても従業員が減ったしわ寄せが自分に来ることもありえます。
自分がどんなに気をつけていても、こればかりはどうしようもありません。そんな時、日本から脱出できなければ自分はもちろん、自分の家族や子供も、自分と同じ苦しみを背負うことになります。そうならないように、どんな時代でも、どんな場所でも働けるような、普遍性の高いスキルを身に付け、いつでもどこでも働けるように備えておくのが重要です。
スキルは、"soft skill（ソフトスキル）"と"hard skill（ハードスキル）"に分けることが出来ます。この二つの言葉は、まだ日本では耳慣れない人も多いかと思いますが、欧米のビジネスの場では比較的一般的な観念です。（※２）
ソフトスキルとは、人当たりのよさ、コミュニケーション能力、リーダーシップ、振る舞いなど、他社との関わり方を決定するスキルで、EQ（心の知能指数）と深く関わっています。
EQテスト http://www.unnmei.com/eq.html
ハードスキルとは、 特定業界に関する知識、数学や経済学などの学問、会計などの実践的な技能、言語、コンピュータスキルなど、IQと深く関わっているものです。教育機関で教わることも、独学で学ぶことも比較的簡単にできるのが、ハードスキルです。
日本の新卒採用では「コミュニケーション能力」などのソフトスキルが非常に重要視されますが、日本人が世界で働ける普遍的なスキルを持ちたいと思ったなら、ソフトスキルよりもハードスキルを重点的に磨くべきです。
ソフトスキルはハードスキルと比べて、文化に大きく依存します。例えば、はっきりした物言いはアメリカではソフトスキルが高いとみなされますが、日本ではむしろソフトスキルが低いとみなされる傾向があるでしょう。
ただし、ソフトスキルが飛びぬけて高い人なら、話は別です。今まで接したことがない未知の文化を持つ人に対しても、表情や仕草などから、その人の感情を読み取り、瞬時に適応することが出来る人もいます。
しかし、そんな飛びぬけたソフトスキルを習得するのは非常に困難です。表情から心理状態を読み取る方法や、心理学などを勉強し、さらに実践を重ねれば、どの国の誰に対しても、うまく接することが出来るようになるかもしれませんが、膨大な時間を費やすことになるでしょう。
また、欧米では一般的には「専門的な技能を持った即戦力」が求められている人材です。外国人なら、特にそうです。外国人を雇って、現地人より教育にコストがかかってしまうのでは、わざわざ外国人を雇う理由がありません。
以下の条件を満たすハードスキルがより普遍的であり、習得すべてきでしょう。
2. 長期的な需要が見込める
3. 供給が不足している
4. 流用可能
（例、英語、プログラミング、教育学、料理、Windows、Microsoft Office、Supply Chain managementなど経営学、etc）
国や文化に依存せず、一度習得してしまえば多少の応用するだけで、多くの国で使える技術や知識が「世界中で需要がある」スキルです。どの国の経済も好調なときや不調なときがあります。今は経済的に強い国も不調だったことがあります。日本もそうです。わざわざ景気が最悪な国で働く必要はありません。日本の景気が最悪であれば、少しでも景気が良い国で働くことが賢い選択ではないでしょうか？
それを実現するためには、世界的に需要があるスキルを身につけることです。例えば、英語はすでに国際語ですので、英語を使えれば世界中どこで働いても、研修を効率的に受けられます。そのため、企業からすればその分コストを低く抑えられるのです。
２、長期的な需要が見込める
何か一つスキルを習得したとしても、そのスキルそのものの価値が下がってしまっては下も子もありません。例えば、ある会社の営業がある製品の特徴について必死に覚えても、その製品が発売されなくなり、類似製品や後継製品なども全て生産終了したら、その製品の知識は全て無価値になり、そのスキルに対する需要は激減します。そうならないように、自分が退職するまでは需要が見込めるようなスキルを習得することが重要です。（※３）
３、供給が不足している
世界的に需要があるスキルでも、すでにそれを習得したライバルがたくさんいて、供給過多になっている状態では就職できるかどうかわかりません。しかし、供給が不足しているスキルを習得していればライバルが少ないので、比較的簡単に仕事が見つかります。
しかし、「どこで」供給が不足しているか見つけるのは困難です。例えば、日本には日本語修得者がたくさんいるため、日本語修得者の供給は足りていますが、スロバキアでは日本語修得者の供給が足りていないか、かろうじて足りている程度です。また、プログラミングやパソコン全般に関する技能に関しても、 IT産業では有り余っていても、例えば服飾産業のA社では「一人か二人いてくれたら非常に助かる」と、供給が不足している可能性もあります。ただし、企業自身も自分に何が必要かを理解できない場合があるので、常にアンテナを広く張っている必要があります。
４、流用可能
２、「長期的な需要が見込める」で記しましたが、需要があったスキルもその価値が失われる可能性があります。しかし、修得したスキルの大半を他のスキルに流用できれば大きな問題にはなりません。例えば、C言語がなくなったとします。そして、新たにD言語というのが生まれて、英語ではなくドイツ語をベースとしたプログラミング言語になったとしても、C言語から得た、「プログラミングの考え方（アルゴリズムなど）」は失われないので、始めてC言語を勉強したときよりは早くD言語を修得できるでしょう。
また、需要が合ったスキルの価値が失われなくても、スキルを流用し、新たなスキルを修得することも出来ます。例えば、英語を勉強し、文法を理解したことによって、文章を構造的に捉える能力を修得すれば、新たな言語を習得しやすくなります。
2chの住人や年配の方など、海外に長期滞在したことがない人の一部が「日本より暮らしやすい国はない」と信じているようですけど、それは間違いです。
まず、大都会に行けば基本的に何でも手に入るし、交通は便利だから、不便は感じません。日本食だって、日本で食べるより美味しい日本食を食べられる場所もあります。
また。日本より天候が穏やかな国もたくさんあります。スロバキアなどは、日本レベルの台風や地震がきたら、恐らく都市が壊滅するレベルです。それだけ、気候が穏やかなのです。また、夏も日本の夏と違い、空気が乾燥しているので、すがすがしい暑さです。クーラーはいりません。蚊も日本ほど多くはありません。蝉もうるさくありません。
治安だって、きちんと安全対策を講じていればまず問題はありません。昨日は１１時過ぎに、一人で２km散歩しながら帰りました。全然余裕です。
水ももちろん飲めます。むしろ、スロバキアの水は、確実に東京の水よりは美味しいです。 一部の日本人は体質によって受け付けないそうですが、それでもたまに下痢する程度でしょう。
投資のことわざに、「全ての卵を一つのかごに盛るな」というものがあります。これは、全ての玉蛾を一つのかごに持っていたら、そのかごを落とした時点で全ての卵が台無しになってしまうから、卵を複数のかごに分散させたほうがリスクを回避できるということです。
日本依存、企業依存は、「このかごは脆そうだし、心配だなぁ」と文句を言いながら、自分の人生をひとつのかごに乗せているようなものです。普遍的なスキルを修得して海外移住をすることは、「リスクを伴った挑戦」ではなく「リスク回避のための戦略」なのです。自分と、将来の家族や子供たちのために、少し考えてみる価値はあるのではないでしょうか？
すみません。引用です。というより、ほぼ転載です。URLを忘れていました。
http://kaigai-shushoku.blogspot.com/2010/06/blog-post_16.html
「おもしろいと思ったら転載元のほうもはてぶしてください」
マジな要素を抽出するとしたら、
1から100までコードをべた書きするのが実行速度的には効率良いのだけど、
それを手で書くのはバカらしいので、
コンパイル時に一種のプログラムを実行してコードを生成しよう、という考え方。（メタプログラミングという）
コンパイル時にFizzBuzzをやってしまっておけば、実行時にはもうしないで済む。
この手のメタプログラミングはC++のtemplate周辺が恐らく発祥の地で、
いまD言語がそれを色々発展させてる。
汎用的なデータ構造（配列やら連想配列やらツリー）やアルゴリズムの実装とか、
普通にやると似たようなコードをたくさん書かなきゃいけない場合に使われる。
まあスクリプト系の言語だと「文字列をコードとして実行」(evalとか?)という機能が割と普通にあるから、
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)