|
本当は、先週発売されたＤＳ版「狼と香辛料」について書こうと思ったのですが、
まだクリアしてないので、関連で別なネタ ＲＯのＢｌｏｇの方で、「ＲＯ的占星学」の連載を始めてますが、 それに関連して、「狼と香辛料」の「ホロ」は何座なのかなと、 いろいろ考えてみたわけです こちらでこのネタはあまりにいきなりすぎるのですが、 忘れないうちにガリッと書かせてください(´･ω･`) 解説は吹っ飛ばしていきますので、わからなければ別途質問を まず、４属性で何に分類されるかを考えていきます ホロの特徴として、なんといっても知的であることが挙げられますが、 同時に会話のテンポの速さも特徴的です よって、同じ理詰めであっても、 「考えすぎて会話がワンテンポ遅れる」地の星座は該当しないでしょう 次に、会話といえばコミュニケーションが得意な水の星座が考えられますが、 もし蟹座的な自己防衛が強ければ、 出だしのシーンであんな無防備な姿はさらさないはず かといって、蠍座的な微妙な暗さや独特のこだわりもなく、 魚座的なとらえどころのなさも見られません （わりとはっきりと物を言う） 残るは火の星座か風の星座になりますが・・・ 牡羊座のように直情的というほどではないし、 獅子座ならば恋愛的な言葉遊びはできないはず （ど直球を投げることしか知らない） 射手座はわりと怪しいラインですが、 かなり気まぐれというか、気分が変わりやすいのも射手座の特徴です 射手座であれば、過去の約束を律儀に守らないかもしれないし、 なにより「裏切られた」こともすぐ切り替えていくように思います なので、射手座もない・・・と 残るは風の星座になりますが、まず天秤座的な怠惰感というか、 ある種の「けだるさ」（めんどくさーい的な）がないので、 天秤座は消えます かといって、水瓶座的な、ある種「天然」っぷりもないです 水瓶座だともうちょっとマイペースというか、 あそこまで切り返しが速くないかなと というわけで、残るは双子座になりますが、 これはかなりいい線いってます 明るくパワーがあり、どことなくクールに見られがちだけど、 実際は愛嬌で勝負するタイプ その名の通り、一人で行動するのは嫌いで、 何より会話のペースが速い（切り返しが高速） 何事も器用にこなしますが、 それゆえに「便利屋」に扱われてしまうのが損をするところ ストーリーにもその特徴が出ていて、 「便利屋」に扱われた結果、徐々にありがたみを忘れられてしまい、 最終的に頭に来てしまったわけですね （獅子座だと、どんどん株を上げることになるのですが・・・ 良くも悪くも「重さ」がなく、「軽い」ことが影響しているんですかね？） というわけで、「ホロ」の行動パターンは「双子座」と判断します(`･ω･´) ・・・まあ、興味ないですよね(´･ω･`) |
|
例の本を読んだおかげで、
だいぶRailsの仕組みがわかりました(｀･ω･´) ｂ （結局のところ、ものすごくシンプルなＭＶＣであるという・・・） Railsの生成したコードだけ見ると、 あまりに省略されすぎで、かえってコードが追いづらいのですが、 この本はその「隠された部分」を明示するように解説していて良いです ただ、基本的なことに絞って解説されているので、 「何ができるか」というリファレンス的な部分が甘いですが、 逆に「基本」を徹底して書かれているので、１冊目としては最適です まあ、そんな感じでRailsが見えてくると、 当初懸念していたものに対する回答も見えてきました ・セッション管理 Railsはセッション管理の仕組みを持っている （専用のDBテーブルにデータを格納する仕組み） ・MySQLの暗号化関数を利用したフィールドへの対応 たぶんできるが、確実に手間である そもそも、自分のシステム（というかフレームワーク）の方向性として、 特定のOS・サーバ・DBに依存しないというものがあるので、 MySQL固有のコードを記述していることそのものが問題 よって、Railsと関係なく、ダイジェストを使った格納に変更 ダイジェストであればRailsでも利用可能 （Railsというか、Rubyのライブラリとして存在） ・スケルトンからユーザ権限別のUIを作るのは、一から作るのとどっちが早いか？ セッションが使えるため、権限に応じたViewに振り分けは簡単 こうしてみると、何一つ問題がないように見えますが、 最大の問題は・・・ 既存のDBからコードを起こすのが手間（再設計が必要になる） ・・・ってことでしょうか まず、プライマリキーの変更が面倒です これ自体はできるのですが、 生成されたコードをいろいろいじる必要があるのと、 URLにプライマリキーの値が入ってきてしまうのが一番怖いです また、Rails1.0ならともかく、2.0を基準に考えた場合、 DBの構成に合わせた引数をコマンドに与える必要があります DBのハンドリングをRailsで行うため、 既存のDBを壊さないようにいろいろ変更を加えるのが、 無理とは言いませんが、リスクが高めです 結局のところ、すでに動いてしまっているシステムに対して、 特定の部分だけRailsというのはわりと難しいのかなと できない、とは言いませんが、わりと大掛かりに手を加えることになると、 それはもはや「Railsを使うこと」が目的になってしまい、 手段が目的化してしまってよろしくないように思います すでに他の言語でシステムが動いているならば、 その言語で追加するのはシステム設計上当然であり、 無理矢理Railsを使おうとすると、かえって工数がかかるのかなと このあたり、DBからViewまで一貫してハンドリングするRailsの、 強みでもあり、弱みでもあるところですね 要は「銀の弾丸」にはならない、ってことです まあ、今回の場合に限れば、「Railsを試すこと」が目的なので、 いろいろやってみてもいいのですが、 それが他のシステムで役に立つかというとちょっと・・・ というわけで、作ろうとしていた機能は予定通りJavaで組んで、 Rails用には別のシステムを割り当てることにします 問題は何を作るか、なのですが・・・ |
|
先日、初めてRailsを試したときには、
2.0でインターフェースが変わったのを知らず、 動かすまでにえらく時間がかかりました(´･ω･`) （しかも、困ったことに、つい最近2.1が出てしまったようで・・・ 自宅で環境を作ろうとしたら、gemで2.1が入ってきてあせりました） そんなわけで、私がつまづいたポイントを具体的にメモしておきます ○scaffoldを作る手順が違う たぶん、有名ニュースサイト等を見てRailsを始める場合、 一番最初につまづくのがこれです ＜1.0の手順＞ １．DBにテーブルを定義する ２．「ruby script/ganerate scaffold hogehoge」を実行 ３．database.ymlを書き換える ４．サーバ起動 ＜2.0の手順＞ １．「ruby script/ganerate scaffold hogehoge name:string job:string age:integer...」のように、データ構造を一緒に渡す ２．database.ymlを書き換える ３．rakeでDBの「マイグレーション」をする（要するに、DBテーブルをcreateする） ４．サーバ起動 大きく違うのは、DBを定義してそのデータ構造からscaffoldを作るのではなく、 scaffoldであらかじめデータ構造を定義し、 それを元にDBを作るという仕組みに変わっています また、DBの定義を変える場合も、rails側でコマンドを発行して、 DBのマイグレーションを行うという手順になります つまり、データ構造のハンドリングをするのが、 DBからRailsに移っているのが2.0の特徴といえます ○作られるコードが全然違う 1.0に比べて、2.0で生成されるコードは、 明らかにコード量が減っています これはとてもすばらしい変更なのですが、 逆を言えば、慣れない人間からすると、 どこで何をしているのか読み解きにくいとも言えます その他、2.0から2.1になって、 マイグレーション定義のファイル名が変わっていたりしますが、 それは「一から学ぶ」上ではあまり関係ないかな・・・ こんな感じでかなり手順が変わっているので、Railsの情報を集める場合は、 どちらのバージョンで書かれているか確認した方が良いでしょう （何も書いてないとか、2007/12以前だったら、確実に1.0系です） 今回のラストに、Amazonで私が注文した本と、 先日も紹介したサイトをもう一度 はじめてのRuby on Rails 2 Amazonで見る限り、さすがに2.0系に対応した本は少ないのですが、 早くも対応済みで、しかも初心者向けに書かれているようなので選びました 評価も悪くないですしね たぶん、本格的に使い始めると物足りないと思いますが、 私のレベルならばこれくらいから始めるのがいいのかなと Ruby on Rails 2.0 チュートリアル 非常にわかりやすくRails2.0でのアプリ構築について書かれています しかも、実用的なテクニック（セッション管理だとか、PASSのハッシュ化だとか）が 書かれているのも高ポイント RedRails(Aptana) Eclipseベースの無償IDE「Aptana Studio」を公開しています これのプラグインが「RedRails」で、 これがあるとRailsに関するほとんどの操作をGUIで行えます 一応、既存のEclipseにプラグインベースでインストールもできるのですが、 Eclipseのインターフェースを激しくいじられるので、 「Aptana Studio」を別途インストールした方が無難かと この場合でも、日本語化には「Pleiades」が使えますが、 いつものようにconfigに追加すると、 スプラッシュがPleiadesのものになってしまいます これをAptanaにしたい場合は以下に変更で -javaagent:plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar=default.splash （どこで拾った情報だか失念・・・(´･ω･`)） こんな感じで情報を集めたり、環境を作ったりするうち、 この前挙げた「引っかかること」のうち、 一番やばいものに引っかかっていることに気づきました 次回はそのお話 |
|
数分でBlogが作れると評判のRails
今日は仕事と平行して環境を作り、動作させてみたのですが・・・ ・・・動くまでに６時間かかりました(´･ω･`) とりあえず、以下のサイトを追加して、 RedRailsをEclipseに入れるまではＯＫ http://update.aptana.com/install/3.2/ http://update.aptana.com/install/rails/3.2/ 致命的だったのは、Rails1.x系と2.x系でscaffoldの作り方が違ったこと 有名サイトの記事はどれも1.x系を元にしていたため、 そのままトレースしてもうまくいかなかったのです でも、以下のサイトを見つけて、それで応用したら、 本当に５分でマスタメンテ的なものが動きました Ruby on Rails 2.0 チュートリアル 要は、DBテーブルを先に作っておくとダメだったって事なんですけどね このあたりの動きが2.0では違っていたようで 上記のサイトは非常に良くできていて、 かなり本格的なサイト構築を例にまとめてあるので、 ここを読むだけでたいていのことはできるかと 他にもいろいろわかったのですが、細かいことはまた後日・・・ |
|
前々から気にはなっていた「Ruby on Rails」（RoR）ですが、
週末に見たこの記事をきっかけに、 本気でいじってみようかと思い立ちました Rubyは10年前のJava － ＠IT 幸いなことに（？）、Ｇｖ管理システムのユーザ管理機能でちょっと悩んでいたので、 試すにはちょうど良いかなと というのも、基本的にはマスタメンテナンス系の機能なのですが、 いちいちFlexで組むとちょっと重かったので、 ピュアJavaで書こうかと思っていたので、これをRoRで書いてみようかなと 「Blogが数分で作れる」というふれ込みのRoRですが、 私的にはいろいろ懐疑的でした 確かに、DBの構成からスケルトンを作れるのは便利ですが、 細かいことをやろうとしたときに、 果たしてこのスケルトンがどこまで役に立つのかなと それの検証の意味も含めて、 先ほどの機能をRoRで書いてみようと思ってます たぶん、引っかかると思うのはこのあたり ・セッション管理をどうするか？ →ログイン情報をクッキーやhiddenタグを使わず維持できるか？ ・ユーザのPASSはDBに暗号化されて格納されているが、 このデータを正しく更新できるのか？ ・スケルトンからユーザ権限別のUIを作るのは、一から作るのとどっちが早いか？ ぶっちゃけ、自分のフレームワークを使えば、 このあたりはさくっとできる部分ではあるのですが、 RoRで実際のシステムを組むことで、ある程度勉強になるかなと まずは環境からか・・・ |
