Author Archives: KazuCocoa

『dRubyによる分散・Webプログラミング』を読んで分散処理を思い出す

dRubyによる分散・Webプログラミングを読みました。 この書籍ではdRubyのモジュール解説だけでなく、処理の中心となる考え方や参照渡しと値渡し、マルチスレッド、排他制御、Webアプリケーション実装など含めて、分散処理を考える上で基本的な考え方を網羅しています。dRubyは、 require “drb/drb” すると得られるRubyにおける分散処理環境を提供する機構です。 分散処理を考えるとき、遠隔で処理を行うための規格としてRPC(Remote Procedure Call)なんかがあります。それらはクライアント/サーバのスタブを提供し、ネットワーク越しの分散処理環境の構築を支援します。一方、dRubyでは、オブジェクト同士の通信の概念をネットワーク越しにまで拡張して、分散処理機構を構築します。Pure Rubyで実装されている、というところもとても素晴らしいですね。 私はここ半年いかないくらいの間、Erlang/Elixirをざっと学んでいました。なので、分散オブジェクト同士のコミュニケーションの取り方やLindaのRuby版であるRindaのTupleSpaceなんかの役割など、プロセス間のメッセージパッシングやETSを対比として理解を深めることができました。 この書籍、2005年の段階で関さんによって書かれていることがすごいですね。(その頃はまだ私は大学に入りたてでコンピュターにさえ慣れていなかったな…)More

[Elixir]1worker、1portでリクエストを待ってHTTPのリクエストをProxyする

HerokuがErlang製のHTTP Proxyを公開しましたね。少し中身見てみたのですが、彼らもForkしたCowboyを使ってProxyを構築しているっぽい。他にも軽く読んでは見たのですが、Erlangも多少読めるようになっててびっくり。 https://github.com/heroku/vegur 話は少し変わって、[Elixir]Elixirで簡単なHTTP Proxyを書いているときに出会ったエラーのメモで、Supervisorのworkerごとに異なるportを待ち受けてそれぞれが独立したproxyとして動作する機構を書いてたのですが、PIDの衝突の発生で思った感じでできてませんでした。 でも、考えるほどにやっぱりできるはずだよなーと思いもう少しやってみました。それと、先ほどのVegurでもやっぱり異なるPortで待ち受ける処理が書いてあって、やっぱり実装間違ってるなと確信。 もう一度考え直してみると、今回は考えた通りに書いていったら期待通り動作することができました。 結局は、 Plug.Adapters.Cowboy.http に対して与えている ref の与え方が間違っていた、という情けないミスでした… リポジトリ: https://github.com/KazuCocoa/http_proxy 前回の誤り 今回 これで、例えば以下のような実装を書いたときに、Supervisorで監視される各々のWorkerが異なるProcessとPortでリクエストを待つことができるようになります。 HttpProxy.Handle のモジュールに、先ほどのCowboyの起動が実装されていることを想定しています。 修正時のコミット(ファイルの置き換えあり): https://github.com/KazuCocoa/http_proxy/commit/8b5368f15a2e149ac7069a33379e4c190cf93374 Elixir/Erlangさわりはじめて、大学の頃もでしたが、やっぱり私は分散系に対して技術的な興味を持っているのだなーと感じました。More

[Elixir]Elixirで簡単なHTTP Proxyを書いているときに出会ったエラーのメモ

追記 2015/11/08 [Elixir]1worker、1portでリクエストを待ってHTTPのリクエストをProxyする で解消済 最近、簡単なHTTP Proxyを書いてみています。Elixir/Erlangの多プロセスで動作する点を利用して、軽量なproxyとして動作できるのかなー？というところがあってです。 https://github.com/KazuCocoa/http_proxy 以下のような感じでportを指定したら、そのportに対してどんなパスでアクセスしたかで接続先を制御できる感じにしています。 Plug や Cowboy を結局は使っています。Supervisorのworkerとしてプロセスは起動するようにもしています。 この動作確認の中で、ElixirのSupervisorで複数のPlugを持つ同一モジュールを動かそうとしたらPIDの競合でエラーがでたのでメモ。少し調べてみると、それはPlugが Plug.Adapters.Cowboy.httpや Plug.Adapters.Cowboy.https をSupervisorで起動するときに :name で __MODULE__ を指定しているのが原因な気がしています。 というのも、例えばSupervisorで呼ばれたときにまず起動するここらへんで使われる、start_link で最初に呼ばれるところで ref: を与えたり、 workerで与える :id を変えても変化なかったためです。ここな感じ。More

『21世紀のビジネスにデザイン思考が必要な理由』を読んだ

『21世紀のビジネスにデザイン思考が必要な理由』を読みました。誰かから勧められたからか少し記憶に無いのですが、Kindleにあったので、くらいがきっかけです。 デザイン思考系は幾つか過去に読んだことあるのですが、過去読んだものは比較的具体的な技法といった話を扱っていました。それに対して、この本はそのデザイン思考に対する入口的なものだと思います。 別の書籍からの影響も含め、新しいことを生み出す感性を6つに区分し、 機能だけでなくデザイン 議論よりも物語 個別よりも全体の調和 論理ではなく共感 まじめだけでなく遊び心 モノよりも意義 を提示していたりします。比較ベースで、xxxよりもyyyという形で説明している姿はAgile Manifestoをそのまま思い浮かべさせられます。 この他に関しては、いわゆる問題解決型の考え方を主にデザインする人の視点で述べています。サービス開発を経験している方だと、多くは普段の開発そのままを示していると思います。More

[Elixir]GenServerのcallとhandle_callにおける:nameによる指定

GenServer.start_link __MODULE__, default, [name: __MODULE__] で name を指定することの必要性に関してメモ。 以下の通り、Sample.neko を読んだ時、 __MODULE__ にメッセージが送られてGenServerのコールバックであるhandle_call にメッセージが送られる。そのパターンマッチで処理される handle_call が決定、実際にプロセスで処理される。という一連の処理を作るために、 start_link では名前をちゃんと与えることが必要。そうでなければ、process idを直接指定しなくてはいけない。(それはあまり現実的ではない..) 関連した修正はこちら https://github.com/KazuCocoa/my_bot_ex/commit/b9be93de02e47b97a2a2e93dcbb46104ddb47004More

[iOS][Swift]XCTestでパフォーマンスを計測したり、処理をwaitする

XCUITestでテストを行う時、アニメーションの都合で処理をまったり、突然の性能劣化がないか、ということを計測することの重要性が高くなります。 そこで、XCTestを使ってそれらを実現する方法を最近調べたのでメモ。 処理性能を計測する ある範囲の処理の処理性能を計測したい場合があります。 XCTestでは、以下の通り measureMetrics を使って、与えたブロック内の処理を計測、一定の性能劣化があった場合にfailしてくれる機能があります。 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 Show hidden characters func testShouldDisplayAlertWithText(){ // run 10 times and…More

[iOS]XCUITestを既存サンプルコードに適用してみた

別用もあって、XCUITestをちゃんと触ってみました。 XCUITestに対して多くのプロジェクトで問題になるのって、多分既存コードに組み込むことができるか？だと思うのですよね。(私もそうです) なので、iOS6.0をdeploy targetにしているAppiumのサンプルコードを引っ張ってきて、それを7.0にあげた状態で動くか、というところから確認してみました。結果的に、アプリは7.0を保ちつつ、XCUITestはiOS9.0を対象にしてテストを回す、ということができました。Xcode8頃から怪しくなりそうな気がしているInstruments越しのUIAutomationを見ると、できるところからiOS9系だけでもXCUITestを視野に入れ始めたほうがよさそうですね。 修正したコードは以下に入れています。 git clone して、iOS9シミュレータをターゲットに設定して command + u で実行できます。 https://github.com/KazuCocoa/XCUITestExample/tree/master やったことは、 サンプルコードを取得する iOS7.0をミニマムにする XCUItestのターゲットを追加する 幾つかのテストコード書く(ついでに、accessibility付与したり、要素の結合したり) https://github.com/KazuCocoa/XCUITestExample/blob/master/TestAppUITests/TestAppUITests.swift accessibilityIdentifier や title、private methodへの切り出し くらいです。 そのほか Storyboardから、 accessibilityIdentifier を設定できるようになっていました。Storyboard中心になるのは、実装とUIを切り分けできているので良いのではないかなと思います。 ただ、動的に変化する要素に対してaccessibilityIdentifierを付与する、というのはやっぱりコード読み書き必要だし、テストコードはやっぱりSwift/Objective-Cになるだろうので、中身見ることができる人は必要、というのは変わらなくて良いのですけどね。 XCWaitCompletionHandler がwaitとしてつかえそうだったりと、Instruments越しのUIAutomationよりは、個人的に安定した並列実行とかもできるのでは？と少し期待。 これの成果物、Amazon Device Farmなんかにも適用できるかなー。 This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review,…More

[Android]Amazon Device FarmをInstrumentsのテスト/APIからの操作で試してみた

Amazon Device Farmに関して、実際に色々触ってみての感想。 既存のinstrumentsのテストやEspressoを実施、はたまたAPI経由で操作した時の感想です。(APIはできる、ところまで確認したというのが正しいですが。時間あったらAPIは試す。) 即時性の求められるテスト実行には少し向かないけれど、案外段階かもしれない。 Androidのinstrumentsによるテストの実施 JUni4の記述を自動でテスト対象と認識させるには以下が必要。JUnit4ベースになって test の接頭辞をつけなくなって良かったのだけれど、ここに来て必要になるとは… テストクラス名に*Testと、Testの接尾辞をつける テストクラス内のテストケース名にtest*と接頭辞をつける 他は特に問題なさそう。 @RunWith(Theories.class) と @DataPoints におけるパラメータ化テストだったり、 @Before/@Afterはともにできました。また、Espressoのテストも無事実施することができました。 この28件の成功の中には、EspressoやParametarized Testも含まれている状態です。 参考: https://github.com/awslabs/aws-device-farm-sample-app-for-android/issues/5 https://forums.aws.amazon.com/thread.jspa?threadID=211353&tstart=0&messageID=669228#669228 アップデートするAPKの生成 $ ./gradlew assembleDebug $ ./gradlew assembleDebugAndroidTest APIによるアップデート、テスト実施の自動化 AmazonのRubyライブラリにすでに統合されていた。 https://github.com/aws/aws-sdk-ruby なので、特に問題なくテスト対象のapkをアップロード、instrumentsのテストを実施、結果を得るという一連の流れをRubyスクリプトでサクッと実現できそうでした。 ドキュメントはこちら。中身見ると、JSONで設定ファイル作れば十分な感じがしますね。 http://docs.aws.amazon.com/sdkforruby/api/Aws/DeviceFarm/Client.html 重要なところは、 #create_upload(options = {}) ここで、テストのconfiguration設定時には type: に INSTRUMENTATION_TEST_PACKAGE を指定する #schedule_run(options = {}) 実際にテストを実施する ほか、いくつか端末の設定も含まれているのでいくつか通信が必要そう。 締め 色々段階っぽいですが、現状の結論としては以下ぽい。 (私のコメント箇所は、最終的にクラス名にTest加えたり、テスト対象だけtestつけるとかしたら解決できました。) @Kazu_cocoa 手元でも動かせるテストをリモートでも自然に動かせるみたいのじゃないとテスト書くのやってらんないし、現状特定用途向けにしか使えなそうっすねえ。デベロップメントテスト走らせるには厳しい —…More