- Milyen okostelefont vegyek?
- Xiaomi Smart Band 8 - folyamatosan
- Android alkalmazások - szoftver kibeszélő topik
- Mobil flották
- Redmi Watch 4 - olcsó hús, sűrű a leve
- iPhone topik
- 15 éves az első androidos Samsung telefon
- AGM M7 - elnyűhetetlen okostojás
- Telekom mobilszolgáltatások
- Motorola Edge 40 neo - színre és formára
Hirdetés
-
Konzolokra is megjelenik a Fera: The Sundered Tribe
gp A kooperatív szörnyvadászós játékhoz a minap egy friss trailert kaptunk.
-
Nem fogod kitalálni, mire fókuszál a Dimensity 9300+
ma Spoiler: az AI-ra, ami májusban még az évszakot is megváltoztatja.
-
Az Apple iPadOS-t is megrendszabályozza az EU
it Az EB közölte: az Apple iPad táblagépekre írt iPadOS rendszere is kapuőrnek számít, az üzleti felhasználókra gyakorolt fontossága miatt.
Új hozzászólás Aktív témák
-
-
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.ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
-
TBG
senior tag
Visszafelé egyszerűbb, de aki csak backend-et tud programozni, az nem feltétlenül képes egy SWING/AWT felületet összerakni. Itt már az a szabály, hogy nem elég a Java-t ismerni, hanem az adott framework-ban is büfének kell lenni.
ZTE Grand X powered by Intel® Atom™, Eladó: Panasonic HC-V10 HD+16GB SD kártya 25K.
-
addikt
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.
-
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.
-
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 ideJava 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
-
gygabor88
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.[ Szerkesztve ]
-
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)
-
Karma
félisten
-
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.
[ Szerkesztve ]
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))