yidev 第16回で発表してきた

By | 2014年9月29日

先日 yidev#16 で発表してきました。
第16回 #yidev 横浜iPhone勉強会に参加してきたよ」がとても分かりやすいです。
また運営の @es_kumagai さんありがとうございました。

発表の際に @sonson_twit さんがデバッグ情報をスクショの EXIF に埋め込めば?というアドバイスをもらってそれだとコピペもできるしいいな〜と思ったので、実装しようと思ってた矢先にまさかの PR が。

仕事がはやい!!感謝感謝です。

というわけで 0.0.4 をリリースしました。
挙動は今までとかわりませんが、保存されたデバッグ用の画像の EXIF(userComment) に保存されています。

スクショを撮った時に Slack や Hipchat への自動送信の機能を考えてるので、それを実装する時にでも本物のスクショの EXIF を操作するようにしようかなと思います。

See also

* スクショを送られてきた時にデバッグを楽にするライブラリを作った

スクショを送られてきた時にデバッグを楽にするライブラリを作った

By | 2014年9月3日

バグってんだけど…これちょっとおかしい…デザインくずれてんだけど…
といわれてスクショだけ送られてきたことが一度はあるかと思います。
(まぁどういう状況なのか見た目から推測できるので無いよりもマシだけども…)

さて、スクショだけを送られてきてバグってるといわれた時に何が困るでしょうか。

それは情報が足りずにデバッグを始める前に情報集めをしないといけないことです。
当然ユーザーのための画面にエンジニアが必要な情報が出ていることはまずないでしょう。

個人的にはこの情報を集めるのがクソめんどくさい!!!!!1

送ってきたユーザーはだれ?
デザインが崩れているデータはどれ?
自社で API も開発してる場合は原因はサーバーサイド?それともクライアントサイド?

スクショを撮った時に表示されてる UIViewController からなら上記のような疑問を解決するのは容易なのに…と思いながら、それらを特定するための情報を集めるところからはじまります。

リクエスト先の API が自社の場合だと Access Tokenと Request Parameter が分かれば、
実際にリクエストを送り原因がサーバーサイドなのかクライアントサイドなのかを特定することができて便利ですね。
(Access Token を出力する場合はセキュリティ上、注意が必要なので自己責任でやってください)

また UIWebView を使用している Application だと特定の WebStorage や Cookie が見れたらデバッグが捗るかもしれません。

デバッグに必要な情報は画面(UIViewController)毎に異なります。

前置きが長くなりましたが、デバッグに必要な情報を揃えてるプロセスがそもそも無駄だなと常々思っていました。

それを解決する方法を思いついたのでライブラリにして公開しました。

dealforest/DFTDebugScreenshot

方法はシンプルでデバッグ情報がほしい UIViewController に - (id)dft_debugObjectForDebugScreenshot
を定義し、デバッグに必要なオブジェクトを返すようにしておけばスクショを撮った際に、そのオブジェクトの description した結果が画像として出力されます。

demo

CocoaPods にも公開しているのですぐに使えます。

長くなってきたので、ライブラリの詳細については別エントリーにしようと思います。

yidev 第16回勉強会 で発表する予定なので、この辺りのことをまとめて話せればと思ってます。
もし他で話す機会があれば話そうかなと思います。

ではでは。

おまけ

Homebrew や PromiseKit で有名な Max Howell(@mxcl) 氏に公開してすぐにスターをつけてくれたのでやる気に満ち溢れています。

Posted in ios | Tagged

yidev@恵比寿勉強会 で chisel について発表してきた (動画付き)

By | 2014年4月27日

2014/4/26 #yidev @恵比寿勉強会 で発表させてもらいました。
facebook/chisel を使えば LLDB からのデバックがこんなに快適になるよ!といった内容です。
好評なようでよかったです。

chisel は LLDB に Python のスクリプトを実行する仕組みがあるので、それを利用した便利なコマンド集です。
LLDB Python Refarence にその辺りは詳しくのっています。
発表に伴い資料だけだといまいち魅力が伝わらないのがもったいないとのことなので、デモ動画を作成しました



初めて動画を作ったのでどうしたらいいかイマイチわかりませんでしたので、誰かその辺り教えてくれたら嬉しいです。

このデモのサンプルを github にあげているのでもしよければそっちでも動かして確認してみてください。
実際、自分のプロダクトでいきなり使えるので、そんな必要ないとは思いますが…

また、今回発表の場をあたえていただいた @takayama さんありがとうございました。運営ご苦労さまです。

cocoapods で homepage を開くコマンドを作ったお話

By | 2013年12月28日

みなさん cocoapods を使って久しいかと思います。
僕がよくやるのが pod seach で検索して Homepage(大体githubのページ) を開いて README, 履歴, コードをざっと確認してそのライブラリを使うかどうか確認していました。

ただこれがいくつもあるとコピペで繰り返すのは面倒くさい作業でした。

このツイートを見て try くそ便利だなと。
コマンドで browser を開ければいけてるやん!!
と思って早速調べてみました。
cocoapods には plugin 機構があり、簡単にできそうなので作ってみました。

使い方は簡単で gem で install するだけで使えます。

gem install cocoapods-browser

あとは気になった pod を引数に渡すと browser で podspec で指定している homepage(おそらくgithubのページ) を開くことができます。
pod は複数指定することもできます。

pod browser PODNAME

dealforest/cocoapods-browser

プルリクもらえればとりこみまっす。
ではでは〜

追記1

便利そうなので追加しました。

pod browser PODNAME --spec

これで https://github.com/dealforest/iOS-FakeWeb/blob/master/iOS-FakeWeb.podspec を開くようになります。

追記2

Naming (browse instead of browser) のアドバイスより version 0.1.0 からコマンド名が browse になりました。

pod browse PODNAME

iOS7 で UITableViewCell の深度を変更する時に気をつけること

By | 2013年10月25日

UITableView に対して bringSubviewToFront: のメッセージを送って UITableViewCell の深度を変更していたですけど
iOS7 からだと深度がかわらんなくなって困ったというお話です。

原因は iOS7 と iOS6 とで UITableView の構造が変わったためです。
iOS6 では UITableViewCell を UITableView が抱えていたのですが
iOS7 からは UITableViewWrapperView が間に加わりそいつが UITableViewCell を抱えてます。

[iOS6]
UITableView
    ├── UITableViewCell
    ├── ...
    └── UITabelViewCell

[iOS7]
UITableView
    └── UITableViewWrapperView
                   ├── UITableViewCell
                   ├── ...
                   └── UITableViewCell

bringSubViewToFront: は抱えてる view に対して実行してやる必要がるので
iOS7 の場合は UITableViewWrapperView に対して実行してやれば深度が変更されるというわけです。

とはいえ UITableView から UITableViewWrapperView にアクセスができません。
正確には subviews をたどればできるけど諸々考慮すると最終手段にしておきたい手段です。

superview が抱える view を指しているので、ようするに UITableViewCell の superview に対して実行してやれば
iOS7 と iOS6 共に同一のコードで深度が変更できます。

[旧]: [tableView bringSubViewToFront:cell]
[新]: [cell.superview bringSubViewToFront:cell]

元から UITableViewCell の superview をたどってメッセージを投げていれば問題なかったというわけです。
つまりは構造が変わってるから気をつけろよといったお話ですね。はい。
今回のとは関係ありませんが UITableViewCell の構造も変わったので注意しないといけないですね。

あと、iOS6 の時は深度変更した際にスクロールバーが消えるバグがあったんですけど iOS7 では直っていました。
iOS6 では 「UITableViewCell の深度を変更した時に scrollbar を正常に表示する方法」で表示することができますがパフォーマンスは若干落ちます。