はてなキーワード: C#とは
http://el.jibun.atmarkit.co.jp/hidemi/2009/06/post-3b92.html
SEと名乗ってきたことはない。というか、会社からSEという肩書をもらったこともないけど。
学生時代からプログラミングやり続けて、仕事もプログラマーを選んで、今年で社会人7年目。
お客さんのところに行って打ち合わせして、
どんな機能が欲しいのかとか、どんな画面にするかとかって話もするし、
肩書はプログラマーだし、自分自身、その肩書に違和感を感じたことはない。
SEを名乗っているのに、プログラム(技術)のことをあんまりよくわかってない人が結構いたこと。
今まで仕事とかで会った人で、
C++とかC#とかWindowsAPIとかLinuxとかApahceとかSQLとか
HTMLとかCSSとかjavascriptとか、、、、
を知らないのに、SEを名乗ってる人が少なくはなかった。
結局SEって何をする人なんだろう、、。
元増田です。
元記事で「同じ動きをする」の前に「ほぼ」と書いたのはintがオーバーフローするときに1万回に1回ではなくなっちゃうことを考慮したものです。
「== 0」を書いた理由はこのコード例をC言語に特定したくなかったからです(せっかくJavaやC#でも通用する話なのにCに特定しちゃうのはもったいない)。printfでなくprintと書いたのもそのためです。
『本人がプログラミングをして、何をしたいかによる』
そっからは、やれC言語だ、やれActionScriptだJavaScriptだ。ってやっていけばいい。
例えば、ゲーム作りたい!っていう奴がいるとする。
それで、まず最初はC言語だからねーって言ってscanfとprintfで電卓を作らせる。
これで感激して、もっと勉強したい!覚えたい! って、なるのか。
なればいいよ。でも多分ならないだろー
情報処理の教科書みたいに、10進数から2進数へ変換するプログラム書きましょーって。出来るけど、そいつにとって何が面白いのよ。
C言語は確かに基礎だけど、ifとかforを基礎というならJSでもいいし、ポインタやらメモリ管理って言っても、本当にそれは必要なの?
それはC言語にとっての基礎で、シューティングゲームをASとかで作る時は最初に覚える必要はないよね。
なにかしら目標もって、それを実現するために勉強していって、自分のスキルが上がっていくのが分かるからモチベーションに繋がる。
そいつにとって、C言語は目標までのトンネルが長すぎる。出口が遠すぎて目の前が真っ暗。
プログラミングの歩き方をよく分かっていない初心者。早く画面でいろんな動きが見たい!という初心者が、トンネルの出口までたどり着くのは難しい。
それなら、10行で早押しゲームが出来る言語から始めるべき。JSとかが楽かな。他にそういうのがあればそれでいい。
初心者にとっての丸写しじゃない10行は、エキスパートからみる500行と同じ。書いてる時の気分は。
自分の書いたコードが画面に色をつけて、クリックしたら反応する!!
でもクリックしても文字が変わるだけかー。それならもう一回クリックしたら、別の文字になるようにしてみるか。
ならついでに色も変えよう。以下略。
まず『自分でパソコンの画面が動かせる!』ということを実際に体感してみないと。
RPGでも、最初からボス出てきて瞬殺されたらやる気なくすじゃん。最初はユルい敵倒していって、レベルアップしていく。
そのうち勝てない敵が現れるけど、勝ちたいから経験値貯めるんでしょ。
そのうちに、その言語だと絶対不可能なことが出てくるはず。その時にC言語やってポインタ覚えればいい。
今回はゲーム作ってみたいっていうパターンを例にしたからC言語はダメだと言ったけど
コンピューターの動作について理解したいとか、そういうのなら断然C言語かなと思う。
とりあえず、初心者が「プログラミングしたいんだけど、どの言語がいい?」と聞いてきたら、
http://anond.hatelabo.jp/20090404235214です。
ご協力ありがとうございます。
普通の:
・Compiler Construction (Louden)
・Effective C# (Wagner)
・Compilers (Aho, et al.)
・Virtual Machines (Smith, Nair)
・Garbage Collection (Jones, Lins)
・車窓で旅する日本列島
・Common Lisp 第2版 (Steele Jr.)
・Assembly Language for Intel-Based Computers (Irvine)
・Concrete Mathematics (Knuth, et al.)
・Programming Language Pragmatics (Scott)
・Basic Category Theory for Computer Scientists (Pierce)
ダメげなの:
・サモンナイトコレクション
・しろ画集
・カーネリアンコレクション
・Bittersweet Fools ビジュアルファンブック
・ISO/IEC 13211 Information technology - Programming languages - Prolog - (Prologの規格書)
・県別マップル十数冊
整理されてなさすぎるのがよくわかった。
その他本棚にあるもの:
・危ない28号 3冊
・夏少女の紙袋
一応プログラマ(というよりはソフトウェア開発者)として仕事してるんだけど、俺はギークにはなれないなとつくづく思う。
ぶっちゃけプログラミングとかコンピュータ・アーキテクチャ、ネットワークプロトコルみたいなものに興味が無いんだよね。
俺にとってプログラミングは、その背景にある数学的モデルをマテリアライズあるいはマネタイズするためのツールでしかない。
○○ハックとか、どの言語が有利だとか、凝ったコーディングテクニックだとかデータ構造の細かな工夫なんかには全然興味が無いんだ。
ぶっちゃけそこそこ習得能力はある方じゃないかと思う。コーディング始めてまだ1年経ってないけどオブジェクト指向(C++)でバリバリ書ける。
JavaやC#みたいにガベージコレクタがあって抽象度の高いオブジェクト指向言語なら(たぶん)少し慣れればかなり書けるだろう。
でも興味無いんだよね。だからコンピュータ大好き少年のようにどんどん新しいことを覚えて勝手にのめり込んでいくようなことができない。
勉強しなきゃなとは思うから本とか読むけど、あくまで義務感でやってるだけ。
プログラミングそのものには興味が無いから、作るシステムの目的がつまらなかったらやる気が無くなる。
それから、LINUXとかにも興味が無いので、なかなか使いこなせなくて困ることがある。
ギークにはなれない。どうやって生きていくのがいいかなあと思う。
巷のPerl Mongerな人たちの間で話題の『モダンPerl入門』を読み始めた。
第1章はオブジェクト指向のトレンドの話で、とても興味深く読んだのだが、同時に「なんでこれPerlで実装せなあかんの?」と疑問に思った。ていうかオブジェクト指向やりたいならJavaやC#でいいじゃん。
継承という基本的な概念もないし、コンストラクタなんかも用意されていない。ゆえに、MooseとかのCPANモジュールを使って実装しなければいけないのだけれど、その分敷居が高くなって初心者には判りづらい。初心者でも現場に投入できるような、強力なオブジェクト指向機構が用意されているJavaやC#といった言語、StrutsやASP.NETといったフレームワークなんかとは全然違う。
私はメインがPHPとASP.NET(C#)という人間で、Perlはバッチプログラムとかクローラの実装とか雑用処理なんかに使っている。PHPは小規模プロジェクトでアジャイルな開発がしたい時、ASP.NETは大規模プロジェクトに呼ばれた時用の懐刀という感じで使い分けている。PerlでWebサービスを作ることももちろん出来るけれども、どちらかというとスピードが優先される開発に用いるものだと思うし、OOPを用いた大規模なプロジェクトにPerlを使おうとする理由がよく判らない。無駄に難しいし、そもそも本書を読めるレベルでPerlを理解している人の頭数がかなり少ないだろうから、実装しても保守コストがやたらかかる。Livedoorやmixiやはてなのような大規模サイトはPerlで動いているようだが。。。
『モダンPerl入門』は内容も書き方も素晴らしい良書だけれど、その辺りが引っかかった。「PerlでOOPを使う理由(APS.NETやStruts+Javaを採用しない理由)」は何なのだろうか? 私のプログラマーとしてのスキルが低いだけだと思うが、よく判らないので誰か教えてくだしあ。教えてダンコーガイ!
これからのWebサービスとかデスクトップアプリケーション市場はActionScriptとC#の対立になると思っているんだけれども、
その2つを対比している事をあまり見たことがない。
それはたぶんプラットフォームの軸でまとめられているから黒子になっているんだと思う。
ActionScriptはFlashやAIRの開発言語で、それに対してC#はWPFやSilverlight。
Flash VS Silverlightは最近ちょくちょく目にするから対比構造はあるんだろうけれども
それがActionScript VS C#とはならないのはなんでかなぁ
/*
VSと書いたのは煽っているからだけど、もっとC#とJavaのようなイデオロギー紛争になっていも面白いのになぁ。
(ASがJava系譜の流れなんだから、AS vs C#の言語コンセプト論争もあってもいい気がするんだけれども)
畑が違うっていうけれどもAdobeもMSも向かっている所は似たり寄ったりで、
事実、技術採用の時にFlashか?Silverlightか?みないな話は水面下でちょいちょいあるはずだと思う。
(それで「やっぱりFlashかな」とかなるんだろうけど)
*/
仮にRIAっぽいことを目指すならFlashかSilverlightかを選択肢にあがるけれども、
そこにはプラグインの機能有無や普及の優劣の話しか持ち上がらない。
ビジネス的にはもっともな論点だけれども、
デベロッパから見た選択理由としてプログラミング言語のあれこれを考えないはずがない。
それなのにその考えが全然見かけないよ。
おそらく一昨日の激しいMOJIBAKE不具合の発生原因となった修正によると思われる、キーワードがアンカー文字列にあるとそこからキーワードリンクにされてしまう、という別の不具合が発生している。
+[http://anond.hatelabo.jp/:title=はてな匿名ダイアリー] +<a href="http://anond.hatelabo.jp/">はてな匿名ダイアリー</a> +[http://anond.hatelabo.jp/:title=はてな匿名ダイアリー] +[http://anond.hatelabo.jp/:title=これがはてな匿名ダイアリーの姿] +[http://anond.hatelabo.jp/:title]
5番目のパターンは、多くの文字の数値文字参照化と取得した文字との関係で起こっている現象であろうと、たとえば「YouTube - Broadcast Yourself([http://www.youtube.com/:title])」等から推察できる。
+http://www.hatelabo.jp/ +http://anond.hatelabo.jp/ +[http://www.hatelabo.jp/:title=http://www.hatelabo.jp/] +[http://anond.hatelabo.jp/:title=http://anond.hatelabo.jp/] +[http://anond.hatelabo.jp/:title=http://www.hatelabo.jp/] +[http://www.hatelabo.jp/:title=http://anond.hatelabo.jp/]
例えばwwwとこのエントリー内に書いてありキーワードリンクが発生している条件では、上記の内容が下記のようなリンクになる。
この時、ASCII文字によるanondもキーワードである事に注意。
これは若干異なるものの、以下のように連続した英数字からなる文字列の場合は途中でキーワードリンクにならないが、他の場所でキーワードリンクとなってる文字列の場合はキーワードリンクとなる従来の仕様の影響かもしれない。
このほか従来からのpタグ(下記参照)に加え、&や>(ASCII文字による&と>)等の不具合も出ている。
<p>
しかし、この修正でhttp://anond.hatelabo.jp/20070129012129と同一の内容であっても、多くのキーワードが正常にリンクされるようになった。
OK
C# $10 (T_T) *ist D +ANIMA yes,mama ok -196℃ .book c/w :active ave;new アンリ・カルティエ=ブレッソン ?B @CHaT [TV] ^H _no PE`Z ||リ・_・`川
AirH" AirH" 女子高生 GIRL'S-HIGH 女子高生 GIRL'S-HIGH MÄR MÄR (*゚∀゚)ノ パキャッ (*゚∀゚)ノ パキャッ
文字参照に変換されるため双方上と同様に
P&G
含むキーワードを見つけられず
% \ { } ~
キーワード関連
また、近い問題としてhttp://anond.hatelabo.jp/20070328234724もあげておく。修正されていた。
結論としてエスケープは面倒臭
元増田っす
言語仕様がコンパクトなのがなぜ良いのかと言うと、実は2つ理由があります。
1つめは「全体像を把握するのが楽」という理由で。C++やJAVAだと全体像を把握するだけで疲れてしまうわけです。(使い方は奥深いけどね)
2つめはCOBOLを学ぶのと同じ後ろ向きの理由だけど、これからも活躍の場が多いだろうという予測。いまだに組み込みとかハードよりのところだとCは現役だったり、新製品の開発でももりもり使われてます。コンパイラが簡単に作れるし移植も楽だから。(これがCOBOLとかJAVAだと、開発環境を整えるのが大変なので選択されない。未来はわからないけれどもね)
標準ライブラリまで含めても、Cは異常に小さいよ。速いし。
Cのポインタってのは、値渡しのみにするとスタックでコンパイラをすっきりかけるけど、じゃあどうやって柔軟に運用させるべーと考えた妥協の産物です。
だから標準ライブラリにすら文字列・集合・リスト・配列を便利に扱えるものは入ってないし、ガーベジコレクションも多重のスレッドもヒープも入ってないわけです。(だからスタックと静的割り当てだけなんとかすればコンパイラが作れちゃう)知らなかったから作れなかったんじゃなくて、あえて切り捨ててる。
方向性として「間違いを少なくプログラミングする」とか「効率よくプログラミングする」ではなく、「コンパイラを簡単に作れるのが1番。でもできるだけプログラミングしやすいよう」にしてる。
そういう言語を2番目以降に学ぶのが良いのは、ハードよりの考え方(正確には、コンパイラよりの考え方)が出来るようになるから。これが「ポインタと言う概念を理解できる」ということに含まれてる。
メモリを意識したりポインタの概念を理解しておくと「なんで暴走するのか」「どうすると自分の足を撃てるのか」が理解できる。限界も面倒くささも便利さもわかるからね。(ポインタだからっつって暴走するんじゃなくて、C言語のポインタの実装だから、なんだけども。あと、ほんとは機械語=アセンブリを学ぶのが良いとは思うけど、それはハードルが高い。出来ることも少なくなっちゃう)
ポインタが暴走するから隠蔽する・使わないようにする・ミスっても平気にする、ミスらないようにするというのは、言語としては正しい方向性だと思う。
誰がどう考えても「存在しない配列を参照したらエラーを返さずに黙って暴走する(そこにあるメモリを見ちゃう)」「仕様として不定な動作が多い」なんてのはまずいでしょう。けれども、なぜまずいのか知らないまま便利な言語に慣れちゃうのは、感覚として良くない様な気がする。
C#だと信じられないくらい簡単にアプリ作れるし、PythonやPerlは普段使いの言語としてはすっごく便利。でもそれって、パック野菜やお惣菜を買ってきて晩御飯を作るようなものじゃないかな、と。ピーラーやミキサーは便利だし炊飯器はなきゃ炊事なんてやってられない。それでも、その道を学ぶのであれば「レシピを見れば料理は作れる」「包丁となべで調理できる」「なべかまでご飯は炊ける」なんてのは、必要じゃないかなあと。
今あえてC言語を学ぶのは、それが学びやすい(情報が手に入りやすい)最後の言語だから。
(まあ、何を目指すかによって違うとは思うけどね。僕の言ってんのは「いまあえてスペイン語だ!」って言ってるようなもんだし。違うか)
とはいえ、参照や配列を理解するのにポインタは必須ではない、というか別概念だよね。
Cでは参照や配列を扱うときにポインタという生の実装がむき出しになってしまうけど。
OCamlやSML (もしくはHaskell) のような、ぜーんぶ値渡し+必要なところだけ陽に参照(ref)型を使う、という言語を最初に使ってれば、ポインタを理解してなくてもJavaやC#の参照もまあすんなり理解できると思う。
なまじ中途半端に参照と値渡しが構文的に区別されずに存在していたり、Rubyのように参照しかない(と思ってるんだけど)世界からはじめると、後々苦労するような。
CはもはやゲームとかOSとか組込みとか、リソース制約のきついソフトウェアを書くための言語にすぎないと思う。やっておくに越した事はないし、低レベルレイヤを理解しておくべきだし、言語間の関数呼び出しみたいなことをするのにも知っておいた方がいいけど(とはいえSWIGみたいなものもある)、より抽象度の高いところから手をつけるアプローチもあっていいんじゃないかなー。
o 21 !K7
22 AirH"
o 22 AirH"
22 AirH&quot;
o 23 C#
o 24 $10
26 R&B
o 26 R&B
27 B'z
27 B'z
o 28 (T_T)
o 29 (T_T)
o 2a *ist D
o 2c yes,mama ok
o 2e .book
x 2f c/w
o 3a :active
3c のどごし<生>
3c のどごし<生>
3e のどごし<生>
3e のどごし<生>
x 3f ?B
o 40 @CHaT
o 5b [TV]
5c \
o 5d [TV]
^H
o 5f _no
o 60 PE`Z
7b {
o 7c ||リ・_・`川
7d }
7e ~
MÄR
o MÄR
(*゚∀゚)ノ パキャッ
P&G
P&G
いまさらだが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。こっちの方が安定してる?)
肩書としてはソフトウェア開発。
だけど、ソフトウェア開発なんてやったことはない。
SEのように設計するでもなく、コーディングするわけでもない。
部内のサーバ運用もちょこちょこやってみるが自分でもスキルのなさ具合に吐き気がする。
わからないから誰かのまねごとをするしかない。
スクリプトも真似ごと。
テストの内容も真似ごと。
ちょっと改造しただけ。
とりあえず、他のところが公開してる資料とかWebで調べたのとか見て同じタイプのテストを導入してみる。
さすがに何もわからないと嫌なので。何でやるのか休日に本を漁りにいって意味を調べてみる。
……ダメだ。広大すぎて埋もれそう。
問題起きたら調べてねー、と言われてソースの中を漁る。
cscopeとタグジャンプはそのうちにやっと覚えた(最初から知っとけ、恥ずかしい)。
とりえあえず現象が発生してる原因はわかった。
だけど、それが問題なのかどうか調べないといけない。
でも日本語版は古くて中の記述がこっそりかわってたりする。おのれ。
えーと、なんとなくやっぱり原因はわかった。
だけど、仕様って何それ? 周りも誰もしらない。
だからまた放浪の旅に出る。
……やっとわかった。だけど、やってる人からすれば当り前のこと。
自分じゃなかったら一瞬でわかるんじゃないだろうか?
プロジェクト管理もまともにできてない。
テストなんて本で書いてることなんて眩しすぎる。
理念はなんとなくわかる。そうしたい。
だから自分のやってることのギャップがとてつもなく苦しくて惨めだ。
そんなことをいっぱいつなぎ合わせてなんとか今の仕事をしてる。
2000年以前はCGI全盛期だったのでPerlスクリプトを作ったり改造したりしてたときは楽しかった。
Perlですらもうついていけないだろう。
知ってるのはCとシェルだけだ。しかもまともな開発経験なし。
入社時にみんなで研修で作ったのが最後。
あの時はプログラム組める奴が少なかったけど、今じゃすっかり逆転してるだろうなぁ。
設計したい。
でも、俺の知識で作れるものなんてないんだ。
読んでもわからない。永遠に差は縮まらないような気がする。
挫折しそうだし、誇りも持てない。
隣の開発してる人たちを横目でみながら、みんな眩しくてよいなと思う。
自分もそっちに行きたい。
行きたいけど経験がない。
経験を積むためには技術が居る。
でも、もう遅すぎる。
ちょっと疲れた。眠って起きたらまた少し頑張ろう。
たとえ遅れていくとしても、歩むのを止めてしまうとあとは沈むだけだろうから。
自分には何が足りないんだろう。自分と凄い技術者の差はなんだろう。
埋められるものではなくとも、その原因を知りたいと思う。
javaなんておさわりでしか触ったことが無いけど、どれもわからん。面接とおらんわw
Enum と 可変長引数 はなんとなく察せられるが、拡張for構文 はなんのこっちゃ?
http://journal.mycom.co.jp/column/java/016/index.html
for (int target : integers) {
これをみるかぎり、foreachみたいなもんか?
可変長引数はみてみたが、Javaみたいにチームで開発するんだったらまあいいんじゃないかな。
ジャンルがわからんので何ともいえんけど、大卒の新人とか見てると、自分の仕事こなせるようになるまで3年はかかるね。
だから1ヶ月強でそのレベルまで達しているなら、それだけでスゴいと思うけどw
「そっち側」というのが (広義の) Webサービス構築をひと通り自分だけでこなせるぐらいのスキルだとすると、こんな感じか?
ググったりパクったりしながらでもいいので、とにかく経験することかな?
チョットしたツールをつくるんだったらVB6とか使ってたけど、最近はどうなんだろうね。
C#とかあのお手軽感に比べるとちとめんどくさい感じ。
どんどん重たくなっていく……。
C#を最後にいくつかやってWinアプリ系の開発は殆ど組まなくなったのだけど、
vistaの時代になっちゃうとWinアプリっちゅうとやっぱりC#一本なのかな?
c++でDLLとか作るぐらいならc#のIDEつかっちゃったほうがよさそうだし。
ODBC利用できてちょっと簡単なWinAPI叩けるだけで大抵は満足なんだけど、、
大げさだよ・・・。
JavaのSwing、Beansとかも結局期待はずれだったし。。
フラッシュあたりがもうちょっとGUIを簡単につくってくれたらなぁ。
そんな、ぼやッきーを総合して、
「Windowsアプリを作るのに最適な言語を教えてください。」という一言なんじゃないだろうか。
この回答している人達の内容が気になりますね。
分裂勘違い君劇場を、わんさかブックマークする人達というのは何を好きこのんでいるのだろう。浅く、薄っぺ。腹が立つので、ブックマーカーに突っ込みを入れてみよう。ちなみにこのエントリ「日本でしか生きていけないと将来破滅するリスクがあるので世界中どこでも生きていける戦略のご紹介 - 分裂勘違い君劇場」には今現在183のブックマークがついていた。
考えさせられる
そうですか?腹が立つという意味なら同意です。
分裂君の評論能力にはつくづく感心させられるなぁ。
ある意味正しい。きちんとblogの形にまとめてくる能力は評価できますね。でも、なんだかバックグランドとして透けて見える彼の価値観がどうにもよろしくない。プロフィールのところで、逃げを打つあたりも疑問だしネ。
同意。全くその通り。地方のSEにこんな感じのリーダが昔は沢山いた。世間狭すぎる。会社にべったりのスキルを獲得しないで、何をやった気になってるんだろう。大型開発ほど、困難な開発ほど、会社として総力戦になる。自ずと独自製品べったりになる。そんな現場に立ち会っていない。というか、立ち会ったかも知れないが外野として俯瞰していた感じだ。
AJaxが無いのは書き漏らしたのかな。独自製品べったりを嫌うだけあって運用管理ツールは無いな。Apatche, MTが無いあたりは勘定系などのSEなのかと思わせられる。それにしても、「正規表現、TCP/IP」は一般教養だからここに書かない方がいいのでは。iosが無いのはネットはやらない人なんだな。
国家に対しても同じことが言えます。
IT系企業と国家を同列で考えるのはいかがな物か。しかも、文の構成から見てIT企業の考察から類推している(国家破滅の例としてIT企業を出したとは思えない)。
全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
またも、理由を開示せず類推で話を終えている。投資のポートフォリオをどっかで聞きかじったんだろうが、薄っぺらい。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です
古いとしか言っていない。良い悪いの話じゃないのか。古いが悪いのはITだけだよ。価値観なんて人それぞれ、古かろうが主流じゃなかろうが幸福追求に都合が良ければそれでよし。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
まただ。しかも、今回は「依存症」という単語で一本書こうとした糸口が透けて見える。面白いけど、調査不足。力不足。埋め草が多すぎる。
なぜ、この話題で計算式を出さない。計算してみればあなたの提案がとても難しい物だというのがよく分かるはず。私の資産では年率16%の運用利回りをたたき出さないと生活はできない。平均的な資産運用は5%。企業は年金の運用を2〜5%でやっている。16%の運用ができるなら、日本にいた方がいい。
新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。
仕事は何をやってるんだろう。わずかな薄皮で日々しのげる楽な仕事なんだろうなぁ。スコープも狭いし。
自営業は、あたると凄いんです。
あたらないと書いてるように見えるのだが、気のせいだろうか。
いちいち、けちを付けて申し訳ない。なんだか、今猛烈に反省モードです。しかも、初めて彼の日記を読み切ったのですが、薄っぺらいという感想は変わりませんが好きになったかも(w。愛されるべきSEなんですね。でも、これだと商談取れないぞ。
だいぶ前にTurbo Delphi Explorerを試してみたが、添付ファイルは送られてきたよ。メーラーとかファイアーウォールが添付ファイルを剥ぎ取ってない?
もともとTurbo Pascal 2.xあたりからのユーザーなんだが、Delphi 5.xくらいでアップデートを止めてしまった。久しぶりにDelphiの無料版をインストールしてみた時には悲しくなったよ。
ヘルプがアップデートされていないので、あちこちつじつまが合わないんだよ。おまけに、ヘルプのトップに堂々と昔の日付が書いてあったりして、「もうわれわれにはこれを続ける余力はありません」って無言のメッセージが伝わってくる。
昔Delphiに触った連中が、あきらめ切れず今でも愛し続ける理由はわかるんだよ。でも、これからはじめるなら俺はC#を薦めるね。Delphiのチーフエンジニアが開発を率いたので、Delphiの良いところがいろいろ盛り込まれているし、悪いところも改善されている。
Visual Studioも無料版がある。
「私、プログラミング好きだよ」と言うプログラマに、好きな言語や開発ツールを聞いて「C/C++/C#」の名前があがってくるとげんなりする。心底がっかりする。C/C++/C#は俺も大好きだし、素晴らしい曲開発環境だと思うけども、臆面も無く低レベルプログラミング言語を挙げる人のほとんどが、それ以外の低レベルプログラミング言語を知らないんだもの。それどころか、IA-32の仕様書があることすら知らないし、興味が無い。せめて4004の基本構造くらい理解してから言ってもらえませんかね。
要するに「プログラミングを理解する知識の深い私」を演出するために、いちばんてっとり早くて優等生な回答なんですよね。C/C++/C#は。あと、アセンブリ言語や、機械語もこのカテゴリに入る。
確かにUnixを記述したC言語として鉄板なことは間違いないけど、本当にプログラミングが好きならもっとたくさんの名前が挙がってもいいと思う。もっと書けよ!インテル系以外も!最近のも!「C」「アセンブラ」「MMX」「SSE」「3DNow!」のコンボはもう飽きました。
1度だけ悲しきAdaという回答が返ってきて、土下座せんばかりに感動したことがあります。あ…この方、本当にプログラミングを趣味でやってるんだ…と思ったよ。
ごめんなさい、僕、嘘をつきました。