Google Readerを便利にするGreasemonkeyスクリプト
Via http://www.readwriteweb.com/archives/greasemonkey_scripts_for_the_s.php
非常に便利なのでまとめて紹介。
"1000+"の代わりに実際の未読数を表示する。
Google Readerは未読が1000を超えると、未読"1000+"という表示だけで実際の件数がわからない。
このスクリプトを使うと各フィードの未読数を合計して実際の件数を表示してくれる。
使い方は簡単。未読カウントの隣に表示されるようになるGoogle Readerアイコンをクリック。
手動でクリックしなければならず、自動更新は今のところなし。
"Preview"ボタンを追加する。このボタンを押すと実際の記事をフレーム内にロードするので内容を
Google Reader内で確認できる。もう一度クリックするともとに戻る。
List viewでもexpanded viewでも動く。
なお、プレビューはタイトルクリックやShift-VのショートカットでもOK。
名前の通り。自動的にスクロールしてくれる。
zを押すだけ。マウスホイールまわしてスピード調整。
他にもいろんな機能が入っている。
.crypto's devlog: Project: Google Reader autoscroll
memcachedは何故libevではなくlibeventを使っているのか?
多くの人がlibevの方がlibeventより早いし安定していると言っているのを聞くし、
3倍速いことを示すベンチマークも見た。libevにする予定はある?
という質問に対しての回答。
libevには半信半疑なんだ。pollerの指定をいろいろやる必要があるし、
graceful fallbackは複雑に見える。それに彼らはcronをリライトするのに一生懸命だ。
もし誰かパッチを書いてくれてベンチマークを走らせられるようなら、そのパッチとベンチマークを
ポストしてくれれば議論できるよ。それが全然早いようなら、オプションかなにかで動くようにする。でも僕はlibevにはlibeventスタイルのthreadサポートが欠けていると思ってる。
(ゲットーだけど動くからね)。 僕らには重要なことだ。libev
うまくいってるようには見えないよ。間違ってたら指摘して欲しい。
OOコード養成ギブス
Binstock on Software: Perfecting OO's Small Classes and Short Methods
The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に
興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。
これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための
詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら
このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。
彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。
これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるためだ。
このテクニックを適用したらコードは顕著にオブジェクト指向よりになることを保証する。
この制限は次のものだ。
- インデントは1メソッド1レベルのみ。2つ以上必要ならもう1つ別のメソッドを定義してそれを呼ぶようにする。これ重要。
- 'else'は禁止。条件文はifだけ。出来なければそのルーチンをexitすること。これでif-elseの連鎖を避けられて、1つのルーチンは1つのことだけをやるという状態を保てる。わかってきたね。
- 全部のプリミティブとstringをラップせよ。"primitive obsession."だ。整数型が使いたかったら、はじめにクラス(インナークラスでもいい)を作ってそれの本当の役割をはっきりさせる。たとえば郵便番号はオブジェクトで整数じゃないという具合に。これですっきりしてて、なおかつテストしやすいコードになる。
- 1行に1つのドットのみ使うこと。これで他のオブジェクトの深くまでいってフィールドやメソッドにアクセスするってことを避ける。こうしちゃうとカプセル化を破ることになってしまうから。
- 名前は省略しない。ある種の余計なものによって手続き的な冗長さできることを避けるためだ。もしメソッドや変数のフルネームをタイプしないといけないんだったら、きっともっと時間をかけて名前について考えるだろう。それによってshipOrder()というメソッドを持ったOrderなんてオブジェクトを作らなくなって代わりにOrder.ship()みたいな呼び出しが増えるはずだ。
- エンティティを小さく保つこと。クラスは50行まで、パッケージごとに10クラスまで。1クラス50行までというのは極めて重要だ。これは簡潔さを強いてクラスをフォーカスさせるだけではなく、どんなエディタ/IDEでも1画面にクラスが収まることにもなる。
- 3つ以上のインスタンス変数を持ったクラスは使わないこと。きっとこれは一番難しいだろう。ここでの著者の考えは、2つのインスタンス変数があると、ほぼ必ずと言っていいほどそのいくつかの変数を別のクラスにサブグループかする道理があるってことだ。
- ファーストクラスコレクションを使うこと。換言すればコレクションを持つクラスは他のメンバー変数を持つべきではない。primitive obsessionの拡張だ。コレクションを含んだクラスが必要なら、そういう風に書くんだ。
- セッター、ゲッター、プロパティを使わない。これはカプセル化を強いる抜本的なアプローチだ。これはDependency Injectionアプローチの実装も必要になるし、"言え、訊くな"という格言の遵守も必要となる。
断言する。これらのルールを破らずに1000行のプロジェクト書いたものはOOがうまくなる。
よって望めば制限を和らげることも出来るようになる。でも作者が指摘するのはそうする理由はないということ。
彼のチームはちょうど100,000行のプロジェクトをこの制限のうちに終えたところなんだ。
[Mac] Firefox3でのAquaSKKとことえりで常に半角スペースを入力をする話
AquaSKKがFirefox3でうまく動かないので一時的にことえりに戻した。
日本語入力時にスペースが全角になるのが嫌だったけど
簡単に直せた。
使えるdefaultsを書き込め
Leopard限定。
ことえりでスペースを半角に。
$ defaults write com.apple.inputmethod.Kotoeri zhsy -dict-add " " -bool false
再ログイン。(または killall Kotoeri)
trueで全角に。ほかにもあるから、見てみれ。
defaults read com.apple.inputmethod.Kotoeri zhsyわけわかめになったら、まるごと消せば次回に元に戻るみたい。
defaults delete com.apple.inputmethod.Kotoeri zhsy~/Library/preferences/com.apple.inputmethod.Kotoeri.plist を編集する方が楽かもしれん。
ちなみにAquaSKKの問題の方はhttp://www.mozilla-japan.org/products/firefox/3.0b5/releasenotes/
に既知の問題としてあげられていて、そこにあるBugzillaへのリンクをみる限り修正済みのようだ
次では修正されているはず。
KeyRemap4MacBookがEmacs,Terminalでも快適に
http://www.pqrs.org/tekezo/macosx/keyremap4macbook/index.html.ja
開発中のバージョンですと Emacs や Terminal, X11, VMware, Parallels などでは
自動的に EmacsMode を無効にするような機能が組み込まれていますので、
こちらをお使いください。
とのこと(多分4.0.29以降から?)。とても快適。
リンクは下のコメント欄のところにある。開発版だけどpkgファイルになっているので
インストールはダブルクリックするだけ。
開発版とは言っても今のところ全く問題なく使えているので怖がらなくてもOK、だと思う。
