Klávesové zkratky na tomto webu - rozšířené Na obsah stránky

Proč je [programovací jazyk X] rozhodně lepší než [programovací jazyk Y]

| Jen tak

Poslední dobou můžete najít spoustu srovnání, proč je [X] lepší než [Y], často ale může být pozorný čtenář ještě víc zmaten. Nakonec, vždyť oba jazyky jsou [pardigma] orientované, které běží na [platforma] a usnadňují programovat [styl] stylem, zatímco ponechávají dostatek flexibility, abyste mohli psát [sračkoidní kód].

Jelikož jsem napsal [jednoduchý CRUD backend] v obou jazycích, cítím se být dostatečně kvalifikovaný na to, aboch některé věci vyjasnil. Představte si [jednoduchý problém, který byste zadali páťákovi, který se učí programovat]. Implementace v [Y] by mohla vypdat nějak tak:

[Opravdu špatný kód v Y ]

Naproti tomu v [X] by to mohlo vypadat jen takhle:

[Vyleštěný kód v X, který předvádí syntaktický cukr]

Je celkem jasné, že druhá ukázka je mnohem snažší na pochopení a odolnější vůči chybám.

Teď zvažmě typové systémy. [Přesvědčení o tom, jaké relativní výhody a nevýhosy přináší statické/dynamické typování.] Jistě, [Y] nám dává [výhody Y typového systému nebo naopak jeho absence], ale vyváží to [nevýhody Y typového systému nebo jeho absence]? Jistě, že ne!

Dále se musíme podívat na buildovací nástroje. Zatímco [Y] používá [nástroj, kerý jsem se neobtěžoval pochopit], [X] používá mnohem vychytanější [nástroj, který jsem trošku pochopil]. To je dostatečný důvod na switch!

Podívejme se na to obšírněji. [X] má úžasnou [featura specifická pro X IDE, která je stále v alpha verzi] a také má skvělou integraci do [asi 50 let starý textový editor, jehož klávesové zkratky vycházejí z klingonštiny] a [IDE, které všichni používají a z hlouby duše nenávidí]. Jistě, [Y] taky můžete psát v některém z nich, ale je to mnohem složitější a bolestivější.

Nakonec, ikdyž je tu místo pro vícejazyčnost na platformě [platform], bylo by lepší, kdyby se šli [Y] programátoři někam zahrabat, nebo switchli na [X] a soupeřili s náma o hrstku [X] pracovních míst. Počkat, beru zpět. [Y] je úžasný!

Volný překlad článku od Joela Gruse – Why [Programming Language X] Is Unambiguously Better than [Programming Language Y]

Autor: Aleš Roubíček |

Velká pyramida

| Jen tak

Programátoři dostali na starost projekt na zelené louce: „Postavte pyramidu.“

Úkolu se chopili svědomitě. Architekturu rozdělili do tří vrstev, protože tak se to vždycky osvědčilo. Nejprve začali návrhem databázového modelu. Po dlouhosáhlých debatách, jestli použít Oracle nebo zkusit nějaké NoSQL řešení (třeba Mongo), zjistili, že pyramida žádnou databázi nepotřebuje.

Pro jistotu naimplementovali doménovou vrstvu. „Ta tam být musí!“ Byla to krásná velká koule z bláta. Nic na plat, že koule ani zdaleka pyramidu nepřipomíná, ale takhle to prostě dělají. Několik borců přišlo s návrhem elegantního řešení: „Uděláme novou verzi, která bude hranatější! Tady kluci už mají prototyp postavený na kolejích.“ Nutno dodat, že to byl velice krásný dodekahedron.

Pak přišla na řadu vrstva servisní, kde se použilo WCF, protože v něm lze prát RESTový i SOAP služby vpodstatě najednou. A tak se stalo, že nová vrstva okolo koule z bláta vypadala úplně jako, když si vytáhnete sluchátka po týdnu z kapsy – klubíčko neštěstí.

Blížil se šibeniční termín a nikomu ta změt stále pyramidu nepřipomínala. Pozvali si tedy ostřílené konzultanty, kteří už měli za sebou zkušenosti se stavbou zemljanek a dětských hřišť. Po dlouhých debatách přišli s geniálním řešením: Потёмкин.

Kouli z bláta obalenou změtí kabelů schovali za krásnou kulisu vyrobenou z fotky z Gízy. Detailu, že fotky z webu nejsou v dostatečným rozlišení pro tak velkou kulisu, si nevšímejte. Stačí nechodit moc blízko.

Autor: Aleš Roubíček |

Reaktivní programování

| Moje práce

V uplynulém roce se začaly hejbat ledy okolo rektivních extenzí a reaktivního programování vůbec. A já byl u toho. :)

Reaktivní manifest

Byl publikován Reaktivní manifest, který se snaží definovat, jak mají reaktivní aplikace vypadat a proč.

  1. Mají reagovat na události
  2. Mají reagovat na zátěž
  3. Mají reagovat na selhání
  4. Mají reagovat na uživatele

Manifest vyjadřuje moje snažení v uplynulých letech, takže jsem ho samozřejmě signoval.

CZPodcast

Již potřetí jsem byl pozván do CZPodcastu, abychom se pobavili o reaktivním programování, reaktivním manifestu a reaktivních extenzích.

CZ Podcast 92 – Reaktivní programování by Aleš Roubíček on Mixcloud

DevFest Pardubice

Na DevFestu jsem měl přednášku o Reaktivním programování a reaktivních extenzích.

Autor: Aleš Roubíček |

Mikroslužby

| Moje práce

Máme tu jedinečnou příležitost definovat si Mikroslužby ne v tom, co nejsou, ale v tom co jsou.

Tohle je má definice.

Definice

Mikroslužba je oddělený izolovaný a pojmenovaný kus logiky, který konzumuje 0..N vstupů a produkuje 0..N výstupů, který je vykonaný za účelem přinést konzumentovi nějakou výhodu. Toto je poskytováno jako služba.

Oddělená

Důvodem, proč to nazýváme Mikroslužbou a ne Službou, není počet řádek, který je menší než N, nebo velikost nasazované služby, která je maximálně N kilobajtů nebo žádná jiná libovolná metrika. Tím důvodem je nízký počet zodpovědností: jedna. Dělá to jen jednu věc a tu dělá skvěle.

Izolovaná

Izolovaná znamená, že funguje odděleně od ostatních věcí, což z ní dělá distribuovanou entitu. Nezáleží na tom, kde konkrétně leží fyzický hardware nebo na jakém OS to běží. Pokud to spadne, zůstává to v izolaci. Předchází se tak kaskádovému šíření chyby. Navíc nám to umožňuje snadno vyvíjet a aktualizovat službu samostatně.

Pojmenovaná

Jelikož jsou Mikroslužby izolované, potřebujeme na ně nějakým způsobem odkazovat. Jméno v kombinaci se vstupy a výstupy Mikroslužby nám definují signaturu nebo identifikátor Mikroslužby.

Vstupy a výstupy

Pokud máme jazyk, který podporuje typové informace, vstupy a výstupy mohou být typové. Tyto typy by měly být reflektovány při manipulaci. Což znamená, že konzument služby by měl znát, co služba přijímá a co poskytuje.

Vykonání

Protože konzument není ten, kdo vykonává logiku Mikroslužby, a Mikroslužby jsou přirozeně distribuované, volání nesmí konzumenta blokovat ve vykonávání jiných operací po dobu výkonu mikroslužby. Konzument nesmí být držen jako rukojmí, dokud mikroslužba nevyprodukuje svůj výstup. To znamená, že musejí být vytvořeny takové abstrakce, které nám umožní Mikroslužby konzumovat asynchronně.

Překlad článku Microservices od Viktora Klanga

Autor: Aleš Roubíček |

Legacy code writer - part 2

| Moje práce

Dostal jsi nový úkol, implementovat jednoduchou featuru do korporátního projektu. Jenže ten kód byl past vedle pasti.

Produkoval jsi legacy kód, kvůli Legacy code writerovi.

Nikdo nepíše legacy code od základu

Je dost možný, že vám první díl zněl trochu povědomně. Každý z nás se dost pravděpodobně v podobné situaci ocitl.

Nyní, prosím, zkuste přehodnotit svou víru ve zlého Legacy code writera. Myslíte si, že opravdu existuje? Jste si jistí, že pokaždé když narazíte na legacy code, tak k němu existuje mystický můž, který to celé napsal od základu?

Víte čemu věřím já? Že tento muž vůbec neexistuje, že je to jen velice příjemná a pohodlná zástěrka. Není tu žádná taková osoba, která by byla zodpovědná za celej ten bordel. Špatný programátor, Legacy code writer, je jen fiktivní postavou vytvořenou k tomu, aby nám pomohl obhájit naše malé, přetrvávající, hříchy.

Došel jsem k názoru, že psaní legacy code je distribuovanou aktivitou. Každý z nás do tohoto vleklého procesu, třeba i nevědomky, přispívá.

Zbytečně nezahazujte čas pátráním, kdo za to může, protože to my všichni. Každý z nás!

Legacy code je jako prach

Pokud neuklízíte, neustále se usazuje a je jedno jestli se díváte nebo ne.

Každý kus kódu, pokud je spravován více lidmi, tíhne k tomu stávat se špagetami nebo lasagněmi. Entropie má potřebu růst. Je to absolutně přirozený proces.

Nevěříte?

Zkuste se na to podívat z jiného úhlu pohledu: Kód přirozeně netíhne k tomu být čím dál tím lepší pouhým přidáváním featur hordou programátorů.

Mně to zní jako jednoduchý přírodní zákon: Živý kód tíhne k tomu, stávat se horším, dokud nedojde k záměrnému aplikování síly proti přirozené potřebě entropie růst.

Legacy code je to, co získáte, pokud nejste odhodlaný přísně aplikovat dobré zásady při správě kódu.

Dvě špatná rozhodnutí se vzájemně nekompenzují. Komulují!

První verze byla pravděpodobně navržená dobře. Šlo to celkem snadno, před programátorem byl list nepopsaného papíru. :)

Každý dokáže navrhout dobrý kód na zelený louce a udržovat ho po dobu tří měsíců. Pouze profesionální vývojář to zvládne i po dobu následujících let.

Nekritizujte prvního progrmátora, on možná odvedl velmi slušnou práci. Jenže jak na chvilku polevíte, začnou se objevovat první nepatrné částečky legacy kódu. Problém s částečkama legacy kódu je jako s korálama: mají potřebu se na sebe lepit až z nich nakonec vznikne nepropustná bariera pevná jako skála, se kterou už nepohnete.

Zaveďte dočasnou proměnnou a vězte, že další programátor se bude cítit oprávněn na ní nalepit nějakou funkcionalitu. Udělejte copy&paste maličké pětiřádkové funkcionality a čekejte že vaše budoucí já v jedné z těch kopií změní dva řádky a připraví tak jeho nástupce, kteří se to pokusí refactorvat, o několik vlasů. Nejspíš to vzdají.

Vynechte unit test a vězte, že další team si pomyslí:

Předchozí programátor si myslel, že pokrýt tuhle funkcionalitu testy je příliš nákladné. No, teď to určitě nebude o nic snažší. Takže se na to taky vyprdneme.

A tady to začne chátrat. Taky se tomu taky říká teorie rozbitého okna

Autor: Aleš Roubíček |