Category Archives: development

“Designing Autonomous Teams and Services”を読んだ

元々はこれ => http://www.oreilly.com/programming/free/designing-autonomous-teams-and-services.csp ちょくちょくと、オライリーさんからこういった無料で購読できる、ちゃんとした内容のものが増えているように見えますね。こういうところで経験をまとめ、今後のビジネスにしていくという著者のスタイルとか一般化しているのでしょうか… この書籍を表現すると、複雑な課題に自律的に取り組める組織/サービスを作る、ということだろうか。（タイトルのまんま…） 実際に、この書籍は単に組織の話だけではなく、例えばBDDやユースケースをモデリングして管理する為のサンプルの提示なんかもしている。Microservice関係の書籍、Spotifyのエンジニアリング組織といったあたりの有名どころの情報に触れていない人にとっては、よくまとまった書籍という感じがします。 気になったところをかいつまんで以下に残しておく。あまり文章としてまとめる気持ちにならなかったので、今後の自分のポインタとして… どこに境界を引くかというところ To maximize autonomy and enable business agility, it is essential to align organizational and technical boundaries. 誰/何に自律的なところを期待するか これらを持っているチームの場合、より高い嬪度で良い連携を組むことができる。 Aligned autonomy—that is, a shared understanding of the company’s strategic context and key objectives Autonomy to make business and product decisions Autonomy to develop a rich understanding of user…More

[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。 そのために、 などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITest や EarlGrey によるテストを行うときもこの判定に引っかかります。 以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。 https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5 これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。 https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要（プロセス外で定義した環境変数は参照されない） reference https://stackoverflow.com/questions/26946677/uiapplication-sharedapplication-delegate-as-appdelegate-causes-exc-bad-access?answertab=active#tab-top https://stackoverflow.com/questions/39478895/can-you-pass-environment-variables-into-xcodebuild?rq=1 https://stackoverflow.com/questions/27930137/ios-swift-separate-appdelegate-for-xctest/27981726#27981726More

read “Learn Functional Programming with Elixir”

少し気になっていたLearn Functional Programming with Elixirがβ公開されたので、気になって読んでみた。 内容自体はすでになんらかのElixir本を学んでいると特に目新しいものにはでくわさないと思う内容だった。ただ、7、8章の Design Your Elixir Applications, Handle Impure Functions はまだ公開されていないが、この箇所は少し雰囲気がElixirの説明から実際のアプリケーションに話が寄っている感じがしている。 内容として、高級関数の他に、末尾最適化の話も触れていたし、そこは実際のプロセスモニタリングしながらmemory消費の優位性を明記していたところが良かった。 あとはeager/lazy関数のことも言及していて、以下のような無名関数を使い、lazyな関数宣言を適切にモジュール内で使っていたリファクタリングの話なんかは、少し新鮮で面白かった。 あと、 :ok, :error で結果を出し分ける言語文化(from Erlang)の話も触れていたり、コラムもほどほどに詳しいところに踏み込んでいて良かった。 最初の一冊よりは、少しチュートリアルをやった後にElixirらしい記述をするためのとっかかりとして学ぶとか、そういう書籍っぽい。More

「RubyでつくるRuby」を読んだ

ラムダノートから出版されている、RubyでつくるRubyを読んだ。 とちぎRuby会議07で、同書籍の一部を学び、そこからまるっと学んだ感じ。ElixirのMacroやLispがこの木構造と同じ形をとるので、木構造に分解された抽象構文木を見てもさほど読みにくさはなかった。 大学の頃、コンピュータサイエンス系をかじると大体はこういう分解された処理機構に触れるのではないかなと思います。それをRubyを使い、わかりやすく表現している書籍。プログラミングにまだ慣れていない人でも、読みながらインタプリタを書き、どういう形で構文が解析され、実行されるかを観察することができるとても良い書籍だと思います。 良い復習になったと思う。More

[Kotlin]Kotlin in Actionをようやっと終えた

長らく読んでいたのですが、Kotlin in Actionをようやく読み、写経などし終えた。 他にも同時にやっていたとはいえ、このときからすると時間としては結構長かった… ただ、Kotlin全体の形や、以下のような処理を書いたりしてというところが理解・発想できるようになったぶん、読んで全体を知ることはよかったかなと思います。 以下は、KotlinでSpekといった大きなライブラリを使うほどではないけれど、テストにコンテキストを持ち込みたい時なんかにプロジェクトに書いておくと良いのではないかな、と思うやつです。 KotlinだとWhenが予約語になっているので、Spekででもなのですが、Given/On/Itスタイルにすると良さそう。 すぐに書くことはできるものですが、一応、ここではライセンスをMIT Licenseにしておきます。More

[Kotlin]SoftAssertions with Kotlin and AssertJ

Hi there, Do you know soft assertions provided by AssertJ? In many cases, one test case has one assertion. But sometimes we’d like to collect some assertions within one assertion, and then we can use SoftAssertions() for the purpose. Of course, we can use AssertJ in JUnit. In addition, we can use it in Kotlin…More

UberがRuntime Validationを実現するRaveのv2を公開していた

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

[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