これぞ最強のバ美肉 Zoom ビデオ会議 on Mac


2020-06-14 追記:

CamTwist よりも OBS の方が圧倒的に高機能で使いやすいので、OBS を使う方法に変更しました。

また、Zoom の Mac 版は 6.0.4 から再びバーチャルカメラが利用可能になったとのことですが、残念ながらそれはバーチャルカメラのホワイトリスト形式での利用可能で、OBS Mac VirtualCam Plugin はそのホワイトリストに含まれていないため、現状はこれまで通り手を加える必要があります。詳しくはやり方の 5.1. で説明します。


バ美肉 #とは

Wikipedia をご参考にどうぞ。(まあ簡単にいうとバーチャルな美少女に化けること)

用意するもの

ハードウェア

  • MacWindows ならそもそも FaceRig 等の手軽なツールがあるため本記事を読まなくても簡単にできる)
  • iPhone(可能なら Face ID 対応のもの)
  • スマホスタンド等の iPhone を正面に固定できるもの(なくてもいいけど手が疲れる)
  • iPhoneMac を直接接続するケーブル

ソフトウェア

  • OBS(画面合成用)
  • OBS Mac VirtualCam plugin(OBSの画面をバーチャルカメラとして出力用)
  • バーチャルカメラ対応のビデオ会議ツール(Zoom はちょっと手を加える必要がある;詳しくは後述)
  • Vtuber になるための iPhone アプリ(REALITY とか)

結果プレビュー

f:id:elhoshino:20200613152911p:plain
こんな感じで可愛い美少女になってビデオ会議に参加できる

やり方

以下のやり方は上記の用意するものが全てある前提で進めますので、まだの方は是非先に準備してから続きを読んで下さい。

1. Vtuberアプリで自分のアバターを作成

先に Vtuber アプリで自分のキャラクターを設定しておくこともお勧めします。アプリによっては live2D モデル対応だったり VRoid モデル対応だったりもしくは完全に独自カスタマイズアバター設定や内蔵キャラクターしか設定できないアプリもあるので、そこら辺は自分でいろいろ試して自分に合うアプリを決めましょう。筆者は REALITY を使っています、理由は live2D モデルとかに対応していないが独自のカスタマイズキャラクターが使えてしかも結構かわいいので。かわいいは正義

またもしこの時背景を単色に設定できるなら、グリーンスクリーンとかにしとくとあとで合成がしやすいのでおすすめです。例えば筆者はこんな感じです:

f:id:elhoshino:20200613160426j:plain

ちなみに今 REALITY はなんとアバターを cluster と連携できるようになったので筆者としてめちゃくちゃおすすめです。

2. iPhoneMac に繋いでスマホスタンド等で固定

先ほど決めた Vtuber アプリを顔トラッキングモードにして、ちゃんとキャラクターが自分の動きに合わせて動いてくれてる状態にします。ちなみに筆者はこんな感じの車載スマホホルダーでモニターの前に固定しています:

f:id:elhoshino:20200613154309j:plain

3. OBS を設定

3.1. 出力サイズとキャンバスサイズなどを設定

個人的には 1280×720 の解像度で 30 fps のフレームレートをお勧めしますが、もちろん自分のパソコンのスペックに応じてこれ以上上げることも可能です。

f:id:elhoshino:20200613230420p:plain

3.2. 入力ソースとして Mac に接続した iPhone を追加

まずは OBS のソースメニューからビデオキャプチャバイスを選択

f:id:elhoshino:20200613231306p:plain

名前を適当に決めて OK です

f:id:elhoshino:20200613231549p:plain

iPhone 直接が Mac に接続されてる場合、デバイスリストから iPhone の名前が表示されてるはずなので、それを選びます(私の iPhone の名前についてのツッコミは不要ですw);またなるべく高い解像度が使えるために、プリセットは High を選びます

f:id:elhoshino:20200614122716p:plain

もちろんこのままだと携帯画面の解像度が高すぎるので実質顔が見えないことになりますが大丈夫です、まだ色々設定しますので。その前に、まずこのままだと、画面の上下のあまり出したくない領域も出てしまいます。例えば下は LIVE ボタンとか(一回画面タップすると消えてくれますが、会議の途中で誤操作で出してしまったらかっこ悪いので)を隠したいし、上は通知が表示されちゃうこともあるので消したいですね。この時は、レイヤーにクロップフィルターをかけることでできます。というわけでまず iPhone 画面のソースに右クリックしてフィルターを選びましょう

f:id:elhoshino:20200614123333p:plain

フィルター設定画面でエフェクトフィルターからクロップを選び、名前を適当に決めます

f:id:elhoshino:20200614123526p:plain

クロップ領域の設定で相対サイズを選択し、最低限下は LIVE ボタン、上は通知が完全にクロップされるくらいまでクロップします。iPhone X の場合上は 400、下は 450 になりますが、機種によって数値が変わるかと思います(通知が来るタイミングじゃないとどこまでが通知の領域がわかりにくかったりするので、例えば Slack で自分に通知を送るとかの方法で出してみるといいかもしれません);またクロップ領域によっては iPhone 側のアバターのサイズや位置を調整する必要があります、RREALITY の場合は指 2 本で操作できます

f:id:elhoshino:20200614124358p:plain

ついでにもし背景色をグリーンスクリーンのような単色に設定してある方でしたら、せっかくなので背景を透過したいですよね。というわけで同じようにフィルターを追加します、今度はクロマキーです

f:id:elhoshino:20200614124535p:plain

グリーンスクリーンなら初期設定のままで基本大丈夫かと思います;ただしもちろん衣装がそもそも緑だったりすると、背景を別の色にする必要がありますので、その時はクロマキーのキーカラーとかをその背景色に合わせて設定しましょう。設定できたらプレビューで背景が消えるはずかと思います

f:id:elhoshino:20200614124847p:plain

ここまで設定したらとりあえず iPhone の画面の取り込み自体はほぼ終了なので、あとは出力に合わせてレイアウトを調整するだけです。というわけでフィルターの時と同じ要領で、今度は iPhone 画面のソースに右クリックして変換(Transform)メニューから、画面にフィットするを選ぶと楽にできちゃいます(もちろんこだわりがある方、例えば特定な場所に置きたいとか特定の大きさにしたいとかの場合は、直接変換の編集...(Edit Transform...)を選ぶと色々詳しい設定が可能です

f:id:elhoshino:20200614130122p:plain

ここまで設定できたら、自分のアバターが画面の真ん中にくるようにくるはずです

f:id:elhoshino:20200614130222p:plain

3.3. 背景として表示したい画像とかを追加

携帯の画面は基本縦長だけど、テレビ会議の場合は基本横長の画面になるので、多くの場合は左右に余白が出てしまって見栄えが悪いですし、そもそも今回の OBS のキャンバス解像度も 720p にしています。それにグリーンスクリーンを設定した方はクロマキーでアバターの背景を抜いたから、尚更背景が欲しいですよね。まあこれはキャラの追加と比べてだいぶ楽です。まず背景として表示したい画像を探して Mac に保存しておきましょう。この時キャンバスと同じアスペクト比の画像が一番理想です。それができたら iPhone の画面ソースと同じ要領でソースから画像を追加して名前を適当に決めます

f:id:elhoshino:20200614130738p:plain

次に設定画面から先ほど保存した表示したい画像を設定します。背景画像の解像度がキャンバスの解像度と一致しない場合は、iPhone 画面の時と同じく変換メニューから画面をフィットするとか、変換を直接編集して色々弄ってあげましょう

f:id:elhoshino:20200614131109p:plain

ところがこれだとアバターが背景に隠されてしまうので、レイヤの順番を変更しましょう。フィルターとか変換とかと同じ要領で、画像背景ソースを右クリックして順序(Order)メニューから最下部に移動(Move to Bottom)を選びましょう、そうすると背景画像が一番下のレイヤに行ってキャラクターが見えるようになります

f:id:elhoshino:20200614132258p:plain

3.4. 余裕がある方向け:さらに画面表示をパワーアップ

ここまできたら、もっと画面を華やかにしたかったりしますよね、例えば筆者はこんな感じにテキストウィンドウを追加してギャルゲーの UI っぽい風にしてみました(ちなみに本当はさらにリアルタイムテキスト起こしを入れて話したことをそのままテキストウィンドウ内で表示したかったんですけどね…そこまでできたらもう本当にギャルゲーの画面になりますがw)

f:id:elhoshino:20200614135139p:plain

そしてそれだけでなく、オンライン勉強会とかの時も Keynote スライドやライブコーディングに合わせて画面を作ったりすることも可能です

f:id:elhoshino:20200614135256p:plain

4. OBS の VirtualCam を起動

OBS Mac VirtualCam plugin がすでにインストールされ済みなら、ツールメニューから Start Virtual Camera のオプションがあるはずなので、それをクリックすればバーチャルカメラが起動されます

f:id:elhoshino:20200614133055p:plain

5. テレビ会議ツールを設定

テレビ会議ツールを直接設定する前に、macOS 10.15 (Catalina) からアプリが明示的に DAL を許可する entitlements を組み込む必要が出たため、一部のツールは本当は機能としてバーチャルカメラに対応していますが選べない状況になっています。この場合、自分でちょっと手を加えることで封印されたバーチャルカメラの利用機能が再び復活しますので、OBS Mac VirtualCam plugin の Compatibility ページからどのツールがこの処理が必要かが確認できます。とりあえず 2020-06-14 追記に書かれた通り今話題の Zoom(現時点最新バージョン:5.0.5)はこの処理が必要です。

5.1. 一部のツールのみ必要:DAL バリデーションを無効化する

DAL バリデーションの無効化は二通りの方法で回避できます:コードサインを削除する方法と、自分の開発者証明書で再コードサインする方法です。もし Apple Developer Program や Apple Developer Enterprise Program 等に入られていない方(そもそもこれらは何?という方は十中八九入ってないと思います)でしたらコードサインを直接削除しちゃえば一番楽です:Terminal から codesign --remove-signature "<アプリの絶対パス>" を打ち込んでください。例えば Zoom でしたらこんな感じです:

codesign --remove-signature "/Applications/zoom.us.app"

しかしこの方法ですと、ツールによってどうしてもコードサインが必要な機能の利用で支障がある可能性があります、例えば Zoom だと起動する度に毎回これが聞かされます:

f:id:elhoshino:20200615005846p:plain
「常に許可」を選んでも毎回起動する度に聞かれます;それにコードサインを無くすということは第三者がこのアプリを改竄し放題ということを意味しますので「拒否」を選んだ方が無難です

そのためもしすでに上記の ADP もしくは ADEP に契約されてる方でしたら、自分の証明書でコードサインし直した方がいいです。この場合、まずは Terminal から codesign -d --entitlements entitlements.xml "<アプリの絶対パス>" のコマンドで既存の entitlements を書き出します。例えば Zoom ならこんな感じです:

codesign -d --entitlements entitlements.xml "/Applications/zoom.us.app"

そしたら今いるところに entitlements.xml のファイルが書き出されているはずなので、これを開いて、先頭のゴミを削除し、com.apple.security.cs.disable-library-validation についての記述を追加します。例えば Zoom 5.0.5 の時点で書き出されたものなら修正後の内容はこんな感じになるはずです:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
    <key>com.apple.security.device.audio-input</key>
    <true/>
    <key>com.apple.security.device.camera</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>
</plist>

ここまでできたら、最後は自分の証明書でコードサインし直すだけです。まず自分の証明書の名前を控えておきましょう、ADP か ADEP に契約されてる方なら Keychain から見つかるはずです:

f:id:elhoshino:20200615010758p:plain
枠に囲まれてる部分が自分の証明書の名前です

そして Terminal から codesign -f -s "<自分の証明書の名前>" --entitlements entitlements.xml "<アプリの絶対パス>" を打ち込めば終わりです。例えば上記の証明書で Zoom をコードサインするときはこんな感じになります:

$ codesign -f -s "Apple Development: XIANGXIN SHI (ExxxxxxxxD)" --entitlements entitlements.xml "/Applications/zoom.us.app"

こうすれば、きちんと署名がつくので、第三者の改竄を心配することなくかつ毎回毎回セキュリティ問題について聞かれることもないです。

5.2. ビデオ会議ツールでバーチャルカメラを利用

とりあえず今回は Zoom を例に説明します。上記のように DAL バリデーションを無効化すれば、Zoom の環境設定からビデオソースを OBS Virtual Camera に選ぶと使えるようになります。ちなみにその際は左右反転しない方がいいですね、これまで我々が画面作ってる時はそもそも反転で作っていないし、REALITY を利用してる場合は実は REALITY もフェイストラッキングの描画としては反転していますが、衣装の文字とかみてみるとわかるはずですが実は観客にもそのまま送信していてむしろ反転した方が文字が逆になっちゃいますので。

f:id:elhoshino:20200614134210p:plain

後書き

ちなみに iPhone とかを使わないで完全に Mac だけでできる方法もあります(というよりそもそも本記事はその記事を参考に作ったものです2020-06-14 版では CamTwist から OBS に変更したため違う構成になります)ので、もし iPhone とかを持っていない方でしたらこちらも試してみてもいいかもしれません。筆者が iPhone を使う方法にしたのはブラウザによる顔追跡は精度が低い&CPU使用率が高い&使いたいキャラクターがもともと REALITY で設定してたからです。

qiita.com

COSCon(中国オープンソースカンファレンス)行ってきました

なんのイベント

実は私もあまり詳しく存じておりませんが、とにかくなんかオープンソースなものについてみんなで一緒に盛り上げようぜっと言うカンファレンスです。そしてそれもソフトウェアに限らず、ハードウェアとかでも、オープンソースなら話しましょうぜっというスタンスです。実際日本からもラズパイユーザグループの方が登壇に招待されたりしています。

開催は先週末の11月2日〜3日、上海の華東師範大学にて2日間でしたので、私にとってはもしかするとほぼ10年ぶりの上海だった気がします。

詳しくはこちらの公式HPからご覧ください(中国語注意)。

www.bagevent.com

なんでお前が行ったの

正直申し上げますと、実は私はそもそもこのイベントのこと知りませんでした。そもそも普段は日本でしか活動していないし、活動内容も基本Swift周りのみなので、オープンソースとか言う主語のデカイイベントにはずっとハードルが高いと思っていました(まあ実際参加してみてもやはり周りはフロントエンドバックエンドばかりでモバイルネイティブのエンジニアが少ないのは事実である)。

それなのになんでこれ行ったの?と言うと、これもまた偶然に偶然を重ねた結果で、まず私はWeibo(中華Twitterみたいなもの;以下皆さんが分かりやすいように、Weiboの各機能をTwitterの機能名に置き換えて説明します)での知り合いが、「COSConに登壇に招待されたからチケット5枚もらってるけど、同僚や知り合いにあげてまだ1枚余ってて誰か欲しい人いる?」と言う抽選ツイートをしたのです(Weiboでは公式で「抽選」機能があり、対象のツイートを締め切りまでにRTすれば抽選に参加でき、締め切りになったらRTしたユーザから自動でランダムに当選者を選んでくれます;また当選者の人数も設定可能です)。絶対当たるわけないだろwww当選率を下げたろーと言う軽い気持ちでRTしてしまったら、まさかの本当に当選してしまったと言う…

f:id:elhoshino:20191108170013p:plainf:id:elhoshino:20191108170017p:plain
抽選率下げたろーと言う軽い気持ちでRTしてしまったら、本当に当選してしまったの巻

見ての通り、当選したのは10月29日と言う開催直前のタイミングでした。本当にいきなりでした。しかし当選してしまったら仕方ない。さすがに行かないのは行きたくてRTしたのに落選した人には悪すぎる。行くしかない。そんな時にとても助かったのは、弊社の勉強し放題制度、と言うものです。勉強のためなら安心していけ、金銭的な負担は全て会社が担いでやる、と言う勉強好きな人にとって夢のような制度です。

note.mu

とは言え、さすがに会社のお金は無限ではありませんし、こんな素晴らしい会社が倒産してしまったら次のカモはそうそう現れない心が痛みますので、節約できる部分は節約しましょう。と言うわけでほぼほぼ前日ですが、LCC渡航することによって、通常の航空券の半分もかからない、往復で25000円程度に抑えられました。それに会場近くのホテルと合計して45000円程度の経費を計上(することを予定)しました。ちなみにLCCは福岡⇄上海航路がないため、佐賀空港発にしました。航空会社は安定の春秋航空です。佐賀空港は駐車場がタダなので、一人で数日渡航しても駐車料金がかからないから、燃料代考えても非常にお得です。

f:id:elhoshino:20191108135840j:plain

カンファレンスをどう過ごしてきたの

スケジュール構成は午前は大きなトラックを一つ確保して大袈裟なKeynoteを、午後は分野を分けて小さいトラックをたくさん用意して細かい発表を、さらに最終日の午後最後にLTをいくつか登壇させるスタイルです。正直午前中のKeynoteは基本「マイクロソフトオープンソースを愛してるよ」「アリババはこんな風にクラウドサービスでオープンソースを活用してるよ」と言ったスポンサーの宣伝タイムの匂いが濃厚なので、私は午後の知り合いのトークと興味がある分野だけしか行きませんでした。それでも実は思った以上の収穫がありました。

まず1日目は知り合いと合流したのち、その知り合いを通じて中国でのiOSエンジニアと何人か会いました。中国のモバイルネイティブ開発、引いてはプログラミング全体の空気がある程度イメージが湧きました。なんか中国では最近「KPI」と言う概念をほとんどの企業が導入しており、簡単に言うと業績を叩き出せなかったら即解雇という流れがあるらしいです。まあ結果主義なのでそこまでは驚かないですが、ただ本当に中国のエンジニアと会話するたびに「KPIガー」「KPIガー」が登場するので、今回ようやくその正体を突き止めてきました。もちろんそれによってストレスもたまりますが、最近は好景気も相まって、本当に給料がだいぶ上がってきてるらしいです。特にエンジニアの場合、直接数字を聞いておりませんがまあ私より稼いでますね確実に。

お金の話といえば、ちょっと脱線しますが、今回の会場が大学内であることもあり、近くのコンビニに文房具とかの学生向けのライナップもそこそこ充実しています。そこでいかにも学生さんが使ってそうなペンの値段を見てみたら…もちろんモデルとか機能とかにもよりますが、単色の黒色ボールペンというカテゴリで見るともう日本とほとんど変わらないやんけ…筆者が中学生の頃はボールペンなんて1/5の値段しかしなかったから金銭感覚が狂ってしまう

f:id:elhoshino:20191108144259j:plain
昔1元とか1.5元しかしなかったボールペンが今や6.5元とか7.5元かかる

そして2日目はとりあえずとっつきやすそうな発表「开源是菜鸟通往大神之路(オープンソースこそ素人からベテランへの道)」を聞いてみました。とても面白かったので2枚スライドを共有します:

f:id:elhoshino:20191108144320j:plain
ソースコードGitHubに上げるだけでIssueについてオープンに議論しなければ、これオープンソースとは言えずただのgitを使ってるエンジニアでしかない

f:id:elhoshino:20191108144402j:plain
今社内で使われているモジュールをオープンソースにすれば、プロダクトがよりハイレベルに更新され続け、ある意味世界中のベテランプログラマを雇った事になる

うん、まさにこの通りだと思います。と言うわけで実は弊社もこれからいくつかのライブラリーをオープンソースにしようと準備をしています。ただ自社サービスの会社と違い、「じゃあこれソース公開するね」と自分たちだけ言ってぽんって公開できないので、いろいろ準備をしなくてはならないのです。

ちなみにこの発表の後の質疑応答タイムで質問したら、発表者だけでなくその場にいた主催の方の一人からも答えをいただいて、なぜかと言うと発表者は台湾の方で、更にその主催の方も台湾出身で、発表者の答えの後に追伸をくださいました。それを機にWeChat(中国のLINEみたいなもの)友達を追加しておきました。

この発表が終わったらしばらく特にやることなかったので会場の外のキャンパス内の芝生に来てちょっと休もうと思ったら、立ち話してるグループから「日本」と言うキーワードが聞こえて、特に今やることもなくて退屈してるから初対面にもかかわらずとりあえず会話に参加してみたら、ここからまた友達ができました。やったね!と言うかみんなの経歴すごすぎ、高校卒業してアメリカの大学通ったりエリア51で遭難しそうになったりスイス行って登山したりアクティブすぎw

そして最後はLTを聞いてみたかったのでみんなお別れしてLTの教室に。ここにも面白い発表があったのでスライド貼ります

f:id:elhoshino:20191108144438j:plain
我々は「996」を反対しているが、本当に反対しているのは「視野と生きる空間が制限され、仕事と生活が機械化され、それによって想像力が少しずつ無くなっていき、最終的に生き甲斐がなくなること」だ(996は「朝9時出勤夜9時退勤週6日勤務」の略で、中国では特にITベンチャーでは「労働法」違反にもかかわらずこの勤務スタイルを取り入れてる企業がちらほら見られる)

f:id:elhoshino:20191108144450j:plain
自分の趣味が見つかったら、もう一生働かなくて済む。

f:id:elhoshino:20191108144518j:plain
どうやって自分のOSSをPRするか:StackOverflowで人の問題を解決するツールを答えとして返すのはいいぞ(この登壇社はVSCodeプラグインCode Runnerなどの作者です)

そしてLTの始まりに、先ほどの台湾出身の主催者から、「今日のLTは今からでも登壇したい人募集してるよ」と言われて、ちょっと悩んで(日本語のスライドしかないから)結局応募しましたwまあ漢字はちょっとあるしとりあえず言葉で喋れば大丈夫だろうと思って応募してしまいました。ところでいろいろ探してみたがオープンソースのカンファレンスで喋っても大丈夫であろうスライドが15分の発表のもので、このLTがスケジュールの問題で5分以内にと言われました、まあ頑張って超早口で喋って所々を飛ばすしかないと開き直りましたwそして更になんと参加者に動画撮影してbilibiliにもアップロードされたので、初めてbilibiliの他人の動画に出ることになりましたw興味ある方はぜひこちらの動画をご覧ください(もちろん喋りは中国語ですが先ほど言った通りスライドは日本語です)

https://www.bilibili.com/video/av74440949?p=1www.bilibili.com

カンファレンスについてどう思うの

とりあえず正面の入り口の看板や会場のバナーとかをご覧ください

f:id:elhoshino:20191108135924j:plainf:id:elhoshino:20191108144226j:plainf:id:elhoshino:20191108144236j:plainf:id:elhoshino:20191108144423j:plain

見ての通り、多くのスポンサーがついています。知らない人はいないであろうマイクロソフトもいれば、日本市場にもますます存在感を増してきたアリババやファーウェイもいます。そこそこ大規模なカンファレンスですね。

私は本当に何も知らずにチケット当たっちゃったから行かないのはまずいと思って行ってみただけなので、行ってみて思ったよりは全然楽しかったです。知り合いと合流して業界全体の会話ができたり、発表でiOSとは全く関係ない分野の話が聞けたり、何より新しい友達ができたのがとても嬉しかったです。別に当分の間は中国に帰る予定が全くないですが、繋がりができて共通の話題が持てるのは嬉しいことです。

そして中国人は本当にアクティブです、最終日のLTはその場での応募もたくさんあったらしいし(日本人はその場で登壇申し込みどころか質疑応答タイムですら積極的に質問する人少ないよな…後で聞くくせに)、参加者のWeChatグループがいまだに毎日活発に会話していてある意味うるさい(笑)

ただもちろんちょっとうーんなこともあります。一番思ったのはスケジュール管理がずさんすぎですね(苦笑い)。実は1日目に他の聞きたかったセッションがあったのですが、もらった紙のスケジュール表の時間割が古く、その後のセッションと入れ替えられてしまったので、会場についたときはすでにその発表が終わってました。その後携帯アプリから調べ直したら入れ替えられたことを知ってとても残念な気持ちでした。せめて会場内でどこか案内が欲しかった(逆に今の中国人はもうみんなアプリしか見ないのかな…?いやアプリ見るのはいいことだけど携帯の画面ちっちゃすぎてスケジュール見づらくない?)。そして発表時間も人によってはオーバーしたりでその後の発表の時間が押されてしまったり。

でも後で聞いた話ですが、そもそも今回の主催や運営は学生さんが多いらしいです。まあそもそも開催地が大学ですもんね。それを考えれば、むしろ学生主体でこれだけ大規模なカンファレンスが主催できたのが既に凄すぎます。自分が大学生の時はサークルの飲み会で精一杯でしたよな…

他に何か言いたいことあるか

チケットくれた知り合いにお土産あげたら、加藤ちゃんの絵を書いてくれた

f:id:elhoshino:20191108144218j:plain
加藤恵

会場の大学食堂のお昼

f:id:elhoshino:20191108135948j:plain
懐かしい大学食堂

ホテルから見た上海の夜景

f:id:elhoshino:20191108144547j:plain
日本にもこう言うフリーウェイ欲しい

大学のすぐ近くにあるショッピングモールに、タオバオの公式店舗サービス「天猫」のマスコットキャラがあった。かわいい

f:id:elhoshino:20191108144155j:plain
天猫ちゃん

よくわからないなんかそのサービスでは車のコーティングもやるらしくそれの宣伝トラックもあった。かっこいい

f:id:elhoshino:20191108144207j:plain
よくわからない店舗のトラック

レストランの前に飾られてる古典的な漢服を着てるお人形

f:id:elhoshino:20191108144536j:plain
かわいい

そろそろ洗車した方がいいぞ、のかわいい車

f:id:elhoshino:20191108144601j:plainf:id:elhoshino:20191108144614j:plain
流石にそろそろ洗車しないと…

以上、中国も楽しいよ!

iOSDC JAPAN 2019 参加してきました

年に 1 度の日本 iOS 開発者の祭典、iOSDC に今年 3 回目の参加してきました!

私のこと知ってる人なら知ってると思いますが、私は今年 2 月に福岡に引っ越しましたので、それまでに東京で知り合ったエンジニアと会う機会が非常に減りましたので、iOSDC のような日本全国から集まってくれるイベントはとても貴重です。そしてもちろん半年ぶりに会った東京のエンジニアもいるし、一年ぶりに会った他の地方のエンジニアもいますし、さらに新しい知り合いもできました。ありがとう、iOSDC!

そして iOSDC は一方通行のコミュニケーションではなく、登壇者も視聴者も対等に双方向のコミュニケーションの場として提供したい!とのことですので、聞いた発表に気軽にフィードバックをオンライで できる仕組みが作られています。とりあえず聞いた発表全部フィードバックを送ったら、なんとフィードバッカー賞をいただきました!ありがとうございます!!今年は大体一言で終わらしました(何人かは一言もなく空白で送っちゃいました)から申し訳ないと思いますので、来年はもっと長文のフィードバックを送れたらと思います💪

ちなみに個人的に今年で一番良かったと思ったセッションは koher さんの「Heart of Swift」でした。やはり私は iOS がどうのこうのではなく「Swift」言語そのものが好きです。残念ながら執筆した現時点ではまだスライドの PDF が公開されていません、と言うのもそもそも発表スライドは Keynote とかではなく、iPad アプリで作ったらしいです。さすがの気合です。と言うわけでとりあえず CfP のリンクを貼り付けます: fortee.jp

会期中は発表とおしゃべりに集中してましたので、あまり写真をたくさん撮れませんでしたが、とりあえずいくつかお見せしましょう:

f:id:elhoshino:20190908123719j:plain 入り口のバナー

f:id:elhoshino:20190908124748j:plain 弊社の紹介バナー

f:id:elhoshino:20190908125016j:plain みんな大好きタピオカミルクティー

f:id:elhoshino:20190908125231j:plain ベストフィードバッカー賞でいただいた T シャツを早速着てみた

それでは!

町、時の流れ、人

2019年7月18日午前10時半過ぎ、京都アニメーション第一スタジオが放火され、執筆している現時点で34人の方が死亡し、34人が重軽傷を負う事件が発生しました。

事件発生した当時のニュースは火災の報道しかなかったため、私は「京アニ燃えちゃったか…早く火を消せたらいいな」くらいの温度感しかなく、普段通りに仕事場に向かいました。

ところが時間の経過につれて、「死亡確認」のニュースが出始め、さらに死亡者数も見るたびに上がって行きました。

頭がだんだん白くなっていきました。何も考えられなくなりました。あまりにものショックで、出社して4時間も経たずに帰宅することにしました。そして翌日も、面接して最低限の作業だけに留まりました。

最初はまだ被害者への悔しみと放火犯への怒りで頭がいっぱいでした。古代中国の凌遅刑が復活すればいいのにとすら思いました。しかし新しい情報が入ってくるうちにいつの間にか全ての感情を失いました。19日はただロボットのようにひたすらニュースやコメントを更新して眺めるだけの1日を過ごしました。

京アニは私にとってとても大事な存在です。2004年高校生になった私はクラスメイトの影響でアニメにハマり、新旧問わず様々な作品を見ていました。そんな頃に、京アニの元請け作品2作目のAIRと出会い、京アニファンと鍵っ子になりました。感動的なストーリーはもちろん、今でも印象に残ってるのは、周りの多くの人は「あんなクッソでかい目玉まじクソ作画じゃんw」と笑う中、私は逆にあの宝石のような瞳の描き方に魅了されました。中国では「目は心への窓口」の言葉もあり、瞳にこんなに力を入れる作品は神作に決まってると断定しました。そして完結と共に、私の判断は間違ってなかったと安堵しました。もしヒロインが最後死ぬ物語は悲劇ならAIRは間違いなく悲劇ですが、不思議と一般的な悲劇と違うのは最後まで見終わったあと、心に残ったのは憂鬱ではなくまた明日も頑張ろうっという希望に満ち溢れたポジティブな感情でした。

それ以来、女性向けのFree!も含めて京アニのほぼ全ての作品を見てきました。とてもハマった作品もあれば、当然それほど好きになれなかった作品もあります。ただ「適当にこういうのだしとけば儲かりそう」という薄っぺらい作品は一つもなく、どれもスタッフの熱意と苦労がこもった作品ばかりです。この拝金主義が横行し、とりあえずソフトポルノなやつだしとけばホイホイとお金出してくれる楽な商売で生きていける現代社会で、落ち着いてゆっくりと、それもしっかりと一つ一つの作品を心を込めて大事に育てていく会社はそう多くありません。だからこそ、アップルCEOのティムクック氏も京アニを、「home to some of the world’s most talented animators and dreamers(一部の世界で最も才能溢れたアニメーターとドリーマーにとっての家だ)」と高く評価してくれたでしょう。

ティムクックや私のような京アニファンだけでなく、京アニに「監督降板」させられたヤマカンこと山本寛氏も、最初の頃は「ちょっと黙っといて」で炎上しましたが、事件翌日偶然、中国新華社ライブ配信に献花の姿を撮られました。正直なところ、私はヤマカンのことそれほど好きというわけではありませんが、部外者の私より彼のほうがよっぽど京アニに思い入れがあるでしょう。彼は一体どんな気持ちで献花したのかを推測できる立場ではないと自覚しておりますが、あの涙はきっと本物だと私は思います。それにしても運命はわからないもんです。日本でも中国でもなかなか才能が認められず、その上戦争についての発言で中国で炎上し、入国禁止まで食らったヤマカンが、逆に中国メディアにその思い入れの一面が映り、世界に公開されたわけです。

京都アニメーションは創立当初から、地元貢献を企業理念の一つとして運営してきました。今回の事件についても、八田社長は焼失した第一スタジオを取り壊し、記念碑を建てた公園にしたいとコメントしました。これほどの被害を受けても、従業員と彼らの家族への取り組みを最優先にし、そして自社の再建よりも地元民を大事に考えています。これほど尊敬できる企業はなかなか出会えません。そしてこんな尊敬に値する企業だからこそ、地元民のみならず世界中から支持を集めているでしょう。事件発生してから、従業員を頑張って救助しようとしている住民や消防隊、日本中から駆けつけた献花者、世界中から集まる義援金京アニに感動をもたらされた一人一人が自分でできる限りのことに尽力しています。

亡くなった方々は復活できませんが、それでも生き残った我々は自分の使命を果たし、世界をもっと美しくし、より多くの人々に夢を与えなければなりません。それこそが犠牲者へ捧げられる最大の敬意だと私は思い、明日に向けて生きていくと誓います。


※タイトルは京アニによってもアニメ化された作品「CLANNAD」の、ゲーム中BGMの一つのタイトルです。

LINE Developer Meetup(京都)#53 に行ってきました

お久しぶりです。転職ではないが東京に飽きて特に渋滞にうんざりしてしまって会社に「福岡行きたいです」って言ったら一人で福岡オフィス作った(と言う名のWeWork借りた)星野です。ちなみに福岡に移住したとは言え、iOS 系の勉強会がやはり少ないから、月一くらい東京の勉強会行くから旅費くださいって言えば出してくれる会社ですのでとても助かります。と言うわけで今回は東京ではなく京都に行ってくました:

line.connpass.com

LINE さん主催の勉強会で、一般公募登壇枠がなく全て LINE の社員による発表(しかも 3 枠のうち 2 枠は外国人社員による英語の発表)ですが、どれも内容がとても濃くて完全に吸収するのにはまだ少し時間がかかりそうです。と言うわけで復習も兼ねてこの記事で簡単にこれらの発表を振り返ってみます。

MVC @ IOS

speakerdeck.com

これは MVC パターンを綺麗にするための発表です

概要

  • 従来の (CocoaMVC パターンは VC(ViewController)が Fat になりがち
    • そのため MVP や MVVM などの設計が考案され、MVC はもう時代遅れと言う風潮になった雰囲気がある
    • しかし本当に MVC はそれほどダメなのか
  • iOS の VC と View は本来それぞれちゃんとした役割がある
    • VC は画面遷移、View のライフサイクルやイベントなどの管理を行う
    • 対して View は子ビューの階層構造、レイアウト、レンダリングやアニメーション等を行う
  • View を自作してみよう
    • 画面系のセットアップを VC から View に移行しよう、これで View のテストも作りやすくなる
  • VC から Model や Network などの要件もちゃんと分離しよう
    • これで Unit Test もやりやすくなる
  • 画面が複雑になってきたら子 VC の利用も検討しよう
    • 要件が単純化され、作りやすくなる
  • まとめ
    • MVC でも綺麗で読みやすい作りにできる
    • 汎用的で再利用しやすい UI を作ろう
    • 設計に銀の弾丸はない、ちゃんと自分たちで設計要件を検討しよう
    • もちろもちろん MVVM や Redux なども魅力的だよ!

感想

実は設計について、自分も去年こちらの本の執筆に参加しており、中でまさに MVC の章の執筆を担当しました:

peaks.cc

この章の執筆によって MVC の資料をたくさん漁って、実は今まで MVC に関する知識は間違っていた!?と言う反省を抱きながら、執筆に臨みました。そしてその感想として、やはり MVC でもきちんと設計を行っていれば綺麗なコードにはなるし、逆に何も考えずに Fat な VC を作っちゃうような人たちは、仮に MVVM や MVP とかの設計に転向したところで、Fat な ViewModel や Fat な Presenter を作ってしまうだけで終わりますので、やはりどの設計を選ぶか以上に、どの部品がどこまでの責務を持つかをきちんと考え抜いたほうが大事ですね!Fat VC を理由に MVC を拒まないようにしましょう、MVC も立派で偉大な設計パターンです。

Swift コードのための Swift プログラミング

speakerdeck.com

ちょっとわかりにくいようなタイトルですが、Swift プログラムで、Swift のソースコード(フォーマット)を綺麗にするための発表です

概要

  • SwiftSyntax と言うツールがある
    • これを使うと、特定なキーワードでワーニングを出したり、ソースコードを機械で生成/編集したりできる
  • SwiftSyntax はコンパイラ内部で使う libSyntax を利用し、構文を抽象化して解析したり作成したりできる
    • 具体的にはどんな型があって、中にどんなプロパティーがあって、どの protocol に準拠してるかだとか、様々な構文情報がわかる
    • それによってプロパティーの書き換えや場所の移動、private などの attributes の追加なども簡単に実現できる
    • 構文の解析には SyntaxVisitor を利用する
    • 構文の編集は SyntaxRewriter を利用する
    • 構文の生成は SyntaxFactory を利用する
  • 具体的な操作は上記のスライドを参考に

感想

実は今年の try! Swift Tokyo にもありました SwiftSyntax のネタですが、try! Swift の時は 5 分しかない LT だったので最低限のイメージの紹介しかできなかったが、この発表では時間がたっぷりありますので、具体的にどう言う風に使えばいいかだけでなく、実際にそのツールをすでに作って& OSS 化したので、より使いやすくなったと思います。特にチームで開発する際に、フォーマットの平準化にも役に立ちそうですので、いつか導入したいですね。今のところ唯一の懸念点は、どうやってコミットを実行済みの結果に保証するかの仕組みを考えないとですね…

Networking shouldn't be so hard

speakerdeck.com

これはネットワーク処理(リクエストやレスポンス)についての、非常に詳しい発表です

概要

  • ネットワーク処理は簡単か?
    • 理想論ならとても簡単
    • でも現実世界ではなかなかそうシンプルにはいかない
    • しかし本来ならばそう難しくなるべきでもない
  • 大昔のネットワーク処理は今と比べるとちょっと煩雑だった
    • NSURLConnection とかを使っていた
    • セッション管理とかキャッシュとか自力でやる必要があった
    • ただ別にそれでも特に難しくはなかった
  • 今はさらにいろんなラッパーライブラリーがある
    • URLSession とか Alamofire 使えばもっとやりやすくなっている
    • Client を作ってリクエストとレスポンスをセッション通じてさらに管理しやすくできる
    • レスポンスの面倒な (data: T?, response: URLResponse?, error: Error?) はさらに Swift 5 の Result<T, Error> でまとめられる
    • よってネットワーク処理は本当に(理屈上は)簡単
  • しかし現実世界はそう単純にいかない
    • リクエストのコンテンツは JSON Body なのか URL Query なのかだとか
    • 正常でないレスポンスが返ってきたときのハンドリングとか
    • ネットワークがつながりにくい時のリトライや Token が古くなった時の更新だとか
    • 現実世界で起こりうるシナリオの多さは問題を難しくしている
  • でも問題を単純化することは可能だしそうすべき
    • 各々の責務を細かく抽象化して分けよう
      • リクエストならリクエストを作る責務を抽象化して、内容に応じた具体的なリクエストの作りをその部品に任せよう
      • レスポンスなら意思決定ベースで continue restart errored done に抽象化してそれぞれの動作を実装しよう
    • リクエスト駆動でやることをリスト化する
  • 問題を細かく抽象化して対処すれば難しくない
    • 部品が小さくなるので見通しが良くなる
    • 副作用を排除したのでテストがしやすくなる
    • protocol の活用で実際のケースに応じた柔軟な対応がしやすい
    • 意思決定を基にした拡張性の確保
    • リクエスト駆動による操作性の向上
  • 結論:現実世界でもネットワーク処理は難しくないはず

感想

なかなか濃い内容で、これだけでも京都に来た甲斐はあったと思えるくらいのボリュームです。ネットワーク処理をどう単純化すればいいかなど、細かいところまでカバーしてたので今後の開発に参考にできるものも非常に多いです。ちなみに Speakerdeck に上がっている資料は 133 ページもあるのですが、発表者の @onevcat 氏によるとこれでもすでに初稿から 20 ページも削除したそうです…

あとがき

どうしても日帰りで福岡に帰りたかったので残念ながら懇親会はほんの少しだけしかいられなかったけど、久しぶりに京都勢に会えたので今度はぜひみんな福岡に来て欲しいw

try! Swift 2018 レポート的な何か

あらすじ

年に一度、日本で開催される Swift 関係で唯一の国際カンファレンス:try! Swift Tokyo へ今年も行ってきました。1 日目と 2 日目はトーク、そして 3 日目は各種ワークショップやもくもく会など、盛りだくさんの内容で賑わう 3 日間でしたので、今回の参加で気になった内容をまとめようと思い、この記事を書くこととしました。最初は Qiita で書くかこちらで書くか迷いましたけど、みんな Qiita で書くと try! Swift 関連の記事で TL 荒らしになりそうな気がするのでこちらにしました(笑)。

1 日目

裏 Swift Tour

speakerdeck.com

最初の発表。普段何気なく書いてるあのコードも、実は裏ではこんなことをやってるの!?みたいな解説もあって、とても興味深かったセッションでした。トリッキーな動きをするコードはあまり積極的に買うべきものではないですが、その動きを把握することはデバッグすることにおいてとても重要ですので、把握しておいて損はないです。ちなみに個人的に一番興味深かったのは、宣言が Stored Property のように見えても、didSetwillSet 入れただけで、実は裏では setget を利用する Computed Property になります。Computed Property と Stored Property は、特にマルチアクセスがあるときの動作は結構違いますので気をつけましょう。

レスポンダチェーンを知ろう

※公開スライドなし

iOS の開発しかやってないとあまり意識したことがない Responder Chain ですが、チェーンをカスタマイズすることで途中で好きな処理を挿入できたりして、例えば Delegate を使ってた処理とかも、Responder Chain の途中で好きなオブジェクトを挿入してハンドリングしてもらうこともできるそうです。個人的にはまだあまりその旨味を実感できてませんが、これからはこれを意識して使い道を探してみようと思います。

関心の分離と単純化のためのSwiftコードの最適化

speakerdeck.com

我々はソースコードを書くことよりも、倍以上の時間を費やしてソースコードを読んでます、そのためコードレビューなどではコードの読みやすさはとても重要です。そんな中、コードの中に「What」と「How」を分離することは、コードの読みやすさに大きく貢献しています。例えば UTF16 で文字数を数えるソースコードで、.utf16.count を使うわけですが、このコードだけでは .utf16.count を使っていることはわかっても、なぜ utf16.count を使っているのか、これはプログラム上ではどういう意味を持っているのかはわかりません。そのため、String を拡張して、var countUsingBackendPolicy: Int { return utf16.count } を定義することによって、「これはバックエンドのポリシーによる文字数の数え方だよ」ということが読み取れます。この発表はこのようなユースケースをたくさん紹介して、実務ではどのようにソースコードを改修してきたのかを説明したとても為になるセッションでしたので、スライドも定期的に読み直したいですね。

SwiftyPi

speakerdeck.com

実はこのトークの時間、自分は前の前のセッションの Ask The Speaker のコーナーにいたのでその場で聞くことはできぜ、あとからスライドを眺めることしかできませんでしたが、内容自体はとても気になりました、なぜなら実は自分も去年ラズパイに Swift 入れようとして Ubuntu 入れるところまで行ったけどそれ以上の進捗がなく止まってました。このトークによりますと、どうやら現状 Swift 4.1 はまだ ARMv7 の対応がなく、使うときは Swift 3.1.1 を利用すべきらしいです。また、GPIO を操作するときは GPIO の番号を使う必要があって、それが物理の PIN 番号とは違うので要注意です(そして GPIO 番号はボード上ではバラバラに配置されています)。また、このトークでは Vapor も利用しており、クライアント側/サーバ側/組み込み側が全て Swift で作られているので、Swift 信者としてはとても気持ちいい構成になってますので時間あるときに是非とも深く研究してみたいと思います。

👾

speakerdeck.com

去年からゲーム開発ネタをぶち込んでくる自称ゲーム開発者の iOS エンジニア兼 fastlane コントリビューターの giginet さんの発表です。去年はマリオを Apple Watch に移植したことを発表しましたが、今年はさらにエスカレートし、Xcode を「統合ゲーム開発環境」だと訴えました。まあ確かに Xcode だけで RPG のマップとか作れるけどさー。自分も前職がゲーム会社だったこともあって、リリースまでは持ち込めなかったものの、ゲーム開発用の SpriteKit や SceneKit は確かに色々触ったこともありましたので、3D は専門外ですが 2D なら確かに SpriteKit を使えば結構手軽にいろんなジャンルのゲームが作れます。そして SpriteKit は唯一 Apple Watch に対応しているゲームエンジンだということもアピールし、自作の RxSpriteKit の宣伝もしっかり入れました。凄まじいゲーム愛を伺えます。

AST メタプログラミング

speakerdeck.com

なかなか高度の話題で、少なくとも自分としては今まで全く触ったことのない分野の話でした。構文解析された Abstract Syntanx Tree の中にさらに独自の処理を入れることによって、普通に自力でソースコード書くととてつもなく大変なものがテンプレートを使うのと同じ感覚ですぐ書けちゃうのがとても魅力的で、生産性が上がるだけでなく重複労働が省かれるためヒューマンエラーも減りそうな予感です。この発表では発表者の岸川さんが作った強力なアサートライブラリ SwiftPowerAssert を最後に紹介しましたが、真面目な話、自分が作ってる NotAutoLayout もメタ的な視点で見ると重複してるコードが沢山ありますので、是非とも導研究してみたい気分です。

2 日目

超解像 + CoreML + Swift を使ってアプリの画像データ転送量削減に挑戦する

speakerdeck.com

通信、特に画像や映像が頻繁にサーバとやりとりするアプリでは、通信量の削減は常にホットな話題の一つです。削減法は沢山ありますが、例えば画像の場合、圧縮比の優れたフォーマットを利用する方法もありますが、もっと直接で乱暴な方法として画像の解像度を減らすというのもあります。しかし低解像度の画像をそのまま表示されると見栄えがさすがに悪いので、どうにかローカルで解像度を上げないといけません。そんなとき、我々アニオタならまっ最初に頭に浮かぶのは waifu2x ですが、それはアニメ画像用にチューニングされたものですので、直接漫画に適用すると、漫画のトーンが潰されたり、文字が滲んだりする問題があります。そのため、DeNA ではマンガボックスというサービスのために、ローカルで解像度を上げた画像を手軽に利用するための SRCNNKit を公開し、その解像度を上げるための独自の学習モデルを開発しました。さすが漫画データを用いた学習済みモデルだけあって、漫画トーンもとても綺麗に出てかなり良かった感じです。

Swift 5 の Ownership に備える

speakerdeck.com

Swift 5 では新しい機能として「Ownership」が導入される予定だというのはもうニュースではありませんが、このトークは実際 Ownership 導入されたら今までのコードにどんな影響をもたらすのか、我々エンジニアにとってどんなメリット/デメリットがあるのかについて軽く紹介した内容です。Swift は値型である structenum を大幅にパワーアップし、今まで参照型である class にどうしても頼らなくてはいけない多くのものは、値型の structenum でも十分カバーできるようにし、暗黙な参照を減らすことでより安全なコーディングを可能にしました。しかしその反面、値型のデメリットであるコピーコストはどうしても避けては通れない道でした。今まででも Copy on Write という仕組みで、値型はコード上コピーされても、実際の動きは修正が入ってから初めてデータがコピーされることによってある程度のパフォーマンスの問題をカバーしてきましたが、それをより高度なチューニングを可能にしたのが Ownership です。moveonly struct による定義や shared 修飾子による引数宣言で、プログラムは今までと同じ安全性を保ちつつも、明示的に参照だけ渡すことを可能にしたことで不要なコピーコストをさらに減らすことが可能になります。またすでに Ownership を導入した Rust では学習コストが高く、Ownership を使いこなす必要がありますが、Swift では Ownership はあくまでチューニング用の機能であり、使わなくても今までと同じコードで開発可能だそうです。

Codableが導く型安全な世界

speakerdeck.com

Xcode 9 がもたらす最も嬉しい機能の一つと言っても過言ではないであろう Codable ですが、多くの人はこれを JSON データとの相互変換にしか使っておらず、それが大変もったいないということを再確認させてくれるトークです。CodableJSON だけでなく、ありとあらゆるデータのエンコード/デコードは理論上可能であり、その必要があれば自前の XxxEncoderXxxDecoder さえ作れば OK です。そして、発表者は実際にそういったエンコーダ/デコーダを作った MoreCodable ライブラリーも公開し、JSON 以外でもより手軽に Codable が使えるようになりますので、ぜひ試してほしいライブラリーの一つです。

3 日目

今年の try! Swift Tokyo は 3 日目にハッカソンがなく、代わりに様々なワークショップがあります。そんな中で自分が参加したのはこちらです↓

Swift の値型を極める powered by SWIFT QUEST

参加した、というのは間違いないですが、さらに正確にいうとアシスタントとして参加し、ステップバイステップに手を動かしたわけではなく、むしろ参加者が手を動かすのを手伝う立場でした。

前述 2 日目の Ownership の話にもあった通り、Swift の値型はとても強力で、このワークショップはその値型の振る舞いをマスターするためのものです。そのために使ったのは主催者が作った SWIFT QUEST という誰もが知っている(であろう)あの RPG をモチーフにしたゲームです。このワークショップを通じて、如何に値型の struct だけで、安全なプログラムを構築しながらも手軽なデータ修正を行うという、Mutable Class と Immutable Class 両方のいいとこ取りをするのか体験できます。

After talks 2 日目

公式のプログラムが終わった後には、さらに非公式な関連イベントがいくつか開催されており、この After talks もそのうちの一つです。また、とても光栄なことに、自分も当時 try! Swift に出した CfP が落ちたものの、「この CfP が聞きたい!」という声があったためここで発表する運びとなりました。

初めてのターミナルプログラム

speakerdeck.com

当日は仕事の都合によりほとんどのトークが聞けず、なんとかギリギリ自分の発表順番が来る直前に会場にたどり着いたわけですが、そこで発表したのがこちらです。Swift はアップルが主導で開発している言語であり、また Swift を使った開発の多くは iOS 開発でしょう。しかし Swift はあくまで汎用プログラミング言語であり、iOS だけに使うのはもったいないです。せっかく我々は Mac を使って iOS 開発しているので、ついでに Swift で Mac のターミナルで使えるプログラムも開発してみようではないか、という思いで出した CfP でして、また発表自体ライブコーディングを交えつつ簡単なズンドコプログラムをその場で作りました。ターミナルプログラムの開発はとても手軽にできちゃいますので、ぜひともたくさん作ってみてほしいと思います。

まとめ

本記事が完成した時は既に try! Swift の開催から2週間も過ぎたのですが、今年も多くの収穫があり、特に Ask The Speaker コーナーは今年自分初めて利用し、そこでアップル社の中の人ともお話ができてとても嬉しかったです。限られたリソースの中、アップルとしても Swift をより汎用的なステージに送り出そうとしているようですので、Swift 大好きな筆者としてもぜひこれから iOS、ひいてはアップルのエコシステム以外での Swift の活躍をお祈りしたい気分です。

そうだ。浜松、行こう。

これは、今年行ってよかったところ Advent Calendar 2017 3 日目の記事です。

ものすごい遅くなって大変すみませんでした。冬コミの原稿の進捗がかなり思った以上にやばくて、Advent Calendar の執筆が遅れてしまうことになりました。そしてどうせならついでに宣伝します。冬コミ 1 日目、12 月 29 日に、東キ-11b にて、自作 iOSフレームワーク「NotAutoLayout」の解説本:「レイアウトを、もっと Swifty に」を出します。表紙入れて全 48 ページで、当日現金価格 1000 円です。また、昨年と同じく一部電子マネーによる支払いも受け付ける予定ですが、対応する電子マネー及び電子マネー用の価格はまた後日発表いたします。

それでは、本編に入ります。

なぜ、浜松へ?

筆者は大学時代は宇都宮で過ごしていました。そういった意味では浜松に対してはある意味ライバル視な気持ちがあります。餃子の街として。

ところが、今年に「ガヴリールドロップアウト」というアニメがありました。とても面白かった。そしてそのアニメの舞台となっているのが浜松でした。聖地巡礼大好きな筆者として行かねばと思いました。

準備

準備と言えるほどの準備なんてしませんでした。いつもなら行く前に一応最低限の下調べして、どのシーンにどこが映ったかとかを把握した上で行ってます。でも今回はあまり時間がなかったので、とりあえず公式聖地巡礼 HP にも載っている「舞天島」こと「弁天島」に行くことだけ決めました。そして運転するのが大好きな筆者として、せっかくだからタイムズレンタカーのマツダロードスターを借りることにしました。初めて乗りましたけど、ロードスターはいいぞ

マツダロードスター

別にステマやってるわけではありませんが、マツダロードスターは本当にいい車ですのでここで少し場所を借りて宣伝してみたいと思います。そして「マツダロードスター」って名前なんか長いのでここからは海外名の「MX-5」を使います

意外と知ってる人少ないようですが、MX-5 は実は全世界で一番売れている 2 シーター 2 ドアオープンカーです。MX-5 がこれだけ売れてる理由は実はとてもシンプルで、馬力こそそんなに高くないものの、非常に高い操作性を持ち備えながら誰でも純粋な運転の楽しさを気軽に感じられ、日常の中でちょっぴりな非日常をリーズナブルな金額で味わえられる車だからです。200 も行かない馬力しかないですが、たった 1 トン程度の重さに、完璧たる 50:50 の前後比重、そしてスポーツカーの王道である FR 駆動方式、ダントツな助手席に彼女を載せたい車 No.1 間違いなし(筆者調べ)です。(なお彼女(ry

そんな MX-5 ですが、MT 車もタイムズレンタカーで取り扱っており、興味ある方はぜひ一度借りてみてはいかがでしょうか?以上宣伝です。

f:id:elhoshino:20171225152246j:plain
今回借りた MX-5 です

弁天島

弁天島はガヴドロでは主にいわゆる「海回」の第 4 話で登場した舞台です。天使と悪魔たちの楽しい楽しい海でのお話です。混ざりたい。

f:id:elhoshino:20171225154049j:plain
駐車した MX-5 に、弁天島のあの有名(?)な鳥居
f:id:elhoshino:20171225154605p:plain
参考にアニメに登場したあの鳥居
f:id:elhoshino:20171225160759j:plain
弁天島の海辺
f:id:elhoshino:20171225154734j:plain
現地のお店にもガヴドロのポスターが貼られたりしてます
f:id:elhoshino:20171225160330j:plain
というわけで入ってみた

浜松市

せっかくなので一応市内にも行って来ました。駅の観光案内所にもガヴドロの巡礼マップ配布してると聞いたので(ry

f:id:elhoshino:20171225161731j:plain
ヴィーネちゃんが律儀に 2 時間も待った場所
f:id:elhoshino:20171225161912p:plain
アニメ
f:id:elhoshino:20171225161934j:plain
原作
f:id:elhoshino:20171225162228j:plain
観光案内所からもらったガヴドロ聖地巡礼マップ
f:id:elhoshino:20171225162601j:plain
一応ライバル心燃やして夕飯餃子頼みました。

以上、短くて何も伝えなかったが浜松でした。今度チャンスあるときに是非ともまた行きたいです。夏に。できれば彼女と(ry