検索キーワード「���������������」に一致する投稿を関連性の高い順に表示しています。 日付順 すべての投稿を表示
検索キーワード「���������������」に一致する投稿を関連性の高い順に表示しています。 日付順 すべての投稿を表示

2011年5月3日火曜日

Xcode のビルド設定で $(inherited) を使って設定を継承する



AppleのXcode 2のころのドキュメントによるとXcodeのビルド設定は以下の順に設定内容が解決されていきます。
  1. ユーザーのデフォルトの環境変数設定(たいていは ~/.MacOSX/environment.plist で指定されている)
  2. Xcodeのビルトインデフォルト設定
  3. Xcodeのアプリケーション設定(これはXcode 4では廃止されている気がします)
  4. ベースとなるビルド設定ファイル(元のドキュメントには書いてありませんが、.xcconfigファイルを使ってビルド設定を指定可能です)
  5. プロジェクトのビルド設定
  6. ターゲットのビルド設定
  7. コマンドラインから起動した場合は、コマンドラインのビルド設定フラグの値
このとき、下位の設定は上位の設定を上書きして使用するようになっているのですが、ここで上位の設定をそのまま受け継いで使いたい場合には、設定項目に$(inherited)という特殊な値を指定することが可能です。

2010年9月12日日曜日

iPhone 開発規約まとめ

あんまり iOS 上での開発規約とか見かけないので、試しに私が今個人/会社で使っている開発規約を公開してみることにしました。


■設計

設計は所謂 MVC と呼ばれる設計モデルを採用します。ただし、厳密な MVC というわけではなく、以下のような区分になっています。
  • Model
    Core Data を使用します。通常 MVC での Model というと業務ロジック等を含めた業務モデル一般すべてを含むのですが、私の場合は特に Core Data の NSManagedObject を Model として扱い、 Model 単体のみで完結するロジックのみを Model に記述します。たとえば、
    • Core Data から対象の Model とその関連 Model 取得
    • Model の新規作成
    • 新規作成時、更新時に自動的に Model のプロパティを更新する
    • Model のプロパティの値を元に幾何学計算をしたり、一時的に使うキャッシュを用意したりする
    などです。実際のコードのサンプル (ニュースサイトのニュースを表す News モデルの実装) はこんな感じになります:
    #import "News.h"

    @implementation News

    @dynamic body;
    @dynamic title;
    @dynamic imageURL;
    @dynamic objectId;
    @dynamic dateCreated;
    @dynamic dateUpdated;
    @dynamic sortOrder;

    @end

    //----------------------------------------------------------------------------------------
    // ここから上は .xcdatamodel ファイルから自動生成されたコードなので触れないようにします。
    //----------------------------------------------------------------------------------------

    #import "AppDelegate.h"

    @implementation News (NSManagedObject)
    - (void)awakeFromInsert {
    [super awakeFromInsert];
    // Insert
    self.dateCreated = [NSDate date];
    }
    - (void)willSave {
    [super willSave];
    // Update
    // DO NOT DO THIS in here because updating self.dateUpdated will call -willSave method recursively until this application crashes!
    // Use NSManagedObjectContextWillSaveNotification / NSManagedObjectContextObjectsDidChangeNotification and watch the time delta of previous change
    // If the time delta is small enough to ignore, do not update dateUpdated property to avoid infinite loop
    //self.dateUpdated = [NSDate date];
    }
    - (void)awakeFromFetch {
    [super awakeFromFetch];
    // Select
    }
    @end

    @implementation News (DBAccessors)
    + (NSArray *)all {
    AppDelegate *appDelegate = [AppDelegate appDelegate];
    NSFetchRequest *request = [appDelegate.managedObjectModel fetchRequestTemplateForName:@"allNews"];

    // Sort by sortOrder, ASC
    NSArray *sortDescriptors = [NSArray arrayWithObjects:
    [[[NSSortDescriptor alloc] initWithKey:@"sortOrder" ascending:YES] autorelease],
    nil];
    [request setSortDescriptors:sortDescriptors];

    NSError *error = nil;
    NSArray *resultArray = nil;
    if (!(resultArray = [appDelegate.managedObjectContext executeFetchRequest:request error:&error])) {
    // handle the error;
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
    return nil;
    }
    return resultArray;
    }
    + (id)get:(NSString *)targetId {
    AppDelegate *appDelegate = [AppDelegate appDelegate];
    NSDictionary *substitutionVariables = [NSDictionary dictionaryWithObject:targetId
    forKey:@"objectId"];
    NSFetchRequest *request = [appDelegate.managedObjectModel fetchRequestFromTemplateWithName:@"getNews"
    substitutionVariables:substitutionVariables];

    NSError *error = nil;
    NSArray *resultArray = nil;
    if (!(resultArray = [appDelegate.managedObjectContext executeFetchRequest:request error:&error])) {
    // handle the error;
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
    return nil;
    }
    return [resultArray lastObject];
    }
    + (void)deleteAll {
    AppDelegate *appDelegate = [AppDelegate appDelegate];
    NSFetchRequest *request = [appDelegate.managedObjectModel fetchRequestTemplateForName:@"allNews"];

    NSError *error = nil;
    NSArray *resultArray = nil;
    if (!(resultArray = [appDelegate.managedObjectContext executeFetchRequest:request error:&error])) {
    // handle the error;
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
    return;
    }

    // Delete all objects fetched
    for (NSManagedObject *obj in resultArray) {
    [appDelegate.managedObjectContext deleteObject:obj];
    }
    }
    @end
  • Operation
    本来の MVC モデルには存在しませんが、私は特別に Operation という区分をもうけています。定義は以下の通り。
    • 一つの業務モデル、業務ロジックを完結させるひとまとまりのロジックであること。要するに本来の MVC モデルの業務ロジック的要素であること。 もっと言うなら Operation だけを切り出して単体テストできること。
    • それなりに重要でかつ量があり、 Controller や Model から共有的に呼びだされること。
    • 非同期で処理ができること。
    • NSOperation クラスのサブクラスにすること。
    たとえばインターネット経由で API を実行して結果を Model に突っ込む処理などは Operation として実装しています。 NSOperation として実装することで、非同期処理が簡単にできるようになるだけではなく、 タスクの依存関係を決めて先に親タスクが実行されるのを待つようにしたり、現在の状態を厳密に判定したり、タスクをキャンセルしたりするのが容易になります。また、将来的に iPhone / iPad のCPUがマルチコアになった場合、 NSOperation を継承しておけばほとんど何もしなくてもその恩恵を受けることができるはずです。
  • View
    ビューです。主に UIKit および Three20 を用いて構築し、必要に応じてその他のビューライブラリを組み込みます。個人的には UIView のサブクラス一般をすべて View として扱っています。 View には描画ロジックと幾何学計算などの補助ロジック、およびそれに必要な最小限のデータのみを持たせるようにします。状態を持ってもかまいませんが、状態のコントロールを View 自身が行うのはできる限り避けます。タッチイベントのハンドリングは必要に応じて View で touchesBegin: などを実装して行いますが、基本的には Controller 側で UIGestureRecognizer を用いて行います。
  • Controller
    コントローラーです。私の中での定義は UIViewController のサブクラスです。アプリの内容に応じて UIKit と Three20 を使い分けます。 本来 Controller は全体の流れのみを管理し実際の処理を行ってはならないということになっていますが、 UIViewController の性質を鑑みて、私は次のように Controller の役割を定義しています。
    • View の管理。
    • 画面遷移, 要するに Controller 間の遷移の管理。
    • タッチイベント、ジェスチャイベント、加速度計などからの入力の受付と処理。
    • 各種 UI コンポーネントの Delegate 処理。 UITextView, UIPopoverController, UIActionSheet, などなどなど多岐にわたります。
    • Operation 完了時の処理など、各種 Notification を受け付けて処理。
    • 上記に必要になるデータ/メソッドの定義。 View に持たせるぐらいならこちらに持たせる。他に持たせるところがないなら Controller にすべて持たせる。
    ということで、 Controller を名乗っていますが実際にはかなり自分で処理をします。こんなのいちいち分けていたら大変ですし・・・といういいわけです。実際のコードサンプルはお見せできないのですが、実装の概要はこんな感じです



  • Application Delegate
    これも本来の MVC モデルには存在せず、本来は Controller として扱うべき物だと思いますが、私は特別に分けています。 Application Delegate は所謂アプリケーショングローバルなデータや設定、オブジェクト、ユーティリティメソッドを管理するものとして扱います。たとえば、
    • Operation 駆動用の NSOperationQueue
    • Model のための NSManagedObjectContext / NSManagedObjectModel / NSPersistentCoordinator
    • 現在通信可能か否かを判定するためのユーティリティメソッド
    • アプリケーショングローバルな Notification を受け取って Application Delegate のプロパティとしてセットする
    などです。これらはほぼすべてのアプリで絶対に必要になるのでテンプレ化しています。


■Xcodeプロジェクト

プロジェクトのグループはこんな感じで分けます。



ビルド設定については、プロジェクト全体のビルド設定は可能な限り使わないようにして、ターゲットごとのビルド設定 ( Cmd+Option+E ) を主に使います。ターゲットが例え複数に分かれても常に同じ物を使うところはプロジェクト全体の設定を変更します。


■命名規則

大体以下のような方針でやっています。
  • Foundation や UIKit など Apple の使っている命名規則に似せること。似てないシグネチャは即リファクタリング対象。
  • ミススペル、Typo、意味のわからない英単語 ( registとか ) は一文字一単語であろうとも発見した瞬間即リファクタリング対象。英語辞書のソースは http://www.alc.co.jp/ とする。
  • 名前はどれだけ長くなろうとも絶対に省略しないこと。 updUniqUsr とか発見したら即リファクタリング対象。逆に BPSuperDuperViewControllerDidFinishedUberTaskNotification とかは表彰モノ。
    • これを BPSDVCDFUTN とか略した奴が現れたら即 SATSUGAI モノです


■まとめ

ここまで書いておいて何ですが、要するに 一貫した基準があるなら 自分らの好きなようにするのが一番いい のかなと思います。

2009年6月4日木曜日

Firefox 3.5を導入してみた


いろんなところで話題になっている(http://d.hatena.ne.jp/chroju/20090523/1243076800)Firefox激重問題ですが、我が家でもニコニコ動画を見ることができないぐらい重くなっていたので、思い切って3.5b4を導入してみました。ちなみに、Mac OS X 10.5.7で試しております。


■利用したバックアップ用アドオン一覧など
Mozilla Re-Mix: インストールしているFirefoxアドオンをWeb上に保存してリストアできるアドオン「BELOW」
http://mozilla-remix.seesaa.net/article/109386090.html
Mozilla Re-Mix: Greasemonkeyスクリプトの利用環境をもっと便利にするFirefoxアドオン「Wescript」
http://mozilla-remix.seesaa.net/article/119556026.html
Mozilla Re-Mix: 拡張機能の「個別設定」をインポート・エクスポートできるFirefoxアドオン「OPIE」
http://mozilla-remix.seesaa.net/article/90165156.html
Mozilla Re-Mix: Firefox3 Beta版に対応していないアドオンを強引にインストールする方法。
http://mozilla-remix.seesaa.net/article/84338863.html


■インストール手順
1.AppCleaner(http://www.freemacsoft.net/AppCleaner/)を使ってFirefoxを完全に削除
  Windowsより消すのがラクチンです。

2.公式サイトから最新のbeta版をダウンロードしてきてインストール
  コピーするだけ。これも非常にラクチンです。

3.アドオンの復旧、まずはXmarks (http://www.xmarks.com/) をインストール
  ブックマークを最初に復旧します。

4.about:configを書き換えて強制的に古いアドオンをインストールできるようにする

5.ブックマークから、上記のバックアップ用アドオンを探してきてインストール

6.BELOWを実行

7.OPIEを実行

8.FireGesturesの設定が正しく復旧されていないので、手で復旧

9.Tab Mix Plusの設定が正しく復旧されていないので、手で復旧

10.Tab Mix Plusがバグっていることが判明したので、開発版 (http://tmp.garyr.net/dev-builds/) をインストール
   具体的には最後に閉じたタブが開けませんでした。
   Tab Mix Plusは大体バージョンあげるたびに問題が出るので、このサイトを覚えておくと便利。

11.Firefox自体の設定を調整

12.Wescriptを実行

13.自作のGreasemonkeyスクリプトをインストール


以上です。作業時間は40分程度でした。BELOWとOPIEは極めて便利なので本当にお勧めです。


■で、何が変わったか
正直、見た目はFirefox 3.0と全く変わりがありません。見た目で変化がわかるのはロケーションバーぐらいでしょうか。



動作はというと、まず例のニコニコ動画がガクガクして全く見られない問題は解消しました。動画を見ているときのCPU使用率も、前は2コアとも40〜50%程度消費していたところ、16〜20%程度まで低減しています。どうやら中身はしっかり改良されているみたいです。

いちばん大きな変化はリリースノート(https://developer.mozilla.org/Ja/Firefox_3.5_for_developers)を見ても分かるとおり、HTML5サポートだと思います。videoタグやaudioタグを利用できるようになったそうです。

早速試してみました。
http://www.youtube.com/html5


・・・動かないじゃないか!!><
(ちなみにSafari 4 betaでは動きます)

おそらく使われているビデオの形式がmpeg4なのが原因だとは思いますが・・・
変な青い枠が出ているのも、おそらくGoogleの中の人がChrome (Webkit)でしかテストしていないからでしょうし。
しかし、うーん、まだまだ開発版って感じがします。


■気になるアドオンの動作状況
微妙にTab Mix PlusがBuggyです。閉じたタブの履歴を正しく保存してくれていない感じがします。その他AdblockやFirebugなど、メジャーどころはほとんどすべて入れていますが、まだ1日も使っていないので何とも言えません。

2012年9月26日水曜日

Unity の PostprocessBuildPlayer を使って Weak Framework を追加する方法

※2013/11/27追記: 第二版を公開しました。

UnityでiOSのアプリを作っていて困ることの一つに、iOSが提供するシステムフレームワークへのリンクをプロジェクトに追加するのが超面倒くさいという問題が挙げられます。UnityがiOSアプリを書きだした後、手動でXcode上からシステムフレームワークを追加してもいいのですが、これはとんでもなく面倒です。

そこでUnityジャパンの伊藤さんという方が PostprocessBuildPlayer という仕組みと Ruby の xcodeproj ライブラリを使ってビルド時に自動的にシステムフレームワークを追加する仕組みを公表してくださいました。お陰様で随分とはかどっていたのですが、その方法では実はシステムフレームワークをWeakリンク(Optionalリンク)することができなかったのです。これでは例えばSocial.frameworkを使うアプリをビルドしてiOS5で動かすと起動時に問答無用でクラッシュしてしまいます。困りました。iOS6/5両対応ができないと話になりません。

というわけで作りました。システムフレームワークをWeakリンクできるPostprocessBuildPlayerを。こちらです。


ライセンスはMITライセンスにしておきました。
使い方は大体見ればわかるかと思いますが、まず最初にgem経由でxcodeprojをインストールしておくこと。
sudo gem install xcodeproj
あとは上記のPostprocessBuildPlayerをUnityプロジェクトの /Assets/Editor 以下に配置して、コード中のフレームワーク名を指定している箇所をご自身のお好きなように変更してやればオッケーです。

2011年3月17日木曜日

Xcode 4 で昔の Three20 フレームワークを使っているプロジェクトをビルドする方法

主に自分用のメモ。
Xcode 3 時代に作った Three20 フレームワークを使っているプロジェクトが動かない場合の対処法です。


動かない原因は簡単で、Xcode 4からはビルドした生成物が用意される場所が、各プロジェクトのbuildディレクトリ以下から、
~/Library/Developer/Xcode/DerivedData/プロジェクト名/Build/Products
以下に移動しているからです。なので、たいていの場合ヘッダ検索パスが間違っているので動かなくなります。

対処法はThree20公式ブログに載っているので転載します。
http://three20.info/article/2011-03-10-Xcode4-Support

以下のようにヘッダ検索パスを追記すると良いようです。
"$(BUILT_PRODUCTS_DIR)/../three20"
"$(BUILT_PRODUCTS_DIR)/../../three20"


2011/04/03追記: はじめに載せていた対処法は間違いでしたorz 大変申し訳ありません!
以下、はじめに掲載していた間違っている対処法です。この方法では通常のビルドはうまくいきますが、アーカイブ時のビルドに失敗します!どうもアーカイブ時と通常のビルド時でもビルド先のディレクトリが指し示す先が異なるようです、

対処法は、以下のようにヘッダ検索パスを書き直します。
$SYMROOT/three20


$SYMROOTという環境変数がキモです。



こいつはドキュメントには書いてませんが、Xcode 4のビルド設定ですと、
~/Library/Developer/Xcode/DerivedData/プロジェクト名/Build/Products
に対応するパスを返してくれるようです。

2011/04/03追記: 上にも書きましたが、アーカイブ時には上記に対応するパスではなく、異なるパスが使われます。そのためこの方法ではうまくいきません。Three20.infoに掲載されている方法を使うのが一番良いようです。

2009年6月7日日曜日

java-ja #15 TDDとかペアプロとか

株式会社ドワンゴの本社にて開催された、java-jaの第15回勉強会に参加してまいりました。(ドワンゴさんありがとうございます!噂通りの社風が垣間見られておもしろかったです)
今回のテーマはTDDとペアプロ。TDDの権威である@t-wadaさん(http://twitter.com/t_wada)の講義+実際にTDD&ペアプロを体験する時間が設けられ、非常に充実した時間が過ごせました。

以下、Twitterにアップした感想を転載。


とにかく疲れる!そして慣れていないせいもあるがコードが進まない!普段の倍疲労して半分しかコードが進まないなら、明らかに生産性が下がっているように見える。でも違う、逆だ。こんなに生産的にコードが書けるとは思わなかった!

TDDを進めていくうちに、自分が意図しない考えや見落とし、typoなどの指摘が次々に飛び出した。書き上がったテストコードも普段自分が作っているものより綿密だ(もっとも普段はかなり手抜きなのだが)。TDDに反する進め方を指摘してストップすることもできた。

TDD自体はというと、テストケースが増えたり仕様が複雑化してきたりすると、途端に難易度が跳ね上がるな。一箇所直すと複数のテストがあっという間に真っ赤になる!新しくテストを作る判断とかも難しい、なによりテストを実行するのが面倒になったりする。jUnitMaxが素晴らしい理由を体感。

ペアプロの弱点は調べ物だな。明らかに調べ物をするときは個々人がググったほうが早い。だから熟練度が高くないとオーバーヘッドが大きくなってかえって非効率的。@yuruyoroさんには足引っ張って申し訳ない。スキルの差を埋める必要があるのも課題かなー、、、

個人的には一人でやる方が楽かな。人と話すのがへたくそ何だよなあ、、、いつもより疲れるのもそれが原因かも。ウォーターフォールがいけてないとはよく言うが、TDDやペアプロ自体にもたくさん課題があるのだなー、、、でも同じ課題満載なら、新しいやり方を開拓する方がいいよね、多分


TDDやペアプロは良いプラクティスですが、慣れないと実践は難しいですし、ウォーターフォールに代わる銀の弾丸でもなさそうです。そのことを実際に体で覚えることができたのが一番の収穫かな!

2011年5月5日木曜日

atos を使ってアプリのクラッシュログを symbolicate する方法

iOSアプリがクラッシュするとクラッシュログがデバイスに残され、 Xcode のオーガナイザーからログを取得してバグの原因を解析できるのは皆さんご存知の通りだと思います。このとき、基本的には Xcode がクラッシュログがの中のシンボルを自動的に読める状態にしてくれる (symbolicate) のですが、どうも Xcode 4 になってからこの symbolicate がいまいちよく動いてくれないので、手動で symbolicate をする方法を調べてみました。

参考にしたページは以下の通り。
http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports


■atosの使い方

symbolicate をするには Xcode に付属している atos というコマンドラインツールと、ビルドの際に生成される dSYM と呼ばれるファイルを使います。

まずは dSYM ファイルを探します。 Xcode 4 の場合は、デフォルトで *~/Library/Developer/Xcode/DerivedData/プロジェクト名-ランダムな文字列/Build/Products/ビルド設定名/アプリ名.app.dSYM* に生成されるようになっているはずです。

dSYM ファイルが見つかったら、コンソールから atos を実行します。 atos の使い方は以下のとおりです。
atos -arch アプリがクラッシュしたデバイスのアーキテクチャ -o アプリ名.app.dSYM/Contents/Resources/DWARF/アプリ名 クラッシュした関数またはメソッドのアドレス
実際にやってみるとこんな感じです。
cd ~/Library/Developer/Xcode/DerivedData/MyProject-xxxxxxxxxxxxxxxxxxxxxxxxxxxx/Build/Products/Debug-iphoneos/
atos -arch armv7 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp 0x00072ce6
これで指定されたアドレスが symbolicate され、シンボル名および元のソースコード上の行数まで表示してくれます。超便利です。


■注意点

何回か試してみましたが、ときどき実際にクラッシュしたシンボルと違うシンボルが表示されることがあるみたいです。上記で紹介したやり方が間違っているのか、それともそういうものなのかわからないのですが・・・すんません>< しかしその場合でもだいたい表示されたシンボルの近くが問題の原因だったため、いまのところ参考ぐらいには使えています。

2012年5月5日土曜日

自作の Unity Editor Script を github に公開してみた



最近は仕事の関係でUnityばっかり触っているのですが、中でも今お気に入りなのがEditor拡張機能です。これは自分で簡単なスクリプトを書くだけでUnityのエディタ上の表示を自由にカスタマイズできる機能なのですが、コイツの出来がなかなか素晴らしいのです。これまでいろんな開発環境を触ってきたのですが、ここまで簡単にエディタ上の表示を自在にカスタマイズできる環境は他に類がありません。

ということで調子に乗って自作のEditor拡張機能を書いて公開してみることにしました。まずは簡単なものからということで、シーン上に配置できる定規を作りました。


■機能
  • 原点からの距離(u)、高低差(u)、対象位置地面の水平方向傾き(度)を測定可能 ※1u=Unity上での長さの単位1とします
  • イメージを見ての通り全数値がエディタ上に表示されるので一目でわかる
  • Raycast飛ばしてるので確実に地面位置を基準にして判定してくれる、Raycastが外れても空中の座標がきちんと出る隙を生じぬ二段構え
  • 画面上の色/フォントを自由にインスペクタから変更可能
  • すべてEditorScript/Gizmoなので万が一何かの間違いでリリース版のシーンに残っていてもMesh Rendererが走って画面に表示されるという悲しい思いをしない
  • 操作は原点を選択してAdd Pointボタンを押して出てきた点を任意の位置に移動して配置するだけ
  • Clear Pointボタン付き
ひと通り基本的なのは揃えてみました。


次は高低差メッシュをTerrainの上に表示する機能とか作ってみたいっすね。

2009年7月12日日曜日

EditControlとAccessoryViewの背景は透明



  • EditControlの背景はデフォルトで透明
  • AccessoryViewの背景もデフォルトで透明
  • UILabelの背景はデフォルトで白塗りつぶし(透明にはならない)

OS 2.2.1での実験結果なので、3.0では違うかも(たぶん同じ)

それだけです。お粗末様でした・・・

2016年11月17日木曜日

ビルドが遅いのをどうにかこうにかやりくりする方法

すでに皆様痛感されていると思いますが、Swiftはビルドがとんでもなく遅いです。正確に言うと、Swiftのビルドが遅いのに加え、clang moduleのビルドが遅いため、frameworkの数が増えてくるとビルドにかかる時間がどんどん破滅的なことになってきます。

Swift & dynamic framework導入前はアーカイブ込みで10分以下だったビルド時間が、現在は20分を超えてしまっており、更に今後もSwiftコードの増加ととframeworkの増加に従ってビルド時間が伸びることが予想されます。そこでなんとかしてこの時間を短縮しようと思って調べてみました。

そもそもビルド時間が伸びる原因


  • Swiftのビルドが遅い、特に型推論が遅い
  • frameworkのビルドが遅い
  • Xcode上でcleanを実行するとプロジェクト内でビルドしているのframeworkが全てビルドし直しになり分割ビルドの恩恵が得られない

それぞれ詳しく見ていきます。

Swiftのビルドが遅い、特に型推論が遅い

以下の記事が大変参考になります。
https://thatthinginswift.com/debug-long-compile-times-swift/
Swift 3.0になって随分と高速化したため、型推論のせいで異常に時間がかかるという自体は減りましたが、それでもObjective-Cのコードと比べると10倍以上時間がかかることが多々あります。型を明示すれば高速化に寄与できますが、そうするとSwiftのせっかくの旨味が減るため悩ましいところです。

frameworkのビルドが遅い

dynamic framework = clang moduleのビルドはコードのコンパイル以上の作業を多分に含むため、分割すれば分割するほどそのオーバーヘッドが増えて無駄に時間がかかることになります。

Xcode上でcleanを実行するとプロジェクト内でビルドしているのframeworkが全てビルドし直しになり分割ビルドの恩恵が得られない

個人的に最悪なのがこれだと思います・・・せめて特定のコードに対してのみcleanできれば良いのですが、Xcodeで各種トラブルを避けるためにはcleanは必須、しかしながらcleanを実行すると全てのframeworkがビルドし直しとなって分割ビルドの恩恵が得られません。

特にCocoaPodsを使っていると全てのpod管理下のframeworkが再ビルドとなるため大変効率が悪いです。

これらを踏まえて対処法を考えてみました。と言っても大したことは出来ないのですが、

  • 定期的にビルドタイムをチェックする環境を用意する
  • CocoaPodsをやめてcarthageを使用する
  • microframeworkをやめる、どうしてもmicroframeworkを行うのであればcarthageと併用する

ビルドタイムのチェック方法は https://thatthinginswift.com/debug-long-compile-times-swift/ に記載がありますが、Other Swift Flags-Xfrontend -debug-time-function-bodiesを追加してビルドし、ビルドレポートを見ればOKです。結果はpbpaste | egrep '\.[0-9]ms' | sort -t "." -k 1 -n | tail -10などで整形すると見やすくなります。100msを超えている関数があれば手を打つ必要があるかもしれません。

CocoaPodsですが、手元で全てのframeworkをビルドしようとするためcleanした際の無駄が多いです。carthageを使えば最初にビルドを一回行って後はそれを参照して使いまわすだけ、という風にできます。ただしcarthageは最初のビルドがやたら長く、CocoaPodsを使った場合より5倍以上遅い?と言う問題があるのでその点は注意が必要です。

microframeworkを辞める論についてはおそらくいちばん賛否両論議論があるところかと思いますが、少なくとも殆どの場合、開発中はコードを使いまわす回数と時間よりXcodeをcleanしてビルドし直す回数と時間のほうが支配的であると信じています。Xcodeがちゃんとしてさえいればベストプラクティスに従ったほうが良いのでしょうが、そのようなことは伝統的にないので、ベストプラクティスにこだわらずビルドを高速化するために一つのframeworkにまとめるのも悪くはないのではと思っています。
ただしcarthageと併用できるのであれば、一度ビルドしたmicroframeworkを使いまわすメリットが享受できるので良いかもしれません。その場合、microframework側はコードベースがある程度安定している必要があります。さもなければ何度も何度もcarthage updateを走らせ直して結局時間がかかることになります。

結論

いろいろ考えてみましたが、頑張ってビルド高速化するより、新しいビルドマシンを増設したほうが結果的に良いかと思います\(^o^)/

2016/12/01 追記

Qiitaにより詳細で素晴らしいまとめがあったのでそっちを見ておいたほうが良い気がします(´・_・`)

全体的に見て型キャストとかワンライナー(とそれを誘発する演算子等)による途中の型推論が劇的に遅い原因のようですね。まぁ来年ぐらいまでにはclangが賢くなって直ってるのではないでしょうか・・・多分・・・

2010年1月3日日曜日

Google Code Prettify のテスト

■Python(自動判別)
abesi='abesi'
hidebu=3
print abesi+hidebu
def tawaba(n=0):
result = 0
for i in range(n):
result = result + i
return result
きちんと自動判別してくれているみたいです

■Python(言語指定)
abesi='abesi'
hidebu=3
print abesi+hidebu
def tawaba(n=0):
result = 0
for i in range(n):
result = result + i
return result
lang-pyを指定してみました

■Objective-C(自動判別)
NSString *abesi = @"abesi";
int hidebu = 3;
NSLog(@"%@%d", abesi, hidebu);
@synthesize anProperty;
#pragma mark -
#pragma mark Functions
int tawaba(int n) {
int result = 0;
for (int i=0; i<n; i++) {
result += i;
}
return result;
}
こちらも判別に成功。

■JavaScript(自動判別)
var abesi = 'abesi';
var hidebu = 3;
console.log("%s%d", abesi, hidebu);
// 日本語コメントのテスト
/**
* 日本語コメントのテスト
*/
function tawaba(n) {
var result = 0;
for (var i=0; i<n; i++) {
result += i;
}
return result;
}
日本語コメントのテストなど。

いまいち配色が気に入りませんが、svnのtrunkに直リンクしていてこちらでは修正できないのでまぁ仕方ないかなと思います。それからActionScript3に未対応なのがかなり不満です。外部CSSとJavaScriptが増えて重くなるしonloadのタイミングで実行しなくちゃいけないし・・・Googleらしからぬイマイチさ。

2016年9月11日日曜日

iOSのフォントのお話

最近フォント周りについて深く掘り下げる機会がありましたので、その際のメモを残しておこうと思います。かなり読む人置いてけぼりな中身になってますが、フォントを詳しく触り始めるとなるほどーとためになる(と思う)のでどうかご了承ください(´・_・`)

UIFontのプロパティについて

UIFontにはフォントに関する数値を表すプロパティが存在します。いろいろありますが、もっとも重要なのは以下に列挙するプロパティです。

  • pointSize
  • lineHeight
  • ascender
  • descender
  • leading
  • capHeight

以下の画像を見ると非常にわかりやすいかと思います。


参照元: https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/CustomTextProcessing/CustomTextProcessing.html および http://stackoverflow.com/a/35922853

これを踏まえて各プロパティを解説すると以下のとおりになります。
  • pointSize
    • フォントのサイズを表します。
    • ほとんどすべてのケースでpointSize = ascender + descenderとなり、すなわちpointSizeは上端と下端に空白を含まない純粋なフォントの高さだけを表す数値であると言っても良いと思います。
      • 上下に空白を作らない高さでフォントを描画したい場合はこの高さを使うと良い、と言い切って間違いないと思います、ごく一部の変なフォント以外。
  • lineHeight
    • フォントの上部末端(上端空白が存在する場合はそれも)から下部末端(line gapも存在するなら含む)までの完全な高さを表します。
    • 飾り文字などではないまっとうなフォントであれば、必ずこのlineHeightの中に文字の高さが収まるようになっています。
      • 一部飾り文字のあるフォントについてはfont leadingを使って下部末端のline gapを表現していることがあります。
    • pointSizeとの最も大きな違いは、上端と下端にline gapに相当する空白を持っています。特にシステムフォントで顕著にそれが見られます。詳しくは後述。
    • 実際にフォントが画面上にレンダリングされるときはこのlineHeightがすべての基準になっているケースが多いです。
  • ascender
    • 全てのアルファベットの文字の最大高さを表します。
    • この高さまで描画されるのはごく一部の文字だけで、殆どの文字はcapHeightまでの高さしか使いません。詳細はこの後のcapHeightを参照してください。
  • descender
    • アルファベットのBaselineより下に描画される文字、例えばj p q yなどの下付き部分の高さを表します。
    • 日本語の文字でこの領域に描画される文字は私が知っている限りでは存在しません。
    • UIFontが返す値は常にマイナスになるので気をつけてください。
    • CTFontが返す値は常にプラスです。
      • めんどくさいので常にfabs()を通すといいと思います。
  • leading
    • Baselineからフォントの下部末端(line gapを含む)までの高さを表します。
    • 上記の図ですとline gapの部分だけがleadingとなっていますがヒラギノフォントで試した限りは誤りです。Baselineから下全てが対象になっているようです。
    • lineHeightに含まれている下部末端のline gapとは「全く別の値が付与されていることがあります」。
      • 例えば飾り文字のあるフォントについて、lineHeightよりもフォントの描画が大きくなるぐらい下に飾りが伸びていたとしても、leadingの値はそこまで考慮して付与してあるので、usesFontLeadingのオプションを付与すると下の行にはみでなくなる、みたいなケースが存在します。
  • capHeight
    • アルファベットの大文字の最大高さを表します。
    • 日本語の文字は(特に漢字は)基本的にすべてcapHeightの高さに描画されます。
    • capHeightより上に描画されるのは、例えばÅ(Aウムラウト)のように修飾子が付いているアルファベットや、日本語だと濁点および【】隅付き括弧のような一部の文字が、capHeightよりも上に描画されます。
特に覚えておきたいのがleadingというプロパティの働きです。UIKit, TextKit, Core TextにusesFontLeadingというような名前のオプションが存在するケースが多々ありますが(例えばNSAttributedString.boundingRect(with:options:context:)のoptionsとかですね)、これは何かというと、
usesFontLeadingが指定されている場合、lineHeightの計算の際に常にUIFont.leadingの値が使用される。従って、もしattributed stringにparagraph styleを付与してlineSpacingに0を付与していたとしても、フォントにleadingの値が付与されていたら、それ以上に行の高さが低くならず必ず行間が開いてしまう。
というオプションになります。paragraph styleでlineSpacingやparagraphSpacingを0に指定しているにもかかわらずどうしても行間がゼロにならないとか、指定するより広がってしまうみたいな状況になった場合は、このfont leadingを疑ってみてください。

ちなみにiOS 8以上については以下のとおりです。

  • UILabelは常にfont leadingを使用しません。
  • UITextFieldは未調査ですがおそらく常にfont leadingを使用しません。
  • UITextViewはデフォルトfont leadingを使用しますが、UITextView.layoutManager.usesFontLeadingの値をfalseにすることで回避可能です。
  • その他のラベルパーツ(UIButton.titleLabelなど)については完全には調査できていませんが、UIButton.titleLabelに関してのみいうとiOS 9の地点ではfont leadingが常に「使用されてしまいます」。これはおそらくiOS 6以前のUILabelの挙動がそのまま残っているためではないかと思われます。同じUILabelクラスですが中身と挙動がUILabelと異なるため気をつけてください。このようなケースは他にもあると思われます。

iOSビルトインフォントの問題点

幾つかのiOSビルトインフォントについては、先述のUIFontのプロパティの値に疑問がある数値が設定されているケースが有るようです。具体的にご紹介します。

1. ヒラギノフォントの場合

ヒラギノフォント、すなわちヒラギノ角ゴシックW3/W6、それからヒラギノ明朝W3/W6については以下の様なフォントの設定の特徴があります。
  • leadingの値がきちっと付与されています。
  • 常にpointSize == lineHeightになります。
  • おそらくバグだと思うのですが、descenderの値が本来必要な量の半分しか設定されていません。そのためヒラギノフォントを明示的に付与したラベルにg, j, y, qなどの下付き部分があるアルファベット文字を描画すると下が途中で千切れてしまいます。
    • 対処法としてはfont leadingを使用するか、または自力でdescender分だけラベルの高さを高くするか、明示的に指定してヒラギノフォントなんて使うのをやめてシステムフォントを使用してください。

2. システムフォントの場合

次にシステムフォントはどうなっているのかというと、以下の様な特徴があります。
  • 常にleadingの値がゼロになります。従ってfont leadingを使うモードで描画しても使わないモードで描画しても全く同じ結果になります。
    • iOS 8はHelvetica Neue, iOS 9以上はSan Franciscoが採用されていますが、いずれのケースでも全く同様の設定になっています。
  • pointSizeよりlineHeightが高く、ちょうどその差分の分だけ自動的にline gapとして行間が開くような設定になっています。
    • 要するに簡単にいえば、font leadingを使わないで、かつattributed stringでlineSpacingやparagraphSpacingをゼロに設定したとしても、必ず行間がちょっとだけ空いてしまいます。まずやることはないと思いますが、正確に行間ゼロを作るのは著しく困難です。

UIFontのpointSizeについて

UIFont.pointSizeについて、みなさん普段から何気なしに17とか14とか値を指定されているかと思いますが、このpointSizeに指定する値の単位って気にされていますでしょうか?このフォントのpointSizeとはPostScriptポイントないしDTPポイントと呼ばれるものらしいです。一般的に1PostScriptポイント=1/72インチとされています。

ではこの単位はiOS上で使われている論理座標系のpt単位とは全く違うものなのかというと、どうやら大昔のMacintoshのころからの名残で、macOS/iOS上の論理座標系の1pt=1PostScriptポイントとなるように定められていて、これは現在に至るまで常に維持されているということらしいです。

要するに、UIFontのpointSize=iOS上での1ptと完全に一致します。このことはlineHeightが16のフォントを画面上にレンダリングすると論理単位16pt(2倍Retinaなら32pxになる)ことからも確認ができます。便利ですね。


UIFont.leadingのiOS 8以下での不具合

かいつまんで言うと、UIFont.leadingの値は、iOS 8以下のときに常にUIFont.lineHeightと同じ値を返します。これは"font leading"という単語が使われている文脈や文化圏によって意味が異なり、font leading = line heightとなる文化圏があったので誤用されてしまった、ということらしいです。しかしながら実際のiOSでは先述の通り「font leading = BaselineからフォントのLine gapを含む下端までの距離」と定義されていますから、このような値では困ります。

対処法として、iOS 8以下の場合はCTFontを使ってleadingの値を取得してください。こちらにコードを用意しました。
https://gist.github.com/akisute/3c3d162da73abd784525c9ed7859cda2

なお、iOS 9以上はこの問題は発生しません。iOS 8なんてそろそろサポート切れるんで忘れていいかもしれませんが、念のため。

まとめ

デザイナーさんにフォント周りで行間調整がおかしいぞーとかベースラインがずれてるぞーとか突っ込まれまくっていて必死こいて修正方法を調べている時に、こんな記事を見つけました。

https://www.raizlabs.com/dev/2015/08/advanced-ios-typography/

Stop Saying "No" to Designers.
このサイトには英字フォントをBaselineではなくcapHeightの位置で上揃えにするべく奮闘した一人の漢の話が書かれています。おお、海外にも私と同じ境遇の漢が居たのです。

我々もデザイナーにNOと言わないタイポグラフィを実現させたいですね\(^o^)/

2008年11月22日土曜日

iPhone OS 2.2にアップグレードに失敗、ずいぶんと酷い目にあいました

  • iPhone OS 2.2へのアップグレード時に途中でエラーが出て中断、そのままインストールが再開できず
  • ケーブルを接続し直したり再起動したりHomeボタン押しっぱなしでセーフモード起動してもiTunesが認識せず
  • 結局Macbook Airにつないでみたら一発でリカバリモードで認識してくれたので助かった
  • ということでiPhoneで本当に困ったときはMacにつなげ、Windowsは信用ならない
  • いつのまにやらiPhone上のi.softbank.jpメールアドレスの設定が非常に簡単になっている(メアドとパスを入れるだけですべてやってくれる)

iPhone OS 2.2が事前予想通りにリリースされたので、さっそくアップデートを試みました。
が・・・途中で原因不明のエラーが出てアップグレードに失敗してしまいました。
そのままiTunesが何度やってもiPhoneを認識しないと言う事態に陥り、あわや愛しのiPhoneが6万円の格好いい板になりはてるかと気が気ではありませんでした。
結局Macにつないでみると無事認識してくれたので、そのままiTunesから復元を試みて無事復活。やれやれです。
基本設定が全部吹っ飛んでしまいましたが、アプリのデータなどはすべてWebサービス上にあるため全く無傷でした。おかげさまでiPhoneが無事立ち上がってからは1時間もかからずにすべてのデータを復元できました。クラウドコンピューティングの強力さを改めて実感です。


メールアカウントを設定し直す際に気づいたのですが、いつのまにかi.softbank.jpメールアドレスの設定が極めて簡単になっています。
以前は設定時にSSL通信を使わないようにしたり、IMAPとSMTPサーバー名を自分で設定する必要があったのですが、今日試してみたらメールアドレスとパスワードを入れるだけで全部自動でやってくれました。

それからiPhone 2.2といえばなんと言っても顔文字。コレで日本語キーボードがQWERTY、10キー、そして顔文字と3つになってしまいました。どれだけ日本語入力に力を入れてるんだって感じです。


メールの設定が楽になったり、顔文字が使えたりワンセグを見れるようにしたりと精力的に対応してくださって本当に助かるのですが、
それでもやっぱり、アップデートを行っただけで二度と起動しなくなってMacにつながない限り復元できなくなるようでは、とてもじゃないですが普通の人にiPhoneをお勧めは出来ないですね-。
だってこんなのが100万台も日本で売れたら、きっとソフトバンクモバイルのカスタマーサポートの中の人がストレスと過労でみんな死んでしまいますよ?

2011年8月5日金曜日

自分流 View Controllerの作り方 その1



その2はこちら

以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。




通信が絡んでくると、たいていの人がやりがちな問題(実例)
  • API通信のレスポンスを処理するコードがViewControllerの中に入っている
  • API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか
  • ABCのレスポンスJSONのパースまでViewControllerでやっている
  • というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする
API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる

それに対する対応策。そもそもなぜこのような問題が発生するのか?
  1. Outletの生成・更新・レイアウトが分離されていない
    • そのため複数回画面が更新されるタイミングが発生するととたんに破綻する
    • 大変よく見かける初心者コードが"drawXXX"という名前のOutletを生成してデータをセットしてframeまでセットして画面に配置するコード
    • Outletを描画コードと勘違いしている。Outletはペンやブラシに相当するものであって、実際に線を書くコードではない
    • この初心者コードでも動く唯一の理由は画面が一回(viewWillAppear時)しか更新されないから
  2. 通信という(比較的大きくなりがちな)ドメインロジックがViewControllerに混入している
そこで問題1.に対応するためにViewControllerの中でやる作業を以下のように分割する
  • Outletを生成する
    • preload(一度に生成する方法)
    • lazy load(必要になったら生成し、必要でなくなったら捨てる方法)
  • Outletのプロパティを更新する
  • Outletをレイアウトする
これらはそれぞれ(基本的に)以下のようなUIViewControllerのメソッドが対応する
  • loadView
    • Outletをpreloadする場合はコレで全く問題ない。このとき、self.viewとここで作られたOutletの生存期間は等しくなる
    • Outletをlazy loadする場合はOutletを生成するコードと削除するコードを用意しておいて、必要なタイミングで呼び出すとかする
  • なし
    • プロパティを更新するために、たとえばupdateOutletsみたいなメソッドを自分で用意してやる
  • 各種willRotate...系メソッド
    • willRotateほげほげの中にレイアウトコードを入れておくと自動的に画面の回転にも対応できて超便利
    • 自動的に必要なタイミングで適切に呼び出ししてくれて超便利
    • そういうのが嫌いな人はlayoutOutletsForInterfaceOrientation:みたいなメソッドでも作ればいいんじゃないでしょうか
次に問題2.に対応するためにAPIの呼び出しやファイルアクセスなどはService, Managerなどの層を作ってそちらに任せる
決してViewControllerの中にドメインロジックを混入させないのが大事
→混入するとドメインロジックとビューナビゲーションロジックが混ざって大爆発する
→さらにドメインロジック自身も複雑な通信が必要になると大爆発する

それとは別にイベントを受け取ってViewの状態を制御する大事なお仕事をする必要がある
  • ボタンタップしたり
  • 画面をタップしたりパンしたり
  • スクロールが発生したり
  • APIコールが完了したり
  • In App Purchaseが完了したり
ここまでがView Controllerのお仕事。決してドメインロジックを混ぜないのがポイント

2009年2月22日日曜日

Mac OS X LeopardでPYTHONPATHとPYTHONSTARTUPを設定してみました

  • 環境変数PYTHONPATHとは、Pythonがimportするときにモジュールを探しに行くパスのこと。JavaでいうところのCLASSPATHにあたる
  • 環境変数PYTHONSTARTUPとは、Pythonを対話モード(プロンプトモード)で実行した時に自動的に実行されるPythonスクリプトのこと。起動時に毎回読み込みたい設定とかを書いておくことができる
  • autoimpとPYTHONSTARTUPを組み合わせるとimportの手間から解放されて非常に便利

Pythonのモジュール名・関数名がわからないときや、ちょっとだけスクリプトを実験してみたいときなどPythonをコマンドラインから呼び出すことがよくあると思います。
ところが未設定のままのPython対話モードだと以下のような問題が生じます。
  • 毎回毎回使うimport osとかimport sysとかをいちいち手で実行するのが面倒くさい。自動でやりたい
  • 後からインストールしたライブラリ、特にGoogle App Engineのモジュールが利用できない
そこでこれらの問題を解決するべくPythonの環境設定を行ってみることにしました。
以下、すべてMac OS X 10.5.6と付属のPython 2.5.1 (Apple Build)で設定を行っています。python.orgからダウンロードしてきたPython 2.6や3.0の場合はファイルのあるパスが違ったりなどするかもしれません。


■PythonPathを通そう
PythonPathとは要するにJavaのクラスパスです。このパスが通っているところからPythonはモジュールをインポートしようとします。
現在のPythonPathを確認するためには、以下のPythonスクリプトを実行します。
>>> import sys
>>> sys.path

似たようなのにos.pathがありますが、アレは全く別物みたいです。まどろっこしいです。

さて、PythonPathを上手に利用するためには2通りの方法があります。
一つは自分で環境変数PYTHONPATHを設定してPythonPathに好きなパスを追加する方法です。
export PYTHONPATH=${PYTHONPATH}:/usr/local/google_appengine:/usr/local/google_appengine/lib/antlr3:/usr/local/google_appengine/lib/django:/usr/local/google_appengine/lib/webob:/usr/local/google_appengine/lib/yaml/lib

もう一つは最初からPythonPathが通っていて、かつユーザーが自由に使ってもいい領域「site-package」を利用する方法です。
詳しい理屈はよくわかりませんが、Pythonには最初からsite-packageとかいう自由にライブラリを追加するための領域があるみたいです。
現在のsite-packageを調べるためには、id:a2cさん曰く
python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

これだけでいいそうです。試しにPython 2.5.1 Apple Buildで実行してみたところ、
$ python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
/Library/Python/2.5/site-packages

こうなりました。たぶんpython.orgのPythonや、macportでインストールしたPythonだとまた全然違った値になるのではないかと。
ということでこの/Library/Python/2.5/site-packages以下に、ダウンロードしてきた外部のライブラリなどを配置していけば自動的にパスが通っていい感じになりそうです。


■autoimpを使ってみよう
autoimpというライブラリを利用すると、いちいち最初にimport osとかimport mathとかしなくても直接os.path.join()とかmath.piとかが呼び出せるみたいです。
http://www.connellybarnes.com/code/autoimp/
使い方は簡単、まずはライブラリのソースを↑のページからダウンロードしてきて、
先ほどご説明したsite-packages以下に置くだけ。

あとは、
>>> from autoimp import *
>>> os.stat('.')
>>> sys.path
>>> math.pi
>>> google.appengine.ext.db.Model

一度from autoimp import *してしまえばimportなしで何でも自由に使えるという寸法らしいです。すごい。
でもこれでは結局最初にfrom autoimp import *と書く手間がかかってしまいますので、
Python起動時に自動的にfrom autoimp import *してくれるように設定してみましょう。


■PYTHONSTARTUPを設定しよう
環境変数PYTHONSTARTUPを利用すると、Pythonの起動時に毎回決められたスクリプトを実行することが出来るらしいです。
たとえば自分のホームディレクトリに、以下の.pythonstartup.pyというファイルを作ってみます。
#!/usr/bin/env python
#coding: utf-8
print 'hogehoge'

そして環境変数PYTHONSTARTUPを以下のように設定します。
export PYTHONSTARTUP=~/.pythonstartup.py

一端ターミナルを再起動してからpythonを実行してみると・・・
akisute ~$ python
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
hogehoge
>>>

ほら、print 'hogehoge'が実行されてますよね。
同様にして、以下のように.pythonstartup.pyを設定すれば・・・
from autoimp import *

Pythonを実行すると・・・
akisute ~$ python
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> os.path
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/posixpath.py'>
>>> math.pi
3.1415926535897931
>>> google.appengine.ext.db.Model
<class 'google.appengine.ext.db.Model'>

ごらんの通り!importなしに自由にモジュールが利用できています!

2016年10月3日月曜日

ATS の AVFoundationに対する 例外条項の注意点

2016/10/03段階でのATSを有効にする際の覚書です。基本的には全てTLS 1.2以上をサポートするhttpsにしてしまえばOKですが、例外条項としてAVFoundationのStreamについてはhttpでもよいと例外条項が定められています。

https://developer.apple.com/videos/play/wwdc2016/706/?time=324

これについては設定不要で自動的に適用されるようにWWDCのビデオ上では見えますが、実は落とし穴があり、この例外条項はiOS 10以降でのみしか適用されません。iOS 9については実はAVFoundationのStreamについてATSが完全に適用されているようで、httpの動画をStreamingしようとしても失敗してしまうので注意が必要です。

2016/10/03 16:45 追記
こちらXcode 7.3.1でビルドしたバイナリにて調査した内容ですので、SDKのバージョンが異なるXcode 8.0以降でビルドしたバイナリであればiOS 9.x系でもAVFoundationのStreamについてATSの例外条項が適用されてhttpで通信できるようになるかもしれません。ただ紹介した参照元のWWDCのビデオを見ても分かる通り、基本は例外を考えず全てhttps化するのが良いとされているため、ビデオストリームについても可能であれば全てhttps化するほうがトラブルがないかと思います。

2009年2月26日木曜日

input type="radio"でchecked指定しているにもかかわらずデフォルトでチェックが入らない?と思ったときは・・・

原因を調べるのにずいぶんと苦戦したので備忘録を作ります。
input name="calendar_1" value="1" type="radio" checked

こんな感じのチェックボックスが画面にあるのですが、何度試してもデフォルトcheckedにならないのです。
IEでもFFでも再現しました。

Firebugからcheckedを再度指定し直したり、きちんとchecked="checked"に書き方を変えてみてもダメ。HTMLのバグかと思いましたよ。

原因は・・・そう、ラジオボタン、カレンダーで使ってたんですよ。
3月の1日と4月の1日が同じカレンダーの上に乗っかることもありますよね。

input name="calendar_1" value="1" type="radio" checked
input name="calendar_2" value="2" type="radio" checked
input name="calendar_3" value="3" type="radio" checked
・・・中略・・・
input name="calendar_31" value="31" type="radio" checked
input name="calendar_1" value="1" type="radio" disabled checked
あ、同じ名前のラジオボタンがあるじゃーん。しかもcheckedだー。
そりゃだめだわーアハハハハというお話でした。
checkedが機能しないときはまず真っ先に同じ名前のラジオボタンがないか疑え、ということで。

2014年1月7日火曜日

LLDB のカスタムコマンドを Python で書いてみようとして大失敗した話

なんかうまくいかないんです(´・_・`)

Xcode 5のデバッガとして用意されているLLDBですが、実は設定ファイルを書くことで自由にカスタマイズすることが可能になっています。またPythonを使ってより深いLLDB自体の挙動をカスタマイズすることも出来るらしいと最近教えてもらいました。

参考: http://qiita.com/dealforest/items/e3a5284badd17733ccc1

さてこちらの参考記事に、
例えば動的に生成した UIImage をファイルに出力するコマンドとかは便利そうですね。
というなかなか夢のある発言があるのですが、残念ながらこちらの記事の中では実際のコードがありません。ということでLLDBの設定の練習がてら、私の方で早速デバッガからUIImageをファイルに書き出すコマンドの作成にチャレンジしてみました。

■実装方針

LLDBを操作するために使用できるPythonモジュールについては、LLDBの公式ページに詳しいドキュメントが揃っています。
http://lldb.llvm.org/python-reference.html (簡単な解説とチュートリアル)
http://lldb.llvm.org/python_reference/ (APIドキュメント)

また既に何人かの方が似たようなことをされた形跡があります。
http://stackoverflow.com/questions/12668815/lldb-python-access-of-ios-variables
http://stackoverflow.com/questions/18468126/pointer-arithmetic-in-lldb-python-scripts
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-January/000321.html

これを元にして、以下の様な戦略でいってみます。

  1. 引数のUIImageをUIImagePNGRepresentation関数を通してNSDataにする。
    • ただのUIImageをそのままファイルに書き出しても使えませんので、まず一旦JPEGなりPNGなりに変換する必要があります。ここではObjective-C側に変換してもらうことにします。
  2. NSData bytesを取得する。
    • expr (const void *)[(NSData *)UIImagePNGRepresentation(image) bytes]とか叩けば一発なはずなので、その方針で行きます。
  3. ファイルに書き出す。
    • exprの結果をraw dataで取り出せれば、あとは普通にファイルに書き出しておしまいです。簡単そうですね。
ということで出来たコードはこちら。


■しかし

やはりというか落とし穴がorz
冒頭の画像にもあるのですが、Python経由でexprした実行結果を取得する手段がどうにも見つかりません。SBFrame.EvaluateExpression(expr)の結果がSBValueなんだからそっからデータが引けるだろうと思っていたのですが、何を実行しても壊れたSBValueしか返却されないためどうにもうまくいきません。SBDebuggerやSBCommandInterpreter経由でHandleCommand(expr, result)する手も考えたのですが、今度はresultから値を取る手段がない(resultをコンソールではなくファイルにリダイレクトする手段しか無い)ためやはり断念です・・・

うーん。もう少し頑張ったらうまくいきそうな気もするのですが。残念です><


2009年7月12日日曜日

vim javascript indent plugin syntax

javascript用のvimプラグインがたくさんあって探してもこれといったまとめがなかったので探した範囲でまとめました。タイトルが釣りっぽいです。ごめんなさい。


■syntax
JavaScript syntax : Better JavaScrirpt syntax support
http://www.vim.org/scripts/script.php?script_id=1491

悪くはないです。ただし中身を見た感じFirefox + Dojoで使うことを想定されているようで、jQueryとかでprototype.jsでハイライトして欲しいオブジェクトがなかったりします。気に入らなければ適当に改造するのがよいと思います。それに、所詮syntaxですから無くてもあんまり困りません。


■indent
よさげなのが2つあります。まず一つ目、Ryan Fabellaさん作。スタンドアロンで動くもの。
OOP javascript indentation : This indentation script for OOP javascript (especially for EXTJS)
http://www.vim.org/scripts/script.php?script_id=1936
especially for EXTJSとか書かれてますがjQueryでも全く問題ないです。快適。

実際にインデントしてみた結果はこんな感じです。




//でコメントアウトすると完全にレイアウトが壊れてしまいます。/**/を使えば問題ないようです。


二つ目、Tye Zdrojewskiさん作。別にプラグインが必要になるもの。
http://www.vim.org/scripts/script.php?script_id=1840
会社のマシンにはこちらを入れています。実際にインデントしてみた結果はこちら。





こちらは//だと問題ありませんが、/**/だと崩れてしまいます。あと、$(function(){hogehoge...});を綺麗にインデントできていません。


どちらも一長一短なので、どちらを使うかは好みの問題ですね。


■plugin
IndentAnything : Write indentations or enhance existing indentations without writing code
http://www.vim.org/scripts/script.php?script_id=1839

Tye Zdrojewskiさんのjavascript indentを動かすために必要です。なんか勝手にIndentAnything_htmlなんていうindentが付属で付いてきますので、既にhtmlのインデントを持っている人は注意です(IndentAnything_htmlはおまけなので入れなくても大丈夫だと思います)。

2013年1月20日日曜日

エンジニアサポートCROSS 2013で発表してきました

先日ニフティさんが主催されたエンジニアサポートCROSS 2013におじゃまさせていただきました。このエンジニアサポートCROSSは年に1回、去年から開催されているらしいのですが、なんといっても大手企業さんが主催ということで
  • 参加者がとにかく豪華
  • プレモル飲み放題ケンタッキー食べ放題という夢の様な環境
  • それでいてきちんとWeb系/Make系コミュニティのギークっぽい雰囲気のカンファレンスになっている、スーツではない
という独自の魅力があるカンファレンスになっていました。

で、このエンジニアサポートCROSSにはアンカンファレンス枠があって、参加者が自由気軽にその場でプレゼンを行う事ができる場がありましたので、せっかくだからということで私も発表させて頂きました。


内容については先日リリースしましたダンゴルのサーバサイド側の裏話です。といってもスライド見れば分かる程度のものです。

来年は正規のスピーカー枠で参加したいです><