kumamotone’s blog

iOS/Android アプリエンジニアです https://twitter.com/kumamo_tone

potatotips #45 に参加しました (iOSブログまとめ)

potatotips #45iOSブログまとめ枠で参加させていただきましたのブログです。

f:id:kumamotone:20171128234024j:plain

今回の会場はリクルートマーケティングパートナーズ さんのオフィスです。

f:id:kumamotone:20171128234113j:plain

溢れ出す親切さ。飲み物なども個人的にありがたいバランスでしたーありがとうございます。

以下発表内容です。間違いや気になるところなどあればご指摘ください。埋まっていない資料は公開されたのを見つけ次第反映します。

swagger-codegenから眺めるSwift4 / d_date さん

speakerdeck.com

SwaggerではAPIの仕様をYAMLで管理できる。 swagger-codegen を使って YAML 書いて CircleCI にぶち込んでクライアントとサーバーサイドのコード両方生成したい気持ちがある。

そんなswagger-codegenはSwift4に絶賛対応中。

絶賛対応中ということは壊れているということ。

運用でカバーでも良いが壊れてるなら直せば良いんですよ。→直した。手っ取り早く草を生やしたい人にオススメです。

感想

流れが速すぎて笑いました。関モバで予習していてよかった(?)

コード生成による自動化、壊れていたら直すの精神などもう1から10までエンジニアとして見習うべきだなぁと思いました。

XcodeGenでxcodeprojを卒業する / nonchalant さん

speakerdeck.com

xcodeprojっていうのがありますよね。ただのディレクトリなんだが、ターゲットの情報だとか、ビルド設定だとか、色々持ってる。

ところでxcodeprojってコンフリクトするよね。つらい。gitで管理したくない。

github.com

そこでXcodegen。説明によるとこれを使えばgitの管理下から外せるので、二度とxcodeprojでコンフリクトは起こらないとしている。

どういうものかというと、 project.yml を入力に xcodegen を叩けば xcodeproj にできる。Swift製。

github.com

サンプルリポジトリを作ってみました。見てみるとわかるが、project.ymlのほうが可動性がある。短いし。特にdependencesのあたりとかわかりやすい。

RIP *.xcodeproj :pray:

感想

良さそう。が、なかなかここらへん自分でいじるのは勇気要りそう‥‥

あと層ごとにフレームワークに分けるのも普通によさそう。

stackviewでボタンつくった話 / sun54907 さん

speakerdeck.com

仕事でボタン作った。要件はよくある感じのやつで、以下のようなパターンがある。

  • タイトル(文字だけ)
  • タイトルの左に画像がある
  • タイトル右の画像がある
  • 内容に合わせた幅になったり、固定幅になったりする

github.com

これを公開した。 工夫した点として、Stackviewで Android の wrap_content っぽい挙動を実現している。

内容が多くなれば広がるし、 isHidden を設定すればトルツメできるので便利。

感想

iOS8 切れない状況でConstraintをごにょごにょやってトルツメとかやったことあるので、ここらへんの便利さは分かりみがある。

全体的にUI周り不親切感あるなぁという気持ちが爆発している。普通にこのくらいUIButtonでいい感じに出来てほしいし、StackViewに乗せると自動で幅が変わってすごいっすよ〜みたいなの確かにすごいんだけど悲しくなってくる。未来の子どもたちはここらへんまったく意識せずにも実装できる世の中に生まれてほしい。

Codable Tips集 / tattn さん

speakerdeck.com

Codableは型のエンコードとデコードをサポートする機能。Codableは大人気でめっちゃ記事があるのでそれを参照してください。

CodableはSwift3.2で使えます

まずはこれを伝えたい。CodableはSwift4の機能だと思っている人たくさんいるが、CodableはSwift3.2で使えます。

複数行の文字数リテラルとかKeyPathリテラルクロージャ型KVOとかすげぇ便利なやつもSwift3.2で使える。Swift4が使えない事情があっても大丈夫。

Upper Camel Caseをkeyにするプロトコル

本題。APIがKeyがUpperCamelな名前でデータを返してきて、クライアントではふつうにlowerCamelで受けたいケースがある。こういうときはふつう CodingKeysを書いて対応すると思うけどtypoすると通らなくなるし冗長で嫌。

CodingKeyにはkey名とプロパティ名の対応をカスタマイズできるI/Fが用意されていて、これをカスタマイズすれば型で変換を表現できるしtypoしない。

Upper Camel Caseをkeyにするプロトコルを紹介したが、これ以外にもSnakeCaseCodingKey とか作れば snake_case でもなんとかなる。文字列処理のパフォーマンスがきになる場合は変換後のkey名をキャッシュしたりSourceryを使ってコード生成したりすると解決できる。

String を任意の型で受け取れる型を作る

ときどきあって、本当はサーバーで直してほしいのだが、Int で返してほしいValueがStringで返ってくるのをどうにかしたい。

Stringを別の型に変換する魔法の箱をつくると解決できる。

デコードの失敗を許容する型を作る

配列やURLをデコードしたいが、たまにデコードできない値が入るということがある。そんなときもデコードの失敗を許容する型を作って解決できる。

残り

時間がないので資料を見てください

github.com

感想

今日から使いたいTipsが多くガッツリ使いたい気持ちになった。

パフォーマンス改善の部分、具体的にどうなるのか気になる。

Human Interface Guidelinesを参考にApp Storeを見てみた / NatsukiIdota さん

App StoreのTodayは見出し+カードという構成。たぶん見出しはHIGの Clarity. に当たり、 角は Diference. に当たるんではないかと思う。

App Storeは、全体としてみると一見HIGにそっていないように見えるが、1つ1つを見れば、HIGに沿っているという感じがする。

感想

たしかにHIGに標準アプリを参考にするということはあると思うけど、App Storeは特に参考になりそうな部分かもなと思った。

最近あんまり意識してなかったのでざっくり眺めなおしても良さそう。

できるだけUI系のライブラリを用いないアニメーションを盛り込んだサンプル実装まとめ / sakmt さん

www.slideshare.net

仕事でUI書くこと多くて、AWAを参考にして以下の記事を書いた。

qiita.com

UIScrollViewの中にContainerViewが2つあり、画面を左右のスワイプあるいはタブのタップでに切り替わるみたいなUI。MVP使ったりした。

アニメーションや動きを伴う実装部分を色々DIYしてみたが、自分で作ってみると意外と趣があって良い。

感想

Qiitaが力作で、後でゆっくり読みたいと思った。

ScrollViewにコンテナがいくつかとTableViewがあって〜みたいな実装はよくあると思うので自分もDIYして知見溜めていきたい。

UIStackViewとかで快適UI作り事例紹介 / sakmt さん

UIStackView良いですよね。人間が美しく感じる形、同じ大きさ同じ形同じ間隔、それってUIStackViewじゃん、となる。

後半ライブコーディング。SnapKit+Kotlinのapply関数っぽいエクステンションの組み合わせを使って、カルーセルを作ってみる。

UIStackViewとScrollViewがあれば、5分たらずでよくあるカルーセルができる!

感想

ライブコーディングがかっこよかった。

SnapKit+Kotlinのapply関数っぽいやつの組み合わせ、気持ちよさそうなのでやってみたい。

ContainerViewController作成の流れ / vespid さん

github.com

ContainerViewControllerでTwitterプロフィール画面のUIを作ってみる。

制約:

  • スクロールできる
  • スクロールによってヘッダが縮む

とか。

素朴に作ると、UIの要件と、自然なUIの両立ができないときがある。たとえばcontentSizeが小さい場合に画面切り替えでヘッダがおかしくなるとか。こういう場合には落とし所を見つける必要がある。

今日は時間の関係上抽象的な話になりますが、再利用性を高めながらいい感じに作っていきましょう。

感想

動画キャプチャをいい感じに載せてくださっていてスライドがわかりやすくかっこよかった。

たしかにこういう画面割りとよくあって、作ってみると理解深まって良さそう。

ReactNative+GraphQLでなんか作る / yukiasai さん

speakerdeck.com

GraphQLはFacebookが頑張ってるやつで、Scheme,Query, Mutation, Subscription というのがある。

SchemaはSchema。Get に相当するのが Query、 POSTがMutationみたいな感じだと思ってもらっても良い。Subscriptionは購読できる。なんか値が変わったときに通知してくれる。イケてる。

ReactNativeとGraphQLでChatを作ってみる。 react-apollo を使って Reduxは使わない。簡単!

感想

たしかに既存のよくあるAPIのつらみみたいなのが解決できそうな雰囲気があって、MutationやSubscriptionのあたり、すごく良さそうだなという気持ちになった。

サンプルコード後で拝見したい。

さいごに

f:id:kumamotone:20171129001349j:plain

全体的にUIの話が多いな〜と感じた。京橋だけどあんまりリアクティブエクステンションの話は出てこなかった。

懇親会でUI周りのつらみとかXcodeのここがバグっている、みたいな話ができてよかった。

明日使えるTipsとしては @IBDesignable 付けてるとなんかやたらIBがビルドをはじめてバッテリを持っていかれるときがあり、そういうときは 「Editor > Automatically Refresh Views」 のチェックを外すと一旦走らなくなる、だとか、

あと悲しい感じの話としては「全体選択してctrl+Iでフォーマットできるけどカーソルがファイル末尾にぶっ飛ぶ」「Editor > Fix All in Scopeを選択すると赤丸のポチポチでFixしまくらなくて良くて便利だったがXcode9でなんかグレイアウトして使えなくなった」「Editor > Refactor to Storyboard...は便利そうだけど一回使ったらぶっ壊れた」などがありみなさま各々苦労してらっしゃるな〜という感じだった。

毎回頑張って聞いてまとめているとどんどん短い時間で理解できる力は増している感じはする。がAndroid枠の方も結構気になる発表とかあったのに聞き漏らしちゃってるのであとで資料を拝見したい。

最近毎回ブログ書いてるんですが毎回ブログ書いてると「ブログ枠空いてますよ」とか教えてくれたりする人とかもいて最高。基本的に良いことしか無いので今後もやっていきたい。

potatotips #44 に参加しました (iOSブログまとめ)

potatotips #44iOSブログまとめ枠で参加させていただきましたのブログです。

f:id:kumamotone:20171025234605j:plain

eureka さんのオフィス。アクセスがとても良く、ブログまとめ枠なのに遅刻とかヤバいなと思いながらギリギリの電車に乗ったのですがなんとか間に合いました。

f:id:kumamotone:20171026112153p:plain

おしゃれ。なんか写真?とか飾ってある。おしゃれ‥

f:id:kumamotone:20171025234728j:plain

電源タップも用意していただいて大変ありがたい。あと良いスピーカーが良い位置にあって聞きやすかったです。

社員さんの人柄も良い(個人の感想です)。

以下発表内容です。間違いや気になるところなどあればご指摘ください。埋まっていない資料は公開されたのを見つけ次第反映します。

アプリ内でWebAPIを抽象化するためのフレームワークAbstractionKitの紹介 / hiragram さん

speakerdeck.com

APIリクエスト周りつらいのでAbstractionKitというのを作った。WebAPIを構造化して定義するためのフレームワーク

github.com

結果取り出すときは:

SingleResponse<User>.init(json:json).result → User 

みたいな感じで取り出せる。

配列は:

ArrayResponse<User>.init(json:json).result → User 

無を取り出したい場合は:

EmptyResponse.init(json:json).result → Void

統一的!プロダクト寄りの視点でVASILYさんのブログにも書かれているようです。

iOSアプリに導入したプロトコル指向なAPI抽象レイヤーの設計 - VASILY DEVELOPERS BLOGtech.vasily.jp

感想

APIリクエスト周り絶対に抽象化したい気持ちを感じました。

アプリ、API叩いてつらくなるケースがほとんどだと思うので、言語もいい感じに進化してここらへん楽になるといいなぁと思いました。

Showcase Library について / YuyaHorita さん

ルーセル表示を簡単にするライブラリをつくった。

github.com

サイズ、間隔、方向、動き方(直線的ではなく、にゅっと動くとか)などがカスタマイズできる!具体的な使いかたや使い道を紹介。

感想

円軌道のカルーセルなどを簡単な設定で作れるのは面白いなーと思いました。

kazuhiro4949/PagingKit を見たときも思ったんですけど、UIライブラリ使うと便利だけど完全に見た目がそのライブラリの表現できる幅に制限されるという問題があるので、こんな風にカスタマイズ性を重視した作りになっていると使い勝手良さそうだなぁと思いました。

github.com

Introduction Differ / Yusuke Takahashi さん

speakerdeck.com

Flux と RxSwift でアプリ作る。tableViewの内容を書き換えて更新処理するようなものを考える。

Flux、Virtual DOMとは相性良いのだろうけど、iOSだと単純に作ると毎回全体reloadしてしまってパフォーマンス的に微妙だったり、アニメーションが走らなかったりしてUX的にも微妙。

tonyarnold/Differを使うとそれらがいい感じにバランス良く解決できるよーという話でした。

github.com

これはcorin8823さんのデモ。

github.com

感想

Differ、Flux使わない場合でも便利そうと思いました。UITableViewの更新パフォーマンスに悩んだときは参照しなおしたいです。

WKWebViewのキャッシュについて調べた / hotpepsi さん

www.slideshare.net

WKWebViewでblobsが肥大化する件について、実機とシミュレータで調べた。

Appleは意外とちゃんとオープンソースでデータを公開していて、 https://opensource.apple.com から見ることが出来る。WebKit2は https://opensource.apple.com/source/WebKit2/ っぽい。

iOS8は肥大化しない、iOS9の肥大化しない、iOS10もソースは同じっぽいけど何故か肥大化する。WWDCで直接開発者に言ってみた。

iOS11ではキャッシュがアプリサイズに含まれなくなったので良くなった!めでたし

感想

ソースを参考に解決をスタイル、WWDCで直接開発者に聞いていくスタイルに強さを感じました。つよい

入力を型で表現する / Motoki Narita さん

speakerdeck.com

メルカリカウルで出品するとき、「バーコードを読み込む」「タイトルから検索する」方法がある。

出品ボタンを押すと、カメラが起動して、バーコードを読むと、ISBNから商品を検索してくれたりする。

これ、そこそこ複雑だが、入力は1つの型で表現している。

Inputを、データとenumのセットのstructで宣言しておく。こうすることによって、データと画面処理を分離しやすいし、今後入力のバリエーションが増えることがあっても同じ型で表現することができる。

感想

いい感じに製品紹介が含まれておりメルカリカウルをまんまとちょっと使いたい気持ちになってしまいました‥w 個人的にキャッチーなタイトルで楽しみでした。型で表現できることはどんどん型で表現していきたいですね。

carthage verify / r_plus さん

speakerdeck.com

Cartfile.resolveを更新してコミットしてpushするのだが、果たしてチームメンバーはちゃんと追随してくれるのだろうか?CocoaPodsの場合は保証する仕組みがある(Manifest.lock)。

色々試行錯誤した結果、commitishとCartifle.resolveを比較しればいいのでは?となった。というかこれ本家で提案されているのでは?となった。

調べてみた提案されていたが、carthage自体でやんないほうがいいよねとなりcloseされていた。

github.com

その提案してくれていた人がCarthage/workflowsにcarthage-verifyというシェルスクリプトを追加してくれていた。Build Phases にこれをつっこむと、diffがあればビルドエラーにしてくれる。速度もBuild Phasesに入れていいレベルで、0.08秒とかで終わるレベル!

感想

Carthage単純に便利だから使っていて、ビルドできなくなったらなんとなくupdateするみたいな適当な使いかたしてたけど、たしかに動いているように見えて挙動が変わっている可能性もあり、追随を保証する仕組みはたしかに欲しいところだなぁと思いました。

ここらへん詳しくないのだけど、とても分かりやすく聞きやすい発表でした。

ARとFaceTracking / TachibanaKaoru さん

speakerdeck.com

ARKit本当に簡単。Xcodeにテンプレートあるし、ARSCNViewなどのオブジェウクとを作るだけで動画処理などしなくて良い。

描画エンジンを選択できて、SceneKit、SpriteKit、Metal、だけでなくUnity(専用のプラグインがある)、Unreal Engineも。

ふしぎの国のアリスARというのがあって、結構面白い。

AR Face Detection も簡単に使える。iPhoneX、前面にカメラ以外にも色々ついていて、顔になんか照射して顔の深度情報を取得できたりする。顔の情報が取れたらdelegateで内容が取り出せる。ただし実機のみ…iPhoneXほしい!

感想

こういうの聞くとなんだかんだiPhoneX触ってみたさ出てきますね。

ふしぎの国のアリスAR面白そうなので触ってみようと思います。

iOSのCorner Rounding Strategy / Shunki Tan さん

speakerdeck.com

丸く画像をくり抜くのにどうやってパフォーマンスよくするかという話。

今日の話のソースはここ。

texturegroup.org

CALayerのCornerRadiusはパフォーマンスが悪い。なぜかというと、毎フレームクリップ処理のためにレンダリングが走っている。角だけのViewを作って、かぶせるとパフォーマンスが良い。

感想

個人的に英語の記事をわかりやすく解説してくれる発表は単純にありがたかったです。cornerRadius普通に使いまくってる気がするのでパフォーマンスに影響が出ていないか心配になってきました。

さいごに

f:id:kumamotone:20171025235240j:plain

懇親会でPairsアプリの細かい挙動の指摘をhiragramさんがエウレカのエンジニアさんにしてるのとか見たりしてワイワイしました。

なんか隣でじゃんけん大会もやってました。

完全に私事ですがブログ枠で、今回はじめて当日中にpostすることができました(日付は変わってしまいましたが)。

前々回はじめてpotatotipsでブログまとめしたときは、あまりにブログ慣れしていないが故にTwitterは追えずツイートも出来ず、ブログまとめるのには丸2日ぐらい掛かっていているという惨状でした(大したこと書いていないのに…)。

しかしさすがに連続でブログ書くとちょっと慣れてきた感じがあり、今回はちょいちょいツイートしつつ、DMとか返しつつ、ブログの材料も時間内に割りとメモることができました。まだまだ不慣れ感はありますが…

potatotips、個人的には出ることで学びと成長を感じれる勉強会なので本当に助かっています。今後も参加していきたいです。

potatotips #43 に参加しました (iOSブログまとめ)

potatotips #43iOSブログまとめ枠で参加させていただきましたのブログです。

f:id:kumamotone:20170903191929j:plain

会場の Money Forward さんのオフィス。プレミアム会員になるぐらいにはお世話になっているのでテンションが上がる。

f:id:kumamotone:20170903192144j:plain

会場。とにかく新しくてオシャレという印象。

社員さんがいらっしゃったので、

「LINE Pay に対応して最高に便利になりました」

「bitflyerやmaneoとか銀行以外にも手広く対応してるのありがたいです」

「ただアプリで開くとあまりに堂々と総資産が表示されすぎて出先で開きにくいので非表示にするオプションをつけてくれ」

などなど日頃の感想を言いたい放題言いました。

以下発表内容です。間違いや気になるところなどあればご指摘ください。

iOSのBLEでハマった事 + Tips / tomoya0x00 さん

qiita.com

BLEデバイス(peripheral)がアプリから見つからない(フォアグラウンドのスキャンでは引っかかるが、バックグラウンドだけ見つからない)ということがあった。

まずバックグラウンド特有の制限に引っかかっているのではないかと考えたが違った。アドバタイズ間隔が広すぎるとバックグラウンドで検知できないのではないかと考えたが、それも違った。

その後、BLEスニファーというものを使って、BLEの伝播をキャッチして通信内容を見た。iOSだとスキャンレスポンスは無視されるのだが、スキャンレスポンスにService UUIDが乗っかっていたのがわかった。

どうするか?iOSは過去に接続したことあるBLEデバイスのIdentifierを記録しているので、これを指定すればスキャンせずに接続要求できる。ベストプラクティスに従うと吉。

感想

BLE扱うのなかなか大変そう。どういう風に対処していったか、細かく紹介されていて参考になりました。

VIPERアーキテクチャのRoutingに関してTIPS / ヤマグチケイスケ さん

www.slideshare.net

まずVIPERの説明。VIPERとは

  • View 画面。UIViewControllerとか
  • Interactor ロジック
  • Presenter 仲介するやつ
  • Entity データとかenumとか持っている
  • Routing なにがどこにあるか知ってる

の5種類のModuleを使ってアプリを構成していく設計。

それぞれに Input と Output の protocol を持たせて、どういうI/Fでモジュール間のやりとりをするのかを規定する。Generambdaという自動生成機を使えばModuleを簡単に生成できて便利。

Routingは全Moduleを知っている唯一の存在。これに hyperoslo/Compass をつかうとすごく良い。

github.com

hyperoslo/Compass は、画面の呼び出しや機能の呼び出しを一括で文字列のスキームとして扱えるので、Routingを1モジュールでやる場合に相性が良いとのこと。

2つ目のtipsは時間がなくて終了。(Storyboard のインスタンス化をenumを使って便利に安全にやるというやつっぽい)

感想

VIPER、何度も名前は聞いててMVVMで足りないときちょうど良さそう、という印象。

実際に使って作ってみたことがないのでそろそろ作ってみたい気分になりました。Generambda も使ってみたい。

Firebase Realtime Databaseを良さげに抽象化する / hiragram さん

speakerdeck.com

Firebase Realtime Database を 良さげに Swift で抽象化した話。

Firebase Realtime Database はでっかいJSONをみんなで読み書きするようなイメージのDB。オフラインで読み書き可能で、再接続時に自動的にサーバーと同期してくれるのがお気に入りとのこと。

Firebase自体は便利なのだが、JSONそのまま扱うとぐちゃぐちゃになりそうで、抽象レイヤー(Repository層)を作りたいと思った。具体的にはモデルをプロトコル志向っぽく定義して、それらのプロトコル使って読み書きメソッドを共通化する。

たとえば RxSwift の Single<T> を返却する fetchAllFromFirebase<T: FirebaseSchemaMaster>() とかを定義して(FirebaseSchemaMasterは今回定義した、Firebaseのモデルが準拠するプロトコルで、マスターテーブルっぽく使う)、その中で firebaseDBRef を使う。

こうすることによって、FirebaseSchemaMaster に準拠しているモデル型は、fetchAllFromFirebase()を呼ぶだけでよくて、Firebaseに関する実装から切り離すことができる。

感想

Repository層を導入したくなった動機として以下が納得感が強かったです。

たしかにテストのこと考えても抽象化しておいたほうがよさそうです。

本筋に関係ないですが tryJSON の値を取得してる拡張すごく直感的で良いので使ってみたいと思いました。

5分で理解が追いつかず hiragram さんには懇親会で色々質問しまくってしまったのですが丁寧にお答えいただきありがとうございました。

FirebaseUIとSDWebImageのコラボでFirebaseStorageの画像を表示する / kboy さん

qiita.com

受託したアプリでFirebase使った。サーバーサイドが書けないのでmBaaS使いたかった。mBaaS の他の選択肢として、ニフティの NCMB を使うこともできたが、今回はプッシュ送りそうなのでFirebase を使ってみた。

手前味噌ですが140文字でいい感じにまとまったので貼ります。

感想

Qiitaに追記されてましたが、本質的な原因は、downloadURL ではなく、 content-type が application/octet-stream になっていたからとのこと。

アップロードの際に content-type を image/jpeg などにすると、 downloadURL をそのまま指定してもいけるとのことでした。

downloadURL() で public なURLが取れるので、アクセス許可周りはいじらなくても大丈夫とのこと ( http://qiita.com/k-boy/items/3d6aa6c26a0c6510320e#comment-e712b0c042bcb5554765 )。

発表しっぱなしではなく、TwitterやQiitaコメントを拾って、本記事にスピーディーに反映していたのが素晴らしいなと思いました。

danger-swift / jp_pancake さん

speakerdeck.com

danger は プルリクエストで人力"you forgot to …" をしないように予めルールを定義してCIでチェックできるツール。

最初にRuby版のDangerがあり、最近DangerJSというのができた。そしてごく最近danger-swiftというのができた。Ruby版は cookpad/dokumi というOSSがベースになっているらしい。

github.com

CI回さずにコンソールからでも実行可能で、GithubからPRの情報を取得してwarn関数で出力することができる。

danger-swiftでは Dangerfile(設定ファイル)をSwiftで書ける。DangerJSを中で使っているぽくて、ステータスは開発中。

感想

danger、話を聞く度に、すごく良さそうという気持ちにはなるのですが、後回しになっていて、そろそろ触ってみねばなという気持ちになってきました。

同じく jp_pancake さんの以下のスライドでは、fastlaneやRxSwiftでの事例も紹介されています。もっとガッツリ使うとどうなるのかも気になるところ。

speakerdeck.com

Natural Language APIとその裏側を覗く / akatsuki174

speakerdeck.com

Natural Language Processing and your Apps というWWDC2017のセッションのざっくりした内容と、裏側で使われている技術について。

developer.apple.com

セッションの内容に、ファーストパーティアプリでどのような活用がされるかという話があった。iMessageアプリで、予測変換で最初サジェストされていなかった語が、Webページを読むにつれ学習されていってサジェストされるようになるなど。

おそらく、固有表現抽出というのを使っている。固有表現抽出というのは、固有名詞、時間表現などをテキストから抽出する技術。 固有表現抽出の活用どころとして、Watsonなどの質問応答システムなどがある。

固有表現抽出とは何か?たとえば、「渋谷で明日19:30から予約できる店を探して!」とチャットボットに送ると、固有表現q=渋谷, 明日19:30を抽出する。

逆に、「昨日あった地震の最大震度、マグニチュード震源地について知りたい」とやると、それに関して書いてある文章から固有表現を抜き出してというパターンもある。

固有表現抽出をするには、知識ベースで規則を定義しまくるか、SVMなどで学習することになる。でもNLP API ではそこら辺考えずに結果だけ使うことができる。

時間の都合上削った内容も含まれている完全版のスライドはこちら。

speakerdeck.com

感想

SiriだけでなくAmazon Echo, Google home, Clovaなどの音声スピーカーの台頭により、音声認識自然言語処理に関してはこのあたりこの先盛り上がっていくことは間違い無しなので、ここらへんのカジュアルな話がアプリ開発者向けにアレンジされている発表は個人的にありがたい感じでした。

固有表現抽出の説明がとてもわかりやすくて、人に説明するときに使いたいなと思いました。iOSDCの発表も楽しみです。

Getting all Enum element. / bannzai さん

speakerdeck.com

Int型の連番のEnumのすべての要素を取得できるマイクロライブラリを開発したのでその紹介。

enumにどういうcaseがあるのか全列挙したり、要素の数が知りたいときに、自分で定義した Enumerable に準拠させれば、 .elements.count でそれぞれ取れるようになる。

github.com

感想

Hashable に準拠していれば使える版のブランチも用意しているとのこと。

github.com

内容自体はシンプルなextensionで、なるほど〜で終わってしまいそうですが、ライブラリにしていい感じに共有する行動力と瞬発力が素晴らしいなぁと思いました。

ちょうど自分のお仕事で関わっているリポジトリでも同じことやっている人が最近いらっしゃったので、個人的にタイムリーでした。

さいごに

f:id:kumamotone:20170903192058j:plain

懇親会ではピザとポテチなどをいただきました。ポテチうまい!

全体的にバリエーションに富んだ発表でとても面白かったです。また参加したいです(毎回言ってる)

potatotips #42 に参加しました (iOSブログまとめ)

potatotips #42iOSブログまとめ枠で参加させていただきましたのブログです。

様子です。クックパッドさんで開催されたのですが手作りポテトチップス以外にも手作りの料理(プロの仕業だとか)がテーブルに並んでおり大変おいしかったです。

では以下発表内容です。

iOS11でのHEVC動画のHLS配信 / YuyaHorita さん

speakerdeck.com

HEVC(H.265)は、よく使われているH.264に比べて圧縮率2倍の映像コーデック。

このHEVCを、HLS(アップルが自社iOS向けに開発した、HTTPベースのストリーミングプロトコル)で配信しようとしたとき、うまく再生できないことがあった。原因はbitstreamがhev1になっていたから。

HEVCにはhev1とhvc1の2つの種類があり、iOS11/High Sierra で再生できるのはhvc1のほうだった。MP4Boxを使うとhvc1に変換できる。

というわけで、iOS11にHEVC動画をHLS配信するときは、bitstreamに気をつけましょうとのこと。

CoreMotionを使って気づいたこととiOS11での新機能 / tattn(@tanakasan2525)さん

speakerdeck.com

CoreMotionは端末の傾きや歩数など、デバイスの動きやそれからわかる人の動きなどを取得できるフレームワークiOS4から提供されているが、iPhone5s以降のコアプロセッサM7以降で大幅機能強化された。

使ってみて気づいたこととして以下のようなことがあった。

  • 情報が少ない
  • プロパティ名がわかりづらい
    • 1例として、xArbitraryZVertical と xArbitraryCorrectedZVertical というのがある。Correctedがついているほうは実は磁気センサを使っており、これを使うとCPU使用率が上がる
  • ドキュメントが改行に失敗してたりして雑
  • I/Fがやる気なくてSwiftから使いにくい

iOS11の新機能にも触れられていました(あんまり更新されてないなという印象)。ほぼ全機能を使ったCoreMotionのサンプルアプリを作ったので、CoreMotionを使ってどういうものが取れるか興味ある方は試してみてくださいとのこと。

github.com

簡単に激安感を表現するライブラリを作りました / hirose_yudai (@yhirose741)さん

speakerdeck.com

NSAttributedString にはいろいろつらいところがある。

  • Dictionary で指定するのがつらい(何があったか忘れる)
  • 型を間違えるとクラッシュして危険
  • NSRange での範囲指定

など。そのため NSAttributedString を簡単に扱えるライブラリを作った。メソッドチェーンで設定できて、使用例として、スライド中では激安感(お店のPOPとかでよくあるやつ)を表現するサンプルコードも紹介されています。

ライブラリは以下で公開されていて、issue、PR、コメントなどお待ちしていますとのこと。でも一番嬉しいのはスターとのこと(それはそう)

github.com

海外カンファレンスに招待された事情 / pancake (@jpmartha_jp)さん

ベラルーシであったMobile Optimized 2017というカンファレンスに行ってきた。招待された経緯はオフレコ。

招待されるまでに、以下のような活動をされていた。

  • 英語でブログを執筆
  • Swift Package Managerなどのオープンソースにコントリビュート
  • ニューヨークのミートアップで登壇

勉強方法として、WWDCのセッションやRealmが公開しているトークを聞いたり、Podcastを聞いたり、Slackでの英語のやり取りというのを挙げられていました。逆に、英会話や、TOEICなどの試験勉強はしたことがない(受けたことない)。

国際カンファレンスでは、英語が得意でない参加者もいたりして、下手な英語でもOKなのでゆっくりはっきり話すことが重要、英語のうまさよりいかにトークに惹きつけるかが重要とのこと。

AutoLayoutのデバッグをちょっとだけ楽にやる / @hiragramさん

スライドは公開され次第追加します(発見できていないだけでしたら申し訳ありません)

Autolayout が矛盾していたりしてコンソールにエラーが出たとき、意味不明でつらい。しかし、

  • View の accessibilityIdentifier を設定
  • NSLayoutConstraint の identifier を設定

しておくとエラーのメモリアドレスで表示されていた部分が、指定した Identifier になって読みやすくなる。

また、unsafeBitCastを使うとメモリアドレスから任意の型のインスタンスを得ることができて、たとえばUIViewにキャストして、背景色を変えるとか、色枠をつけるとかができる。

これを利用して、アドレスを渡すと対象のViewに色枠を付けてくれるLLDBプラグインをつくったとのこと。以下のブログで紹介されています。

hiragram.hatenablog.jp

Swift4 で進化した Range / ezura (@eduraaa)さん

スライドは GitPitch 形式で公開されています。 https://gitpitch.com/ezura/P_Swift4_Range/master?grs=github

Swift3 までの Range は、 Range (0..<5.0) ClosedRange (0...5.0) CountableRange (0..<5) CountableClosedRange (0...5) の4種類だった。Closed〜 は 閉区間Countable〜 はInt刻みとか、離散的な空間を表す。

Swift4 では One-sided Ranges が追加され、 ...i のような、片側だけの範囲指定が可能になった。 (今までは0...i のように両側指定するか、 let greeting = s[s.startIndex..<i] のような冗長な書き方が必要だったが、可読性が向上した) 具体的には新たに PartialRangeFrom (5.0...) PartialRangeUpTo (..<5.0) PartialRangeThrough (...5.0) CountablePartialRangeFrom (5...) が追加された。

また、Swift3まではRangeを表すprotocolがなく、それぞれのRangeは独立した存在だったのですが、Swift4 では protocol RangeExpression が追加され、すべてのRangeが準拠することで、統一的に扱えるようになった。

スライドでは具体的な使いかたも併せて紹介されています(zip(1..., ["🍎", "🍇", "🍐", "🍓"])ができるのは面白いなと思いました)。文字列だけじゃなくてArrayの範囲だとか、発表者のezuraさんは最近、発表資料を作る前に技術的な部分をマインドマップで整理してるとのことで、coggleでまとめたものを公開されていました。併せて読むと理解が深まると思います。

Introducing Feedback Tool - Ajimi / @nakajijapanさん

speakerdeck.com

Ajimiというフィードバックツールを作ったので紹介。誰でもいつでも簡単にという意味合いを込めてAjimi(味見)。

フィードバックは大変。スクリーンショットを撮って→GHE開いて→issueを作る→スクリーンショットを貼り付け→どのデバイスで、どんなバージョンで使ったのかを書く…この一連の動作を自動化したかった。

既存のものとしてbaltoInstabugSupporterKit(DeployGate製)を調べた。共通してSDKがある、画像と動画が扱える、コラボレーションツール(GithubやSlackに投稿する)などの利点がある一方、議論される場所が分離されてしまうという欠点もあり、それらを意識して作った。

GHE、deploygate、Gmazeを使っている。スナップショットを取る機能と、ビデオを撮る機能。ビデオは5秒間撮影可能で、 勝手に gif にしてGithubにアップロードしてくれる。課題に感じていることは、現状誰が投稿したのかわからないこと、GHEを使っているので社外ネットワークから使えないこと。

コードはGithubで公開されています。

github.com

Vision Framework 入門 / Motoki Narita (@motokiee)さん

speakerdeck.com

Vision Framework は、iOS11で追加される、顔認識や特徴検出、画像の分類など機械学習の機能が使えるフレームワーク。同じくiOS11 で追加される Core ML が内部で使われていて、端末単体で動作することができる。

これを使ってバーコードリーダーを作った。 CIBarcodeDescriptorというのを使うとバーコードが取り出せるはずだ、と思ったができなかった。

正確には、バーコードの検出自体はできたのだが、CIBarcodeDescriptorにISBNコードの取得する関数などがあるのではないかと思ったのだが、実際には何も実装がなくISBNコードを取得することができなかったとのこと。ただバーコードの位置と、検出したものがISBNだということは分かっているもようで、ISBNコードの取得自体もそのうち対応される可能性はあるだろうとのことでした。

感想

  • potatotips参加3回目だが、毎回参加してよかったという気持ちになる。今回もとても良かった
  • 司会の @giginet さんが使っていた タイマーアプリのアラーム音がちょうど良い具合だったので、使ってみたいと思ったのだが配信停止されていて悲しみに包まれた
  • また参加したい

気合を入れないと投稿できない

気合を入れないとインターネットに投稿できない。

一方、エンジニアとしては、できるだけ多くアウトプットして、考えを整理することや、フィードバックを得る機会を増やすことが重要と思う。

バランスを取るため、技術の話題に関しては、自分の中でできるだけフィルターを掛けずにpostして行こうと思う。

経験的にすぐにはうまくいかない気がするが、徐々にやっていこうと思う。

twitter.com