gitの別リポジトリを合流させる

git

TLでtyru さんの 全く履歴が被らない (別リポジトリとかの) ブランチ同士を無理矢理マージ - Humanity を見て、gitなら履歴を残してマージ出来るのでは?と思ったのでメモ

やること

全く別々のリポジトリAとBの、それぞれhogeブランチとfooブランチをマージする

# リポジトリAをブランチを指定してclone
$ git clone -b hoge (リポジトリA)

# リモートブランチとしてBを追加
$ git remote add repoB (リポジトリB)

# Bの内容を取得
$ git fetch repoB

# 現在のブランチ(Aのhoge)にBのfooをマージ
$ git merge repoB/foo

HerokuのReviewAppsを使うときの小ネタ(HEROKU_APP_NAME,MySQL)

アプリ毎の名前やホスト名を設定したい

ReviewAppsがPR1つずつにアプリ名を環境変数で渡してくれる仕組みがあるのでそれを使うとよい

Review Apps | Heroku Dev Center

app.jsonに以下のような設定を追記すればOK

{
  "env":{
    "HEROKU_APP_NAME": {
      "required": true
    }
  }
}

HEROKU_APP_NAMEは (appname)-pr-(pull request No.) といったフォーマットが渡される。
自分のプロジェクトではこれを使って、S3へアップロードする処理でPR毎に出力ディレクトリを変更するようにしている

mysql2.gemを使いたい

プロジェクトのDBはMySQLなのでReviewAppsでもMySQL(ClearDB MySQL)を使った。
この時、DBへの接続URLは環境変数CLEARDB_DATABASE_URLに入ってくるのだが、URLmysql2:// ではなく mysql://から始まるためこのままだとmysql2.gemが使えない。

単体のアプリなら CLEARDB_DATABASE_URL を置き換えればいいのだが、ReviewAppsだとPR1つ1つに対して置き換えを行う必要が出てくるので現実的ではない。

結局以下のように強引に置き換えることにした

development:
  <<: *default
  url: <%= (ENV['CLEARDB_DATABASE_URL'] || ENV['DATABASE_URL'] || 'mysql2://localhost').gsub(/^mysql:/, 'mysql2:') %>

翔泳社セールで買った

性懲りもなく積読を増やした。
あ、これ買おうって思ったのがすでに購入済となってたのでそっちも早く読まないと…

ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)

ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)

エンジニアのための図解思考 再入門講座 情報の“本質

エンジニアのための図解思考 再入門講座 情報の“本質"を理解するための実践テクニック

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

おうちで学べるセキュリティのきほん

おうちで学べるセキュリティのきほん

クイズで学ぶデザイン・レイアウトの基本

クイズで学ぶデザイン・レイアウトの基本

レガシーコード改善ガイド

レガシーコード改善ガイド

あと波よ聞いてくれの2巻が出てたので合わせて買った

波よ聞いてくれ（２） (アフタヌーンコミックス)

波よ聞いてくれ（２） (アフタヌーンコミックス)

Cookpad TechConf 2016に行ってきた その1

幸運にもCookpad TechConf 2016 に参加できた

ユーザーのために、技術をどう活かすか

CTOの舘野さんのお話。

クックパッドがユーザファーストな企業であるために技術に関して、組織作りに関してどう取り組んでいるかの話。 後で振り返ってってみると、この後に続いたどの話でユーザーを第一に考えていて、クックパッドはほんとにユーザーを大事に考えて取り組んでいるんだなという印象を強く受けた。

舘野さんの話で印象に残ったのは組織作りの中で話されていた情報共有の取り組みについて。 情報共有に関してはのところ、自分もどうやったらうまくいくのかなと思っている部分なので興味があった。

社内の情報共有ツールのGroupad(Blog+WIkiみたいなの)には技術情報だけじゃなくて、料理のレシピやスーパーマーケットでの(たぶん携帯の)電波の入りが悪さについての話などもあるらしく、情報の量が多くなって逆に伝わらないということはないのかな？という疑問を抱いた。 懇親会でお話する機会があったのでそこらへんを聞いたところ、以前はフラットに情報が流していたが、組織が大きくなってから部署などグループ内で共有するようにして、その中でいいねなどしてきたのが全体に流れてくるようにしてるとのこと。

おでかけスポット検索のむずかしさ - Holiday を支える検索技術

内藤さんのおでかけスポットを検索の検索のお話。

「中目黒 デート」というキーワードで単純に検索すると住所の中目黒にヒットしてしまい、ユーザーが期待しているカフェとか雑貨とかオシャレなイメージと乖離してしまう。 これを位置情報の検索を工夫して解決している話だった。

「中目黒 => オシャレなイメージはどうやって推測するのか? 他の場所でもできるのか?(推測する仕組みはあるのか?)」みたいな質問をしたかったんだけど、要領を掴んでない質問になってしまって残念だった…

Railsアプリ開発環境の高速化

k0kubunくんさんの高速化話。速い。

asset:precompileに23分かかっていたものが最終的に1分(キャッシュありの場合)まで縮めたとのこと。 23分という時点でも驚きなのにここまで速くできるのはすごい。

何故高速化するのか?という文脈でも(ユーザーに)価値を届けるという話が出てた。 クックパッドは価値を届けすぎではないだろうか。

R&D at Foodtech company

chezouさんのR&Dの話。いい声。

食文化研究の文化や食べみるの話。 クックパッドがNII(国立情報学研究所)にパブリックデータを提供してるのは初めて知ったかも。

最後のほうに出てくる、非専門家でもレシピを機会学習を使って自動分類などができる仕組みについて。 ちょっと前に自分のまわりで自動で分類などをできる仕組みが欲しいみたな話があったので懇親会でいろいろ聞いてみた。 …のを書こうと思ったけどchezouさんが自身のブログでそこらへんをすでに書かれていたのでぜひ読んでみて欲しい。

chezou.hatenablog.com

技術力を事業の強みするために必要なこと

大野さんのお話。 正直、難しい感じだったので改めて発表を見て頭を整理したい(動画待ってます!) "技術は議論や調整に弱い、決定とテストを行う" とか "定義」があることで「評価」が簡単になる" の言葉が印象的だった。

開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法

五十嵐さんのお話。 ディレクターだけどコードも書いてるらしい。

中の人からはこんな話も。

やばい。

技術先行だったりで思いついた機能で失敗した話と今はどう取り組んでいるかと話でした。

この日どの発表もすばらしかったんだけど、個人的に一番好きな内容でした。 特にこのページ。

機能の前の価値探しの話なんですが、まずベースに企業理念の反対な状態「料理が楽しくない」ってところから考えるところがおもしろいなぁと。 あとは欲求もあったら嬉しいみたいなポジティブなものではなくネガティブなものにフォーカスして、あっても使わない機能が入ったりしないようにしてるみたい。

よくやっちゃいそうな 技術→製品→価値 ではなく、価値→製品→技術 という流れで考えていくのはなんとなく↓のゴールデンサークルぽい考えですね。 自分もぜひ取り入れたいと思います。

サイモン シネック: 優れたリーダーはどうやって行動を促すか | TED Talk | TED.com

(その2 に 多分続く)

age++

一応誕生日Advent Calendar 2015用のエントリです

本日で35歳、ついにプログラマの定年を迎えました。
といっても別に何も変わりなく今日も明日もコードを書きます。

今年を振り返ってみると、プログラマーとしてはあんまり新しいことにチャレンジできなかったという反省があります。当初はGoやるぞ！とか意気込んでいたんですが結局尻すぼみになってしまいました。
来年はもうちょっと通勤時間や帰宅してからの時間などを上手く使って勉強する時間を取れるようにしないといけないなと思ってます。

また今年は例年以上にいろいろな人と知り合えた年になった感じがあります。
一緒に食事をすると仲良くなれるものですね。 ブローカーとかいう妙な呼称もいただいたので来年もこの力を活かしていこうと思います。

余談ですが例の店には15回行ってたみたいです。
(年内にもう1回行く)

さて来年2016年ですが、今のところ以下のようなことを頑張ろうかなと思ってます

  • 来年こそGo
    • ちょうど作りたいものが1つあるので1、2月中にはそれを完成させたい
  • 英語
    • 秋のKaigiまでにもうちょっとリスニングの能力上げる
  • Rubyへの貢献
    • Kaigiでモチベーション上がってるので早めに何かしたい

ということで、とりあえず来年もみなさまよろしくお願いいたします。

あ、例のやつ置いておきますね

Itamae meetup ＃1 でvagrant-itamaeのLTしてきた

(最後の追記も見てね)

 

資料はこちら

プレゼンアプリが固まって慌ててPDF出力したりして発表してた
 

Itamaeと自分

実はまだItamaeをちゃんとプロダクションで使ったことがない。
 
最初にItamaeを知ったのは、Chefに疲れた/合わなかった勢がAnsibleに流れてた時期だった気がする。どうもAnsibleが手に合わなかった(YAMLで書きたくなかった)ので、Itamaeのシンプル&プログラマブルなとこに魅力を感じた。
 
ガリガリ使ってウチらでItamaeを盛り上げてこっ！ってことをやりたかったんだけど、当時は転職直後でインフラを使う機会が無かった。そこでItamaeの利用を促せるツールを作ることを考えた結果が vagrant-itamae だった気がする。
 

次にやりたいこと

まだ Itamae は packer で使えなくてこれをなんとかしたいなと思ってる。
冬休みにGoの勉強も兼ねて書けたらいいなぁ。
 
(2015/12/10 11:20 追記)
 

資料の中の「vagrantが無くなる」「itamaeの--sshが無くなる」とか書いてる件について

 「itamae --ssh」は @ryot_a_raiさんのkeynoteで「--ssh 無くしたいな〜」という発言を受けたものではあるんですが、他の方の発表で使ってるって声がいっぱいあったので無くなることはないかなと思います。
 
Vagrantについては後継とされるOttoというのがあって、今は内部でVagrantを使っているけどそこが(多分Goで書かれた)何かに切り替わっていくものと思ってます。
ただこれも確定している話ではないと思います。

Gitでしていた勘違い

Git Advent Calendar 2015 6日目のエントリーです。 昨日は oh-sky さんの aliasにできないならsub-commandにすれば良い でした

みなさんはgitで操作をした後、内部のグラフがどうなっているかを意識していますか? 自分はGitの中身を勉強するまでは漠然としたイメージしかもっておらず、なんとなく操作して失敗するたびに泣きたい気持ちになっていました

このエントリでは簡単な例を上げて以前自分が勘違いしていたことと間違いに気付いてからの話をしたいと思います

さて問題です

      E - F(topic)
     /
A - B - C - D(master)

(A〜FはSHA-1のハッシュ値、カッコで囲まれているのはブランチ名ということにしてください)

たとえば上のようなグラフがあったとき以下のコマンドを実行したらどうなるでしょうか

  • git rebase master topic
  • git branch -D topic

git rebase master topic

自分が思っていたのは以下のようなグラフでした (man git-rebaseをしてもこういう例になってる)

              E' - F'(topic)
             /
A - B - C - D(master)

しかし正確には以下のようなグラフになります

      E - F
     /
A - B - C - D(master)
             \
              E' - F'(topic)

topicブランチは移動しているものの元のE - Fのコミットは消えずに残っています もちろん、git checkout topicとしてもFは参照できませんが、SHA-1がわかれば rebase 前のコミットを参照できます

git branch -D topic

deleteだから当然以下のようにbranchにあるコミット全てが消えると思っていました

A - B - C - D(master)

正確にはこうなります

      E - F
     /
A - B - C - D(master)

こちらでもFはSHA-1さえわかれば参照することが可能です

自分は何を勘違いしていたのか

この例に限らず Gitにはコミットを消してしまうようなコマンドがない ということです (消せるのはbranchのみ)

これに気付いたときは結構な衝撃をうけました
削除することができないということは、何かを失敗しても 必ず元に戻すことが可能 ということだからです
それからは何をするにもビクビクしながらgitを使うようなことはなくなりました

自分がこのようなことに気付いたのはGitの中身を勉強しようと 実践 Git - 低レベルに知る Git を見て、その後 入門Git を読み直してからです
ぜひみなさんもGitの中身を見て今まで誤解していたことや、ぼんやりとしたイメージしか持てなかったことを改めてはいかがでしょうか