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

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

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

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

ポイントとしては

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

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

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

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

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (157件) を見る
とか
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (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

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

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

f:id:laiso:20170918034140j:plain

TL;DR

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

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

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

*

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

f:id:laiso:20170918031603p:plain

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

f:id:laiso:20170918032130p:plain

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

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

f:id:laiso:20170918032200p:plain

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

f:id:laiso:20170918032259p:plain

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

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

f:id:laiso:20170918032320p:plain

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

f:id:laiso:20170918032338p:plain

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

f:id:laiso:20170918032401p:plain

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

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

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

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

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

f:id:laiso:20170918032438p:plain

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

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

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

f:id:laiso:20170918032510p:plain

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

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

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

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

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

f:id:laiso:20170918032635p:plain

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

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

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

f:id:laiso:20170918032728p:plain

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

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

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

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

f:id:laiso:20170918032826p:plain

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

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

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

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

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

f:id:laiso:20170918032951p:plain

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

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

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

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

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

f:id:laiso:20170918033021p:plain

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

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

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

f:id:laiso:20170918033051p:plain

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

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

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

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

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

f:id:laiso:20170918033118p:plain

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

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

f:id:laiso:20170918033134p:plain

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

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

f:id:laiso:20170918033238p:plain

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

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

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

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

f:id:laiso:20170918033304p:plain

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

f:id:laiso:20170918033323p:plain

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

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

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

f:id:laiso:20170918033345p:plain

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

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

f:id:laiso:20170918033406p:plain

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

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

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

f:id:laiso:20170918033435p:plain

皆さんも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 が開催されました

f:id:laiso:20170708224115p:plain

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 な VonicOnsen 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: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

try! Swift Tokyo 2017 に参加した

try! Swift にDay 1, 2 へ行ってきたので感想を書きます。 すべてのセッションを拝聴できたわけではなく、一部だけ聞きに会場へ足を運びました。 あとから資料と他の人のレポート見れば補完できるかなーと甘えた気持ちでいたのですが、結論としては全部聞けばよかったと後悔しています。 (勉強会スタイルの「スライド資料」大規模イベントでの「プレゼンテーションのトーク」の性質の違いをよく分ってなかった)

イベントの感想

  • 様々なテーマのトークが聞けるよう設計されておりSwift言語のコアな話題以外も聞けました
  • 国内外の他の参加者との交流が促進されるような仕組みがありました。通訳、Q&A, ハッカソンイベント
  • 世界的に活躍しているデベロッパーの生の話を聞けました。日本に居ながらこの規模・質のイベントに参加できるのはたいへん貴重でした

コンピュータビジョン

スマートフォンのカメラを通じた画像認識関連の話題がいくつかありました。

業務で実世界の数字検出するコードを書いていたので参考になりました。

try! Swift 2017で「クライアントサイド・ディープラーニング」というLTをしました #tryswiftconf - Over&Out その後

AppleがCNNモデルによる手書き文字認識のサンプルコードなどを公開していることを今回知りました

https://developer.apple.com/library/content/samplecode/MPSCNNHelloWorld/Introduction/Intro.html

名刺管理アプリWantedly Peopleでの話

リアルタイム物体検出アプリでよりよいフィードバックを提供する | try! Swift Tokyo 2017 #tryswiftconf Day1-15 - niwatakoのはてなブログ

物体検出のスキャンビューの具体的な実装の話があり参考になりました

機械学習

機械学習の話もありました

Swift開発者が知りたかったけど聞きにくい機械学習のすべて | try! Swift Tokyo 2017 #tryswiftconf Day1-1 - niwatakoのはてなブログ

ユーザーインタフェイスとAI技術の共通点に関してはうなずくところがありました。

Googleの「AIファースト宣言」が示すように、機械学習、Deep Learningによるデータ革命はモバイルのユーザーインターフェイス開発にも影響を与えると思います

Googleは「モバイルファーストからAIファーストへ」。その理由は、いずれデバイスという概念は消え去り、インテリジェントなアシスタントになるから - Publickey

「1クリックを0クリック」にするのがUIデザインの力だとすると、クリックの必要性をマイナスにするのがデータ革命の力です。

テスト

前回のtry! Swiftと比べて印象に残ったのはテストや品質管理関連のセッションの多さです

try! Swift Tokyo 2017 テスト系セッションまとめ #tryswiftconf - やらなイカ?

クックパッドアプリに長年テストエンジニアとして携っているkazucocoaさんのお話は圧巻でした

クックパッドアプリのテストを味わう | try! Swift Tokyo 2017 #tryswiftconf Day1-8 - niwatakoのはてなブログ

Appiumなどを活用したUIレイヤーの高度に自動化されたテストをここまで大規模に行っている例は見たことがありません。 プロダクトが成長し、組織にテストエンジニアリングに取り組む人が出現することがスタート地点であるので、 多くのエンジニアにとって大規模テストのスケールへの仕組みの話は貴重な情報となることでしょう。

以下は聞き逃しました(聞きたかった)

テスト可能なコードを書くということの2つの側面 | try! Swift Tokyo 2017 #tryswiftconf Day1-1 - niwatakoのはてなブログ

OCHamcrest/OCMockitoの作者の人が来てるぞ、というのを発表直前に気付いてサプライズでした。モックオブジェクトの話でした

モックオブジェクトをより便利にする (Try! Swift2017) - Qiita

JUnit系のモックとスタブ、フェイク、スタブオブジェクトなど類似用語がたくさんありiOSコミュニティでは混同されがちだったのです、モックオブジェクトをテスト対象の依存として差し込む正統派の例で他の人にモックとスタブ化の違いを教える時にお手本になりそうな内容でした。

最近Swiftを書きはじめて、Objective-C時代のProxyオブジェクトやメソッドディスパッチングのdynamicなテスト手法をSwiftにあわせて安全に最適化していなないといけないなと感じるところでした。

サーバーサイド*Swift

イベント的にも今回サーバーサイドSwiftは1大セクションとしてプッシュされていたように思います。運営コミュニティの一角のRealmやIBMも近頃はサーバーサイドのソリューションに熱心です。

今回CocoaPodsコミュニティでよく見かける開発者が多く居ました。Web APIの設計・開発の話をしてくれた kylef さんもその一員です

SwiftのWeb APIとアプリをともに構築する | try! Swift Tokyo 2017 #tryswiftconf Day1-11 - niwatakoのはてなブログ

個人的に興味のある分野だったこともあり疑問点を質問しました。「APIドキュメンテーションの例にAPI Blueprintをあげているのはなぜ?」といった内容です。僕ならSwaggerを第一に候補にすると思われたからです。 しかし後程彼のプロフィールを見ると彼の現在の職がAPI Blueprint開発元のApiary社だということに気付きました。意図せず意地の悪い質問になってしまいました。

Realmのmrackwitz(彼もCocoaPodsコミッタの1人です)からはRealm Mobile PlatformというローカルDBのsynchronizeソリューションを使ったアプリ開発について話がありました

Realmを使ってコラボレーションアプリを作る | try! Swift Tokyo 2017 #tryswiftconf Day1-13 - niwatakoのはてなブログ

RealmとNode.jsを使ったサーバーサイド連携についてリリース時よりいろいろ遊んでいたので興味深く聞きました。 realmデータの外部システム(Railsアプリとか)との対話やNode以外のプログラミング言語への対応+Webブラウザのクライアントサイドの連携は引き続き気になるところです。

noviさんが関るデータ基盤のクローラー実装をscrapyからSwiftに置き換えるプロジェクトの話もありました

様々な場面でSwiftを使う | try! Swift Tokyo 2017 #tryswiftconf Day1-3 - niwatakoのはてなブログ

NSURL系のHTTPクライアントに使うコア実装は僕が以前チェックした時は絶賛開発中といった状況でしたが今は libcurl で実装されているようです(Cocoa版はCFSocket系でC++独自実装だったかと思います)。 libmysqlclientベースのコネクターを開発されているのは知っていましたが、nkfで文字エンコーディングを処理している話も聞けました。

全体としては「ほとんどC」でがんばっているという印象でしたが、今後pure Swift実装でパフォーマンスが出たりするとサーバーサイドSwiftコミュニティはさらなる発展しそうだと感じました。

クロスプラットフォーム

サーバーサイドSwift以外にもiOS/macOS由来技術とか別のアプローチでアプリを開発する話が盛んでした

中でもSwiftでAndroidアプリを実装する発表は変態性が高かったらしく私の周りでも「ほとんどC」と評判でした

try! Swift Tokyo 2017 - Swift on Android(1) - Qiita

確かにWebクライアントサイドの世界でもWebAssemblyが控えていますし、LLVM関連技術の重要性は今後増してゆくばかりです

A WebAssembly Milestone: Experimental Support in Multiple Browsers ★ Mozilla Hacks – the Web developer blog

またしてもCocoaPodsコミュニティでお馴染のortaさんの話すArtsyのネイティブアプリケーション開発についての物語について話がありました

独自のツールを構築する | try! Swift Tokyo 2017 #tryswiftconf Day1-14 - niwatakoのはてなブログ

個人的にかなり刺さる内容でした。Swiftカンファレンスで「Swiftをやめてしまった」話をするのにはかなりの勇気が必要だったことでしょう。 思えばネイティブアプリ開発がウェブ開発に比べ作業コストが重く時間がかかる事実を私たちは暗黙的に受け入れてしまっていました。 ここに疑問を見出して、組織として製品としての開発環境の改善に挑むのがArtsyのストーリーの見所です。

この講演でReact Nativeが提供するJavaScriptエコシステムのパワーに注目した人は多いと思います。 しかしAppStoreで “Artsy” のアプリをインストールした人は居たでしょうか? 触っていて「適材適所」のフレーズが頭に浮んだら、私たちは同士です。

「UI開発をSwiftで加速する」については先日公開されたKickstarterのOSSコードに見られるPlaygroundを活用したUI開発にも可能性があると思っています

kickstarter/ios-oss: Kickstarter for iOS. Bring new ideas to life, anywhere.

PAY.JPについて

イベント開催の直前の土壇場になってスポンサー参加を受け入れてくれ、各所の協力を得て無事シルバースポンサーになることができました(その節は誠にありがとうございました)。

最近の我等がPAY.JPについてもB2C領域を本腰入れてやっていくぞ! ということでtry! SwiftやDroidKaigiにスポンサー参加してiOSやAndroidアプリを開発する人デザインする人を募集しているのですがいまいち採用状況の進捗が「無」に等しい。無 to 在 のフェーズなんですが、リサーチによるとそもそもモバイルのデベロッパーコミュニティでの知名度もなく、ブランディングがうまくいってなくて

PAY.JP からイメージするものって

  1. 社外取締役の家入氏
  2. BASEさん。モバイルBASEアプリ
  3. ウェブに露出の多いCEO, CTOなどの要職の人々
  4. なんかそれ以外(のうちの10%ぐらいがPAY.JP)

といった具合でした。

家入さんなんかは最近CAMPFIREの人なので見たこともないけど影響力強過ぎだろうと参っています。 そして、ことモバイルデベロッパーに関してはあれだけ炎上バズっているえふしんさんのブログ知らない人も何人か居て、ブランディングというのは難しいものだなーと思っている次第です。

なので今 #rebuildfm に広告を投入しようか、と奇策をねっているところです。

「try! Swift Tokyo 2017」イベントスポンサードのお知らせ

「俺」(代表:俺 。東京都渋谷区 )はこのたび、プログラミング言語「Swift(スウィフト)」に関するカンファレンス/ハッカソンイベント「try! Swift Tokyo 2017」にゴールドスポンサーとして協賛いたします。

f:id:laiso:20170222224750j:plain

www.tryswift.co

「俺」は、今回のイベント協賛を通じ、世界のSwift開発環境の発展をサポート出来ることを大変光栄であると考えています。 「俺」では、スポンサーブースの不出展、懇親会の欠席、ハッカソンの不参加などでこれからも、さらなるSwiftの普及・発展に協力してまいります。

【沿革:「俺」について】
1981年 誕生
2016年 ジンバブエドル調達の失敗
2017年 「try! Swift Tokyo 2017」イベントスポンサード

※「iPad」「iPhone」「iPod touch」は、米国および他の国々で登録されたApple Inc.の商標です。iPhoneの商標は、アイホン株式会社のライセンスにもとづき使用されています。