先日のポストの続き、と言うより一例として、 Lokka に対しての Rack Middleware の使い方を見てみたい。 Lokka は軽量でステキな、 Sinatra ベースの CMS で、オープンソースの権化みたいなクールな会社フィヨルドさんで開発、メンテナンスをされている。個人的にも使わせていただいているソフトウェアなのだけれど、今回の利用にあたって例えば以下のカスタマイズ要件が必要になったとする。 身内向け告知用 CMS のため、 heroku にデプロイする以上、一応 Basic 認証をかけたい さらに、 http でのアクセスは、全部強制的に https にリダイレクトしたい 全部 Rack Middleware でできます。 まず、 Basic 認証ミドルウェアは、 Rack に標準添付されています。 config.ru を編集。 Encoding.default_exte

今まで不細工な自前実装をしていたけど、シンプルでお手頃なものがあった。 zachinglis/crummy – GitHub 導入 Gemfileに以下の行を追加してbundle install gem 'crummy' 基本的な使い方 コントローラーでadd_crumbしてビューでrender_crumbs。 あとは本家のExampleを眺めるとなんとなく分かると思う。 といっただけで終わらずのもなんなので、以下は動作に関するちょっとしたメモ。 パンくずリストの表示 – render_crumbs ビューのパンくずリストを表示したい場所にrender_crumbsを埋める。 多くの場合はレイアウトファイルに書けばいいと思う。 <%= render_crumbs %> render_crumbsにはオプションがいくつかあるが、おそらく使いたいのはセパレータの指定くらい。 （デフォルトのセパ

(追記：2013-08-16) 本記事のトリビアを含む５５のトリビアを以下の記事にまとめました。 知って得する！５５のRubyのトリビアな記法 なぜかトリビア人気が再燃しているよ。 知って得する21のRubyのトリビアな記法 第２弾！知って得する12のRubyのトリビアな記法 これでみんながトリビア好きだということが分かったので、何とか絞り出して第３弾を書いたよ。ここでは第１弾、第２弾で使ったテクニックも使ってるから、知らないテクニックがあったら先に見てもらえるいいかもね。 1. Enumerable#each_with_object Enumerable#mapではブロックの代わりに&付きのシンボルを渡す技が知られているよ。 langs = ["ruby", "python", "lisp", "haskell"] langs.map(&:capitalize) # => ["Ruby"

2012年05月07日11:49 Ruby respond_withメソッドを使うと処理をDRYに記述できる Rails には respond_to というメソッドがあり、これを使うと同じリソースに対して複数のフォーマットでレスポンスを返す処理を簡単に書けます。例えば users_controller.rb で以下のように定義すれば、/users でも /users.xml でもひとつのアクションで処理することが可能です。 def index respond_to do |format| format.html # index.html.haml format.xml { render :xml => @users } end end さらに、Rails3.0 からは respond_with というメソッドが追加されました。これを使うと処理をさらにすっきりと書くことが可能になります。 c

This shop will be powered by Are you the store owner? Log in here

はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。では、効率的に開発・運用・保守・管理を行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えば

Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。 こんちわSig.です。今回は第29回Sugamo.cssで発表したネタ。スライド出せば良いや−、と思っていたのだけど@soh335がピュアな視線で訴えてくるので、重い腰を上げてBlog記事にしてみることにしました。 さて、Vimにおいて多数のファイルを対象に検索→置換する場合、だいたい２つの方法があります。 :argdo %s/FooBar/BarBaz/gce | update :bufdo %s/warnings/warningssss/gce | update 順に、引数リストを使う方法、バッファリストを使う方法です。:bufdoの類似で:tabdoとか:win

Rails アプリ開発時のログは、"rails s" したターミナルで screen のコピーモードを使うだとか、"tail -f -n 100 log/development.log" するだとか、いくつかの確認方法がありますが、私は less の使い勝手がよいと思っています。自動更新も検索も、両方できるからです。.bashrc 用の、こんな関数を書きました。 rlog() { it=$(git rev-parse --show-cdup 2>/dev/null)log/development.log && less -NRij10 +F $it } 簡単に解説します。 +F オプションで、tail -f のような自動更新モードでファイルを開きます。C-c で普通のモードに戻り、F を押下することで再び自動更新モードに入ります。 -ij10 は、 /, ? での検索のためのオプションです

最近、会社でシェルの操作方法について教えているのだが、 pgrep / pkill / skill / pidof といった 便利なプロセス操作系コマンドを知らない人が実に多い。 プロセスを殺すというのは、よくある作業なので 今回はコレについて書いてみる。 たとえば、これらのコマンドを知らない人が、 指定した名前のプロセスを kill する手順はだいたい 以下のようなものになることだろう。 $ ps aux | grep プロセス名 | grep -v 'grep' # コマンドの出力結果から pid を目で確認 12345 ... .. hoge .. .. $ kill 12345 この作業は非常に面倒で退屈だ。 もし殺さなければならないプロセスがたくさんあったときは どうするのだろうか。 おまけに、grep コマンド自身が候補に含まれてしまう事があるのだが、 grep -v grep