今まで紹介してきたiPhone開発Tips情報が大量になってきて、このままじゃわけわからんし、探しにくいことこの上ない!! ってことで、少し整理してみました。 アプリ開発入門アプリリリースリジェクト開発者インタビュー動画、サウンド画像処理カメラ開発関連書籍ネットワーク各種イベントアイコン環境、設定等フォント文字列日付関係オブジェクト保存等UIViewUITableViewUITextFieldUIWebViewUIPickerViewOpenGL各種コントロールローカライズSqlite新パーツ、クラスデバッグ関係メモリ・性能関係メモリリーク関係Adhoc・テスト ※以下のエントリー内容を包含しつつ整理してみました。 iPhone開発で役立ちそうなTipsの紹介iPhone開発向けTips追加分(20081110)iPhone開発向けTips追加分(20081125)iPhone開発向けTi
この文書は、バグフィックスを除いて、ユーザから目に見える変更点を列挙したものです。 それぞれのエントリは、その背景や参考情報を端折ってしまうくらい簡潔にまとめられていることに注意してください。全ての変更点のリストとしては、 ChangeLog ファイルを参照してください。 言語の中核部分 新しい文法と意味 ブロック引数は全てローカルスコープになりました ブロック引数の意味が新しくなりました defined?とローカル変数 パーサはソースコードがある文字エンコーディングに対してvalidなバイト列であることを期待するようになりました。どのエンコーディングを使っているのかを、マジックコメントでパーサーに知らせてください。 instance_evalやmodule_evalの中での定数定義の意味が変わりました。 廃止された文法 if/unlessやcase表現において、thenの代わりにコロン(
有限会社タグパンダ 喜安 亮介 2009/2/20 テキストに意味を持たせるXHTMLタグの正しいマークアップをおさらいしましょう。フレーズ要素を含む19タグを一挙ご紹介します。 これらの要素を用いたマークアップを行うことにより、「この文章は○○から引用された文」とか「この文字列は▲▲の略語である」といったふうに、テキストに論理的な意味を持たせることが可能になります。 p要素 p要素は、文章の段落を表すための要素です。 ブロックレベル要素として機能し、テキストとインライン要素を内包できますが、ブロックレベル要素を内包できません。 p 文章の段落構造を表すp要素 q要素 q要素は、段落による区切りが不要な短い引用文を表す際に使います。 インライン要素として機能し、テキストとインライン要素を内包できますが、ブロックレベル要素を内包できません。cite属性値に引用元のURIを記述し、必要に応じて
RubyのMatzさんがBruce Eckelのエントリを紹介している。この2:8の法則を掛け合わせるという論法は他にもいろいろ使えそうな感じ。例えば、8割のプロジェクトは失敗と見なされており、成功した残り2割のプロジェクトを牽引したのはそのうちの2割なのだ、とか。8割の開発者は結果を出し得るプロジェクトに携われておらず、結果を出し得るプロジェクトに携わっている開発者のうち8割は実際の成果を上げられていないとか。 IT技術者ではトップ5%は残りの人たちの20倍の生産性を持つという。 これが本当のことであるとしたら、その科学的な根拠はなにか、という話。 80%の技術者は、本を読まない、イベントに参加しない、勉強しない。 それでどうして、それらを継続的に行う開発者と同等の生産性をあげることができるのか。 それらを行う20%のうち、さらに80%は、(まだ)うまく成果をあげられていない。 すると、
IT業界で無事にいたいなら銀行に関わるな 3Kとか7Kとか言われているが、底辺の会社にいなければそれほどひどくないし、正直どうでもいい。しかし関わった人は皆同じことを口にする。 銀行には関わるな。特に最新技術に詳しい人ほど真っ先に壊れる。すぐに逃げ出せ。 新規開発が出来ると思うな。10年以上経ったシステムのお守りがほとんど。当然コードは見るに堪えない。そのくせ仕事はたくさん来る。ほとんどがバグ修正か機能拡張。そして時間のほとんどはテストで消える。1行修正するだけでも数週間のテストが普通。OSが変わったら一年中テストで潰れる。 休みが人並みに取れると思うな。深夜まで仕事をするのが当たり前。GWと正月はないと思え。しかも一回や二回ではなく仕事辞めるまでずっとだ。 仕事の出来を褒められることを期待するな。動いて当然、止まったら新聞沙汰だ。当然直るまで何日でも徹夜。 キャリアの役に立つと思うな。業
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − @ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
タイトルが非常に差別的な響きであることは自覚しておりますが。 情報サービス産業に対しては,人月単価ベースのビジネスモデルがいけない,エンジニアを使い捨てている,高い単価でオフショアとどう戦うのか,とかいろいろなことがいわれているし,どっかに活路がないものかなとここ数年いろいろ調べたりもしたのだけれども,最近ふと別に情報サービス産業に明日がなくても構わないじゃないか,と考えるようになった. 結局のところ要件定義や仕様書に基づいてシステムをつくるという仕事は,ITが生む付加価値そのものを受け取るようにビジネスモデルができていないのだ.技術や製品・専門知識に希少性があった時代はそれでも儲かったが,ハードやソフト,それらに対する知識がコモディティ化した瞬間,サービスやソリューションそのものがコモディティ化することは避けられなかったのだろう. 「情報サービス産業に明日がなくても構わない」(@雑種路線
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く