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への導入の敷居の高さで挫折した・・・んだけど、
TigerにはRubyが入ってるのね。問題はMySQLか(起動が遅くなるので
あんまり入れたくないんだよね・・・)
素のPHPだとSQLの発行が面倒だったりするんで、データベースが必要な
用事があったらRoRを試すのもアリかもしれない。
PHPの、Railsもどきのフレームワークに決定版があれば、それもいいけど。
#ああ、完全にチラシの裏だわ
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文を書くのが、分かりにくい。
> $a = "SELECT * FROM hoge WHERE name = 'poge';"
みたいに。文字列を繋げて、繋げて、長いSQL文(配列)になると、間違いを
探すのが大変だし。エラーの戻り方もPHPからかけ離れてくる。
↑
この不満をなんとかしようと、ライブラリを使ってみたけど、そんなに
便利になった気がしないので。結局そのままSQLを書くか、(データベースを
使わないで)直接ファイルに読み書きする方を考えちゃう。幸い、私が作る
ような物はパフォーマンスとか考える必要が無いので、それで十分なのです。
余談ですが。HyperCardでデータベースを作る場合。
バックグラウンドにフィールドを配置すれば、できあがり。
カード型データベースなんで、当たり前と言われそうですが。
FileMakerよりも簡単。
つまり、入れ場所のテンプレートさえ作れば、その入出力/編集の
基本的な部分のコードを書かなくていい、というのが私の望み。
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
たとえばDelphiのDBコンポーネントも、多分そんな感じでした。
DB定義
↓
コンポ(Tableに一対一対応する非表示型コンポと、UIになる表示型コンポと)をWindowデザイナ上のWindowに貼る。
非表示型とUI型とが一体じゃなく役割分担してるのがDelphi流儀。
↓
Delphiを(正確にいえば上で貼ったコンポを)DBに接続する。
デザイナ上(実行前)でも接続できちゃうのが奇妙というか便利というか。
↓
コンポのプロパティをいじる。
Tableコンポは接続するTable名とか(望むならWhereとかも)をプロパティで設定。
UIコンポは
Re:翻訳(「1.Ruby on Railsでなければできないことは実は無い」とOOPの考察) (スコア:0)
中身スカスカで正直びっくりする。
テクニックではなくて標準APIの使い方だけの説明がほとんどってどういうことよ。
通常SwingコンポーネントとDBの接続方法としてはBeansとのBindingライブラリを使って接続、JPAなどBeansとO/Rマッパで接続、というのが普通だと思います。
JBuilderはDelphiやBCBと同じコンポーネント構成です。ぽとぺたでできます。そのかわり開発環境がJBuilderに縛られ続けるので、パッケージ構成がころころかわるJBuilderはつらかったです。JBuilder6くらいまではかなりよかったのですが。
ですから、Javaでは、というのはあてはまりませんね。