武之新

dojox.form.Uploaderのtips

Mon, 07 Nov 2011 16:38:34 +0900

dojox.form.Uploaderを使っててほいほいハマるので、ほぼ備忘録としてのメモ。

* POST時に他のデータも渡したい

uploadWithFormData()を使う。uploadOnSelectをtrueにすると勝手にsubmitされてしまうので、ファイルを選択されたらすぐにsubmitしたければ

<button data-dojo-type="dojox.form.Uploader" data-dojo-props="
	id: 'uploader'
	, name: 'uploaded'
	, multiple: false
	, uploadOnSelect: false
	, url: 'xxx'
	, onChange: function(){
		doUpload();
}">upload now!</button>

function doUpload(){
	var uploader = dijit.byId("uploader");
	uploader.onComplete = function(array){
		if (array[0] == "succeeded"){
			// succeeded
		}
		else {
			// failed
		}
		uploader.reset();
	};
	uploader.uploadWithFormData({
		"hoge": "hoehoe"
	});
}

とやっておけば概ねおｋ

* 1回目は動いたけど、2回目が動かない

ファイル名が同じだとonChangeが発生しない。同じファイル名でもsubmitしたければ、onCompleteの最後のほうでreset()を呼ぶ。

celeryでsingletonなタスク

Fri, 14 Oct 2011 16:39:00 +0900

djangoでバッチ処理や非同期処理を組もうとしてceleryを導入。使い方も簡単でとても便利。

が、多重起動されたら困る処理を制限しようとしても、celery自体にはそういう機能がない模様。celeryのcookbookをみると、celery.task.Taskを継承したクラスを自分で作ればいいらしい。でもいちいちclassを定義するのは面倒。

というわけでdecoratorでsingletonなタスクを実現できるようにしてみた。

やり方は簡単。というかcookbookの実装そのまんま。

def singletonTask(lockkey):
	def _make_runner(func):
		def _work_or_die(*args, **kwargs):
			expire_time = kwargs.get("expire", SINGLETON_TASK_EXPIRETIME)
			acquire_lock = lambda: cache.add(lockkey, "true", expire_time)
			release_lock = lambda: cache.delete(lockkey)

			
			#logger = _make_runner.get_logger()
			#logger.info("check working flg...")
			
			if acquire_lock() :
				try:
					#logger.info("started....")
					func(*args, **kwargs)
					
				finally:
					release_lock()
	
			else :
				#logger.info("job cancelled")
				raise TaskAlreadyWorking(lockkey)
				
		_work_or_die.__name__ = func.__name__
		_work_or_die.__module__ = func.__module__
		return _work_or_die
			
	return _make_runner

弱点は_work_or_dieの中ではloggerが使えないこと。func.get_loggerも、_work_or_die.get_loggerもうまくいかなかった。困った。

あとキモは_work_or_die.__name__ を func.__name__ に書き換えていること。celeryのtask生成部分を見てると、@taskにnameを与えない限り、func.__name__ を元にtaskの名前を決めている。なので _work_or_die.__name__ を書き換えないでそのまま返すと、全て同じ名前になり、正しいタスクが起動できなくなる。

最初気が付かなくてハマったので、FAQの decorating tasks のあたりにでも書いておいてほしいなぁ。

2011/10/15 追記

__module__も書き換えないとダメなことを忘れていたので追記

dojoでハマってる

Wed, 31 Aug 2011 09:15:00 +0900

Webアプリを開発中で、ブラウザ側はdojoを使っているのですが、色々とハマっております。現在最も困っているのがdojox.grid.DataGridに埋め込んだdijit.form.Buttonの挙動。
dojox.grid.DataGridがなかなか強力で、これが使いたいためにdojoを選んだわけですが、このgridの各行にbuttonを配置すると途端に挙動が怪しくなってきます。

（１）ボタン文言をasciiにすると見た目が装飾されない。

表題の通りだけど、文章からは現象が伝わりづらい。次の画像をみるとわかりやすい。

ascii

not ascii

同じタグ構造で、上はボタンの文言が「test」、下は「テスト」。この違いだけで見た目がこのように変わる。どちらも画像左上に「test」ボタンがあるが、このようにgridの外であればこの現象は起きない。わけがわからん。

追記：
gridのformatterで＜button data-dojo-type=”dijit.form.Button”＞test＜/button＞とやるとおかしくなるが、ボタンが1個だけでよければ

formatter: function(value, index){
  return new dijit.form.Button({
    label: "test"
  });
}

とやればasciiでも期待通りになる模様。ボタン2個のときはどうしたらいいのだろう…

（２）gridの中に入れたdijit.form.Buttonをクリックすると、外のwidgetにイベントが伝播する。

これまた意味不明な挙動なのだが、次のようなタグ構造があるとする。

＜div data-dojo-type="dijit.Dialog"＞
  ＜form id="frm" data-dojo-type="dijit.form.Form"＞
  ＜div data-dojo-type="dijit.layout.BorderContainer"＞
    ＜div data-dojo-type="dijit.layout.ContentPane"＞
      ＜div id="grid" data-dojo-type="dojox.grid.DataGrid"＞＜/div＞
    ＜/div＞
    ＜div data-dojo-type="dijit.layout.ContentPane"＞
      ＜button data-dojo-type="dijit.form.Button"＞ボタンA＜/button＞
    ＜/div＞
  ＜/div＞
  ＜/form＞
＜/div＞

このとき「ボタンA」をクリックする分にはそのボタンのonClickが動くだけなのだが、gridの中にボタンを配置しそれをクリックすると、そのボタンのonClickが実行された後にfrmがsubmitされてしまう。
とりあえずfrmのonSubmitにfunction(){ return false; }を入れて回避しているが、普通にsubmitさせたいformの場合は困ってしまうだろう。

gridに絡まない部分ではクセさえ掴めば割といい感じなのだが、（といってもdijit.formにほしいwidgetがないとが色々あるけど）、gridとdijit.formを組み合わせるとイマイチなのかもしれない。

ファイルアップロード処理でtempfileを使う

Thu, 04 Aug 2011 17:11:27 +0900

ファイルアップロードをする際にposterを使っています。とても便利なのですが、実体ファイルを構築して、posterに食わせて、ファイル削除、という手順が面倒だったので、tempfileを使ってみました。

# make temporary file
temp = tempfile.TemporaryFile()
temp.write(simplejson.dumps({
	"seq": 1,
	"abc": 123,
	"def": "ASD"
}))
temp.write("\n")
temp.write(simplejson.dumps({
	"seq": 2,
	"abc": 123,
	"def": "ASD"
}))
temp.write("\n")
temp.write(simplejson.dumps({
	"seq": 3,
	"abc": 123,
	"def": "ASD"
}))
temp.flush()
temp.seek(0)


# encoding
datagen, headers = multipart_encode({
	"args": "other parameter", 
	"datas": temp
})


# create request
request = urllib2.Request("http://localhost:8000/fileupload/", datagen, headers)

# do post !
response = urllib2.urlopen(request)

これで少なくともファイルの後始末は気にしなくてよいので便利。ちなみにSpooledTemporaryFileだとうまくいかない。rollover()すればイケるかもしれないけど未検証。

pythonのissubclassでハマる

Thu, 04 Aug 2011 11:51:43 +0900

最近djangoでWebシステムを作るお仕事しています。python、djangoはなかなかよく出来ていてハマるところが少ないのですが、うっかり軽くハマったのでメモ。

あるクラスがあるクラスを継承しているかどうかをチェックするためには組み込み関数のissubclass()を使いますが、継承元が抽象クラスだとissubclass()はFalseを返してくるらしい。

検証のために次のようにやってみた。

>>> class ABC(object):
...     class Meta:
...             abstract = True
... 
>>> class GHJ(ABC):
...     hoge = 1
... 
>>> issubclass(ABC, GHJ)
False
>>> 
>>> 
>>> class ZXC(object):
...     hoge=1
... 
>>> class ASD(ZXC):
...     hoge=2
... 
>>> issubclass(ASD, ZXC)
True
>>>

わかってしまえばなんてことないんですが、うっかりすると欲しい結果にならないので要注意

Titaniumで死ぬほどハマる

Wed, 13 Jul 2011 13:38:51 +0900

最近TitaniumでiPhone&Androidアプリを作ってたりしますが、これが死ぬほどハマる地獄道でした。特にAndroid。iPhoneはそれなりにクセがあるけど、理解さえすればそうでもないのですが、Androidは別格です。

いまハマっているのはカメラ。ただ写真を撮って、それをアプリで使いたいだけなのに、なぜか写真を撮り終わったときのイベントハンドラが呼ばれない…。

var test_window = Ti.UI.createWindow({
    title:'test',
    backgroundColor:'#fff'
});
var tab_test = Ti.UI.createTab({
	title: "test",
	window: test_window
});
var label1 = Titanium.UI.createLabel({
	color:'#999',
	text:'I am Window 1',
	font:{fontSize:20,fontFamily:'Helvetica Neue'},
	textAlign:'center',
	width:'auto'
});

test_window.add(label1);
label1.addEventListener("click", function(e){
	
			Ti.Media.showCamera({
				saveToPhotoGallery: true,
				allowEditing: false,
				mediaTypes: [Ti.Media.MEDIA_TYPE_PHOTO],
				cancel:function(){
					Ti.API.warn("camera cancelled");
				},
				error:function(){
					Ti.API.warn("camera error");
				},
				success: function(event){
					Ti.API.warn("camera succeeded");
				}
	});
});

やっているのはこれだけ。空っぽのprojectを作って、これをapp.jsに書くと動くのだけど、実際のアプリに組み込むとsuccessもcancelもerrorも呼ばれなくなったりするのです。どうやらapp.jsなら動くというところに回避策がありそうですが、いまのところドハマリ中。

他にもドキュメントに書いてあるけど未実装だったり、ググると出てくるサンプルコードがいまの最新では動かなかったり、そもそもそのサンプルで使ってるAPIはドキュメントに書いてなかったり、まぁ、いろいろ香ばしい。まだ実戦で使うものではない気がしてきています。

xibのローカライズでハマる(2)

Wed, 04 May 2011 12:30:56 +0900

以前もハマったxibのローカライズ。またもハマりました。

どうやらxibをローカライズ前（言語環境毎のファイルを作る前）に実機転送してしまうと、その状態を覚えてしまうのか、その後どうやってもxibの内容が反映されなくなるという状態に陥りました。わけわかんない。
他にも、今回はNSLocalizedStringでいままで取れていた日本語リソースが、ある時点を境に英語しか取れなくなったりと、ローカライズ関連でハマりまくりです。

NSLocalizedStringのほうはどうやらフォルダの名前に問題があった模様。古いXcodeで作ったprojectなので、English.lproj や Japanese.lproj とかになっていたのですが、これを en.lproj 、 ja.lproj に変更したら日本語が取れるようになりました。

xibのほうは最後まで解決策がわからず。
仕方ないのでファイル名をrenameしました。renameするととりあえず反映されるようになりました。ホントにもう、わけわかんない。

EXC_BAD_ACCESSでハマる

Tue, 03 May 2011 12:28:00 +0900

iPhoneで開発してて、よく突き当たるのがEXC_BAD_ACCESS。
大抵は多重releaseしてしまうなどの単純ミスですが、稀に不可解なEXC_BAD_ACCESSに陥ることがありますよね。今回たまたま不可解なEXC_BAD_ACCESSが解決できたので、その顛末を参考までに書いてみます。

今回起きたのは「UIWebViewで画像長押し時にActionSheetを表示する」という処理の中。

UIWebViewは内包する子Viewの中で処理を行い、UIWebView自体は入れ物でしかなく、UIWebViewにUILongPressGestureRecognizerを登録しても無意味です。なので「UIWebViewで画像長押し」を検知するのに色々小技が必要になります。
今回検知のためにNSObjectのrespondsToSelector:をmethod swizzlingしていました。ここで長押しを検知し、NSNotificationCenterを経由してActionSheetを出す、という仕組み。処理としては、

(NSObject) respondsToSelector:
NSNotificationCenterのpostNotificationName:object:を使って自作クラスのハンドラを呼び出す。
(自作クラス) notificationハンドラ
ここでUIActionSheetを構築、表示
(UIActionSheet) showInView:

という流れ。

この処理の流れでテストを行っていたところ、うまく動作するときもあるのですが、(3)の段階でEXC_BAD_ACCESSが起きることがあります。(2)でUIActionSheetを構築してる段階では問題なし。UIActionSheetの構築コードは元々バッチリ動いていた箇所からの転用なので、それが原因とも思えないですし、UIActionSheetを作ってもshowInView:を呼び出さなければEXC_BAD_ACCESSも起きないため構築に問題があるわけではないらしい。
当然UIActionSheet関連処理をすべてコメント化するとEXC_BAD_ACCESSは起きない。

正直かなりお手上げ状態。なにがダメなのか？？？
上記処理は1から3まですべて同期的に動くので、それがダメなのかな？

試しに(3)を別メソッドに切り出し、(2)からperformSelector:withObject:afterDelay:を使って非同期式に変えてみたところEXC_BAD_ACCESSが出なくなりました！わーい！

というわけで、私が今回ハマったEXC_BAD_ACCESSではrun loopに戻る前にやってはいけないことをやっているようでした。たぶんrespondsToSelector:から戻った後の処理のなにかとバッティングしているのでしょう。なにとバッティングしているのかは全くわからず、Appleのみぞ知ることでしょう。回避できたのはたまたまです。

不可解なEXC_BAD_ACCESSがいつも同じ理由というわけではないですが、こういうこともあるようです。困ったときの参考になると幸いです。

UIWebViewでリンク長押し時のActionSheet

Tue, 12 Apr 2011 19:05:48 +0900

UIWebViewはデフォルトで、リンクを長押ししてるとActionSheetが出てきます。選択肢がOpenとCopyしかないので、実質あまり意味がなかったりしますが。
なのでこのActionSheetのボタンをアプリでカスタマイズしたい諸兄も多いことでしょう。

そんなときのTips。

まず問題は長押しされたことの検知と、長押しされたリンクのURLの取得。相変わらず、普通にやるとActionSheetが表示されたことすら検知することができません。GestureRecognizerを当てれば長押しされたことだけはわかりますが、それだとリンクURLを抜き出すことが不可能（だと思う）なので、UIWebViewの仕組みを使いたいところです。

私がやったチカラ押しな方法は次の通り。

NSObjectのrespondsSelectorをmethod swizzling。
置き換えたメソッドの中でtouchCalloutEnabledを監視させる。 touchCalloutEnabledでActionSheetを出すべきかどうかを判断させているようなので、これが呼ばれた＝ActionSheetの出番、という判断にできる。
UIActionSheetのshowInView:をmethod swizzling。touchCalloutEnabledが呼ばれた直後のshowInView:はUIWebViewが出そうとしているので、それを出さない（捨てて）、独自にActionSheetを表示する。
長押しされたリンクのURLはActionSheetのtitleになっているので、それを使う。

というゴリ押しな方法で、とりあえず独自ActionSheetが出せる。
注意点はshowInView:でUIWebViewが表示しようとしたActionSheetを捨てるところ。なにもしないまま放っておくと、ActionSheetが閉じるのを待っているのか、UIWebViewが動かなくなる。仕方ないのでキャンセルボタンが押されたかのように

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo} actionSheet:clickedButtonAtIndex:
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo} actionSheet:willDismissWithButtonIndex:
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo} actionSheet:didDismissWithButtonIndex:

を呼び出してあげると忘れてくれます。
相当ごり押しな方法ですが、なんとか目的達成。もっとスマートな方法があれば誰か教えてください…

ちなみに、ActionSheetを出さないのは

[webView stringByEvaluatingJavaScriptFromString:@”document.documentElement.style.webkitTouchCallout = ‘none’;”]

とやるだけで簡単にブロックできます。

UIWebViewでcanGoBackが効かない

Tue, 29 Mar 2011 09:49:00 +0900

UIWebViewではページの読込ませ方によってcanGoBack, canGoForwardの挙動が変わるようです。

canGoBackがYESになる
loadRequest:

canGoBackがNOのまま
loadData:MIMEType:textEncodingName:baseURL:
loadHTMLString:baseURL:

これはcanGoBackだけでなく、実際にgoBackしても動作しなくなります。historyがきちんと更新されるのはloadRequest:だけのようです。

Javascriptでhistoryがいじれるといいのですが、試しにやってみたところ期待通りにはいきませんでした。できそうなものなんですけどね、、

アプリの申請でハマる

Sun, 20 Mar 2011 00:10:23 +0900

はじめてiPhoneアプリをAppleに申請してみました。
が、そこで思いっきりハマりまくりでした。

ハマったのは次の２点。

証明書を取らないとダメ
申請するアプリはCode Signされてないとダメで、Code Signは個人証明書を取得してないとダメなわけです。と言ってもこれは比較的有名なハマりポイントらしい。

スクリーンショット不足
初めてのくせにiPhone, iPadのユニバーサルアプリにしてみたので、iPad用スクリーンショットもアップロードしないとmissing screenshot状態でストップしてしまいます。追加すればよいのですが、Localizeしてると、言語毎にスクリーンショットも独立しているので、全ての言語にiPad用スクリーンショットをアップロードしないといけません。

どハマりしたのはスクリーンショットで、アップロードしたのに状態が変わらず焦りました。こんな状態になるのはユニバーサルかつLocalizeしたときくらいでしょうからレアケースだと思いますが。

xibのローカライズでハマる

Fri, 04 Mar 2011 15:07:17 +0900

設定画面など、あちこちに文字列を埋め込んだ画面はいちいちコードでNSLocalizedStringするのが面倒なので、xibをローカライズしてしまうのが簡単だと思います。

はじめてxibをローカライズしてみたのですが、色々ハマりました。

xibはサブフォルダの中でローカライズしてはいけないらしい。
たまたまユニバーサルアプリでやっていたので、xibがiPhoneサブフォルダの中に出来てしまいました。そこに置いたままローカライズすると認識されない模様。文字列リソースをローカライズするとプロジェクトフォルダの直下にJapanese.lprojができますが、そこに入らないとダメみたい。

サブフォルダの残骸はFinderで削除しないとダメみたい。
一回xibをサブフォルダで作ったあと、サブフォルダにできたJapanese.lprojの中にxibが残ったままにすると、Xcode上でxibを削除しても、ビルド時に掴んでしまうくさい。
サブフォルダに作ったxibと同じ名前でプロジェクトフォルダ直下に作り直しても、残骸が残ったままだとそっちが優先して使われているようで、うまく動かなくなりました。

それにしても、Xcodeはメジャーバージョンが変わるたびに作法がガラリと変わるので、ネットで調べてもどれがいまも使える方法なのかがわかりづらいですね。

UIWebViewでフォントサイズをいじる

Thu, 03 Mar 2011 10:12:27 +0900

相変わらずUIWebViewと格闘中です。

AppStoreにあるブラウザアプリで、フォントサイズが変更できるものがあったので、真似してみることに。

やり方は簡単、次のようにやるだけ。

script = @"document.getElementsByTagName('body')[0].style.webkitTextSizeAdjust='120%';"; [webView stringByEvaluatingJavaScriptFromString:script];

jQueryなどでスタイルのfont-sizeをいじっても、HTML上のスタイル定義のされ方によって適用されたりされなかったり安定しません。webkitTextSizeAdjustを使えばそういうときでもイチコロです。

元ネタはこちら。
http://stackoverflow.com/questions/589177/how-to-increase-font-size-in-uiwebview

続：NSURLCacheでGoogleのトップページをキャッシュすると落ちる件

Mon, 21 Feb 2011 14:09:00 +0900

結局解決できていません、本件。

あれからさらにいろいろ試して、見えてきたのは[NSURLRequest cachePolicy]。

そもそもは、デフォルトのNSURLCache実装がstoreCachedResponseでデータを渡されていてもcachedResponseForRequestで返すものと返さないものが存在している、というところでした。

なぜか？
データは違えども、NSCachedURLResponse、NSURLResponseの状態は概ね同じ。違うのは[NSURLRequest cachePolicy]。デフォルトのNSURLCacheはNSURLRequestReturnCacheDataElseLoad、NSURLRequestReturnCacheDataDontLoadの場合はキャッシュを返すけど、NSURLRequestUseProtocolCachePolicyの場合は返さないようです。

相変わらず理由はわかりませんが、真似してみることに。

ふむ、落ちなくなった。

前回も落ちなくなった後、他の箇所をいじっていたら再発したので安心できませんが、とりあえず改善。どうやらものすごく微妙なバランスで動いているようです、NSURLCache。

ただ、割といろんなリソースがNSURLRequestUseProtocolCachePolicyでリクエストされているので、NSURLRequestUseProtocolCachePolicyだとキャッシュを返しちゃだめとなるとローカル保存からWebページを再現するのは難しいのかもしれません。。

[iPhone]UIWebViewでNew Windowをなんとか検知する

Mon, 21 Feb 2011 12:00:06 +0900

先日（どころか実際には昨年から）ハマってるUIWebViewですが、懸案課題のNew Windowの検知が次のような姑息なアイデアでなんとかなりました！

やり方は次の2つの組み合わせ。

UIWebViewの webView:willClickElement: をoverrideして、elementからtarget属性を探す。（Aタグ用）
UIWebViewの stringByEvaluatingJavaScriptFromString: でJavascriptの”window.open”を書き換えてしまい、window.openされたら特殊なURLに飛ぶようにして、webView:shouldStartLoadWithRequest:navigationType: で検知する。（Javascript用）

(1)は簡単で、次のような感じ。

@implementation UIWebView(hack)

- (void)webView:(UIWebView *)sender willClickElement:(id)element {
   BOOL is_new_window = NO;
   NSString* nodeName = [element nodeName];
   NSString* hrefURL = [element hrefURL];
   NSString* textContent = [element textContent];
   id attributes = [element attributes];
   int length = [attributes length];
   for(int i = 0; i < length; i++ ) {
   id item = [attributes item:i];
   NSString* name = [item name];
   NSString* value = [item value];

   if (NSOrderedSame == [name compare:@”target” options:NSCaseInsensitiveSearch]){
   is_new_window = YES;
   break;
   }
   }

   if (is_new_window){
   NSLog(@”clicked!!”);
   }
}

@end

これは http://son-son.sakura.ne.jp/?p=752 を参考にさせてもらいました。

(2)はなかなか面倒で、次の２ステップが必要。
まず、webViewDidFinishLoad: でwindow.openを書き換える。書き換え方は

[webView stringByEvaluatingJavaScriptFromString:
@”window.open = function(url, window_name, options){
   window_name = window_name == ” ? ‘_blank’ : window_name;
   location.href = ‘wopen://’ + (window_name == null ? ‘_blank’ : window_name) + ‘/’ + url;
   };”];

こんな感じ。あとでURLからwindow.openが呼ばれたことと、遷移したいURLがわからなければならないので、schemeを独自のものに書き換えてしまうのがよいと思う。

続いて、webView:shouldStartLoadWithRequest:navigationType: で検知する部分。

- (BOOL)webView:(UIWebView *)webView
   shouldStartLoadWithRequest:(NSURLRequest *)request
   navigationType:(UIWebViewNavigationType)navigationType
{
   NSURL *url = [request URL];
   if ([[url scheme] isEqualToString:@”wopen”]){
   NSString *host = [url host];
   if (host != nil && [host isEqualToString:@”_blank”]){
   NSLog(@”new window!”);
   }
   return NO;
   }

   return YES;
}

URLのscheme部分をみてwindow.openなのかどうかを見極め、遷移先を[URL path]で取って、あとは自分でどうにかする、という感じです。

自分もまだ基礎実験までしかやってないので、すごく見切り発車的エントリです w
このあとアプリに実装してみようと思います。

NSURLCacheでGoogleのトップページをキャッシュすると落ちる件

Sun, 20 Feb 2011 17:29:00 +0900

原因が特定できなくて困っていた、Googleのトップページでだけ発生する落ちバグがあったわけですが、なんとなく原因が特定できたくさい。
ちなみにこれは次のような現象。

Googleのトップページ（http://www.google.co.jp/）の内容を保存しておき、通信しないでUIWebViewで表示しようとすると落ちる。
キャッシュの仕方はNSURLCacheでやろうと、別の方法を使っても発生する現象は同じ。
落ちるのはHTTPProtocol::createStreamのあたり。起きているのはEXC_BAD_ACCESS

あちこちのサイトをキャッシュしてみても、上記現象が起きるのはなぜかGoogleだけ。Googleとは言っても、ニュース（http://news.google.co.jp/）では大丈夫だったりします。

さらに、EXC_BAD_ACCESSは通常過剰releaseによって解放済みのメモリにアクセスすると起きるものですが、いくらretainかましても改善しませんでした。過剰releaseならGoogle以外でも発生するだろうし、ランダム要素があるなら http://www.google.co.jp/ で100％発生するというのはおかしいので、やはりGoogleさんのサイト構造に起因するものとして調べてみました。

とはいってもソースもないライブラリの中で起きてる例外なので調べようもなく、できることといえばファイルの構成をよくよくみてみるくらい。じーっ、とよく見てみると、試してみたサイトの中で、唯一 http://www.google.co.jp/ だけHTML5のmanifestファイルが含まれていました！

試しにmanifest指定を削ってみます。

落ちない！　これか！

理屈はわかりませんが、とりあえずmanifest指定を削ってしまうとよいようです。

（2/21追記）

いろいろいじってるうちにまた落ちるようになりました。違うらしい。

[iPhone]UIWebViewで困ってること

Sun, 20 Feb 2011 12:00:06 +0900

相変わらずUIWebViewと戯れているわけですが、いまのところ次の2点で困っていたりします。

リンクを長押ししたときに表示されるActionSheetのカスタマイズ方法がわからない
新しいWindowを開こうとしていることを検知できない

iOS4.2だと、長押ししているとUIWebBrowserViewに longPressGestureCanTransitionToRecognizedState: というメッセージが送られてきているようなので、このselectorを書き換えてしまえばなんとかなりそうです。
ですが、UIWebBrowserView は非公開クラスなので、いつ実装が変わるかわからないのであまり適切な方法ではなさそうです。

一番困っているのは2のほうで、Aタグの場合（<a href=”hoge” target=”_blank”>等の場合）は検知ができているのですが、Javascriptでwindow.openしようとしていることが検知できなかったりしています。
AppStoreでタブブラウザをいくつかダウンロードしてみたのですが、window.openもきちんと別タブにするアプリもあり、なんらかの方法で検知できるようです。はてさて。。

[iPhone]サイトをローカル保存するための格闘

Sat, 19 Feb 2011 10:40:00 +0900

iPhoneを使っていて、最もイライラするのは通信状況。電波の受信感度はバッチリでも通信できないということが珍しくありません。
iPhoneのせい、というよりは、Softbankの電波のせいなわけですが。

iPhoneのSafariは（というか普通のブラウザはみな）一回みたページに戻る場合でも最新かどうかを判断するため通信しようとするので、通信状況が不安定だとブラウジングがものすごくイライラします。

そこで一度みたページをすべてキャッシュし、キャッシュがあれば最新チェックもなにもかもすっ飛ばして表示してくれるアプリを作ろうとしています。が、これがなかなかに難儀しています。

いままでチャレンジしてみたこととしては、

(1) webView:shouldStartLoadWithRequest:navigationType: で保存すべきURLがわかるか？

ドキュメントのURLはこれでわかるけど、画像やCSSなどのリソースについては呼び出されないのでわからない。さらにJavascriptでXHRとかしてるとそれは呼び出されてしまい、なにがページでなにがXHRかわからない。

(2) いっそのこと webView:shouldStartLoadWithRequest:navigationType: に飛んで来たURLからHTMLを取得し、中身をparseして画像やCSSなどのリンクをたどればできるんじゃないか？

HTML、CSSのparseはできた。
GoogleやYahooなどではCSSをJavascriptで後から追加するので、HTMLだけparseしても正しく表示できない。
Javascriptのparseはさすがにちょっと無理。

(3) uiWebView:resource:willSendRequest:redirectResponse:fromDataSource: でなら画像やCSSも含めて呼び出されているっぽいからいけるんじゃない？

概ねこれで保存対象がわかるようではあるが、一部のリソースは呼ばれない模様。NSURLCacheのcachedResponse:forRequest: をチェックしているとwillSendRequestに飛んで来てないURLがcachedResponse:forRequest: されていたりしている。
キャッシュしているリソースであればrequestのURLをfile://に書き換えたいが、それをすると落ちる。特にGoogleのトップページとか。
2が回避不能なのでこれだけでは解決できず。

(4) NSURLCacheでどうよ？

キャッシュを返しても落ちない！キャッシュを返すのはこれでイケる。
UIWebViewWebViewDelegateよりも呼ばれる数が多いので、こちらが呼ばれたものが本当に通信しにいっているリソースだと思われる。なので、これで保存対象がわかる。
storeCachedResponse:forRequest: はredirectされていても呼ばれてしまう模様。NSCachedURLResponseだけではredirectされたものかどうかの判断ができそうにないので、保存は無理。

という流れ。
結論としては、(4)でなんとかなりそう。
ただしstoreCachedResponse:forRequest: はredirectの絡みで使えないため、

cachedResponse:forRequest: で保存対象を特定
自力で保存
自力保存したリソースが要求されたらそれをcachedResponse:forRequest: で返す

という実装になりそうである。なかなか大変。

クラウドとセキュリティ

Wed, 16 Feb 2011 12:00:06 +0900

クラウドで構築するシステムを進めている中で、サービス毎の差異やセキュリティ対策の状況を調べていました。主に検討しているのはGoogle AppEngine, Amazon EC2, あとは国内ものとしてニフティクラウド。PaaSとIaaSが混じってるのはご愛嬌。

個人的には、クラウドは最終的にPaaS化していくだろうと考えていますが、現段階ではGAEはなにかと融通が効かないというか、Webアプリ or サービスを公開する以外には適用できそうにないので、本命はEC2。

コスト、使えるサービスと自由度、可用性などについては特に問題ないと思うのですが、課題になっているのはセキュリティ。自分的には、Amazonがセキュリティ施策でなにをしているのかを読むと充分だと思うのですが、これをクライアントに納得してもらうのが難しい。第三者機関からなにかの認定を受けているとかしていてくれれば安心材料になるのですが、SAS70くらいしかないですし、これってセキュリティの認定じゃないし。

そもそもクライアントには「自分の資産(データ)がどこにあるのかはっきりしないし、データが他人の管理下に置かれるわけだし、しかも他の企業と相乗りサービス」という漠然とした不安が根底にあるので、なおさら根拠を求められるわけです。

私としては、

物理的に完全に分離されていないとしても、暗号化した上で分散して保存されていれば、第三者が不正アクセスでデータを完全な形で引き抜くことはできないでしょうし、複数のデータセンターに冗長化して保存されている時点で物理的なデータ保管場所にはさほど意味がないと思ってます。
運用会社内部からの不正アクセスはホスティングだろうとクラウドだろうと付きまとう問題なので、クラウドという環境の特性ではないと思ってます。
物理環境としては、他の企業と空間をshareするデータセンターよりも、物理環境に立ち入るのはサービス提供業者だけに限定されているクラウドのほうが入退室管理も厳密にできると思うので、ちょっと前までよくやっていた、自社でサーバを購入してどこかのデータセンターにハウジングしてもらうより、よっぽどセキュアだと思ってます。
電子的セキュリティも重要ですが、ソーシャルエンジニアリングのほうがよっぽど怖いので、システム化範囲を削って電話対応等を増やすほうが危ないと思ってます。

自分ではこのように思うのですが、絶対的な保証や安全などは当然ないわけです。明確な課題を検討するのと違い、不安を払拭するのは難しいものですね。

ちなみにAmazon Web Serviceのセキュリティについてはこちら。
http://aws.amazon.com/jp/security/

バッチ処理の高速化

Tue, 15 Feb 2011 21:58:00 +0900

5年程前に書かれた、他社が作成したシステムのバッチ処理があまりに不安定かつ低速だということなので、改善プロジェクトを実施しています。

懸案課題が解消すること
パフォーマンスが改善されること
現在保守している会社が保守していけること
保守性が向上すること

となかなかハードルが高い案件です。なんといっても、このシステムは資料もなく、ソースも滅茶苦茶で可読性が悪く、コメントの要領を得なくて大変なのです。

まだ進行中ですが、

長らく不思議現象だった懸案課題も改善できたようですし、
保守会社に新しい設計を理解してもらえたようですし、
新しい設計では現行システムの20倍速くらいにパフォーマンス改善されたようですし、
いままで明文化されていなかった要件やフローが資料化できるネタが洗いだせたようですし、

ほぼハードルをクリアできそうです。ひと月でここまでできればなかなかいい感じ。特に、設計／実装のコンセプトを保守会社の方々に伝えて彼らにやってもらう、という方法を採りながら目標達成できそうなのが素晴らしい。

自分で設計／実装してしまえば割と簡単なのですが、今回は今後の保守の兼ね合いから、保守会社の方々に設計を理解してもらう必要があります。設計／実装に彼らが深く関わることで、彼らに「自分のシステム」という認識をもってもらうことがとても重要だと考えているからです。

そうは言いつつ、アドバイザーに徹するだけで到達可能だと考えていたレベルに到達できるかどうか不安でした。でもなんとかなりそうです。こういう関わり方でもきちんと実績を残せると、自分も新しいプロジェクトの関わり方ができそうです。