A gazdasági vállság első hullámai hozzánk is eljutottak mostanra, a munkahelyem is nekilátott a leépítéseknek (ami a szokásos közismert multinacionális médiacég). Ez tök unalmas és agyontárgyalt dolog, csak egy megfigyelésemet szeretném megosztani, ami legalábbis engem meglepett:
Az elbocsájtott dolgozók között körülbelül saccra ugyanannyi a lusta és a szorgalmas, ugyanannyi a balfék mint a született tehetség, sőt a managerek és beosztottak aránya is passzol. Nem az a szempont, hogy a jól dolgozó embereket megtartsák, hanem egyszerűen akinek megszünik a projectje azt kirúgják.
Ettől kezd izgalmas lenni a játék.
2009. január 30., péntek
2009. január 25., vasárnap
System.currentTimeMillis() tréfa
Na most kicsit sok idő kimaradt, az utóbbi időben jól el voltam látva munkával. Az XML-es ámokfutásomat is csak most tudom majd újrakezdeni. Bocsi mindenkitől, aki másnapra várta.
Megint kis bullshitelés következik.
Mese... A régi cache-interszatyorhoz írtam egy unit tesztet, ami párhuzamosan futó szálak lockolási megoldását teszteli. Azt a tulajdonságát akartam unit teszt karókkal megtámogatni néhány oldalról, hogy ha egyszerre egy cachelt szolgáltatást ezren meghívnak egyszerre, ne történjen meg minden hívás, hanem csak egy, a többi pedig kapja ugyanazt - ez egy fontos opció a cuccban, könnyen agyoncsaphatjuk valamelyik backendünket. Ezt kétféleképpen is verifikálom: minden szál lefutás után a ugyanazt étréket kell visszaadja a cache-ből, valamint mivel a cache-vel körbevett metódus maga úgy lett leheggesztve, hogy 1000 ms-ig tartson, azt is ellenőrzöm hogy 1000 ms-nél több időbe telljen a hívás, és persze az érintett cache-vel körbefalazott metódus csak egyszer hívódjon meg ténylegesen.
És ment is elsőre mint a karikacsapás, boldogság zöld csíkja. Egészen addig, amig be nem dobtam az SVN-be a cuccot és a nyilván linuxon futó build agenteink fel nem kapták hogy ők is kipróbálják tényleg megy-e. És nem ment :-) Nagyon gyanúsan 1000 ms köré eső értékek jöttek, de hát alatta voltak kicsivel.
A probléma az volt, hogy a System.currentTimeMillis() nem egészen pontosan adja vissza minden operációs rendszeren a jelenlegi értéket, hanem egy kicsit szemcsésen. Csak 64 bites linuxon sikerült ezt elérni amúgy. Ez így emlékeztetőnek kiválló volt, hogy ilyeneket ne írjak unit tesztekbe :)
Egyébkén köszi a szavazatokat, 4.5 fölött van idáig az átlagom, legutóbb általános iskolában volt így talán.
Megint kis bullshitelés következik.
Mese... A régi cache-interszatyorhoz írtam egy unit tesztet, ami párhuzamosan futó szálak lockolási megoldását teszteli. Azt a tulajdonságát akartam unit teszt karókkal megtámogatni néhány oldalról, hogy ha egyszerre egy cachelt szolgáltatást ezren meghívnak egyszerre, ne történjen meg minden hívás, hanem csak egy, a többi pedig kapja ugyanazt - ez egy fontos opció a cuccban, könnyen agyoncsaphatjuk valamelyik backendünket. Ezt kétféleképpen is verifikálom: minden szál lefutás után a ugyanazt étréket kell visszaadja a cache-ből, valamint mivel a cache-vel körbevett metódus maga úgy lett leheggesztve, hogy 1000 ms-ig tartson, azt is ellenőrzöm hogy 1000 ms-nél több időbe telljen a hívás, és persze az érintett cache-vel körbefalazott metódus csak egyszer hívódjon meg ténylegesen.
És ment is elsőre mint a karikacsapás, boldogság zöld csíkja. Egészen addig, amig be nem dobtam az SVN-be a cuccot és a nyilván linuxon futó build agenteink fel nem kapták hogy ők is kipróbálják tényleg megy-e. És nem ment :-) Nagyon gyanúsan 1000 ms köré eső értékek jöttek, de hát alatta voltak kicsivel.
A probléma az volt, hogy a System.currentTimeMillis() nem egészen pontosan adja vissza minden operációs rendszeren a jelenlegi értéket, hanem egy kicsit szemcsésen. Csak 64 bites linuxon sikerült ezt elérni amúgy. Ez így emlékeztetőnek kiválló volt, hogy ilyeneket ne írjak unit tesztekbe :)
Egyébkén köszi a szavazatokat, 4.5 fölött van idáig az átlagom, legutóbb általános iskolában volt így talán.
Feliratkozás:
Bejegyzések (Atom)