ちなみにキーチェーンで証明書作ってUPしてAppleからDLして（以下略）的なことをするのに非常に苦労をされている方が多いようですが、そうした人たちが提供して下さる情報のお蔭で、数時間も悩むことなく終わり、何はともあれ適当なサンプルコードを実機で動かすことができました。問題は、自分の能力が追いついてないことですが… orz

Appleとかソニーとか、特に昔のMicrosoft（IE4あたりか）とか、露骨にユーザー無視な囲い込みをする企業は「…ん～、それって長期的に見たら損じゃないの？」と思ってしまう。まーうまくやればうま味もデカイのが囲い込みですが、ソニーもウォークマンとかMDで味しめちゃったんだろうねぇ。ATRACとかUMD（あってる？）とかメモリースティックとか、もう明らかにどこも採用しないんだから、自社のファンを解放してやれよ、と思うような状態になってもやめないしね。

その中では慎重なAppleだけど、iPhone OS 3.0でやっとコピペ解禁ですよ。まあメジャーアップデートだけあって色々目玉はあるけど、コピペできるようになったことが目玉なOSってなんだって話ですよ。慎重なのはいいけど、ガチガチの状態でリリースして、徐々に緩和していくのはホント初期ユーザーがえらい目に遭うからなんとかしてほしい。

まあ、それでも売れるような、魅力的なもん作ってるから儲かってんだろうけどね（Appleの製品はわりと好きだが商売は巧いけどあまり好きじゃない）。

まー愚痴はともかく、ゆっくりやっていくかなぁ。OS3も楽しみだし。

自分は今んとこサーバーとかネットワーク周りの仕事がほとんどなので、たまぁにプログラム書いてもPerlで簡単なスクリプト書いてcronで回すとかそんなもんですが、時々ちゃんとMVCとかオブジェクト指向を今のウチに習得しとかんと、年くったら吸収悪くなんぞ？という危機感はあります。

Perlで先に進むのも一つの選択肢ですが、悲しいかなOOPやWebアプリケーション開発という時流を汲んで開発（または拡張）された後続言語からすれば、Perlの実装は特殊すぎて他に使い回せねぇじゃねーか、と思うところはなくもない。こないだ少し大きめの社内用アプリをWebベースで書いてたらキレそうになった。まあ、packageの使い方がダメダメだとか能力的なものはあるけど、少なくとも素人が書いたらどうしようもなくなる言語は、そこそこの人が書いても規模が大きくなったときにほころびがより出やすいんじゃないだろうか。

もちろん、mixiなどもmod_perlで書かれてますし、キチンとコーディングルールを作った上でpackageやライブラリ化などを適切に使えるならそれでもOKなのでしょうが、それが出来ないレベルの素人（＝自分）にはしんどいです、正直。フレームワークも…なぁ。

んなワケで。会社で使ってるから?という理由で同じ言語やフレームワークを使ってもイイのですが、OOPに向いてる言語、可能だけど不向きな言語とかはよく聞きますよね。ruby on railsはものすごく賞賛されていますが、概念自体はいろんな言語に取り入れられたけど、rubyで開発された大規模なシステムって（あるんだろうけど）そういえば聞かない。実行速度やソース行数（記述）などを考えると、かなり大規模なシステムでは、むしろPython使ったりとかいうケースが多いらしい。

JAVAはよくオブジェクト指向という言葉と同時に出てきたりしますが、周囲にJAVA使いがまったくいないし、故にTomcatをわざわざ入れることもないので使いません（ちょっとだけ書いてみたことはある…触りだけね）。Webアプリ＋フレームワークで気軽に覚えられることを考えると、やはりLAMPでフレームワークをどうするか、って感じが一番ラクなのかねぇ（基本的に概念を掴むことが目的なので、資料が豊富な言語であればいいし）。

じゃ、フレームワークは？会社で使ってるヤツは、特性と目的が決まってて選んでるだけなので、世間的にはマイナーで資料もホントに少ない。Zend Frameworkとか、cakePHPとか、Symfonyは本屋でよく見ますね。そのへんはホント素人なのでPHPプロを見てみると、…。どうなんだろう。symfony、自動生成部分が多いということは、少なくとも初心者があまり考えずに書いても、ViewにActionほとんど書いてしまったり、ということは少ないんじゃないか、と思うのだが…。実行速度で劣るようだが、書きやすさや安定性を重視した結果そうなっているのなら、実務は知らんが学習にはいいんじゃなかろうか…。

以前、symfonyのデモ動画を見たら、WebアプリケーションのクセにデスクトップのIDE並みにサクサクブログとかを実装してて驚いた記憶があります。んー、ちーと入れてみたりするかなぁ。

資料がまだ少ないのと、手続き型プログラムしか書かないのと、そもそも私の頭が残念な頭なのでなかなか先に進めません。

そんな中でも少しずつ資料を買い足したりしつつ、こうして覚えていくのがいいのかな、と思ったところを書いてみようと思います。
すんなり覚えちゃった人には戯言ですが、同じような状況の人には役立つところがあるかも知れません。
「プログラムとかよくわかんないけどiPhoneアプリつくりてぇ」という人がイキナリ「詳解 Objective-C」とか、Apple公式ドキュメントにいくと、まず挫折すると思う。

• なんかプログラム書いた経験があったほうがいいし、ないなら書いてみるといい。手続き型でいいから。今からどうせやるなら、Objective-Cにも生かせるCとか。最近は解説書も易しいし多いし大丈夫。ひとつ言語をやってれば、大抵の言語では基本的な要素は共通してるから、他の言語でもOK。でも、難しいところまで覚えなくていい。
• 基本的なプログラミングを覚えたら、次はオブジェクト指向でプログラムを書いてみるとか、書き直してみる。もし慣れた言語があるなら、それで覚えるといいと思う。本とかで意味や概念を知ってても、普段オブジェクト指向で実際にコード書いてみないと理解できない。
  ただ、オブジェクト指向に弱い言語もあるから注意。最初にCから入ったなら、せっかくだしそのままObjective-Cにいってもいいかも（ネット上探せば資料あるし）。Javaとかやってる人はいいですよね。
• Xcodeとか、Cocoa Touchはその後使い方覚えればいいと思う。一緒に解説してるのはどうも言語の解説が薄くなりがちだし、そもそもこれらを使いはじめるのは、オブジェクト指向プログラムを書き始めるよりも何倍もとっつきやすい。あとは、複雑な機能は順々に覚えていけると思います。

んな感じかなぁ。
オブジェクト指向ってとっつきにくいんですよね。大概の高級言語は書き方やクセに違いはあれど、基本的な構文とかはそんなに大差ないし、次の言語へのつなぎとして覚えるだけならそんなに難しくはない（プログラムで難しいのは言語そのものじゃなくて、処理とかだから）。
でも、オブジェクト指向は言語を覚えた上で、現実にはない独特の概念に沿ってプログラムを書くと色々いいですよー、というメソッドなので、いきなり言語すっとばしても覚えられないと思う。普通の人は。だから別に集中してやったほうがいいと思う。

あとは

• コードは実際に書いて動かす（とりあえず写すだけでも何となく『ココでこうしてるんだ』と気づいたりすることもあるし、何より書かないと覚えられない）
• 本や資料はケチらない。個人的に、1冊でなんとか覚えようとしてわからなくても、同様の本を数冊持っていると、書き方のクセとか表現の仕方が著者によって違うので、わからない部分を読み比べてるうちに分かってきたりすることがあります。
• 「○○日で分かる」とかはあくまで基礎習得が○○日なだけです。特に、1週間とかでゲームプログラミングとか高度なことやってる本とか、やたら薄い本とかは、大抵大事な部分をすっとばしているだけで、実際にその本だけ読んでゲームが作れる、とかはまずないです。
  本当に覚えたいのなら、そういう本を読んで挫折するよりも、ある程度分厚くて「うわ…」と思うくらいの本のほうがいいです。そのほうが少しずつ進んでいくので、途中でわからなくなることが少ない。

まあ本選びは向き不向きもありますが、最初にどれ買ったらいいかわかんない、というときは、ケチらずに気になった本は数冊買っておくといいと思います。最初に買ったときワケがわからなくても、後でスキルアップしたときにすごく重宝したりするので。

最後に、細かい言語解説とかは他に譲りますが、Objective-CってイキナリXcode上でなんかアプリケーション作りだしたり、とにかくワケわからん資料も多いので、こちらを参考にObjective-C版のHello Worldに、コメントつけてみました。オブジェクト指向がおぼろげに分かりだしたら、上記サイトとあわせて見てもらうと「なんだ簡単じゃん」ってなると思います。

あ、ちなみに私はLinux上でコンパイルしてますが、MaxOS Xのgccコンパイラ（Xcodeの中身みたいなもんなので、ターミナルから使えます）でもできるはず。以下のコードを書いて

gcc ファイル名 -lobjc

とやれば、a.outというファイルができると思います（ファイル名はtest.mとかで）。それを

./a.out

で実行してあげると、文字列が表示されるプログラムです。

んでは、私も含めてがんばって覚えましょう。