生き残るフレームワーク、どうすれば選択できる？ 145
選択 部門より
私は小さなソフトウェア開発会社で指導的立場にあり、購入を含めてツールの選択にも責任がある。しかし、チームで使用するフレームワーク、特にUIフレームワークを選択するのは非常に難しい仕事だ。数年前、将来のWeb開発に向けてリッチインターネットアプリケーションフレームワークを選択した際、自分の調査ではAdobe Flexが最適と思われた。AdobeがLinuxバージョンのFlashを廃止することが想像できなかった頃の話だ。当時HTML5は初期の計画段階だったのに対し、Flexは完成度が高く、ドキュメントも豊富な商用製品であり、Flashを使用するための優れた機能が搭載されていた。そのため、Flexを選択したが、現在では開発が停止している。逆に、15年前にデスクトップアプリケーションをQtに切り替えたが、こちらは現在も広く使われている。そこで、私は正しい選択と誤った選択の違いを見出したいと思っている。Qtは設計がよくできていたのかもしれないが、私の評価が正しいかどうかはわからない。今のところ、自分の経験をもとにした長期にわたって使用できるツールの選択を助ける適切な決定木はみつかっていない。このことについて、尊敬する/.諸氏から役立つ情報が得られるのではないかと期待している。失敗のない原則を見つけることは可能だろうか。
(続く...)
当時はAdobeのような大企業の製品がオープンソース化されるとは思わず、Flexには多額の投資をした。しかし、数年後にFlashのLinuxサポート終了が発表され、投資は無駄になってしまった(今回の議論とは無関係なので理由は説明しないが、うちの会社ではLinuxサポートが非常に重要だ)。Adobe Flexと前後して、FlashとDHMLを切り替えて出力可能なOpenLaszloも試していた。今となってみれば、当時の印象とは異なり、こちらのほうがよい選択だったような気もする。 同じようなことは、クラシックPHPにかえて選択したCodeIgniterでも起こっている。CodeIgniterを使うためにTesla Model Xが買えるほどの金額を投資したが、現在では開発元のEllisLabが売却先を探している状況だ。
現在もPHPフレームワークとしてLaravelを押す人や、他の提案をする人がいて、私は再び岐路に立たされている。そのため、起こり得る将来の失敗をどうすれば避けることができるか悩んでいるところだ。実際のところ、ツールが生き残るかどうかを予測するのは不可能なことのようにも思える。過去の決定の中には失敗したものもあるが、再考してみると当時はすべてが適切な選択だったと思われるのだ。
そんなものが確実に予測できるなら (スコア:4, すばらしい洞察)
ITエンジニアなんかやってないで株買って大儲けできるよ。
わからない (スコア:3, 興味深い)
JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。
JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん MEAN Stack [youtube.com] が最高に近い形に見えます、が、Dart だの、Type Script、オフラインアプリケーション、いろんな方向から新しいコンセプトが次々出てくるときになにが最善かわかりようがない。
（その点、iOS や Android は簡単でいいですね。ＯＳが提供する API を使う以外に選択肢がない。はっきりしていていい）
Re: (スコア:0)
> JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。
それはないです。
見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、
JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。
特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし
相手のブラウザにはなるべく仕事をさせない必要があります。
これはビジネスの話ですので、実装の都合などより上のレイヤーです。
Re:わからない (スコア:2)
JavaScript に頼った実装で問題ない、というのがここ五年間の中で理解しなければならない重要な変化だと思います。ブラウザ変更で動きが大きく変わるというのは、過去の話。さすがにもう PHP は要らないと言わせてください（笑）
Re:わからない (スコア:2)
JSのひとつの問題としてセキュリティがあります。
つまりユーザー側でコードや変数の書き換えが好き勝手にできる。
ゲームで言えばチートし放題。ChromeにはJSコンソールというチート機能が標準搭載。
そこで質問ですが、JSオンリーで書かれたネットバンクサービスとか、使いたいですか？
Re:わからない (スコア:1)
JSだろうがHTMLだろうが、結局HTTPしゃべってるだけなんだから、
そんなん自由にユーザ側で書き換えできることに大差ないだろ?
別にユーザ側から好き勝手なHTTP送られても、サーバー側のValidationが機能要件を満たしていれば関係なくね?
Re:わからない (スコア:1)
ないわー。
jQueryを使おうが、JavaScriptを使う限りブラウザ間の互換性・挙動の違いに振り回される。
ましてやPHPが要らないとか、本気で業務アプリ作ってるのと言いたくなります。
時代の変化はありますが、それが全てを解決した訳でもないし、エンドユーザーに対して「このブラウザ以外は動作しません。ご了承ください。」と
動作環境を押し付けられる訳でもない。
個人で趣味で作るようなものならともかく、対顧客ありきのシステム構築で「JavaScriptに頼ったUIが最適」とか意味わかりません。
Re:わからない (スコア:1)
IE9/10とその他のブラウザは一緒でいいだろ
Re:わからない (スコア:1)
これには反対１票
組み込み系で、複数のブラウザ＋独自機器をサポートしています。
JavaScriptに頼った場合、貧弱なマシン、独自機器での表示パフォーマンスが
極端に落ちるのが現状です。
あと、特定のブラウザでの不具合回収時の、再確認も、
サーバサイド側での対応のほうがやりやすいです。
表示がリッチになればリッチになるほど、サーバサイド側で、
必要な情報を出力するほうがよいというのが、
昨年まで作っていたシステムでの結論です。
コソコソＡＣ
Re:わからない (スコア:1)
さすがにサーバーサイド開発に、JavaScriptを使いたいとは思わないな。
型安全性さえ満足にナインだぞ。
Effective JavaScriptを読んで、ますますそう思ったわ。
Re: (スコア:0)
今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。
# 超AC
Re:わからない (スコア:1)
8年くらい前になるか、某プロバイダのWebメール新版を作るとき、Outlookを目指してAjax/JSONバリバリでやったなぁ。
Ajaxの技術書も限られてて、結構難産だったけど、動作の組み立てよりも軽量化に腐心した記憶ばかり蘇る。
それでも「重い」「使いづらい」と不評だったけど。
クライアント側はその頃からさらに代替わりしてるけど、鯖側は我々が作ったものを引き継いだと聞いた。
「ここ五年間の」ということは、やはりちょっと早かったのかな…。
Re: (スコア:0)
実用重視なら、余計にJSは使うと思うんだけど、#2485073の人は、装飾用途でのJSしか知らないのかしら。
HTMLページを一Pづつ開くより、Ajaxで必要な部分だけ書き替えたほうがずっと負荷が少ない。
Re: (スコア:0)
サーバー側は、JSONベースのAPIさえ定義できれば、比較的、UI側の人と分業がしやすいので従来よりは開発が楽になったと思っています。
いざとなれば、JSONを喋るリッチクライアントも作れますし、
セキュリティやユーザーサイドを信用できるかどうかといった議論さえしっかりできれば非常によい傾向だと思っています。
Re:わからない (スコア:1)
>+で文字列連結禁止
何年前のコンパイラ使っているの？
>継承禁止、privateメソッド禁止
え～と、JSPって出てきているからjavaだよね？
無駄に工数増やしているような……
# 関わりたくない、本気で。
notice : I ignore an anonymous contribution.
Re:わからない (スコア:1)
凄いなの意味が良い意味なら同意。
悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから
今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なので
privateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。
今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
Re:わからない (スコア:2, すばらしい洞察)
privateだからテストしにくいという時点で設計を間違えている
Re:わからない (スコア:1)
おもしろおかしいをつけたいけど、
まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が
先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。
#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな
ビジネスに合ったものを選ぶしか。あと消去法 (スコア:3, 興味深い)
1. 利用者数が少ないフレームワークは回避する。
利用者が多いのは強いです。Stack Overflowを探せばあなたと同じ悩みを抱えていたひとがきっといます。
PHPだったらCakePHPが無難でしょう。FuelやLaravelはパフォーマンスも高く、
評価も良いですが、Cakeに比べたら利用者も少ない。
同じプラットフォームであれば、Google Trendsで比べてみるのも良い手です。
2. 致命的な脆弱性が頻発するフレームワークは回避する。
保守費用に含めるフレームワーク部分の保守コストを計算してみましょう。
致命的な脆弱性が発見されると、あなたが納品した数だけコストがかかります。
分かり易く言えば、Struts2は今すぐ滅びるべきフレームワークの筆頭ということです。
3. 人員のスケールアウトに耐えられるものを。
ビジネスが拡大し、人員が増えたときのラーニングコストは馬鹿に出来ません。
ドラクエで主人公を以外を全員転職させてしまった状況を考えてください。
あまりに尖ったフレームワークやプラットフォームだと、大変困ったことになります。
少数精鋭でビジネスを展開するのであれば、そこまで気にする必要はありませんが、
チームメンバーが一人死んだとき、代わりの人材を確保するためのコストを考えておくことは有用です。
4. アプリケーションライフサイクルを考慮して。
ビジネスに最適化されたフレームワークは、ある程度の期間は高い生産性を維持できますが、
そのパフォーマンスを維持するにはフレームワーク自体をモダンに保つためのコストが高くなりがちです。
自社専用フレームワークや、既製フレームワークをごっそりとチューンしたものは3.の問題にも直結する上、
気を抜くと土台から腐っていくという大きなリスクがあります。やめておきましょう。
あたながすべきことは、候補のフレームワークのライフサイクルが自分たちの仕事のやり方にどう影響するか、
これを最初から考えておくことです。
Re: (スコア:0)
PHPやJavaのフレームワークなんてどうなるか分からんよ
ベースとなるブラウザですら一寸先は闇なんだから
あと言われんでもわかってる事を並べるのは無粋すぎる
Re: (スコア:0)
> PHPやJavaのフレームワークなんてどうなるか分からんよ
でも消去法で選択肢を絞ることはできるだろ。
PHPならSymfonyやZFのようなセンスの無い上に絶妙にモダンを履き違えたフレームワークを選んではいけないし、
JavaならSpringのような脳味噌がXMLで出来たようなクズどもが作ったフレームワークを選んではいけない。
そういうのは重要だよ。後々響くんだから。
Re:ビジネスに合ったものを選ぶしか。あと消去法 (スコア:1)
例に挙げている、Symphony,ZF,Springは淘汰されたといえず、まだちゃんとメンテされている。
それよりももっとまともな設計のものではさっさと淘汰されるのがあるから、中身だけでなくて他に何を基準にすればいいのかってことでしょ。
ないなら作るしかないだろ (スコア:2)
それがGeekってもんだろ
# と言いたいところだけど企業だとそうもいかないだろうな
# といっても5年前にもてはやされてたフレームワークでいまも生きてて今後も数年にわたってつかえそうなものを
# ピックアップしてみると何か見えるものがあるかもしれない・・・気がする・・・かも・・・
本気で付き合い続ける気があるならOSSも手では？ (スコア:1)
何言ってるんだよと言われるとは思いますが、本気で一つのフレームワークと付き合う気があるならOSSの中で選ぶのも良いと思います。
クローズドな製品と違って、OSSなら開発が止まろうとやる気にさえなれば自力でメンテすることができます。
｢CodeIgniterを使うためにTesla Model Xが買えるほどの金額を投資｣するような会社なら、自力メンテを視野に入れてもいいんじゃないでしょうか。
内製で作るよりもスタートアップのコストが削減できますし、Linuxサポートが重要になる会社ならOSSとの付き合い方にも慣れてるでしょうし。
Re:本気で付き合い続ける気があるならOSSも手では？ (スコア:1)
まあ,自社で作る云々はおいておいて,
もともとコミュニティでの開発が中心で回ってるプロジェクトなら,
個人の意向で簡単に終了はしないと思いますね.
GNUやLinuxやgtk+は,1企業の意向で終了させることはできないでしょう.
Re: (スコア:0)
そんなメンテ能力があるなら最初から自作出来ると思いますよ。
Re:本気で付き合い続ける気があるならOSSも手では？ (スコア:5, おもしろおかしい)
>> 内製で作るよりもスタートアップのコストが削減できますし
だから3行以上あっても最後まで読めよ
Re:本気で付き合い続ける気があるならOSSも手では？ (スコア:1)
きっちり4行目を読んでないのがうける
Re:本気で付き合い続ける気があるならOSSも手では？ (スコア:1)
それやるとその時点でクズでも何とか読む貴重な1行使っちゃうしねぇ
しかもやはり3行目以降は読まない。
分からないということを分かるべき (スコア:1)
世の中は、長期的に安定した流れがある一方で、時々ブレークスルーのような不連続的な変化があるので、確実に予測することは難しい。
だから、どのフレームワークが生き残るかは分からないという前提で、設計をするべきである。
デザインパターン等で、フレームワーク部分依存とそうでない部分を分離することは技術的に可能であろう。
ただ、検討した結果、フレームワーク依存しかないというなら諦めるしかない。それは、他人のふんどしで相撲をとるビジネスを選択してしまった報いなのだから。
理想のフレームワーク (スコア:1)
Re:理想のフレームワーク (スコア:2)
しかし、そんな素晴らしいものがあるとすると、おそらく君は失業するな。
新しいものにホイホイ飛びつかない (スコア:1)
「新しいものにホイホイ飛びつかない」
これは、昔から言われている話です。
新しいものは致命的なバグが有ったりして、バッドノウハウが必要になったり。
大勢が決するまで傍観して、既存のフレームワークを使い続ければ良いんじゃないかと。
かんたんだよ (スコア:0)
オレの書いた奴使っとけばいいんだよ！
他人の作ったライブラリなんかアテにならねっての！
自分を信じる自分を信じろ (スコア:0, オフトピック)
フレームワークの話ではないが
自分が面白いと思ったゲームは必ず売れている。
自分がつまらないと思ったゲームが売れていることも当然あるが、ここで重要なのは面白いと思ったゲームが「必ず」売れている所。
自分が面白いと思って外れたゲームは今の所存在しない。
ちなみにゲーム歴は30年近く、コンシューマだけではなくPCとか最近ではソシャゲ等、ジャンルは多岐にわたりプレイ総数は1000や2000を軽く超えるだろう。
その数千のうち、面白いと思ったゲームは必ず売れているわけだ。※予め売れる予想がたつ大作シリーズ等を除いても
というわけで、自分が選ぶ物は世間に受け入れられる物だという認識をしている。
フレームワークでも同じで、結局使われていくものは世間に受け入れられる物なのだから
こういう自分自身の経験則や実績によって判断すればいいのではないだろうか。
逆に自分が選んだ物はいつもすぐ消えていく、という実績があるのであれば、自分とフィーリングがあった物を使わなければいいという選択肢ができる。
運が悪い奴はその反対をすればいいんじゃね理論である。
自分に絶対的な自信があるか、もしくはないかどちらでも対応できる。
中途半端に平凡だと反対にしても平凡なので通用しないが。
Re:自分を信じる自分を信じろ (スコア:1)
自分に絶対的な自信があるか、もしくはないかどちらでも対応できる。
中途半端に平凡だと反対にしても平凡なので通用しないが。
もし、そんなに自分に自信を持っているんだったら、こんな相談はしないと思われる。
その数千のうち、面白いと思ったゲームは必ず売れているわけだ。
その数千はどうやって選んだ? レビュー誌とかネットの評判で選ばなかった?
Re:自分を信じる自分を信じろ (スコア:1)
元コメ主が「多くの人が面白いと思うものを面白いと思う」っていう平凡な人というだけじゃない？
わかるはずがない (スコア:0)
もしそんな原則が存在しうるなら、
Microsoftあたりが何としてでも見つけ出して、
自社製品が生き残るようにしているでしょう。
そんな原則は存在しないことを前提に、
その場合に最適な設計、
つまりフレームワークの切り替えを前提とした設計を導入するのが、
もっともよい選択肢でしょうね。
Re:わかるはずがない (スコア:1)
デスブログ (スコア:0)
NetCommons (スコア:0)
XOOPSの独自拡張という段階で嫌な予感がしましたが以下のように変化していったのでした。
Ver.1 XOOPS
Ver.2 Maple *いわゆるStable
Ver.3 CakePHP
とフレームワークがかわっています。きっと次はうまくやってくれるでしょう。
# ZAPZAPZAP
巨大なフレームワーク (スコア:0)
WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、
静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。
特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、
適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、
DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、
ビルド済みのライブラリの配布はDLLになっていることが多いですね
（DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか）。
フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。
Re:巨大なフレームワーク (スコア:1)
5年以上前にwxとMingWの組み合わせで
GUI版ハローワールドで１０MB超えたなあｗ
DLLでなく、静的リンクにしたから、とか言うオチじゃないよね?
Re:巨大なフレームワーク (スコア:1)
いや、静的だろうが動的だろうが、
最終的に単体配布するなら結局そのサイズ分のインストールになるから
DLLなら単体は小さいなんて事は重要ではない
それは、コンパイラにgccを使うか、Visual C++ Expressを使うかで変わる問題か?
wxはよく知らないけど、wx+gccの組み合わせと、wx+Visual C++ Expressの組み合わせで配布する容量はそんなに違うの?
Re:巨大なフレームワーク (スコア:1)
うん ひとけた違う
MinGW環境のつもりが、Cygwin環境だったとかじゃない?
一桁って、絶対値ではいくらくらいよ?
理由は謎
リンクしているライブラリが違うのか、リンク前のオブジェクトファイルのサイズが違うのか、くらいは判るだろ?
*.exeがリンクしているDLLは、Cygwin環境があれば
で調べることができるぞ。
あと、まさかとは思うけど、デバッグオプションの違いとかじゃないよな?
Re:巨大なフレームワーク (スコア:1)
もうwxを使えるカラダじゃないｗ
使う必要のない方法を書いたつもりだけど、解らなかった?
なんてーのかなー。それはコンパイラのせいじゃないと思うなあ。
いくらなんでも、コンパイラの差だけで、10倍以上もサイズに差が出るとは思えない。
やっぱり、あるとすれば、リンクしているライブラリの差じゃない?
そうでないとすれば、コンパイラオプションが違いするぎるとか。
Re:巨大なフレームワーク (スコア:1)
VCで自前ビルドしたRuby1.9のbinの下が1.2MB（これでstatic link）
ふーん。
ちなみに、CentOSのRubyは、
だけどな。もちろんこれは、gccでコンパイルされている。
何が動的にリンクされているかと言うと、
とまあ、予感ばかりに頼ってないで、こういう風に調べてみたらどうなる? 意外な結果が出るかもよ。
Re:巨大なフレームワーク (スコア:1)
DLL関係が違うだけなのに、倍のサイズ取ってるね。
より正確には、1.8倍強だね。その程度なら十分考えられる範囲。
で結局、「一桁違う予感」とやらは当たってなかったね。
# その一桁が二進数なら当たってるけどさ(笑)。
みんなで決める (スコア:0)
フレームワークなんて、ただ生き残ればよいって訳でないし、どれを選べば問題が少ないなんて予測できないだろうし、
PHPみたいに生き残ってるのが困るんだよみたいなのもあるし、
最終的になくなるケースでも移行先が準備万端とか、最初から移行しやすい構成に設計されてるとかあるだろうし。
自分で特に推したいものが無ければ、信頼できるメンバに情報出させて、その後みんなで投票するぐらいの方が正解に近いかもしれんよ。
選択候補には「特に希望はない」も含めておいて。
メンバも納得して仕事できるし、自分だけの責任にならないし。
どうせ捨てることになる (スコア:1)
システムは5年で捨てる/リプレースする前提で計画すべき
って気がする。