link_to 等のヘルパメソッドは sinatra 本体には含まれていませんが、 sinatra_more という gem が用意されています。 install
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
今朝Snow Leopardにアップデートしたら、デフォの設定でイーモバイルがうまく動作しないけど、環境設定の「ネットワーク」→「詳細」で以下の設定をしたらちゃんと接続できました。 製造元:一般 機種:Dialup Device ダイアル:パルス USBモデムD23HWを使っています。他の機種が上手いくかどうかわからないけど….
Gemを作るのが面倒になってきたので、githubから直接requireできたら楽になるかもしれないと思い、試してみました。 1 def git(uri, sha1, options = {}) 2 require "tmpdir" 3 basename = File.basename(uri) 4 outdir = File.join(Dir.tmpdir, basename, sha1) 5 unless File.exist?(outdir) 6 sh = proc{|command| IO.popen("#{command} 2>&1"){|io| io.read}} 7 sh["git clone #{uri} #{outdir}"] 8 sh["cd #{outdir}; git checkout #{sha1}"] 9 end 10 $:.unshift
MacOSXのTerminal.appで、選択をした時に、 自動的に選択した文字列をコピーするSIMBLプラグイン TerminalCopyOnSelect を作ってみました。 TerminalCopyOnSelect.bundle.zip インストール方法 まずはSIMBL をインストールします 上述のTerminalCopyOnSelect.bundle.zipファイルをダウンロードして展開します 展開されたTerminalCopyOnSelect.bundleを、 ~/Library/Application Support/SIMBL/Plugins/の下にコピーします。 ディレクトリが無い場合は作成してください。 Terminal.appのプロセスを終了し、Terminal.appをもう一度起動します これでOKです。 一時的にこの機能をオフにする場合は、 以下のようにメニューから
急遽大門駅付近で開催されることになったCouchDB勉強会のレポートです。 参加者: @maiha, @yugui, @yamaz, @takiuchi そもそもCouchDBは何かというと、 Apacheのプロジェクト で、分散、耐障害性、スキーマフリー、ドキュメント指向なデータベスで、 RESTfulなAPIを使って制御します。 結構前から存在していたのですが、取りかかるきっかけがなくてスルーしていました。 しかし、dm-couchdb-adapterを使ってMerb/DataMapperで利用可能という事が分かり、にわかに盛り上がってきました。 早速、couchdbをインストールします。 いまのところ、ソースからcouchdb-0.9.0をインストールするのが一番良いようです。 macportsのcouchdb-0.9.0aでは動作が微妙に異なっているようでうまく動きませんでした。
弊社は、deployツールとしてcapistranoを使っています。 しかし、Capistranoのメンテナンスが終了するという話("Jamis Buck氏, CapistranoやSQLite/rubyの開発を終了"参照)を聞いても、 特に困らないという事に気がついて、あらためて驚きを感じました。 なぜだろうと考えてみると、それはGitとGitHubの存在による所が大きい。 GitHubにソースがある限り、メンテナが不在でも勝手にforkして 野良patchを書いたり、それを集めてきてちょっとした stable release的なものを作ったりする事ができてしまう。 もちろんそれは、今までだって頑張れば出来た事だけれど、 Git/GitHubは、それを全く違う次元で簡単にしてしまった。 かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの
従来のソフトウェア工学が決定的に間違っている点 従来のソフトウェア工学が決定的に間違っている点は、 ソフトウェアを作るソフトウェアに関する工学ではない事だと思う。 100倍の生産性を達成するためには、ひとつ階段を上にのぼる必要がある。 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 「やらなきゃいけない」仕事が20%で、残りの80%が「やりたいしごと」。たとえ単純作業でも、残り80%にそれが属しているのであれば嬉々としてやってしまう。彼らからこれを取り上げてしまうと、残り20%も小さくなってしまう。好きなようにやらせておくのが吉である。 つまらないコードを生成するコードを書く事は、 つまらないコードを書く事自体と比べて何倍も面白い。 手でコードを書くプログラマと、コードにコードを書かせるメタプログラマでは、 規模が大きな仕事になるほど差が開いていくと思う。 「ソフトウェア工学
RubyでバイナリデータをBase64エンコードする場合、 require 'base64'をしてからBase64.encode64(binary)をするか、 以下のようにpackのmテンプレートを使うことができます。 しかし、アップロードしたファイル用のテンポラリなファイル名 などに使用する場合、Base64でエンコードした文字列は ファイル名に使えない(可能性が高い)文字を含んでいるため、 そのような場合にはbase64url形式でエンコードします。 base64url って何? base64url とは、base64 を基に RFC4648 で規定された変換方式で、url とファイル名に使用しても安全になるように設計されています。変更点は、base64 では + と / が使用されていますが、それを - と _ を使用するようにします。具体的には、base64では「ABCDEFGHI
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ここやここで書いたSchwartzさんですが、Git@goole techtalkの資料公開をリクエストしてみました。 次の日の朝には返信が帰ってきて、「1年ほど前のやつだしちょっと話している内容とはちょっと違うけど大体同じだと思う。」ということで教えていただきました!yay! CCで公開されています(商用はNG)。すばらしい。 SchwartzさんのGit資料 http://www.ourmedia.org/node/276036 http://www.archive.org/download/Introduction_to_git/Git.pdf 資料直リン Schwartzさんの他の資料へのリンク http://our
yield と content_for の使い方の紹介。 Railsを使っていてありがちなのが、layouts/application.rb で共通レイアウトテンプレートを使っているときに、画面ごとに <head> の中身を変えたいという事。 そんなときは yield と content_for を使えばOK。 layouts/application.html.erb <head> (- - snip - -) <%= yield :head %> </head> foos/bar.html.erb <% content_for :head do %> <%= javascript_include_tag 'iepngfix' %> <% end %> こんな感じに、画面ごとに <head> に追加したい項目を書くことができます。 また、 content_for は、何度呼び出してもOKで
SVN使いがとりあえずGitを使ってみるなら、 Git - SVN Crash Course がお勧め。 自分で覚えるためにポイントを書いておく。 ちなみにZSHはGitのサブコマンドも良い感じにTAB補完してくれます。 git pull でリポジトリから持ってくる。 管理する単位はProject Tree=リポジトリ。しかしWorking Treeという用語も散見される。ちょっとどれが正式な呼び方なのか不明。 手元に持ってきたProject TreeはWorking Copyと呼ぶ Project TreeはTagやBranchを含んでいる。従ってURLはリポジトリの場所を表すだけ。 デフォルトのブランチ名はmaster (SVNの) Working Copyのルートディレクトリにだけ.gitディレクトリが作られる。SVNやCVSでサブディレクトリ全部に管理ディレクトリが作られるのとは対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く