Google jobs

Az elmúlt időben a felröppent pletykák miatt figyelemmel kísértem a Gugli aktivitását kishazánk környékén. Az első blogbejegyzéseket 2006 májusából találom a témában.

Az Utazás kiállításon volt egy Google egyetem, ahol láthatóan nagyon a reklámozásra gyúrtak. Peresztegi Zoltán beszélt arról, hogy mit akar a Google Magyarországon. Egyelőre nem sok válasz volt a kérdésre. Volt Interjú Dennis Woodside-dal a Google kelet-európai piacokért felelős igazgatójával. Mégegy, ami elég béna és mégegy, részletekbe menő. A magyar emberek még: Hegyi Péter (Dublin), Stekkelpak Zoltán, Baloghy Réka, Bódis Attila, aki az Official Google Blog-ba ír. dLux pedig Zürichben nyomja (lásd később).

2007 májusában volt Londonban Google fejlesztői napok: Beszámoló róla.

Aztán úgy folytatódott, hogy írták a zindexen és az sg.hu -n, amikor nálunk járt Vint Cerf, hogy a Google próbafelvételiket tartott egyetemisták körében. Olyasmi lehetett, mint a Morgan Stanley-s téma, hogy logikai feladatokkal traktálták a delikvenseket, plusz "mitírki" feladatokat kellett megoldani. Állítólag előny volt, ha valaki több programozási nyelvben is otthon volt. Ez a Felkeltette az érdeklődésemet, bár lemaradtam az előadásról.

Gondoltam, mindenesetre érdemes lesz nézegetni néha a google.jobs -ot, ahol Magyarországot illetően már volt néhány állásajánlat, de még egyik sem fejlesztői. Konkrétan ezek:
• Account Manager - Budapest
• Account Strategist - Budapest
• Associate Product Marketing Manager - Budapest
• Country Business Manager - Hungary
• Emerging Markets Strategy Associate - Europe
• Global Deployments Project Manager - Budapest
• Product Marketing Manager - Budapest

Láthatóan Lengyelországban jobban nyomultak, vagy legalábbis előbbre tartottak ebben az időben. Fejleszőket kerestek és tanulóknak is voltak lehetőségeik. Romániában semmi, Szloviban country consultant-ot kerestek, a cseheknél valamivel mögöttünk voltak. Októberre eltűnt a szlovák country consultant ajánlat.

A fenti állásajánlatok közül július közepére kettő ki lett lőve. (Associate Product Marketing Manager és Product Marketing Manager.) Viszont Dublinba kerestek magyarul beszélő Editor-t és Online Sales and Operations coordinator-t. Emellett sokféle nyelven beszélő embereket. Az SG-n ismét volt egy cikk, hogy ez a Google egy milyen marhajó hely, de voltak olyanok is, akik némileg objektívebben összehasonlítottak több mammutcéges munkahelyet is (MS, Yahoo, G).

Augusztus elejére Dublinban elkeltek az állások és az Emerging Markets Strategy Associate is eltűnt, tehát ezek maradtak:
• Account Manager - Budapest
• Account Strategist - Budapest
• Country Business Manager - Hungary
• Global Deployments Project Manager - Budapest

Augusztus közepére a Country Business Manager állás is gazdára talált, vagy pedig feladták.

Szeptember 19.-én publikáltak egy Hardware Operations Team Manager állást, ami arról szól hogy infrastruktúrát kell tudni összedrótozni, illetve gondolom a későbbiekben egy ilyen csapatot el kell tudni vezetni. Mindenféle Linux-Unix ismeret előny. 27-én pedig a Webisztánon volt egy bejegyzés a Reuters hírei alapján affelől hogy látszólag Európában akarnak fejleszőket toborozni.

Október elején pedig kinevezték Nelson Mattos-t az európai, közel-keleti és afrikai (EMEA) térség mérnöki tevékenységekért felelős alelnökének. A cikk leírja még, hogy hol vannak a térségben fejlesztőközpontok. Van pl. Krakkóban, ami meglepett. (Varsóban nincs.) Közben volt a TV-ben egy film, a "Google kulisszatitkai" címmel, de jól lemaradtam róla.

Egyébként pedig végzős fejlesztőket kerestek Prágában, Krakkóban, Zürich-ben és még több helyen. Nálunk nem. Svédországban pedig rengeteg állásajánlat van.

2007 Október 8: Data Center Technician (Temporary). Linux cluster összepakolásához.

További mozgások:
2008.01.15, Magyarország:
Account Manager - Budapest
Country Business Manager - Hungary
Data Center Technician (Temporary) - Budapest
Hardware Operations Team Manager - Budapest
2008.02.06
+Account Strategist - Budapest
2008.02.22
+Senior Financial Analyst - Budapest
(Közben Prágában 10 ajánlat van, közte Senior SD, szlovák-cseh-angol.)

Most pedig megnyitott a Zürich-i iroda, ami világossá tette, hogy nem lesz Magyarországon fejlesztés. A Webisztános cikk elég sokmindent leír három részben, nem is kell tovább ragozni.

Update 2009.01.22: A Google magyar munkatársai elindítottak egy blogot -sajnos keresőmarketing kategóriában. A bloggolók között van néhány fentebb említett név. Egyébként kismillió blogot találok mostanában, ami az online marketing témával foglalkozik. De minek.

Mobilhelyzet, Android

Lassan közeledik az Android Developer's Challenge névleges határideje, most van Barcelonában a Mobile World Congress (cikk róla magyarul) amin biztos bemutatnak pár Androidos prototípust, ráadásul januárban volt egy Sun Mobile Embedded Developers Days is (ahol inkább nyilván a JavaME-t és a JavaFX-et hájpolták, de elhangzott egy olyasmi mondat, hogy az "Android mindenesetre kiváló bizonyíték rá, hogy a mobil technológiában lenne mit jobban csinálni"), úgyhogy íme néhány link az Androidról és a mobil technológiáról, ami összegyűlt az utóbbi időben.

Megjelent egy könyv "Nehogy már a mobilod nyomkodjon téged!" címmel. Tartalomjegyzéke megtekinthető itt. Van szó benne Androidról is (kb 10 oldal), de alapvetően MIDP-re és Netbeansre épít.

Itt pedig egy szerintem kifejezetten ronda, ráadásul valószínűleg kamu Android kütyü látható élőben. A kanadai La Mobile egy HTC Qtek 9090-esbe tett Andriodot. Ugyanerről a Webisztánon.

Cikk a Webisztánon arról, hogy elkésett-e az Openmoko. Ugyanitt videó a Bp Meetup-os Android előadásról. A meetup-on előadó Kis Gergely elérte, hogy egy Zaurus SL-C760-on fusson a Google Android (ezt is a Webisztános Openmoko cikk kommentek között találtam.)

Developer Podcast, amit meg akartam nézni de elnapolódott, úgyhogy nem tudom mi van benne.

Javafórumról link egy blogra, ami azt fejtegeti, hogy megéri-e nevezni az ADC-re, valamint egy másik, hogy kinek hoz pénzt. A Részvételi feltételek hivatalos oldala. Egyébként a március 1-es határidőt meghosszabbítják április 14-ig. Jó ötlet, bár nem érint.

Sok Android hír mp3-ban még decemberből. Nem muszáj meghallgatni, a fontosabb linkek kinn vannak az oldalon. Ha már JavaPosse, itt van egy interjú a JavaME-ről.

NetBeans plugin Roumen-nél, hogy ne csak az Eclipse-esek örüljenek.

Futtassunk Scala-t az Androidon!

Az Androidra visszakanyarodva, decemberben elméletben még foglalkoztatott az ADC-n való indulás, de aztán más melók miatt elkallódott ez a törekvés. Szerintem olyanoknak volt érdemes ezzel foglalkozni, akik egyébként is mobil (MIDP) alkalmazásokat csinálnak és viszonylag kevés plusz munkával át tudják portolni Androidra a cuccot. Ezzel viszont az a gáz, hogy a G-nek át kell adni a szoftvert, legalábbis a kliens oldalt. Ahogy a fenti linkek valamelyike említi nem túl jó biznisz anyagilag az ADC, legfeljebb hírnév szempontjából.

Egy olyan alkalmazáson gondolkodtam, ami a mobil kameráját (majdnem mindben van már) vonalkód leolvasására használja. Sima kereskedelmi vonalkódokat és speciális vonalkódokat tudna leolvasni, amik pl. URL-eket tartalmaznának.

A kockázatelemzésig nem jutottam el, szóval nem tudom, hogy egy mobilos kamera egyáltalán be tudna-e fókuszálni rendesen egy szokásos méretű kereskedelmi vonalkódot. Lehet hogy nem. Az URL-es vonalkód viszont spanyolviasznak bizonyult, mert már létezik ilyen és Semacode néven fut, csak sehol sem használják. Legalábbis sehol sem láttam még.

Pedig jó buli lenne rányomni plakátokra, hirdetésekre, menetrendekre, buszmegállókra, bögrékre, pólókra, kocsira, sportolókra, járdára, házfalra a szokásos nyomtatós, matricázós technológiával (micsoda kampánylehetőségek!), aztán lehetne böngészni, letölteni, vásárolni, rendelni, belenézni, utánanézni, belehallgatni, játszani, tippelni, fogadni az URL bepötyögése nélkül.

A szokásos vonalkódokat leolvasva pedig árösszehasonlító, vélemény megmondó, statisztikai oldalakon lehetne lekérni az adott termékről az információkat, nem azt amit helyben a boltban hazudnak róla.

Na, ti örülnétek ilyen alkalmazásoknak?

Update 2008.12.09: Közben ahogy a megjegyzésekben is írtam, az ADC-n is igen jó helyezést ért el egy ilyen vonalkódolvasó szoftver, és a sima mobilgyártók is kezdik felnyitni a szemüket.
Update 2009.01.23: Ismét egy sg.hu cikk. Ahogy látom Japánban már több éve használják a 2D vonalkódot. Olyan is van, hogy Semapedia.

JUnit 3.8 Intermed

Azt gondolná az ember hogy tesztesetek írása csupa unalmas ujjgyakorlat.
Itt most ismét JUnit 3.8-as dolgokról lesz szó + általános elvekről.

Failures vs Errors

Alapvetés: A failure és az error is elbuktatja a tesztesetet. A failure-re számítunk, az error-ra nem.

A failure AssertionFailedError-t eredményez. Hogyha a teszt amiatt bukik el, hogy a setUp()-ban vagy a tearDown()-ben exception keletkezett, az pl. error-t eredményez.

Figyelem: A fail()-t és az elbukott assert-eket elkapja a catch(Error), mivel ezek AssertionFailedError-t dobnak. Úgyhogy ha valami (különös) oknál fogva Error-t kell elkapnunk vagy ellenőriznünk, az AssertionFailedError-t tovább kell dobnunk, mert különben szépen csendben elnyelődik. (Pl. külön catch ágat adhatunk az AssertionFailedError-nak.)

A teszt metódusokat el lehet látni throws kitétellel. Ha bekövetkezik az exception, Failure lesz a teszt eredménye. Az a mondás, hogy jobb throws kitételt írni a teszt metódushoz, mint a metóduson belül catch-sel elkapni és kézzel fail-t hívni. "Sosem kapjunk el nem várt exception-öket."

Text test runner kimenetei:
. pass, F:failure, E:error

Assertions

Az asserteknél általában mindig az első paraméter a várt, a második a kapott érték. Ha message is tartozik az assert-hez, az ezeket mind megelőzi.

assertNotNull: van ilyen, nem kell assertEquals(true, obj==null)-t használni.

Az assertSame szolgál a referenciaegyenlőség vizsgálatára.

Az assertEquals nem használható tömbök egyezőségének vizsgálatára. Tömbök egyezőségének vizsgálatához ez ajánlott:
assertTrue(java.util.Arrays.equals(expected, actual));

Redundant assertion antipattern: pl. assertTrue(true)-t betenni olyan helyekre (több helyre), ahova szerintünk elér a vezérlés.

Egyebek

junit.extensions package: A test decorator-ok, mint például a RepeatedTest arra valók, hogy különféle kiegészítő viselkedéseket vezessünk be a tesztek futása előtt illetve után. A test decoratorok tehát nem test suite-ok.

Nem lehet párhuzamosan (szimultán) teszt metódusokat futtatni egy TestCase-en belül. Az ActiveTestSuite-tal lehetőség van tesztek futtatására oly módon, hogy minden hozzáadott TestCase külön szálban indul el párhuzamosan, de a TestCase-eken belül a teszt metódusok továbbra is egymás után hajtódnak végre valamilyen sorrendben.

Interfészekkel tesztelni egyszerűbb. Emiatt (extrém megközelítés) a tesztelés szempontjából elónyösebb, ha a tesztelendő komponensben minden interfész. (A lokális változók, a visszatérési értékek és a függvény paraméterek.)

Hogyan győződhetünk meg róla, hogy a tesztjeink függetlenek egymástól:
-Ugyanazokat a teszteket futtassuk kétszer egymás után.
-Futtassuk a teszteket különböző sorrendben.
-Néhány tesztet üssünk ki mesterségesen és győződjünk meg róla, hogy a többi teszt továbbra is rendben lefut.

A TestSetup osztállyal lehetőség van a normál setUp és tearDown működést kiegészíteni pl. így:

 public class TestBigClass extends TestCase {
      public void testMethod1() {
          System.out.print("A");
      }
      
      public void testMethod2() {
          System.out.print("B");
      }

      public static void customSetUp() {
          System.out.print("C");
      }
      
      public static void customTearDown() {
          System.out.print("D");
      }
      
      public void setUp() {
          System.out.print("E");
      }
      
      public void tearDown() {
          System.out.print("F");
      }
      
      public static Test suite() {
          TestSuite suite = new TestSuite();
          suite.addTestSuite(TestBigClass.class);
          
          TestSetup setup = new TestSetup(suite) {
              public void setUp() {
                  customSetUp();
              }
              
              public void tearDown() {
                  customTearDown();
              }
          };
          return setup;
      }
  } 

A futtatás eredménye: CEAFEBFD vagy CEBFEAFD, mivel A és B sorrendje elvileg véletlenszerű, tehát a custom setup és teardown közrefogja a teszteket a normál setup és teardown-okkal együtt.

A JUnit a lelke mélyén nagyjából a következő template metódust használja a tesztek futtatásához:

public void runBare() throws Throwable {
     setUp();
     try {
         runTest();
     } finally {
         tearDown();
     }
} 

Fontos megállapítás, hogy mindent dobhat (throws Throwable) és a tearDown() mindenképpen lefut.

Minták

Mock object: stub (static return)- fake (not yet implemented) - mock (valamit csinál) Bővebben.
Self-shunt: A tesztosztály egy callback jellegű interfészt implementál, ahol magukba a callback metódusokba írjuk az assert-eket.
Crash test dummy: Hibakezelés tesztelésére. Szándékosan hibát idézünk elő. Elkapjuk a várt kivételt és esetleg megvizsgáljuk a paramétereit vagy a környező változókat.
AbstractTestCase: Az absztrakt teszt eseteket is a TestCase osztályból örököltetjük, csak teszünk bele absztrakt metódusokat, például különféle factory metódusokat amelyek a tesztekhez szükséges objektumokat gyártják le. Az absztrakt tesztosztályban csak a közös vonásokat teszteljük le.
Extract repetitive setup code to fixture: Ne ismételjünk fölöslegesen a teszt metódusokon belül. Emeljük ki az ismétlődő dolgokat a fixture-ökbe: setUp(), tearDown().
Collecting Parameter Pattern: Amikor több tesztmetóduson keresztül kell összegyűjteni az eredményeket, akkor a metódusnak átadhatunk egy paramétert, amibe az eredményt belepakolhatja. A junit.framework.TestResult egy olyan osztály, amit erre felhasználhatunk. Tárolja hogy mennyi teszt futott összesen, tárolja az error-ral és failure-rel elbukott tesztek referenciáit.
Parameterized test case: Egy előző postban már írtam ilyesmiről, JUnit4 témában. Nem tudom 3.8-ban hogyan működik.
Base test case: Erről nem találtam semmit, de biztos köze van az öröklődéshez.
Good test naming: Nevezd el ésszel a teszteseteidet.

Linkek

• A JUnit mélyebb lelkivilágáról.


• Javadoc


• JUnit Best Practices a Javaworld szerint. Hasznos okosságok.


• Antipatterns az IBM-nél.


• Egy előadás shownote-jai. Nem túl hasznos.


• A JUnit recipes című papírkönyv, amiben sokminden benne van.

JUM V.

Megvolt az ötödik is. Kocka leírta hogy mi volt, az éppen építgetés alatt lévő Javafórumon pedig született egy-két topik a találkozó után. Egyik a JasperReports-ról, másik a Java 7 vitafórumról. A régi általános paláver topik pedig itt van.

A fórumon leírtakon kívül még szóba került, hogy a Windows (Vista?) eléggé .NET alapú, ami érdekes helyzetbe hozhatja a JVM-eket. Márminthogy .NET-re kell írni a JRE-t. Jobban belegondolva nem hiszem hogy ez akkora gond lesz.

Érdekes dolgok történnek mostanában, annak ellenére hogy a Java halott.

Ha jövőre véletlenül a Javapolis felé vetődnék: Sajnos elfelejtettem, hogy Antwerpenben drága vagy olcsó a tömegközlekedés és a belvárosban vagy a külvárosban érdemesebb szállást foglalni. Arra emlékszem, hogy nem szép hely, viszont jövőre is ugyanott lesz a JP.

A következő JUM március 19.-én lesz és elvileg GWT-re, SOA-ra már lehet számítani. Sörözés közben még súgtak izgalmas ötleteket a következő vagy az azutáni JUM-ra, de nem tudom mennyire publikus úgyhogy nem írom le.

Swing GUI trükkök

Éppen Swing-gel tolom. Íme néhány szépség, csak hogy látható legyen, hogy nemcsak a webes GUI készítésnek vannak meg a szépségei.

-A JFileChooser nagyon lassú Java 1.6_02-vel és 1.6_03-mal Windows-on, ha a megnyitott könyvtárban nagy zip fájlok vannak. Van róla bug report is. Több percig is eltarthat, mire megjelenik a dialógus ablak. Addig a hívás blokkolva van. 1.6_01-gyel nem lassú és ahogy nézem az 1.6_04 release notes-jában szerepel hogy javították.

-Swing komponens konstruktorába továbbra sem érdemes bepakolni a setVisible(true) hívást. Főleg modális dialógus konstruktorába, mert akkor a konstruktor hívása után már nem lehet semmit hozzádrótozni, mivel a setVisible(true); utáni kódrész csak a dialógus lezárása után hívódik meg. Modális dialógust átírni nem modálisra (és visszafelé) eléggé termékeny a hibalehetőségek szempontjából. Különben sem jó ötlet túl sok mindent bepakolni a konstruktorba, ez általános szabály két dolog miatt: 1. Biztos nem lenne hasznos valahol máshol a konstruktorba került inline funkcionalitás egy külön függvényként? 2. Öröklésnél a szuperosztály konstruktorának hívásánál még nincsenek beállítva a leszármazott osztályok mezői. Emiatt konstruktorban nem szerencsés a leszármazott osztályban (felül)definiált metódust hívni, főleg ha az a leszármazott osztály mezőit is használja.

-A JScrollPane-be ágyazott JPanel-eknek van egy rettentően kényelmetlen tulajdonságuk, mégpedig hogy amikor az egérrel görgetjük a külső scrollpane-t és ráfut az egér egy belső panelre, a görgetés hirtelen abbamarad. Erre lehet leleményes workaround-okat csinálni, kérdés hogy melyik Look and Feel-en hogyan működik.

-Look and Feel-eket cserélgetni programfutás közben -bár csábító a lehetőség- nem igazán ajánlatos. Nem mindig sikerül minden úgy ahogy kéne. Nálam néha beragadtak komponensek, azaz a GUI nagy része lecserélődött, de egy-két gomb megmaradt a jól megszokott metál stílusban. Különben -ahogy a JavaPosse-ben megmondták, a Swing Look and Feel-ek kicserélhetősége csak egy elméleti dolog, mert nem skin-ekről, hanem komponensekről van szó. Ha egyik készletben egy komponens így működik másikban meg úgy, az zavart okozhat. Említettek valami okosságot a témában, majd utánanézek. Egyelőre nem találtam meg, csak egy oldalt, ahonnan sokféle L&F letölthető. (JavaPosse 103)

-A JLabel és JButton kényelmetlen tulajdonsága, hogy többsoros szöveget csak HTML tag-ek segítségével tud megjeleníteni. Ez nem is lenne baj, viszont ilyen többsoros szövegnél már nem működik a setEnabled(false). Ajánlanak különféle megoldásokat, de egyik sem nagyon elegáns. Az alapprobléma az, hogy nem mindig elég egyszerűen kiszürkíteni a feliratot, mert némelyik look and feel-ben a bevésett halvány szöveg jelenti a letiltott label-t. Próbáltam azt is, hogy egy JEditorPane-t konfiguráltam úgy, hogy labelnek nézzen ki, de az meg a fókuszt kavarta el az oldalon és ezt nem is tudtam kiküszöbölni a setFocusable-vel és társaival. Végül úgy csináltam meg, hogy HTML-es labelt használtam, aminek setEnabled(false)-nál mondtam egy szürke színt és kész.

-A Swing komponensekhez a setClientProperty()-vel objektumokat lehet rendelni, amit aztán a getClientProperty()-vel vissza lehet olvasni.

-A Swing eseménykezelését továbbra is érdemes tanulmányozni. Legrosszabb megoldás ha egyáltalán nem foglalkozunk vele (eseménykezelőben, pl. actionPerformed semmi új szál, hanem csak az akciókód - ilyenkor hosszabb műveleteknél a GUI úgy néz ki mintha lefagyna), közepesen rossz megoldás ha mindig külön szálat indítunk az eseménykezelőkben. Jó megoldás az invokeAndWait és az invokeLater használata.

-A fest-tel nagyon jól lehet Swing-es GUI-kat tesztelni. Töltögeti a szövegmezőket, nyomogatja a gombokat szorgalmasan ahogy beprogramoztuk, csak legyen beállítva a Swing komponensek neve és legyen úgy görgetve a scrollbar, hogy látszódjon az ablakban amire klikkelni kell. Egyszerre egy klienst lehet tesztelni és jól lefogja az egész desktopot, úgyhogy ilyen jellegű tesztelésnél érdemes újságot, könyvet vagy másik számítógépet kéznél tartani, vagy elmenni kávézni.

-Ezt is beraktam a csőbe, majd valamikor elolvasom: WebCream 6.0 Swing alkalmazásokból AJAX-os webalkalmazásokat csináló medzsik (lásd még: Javaposse 137).

Amíg az embernek nincsenek túl nagy extra igényei egész jól el lehet lenni Swingben. Azonkívül ez még mindig igazán szórakoztató ahhoz képest, mint amikor JSF-ben (GWT-ben, Tapestry-ben vagy akármilyen webes GUI keretrendszerben) kell percenként aknákat kerülgetni.