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の商標は、アイホン株式会社のライセンスにもとづき使用されています。

BASEに入社した

近況

ユビレジ での勤めを終えて、ネットショップ作成サービスの BASE(ベイス) で働きはじめた。

決済サービスのPAY.JP のプロジェクトにエンジニアとして参加している。

(何かを予期した二年前の投稿)

入社の経緯

時系列順にいうと

昨年末ぐらいに退職の打診をして今後どうしようかなーと正月だらだらしていた時に以下のニュースを読む。

jp.techcrunch.com

なんとなーくショッピングやフリマアプリもしくは金融サービス(フィンテッ・・)の方面の開発現場が楽しいんじゃないかと考えていて、 そういえばBASEが決済サービスをやっている会社だということを思い出して、どっちもやってる好都合な会社あるじゃんと膝ポンして*1「次のプロジェクト」の候補に入れた。

「転職ドラフト」というサイトに登録して好き勝手ウォッチしていたらCTOから声をかけられたので見学に行く

job-draft.jp

「面談に出てくる人たちが全員デカい」程度の好印象を得て帰宅する。

上記の募集だとどうやらBASEショッピングアプリのモバイル開発人材を探していたようなんだけど、面談でPAY.JPのことをしきりに聞いてたこともあってか後日「PAY.JPのチームにも会ってくれ」と連絡が来た。

PAY.JPはもともと外部の会社と合流してBASEの元にあるので、なんか組織形態的にも分かれているとのことだった(これは入社してから正確に理解した)

www.fashionsnap.com

業界や会社に勢いがあってええやんけと思っていたところいつの間にか内定が出ていたので働くことにした。

決済サービスやってる会社なんていくらでもあるじゃん? と思うかもしれないけどサービスの信用上詳細を書けないが、関っているプレイヤーや状況などを加味してユーザーに提供できそうな価値が、思想的にもビジネス的にも技術的にもイケそうな手応えがあった。(イケそうというのは「世界をより良くする世界をより良くする」のマントラを唱えながら労働するという意味です)

社内の印象

サービス立ち上げの時代から活躍している二十代若手社員中心の開発組織に、経験者の採用を強化してチームの成長を促すような人事面のサポート体制があるように感じる。どんどん新しいメンバーが増えていて、みんなでサービスを拡大していくぞ! というような空気がある。

事実とんでもない勢いでユーザー規模は増加していて、技術的な面でも組織的な面でも課題てんこ盛りで圧倒的人手不足なので優秀なエンジニアさんデザイナーさん今すぐジョインしてくれ!*2 という心境だろう。

www.wantedly.com (起死回生の求人の一手の様子)

BASEとPAY.JPはセキュリティ要件により物理的にオフィスが分断されていてあまり会社全体を見る機会がないんだけど、みんなSNSやチャット大好きインターネットピーポーなのでログで残ってる。

BASEチームはおたくサークルのような健全さがあり、みんな仲がいい。「Stay Geek」という社是がぴったり。すろっくさんという名物エンジニア(SRE)がおり、彼のタイムラインを見ていれば会社の雰囲気はだいたいわかる。

PAY.JPチームはコンピュータークラブのような御淑やかな雰囲気で落ち着いてる、あとなぜか冷房が寒い。Pythonコミュニティで活躍している人が何人も働いている贅沢な環境で、コードが超参考になる。

プロダクトに関しては来月の以下のイベントでバーンとやっていきますみたいな発表があるようだ(NO関与)

base.connpass.com

あと、みんな10時に出社してくる(すごい)

ユビレジをふりかえる

ブログで求職していたら突然連絡が来てかなり舞い上ったのを覚えている。その当時何十社か就職先をひたすら検討していたんだけどユビレジに参加できるとは全然思っていなかったので、候補を全部押しのけて入社を決めた。

なにせその頃は採用活動してる雰囲気はなくて、選ばれたOSS界隈のトップレベルの人達だけが加われる雲の上の存在のような憧れの会社だった。

業界の人材流動性的にこの面子で一緒のオフィスで同じソースコード触れるチャンスは今を逃すと一生ないなと思ったのでもう即決だった。

f:id:laiso:20160822234500p:plain 当時の筆者の心境 (アオイホノオ 小学館より)

Scala

入ってから一番ビビッたのは既にScala界のすごい人が全員ドワンゴに移ったのを知ったことだった笑*3。今でも他の会社の人に「ユビレジってScalaの会社ですよね」と言われるので相当Scalaな人たちが残した功績は大きかったのであろう。

ユビレジはすっかり今ではRailsの会社なんだけど(Railsコミッターがコード書いてた)、過去にScalaに移行しようとした形跡がGitHubリポジトリにあった。

Play2である時期まで活発にコミットされていたコード、これがひときわ禍々しさを放っていので後日退社前にリポジトリの管理を僕がしていた時に「バイバイ、スカラ」といって消した。

CTO

その次ぐらいに驚いたのが当時CTOの*4 soutaroさん の職業人としての能力の高さだ。これは外からは全然わからなかった。

朝から晩までフロントエンド-DB-ハードウェア-モバイルの全部のレイヤーのコード書いていて運用やユーザーサポートに借り出され帰ってきたらSketchでデザイン制作しプロダクトマネージャの全行程を勤め経営会議に参加しチームのマネジメントもするという寿命と頭脳を消費する滅茶苦茶な仕事をこなしていた。

彼のおかげでスタートアップのCTO像のハードルが一気に上がってたまったものではない。明かに業務が集中し過ぎているので入社してしばらくして社内の状況を把握した後は、soutaroさんの雑用が減るように動くことが組織にとって望ましいと思ったので意識して実行した。

iOS

ユビレジでは「iOSのことを最も知らないiOSエンジニア」という不思議な立ち位置で仕事をした。

入社する前は最前線のiOS開発現場なのでバリバリiOSのプログラミング能力を上げるぞ! と思っていたんだけど、いざチームに入ってみると自分よりiOS超得意な人にiOS方面は任せればよくて、現在チームに足りていない部分を補強するのが自分に向いているというのを感じたからだった。

なのでiOSの一線の開発情報とかはパタリとチェックしなくなっていたし、趣味でコードも書かなくなっていた。

具体的にはクライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要な領域を任せてもらえるのが僕の強みだというのがわかった。器用貧乏さという裏の弱点があるわけだけど、しょうにあっているしこれは今後も役に立つだろうとは思う。

フロントエンド

iOSのコードを趣味で書かなくなったかわりにフロントエンドやJavaScriptの最新情報をチェックしていた。

ユビレジはRailsデフォルトに乗っ取ってCoffeeScript+Backboneでフロントエンドを構成していたんだけど、シングルページアプリケーション化に舵をきってからとうもの規模が大きくなってきて自前で Marionette.js のような仕組みができつつあり、精鋭のRailsエンジニアが片手間で書いてたJSに苦労させられる場面が課題だった。

当時 6to5 プロジェクトこそ未来だというのは azu_re というBOTみたいな大量の情報を吐くアカウントを追っかけていれば当然のことだったので、RailsアプリからフロントエンドのGUI開発を解放するためにユビレジもその流れにのってもらうことにした。

Reactを実験的に試しつつSprocketsに巻き込まれ重傷を負いつつも少ししたらいきなり事態が好転して、JavaScriptをメインで書くことを期待された強力な新入社員たちが加わったのだ。かなり救われたと思って彼等と相談し当時鳴り物入りで登場したReduxをメインにフロントエンドを再構成する活動がはじまった。

そして強力なメンバーが入ったことにより僕は「JavaScript超できる人いるからわざわざやらなくていいか」(怠惰かよ) という思考に陥りはじめる……

プロダクトマネージャー

日々のタスクとしてはiOS開発が一番人手が薄く求められていたのでしかたなくオブシー*5を書いてだらだら仕事していたんだけど、その頃から ninjinkun's diary なんかに影響され「UXとは」と独り言をいいながらその手の本や知見を得て、色んなビジネスアプリを触りながら自社製品の改善点を黙々と報告していた。

ユビレジには伝統的にというか前述のCTOが全部やってる問題があったので開発ディレクター・プロダクトマネージャーの職位がなかった。しばらくしたら歩夢さんというキラキラネームの人がやってきてプロダクトマネージャーを兼任していた。彼もフルスペックな人でビビったのだけど、なにせ会社ごと一緒になったので製品とかシステムも増えてやることはたくさんある状況だった。

なので「各自必要を感じたらなんか関係者をつかまえていい感じにやれ」ぐらいのゆるい感覚で進行管理をしており「開発者を一気に増やしてコード書いてみたけど謎の要因で1年間リリースが凍結されている。謎の要因がはたして何なのか、それは関係者をつかまえていい感じにやれ」というようなプロジェクトがザラにあった。

これが結構「クライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要」というのにフィットしていたので助けることができると踏んだ。 やってみると爽快でコードを書かずに製品を良くできるんだ! という感動があった。今までは要求された仕様に対していかに良いコードを書くかテストを自動化するかというような価値観でプログラミングしていたので、世界が広がった。

ユビレジは「無断ユーザー訪問し放題」という性質があるのでこの頃はジャンジャン使っているお店に行ってみた。

チーム・労働環境

女性比が高く男子校っぽいノリがなくて快適だった。メンバーも謙虚で助け合いの精神を持った善良な人たちばかりだった(小池陸以外)。

みんな遅くまで残ることもないし、子育て世代もいっぱいて働きやすいと思う。

「開発合宿やるぞ!!!!」と盛り上っていた時も僕行かないッスと言ったら免除してもらえて快適だと思った。

出社時刻は完全に裁量労働に忠実な無法地帯で、午前に出社する定時組と昼過ぎにバラバラと来る人達「24時までは午後なので出社と言えそう」「出社失敗」などの概念があった。僕はだいたい午前中のんびり過しランチして出社20時ぐらいまでには帰ろーという生活をしていた。休日出勤はゼロで、在宅勤務もし放題だった。

入社した頃はなぜか朝会が17時にあり、夕方以降にものごとが動きはじめたりしていて完全にユーザーとのタイムゾーンのズレがあったので譲歩して15時にした。

退職

退職の話をマネージャや社長にしたらえっ、辞める要素ないのになんで!? と驚かれたので逆に僕はえっ理由用意しとかなきゃいけなかったかとビックリした。これに限らず僕のキャリア感というのはちょっと他人とズレていることを認識した。僕はユビレジもBASEも同じようなコミュニティの人たちで似たような会社だから異動みたいなもんかなと考えていたのだけど、世間ではそうでないようだ。

なぞの思考回路によるめんどうくさい持論みたいな理由はいくらでも出せるんだけど、めんどうくさいので「金と名誉のために転職した」というストーリーでお願いすることにした。実際給与は上っているし(逆にユビレジ入社時に給与交渉レベルのささいなことに関心がなかった)。

スタートアップと待遇

スタートアップ(ここでは出資を受けて拡大を目指す企業ぐらいの意味)で働くと薄給で長時間働くことになるんだろうなという古い意識を未だに持っている人を時々見かけるんだけど、それは良い環境の大企業と劣悪な大企業を見つける程度の差でしかないですよというのを言いたい。

大企業にしかないリソースの壁というのは確かにあると思うけど、大企業のリソースでしか到達できない領域に辿りつける人なんて全世界ランク10%以内の人達とかですので我々には関係ない。

BASEなんて「学生発」「インターネット」「シェアハウス」「家入」*6この時点でいかにもまともな給与出なそう会社に見えるけど、普通にユビレジと同じく良い待遇を受けられる企業なのでどんどん応募するとよいと思います。

www.wantedly.com

www.wantedly.com

ユビレジはまだエンジニア/デザイナー募集出てないけど単にWantedlyに投稿忘れてるだけなのでメールするか関係者にコンタクトを取るかすればいいと思います(しかしハードル高過ぎでしょう)

*1:正確には二子玉川方面にも1個ある

*2:大袈裟に書いています

*3:大袈裟に書いています

*4:俺と一緒に退任したのもビビった……

*5:https://twitter.com/laiso/status/758884371453530113

*6:オチにしてすみません。新刊を買いましょう → さよならインターネット

atteアプリ開発の話をイベントで聞いてきた

これ:アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました - Mercari Engineering Blog

Golang と Google App Engine

https://speakerdeck.com/ttsuruoka/atutekai-fa-falseji-shu-golang-to-google-app-engine

Datastore APIの話とかPython SDKが出た頃によく触っていたので懐かしかった。

App Engineは2013年ぐらいにやっとAPNSのPUSH通知ができるようになったのだけど、(http://blog.lai.so/entry/20130415/1366024996

最近他の会社でもGAE/Goの組み合わせて使っているプロジェクトを見かけるし。特にGCPリリース以降、バックエンドにAWSじゃなくてHerokuでもなくてGAEというのが選択肢になってきているんだなーと感じた。

そういえば2012年に調べたことがあるんだけど、インフラはAWS一色だなーというのhttp://blog.lai.so/entry/2012/02/16/003509 を思い出した。

また言語選定の話で、特にGo言語書き慣れている人たちを集めてきたわけではないというのが興味深かった。Scalaなども選択肢にあったのだろうけど、Goのスクリプト言語系の書き手への相性の良さとGAEの存在が決め手かなと感じた。

(PHPの優位性は協業するウェブデザイナーに一番リーチしているところだと思います)

また重厚なウェブフレームワークは使わずに標準的な小さいライブラリで構成していくのがGoのやり方だろうと解釈もなるほどと思った。

Goは以前話題になった時はCの替わりのシステム開発言語ぐらいに思っていたけど、これでウェブアプリ開発するのに俄然興味を持って帰りに入門書を買ってしまった。

スターティングGo言語 (CodeZine BOOKS)

スターティングGo言語 (CodeZine BOOKS)

Go言語によるWebアプリケーション開発

Go言語によるWebアプリケーション開発

Swift と RxSwift

https://speakerdeck.com/bricklife/atutekai-fa-falseji-shu-swift-to-rxswift

CocoaPodsが嫌いでCarthageが使えるiOS 8以上をターゲットに設定したというネタが枕にあって、パッチ2、3送っているぐらいのファンとしては気になったがビルドエラーのトラブルとかが嫌われてしまう原因かな。それはわかります。

RxSwift、というかリアクティブプログラミング(Rx)系のライブラリを採用した理由として「メルカリアプリでずっとReactiveCocoaを使っているのでなしでは組めなかった」というのが面白かった。

僕はWindows系のアプリケーション開発(Silverlightぐらいの時期)やHaskell for GTK+なプログラミング環境でリアクティブエクステンションとかFRPとかの概念を知り以前から興味を持っていて、 自社のアプリでReactiveCocoa本格的に使いたいなーと思ってもう2年できずにいるので羨ましかった。早い段階でReactiveCocoa導入していた人たちはあとはKobito(OS X), freee(iOS)なども居たと思う。

RxはUI非依存なストリーミング操作だけ保守的に使うというtipsもあるけど、UIコンポーネント拡張を取り入れた方が段違いに恩恵があっていいと思っている。

Reactと同じくプラットフォーム横断で思想が共通しているのがRxの良いところなので、AndroidのUIもRxJavaで組んでいるのでしょうか。ウェブアプリは?RxJS?

質疑応答で発言して「ネコ風のあいつ」が描かれたトートバッグをもらいました

「川」という隠語はよく把握していませんが内輪用方っぽい

アッテiOSの設計と開発フローの変遷

https://speakerdeck.com/ishkawa/atuteiosfalseshe-ji-tokai-fa-hurofalsebian-qian

MVVM

各タイムラインの要素を<Element>で表現したページネーションViewModelを複数のViewから参照する図が出てきたけど、複数のViewControllerにまた別の振る舞いを追加したくて実装をViewModelで共通化したい時にViewControllerはViewModelを一対多で持つのか一対一で巨大なViewModelを拡張していくのかというところが書き慣れてなくてピンとこなくてちょっと自分でやってみないとわからないなという感想だった。

Caching

RealmをキャッシュDBに使ってなんでもオブジェクトを作っていたんだけど破綻したという流れがあったけどちょっとこれも実際のソースコード見てみないと何が問題なのかわからなそうだった。

でもメモリに乗せてJSONに書き出して時限でいらなくなったら消すというのは普通に有効なパターンだと思った。Himotokiとかもいきなり出てきたし設計自体が流動的に変わったのだろうと推測。

ところでなぜRealmはライトウェイなキャッシュストアに使われがちなのだろうか。 というかマイグレーションが必要な永続化ストア需要が地下鉄で使われるアプリケーションとかにはあまりないのも関係していそうだ。

Deployments

結構自社とやっていることが似ていた。というかどこも似たようなものなのかも。

ユビレジではangleddeckというツールがあって、これがプルリクエストのOPENでインストールURL付きのウェブアプリをBOTがコメントでつけてくれてマージする前に非開発者でも確認しつつ作業を進められるのでみんな使った方がいいと思った(でもApple Developerエンタープライズ契約がいる)

ちょうど Quipper の開発事例 とかHerokuの Review Apps のiOS版という感じ

こういうツールはだいたいCTOのsoutaroさん(kではなくmの方)に「こういうのが欲しいんですよ〜」と話すと次の日に納品されてくる(関係性が逆だ……)

あと soutaro/Obihiro というPageObjectでのViewControllerテストツールもお気に入りでこれも使って欲しい

JSON RPC

さらっと出てきていたけど JSON RPC の採用は結構肝だと思った。クライアント側から各通信で欲しいデータを柔軟に取ってきたり調整が楽なんだろうなと想像した。この辺深掘りしたい。

(余談:某社ではNode.jsのAPIサーバーが各大規模サービスの前面にあって、フロントエンドエンジニアの人が自分が叩きたいWeb API自前しているという話も聞いたことがある。それに近い。)

monorepo

FacebookやGoogleのやり方に従って関連リポジトリを1つにまとめて管理する方法を取っていると聞いたのだけどサーバーサイドだけの話だろうか。

モバイルアプリも全部含めて会社で1つ? 聞きそびれた。

所感

メルカリ2年ぐらい前には他のフリマアプリよりは比較的ユーザー少なそうに見えていたんだけどよくこの短期間で急成長したなーとビックリした(偉そう)。

新しい価値を新しい事業で作るために新しい会社を設立して新しい人たちを集め*1新しい技術を使って開発したという意図があるように見えた。

技術者コミュニティへのブランディング活動の巧さはテックブログ黎明期の頃のウノウラボブログの存在を思い浮かべさせてちょっと面白い。

*1:中心となっている技術者は古株メンバーだったけど

いのちの指輪としての技術顧問

新取締役及び技術顧問就任のお知らせ にあるとうり会社には技術顧問という肩書の人がいて、プログラマーの世界ではビッグネームなタレントが揃っているんだけど、はたして一般社員の開発者にとってこういう仕組みがどういう意味をなしているのかということに触れたい。

おそらくはてなブログ読んでいる技術者というのは技術顧問というお仕事 のNaoya Itoさんような現場に入って組織の課題を技術者の立場から意見して改善してゆくプロジェクトの請負人というのを想像するの? かどうかはよく分からないが、 ユビレジの場合は何か具体的なタスクを行っているわけではない。なのでレンタルCTO的なイメージと比較するとコミットが少なく見えると思う。 僕の知る限り他の会社では契約時に会社が週や月に何回かの定期訪問(もしくはビデオチャットなど)をセッティングしたりすることもあるらしいが、それもない。 これにはもともと技術顧問両氏はフルタイム、パートタイムで出社して他の開発者と同じように製品開発のタスクを何年か行っていたので、いざ技術顧問を受け入れて問題を解決や〜というきっかけはなかったという事情がある。

ウェブで見聞きできる中では「月に1回Matzと話せるという福利厚生がある会社」というのが近いのではないかと思うが、 それよりは若干チームにコミットしていてチャットに常時いるのでアドバイザーっぽく技術的な相談をけしかけたり、雑談したりは気軽にできる(まあお二人が多忙であろうのはなんとなく察しがつくのであまりやりとりは発生しないけど)。 あとは間接的には「あの凄腕技術顧問氏が目をかけるような会社だ」と人材市場にイメージを与えるという意味もあるんだろうなと思う。

ということでMatzがジャイアントパンダ的なモフモフであるとするのならユビレジの技術顧問は装備しておくとフィールドでHPが回復してゆくお得なアイテムである、というのが僕の見解です。

「死亡時にインターネットへの告知を希望しますか? はい/いいえ」

という項目をはてなブログの http://blog.lai.so/about へ載せれるようになるといいと思った。臓器提供カードのような役割で。

僕は以前からインターネットの人は死んだかどうかよくわからないので偲ぶタイミングがあんまりなくて不便だということをとなえていた。

しかし自分ごとをして考えると、生死不明のままインターネットのログになりたい人もいるだろうから各自選択できるのが好ましい。

インターネットへの投稿を個人の秘密として完全に墓場まで持っていけるケースがどの程度あるのかはよくわからないが、僕等のようなインターネットへ何か投稿し続けていないと自我が保てないような人々は身内や知人への根回しがないとこれは難しい。

そして独自ドメインには死後にURLが消滅してしまうリスクもある。それを考えるとはてなみたいな死人のログが手厚く維持されそうなプラットフォームを選択して投稿をすべきなのかもしれない(Twitterはまだいまいち信用できていない)。