pivotalの日本からの支払方法誰か教えて

ハッカソン用にpivotalでproject作ってcollaborators登録しようとしたら、freeだとcollaborator一人(自分)しか作れない。

http://gyazo.com/88fab44b58ef68331059e5403dde1377

じゃあ月$7ぐらいなら支払いしてもいいよなーとカード番号入れてjapan選んだら、united statesとcanada以外のカードは受け付けねー!! って言われた。pivotal推しのオマエラどうやって支払いしてるんだ。あとstart upでもすぐ10人ぐらい超えそうでどうしてるんだろう。8人$50、11人$100でーす、て言われるとその価値認めててもウッってなりそう。pivotal cloneのfulcrum使うといいのかなあ。ちゃんと支払いたい。

ハッカソンのプロジェクトは、privateじゃなくてpublicにしたらfreeでcollaborator登録できたのでよかった。

fulcrumの使い勝手そのうち聞いてみたい。

herokuにfulcrumをインストール – komagata
malclocke/fulcrum

アジャイルサムライ

アジャイルサムライを”やっと”読んだ。書き抜きとメモと思ったことと8:1:1ぐらいでごっちゃに。
2012-03-31

アジャイルな顧客
顧客を直に開発に巻き込む

アジャイルなアナリスト

アジャイルなプログラマ

アジャイルなテスター

自分は何が得意なのか
テストコードが得意デプロイが得意サーバの構築が得意サーバのメンテナンスが得意
自分はどうやって貢献するつもりか
リリースできるものをすぐに作ることができる自動化省力化
自分が大切に思う価値はなにか
良いと思うものをすみやかにユーザに提供できることアプリが困ったふうに落ちないことアプリは困ったら落ちること
チームメンバーは自分にどんな成果を期待してると思うか
特に困らずなんでもできることいろんな条件を見落とさずにリリースまで行けること
セキュリティとかパフォーマンスとか

インセプションデッキ
– われわれはなぜここにいるのか?
– エレベーターピッチ
– パッケージデザイン
– やらないことリスト
– 「ご近所さん」を探せ
– 解決案を描く
– 夜も眠れない問題
– 期間を見極める
– 何を諦めるのか
– 何がどれだけ必要か

プロジェクトは自分たちチームのものなのか? 顧客のものなのか?
“チーム”って? わかりやすいプロダクトオーナーが居るケースってあんまりなさそう

期間、スコープ、予算、品質

われわれはなぜここにいるのか
自分自身で確かめること
君の「司令官の意思」を把握すること

この質問の答えだ！と考えた理由はなんなのかを話しあうこと

エレベーターピッチをつくる
独自ローカライズで別アプリって、代替の最右翼が大成功してる本家って時点で自家中毒じゃん

夜も眠れなくなるような問題
プロジェクトのリスクを書き出す
リスクを話し合うのは良いことだ

取り組む値打ちのあるリスク
値打ちのないリスク

期間を見極める
小さく考える
プロジェクトへの長さの期待をマネジメントする

システム全体で想定していたビジネス上の利益

インデックスカード
要求を収集するときの一番の目的
フィーチャーのあらゆる詳細を聞き出すことじゃない
フィーチャーの本質を捉えるキーワードを書き留めておくこと

ビッグウェイブ・デイブ
– 開催予定のイベントを一覧できる
– ビーチの様子を撮る
– とったビーチの様子を中継する
– 物販へのリンクを貼る

<ユーザの種類>として
<達成したいゴール>をしたい
なぜなら<理由>だからだ

開発チームは同じ仕事場に集まって作業して
ちゃんと動くソフトウェアを成果として
目の前の顧客へ定期的に見せていくこと

大事なのは価値につながる習慣を守ること

Acts as agile
– 毎週、価値ある成果を届けられているか
– たゆまぬ改善のための努力を惜しまず続けているか

ランチ社内読書会やってみた塹壕よりScrumとXP

ランチ社内読書会やってみた。
塹壕よりScrumとXP – Scrum and XP from the Trenches

4回ぐらいでさらっと終わらす予定だったのだけど、10月末から12月末まで7回もかかった。

きっかけ
kawaguti: アジャイルに興味があるソフトウェア開発現場の方は、とにかくまず「塹壕よりScrumとXP」をみんなで読んでみることをお勧めしたい。InfoQ Japanより無料で手に入る。
http://twitter.com/kawaguti/status/28705637412

pdf入手場所
http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

進め方
ぼくが章の中身をメモってきて、それを肴に社内の実際のプロジェクトでどうやってるのか、の話を振る感じに落ち着いた。
負担と見返りとを考えるとこれが出来る精一杯かなあと。
事前に読んできてもらうのも、それが出来るようにまとめてくるのも、どちらもハードル高い。
自分にファシリテート力もコミュニケーション力もないので、参加してくれた同僚のおかげでどうにか一通り回せた。
半年後に、もう一周やってみる。

はじめたときの立ち位置
ぼくがxp厨 xpは一人からボトムアップで出来るし
でもscrumよくわからない　組織論ばかりでうさんくさいとおもってた
社外のアジャイルな開発のひとたちでscrumな勢力強い
社内にscrumっぽいやり方が導入されはじめた
xpでもscrumでもリーンでもなんでもいいや小異を捨てて大同につこうそれがアジャイルマニフェストだよね
まず知ろう

やってみてわかったこと
読んでメモして説明するだけで、分かりにくかったことも同僚がフォローしてくれてどうにか頭に入った
開催日の締切り駆動だと泣きながらどうにか頑張れた
毎回新しい人が見にきてくれた
圧倒的に自分が得

課題
開催曜日時刻が安定しなかった
→ぼくの業務都合
質の問題
→ぼくの慣れでどうにかなる部分とならない部分だなー

以下資料
slipはsafariで見えなかったと思う
https://github.comからのリンクを開けば雰囲気はわかる

テストに関心あるプログラマとアジャイルに関心あるテスターの架け橋

“実践アジャイルテスト”を読んでよかったと思ったのでメモする。

中身
テストに関心あるプログラマとアジャイルに関心あるテスターに向けての話。
品質管理部門のある会社で働いたことないし、ガチガチの納品物を作成したこともないので、どこか他人事だった。
なので問題意識としては分かるけどそもそも語彙からよく分からない部分だった。

どこで知ったか
ウノウラボ Unoh Labs: テスト本の読書会を行います。
参加しそこねたのが残念。

自分の立ち位置
BDD厨。単体テストやコンポーネントテストをもっと軽く速く繰り返ししたい。ロジックのテストを書きたい。その部分のテストでDBさわりたくない。
テストしにくい部分や時間がかかる部分、一番表の表示部分は、一旦テスト無くてもいいor薄くてもいいと思ってるしそういってる。
極論すれば表示はどうあれ適正に計算が行われていればいいでしょという。

8割ぐらいは本気でそう思っているけど、やっぱそれじゃまずいよね、どうするかな、というのが本音。
知ってて切り捨てる所と知らないでフワフワにしてほかのひとがいうのを見た気もするので切り捨てるの溝を埋めるために、読んだ。

読んで思ったこと
ビジネスとしての実現価値の視点から目を逸らしてもしかたないなと再確認。
あと横道だけど、携帯サイトでキャッキャうふふする以上、3キャリアでの実機表示というのが一番偉いわけで、ハッピーパスは手でやるのかなあと思う。
投げっ放しだけどおしまい。

api変わるレベル以外のバージョンアップはheadについていくべき

個人的には、外部ライブラリはapi変わるレベル以外のバージョンアップはheadについていくべきだと思っていて、なのでsvn:externalsやgit submoduleやbundlerのアプローチはすごく楽しい。
ただ世間一般的にはバージョンを固定して使い続けるのが安全な認識があって、理屈としてはこちらが当然正しい。ただ理屈に反してでもheadを追いかけていく方が最終的には幸せになれるような気もしている。もちろんheadを追いかけていくことで本質ではないバグにハマって時間を浪費するのも不毛なのでバランスかなあと日和っておく。

となると、ライブラリは全部リポジトリに突っ込んでおくのが安全なのかなあ。

webアプリなんて「あれれうごかない
ごっめーん」で済むようなものだと思っていて、それはたとえgmailクラスのインフラになっているものであっても同じと思っている。もちろんそうならないように開発を駆動するテストと網羅して担保するテストが必要なのは前提でね。そうしていけたらよいですね。

『パターン、Wiki、XP』刊行記念トークセッション聞いてきた

江渡浩一郎
著『パターン、Wiki、XP』（技術評論社）
刊行記念トークセッション
を聞いてきました。

＝＝＝
2009-07-09 19:00-
@池袋ジュンク堂
以下＠以下は自分の感想

●江渡
便利と思って追加した機能が実は悪い機能なことがある
wikiの本質を強化する機能
→wikiの本質とは？

よく見る典型的パーツを組み合わせる「デザインパターン」
ケントベックとカニンガムのデザインパターンのはじめの論文読んだ
おもしろい
今の「デザインパターン」と微妙に違う

XP
XPは理屈はわかるけど…責任の分解点が必要
XPは無理じゃないの感を持っていた

デザインパターンはXPにつながっている
パターンの2回目のトライがXP

XPの土台がwiki
wikiは土台であり、本質である

そしてアレグザンダー
はじめのころの主張
デザインするということ
YesかNoかで切り分けられるように分解すること

途中からの主張
自然都市と人工都市
利用者参加の建築

「無名の質」

形の科学
形を科学の対象にするのは難しい
科学の対象＝再現可能なもの、制御可能なもの

wiki
パターンをいかに適用するかを考えている
コミュニケーションの土台

●トークセッション
トークセッションはソフトウェア開発にテーマを絞る
＠以下、メモ少なくして聞き入ったので省略形

「サワダマンション」

クリーンコードの前書き　コプリン
パターン XP リーン

×2周目かおまえら
○正しい方向へのアプローチ

パターンて名前を捨ててアジャイルじゃね
＠テストじゃなくてBDDみたいなことだな

形がどうできるかの力
「インターネットが死ぬ日」

×つくろうとしてつくる
○できちゃった　内側から現れてきちゃった

デザインパターンは今まで見たことあるものに当てはめていくもの　という印象になってしまっている
小さい　すごく小さい

なんかいいかんじ　えもいわれぬよさ
それが無名の質

「Nature of Order」
living
いきいき

どうやるとパタンランゲージかけるのかについては触れられなかった

でもそれをやんなくちゃ

15の属性で考えよう

背後にある力は何なのか

部品があってガチャンコすれば出来るんじゃないぞ

江渡
C++だとイテレータがないので「イテレータはこうすれば実現できるのである」
それをrubyではあたかも所与のように使える
これこそ構造保存変換である

修復の話
全体を見よ

ハッカーが自然に身につけたやり方を
普通の人が集団でそれを出来るようにする　それがXP

generative
「wiki way」yomoyomo　絶版

＠なんだこのセッションは…無限に本が買いたくなる

江渡
「エクストリームプログラミング」は「気付けよ！」みたいなことがあって
「アートオブ　アジャイルデベロップメント」がXPの第3版であるって聞かされてなるほどってなった

アジャイルをはじめるには
角谷「あいさつして朝会やってふりかえりしろ」

おすすめの1冊
懸田「パターンランゲージによる住宅の建設」

●質疑応答
質問1
アレグザンダーの言ってることが変わったって言ってたけどアレグザンダーの考えが変わったの？

答え1
江渡
変わってない
周りの人の受け止め方が180度変わった

要求条件を満たす方法をずっと考えてた
実現する方法が違う

最初
中心となる設計者がいる　コンピュータが助けになる

最後
建築を設計するのは利用者である

質問2
サワダマンションのどこに無名の質があるのか
答え2
角谷
wikiばなで聞け！

懸田
ちょっとずつ作ってる
1期2期3期
一部屋出来たら貸してたｗ
ちょっとずつ作って、リリースして、お金を回収して、次のサイクルへ
アジャイルじゃんこれ

＝＝＝

トーク
Keep
　会場運営ありがとうございました
　あっちこっち話が飛んでるのにブレなかった
Problem
　3人が薦めてた本があとからだとわからなくなるものがある
Try
　「それ買う」ボタンが座席についてて、薦めてた本をその場で買えるようにすれば
　ジュンク堂がしやわせになれる(催眠商法みたいだがｗ)

じぶん
Keep
　江渡サイン本をget
　あがったテンションでそのまま本を読みきった
Problem
　受身なところ
Try
　今度は質問しよう