thinの速さを確認しようとしてOSX 10.7のぶっ壊れたabに苦労したにも関わらず、thinの利用をやめた。理由は
なんかよく分からないけど一部の画像が来ないとかCSSが来ないとか、ちょこちょこ変な見栄えになるから。
HTMLは来るのでサーバサイドの確認には十分なんだけど、見栄えを含むデキの確認にはちょっと安心して使えない。development環境を共有してフロントの人と共同作業するときにお互いにドキッとするので、多少のスピードは我慢して安心を優先した。
何か設定などがあるなら教えてもらえると嬉しいです。
以前 jarp で
こんなことやってて、変なことやってるなぁと思ってしまったんだけど、
その必要性が分かってしまった
ので自分もやってみた。
というのも git には svn info 相当の情報がないので、今自分の使っているリポジトリが何かよく分からなくなってしまう。もちろん
git remote -v
とかやると origin を表示できたりするんだけど、自分の場合は
origin の同じ複数の git リポジトリを作ってしまう
ので、これだけだと情報量が足りないのだ。というのも
で触れたように、svn の中に（今回の編集とは）無関係なファイルが多すぎるので、別個に git リポジトリを作って作業を始めるようにして、不要になった git リポジトリを削除するようにしているんだけど、念のためこの git リポジトリは bundle ファイルを作ってバックアップを作ったりもするので、
同じ svn tree を起源に持つが作った時期も作業内容も違う git tree が複数できる
という、ちょっとどうだろうという状態になってしまう1。そこで、commit log を見てみるも、すでに混乱したあとでは終盤の commit がよく似ていたりする。
そうだ。最初の commit を見れば違いがはっきりするはず。なんだけど、うっかり
git log -1 --reverse
すると最新の commit だけが出てきてしまう。つまり、-1 だけが有効になっている。正解は
git rev-list --all --reverse | head -1 | xargs git log
–all は jarp の記事では不要っぽいけど、試したリポジトリでは必要だったのでこんな感じにしてみた。
ついでに
alias git-info='git rev-list --all --reverse | head -1 | xargs git log --name-only'
こんなものを用意しておくといざってときに助かるかも、と思った。残念ながら .gitconfig の中ではパイプを使う処理は alias 登録できないみたい。
たぶん、フツーはこんなもの必要ない。
cf.
優しいgitの育て方 : info - ヽ( ・∀・)ノくまくまー - s21g
いろいろ事情があるのです。staging サーバ内を開発者以外が直接編集したりするのでそのバックアップをひっそり git で取ったり。 ↩
超いまさら。
やったこと。
- tDiary のパッケージを落としてくる
- 展開
- 前のバージョンでいじったCSSを適用
- ローカルで動作の検証
- sync
の予定だったんだけど、sitecopy で作ってる sync の仕組みがここに来てうまく動かず。いろいろいじってるうちに逆方向（remote -> local）で sync が動いててオレ涙目。結構ビックリした。まぁDOC_ROOT以下とデータ置き場と全部別々に sync できるようにしてたので、全部いっぺんにひどいことにはなかなかならないんだけど。
でだ。実は 4 の動作検証というか動くようにするのにちょっと手間取った。
キモは tdiarysearch1
2.3系の utf-8 で動くようになっていて、2.2 では conf を eval した瞬間にエラーで止まっちゃう。仕方ないのでバージョンを見て振り分けることにした。成果は coderepos へ上げたので 2.3 ですでに動いている人も試してみてほしい感じです。
/platform/tdiary/util/tdiarysearch – CodeRepos::Share – Trac
あと最後にHTMLが一部変わっててCSSを直し足したりした。cache もクリアした。
さて、やっとこれで読書日記書けるようになったよ。
どうしても tdiary grep と呼んでしまうけど ↩
今回初めて気がついたけど、OSX は、ネットワークの設定からプロキシの設定をいじることができる。
この設定は上に挙げた以外の
- Safari
- Sunrise
- Camino
- iCab
で有効だった。
手早いかと言われると操作性として微妙だが、複数のブラウザに一気に反映させられるのはなかなか魅力。
Opera は独自のプロキシ設定を手早く反映する工夫がなされている。
プロキシの on/off をクイックメニューからすぐに切り替えられるのだ。
Firefox は例によって extension で。
SwitchProxy Tool :: Firefox Add-ons
インストール後、何か特別なことをした覚えはないけど、いきなりツールバーに日本語で出現したのでビビる。すげぇ。
※ 本人に補足されたっぽいので調子に乗ってアイディアを追加しました。
最速インターフェース研究会 :: 萌ディタとSleipnirとWEBrickを使って人のサイトのCSSをリアルタイム編集するデモ
非常にありがたいんだけど、実際使ってみて以下の点がイマイチかなと思った。
- full_path を + で求めてるけど、File.join() 使えば / の有無を気にしなくて済むよ。
- rewrite の設定があるけどファイルが存在していないから rewrite を行わないのか、rewrite の設定がないから行わないのか分からない。
- rewrite 設定ってハッシュじゃなくてそのままパスの文字列を書いたリストでもいいような？
- dir があるんだからサイトごとにそのサイトの構造に従ってファイルを置いておいた方が分かりやすくない？
- rewrite と capture で設定を分ければいいかな？ capture の方は proxy ホストのファイルを使う、rewrite は通常の URI の rewrite に使う、ということであれば、rewrite はハッシュの方がよさげ。
こんな感じ？
まだ File.join() の部分しか直してないんでスクリプトを上げたりはしないけど、そんなことを思った土曜出勤の昼下がり。
たぶん1年以上前のものなので、現在は超絶パワーアップしたものが使われているはず。
最後に一言。便利なものをありがとう！
[2007-10-17 追記] 高速化アイディア
なんか遅い気がするのでとりあえず吐き出しとく。ヘボい機械使っててごめんなさい。
- hostname をキーにしたハッシュもあるといいかも
パースしたら enable になってる filter だけで以下のようなハッシュ
host1: filter1
host2: filter2
を作ると hostname だけで rewrite の設定があるかどうか分かるので少しは速くなるかも。公開されてるコードだと filter や host の数が増えてくるとリニアに遅くなる予感。
- そのためには filters もハッシュの方がよい？
公開バージョンのように
filters:
-
name: value
enable: bool
target:
- host
-
name:
...
という構造になってると特定のフィルタだけを呼び出すのは難しいので
filters:
filter1:
enable: bool
target:
filter2:
...
って感じにすると host -> filter の呼び出しがスムーズになる気がする。
- req.path_info が rewrite の設定に引っ掛かったどうかチェックした方がよくないか
公開されているバージョンのコードだと rewrite のルールをガーッと読んでリクエストされたパスに対して gsub! を掛けまくったあとに、問答無用で FileTest.file? してるけど、まったくの想像で申し訳ないけどすべてのリクエストに対してこれらの行程が走ったらそら重たいような？
gsub!() の結果が nil でないときに rewrite が起きたと言えるわけだから、それを保存する値を適当に作って、rewrite が起きていれば FileTest.file? から File.read() っつー流れはどうだろう。
チョーうれぴーっす。
サービスを科学する”新しい学問、IBMが開拓中 (ITmedia)
具体的なところがよー分からんが、コールセンターサービスってのは確かに今ものすごい需要だと思う。なんとなくそれって生活を豊かにするための道具に振り回されてるって感じで人間というか文化のダメさみたいなものを感じずにはおれないけど、まぁそれはこの際置いておこう。
他にも経済からではなくサービスそのものに注目して面白そうなものって結構あるような気がするけど、書いてる今は思いつきません。