2016年振り返りと2017年へ

2015年振り返りと2016年へ ~20代も最後~からもう1年たったのですね。30歳ですかー。

今年の活動を簡単に振り返る。2017年のことも、最後に。来年振り返る時にちゃんと達成できているとよいな。

全体

今年は私の中ではOSS周辺の活動が大きく動いた気がします。あとは機械学習系とかも今後テストでは標準的なスキルになるはずなのでそこらへんを学んだり…

振り返り

仕事(Works)

活動(Activity)

発表系

2015年はJaSSTなんかに積極的に募集したのですが、今年は少し異なる方面の活動をしていました。人のキャリアプランに影響を及ぼしているという話も耳にし始めました。

OSS系

一番大きかったのはAppiumのRuby bindingのメンテナになったことでしょうか。他には言語ではElixir、Ruby、Swift(Objective-C)、Java周りで既存OSSにPR投げたりOSS公開したりしました。今の会社に入って、会社がOSSを推奨するのでOSSに対する活動を広げてきましたが、ここにきて世界的に使われているツールのライブラリメンテナになるとは思ってもなかった…

screen-shot-2016-12-31-at-22-17-10

  • AppiumのRuby bindingnのメンテナになった
  • 公開したもの
    • DroidTestHelper
    • anticuado
      • 対象となるプロジェクトのoutdatedなライブラリをHash形式で整形されたものを取得可能なライブラリ
      • Android(Gradle)、iOS(CocoaPods/Carthage)、Ruby(Bundler)、Elixir(Hex)、JavaScript(npm)を今サポートしている
      • https://github.com/KazuCocoa/anticuado
  • 以下のOSSに不具合修正などのPR投げた
    • Elixirやその周辺ライブラリ
    • EarlGrey、Turnipなどのテストライブラリ
    • toothpick といったAndroid向けDIライブラリ

その他

  • とあるソフトウェアエンジニアリング系の書籍の翻訳を複数人で実施中

専門性

  • ソフトウェアテストや品質改善に関してはちらほらと勉強会に顔を出したりしています
    • JaSSTの廊下で話すようなところが一番実りある会話できますね。そういえば…
  • 引き続き、自動化研究会に参加
  • UdacityのDeepLearning系とか学んだり

2017年へ

いくつかやりたいことに向けて蒔いたタネが実ってきているので、もう少し先のやりたいことへ手を出したいなーと思う次第。
あとは健康に気をつけながら…(私生活は言わずもがな)

やること

やりたいこと

  • DMM英会話など使って英語の会話に慣れる
    • try!SwiftTokyoに向けて週2、3で最低限やっていきたいのですよね
  • 海外に出張/移住ベースで何か仕事していきたい
    • 外にいくだけなら旅行でも良いのですが、仕事としてちょっと活動したいかなーという感じ
    • ちょっと親知らず抜いたりするので、前半は厳しいけれども…
  • Swift/Kotlinに関するプログラミングスキルを補填したい
    • 仕事…

興味の対象を主な活動の範囲として楽しみながらやりたいですねー

Advertisements

Design Document Template

This may help me when I try something stuff.

WIRED Vol 25に書かれてた多数決に関する話

WIRED(ワイアード)VOL.25 に多数決の話があったので読んでみた。

ここで扱う多数決は、対象の半数以上を大多数とする、という類のもの。幾つかの政治的な実例から多数決の正しさ、妥当さを考えた記事でした。また、コンドルセの多数決を取り上げていました。

こういう分野、行動経済学と確か呼ばれていますね。

多数決では独立性が非常に鍵で、他要素からの影響であったり不正確な情報が入る環境下では正しく判断できない(判断に重み付けが含まれる)というところが難しいところです。そして、WIREDにもここまで言及されていたところが良かったです。

内容自体は修士論文書いていた頃にすでに言われていた(論文として調べていた)ことなので目新しさはなかったのですが、こういう変わり種も載せてくれるところがWIREDの面白いところですね。

2015年振り返りと2016年へ ~20代も最後~

2014年を振り返って、2015年を迎えたわけですが、ここで同じように振り返ってみます。主には表立っているところで。

来年の年明けは30歳になっていると思うと、なんだか身の引き締まる思いですね。想いだけ。

テストする人に対する技術的側面を広めることができて良かったと思います。私の観測する範囲では、求人にも多少なりとも良い影響をあたえられたと思います。私のところに募集して来ていただけるとなお嬉しい。

書籍関係はこちら => 2015年に新たに読んだ書籍群を振り返って

振り返り

仕事

  • サービスの開発に注力できるように開発プロセスが深化してきた(モバイルアプリ)
    • リリースまでの流れの中で、全体最適を目指して時々のボトルネックを補ってきた成果でしょうか。優秀な方々が特筆して技術的な課題を解決する傍ら、広くを見ることができる人が外堀を埋めていく感じ。
  • 採用の方向性などにも主導する形で関わるようになってきた。いろいろと難しい。

活動

基本、職種と役割、採用目的で頑張ってた社外発表が身をむすびつつある気がします。が、役割を広めて仲間をつくっていくって難しい。

その他、OSS活動もボチボチ。OSSというか、自分の課題を解決するための開発の成果を公開した、という感じですね。
Androidの資源計測のための droid-monitorであったり、ElixirでParameterized testを支援するためのex_parameterized、発端はモバイルアプリをテストするときのある問題を解決するためのproxy serverが欲しかったから作ったhttp_proxyなど。実装内容を追うと、そんなに混んだことはしていないですが。

SQuBOK読破会も1年が経過して、アドベントカレンダーまで書くほどになったのは思った以上の成果になりました。

専門性

  • 業務でもテストコードとか結構書く(時間的な)余裕が出てきた
  • Swift/Elixirを新たな言語として集中して学んだ
    • 思いの外、Elixir/Erlangがしっくりきた。分散系はやっぱり興味の対象なのね。あと、あの手のMacroは使いやすい。
  • Android/iOSのEspressoやXCUITestなど、情報少ないところ進んだ
    • 未成熟なところなので、結局はコードを追うことになる…
  • SQuBOK読破会など、テスト/品質界隈への取り組みは継続 🙂

総括

社内外で色々取り組みを広げた1年だった気がします。外部への発信は社内の成果の賜物です。ありがとうございます。

ふと、もう6年くらい前になる学生の頃に考えていた位置情報と食を組み合わせたサービスを思い出しました。そのサービスはキャンパスベンチャーグランプリというちょっとした大会で小さな賞をいただけたのですが、収益性とか事業としてまだ多分に未熟だったこと、修論でそれ以上手を伸ばせてなかった為にそのまま投げてしまいました…

そこらへんの経験と教授の影響があって、より良いサービスを創造して開発していく為に私はテストエンジニアという役割を進み始めたのだなと思い出しました。品質向上の為のいかなる活動にも関与できるじゃないですか。

やりたいこと

2016年、20代最後です。地に足をつけて歩み続けたい。

仕事

  • Web/Server側へも足を運ぶぞ!(ようやっと)
  • 社内でxUnit Test Patternsの読書会やるので、そこらへんをかんばりたい
  • 海外とかも
  • 同じ職種を広げたい
  • 欠陥から学ぶ、というところに焦点を当てた何か活動を進めたい
    • KPTを回すとかではなく、もっと規模も大きく長期的なやつ

活動

  • デブサミ2016へも依頼頂けたので、ちゃんと役割をこなしたい
    • こちらです =>
  • 引き続き、採用も兼ねて外に顔だしたい
    • 仲間見つけるの、やっぱり大変なのでそこはカバーせねば…

社内外でうまいこと立ち回りたいですね。どちらか一方に偏るのは私は好きではないので、バランス良く生きたい。

※プライベートはもちろん大事にね。

システム自動化カンファレンス2015で登壇してきました

システムテスト自動化カンファレンス 2015で発表してきました。

今回はサービスを生業としている企業が少し目立つ感じで居ましたので、ビジネスの形態の違いから疑問を残したままの参加者もいるかもしれません。リリースに至るまでの文化の違いや、一見出してなんぼに見えすぎる世界など、その裏側の取り組みを除くとその疑問も拭えないものであるかもしれません。ですが、全体的に見慣れた風景とは違ったものが見えたのではないでしょうか。(そうだとうれしい)

ところで…

私の発表は終わり頃で、聞かれている方々も結構お疲れだったのではないでしょうか。

1時間という長い時間が持ち時間だったので、入りの猫の画像であったり、所々少し誇張気味に表現しながらも、退屈せずに聞くことができるように工夫してみました。Twitterをみるに、概ね期待通りの効果が出たようでうれしい限りです。

発表

スライドは以下です。発表した感じ、想定した時間通りに、要素をかいつまみつつモバイルアプリの開発/テスト/ツール群/事例を共有できた気がします。

遊び

ところで、最初の自己紹介のstruct( %{} )やパイプライン演算子など、モバイルとはほとんど関係ないElixirを取り入れていたことはお気づきだったでしょうか?ちょっとしたお遊び。

気づいてくれたかたもいたみたいです。

One more thing

発表の前にもスライドを公開しましたが、そちらには意図的に載せていなかったことがあります。One more thingです。正直なところ、いろいろ書いててもっと時間を使おうとも思ったところです。ただ、モバイル開発という文脈から距離のある方が多いと踏んで、情報過多になるだろうのでここはかなり端折りつつ、要点だけ載せるに止めました。

tgetterはこちら

http://togetter.com/li/912197

最後に

パネルのところでは、直前の1時間の発表で疲れてて、集中力に欠けてて申し訳ありませんでした…

IoTの話は以前考えたことあるのですが、広い視野でみると分散系の話に落ち着いていくのではないかと思います。そこでは、研究でかじっていたビザンチン将軍問題も絡んでくるような分散ネットワークな話になると個人的には面白いと思っています。(大変ですが)

私よりも人格/スキル/能力共に高いかたが大勢いると思いますので、もし興味があるようでしたら一緒にこのような変化へ飛び込んで、さらにハッピーになりましょう。

SQuBOKv2読破会と私

最近開いたTestingに関するイベントを行ってから、感じること、気づくこと、つながりといったところを考えるこの頃です。

さて、SQuBOKv2読破会 Advent Calendar 2015、5日目の記事です。4日目はSQuBOKによる無知の知の体験でした。

この会は、有志何人かが集まってソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)を読み、議論し、より良いソフトウェアを創造していくための足がかりを得るものです。そこら辺の概要は1日目の記事を参考にすると良いでしょう。

この本自体はより良いソフトウェア開発を対象とした、組織的な大局話からプロジェクト個々の話、コード品質やテスト技術と局所的な話に至るまでの全般な話を扱っています。コードの実装やテスト実施などの実施の時代によって移り変わりが激しいところは適度に抽象化されて、時代に流れすぎない形でまとめられています。

今回は、この読破会と私、ということで少し書きます。

きっかけ

私は過去、WACATEと呼ばれるソフトウェアテストに関わる人たちの集まりに参加しました。2014年の冬でしょうか。その頃、夜の分科会を(確か)テストエンジニアのこれから、という少しざっくりとした話題で開かせて頂きました。その時に色々話をしました中にいた、@masskanekoに誘われる形で参加しました。

当時、SQuBOKv2は軽く読んでいました。ただ、やはり量が多いので個々の要素は詳しく読んではいませんでした。自分の必要な箇所だけかいつまんで読む、それ以外はこれから必要になったときに時折読む、という感じでした。

そんな折、この読破会への誘いを受けました。結果、一人で読んで積読に近いものになるよりは良いかな、という気持ちで参加してみました。

参加して

SQuBOKは知識体系と言われますが、実態は 困った時に過去の経験を素早く参考にすることが可能な indexのようなものです。内容の情報量からしてもそうは思っていたのですが、この会で読んでその認識がさらに強くなりました。この過去の経験、というのは1990年代の産業が成長し始めている頃からの様々なトライアンドエラーの塊です。

例えば、Web界隈では最近開発プロセスの変化や組織の移り変わりの話など含めてマネジメントの話、プロセス改善の話をよく聞きます。そのあたりは、小さな個人の開発からチーム/組織な開発に業界全体が遷移しようとしている時代だからであったり、はたまたスタートアップが増えているからでしょう。そこでよくある改善の取り組みやアンチパターンなんかは、私の経験と照らし合わせてもこのSQuBOKに同様なことがすでにまとめられていました。(マネジメント特化、などになるとまた話が変わりますが。)

失敗するよくある形、それを防ぐために先人はどのような取り組みを行ったのか、というものをざっと知ることができました。その具体は時代や周辺環境に差があるので全く同じではない、というのは自明です。それを踏まえた上でも、やはり役立ちます。

手段としてのツールや環境は変わろうとも、人による創造的な取り組み自体は今も昔も大差ない、ということのようですね。そこら辺の取り組みが巨大化・形骸化して今に至ったのだとしても、前を向いて前進していた熱い時代では変わらぬ改善への取り組みを行っていたようですね。ここら辺は大学時代に教授らから話を聞いてはいましたが、改めてなるほどねーという感じでした。

合宿

開発者の中には開発合宿を開いたこともあると思います。それと違わず、この読破会も同様な合宿を夏頃に行いました。ただ、開発者合宿でよくあるプログライングが伴うものではありません。

ソフトウェアメトリクスなどの、ソフトウェア製品自体の計測をどうするか、どんな研究があるか、というところを話題の中心に、色々議論していました。参加した人たちの経験などを色々議論しつつ、非公開な情報を共有したりと、本だけでは得られない知見を得られました。

アルコールや温泉などは言わずもがな 、です。

今生かされていること

これらの経験は、今の実際の業務に生きています。

例えば、私は立場上プロセス改善などを主導する位置にもいます。また、チーム作り、採用などの先も考える必要もあります。そのような組織に寄った活動を日々のそれなりに多忙な開発実務と並行して行うには、経験が全てではやっていけません。(少なくとも私は無理そう)。そのような時、直接的な解答をあたえてくれることは少ないですが、それにつながる過去の事例を提供してくれる体系はとても役立ちます。

少なからず私たちが進めようとしていることに対してよくない匂いに気づくアンテナを広げることにも役立っています。取り組んでいることがハズレではないこと、不安なら参考になりそうな過去の経験へのアクセス手段までたどり着けることがわかっていることは、行う取り組みに対して背中を後押ししてくれます。

開発言語やそれらを取り巻くツールのように動きの早いもの、人に関する古くから研究されていて動きの穏やかなもの、それぞれを上手い具合に取り入れながら活動を継続したいですね。

最後に

今の自分、環境は特別である。過去の先人とはまったく違う。

こういう思想を持っていない人にとっては、SQuBOKのような体系はなんらかの形で恩恵を読者にあたえてくれると思います。これは新規サービス開発といったサービス自体の話ではありません。すでに研究され続けている人の関わる系に関する話です。

この書籍に限りませんが、よくある失敗として目的と手段のはきちがいがあります。また、前例にとらわれて思考が停止してしまうこともよくあるでしょう。そこに言及することは不毛なので立ち入りませんが、一応注意点としては残しておきます。

では、手短な内容となりましたが以上になります。次回は 吉田東京 さんです。引き続き宜しくお願いします!

SymfonyにおけるPRの概要を書くテンプレート

java_ja_ossにでて知ったことメモ。
Symfonyコミュニティ、PRの内容を知るためのテンプレート。

https://symfony.com/doc/current/contributing/code/patches.html#make-a-pull-request

[Yaml] fixed something
[Form] [Validator] [FrameworkBundle] added something
The pull request description must include the following checklist at the top to ensure that contributions may be reviewed without needless feedback loops and that your contributions can be included into Symfony as quickly as possible:

| Q             | A
| ------------- | ---
| Bug fix?      | [yes|no]
| New feature?  | [yes|no]
| BC breaks?    | [yes|no]
| Deprecations? | [yes|no]
| Tests pass?   | [yes|no]
| Fixed tickets | [comma separated list of tickets fixed by the PR]
| License       | MIT
| Doc PR        | [The reference to the documentation PR if any]

なるほどー。コミュニケーションを円滑にするために、こういうの良いですね。コミュニティで用意しているの。
tests pass?no がとは…

[Elixir in Action]Erlang/Elixirの再帰計算におけるnon-tail recursionとtail recursion

ちょっと印象的だったので。

再帰計算を行う関数の最後が、別の関数呼び出しかどうか、という違いです。

non tail recursion

defmodule ListHelper do
  def sum([]), do: 0

  def sum([head | tail]) do
    head + sum(tail)
  end
end

https://github.com/sasa1977/elixir-in-action/tree/master/code_samples/ch03

tail recursion

defmodule ListHelper do
  def sum(list) do
    do_sum(0, list)
  end

  defp do_sum(current_sum, []) do
    current_sum
  end

  defp do_sum(current_sum, [head | tail]) do
    new_sum = head + current_sum
    do_sum(new_sum, tail)
  end
end

https://github.com/sasa1977/elixir-in-action/blob/master/code_samples/ch03/sum_list_tc.ex

Dive to source code

Elixirには、再帰表現をまとめたコードとして Enum.reduce(collection, acc, fun) なんかを提供しています。
この中身を少しみてみましょう。

Elixirの の再帰箇所は以下のように書かれています。

def reduce(collection, acc, fun) when is_list(collection) do
  :lists.foldl(fun, acc, collection)
end

Erlangの資料によると、 :lists.foldl(Fun, Acc0, List) はtail recursionとのこと。
こちら

foldl/3 is tail recursive and would usually be preferred to foldr/3.

ということは、 Enum.reduce(collection, acc, fun) はtail recursionなのですね。

コード追うと Enum.reduce/2Enum.reduce/3 を結局は呼ぶので、reduceはtail recursionで実装されていて、巨大なリストに対してもちゃんと再帰計算ができることを重視されているのですね。
Elixirの List.foldr/3List.foldl/3 もそれらを呼び出しているので、tail recursionなのですね。

利点として、このtail recursionの場合、メモリの消費を増やすことなく、無限に再帰呼び出しができると。
一方、これは手続き型な書き方な側面や、性能的にnon tail recursionよりも遅い場合があります。

なるほどなるほど。


[更新]20150806

Erlangの :lists.foldr(Fun, Acc0, List):lists.foldl(Fun, Acc0, List) に書き直しました。

[Elixir]パターンマッチやcase文でのwhenにおけるguard clauses

Elixirの記述に慣れるため、exercism.ioで簡単な問題を解きながら時間の合間に遊んでいます。
そこで少しエラーを何回も出してしまったのでメモ。

以下の通り、Elixirではguard clausesの中におけるbooleanの式ではand or not を使う必要があるみたいですね。

Note that while boolean operators such as and, or, not are allowed in guards, the more general and short-circuiting operators &&, || and ! are not.

from: http://elixir-lang.org/getting-started/case-cond-and-if.html

他言語だとビット演算云々で私は || とか && を使うことに慣れていたのでつまづいてしまった…

あと、同じように以下の[ここ]と書いている箇所。判定を読みやすくするために独自の関数を作ってみたのですが、guard clausesの中ではそのような独自な関数はちゃんとマクロ組んで作らないといけないのですね。

case example do
  x when [ここ] -> 処理
end

あらかじめこのwhenの中で使える関数が用意されていますが、それを超えるものはマクロ組んでいく必要があるみたい。ただ、それは可読性を損なう恐れのあるものなので、個人的には case example do のexampleをうまいこと表現したいですねー。

もう1個。以下のようなcaseを使った関数、パターンマッチを組み合わせた関数でも記述することができます。

  • case文
  def leap_year?(year) do
    case year do
      rem when rem(year, 400) == 0 -> true
      rem when rem(year, 100) == 0 -> false
      rem when rem(year, 4) == 0 -> true
      _ -> false
    end
  end
  • パターンマッチ
  def leap_year?(year) when rem(year, 400) == 0, do: true
  def leap_year?(year) when rem(year, 100) == 0, do: false
  def leap_year?(year) when rem(year, 4) == 0, do: true
  def leap_year?(_), do: false

whenの中に記述できる処理式には限りがあるので、複雑な分類であれば case を使うほうがよさそうですが、簡単な when で区分できる場合、関数自体を分けたほうが責務が明確になってよさそう。

個人的には、パターンマッチで関数を分ける => case文で処理を分ける、という優先順位で処理を考えるときの思考が定着してきた感じ。

[Elixir]パターンマッチにおけるpin演算子

個人的なメモです。

Elixirでの、pin演算子の意義として以下の返答をもらいました。

確かに、個人的に明示的にパターンマッチと知らせるために ^x = 1 のように書かせることに利点があるという言語設計、納得。