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
Category Archives: books
駆け足でテストコードのプラクティスを学べる『実践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
『万人のためのデザイン』を読んだ
『万人のためのデザイン』を読みました people designが原書です。 ほぼデザインの本で、色々なデザインの引用を持ってきながら、工業デザインの進化を平均な人に向けたもの、規格外の人に向けたもの、と色々区分して紹介・説明していくという内容でした。この中で、人に合わせたものを作る、という目的のために人の理解を進めようとする話もあります。デザイン、なので、主には外見に関わるところですが。 人間工学への進展や、ユニバーサルデザイン、経済、オープンソースデザインなどの話も。 その中で、製品とユーザの関係で、初期の使い始めの頃から、だんだんと慣れて日常になるまでの興味の持ちようをグラフとして引用してたところが面白かったです。More
『さよなら、インターフェース』を読んでUXに思いを馳せる
『さよなら、インターフェース』を読みました。何かのWeb情報を見て、タイトルが気になった書籍。 おそらく原書のノリそのものだと思うのですが、訳も砕けた感じの言葉で話を進めている、トントンと内容を読むことができるものでした。また、画面全体であったり、複数の画面にまたがってUIの説明などしている箇所があり、これは書籍として手に取るほうが楽しめそうなものだと思いました。(そもそも、Kindle版は無さそうですが) この書籍自体、User Interfaceが人にどのように影響を与えるか、UXをどうするか、ということを、UI/UXとを切り離して考えるきっかけをあたえてくれるわかりやすいものだと思います。 これを読んだ後、私が属している組織が提供するサービスはNO UIの考えにどのくらい近づけるのか、何が提供できるか考えました。つまり、料理を作るに関係する試行において、いちいち検索とか、アプリ開くとか、そういうことをしなくても必要なものを機械がサポートしてくれる。そんな世界はどういうところだろう、と。 キミたちはもうひとつ、やるべきことがある。シリコンバレーの二番煎じなんかじゃなく、さらなる高みを目指せ。シャンとするんだ！ > p.54 UIとUXに対して、比喩的に以下の通り捉えていました。いわゆる、Qualityとして目指すはUXで、その手段としてのUI。広く言われている感じですね。 UIとは、ナビゲーションやエラーメッセージ、テキスト入力や領域、アニメーションなどのsignifire UXとは、人、しあわせやうれしさなどの感情、問題解決、至福など。 ほか、最近のUIとUXを類似したもの、と捉えた時の反例的な例を幾つか挙げていました。 UIをつければ良い！という、UX無視したアプリ開発 ユーザ体験と広告の、利益を得るための(分かっていての)犠牲 UIを表示するディスプレイのバックライトのγ値などと、人の知覚の関係(覚醒するとか。) 「まずは画面」から、スマホはケツポケットにしまっとけ！という考え方への転換 スマホを操作してxxできうようにする、ということは、スマホを取り出して、ロックを解除して、アプリを起動して…という操作をさせること。それ自体が、本来したい動作の大半に無駄を埋め込んでいる。 日常の範囲内で、体験を満足させることができるようなサービス/機能 それらの反例にあるスマホを出して操作するという事後対応型と、この No Interface の主張としての事前に設定しておくことで以降はわざわざスマホを取り出さなくても使える事前対応型サービス/アプリの例も、対比としてつらつらと書かれていました。 余談: 広告に関して、Facebookのユーザ体験向上施策と、ユーザの滞在時間の短縮と、広告収入のために意図的に滞在時間を伸ばすように体験を低下させた話とか。(その真偽はさておき、例として。) いろいろ悩ましいところですね。。。 鍵となる考え方は以下の3つ。 画面なんかよりも先に、解決したい課題の「いつもの手順」を理解する 利用者にこき使われるシステムを創り出す ひとりひとりに合わせる 物理的なものを持たない、特にWebから出発したサービスって、どういう品質がユーザにとってしあわせになるのでしょうかね。そこをちゃんと考えるには、手段としてSoftwareだけではなくHardwareも関わらないといけないのかな。More
『ソフトウェア・テストの技法 第2版』を久しぶりに読んだ
『ソフトウェア・テストの技法 第2版』 を再度読んでみました。 読み直す、と積読にしてたもの。 入門的なものなので、結構前に読んでいたのですが、改めて軽く読んでみました。ソフトウェアテストであったり、デバッグであったり。プログラムを書く上で、エラーを見つけて治す、というところに対する原理原則をまとめている書籍です。 用語の定義は置いておいて、昨今の開発者テストの文脈で開発者も多少は目を通すのも良いかなと思った内容です。 ソフトウェアテストの心理学 テストとは、エラーをみつけるつもりでプログラムを実装する過程である。 (この書籍における)ソフトウェア・テストの原則 テスト・ケースの必須条件は、予測される出力または結果を定義しておくことである プログラマは自分自身のプログラムをテストしてはならない プログラム開発グループは、自分達のプログラムをテストしてはならない それぞれのテストの結果を完全に調査せよ テスト・ケースは、予想できる正しい入力条件ばかりでなく、予想しないあやまった場合も考えて書かなければならない プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない エラーはみつかれないだろうという仮定のもとにテストの計画をたててはならない プログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例する テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である そういえば、エクスロリームプログラムにおけるテストであったり、インターネットを含んだWebアプリのテストの話が載ってました。2版で追加されたものですね。 前者は、JUnitなどのフレームワークも用いた、自動化されたテスト群をおもに扱っていました。後者は、ネットワーク含むシステム全体を、ネットワーク/DB/Webアプリのモデル層などのように区分して、それらに関わるテストの話を載せていました。 Webアプリのテストの話では、コンテンツ・テストとしてGUIに関する要素が、利用時の品質に大きく関わる、という文書がありました。おもに回帰テストにおけるテストの実行速度の面になるとどうしても優先度下げられたり、人海戦術任せになってるところがありますが、ここら辺は利用時の品質に大きく関わる(利用者が多ければ、尚更)箇所なので、ちゃんと言及されているのは良いことですね。 システム全体の構成の話、目新しさは無かったのですがそこらへんの要素を経験/学んでいない場合は目新しさに映るのですかね？昨今ではそれぞれの箇所で専門性が高まったり、よくあるSeleniumを使ったE2E系の話しだとそれらの多くの要素が(意図的かどうかは置いておて)省略されている場合もあって、システム全体に対する構成に対する想像がされない世界になってきている気がします。 隠蔽された良い面と、開発やテストを行う者としては知らなさがシステムを造る上では悪い面がありますね。More
入門ではなく、基礎として『人間中心設計の基礎』を読んだ
『人間中心設計の基礎 (HCDライブラリー (第1巻))』を読みました。 新しめのユーザビリティ系の本やデザイン系の本を読むと必ずと言っても良いほど出てくる参考書籍です。基礎と書かれていますが、入門ではないので積読な状態でした 🙂 序盤はISOなどで標準化された領域の話しや、その遷移などが書かれていて、だんだんと”人”に対する設計や品質といったものが評価されるようになってきたのかを見ることができます。人間工学よりの話は出てくるだろうなと思っていましたが、Software QualityのISO 25000シリーズへの言及があったのが個人的に面白かったです。良い驚き。 テストエンジニアというか、ソフトウェアテスト界隈でよく参照されるISOがこういう場でも取り上げられるって、ソフトウェアの品質という視点が広く影響を及ぼしているということですね。ISO25010から、一部、抜粋。 Product Quality Functional Suitabiiity Performance effectivicy Compatibility Usability Reliability Security Maintainability Portability Quality in Use Effectiveness Efficiency Satisfaction Freedom from Risk Context Coverage http://maisqual.squoring.com/wiki/index.php/ISO/IEC_SQuaRE 中頃では人間工学と認知心理学の話し、より技法よりな話しがかかれていました。最後は評価で締め。 評価なんかは、実際に経験もしないとなんとも言えないのですが、そういうことも経験として腹に据えることができる環境にもいるので、落とし込んでいきたいです 🙂 コード書くだけかプログラマではないように、テストコード書くだけがテストエンジニアではないですよね。More
『The Little Elixir & OTP Guidebook』のMEAPを読んでみた
『The Little Elixir & OTP Guidebook』のMEAPを読んでみました。 MEAP = Manning Early Access Program つまる所、正式なリリース前から中身を見れるBetaみたいなやつです。完全版は来年頭くらいらしいですね。その頃には今より盛り上がってるのかな。Elixir。 https://www.manning.com/books/the-little-elixir-and-otp-guidebook 途中の章まで書き上がっていたので、今ざーっと記憶が安定している時にまとめて学んでみようということでやってみました。 内容的には、Suprvisorなどを順に構築して、 use Supervisor とかで置き換えて、だんだんと全体の並列処理システムを構築していこうというものでした。まだ書かれていないところにPhonenixとか書かれているので、最終的にはそこらへんを使ったシステムに成長していく、というものぽい。 基礎部分というよりは、実装で手を動かして写経していくことが主な印象で、 Elixir in Action 読んで、写経とかして学んでいれば、そちらの方が良いかなという感じでした。なので、私はさーっと読んで、流した感じで終りました。More
『BDD in Action』を読んだ
『BDD in Action』 積読になってたやつです。 BDD = Behaviour Driven Development この本は、JavaをベースにしたGherkin形式の書式を元に、BDDの具体的な説明を行っているものでした。Gherkin形式で書くことがBDDのGOALではないのですが、いくつか区分を分けた中で一番人に近いところの表現を使うからこれを選んでいるのだと思います。 Gherkin形式は、Given/When/Thenという形式で書かれる、外側から観測される内容を自然言語で記述して実施されるテストコードの形式です。コードと表現を分けた形式で残すやり方ですね。 以下、雑な感じですがメモ。多くが知ってたり経験している内容で、それらを読みながら照らし合わせていった感じ。 Visionから、実装コードへ だいぶ前に アジャイルソフトウェア要求を5章まで読んで というポストを書いているのですが、この書籍ではそこら辺でよく使われている用語を使っています。 Vision => Goals => Capability => Features => Stories => Acceptance criteria => Example => Code このような流れで、構想(Vision)から実コード(Code)に具体化され、動くものが創られます。BDDで観測するのは、主にFeature/Stories/Acceptance criteria/Exampleの箇所。つまり、どの粒度からみた振る舞いでテストコードを記述し、実装を確認するか、ということ。この落とし込みには、impact mapなんかを参考にしたりもします。 impact mapは、 Why(なんのために) => Who(誰を対象に) => What(何を) => How(どんな方法で) とだんだんと Business Goals => Stakeholders => Capability => Features と具体化していく流れを図示したものです。これにより、最終的なゴールと、実装が繋がってシステムを把握しやすくなったりします。 ここからさらに、…More
新装版『人月の神話』を読んだ
人月の神話は、多くの人が耳にしたことがあるであろう有名な書籍ですね。 non silver bulletは特に有名な言葉ではないでしょうか？ 新装版『人月の神話』 私が院の頃、教授からブルックス氏本人のこと、この人月の神話のこと、教授の体験話なども含めて色々聞いたりしていたので部分的には知ってたりしたましたが、今回改めて読み返してみました。経験と知識を紐づける、という感じですかね。 この書籍が長く読まれている理由は、やはり人や組織を焦点としてまとめられていることではないでしょうか。人と組織という、ソフトウェア開発の本質だけれど、なかなか変化しないところに焦点を当ててまとめていたから読まれているのですね。 私は、ソフトウェア構築において困難な部分は、この概念構造体の仕様作成とデザインおよびテストにあって、それを表現する仕事やその表現に忠実か否かをテストする仕事ではないと考えている。 今だとAgileな開発でフィードバックを回すことに価値を置く開発スタイルが広まっていますね。それは今までの開発の歴史上、ブルックス氏も書かれているこの問題に対する1つの取り組みなのですね。 Software Testも”仕様に対して正しい”かどうかの確認(Checking)よりも、そこは機械に任せて、より人だから判断できるであろう仕様などの検証(Testing)に力を入れる方向に向いているし、私も仕事ではそういう方向に向きたいと思っています。 ブルックス氏は、OS/360の経験からこの書籍をまとめたこともあって、 だがもっと本質的な理由は、成功のためには、プロジェクトに携わる人々の質、およびその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えていることにある。 の考えを強く持っている、と述べています。個人的に、ここは数人規模のベンチャーであろうと関係があると感じています。そして、組織論やピープルウェアなどがあるように、たぶんソフトウェア開発においてはかなり重要な点なのでしょうね。 最後に、私はSoftware Test畑なので、こんな引用もおいておきます。 1970年代にエンジニアリングの原則をソフトウェア製作に対して適用する目的は、ソフトウェア製品の品質・テスト可能性・安定性・予測可能性を増加させることが目的であったのであって、必ずしもソフトウェア製作の効率性の増進ではなかった。 > 「企業の生存競争：ソフトウェアの次元」 なるほど。 ソフトウェアが関わるシステムは、結局は人や組織の模倣とまでは言わないですが強く関わるものですね。More
~ my tech diary ~ 