MagitのRewritingがよく分からなかったので、色々触っていたらなんとなく理解したけどgit rebase -iとどこが違うんだろう？

ちなみに、M-x magit-statusを毎度叩くのも飽きたのでC-x gに割り当てました。

(global-set-key (kbd "C-x g") 'magit-status)

Rewritingの使い方

まずはl lでログリストを出して、修正の起点のコミットログでr b(begin)を押す。

すると、magit-statusでそれ以降のコミットログがpendingされたコミットになっているので、修正したい順番にAを押していく。きちんとコミットされるとpendingのステータスが*(未使用)から.(使用済み)に変わる。r .とかr *でも状態変更はできる。

これはgit rebase -iでコミットログの順番を変えるのとほとんど一緒だと思う。

まとめてコミットしたい場合はaをつかえばいいんだけど、コンフリクトしたりしてなんか挙動がいまいち掴みきれていない。

最初の方はなかなか思い通りにいかなくて最初からやり直したいことが多いが、そういう場合に破棄するのはr a(abort)でOK。

慣れるまではcloneしてテスト用のリポジトリで作業してみて、OKだったらもとのリポジトリで修正すんのがいいのかもしれない。

Reflogの使い方

l hでReflogが出るのでAを押すとコミットが取り込まれる。

実用Git
Jon Loeliger
オライリージャパン / 2940円 ( 2010-02-19 )

Git初心者が絶対に覚えておくべきコマンドをMagitでやるには。

git-commit --amend

通常コミットするときはステージに上った状態でcを押しコミットログのためのメッセージを編集した後C-c C-cします。

ここでC-c C-cではなくC-c C-aするとamandのための編集画面になります。

Amend: "yes"
-- End of Magit header --
second commit # コミットログメッセージ

あらためてC-c C-cすればamendされます。

git-reset

magit-statusしてステータス画面を出したあと、Headの行にカーソルをあわせてxを押す。

デフォルトは git reset HEAD^となります。

ログ画面でxを押すと対応するとこまでresetされます。

git-reflog

magitの場合、元サイトのようなミスは起こりにくいと思いますが。

magit-statusでr bを押すとrewriteがはじまるので、aとかAとか押したりして歴史の修正をしていく。

実際やってみたけど、ちょっとややこしいのでRewritingのセクションをきちんと読んだほうがいいのか。

あとでちゃんと理解しておこうっと。

GitとGitHubの入門的なハンズオンをやります。独りで一通り使えるようになることを目指す内容になっています。

Gitについて

• 基本コマンド(ハンズオン)
• タグ、ブランチについて
• タグ、ブランチ周りのコマンド(ハンズオン)
• 分散バージョン管理について
• リモート周りのコマンド

GitHubについて

• 同一ホスト内で clone, pushしてみる
• アカウント登録
• SSHの設定
• Git入門でつくったやつをpushしてみる
• GitHubでのforkとcloneの違いと使い分け
• GitHub pagesの説明
• issueとpull reqに関して（やらないかも）

既に枠は埋まっていますが、キャンセルがぼちぼち出ているので登録しておくといいかもしれません。懇親会のみの参加もおそらく可だと思います。

• 静岡Developers勉強会　GitHubハンズオン
• 静岡Developers勉強会　GitHubハンズオン懇親会

今回はweb系（デザイナー？）っぽい方々がちらほら参加されているのでちょっと楽しみですね。

入門Git
濱野 純(Junio C Hamano)
秀和システム / 2310円 ( 2009-09-19 )

色々はまったのでメモ。

Titanium StudioにXcodeが認識されない

• Xcode > Preferecens > DownloadsでiOSシミュレーターが入ってるか確認
• それでもpreferenceで設定されてなければxcode-selectを使う

参考

-Switch between Xcode 4.3 and other Xcode versions (Xcode 4.2 and lower)

~Library/MobileDevice/Provisioning Profilesにファイルがないっていうエラー

アプリを実機に転送する際にfile not found error。.mobileprovisionファイルを該当する名前でエラーの出たディレクトリにコピーすることで解決。これは何がおかしいのかよくわからん。

• Install error (traced to No such file or directory when trying to find the developer profile)

その他

プロビジョニングのとことかきちんと理解してなくて本のとおりになぞっただけなので、そのうちきちんと理解しないといけない。

実際に動かしてみた感じではjQuery Mobileよりもなめらかに動いて良い感じ。

Titanium Mobile iPhone/Androidアプリ開発入門―JavaScriptだけで作る
小澤 栄一
秀和システム / 2520円 ( 2012-02 )

ちょっと人情系入りすぎだけど、改善した後の短縮された時間をどう使うのかという認識が一致していないとうまくいかないというのは盲点だった。

改善するための前提

たとえば導入した結果、従来と同じ量の製品をつくるのに要する時間が、一時間短縮できたとする。この短縮した１時間をどう使うのか。そこをはっきりさせておかないと、時間を短縮した意味がなくなる。

自分の場合、効率的に仕事をして、余った時間は「より高度なことにチャレンジするか、早く帰って家で新規な技術を試すかっていうこと」に突っ込むの当たり前じゃんって思ってたので。

単に時間労働って考えている人にとっては時間ギリギリまで引き伸ばすのは当然の事なので違和感を感じるのかと気づいた。思い返せば確かにグダグダ言ってるな。

ホウレンソウとは

事実は起きた瞬間に事実ではなくなり、見たものの主観に左右されてしまうからである。主観で書かれたものは、もはや事実ではない。

プロジェクトの報告もプロジェクト側から語られるものはそういう性格を帯びる。そういうのを客観的に眺めたくて色々チャレンジしているところ。

僕もホウレンソウのうち報告と連絡は無駄だと思っている。あんなのはコンピューターが定期的にレポートを出して、相談に時間を費やすべきであろう。

ムダとはどこからみて

答えは、ひとつ。あくまでも「後工程」にとってムダかどうかである。

これはどうなんだろう。ちょっと悩んでいる。生産だとシーケンシャルだから、後工程ってのは直後の行程であることが多いだろう。多次元最適化とかやってる場合後工程ってのはデータが全部出揃ったとこのことなのだろうか？

「トヨタ流」現場の人づくり―トヨタ元生産調査部部長が明かす (B&Tブックス)
田中 正知
日刊工業新聞社 / 1680円 ( 2006-11 )

失敗を貴重な体験と考えよう！

最近Twitter Bootstrapばかりいじっているので、カスタマイズのやりかたが非常にきになって仕方がない。LESS覚えないといけないけど、それはあんまり問題じゃなくて、アップデートに柔軟に対応できるような構成にしておくのが重要だったりする。

できるだけカスタマイズ性をあげつつ、一方で更新に対応するため、bootstrap自身はできるだけ触らないようにするにはどうしたらいいか探してたら、sofに2つほどやり方載っていた

Twitter Bootstrap Customization Best Practices

add-on.lessをbootstrap.lessの途中に挟み込む方法

変数の設定とミックスインの設定をした後に独自の定義を施したlessを読み込んで上書きする。

// CSS Reset
@import "reset.less";

// Core variables and mixins
@import "variables.less"; // Modify this for custom colors, font-sizes, etc
@import "mixins.less";

// Custom Addons
@import "addon-file.less"; // <--- My custom LESS addon

// Grid system and page structure
@import "scaffolding.less";

...

bootstrap.lessに手を入れちゃうので、更新するたびにこの一行を書きなおす可能性があるかも。あんまり気にならないのかもしれないが。

bootstrapには触らない方法

bootstrapは適当なディレクトリ(この場合はbootstrap)においておいて、bootstrap.lessとvariables.lessをコピーしてくる。bootstrap.lessはtheme.lessに名前を変える。

/Website            
       theme.less
       variables.less
       /bootstrap

variables.lessは好き放題変更を加える。theme.lessの方は変更を加えたvaliables.lessをimportするようにして、残りはbootstrap/*.lessをimportするように修正を加える。

こうしておけば、bootstrap以下は常に安全に更新できる。

特にgit cloneしたtwitter-bootstrapの場合、git pullで安全に更新することができるのでこっちのほうがいいかもしれない。

今度つくるサイトはこの方法でやってみる。

実体験に基づかないで伝聞から結論を導くのはどうなのかな？と思いつつ読んだ。

美味しんぼのトマトのエピソードなんて、実際にトマト植えたことがあったらあれどうなのよ？って思うけど、メタなタイトルだから、そういう話の組み立て方で文章を構成したのかもしれない。

なので、章の最後にまとめが箇条書きされているページがあって、そこだけ読めばこの本を読んだと思っていいだろう。

「考え方」の考え方 すぐれた企画は30秒で伝わる
指南役
大和書房 / 1470円 ( 2008-10-23 )

すぐれた企画は模倣から生まれると思うので、模倣のためのストックをたくさんもつことの重要性は考えさせられた。

なぜメモをとらない若手社員が増えているのかというエントリを読んだ。ちなみに僕は、メモ魔なのに取ったメモを読み返さないで、同じ失敗を何度も繰り返す年上の部下に「お前のメモに「メモを読み返すこと」ってメモっとけ！」ってブチ切れた苦い思い出があるのでメモ魔は苦手だ。

リンク先にも書いてあるが、

メモをとる理由は、打ち合わせの内容・やるべきアクションを「忘れない」「確実に実行」のためです。よって仕事上で正確なメモをとるようにしないと意味がありません。

実際は、これプラス合意が必要だろう。打ち合わせのメモというのは議事録的な性格を帯びていることが多いし。

さて、そのようなものは指示を受けるほうが用意しないといけないだろうか？

否というのが僕の考えなので、最近は上司に仕事を振ることの多い僕が試している方法を2つほど紹介してみたい。

メモや議事録をWIKIでとる

会議の最後に5分ぐらいラップアップの時間を設けて、WIKIをスクリーンに表示しながら議事録をつくります。いつまでに誰が何をやるかを合意していきます。メモはあくまで主観的な情報の羅列だし、こういったものをもとにメールベースで議事録を作ろうとすると、行った言わないとか無駄なオーバーヘッドが発生するので、その場で合意するのがいいね。

これは外資系出身の元上司に教わって、試してみたら自分に合っていたのでそれ以来できるだけこのやり方をしている。

議事メモの作成は書記的な人を指名してお願いしてもいいけど、

3．本質を見極める習慣が身につく。 打ち合わせで話した内容で本当に重要なことは何か？を覚えておける範囲は限られる。だからこそ、重要なポイントを探る力が身につくようになる。

とかいう言い訳じみた事を言う人にラップアップやらせれば要点だけのスマートな議事録が出来て、自分たちも先方も喜ぶかもしれない。。

redmineを使ってその場でチケットを発行しておく

最近気に入っているのが、redmineを使ってタスクに落としてしまうことだ。これだとwikiで文章化する手間が減りますし、先にも出したメモの本来の目的である

メモをとる理由は、打ち合わせの内容・やるべきアクションを「忘れない」「確実に実行」のためです。よって仕事上で正確なメモをとるようにしないと意味がありません。

という5W1Hが簡潔な形で記述されます。

タイムラインで見たい場合にはガントチャートで表現できるし、誰にどのくらい仕事が振られているのか一目でわかるので調子がいい。

業務の引き継ぎとか新人研修みたいなのはWIKI

同じことを繰り返して教える場合はWIKIがいい。まずはWIKIのマニュアルを見てやってもらってわからないことがあれば質問してもらうという方式にする。わからないことは丁寧に教える代わりに、覚えたことをWIKIに足してもらうことで、マニュアルが洗練されるし、次に教わる人にとってもより分かりやすくなるので、みんなの利益になっていい。

まぁ、これはどこでもやっていることだと思うけど、一応載せてみた。

まとめ

メモをとらせるというのは、自分で仕事をコントロールしないで相手任せにしすぎな行為の気がする。結局、いつまでに何を取るかの合意を明確にしたいんだから、今だったら色々やりかたあるよねと思っている。

電車の関係で、ちょっと早く着いたので三島駅から二日町まで歩いた。途中に妙にレトロな建物があった。三島は突然レトロな建物が現れることが多い。

まずはビール。というか最初から最後までビール。タレは甘口、中辛、辛口が選べるが、辛口しか頼んだことない。

カルビだったかな。厚みもあって旨いです。マジウママスト。

こっちは肉盛り合わせ。自分で選ばずに盛り合わせを頼んで、肉との巡り合わせの妙を楽しむのが大人スタイルですな。とか言いながら、育ち盛りのようにガツガツたべる。

肉焼いてます。

ホルモンも焼いてます。

今回も焼きまくった。そして、服には焼肉臭が染み付いたので選択に回したのであった。

近いうちにまた行きたい。

三島は京都みたいに歩いて楽しい街なので僕は好きですね。

@motimuneとコミュニティfで会う用があったので、ついでに黙々とHakyllでサイトをつくってみた。

• Shizudevつくる会

Hakyllは面白いがデプロイがめんどくさかったので、HakyllでGitHubのProject PagesのHTMLを作るみたいにデプロイ用の設定をしないといけないなぁと思った。

あとHakyllで黙々したい（よね？）