2003-05-12
_ 静電容量無接点方式のキーボード
http://www.topre.co.jp/products/electric/keybord/index.html
最近話題の静電容量無接点方式。何が違うのかと思ったらこういうことですか。何がいいってこの後半の図で描かれている荷重曲線ですね。これ！ これですよ！ これが自分の好きなキーボードのタイプです。しかも負荷が軽いときたもんだ。もうサイコー！ ThinkPad はこんな感じなのに、SpaceSaver はなんかどうもイマイチなのです。ところが東プレのコンパクトタイプはカーソルキーの配置が…。（トラックポイントはカスタマイズで付け足せそうな気がしないでもない。）
なかなか難しいもんですなぁ。
_ 「ブラインドタッチ」は誤りらしい
スラド経由http://homepage1.nifty.com/cura/oya/blind_and_touch.html
正直言うと自分はブラインドタッチという表現の方が好きでした。タッチタイプだと意味が分からないので。なんつーか「ぺたぺたキーをなでまわすようなタイピングのことか？」と感じるのです。これだとタイピングにおいてある程度以上のスキルがあるように聞こえないのですね。
ところが上の文を読んでいると最終的にはキーボードを見ずに打てるかどうかが重要ではない、てなことになってきてて、確かに自分も「ほとんど見ないけど、実際はちょっと見てる」状態なので、この理屈は実に自分に都合がいいのです。つまり、自分はブラインドタッチはできないけど、タッチタイプならできると言えるわけです(笑)
まぁそんなことはともかく、この最後の部分の burst typing これいいですね。まさに自分の考えていたこととドンピシャ。burst typing という表現はどうかと思うけど。
というわけで今後は言葉にはこだわらないようにしようと思います。
2004-05-12
_ sitecopy で mirroring ダウンロード
問題なくできることを確認。ただし一発では不可。
sitecopy -f サイト名 sitecopy -s サイト名
の二段構えの必要アリ。これは sitecopy の動作が
- 手元にあるファイルリストのリストを元にサーバ上のファイルとの比較を行なう
ためで、
- ファイルリストがローカルとリモートで食い違っていると -s オプションは十分に機能することができない
したがってまず
- -f オプションでリモートのファイルリストを取得しておく
のがカギ。
なお、この方法でちゃんとローカルのファイルは削除される。
いい感じ。これで Wiki や tDiary などサーバ上で直接更新するコンテンツの保全を行なうことができる。sitecopy が sftp に対応したらかなり最強な気がしてきた。（いつもこう思うきっかけがけっこう簡単だよな。）
※ もし local の準備が何もできていなくて、remote の階層が深い場合は何回も fetch する必要がある。少なくとも v0.16.6 ではそのような動きをする。これは LIST 取得したのち、local のディレクトリ作成の前にファイルの転送を試みて失敗するため。失敗後確認するとディレクトリの作成は行われているので、「何回か実行していると同期が終わる」という、少し残念な挙動をする。
_ ODBC, JDBC がだいぶ分かる
DBI ってなんだろう。DBD って？
言語直接バインディングはややこしくなくていいね。でも携帯端末情報DB みたいにあんまり依存したくない場合は ODBC とか使った方がいいんやろな。
_ とうがらし入り梅茶
最近ちょっとハマっているのだが、これはみやげもの売り場で買ったもの。日常的に手に入れるのはちょと難しい。ちと調べたら全国のみやげもの屋でパッケージをちょっとずつ変えたりして同じものが売られているらしい。ということは本家があるんだよな。そこはどこだ。
_ Dia 0.92 で日本語断念
1.0 は Gtk2 になるのかなぁ。とりあえず Gtk2 の sodipodi はインラインで入らないだけで日本語の取り回しにこれと言って問題は見られないので、さっさと Gtk2 に移行してくれるのが嬉しいんだが、まぁそれができないうちはまだインスピのお世話にならねばなるまい。
_ ついに asahi.com にレッシグ教授登場
「ＦＲＥＥ ＣＵＬＴＵＲＥ」を出版したローレンス・レッシグ教授に聞く （asahi.com）
やっとここまできたか、って感じ。一般メディアの代表中の代表である朝日新聞に、Web 版とは言え、「ネット文化と著作権」に関して様々な問題があることと、「半端な著作権保護の体制が文化をダメにする」という主張が正しく（自分が読んだ限りは正しく）書かれているのは素直に嬉しい。
_ 旧Lab コンテンツの発掘予定
- dl,dt,dd を使った table → making-web
- ドキュメントの訳 → trans（新設）
おしゃべり → bookmark へそれなりに済- XML → bookmark へそれなりに
- せっかく図描いたんだけどねぇ
未定のもの
- switch
- wtnabeのデスクトップ
- ときどきタイピングにハマる
- Winamp Output プラグインの設定 → /techmemo/ ?
- キーボード遍歴
2005-05-12
_ Wiki と tDiary テーマは合わないんじゃないか
tDiary テーマに対する不満
tDiary テーマはたくさんあって便利だけど、扱いにくいなぁと思うことがよくある。いちばん感じるのは短いページの場合、やたらと下に空白ができてかっこ悪いということだけど、それに次ぐのは「tDiary ではユーザーに対するナビゲーションと管理者向けのアクションに区別がない」という点である。これらはすべて adminmenu という HTML class の中に入ってしまう。しかし横一列*1にすべてのメニューが並んでいて、果たして使いやすいだろうか？
Wiki で tDiary テーマを採用するとメニューが窮屈では？
まぁ tDiary の場合は編集系のメニューはほとんどなく、全部 adminmenu 扱いでも別にいいかなと思う程度なのだけれど、これが Wiki になると話は別である。圧倒的多数の ROM に対して編集系のメニューを絶えず表示し続けるのはいかがなものか？ もちろんフラットに表示することで Wiki のオープンさを表明することはできると思う。メニューを分けないことで誰もがこのコンテンツを編集できるということを明示する効果はひょっとしたらあるかもしれない。しかし使いやすいとは言えないと思う。
例えば閲覧の利便性から言えば検索窓は常に分かりやすい場所にあってほしい。sidebar に plugin などで表示するのもアリっちゃアリだけど、そういうよく使いそうな機能こそ上にきててほしくない？ というか tDiary テーマ互換でないサイトの場合は右上の方に検索窓があるのは割とフツーなので、やっぱりその辺に配置したくなる。しかし Wiki の多彩なメニューをひとまとめに表示している場合は、検索窓はでかすぎて扱いにくい。だからかどうかは知らないけど、多くの Wiki では検索するために
- 検索のメニューをたどる
- 検索窓だけのページを表示してキーワードを入力する
という2アクションを要求する。個人的にはこれはとてもいやだ。
もちろん使い勝手はその Wiki の性格（コンテンツ）にもよるので一概には言えないかもしれない。ならばどれだけカスタマイズしやすいかということもまた重要なのではないだろうか。
tDiary テーマ互換とデザインのカスタマイズ
具体的なカスタマイズの話をすると、PukiWiki はあまり凝った作りをしていなので skin に該当する PHP のファイルを力任せにいじっていけばどんなデザインや機能もまず実現可能である。例えば標準状態では一直線に並んでいるメニューを Firefox まとめサイトのように分離してしまうことも、作業そのものはホネだが、技術的にはそう難しくない話である。（むしろデザインの力と HTML と PHP が複雑な if 文を挟んで混在する skin ファイルをきちんと調整する根性が必要。）
しかし tDiary テーマ互換の場合はそうはいかない。あまり HTML の構造に手を加えてしまうと、200もあるテーマから選べるというメリットが消えてしまう。それに新しい HTML の class を追加して adminmenu と navigation を分離することはできるかもしれないが、アプリの方で adminmenu が一つしかないことを前提に作り込まれていれば、その修正作業量はかなりのものになってしまうだろう。
今まさに FreeStyle Wiki に accesskey を付ける、という作業でメニューのカスタマイズについて考えている。PukiWiki の場合はメニューは全部 skin に集約されているので、skin をどれだけカスタマイズしても本体には影響せず、アップデートへの追従もしやすい。しかし FreeStyle Wiki ではメニューの構成は本体の方に入っているのでカスタマイズしてしまうとアップデートしにくくなる。そこでうまい具合に本家に取り込んでもらおうとしているんだけど、そもそも tDiary テーマ互換の場合はメニューのカスタマイズの自由度ってそんなに高くないんだよなということを改めて思っている次第。
便利なんだけどね、tDiary テーマって。でも Wiki に向いているとは思えないんだよな。HTML 的にも class="day" とか入っておかしなことになっちゃうし。tDiary テーマ互換を謳わずに、ある程度有名で、なおかつ今のうちなら skin のカスタマイズが容易な PukiWiki 当たりで Wiki 向けの共通テンプレートが作れたら面白くなるんじゃないかなぁ。
PukiWiki はなぜ table レイアウトなのか
ただ PukiWiki は標準の skin が table レイアウトだから、その辺で CSS によるデザインがやりにくいと思われているのかもしれない。これは歴史的な経緯によるもので、CSS によるマルチカラムデザインに対応していない Netscape 4 などのブラウザでも MenuBar（tDiary で言う sidebar）がちゃんと表示されるようにという配慮からくるものである。当時 Reimy 氏は苦渋の決断と言っていたように記憶している。なぜ MenuBar にこだわったのかは記憶にないが、Wiki の場合は、特にページ数が増え、内容が多岐に渡った Wiki の場合は MenuBar があった方が確かに便利だなとは思う。そこでマルチカラムデザインを守るために table を採用したというわけだ。これなら w3m でも使い勝手が大きく変わらないし、実際使ってみて便利だなと思う。
しかしそれも含めて再検討してもよいんじゃないかと個人的には思っている。PukiWiki 1.4 以降は UA ごとに skin を細かく切り替えられるので、tty 用ブラウザは table レイアウトで、グラフィカルなブラウザの場合は CSS レイアウト、という具合に分けるのもアリだし、今さら Netscape 4 のことを考える必要は、少なくとも非商用プロダクトの場合はないと思う。*2
まぁいちばんの問題は、例によって「じゃあお前が叩き台作れよ」と言われてもちゃんと作り上げる気力が自分にはないってことか。作るだけじゃなくて結構な量の議論をこなさないと標準的なテンプレートに育てることはできないしねぇ。
2006-05-12
_ 辞書サーバあったら便利かなぁ
と、不定期に思いつくんだけど面倒くさくて放置になってる。辞書サーバがほしいのは
- CD とか DVD とかメディアに縛られるのはいや
- 別に買うのがいやっていうわけじゃない
- goo とか infoseek とか Google とか使うけど、やっぱインターネット接続って速くないし、辞書はみんなが使うせいか反応がよくない
- 自分のサーバに放り込んでおけば LAN でサクサクだぜー
- 自分サーバなら自分で辞書データ選べて嬉しいぜー
という辺りが理由。サーバというからには当然 TCP/IP 越しに辞書データが検索、閲覧できることを想定している。
今はフリーで公開されていた当時の英辞郎データを後生大事に使い回してるんだけど、これだと英和しか引けない*1。和英は全文検索でなんとかなるけど英英とか引けないし、当然国語辞典にもならない。
で、何が面倒くさくて放置になっているのかというと、
- そもそもイマドキの電子辞書形式が分からない
- まだ EPWING でいいの？ そこで知識止まってるんだけど、もう古くない？
- クライアント/サーバで動く辞書ソフトを調べてない
- つかネットワーク越しに使うことについてライセンス的にはどうなってるんだろう？
- 個人利用は ok ? 複数人で共用は？
一台のクライアントマシンで使うだけなら、仮想CDのソフトと辞書のビュワーだけでいいんだろうけど、
それじゃ面白くないんだよな、なんとなく。
[2006-05-13 追記]
ndtp という情報が先に引っかかったが、最近は eb ライブラリ + (ebnetd | ndtpd | httpd) な感じっぽい。いやーここはなんでも揃ってるな、と思ったら以前 cvs proxy 調べてたどりついたページだった*2。
ndtp クライアントは Mac なら iDictionary.app がいいか？ Windows ネイティブは見つからないなぁ。CLI だったら結構いろんなものがある。EBView は GTk+ でよさげなんだけど、これはネットワークには対応してなさそう。ふむ。面倒なので Jamming *3 にしようかとか思い始めていたけど、ちょっとやる気出てきたかも。データは FreePWING による各種辞書 を見ると結構いろんなものが活かせそうだし。
参考
情報量が多すぎてあんまり見てない(^^;んだけど、たぶん一通りの情報は全部揃ってるんじゃないかな。EBNETD の方も詳しいマニュアルがあるのであとは辞書があればよさげな気がしてきた。
2010-05-12
_ mergeが難しいのはrepositoryが中途半端だから
のような気がする。最近は。
svn 1.5 くらいからあまり merge で苦労することはなくなっているような気がする。それでも merge に苦労することがあるのは
- branch が複線化しているなど複雑すぎる
- working copy の状態が中途半端
な場合が多い気がしてきた。
特に自分の場合は 2 のケースが多い。というのも関連するファイルに触る人が開発者以外も多く、とうてい全部をバージョン管理できない状態だから。（規模に対して教育コストが大きすぎる。）
理由が分かればあとは簡単。merge 用の working copy を用意すればよい。
実際、この方法を採用してからは merge でトラブることはほとんどなくなった。問題は、この方法を採用していることを忘れて中途半端な working copy で作業してしまうケースが後を絶たないことなんだけど、それはこのように日記に書き起こすことで少しは…減ってくれないかな。
_ Y!Pipesで日本語リソースに対してFilterモジュールを使う
結論だけ。2009-05 現在、[ Operators ] の [ Filter ] を使いたい場合は
- [ My pipes ] を起点にしてはいけない（ちゃんとフィルタリングされない）
- My pipes は使わずに Run Pipe した結果の feed を [ Sources ] の [ Fetch Feed ] を使って取り込むと大丈夫
- つまり、Pipe の結果を取り込もうとしない限り Filter は日本語リソースに対しても安全
という結果になった。こういうのって Pipes のバージョン情報とかないので、「いつの時点」しか書きようがないんだけど、ちょっと不便だね。細かいバージョン情報がとれるといいんだけど。