<< 2008/10/ 1 1. だいぶ git つかめてきた
2 3 1. Fastladder の bot の If-Modified-Since が変
4 5 6 7 8 9 10 11 12 13 14 15 16 1. Yapra で Trac の timeline feed を 1本に
17 1. git の pull request は fork 前提って理解で合ってますか
2. Trac の feed を merge する Yapra の YAML を ERB で作る
18 19 20 1. 超自分用 Mozilla extension メモ
2. Ubuntu へ避難
21 1. PLUTO読み始める
2. Gnome の環境を Mac に合わせるのを諦めた
22 1. Ubuntu でそこら中 Emacs 風に
2. IP messenger に四苦八苦
23 1. 英辞郎を Linux デスクトップで
2. Wedata のお勉強
24 1. MacOSX の open を GNOME で
2. git で svn status のようなもの
25 1. Yapra に Publish::Smtp 追加
26 1. revert, reset, rebase, ...
27 28 1. gnome-terminal って賢いな
29 30 1. evolution でカレンダーの共有
31 >>
トップ «前月 最新 翌月» 追記

2008-10-01 [長年日記]

_ だいぶ git つかめてきた

と言っても push とか pull とかしたいわけじゃなくて、

svn に突っ込む前のものを手元でだけ管理したい

という特殊な使い方をしているんだけど。というわけで push も pull も branch も merge も使ってません。要は現代的な RCS としてしか使ってない。

ちなみに個人的な好みでは Mercurial の方が好きだったんだけど、

  • Mercurial はバージョンと Python のモジュール絡みかなんかで、locale の設定がどうたらウザイことをぬかす輩がいた(要するにデフォルトのまますぐに使い始められないときがあった。たぶん PCC Mac だから。)
  • リポジトリに突っ込んでいない大量のファイルがあるディレクトリで使おうとすると圧倒的に git の方が Mercurial より速い
  • github を使えないとちょっと恥ずかしい

という理由で git も覚えなきゃ、と思って使っているのが現状である。積極的に使いたいわけでもないし svn との併用を前提に考えているので、git のいちいち操作性が微妙に違うところがヒジョーに気になっていたんだけど、だいぶ慣れてきた。最近便利に使っているのは以下のコマンドかな。

git commit -a
デフォルトでは add したもの以外は commit されない。
git diff [--name-only|--name-status]
svn のときは svn diff | awk '/^Index/ {print $NF}' ってやってたんだけど、git では必要なかった。
git log --name-status
これいい。変更のあったファイルの一覧が取れる。どのタイミングでどのファイルをいじったか分かる。patch の内容までは要らないけどいつ何をいじったか知りたいって場合は多いので。svn でもできるのかもしれないけど、svn の場合は Trac 任せなので細かい機能を知らないんだよな。
git log -n NUM
何個 log を表示するか
export GIT_PAGER=''
git は出力が長いときに自分で pager に処理を渡しちゃうんだけど、扱っているファイルのエンコードが Terminal のそれと違う場合とか化けてうざい。そこで pager の設定を空にしてやると pager に渡すタイミングを自分で制御できる。

まだよく分かってなくてちょこちょこ困るのは svn status -v 相当の情報の取り方。要するにどのファイルがいま変更とか追加されていて、それが commit される前の状態なのか、リポジトリに突っ込んでいないファイルを含めて一覧する方法。

個別には git diff --name-status とか git ls-files とか使ってなんとかほしい情報は取れるんだけど、一発でズバッと取れないかなーと思っている。なんでこういうことを感じるかっていうと、リポジトリに突っ込むつもりではいるんだけど、まだ突っ込んでいないファイルを一生懸命いじっていることが svn の場合はちょこちょこあって、それの確認に便利だからだと思う。git で手元のファイルを管理する分には必要になりそうなものは片っ端から突っ込んでいけばいいじゃん、というのがたぶん正解なんだろうなー。

ちなみに今は git メインでは使っていないので svn にコミットして一段落したら .git は消してしまっている。基本的にリポジトリは remote に置いておく方が安心だし、git master は今のところ存在しないので。


2008-10-03 [長年日記]

_ Fastladder の bot の If-Modified-Since が変

Last-Modified を勉強して意気揚々としていたところ、更新されてもいない item が Fastladder でどうしても更新として現れてしまうという現象に気づきました。

以前、生成済みの静的な feed ファイルについては公開時に checksum なりダイジェストで確認して行うといいというような話を書きましたが、今回の feed は動的に生成し、request header に応じて redirect させるとか 304 Not Modified を返すとか、細かい制御を行いたいと考えていました。この現象は要するに 304 が返ってないんだなーと思い、とりあえず bot についてはいくつかヘッダの情報をログに落として確認してみました。

そこで発見。

Fastladder FeedFetcher/0.01 という bot はサーバの response した Last-Modified ではなく、最新 item の pubDate(last modified) の日時を If-Modified-Since で送ってきている。

それはどうなんだ。

そんなにいくつも調べてはいないのですが、少なくとも FeedBurner についてはサーバの返した Last-Modified をそのまま送ってよこします*1。今回吐いていた feed は最新 item の日時と実際に feed を生成する時刻がずれており、つまり最新 item の日時と Last-Modified が合わないのは仕様です。ということは

Fastladder bot には必ず 200 が返ってしまう

のです。

やっぱ変だよなぁ、これ。と思って調べてみたところ、こんな記述を見つけました。

To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header field whenever possible.

cf. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

「ベストな結果を得るには、キャッシュの検証のために If-Modified-Since ヘッダを送る際には、クライアントは可能な限り前回リクエストで受け取った Last-Modified の文字列を正確に利用することが推奨される。」

わけですよ! やっぱそうだよね! なんで FeedFetcher は最新 item のタイムスタンプなんすか! Last-Modified を使ってくださいよ!

しかしじゃあなんで静的ファイルの場合は最新 item の時刻と食い違ってても更新として出てこないのかな? まだなんか秘密があるのかなぁ?

[追記] はてブに的確なツッコミ降臨。

kazuhooku 「推奨」であって義務じゃないよ。それに、RSSファイルが更新されたかというのと、フィードのアイテムの更新判定はまた別の話

いやまぁそうなんですけどね。もう一度整理すると疑問は2つあって、

  1. あえて違う値を使う意味あんのかなー?
    • 例えば Last-Modified が返ってこない場合とかなら分かります。まーでもだったら If-Modified-Since にそれ付けてもたぶん意味ないよなーと思いますけど。
  2. なぜ今回の feed だけ更新判定ミスってるのかな?*2
    • これはこちらでもっと追求しないといけないと思います。

ということなんですよね。もしかして吐いてる HTTP date がまだ何かおかしいのかしら?(これがいちばんかっこ悪いパターン。)

個人的には今回の件以外にも更新判定ミスっててちょっと困ってる feed があるのですが、これも合わせて調べてみた方がいいかな。これは自分で提供してるものではないので、外から分かる範囲になっちゃうけど。

[2008-10-16 追記]

その後、誤検出については内容を増やした辺りからなくなったように思う。

んだけど、なんか今日気づいたけど If-Modified-Since に Last-Modified から 35分弱早い謎の時間を送ってくるようになっていた。これは予想していなかった。なんだろう、この微妙にずれた時間は。

Tags: Web Feed

*1 最初実は間違えて JST な Last-Modified を返していたのですが、そのときも真面目に GMT なスタンプで送ってきてました。実は HTTP date の仕様に気づいたのはこれがきっかけでした。

*2 特定の item でも最新の item もないけどなんか法則性ありますね。うーん?


2008-10-16 [長年日記]

_ Yapra で Trac の timeline feed を 1本に

本当は Yapra でやりたかったことナンバーワンだったはずなのに全然やってなかったイントラの Trac の timeline の一本化をやりました。(面倒くさがってただけでやり始めたら割とすぐできた。)

今回のキモはイントラの Trac の URL が

http://host/trac/NAME

の形で統一されているので、/ で split して NAME を引っぱり出すところかな? これで一本化された feed を読んでいてもどの Trac からの情報かが title だけで分かる。(まぁリンクを踏めば間違いなく分かるんだけど。)

- module: RSS::load
  config: 
    url: 
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
      - http://host/trac/NAME/timeline?VARIOUS_OPTIONS&format=rss
- module: Filter::sort
  config:
    method: date
- module: Filter::ApplyTemplate
  config: 
    title: '<%= "[#{item.link.split( /\// )[4]}] #{item.title}" %>'
- module: RSS::save
  config:
    title: "multitrack"
    link: http://HOST/PATH
    filename: /PATH/TO/FEED

実際の Trac の URL とか保存先のファイル名とかよしなにしてください。

本当は My Tickets の一本化もやりたいんだけど、なんかあまりうまい方法が思いつかないんだなぁ。ユーザーごとに feed を作るようにするしかないかな? 人数少ないうちなら全然それでも問題ないんだよな。

あーあと本当に今いちばん欲しいのは Roadmap の iCal データを merge して出してくれるものだな。あったらすっげー便利だと思う。

trac の情報を引き出す plugin にしちゃった方が応用はやりやすいんだろうなぁ。

Tags: Yapra Ruby

2008-10-17 [長年日記]

_ git の pull request は fork 前提って理解で合ってますか

なんか github の pull-request の説明はすでに fork -> commit -> push 済みなのを前提に説明されているようで、他の方法がよく分からなかったのだけど、考えたら pull request ってのは「ここの repository にあるこの commit をそっちにも merge してくんねーか?」という意味だと思えば fork が公開されてなきゃ意味ないんですよね。

まだ github のサイト上でしかやったことがないけど、git-request-pull でも同じこと、、、なのかな。なんか man 見てもドキュメント読んでもこの辺の記述が見つけられないんだよなぁ。まぁ github 以外では git 使って分散管理する必要ないからこっちは困ってないんだけど。

Tags: Git

_ Trac の feed を merge する Yapra の YAML を ERB で作る

タイトルなげぇ。

昨日 Yapra で Trac の timeline feed を 1本に を書いてから、Plagger の assets みたいな仕組みがあればベタに書かなくて済むのかなーとか思ってはいたんだけど、うまい方法も思いつかないので今日とりあえず ERB を使って一つのテンプレートから生成するようにしてみた。

想定しているパターン

  • 複数の Trac を運用しているがチェックが面倒なので Timeline の feed を一本化したい
  • それぞれの Trac に対してユーザーが複数いるので、各自の横断的な My Tickets の feed を生成したい

場合に役に立つ Yapra 用 YAML を作ります。そのために ERB を利用します。

基本構成

スクリプトと、それを動かしてできた結果のファイルがこんな風に一つのディレクトリに収まる形を想定しています。

.
|-- jane_tickets.yaml        My Tickets 用の YAML
|-- john_tickets.yaml        My Tickets 用の YAML
|-- merge_trac_timeline.erb  timeline 用の YAML のテンプレート
|-- merge_trac_timeline.yaml timeline 用の YAML
|-- prepare.rb               スクリプト
|-- smith_tickets.yaml       My Tickets 用の YAML
`-- user_tickets.erb         各 user の My Tickets 用の YAML のテンプレート

で、yapra からは

ruby YAPRA_PATH/bin/yapra -d /PATH/TO/ABOVE

という具合にファイルを置いたディレクトリを指定してやると

*.yml
*.yaml

以外は無視して動作してくれます。

スクリプト

users, sites などを適宜調整してください。

#! /usr/bin/ruby

require 'erb'
require 'optparse'

class TracMergePreparer
  class FileCannotOpen < Exception; end

  def initialize
    @path = nil
    @name = nil
  end

  def run
    if ( parse_args() )
      erb = ERB.new( File.read( @path ), nil, '-' )
      if ( @name == 'user_tickets' )
        users.each do |user|
          File.open( "#{user}_tickets.yaml", 'w' ) do |f|
            f.write( erb.result( binding ) )
          end
        end
      else
        erb.run( binding )
      end
    end
  end

  def parse_args
    ret = false

    opt = OptionParser.new()
    opt.on( '-f', '--format ERB_NAME' ) { |file|
      path = File.join( File.dirname( __FILE__ ), file )
      if ( File.exist?( path ) ) 
        @path = path
        @name = File.basename( file, '.erb' )
        ret   = true
      else
        raise FileCannotOpen
      end
    }
    opt.parse!

    return ret
  end

  def users
    return %w(
               john
               smith
               jane
              )
  end

  def sites 
    return %w(
               foo
               bar
               baz
             )
  end
end # of class

if ( __FILE__ == $0 )
  app = TracMergePreparer.new()
  app.run()
end

timeline merge 用の YAML を作る

erb はこんな感じ。

<%-
# Usage: ruby prepare.rb -f merge_trac_timeline.erb > merge_trac_timeline.yaml
-%>
- module: RSS::load
  config: 
    url: 
      <%- sites.each do |site| -%>
      - http://HOST/PATH/<%= site %>/timeline?changeset=on&milestone=on&ticket=on&wiki=on&max=50&daysback=90&format=rss
      <%- end -%>
- module: Filter::sort
  config:
    method: date
- module: reverse
- module: Filter::ApplyTemplate
  config: 
    title: '<%%= "[#{item.link.split( /\// )[4]}] #{item.title}" %>'
    description: <%%= item.description.gsub( /<[^>]+>/, '' ) %>
    content_encoded: <%= item.description %>
- module: RSS::save
  config:
    title: "multitrack"
    link: http://HOST/PATH/TO/FEED
    filename: /PATH/TO/FEED

Trac を設置している HOSTNAME や PATH、あと item.link から title に Trac の名前を埋めている部分も PATH の深さによって変わるので注意してください。それぞれ適宜修正のこと。

使い方は上の例で言うと

ruby prepare.rb -f merge_trac_timeline.erb > merge_trac_timeline.yaml

として使う形を考えています。

各ユーザーの My Tickets 用の YAML を作る

<%-
# Usage: ruby prepare.rb -f user_tickets.erb
-%>
- module: RSS::load
  config: 
    url: 
      <%- sites.each do |site| -%>
      - http://HOST/PATH/<%= site %>/report/7?format=rss&USER=<%= user %>
      <%- end -%>
- module: Filter::sort
  config:
    method: date
- module: reverse
- module: Filter::ApplyTemplate
  config: 
    title: '<%%= "[#{item.link.split( /\// )[4]}] #{item.title}" %>'
    description: <%%= item.description.gsub( /<[^>]+>/, '' ) %>
    content_encoded: <%= item.description %>
- module: RSS::save
  config:
    title: "<%= user %>'s tickets"
    link: http://HOST/PATH/<%= user %>_tickets.xml
    filename: /PATH/TO/<%= user %>_tickets.xml

これも必要に応じて修正してください。使い方は

ruby prepare.rb -f user_tickets.erb

を想定しています。この名前はスクリプトの中で決め打っちゃってます。実行すると users に登録してある user の分だけ

#{user}_tickets.yaml

を生成します。

制限

それぞれの Trac に登録されているユーザーが同じでない場合は考えていません。feed が fetch できないとエラーで止まるかも。

また description 内で HTML タグらしき形のものを片っ端から除去しています。読めば分かるように副作用がありますので、注意して使うか、不要ならこの処理は捨てちゃってください。

Tags: Yapra Ruby

2008-10-20 [長年日記]

_ 超自分用 Mozilla extension メモ

たまに振り返っておく。というか今サラの環境を作っているのでメモ。

Firefox add-ons

Thunderbird add-ons

いつの間にか多くなってしまったなぁ。

_ Ubuntu へ避難

twitter のログを使って過去の日記を書く術。

PowerBook G4 の調子が尋常じゃなく悪い。起動に10分以上とか平気で掛かるし、作業中もときどきジッと固まって何もできなくなる。しばらくすると帰ってくるんだけど、これはなんか昔ディスクが逝ってスローダウンした状況によく似ている。日に日に遅くなっていくのが分かる。

これは危険ということで、まだなんとか動くうちにとりあえず Ubuntu 8.04 を仕込んでおいた空き PC にお引っ越し。スペックは聞くと泣けるので聞いちゃダメ。

基本的には Mac と言っても Un*x 的に使っていたので、なくなって困るのは OmniGraffle くらい。あとは Firefox も Thunderbird もあるし、Emacs をはじめ terminal の環境は恐らく Mac よりも便利なものを素早く入れられるはず。*1Mozilla アプリは Profile 丸ごと持ってくればたいていのものはそのまま動くし、ダメな extension でも入れ直せば動いたりする。環境設定はいじり直す必要あったりするけど。主に外部のツールやファイルを利用するもののパスの設定ね。あ、今回は Firefox 2 を 3 に上げるのでそこは新規に作り直すことにした。せっかくなので。今ごろかって? そうさ、OSX 10.3 は Fx 2 までしか動かないんだよ。

というわけで Ubuntu の方は ctrl <-> caps lock の設定をすればまずは普通に使える。cmd を ctrl に置き換えてしまえばとりあえずたいていの作業は支障なく行える。あとは最近教えてもらった

Twitter / はぎー: @wtnabe ブラウザのタブ切り替えはCtrl + ...

タブ切り替えが炸裂すれば完璧だぜ!と思ったけど

Mac Gnome
terminalでコピペ cmd + c/x/v shift + ctrl + c/x/v
terminalのタブ作成 shift + ctrl + t

こんな感じで、一部のショートカットキーが予想に反していた。gnome-terminal だけ shift が必要なのね。ちょっと気付かなかった。*2

あとはおいおい。

データのお引っ越しは rsync だけでなんとかなるかと思ったけど、日本語のファイル名もあるのでおとなしく samba を経由させた。さすがに遅いけど、あとで泣く可能性を考えるとじっと我慢の良い子なのであった。

Tags: Debian Linux

*1 Mac では便利なものはたいていコンパイルして入れているけど、Ubuntu なら自分の使っているものはバイナリがまず間違いなくある。

*2 OSX の Terminal は 10.3 ではタブはないのですT_T


2008-10-21 [長年日記]

_ PLUTO読み始める

PLUTO (1)(浦沢 直樹/手塚 治虫/手塚 真)

うーん。失敗だったかなぁ。

気になってしかたがない。この人の序盤のストーリーテリングのうまさにはどうしても敵わないな。途中からオチにかけてはなんか満足感がイマイチなこともままあるけど。*1

というか連載追っかけ作品は増やしちゃダメだって。

_ Gnome の環境を Mac に合わせるのを諦めた

Ubuntu に引っ越したけど、細かいところで Mac のクセをそのまま活かせたらと思い、以下の設定をした。

  • alt + space で SCIM on/off
    • しかしアプリによってはこれでメニューが開いてしまうので、とりあえずかなりの時間使うであろう gnome-terminal は設定でこの動作をオフに
  • gnome-termial はショートカットキーを覚えて設定が終わればメニューは不要なので非表示に
    • 行数確保

他に

  • option*2 を meta として使う

のはやりたかったんだけど、どうしても gnome-terminal でうまくいかなかったので諦めた。そのとき以下のことを教わった。

Twitter / Takeru Naito: @wtnabe [Win] は通常 [Super] ...

ls のオプションはこんな感じ。

Twitter / wtnabe: BSD系の ls -wAFG は GNU では ls ...

ちゃんと環境読み取って if else で alias 定義すればいいんだろうけど、いつも面倒でそのまま書き換えちゃうな。良くない、良くないよ。


最後に、ハマったのはこれ。

Ubuntu日本語フォーラム / Emacs にてAlt+<, Alt+>が効かない

かなりハマった。キーボードのレイアウトがいきなり変わる意味分からなす。

Tags: Linux

*1 MONSTERとか21世紀少年とかはそのクチで、終盤、個人的には惰性で読んだ感が残った。

*2 Realforce上では左Winに割り当てていた


2008-10-22 [長年日記]

_ Ubuntu でそこら中 Emacs 風に

MacOSX の自分にとってよいところはいたるところで Emacs 風の編集が有効なこと。で、当然 GNOME でもできると思ったけど、標準ではできないっぽい。

gconf-editor

図のようなこんな感じで gconf-editor から /desktop/gnome/interface/gtk_key_theme を emacs にすると良い。

Tags: Linux

_ IP messenger に四苦八苦

昨日から IP messenger を使おうとして四苦八苦している。IP messenger については実は興味はあったが試したことのなかったアプリがあって、それが

今までプロトコルと UI を分離してる実装はお目にかかったことがなかったのでこれは面白そうだと思ったわけ。

IP messenger は基本的に Windows アプリで、それ以外のプラットフォームにも様々な移植版が存在する。本家 Windows 版を使っている分には LAN 内での軽めのメッセージのやりとりに非常に重宝するのだが、他のプラットフォームではやはりクライアントの完成度が落ちてしまう問題があった。

Un*x には上に挙げた kipmsg の他にも X 版、GNOME 版がある。でもさすがに古すぎる。Java 版があるのも知っていたがここは最も新しいものを試したい。結果、

早すぎたんだ

最初 deb 用のファイルリストが用意されていることに気付かずに GNOME で動かしている Ubuntu 上で必死に KDE の環境をインストールしていたがあえなくコンパイルできず泣きそうになった。が、実はまったくそんな苦労は必要なかった。しかし、ちょっと使ってみたらウィンドウのちらつきが気になったり、問答無用で refresh が走ってユーザーを選択できないとか、refresh が走るたびにメンバーリストのカラムの幅がリセットされるとか、終わりのない我慢大会だったのでこれは諦めた。

最後に見つけたのがペタクローン。これはいい。Java なので最初の起動は重たいが、起きてしまえば結構快適に動く。タスクトレイ的な場所のアイコンの他にどうしてもウィンドウが存在してしまうのがうざいが、それを我慢させてしまう強力な機能がある。

メンバーのインクリメンタルサーチ

もう一度言う。これはいい。本家 ML でもメンバーの検索したいですと言ったことはあるんだけど、検討されている様子はまったくなかった。でも IP messenger のインターフェイスなら検索は必須だと思うんだよな。irc みたいに nick 補完でメッセージ投げるわけにいかないんだから。

ただ最初戸惑ったのが、メンバーリストはメッセージを作成してから [ 送信 ] というアクションを起こさないと出てこないこと。IP messenger と互換クライアントをいくつか試してきたなかで、このタイプは初めてだった。これまでの記憶ではみんな送信ウィンドウでメッセージの作成とユーザーの選択を同時に行えたはず。

で、まぁ検索の仕組みまで入るとゴチャゴチャしちゃうからかなぁと思ったけど、この方式には実は致命的な問題もある。

メッセージを投げようとするまで相手がクライアントを立ち上げているかどうか確認できない

メンバーリストを最初から見ることができればメッセージを作成してしまう前に相手の存在を確認できる。しかし現在のペタクローン方式だとどうしても先にメッセージを作成する流れになるので空振りになる危険性がある。そこだけもったいないなと思う。メンバーリストを任意のタイミングで自由に確認できるようになったらいいな。

Tags: Linux

2008-10-23 [長年日記]

_ 英辞郎を Linux デスクトップで

Windows では PDIC で、MacOSX では英辞郎ビューアでお世話になっている英辞郎。

伝統的には Un*x で辞書っつったら EPWING 形式なんじゃねーかなぁと思うんだけど、以前一度だけ FreeBSD 上で英辞郎を EPWING で利用できるように変換しようとして挫折した思い出があって、もしかしたらついに英辞郎を諦めなきゃダメかもなぁと考えていた。でも EPWING にこだわらなければ方法はあった。

の二つ。rdic は Ruby で書かれていて、おぉと思ったけど Ubuntu パッケージになっていなかったので今回は sdic の方を使うことにした。Emacs ユーザーじゃなきゃわざわざ辞書のために Emacs を立ち上げようとは思わないけどね。

インストールは他のアプリと同様 aptitude でできるんだけど、このときいきなり CD-ROM 上に英辞郎の辞書があることを前提に、sdic で利用する suffix array の構築に取りかかろうとする。辞書の取り込み用の UI はないのかな?と思ったけど、まぁ取り込もうとしているパスは分かるので、そのディレクトリを作ってご所望通りに辞書データを置いてから aptitude を叩いてインストールした。

機械が遅くて suffix array の構築にものすごく時間が掛かったけど、実際に辞書を引く動作自体は比較的軽い。これでかなり快適になった。やっぱインターネット越しにしか辞書がないなんて考えられない。もっと速く引けないと。

Tags: Emacs Linux

_ Wedata のお勉強

以前から名前だけは知っていたけれどイマイチ実体のつかめないというか、イメージをつかめないでいた Wedata について調べてみた。

結論から言うと下のリンク先を読め。以上。

さすがにあんまりなので自分の言葉で簡単にまとめ直すと、

  • データベースとアイテムという単位があり、これは一般的な RDBMS で言うところのテーブルとレコード(名前がついている)のようなものに相当する
  • 読むのは自由、書くには OpenID での認証が必要
  • アイテムに key と value の組み合わせからなるデータを保存できる。ここは DBM 風。
  • ブラウザからも API からもこれらを CRUD できる

で、このアイテムの key と value の組み合わせに自分なりのルールを作って API から叩くと、Web 上にデータベースがあるように使えるというもの。それが Wedata、のはず。

ただデータベースと書くのは語弊があって、API からは内容で検索とかはできない。あくまでデータベースの一覧やアイテムの一覧が取得できるだけ。Web 上ではデータベースの description で検索したりアイテムの名前で検索とかできるけど、これも API ではできないんじゃないかなぁ。やってみてないけど。で、検索なんかは結局ローカルというかクライアント側で実装する必要がある。

Wedata はもともと AutoPagerize という Firefox extension で利用する情報を Web 上に保存する目的で Wiki の代わりに作られている。Wiki には基本的に Wiki 記法以外に構造を表す手段がなく、この構造も文書に特化している。自分も Wiki は好きで比較的なんでも Wiki にすればいいじゃんと思ってしまうが Wiki は Wiki で不便だよなぁとも思っていた。それがこの構造の部分。Wedata はそこをうまいこと DBM 風にして解決しようとする試みなのだな、きっと。

Tags: Web DBMS

2008-10-24 [長年日記]

_ MacOSX の open を GNOME で

もうそのまんま gnome-open だった。

Twitter / UI: alias open='gnome-open' はあ ...

ただ alias って Emacs の Dired では解釈されないらしく、どうしても標準で入ってる open*1 の方が立ち上がっちゃって悲しい。

ちなみに OSX と同じく標準状態で PDF が手軽に作成できてるのは嬉しいんだけど、~/PDF/ に入るのはなんかもうちょっと分かりやすく GUI から設定できてもいいんじゃないかと思った。

Twitter / Takeru Naito: @wtnabe /etc/cups/cups-pdf ...

Tags: Linux

_ git で svn status のようなもの

git ls-files にいろいろオプションがある。

-m(--modified)
修正されているファイル。svn では M と出てくるやつ。
-o(--others)
管理対象外のファイル。svn では ? と出てくるやつ。--directory を付けると、丸ごと others なディレクトリは DIRECTORY/ までの表示になる。必要以上に出てこないのでうざくない。こっちがデフォルトの方が親切なような気もする。
-t
管理されているファイルの status が取れる。これこそが本当に svn status 相当。のはずなんだけど、見てる情報が違うらしく、上の二つの情報を合わせたものにはなぜかならない。どーもこの辺、git のマニュアルが不備なのか自分の理解が足りないのかよく分からんのだよな。

あと svn info 相当の情報も取り方がよく分からない。git remote -v でずいぶんあっさりした情報は取れるんだけどねぇ。

Tags: Git

*1 全然ベツモノ


2008-10-25 [長年日記]

_ Yapra に Publish::Smtp 追加

最近 github で喜んで fork して作業してます。

Pragger についてこんな記事がありましたが、

Praggerとnetpbmで作る画像→AA変換ツール − @IT

Yapra には

  • Publish::Imap
  • Publish::Smtp

揃ってますよ! すぐにメール送信できますよ!

使い方は

- module: Publish::Imap
  config:
    imap_server: XXXX
    username: YYYY
    password: ZZZZ
    mail:
      subject_prefix:  
      from_template: 
      to: 

- module: Publish::Smtp
  config:
    smtp_server: XXXX
    username: YYYY
    password: ZZZZ
(ry

のように設定を書きます。

Publish::Smtp の方は Net::POP, Net::SMTP で使える認証方法に対応しています。Publish::Imap に倣って設定を行うと SMTP-Auth でメールを送信します。また pop_server を書き足して

- module: Publish::Smtp
  config:
    smtp_server: XXXX
    pop_server: AAAA
    username: YYYY
    password: ZZZZ

と書くと POP before SMTP で認証できますし、ここに

    authtype: apop

を足すと APOP で認証できます。

- module: Publish::Smtp
  config:
    smtp_server: XXXX

のように認証情報を一切省略すれば無認証で SMTP で送信できます。

便利に使ってやってください。

yuanying's yapra at master ― GitHub

まだこれを書いてる時点ではリリースには入ってないので git clone してね。

Tags: Yapra Ruby Mail

2008-10-26 [長年日記]

_ revert, reset, rebase, ...

例によって自分用のメモ。間違ってる場合はツッコんでください。

「svn revert」は「working copy の変更をなかったことに」してやり直すために使う。update でコリジョンが起きた場合にこれを使うと問題なく repository の状態に追随できる場合が多い。

「git revert」はコミットそのものをなかったことにする。はずだったような気がしてたんだけど、「コミットそのものをなかったことにするコミットを行う」。言い換えると revert しましたという記録を残す。

git で svn revert 相当のことをやりたい場合は

  • git checkout
  • git reset

のどっちかでいいような気がする。こんな感じに使う。

git checkout BRANCH
git reset COMMIT

git reset の動作は3種類。

--mixed
working tree には触れずに index の commit をなかったことにする。デフォルトの動作。
--soft
index も working tree もまったくタッチしないって言ってるような気がするんだけど、自分が試したら見事に修正分がぶっ飛んだ。意味が分からん。怖くて使えん。
--hard
こっちが本当は自分の作業を全部ぶっ飛ばしてしまう動作のはず。

あちこちでいろんな人が言ってるけど git ってほんとよく分からん。根本的な考え方が他のツールと合ってない部分が多く、使う言葉が違うので当てずっぽで作業すると痛い目にあう。もちろん互換性を捨てたおかげで良くなっている点もあるんだろうけど、移行するにはハードルが結構高い気がする。

ということで最近では凝ったことする前に Mercurial にも突っ込んで意図しない動作をしても元に戻せるようにして作業している。git は便利だがなんか怖い。

ただ、Emacs の vc-mode で vc-revert-buffer すると svn だろうと git だろうと同じように扱える。一回に一つのファイルしか revert できないけど、すでに Emacs と vc-mode を使えている人はこれ使うのがいちばん確実だと思う。vc-mode がいつから git に対応しているのか細かことは知らないけど、たぶん 21 は NG で 22 は OK だと思う。

rebase はなんかよく分からなかった。名前がちょっと似ているだけでまったく別な機能らしい。

Tags: Git

2008-10-28 [長年日記]

_ gnome-terminal って賢いな

中で less とか Emacs を開いている状態で PageUp, PageDown を押すとそのアプリの中がスクロールする。Mac の Terminal.app ではそんなことできないんだよね。これは地味に便利だなぁ。

Tags: Linux
本日のツッコミ(全2件) [ツッコミを入れる]

_  [kterm でも rxvt でも同じ動作になります! > less + UpAllow & DownAllow ..]

_ wtnabe [なるほどと思って調べてみたら Terminal.app では shift を押しながら PageUp, PageDo..]


2008-10-30 [長年日記]

_ evolution でカレンダーの共有

Mac では Thunderbird + Lightning + WebDAV でカレンダーを共有していたんだけど、Linux にきたら動かなくなってしまった*1。そこで evolution を試してみているんだけど、

どうも evolution は WebDAV でリモートのカレンダーを直接読み書きできない

みたい。読むのは読めるけど書くのはローカルに書いて、それを [ アクション ] → [ カレンダー情報を公開する ] という流れで作業する必要がある。ちょっと面倒くさい。それか予定一つ一つ (コピー or カット) and ペーストする。直接書けないのにペーストできるってのがイマイチよく分からない。

でもこの仕様になっているおかげで、自分のカレンダーにとりあえず書いて他人のカレンダーにカット&ペーストでイベントをアサインできるのは便利。間違ってイベントを削除することができないのは安心。

Tags: iCal

*1 恐らく Lightning はプラットフォームに依存している部分があったので再インストールする必要があった