mboost-dp1
Java EE survey results
http://www.zeroturnaround.com/java-ee-productivity...
Nogle af resultaterne er ikke overraskende. Men der er flere som overrasker mig:
- at Maven har overhalet Ant som build tool
- at der redeployes så meget i udviklingen (tilsyneladende er windcape ikke den eneste som har fokus på det)
Nogle af resultaterne er ikke overraskende. Men der er flere som overrasker mig:
- at Maven har overhalet Ant som build tool
- at der redeployes så meget i udviklingen (tilsyneladende er windcape ikke den eneste som har fokus på det)
Jeg er ikke helt sikker på om jeg forstår den med redeployes. (Jeg laver åbenbart ikke så meget Java web) Mener man en redeploy når man laver deploys til test server? Eller er det også en redeploy når man afvikler tingene i sit lokale miljø? (Således at hver redeploy illustrerer en test-eksekvering. Både systematisk og ad hoc?)
Personligt ville jeg mene at det først er en deploy, når koden bliver eksekveret i eksternt miljø, parat til at blive testet af de systematiske tests. Men det kan vel næppe være dem, man laver 4 af i timen.
Personligt ville jeg mene at det først er en deploy, når koden bliver eksekveret i eksternt miljø, parat til at blive testet af de systematiske tests. Men det kan vel næppe være dem, man laver 4 af i timen.
Jeg er lidt overrasket over brugen af JSF (Som er repræsenteret i form af JSP + Wicket + Seam??)
Det er virkelig smertefuldt at arbejde med.
Og god damn, deployment tiden for Java EE er skræmmende.
JSF og GWT kræver også at de redeployer i lokalt miljø for at teste ændringer. (F.eks. en layout ændring i HTML delen, super sjovt at skulle vente 5min på det , ikk?)illishar (2) skrev:Eller er det også en redeploy når man afvikler tingene i sit lokale miljø?
Det er virkelig smertefuldt at arbejde med.
Og god damn, deployment tiden for Java EE er skræmmende.
Windcape (3) skrev:JSF og GWT kræver også at de redeployer i lokalt miljø for at teste ændringer. (F.eks. en layout ændring i HTML delen, super sjovt at skulle vente 5min på det , ikk?)
Hrmmmm....
Jeg ved ikke helt hvorfor det tager 5 minutter at deploye for dig, eller hvorfor det overhovedet er nødvendigt (at gøre det ofte).
Med en konfiguration af Tomcat server i Eclipse JEE, så tager det ikke mere end 20-30 sekunder at genstarte serveren (de gange hvor dine kodeændringer ikke umiddelbart kan ændres).
Kan ikke se nogen grund til at genstarte eller redeploye til din server for GWT ændringer, hvor ofte kan din hostpage ændre sig? Kør blot GWT i developer-mode og så skal du bare refreshe din browser for at se dine ændringer slå igennem.
Vel og mærke kun hvis man har et browser plugin installeret.Corholio (6) skrev:Kør blot GWT i developer-mode og så skal du bare refreshe din browser for at se dine ændringer slå igennem.
Og så skal man lige acceptere at browseren fryser i 30 sekunder mens den redeployer samtidigt.
Oh the joy of GWT!
Som jeg har fortalt Windcape mange gange før:
Jeg arbejder med J2EE til dagligt. De fleste ændringer testes på denne måde: ctrl+s, alt+tab, f5. Hvis jeg virkelig gør det så hurtigt jeg kan, kan jeg nogle gange nå at få at vide at den ikke er klar. (Forresten, jeg har fået en langt hurtigere PC siden sidst jeg prøvede.)
Kan det ikke gøre det, kan det typisk klares med to klik og at vente 5-10 sekunder.
Meget sjældent (ikke hver uge) er jeg nødt til at genstarte min test-server. Det tager vist knap 5 minutter.
Det er ikke J2EE i sig selv der er problemet.
Jeg arbejder med J2EE til dagligt. De fleste ændringer testes på denne måde: ctrl+s, alt+tab, f5. Hvis jeg virkelig gør det så hurtigt jeg kan, kan jeg nogle gange nå at få at vide at den ikke er klar. (Forresten, jeg har fået en langt hurtigere PC siden sidst jeg prøvede.)
Kan det ikke gøre det, kan det typisk klares med to klik og at vente 5-10 sekunder.
Meget sjældent (ikke hver uge) er jeg nødt til at genstarte min test-server. Det tager vist knap 5 minutter.
Det er ikke J2EE i sig selv der er problemet.
#11
Ja, du har ret (some sarcasm may be applied):
GWT's muligheder med:
- deres MVP framework
- UIBinder
- Localization support
- Deferred binding
- Obfuscation
- Browser optimering
m.fl.
Det kan enhver codemonkey lave med den ene hånd bundet bag på ryggen. (dermed antager jeg ikke at der ikke findes javascript frameworks der prøver på at gøre det samme).
Ja, du har ret (some sarcasm may be applied):
GWT's muligheder med:
- deres MVP framework
- UIBinder
- Localization support
- Deferred binding
- Obfuscation
- Browser optimering
m.fl.
Det kan enhver codemonkey lave med den ene hånd bundet bag på ryggen. (dermed antager jeg ikke at der ikke findes javascript frameworks der prøver på at gøre det samme).
Hvilket er en elendig ide, som kun viser der er flere aber i verden der kan kode middelmådig Java, end ordenligt JavaScript.arne_v (13) skrev:Hele ideen i GWT er at det er bedre at skrive Java kode end JavaScript kode.
JQuery + ASP.NET MVC2 er allerede mange gange nemmere, og mere simpelt, end hvad GWT tilbyder.
Hele grunden til GWTs eksistens er jo netop, fordi at Google så slipper for at omskole en helt masse Java programmører til at kunne kode JavaScript.
#14
Det er jo et synspunkt.
Der er ikke alle som er enige, men det er stadig et synspunkt.
Men jeg kan ikke se at det giver meget mening at argumentere for hvordan GWT skal bruges udfra en forudsætning om at ideen i GWT er forkert.
Windcape (14) skrev:Hvilket er en elendig ide, som kun viser der er flere aber i verden der kan kode middelmådig Java, end ordenligt JavaScript.
JQuery + ASP.NET MVC2 er allerede mange gange nemmere, og mere simpelt, end hvad GWT tilbyder.
Det er jo et synspunkt.
Der er ikke alle som er enige, men det er stadig et synspunkt.
Men jeg kan ikke se at det giver meget mening at argumentere for hvordan GWT skal bruges udfra en forudsætning om at ideen i GWT er forkert.
Windcape (14) skrev:Hele grunden til GWTs eksistens er jo netop, fordi at Google så slipper for at omskole en helt masse Java programmører til at kunne kode JavaScript.
Jeg tror faktisk at Google har JavaScript ekspertise i huset.
De har trods alt lavet et par JavaScript apps, som har været gode nok til at skaffe nogle få brugere: GMail og Google Docs.
Det var mere fordi at jeg ikke ser nogen fordel overhovedet i at bruge GWT hvor man ikke benytter serverdelen.arne_v (15) skrev:Men jeg kan ikke se at det giver meget mening at argumentere for hvordan GWT
Det har de.arne_v (16) skrev:Jeg tror faktisk at Google har JavaScript ekspertise i huset.
Men de har også en masse Java programmører som ikke kan kode JavaScript, og derfor bruger GWT.
Windcape (9) skrev:Og hvad myplacedk forsøger at sige, er at han er uenig med det survey der linkes til i #1
Lad være med at fortælle hvad jeg siger.
Det kunne have fremgået tydeligere, men det var ikke #1 jeg kommenterede, det var dig.
Hvis jeg skal hive et citat ud fra denne tråd, så må det være:
Windcape (3) skrev:Og god damn, deployment tiden for Java EE er skræmmende.
#redeploy tid
Tiden afhænger jo meget af:
* udviklings kontekst
- udvikling i server dir
- build og deploy af single war med mockup backend
- build og deploy af fuld ear med alle war,ejb jar og rar
* server model:
- JSP compile + EJB stub generering ved build
- JSP compile + EJB stub generering ved deploy
- JSP compile + EJB stub generering ved first call
* projektets størrelse
Tiden afhænger jo meget af:
* udviklings kontekst
- udvikling i server dir
- build og deploy af single war med mockup backend
- build og deploy af fuld ear med alle war,ejb jar og rar
* server model:
- JSP compile + EJB stub generering ved build
- JSP compile + EJB stub generering ved deploy
- JSP compile + EJB stub generering ved first call
* projektets størrelse
Windcape (17) skrev:Men de har også en masse Java programmører som ikke kan kode JavaScript, og derfor bruger GWT.
Har du nogen kilde til hvor Google folk siger at det er fordi deres Java folk ikke kan JavaScript fremfor at det skulle være fordi at de kan lide det mere type safe i Java?
#GWT client og server side
GWT client side er reelt mere en app som kører i JavaScript engine end en traditionel web app.
Jeg er generelt meget skeptisk overfor stor afhængighed mellem client og server.
Det er sikkert nemt at bruge GWT både client og server side.
Men man får noget mere frihed hvis man:
- designer et API mellem client og server
- implementerer client i GWT
- implementerer server i Java EE
Så kan man udskifte GWT client med et JavaScaript framework og lidt håndkodet JavaScript uden at ændre server delen - og man kan udskifte server delen med PHP uden at ændre client delen.
GWT client side er reelt mere en app som kører i JavaScript engine end en traditionel web app.
Jeg er generelt meget skeptisk overfor stor afhængighed mellem client og server.
Det er sikkert nemt at bruge GWT både client og server side.
Men man får noget mere frihed hvis man:
- designer et API mellem client og server
- implementerer client i GWT
- implementerer server i Java EE
Så kan man udskifte GWT client med et JavaScaript framework og lidt håndkodet JavaScript uden at ændre server delen - og man kan udskifte server delen med PHP uden at ændre client delen.
#23
Det mener du.
Men der sal nok være andre med en anden mening.
Jeg ved ikke hvorfor de droppede det.
http://projects.nikhilk.net/ScriptSharp eksisterer stadigvæk.
Windcape (23) skrev:Men så er det virkeligt ikke besværet værd at bruge GWT.
Det mener du.
Men der sal nok være andre med en anden mening.
Windcape (23) skrev:Jeg sætter på det var samme grund til at Microsoft droppede deres Project Volta.
Jeg ved ikke hvorfor de droppede det.
http://projects.nikhilk.net/ScriptSharp eksisterer stadigvæk.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund