Sunday, April 12, 2009

using SyntaxHighlighter

SyntaxHighlighterを試してみました。


class FooController < ApplicationController
before_filter :set_foo

# 詳細
def show
end
end

EMOBILE H11LC with Mac - a review

イーモバイルの小型通話+データ通信端末 H11LC を買ってしまいました。
Mac につないで実際に利用した場合のレビュー記事が見つからなかったのでちょっと書いてみます。

まだ一週間も経っていませんが、いまのところは、まあ、いいんじゃないですかね。

使う前は、一度何かをインストールすればあとは、USBで接続したらもうネットに接続されると勝手に思い込んでいましたが、実際は、
1. USBで接続すると、"Modem" という名のボリュームがマウントされる
2. そのボリュームに含まれる "H11LC_utility_mac_V1_00.app" または /Application にインストールされる "EMOBILE H11LC Utility.app" を起動する
3. その Utility で接続をクリックするとモデムで発信してネットに接続する
最低でも3アクション必要で、(自分の環境では) utility の起動に数秒かかります。

勝手に接続すると、接続料金が知らずに加算されていたりしそうなので、考えてみればあり得ないですね。
でも、USBに挿したらメニューバーの常駐アプリケーションの表示が変わり、メニューから「接続」を選択できたりするといいのに。

あとは文章にするのが面倒なので箇条書きに列挙します。

他に気づいた点を列挙すると、
* microSD のボリュームも utility 起動にちょっと遅れてマウントされるので USBメモリと同じ感覚では使えない
* 有機ELだからなのか?ディスプレイは日中の太陽光の下では非常に見にくい
* なぜか試供品扱いのストラップになる USBケーブル2 はかっこ悪いが便利なので外せない

音楽プレイヤーに関しては、(音質を気にするなら使わない前提で)
* utf-8 の日本語ファイル名は表示できている
* スペック通り mp3 以外は再生できないので m4a などは変換する必要あり
* mp3 の(ID3などの)タグ情報は参照されないのでファイル名でのみ識別
* mac 接続してユーティリティーを起動すると音楽再生は停止する
* イヤホンを接続するためには黒くダサイ専用イヤホンマイクを利用するか、ありえないデザインと大きさの黒いアダプタを利用する必要がある (pdfマニュアル p21 参照) => 他の携帯向けの変換アダプタが使えるか?
* 背面スピーカーからの音量は以外と大きいのでポケットに入れて、フロ掃除したりするときのBGMには使えるかも
* プレイリストの編集はメモリカードでなく本体のメモリ?に保存され、本体からでしか操作できない
現実的にはmp3を厳選するか、たくさん入れて全曲プレイリストのランダム再生?

Mac と他のシステムとファイル共有したりするときのいつもの問題だが、
* Finder を利用してコピーするとリソースフォークが ._ファイル名 として保存されるてしまい、音楽再生時に ._ファイル名.mp3 を無視してくれないので、いちいち「ファイルが壊れています」と表示されウザイ
* Spotlight 環境設定で除外しないと Spotlight の index が作成されて容量がムダになる (._ ファイルと同様、 Mac OS X 側の問題)

プログラマの視点からのどうでもいいこととしては、
* Utility はいちおう Cocoa アプリケーションのため、連絡先編集などのテキスト入力で emacs binding は使えるが、コスト削減のためか Windows 版と同じ設計(デザイン)で非常に格好悪い(スプラッシュ画面が出るようなアプリケーションに共通の格好悪さがある)。

あとは、参考資料
* イーモバイルのダウンロードページに H11LC の マニュアル(pdf)があります。
* ASCII.jp でのレビュー
* 小暮祐一という方のブログ記事
* みんぽす (先のリンクに複数のレビューあり)
などを参考にしてください。

Thursday, April 2, 2009

Pulling forked changes with git - an example

うれしいことに、拙作 script/refactor を改善する変更の pull request のメッセージが届いていたので早速、 pull しようと思ったけど手間取ってしまったのでそのメモです。

GitHub のガイド wiki には Pull Requestsがあるんですけど、手元の git (v 1.6.2.1) では、そのまんまだとリモートブランチとローカルブランチの名前が同じになってしまって、何かすると
warning: refname 'tjsheehy/master' is ambiguous.

のような warning が出て気持ちわるい。

試行錯誤の結果、シンプルにローカルブランチは作らずに master ブランチで pull して GitHub に push しました。
$ git remote add -f tjsheehy git://github.com/tjsheehy/script-refactor.git
$ git pull tjsheehy master
$ git commit


また、CHANGELOG をつくるのには、
$ git log --pretty=format:"* %s [%an] %h" | cat
こんな感じでログをフォーマット指定の pager なしで吐いて、切り貼りしました。


でも、あれですね。メジャーなプロジェクトをホストしている人は pull request 来まくって、ウザいでしょうね。

あと思うのは、 ssl_required など、とりあえず GitHub に引っ越しただけのプロジェクトとか fork されまくってるけど全然本家にマージされてないやつとかどれ使っていいのかわからなくて困りますね。Network グラフをみてどのリポジトリの本気度が高いか見極める必要があるし。

Tuesday, March 31, 2009

Disassembling Microsoft Bluetooth Notebook Mouse 5000

2009-11-8: See this instructable photos instead of my post.
2009-11-8: この記事を見るより、写真による説明を見た方がいいです。百聞は一見にしかず...。


(English version of instruction at the bottom of the post...)

Microsoft Wireless Notebook Optical Mouse 4000 を気に入っていたのですが、
* Macbook で使うには USBレシーバーが邪魔
* 光学式なので僕の机だとマウスパッドがないと動かない
* ホイールを左右に傾けられるやつなのでホイールが溝にひっかかる感じになることがある
というところが気に入らなかった。

Microsoft Bluetooth Notebook Mouse 5000ですべて解消すると思って買ってみました。
しかし、
1. 4000 と比べると形状が違うのでホールド感に違和感がある
2. 4000 のホイールはヌルヌルだったけど 5000 はゴリゴリでうるさいし、ちゃんとホールドしないと回しにくい

1 の問題は、まあ慣れればいいかなと思いましたが、2のゴリゴリ言うホイールは我慢できなかったので、分解して調整してみました。
分解の仕方がわからなかったけど、試行錯誤の結果分解できたのでそれを共有しようというのが本題です。

ポイントは
1. 最初にまわすべきネジの位置 -> 上部後方の三角のレーザーマーク?の下
2. そのネジがトルクスネジ(T6)なのでふつうの+/-のドライバーでは外せない
3. 2/3番目のねじはマウスボタンの下だけど、マウスボタンが固定されている後方のツメをうまくはずさないと回せない
という感じですね。



分解できたら、ホイールの軸受けみたいなところのデコボコと金属のヤマがゴリゴリいうのでそのヤマをマイナスドライバーとかで少し潰す。(画像ピンボケですいません)


はい終わり。

以下は英語で助けを求められたので説明を英語で書いてみました。(2009-5-13)

Instruction
1. Remove the emblem (image of laser?) on the hip? of the mouse. Because of it is glued you can remove it with tip of pin or needle.
2. After removing the emblem, you can see a torx screw (See the first photo). Remove it (I suppose required size of driver is T6).
3. I can't recall precisely, but without the screw you can slid mouse buttons, then unscrew pair of screws under the mouse buttons. Be careful to slid the mouse buttons, they are fixed with claws on the body.
4. Sorry, I can't recall anymore, I hope you get the point from my instruction.

Monday, February 2, 2009

search with named scopes

複数条件の AND 検索機能は Web アプリケーションを実装すると必ずといっていいほど実装するかと思います。
例えば、フォームからの入力で
params  # => {:city => "tokyo", :age => 30}
のようなパラメータが与えられるとすると、 fat controller を気にしなければ rails のアクションの実装は以下のようにやってました。
def index
conds, args = [], {}
unless (city = params[:city]).blank?
conds << "city = :city"
args[:city] = city
end
unless (age = params[:age]).blank?
conds << "age = :age"
args[:age] = age
end

if conds.blank?
@users = User.find(:all)
else
@users = User.find(:all, :conditions => [conds.map{|c|"(#{c})"}.join(" AND "), args])
end
end


named scope を使うと
class User
named_scope :city, lambda{|city| {:conditions => ["city = ?", city]}}
named_scope :age, lambda{|age| {:conditions => ["age = ?", age]}}
end

def index
@users = [:city, :age].inject(User) do |ret, scope|
params[scope].blank? ? ret : ret.send(scope, params[scope])
end.all
end

すばらしいじゃないですか。

検索してみるとすでに同じ事を思いついている人はたくさんいるようですね。

(上記、実際に動かしたコードをブログ用に書き換えたのでどっか間違っていたらごめんなさい。)

Tuesday, January 27, 2009

script/refactor

script/refactor という rails アプリケーションのリファクタリングを支援するスクリプトを書いてみました。

$ script/plugin install git://github.com/hiroshi/script-refactor.git

インストールすると、 script/refactor が生成されます。

例: user を person に変える。
$ script/refactor resource user person
Renamming files and directories:
git mv app/views/users app/views/people
git mv app/helpers/users_helper.rb app/helpers/people_helper.rb
git mv app/models/user.rb app/models/person.rb
git mv test/unit/user_test.rb test/unit/person_test.rb
git mv test/functional/users_controller_test.rb test/functional/people_controller_test.rb
git mv app/controllers/users_controller.rb app/controllers/people_controller.rb
git mv test/fixtures/users.yml test/fixtures/people.yml

Replacing class and variables:
user -> person
Users -> People
User -> Person
users -> people
pettern: /(\b|_)(user|Users|User|users)(\b|[_A-Z])/

./test/unit/person_test.rb:3: class UserTest < ActiveSupport::TestCase
./test/unit/person_test.rb:7: fixtures :users
./test/unit/person_test.rb:9: def test_should_create_user
./test/unit/person_test.rb:10: assert_difference 'User.count' do
...
./app/controllers/application.rb:18: current_user.group

NOTE: If you want to revert them:
git reset --hard


こんな感じにモデル、コントローラ、ヘルパー、テストのファイル名を変更して、コード中のクラス名、変数名もルールに従っているものは変更します。

適当に書いたスクリプトなので、特に置換する部分が思うような挙動にならない場合もあるかと思います。改善案やパッチをください。

Friday, January 23, 2009

My philosophy about testing

テストを含む開発の哲学については Rails 開発者の中でも様々あります。僕の場合、現状ではこんな感じなんですけど、みなさんどうですか?

テストの目的は2つあると考えます。
開発する最中に自分の書いているコードが正しいか確認するためのものと、コードを変更したときにその影響により過去に書いたコードが壊れないか確認するもの。

Rails アプリケーション開発の場合、前者は、基本的には、見た目の確認も行うため development mode でブラウザ確認で行います。
例外的に、レコードの作成、更新などで複雑な処理をする場合など、ブラウザでフォームに入力して、レコード作成、表示をするのに手間がかかったり、画面には現れないカラムの内容を確認したいときに、簡単な unit test を書いたりもします。

後者は一般的に回帰テスト(regression test)と呼ばれるもので、 Rails では functional test を中心に書いてゆきます。記述する精度は余裕やモチベーションによっても違うと思いますが、controller の各 action を実行して結果を簡単に確認して、 rcov による coverage 率が 100% に近づくようにします。

実装と平行、またはテスト駆動が望ましいとは思いますが、そうは言ってもね、たいていの場合は仕様がガッチリ決まっているわけではなく実験しながら実装することになるので、大きく変更する可能性があったり場合によっては捨ててしまうコードのテストに時間をかけるのはもったいないしモチベーションも上がらないので、実装がほぼ完了して次のタスクにとりかかる前にテストを書きます。
仕様決定権限がある人に確認してもらうこともある意味テストなので、極論ですけど、実装したものが仕様として望ましいかどうかのテストに合格してから実装の品質をテストしないと、「テストも全部書いてしまったので変更はできません」なんて本末転倒なことになるかと思います。

あとは、リリース後に不具合が見つかった場合、テストが甘かったわけなので、理想的には、その不具合を再現するテストを書いて、コードの修正でテストが通ることを確認して解決とします。