 
|
はてなキーワード: ポインタとは
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
//ダイアログクラスにメンバ変数を定義 std::auto_ptr<CBitmap> m_pbmp; //bitmapを設定するメンバ関数 void C*****Dlg::Set*****Bitmap() { CDC* pDC = GetDC(); CDC memdc; memdc.CreateCompatibleDC(pDC); m_pbmp.reset(new CBitmap()); CBitmap&amp; bmp = *m_pbmp; bmp.CreateCompatibleBitmap(pDC, width, height); CBitmap* old = memdc.SelectObject(&amp;bmp); memdc.FillSolidRect(0,0,width,height, color); memdc.SelectObject(old); ((CStatic*)GetDlgItem(IDC_STAIC_*********))->SetBitmap(bmp); }
スクリーンと同じデバイスコンテキストとビットマップを作成し単色で描画している。描画し終わった後のSelectObjectを忘れてはいけない。
CStatic::SetBitmapに渡した後も実際に描画されるまでCBitmapの寿命を保証しなければならない。
そのためメンバ変数にCBitmapを持たせるがCBitmapが再利用を考慮していないという驚くべき仕様なので仕方なくauto_ptrでラップしている。
いい加減MFC滅びてくれないかな。抽象度が低すぎる。こんな記事自分のブログに書きたくないよ。
さらにVisualStudio 2005のauto_ptrのバグを見つけた operator = にポインタを渡すとおかしくなる。これは本来コンパイルエラーになるべきで代わりにresetメンバ関数を使用するべきだ。
修正するには<memory>ヘッダのauto_ptr_refのコンストラクタのひとつ上の行(642行目)に private: template<class T> friend class auto_ptr; を挿入する。
これは規模じゃなくて難易度の話だろ
難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか？
javaだとなんだ、、、オブジェクト指向なコード書けることか？
元増田に話しとくとjavaで開発するにもHadoop、strutsやらのフレームワークや
jspなどなど色々ある
Androidアプリはその中じゃそんなに難しい部類ではないと思う
別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ
別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないから
引き返したほうがいいな
似たように苦しむ事が多いが腹をくくってる
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
文系の情報系の学科を卒業して、おめでたい頭で何となくSEになって二年目になりました
情報系の学科ではあったけど、SEだのPGだのに就くのは男子学生のうち6割、女子学生では1割いないような感じ
で、非コミュと半ヒキと地頭の悪さで競争率の低そうなSE職についてめでたくその1割に当選
私以外は大体プログラミング楽しい～とか、そういう子ばっかりの中での1割
ちなみにプログラミングの授業は大嫌い。未だに関数がー引数がーポインタがーって意味分かんない。
授業でやったのよりよっぽど分かりやすくて、今になって初めて知ることがたくさんあった
でも別に向上心はないので「そうなんだーすごいなーへー」という感想しか浮かばない
保守開発メインだから今までの開発step数って3桁行かないし、使ったのは「＝」と「if文」が精々
仕事で使うのはCでもJAVAでもないけど、そんなことも分かってなかったの？って呆れられるだろうなー
こんな私でも応用情報が余裕で取れているし、来週受ける上位資格も難なく取れそう
SEって馬鹿でもなれるしお給料いいしで良い仕事だよ！と、後輩には勧めておいた
ただし毎晩終電帰り・残業120時間超でも残業代出るのは30時間まで・仕事が終わらないなら土日は潰れて当たり前なのが気にならなければね、というのは黙っているけれど
職場結婚率は割りと低いけど、他の職場の同業種の人との結婚率はめちゃくちゃ多い。
三年以内に寿退社する人もとても多い。仕事きついし辞めたい女側と、家のことして癒してくれる子がいい男側の需要と供給が程よくマッチングしてるんだろうな。
どうせ細かい説明しても向こう分んないんだし。
どうしても工期短縮しろってんなら、じゃぁ、テストとかバグ取り出来ませんけど？と念書を取るべき。
何でだよって言われたら、「専門的な話になりますが」と断りを入れて、
・ポインタ使われていないのでコードが乱雑になっており、バグが発生した際に原因を解析できない可能性がある事
・古い仕様のコードが大量に含まれており、.net用に書き直すとなると、フローを再構築することになり、ほぼ一からの開発と変わらない事
辺りで良いんじゃないかね？
説明ができるというよりは、相手に言いたいこと言えるかどうか。
相手との関係がすでに悪いとか、なんか微妙なのは営業のせいだし。
上がってきた見積もりを持ってどう交渉するかだって、営業のスキル。
というか、そのために営業っているもんだしね。
技術屋は技術屋らしく、言いたいことを言った方が良いと思うが。
顧客との関係が良好だと、会計システムVCで組むのめんどくさいのでACCESSで良いっすか？ってのが通ったりもする。DBをOracleにして一点豪華主義。
かれこれ5年ぐらい走らせてるが、向こうがPC更新した時ぐらいしかトラブったこと無い。これも、ファイルパス変更しただけで動いたし。
プログラムを理解させるには？のブックマークコメントを読んでいて。
ブックマークコメントの中に、「資格」とかのコメントがいくつかあった。
既に情報処理試験とかあって、いろんなIT系資格があるのだけど、プログラマーやってる人なら誰でも感づいているとは思うが、資格など何の役にもたたない、という事で。高度情報処理資格を持っているからと言って、プログラム（その他設計やコンサル）が出来るとは限らず、逆に何の資格も持っていないのに、すばらしいプログラムをする人がいる。
まぁ、これら既存のIT系資格にある一定の目安にはなるとは思うけれども、万能では無いのも確か。昨今の不況、ITバブル崩壊で、IT系資格の資格手当が真っ先に削られたのも、記憶に新しい（弊社だけかもしれないが）。
雇う外注のソフトハウスから派遣されて来た人など、だいたい15分も話せば、どのくらい出来るか、使えるかは判断出来る。これは資格では計れないものだ。
仮に、弁護士や行政書士、医師など、士制や免許制はどうだろうか？
車の免許はどうだろう？
プログラマーはどうだろうか？
例えばトイレ。水を流すのに、最近のトイレは、リモコンでスイッチを押すと水が流れるが、あれ、プログラムだよね。
例えば炊飯器。米と水を入れて、スイッチを押せば、ご飯が炊きあがるが、これもプログラムだ。
車。ハイブリットや低燃費車が走っているが、あれは電子制御で動いている。
ロケット。アポロはファミコンにも劣るコンピュータで月まで行ったが、プログラムだ。
先日の中国の高速鉄道の事故も、ATCプログラムのミス（？）による事故だ。
先日の$oftbank携帯の通信障害は、故意に仕組まれた通信障害だった。
どこにでもプログラムは入り込んでいるし、そのプログラムによって、便利になっている反面、人命をも奪い、都市機能を麻痺させる事も出来る。
なんでだろう？
介護について考えてみよう。
ヘルパー資格や介護士とかいろんな資格が必要だが、世間一般的には、ワーキングプア、もしくはそれに近い悲鳴が聞こえてくる。
なんでだろう？
資格や免許を持っていても、それが収入や時間に反映されないいい例だと思う。
「プログラマー」「SE」と名乗るのは簡単だ。「漫画家」「小説家」と名乗るのと同じように。なんだったら、名刺の名前の上にそういう肩書きを書いておけば、「プログラマー」であり「SE」である。
漫画家・小説家と違うのは、漫画家や小説家は「売れなければただの無職」という事だ。あっという間に食えなくなる。自分、アシスタントをやっていたし。アシスタントでは、ちょっと食っていけなかった（アシスタントと作家自身は違うが、それなりに間近で見てはいるわけで）。
プログラマーやSEが個人事業種の人達だったら、その通りになるだろうけど、多分、半分以上の技術者は、どこぞの会社に所属しているサラリーマンだと思う。もちろん、これはこれでメリットがある。営業や経理・総務・庶務等が他の人に分担されている事や、会社などの福利厚生も使えるから。
逆に「金の切れ目が縁の切れ目」が使いにくいというのがある。同僚が失敗したり行方不明・自殺等というのはこの業界日常茶飯事だが、そのリカバリーは必ず誰かがやらなければならない。そして不思議な事に、それをやる人間は決まっている。失敗したマンガや小説を他の作家がリカバリーする、というのはあり得ないのにね。
資格制度・免許制度が万能とは言わないが、有効かどうかと言われると、自分には判断出来ない。しかし、前述したとおり、非常にクリティカルなモノを作る場合も有り、無資格なのはそれはどうだろうか？とも思う。
プログラマーやSEがミスすれば、都市機能は麻痺し、人が死に、医療器具が動作せず、電力が起きず、このインターネットすら動かない。TVもラジオもダメ。第1次産業以外のほとんどが停止する事になる。
そんなクリティカルな仕事なのに、この士農工商穢多非人の非人のような扱いを受けるのは何故なんだろうか？
経営者や管理者からみれば、次から次へとターゲットが蛆のように沸いて出てくる職業であり、使えるだけ使って、あとは使い捨て、という業界だし。
一度、プログラマーやSEは自分のやっている仕事がどういう事なのか、考えてみた方が良いのでは無いだろうか？
考える事は出来ると思うよ？ だって、「完全動作する事を常に考えている」のだから。それが過失・故意にでも動かなかった場合、どういう事になるかは、簡単に想像出来るよね。
絵描きや小説書きや楽器演奏や作曲は、小学校の頃、学校で習うから、分かると思うんだけど、【今の現役世代以上】のプログラマーやSEは、小学校で習わなかった。この差が非常に大きいのだと思う。
どんな無能な経営者や無能な管理者だって、「自分が絵を描けない・難しい」というのは、自分で分かる。なぜなら、義務教育時代にやっていたから。ところがプログラミングやSEはどうか。やってないから分からない、わけだ。
あと、拍車をかけているのが、どこかが発表している「情報技術者何万人不足」という発表。この時点で「質」が考えられていない。そこへ、程度の低い派遣業が入り込んで、エライ事になる。そもそも派遣とは、受け側に技術が無いからその手助けに赴くものであって、人身売買では無い。先日も弊社で「組み込み系の低いレイヤーの部分を作るC言語（かなりアセンブラ寄り）が出来る技術者」を要求したのに、実際ソフトハウスから派遣されてきた人間は「C言語のポインタという概念も知らない」技術者だった（どうやら、Windowsの統合開発環境上においてC#だったら使える、というレベルだったようだ）。もちろん、そんな人員を使えるわけ無いのでその場でお引き取りを願った。こういう、「質」や「ベクトル」に関係無く「頭数」だけでどうにかなると思っている奴らが非常に多い。日本の（少なくとも情報系）派遣や客先常駐の考え方は、間違っていると思う。
そう考えると、ある一定の基準として、質やベクトルを明記する必要はあるのかもしれない、と思う。それが労働時間や賃金に反映されるかどうかは分からないが。
K＆RのCで書かれたプログラムを渡された（もう少し正確に言えば、VisualStudioのWizardで作られたものにK＆RのCでコーディングしてある(C++ですら無い)ので純粋なCでは無いが果てしなくK＆RのCだ）。あと、これを作った人はどうにも「ポインタ」の概念が無いらしく、無駄に多次元配列だったり、配列のアドレス渡しとかが多用されている。
作業指示は、これを流用して、C++/CLIかつ.netFramework3.5使用かつ新規案件に対応せよ、との事。
個人的にはどう見積もっても3人で4ヶ月かかる量なんだが、予算が1人で1ヶ月、と言って来た。理由は「Cからの流用だから」。
参ったな。自分としては、C++/CLIはもはや別言語だと思っているんだが。
どうにも上司と顧客に説明出来ない。説明出来ないのは、自分が理解していないせいだ、と言われればそれまでなのだが、自分の感覚で言うと、高段者がうっている将棋や囲碁の一手を初心者に教える、とでも言うか、小学生に微分積分を教えるというか、そんな感覚がある。
いや、相手が、K＆RやANSI、C++、C++/CLIを分かっている人間になら、説明は出来るのだが、相手のレベルに合わせて、説明が出来ない。
今回のこれに限らず、見積もりとかすると、「なんでこんなに時間かかるの？」とか「高い」とかよく言われるのだが、やっぱり説明が出来ない。デスマってるプロジェクトには、よくさらなる人員投入がされる事が多々あるのだが、デスマってる時点で負け戦だし、「混乱したプロジェクトに人を投入すれば、さらに混乱するだけ」と自分は思っているので、やめてもらいたいと思っている。
「あんたの小学生になる子供が、100人いたら、東大に合格するくらいの学力が発揮されるんですか？」と問いたい。
あれは、VisualBasic4が出た頃か。それまでWindowsプログラムというものをCまたはC++で書いていた自分には、驚異的な言語に思えた。そしてみんな言う。「VBで作れば簡単ですよ」
自分にはVBという言語はとてつもなく難しい言語に思えた(MFCは論外)。なぜなら「かゆいところに手が届かない」言語だったから。だから、皆が言う「VBなら簡単」の理由がさっぱり分からなかった。ちょっとした使い捨てツールや、極々Windows標準的な事しかやらないのであれば、VBは簡単な言語であったのは分かる。実際自分もそういう使い方をしていたから。
そして、うちの職場ではそんな製品を作る所では無く、仕様を満たすためにはサブクラス化とかWin32APIを使うとかしないと実現出来なかった。もちろん「VBで作れば簡単ですよ」と言っていた連中にサブクラス化など理解出来ようも無く、ただただ右往左往してデスマーチに突入していった。
その時も、お偉方や顧客に説明が出来なかった。「VBなら簡単」と言っていただろう、と言われるだけ。
まぁ、VBも.net時代になってから、だいぶマシになってきたと思うけどね。少なくとも、スレッドセーフになってくれただけでもありがたい。
まぁ、その辺はともかく、もしかして、デスマやIT土方とかなるのは「説明が出来ないから」なのではなかろうか？と思えてきた。必要な時間と予算を説明出来ないから、泥沼になるのではなかろうか、と。
説明が出来ない限り、プログラマーは永遠にIT土方であり、地位向上は望めないと思う。人月の神話じゃなく、ファンクションポイント法とか、なにか定量的に説明出来ればいいのだけど。ファンクションポイント法だって、それが分からない人には通じないわけで。「小学校に入学した児童にも分かるような」説明が出来ないとダメなんだろうなぁ。どうすればいいんだろ？
反応感謝。おかげで論の穴や新しい観点が見えてきて面白い。この問題をより突き詰めたら「現代オタク論」とでも呼べる議論ができるんじゃないか。
ってか疲れてきたから真面目口調やめていいよね？ あと眠くなってきたから寝る前に四点だけ言わせてくれ。
起きたら練り直して反論するかもしれない。しないかもしれない。
NAVEARがいつのまにかオンライン英語辞書のサービスを始めていた。
プレスリリースによると、小学館の「e-プログレッシブ英和中辞典」「プログレッシブ和英中辞典」、及び英英辞典として
HarperCollins Publishers Ltdの「Collins English Dictionary」をベースとしているもよう。
Yahooやgooの辞書に英英辞書がプラスアルファされた程度のものだろうと想像していたが、実際に触ってみて、かなり個性の強いオンライン辞書であることが分かった。
海外の新聞記事やサイトより例文を引用しているらしく、例文がハンパなく多い。
２， 例文の絞り込み機能が秀逸！
自分は仕事の関係、アルク英辞郎のヘビーユーザーなのだが、英辞郎の例文表示に不満をもっている。
というのも、例文が多すぎて欲しい用例を見つけるのに3ページ目、4ページ目とクリックして探さなくてはならない……..。
今回NAVER英語辞書の例文表示ではこの点が解決されている。テーマ別、文体別、地域別、翻訳の有無、難易度別、年代別などに条件設定して例文を絞り込めるのだ。
例えばテーマ別で「名言」をクリックして単語検索すると、その単語を含んだオバマとかプルーストとかの名言が例文として表示されるしくみ。いい仕事してます。
３， クイック辞書機能
例文中の英単語にオーバーマウスさせると黄色くハイライトされる。さらにクリックするとページ右脇にススッーっとウィンドウが開き（なんだか気持ちいい….）、
その単語の意味が表示される。よくあるポインタ上のポップアップでの表示ではないので目障りにならない。
などが優れている点。問題点は
１， 見出し語数。専門用語などはアルクほどカバーできていない。
コンテンツ量では英辞郎に劣るものの、ユーザビリティではNAVER英語辞書に判定をあげたい。
今後中国語や韓国語のオンライン辞書もリリースするそうなので、中国語初級者の自分としては大変期待している（東方書店あたりの相原先生の辞典を採用してくれるといいなぁ….）。
http://anond.hatelabo.jp/20110114224058 を書いた増田です。
ちなみにFizzBuzzを短くするなら、こう。printfの""はポインタである。というのをつかって\0を文字列に入れ込み、数値の演算結果で文字列をシフトする。
俺ならその4行目は
printf("%d\n\0Fizz\n\0FizzBuzz\n"+("PFFJFTFFJFTFFJF"[i%15]-'F'), i );
みたいにしたくなるけどコードレビューで殴られそうなのでやらない。
このコードだと条件分岐がなくなってるし割り算の回数も減ってるから速くなるかもよ?
(でもそんなこと言うならprintf使ってる時点で論外だよな)
まぁ、今時は３２Bitだし 100までしかFizzBuzzは回さないだろうから、動くんだろうな。
どうでもいいけど
cout 書いたなら、strstreamだろうし sprintf使うならprintfだろうなぁと
int main(void){
int i;
for(i = 1 ; i <= 100 ; i++){
printf("%d \0Fizz \0FizzBuzz "+(i%5?(i%3?0:4):(i%3?14:10)),i);
}
printf("\n");
return 0;
}
ちなみにFizzBuzzを短くするなら、こう。printfの""はポインタである。というのをつかって\0を文字列に入れ込み、数値の演算結果で文字列をシフトする。
Buzz単体を表示したい時にはFizzBuzz+4相当で表示できる というのがさらにポイント。
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のクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。
それとも、実はただの調査不足で既にあったりとか…
ブログに書くと、一発で仕事バレするようなニッチなネタなのでここにメモっとく。
http://www.atmarkit.co.jp/fsys/zunouhoudan/091zunou/xmos_cpu.html
ここではボロカスに書かれていたが、やっと安い評価キットが出はじめた。
http://www.csp-consortium.org/apps/XMOS_training_kit%282010-08%29.pdf
ニコニコ技術部あたりが食いつきそうなネタではあるものの、今の所ニコ動でXMOSで検索しても１本も出てこない。
デジキーですぐ買える。チップ１０００円～３０００円。小規模な評価キット２万～３万ぐらい。
ちなみに総産研にXMOSという名前を使った特殊なMOSトランジスタの研究発表があるが、それとは全く別物。
特徴：
普通にC言語でも使えるらしいが、チップの特徴を活かすためにはXC言語という専用の言語を使う。
昔、トランスピューターをやってた人達が作った。なので、XCの実態はトランスピューター用言語とC言語を混ぜたような感じ。
・小規模な組み込み向けの用途において、安価なチップで、並列処理とかイベントドリブンな処理が可能、という点が画期的。並列処理は大規模コンピューティングだけのものじゃないよ！という熱いメッセージ。
・ハードウエアの動作をソフトでエミュレーションする処理は、いわゆる「ワンチップマイコン」よりは得意＆楽。
・XCは言語仕様としてポインタが削除されてる（！）。XCをC言語の派生言語と呼んでいいのか迷う所。
・XCは、昔のトランスピュータを勉強した経験がある人じゃないと、上手には使いこなせないクセモノ。いい感じにガラパゴス化しとる。
・大容量のメモリをつなぐことを想定した専用ハードを持ってないので、自ずと用途は限られる。（DRAMのI/Fをエミュレータでやれ、なんて言われても絶対嫌だ。）
・XCの言語仕様は、「木に竹を接いだ」ような状態で、お世辞にも美しいとは言えない。ソースコード眺めてるだけでムカつく。（将来的に改善される可能性はある）
・「チャネル」というのが１つのキモだが、この帯域幅が今時のチップとしてはしょぼい。ただしこの欠点は大量のチップを並列に使えば、理論上はある程度補うことが可能らしい。
・MMUを持たないので、Linuxを移植できないのか、と言われるとツラい。
XMOS応用例 Youtubeでもやっと数千再生しか行ってない。
http://www.youtube.com/watch?v=4gbFagvjSfU
http://www.youtube.com/watch?v=eLyn2Ghq_oE
http://www.youtube.com/watch?v=atAdpt5SZe8
今、XCとXMOSに取り組めば、あっという間に国内のこの界隈では有名人になれるかもしれない。強いて言うならそこが唯一の魅力。
ていうか当たり前。
いやもちろん問題なんだけどね。
現場にいる私にとっては同僚のスキルが低いのは当然問題なんだし私自身へぼであることは問題だけれども、そういう次元の話じゃなくて。
はてななど見てると、まるで何か、プログラミングへの情熱に燃えて努力を惜しまずスキル向上してる人がプログラマって職業に付くのがしかるべき姿であって、ポインタもポリモーフィズムも理解できない（理解しようと努力もしない？）間抜けがプログラマになるなど言語道断であり、10000行のメソッドが作られるような悲劇はなんとしても避けなければならない、って雰囲気だけど。
いや悲劇は避けられたほうがいいけどさ、あのさ、「その仕事に熱意もないし能力もない、特になんもない人がその仕事をしてる」っていう状況は、しごく当たり前なのであって、むしろ、「自分の好きなことを仕事にして自分の能力を伸ばして社会に会社に貢献して自己実現しましょー」っていう思想のほうがよっぽど異常だから。
仕事にしたいような好きなことなんて、無いでしょ。ふつう、無いでしょ。
なんとなく学校出て、働かなきゃなー、って思って、なんとなく働くの。そんだけ。
で、たとえば飲食店に行ったら、いかにも接客業に向いてない感じのぼさーっとした奴が店員やってたりするでしょ。これ、普通。
世の中、たとえばタンポポを刺身に仕事があって、タンポポ大好きでその仕事するやつもいれば、なんとなく就職してタンポポ乗せてる奴もいる。
そんで、タンポポ乗せるのうまい奴とか下手な奴とかいる。それだけ。
もしかしたらソフトウェア開発ってのは崇高なる職業であってセミの死骸を裏返しにする仕事とは格が違うのかもしらんけどさー。
たいした変わらんって。
人間だいたいほとんどバカ。バカばっかり集まって社会ができててもなんとかなる。これ素晴らしい。
プログラミングできないけどSE、なんてねえ、まあ、とりあえずパソコンに向かって座ってて給料もらえるんだから、しめたものですよ。
あいつ全然仕事できないっていうか俺の書いた美しいコードを汚してるだけなのに、俺と同じ給料もらいやがって、ってそれ、賃労働に囚われ過ぎ。
がちがちに仕事できるやつだけ集まってる職場なんて息苦しいですよー。
そんなこんなで明日も日が昇るのだから、すーぱーはっかーにもFizzBuzz書けないあいつにも等しく感謝して、だらだら生きなさい。
MacBookProを購入しました。そして、まさか、こんなにハマるとは自分でも思っても見ませんでした。
私も元々はこれを読んでいる大多数の方と同じくWindowsを使っていて、
「Mac? 2番手なのにシェア1割じゃ余計に誰も買わないだろ」なんて思っていました。
しかし、今となってはそんな事(シェア)なんてどうでもいいのです。Macは最高なのです。
この、全てが美しい愛機にゾッコンなのです。もう手放せそうにないのです。
なのですが、「Macのどこがそんなにいいの?」と聞かれると上手く説明できません。これは、難しい。
Macユーザーならこの気持ち分かると思うのですが、Macの良さって言葉にすると伝えきれないもどかしさを感じます。
言葉にした途端に輝きが失われるというか。例えば、
J「トラックパッドが凄いんだよ。超直感的」
G「へー、そうなんだ。直感的に操作できるんだ」
J「そうなんだよ! 分かるかな、こう、スクロールとか、全然違うわけ。
スーって動くし。あと、3本指でシャッてやるだけで進んだり戻ったりできるし!」
G「そうなんだ」
J「しかも、その手の動きが画面と一体化してて、もうヤバいよ、アレは!」
G「そんなに凄いの?」
J「あー、もう、見せたい! というか、使って欲しい! 見るだけじゃ伝わらないわ。よし、買え!」
G「えー、操作感のためだけに買い替はしないだろ。つか、皆WindowsなんだからWindowsで十分なはずじゃね?」
切ないです。という訳で、改めて何故Macがこうも使いやすいのか言葉にしてみると同時に、
買おうか迷ってる方の背中を押す文章を捧げたいと思います。
最初に紹介するMacの良さは、地味なところで「画面が目に優しい」という事についてです。
もちろん、パソコンで作業すること自体は目が疲れるという意味では少なからず目に悪いのでしょうが、
ここで言いたいのは視力云々の話ではありません。Macの画面は精緻な芸術作品である、という話です。
WindowsでWordを使っていると、フォントをゴシック体から明朝体に変更すると文字が急に読みにくくなりますよね。
文字が大きい場合は特に問題ないのですが、10pt前後の大きさの文字はギザギザして読みにくくなると思います。
明朝体に限らず、メイリオや丸ゴシックに変更すると文字化崩れて読みにくい。
そして、文字の大きさを少しづつ大きくしていくとある大きさから急に薄めの字でまともに読めるようになり、
プリントアウトすると実はどちらでもきちんと印刷できたりしますよね。それ、見にくいと思います。
それが、Macには無いんです。明朝体なら明朝体が表示されるだけ、です。しかも、普通に読みやすい。
これはウェブ閲覧時にもありますね。突然明朝体のサイトに出くわすとものすごく読みにくかった記憶がありますが、
Macにしてから何も気にせず読めてます。
というか、明朝体の持つ「お硬い文章ですよ」という雰囲気がしっかり表現されていて制作者の意図通りに読めるが嬉しいですね。
フォントといえば、Macに標準装備されているフォントは美しい! iPhone持っている方なら実感あるかと思いますが、
文字って思った以上に小さくても読めるものなのだと思います。可視性の高いフォントであれば。
そして、Macに標準装備されているOsakaやヒラノギといった美しいフォントは、眺め心地が心地良く、
Macが電気的な機械ではなく、もっとアナログに近い何かかと錯覚してしまうほどです。
これには心底感心しました。Windowsを使っているときは、「Alt+Ctrl+Delete」に何度お世話になったことか分かりません。
それから、電源ボタン長押しも。Macを使い始めて驚いたのが、負荷が大きくなった時の
「時計マーク(ポインタが輪っかになりクリックできなくなる現象)」が、少しの間待っていればきちんと解消されることです。
Vista時代は、時計マーク、即、強制終了だったので非常に助かります。
特に、iTunesとEvernoteは顕著ですね。グラボのせいなのでしょうか?
iPhone持ちにとてiTunesはそれなりの頻度で使うソフトだと思うのですが、使えたものではないですよね。
楽曲の管理がかろうじて使えるくらいで、アプリの管理は諦めていました。Evernoteにしてもそうで、
一応は使えるながらも挙動がいちいち遅くて待ち時間が殆どでは?とイライラしていました。
それが、Macに変えて軽い事、軽い事。iTunesはAppleが作ったものなので仕方ないですが、
こんなにも差別されているとは知りませんでした。使えるソフトの数ではWindowsが勝つとはいえ、
常用するソフトが快適なMacの方が世間から優遇されているのでは?なんて感じたほどです。
これも、説明するのが難しいのですが、Macは「何がどこにあるのか、又何がどこにあるべきなのか、それが全て決まっている」印象があります。
パソコンを使う時間が長くなるに連れてファイルの整理が意味不明になりがちかと思いきや、全くそんな事は無く、
むしろいくらでも増えてくれとまで思います。これも地味な特徴ですが、実は効果絶大でとにかく「整理」にかかる時間は短く、
また欲しいファイルまで文字通り一瞬でたどり着けます。
余りある快適さを手に入れながら、現時点で私が唯一どうしようか迷っているのがOfficeソフトです。
Mac製OfficeであるiWorkは、個人で使ったり提出するために使うには快適そのものなのですが、
他人からdocxやらxlsxファイルを受け取ると少し困るので。単純なレイアウトならそのままiWorkで開くのですが、
スマートアート含め、どうしても形が崩れますね。。。もうすぐOffice:mac 2011が発売されるので待とうか、
現状のOpenOfficeで我慢しようかといったところです。Office:macは少しだけ高めの価格設定なので、そこさえ払えるのであればMac一択です。
というか、Macを使うためだったらそれくらいは気にせず買う事を強くおすすめします。Macを知らないで一生を過ごすのは勿体無いと思うので。
うーん、たとえば、だ。
C言語のプログラミングテクニックを論議する場において「C言語でスマートポインタ実装だろ」とか「com使って別言語のガーベージコレクション利用」とか言ってる場に、プログラムのプの字も知らないやつが現れて「メモリって何？」とか基本的なことを聞かれても「そもそもそのレベルで論議に参加すんなよ」あるいは「自分で勉強すりゃ判るだろ」になるだろ。
あるいは丁寧な人はメモリとポインタについて講義するかも知れない。ただ、C言語のポインタってそれだけで書籍が出るぐらい、判らない人には判らないもので。
結局、こんな場所で「教えてくれ」なんていうやる気無いやつが理解できるとも思えない。
入門書読めばついていける程度のレベルの内容なんだし、そのくせここで解説もとめるのはちょっとなぁと思うんだが。