Ruby on Railsで開発中、「このテーブルのカラム名を変更したい」「このテーブルの構造を変更したい」といった事態が生じると思います。
こんなとき、最初はdb/migrateの下にできたファイルを編集すればいいのだと思っていました。しかし、いくら変更しても、追加したカラムが反映されない。どうもおかしい。なぜだろう、といろいろ見てみると、db/schema.rbというファイルでデータベースの構造を管理していることが分かりました。こちらも編集すると、追加したカラムなどが反映されます。
しかし、このような方法は推奨されない、というかやってはならないものみたいです。rails generate modelした直後に変更するなどならまだしも、以前に作られたものを変更するなどすると、もはや元に戻せなくなり、困ったことになりかねません。ちょっとした変更でも、ちゃんとジェネレータを介して操作した方がいいようですね。
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 3.0 日記」で解説がなされていました。Railsを以前から使っている方が書いた記事のようで、ちゃんと「分かっている」方が書いた内容となっています。また、スクリーンショットも多用されているので、分かりやすいないようになっています。
すでにいろいろと書きましたが、ぜんぶ忘れてください(笑)。上記記事を参照すれば、Ruby on Railsの基本的なところは分かると思います。
ここでは、作業記録的なものを書いていこうと思います。
Ruby on Railsが動作するようになったところで、アプリケーションの完成形をイメージしていきます。抽象的な事項（アプリケーションが提供する機能）は先に掲げたとおりですので、その機能を提供するための具体的な方法や手順について考えていきます。これにより、アプリケーションがどのようなウェブページを提供しなければならないのか、そして何を作らなければならないのか、明らかになっていきます。
Anacondaは、情報源を外部に頼ります。そのため、「どのような情報が存在するのか」をシステムに知らせてあげなければなりません。情報はIDによって識別するものとします。Evernoteは各ノートにGUIDを割り当てているので、このGUIDをIDとして使えばいいでしょう。Spiderで考えれば、ネットワークのGUIDと、情報オブジェクトの番号を組み合わせた文字列がIDになります。Anacondaは、まず最初に、このID収集を行う必要があります。IDを収集する際、同時に、どの情報源から取得したのかも記録しておく必要がありますね。
使用する情報のIDが集め終わったら、反復学習を始めることができます。以前にチェックした日時と、そのときのユーザー評価から、表示すべき状態にある情報を選び出し、表示します。そして、ユーザーは表示された情報についてチェックし、もう表示する必要はない、ある程度分かったので次のチェックは先でよい、分かっていなかったので次のチェックは近くに行う、などの評価を与えます。メモを残せるようにしてもよいですが、現時点では見送ることにしましょう。ある情報についてチェックが終わったら、次の情報を表示します。表示すべき状態にある情報が無ければ、その日の分は終了したということになります。
なかなか理解が進まない情報や、全体に対する進捗情報などを確認する、分析的な処理もあると便利ですね。しかし、これも現時点では見送ることにしましょう。いつか追加する予定がある、という程度に捉えておきます。
以上から、Anacondaが提供すべきウェブページは、次のようになります。
とりあえずは、トップページから作っていくことにしましょう。
とは言ったものの、何を編集すればよいのか分かりません。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で動作するので、まずは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なのか」をしっかり把握しておくようにしたいと思います。まあ、そのうち、そんなことを考えなくてもいい時代が到来するのかもしれませんが。
Evernoteの発見により、Spiderは瀕死の重傷を負ってしまいました。
細かい点を見れば存在価値も見出せるので、息の根を止められたというわけではないのですが、はたしてそれらのために作り続けるだけの価値があるのかというと難しいところがあるので、再起不能の重傷を負ってしまったといえるでしょう。
一方、Spiderを利用して作ろうとしていたアプリケーションは、Evernote単体では実現できない機能を提供するので、少なからぬ動揺を受けてはいるものの、未だ健在です。
何を作ろうとしていたかといえば、反復学習のためのアプリケーションです。学習は、新たに取得した記憶を自身に定着することで進んでいく側面があります。これは、同じことを繰り返し行うことで実現されるのですが、自分で意識的に行おうとするとなかなか難しいところがあります。効果的な反復学習を行うには、一定の時間を空けることが必要といわれています。どの情報を、いつ取り組んだのか、すべて自分で管理するのは、情報が増えれば増えるほど難しいものです。そのため、アプリケーションによる学習履歴の管理が必要となるのであり、類似のソフトウェアも存在するようですが、わたしが望む機能を備えているものは無いようです。
このようなソフトウェアを、まるで知識に巻き付いて取り込んでいくものだということで、Anacondaと名付けました。
最初はSpiderのネットワークを利用してアプリケーションを構築しようと考えていたのですが、先述のとおり、Spiderは再起不能となってしまったので、依って立つ土台を大きく変える必要があります。
どうやら、Evernoteは、付属するアプリケーションや、Web APIを利用することで、そのデータベースにアクセスすることができるとのことです。だとすれば、ウェブアプリケーションとの親和性が強いということになります。ウェブアプリといえば真っ先に思い浮かぶのはPHPですが、個人的には、あまり好きではありません。使えるものならば、Rubyを使いたい。そういえば、Rubyにも優秀なフレームワークとしてRuby on Railsというものがあります。噂には聞くのですが、実際に使ったことはありません。
ということで、Ruby on Railsを使って、Anacondaを実装することに決定しました。
とはいえ、Ruby on Railsに関しては素人なので、「流儀」を学びながらの開発となります。その過程については、このブログに書き込んでいく予定です。
さて。まずはAnacondaが備えるべき機能を明らかにしておきましょう。いわば、これから歩む道の到達点です。
ひとまずは、こんなところです。すでに作成に取りかかっていることもあるので、これは枝葉を取り除いた後の姿になっています。最初はいろいろと別の機能も搭載することを考えていたのですが、そうすると「これは一体いつ完成するのか？」ということになってしまうので、できるだけシンプルな機能だけを搭載することにしました。その代わり、外部とのインターフェイスには最大限の柔軟性を持たせ、多様な外部アプリケーションとの連携を前提としています。
以前から、使いやすいWindows用テキストエディタを探しています。
「使いやすい」とは、「自分の手になじむ」「自分の感性に合う」という意味であって、客観的な評価基準があるというわけではありません。この「自分にとって」という主観的な評価基準をできるかぎり客観的に表現するのであれば、不完全ながら、次のようになるでしょう。
いろいろと使ってみてはいるのですが、なかなか「これぞ！」というものに出会えません。そりゃあ、これだけ高いハードルを設定すれば、そうかもしれませんが。
しかし、テキストエディタは意外と多くの方々が作っているソフトウェアであり、探せば理想とするものが見つかるかもしれません。多くの方々が作っているというのは、それだけ何かしらの不満があるということなのかもしれませんね。
まずは、どのようなエディタがあるのか、というところから調査します。同じようなことを考えている人が多いのか、Wikipediaには、代表的なテキストエディタをリストアップしたページがあります。まずは、そこに挙げられたテキストエディタを確認していきましょう（随時更新予定）。
最近流行のEvernoteを使ってみました。
第一印象としては、「緩い」個人用データベースです。
これはSpiderとほぼ同じ方向性です。パクられた！(笑)
というわけで、困りました。Spiderを作り上げても、その到達地点には、Evernoteという同目的かつ高品質な製品が待ち構えています。はたして、Spiderを作り上げる意味はあるのでしょうか？
もしEvernoteの保有する情報を他のアプリケーションから使用できないのであれば、Spiderにも存在意義があります。しかし、Evernoteは、Evernote APIという形で、データベースへのアクセス方法を提供しているのでした。ちゃんちゃん。
これにて、Spiderは息の根を止められました。
今後は、いかにEvernoteのデータベースを外部アプリケーションから操作するか、という観点で研究を進めていきたいと思います…。
日本語変換ソフトとしてATOKを使っています。MS-IMEでも良いのでしょうが、以前から使っているというのと、日本語変換の精度で定評があるということで選びました。長く使っていますが、間違った選択ではないと思っています。
さて、ATOKでもMS-IMEでも、真に使いやすい日本語入力環境とするには、個人に応じたカスタマイズが必要です。辞書の整備もそのひとつで、よく使う単語などは、辞書に登録しておくと後々の作業がはかどります。ATOKの辞書管理はちょっと特殊で（MS-IMEなどを詳しく知らないのでこれが普通なのかもしれないけれど）、ユーザーが自由に作成できる辞書と、システムが使っている辞書があります。ここで混乱を引き起こすのが、「辞書セット」という概念です。辞書セットには、複数の、ユーザー（辞書作成を主たる事業とする企業なども含む）が作成した辞書を登録することができます。これにより、ある特定の辞書セット（たとえば「インターネット関連辞書セット」）に、特定の傾向を持った単語が登録された辞書（たとえば「インターネット顔文字辞書」「インターネット用語辞書」）が登録できるようになります。いちいち辞書をマージしなくてもよいのが便利なのでしょう。しかし、これらの「登録された辞書」とは別に、「ユーザー辞書」というものが、それぞれの辞書セットに作成されます。この「ユーザー辞書」とは、単語登録（Ctrl+F7）や推測変換の情報を貯め込む辞書です。単語登録時に登録先の辞書セットを選ぶことができるのですけれども、ある辞書セットを選択して単語登録をすると、その辞書セットに登録されている辞書（のファイル）に単語が登録されるのではなく、辞書セットに対応したユーザー辞書に単語が登録されます。このユーザー辞書は、ATOK側が自動的に作成してくれます。
さて、登録した単語が間違えていた、他に作成していた自分用の辞書の情報をマージしたい、などの理由により、ユーザー辞書を編集したくなったとします。このとき、「辞書メンテナンス」にある「辞書ユーティリティ」というツールを使うことで、登録されている単語を編集したり、他の辞書から単語情報を持ってきたりすることができる…はずなのですが、メニュー上の項目が灰色になっており、単語情報の編集はおろか、追加や削除もできないようになっている場合があります。
これは、「オンメモリ辞書」という機能を使っているために引き起こされます。メモリ上に辞書を置くのでアクセスが高速化されるのですが（以前使っていた環境ではバグの温床でしたが…最近は改善された様子）、登録された単語情報を編集できなくなるというデメリットも生じてしまうということになります。…ひどいですね！
「オンメモリ辞書」のチェックを外すと、編集ができるようになります。このとき、再起動が必要になります。