BotFramework で PomodoroBot をつくった

前回 に続き、BotFramework で作ったもの第二弾。
PomodoroBot を作成した。

Pomodoro Bot

使い方はサイト内の How To Use を参照。


訴求点

  • ギョームとプライベートなどで異なるプラットフォーム環境でも共通して使えるツールが欲しかった
  • Bot のインストールで済むので気軽


システム構成

pomodoro-bot

pomodoro-notification


まだまだなところ

  • タイマーの途中停止ができない
  • Heroku の再起動) でタイマーが止まる
    通知は来る
  • Heroku の deploy でもタイマーが止まる
    Deploy Hooks で止まった通知は来る


学び


感想

BotFramework 自体は C# or Node.js だが、FormFlow は今のところ C# でしか実装されてない。
これを渡すだけでポモドーロタイマーを作成するウィザードにしてくれるんだからありがたい。

[Serializable]
public class PomodoroTimer
{
    public const string DescName = "name";
    public const string DescDuration = "duration minutes";
    public const string DescShortBreak = "short break minutes";
    public const string DescLongBreakSpan = "long break span";
    public const string DescLongBreak = "long break minutes";

    [Describe(DescName)]
    public string Name { get; set; }

    [Describe(DescDuration)]
    [Numeric(5, 60)]
    public int Duration { get; set; }

    [Describe(DescShortBreak)]
    [Numeric(1, 20)]
    public int ShortBreak { get; set; }

    [Describe(DescLongBreakSpan)]
    [Numeric(2, 10)]
    public int LongBreakSpan { get; set; }

    [Describe(DescLongBreak)]
    [Numeric(5, 60)]
    public int LongBreak { get; set; }
}


Bot 開発は機械学習に踏み入れなければそこまで難易度は高くない。
アプリのように UI がないのが大きい。
システム全体の構成を考えるアーキテクト視点のスキルが必要に感じた。
フルスタック、というか広く浅いスキルセットを持っている僕みたいな人にマッチしてる。


アジャイルな時間管理術 ポモドーロテクニック入門

アジャイルな時間管理術 ポモドーロテクニック入門

BotFramework で遊んだ

BotFramework とは?

BotFrameworkMicrosoft が発表した Bot 作成の仕組み。
公式ドキュメント にあるように、BotConnector と BotBuilder (と詳細が明らかになっていないBotDirectory) で構成されている。


BotConnector

BotConnector は Bot のO/R マッパーみたいなもの。
日本で使えそうなチャットサービスは、Skype, Slack, SMS, EMail, WebChat あたり。
LINE 対応してないのが惜しいけど、上のラインアップを見る限りビジネス向けの Bot を作ることになるんだろう。


BotBuilder

対話式で bot とやり取りするためのライブラリ。
Web ページの Form を置き換えるものだと思ってる。


何ができるか

ひとまず BotConnector を見て思いついたものをつくった。
チャンネルをまたいでチャットをするサービス。

ChatBridge

試すとわかるが、相手に ID を教える必要があり、それをチャットで送りたくなる。
ということで今ひとつ使い勝手がよくない。
ソースも公開しておく。

github.com


BotFramework の課題

試して気付いた課題や注意点がいくつかある。

Skype

  • Skype Bot の申し込みは申し込みから利用開始まで8時間くらいかかった
  • 現在の対応プラットフォームは Windows, Android, iOS で、Mac は未対応。(Web 版は未確認)


Slack

  • MessagesExtensions 経由のメッセージ送信はユーザIdのメンションがついてしまう。
    f:id:khei-fuji:20160423181711p:plain
    Reply の場合は問題ない。
    [2016/05/05 9:28 追記] 上記現象は発生しなくなっている模様。


最後に

デモにあったようなピザを注文するとかの利用はわかりやすいが、Bot のサービス提供のみでビジネスになるのかなって気がしている。
Web ページと違って広告も入れづらいだろうし。
マネタイズがよくわからない。

Web ページでやってることを Bot にただ持ち込むのではスマートウォッチと同じことになる。
でも Bot はスマートウォッチや IoT よりも来る可能性があると予想されていて、僕もけっこうそうかもしれないと思っている。
果たしてどうなるか。


世界トップ企業のAI戦略

世界トップ企業のAI戦略


出不精ITエンジニアの自宅トレーニング環境が整った

昨年エアロバイクを購入し 、最初の1ヶ月は毎日のように使っていたものの、だんだんと頻度が下がっていた。
GitHub でいえば草が生えてない状態だ。


エアロバイク漕ぎながらスプラトゥーンするとか、PodCast 聴きながらとか、いろいろ試してみたもののハマるものがなく、くすぶっていた。
なお、漕ぎながらスプラトゥーンするとウデマエが下がる。


そんななか、今までで一番ハマった感触を得たので書く。
先日購入した iPad mini 4 が残りのピースを埋めてくれた。


f:id:khei-fuji:20160412214105p:plain


エアロバイクを漕ぎながら iPad mini で動画を観る。
これは革命的だ。
正面に TV やディスプレイを置くのが一番いいかもしれないが、程よいサイズで没入感が得られる iPad mini は自分にとってはちょうどいいデバイスだった。


ちなみに写真でハンドル左側についているのは iPhone を設置していた残骸。
やはり iPhone で動画を見るのは小さすぎる。


iPad miniタブレットスタンドで固定している。
タブレットスタンドは Amazon で検索上位のもの。


安定感はバツグン。
しかし当時(4/2)は ¥1,580 だったのに今見ると高い。
ブラックではないからかも。


ということで、普段からアニメやドラマなどの動画を観る習慣がある人は、エアロバイクを買って動画視聴時間≒運動時間 という図式をつくると健康的になれる、かもしれない。



Hello iPad mini 4

昨日 WiiU が思っていたよりも高く売れたので、iPad mini 4 16GB ゴールドを購入した。


発送の段ボールがあまりに小さくて別のものが届いたかと思った。



周囲にサイズ比較できるものないと iPad かわからないことに気づく。



用途


葛藤


16GB の容量について


最後に

これで dアニメストアと Hulu の生活が捗りそうだ。



iPad mini 4 Wi-Fiモデル MK6L2J/A (16GB・ゴールド)

iPad mini 4 Wi-Fiモデル MK6L2J/A (16GB・ゴールド)

WiiUとスプラトゥーンなどを買取してもらってきた

2015/6 にやっていたAmazonWiiUとスプラトゥーンのセット¥1,500割引セール。
そのときの購入から9カ月。

今はもう惰性で遊んでしまうので買取してもらってきた。
買取は地元のゲオに依頼。

WiiU本体は初期化と掃除済み。
そういえばWiiリモコンや付属のマリオカートは一切触らなかった。

買取価格

カッコ内は購入時の価格。


ざっくり、¥42,000 払って ¥36,000 返ってきた。
プレイ時間見ておくの忘れたけど、ゼノブレイドはエンディング時点で100時間だったし、スプラトゥーンはそれより少ないはずがない。
9カ月十分遊んでこれだけ戻ってくるのはかなりコスパのいい買い物だったのではないか。


スプラトゥーン from:kheiakiyama - Twitter Search

またこういうお祭りに参加したいな。

Splatoon (スプラトゥーン)

Splatoon (スプラトゥーン)


翔泳社のセールやってたので衝動買い

セールしてる!

www.shoeisha.co.jp


最近 Kindle 読んでないけど衝動買いした。
時間があるときに読んでみよう。
以下、買った本。


TCP/IPの絵本 ネットワークが面白くなる9つの扉

TCP/IPの絵本 ネットワークが面白くなる9つの扉

イノベーションのジレンマ 増補改訂版 Harvard business school press

イノベーションのジレンマ 増補改訂版 Harvard business school press

あなたのチームは、機能してますか?

あなたのチームは、機能してますか?

新エバンジェリスト養成講座

新エバンジェリスト養成講座

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

というアフィ記事。

初心者と PullRequest 駆動開発

Web界隈からすると今さらに見えるかもしれない。
職場で PullRequest 駆動開発に近い状況を作れないだろうか、と一部のプロジェクトで検証したり、広めたりしている。


まず言えるのはこれで効率が何倍にも高まるわけではないということ。
細切れの時間でもパフォーマンスが下がりづらくなるというのが効果だと思う。
いくつかのシステムを横断的に見る役割を担っているが、1日の中でシステムを行ったり来たりするとしんどい。
この、いわゆるコンテキストスイッチが緩和される。
リモートワークでもこれは顕著。たまの出張でもあまり差が出ない。


ここに挙げたメリットは、今の自分ならそれなりに感じられる。
しかし初心者にとっては正直効率がよくない。


それは PullRequest を送るまでの流れにある。
おおまかに分解すると以下のとおり。

  1. 期待結果を検討する
  2. テストを書く
  3. 実装する


そこそこの開発者であれば、これらの作業中に誰かに相談することは1回くらいで済むだろう。(もちろん規模にもよる)
これが初心者の場合は5, 6回と何度も手戻ることがありえる。
PullRequest を上げるころには、周囲の開発者がレビューを見なくとも内容をすべて理解しているということもざらだ。
初心者が多いチームでは手間を増やしてしまうだけに過ぎない。
ペアプロなどもっと密に作業して、早く「そこそこの開発者」になってもらうことを目指したほうがお互いのためだ。


まとめよう。
どのような状況であれば PullRequest 駆動開発が効果を発揮するか。
チーム内にそこそこの開発者が揃っていること。
細切れの時間が発生しやすい開発者が多いこと。


もちろん作業がワークフロー化されて理解しやすい、CI との相性がいい、といった効果もある。
しかし技術面に注目しすぎで、上にあげたような人の側面を忘れてはならないと思った。


GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

ピープルウエア 第3版

ピープルウエア 第3版