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

食の世界地図を読んだ。

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

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

[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)をどうやって評価するか、それをどうやって安定した開発に繋げることができるか?といったところ、テストエンジニアとして技術的な視点では非常に挑戦的で面白さを感じますね。

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

今月のobjc.ioはiOS at Scaleだった

今月のobjc.ioでは、iOS at Scaleということで、iOS開発においてスケールに対する話が中心でした。

http://www.objc.io/issue-22/

モバイルアプリでサービスを提供する企業も、サービスの拡大に伴ってアプリも肥大化してきて、ある程度プロセスの整備も必要になってきたような。読んでみると、だいたいは抱えている問題は同じ感じ。その解決方法も似たようなもの。だけれど、ここに書いているように抽象化したところを除けばその組織ごとの事情によって色々最適化されているのでしょうね。

理想と現実のギャップを埋めるために問題を解決していくエンジニアリングを繰り返して、より無理のない安定した開発を目指したいところですね。

Why The Facebook App is Rated Below 2 Starsを読んだ

最近みたこの記事から、モバイルアプリ開発に関して学ぶことができた気がするので、メモ。
これはメモなので、興味のある方は本文読んだ方が良いです…


最近のiOSのFacebookアプリは、各国で以下のように平均で低いレートを得ています。この記事では、その原因を分析していました。

Breakdown of Issues Reported

以下は、1月1日〜1月15日の間の、USにおけるレビューの内容を集計したものです。

これを見ると、マイナス要因になるレビューは

  • アプリのクラッシュ
  • コア機能

の2つが大きいそう。他にも要因も書かれていましたが、大きくはこの2つのようですね。

リリースサイクルとQAチーム

FacebookのiOSチームは、2週間のリリース間隔を持っているようです。また、1週間ごとのスプリントで開発サイクルを継続しているよう。

このYouTube記事によると、FacebookはQA期間を設けていますが、公式なQAチームは存在しないらしいです。その代わり、テストベースの開発に注力しているようです。

“As you may know, Facebook does not have big QA teams…we believe that developers are responsible for their own code, and they’re supposed to write the tests to do that.”- Quote from Alan Cannistraro

実施しているテストツールの一部

以下のようなテストツールを使っているそうです。

  • Snapshot unit test
    • ios-snapshot-testingのやつですね。GitHubで公開されています。
  • Testing by employee base
    • 開発者ベースの動作確認です
  • An Internal Settings development Dashboard
    • 開発者ベースのテストで、パラメータかえたり、イベントを送ったりしている?
  • Watchdog Timer
    • メインスレッドに対してx秒毎にpingを送って、不意なタイミングでスレッッドが予期しないクラッシュしないか見るとかでしょうか
  • Shake Report
    • Shakeすることで、開発中のアプリの画面キャプチャなどを自動で送ることができる機能

Facebookチームの問題

テストベースで開発していますが、例えば開発者は主に自分たちの開発領域にしか目が届かず、全体としての品質に対して責任を持ったりするところがいないことがよくないとかも書いています。

また、具体的なFacebookチームの問題点として以下のようなものをあげています。

  • Facebookは、2週間という短いリリースサイクルを行うための十分なツールやプロセスをまだ持っていない
  • 2週間のサイクルは、十分な品質と多くの機能を配信するには短すぎる

記事の締め

今のままだと、Facebookはモバイルアプリを主としたマーケットにおいて、アプリの評価を回復していくことは難しそう。そうなると、モバイルマーケットでは厳しくなるでしょう、とまとめられていました。

感想

Facebookのリリースサイクルなどはいろいろ参考になりますが、彼らの規模、機能製、サービスの内容などを見るといろいろ困難が多いことが容易に理解できます。サービスを提供するために早い開発サイクルを回したいことも理解できます。
その中で、より安定した開発プロセスを回し、組織としてサービスの成長に注力できるように開発サイクルを安定させることは、まだまだ考えて挑戦すべき領域のようですね。

ところで、若干蛇足ですが、QAってどこから関わると良い?と聞かれることがあります。理想をいうなら、プロジェクトの”初めから”です。少なくとも、開発者が関わるのと同じくらいのタイミングで関わることが、理想的ではあります。

というのも、QAの多くはプロダクトを横断的に関わることが多いので、広い視野を持っていることが期待できることが多いと思います。また、主に関わっている製品に関しては、開発者まではいかなくとも、多少なりとも技術的な知見を有していることが期待できます。その場合、不具合作り込みに一番つながる、考慮漏れを防ぐことができる、という意味合いからも、早い段階から入る方が良いと、私は思っています。

あとは、単純にスキルセットが分散されて、チームとして良い感じで協力できそう、というものあります。

これを読んだ時、合わせてこの記事も読みました。
GoogleによるAndroidのパフォーマンスについて
広告にかかる通信などのコスト、バッテリーに大きくのしかかるのですね。なるほど。。。

Selenium/Appium Advent Calendar 2014の23日目の記事に載せた

Appiumを使ってiOS/Androidの要素を取得する方法の数々をポスト。

iOS/Androidにおける、要素の取得方法で普段使っていることをまとめたもの。


話は関係ないですが、Circle CI、Travis CI、Hosted CIと、少しづつiOS/AndroidがビルドできるCIサービスが増えてきましたね。

Enterprise用途でも使えそうなものが散見されはじめているところも、これからに期待。