Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね？ $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e
minimist - Weblog - Hail2u.net
Node.jsでCLIツールを作る時に使えるコマンドライン・オプションのパーサーとしてminimistをよく使うようになった。なかなかの好感触。同様のものとしてoptimistやその後継のyargsが有名で、しっかりと作るならそっちの方がよく出来ているけど、数個のオプションの切り替えと余りの抽出くらいならminimistの方が楽。 インストールしたら以下のようにパースしたいコマンドライン・オプションの配列を渡すと、良きに計らってくれたオブジェクトが返ってくるので、それを使うことになる。 #!/usr/bin/env node 'use strict'; var minimist = require('minimist'); var argv = minimist(process.argv.alice(2), { string: ['output'], boolean: [ 'sourcem
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
デザインの解剖 - MEMOGRAPHIX
武蔵野美術大学・デザイン情報学科の学生だった時、「デザインの解剖」というカリキュラムがあった。 デザインの解剖とは、グラフィックデザイナーの佐藤卓さんが独自に行ったプロジェクトで、コンビニやスーパーで売っているような日用品を題材に、ひとつの商品の構成要素を約20項目に分解、それぞれの項目で「どうしてこの部分はこうなっているのか」を、企業の担当者に直接取材して調査するというもの。この基本フォーマットを崩さぬまま、大学の授業としてアレンジしたのが、ムサビ版「デザインの解剖」だった。もちろん客員教授として佐藤卓さんを招いている。 今までに佐藤卓さんが「解剖」した商品は、ロッテ・キシリトールガム、富士フイルム・写ルンです、タカラ・リカちゃん、明治乳業・明治おいしい牛乳など、馴染みのある商品ばかりだ。このプロジェクトは、普段私達が「よく知っている」と思っているものが、実は「よく知らない」ことに気づく
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
aereal on Instagram: "電池膨らんでしまった……"
気になるデジカメ長期リアルタイムレポート：PENTAX K-3【第3回】 絞り込みによる回折の影響を確認してみた
