Je GO lang opravdu tak rychlý?

Před nějakou dobou jsem měřil rychlost JavaScriptových enginů v růyných prohlížečích a NodeJS. Více zde.

Vedlo toho jsem se letos začal věnovat více i Go, a proto jsem rychle přepsal základní test for loop smyčky do goučka a cvičně to otestoval…

Testovaný kód

A výsledek je zde:

Vedle toho jsem cičně znovu spustil původní test v TypeScriptu a dostal jsem následující výsledek:

První závěr

Go skutečně rychlejší je. Nicméně ne o tolik, kolik bych čekal, když slyším všechny o Go básnit. Což je dobrá zprává pro všechny příznivce JavaScriptu, či TypeScriptu.
Tím samozřejmě nesnižuji Go. Libí se mi.

Vedle toho je mi jasné, že moje tesováné je hodně zjednodušené 🙂
Na druhou stranu aspoň nějaké testování… Vůbec v době, kdy je internet plný samých důveryhodných informací.

Vedle toho

Vytvořil jsem z Go zdrojáku i binárku pro svého Meka a otestoval i tu:

Opakovaně jsem spouštěl test jak v interpreteru, tak jako binárku.

Pak jsem otestoval i na VPSku s Centos 7 a dostal se následujícím výsledkům:

Hola!

Zajímavým zjištěním je že můj zkompilovaný test není rychlejší než kód běžící v interpretu. Potvrzeno i na jiném stroji.

Opět připomínám: měřil jsem velice jednoduchou funkcionalitu, ale v každém případě je to minimálně zajímavé zjištěmí, o kterém jsem přesvědčen, že mnoho z těch, co diskutují do aleluja, vůbec neudělali…

Proč

Mimo jiné jsem chtěl poukázat na fakt, že je leckdy docela jednoduché a asi nejpřímočarejší si napsat své vlastní testy na vybrané aspekty, na kterých vám záleží. A těmi nemusí být vždy jen samotná rychlost, ale například i memory usage, nebo propustnost, či cokoliv jiného.

NodeJS: neodchycené výjimky

Premisa 1: JavaScript, potažmo TypeScript, je komplexní, mocný programovací jazyk. Krom všeho možného 🙂
Premisa 2: všichni děláme chyby…

Je dobré o chybách vědět.
A to je cílem tohoto kódu:

Tento krátký kód se postará o obsluhu všech neodchycených výjimek kdekoliv v aplikaci. A proto je dobré jej umístit někam do míst startu aplikace, aby vše, co je španě, někde nepropadlo. V samotné funkci obsluhy výjimky pak může být cokoliv co vám dává smysl: výstup do konsole, notifikace někam přes sít, či cokoliv jiného co vám dává smysl.

Více zde.

Objektové programování vs funkcionální programování

Nemám tyhle debaty o programování rád, ale čas od času jsem do nich i já nějakým způsobem zavlečen a musím se v nich, respektive k nim vyjadřít.

Takže předně

Každé programovací paradigma má své nějaké základní parametry, vlastnosti, respektive přímo důvody vzniku, které jej více či méně kvalifikuje pro řešení daného problému. Tohle je si potřeba uvědomit hned a postupovat podle toho. Z toho může po povrchní úvaze, bez hlubších teoretických znalostí vyplynout, že v podstatě vše jde napsat v čemkoliv. Což může být určitě taky pravda…

Na druhou stranu není dobré se dostat do extrému, kdy na základě výše popsané situace s univerzálnosti a všestranností porgramovacích jazyků, dojdete k názoru, že pak je vlastně jedno v čem píšete, a proto vše co píšete, nebo budete psát, budete psát striktně dle jednoho jediného paradigmatu.

Do této pasti se obvykle dostávají buď juniorští programátoři, v lepším případě dobře teoreticky připraveni, ale bez praktických zkušeností, které by jim pomohly identifikovat potřebné signály, které by je vedli k adekvátnějším závěrům, nebo naopak rádoby seniorní programátoři, kteří na nějakou teorii, kterou možná kdysi znali už zapomněli, a vidí jen to svoje.

Co z toho vyplývá?

Vedle každodenního psaní kódu je potřeba se stále vzdělávat. Znát věci nejen prakticky, ale vědět proč a jak fungují. Vědět, co stojí za jejich fungováním. A čím hlouběji půjdete, tím lépe. V dlouhodobém měřítku na tom rozhodně vyděláte.

A tady se dostávám k jednomu z programátorských doporučení: kterýkoliv programátor by se měl každý rok pokusit naučit nějaký nový programovací jazyk. Studiem nového jazyka si osvojujete nová paradigmata, která rozšiřují váši teoretickou znalost. Vedle toho vám tyto nově nabité poznatky dovolí podívat se na každodenně řešené úkoly novým úhlem pohledu a umožní vám úkol řešit novým způsobem, nebo i novým paradigmatem. Možná i novým programovacím jazykem… 🙂

A kde začít?

Našel jsem velice pěkný článek, který se dá použít jako materiál pro vlastní argumenty k těmto diskusím…

Kam dál?

Funkcionální programování
Deklarativní programování
Imperativní programování
Strojový kód
Referenční transparentnost
Strukturované programování
Objektově orientované programování
Multiparadigmatický programovací jazyk

Tenhle ví o programování skutečně všechno…

Co by každý programátor měl znát

Našel jsem velice hezký, ne až moc dlouhý, článek, popisujicí některé základní koncepty, návrhy v OS, o kterých si myslím, že by měl znát, nebo asponň měl mít minimální povědomí, každý, kdo se rozhodne profesionálně programovat.

Hloubka těchto znalostí a míra dalších, pak odděluje jednotlivé programátory na stupnici HEJA!…….OUPS!

A myslet si, že pokud píšeš v JavaScriptu, nebo nedej bože v PHP, tak se tě to netýká, tak to je opravdu omyl. Velký omyl!

Těch znalostí by mělo být samozřejmě daleko víc. Ne jen týkající se OS, ale dalších témat. Myslím si, že právě komplexnost, tedy rozsah znalostí a jejích hloubka každého kdo se snaží o dobrý kód posouvá na oné stupnici blíže k označení HEJA!.

Zároveň si uvědomuji, že ono posouvání je dlouhodobý a tvrdý proces. Musí tě to bavit 🙂

Proč tento článek?
Mám takový nějaký divný pocit, jako by všechny kolem zachvátil virus povrchnosti, který dává všem falešnou představu znalosti a neumožňuje jim opravdového prohlédnutí. A to se asi netýká jen IT. Je to asi obecnější jev. Lidi se díky tomuto viru nejsou schopni ponořit hlouběji, a proto nezažívají uau efekty, který je nutný na cestě od OUPS! k HEJA! A pokud budete dlouho OUPS!, pak asi těřko můžete být spokojený, natož šťastný.
HEJA! je to ještě o programování? Jasně že je! 🙂

Z shell

Vedle samotného vývoje se zabývám devops činnostmi, ke kterým patří různé práce na strojích v drtivé většině s OS Linux. Hodně času trávím v sehllu. Na většině serverech je výchozím shellem bash a mě až do nedávné doby nenapadlo nevyzkoušet žádný jiný shell. A že jich je….

Až do minulého týdne. Po velmi dlouhé době jsem se vrátil k zshellu. Podařilo se mi dotáhnout instalaci až do konce a jsem nadšený… Nejenže zshel vystřídal na mém mekovi stantdartní a defaultní bash, ale nainstaloval jsem si jej i na ostatní servery, na kterých provádím nějaký deploy.

Jednu z nejsilnějších stránek zshellu vidím super konfigurovatelnost promptu a jeho možnosti vizualizace. Prompt v zshellu vypadá opravdu skvěle. A nakonfigurovat jej je skutečně hračka.

zshell

Na první pohled vidím, že nejsme na svém stroji, ale na nějakém serveru, vidím kde jsem, ale co je největší přínios, hned vidím kde jsem v gitu, na jaké jsem branchi a jak si na něm vedu. Mám aktuální zdrojáky? Nejsem v nějaké změně dopředu? Integrace promptu s zsehllem je super!

Vedle toho jsem si dokonfiguroval pravou stranu promptu: odebral jsem všechny možné skopičiny a nahradil jej jen jednoduchou notifikací informace s návratovou hodnotou provedeného příkazu.

Další drobnost, ketrá potěší. Už žádné echo $?, ale jasně zobrazený výsledek i s exit statusem…

A těch drobností je mnohem. Víc.

zshell: instalace

1. instalace samotného zshellu

Pokud jste na mackovi stačí jen přes brew:

A pak už jen výměna defaultního bash za zshell:

2. instalace oh-my-zshell

Oh My Zsh je skvělá nadstavba pro zshel!

3. instalace themes pro oh-my-zshell

4. kustomizace promptu

Finální úprava konfigurace v ~/.zshrc

5. změna fontu v terminálu

Aby se všechny znaky korektně zobrazovaly, je potřeba si v terminálu nastavit font, který tyto znaky umí. Jedná se o fonty, které obsahují ve svém názvu slovo Powerline. Odkaz na fonty najdeš níže.

font

iTerm2 -> Preferences -> Profiles -> Text -> Font

6. doinstalovani pluginu

je pak jeětě potřeba do sekce plugins pridat zsh-autosuggestions a zsh-syntax-highlighting

Hotovo!

Může se hodit:
Powerlevel9k
Powerline fonts
Oh My Zsh

TypeScript: async funkce s interface

A takhle by mohla vypadat vaše async funkce pracující se složitějšími datovými strukturami realizovanými pomocí interfaces:

Async/await nebo callback? Oboje!

Pokud chcete nabídnout svoji funkcionalitu skutečně širokému obecenstvu, pak byste je asi neměli nutit do vámi vybraného modele použití formou callbacku, nebo promises, ale nabídněte hned obě.

Nic složitého. Stačí nabídnout interface funkce, kde budete detekovat její parametry a podle nich, respektive volání s nimi, zjistíte jak daný konzument vaší funkcionality hodlá použít a podle toho vyberete implementaci samotné funkce:

Samozřejmě lze napsat i kompaktněji:

Syndrom mrtvého koně

…Syndrom mrtvého koně je jistý druh slepoty, která může postihnout stejně tak webdesignera jako vrcholového manažera.

Když zjistíš, že jedeš na mrtvém koni, sesedni!

V reálném životě a zejména tom profesním, lidé volí i další strategie:

  1. říkáme: Vždyť ten kůň vždycky jezdil
  2. založíme pracovní skupinu pro analýzu koně
  3. zapřáhneme několik mrtvých koní k sobě, aby se jim společně lépe táhlo
  4. navštívíme jiná místa, abychom se podívali, jak se tam jezdí na mrtvých koních
  5. obstaráme si větší bič
  6. vyměníme jezdce
  7. zvýšíme standard kvality pro jízdu na mrtvém koni
  8. vytvoříme výbor pro oživení mrtvého koně
  9. vypracujeme srovnávací přehledy různě mrtvých koní
  10. upravíme kritéria, podle kterých se určuje, zda je kůň mrtvý
  11. zaplatíme externí specialisty, aby jezdili na mrtvém koni
  12. prohlásíme, že žádný kůň nemůže být natolik mrtvý, aby se na něm ještě nedalo jezdit
  13. vypracujeme studii, abychom zjistili, zda pro tento problém existují levnější poradci
  14. zakoupíme něco, po čem bude mrtvý kůň běžet rychleji
  15. nasedneme na svého starého slabého osla a zamaskujeme ho mrtvým koněm
  16. nařídíme přesčasy a nosíme mrtvého koně sami
  17. restrukturalizujeme stáj
  18. zdvojnásobíme příděly krmení
  19. prohlásíme, že mrtvý kůň byl už od samého počátku naším cílem
  20. povýšíme jezdce
  21. budeme zapírat, že jsme kdy nějakého koně vůbec měli
  22. sedneme si a budeme čekat, až se kůň sám zvedne
  23. dáme mrtvému koni řídíci funkci

A pak ještě tahle verze mrtvého koně… 🙂

JavaScript: proměnná jako klíč v objektu

Pokud byste chtěli v objektu nějak dynamicky generovat název klíče, pak takto:

TypeScript: typovost skrze interface a její rozšíření

Jednou z hezkých věcí v TypeScriptu je možnost definovat vlastní datové typy a to hned dvěmi způsoby: skrze type, nebo pomocí interface.

Čas od času se může stát, že potřebujte vámi definovaný typ rozšířit o nějkou vlastnost a nechcete kvůli tomu vytvářet další, nový datový typ. Pak se vám bude hodit konstrukce využívající operátor &, která přesně tohle dělá.

Hezké je, že můžete takto spojovat více již nadefinovaných typů, a spojovat můžete i více než 2 typy, ale můžete rozšířit daný typ jen o konkrétní požadované nové položky.

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑