@ledsun blog

無味の味は佳境に入らざればすなわち知れず

技術的負債の数え方

技術的負債の数え方に関する与太話。 落ちを先に書くと「シュレディンガーの猫」って言いたかっただけです。

技術的負債とは

Ward Cunningham 曰く

最初のコードを出荷することは、借金をしに行くことと同じである。
小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。
危険なのは、借金が返済されなかった場合である。

品質の良くないコードを使い続けることは借金の利息としてとらえることができる。
技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、
立ち尽くす羽目になる

技術的負債 - Wikipediaから引用

要約すると「汚いソースコードは後で直すのが大変。けど、拙速も大事」という話です。

数え方

「技術的負債が借金だとすれば、いくら借りているのか数えられるのでしょうか?」が今日のお題です。

技術的負債を観測する方法

Michael Feathers の話を聞いた安井力さん曰く、 これに対してこんな方法があるようです

機能見積りトレンド (Feature Trend Cards)

ある機能の実装にどのくらい時間がかかるか見積もる。
で、実装しない。定期的に同じ機能を見積もる。
もし見積りが大きくなっていたら、それは負債が増えているということだ。

リファクタリングしてみる (Scratch Refactoring)

やりたいように大規模にリファクタリングをする。
でも保存しない(コミットしない)し、動かなくてもいい。
どんな感じかつかむためで、そこから情報を得る。

こちらはレガシーコード改善ガイドに載っているそうです。

これらの方法に対する疑問は

  • 「機能追加」や「リファクタリング」は実際に起こるのでしょうか?
  • いつまでも見積もれる「機能」は追加しなくてよいのではないでしょうか?

変更しないと技術的負債は観測できない

例えば、インデントが揃っていない、変数名が連番のソースコードがあったとします。

  • 変更を設定で吸収できた場合は、技術的負債は見つかるでしょうか?
  • ソフトウェアが変更されなかったら、技術的負債は見つかるでしょうか?

ソフトウェアを変更してみるまでは、技術的負債は観測できません。

技術的負債はシュレディンガーの猫である

シュレディンガーの猫とは

この実験で箱のなかの猫は、放射性物質のアルファ崩壊という量子力学的な振る舞いにのみ生死が
決定するため、観測者が箱を開けて中を観測しない限り、猫は 量子力学のウィグナーらが唱えた
確率的解釈により生きている猫と死んでいる猫が50:50で重ね合わせで存在している事になる。

つまり箱の中の猫はふたを開けて観測するまで、生きてもいないし死んでもいないのである

シュレーディンガーの猫とは (シュレーディンガーノネコとは) [単語記事] - ニコニコ大百科から引用

技術的負債は、この「シュレディンガーの猫」のような存在に思えます。 変更を加える前は「技術的負債」は有りも無くもしないのです。

「技術的負債」が問題になるソフトウェアの変更は予想できません。 「予想出来る変更」は設定で吸収できるようソフトウェアを設計すれば対応できます。 「技術的負債」は問題になりません。

「技術的負債」は予想できない変更に依存します。 変更を加える前は「技術的負債」は「有る」と「無い」が重なりあった状態です。 変更を開始して「技術的負債」が観測された時に状態が収束します。

この仮説が成り立つなら、量子の観測と同じ方法で定量的に評価できそうです。

量子の観測方法を借りてくる

ソースコードは技術的負債は持たず、技術的負債を発する能力「技術的負債能」を持つと考えます。 *1

具体的には、イテレーション中に「技術的負債」を発見したらカウントアップします。 あるイテレーションでは技術的負債が30発見され、別のイテレーションでは100発見されます。 発見数をグラフ化すればトレンドを見ることができます。 *2

ボウリングの観測方法を借りてくる

イテレーション毎に変更内容は変わります。 イテレーション毎に発見する「技術的負債」数も変わります。 どうすれば異なるイテレーションの「技術的負債」数を比較できるでしょうか?

ボウリングでは、レーンとの相性や体調の変化により1ゲームのスコアに変動があります。 レベルの異なるプレイヤーを集めて大会を開くにはハンディキャップの設定が必要です。 一般的な大会では、ある程度公平なハンディキャップを決めために、 30ゲームのスコアの平均を使っています。 つまり30ゲームのスコアの移動平均でプレイヤーの能力を測っています。

これを真似て、30イテレーション移動平均を取れば有効な数値が取れそうです。

技術的負債にはビジネスが含まれている

この値にはビジネス価値に依る変更箇所の偏り、 ビジネス環境の変化による変更箇所の変動も含まれているはずです。

まとめ?

「技術的負債」はソースコードの属性ではありません。 チームの属性です。 また、ただの技術力の指標ではなくビジネスの予測力を含みます。

*1:放射線放射能のメタファーです。

*2:簡単に書いていますが、変更時にはたいてい技術的負債が見つかります。発見数は単にストーリー数やストーリーポイント数になりそうな気がします。

グーグルカレンダーに予定を追加するURLを作るライブラリを作りました

Node.jsとブラウザどちらでも動くように作ってあります。

作った理由

Google Chrome拡張で使いたかった。探してもURLだけを作ってくれるライブラリがありませんでした。

URLは作ってくれるだけど、ボタンを作る機能は不要でした。

仕様メモ

作るにあたって公式仕様を調べたのですが、見つけられませんでした。 ぐぐって分かった情報を残しておきます。

終日予定(allday event)を作る方法を調べるのに苦労しました。

action(必須)

action=TEMPLATE

TEMPLATE固定です。

text

text=Garden%20Waste%20Collection

予定のタイトルです。 URLエンコードします。

空文字を指定すると(日本語の場合)無題の予定になります。

dates

dates=20090621T063000Z/20090621T080000Z

予定の開始と終了時刻です。 ISO日付フォーマットでUTCを指定します。 付けないと現在時刻から設定されます。

終日予定の場合は日付のみを指定します。

dates=20131208/20131209

ユーザーのタイムゾーンを使う場合はZをつけません

dates=20131208T160000/20131208T180000

location

location=Home

予定の場所です。 URLエンコードします。

details

details=Happy

予定の詳細です。 URLエンコードします。

参考リンク

stackoverflowです。

TDDについて

このライブラリはTDDで作りました。 TDDを採用した理由

  • Google Chrome拡張での動作確認はテンポが悪い
    1. Google Chrome拡張を読み直す
    2. ブラウザのタブを切り替える
    3. 対象サイトを読み直す
    4. ロード待ち
    5. 結果を確認
  • 入力データが限定されていた。作るGoogle Chrome拡張の仕様も大体決まっていた
  • 出力仕様が明快だった。迷ったらGoogleカレンダーが期待通りに動くURLにすれば良かった
  • コードのイメージはあった。詳細設計するのは面倒くさかった。三角測量したかった

ライブラリを作る時はTDDがいいですね。

power-assertについて

テストコードを書くのにt_wadaさん作の twada/power-assert · GitHub を使いました。

実に良いです。テストに失敗した時だけ、詳細な値を表示してくれるのはとても自然で、そして便利でした。 まるで、気の利いた執事とテストをしているようです。

power-assertは良いものです。次も使います。

参考図書

テスト駆動JavaScript サーバサイドJavaScript Node.js入門 実践Node.js プログラミング

東京Node学園祭2014に参加しました #nodefest

東京Node学園祭2014に参加しました。

nodeschool in Japan

maxwell ogdenによるNode.jsのワークショップの日本出張版。 Nodeschool Tokyoに大体の内容が書いてある。

maxogden/levelmeup-jp · GitHub をやってみました。

  • levelmeup-jpコマンドでターミナル上に問題とチュートリアルを表示
  • levelmeup-jp verify my_program.jsで、作ったプログラムが正しいか評価してくれます

このバランスは新鮮です。社内研修に使えるかもしれません。

内容は非同期IOに慣れなくて、結果が取れる前に表示しようとしたり苦労しました。

基調講演

Socket.ioの作者、Guillermo Rauchの基調講演。 partyというブラウザからのファイルをアップロードするためのフレームワークの紹介です。

bittorrentっぽくファイルをチャンクに分けてアップロードする。 帯域を有効に使えるしresumeもできる。 File APIでファイル情報取ったり、XHR2を使って進捗取ったりしているらしい。

テストサイトで動いているのが見れます。 まだ、開発中でソースはAutomattic · GitHubで公開予定だそうです。

Guillermoの発表はFTPとかHTTPとか背景の説明がすごい丁寧。 最初に何の話をするのか教えて欲しいな・・・

What’s coming in Node, Express & LoopBack

StrongLoopのCEOによるLoopBackの紹介。 英語だったけど聞き取れるぐらいにゆっくりしゃべってくれたのがありがたかったです。

ツール類がすごかった

LoopBack自体はExpressベースのWeb APIフレームワークslcコマンドでyomenみたいにscaffoldできるそうです。 zoneはデバッギング用のツールで、この辺をしっかり作っているのがEnterprize向けにありがたい感じです。

APIを作りたくなったら使ってみようと思います。

すべてのノードトランスパイラーがひどい!ならば、ノードトランスパイラーをいかに改善できるか。

Martin Heideggerの発表。

ちょっと難しかった。「トランスパイラーの品質特性を定義する」話だと理解しました。

テスト用ライブラリ power-assert, その開発で学んだ npm モジュール設計の勘所

我らがt_wadaさんの発表

最近、power-assertを使ったので便利なのは知っていました。

講演を聞いて、感じてた以上に馴染んでいたっぽいとわかりました。 あまりにもしっくり動くので、便利さを軽視していた気がします。 このしっくり感はBrowserifyっぽいです。 assertion warはホントに終わるかもしれません。 *1

発表内容がsubstack pattern > UNIX哲学と突き進んで行くのがすばらしかった。

要チェックキーワード

  • concat-stream
  • esprima - estraverse -escodegen

オレオレ(C言語的な意味での)マクロが作れるってこと?ますますテストが大事になりそうです。

f:id:ledsun:20141116110216j:plain

ギャルでもゎかる node-webkit

upgrade_ayp氏によるnode-webkitの紹介。

序盤緊張してたけど、載ってくるとすごいエネルギーだった。 可愛いギャルなのに技術キーワードバリバリw。

mochaがCUIで動かないのでgulpで出力先変えるハックとか、ソースコードプロテクションのために読込みhookするとかアプローチが技術的すぎて、違和感との戦いが大変でした。

いま、社内システムの魔改造Chrome拡張でやっている。 ページ遷移があるとnode-webkitが良さそうなので、切り替えてみます。*2

※以前の発表資料です

その他のメモ

まとめ

Node.js勢は勢いに乗っています。

*1:assertion warは千日戦争(ワンサウザンドウォーズ)みたいな響きがあって良い

*2:いずれにしろDOMトラバースの辛みは変わらない

reduceでPromiseをつないでタイムライン実行する

Promiseとreduceを組み合わせたトリック。 適当な間を置いてイベント発行するstubを作る時に使いました。

指定時間後に処理を実行するPromiseを作ります。

var DelayPromise = function(delay, action) {
  return new Promise(function(resolve, reject) {
    setTimeout(function() {
      try {
        action();
        resolve();
      } catch (err) {
        reject(err);
      }
    }, delay);
  });
};

map/reduceでつなげて実行します。

[1, 2, 3].map(function(record) {
    // Promiseはnewすると実行します。前のPromise完了後に実行する関数を作ります。
    return function() {
      // 指定秒後に数字を表示します。
      return new DelayPromise(record * 1000, function() {
        console.log(record)
      });
    }
  })
  .reduce(function(prev, action) {
    // 順次実行するために各actionをthenで繋ぎます。
    return prev.then(action);
  }, Promise.resolve())
  .catch(function(err) {
    console.error(err, err.stack);
  });

1秒後に1が、それから2秒後に2が、それから3秒経って3が表示されます。

Mac OS X で Raspberry PiのOSイメージを焼く

Mac OS XMac に刺したSDカードにddコマンドを使ってOSイメージを焼く方法です。

OSイメージの入手

Downloads | Raspberry Piから好きなイメージをダウンロードします。 特にこだわりがなければ、サンプルが多いRASPBIANが良いと思います。

Download Zipをすると数時間掛かるので、面倒でもBitTorrentをインストールして、BitTorrent経由でダウンロードするのをオススメします。

SDカードの確認

SDカードのデバイス名を確認します。 SDカードをMacに刺し、ターミナルから次のコマンドを実行します。

diskutil list

次のような結果が表示されます。

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            250.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *374.6 MB   disk1
   1:        Apple_partition_map                         32.3 KB    disk1s1
   2:                  Apple_HFS Adobe Photoshop CC 2014 374.6 MB   disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *46.1 MB    disk2
   1:        Apple_partition_map                         32.3 KB    disk2s1
   2:                  Apple_HFS Bitcasa Installer       46.1 MB    disk2s2
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *8.0 GB     disk3
   1:                 DOS_FAT_32 NO NAME                 8.0 GB     disk3s1

Appleで始まるキーワードはOSで使っているデバイスです。 それ以外のデバイスが今回刺したSDカードです。 この例では/dev/disk3/です。

OSイメージを焼く

ddコマンドを使ってOSイメージを焼きます。

アンマウント

ddコマンドはマウントされているデバイスには実行できません。 一度アンマウントします。 指定するデバイス名はさきほど確認した/dev/disk3/です。

diskutil unmountDisk /dev/disk3 

焼く

ddコマンドでOSイメージを焼きます。

sudo dd if=2014-09-09-wheezy-raspbian.img of=/dev/rdisk3 bs=1m

完了まで6分掛かります。注意点がたくさんあります。

  • デバイス名を間違えるとMacのデータを壊せるので気をつけましょう
  • デバイス名にrを付けて/dev/rdisk3/にすると10倍速く焼けます
  • bs=1mオプションを付けると10倍速く焼けます

指定を間違えると、ものすごく時間が掛かるので気をつけましょう。

進捗確認

ddコマンドは実行中にCtrl + Tを押すと現在の進捗を表示します。

load: 1.00  cmd: dd 3056 uninterruptible 0.00u 1.31s
1935+0 records in
1934+0 records out
2027945984 bytes transferred in 258.285589 secs (7851565 bytes/sec)

2014-09-09-wheezy-raspbian.imgのファイルサイズは3276800000バイトです。 おおよその残り時間が推測できます。

動作確認

Raspberry PiをHDMIケーブルでモニタと繋ぎ、SDカードを刺して電源を入れてみましょう。 起動画面が表示されば成功です。

参考リンク

参考書籍

Raspberry Piユーザーガイド 第2版 ラズパイマガジン (日経BPパソコンベストムック)

Raspberry piをMQTT 気温 publisherにするAnsible Playbookを公開しました

過去のBlogで手動でやっていたことをAnsible Playbookに書き起こしました。

変更点は?

  • 秘密情報(Sangoへの接続情報)をansible-vaultで隠蔽した
  • cron設定(15分に一回)を追加した

困ったこと

  • 電車の中や外出中はRaspberry Piの実機がなくて動作確認できなかった

次にやりたいこと

  • Raspberry Pi でMQTTで更新トピックを監視、メッセージが飛んで来たらansible-pull
  • Raspberry Pi を増やして、それぞれ別トピックにpublish。ansibleのrollを使ってトピック名を変数で指定する

とてか03にて発表してきました #toteka

咳マニアの集うイベント とてか03 にて発表してきました。 発表は「忍者式テスト」についてです。 忍者式テストは2004年頃に咳さんが発表されてから(咳さんチーム以外の)実施者が一人しか観測されていないテスト(開発?)手法です。

私が忍者式テストに取り組んだ経緯と、やってみてどうだったのかの感想をしゃべってきました。

MVCとかMVPとかしゃべるのはマニアックすぎないか、そしてマサカリが飛んでこないか恐かったです。 特に問題はありませんでした。

最強のIT系かあちゃんからたかしへのアドバイス知っている方が何人か居ました。 おほめいただき光栄です。

質問など

  • 何人で開発して忍者式テストは何人がやっているのですか?
    • 一人プロジェクトです。なので全員がテストしています。
  • テストを一周回すとどれぐらいの時間が掛かりますか?
    • バグが無ければ30分、見つけても1時間ぐらいで終わります。
  • テストを捨てるのに驚きました。
    • 一周が1時間を越えると、毎日できなくなるので頑張って減らしています。
  • なんで忍者式なんですか?
    • 忍者のジャンプ練習法からです。麻の苗を植えて毎日飛び越えるやつです。
    • 本当はタケカワユキヒデさんの英単語の学習法かららしいです。
  • そのTシャツはどこで売っていますか?
    • KUMAYAで買えます。
    • 当日は「つゆだく」ホワイトを着ていました。

感想レポート

とてかの感想

湯本さんの基調講演

「自分の作業手順(プロセス)をしらないと他人の手法をどこに入れていいか分からない」がぐっときた

いかつい

ぐっときた

  • ツイートを「すらっとしている」と形容
  • 人間は数字を追いかけるのが好き。79に行くと80にしたくなっちゃう
  • 漏れは認識の違い。使う人と作る人のズレ
  • テスト対象に詳しくないとフリーダムなテストができない
  • テストケースの上に目的を書いている
  • 開発者はいい加減な仕様から、ちょっと外れたケースを考えて設計している

ぞっとした

  • 一万回テストというものがある。30人で2,3日掛けてやる。再現しなかったらOK。再現できたら、「とりあえず直してみた」からもう一回。

Raspberry piからmqttcliでSangoに送信する

mqttcliのarmバイナリを作ってもらったので使ってみます。

インストール

Raspberry Pi にsshログインして実行します。

wget https://drone.io/github.com/shirou/mqttcli/files/artifacts/bin/linux_arm/mqttcli
chmod +x mqttcli 

実行

Raspberry Pi にsshログインして実行します。

export MQTT_HOST="lite.mqtt.shiguredo.jp"
export MQTT_PORT="1883"
export MQTT_USERNAME="ledsun@github"
export MQTT_PASSWORD="XXXX"
echo hoge | ./mqttcli pub -t "ledsun@github/temper" -s

※ 接続パスワードは伏せてあります。

確認

Mac OS Xから確認します。

export MQTT_HOST="lite.mqtt.shiguredo.jp"
export MQTT_PORT="1883"
export MQTT_USERNAME="ledsun@github"
export MQTT_PASSWORD="XXXX"
mqttcli sub -t "ledsun@github/temper"

Mac OS XでSubscribe中に Raspberry PiからPublishしてMac OS Xで以下が表示されました。

hoge

成功です。パチパチ

Raspberry piで計った温度をMQTTでSangoに送信する

構成

Raspberry Piの設定

2014-09-09-wheezy-raspbian.img を使ってRaspberry Piを起動してください。 Raspberry Piにsshでログインし、以下の作業を行います。

aptの設定

現時点でwolframに接続できません。削除しておきます。

sudo mv /etc/apt/sources.list.d/wolfram.list /etc/apt/sources.list.d/wolfram.disabled
sude apt-get update

temperのインストール

を参考にします。

sudo apt-get install gcc libusb-dev
git clone git://github.com/bitplane/temper.git
cd temper
make

実行

sudo temper/temper 
26-Sep-2014 14:58,44.412800

GMT時刻と現在の温度が表示されます。当然ですが、USB温度計を刺していないと表示されません。

※ Raspberry PiのUSBポートに直接刺すと、Raspberry Piに温められ40度を超えることがあります。

MQTT clientのインストール

Mosquitto Debian repository | Mosquitto の通りですが、クライアントだけをインストールします。

wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list
cd ~
sudo apt-get update
sudo apt-get install mosquitto-clients

publish

を参考にしてpublishします。次のようなコマンドになります。

sudo temper/temper | mosquitto_pub -h lite.mqtt.shiguredo.jp -u "ledsun@github" -t "ledsun@github/temper" -P XXXX -s

※ 接続パスワードは伏せてあります。

subscribe

Mac OS Xから確認します。

を参考にしてmqttcliを使います。

export MQTT_HOST="lite.mqtt.shiguredo.jp"
export MQTT_PORT="1883"
export MQTT_USERNAME="ledsun@github"
export MQTT_PASSWORD="XXXX"
mqttcli sub -t "ledsun@github/temper"

実行

Mac OS XでSubscribe中に Raspberry PiからPublishしてMac OS Xで以下のような表示がされれば成功です。

26-Sep-2014 15:26,29.368061

Ansibleを使ってRaspberry PiにNode.jsをインストールする

前提

2014-06-20-wheezy-raspbian.imgを使ってRaspberry Piが起動できていること。

ansibleをインストール

Mac ではHomebrewが使えます。

brew install ansible

設定ファイルを準備

hosts

[raspberry-pi]
192.168.0.54

IPアドレスを適切に設定します。

ansible.cfg

[defaults]
hostfile = hosts
remote_user = pi
ask_pass=True
transport = paramiko

ログインユーザーを適切に設定します。 ここでは初期値のpiを指定しています。

node.yml

---
- hosts: raspberry-pi
  tasks:
    - name: download dpkg
      get_url: url=http://node-arm.herokuapp.com/node_latest_armhf.deb dest=node_latest_armhf.deb

    - name: install dpkg
      apt: deb=./node_latest_armhf.deb
      sudo: true

実行

ansible-playbook node.yml

参考

crestとバグとpacage.json

MongoDBを外部プログラムから更新するのにREST APIがあると便利です。 Cordazar/crest · GitHubというアプリケーションを試してみました。 バグを踏みましたが、原因がわかりました。そういう話です。

npm installできない

npm install crest

エラーが起こります。

npm ERR! Error: ENOENT, chmod '/Users/shigerunakajima/node_modules/crest/bin/server'

この時点でよく考えればわかったのですが・・・

親切な罠

同じ問題がISSUEに上がっていました。

npm install exits with Error: ENOENT, chmod ... · Issue #1 · Cordazar/crest · GitHub しかもPullReqestまで!

これでインストールできる♪

npm install git+https://github.com/jasonnathan/crest.git

しかし・・・通らない!!! 同じエラーが起こります。

npm ERR! Error: ENOENT, chmod '/Users/shigerunakajima/node_modules/crest/bin/server'

バグは

冷静にエラーメッセージを見ます。 見つからずにエラーになっているファイルはserverです。 私が使いたいコマンドはcrestでした。

package.jsonを見てみましょう。

  "bin": {
    "server": "./bin/server"
  }

実行ファイルとして./bin/serverが指定されています。 binディレクトリに入っているのはcrestです。

確認

forkして、package.jsonを直します。

  "bin":  "./bin/crest"

インストールしてみましょう。

npm uninstall git+ssh://git@github.com:ledsun/crest.git

無事にインストールできました。

node_modules/crest/bin/crest
crest listening at http://0.0.0.0:3500

起動もできました!

参考

package.jsonの書き方はこちら。 npm package.json 日本語版 取扱説明書

永和さんの「価値創造契約」に思うこと

刺激を受けました。 個人的な思いを書きます 後出しじゃんけんです。 寝言です。

価値観

「初期費用が無料だから私たちは本気です」という価値観はあまり好きではありません。 「斉藤浩司@帯をギュっとね」メソッドや「苦しければ報われる欺瞞」に近いものを感じます。 お客にリスクを負ってもらって、それに報いる方がより本気のように感じます。

商売として

お金は商売の血液

1000万円の資金を全額、保証金としてロックするのは商売として考えると微妙です。 商売お金をお客様とそのお客様と自分たちと協力会社と・・・の間を血液のように流す活動のことです。 バッファとして30%ほどをプールするのは良いですが、100%プールするのはいけません。 脾臓に血液を貯めても全身に巡らなければ死んでしまいます。

*1

気が長い

2,3年続かないとペイしない契約で、 成り立つのはファンドや保険などの数百〜万契約を束ねられる商売だけです。 新規ビジネスとして始めるにはリスクがすこし大きいです。 資金ショートがこわいです。 多額の保証金が必要な理由でもあります。

チケット制

チケット制は契約はシンプルですが運用が面倒くさいです。

特にシステム担当者には辛いシステムです。 毎日チケット消化のネタを考える時間はないので、余らせがちです。 余らせると怒られると思います。

担当者がつく案件の場合は、 事前に数ヶ月程度の消化計画を立てる必要があります。 実施しながら消化計画を修正しながらすすめて行くと、アジャイルっぽくなります。

大きなマイルストーンは必要です。

経営者からの直接発注であれば細かい計画を立てなくてもマッチすると思います。 毎日チケット消化のネタを考える仕事なので。

このまま進むならお客さんを選ぶのがいいと思います

永和さんにはファンがいっぱい居ると思います。 そのうち一社か二社を、木下さんが「なにかあったら俺がケツ拭くから」と口説きましょう。 売上を立てて、オブジェクト倶楽部で事例発表してもらいましょう。 ここまで1年。 2年目に5社まで増やせれば、3年目ぐらいでギリギリ赤字ぐらいになると思います。

複数案件掛け持ちで、お客さんのチケット消化スケジュールを考慮しながら、 開発を進めていくのはめちゃくちゃしんどいです。 開発者がやめたくなるかもしれません*2

トントンが見えれば仕事として取り組めるので、 もう少し「仕組み化」できるかもしれません。 というか、そういうのを期待しています。

Try もし私がやるとしたら

今は業務委託でも受注できるので「アジャイルな受託開発のため」だけなら不要と思います。

「1/3人月しかお金が無いけど、作りながら考えたい」という需要はありそうに思います。 実装を伴う要件定義です。 そろそろ自社サービス開発以外の受託開発でもやってもいいかもしれません。 というわけでプランはSとSSに絞ります。 要件決定のインセンティブとして最大3ヶ月間など期間の制約がある方がいいかもしれません。

開発案件として立ち上がって1人/月以上の開発になれば普通の受託開発にします。 仕様をよく理解できているので開発者としてはやりやすいと思います。 会社としても得意な受託開発のリソースが生きるので良さそうです。

全てのステークホルダーが参加してインセプションデッキを作って、 夢のようなアジャイル受託開発ができるかもしれません。

*1:インカムゲイン原理主義者からすると株主をなめすぎと思います。 資本を預かって、商売して利益出して配当出すのが(インカムゲイン原理主義者的な)株式会社の本分です。 使わない資本を減らせば一株辺りの配当増えるじゃん。 余った資金を他の会社に出資したいです。 永和さんは非上場会社ですので余計なお世話ですね。 それでも資本金6000万円の15%と考えると大きなチャレンジです。 すごい会社です。

*2:私はチケット制は一社でこりました。

mowsのtestlingの動かし方

mowsのテスト方法が判明しました。

mowsのtestlingの実行方法

npm install -g testling

でインストール

testling -u

を実行、表示されたurlをFirefoxSafariで開くと通ります。 そしてPull Reqesutを修正しました。

npm testも実行し、テストが通ることも確認しています。

Google Chromeではエラーが出る

testling -uGoogle Chromeで開くとエラーが出ます。 これはどうしたらいいのだろう?Issueをあげればいいのかな?

mowsにPull Requestするなど

PullRequestを送る

mowsというWebSocketに対応したJavaScriptのMQTTクライアントがあります。

URLと認証情報を同時に設定してconnectすると、認証情報が無視されます。 修正するPullRequestを送っている話。 現在進行中です。

testlingへの対応

mcolinaさんはnodeconf.euに参加していたようで、しばらく反応がありませんでした。 関係ないけど、日本に来たら握手しに行く!

Fix connect URL with authentication. by ledsun · Pull Request #15 · mcollina/mows · GitHub

To check, you can run testling

と、コメントをいただきました。 対応しようとtestlingを設定するも上手く動かせない・・・

作業ログ

testlingと必要なツールをインストール。

npm install -g testling phantomjs browserify
node /usr/local/lib/node_modules/testling/node_modules/browser-launcher/example/detect.js

browserify test.js | testlingで実行してもtestlingで実行しても、テストが通らない。 もちろん修正前のコミットです。

そもそもtestlingの使い方がよくわかない。 質問を投げて今日の作業は終了にします。

MQTTのリアルタイムWebビューの実装など

活動記録の続き。完成していません。

sangoでconnectionが残る問題

  • WebSocket上だとkeepalive指定があってもsangoにconnectionが残ることがある
  • 次回deployで修正予定らしい
  • connect中にPCをスリープにしてネットワークを切断するか切り替えるかで発生した
  • 具体的には、電車の中でつないでて、電車降りて(スリープ)、家帰って(ネットワーク切り替え)Dashboard見たら起きてた
  • 一応beforeunloadイベントでdisconnectする実装を入れたけど、 ブラウザ閉じなくても起きるので、この問題には無意味だった。
  • 世のWebSocket対応MQTT Brokerは対応しているのだろうか?

疎通確認

  • PC上のmqttcliからsangoを通してブラウザでsubscribeしたメッセージを見るところまできた
  • -d付けるとBroker URI: %stcp://free.mqtt.shiguredo.jp:1883%sが余計に表示される
  • mqttcli/mqtt.go at master · shirou/mqttcli · GitHub のぱっと見では起きそうにないんだけどな・・・
  • 次はRaspberry Piからpublishしたい
  • goの環境を作らなくては

追記

  • mqttcli は修正済みでした
go get -u github.com/shirou/mqttcli
mqttcli pub -t "ledsun@github/test" -d -m "yoyo"

INFO[0000] Broker URI: tcp://free.mqtt.shiguredo.jp:1883 
INFO[0000] Connecting...                                
INFO[0000] Connected                                    
INFO[0000] Topic: ledsun@github/test                    
INFO[0000] Published
  • sangoも対応版をdeploy済み出そうです。
  • この対応の早さたるや!mowsはいつPull Requestに反応してくれるのだろう・・・