Shibuya.trac #13 - よりよい開発を目指して -

Shibuya.tracの第13回勉強会行ってきました。

立案企画の @tyobichiさん
発表者の @kanu_さん、@ikikkoさん、@kompiroさん
kompiroさんは遠路はるばるお疲れさまでした！
また、会場サポートスタッフの皆様、大変お世話になりました。

今回は、場所は日本橋のパソナエンジニアカフェさんをお借りしました。
あまりにおしゃれな建物で、しかも発表してる横に、
水耕栽培してるという、良い意味で面白く、凄い場所でしたw

目的として、よりよい開発を目指してと、かなりアバウトといえばアバウトなんですが
そこを目指すのがこのコミュニティなんで、それでいいかとも思います。
内容がタイトルに縛られないためか、おもしろいエントリがならんだのかなとか。

発表は

Scrumでやってみた
@kanu_さん

Jenkins実践入門の Next Step
@ikikkoさん

Kanban - お客さんの視点に立ったアジャイルなやり方 -
@kompiroさん

の三名でした。

LTで

パソナテック / エンジニアカフェのご紹介
パソナテック様

という4本だて2時間です。

開始が少し遅れて19:10からになってしまい
時間が押してしまったのが申し訳なかったです
（休憩時間をがっつりけずったり、総合QAを削ってるので
色々聞きたかった方は、Twitterとか使ってもらえるといいかなと思います）


Scrumやってみた

結論 : tracいらねぇんじゃねぇの？

というのも、ツール自体はあくまでツール
Trac.Lighningのデフォルトページにあるとおり、
Trac自体は最小限の干渉しかしないサポートツールで
開発者は、Tracにアクセスする作業が増大することで
開発に支障がでるようであれば、それは本末転倒かなぁと理解しました。

便利なプラグインは多くあるにしても、
Trac.Lightningに入っているプラグインは把握できてないし
汎用的に仕える物と、そもそも状況に応じて自分でいれて拡張することで
初めて力を発揮するのがtracかなと思いました。

開発とプロジェクト管理を両立させるのは、ますます無理だなとw
本当にtracを使って集計や方向性とかを決める材料にするのであれば
それに大して100%注力できる環境が必要なような気がします。

tracが管理のためのツールになり、第二第三のExcelにならないように
使い方をしっかりと考えて使うことが大切なのではと思いました。

「とうとうExcelがやられたか、しかし奴はBTSの中では最弱」

的な展開はしたくないところですw


Jenkins実践入門 の Next Step
（後日、発表資料公開があるらしい）

この発表は、JenkinsのTips集のような感じでした。

前半は、Jenkins本の紹介
積み本が増えてきたので、いまのものがあらかた片付いたら
読んでみようかなと思います。

後半はこうしたらいいよ！っていうTips
Jenkinsの？ボタンはほんと助かります。
いつも押す？ボタンは、スケジュールの設定のところのやつと
成果物の収集のところのやつです。お気に入りの？ボタン

高度な設定は、一通り使った後に、押してまわると面白いかなと思います。
中身は、やってみないと分からないものが多いと思うので
まずは使ってみてからの、ひと押し

実際、僕は本を読まずに、ネット + 素晴らしい先人たちが残してくれた
Jenkinsの環境設定を見ながら、Jenkinsを利用しています。
大体問題にぶち当たると、twitterで呟きつつ、自分の昔作った
プロジェクトを眺めて、あーでもねぇ、こーでもねぇとやってます。


Kanban - お客さんの視点に立ったアジャイルなやり方 -

発表時間が短くなってしまい、申し訳ありませんでした。

いつもの todo doing done のScrumボード（意味あってるのかな）じゃなく
Kanbanの仕組みと、用語の解説。
また、おもしろいサンプルケースとして、
タスクの完了期限を決めないことで、生産効率が上がった事例をお聞きしました。

Kanbanで優秀だなって思ったのは、流れが停止しないことだと単純に思ってます。
Todoは常に補充され、開発者は補充される物から順番にタスクを拾って処理していくため
機能追加が滞らない場合は、開発者はシームレスにタスクをこなすことになると。

気になるというか、辛そうだなと思うのは、まず終わりが見えずづらいこと。
TODOに入れる個数が制限されて、そこに入るタスクは、顧客側が管理するとなると
顧客のプロダクトバックログや、要求仕様を確認していかないと
プロジェクトの終了が見えないのかなと思いました。

あと、シームレスの弊害があると思って、ふりかえりや改善のタイミングは
どうやって図るのかなというのが、疑問として残りました。
これに関してはチームがここで振り返るよ！って言ったときに、
前回の振り返りからの完了タスクとかでやるのかなぁとか。

実際問題として、組み合わせちゃいけないというわけでもなく

プロジェクト管理をScrumボード タスク管理をKanbanで
とかでもいいのかなとか。
とりあえず勉強不足なので、この辺は戯れ言ですw


パソナテック / エンジニアカフェのご紹介

今回会場を提供していただいたパソナテック様のLTです。

いいね！ をするがいい！ という（ぉぃ


勉強会とかで会場提供して、交流を深めるのが真の目的だそうで
今度はHTML5とかゲーム開発のフレームワークの勉強会とか
結構ワクワクするような勉強会やってそうでした。

とりあえず、イイネはしてきた！

というわけで、皆様お疲れさまでした。

後日談

今回の勉強会では、司会をやらせていただきました。
時間調整で、お品書き削ったりとかしかしなかったんですが
発表者に大して、時間はあとこれぐらいで頼む！とかいうのも
有志の勉強会で、それはないなぁという意識から
そのまま流させていただきました。

おかげさまで、最後の総合QAと休憩時間を一個半削るという
暴挙をやらかしたのも反省点です・・・

とはいえ、お褒めの言葉もいただき嬉しい限りです。
また機会があれば、お手伝いしたいと思います。

司会業は、舞台度胸つけるのに結構いいんじゃないかなと
最近思ってます。あがり症なため、前にたつと
足がガクガクしてたりしますw

SCMBCいってきた。

SCMBootCampいってきた。

SCMBootCampの主催者、きょんさん(@kyon_mm)、ほんとお疲れさまでした。
また、会場を提供していただいたORACLEさん
講師、スタッフの方々、大変お世話になりました、ありがとうございます。

とりあえず、内容や会場の様子は、こちらの人のブログからどうぞ。
（楽してすみません、「こちらの人」を流行らせたいです。）
SCMBootCamp in Tokyo 2に参加してきた #scmbc - Shinya’s Daily Report

んで、僕はgitで参加してきました。
選びがたかったんですけど、初参戦かつ、gitまともに使えてるのか？という疑問もあって。

自分の感想とかですが
僕、git 使えてませんでしたゴメンなさい。
これからはちゃんと勉強するので、許してください。

というのも、基本操作で使ってることが多すぎて
あ、こんなこともできたの？ なに！？そんな方法が！？

っていうのが多くて、「一度、コマンドのヘルプ全部眺めてみるといいよ」
って言われた意味を、やっと理解したとか。

ただ、少し言い訳しとくと
普通に使ってるだけでも、効果は出ると思うんです。
動作を理解しないのはいけないと思うんですが、

1. なにするか決める
2. topic branchを作って移動(checkout -b)
3. 作業する
4. addする
5. commitする
6. （rebaseする）
7. checkoutでマスターに戻る
8. pullする
9. mergeする
10. pushする

各所で、log と status と gitk

これだけのステップで、リモートにほぼ依存することなく
開発できるってのは素晴らしいことだと思います。

僕は本を読むのが苦手なわけですが、本を読まなくても
ここまでやることができて、ある程度のことが出きるようになれば
本も読めるようになるだろうってことで、後日入門Gitも買ってきました。
そんなわけで、これを最初のステップにして、これから勉強していこうと思います。

うちのチームの成果物（Gitチートシート）は

risk/SCMBootCamp - GitHub

ここに入ってまして、いまだ少しずつ改良が進められていますw

内容的には、単純にアルファベット順にコマンド並んでるだけですが
これを一通り読むだけで、あぁこんなこと出来んのか〜って思えます。
なので、これはこれでありだなぁと思ってます。

というわけで、短いですが、これぐらいにしておきます。

そうそう、忘れてた。
思い残しが数点

きょんさんに、僕のリポジトリを君のリポジトリと統合しないか？
とか言ったんですか？と聞こうと思ってたのに忘れたこと

せっかく鼻メガネ持っていったのに、恥ずかしさに負けて
装着時間が短く、自分の勇気の無さに落胆したこと

を付け加えておきます。

最後になりますが、

同じチームで作業してくださった
@inda_reさん @nobusueさん @Soltiさん
@sue445さん @natsu_nananaさん
講師の@tosikawaさん ありがとうございました。

いろんなおもしろい話と、他業種の話は大変興味深く
「組込み以外もおもしろそうだな」と思いました！

とりあえず、branchを切り忘れる癖から矯正しよ・・・

ＣＩ（継続的インテグレーション）超入門：Jenkinsのススメ

「ＣＩ（継続的インテグレーション）超入門：Jenkinsのススメ」
に行ってきた話

内容的には、

• CIって何？
• jenkinsいいよー
• 商用CIツールの宣伝

といった感じでした。

CIの説明

ソフトウェアの調理方法を。

ビルドって何？ということで、そういやあまり考えたことがなかったな
ビルド自体はには２つの意味があることを。

• 実行可能なソフトウェアを作ること
• 実行可能なソフトウェア自体

の意味があるんだね。

「ビルドをビルドする」は
「料理を料理する」と同じ意味合いと言われてあぁって思った。

本題ですが

提供する側が必要なことってことで

「いつでも同じビルドを届けることができることが重要」

確かに、「あの時のビルドの環境作ってほしいんだけど」
ってよく言われるので、よく分かる。
背景を説明すると、リリースと開発が平行してて

リリースした製品でxxxなバグが出たから、再現環境作りたいんだけど

とか。

そんなときに、再現可能なビルドをしとくことが重要になると。
再現可能ってのはどういうことかというと

• いつでも誰でもビルドできる
• ユーザーに届けたものと同じものをビルドできる

これを実現するために
必要なことが、全部とはいわないが一般的に

• ソース
• レシピ
• 手順書
• スクリプト
• ビルドマシン
• コンパイラ
• ビルドツール各種

とか。

話は変わって開発環境の話ですが

開発者はサンドボックスでビルドすることが望ましい

じゃあビルドはどこでやるの？というと

ビルド専用マシンを立てましょう ということに。

んで、ビルドマシンが使うソースはどこに？ というと

リポジトリが必要でしょう。

• サンドボックス
• リポジトリ
• ビルドマシン

この３つを連携させて動作させると

「サンドボックス」で開発して
「リポジトリ」にコミットして
「ビルドマシン」がビルドする

これを繰り返していくことがCIですね。
キレイな環境で作ってあげることで
安定したビルドが出来上がると。

ただ実際に開発していくと、普通ソフトは壊れます。
実行時バグとか、他の機能に干渉するとか原因はいっぱいあるけど

壊すタイミングは何かってことになると
コミットしたときにビルドの成果物が壊れるんですね。

これを避けるための、コミットポリシー

大体コミットするときのお作法として決められているような内容ですが

• 自分のところでビルドしてエラーが無いことを確認する
• バディビルドを実施する
• コードレビュー

とか。

バディビルドをビルドサーバーにやらせるっていいなぁと思った。
実際にビルドサーバーがビルドするんだから、同じ環境で試しにビルドして
結果を教えてくれるなら、それが言いに決まってる。

まえに、名古屋のイケメンが話していた

自分用のブランチにコミットすると、ビルドサーバーがビルドしてくれて
OKなら、メインのリポジトリにコミットしてくれるっていう仕組みが
この流れと同じだと思うんだけど、環境構築大変そうだなぁと思ったり。

最後に、リリーストレインの話。

駆け込みコミットはお控えください
ビルドは定刻通りに発車しております。

これがすべてか。

変なタイミングのコミットは、本当に問題の元。
落ち着いて、良いリズムの開発を心がけたいものです。

まぁ一日一回のビルドだときついと思うので
デイリービルドするなら、プレビルド的な
コミットを監視してるやつも一緒に立てて上げるのがいいよなぁと思う。

jenkinsの話

なんでCIするのって話から。

インテグレーションを頻繁に行って、結合作業時に「え！？」ってならないように。

最近のCIの定義でいくと
ビルドを頻繁に行うことで、退行をできるだけ早く検出する
コードの品質検査を定期的に。

どっちにもいえることで

「機械ができることは機会にやらせればいいじゃない」

と。
僕も、ものすごくそう思います。

利点とか

リグレッションは、そのまま直訳で「後退、退化」なんですね。
うちの会社では、デグレとか読んでるソレです。
テストの場合は、前に出来たことが出来なくなることを見つけるので
リグレッションの方がしっくりくるかなぁとか思ったり。

リグレッションが早く見つかる
常にテストを書けている場合にかぎらず
成果物が常時できているので、コミットフックのビルドをかけるだけでも
結構違うと思う。

頻繁に成果物が生成されることで、ここからxxxの現象が出てるって
確認しやすくなります。

頻繁にリリースできるため、バグを早い段階で見つけることが出来
「あーそんな変更あったね（笑）」
を減らすことができます。

見える化
jenkinsさんは、情報収集が得意なので、各種情報が
jenkinsに集まり、ダッシュボードをみれば現在の状況
各種ビルドをみれば変更点やテスト状況など、みることができます。

属人制を減らす。
ビルドサーバーさえあればビルドできるはずなので
急にチームから人が消える
病気で倒れる
など、あったとしても大丈夫と。
あと、ビルドサーバーが開発のためのお手本環境になるので
各メンバーの開発環境を統一化するのにも一役かってると思います。
前に自分用Jenkinsいれた！って呟いたら、突っ込まれたのを思い出しますw

追跡可能性
バイナリが作られた原因（なんのコミット？）が分かる。
リグレッションの原因分析の手助けに使える。

かるくまとめ
CIは、手間を減らす というよりは
「人が人のやるべきことをやるために」
機械にできることは、できるだけ機械にやらせるのが良いと。

Jenkinsさんの紹介ですが

いいところをざっと。

• 導入設定が簡単
• 各種OSパッケージ
• プラグインによる拡張機能
• ４５０個以上のプラグインで多用な環境に
• プラグインを自作することもでき、さらに柔軟な環境へ

ビルド以外に出来ることの紹介

• FindBugs 静的解析かな？
• コードカバレッジの計算と表示
• チケットシステムとの連携
• 分散ビルド

チケットシステムとの連携は、コミットログから飛ぶぐらいかな
って思ってたけど、jenkins自体がチケットに書き込みに行ったりするんですね。

プレテステドコミットとかは、難しそうだなぁって話してたら
かおるんに、TFSなら簡単に出来るよって言われたり。
流れてきには、

1. 開発者が自分のトランクにコミットする
2. jenkinsがそれを見つけて、ビルドとテスト
3. OKならjenkinsからメインのリポジトリにコミットする

これならメインのリポジトリを破壊する可能性がグッと減りますね。

どの出来ることもそうだけど、機械には得意な事と不得意なことがあるので
得意なことはいっぱいやってもらって、あまったことだけ人間がやるのが
ベストだなぁと思います。

最後に、「具体的にはじめるには？」ってことで

• 千里の道も一歩から、
• ビルドの自動化
• テストの自動化
• コンポーネントを一つづつ
• 自動化の島をたくさん作って大陸へ進化

コツコツが大切なんだなぁと改めて。
（苦手だ・・・）

最後の話は、未発表製品なので割愛。
静的解析ツールの話でした。

ディスカッションですが
全体的にまだ何もいれてない！ってところと
まぁそれなりに〜ってところが半々って感じだったのかな
（一番前に座ってたのであまり会場がみえなかった）

どの質問に関しても、共通して言えることは

Small start Small win

の繰り返し。

こんてぃにゅあす うぃん

です。

何事も、出来そうだなぁとおもったことをとりあえずやってみると
なんか見えると思います。

以上、勉強会レポでした。

勉強会後、
@heroweenさんとか、@shinyaa31さんとか、
@711fumiさんとか、@cyobichiさんとオムライス食べました。

いろんな話が出たけど、共通して言えることは
勉強会大好き と 開発者が楽しいって思えることを出来ないと
人は集まらないし離れていくってことでした。

さて、締めの言葉は、

「俺には前しかみえない（腹肉的な意味で）」

やっぱりこれですね。

ではでは。

boost.statechart を使ってみた。

まず普通に使ってみた。

例題は、
letsboost::statechart

ここを参考にさせていただきました、いつもお世話になってますw

まずシンプルな奴。

#include <iostream>

// boost
#include <boost/statechart/state_machine.hpp> // ステートマシン
#include <boost/statechart/simple_state.hpp>  // ステート
#include <boost/statechart/event.hpp>    // イベント
#include <boost/statechart/transition.hpp>    // 遷移
#include <boost/statechart/in_state_reaction.hpp> // イベントアクション
#include <boost/mpl/list.hpp>       // イベントテーブル

using namespace boost;

namespace gate
{


namespace events
{
// イベント
class InsertedCoin : public statechart::event< InsertedCoin > {};
class PassedThrough : public statechart::event< PassedThrough > {};
};

// 初期ステートのみを前方宣言
namespace states { class Locked; }
// ステートマシン < マシン, 初期ステート >
class Gate : public statechart::state_machine< Gate, states::Locked >
{
 // メインスレッド

 // イベントハンドラ
};


namespace states
{
class Locked;
class Unlocked;

// ロック状態 ステート < ステート, マシン >
class Locked
 : public statechart::simple_state< states::Locked, Gate >
{
public:
 // イベントを引数に取る
 void alarm( const events::PassedThrough& event )
 {
  std::cout << "ｳｳｳｳｳｳｳｳｳ ｳｳｳｳｳｳｳｳｳｳｳｳ" << std::endl;
 }

 // イベントテーブル
 typedef boost::mpl::list<
  // 遷移
  // InsertedCoinイベントで、Unlockedへ遷移
  statechart::transition < events::InsertedCoin, states::Unlocked >,

  // リアクション
  // 通過イベントで、アラームを発生 ステートは維持。
  statechart::in_state_reaction<
   events::PassedThrough, Locked, &Locked::alarm >
  > reactions;
};

// ロック状態 ステート < ステート, マシン >
class Unlocked
 : public statechart::simple_state< states::Unlocked, Gate >
{
public:
 void thankYou( const events::InsertedCoin& event )
 {
  std::cout << "ありがとう・・・ありがとう・・・" << std::endl;
 }

 // イベントテーブル
 typedef boost::mpl::list<
  // InsertedCoinイベントで、Unlockedへ遷移
  statechart::transition < events::PassedThrough, states::Locked >,

  // リアクション
  // コイン挿入イベントで、感謝を。ステートは維持
  statechart::in_state_reaction<
   events::InsertedCoin, Unlocked, &Unlocked::thankYou >
  > reactions;

};

} // namespace states

} // namespace gate


int main()
{
 gate::Gate gate;

 // ステートマシンの初期化
 gate.initiate();

 // とりあえずイベントを発生させてみる
 gate.process_event( gate::events::InsertedCoin() );
 gate.process_event( gate::events::PassedThrough() );
 gate.process_event( gate::events::PassedThrough() );
 gate.process_event( gate::events::InsertedCoin() );
 gate.process_event( gate::events::InsertedCoin() );

 return 0;
}

内容は、そのまんまで、使ってるクラスは、大きくわけて三種類

• イベント
• ステートマシン
• ステート

ステートを使ってるので当たり前だけど
ステートマシン が ステート を イベントをトリガに遷移していく動作をさせます。

イベント
boost::statechart::event テンプレート
イベントクラスがこのテンプレートクラスを継承する
テンプレートには、イベントクラスを渡す。

イベントハンドラの登録
boost::statechart::in_state_reaction テンプレート
イベントクラス、イベントハンドラを持っているクラス、イベントハンドラ を設定する。
後述するイベントテーブルに渡すことで、イベント発生時に、イベントハンドラが呼び出せる

イベントをトリガに別ステートへ遷移する
boost::statechart::transition テンプレート
イベントと遷移先のステートを設定すると、イベント発生時に指定したクラスに遷移する

ステートマシン
ステートマシン
boost::statechart::state_machine テンプレート
ステートマシンクラスが、このテンプレートクラスを継承する
テンプレートには、ステートマシンクラスと、初期ステートを設定する

ステート
ステート
boost::statechart::simple_state テンプレート
ステートクラスが、このテンプレートクラスを継承する
テンプレートには、ステートクラスと、ステートマシンを渡す。

イベントテーブル
boost::mpl::list テンプレート
ここに、イベントハンドラや、状態遷移 を登録する。

といったところです。

んで、いろいろ考えて、自分なりにごにょごにょやったのがこっち。
最終的にステート使う人が、書く量を減らせるようにというのを目標にしたんですが
いまはソースが一枚になってるので、結構ごちゃごちゃしてます。

イベントは分かる人が実装して、普通使う人が
ステートだけを実装していくような用途を想定しています。

/**
* @file   statechart.cpp
* @author riskrisk
* @date   Fri Oct 28 17:31:30 2011
*
* @brief  statechart sample
*
* commandline : g++ -lboost_thread -lpthread statechart.cpp -o statechart.bin
*/

#include <iostream>
#include <queue>

// boost
#include <boost/thread.hpp>
#include <boost/bind.hpp>

#include <boost/any.hpp>

#include <boost/statechart/state_machine.hpp> // ステートマシン
#include <boost/statechart/simple_state.hpp>  // ステート
#include <boost/statechart/event.hpp>    // イベント
#include <boost/statechart/transition.hpp>    // 遷移
#include <boost/statechart/in_state_reaction.hpp> // イベントアクション
#include <boost/mpl/list.hpp>       // イベントテーブル

using namespace boost;

namespace gate
{

// イベント
namespace events
{
// コイン挿入
// イベント( event< Event > )
class InsertedCoin : public statechart::event< InsertedCoin > {};
// イベントハンドラ
class InsertedCoinHandler
{
public:
 // イベントハンドラ( onXxx( const Event& ) )
 virtual void onInsertCoin( const InsertedCoin& event ) = 0;
 // ハンドラ登録( in_state_reaction< Event, HandlerClass, EventHandler > )
 typedef statechart::in_state_reaction< InsertedCoin,
             InsertedCoinHandler,
             &InsertedCoinHandler::onInsertCoin > EventHandler;
};
// 遷移( transition< Event, TransitionState > )
template< class TARGET_STATE >
class InsertedCoinTransition
 : public statechart::transition< InsertedCoin, TARGET_STATE >
{};

// 通過
// イベント( event< Event > )
class PassedThrough : public statechart::event< PassedThrough > {};
// イベントハンドラ
class PassedThroughHandler
{
public:
 // イベントハンドラ( onXxx( const Event& ) )
 virtual void onPassThrough( const PassedThrough& event ) = 0;
 // ハンドラ登録( in_state_reaction< Event, HandlerClass, EventHandler > )
 typedef statechart::in_state_reaction< PassedThrough,
             PassedThroughHandler,
             &PassedThroughHandler::onPassThrough > EventHandler;
};
// 遷移( transition< Event, TransitionState > )
template< class TARGET_STATE >
class PassedThroughTransition
 : public statechart::transition< PassedThrough, TARGET_STATE >
{};

// イベントのシリアライズ用
typedef boost::shared_ptr< statechart::event_base > EventPtr;
};

// 初期ステートのみを宣言
namespace states { class Locked; }
// ステートマシン( state_machine < StateMachine, InitialState > )
class Gate : public statechart::state_machine< Gate, states::Locked >
{
private:

 bool isExit_;    // スレッドの終了
 std::queue< events::EventPtr > events_; // イベントのシリアライズ

public:
 // コンストラクタ
 Gate()
  : isExit_( false )
 {}

 // スレッドの終了要求
 void requestExit()
 {
  isExit_ = true;
 }

 // メインスレッド 
 void run() {

  std::cout << "machine entry" << std::endl;

  // ステートマシンの初期化
  initiate();

  // メインループ
  while( !isExit_ ) {
   // イベントハンドラ
   eventHandler();

   // 登録イベントが無い場合は、少し待ってみる
   if( isNoEvent() ) {
    usleep( 100 * 1000 ); // 100msec
   }
  }

  std::cout << "machine exit" << std::endl;
 }

 // イベントが無い場合に真を返す
 bool isNoEvent() { return events_.empty(); }

 // イベントの追加
 void addEvent( events::EventPtr event ) {
  events_.push( event );
 }

private:

 // イベントハンドラ( とても適当 )
 void eventHandler() {
  if( !isNoEvent() ) {
   process_event( *( events_.front() ) );
   events_.pop();
  }
 }
};

// ステート
namespace states
{
class Locked;
class Unlocked;

// ロック状態( simple_state< State, Machine > )
class Locked
 : public statechart::simple_state< Locked, Gate >
 , public events::PassedThroughHandler
{
public:

 // イベントハンドラ
 // 通過
 virtual void onPassThrough( const events::PassedThrough& event )
 {
  // アラームを鳴らそう
  std::cout << "ｳｳｳｳｳｳｳｳｳ ｳｳｳｳｳｳｳｳｳｳｳｳ" << std::endl;
 }

 // イベントテーブル
 typedef mpl::list<

  // 遷移
  // InsertedCoinイベント -> Unlockedステート
  events::InsertedCoinTransition< Unlocked >,

  // イベントハンドラ
  // PassedThroughイベント
  events::PassedThroughHandler::EventHandler
  > reactions;
};

// アンロック状態( simple_state< State, Machine > )
class Unlocked
 : public statechart::simple_state< Unlocked, Gate >
 , public events::InsertedCoinHandler
{
public:

 // イベントハンドラ
 // コイン挿入
 virtual void onInsertCoin( const events::InsertedCoin& event )
 {
  std::cout << "ありがとう・・・ありがとう・・・" << std::endl;
 }

 // イベントテーブル
 typedef mpl::list<
  // PassedThroughイベント ->、Unlockedステート
  events::PassedThroughTransition< Locked >,

  // イベントハンドラコール
  // InsertedCoinイベント
  events::InsertedCoinHandler::EventHandler
  > reactions;
};

} // namespace states

} // namespace gate


int main()
{
 gate::Gate gate;

 // ざっくりとイベントを登録
 gate.addEvent( gate::events::EventPtr( new gate::events::InsertedCoin ) );
 gate.addEvent( gate::events::EventPtr( new gate::events::PassedThrough ) );
 gate.addEvent( gate::events::EventPtr( new gate::events::PassedThrough ) );
 gate.addEvent( gate::events::EventPtr( new gate::events::InsertedCoin ) );
 gate.addEvent( gate::events::EventPtr( new gate::events::InsertedCoin ) );


 std::cout << "start" << std::endl;

 // ステートマシンを起動
 boost::thread gateThread( boost::bind( &gate::Gate::run, &gate ) );

 // ちょっとだけ待っておく
 sleep( 1 );

 // 終了要求
 gate.requestExit();
 // 終了待ち
 gateThread.join();

 std::cout << "end" << std::endl;

 return 0;
}

// EOF

git-svn で dcommitするときに。

久しぶりにエントリですw

相変わらず、社内で利用しているSCMは、Subversionでして、 git-svn のお世話になってます。
で、前に分散管理勉強会で git-svn の発表したときに、間違えてはいないんですが、
ちょっとなぁって思う部分があったので、そこについて補足しようと思います。

何かって言うと、コミットログについてです。

スライドの順番通りやると、コミットログが「マージしました」になります（汗
どういうことかっていうと、masterにすべてマージしてからコミットする手順で紹介してたんですね

手順的には

ブランチに master と working があるとして

1. wokingで作業
2. 一段落したので、コミットしようと思い立つ
3. git checkout master でマスターブランチに移動
4. git svn rebase で、masterを最新に更新
5. git merge working で、masterに変更を反映
6. git svn dcommit でsvnにコミット

これだと、５の時点で、サーバー上に反映されるログが

「Wokingをマージしました（ｷﾘ」

になります・・・

んで、正しい方法なんですが、

1. wokingで作業
2. 一段落したので、コミットしようと思い立つ
3. git checkout master でマスターブランチに移動
4. git svn rebase で、masterを最新に更新
5. git checkout working でworkingに戻る。
6. git rebase master で、working を最新に。
7. git svn dcommit でsvnにコミット

という感じでできるっぽいです。（今のところ大丈夫）

実はまだ、コンフリクトしてないので、どーなるかなーとは思いつつも、
コンフリクトしない素晴らしい状況（まぁ僕のところは僕しかイジらないってだけですが）
で仕事してるので、またなんかあったら、情報更新しようと思います。

ではでは。

自分のスキルマップ

自分の値段を考えたことがなかったけど、それを決めるための指標になりそうな手段

実際に、Google検索でスキルマップを検索してみると、画像検索に結構出てきたり
作り方のページが表示されたり。

ただ、見てて思うのは、

• 表の形状にして、そこに文字を当てはめる
• できることが数値化されているが、その数値はどこから？（5段階評価みたいなレーダーチャート）

実際に見たい、見てもらいたいデータは、分野に分かれて、その分野でどの程度のことを
やったのか、どんなことができるのか、どんな経験があるのかだと思う。

そんわけで、自分のスキルをマインドマップ化するっていうのが流行ってたし、そんなデータを自分でも作ってみた。

この図も経験とスキルに色分けされてなくてちょっと見づらい・・・

多分だけど、自分の値段がある程度正確に把握できてる人は少ないんじゃないかと思う。
（そもそも、そんなもの導き出せるのか？という話もあるけど、診断サイトとかあるしなぁ）
実際、時代の流れ（流行り廃り）でも、評価はどんどん変化するわけで、変わらないのは
自分が出来る言語や、自分の経験かなと。

上に書いたような自分の財産を見せられる「元データ」があって、

「コレだけのことをやってきて、こんなことができるんですが、僕いりません？」

と聞けるようになってたら、転職しやすいんじゃないかと思って。
お前は何ができるんだ？という疑問を投げられたときに、胸を張って、

このページを見てもらえれば！と言えれば作った価値があるってもんだ。

Cygwin+Windowsのエディタで歴史改変（git rebase -i）

僕は、現状でCygwinをつかってgitをいじってます。
んで、コミットログとかの入力はWindowsアプリでやってます（terapad）

んで、最近自動コミットを試してみてたんですが、どーにもgit rebase -i を実行すると、
エディタが開いて何も表示されないことが続いてました。

ついったで、なんでじゃーってつぶやいてたら、

@riskrisk cygpathで変換してあげないとだめな気がしますless than a minute ago via TwitVim Favorite Retweet Replyぱせら
pasela

おお、なるほど、Windowsのエディタに、Cygwinのパス /homeとかああいうやつがそのままわたるのか・・・

ためしに、/lib/git-core/git-rebase--interactive の最初でパスを設定してるので、そこでechoを突っ込んでみたら
見事に、homeから始まるアドレスが出てきた！

で、解決方法も、cygpath -w でWindowｓのパスに変換してくれるよ ということなので、
さっそく、スクリプトをいじって試すと動くようになったんだけど・・・

そこで、もう一通

@riskrisk 自分は引数をcygpathで変換してから渡すシェルスクリプト書いて、それをGIT_EDITORに指定してますless than a minute ago via TwitVim Favorite Retweet Replyぱせら
pasela

そりゃそうですね・・・ その方法が一番正攻法だと思います

というわけで、下記にサンプルです。

$ git config --global core.editor ~/.git-editor

これで、自分のhomeディレクトリの直下にある .git-editor を実行してくれるので、
このスクリプトを書きます。

#!/bin/sh
# editor setting
"/cygdrive/c/Program Files/TeraPad/TeraPad.exe" /cu8 `cygpath -w $1`

僕のやつはこんな感じ。

これで、git rebase -i の編集に、terapadが使えました。

ほんとありがとうございました。

makeをファイル更新のトリガで自動実行

今日は、makeを使ってTDDするときに、

1. コード変更
2. いちいちmake -> エンター（ﾀｰﾝ ビンゴだ！）

ってやるのが、結構めんどくさく感じてまして。

求めてる動きは、ソース変更したら、勝手に結果でねぇかな と思ってたんですよね。

で、今まさに

• 開発言語 C++
• Cygwinで開発中
• GoogleTest と GoogleMock

で、結局シェルスクリプトで実現することにしました。（いろんなアドバイスもらったので、それに関しては後述します）

まずシェルスクリプトです

#!/bin/sh

echo "check file update!"

makeOpt=$1

# 作業ディレクトリ（衝突しない名前に）
workDir=autorun

rm -rf $workDir
mkdir -p $workDir

while [ 1 -eq 1 ]
do
 isMake=0

 # 更新確認するファイルを、in のあとに並べる
 for file in *.cpp *.hpp Makefile tmp/*.cpp
 do
  backup=${workDir}/${file}
  if [ ! -e $backup -o $file -nt $backup ] ; then
   cp -f --parents $file ${workDir}/
   isMake=1
  fi
 done

 if [ $isMake -eq 1 ] ; then
  make $makeOpt
  if [ $? -eq 0 ]
  then
   echo success!
   # 成功時の処理をここに書く
  else
   echo failed!
   # 失敗時の処理をここに書く
  fi
 fi

 sleep 1
done

このスクリプトのいいところ

• スクリプトの第一引数で make の引数を指定できるので、モジュールごとに実行しておくことが可能
• makeとテストが両方成功した場合の判断ができるので、シェルスクリプトの編集で成功時にコミットとかできる（と思う）
• 後片付けは、作業ディレクトリを消すだけ（.gitignore とかに指定しておくとよさそう）
• 使うときはシェルスクリプトをmake用のディレクトリに置くだけ。

使うに当たって修正するところ

• 自動でworkディレクトリとか作る（スクリプト内のworkDirで指定可能）ので、衝突しない名前にしておく
• 更新チェック対象は、for の in のあとに付け加えるだけ
• 成功時、失敗時（make失敗 or テスト失敗）の処理が必要な場合は、success と failed の場所を修正

という感じで。

実行は、

./autorun.sh make-option

で走りっぱなしになります。更新チェック対象のファイルが更新されたら、自動でmakeが始まります。

 

スクリプトの説明は以上で、ここから先は皆様からいただいたアドバイスですが

• omakeでそんなことできたんじゃないかな（omake -p）
• eclipse で 自動ビルド
• make に仕込みをいれていく

なんて話をもらいました。

できない系の否定的な意見は、嫌なので、下のは自分の調査不足です。（実際にomakeもできたよーって話ももらいましたｗ）
んで、その上で僕の現状ですが

omakeは、もの凄いツールで、使いたくて頑張ったんですが、make -> ocaml -> flexlink -> アクセスが拒否されました。
というコンボが重なり、いまのところペンディングです（涙

omakeは、あとで使いたいのでLinux環境いったときに使いますね。

eclipseとgmakeについては、実際に「C++とGoogleTestのTDDをeclipseでどうか」を実験してたんですが、
あまりおいしくできなくて、やめていた経緯がありました。

• eclipseが自動で作ってくれるmakeだと、実行ファイルが一つしかつくれなくて、うまくできなかった
• makeを読込ませてやってみたが、makeターゲットの指定とかが意外と面倒

こんなところです。

とりあえずやりたいことはできた、よかった！

すくすくスクラム第23回にいってきた #suc3rum

皆様おつかれさまでした。

海江田@Qooh0さん、講師お疲れ様です。スタッフの皆様、すばらしい勉強会をありがとうございます、参加者のみなさまに出会えて、とても有意義な時間をすごさせていただきました。

今回のすくすくスクラムは、初学者向けってことで、スクラムって何？ってところから、お話していただけました。
そんなこともあって、「今回初めて！」って方がいっぱいいらっしゃって、スクラムってやっぱり注目されてるなぁと思ったり。

後日談ツイートで見かけたところによると、1/3ぐらいゲーム業界からいらっしゃっていたようで、懇親会でも話を聞けたんですが、ゲーム開発にぴたっとはまる瞬間があるみたい。（実際は、いろんなプロセスを混合する感じのほうが、上手くいくかもしれないとか、いろいろと意見はあるようです）

勉強会の内容的には、いままで教えてもらったことの再認識って感じだったけど、地味に勘違いしてるとことか、分かってなかったところが見えて、とってもうれしかった。そして、紙飛行機飛ばしは、意見をまとめて、「これでいこう！」っていうFixが、ものすごい難しかった気がする。

ロール

• プロダクトオーナー
• リリースとかの権限を持ってる
• 製品の行く末を決める
• チーム
• チームは、長いスパンで成長させていく
• スクラムマスター
• サーバントリーダーシップ（よいしょ係）

昔会社で、一番難しい命令は「うまくやっといて」だとか話をしたのを思い出したけど、スクラムマスターは、まさしく「うまくやる人」なんだなと思った。

キックオフミーティング

• プロダクトバックログ（PBI：プロダクトバックログアイテム）
• 優先度、価値を決める
• 見積もる
• Tシャツのサイズ見積もり（SML）
• プランニングポーカー
• 誰のために、何が出来たらいいの？を決める
• 顧客が見えないんですけど。
• ペルソナ
• ログ
• さまざまな情報を収集した結果を持って、ある程度の値を決めると、話がしやすいのではないか？（「値」の重要性？）

懇親会でも話しにあがったけど、優先度がつくことで、必須機能やオプション機能、実現性とかのからみを上手く紐解ける感じになるのかなって思った。

このあたり、実体験から話しを聞けたのは、とても良かった。

余談だけど、プロダクトバックログの書き方の話で「ユーザーは」じゃなくて「僕は」だったり、それらしい口調のほうがしっくりくるって話をゲーム関連の方がおっしゃってて、おもしろいなぁと思ったり。

あと、勉強会後に、記念と義援金ってことで、すくすくプランニングポーカーを買ってきたｗ

スプリント計画ミーティング

• スプリントで何をする（タスク）
• タスク粒度
• 1～16 時間派
• 1～8 時間派
• 完了の定義の重要性
• 大体の目安で、チームとプロダクトオーナーが完了に同意できれば完了
• リリース可能（昨日が使える状態＝プロダクトバックログの完了って感じ？）
• C.I.とかと連携させてリリースできるようなものを作っていく

スプリントで何するかってのを決めるのが、コレですよね。

完了の定義を決める っていっても、実は「定義」のイメージが沸きません。
完了するってことは開発であれば、「ｘｘｘのように動くこと」とか、当たり前のことを定義とするんだろうか。バグであれば、直ってること？再現しないこと？何を持って再現しないとする？
実際、そこらへんを実例で見てみたい気がするなと思った。

スプリントが始まったら

• デイリースクラム（毎日やろう、朝会）
• 昨日やったこと
• 今日やること
• 困ってること
• 障害リストのUpodate
• バーンダウンチャート
• 必ずやっとけ、マジで。やれ

朝会の3項目は、最近一人朝回が開催されてます。ちなみに、やった日とやらない日では、仕事の進み具合が違います。一人でもやっとく価値がある。

んで、僕、バーンダウンチャートがどーも苦手で、なんかアレを書けといわれてかけないんですけど、やらんでいいですか？って先生に聞いたら、
ダメですd(´∀｀)bって言われた。

バーンダウンチャートの重要性って、タスクの消化具合からプロジェクトの健康状態、お客さんとの交渉材料と、多岐にわたってあるんで、コレがあるのと無いのではずいぶん違う模様。

都合上、ノートとかにこそっと作っておくぐらいにすべきか、もしくは、Tracでバーンダウンを吐き出せるようにするか。どっちにしても準備がいるなぁ

スプリントが終わったら

• スプリントレビュー
• Demo or Die
• ふりかえり（レトロスペクティブ）
• チームをよりよくするための改善
• スプリントミーティングから、スプリントレビューまで

この2つは、参加者が違うんですね。

スプリントレビューのほうは、そのスプリントの成果を発表する場で、こんなもんができましたよ！ってやつ。

で、ふりかえりは、チームでやる。良かったところとか悪かったところを確認して、改善していくのが目的。

懇親会にて、「ふりかえりやらないと、改善するタイミングないよ」とのこと。
そりゃそうですよねぇ・・・

ちなみに、ふりかえりは学級会みたいでプライドが許さない！っていう感じでとっつきづらいという話をきいて、あーなるほどｗと思いつつ、でも、そこのチームでは、繰り返すうちに、それが普通になっていったそうで。やっぱり継続は大切だし、もう一個、その方法が身にしみていく慣れがいるのかなとか。

全然関係ないけど、Demo or Die はいつも、House of the Dead のあの声で再生されます。（バイオハザードの声でも良いですよ）

紙飛行機飛ばし（ワークショップ）

紙飛行機とばしまくってきたｗ

• スプリントミーティング：2分
• スプリント：3分
• 振り返り：1分

成功品の数は、10 → 21 → 20 だったかな。

見積もりは 無し → 15 → 25 だったかな。

第一スプリント（計画）

• 飛行機を折るのは、ペアプロならぬペア折り紙ｗ
• 折る人4人 飛ばす人1人 飛行機の先を丸める1人
  飛行機輸送1人

第一スプリント（ふりかえり）

• 我がチームは、いっぱい飛んだ！
• 輸送と先を丸めるロスが意外と
• 飛行機の品質がバラバラで飛ぶのと飛ばないのがあるよ
• ペア折り紙より、ライン作業のほうがいいのでは？
  （工程を分離することで、作るものが安定する？）

第二スプリント（計画）

• とりあえず、折る人いっぱいにしよう
• 7手かかる飛行機をおるので、7人必要
• 丸める係りは、最後の一手を折った人
• 飛ばす係、輸送係は、同様で。

第二スプリント（ふりかえり）

• すごい、飛ばした数が倍になったぞ！
• 終盤、仕掛け品がたまってきててもったいなかった
• タイムキーパー的な何かが居るのでは？

第三スプリント（計画）

• 最後は、作るだけ作って数人で飛ばしにいこう
• 最後30秒でまとめて投げに行こう
• タイムキーパーは、iPhoneの時計を机に。

第三スプリント（ふりかえり）

• 数増えなかったねぇ。
• あせって飛ばしきれなかったのがあった
• 最後30秒じゃちょっと短かったかな

と、試行錯誤しながらも、次にチャレンジすることが、どんどん出てきた。

会社でKPTとかやっても、大して出ないんだけど、違いは何だｗ

というわけで、本日のすくすくスクラム初潜入は完了しました。

実際、めっちゃたのしかった。会場も近場だったのでさらっと参加できたけど、遠くなるとちょっと難しいんだよなぁ。でも楽しかったし次も出たいし・・・

まとめらしいまとめはしないです、適度に混ぜ込んであるのでｗ

では、皆様おつかれさまでした。

モテる組込み女子力を磨くための４つの心得

こんにちは、組込みシステムを作っているriskです。私は学歴も知識もありませんしカスプログラマですが、組込みに関してはプロフェッショナル。今回は、モテる組込み女子力を磨くための4つの心得を皆さんにお教えしたいと思います。

 

1. あえて2～3世代前のOSを使っておく

あえて2～3世代前の組込みOSを使っておきましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくOSの性能について悩んでみましょう。そして「あ～ん！　このOS本当にマジでチョー使いづらいんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「OSとか詳しくなくてぇ～！ ずっとコレ使ってるんですけどぉ～！ リソースっていってもタスク管理ぐらいしかしてくれないし、例外起こったらそこでシステム止まっちゃうし、使いにくいんですぅ～！ ぷんぷくり～ん（怒）」と言いましょう。だいたいの男は新しいOSを使いたがる習性があるので、古かったとしても1世代前のOSを使っているはずです。

そこで男が「新しいOSにしないの？」と言ってくるはず（言ってこない空気が読めない男はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！　最近iOSが人気なんでしょー!?　あれってどうなんですかぁ？　新しいの使いたいんですけどわかんなぁぁああい!!　私かわいそーなコ★」と返します。すると男は「iPhoneとかでしか使えないでしょ？ 本当に良くわからないみたいだね。どんなOSが使いたいの？」という話になって、次の休みの日にふたりでiTRONのポートマッピングができるというわけです。あなたの組み込み女子力が高ければ、男が自作OSを作ってくれるかも!?

 

2. LCDに＞＜を表示するとモテる

「キャー！」とか「悲しい！」などを表現する「＞＜」をLCDに表示すると、組込み男性ユーザーは「なんかこの子カワイイなぁ」や「支えてあげたいかも」と思ってくれます。LCD上では現実世界よりも簡素化された8x16のアスキー文字列でイメージが増幅されて相手に伝わるので 「＞＜」 を多用することによって、男性はあなたを可憐で女の子らしいと勘違いしてくれるのです。そういうキャラクター（文字列ではない）にするとほぼ絶対に同性に嫌われますが気にしないようにしましょう。

 

3. とりあえず男には「えー！ なにそれ!?　 知りたい知りたーい♪」と言っておく

飲み会などで男が女性に話すことといえばCPU占有時間やリソース削減の話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ～？」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女ダメだな」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー！ なにそれ!?　 知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。

いろいろと話を聞いたあと、「CPU占有時間は、基本的に常に動き続けるスレッドを作ってることがミスであって、割り込みなどをつかったリアルタイム性重視のシステムにすべきなんですね。メモリ使用量の削減も、もともと確保されるスレッドのスタックサイズや、不必要なグローバル変数の削除、共有リソースをシングルトンにすることで単一プロセス内の無駄なメモリ確保をしないようにとか、覚えたぞぉ！　メモメモ！」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「00110010110101011011010101010101！ 10101010101010111101111111111111！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「私の物理メモリに記録しているのでありますっ☆」と言えば組込み女子力アップ！　そこでまた男は「この子まじでハードウェアかも！？」と思ってくれます。私は学歴も知識もありませんしカスプログラマですが、こういうテクニックを使えば知識がない私のようなヘタレプログラマのほうがモテたりするのです。男は優越感に浸りたいですからね。

4. 新規ハードウェアではレジスタをいじれない女をアピールせよ

男と新規ハードウェアの検証作業に入ったら、真っ先にデータシートのなどのレジスタマップを探し出して「あーん！　私レジスタたたけないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「どうして？アドレスとポインタ分からないの？」と聞かれるので、「嫌いじゃないし叩きたいけど、叩けないんですっ＞＜」と返答しましょう。ここでまた100パーセント「嫌いじゃないのにどうして叩けないの？」と聞かれるので、うつむいて3～5msecほど間をおいてからボソッとこう言います。「……だって、……だって、レジスタ叩いたら、レジスタ値がかわっちゃうじゃないですかぁっ！　ハードウェアさんかわいそうですぅ！まだ動作検証もしてないのにぃぃ～（悲）。電気ながれちゃうんですよ……」と身を震わせて言うのです。

その瞬間、あなたの組込み女子力がアップします。きっと男は「なんて優しい天使のようなコなんだろう！　絶対に動かしてやるぞ！　コイツは俺の製品だ！」と心のなかで誓い、ハードウェアに惚れ込むはずです。意中の男と付き合うことになったら、そんなことは忘れて好きなだけレジスタを叩いて大丈夫です。「叩けないんじゃなかったっけ？」と言われたら「大丈夫になった」とか「慣れた」、「そんなこと言ってない」「いま検証中だろ」と言っておけばOKです。

TwitterBot開発 ～Twitter連携～

今回は、TwitterBotを作るうえで重要な、Twitterとの連携についての話を。

Torubotは、一定時間につぶやく機能や、自分に関係のあるつぶやき（mention）を確認して
返信を返す機能などを実装しています。

Twitterとどうやって連携してるの？というと、一番直接的な方法はTwitterAPIに直接アクセスする方法があります。

このあたりを見ると、やり方やらが色々出てくるわけですが・・・

僕は難しくてそんなことできないんで、githubから、教えてもらったコンポーネント使ってアクセスします。
正直、一番面倒だなぁと思ったのが、oAuth認証で、コレさえなかったらURL直接アクセスもいいんでしょうが・・・
（お前が内容理解してないだけだろうといわれれば、返す言葉もございません）

んで、神速さんに教わったのが、Tweepyでして。

必要なコンポーネントやらスクリプトの入手

joshthecoder/tweepy - GitHub <https://github.com/joshthecoder/tweepy>

からいただいてきます。

使い方は、ローカルで使う場合は、setup.py があるので、setuptools使って入れます。

setuptools は、このあたりからインストーラを拾ってくれば簡単に入れることができます。

tweepy自体はgithubから取得するので、cloneしましょう。
gitの使い方は、前になんか記事書いた気がする。

HIGH risk LOW return + α: GitをWindowsで使うには？ <http://highrisklowreturn.blogspot.com/2010/10/gitwindows.html>

んで、

> git clone URL

で、ダウンロードしてきましょう。URL部分は

さっきのtweepyのページに、アクセス用のURLがあるので、そこを指定します。

ダウンロードできたら、実際にインストールしてみます。

ダウンロードしてきたリポジトリの直下に、setup.py があるので、実行しましょう。

> python setup.py install

って打つと、インストールが完了します。

次に、bot作るアカウントの情報を持ってきます。

実際に必要な情報は、oAuth認証を行って、トークン集めをします。

全部そろわないと、アクセスできないよ！

でも、やること自体は、そこまで複雑ではなくて、もう一つリポジトリをダウンロードしてきます。
tweepyのサンプル集なんですが、ここにoAuthの認証サンプルがいるんで、そいつを使いましょう。

まずは、githubなので、先ほどと同様に、

joshthecoder/tweepy-examples - GitHub <https://github.com/joshthecoder/tweepy-examples>

ここから落としてきましょう。

ここまでで、必要なスクリプトやコンポーネントがそろったことになります。

アプリケーションの登録

最初にやることは、tweepyからアクセスするアカウントに、自分のアプリを知らせなくてはいけません。

ブラウザから、tweepyからアクセスするアカウントにログインして、アプリケーションの登録を行いましょう。

登録は、ログインしたあと、設定のメニューから行います。

設定メニューを開くと、一番右に連携アプリというタブがあるので、そこを開きます。

さらに、そのページの右側カラムの開発者のところの連携アプリの追加と設定に入りましょう。

こんなページが表示されるので、「新しいアプリケーションを追加」から新しいアプリケーションを追加しましょう。

いろいろ聞かれるので、しっかりと埋めておきます。

重要な部分として、アプリケーションの種類をブラウザアプリケーション、標準のアクセスタイプを Read-Write に設定します

しっかりと埋まっていれば、Consumer Key や Consumer Secret が表示されます。
また、この値は、メモっておくほか、開発者のページに来れば確認することができます。

oAuth認証

実際にoAuth認証をして、アクセスするために必要なTokenを取得します。

先ほどダウンロードしてきたexamplesリポジトリの /oauthフォルダ以下のpythonスクリプトを実行することで、取得できます。

> python getaccesstoken.py

Consumer key とか Consumer Secret を聞かれるので先ほどメモした値を入れましょう。

答えると、リダイレクトで認証番号がブラウザに表示されるので
さらにそれを入力します。

これで、認証が完了し、Access Token/Secret を返してくれます。

この値は、どっかにメモっておいてください。コレが無いとアクセスできなくなっちゃいます。

つぶやいてみる

全部取得できたら、次は実際につぶやいて見ましょう。

つぶやき方ですが、tweepyの使い方の手順として

1. APIクラスのインスタンス（命令を出す本体）を生成する
2. APIクラスから、やりたいことを呼び出す

とっても単純になってます。

スクリプトを見てみましょう。

まず認証して、APIクラスのインスタンスを作りましょう

import tweepy

# create OAuth handler
auth = tweepy.OAuthHandler(Profile.consumer_key, Profile.consumer_secret)

# set access token to OAuth handler
auth.set_access_token(Profile.access_key, Profile.access_secret)

# create API
api = tweepy.API(auth_handler=auth)

これで、準備完了です。

Profileの中には、先ほど取得した値が名前どおりに格納されていると思っておいてください

• Consumer key → Profile.consumer_key
• Consumer Secret → Profile.consumer_secret
• Access Token → Profile.access_token
• Access Secret → Profile.access_secret

の4種類ですね。

認証が終われば、後はツイートするだけなので、つぶやくのであれば

api.update_status(つぶやく内容)

でつぶやくことができます。

その他の機能は？

そのほかの機能については、tweepyのヘルプを読んでみてください。
書いてある内容は、twitterを使ったことある人なら、大体推測がつく内容になってます。

というわけで、自分の作ったtorubotはこのあたりから落とすことができます。
実際にtwitter関連の制御をまとめたtwitter.pyがあるので、興味があればご覧ください。
（ソースは酷いので、あまり気にしないでください・・・）

toru-bot/source/riskrisk-torubot at master from risk/risk – GitHub
<https://github.com/risk/risk/tree/master/toru-bot/source/riskrisk-torubot>

TwitterBot開発 ～開発環境～

ずいぶんと長く開いてしまった。一応仕事がたて込んでたってコトで・・・

本題ですが、開発環境とかの話。

今回のBotは、GAEで動かすことが決定してたので、そのとおり組み立てていきました。

GAE自体は前に毎時50分のタイミングでつぶやく、10分前行動Botを作ったときに
作ったの元データがあったので、いろいろ流用しました。

大まかに、どんなもの使ったかを箇条書きすると

• OS : Windows7
• 実行環境
  • Python - Version 2.6（GAEが2.5だということに、気がつきながらも2.6でやってたとか・・・）
  • GoogleApplicationEngine （実際にソフトを動かすところ。タダおいしいです（＾q＾））
• テスト関連ツール
  • nose （テストフレームワークで、途中からTDDに移行するに当たってお世話になった）
  • noseGAE（nose上でGAE依存のテストをするために必要なモジュール）
  • pymox （Mockを使うために必要 GoogleのPython用Mockオブジェクトフレームワーク EasyMockがベースになってる ）
• バージョン管理
  • git （cygwin）
  • github

を使いました。

最初はTDDとかぜんぜん考えてなくて、Python2.6 と GAE のみで動かしてましたｗ

当初のテストに関しては、何もやらなかったというわけではなく、mainに関数呼び出しをいろいろ実装しといて、
そこが正しく動いたように見えれば「まぁいっか（笑）」という感じで・・・

ちなみに、どのツールもインストールは簡単で

pythonに関してはここ（http://www.python.org/）から、インストーラをダウンロードするんですが、いま2.7で、今回はそれより前のバージョンを使うので

左側のメニューからDOWNLOADを開く、そこのReleaseを開く そうすると、リリースバージョンが選べるので、そこから
お好きなバージョンを選んでください（GAEの開発なら2.5が妥当だと思います）

インストールは、次へ連射になるので・・・

次は、GAEのインストールですが、これもGAEのページ（http://code.google.com/intl/ja/appengine/）から、
ダウンロードを選択して、SDKのインストーラを落としてきます。

今回はPythonを使って開発するので、選ぶツールは

Google App Engine SDK for Python の Windows用

これ、Java用もあるのでお間違えの無きよう。

あとは、次へ連射でインストール完了です。

忘れちゃいけないことなんですが、GAEを使う場合、お手持ちのGoogleアカウントで認証が必要です。
認証方法については、詳しく書かないですが、GAEのホームに、使い方の手順が右側のカラムに書いてあるので、
そちらを参考にしてもらえればと思います。

んで、準備ができたら、ためしにサンプルのGAEプロジェクトを作りたいと思うのが技術者なので、とりあえずなんか作ります

まず、GAEにアプリケーションを登録しましょう。

https://appengine.google.com/ にアクセスすると、自分のプロジェクトの一覧が見れます。

ここの一番下に、

のボタンがあるので、これを押して自分のアプリケーションを登録します。

アプリケーションのIDとタイトルを設定したら、出来上がりです。IDに関しては
あとで、yamlの名称のところに突っ込む必要があるので、どっかにメモっといてください。

正しく登録できたら、次に進みます。

こんどは、自分のPCにGAEのプロジェクトを作りましょう。

GAEのSDKをインストールするとGoogleApplicationLauncher

がインストールされるので、これを使います。

このツールは、ローカルのダミー実行から、デプロイまで一通りサポートしてくれるので、とっても便利です。

まずは、新規のプロジェクト作成です。

こんな感じで、Fileメニューの中に、新規に作成（Create New）と既存を追加（Add Existing）があるので、
Createのほう、選んでください。

そしたら、プロジェクト名とパスを決めろってダイアログ出ます。

ポート番号は、実際にローカル環境で実験を行う場合の接続先になります。
ここで指定された番号（defaultだと8000かな？）を使ってる場合は、別の値にします。

んで、プロジェクトを作ると、ベースは全部作ってくれます（hello worldを作ってくれます）

フォルダの中には

• app.yaml （どこにアクセスしたら、何を呼び出す？っていう設定の書いたてあるファイル）
• index.yaml （いじらない・・・むしろいじったことがない）
• main.py （app.yaml の設定に使われていて、実際に呼び出されるスクリプト）

が出来上がります。

今度はさっきメモったIDを、app.yaml に設定します。

を押しまして、テキストエディタでapp.yamlを開いてくれます。
（テキストエディタは、デフォルトがワードパッドで、上部メニューの、edit -> prefarences... から変更できます。）

applicationのところを、さっきメモしたアプリケーションの名前に設定します

では、実際にデプロイして、Web上で動かしましょ。

右端の２つのボタンが、デプロイ（サーバーに反映させる）と管理ページ（Dashboard）のボタンです。

 

まず、左のDeployを押しましょう。

こんな画面がでてきますので、gmailのアドレスとパスワードを突っ込んでOK

複数プロジェクトを作ってる場合は、Projectのところにプロジェクト名が出てますのでちゃんと確認しましょう
ちなみに、プロジェクトの名前が並んでるリストボックスで選択されているものがカレントになります。

（決して、いまつくったプロジェクトをデプロイしようとしてとおるぼっとをデプロイした
なんてことはありません、ええ、断じてありまｓん）

次に、右側のDashboardを押しましょう。

そうすると、ブラウザに管理ページが表示されます。

左側のメニューから、Application Settings を選択すると
Application Identifier に、URLがあるので、そこのアドレスにアクセスします

左下のところと、右側ののアプリケーションのところです。

実際に、表示されているURLにアクセスすると、

「Hello world!」が表示され、スクリプトが動作したことを確認できます。

次に、Twitterやら、テストやらに特化した話を少し書こうと思います。

@torubot 取扱説明書

とおるぼっとって何なのよ？

@torubotは、池袋のねこカフェ「ねころび」の名物店員「とおるさん」を
いじりたおすために開発した、ツイッターBOTです。BOTは「ロボとおる」と呼んでいます。
とおるさんはTwitter上での活動が、とても活発であり、
毎日ツイッタばっかりしかやってなくね？しかもきなこおんりーなど
「実際のねころび業務はどうなってるんだ！」と疑問に思うほどの出現率です。
名物ツイートは、「イヤッホゥ」。これを聞くためにフォローしてる人も多いとか。
開店時、閉店時に返信イヤッホウを返すと、喜んで絡んでくれる場合がありますが、
最近飽きてきている相手（たとえば@riskrisk）は、あんまり遊んでくれません(´・ω・｀)
噂によると、男一人で行くとやさしいのに、彼女つれていくと話しかけてもくれない とか。
僕はいつもボッチで行きますが、やさしく話しかけてくれます。

機能概要

機能は2種類に分かれています。

• 通常ツイート機能
• 返信ツイート機能

通常ツイート

とおるBotが自主的につぶやく機能です。きなこさんに偏りすぎとか、ロボットなのになぜ生理とか
微妙要素に関しては、作者や周りの人間の偏ったイメージ感を具現化した結果であり、
一部ユーザーには、予想通り過ぎてﾌｲﾀなどの感想をいただいています。

定時ツイート機能

一時間おきに、ランダムでツイートを行います。また、つぶやいた時間を伝えるため、簡易な時報としても使えます。
内容的に、アウトのものも多いですが、いまだ本人からはそこまで怒られていないという不思議と、恐怖があります。

開店／閉店イヤッホゥ！

お店の開店（10:50）と閉店（22:50）に、イヤッホゥツイートをします。
実はこの機能がこのBOTの原点で、とおるさんが休みの日に、ふざけて「とおるぼっと」なる名前で
ねころびスタッフさんが「イヤッホゥ」をツイートしたのが始まりとか。

イベント・予定ツイート

予定日前日の夜（）、予定日の朝に予定をツイートします。
注:この予定は、ねころびGoogleカレンダーより取得しており、予定を約束するものではありません。

記念日ツイート機能

記念日に、特殊なツイートを行います。現在の登録は以下のとおり。

• ねころび開店記念日

返信ツイート

ユーザーの発言に@torubotが含まれている場合に、ツイートの内容をチェックして返信する機能です。
たまに誤検出して、あらぶる場合があります・・・（ロボなんで故障すんのかなぁ）

「イヤッホゥ」返信機能

「イヤッホゥ」成分（イヤッホゥっぽい言葉）を含むツイートに反応して、イヤッホゥを返信してくれます。

• @torubot ｲﾔﾎｩ！
• 今日も一日、イヤッホオオオオオオゥだぜえええええ @torubot

のようにつぶやくと、イヤッホゥ返しをしてくれます。（上記は一例です。ある程度柔軟に検出するはず）

「ウッヒョウ」返信機能

ウッヒョウ成分（ウッヒョウっぽい言葉）を含むツイートに反応して、ウッヒョウ的なを返信してくれます。

• @torubot ウッヒョウ！
• ウッヒョオオオオオオオゥ @torubot

のようにつぶやくと、ウッヒョウ返信を返してくれます。（上記は一例です。ある程度柔軟に検出するはず）

俺はノンケでもペロペロしちまう男なんだぜ機能

「ペロペロ」成分を含むツイートに反応して、とおるBotがペロペロしてきます。

• @torubo ペロペロしておくんなさい
• とおるさんぺろぺろ @torubot

などとつぶやくと、ペロペロしてきます。（上記は一例です。ある程度柔軟に検出するはず）

すくに同意しちゃう男、とおる機能

質問っぽい成分を含むツイートに反応して、とおるBotが同意してくれます。

• @torubot 俺のことイケメンだと思うね！
• とおるぼっと、生理くるって本当ですか？ @torubot

などとつぶやくと、同意してきます。この機能は、開発者の都合により 「マジスカ！」「だよね？」など、
疑問符、感嘆符が付かないと反応してくれないので気をつけてください。

そんな機能でイーノック？

「大丈夫か？」と「イーノック？」に反応して、大丈夫か、大丈夫じゃないかを教えてくれます。
1/2の選択に迷った場合などに使える、とても便利な機能です。

• @torubot おまえさん、調子はイーノック？
• 俺の頭は大丈夫か？ @torubot

などとつぶやくと、大丈夫か大丈夫じゃないか返信してきます。

おみくじ機能

「おみくじ」「占って」などの言葉に反応して、おみくじ返信をしてくれます。
おみくじの種類は、現在３８種類ぐらいですが追加することができます。

• @torubot おみくじちょうだい。
• とおるぼっとよ、今日の運勢を占って。 @torubot

などをつぶやくと、おみくじを引いた結果を返信してくれます。

おみくじ追加機能

「くじ追加」のキーワードを含むツイートの場合、ツイート内にある「」の中身を、おみくじのネタとして追加します。

• @torubot くじ追加 「バート君の寝込みを襲える券」
• 「バート君の寝込みを襲える券」 くじ追加 @torubot

上記例では、1つ目なら「バート君の寝込みを襲える券」というくじが追加され、とおるぼっとから追加完了のツイートが返ってきます。

その他

• おみくじとかは皆さんの協力が必要で、もっといっぱい種類を増やしたいので、このまま運用していく予定です。
• とおるさんがブチキレタ場合や、ねころびさんに迷惑がかかりそうな場合は、連絡なく終了する場合があります。
• とおるぼっとにつぶやかせたい定時ツイートや返信内容があれば、@riskrisk宛に、＠ください
• 追加してほしい機能や、ご意見・ご感想がいただけると、開発する元気になるので、気軽に話しかけてください！
• とおるぼっと返信してくれなくても泣かないで、@riskriskに文句言ってください。直したり、原因を確認したいです！

TwitterBot 開発 ～とおる＠ねころびぼっと開発～

タイトルのやつを開発してみました。

ぼっとさんはこちら！@ToruBot

ねころびってなんぞ？

ねころびは、池袋のサンシャイン裏にある、ねこカフェさんです。

http://www.nekorobi.jp/

サイトのブログや、ぬこさんの写真だけでも、かなり癒されるのでどうぞ！
もちろん、現地に足を運べば、ねこすたっふさんにいやされることうけあいです。

んで、もともとねこかふぇいきたいなーっと思ってて、いかずじまいだったんですが、
行くタイミングがたまたまできたので、行ってみたら見事にはまってしまい、しばらく通いつめることになります。
そこにいらっしゃる、イケメン店員のとおるさんが、あまりにいじり易いとは感じてたんです。

とおるさんについては、また後で語るとして

これを作るきっかけになったのは、忘れもしない正月明けのモンハンオフ（まぁ日付わすれたけども）
本人に、「とおるさんいいなぁ、botつくっていいっすか？」って聞いたら、「好きにやって良いですよ」って言うもんだから

じゃあそういうことなら ということで、作り始めました。

開発期間は意外と長くて、いろいろ試行錯誤しながら２ヶ月近くやってる気がします。

時間は、土日とか、行きと帰りの電車とか昼休みとか、基本空き時間なので、そんなに長くないかなと思いますが
（たまに、長いmakeやってるときとかにいじったりもしましたが）

現在の表に見える機能は

• 通常のツイート機能（一時間に一回呟く。うざくない時報とあとで命名された）
• 開店・閉店のｲﾔｯﾎｩ機能（朝11:00に開店、夜23時に閉店のツイートとを行う。

当初は、これだけしか考えてませんでしたｗ

その後、通常ツイートの機能を調整していくわけですが、
その結果生まれてきたのが、適当に呟くだけでいいのかな？っていう疑問。

どうせ作るなら、役に立つ機能を追加していこうってことで

• GoogleCalendarと連携して、お店の予定を前日と当日にお知らせツイートする機能
• ねころび三周年記念があったので、その日だけ荒ぶってしまう、アニバーサリー機能

とかを追加していきました。

途中、返信してくれたら楽しいのにね！っていう意見をいただいてたので、さらに付け加えて

• イヤッホウに返信してくれるイヤッホウ返し。
• ウッヒョウに返信してくれるウッヒョウ返し。
• 俺はノンケだってペロペロしちまう男機能
• なんだって同意しちゃう激しく同意する機能

を追加しました。

その後一通りテストとか追加しだして、停止してましたが

• そんな機能でいーのっく？
• リフォロー機能（鍵つきだとダメなんだって・・・）

を実装して今に至ります。

いまのとこ、ここまでの実装ですが、今後もいろいろ増やしていく予定です！
そろそろぼっとのTopページに、取り扱い説明書がほしくなってきましたｗ

Shibuya.trac #10 勉強会

でぶさみのあとに、強行突入です！

スタッフの中にも、連続してやっていただいた方も多く、皆様ほんとうにお疲れ様でした。
また、参加してくれた方や、会場スタッフの方、皆様本当にありがとうございます。

今回は、司会をやることになったので、話をしっかり聞けるか不安だったんですが
司会業を地味に忘れて、しっかり聞いてしまいました。
（マイク持つとか、気がつかなくてごめんなさい そしてありがとうございます @wyukawaさん）

@tosikawaさんの、神速ファンクラブ広報

初めて公式に、広報していただきました。

例の隣の人ですね。でも、隣の人って大事ですよねっていうのを認識させていただきました。
（あそこまで、溺愛は僕にはちょっと難しいですが、女の子なら・・・）

それと、ちょっと変な割り込み方してしまって、グダグダをやらかしました・・・
多分ステッカーも結構あまってるみたいなんで、頼むともらえる？

こんどから、Shibuya,tracの勉強会告知に、

「Shibuya.tracで神速さんと握手！」

みたいなの、美味しいですかね。

Oかもとさんの、とある券売機の改善記録（Kanon発表会）

いきなりタイトルとぜんぜん違う話になったので、誘ってもらえないからキレたのか！？と思ったり。
実際は、Ticketシステムの改善としてKanonへっていうことでよいのだろうか。いいんだろうな

素直に、Kanonいいなぁと思いました。いまやってるプロジェクトも、Linux上での開発なので
TracLightningだとCIサーバーを別に用意してるんですよね。

まぁ、素のtrac使えばいいじゃんって言われちゃうはずですが、TracLightningらくちんなんだもんｗ

そんなこんなで、開発者募集とかしているようなので、参加できたらいいなぁと思っていたり。
（僕のスキルが足りないとかそういう話は、またあとで検証しよう）

こくぼさんの、RedmineとBacklogs

かんばんが、すごい衝撃的だった。昔こういうのあったら、意外と使うようになるかな？って
話してたのが現実に存在してた。

というわけで、Redmineに興味をもったとか。
使わなきゃいけない場面もあるので、これを機にはじめるか・・・

子供かわいい。

LT: @wyukawaさんの、Tracユーザーから見たMantis

Mantisの画面を始めてみたけど、色合いが見やすいなと思った。

LT: ふじはらさんの、EnterpriseRedmine

ここまで広範囲に広がったBTSの話を聞いたのが初めてだった。
広がり続けたときの問題点とか、対策とか、勉強するところは多かった。

LT: @ikikkoさんの、モテBTS～Backlog～

モテるのか・・・。それはそうと

僕も地味にBacklog使ってるんですが、あまりなじみの無い人でも使えるのは、
じぶんちの嫁で確認済み。すごいなぁと思ってます。

LT: @Sean_SFさんの、チケット管理システム大決戦 本戦

本戦やるのかっ！ 実際、戦う必要があるかどうかは不明として（ｗ）、どのツールが、どういう用途に向いてるってのは
まとまって話す機会が少ないと思うので、気になる気になる

そっち方面に詳しい人は、このWikiに書き込んでほしいそうです！コメントでもOK!
あと、すでにKanonも入ってるなぁ、すごい Backlogも参戦

LT: @kawagutiさんの、Scrum in 10 minutes

5分にしてごめんなさい、でも、わかりやすかった。スライドここで見れる。なんども見る。

以上です。

自分のこと

とても楽しく過ごせました。時間調整とか、おかもとさんのデモ切っちゃうとかもあったので
申し訳ない部分もありましたが、いろんな人に、「よくやった」って言ってもらえて、涙でそうです。

思えば、@kaorun55に、元のスライドをもらい、@kanu_さんにコミュニティ紹介スライドを提供してもらい
@tyobichiさんに、タイムテーブルとかの情報をもらって資料をしあげ、
前説で、@tosikawaさんがまとめてくれたのに、変な付け加えをし・・・
@LightningXさんに、「すまないが、先にやってくれないか」と言い、しかもデモを削ってもらい・・・
@ikikkoさんの時間を10秒勘違いし。

いろいろあったけど、楽しかった！

そういえば、@kaorun55のTracの事を書いた記事を紹介するの忘れてました。

とりあえずここで紹介しておこう・・・

http://gihyo.jp/magazine/SD/archive/2011/201102

これ！Tracを使ってプロジェクトを改善するってことについて書いてある。
しかも、実際にやった事を記事にしてるから、空論じゃないんだぜ！

と、やっつけ気味に、れぽ終了・・・

DevelopersSummit2011いってきた

祝・初参加！

セッションは、4つほど聞かせていただきました。
あと、OpenJamに参加しました

• 17-B-3 「チケット駆動開発～タスクマネジメントからAgile開発へ～」
• 17-B-4 「チケット管理システム大決戦」
• 17-B-5 「今そこにあるScrum」
• 18-B-1 「プログラマが知るべき、たった一つの大事なことがら」
• すくすくスクラムのOpenJam

今回も感想のみですが

17-B-3 「チケット駆動開発～タスクマネジメントからAgile開発へ～」

うちの会社にTracを入れよう！ってなったときに、昔別のとある会社で
BTSを使ってたときのメイン用途が、バグ管理だったこともあって
バグ管理ってイメージが強かった気がします。

いまはタスクとかも入るようになって、じわじわと「チケット」っていう言葉が
浸透してきてるのかなぁ・・・（まともに使えてないからダメ？ｗ）

バグ管理とかから、チケット中心（no Ticker no commit）みたいなことが
習慣として根付いたら、「やらなきゃいけない」から、「自然とやっている」まで
移ることが出来るかなと思ったり。

実際、いつぞやの新入社員は、最初っからTracがあって、チケット登録してから
仕事するんだよって、いまはなきあの方が指導したら、自分よりしっかりと
チケット管理してたきもします。

自分を 強制 というか 矯正 する必要がありそうなきがしてたのを思い出しました。

17-B-4 「チケット管理システム大決戦」

そのあとのチケット大決戦は、後で本戦の話題も出るほどでｗ

ただ、聞いてて思ったのは、どれもツールであり、ツールを使ったから
改善するわけではなく、適したツールを使うことでより良い改善が出来るということ。

僕自身、実はTracっていうツールから、勉強会とかの世界にはいって、
そこをきっかけに、あーこういう手法とか、ああいう開発方法があるんだなって
やってきました。

なので、最初はツールに使われててもいいと思うのです。
ただ、忘れちゃいけなくて、ツールは助けてくれるけど、それは自分が
助けを求めたときだけなので、きっかけは自分から。一歩進むのも自分ですよね。

17-B-5 「今そこにあるScrum」

Scrumの話ですが、応援団がいっぱいいらっしゃって、素敵だったと思います。

確かに、あしたScrumをやれといわれるような現状で、何も知らないのはどうかと思う。
そもそも、できるにも種類があって、普通にできるものと、苦しんで死ぬかもしれないが
やろうと思えば出来る という、2種類。おそらく、Scrumをいきなりやれといわれたら後者。

知ってる人間だけあつまってやればいいなら、まだどうにかなるにしても
まったく知らない人を上手く導くすきるなんて、無いです。

だからこそ、開発手法の概要だけでもある程度理解しておくことで、
仲間の誰かが、「やれ」といわれたときに、よしやろうって周りが言ってあげられたら
いいのになぁとか思います。

あとは、Scrumをやることが目的になっちゃうのがマズイってのを再認識。

Agileをやりたいからやる んじゃなくて、Agileは必要だから導入する。
Agileでないと実現できないから、自然とAgileになっていく

みたいな。どこかで聞いたぞ。AgileDayか。

18-B-1 「プログラマが知るべき、たった一つの大事なことがら」

なんか、心に響いた。

僕自身、まだインプットすら中途半端で、たまにブログを書くぐらいになってるけど、
自分で伝えられることがあるなら、やりたいなぁと。

素直に、かっこいいな と思ったし、あこがれもした。

あと、年下から学べるかどうかっていうのは、やっぱりそうなのかと思った。
というか、ぼくの周りには、恐ろしい年下の方ばっかりで、こないだ、この人何歳なんだろって聞いたら
自分より年下のあまり、なんかいたたまれない気分になったりと。

「25歳以降は、自分が何をしてきたかなので、別に年齢なんか関係ないさ！」とか、話すことも多かったけど、改めて実感

後日談で、かおるん（@kaorun55）に、「ボクカラマナンデルジャナイデスカ」って、冗談交じりに言われたけど
彼が居なければ、こういう勉強会とかに参加することも無かっただろうし、tracすら触ってなかったかもしれない。
わださんに、師と呼べる人がいたように、自分も誰かに教わりながら、誰かに伝えながらやっていこうと。

ドラムサークル体験 すくすくスクラム OpenJam

なんか肩が重いし、休憩しないとやばいなぁ思いながらブースすわってたら、やってくる@Qooh

「OpenJamにおいでよ！」

と誘っていただいて、何々？いくいくｗ とホイホイつられたわけですが

クリエイティブになるための、子供に戻るセッション？ｗ

あいかわらず、林さんの空気に飲み込まれてる（こないだのエクセレントサークルとか）気がするけど、よしとする。

実際にやってみると、最初は正直、こっぱずかしいなぁと思ってやってたけど、だんだんどうするんだこれみたいな
お題が振ってきて、最終的にはなんかノリノリでやってたｗ

やっぱりものをつくるのは楽しくなきゃいけないですね。

実は後日談があって、ついったでも少し喋ってたんですが、こどものクリエイティブがどんだけか試してみたんです。

何をしたかというと、2歳になる娘と、コタツのテーブルに、模造紙敷き詰めて、絵を描いてみました。

結果的に、僕が小さい絵を一生懸命書いてる間に、模造紙がいろんな色の渦で8割ほど埋め尽くされて
それでもまだ楽しそうにペンを握って、叫びまわる娘がそこに居ましたｗ

やっぱり子供のほうが、思うがまま、いろんなことが出来るんだなぁって実感しました。

ぼくは、線一本引くだけで、ものすごい迷ってましたし。とにかくやってみるってのは、子供から学ぶ部分も多いのかなｗ

Shibuya.trac お店番

今回の僕のメインイベント。

スーツ率が高いってきいてたので、ちょっとgkbrしながら、行ったんですが、Shibuya.tracのブースはいつもの空気でしたｗ
（kanuさんがいたから？ｗ）

ビラ配ったり、ビラの説明したり、ボードにシールはって～ってお願いしたりと、いろいろやって、
いろんな人が、同じような悩み抱えてるんだなぁって認識できた。

あと、ブースを見てくれた人で、組み込み関連技術者に会えたのが、すごい大きかった。
組み込みに、新しい文化を入れるのは大変だよねーって会社で話していた、直後の出来事で
そう思ってるのが、自分だけじゃない って思えるようになって、やる気++

というわけで、僕の初でぶさみは、盛況のうちに幕を閉じたのでした。

Shibuya.trac #10 は、別記事でｗ

Windows の python と Cygwin の共存ではまるの巻

ちくしょう、昨日の夜中と今日の午前中を返せ！

というわけで、Windowsでpythonやってるんですが、

Windows Python2.6 と cygwin の入ってる環境で、
見事にはまりましたので、現象と解決策をまとめます。

まず、何が起きたかというと、Windows版でeasy_installを利用する場合
インストーラーにて、インストールすることになります。

で、使えるだろ思って、今回はNoseGAEをインストールしようと

$ pyhon setup.py install

と行くわけです。で、出てきたメッセージは、

  File "setup.py", line 1, in <module>
    from setuptools import setup
ImportError: No module named setuptools

なんのことかと思いました。だって僕インストールしたもんさ！

そして悩むこと数時間。pythonを起動するといつも出てくるメッセージに
違和感を覚える。

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

cygwin？

cygwin？

cygwin？

・・・

あ、共存に失敗しとる？

というわけでGoogleさんに聞いてみると、一発でこちらのページに
たどり着きまして、「そりゃそうだよね」と納得した次第。

環境変数のpathでcygwinのほうが、優先度が高くなってまして
Windows版のpythonが呼ばれてなかったようです。

また、あわせてpythonのパスも設定しておく必要があるそうなので、それも。

PATHの先頭（cygwinのパスより先に、pythonのパス
（デフォならc:\python26あたり）を設定してあげると、Windows版を呼びます。

Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

こんな風に出たらOK！

あと、PYTHONPATH（説明）を設定しておくと、setuptoolsも探しにいってくれるはず。

PYTHONPATH の環境変数を新規に作成して、site-packagesを追加します。（デフォなら c:\python26\Lib\site-packages\ あたり)

これで、easy_installを使うセットアップ呼び出したら動いた！良かった・・・

たぶん、この時点で気がつかなかったら、GAE関連やり始めて、さらにカオスに陥ることうけあい。不幸中の幸いかなぁ・・・

github で協力開発

せっかくgithubなので、協力者について少し書いておこうと思います。

githubはタダの場合は、問答無用で公開リポジトリです。

ただ、公開されてるだけなので、読み込みは出来ても、
書き込みできないようになっています。

協力者の設定を行うことで、書き込み権限を与え、開発ができると。

すばらしい。

方法は簡単で、まず条件ですが、

• 協力者がgithubのアカウントを持っていること

です。

では方法。

まず、一緒に開発するためのリポジトリのページを開きます。

右上あたりに「管理」ってボタンがあるので、そこを押します。

そうすると、リポジトリの設定画面が表示されます。

協力者の部分を開いて、追加したい相手のIDを、入力エリアに入れます。
ちなみに入力すると、かっこいいウィンドウが開いて、候補を出してくれます。

入れ終わったら追加を押すことで、協力者を設定できます。

相手が、リポジトリのページを開けば、読み書きできる方の
リポジトリのURLが表示されているので

$ git clone <gitリポジトリのURL>

で、ローカルリポジトリを作りましょう。

あとは前の記事のとおりです。

少し追記しましたが、前の記事では、自分でremoteとか設定してますが
cloneの場合、勝手にはいっているので

リモートリポジトリに変更を反映する場合は

$ git push

リモートの変更点を、ローカルに反映するには

$ git pull

でいけます。

githubではじめるgit

本日会社にて、「gitむりっす、コマンドラインがっ」って言われたんで
とりあえず使うだけでも使えるように、少しまとめてみようかなって。

何を題材にしようかとおもったら、とりあえず、git-svnからとかだと
いろいろ紛らわしいので、まずはただの git からいこう！と。

世の中には便利なサービスがあって、githubという、自分のリポジトリを
タダでもてるという素敵なサービスがあるんです。
まずは、それを使って、最初のコミットまで。
（実際は、チュートリアルがあるのでそのとおりなんだけど）

対象は、Windowsをつかってて、git使いたいけど、試すのが・・・とか
コマンド難しくて、なに覚えていいかわかんねぇんだけど・・・な人です。

ゴールは、とりあえず一連の操作できるようになったらいいね！ってことで

githubに登録する

https://github.com/ にいくと、ロケーるが日本であれば
上のほうに、「日本語で使う？」って出るので、「はい」と素直に。

日本語になるんで、ど真ん中のでかい新規登録ボタンを押します。

そしたら、とりあえずお金使いたくないので、
公開リポジトリを作ることにします。

一番上に、オープンソース用無料プランがあるんで、ここを選びます。

必要な情報を入れて、ぽちっとアカウントの作成を押します。

これで登録は完了。画面はダッシュボードへ移動します。

リポジトリを作ってみる

登録できたんで、次はリポジトリを作ってみます。

まず、右端に

おまえのリポジトリねーから って言われてるので、
自分のリポジトリ作ります。

新しいリポジトリ のボタンを押して、リポジトリ作成画面へ
（ちなみに、下の「リポジトリを作りましょう」をクリックしても同じ画面です）

リポジトリの情報を入れて、作ってください。

最初のやつなんで、プロジェクト名は自分の名前。
説明は、「俺の伝説の始まりだぜ」とかで。
ホームページはあれば入れとくと、リポジトリのページに表示されたりとか

あとで修正できるので、optional部分（説明、ホームページ）は適当で大丈夫

アクセスできるのは、「誰でも」で。アップグレードするとお金かかるんで。

これでリポジトリが完成。今度はクライアント側の設定をしましょう。

gitを使うための、クライアント側設定

今回は、Windowsホストを対象にしてるので
gitはcygwinでやりましょう。
インストール方法はここを参考に。

gitとopen-sshがインストールできたら、cygwinのコンソールを開いて
とりあえず git用のフォルダを作ってそこに入っておきます。

$ mkdir git
$ cd git

まずは、自分のユーザー名とメールアドレスを共通設定に
書き込んでおきます。

$ git config --global user.name "ユーザー名"
$ git config --global user.email "メアド"

ちなみに、--global で、共通設定 付けない場合は、
リポジトリ固有の設定になります。

次に、一番引っかかる、鍵の作成をします。

open-ssh をつかってやるんですが、まず仕組みを。

鍵を作ると、公開鍵と秘密鍵が出来るんですが、公開鍵のほうを、
githubに登録しておくことで、クライアントを認証します。

これをやらないと、コミットすることが出来ませんので注意です。

で、やり方ですが、ここが参考になります。

まず、鍵を作ります。

$ ssh-keygen -t rsa -C "メールアドレス"

インストール場所聞いてくるので、普通はそのままでOKです。
前に作ったことある場合は、上書き確認が出ます。
大事な鍵の場合もあるので、上書き確認でたら、バックアップとってから
もう一度やり直してください。

パスフレーズを聞かれますので、必要であれば入力してください。
必要なければ、何もいれずにEnter。再入力きかれるので、Enter
（パスフレーズ設定した場合はそれを入れてEnter）

そうすると、鍵が出来上がります。

公開鍵側を、githubに設定するので、鍵のフォルダに移動します。

場所は、先ほど鍵作成時に指定した場所（通常は、ホーム/.ssh）です。

ここに、「id_rsa.pub」というファイルがあるので、これをcatします。

$ cat id_rsa.pub

そうすると、公開鍵の情報が出てくるので、とりあえずクリップボードに
コピーしておきます。

次に、githubのページに移動しましょう。

右上のメニューから

アカウントの設定を選んで、その画面の

SSH公開鍵 を選択、隣の「別の公開鍵の追加」をクリックします。

タイトルと、キーを聞かれるので、タイトルには、

メールアドレスとかで分かりやすく。

キーの部分に、先ほどcatで表示した公開鍵を丸々貼り付けます。

終わったら、キーの追加を押すと、正常に完了すれば

こんな感じで、登録されます。

これで鍵の登録は完了、無事、リポジトリに
アクセスできるようになったわけです。

実際にリポジトリにアクセスしてみようか

リポジトリにアクセスできるようになったので、実際にファイルを入れましょう

まず、githubの画面でダッシュボードに戻って、右下の自分のリポジトリを
クリックしましょう。

手順が画面に表示されていると思うので、そのとおりに行きます。

1. mkdir リポジトリ名
   まず、リポジトリになるフォルダを作ります
2. git init
   リポジトリとして使うために、gitに .gitフォルダを生成してもらいます。
3. touch README
   コミットするファイルがないとこまるので、touchで適当に作ります
4. git add README
   コミットするファイルとして、README を追加します。
5. git commit -m "first commit"
   コミットメッセージを first commit でコミットします。
   -m で直接メッセージ入れてますが、別に付けないで
   エディタでメッセージ編集してもOKです。
   エディタの場合は、コミットメッセージを書き込み「保存」して、
   エディタを閉じることでコミットされます。保存してない場合は
   コミットされませんので注意
6. git remote add origin <githubの読み書きできるURL>
   originって名前で、指定したアドレスにアクセスするよーって命令
   origin自体は特殊な名前であってうんぬんかんぬん。
   とりあえず、いま作ってるリポジトリは、指定したURLと、
   関連づいてるんだ！っていう設定
7. git push origin master
   origin で設定したリモートのところの、masterってブランチに
   コミット内容をpushします！

こんな感じで、最初のリポジトリ作成まできました。

githubの画面

こんな風に、コミットした感じが見えますかね？

普通、こんな感じでつかうよね？っていう流れ

リポジトリもできて、最初のファイルも出来たんで、
次に、自分の作ったファイルとかをコミットしていく流れをやってみましょう

まずは、作業用のブランチをきりましょう。
masterブランチは汚さないようにするのが一番です。
ネットワーク経由の動作でコンフリクトすると面倒なので。

作業用にwoking というブランチを作ってみます。

$ git branch working

作ったブランチに移動します

$ git checkout working

ここのあとは、ファイル作ったりして、追加したり
開発らしいことします。

$ git add <ファイル名とか . とか。 再帰的に探してくれるよ！>

いらないファイルは、消してみたり
（手で消すと、整合性が取れなくなるので、gitのコマンドで消してね）

$ git rm <ファイル名>

一通り終わったら、commitしましょう

$ git commit

-m "メッセージ" でメッセージ直接いれてもいいですよ。

コミットが終わったら、

$ git log

でコミット情報を確認したり

$ git status

で漏れを確認したり。

$ gitk

gitkの素敵な表示で満足したり。

ちゃんとcommitできてそうなら、masterブランチに戻りましょう

$ git checkout master

ここから、サーバーにアップロードする準備です。

サーバーから、最新の情報を拾ってmasterブランチを更新

$ git pull origin master

最新の状態になったら、自分の変更（working）をマージしましょう

$ git merge working

変更が反映されてることを

$ gitk

とかで確認してOKそうなら、リモートへ送り込みます

$ push origin master

あとは繰り返し。

ここまでできたら、あとは繰り返すだけですよね。

最後に。

自分のリポジトリとかを、

$ git clone <リポジトリのurl>

とかでやったぱあいは、pushとかpullは、クローンしたところが元になるので
push/pullの origin やら master やら、指定しなくても動いたり。
（リモートが自動設定されるんだっけ？この辺よくわかってない）

色々やってみるのが一番早いと思いますが・・・

迷ったら、git help もありますし。聞けば誰かが。

追記

git clone すると、configに各種情報が自動で入るんですね。
なので、指定しなくても動くと。

最初の作成だけやったら、clone で作り直しちゃったほうが楽かも。とおもた

Foxit Reader

PDFで資料読むのに、思いの外野でAdobeReader入れないで、
GoogleChromeで読んでたんだけど、

本当に、良いPDFリーダーは無いのかなと思って、Google先生に聞いてみたら

FoxitReaderってのがでてきた。

現在バージョンが2011年2月現在で 4.2 ですね。

良いところぐらいしかまだ見えてないんですが

• 起動が早い
• 動作が軽い
• 簡単な編集機能がついてる

ぐらいでしょうか。とりあえず困らないレベルで使えそうなので、
しばらくこれで行きます。

インストール方法は、ここからダウンロードするあたりのボタンでたどって
セットアップを落として実行でOKです。
日本語版がちゃんとあるので、いいですね～
（プログラムに関しては英語でもいいけど、普通のソフトで英語だといろいろ読めん）

Innovation Sprint 2011 に参加してきた

いってきたぞおおおおおおおおおおおおお

こっちもいまさら書くなですけど。

実際、何かいていいかよくわかんなくてですね。

一番印象に残ってるのは、やっぱり
野中郁次郎先生と、JeffSutherland先生のセッション

野中先生のほうは、最初SCRUMの元になった考え方とか
そういうものの「解説」って感じなのかと思ってたら、もっと根底にある
知識についてとか、Innovationはどうしたら起こる、どうやって起こすとか

Jeffさんのほうは、英語ぜんぜん聞き取れないし、しゃべれないんですけど
平鍋さんの説明と、Jeffさんの身振り手振りで、少しは聞けたかなぁ
（途中、聞き取りやすい英語に変わったので、意識していただけたのかもしれない。）

んで、内容云々は僕が説明するより、ほかの方のサイトを・・・
（僕には、うまく説明できない、くやしい）

んで感想を2つの視点から

自分自身変わろうと思った（変わった）こと

• やろうとしてやってないことが多いってことに、
  改めて気がついたこと（いつもどおりだけど・・・）
• やれるはず って言われて、いままで失敗した～と
  ばかりいってて、なんでできなかったか、
  しっかり考えていたのかという疑問を持った。
• Anyting is possible !
• しかたないのでを卒業すべき。「しかたないのでやる」ぐらいならやらないか、もっといい方法を探す。

次に何しようか

• SCRUMっていうテーマのイベントに参加しておいてアレだけど
  別にスクラム以外でも、自分の周りや、仕事にあうスキルを
  模索してみる。
• もうちょっと本を読む
  （積み本が増えてる、忙しいをいいわけに読まない）
• 英語。

最後に、Innovation Sprint 2011 について、社内に、
ちょっと話を聞いてみてくれ！って、もっと強く出るべきだったと後悔してる。

自分で話をして、影響を与えられるのが一番かもしれないけど
やはり、人によって言葉の力は全然違うことをを再認識した。

shibuya.trac 新年会

いまさら書くなって？

いいじゃないか、まだ二週間たってないｗ
書かないほうがもっと良くないんだぞ！

というわけで、1/7に、Shibuya,tracの面々と、新年の挨拶をしてきました。

まず、幹事の@nekotankさん、ちょーおつかれさまでした。
非常に楽しく飲むことできました。

最初のほうは、TracLightning3がっ！とか、自己紹介とか、わいわいな感じ

そして、途中から始まる Shibuya.trac恒例（？）の

神速さん（@sinsoku_listy）いじり。

ちなみに、本人はいらっしゃってません。

電話にて、「しゅっしゅした？」と聞き続ける姿

複数の人間から電話がかかってくるのに、電話の先の人は同じという恐怖

どれをとっても高品質のサービスを提供できたと思います。

んで、後半は、こゆい話とか、神速Pluginとかｗ

ちなみに、神速pluginは、少し手をつけたものの
（いいわけ）ログインしないとAPI経由で個人のツイート拾えないっぽいので
HTML解析にしようとして、HTMLParserに食わせたらエラーが出てとか
僕のレベルじゃちょっとまだ難しそうなので、またPython勉強に戻りましたｗ

というわけで、おいしく楽しく、飲ませていただきました。

デブサミのお店番も、手伝えるかどうか分からないとかいいつつも
どうにかがんばって予定調整してみる！