アカウント名:
パスワード:
JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。
JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん
> JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。
それはないです。
見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし相手のブラウザにはなるべく仕事をさせない必要があります。これはビジネスの話ですので、実装の都合などより上のレイヤーです。
今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。# 超AC
今、とあるWebシステム（100画面はある。顧客、オペレータ両方使う）のリプレース版を作ってるんだけど…JavaScriptなんてほとんどないよ…。選択による活性非活性の切り替えとか、領域の表示非表示とか、それくらい。周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。いや、そもそもJSP使ったことある人間が少ないかも。
鯖側は一応のフレームワークがあるけど業務は画面からのコマンドごとのベタで、ほとんど同じコンポーネントが5つも6つもあったり。利用者や開発者の目線はなく、進捗管理の目線だけっぽい。
継承禁止、privateメソッド禁止、三項演算子禁止、==null禁止（共通クラス使用）、+で文字列連結禁止、単体試験も専用ツール利用（死ぬほど重くて使いづらい）、etc.、etc.で頭が痛い日々。
まあ、H系なんですが。いい加減抜けさせてくれ。
privateメソッド禁止って凄いな。
凄いなの意味が良い意味なら同意。悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なのでprivateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
おもしろおかしいをつけたいけど、まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
わからない (スコア:3, 興味深い)
JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。
JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん
Re: (スコア:0)
> JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。
それはないです。
見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、
JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。
特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし
相手のブラウザにはなるべく仕事をさせない必要があります。
これはビジネスの話ですので、実装の都合などより上のレイヤーです。
Re: (スコア:0)
今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。
# 超AC
Re: (スコア:0)
サーバー側は、JSONベースのAPIさえ定義できれば、比較的、UI側の人と分業がしやすいので従来よりは開発が楽になったと思っています。
いざとなれば、JSONを喋るリッチクライアントも作れますし、
セキュリティやユーザーサイドを信用できるかどうかといった議論さえしっかりできれば非常によい傾向だと思っています。
Re: (スコア:0, 興味深い)
今、とあるWebシステム（100画面はある。顧客、オペレータ両方使う）のリプレース版を作ってるんだけど…JavaScriptなんてほとんどないよ…。
選択による活性非活性の切り替えとか、領域の表示非表示とか、それくらい。
周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。
いや、そもそもJSP使ったことある人間が少ないかも。
鯖側は一応のフレームワークがあるけど業務は画面からのコマンドごとのベタで、ほとんど同じコンポーネントが5つも6つもあったり。
利用者や開発者の目線はなく、進捗管理の目線だけっぽい。
継承禁止、privateメソッド禁止、三項演算子禁止、==null禁止（共通クラス使用）、+で文字列連結禁止、
単体試験も専用ツール利用（死ぬほど重くて使いづらい）、etc.、etc.で頭が痛い日々。
まあ、H系なんですが。いい加減抜けさせてくれ。
Re: (スコア:0)
privateメソッド禁止って凄いな。
Re: (スコア:1)
凄いなの意味が良い意味なら同意。
悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから
今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なので
privateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。
今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
Re:わからない (スコア:1)
おもしろおかしいをつけたいけど、
まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が
先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。
#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな