Itt az összes fejlesztés témájú bejegyzést olvashatod; jó szórakozást!


Hat dolog, amit vezető fejlesztőként tanultam

Júliusban volt »öt éve, hogy az ingatlan.com-nál dolgozom«, és július óta vagyok a fejlesztőcsapat vezetője. A cégen belül sok dolgot láttam már, sok projekten dolgoztam, de a legtöbbet egy csapatban és egy terméken: az ingatlan.com keresőjén. A többnyire ezen dolgozó csapatban nagyjából két évet töltöttem vezető fejlesztőként.

A vezető fejlesztő sok cégnél sok különböző dolgot jelent, nálunk ez nem egy pozíció, hanem egy szerepkör, úgymond sapka: minden csapatban van egy fejlesztő, aki ezt a sapkát viseli, és akinek feladatai a szoftverfejlesztést ezekkel egészítik ki:

  • csapattagok szakmai fejlődésének figyelése és segítése,
  • fejlesztési feladatok tervezése, összefogása és megvalósítása,
  • technológiai akadályok feloldása,
  • a termékmenedzser (vagy product owner) támogatása technológiai kérdésekben,
  • kódolási irányelvek követésének figyelése,
  • az adott termék életútjának egyengetése, karbantartása, valamint
  • a hosszútávú technológiai „vízió“ kialakítása az architecttel közösen és
  • úgy általában a zöld buildek és a sikeres élesítések útjának megteremtése.

Vezető fejlesztőként rengeteg tapasztalatot szereztem, ezeket szeretném most összefoglalni. Ezt eredetileg egy blogbejegyzésnek szántam, de még vázlat korában volt lehetőségem előadni az ELTE Szakmai Esti Mesék eseményén, ahol végül egy előadás lett belőle, most viszont leporoltam a bejegyzés vázlatát is.

Még nincs vége, olvasd tovább »


KöviBusz

Mostanában főként filmekről és fejlesztési dolgokról írok, így ismét kocka témával jelentkezem, bár most nem annyira a technológiai oldalról közelítek.

Az egész sztori onnan indult, hogy nagyon régen az irodában volt egy monitorunk, amin az oldal állapotát láttuk (néhány teszt volt akkoriban még csak, ezek világítottak zölden/pirosan). Akkor a BKV-nak még semmi onleány felülete nem volt, így a Google Mapsből hákoltam ki az iroda előtti buszmegállóban a következő 178-as indulását. Apró úrias bolondéria ez, de mégis kényelmesebb, ha nem az ember orra előtt megy el a busz.

KöviBusz

A monitor azóta nagyon sokat fejlődött: lett sok tesztünk, amit szintén pirossal/zölddel jelez; mutatja a kódban lévő hibákat; jelzi, hogy melyik webszerverek vannak forgalomban és a hirdetések állapotát, számát. A buszmenetrend már régóta eltűnt, de most valamelyik este kedvet kaptam a Heroku és az »Árfigyelő« kapcsán a Node.js-sel való mókázásra, és összedobtam egy prototípust:

Build monitor az Arkonnál

A dolog annyira megtetszett, hogy azóta továbbfejlesztettem az eleinte csak egy járat kijelzését és elérhetővé tettem a világhálón. A KöviBusz azóta kapott egy MapBox térképet, megtanulta a trolibuszok, metrók, villamosok és éjjeli járatok kezelését is, az adatokat pedig a BKK Futár API-jából nyeri, így a tényleges indulást lehet látni. Az irodában néha rá szoktam nézni, szinte mindig másodperc-pontos, ami azért elég menő. A Futár amúgy tökéletesen megmutatja a BKK utóbbi években történt fejlődését, nagyon tetszik az irány.

Ennyi lett volna mára. Ja igen: nyílt forráskódú, a projekt GitHub-on megtalálható, akit érdekel a forráskód, villázzon bátran.


Apróbetűs rész: az alkalmazás semmilyen infót nem tárol rólad, legfeljebb csak amit a Google Analytics összeszed. Az elhelyezkedésedet csak azért kéri el, hogy a térképen a közelben lévő megállókat mutassa. Ha nem adod meg az elhelyezkedésedet, a térkép a Kodály Körönd környékére ugrik.


Árfigyelő

A mai napon élesítettük az ingatlan.com legújabb szolgáltatását, az Árfigyelőt, ami közel azonnal küld e-mail-értesítést, ha egy kedvencnek jelölt hirdetésed árát megváltoztatták.

Árfigyelő az ingatlan.com-on

A projekt érdekessége számomra, hogy a levelek összeállításáért és kiküldéséért felelős kódokat Node.js-ben készítettük. Az egész mögött áll még egy kis RabbitMQ-s üzengetés, meg némi klasszikus adatbázis mókolás. A csapatban majdnem mindenki ismeri a Node-ot, de ilyenformán élesben most használtuk először. Nekem ennek (és egy másik szintén icomos projektnek) kapcsán egyelőre nagyon jók vele a tapasztalataim: elsőre kis gondolkodásmód-váltást igényel, de utána rendkívül gyorsan lehet benne haladni és mivel most nagyjából olyan szerepet tölt be, mint pár éve a PHP, rengeteg dokumentáció, segédlet, nyílt forráskódú eszköz érhető el hozzá.

Amit még használtunk és lehet, hogy neked is jól jöhet:

  • log4js-node: naplózásra való, ráül a console.log metódusra, így nagyon kényelmes a használata. Tud írni fájlba, adatbázisba, kimenetre és nagyon könnyen konfigurálható.
  • knex: SQL-lekérdezések építésében és azok kezelésében nyújt nagy segítséget: áttekinthetőbb tőle a forráskód, nagyon jól dokumentált és a bonyolultabb feltételekkel is megbirkózik. Sok hasonlóval találkoztam már mindenféle nyelvben, de eddig ez vezeti a listát.
  • Nodemailer: amint a neve is mutatja: levelek kiküldésére jó. Szintén könnyen konfigurálható, nagyon jó az alap leírása és voltaképpen mindent tud, ami akár összetettebb levelezésre is kellhet.

Az új szolgáltatás valójában már tegnap elindult, de akkor elővigyázatosságból csak egy teszt címre küldte az összes levelet, de mivel láttuk, hogy egész nap és éjszaka zökkenőmentesen működött, nem tapasztaltunk semmilyen problémát, így ma délelőtt az összes felhasználónknak elérhetővé tettük.

Szóval ha van kedvenc hirdetésetek, figyeljétek a bejövő mappát, hátha olcsóbban tudtok rá lecsapni!


Térkép az ingatlan.com-on

Ez egy részben technológiai szemléletű, főként viszont személyes élménybeszámoló a napokban élesített legújabb fejlesztésünkről, az ingatlan.com térképes nézetéről, amely nagyjából fél év munkájának gyümölcse.

Honnan indultunk?

Amikor 2011-ben elkezdtem dolgozni az ingatlan.com-ot fejlesztő Arkonnál, hamar elindult egy elég nagy fejlesztés: meg akartuk csinálni az ország legjobb elhelyezkedés-adatbázisát. A motiváció érthető: ha a mi adatbázisunk a legjobb, akkor minden hirdetést pontos címmel tárolhatunk, és később könnyedén megjeleníthetünk a térképen. Akkoriban volt egy nagyon kezdetleges és egyszerű térképes nézet az oldalon, de egyrészt a háttérben egy rendkívül optimalizálatlan kód szolgálta ki, és akkoriban a szerverek sem voltak olyan állapotban, hogy elbírták volna a terhelést. Az már akkor látszódott, hogy a felhasználók nagyon szerettek volna térképen keresni, de a mérésekből azt is leolvastuk, hogy maximum 60 másodpercet töltöttek az oldalon, és mentek is át a hagyományos lista nézetre.

Az elhelyezkedések összegyűjtése egyszerű feladatnak tűnhet, de egyáltalán nem az. Magyarországon sajnos nagyon össze-visszák az alapok is: léteznek például városrészek, de sokszor még az ott lakók sem ismerik őket, mert a köznapi használatban ritkán kerülnek elő. Arról nem is beszélve, hogy egy utca háromféle adatbázisban háromféle irányítószámmal szerepel. A munkánkat nagyban segítette, hogy a csapatban van Szabó Paula térképész is, akitől az évek során én személyesen sokat tanultam a témáról (persze még mindig messze állok tőle), és aki nagyon sokat segített a projekt levezénylésében.

Időközben keresőmotort is váltottunk, az igényeinknek kevésbé megfelelő és nem annyira skálázható Sphinxet lecseréltük Apache Solr-re, ami egyébként nagyon jó döntésnek bizonyult így kicsit több mint egy év távlatából. Hosszas szenvedés, sok sikertelen nekifutás és rengeteg elfogyasztott fejlesztő után (azt hiszem, egész pontosan Gábor volt a negyedik, aki a projekten dolgozott, de szerencsére révbe ért) végül aztán elkészült az adatbázis, átállítottuk a rendszereket, vért izzadtunk pár estén át de »Mikulás napjára« élesítettük a fejlesztéseket.

Voltaképpen minden adott volt, hogy induljon a térkép elkészítése, de utána még más fejlesztések voltak fókuszban, és egyszer változott a csapatok összetétele is.

Milyen nehézségek voltak?

Egyrészt az elhelyezkedések (utcák, városok stb.) és a hozzájuk tartozó koordináták valamint befoglaló téglalapok adatainak hiánya. Ezeket a híres-neves adatbázis elkészítésével megoldottuk, de ott volt még a legnagyobb probléma: a felhasználók. Persze ne értsetek félre, imádom a felhasználóinkat, hiszen értük-nekik csináljuk az oldalt, de sajnos megküzdöttünk azzal a problémával, hogy az ingatlanügynökök rettenetesen féltik a hirdetéseikhez tartozó ingatlan pontos címét, sokszor volt már rá ugyanis példa, hogy cím alapján a vásárlók inkább megkeresték a hirdetőt személyesen, kihagyva a referenst.

Ennélfogva a hirdetések jelentős részéhez nincsen megadva cím (illetve, pontosítok: meg van adva, de a hirdetők kérésére mi azt kötelesek vagyunk elrejteni). Az pedig nagyon jó információ, hogy a hatodik kerületben van egy kiadó lakás, de nekem, mint térképen kereső felhasználónak, arra lenne szükségem, hogy melyik utca melyik sarkán van az a bizonyos lakás, különben bőven elég egy lista is. Itt nagyon sok dilemmánk volt, de végül arra jutottunk, hogy ha a felhasználó nem szeretné, hogy megjelenítsük a címet, akkor a térképen sem rakhatjuk ki pontosan a házikó ikont. A döntés így az lett, hogy település szinten (ez azt jelenti, hogy a térképen nagyjából egy egész település látszik) megjelenítjük egy buborékban a hirdetéseket, de ha közelebb megy a felhasználó, és már utcák is látszódnak, akkor csak külön, egy más grafikai elemmel, és kis magyarázattal a város vagy a kerület közepére tesszük az általunk csak pontatlan címűnek nevezett hirdetéseket.

Problémát jelentett még az is, hogy habár összeállt a csapat: Balázs, Gábor és személyemben volt három fejlesztő; Paula mint térképész; Hosszú Zoli mint grafikus, Dóka Máté és Ladnyik Miki mint profi tesztelők és persze Szűcs Ati, mint termékmenedzser valamint a csapat vezetője, azonban senki nem foglalkozott még ilyen mélyen térkép vonatkozású fejlesztésekkel, ráadásul mindenki inkább backenden mozgott otthonosan. Ismertük persze a JavaScriptet, azt is tudtuk, hogy a világ legfélreértettebb programozási nyelve, meg azt is hogy mi az a prototype, illetve nagyjából eligazodtunk az amúgy rémes OpenLayers dokumentációkban, de azért mégis.

Módszertan tekintetében hogyan fejlesztettünk?

Fent felsorolt ismereti nehézségekből kifolyólag kicsit megerőszakoltuk a Scrum módszertant, nevezetesen pedig azzal, hogy megbeszéltük, megtervezzük felhasználói szinten olyan részletesen a térképet, amennyire csak tudjuk, majd elkészítünk egy prototípust. A prototípus persze tele lesz hibával, közben rájövünk ötvenezer dologra, amire nem is gondoltunk, de: akkor már túl leszünk több száz óra fejlesztésen, és könnyedén át tudjuk írni kódot szebbre-jobbra, sőt, még esztimálást is tarthatunk, hiszen addigra már térképésszé programozzuk magunkat. Rizikós volt, féltünk, de a módszer bevált: néhány sprint alatt eljutottunk oda, hogy volt térkép, volt lista, voltak markerek is, mi pedig örültünk.

Aztán jött az igazán érdekes rész: másfél kéthetes sprint alatt három fejlesztőnek rendbe kellett tennie az egész kódot. Egy több mint ezer soros map.js fájlból végül csináltunk egy nyolc-tíz fájlból álló, jól strukturált, nagyrészt egységtesztelt és ami a legfontosabb: könnyen fejleszthető és újrahasznosítható kódot.

Amit én az egész fejlesztés alatt nagyon élveztem, hogy nem engedtük el a projektet. Sikerült elérnünk, hogy nagyon kevés más fejlesztéssel kellett foglalkoznunk, és élesítés után nem zuhantunk rá rögtön a következő feladatokra. Sokat agyaltunk, vitatkoztunk, beszélgettünk, próbáltunk a felhasználóink fejével gondolkodni.

ingatlan.com térképes nézet

Milyen technológiákat használunk?

OpenStreetMap: a térképünk adatait a nyílt forráskódú, felhasználók által szerkeszthető OSM-ből nyerjük. Ezzel kapcsolatban a legmenőbb élményem az volt, hogy Paula, a térképész kollégánk aktív tagja az OSM-közösségnek, így nagyon sok mindent ő maga javított vagy hozott létre a rendszerben. A térképet Hosszú Zoli szépen meg is dizájnolta.

OpenLayers: a böngészőben a térkép a szintén nyílt forráskódú library, az OpenLayers segítségével jelenik meg. Az OpenLayers gondoskodik továbbá a különböző, térképen megjelenő grafikai elemekről is.

Varnish Cache: a térkép csempékből áll, ezek egyszerű képek, amelyeket a megfelelő koordináta és nagyítási nézet szerint tölt be az OpenLayers. Ezen csempék kiszolgálását az ugyancsak nyílt forráskódú Varnish Cache segítségével támogatjuk.

Jasmine: JavaScript kódok egyszerű unit tesztelését teszi lehetővé, nagyon kényelmesnek és jól használhatónak bizonyult.

A kódokban használunk ma már mezeinek számító jQuery-t, a háttérben pedig a symfony 1.4-es keretrendszerben megírt PHP-kódok rángatják elő Solr-ből a különböző adatokat. A szerverek mélyén van még egy kis varázslás a térképcsempék generálásához.

Szintén technológiai érdekesség, hogy a fejlesztést feature switch segítségével vittük végig. Feature branch-et nem hoztunk létre, a szolgáltatás folyamatosan élestíve volt, eleinte csak a csapat, később csak a cég dolgozói, majd a bejelentkezett felhasználók érték el, mielőtt mindenki számára nyilvánossá tettük.

Hosszabb távon, ha indokolt lesz, tervezzük az Underscore.js bevezetését is, de egyelőre nem került rá sor.

Merre tovább?

Természetesen nem állunk le, most, hogy a fejlesztés éles, természetesen gőzerővel javítjuk a hibákat, illetve oldjuk meg az olyan problémákat, amelyek nem számítanak hibának, viszont a felhasználók visszajelzése alapján nem kényelmes vagy nehezen érthető.

És végül egy személyes gondolat: azért is örülök, hogy részt vehettem ingatlan.com térképes nézetének fejlesztésében, mert a fent felsoroltakon túl (vagy inkább azok eredményeként) úgy érzem, hogy ingatlanok keresésére az országban elérhető legjobb térképes nézet érhető el két kattintással, az országban elérhető legjobb ingatlankeresőn. És ezt egyáltalán nem mint arkonos, vagy mint fejlesztő, szigorúan mint felhasználó gondolom így, a rendszer minden ismert hibája ellenére. Abban pedig a marketingbullshitet mellőzve tényleg hiszek, hogy ezzel megkönnyítjük az otthont, irodát, nyaralót vagy fejlesztési területet keresők munkáját.

Szóval, kattintgassátok, nagyítsátok, használjátok, a konstruktív vélemények pedig jöhetnek e-mailben, kommentben és mindenféle egyéb csatornán!


Funkcionális programozás, Scala

Idén »személyes vállalásom«, hogy kicsit rendszerezettebben és koncentráltabban igyekszem tanulni szakmai újdonságokat. A terv az volt, hogy havonta egyszer egy hétvégét valamilyen új technológia megismerésére szánok. Ezzel teljesen jól haladtam, egészen addig, ameddig bele nem futottam Felhőbácsi és még sok-sok más ember ajánlására a Coursera képzésébe, amely hét héten keresztül oktatja a funkcionális programozás alapjait, a Scala segítségével.

Funkcionális programozás, Coursera, Scala

A Scala nem teljesen új nekem, a »Play! Framework« kapcsán még anno játszadoztam vele, de közel nem olyan mélyen, mint amennyire most muszáj a feladatok miatt.

Átlag hét-nyolc 15 perc körüli videóból áll egy hét anyaga, és három feladatot kell beadni. Mindent készen kapunk: Eclipse-t mint IDE-t, sbt-t mint interaktív parancssori eszközt és letölthetően a feladatok projektfájljait, egységtesztekkel. Az egyetlen problémám a videókkal van: egyszerűbb lenne egy szöveges formátum, amit reggel a buszon átolvasok, így kicsit több időt vesz igénybe, de érthetőbb is.

A beugró és az első hét feladatai is 100%-osak lettek; az első heti feladatokat egyetemi diplomával valószínűleg egyszerűbb megoldani, elég sok matek volt mögötte, de szerencsére sikerült, ha kicsit lassabban is.

Ha most jelentkeztek, még pár óráig fel lehet tölteni az első megoldást, utána kis bünti jár, de ettől függetlenül el lehet kezdeni.