- Milyen billentyűzetet vegyek?
- Teljesen az AI-ra fókuszál az új AMD Instinct sorozat
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- OLED TV topic
- Ez már a középkategória: teszten a GeForce RTX 5070
- Milyen TV-t vegyek?
- Fujifilm X
- Azonnali VGA-s kérdések órája
Új hozzászólás Aktív témák
-
Szmeby
tag
válasz
btraven
#12173
üzenetére
A monad egy magányos lélek, ki csendben, magába fordulva, mindentől elzárkózva lebeg az éteri mezők felett. A monad nem foglalkozik a külvilággal. A monad csak befelé figyel. Ha a monad mondjuk egy gömbként éli életét, bár mélyen legbelül forrong is, ő továbbra is egy gömb formájában létezik. Akkor és csakis akkor mutat változást kifelé, amikor beteljesíti rendeltetését, eljő érte a terminal operator, megszűnik létezni, miközben hamvaiból egy kocka emelkedik fel. Az a kocka már nem feltétlenül egy monad. Általában nem az.
Amikor egy mondjuk stringre ráhívod a parseInt metódusát, ő voltaképpen egy lépésben válik egyikből a másikká. A változás kívül megy végbe, azonnal, szemmel jól láthatóan.
A stream egy monad, a legtöbb operátora a belső lelkivilágát alakítja, kívülről láthatatlan, ezért is tükrözik az elnevezések ugyanezt. A map nem a monad külsejét akarja megváltoztatni, hanem a belsejében található tartalmat alakítja, esetedben egy-egy stringet. A mapToInt úgyszintén. A max operátor ellenben terminálja a monadot és ebből a sejtelmes lényből csinál egy számot, ami már kívülről is láthatóvá válik, miközben a monad meghal.
A java nyelvben nem csak egyféle lény él. A különféle lények eltérően viselkednek és a viselkedésüket csak kontextusukban érdemes értelmezni.
-
-
Drizzt
nagyúr
válasz
btraven
#12008
üzenetére
Ha kifejezetten méretre lősz és nem muszáj JDK only megoldást adni, akkor lehet jobban jársz, ha valamilyen cél library-t használsz. Némi összehasonlítás: [link] Főleg a 3.4 performance az érdekes.
Btw: Nagyban függ attól, hogy mi egyéb van még az osztályokban, ha csak egész számok, akkor hány darab, etc. De ha nagyon optimalizálni akarsz méretre, akkor lehet nem is magát a classt kéne szerializálni, mert az nyilván hoz magával mindenféle metadatát, ami tuti sokat fogyaszt. -
válasz
btraven
#11987
üzenetére
Leírja, hogy olyan funkciót használsz ami a jövőben nem lesz táogatott. Ez miért gond?
Itt a deprecated jelentése: [link] . Használj gradle wrappert és akkor fixen használhatsz arhaikus verziót mindenféle hibaüzenet nélkül.
Az isten óvjon minket attól, hogy minden libet kézzel keljen újra behúzni.
-
Drizzt
nagyúr
válasz
btraven
#11879
üzenetére
[Például]
De egyébként A hello world egy unit tesztelhetőség szempontjából pont eléggé faramuci dolog, mert ott a függvényedet le kellene választani a környezetéről. Ha nem a környezetéről leválasztva tesztelsz valamit, akkor az az én szememben már inkább integration teszt.
Egy olyan függvényt, ami a standard outputra kiírja, hogy Hello world, nem lehet jól unit testelni, mert a standard outputot kell mockolni, ami meg csak ilyen nyakatekert módokon oldható meg.
Ha viszont olyan függvényed lenne, ami visszaadja, hogy: "Hello world" -> remekül unit tesztelhető. Olyan, ami kap egy outputstream-et input-ként és kiírja rá, hogy "Hello world" -> szintén remekül unit testelhető.
"Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek."
Ez utóbbi mindig nagyon gyanús. Én is mindig azt hiszem, ogy jó, triviális kódokat írok, aztán amikor elkezdem tesztelni, szinte mindig kijön valami turpisság. Nyilván a tesztelés mehet három módon: kézzel pöcögtetve: valószínűleg jó kódot eredményez, de ha legközelebb aki hozzányúl, nem olyan alapos, mint aki írta és kézzel tesztelte, akkor rögtön veszélyes lesz módosítani a kódot. 2.: vagy azonnal automata tesztet írni, vagy az előző pont kézi eseteit automatizálni. Ez elég jó általában. 3.: előre írni meg a tesztet és csak utána a kódot. Pont az a nagy előnye, ami miatt elsőre nagyon nehéz vele dolgozni: végig kell előre gondolni az elvárt viselkedést és a trükkös eseteket is. Erre gyakran használt kifogás, hogy sokat változik az elvárás, azért nem kezdenek vele. De nem teljesen korrekt érv, hiszen anélkül, hogy tudná mit akar csinálni az ember, el sem tud mit kezdeni programozni.
Én tényleg csak alkalomszerűen TDD-zek, de örülnék, ha valamikor elkezdenénk végignyomni vele teljes projekteket, mert minőségben ég és föld a különbség. Ha előre írsz tesztet, akkor sokkal jobban át tudod gondolni, hogy milyen osztályoknak, milyen interface-eken keresztül kell tudniuk egymással beszélni. Sokkal könnyebb elkerülni a spagetti kódokat. -
BE4GLE
aktív tag
válasz
btraven
#11879
üzenetére
Ha ez a kérdés fölmerült benned az számomra azt sugallja, hogy nagyon nem tudod mire való egy unit teszt. Vagy csak trollkodsz.
Az ilyen tesztekben az interface-eket mock-olod. A user interface-t is. Nem célja ezeknek a teszeknek ellenőrizni, hogy a layout-ot helyesen raktad e össze, és hogy a szöveged jól legyen tördelve. Viszont a Hello World-ig vezető utat le tudod tesztelni és a kimenetet is. -
BE4GLE
aktív tag
válasz
btraven
#11873
üzenetére
Nálunk se jutnál keresztül a felvételi folyamaton enélkül. És nem tudom miről beszélsz. Én sosem bántam meg. Az olyan kódokkal viszont nagyon nehéz dolgozni, amik teszt nélkül össze lettek gányolva. Már csak azért is, mert az ilyen kódok jellemzően később se teszteletőek. Egészen máshogy írsz meg valamit, ha a tesztelhetőség és karbantarthatóság is szempont, és nem csak az, hogy minél előbb legyen egy látszólag működő funkciód.
-
-
Drizzt
nagyúr
válasz
btraven
#11828
üzenetére
Valoszinuleg sosem fogd megerteni, hogy mit jelent egy feketenek a mester szo hallata. En sem fogom, bar szeretnem azt hinni, hogy igen. De nem vagyok naiv, sosem fogom valoban aterezni milyen rabszolgacsalad sarjanak lenni, barmekkora is az empatiam. Az ilyen szavak tudat alatt is hatalmas karokat tudnak okozni az erintetteknek. S az is persze igaz, hogy Magyarorszagon tok mas az elsodleges jelentese a leforditott szonak, emiatt megint mas elkepzelni a pszichologiai hatasat. Idehaza persze elsosorban a mindenhez erto ember jon elo a szo kapcsan, nem a korbacsos rabszolgatarto. Meg az is igaz, hogy biztosan korulvesz minket ezer olyan szo, ami mas emberekben szorongast valt ki. Es persze eszre se vesszuk. Azert amik eleg szeles korben okoznak problemat, az reszemrol nem baj, ha atnevezesre kerul. Meg fogom birni szokni, hogy 1 betuvel kevesebbet kell gepelni.
-
-
axioma
veterán
válasz
btraven
#11749
üzenetére
Hat ennyibol csak azt lehet megmondani, hogy vagy rossz az interface design-ja, ha igy kell hasznalni akkor irhatott volna melle kommentet hogy minek, vagy tenyleg hibas a sor duplazasa. Ezen felul vagy felesleges (abban az ertelemben hogy nem okoz semmi elterest), de akkor rossz az elnevezese a fuggvenynek [pl. ha set jellegu, egy par csak 1x lehet akkor ne nevezze add-nak], vagy kimondottan problemat okozhat (pl. memoria), ha egy "add" egy peldanyt fog letrehozni azaz szumma 2-t, de kesobb muvelet csak az egyikkel van (es megszuntetes is 1x).
Es szerintem me'g mindig nem fedtem le az osszes lehetseges kombinaciot... Nyilvan attol is fugg, hogy hol van ez a kodreszlet, ha egy standalone jatek (amire elsore asszocialni tudok), akkor kiszeded es kiprobalod, de prod kornyezetben ez nyilvan egy teljesen mas folyamat (es itt me'g csak nem is arra gondolok hogy forumrol vagy mashonnan szerzel hozza infot). -
Spidi77
csendes tag
válasz
btraven
#11741
üzenetére
Köszönöm mindenkinek a segítséget így valamennyire előrébb vagyok. Kezdem már érteni a setter feladatát. Megpróbálom átadni a beolvas metódus értékét közvetlen a setternek, akkor valószínűleg már el fogja fogadni a kiértékelő program.
A tesztelés csak a következő tananyagban lesz egyenlőre annyira nem akarok előre rohanni. -
Drizzt
nagyúr
válasz
btraven
#11666
üzenetére
Koszi a peldat!
Igy egyszerubb valaszolni a kerdesedre.
[Javadoc] : "Exceptions are thrown for problems with the OutputStream and for classes that should not be serialized. All exceptions are fatal to the OutputStream, which is left in an indeterminate state, and it is up to the caller to ignore or recover the stream state."
Szoval nincsen kulonosebben specifikalva, hogy mi fog tortenni Exception eseten. Elofordulhat, hogy kulonbozo JVM-eken es kulonbozo javaverziokon is kulonbozokeppen viselkedik, de a leirasaban benne van, hogy az esetleges szemetet a hivonak kell feltakaritani. Szamomra meglepo, hogy igy van. Szoval a catch agban zard a Streameket, majd torold a fajlt, ha van.
Ha atirod a peldadat "try with resources" alapon, akkor a close-et nem kell sehol meghivnod, mert a ket outputstream autoClosable. -
disy68
aktív tag
-
#11588
Aethelstone
addikt
btraven
#11585
Aethelstone
addikt
válasz
btraven
#11585
üzenetére
Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt.
Nah jah, de akkortájt még nem is kellett annyi minden És hidd el, hogy akkoriban vért kellett hugyozni annak a megírásával, amit most pár, jól irányzott annotációval százszázalékos biztonsággal meg tudsz oldani. Ilyen fejlesztői napidíjak mellett nem rentábilis egy problémát napokig reszelgetni, amikor triviális megoldás is van -
Drizzt
nagyúr
válasz
btraven
#11585
üzenetére
"Nem lett bonyolult a helyzet ezzel a lambda meg stream-ekkel?"
Nem, sokkal egyszerűbb lett. Egyébként lambdát nem kötelező használni, ahol tudok inkább method reference-et használok. A streamnek meg fontos képessége a lazy eval, meg a concurrency support. Bizonyos problémákat tök egyszerűen, szépen, elegánsan és hatékonyan meg lehet oldani funkcionális eszköztárral, amit amúgy bonyolultan/csúnyán lehet megoldani nélküle.
"Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt."
Ez ma is így van. Maximum 1-2 szinte már sosem használt nyelvi elem léte lenne megkérdőjelezhető, de azok meg maradnak némi backward compatibility miatt. Az meg ha esetleg azért kérded ezt, mert szerinted a Stream felesleges, akkor egyszerűen még nem éreztél rá. Nélküle nagyon szar lenne az élet, ezt pár évi gyakori Stream használóként mondom. Nézz végig valamilyen alap fukncionális progamozást traininget, után egyértelműnek kellene lennie miért ilyen fontos dolog.
"Most már nehéz a programozó élete. A sok nyílt forráskódú, ingyenes cuccban az egyik fele nincs dokumentálva a másik fele meg hibásan működik vagy éppen sehogy. Ugye azért nyílt, mert majd kijavítod magad ha nagyon kell. Csak nem képzeled hogy ingyen még hibátlan is legyen?"
Ez megint nincs így. A lefontosabb, legnépszerűbb framework/libek leggyakrabban használt funkciói eléggé stabilak, ritkán kell körbebástyázni őket. A probléma az esetek 95%-ban abból adódik, hogy valaki megspórolja az alapjaik megismerését és anélkül kezdi őket használni valami olyan célra, amire nem feltétlenül alkalmasak. Még ha elő is fordulnak bugok, sokkal előrébb jársz, ha valami libet használsz rájuk, mintha 0-ról kezdenéd megírni. Sokkal tovább tartana, s a minősége is szinte borítékolhatóan rosszabb lenne.
Az utóbbi évekből pár dolog, aminek én nem voltam elégedett a dokumentációjával: annotation processor, Spring boot property source használat belsőségei. De az is lehet csak nem a megfelelő dokumentációt olvastam. Ráadásul Java-ban az se megy ritkaságszámba, hogy korábbi open source lib a nyelv részévé válik, pl.: Joda-time. -
#11575
Aethelstone
addikt
btraven
#11572
Aethelstone
addikt
-
-
fatal`
titán
válasz
btraven
#11546
üzenetére
Ha még nem pusholtad be akkor lehet (utána is, csak force push kell és ha valakinél már lent van a commitod akkor össze-vissza fog mergelgetni). Ha a legutolsó commit, akkor változtatás nélkül az "üres" staget tudod amendelni és átírni a commit messaget. Ha régebbi commit akkor interactive rebase.
-
Drizzt
nagyúr
válasz
btraven
#11514
üzenetére
Ja igen. A helyzet az, hogy az a2 nem módosulhatott. Valami más miatt tűnik úgy, mintha ez történt volna. Hogy néz ki az A class? Nem véletlen valami static field-et állít át a konstruktora? Mi alapján gondolod, hogy a1, meg a2 is "hi"?
Itt egy példa, hogy ennek a fajta értékadásnak az a2(, a példában s2) által mutatott címet nem szabadna mósodítania.
@Test
void assignment() {
String s1 = new String("Hello");
String s2 = s1;
s1 = new String("hi");
System.out.println(s1);
System.out.println(s2);
System.out.println("s1 default hashcode: " + System.identityHashCode(s1));
System.out.println("s2 default hashcode: " + System.identityHashCode(s2));
}
Output:
hi
Hello
s1 default hashcode: 1366025231
s2 default hashcode: 1427889191 -
Drizzt
nagyúr
válasz
btraven
#11512
üzenetére
Nem poolozva vannak, hanem egyszeruen az osztaly/interface tipusu valtozok gyakorlatilag pointerek. Szoval ezekkel a sorokkal kb. az alabbit csinaltad:
A heapen letrehoztal egy A tipusu peldanyt. A kis a valtozot letrehoztad a stacken, ami az elobb letrhozott heapen levo peldany cimere mutat. Letrehoztad az a2 valtozot a stacken, ami ugyanarra a cimre mutat az ertekadas miatt, mint a.Emiatt van az is, hogy nyelvi alapelem lett az equals, hogy latvanyosan megkulonboztetheto legyen az ertek szerinti osszehasonlitas a cim szerintitol.
-
Szmeby
tag
válasz
btraven
#11495
üzenetére
Normális esetben kompatibilis. Ha valóban CME-t dob, akkor a jelek szerint az Army objektumaid nyilvántartják magukban, hogy a defenderArmies collection részei, és valamelyik remove (gondolom az utóbbi) el akarja távolítani saját magát a defenderArmies collection-ből is.
És ha ez a helyzet, míg az iteratoros példa CME nélkül lefut, akkor szerintem hibázik. Mivel az iterator saját állapotot tart fenn, hogy tájékozódjon a collectionben, őt különösebben nem zavarja, ha menet közben törölsz a listából, de ha ezt nem közlöd az iteratorral, akkor minimum hibás eredményt hoz, pl. nem töröl mindent, vagy nem azt törli, amit kellene, nem tudom.
Az iterator tényleg lefut, míg a foreach elszáll?A helyes iterator használat valahogy így nézne ki:
Iterator<Army> iter = defenderArmies.iterator();
while (iter.hasNext()) {
Army army = iter.next();
// do sth with army
iter.remove();
}
Az iter.remove() mondja meg az iteratornak, hogy itt törlés van, és vissza kell léptetnie a kurzorát. Enélkül, hát, csodálom, hogy nem dob hibát. -
sztanozs
veterán
válasz
btraven
#11500
üzenetére
Nem tudod megoldani, hogy egyezzen a típus?
Egyébként az IDE se mindentudó - a gond nálad ott van, hogy nem az iterált objektumból törlöd az army objektumot, hanem konkrétan magát az objektumot törlöd. Az IDE nem jött rá, hogy ezzel módosul maga az iterátor is. Amúgy ez szvsz inkább tervezési hiba lesz.
-
-
Szmeby
tag
válasz
btraven
#11473
üzenetére
En ugy gondolom, hogy jelentos merteku fejfajastol kimelned meg magad, ha elobb bekonfiguralnad az IDEt ugy, ahogy neked tetszik. Minden valamire valo IDE-ben be lehet allitani, hogy mit tekintsen hibanak es mit ne, hogyan formazzon es hogyan ne. Szerintem ez is kepes ra.
Persze ha csak ventillalni szeretnel, akkor targytalan, folytasd nyugodtan.
Megjegyzem, en szeretem a zarojelet az if-nel, mert igy egyseges, konnyen attekintheto.
-
Szmeby
tag
válasz
btraven
#11462
üzenetére
En amikor csak lehet, csak backendet keszitek javaban. A frontend meg szepen koltozzon at a bongeszobe (angular, react, vue, stb).
Ha tenyleg annyira pici a problema, hogy nem eri meg egy js frameworkkel loni ra, akkor desktopra inkabb raknek ossze egy python appot. Az is benacska, de legalabb gyorsan elkeszul. Azert python, mert szerintem sokkal konnyebb es mert mashoz nem ertek.
Ha meg nagyon ragaszkodnek valamiert a javahoz, akkor +1 a javafx-re. Az a legujabb desktop frontendje, de mar azt sem eroltetik a keszitok.
-
Drizzt
nagyúr
válasz
btraven
#11422
üzenetére
De, szabad hasznalni. Viszont ha nem valamilyen factory metodusban hasznalod, akkor gyanus, hogy lenne helyette szebb, biztonsagosabb, bovithetobb OOP megoldast talalni a problemara. Nyilvan nem mindig. Akkortol jon a gond, ha tobb metodusban ugyanazon ertekkeszlet alapjan kell kulonbozo dolgokat csinalni, mert konnyen el lehet cseszni, ha bovul az ertekkeszlet.
-
Gyuri16
senior tag
válasz
btraven
#11381
üzenetére
Itt csak a megnevezesekben van kis kavarodas. Es abban, hogy a mapper fuggvenynel a Function volt generikus, itt pedig a src es dest valtozok (tipikusan valamilyen Collection).
A valtozok felhasznalasat kell nezni. A src egy Collection, ebbol a copy fuggveny olvasni fog ("The src argument provides the data to be copied"). Tehat a src egy producer.
A dest valtozo az eredmeny, ebbe a fugveny irni fog, tehat consumer. "the dest argument accepts data" -
Gyuri16
senior tag
válasz
btraven
#11376
üzenetére
Ha nem akarsz rajta gondolkodni, akkor eleg megjegyezni hogy "Producer extends Consumer super" - PECS.
mapper fuggveny elso parametere a bemenet, ez consumer. A masodik az eredmeny ez a producer.
Ha erdekel bovebben, akkor lehet itt kezdeni: [link]
Igaz collectionokrol van szo, de a lenyeg ugyanaz.map fuggvenynel maradva, vegyunk egy konkret mapper implentaciot.
mapper fuggveny parametere egy valtozo. Azt akarod, hogy a valtozo el tudjon tarolni egy T tipusu objektumot. Milyen lehet a valtozo tipusa? Nyilvan lehet T. Lehet-e T-tol leszarmazott osztaly? Nem, mert akkor nem tudna egy T tipusu objektumot tarolni (pl. Integer valtozoba nem lehet Object-et tarolni). Lehet-e T elodje? Igen, altalanosabb tipusu valtozoba lehet leszarmazott osztalyt kuldeni. (ismet: Object-be lehet Integert). Ezert super.Nezzuk a mapper fuggveny eredmenyet. Itt azt szeretned, ha egy R tipusu valtozoba el lehetne menteni.
R eredmeny = mapper(bemenet);
Milyen osztalyokra igaz ez? R lehet. R elodje nem lehet (Integerbe Object-et). R-tol leszarmazott lehet. Ezert extends.Ha eloszor foglalkozol ezzel, kicsit zavaros lehet. Ajanlom, hogy probald ki egy egyszeru A->B->C hierarchian Collectionokkel (ami a linkben van).
mod: amig irtam, nyilvan megeloztek
most mar itthagyom, hatha segit a magyar verzio.
Honnan tudná, hogy hány ujjal gépelsz?
Az ilyen tesztekben az interface-eket mock-olod. A user interface-t is. Nem célja ezeknek a teszeknek ellenőrizni, hogy a layout-ot helyesen raktad e össze, és hogy a szöveged jól legyen tördelve. Viszont a Hello World-ig vezető utat le tudod tesztelni és a kimenetet is.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Milyen billentyűzetet vegyek?
- Teljesen az AI-ra fókuszál az új AMD Instinct sorozat
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Anglia - élmények, tapasztalatok
- Kerékpárosok, bringások ide!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Kazy Computers - Fehérvár - Megbízható?
- Milyen légkondit a lakásba?
- További aktív témák...
- Prémium PC házak akár 20-40% kedvezménnyel eladók garanciával, számlával!
- Így lesz a Logitech MX Keys magyar billentyűzetes
- BESZÁMÍTÁS! Gigabyte Z370M i5 9400F 16GB DDR4 512GB SSD RX 5700XT 8GB ZALMAN S2 TG Corsair S650W
- 122 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Lenovo ThinkCentre M910q Mini PC / i7 7gen/8GB RAM/240GB M2 SSD/12 hónap jótállással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest