何年ぶりか分かりませんが，xyzzyがバージョンアップしました。
作者の気分が乗らなくなったとかで開発が完全ストップしていましたが，最近になって，オープンソースとして開発が進んでいるようです。新機能やバグ修正が行われており，また使ってみようかと思っています。
xyzzy 0.2.2.236
Reply
Category Archives: ソフトウェア
Ruby on Rails挫折
こんなところ読んでいる人がいるのか分かりませんが、ことの顛末は書かなければならないと思いますので、書いておきます。
2か月ほど前に「Ruby on Railsでアプリを作る！」と意気込んでいたのですが、その意気込みは、日数が経過して完全に消滅してしまいました。なぜかというと、Ruby on Railsで開発することの「まずさ」が予想以上に大きかった、時間が経過するにつれて考え方が変わった、という理由によります。
最初、次のような理由からRuby on Railsを使おうと考えていました。
- 書かなければならないコード量が少ない。
- Rubyで書ける！
- データベースの種類を気にせず、データベースの恩恵を受けられる。
- HTML部品が使えるので、プレゼンテーションが比較的容易。
しかし、作っていく中で、次のように考えが変わってきました。
- 単体で動作するアプリケーションとする場合、ウェブサーバを立てなければならない。それがRuby on Railsに付属するものであったとしても、手軽さは減少する。
- デバッグがやりにくい。起動して、走らせてみて、動作チェックするというプロセスに（スタンドアロンのプログラムと比較して）時間がかかる。
なんとなく、Ruby on Railsは最初に設計をしっかりと行ったうえで、ある程度の見通しを立ててから作るスタイルなのだと感じました。だとすると、行き当たりばったりで作っているようなホビープログラマには向かない環境だということになります。
もちろん、使い始めて間もないので、今回苦労したあたりを楽にするツールもたくさんあるのだろうと思います。しかし、それを教えてくれる環境もないですし、自ら探すのも面倒に感じます。
そんなわけで、Ruby on Railsでなにかを作るという計画は、いったんお蔵入りとし、続く記事は書かれないということになります。いつか、Ruby on Railsに適したアプリケーションを作ろうとしたとき、また触れるかもしれません。
Pure JavaなHTMLレンダリング
CobraというPure JavaなHTMLレンダラーがあるそうです。オープンソースで開発が進められており、HTML4、Javascript、CSSがサポートされているとのこと。性能のほど（レンダリングの質）はまったく確認していないのですが、JavaでHTMLを扱うソフトウェアを開発するときなど、役に立つ場面もあるのではないでしょうか。
ちょっと気になるので、いつか使ってみようと思います。
Ruby on Rails – 開発中のテーブル調整
「最初にガチガチに設計してから開発する」というスタイルをとらない場合（個人開発・趣味開発の場合はほとんどがあてはまると思います）、開発が進行するに伴って、モデル（データベーステーブルの設計）を変更していきたいと思うはずです。
このようなとき、先の記事にも書きましたが、db/migrateにあるファイルを変更するだけでは、データベースに反映が行われない場合があります。正しくは、マイグレーション機能を使ってインクリメンタルに変更していかなければなりません。しかし、個人で開発する場合、これは面倒です。テーブル数が少ない、カラム数が少ない、といった小規模開発の場合は、とくに当てはまります。
そんなわけで、たぶん正しいやり方ではありませんが、db/migrateのファイルを直接編集する場合の力技的な方法をメモしておきます。
1 2 3 | $ rm db/migrate/*.sqlite3 db/schema.rb $ rake db:create $ rake db:migrate |
要は、データベースファイルとスキーマファイルを削除して、データベース関連ファイルを再構築するだけです。すでに完成したバージョンの上で動かしたい場合は、その時点のデータベースファイルとスキーマファイルを保存しておいて、巻き戻したいときはそれらのファイルで上書きコピーしてしまえばいいということになります。このとき、編集するdb/migrateのファイルを間違えないように注意（そんなことはしないと思いますが…）。
Ruby on Rails – データベースのマイグレーション
Ruby on Railsで開発中、「このテーブルのカラム名を変更したい」「このテーブルの構造を変更したい」といった事態が生じると思います。
こんなとき、最初はdb/migrateの下にできたファイルを編集すればいいのだと思っていました。しかし、いくら変更しても、追加したカラムが反映されない。どうもおかしい。なぜだろう、といろいろ見てみると、db/schema.rbというファイルでデータベースの構造を管理していることが分かりました。こちらも編集すると、追加したカラムなどが反映されます。
しかし、このような方法は推奨されない、というかやってはならないものみたいです。rails generate modelした直後に変更するなどならまだしも、以前に作られたものを変更するなどすると、もはや元に戻せなくなり、困ったことになりかねません。ちょっとした変更でも、ちゃんとジェネレータを介して操作した方がいいようですね。
Ruby on Rails – コントローラのメソッド
Ruby on Railsは、さまざまな「慣習」を用いて、コーディングしなければならない分量を減らす作戦を用いています。
コントローラのメソッド名も、そのなかの一つ。こういう「暗黙のルール」をまとめておいてくれる場所って、ないものですかねえ。まあ、ドキュメントの全部を把握していない段階では、すべてが「暗黙のルール」に見えるわけですけれども。いや、ドキュメントに書かれていれば「明示のルール」なのかな？
それはさておき。
RailsGuidesのRails Routing from the Outside Inによれば、HTTPリクエストの命令とパスによって、コントローラのうち呼び出されるメソッドが決定されるとのことです。ドキュメントの位置からも分かるとおり、これは「ルーティング」に分類されるルールです。リクエストに応じて適切なコントローラのメソッドを呼び出すのですから、確かにルーティングですね。
ただし、これは自動的に設定されるわけではなく、routes.rbで明示的に指定する必要があります。
1 | resources :controller1, :controller2, ... |
なお、resourceではなく、resources（複数形）なので注意してください。単数形の方は、パスの中にIDを含まない（パラメータでIDを指定する）ものになります。複数形の方は、パスの中にIDを指定するものになります。
resourcesで使用されるメソッド名は、次の7つです。
| メソッド名 | 対応するHTTPリクエスト |
|---|---|
| index | GET / パス=/example |
| new | GET / パス=/example/new |
| create | POST / パス=/example |
| show | GET / パス=/example/[ID] |
| edit | GET / パス=/example/[ID]/edit |
| update | PUT / パス=/example/[ID] |
| destroy | DELETE / パス=/example/[ID] |
コントローラでこれらのメソッドすべてを実装する必要はありませんが、特定のHTTPリクエストが送られてきたとき、対応するメソッドが定義されていないとエラー（ページ）が返されます。
Ruby on Rails – 先人の軌跡
探せばあるもので、Ruby on Railsの基本的な部分については、「Ruby on Rails 3.0 日記」で解説がなされていました。Railsを以前から使っている方が書いた記事のようで、ちゃんと「分かっている」方が書いた内容となっています。また、スクリーンショットも多用されているので、分かりやすいないようになっています。
すでにいろいろと書きましたが、ぜんぶ忘れてください(笑)。上記記事を参照すれば、Ruby on Railsの基本的なところは分かると思います。
ここでは、作業記録的なものを書いていこうと思います。
Ruby on Rails – 設計
Ruby on Railsが動作するようになったところで、アプリケーションの完成形をイメージしていきます。抽象的な事項（アプリケーションが提供する機能）は先に掲げたとおりですので、その機能を提供するための具体的な方法や手順について考えていきます。これにより、アプリケーションがどのようなウェブページを提供しなければならないのか、そして何を作らなければならないのか、明らかになっていきます。
Anacondaは、情報源を外部に頼ります。そのため、「どのような情報が存在するのか」をシステムに知らせてあげなければなりません。情報はIDによって識別するものとします。Evernoteは各ノートにGUIDを割り当てているので、このGUIDをIDとして使えばいいでしょう。Spiderで考えれば、ネットワークのGUIDと、情報オブジェクトの番号を組み合わせた文字列がIDになります。Anacondaは、まず最初に、このID収集を行う必要があります。IDを収集する際、同時に、どの情報源から取得したのかも記録しておく必要がありますね。
使用する情報のIDが集め終わったら、反復学習を始めることができます。以前にチェックした日時と、そのときのユーザー評価から、表示すべき状態にある情報を選び出し、表示します。そして、ユーザーは表示された情報についてチェックし、もう表示する必要はない、ある程度分かったので次のチェックは先でよい、分かっていなかったので次のチェックは近くに行う、などの評価を与えます。メモを残せるようにしてもよいですが、現時点では見送ることにしましょう。ある情報についてチェックが終わったら、次の情報を表示します。表示すべき状態にある情報が無ければ、その日の分は終了したということになります。
なかなか理解が進まない情報や、全体に対する進捗情報などを確認する、分析的な処理もあると便利ですね。しかし、これも現時点では見送ることにしましょう。いつか追加する予定がある、という程度に捉えておきます。
以上から、Anacondaが提供すべきウェブページは、次のようになります。
- ID収集・学習などの機能へ分岐するトップページ。
- ID収集のため、収集元を選択するページ。
- 表示すべき状態にある情報を表示し、それに対する評価を与えるためのページ。
とりあえずは、トップページから作っていくことにしましょう。
とは言ったものの、何を編集すればよいのか分かりません。Ruby on Railsのガイドを見ながら進めていくことにします。
まずはアプリケーションを作成します。
1 | $ rails new Anaconda |
詳しい仕組みはまだ分からないのですが、サイト上のルートディレクトリはプロジェクト上のpublic/に相当し、ここにindex.htmlというファイルが存在すれば、これを読み込むようです。静的なウェブページを使うことはないはずなので、削除してしまいます。すると、ルーティングに失敗するというエラーが出るようになります。ルートディレクトリについて表示すべきファイルがないため、エラーが出ているようです。そこで、表示すべきページを作成することにします。これは、Ruby on Railsが提供する機能を使って自動的に行うことができます。
1 | $ rails generate controller index home |
次に、ルーティングを行うファイルに、ルートディレクトリとして表示すべきものの位置を教えてあげる必要があります。config/routes.rbを開き、次の行を書き加えます。
1 | root :to => "home#index" |
ルートとして、"home#index"を指定するという意味です。これは、コントローラhomeのindexメソッドを表しており、homeというページのindexというラベルを表すものではありません。ここまで書き加えれば、サーバを起動して、http://localhost:3000にアクセスすることで、homeコントローラのindexメソッドが呼び出されていることを確認できます（表示されているのはビューhomeのindex.html.erb）。
ところで、config/routes.rbには、次の行も追加されています（railsコマンドで自動的に追加される）。
1 | get "home/index" |
これは、パスhome/indexに対するHTTPのGETリクエストを許可するという意味です。呼び出されるのは、homeコントローラのindexメソッドになります。この行を取り除く前はhttp://localhost:3000/home/indexに対するアクセスが成功し、取り除いた後はhttp://localhost:3000/home/indexに対するアクセスがエラーを返すようになります。home/indexは使わないので、取り除いておきます。
サーバの起動は、次のようにして行います。
1 | $ rails server |
いきなり「コントローラ」や「ビュー」という言葉が出てきました。これは、MVCモデルのControllerとViewのことです。Ruby on RailsはMVCモデルを採用しています。これによって、論理のコードと表示のコードを分離することができ、開発を局所に集中して行うことができるようになります。なお、Rubyはとても緩い言語ですので、表示に関する処理のみをすべきであるビューに、データ操作に関する処理を入れてしまうことができます（たぶん）。これをやるとMVCモデルを採用している意味が完全に失われてしまうので、自分がいまどの部分について作業しているのか、しっかりと自覚しておく必要があります。まだModelが出てきていませんけれども、じきに登場します。
Ruby on Rails – 下準備
Ruby on Railsはスクリプト言語Rubyで動作するので、まずはRubyをインストールするところから始めます。なお、環境はWindowsです。
Rubyの公式サイトからダウンロードしてもよいのですが、RubyInstallerというパッケージを使うのも楽です。これは、Windows用にRubyをビルドした環境をパッケージにしたものです。実行形式のインストーラーもあるので、楽ではあります。単にアーカイブしただけのパッケージもあるので、変なインストーラーは使いたくないという方は、そちらも使えます。使うRubyのバージョンは、もちろん最新版（執筆時点で1.9.2）。いまさら1.8系を使うのも、時代遅れというものです。幸いなことに、Ruby on Railsも3.0以降はRuby 1.9をベースにしているようです。
次に、Ruby on Railsをインストールします。
Rubyを使える状態にして（環境変数PATHにRubyの実行ファイルが格納されたディレクトリを追加する）、Rubyのパッケージマネージャgemを使えるようにしておきます（いまは標準添付されている？）。ここまでできたら、gem install railsするだけです。
1 | $ gem install rails |
自分の環境では、マニュアルをコンパイルしているところでエラーが発生しました。しかし、全体としては問題なく動作しているので、無視しています。何も指定しなければ、安定した最新版がインストールされることになるでしょう（執筆時点で3.0.9）。
次に、SQLite3をインストールします。これは必須ではないのですが、開発段階からMySQLなどフルセットのデータベースを使うのは設定が面倒ですから、それらの面倒を省くことのできるSQLiteを導入しておいた方が楽だと思います。
まず、gemで必要なRubyライブラリをインストールします。
1 | $ gem install sqlite3 |
次に、SQLiteのホームページからsqlite3.dllをダウンロードします。ダウンロードしたら、適当なディレクトリにDLLを展開し、環境変数PATHを通します。ここまで終わったら、正常に動作するか、チェックしておきましょう。
1 | $ ruby -e 'require "sqlite3"' |
さて、ここで、rake 0.9以降を使っている場合（？）、rakeがうまく動作しないという問題があります。理由はよく分からないのですが、こちらで紹介されている解決方法を実行すると、確かにエラーが出なくなりました。どうやら、rakeのバージョンによって挙動が違っているようで、それが悪さをしているようです。この対処により正しく動作しているような感じですが、まだちょっと分かりません（のちに検証して追記するなどします）。
まだ方法は紹介していませんが、作成したプロジェクトにあるGemfileに次の行を書き加えます。
1 | gem 'rake', '0.8.7' |
そして、次のコマンドを実行します。
1 2 | $ bundle unlock $ bundle update |
こちらの情報によれば、Gemfile修正後、次のコマンドを実行するのでもいいようです。
1 | $ bundle update rake |
ちなみに、bundleとはBundlerというプロジェクトが提供するプログラムで、アプリケーション相互の依存関係を管理するために作られたものだそうです。
Ruby on Railsは素晴らしいフレームワークですが（そうなのだそうだ）、さまざまな技術を利用しているので、「果たしてこの機能は何が提供しているんだろうか？」と疑問に思ってしまうことがしばしばです。なにやら、Active Supportという、Rubyの標準ライブラリに（ウェブアプリ開発に）便利な機能を多数追加するという芸当をやっているそうで、これも「果たしてこの機能はRubyが標準で提供しているものなのだろうか？」と思ってしまうことが多いそうです。おいおい分かってくると思いますが、「どこまでがRailsなのか」をしっかり把握しておくようにしたいと思います。まあ、そのうち、そんなことを考えなくてもいい時代が到来するのかもしれませんが。
ATOKのユーザー辞書が編集できない
日本語変換ソフトとしてATOKを使っています。MS-IMEでも良いのでしょうが、以前から使っているというのと、日本語変換の精度で定評があるということで選びました。長く使っていますが、間違った選択ではないと思っています。
さて、ATOKでもMS-IMEでも、真に使いやすい日本語入力環境とするには、個人に応じたカスタマイズが必要です。辞書の整備もそのひとつで、よく使う単語などは、辞書に登録しておくと後々の作業がはかどります。ATOKの辞書管理はちょっと特殊で（MS-IMEなどを詳しく知らないのでこれが普通なのかもしれないけれど）、ユーザーが自由に作成できる辞書と、システムが使っている辞書があります。ここで混乱を引き起こすのが、「辞書セット」という概念です。辞書セットには、複数の、ユーザー（辞書作成を主たる事業とする企業なども含む）が作成した辞書を登録することができます。これにより、ある特定の辞書セット（たとえば「インターネット関連辞書セット」）に、特定の傾向を持った単語が登録された辞書（たとえば「インターネット顔文字辞書」「インターネット用語辞書」）が登録できるようになります。いちいち辞書をマージしなくてもよいのが便利なのでしょう。しかし、これらの「登録された辞書」とは別に、「ユーザー辞書」というものが、それぞれの辞書セットに作成されます。この「ユーザー辞書」とは、単語登録（Ctrl+F7）や推測変換の情報を貯め込む辞書です。単語登録時に登録先の辞書セットを選ぶことができるのですけれども、ある辞書セットを選択して単語登録をすると、その辞書セットに登録されている辞書（のファイル）に単語が登録されるのではなく、辞書セットに対応したユーザー辞書に単語が登録されます。このユーザー辞書は、ATOK側が自動的に作成してくれます。
さて、登録した単語が間違えていた、他に作成していた自分用の辞書の情報をマージしたい、などの理由により、ユーザー辞書を編集したくなったとします。このとき、「辞書メンテナンス」にある「辞書ユーティリティ」というツールを使うことで、登録されている単語を編集したり、他の辞書から単語情報を持ってきたりすることができる…はずなのですが、メニュー上の項目が灰色になっており、単語情報の編集はおろか、追加や削除もできないようになっている場合があります。
これは、「オンメモリ辞書」という機能を使っているために引き起こされます。メモリ上に辞書を置くのでアクセスが高速化されるのですが（以前使っていた環境ではバグの温床でしたが…最近は改善された様子）、登録された単語情報を編集できなくなるというデメリットも生じてしまうということになります。…ひどいですね！
「オンメモリ辞書」のチェックを外すと、編集ができるようになります。このとき、再起動が必要になります。