『複雑さとともに暮らす』、を読んで

人間中心設計で有名なドナルド・ノーマン氏の書籍です。 複雑さと共に暮らす―デザインの挑戦 過去、同氏の書籍では誰のためのデザイン？を読んだことがあります。 こちら 人間中心設計であったり、さよなら、インターフェースであったりと、私は定期的に課題解決のためのデザインに関する書籍を読んでいるぽい。こう言う書籍、頭の運動兼ねて適度に読むと考え方の体操になって良いですよね。現実世界でQualityと向き合うときにこの考えに触れることは避けることが難しいと考えています。 簡単だからと言って機能が少ないとは限らない “簡単”は”使いやすい”、”機能が少ない”は”能力がある” “複雑”と”迷う”はイコールではない 社会的signifireは社会的な約束事 良いシステムデザインは、人間中心な社交的システム などなど。 こう言う系統の物は記載されていることを知るよりも、それによって何か考え直したり考えるきっかけになることが大事だなーと感じます。 時折、さっと読み返していきたい。 そういえば、複雑さに対処するための心構えが書いていました。こう見ると、個人的にはエンジニアが普段やっているようなことだなーと感じました。この考え方。 受け入れよ(複雑なものである) 分割統治せよ(細かく砕いて、それを組み立てる) just in timeで学べ(必要に応じて) 理解せよ、記憶はするな(基礎理解が大事で応用が利く) 他の人をよくみよ 実世界の知識を使う: signifier, affordance, limitation 実世界の知識を使う: sign, label, marker 実世界の知識を使う: list(checklistなど)More

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

過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。 対象のproject: https://github.com/KazuCocoa/MyGithubSearch 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167 幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。 EarlGreyについて EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。 リポジトリはこちら。 https://github.com/google/EarlGrey EarlGrey自体の説明はあるのでここでは書きません。 セットアップ、導入 https://github.com/google/EarlGrey/blob/master/docs/install-and-run.md Swiftサンプル https://github.com/google/EarlGrey/blob/master/Demo/EarlGreyExample/EarlGreyExampleSwiftTests/EarlGrey.swift 何か困った時 使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。 APIドキュメント https://github.com/google/EarlGrey/blob/1.0.0/docs/api.md 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を有効にしてそれを使うと良いです…More

Reading “Raft” – consensus algorithm

Raftという、合意アルゴリズムが存在する。これは、多数決を元にした多数派の意見を決定するためのアルゴリズムで、分散環境下における合意形成でも使える。最近、分散系の幾つかのWebサイトを眺めていると見つけた。 私は、こういう系統の技術分野は大学院の頃にByzantine General Problemを扱ってから比較的興味を持っている。 実際のツールだと、CoreOSのetcdやhashicopeのconsulなんかで使われているみたい。 Raft自体に関係するところは以下。 https://raft.github.io/ http://thesecretlivesofdata.com/raft/ 幾つかの言語で実装されているみたい。etcdではgolangぽい。 Erlang実装の1つ https://github.com/dreyk/zraft_lib Elixir実装の1つ。 https://github.com/mururu/rafute 幾つかRaftの論文のreferencesを見てみましたが、Byzantine faultなんかはやぱり参考にされていました。2014年が論文としては初出？ LESLIE LAMPORT氏によるByzantine General Problemの問題は、懐かしさがある(大学院の頃によく読んでいた)。最近はご無沙汰だけれど、技術だけの話でいうとこれ系が関わる仕事はしてみたいな。 参考 http://blog.obfuscatism.net/2014/12/01/raft.html http://kumagi.hatenablog.com/entry/distributed_system_taxonomy_part4More

Reading “Mobile Application Penetration Testing” and dive into it

『 Mobile Application Penetration Testing 』 を読みました。 セキュリティ系の話でこのようにまとまったものはなかなかないので、周辺の知見を集めるという意味も込めて。あとはペネトレーションテストに焦点を当てた書籍自体をあまり見ないので、純粋にその方面への興味からも。 この書籍は、言うなら現状のiOS/Androidに対して実装するなにがしかのソフトウェアに対して、どのようなセキュリティリスクが存在するか、をいろいろとまとめているものです。また、実際に攻撃可能なサンプルも用意しており、それらを試すことも可能です。 The key challenges for mobile app モバイルアプリのセキュリティという話において、以下のように大まかに重要な領域を分けて話をしていました。 Network Layer Hardware Layer Operating system Layer Application Layer この書籍は、これらに対してちゃんと脅威モデルを作成し、それらへのリスク判断や対処を行うための参考になるように作られていました。区分整理や実演など含めて多くに取り掛かっています。 methodology for Mobile applications ペネトレーションテストなどの取り組みは、Discovery、Analysis、Exploitation、Reportingの4つな手順から形作られます。OSSやプラットフォーム理解、サーバとクライアントのことを考えながら重要な情報を探し出す。リバースエンジニアリングだったり、ネットワークの状態といったことや静的ツールといったものを使い解析を進めます。そこから実行やレポートへ落とし込むことになります。このような一連の流れをベースに、実際にどのような点を考慮すべきか、というところに焦点を当てて作業を進めることになります。 mobile top 10 risk OWASPは、2013年にモバイルアプリのtop 10のリスクをあげました。 Weak Server Side Controls Insecure Data Storage Insufficient Transport Layer Protection Unintended Data Leakage Poor Authorization and Authentication…More

[Elixir]concurrent integration test with Hound and handle it with tag

雑にしか書きませんが、Phoenixのcontrollerのテストでは、あるURLへの操作に対する結果のチェックにはstatus codeが何か、そのtitle要素は何かといった簡単なHTML要素をみます。そこは静的な要素をチェックできるのですが、画面の遷移が絡んでくるとintegration testと呼ばれる段階のテストを用意する必要があります。 Elixirでは、その手のツールに以下の2つがあります。 Hound Wallaby Wallabyのほうが後発です。これはconcurrentなテストを主眼に開発されているようです。ただ、対応ブラウザがPhantomJSだけだったので、私はHoundを選びました。 そして、concurrent integration testを行うにはphoenix_ecto3.0 + Ecto 2.0を使う必要があります。これは、Ecto2.0から入ったownership制のsandbox環境を使い、concurrentなテストを実行する必要があるためです。 ※Ectoのこのownership制の話とか気になる人はこちらを読むと良いと思います。コード 設定 以下の設定説明を参考にすると、基本的なところは完了。サクッと実行できます。なのでここではリンクだけ… https://github.com/phoenixframework/phoenix_ecto#concurrent-acceptance-tests https://github.com/phoenixframework/phoenix_ecto#hound 私はfirefoxとWebDriverのstandaloneを使ってサクッと実行しました。 WebDriverはこちらからダウンドード可能です=> https://selenium-release.storage.googleapis.com/index.html tips 通常、この手のintegration testはブラウザを使うのでテスト実行が遅かったり不安定だったりします。そのため、その他のmodelやcontrollerのテストとは別に制御できるようにして、不要なときはskipするなりしたいです。 ここでは、tagを使って制御しましょう。ただ、よくあるメソッドごとに @tag をつけるのでは煩雑になるいっぽうなので、 integration_case.ex なんかを作って、それを読み込んだ全てのモジュールに対して勝手にtagがつくようなやり方です。 tagを付与する support/integration_case.ex にtagを設定する 以下のようにヘルパーを作ってあげると、 use MyApp.IntegrationCase したモジュールは自動的に @moduletag :integration のtagが付与されます。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than…More

とてか04で多くのものを拾ってきた

とてか04とは 『とちぎテストの会議04』が正式名称。 toRubyを主催している方々が、主に”テスト”に関わる何かを主において開くイベントです。 その中で、今回は以下の通り「つくるいとなむ」を主なタイトルとして開かれました。 http://d.hatena.ne.jp/tochigitestnokaigi/20160423 私 私は以下のようにLTの1番目として発表いたしました。 これ自体は私の普段の学び方だったり、その中で特に業務に活かすために特に疑問に感じていたことをお話し致しました。 「チョットデキル人に訊け！」ででた”テストをうまくなるには？” こちら、何が自分、ひいては周りの向上を誘うか、ですよね。私も考えてみたのですが、やっぱり以下のようにやりたいことベースでいろいろ学ぶなーと感じました。それ以外だと、業務上だったり一時の知的好奇心から、というのはちらほら。 うまくなるには、みたいな話、私なりに考えてみると結局はやりたいことあるからベースが一番強そうです。 #toteka — KazuCocoa (@Kazu_cocoa) April 25, 2016 これ以外だと、何か興味を持っていることの周辺でテストに絡めて学ぶ、というのが面白いのでないですかね。 拾ってきたもの 多くの方々とのつながり。 とてか03で初めて足を運んだとてか。そこから1年後の2回目。前回よりもいろいろな人と話をしましたし、つながりもできました。これは私にとってとても良いつながりだと感じます。ありがとうございました。More

[Elixir]Ecto.RepoのRepository Patternを見る

Mediumでたまたま Repository Pattern を見たこともあって、 Ecto.Repo を見てみました。こういうまとまっているフレームワーク見ると、手軽なデザインパターンの理解や頭の整理にもなりますよね。 Ecto.Query付近は随分前にざっと見ているので、今回は別。 [Elixir]EctoのQueryを少し読み解く ~ コードに前提条件が書かれるので読み解きやすいですね ~ Ecto 2.0から、 Ecto.Repo.first とかもdeprecatedになったので、その対応をついでにメモ。 以下の User は、 Ecto.scheme によって定義されたmodelです。それに対して、1件のemailに合致するデータを引っ張ってくるという処理です。 この Repo.first がdeprecatedなので、それをQueryを使って書き直すと以下のように書くことができます。 この時、 Ecto.Query.first の結果は以下のようになります。 ここは、実際にSQLを出す前のQueryを構築するところです。この Repo.one が実施されると、SQLが発行されてその結果がmodelの結果として得られます。以下は Repo.one まで行われた結果です。 Ecto.Query.first ではリクエストしたいSQLの構築、 Repo.one で実行と、クエリ構築とその実行が分離されていますね。 変更したdiffを合わせて置いておきます。 https://github.com/KazuCocoa/web_qa_vote/commit/4a0242455fb3b9c15d5c68d5e8e78336a2474b54More

[Elixir]マクロ defptとdefp、def

友人が作成していた https://github.com/skirino/croma に、 Mix.env の値によってコンパイル時に def として解釈するか、 defp として解釈するマクロがあります。 その使われ方が面白かったのでメモ。 その箇所だけ切り出して、参照値を環境変数のMIX_ENVにしたものが以下の Functions モジュールです。それをimportする Defpt モジュール、利用する Alexa と Alexaを呼び出す Me 。この Alexa で定義している defpt が今回の対象です。 これを見ると、 Me の中の Alexa.hello が、MIX_ENV == “test” の時はアクセス可能だけれど、それ以外ではundefined function errorになることがわかります。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review,…More

[Elixir]withとelseとguardsと。

Elixir 1.3では、 with に対して else や guards を使えるということで、少し試してみました。1.3の時と、1.2.4の時で無理やり書いた時。 http://tuvistavie.com/tokyo.ex 簡単な、 %{width: 10, height: 20} から値を取得して、それに対して幾つかのエラーケースを実践するという内容です。 1.3 さっとまとまる。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters…More