Gitコマンドラインショートカット | POSTD
私は多くの時間をターミナルの前で過ごしていて、そのほとんどをGitコマンドのタイピングに費やしています。ワークフローを高速化して、毎日何百というキーストロークを節約するために、Bashのエイリアスと関数を使って1組のコマンドラインショートカットを作りました。 Git Bashエイリアスと関数 Gitではエイリアスを設定できますが限定的であり、節約できるキーストロークは、ほんの数ストロークです（例えば、”git checkout”の代わりに”git co”とタイプすることはできますが、まだ”git”とタイプしなければなりません）。Bashはターミナルのデフォルトのコマンドラインインタープリタなので、Bashエイリアスを設定して、さらにキーストロークを減らすこともできます。 これが、私のGit Bashエイリアスと関数のリストです。ご自分のエイリアスや関数の保存先ファイル（例えば、~/.bas
Effective Ruby を読んで - ボクココ
以前から気になっていた "Effective Ruby" を読んだ。 Effective シリーズは中級〜上級向けプログラマーの読むべき本として親しまれている。 個人的にもっとも得意な言語はRubyだったので、このシリーズが出るのを楽しみにしていた("得意な"と変換しようとしたら"特異な"と変換されるくらいには使用している)。 中身のネタバレはもったいないので、この本を通じて自分が今まで見落としていた点を挙げてみようと思う。 nil 時の対応 array = hoge() array.split('/')[1] NoMethodError: undefined method hoge for nil:NilClass。Rubyプログラマーなら何度も遭遇するであろうこのエラー。配列でnilっぽくしたい時は空の配列を用意してあげたいところだが、その変数にnilが返ってきてしまうとこの問題に出く
雑な発想を活かすチーム作り - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Railsでルーティングが無いときの挙動を変える - Qiita
挙動を変えたい場合がある config/routes.rbに定義されていないパターンのパスを持つHTTPリクエストが来ると、Railsは非Production環境では例外を発生させ、Production環境では404用のレスポンスを返す。HTMLであればpublic/404.htmlを変更すれば幾つかの要求は満たせる。しかし、例えばJSONを返すAPIを提供したい場合、またレスポンスを動的に返したいような場合、任意の処理を実行可能にしたいという要求が生まれる。 全パターンに一致するルーティングを定義する 例えば GET /v1/users のように/v1以下をAPI用のパスに利用しており、/v1/foo などの定義されていないパスにリクエストが来たとき、適切な処理を実行させたいものとする。これは、matchを利用して全てのパターンに一致するようなルーティングを末尾に定義しておけば実現できる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
