読者です 読者をやめる 読者になる 読者になる

esm アジャイル事業部 開発者ブログ

永和システムマネジメントアジャイル事業部の開発者ブログです。

改訂2版 パーフェクトRubyが出版されました

こんにちは。takkanm です。

本日 2017/05/17 は、弊社メンバーが関わっている書籍パーフェクト Ruby の改訂2版の発売日です。

パーフェクト Ruby は、Ruby に関する内容を言語仕様から、メジャーなライブラリまでを網羅することを目的とされた書籍です。 弊社からは、私と hibariya が執筆に携わっています。

初版は 2013 年に発売されたので、今回は 4 年ぶりの改定となります。 改定内容としては、初版時にターゲットとした Ruby のバージョンである 2.0 から、昨年末にリリースされた 2.4 までの差分をアップデートしました。対象バージョンのアップデートにおいては追加されたメソッドが追加されているのはもちろん、初版から大きく仕様の変わった refinements についての内容を大きくリライトしました。 さらに、初版が発売後に対象を Rails に絞ったパーフェクト Rails が出版されたということもあり、Web 関連の章が削られ、代わりに test-unit を使ったテストの章が追加しています。 このように追加要素も多いので、初版を持っている方にもオススメです。

紙の本は、Amazon やお近くの書店でお求めいただけると思いますし、GihyoDigitalPublishing では PDF でもお買い求めいただけます。

みなさんが Ruby でプログラムを書く際の良きお供になれば幸いです。

併せて読みたい

AgileJapan2017とワークショップに参加して、モダンアジャイルについて考えてきました

こんにちは、平田です。 少し前の話になりますが、AgileJapan2017と、翌日に開催されたモダンアジャイルワークショップに参加してきました。

www.agilejapan.org

agilejapan.org

モダンアジャイルについて

アジャイルソフトウェア開発宣言が出されてから15年以上が経ち、その現代的な解釈を「モダンアジャイル」として Joshua Kerievsky さんがまとめました。 モダンアジャイルの4つの原則は以下の通りです。

  • Make people awesome(人々を最高に輝かせる)
  • Make safety a prerequisite(安全を必須条件にする)
  • Experiment and learn rapidly(高速に実験&学習する)
  • Deliver value continuously(継続的に価値を届ける)

それぞれの内容については、いろいろなブログ記事も出ているので、ググっていただくとして、私からは基調講演とワークショップの2日間で感じたことをいくつか紹介します。

f:id:m_pixy:20170414181136j:plain

安全

4つの原則のうちのひとつに含まれる「安全」については、基調講演の中でもかなり多くの時間を割いていました。安全は優先順位が一番高いというわけではなく、必須の前提条件であるという考え方です。Googleでの心理的安全の重要さが分かった調査結果は有名ですが、他にもメンバーが様々な挑戦をするために安全なミーティングをやるための5箇条など様々なエピソードが紹介されました。

面白かったのは、Slackが非アクティブなユーザーがいることを伝えてきて、そのユーザーの分の料金を返金してくれたというエピソードでした。Slackというサービスは顧客の予算を守ってくれるという安心感をくれたという話で、開発メンバーにかぎらず、関わるすべての人の安全のために行動するということの重要性が伝わりました。

アウトプットではなくアウトカム(成果)に着目する

良いソフトウェアを作ろう、動作するソフトウェアを作ろうと考えるのではなく、それらが生み出す「成果」に着目しようということです。 ワークショップの中で「継続的に価値を届ける」ことをチームで改善していくために、計測すべき指標を考えようというものがありました。私たちのチームでは、「継続的にチームがソフトウェアをリリースすることが重要である」と考え、たとえば日単位での本番リリース数などを数えようとしていたのですが、Joshuaさんから「それは成果なのか?」という問いかけがありました。

「包括的なドキュメントよりも動くソフトウェアを」というアジャイルマニフェストの先にある、「ソフトウェアがもたらす成果」に着目することの重要性に気づくことができました。

「要求」を「実験」として捉える

アジャイルマニフェストの「変化に対応する」というのは受動的である。高速に実験し、高速に学習するために、顧客からの要求さえも実験であると捉え、早く失敗していこうという話がありました。

まとめ

今回の基調講演や、Agile2016での基調講演(リンク)では、モダンアジャイルの4つの原則について、考えられた背景等をエピソードを交えて紹介されていました。実際のプロセスについては、チームで考えていくべきという考え方であると理解しましたが、ワークショップの中で紹介されたプロセスでは、クリックテストやセットベース設計など、UXやリーン、DevOpsなどの文脈で語られることの多いプラクティスが紹介されていました。モダンアジャイルの原則は、これらの考え方やプラクティスを束ねる概念として利用してみるのもの面白いと感じました。

最後に

さて、今回のAgileJapan2017には、2016年に引き続いて、永和システムマネジメントはサテライトスポンサーとして協力をしています。 聞きなれないスポンサーですが、これは全国で開催されるAgileJapanの地方サテライトに、永和のメンバーが講演や運営のサポートとして参加するというスポンサーです。

身近でアジャイルの話が聞ける、議論できるチャンスですので、ぜひお近くの方は参加いただければと思います。弊社のメンバーも各地のサテライトに参加します!

私も直近では、栃木サテライトにお邪魔する予定です。皆様とお会いできるのを楽しみにしています!

www.agilejapan.org

Repro様とExtreme Fish Bowl を開催しました

こんにちは @color_box です。

2017/01/27 に Repro のエンジニアの皆様と Extreme Fish Bowlを開催したので、それに関する報告をします。


Extreme Fish Bowl

Extreme Fish Bowlとは、皆に見られながらペアプログラミングをするというものです。 その場にいる全員の中でペアを組み、1台のマシンを使ってかわるがわるペアプログラミングをしていきます。 ペアプログラミングをしていない他の参加者は、観戦にまわります。

5分を1ターンとして、ターン終了時にドライバーが抜け、ナビゲータがドライバになります、ナビゲータは他の参加者の中から一人入って次のターンに進みます。 そうやってナビゲータとドライバを一人ずつ交代しながらプログラミングを進めていくのがExtreme Fish Bowlです。

プログラミングの対象となるお題は事前に与えられており、お題を解くようなコードを全員で考えていきます。 作業風景は常にスクリーンに映し出されており、会場にいる全員に共有されます。 もちろん手を動かしていない他の参加者も、ペアプログラミングをしていえる二人に温かい野次のような声援を飛ばして構いません。

f:id:color_box22:20170127204439j:plain


当日のコード

当日書かれたコードは下記リポジトリにおいてあります。 github.com

続きを読む

2017 アジャイル事業部 年始のご挨拶の会を開催しました

あけましておめでとうございます。

はじめまして。当日はLTのドラを叩いた @color_boxです。

2017/01/11に永和システムマネジメント東京支社にてアジャイル事業部の年始のご挨拶の会を開催しました。

esminc.connpass.com

続きを読む

2017 アジャイル事業部 年始のご挨拶の会のご案内

f:id:E_Mattsan:20161213093204p:plain

2016 年も残すところ半月あまりとなりました。インフルエンザも流行の気配を見せています。みなさんもお気をつけてください。

そんな年の瀬ですが、アジャイル事業部で来年のカレンダーを作りました。1月から12月までひとりひと月ずつ、ソフトウェア開発にまつわるテーマのエピソードを載せています。

そこで年明けの1月11日(水)、年始のご挨拶として各月を担当したメンバーによるLTを行うことにいたしました。簡単な軽食とお飲み物をご用意しますのでご来場いただき楽しい時間をお過ごしいただけたらと思います。 またご来場された方にはお年賀としてこちらのカレンダーをお渡しいたします。

ご参加を希望される方は申し込みページからご登録をお願いします。

皆様のご来場をお待ちしています。

f:id:E_Mattsan:20161213090537j:plain

勤怠ボタンのつくりかた

f:id:htkymtks:20161212180250j:plain

こんにちは。永和システムマネジメントの内角低め担当、はたけやまたかし( @htkymtks )です。

Amazon Dash Button に触発されて「勤怠ボタン」をつくってみたのでご紹介します。(↓こんなのです)

勤怠ボタンとは?

私の所属する永和システムマネジメントでは在宅勤務が認められています。部署ごとに在宅勤務の運用ルールは異なりますが、私の所属するアジャイル事業部では在宅勤務時の作業開始と終了の連絡を社内チャットツール「Idobata」 *1 へ投稿するルールになっています。

勤怠ボタンの「🏠」と「🔚」を押すことで作業開始と終了を Idobata へ投稿することができます。

f:id:htkymtks:20161212160458j:plain:w300

ハードウェア

勤怠ボタンはESPr DeveloperというWiFi接続可能な小さなマイコンを利用しています。ESPr Developerに載っているチップ「ESP8266」にはArduino開発環境が用意されているため、Arduino ライクな開発を行うことができます。

回路図

回路はこんな感じ。至ってシンプル。

f:id:htkymtks:20161213100644p:plain:w300

ブレッドボード上で配線するとこんな感じ。

f:id:htkymtks:20161213102135j:plain:w300

事前準備

事前に「Arduino IDEのセットアップ」と「ESPr DeveloperのArduino化」を行う必要があります。以下のサイトを参考にESPr DeveloperのArduino化を行いました。

以下のコードで14ピンに接続したLEDがチカチカすればOKです。

void setup() {
  pinMode(14, OUTPUT);
}

void loop() {
  digitalWrite(14, HIGH);
  delay(1000);
  digitalWrite(14, LOW);
  delay(1000);
}

ソフトウェア

以下が勤怠ボタンのソースコードです。

  • 接続するWiFiSSID
  • 接続するWiFiのパスワード
  • Idobataの認証トークン(取得方法は後述)
  • 投稿先のルームID(取得方法は後述)

を設定して、Arduino IDEからESPr Developerへ書き込みます。

loopの中で12ピンと13ピンの値を監視し続け、13ピンにつながった「🏠」ボタンが押された場合は「:house:」が、12ピンにつながった「🔚」ボタンが押された場合は「:end:」が Idobata へと投稿されます。

#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>

// WiFi SSID & Password
const char* ssid = "<Your WiFi SSID>";
const char* password = "<Your WiFi Password>";

// サーバ証明書のフィンガープリント
String fingerprint = "DC 0B 75 2D 66 75 42 65 AC 6D 68 C5 53 59 A4 25 E9 12 87 C2";

// 認証トークン
// curl -X POST -H "Content-type: application/json" -d '{"grant_type":"password", "username":"<Your email>", "password":"<Your password>" }' https://idobata.io/oauth/token | cut -b17-82
String authToken = "<Your auth token>";

// 投稿先ルームID
String roomID = "<Your kintai room ID>";

void setup() {
  pinMode (12, INPUT_PULLUP);
  pinMode (13, INPUT_PULLUP);
  pinMode (14, OUTPUT);
  
  Serial.begin(115200);

  // Connect to WiFi
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.println("WiFi connected");
  piko(1);
}

void loop() {
  if (digitalRead(12) == LOW) {
    post(":end:");
    piko(3);
  }

  if (digitalRead(13) == LOW) {
    post(":house:");
    piko(2);
  }
}

// 指定した回数ピコっと光る
void piko(int n) {
  for (int i = 0; i < n; i++) {
    digitalWrite(14, HIGH);
    delay(100);
    digitalWrite(14, LOW);
    delay(100);
  }
}

void post(String message) {
    if (WiFi.status() == WL_CONNECTED) {
        HTTPClient http;
        http.begin("https://idobata.io/api/messages", fingerprint);
        http.addHeader("Content-Type", "application/json");
        http.addHeader("Authorization", "Bearer " + authToken);

        int code = http.POST("{\"message\":{\"source\":\"" + message + "\",\"room_id\":\"" + roomID + "\"}}");
        if (code > 0) {
          Serial.printf("ok: %d\n", code);
        } else {
          Serial.printf("error: %d\n", code);
        }
    }
}

SSLサーバ証明書のフィンガープリント

https 通信を行うためにサーバ証明書のフィンガープリントが必要です。ブラウザで https://idobata.io を開いて証明書の詳細を表示、「指紋 - SHA1」の値を使ってください。

f:id:htkymtks:20161212144546p:plain:w300

Idobataの認証トークン

Idobata へ投稿するためには、httpリクエストヘッダに認証トークンを付与する必要があります。ターミナル上で以下のコマンドを叩くと Idobata の認証トークンを取得できます。ソースコード中の authToken 変数へ取得した値をセットしてください。

$ curl -X POST -H "Content-type: application/json" -d '{"grant_type":"password", "username":"<Your email>", "password":"<Your password>" }' https://idobata.io/oauth/token | cut -b17-82

投稿するルームの ID

投稿するルームの ID は Idobata の「ROOM SETTINGS」から確認できます。ソースコード中の roomID 変数へ取得した値をセットしてください。

f:id:htkymtks:20161212153032p:plain:w300

ユニバーサル基板へ移植

ブレッドボード上で作成した回路をユニバーサル基板へ移植しました。

これが

f:id:htkymtks:20161213102135j:plain:w300

こうなりました。小さくてカッコイイですね。ちっちゃいは正義だ。

f:id:htkymtks:20161212180250j:plain:w500

最後に

以上、勤怠ボタンのつくりかたでした。

本当はAmazonDashButtonのガワだけでも使えないかなあと考えていたのですが、Dashのガワの再利用は思っていたよりも難しかったため基盤ムキ出しになっちゃいました。無念...。

また、今回はじめてESPr Developerを使ってみたのですが、小さくて安くてパワフルでお手軽な素晴らしいマイコンでした。ESPr Developer最高かよ。これからもESPr Developerを使ってIdobataと連携するボタンをいろいろと作りたいなあと考えております。はたけやま先生の次回作にご期待下さい!

パッチファイルの構造

TL;DR - patch(1) に渡すパッチファイルの最初の方には色々書ける。

こんにちは、hibariya です。これまで曖昧に理解していたパッチファイルのフォーマットについて調べました。たまに diff や git の出力するパッチを patch コマンドで既存のファイルに適用する機会があります。git の吐くパッチというとこういうのです。

commit fc787cd3fc0b69526d8686e529e7574b5be9497c
Author: Hibariya <hibariya@gmail.com>
Date:   Tue Nov 8 18:49:32 2016 +0900

    Resolve all messages in advance

diff --git a/frontend/app/routes/stars.js b/frontend/app/routes/stars.js
index 80b476b..59e6947 100644
--- a/frontend/app/routes/stars.js
+++ b/frontend/app/routes/stars.js
@@ -21,11 +21,19 @@ let StarsRoute = Ember.Route.extend(MousetrapRoute, {
   },
 
   model({query}) {
+    let stars;
+
     if (query) {
(長いので以下略)

パッチファイルの先頭にあるもの

git show -p で出したパッチのはじめには、上のようにコミットの情報があります。これらの行は patch に渡す情報としては不要そうですが、そのままでも patch -p1 < patchfile と渡すと問題なく適用されます。

先頭の不要な情報は patch がいい感じに無視してくれているのでしょうか。気になります。手元のシェルで man 1 patch してみました。

patch tries to skip any leading garbage, apply the diff, and then skip any trailing garbage. Thus you could feed an article or message containing a diff listing to patch, and it should work.

なるほど、やはり不要な情報 (garbage) を無視してくれているんですね。だから英語や日本語でコメントを書いたりできる。実際にコメントが書かれている例を探してみたところ、Pure Data (extended) の Debian 向けパッチに見つけました。

Description: hard code to Debian's /usr/bin/wish8.5
 Force pd-gui.tcl to use /usr/bin/wish8.5 so that it always uses Tk 8.5
 regardless of how the 'wish' alternatives are setup.
Author: Hans-Christoph Steiner <hans@eds.org>

--- pd-extended-0.43.4.orig/pd/tcl/pd-gui.tcl   (revision 16941)
+++ pd-extended-0.43.4/pd/tcl/pd-gui.tcl        (working copy)
@@ -1,6 +1,6 @@
 #!/bin/sh
 # This line continues for Tcl, but is a single line for 'sh' \
-    exec wish "$0" -- ${1+"$@"}
+    exec /usr/bin/wish8.5 "$0" -- ${1+"$@"}
 # For information on usage and redistribution, and for a DISCLAIMER OF ALL
 # WARRANTIES, see the file, "LICENSE.txt," in this distribution.
 # Copyright (c) 1997-2009 Miller Puckette.

適用する目的を同じファイルに書けるのは便利そうです。

パッチの本体

ところで patch はどうやってパッチの本体を見分けているのでしょうか。ぱっと見、最初の空行で分かれているように見えますが、せっかくなので一応確認してみましょう。また man を見てみます。

patch takes a patch file patchfile containing a difference listing produced by the diff program and applies those differences to one or more original files, producing patched versions.

patch は diff の出力を受けとることを想定しているということなので、diff のフォーマットを見ると良さそうです。よく使う Unified Format の説明を見つけました。

The unified output format starts with a two-line header, which looks like this:

--- from-file from-file-modification-time
+++ to-file to-file-modification-time

Comparing and Merging Files: Detailed Unified

予想通り、この ---+++ で始まる行から先がパッチの本体でした。なるほどー。これで、これからはパッチがどこから始まるか一目で分かるし、心置きなくコメントが書けそうです。

おわりに

パッチファイルについて簡単に調べてみました。当たり前かもしれないし、使う頻度を考えると少しトリビアルかもしれない内容でしたが、いつかどこかでなにかのお役に立てばと思います。