# lib/tasks/app.rake
namespace :app do
desc 'Set database.'
task :set => %w(db:migrate db:seed)
desc 'Reset database.'
task :reset => %w(db:migrate:reset db:seed)
end
dpkgやrpmのメタパッケージみたいにそれ自身は何もしないメタタスクを定義しておくとちょっと便利。
これまたRailsじゃなくてRake Tips・・・。
「Backlogは素晴らしい。」
そもそもBacklogの素晴らしさに嫉妬の炎を燃やしていたところにCacooというサービスが出てきた。それ以降、僕らは自分達の仕事にCacooを使っている。(Webアプリのワイヤーフレームを書くため)
これも株式会社ヌーラボのサービスだという。
僕は別にヌーラボの回し者でも知り合いでも何でもない。「Web+DB Pressでヌーラボって名前をちょっと見たことあるなー」ぐらい。
個人やSOHO、LLCといった小さなグループがインターネットを使って共同作業する機会がこれからさらに増えてくのは間違いない。ローカルアプリよりWebアプリ。社内サーバーより社外サーバー。社外サーバーよりASP/SaaSの方が管理が楽。
数年前から海外のITベンチャーがGithubスタックと呼ばれる複数の外部サービスを組み合わせて仕事をするというスタイルが広まってるらしい。しかもそれは個人で使うには無料だが会社で使うと有料というしっかり儲けるモデルらしい。国内にももっとそういうサービスが必要だ。
そんなことは分かる。全くもって正論だ。でもそれを上手にやるのは簡単じゃない。
自分の作った製品、もし全く平等に見てはてブ経由で知って、他の製品群の中から本当にそれを選ぶ?
自分さえ使わない製品は犬も食わない。
よく「そういうソフト/サービスありましたよ。」という話しを聞くけど、それ、使ったんかい。毎日の仕事で使ってるんかい。
機能要件さえ満たしてればいいなら、XOOPSがあれば全てのサイトが作れる。OpenPNEがあれば全てのSNSが作れる。もうサイトの成功は約束された。
でも違うでしょ?
デザインが違うだけでもそのサイトのカラーは全く違うものになり、出来上がるコミュニティも違う。それに伴って必要とされる機能も値段も全然違う。
ユーザーのフィードバックを元に、自分で使ってみた感触を元に、細かい改良を積み重ねていって、かゆいところに手が届く、心地良いものにして始めてユーザーが使ってくれる。
ユーザーが製品を自分のツールボックスに加えてくれるかどうかはそういった細部にかかっている。
オープンソースを中身も見ずにカスタマイズした奇形児のようなサービスを使ったかい?
「バイクが2台無料だからこれをつなげて車を作れば安く出来るはずだ」といった方法論で作られた道具を自分のツールボックスに入れておきたいかい?
株式会社ヌーラボは確実にドックフードを食べている。繰り返される改良に耐えられる地に足の付いた確かな技術がある。(想像)
勿論Cacooには個人的に足りない機能もあるし、ここがこうだったらいいなという点もある。しかし、着実に良いものになっていくだろうという期待と自分のツールボックスに入れておきたい魅力がある。
Help me, hackers!をやり始めてからパッチ送ったり、貰ったり、pull requestしたり、されたり、ソースを通したコミュニケーションが増えて楽しい。
今まではpull requestとかpatchとか滅多にやらないからやり方忘れててやる度ににググってた。
ソースコラボのための色々な方法
gitでpatchを作る
適当にファイルを修正してリポジトリのルートで
% git diff > foo.patch
gitで作ったpatchを当てる
同じくリポジトリのルートで
% patch -p1 < foo.patch
Mercurialでpatchを作る
適当にファイルを修正してリポジトリのルートで
% hg diff > foo.patch
Mercurialで作ったpatchを当てる
同じくリポジトリのルートで
% patch -p1 < foo.patch
githubでfork
githubでpull request
forkした自分のリポジトリでpull requestボタンを押す。recipientにマージして欲しい人を選択してメッセージを送る。(自分のリポジトリからpullしてねとお願いする)
gitでpullする
取り込みたい他人のリポジトリをpullしてくればいいだけ
% git pull git@github.com:komagata/haml.git master
bitbucketで・・・
githubとおなじようなもん。(以下省略)
githubやbitbucketだったらどうせローカルで動作確認するんだし修正する側もマージする側もfork -> pull requestの方が楽かと思う。それにcommit履歴に他人の顔が入って楽しい。
キャッシュを確認
% dscacheutil -cachedump -entries host
キャッシュを削除
% dscacheutil -flushcache
![]() |
|
iPadのケース買いました。
電子ブックリーダー用途メインで使いたいので普通の見た目にしたかった。
これが普通の状態。
これが開いた状態。
そしてこれが・・・「止める部分を切っちゃった状態。」
だって、あの部分糞邪魔なんだもん・・・。
個人的に道具は役割さえ果たせばぞんざいに扱いたい派。
ちょっとこういう事言うとスゴい怒られるかもしれないけど、MacBookもiPadもコンピューターの中じゃ無駄が無いデザインだと思うけど、コンピューター以外の広い意味でデザイン業界全体で考えれば単に邪魔にならないデザインってだけで特に愛着は無い。
すいません、すいません、石を投げないで下さい・・・。
HTMLのインデントを綺麗にするサービス、「Ham Cutlet」を公開しました! | FJORD, LLC(合同会社フィヨルド)Help me, hackers!に続くフィヨルドのサービス第二弾をリリース!今回はちょっとした便利ツールHTMLのインデントを美しくするサービス、その名も「Ham Cutlet(通称ハムカツ)」です。
HTMLのインデントを綺麗にするサービスHam Cutletを作りました。
中身はHaml::HTMLでHTMLをHamlにして、Haml::EngineでHamlをHTMLに戻すだけです。
で、Haml::Engineはメインなので問題無いんですが、Haml::HTMLはおまけ的な感じなのと、仕様的には問題のあるHTMLでもある程度許容しないと使えないのでちょっと弄る必要がありました。
class Hpricot::Comment
def to_haml(tabs, options)
content = self.content
if content =~ /\A(\[[^\]]+\])>(.*)<!\[endif\]\z/m
condition = $1
content = $2
end
if content.include?("\n")
"#{tabulate(tabs)}/#{condition}\n#{parse_text(content, tabs + 1)}"
else
"#{tabulate(tabs)}/#{condition} #{content.strip}\n"
end
end
end
class Hpricot::Elem
def to_haml_filter(filter, tabs, options)
content =
if children.first.is_a?(::Hpricot::CData)
children.first.content
elsif children.first.is_a?(::Hpricot::Comment)
children.first.content.gsub(/\/\/$/, '')
else
CGI.unescapeHTML(self.innerText)
end
content = erb_to_interpolation(content, options)
content.gsub!(/\A\s*\n(\s*)/, '\1') original_indent = content[/\A(\s*)/, 1]
if content.split("\n").all? {|l| l.strip.empty? || l =~ /^#{original_indent}/}
content.gsub!(/^#{original_indent}/, tabulate(tabs + 1))
end
"#{tabulate(tabs)}:#{filter}\n#{content}"
end
end
一つは単一行のコメントに改行が付かないところ。これは単なるバグだと思います。
もう一つはHamlのせいというかHTMLの仕様的にOKかどうかわからないんですが、
<script type="text/javascript"><!--
function foo() {}
//--></script>
よくあるこういう書き方への対応部分です。HTML -> Hamlの変換時に、Javascriptの部分は:javascript haml_filterに、HTMLコメントはHpricot::Commentとして処理されます。
上記はscriptタグ -> HTMLコメント -> Javascript(+Javascriptのコメント)という構造になっています。
Haml::HTMLでは、scriptタグの中はjavascriptかCDataしかないと思って油断しているのでHTMLコメントが処理できません。さらにHTMLコメントの中のJavascriptは本来HTMLでは中がどうなってようが大した問題じゃないんですが、Javascript的には大問題。最後にあるJavascriptコメントも処理出来てないので修正。
CSSのtypeタグも似たような感じで修正。
お陰でこんな感じで綺麗になりました。
<script type="text/javascript">
//<![CDATA[
function foo() {}
//]]>
</script>
Yahoo JAPAN!のHTMLを食べさせたらInternal Server Errorになってしまう - Help me, hackers!
Yahoo! JAPANトップページのHTMLを貼り付けてみたところ、Internal Server Errorとなってしまいました。不味いものを食べさせてしまったみたいで申し訳ないですが、サーバー側でログを調べてもらえると解決も早そうです。
Yahoo! JAPANのHTMLを読めるように対応していたら他のページの対応率もグッと上がって良かったです。
先週、ダイアリーがリニューアルされました。今回のリニューアルはダイアリーの応答時間の改善が目玉の一つとなっており、そのために1週間リリースを延ばし、改善の時間を確保していました。今回は、この改善について記しておきます。
確かに体感で「何かサクッってる気がする」って感じがします。iPhoneで鬼見易くなったし、僕ははてダあまり使ってないんですが、はてダユーザー以外にとっても嬉しいリニューアルですね。
githubでソースを公開しつつHerokuで動かすアプリの場合、git push heroku masterでHerokuにビルド、git push origin masterでgithubに公開という風に分けられて良いんだけど、database.ymlみたいな設定ファイルが困る。
具体的にはtwitter_auth.ymlというファイルにTwitter APIのキーやbitly APIのキーを入れていて、githubにはtwitter_auth.example.ymlをアップしてるんだけど、Herokuにはホンモノをpushしないといけない。
「ブランチ作って、ホンモノの設定ファイルコミットしてpushしてブランチ削除」みたいなshellスクリプトでも書く必要があるのかな?
結構これみんな遭遇しがちなことだと思うので誰かがもっとスマートな方法知らないかと思ってググってるけど見つからない。
追記:教えて頂いた内容で解決しました。Heroku - ソース中のパスワードなどの処理 - komagata [p0t]
Mac(Snow Leopard)でpgのgemインストール。
% sudo port install postgresql84
% export PATH=/opt/local/lib/postgresql84/bin:${PATH}
% env ARCHFLAGS="-arch x86_64" sudo gem install pg
CentOS 5.3
$ sudo yum install postgresql84-devel
$ sudo gem install pg