「食の世界地図」を読んだ

食の世界地図を読んだ。

食の起源を、文献などから辿れるだけ辿って、そのルーツを垣間見ることができる文庫。その食の時代背景なども含めて見ることができる。

少し前に読み終わっていたのだけれど、メモ。

[Appium][OSS]Thanks for t-shirt and stickers

A few months ago, I start maintaining Appium’s ruby-binding.

[Mac][RedwoodHQ]Run on Mac

RedwoodHQ on Macを過去書いた時点ではMacで動かすことができていなかったのですが、最近見て見るとLinux/Mac上でも動作するようになっていました。

http://redwoodhq.com/redwood-download/

からダウンロード・展開して、

$ ./start.sh

を実行、 http://172.0.0.1:3000 へブラウザからアクセスする、です。私はNode 4.7.2で実行していました。

ちなみに、このRedwoodHQは以下にフォークされてPRなどが取り込まれていました。

https://github.com/wolterskluwer-redwoodhq/RedwoodHQ

もともと作ってた人は退いたのかな。

[Android][Accessibility]accessibility check in Espresso

Androidでは、以下のようにしているといくつかのAccessibilityCheckをEspresso実行時にViewに対してチェックしてくれます。

import android.support.test.espresso.contrib.AccessibilityChecks;

@RunWith(AndroidJUnit4.class)
@LargeTest
public class AccessibilityChecksIntegrationTest {
    @BeforeClass
    public static void enableAccessibilityChecks() {
        AccessibilityChecks.enable();
    }
}

これに似た機能をEarlGreyでも実現してほしいというissueが立ってました。
https://github.com/google/EarlGrey/issues/393

ここら辺をうまく拡張していくと、自分たちの組織におけるViewなどのチェックを拡充していくことができるのでないかなーと期待。

[Elm]getting start Elm language

Elm is a functional language that compiles to JavaScript

GitHub : https://github.com/elm-lang

知ってはいたのですが触っていなかったElm。少しきっかけがあったので触ってみました。
※Elmについて、といった内容はここでは触れません。

この理由としては、チームメンバの1人がSwiftでとある機能を実装している時にこのElm Architectureから構成をインスパイアされたといっていたためです。といっても、Elm Architecture付近をチュートリアルを元に学んでみたというくらい。なので記法を学ぶというよりは、どんな問題を解決しようとどういう設計を行ったか、です。(そういえば、このElm->JSのコンパイラはHaskell製)

試したElmは0.18.0

tutorial(guide): https://guide.elm-lang.org/

tutorialをいくつか実際に動かしたGitHub repository: https://github.com/KazuCocoa/my_first_elm

Elm、実行環境も elm-repl コマンドでターミナル上から簡単に動作みることできるし、 elm-reactor コマンド実行するとローカルホストにブラウザでアクセスするとすぐに動作みることができるので触ってみる障壁がとても低くて感動しました。ドキュメンテーションとか、コミュニティパッケージ群も揃っていました。テストツールとかも、パッケージとしていくつも既に存在しているみたいです。

Elixirをもともと触っていると感じたのですが、なかなかElixirと似通ったものがありました。類似言語に影響を受けているっぽいので文法的なところもなのですが、 One crucial detail here is that commands and subscriptions are data と書いていたり、 Elm treats errors as data とあるように、データの流れを基軸として表現しようとしているところです。

では、かいつまんで。

Architecture

Elmの実装設計パターンは画面の操作を以下のように3つに分割してデータを記述するところ、データを更新するところ、それをViewに反映するところ、で分けるところです。これにより、基本的なボタンをタップするとか、そういうことに対してデータを受け取り、更新し、Viewに反映するという一定の操作を決まった定型文によって区切りながら実装することができるようになっています。

  • Model — the state of your application
  • Update — a way to update your state
  • View — a way to view your state as HTML

これに加え、例えばHTTP通信などの非同期処理などの命令を扱うためにも以下のように2種類の定義も追加されました。( https://guide.elm-lang.org/architecture/effects/ )

  • Commands — A Cmd lets you do stuff: generate a random number, send an HTTP request, etc.
  • Subscriptions — A Sub lets you register that you are interested in something: tell me about location changes, listen for web socket messages, etc.

Elmはこのeffectsの箇所でも以下のように書いている通り、この commandssubscriptions もデータを記述しElmフレームワークに渡すためだけのものとして扱うようです。そこらへんから結果を受け取ってViewに反映させるまでの受け渡しはElm側がみていると。

Aside: One crucial detail here is that commands and subscriptions are data. When you create a command, you do not actually do it. Same with commands in real life. Let’s try it. Eat an entire watermelon in one bite! Did you do it? No! You kept reading before you even thought about buying a tiny watermelon.
Point is, commands and subscriptions are data. You hand them to Elm to actually run them, giving Elm a chance to log all of this information. In the end, effects-as-data means Elm can:
– Have a general purpose time-travel debugger.
– Keep the “same input, same output” guarantee for all Elm functions.
– Avoid setup/teardown phases when testing update logic.
– Cache and batch effects, minimizing HTTP connections or other resources.
So without going too crazy on details, pretty much all the nice guarantees and tools you have in Elm come from the choice to treat effects as data! I think this will make more sense as you get deeper into Elm.
> from https://guide.elm-lang.org/architecture/effects/

あと、エラーハンドリングのところも昨今のnullやexceptionの扱いに関して言及していてよかったです。Erlang/Elixirを触っていると結果はだいたい {:ok, xxx}{:error, xxx} として処理を分けることがほとんどなのですが、そのような感じですね。

実装され、提供されている機能は以下。

  • Maybe
  • Results
  • Task

Null

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
> 本文より

Exceptions

Joel Spolsky outlined the issues with exceptions pretty nicely in the year 2003. Essentially, code that looks fine may actually crash at runtime. Surprise!

以下なんかをみていると特に、Elixirでいう case ... do ... end の形を思い出します。

締め

1日程度触った感じですが、Elm、なかなかElixirやSwift書いている人にすると比較的学びやすいJS実装な気がします。今後使い続けるかは別にして、関数型言語の領域を学ぶというところでは情報も多すぎず程よいかもしれません。

[Appium]preventWDAAttachments for XCUITest strategy

Appium1.6.2から、 preventWDAAttachments というパラメータが付与されました。

これは、WebDriverAgentを動作させるときにXcodeのDerivedDataに多くの不要なファイルを書き込むことを抑制するために、そのディレクトリの権限を読み込み専用(555)に変更させるものみたいです。

defaultはtrueのようですね。

https://github.com/appium/appium-xcuitest-driver/blob/0c36c7659373c1c82a1411e50fa2503920909624/lib/desired-caps.js#L45

ただ、これはXcodeの権限設定を一部変更することになるので、capsには明記しておいたほうが良さそう。

[Elixir in Action]No technology is a silver bullet.

ここ最近、ざっとGetting startedやらexercism.io、PhoenixとElixirやその周辺ライブラリを触って、ちょっとしたライブラリも作って。Phoenix使って簡単なWebアプリ作って、というところをしました。

そんな折、Elixir in Actionを読み始めました。他のElixirの本も読もうと思うのですが、Actionシリーズなのでまずはこちらから読んでみようかな、と思いまして。

この書籍は言語自体の話から、Elixirのプラットフォームの話へと進んでいきます。多分、他の書籍も同じ。ただ、この書籍の著者はErlangを専門とする人のようで、RubyからElixirに寄った人たちとは異なった視点からの意見を望めます。良いですね。

Erlang

Erlangの話から。Erlangはfault tolerance、Scalability、Distribution、Responsiveness、Live updateを重視した、高い可用性(high availability)を目指した言語です。それらを実現するための核が、concurrency。BEAM VM上に存在するプロセスとプロセス間通信を構築するなどでconcurrencyを核に添えた開発環境を構築できる、と。

WhatsAppsなんかはかなり有名ですね。私もErlangは少し触れたことがあります。ただ、言語の記述には慣れなかった…

Elixir

Elixirは、Erlangの記述を単純化したり、拡張することで描き易くしたものです。一言でいうとそんな感じなのですが、そこは開発者を取り込むために必要なものです。ClojurやRubyに影響を受けているので、そちら方面の人は馴染みやすそう。

No technology is a silver bullet.

ErlangやElixirにも苦手なところがあります。この書籍では、その点も書いていて良かったです。

  1. Speed:
    • CやC++にはかないません。BEAM VMは、ハードウェア資源をめいいっぱい使うので、貧弱なハードウェアだと性能劣化が発生します。これは多くのプロセスを立ち上げ、処理を行っていくという特徴を持つから。なので、CPUの拘束が長い処理を行う場合、別の言語を選んだほうが良いでしょう。
  2. Ecosystem: 単純に、まだ、エコシステムとしては小さい。

まだまだ先は長いですが、ちょっとづつ読んでいこう。

こういうfault toleranceなシステムや分散システムを前提としたシステムのテスト、品質(Quality)をどうやって評価するか、それをどうやって安定した開発に繋げることができるか?といったところ、テストエンジニアとして技術的な視点では非常に挑戦的で面白さを感じますね。

ただ、それらの先にユーザがいなければ自己満足な世界で終わるのでそこは忘れてはダメですね。