Interface Builderを使わずに作るiPhoneアプリケーション作成入門
こんにちは、亀本です。 最近では、だいぶiPhoneアプリ開発に関するチュートリアルも日本語で散見されるようになってきて、以前よりも状況は改善されてきたかなーと思います。 そういった様々なチュートリアルが出てくる中でちょっと気になったのは、どれもこれもInterface Builder(IB)ばりばりに活用しようぜ！なチュートリアルだということ。 多分やり方的には正しいんですが、正直なところ自分がiPhone開発をしていく上で一番苦労したのがIBでした。 ぶっちゃけていうと、iPhoneのフレームワークであるUIKitなどの挙動や感覚がわからないうちからIBを使いこなすのは結構大変なんじゃないかなぁ、と思うのです。僕がへっぽこなだけかもしれませんが。 というわけで、チュートリアル読んだけど結局 IBチンプンカンプンで開発とかできねーYO!!という方、および一度に二つのことを覚えられないOb
2008-03-22
iPhoneSDKで配信されているサンプルコードMoveMeについての解説の概要。元ページはhttp://developer.apple.com/iphone/gettingstarted/docs/creatingiphoneapps.actionです。しっかり翻訳したわけでないので、詰まったときは元のページを見てください。んで間違ってるところ見つけたら教えてください。 ================================================================================= iPhoneアプリをつくるにあたって、まずmain関数で全体の初期化を行う必要がある。そのときに記述するコードは下記のようになる。 int main(int argc, char *argv[]) { NSAutoreleasePool * pool = [[
iPhoneアプリ開発開始時に気をつけるべきファイルの取り扱い (1)
こんにちは、亀本です。 今回から何回かに分けて、iPhoneの申請まわりの事に関するファイルの取り扱いノウハウを書いてみたいと思います。 ここでのファイルの取り扱い方の紹介方法は、ファイル一つ一つについて個別に言及するようなまとめ方はしません。 代わりに、そのファイルを作成・利用するタイミングを切り口として紹介し、その際にファイルをどう取り扱うべきかを、その理由とともに説明していきます。 (※なお、あくまでも個人的に感じたノウハウであって、必須事項ではありません。) １回目は、まず触れるべきファイルの説明と、一番最初のCSR発行時に気をつけておくことを紹介します。 はじめに iPhoneの開発を始めようとすると、最初にCSRやらProvisioning Profileやら、いまいちパッとつかみづらい概念が出てきます。 このあたりのよくわからない事、けっこう悩まされてしまいますよね。 とはい
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
プログラマの権利宣言
Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基本的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？…
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？ プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。 そのため いつもつらい思いをしています。 環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。 マウスもゲーム用の高精度のものを使っています。 調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。 DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。 出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。 単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。 しかし開発速度は効率化とは無縁だとすら感じています。 仕事を減らすことが優先ではないか？と。 昔から創作活動は好
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
ウノウラボ Unoh Labs: PHPによるテキストファイルへのロギング
yamaokaです。 PHPでwebアプリケーションを作成するとき、 皆さんはロギング（ログの出力）をどうされているでしょうか。 今回は、テキストファイルへロギングする方法をいくつか紹介したいと思います。 error_log関数 syslog関数 PEAR::Log log4php Zend_Log error_log関数 PHPでは、標準の関数として error_log関数が用意されています。 使い方はとてもシンプルです。2番目の引数に「3」を指定することで、 テキストファイルにログを出力することができます。 error_log('message', 3, '/var/tmp/app.log'); syslog関数 また、syslog関数も 標準で用意されている関数です。syslog経由でテキストファイルにログを出力することができます。Windowsの場合は、イベントログでエミュレートさ
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
flair4 blog - Flashが何故かうまく動かない時に疑うべき8つの要素
プログラムは間違っていないのに動かない！ 修正したはずなのに修正が反映されない！ 俺のPCでだけうまくパブリッシュされない！ Flashやってるとこういう事がけっこう起こります。 気がつくと１時間くらい格闘するとかあって非常に困ります。 今日はそんな時に疑うべき要素とその解決(するかもしれない)方法を あたりまえじゃんという所から ちょっと深く突っ込んだ内容まで含め８つほど紹介します。 ちなみに若干長いです。 (基本的に FlashCS3 でAS3.0 での話です) (早くも若干追記しました) 文字コード XML等を使っている時確認すべき内容 基本中の基本ですね Flashは基本UTF-8が推奨なわけですが Shift-JISだったりとかUTF-8Nだったりとか・・・ しっかりと確認しましょう。 もしどうしてもUTF-8以外を使わなければならない場合には
アンドロイドアプリができるまで:001 開発環境の準備
アンドロイドファンの皆様、初めまして。タオソフトウェアのため吉と申します。縁あって、今週からアンドロイドアプリの開発について連載することになりました。よろしくお願いいたします。 皆さんが使っているアンドロイド端末にもたくさんのアプリケーションがインストールされていると思います。中には「これがなくっちゃ暮らせない！」というほどの生活必需品になっているアプリもあるかも知れません。当たり前ですが、そういう素敵なアプリケーション達は全て「人が手作り」したものです。 この連載ではアプリケーションが出来るまでの工程を皆さんにお伝えしながら、アプリアイコンの裏に隠れた作者側の思いやドラマを描くことができたらいいなぁ、と思っています。 どうぞよろしくおつきあいくださいませ。 アンドロイドアプリをつくるためには まずはアンドロイドアプリを作るためにはどんなものが必要なのかというところから始めたいと思います。
最も todo と fix meが多いプログラミング言語は Python かもしれない - higepon blog
プログラムを書いていると todo としてコメントを入れることがあります。 現時点ではこのコードは書けない 余裕のある時にやろう 汚いコードを書いていることに対する言い訳 など理由は様々。 todo コメントの例としては // todo check hogehoge hoge(); のようなものが挙げられます。 ふと思いついて「最も多くソースコードのコメント中に todo と書かれている言語は何か？」をGoogle Code Searchを利用して調べてみました。 行コメント限定ですが結果は以下の通りです。 lang todo % todo/all scheme 1.4% 1000/71000 c++ 0.2% 12300/6280000 c# 0.2% 13600/6280000 fortran 0.0% 100/233000 perl 2.1% 28600/1370000 php 1.
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
コピペはプログラミングの基本。どんどんコピペしなさい。 - このブログは証明できない。
コピペはプログラミングの基本です。どんどんコピペしなさい。って、スラムダンクに書いてあった気がしますが、気のせいかもしれません。私はコピペ推進派です。コピペはプログラミングの基本なので、がしがしコピペすればいいと思います。今日は、この辺の話をしていきますが、話題がそれて三井寿を語る場になったらスミマセン。 まず、プログラミング初心者。これはもう、わしゃわしゃコピペすべきです。ホントは写経の方がいいのですが、コピペでも構いません。構いませんとも。かまいたちの夜です。プログラミング初心者が参考書のプログラムを理解するには、読むだけでは足りません。まず、サンプルプログラムを動く状態にして、それを改造すべきなのです。大幅な改造は必要ありません。まずは、変数の中身を変えるとか、そこから始めます。 英語を学習するときに、1単語を覚えるよりも、ひとかたまりのフレーズで覚えた方がいい。って、スラムダンクに
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary
まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日本は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ！全
Life is beautiful
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
あなたのソースを汚くして生産性も下げている、たったひとつの間違い - よくわかりません
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iPhoneアプリ開発入門 − ＠IT CORE
プログラミングの下手な奴の特徴:アルファルファモザイク
リアルタイムにコード編集、チャットもできるオンラインエディター『SquadEdit』 | 100SHIKI
