[Elixir][Swift]ElixirやSwiftのprotocolなどの話

たまたま見つけて。 Comparing protocols and extensions in Swift and Elixir http://blog.plataformatec.com.br/2014/06/comparing-protocols-and-extensions-in-swift-and-elixir/ ElixirはClojureに影響されているのですね。protocol周辺の使い道。 パッと、 defimpl の対象となるタイプを思い出せなかったので以下にURLを一応。 http://elixir-lang.org/docs/stable/elixir/Kernel.html#defprotocol/2 こんな感じ。 defimpl の 第一引数のタイプ によって、どのタイプに対する実装かを示しています。 Swiftは、記事のものは古いので省略。も少しあとで。More

[Java]最大値の反転で負の数値になってた(初歩的なミス…)

Javaの、基本的なところで見逃してしまった不具合を、自戒を込めてメモ… キャストの順序により、補数によって負の数値として扱われていたのか… long で宣言されていた time を計算で使っているので、括弧内の計算も long で計算されるとなんか脳内変換していた…テストする人として、見逃してはいけないような初歩的なミスだ… ※DateUtils使えば、とかの話は置いておいて… 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 import java.lang.Long; import java.lang.System; import…More

[Elixir]Post app reviews, get with simple_app_reporter_ex, to Slack

I implemented simple posting app reviews to slack with Elixir-Slack(version 0.2.0) and Reporter(version 0.2.5). Base implementation to handle post to slack with Elixir-Slack 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.…More

『Programming Phoenix』を読んでみた（まだドラフト版）

ElixirによるRoR実装と表現される、Phoenix Frameworkの作者による書籍『Programming Phoenix』を読んでみました。今はドラフト版ですが、こういうフレームワークの基本的な思想とか好きなのと、PhoenixはElixirのmacroを駆使しているという話をみて、気になって買って読んでみました。(Elixir、macroがほぼそのままLips形式の記述なのですが、そこも著者は気に入っているそう。) 以下ではElixir 1.1.0、Phoenix 1.0.3を対象としてます。 内容としては、簡単なサンプルを作りながらPhoenixの話、Ecto、Plug.Conn、Ecto.QueryなどのElixirの基礎要素の話がありました。テストの話なんかはまだ書きかけ。Phoenixの話ばかりと思ってたら、結構Elixirの周辺の機構の主要な要素をかいつまんでいて、良い意味でびっくりでした。 個人的には、 https://github.com/KazuCocoa/web_qa_vote で作っていたことがこの書籍読んだあとだったらもっとサクッとできたのかな、という感じでした。ある程度Elixirの文法わかって、簡単なWebアプリ作ったことがある人が、中身を理解するという段階で有用な書籍っぽい。 技術的なところは置いておいて、個人的に面白かったのは、所々でてくる、著者らによるコラムです。なんでこうしたか？というところに、どのような意図があってこうした、というのが散らばってます。 例えば、Phoenixの内部処理ではAtom keyを使うけれど、外部(開発者)はString keyでパラメータを書く。これは、データの安全性への考慮を含めているから、というような。Phonenixの web ディレクトリと lib ディレクトリの役割の違いなど。あと、HTMLのtemplateの処理がPhoenixではなぜ早いか？というところに対しては、Phonenixは、templateをStringではなくlinked listsとして扱っているから、そのぶん性能的な改善が見られる、らしい。 以下、書籍のまとめとかではないけれど、個人的に派生して読んだり学んだことのメモ。 Phoenixのテンプレート的な話 Viewを生成するとき、以下の Phoneix.HTML.safe_to_string の関数を通して、 :safe 要素を持つTupleでViewのhtmlを表現したりしている。 https://github.com/phoenixframework/phoenix_html/blob/master/lib/phoenix_html.ex#L156 Dive to logic of authorization 認証機構の実装の話も扱っていたので、ついでにGuardianの中身も覗いてみました。結構似たことしているので、初見では読み悩んでいた箇所もスラスラ読めるようになっててびっくり。 例えば、sign_inした状態のsessionを作り出すときの話。Guardianを使う場合、以下のような処理を書いたりします。 この中で、 Guardian.Plug.sign_in/4 を覗いてみると以下のような処理をしています。 guardian/lib/guardian/plug.ex この中でパイプでつながっている set_* 系のものを見ていると、 Plug.Conn.* のPlugの機構の中で put_session とかしてて、いろいろ conn に Map.put して情報を付与していることがわかります。 つまるとこ、Guardianは conn の構造体にあるassignsやstateなんかのキーに値を追加していっているのですね。なるほど。ちなみに、 put_session は、 Plug.ConnのprivateのMapに独自の情報を追加していくのですね。…More

駆け足でテストコードのプラクティスを学べる『実践JUnit』を読んだ

いざアサートせよ 緑の光あれ 我ら Javaの騎士 少し前に『実践JUnit』の書籍が発売されました。 対象とする読者に書かれているよう、ユニットテストの記述に慣れていない人を対象にしているものです。ツールの詳細などにはあまり踏み込みませんが、 どのようなテストが良いとされるのか というプラクティスや考え方がまとまっています。 ユニットテストフレームワークは随分使われてきました。その中で蓄積されたプラクティスを知って取り組むのと、知らずに取り組むのでは考え方の洗練されかたに差がでますよね。きっと。 この考え方は開発者テストと言われるユニットテスト以外にも、統合であったりシステムであったり、様々なスコープのテストコードを考える上でも共通して使えるものです。なので、 具体的なツールはある程度知っているけれど、どのような粒度、もしくは内容を意識してテストコード書けば良いか、そもそもの指標もわからない という人はかなり適したものな気がします。 私個人は、どのようなテストが良いのか？といったポイントは見聞きしたことがあるものでした。ただ、JUnit4 + Hamcrestの組み合わせのフレームワークの使い方には疎かったので、ツール自体は知っていましたがそれらを使ったフレームワークの遷移が面白かったです。他、テストのリファクタリングの テストの臭い は面白かったです。TDDであったり、 活きたドキュメントとしてのテストコード まで言及されていたのはさすがでした。 いくつかかいつまんで… 良いテスト FIRST Fast Isolate Repeatable Self-Validating Timely テスト対象 Right-BICEP Right Boundary Inverse Cross-check Error Performance 境界条件 CORRECT Conformance Ordering Range Reference Existence Cardinality Time テストの臭い 不具合ありそうなコードの臭いみたいなのと同じで、よくなさそうなテストコードの臭いです。 不必要なコード アブストラクションの欠如 無関係な情報 肥大化したコンストラクタ 複数のアサーション 不必要な詳細さ 誤解を招く構成 暗黙の位置付け ここら辺で言われているのはテストコードに限った話ではないですね。…More

『TPI NEXT』を読んで(テスト)プロセス改善を考える

TPI NEXTは、テストプロセス改善に関する書籍です。プロセス改善という話では、CMMI、PSP、TSP、TPI、TMMiといったものを耳にします。中でも、TPI系は現場主導的な、ボトムアップ的な立ち位置から集められたノウハウが蓄えられています。私はPDFを購入して読みました。 読み始めは、 http://nagasaki-it-engineers.connpass.com/event/20219/ の勉強会に参加してからでした。久しぶりにテスト界隈の本流に浸かりました。 テストプロセス改善ということなので独立したテストチームの話が中心かと思っていました。が、思いの外反復型とアジャイル開発の形とテストの関係にも言及があったところがよかったです。 プロセス改善自体はテストに関わらずソフトウェア開発の中で活かせそうなものはありました。また、経験と照らし合わせてそうですよねというものも多かったですが、主な対象は納品のある受託開発という感じでした。 プロセス改善ってあまり学ばれないのですが、少しでも学んでいる人がいると明らかな失敗に対して予防策はれたりしてよいですよね。テストエンジニアとして学んでいくと、ここら辺も知見を有する領域としてははずせないです。陰ながら、失敗に進みそうになったらそれを避けるように動くとか、そういう立ち回りは必要ですもんね。 少数で完結するアプリを開発するという領域を超えたところから、なんだかんだで必要になる知見ですよね。プロセス改善だけ行き過ぎた開発は形骸化が大きいのは言わずもがな、ですが。 経験だけを信じる人も多いかもしれませんが、こういう大多数の人たちのノウハウがまとめられたものって、大事ですよね。自分が人とは違った特別な存在でない限り、なんらかの気づきを得られる可能性がありますし。そこをどう最適化するか、がそれを活用する人のスキル次第、でしょうか。 ちなみに、これらの活動の核は やる気のある人個人を集めてプロジェクトを構築すること。必要な環境と支援を与え、仕事を任せること。 でした。最近のXPの風潮など含め、結局はソフトウェア開発は対人による作業なのでここははずせないですよね。 サービス業に身を置くとそぐわないことも多いですが、良いところは影響を受けて、サービス全体の品質が向上するように影で動き回りたい。More

[Elixir]power_assert_exをex_parameterizedと組み合わせて使ってみた

Power AssertのElixir版を、 @ma2ge さんが作成されていたので、ex_parameterizedと合わせてみました。ex_parameterizedは、パラメータ化テストの記述を支援する、簡単なマクロです。 power_assert_ex https://github.com/ma2gedev/power_assert_ex ex_parametarized https://github.com/KazuCocoa/ex_parameterized やることは簡単。単に、 use ExUnit.Case を use PowerAssert に置き換えるだけでした。 ex_parameterized自体、単に test マクロを内部では使っているだけなので、特に変なAST操作は行っていません。なので、問題なく表示されました。すごい。 以下は、ex_parameterizedのテストをわざと失敗させた時の出力結果です。 まだ色々と制限もありますし、ExUnitの結果自体そんなに読みにくいテスト結果なわけではありません。ただ、なんだかんだでテスト結果を観察することが楽になりますので、良いなーと思いました。More

[Elixir]Plugを使ってたときにPhoenixの1request-1processが気になったので追ってみた

ちょっとしたHTTPの処理を受けるサーバを Plug を使って実装してようとしたら、 Plug.Adapters.Cowboy.child_spec() をすることになりました。また、trotも少し処理を追ってみると同様なところに行き着く。 ふと作業している途中で、Phoenixだと、1 request – 1 processとなるendpointの処理は結局はどこが処理してそうなっているのだろう、という疑問がわいたので、 すべきことを横に置いて さかのぼってみました。 過去、似たようなところとして以下のようなものを追っていました。 [Elixir]Phoenix.Router付近やendpointを追ってみる [Elixir]PhoenixのSupervisorのstrategy 開始地点 ひとまず、雑に Plug.Adapters.Cowboy で検索してみました。これは、Elixirの機構を使っているなら、最終的に同様にPlugにいくだろう、とのことから。 すると、Plug.Adapters.Cowboy.Handler なんかが検索に引っかかります。 この中から、 Phoenix.Endpoint.CowboyHandler の child_spec の中で使われているのを見つけました。この child_spec は、Subversion Treeの中で呼ばれます。 同様に、このHandlerをみてみると、この行にて、 が呼ばれていることがわかります。つまり、Phoenixのendpointの処理は、最終的にはPlugを使い、Cowboyへと向かっているのですね。 なるほど。 Subversion Treeを遡る もう少し、今度はSubversionがどのように流れているのかを追ってみました。つまり、 Phoenix.Endpoint.CowboyHandler がSubversion Treeの中で呼ばれるところを探す、です。 検索してみると、Phoenix.Endpoint.Serverで、 として定義され、この@handler が同じファイル内の initの箇所で呼ばれています。 じゃあ、このPhoenix.Endpoint.ServerをどのSubervionが呼んでいるのか？というと、Phoenix.Endpoint.Adapterで呼ばれていました。 もう少しさかのぼると、 Phoenix.Endpoint.Adapter は Phoenix.Endpoint の def server()内で stat_linkされるようです。この server() は、同じファイルの __using__ で呼ばれているので、Phoenix.Endpoint…More

やっぱりモバイルアプリの(シナリオベースの)テストコードは1つの言語で書きたい

ruby_libのissueでとある文言を見て、そうだよなーと感じたもの。 https://github.com/appium/ruby_lib/issues/337#issuecomment-143345864 Originally we used Ruby across web/ios/android. The mobile tests weren’t stable. Now we have 3 suites in different languages. – Ruby web test suite (angular_automation) – Java Android suite (Espresso) – Objective C iOS suite (XCTest) It’s a lot of work but the tests are stable and fast. I hope the new mobile…More