2003-06-11
_ うがー行きたい
http://slashdot.jp/article.pl?sid=03/06/10/1820238
Perl, PHP, Python, Ruby 合同の Lightweight Language Saturday. 無理だなぁ。行きたいなぁ。あーあーあー。
_ 検索窓つけてみました
自分でも不便だなと感じていたので上の方に検索窓つけてみました。これでいちいち検索ページに移動しなくてもサクっと検索できるので少しは使い勝手よくなった感じ。
_ 続・HTML メール
http://slashdot.jp/article.pl?sid=03/06/10/091252
たかをくくっていたこの話題、案外広まっているようで。で、推進派は
- ユーザーに受け入れられていて
- 視覚に訴えるので販促効果もある
ちゅーことにしたいようですが、少なくともユーザーに受け入れられているという評価はどうかなと思いますね。大半の人は
- 受け入れるも受け入れないも、何がなんだか分かっていない
- アクションを起こす（抗議メールを送る、メールソフトの設定を変更する）のが面倒で流されている
のが現実でしょ。まぁ、言ってしまえば政治なんかの置かれている状況と同じように見えるわけですが。。。
あとは「効果なんかないよ」ということが言えればいいんですけど、なかなかこれは難しいかなぁ。たぶんユーザーに飽きられるまではある程度効果は上がると思ので。
ところで HTML メールが（正しくは解釈したメールソフトが）余計な通信をする危険性は言うに及ばずですが、それより、メールのサイズが不必要にでかくなるのは勘弁してほしいです。みんなメールボックス膨れ上がってないの？ え、数百MBあっても平気？ みんなそんなに安定したメールソフトや OS 使ってるの？
嘘おっしゃい。
2004-06-11
_ mapae 動かず
FreeBSD の Perl が古すぎたか？
- CPAN モジュールのインストールは cygwin ではうまくいかない。
- FreeBSD ではモジュールのインストールはできた
- しかし肝心の mapae はやはり動かず
_ CPAN ミラー
- jaist はダメか？
- → 違った。なんか cygwin の lynx で -source つけて get するのが全然うまくいってなかった模様。ncftpget で ok っぽい。まーでもやっぱかなり不調な感じはするけど。なんでやろ。
cygwin の遅さと回線の質を差し引いてもやっぱ jaist はダメっぽい。FTP がダメなんかも。でも CPAN モジュールの FTP を passive にする設定があるんかどうかも分からんしな。
CPAN ミラーは http で取得させてくれるところを選ぼうってことやな。
_ CPAN の設定
保存場所
| FreeBSD 4.x | /usr/libdata/perl/5.00503/CPAN/Config.pm |
| cygwin 1.5.x | /lib/perl5/5.8.x/CPAN/Config.pm |
FreeBSD で CPAN の設定をしてたらなんか Perl 5.8.4 をビルドする準備が進んでいるような。。。
_ Miech でゴー
あれこれ試したが結局現状の完成度は Miech が高そうなので、ある blog の編集はこれでイクことにした。うん、便利だな。
_ Unison の運用考察 → 断念
Unison をすでによく使っている方の日記。誰かと思えば Wikicker の作者。
こちらの予想とは裏腹に、Zebedee では補えない問題がいくつかあることが判明。
- サーバ側でミラーリング対象のディレクトリを制限できない
- これはプロファイルをうまく書けばできそうな気がするので追試
- unison 単体では一切の認証不可
- rsyncd は単体で一応認証可能
- Zebedee を使おうにもまず fw で unison の素のポートを閉じる必要があるが、そういう fw が Windows には標準で用意されていない。
てことですな。とりあえず認証は置いておくとして、プロファイルでサーバ側のディレクトリをどうにか制限できないか、実験してみよう。
と思ったが、
Unison はバックアップ目的には使えない
ことが判明。それは
「シンクロ中にファイルの変更を検知すると止まってしまう」
という設計。これだとちょっとバックアップ目的で裏で動かすためには使えない。Windows 同士の、SMB より速いミラー方法が見つかったと思ったんだけど、ダメでした。
_ Free-ATX セレクション
http://www3.soldam.co.jp/free_atx/live/
キューブ型でもベアボーンじゃないケース群のうちの一つ、Live1000.
これ + マザーで4万くらいか。HDD 2基搭載できて、静音性、冷却性もよいとなるとやっぱ惹かれるものがあるな。
2006-06-11
_ 田舎に泊まろう 石川県宝達志水町
すっげ。今まで見たことないくらいに断られてるわ。やっぱ北陸は閉鎖的なんだなって感じですなぁ、こりゃ。
まぁこの企画はそもそも女性には向いていないと思うけどねぇ。それにしたってこれはすげぇ。偉人て言ったのに、モーゼの墓なんつーオチがくるのも普通は予想できないって。
_ epeg はちょっとクオリティ低いな
いやなブログ: Epeg で JPEG ファイルのサムネイルを高速に生成する
は以前から気にはなっていたんだけど、今回実際に FreeBSD に入れて、自宅サーバに入れている Singapore がもっと早くならないか試してみた。
epeg は C のライブラリで、PHP のバインディングは存在しない。しかし epeg コマンドが存在するので もともと外部コマンドを呼び出してサムネイルを作っていた Singapore では利用しやすかった。*1
やることは thumb.php の中で $imagetype が 2 のときに imagemagick の convert コマンドではなく epeg コマンドを呼び出すようにするだけ。
はえぇぇ。
超はえぇぇ。
正直、C3 1GHz のサーバの性能そのものに限界を感じていたんだけど、まだまだ十分いけんじゃんと思わせるに十分な速度だ。
……。
あれ？
なんか画像が汚いなぁ。
あー。
分かった。本当にサムネイル向けなんだ、これ。ここで自分の環境を整理してみる。
- 手元の Singapore では 40*40, 120*120, 160*160, 700*600 の各サイズの画像を生成している
- 700*600 は閲覧用。それ以外はナビゲーション用。
- 汚いと感じたのは 700*600
要するに、epeg の縮小画像の生成はすごい速いけど、よく見るとアラが目につくレベルなわけだ。仕方がないので、700*600 の縮小画像を生成するときは epeg ではなく、従来通り ImageMagick を使うように設定した。
ちなみにリンク先の記事では ImageMagick に size オプションをつけるとかなり性能が向上するように書かれているが、手元の環境では size オプションをつけても思ったようには速くならなかった*2。少なくともその状態でも epeg とは圧倒的な差があった。
そうすっとあれだな。ユーザーのアクションに追随しなければいけないような速度を要求されるサムネイルの作成（例えばアップロード済み写真の確認とか）には epeg を、くり返して「観る」ための画像の作成には ImageMagick をバックグラウンドで、と使い分けると気持ちいいアプリになるのかもしんない。
2007-06-11
_ Frenzy is temporarily suspended
うぉっつ。
しかしそこでじゃあオレ手伝うよ、と言えるほどモノが分かっていないのが悲しいところ。あんまりじっくりと OS の勉強できる状態でもねーしなぁ。にんともかんとも。（Debian Live だの浮気してる場合じゃないか？）
分かっている人は FreeSBIE でオリジナル Live CD をガンガン作って活用してるから Frenzy が遅れても困ってないのかしら？
_ 学校向けにPCリサイクルができるのか
スラッシュドット ジャパン | 「学校向けWindows 98/Meインフォメーションセンター」でセキュリティ関連情報を提供
から
スクール OS 無償プログラムは、学校に寄贈された PC が Microsoft Windows ( R ) OS のライセンスを持たない場合、あるいはライセンス所有の有無が不明確な場合に、無償で正規ライセンスを提供するプログラムです。
これは知らなかった。
けどあれか。自宅サーバで無料 OS 使ってた機械の場合はダメなのね。アレゲ人のお下がりに期待するのは結構難しそうだな*1。それに管理する側からすると全然違う機械がたくさんあっても困っちゃうよなぁ。中の人（教員）もそうだし、外の人（請け負う業者）も困る。あんまりいいことないよな。全部ネットワークブートでまかなえるようになるとか言うんなら話は別かもしれないけど。
学校向けの機械の難しさって、ストーリー中のコメントにもあるけど、周辺機器の複雑さなんだよな。しかもアプリの市場もそんなに儲かるわけではないので、異常に古いプラットフォームを前提にしているケースがままある。そして後継バージョンはないという状況。一般のオフィスワークからはかけ離れた、結構ヘビーな使い方してるんだよなー。JUST SYSTEM のアプリさえ動けばいいってもんじゃーない。
ドライバの問題やアプリの問題を解決しないと Un*x へ移行して経費削減、なんてのはかなり難しいだろうな。Edubuntu とか使ったことないけど、どういう工夫してるんだろ？ そしてそれは日本にもマッチするのかな？
*1 自分のもアウト
2008-06-11
_ Pragger 続き
どうもこれまずい気がしてきた。
- 現在(Rev 100)の構造では plugin の中で依存している plugin を動的に読み込むことができない
- したがって先に YAML をパースして、利用する plugin だけ読み込んで動作を軽くすることはできない
- つまり今後も重くなる一方
うーん。ちらちら plagger も読んでるんだけど、こっちはやっぱきれいにできてんだよなぁ。もったいない。せっかく pragger は依存モジュール地獄に落ちずに済んだのに。
あ。Plugin クラスの load_plugins() をバラせばいいのかな？
def load_plugins()
ファイルをリストアップしてぐるぐる do |file|
register( file )
end
end
def register( file )
$plugins[ごにょ] = Plugin.new( file )
end
みたいな感じか？ あ、register で与える file はフルパスじゃなくて plugin ディレクトリ以下じゃないと不便だね。
またドキュメントのためにコードを丸ごと文字列で持つのは RD とか RDoc をうまく使えば避けられるんじゃないかと思ったけど、よく分かんないorz Perl なら Pod 関係のパッケージですぐできるんだけど、Ruby ではやり方が分からない。いやビックリ。まさかオレ Perl の方が得意なんじゃね？ まぁ全部文字列で持つとしても、少なくとも個々の plugin を選択的に読み込む機能がつけばだいぶ違うような気がする。うむうむ。やっぱまずそこか？
