Create a PR to update outdated libraries by script

Updating outdated libraries is important. Longtime outdated libraries probably lead difficult updating libraries. Sometimes they have breaking changes. We can reduce the risk updating libraries frequent and keep them small size.

Meanwhile, it’s difficult to catch up with ALL outdated libraries and updating them frequently. Since our works aren’t only updating them.

Get outdated libraries by anticuado

I’ve created https://github.com/KazuCocoa/anticuado to help get outdated libraries. Using the library, you can get outdated libraries as JSON format. Currently, the library supports the below.

  • Java
    • Gradle
  • iOS
    • CocoaPods
    • Carthage
  • Ruby
    • Bundler
  • Elixir
    • Hex
  • JavaScript
    • npm
    • yarn

How to use it

For example, you can run it against cocoapods.

require "anticuado"

cocoadpos = ::Anticuado::IOS::CocoaPods.new "path/to/project"
outdated = cocoadpos.outdated 
cocoadpos.format outdated

The output is the below.

[
  {
    library_name: "AFNetworking",
    current_version: "2.5.0",
    available_version: "3.1.0",
    latest_version: "3.1.0"
  },
  {
    library_name: "OHHTTPStubs",
    current_version: "4.1.0",
    available_version: "5.0.0",
    latest_version: "5.0.0"
  }
]

You can run it on CI services like Jenkins and send them to your slack channels.

Create a new PR automatically

Lately, I’ve added a feature to create a PR which include updating outdated libraries. The below is an example of cocoapods. The target repository is https://github.com/KazuCocoa/test.example. The result is https://github.com/KazuCocoa/test.examples/pull/2

If you have CI environment, automated tests should run after creating the PR. If they are green, you probably can merge it to master branch.

As a result, you can reduce the work to update outdated libraries by yourselves.

conclusion

The update logic is not complicated, but the tasks drain our time. This kind of work will improve your development environment step by step, I believe.

Advertisements

iOS 11 Programmingを今更だけれど読んだ

そういえば、半年以上はもう経ってますよね…

飛行機の待ち時間とかにざっと読んだり、所々、きになるところは写経しながら読んだ。知っているところ、知らないところと様々あったのですが、あの時期にこれだけのものをリリースしたのってやっぱりすごい…

個人的には、Decodable付近の話が一番実際の仕事にも結びつく感じでよかったです。PDFKit付近は、簡単なアプリ作成も兼ねて作ってみようかなと思いました。技術書系も大体はebupで購入してGoogleBooksにあげている生活なのですが、たまにPDFのものを手に入れることもありますし。そんな時に自分で作ったものでサクッと読むとかやっぱり面白いですよね。(そこまで簡単にPDFを組み込める、というところが特に面白かった)

iOS 11 Programming

iOS 11 Programming

  • 著者:堤 修一,吉田 悠一,池田 翔,坂田 晃一,加藤 尋樹,川邉 雄介,岸川 克己,所 友太,永野 哲久,加藤 寛人,
  • 製本版,電子版
  • PEAKSで購入する

そういえば、Metalもそうだったんだ、確かにというところが多くてとても為になりました。

ありがとうございました。

“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

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


[app]fuse

ちょうど、 https://www.fusetools.com/ というツールを見つけたので触ってみた。

期待としては、やっぱり簡単にアプリの雛形を作ることができ、その雛形を参考にAndroid/iOSの各プラットフォームでプロダクトを開発することができる状態でしょうか。

少し触った感じ、previewがうまく動かなかった…
マシンスペックも関係するのか。。。
まだBetaなので、もう少ししたらまた触ってみよう。

こういうのを試してみようとした。
https://www.fusetools.com/examples/circle-menu

[Elixir]Registerを覗く

key-value processとしてElixir1.4に入れる予定の Register というものが公開されました。

付属のベンチマークによると、以下のように高い性能が出ていることがわかります。

このベンチマークの内容は以下

https://github.com/elixir-lang/registry/blob/master/bench/shared.exs

プロセスを起動して、登録して。それを10000回登録する間の時間を計測しているみたいですね。
各ベンチマークの最後で登録した名前をチェックして、その欠損がないことを確認して終わり、と。

register/3 周りは以下

https://github.com/elixir-lang/registry/blob/master/lib/registry.ex#L535

ここら辺を見て回ると、 :ets テーブルを複数に分割(sharding)しているぽい。
同じようなことをしているものがあるのかなと調べてみると、以下のライブラリがすでに。

https://github.com/cabol/shards
https://github.com/cabol/exshards

プロセスを気軽に使えるように便利機能を拡充していく、という感じですかね。


おまけ

テストコード、繰り返しには以下のように fordescribetest を囲むことができるのですね。こう言う書き方もあるのねーという学びでした。

https://github.com/elixir-lang/registry/blob/master/test/registry_test.exs

[Elixir]diff of struct against elixir 1.2.6 and 1.3.1

pattern match with struct

  • Structでもpattern matchingすることができる
    • [Kernel] Allow variable struct names when matching, for example, %module{key: “value”} = struct

__struct__

__struct__ が補完候補に出てこない。けれど、使うことは可能。

  • Elixir 1.2.6
iex(1)> Version.
InvalidRequirementError    InvalidVersionError
Parser                     Requirement
__struct__/0               compare/2
match?/2                   parse/1
  • Elixir 1.3.1
iex(1)> Version.
InvalidRequirementError    InvalidVersionError
Parser                     Requirement
compare/2                  compile_requirement/1
match?/2                   match?/3
parse!/1                   parse/1
parse_requirement/1

ただし、Elixir1.3.1でも、

iex(1)> Version.__struct__
%Inspect.Error{message: "got Protocol.UndefinedError with message \"protocol Enumerable not implemented for nil\" while inspecting %{__struct__: Version, build: nil, major: nil, minor: nil, patch: nil, pre: nil}"}
iex(1)> %Version{}
%Inspect.Error{message: "got Protocol.UndefinedError with message \"protocol Enumerable not implemented for nil\" while inspecting %{__struct__: Version, build: nil, major: nil, minor: nil, patch: nil, pre: nil}"}

と使うことは可能。

[iOS]EarlGreyを使ってシナリオを記述する

過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。

幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。

EarlGreyについて

EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。

リポジトリはこちら。

https://github.com/google/EarlGrey

EarlGrey自体の説明はあるのでここでは書きません。

何か困った時

使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。

  • APIドキュメント
  • Matcherの実装
    – どのように動作しているか、といった説明も書かれているので、ざっと一読することをお勧めします
    https://github.com/google/EarlGrey/blob/master/EarlGrey/Matcher/GREYMatchers.h
    – AccessibilytLabelやidentifierの他にも、Valueなど多くの要素が使えるのよいですね
    – ただ、 We strongly recommend using an accessibility identifier as it uniquely identifies an element. と書かれているように、やぱり accessibilityIdentifier を使うことが良いことには変わりなさそう。ここは激しく同意。

Other Tips

  • 要素を見つけたい時
    • シミュレータだと、AccessibilityのAccessibility Inspectorを有効にしてそれを使うと良いです
    • Appiumだとinspectorを使ったりPonyDebugger使ってたのですが、このAccessibility Inspectorが実は一番楽なのかも?
  • Search Fieldなどで”Search”をしたい(テキスト入力後の決定)
    • \ngrey_typeText で入力しましょう。そこを契機にkeyboardの”return”や”search”になる箇所の操作と同じ動作をします

シナリオの記述例

以下、Searchフィールドをたっぷ、”KazuCocoa”と入力して決定、検索するというシナリオです。

  • selectElementWithMatcher で要素を見つけ、 performAction で何か操作をし、 assertWithMatcher で要素をチェックする。
  • EspressoのViewMatcher、Perform、Assertの形と同じですね。Googleではこういう形での記述に統一しているような雰囲気を得ます。

具体的には以下。

Appiumとの使い分け

ざっくりと書くと、ツールの使い分けは以下な感じ。Quickなどはありますが、やはりSwiftでシナリオベースのテストコードを書くのは面倒です。なので、本当にその視点から記述したシナリオベースのテストを残しておきたいなら、私はAppium + Rubyをベースにしたものをつかたいと思います。

  • Appiumを使うとき
    • シナリオを記述したテストコードの実行
    • ネットワークキャプチャなどのアプリ全体を操作したい時
  • EarlGreyを使いたい
    • CIに組み込む
    • 限定的な操作を安定して早く実施したい
      • イメージとしては、単一の機能であったり、境界値によってViewが変化するような隅っこのチェック
    • Layoutをチェックしたい(image diffではない)

image diffなんかは単なるassertionの手段なので、必要に応じて使いましょう。

こういうのを、社内で置いているテストレベルと照らし合わせながら導入できると雑多にはならなさそうですね。

XCTest -> EarlGrey -> Appium

という感じで、ロジックのチェックからGUIのチェック、アプリ全体の計測まで進んでいくと順当そう。
ちょうど、テストサイズをベースにするとS/M付近がXCTest、M/L付近がEarlGrey、L/EがAppiumという感じの関係性でしょうか。

締め

あまり情報がないですが、やはり短時間で成果を出すにはこの手のテストコードも素早く安定させた形にすることが必要です。その上で、この手ではできないことを人が実施する。

そのためにはこういうツールやテストの構築方法含め、フルで知見を導入していきたいですね。

Reading “Raft” – consensus algorithm

Raftという、合意アルゴリズムが存在する。これは、多数決を元にした多数派の意見を決定するためのアルゴリズムで、分散環境下における合意形成でも使える。最近、分散系の幾つかのWebサイトを眺めていると見つけた。

私は、こういう系統の技術分野は大学院の頃にByzantine General Problemを扱ってから比較的興味を持っている。

実際のツールだと、CoreOSのetcdやhashicopeのconsulなんかで使われているみたい。

Raft自体に関係するところは以下。

幾つかの言語で実装されているみたい。etcdではgolangぽい。

幾つかRaftの論文のreferencesを見てみましたが、Byzantine faultなんかはやぱり参考にされていました。2014年が論文としては初出?

LESLIE LAMPORT氏によるByzantine General Problemの問題は、懐かしさがある(大学院の頃によく読んでいた)。最近はご無沙汰だけれど、技術だけの話でいうとこれ系が関わる仕事はしてみたいな。

参考

[Elixir]愚直にズンドコキヨシ

こちらの「ズンドコキヨシ」を簡単に実装してみた。Streamとか、そういうのは使ってない。実際に処理するメソッド数は3つ。 Enum.take/2 のようなものは使っていない。

実行

iex> c "zndc.exs"
iex> Znd.kiyoshi
"ズンズンズンズンドコキ・ヨ・シ"

Listの追加方法を先頭から追加する形に少し変更してみた。ついでにdropしてた所を出力してみた。ただ、少しに煩雑になったかな…