  |
はてなキーワード: インスタンスとは
プログラム:定義づけられた物事を進めていく妥当な手順・方法の決定、および物事・手順・方法の記述書
(コンピューター)プログラミング:コンピューターが進めていく物事を定義し、妥当な手順・方法を決定し、記述すること。
プログラミング = デザイニング union コーディング;
デザイニング:進めていく物事を定義し、妥当な手順・方法を決定すること。
コーディング:コンピューターが進めていく定義づけられた物事の決定された妥当な手順・方法を、記述すること。
CD(コーダー):コーディングする人。プログラマーとは限らない。
SE(システムス エンジニア):進めていくべき物事を定義する人。プログラマーとは限らない。
PM(プロジェクト マネージャー):(プログラマー)プログラマー。(コンピューター)プログラマーとは限らない。
※日本のソフトウェア業界ではSEが定義した物事を、何の工夫も無くそのまま記述するCDという体制となっている。
つまり「物事を進めていく手順・方法」が余りにも稚拙で、PGと呼べるSEやCDが居ない。
※「物事を進めていく手順・方法」の巧拙の例としては、
PG: (初項 + 最終項) x 項数 /2
というように、例えば巧拙の差は「上手い・エレガントな方法・アルゴリズム」だったりします。
・継続的に勉強できない(1週間で最低10時間は、何があっても勉強しましょう)
・論文・学術書が読めない。(コードはお堅い理論的に筋道立った文章の極致の一つです)
・100ページくらいなら一晩で修得してやろうという気合いが無い(一晩で仕様書読み込んで次の日から活かす必要があったりします)
・仕事のやり方に疑問を抱かない(楽するためにはどんな苦労も厭わず、常に最善を考えましょう)
・いつかはマネジメントをしたい(人を使うよりも、プログラム組んで仕事させた方が、安くて速くて正確ですよ)
※(笑)なマネジメント:下僕に進捗という数字を報告させて、自分の握っている進捗管理という方眼紙のマス目を埋める作業。
自身の雇い主にマス目の埋まり具合を報告する作業。
※ここで以下の1~4を6ヶ月がんばっても挫折する方は、「一山いくらのコーダー」にしかなれない可能性が高いため、
しがみついてしまうと、真っ当な技術者の足を引っ張ることになります。
・逐次実行、条件分岐、反復実行
・ポインタ ※最近、情報学科のくせに学部でポインタを教えない大学があり、そういうところは真っ当な大学ではございません。
1)O'REILLYの[amazon:C++実践プログラミング]を最初の「ポインタ」まで読んでください。
2)C++の実行環境をC99で整えてください。(環境の準備は自分で面倒を見てください)
3)ポインタを用いて、文字のLinkedListクラスを実装してください。
※LinkedListとは以下の仕様を満たすクラスとします。(C++でJavaのLinkedListを実装)
http://docs.oracle.com/javase/jp/6/api/java/util/LinkedList.html
4)LinkedListの入れ子でTree構造をつくり、再帰を用いて、全要素をコンソール出力するプログラムを作ってください。
5)4)をクリア出来た人は、この本を1年以内に全部読んでください。
ただし、C++は複雑怪奇な言語のため、これ以降は知識レベルの修得で構いません。
私は中3の時、STLやBoostどころかbooleanの無い時にこの本を9ヶ月で読んでおります。
※私が面接に出る場合は、当該内容のLinkedListやQuickSortの概要を直ぐさま説明できる人は、可能性有りと○を出します。
面接で「LinkedListを勉強してきました、直ぐさま説明できます」といって、「そんなの出来て当たり前だ」と言ってくれる会社は殆どございません。
大抵はポカーンとして意味不明という顔をする文系人事だったり、「そんな技能必要ない」というところが殆どです。
逆に「できて当然」と言ってくれる会社は、技術をしっかり学べる可能性大です。
★ここまでクリアした方は、「入門者」と呼んで差し支えございません。次は「初級者」への挑戦です。
※初級者になるためからは、べらぼうに学ぶべきことが広がります。
燎原の火のごとく。
※筆者の立場
Joelさんの「Javaスクールの危険」に賛同するので、ポインタ優先ということで。
変数に型がないということの利点について考える
http://d.hatena.ne.jp/perlcodesample/touch/20130227/1361928810
が大変お粗末な内容だったので、反論記事を書きます。
型推論はソースコードのコンパイルの時間を遅くしてしまいます。ソースコードが大きくなってきた場合に、すばやく書いて、すばやく実行結果をもらうことができなくなります。
大規模開発環境はコンパイル時間よりリンク時間の方が問題になりやすいが、それは別に型の話とは関係ない。
あと、インタープリタも最近は実行時にJITコンパイラが走る。
実行時間に影響がなく、開発者の待ち時間で済む方が実はよいのでは？
統合開発環境での、メソッドの自動補完の機能の実装が少し難しくなります。
みんなが統合開発環境をつくるとでも？
そもそも型が不定なら補完することすらできないので、
比較対象として相応しくない。
変数に型がないとソースコードの変更に強くなります。たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。
これは逆に危ない。
実行するまで意図したインスタンスが返ってこなくなった事実に気づかないから。
変数の型を持つ言語は、型が異なるのだが、処理としては同一の処理を行いたい場合には、オーバーロードという機能を使う必要があります。変数の型がなければ、オーバーロードの機能は必要ではなく、ただ単にif文で分岐すればよいだけなのでとても楽です。
CならVTable。Javaならinstanceofなど同等の事はできます。
というか、これ。型を意識しまくったコードじゃないですか？？？
C++のテンプレートのような複雑でデバッグしにくい機能を使ったりしなければなりません。
実は全然ちがうものが混ざってた！なんて事故がコンパイラによって止められる分、デバッグする必要すら無いんですけどね。
変数に型がないとどのような型の値が代入されているかわからないという批判があるかと思います。可読性の問題で
先日、エロWEBサービス おまいらの夢 ( http://omaira.info )を公開したものです。
http://anond.hatelabo.jp/20130122180847
沢山のアクセスありがとうございます！
公開後にはてな村について、いくつか感じる事があったので
ここに書かせてもらいます。
僕もIT業界では3年以上働いていて (現役学生と勘違いされている方が多いようですが)
そこそこスキルも高いと自負していました。
実際、おまいらの夢の開発期間は1週間程度です。
複数のセキュリティホールの指摘とその対策をメールでご指摘頂きました。
公開数時間で、です。
ITを本気で愛していないとなかなか出来た事じゃないです。
みなさん凄いです。
twitterなどでの評判は
「意外と似ている」「おもしろい」
などの好意的なものが多いのですが
はてなでの評判は
などの厳しい意見ばかりでした。
たとえばこんなの
http://anond.hatelabo.jp/20130124061507
試したところ、精度はまずまずといったところでしょうか。
髪型などはかなりの精度で判別してくれるのですが、顔が少しだけ惜しい。
今後の改善に期待です。
みなさん怖いです。
『おまいらの夢』は公開初日で、約8万PVのアクセスを叩きだしました。
リア充の多いfacebookの人々では同じ事は起こらなかったのではないでしょうか？
その中でも性欲が高い or 発散相手がいない
みなさんエロいです。
アダルトアフィリエイトは儲かるんじゃないか？って思いますよね。
僕もそう思っていました。
あれ？
EC2で結構良いインスタンス使っちゃっているので完全に赤字ですね。
でもこれからも 『おまいらの夢 http://omaira.info 』をがんばります
乱文で失礼しました。
世界一のMMOの名を欲しいままにしているタイトルといえば、もちろんWoWを置いて他はない。
WoW以降、その優れたシステムを取り入れたゲームが主流になったという話もよく聞かれる。
しかしWoWをリスペクトしたと言われるタイトルで、これといって傑出したゲームが出てこないのはどういうことだろう。
そう考えると、結局WoWを名作たらしめているのはゲームシステム以上に、豊富な資金力あるいは資金調達力が大きいのだと思う。
WoWの優れた部分として頻繁に取り上げられるのはクエ、インスタンスD、PvP、GvEなどがある。
どれも飽きずに長く遊んでもらうには周到な作り込みが必要だし、クエに至っては良質なだけではダメで、膨大な数を作らないと「廃人が本気出したら数日でクリア」という事態になってしまう。
あと沢山プレイヤーがいるなら、彼らの声をきちんと汲み取るためにも、それなりの人数のGMが必要だろう。
そしてこれらの実装・維持管理は、全てコストになって跳ね返ってくるわけで。
それこそFFDQの新作なんて霞むレベルの、文字通り桁違いに莫大なコストが掛かることは想像に難くない。
結局、そこまでお金をかけられているのはWoWを運営するBlizzard社だけであり、だからこそ今でもWoWがナンバーワンかつオンリーワンなのだろう。
多分MMOの歴史では空前絶後のタイトルになるんじゃないかな。
そして残念なことに、WoWのケースを誰も真似できないというのは、他のネトゲ運営にしろプレイヤーにしろ、これだけ優れたゲームが全く参考にならないことをも意味するわけで。
http://ugaya40.net/architecture/dis_mov.html
Fat Controllerはダメというのは昔から言われている話で、自分も昔読んだときになるほどと思ったので「なるべくControllerを薄く」を頭に置いているのだけど、どうもうまくいった感じがしなくて挫折感があった。その理由だけど、自分の経験から言うと、「Viewに変数を渡すのがめんどくさい」「途中で処理を中断するのがめんどくさい」の2点だと思う。
たとえばRailsだとController内でインスタンス変数に代入することによってViewに変数を渡すことができる。処理をModelに移すとModelからControllerに変数を返して、ControllerでViewに変数を渡すという二段階が必要になるのでこれがめんどくさい。（正確には、ControllerからModelの状態を取れるように作るのが正しいのだろうけど、Viewで必要となるあらゆる状況を想定してModelの状態を取れるようにするのはなかなか大変。それだったらControllerで処理しちゃって……としてしまいがち）
「途中で処理を中断するのがめんどくさい」
たとえばRailsの場合、Controllerからreturnすればその時点で処理が中断されるし、レスポンスもそこでrenderしておけばよい。しかし処理をControllerに移した場合、Model内で起こったことに応じて適切なレスポンスを返すコードをControllerに書かなくてはいけないが、これがめんどくさいように思う。Modelから直接レスポンスやViewを指定したくなってしまう。（もちろんそれはできないし、Modelの分離の観点からするべきでもない）
O/RマッパーのModelに一切処理を追加しないなんてことはなくて、Modelで処理できることは極力Modelに移しているつもりではいるのだが、どうしてもすっきり書けた感じがしない。
もちろんわかっている人ならこんなところでひっかからず、自分がわかってないだけの可能性が高いのだが、自分が上のような理由で挫折してしまったのは事実なので、何とかしたいとは思っている。
自分としては、理屈はわかるけど実際のコードはどうなんだという感じなので、「これは手本にすべきMVCのウェブアプリケーションだ」というのがあれば読んでぜひ参考にしたいのだけど、何かないものだろうか。
http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=c3a54822-f858-494a-9d74-b811e29179e7
・LocalDB って機能が気になる。開発者用に切り離されたDB の機能のようだが、便利なものなのか？
・動的ポート割り当てがデフォになってるから、支障あるときは構成マネージャで1433などを静的指定しなくちゃならない。
・静的ポート運用のときには、ファイアウォールを1433/TCPだけじゃなくて1434/UDPも開けないとならない。
って、えらそうに書いたけど、
外部からパケットは1433も1434もちゃんと届いていることはパケットモニタで確認できるが
SQL Browser ってのを起動したら、つながった！
外部から名前付きインスタンスへつなげるときは、どうやらこれが必須みたいだ。
http://engineer-memo.com/blogs/engineer-memo/archive/2010/02/21/20100221_5F00_01.aspx
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
こんにちは、プログラミングをしているただの女子です。私は学歴も知識もありませんしブスですが、staticに関してはプロフェッショナル。今回は、モテるstatic女子力を磨くための4つの心得を皆さんにお教えしたいと思います。
あえてnewを使ってインスタンスを生成するようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくパソコンを出してインスタンス生成してみましょう。そして「あ～ん！ この言語本当にマジでチョームカつくんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「プログラミングとか詳しくなくてぇ～！ ずっとこのオブジェクト指向言語っていうやつ使ってるんですけどぉ～しっくりこないんですよぉ〜！いちいちnewって書かないといけなくて使いにくいんですぅ～！ ぷんぷくり～ん（怒）」と言いましょう。だいたいの男はインスタンスを生成せずに、すべてstaticな関数でプログラムを書く習性があるので、newなんてキーワードは使っていないはずです。
そこで男が「static関数使わないの？」と言ってくるはず（言ってこない空気が読めない男はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！最近SQLが人気なんでしょー!? あれってどうなんですかぁ？ 実行時に一行ずつコンパイルするスクリプト言語と違って、もっとも高級な言語なんでしょ？でもなんかよくわかんなーい。私かわいそーなコ★」と返します。すると男は「あぁあいつね、あいつ俺の友達なんだ、イイヤツだろ」といってくるので、そのまま調子に乗らせておきましょう。
「ファイル内ローカル関数」や「関数自体で状態を持つ」ことなどができる「static」をとにかく無闇につかうと、一般のstatic男性は「この子はstaticを愛してるんだなぁ」や「え？こんなところにもstatic使えるの？なにこれ？」と思ってくれます。インターネット上ではそのような〇〇おじさんや、××おじさんなど、変なひとがいるので、よいこの皆さんは関わらないようにしましょう。
飲み会などで男が女性に話すことといえばstaticの話やVBの話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ～？」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女ダメだな」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー！ なにそれ!? 知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。
いろいろと話を聞いたあと、「staticな関数を使えば、newって書かなくていいんですねー。覚えたぞぉ！ メモメモ！」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン！ キュンキュンキュン！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「うるせぇハゲ」と言えば女子力アップ！ そこでまた男は「オブジェクト指向ってしっくりこないんですよね〜オブジェクト指向って(ry」と連呼して壊れだすので、放置しておきましょう。
男とプログラミングするときは、とにかく「あーん！ 私インスタンス生成ないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「え？インスタンスなんて生成する必要ないじゃん。static理解せずにわざわざインスタンス宣言してるやつなんて笑っちゃうよね〜」といわれるので、(こいつなんなの・・・)と心のなかで思うだけにして口には出さないようにしましょう。ここでまた100パーセント「どうしたの？」と聞かれるので、うつむいて3～5秒ほど間をおいてからボソッとこう言います。「そうですよね〜staticおじさんカッコイイ〜」と心にもないお世辞を言っておきましょう。
その瞬間、あなたの女子力がアップします。きっと男は「なんて優しい天使のようなコなんだろう！ 絶対にゲットしてやるぞ！ コイツは俺の女だ！」と心のなかで誓い、あなたに惚れ込むはずです。そういうやつより上にのし上がったら、そんなことは忘れて好きなだけインスタンスを生成して大丈夫です。「インスタンスを生成できないんじゃなかったっけ？」と言われたら「は？」とか「うざい」や「おまえは一生C言語でもかいてろ」と言っておけばOKです。
http://anond.hatelabo.jp/20110316202255
亀仙流やつ鶴仙流など、世の中にはいくつかの流派があり、それぞれ カメハメ波やドドン波、舞空術などの技（メソッド）がある。 実際に技を使う場合、技を覚えているZ戦士（インスタンス）が必要。
クラス = 流派
メソッド = 技
インスタンス = Z 戦士
というのはおもしろいと思うし, 例えばゲームを作るなら実際にそういう実装になると思う.
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shotKienzan(); //Kuririnをextendsしているので気円斬が使えます。
しかし, ここではクラス = Z 戦士になってしまっているので, 混乱を招くだろう.
むしろ, 「JavaScript における prototype」 に絞って説明するのはどうだろう.
(ついでに「撃つ」の現在形は shot でなく shoot ですね)
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var goku = new Goku;
goku.shootKamehameha(); // 波!!!
var Gohan = function () {};
Gohan.prototype = new Goku;
var gohan = new Gohan;
gohan.shootKamehameha(); // 波!!!
そしてセルによる吸収は, 動的な継承として考えるのがより自然だろう.
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var Vegeta = function () {};
Vegeta.prototype.shootBigBangAttack = function () {
console.log("ビッグバンアタック!!!");
};
var Cell = function () {};
// 吸収メソッド
Cell.prototype.absorb = function (target) {
for (var method in target) {
this[method] = target[method];
}
};
var goku = new Goku;
var vegeta = new Vegeta;
var cell = new Cell;
cell.absorb(goku); // 悟空を吸収
cell.absorb(vegeta); // ベジータを吸収
cell.shootKamehameha(); // 波!!!
cell.shootBigBangAttack(); // ビッッグバンアタック!!!
そして次にクロージャの使用例として挙げられた次の例.
例）連続エネルギー波 var shotRenzokuEnergy = function( count ){ var shotEnergy = function(){ //エネルギー波を放ちます }; for(var i=0;i<count;i++){ shotEnergy(); } };
この実装では, shotRenzokuEnergy を実行するたびに shotEnergy が毎回定義されてしまい, 非効率である.
以下のように書き換えることで, shootEnergy の定義は, shootRenzokuEnergy の定義時の 1 回のみとなる.
var shootRenzokuEnergy = (function () {
var shootEnergy = function () {
console.log("エネルギー波!!!");
};
return function (count) {
for (var i = 0; i < count; i++) {
shootEnergy();
}
};
})();
shootRenzokuEnergy(10); // エネルギー波!!! x 10
JaavaScript なら Cell.prototype = goku でいいかもしれんが・・・、ある時点での goku をとかってことになるとすごい大変じゃないか？
亀仙流やつ鶴仙流など、世の中にはいくつかの流派（＝クラス）があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技（メソッド）がいくつかあります。
実際に流派にある技を使う場合、技を覚えているZ戦士（インスタンス）が必要になります。
例）亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す goku = new KamesenRyu("goku"); goku.shootKamehameha(teki);
Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます（継承）。
また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。
クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます。
世界（プログラミング言語）によってはただの人を後付でZ戦士にすることが可能です。
(JavaScriptやRubyなど）
noumin = new Hito();
noumin.kougekiKuwa = function(){
//戦闘力たったの5…ゴミめ！
};
noumin.shootKamehameha = function(){
//な、なんだと！？
};
農民がいきなりかめはめ波をうつようになったら危険ですね、危ないです。
このように後付でメソッドを追加出来るタイプは危険性を含んでいます。
とても良いつっこみが来たので追記します。
前半部分ではZ戦士をインスタンスとしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので
何をインスタンスにして、何をクラスにするかが「設計」なんですね。
セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました。
cell_inst = new Cell(); //このセルは第一段階
cell_inst.absorb(17gou); //第二段階に変身 cell_inst.call18gou(); cell_inst.absorb(18gou); //最終段階に変身 class Cell ....{ function call18gou(){ if(!this.17gou)return error(); //17号を吸収していないと失敗する this.17gou.speak("＊＊＊＊略＊＊＊＊＊ドクターゲロ様＊＊＊＊略＊＊＊＊"); } }
17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました。
でもドクターゲロ「様」って言ったのでセルだってバレバレですね。
http://anond.hatelabo.jp/20110316224648
クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。
変数のスコープを解説する必要があるかなと思ったんですがオブジェクト指向からは外れるような気がします。
エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…
http://www.lastday.jp/2010/11/22/objective-c
早速Objective-Cとやらを勉強しようと思ってググってみたら、Objective-CはC言語の拡張なので先にC言語を学ぶ必要があるという驚愕の事実が発覚！
この文書はC言語については解説されていないため、C言語にある程度慣れていることが前提となり ます。しかし、それほど熟達している必要はありません。Objective-Cによるオブジェクト指向プロ グラミングはANSI Cの手続き型プログラミングとはかなり違っているので、熟達したCプログラマで なくても、さほど不利にはなりません。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Cの知識があるに越したことはないけども、どこまで必要かという話になるとごにょごにょ。
少なくとも、Objective-Cを公開している連中が、"Cの手続き型プログラミングとはかなり違う"と言っているのだから、C言語的なコードの流れには（あんまり）ならない（はず）。
それより、フレームワークの扱いに慣れることに重点を置いたほうがいいんじゃないかな。
苦Cで言うところ、文字列やら、ファイルの取り扱いあたりになってくるとかなり微妙で、出来る限り言語機能やフレームワークに任せたい。
ポインタはそりゃ、Python使いが見たら発狂するんじゃないかってぐらいポインタ演算子が出てくるけど、オブジェクトインスタンスは全部ポインタなんだから、いっそ気にしなくていいんじゃない？ それとも関数ポインタとか使いたい？ きっとデバッグが大変だよ。
YouTubeやVimeoで『Xcode tutorial』で検索すると大量のiPhoneプログラミングのチュートリアルが無料で視聴可能です！
公式の「iOS アプリケーションチュートリアル（日本語版）」を読んだ上で言っているのであれば、どこの誰が作ったかも分からない英語の動画が、アップル公式の日本語ドキュメントより優れている点を挙げた上で、その動画のURLを示して欲しい。
英語なんて分からないよ。
オススメってことは必読じゃないのかな？
3.初期投資
Intel Mac + iPhone or iPod Touch + 10,800円
ここから、開発者プログラムの参加費用$99（¥8000程度）を差っ引くと、一冊分しか残らないから、下の方で紹介されてる本が必読なんだろう。
初心者にわかりやすくObjective-Cの事が書かれています。必読です！
こっちが必読？
内容全く知らないで発言するけども、書評を見てみると、Snow Leopardに対応していない旨が書きこまれていて、多少不安。
流行りに乗ってMacbook Airを購入した人は、大抵Snow Leopardのはず。
記事には、"二ヶ月前"からとあるので、少なくとも記事を書いた人はMacbook Airではないのだろう。
自分のアプリの必要な部分だけを勉強すれば、それだけリリースも早くなりますしモチベーションも下がりません。全部網羅しようと思うと開発自体を頓挫しかねません。
遅延評価勉強法の考えで行くと、C言語を先に勉強する必要はなかったと思うけど、どっちなんだろう。
その辺も遅延で気付いたのかな。
英語力がなくてもアプリは作れますが、英語がわかると公式ドキュメントや先にあげたYouTubeのチュートリアル動画も理解できるので簡単な英語くらいはできる方が良いです。
日本語の公式ドキュメントがあるので、是非参照して頂きたいです。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Apple Developer Documentation日本語版
http://developer.apple.com/jp/documentation/japanese.html
日本語ユーザが増えたら、Xcodeのクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。
それとも、実はただの調査不足で既にあったりとか…
たしかにjavascriptをきっちりマスターすれば、それは強みになるかもしれない。
しかし、いかんせんアクが強すぎる。王道になり得ない。
まず、javascriptだけで完結しない。どうしてもサーバサイドが絡む。
いや、javascriptで完結できるよ、と思うかもしれないが、それは特殊だ。ニッチだ。
何を言っても今のところ、javascriptは組込み言語の域を出ていない。
実行環境が特殊過ぎる。
ファイルシステムがあってプロセスがあってネットワークがあるOSに透過な環境で動かない。
DOMがあってHTTPでデータが運ばれてシングルタスク的な環境になってる。
そして、クラス/インスタンスモデルではなく、プロトタイプチェーンモデルだ。
サーバソフトウェアから使い捨てプログラムまで書くような言語ではない。
プログラミングの体験には良いかもしれない。オブジェクトを体験するには良いかもしれない。
しかし、程々にして他の言語に移った方が良い気がする。
javascriptを極める前にマルチリンガルを目指せ。
……。
当たり前か。
一つの言語で満足できるわけない。
C#もVB.NETも使った事があるのに、恥ずかしながらdelegateというものが何だか良く判っていなかったので、ちょっと調べてみた。
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_017/csharp_abc01.html
かなり適当な理解。
背景も知らないし調べもせずにそんなコードをとりあえず書き換えるならこんな感じ。
適当に自分の好みを入れているのでツッコミ入れたくなる人もいるだろうけど。
int rc = RC_SUCCESS; boost::shared_ptr<ObjA> a = createA(); if (!a) rc = RC_ERROR1; if (rc == RC_SUCCESS) { boost::shared_ptr<ObjB> b = createB(); if (!b) rc = RC_ERROR2; } return rc;
ちょっと言葉が汚いけど簡単に書くと
今朝の日経1面に日立とか富士通がクラウドに100億づつ投資、みたいな煽り記事が出ていて気持ちが暗くなる。VM の個別のインスタンス毎に(OS、アプリレベルの)設定は違うし、RDBMS を明日捨てるわけにもいかないだろうから、物理的なサーバやスイッチの構成が多少均一化されたところで自分の知識が1年後には全く無用になっている筈もないのだが。とりあえず VM ハイパーバイザと hadoop 等の練習はしといたほうがいいかも、ただ未経験なら採ってはもらえないらしいからやっぱりジョブリレバンスは疑問。
クラウドというのは廃熱は減らしても物理的ノード数を減らす方向には行かない(Core 7i をやめて Atom を複数並べる方向ということ)から、大手系列のチェンジニアにとってはむしろ朗報なのだと思う。DC電源化もなんともいえない。やっぱり AC で行くような気がする。iSCSI もイーサネット給電も(IP電話端末を除けば)普及していないし。
なんかPerlのblessっぽい。
JavaScriptのnewって本当にいらない子？(http://d.hatena.ne.jp/jdg/20090706/1246840565)
というよりperlのnewっぽい。なぜか。
classでクラスを定義してnewでインスタンスを生成する言語を「一般的オブジェクト指向言語」とすると、
つまり、javascriptでnewを（直接）使わず、class（のようなもの）を作ればperlっぽくなる。
オブジェクトを作る。オブジェクトを作るには3つの動作が必要である。
通常は言語仕様でこれらを行う"new"という命令が用意されている。しかし、必ずしも必要な物ではない。perlでは言語仕様としてはnewが用意されていない。new関数が存在するのはコーディング規約に従っているからに過ぎない。代わりにblessが用意されている。なぜこのようになっているのか。理由はいたって簡単だ。perlのオブジェクトの実態はリファレンスだ。初期化を行うコンストラクタはどの道定義せねばならない。だから必要なのはリファレンスとパッケージを結びつけるおまじないblessだけだ。コンストラクタで好きなリファレンスを用意し、好きなように初期化してblessすればよい。コンストラクタの名前はコーディング規約でnewと決めた。一方javascriptはnewを用意した。{}でオブジェクトは作れるし、どの道コンストラクタは作る必要があるのに。
オブジェクトとクラスを結びつける。しかし、javascriptはクラスを持たないので必要はない。代わりに必要なのは、継承元との結びつき、プロトタイプチェーンの構築だ。
既存のクラスの性質や振る舞いを流用する。default状態を与える。一般的オブジェクト指向言語ではクラス定義時に継承元となるクラスを指定する。javascriptではクラスの代わりにオブジェクトを指定する。
クラスとはオブジェクトの性質・振る舞いの定義だ。しかし、ダック・タイピングではオブジェクトの性質や振る舞いはオブジェクトの持つメンバにより決まるため、そのような環境ではオブジェクトに初期値と継承関係を与えるのが主な仕事となる。
コンストラクタはオブジェクトの初期化を行う。javascriptではクラスがないため継承とコンストラクタによりオブジェクトが初期化される。
var object = function(o) { var F = function() {}; F.prototype = o.prototype; return new F; };JavaScriptのnewって本当にいらない子？(http://d.hatena.ne.jp/jdg/20090706/1246840565)
個人的には
var object = function(o) { var F = function() {}; F.prototype = o; return new F; };
で良いんじゃね？って思う。
更に、コレでは初期化しないから
var object = function(o, n) { var F = function() {}; F.prototype = o; f = new F; if (n) for (var i in n) f[i] = n[i]; return f; };
みたいな。
さらにせっかくだからメソッドにして
var object = function(o, n) { var F = function() {}; F.prototype = o; f = new F; if (not f.inherit) f.inherit = function(n) {object(this, n)}; if (n) for (var i in n) f[i] = n[i]; return f; };
とか。