EclipseのプラグインClayについて
EclipseのプラグインClayについて「Railsでどのように開発に使っていますか？」という質問メールが来てさらっと回答しようとおもったら長くなったのでエントリーにしました。
私の場合、Clayはモデル図の出力のためというよりは、DB設計の初期の段階で使っているという感じです。
ClayはDBからリバースしてモデル図を出力することもできますが、その場合、テーブル間の関連は失われてしまうようです。（その辺は無料のツールなので贅沢と割り切り）
Rails用のリバースならRails Schema Browserとか今後に期待しています。
http://tomtenthij.nl/2008/2/12/rails-schema-browser-plugin-proof-of-concept
Clayでは逆にGUIでテーブルと関連、インデックスなどを書いて、それがSQLに吐き出せるのでそちらの機能を主に使っています。なのでRailsと連携というよりは、開発環境に設計＆SQL生成ツールがついたと思っていただいたほうが良いかと思います。Railsと連携というよりはDBを使った開発全般向けです。テーブルが数十個とかになってくると関連を覚えておくだけでも大変ですからね。また、RailsにはMigrationという非常に便利なDBスキーマ管理ツールがありますが、「Migrationによるスキーマ管理」と「Clay(というよりER図によるスキーマ管理)」はそれほど相性の良いツールではありません。
私の場合は次のような使いかたをしています。
（最初想定するテーブルが数十とかもっと多いことになることが予想できるような場合です。少ない時はMigrateionだけでOKじゃないかと思います）
（MySQLの場合SOURCEコマンドなどでファイル指定）
- プログラムを書く
開発の初期はある程度これでやってしまいます。
特にRailsに限った話。
- Scaffold(Restfulな)などが使いたい場合は--skip-migrationオプションを付けるとmigrationファイルの生成を止めることができます。
- 現状のスキーマからMigrationファイルを作りたいときは、rake db:schema:dumpを実行するとdb/schema.rbを生成することができますのでこれをdb/migrate/001_initial_schema.rbなどにコピーします。もちろんこのとき001_initial_schema.rbには全てのテーブルの情報が入ります。その後、rake db:migrate OR rake db:migrate:resetでDBに反映させることもできます。
- 最初の公開環境へのDeploy後はClayを使うのを基本的にやめてます。それ以降は通常のRailsの開発の流儀にしたがって、db/migrate/002_xxx.rbといったファイルを作り始める。公開後のスキーマ変更のための差分ファイルがなければ困りますよね？そうしなければcapistranoによるdeployの恩恵がほとんどなくなります。
Railsの正しい（一般的な？）開発は、最初からMigrationを使うことかもしれません。ただし、db:migrate:resetしても良いような時期（公開前）はスキーマの変更がものすごくたくさん発生するので、Migrationファイルは大量にできてしまいます。
公開もしてない仕様も固まってないような開発の初期からMigrationを使うとMigrationのバージョンがあがりすぎて、どのMigrationでどうSchemaが変更されているかがわからなくなってきたりします。migrationファイルが100個ぐらいになってくるとスキーマの変更を追っていくのがかなり大変になります。
そういうのを避けたい場合には最初に設計図とスキーマ(後のdb/schema.rb)を一致させておくというのは頭の整理に多少役立ちます。
あと、Railsの場合、ほとんどの人が一人で開発したりするんじゃないかと思ったりするんですが、複数人で開発する場合には、初期の意志疎通には図があると重宝します。
なお、私もこの通りにやっているばかりではなく、その辺は臨機応変です。WindowsやUbuntuでEclipseを使ってたときはClayも動いたけど、最近はCentOS上で開発することが多くて、CentOSでは動いてません。（Javaのバージョンとかその程度だとおもうんだけど、調べてません。）
何年もEclipseを使ってますが、Eclipseのプラグインのなかではできの良いDB設計ツールだと思います。
CentOS環境でeclipseがうまく動かない件
下記、解決しました。
（ http://d.hatena.ne.jp/yotena/20080702/1215121882 )
追記：
あー。やっぱだめだ。やっぱ、CentOS 5.1まで戻したほうが早い気がしてきた。eclipse使った開発環境だけが問題なだけだから運用環境は問題ないけど。
CentOSが5.2にアップデートしてしまってからだと思うんだが、CentOS上の開発環境のeasyeclipse(for LAMP 1.2.2.2)が起動中、操作中など、以下のようなエラーコードを吐いて頻繁にアベンドしてる。弱った。本番環境がCentOSなので開発環境もCentOSのデスクトップにしているが、もう無理かな。エラー内容はのような内容で、起動パラメータ(メモリサイズなど)を変更すると発生するタイミングが変わったりするのでメモリがらみだと思われるんだが、結構いじった結果お手上げ。
デスクトップだとUbuntuが多いみたいだけど、本番のCentOSに合わせたいんだよな。エラーコード
JVM terminated. Exit code=127 /home/yosinori/tools/eclipse/lamp1222/./jre/bin/java -Xms128m -Xmx512m -XX:MaxPermSize=128m -jar /home/yosinori/tools/eclipse/lamp1222/./startup.jar -os linux -ws gtk -arch x86 -launcher /home/yosinori/tools/eclipse/lamp1222/./eclipse -name Eclipse -showsplash 600 -exitdata 15800a -vm /home/yosinori/tools/eclipse/lamp1222/./jre/bin/java -vmargs -Xms128m -Xmx512m -XX:MaxPermSize=128m -jar /home/yosinori/tools/eclipse/lamp1222/./startup.jar
http://forum.java.sun.com/thread.jspa?messageID=10035446&tstart=0
によると、CentOS 5.2ではxulrunnerというものがわるさしているらしいです。
xulrunnerを再インストールすればいいらしいのですが、xulrunnerを削除するとfirefoxが削除されるので念のためfirefox関係の匱ようなものはバックアップしておきましょう。
sudo yum -y remove xulrunner
{中略}
=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
xulrunner i386 1.9-0.beta5.6.el5 installed 24 M
Removing for dependencies:
firefox i386 3.0-0.beta5.6.el5.centos installed 10 M
yelp i386 2.16.0-18.el5 installed 2.0 M
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 3 Package(s)
CentOS環境
CentOSが5.2にアップデートしてしまってからだと思うんだが、CentOS上の開発環境のeasyeclipse(for LAMP 1.2.2.2)が起動中、操作中など、以下のようなエラーコードを吐いて頻繁にアベンドしてる。弱った。本番環境がCentOSなので開発環境もCentOSのデスクトップにしているが、もう無理かな。エラー内容はのような内容で、起動パラメータ(メモリサイズなど)を変更すると発生するタイミングが変わったりするのでメモリがらみだと思われるんだが、結構いじった結果お手上げ。
デスクトップだとUbuntuが多いみたいだけど、本番のCentOSに合わせたいんだよな。
エラーコード
JVM terminated. Exit code=127 /home/yosinori/tools/eclipse/lamp1222/./jre/bin/java -Xms128m -Xmx512m -XX:MaxPermSize=128m -jar /home/yosinori/tools/eclipse/lamp1222/./startup.jar -os linux -ws gtk -arch x86 -launcher /home/yosinori/tools/eclipse/lamp1222/./eclipse -name Eclipse -showsplash 600 -exitdata 15800a -vm /home/yosinori/tools/eclipse/lamp1222/./jre/bin/java -vmargs -Xms128m -Xmx512m -XX:MaxPermSize=128m -jar /home/yosinori/tools/eclipse/lamp1222/./startup.jar
よくわからないが…
Rails 2.1: Time zones, dirty tracking, gem dependencies, caching, etc
Rails 2.1: Time zones, dirty, caching, gem dependencies, caching, etc
ついに出たみたい。2.0が出たときはRCの時からチェックしてたけど、今回はさすがにそこまで大きくは違わないだろうと思い未チェック。今開発用のVMWareイメージをバックアップ中。今週時間が取れたら試す予定。
Railsのフォーム入力チェックの見せかた
大した話じゃないけど。
Railsで、フォーム入力チェックのエラー結果を表示する時、デフォルトのメッセージを表示すると、divで囲まれたりするので、「URLを入力してください」的なフォームで
http://<%= f.text_field :url %>
なんて入力させる画面を作るとエラーが起きたときに
http://<div class="fieldWithErrors">
<input id="page_url" name="page[url]" size="30" value="" type="text">
</div>なんて醜いことになるので、
.fieldWithErrors textarea, .fieldWithErrors input {
border: 3px solid red;
}
div.fieldWithErrors {
display: inline;
}とするとよいという自分用のメモ。Tips。いままでかなりめんどくさいことしてた。
acts_as_taggable_reduxのtag_listメソッド
以前、以下のエントリーにて結構いじって自分用にカスタマイズしたacts_as_taggable_reduxだけど、昨日、ふと気づいたのでさらに修正。
（以前のエントリー： http://d.hatena.ne.jp/yotena/20071217/1197901746 ）
動きとしては修正後のほうが正しいと思う。たぶん普通の人にとっては...。
オリジナル
def tag_list(user = nil)
unless user
tags.collect { |tag| tag.name.include?(" ") ? %("#{tag.name}") : tag.name }.join(" ")
else
tags.delete_if { |tag| !user.tags.include?(tag) }.collect { |tag| tag.name.include?(" ") ? %("#{tag.name}") : tag.name }.join(" ")
end
end修正後
def tag_list(user = nil)
unless user
tags.uniq.collect { |tag| tag.name.include?(" ") ? %("#{tag.name}") : tag.name }.join(" ")
else
taggings.find(:all, :conditions=>['user_id=?', user.id]).map { |tagging| tagging.tag }.uniq.collect { |tag| tag.name.include?(" ") ? %("#{tag.name}") : tag.name }.join(" ")
end
endその他の改造部分については、以下参照
WYSIWYGエディタ
バリアフリーグルメ情報検索Quuzu.jpのtextareaをWYSIWYGにしたいなと思っていたので、少し検討中。まだ本番環境には適用していないけどいろいろメモ。
ある程度メジャーなWYSIWYGエディタを見ているとTinyMCE、FCKeditor、openWYSIWYG、nicEditなどがいろんなところで紹介されていました。
ひととおりダウンロードして内容をチェックしてみて結論から行くと、今のところはnicEditがいいかなと考えている。以下、nicEditを選択した理由をば。
選択理由
nicEdit
http://nicedit.com/
軽量！特にアイコン画像が1枚のGIFだけで収まっている(クライアントサイドだけで必要な部分だけを表示している)ことや、JSも1ファイルのみ。
safariサポート。
また、本体のJavaScript本体をいじらなくても使用する機能のカスタマイズ（選択）ができる仕組みはうれしい。ほかのWYSIWYGエディタは基本的にカスタマイズのために、JavaScriptをいじらないといけないような気がする。
ただし、シンプルなだけに、変な制約と重要な制約もある。
変な制約の方は、ctrl+zが効かないのと、縦スクロールバーが表示されないのでtextareaが縦に長くなるとどんどん拡大されてしまう（これはこれで結構使いやすい）みたいです。
あと、もうひとつ重要な問題は、textの装飾がすべてstyle属性で付けられること。TinyMCEではこの部分はオプションで設定できることになっている。セキュリティ上あまりユーザの入力したタグに属性を追加させたくない（ほとんどの）場合に頭を悩ませることになる。自分専用のサイトの管理画面にのみ使うのだったら全く問題ないのではないかと思われる。
openWYSIWYG
http://www.openwebware.com/products/openwysiwyg/
nicEditの次の候補です。バージョンアップしたらまた試してみたいです。
多機能かつ比較的軽量。
Firefoxなどの動作バージョンが1.0以上というのはかなりサポート範囲が広くてうれしい。
だが、safari、operaサポートなしらしい。実際operaで使うと、結構不安定だった。
おそらくカスタマイズはソースに手が入る。
TinyMCE
*** TinyMCE、FCKeditor
多機能なのはよいが、そこまでは不要だった。あと重い。
カスタマイズまでは試してない。
多機能、そこまでは不要だがシンプルな機能セットも用意されているので、少ない範囲で使う分にはかなりよい。
デフォルトでは、強調表示はstrongタグ、イタリック体はemタグだが、アンダーバー、取消線などがspanタグのstyle属性にtext-decorationなどを設定する形になっているため、ユーザからの入力を受けるためにエディタを使うためには多少カスタマイズが必要。
ただ、カスタマイズもある程度、外部から引数でセットできるのでやりやすい。
というわけで、候補として急浮上。
FCKeditor
未使用だがデモを見る限り重そう。
雑感
複雑な機能が活躍するのは全体の要件の1割。「主要な9割がうまくできているように」という力の入れ具合はセンス。やはり、軽量シンプルは何にも勝る強さだとおもう。
nicEditの良さは、まさにシンプルさとソースに手を入れなくてもいい部分。
バージョンアップの度に開発者が新しいソースをいじらないといけないのは無理。
ただ、こういった一般的なWYSIWYGエディタは通常のhtmlのtextareaタグに後付けでつけるものが主流のようなので、ひとつのプロダクトにこだわらずに今後もいろいろチェックしては試してみたい。
ところでnicEditの作者もかなり若いね。この辺は若い世代のセンスなのかもと感じてしまうところがある。
GWなんでゆっくり時間をかけて検討しなきゃいけないなと思っていたことをやりたいとおもいつつ、あんまりたいしたことができていない...。
