easyb próbakör

A CÉG másik fele (nem az amelyikben én működök, hanem a gonosz fele) nagyon kedveli a fitnesse-ben írt teszteket. Az első alkalomtól kezdve nekem nem volt szimpatikus ötlet az, hogy a programomat browserből teszteljem, wiki-ben editáljam a teszteket és ráadásul összelőni a builddel is egy borzalom (ebben a legfőbb gonoszok is egyetértettek). Másoknak se jött át az ötlet. Elkezdtem hát más, kicsit elterjedtebb megoldást keresni.
Kipróbáltam mennyire tud fájni a easyb-vel történő tesztelés és megosztanám veletek:

• A teszt tulajdonképpen groovy forráskód. Editálhatja az ember eclipse-ből -ha van groovy pluginja-, vagy alighanem netbeans-ből is (nem próblátam ki). Valamennyi highlight-olást kapunk hozzá, meg egy kics code-completiont-t is. Nem sokat egyikből sem.
  
  
• Futtatni ezt így eclipse-ből is lehetséges, de kicsit fapados (mondjuk a fitnesse-hez képest még mindig sci-fi)
• Maven-ből hajtva kicsit lassú, de rendesen fut.
• A példa kimenet szerintem viszonylag jól öndokumentáló (fájjon csak az angoloknak amit csinálunk a nyelvükkel):
  

  3 scenarios executed, but status is failure! Total failures: 1
  
    Story: situation
  
      scenario normal everyday life
        given a normal situation
        when there are some problems
        then that is just usual
  

  
  

  
  
• Példa projectet ide pakoltam fel.

JUM 2009-05-20

Ma végre összespóroltam rá időt és elhúztam a JUM találkozóra.
Ezek voltak sorrendben:

1. Révész Tamás: Groovy és Java használata SOA projectekben.
   Cobol backend elé bármit is építeni nem lehet móka. Az előadó nem volt szerintem igazán ellazulva az előadáshoz, kapkodott, amitől nekem kicsit nehezen jött át pár infó, de megpróbálom visszaadni.
   Szóval valamiért cefet sok XSLT-t kell generálniuk, néha egészen nagyokat is, és ezt automatizálták groovy-val. Utánna még kézzel meg kell igazítani (robotok sportja). Szóval csak a build processz és fejlesztés támogatásához használnak groovy-t, élesben nem fut. Gondolom nem tennék szivesen élesbe az 1600 soros scriptet.
   
2. Cursin Decurtins: Rapid prototyping with object-oriented databases
   Nyilvánvalóan szívás, amikor egy project elstartolásakor napokig elbíbelődik az ember az architektúra összekalapálásán. Főleg ha csak demó vagy prototype project. Adatbázis, mapping, miegymás. Persze segít valamit, hogy ma már elterjedtek beágyazott relációs adatbázis motorok, mint a derby, de alapvetően sokkal kevesebb meló lehet, ha nem kell mappinget írni. Az objektum adatbázis egyetlen közvetlenül elérhető layer. Példaként a db4o-t mutatta be az előadó. Valóban nagyon egyszerűnek tűnik a lekérdezés, bár volt egy pár példa, ami mögött én csúnya apikat sejtettem. Standard api nincs hozzá, ami talán annyira nem fáj egy prototype-nál. Viszont a mock-os meg a fake-k miért nem jók? Production használatra a szerző nem igazán javasolta egyik terméket sem.
   Szóval ha jól értettem, mitán megcsináltad az egyszerű objektum adatbázison a prototype-t, meg kell írnod relációs adatbázis kezelőre is.
   
3. Elek Márton: Amazon WS
   Ez elég pöpec volt. Azt hiszem ideje végre komolyan utánnanézni a témának, bár a bankszámlám számát nem szivesen adnám meg az amazonnak. Mint kiderült az kell nekik, nekem viszont borzasztó rossz tapasztalataim vannak a netes fizetőeszközök megbízhatóságával kapcsolatban.
   

python kitérő

Rövidebb időre átkényszerültem python használatára 3d alkalmazást kalapálni. Nem első ütközés a pythonnal (például itt egy scriptem ami Oracle[TM] MySQL dumpformátumát tömi be PostgreSQL-be... Hmm, lehet ez még hasznos lesz egyszer....), de munkában talán most használtam elösször úgy, hogy nem csak valami gyors egyszeri hegesztés, hanem élesben kell mennie és futnia, ügyfelek nézik majd az eredményeit.
És hát rendesen megszívatott a httplib-bel. Az az alapfelállás, hogy ez a progi egy queue-t polloz melóért, renderel valamit a saját kis 3D enginén és az eredményt szépen visszateszi az queue-ba. Mivel persze az eredmény egy szép nagy kép, gondoltam file uploaddal elpostolom. A probléma már itt elkezdődött, ugyanis a httplib ilyet nem tud. Az urllib sem tud, a későbbi python verziókban megtalálható ezeknek a libraryknak a 2-es verziója (httplib2, nagyon elegáns), de azok sem tudnak ilyesmit.
Valahol megtaláltam, hogy mikorra igérték ennek a javítását, de ezzel inkáb nem keltenék pánikot, nekem amúgy sem volt adott lehetőség, hogy felűbereljek kevésbé régi python verzióra.
Mindenesetre itt van egy nagyon egyszerű és működő megoldás file uploadra. Kis módosítás után már működött is, és boldog voltam hogy ezt is elfelejthetem. Érdemes még ezen a lapon megnézni hányan jöttek alternatív megoldásokkal.
Egészen addig tartott a boldogság, amíg a CI rendszer fel nem kapta a változtatásokat és ki nem próbálta. Az úgy 2-3 perc. Ami a localhoston működött, az valamiért mocsokul nem akart menni a tesztkörnyezeten, legmeglepőbb módon 404-et dobott az MQ, amikor vissza próbálta küldeni a eredményt. Eltartott egy ideig, amíg végigkotorásztam a tesztrendszer konfigurációit, nézegettem a logfilejait, míg végül már wireshark-ot rántottam, és ott is jó ideig néznem kellett míg végre észrevettem: http 1.0-át használt a file uploadhoz. A http 1.0 egy matuzsálem, nem voltak virtuális hostok benne, így az apache-nek végig fogalma sem volt hogy kinek postol a kliens progi.
Innentől még egy szép nagy kalapálás volt, mire sikerült végre rávennem, hogy http 1.1-et használjon a file uploadhoz is.
Úgyhogy a fenti linken látható alternatív megoldásokhoz hozzátenném a saját mégalternatívabb megoldásomat. Még szerencse, hogy mindent tesztelünk, a publikus tesztoldalakon már sokkal nehezebb lett volna kideríteni az igazságot.

Kiváncsi vagyok a profi python programozók ezt hogyan használják. Például a google a legnagyobb python felhasználó. Vajon nekik ez nem fájt?