Új hozzászólás Aktív témák
-
floatr
veterán
Szerintem meg az amatőr, amikor a saját környezete szerint ítél meg mindent az ember anélkül, hogy megpróbálná elfogadni, hogy van olyan helyzet, amit nem látott még.
Az OS náciságról meg csak annyit, hogy a legtöbben nem imádnak egy OS-t, hanem problémásnak látnak egy másikat adott szempontok szerint. Adott szempontok szerint a win a legjobbabb, mert megy rajta a skyrim. Tapasztalatom szerint java alkalmazások, servlet és bean konténerek, de még egy szimpla AMP stack is észrevehetően pörgősebb binugzon - pláne 64-biten - de szerintem is felesleges ezen a témán pörögni, pláne ebben a stílusban.
-
-
Lacces
őstag
Szerintem, ha értesz a Groovy-hoz, vagy előtte fejlesztettél a Ruby in Rail-ben akkor a Grails-ben lehet "közepes" méretű alkalmazást is készíteni. Kicsiket, szerintem tényleg gyorsan lehet létrehozni.
De valahogy én is úgy látom (bár perfekt nem vagyok még), hogy csak kisebbekhez használható jól és gyorsan.
De majd a nyár végén erre visszatérhetünk, akkor már a Spring-et is ismerni fogom. (Bár a Grails elméletben a Spring-re épül, és ők is támogatják, de valahogy van egy butított hegesztett érzése az egésznek még... nekem)
Azonban a MongoDB driver Grails alá, hááááát, nem olyan jó... (Nekem nem tetszik)
-
skoda12
aktív tag
1. Elegge bugos szegeny. Pl rendszeresen elofordul, hogy ugyanazt a projektet valtoztatas nelkul ketszer egymas utan nem lehet leforditani / futtatni. Ilyenkor ivy cache es a project alatti plugins mappa torlese utan ujra fordul a project.
2. Ivyt hasznal dependency managementhez. Ez nagyon jo, csak ha nalunk mavenes a projekt, akkor feleslegesnek erzem magamra eroltetni ivyt is. Allando kavarodas van, hogy mi kerul BuildConfig.groovy-ba es mi a pom.xml-be.
3. Groovy nagy projektre nem alkalmas. Kis scriptekhez tok jo, pl hogy automatizalt modon hivogassunk jmx vagy rmi metodusokat. Egy csomo mindent elfed a grails es a groovy. Sok helyen osztalyszintu valtozok def kulcsszoval vannak definialva es a grails a hatterben odavarazsol valami objektumot a helyukre. Ami azert baj, mert itt nem latod a tipusat es ezek mar nem String vagy integer valtozok, hanem service objektumok, ahol fontos lenne latni, hogy mi mitol fugg legalabb interface szinten.
4. A kodgeneralasi funkciojanak nem latom ertelmet. Gyakorlatilag annyit general le, mintha eclipseben kivalasztanam a new class funkciot.
5. Nem a programozo hasznalja a frameworkot, hanem a framework hasznalja a programozo kodjat. Nekem ez sosem tetszett.
6. Osszessegeben belassitotta a fejlesztesi folyamatot. -
Lacces
őstag
Szerintem előbb döntsd el, hogy mit szeretnél pontosan a Java-tól és abba az irányba indulj el. A PHP-hoz képest itt nagy a "Birodalom" mérete.
Már maga a Java SE sem kis mennyiség. (GUI-k-ról nem beszélve, annotációk, amelyek a gyenge pontjaim, stb. Könyv függő, hogy mit sorolnak ide
Java EE végül is durván mondva, API-k gyűjteménye, párat már Modder is írt. (Najó talán az alapokat, a nagyon-nagyon alapokat érdemes átnézni esetleg egy szakdolgozatból, hogy elméletileg tud, hogy mi az. Amikor olyanokról beszélnek, hogy komponens, konténer, szervlet stb.)
Cég függő, hogy melyiket használják a Spring és a Java EE közül. Bár lehet a pénzszektorhoz a Java EE kell. Mondjuk a Morgan Stanley Spring szakembereket keress.
Ha webes alkalmazások érdekelnek akkor én inkább a Grails-et javasolnám. Egyszerű szimpla és a Spring-re épül (na meg az a csapat is fejleszti
). Java EE esetén meg ott a JSP és a JSF is... (itt viszont az ASP.NET-tel mutatt rokonságot... JSF az olyan Webforms benyomást kelti a JSP pedig az (asp.net)MVC és PHP benyomását). Grails-nél keveset kell a config fájlokban lennem És ott van még a fentebb említett nagy vállalati "irány" is.
Bár még én sem vagyok pro, de szerintem az irányt nem árt tudni
-
modder
aktív tag
Helló,
Nem.
A spring Java EE-től független technológia. Ugyanarra találták ki, mint ami ma a Java EE, még az előtt, hogy a Java EE igazán használható lett volna. Helyettesítő technológiák.Ugyanakkor, ha készítesz egy Springes alkalmazást, megvan a lehetőséged, hogy Java EE technológiákat használj benne. Például a JPA egy Java EE specifikáció, de mára annyira kiforrott (és persze mert java standard), Springes alkalmazásokban is használják ORM rétegnek.
Ha elsősorban Springet akarsz használni, akkor spring tutoriallal kezdd. Csak akkor olvass Java EE tutorialt, ha olyan technológiába ütközöl.
-
Visszafelé könnyebb átállni. Egy webes alkalmazás sokkal összetettebb, mint egy asztali, a fejlesztése magasabb szakmai felkészültséget követel meg. Asztali alkalmazásnál igazából csak a swing-es osztályokat kell megismerni, meg érteni az Event dispatching thread működését.
-
-
TBG
senior tag
Nem következik. A webes alkalmazásfejlesztés Java-ban egy teljesen más műfaj. Ahogy a kolléga is írja, a GWT áll a legközelebb hozzá, de HTML/JS ismeretek ott is elengedhetetlenek.
Egyrészt kell egy erős backend ismeret...minimum Servlet szinten, de a különféle EE környezetek ismerete is erősen ajánlott.
na mindegy.
Sorry...magas labda volt 
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Azonnali készpénzes Intel i3 i5 i7 i9 8xxx 9xxx processzor felvásárlás személyesen / csomagküldés
- BESZÁMÍTÁS! ASUS ROG Ally Z1 Extreme 512GB SSD játékkonzol garanciával hibátlan működéssel
- Csere-Beszámítás! Számítógép PC Játékra! I5 14400F / RTX 4060ti 16GB / 32GB DDR5 / 1TB SSD
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged