投稿者「akin」のアーカイブ

初めてのIoT

akin｜2017年12月15日

開発よもやま

こんにちは、ランサーズ Advent Calendar 2017の15日目を担当します、akin.です。

年初から家でIoTを導入してから、ちょっとずつ便利になってきました。
何番煎じなのか分からないですが描かせて頂きました。

まだAmazon EchoやGoogle Homeなどのスマートスピーカーは導入していないのですが、
iPhoneのSiriとiPadのHomeKit連携を利用し、自宅サーバーとIRKitの組み合わせでIoT化しています。

IRKitとは

IRKitは赤外線の送受信を行えてWiFi接続をも備えている端末で、APIサーバーともなっています。
後継機のNature Remoも同様な仕様であり、他にも沢山センサーが付属されているそうです。

構成＆動き

iPhoneでSiriで声掛け又はHomeKitのアプリから操作
家のiPadがその情報をキャッチして家サーバーへPush
家サーバーがIRKitのAPIを叩くことで家電を操作

こういうリレーを行い操作をしています
そのため、Siriからスマートスピーカーに置き換えることや追加することもある程度簡単になっています。

また、IRKitはオープンソースなため、すっごく眩しい青ライトもコード書き換えでオフ状態にもできます。
自分はエラー時の赤ライト以外はオフ状態にしてあります。

color.setLedColor(0, 0, 1, false);

上記の数値部分がRGBのフラグになっていますので、全て0にするとオフ状態になります。
ただ、Remoに変えれば青ライトの眩しい部分も軽減できますのでそんなことをしなくてもよくなるかと思います。

サーバーのセットアップ

サーバーにはhomebridgeというHomeKitのエミュレートできるNodeJSサーバーになります。
homebridgeにはいろいろなPluginがあるため、今回はIRKitのPluginを利用してIRKitのAPIを叩いています。
※ 導入方法に関しては情報が沢山ありますので割愛します。

後はSiriに話しかけるだけ

後は家電の赤外線信号をhomebridgeに設定。
それが終わればiPhoneに「おはよう」や「おやすみ」など登録することで家電を操作できるようになります。

今後の予定

Nature Remoも手に入れていますので、今後人感センサー部分も開放されたらそちらに切り替える予定です。
一般販売されたのも10月ぐらい？ですので今後期待になりますね。

一昔前のやり方になりましたが、まだまだ現役で利用できるためご紹介させていただきました。

PHPカンファレンス2017 に登壇してきました

akin｜2017年10月10日

CakePHP

初めて登壇してきました、開発部のakin.です。

10月8日に開催されたPHPカンファレンス2017に25分枠で採択して頂き登壇してきました。
また、スポンサーとしてランサーズのブース出展も行いました。

(さらに…)

PHP向け簡易A/Bテストライブラリーを公開しました

akin｜2017年01月31日

PHP

誕生日にSNS上では祝われリアルでは誰にも祝われず翌日にカッとなってMAKAVELICのリュックを買ったプロダクト開発部のakin.です。

今回はプライベートでA/B/n テストを行えるPHP向けライブラリーを公開致しましたのでお知らせいたします。

どんなライブラリー？

使い方は簡単で、PHP5.3〜7.1まで利用できます。
導入に関してはcomposerを使いますので、

$ composer require dimgraycat/split-testing

これで完了です。
もしバージョンを指定した場合は composer.jsonに下記を追記し

{
    "require": {
        ...
        "dimgraycat/split-testing": "^1.0" // これを追記
    }
}

以下を実行します。

$ composer update

又は

$ php composer.phar update

使い方

<?php
use \Ab\SplitTesting;

$params = array(
    'use'       => 'random',
    'variation' => array(
        'foo',
        'bar',
        'miko'
    );
);

$result = SplitTesting::get($params);

こちらが一番簡単な方法です。
だたこれだと毎回ランダムに取得されます。
その為、結果を一定期間キャッシュするなどをするとより効果的に利用できます。
A/Bテストの種類として

ランダム方式
Rate(ルーレット)方式
パターンマッチ方式

の３種類用意しました。
ライブラリーはPackagistに公開していますのでご利用ください。
詳細に関してもそちらをご観覧して頂ければ幸いです。

A/Bテストとは

きっと何方もご存知ではあると思いますが改めて説明させていただきます。

簡単なA/Bテストの場合は異なる複数パターンを用意することによりユーザへ訴求効果を測る検証手法になります。
Webページの効果測定では

文言を複数パターン
ランディングページを複数パターン
フォームの項目数の違うパターン

などを一定期間複数パターンを表示させることでクリック数(コンバージョン)÷表示数(PV)からコンバージョン率を測定し、最も良いパターンを探し出す手法です。

ただ、１回のA/Bテストだけでは正しい効果を得られません。
そのため長期間に渡り測定を行い最適なパターンを探し出すことが良いでしょう。

最後に

ランサーズでもA/Bテストを導入しており紹介したライブラリーも一部利用しています。
~~次回以降ではA/Bテストに関して深掘りしていけたらと思います。~~

バーンダウンチャートでISSUEやPRを可視化

akin｜2016年12月23日

ツール／ライブラリ

この記事はランサーズ Advent Calendar 2016の２３日目です。

昨日夜の暴風雨で家が少し揺れたりして危機感を感じたプロダクト開発部のakin.です。

今年のAdvent Calendarも今日を含めあと３日！
今回は弊社Advent Calendar２日目のsayaさんで紹介されていたGoogleSpreadsheetの部分を具体的にご紹介できればと思います。

はじめに

現在GitHubのチケット駆動をカンバンとして可視化するためにwaffle.ioやZenHub等のツールを利用し検討を行っている段階です。

スプリント単位は上記のツールでMilestoneを設定することで見える化が行えると思います。
では、全体的にはどう動いているのか可視化するためにGoogle Spreadsheetを利用しツールを作成してみました。

以下の図の様にバーンダウンチャートとして可視化を行っています。

どんなシートなのか

説明の前に、前提として各ストーリーにストーリーポイント(SP)付けされており、1SPを1時間として置いていますがあくまで目安です。
SPはプランニングポーカーを利用しポイント付けを行います。

なぜ時間として置いているかというと実際の作業時間と絡めるためになります。
本来のSPはストーリーの規模や複雑さを測るものになり、時間にするのはあまりおすすめできません。

それでは具体的に説明へ
最初に行うことはプロダクトを進める前にストーリー出しとストーリーに対してのISSUEやPRを作成しポイント付けを行います。

この記事では今日のアドベントカレンダーを書くというプロダクトで進めたいと思います。
プロダクト内容からストーリーをざっくり出したのが以下のISSUEとSP(Estimate)になります。
このタイミングでGitHubのAPIでデータを取り出しSPの設定だけ行えるようになっています。

ポイント付けを行ったあとは各種設定をします

SPの合計を初期見積もりとして48を、1日に作業できるポイント(時間)を3とします。

今回は途中で2人に増員すると前提なため、作業人数を２に設定し1日総ベロシティ(時間)が６として算出されます。

あとはプロダクトの開始日や実装目処を記入します。
企画からの希望日とデータからエンジニア１人で頑張るとこの日になりますよという希望日を設定します。

そうすると、以下の図のようにバーンダウンチャートが出来上がります。

この時点で１人で記事を書くと12月28日になってしまいアドベントカレンダーなんて無かったことになってしまいますね。あるあるです。
内訳として消化SPと週間消化SPは棒グラフで、それ以外は折れ線グラフで表示されます。

消化SP：１日に消化したISSUEやPRの終了日(closed_at)から何ポイント消化したか
週間消化SP：金曜日時点で月曜日からの消化SPの合計
ガイドライン：１人で実装を行った場合の理想線
皆ガイドライン：１日総ベロシティからの理想線
残SP：消化SPからの実績線
作業PT：実際にプロダクトで作業したポイント(時間)

実際に開発を始めてから２日目(12月02日)には以下の図になります

残SPラインと作業PTラインの位置関係から作業PTが掛からず３SPを消化出来たようです。
※ 残SPラインより作業PTラインが下に行けば行くほどウナー状態です。

12月02日は金曜日で振り返りの日です。
KPT出しを行い次のスプリントに向けて盛り込む内容を決め、スパイクが打てるものはスパイクを打ちストーリーの分解を行います。

このタイミングで人員追加予定とスパイクを打ちISSUE４〜８が出てきました。
また、分解することによって「素材の準備」というISSUEのSPを0にし、
ISSUE４〜８へプランニングポーカーでポイント付けしました。
総SPが48SPから44SPに減った！

まぁそうですね。。。
「作業の準備」だけではふわっとしていてどんなストーリーなのか分かりません。
Milestoneも設定しておきましょう。次のスプリントではない時は後からでも大丈夫です！

12月09日の振り返り日

Milestone：準備_1

作業PTが一時的にウナー状態だったみたいですが、なんとかスケジュール通りにSPを消化しています。
次は助っ人にお手伝いをお願いして進めていくスプリントです。

12月16日の振り返り日

Milestone：準備_2

助っ人の方は想定SPより早い作業PTで終わったみたいですが、
頼んだ本人は怠けていて途中作業PTが下回っていますね。
でも、振り返り日には巻き返してる！

後はブログを書くだけです。
Milestoneも必要か微妙ですが「書く」を付けました。
12月22日までのスプリントになります。

12月22日の企画希望日

Milestone：書く

ウナーになりつつも12月21日には完成したようです。
なぜラインが０に行っていないのは最初に見積もった48SPから44SPへ減ってしまっているからです。

上記の図のように上手くいくケースですが、作業PTが下回りすぎてマイナス値に行く場合もあります。
その場合は見積もりの誤りや、直ぐスパイクを打ちストーリーの分解をして作業を分けるなりウナー状態を解消するためにも周へ相談をするか周りから声をかけることでウナー状態がどんどん深刻化しなくなるかと思います。

まとめ

今回のバーンダウンチャートには計画線がないため、追加しようと思いました。
振り返り時にウナー状態だったときに企画サイドへリリース時期をリスケする資料にもなります。
また、可視化することでエンジニアだけではなく企画側もある程度把握できるのではないかと思います。

それでは良いクリスマスを！

日々のスケジュール管理

akin｜2016年12月12日

開発よもやま

この記事はランサーズ Advent Calendar 2016の12日目です。

はじめまして、最近ニュースでFitbitがPebbleを買収することが確定してしょんぼりな
プロダクト開発部のakin.です。

今回はAdvent Calendarの場を借りて、ボクなりに日々のスケジュール管理をしている事をご紹介させていただきます。
その為、「この管理方法はちょっと自分に合わないなー」ということがあります。

はじめに

皆さんはどのようなツールを利用しでお仕事中のスケジュール管理を行っていますでしょうか。
例えば、Cybozu GaroonやGoogle Calendar, iPhone/Androidのリマインダー機能等がありますね。

(さらに…)