RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

この前記事になった人に追加でインタビューしてみた

こんにちは。開発エンジニアのamdaba_sk(ペンネーム未定)です。

前回は「OWASP ZAPについて調べてみた」という記事を書きました。単体テスト中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。

それはさておき、ひと月ほど前の話になりますが、弊社エンジニアのインタビュー記事が公開されましたね。

周りから信頼されていきいきと業務に励む坂田くんの姿が伝わってきます。この記事を読んで、わたくし不覚にも「楽しそうな職場だなあ、私もそういうところで働きたい……」とちょっと思ってしまいました。いえ、別に今の職場環境に不満があるわけでもないのですが。

まだご覧いただけていない方はぜひに。

ところで実は彼は私の同期でありまして、先日お昼を一緒に食べたついでに雑談に見せかけて追加でインタビューしてみましたので、その時の話を今回は書こうと思います。 (※本人了承済み。ただし写真は気恥ずかしいのでNGだそうです。今さらな感じもしますが)

ある昼下がり

私は前回のブログ投稿からけっこう間が空いていたので、そろそろ新しい記事を投稿したいなと思っていました。技術的なTipsのようなネタもよいけれど、たまにはラクス社員である自分しか書けないようなネタが良い。そしてせっかく書くのだから自分も楽しんで書きたい。業務の傍ら頭の隅で考えるものの、しかしこれだというネタがなかなか見つけられずに少し焦っていました。

混雑を避けて少し遅めの時間帯に昼食をとるのが同期の間での習慣です。業務の切りを見て社内チャットで誘い合い、オフィスから出て外へ。その時は私と坂田くんの二人でした。

そこで、ピンときました。思い立ったが吉日ということで早速アイディアを実行に移す私。その時ちょっと顔がにやけていたかもしれません。

ペンネーム未定(以後 ペン未)「そういえばこの前インタビュー受けてた記事公開されてましたね。見ました。全国デビューおめでとうございます」

坂田くん(以後 坂田)「やめて」

ペン未「なんかめっちゃいい感じのこと言ってたじゃん。あれほんとに言ったの」

坂田「そのままは言ってない。記事の目的に合わせてかなり編集されてるし、後から修正もしたし」

ペン未「まあ、ですよね」

坂田「でもベースはインタビューの時に話した内容」

チャットディーラーのことについて

ペン未「CD1で使ったフレームワークってなんだっけ。ら……ららばい?」

坂田「Laravel。PHPのWebアプリケーションフレームワークだね。あとJavaScriptでVue.js」

何言ってるの? みたいな顔をしつつも坂田くんはちゃんと答えてくれます。ありがたや。

ペン未「そうでした。使ってみてどうだった? 例えばMD2と比べてみて」

MDはCDと同じくPHPで書かれていますが、特にフレームワークは使用していないということは以前坂田くんから聞いていました。

坂田フレームワークがあるとやっぱりかなり楽。面倒なことはやってくれてるし、どこにどんなことを書くといいのかが明確に分かれてるから、作りたい機能のことに集中できる。これはLaravelに限った話じゃないとは思うけど。他にフレームワークを触ったことが無いから他のフレームワークと比べてってなるとよくわからない」

ペン未「Vue.jsは非難殺到だったって話だったよね」

坂田「あー、うん、慣れるまではちょっと大変だったかな。それまで慣れ親しんだ手続き的なJSの書き方とはパラダイムが違うというか。Vue.jsっぽい書き方ってどんなだろうってはなった。開発入る前にもちょっとは勉強してたけど、実装始めてからも公式サイトのドキュメント読んでることが最初のうちは多かった」

ペン未「へー……。先輩に教える場面もあったって記事には書いてあったよね」

坂田「みんなして慣れてなかったからね。LaravelもVue.jsも。何か新しくわかったことがあったらけっこう教えあってた。Laravelだとこう書けばいいみたいですよー、とか、Vue.jsでこう書くとそれたぶんうまくいきます、とか」

話しているうちにオフィス近くの定食屋さんに到着し、食券を購入するために話は一時中断となりました。

かみせん

ペン未「そういえばCDは全社交流会3で表彰されてましたよね」

坂田「そうですね」

ペン未「そういえばあなたもういっこ表彰されてませんでしたっけ。なんででしたっけ」

坂田「そうですね。かみせんプロジェクトですね」

ペン未「それ前から思ってたんだけど、かみせんって結局なにしてるの」

坂田「目標は、なんだっけ……新しい技術とかにチャレンジして、わかったことを普段の業務の改善に活かすこと。具体的にはQCポータル4の段階的マイクロサービス化を今やってるとこで、私はマイクロサービス一つの実装をやってた」

Haskell……?

ペン未「それでHaskell?」

坂田「そうね」

ペン未「なんでHaskell?」

坂田「え、なんかかっこいいから……純粋関数でプログラム書くのってなんか良さそうじゃない? 変なところに副作用が出ないから修正のための影響範囲の調査だって楽そうだし、もし影響があるなら型検査で引っかかるだろうからすぐわかるし」

ペン未「でもそれでアプリケーション作るとかイメージできないんだけど」

坂田「それはライブラリがあるから大丈夫。この前ビアバッシュ5で紹介した本6にはWebアプリケーションを作る章もあるし簡単なAPIサーバーくらいならすぐに」

ペン未「っと、そろそろ時間やね。行きましょうか」

そして仕事はつづく

Haskellについて熱く語ってもらえそうな感じになっていましたがあいにくと時間切れ。ごちそうさまと告げて店を出、そのあとは他愛もない話をしつつオフィスに戻りました。午後の業務が始まります。

自席について先ほどの話の内容をメモしつつ、私が思ったのは一つでした。

Haskell好き、増えるといいね……


  1. Chat Dealer(チャットディーラー)の略称。CDについて詳しいことは商品サイトを参照 → https://www.chatdealer.jp

  2. Mail Dealer(メールディーラー)の略称。MDについても詳しいことは商品サイトを参照 → https://www.maildealer.jp

  3. 年度末に開催される全社員が集まってのパーティ。その年度に特に活躍したりした個人・グループが表彰されたりする。

  4. 社内用システムのひとつ。いくつか機能はあるが、もっぱらその日の仕事はどんなことを何時間やったか入力のために利用される

  5. 月1で開催している開発部の交流会。ビールなどのアルコール(+軽食)を片手にフランクに技術内容について発表したり語り合ったりする。このブログ内でも過去に紹介された

  6. 本間 雅洋, 類地 孝介, 逢坂 時響 (2017)「Haskell入門 関数型プログラミング言語の基礎と実践」技術評論社

新人がDockerを学習すべき4つの理由

f:id:Y-Kanoh:20180424012858p:plain

Y-Kanohです。 社会人になって2年とちょっとが経ちました。

私は、入社してから、会社で得た知識など、新しい技術を試す際、Dockerを使って開発環境を構築しています。 Dockerというと、その手軽さと管理のしやすさから、非常に注目されていますが、新米エンジニア目線だと、技術学習のツールとして大変重宝する点がとても多く感じます。

今回は、新米のエンジニアがDockerを学習することでよかったと感じたことを4つまとめます。

その1:軽量な開発環境として使える

Dockerとは仮想化技術の1つです。 と言っても、VirtualBoxなどのようなホスト型仮想化ではなく、コンテナ型仮想化技術です。 使い古された図ですが、下図のように、 コンテナ型仮想化では、ホスト型仮想化と違い、 ゲストOSを用いず、OS上の区切られたコンテナと呼ばれる空間で動作するプロセスとして仮想空間を扱うことができます。 そのため、ホスト型仮想化より軽量で、CPUやメモリの使用量も抑えることができます。

f:id:Y-Kanoh:20180424005710p:plain

新米のエンジニアとして、自宅で必要になるものは、自分が自由に扱うことができる開発環境です。 会社で得た技術を試したり、ちょっとした下調べ、さらには自宅での開発を行うには、開発環境が必要ですが、 重い仮想マシンを立ち上げることはあまり得策ではありません。さらに、サーバを複数台用いた開発を行いたい場合は...

最初からハイスペックなコンピュータを持っている場合は別ですが、スペックが限られたコンピュータしかもっていない場合なおさらです。

その2:使用するMWを意識できる

Dockerは"Infrastructure as Code"と呼ばれる、インフラ環境をコード化して管理することができる仕組みを提供してくれます。 具体的には、「Dockerfile」と呼ばれるファイルに、コンテナを構成するOSやMWを記述し、「Dockerfile」を基にコンテナを作成することで、何度でも同じ環境を構築することができます。

以下は簡単なPHP環境を構築する際に使用したDockerfileです。とくに難しいことが書いてあるわけではなく、使いたいMWのインストールコマンドがほとんどなため、知識がなくてもハードルは高くありません。。

FROM php:7.2.0-apache

RUN apt-get update
RUN apt-get install -y libpq-dev && docker-php-ext-install pdo pdo_pgsql mbstring

RUN a2enmod rewrite

## 設定ファイルの追加
ADD ./config/000-default.conf /etc/apache2/sites-available/000-default.conf
ADD ./config/php.ini /etc/php.ini

# タイムゾーンの設定
RUN cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

CMD apache2-foreground

あまり知識がないうちの開発では、自分が一体どのMWやライブラリの機能で実装できているのかわからなくなる時があります。 私の場合、自宅の仮想マシンでできていたことが、実はOSにたまたまインストールされていた機能だったのに、知らずに使っていたということもありました。

元々、「Dockerfile」はインフラ環境をコードとして管理することで、MWのバージョン管理や、デプロイの効率化などが目的かと思います。 ですが、学習目的としての環境構築時には、自身が必要とするMWがなんなのか、何の機能を使って開発を進めるのかを自覚することができます。

Dockerfileは、自身の構築する環境をしっかり意識するためにも、役に立つのではないでしょうか。

その3:まっさらな開発環境がすぐ手に入る

学習目的の開発を行う上でありがちなのが、様々なライブラリやMWを試すうちに、 なにをどうインストールしたのかわからず、開発環境が修復できない状態になってしまうことです。 少なくとも、私はそうでした。 インストールしたMWは覚えていない、バージョンもよくわからない、といった状況です。

そのたび、開発環境をリセットするために、OSをインストールしなおすのは、時間もかかり、それに伴ってモチベーションもなくなるため、あまりにナンセンスです。

Dockerでは、「Dockerイメージ」と呼ばれるコンテナのテンプレートのようなものを保存することができます。 「Dockerイメージ」はホスト型仮想マシンのスナップショットのように容量も大きくなく、 コマンド一発ですぐコンテナを作ることができます。 「Dockerイメージ」は、先に触れたDockerfileから作ることもできますし、 インターネットには、たくさんの「Dockerイメージ」が公開されています。

もし、開発環境の構築でいろいろ試したい場合は、ベースとなるOSのコンテナを作成し、 気になったMWをインストールして、うまくいかなかったらすぐ破棄してもう一度コンテナを作り直すといったことを、 短いスパンで繰り返すことができます。

そのため、ツールの選定時には、とても重宝しますし、気軽にトライアンドエラーを行うことができます。

その4:さまざまなOSSツールを試すことができる

Dockerの利点は、なにも開発環境の構築だけではありません。 主要なOSSは、公式のDockerイメージを公開しています。 たとえば、redmineやGitLab、Jenkinsなど、Dockerイメージが用意されており、 コマンド一発で手元にデプロイすることができます。

そのため、もし、配属されたチームにて使っているツールについて、わからないことがあった場合、 自宅でそのツールをデプロイして、自分でいろいろ試すことができます。 私の場合、チームで使い始めたGitLabを自宅で立ち上げ、普段使っていない機能を触ったりしています。

チームで使用しているツールは、開発の中で使いこなせるようになるとは限りません。 かといって、チームで使っているツールを学習目的で弄るわけにもいかないので、自宅で簡単にデプロイし、自由に使える環境はとても重要です。

おわりに

私の場合、最初にDockerを学習したきっかけは、上記のような学習目的ではなく、単純な興味でした。 しかし、Dockerを学習したおかげで、自宅での開発や学習に対して、フットワークが軽くなったと感じています。

Dockerの知識が業務に直接役に立たない場合でも、自身のスキルアップのために、学習してみたらどうでしょうか。

Swiftのクロージャについて

はじめに

こんにちは。ラクスエンジニアのstrongWhiteです。
今回はSwiftにおけるクロージャの書き方をまとめようと思います。
クロージャJavaScriptなどを勉強した方は馴染みがあるかもしれませんが、初めての方は慣れるまで時間がかかるかもしれません。
なお、今回はSwift自体の説明を省きます。過去の記事でSwiftについて触れているので、気になる方はそちらをご参照ください。

クロージャとは

まずは前置きから。そもそもクロージャとは?ですが、簡単に言うと名前のない関数です。
文章にすると余計に混乱されるかもしれませんが、あえてまとめるなら以下のような感じでしょうか。

  • 自身が定義されたスコープ内で解決する関数
  • 実行結果を次の処理で続けて使用する関数を作成したい場合に使用

これを読んでも意味不明だと思いますので、後ほどサンプルコードを書いてみます。

コールバックとは

クロージャとは直接関係ありませんが、この後のサンプルコードにコールバック関数が出てくるので、コールバックとは?という方のためにあらかじめ解説しておきます。
コールバックとはあとで呼ぶという意味で、呼び出し先の関数の中で実行されるようにあらかじめ指定しておく関数をコールバック関数と言います。関数の中で別の関数を呼ぶイメージです。

実例(通常の書き方)

それではサンプルコードを見ていきましょう。まずは通常の書き方から。単純な文字列を出力するプログラムです。

func A() {
    print("RAKUS Developers Blog", terminator: "")
    B()
}
        
func B() {
    print("を読んでラクスを知ろう")
}
        
A()

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

実例(クロージャの書き方)

続いてクロージャを使ったサンプルコードです。処理内容は通常の書き方と変わっていません。

func A(title: String, callback: (String) -> (String)) {
    print(callback(title) + "ラクスを知ろう")
}

A(title: "RAKUS Developers Blog") { (blogName) in // <--クロージャ
    return blogName + "を読んで"
}

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

ややこしそうですが簡単に処理の流れを解説すると、関数Aの実引数titleの値がcallbackの引数になる=blogNameの引数になります。
そしてRAKUS Developers Blogを読んでが足された文字列がreturnされ、関数Aの処理でさらにラクスを知ろうが足され、最終的な文字列が出力されることになります。
高度な書き方に見えますが、Swiftをやっているとよく出てくる書き方なので覚えておいて損はないです。
このとき、関数Aのcallbackが前述したコールバック関数です。関数Aで呼び出されて初めて処理が行われます。

クロージャにすると何がよいのか?

最初に書いたように実行結果を次の処理で続けて使用する関数を作成したい場合に有効です。
例えば、ダウンロードしたCSVファイルを返す関数downLoadCsvがあるとします。サンプルコードでいうとdownLoadCsvは関数A相当になります。
downLoadCsvから返されたCSVファイルをもとに後続の処理を行いたい(例. CSVファイルをパースする)場合、クロージャdownLoadCsvの返り値を記述してあげれば実行結果を引き継げます。
慣れるととても使いやすく、記述もシンプルになるので、クロージャの書き方をぜひマスターしてみてください。

˚✧₊⁎❝᷀ົཽ≀ˍ̮ ❝᷀ົཽ⁎⁺˳✧༚ ← どのように見えますか? ~unicodeをざっくり知ろう~

はじめに

新卒3年目に突入しましたnorth_mkyです。
エンジニアをしていると一度はコンピュータでの文字の扱いについて考えることがあるのではないでしょうか。 今回は、かなりの国の文字をカバーしている符号化文字集合unicodeの特徴について書きます。

※今回はわかりやすさのために厳密性は求めない書き方をしている箇所があります。ご容赦くださいませ。

1. unicodeとは

符号化文字集合のひとつです。
...と書くと頭にはてなが浮かぶかもしれません。

文字というのは世界規模だとかなりの数が存在します。 ただ文字を集めただけではまとまり(ひらがな、漢字、ラテンなど)を表現することが難しかったり形や使われ方の違う文字の統一的に管理することが難しいため、「この位置にこの文字をおいておく」というように文字を系統的に定義し、管理しやすくしています。この位置のことを符号位置(コードポイント)といい、字に対して必ず一意の数値で表される符号位置が存在する、つまり字を数値に表せる「符号化」を行っているため、”符号化文字集合”といいます。

unicodeの他にも符号化文字集合は世界の各地域で存在しています。 こと日本でいいますと文字として、「ひらがな・カタカナ・漢字・アルファベット」を使うため、それらの符号化文字集合の定義が必然となります。国内でこれらの文字に特化した有名な符号化文字集合JIS X 0208があります。

この符号化文字集合は単に字を符号位置という位置づけを付与し文字を定義し集めているだけなので、コンピュータで扱いやすい・処理されやすいよう更に特定のアルゴリズムで符号化をしていることが多いです。この符号化の種類のことを符号化方式といい、具体的には下記のように符号化文字集合を表現する複数の符号化方式が存在します。

符号化文字集合 符号化方式
unicode UTF-16, UTF-8...
JIS X 0208 Shift_jis, EUC-JP, ISO-2022-JP

と、少し長くなりました、話を元に戻しますとunicodeとは符号化文字集合の一つです。 webではデファクトスタンダードの符号化方式(文字コード)、UTF-8の文字はこのunicodeを符号化したものです。冒頭で述べた通り、unicodeは多くの国の文字をカバーしているのですが、それゆえに文字集合の表し方や字の定義の仕方に特徴があります。以下にその特徴を述べたいと思います。

2. unicodeの特徴

unicodeには大きな特徴が4つあります。

  • 特徴1. 4次元で一つの文字を表す
  • 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)
  • 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)
  • 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴1. 4次元で一つの文字を表す

unicodeでは符号位置は4次元で表しています。 擬似的に表現すると下記のようになります。

characterSet[group(群)][plane(面)][row(区)][cell(点)] = 'あ'

unicodeでは各々の次元をおおよそ1バイト(0x00~0xFF)の範囲で表現しており、1文字を4バイトの符号位置で表現しています。 かなりの符号空間を用意しているわけですが、全世界で現在利用している文字のほとんどはgroup:0x00,plain:0x00の範囲に収まっています。 この範囲だけ特別にBMP(Basic Multiligual plane:基本多言語面)というように呼ばれています。

unicodeエスケープ表記で表されている文字で「u\3042」というように2バイト表記されているものは、BMPに属しています。

  • u\3042」=「group0x00/plane0x00の面にある、row0x30のcell0x42の符号位置」

ちなみにBMPにのれず、別のplaneにある文字として日本で使われている一部の漢字があります。 このplaneの文字を実装していないシステムだと文字がただしく表示されない事象が発生します。

  • 文字があるはずの場所が空白
  • □の中に×が表示されている文字になる

特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)

unicodeでは複数の合成用文字(結合文字)を合成して1文字を表す、というのを実現可能にしています。 たとえば日本語の「ぱ」などの半濁音は合成用の半濁点がunicodeに存在するので、「は」+「 半濁点」で表現できます。(※他の符号化文字集合との変換性を考慮して合成用でない半濁点、そもそも「ぱ」だけで符号位置もあります、むずかしいですね...) ですので、たとえば「あ」に半濁点をつけるなど、文字として認識されていない文字を合成して1文字のすることがunicodeを用いれば可能になります。

特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)

漢字を用いる民族、として日本の他に中国・韓国・台湾がなどがありますが、同じ漢字の形で少し書き方が違うものが数多く存在します。(ex. 海|海) このような漢字はunicodeでは一つの字体に統合しています(統合文字)。

特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴3で字体を統合している、といったものの、厄介な問題があります。 別の符号化方式では区別している文字らをunicodeに変換すると、その字体の違いが吸収され、もとの符号化方式での字体を再現することができない事象がおこります。 このような事象を解消するために他の符号化方式との互換性を目的として文字が追加されることがあります。追加したそれらは別途互換文字と呼ばれます。

3. unicodeは進化し続けている ~タイトル回収~

ざっくりunicodeについて特徴を述べたのですが、やはり「すべての文字を網羅する」のは非常に難しく、既存の符号化文字集合との互換性の対応は不可欠となっているようです。ですので、unicodeも進化していっています。最近は文字だけでなく、絵文字の追加も盛んに行われています。それに対してシステムが使っているunicodeのバージョンが異なると文字が表示されない現象がおこります。

タイトルに書いた顔文字ですが、まさしく特徴でお話した結合文字を駆使して作られています。 私の環境ですと、chromeでは一部文字が表示できませんでしたが、safariではきちんと文字が表示されました。

chrome safari
f:id:northmky:20180417095732p:plain f:id:northmky:20180417095728p:plain

4. 終わりに

unicodeのざっくりした特徴を述べました。 何気なく単語として聞いているunicodeがどんなものなのか、掴めるようになりましたら幸いです。

5. 参考文献

今回の記事はこちらをとても参考にさせていただきました。
「第三水準漢字」「サロゲートペア」などの単語がどのカテゴリのどこに位置する話なのか、などがわかるかと思います。

アジャイル開発のプラクティスを取り入れてチームを成長させよう

id:radiocat です。スクラムマスターをやっています。 先月、社内のTechイベントの全社MeetUpで発表してきました。今回はその内容についてあとがき的にまとめてみました。

f:id:radiocat:20180409202902p:plain

終わらないスクラム

私達のチームでは、以前このブログでも紹介されているスクラムトレーニングを受講してスクラム開発を実践しはじめました。

tech-blog.rakus.co.jp

その経験を踏まえて得た知見や気づきを元に発表したのがこのスライドです。

speakerdeck.com

事前にトレーニングを積んでいたものの、実際にスクラムを実践してみるとうまくいかない事がたくさん出てきてスクラムイベントが思った通りに終わらない事態に陥りました。そんな状況を改善するためにスクラムコーチの吉羽さんにアドバイスを頂いたり、スクラムガイドや様々な書籍・資料を参考にして、スクラムイベントをきちんと終わらせるように取り組んだのが次のような内容です。

タスクの細分化

スクラムガイドには 作業の単位は1日以下 と書かれています。タスクの粒度が大きいと着手中の状態が長くなり、どの程度進んでいるのか、どれくらいで終わるのかの見通しがわかりづらくなります。そもそも見積もった時点で1日以上かかるということは細かい作業内容が充分イメージできていない事が多いため予定通り進まないことも多くなります。私達のチームでは見積もりが大きい場合は半日以下になるまでタスクを分解するルールにしました。

リファインメントの徹底

開発チームとプロダクトオーナーがしっかり会話してプロダクトバックログの内容を相互に理解しておかないと、何をどうやって実現するかが明確にならず半日以下のタスクに分解することも難しくなります。スクラムガイドにもリファインメントは プロダクトオーナーと開発チームが協力して行う継続的なプロセス であると定義されています。私達のチームでは リファインメント会議を毎週1回定期開催 するルールにしました。

デイリースクラムの改善

私達のチームではスクラムで開発を始める前から朝会で全員の進捗を確認していましたが、改めてスクラムで定義されているデイリースクラムの目的は何かを考えて朝会のあり方を見直しました。スクラムガイドには 自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握 するためのイベントと定義されています。そのためチームのリーダーが進行して進捗を確認するスタイルから開発チームが交代制で進行するルールに変更しました。

カンバンを検査の拠り所に

カンバンもスクラムで開発を始める前から導入していましたが、チームで意見を出し合って少しずつマイナーチェンジを繰り返しています。デイリースクラムを毎朝カンバンの前で行うため、カンバンもデイリースクラムの目的に沿っていることが重要です。チームの状態を検査し今後の状態が予測できる場にするためにより良い使い方を模索してきました。現在、私達のチームが実践しているスタイルは左からToDo、実行中、レビュー中、完了の順にレーンをわけて、優先度の高いタスクを上から順に並べています。右上にいくほどチームとして最も優先度の高いタスクであり、全員で協力して早く終わらせるようにしています。

むきなおりでチームの方向性を再確認

はじめからチームの進むべき方向性がきっちり定まっていて全員の認識が一致しているようなチームは稀です。私達のチームもはじめは手探り状態でどこかで不安を抱えながらスプリントを進めていたため、3回目のスプリントが終わった時に改めてチームの進むべき方向性を議論して目指すべき設計の方針や品質目標を再確認しました。

インペディメントの除去

スクラムガイドにはスクラムマスターはサーバントリーダーであり 、 メンバーが成果を上げるために支援や奉仕をするリーダー であると書かれています。スクラムにかぎらずソフトウェア開発において開発チームには様々な妨害要素が待ち受けています。近年のソフトウェア開発では、今まで使ったことのない新しい技術や外部のサービスを使うことも当たり前となっています。スクラムマスターはそのような要素を妨害リストとして洗い出し、それらを少しだけ先回りしたり、問題が小さいうちに手を打つことでチームが成果を上げられるように支援に徹しました。

2つの気づき

これらの取り組みを実践することで得た気づきは大きく2つです。

アジャイル開発のプラクティスは従来型の開発でも役に立つ

スクラム開発で取り組んだことは従来型の開発にも活かせることが多いと気づきました。実際にこのような手法は、従来型の開発プロセスの中にアジャイル開発のプラクティスを取り入れるということでハイブリッドアジャイルと呼ばれて実践されているようです。つい最近、日経SYSTEMSの最新号でもハイブリッドアジャイルをテーマにした連載が始まっています。

tech.nikkeibp.co.jp

改善の機会はスクラム開発のほうが豊富

スクラム開発では決まったタイムボックスでイテレーティブに開発を進めることによってアジャイル開発のプラクティスを取り入れるための検査・適応の機会がたくさん訪れます。アジャイル開発のプラクティスを実践して改善する機会はスクラムのほうが豊富にあると感じました。

終わらない学びと実践

スクラム開発でもそれ以外の開発プロセスでも、アジャイル開発のプラクティスは活用できます。そして、スクラムで開発する機会が訪れた時にはアジャイル開発のプラクティスを活用する機会は増加します。つまり、いずれにしてもアジャイル開発のプラクティスを取り入れて学びと実践を繰り返していくことがチームが成長していくための道筋の1つだとスクラム開発を通して学びました。スライドではそのようなアジャイル開発のプラクティスを取り入れるための情報源を幾つか紹介しています。

スクラムガイドによるとスクラム開発は 理解は容易習得は困難 とあります。私達もまだまだ終わりは見えていませんが、習得に向けて学びと実践を繰り返すことでチームがさらに成長できると思っています。

f:id:radiocat:20180409203832p:plain

「tig」をつかってcommitをきれいに分割する

f:id:FM_Harmony:20180404022333p:plain

はじめに

2年目のエンジニアになりました、FM_Harmonyです。 Rakus Developers Blogでは4回目の投稿です。

↓前回の記事はこちら tech-blog.rakus.co.jp

さて、弊社ではビアバッシュというイベントを行っています。(ビアバッシュ・・・?という方はコチラ
今回はその際に私が発表したことについて、補足も踏まえつつまとめたいと思います。 テーマはtigでcommitをきれいに!です。

続きを読む

JaSST'18 Tokyo 参加レポート

3月初旬に開催されたJaSST'18の参加レポートです。 [読了時間 8分]

JaSST Tokyo とは

国内最大級のソフトウェアテストシンポジウムです。

JaSST'18 Tokyo

JaSST Tokyo の昨年と今年のベストスピーカ―賞の傾向(2017年2018年)から、プロセス改善に注目が集まっている感もありますが、今回の JaSST'18 Tokyoの目玉はやはりなんといっても、Google ジョン・ミッコ氏の Flaky Test だと思います。

以下では、ミッコ氏による2つのセッション

を取り上げて、今回参加できなかった方でも、Google社の先進的な取り組みについて概要を把握できるよう、ポイントを絞ってお伝えしたいと思います。(ブログに掲載することについては、ミッコ氏の許可を得ております。ありがとうございます!)


基調講演 セッション A1「Advances in Continuous Integration Testing at Google」、基調講演者チュートリアル G5「How to identify test flakiness in your test result data テスト結果からテストの不安定性(test flakiness) を読み解く」

講演資料 が公開されていますが、 語彙の事前知識や質疑できる場などがないとなかなか理解しにくい箇所もあると思います。 まず、趣旨(引用)とキーワードを簡単に整理した後に、セッションの要点をお伝えします。

趣旨

  • より効果的なテストのスケジューリングとは
  • コストの削減方法
  • 不安定な自動テストへの対処(Flaky Test)

キーワード

  • SETI (Software Engineer, Tools and Infrastructure)
    • テストインフラを開発する役割
      • 8~10人のチームに1~2名のSETIアサインされる
  • RTS (Regression Test Selection)
  • Transition
    • テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移すること
  • Edge
    • テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移したチェンジリストの断片
  • Greenish
    • テスト成功(グリーン)のような状態
    • 確信ではなく確率
  • Flaky Test
    • 不安定なテストのこと
      • テスト結果が非決定論的
      • 同じコードリビジョン、同じ入力と設定、においてテストが成功したり失敗したりする

Googleの自動テスト(概観)

  • 420万の独立したテスト
    • その16%は何がしかのFlakyさを持つ
  • 1日あたり1億5000万のテスト実行数
    • 平均して各テストが毎日に35回実行される
  • 1万3000以上のチーム
  • テスト実施の99%は成功する
  • テスト結果がPASS→FAILに遷移したテストのうち、84%はFlaky
    • テスト失敗の16%だけが欠陥を意味していた
  • テストの 1.23% だけがソフトウェアの欠陥を見つけている
    • 変更頻度が多いファイルは欠陥が埋め込まれやすい
    • 開発者が3人以上修正したソースは欠陥が埋め込まれやすい
      • 1人より2人がよい
      • 3人より2人がよい
    • 言語によって欠陥の埋め込まれ度合いが異なる

なんというか規模が桁違いですね!

RTSはなぜ必要か

テスト実行数を削減するため

  • テスト実行の99.8%は、テスト結果の遷移を引き起こさない
  • テスト結果の遷移を引き起こすような0.2%のテスト実行だけで十分なことになる
    • もし完璧なアルゴリズムがあれば、すべてのテストを流し続ける必要はない

Greenishという概念がなぜ必要か

テストの量、実行回数ともに莫大で、全てを実行しきれないため

  • RTSだけでは問題が多い
    • 依存関係グラフを元にした回帰テスト対象の選定(RTS)を行っても、コアモジュールへの些細な修正がほぼ全体に影響するため、一定期間のマイルストーンでのスケジューリングにおいて全テストを実行することになりがち
  • マイルストーン間は、プロジェクトの状態は決定的ではない(inconclusive)
  • 全テストを実行することによる「グリーンの確信」に代わり、「グリーンの確率」を提供している
    f:id:maskondo:20180330152612p:plain
    図1. Greenish
    • 図1で、大きい緑●が「グリーンの確信」
    • 図1で、モスグリーン四角が「グリーンの確率」
  • チームにとってはリスクを持ってリリースすることになる

遷移を見つけるまでの時間を節約することを重視 しているようです。1日経てば「過去」であり内容を忘れている、と。

Flakyという概念がなぜ重要か

テスト結果が成功から失敗に状態遷移したときでも、その84%が誤報であるため

  • システムの問題なのに、開発者にテストが不合格だったと通知がくることで調査する時間が無駄になる
  • マシンリソースの 2~16%をFlaky Testのために消費している
  • 全てグリーンでないとリリースしないため、リリースの妨げになる
  • 無視すべきでないときもある
    f:id:maskondo:20180330155635p:plain
    図2. Flaky
    • 図2で、Flakesはテスト結果が非決定論的に成功したり失敗したりするFlaky Test

Flakyなテストがあると、テスト失敗が常に欠陥を意味するとは限らなくなってしまう のです。狼少年のような存在ですね。

Flaky Testへの対処

Flaky Testを検出することで、開発者にはテスト結果に添えて「Flakyである」という旨も一緒に伝えることで、調査コストを抑える

  • Flakyさは不可避(Inevitable)との見解
    • Flakyさを除去するのと同程度には新たなFlakyさが埋め込まれる

Flaky なテストを単に無視したり削除するという考え方について、休憩時間にミッコ氏に直接尋ねることができました。不安定なテストはまだバグを捕まえるために価値があるので無視したり削除したりしてはならない(意訳)とのことでした。

Flaky Testの検出方法

テスト結果(PASS/FAILのバイナリ値のみ!)を残すだけで、Flaky Testへの洞察が得られるそうです。 特殊な操作は必要なく、単純なクエリで推定できるところがポイントです。

  • Google では テスト結果を2年間記録を残し続けている

    • PASS/FAILのバイナリ値のみ
    • Googleでは *unit.xml ファイルは残していない(が残しても構わない)
  • テスト結果の遷移であるTransitionやEdgeに着目して、経験則を育てている

    f:id:maskondo:20180330152621p:plain
    図3. Edge

    • 履歴を共有(同じタイミングで成功・失敗すること)する他のテストの数が多い場合はFlakyではない
      • ライブラリ起因などの明確な理由がある可能性が高い
    • テスト結果の遷移が多いテストは、Flakyと判断できる
      • 例えば、1日に30回もテスト結果が遷移するテストがあった場合に、開発者がそれほど頻繁に直したり壊したりをしたとは到底考えられない

チュートリアルで Flaky Test の検出を実際に Google BigQuery を使って行いましたが、とても簡単でした。


感想

自動テストへの長年の取り組みの成果として、もし自動テストを全て流せるなら「確信(100% Confident)」があるという土壌があった上で、テスト実行の運用をいかに効果的に行うか? という次元のお話でした。 確信(100% Confident)に代わる何かが必要な状況で、ビッグデータ解析を活用するところがグーグルらしいですね。 クロージングパネルでも話されていた「アメリカでは大企業、中堅企業において自動テストは既に当たり前であり、より効果的な運用についてその興味が移っている」といった言説が印象的でした。

Copyright © RAKUS Co., Ltd. All rights reserved.