検索

• [ Prev ]
• [ Next ]
• [ C言語系 ]

Objective-Cの勉強を始めようと思って、適当にネットで漁ったHelloWorldをgccでコンパイルしたら上手く動かない。
で、調べ始めたらObjective-C/NeXT/OpenStep/MacOSXの歴史とかUniversalBinaryとかにまで広がってしまいましたが、ようやく収拾がついたのでまとめます。

環境：

Mac OS X (Lion), 10.7.2
Intel Core i5
64 ビットカーネルと拡張機能：有効
Xcode 4.2

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 ¥
(Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

• [ Prev ]
• [ Next ]
• [ JavaScript ]

JavaScript/オブジェクトリテラルのプロパティリストの末尾要素の","についての記事を書き終わった後、ふと配列リテラルの場合が気になったので調べてみました。

ECMA262, 11.1.4 Array Initialiser より :

ArrayLiteral :
    [ Elision(opt) ]
    [ ElementList ]
    [ ElementList , Elision(opt) ]
ElementList :
    Elision(opt) AssignmentExpression
    ElementList , Elision(opt) AssignmentExpression
Elision :
    ,
    Elision ,

これを見る限りは末尾の","は許容されているようです。そこで、簡単なJavaScriptで調べてみました。

var a = [,];
for (var i = 0; i < a.length; i++) {
    alert(a[i]);
}

試してみて驚きですが・・・

Firefox/Chrome

"undefined"が 1回 表示される。

IE8

"undefined"が2回表示される。

IE9

"undefined"が 1回 表示される。(new!)

どうもIE8の場合は "," を境に二つのundefinedがあるものと解釈されているようです。

var a = [,,,];

とすると、Firefox/Chrome/IE9なら3回undefinedがalertされ、IE8だと4回alertされます。

ちなみに本当に空っぽの場合は、Firefox/Chrome/IEともに0回でした。(lengthプロパティ == 0)

var a = [];

まとめると、配列リテラルの要素区切りの","については、末尾の","は文法上は許容されています。IEでもエラーになりません。ただし、","で終わるとIE8の場合は暗黙的にundefinedを補完しているらしいことが分かりました。従って、オブジェクトリテラルのプロパティリストの時と同様、安易に最後の","を残しておくと、IE8で動かした時にループの最後がおかしくなる場合があるかも知れません。

やはり配列リテラルの場合でも、末尾の","はきちんと削っておいた方が良いようです。

• [ Prev ]
• [ Next ]
• [ Up ]
• [ JavaScript ]

中華の炒め物セットで、袋に書いてあるレシピ通りだと少し分量が物足りない時、厚揚げが便利。
多少乱暴にいじっても崩れたりしない。味も、濃い目・薄目両方共相性が良い。
中華だけじゃなく、イタリアンとも相性が良いのではなかろうか。
すでに油で揚げてあるので、炒め合わせるときに追加の油が不要。
ご家庭のフライパンで日常的な炒め物を料理するときに、意外と便利でした。

今年は鯖の水煮の缶詰、厚揚げの使い方を開拓できた一年だった・・・。

2011年は震災を抜きにしても変化が激しい一年でした。

参考：日記/2010/12/31/2010年のまとめ

個人的に印象の深い出来事を挙げてみます。

1. 積まれていた技術書を全て消化完了
2. 震災で実家周辺液状化
3. セキュリティ診断会社に就職

1年半に及ぶニート生活により、「いつか読もう・・・」と心の重荷になっていた技術書を全て消化し終えました。結構「読み飛ばし」したのも混ざってますので、あんまり血肉になったとは言えないかも。

震災については実家周辺が液状化に見舞われまして、1ヶ月ほど実家で片付けなど手伝ったりしてました。

そして、ようやくニート脱出。運良く、Webアプリケーションの脆弱性検査サービスをメインとしている会社に就職できました。
これに伴い、実に2年振りにWeb開発の最前線に戻ることになり、同時にAndroid端末, iPad, MacBookAirの購入など環境が大きく変化しました。さらにSubversionからMercurialへのシフトも経験しました。
個別の記事リンクは載せませんが、いろいろ調べたなぁ・・・。

• OAuth, OAuth 2.0
• OpenSocial
• Android開発
• Subversion to Mercurial
• HTML5

就職した会社がGoogle Appsを使用していたこと、及びAndroidやMacBookAirを購入したことから、個人のメール環境についてもGoogleサービスへシフトしました。これまでのPOPアカウントについてはgmailから取得するようにしてgmailに一本しました。また、ダイビングの写真など一部のストレージをGoogle+やGoogleドキュメントに移行しました。
MacBookAirを使い始めたことにより、ID・パスワード管理を ID Manager からGnuPGを使った簡単なラッパースクリプトに変更したりもしました。

2012年も色々あるかと思います。それでは皆様よいお年を。

MonacaとPhoneGap触って見ました。使用OSはAndroid。

• Monaca - クラウドベースのネイティブアプリ開発環境
  • http://monaca.mobi/
• PhoneGap
  • http://phonegap.com/

で、ローカルファイルシステムはどうなってるんだろうかと。

基本的にW3CのFile APIを使うようになってるみたいです。
こんなのをHTML側の適当なボタンから呼び出して動作を確認してみます。

function showFSInfo(fs) {
    alert(fs.name + "\n" + fs.root.name + "\n" + fs.root.fullPath);
}

function fsdemo01persistent() {
    window.requestFileSystem(LocalFileSystem.PERSISTENT, 0, showFSInfo, null);
}

function fsdemo01temporary() {
    window.requestFileSystem(LocalFileSystem.TEMPORARY, 0, showFSInfo, null);
}

function fsdemo02write() {
    window.requestFileSystem(LocalFileSystem.PERSISTENT, 0, 
        function(fs){
            fs.root.getFile("foo.txt", {create: true}, 
                function(fileEntry) {
                    alert("fullpath=" + fileEntry.fullPath);
                    fileEntry.createWriter(
                        function(writer) {
                            writer.onwrite = function(evt) { alert("success"); }
                            writer.write("Hello");
                        },
                        function(fileError) { alert(fileError.code); }
                        );
                }, 
                function(fileError) { alert(fileError.code); }
                );
        }, 
        function(fileError) { alert(fileError.code); }
        );
}

function fsdemo03write_temp() {
    window.requestFileSystem(LocalFileSystem.TEMPORARY, 0, 
        function(fs){
            fs.root.getFile("bar.txt", {create: true}, 
                function(fileEntry) {
                    alert("fullpath=" + fileEntry.fullPath);
                    fileEntry.createWriter(
                        function(writer) {
                            writer.onwrite = function(evt) { alert("success"); }
                            writer.write("This is temporary file.");
                        },
                        function(fileError) { alert(fileError.code); }
                        );
                }, 
                function(fileError) { alert(fileError.code); }
                );
        }, 
        function(fileError) { alert(fileError.code); }
        );
}

アプリケーション名：myApp
パッケージ名：your.app.name
でデバッグ版でビルドします。

• LocalFileSystem.PERSISTENTで取得したrootは、"/mnt/sdcard"になってました。単にroot.nameだけだと"sdcard"が返されます。
• LocalFileSystem.TEMPORARYで取得したrootは、"/mnt/sdcard/Android/data/your.app.name/cache"になってました。単にroot.nameだけだと"cache"が返されます。
• foo.txtは"/mnt/sdcard/foo.txt"として無事"Hello"が書きこまれました。
• bar.txtは"/mnt/sdcard/Android/data/your.app.name/cache/bar.txt"として無事"This is..."が書きこまれました。
• 細かい使い方とか、PhoneGap側のDocumentだけじゃ足りなくて、W3Cのサイト見つつになるのが大変。
  • File API: Directories and System
    • http://www.w3.org/TR/file-system-api/

この辺、PhoneGapの仕様としてそうなっているのか、Monaca独自のカスタマイズでそうなっているのかは不明です。
ただ、sdcardに保存されるという点から、あんまり重要情報は保存したくないなぁという感じです。他のアプリからも読み書き出来てしまいますので・・・。

FileSystem以外の感想としては、

• jQueryとかjQuery Mobileの機能も使うので、調べ物が大変。とはいえ学習曲線での初期コストと考えれば、慣れの問題か。
• 外部のURLリンクを置いてみてクリックしたところ、Android標準ブラウザが起動した。独自のWebサイトをPhoneGap(Monaca)内のWebViewで表示するとかは出来るか謎。
• 外部との通信はXHRになるみたいだけど、SameOriginPolicyとかどう扱われるのか謎。
• PhoneGapの標準機能で物足りない場合は、Pluginという形でそれぞれのPlatformに応じたNativeコードを組み込んで拡張できるみたいです。Monacaが対応できるのかする予定はあるのかは不明。
  • http://wiki.phonegap.com/w/page/36752779/PhoneGap%20Plugins
• JavaScriptって『簡単』なのかなぁ・・・？
• console.log()とかが、自分のHTC S31HT (E-Mobile)では動作しないよぉ・・・。

他、参考サイト：

• jQuery Mobile
  • http://jquerymobile.com/
• Phonegap と Titaniumを比較してみた - kurainの壺
  • http://d.hatena.ne.jp/r_kurain/20101121/1290347346
• PhoneGapでAndroidアプリを作るための基礎知識（1/3） - ＠IT
  • http://www.atmarkit.co.jp/fsmart/articles/phonegap01/01.html
• 連載：PhoneGapで手軽にiPhone/Androidアプリを作ろう｜gihyo.jp … 技術評論社
  • http://gihyo.jp/dev/serial/01/phonegap

なんというか、N88-BASIC触ってるような感触を受けました。単純といえば単純なんだけど、アイデア次第で結構面白いの出来るんじゃないか、とか、プログラミングの入り口としても良さそうだな、とか。PhoneGapという制限範囲の中でどんな「捻り」を思いつくのかとか、そんな面白さがある気がします。

1. Mercurial側でEolExtension( http://mercurial.selenic.com/wiki/EolExtension )有効化。
2. もともとWindows側で作成したAndroidプロジェクトなので、native=CRLFでリポジトリルートに.hgeol作成
3. Mac側では .hgrc に eol + native = LF 指定。

これで、Mac側でリポジトリを取得したときに改行コードが全てLFになる。
→ADT Pluginの自動生成でR.javaなどが同じ内容で更新されても、改行コードもLFなので差分無し。

よっしゃ！

BurpもZAPも、WebSocket接続時のHTTPリクエストが、サーバから返ってこないのでタイムアウトして、ブラウザ側もタイムアウトになってしまって接続エラーになる。

Fiddler位かな。でも開発中みたいだし。

• Glimpse of the future: Fiddler and HTML5 WebSockets - Fiddler Web Debugger - Site Home - MSDN Blogs
  • http://blogs.msdn.com/b/fiddler/archive/2011/11/22/fiddler-and-websockets.aspx

CodeZineの次の記事で、「このContentProviderを持っているアプリケーションだけがアクセスできるように制限するには、android:exportedプロパティを明示的にfalseにします。」との記述がありますが、個人で調べた範囲ではAndroidのバージョンに依存しているようです。

• ContentProviderのアクセス範囲　――Dropboxにおける脆弱性の修正：CodeZine
  • http://codezine.jp/article/detail/6286

技術/Android/PermissionExamples にて、Activity/Receiver/Service/ContentProviderを幾つかの組み合わせで呼べる・呼べないを網羅的に調べた資料を公開していますが、ContentProviderでの実験では以下の現象が確認されています。

API Level 8 (Android 2.2)

android:exported="false"でも他のアプリ（署名も別）からアクセス可能。

API Level 10 (Android 2.3)

android:exported="false"で他のアプリからアクセス不可能（"java.lang.SecurityException: Permission Denial"発生）

タオソフトウェアの記事でも、同様の検証結果が公開されています。こちらでもAPI Level 8以前はNG、API Level 9以降で有効との結果になっています。

• Taosoftware: Android ContentProviderのexport指定が使えない
  • http://www.taosoftware.co.jp/blog/2011/10/android_contentproviderexport.html

端末メーカー側できちんと修正してリリースしている可能性もありますが、そこまでは調査しきれていません。

解決策としてはタオソフトウェアの記事でも紹介されていますが、signatureレベルのpermissionを使うことで、署名が異なる＝外部アプリからの呼び出しをブロック出来るようになります。

一点気になるのが、記事中でのDropboxの修正内容で、exported="false"にしているだけです。これはAPI Level 8以前ではナンセンスです。もしかしたらメジャーな実機端末では2.2以前でも修正されていて問題ないのかもしれません。或いはgrant-uri-permissionを指定しているようなのでそれが影響しているのかもしれません。

一応宣伝ですが、技術/Android/PermissionExamples で公開している実験結果の追加検証(API Levelや実機など)を手伝っていただける方募集です。gmailを教えて頂ければ、編集レベルで共有します。実験に使ったアプリのソースもbitbucketでMercurialにて公開してますので、興味のある方は試してみてください。

お仕事で使ってるProxyツール、BurpSuiteのメモ。

・proxyのhistoryで選択→save itemすると文字化けする。
→optionsのloggingでのログは文字化けしない。ただしリアルタイムに書き込みしているわけではなく、数秒間ほど溜めてから書きだしたりしていて、バッファリングされている模様。
→というか、upstream proxyをOWASPのZAPにして、対象サイト以外をフィルタしてしまえば、ZAPなら文字化けせずにデータをごっそり保存・ロードできるので、そちらでロギングしておくという手法も有りか。メモリ食いそうだけど。

・ログイン画面からログインして～とか、CSRF対策用トークンを取得したり、前準備が必要になったりするケース
→最初にoptions→session→macroで、その直前までのリクエストの流れを組み立てておき、session handlingで"Run macro"で追加する。セッションのタイムアウトまで含めてチェックしたい場合は、セッションが維持できているか判定できるリクエストをmacroで組んでおき、"Check session is valid"として追加しておく。なお"Check session is valid"で"if session is valid, don't process any further rules or actions for this request"にチェックを入れておくと、セッションが有効なときに、他のRun macroとかで登録したアクションが実行されない。トークン取得の前段階としてセッション判定を入れたい場合は、このチェックを外しておかないと、セッションが有効な場合にトークン取得が動かないので失敗する。チェックを外せば、セッション有効ならそのままトークン取得が動くのでOK。
→この辺は実際にrepeaterとか使って動かしてみた後、"view session tracer"でルールの動作を確認したほうが良い。別のproxyをupstream proxyに設定して、そちらで全体のリクエストを確認するというのも有り。

・upstream proxyが思いの外便利。
→ブラウザ側でぐちゃぐちゃ切り替えずにBurpから素通しで他のProxyへリレー、みたいなことが簡単に出来るので。

ICSのソース全体がrepo syncでget出来たので、 日記/2011/10/23/Android4.0(IceCreamSandwich)の画面キャプチャ機能 で気になってた実際のソースを探検してみました。

といっても、かなり主観と偏見に基づいて、ざっくりとした流れだけを追ってます。もしかしたら漏れがあるかもしれないし、権限周りなどセキュリティ的な視点は後回しにしてます。

先に三行でまとめ：

1. /system/bin/screenshot (前回失敗) → /dev/graphics/fb0 から手動で読み込んでるのが原因か。
2. /system/bin/screencap (前回成功) → ScreenshotClientクラスのupdate()が成功すれば、getPixels()で読み出している。update()が失敗なら /dev/graphics/fb0 から手動で読み込み。
3. サービスとして：TakeScreenshotService → GlobalScreenshot ： GlobalScreenshotをServiceとしてラップしているのがTaskScreenshotService。GlobalScreenshotの中でスクリーンショットを取得するときのアニメーション処理などを処理しているっぽいので、多分VolDown + Powerでのスクリーンショット取得で動作するのはこのコードで合ってるはず。最終的にはscreencapコマンドと同様、ScreenshotClientクラスのupdate()→OpenGLのglReadPixels()でスクリーンショットを取得している。