feladó: kissildi129 .(Az email cím megtekintéséhez engedélyezni kell a JavaScriptet)
címzett: .(Az email cím megtekintéséhez engedélyezni kell a JavaScriptet)
dátum: 2012. május 1. 17:48
tárgy: Tudom, rég beszéltünk, de ez most nagyon fontos…
küldő: lajt.hu
Egy éve halt meg Laci az M1-esen, és tudom, hogy már nem hozhatom
vissza,de legalább másnak ne kelljen elveszítenie a párját elalvásos
autóbalesetben!
Amióta megvettem az elalvássokkolót, nagyobb biztonságban érzem
magam, bárcsak hamarabb rátaláltam volna!
A nevével ellentétben nem sokkol, viszont garantáltan ébren tart, hangjelzéssel figyelmeztet ha vezetés közben elaludnék.
Erre ne sajnáljátok a pénzt,a szeretteink élete megfizethetetlen!
Én innen rendeltem, mert itt most féláron adják:
Tudtok ajánlani wargamer számára érdekes látnivalókat Prágában? A hadtörténeti múzeumot találtam eddig csak, de szívesen megsasolnám, hogy milyen a helyi klub élet, a helyi boltok felhozatala. Köszi!
Simán: U Vejvodu U Medvidku
Ez utóbbinál javaslom a literes házi sör - csülök kombót, isteni. Wargamer számára is érdekes lehet…
Szerk.: ja és a lőportoronyban nagyon jó az ír kávé...
Tudtok ajánlani wargamer számára érdekes látnivalókat Prágában? A hadtörténeti múzeumot találtam eddig csak, de szívesen megsasolnám, hogy milyen a helyi klub élet, a helyi boltok felhozatala. Köszi!
De szép szakmai vita… Én a másik oldalon állok általában, BA/PM oldalon. Az ilyen ezt rakjuk bele, máshogy gondoltam típusú hibák két dolgot takarnak szerintem: Balfasz BA/PM vagy Töketlen BA/PM.
Óóó, dehogy, ott van még az “állami szervezet vagyunk, jött egy új osztályvezető, és neki más elképzelései vannak, ha nem rakjátok bele, akkor elhúzzuk majd a kifizetést pár évig” és a “tudjuk, hogy belőlünk éltek, ha nem rakjátok bele, akkor máshoz visszük a jövőben a zsíros melókat” tipusú változtatási kérelem is
De szép szakmai vita… Én a másik oldalon állok általában, BA/PM oldalon. Az ilyen ezt rakjuk bele, máshogy gondoltam típusú hibák két dolgot takarnak szerintem: Balfasz BA/PM vagy Töketlen BA/PM.
Óóó, dehogy, ott van még az “állami szervezet vagyunk, jött egy új osztályvezető, és neki más elképzelései vannak, ha nem rakjátok bele, akkor elhúzzuk majd a kifizetést pár évig” és a “tudjuk, hogy belőlünk éltek, ha nem rakjátok bele, akkor máshoz visszük a jövőben a zsíros melókat” tipusú változtatási kérelem is
en olyan helyen dolgozok, ahol nincs kulon tesztelo
azaz fejleszt majd tesztel=debug majd ujra fejleszt, stb.
nna ez gaz. Vagy kis ceg, vagy hibas ‘csapatosszeallitas’, de mindenkepp jo recept a biztos hibas kodra.
Aki fejleszt csak azokat a lepeseket fogja vegigtesztelni, ami szerinte jo, nem azokat, amik letrejonnek a felhasznalok vagy egyeb okok miatt.
Ugyanezert nem vallalom, hogy a teszteket is en irjam meg a sajat kodomhoz. Egyedul Unitteszt-et csinalok, de azt is igazabol a kodlefedettseg miatt, majd par tovabbival kiegeszitem a tesztelotol jovo infok alapjan (igazabol ez az igazi unitteszt resz, a tobbi csak parasztvakitas).
Mondjuk hivatalosan elobb kellene a tesztet megirni, majd utana a kodot hozza. Kulonben a kodban levo hibakhoz van illesztve maga a teszt, ami mindig gaz (es sajnos legnagyobb cegeknel is hibas sorrendben megy a dolog—> sok-sok bug a vege, foleg ostoba tervezesnel (fejlesztes alatti: ‘meg ezt rakjuk bele’, ‘mashogy gondoltam’, ‘ja megsem kell’)).
De szép szakmai vita… Én a másik oldalon állok általában, BA/PM oldalon. Az ilyen ezt rakjuk bele, máshogy gondoltam típusú hibák két dolgot takarnak szerintem: Balfasz BA/PM vagy Töketlen BA/PM.
de en azt hiszem visszavonulot fujtam, elismerem az igazatok reszben, de kerlek ertsetek meg, hogy nem csak a ti elethelyzetetek van amikor a fejleszto egyenlo a tesztelovel, akkor a teszteles es debug hatarai elmosodnak
Attól még hogy raksz cukrot a kávéba, még nem lesz a cukor is kávé és a kávé se cukor. Hanem egy kávé x cukorral. Amit én mondtam, az nem élethelyzeti kérdés, hanem alapfogalmak. Hozzátenném, hogy alapesetben én is úgy dolgozom, ahogy te, másképp nem is lehet.
en olyan helyen dolgozok, ahol nincs kulon tesztelo
azaz fejleszt majd tesztel=debug majd ujra fejleszt, stb.
nna ez gaz. Vagy kis ceg, vagy hibas ‘csapatosszeallitas’, de mindenkepp jo recept a biztos hibas kodra.
Aki fejleszt csak azokat a lepeseket fogja vegigtesztelni, ami szerinte jo, nem azokat, amik letrejonnek a felhasznalok vagy egyeb okok miatt.
Ugyanezert nem vallalom, hogy a teszteket is en irjam meg a sajat kodomhoz. Egyedul Unitteszt-et csinalok, de azt is igazabol a kodlefedettseg miatt, majd par tovabbival kiegeszitem a tesztelotol jovo infok alapjan (igazabol ez az igazi unitteszt resz, a tobbi csak parasztvakitas).
Mondjuk hivatalosan elobb kellene a tesztet megirni, majd utana a kodot hozza. Kulonben a kodban levo hibakhoz van illesztve maga a teszt, ami mindig gaz (es sajnos legnagyobb cegeknel is hibas sorrendben megy a dolog—> sok-sok bug a vege, foleg ostoba tervezesnel (fejlesztes alatti: ‘meg ezt rakjuk bele’, ‘mashogy gondoltam’, ‘ja megsem kell’)).
en olyan helyen dolgozok, ahol nincs kulon tesztelo
azaz fejleszt majd tesztel=debug majd ujra fejleszt, stb.
kozben jonnek uj fiiicsorok, azaz ujra fejleszt majd tesztel=debug
aztan jon rifaktor, tesztel=debug, stb.
aztan partner megkapja, vegig bogarassza, es jonnek keresek, ekkor fejleszt…
de en azt hiszem visszavonulot fujtam, elismerem az igazatok reszben, de kerlek ertsetek meg, hogy nem csak a ti elethelyzetetek van amikor a fejleszto egyenlo a tesztelovel, akkor a teszteles es debug hatarai elmosodnak
remelem majd eloben is megismerhetlek titeket nehany folyekony kenyer mellett
Ah, bagatell Ugyis a cikkek a lenyegesek, amiket belinkeltem.
Egy példa, ami pl tegnap jött elő:
Adott egy egység sugarú lúzer, akarom mondani user. Leültetik, és megmondják neki, hogy ha beadja az A adatot, majd megnyomja a gombot, akkor B eredmény jön. Erre neki kijön a C, ami miatt sikít, mint a veszedelem… Hát, ez szerintem messze nem debugging, inkább hallás károsítás.
