コンフリクトの解決を記録して再適用する git rerere - Qiita
はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所
AWS DevDay Online Japan に「AWS CDK はどう使いこなすのか、初期開発から運用までのノウハウ」というタイトルで登壇しました #AWSDevDay | DevelopersIO
はじめに CX事業本部IoT事業部の佐藤智樹です。 先日AWS DevDay Online Japan というイベントで「AWS CDK はどう使いこなすのか、初期開発から運用までのノウハウ」というタイトルで登壇しました。 今回は上記の登壇で使用した資料の公開と今回の発表をやりたかった理由などについて書きます。 動画 登壇資料 発表の理由 この1年半ほどの間でAWS CDKを利用した案件へ4,5件ほど関わらせていただいて、最初にここを設計しといた方がよかったという部分やチーム内で認識がずれていると後から直すのが大変な部分を全体的に紹介しました。今回紹介した個々の情報はネット上にもある程度はあるのですが、開発の最初期から運用まで考えてまとまった情報はない気がしたので、今回まとめて発表してみました。今後AWS CDKを本格活用したい方の参考になれば幸いです。 後、以前のイベントでAWS CDK
ユーザー投稿型サイトのSEO対策
Zennという技術情報共有サービスを運営しています。長期的にZennの流入経路の多くは「検索」になると予想しています。むしろ検索流入が多いサービスであるべきだと考えています。 具体的なソースコードや数式が並ぶ文章は、ソーシャルメディアではあまりシェアされません。ある程度抽象的な内容でないと、読者層が狭く、読み手も労力を必要とするからです。 （具体的な話を盛り込みつつ話題を集める文章を書けるスーパーな方もときどきいますが） しかし、いざ仕事で問題に直面したとき、自分を助けてくれるのは、たいてい具体的なコードを含む記事や実際に問題に直面した人によるニッチな体験談です。すぐに誰かに届くものではないけれど、後から同じ道を通った人は助かる… そんな先人の知恵がたくさん集まる場所になったらいいなと考えています。 SEOに関する情報収集源 本題に入る前に、僕が参考にしているSEO対策の情報源を紹介してお
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaトラブルに備えよう #jjug_ccc #ccc_h2
http://paperboy-all.github.io/docs/nagios/learning.html
