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以上をターゲットに設定したというネタが枕にあって、パッチ２、３送っているぐらいのファンとしては気になったがビルドエラーのトラブルとかが嫌われてしまう原因かな。それはわかります。

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のやり方に従って関連リポジトリを１つにまとめて管理する方法を取っていると聞いたのだけどサーバーサイドだけの話だろうか。

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

所感

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

debedebe

現在、この世の事象ほぼすべてが証券化され、市場原理の元に、売買がなされている。 ゲームを考えた 皆さんはもうおそらく意識することなく、まるで食事をとり、睡眠をとるかのようにブックマークをされている事かと思います。 次の事柄を、ブログ読者が引いてしまう度合いの小さい順に並べ替えよ。 結局自分が見つけたのは、肥大化した自己愛、でした。 ネビュラチェーンって何？ だがな。たほいや倶楽部だけは邪魔したらマジで許さんからな。許さん。これだけは。 消極的なんかじゃない。突き詰めた結果なんだ。限りなく透明に近いだけなんだ。何の話だ。 はてブで人気エントリーになるような質問がしたいよぅ（´・ω・｀　） こぼしてないですよ私こぼさせたら大したもんですよ

画像でふりかえる2015年

Qupzillaプラグインを作る@Linux Desktop Advent Calendar 2015

f:id:laiso:20151205004955p:plain

Linux Desktop Advent Calendar 2015 - Qiita の4日目です

(まったく需要がなさそうな話題ですが)QupZillaというGPLv3ライセンスのQtWebKitベースのウェブブラウザがあり。最近これを愛用しています。

http://www.qupzilla.com/

このブラウザを使う理由はChromeやFirefoxの都会暮しに疲れたからとかPhantomJSの気持ちになってデバッグする気分のぐらいの時しかないですが、それはそうとQupZillaには自分の好みの動作になるよう機能を拡張するプラグイン機構があり、今時のウェブブラウザらしくソースコードディレクトリ内へC++/Qtのコードを書いて放り込みいっしょにコンパイルします。

git clone https://github.com/QupZilla/qupzilla
cd qupzilla/src/plugins

にGreaseMonkey、マウスジェスチャなどの標準プラグインが入っています

git clone https://github.com/QupZilla/qupzilla-plugins

へサンプルプラグインがあり、これを組み込んで機能が追加できるのが確認できます PluginInterfaceのインターフェイスを実装してQtのAPIを呼んだりメニュー要素を差し込んだりします。

余談ですが、過去にKonquerorというKDEのブラウザを使っていたのですがこの度Chroniumベースの別のブラウザ実装に置き換わるようです、とArchiWikiに書いてあった https://wiki.archlinux.org/index.php/KDE#Konqueror_and_Rekonq