Apps開発のエッセンス」と題しまして、PWAムーブメント以降のWebアプリ開発のお話しをさせていただきます。10年ビジネスとしてiPhoneアプリ開発を、個人の楽しみとしてウェブ開発とクロスプラットフォームのフレームワーク研究を嗜んできた私が現在関心を持っているのがこの最新のWebアプリ開発手法についてです。以下のような内容になるかと存じます「PWAとは?」でウェブ検索してキャッチできないような技術者的観点からレビューしたPWA論マーケット、ビジネス的、組織的観点のPWA評はおそらく期待できません。ウェブに情報が溢れているので自身で見てもらった方が良いと思います。近年最も高速に進化しているGUI開発環境であるWebアプリのフロントエンド開発について、私見を交えiOS開発者にとって参考になるような内容にします。複数のプラットフォームに精通するとGUI開発を多面的に捉えることができ、そこから発見できる自己理論を持ち出すことができます。以下は本トークの雰囲気に近そうな窪塚洋介氏のインタビューです。ドキュメントを直でホストすればいいんじゃないと思っていたので実現方法を調べた。数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。手動テストで不具合を再現ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットするプライベートメソッドを外に出して関数→モジュール化する(4)のメソッドに対してテストを書き、失敗するのを確認するポイントとしては運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。見るけど現実ではエイヤで全部捨てるプロジェクトが多くてもったいないなーと思っていた。上京してから10年程東京で単一障害点を構成してきたのだけど、今年からバンコクで暮しはじめた。バンコクというのはタイ王国の首都の名前なんだけど「タイへ来た」という程バンコクの外のことを知らないのでもっぱらバンコクがどーだこーだと呼んでる。ドリコムの海外子会社で就労ビザサポートしてもらってiOSアプリとAndroidアプリのメンテができるRailsエンジニア的な役割で働いてる。Managerになってたりするけどエンジニア俺一人しかいないので多分に正確ではないと思う。バンコクという都市について日本人が住みやすい海外都市の筆頭には毎回上ってるらしい。繁華街に日本語の看板をちょいちょい見かける。日本語が通じるかといえば通じないと思う。街に外国人が溢れていて中国日本欧米東南アジアの人々が全部ごっちゃ混ぜな雰囲気がある。英語はそれなりに通じる。日本人の英語返せない比率から考えると、外国人として東京でローカルなサービスを受けたい場合のがハードル高そうだと思った。物価については解釈が必要で、大きく「観光客向け」「外国人向け」「現地向け」の経済圏があって慣れてくるとどの程度のコストでどこのサービスを受けるかというのを自分でコントロールできるようになるのだと思う。モチーフがタイらしいのだけど銃撃戦も起きないし、爆発物も持ち込めないし平和な方だと思う。日本人の頭の中には10年以上前の新興国真っ只中の時代のアジアのイメージが残っていて、観光向けの宣材には過剰にキラキラした歓楽街とか高級ホテルやバーの写真が使われてたりするけど、実際の感じはGoogleストリートビューで見てみるのがいいんじゃないかなーと思います。個人的には東京の冬の気候(寒さや乾燥)と花粉にやられていたので快適になってよかった。空気と水の質も良い気がするけど東京が合わなさ過ぎただけなのかもしれない。BASEについてこのままBASEにいれば好条件な待遇を受けて楽しい仲間たちと働けて会社や事業や業界も気絶しとけばどんどん成長していくし、手放すのはとても惜し過ぎたんだけど、前々から人生一度ぐらいは海外に住んでみたいもんだという思いがあってわがままを言わせてもらった所がある。いうところだったので最悪といえば最悪だけど幸い強力なメンバーたちが加入してきてくれたので全部任せることができてよかった。あとそういえば社外取締役の家入さんには一度も会わなかった。キャリアについて就労に関しては「転職活動!」みたいな意識はあまりなく移住先行だったので正式な面接フェーズもなく、まわりの共通の知人などに推薦してもらってことがすすみ、流れにのってたらそのままビザをもらえた。エンジニアが「海外!」という時の8割はアメリカを指して残りはヨーロッパを指してる場合が多いので、他の人に「タイに行きます」というと「なぜタイに......?(タイなんかに?)」という反応をされることが多かった。幸運なことに僕はどこでもいいっすという性格だったので、こちらから見ると「なんで行かないの?」という感じであり話は平行線だった。今の仕事は海外市場のサービスの開発に携われることと、公用語が英語なこと、あと久しぶりにサーバーサイドをやりたかったのでその点も好都合だった。語学について英語は本当にできないまま渡航して、なんとかやるだろうぐらいのナメた気持ちでいたんだけど、全然なんとかならなく、とて〜も色々な人に迷惑をかけて死にたくなるところなんだけど社内の日本人に助けを求められるしコード書いてりゃいいし。恵まれた環境を引いたと思う。タイ語はこっちで会う日本人にも聞いてみると「全然できない」という人が多く、できなくてもなんとななるようだ。いうか外国人生活圏で暮せるよう最適化されるのだと思う。所持してるのでタクシーレベルーのコミュニケーションは問題ないと思われる。東京もたぶんたくさん開催されてるだろうけど。日本人や東京会社がやってるような聴講者が一斉に着座してMacbookでスライドのメモを取り寿司を食う「勉強会」スタイルのものはなく欧米式のミートアップが主だと思う。バンコクを拠点として活動されているので参加しはじめた。バンコクにやってきたので一緒になってる。Nativeを題材に何かトークをしようと応募したら、まんまと枠をもらえたので話をしてきました。Nativeにご注目ください。*以下は当日に上映したスライドに、スピーカーノートして書いたテキストを交えたものになります。資料だけでは情報が不足していると思われるのでご参考ください。Nativeが提供するプログラミングモデルをiOSアプリ開発者の視点でお話します前提にあるのは「Viewの開発は難しい」という問題です。Viewはユーザーにも開発者にも心理的な距離が近いので、現実のアプリケーションを作る上で「Viewをどう作るか?」というのは重要な点になっていますその中でFacebookは20億人とも言われるユーザーに対して日々Viewを開発し続けている、世界最大のViewの生産者であると言えます。そんなFacebookの開発の現場で生まれたUI開発のための考え方を紹介したいと思います。思い出したように突然の自己紹介です。私は普段はSwiftとKotlinでiOSとAndroidのネイティブアプリケーションを開発しているのですが、趣味でアプリケーションフレームワークを研究している者です。iOSやAndroidのネイティブアプリケーションが開発できるツール群」ということになりますReactはもともとブラウザ向けのViewを開発するライブラリとして登場しましたが、ブラウザとそれ以外のプラットフォームにViewの解釈が拡大してからは、フレームワークやUIプログラミングのためのプラットフォームの側面が強くなっています。Nativeを使ったViewのコードをお見せします。Componentという単位でViewを開発します。関数以下に埋め込みます。Buildを通じてViewControllerが扱う初期状態のViewを定義しますViewController内部プロパティでプレゼンテーションのための状態データを管理し、イベントが発生するごとに操作してViewを書き換えるコードを書いています。Viewを更新するコードの積み重ねは、1つのViewControllerが抱える要件が増えていくことによってどんどん肥大化していきます。ここにViewの開発は難しいという問題の根本があると思っています。これに対しReactコンポーネントはViewに必要な状態が変る度にView全体がフレームワークによって自動で再構成されます開発者はViewを更新するための具体的な手順を記述せずに、Viewが描画された後の結果を直接XMLのコードで表現しますこれを宣言的なViewと呼びますReactの宣言的なViewの利点は、フレームワークによって「Viewをどう表示するのか」という手続きが隠され、「どう表示された」だけを抽象的に考えてViewを作ることができます。表示する前の状態を定義するのとは対照的に、ReactのViewは表示するViewそのものをコードで表現します。関数内にすべて書くことができます。これは継続的なUI開発で変更しやすく複雑になりにくいコードを維持することにつながります。Componentを定義して、それらを組立ながら画面を構成していきます。これをReactではコンポーネント指向なViewといいますコンポーネント間のデータのやりとりは一般的には、より上位のコンポーネントから差しこんだり、ハンドラ関数を登録し任意のコンポーネント内で処理が実行されるようにしたりします(Delegateパターンに少し似ています)コンポーネント指向でViewを構成することの利点は、各Viewが小さな部品となり取り扱いやすくなることにあります。一般的なプログラミングでクラスや関数を作ることと動機は同じです。コンポーネントはただのデータ構造なので、それ自体が引数と戻り値がある関数であるととらえることができテストも書きやすいです大きくなったコンポーネント下位コンポーネントへ分割し小さくしたり、内部の詳細はカプセル化されているので他のコンポーネントと共有化することもできますまたUIViewControllerモデルではどうしてもViewControllerの切り替え=画面遷移して移動。記述することになります。いう話題について個人的な妄想を話します宣言的なViewを実現する方法としてUIデータバインディングがあります。Builderでネイティブに動作するデータバインディングの仕組みが既にあります。DOMと呼ばれています。以前にReactにヒントを得てiOSのUIKitで動作するライブラリとして「AsyncDisplayKit」と「ComponentKit」が存在します。Nativeに影響を与えています。NativeではコンポーネントのレイヤーをJavaScriptで記述し、JavaScriptCore経由でネイティブのUIKitコンポーネントのViewへ適応します。前述のように内部的には各Viewに相当するデータ構造を保持していまして、バックグラウンドスレッドや最小限のコストで描画処理が走るよう最適化されています。使っていることもあって動向を注目しているVue.jsについて、国内最大のコミュニティの第四回ミートアップが開催されました。会場はLINE株式会社提供のセミナールーム「オーディトリウム」で100名以上の参加者がおりたいへん盛況なイベントになりました。今回ブログ枠で参加させていただいたのでレポートを書きます。Nativeとの比較。管理下に移されたり開発がどんどん活発になっていっている印象です。Nativeとだいたい同じ」といえると思います。Nativeで実現されている機能はひととうりあります。第一級サポートされている」という点かと思います。appをiOS/Androidにそのままポーティングできるというスタイルを意図しているのだと思います(この性質には懸念点もありますが)。Nativeより1年は遅れを取っているので、エコシステムの充実や周辺ツールなどまだまだな印象ですがVue.jsコミュニティ自体の拡大とともに今後も要注目のプロジェクトだと思います。プロジェクトなども気になるところです。いう知見を共有していただきました。リクエスト時に動的生成するのか、それともプリレンダリングで事前に生成したHTMLを利用するのか。使うのか→そ0の理由は?、などアーキテクチャの構成を一般的な問題解決の手法で行っていく具体的な事例のお話が聞けました。検討の最終段階としてNuxt.jsの動作を理解して、得られるメリットと導入後のリスクを考える過程は現場の実践感があって良かったと思います。APIを使って開発した実例の紹介でした。宣言した名前をキーに開始→終了のCSS-classのエントリーポイントに状態を記述していくだけで各点を繋ぐアニメーションなどが実現できるというとてもシンプルでパワフルな仕組みでした。group)などを実アプリの画面でDemoされて盛り上っていました。@hypermktspeakerdeck.comGMOペパボアニメ部部長のバーチーさんによるLTです。業務でバリバリVue.jsコードを書いているらしくかなり実践的な内容でした。いう公式のライブラリの開発が進んでいるようです。vue-test-utilsはまだ絶賛開発中(未リリース)なこともあり、LTではvue-test-utilsの前身となるavoriazの使い方を例に、Vueコンポーネントベースでのユニットテストの方法が紹介されました。DOMイベントをコンポーネントへ伝え状態変化させテストする手法などなかなか他のUI開発のプラットフォームでは見られない仕組みが新鮮でした。苦行に挑戦されているセキュリティエンジニアのコキチーズさんのLTです。使ったサーバサイドレンダリングの話でした。ご紹介サーバサイドレンダリングとクライアントサイドの初期化双方の表示を並べて表示の速さなどをデモしてくれました。これらのサーバーを自前で構成するのも一苦労だしFirebase圧倒的便利感あるなーという感想でした。新規の課題もあるようです。@KeimaKaiSTUDIOというウェブベースのデザインツールを開発されている甲斐さんのお話でした。Object内部データの同期の仕組みやVueコンポーネントへ適用してリアルタイムにプレビューしている様子が紹介されました。本格的なSPAのJavaScript自体の経験も充分でない中コードを書きはじめたらしいのですが、Vueは柔軟で使いやすく高評価とのことでした。UIベースで構成された既存UI資産の統合なども見られて、デザイナーのコーディング視点でのVueといった感じで参考になりました。@naruohamaビジネスアプリ作成プラットフォームのkintoneを使ったシステム導入などを手掛けている大阪からいらっしゃったnaruohamaさんのLTです。近いのかなーという印象でした。kintone本体ではReactが使われているらしく、そこにさらにVueを使ってUIを構成されていました。2017の参加レポートです。VSCodel(vetur)、セミコロン論争などのこぼれ話を聞くことができました。爆発的に成長する中国の開発者コミュニティの勢いを背景に2016年-2017年と普及期に来たVue.jsですがReactやAngularのコミュニティでも見覚えのある話題が増えてきました。これはコミュニティが成熟してきた証だと思います。いろいろな言語やフレームワークのコミュニティをウォッチしてたりすると各コミュニティの違いが共通点が分っておもしろいのですが、Vue.jsコミュニティは「PHPコミュニティと共通する良さを持っている」というのが個人的な見解です。開発者コミュニティにユーザーに対する献身さがあります。公式ドキュメントの日本語訳も即時に手厚くサポートされていますし、マークアップの延長線でコーディングでき、ビルドツール環境の複雑性も露呈させず、デザイナーやSPA開発の専門家でもない人達にも入門しやすくチュートリアルが書かれています。Vue.jsのユーザーはPHPと同じく自分のアプリケーションを構成するためのシンプルで本質的な問題解決法を求めているのだと思います。PHPで今一番勢いのあるフレームワークであるLaravelがデフォルトでVue.jsを採用しているのは象徴的です。今回のミートアップでも「実際に何か作っていて、そこでVue.jsを使っている」という話題がほとんどを占めていました。個人的なViewレイヤーのプログラミングをうまくやる自作ツールからスタートして、企業が牽引する2大フレームワークの成長を他所にVue.jsが「アプリケーション開発のためのツール」であり続けていることが大きいのだと感じます。eed3si9n今回のミートアップではサーバサイドレンダリングの実践やFirebase(BaaS)の活用の話題が熱かったです。JSXサポートやTypeScript連携、GraphQL統合などの先の話題も気になりますし、次回開催も楽しみです。経つので振り返りがてらに近況を書くことにした。これがどこまで正確に表現できてるかどうか不明だけど入社してしばらく咀嚼するまでいまいちわからずやっていっていたまずBASEとPAYでメインのプロダクトが二分していて、それぞれにBtoBとBtoCの側面をもったサービスがある。BASEがリリースから3〜4年目の組織だとすると、後から加わったPAYは1〜2年目といったところで組織の成熟度などにフェーズの差がある。その中でもBtoBの開発のが先行していてBtoCが後発ではじまったというのもある。PAYのBtoCのやつは決済インフラとしては元気に動いているがサービスのブランドとしてはまだピヨピヨしている感じ。組織の一番若いところのプロジェクトに入った。僕が入った時のBASEのアプリ開発は「半年前に入社して引き継いだiOSエンジニア1名」ががんばって開発していて「Androdエンジニアは訳あって0名」という絶望的な状況で。Androidアプリのバグ修正が誰もやる人居ないけどまぁいいか、というムードだったのでいくつかプルリクエストしたりした。したらあの人やこの人たちがどんどん人が入ってきて今はアプリ開発チームの所帯が育ってきた、という状況。会社の雰囲気ユビレジは30代が中心の会社だったけれどBASEは20代と、一気に若返って雰囲気も大分違う。新鮮だったのはエンジニア職以外の人もITツールをネイティブに使いこなせるほどリテラシの水準が高いことだった。🤔)来ないこともあってよくわからなくなってしまった。人が入れ変ってゆくうちにDST(ドワンゴ標準時)が適用されはじめたりとかしないとか。コミュニケーションの機会はあるんだけど全然参加せずとも勤務できており、部署内外の人とひとつも会話が発生しないで退勤することがよくあり大丈夫なのと思うけどなんか問題起きないので過している。同僚の顔もよく覚えてないのですれちがっても気付かないし社内の人との会話カバレッジが著しく低い。チャット上でのやりとりで基本全部済ませていて、このチャットで話しかけている人顔知らないなぁみたいなことがよく発生する。社内をよくファッション誌の編集部員とかアイドルみたいな女子とか下駄の人とか(下駄かよ)が歩いているけどはたして社員なのか、アイドルが生息しているのか。定かではないけど気にしないようにしてる。PAYチームについてPAYのエンジニアは10名ぐらい全員PythonでWeb開発やっている感じ。」の人も書いてたけどある程度の規模と品質を保っているコードベースでPythonを書きまくる環境として最適なんじゃないかと思う。事業的には直近ではBASEの取引数が爆発的に成長しているのでバックエンドのPAYもチート的に成長していて、それに加えて某オンライン決済APIの撤退からの移行ユーザーがガッと押し寄せている。プロダクト的には現金主義の慣習や銀行とクレジットカード業界の構造で成り立っている古い仕組みを新世代のサービスでアップデートしたいというところが主で、世のフィンテック競合他社とされているところは個人的には「戦友」という実感。内部的な視点でみるとフィンテックもAIブームも関係なく世の中や市場が求めているので絶対今のオンライン/オフライン決済のUXは自分達の世代が生きているうちに変わっていくだろうなーと思っている。モバイル方面のエンジニアは増える予定あるけど今後も絶賛募集中という状況で、「最もHR部門に協力的なエンジニア」を目指して採用活動も支援してる。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。