週休七日

趣味のこととか、技術のこととか、読書感想文とか

Ganacheで手軽にDappsを体験する

ERC20 Ethereum 技術

やること

今回はGanacheを利用して、昨日作成したスマートコントラクトをテストネットワーク上で動かしてみたいと思います。

luca3104.hatenablog.com

Ganacheとは

truffleframework.com

一言で言うとONE CLICK BLOCKCHAINです(!?)

ローカル環境にEthereumのテストネットワークを手軽に立ち上げることができます。

ダウンロード

f:id:luca3104:20180406090449p:plain ヘッダー右下にある、DOWNLOADボタンをクリックし、ダウンロードを開始します。

開く

アプリケーションを開始すると、以下のような画面になります。 f:id:luca3104:20180406091257p:plain 最初からテスト用に複数のアカウントと、それぞれ100ETHずつあることが確認できます。

ネットワークの確認

アプリケーション右上にある⚙ボタンをクリックし、設定画面を開きます。
設定画面内にサーバーの情報が書かれているのでメモします。
f:id:luca3104:20180406092914p:plain

デプロイの準備

前回の記事で作成したトークンのディレクトリに移動します。
ディレクトリ内にあるtruffle.jsを以下のようにします。

module.exports = {
  networks: {
    development: {
      host: '127.0.0.1',
      port: 7545,
      network_id: 5777
    }
  }
};

このtruffle.jsは接続するEthereumのネットワークに関する設定ファイルです。

デプロイする。

コマンドラインから以下を実行し、コントラクトコードをGanacheのネットワークにデプロイします。

truffle migrate --network development

すると以下のようになります。 f:id:luca3104:20180406165233g:plain

これでデプロイが完了です。 コントラクトをデプロイした際にETHが減ります。

コンソールを開く

以下のコマンドでコンソールを開きます。

truffle console --network development

送金

前回の記事同様、accounts[0]からaccounts[1]にに送金します。

truffle(development)> token.transfer(web3.eth.accounts[1], 10000e18)

無事送金ができました！

ETHが小数点以下二桁しか表示されていないのでわかりづらいですが、何回か送金すると、gathとしてETHが使用されていることがわかります。
f:id:luca3104:20180407150335g:plain

最後に

ネットワークを実際のEthereumに向けてデプロイすると実際にトークンが発行できます。
web3.jsを利用すると実際にコンソールで叩いていたコマンドがjsで実装できるのでアプリケーションが作れます！
github.com

何かいいアイデアが思いついたらDapps作ってみたいと思います！

ERC-20トークンを爆速で作ってみる

技術 ブロックチェーン ERC20 Ethereum

ERC-20とは

github.com

Ethereum上で発行できるトークンの標準規格です。

Truffle

truffleframework.com

トリュフです。
Ethereumのフレームワークで手軽にトークンが作れます。
まずはnpm経由でインストールします。

npm install -g truffle

次に任意のディレクトリ内でtruffleを初期化します。

truffle init

以下のように表示されたら成功です。
f:id:luca3104:20180404213327p:plain:w300

OpenZeppelin

github.com

OpenZeppelinはスマートコントラクトのフレームワークで手軽にスマートコントラクトを書くことができます。
OpenZeppelinのZeppelin Solidityを利用します。
まずはプロジェクト内でpackage.jsonを生成します。

npm init -f

次にモジュールをインストールします

npm install truffle-hdwallet-provider --save

これで準備は完了です。

solidityファイルの作成

token/contracts以下に.solのファイルを作成します。(今回はkj3104.sol)
f:id:luca3104:20180404230717p:plain:w400

zeppelin-solidity/contracts/examples/SimpleToken.solを参考に書いていきます。

pragma solidity ^0.4.18;

import "zeppelin-solidity/contracts/token/ERC20/StandardToken.sol";

contract kj3104 is StandardToken {
    string public constant name = "kj3104"; // 通貨の名前 Bitcoin, Ethereumなど
    string public constant symbol = "XKJ"; // 通貨シンボル BTC, ETHなど
    uint8 public constant decimals = 18; // 少数以下の桁数

    // migration時に初期発行量を決めれるようにする。
    function kj3104(uint256 _initialSupply) public {
      totalSupply_ = _initialSupply; 
      balances[msg.sender] = _initialSupply;
      Transfer(0x0, msg.sender, _initialSupply);
    }
}

これでコントラクトコードの完成です。
次にこのコードをコンパイルしましょう。
コマンドラインで以下を実行します。

truffle compile

すると、build/contracts以下にズラズラとファイルが生成されます。
今回作成したkj3014.solに対応するコンパイル後のファイルはkj3104.jsonです。
次にmigrationを書きます。
ファイル名は[数字]_[トークン名]_migration.jsとします。
今回は2_kj3104_migration.jsとなります。 初期化時に生成される1_initial_migration.jsを参考にして記述します。

const kj3104 = artifacts.require('./kj3104.sol')

module.exports = (deployer) => {
  const initialSupply = 1000000e18
  deployer.deploy(kj3104, initialSupply) 
}

これで完了です。

デプロイ

デプロイします。
今回はテストネット等は使わずにローカルでのみ動かします。
コマンドラインで以下を実行します。

truffle develop

するとアカウントとプライベートキー、ニーモニックが表示され、対話型のコンソールになります。
まずはmigrateと入力しましょう。
先程作成したmigrationファイルを利用してコントラクトコードをデプロイします。
これでデプロイの完了です。

コントラクトコードを編集後、または対話コンソール再起動後

migrateをすると以下のようなエラーが出てしまいます。

Error: Attempting to run transaction which calls a contract function, but recipient address 0x8cdaf0cd259887258bc13a92c0a6da92698644c0 is not a contract address

この場合はmigrate --resetと入力しましょう。

動かす

実際にコンソールから動かします。
まずはコントラクトを変数に入れます。

truffle(develop)> token = kj3104.at(kj3104.address)

こうすることで、 tokenから様々な情報が取れるようになります。

truffle(develop)> token.name()
'kj3104'

truffle(develop)> token.symbol()
'XKJ'

アカウント一覧はweb3.eth.accountsから取得できます。

truffle(develop)> web3.eth.accounts
[ '0x627306090abab3a6e1400e9345bc60c78a8bef57',
  '0xf17f52151ebef6c7334fad080c5704d77216b732',
  '0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef',
  '0x821aea9a577a9b44299b9c15c88cf3087f3b5544',
  '0x0d1d4e623d10f9fba5db95830f7d3839406c6af2',
  '0x2932b7a2355d6fecc4b5c0b6bd44cc31df247a2e',
  '0x2191ef87e392377ec08e7c08eb105ef5448eced5',
  '0x0f4f2ac550a1b4e2280d04c21cea7ebd822934b5',
  '0x6330a553fc93768f612722bb8c2ec78ac90b3bbc',
  '0x5aeda56215b167893e80b4fe645ba6d5bab767de' ]

最後に送金をします。
0x627306090abab3a6e1400e9345bc60c78a8bef57から0xf17f52151ebef6c7334fad080c5704d77216b732に100XKJを送金します。

truffle(develop)> token.transfer(web3.eth.accounts[1], 100e18)
{ tx: '0x58147cfec997910d11bdab81d79abc4573b4bf50e1cd6b14b281fc2fa5118a7b',
  receipt:
   { transactionHash: '0x58147cfec997910d11bdab81d79abc4573b4bf50e1cd6b14b281fc2fa5118a7b',
     transactionIndex: 0,
     blockHash: '0xa3c03f135dc87ffef92c58e303bc22975d7162e72b1399ea0c28f5d8024e4def',
     blockNumber: 5,
     gasUsed: 51925,
     cumulativeGasUsed: 51925,
     contractAddress: null,
     logs: [ [Object] ],
     status: '0x01',
     logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000010000008000000000000000000010000000080000000000000000000000000000000000000000000000000000000000000000010000000000000000000010000000000000000000000000000000000000000010000000002000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000000010000000000000' },
  logs:
   [ { logIndex: 0,
       transactionIndex: 0,
       transactionHash: '0x58147cfec997910d11bdab81d79abc4573b4bf50e1cd6b14b281fc2fa5118a7b',
       blockHash: '0xa3c03f135dc87ffef92c58e303bc22975d7162e72b1399ea0c28f5d8024e4def',
       blockNumber: 5,
       address: '0x345ca3e014aaf5dca488057592ee47305d9b3e10',
       type: 'mined',
       event: 'Transfer',
       args: [Object] } ] }

送金されているか残高を見ます。

truffle(develop)> token.balanceOf(web3.eth.accounts[0])
{ [String: '9.999e+23'] s: 1, e: 23, c: [ 9999000000 ] }

truffle(develop)> token.balanceOf(web3.eth.accounts[1])
{ [String: '100000000000000000000'] s: 1, e: 20, c: [ 1000000 ] }

これで送金ができました！

おまけ

中央銀行的な発想で追加発行ができるようにします。
コントラクトコードに、addTotalSupplyを追加し、totalSupply_及びownerの残高に追加します。
以下がコードです。

contract kj3104 is StandardToken {
    string public constant name = "kj3104"; // 通貨の名前 Bitcoin, Ethereumなど
    string public constant symbol = "XKJ"; // 通貨シンボル BTC, ETHなど
    uint8 public constant decimals = 18; // 少数以下の桁数

    address public owner; // オーナーのアドレスを初期化時に持つ

    function kj3104(uint256 _initialSupply) public {
      owner = msg.sender; // オーナーの代入

      totalSupply_ = _initialSupply;
      balances[msg.sender] = _initialSupply;
      Transfer(0x0, msg.sender, _initialSupply);
    }

    function addTotalSupply(uint256 _value) public {
      require(owner == msg.sender);  // オーナーでないと実行できない

      totalSupply_ += _value;
      balances[msg.sender] += _value;
  }
}

これで追加発行機能を実装できました。

最後に

Open Zeppelinは実は知らなくて前まで結構面倒くさいなあと思いながら書いてました。
ぜひ使ってみてください

これからトークンや仮想通貨、トークンエコノミーなど乱立する時代になってくると思います。
一時期流行ったVALUのような感覚で自分自身をトークン化して価値をつけるというのも面白いですね。

BitcoinがDouble Hashを利用している真意を突き止められない

技術 Bitcoin 暗号処理

TL;DR

Preimage attack対策ではない(はず)
length extension attack対策ではない(はず)
サトシ・ナカモトは心配性？

Bitcoin

f:id:luca3104:20180331215952p:plain ビットコインはもはや誰でも知っている存在になりましたね。
そんなBitcoinは全世界のマイナー達によるPoWによって成り立っています。

Double Hash

PoWのhash値計算のときに必要なhash関数はDouble Hashと呼ばれているSHA256dです。
SHA256の関数を２度呼んでいます。

SHA256(SHA256(m))

ここで疑問に思ったのが、なぜBitcoinでDouble Hashを利用する必要があるのか。ということです。
色々調べてみたのでここに書いていこうと思います。

Preimage attackの対策

これはないと思います。 Preimage attackは、hash(m) = hとなるようなメッセージmを求める攻撃方法です。
マイニングはそもそも、hash(hash(m))のメッセージmを求めるものなので・・・

length extension attackの対策

色々なところでこの件について議論されていますが、ほとんどの結論はlenght extension attackの対策だとしています。

bitmessage.org

crypto.stackexchange.com

length extension attackは以下のようなものです。
不明な値Unknownとメッセージmによるハッシュ値H(Unknown||m)とUnknownの長さが分かると、mに適当な文字列を追加した文字列m||m2について、Unknownを知ることなくH(Unknown||m||m2)を求めることができる攻撃

参考：CTF/Toolkit/HashPump - 電気通信大学MMA

しかし、これが目的であることが考えづらいです。
認証に対する対策であればわかりますが、nonceを求めるのがマイニングなので特に関係ないように見られます。

ちなみにこの攻撃は、下記のツールで試すことができます。

github.com

結局何なのか

検索しているうちに以下の本を見つけました

books.google.co.jp

この部分に書かれている、

I don't think Bitcoin ever uses hashes in a way that would suffer from length extensions, but I guess Satoshi went with the safe choice of preventing in everywhere.

サトシ・ナカモトは全ての場所の予防で安全を選択した。

🤔🤔🤔
そういうことなのか・・・
とにかく理由はなさそうです。

Merkle-Damgård construction

余談ですが先程のlength extension attackはMerkle-Damgård constructionで構築されているhash関数すべてで可能です。

違う構造で作られているSHA-3はこの攻撃が無効なようです。

Keccak Team

Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction. Instead, MAC computation can be performed by simply prepending the message with the key.

EthereumやNEMではSHA-3を利用しています。

結論

備えあれば憂いなしって感じでしょうか。
もうちょっと探ってみたいと思います🙇

OKRの本を読んだ

読書感想文 マネジメント

もともと概念としては知っていたけれど実践していなかったOKRの本(の翻訳本)が出たので読みました。

TL;DR

とにかくOKRを実践しよう
失敗を恐れるな 👊
早く導入したい

OKR本

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

Facebookでこの本についての投稿が多かったのでぜひ読みたいと思い購入しました。
ある程度のページ数ですが、物語形式の前半はスラスラと読めて、後半はノウハウをインプットしていく感じで楽しく読めました。

OKRとは

業績管理の一つのフレームワークです。
OはObjectives = 目標。
KRはKey Results = 主な結果です。

KPIとの違い

別のフレームワークとして、KGI・KPIは有名ですね。
自分も何度かKPIを作成して取り組んだことがあります。
全員のゴール(KGI)を決めて、中間目標を決めて、細かいタスクを作って・・・
やっていくうちに現場のプレイヤーは目標を達成するためではなく、自分のタスクを消化するのを目標になってしまいました。

OKRはCEOから従業員までが全員が目標を設定することに価値があると思います。
KPIでは会社のために働くという意識がどうしても大きくなってしまいますが、OKRでは全員が同じゴールに向かって働くという意識に変えられると感じました。

f:id:luca3104:20180331105731p:plain

OKRを導入する

本書にも書かれていますが、最初から全社全部門でOKRを導入するのは至難の業です。
まずは会社として、ゴールを共有することから始めましょう。
そして徐々に部門に広め、各プレイヤーに広めていき、全社で目的意識を持てるように作れるとものすごいいい環境ができますね。

OKRを作る

Oの設定

年間目標に対して・四半期目標に対してなど、期間を設けて作ります。
Oの内容は明確で定性的な目標です。
例えば立ち上げ時のITベンチャーであれば、サービスのMVPを開発しリリース、初期ユーザーを獲得する。とか良さそうですね。
この目標は野心的でも不可能ではない範囲で設定します。

KRの設定

KRは目標の達成度合いを判定するための定量的な指標です。
先程の例であれば、コンバージョン率○○％などが良さそうです。
KRは３つほど設定しましょう。 KRを決定したら横に自信度を追加します。0.0~1.0の間で定義します。 0は不可能。1.0は絶対に達成できる(もしくは、達成した)という感じでつけます。
自信度が変化したら随時更新していきます。 KRはできれば自信度0.5のものを設定しましょう！

最優先事項の共有

これはOKR本にあったやり方ですが、OKRとは別にその週にやるべき最重要事項をリスト化し、優先度をつけます。 毎週月曜日にその週のやるべき最重要事項のリストを作りましょう。
横に優先度をつけます。
フォーカスし5つ以内で収めましょう。
本には以下のように書かれています。

「ここでは、細かいことをいちいち知らせるのが目的じゃない。重要なこと、メンバーが手伝えること、あるいは少なくとも認識して置くべきことだけ書くんだ。みんながどれだけ一生懸命やってるかはわかってる。ただ、正しいことを確実にやれるようにしたいんだ。」

あくまで仕事してる自慢ではなくて、認識合わせに利用しましょう。

この最重要事項を決めるために毎週定例会を開催しましょう。

ウィン・セッション

毎週金曜日に成果物を見せ合う会を開催しましょう。
全員が参加し、とにかく見せられるものがあればなんでも見せ合いましょう。
このウィン・セッションはいくつものメリットが有るとOKR本で書かれています。

  1. メンバー自身が、特別な勝利のチームに属しているような気分になれる。
  2. 共有できるものをつくることが、チームにとっての楽しみになる。
  3. メンバーが勝利を求めるようになる。
  4. 会社が各部門の仕事に感謝しう、社員が日々何をしているのかを理解するようになる。

また、この会を開催するにあたって、ビールやお菓子など、飲食物を提供しましょう！

失敗を恐れてはいけない

OKR導入時には必ず失敗をします。
本書に何度も書かれているように、これはプロセスのせいではなく、最初から上手くいくのは滅多にないです。
こういった類のものは何度も何度も経験して、実になるものです。
導入時の失敗を恐れずに継続的に改善していきましょう ✊

導入したい

とりあえず私生活周りで自身のOKRを設定してみようかなと思います。

最後に

このOKRを導入してチームが出来上がるととても良い環境・文化の会社が出来上がりそうですね！
意識して取り組んでいきたいと思います

結婚式をした🎉

イベント ポエム

無事結婚式が終わりました。
記念に書きます 🎉🎉🎉

TL;DR

コミュニケーションを怠るな
タスク管理したほうが良い
達成感は半端ない f:id:luca3104:20180326150202j:plain

結婚

今年の1/1に入籍しました。
もともと結婚式をやろうという話はしてたものの、会場決定が1月。
しかも式は3月末というハードスケジュール
更に1月後半から2月頭まで新婚旅行という、まさに締切との闘いでした。 f:id:luca3104:20180326145642j:plain:w400

コミュニケーション

コミュニケーションを怠ってはいけません。
これは親とのコミュニケーション、来賓とのコミュニケーション、もちろん嫁とのコミュニケーションです。
怠ると大変なことになります 😨
f:id:luca3104:20180326150434p:plain:w400

タスク管理

仕事でマネジメントをやってるのですが、嫁とのタスクを全くと言っていいほど管理していませんでした。
大失態です。
本当にタスク管理をすることをおすすめします。
期限、担当者、状態を常に管理すべきです。
そしてデイリースタンドアップをすることで、毎日のタスク消化速度を把握しましょう。
嫁と二人なんだから家の壁に付箋でカンバンボードを作りましょう。
https://upload.wikimedia.org/wikipedia/commons/f/fb/Simple_Task_Kanban.jpg

達成感

なんだかんだ喧嘩をし、口論もし、親とも揉めますが、最後の達成感は半端ないです。
いろいろな人に手伝ってもらって完成した結婚式は最高の思い出になります。
完全に和装だけでやったのも大成功でした。
やはり日本の文化は良いですね。

最後に

皆様、本当にありがとうございます。

パーミッションドブロックチェーンでサービスを考える時に悩むこと

仕事 技術 ブロックチェーン

TL;DR

パーミッションドブロックチェーンはとても悩ましい

パーミッションドブロックチェーンについて

ブロックチェーンには2種類の考え方があります。
一つはBitcoinやEthereumのように誰でもネットワークに参加ができるパーミッションレスブロックチェーン。
もう一つが閉じられたネットワークで特定の参加者のみがいるパーミッションドブロックチェーンです。
さらにパーミッションドブロックチェーンには完全に一社で閉じたネットワークのプライベート型と、複数企業がネットワークを作るコンソーシアム型があります。 今回はパーミッションドブロックチェーンでサービス展開などしてきた経験上悩んできたことを羅列していきます。
オープンソースとしてHyperledger fabricやQuorumなど、販売商品としてmiyabiやmijinがあります。
f:id:luca3104:20180322104211p:plain

悩みどころ

透明性・信頼向上

よく、"ブロックチェーンを利用すると透明性が上がって信頼が上がるんでしょ？うちも使いたい" という言葉を耳にします。
これは誰に対しての信頼か。ということを考えないといけません。

信頼の対象

ユーザーが企業への信頼

これまで、ユーザーは一社に対して信頼をおいてサービスを利用しています。
これをブロックチェーンに変えたところで何も意味がありません。
結局管理している母体は一社となるからです。

内部不正対策への信頼

基本的に個人情報漏洩などは内部不正の可能性が高いです。
すべての行動を追えるパーミッションドブロックチェーンを使う意味が見えて来ると思います。

企業同士の信頼

企業同士で信頼度を増したい場合、コンソーシアム型であれば信頼度の向上に意味があります。
コンソーシアム型はお互いにノードを持ち、監視をし合うという閉じた世界の中でも非中央集権となるからです。

鍵管理

地域通貨などを開発するときに悩みどころとして"鍵管理を誰がするか"というものがあります。
基本的な考え方として、ユーザーが個人で所有するクライアント型か、取引所のように中央のサーバーで管理するサーバー型があります。
f:id:luca3104:20180322102826p:plain 仮想通貨オタクからすると"そりゃクライアント型でしょ"となりますが、サービスプロバイダーである以上、ここに関してはかなり悩みどころです。
これを解決するのは株式会社を超えた自律分散型組織みたいな世の中になって、全ての責任をユーザーに帰属させないと難しいです。

アカウントマイグレーション

一つ上の話にもつながってきますが、もしクライアント型の鍵管理を選択した場合、アカウントをどう引き継ぎするかと言うものを考慮する必要があります。
ここでSMSやメールなどを利用した認証を用いるのはとても危険と思っています。
それでは従来型のログインと変わらないため、あまりクライアント型にしている意味が無いためです。

リアル世界との乖離

パーミッションドブロックチェーンの一つのユースケースとして、サプライチェーンマネジメントなどがあります。
実際にあるユースケースとしては以下のものがあります。

jp.techcrunch.com

サプライチェーンマネジメント×ブロックチェーンは食の安全などにおいて絶大な影響は今後出てくると思っています。
しかし、そもそもブロックチェーンに書き込む時点で改竄が可能なため、そこまでの担保ができないという点が問題と感じています。
仮想通貨(ココではパーミッションドでの通貨)の転々流通は中央銀行となる組織が通貨発行をするので最初から偽装通貨の混入などはありえませんが、肉などは最初にトランザクションを発行する組織が様々なためです。
ブロックチェーンで管理したところで、リアル世界のトランザクションとブロックチェーン上のトランザクションとの整合性が取れるとは限りません。

スマートコントラクト

スマートコントラクトですべてを自動化したい人がたまにいます。
それ既存システムの自動化で良くないですか？

DR対策

当初、DR対策(Disaster Recovery, 災害復旧)が不要になる革命じゃんとか思ってました。
実際に色々触れていくごとに、もちろん部分的にDR対策が不要な箇所はありますが、結局サービス開発の上でAPサーバーが必要であったり、DBが必要になったり、外部サービス連携、旧システムとの外接など、複数の要因によって、あまりここのコストを下げることは難しいです。
ブロックチェーンは大きなデータ入れたら遅くなるから別途DB使おうとなるからです。

コンソーシアムを始める

コンソーシアムを始める上で"ジョイントベンチャーを作ろう"というのが多いです。
この決定にはかなりコストと時間がかかるもので、プロジェクトが進みづらくなってしまいます。
”誰が何%を持つのか” や ”知財の帰属先" などとても話し合わなければいけないことが多いからです。

最後に

かなり悩んでいます。
　　
パーミッションドブロックチェーンは本当に社会インフラを変えることができるのか。
この答え合わせは数年後にできると思います。
ある程度技術としては成熟してきて、ビジネスもレッドオーシャンになっています。
実際にユーザーが便利に使えるようになるのもまだまだ先の話でしょう。

Github IssueとTrelloをWebhookでつなぐ

技術 自動化

TL;DR

会社にTrelloを導入したのでGithub IssueとTrelloを連携してみた

経緯

会社でTrelloを導入しました。
もともと社内ではJIRAを使用していましたが、オーバースペック過ぎたため移行しました。(それと重い)
バグ報告などはGithub Issueを利用してるのでIssueが作られたらTrelloにカードが作成されるようにします。
ココではコードを書いて説明していくのではなく、やり方やTrello APIについて書いていきます。

コールバック先の設定

説明は省きますが、Webhookを受け取るコールバック先を設定します。
今回筆者は手軽にLambda x API Gatewayで構築しました。

GithubのPersonal access tokenの取得

Setting > Developer setting > Personal access token > Generate new tokenからGithub APIを使用するためのトークンを生成します。
Select scopesではリポジトリの情報を得るためにrepoにチェックを入れました。

f:id:luca3104:20180318105159p:plain

ちなみにこのトークンはOrganizationには無いです。会社で使うときも個人のアクセストークンが必要なので、可能であれば会社用にアカウントを作成しましょう。

認証

Github Webhookから呼び出される際にオープンなので認証をします。
HMACでヘッダーのX-Hub-Signatureを検証します。
f:id:luca3104:20180318172837p:plain Node.jsでは以下のように記述しました。

  const hmac = crypto.createHmac('sha1',{Private access token})
  hmac.update({受け取ったbody}, 'utf8')
  const signature = 'sha1=' + hmac.digest('hex')

TrelloのAPI tokenを取得する。

https://trello.com/app-key/
上記にアクセスし、APIキーを取得します。

f:id:luca3104:20180318173837p:plain:w400

キーの枠に書かれているものがAPIキーです。
次に下部にある Token をクリックします。
以下のような画面が表示されるので許可をクリックします。

f:id:luca3104:20180318173832p:plain:w400

すると以下のような画面が表示されるので下部(灰色で消してある部分)にあるAPI tokenをメモしておきます。

f:id:luca3104:20180318173826p:plain:w400

これで準備が完了です。

Webhookから呼び出されたらTrelloのAPIを叩く

TrelloのAPIを叩きます。 今回使用したAPIを紹介していく形で書きます。

ボードIDの取得

まず何をするにもボードIDが必要です。
個人のボードIDを取得するには/1/members/{username}/boardsを利用します。
組織を使ってる場合は/1/organization/{organization name}/boardsを利用します。
クエリーパラメータとして、?fields=id,name&key={APIキー}&token={APIトークン}を指定します。
今回はGithubリポジトリ名とボード名を同じにして、一致したらそのIDを使用するようにします。

ボードのリストIDの取得

カードを作成するリストを指定するためにリストIDが必要です。
リストIDを取得するには/1/boards/{ボードID}/listsを利用します。
クエリーパラメータは先程と同じものを指定します。

カードを作成する

IssueのActionを見て、openedの場合カードを作成します。
カードを作成するには/1/cardsにPOSTリクエストします。
パラメータは以下の通りです。

        const requestJSON = {
          name:'#' + ISSUE_NUMBER + ' ' +ISSUE_TITLE,
          desc: ISSUE_BODY,
          idList: {リストID},
          key: {APIキー},
          token: {APIトークン}
        }

今回、作成されたらBackLogリストに入るように条件分岐しています。

上記のAPIでGithub IssueからTrelloへのカードの作成ができます。
筆者は他にもIssueをcloseしたらDoneレーンに移動したり、Bugラベルが貼られたらBugレーンに移動したりする実装をしています。

Github Webhookの設定

Webhookを設定するリポジトリから、Setting > Webhooks > Add webhookにアクセスします。

Payload URLに先程コールバック先として設定したURLを入力します。
Secretには最初に取得したPrivate access tokenを設定します。
Which events would you like to trigger this webhook?はLet me select individual events.を選択し、IsuueとLabelsを選択します。
以下のようになります。
f:id:luca3104:20180318012931p:plain

最後に

TrelloのAPIドキュメントが読みづらくて少し苦戦しました。

Trelloからも連携したらめちゃくちゃ便利ですね(いつかやる)
みなさんも自動化に挑戦して会社の環境を良くしていきましょう！