enpassant blogja

Miért rossz az @Annotáció?

 ( enpassant | 2018. november 27., kedd - 22:51 )

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 és parciális függvények

 ( enpassant | 2018. szeptember 24., hétfő - 8:00 )

Totális függvények

A függetlenség napja

 ( enpassant | 2018. augusztus 28., kedd - 19:09 )

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ó.

Problémák a függőséggel

 ( enpassant | 2018. május 3., csütörtök - 22:41 )

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.

Deklaratív konkurens programozás kémia segítségével

 ( enpassant | 2017. november 30., csütörtök - 22:20 )

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.

Mire, hogyan jók a típusok?

 ( enpassant | 2017. november 4., szombat - 15:45 )

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.

A megszokás nagy úr!

 ( enpassant | 2017. július 19., szerda - 19:53 )

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

CBT build eszköz már majdnem production ready

 ( enpassant | 2017. június 19., hétfő - 22:25 )

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 filmeket az Indexen

 ( enpassant | 2017. április 1., szombat - 22:29 )

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.

Mi is a funkcionális programozás lényege?

 ( enpassant | 2017. február 2., csütörtök - 15:06 )

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!

VimWiki markdown formátum támogatással (Pandoc)

 ( enpassant | 2016. december 17., szombat - 13:27 )

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.

N Királynő-probléma avagy "A lustaság fél egészség"

 ( enpassant | 2016. november 14., hétfő - 17:58 )

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

Hatékony naplózás (log) Java 8-on [Szekesztve]

 ( enpassant | 2016. október 22., szombat - 12:03 )

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.

GildedRose-Refactoring-Kata Scala nyelven

 ( enpassant | 2016. szeptember 14., szerda - 19:28 )

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

squbs: Egy új fajta, reaktív alkalmazás készítés PayPal módra

 ( enpassant | 2016. augusztus 25., csütörtök - 11:16 )

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 SOLID alapelv alkalmazása elindít az FP útján?

 ( enpassant | 2016. június 29., szerda - 8:40 )

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).

Tranzakció vs Saga

 ( enpassant | 2016. június 25., szombat - 12:13 )

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.

Java exception kezelés

 ( enpassant | 2016. június 21., kedd - 11:34 )

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.

Concurrent vs Parallel (Konkurens vs Párhuzamos)

 ( enpassant | 2016. június 11., szombat - 21:28 )

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?

[Scala] Polimorfizmus. OOP vs FP

 ( enpassant | 2016. június 7., kedd - 19:23 )

Akka, újrafelhasználható Response Collector

 ( enpassant | 2016. április 27., szerda - 10:00 )

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.

Immutable vs mutable

 ( enpassant | 2016. március 12., szombat - 13:18 )

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.

Mock & Stub, avagy hogyan tesztelünk rosszul tervezett kódot

 ( enpassant | 2015. november 18., szerda - 16:53 )

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,

Scala implicit konverzió helyettesítése

 ( enpassant | 2015. július 13., hétfő - 17:33 )

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