- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gban: Ingyen kellene, de tegnapra
- Argos: Szeretem az ecetfát
- Elektromos rásegítésű kerékpárok
- sziku69: Szólánc.
- Magga: PLEX: multimédia az egész lakásban
Új hozzászólás Aktív témák
-
-
#5798
WonderCSabo
félisten
RaPiDsHaRe
#5796
WonderCSabo
félisten
válasz
RaPiDsHaRe
#5796
üzenetére
Egy hiba mindenképpen van benne. Először kiírja 2x a cuccot, aztán csökkenti a számot és még egyszer kiírja. Ez a végén ahhoz fog vezetni, hogy "1 bottles of beer on the wall" is ki lesz írva.
-
#5797
emvy
félisten
RaPiDsHaRe
#5796
válasz
RaPiDsHaRe
#5796
üzenetére
Attol fugg, mit kellene csinalnia
-
#5796
RaPiDsHaRe
aktív tag
RaPiDsHaRe
aktív tag
Hello!
Olvasom az Agyhullam: java címü könyvet. Ebben a kodban még mi a hiba:
Probáltam megkereseni, de nem jöttem rápublic class BeerSong { //14. oldal
public static void main(String[] args) {
int beerNum = 99;
String word = "bottles";
while (beerNum > 0)
{
if (beerNum == 1)
{
word = "bottle";
}
System.out.println(beerNum + " " + word + " of beer on the wall");
System.out.println(beerNum + " " + word + " of beer");
System.out.println("Take one down.");
System.out.println("Pass it around.");
beerNum = beerNum - 1;
if (beerNum > 0)
{
System.out.println(beerNum + " " + word + " of beer on the wall");
}
else
{
System.out.println("No more bottles of beer on the wall");
}
}
}
} -
bucsupeti
senior tag
EE témával kapcsolatban lenne kérdésem. Nemigazán vagyok otthon a témában, most kezdek részletesen belemerülni.
A kérdésem az hogy mi a különbség ha EJB-vel vagy ha az nélkül csinálok egy web alkalmazást? Értem hogy az EJB-k azok önállóan futkorásznak a konténerben és ezeket meg lehet szólítani és a publikált szolgáltatásait elérni. Ebben lehet pl valamilyen perzisztenciakezelőn keresztüli adatbázis elérés stb.
Ugyanakkor csináltam próbaként olyan alkalmazást ami Tomcat-en futott, nem volt benne semmiféle EJB és azzal is tudtam Hibernate-el adatbázist kezelni.
Szóval mi a különbség az EJB konténerben és a WEB konténerben futtatott üzleti logika között?
Értem hogy szebb ha elkülönül ez a réteg, de egyéb más előny/hátrány van? Pl többfelhasználós környezetben tud működni a webkonténeres megoldás? -
#5790
tboy93
nagyúr
WonderCSabo
#5789
válasz
WonderCSabo
#5789
üzenetére
lol
-
Dave-11
tag
válasz
caindwan
#5787
üzenetére
Először én is azzal kezdtem a Java tanulást, de szerintem egy kicsit erős kezdőknek, most nyáron elkezdtem olvasni az Agyhullám - Java című könyvet, ez nagyon jó!
Kicsit lazább hangvételű könyv, vannak benne poénok is, életszerű példák, a leckék végén gyakorlatok és hozzájuk tartozó megoldások.
Csak ajánlani tudom
-
Szmeby
tag
Ha nem akarod mockolni a Commandert, akkor csinálj egy teljesértékű Commander objektumot, amiben persze továbbra is mockolod a mockolnivalót.
Ezt a Commandert pedig nyugodt szívvel leküldheted a tesztelendő osztálynak.
Bár a kódot te látod, neked kell eldönteni, hogy mit lehet és érdemes megcsinálni. Kicsit engem is zavar, hogy több rétegen át kell lemenniük a mockoknak, mert nem lehet másként. -
Szmeby
tag
válasz
Dave-11
#5784
üzenetére
Ha biztosra akarsz menni, akkor a default package-be teszed.
Ami ugye azt jelenti, hogy az osztály a classpath gyökerébe kerül, és elhagyod az osztály első sorában a package sort.
Habár szerintem is a sereg csomagon kívüliségre gondolt, de furán fogalmaz, az biztos. Ha úgy érzed valami speciális illene ide, akkor csak a default package marad. Ki tudja, lehet, hogy előadáson így nevezte a default package-et. Ha így lenne, de te nem így csináltad, akkor viszont mehetsz reklamálni, mert azt nem úgy hívják és különben is odaírhatta volna, hogy pontosan mire gondol. -
#5782
skoda12
aktív tag
aronkatona92
#5778
skoda12
aktív tag
válasz
aronkatona92
#5778
üzenetére
-
#5780
-v-
addikt
aronkatona92
#5778
-v-
addikt
válasz
aronkatona92
#5778
üzenetére
magyar verzióját
Fasza lehet -
#5778
aronkatona92
csendes tag
Szmeby
#5775
aronkatona92
csendes tag
Pont most kezdtem olvasni a clean code magyar verzióját és a felület szónál azonnal eszembe jutott a forum. Amíg nem írt konkrét példát addig fogalmam nem lett volna mire gondol a költő
Általában neten szoktam angolul olvasni, de ez most kivétel.
Van még pár gyöngyszem amit tudnál mondani? -
Szmeby
tag
"Vannak ValamiTask osztályaim, amik mindegyike tartalmaz egy doAction metódust, és az tartalmazza az üzleti logikát, valamint a commander meghívását.
[..]
Hogy oldom meg a TaskTest osztály testDoAction metódusában, hogy az ott példányosított Task osztály doAction függvényében meghívott commander osztály mock objektumokat használjon? Tehát két hívásra to"le."Hát leküldöd neki.
Bár nem látom, hol van itt a második réteg.Ezekszerint nem ilyen a design:
public class Task {
private Commander cmd;
public Task(Commander commander) {
cmd = commander;
}
public doAction() {
// using cmd
}
}Tesztelhetőség szempontjából ilyesmi lenne a célravezető. Konstruktor argumentumként adod le neki a mockot, vagy a mockokat használó Commander példányt és azt csinál majd vele, amit csak akar.
-
Szmeby
tag
válasz
Dave-11
#5773
üzenetére
Az osztályokat csomagokba rendezzük, arról gondolom már volt szó. Bizonyára valamilyen csomagban lévő osztályról beszél (pl.: com.dave.proba.MyClass), és most az idézeted egy az adott csomagon kívül eső osztályra tér rá (pl.: com.dave.MyOtherClass).
Egy osztályt futtathatónak nevezhetünk, ha van pl. main metódusa. De a "futtatható" szó akár a Runnable interfészre is vonatkozhat, ami a szálkezelésnél jön elő, és teljesen mást takar.
Amúgy nem tudom, ennyi információból nem lehet megmondani, max találgatni.
Szerintem ne várj érdemi választ egy kontextusból kiragadott mondatra, akarom mondani 4 szóra.Valószínűleg többre mennél a könyv eredeti (angol nyelvű) változatával. Bár nem olvastam még, de sajnos az a tapasztalat, hogy előszeretettel fordítanak le MINDENT (igen, a keyword-öket is) elcseszett magyar kifejezésekre, így totálisan érthetetlenné téve a szöveget. Persze az is lehet, hogy csak nekem tűnik érthetetlennek, mert én az angol neveken szocializálódtam. Sose hívnám az interfészt pl. felületnek. És ez még a megbocsátható elfordítások közé tartozik. Borzasztó miket ki nem találnak.
-
Sziasztok! Van egy elérési utam, amiből hátulról szeretnék az első / jelig törölni karaktereket.
sdcard/Mappa/Almappa/Masodikalmappa/fajl.txt => sdcard/Mappa/Almappa/Masodikalmappa/
Erre írtam ezt a ciklust:
while(SharedData.choosenDatafileFolder.substring(SharedData.choosenDatafileFolder.length() - 1)!="/"){
SharedData.choosenDatafileFolder.substring(SharedData.choosenDatafileFolder.length()-1), "");
}Ez valamiért ezt eredményezi: sdcard/Mappa/Almappa/ (nem az első / jelig töröl)
Miért csinálja ezt?
-
Karma
félisten
Sőt, ha már reflexióval birizgáljuk őket, hozzá is lehet férni az értékéhez (persze ha nincs security manager az útban).
import java.lang.reflect.Field;
public class HelloWorld{
public static class A {
private int value;
public A(int value) {
this.value = value;
}
}
public static class B extends A {
public B(int value) {
super(value);
}
}
public static void main(String []args){
B b = new B(42);
try {
Field valueField = A.class.getDeclaredField("value");
valueField.setAccessible(true);
int internal = valueField.getInt(b);
System.out.printf("Found value: %d%n", internal);
} catch (Exception ex) {
System.out.printf("Reflection failed: %s%n", ex.toString());
}
}
}Ez az előbbi peremfeltétellel azt írja ki, hogy "Found value: 42".
-
MrSealRD
veterán
válasz
Dave-11
#5766
üzenetére
A kérdés ennél kicsit bonyolultabb.
Itt érdemes megnézni a Private Members in a Superclass című részt.
Tehát az alosztály nem örökli az ősosztály privát tagjait. Azonban ha ezekhez a tagokhoz az ősosztályban írsz public vagy protected metódusokat akkor az alosztály ezáltal hozzáférést kap az ősosztály privát adattagjához...
Ezt egyébként gyakorlati úton is lehet bizonyítani.:
Ha a ClassA-t átírod az alábbi kódban a saját osztályaid nevére, akkor ez kiírja az adott osztály adattagjait. Ez a kód amúgy a stackoverflow-ról van. Van ott pár érdekes kérdés erről a témáról.
Szóval ha lefuttatod akkor látni fogod, hogy az ősosztályodra listázni fogja az adattagokat, de a belőle származó alosztály esetében nem fog megjelenni a listában az ősosztály private adattagjai.public static void main(String[] args) {
inspect(ClassA.class);
}
static <T> void inspect(Class<T> klazz) {
Field[] fields = klazz.getDeclaredFields();
System.out.printf("%d fields:%n", fields.length);
for (Field field : fields) {
System.out.printf("%s %s %s%n",
Modifier.toString(field.getModifiers()),
field.getType().getSimpleName(),
field.getName()
);
}
}De olvastam olyat is ahol azt írták, hogy inkább azt modjuk örökli, de nincs hozzáférése...
-
MrSealRD
veterán
válasz
Dave-11
#5764
üzenetére
Az A osztályodban az adattag private, de a hozzá tartozó getter & setter public. Ezért azok bárhonnan láthatóak. Ez így van jól.
Ha csinálsz egy public adattagot az A osztályban akkor látni fogod, hogy B osztályban el tudod érni getter & setter nélkül... Ez mondjuk nem túl egészséges...de ha tovább olvasol majd meglátod.
A getter & setter lényege pont az, hogy ellenőrzött módon tudj az adattagokhoz hozzáférni...
-
Dave-11
tag
Sziasztok!
Korábban már volt egy kis Java ismeretem, de most nyáron jobban belemélyültem a dologba, éppen az öröklődésnél és az osztályoknál járok. Mindent értek, találtam egy kis dolgot, ami nem tiszta.
A könyv amit olvasok (Agyhullám - Java) azt írja, hogy "A privát tagok nem öröklődnek."
Én írtam egy A osztályt, aminek van egy int típusú privát tagja, és ezt el lehet érni és módosítani két publikus metódus segítségével. Aztán csináltam egy B osztályt, ami az A-t bővíti.
Létrehozok egy B objektumot, de ugye a B objektumnál is meg tudom hívni az elérő és módosító metódusokat, tehát a B mégis rendelkezik azokkal az adattagokkal?
Vagy ez azért működik, mert a B típusú objektum közben egy A objektum is (tehát a többalakúság miatt)?
Vagy hogy lehet a legjobban értelmezni ezt a mondatot? -
boost
veterán
Ja, és az én "rossz" megoldásom az lenne, hogy lebontani ezeket a rétegek beanekre, és akkor lehetne távolról is több rétegen át injektálni a mock-objekumokat.
A szerintem jó megoldás, hogy el kell engedni a többrétegu" unit teszteket, hisz a unit teszt arra van, hogy azt a metódust tesztelje, az abban levo"üzleti logikát, és nem a metódus által meghívott metódusokat, szóval ebben az esetben a commander hívás már egy mock commander lesz. és csak arra koncentrálok, hogy mikor, és hányszor lett meghívva a mock kommander, és ez az eredmény megfelel-e annak, amit vártunk to"le.
-
boost
veterán
Sziasztok, lenne egy kérdésem a Mockito-val kapcsolatosan.
Már nem nagyon foglalkozok Java fejlesztéssel, de most egy BigData projekt kapcsán beleugrottam újra, nagy lelkesedéssel.
Le is érkeztem a gödör aljára.
Szóval egy kis progit írtam, ami különbözo" rendszereket hivogat meg, akár többször is. A különbözo" rendszerek saját zárt api-kkal rendelkeznek.Az összes rendszerhez írtam egy ValamiCommander osztályt, aminek a feladata a külso" rendszerekkel való kommunikáció, és aminek a unit tesztjénél az eredeti helyett mockobjectekkel dolgozok.
pl: FileSystem fileSystem = mock(FileSystem.class); ezután when, meg verify, stb.Ezeket a CommanderTest teszteknél használtam is nagy örömmel. Külön tetszett, hogy nem kellett setter a mock objekthez, hanem beleinjektálta.
Mivel a commander osztály nem tartalmazott üzleti logikát, csak lényegében továbbadta a hívást a külso" APInak, ezért sok értelme nem volt a unit tesztelésnek, de legalább belerázódtam egy kicsit.
Az üzleti logika egy szinttel feljebb van. Vannak ValamiTask osztályaim, amik mindegyike tartalmaz egy doAction metódust, és az tartalmazza az üzleti logikát, valamint a commander meghívását.
ès most jön a kérdés:
Hogy oldom meg a TaskTest osztály testDoAction metódusában, hogy az ott példányosított Task osztály doAction függvényében meghívott commander osztály mock objektumokat használjon? Tehát két hívásra to"le.
Nekem van pár túl gyenge tippem, de szeretném megkérdezni a közönséget is.
-
caindwan
aktív tag
Ezek mik? Sokat latok ilyesfele kifenezeseket javas dolgoknal, de valahogy nem ertem, hogyan kellene oket hasznalni. Ha jol sejtem akkor elore megirt osztalyokrol van szo?
Eddig csak olyan alap java-t tanultam es szeretnek komolyabbat is tanulni (otthon ) es nem tudom merre kezdjek hozza. Gondolom ezek jo kiindulasi pontok lennenek. -
-v-
addikt
Hat eleg szeles a skala szerintem ... van ahol a knowledge transfer mint olyan nem is letezik, van ahol meg tok nagy hangsulyt fektetnek ra. Kollegaktol is fugg, meg attol is, hogy az adott helyen mi a policy erre ... remenykedj hogy jo helyre kerulsz, mert be lehet szopni, plane ha valami ezereves fos legacy codebase van, mindenfele sajat szutykokkal, amik kozeleben se jarnak a szabvanyos megoldasoknak, minden mindennel okosan ossze van drotozva, doksi nulla, design nulla, knowledge transfer nincs, kollegak basznak rad, oldd meg ahogy tudod, aztan mehetsz turkalni nyakig a kakiban ...
Szerintem azert nem ez az altalanos, de van ilyen is. Remelhetoleg baratsagos konyezetbe, meg szakmaikag jo projektre mesz. -
-
floatr
veterán
Nálunk vannak belső téma-specifikus oktatások, de hasonló alapokon megy a dolog, mint az előbb említettek.
A legjobbat akkor teszed magaddal, ha a maradék idődben gyártasz magadnak egy példát, amiben végigviszel pár tutorialban leírt dolgot. Szeretik az aktív embereket, és kevesebbet kell majd másokat nyaggatnod egy idő után.
-
Cathfaern
nagyúr
Nálunk ez úgy zajlott (előző munkahelyemen, jelenlegin nem jött új programozó mióta itt vagyok), hogy az új embert leültettük egy tapaszt programozó mellé. Ő elmagyarázta a keretrendszert amit használtunk, illetve a keretrendszerben lévő saját fejlesztéseket (kvázi mi az amit a keretrendszer doksijában nem találsz meg). Ezt követően 1-2 napig a tapasztalt arc mellett maradt, aki csinálta a napi munkáját, viszont folyamatosan magyarázta, hogy mit csinál. Ha az új ember úgy látta / mi úgy láttuk, hogy menni fog neki egyedül is, akkor kapott valami feladatot, viszont továbbra is a tapasztalt közelében maradt halló és látótávolságra, szóval ha bármi kérdése volt, vagy elakadt, akkor a tapasztalt csak picit odébb gördült a székkel és már látta a monitorát / tudott segíteni.
-
Mukorka
addikt
Hello!
A legtöbb ilyen cégnél vannak kialakult rutinok erre főleg ha gyakornoknak vettek fel. Ahogy én eddig láttam, nem várnak el semmi extrát az elején: Olvastatnak a keretrendszerről, összeraktok egy workspace-t, esetleg kapsz pár nem projekt specifikus feladatot ami utánajárást követel meg (ez alatt meglátják hogy mennyire vagy hülye és aszerint használnak a későbbiekben). Általában segítenek elmagyarázni és hetekig nem is kell nagyon dolgozni. Ismerek valaki aki egy hónapig csak olvasott pedig juniornak vették fel.
-
hablex
újonc
Sziasztok
2 hét múlva kezdek egy 30 fős cégnél mint java gyakornok. Spring MVC-ben fejlesztenek és annak ellenére vettek fel, hogy még csak java SE-t tanulgatom. Az lenne a kérdésem, hogy ilyen helyen általában, hogy zajlik a betanulási fázis. Leülök próbálkozni és néha kérdezhetek vagy heti 1-2 órát magyaráznak? Nem tértünk ki erre, de kíváncsi lennék a tapasztalataitokra.
-
zserrbo
aktív tag
Úgy tudom mindkettő ugyanazt a végeredményt adja: kiírja a 77-es értéket az stdout-ra.
System.out.println(Integer.toString(77));
System.out.println(77);
A Printstream-nek vannak túlterhelt metódusai, ami megoldja:
void println(int x) - Prints an integer and then terminate the line.Akkor tehát ekvivalens a két utasítás?
Persze, ha el akarom menteni pl egy változóba akkor: String s = Integer.toString(111)
-
floatr
veterán
Tudom ajánlani az ExtJS kitchen sink oldalát és a Dijit demót, ha a részletekre vagy kíváncsi.
A core, az adatkezelés, a kommunikációs eszközök sokkal kidolgozottabbak az ExtJS esetében. A komponensek tekintetében a Dijit-nél az összkép elég lehangoló -- olyan mintha félbehagyta volna a tervező, és nem figyeltek volna az eseménykezelésnél a megfelelő sorrendekre.
Az ExtJS-nek nagyon erős a komponens modellje, és eléggé rágyúrtak az OOP-szerű programozási modellre. A Dojo az eseménykezelésre gyúrt rá, de nagyon nem mentek tovább. Az ExtJS komponensek tudása lényegesen nagyobb, és nem elhanyagolható az sem, hogy a Dojo dokumentációja messze elmarad az ExtJS-étől.
Az ExtJS gyengéje a custom design. Ha sajátot akarsz készíteni az összetett komponensekre, akkor az nagy meló. Amennyire látom a Dijit esetében ez kevésbé időigényes, bár az ExtJS alapkomponenseiből elég gyorsan lehet építeni saját összetett elemeket is.
-
-
TedThomas
aktív tag
Sziasztok!
Kezdő vagyok ebbe a java cuccban de örököltem egy rendszert.
Valami tomcat alatt futó java. csatolok alul egy képet róla hátha tudjátok mi ez
Állandóan bele futok a "java heap space out of memory" problémába a szerveren, pedig elvileg van elég memória még.eclipse-be akarnám vizsgálni a memória fogyasztást és akkor azt nézve optimalizálni a kódon.
De ez valahogy nem sikerül. Jvm monitoring fent van, fut a kód de semmi nem látszik benne.
Ötlet?
-
#5738
Fr@nkieWilde
senior tag
boost
#5737
Fr@nkieWilde
senior tag
Köszönöm a gyors választ és benne a segítséget.
Öcsém most végzett szoftverfejlesztőként, ő is azt mondta, meg lehet tanulni, de vagy van készségem hozzá vagy nincs.Ez az ingyenes weboldal pont jól jön (még nem hallottam ilyenekről), hisz valóban nem szeretnék se pénzt, se időt feleslegesen kidobni.
Ezekből van a legkevesebb.Köszönöm még egyszer.
-
#5737
boost
veterán
Fr@nkieWilde
#5736
boost
veterán
válasz
Fr@nkieWilde
#5736
üzenetére
Szia, nem konkrétan Java programozásra válaszolnék, hanem általánosan. A programozás az kicsit túlózva olyan, mint a mu"vészet. Vagy van hozzá érzéked, és akkor megy, vagy nincs, és akkor csak szenvedés lesz. Most már van a neten elég sok ingyen, interaktívan programozást tanító oldal, én ott ugornék neki. Ha beszippant, és tetszik, akkor érdemes foglalkozni a Java-val.
Èn a codeacademy-t ajánlanám neked. Java nincs, de pl javascripttel kezdeni nem rossz, vagy valami más nyelvvel, mint ruby, vagy python. ès ha egy két hét után is megy, és beszippantott, akkor keress valami Java kurzust, hogy beleinvesztálj elég sok lóvét.
-
#5736
Fr@nkieWilde
senior tag
Fr@nkieWilde
senior tag
Sziasztok!
Információ szerzés gyanánt írok ide.
28 éves vagyok. Jelenleg főállásban dolgozom (nem informatikával kapcsolatos állásom van), de a későbbiek folyamán váltani szeretnék.
A JAVA programozással/szoftverfejlesztéssel szemezgetek.Sajnos nincs e téren semmilyen tapasztalatom/tudásom/gyakorlatom. Sőt, soha nem tanultam semmit ami informatikával kapcsolatos.
Minimálisan értek a hardverekhez, de ennyi.Azt szeretném kérdezni, hogy így van-e esélyem, érdemes-e egyáltalán elkezdenem tanulni JAVA programozást?
Érdemes-e pénzt/időt belefektetni? Egy szimpla tanfolyammal sikerülhet-e elhelyezkedni?
Főállás mellett szeretnék tanfolyamra járni. Tudtok-e megnevezni képzési intézményeket, ahol érdemes tanfolyamot végezni? (Budapest)Tehát összefoglalva láttok-e esetleg esélyt arra, hogy a későbbiekben egy sikeres vizsga után JAVA programozóként dolgozhassak?
Köszönöm.
-
boost
veterán
válasz
plaschil
#5733
üzenetére
Azzal tudod a programodat Debuggolni. Azaz elindítod a programot, és ahova elhelyeztél breakpointot ott megáll, majd onnan lépésről lépésre tudod léptetni. Közben egy másik ablakban látod a változók aktuális értékét. Hibakeresésre kíváló. A zöld nyíl azt jelenti, hogy fusson tovább a program, Pause jel futás közben megállítod ( erre inkább breakpoint), piros a teljes program leállítása. A nyilak pedig egy funkcióba való belépést, kilépést, vagy átlépést jelentik. Ezek az alapok. A többihez nekem is el kéne indítani egy eclipse-t.
-
plaschil
aktív tag
Sziasztok!
Az eclipse-ről érdeklődnék, hogy a sárgával jelölt rész micsoda?
Mindig úgy indul az eclipse, hogy ez fut, de mi ez? Ráadásul most töltöttem le. És mindegyik verzióban ott van, alapból. -
bucsupeti
senior tag
Egy olyan kérdésem lenne hogy hogyan, milyen környezetben történik egy szoftverfejlesztő vállalatnál a szoftverfejlesztés? Főként bonyolult EE fejlesztésre gondolok ahol több programozó, designer, stb dolgozik ugyanazon projekten.
Gondolom többen vagytok akik ilyen vállalatnál dolgoztok. Biztosan van valami verziókezelő rendszer stb.
De mégis hogyan adják ki a feladatot, hogyan történik egy-egy verzió build, stb...
Ha egy projekten dolgozik 4-5 programozó, akkor ők hogyan tesztelik a saját maguk részét? Nemhiszem hogy ez csak a teljes projekt futtatásával lehetséges.Én egyelőre csak SE alkalmazásokat készítettem, de érdekel az EE világ nagyban is.
Írnátok erről pár gondolatot?
Azért írom ide mert kimondottan Java környezetben érdekel ez a téma. Nem tudom hogy általánosságban is ugyan azok a dolgok működnek-e, vagy van speckó Java módszer...
-
floatr
veterán
Szerepkörről beszéltem, nem két főből álló teamről, és nem egy teljes projektről, de még csak modulokról sem. A projekten belüli egységnyi feladatok szerepköreinek felosztását próbáltam a felvetés szerint elmondani.
Mi most egy 19-fős projekten dolgozunk egy 3 + 2 modulra bontott projektben, osztott munkában két ismeretlen létszámú fejlesztőcsapattal dolgozó (khm) partnerrel. A feladatok leosztása specifikáció és interfészek mentén van bontva. A belsős csapat ráadásul földrajzilag is osztott. Van 1-2 frontendes, aki a kereteket adja meg, és utómunkákat végez. A feladatok jellege szerint vannak olyanok, akik csak backenddel foglalkoznak, de olyanok is, akiknek a backend + funkcionális frontend egyformán feladata. A helyzetet tarkítja, hogy más projektekbe is be vannak kisebb óraszámok szerint szervezve néhányan. Szóval ha erre vagy kíváncsi, igen kipróbáltam, és arról beszélek, nem amiről álmodok.
szerk: egyébként pont ERP-rendszereknél lehet jó választás az ExtJS, ha van olyan, aki ért hozzá.
-
boost
veterán
En nem kétfo"s csapatokról beszéltem, hanem enterprise környezetro"l. Nem akarok budapesti cégnevet mondani, de 15 éve fejlesztenek egy ERP rendszert, és kb 25 programozó dolgozik rajt 5-6 divizióban.Ha ott még külön mindenkinek designolni kellene, akkro egyrészt sose lenne egységes a rendszer, másrészt az még 10-12 embert jelentene.
-
floatr
veterán
Nem az én elméletem. Gyakorlatban nálunk ez úgy működik, hogy
- vagy egy ember hegeszti a backendet és a frontend funkcionális részeit, és egy "designer" előkészít/utánaigazít
- vagy két ember dolgozik egy specifikált interfész alapján. Az interfész alapján először egy "mockup" backend készül, így egy kis plusz melóval tudhatnak párhuzamosan dolgozni.
Előfeltétel a specifikáció, és hogy mindenki ért ahhoz, amit csinál. Ha a kettőből akár az egyik nincs meg, az nagyon fájó hiányosság tud lenni.
-
boost
veterán
Az elméleted remek, csak gyakorlatba nem mu"ködik.
ÈS nem azzal van a gond, hogy nem tudnak csapatban dolgozni, hanem, hogy 1. drága ( két ember kell hozzá), és 2. nem hatékony (egymásra kell várniuk, fejlesztésnél, és tesztelés/hibajavítás esetén is.A házépíto"s példa: gyakran elo"fordul, hogy nem tudnak festeni a festo"k, mert várni kell a villanyszerelo"re, hogy befejezze a már elkezdett vezetékelést.. csak épp másnál van, mert megcsúszott a melóval. Ezért jó ha a kömüves olyan falat épít, amibe alapból bele van gyártva a vezetékelés.
-
floatr
veterán
Ezzel már mi is sokat kínlódtunk, de egyelőre mindig oda jutottunk, hogy kicsit fel van hígulva a szakma manapság, és sok a töltelékember.
Amúgy pont amiatt mondtam az ExtJS-t, mert az inkább szól programozásról, mint kígyóbűvölésről. Akinek ez sem elég jó, annak ott vannak a generálós megoldások, meg a JSP-s szutykok (bár szvsz a JSP még rosszabb is mint bármelyik tisztán JS-framework)
(#5726) M_AND_Ms az elmélet nem rossz
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
boost
veterán
Mert enterprise környezetben "nem szeretnek" egyszerre a fejlesztok Java-t, html-t, és js-t kódolni. Nem is megoldható, mert nem találsz 10es nagyságrendben olyan fejleszto"t, akik ezekkel a technológiákkal mind tisztában vannak egyszerre magas szinten. Ezért mu"ködik jól a GWT, vagy még a JSF is, ahol erre nincs szükség. Az meg megint nem mu"ködik, hogy egy Change Requestet, ami arról szól, hogy egy mezo"t, kell mondjuk egy "Megrendelés" formhoz hozzáadni 2 részre kelljen bontani, java fejleszto"nek, és HTML/Javascript/CSS fejleszto"nek. Mert akkor vagy párban dolgoztatjuk o"ket, vagy sose lesznek összhangban, és mindenképp ido" és ero"forrás veszteséggel jár.
Ez azért lenne jó, mert fizikailag is szeretném különválasztani a Controller szintet a UI-tól, és pl kipróbálni ezt a Microservices architektúrát.
-
-
boost
veterán
Tényleg, van olyan framework/megoldás, amivel a JSF UI felület teljesen különválhatna a Controller rétegto"l, és REST api-n át, vagy vlahogy máshogy kommunikálnának? Tehát, hogy teljesen külön appba rakni a megjelenítést, de mégis legyen JSF. Ja, és persze valamennyire automatizált.
-
-v-
addikt
Igen hat ez igy van ebben a szakmaban, valtozik folyon, nyitva kell tartania az embernek a szemet, aztan gyorsan reagalni ha valami van ... Akar technologiaval, akar massal kapcsolatban. Eddig nem volt luxus, ha mostantol az lenne valami miatt, akkor nyilvan felturbozom magam javascript ugyben, ennyi.
A rugalmassag meg a tanulas az itt orok, de amig megtehetem hogy ragaszkodok a sajat szempontjaimhoz addig azert valamennyire megtszem, mert nyilvan olyat akarok csinalni, ami szeretek ... De aki azt hiszi, hogy ebben a szakmaban nem kell folyton tanulni, meg valtozni stb. az halott Na meg minel tobbet latott az ember, annal nagyobb a ralatasa. Nem abbol lesz jo architect, aki 15 evig utotte ugyanazt a fos legacy kodot valahol... -
floatr
veterán
Luxus, mert most láthatod, hogy valamire szükséged lenne, amit nem tudsz megkerülni. Persze játszhatod azt, hogy ameddig tudod, másra tolod, vagy ilyesmi, de mostanában egyre népszerűbbek azok, akik több dologhoz is értenek (vagy akarnak érteni).
Szerintem a javafx IS döglődik a többi plugines technológiával együtt. Gyakorlatilag mindenki JS-t használ.
-
-v-
addikt
Nem mondtam, hogy nem talalkoztam vele, sajnos talalkoztam tobbet mint akarnek
De mindig tudatosan es szandekosan kikerulom, ahogy lenyegeben az osszes java fejleszto, akit valaha ismertem. Rossz, nem rossz, ez van, faszom se akar expert lenni javascriptbol ... Van ralatasom szerintem epp eleg, hadd mondjam mar valamire hogy szar, ha az a velemenyem Nem mondtam, hogy ez az objektiv igazsag vagy nekem van igazam ez ugyben, aki szereti csinalja.Mas: javafx ugyben mi a velemenyetek?
-
Jim-Y
veterán
Ez nem feltétlen ui. Mármint.. ha te értesz a javascripthez az nem feltétlen jelenti azt, hogy te gui ninja vagy. Egy normális cégnél, egy javascriptes projekten, mondjuk 1,2 ember foglalkozik a gui-val (=css, html), az összes többi, mondjuk 3 frontend fejlesztő csak az üzleti logikával, megint másik 2,3,5 a backenddel. Ugye a backend lehet bármi. Általában java, webservicekkel, vagy akár nodejs, .net stb...
Az, hogy nem találkoztál a javascripptel eddig igencsak meglepő. A legtöbb enterprise rendszerben, aminek valami köze van a webhez, ott 100%, hogy megjelenik valamilyen szinten a js. Van ahol kevésbé, csak designolás miatt. Van ahol sokkal inkább. Pl apache cordova (alias PhoneGap), vagy ha pl van valamilyen I/O app, arra a legalkalmasabb momentán a node.
Szóval az én véleményem az, hogy egy mai programozónak valamilyen szinten tisztában kell lennie a js-el, mert előbb-utóbb találkozni fog vele. Én nem várnám el mindenkitől, hogy értsen hozzá, de azt elvárnám, hogy rálátás nélkül ne mondja rá, hogy szar, csak azért mert nem ismeri O.o
És igen, szerintem is abban teljesen igazad van, hogy nem az a jó szakember, aki ehhez, vagy ahhoz nagyon ért, majd mindent abban próbál megoldani, hanem inkább az, aki képes felismerni, hogy egy feladatot miben érdemes megoldani, majd az új technológiát képes minél gyorsabban a magáévá tenni.
-
-v-
addikt
Lehet igazad van, de attol ez meg nekem mindig egy fos marad
Persze megszokni mindent meg lehet, meg beletanulni ... De ahogy Winkler szokta mondani, altalaban ezek a "meg kell szokni" dolgok siman csak azt jelentik, hogy szar
Az meg, hogy luxus lenne kikerulni ... Nem tudom, eddig sikerult. Meg sokaknak sikerul, siman nem mennek el UI-t fejleszteni es ennyi. Persze valamikor luxus valamit kikerulni vagy ignoralni, es igen, hulye nem vagyok, hogy ha csinalni kell valamit aminek a legjobb modja jelenleg ez vagy az, akkor azt csak azert kikeruljem mert nem szeretem. Ertelmes mernok ilyet nyilvan nem csinal ...Jo de verpistike kettot akkor mar javascript ui fejlesztonek hivjak ...
De a listat lementem koszi -
Jim-Y
veterán
Lejárt...
Utóbbira, hogy ne csak a szám járjon, álljon itt 2 képzeletbeli eset:
1: vérpistike, aki szerint szar a js, nekiáll js-t használni. Mit csinál? Nyit egy szövegszerkesztőt, mondjuk vi-t, és elkezd javascriptben kódolni valamit, html, css, meg js ugye. Esetleg leszedi a jquery-t, mert a csapból is az folyik. Eset vége, vérpistike elkönyveli magában, hogy szar a js.
2: vérpistike 2, aki azért már eltöltött pár hónapot/évet a nyelvvel, még ha csak elméleti szinten is, követi a nyelv eseményeit, így tudja, hogy milyen hasznos eszközök állnak a rendlkezésére.
1: leszedi a Webstorm-ot, ami egy durván jó IDE javascripthez.
2: felteszi a nodejs-t
3: felteszi a grunt-ot npm-el.
4: beállítja a gruntot automatikus hintelésre, jasmine-al / mocha-val / karma-val megvalósít egy test-driven developmentet.
5: tudja, hogy mit vár el az apptól, tudja, hogy majd milyen web-service-eket akar hívni, milyen funkciókat akar megvalósítani, ezért már előre megírja a teszt-eseteket, és ehhez mérten valósítja meg a funkciókat.
6: vagy használja a browserify-t, vagy a RequireJS-t a modularizációra, így hosszú távon is fenntartható, és könnyen fejleszthető lesz a rendszer
7: leszed valami 3rd party lightweight library-t, hogy a DOM manipuláció egyszerűbb legyen, esetleg valamilyen templating rendszert
8: használja a Kaplan féle grid-et.Hoppá story end, és egy fasza kis kliens app kerekedett belőle.
-
Jim-Y
veterán
Közvetlen alternatíva nincs. Csak a legtöbb compile to js. Még az egyik ami a legígéretesebb a js leváltására az a Dart.
javascript az egy fos
Ebből a hozzászólásodból csak az jön le, hogy nem értesz hozzá, se a dolgokhoz. Ne vedd magadra, de tényleg. Most szar a C#, a Delphi, a Haskell, csak azért mert nem értek hozzá? Mert ennyi erővel ezekre én is mondhatnám, hogy szar...
10 évvel ezelőtt még lehet, hogy szar volt, de napjainkban a js aranykorát éli. Ha valaki tudja a bad habits-et, és azokat kerüli, neadj isten még ismeri a hasznos könyvtárakat, toolokat, akkor igenis nagyon baró cucc.
-
-v-
addikt
"Megint csak sajnálatos - amitől sokan fáznak - hogy a JS-fejlesztésnek sok buktatója van a laza típusosság miatt."
Szepen fogalmazol .... En inkabb ugy mondanam, hogy ez az egesz javascript egy fos szutyok sz*r g*ci szemet, es a lenyeg hogy ne kelljen hozzanyulnom ...
Szerintem egyre jobbal elvalik a UI fejlesztes, fel kell ezekre venni kulon javascriptes embert, mert ertelmes fejleszto nem szivesn nyul hozza ... -
floatr
veterán
Nézd, én nem mondtam soha senkinek, hogy könnyű. Meg kell ezt is tanulni, és kell hozzá tapasztalat. Ha a "könnyebb" utat választanád, akkor vehetsz hozzá designer-t is, de azt is tanulni kell. Lehet jól csinálni, és lehet nagyon rosszul is. Több szintje van a frameworknek: class management, core, alap komponensek, összetett komponensek; utóbbit nem mindig érdemes használni épp hasonló okok miatt, mint ami a vaadin problémája is.
Debugolni, és pofozgatni szerintem lényegesen jobb, mint a többit, csak sajnos nem tudsz odaülni egy 2 órás gyorstalpaló után LHC-vezérlő GUI-t gyártani/debugolni. Megint csak sajnálatos - amitől sokan fáznak - hogy a JS-fejlesztésnek sok buktatója van a laza típusosság miatt. Ez van, ezekből tudsz gazdálkodni.
Mihelyst egy összetettebb UI-ra van szükséged, meg vagy lőve, bármilyen frameworköt használsz, mert vagy elrejt tőled olyan dolgokat, ami idővel kelleni fog, vagy rádönti. Nincs bölcsek köve - itt sem.szerk.: az MVC részét nem feltétlenül érdemes erőltetni, mert kiszervezi a komponensekből a működést, ami szerintem megint egy olyan hiba, ami a hagyományos frontend fejlesztés megszokásaiból ered.
-
-v-
addikt
Hat igen ... Igazabol a spring mvc restes webservicekkel, meg egy extjs mvc a frontenden az tok jo architektura ... Soa-sodik a vilag, meg ez a sofea architectura az kb. pont ez. Nekem csak annyi a bajom, hogy a javascript az egy fos ....kene valami tisztesseges kliens oldali nyelv meg technologia ...
-
Senhi
aktív tag
Én is a JSF + Primefaces kombóra szavazok.
Wicket-tel van még tapasztalatom, kicsit hasonlít a vaadin-ra csak itt a html kódot is részben meg kell írni (JS-t generálja) így a kinézetet sokkal könnyebb személyre szabni. Hátránya, hogy kicsit bonyolult és sok felhasználó esetén figyelni kell, mert a session mérete nagyon megnőhet. -
-v-
addikt
Hat en soha semmivel nem szivtam annyit, mint az extjs-el ... Sose mukodik semmi, meg az se amit a hivatalos doksibol nezek, debugolni pain in the ass ... Persze az egesz javascriptet ugy utalom, ahogy van. Van egyaltalan jelenleg barmi alternativaja amugy JS-nek kliens oldalon? Vagy most tenyleg ez a jovo? :S szvsz nagyon tul vagyunk a javascript lehetosegein, ez az extjs fele mvc framework is egy vicc szerintem ..persze most ezek a JS frameworkok mennek, egyik rosszabb mint a masik.
Generalt ui ... Hat igen. Tegnap ota vaadin ugyben olvasgatok, azert az a fos amit general, meg hogy utana belenyulni meg custom komponenest csinalni pain in the ass ... Na meg azert ez a sok ajax hivas is, nem tudom. De extjs-t meg soha tobbet ...akkor jsf-es irany, primefaces? Grails, wicket, play, ezek mit tudnak?
Kurvara nem latom webappok teren az iranyt, mi lenne a tuti ... Szar mind. SOA-s irany tetszene, meg talan legjobban egy spring mvc-s backend es melle valami jquerys ui? Restes webservicek... -
floatr
veterán
Webes kliensnél? Erre nem fogsz jó választ kapni. Mindenki elmondja a véleményét
A generálás szvsz egyáltalán nem követendő. Manapság van pár divatos frontend platform: AngularJS, JQuery, Sencha Touch/ExtJS, Dojo, meg még sok más hasonló framework. Nekem ezekkel kapcsolatban az a meglátásom, hogy az első kettő elég ingatag, állandó pletykák keringenek a támogatásukkal kapcsolatban. A Dojo egy kicsit komolyabb háttérrel rendelkezik, de a Sencha-hoz képest kevésbé teljes termék.
A Touch/ExtJS nem egyszerű eset, ha tanulni kell, mert a tipikus frontendes számára érthetetlen, hogy szoftveres logikára épül (Java/PHP fejlesztők számára készült inkább), ezért sokan kerülik, bár nálunk ez van majd minden projektben. Sokakat az riaszt, hogy nem GPL felhasználáskor fejlesztői licenc kell hozzá, bár amennyi emberórát elpocsékoltak itt páran JQuery komponensek keresésével/illesztésével, abból kijönne pár licenc.
Mert akkor elég egyértelmű:
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Luck Dragon: Asszociációs játék. :)
- PlayStation 5
- Path of Exile (ARPG)
- Bluetooth hangszórók
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Fejhallgató erősítő és DAC topik
- OLED TV topic
- eBay-es kütyük kis pénzért
- 3D nyomtatás
- Beperelték az Apple-t a részvényesei, mert túlzott az AI-fejlesztések kapcsán
- További aktív témák...
- HP Victus 16-d10008tx 16.1" FHD IPS i7-12700 RTX 3060 16GB 512GB NVMe gar
- Lenovo Legion 5 Pro Gamer Laptop 2év garanciával (i7 13700HX, RTX 4060)
- IPhone 11 Pro max 64GB megkímélt új emelt kapacitású akku!
- Apple Pencil Pro bontatlan 1 év Apple jótállás
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4060 32GB 512GB NVMe magyar vbill gar
- Bomba ár! Lenovo ThinkPad X270 - i5-6G I 8GB I 256GB SSD I 12,5" FHD I HDMI I Cam I W10 I Garancia!
- LG 65" C1 OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- BESZÁMÍTÁS! Gigabyte A620M R5 7500F 32GB DDR5 512GB SSD RX 6700 XT 12GB ZALMAN S3 TG CM 700W
- ÁRGARANCIA! Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Apple iPhone SE 2020 64GB, Yettel függő, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest