2004-01-27
_ OOo の書き出した PDF は
Illustrator 9 で読み取れまへんでした。形式が不正とな。Acrobat で pdf, eps, ps にそれぞれ変換してみたけど、どれもフォント周りがダメ。どうも OOo の吐き出す PDF でフォントが埋め込みサブセットになっちゃうのがまずいんじゃないかと思ってみたり。
Adobe アプリのバージョンを上げないと最近のこの手のやつをチェックする意味ないかもなぁ。
PDF はともかく、wmf の扱いは問題ないのでインスピ → OOo はよいですな。インスピ → Illustrator より精度は荒いけど作業は減るので用途に応じて使い分けですな。
_ すっかり Perl 忘れてきたぞ、最近
いいんだか悪いんだか。
_ @nifty が20円安くなるそうな
ADSL 接続料が 400円安くなってモデムレンタル料が一律 IP 電話機能つきのものに合わせられて 380円の値上がり。しめて 20円/月の値下げ。 なんやそれ。
2005-01-27
_ diff の RSS が抱えてるっぽい問題と自分のスタンス
辺りを読んで、現在 RSS 1.0 で最新の diff だけを配信している rssdiff.inc.php はちとまずいなぁという思いが少し強くなった。（以前から使いにくさは感じている。）
RDF 的な意味のおかしさ
RSS 1.0 は RDF の縛りを受ける。RSS1.0によるdiff配信に反対 を読むと「diff のページへリンクを張っている RSS」として提供する分には問題なさそう。diff の RSS なんだから別にいいじゃんと思っていたがかずひこ氏が Hiki の RSS 出力をマシにしよう計画 で
「content とか言っておきながら差分だけですか？」というのが気にならないでもないのですが、description のところに「わかりやすく」差分を見せるのも難しいような気がします。
となんか変だなと感じていたのも根っこはこの部分なんだな。きっと。
しかし逆に diff にリンク貼られてもあまり嬉しくないんだよなぁ。これは diff を pre で表示しちゃう PukiWiki の特性かもしれないけど。少しでも文章が長いととにかく横にスクロールさせなきゃならなくて見にくい。
RSS 2.0 だとこの辺の diff にリンクすべきという問題は解決できるんだろうか？ 解決できるなら RSS 2.0 という選択肢はがぜん現実味を帯びてくるな。
人間にも意味が分からなくなる可能性
これはおおいにありうる。自分のように細かく修正を保存しながら書いていくタイプの人間が使っている Wiki では diff があまりに断片的になりすぎて使いものにならなくなる可能性は高い。ただしこれには解決策とあまり問題にならないのではないかという2つの解答が自分の中にある
diff の基点を明示できるようにしたらどうか？
現在の Wiki のインターフェイスにこういうものは存在していないが、近いものは KakiWiki である。使ったことはないが、KakiWiki にはスナップショットを保存するという機能がある。これは実は自分の考える理想の Wiki に少し近い。自分の現在考える理想の Wiki は cvs commit のような明示的なアクションで snapshot を保存し、diff はそこからの差分を表示するという形のものである。commit を自動で毎回行い、権限の管理を行わないという方法もあるだろうし、commit の権限を core member に限定してしまうという方法もありだと思う。個人的には core member に限定して commit 時にちゃんと log を書くという方法の方が嬉しい。断っておくがここで編集の権限と commit の権限はベツモノである。あ、例えばこれを利用すれば特定のリビジョンにロールバックするのも簡単にできそうだ。
こうすると細かく保存しながらある程度まとまったところで commit、変更点を分かりやすく書くことで追跡を容易にするという芸当が可能だ。
「細かく保存しなければよい」という選択肢もあるが、指が無意識のうちに保存のための動作を行うようなタイプも居るのだ。細かく保存せずに長文を書くなんてちょっと昔の安定しない OS を使ったことのある人間や冬の北陸に住んだことのある人間*1には恐ろしくてとてもできない。これは Web アプリでも同じだ。
当然のことながら Wiki 上でコミュニケーションまでやってしまっているような使い方ではこういう方法は採用しにくいだろう。が、これはそもそもそういう使い方は Wiki としてどうなのか？という疑問の方が強いので考慮しないことにする。
あまり気にしなくてもよいか？
まず前提があって、自分は Wiki の RSS をすべて diff にするということは考えていない。RSS も目的別にあってしかるべきだと思う。だから diff についての RSS ですべてをまかなう気はないし、diff の RSS では一見については考える必要はないと思っている。diff の RSS を必要としているのはリピータである。しかも荒らしを見つけてくれるようなディープなリピータ（小人さんとも言う）である。どちらかというと core member。diff の RSS はそういうユーザーにフォーカスされていていいと思う。
もちろんフォーカスされていても時間が経てば diff だけ見ても何がなんだか分からないということはあるだろうけど、そういう場合は諦めて全文読み直してくれってことだ。RSS が万能である必要もないと思う。
しかしあれだなー。こういうネタのときは TrackBack 送れないのはもどかしいなぁ。やっぱ引っ越しますか。
*1 太平洋側だといつ夕立が降るか分からないような、そんなスリリングな状況を想像すると分かりやすいかもしれない。
_ オレオレ証明書クイズがらみ
を読んで、やっぱりこれが自分の使う言葉だなと感じた。高木さんの言葉は切れ味が鋭すぎて問題を理解させるための材料には使いにくい。
いや実際にこの結城さんの言葉を使ったのです。過去にね。で、そのサイトは今第三者認証を得た https をユーザーに提供しています。
そもそも SSL って何？ベリサインて何？という人に対しては
- 通信の暗号化
- 接続先サイトの真正性の証明
の2つをちゃんと分けて、なおかつこれは別の次元の問題だという説明をしなければいけない。しかし高木さんの書き方は「証明書がなきゃ意味ないじゃん」という前提（要するにセキュリティを考える人間にとっての常識）に頼っている部分があるので、前提を分かっていない人に対して何が問題なのか理解させにくい。
「設問がよくない」のは SSL という全体像を捉えて、正しい SSL を一発で解答したい場合に限って正しい指摘だが、設問がよくないかどうかも分からない人にとっては、片方だけではダメなことがはっきり分かる形にするために問題文もあえて分けてやった方がよい。
ただ結城さんの問題は (2) がいきなり高度かなという気もする。ここも YES/NO で答えられる形で「間違いなく自分の意図するサーバに接続しているかどうか」を問うた方がよかったように思う。そうしておくと SSL に限らず普段見ているサイトが果たして本物かどうかを考える契機にもできるから。
_ ちょっとダウン
今週頭から調子悪かったんだけど、どうも昨日からいよいよ風邪っぽい。知恵熱？とか思ったが、だったら鼻水ズルズルにはならないだろうから違うと思う。
気をつけているつもりだったんだがなぁ。うがい、手洗いをやっていても、もらっちゃうときはもらっちゃうんだな。
2009-01-27
_ Capistrano の :ssh_options と Net::SSH
また twitter の log から。
00:11:35 wtnabe< それ以前に :ssh_options の設定方法をミスっていたらし
い。:config => true を外してもそのまま認証できた。。。
00:11:43 wtnabe< 昼間のオレはバカすぎたということか。
00:12:18 wtnabe< オプションの与え方は set :ssh_options,
00:13:03 wtnabe< オプションの与え方は set :ssh_options, {} で、何がセッ
トできるかは net-ssh の ssh.rb を読むと書いてある。
lib/capistrano/ssh.rb
まず Capistrano の ssh 関係のファイルを読んで行くと以下のような記述が見つかる。
# If an :ssh_options key exists in +options+, it is passed to the Net::SSH
# constructor. Values in +options+ are then merged into it, and any
# connection information in +server+ is added last, so that +server+ info
# takes precedence over +options+, which takes precendence over ssh_options.
def self.connect(server, options={})
connection_strategy(server, options) do |host, user, connection_options|
connection = Net::SSH.start(host, user, connection_options)
Server.apply_to(connection, server)
end
end
ということで :ssh_options に設定するらしい。何が与えられるかというと、Net::SSH.start を読めばいいのかな。
lib/net/ssh.rb
def self.start(host, user, options={}, &block)
invalid_options = options.keys - VALID_OPTIONS
if invalid_options.any?
raise ArgumentError, "invalid option(s): #{invalid_options.join(', ')}"
end
この上の start メソッドのコメントにオプションというオプションがズラーっと書いてある。ここ読めば全部分かります。あまりの量で引用の範囲を明らかに超えそうなので控えてしまいました。
なるほどな。いやこの Net::SSH ってホントすごいな。
2011-01-27
_ 今さらab以外のテストツール調べた
ふと twitter 上に httperf という文字がよぎったので、はてなんだべと調べていたらこれが見つかった。
Programing Bible：Webの負荷テストに使えるフリーソフトウェア (1/2) - ITmedia エンタープライズ
で、感想としては
- 普段使いなら ab でいいかな
- より複雑で実際の環境に近いテストは Siege がよさげ
- Siege 入れられない環境とか ab 入ってない環境は httperf がよさげ
という感じかな。httperf は流行ってるらしいけど ab から積極的に乗り換えるほどでもないように見えた。もちろん Apache をインストールしていない環境の場合は話は変わってくると思うけど*1。
Siege
proxy で URL 収集ができる。収集した URL からランダムにマルチスレッドでリクエストを投げるので、より実際の環境に近いテストができる。らしい。
| パッケージ | 有無 |
| fink | NO |
| CentOS | YES |
| Debian | YES |
| MacPorts | YES |
httperf
| パッケージ | 有無 |
| fink | YES |
| CentOS | YES |
| Debian | YES |
| MacPorts | YES |
参考
上の記事は日本語訳は sf.jp が元記事で、さらにオリジナルは linux.com らしい。これだけリンクしとけば情報源としてどれかは生き残るだろう。
- Webの負荷テストに使えるフリーソフトウェア - SourceForge.JP Magazine : オープンソースの話題満載
- Linux.com :: Using free software for HTTP load testing
*1 Apache 1.3系が信用できないとかいう話になるとそれはもう残念ですねとしか言いようがない。