PostgresPedia

Kerestem egy scriptet amivel át lehet konvertálni a MySQL dumpokat PostgreSQL által emészthető formátumba. Nem találtam semmit, pedig régen a postgres contrib csomagai között láttam ilyesmit. Van egy perl script is, amit úgy 6 éve nem tartanak karban és úgy látom nem nagyon megy. Most már mindegy...

Hát biztos van még mit pofozni rajta, például hogy insert helyett COPY-val menjen, de a wikipédia január elején kipakolt dumpjait be tudja pakolni postgres alá. Ha van hozzá tárad és türelmed :-)

Tessék.

Valamikor volt egy hamvában holt próbálkozás amúgy a mediawiki betuningolására PostgreSQL-re, a dolog a forkolásig eljutott, aztán sehova. Pedig érdekelne az eredmény.

Ha már úgyis írok: Munkatársat keres nekem a munkaadóm ide Budapestre és rohadtul fontos különben nem írnám oda mindenhova. Szóval ha bárki szereti a szép kilátást, nyugis légkört, ingyenüdítőt és hébe-hóba érdekesebb feladatokat, akkor ott van az email cím...

Hivemind & Spring in da house

Van egy web alkalmazásunk, ami több címen is elérhető. Barátságos a buta felhasználók felé, olyan nyelven beszél a felhasználóhoz, amilyen ország domain-jén megtaláltad. Többnyelvű országok mint Belgium, hát az most mindegy. Mindenesetre ez egy tapestry 4.0.x-es alkalmazás, aki ismeri a tapestry gonosz I18N rendszerét az már biztosan találkozott vele, ilyenkor a hivemind.ThreadLocale és a tapestry.request.RequestLocaleManager szolgáltatásokat kell felülfertőzni a hivemodule.xml-ben valami custom ingyombingyommal.
Cifraság kerül a képbe: ami eddig csinálta az egy spring-be beregisztrált bean szolgáltatásaival oldotta meg a problémát, ha már úgyis ott van, használjuk onnan, legyen ilyen a mi custom ingyombingyomunk.
Ez kicsit olyan mint a gagyiscifiben a dimenziókapu, hogy az egyik IoC konténer által kezelt bean-t kell bepakolni a másik IoC konténer egyik bean-jének. Ez is túlélhető mutatvány egyébként: kell hozzá csinálni egy factory-t, ami a megkapja a tapestry.globals.ApplicationGlobals szolgáltatást (ez ApplicationGlobals interface-t implementál), onnan kitúrni a WebContext-et, abból kiszedni a spring WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE attribútumát, amit már csak át kell castolni ApplicationContext-té és kiszedni belőle a megfelelő beant.

Nem is volt olyan bolonyult. Viszont néhány esztétikai kérdés nekem eszembe jutott:

• A tapestry mi a fészkes fenének wrappeli be servlet api interface-it saját érdekességekkel, amikor teljesen ugyanazt csinálják?
• A hivemind szintaktikája még annyira sem olvasható mint az avalon descriptorok voltak anno, a dokumentáció meg...
  
• Mekkora gáz hogy 2 IoC konténert kell használnunk. Persze a tapestry-nek szüksége van a hivemind-ra, de mi nem akarunk a hivemind-dal menni mert elég rendesen el van dizájnolva.

Ennyi a mai történet, nincs tanulság. Valamint a Paypal mese tényleg utolsó epizódjaként az derült ki, hogy a történelem során senki nem használta azokat az API hívásokat amiket ajánlottak nekünk a srácok. Értsd: velünk teszteltették a saját rendszerüket.
Speciel én mindig megtiszteltetésnek veszem ha egy ilyen nagy cég szivat meg :)

Nyugaton a helyzet

A sun végre valahára kiegészítette alkalmazás stackjét egy adatbázis szerverrel - még ha gagyi is kicsit, míg az Oracle felvásárolta a konkurensét és a piacát.

Csak hárman maradtak versenyben: Oracle, IBM és SUN, mindenkinek teljes saját stackje. Apróbb különbségek:

• az Oracle-nek nincs vasgyára
  
• a Sun adatbázis szervere kicsit alulfejlett (amit a népszerőségével pótol)
• az IBM java szoftverei hírhedtek stabilításukról :)

Viszont talán elöbb-utóbb kiterjed a versengés az offline webapp és más kliens oldali rendszerek témakörre, ahol olyan cápák is vannak már mint a Microsoft, Google, satöbbi.
Ki veszi meg az Adobe-t? :-)

JUM 2008-01-16

Az idei első Java User Meeting aka Paláver. Bevetettem egy kis gerillamarketinget a JHacks ügyében (köszi a lehetőségért :)), mire haza értem már új snippeket láttam. Köszi köszi :)
Szóval ezek voltak...

1. Kuvera: JasperReports
   IReports tervezővel bemutatva a Jasperreports. Elég jól nézett ki a dolog, nekem viszont a BIRT riporttervezője kicsit tökösebbnek tűnik, főleg hogy abba az IDE-be van építve amit amúgy is használok.
   Igen pontos és részletes bemutató volt, szerintem kicsit túl pontos és részletes, pl a classpath beállítások kevésbé lényeges dolgok...
   
2. Balogh Péter: SCA, SDO
   Az első cégember a JUM történetében, az IBM-től. Hát vannak az IBM szoftverekkel előitéleteim, ezt az előadást is így szemléltem, mindenesetre elég szinvonalas összefoglaló volt. Majd az apache tuscany házatáján jól szét fogok nézni.
   A melóhelyi SOAP gebaszolásokkal pont egy fényévre vagyunk ettől a szinttől, de keményen követjük a trendet gyökkettő sebességgel.
   
3. Java 7 vitafórum TVik vezetésével
   Új műfaj a JUM-on, és elég jó indítással szerintem. Nekem nagy megkönnyebbülés volt hogy nem csak én fújolok a java-xml integrációra, hanem minden jelenlevő. Viszont mi lesz a javával?
   Hát ha szabad tippelni, a java 1.5 a csúcs volt, már ebben is volt pár aknamező feature mint pl autoboxing. Lassan kevésbé lényegessé válik a java nyelv, sokkal inkáb lényeges lesz a java runtime.
   Lassan be kell szerezni a Groovy könyveket (nekem már kipipálva), 1-2 éven belül talán már hazai álláshirdetésekben is megjelennek követelményként alternatív JRE-alapú nyelvek ismerete. Majd nosztalgiázva gondolunk vissza azokra az időkre, amikor még volt normális editor ahhoz a nyelvhez, amit használtunk.
   

Paypal minefield összefoglaló

Kérem fáradjon a 3.2-es verziójú pénztárhoz.

A PayPal NVP api szerver oldali működéséről azt sikerült megtudni, hogy a "VERSION" request paramétertől függően a szerver átdobja a kérést a megfelelő verziójú backendre. Ez szerintem tök jó.
A probléma ott jelentkezik, hogy ez a bizonyos szerver egyes verziókra olyan backendre küldi át a kérést, ami valahogy meg is csinálja amit kértél, konkrétan levon a kedves vevőtől egy marék ZS-t, ugyanakkor viszont egy HTTP 500-at kapsz vissza (apache httpd 1.3.x default http 500 oldal, nem vicc), amit mivel nem tud parsolni a NVP kliens api, cefet nagy hibaként kapod vissza.
Ha üzleti szinten nézed az eredményt, igen katasztrófális: te úgy látod hogy nem sikerült a vevőt megvámolni, a PayPal viszont úgy látja hogy dehogynem, ezen a téren a programok között pedig további kommunikáció hijján ennyibenmaradás lesz.
A hibásnak bizonyult verzió a 3.0. A PayPal-es srácok szerint elég, ha a verzió stringet változtatod 3.2-re. Kipróbáltam, úgy látszik tényleg elég.
Ja és ez csak a LIVE rendszeren van, a sandbox ha lassan és kihagyásokkal is, de oké.

Tréfás?
Szerintem se. Remélem nagyon hosszú időre ez a PayPal történeteim vége.

Technotoys. Newtech meetup 2008-01-09

Lassan elkezdődik ez az év is.

• Vomberg István: Kromatográfiás méréstechnika Linux környezetben.
  Vegyészek. A címe alapján nem érdekelt volna, de sikerült felkelteni az érdeklődésemet. Ha egyszer vegyész leszek, biztosan ki fogom próbálni.
• Trencseni Márton: Facebook alkalmazásokról
  A Facebook API röviden. Említette, hogy gonosz alkalmazáok elrabolhatják a szegény ártatlan felhasználók adatait. Ebbe én is belenéztem régebben kiváncsiságból, összegányoltam rá egy "FooBar" alkalmazást, és én úgy tapasztaltam, hogy a facebook szerver nem engedi a 3rd party alkalmazásnak, hogy lekérdezze a barátok barátait. Ha jól emlékszem, a barátokról is csak az ID-t lehet tudni, semmi mást. Persze lehet hogy valami ajaxos hack-kel lehet kötyülni, mint amilyet a google mail ellen is be lehet vetni. A crawlereknek sincs sok mozgásterük, mert csak a saját hálózatuk tagjait láthatják a regisztrált felhasználók is. A facebook talán a legizmosabb adatvédelmű közösségi oldal.
• Maróy Ákos: Zigbee - wirless mesh networking protokol
  Egymással kommunikáló kis embeded rendszerek. Féligmeddig még kitalálás alatt álló dolognak tűnik.
  
• Mónus Ádám: Abaqoos pénztárca - a Felhasználók hatalomátvétele a fizetési megoldásokban is
  Nekem nem jött át a szikra, hogy miért jelent ez hatalomátvételt, de nagyon szimpatikus hogy magyar méretű pénzekért is megmozgassanak drága biteket a szerverek, ilyen 10-20 forintért. Technológiai oldalát nézve semmi új, szerencsére :)
  
• Nagy Ágoston: autoCut
  Az elejéről jobbára lemaradtam, mert a srác bejelentette hogy nem tud programozni és erre nagy hőbörgés támadt körülöttem, kint meg már addig is nagy parti volt. Gyorsan átparkoltam máshova, és nekem igazábol nagyon tetszett amit a nemprogramozó srác kitalált. Találtam ki én is hasonlót, csak persze arra sem volt időm hogy belefogjak. Ha lehetne kalapálni mégjobban tetszene, de nem lehet.
  

Hát ennyi volt...

3D

Gráf megjelenítés téma mégmindig...

Egy olyan gráf megjelenítőn álmodoztam az utóbbi napokban, ami képes 2 vagy 3-dimenziós megjelenítésre, és a csodálatos grafikus menük és toolbar-ok helyett egyetlen command line-szerű kisablakot kapna a kedves felhasználó, ahol olyan utasításokat adhatna ki, mint hogy gráf betöltése, layoutolás, clusterezés, az élek és a csomópontok tulajdonságai alapján valamilyen megjelenítési tulajdonság beállítása, szűrése. A konkrét megjelenítésen csak forgatni és nagyítani lehetne az eredményen.
Például ha egy ország közlekedési hálózata a gráf akkor mondanék egy olyat hogy
HIDE NODES WHERE population < 10000
COLOR 'red' EDGES WHERE type = 'railway'

Ilyesmi, kicsit SQL-szerűen. A nagy méretű gráfok kezeléséhez egyszerűen lényegtelen az, hogy egyenként lehessen a csomópontokat babrálni, a kicsiket meg mégiscsak jobb papíron vagy táblán rajzolni :-) Ehhez nézegetem a java 3D dolgait, ami inkáb Pali szakterülete.

• JMonkeyEngine - kicsit mintha játékra lenne kihegyezve, de nagy hype van körülötte
  
• Java3D - nekem ez elég jó teljesítményű dolognak tűnik. Kicsit régi, de újabban kitettéj java .net projectnek és mintha élne...

Valószinűleg nehézség lesz benne az, hogy maven-nel lebuildeljem, mert mindkettő natív cuccot is tartalmaz. Meglássuk akarok-e mad ilyet a végén, vagy hagyok egy ilyen kakukktojást a kupacban...

WS-Hell

Végignéztem az általam ismert java web service stack-eket (Axis 1-2, CXF, Xfire, JAX-WS) és egyik sem tudja kezelni a soapenc:Array típust. Néhányan azért mégiscsak használják, ezt az adattípust, például a google a SOAP search apiban. Ez kicsit szomorú :-(
Valamit kihagytam esetleg?

String.equals() lelkivilág...

Na jó, ez csak elmélet...

Egyszer valaki mondta, hogy a String.equals() végigellenőrzi az összes karaktert egyenként, persze csak ha ugyanolyan hosszúak. Nem hittem el, de végülis csak egy kattintás megnézni, tényleg ezt csinálja. Pedig milyen okos dolognak tűnik elöbb menézni a hashCode-t, ha az nem passzol, a string sem fog passzolni.
Viszont ha belegondol az ember alaposabban, nem olyan vészes dolog ez. Mióta Collections létezik, nem hasonlítgatunk össze nagy számú String objektumot, hanem a hash kódjuk alapján pillanat alatt megtaláljuk őket. Tényleges összehasonlítás nagyon kevés történik a Collection méretéhez képest.
Érdekes kérdés hogy ha a String.equals() használná a hashCode() metódust, akkor milyen típusú alkalmazások futnának gyorsabban, a hashCode() ugyanis bár cachelve van egy mezőben, a kiszámítása valamivel időigényesebbnek tűnik mint egy equals. Azaz rövid életű string objektumoknál valószinűleg nem térülne meg, így a java objektumfilozófiájával dolgozó alkalmazások talán valamit nyernek sebességben.
Talán mégsincs ez hülyén kitalálva, de biztosan más eredményeket adnának különböző alkalmazások.

OFF: El is felejtettem majdnem mondani hogy boldog BUÉKot kivánok mindenkinek, valamint egy éves az I Will Work For Food!

Pár hét TeamCity-használat tapasztalatai

Még a JavaPolis-on találkoztam a JetBreains embereivel, akik bemarketingelték nekem, hogy a TeamCity most már ingyen is használható 20 projectig és 20 felhasználóig. Ezzel érdemesnek tűnt egy alapos kipróbálásra.

1. Megpróbáltam a régi és az új perverz verziókövetőt is hozzáilleszteni a munkahelyemen. A rémlassú kapcsolatunkkal a verziókövető rendszereinkkel már az elején gebasz volt, erre az Jira-ba nagyon gyorsan adtak egy workaround-féleséget, amivel a Perforce (az új perverziónk) elment, az MS-VSS valami rettenetes összevisszaságot teremtett a filerendszeren. Nem vagyok bizos benne, de úgy látszik file nem maradt épen. Úgy látszik ezt valami natív VSS kliens okozza, amit a TeamCity futtat.
   Ez túlélhető, ásatunk egy csinos kis gödröt a VSS-sel és megkérjük hogy térdeljen a szélére.
2. Itthon persze a finom kis SVN fut, ezzel pillanatig nem volt probléma, ezt mondjuk el is várom :-)
3. Maven multiprojecteim buildelése. Ezzel van egy olyan különbség a continuum-mal szemben, hogy nem dobja be az alprojecteimet külön projectként. A probléma akkor következik, amikor az előző project teszt hibái miatt az új projectek tesztjeit már le sem futtatja. Ez mondjuk logikus, de jobban szeretném ha mindent mindig lefuttatna, SNAPSHOT verziókban mindig vannak törött tesztek. Na erre beállítottam egy -Dmaven.test.failure.ignore kapcsolót a maven paraméterei közé. Ezzel megy. Persze kérdés hogy ez mennyire korrekt.
4. Ezt még nem tudom, hogy miért, de a build agent újrastartolása után újra azonosítani kell a szerveren. Hmm, sebaj.
5. Az egyik eclipse installációban a TeamCity plugin nem működget. Valószinűleg az a baja hogy utólag dobtam utánna a SVN plugint. Nyilván, munkában nem használunk SVN-t, az túl egyszerű lenne. Viszont a windózos teamcity tray icon az csodás dolog, egy ilyet szeretnék én gnome-hoz linuxra.
   

Ennyi, az érdekességekről...