「小さく賭けろ！」を読んだ

Amazonのleanstartupセミナーに行ってきて、そこで売っていた「小さく賭けろ」についてのメモです。「リーン・スタートアップ」の出版記念的なところもあったと思うのですが、なぜかこちらが気になって買いました。

小さく賭けろ! 世界を変えた人と組織の成功の秘密

がっつり、各章の気になったところをローカルにメモったのですが、さすがに引用多すぎてヤバい感じがしたので、こちらのエントリーはさらっとしたメモにしておきます。

小さな賭けの原則

小さな賭けの原則として以下の6つが挙げられています。

• 実験する
• 遊ぶ
• 没頭する
• 明確化する
• 出直す
• 繰り返す

心構えをこうした考えへシフトしていくと、どのような変化が訪れるかということが中心です。

成長志向のマインドセット

固定的なマインドセットを持った人たちと、成長志向のマインドセットの違いは本書にも掲載されていた以下の図が分かりやすいです。

遊びの天才

ミハイ・チクセントミハイのフロー理論また出てきました。まさにフロー状態で読めました。そろそろ、フロー理論の本読みたいですね。

実際に人間と語り合うことや体験することの大事さ書いてあり、ちょうどいま自分が考えていることってたまたま手に取った本にも書いてあることが多く、本との出会いにも縁を感じます。

git道場#1参加した #gitdojo

はじめに

• 最後には師範代に認定
• git覚えたらプロジェクトを heroku.com へ deploy しよう

心: git総論、心構え

• @iwamatsu
• 岩松さん
• DebianのOS開発
• 師範
• 彼がmergeやrebaseができなかった。別れたい

gitは分散

• リモートリポジトリとローカルリポジトリ
• 主な作業はローカルリポジトリで行う
  • 必要なデータがローカルにあるので動作が速い
• プッシュしてはじめて、他のユーザーと履歴共有する。
• ローカルリポジトリはおれのもの。リモートリポジトリはみんなのもの

リモートリポジトリとローカルリポジトリ

• HEAD いまチェックアウトしているもの
• 作業中に誰かがコミットをプッシュしても、ローカルは認識できない
  • リモートの作業を反映するまではその辺は気にしないで良い

gitは頑健

• 乱暴に言うとスナップショットシステム
• SHA1ハッシュで管理されている。
  • コミット、ツリー構造、実際のファイルのどれかが変更されるとハッシュ値が更新される

gitは時間的な変遷を管理する

• コミットの前はどうなっていたのか
• 前の状態に戻すことが出来る
  • git reflog
  • 消したbranchとかも参照を消しているだけなので、戻すことが出来る
  • 90日まで
  • git gcするまで
  • git config --global gc.auto 0 でgcを無効にできる
• 常にコミットしておいた方がむしろ安心。

質問

• svnから移行するときの説得方法は？
  • コミット権限とりあげよう
• githubが重い
  • enterprise速いよ
• git gc実行こわい。どれくらいのサイズですればいいの。
  • 大きいのは仕方ないのでは
  • git objectを集めるのが趣味なので気にしない人もいる
  • 検索かけたときに遅くなったら、とか目安になるかも。

技:

• 小川さん
• @@conceal_rs
• jpmobileの人
• 師範

本日の課題

• 3〜5人のチームで
  • コミットメッセージちゃんとかく
  • git pull --rebaseを怖がらずにやる
  • git pull との違いを実感する

コミットメッセージをしっかり書く

• 当たり前のことだが、あまり実践されていない
• コミットメッセージのみを介して会話する
• 意思疎通が出来るレベルでメッセージを書くことが目的

git pull -rebaseを怖がらずに

• 今日はコンフリクトが起こりやすい題材となっている

git pull との違いを実感する

• mergeとrebaseの違いを実感する
• mergeだとコミット家系図が入り込んでしまうため、コミット間の相関関係が分かりづらい

題材

• Numbersファイルをチームで編集
• チーム間ではコミット内容に関する相談、会話をあまりしない
• pushのタイミングは告知しないでいいよ
• commitしてpushすることを5回ほど繰り返す

Numbersとは

• 1〜10の数値が書かれた10行のファイル
• 好きな数値の後ろに記号を追加/削除する
• コンフリクトしやすくしよう！
• コミットメッセージに、追加した記号や数値に関する情報を記載する
• コミット内容に関しては、このコミットメッセージでやりとりする
• コミット内容に関しては、相談・会話をしない！
• コミットメッセージは、コミットオブジェクトの要約であることを意識する
• 自分のコミットが連続しているのは敗北！
• git pushの声掛けはok

最後にやったことの確認

• githubのNetworkを確認
• git log --graph --pretty=oneline --decorate

repository

http://github.com/git-dojo/teamNN をcloneして始める

実技

Numbersを自由に更新

実技2

pull時に必ずrebaseでやる縛り

git commit -> git push | git pull --rebase 

git remote update -> git rebase origin/master 

テクニックの解説

• rebaseはコミットをかぶせる感じ
• mergeはコミットを統合する

git pushが失敗するのは？

• remoteに新しいコミットがあると失敗する

このときgit pull

• remoteにある、差分をmerge
• localのコミットをmerrge

git pull --rebase

• remoteの差分を先にrebase
• localのコミットをmergeする

git pull --reaseでconflict

• 無名branchがチェックアウトされた状態
• どうする

1. ファイル編集
2. git add Numbers
3. git rebase --continue

• つまりgit commitしないこと

git rebaseの利点

• 見やすい
• 誰がcommitしたか分かりやすい

git merge

• conflictしない
• 自分の元々の編集履歴が残るので、後になって調べやすい
• commitに問題があったかどうかなどの調査しやすい

merge か rebase か

• 状況次第であることを意識する
• 基本的にはrebaseしてからpushが良い
  • 他人がcommitしていることが意識出来る
• ブランチはmergeが良い

無名ブランチ

commitしないこと

• git rebase --continueで続ける
• git rebase --abort
• git rebase --skipでそのコミット捨てちゃう

今日覚えた事のメモ

git push するたたびにgithubのアカウントとpw聞かれるのはなぜ？

以下のように、.git/config内の記述がhttps〜になっていると聞かれる

 url = https://github.com/git-dojo/team10.git 

ので、このように変更する。

 url = git@github.com:git-dojo/team10.git 

githubのNetworkみたいなものをコマンドラインで見る

git log --graph --pretty=oneline --decorate 

git pullする際のお作法

--rebaseをデフォルトで付ける。

git config branch.master.rebase true 

diff

git diff --word-diff 

作業の流れ

1. いろいろ作業
2. git add
3. git commit
4. git pull --rebase
5. conflictを解決
6. git add
7. git rebase --continue

githubのNetworkの遷移

git pull --rebaseを知らない頃

git pull --rebaseを覚えた後

#kobitoapp と #qiita とblogの関係について考えた

ちょいと前に、kobitoのユーザーインタビューのオファーを頂き、中の人とお会いしました。ちょっとテンションがあがってしまい、しゃべりすぎてうるさかったのではという噂があります。

その後、kobitoとqiitaの関係について考えてみました。

kobitoとqiitaの関係

qiitaはエンジニアがローカルに貯めたメモを公開することで、世の中で同じことに困っているエンジニアの無駄な時間を省くためのサービス、だと思います。

kobitoは、qiitaに上げる前のメモを貯めるアプリと考えています、私は。

私がメモアプリに望むこと

となると、メモアプリに望むことを考えるわけですが、ざっとあげるとこんな感じかな。

• 軽い
• マークアップが使える
• すぐに何かに対して共有出来る

私がメモアプリに望まないこと

逆に考えると、こんな感じ。

• 余計な修飾機能
  • とあるアプリ、コピペで何、勝手にスタイル継承してんだよアホか(主観です)
• ライフハック感
• bookmark的な機能
• 画像クリップ機能

でkobitoはどうなの

私がメモアプリに望むことをすべて満たしているですね。こりゃ、もう使うしかないでしょ。もうちょっとここがこうだったらなー？と感じたら要望だすでしょう、そりゃ。という感じです。

ちなみに、kobitoに書いてある3つの特徴

• Markdownとリアルタイムプレビューで快適に入力
• シンタックスハイライトでコードをきれいに記録
• ボタンひとつで簡単に公開

何これピッタリ。ローカルにメモを書き溜めるkobito、書き溜めたメモを公開して共有するサービスであるqiita、この関係が絶妙ですね。

kobitoとblogの関係

kobitoとblogの関係を考えるときに、重要なのが、blogに上げる情報と、qiitaに上げる情報との違いなのです。そう考えると、必然的にkobitoとqiitaとblogの関係を考えることになります。

kobitoとqiitaとblogの関係

と、いいつつ、この点に関しては未だ答えが出ていないのですが、いまのところ以下の使い方を試して見ています。

qiitaとblogの使い分け

qiitaをエンジニアのメモ集、blogをイベントにひもづく時事ネタと考えると

• qiitaには技術的なメモを書く
• blogには勉強会などイベント系メモを書く

という感じかなと思っています。こう考えると、qiitaに書くネタは更新性があり、正確性が求められるので他人が更新出来る仕組みが欲しくなります。古くなった使えない情報は他のエンジニアを助けるどころか、逆に困らせる可能性がありますよね。

kobitoに書くもの

こちらは、すべてのメモやblogの下書きを書きます。基本的にはありとあらゆるテキストはここに集約したいという気持ちがあります。

• 技術的なメモ
• 勉強会などイベント系メモ
• blogの下書き

qiitaに書くもの

• kobitoにためたもののうち
  • 技術的なメモは
  • 勉強会などイベント系メモ

qiitaには直接書かないというポリシーを持ちたいと思っています。これは、qiitaに書いたものはすべてkobitoにあるという状態にしたいからです。同じくblogに書いたものはすべてkobitoにあるという状態にしたいです。

欲しい機能

qiita

• qiitaに下さい
  • blogの記事に対して、これはqiitaに投稿して欲しい！という記事を記事書いた人に知らせる何か
  • 更新性の高い記事はqiitaに集めたいという理由から
• wikipediaのように誰でも更新出来る機能
  • 更新性の高い情報は、古くなると逆に有害な情報になりうる
• レビュー機能
  • qiitaの記事のの信憑性をチェックしたい

kobito

• 一覧でのtagクリック時に、勝手に絞り込み検索
• レビューのON/OFF機能(と思ったら、左下にあった！)
  • インタビュー時にもあると言われた気がする
• みんな要望提出済みなDropbox連携
• blog投稿機能
  • octopressだったら一発で出来るpluginとか用意すれば出来そうかな
• iOS版
• あとは、随時 #kobitoapp 付きのツイートを投げます。

エンジニアを幸せにするサービスの素晴らしさ

Increments株式会社のmeta[name="description"](なぜ見つけた)にある

Incrementsは、「プログラマの誰もが楽しくプログラムを書いて、いろんなモノを生み出すことができる世界」を実現する会社です。

というのが素晴らしいなと思い、共感するわけです。

私は、世の中のシステムを作っているエンジニアやデザイナーなどクリエイター達がストレスなく幸せに伸び伸びと、素晴らしいものを生み出せる環境が広がることを望みます。

まずはクリエイターが幸せになってから、他の事したいですよ。まずはそれから。

合わせて読みたい

@fakestarbaby さんの Kobitoのユーザーインタビューに参加しました！もどうぞ。