enpassant blogja

Ez a Paksi matek blog folytatása.

Sajnos már három és fél éve is látszott, hogy a Paksi matek nem jön ki.
Azóta folyamatosan jönnek a figyelmeztető adatok, hogy Paks 2-t jobb volna még most abbahagyni.

A magam részéről itt fogom gyűjteni a további adatokat, amik Paks 2 ellen szólnak.
Arra kell készülni, hogy egyre több ilyen lesz.

Lezárások és a maszk hasznossága avagy épp az ellenkezője?
Szezonális-e a vírus?
Második hullám?
Mi lesz a következő időszakban?

Rengeteg írás született már, hogyan készítsünk RESTful rendszert. Sajnos, amiket eddig láttam azok 99%-ban nem RESTful API-kat írnak le. Részletesen elemzik, hogyan alakítsuk ki az útvonalakat (URI path), miként nevezzük el az erőforrásainkat, mikor milyen HTTP metódusokat (POST, PUT, DELETE, PATCH, ...) használjunk, de ezek részletkérdések és általában csak a rossz irányba visznek minket.

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:
The case against annotations (Adam Warski), slides
Java Annotations Are a Big Mistake (Yegor Bugayenko), on DZone, slides
Evil Annotations

Totális függvények

Sokak által ismert a függvények és az eljárások (utasítások) közötti különbség. Az is ismert, hogy milyen előnyei vannak a függvényeknek az eljárásokkal szemben, amiért célszerűbb inkább azokat használni. Az már kevésbé ismert, hogy a függvényeket két nagy csoportba sorolhatjuk, parciális és totális. Ebben a cikkben megvizsgáljuk a parciális és totális függvények tulajdonságait, és azt, hogy miért célszerűbb utóbbiakat alkalmazni.

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.
2. Meg kell határozni az egyes kémiai reakciókat; vagyis mely molekulák együttese lép reakcióba és milyen molekulák lesznek az eredményei. Természetesen side effect is történhet a reakció során.

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.

Miért van ez? Lehet ezt jobban, sokkal jobban?

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;
  };
};

Ha valaki szeretne bővebbet olvasni arról, hogy a megszokás eltorzítja a gondolkodásunkat és ez milyen hátrányokkal jár, annak javaslom elolvasásra Eric Elliott ezen cikkét: Familiarity Bias is Holding You Back: It’s Time to Embrace Arrow Functions.

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.
Részletek és kép itt.

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
Laziness is the Ultimate Sophistication, both in Life and in 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.

Készítsünk egy kis alkalmazást és egy kis naplózó rendszert, amin meg tudjuk vizsgálni a problémát és ahol tudunk keresni az eddigieknél sokkal jobb megoldást is!

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

Én ezzel a Scala-s verzióval kezdtem, és a végére ide jutottam.

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.

A PayPal-osok írtak róla egy cikket is.

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).
  Egy osztály vagy modul egy, és csak egy felelősséggel rendelkezzen (azaz: egy oka legyen a változásra).

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.

• Atomicitás: több műveletet atomi (oszthatatlan) műveletként hajt végre, azaz vagy az összes művelet sikeresen végrehajtódik, vagy egyik sem.
• Konzisztencia: biztosítja, hogy az adatok a tranzakció előtti érvényes állapotból ismét egy érvényes állapotba kerüljenek. Fontos, hogy a tranzakció ideje alatt is konzisztensek maradnak az adatok.
• Izoláció: A tranzakciók izolációja azt biztosítja, hogy az egy időben zajló tranzakciók olyan állapothoz vezetnek, mint amilyet sorban végrehajtott tranzakciók érnének el. Egy végrehajtás alatt álló tranzakció hatásai nem láthatóak a többi tranzakcióból.

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.

Checked exception-ök kezelése: https://pbs.twimg.com/media/CkPvdPBWEAA7U4i.jpg

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?

Konkurenciáról akkor beszélünk, ha egy időintervallumban versengés van valamiért, több valami verseng egy valamiért. Pl. két tevékenység konkurensen hajtódik végre akkor, ha adott időintervallumban mind a kettő végrehajtódik (a két tevékenység verseng a végrehajtóért, vagyis azért, hogy a végrehajtó melyiket hajtja végre).
Párhuzamosságról akkor beszélünk, ha két tevékenysége egyszerre hajtódik végre.

OOP Polimorfizmus vs FP Monomorfizmus

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.
Ahelyett, hogy a timeout és hibakezelési logikát több helyre kellene felvennünk az actor rendszerben, az actor-ok egyszerű válaszokat adnak a kérésekre a tell mechanizmus segítségével, mialatt a Response Collector actor a beérkezett elegendő válasz alapján válaszol a kérést feltevőnek illetve kezeli a timeout-ot és az egyéb hibákat.

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.

Sokan OO vs FP ellentétként élik meg, magyarázzák, de a fő gond nem az OO-val van, hanem a mutabilitással. Az OO-t lehet immutable-ként is használni, úgy sokkal kevesebb gond van vele(, illetve mutable-ként is, ha üzenetváltással kommunikálunk).
Ha már itt tartunk, akkor megjegyezném, hogy szerintem a következő programozási paradigmákat érdemes használni (csökkenő fontossági sorrendben), ha egyszerű, könnyen érthető, de hatékony programot szeretnénk készíteni:

1. FP
2. immutable OOP
3. mutable (OOP) üzenetekkel (pl. akka, smalltalk)
4. egyéb mutable