git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
リアル世界にレベル上限はない
http://anond.hatelabo.jp/20131212133805 オレは、小中高とそこそこくらいの勉強量で、現役で東大に入って、恥ずかしながら「オレは普通の人間と比べてレベルアップによるステータス上昇pointの高い優れた人間なんだろう。普通に努力を続ければ50歳くらいでレベルカンストしてスーパービジネスマンになってるはず。」と勘違いしてた。まあよくある「やればできる子」のスペック高いverみたいな感じ。 大学を卒業して就職してから10年くらい経つが、「ステータス上昇point」という考え方が大間違いだったことに数年前に気がついた。成長するやつと成長しないやつの違いって、「ステータス上昇point」じゃなくて「周りにいるモンスターの強さ（＝経験値）」なんだわ。つまり環境。心身が壊れない程度に強い（＝経験値が多い）課題に囲まれている環境。 オレは、両親兄弟の全員が旧帝大とかの高
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
