“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 needs through continuous discovery directly with customers
  • Autonomy to employ technical practices that enable continuous delivery
  • Autonomy to organize technical and team boundaries around business outcomes

リーダーシップ

Leadership requires two things: a vision of the world that does not yet exist and the ability to create it.
Simon Sinek


OKRの設定とその達成への取り組み


より効率的な、高い成果を出すのであれば、横断的、協力的、誠実にこなしていくことが必要となってくる。

If high performance is your goal, you need to accept that the design of teams and the design of software systems are inextricable. You must design cross-functionally, collaboratively, and conscientiously.


ユースケースのモデリングの話。以下のようにユースケースをモデリングし、管理していく。読んでると、Specification by Exampleのような話が展開されていることがわかる。

When I want to so I can .

そのほかに、TDD/BDDやコンテキストマップなどの使い方も提示している。使い方のきっかけを載せている感じ。


チーム間で知識を共有していくことで、各々のチームの発展にも言及していた。

  • Show and Tell
  • Cross-team pairing
  • Cross-skill pairing
  • Mapping the System

だいたいは想像している感じ。これらを組み合わせて、知識を循環させるという感じの内容。


そういえば、Complexityの理論と整理も行われていた。Simpleが一番因果関係が予測可能な状態を表現する。だんだんと、不確実性や複雑さがまし、予測だったり区別がはっきりしなくなる。これらに対してどのように対応していくか、対応できるようなチーム/組織にしていくかというのも一種の目的とその設計となってくるのだろうな。

  • Simple
  • Complicated
  • Complex
  • Chaotic
  • Disorder

ところで、これは、科学よりもアートに近い、と表現している箇所がある。確かに、組織論は科学的なものよりも、どう設計して表現させていくか、というところに寄っていくのでそう表現しているのだろうな。


Advertisements

[Elixir]format syntax automatically

https://github.com/elixir-lang/elixir/pull/6639/files has been merged to master, and Elixir lang support formatting feature by default.

The following library is my experimental place and I’ve adapted the formatter to the library is create a pull-request.
https://github.com/KazuCocoa/http_proxy/pull/43/files

[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。
そのために、

XCTAssert(NSClassFromString("XCTest") != nil)
XCTAssert(NSClassFromString("XCTestCase") != nil)
XCTAssert(ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil)

などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITestEarlGrey によるテストを行うときもこの判定に引っかかります。

以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。

https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5

これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。

XCTAssert(ProcessInfo.processInfo.environment["EarlGrey"] == "true")

https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f

プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要(プロセス外で定義した環境変数は参照されない)

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な関数宣言を適切にモジュール内で使っていたリファクタリングの話なんかは、少し新鮮で面白かった。

a = fn x -> IO.puts x end
a.(1) # 1, :ok

あと、 :ok, :error で結果を出し分ける言語文化(from Erlang)の話も触れていたり、コラムもほどほどに詳しいところに踏み込んでいて良かった。

最初の一冊よりは、少しチュートリアルをやった後にElixirらしい記述をするためのとっかかりとして学ぶとか、そういう書籍っぽい。

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

ラムダノートから出版されている、RubyでつくるRubyを読んだ。

とちぎRuby会議07で、同書籍の一部を学び、そこからまるっと学んだ感じ。ElixirのMacroやLispがこの木構造と同じ形をとるので、木構造に分解された抽象構文木を見てもさほど読みにくさはなかった。

大学の頃、コンピュータサイエンス系をかじると大体はこういう分解された処理機構に触れるのではないかなと思います。それをRubyを使い、わかりやすく表現している書籍。プログラミングにまだ慣れていない人でも、読みながらインタプリタを書き、どういう形で構文が解析され、実行されるかを観察することができるとても良い書籍だと思います。

良い復習になったと思う。

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

長らく読んでいたのですが、Kotlin in Actionをようやく読み、写経などし終えた。
他にも同時にやっていたとはいえ、このときからすると時間としては結構長かった…

ただ、Kotlin全体の形や、以下のような処理を書いたりしてというところが理解・発想できるようになったぶん、読んで全体を知ることはよかったかなと思います。

以下は、KotlinでSpekといった大きなライブラリを使うほどではないけれど、テストにコンテキストを持ち込みたい時なんかにプロジェクトに書いておくと良いのではないかな、と思うやつです。

class Then {
}

class When {
    fun then(description: String, then: Then.() -> Unit) {
        then.invoke(Then())
    }
}

class Given {
    fun `when`(description: String, `when`: When.() -> Unit) {
        `when`.invoke(When())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  `when`("description for when") {
    then("description for then") {
      println("finish")
    }
  }
}

KotlinだとWhenが予約語になっているので、Spekででもなのですが、Given/On/Itスタイルにすると良さそう。

class It {
}

class On {
    fun it(description: String, it: It.() -> Unit) {
        it.invoke(It())
    }
}

class Given {
    fun on(description: String, on: On.() -> Unit) {
        on.invoke(On())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  on("description for on") {
    it("description for it") {
      println("finish")
    }
  }
}

すぐに書くことはできるものですが、一応、ここではライセンスをMIT Licenseにしておきます。

The MIT License (MIT)

Copyright (c) 2015 Kazuaki MATSUO

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

[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 like the following.

SoftAssertions().apply {
  assertThat(1 + 1).isEqualTo(1)
  assertThat(1 + 3).isEqualTo(2)
  assertThat(1 + 1).isEqualTo(3)
}.assertAll()

So useful syntax 🙂

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で送るとか、クライアントのエラーログをサーバに蓄積するとかも良いですが、こういう形でそのエラーを区別できるようになると監視なども捗って良さそう。

[Kotlin]Kotlin in Action vol3

Kotlinを学んでいて、

みたいな感想を受けました最近。

class Button : Clickable, Focusable {
    override fun click() = println("I was clicked")

    override fun showOff() {
        super<Clickable>.showOff()
        super<Focusable>.showOff()
    }
}

interface Clickable {
    fun click()
    fun showOff() = println("I'm clickable!")
}

interface Focusable {
    fun setFocus(b: Boolean) =
        println("I ${if (b) "got" else "lost"} focus.")

    fun showOff() = println("I'm focusable!")
}

fun main(args: Array<String>) {
    val button = Button()
    button.showOff()
    button.setFocus(true)
    button.click()
}

Kotlin、このように複数interfaceを受けてsuperで順序選択するんですね。
Kotlinでは、初期では final がデフォルト。open class Hoge : Neko {} を使う場合、そのクラス内で宣言されるoverrideなんかは open が暗黙的に宣言されるので、final にしたい場合は final を宣言する必要があるらしい。

まだ先は長いですが、徐々にKotlinに取り組むことができ始めた。

[Swift]try!Swiftで学んだことまとめ

私は職場で作ってきたテストの話のうち、UI Testに近いところの話をしました。

英語での発表は初めてだったのですが、一部想定通りに話せなかったところがありながらも無事に終えることができ、ホットしました。日本以外から来た人含め、いろんな人から英語も聞き取りやすかったし内容も良かったと言って貰えて、ひとまず安心しました。

お題の悩み

私は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 さんがまとめを書いていたので、テストに関してはそこにお任せ。
http://nowsprinting.hatenablog.com/entry/2017/03/05/061441

内容自体はprotocolやstruct付近を使った話で、functional programmingもかじっていると理解を深めることができる内容でした。

The Two Sides of Writing Testable Code

ここで出てきた “co-effect” に関しては以下が参考になるらしいので、少し読んでみようと思います。

ReactNative

3日目のハッカソンでは、その間に行われたReactNativeのゲリラワークショップを経験しました。

ReactNativeのテストには、JSレベルでは jest、UIレベルだと testID を付与してからのUI Test系ですね。
JSの世界でテストが実行できると、unit testでもXCTestよりも素早くテストのサイクルを回すことができて良いですね。

最後に

本当にお疲れ様でした & ありがとうございました