Nem Java, de mégis java static site generáló - avagy Nanoc Java-ban

Szóval static site generaló alkalmazást keresek. Pontosabban olyat, ami Java alatt is működik és elég rugalmas az igényeimhez. És megtaláltam.

Mint korábban is említettem, különféle okokból, de csak Java alapú megoldás jöhetett számításba (leginkább telepítési/futtatási korlátoltságom van).

Amilyen sok megoldás van Python vagy Ruby nyelven, hogy az a csodálatos, hogy mennyire nincs Java alapú megoldás.

Vannak régi site generáló megoldások (akár a Maven beépített megoldását is nézhetjük), de annyira fapadosak, hogy az dolgozzon velük, akinek két anyja van.

Találtam egyetlen egy Groovy alapú megoldást, de az valami elképesztően kezdetleges volt.

Én saját magam is elkezdtem egy csökevényt QSiteGen néven. De ez inkább azt bizonyítaná, hogy egy cél-implementációt milyen egyszerűen meg lehetne valósítani. (Lehet, hogy ez az ok, miért is nincs Java-ban egy kiforrott projekt erre.)

Jóval fejlettebb a Scala-ban implementált Monkeyman. Teljesen használható a 0.4-es verziója. De még vannak gyermekbetegségei. Például egy kicsit korábbi verziójában még alap UTF-8 kódolási gondok voltak.

Persze voltak a blog-generálók is. A blog generáló az a jószág, ami egy általános static site generáló egy specializált funkcióját képviselik. Természetes limitációjuk, hogy blog készítésére vannak kihegyezve. De ha nem blogra van szükséged….

A szigorúan vett Java megoldások ezzel véget is értek.

De mint említettem az igazi nagyágyúk scripting nyelvek alatt érhetőek el. És hát van nekünk olyan, hogy JRuby. Igaz, hogy a futtató környezetet telepíteni vagy akár csak letölteni nem tudok kis otthoni barkácsolással van megoldás. Lássuk hogy megy ez nanoc-val.

1. Tölts le a JRuby complete.jar kiadását (jelenleg jruby-complete-1.7.4.jar). Ez egyetlen egy darab jar, ami tartalmazza a teljesen Ruby interpretert és alap library-t.
2. Másold le mint jruby-complete.jar (hidd el, párszor meg fogod ismételni, mire elkészíted a saját verziódat).
3. A trükk az, hogy ezzel a disztribúcióval bármit tudsz csinálni. Fogod magad és letöltöd a neked tetsző gem-eket és élvezed. Persze vannak korlátok, hiszen a C kiterjesztéssel működő gem-ek nem fognak simán működni, de a tisztán Ruby-ban implementált gem-ekkel nem szabad, hogy gond legyen. (Egyébként jelenleg ez a leggyorsabb Ruby implementáció, ha a start-up időt nem számítjuk.)
4. töltsd le a szükséges gem-eket, nanoc és függőségeit: (pl.: kramdown) java -jar jruby-complete.jar -S gem install -i ./nanoc-gems nanoc kramdown
5. Updateld a JRuby jar filet: jar uf jruby-complete.jar -C nanoc-gems/ .
6. kezd el használni a nanoc-ot (honlapról vett példa): java -jar jruby-complete.jar nanoc create-site tutorial stb…

Szerintem minimum szükséges gem-ek listája:

• nanoc
• adsf
• builder
• colored
• kramdown
• nokogiri

De ezzel még nincs vége, mert nanoc-ot feltehetőleg amerikai csinálta, mert minden input esetében az operációs rendszer karakterkódolását használja. (21. század! Érted?) De ott van nanoc.yaml, amiben kis módosítással megkaphatjuk a hőn áhított magyar ékezeteket. (FONTOS: figyelj oda, hogy spacekkel vagy tab-val dolgozol, mert érzékeny rá. Notepad++-ban kapcsold be a rejtett karakterek megjelenését!) És állíts be az enkódingot (1 sor a megfelelő helyre, meg fogod találni)

type: filesystem_unified
# ez az új sor
encoding: utf-8

És már dolgozhatsz is az egyik legszuperebb static site generálóval.

Ha kíváncsi vagy, hogyan is generálom ezt a site-ot, akkor kezdj el böngészni a Github-on

---

Két önéletrajz kell!

Mindenhol azt javasolják, hogy a megpályázott pozíciónak megfelelő önéletrajzot adjál be. Miért nem teszi ezt mégsem egy átlagos munkakereső? Miért csodálkozik, ha nem az elvárásai szerint folyik az álláskeresés?

Vezetői életszakaszom során (most külföldön építem újra magam :) ) több száz önéletrajzzal találkoztam és rengeteg állásinterjút vezettem le. De mikor nekem kellett munkát keresnem Luxembourgban azt azzal kezdtem, hogy elolvastam egy könyvet a témáról (101 Great Resumes)

Maga a könyv persze nem ültethető át az én napi gyakorlatomba. Ki kellett mazsoláznom az én helyzetemnek és országomnak megfelelő tanácsokat.

A legfontosabb tanács az volt, hogy legyen több változata az önéletrajzodnak. Attól függően, hogy mit pályázol meg mást és mást kell kihangsúlyoznod. De nem csak a pozíció, hanem a saját tapasztalataid miatt is.

Magyarországon vezetőként dolgoztam. A saját magam elő tűzött karriercélt elértem. Aztán jött az új ország. Minden vezetői álláshirdetés után kb. 15 perccel kaptam hívásokat. Franciául akkor semennyire sem beszéltem (most sem tárgyalóképes még), emiatt hamar kiábrándultak és elköszöntek. De ennek a hátrányomnak tudatában voltam és tudatosan kerestem “csak” szoftverfejlesztői munkát is.

Ezzel el is értünk oda, hogy miért fontos a többszörös önéletrajz. Képzeld el, mikor az önéletrajzodban több évnyi menedzseri, vezetői tapasztalattal és látványos beosztások figyelnek. Büszke vagy az eredményeidre. (De csakis az igazság. Számos önéletrajzot láttam vezetői tapasztalattal teletűzdelve, de mikor rákérdeztem kiderült, hogy csak annyi történt, hogy a kutya se nézet az illetőre, emiatt mindent nekik kellett egyedül megcsinálnia). DE!

Az írott kommunikáció alapszabálya: Az olvasónak írjál, ne saját magadnak!

Mit is látszik az ilyen önéletrajzból: egy ember aki vezető volt. Feltehetően (assumption) itt is vezető akar lenni. De ha Te, tudatosan, egy alacsonyabb pozíciót pályáztál meg?

Én emiatt csináltam két önéletrajzot. Egz olyat, amiben a vezetői, menedzseri eredményeimet emeltem ki és egy másikat, amiben a technikai, technológiai és architect képességeimet hangsúlyoztam. Természetesen nagy az átfedés a kettő között. Nem hallgatok el semmit sem. Igazából mindkettő teljes egész (persze lehetséges, hogy nem sikerült elég hangsúlyosság tennem a különbséget - de a koncepció akkor is áll).

Summa: Legyen több variációd az önéletrajzodból

• minden megpályázott beosztásra
• technikai, technológiai variációra és
• iparágra

---

Miért halott a bookmarkolás

Miért halott a bookmarkolás vagy magyar nevén weboldalak könyvjelzőzése? Mert az Internet nagyon messze van attól, hogy stabil legyen.

Eredetileg azt kezdtem el írni, hogy miért is vezess blogot. De nem is igazán a blogolás körül jártak a gondolataim. Hiszen, mikor első alkalommal elkezdtem blogot írni, sokkal inkább a saját gyűjtéseim rendszerezéséről szólt, semmint arról, hogy ezt valaki érdemben olvasni fogja. És azóta sem nagyon változott. A célom, hogy saját magam rendszerezzem. És mellékesen nyilvános is, hagy okuljanak tapasztalataimból mások is.

Az adatok gyűjtése nekem is (mint sokan másoknak is) a könyvjelzők gyűjtésével kezdődött. Mi sem egyszerűbb, mint megnyomni egy gombot és már meg is marad a link. Hamar kiderült, hogy rendszerezés nélkül nem nagyon használható. Ráadásul elenyésző extra információ mentődik le, hogy később hatékonyan vissza lehessen keresni. Másik ok, hogy többlaki életet éltem. Nem csak egyetlen számítógép volt, amit rendszeresen használtam. (És akkor még nem létezett felhő alapú backup)

Hamar megtaláltam az online bookmarking szolgáltatásokat és nagyon sokáig aktív Delicious felhasználó voltam. Teljesen elégedett voltam. Szinte automatikusan tudtam gyűjteni a linkeket és automatikusan szedett egy kis kivonatot az oldalról, ami nagyban segítette a későbbi keresést is. És persze online volta is elképesztően hasznos volt. Igazából egy baja volt: eltűntek a linkek mögül az oldalak.

Most (kis ugrás) migráltam az oldalamat Drupal-ról statikus lapokra és nem sajnáltam az időt és átnéztem minden lapot. És elképesztett az, hogy ugyan a legrégebbi lap 2009-es (magyarul nem is tűnik olyan réginek) mégis rengeteg olyan linket gyűjtöttem bele, amik már nem léteznek (broken, dead links). Van ahol, ugyan a forrás megmaradt, de az oldal más URL-re került. De legrosszabb, mikor teljesen és nyom nélkül szűnt meg az egész site. De ami nem is szűnt az meg, az is gyakran csak eltüntette a tartalmat (lehet, hogy jogi okokból kellett levennie), de van ahol megvolt csak még egyszer rá kellett keresni (legutálatosabb az volt, mikor ott volt az oldal, csak korábban htm kiterjesztesse, most meg html-vel - csak néztem és néztem, de nem találtam meg mi nem stimmelt, nem gondoltam a végződésre).

Erre a problémára csak egy érdemi választ van: saját magadnak kell gondoskodnod arról, hogy a számodra fontos tartalmak megmaradjanak.

Én magam a következő megoldásokkal dolgoztam:

• Evernote (és barátai): bármiről készíthetsz egy mentést. Nagyon jó böngésző pluginek vannak. Öröm használni. Hátránya az, hogy a mobil kliens (ingyenes verzió) erősen internet igényes és emiatt ok nélkül tud lassú lenni, míg a desktop kliens villámgyors.
• Wired-marker: Maga nemében egyedülálló böngésző plugin (egyetlen hátránya, hogy csak Firefox-ban működik, pedig önállóan és Chrome böngészőben is el tudnám képzelni). Használata csodálatos. Csak olvasod a lapot és ez érdekes gondolatot egyszerűen kijelölöd. Wired-marker pedig szépen lementi a kijelölést (a teljes weblapos tartalommal együtt). Majd ha később visszatérsz az oldalra a Wired-marker megint kijelöli a korábban megjelölt szekciót. (részben az Evernote Clearly is képes erre). Egyszerűen imádtam. A gépek közötti szinkronizációt saját magamnak kellett megoldanom Dropbox-on keresztűl.
• Blog: mit ahogy a saját site-omon is sok hivatkozás van más oldalakra. Kiemelve az számomra érdekes, és belinkelem az eredeti. Ha el is tűnik az eredetei, akkor is meglesz a legértékesebb gondolat (gondold csak végig, hogy egy átlagos weboldal mennyi érdemi információt tartalmaz és mennyi a helyfoglaló körítés - a 80-20-as szabály működik!)

---

Speed of EP

Hogyan pazarol az Europai Parlamant.

1. Ma beugrottak, hogy ellenőrizzék a hálózat sebességét. Mindenből ki kellett lépnem, hog yők be tudjanak jelentkezni (hiszen inaktiválva volt, hogy több felhasználó párhuzamosan tudjon dolgozni)
2. Ketten jöttek (bár az egyik nem csinált semmit sem) és szépen 5-10 perc alatt lefuttattak pár diagnosztikát. Eredmény: minden rendben. Kérdezem is, hogy tulajdonképpen miért jöttek, hiszen én nem panaszkodtam semmi ilyesmire. Előveszik a papírjukat, ami nyomtatott email oldal (noha nekem minden kommunikációt egy hasznavehetetlenül fapados weboldalon kell csinálnom), amin ott áll, hogy én, Takács Ottó panaszkodtam a sebességre (még egy dátum sem volt a papíron). És akkor beugrott. Bizony ám, panaszkodtam én, majd egy évvel ezelőtt! Azóta már új gépet is kaptam. Az új gép óta nem volt gondom, szóval nem a hálózat sebességével volt a gond, hanem a géppel magával. Összes időtartam: 2 ember X 15 perc. Plusz, amit nekem kellett, hogy újra dolgozni tudjak.
3. Mivel, akármilyen erős gépem is van (sokezer megahertz, 8 giga RAM, stb.) a bejelentkezés (és a bootolás is) sokkal lassabb, mint bármelyik otthoni gépemen, noha azok jóval gyengébbek. Az ok az, hogy mindenféle rejtélyes scripteket futtatnak. Hálózati terheltségtől függően 5-15 perc, amíg dolgozni tudok a gép bekapcsolása után. Persze hibernálni, vagy bekapcsolva hagyni nem lehet, mert este automatikusan kikapcsolják mindet.
4. Ma még emailt is kaptam, hogy van egy régi ügyem velük, ami a részükről már megoldódott (monitorcserét/dual monitor rendszert szeretnék, mert most egy régi és kicsi (20 col) van). Persze irom nekik vissza, hogy a “ticket feladása” óta (kb 4 hónap), nem történt semmi. Visszakoztak, hogy ez csak véletlen, de azt is mondták, hogy cserélni általában csak 20-nál kisebb monitorokat szokták.

Na nézzük csak, hogy milyen kiadást jelent a egy duál monitor rendszer ténylegesen.

• 2 db 23 col monitor (amazon.de) 2X132 eur = 264 eur
• tegyük fel, hogy dolgozni is kell vele, akkor legyen 400 eur
• mai napi veszteség: kb 45 perc (lásd fentebb), ami havi 20 munkanappal számolva (és becsült bérköltséget figyelembe véve): kb 20 eur

Teljesen biztos vagyok abban, hogy nem csak nálam vesztegették el ezt az időt. Ha csak a napi bootolási időveszteséget is nézem egy tartós befektetésnek tekinthető dual monitor rendszer semmit nem jelent. (sajnos a dual monitor rendszer hatékonyságnövekedését nem tudom mérni, de mások szerint akár 42% hatékonyságnövelés is lehetséges). (További linkek 1, 2, 3, 4, )

Disclaimer: Mielőtt akár csak a gyanú is felmerülne, hogy valami bizalmas adatokat adok ki, akkor azt kell mondanom, hogy minden EP project publikus, csak senki sem tudja, hogy hol lehet megtalálni. Elvégre közalkalmazottak ők is, szóval az, hogyan pazarolják a mi pénzünket az teljesen publikus.

---

Developing Backbone.js Applications

Backbone.js bekerül a toolbox-omba. Maga könyv pedig egyszerű és világos. És persze teljesen ingyenes.

Ha nem is közvetlenül fogom használni az biztos, hogy változtatni fogok az eddigi JavaScript fejlesztési módszereimen. Szóval inspirációnak sem utolsó

---

Non Fiction 2013 Q1

The mythical man-month

Újraolvasás.

Jó könyv, de megvenni nem javaslom. A könyv maga szolgáltatja a kivonatot. A 18. fejezet a korábbi fejezetek kivonatát tartalmazza. Abból lelehet vonni a tanulságot. Akkor mégis mért olyan jó, ha nem is kell az egész. Egyszerű. A példák és tapasztalatok régiek. A legtöbb esszé a 70-es években született. Akkoriban mások voltak a nagyságrendek és a legtöbb szoftver nem is volt olyan széles körben elterjedve, mint manapság a legtöbb. De a következtetések, alapigazságok nem sokat változtak.

Jó kivonatot lehet a WikipediÁn olvasni.

Peopleware productive projects and teams

Újraolvasás.

Étvágygerjesztő ajánlóban Ed Yordon azt írja, hogy ez egy olyan könyv, amit meg kell venned a főnöködnek. Ha pedig te vagy a főnök, akkor vedd meg minden beosztottadnak és a te főnöködnek is. Még az olvasás elején nagyon marketingszagú mondat volt, de így a végén már azt kell mondanom, hogy tökéletesen igaz. Olyan könyv, amit egyszer elolvasol és jó, de ettől függetlenül minden évben elő kell venned, hogy ne veszíts el a fókuszt, ne vigyenek át a sötét oldalra.

Óriás léptek

Meglepően érdektelen. Nem bírtam átvergődni rajta.

Gradle Effective Implementation Guide

Szemétre a maven-vel.

Gradle build rendszer referenciakönyve.

Sokkal jobb, mint a manapság olyan népszerű Maven.

• használja a maven repositorikat dependency kezeléshez (ez momentán a legjobb dolog, amit a Maven hozott)
• zéró konfigurációval builder projektekt. A nem triviálisokat is a pluginek segitségével.
• Groovy, mint programozási nyelv van mögötte, ha valami mégsem lenne elég.
• telepítés nélkül is működik
• sima IDE integráció
• legnagyobbak is használják (Spring Source)

Szóval: flexibilis, zéró konfiguráció és még meglévő maven repot is kezel. Nem is kell több.

JavaScript testing

Sok olyan JavaScript probléma,ami fel sem merül, ha nem plain javascriptet használsz, hanem valami frameworkot, mint pl. JQuery. Olyan technikákat ismertet debuggolásban, amik nevetségesek , ha már egyszer láttál firebug-ot vagy Chrome böngészőt.

Magyarán tényleg nagyon alapfokú és kezdőknek szól. És már a könyv felénél vagyunk.

Második felétől kezd hasznosabb és érdekesebb is lenni. Végül is egyre jobb tippeket és technikákat kapok. De még mindig nem éri meg a pénzét.

Majd van pár debugging tool bemutatása is, de max. azoknak infó, akik még nem láttam debuggert és hasonló eszközöket.

A Testing tool fejezettől vártam volna valamit, de csak 2 tool igencsak rövid bemutatására futotta.

Summa: le ne vedd a polcról, ha már csináltál webfejlesztést, és nem tök kezdő vagy informatikában.

Test-Driven JavaScript Development

Nagyon jó! Minden ami a JavaScript testing könyvből hiányzik.

Java 7 Concurrency Cookbook

Jó referenciakönyv. Receptkönyv, ami leírja hogyan használd az egyes elemeket. De sajnos ezek le vannak írva neten is. Szóval Könnyebb Google keresést csinálni, mint ezt lapozgatni.

Ami nekem hiányzott: 1. receptek feltételezték, hogy tudod pontosan mit akarsz csinálni. nekem az is kellene, hogy melyik (üzleti) esetben melyik megoldás lenne a legcélravezetőbb. 2. A hogyan teszteljünk konkurens programokat rész egy szem assert-et sem tartalmaz. Nem is nagyon értem miért van a fejezet nevében a Test.

A Java Concurrency in Practice jobb.

The ThoughtWorks Anthology 2

Kellemesen jó volt. Minden esszé jó témákat boncolgatott. Bár sokszor volt olyan érzésem, hogy csak azért szaporítja a szót, hogy több oldal legyen.

És annyira nem lehet hasznos, hiszen konkrétan semmire sem emlékszem belőle.

CoffeeScript Programming with jQuery, Rails, and Node.js

JavaScript ereje a problémái nélkül.

Egyetlen hátránya, hogy kell egy compiler, JavaScript-re fordítja. Az eredmény script meglepően olvasható. Gond nélkül kezeli bármelyik JS library-t, mivel ez csak a JavasScript-re tesz egy másik szintaxis réteget.

Ha találok Java alá egy jó kis on-the-fly fordítót, akkor élesben is használni fogom.

Domain Specific Languages

Meglepően unalmas volt.

Nem az írás stílusával vagy tartalom minőségével volt a gond, hanem magával az alaptémával.

Egyszerűen nem érdekelt annyira, hogy lekössön. Igazából csak pár External DSL parsing technikát emésztettem sokáig és az internal DSL szekciókban találtam pár érdekes gondolatot (a trivialitásokon túl).

Jó lesz arra, hogy ha kell, akkor újra elővegyem. Már tudom, hogy milyen jellegű DSL problémákra, milyen jellegű megoldások vannak.

Specification by Example

Röviden: Specifikáció és test automatizálás.

Nagyon jó koncepciót vázol fel a példákon keresztüli specifikálásról. Csupa-csupa megszívlelendő tanács. Második fele inkább foglalkozott a teszt automatizálással. előnyök, buktatók, best practice-ek.

Minden tanács megszívlelendő.

DE…

A tesztelési rész akármilyen jó. Teljesen mindegy milyen jó specifikációs tanácsokat ad. Nem elég. Felkelti a vágyat, de szinte semmi konkrét eszközt nem ad, amivel a koncepciót megvalósíthasd. Folyamatosan beszél a „Specification by example”-ről de jó ha 2-3 példát (triviálisokat) hoz fel, hogyan is néz ez ki a valóságban. Amit én szeretnék látni az egy valós életbeli példa egy nagyobbacska üzleti alkalmazásból. Egy olyan, ahol jól működik.

Magyarán nem alapmű, vagy alapvetés, hanem egy jó kis kiegészítő mű….csak még nem tudom, hogy mihez.

Akka Essentials

Igazából még nem fejeztem be.

Referencia jellegű könyv. Az Akka tényleg leveszi az ember válláról a legnehezebb és legnyűgösebb részét az elosztott rendszereknek, job-oknak.

Kicsit bővebben nem csak Akka-ról.

Seven Databases in Seven Weeks

Igazából azért olvastam el, hogy képbe kerüljek a NoSQL adatbázisokkal. Mik az előnyeik, hátrányaik, legpraktikusabb felhasználási feltételeik. És meglepő módon mindenre választ kaptam.

Summa: SQL nem halott, csak nem jó mindenre. NoSQL nem az új Silver Bullet, de a megfelelő problémára ez a megfelelő eszköz.

---

The Fourth Question in the Daily Scrum

What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this sprint?

Mert legtöbbször a fejlesztőt nem is kérdezik.

The Fourth Question in the Daily Scrum / Standup - Mitch Lacey & Associates - Scrum and Agile Training

---

Miért nincs jó static site generaló és jó web alapú help rendszer.

Mi az a két dolog, ami nagyon hiányzik a Java ecosystemből? Egy jó static site generator és a egy jó web help rendszer. (Végig free vagy open source megoldásokról beszélek)

Mire nem jó a Word és barátai?

Mire nem jó a Word és barátai (Excel, PDF, stb.). Lehet vele szép leveleket és nagyszerű táblázatokat készíteni. Élvezem is. De amire egyáltalán nem alkalmas az a bármilyen szoftverrel kapcsolatos dokumentáció.

Minden ami szoftverrel kapcsolatos, így a dokumentáció is olyan, mint annak alapja, hogy verziózott legyen. Tipikusan többen dolgoznak rajta és követni kell a változásokat. Aki már dolgozott olyan dokumentummal, aminek mindenféle verziója létezett párhuzamosa (tipikusan a file nevében jelölve, hogy mennyire friss) és némelyik módosítás során az új verziót kell a régebbivel összehasonlítani, más esetben meg változáskövetéssel bekacsolt Word dokumentummal kell égetni a szemed, akkor tudod, hogy miért fontos.

Másik a kereshetőség. Még a legnagyobb és legfejlettebb IT céges környezetben is dominál az egyszerű megosztott könyvtár, amit minden érintett elér. Egyszerűnek tűnik, hisz ha kell valami, akkor ott meg fogod találni.

De mégis mennyi dokumentum után válik hasznavehetetlenné? 10? 100? 1000?

És egy bináris Word vagy Excel file-ban nem olyan triviális keresni, ha nem a “kedvenc” szövegszerkesztődet használod. Vegyél kb. 1000 Word dokumentumot (legyünk optimisták és mindegyiknek csak a legfrissebb verziója van jelen) és próbáld benne keresni a téged érdeklő dolgokat. Filerendszer alapú keresés (pl. totalcmd) használhatatlan, hiszen bináris állományokról van szó. Egyenként megnyitni több száz Word dokumentumot az meg kész rémálom. (régen volt google desktop, ami nagyon jó volt erre a problémára)

Mindkettőre megoldás lenne egy rendesen használható document management renszer. De mint említettem még a legnagyobb IT cégek sem használják.

Mi legyen Word helyett?

Mi legyen Word helyett? Semmi különleges. Csak sima txt file és semmi több. Könnyen verziózható, könnyen követhető a változása, könnyen kereshető.

Jöhetne a kérdés: “és mi van sablonjaimmal és formanyomtatványaimmal, meg a _módszertan szerinti dokumentumokkal?_”

Ha csak egy kicsit is strukturált szöveggel dolgozol (Markdown vagy valami wiki dialektus), akkor könnyedén tudsz generálni akármilyen dokumentumot.

A kedvenc módszered sablonjaira meg az a válaszom: Egyetlen egy módszertan sem követeli meg pontosan azt a Word sablont. Amit azok megkövetelnek, az a TARTALOM!

De miért nincs egy jó static site generáló?

És el is értünk egyik problémámhoz: generáljuk ki azokat a szükséges dokumentumokat a megfelelő formátumba. Szerintem egy sima HTML kimenet az esetek jelentős többségében több, mint elegendő.

De akkor miért nem inkább egyből Wiki-be? Hiszen arra is igaz minden, amit fentebb leírtam.

A szoftver dokumentáció a szoftver része. Pontosabban egy adott dokumentáció halmaz egy adott verziójú szoftverrendszerhez tartozik. Magyarán életciklusok nem szétválasztható. És egy wiki-vel nem tudod megvalósítani ezt az életciklus kötést, hiszen egy teljesen különálló rendszerben (adatbázis) dolgozik. Vannak persze filerendszer alapú wiki implementációk is, de Java-ban nagyon kevés létezik és az is gyatra (alapigény lenne, hogy ne egy könyvtárba hordja össze struktúra nélkül, hanem valami könyvtárszerkezet alapú hierarchiával is tudjon boldogulni). (Egyébként a VQWiki áll legközelebb az én személyes igényeimhez)

Rengeteg static site generáló van. Sajnos a legjobbak, legfejlettebbek mind vagy Ruby vagy Python nyelven íródtak és szükséges a saját futtató környezetük. Én meg olyan környezetben dolgozom (EP), ahol ez nem megoldható. Java alapú megoldások közül szinte egyik sem érdemli meg a “használható” jelzőt. Bővebb értelemben vett Java megoldások közül a Monkeyman (Scala) a legjobb. Mivel a bővítéséhez (pl saját formátumú PDF) már kell a Scala, itt is korlátokba ütköztem.

Marad az a megoldás, hogy saját magam készítek valami használhatót. Nagyon prototípus kezdemény szinten már működik is a QSiteGen. Használható, de még messze van a boldogság.

És miért nincs rendes help rendszer?

A help egy speciális szoftver dokumentáció.

Mit értek az alatt, hogy help rendszer? Pontosan azt, amit. Csak nyisd meg bármelyik help-et és látod.

Kell bele:

• tartalom
• beépített kereshetőség (ebben tér el a korábban leírt dokumentációtól)

Semmi más. Például a hierarchikus rendszer tulajdonképpen tudna jönni a tartalomból. Más kérdés, hogy tipikusan egy extra konfigurációs lépést igényel. Magyarán igen nehézkes.

Nekem egyébként is egy webes alapú help rendszer kell (hiszen webalkalmazásokat fejlesztek). Döbbenetes, hogy a Java mennyire szegényes az alternatívákban. És ami van, az is az igen nehézkesen használható. (A könnyen használható rendszer az, aminek ha elolvasom egy tutorialját, akkor max. 30 percen belül egy használható végeredményt kapok, anélkül hogy mindenféle manuális varázslatot hajtanék végre.)

A legtöbb help rendszer valami miatt igényli, hogy tartalmon kívül még mindenféle extra konfigurációs állományokat is készítsél. Persze lehet automatizálni, de akkor miért nincs már alapból megoldani?

Egyébként is amire igazán szükség van az nem konfigurációból kinyert hierarchikus oldalszerkezet, hanem a kereshetőség. Hiszen alapszabály: keresés gyorsabb, mint a navigálás.

Mit is tud egy ideális help rendszer

1. Filerendszerből dolgozik
2. Automatikusan konvertál a megfelelő formátumba
3. Beépített kereső

Az 1. és 2. pont egy static site generáló is tudja. A 3. pontot pedig egy indexelő szolgáltatás. Ha a help oldal publikus lenne, akkor A Google is elég volna. De egy intranet megoldásnál már nehézkesebbek. Ha teljes szabadságod van a környezet konfigurációjában, akkor Solr vagy még inkább nutch

A legszörnyűbb, hogy PHP és más számomra elérhetetlen (mert EP) implementációk tudják ezt. De Java-hoz nem találtam.

Mese nincs: ez is rám vár.

És az egészben az a legszörnyűbb, hogy alapvetően nagyon egyszerű dolgokról van szó. Emiatt meglepő, hogy miért hiányzik.

---

From checked Exception to code generation

Mi is ez? Nyavajgás és picsogás mennyire fárasztó a Java, ha már ismersz más koncepciókat is

Többféle vélemény van arról, hogy miként kell kivételeket (polgári néven Exception) kezelni. Java-ban két fő kivétel van:

• amit kezelni kell
• amit nem kell kezelni

Mikor azt írom nem kell kezelni nem azt jelenti, hogy hagyjuk figyelmen kívül. Csupán arról van szó, hogy Java-ban nem jól van kezelve. Pontosabban alap Java API nem kezeli jól.

Bárhová tévedsz checked exceptionökbe futsz bele. Nem tudod kikerülni. Még azokban az esetekben is, amikor API szinten lehetőséged van arra, hogy kivételkezelés nélkül is teljesen szabályos kódot tudj írni.

Iskolapélda a filekezelés. Alap, hogy file művelet előtt ellenőrzöd létezik-e, írható, olvasható-e (stb) a file. Ha mindent le tudsz ellenőrizni, akkor felteszem nem akarsz minden áron FileNotFoundException-t kezelni. Teljesen elégedett lennék azzal, ha ez csak simán RuntimeException lenne. Jöjjön csak a nagy Exception, de kelljen minden áron lekezelnem. Főleg, ha nem is tudok vele mit kezdeni.

És itt a másik indok. A dobálódzó kivételek jelentős részét nem lehet értelmesen lekezelni. Azon kívül, hogy a felhasználót/programozót értesítem a lehetőségről, semmi mást nem tudok tenni. Semmit (az esetek 90%-ban)!

Nagyos sok és jó érvet lehet találni a neten. De nekem leginkább a Spring adja a referenciát. Mivel a Spring az egyik legjobban kitalált szoftvercsomag és nem kényszerít minden áron a kivételkezelésre, hanem hagyja, hogy az intelligenciád döntsön felőle, elegendő bizonyítékot kell szolgáltatnia bárkinek.

De azért vannak még vélemények:

• The Problem With Checked Exceptions
• " I would go as far as 98% of catch blocks are meaningless"
• Failure and Exceptions
• Does Java need Checked Exceptions?
• Java's checked exceptions were a mistake

Nem Springet használ az ember. Mindenkinek megvan a maga kedvenc utility library-je. De abban biztos vagyok, hogy Jakarta Commons család sokak kedvence. De általános betegsége, hogy nem foglalkozik a kivételekkel. Hanem simán továbbdelegálja a hívó programegységnek, azaz nekünk. És már kezdhetjük is írni a try-catch blokkokat és throws deklarációkat.

Az évek során rendszeres rutinommá vált, hogy használt commons utilokhoz wrapper osztályokat írok, amik csak delegálják a hívást és bármilyen exception is jön szépen becsomagolják egy RuntimeException-be. Végül is csak egyszer kell csinálni.

Egyszer? Sajnos nem. Céget és országot is váltottam. Több párhuzamos egymástól független projektben is részt vettem. És minden esetben újra kellett implementálnom ugyan azt. Nem nehéz, de már meguntam. Nosza generáljuk ki.

De nem olyan egyszerű. Van amiben az Eclipse elég sok segítséget tudott nyújtani, de még mindig macera volt.

Nosza írjunk egy scriptet, ami szépen elvégzi a generálást. Maga a generálás nem is nehéz. Ami gond az Java forrás feldolgozása. Kis kutakodással találtam pár parsert és a javaparser elég egyszerű volt ahhoz, hogy fel is használjam.

(Groovy)

Map convertables = ["eu.qualityontime.commons.io": [
    /r:\environment\docs\commons-io-2.1\src\main\java\org\apache\commons\io\CopyUtils.java/,
    //... additional files
  ], 
  "eu.qualityontime.commons.io.filefilter":[
    /r:\environment\docs\commons-io-2.1\src\main\java\org\apache\commons\io\filefilter\FileFilterUtils.java/
    ]]

File targetDir = new File(/r:\TEMP\target/)
targetDir.mkdirs()

convertables.each{String packageName, List<String> files ->
  File packageDir = new File(targetDir,packageName.replaceAll('\\.', "/"))
  packageDir.mkdirs()
  files.each{ filename ->
    println filename
    FileInputStream inp = openInputStream(new File(separatorsToSystem(filename)))
    CompilationUnit cu = JavaParser.parse(inp)
    StringBuilderWriter sbw = new StringBuilderWriter()
    PrintWriter w = new PrintWriter(sbw)
    StaticDelegateGeneratorVisitor v = new StaticDelegateGeneratorVisitor(packageName:packageName, print:w)
    v.visit(cu, null)
    println v.typeName
    File outFile= new File(packageDir, v.typeName+".java")
    outFile.createNewFile()
    FileUtils.write(outFile, sbw.toString())
  }
}

Maga a generátor sem túl bonyolult:

class StaticDelegateGeneratorVisitor  extends VoidVisitorAdapter{
  String packageName
  PrintWriter print
  String delegeName
  PackageDeclaration importablePackage

  String getTypeName(){
    "QoT${delegeName}"
  }

  @Override
  public void visit(CompilationUnit n, Object arg) {
    print.println "package ${packageName};"
    super.visit(n, arg);
  }

  @Override
  public void visit(PackageDeclaration n, Object arg) {
    importablePackage = n
    super.visit(n, arg);
  }

  @Override
  public void visit(ClassOrInterfaceDeclaration n, Object arg) {
    delegeName = n.getName()
    print.println "import ${importablePackage.getName()}.*;"
    print.println "\npublic class ${getTypeName()}{"
    super.visit(n, arg)
    print.println "}"
  }

  @Override
  public void visit(ImportDeclaration n, Object arg) {
    print.print n
    super.visit(n, arg)
  }

  @Override
  public void visit(MethodDeclaration m, Object arg) {
    if(!ModifierSet.isStatic(m.getModifiers())||!ModifierSet.isPublic(m.getModifiers())){
      return
    }

    japa.parser.ast.type.Type type=m.getType()
    List<Parameter> parameters = m.getParameters()==null?[]:m.getParameters()
    List paramname = parameters.collect{it.id}
    boolean  voidReturn = type instanceof VoidType
    print.println "  public static ${type} ${m.getName()} (${parameters.join(', ')}){"
    print.println "    try{"
    print.println "      ${voidReturn?'':'return'} ${delegeName}.${m.getName()}(${paramname.join(', ')});"
    print.println "    }catch(Exception e){throw new RuntimeException(e);}"
    print.println"  }\n"
    super.visit(m, arg)
  }

}

Használd egészséggel!

---

Non fiction - 2012

Mi mindent olvastam szakmai szempontból 2012-ben

The productive programmer

A The Productive Programmer olyan nekem mint a Code Craft annak idején, mikor olvastam. Az járt a fejemben, hogy „miért nem találtam meg ezt a könyvet sokkal hamarabb”

Azért már öreg rókának tartom magam, hiszen több, mint tíz évnyi szoftver fejlesztési tapasztalattal rendelkezem. Sok trükköt ismerek, de nem eleget.

Elképesztően élveztem minden majd minden sorát. A tool-ok leírását. Olyan szempontokból használni egy egy fejlesztői eszközt, amiben korábban nem gondoltam volna. Újra elővettem feledésbe merült eszközüket, mikor valaha használtam, de valahogy kikopott az eszköztáramból. gyakorlatilag újratanulom azokat.

Persze negatívuma is van. Néhány konkrét példa már elavult. Egyszerűen fejlődik a világ (különösen az IT területén) és a könyv írása idején nem állt rendelkezésre minden és nem olyan fejlettségi szinten mint ahogy jelenleg megtalálhatóak. De ezeket én a kivonatomban igyekeztem korrigálni.

Informatikusi alapmű.

Code Leader

Nem igazán tetszett. Nem élvezetes a stílusa és nem is adott semmi kiemelkedőt nekem.

The ThoughtWorks Anthology

Nem is tudom, hogy mit vártam, hiszen nincs újdonság benne, csak korábban már publikált cikkek kivonatai. Lusta embere rss-read-je :). Gyakorlatilag nem volt olyan cikk, amit már ne olvastam volna korábban.

101 Great Answers to the Toughest Interview Questions

Az idei éve egyik nagy lépése volt, hogy munkát kerestem Luxembourgban. Régen volt, mikor utoljára ezzel foglalkoztam. az is igaz, hogy rengeteg embert interjúztattam, emiatt igen kialakult véleményem van, hogy miként kell kiválasztani egy jó dolgos munkásembert IT területen. De azért csak felszívtam maga, mert az, hogy én mit szeretnék nem jelenti azt, hogy a cég pontosan mi alapján válogat. És igazam is lett. De nem az én hibámból, hanem a Luxembourgi ekoszisztémából. :)

Maga a könyv egyébként nem egy nagy szám. Olyan érzésem van, hogy volt egy fejvadász cég és az egyik embere írt egy könyvet. Csak annak adott újat, aki nem volt 3-nál több interjún életében (persze most csak IT oldaldól beszélek)

Vezetői időgazdálkodás – Monkey Business

Alapelve már ismert, ha hallgattad az időforrás (http://moly.hu/konyvek/doubravszky-gyorgy-idoforras).

Adva van a majom, mint elvégezendő feladat. annak vállán pihen aki felelős érte. De át is lehet adni.

Leírja a problémát és néhány alapvető tanácsot ad.

Nagyon felelősséglerázós stílusa van a könyvnek. Nagy kedvence lesz a basáskodó főnököknek. Még ettől függetlenül is tartalmaz használható tanácsokat. Hiszen a probléma sok vezetőnek gondot okoz….

JUnit in Action

Korábbi kiadását, már régebben olvastam. Ez jelenleg a legutolsó kiadás. Kicsit felfrissítette az agyamat, hogy mik a “legújabb” toolok a tesztelésben.

97 Things Every Programmer Should Know

1. Internetes blogbejegyzések kicsit átszerkesztve
2. Rövid cikkek
3. Kevés eredeti gondolat
4. Ritkán megfogható az a lényegi és egyértelmű tanács,
5. Ahol megfogható akkor alig egyetlen A4 oldalra elfér az összes (mármint az egész könyv)

Scala for the Impatient

Az ami a Programming in Scala könyv nem. Rövid gyors. Ugyan nem teljesen részletekbe menő, de napi szinten használható hátteret ad és útmutatást ahhoz, hogyan keresd elő a részleteket.

Programming in Scala

Scala programozási nyelv referenciakönyv.Maga könyv száraz, de hát mit is várunk egy referenciakönyvtől. A nyelv nagyon jó és kellemes meglepetést okozott. Azok a dolgok vannak benne, ami kell. Egy nyelven ebből elérhetőek FP és OO paradigmák. Teljesen átjárhatóak, attól függően, hogy mi a leghatékonyabb. És 100%-os Java átjárhatóság.

Scala By Example

Nagyszerű kiegészítés a Scala for Impatient-hez.

SQL Antipatterns

Nagyon jó könyv. Rengeteg mindent tanultam belőle. Olyan problémákat írt le, amit még nem is ismertem vagy igen és saját bőrömön tapasztaltam meg, hogy milyen fájdalmas rossz irányba menni. De van ezekre praktikus megoldás. Különösen tetszettek azok a megoldások, amik (főleg Oracle SQL expertek) követnek, mert az is valami “okos”adatbázisos miatt követik. De gyakran teljesen felesleges.

Például: barom névkonvenciók. Vegyük az egységes névkonvenciót, ami a gyakorlatban arról szól, hogyan rövidíts le értelmes szavak értelmetlenekre. Lásd table PERSON és a PK legyen pers_id. ami egyszerű, de vegyük hosszabb és bonyolultabb táblaneveket és próbáld 4-_id betübe lerövidíteni.

Másik a példa, ami arról szól, hogy egyetlen dolognak egyetlen neve legyen. És sokszor látom, hogy külső kulcsok esetén duplikálnak neveket (pl Person hivatkozás pers_pers_id-ként implementált). Pedig a logikus megoldás az, hogy mindenhol ugyan azt a nevet használni, ahol ugyan azt jelenti (a példában pers_id)

Harmadik példa, a mesterséges kulcsok burjánzása akkor is, ha látványosan hülyeség, de a “best practice” azt mondja, hogy minden táblának legyen egy mesterséges kulcsa. De tényleg kell egy (pl) Language táblába még egy kulcs az egyébként egyedi ISO lang code helyett? Vagy egy 2 FK tartalmazó kapcsolótáblába egy soha többet nem használt mesterséges PK-t belepakolni?

Hibernate: A Developer’s Notebook

Új munkahely, új technológiákat kell mélyebben megismernem. Ezek egyike a Hibernate, amit korábban csak alapszinten kellett használnom. Nem voltam elragadtatva tőle, de sokan nagyon szeretik. Olyan is, akik szakmailag nagyon nagyra tartok. De megismertem és gyakoroltam is. És a következő véleményem alakult ki: egyszerű dolgokra kiváló (de arra más eszköz is ugyan ilyen jó). Közepesen bonyolult dolgoknál már szivárog az absztrakció. Mivel célja, hogy elrejtse a DB-t az átlag fejlesztő elől, akinek csak objektumokkal kell dolgozni. De kb 2 napi szinten belefutok olyan “problémába”, amik csak db szintű ismerettel és bonyolultabb hibernate buherával oldható meg. És a bonyolultabb dolgokra meg amúgy is visszaesek plain SQL szintre (Spring JDBC), hiszen sokkal egyszerűbb azzal megoldani. Összességében nem éri meg a hipe-ot.

Maga a könyv:

Gyakorlatilag egy reggel olvastam át. Pontosabban szólva átfutottam. Nem is érdemel többet.

Néhány jól megválasztott online tutorial is hozza ezt a színvonalat. És ráadásul rövidebbek is lennének.

Ráadásul igen régi is és csak XML alapú konfigurációt tárgyalja.

Lean from the Trenches

Nagyszerű könyv. Lean elvek. Agile fejlesztés. És nem az elmélet, hanem az, hogyan ténylegesen megvalósították egy állami projekten a svéd rendőrségnél.

Többszörösen is aktuális számomra, mert én is közszférában létező projekten dolgozom. Az ottani tapasztalatok és problémákat én is látom a saját szervezetemben. És ha ezek a módszerek ott beváltak, akkor itt az EU más intézményeiben is működnie kell.

Gyakorlatilag semmi elmélet. Csak a véres valóság.

http://www.qualityontime.eu/review/lean-trenches-managing-large-scale-projects-kanban-henrik-kniberg

Java Persistence with Hibernate

Kb a Hibernate referencia megfelelője. Nagyon jó könyv (mint a legtöbb In Action könyv).

jQuery Recipes: A Problem-Solution Approach

Nyers tartalmat tekintve jó. De semmi olyan,amit ne találnál meg a weben ugyan ezekre a kulcsszavakra keresve. Persze ha nem tudod, hogy mi mindent lehet jquery-vel megvalósítani, akkor elsőrangú és hasznos referenciakönyv.

Continuous Delivery

Zseniális jó. Amiről szól, az a delivery chain felépítése. Miért fontos, mire kell figyelni. Nem okosságot mond, hanem felhívja a figyelmet arra, hogy mire kell figyelni a felépítése közben. Rámutatott arra, hogy mik a buktatók. És még egy érvet kaptam arra, hogy miért gyenge a Maven :) Hiszen többek között ezeket az elveket sem támogatja. Bezzeg a Gradle :)

Az egyperces menedzser

Igazából újraolvasás. És még mindig jó :) A Helyzetfüggő vezetés (http://www.qualityontime.eu/review/helyzetfuggo-vezetes-kenneth-blanchard) előfutára. Noha én azt olvastam elsőre. Zseniálisan egyszerű és saját magamon tapasztaltam, hogy milyen hatékony.

Egyperces menedzser a gyakorlatban

Ha vezető vagy, de legalább is azzá akarsz válni, akkor olvasd el. Tudd besorolni az embereket a fejlettségi szintekbe és tudd, hogy milyen vezetési stílust kell náluk alkalmazni. A kulcs: helyzetfüggő vezetés.

Groovy in Action

Korábban Ruby-val ismerkedtem, mint dinamikus nyelv. De az Európai Parlamentben nem lehet akármit használni. De Groovy-t igen. Nosza nézzük meg.

Maga nemében nagyszerű referenciakönyv. Megkedveltem a Groovy-t.

http://www.qualityontime.eu/olvasonaplo/groovy-action

Succeeding with Agile

Nem arra való, hogy megtanuld, mi is az agile fejlesztés vagy management.

Csak akkor vedd elő, ha már van vele valami tapasztalatot.

De akkor rengeteg tapasztalatot és tanácsot kapsz, arra, hogyan küzdj meg a problémákkal bármilyen szinten jelentkezzenek is. Akár feslővezetés, akár fejlesztői szinten.

Tippek és tanácsok az legelső bevezetéstől kezdve addig, amikor már az egész cég agile elveket vallva a dolgozik.

http://www.qualityontime.eu/olvasonaplo/succeeding-agile-mike-cohn

Effective Java

Ugyan ebből senki sem fog programozni tanulni. De ha mar tud javazni, akkor tele van jó tanacsokkal.

Ha esetleg mar olvastad az első kiadást akkor nem sokat fog adni. Persze feltételezve hogy azért naprakész vagy az addig történtekkel.

Clean Code: A Handbook of Agile Software Craftsmanship

Önmagában jó, de Code Craft után semmi.

More Java Pitfalls

Régi és elavult. És gyakran triviális.

Spring Batch in Action

Funkcionálisan teljes rendszer. Nem találtam hiányzó részt. Sőt inkább olyan megoldásokat is, amikkel még nem találkoztam korábban.

Mind tutorial-nak, mind referenciának nagyon jó könyv.

Pragmatic Thinking and Learning

Alapvetően jó, de nekem nekem új dolgot nem adott.

Felépítésileg belekap nagyon sok mindenbe, de semmiben sem mélyed el igazán. Inkább tanácsokat tudsz kiszűrni belőle nem konkrétumokat.

Szorosan kapcsolódik a témához: http://moly.hu/konyvek/daniel-kahneman-thinking-fast-and-slow

Az eredményes tárgyalás

A tárgyalás tudományára minden napszükségünk van. Akár a családon belül akár az üzleti életben.

Fontos legalább az alapokkal kezdeni.

Ebben a könyvben minden lényeges lépés szerepel. Ha szisztematikusan végigmész a témákon, akkor nagyon rossz tárgyaló már nem lehetsz.

DE Sok mindenről beszél, emiatt a témákat nem fejti ki.

Ár érték arányban silány.

Nyelvhack kézikönyv

Új ország és új nyelv. Korábban csak közoktatási és egy fél évnyi nyelvsuliba járásból van nyelvtanulási tapasztalatom. Újra nekiálltam egy komoly tanulási lépésnek. Hiszen ez nem rövid, nem praktikus megszakítani és tényleg sokáig fog tartani. Noha nem kötelező, de Luxembourgban (egy köpésre Franciaországtól) gyakorlatilag szükséges.

Ha elvesszük a nyelvtanulást akkor akar a Csodalámpa c. könyv is lehetne.

De önállóan is megállja a helyet. Rengeteg hasznos tanács és módszer.

97 Things Every Project Manager Should Know

Félelmetes módon nem tudom átrágni magam rajta. Egyszerűen azért, mert annyira közhelyeket pufogtatnak (ez a legkisebb gond), rövidek a gondolatok és teljesen strukturálatlanok a cikkek.

Vedd meg a Manage It (http://moly.hu/konyvek/johanna-rothman-manage-it) és sokkal előrébb leszel, mint ezzel a könyvvel.

Hétfő reggeli döntések

Meglepően jó könyv. Egy 7 szokáshoz vagy Tracy Maximális teljesítményéhez képest nem fog újat mondani. De a méretéhez képest üdítően kiragadja a lényeget, hogyan változtasd meg az életed. Pontosabban valamit az életedben.

Sajnos inkább alapelvekre koncentrál és emiatt kevés konkrét kézzelfogható technikát fogsz benne találni,. Neked kell kitalálnod a lépéseket és módszereket vagy elkezded valamelyik fentebb említett könyvet is :)

Code Simplicity

Rövid kis könyvecske. Nem igazán számítottam sok mindenre. És részben igazam is lett. Kevés a tartalom, de az esszenciális.

Nem igazán konkrét design tanácsokat ad, hanem azokat az alapelveket vázolja, amik segíteni fognak a jó design megalkotásában.

http://www.qualityontime.eu/development/code-simplicity-max-kanat-alexander

Thinking, Fast and Slow

Az év legjobb könyve számomra.

Hangoskönyvben kaptam fülhöz. És annyira megtetszett, hogy el is kell olvasnom. Akárhogyan is nézem voltak nehézségeim a megértésben. Egyszerűen azért, mert ezekkel témákkal még nem volt dolgom angolul. Jól fog jönni a Kindle szótára :)

De miért is olvasom majd el? Mert tudatosabb és bölcsebb gondolkodó akarok lenni. Döbbenetes módon a 9/10 arányban elbuktam azokon a példákon, amiket arra hozott fel, hogy a legtöbb ember esetében a tudatalatti hogyan dönt HELYTELENÜL. Sokkot kaptam. Emiatt olvasom el újra.

És akarod tudni, hogy mi a háttere, hogy boldog legyél. mármint tudományos és pszichológiai tesztekkel bizonyítva? Akkor nosza. ez nem a new-age-es könyvek, hanem csak tudomány.

És akkor még nem is beszéltünk azokról a témákról, amik közgazdászoknak és menedzsereknek szólnak. Zseniális.

ExtGWT Rich Internet Application Cookbook

Új project indul és UI technológiát kellett választani. A kollégám ezt javasolta. Én a alap JSP-t Jquery UI-val. És ExtGWT-ba mélyedtem el, hogy felfedezzem és ő a Jquery-vel. engem ez ExtGWT nem győzött meg, de őt a Jquery igen :)

Könyv:

Probléma leírás majd a forráskód.

GUI elemekre (widget) koncentrál. Arról egy szó sincs, hogyan építs fel egy egy komplex gui alkalmazást hatékonyan.

Mesternap

Szerzőtől megszokott tartalom és minőség.

Ízlésemnek ugyan sok volt a spiritualitás és a vallás, de azt leszámítva csak ajánlani tudom. Rövid és emiatt nem kész recepteket ad, hanem felvázolja a keretet, amit te magad fogsz kitölteni, hogy jobb legyen az életed.

Six Thinking Hats

Kettős mércét kell alkalmaznom.

Sok helyről hallottam, hogy a 6 gondolkodó kalap elve mennyire jó. Nosza neki is kezdtem.

Maga a 6 gondolkodó kalap elvei nagyon jók. Sok nehézségre rávilágít. Nagyon szeretem azt a hasonlatot, ahogyan a bemutatja az elvet egy háznéző példán keresztül. Azaz képzeld el, hogy 6 ember 6 oldalról néz egy házat (négy oldal, felülről és belülről). Ha megkérdezed, hogy milyen a ház, akkor mindenki elmondja, amit lát. Mindenki mást mond. És mindenkinek igaza is lesz. ehelyett vidd mind a 6 embert magaddal és járjátok körbe a házat és nézzétek meg felülről és belülről is.

Szóval az elv nagyon jó…

DE, az elv nem ad szemernyi megoldást sem semmire. Felvázolja, a térképet,d e nem ad módszert, hogyan is jussunk ki a labirintusból. Persze azért is lehet, mert nem egy speciális kontextusban jelenik meg, hanem csak úgy, általánosan. Még keresek irodalmat ebben a témában, hogy több oldalról is lássam.

DE: a könyv túl sok a tartalomhoz képest. Igen kis vékonyka könyv, de még így sokkal több, mint a tartalom, amit magában foglal. Pár sűrű A4 oldal és már mindent megtudtál. Igazat megvallva a wikipédiás összefoglaló lefedi a könyv 80%-át. 15 százalék értéket a „példamondatok” alkotják. És még van 5% jó érték, amikor speciális kérdéseket tárgyal, hogy pl. mi a lényegi különbség két egymáshoz látszólag hasonló kalap között (pl sárga és zöld).

21 Great Ways to Manage Your Time and Double Your Productivity

Rövid, velős. De ha már olvastad a Maximális teljesítményt, akkor nem új. A lényeg, hogy hangoskönyv.

Persze a mondanivaló roppant értékes. Ha nem vagy járatos az időgazdálkodásban, és akkor egy „must have” könyv.

Designing Interfaces

Nagyon tetszett.. meglepően sok inspirációt adott. Segített érvelni a saját UI terveim mellett. Szépen ki van emelve, hogy melyik megoldást, mikor jó alkalmazni. Persze rettentő egyedi dolgokat ne várj. ha használsz számítógépet, akkor mindennel találkoztál már. De tapasztalatom szerint, ha nem érdekel az UX, akkor csak megcsinálod valahogy használhatóan és nem feltétlenül az adott kontextusban leghasználhatóbban. Na ebben segíteni fog.

A 8. szokás

Nem tetszett. A kiváló szervezetekről szól, de olyan kevés konkrétummal, hogy az valami szörnyű. Mivel Leadership tréningjén már voltam, ahol pontosan ezeket a témákat jártuk körül, bátran tudom mondani, hogy ez a könyv felkelti a vágyat arra, hogy elmenj egy ilyen tréningre.

Háztartásunk kémiája

Szigorúan véve nem szakmai, de elképesztően hasznosnak tartom. És igen és is aktívan takarítok otthon. :)

---

No previous | Next