今日も javascript の話

Rubyのことを書くブログだったんですけどね…。

画像の切り替え（同一のエリアに複数の画像をスライドショーのように表示する）を行う javascript を実現しようとして、「そんなの jQuery で一発だろう」と思っていたら、思いのほか基本機能には存在しませんでした。

ということで、「それでも誰かが作っているはずだ」と探したところ、InnerFade with jQuery というのを見つけました。
試してみたら思った通りの挙動をしてくれます。flash のことは嫌いじゃないんですが、やっぱりアクセシビリティということだと厄介な存在だとは思うんで、ちょっとずつ代替手段を見つけていきたいところです。

github のセットアップ on Windows

Github のページを参考に私物 Windows で github が使えるようにしてみます。

準備

使えるようにするための手順：

1. Git for Windows をダウンロード＆インストール
2. インストールした Git bash を使って以下を実行：まずは暗号鍵の生成
1. mkdir .ssh
2. ssh-keygen -t rsa -C "my-email@add.re.ss"
• 暗号鍵ファイルはデフォルトの .ssh/id_rsa{,.pub}
• パスフレーズは適当に設定
3. cat .ssh/id_rsa.pub 
• 次の手順で内容が必要になるので表示させておく
3. 公開鍵を github のアカウントに設定（コピペ）
4. 接続テスト
1. ssh -T git@github.com
5. git クライアントの設定
• git config --list で確認
• git config --global 属性名 値
• user.name, user.email, github.user, github.token

レポジトリの作成

次はレポジトリを作ります。
手元にあった hta アプリケーションをレポジトリに登録してみます。ちなみにこの hta アプリケーションは「学生に ping とか netstat とかをGUIで使わせたいんだよね」という先生の話を聞いて作ったものです。高校とか大学とかの情報教育に役に立てればうれしいのですが…。

1. github のサイトで "New repository" ボタンを押す
2. Project name を決めて "Create repository" ボタンを押す
• 今回の Project name は netcmd-hta としました。
3. レポジトリが作成される。そのページに表示される指示に従って git bash で作業：
1. （適当な場所で）mkdir netcmd-hta
2. cd netcmd-hta
3. git init
4. touch README
5. git add README
6. git commit -m 'first commit: add README'
7. git remote add origin git@github.com:kazunori-kawauchi/netcmd-hta.git
• origin という名前で github の netcmd-hta.git を参照する（リモートとの関連付け）
8. git push -u origin master
• commit した内容をリモートに対して push

こうやって作ったレポジトリにファイルやディレクトリを作っていって、add & commit & push して github 側に載せることができるようになりました。

ということで一応、リンクも載せておきます。
https://github.com/kazunori-kawauchi/netcmd-hta

OAuth について

…久々のブログだ。
というのはさておき。

ちょっと勉強のために OmniAuth を使った OAuth 認証を行えるサンプルの Rails アプリを作ってみました。
# OAuth で「認証」をやっている、と書くだけで素人臭さ全開ですね…。

OAuth の相手にはひとまず Twitter を選んでいます。
思ったよりも大変で1日掛かりでショボショボのサンプルが動きました。

認証基盤などは大雑把に理解しているつもりでしたが、概要と詳細の実現方法には大きな隔たりがある、実際にやってみることが大事だ、ということを再確認することになりました。
今回一番ハマッたのは

• Twitter 側の Callback URL に（テスト環境なので…）http://127.0.0.1:3000/auth/twitter/callback/ を指定する

ところでしょうか…。
後は OmniAuth がよろしくやってくれました。

vForum2011 に行ってきました

Ruby とは全く関係の無い話ですが、vForum2011 というVMware社が主催するイベントに参加してきました。

事前に興味を持っていたのは

• 仮想デスクトップ環境
• 仮想環境のバックアップ

辺りだったので、ほとんどその周辺技術のみの情報収集に終始しました。

仮想デスクトップ

BCP(Business Continuity Plan: 事業継続計画)の観点から仮想デスクトップが注目されているそうです。
3月11日の震災の影響もあり、日本でも一気に導入が進みうる状況が出来上がっています。

個人的には、「数百台のデスクトップマシンを集約的に管理するツール」として使えるかどうかを見に行ったのですが、

• ○：多くのマシンを管理するのには向いていそう
• ネットブート等に比べてもサーバ1台あたりのクライアント数が多い（最大100台くらいまでいける）
• 仮想ゲストOSのテンプレートから各ユーザに割り当てる仮想ゲストを作成し、重複部分は共有できる
• ×：描画のパフォーマンスはチューニング次第でそこそこ出るが、動画や音声を伴うと辛い

などの情報を受けて「教育用環境（特に言語学習）には採用しづらい部分がある」という判断を勝手に下しました。言語学習はどうしても外せない部分なので、「一括管理」を目指すのであればそこだけ分離させるのはどうも筋が悪そうに思えます。

そうなると教職員向けの環境としての仮想デスクトップの方が導入しやすい気がしてくるなぁ…。
教職員の方も、それはそれで「いつまでも Excel 2003を使う」みたいな状況があるので、アプリケーション仮想化と組み合わせて考えないといけないのですけれど…。

Rubyベストプラクティス 3章（中盤）

前・後編にしようと思ったら思いの外、内容がボリュームあって読むのに時間がかかってブログの更新も止まりがちです…。
ひとまず細かく分けることにしました。

ということで、今回は 3.3節 の特異メソッドの話のみです。

3.3節 オブジェクトごとの振る舞い

普通のオブジェクト指向プログラミング言語では振る舞いをクラスに結び付けて定義します。
Rubyではクラスだけでなく、（同一クラスの特定の）オブジェクトに振る舞いを結びつけることができます。

個人的にはまだこの機能の使いどころはつかめていません。この機能を頭の片隅に置きながら Ruby プログラムをたくさん書くことでしか体得できないのだろうなぁ、と考えています。
なお、Rubyベストプラクティスには

スタブメソッドの呼び出しが、テストの実行結果全体に影響を及ぼすことがないようにしたいためだ。

とテストケースの実行における例が書いてあります。

irb で見る基本的な特異メソッド

Rubyベストプラクティスの p.79 のサンプルを実行してみました：

irb(main):001:0> class User; end
=> nil
irb(main):002:0> user = User.new
=> #<User:0xb776a770>
irb(main):003:0> def user.logged_in?
irb(main):004:1>   true
irb(main):005:1> end
=> nil
irb(main):006:0> user.logged_in?
=> true
irb(main):007:0> another_user = User.new
=> #<User:0xb775715c>
irb(main):008:0> another_user.logged_in?
NoMethodError: undefined method `logged_in?' for #<User:0xb775715c>
    from (irb):8

user には logged_in? メソッドが定義されていて、別のオブジェクト another_user では logged_in? が使えないのが分かります。

実際に動的に特異メソッドを定義する

プログラムの内部で動的に特異メソッドを定義しようと思うと "define_method(symbolname, &block_body}" を使うのがこれまでの知識ですが、

irb(main):002:0> user = User.new
=> #<User:0xb773177c>
irb(main):003:0> user.define_method(:logged_in?) { true }
NoMethodError: undefined method `define_method' for #<User:0xb773177c>
    from (irb):3

直接だと define_method は使えません。

define_method を行うようにするには
irb(main):004:0> singleton = class << user; self; end
=> #<Class:#<User:0xb773177c>>
irb(main):006:0> singleton.send(:define_method, :logged_in?) { true }
=> #<Proc:0xb7713cb8@(irb):6>
irb(main):007:0> user.logged_in?
=> true
と記述します。
ここで使われているテクニック：

• 004 の部分（ singleton = class << user; self; end ）では、「クラスメソッドの定義」と同じ手法が使われています（が、詳しくは後で…）
• 006 の部分（ singleton.send(...) ）では、本来 private method である define_method を send メソッドを経由することで回避しています。

これでプログラム内で動的にメソッドを定義することが可能になりました。

Ruby におけるクラスメソッドの定義

Ruby ではクラスメソッドを以下のように定義します：

class A
  class << self
    def message
      "hello, world"
    end
  end
end

A.message
# => "hello, world"

「Ruby の世界では全てがオブジェクト」というのを思い出すと、2行目の "class << self " がクラス A のオブジェクトを拡張して（特異メソッドを定義して）いる、と読むことが…できるそうです。僕にはまだもう少し時間がかかりそう。

なので、irb:004 で行っている class << user; self; end は user オブジェクトを拡張するためのクラス（= user オブジェクトの特異メソッドを定義するための「空間（クラス）」）を生成していることになります。
後はそのオブジェクトに対して define_method してあげればいいわけです。

rvm と bundle の関係（初級）

rvm (Ruby Version Manager)は Ruby および RubyGems の切り替えを行うものですが、gem パッケージを管理する方法として bundler もあります。
いろんなブログを読んでいると「併用が最強」という風に見えるので、 bundler についても理解しておこうと思います。

Bundler は Gemfile を元に動作します。例えば、

gem 'rails', :version "> 3.1.0"

と Gemfile に書いてあれば、

$ bundle install  

とすることで、適切なバージョンの rails をインストールしてくれます。

また、システム上の gem に複数のバージョンの rails がインストールされていても

$ bundle exec rails generate ...

とすることで、Gemfile で指定されたバージョンを使ってコマンドを実行してくれます。

次の段階はきっと「バージョンアップにどうやって対応していくか」だと思うんですが、初歩の段階での環境構築についてはこのくらい分かっておけば何とかなりそうな気がしています。

あと、rvm との併用ってことで流れをまとめると

1. Rails アプリケーションのルートディレクトリ（$APP_HOMEとする）に移動する
2. Gemfile を書いて、$APP_HOME に置く
3. rvm --create use 1.9.2@yourappname とかで、新しい gemset の環境を作りつつ、その環境に移る
4. bundle install --path vendor/bundle で、新しく作った gemset 環境下に gem をインストール
5. .rvmrc を書いて、$APP_HOME に置く： "rvm use 1.9.2@yourappname" とだけ書いておけばOK（？）

こうすれば bundle exec のお世話にならなくても、その rvm 環境では単一のバージョンの gem しか存在しない「きれいな環境」なので、頭を悩まさなくても良さそうな予感です。

rails3 + rspec2 （の一歩手前）

Rails3 + Rspec2 の使い方

rails アプリケーションのルート(?)ディレクトリで、

$ rspec spec/*

とすると、spec以下の全てのテストが対象にできます。

逆に、

$ rspec spec/model

とか

$ rspec spec/model/somemodel_spec.rb 

とすれば、「model だけ」とか「特定の model だけ」とかをテストできます。


…まだ、きちんと書けて無いけれど。