おぉ!素敵記事発見した!

mooapp

XcodeプロジェクトをそのままGitで管理すると、
.xcodeprojファイル配下のメタデータに毎回差分が出て
その度にCommitを要求されて非常にめんどくさい!です。

Gitに無視してほしいファイルを.gitignoreで指定すると、
そんな面倒な手間からおさらばすることができます。

元の投稿を表示 さらに37語

ほむほむ。

NoliliLog

今日リリースされたiOS 6, マップやPassbookが目立った新機能だが、UDID/UUID周りについても重要な変更が行われている。
これらについてまとめておく。

UDIDへのアクセスは基本的にNG.
UDIDへのアクセスはiOS 5から非推奨とされている。
公式リファレンスでは、CFUUIDRefを生成し、アプリ内で保存するなどの方法をこれまでには紹介されていたが、iOS 6ではフレームワーク側でUDIDにかわるID(どれもUUID)を用意している。

+ [NSUUID UUID]
従来のCFUUIDRefのObjective-C版と考えていいだろう。クラス・メソッドの+UUID を呼び出せば、UUIDが新規に生成される。
NSString、バイト列に変換するインスタンス・メソッドも用意されている。
ただし、CFUUIDRefとToll-Free bridgeではない。

UIDevice.identifierForVendor
デバイス固有であるが、ベンダごと(Team IDごと)で異なるUUIDを返す。

ASIdentifierManager.advertisingIdentifier
デバイス固有で、すべてのアプリで共通のUUIDを返す。強力なスーパー・クッキーとして機能する。
広告ネットワークのSDKを開発することを想定されている。
advertisingIdentifierを広告目的で利用する場合、ASIdentifierManager.advertisingTrackingEnabledを参照し、ユーザがトラッキングを許可しているか、確認する必要が有る。ユーザが許可していない場合、このUUIDをトラッキング用途で利用してはならない。
この機能はUIKitには含まれず、利用するにはAdSupport.Frameworksをリンクしなければならない。
なお、advertisingIdentifierをトラッキング目的で提供することは、標準では許可されている。提供を拒否したい場合は、iOSの設定アプリから情報>アドバタイズ>Ad Trackingを制限 でオプト・アウトする必要が有る。

追記

iOS Developer Centerのソースは以下の通り

NSUUID Class Reference

UIDevice Class Reference

Ad Support Framework Reference

追記その2

UIDevice.identifierForVendorとASIdentifierManager.advertisingIdentifierはデバイスの初期化等で再生成され、値が変化する可能性がある。値が変化するタイミングについては、現在調査を進めている。

元の投稿を表示

A-Listers

お馴染みのCoding Horrorでプログラミングの隠語(ジャーゴン)についての記事が話題です。

このエントリの元になったのはStack Overflow上で行われた「あなたが新しく作ったプログラミングのジャーゴンはなんですか?(New programming jargon you coined?)」という質問です。この質問にはなんと386もの回答が寄せられ、その中でStack Overflowのコミュニティの投票で上位になった30のジャーゴンをリストにして解説したのがCoding Horrorの「Coding Horror: New Programming Jargon」という記事です。

下記がコミュニティによって選ばれたジャーゴンのリストです。

1. Yoda Conditions(ヨーダ条件式)


変数とリテラルを比較する際にリテラルを左辺に置く記述。スターウォーズのヨーダが「The sky is blue」ではなく「if blue is the sky」と喋る事から。

2. Pokémon Exception Handling(ポケモン例外処理)

全ての例外を捕まえようとする事。

3. Egyptian Brackets(エジプト人ブレース)


行の最後でブレースを開くスタイル。エジプト人のイラストの手の位置から。

4. Smug Report(ドヤ顔レポート)

自分自身では大した事はしていないのにでシステムデザイン事がわかっているつもりの人によって投稿されるレポート。見当違いの詳細や(間違った)解決策の提案などが添えらている。

関連語としてDrug Report(ラリってるレポート)、Shrug Report(エラーメッセージなどが無く動かないとだけ書かれている)などがある。

5. A Duck

理由もなく追加され、不要な影響を避ける為に結局取り除かれる機能。

あるアーティストがアニメーションの制作に参加した際に、他のアニメーションに影響を与えないようにカモのキャラクターを追加した。プロデューサーによるデビューの際、プロデューサーからのコメントは「良いね、ただカモだけは取り除いてくれ」

6. Refuctoring(リファクリング)

良いデザインのコードにしようとしてあちこち弄り回した結果、誰にもメンテナンスできないコードになること。

7. Stringly Typed(謎の型付け)

強い型付け(strong typing)のもじり。適切な型のパラメータを取ればよいのに、わざわざ独自の文字列を使ったりするなど。

8. Heisenbug(ハイゼンバグ)

それを調査しようとすると変貌したり消えたりするバグである。この名前は不確定性原理を提唱したハイゼンベルクのもじり。

ex) この名前は不確定性原理を提唱したハイゼンベルクのもじり。

9. Doctype Decoration

DoctypeだけHTML5でマークアップは滅茶苦茶といったような様子。

10. Jimmy

標準的な新人プログラマの名前。「もしジミー君が属性の更新をしなかったらどうなるでしょう?」というような例えに使う。

11. Higgs-Bugson(ヒッグスバグ粒子)

ヒッグス粒子 – Wikipediaのもじり。非常に僅かなログなどで存在すると仮定されるが、存在は確認されていないバグ。

12. Nopping

アセンブラなどで使う何もしない命令、NOP – Wikipediaから。昼寝(Napping)に似ているが寝ている訳ではない。

13. Unicorny

かなり初期の計画段階の為、まるで空想の出来事のように説明がつかない機能。

14. Baklava Code(バクラヴァコード)

Baklava - Turkish special, 80-ply.JPEG

トルコのミルフィールのような菓子。レイヤーが多すぎる事。

15. Hindenbug(ヒンデンバグ)

ヒンデンブルグ号の爆発事故のように悲劇的なデータ消失を引き起こすバグ。

16. Fear Driven Development(恐怖駆動開発)

解雇、締め切りの前倒し、リソースの削減などのプレッシャーが管理者から加えられる事。

17. Hydra Code

不死身のヒドラのように直せないコード。1つバグを直すと新しく2つのバグが発生する。

18. Common Law Feature

間違っているのにも関わらず、仕様の一部になってしまったバグ。

19. Loch Ness Monster Bug(ネス湖の怪物バグ)

再現性がなく、目撃者が1人しかいないバグ。

20. Ninja Comments

見えないコメント、秘密のコメント、またはコメントが無い事。つまりコメントが無い。

21. Smurf Naming Convention

全てのクラスに同じプリフィクスがついていること。
例:ユーザがボタンをクリックするとSmurfAccountViewがSmurfAccountDTOをSmurfAccountControllerへ渡す。

22. Protoduction(プロトダクション)

プロトタイプのまま世に出たもの。

23. Rubber Ducking

問題を誰かに説明していると自然と解決策が見つかる事があるので、アヒルのおもちゃに語りかけてみること。

24. Banana Banana Banana

あとでドキュメントを書く所に埋めておくテキスト。IDEの警告を回避する為にとりあえず埋める。

25. Bicrement

変数に1を加算する(インクリメント)ではなく2を加算する。

26. Reality 101 Failure

意図したとおりに動いているが意味のないコード。

27. Mad…

元の投稿を表示 さらに38語

Agile Cat --- in the cloud

http://www.codefutures.com/database-sharding/

Database Sharding 1

Figure 1. The growth in database transactions and volumes has a large impact on response times.

 





元の投稿を表示

ジェネシックスブログ

ふたたび…リジェクト経験だけは豊富な @rikanakayama です。

突然ですが、iTunes Connectでアプリを新規登録する際に、アプリ名とかキーワードとか説明文とか『これって後から変更できるんだっけ?』っと迷うことってないですか?えっと、わたしはいつも…。
ということで(困っているのは自分だけかもしれませんが)iTunesの登録項目を更新可否のレベルで一覧にしたのでシェアさせていただきます(ただの箇条書きだけど)。ついでに各項目を登録する際の注意事項や、わかりにくい項目についての解説も個人的観点で選別してまとめてみました。

いい加減なことを書かないよう、参照には信頼と実績の iOS Developer CenteriTunes Connect 公式ガイドライン(バージョン 7.3, January16, 2012)を使いました。とはいえ、よく仕様変更がある分野なので、この記事はご自身の責任において活用してください 。

【各項目の編集レベル】

(1)一度設定したら変更できない項目
・SKU
・Bundle ID

(2)バージョン単位で更新可能で、In Review以後は更新NG
Rejectされると(Developer Rejectなど含む)は更新OKとなる。
・Version Number
・Category
・Rating
・App Name
・Keywords
・Large Icon
・Review Notes
・Localization(追加) ※削除はいつでもOK

(3)いつでも更新OK
・Copyright
・Description
・Support Email Address
・Support URL
・Marketing URL
・Privacy Policy URL
・Screenshots
・EULA
・What’s New in This Version? ※初回登録時は不要
・Rights & Pricing ※バージョン単位でなくアプリ単位

元の投稿を表示 さらに103語

モバイル端末でのHTML5

気になる記事。

現在絶賛HTML5でのモバイル端末(iPhone,Android向け)ゲームアプリ開発をしてるけど、遅い遅いとは思っていたものの、ここまで遅いのかーなんて。

実際に計測できるコードをかきたいと思うものの、まだ勉強不足でよくわからない部分が多いんだよねorz
難しい。

もっと勉強せねばなーと。