Annotációk használatával rengeteg problémát veszünk a nyakunkba, amit a programozók nagy része nem is sejt.

Van egy nagyon jó előadás a témában, ahol az annotációk mellett az ORM, DIc, Exception-ök káros hatásai is többé kevésbé felmerülnek:
On @annotations - liberate yourselves from demons by Jarosław Ratajski

További hasznos tartalmak a témában:

Totális függvények

A függetlenség napja
avagy erős függőség, gyenge függőség vagy teljes függetlenség

Az alábbi blog bejegyzésben a program fejlesztés közben felmerülő függőségekről lesz szó, aki más témájút várt, azt sajnos el kell keserítsem. A függőségek kapcsán szó lesz még az automatikus tesztelésekről is.

A teljes blog itt olvasható.

Kezdő programozóként még nem nagyon törődtünk a függőségekkel. Nem akartuk lecserélni a függőségeket másra, nem akartuk unit tesztelni a kódunkat, nem hallottunk még a pure-impure dolgokról, és nem tudtuk, hogy a statikus függvények rosszak, valamint azt, hogy a strong/tight coupling (erős, szoros függőség) az nagyon rossz.

Továbbiakat itt találod.

A minap találkoztam ezzel az érdekes videóval.
A Chymyst nevű, nyílt forrású, deklaratív programozást nagyon egyszerűvé tévő könyvtár használata, valamint a segítségével a Chemical machine, vagy más néven Join calculus bemutatása történik.

Használata tényleg roppant egyszerű:
1. Meg kell határozni az egyes molekulákat, amik az információt is hordozzák.

Régóta tervezgettem már ezen blog megírását, de az utolsó lökést ez a bejegyzés adta meg:

én típusmentes rendszerekben (PHP4, ES3) írtam baromi nagy dolgokat, amiket mások szerint anélkül nem is lehetett volna (dehogyisnem, többmillió soros rendszereink futottak benne stabilan).

Ez a bejegyzés alapvetően igaz!

A valóságban tényleg nem sokkal jobbak a statikus típusos nyelvekben írt programok; amilyen kevéssel több munka a típusok kiírása, annyi kevéssel teljesít jobban a dokumentálás, unit teszt és a hibaszám terén.

Eric Elliott [“Programming JavaScript Applications” (O’Reilly) írója] megdöbbenve tapasztalta, hogy egyeseknek egy egyszerű példa mennyire bonyolultnak, zavarosnak tűnik csak azért, mert az adott szintaxis nem megszokott a számukra.

Erről az ES6-os javascript kódról volt szó:

const secret = msg => () => msg;

Ez volt számukra bonyolult, zavaros. A vele ekvivalens ES5-ös kód viszont könnyen érthető és egyszerű számukra:

const secret = function (msg) {
  return function () {
    return msg;
  };
};

A CBT build eszköz koncepcionálisan az egyik legjobb, kicsi, gyors, könnyen megérthető, könnyen bővíthető.
Ha valaki JVM alapú buildeket csinál és ismeri a Scala programozási nyelvet, akkor az egyik legjobb választás lehet rövidesen.
További információk, videók, bemutató diák (slides) itt, ez pedig a legfrissebb videó.

Friss filmek az Indexen, köztük a rólam elnevezett is (En Passant).
Mindet még nem néztem meg, de a Remény nekem nagyon tetszett.

Erre a kérdésre a választ Li Haoyi zseniális cikkében találhatjuk meg.
Fejlesztőknek erősen ajánlott olvasmány!

Aki szereti a VimWiki-t és a markdown (vagy a mediawiki) formátumot, azoknak szól ez a blog.
A VimWiki-ben eddig is benne volt a markdown támogatás, de ha html-re szerettük volna konvertálni, akkor nem volt igazán jó megoldás.
A pandoc programmal egy csomó formátumból (markdown, reStructuredText, DocBook, MediaWiki, ...) konvertálhatunk még több csomó másik formátumba (epub, docx, pdf, odt, html, ...).
Ezt felhasználva a markdown-os VimWiki-nket könnyedén szép HTML-es web oldalakká konvertálhatjuk.

Ebben a blog bejegyzésben azt boncolgatom, hogy egy egyszerű algoritmust hogyan lehet hatékonyabbá tenni. Mindehhez nem kell más, csak egy kis lustaság! ;)

Vigyázat funkcionális programozást tartalmaz és egyébként is túl hosszú, ne olvasd el!

Nagyon jó előadások a témában:
Let’s Get Lazy—The Real Power of Functional Programming - Venkat Subramaniam

Java nyelven biztosan sokan használnak különböző naplózó rendszereket hibák, információk rögzítésére.
Sokszor előjön az a probléma, hogy maga a naplózás visszafoghatja az alkalmazásunk teljesítményét, főleg, ha egy nagyon sokszor hívott funkción belül naplózunk. Lásd pl. itt.

Az if-else használata fórum témánál már előkerült a GildedRose-Refactoring-Kata.
Ez egy refaktorálási gyakorló feladat, amivel rengeteg nyelven próbálkozhatunk.
A feladat röviden:

1. Tesztek írása minden estre.
2. Kód refaktorálása, hogy könnyen érthető és módosítható legyen.
3. Új funkció hozzáadása: "Conjured" elemek kezelése

A PayPal-osok csináltak egy remek keretrendszert (squbs) (Akka-ra épül), amivel könnyen készíthetők jól skálázható, reaktív alkalmazások. Ez a keretrendszer mindenki által szabadon használható, nyílt forrású (squbs forrás GitHub-on), ráadásul részletesen dokumentált (GitHub forrásnál található), rengeteg példával.

Az OOP programozók gondolom hallottak már a SOLID alapelvről, minden estre, ha fel kellene eleveníteni, akkor van egy nagyon jó blog post, janoszen blogtársunk tollából. Én is az ott leírtakat használtam az írásomhoz.

A SOLID-ból nekünk igazából most csak a SID (gonosz kisgyerek a Toy Story-ból;) az érdekes. Nézzük ezeket egyesével:

• S: Single Responsibility Principle (Egy felelősség elve).

A tranzakciót szinte minden programozó ismeri, a Saga-t talán kevesebben. Röviden megnézzük, hogy mire is valók, hogyan próbálják azt elérni, mik az előnyeik, hátrányaik.

Mind a kettő arra való, hogy egy tevékenység sorozatot hajtsanak végre és probléma esetén kompenzálják a módosítások hatásait.

Tranzakció:
Tevékenység sorozat végrehajtása atomi műveletként, miközben az adatok konzisztensek a tranzakció előtt, alatt és után, probléma esetén a kiindulási állapotban marad a rendszer.

A minap bukkantam egy tanulmányra, ami a Github-on és a SourceForge-on található összes Java projekt exception kezelését elemzi, itt letölthető a PDF.

Arra a konklúzióra jut, hogy a fejlesztők többsége figyelmen kívül hagyja a checked exception-t és nem kezeli megfelelően. A más típusú exception-ökkel is hasonló a helyzet. A fejlesztők hozzáállásától és képességétől függ, hogy megfelelően kezelnek-e egy exception-t, azt nyelvi eszközökkel (checked) nem lehet kikényszeríteni.

Nemrég olvastam egy blogot, Don't use Actors for concurrency, amiből kiderült, hogy vannak akik nem tudják (a blog írója), hogy mi a különbség a konkurens és a párhuzamos között.

Hoz egy példát, hogy miért nem jó az (Akka) actor a konkurenciára, amiben nincs is konkurencia, ha lenne benne, akkor viszont jó példa lenne arra, hogy miért is jó az actor a konkurenciára.

Mi is a konkurencia és miben különbözik a párhuzamosságtól?

Polimorfizmus. OOP vs FP

Kérés-válasz (request-response) stílusú actor kommunikációnál a tell alapú (Response Collector) kommunikációt javasolják az ask mintájú helyett. Ez leegyszerűsíti az actor kommunikációt úgy, hogy a legtöbb válasz kezelési feladatot egy kitüntetett actor alá helyezi.

tl;dr
Egyik korábbi blogomhoz érkezett egy ilyen hozzászólás:

Idézet:
"Eddig bármikor is vettem vmit automatából, sose lett új pénztárcám, és sose termett előttem egy másik automata."

Sokan vallják a fentieket, vagyis, hogy a valóságban nem képződnek új objektumok, hanem egy létező objektum állapota változik csak meg.
Ez a hagyományos OO szemlélet.
A másik szemlélet az FP szerinti, ami ellen a fenti idézet is irányul, vagyis, hogy ha változik egy objektum, akkor azt új objektumnak tekintem.

Ha valakit érdekel a clean és simple code, akkor itt olvashat róla:
OKTV-s informatika versenyfeladat átalakítása tiszta és egyszerű kóddá

A történet folytatódik a 2. és egyben befejező résszel.

A napokban találtam a témában egy nagyon jó videót Ken Scambler-től.

A videóban szépen sorra veszi, hogy milyen tervezési hibák miatt használunk Mock-ot és Stub-ot, valójában ezek mit szeretnének kiváltani; és milyen módon tervezhetjük át a kódot, hogy ne legyen szükség rájuk, aminek hatására:

• modulárisabb,
• jobban újrafelhasználható,
• egyszerűbb,
• kevesebb kód,
• kevesebb változó rész,
• Mock eltűnik,

Az implicit konverziónak két fontos előnye van:
1. Látszólag kiegészíthetjük egy osztályunkat új metódusokkal
2. Szép DSL-ek készíthetők vele

A mostani megvalósításra szép leírást találunk itt: Add Your Own Methods to the String Class