Regisztráció Blogot indítok
Adatok
fqqdk

0 bejegyzést írt és 27 hozzászólása volt az általa látogatott blogokban.

2009.05.30. óta tag.
Admin Szerkesztő Tag Vendég
Kilépés a komfortzónából Élmények 2014.03.11 22:53:40
Össze- vissza szégyellem magam, amiért így elmaradtam, de a múlt hét előtti hét nem volt annyira fergeteges, hogy megérte volna a beszámolót. Hétvégén ellátogattunk Sussex megyébe, Anglia délkeleti csücskébe. Hát gyerekek, az maga a paradicsom :) Szép körút volt. Először is…..
fqqdk 2014.03.21 11:55:29
Kilépés a komfortzónából Lépések 2013.12.05 12:01:57
Na, akkor most van vége a nyekergésnek. :) Kirobbantottam magam a rosszból és visszajöttem. Köszönöm Csilla! <3 Különben is Advent van, az a várakozás időszaka. Még kollégista voltam Kőszegen, amikor az adventi időszakban minden hétfőn összegyűlt az egész koli. Verset…..
fqqdk 2013.12.05 12:46:14
Kilépés a komfortzónából Mióta készülök, hogy elmondjam neked... 2013.11.08 14:57:53
Álmodtam. Ebben semmi különleges nincsen, de ezt az álmot már sokszor álmodtam. A helyszín, a szituáció, az idő, mind-mind változó tényező, csak a szereplők ugyanazok. Talán annak tudom be, hogy van egy lezáratlan story az életemben (na jó, több is, de ez bír a legnagyobb…..
fqqdk 2013.11.08 15:22:50
Csak a tesztemen keresztül! Automatizált tesztelés és üzleti tesztelés 2011.02.01 08:45:00
Sokáig azt hittem, hogy az a termék, amit előállítottunk egy teszt automatizálási eszköz. Mert persze az is, hiszen a tesztek automatizáltan futnak le, de ma már a tesztek legtöbbje automatizált. Persze nem mindegyik, mert van amit nem lehet (értsd: érdemes) automatizálni.Azután rá…..
fqqdk 2011.03.05 13:42:35
Ellenőrző Tévhitek az oktatásról 2010.03.30 08:00:00
Egy tanár kollégánk reagál a blogon eddig megjelent posztokban felmerült "vádakra". Véleménye szerint hamis képet fest a tanárokról a posztok nagy része, akaratgyenge, dilletáns, máshová nem való embereknek állítja be a tanárokat.Kedves Ellenőrző!A blogot olvasva az…..
fqqdk 2010.03.30 09:09:26
fqqdk 2010.03.30 09:11:25
Ellenőrző Kell-e vallástörténetet tanulnia egy tanárnak? 2010.03.25 08:00:00
Rabyn egy új témát boncolgat levelében, ez pedig a vallás, ami ma Magyarországon valamiért tabunak számít. Szerinte nem ártana róla beszélgetni, akkor talán elkerülhető lenne rengeteg félreértés.Üdv!A napokban járt nálam egy hittérítő néni, aki itt hagyott pár…..
fqqdk 2010.03.26 13:52:46
Ellenőrző Mi a magyar oktatás baja? 2010.03.12 08:00:00
Levélírónk a magyar oktatás problémáját veszi górcső alá, végignézve a családi hátteret, a modern média hatását és az iskolai tartalomszolgáltatást. Egy diák szemszögéből nézve az általunk már annyiszor megvizsgált problémák új aspektusait ismerhetjük meg. Kedves…..
fqqdk 2010.03.12 17:44:49
[sarcasm]
Ha az iskolának nem feladata felvenni a versenyt az új médiával, és nem feladata megújulni, rugalmasabbá, neadjisten játékosabbá válni, mert ... olvasni kell a munkahelyeken, és nem csinál senki videót masszív doksikról? mert határidők, szigor, és stresszes körülmények vannak? ... akkor hogy lehet az, hogy pont a leggyorsabban fejlődő iparágban, az IT-ban egyre elterjedtebbek az agilis módszerek, és Alistair Cockburn például leírhatja, hogy egy szoftverprojekt az egy kooperatív játék, stb? Mi lenne, ha az oktatással nem az lenne a célunk, hogy a jelen olyan körülményeire készítsük fel a fiatalokat és nem olyan munkamódszerekre kondícionáljuk őket, amik potenciálisan elavultak lesznek, mire szegény párák a munkaerőpiacra kerülnek? Vagy ha annyira biztos, hogy ezek a dolgok ilyenek maradnak (ami elég röhejes feltételezés, ahogy így végignézek a közelmúlton Dr. Antall József halálától kezdve a "Hülye Facebook add vissza a régi júzer interfészt" csoport megalakulásáig) akkor miért ragaszkodunk "XVIZQ Ramszesz rendelkezéseinek" bemagoltatásához, ha ennek az egész folyamatnak a célja nem az, hogy megjegyezze "XVIZQ Ramszesz rendelkezéseit", hanem az, hogy határidők betartását, meg egyéb "életszagúbb" dolgokat tanítsunk meg általa? Rakjuk akkor a gyerekeket szoftverprojektekre, írjanak EUs pályázatokat, akár versenyeztetve is, és akkor ami tudás mindezen dolgokhoz szükséges, menetközben beszivárogtatható, meg lehet tanítani, hogy hogy wikizzék/guglizzák ki.
[/sarcasm]
Csak a tesztemen keresztül! Újra fizetni kell 2010.02.16 11:29:00
Az utv.hu-n olvasomÚjra fizetni kell utv uv2010-02-15 20:51:00 Tegnap reggeltől ismét ellenőrzi a parkolást a Budapesti Önkormányzati Parkolási Kft. (BÖP), a IX., XIII. kerületek teljes területén...És nem értem. Tényleg azt gondoljuk, hogy…..
fqqdk 2010.02.16 17:01:13
Kultúra. Ez jó szó a jelenség kapcsán.
A tesztelés egyik legfontosabb feladata megismételhető teszteseteket alkotni, amelyek a program (remélhetőleg helyes) működéséről vallott feltételezéseinket igazolja. Ez nagyon hasonít a tudományos kísérletekhez. Azokat is meg kell tervezni, biztosítani a megismételhetőségüket, stb... A tesztelés kultúráját szerintem erősítené a tudományos gondolkodásmód terjesztése. Persze programozó szakokon csak a két véglet van: színtiszta matematika, amit szerintem sok végzett programozó baromságnak és feleslegesnek tart, ilyen középiskolás lázadó jelleggel, illetve a gyakorlati tárgyak, amik az én tapasztalataim szerint nem fókuszálnak eléggé a szoftvertechnológiára, pláne nem a minőségellenőrzésre. Utóbbin mindenképpen kellene változtatni, és lehet, hogy egy-két kísérleti tudományokkal kapcsolatos kurzus is jót tenne a végzett programozóknak.
Aztán persze ki tudja, mikor fog az oktatás felzárkózni az iparhoz. Itt egy jó kis Stroustrup interjú: cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext
Ez még egy érdekes adalék a témában: misko.hevery.com/2009/07/11/computer-engineer-vs-computer-scientist/
Beautiful English Apple of one's eye 2010.02.11 10:51:00
Mai kifejezésünk azapple of one's eye [æpl əv wʌnz aɪ](főnév)valakinek a szeme fénye, szeretetteljes ragaszkodásának tárgyaPéldamondat: Mary's children are the apples of her eye.Görög mitológiai gyökerei vannak a kifejezésnek, az Erisz által elgurított aranyalmára vágyott…..
fqqdk 2010.02.13 12:34:26
fqqdk 2010.02.13 12:35:03
Ellenőrző Okoz-e maradandó károsodást az iskola? 2010.01.25 14:12:00
A félévi bizonyítvány/értékelés sok családban vezetett konfliktushoz, levélírónk is egy ilyen problémát oszt meg velünk. Esetében a tanító néni negatívan értékelte a lánya öltözetét és frizuráját, ami a kislányt és a szülőket is megviseli.Kedves Ellenőrző!Egy…..
fqqdk 2010.01.25 16:45:41
Csak a tesztemen keresztül! Unit tesztelés EasyMock-kal 2010.01.04 10:00:00
Ez most egy kicsit erősebben szakmai bejegyzés. Kell-e unit teszt? (naná) Korábban már volt szó unit tesztelésről, és felvetettem azt a kérdést is, hogy a unit teszteket vajon a program kód megírása előtt, vagy utána kell elkészíteni. (És kell-e egyáltalán?) Hogy…..
fqqdk 2010.01.15 13:57:58
fqqdk 2010.01.15 14:01:58
fqqdk 2010.01.18 21:10:36
1. Én aztán nem mondtam, hogy soha :) Én azt mondtam, hogy "ökölszabály", amit az angolszász "rule of thumb" helyett használtam, és azt értettem alatta, hogy "általában" (lehet, hogy helytelenül). Eszem ágában sincs kategorikusan kijelenteni, hogy mi jó, meg mi rossz. Pláne mivel egy-két linken kívül nincs más a tarsolyomban. Ez alatt azt értem, hogy nincs konkrét anekdotám, amiben migrénes fejfájást, és egészéjszakás debug szessönt okozott volna egy mockolt HttpServletRequest. De azt nyugodtam mondhatom, hogy eddig csak hasznát láttam a fenti elvnek.
2. A servlet api pont az, amivel kapcsolatban nagyon jól lehet példálózni a vita (mit és mit ne mockoljunk) mindkét felén, mert nyilvánvalóan életszagúbb, mint a Foo meg a Bar, és nagyon sok projektnél jelentkezik dependenciaként :D Azt viszont tudni kell, hogy némely hardcore TDD arcok szerint, mint Miško, borzalmasan rossz API (misko.hevery.com/2009/04/08/how-to-do-everything-wrong-with-servlets/ és itt most nem hiszem, hogy téma szempontjából nagy probléma lenne, hogy ez már nem a Requestről szól).
Csak a tesztemen keresztül! Elvárt és nyújtott minőség 2009.12.02 09:22:00
Öregszem. Már nincsen mindenkiről és mindenről olyan hamar kiforrott véleményem, mint régen. És megbocsátóbb is vagyok. Ha valaki bevág elém autóval, veszélyeztetve az épségemet, nem felkoncolnám először, hanem az jut eszembe: biztos jó oka van sietni. Pedig valószínűleg…..
fqqdk 2009.12.10 17:43:21
Csak a tesztemen keresztül! Pegamento demo 2009.10.05 10:14:00
Pegamento az a módszertan és kötő szoftver ami lehetővé teszi, hogy a tesztelés teljesen automatizált legyen. Ez a rendszer a GreenPepper, SOAPui és a jövőben reményeink szerint más szoftvereket is összeköt, így a Confluence web oldalról lehet elindítani további programozás…..
fqqdk 2009.10.05 15:40:34
fqqdk 2009.10.06 10:10:18
Csak a tesztemen keresztül! Jól beégünk 2009.07.15 16:11:00
Nyár van, és nemsokára elmegyek szabadságra, ezért nem adom fel a kérdést, hogy magyarázzátok meg ...Szóval volt egy szoftver, ami a weben keresztül szolgált ki kéréseket. A válasz összeállítása X darab adatbázis kérés után alakult ki, de mindenképpen 2mp-en belül kellett…..
fqqdk 2009.07.20 13:29:07
Ez a beégetéses teszt dolog úgy tűnik tényleg rendkívül költséges. Ahhoz, hogy egyáltalán azt tesztelje, amit akarsz (mármint hogy reteksok használat után valami hibás erőforrásmenedzsment jellegű dolog miatt szétrohad-e a rendszer), csinálnod kell "piszkos" környezetet, ami nem hinném, hogy triviális probléma. És ezek után rettenetsokáig pörgetned kell, miközben nyilván nem csak ülsz és malmozol, de akkoris.
A TDD-s csókáknak teljesen igazuk van, amikor azt sulykolják, hogy RAPID FEEDBACK. Minél gyorsabb a visszacsatolás, annál hamarabb látod, hogyha elcsesztél valamit, és minél hamarabb látod, hogy elcsesztél valamit, annál valószínűbb, hogy még elég olcsó lesz javítani.
Úgyhogy továbbra is úgy gondolom, hogy a legfontosabb tesztek a fejlesztői tesztek, azok közül is azok, amik 2 ms alatt lefutnak. :)
Persze továbbra sem próbálom azt állítani, hogy más teszt nem is kell.
A fejlesztőnek tesztelnie kell, és ahhoz hogy a teszteknek, amiket ír, értelme legyen, ahhoz el kell sajátítania a tesztelés kultúráját. Mert a tesztelés valójában kultúra, legalább annyira, mint az, hogy visszahajtod-e a vécédeszkát (hogy a lehúzásról ne is beszéljünk...)
És ennek a kultúrának nagyon fontos eleme, hogy a fejlesztő tisztában legyen a jó objektumorientált fejlesztés alapjaival, a tervezési mintákkal, a kódszagokkal, refaktorálással, miegyébbel. Még ma is baromi sok fejlesztő van, aki számára a tesztelés valami olyan dolog, amit majd megcsinál valaki más, és így aztán nagyon könnyű eljutni oda, hogy van valami olyan végterméke amire hónapokon belül mindenki, aki csak látja, azt sikítja, hogy egyszerűbb lenne újraírni nulláról.
Csak a tesztemen keresztül! Jónak tűnik, vagy jó? 2009.06.22 07:48:00
Nem mindegy. Mármint az, hogy a címben feltett kérdésre mi a válasz. Mert lehet valami jó, ha annak tűnik, de nem biztos, hogy az. Ahogyan ha valami rossznak tűnik, attól még... Szóval ami rossznak tűnik, az rossz is. És ezek miatt nem az a kihívás a tesztelésben, hogy megtaláljuk a…..
fqqdk 2009.06.24 17:44:31
Csak a tesztemen keresztül! Janó bá 2009.06.15 10:00:00
Így nyaranta, langyos estéken előfordul, hogy leülünk barátokkal beszélgetni az élet dolgairól, és két pohár száraz vörös bor után néha elfog a kétség, hogy valóban jól csináljuk-e az életben a dolgainkat. Jól nevelem-e a gyerekeimet, jól szeretem-e a feleségemet, tisztelem…..
fqqdk 2009.06.19 17:31:55
Csak a tesztemen keresztül! Pali és a kamatok 2009.06.01 10:00:00
Először két idézet a kommentlőktől a korábbi bejegyzésekre: fqqdk 2009.05.30. 15:45:22 "Ami azt illeti, az egységteszteket a programozónak kell írnia" brslc 2009.05.11. 10:54:00"legjobban a program írója tudja tesztelni a programját, mégpedig úgy hogy a csak…..
fqqdk 2009.06.01 12:55:29
Kezdjük a gonoszabb részével a dolgoknak, méghozzá azzal, hogy a fenti rendszer tervezőjének bár volt annyi esze, hogy ne "double forintÖsszeg" jellegű felületet írjon, hanem alkalmazta a csodálatos Money tervezési mintát, ami ugye azért kell, hogy a átváltogatásokat, meg a tzedeseket meg hasonlókat kezelő logika egy helyen legyen (pl most a ForintÖsszeg osztályban), de fel nem merült benne, hogy ugyanezt érdemelnék a dátum intervallumok is. Pedig ez a hiba jó eséllyel elő nem fordulhatott volna, ha a fenti metódus mondjuk úgy néz ki, hogy
ForintÖsszeg kamatSzámítóMetódus(DátumIntervallum intervallum, ForintÖsszeg forintÖsszeg).
Mondjuk nehéz is elhinni, hogy egy ilyen rendszerben a kamatszámító metódus az egyetlen, ahol két dátum mint egy intervallum fordul elő. És akkor már el is lehet mondani azt, hogy a TDD-nek lett volna esélye megakadályozni a fenti problémát: például azzal, hogy a refaktorálás szakasznál rájön szépen Pali, hogy már harmadszor írja le ugyanazt, azaz hogy Dátum intervallumKezdete, Dátum intervallumVége, és következetesen végrehajtja az "eliminite duplication" nevű igen hasznos lépést.

Aztán persze az is igaz, hogy némileg félreértjük egymást, azzal kapcsolatban, hogy mit nevezünk egységtesztnek, ami nem meglepő, mert ez egy globális jelenség, a szakma angol anyanyelvű része is ezen izgulászik:
http://www.infoq.com/news/2008/06/hill-microtesting
Amikor én egységteszteket mondok, akkor ezekre a mikrotesztekre gondolok, amik nem piszkálnak adatbázist, fájlrendszert, más relatíve lassú erőforrást, és az egységeket önmagukban tesztelik, nem pedig a kollaborátoraikkal. Ezeket a fejlesztőnek kell megírnia, hisz arról szól a dolog, hogy ezeket minden egyes kódváltoztatásnál le kell futtatni. Ezek nélkül nem lehetséges megbízhatóan refaktorálni, tehát a kód belső minőségét állandóan, és megbízhatóan javítani.
A mikrotesztek rendszerint nem tesztelik az egyes egységek együttműködését, tehát szigorú értelemben véve esélyük nincs elkapni a fenti hibát.

Az egyes modulok együttműködését az integrációs teszteknek kell vizsgálnia, azaz a fenti esetben pl egy olyan, szintén junit tesztesetként megfogalmazható tesztnek, ami a kliens kódot és a kamatszámító kódot egyszerre teszteli. Ha a két fél nem ugyanúgy gondolkozik a paraméterek sorrendjéről, az Pali kommitja után mondjuk egy órával kiderül, amikorra a kontinyusz integrésön szerver lefuttatta az összes integrációs tesztet. Meg acceptance tesztet. Vagy ha nem kommit után rögtön, akkor mondjuk éjszaka. Vagy minden kedden meg csütörtökön.
De az, hogy az egységteszt utáni következő minőségellenőrzési réteg az ÁTADÁS UTÁNI, felhasználó általi tesztelés, az szégyen, és nem annyira Palira nézve.
fqqdk 2009.06.01 14:21:03
fqqdk 2009.06.02 08:17:05
Csak a tesztemen keresztül! Hogyan érjük el, hogy teszteljünk? 2009.05.18 15:50:00
Szoftverfejlesztés közben tesztelünk, mert jó. Számomra sok esetben a kódolás során az okoz örömet (flow) amikor elindul a program, elkezd működni, azt csinálja amit én akarok. Olyankor én vagyok az Isten. (Tudom, cseppnyi az én világom, de mégiscsak én teremtettem. Rajzolj nekem…..
fqqdk 2009.05.30 15:34:43
fqqdk 2009.05.30 15:45:22
Ami azt illeti, az egységteszteket a programozónak kell írnia, és a programozónak kell futtatnia is, még mielőtt kommitolna a verziókezelőbe. Sőt, lehetőleg minden egyes ctrl+s után. Sőt, lehetőleg úgy, hogy ezt az IDE megcsinálja neki, szép grafikusan. Mindenki mindig a szoftver külső minőségével van elfoglalva (nem ír ki hülye hibaüzenetet, nem törik szét a dizájn), holott az iszonyatos pénzek meg idők arra csesződnek el, hogy förtelmes belső minőségű kódok tonnáiban turkálgatunk, csigalassúsággal. Merugye elmondják ám az iskolában, hogy programozzunk modulárisan, meg olvashatóan, de nem igazán mutatnak rá masszív, prodáksön kódot, ami olyan is lenne.
A Test Driven Developmentnek az az egyik legfontosabb előnye, hogy amikor előbb írod meg a tesztet, garantálod, hogy a kód utána tesztelhető lesz. A tesztelhetőségnek meg eléggé komolyan feltétele az, hogy a kódod _tényleg_ moduláris legyen.
felhasználási feltételek adatvédelmi tájékoztató segítség jogi problémák dsa impresszum médiaajánlat süti beállítások módosítása