1. Ruby on Railsでなければできないことは実は無い “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” 2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要 OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長 DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い IT’S SMALL AND FAST
5. phpは自分好みにいじれる IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった PROGRAMMING LANGUAGES AR
翻訳 (スコア:5, 参考になる)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
2. 社内にPHPの利用者が多く、Railsに移行するには再教育が必要
OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
3. Railsは冗長
DON’T WANT WHAT I DON’T NEED
4. phpは小さくて早い
IT’S SMALL AND FAST
5. phpは自分好みにいじれる
IT’S BUILT TO MY TASTES
6. phpだと自分でSQLを書ける
I LOVE SQL
7. Ruby on Railsを学んだことでphpでもっといいコードが書けるようになった
PROGRAMMING LANGUAGES AR
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
“IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
PHPとRubyの対比という全体的な意味で捉えると、
この文には「PHPでのオブジェクト指向」なども含まれてるのかな。
個人的には、何でもオブジェクト化する必要は無いと思ってます。
特にWEBプログラミングは、文字列操作と組み込み型(リスト、ハッシュ)操作、
共通部分の関数化で済んでしまう、わりあい平坦な構造のプログラムが
多いです。こういうとき、OOPは単に冗長なことが多いです。
名前空間としてOOPするなら別ですが、本格的なOOPの導入は、
手続き型のコードでは可読性が損なわれてしまう程度に
複雑な処理が必要になってから考えればいいことだと思います。
その場合でも、ライブラリだけOOPするとか、段階的な
導入のほうが上手くいくと思います。
金槌で全てを叩くだけが方法ではないのです。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:2, 興味深い)
いろいろ反論ありそうですが。私も同感です。
私も(職業ではありませんが)大きなプロジェクトになりそうなものは
OOPで作り始めました。必要なライブラリもOOPで拡張するようになっ
てましたし、PHPのオブジェクトは書きやすいから好きでした。
(モノにはなりませんでしたが)
一方、つい最近、ごくごく簡単なPHPスクリプトを作りました。
HTMLとPHPが混じった綺麗とは言い難い内容ですが。
ニーズが少なすぎてメンテする人さえいない状態で、
とりあえず動くモノを早く提供する事が大切という点では、
OOPにこだわらずに作るのもアリだと思いました。
いくつかfunctionは使ったので、classにまとめることも
できたんでしょうけど。そこまでの必要性が無かったから
しなかった。それだけのこと。
#以上、チラシの裏でした
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
個人的には必ずしも OOP である必要は無いというのは同意するけど、OOP で書きたいと思ったときに
書くのが面倒な言語ってのも非常にストレスがたまる。なもんで、短いものなら関数型っぽく書けるし
基本的には OOP として書ける ruby は非常に楽。Python も悪くない。
Perlは手付にはいいんだけど書きつづけてくと自分が書いたコードが意味不明になってくんだよな。
いやもちろん Perl だけが悪いわけじゃないけど。
PHPにはできるだけ触れないように生きているので省略。言語自体を批判する気は全然ないけど、
毎週のように脆弱性がボロボロ出てくる言語でWebサーバを公開したくない。最近はそうでもないのかな?
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
Perlは以前試したけど、他人のソースを見ても、全く勉強にならずに挫折した。
それに、webとのやりとりで(なぜか)苦労したので使わない。
うちの場合、ローカルで動かす物ばかりなので、脆弱性うんぬんは関係ないのです。
は、PHPでも同じような。というか、どれでも出来そう。
私の場合、PHPなら出力が自動的にwebベースで出てくるのが非常に楽。
Cocoa(つーか、Interface Builder)やDel
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
Webアプリ程度のものでいいならWebアプリのエンジンを使うと結構楽そうです。
Ajaxだと多少複雑になりますが、まあなんとかなるか。
Flashあたりだと(バックエンドは)もっと複雑に成り得ますね。
もちろんクライアントが高機能化すればするほど、
サーバは楽をできるという面もあるんですが、
高機能なクライアントからの要求は「ときどき」複雑になります。
JSなしのWebアプリみたいに「ダム」な画面だと、
クライアントが複雑な要求をするということは有り得ないですが、
ダムでないクライアントは、何を要求してくるかわからない。(そのぶん色々やれます)
ところでJavaAppletなんかいかがですか?
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
Ajaxって「見栄えを良くする」方法に過ぎないと思うんですね。
webアプリを売り物にしてる人にとっては、客にアピールできるんだろうけど。
自分で使う物にはあんまり必要ないと思う。
Flashは紙芝居を作って遊ぶのに使ってます。HyperCardの代わりって感じ。
(本当は、HyperCard大好き! でも、真に置き換えになる物は見つからない)
Javaはいろんな意味でダメでした。理由が多くて書き切れません(笑)
Ruby on Railsは、以前Macへの導入の敷居の高
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
私はAjax…というかJSを使うこと…ではっきり変わり得ることといえば、
MouseMove(とかDragとか)が取得できるようになること、だと思っています。
なので、MouseMoveを活用して何かをやりたい(やらせたい)人でなければ、
たしかにAjaxは「xxxに過ぎない」でしょうね。
Flashとの違いは突き詰めれば効率というか処理速度でしょうね。
JavaAppletについては、最近出てきたJRubyやJavaFXでなら、まだしも楽に開発できるんじゃないか?と少し期待しています。起動が遅いことについては(ry(言葉を濁す
>本当は、HyperCard大
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:1)
というか、RoRが魅力的に見えたのは、私の場合にはもっと基本的な所で、
「データベースにテーブルを作れば、データの入力・編集の部分は自動生成
される」って所です。テーブルを追加すれば、それなりにしてくれるし。
PHPでもPEARや何かを使えば、そうなるんでしょうけど。決定版が無い感じ。
また、HTMLとPHPの混在って(書き方にもよりますが)、まだ共存できてる
感じがするけど。SQLって言語は、PHPの中にいる場所が無いって感じがする。
具体的には、ダブルクォーテーションの中にSQL文を書くのが、分かりに
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
たとえばDelphiのDBコンポーネントも、多分そんな感じでした。
DB定義
↓
コンポ(Tableに一対一対応する非表示型コンポと、UIになる表示型コンポと)をWindowデザイナ上のWindowに貼る。
非表示型とUI型とが一体じゃなく役割分担してるのがDelphi流儀。
↓
Delphiを(正確にいえば上で貼ったコンポを)DBに接続する。
デザイナ上(実行前)でも接続できちゃうのが奇妙というか便利というか。
↓
コンポのプロパティをいじる。
Tableコンポは接続するTable名とか(望むならWhereとかも)をプロパティで設定。
UIコンポはどのTableコンポと「接続」するかをプロパティで設定。
このとき、
Table名やTableコンポ名は、手入力する必要はなく、DropDownListなプロパティで選択できる。
Table名は(上で接続したおかげで)DB上のリアルなテーブル名が選択肢として挙がるし、
Tableコンポは同じWindowに貼った奴が選択肢として挙がる。
(手入力したければしてもいい)
↓
はい。できあがり。
F5(もとい、DelphiならF9だ)を叩いてコンパイルすれば、数秒後に出来上がり。
(Delphiはコンパイル速いので、ほんとに数秒です。)
これでとりあえずテーブルをCRUDできるアプリになってる。
親子関係などのある複数テーブルからなるアプリでも、
Tableコンポ同士(だったかな…詳細忘れた)に
関連を定義するようにプロパティを設定すれば、
これまたワンタッチで出来上がり。
>バックグラウンドにフィールドを配置すれば、できあがり。
RDBが絡むと流石にそこまで簡単にするのは難しそうですが、
RDBが絡んでも上記のようにある程度簡単にやる道が有るようです。
この環境に95年(Delphi初代が出た年)から慣れてた私としては、
Railsの「すきゃふぉーるど一発」という売り文句を聞いても、
「うーん。それなら10年前から有るよね」
が感想でした。
そういえば以前
「Swing Hacks」というJava Swingのネタ本を買ってみたんですが、
データベース(JDBC)にGUIベースでアクセスするHack(?)の例として、
データを「表示」するだけのアプリの作り方までしか紹介されてませんでした。
がっかりしました。
Swingにおいては、DB更新系アプリは、ワンタッチどころかHack(濃いやり方)としてすら「簡単には書けない」部類になってしまうのですね。
たとえばこのDelphiのようなDBアプリ開発環境が、もっと色々な場所というか、色々な「言語」に、広まって欲しいなと思います。
上記はDelphi言語でないと実現困難な面など殆ど無いです。たぶん移植可能。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
中身スカスカで正直びっくりする。
テクニックではなくて標準APIの使い方だけの説明がほとんどってどういうことよ。
通常SwingコンポーネントとDBの接続方法としてはBeansとのBindingライブラリを使って接続、JPAなどBeansとO/Rマッパで接続、というのが普通だと思います。
JBuilderはDelphiやBCBと同じコンポーネント構成です。ぽとぺたでできます。そのかわり開発環境がJBuilderに縛られ続けるので、パッケージ構成がころころかわるJBuilderはつらかったです。JBuilder6くらいまではかなりよかったのですが。
ですから、Javaでは、というのはあてはまりませんね。