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

近況

4/1に株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

そしてBASEに入社した からしばらく経つので振り返りがてらに近況を書くことにした。

BASE社とPAY事業部

かなーりわかりづらかったので、頭の中にある組織図をツリー形式にしてみた

- BASE
  - プラットフォーム開発: ECサイト構成の心臓部な部分
    - PHPエンジニア
  - アプリ開発: ショッピングモールアプリ開発
    - API(PHP)エンジニア
    - iOSエンジニア
    - Androidエンジニア
  - プロダクトマネージャ・BI
  - SREチーム
  - デザインチーム・フロントエンド
  - 営業
  - メディア編集 :  コンテンツ制作
  - カスタマーサクセス・ユーザーサポート
- PAY
  - PAY.JP : オンラインAPIを提供するサービスの方
    - Pythonエンジニア
      - API
      - Web
      - SDK
      - 社内システム
      - インフラ
  - PAY ID : BASEに組込まれてる購入アカウントの方
    - iOSエンジニア
    - Androidエンジニア(居ない)
  - BizDev
- コーポレート
  - 人事
  - 総務
  - 経理
  - 法務
  - 広報
  - 情報システム

こんな感じで100名に満たないぐらいの段階の1会社があって、この図でいうと僕は PAY ID -> iOSエンジニア になるみたいだ 。 これがどこまで正確に表現できてるかどうか不明だけど入社してしばらく咀嚼するまでいまいちわからずやっていっていた

まずBASEとPAYでメインのプロダクトが二分していて、それぞれにBtoBとBtoCの側面をもったサービスがある。 BASEがリリースから3〜4年目の組織だとすると、後から加わったPAYは1〜2年目といったところで組織の成熟度などにフェーズの差がある。 さらにその中でもBtoBの開発のが先行していてBtoCが後発ではじまったというのもある。

PAYのBtoCのやつは決済インフラとしては元気に動いているがサービスのブランドとしてはまだピヨピヨしている感じ。なので組織の一番若いところのプロジェクトに入った。

僕が入った時のBASEのアプリ開発は「半年前に入社して引き継いだiOSエンジニア1名」ががんばって開発していて「Androdエンジニアは訳あって0名」という絶望的な状況で。Androidアプリのバグ修正が誰もやる人居ないけどまぁいいか、というムードだったのでいくつかプルリクエストしたりした。けどしばらくしたらあの人やこの人たちがどんどん人が入ってきて今はアプリ開発チームの所帯が育ってきた、という状況。

会社の雰囲気

ユビレジは30代が中心の会社だったけれどBASEは20代と、一気に若返って雰囲気も大分違う。一番新鮮だったのはエンジニア職以外の人もITツールをネイティブに使いこなせるほどリテラシの水準が高いことだった。すごい。

入社した頃はみんな10時頃出社してきてそれもあんまり見たことない光景だったので新鮮だったが、自分自身も朝早く(10時は早いのか 🤔)来ないこともあってよくわからなくなってしまった。だんだん人が入れ変ってゆくうちにDST(ドワンゴ標準時)が適用されはじめたりとかしないとか。

コミュニケーションの機会はあるんだけど全然参加せずとも勤務できており、部署内外の人とひとつも会話が発生しないで退勤することがよくあり大丈夫なのと思うけどなんか問題起きないので過している。同僚の顔もよく覚えてないのですれちがっても気付かないし社内の人との会話カバレッジが著しく低い。チャット上でのやりとりで基本全部済ませていて、このチャットで話しかけている人顔知らないなぁみたいなことがよく発生する。

社内をよくファッション誌の編集部員とかアイドルみたいな女子とか下駄の人とか(下駄かよ)が歩いているけどはたして社員なのか、アイドルが生息しているのか。定かではないけど気にしないようにしてる。

そしてPAYチームについて

PAYのエンジニアは10名ぐらい全員PythonでWeb開発やっている感じ。ビープラウドとかPyspa(Python温泉)周辺の関係者や元「今すぐ Follow すべき PHP 界のスーパーエンジニア*1 」、オライリー本著者(もう来てないけど)などで構成されており「続・ラフなラボ*2 」の人も書いてたけどある程度の規模と品質を保っているコードベースでPythonを書きまくる環境として最適なんじゃないかと思う。

事業的には直近ではBASEの取引数が爆発的に成長しているのでバックエンドのPAYもチート的に成長していて、それに加えて某オンライン決済APIの撤退からの移行ユーザーがガッと押し寄せている。

プロダクト的には現金主義の慣習や銀行とクレジットカード業界の構造で成り立っている古い仕組みを新世代のサービスでアップデートしたいというところが主で、世のフィンテック競合他社とされているところは個人的には「戦友」という実感。 内部的な視点でみるとフィンテックもAIブームも関係なく世の中や市場が求めているので絶対今のオンライン/オフライン決済のUXは自分達の世代が生きているうちに変わっていくだろうなーと思っている。是非見届けたい。

モバイル方面のエンジニアは増える予定あるけど今後も絶賛募集中という状況で、「最もHR部門に協力的なエンジニア」を目指して採用活動も支援してる 。

早くiOSのプロジェクトやっつけてAndroidアプリ書きたいので、iOS x Android両方グ〜ンと書いていきたい人はご連絡ください(上の組織図を見てBASEのこのへんが気になるというメッセージくれてもいいよ)

www.wantedly.com

*1:http://sotarok.hatenablog.com/entry/20110617/1308227462

*2:https://memo.laughk.org/2017/01/09/0003.html