iOS 12ショートカットからim@sparqlにアクセスしてクイズをつくってみた

このあいだiOS 12のショートカットを試して楽しかったので、今度は遊べるようにクイズを作ってみた。 完成系はこんな感じ↓。アイマスのアイドル(、他)がランダムに10名表示されるので、身長が149cm以下のアイドルをすべて選択すると、合っているかどうかを表示してくれる。

https://esa-storage-tokyo.s3-ap-northeast-1.amazonaws.com/uploads/production/attachments/9621/2018/09/27/1855/6b48385d-8576-4ace-b7a2-cf84881efeaa.mp4

このショートカットの中身は、下記のアクションで構成されている。このブログエントリでは、ショートカットの配布リンク提供と、ショートカットの中身のウォークスルー解説をする。

f:id:banjun:20180926200311j:plain

うまくオリジナルサイズの画像が貼れなくて読めないと思うので、オリジナルサイズはこっち。

https://img.esa.io/uploads/production/attachments/9621/2018/09/26/1855/aa46e4ad-7205-49a2-8607-c6f58a46ab3f.jpg

ショートカットの入手と実行

ショートカット本体は、iCloudでシェアできる。実際にこのiCloudリンクから入手して、実行したり、なかみを見たりできる。ぜひiPhoneに入れて動かしてみてほしい(App Storeでショートカットアプリを入れておく必要がある)。

im@sparql 身長U149クイズショートカット: https://www.icloud.com/shortcuts/93a3d2a6052048638943300edb80e8a9

なお依存先のショートカットがひとつあるので、下記のショートカットと合わせて2本、インストールする必要がある。

im@sparqlクエリ実行ショートカット: https://www.icloud.com/shortcuts/922ef6fc7366437e8b01659372fe48af

im@sparql 身長U149クイズショートカット のフロー解説

以下、ざっと流れの解説。長いスクショを見ながら追うといいかも?(いいのか?)

f:id:banjun:20180927001540j:plain

テキスト「SELECT...」→ ショートカットを実行「im@sparqlクエリ実行」で、アイドル名と身長のリストをとってくる。400以上の結果が返ってくる。データが充実しているのはim@sparql自体がすごい。「im@sparqlクエリ実行」ショートカットは、別のショートカットの入力に渡して結果を受け取る。さしあたり、SPARQLのSELECTクエリを渡すとim@sparqlから結果を辞書でとりだしてくれるすごいやつ、と認識しておけばよい。

SPARQL自体をどう書くか、については下記のページで解説されているので、そちらを参照。

im@sparqlを組み込んでみる

f:id:banjun:20180927001743j:plain

「リストから項目を取得」→「それぞれで繰り返す」で、ランダム順のあたま10名ぶんを取り出し、なまえと身長の辞書、のリスト、を得る。「辞書の値を取得」は、JSONのキーを辿るやつ。.name.valueになまえ、.height.valueに身長がはいっているので、そう辿る。「それぞれで繰り返す」は、リストのmapであるから、「繰り返しの終了」の直前をみると、map先の値がわかる。アクションの入出力のフローは一直線なので、「繰り返し項目」を二回入力として使うために、途中で「変数を取得」して入力を読みなおしている。

出力はこまめに変数にいれておくと、わかりやすい(変数にいれなくても、各アクションの出力は、マジック変数で参照できる)。

f:id:banjun:20180927001927p:plain

「リストから選択」ではクイズの出題と回答のUIを提供する。この入力は、ユーザーにみせる文字列のリストでないといけない。この制約がけっこう厳しい。辞書を渡せればいいのだが、表示名だけを渡さないといけない。。「複数を選択」にすることで、選択した項目のリストを得られるので、今回のクイズが実現できる。

f:id:banjun:20180927002007p:plain


f:id:banjun:20180927002020p:plain

そのあとほぼ終わりまで続く長い「それぞれで繰り返す」が、答え合わせのループとなる。「リストから選択」の制約で、選択された項目については、アイドルの表示名のリストについてのデータしか持ち合わせていない。したがって、再度、なまえ身長リストをループして、答え合わせをしていく必要がある。

f:id:banjun:20180927002105p:plain

または不正解

f:id:banjun:20180927002651p:plain

「次の場合」はif-else-endifの形式のブロック構造をしている。アイドルごとの判定は「そのアイドルは149cm以下かどうか」×「ユーザーはそのアイドルを選択したかどうか」なので、「次の場合」を2重にネストして、それぞれの4パターンの答え合わせ結果を生成する。「次の場合」も結果を上位のブロックに出力するので、4パターンとも、結果を「テキスト」にして、正解と不正解をもたせる。すると、2重ネストの外側の出力として、「結果が以下の場合」の変数に、正解か不正解かが流れてくる。

f:id:banjun:20180927002121p:plain

f:id:banjun:20180927003229p:plain

f:id:banjun:20180927003729p:plain

[結果が以下の場合] に答え合わせ結果のテキストを絵文字で入れているので、こんな感じの出力になる。×が出たら覚えていこう。

f:id:banjun:20180927002148p:plain

これがアイドル10名ぶんmapで繰り返されてくるので、joinする。joinは「テキストを結合」で、改行区切りを選択する。 最後に「クイックルック」で結果をユーザーに表示してやる。「クイックルック」は、ショートカットを組み立てるときに、途中に挟んで、実行を止めて出力の内容を見られるので、プリントデバッグ的な感じでべんりに使える。

im@sparqlクエリ実行ショートカット のフロー解説

こちらのほうが短いけれど、オリジナルサイズの全容はこちら。

https://img.esa.io/uploads/production/attachments/9621/2018/09/27/1855/932481f7-a32c-4d65-8993-f466f8962652.jpg

SPARQL初心者なので、SPARQLのSELECT書いたらim@sparqlで実行してくれるだけのモジュールとしてのショートカットを作って、試行錯誤しようとして、↑↑のクイズのショートカットから分離したもの。

SPARQLのクエリはPREFIXとSELECTからなるようで、PREFIXはお決まりのものを入れておけば良いかなと思って、SELECTだけ書いたら動くようになっている。

「ショートカットの入力」で他のショートカットから入力をもらう。「次の場合」では、空実行されたときに後段まで実行されて無駄クエリを投げることがないように、キャンセルできるようにしている。ただのキャンセルというのが分からなかったので、[キャンセル][OK]でキャンセルできる、というだけ。

URLエンコードして、im@sparqlのエンドポイントのqueryにくっつける。im@sparqlの結果はJSONで返ってくるようで、辞書にして、お決まりの階層がいくつかあるようなので、results→bindingsと辿って、結果の辞書部分だけをこのショートカットの出力とする。

これで、SELECTを書くだけのショートカットを作りやすくなる。例えば、下記のページで提供されているようなクエリ実行は、こうなる。

https://sparql.crssnky.xyz/imas/ImasIllustTheme.html

f:id:banjun:20180927001333j:plain

このサンプルのショートカットへのリンク: https://www.icloud.com/shortcuts/41d10a57b1e84a03b38914fc95be0d86

おわりに

こうやって、ショートカットでなにかをするときにはこのアクションを使えばいいのかな?、ってアクションの語彙が増えていくと、iPhoneだけでどんどんロジックを組めるようになってくる。iPhoneなので電車のなかでも組める。実際に今回のショートカットのほとんどは、毎日の電車のなかで作成した。 たぶんショートカットはもっといろんな連携のパターンがあると思うから、ショートカットで出来ることの語彙を増やしていきたい。

こんなアクションつかったらきれいにできる、とか、ここは分離して別のショートカットにしたらいい、とか、そういうネタがあったら教えてほしい。

謝辞

github.com

このデータ量よ

nrstudy.connpass.com

このブログ書きました

esa.io

べんり

プリッカソン#5でノンプログラミングやってみた

prickathon.connpass.com

ちょっと間があいて久々のプリッカソンに行ってきた。参加するとアナウンスで、一度休んだから行きづらいということはなく、予定が合ったら行こうかなくらいでいいですよ〜くらいのノリで、と言われていて、カジュアルに参加できて良いのだが、なんだかんだ最近は連続で参加できている。暇というわけではなく9月の忙しさのなかによくうまくはまったなというか.. .

f:id:banjun:20180924003131j:plain

今回やったのは、プリパラDB(仮) + iOS 12ショートカット。このブログエントリでは内部的な解説成分多めで。ショートカットの情報がまだどれくらいあるか分かっていないので。

プリパラDB(仮)側

、、って、今回のプリッカソン参加者はrubyでgemにしていたの?? という話もあった。ruby直であれば最速っぽいが、今回は↑のほうの話。

github.com

ようするにプリパラに関するデータを蓄積していくのだが、すべてをいちどにやるのは無理なので、現時点での関心領域は、キャラとか、アニメの話数とか、曲名とか、アニメに出てきた曲、誰が、とか、そのあたり。しかもプリパラのみ(アイドルタイムプリパラも、まだ)。ではあるが、他のシリーズとか、アニメ以外の情報へ拡張していくのは原理的にはできるはず、、というか、できる構造を狙ってつくっていく、というものだった。

いちどはfirebaseに置いてみたり(つまりほぼjsonで書いて、さらにCloud Functionで整形する方式)、どこかのRDBに置く話の検討もあったが、インフラ側の準備作業がちょっとあるのに加えて、おもに編集作業がつらいのであった。生データを直で触れない場合は編集UIが要るし、データに制約がある場合は制約を設計して、編集者が理解して、あるいは制約をきれいに編集できるUIが必要になり、という感じで、編集にとりかかるハードルが高い。そういうUIがあるのは良いことだが、必須でないほうがありがたい。Googleスプシで書けるくらいで始められたらよい。

webapi-mock-up/pripara-episodes.csv at master · prickathon/webapi-mock-up · GitHub

なかひこくんさんが、githubcsvを置くと整形表示とフィルターがある、と言ってCSV書いてみていた。なかなかよいし、github上にマスターデータがあるということはdiffも歴史もあってよい。firebaseもRDBも、diffと歴史の保存(てきとうにいじってデータ壊してたときのためにバックアップとるとか)は課題として上がっていたし。

なんか、エディタによってはCSVの色わけをうまくやるというのもあるみたい。Vimでもいけるかな?

https://prickathon.github.io/webapi-mock-up/episodes.json

github pagesのJekyllでCSVJSONに変換できるんですよ、というのも見せてもらって、なるほどインフラ不要でよい、と思った。

webapi-mock-up/episodes.json at master · prickathon/webapi-mock-up · GitHub

その実装をみて、なるほどJSON変換、とは・・・?となったが、別インフラも別な生成スクリプトの実行もなくて済むし低コストだし、ありよりのあり。 (そういえば頭の角ブラケット...)

webapi-mock-up/pripara-lives.csv at master · prickathon/webapi-mock-up · GitHub

webapi-mock-up/lives.json at master · prickathon/webapi-mock-up · GitHub

というわけで、アニメの各話に出てきた曲が、どの曲で、誰が歌ったか、を引けるようにするために、CSVを書き足して、JSON APIをつくってみたのがこれ。書いてるのCSVとテンプレートだし、プログラミングとしてはノーカンでいいよね。

iOS 12ショートカット側

iOS 12でショートカット (Workflow) のアプリがいい感じになっていて、リリースとともにさっそく使ってみた話をタイムラインでよく見かけるようになった。そんなに意味のあることはできないのかなと先入観を持っていたが、わりと高度なことまで出来るようだったので、興味が出てきたので、プリッカソンで調べてやってみようと思った。

知識ほぼゼロでアプリ起動してショートカットで使えるアクションを検索すると、JSONを辞書として扱えるようにするのがあった。その入力までは、URL → URLの内容を取得 → 入力から辞書を取得。ドラッグドロップで並べて、アクションの設定値をいれていく。

f:id:banjun:20180924115904j:plain

残念ながらCSVを読めるアクションはなさそうだった。Swiftクライアント書くならCSV直でもJSON APIでもクライアントサイドジョインがあってもまぁなんでもいいかなという気持ちもあったが、ショートカットで実現することを考えると、とりあえずJSONになっているだけでもありがたい。さっきのJekyllが役立っている。

f:id:banjun:20180924120234p:plain

キャラクターのJSONをとってきて、そのキーのリストをユーザー選択のアクションシートに出して、そのキャラの情報を引いてくることができる。ここでの未解決課題は、キーではなく名前を出したいのだが、リストから選択アクションでは、選択する値そのものしか表示できないらしい。キーをそのままユーザーにみせるしかない。

f:id:banjun:20180924120512j:plain

触ってみてわかってきたのは、いちいち結果を変数に名付けておくと分かりやすいし、フローを切って次のフローを始められるのでよい。日本語もつかえるので、選択したキャラの「なまえ」と「チャーム」を保持しておいて、「[なまえ]は[チャーム]ね」というフォーマットで結果表示できる。わかりやすい。いかにもプログラミング入門めいてきた。「らぁらちゃんがショートカットで◯◯を作る本」だれか書かないかな?

次に、曲名を選択すると、それが歌われたアニメの話数を表示するショートカットをつくってみる。入力はsongs.jsonをみる。

f:id:banjun:20180924121023j:plain

jsonのキー一覧を、「それぞれで繰り返す」で、jsonから値取得してnameをとる、ことは、曲名のリストを得ることになる。つまり「それぞれで繰り返す」はmapのことである。これでキーのリストではなく曲名のリストでユーザーに選択させられるのだが、さっきの未解決課題のとおり、選択されたキーがなにか、というのは失なってしまう。しかたがないので、曲名に重複がないことを利用して、もう一度繰り返しで、選択された曲名と一致するところだけを処理する。 概念的には for 曲辞書の値 { if 選択された曲名 == 曲名 { ... } } みたいな。

f:id:banjun:20180924121613p:plain

ifに相当するのが「次の場合」のようだ。「次の場合に終了」までのブロックが生成されるが、これは日本語だから分かりづらいのかなぁ。英語みてないけど、endif的なものだと思われる。ネストが深くなると余計にややこしくなるので、ifが成立したときに変数にいれておくだけにして、フローを切るとよさそう。

これで選択した曲情報は得られる。このうえで、songs.jsonJSON API側(Jekyllによる)でjoinされているlivesをもってくる。なぜlives.json側から引いてきていないかというと、、、これも未解決課題で、filterやuniqueの操作をショートカットでやる方法が見つけられていないから。だからAPI側で、やりたいことに合わせてjoinをしておかないと難易度が変わってしまう。Swiftクライアントならどっちでもよさそうなものだが(クライアントに書くかAPIサイドに書くかの違いのみで、ある特定のクライアント都合のユースケースAPIサイドに書いていいものか問題はある)、ショートカットでは、クライアントでつらい仕事はAPIサイドに書くのが正解かもしれない。

f:id:banjun:20180924122127j:plain

結果表示はリストを埋め込んでも改行で表示される。機械的に改行されている感じが、プリパラ世界の「システム」である、めがねぇっぽくてこれはこれで良い。空を判定して分岐はできるようだったので、見つからないときに別のメッセージを出すのもできた。

f:id:banjun:20180924122411j:plain

f:id:banjun:20180924122414j:plain

リストから文字列へは好きな区切り文字で結合できて、こうするとより人間的になる。

f:id:banjun:20180924122623j:plain

ショートカットは当然にSiriのフレーズを設定できるので、「この曲いつのだっけ」で起動できるようにした。いま再生中の曲名も取れそうなので、曲名一致をどうにかクリアすれば、再生中の曲からもいけそうである。

あとはデータの充実で、ここのcsvを充実させてくれる協力者がいれば、、、という感じ。プリ☆チャンは毎週データ増えていくし、プリ☆チャン用も同様にして誰かつくりませんか? どうですか?

webapi-mock-up/pripara-lives.csv at master · prickathon/webapi-mock-up · GitHub

成果物

このショートカットは、iOS 12で↓のリンクからインストールできる。もちろん中身の実装がみられるし、編集もできる。

https://www.icloud.com/shortcuts/384204a915a1429db3e7d2a1c21ba0f7

ノンプログラミングで、できました。

所感

ショートカットをやっているとMacBook Proは必要なかった。iPhone上でドラッグドロップを精度よくやっていくだけ。もちろんどこでもできるので、↑のテキスト結合あたりは、帰りの電車で見つけて実装した。べんり。ショートカットのシェアーができるのも良い。どこかにアップロードする場所を用意する必要もない。ハッカソンだと、iOSアプリって作ってもすぐシェアーできないので(TestFlightだとしても審査に1日かかってしまう)、そういう意味ではアドバンテージが高い。ただ、シェアーしたショートカットをどう残していくかと、どうバージョンアップしていくかは、課題。ツイートでいいんだろうけど、流れていくし、かといって、つくったショートカットの一覧ページみたいなのつくるのも、ちょっと作業がいるかなぁ。

プリッカソン会場はここ数回はサポーターズの広い会場で、いつも快適で良い。参加人数もじわじわ増えている。わたしはプリズムストーンのコスプレ参加(?)だったけど、サポーターズのコスプレ参加(?)のひともいた。

f:id:banjun:20180924124417j:plain

成果発表のあと買い出しして懇親会。参加者みんな(論理)女児だしアルコール買わないので安いというのもあるが、前回よりさらに安く済み、一人300円となった。遠足のおやつレベルでは。

次回はまた予定があえば参加、今度はもっとプログラミングしようかな。connpassページから辿るとSlackもあるので気になっているおともだちもぜひ。よろしくお願いします。

iOSDC 2018 に参加して登壇してきた

f:id:banjun:20180907230358j:plain

パンフ,うれしい。

プロポーザルと登壇

iOSDCには2016,2017と参加してきて3年目,初めてプロポーザルを出した。30分枠とLT枠と出して,30分の差分更新のトータルパフォーマンスのほうが採択された。VFLの話もしたかったな...?

5000行のUITableViewを差分更新する by ばんじゅん🍓 | プロポーザル | iOSDC Japan 2018 - fortee.jp

https://fortee.jp/iosdc-japan-2018/proposal/3ae8b788-8df5-4f1e-8862-7c5170a14d36

今回プロポーザルを出したのは,そろそろ勉強会慣れもしたし喋れそうかな?と思ったのもあるが,まわりで,プロポーザルを出す,いくつ出す,15分と30分と両方出したほうがいいらしい,みたいなプロポーザル提出時点での盛り上がりがかなりあり,雰囲気に釣られて出した部分も大きい。つまりノリである。 年間の大きめのカンファレンスというとtry! SwiftとiOSDCとあるが,どちらかというとiOSDCのほうが好きなことを喋っているという要素が大きい印象がある。言葉にしづらいが。

f:id:banjun:20180907234857j:plain

photo by mzp

f:id:banjun:20180911224529j:plain

photo by iOSDC Japan: iOSDC Japan 2018の写真を公開しました - iOSDC Japan スタッフブログ

登壇自体は緊張したのもあったが,30分喋り続ける体力のほうがつらかったかもしれない。iOS界隈でこれ以上大きいハコで喋ることはなかなか無さそうだし,いまできる範囲でいちばん経験値積めそうなことが出来ました(レベルアップ)という実績解除っぽくてとてもよい。

f:id:banjun:20180908001425j:plain

登壇中と前後はワークアウトにして心拍数をとっていた。ライブとおなじ。それなりに高い。なぜか10分くらい喋ったところが高い。

資料とまとめ

トークの内容的には,UITableViewの差分更新がなにか知らないところから入ってもメリットが分かるようになっていて,ほとんどの場合はライブラリを入れるだけで利用できるけれども,大きな行数の場合には遅くなってしまうかもしれない,そういうときにパフォーマンス解析するにはどうしたらいいだろう?という流れになっている。パフォーマンス向上ネタをいくつも持っていても,ボトルネックがそこにあるかどうかというのは勘で当たったり当たらなかったりする。Instrumentsで見れば事実が分かる。知らないボトルネックが登場したら,それはSwiftの内部や,UIKitの特徴を新しく知ることになり,それはそれで知見になる。そういう手段も持ち合わせておくと気が楽になるし,差分更新をどんどん使っていけたら良い。

speakerdeck.com

togetter.com

YouTube配信もそのうちあるはず?

実況の様子を後からみるの楽しい。まとめてくれたかっくんありがとう。 登壇で言いたいことってなかなか言葉で伝えづらいものだなと感じたが,ツイートをみるときれいにまとめられていて,そう言えばいいのかみんな賢いすごいと思いながら読んだ。

記述ミスへの指摘を実況+Q&Aでしてくれた方もいて,もやっとしたままにせず共有されたのは良かった。(speakerdeckはその後修正して更新した,はずだが,反映されてないかも...)

Ask the Speakers

そうか登壇するとAsk the Speakersもやることになるのか~と感動していた。来てくれた方は本当にありがとうございます。うれしかった。 人がこないときは並行しているセッションのスピーカーと喋ったりというのも良い機会だった。

登壇練習

いままでの他の登壇では発表練習らしい練習をしたことがなかったが,今回は2回発表練習をした。社内勉強会での発表練習と,Timersでの登壇練習会。

mokumoku-ebisu.connpass.com

つきあってくれたみなさんには感謝している。特に,Timersで,他のスピーカーの練習をレビューする側で4時間くらい(??)やっていて,これは聴いてフィードバックするというのは大変なことだなと実感した。 フィードバックはそれ自体が良い影響があるが,発表練習がなによりも良いのは,その期日までに進捗が出る,ということで,これは助かった。さすがに作らずに練習はできない。技術的内容とか構成以外だと,どこが意外とウケないとか,ここ意外とウケるんだ,とか,そういうのが役に立った。録音しておいたので後でどのスライドが何分くらいか分かるし,自分の発表を聴くことで,喋りの反省と喋る内容を記憶するのに,役に立った。

もくもく会で資料準備

茅場町モバイルアプリもくもく会 #2 - connpass

7月から, @shiozaki_study さんと,もくもく会の主催をするようになったので,そこでも登壇資料を作っていた。Instrumentsのスクショを集める作業が意外と難しくて何度かやりなおす必要があったので。もくもく会だから,コードを書かなければならないということはない。が,コードを書いて進捗だしている人たちが楽しそうだったので,やはり今度はコード書けるように準備をしておこうと思いながらスクショ作業をした。また9月も開催するのでぜひ来てね(いつも参加枠が一杯になってから宣伝してしまうやつ...)。

茅場町モバイルアプリもくもく会 #3 - connpass

iOSDC当日のいろいろ

トークセッションが並行でいくつもあるので,選ばなければいけない。Interactive Round Table (IRT)もあり,アンカンファレンスもあり,スポンサーブースまわりで喋るのもよし,Ask the Speakerも行きたいのあるし,どこに行くべきか。聴かなかったトークも良いものであるという情報が流れてきて,やはり・・・あとでチェックしなくては,となる。まるでWWDCのときのように,どんどんとチェックすべきタスクが積まれていく,というような話を聴いた。なるほどその通りである。

アンカンファレンスの自由さもよい。(わいわいswiftcに行った)。休憩時間ごとに,「フリーのIRTもひとつ用意してあります」ってアナウンスされてると,これは何かテーマを出したらいいんじゃないかって思いをめぐらすことになるのもよい。macOSの話をするまでには至らなかったのだけれど。予定されていたIRTのなかでは,autolayout/storyboardに行った。Visual Format Languageこそ至高。時間がいくらあっても足りないのでは感があった。VFLの項目だけネタとして出して,登壇の時間なので登壇してきたら,VFLネタそのあとのIRTで拾ってくれていたらしい。

f:id:banjun:20180907234643j:plain

それとは別に,コードレイアウトアンケートがあったのでVFLの領域を書き足しておいたのだが,増えていたらしい・・・一体誰なんだ・・・。

f:id:banjun:20180907235017j:plain

ある日の朝はドーナツが置いてあった。すくなくとも私が辿り着いたときにはフレンチクルーラーはなかった。

f:id:banjun:20180907235200j:plain

ある日の朝は野菜になっていた。

macOS nativeシンポジウム

なぜか,たまたま,iOSDCに隣接して,macOSネイティブ勢のシンポジウムがあった。たまたまなのでiOSDCの話に混ぜるのは不自然かもしれないが,なぜかたまたまなので混ざることもある。iOSDCのオープニンの懇親会とかぶっていたが,レアリティという意味ではmacOSネイティブのほうが高いので,これに参加していた。

macos-native.connpass.com

macOSネイティブ勢はすぐ昔話になりがちという印象があるが,シンポジウムのトークはむしろ,歴史を観察・分類し,現時点ではこうなっている,という話の傾向だった。いま作っているmacOSアプリをどうするか,これから作るものはどうするか,という視点で勉強になった。

とはいえ懇親会で老人会のようなネタ振りをして盛り上がってしまったのも事実で,Instrumentsの前って何をつかってましたっけ?みたいな話が出来る場があって本当に楽しいなと思った。

なぜ60人キャパに対し30人しか集まらないのか・・・。みんなmacOSアプリ使ってるはずだし開発環境も既に整っているはずだし,もっとネイティブアプリ自作しようよ。

おわりだよ~

f:id:banjun:20180907234747j:plain

f:id:banjun:20180911230111j:plain

次は俺コン&リジェクトコンで。聴きたかったトークあるから楽しみ。iOSDCで話せなかった人とも話したい。話しかけてくれるとうれしい。。

iOSDC Japan 2018にbanjunから1名が登壇いたします

最近は白桃&ベリーのハーゲンダッツジューシーバーが当たりだと思っているばんじゅんです。今年のiOSDCのレギュラートーク(30分)に採択されたので登壇します。iOSDCに初めてCfP出したところ30分枠もらえてしまったので,がんばります。

5000行のUITableViewを差分更新する by ばんじゅん🍓 | プロポーザル | iOSDC Japan 2018 - fortee.jp

9/1(土)の 14:20〜 Track Aです。ぜひチェックしてみてください。

f:id:banjun:20180819202816p:plain

UITableViewの差分更新の仕組みとは?既存アプリに導入したときにパフォーマンスが出ない場合,解析して対策するには?どこがボトルネックなのか?何を諦めるのか?というような内容になります。Instrumentsは好きですか?

f:id:banjun:20180819204154p:plain

お話しする知見のいくつかは(実験的な)差分更新ライブラリに実装されています。 GitHub - banjun/BigDiffer: diff & patch for UITableView with large number of rows (changes between 0~5000)

関連トーク

宣言的UICollectionView by ishkawa | プロポーザル | iOSDC Japan 2018 - fortee.jp

差分アルゴリズムの原理について by horita-yuya | プロポーザル | iOSDC Japan 2018 - fortee.jp

差分計算アルゴリズムを用いた高速なUITableView描画 by fumito-ito | プロポーザル | iOSDC Japan 2018 - fortee.jp

差分更新流行るのかなーと思っていたところ,やはりというか,iOSDCでもいくつも差分更新が関係するトークがありそうです。

あっここは時間がかぶっている・・・なやましい・・・

f:id:banjun:20180819202702p:plain

差分更新のまわりの話もいろんなエリアがあり,私のケースではトータルの更新パフォーマンスにフォーカスしているので,関連するトークと合わせて補完的に,別な視点も提供できるはずです。

トーク後はAsk the Speakerもあるようなので,喋りにきてくれると嬉しいです。 iOSDCでみなさんといろんな話ができるのを楽しみにしています。

IM@S Engineer Talksで喋ってきた話のメイキングのおはなし #imas_hack

imas.connpass.com

IM@S Engineer Talksの30分枠で喋ってきた。 ライブのときの心拍数のログを取っているので,BDの再生と合わせて表示するアプリの話。ドキドキしているのはどの曲だったのか?

f:id:banjun:20180713211724j:plain:w480 f:id:banjun:20180713211959j:plain:w480

スライド

かわいいを支援するAppleハック,そして💓で振り返るシンデレラ5th / Apple hack assisting kawaii & Replay Cinderella Girls 5th LIVE with heartbeats - Speaker Deck

YouTube Liveのアーカイブ

IM@S Engineer Talks - YouTube

trebyさんに「今度長めに喋りませんか?」という話をされてから数ヶ月たち,ほんとに喋る機会をもらえたので,じゃあやるぞということで,追加の実装とかしつつスライドを作った。そのときの話を書く。

狙い

いつものLTのノリで作るとカタイ30分になるかもしれないと思い,遊びを入れていこうとしていた。最初に書いた,やりたいネタメモ:

  • そろそろスライドマスター変えたいけど
  • サブタイトルスライドは,しんげきのアイキャッチみたいな文字にしたい
  • サブタイトルスライドの端に,ありすの絵をいれていくか?
  • PhotoStudioPlayerありす付きにする?あとで出す?
  • 盛り上がり箇所いれたい

スライドマスターは最初にLTしたときにアクロスザスターズ風のヘッダーを置いて,そのままどこに出すときでも使っている。のでそろそろ変えたかったが,時間がとれなくて今回もそのままになった。でも他の項目は実現した。

アイキャッチ

f:id:banjun:20180713222552p:plain:w480

シンデレラガールズ劇場のアニメのアイキャッチがシンプルでかわいくて気に入っているので,スライドの区切りにいれる文字だけのサブタイトルスライドを,そういうテイストにすることにした。

f:id:banjun:20180713222620p:plain:w480

この背景かんたんにできないかな~と手元にあったPixelmator Proの機能をいじっていたところ,背景はGenerate系のフィルターのみで作れたので,そうした。ストライプをつくって傾けて星を置くだけ。パラメータをいじっただけで出来てしまった。

f:id:banjun:20180713223103p:plain:w480

Keynoteだけではフチが太い文字を作るのが難しいので,これもPixelmator Proでつくった。FillとStrokeで同じテキストを入れて重ねている。FillとStrokeを同時に設定したときの重ね順が,欲しい順序と逆なので,2レイヤー必要になってしまっているのが,おしい。

サブタイトル文字だけじゃなくてイラストもあったほうが明るくなると思う。ちょうど最近描いていた絵がいくつかあったので,それを使うことにした。足りない分はアイコン描いたときのものを持ってきたりした。目立ちすぎないように明るさを調整している。

これらのイラストはProcreateとApple Pencilで描いている。Procreateなので,イラストのメイキング自体はタイムラプスで録画できている。

imastodon.net

imastodon.net

登壇したあとで,イラストかわいいって言ってもらえて,とっても嬉しかった。

PhotoStudioPlayerでありすを出す

PhotoStudioPlayer (デレステフォトスタジオのリアルタイム透過プレイヤーをつくった - ツバメになったバリスタ) の話も少しだけしようと思い,でも新規ではないので長い話にしないために,デモを兼ねて,途中からスライドと一緒に表示しておくことにした。

そのままではKeynoteのプレゼンモードの上には出なかったが,id:mzp がそれより前面に出すようにPRをくれたので,Keynoteの上に出した。

Release 0.8.0: Front Row · banjun/PhotoStudioPlayer · GitHub

盛り上がり箇所をつくる

imas_hackのLTでは,ペンライトを振ったりUOを振ったり,急に \かわいい!/ コールがあったり,ということが起きる。 前回のLTでは,PhotoStudioPlayerでありすを出したときにいろんなコールをもらって楽しかったので,今回もやってみたいと思った。発表順2番目で最初のほうだし。おそらくライブ慣れしているみんなも声を出したいのだろうと思う。声出したいよね?

ちょうどその週にひなたが誕生日だったので,画面に大きく出して,おめでとうを言ってもらった。みんな優しい。。。本当にありがとう,ありがとう。

そしてPhotoStudioPlayerでありすを出すところ。流れで,はい出ました,ってやるよりも,みんなで呼び出してみたい。「せーの」\\ありすちゃーん// で出せて,楽しかった。とはいえもうちょいスムーズに出せるように準備しておいたらよかった。

他のこまかいこと

そんなふうに作っていたら楽しくなってきて他にやったこと

スシロータイムライン

f:id:banjun:20180713230210p:plain:w480

これは今回作った,ライブフォトの歴史に関して世界で一番情報濃度の高いタイムライン。

f:id:banjun:20180713230826j:plain:w480

3軸の流れを並行して見せたかった。進んでいく形式のUIといえば,デレステの「ススメ!シンデレラロード」イベント(通称「スシロー」)。 というわけで,それっぽいブロックを並べた。ブロックの色には特別な意味はなくふんいき。Keynoteで四角シェイプをeditすると平行四辺形にできるのでちまちまとコピペして並べた。

Keynote+Apple Pencil

f:id:banjun:20180713231530p:plain:w480

他の勉強会で,iPadKeynoteだとApple Pencilで直接絵を描きこめるというのをみたので,いくつかのページはそれで描いてみた。 特に,自由な矢印を描くときには,スッと描けていい感じだった。iCloudで共有しておけば,ほぼ,同時というか交互に,Macで編集し,iPadで描きこむ,というのができた。

会場やtwitterハッシュタグでいただいたフィードバックなど

メイキングはここまで。

登壇して,たくさん質問&フィードバックをもらえて嬉しかった。ありがとうございます。

  • 心拍数グラフ側から再生位置指定したい
  • AppleScriptでは出来ないか?
  • YPTとか絶対特権とか終わったあとに心肺止まっているのでは?(グラフがないところがある)
  • CNNが必要では,ない,よね
  • 心拍数だけじゃなく加速度とかとって,動いてないのにドキドキしてるとか分かるかも
  • みんなの心拍数をシェアしたら,みんな高いところとか,みんなが高いのに自分が低いとか,みえそう
  • 絵がかわいい
  • (就職したら) Watch買います
  • どうして心拍数をとりはじめたのか

さらにフィードバックありましたらぜひ: https://quesdon.rinsuki.net/@banjun@imastodon.net

どうして心拍数をとりはじめたのかについては,たしかになぜ・・・,と考えてしまったが,記憶がガバガバで分からなかった。 日記などを掘りかえした事実からは,シンデレラ4thではワークアウトにせずに心拍数アプリで取れたぶん(=取りこぼしの期間が長すぎる)でチェックしていて,年を明けて2017年から,ワークアウトで記録しはじめていた。

そして残りのツアーBDの確認へ

imastodon.net

翌週には5thの静岡のBDが届いた。これも「頭にYPT」の心拍数パターン。まだまだ残りも届くので楽しみ。

プリッカソン#4でコーデを身体に映しだしてみた

prickathon.connpass.com

今日もプリッカソン行ってきた。U149の応募はがき今日の消印必要だなと気付いて,渋谷駅ダンジョンを迷いつつ消印確認してからの遅刻。

f:id:banjun:20180618000305j:plain

動画処理,画像分類,データAPI化,webpack静的配信化,vue化,AR,マップ,ゲーム+絵,楽曲アレンジ,など,いろんな領域での活動がされていてよかった。(プリパラ多様性がry)

今日はなにをやろうかと着いてから考えていて,Pripara-DBが若干手詰まり感はあるなぁとか,なかひこくんちゃんに分けてもらったらぁらLive2DモデルをAR顔認識と組み合わせた進捗をみせつつもモーションの作りかたが分からないしAppleによりOpenGLのdeprecate宣言が出るしということで,もうひとつ話題にしてたネタの,PoseNet的なやつで姿勢推定してコーデをオーバーレイするやつ,というのに着手することにした。

github.com

PoseNetはここにあり,ブラウザ(ブラウザを選ぶ)デモもある。 Core ML化した記事はQiitaにあった。ありがたい。

qiita.com

まずはこれをベースにつくるが,Core MLモデル以外のブラックボックスは減らして,活用できる自由度を学んだほうがいい,と考えてモデルファイルを新規プロジェクトにいれてVision.frameworkと繋ぐところから。ちなみにVisionのリクエストにすると,Core MLの入力のシェイプ(というかここでは画像で337x337)は,Visionで処理されるのでスクラッチの手数が減る(CVPixelBufferでリサイズをしなくてもいい)というとがわかった。

PoseNetの出力は3次元MultiArrayが4つでてくる。謎が多い。

  • そもそもクラス分類しかまともにみたことがないので,MultiArrayがなにを表すときに使うのか謎
  • VisionのRequestでは,4つ出てくるArrayの順序が謎。Core ML定義通りの順序ではないし,辞書ラベルも失なわれている。シェイプ違いは「見れば」わかるが,そもそも順序が違う意味がわからない
  • どうやらいくつかの後処理をかけないと,関節の座標すらとれないようだ。必要なものを順にiOS化されたときのプロジェクトから拾ってくる。結局内容詳細は不明のままだが,これがないと始まらないようなので。 GitHub - infocom-tpo/PoseNet-CoreML: I checked the performance by running PoseNet on CoreML

これで顔のポイントや,肩・肘のポイントは取れる。顔の鼻の位置と,目の間の距離をつかって,らぁらの顔を当てはめた。シェイプを合わせるためにスケールしていたり,カメラは回転しているしプレビューレイヤーは伸び縮みしているし,間違えていると思っていないaffine transformの一箇所が間違えていて,顔を置くのに時間をかけてしまった。しかもARKitのフェイストラッキングより相当にブレブレの結果しか出ないという。

さて顔だけでは精度的にも勝利にならないので,腰をつかっていく。どうやら顔や肩や肘とは違い,肩からさらに関節を辿っていかないと見えない構造の先に腰があるようだったので,そのコードももらってくる。そうすると,腰がみえているときは左右の腰の位置がわかるようになる。

結果はこんな感じ。ウィッシュリボンアイドルコーデすき。

f:id:banjun:20180618004327j:plain

f:id:banjun:20180618004332j:plain

しかし顔の位置と同様に腰の位置もブレブレであり,写っているほとんどのフレームでは間違った位置にあるようにみえる。 さらにアングルを連動させてみたりすると,ブレブレ感が増していくので,あまりなにもしないほうがいいのかもしれない。 何枚も撮影するといい感じの写真がとれるという具合なので,成果発表では,たくさん撮ってもらっていい感じにハマっているのを成功例として使ってもらうようにしたというものだった。

githubレポはこちら。一部画像リソースは含めていない。

github.com

振り返るとあやしい処理をしているところはありそうだし,精度はまだ上がるかもしれない。が,それでも画像上の二次元座標がとれるだけだと,身体がどちらを向いているかという情報は使えないかもしれない。ARKitで顔認識してその向きをつかったらどうかというアドバイスももらった。たしかに顔についてはARKitのほうが格段によさそうという印象だった。顔と身体の向きは違うかもしれないというのはある。 新しい領域の知見は得られたし,見た目にわかる系のものなので説明しやすくてよかった。

tweetとか

他のいろいろ

今日も会場はサポーターズの広い部屋で快適だった。プロジェクターが(持込みで)2台になったりして,広さを活用しはじめた感がある。

f:id:banjun:20180618000144j:plain

そしてついに,プリッカソンのステッカーが作られて配布された。MacBook Proに貼っているなかでもかなりかわいい。かわいいけどスッとしたシルエットでクール。スケート靴のPとかセンスの塊かと思った(スケート靴の時代のプリティーシリーズまだみてない。まずRLみなきゃ)。

f:id:banjun:20180618004835j:plain

懇親会はピザピザポテトピザ。梅干しはのってない。

プリッカソン第3回やってみた!

prickathon.connpass.com

アイドル×ハッカソンアイマスハッカソンだけじゃない,プリパラハッカソンも(本当に)あるんだ,ということで,第2回につづき2回目の参加をしてきた。

f:id:banjun:20180521002542j:plain  道中のコンビニでプリパラっぽいおやつを探す。梅ののど飴とパクチープリッツ。時間ぴったり。

f:id:banjun:20180521002606j:plain  会場はサポーターズの広い会議室。主催の@takanakahiko さんが遅れているということで,プロジェクター接続確認とかを。ホワイトボードがあるが絵もなにもない!なかったら描くしかない!ということで描いておいた。この1ヶ月くらい,夜はコードも書かず(ハッカソンの準備すればいいのに・・・),pixiv senseiやってたからな・・・1ヶ月でやれば有料会員も1ヶ月で済むとかそういう。 ぼちぼち人が揃って自己紹介タイムして,日曜なのでプリ☆チャンをみる。あにてれ最高。

ハッカソンのネタは,前回に引きつづきで im@sparql インスパイアのプリパラDBを進められそうな雰囲気だったので,ネイティブクライアント側の続きから攻めてみる。 Firebase最近ちょっとチェックしたこともあり,どうやらjsonにRESTアクセスするよりも,Firebase SDKから触るほうが,異なるパラダイムを体験できて正しいということのようだったので,それを試してみる。 クライアント機能としてなにを実現するか,というのはネタ出しも難しいので,DBをFirebase SDKでみられるようにする,という素振りをやることにした。

Access to Firebase Realtime DB by banjun · Pull Request #1 · prickathon/PriparaDB-song-ios · GitHub

Realtime DBというとおり(なのか?),リクエストを投げておけばDB側が更新されたときに自動的に更新内容が再取得されるようになった。さすがFirebaseの力という感じがある。DB側はまだ手でJSONを書き足していたけど,追加するとiOSアプリ側に降ってくるのに良さがある。プリパラのサブタイリストに各話を追加すると,謎の仕組みによりiOSアプリ側が勝手に再描画される。 自動再描画は通信部分はFirebase SDK,データ保持はReactiveSwift,差分更新はBigDiffer,ということで,新規要素はFirebaseのシンプルなところだけで,他は迷いなくいける。BigDiffer最近つくっておいて便利だった。マルチセクション差分更新やれるし。GitHub - banjun/BigDiffer: diff & patch for UITableView with large number of rows (changes between 0~5000)

Firebase SDKの返り値自体はSwiftyJSONぽさのある型の期待できない,Codable JSONよりだいぶ劣るダサさがあったのだが,誰かやっているだろう・・と探すとCodableFirebaseというのがちょうどリリース更新されていたので,それを噛ませて,困ることはなかった。 GitHub - alickbass/CodableFirebase: Use Codable with Firebase

f:id:banjun:20180521002625j:plain

 実際のところは,クライアントで,リアルタイム更新反映が必要なユースケースは,ゼロかもしれない。そのへんが,ただのRESTのほうが単に便利なのではという気がしなくもないという迷いが残ったまま。 Firebaseではクライアントサイドジョインをするのです,という話もみたので,シリーズ名(=セクションに表示している,「キラっとプリ☆チャン」「プリパラ」)を引いてくるところを,UITableViewのセクション表示をトリガーに(=lazyに),シリーズのキーからFirebaseにリクエストして取得,という練習もしてみた。そもそも速すぎて効果は謎だし,たくさん同じリクエストしたときにキャッシュされたりするのだろうか,とかも未調査のままである。

Firebase Realtime DB側もちょっとだけ。orderbyとかフィルタにはindexを貼るといいというログが出るとか,そもそもRealtime DBはorderとフィルタは重ねられないとか,そういう知見を得ることとなった。indexのルールをbolt書こうとしてハマりまくったPRたち。やたらかわいい。

enable query by series on episodes by banjun · Pull Request #1 · prickathon/priparaDB-firebase · GitHub

index should be placed in path in bolt by banjun · Pull Request #2 · prickathon/priparaDB-firebase · GitHub

Fix: boltから生成されたルールで$...keyが二つになるとデプロイできない by banjun · Pull Request #3 · prickathon/priparaDB-firebase · GitHub

indexの位置を/episodes直下に上げる(pathの数自体を増やさずに) by banjun · Pull Request #5 · prickathon/priparaDB-firebase · GitHub

前回のハッカソンは2ヶ月前,ちょうど,プリパラ最終回の前の日曜日だった。今回までのあいだにはプリパラが終わりプリ☆チャンが始まりプリパズが終わり映画が始まり・・いろいろあったが,プリ☆チャンと並行して,Vtuberが流行りVR出社が流行り(?),周辺界隈は技術的にも見どころが多い。このへんの技術を組み合わせていくとプリ☆チャンの時代にはマッチしそうだが・・・調査とか準備次第かな・・・。

おまけ: 会議室の入り口ではSuicaレッドブル買えてちょうべんり。

f:id:banjun:20180521002643j:plain  とても快適な会場だったので次も貸していただけるならやりたい・・・!が,会場キャパに対して人数が足りていないのはもったいない。。次はここを(アイドルで)いっぱいにしてみせます!ってやりたいね。