Singleton Methodを削除する方法 についてですが、 Objectクラスに用意されているとありがたいですね。

object_ext.rb

   1  class Object
   2    def remove_singleton_method(*args)
   3      (class << self; self end).class_eval do
   4        args.each{|i| send :remove_method, i}
   5      end
   6    end
   7  end

こんな感じ。

方法を探していたのですが、意外と苦戦したのでメモ。

   1  object = new Object
   2  def object.foo; end
   3  object.singleton_methods #=> [:foo]
   4  (class << object; self end).class_eval{send :remove_method, :foo}
   5  object.singleton_methods #=> []

これで行けるようです。instance_eval{undef foo}でも削除はできますが、その場合親クラスのメソッドにもアクセス出来なくなってしまうので、 singleton methodだけを削除する場合には、 メタクラスのインスタンスメソッドをremove_methodするのが良いようです。

カメラ系やメモ系のアプリなんかはユニーク/一意な名前を考えるのに苦労します。で、*.appファイル名と、iPhone上で表示される表示名を変えたいと思ったのでメモメモ。

Store上で表示される名前と*.appファイル名と、iPhone上の表示名が違っても申請が通るかどうか、またどれくらい違ったらokなのか気になるところです。ちなみにStore上とiPhone上の表示名は違うことはよくあるみたいで、Store上ではより長い仕様分かりやすい名前にするのをよく見かけます。

結論：CFBundleDisplayNameを編集すればok

例えばShopping Pink.appというappファイル名で、表示はShoppingとすることが可能です。

Info.plistで：

   1  	<key>CFBundleDisplayName</key>
   2  	<string>Shopping</string>
   3  	<key>CFBundleExecutable</key>
   4  	<string>${EXECUTABLE_NAME}</string>

CFBundleDisplayNameとCFBundleNameの違い

ぐぐったところ、CFBundleNameはQuickLookでindexされる名前？？、CFBundleDisplayNameは言語毎にローカライズしたい時に使うプロパティだということがわかりました。

/ Localized versions of Info.plist keys /

NSHumanReadableCopyright = "© __MyCompanyName__, 2008";
CFBundleName = "English MenuBar"; //...and Finder's QuickLook
CFBundleDisplayName = "EnglishApp";
http://forums.macrumors.com/showthread.php?t=537977

Refs

http://eien.seesaa.net/article/27964381.html
http://forums.macrumors.com/showthread.php?t=537977
http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/LocalizingPathnames.html#//apple_ref/doc/uid/20002141-97582-BCIDCGHG

An Idea for Open Avatar Exchange

I am using GRAVATAR at github.com. It is very interesting service that provides globally recognized avatar image from a hash of email address. What is clever is a service using GRAVATAR can present its user's avatar without not exposing his/her email address.

But the GRAVATAR is not the only provider of such avatars. For example, twitter.com has huge database of mapping from email address to avatar image. There are a lot of services which have such the database.

Imagine twitter.com, facebook, linkedin and so on provide their avatar images by the same manner. We can provide avatar image for every user of which we know his/her email address everywhere and quite easily. This is the principal advantage of this idea.

But what is advantage for provider? That's the obvious question. Answer is inter-service completion of avatar images. In each service, not all users have his/her avatar image. For such users, the service provides disappointing default avatar image. But if there is the open avatar exchange, the service can try to find it in other services instead.

The way to make the exchange is really simple. Provide REST API to map MD5 hash of email address to avatar image. Block accesses from domains you don't want to exchange.

In addition, avatar providers can harvest stats of the sites that are using your avatar image.