HTML

asdf

Robert C Martin: Clean Architecture

2022.10.21. 09:24 tvk

Már ezer éve kódolok és pár éve architectkedek is, de mindig van amit lehet tanulni. Most éppen a Clean Architecture című könyvet olvastam el Uncle Bob-tól egy hosszabb repülőút során. Pár dolgot lejegyzeteltem magamnak egy fecnire, de ezeket inkább bedobom ide, hátha ez időállóbb.

Az első pár oldalon próbálja definiálni az architektúrát, aztán végigmegy a programozási paradigmákon (SP, FP, OOP) ami egyébként érdekes annak akinek ez új és levonja a tanulságot hogy az OO egyetlen előnye a polimorfizmus. Ezután végigmegy a SOLID elveken (ebben a könyvben van azt hiszem benne a története, hogy miért lett SOLID) és átülteti ezt az egészet modul szintre, aminek nem sok értelmét látom mert nehéz ezeket az új rövidítéseket megjegyezni. Nem is fogom.

A 104.-110. oldaltól terjedő rész jó téma. Vannak kollégák akik állandóan szétmodularizálnának, szétcincálnának külön modulokba mindent rögtön az elején. Mindig az volt az érzésem hogy ez fölösleges, túl sokat kell foglalkozni az instabil projektek életciklusával és ez a fejezet megerősít engem ebben.

Jön a szokásos téma, hogy a stabilabb és absztraktabb komponenseken kell függeniük az instabilabb és konkrétabb komponenseknek (vannak azért kivételek) aztán erről még grafikonokat is rajzol ami már elég őrült. Egy későbbi fejezetben előjön, hogy melyik a leginstabilabb és legkonkrétabb rész a kódban. Na melyik? Hát a belépési pont, a “main”. Tehát az oké, hogy az gusztustalanul függ mindentől. De azért nem kell túlzásba esni. Tetszik az a megközelítés -ismét egy későbbi fejezetből- hogy a main-be akár olyan lehetőséget is érdemes lehet betenni, ami a szoftvert valamilyen teszt üzemmódban indítja el.

A 140. oldalon elhangzik az érv amit a menedzserek utálnak, hogy az opciókat nyitva kell hagyni, a döntéseket késleltetni kell amíg lehet. Néha egyébként a döntések mögött csak hatalmi háttér vagy tekintélyelvűség van.

A 157. oldal tetején explicite kimondja, hogy a service-ek szétválasztása drága, fejlesztői időt és hardver erőforrásokat tekintve is. Mikroszervíz fanok, ehhez mit szóltok? De azért hoz pár dolgot hogy mi mentén érdemes szétvágni a szoftvert. Az nekem érdekes hogy a jar fájlot függetlenül telepíthető komponesnek veszi. Ez nyilván lehetséges bizonyos környezetben (OSGi?), de nem szoktuk. Mondjuk élném ha szoknánk.

Egyébként folyamatosan hoz példákat “Bob” régi projektjeiből. Viszont azt vettem észre, hogy engem már kicsit fáraszt ez könyben is és élőben is, amikor egy kolléga elkezdi, hogy “az előző cégemnél” és akkor lenyom egy sztorit és rövid beszélgetés után kiderül hogy a mostani helyzetben miért nem releváns.

A könyv egyik legértékesebb gondolata, ami elég sokszor visszaköszön, az a szintek (level-ek) azaz hogy az implementáció közeli részeket nevezzük alacsonyabb szintűeknek, a domain-hez közeli részeket pedig magasabb szintűeknek. Az alacsonyabb szintű részek függhetnek a magasabb szintűektől, de fordítva nem. Ez az ún. “Dependency rule”. Tehát a domain modellnek tisztának kell lennie, ne legyenek bepiszkolva (JPA) annotációkkal, stb. Ne adogassunk át felsőbb szintekre alsóbb szintű objektumokat, pl Hibernate entitásokat, hanem inkább másoljuk át új DTO-ba az adatokat. Na adjuk át implementáció specifikus paramétereket modulhatárokon. Ez a “Clean Architecture” vagy “Onion Architecture” vagy “Ports and Adapters” amit nem Bob talált ki, hanem Alistar Cockburn. Steve Freeman és Nat Pryce Growing írta ezt le a Object Oriented Software with Tests című könyvben. Bakancslista.

Későbbi fejezetben még leírja, hogy a DB, a Web, a mindenféle framework csak alacsonyabb szintű részlet, ne erről szóljon a kód meg a projekt. Ha ránéz valaki a kódra, ne azt lássa hogy ez egy X framework projekt, hanem hogy ez egy webshop, például. Akármilyen lelkesek is vagyunk egy framework iránt, ne arra építsük fel a mindent. Tartsuk meg lecserélhetőnek. Legyen ott a gondolat, hogy mi lenne ha egy év múlva már nem használhatnánk ezt a frameworköt. Újra kéne írni az egész kódot? Mert az gáz.

A fentiekkel lazán kapcsolatos a “humble object pattern” (humble = szerény). Amikor van egy nehezen tesztelhető vagy más szempontból kritikus aspektusa a kódnak, pl. GUI, akkor úgy kell szétválasztani a kódot, hogy a “humble object”-be minél kevesebb dolog kerüljön, de azok a dolgok kerüljenek oda amik nehezen tesztelhetőek, kritikusak. Tehát a GUI-val foglalkozó osztály pl legyen buta, szerény, ne pakoljunk bele üzleti logikát, ha már tesztelni nem tudjuk rendesen. Egyébként REST APIs alkalmazásoknál az endppoint-ok is humble object-ek lehetnek.

A “partial boundaries” is egy jó téma amit én is előszeretettel használok. Ez arról szól, hogy -habár nem vágjuk szét a kódot függetlenül telepíthető részekre- de mégiscsak ezzel a mindset-tel írjuk a kódot. Így egyébként tisztább, tesztelhetőbb a kód és ha szükség van rá, valóban lehetséges a vágás.

A 240. oldalnál kezdődő, szerviz-orientáltsággal foglalkozó fejezetben azért van valami amivel nem értek egyet, mert más könyvben mást olvastam és azzal az érveléssel jobban egyetértettem. (Az az Eric Evans DDD könyve volt.) Ismét a szervíz-ekre bontások ellen ágál mindenféle érvvel, de figyelmen kívül hagyja a DDD-t. Különböző bounded context-eket továbbra is abszolút érdemes különböző szervizekben implementálni.

Külön fejezet van a hardver közeli kódolásra, hogy ott is érdemes követni a “clean architecture” elveket. Ezt nagyon adom. A regiszter és I/O mókolás elveszi az ember figyelmét. Van is egy olyan hobbiprojektem a polcon ami emiatt áll, hogy elment a kód az erdőbe (nem én voltam, más besegített!) és már nem értem, nem merek hozzányúlni. A könyv vége felé még Simon Brown nyom be egy fejezetet, amiben az Onion Architectúrát fejtegeti tovább. Hogy van ez a dolog az interfészekkel, package-ekkel és osztályokkal.

Aztán pedig Robert C Martin végigveszi a főbb projekjeit a karrierje elejéről. Ez érdekes olvasmány, bár nem túl sokat ad szakmai szempontból. Nagyok voltak a vinyók, szétvágták a falat ha tönkrementek, oké. Viszont leírja hogy hogyan lett ő “Uncle Bob” és ami nekem wow-momentet okozott, hogy dolgozott a Rational Rose-on. Ezt én is használtam jó régen.

Szóval jó könyv, jó olvasmány, ajánlom mindenkinek de főleg aki tapasztalt szoftverfejlesztőnek tartja magát és az architect-kedés felé kacsintgat.

Szólj hozzá!

Címkék: könyv architect

Poszt-pandémia poszt

2022.06.10. 11:00 tvk

Nagyjából véget ért a pandémia, ideje számot vetni hogy mi változott meg.

Kávé (a legfontosabb)

2019-ben még úgy kezdődött a napom, hogy reggel még mielőtt beértem volna az irodába, beültem egy barátságos kávézóba, felnyitottam a saját laptopomat és 20-30 percet reszelgettem a hobbiprojektemet vagy olvastam. Nos, azóta ez az egész kávézólánc bezárt, de a Frei Caffé hasonlít hozzá, szóval oda még akár be is ülhetnék. Viszont valahogy nincs már rá késztetésem. Inkább a lakásomhoz közeli kis cukrászdába szoktam beugrani. A pandémia közben úgy alakult, hogy az összes széküket kirakták az utcára -mivel nem lehetett odabenn fogyasztani- és ez már így is maradt. Ez arra jó hogy bedobjak egy presszót, de a laptopot nem csapnám fel az utcán. A kávé ára is jól felment, így otthonra is vettünk egy kávégépet, de azért annak nincs túl nagy varázsa amikor otthon simán csak beviszem az adagomat. Az irodában ingyen van a kávé még mindig, szóval ha tömegközlekedéssel megyek, a jegy ára (mert bérletet már nem veszek) kiadja a napi 2 kávét. Az azért elég nagy szívás volt, amikor papírpohárból kellett az utcán innom egy félreeső helyen, ahol nem látják hogy leveszem a maszkot.

Home Office

A lockdown beköszöntével hirtelen beütött a home office. A mi lakásunk abszolút nem arra van kitalálva hogy legyen benne egy iroda-sarok, de azért van egy kisasztal a háló-nappaliban ahova a laptopot le lehet tenni. Szépen lassan a kisasztalról eltűntek a mindenféle kacatok, később vettem egy monitorállványt és kaptunk a cégtől otthonra egy monitort. Ez abban is segített, hogy az új lockdown-hobbimat (Sim Racing) kényelmesebben tudjam űzni. Még mindig egy kicsit ratyi a szitu és nekem eleve az sem segít hogy a lakásban konstans kupi van. Feleségem a kanapéról laptopozik, neki az úgy jó. Nem könnyítés az sem amikor a gyerekek otthon vannak. A pandémia előtt valahogy többet voltak a suliban, később lehetett elhozni őket, aztán a járvány közben minden délutáni tevékenység elsorvadt és ez így is maradt.

Visszatérve a technikához, először még remote-tal csatlakoztunk az irodai géphez, ami kicsit döcögős volt, de aztán a cég beruházott laptopokba. Sajnos nem a legfancybb modellt vették meg, szóval ez asztali használatra oké, de egy repülőutat a reptéren való várakozásokkal együtt nem hiszem hogy kibírna akksival. Nem szívesen nyitom ki nyilvános helyen amúgysem, mert néha olyan a hangja mint egy hajszárítónak. Kialakultak az otthonról dolgozós workflow-k, már nem para online meetingeket tartani, egészen meg lehetett szokni.

Próbálkoztunk online közös ivással, de abban mindenki egyetért hogy az nagyon kínos. Egyébként ott nem is tudnak kialakulni külön beszélgetések, hanem általában egyvalaki beszél, a többi meg hallgatja. Erre mondjuk lehetne csinálni valami szoftveres megoldást, ami a chat programon belül leszimulál egy közösségi teret. Oda lehet menni kisebb csoportokhoz, belehallgatni beszélgetésbe, stb.

Rendes Office

Az igazi office eléggé letisztult, már nincsenek dedikált munkaállomások hanem mindenki oda ül ahol talál helyet. Az asztalok üresek, szellős minden, nincs az irodában kupi. Ez nekem bejön, szívesen bemennék többször is. Az emberekkel való kapcsolattartás gyökeresen megváltozott. A legtöbb kollégával már nem találkozok személyesen. Vannak olyanok is akiket felveszünk, majd elmennek és közben egyszer sem találkoztunk.

Fíling

Végülis, ami a legnagyobb változás számomra, hogy már a pandémia közben is, de miután kijöttünk belőle azután is - nekem szinte teljesen eltűnt az én-időm. Nincs az a reggeli kávézóba beülés, ha home office-ozok akkor a család folyamatosan a közelemben van, ha az irodában vagyok akkor pedig intenzív módon próbáljuk kihasználni az együtt töltött időt. Szóval így itt-ott próbálok csipegetni magamnak pár percet, de az nem sokra elég. Tulajdonképpen ezért (is) nem csináltam bejegyzést mostanában, de ezt most már muszáj volt kiírni magamból.

Szólj hozzá!

Címkék: élet

Másvalaki kódja

2020.11.07. 10:53 tvk

Mostanában a szoftverfejlesztés humán oldala kezdett el foglalkoztatni, leírom róla a meglátásaimat, tapasztalataimat. Nem kifejezettem másoknak akarom ezzel osztani az észt, inkább a saját gondolataimat akarom rendberakni. Szóval:

Manapság a kódot (még jó ideig) biztosan ember írja. A kód maga leginkább az aktuális céges szabványokon és szokásokon alapul, de elkerülhetetlenül tartalmaz valamennyit a programozó saját egyéni stílusából, ötleteiből. Ha kód review-re is sor kerül, akkor esetleg több programozó stílusa és ötletei is keverednek, jó esetben pozitív hatást okozva.

Egy kis kitérő:

Az elmúlt években több ismerősöm is vett használt lakást. Nagyon különböző, hogy ki mit kezd egy ilyen használtan vett kéróval. Van aki megejt egy tisztasági festést, kicserél pár elavult dolgot és kész, de van aki minden egyes falat arrébb pakol és a vizesblokkot is, mert minden pont úgy nem jó ahogy éppen van.

Nos, ugyanezt érzem a szoftverfejlesztésben is, amikor legacy kódon (jó kérdés mi a legacy kód...), vagy legalábbis másvalaki kódján kell dolgozni:

Bizonyos emberek elfogadják, hogy ez a kód így készült el, megvan mindennek az oka és tulajdonképpen az egy évek óta működő és pénzt termelő rendszer. Próbálják megérteni, apró kicsi változtatássokkal jobbá tenni. Hogy konkrétumokat is írjak: egyértelmű elírásokat, standardtól való eltéréseket javítani, unit teszteket írni, ha nem tesztelhető akkor megpróbálni némileg tesztelhetővé tenni és ezután bevezetni új változtatásokat.

Mások nem próbálják meg elfogadni és megérteni a létező kódot, a saját stílusukban gondolkodnak, azt próbálják ráültetni. Ez persze nehéz, vagy nem működik. Az új változtatásokat hozzáfércelik a meglévő kódhoz és ha bug jelentkezik a régebbi kódot hibáztatják. Tipikus kijelentések ebben a szituban: ez az egész össze fog omlani, újra kéne írni az egészet, ezt lehetetlen továbbfejleszteni. Természetesen az újraírásnak is megvan a létjogosultsága bizonyos esetekben, de nem anélkül hogy minimális szinten megpróbáljuk megérteni az eredetit.

A szituációt az is nehezíti, ha a kód eredeti szerzői már nem dolgoznak az adott projekten. Ilyenkor nincs aki érveljen a kódban szereplő stílus és ötletek mellett.
Ráadásul, tapasztalataim szerint a legtöbb fejlesztő számára, ha át kell venni másvalaki projektjét, az morális csapás, bármilyen minőségű is az átvett projekt. Még sosem találkoztam olyan esettel, amikor egy átvett projekt friss gazdái jóízűen csettintettek, hogy "ejha de szép kód, de szép projekt, de tetszik". Inkább azt hallottam, hogy "úristen milyen érthetetlen katyvasz ez" még ha az előző tulajdonosok az egekbe is magasztalták a saját stílusukat.

Valójában ez nem meglepő. Már (Java és JS világban legalábbis) rengeteg féle framework és nyelvi elem létezik, frameworkökön belül is sok megoldás és azok konstellációja, és ezek nem mindig könnyen érthetőek első ránézésre. Nem esik le egyből a tantusz, esetleg kell pár hét aktív tapasztalat mire rááll az ember agya, hogy erőlködős nélkül tudja értelmezi az idiómákat.

Tudnék még ezen pörögni, de inkább leírok pár tanácsot ami segíthet a hasonló problémák leküzdésében:

  • Lehetőleg minimalizálni kell a projekt átadás-átvételek számát, vagy legalábbis okosan csinálni, átmenetekkel, beszoktatási időszakot beiktatva. A régi programozók közül valakit ideiglenesen betenni az új csapatba. Nem is tudom, talán ettől függetlenül kötelezővé is tenném, hogy fél évente legyen valami embermozgás csapatok között bár ez így nagyon rosszul hangzik.
  • A nagyszájú developereket szerintem finoman helyre kell tenni előbb-utóbb. Ha panaszkodik hogy katyvasz a kód, konkrétan bele lehet kérdezni hogy érti-e a projekt domain vagy technikai szintű koncepcióit. Ha nem érti akkor lehet mondani hogy akkor még tanulgassa, vagy gondolkodjon hogy mit akar. Ha vannak saját nagyobb volumenű ötletei akkor megkérni, hogy dolgozza ki őket részletesen, bocsássa vitára, becsüljük meg együtt mennyi idő megvalósítani aztán kérdezzük meg az illetékes PM-eket hogy mehet-e. Legtöbb esetben ezek az ötletek elhalnak már az első lépésnél amikor ki kéne dolgozni őket rendesen. De ha nem, annál jobb mert akkor talán tényleg megvalósíthatóak. Kisebb volumenű kód módosítási ötleteket egy exploratory refaktor során lehet validálni, esetleg pair programozás keretében. Itt is, az egyszerűen induló refaktor eldurvulhat és akkor egy "na jó, inkább hagyjuk" sóhaj keretében mindenki mehet a dolgára, de ha sikerül akkor örülünk.
  • Semmelyik projekt sem élhet a végtelenségig. Előbb-utóbb valóban újra kell írni, meg kell szüntetni vagy ki kell találni helyette valamit. Ez nem szokás, de én már a projekt kezdetekor elgondolkodnék exit stratégiákon: mi lesz ha majd elavul az éppen alkalmazott technológia vagy fundamentálisan megváltoznak a körülmények? A mikroservice architektúrák egyébként viszonylag jól kezelik ezeket a forgatókönyveket, legalábbis részben, de nem minden business helyzetben triviális megvalósítani őket.
  • Végezetül, ezt a könyvet melegen ajánlom a témában. A végtelenül unalmas cím nagyon hasznos és izgalmas kontentet takar:
    Michael Feathers - Working Effectively with Legacy code

 

2 komment

Fullstack!

2018.10.26. 15:04 tvk

Szóval van ez a fullstack developer, devops és software craftmanship őrület, ami nagyon menőnek számít.
Akkor nézzük át mit is kéne tudnia egy ilyen fullstack software craftman-nek, aki még ráadásul devops-ban is jártas:

Szólj hozzá!

Címkék: architect antipattern

Frontend konf?

2018.07.26. 13:03 tvk

Már több éve a Devoxx nevű antverpeni főleg Java fejlesztői konferencia visszatérő látogatója voltam, de idén valahogy elfogytak a jegyek mielőtt maga a program publikálásra került volna, szóval erről most lecsúsztam - lecsúsztunk testületileg a céggel. Nem repülök Belgiumba novemberben. Viszont ez egy kiváló indokot ad valami másik konferencia kipróbálására. Kiváló indokot arra is, hogy feltegyem a kérdést magamnak, hogy akarok-e én Java konferenciára menni, vagy inkább másfelé kellene kacsintgatni.

Szólj hozzá!

Címkék: javascript konf

A kódolás szintjei

2018.05.11. 16:52 tvk

Egy futó projektünkkel kapcsolatban elgondolkodtam rajta, hogy a programozásnak milyen szintjei vannak. Szerintem ilyenek:

level 1
Amikor nagyjából értjük a használt eszközöket. pl. a programozási nyelv elemeit. Ha a kódot egyszer láttuk jól működni akkor megoldottnak látjuk a feladatot, eldobjuk az egeret és a billentyűzetet. Automatizált tesztelés nincs, meg kézi tesztelés sem nagyon. Nincs ezzel semmi baj. Nagyházikat kettesért, hobbiprojekteket kezdetben össze lehet így dobni. Igazi gyárban még talán prototípus projekteknek is neki lehet így indulni azzal a felkiáltással, hogy majd közben megtanuljuk a dolgokat. Viszont helyén kell kezelni az elvárásokat a prototípussal szemben, és nem szabad elfelejteni tényleg tanulni. Ha tényleg ez történik, magától eljön a második szint.

level 2
Amikor már tényleg értjük a használt eszközöket. Nem elégszünk meg vele, ha a kódot egyszer láttuk jól működni, hanem tudni akarjuk, hogy az alapkoncepciók amiket használunk helyesek. Pl. a működés valóban tranzakcionális, egy számítás más értékekkel is helyes, hibakezelés rendben van, stb stb. Ehhez nem feltétlenül kell unit teszteket írni, de esetleg kód review (már ha megvan hozzá a kultúra meg a hajlandóság) segíthet. A kódnak sem kell túlzottan letisztultnak lennie, de azért jó ha úgy nagyjából rendben van. Beadandókhoz jó jegyért, rövid egyszemélyes projektekhez amiknek már tétje is van megfelelő lehet ez a szint.

Ha valakivel pair programozok és háromszor egymás után nem az történik amire számítunk ("nem azt csinálja a program amit kéne"), akkor tudom hogy valószínűleg nem értjük a használt eszközöket, nem vagyunk a második szinten. Ilyenkor már általában nem megyek bele egy következő próbálkozásba, hanem azt javaslom hogy fékezzünk, lapozzuk fel a könyvet (vagy a Google-t), gondolkodjunk.

level 3
Amikor már előre gondolkodunk arról, hogy ezt a kódot később is használni fogjuk, a kód nemcsak működik, hanem karbantartható is. Az az alap hogy értjük az eszközöket és biztosak vagyunk benne hogy a koncepcióink működnek. De itt már arra is számítani kell, hogy a kódot valami olyan ember fogja módosítani olyan módon ahogy nem kéne. Itt már a nyelvi elemek és a kommentek nem mindig segítenek, de a unit tesztek jól jönnek. A kódnak is tisztának és érthetőnek kell lenni. A hibakeresés szerintem kb kétszer annyi okosságot igényel mint magának a kódnak a megírása, tehát ha valaki mindent belead a kód megírásakor és valami über komplexet alkot, az bajban lesz amikor egy hibát kell megkeresnie és javítania, feltehetőleg nyomás alatt. Tehát ezen a szinten egyszerűségre kell törekedni.

Az előző szinthez hasonlóan, ha egy módosításhoz túl sokat kell tökölni, háromszor nem jön be a változtatás amit csinálunk, akkor ismét a fékezést javaslom. Nézzük meg mit csinál a kód, mire gondolt a szerző. Esetleg refaktoroljunk, írjunk új unit teszteket. Ha nem lehet unit teszteket csinálni, tegyük a kódot tesztelhetővé.

Szóval ezek a szintek vannak az én önkényes értelmezésemben.

Nincs olyan, hogy egy szoftverfejlesztő általánosan ezen meg azon a szinten van, mert ez projektenként változik. Egyes hobbiprojektjeimen -ahol éppen egy olyan nyelvet tanulok amit eddig nem ismertem- én is az 1-es szinten mozgok.
Viszont egy projekten belül nem árt ha minden fejlesztő ugyanazon a szinten van. Tehát egy éles gyári projekten nem jó, ha bizonyos fejlesztők a 3-as szintre törekednek valaki pedig az 1-es szinten gányol. Ilyenkor ki kell kényszeríteni kód review-ekkel, pair programozással, tudásmegosztással az azonos szintet.

 

Kódoljatok, csá!

Szólj hozzá!

Címkék: architect agile

Etikai kérdés

2017.07.20. 08:46 tvk

Nyár van, dél, kánikula, izzik a levegő. Mész a dolgodra egy városszéli parkolón keresztül. Csak egy-két autó parkol, sehol egy ember. Önkéntelenül benézel az utasterekbe, némelyik ember szemétdombot tart az autójában, mások elég rendszeretőek. Érdekes. Nem kéne ezzel foglalkoznod, milyen dolog már mások privát dolgait nézegetni.

De az egyik autóban valami furcsa. Benn van egy kisgyerek, alszik, vagy legalábbis nincs nyitva a szeme. Na ez így nem biztos hogy frankó. A motor nem jár, klíma nem megy. Lehet benn vagy 50 fok. Mit kéne csinálni?

2 komment

Címkék: metafora

Amik nem mentenek meg

2016.08.24. 21:52 tvk

Valami hotelben vagyok valahol Rotterdam mellett. Kódolni már fáradt vagyok, úgyhogy összeszedem mi a bajom a legfrissebb informatikai trendekkel. Mik azok a dolgok amik nem mentenek meg:

- JSON: az utóbbi időben a JSON nagyon menő lett, az XML meg nagyon nem. Nincs ezzel semmi baj önmagában, mert a JSON formátum valóban tömörebb és mellesleg Javascript-ben egyszerűbb feldolgozni, ami szintén menő lett, még szerveroldalon is (lásd később). Viszont az XML-hez már annyi jó eszköz volt. Pl. XSD a séma leírásához, XSLT transzformálásokhoz. Namespace-ek, attributumok, mindenféle. Namost ezt JSON-hoz is sorra kezdik újra feltalálni. De még ez sem gáz. A gáz ott kezdődik, amikor emberek elkezdenek fújolni, amikor XML-ben kell megcsinálni bizonyos dolgokat pl. konfigurációkat, lásd web.xml. De ha JSON-ban kell csinálni akkor az már mindjárt nagyon tuti és menő. Én mindkettőt használom és sosem fújolok egyikre sem, de mondjuk el tudom képzelni hogy az XML népszerűsége szigorúan monoton csökkenő tendenciát fog mutatni mostmár. De azért az még messze van, hogy a böngészők JSON alapú weboldalakat tudjanak renderelni XML helyett. De előbb utóbb be fog következni, amikor a JSON már annyira menő lesz. Muhahaha.

- Annotáció hegyek: Nem is tudom mikor jött be a Java-ba, talán az 5-ös verzióban. Néha jól jön, pl. a Lombokot én viszonylag szeretem, de van amikor inkább kihagynám, hogy pl. adatbázis mezők neveinek literálját inkább nem írogatnám be Java osztályokba. Amikor 3-nál több annotáció van valamin akkor az az érzésem hogy kicsit már túl van tolva. Ilyenkor már nagyon fel van ruházva egy osztály vagy egy metódus meta adatokkal, de hogy tulajdonképpen mit csinál az a környezet jóindulatától függ. Jól felannotáltuk az osztályokat és kiderül hogy mégiscsak másik frameworköt fogunk használni? Sok szerencsét.

- Javascript szerveroldalon: Kliensoldalon azzal küzdünk, hogy valami típusosságot vigyünk a jó öreg JS-be, mert egyébként félelmetes dolgokat lehet csinálni, valakik meg szerveroldalon kezdik használni, ahol Java-t is használhatnának vagy valami másik értelmes nyelvet. De majd idővel ők is kitalálják hogy azért néha jól jönnek a típusok. És akkor majd középen találkozik mindenki és lesz nagy egymásratalálás. Lehet hogy a végén még tényleg a Kotlin lesz a befutó?

- Ecosystem orientáltság: vannak eszközök, framewörkök, amiknek úgy kezdődik a bevezetője, hogy node.js-ben, gulp-ban, grump-ban ezt meg azt csináld. Nyilván ez azért van, mert nem elég már, hogy berakom a HTML-be az egy JS fájlt, hanem ezeknek is vannak függőségei, amiket majd a grump behúz, vagy mittudomén. Vagy nekem kéne összeszednem magamat e téren. De amúgy meg úgy érzem, hogy a szerver és kliensoldali build tool market totál szétszakadt, bár jobban belegondolva ez így törvényszerű. Maven,gradle vs gulp,grunt. Talán ezt kell szeretni.

De nem mentenek meg a mikroszervizek sem, meg a docker sem semmitől.

Hogy valami pozitívat is írjak: A lambdák a java 8-ban. Az tényleg elég menő. Biztos lehetne, de abba nem tudok belekötni. A lambdák megmentenek.

Hát nem ez lett a legösszeszedettebb posztom, de nem baj, nem kell érte lovagkereszt.

Szólj hozzá!

Termékárazósdi startupoknak

2016.01.29. 17:31 tvk

A 2015-ös Devoxx-on Antverpenben volt egy előadás Nick Boucart-tól startupok árazási modelljeiről. Akinek van 1 órája megnézni az előadást és tud angolul, az itt megteheti. A többieknek összeszedtem a lényeget:

Startupok számára baromi nehéz téma az árazás, mert sokszor olyan terméket akarnak eladni, amihez még hasonló sem létezik. Nick 11 árazási modellt mutat be, amelyek közül egyik sem 'silver bullet', de adott esetekben egyik-másik jól használható.

Szólj hozzá!

Címkék: startup

Mikroszervizek

2015.09.18. 16:10 tvk

Szerdán volt az Ericcson-ban egy Java User Meetup ahol két előadás is mikroszervizekről szólt. Kimondták amit sokan ki szoktak mondani, hogy mikroszervízeknek akkor van értelme, ha már nagyon magas a rendszer komplexitása és ideje részekre bontani. De ez szerintem csak részben igaz. Nem maga a bonyolultság a jó indok, hanem a kultúrális és technológiai távolság az egyes modulok között.

Szólj hozzá!

Címkék: architect

Egy kis lambdázás

2015.02.05. 12:43 tvk

Van a következő két metódus, ami egyébként funkcióját tekintve ugyanazt csinálja, de a szemmel látható különbség hogy az egyik névtelen belső osztályt ad vissza a másik meg egy lambdát. Egy jobb IDE egy kattintással ide-oda tudja őket konvertálni, viszont van köztük egy óriási viselkedésbeli különbség, ami remek alkalmat adhat a saját magunk vagy mások lábon lövésére. Hajtás után elmondom, addig lehet rajta gondolkodni:

    public Function<String, String> createInner1() {
        return new Function<String, String>() {
            @Override
            public String apply(String t) {
                return t + t;
            }
        };
    }
    
    public Function<String, String> createInner2() {
        return t -> t + t;
    }

Szólj hozzá!

Címkék: java antipattern

NFC alapozás

2015.01.02. 18:18 tvk

Az előző életemben már volt szerencsém az RFID és NFC technológiákhoz. Annó így fogalmaztam meg dióhéjben ezeknek a kütyüknek a működési elvét:  “Az RFID hasonlóan működik mint egy trafó. Váltakozó áram indukálódik a kártyában, ami egyben magát az adatot is jelenti, emellett a kártya áramellátását is megoldja arra az időre amíg az adatok feldolgozódnak.“ Ez elég pongyola megfogalmazás, de itt van mégegy nekifutás:

Szóval a kommunikációt kezdeményező eszköz létrehoz egy elektromágneses mezőt valamilyen frekvencián. Ez az elektromágneses mező áramot indukál az RFID kártyában, mire az működésbe lép és elkezd adatokat sugározni. Ráadásul ez a frekvencia nem feltétlenül állandó, hanem modulálva lehet bizonyos digitális adatokkal, amit a kártya esetleg értelmezni tud és ennek függvényében folytatja a működését.

Szólj hozzá!

Címkék: nfc

300ms

2014.09.11. 15:38 tvk

Annó naívan azt gondoltam, hogy mobil webalkalmazás fejlesztésnél az lesz a legnagyobb gondom, hogy a mobil eszköz képernyőjén kevesebb képpont van mint egy rendes monitoron. Hát nem ez lett a legnagyobb gondom. Köztudott hogy egér és egyéb pointer híján leginkább kézzel böködünk. Ráadásul létezik duplaböködés, tehát ha kétszer gyorsan egymás után odapöccintünk akkor az csinál valamit, például felnagyítja/lekicsinyíti a weboldalt. Viszont ahhoz hogy ki lehessen találni hogy egy dupla böködésről van szó, az első böködés után kell várni egy kicsit, például 300 milliszekundumot, azaz durván egy harmad másodpercet. Annak idején, amikor még nem voltak multitouch kijelzők, valószínűleg jó ötletnek tűnt.

Szólj hozzá!

Címkék: mobil javascript webapp

Agilis újraírás

2014.08.13. 10:41 tvk

Sok évvel ezelőtt részt vettem egy projektben. JavaEE volt az implementáció alapja, de ez nem lényeg. Több hónapig dolgoztunk rajta, aztán amikor élesbe ment, kiderült hogy nem igazán működik. Nem olyan terhelés jött rá, mint amit előzetesen elképzeltek/specifikáltak, lassú volt az egész. Nagy volt a pánik, mert az ügyfél nem akart fizetni. A menedzserek rögtön leszögezték, hogy a java szar és lassú és az egyik fejlesztő elvállalta, hogy egy nap alatt újraírja az egészet .NET-ben, ami egyébként ismét nem lényeg. Így is lett, másnapra elkészült a szoftver újabb változata és működött. Az ügyfél boldog volt, fizetett, így mindenki boldog volt.

Viszont az új változatból már kimaradt egy csomó apróság amire egyébként az ügyfélnek nem is volt szüksége, viszont az eredeti projektben egy csomót szívtunk vele. Az eredeti speckóban például benne volt, hogy hibatűrőnek kellene lennie a rendszernek. Ha elszáll a szerver, akkor egy másik szervernek át kell vennie a munkát gond nélkül. Többek között ezért választottuk a J2EE irányt, de az ügyfél végül csak egy szervert használt, szóval nem használta (volna) ki a szoftver hibatűrő képességét. Az új változatban az egyetlen követelmény az volt, hogy ideális körülmények között működjön. Semmi hibatűrőség, semmi tranzakcionalitás. Így össze lehetett dobni egy éjszaka alatt.

Úgy látszik a történelem ismétli magát, máskor is előfordult hasonló eset.

Hetekig szívtunk egy projektben pixelek helyre rakásával, corner case-ek kezelésével, a funkcionalitás tökéletesítésével, mire látszott hogy nem leszünk készen határidőre. A ravasz manager (vagy PO, mert azóta már agilisek vagyunk) kitalálta, hogy máshogy is meg lehet oldani a funkcionalitást nagyjából, ha a szoftver másik részét újra felhasználjuk. Igaz hogy nem lesznek rendesen lekezelve a corner case-ek és nem lesz a dizájnerek minden vágya megvalósítva, de az egészet meg lehet csinálni pár óra alatt. A hiányzó dolgokat meg majd megcsináljuk a következő verzióban.

Nade miért nem eleve így álltunk neki?

Jó reggelt!

1 komment

Címkék: agile

Benovative, Prezi, Sziget 2013

2014.01.10. 11:53 tvk

Tavaly egyetlen napra mentem ki a Sziget Fesztiválra. Egy beszélgetést néztem ki első délutáni programnak a Cafebabel szervezésében, ami startupokról és globális terjeszkedésről szólt. Azóta sem találtam semmi írásos beszámolót erről a beszélgetésről, csak egy rövid youtube snittet, úgyhogy veszem a bátorságot és lebloggolom 5 hónap után, amit ott helyben leskicceltem egy 400 forintos fröccs blokkjára. Biztos nem idézek szó szerint és néha a saját gondolataimat is belefűzöm, de próbálok objektív lenni.

A résztvevők: Pécsi Juli a Prezi-től, Várnagy Priscilla pedig a Be-novative-től. Ők meséltek mindenféléről.

Megismerhettük dióhéjban a Prezi és a Benovative kezdeti történetét. Egyik sem önálló vállalkozásnak indult, hanem csak így alakult. A Prezi Zoom-olós megoldását az egyik alapító eredetileg saját célra készítette, hogy az építészeti elképzeléseit demózni tudja. Aztán valahogy megtalálták egymást a másik két alapítóval és még 8 hónapig "ingyen" dolgoztak, átalakították a nyers kódhalmazt valóhban eladható termékké, mielőtt sikerült kockázati tőkéhez jutniuk. A Benovative alapötlete -ha jól értelmeztem- eredetileg egy pszichológiai-szakos egyetemi feladat eredményeként született.

Priscilla mesélt az USA-beli tapasztalataiból: USA-ban a meetup kultúra eléggé más mint idehaza. Odakinn jóval kötetlenebb, mindenki beszél mindenkivel, mindenki próbál segíteni, néha előre meghatározott program sincs. Idehaza kevésbé beszélgetnek egymással az emberek, kevesebb a komunikáció, nagyobb hangsúly van az előadások passzív végighallgatásán. Hasznos tapasztalat volt  számára kimenni egy konferenciára rendezőnek mert úgy sokkal többet lehet tanulni, mint látogatóként. Elvileg némi emailezés után nem nehéz bekerülni rendezőnek. Lakott egy ideig "startup házban", amit pl. a Social Network című filmben is látni, de a srácok csak lumpoltak, nem ment az igazi meló. Az igazi startupperek meetupokra sem járnak smúzolni, hanem az irodában dolgoznak és olyan konferenciákra járnak, ami valóban beleillik a szakterületükbe. USA-ban a "we can do it" hozzáállás a tipikus, a hurráoptimizmus, ami néha egy európai embernek már kicsit sok.

Az USA még más kontextusban is szóba került. Az USA egy hatalmas, nyelvileg homogén piac, ami előnyt jelenthet Európához képest. Európára, vagy az egész világra célzott projektben rögtön gondolni kell a többnyelvűségre, ami igen sok többletmunkát igényel. Ehhez képest, ha egy projektet USA-ra céloznak, rögtön el tudnak érni több száz millió felhasználót mindenféle többnyelvűségi támogatás nélkül. Volt olyan finn mikroblogger startup, ami konkrétan a lokalizációba bukott bele.

Szóba került a dizájn, a külcsín. Amikor a Benovative egyik kezdeti verzióját megmutatták prominens embereknek, nem várt visszajelzéseket kaptak. Arra számítottak, hogy majd a funkcionalitást, az alapötletet kritizálják, ehelyett a dizájnról kaptak kritikát. Legyenek mások a színek, a grafikákon az emberek kicsit máshogy nézzenek ki. A Prezi oldaláról is megerősítették, hogy manapság jóval több hangsúlyt kap a dizájn, mint a logika ami alatta dolgozik. Változnak az idők. Ma már az az elvárás, hogy az "app" egy segítőkész szép kis manó legyen, aki kitalálja a juzer gondolatait, nem pedig egy bürökrata hivatalnok "szoftver", aminek érteni kell a nyelvén és semmit sem csinál meg magától. Ma már nem érdekel senkit a "kód". Manapság már inkább a dizájnereket küldik nyilatkozni is, ők a rocksztárok, nem a programozók. (Ehhez persze programozóként van néhány szavam. A nagy dizájnolás közepette ugyanis gyakran elfelejtődik a gondolkodás, pl. hogy a különböző funkciók hogyan interferálnak egymással.)

Kockatőkéről is szó volt, aminek lehet beszélni két fajtájáról. Az egyik a "smart money", a másik a "dull money". A buta pénzt csak odaadják és figyelik hogy jönnek-e az elvárt mutatók és ha nem akkor bukta van, elzáródnak a pénzcsapok. Az okos pénznél ugyanúgy figyelik a mutatókat, de szakértelmet is adnak. Tudnak segíteni szakmailag amikor kell. Értelemszerűen szerencsésebb smart money-ra utazni.

Kb. hárman jelentettük a hallgatóságot, aminél egyébként kicsivel többre számítottam. Úgy látszik a szigetelők és a startupok iránt érdeklődők halmazának metszete nem túl nagy. Mindenesetre utólag is köszi a szervezést és hogy tényleg megtartottátok a beszélgetést a hőség ellenére is. Mellesleg sikerrel használtam a szig.it alkalmazást aznap az androidos telómon.

Szólj hozzá!

Címkék: startup

IT Architect kerekasztal

2013.12.19. 09:47 tvk

Kb. huszan gyűltünk össze tegnap a Kirakatban az első IT-Architect meetup alkalmából, hogy megvitassuk mi a jobb irány: a svájci bicska, vagy a sok kis egyszerű szoftverkomponens a Keep It Simple elvet szem előtt tartva. A bevezetőben megtudhattuk hogy mindkét irány a hadseregből származik. A svájci bicska értelemszerűen az alpesi országból, a KISS pedig az USA hadseregéből, ahol inkább a moduláris, könnyen cserélhető eszközöket részesítik előnyben.

Aztán egy meglepő kérdéssel folytattuk: mi az alkalmazás? Végül nem jutottunk dűlőre, nem tudtunk letenni egy definíciót az asztalra, de voltak benne ilyenek, hogy értéket közvetít, egyben release-elhető (közben rájöttem hogy ez nem igaz), egy gépen futtatható szoftver komponensek (ez sem feltétlenül igaz). Ennek a definíciónak működnie kellett volna egy Excel táblára (ami lehet alkalmazás), az SDK-ra (ami nem alkalmazás), a Gmail-re (ami a user szempontjából egy alkalmazás a browserben, de backend-en több alkalmazást jelent), demoscene-s szoftverekre, amik üzleti értéket nem közvetítenek, de egyértelműen alkalmazások, és végül SOA-komponensekre, amik nevezhetőek alkalmazásoknak.

Sokféle helyről jöttünk. Volt pár jávás, de volt PHP-s ember is. Nem mindenki definiálta magát architect-nek, volt aki tanulni jött. A vélemények is nagyon sokfélék voltak. Ami nekem feltűnt, hogy a vízesés modell-szerű fejlesztéstől már majdnem mindenki elrugaszkodott -legalábbis azt hiszi- de a Scrum-ban és az agilis módszertanokban még nem hisz. Az adott cégben való szerepek is kihallatszottak. Érezhetően volt aki közelebb van az üzleti döntésekhez a munkahelyén, nagyobb a rálátása a folyamatokra. Van aki olyan helyről jött, aki másnak fejleszt szoftvereket, van aki magának.

A többség afelé hajlott, hogy érdemesebb sok kicsi "alkalmazást" fejleszteni, mint egy monolitikus nagyot még akkor is ha van némi overhead-je. Ahogy folyt a beszélgetés, kiderült miért kellett volna az elején tisztázni mi az alkalmazás. Mi például egy kívülről monolitikusnak tűnő szoftvert (alkalmazást) fejlesztünk, ami belülről viszont modularizált. A modul viszont nem egyenlő az alkalmazással, bár most nem vállalkoznék a különbséget fejtegetésére.

Természetesen nem tudtunk megegyezni mi a jobb irány, de megpróbáltunk legalább érveket felhozni a két oldal mellett. Ez sem sikerült száz százalékban, de szerintem gondolatébresztőnek jó volt a kerekasztal beszélgetés, ami valójában két kerek és egy négyszögletes asztal mellett zajlott, sörözés helyett forraltborozva.

Következő alkalom a vállalati kommunikációról fog szólni. Már előre megbeszéltük, hogy az sem lesz könnyebb menet. Gyertek!

1 komment

Címkék: meetup architect

Devoxx 2013

2013.11.22. 11:34 tvk

Idén is volt szerencsém eljutni a Devoxx-ra, Európa legnagyobb Java konferenciájára Antwerpenbe. Legalább négy magyar cégről tudok, aki küldött ki embereket. Ezek közül a DPC-sek szorgalmasan bloggoltak is az előadásokról. A helyszín még mindig a város széli mozikomplexumban van, a villamos még mindig tömve van, idén még gyanúsabb szendvicseket és salátákat sikerült csinálniuk, viszont a wifi egy hajszállal jobb lett.

Szerdai Keynote Hagyomány szerint a főrendező vezette fel a show-t, aki egyben a Parleys alapítója. Az előadásokat meg lehet majd nézni a Parleys-on karácsony tájékán a regisztrált usereknek, egy év után pedig mindenki számára elérhetőek lesznek. Ez egyben azt is jelenti, hogy a tavalyi Devoxx előadások már elérhetőek. Nagyon rá volt izgulva az új tervezett feature-jükre, hogy egy előadást mobilokkal több szögből is fel lehet venni, amit aztán majd ők összekombinálnak. Prezentációknál szerintem pont semmi értelme, de sportrendezvényeknél ez nagyon hasznos lehet. Brian Goetz az Oracle-től egy kis történelemmel kezdte,, majd a Java8-ban megjelenő lambda kifejezésekkel ismertette meg a közönséget. Voltak még kütyük, sakkozó robot, Amiga korszakot idéző Java 3D animáció.

Szerda Először az UI engineer-ekkel kapcsolatos előadásra ültem be, hátha választ kapok a fejemben homályosan megfogalmazott fejlesztőkkel és dizájnerekkel kapcsolatos kérdéseimre, de nem sok újat hallottam. Egy UI engineer-nek sokmindenhez kell értenie. Aztán azt próbáltam meg kideríteni, hogy a nagyon hatékony csapatok milyen elvek mentén dolgoznak. Martijn rocksztár, úgyhogy a lépcsőn ültünk a teli teremben. Néhány ötlet: közös célok, tisztelet és bizalom újoncoknak is alapból (kétszer lehet büntetlenül hülyeséget csinálni), közös kultúra, vita megengedett de néha tartsunk szünetet, virtuális ablak a többi irodára. Beültem Szegedi Attila Javascript-es JVM-es előadására is, de csupa olyan dolgokról hallottam, amivel egyáltalán nem szeretnék foglalkozni. A nap végén az ideális Java modulrendszerekről és a rögvalóságról szerettem volna tájékozódni. Az a helyzet, hogy ebben a témában tavaly Kirk Knoerschild már mindent elmondott, a könyvében pedig leírta.

Csütörtöki keynote A csütörtöki keynote a Google-é volt, amit egy az egyben be is áldoztak Dart nyelv ismertetőnek. A Dart egy böngészőoldali megoldás, ami a Javascriptet hivatott leváltani. A Chrome-ban van natív Dart futtató motor, a többi böngészőnek viszont be kell érnie a Javascript-re fordított Dart kóddal.

Csütörtök Először egy felhőtechnológiás patterneket taglaló előadásra ültem be. Erről majd írok egy külön posztot. Aztán a lambda kifejezésekkel ismerkedtem. Venkat-ban nem csalódtam, iszonyat jól nyomta. Slide-ok nem voltak. Levette a cipőjét, elindította a text editorát és realtime kódolt, a közönség pedig sírva röhögött és habzsolta a jól tálalt információt. Lefogadom, hogy ez egy klasszikus, sokat nézett és ajánlott anyag lesz, amint felkerül a Parleys-re. Amiket még nem tudtam, hogy a .foreach()-et internal iterator-nak hívják és plomorfizmus szempontjából jobb, mint a sima procedurális for ciklus. A .stream() olyan lusta mint a gyerekek ha leckét kell csinálniuk. A lambda kifejezések pedig nem csupán szintaktikai cukorkák, amik névtelen osztályokra lesznek lefordítva, hanem a háttérben az invokedynamic is szerepet kap, ami gyorsabb működést tesz lehetővé. (Itt már meg lehet nézni a videót egy másik konferenciáról.)

Csütörtök még Érdekelnek az NFC-s cuccok, ezért beültem az NFC+Chrome-os témára. Chrome böngészőből lehet USB-re kötött NFC-s kütyüt vezérelni. Ez elég érdekesen hangzik, de még nem nyílt forrású a JavaScript könyvtár ami ezt kényelmesen lehetővé teszi. Az Agile Architecture Management megintcsak Kirk tavalyi előadásai nyomában kullogott, fő üzenete az volt, hogy kerüljük az irányított függőségi köröket a csomaghierarchiában. Van egy kódanalízis szoftverük, ami segít az analízisben, végülis érdemes lehet kipróbálni. A Javaposse livet is megnéztem.. Nem lettem okosabb, de nem is az a lényeg. Még Continuous Delivery-vel kapcsolatos előadásokra ültem be. Talán majd írok egy-két eszközről amit ajánlottak, de új dolgokat már nem mondtak. CI jó, használjuk ki, ez a lényeg. Ja és ne adjunk ki nem-hivatalos release-eket, soha.

Szólj hozzá!

Címkék: javascript java konf

Google Apps Scripts II.

2013.07.05. 14:53 tvk

Régebben már írtam a Google Apps Script-ről, most jöjjön egy kis frissítés. Emlékeztetőül: Mindenféle Google szolgáltatást lehet programozni a kedvenc programozási nyelvedből (pl. Java). Ha a kedvenc programozási nyelved netalántán a Javascript, akkor még könnyebb dolgod van, mert közvetlenül a böngészőből is írhatod a kódot.

Szólj hozzá!

Címkék: google webapp appengine

Webapp performance, Chrome DevTools @Devoxx

2013.01.11. 13:42 tvk

Körülbelül 10-20 webalkalmazást csináltam eddigi pályafutásom során, kb. 7 különböző Java és/vagy Javascript  keretrendszert használva. Egységsugarú szoftverfejlesztőként leginkább az érdekelt, hogy mennyire kényelmes a mások által kiválasztott keretrendszert használni, mennyire jól karbantartható a kód. A leggyakoribb esetben semmi kapcsolatunk sem volt az üzemeltetőkkel, ritkább esetben volt némi kommunikáció. Ilyenkor azt hallottuk hogy utálnak minket, mert a webalkalmazás lassú, rohadtul zabálja a sávszélességet és lehetetlen konfigurációs szinten optimalizálni, pl. nem lehet úgy beállítani a proxy-t, hogy cache-elni tudja a tartalmat, de különben is egy login oldalhoz minek kell 1 megabájt? Az architekt-jeink általában egy hanyag "sorry"-val elintézték az ügyet. Bocs, ilyen a keretrendszer amit használunk - és továbbra is toltuk bele a megabájtokat a drótba. Szerintem ez nem volt valami profi hozzáállás.

Úgy gondolom, hogy aki több akar lenni mint "egységsugarú webprogramozó", nem elég hogy a nyelvet ismerje amin webalkalmazást ír, és persze a HTML-t és a Javascript-et, hanem azzal is tisztában kell lennie, hogy a bájtok hogyan jutnak el a browser-hez és a browser mit kezd velük. Ennek ismeretében képes lesz rá, hogy az aktuális keretrendszert optimálisabban használja, vagy legalább meg tudja indokolni hogy miért kellene az egészet kidobni a fenébe.

Szólj hozzá!

Címkék: konf webapp

HTML5 Webappok mobilon @Devoxx

2013.01.02. 17:22 tvk

A Devoxx-on jópár előadás webalkalmazásokról és azok optimalizálásáról szólt. Ezen belül a mobil böngészők különös figyelmet kaptak, mivel a 2012-es az az év volt, amikor a mobilról jövő forgalom leelőzte a desktop-ot.

Wesley Hales HTML5 and Javascript Web Apps című előadása volt az első a témában, akinek van egy azonos című könyve is. A terem totálisan megtelt, a lépcsőn találtunk magunknak helyet. Pontokba szedve foglalom össze, hogy mik kerültek szóba, miket véstem a füzetembe:

Szólj hozzá!

Címkék: javascript konf webapp

Scala @Devoxx 2012

2012.12.07. 13:39 tvk

Ma már egy Java konferencia nem múlhat el Scala előadások nélkül, így volt ez az idei Devoxx-on is. Az első university nap egy teltházas First Steps with Scala-val kezdődött Dick Wall és Bill Venners tolmácsolásában. Ezt kihagytam, mint ahogy az esti bratyizós és rejtvényfejtős session-öket is. A Scala-s rejtvények nagyon gonoszak tudnak lenni, nem egy fárasztó nap végére valók. De lehet hogy igazából nem is rejtvényfejtés volt, hanem a scalakoans-on nézegették a gyakorlati Scala feladatocskákat.

Kedden viszont már bementem az Advanced Concepts and Best Practices-re, ami nem pont arról szólt, mint ami meg lett hirdetve. A hamarosan jövő 2.10-es verzió újdonságait mutatták be és néhány jótanácsot adtak. A poszt végére biggyesztettem egy konklúziót, úgyhogy akinek a Scala vagy a funkcionális programozás viszonylag új vagy magas, az rögtön oda tekerhet. Itt olyan dolgok következnek, amiket magamnak firkáltam le:

2 komment

Címkék: konf scala

Magyar Java helyzet 2012

2012.11.30. 23:23 tvk

Valamivel több mint egy éve írtam egy posztot az aktuális magyar Java helyzetről, ami akkoriban nem volt túl rózsás. Azóta sok pozitív dolog történt. A javaforum azóta is él és virul, csak átköltözött Confluence alapokra. Egyúttal a budapesti Java meeting, a JUM is beköltözött a javafórumra és ősszel meg is rendeztünk két alkalmat a XI. kerületben.

Az idei első JUM-ot -sorrendben a 19.-et jórészt házon belüli előadókkal oldottuk meg szeptemberben Auth Gábor a Java 8 lambda kifejezéseiről mesélt, Kovács Richárd a Grails-et demózta, Viczián István pedig workflow esettanulmányokat mutatott be Ant és egyéb alapokon. A videók fenn vannak a javafórumon.

A huszadik JUM-on én adtam elő a Devoxx-os élménybeszámolómat, majd Újhelyi Zoltán mesélt az Eclipse pluginek fejlesztésének rejtelmeiről, végül Marhefka István beszélt a Be-Novative startup technológiai stack-jéről. Prezik, videók itt. A videók egy állványra szigszalagozott Android telóval készülnek, szóval túl jó minőséget nem kell elvárni, de bármilyen ezirányú segítséget szívesen veszünk.

A következő JUM a következő páratlan hónap harmadik szerdáján lesz. Ha valaki jönne előadni szívesen látjuk, bár az a szerencsés helyzet állt elő, hogy már most is van pár jelentkező a talonban. De azért be lehet kerülni. :)

A javalista is újraéledt a jó régi atombiztos motorral. Hol máshol, mint a Javaforum-on. A java-val kapcsolatos Google Group-ok viszont nem bizonyultak életképesnek. Nehogy kihagyjam Kozka twitter aggregárorát, a MagyarJava-t, ami néhány hazai blog frissítéseit böfögi tovább.

Egy Java Bár nevezetű esemény is szerveződött a meetup.com keretében Simon Gézáék háza tájáról, ami eléggé hasonlónak tűnik a JUM-hoz. Ez is kéthavonta lesz megrendezve elvileg. További infó még itt.

Vannak még viszonylag új blogok, például a tifyty mindenképpen említést érdemel. A Facebook-on Marhefka István indított egy szakmai csoportot, Be-novative developer forum névvel, ami nemcsak a Be-novative-ról szól. Összejövetelek közül az Eclipse Democamp még mindig egy biztos pont egy évben egyszer, sőt már Budapest mellett Pécsett is rendezik.

Tehát van egy kis mozgolódás, van hova menni és van mit olvasgatni. Ez a blogposzt viszont a teljesség igénye nélkül készült, szóval ha valakinek van valami jó kis hazai linkje eseményre, blogra, az nyugodtan kommentelje be.

1 komment

Címkék: java konf

Appengine HRD migráció

2012.09.13. 13:13 tvk

Kezdetben a Google Appengine alkalmazásokat csak Master/Slave datastore-ral lehetett összekapcsolni. Ennek a hátránya az volt, hogy a datastore elérhetősége egy konkrét datacenter állapotától függött. Ezen kívül időnként tervezett leállásokkal és readonly módba kerülésekkel kellett számolni, tipikusan amíg replikálódtak az adatok a master és slave között. Cserébe viszont volt erős konzisztencia. Az írás gyors, a beírt adatok pedig rögtön visszaolvashatóak. Ami engem illet, egyébként sosem volt gondom a tervezett leállásokból.

Aztán bevezették a High Replication Datastore-t. Egy időben lehetett választani, hogy melyik fajtával akarom működtetni az alkalmazást. A létrehozásnál meg kellett mondani és többet már nem lehetett megváltoztatni.
 
A High Replication Datastore (HRD) rendelkezésreállása jobb, azaz egyáltalán nincsenek tervezett leállások, viszont a konzisztencia gyengébb, az írási műveletek pedig lassabbak, a beírt adatok nem olvashatóak rögtön vissza. A gyakorlatban ha egy egyszerű webformon keresztül elmentek valamit és ezután úgy akarom megjeleníteni a webformot, hogy visszaolvasom a datastore-ból az adatokat -egyáltalán nem biztos hogy jól fog működni (Master/Slave esetén jól működik). Lehet hogy egy darabig még a régi értékek fognak megjelenni. A háttérben a datacenterek között Paxos algoritmussal replikálják az adatokat, így az adatvesztés esélye még kisebb.

Szólj hozzá!

Címkék: google appengine datastore

GitHub for Windows

2012.08.24. 13:12 tvk

Alapsztori: Windows user szeretne Git-et használni, GitHub-ról leszedegetni cuccokat, esetleg saját repót létrehozni, más projektekből leágazni. Mit csináljon? Hol kezdje? Tegyük fel, hogy a user túl van már az elosztott verziókezelő rendszerek alapjainak megismerésén, esetleg találkozott már másik elosztott verziókezelő szoftverrel, pl. Mercurial-lal.

Az általam ismert opciók:

  • Cygwin + Git - de ha csak a Git alapműveleteire van szükség, nem pedig egy teljes Unix shell szimulációjára, ez ágyúval verébre megoldás.
  • TortoiseGit - A TortoiseSVN portolása Git-re.
  • Létezik egy Git for Windows nevű szoftver, ami viszonylag kényelmesnek tűnő integrációt nyújt, de van némi keveredés a program elnevezése körül. Installáltam, könnyű volt, de kérdezett meglepő dolgokat, pl. hogy hogyan akarom kezelni a sorvégeket, promtból vagy Gui-ról akarom majd inkább használni. Mit tudom én, leginkább is-is. Itt is van egy 5 perces videó az installálásról és az alapvető használatról.
  • Aki tényleg csak a GitHub-on akar nyomulni, annak a GitHub for Windows lesz az ideális megoldás, ami nem is egy régen indult történet. Itt is van róla egy pozitív hangvételű rövid angol nyelvű cikkecske. A kommentekből kiderül, hogy nem csak GitHub-ra lehet használni, hanem másik tetszőleges Git repó-ra is, mivel ez egy közönséges Git kliens.


2 komment

Címkék: git version control

Komment

2012.07.26. 23:12 tvk

Éppen a Clean Code kommentekről szóló fejezetét olvasom Robert C Martin-tól és azt kell hogy mondjam, nem értek vele 100%-osan egyet. Az ő véleménye szerint a kommentek nagy része szükségszerűen rossz, valami olyasmit fejez ki, amit a programozó nem tudott beleépíteni a kódba. Egyfajta magyarázkodások, amik ráadasul időnként elavulttá válhatnak, mert a kód fejlődik, de a kommentet senki sem frissíti.

Egy programozónak elég könnyű magáévá tenni ezt a véleményt, és párszor már vissza is hallottam. Nem kommentelünk, mert Uncle Bob Martin szerint nem kell. Hurrááá, úgyis utálunk kommentelni! Inkább használjunk beszédes változó és metódusneveket, írjunk tiszta kódot! Nemes elhatározás.

3 komment

Címkék: komment antipattern

süti beállítások módosítása