Megosztott hirdetés

HTML

asdf

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

Google App Engine előadás

2012.04.25. 11:47 tvk

Éppen a Buena Vistából jövök, ahol egy kellemes Google App Engine előadást hallgattam meg a Kelly IT resources rendezésében Piros Andrástól. Ebben a témában mindig lehet új dolgokat tanulni. Csak néhány:

  • Az előadó megerősített a hitemben, hogy a JSF orbitális mellélövés Appengine-en belül és kívül. Appengine-en belül főleg azért, mert csak kliensoldali státusz eltárolás a támogatott, ami azt eredményezi, hogy irtózatos mennyiségű szerializáció és deszerializáció történik egy HTTP kérés kiszolgálása közben csupán azért, hogy a HTML-be bekerülhessen a GUI szerveroldali objektumfa reprezentációja BASE64 formában. A szerveroldalon jelentkező több(száz) megabájtos memóriaigényű session-ökről is esett szó. Ezek szerint nem csak én találkoztam már a problémával.
  • Valaki sikeresen futtatja a Liferay-t Appengine-en, pedig abban elvileg RichFaces JSF implementáció van. Implementáció és verzió függő, hogy mi megy el Appengine-en.
  • A GWT támogatottsága nagyon jó Appengine-en belül. Ez talán nem véletlen.
  • A JDO egész gyorsan működik. (Az én kétcentesem az volt, hogy a JPA viszont lassú és senki ne használja.)
  • Datastore műveletekre is vannak callback-ek, ez nekem új volt. Kérdés, hogy ha admin konzolból módosítok perzisztens adatokat, akkor is meghívódnak-e ezek a callback-ek. Hasznos lenne.
  • Szóba került, hogy nem lehet szálakat, JNDI-t és EJB-t használni. Én ezt úgy pontosítanám, hogy nem kell.
  • Spring OK, de lehetőleg AOP nélkül.
  • JBoss SEAM: Inkább ne.
  • A cache-elésről elég sok szó esett. A pricing modell miatt központi szerepe van ennek a funkciónak, mivel ez ingyen van és ki lehet vele váltani fizetős szolgáltatásokat. Elvileg minél több dolgot cache-ből kellene kiszolgálni. Amit nem tudtam, hogy a cache-re is van aszinkron API és nemrég jelent meg az admin konzolon egy egészen használható memcache menüpont, amiben például kutakodni tudunk a cache-ben, vagy üríteni a tartalmát.
  • A HTTP kérések kiszolgálása szerlvetekben alapból szerializáltan, egymás után történik. Explicite kérni kell a konkurrens kiszolgálást, azaz meg kell adni valamit a konfigban. A szerializált kiszolgálás olcsóbb, de hosszabb a válaszidő. A konkurrens kiszolgálás drágább, mert ki kell fizetni az új példányok indulási és leállási overhead-jét. Erre figyeljetek.

Kicsivel több mint tizen voltunk, de sokkal többen nem is fértünk volna be a terembe. (Bár ha jól emlékszem van nagyobb terem is ott.) Nem tudom honnan volt meg Kelly-éknek az emailcímem, mindenesetre szerencse hogy megvolt nekik, és hogy nem jelölte be a levelezőm spam-nek a meghívót. Köszönet a szervezésért!

Update 2012.05.06: Itt van a hivatalos beszámoló a Kelly IT resources-nél, és némi képanyag.

Szólj hozzá!

Címkék: konf appengine

33rd degree 2012

2012.04.19. 13:33 tvk

Pontosan egy hónapja került megrendezésre Krakkóban a 33rd degree Java konferencia, amit idén sajnos kénytelen voltam kihagyni. Viszont követtem az eseményeket a neten, úgyhogy íme egy kis összegzés:

Venkat előadásan minden esetben teltház volt, már a kezdés előtt negyed órával is. Néhány aranyköpés tőle, a dőlt betűs részek az én hozzáfűzött gondolataim:

  • If you can't split it - you can't scale it
  • They fixed Java. And they named the fixed Java Scala.
  • Never argue with Java compiler! Ezt persze ki lehet terjeszteni az egész számítógépre, mindenesetre nagyon élvezetes hallgatni, amikor valaki ököllel üti mellettem a billentyűzetet és szitkozódik, hogy "dehát ennek működnie KÉNE". Esetleg hozzáteszi, hogy a java (vagy az éppen használt tetszőleges programozási nyelv) szar.
  • RDD -> resume driven design Ő azt hiszem úgy értette, hogy olyan komponenseket használnak a szoftverben, ami a CV-ben is jól fognak mutatni. De a másik irányba is van értelme, hogy olyan komponenseket használnak, amik szerepelnek a fejlesztők CV-jében - tehát amiket eleve ismernek. Tehát sosem próbálnak ki új dolgokat.
  • Half of the audience uses Eclipse. How many will still use it when asked to pay for? NONE! Ha fizetni kéne, valóban lehet hogy én is inkább az IDEA-ért fizetnék, bár a franc tudja.
  • Standardization before innovation is a bad idea
  • It's often easier to build good solutions with right people than with cheap people
  • Scala is an ocean and you have to learn how to swim in it.
  • Java gonna have closures between Java 8 and Java 23
  • programming in java concurrency is like working with mother in law. It's just waiting for you to fail
  • Singleton is a pattern that takes 5 minutes to learn and 6 months to get it right
  • if you turn up the volume you hear a compiler laugh "Really???...."
  • Magic in scala is okay but static import in java is not?
  • Valahol szóba került a Kotlin, Jetbrains-ék által kitalált nyelv. Hát, hajrá nekik.

Szólj hozzá!

Címkék: java konf scala

Appengine: startidő, memória

2012.03.14. 13:41 tvk

Az appengine alkalmazás fejlesztésének és üzemeltetésének van egy elég egyszerű szabálya: maradj minél távolabb a kvóta limitektől. De a kvóta limitek mellett létezik még néhány íratlan szabály, amire nem árt figyelni. Vannak a felhőszolgáltatás jellegéből adódó tévhitek, amik közül most kettőt kivesézek.

"Végtelen sok memória van." Ez egyrészt nem igaz, mert jól meghatározott keret áll az alkalmazások rendelkezésére. Ha egy alkalmazás belerúg egy nagyot a memóriaplafonba és a GC futtatás nem szabadít fel elég memóriát, akkor egy jóval drasztikusabb szemétgyűjtő módszer kerül bevetésre: leáll az alkalmazás. Másrészt a java elég hatékonyan tudja elhasználni a szabad memóriát, főleg ha az összes menő keretrendszert beletesszük a szoftverbe és nem figyelünk rá hogy milyen adatokat hogyan tárolunk. Az appengine ebből a szempontból nem úgy viselkedik mint egy átlagos webszerver. Nem kezd el vergődeni, hanem simán kinyírja a szervletet ha valami gond van. Ha rosszul van felépítve a kérés kiszolgálás, akkor minden egyes alkalommal kinyírja, mellesleg ez már nem is elhanyagolható összegbe kerül, ha esetleg a kvóta limitek fölött vagyunk.

Szólj hozzá!

Címkék: appengine

Bp. Newtech Meetup 5. Szülinap

2012.02.21. 08:56 tvk

Múlt héten került megrendezésre a Budapest Newtech Meetup szülinapi partija a Toldi moziban. Már délután kettőtől elkezdődött egy rendezvény, ahol a Mobilitás és Multimédia Klaszter tagjainak fejlesztéseit lehetett kipróbálgatni. Erre sajnos nem tudtam időt szakítani, de az index-en megjelent egy cikk róla.

Szólj hozzá!

Címkék: konf

Appengine Datastore Writes

2012.02.16. 06:39 tvk

Ismét a Google Appengine kvótáival kapcsolatban ragadok billentyűzetet. A Datastore Writes-ról fogok írni, ami némi gondot okozott nekem az utóbbi időben. A Datastore Writes egy mérőszám, ami azt jelzi hogy a GAE alkalmazás mennyi adatbázis írás műveletet végzett a nap kezdete óta. Az első 50 ezer művelet ingyen van, efölött pedig 1 millió művelet kerül 1 dollárba. Ez egyáltalán nem nagy összeg, de azért érdemes figyelni rá. Először is nem árt tudni, tulajdonképpen mi számít egy adatbázis írásnak.

Egy entitás perzisztálása legalább egy darab művelet. Az entitás property-jeire a GAE automatikusan indexeket tesz (kivéve a Text és Blob típusúakat), amik arra kellenek, hogy filterezett vagy növekvő illetve csökkenő rendezett lekérdezéseket lehessen rájuk csinálni. Ez property-nként két indexet jelent, egyben plusz két írási műveletet. Ha összetett lekérdezéseket akarunk alkalmazni az adott entitásokra, akkor saját kompozit indexeket is el kell helyeznünk, amik szintén növelik az írási műveletek számát. Ha kihasználjuk a GAE datastore azon tulajdonságát, hogy egy property-nek több értéket is adunk, akkor találkozhatunk a robbanó indexekkel is. Extrém esetben el lehet érni az egy entitásra rakható indexek maximális értékét is (5000). Itt van egy táblázat arról, hogy az entitások módosítása és a törlése során hogyan számolódnak az adatbázis írás műveletek. Node hogyan lehet ezt optimalizálni?

2 komment

Címkék: java appengine datastore

Google Spreadsheets

2012.01.10. 23:44 tvk

Ha van Google Account-od és nem csak levelezésre használod, akkor valószínűleg találkoztál már a Google Docs-csal, azon belül is a Spreadsheet-ekkel. Az is lehet, hogy szöveges és számértékek táblázatba írásán kívül szükséged volt egyéb okosságokra is, például mindenféle függvények alkalmazására vagy grafikonok rajzolására, esetleg közvéleménykutató formok készítésére. De ezek még csak a kevésbé izgalmas dolgok.

1 komment

Címkék: google javascript java

Kávéfőző

2011.12.08. 15:28 tvk

Csak egy rövid kis sztori.

Pár éve volt egy meló, ami során egy harmadik fél által fejlesztett, több éve élesben működő szoftverben kellett néhány változtatást megejtenünk. Ehhez először is fel kellett derítenünk a releváns kódrészeket és meg kellett értenünk a működésüket.

Rövidesen találtunk egy tiszteletet parancsoló méretű -több ezer soros- forrásfájlot, amibe mindenféle dolog bele volt zsúfolva. Onnan kezdve, hogy egy SAX parszer handler osztálya volt (amibe eleve nem szerencsés túl sok logikát belepakolni), akadt benne validáció, lokalizáció, adatbázis kezelés és munkafolyamat vezérlés. Szóval csúnyán megszegte az SRP-t.

"És még kávét is főz." - jegyezte meg valaki.

Sajnos elég gyakran kellett módosítanunk benne. Elég sok gond volt vele, sok szó esett róla a projekt folyamán. Egy idő után már csak egyszerűen "kávéfőzőnek" neveztük.

Nektek van kávéfőzőtök?

1 komment

Címkék: antipattern

Frontend Hours

2011.11.13. 07:50 tvk

Nov 7.-én ment élesbe a Google Appengine új árazási modellje. Már jó előre bejelentették a dolgot, de mivel azt ígérték, hogy aki eddig az ingyenes tartományban volt kvótahasználatilag, annak valószínűleg ezután sem kell fizetnie, nem fordítottam rá nagy figyelmet. Aztán az élesítés napján ránéztem a kvótáimra és megrökönyödve láttam, hogy ahol eddig 1-2%-os mocorgás volt, ott most a 80%-ot nyaldossa a grafika. Egész pontosan a "Frontend Hours" és a "Datastore reads" volt a két kritikus tényező, aminek az okát rögtön meg is értettem:

1. Nem használtam cache-elést, mert alacsony terheléshez minek. Na ezt most pótolnom kell a közeljövőben. Gyorsan utánanéztem, szerencsére elég egyszerű lesz beépíteni, ezzel nem lesz gond. Kb. úgy lehet cache-be tenni adatokat, mintha Map-be tenném, illetve hasonlóan lehet kiszedni is. Pár finomság azért biztosan elő fog kerülni pl. azzal kapcsolatban, hogy nem egy globális cache-re lesz szükségem, hanem több különállóra, amit esetleg egyenként tudok törölni, invalidálni. Elvileg van erre lehetőség appengine-ben.

2. Volt egy percenként induló cron task-om, ami szintén a datastore-ból kérdezgetett, külső URL-eket fetchelgetett és visszaírogatott a datastore-ba, de mellesleg arra is jó volt, hogy a szervlet leállítását meggátolja és így viszonylag jó válaszidőket tudjon produkálni az alkalmazásom. Na ezt most úgy ahogy van le kellett kapcsolnom, mert zabálja a "Frontend Hours"-ot. A cache-elést itt is alkalmazni fogom majd, de a külső URL-eket továbbra is jó lenne minél gyakrabban fetch-elni. Nem tudom még hogy mi lesz a megoldás, de jó lenne ha minél kevesebbet kellene programoznom hozzá és nem kéne széttörnöm a családi malacperselyt a fenntartási költségéhez.

Szólj hozzá!

Címkék: appengine

Spring Security

2011.10.27. 06:08 tvk

In the recent days, I had to get acquainted with Spring Security, which is a security framework for Java (Web) applications, based on the popular Spring framework. Instead of wading through the docs, I chose to pick and watch a screencast. I've found this one on InfoQ with a lot of well understandable examples and code. It had been recorded at SpringOne 2GX Chicago 2010, October 22. I found myself relistening parts of the screencast again and again, so I decided to write a "table of content" about it with timepoints. It may be useful for others so I post it here. (Well, SpringOne 2GX 2011 is held just now.)

From InfoQ: "Mike Wiesner is a Senior Consultant with SpringSource and has 10+ years experience in Java enterprise development and consulting. He is a committer of the Spring Security Framework and the creator of the Spring Security Kerberos Extension. He regularly speaks at various conferences and publishes work around Application Security and Spring."

Szólj hozzá!

Címkék: java security webapp

Google Dart

2011.10.11. 20:48 tvk

Íme egy tömör összefoglaló a Google új webes programozási nyelvéről a Dart-ról, a langspec alapján. A weblapon vannak fenn interaktívan szerkeszthető példák, amik egyelőre úgy futnak, hogy először Javascript-re fordulnak. De a távlati cél hogy bájtkódra forduljanak, gyorsan induljon az alkalmazás, stb.

Szólj hozzá! · 1 trackback

Bp Newtech Meetup 55

2011.09.08. 12:39 tvk

Lefirkantom a tegnapi Bp Newtech Meetup eseményeit: 18:50-kor érkeztem az ImprÓ-hoz és csinos kis kígyózó sor fogadott a bejáratnál. A pincében vásároltam egy söröt, aztán befészkeltem magam az előadóterembe, ami igencsak tele volt.

Szólj hozzá!

Címkék: startup konf

Google App Engine tapasztalatok

2011.08.15. 12:20 tvk

Egy éve fejlesztek egy alkalmazást Google App Engine platformon, úgyhogy itt az ideje felvésni egy-két tapasztalatot róla. Röviden: az appengine egy webalkalmazások futtatására alkalmas, némileg ingyenes, felhő alapú platform. Egy Google Account-tal és egy telefonszámmal bárki szerezhet appengine account-ot, amivel lehetősége van max 10 webalkalmazás egyidejű üzemeltetésére. Bizonyos kvótákat kell betartani, vagy gondoskodni a kvótatúllépések viszonylag barátságos díjának befizetéséről. Java-ban, Python-ban vagy Go-ban lehet fejleszteni a platformra, miközben komolyan kell venni néhány olyan szabályt, amit bármelyik más platformra való fejlesztésnél komolyan kellene venni, elvileg.

3 komment

Címkék: java appengine