Kategorie: Programování

  • Programovací vyhlídky pro rok 2017 pohledem Javisty

    Občas přemýšlím, co máme k dispozici nyní a co možná do budoucna teprve přijde. Zrovna mi pár myšlenek hlavou koluje, tak jsem se rozhodl je zapsat, než utečou zase pryč 🙂 .

    • Dynamicky typované jazyky: Zkušenost ukázala, že dynamické typy jsou dobré asi jen na jednu věc, a sice jedno-souborový max 50 (nebo možná ještě 100) řádkový skript. Jakmile byste chtěli psát něco většího, tak – co se typů týče – už zkrátka vůbec nevíte, která bije. Když jsem přepisoval IRC bránu z Pythonu do Kotlinu, byl jsem sám sobě vděčný, že jsem si skoro u každé metody psal do komentářů, jakého jsou její parametry typu, jinak bych to možná nepřepsal nikdy 😀 . Z toho mi plyne, že řešením nejsou statické typy samy o sobě, ale především jejich automatické odvozování překladačem!
    • Python vs. Kotlin:  Tuto otázku jsem si ostatně pokládal už před cca 6 lety, když jsem začal objevovat Scalu, ale tedy ještě jednou aktuálně: Má ještě nějaký význam psát něco v Pythonu, když máme něco jako Kotlin? Python je jen o něco malinko stručnější než Kotlin (anebo někdy tomu tak dokonce i neni) a Javovské VMko je přece rychlejší než to Pythoní. Posuďte sami … ale pro toho, kdo je Javovským ekosystémem takřka prosáklý, je, myslím si, volba jasná 🙂
    • Budoucnost jazyka Go: Co jsem slyšel, tak Go-čkaři si především pochvalují, že si můžou zkompilovat jeden docela malý bundle, který běží se vším všudy. Nicméně Oracle již pracuje na AOC překladači pro Javu, pomocí kterého bychom i v Javě měli docílit téhož. K čemu bude Go dobré pak? Pak by ještě mohla přijít řeč na Goroutines, jakožto velmi lightweight alternativu k threadům, ale tady bych odpověděl opět Kotlinem a to slovem „Coroutines“ 🙂

    Z toho, co mě napadá, to bude asi vše, ale co se obecně Javy týče, přijde mi, jakoby se vývoj tohoto jazyka vedl opožděně zcela záměrně, stylem: „Nejdříve omrkneme, jak s danou featurou uspějí jiné jazyky a když se to osvědčí, tak to naimplementujeme taky“. Takto Java sází více na jistotu, ale na druhou stranu vše přichází později. Nedivil bych se, kdyby Java za 5 – 10 let vypadala cca tak, jako Kotlin nyní, ale nevím … ten malý rebel uvnitř mě by byl i docela rád, kdyby indexem TIOBE zatřásla změna a objevil se nějaký nový trend, který by přepsal již po dekády zaběhlé stereotypy.

  • Pořádný kódový žvanec v Kotlinu

    Jak už nadpis říká, podařil se mi v Kotlinu napsat docela slušný blok kódu 😀 . Logika: Představte si, že chcete z chatu načíst nové vzkazy. Věci se však mají tak, že nejdříve načtete, kolik je nových vzkazů, kde odpověď může být null. Pak jen ověříme, že tento počet je více jak 0 a můžeme se do toho pustit. Dříve, než vůbec začneme, pingneme stránku vzkazů, abychom serveru řekli, že už jsou přečtené (anebo to bych asi měl udělat, až je skutečně přečtu, což? 🙂 – opraví se) a pak: zjistíme seznam všech uživatelů, od kterých nám kdy vzkazy přišly (odpověď může být null), pro každé jejich ID načteme seznam vzkazů (včetně našich odpovědí a opět to může být null), odstraníme všechny nully a všechny listy zpráv splaskneme do jediného, odstraníme ty, co jsme poslali my sami, setřídíme je od nejmladšího a z toho celého si vezmeme pouze oněch N nových. Tak, to bychom měli. A nyní už zbýva ověřít, jestli UID zdrojového uživatele není null, a pokud není, tak si ho načteme z keše a pokud ani on není null, tak můžeme směle odeslat IRC klientovi zprávu, že mu přišel vzkaz. No není to paráda? 😀

  • Kotlin vs. Python – srovnání na reálném projektu

    Jak jsem již psal dříve, rozhodl jsem se přepsat jeden náš společný projekt (ChatCzGate), který jsme psali s Imrijou v Pythonu, do Kotlinu. Rozhodl jsem se tak proto, abych jednak Kotlin prověřil trochu důsledněji než jen na jednoduché Spring Boot aplikaci, ale taky abych si ho i trochu lépe zažil. Konec konců, nejlépe se nový programovací jazyk naučíte právě tím, že si v něm rovnou něco netriviálního napíšete.

    Pro srovnáni jsem vybral tyto 2 soubory:

    Co se vám libí více? 🙂

    PS: Zdá se, že vše funguje, jak má a během celé implementace nenastal jediný NullPointerException 🙂 , takže za mě palec nahoru.

  • Krásy Kotlinu aneb střípky z přepisu IRC brány pro Chat.cz

    Abych Kotlin podrobil dostatečné zkoušce, nemohlo to samozřejmě zůstat jen u přepisu jednoduché Spring Boot aplikace. Rozhodl jsem se tedy, že dostatečným kandidátem by mohla být IRC brána ChatCzGate, kterou jsme s Imrijou napsali kdysi dávno v Pythonu. V tomto článku bych se chtěl podělit o pár postřehů, ale i nějaké to zamyšlení ohledně toho, co se v „Kotlinovském kruhu“ odehrává.

  • Programovací jazyk Kotlin a mé první dojmy

    Již před dávnými léty, kdy vypukl JVM-language boom, jsem se doslova musel smát, když jsem se (pocitově) každých 14 dnů dočetl o novém supr dupr programovacím jazyku pro JVM, který zřejmě má být ten nejlepší a říkal jsem si, proč doprčic potřebujeme něco dalšího, vždyť Scala již vyřešila všechny naše problémy, nebo ne? 🙂 Mou pozornost upoutalo nedávné prohlášení Googlu, který oznámil Kotlin jako oficiálně podporovaný jazyk pro Android a dále moc hezký článek Mika Hearna o tom, proč se právě Kotlin stal jeho dalším programovacím jazykem.

  • Lambda funkce v Javě 8 – prokletí nebo vykoupení?

    Já osobně jsem se poprvé s lambda funkcemi setkal ještě za svých studentských časů na mé Ostravské alma mater, kdy jsem byl hluboce zanořen do samostudia jazyka Scala. Tehda to bylo taky poprvé, co jsem se začal seznamovat se základními koncepty funkcionálního programování, které mi přišly zcela mind-blowing. Krom toho taky mnoho featur Scaly byly mind-blowing samy o sobě a už toho času jsem měl takový ten pocit, který mi říkal: „Jó, tak takhle bude možná Java vypadat za 3 roky“. Trošku jsem se přecijenom zmýlil, protože Java 8 přišla až za 4 roky a některé další featury ze Scaly se plánují snad až do Javy 10. Dnes už je to 2 roky, co máme lambdy a Stream API k dispozici a přesto (k mému údivu) narážím až na překvapivě velké množství Javistů, kteří je buď nepoužívají, anebo ani neví, co to vlastně je. Ba co více, nedávno jsem narazil i na kolegy, kteří mi vyloženě tvrdili, že lambdy jsou hnus a že nechápou, jak do Javy mohl někdo něco takového dát. Právě tento názor, který mě upřímně docela dostává, mě motivoval napsat tento článek, ve kterém se vám pokusím zběžně ukázat, proč jsou lambdy boží a proč zřejmě ten nejpodstatnější důvod, proč si zvolit jakýkoliv jiný jazyk než Javu, je již od verze 8 nenávratně passé.

  • Žebříček hry Ovečky pojďte domů byl opět zprovozněn!

    Jak říká název, podařilo se nám s kolegou dát online žebříček opět dohromady. Další novinkou je, že tato hra bude brzy opensource a možná se konečně dokopu dodělat mód vlků s lasery na hřbětě 😀 , takže udatujte, instalujte!

  • Co je RxJava a k čemu je vlastně dobrá

    Už před pár měsíci jsem si tento nadpis přidal mezi rozpracované koncepty tohoto blogu, ale záhy jsem si uvědomil, že na tuto otázku ještě nedokážu zcela uspokojivě odpovědět. Vzpomínám si, když jsem na Devoxxu v Krakově viděl RxJavu poprvé, krom toho, že mi nebylo úplně jasné, jak to přesně funguje, jsem si kladl jednu a tu samou otázku: „K čemu je to sakra dobré?“. Není to to samé, co už umí Streamy v Javě 8? Čas i zkušenosti pokročily a tak nastala chvíle podělit se o to, jak vidím RxJavu já.

  • Java tip: For není fór a split není řiť

    For()

    Už jste se někdy přistihli při psaní tohoto cyklu?

    for(int i = 1; i < something; i++) {
        //Do something
    }
    

    Pak vězte, že v (dle mého názoru) opravdu velkém počtu případů je to znamení, že je něco špatně. Buď máte špatný design, anebo to jde celé udělat jinak a mnohem lépe. Ne vždy se tomu člověk vyhne, ale čím častěji, tím líp.

    Split()

    Další věcí je metoda String.split(). Použili jsme ji asi všichni, ale přiznejte se, kolik z vás ji opakovaně používá na parsování Stringu ve smyslu, že pak použijete pouze něco z výsledné množiny? Na to mám pouze jednu odpověď: Naučte se regulární výrazy a vyzkoušejte Rojo 🙂.

    NějakýInterfaceImpl

    Původně jsem se domníval, že je to spíše věc ojedinělá, ale nedávno jsem v praxi narazil již na druhého člověka, který, jak se zdá, má až chorobnou touhu vytvářet interfacy 🙂 . Jedná se především o DAO třídy. Moje představa o použití interfacu z hlediska designu je taková:

    1. Očekává se, že něco může mít vícero implementací
    2. Tyto implementace jsou volány „přes jediné API“ / nebo též „stejným způsobem“

    Pokud si tyto dvě otázky položím v případě DAO tříd, tak jsem názoru, že každé DAO má mít vždy pouze jednu jedinou implementaci, a i kdybych připustil, že by někdo někdy chtěl mít pro 1 DAO implementací více, tím hůře si dokážu představit, proč by je chtěl volat stejným způsobem? 🙂 S tímto i úzce souvisí názvosloví končící na Impl, kde vám hned vysvětlím, proč ho nemám rád. Samotná neurčitost názvu na mě působí dojmem, že implementace daného interfacu je skutečně pouze jedna, čímž smysl interfacu samotného vlastně popírá, jinak by se přeci jmenovala nějak smysluplně, nebo ne? Např. měl-li bych interface Service, čekal bych implementace jako FileService, NetworkService, ale rozhodně ne ServiceImpl 🙂 . Z tohoto mi plynou hned dvě ponaučení:

    1. Přemýšlejte nad názvoslovím, protože již ono samotné může odhalit chybu ve vašem myšlení
    2. Nedržte se striktně naučených pouček o čistém kódu, ale běžte více do hloubky daného problému a, zkrátka, přemýšlejte 🙂 . Aneb jak již jednou někdo řekl: „Všechny generalizace jsou mylné, včetně této“.

    PS: Další důvod proč nedělat interfacy tam, kde jsou zjevně zbytečné, je ten, že když si na některou metodu takového objektu v Eclipsu se stiskem CTRL kliknu, nedostanu se přímo do kódu, ale do interfacu samotného, což je strašně otravné 🙂 .

  • Rojo benchmark s JMH

    Zrovna nám nedávno vyšlo Rojo ve verzi 1.0.3 a já jsem si říkal, jak je na tom tato knihovna s výkonem. Rozhodl jsem se ji tedy trochu otestovat a proměřit pomocí JMH a i přesto, že se mi způsob vytváření nového benchmarku přes maven archetyp příliš nepozdával, tak se mi to nakonec rozjet podařilo 🙂 .