コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
.gitconfigにinclude書くと捗る - 時計を壊せ
2012-08-20一部訂正 githubにdotfile上げてる人は結構多いですが、 github.tokenなど、一部の設定は公開されると困りますね。 そんなときはincludeディレクティブを使うとローカル用の設定を別ファイルに出来るので捗ります。 [include] path = .gitconfig.local [core] editor = emacs pager = lv whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol excludesfile = .gitignore こんな感じでやると.gitconfig.localを読み込んでくれるので、 github.tokenなどは.gitconfig.localに書いておくといい感じになって捗ります。 参考： http://stackoverflow.com
#isucon に参加してきました。 - 時計を壊せ
うっかり申し込むのを忘れて、定員に達して出れなくなってたので ぬーん（´・ω・｀）ってなってたんですが、 @walf443さんに誘われたので#isuconに参加してきました！ 人数が多い方が有利だとの事だったけど正直足手まといになった気しかしないのは秘密。 #isucon ってなに？ Iikanji Speed Up CONtest の略でISUCONだそうです。 reverse proxy1台、appサーバー2台、DBサーバー1台の構成のWebアプリを いい感じにスピードアップしてあげるコンテストです。 概要: [ http://blog.livedoor.jp/techblog/archives/66528186.html ] ソースコード等: [ https://github.com/tagomoris/isucon ] WHKチームの行動まとめ *1 gitが無いと俺達はソースの変
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
