ツバメになったバリスタスマートフォン用の表示で見るツバメになったバリスタ2019-12-18💝PrismDBとかプリッカソンでやってたことばんじゅんです。最近は「原宿駅からすぐ近くの表参道」でお仕事をしています。2019の18日目の記事です。昨日はやっちさんの「真中のんさんの魅力について」でした。方は是非こちらも読んでみてください。プリッカソンはプリティーシリーズにまつわるものづくりコミュニティです。takanakahiko.hatenablog.comわたしは今年は4月・7月・10月のプリッカソンに参加しました。今年はPrismDBをネタにした活動が多めにしていたので,PrismDBとその周辺技術の話をざっくりまとめようと思います。ブログにもしなかったし。私がやった作業の話というよりは,私の作業とその周辺で起きていたことのお話ということで,実際の立案や開発編集はここのコントリビューターの方々やその周辺でアドバイスをする人たちによるものです。プリティーシリーズのキャラクター・アニメ・楽曲・筐体があるお店・筐体のアイテムがまとめられるべく,データが追加編集されていっている。プリッカソンのようなイベントで,キャラクターの名前一覧が欲しいときに使うというようなシンプルな利用から,SoLaMi♡SMILEがアニメ中でライブをした話数とそのときのコーデと曲を一覧を取得するような利用もできるように想定している。(現状ではアニメ中のコーデのデータは足りていないと思われるが原理上は・・・!協力あるとうれしい)現時点では元データはgithubで管理されている。UIで見たり,SPARQLのクエリを投げたり,RESTで取り出せる。現時点で35キャラクター・106楽曲・300エピソード・227ライブ・2983アイテム・2289店舗が登録されている。ところで今年のライブはマイパマ、マイパマ、マイパマ、マイパマ、オオサカプ、マクパリに行きました。sketch.pixiv.net/items/3898127405622949419PrismDBの変遷ハッカソン系のイベントでなにかサービスを開発しようとしたときに,作品の基本情報が既にまとまっていると便利なことがある。いうSPARQLエンドポイントがあったので,それを成功事例として,プリパラでも情報をまとめようとした。DatabaseにJSON様の構造で書いていた。エリを投げられるよう,また他の作品のエンドポイントと相互接続できるよう,RDF変換してSPARQLエンドポイント提供がされるようになった。RDFというのは,キャラクターや楽曲などの対象にURIを付け,そのURI間やURIと文字列などの値(キャラクターの名前とか)のあいだに関連を貼るだけの構造で,繋がりの自由度は高い。そのまま書くのは難しい(あるいは敷居が高い)。実際にある対象(例えばプリパラ13話)の編集作業を(たくさんすることを)考えると,表を作る作業とあまり変わらないことも多いので,データを書く人が単に表感覚で編集できるようにCSVで書けるようにしている。githubにデータを置くことによって得られるメリットは様々だが,github慣れしていない場合に編集に参加しづらくなるのではという懸念がある。githubはGoogleではないのでスプシのように編集できるわけではない。(MSに買収されたので,そのへんの技術で,CSVをいい感じにWeb上で編集してPRできるようになったらいいなぁ)。パワーがあってすごい。ところでWinterのキラリスト・ジュエリスト良きでしたね。SPARQLをSwiftで使ういっぽう私は2月にほぼ無職期間があったので,Swift用にSPARQLのクエリジェネレーターと結果パーサーを作った。github.comこれは半分くらいはSPARQLの構文をSwiftの型に落とす肉体労働だったので寝ぼけながらもアイドルはキンリョクということで乗り切った。SPARQLの文法が分かるようになり,文字列リテラル一致のセマンティクスが分かりづらいので言語文字列リテラルを使わないほうがミスりにくいとか,タイプ(rdf:type)を付けるとクエリ(とクエリジェネレータ)を書きやすいとか,そのタイプごとに語彙(述語のリスト)を把握したほうがよいとか,の知見を得た。github.com得られた知見をもとに,これらいくつかの設計をした。TypeScriptを書いたことはなかったが、まぁなかひこくんがレビューしてくれるしな、って書いた。ところでロケットハートもライブで聴きたいですね。iTunesmusic.apple.comプリッカソンでやってたこと20194月は,アニメのライブ部分だけを無限再生するアプリ作ろうかなと思って,もしライブの時刻アノテーションがPrismDBにあったとしたら,で再生部分が作れるかを試した(banjun/PrismTV)。今となっては,再生の仕組みと,アノテーションをPrismDBに追記する仕組みは,分離せずにひとつのワークフローの中で出来るようにしないと手間が減らなくて進まないなと思っている。5対応にしたあと,PrismDBの語彙であるところのプリズム語彙の補完に対応させた。プリズム語彙って言うとかえって難しく見えそうでもあるが,単にPrismDBで使われている述語の一覧のこと(prism-schema.ttl)である。Buildersの構文を使って,クエリジェネレータの不要なインデントを落としてすっきり書けるようになるかを試した。結果としては効果は大きくなかったしより適用を増やせばデメリットも増えていきそうだったので保留にしている。Previewsに対応させたほうが楽しそうである。おねがい!SoLaMi♡SMILEにも新曲をください!PrismDBデータ化における概念の難しさ比較的自由な構造でデータを追加できるようになったとはいえ,プリティーシリーズ特有の概念の難しさと向き合わなければいけない局面は出てきて,これはプリティーシリーズに詳しい女児のみなさんがプリッカソンで集まったとしても概念の統合と分離には諸説出てしまうくらい難しいようなネタがあるようだ。一例としてはこんな問題(問い)があるので,わたしのように,果たして真中らぁらとはなんであるのか・・・と考えてみるのも楽しいと思う。複雑性を楽しみつつもデータは充実させていこう。it!歌ってたらどうする?おわりにそのままでは絵として見えてこないということで、やっぱりなんだかよく分からないものをやってる感はやはり出てしまうのかなぁ、分かりやすい成果物がほしいなぁとは思いつつ。直近で欲しいのって,PrismDBから出力されPrismDBに追従して更新されていく漢字変換辞書だったりして。それもまた地味かもしれないですね。ほしくないですか?プリッカソンアドベントカレンダーの明日はダンディ(閣下)さんです。そちらのチャンネルもぜひご覧ください。最近はZOZOTOWNのiOSアプリの実装のリアルと技術的に向き合うお仕事をしています。2019の12日目の記事です。昨日の記事はymd_aaaさんの「SpringAnimationを気軽に使おう」でした。こちらの記事も是非ご覧ください。banjun/YesBDTimeやそのアプリmzp/HeartVoiceを作成した。Exposureと呼ばれる)の測定と警告通知の機能が搭載された。この騒音レベルはHealthKitに記録され、ヘルスケアアプリで見ることができるし、APIから取得もできる。一日を通して騒音レベルを定期的に測定します。これにはマイクを使いますが、音声の録音や保存は行いません。ライブ会場で常時録音機能があると、持ち込みのレギュレーションに心配があるが、Appleの公式仕様によれば録音機能を持たないので安心である(※私が安心と思っているの意でありいずれかの組織の確認が取れた情報ではありません)。ヘルスケアアプリで見るとdBで細かく記録されているが、概要レベルのグラフしか見ることはできないので、HealthKitのAPIを利用して騒音レベルを全て取得し、ライブが開催されていた時間帯について、心拍数のグラフと騒音レベルのグラフを並べて表示してみたい。3chord♪のツアーの幕張・名古屋の計4日間のデータを使用した。チケット連番で現地に連れていってくれたり余らせたチケット連番を受けてくれた方々に感謝します。あったので、その場で開発した。banjun/DOKIDOKI-Rhythm。アイマスハッカソンの名札developer.apple.com前回の実装から2年近く経っていたので今年のWWDCでのHealthKitのセッションをざっくり見るところから始めた。データ構造が無駄の少ないように変わったらしい。メリットしかない(フラグ)。実装の様子はもくもくとやっていただけなので割愛。Documentationプライバシーの使用目的に最低文字数制限が追加され、短い文字列を使っていた場合はリビルドするだけでクラッシュするようになる。(詳細未確認)実現された実装github.com各ライブの開催時間に対して心拍数のログ(ピンク)と騒音レベルのログ(青)を表示できるようになった。ライブ振り返り用データを心拍数の一軸だけじゃなくて今年から収集した二軸めを追加しようとしてたもの。あとでアドベントカレンダーかなにかにする。Playerのバージョンを上げる必要があり、そこではYesBDTimeによる再生時刻取得の手法が使えなくなっている。騒音レベルはヘルスケアの全てのデータで見るだけだとdBでの数値リストしか見えないので、全部取得したらおもしろいデータが取れると思っていたが、グラフにしてみるとそれほど分かりやすいデータではなかった。ライブ中は常に一定の範囲のうるささに収まっているようだ。音量が上がってないのに心拍数がやたら上がっているとか、音量の下がったところでBD再生位置合わせの補助になるかもしれないとか、そういう活用がありうるのか、試してみたい。少ないサンプルの感覚値では、騒音レベルは自分の席の近傍の影響をよく反映するようで、ライブ開演前のCMコーナーでの謎の(?)盛り上がり&歓声で既にライブピーク値と同じくらいの騒音レベルを記録している可能性もある。WWDCのHealthKitのセッションをみて、便利になったのだなと思っていたが、既存の実装だと得られるデータの粒度が大幅に粗くなっていた。7thライブツアー最終地は2月の大阪!どういう構成になるのか本当に楽しみ。明日は_sa_chi_03さんの記事が公開予定です。~Tweet広告を非表示にするもっと読むコメントを書く2018-12-31🍓2018年振り返り今年もいろいろなチャレンジができた。カンファレンス登壇2017年が2回の登壇だったので、今年は3回以上にしようとした。直前まで作りこんでいたのでUNION!!イベがあまり回せていない。内容は、去年のシンデレラ5thでたくさん取得したライブ中の心拍数を、今年発売されたライブBDの再生時に使う、複数年にまたがるお話。iOSDCに初登壇して30分枠。録画トラブルでYouTubeに残っていないのが残念。練習会できたのがよかった。その他、プリッカソンでの成果発表など。今年はmacOSコミュニティが再び盛り上がる年だったのでは。シンポジウムが2回開催された。トーク内容は最新事例まで追っているものだが、macOS界隈はどうしても昔話が入り込みやすいというのもあり、もっと新しい人が入ってくるにはどうすればいいのだろうと思う。SwiftもiOS界隈の普段の勉強会にも継続参加ができた。アイマスハッカソンリスペクトで、プリッカソン(当時はプリパラハッカソン)が開催されていた。いいペースで開催されていたので気付いたときには2回目だったので2回目から参加し、3回参加した。connpass初参加のときが「プリパラは明後日で最終回ですね」みたいなエモエモのタイミングであった。新シリーズは始まるが、現状のコンテンツに対してコントリビュートするのか、新しいコンテンツを自ら供給するのか、みたいに考えどころがあった。このハッカソンに存続してほしいので協力できることはないのか、とサポートしたくなってしまったので、気持ちだけちょっとだけお手伝いというかなんというかをした。ライブビューイング参加した。100人が平日深夜に集まってキーノートをみるイベント、アツくてよかった。Timeで働くため、例外的にリモート+深夜残業+休出扱いにしてもらい、全てのセッションをリアルタイム時間で追っていた。会社で勉強会を主催する話が出たので、主催やるのもいいかもなと思って乗っかり、勉強会を開催した。いう心境になったというのが、要因としては大きい。最初は参加ゼロ人だったらどうしようと不安に思い宣伝などしていたのだが、たくさんの人に来てもらい、本当に感謝している。会社のサイトや転職サイトにメッセージ付き写真つきで掲載されるようになったので、社のエンジニアイメージアップ活動で表に出ていた。2017にあれだけ多かったシンデレラ5thのようなライブがない今年は少なくならないかと心配だったが、振り返ってみるとたくさん行っていた。(ライブではないが、、舞台挨拶付き。全コースみたし応援上映もいった)(ライブではないが、、劇場版アイマスを初めてみた。(現地)ようするにアイマスとプリパラ。Pencilでのイラストを描くのを継続している。senseiのコースに(一時)課金して学んだ。senseiのように知識を与えてくれるコースはありがたい。pixiv描いたイラストは、登壇スライドを華やかにする素材として使うこともできて、楽しかった。フラスタに初めて出資したという実績だったが、今年はフラスタのイラストを描くというのをやった。これは今年初めてチャレンジしたことのなかで大きな成果になった。自分の描いたものを他の人に渡して後のことをやってもらうというのは初めて達成した。描いたフラスタのありす、現地にいた。2018www.pixiv.netありすはメットライフドームのみの出演なので、ナゴヤドームではフラスタにも出てこない。ありすのボードを回収できるというので、企画の方にナゴヤドームに持ってきてもらって渡してもらった。自分で描いたありすがボードになって、メットライフドームに行って、ナゴヤドームに行って、経路は違うけれど同じツアーを辿っていて、一周まわってまたうちに帰ってきたというの、めちゃエモい。今年の誕生日イラストは卯月とありすを描いた。作画できるスコープも作画にかかる時間もだいぶよくなった。初星宴舞くらいから、ライブのあとにイラストを描くというのをやってみていた。高まって語彙を失なって記憶もなくなっていくなかでイラストを描くというのは、負荷が高くて中毒性がある。去年後半に作りはじめた名刺は100枚印刷して無くなるころにマイナーチェンジしてまた100枚印刷、で300枚目を印刷してその半分くらいを配った。Factoryも試したので+30枚くらい。1年とすこしでこれだけの枚数配れるとは予想していなかった。だいたいライブのPさんたちだが、エンジニア界隈にも配ってみていた。稀に返ってくるの驚きだし楽しみでもある。自分のアイコンをシールにするというのもやってみた。界隈の性質上、アイコンで認知されているというのもあり、便利な場面もあった。twitterアイコンとありすアイコンがある。欲しいと言われるとめちゃ嬉しい。Me-MAMORIOは丸いので、シールを貼って疑似グッズ化のにちょうどよかった。betaが出てから、いくつかを試した。AquaSKKをみていくことにした。いままでひっそりとレビューをしていたが。リリースをしたところ。GitHubというか真面目な話で、普通にメンテ協力者を求めている。渋谷のオープンに並んだ。Appleのオープンに並んだ。10月くらいから転職ドラフトをきっかけに転職活動をしていた。序盤は現職に残る可能性を捨てていなくて、100万円くらい現年収を上げる交渉は成功した。ピーク時は平日の半分以上は面接をしていてほかのことがあまりできなかったが、スキルマッチしているところの中の話を聞くのは毎回とても興味深くたくさん話をした。次をどこにするかは決めているので、来年のご報告としたい。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このショートカットの中身は、下記のアクションで構成されている。このブログエントリでは、ショートカットの配布リンク提供と、ショートカットの中身のウォークスルー解説をする。うまくオリジナルサイズの画像が貼れなくて読めないと思うので、オリジナルサイズはこっち。https://img.esa.io/uploads/production/attachments/9621/2018/09/26/1855/aa46e4ad-7205-49a2-8607-c6f58a46ab3f.jpgショートカットの入手と実行ショートカット本体は、iCloudでシェアできる。実際にこのiCloudリンクから入手して、実行したり、なかみを見たりできる。Storeでショートカットアプリを入れておく必要がある)。https://www.icloud.com/shortcuts/93a3d2a6052048638943300edb80e8a9なお依存先のショートカットがひとつあるので、下記のショートカットと合わせて2本、インストールする必要がある。以下、ざっと流れの解説。ショートカットを実行「im@sparqlクエリ実行」で、アイドル名と身長のリストをとってくる。400以上の結果が返ってくる。データが充実しているのはim@sparql自体がすごい。「im@sparqlクエリ実行」ショートカットは、別のショートカットの入力に渡して結果を受け取る。SPARQLのSELECTクエリを渡すとim@sparqlから結果を辞書でとりだしてくれるすごいやつ、と認識しておけばよい。SPARQL自体をどう書くか、については下記のページで解説されているので、そちらを参照。im@sparqlを組み込んでみる「リストから項目を取得」→「それぞれで繰り返す」で、ランダム順のあたま10名ぶんを取り出し、なまえと身長の辞書、のリスト、を得る。「辞書の値を取得」は、JSONのキーを辿るやつ。.name.valueになまえ、.height.valueに身長がはいっているので、そう辿る。「それぞれで繰り返す」は、リストのmapであるから、「繰り返しの終了」の直前をみると、map先の値がわかる。アクションの入出力のフローは一直線なので、「繰り返し項目」を二回入力として使うために、途中で「変数を取得」して入力を読みなおしている。出力はこまめに変数にいれておくと、わかりやすい(変数にいれなくても、各アクションの出力は、マジック変数で参照できる)。「リストから選択」ではクイズの出題と回答のUIを提供する。この入力は、ユーザーにみせる文字列のリストでないといけない。この制約がけっこう厳しい。辞書を渡せればいいのだが、表示名だけを渡さないといけない。「複数を選択」にすることで、選択した項目のリストを得られるので、今回のクイズが実現できる。・そのあとほぼ終わりまで続く長い「それぞれで繰り返す」が、答え合わせのループとなる。「リストから選択」の制約で、選択された項目については、アイドルの表示名のリストについてのデータしか持ち合わせていない。したがって、再度、なまえ身長リストをループして、答え合わせをしていく必要がある。「次の場合」はif-else-endifの形式のブロック構造をしている。アイドルごとの判定は「そのアイドルは149cm以下かどうか」×「ユーザーはそのアイドルを選択したかどうか」なので、「次の場合」を2重にネストして、それぞれの4パターンの答え合わせ結果を生成する。「次の場合」も結果を上位のブロックに出力するので、4パターンとも、結果を「テキスト」にして、正解と不正解をもたせる。すると、2重ネストの外側の出力として、「結果が以下の場合」の変数に、正解か不正解かが流れてくる。答え合わせ結果のテキストを絵文字で入れているので、こんな感じの出力になる。×が出たら覚えていこう。これがアイドル10名ぶんmapで繰り返されてくるので、joinする。joinは「テキストを結合」で、改行区切りを選択する。最後に「クイックルック」で結果をユーザーに表示してやる。「クイックルック」は、ショートカットを組み立てるときに、途中に挟んで、実行を止めて出力の内容を見られるので、プリントデバッグ的な感じでべんりに使える。フロー解説こちらのほうが短いけれど、オリジナルサイズの全容はこちら。https://img.esa.io/uploads/production/attachments/9621/2018/09/27/1855/932481f7-a32c-4d65-8993-f466f8962652.jpgSPARQL初心者なので、SPARQLのSELECT書いたらim@sparqlで実行してくれるだけのモジュールとしてのショートカットを作って、試行錯誤しようとして、↑↑のクイズのショートカットから分離したもの。SPARQLのクエリはPREFIXとSELECTからなるようで、PREFIXはお決まりのものを入れておけば良いかなと思って、SELECTだけ書いたら動くようになっている。「ショートカットの入力」で他のショートカットから入力をもらう。「次の場合」では、空実行されたときに後段まで実行されて無駄クエリを投げることがないように、キャンセルできるようにしている。ただのキャンセルというのが分からなかったので、[キャンセル][OK]でキャンセルできる、というだけ。URLエンコードして、im@sparqlのエンドポイントのqueryにくっつける。im@sparqlの結果はJSONで返ってくるようで、辞書にして、お決まりの階層がいくつかあるようなので、results→bindingsと辿って、結果の辞書部分だけをこのショートカットの出力とする。これで、SELECTを書くだけのショートカットを作りやすくなる。下記のページで提供されているようなクエリ実行は、こうなる。https://www.icloud.com/shortcuts/41d10a57b1e84a03b38914fc95be0d86おわりにこうやって、ショートカットでなにかをするときにはこのアクションを使えばいいのかな?、ってアクションの語彙が増えていくと、iPhoneだけでどんどんロジックを組めるようになってくる。iPhoneなので電車のなかでも組める。実際に今回のショートカットのほとんどは、毎日の電車のなかで作成した。ショートカットはもっといろんな連携のパターンがあると思うから、ショートカットで出来ることの語彙を増やしていきたい。こんなアクションつかったらきれいにできる、とか、ここは分離して別のショートカットにしたらいい、とか、そういうネタがあったら教えてほしい。12ショートカットからim@sparqlにアクセスしてクイズをつくってみたTweet広告を非表示にするもっと読むコメントを書く2018-09-24プリッカソン#5でノンプログラミングやってみたprickathon.connpass.comちょっと間があいて久々のプリッカソンに行ってきた。参加するとアナウンスで、一度休んだから行きづらいということはなく、予定が合ったら行こうかなくらいでいいですよ〜くらいのノリで、と言われていて、カジュアルに参加できて良いのだが、なんだかんだ最近は連続で参加できている。このブログエントリでは内部的な解説成分多めで。ショートカットの情報がまだどれくらいあるか分かっていないので。ruby直であれば最速っぽいが、今回は↑のほうの話。github.comようするにプリパラに関するデータを蓄積していくのだが、すべてをいちどにやるのは無理なので、現時点での関心領域は、キャラとか、アニメの話数とか、曲名とか、アニメに出てきた曲、誰が、とか、そのあたり。プリパラのみ(アイドルタイムプリパラも、まだ)。あるが、他のシリーズとか、アニメ以外の情報へ拡張していくのは原理的にはできるはず、、というか、できる構造を狙ってつくっていく、というものだった。Functionで整形する方式)、どこかのRDBに置く話の検討もあったが、インフラ側の準備作業がちょっとあるのに加えて、おもに編集作業がつらいのであった。生データを直で触れない場合は編集UIが要るし、データに制約がある場合は制約を設計して、編集者が理解して、あるいは制約をきれいに編集できるUIが必要になり、という感じで、編集にとりかかるハードルが高い。いうUIがあるのは良いことだが、必須でないほうがありがたい。Googleスプシで書けるくらいで始められたらよい。GitHubなかひこくんさんが、githubにcsvを置くと整形表示とフィルターがある、と言ってCSV書いてみていた。よいし、github上にマスターデータがあるということはdiffも歴史もあってよい。firebaseもRDBも、diffと歴史の保存(てきとうにいじってデータ壊してたときのためにバックアップとるとか)は課題として上がっていたし。2018なんか、エディタによってはCSVの色わけをうまくやるというのもあるみたい。pagesのJekyllでCSVをJSONに変換できるんですよ、というのも見せてもらって、なるほどインフラ不要でよい、と思った。GitHubその実装をみて、なるほどJSON変換、とは・・・?となったが、別インフラも別な生成スクリプトの実行もなくて済むし低コストだし、ありよりのあり。APIをつくってみたのがこれ。書いてるのCSVとテンプレートだし、プログラミングとしてはノーカンでいいよね。アプリがいい感じになっていて、リリースとともにさっそく使ってみた話をタイムラインでよく見かけるようになった。そんなに意味のあることはできないのかなと先入観を持っていたが、わりと高度なことまで出来るようだったので、興味が出てきたので、プリッカソンで調べてやってみようと思った。知識ほぼゼロでアプリ起動してショートカットで使えるアクションを検索すると、JSONを辞書として扱えるようにするのがあった。ドラッグドロップで並べて、アクションの設定値をいれていく。残念ながらCSVを読めるアクションはなさそうだった。APIでもクライアントサイドジョインがあってもまぁなんでもいいかなという気持ちもあったが、ショートカットで実現することを考えると、とりあえずJSONになっているだけでもありがたい。さっきのJekyllが役立っている。キャラクターのJSONをとってきて、そのキーのリストをユーザー選択のアクションシートに出して、そのキャラの情報を引いてくることができる。ここでの未解決課題は、キーではなく名前を出したいのだが、リストから選択アクションでは、選択する値そのものしか表示できないらしい。キーをそのままユーザーにみせるしかない。触ってみてわかってきたのは、いちいち結果を変数に名付けておくと分かりやすいし、フローを切って次のフローを始められるのでよい。日本語もつかえるので、選択したキャラの「なまえ」と「チャーム」を保持しておいて、「[なまえ]は[チャーム]ね」というフォーマットで結果表示できる。プログラミング入門めいてきた。「らぁらちゃんがショートカットで◯◯を作る本」だれか書かないかな?次に、曲名を選択すると、それが歌われたアニメの話数を表示するショートカットをつくってみる。入力はsongs.jsonをみる。jsonのキー一覧を、「それぞれで繰り返す」で、jsonから値取得してnameをとる、ことは、曲名のリストを得ることになる。「それぞれで繰り返す」はmapのことである。これでキーのリストではなく曲名のリストでユーザーに選択させられるのだが、さっきの未解決課題のとおり、選択されたキーがなにか、というのは失なってしまう。しかたがないので、曲名に重複がないことを利用して、もう一度繰り返しで、選択された曲名と一致するところだけを処理する。ifに相当するのが「次の場合」のようだ。「次の場合に終了」までのブロックが生成されるが、これは日本語だから分かりづらいのかなぁ。英語みてないけど、endif的なものだと思われる。ネストが深くなると余計にややこしくなるので、ifが成立したときに変数にいれておくだけにして、フローを切るとよさそう。これで選択した曲情報は得られる。API側(Jekyllによる)でjoinされているlivesをもってくる。lives.json側から引いてきていないかというと、、、これも未解決課題で、filterやuniqueの操作をショートカットでやる方法が見つけられていないから。API側で、やりたいことに合わせてjoinをしておかないと難易度が変わってしまう。Swiftクライアントならどっちでもよさそうなものだが(クライアントに書くかAPIサイドに書くかの違いのみで、ある特定のクライアント都合のユースケースをAPIサイドに書いていいものか問題はある)、ショートカットでは、クライアントでつらい仕事はAPIサイドに書くのが正解かもしれない。結果表示はリストを埋め込んでも改行で表示される。機械的に改行されている感じが、プリパラ世界の「システム」である、めがねぇっぽくてこれはこれで良い。空を判定して分岐はできるようだったので、見つからないときに別のメッセージを出すのもできた。リストから文字列へは好きな区切り文字で結合できて、こうするとより人間的になる。ショートカットは当然にSiriのフレーズを設定できるので、「この曲いつのだっけ」で起動できるようにした。いま再生中の曲名も取れそうなので、曲名一致をどうにかクリアすれば、再生中の曲からもいけそうである。あとはデータの充実で、ここのcsvを充実させてくれる協力者がいれば、、、という感じ。12で↓のリンクからインストールできる。中身の実装がみられるし、編集もできる。https://www.icloud.com/shortcuts/384204a915a1429db3e7d2a1c21ba0f7ノンプログラミングで、できました。Proは必要なかった。iPhone上でドラッグドロップを精度よくやっていくだけ。どこでもできるので、↑のテキスト結合あたりは、帰りの電車で見つけて実装した。ショートカットのシェアーができるのも良い。どこかにアップロードする場所を用意する必要もない。ハッカソンだと、iOSアプリって作ってもすぐシェアーできないので(TestFlightだとしても審査に1日かかってしまう)、そういう意味ではアドバンテージが高い。シェアーしたショートカットをどう残していくかと、どうバージョンアップしていくかは、課題。ツイートでいいんだろうけど、流れていくし、かといって、つくったショートカットの一覧ページみたいなのつくるのも、ちょっと作業がいるかなぁ。プリッカソン会場はここ数回はサポーターズの広い会場で、いつも快適で良い。参加人数もじわじわ増えている。わたしはプリズムストーンのコスプレ参加(?)だったけど、サポーターズのコスプレ参加(?)のひともいた。成果発表のあと買い出しして懇親会。参加者みんな(論理)女児だしアルコール買わないので安いというのもあるが、前回よりさらに安く済み、一人300円となった。遠足のおやつレベルでは。次回はまた予定があえば参加、今度はもっとプログラミングしようかな。connpassページから辿るとSlackもあるので気になっているおともだちもぜひ。参加して登壇してきたパンフ,うれしい。プロポーザルと登壇iOSDCには2016,2017と参加してきて3年目,初めてプロポーザルを出した。30分枠とLT枠と出して,30分の差分更新のトータルパフォーマンスのほうが採択された。fortee.jphttps://fortee.jp/iosdc-japan-2018/proposal/3ae8b788-8df5-4f1e-8862-7c5170a14d36今回プロポーザルを出したのは,そろそろ勉強会慣れもしたし喋れそうかな?と思ったのもあるが,まわりで,プロポーザルを出す,いくつ出す,15分と30分と両方出したほうがいいらしい,みたいなプロポーザル提出時点での盛り上がりがかなりあり,雰囲気に釣られて出した部分も大きい。SwiftとiOSDCとあるが,どちらかというとiOSDCのほうが好きなことを喋っているという要素が大きい印象がある。スタッフブログ登壇自体は緊張したのもあったが,30分喋り続ける体力のほうがつらかったかもしれない。iOS界隈でこれ以上大きいハコで喋ることはなかなか無さそうだし,いまできる範囲でいちばん経験値積めそうなことが出来ました(レベルアップ)という実績解除っぽくてとてもよい。登壇中と前後はワークアウトにして心拍数をとっていた。