Java Web Application Framework総合　ver2

■ このスレッドは過去ログ倉庫に格納されています
2013/07/21(日) NY:AN:NY.AN
Java用のWeb Application Frameworkについて語るスレッド

海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド

前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/

Web Application Framework　のリスト
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features
2014/05/05(月) 01:34:42.59ID:uhwl8tdd
>>397
業務アプリにとっての「技術」は目的ではなく手段に過ぎないからな
目的が達成できるならレガシーな技術で十分
先端追いかけてくれる人たちがいるお陰で、周回遅れで安定した(枯れた)技術を採用できるとも思ってる
確かに技術屋には魅力はないだろうが、そういうもんだろう
2014/05/05(月) 02:57:09.05ID:wGBQOVTp
>>400

最新の技術に拘る訳じゃないが
新しい方が品質、生産性が高い場合もあるんじゃないかなぁ
学習コストっての問題はあるが・・・
2014/05/05(月) 03:20:29.45ID:uhwl8tdd
>>401
あると思う。
でも数多ある新技術がすべて宣伝通りのレベルに達しているかと言うと、期待はずれの技術もまた多いわけで
その辺はイノベーターさんやアーリーアダプターさん達の成果に頼ることになる
2014/05/05(月) 10:46:41.45ID:XYbGwOBG
JavaでいうとServlet+JSP以外信用できない
フレームワークは穴だらけ
新しいものは信用できない
2014/05/05(月) 16:22:20.74ID:eHaIsNXX
struts普及しすぎたせいで未だにstruts使ってるところ多い感じだ
ドヤ顔で独自フレームワーク開発してますとかほざいたくせにベースにstrutsとか寝ぼけてんのかよ
2014/05/05(月) 23:41:08.23ID:wGBQOVTp
strutsは普及しすぎたが故の脆弱性問題かね
OpenSSLといいIEといいこの手の話最近多いけど
他が安全っつうよりはマイナーなだけな感じ

ただオレオレFWが結局同じ問題を抱えてて
各々対処しないといかんのはダサいね

じゃあjavaEEなのかと言うとよくわからない
標準といえど旧EJBのような失敗作もあるし
2014/05/05(月) 23:55:41.61ID:qgaxSqth
フレームワークは使ってるってだけでドヤ顔できるかな
2014/05/06(火) 00:36:47.39ID:/KCtgeyk
>>400
日本で業務系アプリやってる奴らは
周回遅れどころか10年以上遅れてるだろう
リリース後に1年もたてば十分に安定した技術になる。

ただ時代遅れで新しい技術についていけていないだけなのに
「枯れている」などという言葉で正当化しようとする

フレームワークの有り無しを論じていたり、Strutsがどうこうとか
日本だけ時間が15年くらい止まっている感じだな
2014/05/06(火) 01:51:30.39ID:HbPu7+SF
>>407
どうした？業務アプリに親でも殺されたのか？
2014/05/06(火) 10:04:43.41ID:p+pOalwe
企業の場合、フレームワークにノウハウを詰め込んでる場合が多いから、土台が古くなってもなかなか変えられない。
下手に変えるとエラい目に会うからな。
2014/05/06(火) 10:11:07.39ID:mq0PWr6n
＞strutsは普及しすぎたが故の脆弱性問題かね
JSP系統全体の脆弱性じゃないの

Velocityとかで同じようなことは大丈夫なのかな
2014/05/06(火) 12:34:59.61ID:ifeVOml8
OGNLとかBeanUtilsとか個別の要素のバグや仕様だから同じことしてたら問題はある
2014/05/06(火) 15:00:56.09ID:q8o8j/Sw
欧米だと、業務系アプリでもどんどん新しい技術採用してるのにな
バックエンドはSpring+MySQLやnode.js+MariaDB、フロントはHTML5ベースで
backbone.jsやAngularJSにしてREST-APIで繋ぎ、サブシステム連携も充分とかさ
2014/05/08(木) 20:14:41.32ID:QhqRiqXw
>>393
プログラムとWebプログラミングとで板が分かれていたの知りませんでした。

>>394
JSF2.0は、MSのASP.NETみたいにできるそうです。
でも、MSはサービス運用でライセンスにお金が絡んで自由に使えないのでそんな技術は使いたくありません。
未来に自由をもたらすために、javaで行きます。

LAN内向けサービスなら使えそうですね。
リソースの問題も、今後JSFのバージョンがあがっていくにつれて改善されることを期待します。

>>395>>399
>JSF2 は、... などの旧来型のWebアプリの集大成
今やJDKの標準技術になっているんですよね。

>JSF2に頑張って欲しい
同感です。

>クライアントサイドで MVC が完結して、サーバーサイドは API に特化するという方式に移りつつある。
余計に処理の流れが複雑になりそう・・
サーバの負担は軽くなりそうですね。


JFS2.0の書籍を大型の本屋に探しに行きましたが、一冊だけでした。
掌田 津耶乃「EclipseではじめるJavaフレームワーク入門　第4版」が
JFS2.0を使ったプログラム例と詳細な解説が載ってました。

これ以外に、どうして売っていないのか不思議です。　（JFS2.0は、JDKの標準技術なのに。）
オイラリーのは、JSF1.0を対象に書かれていたので、対象外です。2004年初版でした。
2014/05/08(木) 21:30:25.66ID:+3i6oIvP
asp.netもasp.net MVCっていうサーブレットチックなものが主流になってる。

asp.netもjsfも柔軟性にかける割に生産性もそこまで高くないんだよね
2014/05/08(木) 22:39:57.36ID:2SfqCKIX
生産性が低いとは思わないけど、まあ、ぎょーむ屋さんがつまんねーLOBアプリをシコシコ作るの専用感はある。
2014/05/09(金) 04:23:02.68ID:q6CZdclC
Struts2+Spring DIでStruts2のActionにDIするWebアプリケーションを作ってる。
このアプリの実行時に、DIされるべきフィールドがnullになっててヌルポが発生することがある。
アプリをコンパイルしなおしたらヌルポが発生する場所が毎回変わったりするので原因がよく
わからない。

Tomcatが利用できるメモリ容量を増やしたらヌルポが発生しなかったので、DIに必要な
メモリが足りないのが原因かと思ったんだが、そういうことってありうるのかしら？
みんなTomcatのメモリ容量はどのぐらいにしてる？
2014/05/09(金) 04:36:52.76ID:zfIj6OAD
>>414
asp.net MVCがサーブレットと同類のわけないだろ
お決まりの処理は最小限のコードで書ける
ASP.net MVCの生産性の方が圧倒的に上

>>413
掌田 津耶乃の本はやめておけ
いろんな言語のフレームワークの本を書いているがどれも評価低い
内容が薄っぺらい、同著者のamazon レビューを見たほうがいい

＞これ以外に、どうして売っていないのか不思議です。

理由はJavaの技術は定番がなく分散してるから
膨大な時間をかけて本を書いても売れない、儲からない
日本語で書いたら日本人しか買わない
どうしても本で学びたければ英語で書かれたものを探したほうがいい
2014/05/09(金) 04:41:29.70ID:zfIj6OAD
>>416
いまさらStrutsとは

ヌルポにメモリが関係あるわけないだろ
物理メモリが足りなければ、HDD/SSDなどの仮想メモリが使われる
2014/05/09(金) 05:03:29.99ID:q6CZdclC
>>418
うん、おれもStruts使いたくない。

やっぱ関係ないか。再現条件（ヌルポの発生場所）がころころ変わるんで悩んでる。
DIされるべきところがnullになるケースってなんかない？
2014/05/09(金) 08:34:54.37ID:EM0RixeL
Spring使ってるのになぜStruts?しかも2とかありえねぇ。
馬鹿なの？アホなの？死ぬの？

SpringMVC使えよ。
2014/05/09(金) 08:58:40.41ID:E3wsUlgH
決定権無ければそれでやるしかないよね
2014/05/09(金) 15:31:47.07ID:dvOOVkmX
決定権がある人間が無能だと
こうやって現場が疲弊する見本だな

中途半端に要素技術を聞きかじってると
こうなるよな
2014/05/09(金) 16:52:51.17ID:vziOY5Cd
>>419 OutOfMemoryErrorをどっかで揉み消してるとか
>>418 PermGen上限を緩めてないなんてのはありがち
2014/05/10(土) 09:12:05.20ID:1Do2eZKO
>>420-422
お察しのとおり、途中から参加したプロジェクトなんで変えようがない。
Spring使うならSpringMVC使え、はもっともなんだろね。

>>423
MaxPermSizeを大きくするとヌルポが起きないので、そこかなーと思ってる。
OutOfMemoryErrorのもみ消しはしてないと思う。
2014/05/10(土) 11:23:10.80ID:gSo5tcfL
やっぱTomcat使ってるとこ多いよね

javaEE にするならTomEEでいいかな？
2014/05/10(土) 11:50:16.02ID:ZoW/vxHI
Tomcatで十分だろ。意味わからん
オレオレアーキテクトのオレオレフレームとオレオレコンテナとか誰得だよ
2014/05/10(土) 12:57:17.13ID:2YlfM5m7
趣味ならなんでもおｋ
2014/05/10(土) 13:05:01.57ID:++ojgnt3
将来が有望なWEBアプリのフレームワークって？

JFS2を推したいのだが・・・

他の技術では、HTMLを噛むのでコードが煩雑になりはしないかと躊躇する
2014/05/10(土) 16:08:55.06ID:ReRBG8qB
HTMLをサーバ側で作ってレスポンスに送り出すのか
サーバからは必要な情報だけJSONとかで取得して
ブラウザ側でDOM生成するかで何を使うかが変わってくるな

HTML自体の修正が必要な場合は、個人的好みとしては
後者のほうが修正から反映までの手間が少なくて好きだ。
サーバ側でやると、サーバ側もデプロイしなおしとかあるし
2014/05/10(土) 16:18:20.94ID:lrUbXucJ
最近は後者な流れじゃない？
2014/05/10(土) 16:19:03.56ID:6O8ipEn6
こいつ一昔前までseasar2押してたタイプだ
2014/05/11(日) 15:40:23.86ID:CQcMSGFV
>>429
>ブラウザ側でDOM生成する

せっかく、ASP.NETは、サーバー側で要求を受け付けて処理してHTMLを出力するうまい方法（抽象化されたサーバコントロール）を、
実現していたのに（JFS2みたいに）、今からはブラウザ側がHTMLを自分で作成するのですか。

ブラウザ側でHTMLをコントロールするタイプなら、
何が推しですか？

そういうタイプWEBアプリって、サーバーは基本的なプログラムとデータをクライアントに提供して、
クライアントがその基本的なプログラムを処理することで適切なHTMLを自分で組み立てる感じでしょうか。
2014/05/11(日) 15:55:27.33ID:moCMHB5P
>>432
ブラウザ側でいろいろやるのは別に良い方法というわけじゃないよ

ただJavaの世界ではサーバサイドのフレームワークが
ろくでもないものばかりだから、そういう開発をやる人が出てきただけ

ASP.netやASP.net MVCに比べると開発に時間もかかるし
ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
セキュリティも低下する
2014/05/11(日) 20:28:02.82ID:UwOOPA9c
>ASP.netやASP.net MVCに比べると開発に時間もかかるし
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

いまどきの大手SIerって、こういう時代遅れタイプで占められてるんだよな
だからStruts1が幅を効かせてきたわけだ
2014/05/12(月) 00:07:44.85ID:wroz7708
>>433
>ただJavaの世界ではサーバサイドのフレームワークがろくでもないものばかりだから
>（ブラウザ側でいろいろやる）そういう開発をやる人が出てきただけ

結局は、消極的な理由なんですか。

近年のクライアントのパワーが上がってきたことと、
サーバーの負担を減らすために、クライアントサイドでhtml構成作業を行うようになったのだと思っていた。
あと、ポストバックをなくすために。

>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

ブラウザ環境で意図した動作をしないというのは困りものだな。

うーむ。
だったら、サーバーサイドのフレームワークとして、JFS2.xに期待するなあ。
なんだって、JDKの標準機能に組み入れられたのでしょ。
JFS2には将来性があると思う。
2014/05/12(月) 00:09:39.92ID:wroz7708
>>417
>理由はJavaの技術は定番がなく分散してるから
>膨大な時間をかけて本を書いても売れない、儲からない
>どうしても本で学びたければ英語で書かれたものを探したほうがいい

JAVAって、いろいろ分散していて、いったい何が標準なのかぜんぜんわからないですものね。
JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
今後は、日本語で書かれた書籍も増えてくるかもしれないですね。

ほんと、期待しています。

ASP.NETはいいんだけど、運用保守にお金がお金がかかるかかる。ライセンス問題が非常にやっかい。
MSのご機嫌取りしなきゃいけなくなる。アプリの運用を人質にされて、MSに振り回されるのは勘弁。
なので、ASP.NETは将来を見越したら、取り組みたくないんだなあ。
2014/05/12(月) 00:23:29.96ID:f+OP7VZY
>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。

一応、そのあたりの差異を吸収することも目的の一部に含むのが
jQueryのようなJSのフレームワークなわけで
サーバーサイドの人間は何かというとJSを目の敵にするけど
どちらも使えたほうが、この先業界内で生き残っていける確率は上がるでしょ

企業的には「フルスタックエンジニア」なんて名前の便利屋や何でも屋を
求めるようになってきてるし。
2014/05/12(月) 00:40:16.62ID:h1G1q1Ck
どうでもいいが「JFS」じゃなくて「JSF」な
JavaServer Faces（JavaとServerの間は空けないのがお約束）
2014/05/12(月) 00:42:07.47ID:wroz7708
>フルスタックエンジニア

それでも、htmlやJAVA SCRIPTを触らなくても良い、高度に抽象化された一元的プログラミングをしたい・・・
2014/05/12(月) 00:43:03.15ID:wroz7708
>>438
ありがとう
2014/05/12(月) 01:00:32.81ID:KacrXp1d
>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
というかバージョン変わったりブラウザが変わったりすると動作しなくなる可能性があるのはJAVAでも同じことだと思うけど違うの？
2014/05/12(月) 01:14:18.80ID:/hsNV+iO
>>441
Webアプリでクライアント側のJREは使わないでしょ
サーバサイドでJavaだから、サーバ側のアップグレードしなければ
バージョンアップのエラーは出ない

ブラウザ側でJSを多用するWebアプリは、ユーザのブラウザの種類や
バージョンに依存するようになってしまう


これはJSじゃなくてHTML/CSSの互換性の話だけど
XP時代にIE6用に設計した業務システムを作ってしまい、
悲惨な目にあった企業はたくさんあるのは有名な話。
OSのアップグレードやPCのリプレースもできなくなった。

クライアントブラウザの指定がしやすい業務システムであっても
なるべくサーバサイドでやるほうがあとあと問題は出にくいと思うよ
2014/05/12(月) 01:20:14.46ID:/hsNV+iO
>>442補足しておくと
ブラウザバージョンアップでレイアウトの崩れ程度は起こる可能性は
どの技術でもありうるけど、ブラウザ側でJSを使わなければ
エラー吐くような事態にはならないから新バージョンへの対応もしやすいということ

DartはもうIE9のサポートを打ち切ったらしい
ブラウザのバージョンアップですぐに動かなくなるようではだめだ
DartはJavaScriptに変換する言語ね
2014/05/12(月) 01:27:57.76ID:KacrXp1d
>>442
ちょっとよく分からない。
サーバーサイドですべて出力するにしろ、ブラウザで動作するものを作るわけだよね？
JREで動作させるものじゃないとすると、結果はHTML出力とかになると思う。
だったらブラウザが新しくなったら動作しなくなるとかあるんじゃないの？
445444
垢版 |
2014/05/12(月) 01:30:28.95ID:KacrXp1d
>>443
見てなかった済まない。
しかし昔の業務用アプリならともかく、最近のものでJavascriptを一切使わないってありえないと思うんだけどな。
2014/05/12(月) 01:41:02.37ID:h1G1q1Ck
>>445
このスレは昔ながらの業務アプリしか作らなくて済んでる化石のようなエンジニアの巣窟なの
447>>53
垢版 |
2014/05/12(月) 01:47:49.33ID:iJz1i67B
サーバー側で要求を受け付けて処理してHTMLを出力する方式は
wicketでもjsfでもセッション多用でレプリケーションの同期が多発
Playがセッション使わせたくないのもこの辺が原因でしょ
2014/05/12(月) 02:04:03.42ID:/hsNV+iO
>>445
一切使わないなんて言ってないんだけどな
>>442でも「なるべくサーバサイドでやる」とはそういう意味だ

>>446
業務アプリでJSが必須の機能少ないけどな
どういう機能か言ってみなよ

ユーザデータチェックのValidationではJS使うけど
業務アプリでJSでしか実現できない機能を求められることは少ない
2014/05/12(月) 03:22:01.12ID:KacrXp1d
>>448
いやまあそれ言っちゃうとJSのほうだってなるべくHTMLは書くようになると思うよ。
JSが受け持つ範囲は多くなるけど。
全てのデザインをJSで組むっていうのはまずありえないかなと。HTMLで書くほうが早いし簡単だし。

あと>>446への返信に横入り。
「業務アプリ」で「最低限の機能」しか求められることが少ないって書いてあるけど、それって反論じゃなくて、
書いていることに対して認めているように見えるけど良いの？
2014/05/12(月) 10:18:24.45ID:NL4i9DSa
そもそも業務アプリなんかWebでやりたくねぇわ
2014/05/12(月) 10:37:30.53ID:GdHpjeGh
>>436

> JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
> 今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
>
> ほんと、期待しています。

JSFが何年も前の1のころからJ2EE (いまで言うJavaEE)の標準になっていたが、結局流行らなかった。

流行るものは、結局標準化どうかではなく、そのプロダクトが使いやすいか(いいものか)どうかなんだよ。
2014/05/12(月) 12:03:24.64ID:3xPUgV6E
標準だとしてもOracleだぜ？
何だかんだ言ってもMSの方がマシだろ
2014/05/12(月) 17:15:35.33ID:YqgznOAd
すれち
2014/05/13(火) 22:10:38.32ID:QItZX2Cn
酷い製造現場に入っちまったわ
少なくとも6年以上は前のフレームワークを使って色々やってるんだが
雛型作り上げるまでのプロセスがむちゃくちゃ
2014/05/14(水) 02:03:31.02ID:B2iG6znP
6年前って2008年か… マシな方じゃね？
10年前のJ2EEで止まってる方が酷いと思うわ
2014/05/17(土) 00:35:29.68ID:PXPFtWqe
技術の蓄積が云々でStruts1
2014/05/17(土) 02:08:09.45ID:C6+8ucAK
Struts1内臓の自社製フレームワークだ
2014/05/24(土) 10:45:14.85ID:zWM8Vigu
http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/9/
2014/05/24(土) 18:26:53.21ID:qfxUsSTH
GWTとかVaadinって意外と使われているのね
Vaadinはそのうち開発頓挫しそうな空気だけど
2014/05/25(日) 20:03:15.10ID:gGsDT7q8
結論：Flexでおｋ
2014/05/28(水) 00:27:43.53ID:9OS265q7
GWTが流行るか、javascriptがdartに進化するべきだった
半端なJSフレームワーク乱立とか糞すぎる
2014/05/28(水) 03:27:10.38ID:1YkJU2y3
なんかもう

フロントコントローラ　：　Jersey + 好みのDIコンテナ
テンプレートエンジン　：　お好み（Thymeleafがよさげ）
DB　：　スクラッチ、ヘルパーライブラリ、ORMお好み
フロントエンド　：　軽量のMVCFWお好みで

こんな感じでいいような気がしてきた（想像）
上手く設計できれば結構いい感じにできそう（想像）

今はWebはPythonとかLL中心でアプリはAndroidやってるからJava資産活用できるしWebもJavaでやりたいって
上に言ってはいるけどなかなか通らない。
2014/05/28(水) 06:46:29.77ID:sLOdIin8
ウチはWebはJavaかASP.NETでしかやらせてくれない
物凄く簡単なのでもJava

めんどくさい
2014/05/29(木) 10:16:48.53ID:bCwfT6SY
>>461
その通りなんだけど、 世の中全体としては、
もっと JSフレームワークが乱立して、みんなで右往左往する流れになってるからな・・・
30代後半になったけど、JSの流れにはついて行けなくなった。

jquery を覚えるだけでも精一杯（管理職業務も増えてきてなかなか開発できなくなったってのもあるけど）
2014/06/08(日) 08:55:00.28ID:muM/tUAt
結局新しいものは流行らずにStruts1.x & JQueryなんか？ｗ
2014/06/08(日) 13:24:09.91ID:IMqXIRgz
大手SIerだったら、Struts1.xメインで
jQueryは使ってもほんの一部の機能だけだな
2014/06/08(日) 15:38:05.52ID:2wWwIno8
>>466
そういうとこは、ユーザの操作に対してDOM書き換えは使わずにページ遷移で応答する感じなの？
もしくはJavaScript直書きのコードでDOM書き換えする？
2014/06/08(日) 20:08:38.84ID:9DHwTaw1
>>467
業務アプリだとDOM書き換えはほとんど使わない。
2014/06/08(日) 21:09:27.40ID:IMqXIRgz
だな。
業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。
使い勝手が良かろうが悪かろうが、要件定義書に羅列されたものを
いかに満たしているかどうかがポイント。

そんなことやってるから、SIerは死んだって言われてるわけだけど
別に死んでるわけじゃなくて、そもそものビジネスモデルが違うんだよね
まぁこれからどんどん衰退はしていくだろうけど。
2014/06/08(日) 21:40:50.67ID:GhJMx+U1
> 業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。

全くそのとおりなんだけど、そんなんでユーザ企業の生産性はどうなってるんだっていうね・・・
SIerだけじゃなく日本の産業全体が衰退するだろこれ
2014/06/08(日) 22:35:46.56ID:9o67lThF
業務アプリは工数の制約が大きいから仕方ないじゃん
2014/06/08(日) 23:57:57.03ID:IMqXIRgz
SIerはユーザー企業の生産性なんか気にしたこと無いよ
ただでさえユーザー企業からコスト削減を言われるんだから
確定した要件を決められた予算以下でいかに抑えて利益出すかが
最大の目的であって、使い勝手なんか知ったこっちゃない
2014/06/09(月) 00:00:42.59ID:86AcLmQh
パッケージなんて入れても魔改造で原型を留めていない
そもそも客自体が抜本的に業務を改善する気があまり無い
そんなユーザ企業ばかりだろ
UI/UXとか高尚な話以前の問題だと思うがな
2014/06/09(月) 03:22:14.41ID:ruWyYOGX
そんな構造に嫌気が差してSIerから足洗った

こんな環境にずっといたらもうその会社でしか使えない人材になってしまう。

業務でそこそこ新しい技術を使えてそんなに忙しくないし給料も高い民間（）の会社の方が楽しい
2014/06/09(月) 16:50:04.57ID:7Qzyu762
ユーザの生産性を最大限に上げたいなら、クライアントがブラウザとかそもそもありえないからｗ
2014/06/09(月) 17:04:36.04ID:WQD38f8Z
システム部門の生産性が最大になる
2014/06/09(月) 17:08:43.74ID:HqQRpaLI
まぁEnterprise 2.0 じゃないけど、業務系でも、かんたんな ajax みたいなのは
少しずつ取り入れられてくると思うけどね。

VBの時代に、コード値の入力補助みたいな感じで、
コード値のテキストボックスからフォーカスを外すと、その右側の ReadOnly なフィールドに名称が表示される、とかやったけど
(勘定科目のコードを入力すると、その横に名称が出る、とか)
webでも似たようなことやった。 テキストボックスにコードを入れて onchange() で、そのよこの <div> を更新とか。

あと、めちゃくちゃ工数がかかったけど、Excelのグリッドをブラウザでやったり。
2014/06/09(月) 21:18:06.29ID:+BBgcboW
日本のシステム屋ってパッケージ作って売っていこうっていう風潮にはならないよね。

客はパッケージに運用を合わせる気はないし、
現場SEはバッケージ無視で要件聞いて作り直しが当たり前だし、
営業はそれでもパッケージ適用だと言い張って客から十分な費用取ってこないし、
パッケージ作ってる側もコンセプトがないかブレブレで大幅に手を入れないと売れないものしか作らないし
2014/06/09(月) 22:32:21.23ID:86AcLmQh
>>477
あーExcelのグリッドみたいなのはやったことあるな
二度とやりたくない
2014/06/10(火) 05:51:12.75ID:ktfRooiL
リッチなビジネスロジックをアジャイルに注入する〜♪
馬鹿な用語や言葉遊び多いよね。作るものは結局帳簿だしｗ
2014/06/10(火) 08:23:28.89ID:tVDmQHlD
システム化するほとんどの業務はExcelで回せる程度の話
482デフォルトの名無しさん
垢版 |
2014/06/14(土) 06:03:43.72ID:BupVVlcz
エンタープライズ・アップリケーション（Excel）
2014/06/14(土) 22:44:17.40ID:BupVVlcz
ビジネスロジック注入！
2014/06/16(月) 01:04:21.90ID:2d0xyXjF
喰らえ！ディペンデンシー・インジェクショオオオォォオォォォン！！！！！
2014/06/16(月) 18:44:58.88ID:AxBJea7v
はぁ・・・ほとんどのメインクラスが1万行越える糞ソース見てると目がおかしくなる
技術的な糧にもならんしホント終わってるプロジェクトだわ
2014/06/16(月) 18:56:58.05ID:AxBJea7v
あと話を最後まで聞かないですぐ早とちり返答するプロパーにイラッとする
2014/06/16(月) 22:43:14.49ID:0QAWs/6q
＞メインクラスが1万行越える糞ソース
誰が書くんだろう

「プログラミングなんか重要じゃない」とか逝ってそうな、そいつの顔が浮かぶけど
2014/06/17(火) 09:43:15.84ID:wq60xqCI
お客様には最適なソリューションを注入させていただきます♪
2014/06/17(火) 10:58:44.64ID:AlynCjr8
>>486
「プロパー」という変な和製英語つかってるバカみるとイラッとする
2014/06/17(火) 11:24:22.15ID:DTyoNsq+
>>486がどういう意味で使ってるかよくわからないけどproperとはちがうん？
2014/06/17(火) 13:13:06.34ID:AlynCjr8
和製英語って書いたから誤解されたみたいだな
日本ではそのproperという単語の使い方がおかしいってこと

properは形容詞だし、正社員という意味合いはどこにもない
2014/06/17(火) 13:28:57.17ID:0wNIkktH
プロパーは日本語
2014/06/17(火) 15:05:45.45ID:1K9Dgk3r
>>491
通じるからいいじゃん。美しい日本語を守る会から来たの？
2014/06/17(火) 15:20:15.40ID:AlynCjr8
>>493
その団体は知らない

「私は基本的な英単語もわからない馬鹿です」と宣言するような
「プロパー」なんて言葉を使う必要はないだろう
プログラミングをするならもっと言語の使い方に気を配るべきだと思うわ
2014/06/17(火) 15:48:39.10ID:1K9Dgk3r
プロパーだけで正社員を意味してるわけじゃないからｗプロパー社員の略だからｗ
2014/06/17(火) 16:15:48.62ID:91YaR+D7
のようだ
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1026097815
2014/06/17(火) 17:17:56.95ID:AlynCjr8
>>495
英語の基礎も知らない低学歴か

「プロパー社員」と形容詞的にproperを使っても
意味がおかしいのは変わらない
辞書でproperの意味を調べてみろ
2014/06/17(火) 17:58:42.36ID:1K9Dgk3r
>>497
知らねえよｗ
proper employeeとか言い出した外人に文句言ってこいｗ
2014/06/17(火) 19:22:19.70ID:L+TJtcii
パッパラパーはもういいよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況