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 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 = "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 The result is

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.


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.


[Android]Change locale with Android O

The method of changing locale changes in Android O.

+        if (Build.VERSION.SDK_INT >= 26) {
+            // getConfiguration moved from ActivityManagerNative to ActivityManagerProxy
+            activityManagerNativeClass = Class.forName(amn.getClass().getName());
+        }

Appium has already supported the change.

[Android]Jetpack for test related environments

I’ve bet Truth since [Android]Checking Android Testing Support Library 1.0. I encountered an issue using AssertJ with ATSL 1.x and I talked about it in before.

In a talk , Google starts to provide Jetpack. The pack has various libraries and test related libraries as well. For example, Espresso.

What I surprised is Truth Android extension. They announced the extension will be bundled in the pack. It means they will bundle Truth as an assertion library for Android. For me, the news was very good opportunity since it shows my prediction was a success.

Robolectric 4.0, Nitrogen and AndroidTestOrchestration were also interested.

We can see an announcement of Robolectric in . According to the release note, we can implement test code like instrumented tests but can handle it via Robolectric. In the video, we can hear running test in no emulator environment and I predicted it was this feature. Recent years, Googlers have committed to Robolectric heard and I also thought it would integrate to one of the testing libraries.

class OnDeviceTest {
  @get:Rule val rule = ActivityTestRule(

  @Test fun clickingOnTitle_shouldLaunchEditAction() {

I’ve noted some interesting things for me in the Google IO especially test.

[Android]Use apkanalyzer to get apk data

It’s important to make configurations programmable to manage them codebase and enhance automation. Android has provided apkanalyzer to analyse test target apks easily. Before the command, we use aapt for example. But with the analyzer command, we can get apk related data from target release apks easily.

The below is a simple wrapper for adb and apkanalyzer written in Ruby. I’ve used it to integrate adb commands to integrate Ruby test code.

[Android]New release of ATSL and new feature of composer

Lately, I’ve been using composer to run instrumented tests in the Android world. ([Android]composer and swarmer)

Today, I just found an interesting PR. =>

The PR is emulating the behaviour like AndroidTestOrchestrator. As you know, the orchestrator has some limitations and it includes Parameterized tests aren't currently supported. It is JUnit4’s feature. So, the test support library has introduced JUnitParams.

The PR also has the same limitation. My project has been introduced the new Params so we don’t affect the limitations. But if you’d like to introduce the new composer’s feature, you should take care it.

I also just found interesting news.

Espresso 3.0.2, Runner 1.0.2, Rules 1.0.2, Monitor 1.0.2, AndroidTestOrchestrator 1.0.2 (2018-04-24) have been released!

They have some good improvements and fixes. For example:

  • Espresso 3.0.0 should NOT depend on test runner
  • ActivityTestRule doesn’t update Activity instance during configuration changes
  • Pass -e clearPackageData flag if you wish the orchestrator to run pm clear context.getPackageName() and pm clear targetContext.getPackageName() commands in between test invocations. Note, the context in the clear command is the App under test context.

Reading the release note, they fixed and improved many things for AndroidTestOrchestrator. That is brilliant.

[Appium]Image comparison with Appium and other libraries

In general, we compare two images when we’d like to detect differences between them in visual.

I believe OpenCV and ImageMagick are famous tools to achieve the purpose lately. But sometimes we faced building errors, for example. So, I’ve used a simple enough comparison tool. That is Kobold. The library uses blink-diff as a comparison engine. The library provides some features to configure how to compare each other.

I’ve published Ruby wrapper to use them.

And you can also see some articles for it on this site. (Most of them are Japanese, and you need to translate though…) Link

By the way, I also researched some similar and straightforward libraries. I believe perceptualdiff also a famous library. I compared ImageMagick and perceptualdiff a bit before.

A few years ago, I started to investigate OpenCV, opencv_sample is one example, to make such comparison more flexible. The reason why I investigated it is many guys have been implemented Machine Learning / Deep Learning features in it. So I’ve believed it helps us.

And lately, Appium is going to support OpenCV based comparison features as one of the fundamental features. is the brilliant PR. We can use some OpenCV features via them. We are also able to get diff images to ensure the results in visual.

The feature will help many users who would like to get image comparison easy.

Actually, to make test suites stable, separating steps are important like:

  • Conduct test cases and assert the results without image comparison
  • Compare images
  • Collect and save the results

Otherwise, the new Appium feature will encourage automation more, I believe.

[iOS]xccov and JSON format

Before Xcode 9.2, we can get formatted coverage data using, for example. The library formats llvm-cov.

But from Xcode 9.3, xccov is introduced officially. The command can run via xcrun.

xccov is a new command-line utility for inspecting the contents of Xcode coverage reports. It can be used to view coverage data in both human-readable and machine parseable format. To learn more, enter man xccov in Terminal. (37172926)

I tried the feature with and I put a simple Ruby gem script to get the target name and the line coverage.


$ git clone && cd test.examples
$ xcodebuild -workspace test.examples.xcworkspace -scheme test.examples -derivedDataPath Build/ -destination 'platform=iOS Simulator,OS=11.3,name=iPhone 7' -enableCodeCoverage YES clean build test CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport > result.json


We can get some kind of format.

# Output:
$ xcrun xccov view --json Build/Logs/Test/*.xccovreport | jq .

# Output:
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport | jq .

Parse the JSON with Ruby

parsed = './result.json')
parsed.targets_line_coverage[""] #=> 0.35


From Xcode 9.3, we can get formatted coverage data using xcrun command. I’ve seen some scripts use Slather and Nokogiri to handle XML format and collect them. But the script will be more simple. Does this make you happy?

Read “Practical network automation”. It was for network engineers

I bought the book of Practical Network Automation when the book was discount.

The main topic is Ansible and Python code for network engineers who have few experience for Python/PowerShell. I expected more programming related stories, but it is a bit fundamental stuff.

BTW, when I saw some word such as “Software Defined Network”, “Open Flow”, etc, and it made me nostalgic… (My previous company and sort of my university age.)

[Appium]get performance for iOS

So long ago, I tried to monitor iOS performances using instrument commands. But I gave up once because of host machine’s load.

But is created and that is awesome…

I just remember seeing the PR and I’ve published this article in my memory…

touch Kubernetes

I know of Kubernetes, but I have few experience for that.

But the kubernetes community has interesting tutorials.

I can imagine the architecture and how to work.
I guess I’ll use them and Istio though.