  |
はてなキーワード: C#とは
.NETでオブジェクトの永続化によく使われる、この二つのクラスの違いについて書きます。サンプルコードなどは書きませんので必要ならリンクを参照してください。ずいぶん古いネタだけど、許してね。
全体的に速度が重要な場合か永続化するオブジェクトが単純な場合はXmlSerializerを、それ以外の場合はSoapFormatterを使うのが良いと思う。なるべく短いコード量で行きたいならSoapFormatterの方がベター。
あと、細かいことだけどTypeConverterは便利なので使うべし。シリアライズ不可能な小さなクラスとか特に有効。
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
そういう会社で○年目(5年以下とだけ)がそろそろ終わるのですが、正直転職ばかり考えている。
というのも、自ら設計した仕様書でプロジェクトに火がついたことはないが、下請け案件では殆ど火災だらけ。
国内王手のうちのある会社が主要取引先なのだが、はっきり言おう。
以下に私の食った仕様書をお教えしよう。
はい、メソッド？なにそれ？おいしいの？と言わんばかりの超大作。
上から下まで流すだけ。保守性皆無。
しかも無理やりループを一まとめにするから、もはや何処で何をしてるのか、、、、。
Basic/Cobol ならまだ分からんでもないが Java や C#
作ってないんですねきっと。何がしたいのかさっぱり分からない。
それで実装用の設計起こすんだから、そりゃぁ全体で動くわけねーわ。
(このときにクレーム付けられるのって下請けなんですが、でも下請けでは発言権無いですからね、、、|||orz)
いや本当に何がしたいのか、、、、どういう分岐条件かも分からない。
いやむしろ書いてない！？
DI, AOP, O/R Mapper いずれも基本となる技術なんですよね、でも。
「何でこんな意味の無いところに使うの？」という使い方で逆に労力を増やしてくれる。
例えば O/R Mapper はテーブルとマッピングを行い、プログラム側で処理しやすく、、、、
で、仕様書の指定「すべてのSQL結果に対して対応するO/Rを作成する」ってｗｗｗｗ
当然従えば大量にオブジェクトができて、SQL仕様が変わるたびに、、、、以下略。
「元のプロジェクトが○位の規模なのにどうしてその倍以上の規模なってんだｺﾞﾙｧ」
「すべてのオブジェクトはシングルトンで実装し、Interface用意してね、DIで使うから」
ってどれだけ無駄すれば気が済むのか、、、、。
(Test 時にMock入れるだけならここまでする意味って無いよな…)
そしてこんなことをして下請けをいじめた挙句「弊社には最新技術のノウハウがございます」とか言う。
素敵、、、、、。
こんな人海戦術しかないような仕様を書いてるようでは、そりゃ安価な海外に流れるなと、、、、。
本当に自分の技術を信じる人は、独立系、海外系、自社製品開発に行ってください。((もしくは王手企業でまともな仕様書書いてください))
自分の仕事を「ＩＴ土方」なんていってる奴に出くわした。はっきり言えば、ただの甘え。と言うか、愚図。
こういう連中のせいで、エンジニア全般の価値が下がっているわけで、さっさと営業でもなんでもやってりゃいい。
出来るといわれる人々は、下記を否定しないはずだ。
エンジニアの仕事ほど、未来があって、毎日が新しいくて面白い仕事はない。
これから先、人の生活に益々コンピューターが入ってくる、ハードウェアや技術の進歩もまだまだ止まらない。
そろそろ頭打ちになって来たって言われてるＣＰＵだって、まだしばらくはムーアの法則に従う見込みだ。
シリコンフォトニクスとか夢見たいな技術も実現すべく日々研究されている。
そうしてハードが進歩すれば、開発技術もあたらしくなる。当然そこに新しい仕事がうまれていく。
仮に量子コンピューターが実現すれば、言語そのものに変革が起こる。
それを学べるってだけで涎が出るだろ？でなきゃおかしいんだよ。
毎日同じ様にだ。今持ってる知識で解ける範囲のみで仕事をしてれば、それは昨日とは何も差が付かないし面白い訳がない。
日本のエンジニアが馬鹿というかクソだと思うのは、平気で人が作ったものを何も考えずに使って仕事をすること。
そして使えることを技術だとのたまう事。そんなんで技術が付くかカス。
Hadoop使ってないで、key-value位は自作しようとしやがれ。
結果使うことになっても、作ろうとした過程で手にした経験ほど面白いものはないはずだろ。違うのか？
そしてもうひとつ。日本のエンジニアの大多数は数学がまるで分からないってこと。
いいか。エンジニアは文系の仕事じゃない。コーダーとエンジニアをプログラマって括りでまとめるな。
エンジニアリングを本気でやるなら、他の工学と同じようにコンピューターサイエンスを理解し使いこなせるだけの
数学の素養が必要だ。線形代数とか微分積分、解析学、エンジニアなら離散フーリエ解析くらいはわかっていて当然だろ？
だから思う。
ＩＴ土方とか言ってる奴は甘えてないで、仕事の中に面白さを探して作ればいい。
プロジェクトが火を吹いてるなら、アジャイル・ディベロップメントでも試せばいい。
何か面白そうな論文を見つけたなら、読んでおいていつか実装しようと虎視眈々と狙ってればいい。
アルゴリズマーの知識が羨ましければTopCoderにでも行けばいい。
ソフトウェアの世界にはコミュニティが幾つも開かれていて、学ぼうとする人や毎日を変えようとする人の
全てを受け入れてくれる。そりゃあ残業が多くて時間がないのかもしれない、それなら残業しないで余暇を
勉強に当てられる環境に転職したり、仕事の１０％を勉強に当てる事を認めさせたり、したらいい。
ソフトウエアの世界には、面白いものがいくつでも転がっていて、そして誰も拒絶されない。金も殆どの場合
かからない。だれでも、第一線の技術を作れるし、学べるし、楽しめる。
今は楽しんでいるし、この仕事を死ぬまで楽しんでも居たい。
今ＩＴ業界がつまらないと思ってる人は、もう一度言語を学び始めた頃の気持ちを思い出してみて欲しい。
あの頃は毎日が面白くて、試してみたいこと、知りたいことが山の様にあったはずだ。
その気持ちを何年でも変わらず保ち続けることが大事だよ。
ＩＴ土方なんて、ただの甘えだ。
毎日が楽しくなるなら、営業でもなんでもやればいい、ただし営業だって学ばないやつは使えないと思うよ。
ただ逃げたいだけの奴には、逃げ場なんかどこにもない。
俺IT業界の人だけど、俺もそれには疑問。
例えば「.NET(どっとねっと) が業界を変える！！！！１１２３」とか言われていたけど、何が何だかさっぱりわからん。「C# での開発だから Visual Studio 入れなきゃいけないけど .NET じゃないとだめだ」なんてな話をまれに聞く。何を以って「これは .NET である」「これは .NET じゃない」なんだろう？ 俺の VS 2008 Express は .NET とやらじゃないの？
さっぱり分からんし、分からなくても、動くモノさえ作る事が出来れば年収800万。
まあ彼らの口車には別に乗らなくてもいいよって事だね。ひひひ。
ものすごい重箱のすみをつつくけど
動的で型制約のないスクリプト言語
型制約って、parametric polymorphism の用語だと思う
C++だと concept で書けるんだっけ？
C#は知らんけど一番凄そう
◆日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介
日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。
会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。
会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。
また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。
上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。
なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。
このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。
そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。
たとえば、以下のようなものが考えられます。
・要求分析、要求仕様定義、システムアーキテクチャ設計、RDBスキーマ設計、サーバの負荷分散設計、各種サーバのパフォーマンス解析・チューニング、デザインパターン、マルチスレッドプログラミング、システム管理、ネットワーク管理
・マネージメント、プロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル
・普遍性の高いコンピュータサイエンスの基礎
・Unix、RDB、正規表現、Java、Perl、TCP/IP、.NET、C#
日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。
いまいる会社が今後もずっと浮いたままだという保証はありません。
一つの会社に依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。
いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。
国家に対しても同じことが言えます。
政府は全ての国民を幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。
ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。
もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。
もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家に投票すべきですが、常に正しい政策を実行してくれる政治家が自分の選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家に投票してくれるとも限らないというのが、世の中の現実です。
だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。
たとえば、金持ちばかりが得をし、平均的な労働者が搾取される最悪の格差社会になってしまうかもしれません。
あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者の所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。
あるいは、少子化対策で、実質的に独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。
あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。
あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。
あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員の自分に酷いしわ寄せが来るかも知れません。
労働者保護や消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。
要するに、投資において、全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
この国にずっと住み続けるのが一番賢い戦略でした。
しかし状況は変わりました。
いまや日本よりも豊かな国や都市がどんどん生まれつつあります。
日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。
本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。
いまいる国家が、今後もずっと浮いたままだという保証はありません。
一つの国家に依存しすぎると、その国家が沈んでいくとき、酷い目に会います。
いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1
こういうことを言うと、「おまえに愛国心はないのか？」と言い出す人間が時々いますが、依存症と愛国心とは別の話です。
これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。
経済的にも精神的にも自立していることと、夫を愛することは両立します。
夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。
むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。
そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。
むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。
日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。
むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。
食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市は世界中にたくさんあります。
どんなところでも、けっこう住めば都なのです。
また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険な地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。
それに、どうせネット環境さえあれば、世界中どこでも、twitterやtumblrやmixiで遊べるし、ブログのコメント欄でクネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像をダウンロードすることもできるし、はてブで脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。
「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。
せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。
●依存症からの脱出は難しい
ギャンブル依存症、アルコール依存症、買い物依存症、恋愛依存症、セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)
これに一番効果的なのが、資産運用で暮らせるようにすることです。
利回りのよい債権や株式に自分の資産を分散投資し、運用することは、どこの国に居住していてもできます。
日本の国債や株式で資産を運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本の国債や株式で資産運用することは可能です。
それどころか、そもそも、日本の国債や日本の株式で資産を運用しなければならないということはありません。
むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分の資産が大きく目減りしてしまうというリスクを抱え込むことになります。
資産は、全世界に分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中に分散投資しておけば、それほどひどいことにはなりません。
だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。
ここで、「日本がキャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか？」という疑問がわく人もいるでしょうが、そうでもありません。
まず、税金の徴収には、属人主義と属地主義の二つの方式があります。
日本は属地主義なので、自分が居住している国や地域に税金を納めることになっています。
このため、日本でキャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2
現在、属人主義を採用しているのは、アメリカとフィリピンぐらいなもので、極めて例外的なケースです。
ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。
また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間に国籍を与えてくれる国は、けっこうあります。
日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。
ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。
そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。
そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。
たとえば、前述の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
http://d.hatena.ne.jp/j5ik2o/20091024/1256369305 の
// 1.0 - 9 * 0.1
BigDecimal b1 = new BigDecimal(1.0);
BigDecimal b2 = new BigDecimal(-9);
BigDecimal b3 = new BigDecimal("0.1");
BigDecimal result = b1.add(b2.multiply(b3));
System.out.println(result.toString());
を見て悲しくなった。Javaってひどい。0.1は文字列で渡さないと誤差が出るってさ。泣ける。
C#なら
Console.WriteLine( 1.00M - 9M * .10M );
でOK
経済学科とか経営学科とかどうでもいいからさ、知っとけよ常識として。って感じ。
別にコンピュータ系だけじゃなく、半導体のエンジニアだろうが機械系だろうが同じだと思う。
関係ないけど、ソフトウェアエンジニアとかプログラマーとかが言う「技術」っていう言葉に凄い違和感を感じる。
下手したら単なる言語の使い方レベルの話を「技術」とか言ってたりする。今回用いた技術はC#です、みたいな。
技術の趨勢が速い、とかいう愚痴をよく聞くけど、そりゃそのレベルの話を「技術」と呼ぶなら速いだろうよと。
C#もVB.NETも使った事があるのに、恥ずかしながらdelegateというものが何だか良く判っていなかったので、ちょっと調べてみた。
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_017/csharp_abc01.html
かなり適当な理解。
本に掲載されている人工無能が難しくて、泣きそうになった。
それで簡単なランチャーを作った。
WAVファイルから某サウンドカードで使われていた形式のファイルに変換するツールを作ったこともある。
いいプログラムが作りたくて、構造化の設計手法について勉強したこともあった。
AthenaProjectというエミュ鯖のコミュニティに参加して、ペットを改造したり、日本ではまだ未実装の傭兵を実装したこともある。
ソフトを買うお金がないので、AccesのVBAで複式簿記の家計簿を作ったりもした。
でも、なぜ、知らないが、その後プログラムを組むこともなくなり、ゲームばかりするようになってしまった。
それから二年後、ふとしたはずみでプログラマーになりたいと思った。
でも、Cなどの構造化言語の使い方は知ってるが、オブジェクト指向は全く知らなかった。
C#やJavaなどの言語を学校に通って勉強し、ストップウォッチやモグラたたきゲームなどを作った。
でも、それだけでは足りなさそうなので、オンラインゲームもどきを作った。
これだけあれば中小なら就職できるだろう。
そう思った。
でも、冷静に考えてみたらおれの年齢は26歳。
今更プログラムが組めるようになっても遅いんだよ。
下層SIer体験記
増田「１月からどうなりますかね？」
A社営業「他の客先でPG作業があるんだけど、そこを考えている。増田君の会社の営業にはまだ伝えていないけど、契約延長という方向で思っていてほしい。」
増田「わかりました。うちの営業にも伝えてください」
増田「１月からの話が弊社営業からこないんですが、どうなりましたか？弊社の営業がなかなか電話に出てくれないので、申し訳ないんですが直接伺いました」
A社営業「・・・ちょっと会議室に行こうか」
A社営業「先日の案件の開始が遅くなってしまうので、増田君は申し訳ないが、今月で終わりとさせてほしい。」
A社営業「サブプライムやリーマンショックで、案件の動きが鈍くなってしまった。長いことお世話になっていたが、本当に申し訳ない」
増田「わかりました。このあと営業に連絡を入れておきます」
～廊下にて～
増田「今月で終わりって言われました。営業面でも確認をしてください」
～翌朝９時～
自社営業「増田君、昨日の電話は本当かい？あのあとA社営業に連絡をしたんだけど取れなくって、いまからA社営業に電話したいんだけど見える？」「朝、会議室に入っていくのを見ました。いると思いますよ。よろしくお願いします」
増田「本日まで長い間お世話になりました。ありがとうございました。」
A社営業「こちらこそ、申し訳なかったね。増田君にはいろいろと助けられたよ。もしまた、機会があれば一緒に仕事をしたいと思っている。ありがとう。」
自社営業「増田君。昨年末はぎりぎりまでどたばたして申し訳なかったね。営業で強く抗議したんだけど、駄目だったよ。早速なんだけど、スキルシートを更新してくれないか？なに、増田君ほどの技術者ならすぐに見つかるから心配しなくていいよ。まぁ少し社内でリラックスをしててくれ。程なく面談が入ると思うんだ。」
自社営業「早速案件が合ったよ。Javaで金融系だね。一発面談で即日から。作業場所はXXXね。面談はこの日の１０時だから直行をしよう。僕も行くよ」
自社営業「面談は大丈夫みたいだったね。君が帰ってからリーダーと営業とも話したけど、好感触みたいだった。すぐに連絡が来ると思うよ」
自社営業「この前の案件でOKが出たよ。入場まで少し時間があるようだから、面談で聞いたフレームワークについて勉強をしておいてね」
増田「本日からお世話になります。増田といいます。よろしくお願いします」
～他にも数名が同時に入場した。～
B社リーダー「席はあそこに用意してあるから座っていてほしい。パソコンは午後に届く予定だよ。まずは入館章を作ったり、サインをしてもらう書類があるから、午前中はそのあたりをやっておいてほしい」
増田「景気が厳しいみたいですよね。」
B社BP(あ氏)「でも、まだ待機や契約が終わった人は社内にいないですから」
B社BP(い氏)「僕らは４月以降もあるから一安心ですね」
B社BP(あ氏)「帰社したら、5人くらい若手が待機してるんですよ。営業に聞いたら3月でプロジェクトが終わったんだけど、次が見つからないんですよ」
B社BP(い氏)「同期が待機してるんですけど、次がないから、新人の研修を任されてるって言ってます」
B社BP(う氏)「社内でも屈指の技術を持つ先輩が辞めるかもって噂なんですよ。その人が辞めたら、会社にまともな人材がいなくなっちゃいます」
増田「営業に聞いたら、案件がマジにないって言ってます。何とか現場を延長できるように努力してほしいって言われましたよ」
B社リーダー「皆さんこれまでありがとうございました。営業からも本日中に連絡がはいってると思いますが、皆さんは5月末日で契約を満了します。残り１ヶ月あまりですが、がんばってください。５月の詳細なスケジュールも近いうちに提示します」
B社リーダー「作業の引継ぎは彼(B社プロパー(え氏)にお願いします。二人で相談をして、引継ぎを行う日を決めてください。あと、最終日はいろいろと事務作業をやってもらうと思いますので、午後３時くらいまでしか作業できないと思っておいてください。」
自社営業「増田君。次の案件について、引き合いが少し来ている。面談を今月中に設定したいんで、現場でうまくやってください。大丈夫ですよね？」
自社営業「○○駅に９時３０分にお願いします。そこに私もいます。」
自社営業「うちの増田です。じゃぁC社のCさんお願いします。」
C社営業「わかりました。お預かりします。」
~3分後
C社営業「Dさん、ご無沙汰です。こっちが増田君よろしくお願いします。」
D社営業「わかりました。お預かりします。」
~3分後
D社営業「Eさん、ご無沙汰です。こっちが増田君よろしくお願いします。」
E社営業「わかりました。お預かりします。」
~3分後
E社営業「Fさん、ご無沙汰です。こっちが増田君よろしくお願いします。」
F社営業「わかりました。お預かりします。」
~3分後
F社営業「じゃぁ行こうか。5人いるね。場所はこっちだ。知ってるかな？G社だよ」
～面談終了後～
自社営業「案件どうだった？好感触？」
増田「それよりも、これはいくつ商流が入ってるんですか？少なくとも４人に引き渡されましたよ？もしOKでても、こんなに複雑ではなんかあったときに困りませんか？」
自社営業「大丈夫だよ。連絡はしっかりやるから。で、感触は？」
増田「わかりません。４人同時でした。他にも何人か見ているみたいで数名入れたいみたいですけど」
自社営業「わかった。並行かけているんで、また面談が入ったら連絡するからよろしくね」
自社営業「この前のやつ、増田君としてはOKかな？」
増田「商流の問題さえクリアできるならやります。ただし、念入りにお願いしますね」
自社営業「わかった。じゃぁ、こっちからはOKと返事をしておくよ。たぶん入場は６月頭だから。」
増田「月初から入場って聞いていましたけど、どうなってます？」
自社営業「ごめん、まだ決まってないんだけど月初は無くなった。とりあえず本社に来て」
増田「わかりました」
B社BP(う氏)「先日、面談に行ったんですけど、PGでスケジュールがタイトって聞いたから断ったよ。だからまだ。」
増田「僕は月初からが延期になったんですが、決まりですよ。」
B社BP(あ氏)「よかったじゃん。今は不景気だからね。本当に案件が無いよね」
B社BP(い氏)「僕は１ヶ月休みます。ちょっと仕事が無いなら、家で寝てますよ。わはは」
自社営業「いま2週目からの入場で調整をしてる。すこし社内で休んでて」
自社営業「3週目になりそうなんだ。ちょっとわからないけど、面談を入れるかもしれないけど良いかな？」
自社営業「この前の件だけど、無くなった。申し訳ない。ちょっとトラブルがあってね。だけど、すぐに面談を入れますから」
自社営業「XXXという技術をやったことない？知ってるだけでも良いんだよ。そうしたらスキルシートに書くから」
自社営業「スキルが完全マッチしていないと面談に入れないんですか？でも、増田はこれだけ経験をしてますから、大丈夫ですよ。提案だけでもしてくださいよ」
自社営業「これをやってないとダメなんですか？帳票ツールなんてどれも同じじゃないですか。確かに彼はやっていませんが優秀な技術者ですから、これくらいは営業でうまくフォローをしていただけないですか？」
自社営業「この業務について調べてくれないかな？スキルシートのここを変えておくから、面談ではうまく伝えてね」
H社(準大手)部長「増田君はJavaいろやってるけど、業務に一貫性がないよね」
I社(小企業)営業「せめて業務は何かひとつでも２年以上やってないと、いまは売れないよ」
J社(小企業)営業部長「先週ならJavaっといい話があったんだけどね」
K社(中企業)開発部部長「いまは社内に30名ほどが待機していますね。ちょっと増田君を提案されても、今は厳しいですね。」
自社営業「面談１発でいける案件がありますか？本当ですか。業務は？物流ですね。言語はJavaですね。はいわかりました。早速お願いします。」
～翌朝
L社営業「君が増田さん？今日はお願いしますね。後3人いるので、ここで待っていてください」
L社営業「揃いましたね。いきましょうか。こっちです。」
M社開発部リーダー「今回の案件はC#なんですが、みなさんにお伝えしたときはJavaっていたかもしれません。Java案件はすでに締め切らせていただきましたので、C#でも大丈夫な方のみお願いします。」
増田「JavaじゃなくてC#でしたよ。僕は5年位前に少し触っただけです。アピールにも限界があります。今回のは無理だと思ってください！！」
自社営業「ここに行ってもらえないかな？M社のMさんがいるから、身長が190くらいある人だから見ればわかるよ」
～面談でアピール
増田「M社営業に引き渡されて、N社のNって人に引き渡されてO社に行きました。わりと好感触かもしれません」
自社営業「そう。よかった。今日はもう帰社して良いよ。」
自社営業「M社から連絡があった。一次面でOKでたので、明後日にP社でよろしくお願いします。がんばってね」
増田「まずまずの感じでしたよ。結果は一両日中に連絡くれるそうです」
自社営業「わかった。急な話なんだけど、明日も昼に面談だ。並行はいくつかけておいても損はないからね」
自社営業「はい。(自社営業)です。Mさん。お電話ありがとうございます。はい、増田の件ですね。で？あ、7月からですね。わかりました。ありがとうございます。では失礼します。」
自社営業「おい、増田君7月からP社で決まったぞ。良かったな」
自社営業部長「並行営業を全部とめてくれ！」
M社営業「先日の件ですが、先方からキャンセルがかかりまして、はい。どうも役員が予算を承認しなかったらしいんですよ」
自社営業「そんなっ！」
自社営業「わかってると思うがちょっと厳しい感じなんだ。うちとしてもあまり余裕がなくなってきてね。ここはちょっと増田君にもがんばってもらおうかなと思うんだ。作業はPGで9月末までなんだよ。場所はｘｘだよ。業務はXXで、やったことないから、ここを書き換えて提案したから。PGでJavaだしいけるよね？」
増田「面談を行って来ましたが、僕と同じくらいのが3人いました。まだ募集をかけてるから、わからないですよ。どの人もスキルは立派でしたよ。去年だったら苦労しないだろうなというくらい」
自社営業「連絡来ないねぇ。」
増田「やっぱり面談駄目だったんじゃないですか？だって、数人の枠に十数人が面談に来てますからね」
自社営業「いまも営業を行ってるんだけど、いいところが無くってね。技術者を連れてこられても、案件がないからって断れるんだよ。」
自社営業「保守なんだけど大丈夫？どうも出産間近の技術者の交代要員を探してるみたいなんだけど、詳しいことはわからない。ただ、一発面談だって言うからさ」
増田「行ってみますよ。」
自社営業「OKきたよ！。今度こそ大丈夫」
という半年間だった
勉強でもプログラムでも何でも同じ。てか本当のところ、高校も出ててこんなこと分かってない奴いないだろ？ いたらいたですげー痛い奴だが。
あとはどうモチベーションを維持するか。この辺は20代だとまだ確立できてない奴もいるだろう。こういう最先端をミーハーするとモチベーション保てる人もいるだろうけど、一番手っ取り早いのは、ある程度の規模の作りたいものを一つ作ること。
あと言語選びに関して少しだけ。
上に書いたようになんでもいい。
仕事で使うならその言語だが、そうでなけりゃ、比較的細部を気にせずに覚えても何とかなるスクリプト言語選んどけばいい。具体的には Python とか Ruby とか JavaScript とか Perl とか PHP とか。もしWeb系じゃなく例えばWindowsアプリが作りたいなら C# とか。
この言語選んどけば、みたいなのは全部無視して、とりあえず１つをある程度覚えろ。話はそれからだ。
きちんとした言語やりたいならC++とかやった方がいいと思っちゃうけど、世間的には批判されるんだろうな…。
PythonとかRubyみたいないい加減(柔軟とも言う)な言語だと、プログラミングをあんまり深く理解できないまま終わる気がする。
C++は確かにワケ分かんないことも多いんだけど、型が厳密だから処理をきちんと意識することができるし、ガベージコレクタも無いから、
メモリをきちんと管理することの重要さもわかると思う。参照と実体の区別もきちんとつくようになるだろう。
platinumで吐き出せるFMFを読み取るためクラスを置いておく。特に反省はしてない。
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO; using System.Data; namespace RPG { class MapFile { //FMFファイルのヘッダー struct FMFHeader { public string dwIdentifier; // ファイル識別子 'FMF_' public int dwSize; // ヘッダを除いたデータサイズ public int dwWidth; // マップの横幅 public int dwHeight; // マップの高さ public byte byChipWidth; // マップチップ1つの幅(pixel) public byte byChipHeight; // マップチップ１つの高さ(pixel) public byte byLayerCount; // レイヤーの数 public byte byBitCount; // レイヤデータのビットカウント } private FileStream fs; private BinaryReader br; private FMFHeader _head; private byte[] _data8 = null; private short[] _data16 = null; public int width { get { return _head.dwWidth; } } public int height { get { return _head.dwHeight; } } public int chip_width { get { return _head.byChipWidth; } } public int chip_height { get { return _head.byChipHeight; } } //マップファイルを読み込む。 //エラーが起きた場合は例外を投げます public void Load(String fname) { try { fs = new FileStream(fname, FileMode.Open); br = new BinaryReader(fs); //識別子を確認する _head.dwIdentifier = new String(br.ReadChars(4)); if (_head.dwIdentifier != "FMF_") { throw new Exception("ファイルが壊れています"); } //ヘッダーの残りの情報を読み込む _head.dwSize = br.ReadInt32(); _head.dwWidth = br.ReadInt32(); _head.dwHeight = br.ReadInt32(); _head.byChipWidth = br.ReadByte(); _head.byChipHeight = br.ReadByte(); _head.byLayerCount = br.ReadByte(); _head.byBitCount = br.ReadByte(); switch (_head.byBitCount) { case 8: //8bit layer _data8 = br.ReadBytes(_head.dwSize); break; case 16: //16it layer int count = _head.dwSize / 2; _data16 = new short[count]; for(int i = 0; i < count; i++) _data16[i] = br.ReadInt16(); break; } } catch(Exception ex) { throw ex; } finally { br.Close(); } } //マップファイルを閉じます public void close() { //読み込んだデータを破棄する _data8 = null; _data16 = null; } //マップファイルからチップ番号を取得します public int getValue(int layer_index, int x, int y) { if (_data8 == null &amp;&amp; _data16 == null) return -1; if (layer_index >= _head.byLayerCount || x >= _head.dwWidth || y >= _head.dwHeight) return -1; int index = 0; int layer_offset = getLayerAddr(layer_index); switch (_head.byBitCount) { case 8: //8bit layer index = _data8[layer_offset + x + y * _head.dwWidth]; break; case 16: //16it layer index = _data16[layer_offset + x + y * _head.dwWidth]; break; } return index; } //該当レイヤーが存在する_dataのindexを返す private int getLayerAddr(int layer_index) { if (layer_index >= _head.byLayerCount || (_data8 == null &amp;&amp; _data16 == null)) return -1; return _head.dwWidth * _head.dwHeight * layer_index; } } }
#訂正