HOW UBER ENGINEERING VERIFIES DATA AT RUNTIME WITH THE ANNOTATIONS YOU ALREADY USE を公開していた。 彼らが、Androidでよくある問題(NPEとか)に対して、model層の例えばAPIの結果をvalidationし、その結果が期待していないものなら必要な例外を投げて、意図しない値を不用意に使わないようにするとか、NPEになるようなExceptionの発生を抑制してしまおうとか、そういう話のようですね。この判定はRuntimeに行われます。 それにより、意図しないデータが帰ってきたとか(例えばnonnullなはずなのにnullがAPIで得られたとか)に対して必要な処理を実施できるようになる、と。 ( reference from: https://eng.uber.com/rave/ ) https://github.com/uber-common/rave が対象となるリポジトリ。 Ecceptionを一様にCrashlyticsにnon-fatalで送るとか、クライアントのエラーログをサーバに蓄積するとかも良いですが、こういう形でそのエラーを区別できるようになると監視なども捗って良さそう。More
Category Archives: development
[Kotlin]Kotlin in Action vol3
Kotlinを学んでいて、 I've been learning Kotlin these days, since I need it, and then I feel my experiences for Swift and Elixir/Erlang affect it. — KazuCocoa (@Kazu_cocoa) May 7, 2017 みたいな感想を受けました最近。 Kotlin、このように複数interfaceを受けてsuperで順序選択するんですね。 Kotlinでは、初期では final がデフォルト。open class Hoge : Neko {} を使う場合、そのクラス内で宣言されるoverrideなんかは open が暗黙的に宣言されるので、final にしたい場合は final を宣言する必要があるらしい。 まだ先は長いですが、徐々にKotlinに取り組むことができ始めた。More
[Swift]try!Swiftで学んだことまとめ
私は職場で作ってきたテストの話のうち、UI Testに近いところの話をしました。 英語での発表は初めてだったのですが、一部想定通りに話せなかったところがありながらも無事に終えることができ、ホットしました。日本以外から来た人含め、いろんな人から英語も聞き取りやすかったし内容も良かったと言って貰えて、ひとまず安心しました。 20170302 tryswift tasting_tests from Kazuaki Matsuo お題の悩み 私はSwiftを使ったテストの話(Unit Test)をするかとか、protocolベースのDIの話をテストに絡めるか、UI Testの話をするか悩んでいました。 推薦されたことで話すことができるようになったので、try!Swift全体の中でそれぞれの話す内容が重ならない程度の話題にした方がバリエーション豊かになって良いかなと思い、UI Testsやその周辺の話をしました。 ただ、このレイヤの話はSwift自体でそこの話をするにはネタがない。XCUITestとかだとSwiftではなくiOSフレームワークの話になりますしね。半端にSwift x XCUITest(内部コードとか)の話をするよりは、テスト全体とUI Tests、Re-Engineeringnの話をする方が独自性を持った話ができるかと思い、結果的には話すことにしました。 結果的には、unit test関係で想定していたセッションの内容は他のスピーカーの方々が行なっていたので、重ならずに良かったかもしれません。 運営の方からは良かったとフィードバックをいただけたので、推薦いただいたことに対しては役目を果たせたと感じてはいます。 他のセッション すでに nowsprinting さんがまとめを書いていたので、テストに関してはそこにお任せ。 内容自体はprotocolやstruct付近を使った話で、functional programmingもかじっていると理解を深めることができる内容でした。 The Two Sides of Writing Testable Code ここで出てきた “co-effect” に関しては以下が参考になるらしいので、少し読んでみようと思います。 http://tomasp.net/blog/2014/why-coeffects-matter/ http://tomasp.net/academic/papers/structural/ ReactNative 3日目のハッカソンでは、その間に行われたReactNativeのゲリラワークショップを経験しました。 http://artsy.github.io/blog/2017/02/05/Front-end-JavaScript-at-Artsy-2017/ https://github.com/KazuCocoa/MyArtistExample ReactNativeのテストには、JSレベルでは jest、UIレベルだと testID を付与してからのUI Test系ですね。 JSの世界でテストが実行できると、unit testでもXCTestよりも素早くテストのサイクルを回すことができて良いですね。 最後に 本当にお疲れ様でした & ありがとうございましたMore
「Swift実践入門」を読んだ
同僚や、知人が書かれていることもあり、Swift実践入門を読んでSwift言語への理解を深めてみました。 私個人のスキルでいうと、公式のThe Swift Programming Languageの2.1向けのものや、Functional Swiftとかの英語書籍を読んだり写経したりして簡単なSwiftプログラムを書いたり読んだりはできる感じです。iOSエンジニアとして会社でコードを書き続けているわけではないです。 内容は、うろ覚えだったり把握していなかったとところを補足することができ、言語自体の学びを整理することにとても役立つ書籍でした。iOS周辺の開発になると、こことは別にAPIへの理解も必要なのですが、私はそこはまだまだ足りていない… 全体的に、Swiftの様々な機能をどういう形で使うと良いのか、というところで参考になりました。以下、私が読んでいてメモしておきたかったところをメモしておきます。 2章 Swiftにおける範囲型、Optionalの話とか、復習になった。特に、 ? や ! のforce unwrapの話。実行時に評価されて無理やり値を取り出す ! と、 .none になる ? の話とか。 テストコードだと、例えばEarlGreyのようなやつだと実行時評価が必要なことが多く、 ! を使ったりしていた。けれど、Swiftの理想でいうとやっぱり ! は思想に反する(実行時にしか評価されないし、クラッシュするし)のでやぱりよくないのだなーと。 as? によるダウンキャストや as! as? によるアップキャストの話もちらほら。 3章 switch の制御で以下のようにかける形、Erlang/Elixirを学んでいたので自然な感じだった。こういうの書き始めると、Androidの世界にも時折欲しいと思う時がある… 繰り返しの for … in … {} は使ったこともあるのですが、 case 使う場合もinを支えたのですね。把握していなかった… switchの中、 break を置くことはよくやることですね。Javaとかやっていると。これ、breakしないと多くの場合は次々と case を実行していくのですが、swiftでは明示的に fallthrough を与えないといけないのですね。 あと、 breakやcontinueの遷移先を制御するために label をつけることができるとは知らなかった… 4章…More
[Mac][RedwoodHQ]Run on Mac
RedwoodHQ on Macを過去書いた時点ではMacで動かすことができていなかったのですが、最近見て見るとLinux/Mac上でも動作するようになっていました。 http://redwoodhq.com/redwood-download/ からダウンロード・展開して、 を実行、 http://172.0.0.1:3000 へブラウザからアクセスする、です。私はNode 4.7.2で実行していました。 ちなみに、このRedwoodHQは以下にフォークされてPRなどが取り込まれていました。 https://github.com/wolterskluwer-redwoodhq/RedwoodHQ もともと作ってた人は退いたのかな。More
[Java][Android]Error patternを検出する
Google製のFindBugsみたいなもののようです。 http://yone098.hatenablog.com/entry/2017/01/27/115753 https://github.com/google/error-prone これのパターンに何があるのかは以下に書かれていました。 http://errorprone.info/bugpatterns ざっと見てみると、DaggerなどのDIツールを使っている時のルールもありました。 独自ルールも追加できるみたいですね。 なので、何らかの自社製ライブラリへ適合させる時も使いやすいのかな。 Bazelを見ると、Bazelではすでにこれが組み込まれてて、デフォルトONなのですね。 https://github.com/bazelbuild/bazel/blob/c4e92b1ba06fba48121e4db8050a69b6d998e2e9/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/BazelJavaBuilder.java#L108 もう少し話がそれると、Bazelでは以下がデフォルトで組み込まれているのですね。 https://github.com/bazelbuild/bazel/blob/c51d506eb83f1e5974e3317c53532f6e81ca50d8/third_party/BUILD#L310 以下、試しに適用してみたコミットになります。 https://github.com/KazuCocoa/WebSocketDemoForAndroid/commit/806fe6cebef4e4c4435817b989fddf74724c55de これに対してビルドすると、generated codeに対してwarningが確認されました。 内容は http://errorprone.info/bugpattern/MissingOverride なのですが、ここら辺を見ているとGoogleのJava style gideに合致しているかも見ているのですね。More
[app]fuse
ちょうど、 https://www.fusetools.com/ というツールを見つけたので触ってみた。 期待としては、やっぱり簡単にアプリの雛形を作ることができ、その雛形を参考にAndroid/iOSの各プラットフォームでプロダクトを開発することができる状態でしょうか。 少し触った感じ、previewがうまく動かなかった… マシンスペックも関係するのか。。。 まだBetaなので、もう少ししたらまた触ってみよう。 こういうのを試してみようとした。 https://www.fusetools.com/examples/circle-menuMore
[iOS]run tests on simulators vol2
[iOS]Run multi simulators with FBSimulatorControl にも書いている、iOSシミュレータを1つのマシンで複数動作させるやつ。最近ではLinkedInからOSSが公開されましたね。Blogはこちら。スターも多く、さすがLinkedInという感じ。 社内で FBSimulatorControl ベースの複数シミュレータで実行する環境を作ろうと思っていたけれど、もっと素晴らしいものが世に出てきててオォォォという感じ…(私、価値出せてない…) ここら辺、実装能力が顕著に現れて私は本当にまだまだと思う一方です。。。 以下、以前からある類似のものをピックアップ。 類似 https://github.com/linkedin/bluepill https://github.com/plu/pxctest このeBayに属している方、とても価値出している… https://github.com/plu/parallel_ios_tests 以前はxctoolを使って並列実行をサンプルとして実施可能にしていたのですが、今はpxctestをベースにしているらしいですね https://github.com/facebook/FBSimulatorControl 過去のBlogにも書いやつ。最近のこれ系のツールはこれを基本としていることが多い。 これを実施していると、正直なところ並列実行できないCloud実行環境はイマイチですね。 ローカル環境強し。。。More
Architecture for GUI Testing(mobile)
In 2014, I talked about GUI testing architecture. 20141018 selenium appium_cookpad from Kazuaki Matsuo Recently, someone asks me about the architecture.So, I post the blog about it. The following flow means the architecture. I think this architecture is common if anyone uses libraries such as Cucmber. Scenario layer Describe scenarios. This layer depends on “User…More
[React][iOS][Android]Try ReactNative + TypeScript
以下を参考に、ReactNative + TypeScriptでアプリを書いてみる。 ReactNativeでは testID としてiOSはaccessibilityIdentifier、AndroidはView#setTag/getTagが使われている。(ただ、2016/9ごろにAndroidに対してresource idを付与できるようになったとあったので、ReactNativeでもresource idベースでも今後は大丈夫かも) 以下を参考にした。環境構築周り。 https://medium.com/react-weekly/react-native-and-typescript-ad57b7413ead#.el446eisr https://github.com/mrpatiwi/ReactNativeTS https://medium.com/react-weekly/react-native-and-typescript-ad57b7413ead#.3cdqtxsr2 https://github.com/KazuCocoa/MyFirstReactNativeTS ただ、上記のどれもそのままでは動作しなかったので、本格的にはまだ触っていない。More
~ my tech diary ~ 