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)
- 作者: ルーク・ホフマン,岡澤裕二,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2015/10/02
- メディア: 大型本
- この商品を含むブログ (4件) を見る
エンジニアのための図解思考 再入門講座 情報の“本質"を理解するための実践テクニック
- 作者: 開米瑞浩
- 出版社/メーカー: 翔泳社
- 発売日: 2010/10/15
- メディア: 単行本(ソフトカバー)
- 購入: 5人 クリック: 22回
- この商品を含むブログ (9件) を見る
エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)
- 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
- 出版社/メーカー: 翔泳社
- 発売日: 2005/04/21
- メディア: 大型本
- 購入: 10人 クリック: 635回
- この商品を含むブログ (142件) を見る
- 作者: 増井敏克
- 出版社/メーカー: 翔泳社
- 発売日: 2015/07/03
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- 作者: ヤマダジュンヤ,ハラヒロシ,田中クミコ,ハヤシアキコ
- 出版社/メーカー: 翔泳社
- 発売日: 2013/10/18
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: マイケル・C・フェザーズ
- 出版社/メーカー: 翔泳社
- 発売日: 2016/01/15
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
あと波よ聞いてくれの2巻が出てたので合わせて買った
- 作者: 沙村広明
- 出版社/メーカー: 講談社
- 発売日: 2016/02/23
- メディア: Kindle版
- この商品を含むブログを見る
Cookpad TechConf 2016に行ってきた その1
幸運にもCookpad TechConf 2016 に参加できた
ユーザーのために、技術をどう活かすか
CTOの舘野さんのお話。
クックパッドがユーザファーストな企業であるために技術に関して、組織作りに関してどう取り組んでいるかの話。 後で振り返ってってみると、この後に続いたどの話でユーザーを第一に考えていて、クックパッドはほんとにユーザーを大事に考えて取り組んでいるんだなという印象を強く受けた。
舘野さんの話で印象に残ったのは組織作りの中で話されていた情報共有の取り組みについて。 情報共有に関してはのところ、自分もどうやったらうまくいくのかなと思っている部分なので興味があった。
社内の情報共有ツールのGroupad(Blog+WIkiみたいなの)には技術情報だけじゃなくて、料理のレシピやスーパーマーケットでの(たぶん携帯の)電波の入りが悪さについての話などもあるらしく、情報の量が多くなって逆に伝わらないということはないのかな?という疑問を抱いた。 懇親会でお話する機会があったのでそこらへんを聞いたところ、以前はフラットに情報が流していたが、組織が大きくなってから部署などグループ内で共有するようにして、その中でいいねなどしてきたのが全体に流れてくるようにしてるとのこと。
おでかけスポット検索のむずかしさ - Holiday を支える検索技術
内藤さんのおでかけスポットを検索の検索のお話。
ユーザーの入力するキーワードには、バックグランドを含む「中目黒のおしゃれなイメージ(住所の中目黒にそこまでこだわっていない)」「駅を含むなら駅近いところ」 #CookpadTechConf
— cなんとかe (@chiastolite) 2016, 1月 23
検索って「入力キーワードを使って結果をどう探すか?」って考えがちだけど、「ユーザーがどういうものをイメージしてそのキーワードを入力したのか?」ってのを考えるのは重要だなぁ… #CookpadTechConf
— cなんとかe (@chiastolite) 2016, 1月 23
「中目黒 デート」というキーワードで単純に検索すると住所の中目黒にヒットしてしまい、ユーザーが期待しているカフェとか雑貨とかオシャレなイメージと乖離してしまう。 これを位置情報の検索を工夫して解決している話だった。
「中目黒 => オシャレなイメージはどうやって推測するのか? 他の場所でもできるのか?(推測する仕組みはあるのか?)」みたいな質問をしたかったんだけど、要領を掴んでない質問になってしまって残念だった…
Railsアプリ開発環境の高速化
k0kubunくんさんの高速化話。速い。
asset:precompileに23分かかっていたものが最終的に1分(キャッシュありの場合)まで縮めたとのこと。 23分という時点でも驚きなのにここまで速くできるのはすごい。
何故高速化するのか?という文脈でも(ユーザーに)価値を届けるという話が出てた。 クックパッドは価値を届けすぎではないだろうか。
R&D at Foodtech company
chezouさんのR&Dの話。いい声。
食文化研究の文化や食べみるの話。 クックパッドがNII(国立情報学研究所)にパブリックデータを提供してるのは初めて知ったかも。
最後のほうに出てくる、非専門家でもレシピを機会学習を使って自動分類などができる仕組みについて。 ちょっと前に自分のまわりで自動で分類などをできる仕組みが欲しいみたな話があったので懇親会でいろいろ聞いてみた。 …のを書こうと思ったけどchezouさんが自身のブログでそこらへんをすでに書かれていたのでぜひ読んでみて欲しい。
技術力を事業の強みするために必要なこと
大野さんのお話。 正直、難しい感じだったので改めて発表を見て頭を整理したい(動画待ってます!) "技術は議論や調整に弱い、決定とテストを行う" とか "定義」があることで「評価」が簡単になる" の言葉が印象的だった。
“「定義」があることで「評価」が簡単になる” こういうの、暗黙的にやらずちゃんと明文化して共有するの大事なんだろうな #CookpadTechConf
— cなんとかe (@chiastolite) 2016, 1月 23
開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法
五十嵐さんのお話。 ディレクターだけどコードも書いてるらしい。
中の人からはこんな話も。
五十嵐さん、エンジニアとディレクターとマネージャー全部やってて激ヤバです #CookpadTechConf
— Issei Naruta (@mirakui) 2016, 1月 23
やばい。
技術先行だったりで思いついた機能で失敗した話と今はどう取り組んでいるかと話でした。
この日どの発表もすばらしかったんだけど、個人的に一番好きな内容でした。 特にこのページ。
機能の前の価値探しの話なんですが、まずベースに企業理念の反対な状態「料理が楽しくない」ってところから考えるところがおもしろいなぁと。 あとは欲求もあったら嬉しいみたいなポジティブなものではなくネガティブなものにフォーカスして、あっても使わない機能が入ったりしないようにしてるみたい。
フォーカスするのは欲求までにしてるぽいのが大事なんだろうなぁ。最終的にユーザーに欲しい物まで聞いちゃうと速い馬問題になりかねないし #CookpadTechConf
— cなんとかe (@chiastolite) 2016, 1月 23
よくやっちゃいそうな 技術→製品→価値 ではなく、価値→製品→技術 という流れで考えていくのはなんとなく↓のゴールデンサークルぽい考えですね。 自分もぜひ取り入れたいと思います。
サイモン シネック: 優れたリーダーはどうやって行動を促すか | 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してきた
(最後の追記も見てね)
資料はこちら
Itamaeと自分
次にやりたいこと
資料の中の「vagrantが無くなる」「itamaeの--sshが無くなる」とか書いてる件について
Mitchellと話したら、Vagrantもしばらくは開発して行くけど、数年かけて徐々に完全移行するとの事。今はラッパーな感じ。 @chiastolite: Vagrantが終了するん?
— Michael H. Oshita (@ijin) 2015, 9月 28
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の中身を見て今まで誤解していたことや、ぼんやりとしたイメージしか持てなかったことを改めてはいかがでしょうか