アカウント名:
パスワード:
JavaFX2 なんてものがあるのか、まあ誰にも相手にされずに終わるだろう、ということを確認するためにググったとき読んだこの文章 [oracle.com]のグラフ [oracle.com]が、分かりやすく現状を示しているように思えます。HTML5 は素晴らしいが、どう作るかについては、いまだ試行錯誤のまっただ中。
JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。LAMP Stack は書きづらいだけ。使う理由がなくなった。シングルページアプリケーションの利点がはっきりしてきた今となっては、たぶん
> JavaScriptの発展で、サーバーサイドでHTML生成するタイプのものは不要になるのは明らか。
それはないです。
見た目重視のB2Cではなく、実用重視のB2Bや自社内業務アプリなどでは、JavaScriptに頼ったUI実装は無駄なコストやブラウザ変更時の負荷を非常に増大させるだけです。特に責任の分界があるようなシステムでは、可能な限り「自分の腹の中で」処理をし相手のブラウザにはなるべく仕事をさせない必要があります。これはビジネスの話ですので、実装の都合などより上のレイヤーです。
今作ってる某社の社内システムがまさにクライアントサイドJavaScriptバリバリで、サーバはJSONを返すだけという変態システムなんだが。# 超AC
8年くらい前になるか、某プロバイダのWebメール新版を作るとき、Outlookを目指してAjax/JSONバリバリでやったなぁ。Ajaxの技術書も限られてて、結構難産だったけど、動作の組み立てよりも軽量化に腐心した記憶ばかり蘇る。それでも「重い」「使いづらい」と不評だったけど。
クライアント側はその頃からさらに代替わりしてるけど、鯖側は我々が作ったものを引き継いだと聞いた。
「ここ五年間の」ということは、やはりちょっと早かったのかな…。
実用重視なら、余計にJSは使うと思うんだけど、#2485073の人は、装飾用途でのJSしか知らないのかしら。HTMLページを一Pづつ開くより、Ajaxで必要な部分だけ書き替えたほうがずっと負荷が少ない。
今、とあるWebシステム(100画面はある。顧客、オペレータ両方使う)のリプレース版を作ってるんだけど…JavaScriptなんてほとんどないよ…。選択による活性非活性の切り替えとか、領域の表示非表示とか、それくらい。周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。いや、そもそもJSP使ったことある人間が少ないかも。
鯖側は一応のフレームワークがあるけど業務は画面からのコマンドごとのベタで、ほとんど同じコンポーネントが5つも6つもあったり。利用者や開発者の目線はなく、進捗管理の目線だけっぽい。
継承禁止、privateメソッド禁止、三項演算子禁止、==null禁止(共通クラス使用)、+で文字列連結禁止、単体試験も専用ツール利用(死ぬほど重くて使いづらい)、etc.、etc.で頭が痛い日々。
まあ、H系なんですが。いい加減抜けさせてくれ。
>+で文字列連結禁止何年前のコンパイラ使っているの?
>継承禁止、privateメソッド禁止え~と、JSPって出てきているからjavaだよね?無駄に工数増やしているような……
# 関わりたくない、本気で。
privateメソッド禁止って凄いな。
凄いなの意味が良い意味なら同意。悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なのでprivateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
privateだからテストしにくいという時点で設計を間違えている
おもしろおかしいをつけたいけど、まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな
#2485137から追記。
いわゆるCOBOL風Javaで、処理がダラダラベタ書き。処理を親にまとめたくても継承禁止。仕方なくサブルーチン化を考えてもprivate禁止。そんな感じ。
大半はオフショアがこの縛りで作ったんだけど、一番デカいクラスは9600行くらい。当然不具合てんこ盛りで、修正は国内。
数万ファイルの詳細設計書もいい加減見たくない。
周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。いや、そもそもJSP使ったことある人間が少ないかも。
Java と JavaScript 混同してない?この人?
> まあ、H系なんですが。いい加減抜けさせてくれ。
抜ける前にそこらへん全部改善して行ってよ。改善できるのは関係者以外に居ないんだから。
#金にも権限にも縁のない人間ほどそう言う。というか、本当に金や権限を持つ人はうっかりそんな言質はとらせないんだよね。
というわけで、そんな金も権限ももらってないし、契約も義理もねえ。ムセキニンダーと言いたいかもしれんが、そういう契約で召喚されたのは確か。純粋に心情的な面だけ考えても、一通り改善しまくった結果、さよならだけが人生だというのは虚しいじゃないか。
私も最近作ってるWEBアプリのほとんどにおいて、サーバ側は認証を含むリクエストの妥当性の検証と、それが通った場合はリクエストに沿ったデータをせっせとJSONで返す、というだけのI/Fを最低限守る実装しかしてないかも。フレームワークは古くはPHPでCodeIgniterで作ってたり、最近はnode.jsのExpressだったり様々。それを受け取るクライアントもJSONをもとに画面書き換えするブラウザアプリであったり、はたまた別のサーバ側アプリだったりと様々。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
わからない (スコア: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:わからない (スコア:1)
8年くらい前になるか、某プロバイダのWebメール新版を作るとき、Outlookを目指してAjax/JSONバリバリでやったなぁ。
Ajaxの技術書も限られてて、結構難産だったけど、動作の組み立てよりも軽量化に腐心した記憶ばかり蘇る。
それでも「重い」「使いづらい」と不評だったけど。
クライアント側はその頃からさらに代替わりしてるけど、鯖側は我々が作ったものを引き継いだと聞いた。
「ここ五年間の」ということは、やはりちょっと早かったのかな…。
Re: (スコア:0)
実用重視なら、余計にJSは使うと思うんだけど、#2485073の人は、装飾用途でのJSしか知らないのかしら。
HTMLページを一Pづつ開くより、Ajaxで必要な部分だけ書き替えたほうがずっと負荷が少ない。
Re: (スコア:0)
サーバー側は、JSONベースのAPIさえ定義できれば、比較的、UI側の人と分業がしやすいので従来よりは開発が楽になったと思っています。
いざとなれば、JSONを喋るリッチクライアントも作れますし、
セキュリティやユーザーサイドを信用できるかどうかといった議論さえしっかりできれば非常によい傾向だと思っています。
Re: (スコア:0, 興味深い)
今、とあるWebシステム(100画面はある。顧客、オペレータ両方使う)のリプレース版を作ってるんだけど…JavaScriptなんてほとんどないよ…。
選択による活性非活性の切り替えとか、領域の表示非表示とか、それくらい。
周りを見回してもJavaScriptの技術持ってる人間なんて全然いなくて、だいたい回って来るし。
いや、そもそもJSP使ったことある人間が少ないかも。
鯖側は一応のフレームワークがあるけど業務は画面からのコマンドごとのベタで、ほとんど同じコンポーネントが5つも6つもあったり。
利用者や開発者の目線はなく、進捗管理の目線だけっぽい。
継承禁止、privateメソッド禁止、三項演算子禁止、==null禁止(共通クラス使用)、+で文字列連結禁止、
単体試験も専用ツール利用(死ぬほど重くて使いづらい)、etc.、etc.で頭が痛い日々。
まあ、H系なんですが。いい加減抜けさせてくれ。
Re:わからない (スコア:1)
>+で文字列連結禁止
何年前のコンパイラ使っているの?
>継承禁止、privateメソッド禁止
え~と、JSPって出てきているからjavaだよね?
無駄に工数増やしているような……
# 関わりたくない、本気で。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
privateメソッド禁止って凄いな。
Re:わからない (スコア:1)
凄いなの意味が良い意味なら同意。
悪い意味なら今どきのOODを再入門すると良い。
かつてOODの黎明期にオブジェクトの説明で真っ先にカプセル化を教えたもんだから
今でもカプセル化に拘る人がいるけど、もう今はUnitTestあたりまえ時代なので
privateにされると試験しにくいデメリットの方が大きくなりすぎてカプセル化のメリットを上回っている。
正直カプセル化って、カプセルした中身の信頼度が低いと開かずのトイレで爆弾抱えてるようなもの。
今どきはオープンにして、代わりにコードカバレッジ100%にしたり規約チェック入れたり別の手段で全体の信頼度を高めるのが正しいOOD。
Re:わからない (スコア:2, すばらしい洞察)
privateだからテストしにくいという時点で設計を間違えている
Re:わからない (スコア:1)
おもしろおかしいをつけたいけど、
まあ、卵か鶏かの話になるのかな。「カプセルした中身の信頼度が低い」「カプセルした中身の信頼度が低い事でテストしづらい」という事実が
先行するか、「テストしづらい設計(粒度が低い)にする方が悪い」とするかの問題だと思うが。そこで「privateにすんな」という結論は頭が悪いと思う。
#TDDの話で、「テストしやすい設計にしろ」という話はあまり聞かないけど、言うほどの事もない常識という事かな
Re: (スコア:0)
#2485137から追記。
いわゆるCOBOL風Javaで、処理がダラダラベタ書き。
処理を親にまとめたくても継承禁止。
仕方なくサブルーチン化を考えてもprivate禁止。
そんな感じ。
大半はオフショアがこの縛りで作ったんだけど、一番デカいクラスは9600行くらい。
当然不具合てんこ盛りで、修正は国内。
数万ファイルの詳細設計書もいい加減見たくない。
え!? (スコア:0)
Java と JavaScript 混同してない?この人?
Re: (スコア:0)
> まあ、H系なんですが。いい加減抜けさせてくれ。
抜ける前にそこらへん全部改善して行ってよ。
改善できるのは関係者以外に居ないんだから。
Re: (スコア:0)
#金にも権限にも縁のない人間ほどそう言う。というか、本当に金や権限を持つ人はうっかりそんな言質はとらせないんだよね。
というわけで、そんな金も権限ももらってないし、契約も義理もねえ。
ムセキニンダーと言いたいかもしれんが、そういう契約で召喚されたのは確か。
純粋に心情的な面だけ考えても、一通り改善しまくった結果、さよならだけが人生だというのは虚しいじゃないか。
Re: (スコア:0)
私も最近作ってるWEBアプリのほとんどにおいて、サーバ側は認証を含むリクエストの妥当性の検証と、それが通った場合はリクエストに沿ったデータをせっせとJSONで返す、というだけのI/Fを最低限守る実装しかしてないかも。
フレームワークは古くはPHPでCodeIgniterで作ってたり、最近はnode.jsのExpressだったり様々。
それを受け取るクライアントもJSONをもとに画面書き換えするブラウザアプリであったり、はたまた別のサーバ側アプリだったりと様々。