- Letartóztatták, mert AI segítségével csalt az egyetemi vizsgán
- Betelik a pohár: nagy igény lenne a gyorshajtás-ellenes technológiára
- Synology NAS
- Facebook és Messenger
- SUSE Linux
- Rendszergazda topic
- Sweet.tv - internetes TV
- Kibővítik a várost az ASML kedvéért
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
Mondjuk ehelyett a sok i-1-es szenvedés helyett szerintem szebb lenne úgy, ha 0-tól inicializálnád az i-t, és csak a kiíratásnál, tehát azon az egy helyen adnál hozzá 1-et.
System.out.println("Kerem az " + (i+1) + ". szamot:");
De ne vedd magadra, tudom, hogy az EREDETI kódban javítottad csak a hibát, csak akkor már legyen teljes a korrekció.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
"Igen az utóbbira gondoltam én is, csak a megvalósításában még nem vagyok annyira perfekt"
Nem nagy művészet:
http://prohardver.hu/tema/java_topic/hsz_6769-6769.htmlSk8erPeter
-
Sk8erPeter
nagyúr
válasz
M_AND_Ms #6874 üzenetére
"Csókoltatom a könyv íróját!"
Nem lőttél mellé, nem akarok szemét lenni, de szegénykém egy kókler. Sok tekintetben megragadt a tudása valahol a kilencvenes évek végén, kétezres évek elején, szerintem nem igazán képzi már magát. Ezt onnan tudom, hogy BME-n még régebben felvettem nála egy webfejlesztéssel kapcsolatos tárgyat (kellett a kredit, gondoltam akkor már érdekeljen), és az előadásain a kínok kínját éltem át, amikor például megmutatta a JavaScript-kódjait, és a saját maga által sok-sok éve írt tákolmány fos kódot nem értette, látszott, hogy elakad, agyalnia kellett rajta, hogy az mit is csinál, már nekünk, a hallgatóknak volt égő, készültem rá, hogy jelentkezem, és elmagyarázom neki, mit csinál a saját kódja (de türelmesen vártam, mert így is elég kínos volt a helyzet), de 5 perces hümmögés után valahogy rájött, vagy skippelte a diát. Ősrégi, elavult módszereket alkalmazott, a kódok összecsapottak voltak... na most ennek fényében el lehet képzelni, mennyire lehetnek jók a Java-kódjai és -feladatai. Igazából megdöbbentő számomra, hogy BME-n taníthat (na nem mintha nem lehetne még sok nevet dobálni, akinek finoman szólva nem up-to-date a tudása).Szerk.: az egészből a következtetés igazából annyi, hogy szerintem azt a könyvet nem érdemes komolyan venni, így tanulni sem belőle, bár sosem olvastam, de az előbbi példa lehet, hogy elég is volt rá.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
#92700160 #6963 üzenetére
Nem egy mai csirke az a gép, egy SSD beszerzése, és némi RAM-bővítés egészen biztos, hogy dobni fog a felhasználói élményen, már ha nem érné meg új gépet venni. Az SSD-nek persze van egy olyan előnye, hogy azt át tudod vinni másik gépbe is, tehát az mindenképpen megérné. Tapasztalatból tudom, milyen ugyanaz a gép, amikor HDD-n van minden, és elindítod a NetBeans-t vagy Eclipse-et rengeteg megnyitott projekttel, és milyen az, amikor átkerül az egész SSD-re, brutális a különbség utóbbi javára, jópár hajszállal több marad a fejeden. Ilyenkor az elején ugye végigfutkorászik a projekteken, nem mindegy, milyen olvasási sebességgel kotorászik (meg hát nyilván az írási sebesség sem mindegy).
Egyébként tényleg eléggé OFF-topic.Sk8erPeter
-
Sk8erPeter
nagyúr
"ebben még a 2.0 alapján tanítgatják az embert"
Ez most komoly? Akkor dobd el messzire azt a könyvet. Ez a 24 órás sorozat amúgy is csak felületes gyorstalpalóra jó, nem pedig az alapok normális elsajátítására, meg úgy általában az algoritmizálási képességek fejlesztésére, szóval ha már ilyen gyorspélda-sorozatról van szó, akkor ne ősrégi példák alapján kapj képet a nyelvről.Sk8erPeter
-
Sk8erPeter
nagyúr
Mi volt a bajod vele egészen konkrétan? Amúgy bármilyen másik IDE-re állnál át, mint amit nagyon megszoktál és kiismertél, először gondod lenne vele, és minden totál máshol lenne, szóval annyira nem meglepő, hogy eleinte szarnak találtad. Aethelstone-hoz hasonlóan először nekem is hasonló trauma volt az Eclipse, aztán megszoktam azt is, most meg hogy épp plugint fejlesztek rá, legalább tudom, micsoda egy szar tud lenni.
Pl. az automatikus függőség-felderítés a plugineknél borzalmas, totál hibás, és a legjobban azt szeretem, amikor teljesen általános jellegű exceptionhalmazt kapok pluginfejlesztésnél, vagy amikor magában az Eclipse-ben "törik el" valami, például VALAMELYIK plugin VALAMELYIK része, de nyomozni még a backtrace-ek, logok alapján is elképesztő időigényes tud lenni, hogy mégis mi okozza, és mi oldja meg, és ilyenkor az a remek, hogy gyorsabb egy új, "szűz" Eclipse-példányt letölteni, ismét letölteni a szükséges pluginjeidet, és importálni a beállításaidat. Csak hogy ne tartsa az Eclipse-et sem senki olyan tökéletesnek. Ettől függetlenül megszerettem valamennyire ezt is, bár én a NetBeans-t sok szempontból ezerszer stabilabbnak tartom még mindig, csak az Eclipse-ben sajnos több a lehetőség bizonyos esetekben.
Sk8erPeter
-
Sk8erPeter
nagyúr
Hát ez nagyon furcsa, mert ilyen jellegű instabilitási problémákat soha nem tapasztaltam NetBeans-szel. Eclipse-szel annál inkább (mint írtam, tehát a "VALAMELYIK plugin 'eltört' VALAHOL VALAMI miatt"-szintű exceptionök, rossz függőség-feloldás (ezt konkrétan Xtexttel kapcsolatos plugineknél tapasztaltam), aztán logban, backtrace-ekben túrkálás, feladás, új Eclipse-példány letöltése), tehát számomra az instabilitás az előbb említett dogok miatt inkább igaznak tűnt Eclipse-re, de egyébként ismerősök sztorijaiból kiindulva is megerősítést nyert ez az elképzelésem - nyilván ezzel totálisan ellenkező tapasztalatok is vannak, lásd a Te esetedet. Igaz, a NetBeans-es instabilitási problémák okait tényleg nem értem nálad, fogalmam sincs, mi lehetett az oka. Félreértés ne essék, használom az Eclipse-et, bizonyos szempontokból jobban szeretem a NetBeans-nél, más szempontból meg épp a NetBeans-t szeretem. Egyébként ezek a stabilitásbeli kérdések természetesen felhasználásfüggők is, hogy egyáltalán milyen esetekben van esély rá, hogy előjöjjenek (pl. engem pluginfejlesztésnél halálba idegesít az Eclipse, egy más jellegű projektnél meg simán előfordul, hogy csak úgy megy, ahogy a NetBeans is).
Amúgy még sokan az IntelliJ IDEA-t dicsérik, na ezzel nekem még nincs tapasztalatom, majd adok neki egy esélyt, már kíváncsi vagyok, mitől olyan népszerű.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
polaroi8d #7044 üzenetére
Hidd el, az esetek 90%-ában egy ilyen SEMMI konkrétumot nem tartalmazó hozzászólást ignorálják az azt olvasók, mert az emberek többsége nem fog önként jelentkezni, hogy akkor megoldjon helyetted egy feladatot. Mindenkinek korlátos a szabadideje. De ha bedobnád IDE a kérdést, nem pedig privátban kérnél szívességet valakitől, akkor biztos, hogy lennének többen is, akik segítenének neked.
Sk8erPeter
-
Sk8erPeter
nagyúr
Hű, mennyire egyetértek azzal, amit írtál a tanítási módszerekről. BME-n az egyetem első évében fogalmam nem volt a programozásról, és elképesztő mennyiségű időt kúrtam el az ilyen jellegű fos tanítás miatt (akár az előadásokon, akár a könyvekben), amikor végeláthatatlan mennyiségben hablatyolnak az elméleti háttérről, de még mindig egy sor kódot nem írtam, és nem is értettem, hogy kell megírni egy egyszerű programot, ebből következően az elméletet sem tudtam mihez kötni. Akkor mi a büdös francnak annyit nyomatni az elméletet az elején, ha nem mutatjuk meg a gyakorlatban, hogy mire jó? A legtöbb oktatókönyv írójával az a baj, hogy rohadtul nem tudják beleképzelni magukat a kezdő tanuló helyébe, csak szárnyal a képzeletük, hogy nagyjából hogyan kellene tanítani, de nem néznek utána, hogy vajon az tényleg hatékony-e.
Sk8erPeter
-
Sk8erPeter
nagyúr
Na várj, sztem senki nem mondta, hogy nincs szükség komoly elméleti alapozásra (persze ezt is ésszel kéne, gyakran ez sem elmondható), inkább arról van szó, hogy először meg kéne egyáltalán hozni az egész programozáshoz a kedvedet, nem pedig elvenni azt (akár egy egyetemi/OKJ-s/akármilyen képzésről van szó, akár egy könyvről), értelmes módon kellene vegyíteni a gyakorlati alapismereteket az elméleti háttérrel, de valahogy ez a legtöbbször átcsap abba, hogy kőkeményen nyomatjuk az elméleti bullshitet, hogy legyen mit jól számonkérni, aztán inkább csak úgy mellesleg vannak gépes laborok is, ahol ledarálják, ami kell (elavult eszközök rulez), ha nincs előképzettséged, így jártál, aztán mennek a következő anyagra, csak pörgessük ki a kötelező számonkérhető anyagot. Természetesen ettől még vitathatatlan, hogy saját szorgalom nélkül úgysem fog senki megtanulni programozni, de nem mindegy, hogyan lökdösnek előrébb, vagy csak tömik az agyadat olyannal, amitől csak összevisszaság lesz a fejedben. Ahogy észrevettem, ez nagyon általános probléma.
BME-n azóta szerencsére látok némi javulást az elsősöknek leadott anyagban, ahogy nézegettem a honlapokat. Amikor én jártam prog1-re, elég borzalmas volt a helyzet. Amúgy a kedvencem az volt, amikor az előadó a perifériákról beszélt, hogy hű de jó, hogy van a billentyűzet, meg az egér, 1 perc múlva meg egy C-ben írt kódot mutogatott.Sk8erPeter
-
Sk8erPeter
nagyúr
Azt vágod, hogy a felhasználótól kapott adatot egy az egyben dobálod bele a query-be, escape-elés vagy sokkal inkább prepared statement (rendkívül meglepő módon erre való a PreparedStatement és a Connection osztály prepareStatement metódusa) használata helyett, ezzel fasza kis lehetőséget adva az SQL Injectionre?
http://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html
Meg amúgy a SELECT * használata nagyon nem javasolt sehol. Sorold fel szépen a mezőket, amikre szükséged van.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Ursache #7133 üzenetére
Most ezt kitől kérdezed? Mert megint nem használtad a Válasz linket.
Szokj már rá a használatára légyszi, nagyon zavaró a hiánya (hogy nincs előzménye a hsz.-eidnek a fejlécben), köszi.
Amúgy keress rá Google-ben a "why select * is bad" kulcsszavakra, bőven fogsz találni cikkeket a témában. Röviden: teljesítmény szempontjából nagyon káros tud lenni. Ezenkívül teljesen felesleges minden egyes oszlopot kiválasztani, amikor az esetek 99%-ában nincs szükség mindegyikre. Nem beszélve arról, hogy a mezők egyértelmű felsorolásával kiolvasható a query-ből az is, hogy egyáltalán milyen mezők lesznek elérhetőek (pl. ha már JDBC, a ResultSetből való mezőeléréskor), és melyekre van szükségünk, tehát maga a kód is értelmesebb lesz tőle.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Ursache #7135 üzenetére
"Pár éve olvastam egy etikettet, vagy szabályzatot, miszerint ha az éppen előtted szólónak szánod a hozzászólást, akkor ne használd a válasz gombot. Azóta megváltozott? Vagy a topicra más érvényes?"
Ilyen szabály SEHOL nem volt soha érvényben.Sőt, pont ennek ellenkezője van az alapelvek között is.
http://prohardver.hu/allando/alapelvek.html#jotanacsok
III.12.4.3. "Egy hozzászólásra mindig a Válasz linkkel írj, hogy mindenki láthassa mire és kinek válaszoltál."Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Aethelstone #7138 üzenetére
Így van.
De vágod, nem nekem kell magyarázni, pont emiatt szóltam a kollégának.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7268 üzenetére
Remélem, azért nem szól be, ha egy foreach-ciklusnál (nem sima for) adott esetben használsz breaket... néha vannak emberkék, akik kitalálnak ilyen "szabályokat", hogy legyen mivel lefoglalni magukat.
A kód olvashatóságát pedig ez például nem rontja.
Sk8erPeter
-
Sk8erPeter
nagyúr
"Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést."
Nem véletlenül mondtam az előbb a foreach-ciklust, még ki is hangsúlyoztam, hogy nem sima for ciklusról van szó. Magyarul nincs ciklusfeltétel, kész. Cserébe magának a ciklusnak a "fejléce" szebb tud lenni, nincs szükség indexelésre, és így tovább, hát ugye a foreach-ciklus szépsége. Berakva egy if(...) { break; }-et (nyilván szépen tördelve) semmivel sem lesz rondább, ha az nem valahol egy túl nagyra hízott ciklustörzs (eleve már itt kezdődik a gond) közepén helyezkedik el valahol, teljesen egyértelmű a ciklus megszakítása, szóval nem igazán tudom felfogni, nálad miért nem menne át a kódreview-n. Erre mondtam, hogy sokszor nevetségesek ezek a teljesen rugalmatlan "szabályok". Vannak általános irányelvek, amiktől rondább vagy szebb lesz egy kód, de általánosítani itt is tök felesleges.Sima for ciklusnál teljesen érthető, egy foreach-nél nem, nem lesz tőle rondább a kód, ha a kódot olvasó emberke számára nem egyértelmű, hogy ott bizony valamitől függően kilépés lesz a ciklusból, hát akkor nem a kód írójával van baj.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7278 üzenetére
Teljesen érthető for-ciklusnál, de én még mindig foreach-ről beszélek, gondolom majd azt is fogjátok tanulni.
Sk8erPeter
-
Sk8erPeter
nagyúr
Szerintem tanulmányozd magának a Javának a forráskódját, rá fogsz csodálkozni, hogy TELE van a break kulcsszó használatával ciklusokon innen és túl is.
Na nem mintha azt akarnám sugallni, hogy az biztos a világ legjobb kódjainak gyűjteménye, de valószínűsíthetően nem kókler kretének írják, akik azért használnak breaket, mert buták, és nem tudnak kódolni.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7289 üzenetére
A konzol/terminál tartalmát szeretnéd törölni? Mert Windows-on az a cls bepötyögésével, majd Enterrel megoldható, Linuxnál a clear kulcsszóval.
(Már ha jól értettem a kérdésedet...)Hogy kell elképzelni ezt, hogy mindent konzolon csináltok? nano, mcedit (most ezek Linux-eszközök, de mindegy), vim (bár ezt kétlem), ilyesmik használatával szerkesztitek a kódot?
(#7288) floatr:
A Java-fejlesztőknek nem a hosszú távú támogatás jár a fejében? Ez így furán hangzik.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7291 üzenetére
Jobb gomb az Output ablakban, majd Clear, vagy nyomatsz egy Ctrl+L-t...
Sk8erPeter
-
Sk8erPeter
nagyúr
Ha beírod Google-be a "java interview questions" kulcsszavakat (vagy valami hasonlókat), akkor igen sok találatot fogsz kapni. (Most ezt nem cinizmusból írtam, de tényleg Dunát lehet rekeszteni azzal a kérdéshalmazzal, ami neten fent van megszámlálhatatlan mennyiségű helyen.)
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7342 üzenetére
Akkor valamit nagyon rosszul csinálsz. Vagy a tanárotok egy kókler, hogy nem szól rátok időben, hogy ezt soha ne csináljátok.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7416 üzenetére
"De miért a tanár a hülye, ha ez szerepel a kerettantervben? Csak nem mondhatja azt, hogy screw you és tanítaná azt, ami tényleg értelmes, aztán a hülye tanterv alapján felállított érettségin meg sorban megbukunk"
Az érettségin az ilyen C-szerű kódolást kérik számon Java-nyelven? Nagyon remélem, hogy nem. Ha meg nem, akkor a tanár hülye, hogy olyan szokásokat próbál belétek verni, amik ennél a programozási nyelvnél kifejezetten károsak, és ocsmánnyá teszik a kódot. Ha tényleg ilyet kérnek számon az érettségin is, akkor qrva nagy gáz van az ottani számonkéréssel is.Nem az van, hogy a tanár is most tanulgatja a Javát, és korábban más nyelvben programozott?
A ciklusok, tömbök gyakoroltatására létezne ezerszer értelmesebb és gyakorlatiasabb feladat is.(#7417): tehát akkor most mi is a kódod, ami nem működik?
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7419 üzenetére
És a kerettantervben mi van? Az, hogy gyakoroltatni kell a ciklusokat és a tömbök használatát is, és most épp ott tartotok? Csak mert mint előbb írtam - szerkesztettem a hsz.-t közben -, ezekre ennél SOKKAL értelmesebb és használhatóbb példákat is ki lehetne találni, hogy megértsétek a használatát, meg hogy mire jó. Nagyon nem erre, amit mutattál.
És attól még, mert gyakorlatiasabb példákat vesztek, nem lenne muszáj eltérni a kerettantervtől. Most itt az infós kerettantervet fikázzuk, de még nem említette senki, hogy pontosan mi is van benne, ami szar (nekem most nincs kedvem rákeresni) - biztos egyébként bőven van miért szidni sok tekintetben, de nem ártana némi konkrét információval felvértezve fikázni.
Amúgy most akkor hogyan is alakítgattad a kódodat, ami nem működik? És akkor most mi a gond, hogy nem írja ki az első elemet? Kicsit nekem már zagyva a leírásod.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
norbert1998 #7421 üzenetére
Értelmesebb lett volna, ha egyből egy tesztelhető kódot dobsz be (értsd: mi csak bedobjuk a fejlesztőkörnyezetbe az adott osztály(oka)t, és mehet a teszt), vagy csak a vonatkozó kódrészletet, nem csak simán bedobod ezt az óriási - ráadásul rosszul tagolt - borzalmat (mert lusták vagyunk kibogarászni ekkora kódot, ami ronda is, gyorsabb lenne lefuttatni). Ekkora mennyiségű kód tényleg mehetne pastebinre (ahol bekattintod, hogy Java-szintaxis szerint legyen kiemelve értelemszerűen). Amúgy nem véletlenül mondtuk korábban, hogy bontsd szét a kódodat több metódusra, ez így valami elképesztő ocsmány és átláthatatlan.
(#7423):
Ugyanúgy megoldhatod do-while-lal ezt a feladatot is.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
WonderCSabo #7487 üzenetére
Nekem az a "kedvencem", amikor valaki ilyen magasszintű nyelvben rövidítgeti a változóneveit, mintha nem lenne mindegy akár teljesítmény, akár az IDE autocomplete-je szempontjából, aztán lehet bogozgatni.
Sk8erPeter
-
Sk8erPeter
nagyúr
"Java tray icon" keresőszavakra Google első találata egy Stack Overflow-thread (rendkívül meglepő módon):
http://stackoverflow.com/questions/758083/how-do-i-put-a-java-app-in-the-system-tray
második találata a hivatalos doksi egy konkrét példával:
https://docs.oracle.com/javase/tutorial/uiswing/misc/systemtray.htmlÉs ja, AWT-s.
"JavaFX tray icon" keresőszavakat is nézegethetsz. Itt pl. azt írják kommentben, hogy "JavaFX will get it's own system tray support in a latter release once RT-17503 Provide system tray support is implemented. Until then, using the AWT system tray as demonstrated in the sample code in this gist seems to work fine."
Szerk.: szándékosan nem toolbarra kerestem rá, nekem speciel felhasználóként egy külön eszköztár nem is lenne szimpatikus, már ha megvalósítható (ne terpeszkedjen), sima tray icon viszont igen.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
pvt.peter #7533 üzenetére
Konkrétabban mit takar a "felokosítás"?
(#7528) sutszi:
Jaja, két számjegy viszont simán elfér a tálcaikonon (ld. HWiNFO64 tálcára kirakott kijelzői). Három már elég necces (a töltöttség kijelzésénél mondjuk csak egy esetben van erre szükség, 100%-nál)... Igazából két számjegy esetén állapotjelzésre a tálcaikon a legjobb megoldás, háromnál para. De próbát megér, max. kisebbek lesznek a betűk, vagy 100% esetén egy teljes töltöttséget jelző egyéb ikont mutatsz, nem számot.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Aethelstone #7595 üzenetére
Szerintem a kolléga szándékosan trollkodott.
(legjobb flamewar-keltő megjegyzések az ilyenek, amikor valaki komolyan veszi
)
Hogy a cikkhez is szóljak:
"It started when Oracle sued Google and accused it of infringing on some of its application programming interfaces, including their names (such as the name "max" for the maximum function)."
Az Oracle érintett emberei most megsimogathatják a saját idióta kis buksijukat.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
"Ja, pont akkora őrültség, mint aki a magyar mondataiban nem használ ékezetet.
"
Hehe, hát igen.(#7687) bambano:
"teljes őrültségnek tartom, ha valaki kétféle klavi kiosztást használ..."
Meg ez is jó.(#7683) emvy:
"Teljes orultsegnek tartom, ha valaki HU layouttal kodol"
Jaj, de szeretem az ilyeneket. Mi az a komoly hátrány, ami származik abból, ha valaki átállítja például a toggle comment hotkey-jét az IDE-ben? (Csak egy példa arra, ami mondjuk HU layouttal nem szokott tipikusan működni, de na bumm, körülbelül fél perc átállítani.) Mi az, ami miatt probléma lenne, hogy valaki HU layoutot használ, amikor világéletében ezt szokta meg, mert mondjuk nem élt hosszabb távon külföldön, ami miatt feltétlenül át kellett volna magát állítania más kiosztásra?
Ez nagyjából olyan, mintha beszólok, hogy milyen gyökérség ékezetek nélkül írni, mert amúgy tök idegesítő egy magyar nyelvű fórumon, annak ellenére, hogy nyilván az itt tevékenykedők többsége folyamatosan tudja olvasni az ilyen szöveget is, mivel nem egy túl komoly agyi munka, de akkor is zavaró (másnak nem biztos, nekem például igen, és tudom, "így jártam"). Ha magyar fórumra írsz, miért nem állítod át a layoutot (vagy magadat) magyarra?(#7702): Egy ilyen tényleg nem lehet rossz, de mondjuk itt fura picit, hogy ennyire magasra van emelve, így az ember csuklójának tartása gépeléskor kicsit "megtörik", és nem folyamatos az emelés.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
zsambek #7778 üzenetére
Nem meglepő a NullPointerException, mivel a jatekosok.add() metódust úgy hívod meg, hogy a jatekosok változó nincs inicializálva.
(#7776) Oppenheimer:
Az első bekezdés félreérthető szerintem, ez a thread lehet, hogy felhomályosítja.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
bambano #7781 üzenetére
Igen, jó nagy baromság ezeket kihangsúlyozni, hogy érték szerinti átadás, mert végül is pointert passzolgatunk ilyen alapon, és az eredeti objektumot buzeráljuk, de legalább egy kezdőt tök jól össze lehet zavarni ezzel, és totál nem fogja érteni, hogy most akkor mi van.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
WonderCSabo #7793 üzenetére
Szerintem bambanonak igaza van abban, hogy ez a "MINDIG érték szerinti átadás van Javában" csak egy összezavarásra alkalmas mondat ebben a formában, amitől a kezdő hirtelen nem fogja érteni, mi van, és azt hiszi, hogy egy metódusnak átpasszolt objektumról valamilyen mágikus módon készül egy másolat, és a másolattal fog dolgozni (deep copy nyilvánvalóan nem fog tudni készülni, de ki tudja, hogy a kezdő épp tisztában van-e vele, de már legalább elindítottuk az összezavarás útján), hádepedignem.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
pinnacle #7819 üzenetére
"Javascript engedélyezve van"
Csak hogy ne keverd a kettőt: a Javának semmi köze a JavaScripthez, a kettő nem ugyanaz.------------------
Más:
Ha valaki fejlesztgetett már Eclipse plug-ineket, ahhoz kötődő felületeket, használta esetleg azok közül valaki a JFace-es ILazyTreeContentProvidert pl. egy TreeViewerhez? A lényege az lenne elméletben, hogy ha a felhasználói felületre óriási adatmennyiséget írunk ki pl. egy fastruktúrában (az oka most tök mindegy, kell), akkor az elemek on-demand töltsenek be, akkor, amikor a felhasználó által ténylegesen látható területre kerülnek az elemek - például amikor odagörget az egerével, akkor töltse be a modellből az adatokat. Van hozzá példakód, az abban látottakat alkalmaztam mind (setUseHashlookup engedélyezése, gyerekelemek "manuális" beállítása, stb.), de a gyakorlatban a TELJES struktúrát betölti a memóriába, pedig pont az lenne a lényege, hogy kímélje az erőforrásokat.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #7831 üzenetére
Ja, még annyi, hogy nyilván az SWT.VIRTUAL flag be van állítva.
Mondjuk gondolom erre a problémára túl sok jelentkező nem lesz, de azért próbát megért.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #7832 üzenetére
No, mint kiderült, Eclipse bugról van szó:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340488
Konkrétan a CheckboxTreeViewer rosszul működik sok elemnél az SWT.VIRTUAL flag+ILazyTreeContentProvider használata esetén, és ami rosszabb, StackOverflowErrorhoz vezet, csak hogy örüljön a zzember. 2011-ben reportolt bug, csodás, hogy azóta nincs javítva.A példakód a sima TreeViewerrel jól működik, amint az ember átírja CheckboxTreeViewerre, StackOverflowErrorral hálálja meg.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #7834 üzenetére
"This question was voluntarily removed by its author." - így nehéz.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #7836 üzenetére
Látom senki nem írta le normálisan külön posztban a végső megoldást.
Amúgy majdnem következetesen írtad a components szót componenets-nek.
(#7837) Oppenheimer: me' mé', mit tud? Nem láttam még.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
drogery #7870 üzenetére
Ha jól értem, mit szeretnél, akkor azt gusztustalan reflectionös gányolással lehetne csak megoldani, úgyhogy inkább felejtős. Mi a célod ezzel? Spórolni szeretnél a gettereken/karaktereken, vagy mi?
Ha az is jó, hogy kulcs-érték párok szerint tárolod őket, mert valamilyen módon közösen szeretnéd kezelni a változókat, és át is alakítható a mostani megvalósítás, akkor rakhatod őket valamilyen Map-implementációba vagy Hashtable-be String kulcsok szerint.
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
pvt.peter #7951 üzenetére
Szerintem egyáltalán nem csúnya, hogy külön sorba rakod, hogy mit művelsz azzal a listával, amit majd be szeretnél rakni a HashMapbe. Sőt, gyorsan olvasható, egyértelmű, tiszta, és elkerülsz vele egy tök felesleges plusz metódushívást. A második is jól olvasható, de tény, hogy pazarlóbb. Így egy elemnél aztán tényleg totál mindegy teljesítmény szempontjából, meg láthatóság szempontjából is, de én meg attól kaparom az arcom, amikor olyan kódot kell olvasnom, amikor láthatóan a fejlesztő célja az volt, hogy vagányan mindent minél rövidebbre tömörítsen. Az sem számít, hogy hányszor ismétel azonos metódushívásokat, hány plusz műveletet igényel, de milyen jól mutat, hogy legalább tömör. Hát nem, nem lesz feltétlenül gyorsabban olvasható a kód (persze nyilván bőven vannak kivételek, de ne fossuk már le ennyire a teljesítményt). Tényleg valakinek attól lesz olvashatatlan a kód, mert külön sorban ki van fejtve, hogy mi történik? Az már régen rossz. Magasszintű nyelveknél egyébként nagyon divat(tá vált?) az is, hogy a metódushívásokat egymás után is ismételgetjük, mondván, "nem kell túlpörögni optimalizáció szempontjából", mint a kolléga mondta, ez itt abszolút igaz, de általában ezzel nagyon nem értek egyet. Egyrészt ha ennyire leszarjuk, hányszor történik meg egy-egy metódushívás, akkor az már zsigeri szintű igénytelenséghez vezethet hosszabb távon a teljesítmény rovására, meg azért szépen lehet halmozgatni az ilyen tök felesleges overheadeket, na de minek. (Persze ebben az is szerepet játszik, hogy ebből a szempontból mai napig bennem van a C, C++ tanulásának korszaka, amikor az ilyesmi nem volt menő.)
Pl. ilyesmi:
whatever.doStuff().veryCool().blahblah();
whatever.doStuff().veryCool().wow().great();
whatever.doStuff().veryCool().notCool();
Na itt pl. a whatever.doStuff().veryCool() eredményét el lehetett volna tárolni egy változóba. De nem, ez így tök menő. Ja várjunk csak, mégsem.Szerk.:
Persze simán lehet, hogy az ilyeneket a fordító úgyis optimalizálja.Mindegy, bennem az van, hogy abból baj nincs, ha egyértelműen láthatóvá teszem, mi történik, nekem a pár sorral bővebben hablatyolós kód nem lesz olvashatatlanabb, az agyontömörített kód viszont annál inkább. (Meg a debuggolást is nehezebbé teheti.
)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Aethelstone #7956 üzenetére
Mármint milyen design pattern? Ez a "How to produce spaghetti code and waste resources" design pattern? Vagy inkább nevezzük egy rossz begörcsölődésnek?
(#7955) M_AND_Ms:
Jaja. És mennyivel gyorsabb sorban feldolgozni az infókat, és látni egyenként, hogy mi történik, mint kódátfutás során értelmezni az egybedobált sorokat, ahol ki tudja, még hány egyéb metódushívás vagy más művelet történik. Egyszerűen mész végig a sorokon, és még mindig tudod követni. Amikor viszont agyon van tömörítve a kód, és a szemnek ugrálnia kell, az agynak pedig megjegyeznie egyetlen sor értelmezése közben csomó infót, az fárasztó - és az ember azért elég sűrűn olvashatja munkakörnyezetben másnak a kódját.Amúgy ez az egész kettős: az előző hsz.-emben lévő whateveres példa pont, hogy túl szószátyár és még pazarló is. Számomra sokkal olvashatóbb is lenne az a kód, ha az ismétlődő metódushívások eredményét eltárolnánk egy változóba - amit eleve így illik -, és onnantól kezdve tudnám, hogy kifejezetten azzal akarunk valamit kezdeni, nem kellene mindig végigfutnom a sort odáig, amíg ugyanaz történik, hogy tudjam, hogy most pont ugyanazt babráljuk, csak nem raktuk az eredményt külön válltozóba. (Az ilyennek a lerövidítése egyébként Eclipse-ben annyi, hogy kijelöljük az ismétlődő kódrészt, egy Alt+Shift+L, és létrehozható belőle egy lokális változó, és meg van oldva.)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
PazsitZ #7959 üzenetére
"az a példa szerintem egész eltérő a kiinduló kérdéstől"
Tök igazad van, igazából csak annak kapcsán jutott eszembe ez a másik téma, hogy beszélgettünk arról, hogy mi az, ami "szép", és mi az, ami pl. nekem személy szerint nem bejövős, az eredeti kérdéshez a whateveres példának már tényleg nincs köze. Szóval röviden a lényeg, hogy sokan szeretik agyontömörítgetni a kódot, amikor attól nem lesz jobb vagy olvashatóbb a kód, sőt, jobb lehet inkább szétdobálni, illetve hogy másik oldalról viszont sokan szeretik újból és újból leírni ugyanazokat az ismétlődő kódrészletet, ezzel pont, hogy túlzottan bőlére eresztik a kódot, illetve ez a módszer erőforrások pazarlására is alkalmas (overhead).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #7833 üzenetére
Most jutott eszembe, hogy elfelejtettem megírni, hogy erre sikerült megtalálni a megoldást, hátha valakinek kell, ha a példában a TreeViewert szeretnénk lecserélni CheckboxTreeViewerre, és azt szeretnénk, hogy még működjön is, és ne kapjunk StackOverflowErrort, akkor saját check state providert kell beállítanunk, és a probléma meg is van oldva:
v.setCheckStateProvider(new ICheckStateProvider() {
/**
* TODO: provide complete solution
*/
@Override
public boolean isGrayed(Object element) {
return false;
}
/**
* TODO: provide complete solution
*/
@Override
public boolean isChecked(Object element) {
return false;
}
});Persze az isGrayed és isChecked metódusok visszatérési értékét nekünk kell a saját alkalmazáslogikánk szerint beállítani.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz
Aethelstone #7962 üzenetére
Tényleg nem, de érted, nem attól lesz builder pattern egy kód, hogy láncolva hívogatsz metódusokat (ahogy a kolléga is írta).
Igazából a lényege a példának itt a felesleges "önismétlés" hibájába esés volt, hogy bizonyos - "menetközben" nem változó értéket visszaadó - metódusok visszatérési értékét akár el is tárolhatnánk, hogy spóroljunk némi overheadet, de nem tesszük, mer' nem tom mé'.
Sk8erPeter
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))