コードレビューさせないようにコミット - Qiita
対象 開発フローの中でコードレビューを実施しているひと git add -p や git rebase -i でコミットの分割や統合ができるひと レビュー無しにマージしてもらうために同僚をいかに抱き込むか。 という話ではなく、レビュワーの コードレビューの負荷を下げる ことを意図しています。 無視できるコミットを増やす どうすればレビュワーがより短時間で自分の書いたコードをレビューできるか。この問に対して、レビューの妨げとなるものを排除する、というアプローチがあると思っています。そのための良い方針だと考えている 無視できるコミットを増やすこと について書きます。 前提 コミット どのコミットにおいてもテストが通るようにする コミットメッセージ ちゃんと Git のスタイルで記述する (Gitのコミットメッセージの書き方 の原則を守る) Git の操作 雑にコミットしても、後できれいにコミッ
はじめに | Volt Introduction and Docs
Voltとは Volt は Ruby の Web フレームワークで、サーバーサイドとクライアントサイドの両方のコードを Ruby で記述できることが特徴です。(クライアント側では opal を利用します)。Volt では、ユーザーがページに対して行った操作に応じて自動的に DOM が更新されます。ページの状態は URL として保持されるので、ブックマークによって以前と同じ状態に戻ることが可能です。 Volt では、HTTP を介してクライアントとサーバー間のデータを同期するのではなく、永続的なコネクションを利用します。したがって、ある1つのクライアント上でデータが更新されたときには、データベース、および他のリスニング中のクライアント上でも更新が行われます。(しかも、そのために設定を行う必要はありません)データの更新をコントローｒルするためにパーミションとバリデーションを構成することが可能で
9 Slack Hacks We Couldn’t Live Without - Keen - Event Streaming Platform
9 Slack Hacks We Couldn’t Live Without keenioblog December 17, 2014 At Keen IO, we are huge fans of Slack, a badass chat platform for internal team communications. Our whole company uses it every day as a single, centralized hub where we can discuss stuff, deploy code, and monitor our analytics service. Slack is great in all sorts of ways: Easy on the eyes, nice search functionality, handy away no
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
