rst 备忘录鹅卵石
备忘录鹅卵石
pebble_memo.rst
===========
Pebble Memo
===========
Mac＆iphoneの場合の内容です。
TODO
======
* PebbleとJavaScript間でのメッセージ交換を色々試す。
* SETTINGSのページを作って、設定を保存できるようにする。window.localStorageがつかえる？
* JavaScriptから何かのWEB APIを叩いてアプリ側で反映される何かを試す。
* デザインガイドを読む。
ドキュメント
=============
* `Pebble Developer Guide <https://developer.getpebble.com/2/guides/>`_
開発方法
=========
1. SDKを使って自分でがんばる
2. `CloudPebble <https://cloudpebble.net/>` で作る。
いつもプログラムを作る人でなければ、 `CloudPebble <https://cloudpebble.net/>` を使のがよい。
SDKのインストール
==================
ターミナルを開いて実行::
curl -sSL http://developer.getpebble.com/install.sh | sh
こんなのが出たら成功::
========================================================
Results:
========================================================
Install of PebbleSDK-2.0.1 into /Users/daisuke/pebble-dev was successful!
You are using a non-standard shell (IE, not bash).
To get the 'pebble' command into your path, you'll need to add /Users/daisuke/pebble-dev/PebbleSDK-current/bin to your $PATH.
For reference: with bash, we would have done this by typing
echo export PATH='/Users/daisuke/pebble-dev/PebbleSDK-current/bin:$PATH' >> ~/.bash_profile
最後の方に書いてあるように、.bash_profileの最後か、適当なところにパスを設定する。::
echo export PATH='/Users/daisuke/pebble-dev/PebbleSDK-current/bin:$PATH' >> ~/.bash_profile
Hello World!
=============
* `Build your first Pebble app <https://developer.getpebble.com/2/getting-started/hello-world/>`_
::
pebble new-project hello_world
cd hello_world
pebble build
::
'build' finished successfully (0.514s)
アプリのインストール(iphone)
=============================
iphoneのPebbleアプリ経由でインストールをする。
（直接Bluetoothペアリングしてもできるっぽい）
* iphoneのWiFiをONにする
* 設定から下にスクロールして、Pebbleアプリを選択、DEVELOPERをオンにする。
* Pebbleアプリを開いて、下にあるDEVELOPERをオンにする。
* IPアドレスが書いてあるので、pebble installコマンドでインストールする。
::
pebble install --phone iphoneのIPアドレス
WiFi経由で接続するわけですが、試した環境ではWiFi経由ではできなかった。
そんな場合は、MacのWiFiのメニューからCreate Networkを選んで適当な名前でネットワークを作成し、iphone側がWiFiでそのネットワークに接続する。
そうすると、PebbleアプリのDEVELOPERのIPのところが変わるので、そっちのIPでインストールしてやるとできる。
また、::
export PEBBLE_PHONE=169.254.159.185
としておくと、::
pebble install
だけでインストールできる。
pebble コマンド
================
使いそうなやつ::
new-project 新しいプロジェクトを作成
build ビルド
clean ビルドファイルの削除
install アプリを時計にインストール
logs アプリのログを表示
repl pythonインタプリタを起動。
pebbleオブジェクトを使ってpebbleを操作できる。
screenshot スクリーンショットを撮る
pebble new-project
-------------------
新しくプロジェクトを作成するときに使う。
options::
--javascript javascriptのひな形ができる。
pebble build
--------------
ビルドする。
pebble clean
--------------
ビルドファイルの削除
pebble install
---------------
ビルドしたファイルをpebble watchにインストールする。
options::
--phone 対象のpebbleアプリがインストールされたスマホのipを指定する。環境変数の PEBBLE_PHONE に設定しておくと毎回していしなくてもよい。
--logs インストールしてログ表示する。
peble logs
-----------
アプリの中で出力したログを表示できる。
js::
console.log("hogehoge");
c::
APP_LOG(APP_LOG_LEVEL_DEBUG, "hogehoge");
pebble repl
-------------
pythonインタプリタを起動してその中でpebbleオブジェクトを操作できる。
これはいいね！
が、特に触ることもなさそう。
::
>>> see(pebble)
hash() help() repr()
str() .AutodetectDevice()
.app_log_disable() .app_log_enable()
.app_message_send_byte_array()
.app_message_send_int() .app_message_send_string()
.app_message_send_tuple() .app_message_send_uint()
.connect_via_lightblue() .connect_via_serial()
.connect_via_websocket() .current_running_uuid()
.describe_app_by_uuid() .disconnect() .dump_logs()
.endpoints .get_appbank_status()
.get_phone_info() .get_time()
.get_versions() .id .init_reader()
.install_app() .install_app_pebble_protocol()
.install_bundle_ws() .install_firmware()
.is_phone_info_available() .launcher_message()
.list_apps_by_uuid() .log_levels
.notification_email() .notification_sms() .ping()
.print_pbl_logs .register_endpoint() .remove_app()
.remove_app_by_uuid() .reset() .screenshot()
.set_nowplaying_metadata() .set_print_pbl_logs() .set_time()
.system_message()
例えば、時刻を見るときとか。
jst.py::
import datetime
class JST(datetime.tzinfo):
def utcoffset(self, dt):
return datetime.timedelta(hours=9)
def dst(self, dt):
return datetime.timedelta(0)
def tzname(self, dt):
return 'JST'
::
>>> import sys
>>> sys.path.append('jst.pyがあるディレクトリのパス')
>>> from jst import JST
>>> from datetime import datetime
>>> d = datetime.fromtimestamp(pebble.get_time(), JST())
>>> print d
2014-02-25 07:22:03
やっぱり使わなそう。
pebble screenshot
-------------------
アプリのスクリーンショットを撮る。いい感じ！
外部(?)との通信方法
====================
他の任意の情報が欲しい場合には通信する必要がある。
通信対象としては作れるのは、
* iOSのアプリ
* Androidのアプリ
* JavaScriptプログラム
となるのかな？
外部のサーバーと通信して何かするような処理はJavaScriptで十分な感じ。
スマホ側の情報、再生中の音楽やバッテリー情報など、はスマホアプリじゃないと取得できない感じですかね。せっかくJavascriptでかけるのであれば、Pebbleアプリ用のJSライブラリがほしいですね。そういうのを作れるのかは知りませんが・・・。
JavaScriptアプリ
================
`PebbleKit JavaScript Framework for Pebble OS <https://developer.getpebble.com/2/guides/javascript-guide.html>`_
javascriptのひな形
--------------------
javascriptのひな形付きでプロジェクト作成は次のようにする。::
pebble new-project --javascript sample1
メッセージ交換の仕様
---------------------
* Each message is a dictionary containing key-value pairs.
* Each key must be an integer.
* Values can be integers, strings or byte arrays. Values cannot be other dictionaries or arrays.
* The size of messages is limited to 124 bytes once transformed in binary format.
javascriptとpebble間のAppMessageの変換規則
* A Pebble AppMessage is a JavaScript object (also known as a hash or dictionary: {}). It must conform to the JSON specifications.
* Keys are strings of integers (JavaScript only allows key-valued strings)
* Values are either integers, strings or byte arrays.
* All integers will be transformed into 32 bits signed integers.
* Byte arrays in JavaScript are represented as an array of integers (for example: [ 0, 1, 2, 3, 4, 5] is a 6 bytes long byte-array). Each byte is in the range 0..255.
* When sending data, byte arrays can contain strings. For example: [ 0, 1, 2, “hello” , “01” ] is a 10 bytes long byte-array.
AppMessageのキー
-----------------
javascriptのキーとpebble側のキーを変換する定義をappinfo.jsonに記述する。::
"appKeys": {
"firstKey": 0,
"secondKey": 1
},
appKeysを設定しておくと、sendAppMessageのキーにfirstKeyを使えるようになる。::
Pebble.sendAppMessage({ "0": "A value" });
Pebble.sendAppMessage({ "firstKey": "A value" });
アプリ開始時イベント
---------------------
::
Pebble.addEventListener("ready",
function(e) {
console.log("JavaScript app ready and running!");
}
);
メッセージの送信
---------------------
::
var transactionId = Pebble.sendAppMessage( { "0": 42, "1": "String value" },
function(e) {
console.log("Successfully delivered message with transactionId="
+ e.data.transactionId);
},
function(e) {
console.log("Unable to deliver message with transactionId="
+ e.data.transactionId
+ " Error is: " + e.error.message);
}
);
メッセージの受信
-----------------
::
Pebble.addEventListener("appmessage",
function(e) {
console.log("Received message: " + e.payload);
}
);
Pebbleへの通知の送信
--------------------
::
Pebble.showSimpleNotificationOnPebble(title, text);
設定画面
--------
設定画面のサンプルはこれ `pebble-hacks/js-configure-demo <https://github.com/pebble-hacks/js-configure-demo>`_
設定画面を使えるようにするにはappinfo.jsonに設定する::
"capabilities": ["configurable"],
データの保存はwindow.localStorageを通して使える（未確認
`Persistent Storage for Pebble OS <https://developer.getpebble.com/2/guides/persistent-storage.html>`_
MY PEBBLE画面からSETTINGSをおした時、showConfigurationイベントが通知される。::
Pebble.addEventListener("showConfiguration",
function(e) {
console.log("showConfiguration");
});
この処理の中で、Pebble.openURL()を呼び出し、設定画面を開く。
設定が終わった場合には、次のURLをセットする::
window.location.href = "pebblejs://close#success"
coseが完了すると、webviewclosedが通知される::
Pebble.addEventListener("webviewclosed",
function(e) {
console.log("Configuration window returned: " + e.response);
}
);
pebblejs://close#successの#以降はwebviewclosedのe.responseとして返される。
もし、データを渡したい場合には、次のようにする::
window.location.href = "pebblejs://close#" + encodeURIComponent(JSON.stringify(configuration));
::
Pebble.addEventListener("webviewclosed",
function(e) {
var configuration = JSON.parse(decodeURIComponent(e.response));
console.log("Configuration window returned: ", JSON.stringify(configuration));
}
);
iOSアプリ
==========
iOS appからのメッセージ送信
------------------------------
* uuidをappinfo.jsonのuuidとあわせる。
UI Design
=========
* `Pebble Designer Guide <https://developer.getpebble.com/2/design/>`_
TIPS
=====
ディスプレイのサイズ
--------------------
:width: 144
:height: 168
加速度計
--------
Xが時計に向かって左右の動き。左に傾けるとマイナス、右に傾けるとプラス？
* accel_data: GPoint(0, 0) GSize(144, 10)
*rst dev_2011.rst
dev_2011.rst
#####################
継続開発のススメ 2011
#####################
:更新: 2013-02-06
:バージョン: 1.0.1
:作者: @voluntas
:URL: http://voluntas.github.com/
変更履歴
========
- 2013-02-06
- はてなブログから Gist へ移動
- はてな記法から reST に変更
概要
====
開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。
開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。
これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。
この文章は以下のような構成になってます。書き殴りですみません。
- バージョンの付け方
- ソースコード管理とリリース
- タスク駆動
- 環境方針
定義
====
いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。
- バージョン管理には git を採用しています。
- 開発というのはコードを書く事だけを指してはいません。
- ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。
- ライブラリは自身の開発とそれ以外があると思いますので、そこは明確的に分けていきます。
- プロダクトとはフレームワークやライブラリを使って作る何かです。
フレームワークのバージョンの付け方
==================================
バージョン番号の構成
--------------------
"1.2.10" のような 3 つの区分けによる付け方を採用しました。
それぞれ "メジャー.マイナー.リビジョン" と呼ぶことにしました。
:メジャー: 下位互換を考えない変更
:マイナー: 下位互換がある大幅な変更
:リビジョン: バグフィックスや下位互換のある小幅な変更
小幅か大幅かは明確にするのは難しいので、チームで判断するべきです。
繰り上がりは使いません。リビジョンがたとえ 5000 になってもマイナーに繰り上がることはありません。
バージョン番号による安定版/開発版
---------------------------------
良くあると思うのですが、マイナーの偶数を安定版、奇数を開発版と定義します。
2.1.10 は開発版、2.2.0 は安定版です。
プロダクトのバージョンの付け方
------------------------------
バージョン番号の構成はフレームワークと同様です。
バージョン番号によるリリース版と追従版
--------------------------------------
フレームワークが更新されたとしても「セキュリティや機能追加」がされないのであればプロダクトをあえてアップデートをする必要はありませんが、最新版のフレームワークに追従しておく必要はあります。もちろんそれがフレームワークではなくサードパーティのライブラリの一つに追従するのも必要でしょう。
マイナーの偶数を「リリース版」、奇数を「追従版(イイ名前が思いつかない)」とします。外にリリースするのは偶数番のみです。
バージョンの付け方のサンプル
----------------------------
:X プロダクト: バージョン 1.2.3
:Y プロダクト: バージョン 2.6.2
:B フレームワーク: 安定版 バージョン 2.2.1
:B フレームワーク: 開発版 バージョン 2.3.108
:C ライブラリ: バージョン 1.4.0
C ライブラリが 1.2.0 から 1.4.0 にバージョンアップしました。 C ライブラリは B フレームワークを構成するライブラリの一つです。まずここで B フレームワークを対応させます。Y プロダクトには次のリリースで使いたい機能が入っていることもあり、影響はありますが X プロダクトには影響はなかったとします。Y プロダクトはマイナーを上げてリリースしますが、X プロダクトは追従するだけです。
まず B フレームワークの開発版 2.3.109 にて C ライブラリバージョン 1.4.0 を対応させます。さらにフレームワークの安定版 2.4.0 をリリースまで持って行きます。
:X プロダクト: リリース バージョン 1.2.3
:X プロダクト: 追従 バージョン 1.3.1
:Y プロダクト: リリース バージョン 2.6.2
:Y プロダクト: 追従 バージョン 2.7.87
:B フレームワーク: 安定版 バージョン 2.4.0
:B フレームワーク: 開発版 バージョン 2.5.0
:C ライブラリ: バージョン 1.4.0
ここから X と Y のプロダクトのフレームワークアップデートを行っていきます。
X プロダクトには影響しないので 1.3.2 として追従アップデートを行います。Y プロダクトでは影響があるため 2.8.0 としてリリースします。
:X プロダクト: リリース バージョン 1.2.3
:X プロダクト: 追従 バージョン 1.3.2
:Y プロダクト: リリース バージョン 2.8.0
:B フレームワーク: 安定版 バージョン 2.4.0
:C ライブラリ: バージョン 1.4.0
結局の所はタイミングが重要です。追従バージョンからリリースバージョンへのリリースのサイクルは製品のタイプによって変わってくると思います。
バージョンについて
------------------
あまりバージョンの付け方をきっちり書いている資料とか無いので、色々なプロジェクトを参考にして考えてみました。なにか良い資料などがあれば教えて頂ければと思います。
バージョン管理とリリース
========================
上記のバージョンをつかったリリースをうまくやるためにも、バージョン管理システムは必須です。ここでは git と git の開発手法の一つである git-flow を使って説明していきます。
git-flow
--------
git-flow では develop というブランチが開発ブランチです。新機能は全て feature というブランチを使って開発します。
またリリースの際は release というブランチを切ります。バグフィックスなどは hotfix というブランチを切って開発します。
詳しいのは `git-flow 使ってみた`_ でどうぞ。
.. _git-flow 使ってみた: http://d.hatena.ne.jp/Voluntas/20101223/1293111549
git-flow を使った開発/ビルド/テスト/リリース
--------------------------------------------
新機能はとにかく feature ブランチを切って、単体テストまで書いたら develop ブランチにマージします。
::
git flow feature finish ブランチ名
jenkins や travis-ci や buildbot などで develop ブランチに対して自動ビルド/自動テストをしかけておきます。新機能がばしばし入る場所なので赤いことは多いと思いますが、できる限り青にするように心がけます。
feature ブランチに対しては「長生きしそう」な場合は CI にブランチを登録して自動ビルドしてもらうようにしましょう。
feature ブランチのマージがある程度貯まってきたら定期的に開発版のリリースをしておくと良いです。これは気分的なモノではありますが、なんとなく目安になります。
さて、安定版のリリースに向けて release ブランチを切りましょう。今の開発版が 1.1.x だとしたら 1.2.0 です。
この時、開発版と安定版の担当者を分ける事をオススメします。安定版リリース担当者は release ブランチをメインに触って develop の事は気にしないようにします。
開発版担当者は release ブランチから定期的に develop に対して merge や cherry-pick をするようにします。
::
git flow release finish ブランチ名
安定版リリース後、安定版を使ってプロダクトを開発していきますが、その際もし安定版のフレームワークにバグがあった場合は hotfix ブランチを使って安定版側を直すようにしましょう。develop ブランチでは既に直ったとしても、再度リリースするよりはコストが低いです。
::
git flow hotfix finish ブランチ名
基本的にはこのサイクルの繰り返しです
タスク駆動
==========
人間はとにかく忘れていきます、全員でタスクを共有できるようにしておくべきです。
github の issues や trac や redmine などを使って、気になったこと等、何でもイイから書き込むようにしましょう。
ただし「定期タスクレビュー」を行う事は必須です。これが無いとだんだんタスクが埋もれていって破綻します。
持っている課題をいかにタスクとして外に出せるかが重要になってきます。
タスクベースで仕事を依頼すると、仕事の負荷がわかりやすくなります。大事なのはできる限りタスクをこなさないで良いモノをリリースし続けるか、ということだと思います。
まぁ、難しいですが。
方針
====
環境を作っていて経験上これはいいな、って思ったことを箇条書きで書いてみます
- レビューはコミット後
- github 等を使えばコミットに対して突っ込みが入れやすくて、情報共有がしやすいです
- レビューして貰いたい相手に丸投げできます、レビューを待っている間、開発が止まるなんて時間の無駄です
- 単体テストと外部テストはリポジトリを切り離す
- 外部テストは「まったく別のシステム」として作るべきです
- 外部テストとはソースコードレイヤーでのテストではなく、API を実際に curl からたたくなどの外からのテストです
- フルテストは自前でやらないで、ビルドシステムに任せる
- 時間の無駄です。変更部分だけテストしたらさっさと push してしまいましょう
- コーディング規約は出来るだけ作っておく
- ルールはルールです、ある程度はちゃんと決めておいた方が開発してるときに悩みません
- 少人数で開発する
- 多くても 3 人程度な気がします、もちろん規模にもよります。これ以上多い場合は見通しが悪くなる気がします。
- テスターは専任で(むしろ一番偉いくらいの勢いで)
- 独立したテスター(特に負荷試験やセキュリティ試験に対して)を用意すべきです
- テストはとても難しいので「開発ついで」で出来る技術ではありません
- 週 1 程度の定期的なミーティングを行う
- 「仕様」の打ち合わせと課題を持ち合わせて出来るだけ短く終わらせるように心がける
- 課題を全員で話し合う場は絶対必要です
- 開発チームと製品チームは分ける
- 開発チームは develop ブランチと feature ブランチに注力させるべきです、そうしないと「新しい機能」を実装するのがおっくうになります
- 出来るだけメールを使わない
- 基本「顔を合わせての話し合い」をするべきです。メールは大きな変更が入ったときのアナウンス程度にしましょう
- タスクの共有等はタスクドリブンのところで出したツールで共有します
- 話し合いをする際は資料（テキストベース）を事前に git で共有しておきましょう
- 話し合いの結果はすぐに資料に起こしておくのがオススメです。とくに資料は１枚でそれを淡々と更新していくと良いです。日付毎とかに分けると管理がめんどくさくなります。
- コーディング規約は定期的に出来るだけ見直す
- ライブラリがアップデートしたら出来るだけ早めに対応して、検証する
色々書き出してみましたが、まだまだある気がします。皆さんが思うこれはやっとくべきというのがあれば是非教えて下さい
rst Trelloのススメ
Trelloのススメ
trello.rst
###################
Trello のススメ
###################
:更新: 2013-11-01
:バージョン: 0.0.1
:作者: @voluntas
:URL: http://voluntas.github.io/
概要
====
関わっている全てのプロジェクトが Trello を使っている。さらに大規模な Trello 運用に関わる機会を得たのでそこで得たノウハウをまとめることにした。
ただし、運用というのはそれぞれの組織にあったものを「探していく」べきものであり、さらに必要があれば「変化」していくものだと考えている。
つまり銀の弾丸なんて無い。これはまぁうまくいってるんじゃないか？という例である。
十人十色のタスク管理があって問題ないと思っている。
書き出し
========
- カレンダー機能はオンにする
- アサインされていないタスクを存在させない
- 期限が付いていないタスクをできる限り存在させない
- markdown を覚えて活用する
- タスク管理は運用が全て
- チャットを減らす
- 打ち合わせを減らす
- 明確にアサイン
- trello のボードは増やさない
- 出来るだけプロジェクト単位で増やす
- 組織単位であれば 部署〜課単位で止める
- 部署全体のボード、課単位のボード、あとは全てプロジェクト単位のボード
- 可能であれば課単位のリストでボードをできる限り増やさないようにする
- trello のカードのタスクは細かくしない
- 細かいタスクは全て checklist レベルに落とし込む
- 期限を付けたければチェックリストからカード化する
- リストはできる限りシンプルに (To Do, Doing, Waiting, Done, Pending) 程度にする
- To Do だけは「グルーピング」してもよい
- 「開発者 To Do 」と「デザイナー To Do 」のようなイメージ
- Doing は一つにして「今進行しているタスク」を見える形にする
- 出来ないカードは出来ない理由を書いて Done へ持っていく
- いつかやりたいならその旨をおいて To Do へ
- ただいつかやるはやらないので、本当に残しておきたい物だけ残す
- 管理を継続するには複雑にしない事が大事
- タスクの見える化が目的であって「人の管理が目的」ではないことを理解する
- 気持ちはカードにせず、コメントへ
- カードで議論しない F2F で議論する
- 複数人数での議論が必要な場合は「必要な人だけ」を招集する
- 偉い人専用リストを追加する (~ だけど聞きたいことある？) のようなもの
- わからないことはここに書いて、非同期にする
- 最長でも二日以内には回答するようにする
- 全てをプロジェクト単位で考える
レビュー
--------
- 週１のレビュー
- Done から Waiting 、 Doing へ上って「漏れタスク探すレビュー」を行う
- レビュー時間を決める
- To Do はレビューしない
- レビューは確認の場であって、議論の場では無い
- レビューは相談の場であって、議論の場では無い
- ボード事にレビューを行い「関係ない人」は参加しない
- 確認したいことは事前にコメントに書き残す
- To Do は各自レビューをするのでレビューしない
緊急タスク
----------
事前に To Do に存在するのでは無くいきなり Doing になるタスクというのが存在します。
それが緊急タスクです。緊急タスクは全てのタスクより優先順位を高くします。
このタスクによって他のタスクに影響が発生することも考えられるためあまりあって欲しくないタスクです。
ただ障害対応などの「対応しないとまずい」場合はこのタスクになります。
- 赤のラベルを使う
- 赤のラベルに「緊急対応」と書く
- Doing の一番上に置く
- その部門の責任者、主担当者、副担当者の 3 名をアサインする
- 時間事に経過をコメントに張っていく
- チャットでの対応であればチャットのログをベタベタ張っていく
かなり特別のタスクとして扱うことが重要です。