■
東京にきている
21日までいる。忘備録も兼ねて何をしたかメモをとっておくことにしたい
ギークハウス元住吉さんにお世話になっている。
2014/03/04は、渋谷駅徒歩30秒のワーキングスペース - Lightningspotというところに遊びにいったりした。
東京は寒いけど、思ったほどではないなぁという印象。
うまれてはじめてSuicaというものを使った。気づかないうちに残高不足になりそうなんだけど、どうやってみんなチェックしてるんだろう。
もっとvim力をあげたい
と思って、なるべくvimを触っていこうと思った。 今はこれのテストを兼ねて書いている。
Vim - 依存ツールなしにMarkdownプレビューできるprevimプラグインを作った - ぼっち勉強会
previm単体だと open -a firefoxがcommand not foundになったので、open-browser.vimを入れてみるとうごいた。markdownのプレビューも確認できるのはとても良い。
設定は.vimrcに
let g:netrw_nogx = 1 " disable netrw's gx mapping. nmap gx <Plug>(openbrowser-smart-search) vmap gx <Plug>(openbrowser-smart-search)
って書くだけ。これでファイル形式がMarkdwonのファイルをvimで開いて、:PrevimOpenを押せばブラウザ越しでプレビューを確認できる。保存する度に反映されるからいい。
早く作業しようと思った…
Tumblr, GFMで書けないのか…残念...。
tiqavを高速に利用するChrome Extension、tiqav-quickを改良しました。
今日から idobata をギークハウス沖縄のチャットとして使っています。Githubとの連携とかできたり、エクステンションで通知が見れたりしてとても便利です。
特に画像展開が楽しくて、tiqavから取ってきて、ペタペタ貼ってます。
ただいちいちtiqavから検索して、コピーして、idobataに移動して貼り付けるのがとてもめんどくさかったので、いいのないかなと思ったら、こんなのを見つけました。
tiqavを高速に利用するためのChrome拡張"tiqav-quick"を公開しました
いいなぁと思って入れてみたんですが、
Markdown形式じゃなくてURLでいい。
検索した後に画像を選びたい。
っていう欲求があったので、forkしてきて自分の好きな感じに改良しました。
こんな風に動きます。
Chrome ウェブストア にはアップロードしていないので、下記のページからcloneしてきて デベロッパーモードを有効にしてから追加してください。
https://github.com/kimihito/tiqav-quick
実装もウンコだと思うのでもっと改良して欲しいです。
実装でハマったとことか
$.getJSONとかでいけるだろうとか思ってたけど、いけなくてここが一番ハマりました。
chrome extension external ajax call by jquery not working - Stack Overflow
@hanachin_ さんにスゴいって言われたのが嬉しかったです。
アジャイルサムライのメモ。
ch6.ユーザーストーリーを集める
よくかけているユーザーストーリー
顧客にとって 何かしらの価値が書かれていること。
お客さんが対価を払ってもいいと思うもの
ビジネスの観点から評価できるもの
エンドツーエンドである
- すべてのアーキテクチャを貫いていること。
独立している
交渉の余地がある。
テストできる
ここは自分の考え方になかった部分だ…
完了の基準が明確になっている。
小さい、見積もれる
- ストーリーを１〜５日で完了できるサイズに
デイブの話
- さくさくとかかっこよくとかでもいいんだ。「制約」。
ユーザーストーリーのテンプレート
<ユーザの種類> として <達成したいゴール>をしたい なぜなら<理由>だから
- ユーザーストーリーのワークショップ
- 実践してみたいなぁ。
ch7. 見積もり：当てずっぽうの奥義
概算見積もりなんて当てずっぽう。
ほしいのはこのプロジェクトを与えられた期間とリソースでやり遂げられるのか。
今後の計画を立てられる
見積りは当てずっぽうである前提を持ってる。
ソフトウェアの複雑さを認めている。
相対サイズで見る。
どうやって相対化するんだろう。
お互いがお互いに対してどれくらいの大きさなのかを相対的に見積もる。
自分たちの開発チームがどれくらいの速度で仕事を進められるかを計測する。
個人で言うと、ポモドーロの実施してチェック入れていって１日で振り返りするみたいな感じかな。
でも一番最初って自分の感覚なんてつかめないよなぁ…。
あ、最初っから完璧にしようとしてはいけないのか。
相対見積もりは１営業日ではない
ポイント。
- 1pt : 楽勝。 3pt : やれないことはない。 5pt : ちょっと大変
見積もりの技法
三角測量。基準になるストーリーとの相対サイズを見極める。
基準になるストーリーの選び方。
論理的なグループ分けができそうなものはなにか
エンドツーエンドになっているストーリーはあるか
プロジェクトを象徴するような代表的なストーリーはどれか。
見積もりの再定義は起こりえる。
プランニングポーカー
- 見積もりゲーム
ch8 アジャイルな計画づくり：現実と向き合う
慣れてもらうしかない。
計画の立て方の４つの基準
顧客にとって価値ある聖歌を届けられる計画
わかりやすくありのままを伝える、誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画
- 見た感じ、最後の２つとか両立するんだろうかと思う。
アジャイルな計画づくりとは
- チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすること。
マスターストーリーリスト
- 顧客がソフトウェアで実現したいと思っているありとあらゆるフィーチャが並んでいるリスト
ベロシティ
- ユーザーストーリーを動くソフトウェアに変換する速度のこと。
-
- １~ 2 week
最初から厳格なコミットメントとして扱うと、プロジェクトは始まる前から死ぬ。
やるべきことが多すぎる場合はやることを減らす。
- 何を基準にやめていくかを考えるんだろう。
やってほしいストーリーを追加するときは、既存のストーリーを削ること。
マスターストーリーの長さを一定にする。
個人で言えば、ToDoリスト（ポモドーロでいうところの在庫アクティビティ）を一定にするってことか
僕自身、どうしてもやることを増やしてしまいがちになるからなぁ。もっと、やらないことに対して厳しくいくべきだと思うわ…。
初回の計画づくり
ステップ１：マスターストーリーリストを作る
ステップ２：プロジェクトの規模を見極める。
- 三角測量・プランニングポーカー
ステップ３：優先順位をつける
ステップ４：チームのベロシティを見積もる
チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーション数
フィーチャを届ける ⇛ コーディング＋分析＋テスト＋設計
積極日間な見積りにしすぎないこと。
- うわーこれやってるわぁ…orz
ステップ５：期日を仮決めする。
期日の固定 = 「プロダクトはこの日が来たら何がなんでもリリースする」と宣言するのと同義。
フィーチャセット固定。中核をなすフィーチャのまとまりをすべて完成させるまでは作業を続ける。
バーンダウンチャート
- Pivotal Trackerでも表示されてたやつだ。
実践したくなってきた。Pivotal Trackerでやってみよ。この章を読んだ後に…。
プロジェクトを途中からアジャイルにしていく
イテレーションの運営
1 week ~ 2 week
ステップ１：分析と設計
1ページぐらいにまとめる。
説明
タスク
テスト条件
必要な分だけ、必要なときに掘り下げて分析する
フローチャートを書いてみる。
ペルソナ
ソフトウェアのユーザを役割ごとに簡単に説明したり、典型的な姿として書いたもの
どこまで掘り下げておくべきなんだろう。
例を見た感じだと
役割名
役割の説明
役割がどんな機能をもっているのかを作るソフトウェアの目線で書く。
ペーパープロトタイピング
受け入れテスト
このストーリーが完成したことを確認できそうなことを３つ書く。
好きなだけ詳細に踏み込んでもいい。
しっかりと把握できるまでどんどん質問していく。
ステップ２：開発：作業する。
ステップ３：テスト：作業の結果を確認する
受け入れテスト：”受け入れテストはシステムが正しく作られているかではなく、業務に使えるかの確認が中心" http://www.itmedia.co.jp/im/articles/1111/07/news124.html
カンバン
仕事の流れをスムーズにする。
ストーリーボードとの違い
WIP：チームが同時に着手する作業数はこの制限を超えてはいけない。
- どうやって決めるんかな？勝手に自分で？
運用とかだったらカンパンがいいかもねーだって。
実際のアジャイルの事例とかみておきたいなー。
アジャイルな意思疎通の作戦
イテレーションでやるべき４つのこと
ストーリー計画ミーティング
ストーリーの準備が整っているかを確認する。
受け入れ条件テストのレビュー
見積の数値を確認
調査に漏れがないか
ストーリーが大きい場合は１回のイテレーションに収まるように分割して計画を更新する。
ショーケース
- 成し遂げた成果を広めて、クライアントからフィードバックを得る
イテレーション計画ミーティング
プロジェクトの健康状態を確認するタイミング
バーンダウンチャートでプロジェクトの完了の見通しをする。
悪いニュースは早めに
「だけど」を避ける
ミニ振り返り
10分〜15分
うまくいったこと・もっとうまくやること
振り返りの方法教えて欲しいんだよなぁー。
デイリースタンドアップ
10分以内で自分のやることをまとめる。
これは個人だと、今日のTODOとしてreviewに書き出す感じにしてもいいかな。
やったこと・今日やること・開発を妨げそうなこと
毎日コミットメントをすること。
- ここなんか、週の最初は頑張るんだけど、後半から息切れしちゃうんだよなぁ…
大事なのは勝ちにつながる習慣かどうか。
イテレーションで成果がでなくても、その価値が出なかったことを伝えること
- ここは心が痛い…orz
プロジェクトの状況が芳しくないからといって、そこから目をそむけてはならない。その失敗を受け入れ、改善に取り組むこと。
ch11 現場の状況を見えるようにする。
インセプションデッキを見える位置にある。
リリースボード
チームがどこまで完了しているのかがひと目で分かる
イテレーションごとに分けられた完了したストーリー
残っているストーリー
ストーリーボード
- 現在のイテレーションで取り組んでいるフィーチャの状態
チームの約束
- 現在のチームメンバーにとってはどんなチームなのかを言葉で表す
チームが大事にすること。
- チームの約束よりももっと感覚的なもの。
DDD本は必読だって。
イテレーションの10％はバグを潰すことにあてて、技術負債を返済するのもいいだろう
ch12 ユニットテスト：動くことがわかる, ch13 リファクタリング, ch14 テスト駆動開発,
ユニットテスト：ビルドしたコードがちゃんと動くか
- メソッドレベルの粒度で書く。
リファクタリング：コードをシンプル＆クリーンで読みやすくする
TDD：複雑さに立ち向かうための設計手法
継続的インテグレーション：決まった感覚で統合し、プロダクトをリリース可能を保つ仕組み。
アジャイルの道
毎週、価値ある成果を提供しているか。
たゆまぬ改善の努力をしているか。
これから。
インセプションデッキの作成
ユーザーストーリーを作成。
やめどきがわからない。
これはポエムです。恥ずかしいけども書く。
みどころ.com ( http://www.medokoro.com/ ) が全然ダメ。 人も集まらないし、なんというかこのアプローチがダメなんだろうなと思う。
そんな中で感じてるのが、Webサービス（に限らずだけども）のやめどきがわからない、ということ。
多分、使ってくれない理由はたくさんあって、たぶんデザインがダサいとか、機能が分からないとかそういうものだってのもあるんだけど、もっと深い問題として「問題だと思ってた部分が皆はそうでもない」ってのがある気がする。
たくさんの人の話を聞く機会がある中で、強く思い始めてるのは「○○作りました！」ってのに対してある程度リアクションがないのは続けるもんじゃないなぁと。
僕の尊敬する人に「問題さえ捉えることができれば、解決方法はいくらでもある」って言葉があって（そこには緊急度とかいう物差しもあるんですけど）、どんなにデザインが汚くても、機能が貧弱でも、そのサービスが「××という問題を解決したいと思っている」という部分に刺さっていれば、使ってくれる人は増えるんじゃないのかなと思ってる。
でも結構、それって「いいもの作れば人は集まってくるよ」神話と似てる部分もあるんじゃないのかなとかも思ってた。「そうは言っても改善さえ続けていけば、いつかきっと…」とかおもってた。
でもそうでもなかったように思える。リーン開発とかいうけど、そもそもアクティブユーザが1人しかいないところにそういうの当てはめても意味がない気がしてきてる。割とそういうのって、結構サクっと切り替えできるもんなのかな。
なんかここまで書いてきて、結局相手がいて、そこに対して自分が作ったものがちゃんと価値として届き切れたかっていうフィードバックがない限り、作ってる側はこんな感じで、どんどん心が腐っていくんだろうなと思う。
書いてく中で、また思い出してきたんだけど、MOVIDA SCHOOL1で以前 Zaimの id:ramyana さんこと、@kansai_takako さんの話2を聞いて、「もっと自分が食べたいドッグフードにしなきゃなぁ」ってのを思ったことを思い出した。
サービスに対して、自分がいなくなると、そこに対しての熱量みたいなものはなくなっていくわけで、そうなってるのが今の自分の現状かなと思う。
ユーザを増やす施策なんてものは、そもそも一番最初の状態で増えたことがない限り、はやるべきじゃないんかなぁと思った。
僕にはチームがいないので、誰かが教えてくれると嬉しいな、と思う。
息切れしてきたので、いったんおわり。後で追記する。
1. MOVIDA SCHOOL in 沖縄っていうのがあって、火曜日の17:00からリアルタイムで参加することができるイベントが毎週あります。
Railsのparamsに関するメモ。
外のアプリケーションからRailsのアプリケーションに対して、net/httpを使ってPOSTを叩いても、Rails側の処理で TypeError (no implicit conversion of Symbol into Integer) が出ていたときに解決したときのメモ。
な、何を言っているかと思うが…(ry
ここのurls内の配列がStringで認識されていたので聞いてみた。
JSON.parseを行う位置が間違っていた。
data.to_jsonしてしまっていて、肝心の取り出したい中身の方をjsonにしていなかった。
dataの中の方がStringになっていたのが問題。 JSON形式で渡したい部分のデータを.to_jsonしてから送る。
受け取り側（今回だとRailsのコントローラ側)では、JSON.parseしてからデータを処理する。
もっとラクに送りたい。
受け取り側でJSON.parseしなくてもいいように、送る時点でjson形式であることを知らせてPOSTするメソッドを作成した
@tompngさんに感謝。
Topothesiaというところに来ています。
トポセシアというコワーキングスペースっぽいところに来ています。
FBページ : https://www.facebook.com/Topothesia2013/
前行った時は、なぜか開店30分たっても開かなかったので諦めた場所。
ここは何
https://www.facebook.com/Topothesia2013/info より。
どんな場所
※写真はFacebookページとかそこを見てもらえればいいかと思います。
営業時間は11:00 - 25:00 まで。25:00までやってるとこは沖縄では珍しい。
手作り感たっぷりの空間で座席数はざっと20〜30ぐらい。
どちらかというと、コワーキング「カフェ」なので、カフェ感が強い。
3時間以上滞在するんだったら800円。出るときに自身の滞在時間を伝え、支払いを行うらしい。
ドリンクバーがついていて、カラオケとかファミレスにありそうなやつ。ホットもある。
初回はカードを作成するために200円取られる。そのときに自分の名前とか所属とかの記入を求められる。
再入場は不可。
パーティーとかそういうのは開ける感じだけど、勉強会的なイベントを開くのは難しい。
大学生が来る場所って感じかなー。
スタッフも大学生っぽい。
場を作るって難しい。 - 焼肉リア充に書いたみたいに、ハコがあるだけじゃなくて、そこに居着いてくれるヒトが多くなってくれるといいなぁと思う。
大学の隣で、大学生をターゲットにしてるっぽいけど、大学だと研究室とか学生だとタダ同然で使える場所があるからそこと別の差を作れるといいかなぁ。
とても手作り感あって、とてもいい場所だと思います。スタッフさんの対応も素晴らしいなぁと感じました。
