スタートアップの技術選定とアプリケーションプラットフォーム

photo by pexels.com *1

この記事を書いたきっかけ

niconegoto.hatenadiary.jp

「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。

アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。

— sadakoa (@sadako_a_) August 16, 2018

(Twitter上で多くの共感を集めた投稿)

例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点を分析させています。

そして僕が注目したのは以下の部分について

もっとサービスレベルの話でいくと、初めからwebでやればよかったというのもミスだったと感じている部分です。

最初にアプリで出すことにこだわりすぎてしまい、プロダクトの検証が遅くなってしまいました。ライブコマースの視聴・購入体験をよくするためにアプリでなければならないと思っていましたが実際にはwebでもほとんど遜色ないものを提供することができました。

PinQulをクローズします - niconegoto Blog

PinQul のこれまでの軌跡をみると、2017年10月にiOS版リリース。2018年04月にAndroid。5月にWeb版。という情報がありました。

つまりiOS版をリリース後に少なくとも半年はAndroid版やWeb版を開発しつつ、iOSアプリの方向性を変えPMF(プロダクト・マーケット・フィット)を探っていたことになる。 その期間を3プラットフォーム並行開発するよりWeb版一本でフォーカスしたかったな、という後悔が出てしまうのは共感できた。なぜなら我々も同じような状況で悩み、現在モバイルアプリを開発しているからです。

そんなPinQulのIF...を元に、改めてスタートアップが新規プロジェクトなモバイルアプリを今0から作りはじめるとき、技術的な観点でどの道具を選択するのか、というのを考えてみたかった。

新規プロジェクトというのは俗に言うスタートアップでなくても1企業の新規事業部が0から作り出すソフトウェア製品のことでもいいです。

2012年のビーンボール

最初にPinQulの記事を読んだ時に2012年のマーク・ザッカーバーグのインタビューから起ったネイティブ/Web論争を思い出してしまいました。

これは当時Firebug作者でありiOS向けフレームワークthree20開発者でもあるJoe Hewittを中心に開発されたネイティブ実装で評判もそこそこ良かったFacebookの公式iOSアプリを、ある時に全面的にWebベースのハイブリッドアプリに置き換えようとした所、パフォーマンス問題などが顕著になりネイティブアプリに作り替えた時のものです。

マーク・ザッカーバーグのこのきわどい発言は、その場では投資家向けの弁明も含むもので、補足もされたのですが。様々な反論や憶測を呼び、業界を騒がせることになりました。

その後FacebookはPHPの魔改造Javascript拡張からReactを生み出し、2度3度ネイティブアプリ開発への移植に挑戦した後にReact Nativeを軌道に乗せているわけで、先の弁どうりWeb技術を諦めていない。というのはガチであったことが伺えます。

www.publickey1.jp

この一件は、PinQul とFacebook のビジネスのフェーズが全く異なるにも関わらずダブって見えます。おそらく2012年時点で「Webアプリはダウントレンドで、我々はネイティブアプリにフォーカスする必要がある」という空気が業界を襲ったことへの揺り戻しを感じさせるからでしょう。

当時の時代背景を知る手段として「Webはクソ。ブラウザはマジなんとかしろ」の記事をあげます。ここでは進化の遅く足並みの揃わないWebアプリ開発プラットフォームはネイティブアプリに比べて遥かに劣っているという意見が述べられています。

blog.mirakui.com

いま、Webは重要な転換期の中にいると私は思う。Webはデスクトップアプリケーションと同等になるのに10年以上かかってるし、しかもイマイチだ。そしてネイティブアプリが加速していく中でWebは絶滅の危機に瀕している。

PosterousのCEO「Webはクソ。ブラウザはマジなんとかしろ」 - 昼メシ物語

——そして話は現代に立ち戻ります

モバイルWebファーストと貧者のツール

「貧者のツール(道具、技術)」とは、より少ないリソースしか消費できない環境で、なんとか道具を工夫して製品開発を達成するための考え方の通称で、「人ナイ物ナイ金ナイ」のスタートアップ向きであると言えます。

この貧者のツールとして、スタートアップが新規プロジェクトにモバイルWebファーストを採用する利点としては以下があげられると思います。

チームのエンジニアや開発するコードベースを最小にして高速に開発できる

通常のアプリ開発プロジェクトではWebバックエンド/iOSアプリ/Androidアプリ/フロントエンド。など技術やプラットフォームによって開発担当者をアサインすることが多いかと思います。

モバイルWebファーストにすることで、iOSアプリやAndroidアプリの開発に1-2人ぶんのリソースが取られることはなくなります。またWebアプリ開発者はバックエンド開発の片手間にフロントエンド開発も身に付けている人材が多いので、API→アプリクライアントサイドのコミュニケーションも短縮できる可能性があります。

高速に仮説検証できる

変更する対象コードが少なくデプロイも早い。担当する開発者間のコミュニケーションも省ける。となると高速にプロダクトを仮説検証できる 、というのが想像できると思います。

留意すべき点

しかしモバイルWebファーストの良い面の裏に、思わぬ落し穴が隠されているケースもあります

高速な開発を実現する為に選んだモバイルWebファーストが逆に開発の遅延を招く可能性も考慮すべきです。以下はその一例です

• Webアプリの方が実現が難しい機能
• デバイスに近いAPIを活用するアプリ
• ネイティブアプリで楽に実装できるパターンがよく知られている機能

例えば「QRコード決済アプリ」。これを僕が最初に想像した時はMediaDevices系のインターフェイスでWebでもサクっと実現できそうだなー、という印象でした。

しかし現実の QRCode Scanner のデモコードを見るとC言語のライブラリをJavaScriptに変換し、バックグラウンドでカメラをオーバーレイしたcanvasから抜き出した画像データを送りつける、という過激な実装で実現されています。

またデバイスに近いAPI、OSの機能を呼び出して実装するアプリはウェブで自力実装しづらいだけでなく、実現不可能=詰み状態が訪れる危険性もあり、注意が必要です。

その機能要件はネイティブアプリのが実現しやすいのか? Webで充分に開発できそうか? というのは結局両プラットフォームに精通した視点が要ります。貧者の組織にそのような人物の助けを借りることができるか? というのは怪しかと思います。

PinQulの開発が開始されたであろう2017年の春頃にライブECの要件(明日にはガラっと変わるかもしれない!)はWebアプリで充分に満たせるはずだ! と0ベースの状態で断言できるエンジニアはいないと思います。

スタートアップはスピードが命ですから、もしそれをやるにはプロジェクトの開発が決定する前からアイデアの技術的な検証を普段から行っていないとできません。

Komercoの技術選定

Backend as a Service (BaaS)を活用してサーバーサイド開発の工数を減らし、徹底的に仮説検証して高速に新規サービスを開発するぞ！ という考え方があります。

理想的なプロジェクトではバックエンド開発に携わる工数を大幅に削減でき、貧者のツール的であると言えます。

この思想でFirebaseをフル活用して作られたサービスに、クックパッド新規事業「Komerco」というアプリがあります。

jp.techcrunch.com

Komercoは2018年6月にリリースされ、現在はiOSアプリしか提供されていません。

Komerco開発チームがこのままAndroidアプリやWeb版を開発するつもりなのか、iOSだけでサービスを検証してゆくのかは注目どころです。

※ 同じ手法で開発された「Cookin'」というプロジェクトはiOSアプリだけをリリースした後に、7ヶ月でサービスが終了しました*2

螺旋の原則

「技術選定の審美眼 」という名スピーチがあります。

ソフトウェア業界の技術トレンドは、一見振り子のように同じ場所に戻ってくるように見えるが、螺旋状に変化している。螺旋を作り出す技術要素の差分と、変化の中でも変らない抽象的な考え方に注目することの重要さが説かれています。

www.publickey1.jp

この螺旋の原則でいうと。モバイルシフト、アプリファーストの後にWeb回帰というストーリーに中に以下のような差分が潜んでいるのだと思います

• アプリがコモデティ化して、ネイティブアプリであること自体の競争力が弱くなった
• PCのWebブラウザからモバイルのブラウザへ主戦場が移った
• ブラウザやフロントエンド開発環境が劇的に進化した

例えばフリルやメルカリが世にリリースされたのは奇しくもFacebook HTML5ショックの2012-13年です。この時期にモバイルアプリファーストの開発に注力しているサービスは少なかったと記憶しています(そしてフリルはTitanium Mobileによるハイブリッドアプリ技術を選択し、メルカリはネイティブアプリSDK開発を選びました)。

多くのサービスは先ずデスクトップ向けサイトがケータイ対応し、それを元にスマホ対応→アプリリリース。と開発うるのが通例だったと思います。

この時期にネイティブアプリのUXを高めることにすべてを投資したプロダクトは現在も伸びています。

はたして2018年にモバイルWebファーストで開始するサービスはどうなるでしょうか、非常に気になるところです。

私たちのケース

締め括りに身の上話をさせていただくと、先日私たちもPinQulと同じような状況でネイティブアプリ開発に舵を切りました。

その時は直前までWebアプリ以外にもReact NativeやFlutterでの開発を考えて綿密にプロトタイプ開発をして準備を行っていましたが、スタートアップにありがちな「ある日状況が変わった」というやつが発生しました。

その時の意思決定の理由は以下です

• 一番手を動かしてコミットしてくれそうな新入社員のエンジニアがネイティブアプリ開発が得意だった
• それをサポートするエンジニア(僕)がだいたい何でも対応できた
• AWSからGCPに切り替えることができ、Firebase(BaaS)を全面採用できた
• 開発対象の要件がだいたい想像できた

そこから学んだことは以下です

• 仮説検証やPMFは1プラットフォームで行った方が良い
• 選択するプラットフォームは人的要素で決める
• 「隣の芝生は青い」を乗り越えるにはプロトタイプを作り続けるのが重要

P.S. 現実のプロジェクトとして実際に手を動かし、そのふりかえりを共有してくださったPinQulチームと井手さんに心から感謝します

*1:https://www.pexels.com/photo/4k-background-desktop-morning-459625/

*2:Firebaseを活用したiOSアプリ開発事例 - クックパッド開発者ブログ

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

iOSDC Japan 2018

「iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス」と題しまして、PWAムーブメント以降のWebアプリ開発のお話しをさせていただきます。

10年ビジネスとしてiPhoneアプリ開発を、個人の楽しみとしてウェブ開発とクロスプラットフォームのフレームワーク研究を嗜んできた私が現在関心を持っているのがこの最新のWebアプリ開発手法についてです。

おそらく以下のような内容になるかと存じます

「PWAとは?」でウェブ検索してキャッチできないような技術者的観点からレビューしたPWA論

マーケット、ビジネス的、組織的観点のPWA評はおそらく期待できません。ウェブに情報が溢れているので自身で見てもらった方が良いと思います。

クロスプラットフォームツールとして見たWeb開発

近年最も高速に進化しているGUI開発環境であるWebアプリのフロントエンド開発について、私見を交えiOS開発者にとって参考になるような内容にします。

抽象的で観念的なGUI開発の蘊蓄

好きなので。

複数のプラットフォームに精通するとGUI開発を多面的に捉えることができ、そこから発見できる自己理論を持ち出すことができます。

以下は本トークの雰囲気に近そうな窪塚洋介氏のインタビューです。

Google Docs でiOSアプリの画面を作る

アプリ内に設置する「利用規約」や「プライバシーポリシー」を前々から Google Docs のドキュメントを直でホストすればいいんじゃないと思っていたので実現方法を調べた。

Google Docs のドキュメントは

• URL末尾 /edit で共同利用する状態
• /preview で書類フォーマットの閲覧だけするURL
• /pub でWebページとして公開する時のURL

という3つのものがあり、 /pub をアプリ内に WKWebView で直接埋め込む。

Google ドキュメント、スプレッドシート、スライド、フォームの公開と埋め込み - パソコン - ドキュメント エディタ ヘルプ

見た目が気にいらない部分はJSで書き換えてしまう(Googleの標準フッタの表示を消してしまうと怒られそうではある)

webView.evaluateJavaScript(
            ["document.getElementById('contents').style.margin='0 50px';",
             "document.getElementById('header').hidden=true;",
             "document.getElementById('footer').hidden=true;"].joined()) { result, err in
                assert(err == nil, err?.localizedDescription ?? "")
            }

様子

Drawingや他ツールと連携できるので比較的表現力の高い利用規約が作れるような気がする

まとめ

• 作っては見たものの、アプリとウェブサイトで共有するために結局自社でホストするURL振った方がいいのかもしれない
• 閲覧者がリビジョン履歴を見たり「現在利用規約の見ているユーザー数」などを共有して盛り上がれるといいと思ったけどパブリッシュ済みのドキュメントはその機能はなかった

Gist

gistc621a0b6ca5d3571f19ea801ded7fb8e

無法地帯にテストケースを追加する時にいつもやっている戦略

数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。

不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。

1. 手動テストで不具合を再現
2. ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする
3. 移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットする
4. プライベートメソッドを外に出して関数→モジュール化する
5. (4)のメソッドに対してテストを書き、失敗するのを確認する

ポイントとしては

• 運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる
• 依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。行動したことで学んだIssueを起票する

具体的なリファクタリング方法は

レガシーコード改善ガイド (Object Oriented SELECTION)

とか

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

とか

テストケースが蓄積されるとリアーキテクチャリングにも手を出しやすい

レガシーソフトウェア改善ガイド

けど現実ではエイヤで全部捨てるプロジェクトが多くてもったいないなーと思っていた。

バンコクへ来た🇹🇭

上京してから10年程東京で単一障害点を構成してきたのだけど、今年からバンコクで暮しはじめた。バンコクというのはタイ王国の首都の名前なんだけど「タイへ来た」という程バンコクの外のことを知らないのでもっぱらバンコクがどーだこーだと呼んでる。

仕事に関してはPAYで過した楽しい時間を終えて*1 ドリコムの海外子会社で就労ビザサポートしてもらってiOSアプリとAndroidアプリのメンテができるRailsエンジニア的な役割で働いてる。たまにタイトルがEngineering Managerになってたりするけどエンジニア俺一人しかいないので多分に正確ではないと思う。

バンコクという都市について

日本人が住みやすい海外都市の筆頭には毎回上ってるらしい。繁華街に日本語の看板をちょいちょい見かける。でも日本語が通じるかといえば通じないと思う。

街に外国人が溢れていて中国日本欧米東南アジアの人々が全部ごっちゃ混ぜな雰囲気がある。英語はそれなりに通じる。日本人の英語返せない比率から考えると、外国人として東京でローカルなサービスを受けたい場合のがハードル高そうだと思った。

物価については解釈が必要で、大きく「観光客向け」「外国人向け」「現地向け」の経済圏があって慣れてくるとどの程度のコストでどこのサービスを受けるかというのを自分でコントロールできるようになるのだと思う。

治安についてはBLACK LAGOON のモチーフがタイらしいのだけど銃撃戦も起きないし、爆発物も持ち込めないし平和な方だと思う。

たぶん日本人の頭の中には10年以上前の新興国真っ只中の時代のアジアのイメージが残っていて、観光向けの宣材には過剰にキラキラした歓楽街とか高級ホテルやバーの写真が使われてたりするけど、実際の感じはGoogleストリートビューで見てみるのがいいんじゃないかなーと思います。

個人的には東京の冬の気候(寒さや乾燥)と花粉にやられていたので快適になってよかった。空気と水の質も良い気がするけど東京が合わなさ過ぎただけなのかもしれない。

BASEについて

このままBASEにいれば好条件な待遇を受けて楽しい仲間たちと働けて会社や事業や業界も気絶しとけばどんどん成長していくし、手放すのはとても惜し過ぎたんだけど、前々から人生一度ぐらいは海外に住んでみたいもんだという思いがあってわがままを言わせてもらった所がある。

開発していたプロダクトの PAY ID もやっとモバイル版をリリースしてこれからやっていくぞ！ というところだったので最悪といえば最悪だけど幸い強力なメンバーたちが加入してきてくれたので全部任せることができてよかった。

あとそういえば社外取締役の家入さんには一度も会わなかった。むしろ避けてた。

キャリアについて

就労に関しては「転職活動!」みたいな意識はあまりなく移住先行だったので正式な面接フェーズもなく、まわりの共通の知人などに推薦してもらってことがすすみ、流れにのってたらそのままビザをもらえた。 エンジニアが「海外!」という時の8割はアメリカを指して残りはヨーロッパを指してる場合が多いので、他の人に「タイに行きます」というと「なぜタイに……？(タイなんかに？)」という反応をされることが多かった。

でも幸運なことに僕はどこでもいいっすという性格だったので、こちらから見ると「なんで行かないの？」という感じであり話は平行線だった。

今の仕事は海外市場のサービスの開発に携われることと、公用語が英語なこと、あと久しぶりにサーバーサイドをやりたかったのでその点も好都合だった。

語学について

英語は本当にできないまま渡航して、なんとかやるだろうぐらいのナメた気持ちでいたんだけど、全然なんとかならなく、とて〜も色々な人に迷惑をかけて死にたくなるところなんだけど社内の日本人に助けを求められるしコード書いてりゃいいし。恵まれた環境を引いたと思う。

タイ語はこっちで会う日本人にも聞いてみると「全然できない」という人が多く、できなくてもなんとななるようだ。というか外国人生活圏で暮せるよう最適化されるのだと思う。

いざとなれば現代の翻訳こんにゃくのGoogle Translate app も所持してるのでタクシーレベルーのコミュニケーションは問題ないと思われる。

コミュニティについて

欧米人も結構住んでるので meetup.com などで結構イベントが見つかる。でも東京もたぶんたくさん開催されてるだろうけど。日本人や東京会社がやってるような聴講者が一斉に着座してMacbookでスライドのメモを取り寿司を食う「勉強会」スタイルのものはなく欧米式のミートアップが主だと思う。

渋谷の地域コミュニティ*2 をもともとやっていたtejitakさんたちの GAOGAO はバンコクを拠点として活動されているので参加しはじめた。

ちょうどiOSDCで隣でHEIFのトークしてた*3 Yoshidaさんも偶然(!) バンコクにやってきたので一緒になってる。

まとめ

• 学歴や英語が皆無でも東南アジアのビザはなんとかなる*4

あとエンジニアを募集しています

*1:http://blog.lai.so/entry/2017/04/02/%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BE%E3%81%AF%E3%81%A6%E3%81%AA%E3%81%AB%E5%85%A5%E7%A4%BE%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F

*2:https://devmorning.connpass.com/

*3:https://speakerdeck.com/tamanyan/iosdc-heif

*4:シンガポールは知らない……

iOSエンジニア向けのイベントでReactの話をした

TL;DR

iOSDC Japan 2017 というイベントが先日開催され、そこでReact Nativeを題材に何かトークをしようと応募したら、まんまと枠をもらえたので話をしてきました。

事前のリサーチでiOSのエンジニアはReactやReact Nativeについて名前や概要ぐらいは知っているけど使ったことのある人は多くないということが分ったので、まずは興味を持ってReact Nativeの環境をインストールしてもらうことをゴールに、Reactプログラミングのパラダイムや思想について、iOSエンジニアが普段行なっているネイティブアプリ開発とどのように違うのか? という内容にしました。

いくぶん抽象的な話に終始してしまい力量不足で本当はもっとわかりやすい説明をしたかったなと反省しつつも、実践的な内容はこれからも各所で見られることになると思うので是非React Nativeにご注目ください。

*

以下は当日に上映したスライドに、スピーカーノートして書いたテキストを交えたものになります。資料だけでは情報が不足していると思われるのでご参考ください。

このトークのテーマは「Viewをどう作るか？」という大きな問題に対して、React Nativeが提供するプログラミングモデルをiOSアプリ開発者の視点でお話します

前提にあるのは「Viewの開発は難しい」という問題です。

Viewはユーザーにも開発者にも心理的な距離が近いので、現実のアプリケーションを作る上で「Viewをどう作るか？」というのは重要な点になっています

その中でFacebookは20億人とも言われるユーザーに対して日々Viewを開発し続けている、世界最大のViewの生産者であると言えます。 そんなFacebookの開発の現場で生まれたUI開発のための考え方を紹介したいと思います。

思い出したように突然の自己紹介です。

私は普段はSwiftとKotlinでiOSとAndroidのネイティブアプリケーションを開発しているのですが、趣味でアプリケーションフレームワークを研究している者です。

まず始めにReact Nativeを一言で説明すると「React でiOSやAndroidのネイティブアプリケーションが開発できるツール群」ということになります

Reactはもともとブラウザ向けのViewを開発するライブラリとして登場しましたが、ブラウザとそれ以外のプラットフォームにViewの解釈が拡大してからは、フレームワークやUIプログラミングのためのプラットフォームの側面が強くなっています。

早速React Nativeを使ったViewのコードをお見せします。

ReactではReact Componentという単位でViewを開発します。

React Componentの考え方はUIViewControllerに近いので、あえてViewControllerという名前をつけました

Interface BuilderやStoryboardは利用せず、Viewの定義はすべて render() 関数以下に埋め込みます。

これはUIKitでいうところの loadview() メソッドになるでしょう

React Native がViewを書き出すまでの仕組みです

React Nativeで書いたJavaScriptのコードは、仮想的なViewのデータ構造としてバックグラウンドスレッドでJavaScriptCoreによって処理され、最終的に1つのルートUIViewとなって出力されます

このためネイティブアプリの中の一部分のView以下にReact Nativeを使うという方法も可能になっています

そして、私達がUIKitでViewをどのように作っているのか? というお話にふれます

UIKitでのプログラミングではInterface Buildを通じてViewControllerが扱う初期状態のViewを定義します

ViewController内部プロパティでプレゼンテーションのための状態データを管理し、イベントが発生するごとに操作してViewを書き換えるコードを書いています。

Viewを更新するコードの積み重ねは、1つのViewControllerが抱える要件が増えていくことによってどんどん肥大化していきます。

ここにViewの開発は難しいという問題の根本があると思っています。

これに対しReactコンポーネントはViewに必要な状態が変る度にView全体がフレームワークによって自動で再構成されます

開発者はViewを更新するための具体的な手順を記述せずに、Viewが描画された後の結果を直接XMLのコードで表現します

これを宣言的なViewと呼びます

Reactの宣言的なViewの利点は、フレームワークによって「Viewをどう表示するのか」という手続きが隠され、「どう表示された」だけを抽象的に考えてViewを作ることができます。

Interface Build が表示する前の状態を定義するのとは対照的に、ReactのViewは表示するViewそのものをコードで表現します。

この為、状態変数によってViewの内容が変わる、というコードを render() 関数内にすべて書くことができます。

これは継続的なUI開発で変更しやすく複雑になりにくいコードを維持することにつながります。

次に複数のReact Componentを使ったコードを見ていきたいと思います

React NativeではUIKitの各コンポーネントはReact Componentとしてフレームワーク内に用意されているので、直接UIViewControllerなどを操作することはありません

開発者は独自のReact Componentを定義して、それらを組立ながら画面を構成していきます。

これをReactではコンポーネント指向なViewといいます

コンポーネント間のデータのやりとりは一般的には、より上位のコンポーネントから差しこんだり、ハンドラ関数を登録し任意のコンポーネント内で処理が実行されるようにしたりします(Delegateパターンに少し似ています)

コンポーネント指向でViewを構成することの利点は、各Viewが小さな部品となり取り扱いやすくなることにあります。

一般的なプログラミングでクラスや関数を作ることと動機は同じです。

コンポーネントはただのデータ構造なので、それ自体が引数と戻り値がある関数であるととらえることができテストも書きやすいです

大きくなったコンポーネント下位コンポーネントへ分割し小さくしたり、内部の詳細はカプセル化されているので他のコンポーネントと共有化することもできます

またUIViewControllerモデルではどうしてもViewControllerの切り替え=画面遷移して移動。となってしまう場面でもいつの画面内で済ませられるように感じます

React Component と UIViewController を比較した時に UIViewController側に不足しているのは複数のコンポーネントを組み合わせる時の協調性です

各ViewとViewControllerがどのような親子関係にあるのかをaddChildViewController() で記述することになります。

Reactのような自動でViewを描画する仕組みもないので、データが更新された時に適切に内部通知されデータが渡される仕組みを作り、開発者が手動で必要なViewを探し更新する、もしくはデータバインディング系のライブラリで補うことになります

ReactはどうViewを作るのか？ についてまとめます

ReactのViewは内部状態の更新以降の処理をライブラリ側で行ってくれます

命令ではなく結果をコードで記述するようになるので、よりアプリの本質的な部分だけを考えることができます

ReactのViewはコンポーネント単位の環境に依存しないデータ構造になります

小さな部品を組み立てるようにViewを構成するので複雑なUIをより開発しやすくします

これに対しUIKitプログラミングでは、Interface BuildとViewControllerを駆使してViewを作ります

基本的にViewcontrollerを起点に開発者がすべてViewを手動で記述するので、Viewが複雑になりがちです

React Nativeのすごいところは、UIKitプログラミングの考え方とは全く異るパラダイムで同じアプリケーションを開発できるという体験を持ち込むことに成功しています

UIKitをそのまま動かした上で、既存の開発環境の抱える問題をうまく解決しているという点が非常に夢がある技術だと感じます(しかし現実は厳しい事もたくさんあります)

Interface Builder で構成するViewは状態管理に弱く、命令的なコードを開発者自身が記述しないといけないため、Viewの複雑さを引き起します

また、1画面すべてをViewController以下に収めるプログラミングは拡張性に乏しく、柔軟性に欠けます

React Nativeが解決する問題は現在のUIKitの制約と深く結びついています

つまりiOS SDKやXcodeの進化によって改善するべき点を示唆していると思います

最後にこれらの問題を解消すべく、UIKitがどう進化するといいのか? という話題について個人的な妄想を話します

宣言的なViewを実現する方法としてUIデータバインディングがあります。

MacアプリにはCocoaバインディングというInterface Builderでネイティブに動作するデータバインディングの仕組みが既にあります。

これを是非UIKitプログラミングの世界にも統合して使えるようにしてほしいです

さらに次世代のInterface Buildでは、WindowsやAndroidの開発環境のようにプレーンテキストとプレビュー形式でUIを構成したいです

もしくは、コンパイラレベルの拡張が必要だと思いますが、JSXのようにSwift内でViewの構造を宣言できるのも面白いかもしれません

またReactのコンポーネント指向を例に、複数のUIViewControllerが協調して画面を構成できる仕組みを強化して欲しいところです

Appleらしいやり方としてはStoryboardを拡張してグラフィカルに記述できるようになるというのもいいかもしれません

その時はReactのFluxアーキテクチャのようなコンポーネントツリーを横断してデータを取得する方法の研究も必要になってくると思います

皆さんもReact Nativeで「未来のiOSプログラミング」を想像（創造）しませんか？

以上で私の発表は終了させていただきます

おまけ

尺の関係で個人的には好きだが技術的な解説に寄ってしまうので削った部分がありました、別の機会で何か残したいと思います

• React DOM
  • React + (View)
  • View=DOM, Native, Canvas, SVG, WebGL
  • ^ 一方ウェブブラウザ上で実行されるReactはReact DOMと呼ばれています。
  • Reactのシステムによって最終的にViewが描画されるプラットフォームごとにパッケージ化されており、そのうちの1つがReact Native となります
• React for iOS を実現するツール
  • AsyncDisplayKit
  • ComponentKit
  • React Native
  • ^ React Native 以前にReactにヒントを得てiOSのUIKitで動作するライブラリとして「AsyncDisplayKit」と「ComponentKit」が存在します。
  • Facebookの社内プロジェクトとして開発は独立していて、それぞれ発展を遂げているのですが、現在のReact Nativeに影響を与えています。
• React Nativeの仕組み
  • JavaScriptコードをバンドル
  • RNランタイムをロード
  • バックグラウンドと通信してRootViewが更新される
  • ^ React NativeではコンポーネントのレイヤーをJavaScriptで記述し、JavaScriptCore経由でネイティブのUIKitコンポーネントのViewへ適応します。
  • 前述のように内部的には各Viewに相当するデータ構造を保持していまして、バックグラウンドスレッドや最小限のコストで描画処理が走るよう最適化されています。
• Virtual DOM or Virtual View
  • Viewのデータ構造を生成し
  • 差分を部分的に描画する
  • 高速なViewの描画が可能になる

Vue.js Tokyo v-meetup #4 が開催されました

vuejs-meetup.connpass.com

会社のサービス*1 で使っていることもあって動向を注目しているVue.jsについて、国内最大のコミュニティの第四回ミートアップが開催されました。

会場はLINE株式会社提供のセミナールーム「オーディトリウム」で100名以上の参加者がおりたいへん盛況なイベントになりました。今回ブログ枠で参加させていただいたのでレポートを書きます。

Weex ではじめる Native App 開発 @KaraMisoRamen

LTのトップバッターはKaraMisoRamenさんによるVue.js版React NativeというべきWeex の紹介でした。

weex.incubator.apache.org

Weexプロジェクトの成り立ちやアーキテクチャの概要、React Nativeとの比較。などのお話でした。

僕はフレームワークおたくなので中国語ドキュメントしかない時期にWeexでネイティブアプリをビルドしてみたり挑戦していて最初は動かすだけでひと苦労でしたが、最近は Alibabaのデベロッパーの1プロジェクトから Apache Incubator 管理下に移されたり開発がどんどん活発になっていっている印象です。

アーキテクチャについては「React Nativeとだいたい同じ」といえると思います。後発なのでよく研究されて作られており、Objective-CやJavaでのネイティブコード拡張の仕組みやFlexboxシステム、ブラウザ向けのrouterとの統合などReact Nativeで実現されている機能はひととうりあります。

特徴的な違いをあげると「HTML 5 Web App が第一級サポートされている」という点かと思います。これによってWeexプロジェクト側としてはWebブラウザ向けの開発環境でコーディングしたVue appをiOS/Androidにそのままポーティングできるというスタイルを意図しているのだと思います(この性質には懸念点もありますが)。

プロダクトへの投入という視点だと現時点ではReact Nativeより1年は遅れを取っているので、エコシステムの充実や周辺ツールなどまだまだな印象ですがVue.jsコミュニティ自体の拡大とともに今後も要注目のプロジェクトだと思います。

「Vue.jsでモバイルapp」という話なら、こちらは Cordova のWebViewを基礎技術にしたフレームワークですが、Vue with Ionic な Vonic や Onsen UI for Vue のプロジェクトなども気になるところです。

お仕事で Nuxt.js を使うか検討した話 @inouetakuya

speakerdeck.com

Nuxt.js 公式ドキュメント翻訳*2 などで知られるinouetakuyaさんのLTは、所属するGMOペパボEC事業部の新規プロジェクトの技術選定をどのように行ったのか? という知見を共有していただきました。

対象となるWebサービスの要件から、そもそもSSR(サーバーサイドレンダリング)は必要か? リクエスト時に動的生成するのか、それともプリレンダリングで事前に生成したHTMLを利用するのか。と段階的に議論を進めて、全部入りなNuxt.js を採用するのか Vue.js Server-Side Rendering Guide にも載っている vue-server-renderer を直接使うのか→そ0の理由は?、などアーキテクチャの構成を一般的な問題解決の手法で行っていく具体的な事例のお話が聞けました。

とくに検討の最終段階としてNuxt.jsの動作を理解して、得られるメリットと導入後のリスクを考える過程は現場の実践感があって良かったと思います。

Vue.jsのTransitionでいい感じのアプリにする @tomato360

qiita.com

仕事ではRails+Reactな環境で、プラベートでVue.jsを愛用しているnasumさんが、自作のTwitterクライアントアプリを題材にVueのTransition APIを使って開発した実例の紹介でした。

トランジション効果 - Vue.js

Vueのトランジション(UI遷移の効果) は <transition name="fade"> などで宣言した名前をキーに開始→終了のCSS-classのエントリーポイントに状態を記述していくだけで各点を繋ぐアニメーションなどが実現できるというとてもシンプルでパワフルな仕組みでした。

LTでは投稿のためのモーダルダイアログの出現やタイムラインリストへの要素挿入の連続的なトランジション(transition group)などを実アプリの画面でDemoされて盛り上っていました。

Vueコンポーネントのユニットテスト @hypermkt

speakerdeck.com

GMOペパボアニメ部部長のバーチーさんによるLTです。業務でバリバリVue.jsコードを書いているらしくかなり実践的な内容でした。

Vueのテストツールは最近になってたくさんのプロジェクトが登場していて、その中の1つの avoriaz 開発者を中心に現在 vue-test-utils という公式のライブラリの開発が進んでいるようです。

vue-test-utilsはまだ絶賛開発中(未リリース)なこともあり、LTではvue-test-utilsの前身となるavoriazの使い方を例に、Vueコンポーネントベースでのユニットテストの方法が紹介されました。

依存コンポーネントを動的に分離するShallow Testing(自動でコメントアウトしてしまうそうです!) や DOMイベントをコンポーネントへ伝え状態変化させテストする手法などなかなか他のUI開発のプラットフォームでは見られない仕組みが新鮮でした。

Vue.jsとFirebase Hostingでサーバサイドレンダリング @k2wanko

speakerdeck.com

GAE/Goでサーバーサイドレンダリング などの苦行に挑戦されているセキュリティエンジニアのコキチーズさんのLTです。

Firebaseのサーバレスアーキテクチャ分野の進出である(!) Cloud Functions を使ったサーバサイドレンダリングの話でした。

Google Developers Japan: Cloud Functions for Firebase のご紹介

サーバサイドレンダリングとクライアントサイドの初期化双方の表示を並べて表示の速さなどをデモしてくれました。

これらのサーバーを自前で構成するのも一苦労だしFirebase圧倒的便利感あるなーという感想でした。しかし新たなアーキテクチャだけにFunctionで生成したデータのキャッシュをどこに保持するのか? など新規の課題もあるようです。

Vueでデザインツールを作った話 @KeimaKai

STUDIOというウェブベースのデザインツールを開発されている甲斐さんのお話でした。

STUDIO | 誰でも簡単にプロトタイプが作れるUXデザインツール

ohako.studio

このLTでもFirebaseが登場し、Style Object内部データの同期の仕組みやVueコンポーネントへ適用してリアルタイムにプレビューしている様子が紹介されました。

本格的なSPAのJavaScript自体の経験も充分でない中コードを書きはじめたらしいのですが、Vueは柔軟で使いやすく高評価とのことでした。jQuery UIベースで構成された既存UI資産の統合なども見られて、デザイナーのコーディング視点でのVueといった感じで参考になりました。

kintoneアプリを Vue.jsを使ってカスタマイズする @naruohama

ビジネスアプリ作成プラットフォームのkintoneを使ったシステム導入などを手掛けている大阪からいらっしゃったnaruohamaさんのLTです。

kintone - サイボウズのビジネスアプリ作成プラットフォーム

kintone.cybozu.com

僕の知識でいうとkintoneアプリのカスタマイズは Force.comプラットフォームでのアプリケーション開発 に近いのかなーという印象でした。

kintone本体ではReactが使われているらしく、そこにさらにVueを使ってUIを構成されていました。

VueConf 2017 参加レポート @ktsn

dev.oro.com

Vue.js coreチームのkatashinさんによるポーランドで開催された初の公式な世界的カンファレンスであるVueConf 2017の参加レポートです。

上記ブログ内容を肴に気になったトーク、ESLint やVSCodel(vetur)、セミコロン論争などのこぼれ話を聞くことができました。

推されていたトーク: Animating Vue by sdrasner

総括

爆発的に成長する中国の開発者コミュニティの勢いを背景に2016年-2017年と普及期に来たVue.jsですがReactやAngularのコミュニティでも見覚えのある話題が増えてきました。これはコミュニティが成熟してきた証だと思います。

いろいろな言語やフレームワークのコミュニティをウォッチしてたりすると各コミュニティの違いが共通点が分っておもしろいのですが、Vue.jsコミュニティは「PHPコミュニティと共通する良さを持っている」というのが個人的な見解です。

まず開発者コミュニティにユーザーに対する献身さがあります。公式ドキュメントの日本語訳も即時に手厚くサポートされていますし、マークアップの延長線でコーディングでき、ビルドツール環境の複雑性も露呈させず、デザイナーやSPA開発の専門家でもない人達にも入門しやすくチュートリアルが書かれています。

Vue.jsのユーザーはPHPと同じく自分のアプリケーションを構成するためのシンプルで本質的な問題解決法を求めているのだと思います。PHPで今一番勢いのあるフレームワークであるLaravelがデフォルトでVue.jsを採用しているのは象徴的です。今回のミートアップでも「実際に何か作っていて、そこでVue.jsを使っている」という話題がほとんどを占めていました。

ReactでもAngularでもなく第三の勢力であるVue.jsが選ばれているのは Evan You の個人的なViewレイヤーのプログラミングをうまくやる自作ツールからスタートして、企業が牽引する2大フレームワークの成長を他所にVue.jsが「アプリケーション開発のためのツール」であり続けていることが大きいのだと感じます。これは以下の「シンプルさの必要性」に出てくるような哲学や概念の設計がうまく機能しているためでしょう*3

シンプルさの必要性 | eed3si9n

今回のミートアップではサーバサイドレンダリングの実践やFirebase(BaaS)の活用の話題が熱かったです。JSXサポートやTypeScript連携、GraphQL統合などの先の話題も気になりますし、次回開催も楽しみです。 開催情報は Vue.js Meetup connpassグループに参加して購読しましょう！

実は我々のプロジェクト内の1万行のVue 1.x 系のコード資産があるのですが 、これをドーンと2.xに移行して何かしゃべりたいなーとか思っていました *4

関連エントリ

• 予習として #1 Awesome Vue - genba.fm を聴きました
• 関西から Vue.js Tokyo v-meetup #4 に参加する為だけに東京に来ました！ - ht: もチェック!
• “Vue.js Tokyo v-meetup #4” の Tweet まとめ - Togetterまとめ

*1:https://pay.jp/

*2:http://blog.inouetakuya.info/entry/2017/03/26/203925

*3:でも個人的には Ember もいい感じにレールに乗った開発ができると感じているのでもっと使われてもいいなーと思っています

*4:参加したい人も募集しています https://www.wantedly.com/projects/93638