- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Feltalálta a Google a keresőmotort
- Huawei Watch Fit 5 Pro - jó forma
- Samsung Galaxy Watch8 és Watch8 Classic – lelkes hiperaktivitás
- Apple Watch
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Poco F8 Ultra – forrónaci
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Huawei Watch Fit 3 - zöldalma
Új hozzászólás Aktív témák
-
fatal`
titán
És vajon miféle mondandó lehetett a hsz. mögött?
Ha valaki érti a hozzászólást, akkor szóljon, mert én nem tudom hova tenni
-
bambano
titán
"továbbá rendesen tudni kell az enterprise java beans cuccokat, mavent, antot [...] webservice-k távoli hívását, ldap kezelést jávából [...] clusterezett glassfish-t"
Szerintem ezek kiesnek a "junior" fejlesztőtől elvárhatóak köréből, legalábbis normális esetben - ezekkel együtt már inkább "medior" lehetne, vagy mi a búbánatnak szokták ilyenkor hívni. Enterprise JavaBeans cuccok szerintem végképp nem várhatóak el juniortól, akkor inkább hagyják el a "junior" szócskát az állásajánlatból.Azt tartanám én is normálisnak, ha valóban juniort keresnek, amiket Aethelstone kolléga is írt, hogy látsszon, hogy rendesen vágja a Java-alapokat, és van esze a tanuláshoz, tehát összességében egy jó befektetésnek tűnik, aki hosszabb távon behozza az "árát" (amibe a tanulása kerül, tehát hogy lassabb, eleinte kevésbé produktív, de nyilván kevesebb is a fizetése, mint egy régebb óta a cégnél dolgozó emberkének).
a valódi kérdés nem az, hogy szerinted vagy szerintem mi a junior, hanem az, hogy aki majd megkérdezi, szerinte mi a junior
szerintem a junior az, akinek adott fejlesztés alatt álló szoftver esetén megmondják, hogy mi a konkrét feladata (írd meg ezt a 32 darab getter/settert) és azt végre tudja hajtani. a következő lépés, amikor már nem csak konkrét feladatokat tud elvégezni, hanem bizonyos fokig önállóan képes fejleszteni a programot, általánosabb feladatmegfogalmazásokat is képes megoldani (csinálni kell egy authentikációs modult, kb. így meg így működjön, ezek a paraméterek, stb.). ez a közepesen átsült szték vagy medium vagy mi...
szerintem nem az a junior, akit egyáltalán nem lehet használni a fejlesztéshez, csak betanul.
-
Atlantisz48
őstag
Mert projektet kell létrehozni, és annak részeként fordítani+futtatni (ez így szokott lenni az IDE-knél).
Rendben, köszönöm.
-
mobal
nagyúr
Amikor a céges környezet, és/vagy konkrétan Eclipse-re épülő UI* miatt Eclipse-hez vagy kötve, akkor nem fogsz Ideát használni.
*: vágod, van ilyen lehetőség, hogy az Eclipse modularitását kihasználva, saját plugineket készítve lehet az Eclipse API-t kihasználva készíteni arra épülő alkalmazásokat. Maga az Eclipse, mint fejlesztőkörnyezet, nem meglepő módon ugyanerre épít.
Egyébként szerintem is fasza az Idea, de a munka nem mindig úgy van, hogy azt használsz, ami neked tetszik.
(#8007) M_AND_Ms:
És akkor, amikor rácsodálkoztál, azt reagálta, hogy ő mindig hibátlan kódot ír, és a kollégái is?
Amúgy ez elég durva, gondolom akkor ha mégis valahol hibát fedez fel, kiírogatással próbál szerencsétlenkedni, vagy fogalmam sincs, de azért ugye az ilyenek is az átlagnál magasabb fizetéssel elég jól elvannak, miközben finoman szólva nem emelik a szakma színvonalát...(#8011) ToMmY_hun:
Köszi, végre nem csak én képviselem ilyen határozottan ezt az álláspontot. -
ToMmY_hun
senior tag
Egyetértek, szerintem is. Mondjuk ezt már kezdőként is kéne erőltetni. Ráadásul itt sokszor nem is kis overheadről van szó, sokszor látok olyasmit is leírva, hogy mondjuk 4 ismétlődő metódushívás történik láncolva háromszor egymás alatt, különböző sorokban (ergo ez már 12-szeri beleugrás a metódusba), vagy hogy adott, hosszabbra sikerült metódus törzsén belül lazán le van írva vagy 10-szer, hogy getValami(), miközben az pontosan ugyanazt a referenciát/értéket adja vissza. Ilyenkor az a magyarázat szokott jönni, hogy há' de az nem számít, mit kell itt ilyeneken pörögni, meg takarékoskodni, kit érdekel, stb., pedig ezek az overheadek olyan szépen egymásra tudnak épülni, hogy rossz nézni a végeredményt (nem beszélve arról, amit említettem, hogy ez zsigeri szintű igénytelenséghez vezet hosszú távon). Magasszintű nyelveknél sajnos elég elterjedt szokás magasról lefosni a mikrooptimalizációt.
De van, aki nem hajlandó befogadni ezt.
Pedig eléggé könnyen ki lehet deríteni mi a jó megoldás, leprofilozza az ember a kódot és voila'. Az optimális kódírásnál meg az arany középutat kell megtalálni a gyorsaság és olvashatóság között az aktuális nyelven, aktuális feladat függvényében. Nyilván egy real time képfeldolgozó rendszer esetén egy ilyen overhead is nagyon sokat számít, egy desktop Java app esetén, ahol mondjuk az első körös inicializálásnál fut le egy ilyen kód, ott magasról tenni lehet rá. Ahogy írtad ez inkább amiatt fontos, hogy ne szokjuk meg a lustaságot.
-
ToMmY_hun
senior tag
Amikor a céges környezet, és/vagy konkrétan Eclipse-re épülő UI* miatt Eclipse-hez vagy kötve, akkor nem fogsz Ideát használni.
*: vágod, van ilyen lehetőség, hogy az Eclipse modularitását kihasználva, saját plugineket készítve lehet az Eclipse API-t kihasználva készíteni arra épülő alkalmazásokat. Maga az Eclipse, mint fejlesztőkörnyezet, nem meglepő módon ugyanerre épít.
Egyébként szerintem is fasza az Idea, de a munka nem mindig úgy van, hogy azt használsz, ami neked tetszik.
(#8007) M_AND_Ms:
És akkor, amikor rácsodálkoztál, azt reagálta, hogy ő mindig hibátlan kódot ír, és a kollégái is?
Amúgy ez elég durva, gondolom akkor ha mégis valahol hibát fedez fel, kiírogatással próbál szerencsétlenkedni, vagy fogalmam sincs, de azért ugye az ilyenek is az átlagnál magasabb fizetéssel elég jól elvannak, miközben finoman szólva nem emelik a szakma színvonalát...(#8011) ToMmY_hun:
Köszi, végre nem csak én képviselem ilyen határozottan ezt az álláspontot.Igen, ez totál egyértelmű dolog. Nem szimpatikus hogy a Java programozók ennyire el vannak kényelmesedve. Javaslom az áttekintést a C++ fórumba. Ott napokig megy a vita azon is, hogy egy pre vagy poszt inkrement jelent-e nagyobb overhead-et. Valahogy így kellene hozzáállni, hogy idővel valaki seniornak mondhassa magát.
-
mobal
nagyúr
Viszont gyorsabbá teszi a debuggolást, ha változóba van kirakva, amikor odateszed a breakpöttyöt.
(Már szinte várom előre is a "dehülyevagy-hádeménemdebuggolsz rendesen, az Expressions fület használva, meg mé' nem használod a Ctrl+Shift+D-t Eclipse-ben, a megfelelő kifejezést kijelölve", meg hasonló okosságokat. )Eclipse debuggere?
Ne vicceljünk már! Idea! -
Aethelstone
addikt
Viszont gyorsabbá teszi a debuggolást, ha változóba van kirakva, amikor odateszed a breakpöttyöt.
(Már szinte várom előre is a "dehülyevagy-hádeménemdebuggolsz rendesen, az Expressions fület használva, meg mé' nem használod a Ctrl+Shift+D-t Eclipse-ben, a megfelelő kifejezést kijelölve", meg hasonló okosságokat. )Debug? Úri huncutkodás, az igazi programozó jó kódot ír
Viccet félretéve, igazad van -
Aethelstone
addikt
Nem tudom, mire célozgatsz, de ha még mindig tényleg nem érted, én sem akarlak megsérteni, de próbáld meg talán értően elolvasni még egyszer, amire reagálgatsz már egy ideje, hogy eljuss odáig, ahova a többiek már jól láthatóan eljutottak...
![;]](//cdn.rios.hu/dl/s/v1.gif)
De most tényleg, nem tudom, mit nem lehet felfogni azon, hogy a metódusok visszatérési értékét tároljuk már el a bánatba nyomorult változókba, és ne hívogassuk már ugyanazokat a fostos metódusokat újból és újból az eltárolt visszatérési érték felhasználása helyett. -
Aethelstone
addikt
Most kicsit nehéz eldönteni, hogy tényleg nem érted, miről vakerászok, vagy csak szívatsz.
Megsérteni nem akarlak, ezért inkább azt választom, hogy nem értem, hogy miről vakerálsz
Persze, nyilván van még opció, de mint említettem, nem akarlak megsérteni Peace -
Aethelstone
addikt
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é'. -
pvt.peter
őstag
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. )Köszönöm a részletes válaszodat.
-
Sk8erPeter
nagyúr
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.
-
Aethelstone
addikt
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.)
-
Aethelstone
addikt
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. )Az a buli, hogy a whateveres példád Java-ban egy design pattern
-
M_AND_Ms
veterán
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. ) -
drogery
tag
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.
-
PumpkinSeed
addikt
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.
Nem, de az nem baj, meg igazából elég nagy anomália az is, hogy mikor elkezdem átméretezni a frame-t a rajta lévő vonal eltűnik.
-
#39560925
törölt tag
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.
szép a színe
-
DNReNTi
őstag
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.
"appéication"
-
PumpkinSeed
addikt
"This question was voluntarily removed by its author." - így nehéz.
-
Sk8erPeter
nagyúr
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
nagyúr
"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.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. -
emvy
félisten
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.
-
bambano
titán
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.ok, tehát a jávában mindig referencia szerinti átadás van, amit ők érték szerinti átadásnak neveznek.
-
emvy
félisten
"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.
Ezerfelekepp lehet donteni/allitani. Normal billentyuzetekkel nekem elegge megfajdul a csuklom, az MS Natural a legjobb idaig, de az sima membranos, ez meg mechanikus. Mondjuk 200 euro folott van szallitassal, dehat a cipo, asztal, agy, szek, billentyuzet, monitor es eger a legfontosabb targyak az ember eleteben.
-
Aethelstone
addikt
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.Itt az Oracle a legnagyobb troll
-
pvt.peter
őstag
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. Szia!
Hát eddig C#-ban dolgoztam, most viszont belekell ugranom Javaba is.
Tehát adott egy forráskód elemző, amely Javaban lett írva és egy másik nyelvből húz fel forráskód alapján egy AST -t.
Adott node -nak rendkívül sok függvényét tudjuk meghívni.
Nincs kedvem ezeket kézzel leírogatni és változót létrehozni és arra gondoltam, hogy van-e esetleg vmi automatizált módszer arra, hogy ezeknek a függvényhívásoknak az eredményét megtudjam vizsgálni?
Természetesen csak a paraméter nélküli fgvekről van most szó.
Elég sok öröklődés van benne meg változó meg minden eltorzult dolog -
MrSealRD
veterán
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. 
Azóta nem is tudtam foglalkozni a kis projekttel... meg más irányt kezdtem el kidolgozni. Javafx-ben használható patterneket kerestem... Bár ne tettem volna...Bele se gondoltam a 100-ba így hirtelen. Lehet akkor valami zöld lámpa jel lenne ott lent...az tetszik is.
-
MrSealRD
veterán
"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.
A második találat megvolt. A többit meg azért nem találtam meg mert nem "java tray icon" kifejezéssel kerestem.
Nagyon a toolbar felé mentem... A tray icon nem valami nagy...legjobb esetben is egy kétjegyű szám fér bele... Így állapotjelzésre nem a legjobb. Köszi ezen irányú véleményed. Még átgondolom a koncepciót. -
norbert1998
nagyúr
É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.
Én nem ismerem, a tanárOK mondják, hogy rémes a kerettanterv
Szóval, annyit javult a helyzet, hogy most ha a gazda neve, kor vagy tömeg alapján keresek, akkor tökéletes, viszont ha név alapján, akkor a név tömb első elemét valamiért ignorálja. Az egész beolvasás procedúra tulajdonképpen ugyanaz az összes tömbnél, továbbá ha csak szimplán kiiratom azt a tömbelemet, akkor ott van rendesen, hogy Füsti (vagy akármi, amit beviszek arra az elemre), de a kereséskor nem találja.
Itt a kód(try catch-ben van, de azt most nem keresem meg, hol a vége-eleje, de nincs azzal gond)
Így azt hiszem, egy az egyben be is másolhatváltozók megadásával) futtatható is//változók
int fomenu, kilepes=0;
int bevitel,torles,rendezes,szures,mentes,elvet,kilep;
int bevkeres,torkeres, szurkor,szurtt;
int mod;
//beolvasas
BufferedReader br=new BufferedReader(new FileReader("adatok.txt"));
String sor;
int n=500;
String [] nev =new String [n];
String [] gazdnev =new String [n];
String [] tomeg =new String [n];
String [] kor =new String [n];
int olvastomb=0;
while((sor=br.readLine())!=null){
nev[olvastomb]=(sor.substring(0, sor.indexOf(";")));
sor=sor.substring(sor.indexOf(";")+1);
gazdnev[olvastomb]=(sor.substring(0,sor.indexOf(";")));
sor=sor.substring(sor.indexOf(";")+1);
tomeg[olvastomb]=(sor.substring(0, sor.indexOf(";")));
sor=sor.substring(sor.indexOf(";")+1);
kor[olvastomb]=sor;
olvastomb++;
}
//problémás részlet
try{
int []modvalogatas=new int[n];
int db=-1;
int i=0;
do{
i=0;
System.out.println(BLUE+"MEGLÉVŐ ÁLLAT ADATAINAK MÓDOSÍTÁSA MENÜ"+RESET);
System.out.println("Mi alapján szeretnénk kiválasztani a módosítandó tulajdonságú állatot?");
System.out.println("1-Név alapján");
System.out.println("2-Gazdája neve alapján");
System.out.println("3-Kor alapján");
System.out.println("4-Testtömege alapján");
System.out.println("5-Mégsem");
System.out.println();
bevkeres=extra.Console.readInt("Melyik menüpontot választja? ");
switch(bevkeres){
case 1 : {
String kereses=extra.Console.readLine("Milyen nevet keressünk?");
db=0;
i=0;
while(nev[i++]!=null){
}
for (int g=0;g<i;g++){
if (kereses.equals(nev [g])){
modvalogatas[db]=g;
db++;
}
}
break;
}
case 2 : {//főmenü 1-es menüpont->2-es menüpont
String kereses=extra.Console.readLine("Mi a gazda neve?");
db=0;
i=0;
while(gazdnev[i++]!=null){
}
for (int g=0;g<i;g++){
if (kereses.equals(gazdnev[g])){
modvalogatas[db]=g;
db++;
}
}
break;
}
case 3 : { //főmenü 1-es menüpont->2-es menüpont
String kereses=extra.Console.readLine("Milyen korút keressünk?");
db=0;
i=0;
while(kor[i++]!=null){
}
for (int g=0;g<i;g++){
if (kereses.equals(kor [g])){
modvalogatas[db]=g;
db++;
}
}
break;
}
case 4 : {//főmenü 1-es menüpont->2-es menüpont
String kereses=extra.Console.readLine("Milyen tömegűt keressünk?");
db=0;
i=0;
while(tomeg[i++]!=null){
}
for (int g=0;g<i;g++){
if (kereses.equals(tomeg [g])){
modvalogatas[db]=g;
db++;
}
}
break;
}
case 5: { //főmenü 1-es menüpont->2-es menüpont
break;
}
default: { //főmenü 1-es menüpont->2-es menüpont
System.out.println(RED+"Hibás értéket adott meg."+RESET);
}
}
try{ //főmenü 1-es menüpont->2-es menüpont
if(db!=0){
System.out.println(nev[0]+gazdnev[0]+tomeg[0]+kor[0]);
System.out.println("Az alábbi találat(ok) keletkeztek. ");
for (int j=0;j<db;j++){
System.out.println((modvalogatas[j])+"-"+nev[modvalogatas[j]]+";"+gazdnev[modvalogatas[j]]+";"+kor[modvalogatas[j]]+"év;"+tomeg[modvalogatas[j]]);
}
int modos=extra.Console.readInt("Melyik állatot kívánja módosítani a fentiek közül?");
do{
System.out.println(BLUE+"ÁLLAT ADATÁNAK MÓDOSÍTÁSA MENÜ"+RESET);
System.out.println("1-Név módosítása");
System.out.println("2-Gazda nevének módosítása");
System.out.println("3-Testtömeg módosítása");
System.out.println("4-Kor módosítása");
System.out.println("5-Mégsem");
System.out.println();
mod=extra.Console.readInt("Melyik menüpontot választja?");
switch (mod){
case 1:{ //főmenü 1-es menüpont->2-es menüpont
nev[modos]=extra.Console.readLine("Mi az állat új neve?");
break;
}
case 2:{ //főmenü 1-es menüpont->2-es menüpont
gazdnev[modos]=extra.Console.readLine("Mi az új gazda neve?");
break;
}
case 3:{//főmenü 1-es menüpont->2-es menüpont
tomeg[modos]=String.valueOf(extra.Console.readInt("Mennyi az állat új tömege?"));
break;
}
case 4:{//főmenü 1-es menüpont->2-es menüpont
kor[modos]=String.valueOf(extra.Console.readInt("Mennyi idős az állat?"));
}
case 5:{//főmenü 1-es menüpont->2-es menüpont
break;
}
default: {//főmenü 1-es menüpont->2-es menüpont
System.out.println(RED+"Hibás értéket adott meg."+RESET);
}
}
} while(mod!=5);
}
else {
System.out.println("Nincs ilyen állat.");
}
System.out.println();
}catch(Exception e){
System.out.println(RED+"Hiba történt!: "+e.getMessage()+RESET);
}
}while(bevkeres!=5);
}catch(Exception e){
System.out.println(RED+"Hiba történt!: "+e.getMessage()+RESET);
}
break; -
norbert1998
nagyúr
"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?
-
norbert1998
nagyúr
Jobb gomb az Output ablakban, majd Clear, vagy nyomatsz egy Ctrl+L-t...
Olyanra gondoltam, amit a programkódba lehet írni, de akkor gondolom ilyen nincs. Mindegy, köszönöm
Olyan van esetleg, hogy amit oda kiír a NetBeans, azt vastgított vagy dőlt vagy valamilyen kiemelt betűvel tegye egy-egy sornál?
-
norbert1998
nagyúr
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.Bocsánat. NetBeans IDE
-
floatr
veterán
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.Sajnos láttam már miket műveltek a forrásban
Látszik hogy nagy code wariorok voltak a szerzők, de nem is a hosszútávú támogatás járt a fejükben, amikor megszülték a művüket. De ez elmondható elég sok frameworkről is. -
floatr
veterán
"É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. Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
-
norbert1998
nagyúr
Teljesen érthető for-ciklusnál, de én még mindig foreach-ről beszélek, gondolom majd azt is fogjátok tanulni.
-
estro
csendes tag
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.
Az SQL injection tudtam, hogy veszélyes az adatbázisomra, de még nem néztem utána mit lehet ellene tenni, de akkor most már tudom
. A SELECT * tényleg eléggé rontja a teljesítményt most, hogy belegondolok (főleg ha majd joint is használok), majd kijavítom azt is, mert már van vagy 5 mező mivel regisztrációt is csináltam hozzá. Köszi a tippeket! -
Ursache
senior tag
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.LOL! Most látom, hogy ezt a "másik" topikban is megkaptam, arra ott nem reagálnék, ha nem gond
-
Aethelstone
addikt
Így van.
De vágod, nem nekem kell magyarázni, pont emiatt szóltam a kollégának. Hogyne
-
Aethelstone
addikt
"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." -
Ursache
senior tag
"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." -
Ursache
senior tag
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. -
Aethelstone
addikt
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. -
cucka
addikt
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ű. -
WonderCSabo
félisten
"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.htmlEmlékeztem rá, csak lusta voltam kikeresni, köszi.
-
Devdi
aktív tag
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ó.Az enyém azért költséghatékonyabb... Míg a tiedhez 5 karaktert kell átírni addig az enyémnél csak 4
De amúgy igen elismerem, a tied szebb
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azóta nem is tudtam foglalkozni a kis projekttel... 
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- gban: Ingyen kellene, de tegnapra
- Marxistává válik az AI, ha elviselhetetlenné teszik a munkakörülményeit
- Nem kell még temetni: 2 éves órajelcsúcsot döntöttek meg Raptor Lake-kel
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Autós topik
- Mibe tegyem a megtakarításaimat?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Eredeti játékok OFF topik
- További aktív témák...
- X1 Yoga Gen8 2-in-1 14" FHD+ IPS érintő i7-1355U 16GB 512GB NVMe ujjlolv IR kam gar
- Raktáron, PlayStation 4 Slim 500GB, gyönyörű szép állapotban, 6 hó garanciával, üzletből!
- PlayStation 4 Pro 1TB 7216B, frissen pasztázva, 6 hó garanciával, Bp-i üzletből eladó!
- Nintendo Switch OLED 64GB+256GB MicroSD + okositott, Atmosphere 3 hó garanciával
- Akciós! Kishibás! Macbook Pro 13 M1 16GB 256GB Akku: 87% 1 év garancia
- ÚJ Lenovo LOQ Intel Core i5-13450HX, 32GB, 1TB, RTX 5060(8GB), FHD IPS 144Hz
- Frissen pasztázva! Playstation 4 Pro 1 TB + kontroller 6 hó garancia, számlával!
- BESZÁMÍTÁS! Asus X570 R7 5700 16GB DDR4 1TB SSD RTX 3060Ti 8GB be quiet! Pure Base 500 Chieftec 700W
- HP ProBook x360 435 G8 Ryzen 5 5600U - Utolsó darab - AKCIÓ! - Garancia
- EREDETI NINTENDO Pokemon Go Plus autocatcher dobozban eladó
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest