( mhmxs | 2016. 08. 26., p – 17:00 )

Nem tudom te/ti milyen rendszereket fejlesztetek. Mi egy HadoopAsAService megoldast reszelunk, ami 0-rol felhuz egy a felhasznalo altal konfiguralt Hadoop clustert 4 cloud szolgaltato valamelyiken. Felrantja az infrastrukturat, telepiti a szukseges komponenseket, bekonfiguralja es teszteli a clustert, metrikak alapjan fel es lefele skalaz, mindenzt igyekszik hibaturoen tenni (tech previewban ugyanezt tudja Marathon clusterekkel is). Hat hidd el van side effect boven (ezek csak a kulso tenyezok lecsupaszitva). Vagy ugy is mondhatnam, hogy csak side effect van mert olyan az uzleti logikank, hogy jol kotjuk ossze a kulonbozo side effecteket, taroljuk es kezeljuk a metaadatokat. El kepzelni sem tudom mennyi munka lenne mindent ezeknek az elveknek megfeleloen implementalni a production kod karbantarthatosaganak megorzese mellett. Annyi kombinacio, meg egymasra hatas van. Kenyelmes es egyszeru mockolni helyileg, es meg nem bizonyult szuk keresztmetszetnek. Az tud egy kicsit fajni, mikor mockolni kell a mockolt metodus visszateresi erteket. Ilyenre is van pelda, van egy tipus biztos (forditasi idoben kiderul, ha nem kompatibilis eventtet akar kuldeni egy flow) async flow managerunk, ami osszefogja a kulonbozo lepeseket egy folyamatta. Bizony nem ritkak a message.getResponse().getError().getReason() tipusu hivasok. Nem mondom, hogy nem lehetne valahogy mashogy megoldani, de ez igy mindenkinek kenyelmes (es ertheto), es megsem a teszt vezerli a production kodot.

-
Big Data trendek 2016