その後のその後

iOSエンジニア 堤 修一のブログ github.com/shu223

フリーランスを再開して2ヶ月のお仕事まとめ

アメリカでのパートタイム会社員と日本でのフリーランスの2足のわらじを履き始めてから約2ヶ月が経ちました。今月からまた1ヶ月ほど会社員に戻るので、この2ヶ月にやったこと・つくったものをまとめておきます。1

f:id:shu223:20180506214619j:plain
Alexaを持ち出して外で遊ぶ

Core NFCを使ったゲームアプリ

これはまだ未公開なのですが、Core NFCを使ったゲームアプリをつくりました。ブルーパドル社でのお仕事。既に何種類かのゲームが遊べるのですが、手前味噌ながらかなり楽しいです。早く公開したいですがもうちょっと先になりそうです。

Core MLを使った写真の自動分類機能

とあるIoTスタートアップにて。モデル自体は社内の機械学習エンジニアの方がつくったものが既にあり、それをCore MLで使えるように変換するところからスタート。精度やパフォーマンスの検証、どういうUXに落とし込むのがいいかの検討を経て、当該企業のiOSアプリのいち機能として実装しました。社内βテストののち、近いうちにリリースされる見込みです。

ARKit、Metalを使った機能

GraffityというAR落書きSNSアプリ(最近出た2.0ではARビデオ通話アプリに)の開発をお手伝いしました。ARKitをプロダクトとしてがっつりやっている会社というのは(ゲームを除いて)たぶんまだ多くはなく、しかもMetalシェーダを書くという今の興味にがっちりはまるお仕事でした。2

技術顧問

最近立ち上がったとある会社に技術顧問として関わらせていただいてます。優秀な方々が開発していて、正直なところ技術を顧問できてるかは疑問ですが、年齢的にボードメンバーと開発メンバーのちょうど中間だったりするので、開発陣と経営陣のコミュニケーションの橋渡し役をしたり、色んな現場を見てきたならではの視点からプロダクト全体の方向性について意見を言ったりといったところではお役に立ててるのかなと。立ち上がったばかりのスタートアップで状況は常に動き続けているので、自分がどこで役立てるのか、慎重に見定めて行動していきたい所存です。

その他

Alexaスキル

すごく簡単なものですが、Alexaスキルをつくり、ブルーパドルメンバーで遊んでみたりしました。これ自体はストアで公開するほどのものではないのですが、「音声インターフェースアプリケーションはこんな感じでつくる」というのが掴めてよかったです。

ウェブのマークアップ

ブルーパドル社ではマークアップも経験しました。htmlとcssの概念ぐらいはもちろん理解してましたが、gulp、pug、scssというような最近の書き方はまったく知らなかったし、レスポンシブ/スマホ対応というのはそういうことなのねというのを知れたのも良かったです。残念ながらJSまでは時間的に手が回らず。

AV Foundationを使うiPadアプリ

GitHubの僕のとあるリポジトリを見て、海外の会社より依頼をいただきました。AV Foundationの最近さわってないAPIが関わるところだったので、自分のローカルコードベースを再整備しておく意味でもこれはやっておきたかったのですが、タイミング的に一番忙しい時期で、「次の休日に1日だけやってみて、間に合いそうならやる」と先方に伝え、1日やってみた感触では保ち時間では到底終わりそうにないためゴメンナサイしました。

Fyusion社のお仕事

アメリカでの雇い主であるFyusionより、ちょくちょくタスクが来てました。フリーの仕事で手一杯で機能開発までは手が回りませんでしたが、僕が実装した部分について質問に答えたり、日本のクライアント関連の対応をしたり。

個人活動

はじめて技術書を個人で出版

iOS/macOSGPUインターフェースであるMetalの入門書を書き、「技術書典4」にて販売しました。

shu223.hatenablog.com

総括

実績がぼやけている?

この2ヶ月、夜も休日も仕事をしていてものすごく忙しかった気がするのですが、こうやって列挙してみると、不思議なもので「もうちょっとできたのでは」という気がしてきます。

大小のプロジェクトが順不同で入り混じっているので、工数順に並べ替えてみます。

Metal入門執筆(9人日) > ARKit+Metalを使った機能開発 > Core MLを使った機能開発 > 技術顧問 > Webマークアップ > Core NFCを使ったアプリ開発 > その他(それぞれ1日かそれ未満)

左端と右端以外はあまり大差なく、のべ5〜8人日ぐらい。こうして個々の工数を意識してみると、要は分散してしまってるのだなと。

これはなかなか悩ましい問題です。いまのところは、AlexaやWebをやってみるといった「寄り道」は、これまでiOSにフォーカスしすぎた自分には必要なもので、逆に「プロフィールに書いたときにわかりやすく目立つ実績」(例: 有名なプロダクトをほぼまるっと実装、みたいなの)は、いま仕事の依頼が増えても手が増えるわけでもないので、こだわりすぎるところではないかなと考えています。

iOSエンジニアとしてのリハビリ

1年半にわたってひとつの会社にフルコミットしてきたのち、ひさびさにフリーランスとして色々な現場に行ってみるとまず気付いたのは、iOSエンジニアとしての総合力が落ちているということでした。Fyusion社では機械学習・3Dプログラミング・GPU制御といった新しいフィールドを開拓できた一方で、そういった技術を利用する機能の開発に関わることにフォーカスしていたためか、UIKitの細かい挙動とか、DBまわりとか、Swiftの最近のデファクト系ライブラリとか、そういう今までは普通にキャッチアップできていたところが疎くなっていて、浦島太郎になったような心持ちでした。

専業iOSエンジニアが書いたさまざまな現場のコードに触れ、ひさびさに日々の仕事でSwiftを書き、フルスクラッチでアプリもつくり・・・という中で、だいぶ勘を取り戻せた(キャッチアップできた)実感のある2ヶ月でした。

興味のある技術分野のお仕事

MetalやARKitといった最近興味を持っている分野のお仕事や、Core MLやCore NFCといった新しいフレームワークを実プロダクトで使う機会にも恵まれ、ただただ楽しかったです。

心残りは得られた技術ノウハウ3をアウトプットできてない点。たとえばCore NFCとか、ARKitとか、実プロダクトで使ってみてこそ得られる細かい知見がいろいろとありますが、今の所ローカルメモの中で埋もれています。

技術書の個人出版という新しい可能性

前身ブログ、QiitaGitHubと、たくさん「技術情報発信」を行ってきましたが、基本的にそれら自体は無収益でした。書籍を書くこともありましたが、フルコミットで2ヶ月とかかかって、印税は「3日受託開発した方が稼げる」ぐらい。

自分に学びがあるし、発信した内容からお仕事に繋がることもあるのでここでご飯を食べられる必要はないのですが、問題は、フリーとしての仕事(しかもおもしろい)がたくさんあるとき、それらを断ってまで(=自分の時間を1日n万円で買ってまで)新しい技術を勉強する選択がなかなかできない、というところにありました。

そんな折、今回「Metal入門」というニッチな技術書を執筆し、出版社を通すことなく個人で販売してみたところ、なんと簡単に収益が商業本の印税を超えてしまいました。

執筆に使った時間をカウントしてみると、のべ9人日ぐらい。この内訳としても、半分ぐらいは本としての体裁を整えるためにRe:Viewと格闘する時間だったり、印刷所を選んだり入稿方法について調べたりする時間だったりしたので、2回目、3回目とやっていくうちにもっと短縮できるはずです。そうすると、いずれ(下地となるブログ記事等が既にある前提で)技術情報発信の時間単価が受託開発の時間単価に並ぶというのも可能性としては考えられ、これは個人的には非常にエポックメイキングな出来事でした。

ブルーパドル社での非常勤メンバーとしての関わり

ブルーパドル社では毎週「ハッカソン」と称し、なにか簡単なものをつくってそれをベースにいろいろ遊んでみつつブレストする、ということをやってます。これがめっちゃ良くて、自分でアイデアを出す脳みそをまた久々に使うようになったし、家で眠ってるガジェットを掘り起こして触ってみる機会にもなってます。(上述したAlexaスキルはそのうちのひとつ)

また僕が普段フリーランスとしてお手伝いしているスタートアップの世界と、ブルーパドル社の主な事業領域である広告の世界、すぐ隣にあるようでまったく別の世界である点もおもしろいです。同じようなプログラミング言語フレームワークを使っていても、優先するポイントや考え方が違う。それに付随してスピード感とかも違ってくるし、それぞれの業界にいる人達の興味やトレンドも違う。

いろんな面でとにかく新鮮で、毎日多くの学びがあります。

今後の展望

冒頭に書きましたが、フリーランス活動は一区切りし、5月はひさびさにサンフランシスコに戻ってFyusion社にフルコミットします。6月頭はWWDCで、中旬ぐらいからまたフリーランスを再開する予定です。


  1. 許可をいただいた会社だけ社名を書いています。自分が関わったプロダクトや機能がまだ出ていない会社については、出たら聞こう、と思ってたのでまだ伏せています。

  2. ちなみにアメリカで所属しているFyusion社と事業領域がかぶるところがあるといえなくもない(AR)ので、そこらへんはあらかじめあちらのボードメンバーに了承をとりました。

  3. もちろんその会社固有の技術情報ではなくAPIの使い方とかハマりどころとか、あくまで一般的な話

[書評]iOS/Androidアプリ開発の総合解説書 - モバイルアプリ開発エキスパート養成読本

著者のひとり、森本さん(@dealforest)および版元の技術評論社様よりモバイルアプリ開発AndroidiOS)を解説する技術書「モバイルアプリ開発エキスパート養成読本」をご恵贈いただきました。

f:id:shu223:20170530170038j:plain

この表紙に見覚えがある方もいらっしゃるかもしれません。そう、本書の刊行は1年前、2017年4月24日です。Swift 3、iOS 10Xcode 8とメジャーバージョンにして最新からひとつ前になってしまった数字を見るにつけ記事を書くのが遅れたことを申し訳なく思う気持ちを抱きつつも、いや、バージョンが変わってしまって注目度が下がっているかもしれない今こそこの良書を改めて紹介するタイミングなのではと。

たとえば「Swift 3入門」という記事がありますが、この章では3からの大きい変更である「命名規則」について詳しく解説されています。これはSwift.orgのAPI Design Guidelinesに書かれている1内容で、これはSwift 4になった今でも重要ですし、これを日本語で解説してくれているまとまった情報源というのは貴重ではないでしょうか。

またiOS 10の新機能/新API群も、iOS 12がそろそろ発表されるであろう今こそ、これからiOS 9を切り、いよいよiOS 10APIを積極的に使っていくぞ、という時期なのではないでしょうか。User Notificationsフレームワークによって新たに可能になったリッチなpush通知や、Haptic Feedback等は多くのアプリにとって導入を検討する価値があります。

(User Notifiationsを利用したリッチなプッシュ通知 2

ちなみにiOS 10からの機能ではありませんが、日本では同時期から利用可能になったということで、本書ではApple Payの実装についても詳しく解説されているのも貴重なポイントです。

Xcode 8の章も、(当時の新機能である)Memory Graph DebuggerとInstrumentsを両方活用してメモリリークデバッグする方法や、PlaygroundでCocoaPods/Carthageを使う方法など、さらっと実践的なTipsが書かれていたりします。他にも「なぜXcode Extensionが導入されたのか?」「Automatic Signingで困るケース」等々、とにかく開発者視点だなと。

他の解説書にはない、実際の開発現場に即した内容

iOSアプリ開発やSwiftの入門書は数多出ています。いずれの書籍にも重要なことが書かれていますし、アプリをつくれるようにはなるでしょう。しかし、実際に会社に入り、ひとつのサービス/プロダクトを継続的に開発・運用していく場合、それら既存の本に書かれていることとはまた別の知識が多く必要になります。

本書ではリアクティブプログラミング(RxSwift)、設計手法、テスト、運用ツール(Fastlane等)、mBaaS(Firebase)といった、他の書籍ではなかなか扱わないであろう、しかし昨今の開発現場では必須ともいえるテーマについても書かれています。

目次

目次と、それぞれの著者を載せておきます。現場でバリバリやってるあの人やこの人が書いてます。また本記事はiOSエンジニア視点で書いてますが、Androidについても同じテーマで書かれています。

第1章: モバイルアプリ開発の基礎知識

  • 1-1 モバイルアプリ開発を取り巻く最近の動向…… 黒川 洋 坂田 晃一

第2章: Android開発最前線

  • 2-1 快適な開発を実現! Kotlin徹底入門…… 藤田 琢磨
  • 2-2 最新Android Studio入門…… 山戸 茂樹
  • 2-3 アプリの使い方を大きく変えるAndroid 7.0/7.1の新機能…… 山田 航

第3章: iOS開発最前線

  • 3-1 Swift 3.0入門…… 田坂 和暢
  • 3-2 iOS 10入門…… 熊谷 知子
  • 3-3 Xcode 8入門…… 森本 利博

第4章: リアクティブプログラミング入門

  • 4-1 リアクティブプログラミングとRx…… 黒川 洋
  • 4-2 RxJava実践入門…… 黒川 洋
  • 4-3 RxSwift実践入門…… 坂本 和大

第5章: 現場で役立つモバイルアプリ設計・開発

  • 5-1 メンテナビリティに優れたAndroidアプリを作るための実践ガイド…… 小形 昌樹
  • 5-2 タイプセーフでモダンなiOSアプリの設計…… 鈴木 大貴

第6章: 現場で役立つテスト

  • 6-1 モバイルアプリのテスト事始め…… 山戸 茂樹
  • 6-2 Androidアプリのテスト…… 藤田 琢磨
  • 6-3 iOSアプリのテスト…… 森本 利博

第7章: 運用に役立つツールの使い方

  • 7-1 モバイルアプリの運用に役立つツール…… 志甫 侑紀
  • 7-2 Androidアプリの運用に役立つツール…… 志甫 侑紀
  • 7-3 iOSアプリの運用に役立つツール…… 坂田 晃一

第8章: 今注目の「統合アプリプラットフォーム」Firebase活用入門

  • 8-1 今注目の「統合アプリプラットフォーム」Firebaseとは…… 山田 航
  • 8-2 Firebaseをアプリに導入しよう…… 山田 航
  • 8-3 導入したFirebaseを運用してみよう…… 山田 航

まとめ

そんなわけで、「モバイルアプリ開発エキスパート養成読本」、他の書籍には書かれていない「実際の開発現場に即した実践的な知見」にあふれていて、非常に良い本なので気になった方はぜひ。Kindle版もあります。

モバイルアプリ開発エキスパート養成読本 (Software Design plus)
山戸 茂樹 坂田 晃一 黒川 洋 藤田 琢磨 山田 航 田坂 和暢 熊谷 知子 森本 利博 坂本 和大 小形 昌樹 鈴木 大貴 志甫 侑紀
技術評論社
売り上げランキング: 231,722

  1. 本書はSwift Evolutionのproposalをベースに書かれています。

  2. 画像はiOS 10 Samplerより

ニッチな技術書を書いて #技術書典 に出展してみたら想像以上に需要があった話

昨日「技術書典4」にて、iOS/macOSGPUインターフェースであるMetalの入門書を販売してきました。初出展、初参加なので雰囲気を想像するのがなかなか難しく、ニッチな技術書なのできっと大量に余るだろうなと想像してたのですが、ありがたいことに用意した100部が完売。こういう本でもこれだけ需要があるということに驚き、感動した1日でした。

以下振り返りになります。

本の出来が最高だった

印刷は「日光企画」さんにお願いしました。

僕は学生時代に製本工場で日雇いのバイトをしたことが何回かあって、そこはちょっとしたことですぐに怒鳴るおじさんとかいて非常に緊張感のある職場でした1

というわけで印刷所=怖いというイメージしかなかったのと、サイトをみると情報量が多すぎてどうすればいいのかわからなくてビビっていたのですが2、開催一週間前になってやっと勇気を出して日光企画さんに電話してみたところこれがまぁめちゃくちゃ親切で、質問に丁寧に答えてくれるし、入稿したときも午前中にすぐに確認の電話をくれて、ああ印刷所って怖くないんだ、とイメージを改めた所存です。

そして開催当日の朝、会場のブースに届いていた箱を開けてみると、

f:id:shu223:20180422101931j:plain

最高。

A5というコンパクトさと130ページのちょっとした厚み、表紙のマットPP加工、透明度15%の薄いロゴ。僕は技術書が好きで電子版隆盛の今でも装丁によっては紙の本を買ったりしますが、これは普通に自分でも欲しいと思える出来に仕上がっていました。

売上

書籍(製本版)は1200円、電子版(PDF)とのセットで1500円。4分の3ぐらいの方が電子版セットの方を選択されました。プラス「普及版」という廉価バージョンと、BOOTHで前日に出していた電子版がイベント当日にもポツポツ売れたのもあり、この日の売上は約18万円でした。

今後も電子版や再販、コンテンツの横展開で収益がありえること、そしてそもそも商業誌だと絶対に企画が通らなそうな(≒初版2000部は売れなさそうな)ニッチな分野で本を書いて、それなりに稼げたということに非常に可能性を感じております。

とはいえそれもこれも、マニアックな技術書を買いに6000人もの人達が集まる技術書典というイベントあってのこと。本当にありがたい限りです。

もっと部数を増やすべきだったか?

  • 100部完売したのが14時過ぎ。ペース的に150部だと完売はしなかったと思われる
  • それにしてもわざわざ買いに来てくれた人のぶんがなかったのは申し訳無さの極みなので、次は余らせるぐらいに刷ります
  • とはいえ今回の100部も「絶対余る」と思った数なので難しい。。

その他反省

  • 技術書典のシステムへ情報を登録していなかったため、後払いシステム(QRでの購入)が電子版セットで利用できなかった
  • 同じく、一緒に出ていた多賀谷さんがそのへんのシステムを利用できなくて申し訳なかった(システムに価格を入力したのが前日)
  • 値段体系が複雑になってしまった
    • 「普及版」の存在が話をややこしくしてしまった
    • よくわからないとお客さんは帰る
    • 後半は説明の仕方がこなれてきた。言い方大事。
  • 売り子として未熟すぎた
    • シリアルコードの紙をチョキチョキ切る作業をやってたり
    • 「どうぞ見てってください」のひとことは大事
    • って家に帰ってから思った

その他の学び

  • 印刷所の入稿期限は想像以上にギリギリまで行ける(=ギリギリまで執筆できる)
    • 開催前週の火曜深夜に入稿したが、実際のところまだ1日ぐらい猶予があった

  • おつりは6万円ぶん用意していったが、使わなかった

  • テーブルを覆う布はあってもなくてもよかったかも
  • ブースを構える側の気持ちがわかったのは良い副産物だった

    • いままでこういうブース形式のところに近寄るのが苦手だった
    • 手にとって、買わなくても全然気にならない。手に取ってくれるだけでも嬉しい
    • というわけで完売後に他のブースまわるの楽しかった
  • 本としての佇まいをカッコよくすることは大事

    • 自分で開場を周ったときも、かっこいい本は遠目からでも気になった

今後の展望

  • これでMetal人口増えたら嬉しい
  • Kindle版も出したい
  • 2冊目3冊目も出したい
    • 技術書典5も通ったらvol.2出したい

おわりに

技術書典4、最高でした。運営のみなさま、参加者のみなさま、お買い上げいただいたみなさま、本当にありがとうございました!技術書典5ももちろん応募します!

Metal入門、電子版は4/24まで1500円のところ1200円で販売しております。

booth.pm


  1. 深夜〜朝まで働いて1.5万円ぐらいもらえる当時(20年前)としては破格の仕事だった

  2. こういう理由で、当初「製本直送.com」というシンプルな1部から印刷可能なサービスで刷ろうかなと思っていました。が、製本直送.comだと印刷原価が一冊1500円以上になることがわかって最終的に断念

#技術書典 4で「Metal入門」という本を販売します

iOS/macOSGPUインターフェースMetalの入門書を書きました。その名も「Metal入門」です。4月22日に開催される技術書の同人誌イベント、技術書典4向けに書いたもので、初めて出版社を通さず個人で書いた書籍になります。ちなみに日本語としては初のMetal解説書1でもあります。

本の詳細

A5版(技術評論社の実践入門シリーズのサイズ)で全128ページ。一時150ページに達したのですがどうにかこうにか切り詰めてここまで収めたので、ギュッと詰まってます。小さくて(普通の技術書よりは)薄いので、カバンに入れておいても邪魔にならないサイズです。

f:id:shu223:20180418104931p:plain

ちなみに「GPUと戯れてみたいけどまずはほんのさわりでいい」という方のために、全48ページの「普及版」も用意しております。

GPUを操ることに興味のある方、GPUの気持ちをもっとわかりたい方はぜひ!

価格

無料サンプル

まえがき・目次・各章のさわりを試し読みできる無料サンプルをこちらからダウンロードしていただけます!

booth.pm

通常版

(製本仕様)128ページ/平綴じ/マットPP

  • 製本版のみ: 1200円(会場限定・・・の予定)
  • 電子版のみ: 1200円(4/25以降は1500円)
  • 電子版とのセット: 1500円(会場限定)

普及版

(製本仕様)48ページ/中綴じ/表紙なし

  • 製本版のみ: 500円(会場限定の予定)
  • 電子版のみ: 検討中
  • 電子版(通常版※)とのセット: 検討中
    • ※普及版の電子書籍版は作成しない予定です

目次

  • はじめに
  • 第1章 Metal の概要
    • 1.1 Metal とは
    • 1.2 Metal の用途
      • UIKitでもMetalが利用されている
      • 増え続けるMetal関連機能
    • 1.3 Metal を構成するフレームワーク群とシェーディング言語
  • 第2章 Metal の基礎
    • 2.1 Metalの「最初のハードル」
    • 2.2 「背景にある概念」を理解する
    • 2.3 Metalの基本クラスとプロトコル
      • MTLDevice
      • MTLCommandBuffer
      • MTLCommandQueue
      • MTLCommandEncoder
      • MTLBuffer,MTLTexture
    • 2.4 MetalKit
      • MTKView
      • MTKViewDelegate
      • MTKTextureLoader
  • 第3章 入門その1 - 画像を描画する
    • 3.1 描画処理のためのセットアップを行う
    • 3.2 画像をテクスチャとしてロードする
    • 3.3 描画処理を実行する
      • ドローアブル
      • MTKViewのcurrentDrawable
      • ブリットコマンドエンコーダ
      • 描画処理の全体
  • 第4章 入門その2 - シェーダを利用する
    • 4.1 Metalシェーダの基礎
      • シェーダとは
      • MetalShadingLanguage(MSL)
      • Metal シェーダファイルと Metal ライブラリファイル
      • MTLLibraryMTLFunction
    • 4.2 「画面全体を一色に塗る」シェーダの実装
      • 1.Metalシェーダファイルの作成
      • 2.頂点シェーダ関数の実装
      • 3.フラグメントシェーダ関数の実装
    • 4.3 CPUプログラム側の実装
      • シェーダにデータを渡すためのバッファを準備する
      • レンダリングパイプラインを用意する
      • MTLRenderPipelineStateの生成タイミング
      • レンダリングコマンドをエンコードする
  • 第5章 入門その3 - シェーダでテクスチャを描画する
    • 5.1 テクスチャを扱うシェーダの実装
    • 5.2 テクスチャ内座標データをシェーダに渡す
    • 5.3 テクスチャをシェーダに渡す
    • 5.4 ピクセルフォーマットを合わせる- 第6章 Metal のハードウェア要件
    • 6.1 歴代iOSデバイスのMetalサポート状況
    • 6.2 MTLFeatureSet
    • 6.3 Metal非対応デバイスの判定- 第7章 GPGPU プログラミング入門
    • 7.1 コンピュートシェーダ - コンピュートシェーダとカーネル関数 - 頂点シェーダ+フラグメントシェーダとの違い.
    • 7.2 スレッドとスレッドグループ
      • スレッドグループのサイズと数を指定する
      • シェーダ側でスレッドの位置を取得する
    • 7.3 GPGPUの実装例 - パススルーコンピュートシェーダ - CPUプログラム側の実装
  • 第8章 MSL 入門
    • 8.1 Metal のグラフィックスレンダリングパイプライン
    • 8.2 .metalファイルと.metallibファイル - デフォルトライブラリ - コマンドラインユーティリティを用いた Metal ライブラリのビルド
      • 実行時にMSLをコンパイルする
    • 8.3 FunctionQualifier(関数修飾子)
    • 8.4 AttributeQualifier(属性修飾子)
      • [[position]]
      • [[vertex_id]]
      • [[stage_in]]
      • [[buffer(n)]]
      • [[texture(n)]]
      • [[sampler(n)]]
      • [[threadpositionin_grid]]
      • [[threadgrouppositioningrid]], [[ threadsper_threadgroup ]]
    • 8.5 Address Space Qualifiers(アドレス空間修飾子)
    • 8.6 型
      • テクスチャ型
      • サンプラー型
    • 8.7 GLSLをMSLに移植する
      • 型の違い
      • 戻り値の違い
      • プロトタイプ宣言
      • 作例
  • 第9章 Metal Performance Shaders
    • 9.1 デバイスがMPSをサポートしているかを確認する - 9.2 ガウシアンブラー - 9.3 MPSUnaryImageKernelを継承する他の画像処理カーネルクラス
    • 9.4 画像のリサイズ - 9.5 画像の転置(行と列の入れ替え)
  • 第10章 Metal の最適化
    • 10.1 スレッドグループサイズの最適化
      • スレッドグループサイズの決定方法 - 不均一スレッドグループサイズを利用して最適化する - 10.2 ArgumentBuffers
      • ArgumentBuffersの概要 - ArgumentBuffersの実装 - 第 11 章 Metal のデバッグ
    • 11.1 GPUフレームキャプチャを有効にする
    • 11.2 Xcode上でGPUの負荷を確認する
    • 11.3 GPUフレームデバッガ
      • シェーダにバインドされているリソースの一覧を見る
      • パイプラインの統計情報
      • パフォーマンス改善のヒント
      • issueを見る
      • シェーダの処理毎のパフォーマンス確認
    • 11.4 GPUフレームキャプチャをプログラムから制御
    • 11.5 InstrumentsのMetalSystemTrace
    • 11.6 ラベル
    • 11.7 デバッググループ
    • 11.8 GPUで利用中のメモリサイズを調べる
  • 第 12 章 Core Image × Metal
    • 12.1 Core ImageとMetalのシームレスな統合
    • 12.2 Core Imageのフィルタ結果をMetalで描画する
      • MetalによるCIImageのレンダリング
      • 実装例
    • 12.3 CoreImageのカスタムフィルタをMetalで書く
    • Metalでカーネルを書く利点
    • MSLによるカスタムカーネルの実装
    • Metalカスタムカーネルを利用するためのビルド設定
  • 第 13 章 SceneKit × Metal

    • 13.1 Metal で SceneKit のマテリアルを描画する
      • SCNProgramの実装
      • SCNProgramで利用するシェーダの実装
      • SCNProgramで用いるシェーダに値を渡す
    • 13.2 他のSceneKitとMetalの連携機能
      • SCNTechnique
      • shaderModifiers
      • SCNRenderer
  • 第14章 ARKit × Metal

    • 14.1 マテリアルをMetalで描画する
    • 14.2 MetalによるARKitのカスタムレンダリング
  • 第15章 Core Video × Metal
    • 15.1 Metalでリアルタイム動画処理
      • CVImageBufferからMTLTextureを作成する - CIContextを利用
      • CVImageBufferからMTLTextureを作成する - CVMetalTextureCacheを利用

余談:技術書典で本を出す理由

僕はフリーランスエンジニアでして、1日n万円の単価でお客さんに技術力を提供して生計を立てております。ありがたいことに今のところは食べていけております。

しかしお客さん仕事は基本的に「僕がプロとして間違いなく貢献できる領域」についてご依頼いただけるものなので、それだけでスケジュールを埋めてしまうと、

  • 仕事で必要なわけではないが単に興味がある
  • 今は素人だけど学んでいきたい

というような、「今は仕事になってない技術」を開拓していく時間が減ってしまいます。

なので理想的にはスケジュールをびっちり埋めずに、興味のある技術を勉強したり、それを発信したり、オープンソースで公開したり、という時間を確保したいという気持ちはあるのですが、まぁでもお客さんの仕事もおもしろいし勉強になるし、お金ももらえるし・・・ということでどうしても仕事で埋めてしまいがちです。

そこでよく思うのが、技術の勉強自体をマネタイズできれば、「既にスキルがあって、稼げる」フリーの仕事とバランスとってやれるようになるのになぁ、ということです。興味があってしかも稼げるなら、単純に天秤にかけるときに重みがかかる。

幸運にも、「興味のある技術を勉強しては発信してたらお仕事につながった」という例も過去にはあります(BLEとか)。しかしブログやOSSを見て仕事の依頼をいただける、というのは自分ではコントロールできないので(要は「たまたま」なので)その結果をあらかじめ織り込むことはできない。やっぱり技術情報発信そのものでマネタイズできたら理想的だなと。実際に可能かどうかは別にして、手段は探っていきたい。

その手段の候補のひとつが個人での書籍の出版です。出版社を通してちゃんとした技術書を出すのはめちゃめちゃ大変だしあまり収入にもなりませんが、個人で出すならもっとライトに出せるんじゃないの、と。ページ数が230ページ以上じゃないといけない、ということもないし、技術書っていうジャンルはプロによる超美しい装丁じゃなくてもいいと思うし、売れなそうな企画でも自分さえやりたければGOできる。

これである程度収益になるとしたら、

勉強→ブログ→ある程度たまったら本

というサイクルができたらいいな、と。そういうサイクルをまわしているうちにランダムイベントとしての「お仕事の依頼」もあるかもしれない。

で、そんなことを思い続けて案の定一文字も書くことなく4年程経ち、そこに技術書典という超素晴らしいイベントが出てきたので乗っからせていただいた次第です2。たとえあんまり売れなくても、今回技術書典ドリブンでついに個人で本を書き上げることができたというだけでも、自分的にはかなりの達成感があります。

まとめ

余談が長くなってしまいましたが、つまりいろいろ思うところがあり個人で本を書いて技術書典で販売することになりました!

Swinjectの多賀谷さんと共同ブースです(執筆はそれぞれ)。

techbookfest.org

4月22日、「き04」でお待ちしております!


  1. 章単位でいえば、PEAKS社刊行「iOS 11 Programming」のMetalの章(私が執筆)が初となります

  2. 技術書展が終わったら、noteで単発の技術チュートリアル記事販売とかも試してみたいと思ってます。

try! Swift 2018の思い出 #tryswiftconf

try! Swiftは非日常感がありどの年も色々と思い出があるのですが、今年はスピーカーとしての参加ということで最初にお声がけいただいた9月から約半年感、ずっとtry! Swiftを意識して行動してきたといっても過言ではなく、感慨深さもひとしおでした。

終わってからの2週間、仕事の状況がガラッと変わったこともありしばらくそんなことも忘れるほど忙殺されていたのですが、最近アップされた公式の写真を見ていると色々と思い出されたので、(もう発表内容についての補足記事は書いたものの、)せっかくなので発表内容以外の振り返りについて書いておきたいと思います。

2017年9月: 打診いただく

9月某日、オーガナイザの pancake 氏よりお話をいただきました。

iOS Top 10 Conferences にも選ばれ、海外からも多数の参加者のある名カンファレンスに招待されるチャンスはもう二度とないかもしれません。実際のところ、try! Swift Tokyoは東京開催で同時通訳が行われるので僕でも呼んでいただけましたが、英語主体のカンファレンスではなかなか厳しいのが現実だと思います。1

そんなわけで、打診いただいたその場で二つ返事でお受けしました。

この時点で発表の軸はMetalしかないかなと考えていました。僕が2017年に興味をもって取り組んでいたのは機械学習、Metal、ARあたりですが、機械学習は結局実務で取り組む機会がなく 2、ARはまだARKitの薄いレイヤしか知らないのでカンファレンスで話すような体系立った知見がない。普通に仕事で使ってる&他に話す人もいなさそうなMetalしかないだろう、と。

〜2018年1月: 技術調査

12月にはMetalのアドベントカレンダーも立て、どれだけMetal好きなんだ、と思われたかもしれませんが、常に頭にあったのはtry! Swiftで発表するからには、知見をしっかりためないと、というところでした。

GPUまわりはもともと興味のあったところですが、try! Swift登壇が決まってなかったら、あんなにMetalMetalせず、機械学習とかARとかその他iOSの新機能とか、もうちょっと幅広く勉強したり記事書いたりしてたと思います。

2017年12月: 発表のタイトルと概要が決定

12月だったかに発表のタイトルと概要を3案ずつ提出して、ナターシャさんがチョイスする、というのがありました。

僕が出した3案はどれもMetal縛りでしたが、それぞれちょっとずつ「切り口」が違ってました。

  • UIImageView vs Metal
    • 今回のやつ。Metal自体の解説ではなく、「普段意識する機会の少ないGPUレイヤに目を向けてみる」というのがコンセプト。

MetalはGPUへのアクセスを提供するAPIで、OpenGLより10倍速いという謳い文句で登場しました。本セッションではMetalの基礎を解説しつつ、そのグラフィックス描画性能をUIImageViewと比較してみます。 MetalのAPIを直接利用する機会がなくても、Metalはあなたのアプリの裏で暗躍しています。身近なクラスとの比較を通じて、普段我々が意識することのないGPUのレイヤで何が起きているのか、目を向けてみるきっかけになればと思います。

  • 非ゲームアプリにおけるMetal / Metal for non-game apps
    • 「Metalってゲーム用でしょ?」いやいやそうじゃないアプリでも実際に使ってるんですよ、ということを示しつつMetalの基礎について話す。

「Metal=本格的なゲーム向けのAPI」と考えてしまい、興味の対象外としている開発者は多いのではないでしょうか。そんなことはなく、Metalはグラフィックス処理から機械学習の計算まで、「非ゲーム」アプリにおいても大いに活用の場があります。本セッションでは、実際にAppStoreにリリースされているアプリでのMetal活用事例を題材に、その基礎と実装方法について解説していきます。

  • iOS GPU Programming
    • 普通にMetalについて解説する。ただしなるべくGPUプログラミング未経験者にもわかりやすく。

GPUはその名の通りグラフィックス向けのプロセッサですが、今ではその並列演算処理能力に着目して、ディープラーニングの行列演算のような汎用的な計算で用いられるケースも増えてきています。 そんなGPUへのアクセスを提供するAPIが、Metalです。本セッションでは、Metalを利用してiOSバイスGPUで処理を行う方法について、初めての方でも理解できるよう基礎から丁寧に解説します。

で、"UIImage vs Metal"がチョイスされたわけですが、たとえばもし2番目のになったとしたら、Fyusion社の事例(画像処理、機械学習、描画、いろんな機能で使ってる)について話すことになるわけで、そうすると、会社に許可を取らないといけない部分も多く、会社にこういう打診をするタイミングももっと遅くなってたかもしれません。そんなキャリアの判断の基準にするほどに、try! Swiftでの登壇は重要視していました。

2018年2月: スライド作成

これは2月中旬に帰国してから着手したのですが、難航しました。「Metalを使うためだけに必要な知識」は本発表のコンセプトでは基本的には不要なのですが、Metalを通じてGPUの気持ちを理解しよう、というところではこの説明をしないといけない、うーむ、みたいな。

同時通訳の方々は下調べ等の準備を行うので、2週間ほど早くトランスクリプトつきで提出する必要があったのですが、まずはできているところだけ提出して順次追加版を提出していきました。

(仙台にてもくもくスライド作成合宿)

2月後半の2週間はほぼフルタイムでtry! Swiftのスライド作成に取り組んでいました。

当日

akatsuki174 がまとめてくれたツイートより、当日の様子が分かる感じのをいくつか時系列にピックアップしていきます。

  • 登壇者としては欠かせない宣伝(英語ですべきだけど)

  • 開始前

  • すごく拡散されていた一枚(スライド全体よりも。。)

  • GPUに向いている処理とは

  • UIImageView vs Metalパフォーマンスの結果発表直前(ちゃんとワクワクしてくれていて嬉しい)

  • 🙏

  • UIImageViewは既に十分に有能だった

  • 問題1

トークの内容としてはまだ続きますが、長くなりそうなのでこのへんで。

反応(ツイート)

これについてはQ&Aで同様の質問をいただいたので、補足記事にてコメントしてあります。

shu223.hatenablog.com

反応(ブログ)

ブログ記事でもいくつか反応をいただいてます。大変ありがたいです。

tech.appbrew.io

GPUがどんな物なのかという導入からMetalを使った自作ライブラリのパフォーマンス測定、その過程で得られた知見についてのトークでした。 MetalとGPUについては知識は殆どなかったのですが、GPUとCPUでのコマンドがどのようにやり取りされているか紹介されていたので処理の概要について知ることができました。 自作ライブラリのパフォーマンス測定ではInstrumentsを使用したデバッグの過程が詳細に述べられており、非常に興味深い内容でした。個人的にはInstrumentsを上手く使いこなせていなかったので、その使用例としても面白い内容でした。 iOSアプリは画像描画の速度でユーザー体験が大きく変わるのでパフォーマンス改善をする際にはMetalの部分まで考慮して実装していきたいです。

medium.com

タイトルに「vs」と入っていますが、実際にはUIImageViewはMetalを使って構築されています。堤さんがUIImageViewのようなものをMetalを使って自作してみようとした経験を元に、Metalが何をやっているのかという部分を通じて、GPUレイヤーに目を向けてみようという話でした。Step by Stepで話が進行してゆき、わかりやすく納得感のある内容でした。

なお、ぼく個人はMetalの知識を全然持っていないのですが、そんな人が興味を持つ導入としての話になっていたのではないかと思います。

blog.lisb.direct

アニメーションなどの描画性能はアプリを作る上で決して無視することができない課題です。このセッションではUIKitの内部処理を理解した上でパフォーマンスチューニングを行うことの大切さを知るための体験談を共有してくれました。directのiOSアプリは短い時間で正確な情報をユーザーに伝えるという大切な使命があります。よりユーザーにとってわかりやすくストレスがないアプリにしていくためにMetalまで意識したパフォーマンスチューニングは大切だと強く意識するきっかけとなりました。UIKitはiOSのバージョンアップによって内部の実装が変わることもあるため、そのバージョンに応じて適切な実装を心がけます。

2018 try! swift - Nakajijapan

これは純粋に面白かったし、Metalのこともわかった気になった。

try! Swift 東京 2018 的一些見聞 - 掃文資訊

カッコ()内はGoogle翻訳

堤修一 以前也是 Kayac 的員工,算起來和我在 Kayac 還有幾面之緣。不過顯然他並不記得我,直到看到我的 badge 的 ID 才説“哦哦,就是那個頭像是小貓的男人啊”。每年 WWDC 結束後其實都會跟着他的 iOS-Sampler 項目學習新 API 的用法,受益匪淺。

(Dian XiuyiはKayacの従業員でもあり、Kayacで私と数えます。 しかし、明らかに彼は私のバッジのIDが「ああ、それはアバターが猫の人だ」と言うまで私を覚えていない。 WWDCが終了してから毎年、彼はiOS-Samplerプロジェクトに従って新しいAPIの使い方を学びます。)

這次他帶來了一個關於 Metal 的話題,探索和對比了使用 Metal 進行圖片渲染和直接使用 UIImageView 的異同。一開始給出的數據十分驚人,Metal 的結果要比 UIImageView 快上十到二十倍。但是隨着深入,發現這不過是測量錯誤和實現錯誤的疊加。實際上按照 WWDC 2017 的説法,UIKit 已經在底層使用了 Metal 進行加速。對於 GPU 相關的性能測量以及中後段通過 Metal System Trace (我自己是從來沒用過) 來尋找問題的部分很有意思。

(今回は、Metalに関するトピックを紹介し、Metalを使用して画像をレンダリングし、UIImageViewを直接使用することの類似点と相違点を調査し、対照しました。 最初に与えられたデータは驚異的でした。メタルの結果はUIImageViewより10〜20倍速かったです。 しかし、深くなっていくにつれて、測定誤差と実装エラーが重なり合っていることがわかりました。 実際、WWDC 2017によれば、UIKitは下部に加速のために金属を使用していました。 興味深いのは、GPU関連のパフォーマンス測定値と、中期および後期のセクションで、Metal System Traceの問題を探す部分(私はそれを自分で使ったことはありません)です。)

一句話總結就是,不要想着從底層折騰一套自己的 UI 渲染了,乖乖滾去用 UIKit 吧。信蘋果,得永生。

(要約すると、独自のUIレンダリングのセットを一から上に投げ捨て、UIKitでロールアウトすることについて考えないでください。 私はリンゴを信じ、永遠の命を持っています。)

https://techblog.istyle.co.jp/2018/03/05/try-swift-2018-report/

try! Swift 2018では普段あまり意識することのないlow-levelに焦点を当てた発表がいくつかあり、そのなかで一番身近に感じた発表がこちらでした。

まず発表自体がとってもわかりやすかったです!!!

また、普段何気なく書いている処理がCPU/GPUどちらで動いているのか、正直気にしたことがなかったぼくにとってはとても新鮮で、新しい気づきとなりました。

こちらは発表が終わった後に質問をしてUITableViewのパフォーマンス改善について有益なアドバイスをいただくことができました。UITableViewのパフォーマンスはほぼ全ての画面で気にしなければいけないことなので、注意していきたいです。

tid-a24.hatenablog.com

GPUのことを考えるきっかけになるセッションでした。 ゲームを作っていたころは、ずっとGPUのこと考えてる状態でしたが最近はあまり考えてません。

  • コマンドを送る時は1回にまとめる。
  • テクスチャはGPUにキャッシュさせる。

などは、基本的にMetalだけでなくOpenGLDirectXでも同じです。

shachi.hatenablog.com

vs とは書いてましたが、内容はMetalで表現すると速い……あれ? なんか変。あ、GPUとCPU切り替えてなかった。ちゃんと区分けしないと。 という「やらないと判らない知見」でした。こういう発表は後に続く人が出るので大変嬉しいし、すてき案件。

medium.com

今回は参加者が理解しやすいような題材としてUIImageView vs Metalという発表をされました。主にMetalを通じてGPUレイヤに目を向けてみようという内容でした。

私達が普段何気なく使っているUIImageViewは早いのでしょうか?ピクセルを配置するなど並列処理可能な処理はGPUに任せた方がよりパフォーマンスが良いのではないでしょうか?

こういった切り口で独自のカスタムクラスを作成し実測値を元に発表されました。

jp.corp-sansan.com

MetalImageViewという、UIImageViewのように画像を扱えるMetalラッパークラスの実装を行った経験を通じて、GPUレイヤーの処理を細かく追っていくという内容でした。XCodeのInstrumentsであるMetal System Traceを効果的に利用してボトルネックを特定し、パフォーマンスチューニングを行っていく過程はとても勉強になるもので、GPUに関する知識が全くない状態でも分かりやすく、大変興味深い内容の発表でした。

After try! Swift

try! Swift 直後の土曜、ワークショップは早退し(すみません)、翌日に日本を発ってしまうFyusion社の同僚たちと東京散策に行ってました。

原宿(同僚たちが既にそこに行ってた)を散策し、カフェで雑談したあと、僕自身も初めてのパチンコ屋に行き、

松阪牛の焼き肉を食べ、ゴールデン街へ。

f:id:shu223:20180317144735j:plain
ゴールデン街(写真は昨年のもの)
バーテンの方に「日本語上手ですね」と言われましたw

おわりに

  • 来年は登壇のプレッシャーもないことだし、もっと海外の人たちにどんどん自分から声をかけてコミュニケーションしたい
  • そろそろSwiftちゃんとやる(仕事ではObjective-C...)

  1. CfPを出して採択されるコースは別として。

  2. 社内に機械学習のプロが何人もいるので。。

try! Swift Tokyo 2018で登壇しました&補足 #tryswiftconf

先週開催されたtry! Swift Tokyo 2018にて登壇させていただきました。

f:id:shu223:20180301180646j:plain

タイトルは "UIImageView vs Metal" ですが、Metalの使い方の話「ではなく」、Metalを通じて普段意識する機会の少ないGPUレイヤに目を向けてみるという内容となっております。

実際のところ多くの開発者にとってMetalは使う予定がない/興味がないもので、この一大イベントで800人もの方々の前で関係のない話をしても仕方がないので、せめて何か興味を持って聞いてもらえる切り口はないだろうか、ということでお話をいただいてからの数ヶ月間悩みに悩み、あれこれ検討して、この方向性で行くことにしました。

というわけでMetalを使ってない、使う予定がないという方々にも多少なりとも興味を持っていただける内容になったのではないかと思います。

日本語版スライドはこちらです。

また、発表で用いた英語版はこちらになります。

補足/FAQ

Metalについて話しつつも主題としては別のところにある、というそもそもの発表の構造と、時間の制約もあり、説明が不十分だった部分もあるのでこちらにて補足させていただきます。

トーク内に出てくる「対策」は必ずしもベストプラクティスではない

トークの中で、「問題1の解決策として2つのコマンドを1つのコマンドバッファにまとめた」というくだりがありますが、注意点として、これはベストプラクティスであるというわけではありません。

(もともとやっていたように)リサイズは先に済ませておいて、draw(in:)では描画処理だけやるのが望ましい、とも考えられますし、そもそも描画処理をMTLBlitCommandEncoderではなくMTLRenderCommandEncoderMTLComputeCommandEncoderでやっていればリサイズ処理を別途やる必要もない(シェーダ内で同等のことをやればよい)とも考えられます。

前者であればではどのようにCPUとGPU間で(お互いを待ち合うことなく)連携するか、という話が必要になってきますし、後者の方向性で実装するのであれば、シェーダ等についての解説も必要ですし、直面する問題も変わってきます。いずれにせよこのトーク全体の構成に大きく影響しますし、シェーダやエンコーダ云々の解説をするのであればトークの主旨すら変わってくるでしょう。

このトークのこのパートで伝えたかったのはあくまで "CPUとGPUの処理フローに配慮する" という「視点」です。

また問題2の対策としてキャッシュする、という話もしましたが、これもキャッシュするべきか否か、どのようにキャッシュするか、というのはアプリケーション次第で変わってくるので、このトークにおいて重要なのはそこではなくて、"GPUからアクセスするリソースの場所に配慮する" という「視点」です。

ごちゃごちゃと書きましたが、つまり、本トークは「このようにしましょう」というベストプラクティスを提示することを意図したものではないので、その点ご留意ください。

最終的な速度はどうなったの?

最終的な処理時間がどうなったかが気になった方は多いと思われます。処理時間ベースで問題提起しておいて改善後のものを出さなかったのには色々と理由がありまして、それらを一言で言うとすると、「今回のトークの範疇では最終結論となるような数値は出せないから」ということになります。

たとえばp38での計測方法の修正によりGPUの処理時間も加味されたものになりましたが、waitUntilCompleted()GPUの処理完了を待って時間を計算している部分はあくまでCPUにおける処理であって、依然として厳密にGPUでの処理完了タイミングを測れているわけではない、というところがあります。

そしてUIImageViewの方は単にCPU側でのメインスレッドにおける処理時間を測っているに過ぎません。これがCPUとGPUの処理フローにおけるどこまでの範囲を測っていることになるのか、それは我々はUIImageViewのソースコードを持っていないのでわかりません1

上記2点の理由により、これら2つの処理時間を並べて比較することが適切ではない、ということがそもそもの話としてあります 2

そして、具体的な数値がスライドの最後に載っていると、その数値がファイナルアンサー(=Metalの速さ)として独り歩きしてしまう恐れがあります3

上記の補足にもあるとおり今回の実装はベストプラクティスというわけでもなく、あくまで概念や視点を伝えるためのものなので、あまり意味のない数値が意味のある数値のように拡散されてしまうのを避けるために、意図的に最終的な数値は明示しませんでした。

ではMetalはどういうときに使うのか?

「UIKitの下回りがMetalになってて、Appleの中の人がしっかり最適化してくれてるので、自分で下手に低レベルAPI触るよりは普通にUIKit使えばいいよ」ということを今回のトークの中で言ったので、じゃあMetalはどういうときに使うのか、という質問をいただきました。

たとえば僕は以下のようなケースでMetalを利用しました。

  • シェーダを書いて独自の画像処理を行う
  • MPSCNNを利用する
  • ARKitのカスタムレンダリング

共通点としては「カスタムな並列処理を行いたい場合」という感じでしょうか。

当然これらの処理のあとに、処理結果の画像をUIImageに変換してUIImageViewで表示する、みたいなことをやるとそれこそまさにトーク内で話した「CPUとGPU間を行ったり来たりする」というバッドプラクティスそのものなので、そのままMetalでレンダリングすることになります。

OpenGLを使っているけどMetalに乗り換えた方がいいのか?

特に具体的に困っていることがないのであれば、乗り換える必要はないと思います。OpenGLの方がクロスプラットフォームですし。WWDCラボでAppleの人が言ってましたが、今のiOSではOpenGLもMetalの上に実装されているそうです。

今から始めるのであれば、Metalの方がOpenGLよりはシンプルでとっつきやすいのでは、と思います。初心者にとっての鬼門はGPUまわりの概念であって、そこさえ押さえてしまえば他方のGPUフレームワークに移るのはそれほど大変じゃない(=つぶしがきく)のではと。

Metalに興味はあるがどこから始めたらよいか?

スライドにもあるとおり、Metalは最小実装でも結構コードが長くなるので、初心者には「はじめの一歩目が遠い」と思います。英語ですが書籍や動画等の学習用リソースは色々とあり、僕も今となってはそれらを参考にしていますが、OpenGLDirectXの経験がない中での最初の一歩目としてはそれらは難しく、結局Appleのサンプルを頼りに四苦八苦して学びました。

で、手前味噌になってしまいますが、僕の昨年のiOSDCでの解説、およびiOS 11 ProgrammingでのMetalの章の解説はそんな「最初の一歩目が大変だった」僕の目線で噛み砕いて書いてあるので、かなりわかりやすいのではないかと自負しております。

ちなみにQ&Aブースで海外の方からこういう質問をいただいて、Xcodeのテンプレート(=比較的最小実装に近い/そのままBuild&Run可能)を色々といじってみるところから始めてはどうか、というアドバイスをしました。僕がそこから始めたので。

MetalImageViewのAPIが途中で変わってる件

p26でmetalImageView.texture = textureという感じで簡単に使えるようにする、と構想を述べつつ、p30ではmetalImageView.textureName = nameとなっていたことに、気付いた人もいたようです。

前者のように構想しつつなぜp30で後者のようにしたかというと、metalImageView.texture = textureとするにはMTLTextureオブジェクトをつくる部分が必要になるのですが、そこをラッパークラスの外に出してしまうとp30のコードが見づらくなってしまうし、MTLTextureに初期化メソッドを生やしてmetalImageView.texture = MTLTexture(named: name)ってできるようにするとコード的には構想通りになるけど、そうするとテクスチャロードが同期的になってしまう(→ その後の話の展開が大きく変わってしまう)、というジレンマにより、こんな感じになりました。

御礼

try! Swiftでの登壇は密かにずっと憧れていました。try! Swiftのフルトーク(↔LT)はCfP制ではなく主催者による招待制なのですが、僕は"Swift力"は並かそれ以下なので、このタイミングでお声がけいただけたのは本当に幸運だったと思います。Metalは、もともと興味があったのはもちろんですが、try! Swiftで話す切り口を模索するために勉強していたところも大いにあります。

結果としては、多くの方に楽しかった、良かったと言っていただき、Q&Aも(僕が閉会式に行き損ねたぐらいに)途切れることなく質問に来ていただきました。

出番が最後の方だったこともありずっと気持ちがフワフワしていましたが、非常に思い出深い3日間でした。

長期間準備され、会期中は朝早くから夜遅くまで動き回っていたスタッフの皆様、スポンサー企業の皆様、参加された皆様、どうもありがとうございました!Swiftもっと勉強します。


  1. 今年WWDCに行けたらラボで聞いてみます。

  2. ではなぜ最初にこれらの比較を行っていたかというと、計測方法において僕が実際にしていた勘違いを紹介し、その改善の流れを見ていただくことがGPUレイヤへの「視点」を理解するのに役立つと思ったからです。

  3. BLEのときにそういうことが実際にあった

パートタイムになりました

2016年10月よりサンフランシスコのFyusion社でフルタイムで働いてきましたが、今年2月16日より、パートタイム社員として働くことになりました。

・・・とだけ書くと、あれ、fire的な何か?と心配されそうですが、これは僕から希望して、どちらかというと会社に無理を聞いてもらったかたちになります。

どうなったかシンプルにいうと、今後は「アメリカにいる間は会社にフルコミット、日本にいる間はフリー」ということになりました。H-1Bビザはフルタイムである必要はないので、今後も維持されます。1

Fyusion社で、サンフランシスコで働くことは学びが多く、メンバーも魅力的な人達ばかりで、まだまだ続けたい気持ちがありつつも、興味のある技術を勉強し、発信し、そこから仕事を獲得し、さらに経験と実績を積み・・・というフリーランス時のサイクルが恋しくもあり、フルタイムで働くことに悶々とするところもありました。

で、今年の年明け早々に長い長いメールを書いて自分の考えを伝え、僕の希望と会社の要望との摺り合わせ、法務・労務的な調整etcがあって、このような形となりました。こういうわがままを受け入れてくれた会社の皆様には本当に感謝です。より濃い密度で貢献していく所存です。

アメリカと日本にいる割合ですが、1:2ということで今は考えています。3分の2はまた以前のようにフリーランスとなりますので、みなさままたよろしくお願いいたします🙇🏻

関連記事

入社の経緯と経過報告

d.hatena.ne.jp

d.hatena.ne.jp

結局どうしたいの、というあたりのキャリア観については以下の記事に書いています。

d.hatena.ne.jp


  1. 確定申告はアメリカと日本、両方でやることになります。