CategoryProgramování

Python: __slots__

Protože Python je objektově oriemtovaný, dynamický programovací jazyk, projde vám tato konstrukce:

Byť v konstruktoru v definici třídy inicializuji jen atrribut jmeno, skrze konstrukci self.jmeno = jmeno, mohu pak do objektu pepa vesele přidávat další adributy.

A to díky díky implementaci atributů třídy skrze interní proměnou __dict__ která formou slovníku sdružuje všechny atributy daného konkrétního objektu.

Od verze 3.6 můžete pomocí __slots__ definovat seznam povolených klíčů, atributů a zaříznout tak možnost vytvářet v objentu dané třídy nežádoucí, nebo prostě všechny nedefinované atributy.

Proč?

No minimálně ze dvou důvodů.

  • rychlost: práce se __slots__ zjednodušuje Pythonu přístup k atributům a tedy jej činí rychlejším
  • paměťová náročnost: díky tomu, že interpret zná všechny atributy, může efektivněji inicializovat jednotlivé nově vzniklé objekty

A pak se vám bude lépe kódovat např v MS Visual Codu, protože linter na vás bude řvát, že „Instance of ‚Osoba‘ has no ‚plat‘ member“

JavaScript: statické proměnné funkce

A tohle znáte:

Skrze název funkce můžete v jejím scope definovat proměnné, které se pak chovají jako statické proměnné a navíc jsou pomocí tečkové notace dostupně i mimo funkci 😀

Formátování kódu

Pokud vyvíjíte nějaký kód v týmu, rádi byste, mimo jiné, aby kód dodávaný jedntlivými vývojáři vypadal tak nějak stejně… Tohle se jednoduše řekne, ale ne už tak jednoduše zajistí.

Jasné, domluvíte se, že budete používat 4 mezery, a nastavíte si maximální délku řádku řekněme na 120 znaků (všichni máme přece široké monitory…) No a možná ještě pár nějakých drobností, na kterých se po nesčetném počtu několikahodinových meetingů společně domluvíte.

A věřte, není to žádná sranda, protože, nevím proč, ale tady platí pravidlo, že tohle je extrémně důležitá věc a mají potřebu, nebo rovnou musí se k tomu vyjádřit úplně všichni 😀

A pak příjde ta fáze, kdy se snažíte domluvený set vlastností aplikovat. Značnou výhodou může být když napříč týmem všichni používají stejný IDE, nebo editor, což ale nemusí a často ani nebývá pravidlem. Pak totiž stačí vybrat správný plugin do vašeho editoru a ten dokonfigurovat výše získanou konfigurací.

A ejhle, výsledek se né vždy dostaví. Respektive ne u všech. Každý má přece své prostředí nastavené nějak a nikdy v podstatě nedojde k takové synchronizaci v konfiguracích, abyste opravdu mohli říct: OLA! VŠICHNI FORMÁTUJEME STEJNĚ.

Ale proč vlastně?

No třeba už jen proto, aby když po někom otevřete skrze git verzovaný zdrojový kód a provedete nějakou minimální změnu, opravu, úpravu a pak soubor uložíte, nechcete, aby váš formátovač přeformátoval celý soubor a v gitu pak díky tomu neuvidíte jen vámi provedenou malou změnu, ale všechny nově naformátované řádky. Výsledný commit pak není řekněmě jednořádkovou záležitostí, ale hned velkým commitem. A nedej bože, aby původní programátor si pak onen soubor zase otevřel a znovu přeuložil. Pak vám příjde pullrequest a vy zase vidíte bambilion změn…

Jak tedy na společné stejné formátování?

No docela jednoduše: pokud používáte Prettier jako my, pak bude stačit, když zapomenete na nějakou důvěru ve své kolegy a jejich konfiguraci v rámci editoru a konfiguraci NATVRDO NACPETE DO KONFIGURAČNÍHO SOUBORU, který se stane součástí vašeho projektu.
Stačí, když v / vaše projektu vytvoříte .prettierrc.json a do něj umístíte vámi domluvené nastavení:

Těch konfiguračních možností může být samozřejmě více…

Další informace o možnostech konfiguračního souboru Prettieru najdete zde.

A jak máte nastavený svůj MS Visual Code editor najdete v souboru:
~/Library/Application Support/Code/User/
nebo zde, pokud používáte Insider:
~/Library/Application Support/Code - Insiders/User/settings.json
Pokud tedy běžíte na MacOS.

console.log() pro frontendisty

Jem malé doplnění článku o možnostech funkce console.log, terntokráte pto ty, co se ve vývoji pohybují na frontendu.

Pomocí modifikátoru %c můžete stylovat výstup do konzole prohlížeče a dosáhnout tak větší čtivosti vašich logovaných informací:

Výsledek pak může vypadat třeba takto:

NodeJS: debugování aplikací

Tímto článkem vykopávám asi větší a obsáhlejší samostatné téma, kterým je debugování NodeJS aplikací. Téma, které nepotřebujete hned jak začnete psát v JavaScriptu, nicméně se k němu určitě postupem času, tak jak vaše aplikace začnou být složitější, nebo jim začně docházet dech, propracujete.

Numeral.js

Vsuvka bokem: Numeral.js je pěkná JS knihovna, která vám pomůže pěkně a jednoduše formátovat informace např. s velikostí volné paměti a podobně. Zvláště pak jeji funkce format().

process.memoryUsage()

process.memoryUsage(): úplně tou nejzákladnější informací o kondici vaší aplikace může být info o tom, jak jste na tom s pamětí. Kolik si ji alokujete, kolik ji GC vrací zpět, ale hlavně kolik jí díky špatně navrženým algoritmům konzumujete a neuvolňujete. Tím pádem GC nemůže vracet paměť zpět do systému a vznikají vám memory leaky, které mohou mít za následek až třeba pád samotné aplikace.

Výstupem je pak info o využití paměti vaší NodeJS aplikací:

Debugging v Chrome DevTools

Chrome DevTools je sada nástrojů, které vám umožní monitorovat, debugovat vaši aplikaci přímo v internetovém plohlížeči Chrome. Ano, i to v NodeJS… Jediné co musíte, je spustit node s parametrem --inspect. Detaily najdete na této stránce.

Prohlížeč se pak díky websocketům, které NodeJS inscpector využívá, připojí na vaší aplikaci a uožní jí takto monitorovat přímo v okně prohlížeče.

Jediné co pak musíte udělat je přimo v prohlížeči otevřít stránku chrome://inspect/

V sekci Remote Target pak uvidíte vaší aplikaci spuštěnou s parametrem --inspect.

Po poroklinutí na ní se pak už dostáváte na nové okno, kde můžete procházet detailními informacemi o vybrané aplikaci.

Jen začátek…

V žádném případě si nedělám iluze o tom, že bych měl tímto postem pokrýt celé téma debugování JavaScriptových aplikací. Jde o první krok, výkop, na který budou navazovat další samostatné příspěvky, které budou popisovat nějaké mé rady, návody, postřehy.

JavaScript: nejen console.log()

Nejpoužívanějším příkazem pro debugování JavaScriptových aplikací je console.log(). Ale věděli jste, že výstup můžete formátovat:

Předpokládám, že console.dir(), console.table() všichni znají, ale co třebe console.assert()?

Do console se zapíše, jen když se 1. parametr funkce nebude pravda:

V případě, že výraz bude pravda, pak se žádný výstup do console neprovede.

Další pěknou funkcí je console.count():

Výsledkem pak bude vlastní počítadlo, které se inkrementuje jen když je čílo dělitelné bezezbytku 2:

Super je také console.trace():

Skrze tuto funkci dostanete do konzolového výstupu svou vlastní informaci, ale i info o tom, odkud jste tuto funkci zavolali…

Funkci console.time(), asi každý zná, ale pro úplnost:

Výstupem pak bude informace o tom, jak dlouho trvalo sečíst včechny čísla do 10.000.000 v milisekundách:

No a poslední funkcí je console.group() a console.groupEnd():

Výsledkem je pak pěkně zformátovaný, odsazený, a tedy u čitelný výstup třeba nějakých strukturovaných dat:

JavaScript: příkaz versus výraz

Tohle všichni určitě znáte a běžně děláte. A ti lepší z vás i několikrát denně 😀

A teď by mě zajímalo, kdo používý tento zápis:

Blbost, že? Ale potěší a ušetří 2 řádky kódu 😀

sleep(), nebo wait() v NodeJS

Znáte to: čas od času byste rádi na něco počkali. A zrovna to čekání není moc v souladu s asynchronní povahou samotného NodeJS.

NodeJS, narozdíl od sleep v PHP, nebo time.sleep v Pythonu, žádnou takovou funkcionalitu, zaplať pán bůh, nemá.

Proč byste měli třeba čekat?
Modelová situace: někde na vaší API, nebo někde úplně mimo váš dosah, spustíte například nějakým POST requestem proces, který nevíte kdy skončí, nebo jak dlouho bude trvat. Takže vám nezbude nic jiného, než se stále dokola ptát na nějakém endpointu, jestli už proces nedoběhl a API má pro vás data. No a abyste APInu nezahltily tunou nic neřešících requestů a nedostali se tak třeba na nějaký black list, je dobré mezi odesláním každého requestu nějakou dobu počkat a opakovaně se ptát až po nějakém rozumném časovém intervalu.

Třeba takto

Srdcem tohoto jednoduchého konceptu je jen využití Promise a díky syntax sugaru async/await, to pak celé vypadá takto imperativně, pochopitelně, pro každého péhápkáře 😀

Kód je tak dlouhý, protože v něm demonstruju krom samotnéo sleep() i vše kolem…

Go Lang: Scheduling

Skvělý dvoudílná miniseriál a schedulingu v Go.
Pokud to myslíte s Go vážne, pak by vás tohle nemělo minout.

1. díl
2. díl

JavaScript: funkcionální map trochu jinak

Jsem si jistý, že všichni znají metodu map.

Jedná se o funkcionální přístup, který nahrazuji tento imperativní přístup:

A tohle je map

Věřím, že všem známý a na první pohled jasný příklad funkcionálního programování, kdy ani tak neříkám jak, ale co se má udělat.

A teď trochu jinak

Tak předně jsem přesvědčen o tom, že tento funkcionální přístup je pro tyto druhy výpočtu, nebo něčeho takového, asi lepším zápisem. Ale také se uvědomuji, že i spousta těch, co třeba už dnes po té co se od klasického PHP for loopu dostali až sem, neví přesně co vidí, respektive co používají.

Výše zmíněný kód s funkcí map se dá napsat i takto:

Furt to dělá to stejné, že? 🙂
Ale zápis už je jiný. Vlastně není. 🙂

Věděli jste, že parametrem metody map je funkce? Jo jo, je mi to jasné. všichni kýváte, že samozřejmě ano…
Dyť přece funkcionální programování, vole….

Proč o tom vůbec píšu?

Jedním z důvodů je, že pokud si tento drobný, samozřejmý detail uvědomíte, pak můžete psát třeba i takto:

Líbí?

Pokud ano, pak máte nakročeno nejenom k tomu, že skutečně pochopíte funkcionální programování, ale že jednou budete schopni skutečně psát i větší aplikace a nezaseknete se, jako většina ve stádiu hele kámo, já umím procházet polem. 🙂

Takže ještě jednou: Proč?

Jak se chcete dostat k takovým věcem, jeko je modularizace kódu, jeho dekompozice, nebo možná třeba jen refaktoring, když neuvidíte věci jak je máte vidět?

Myslím si, že pokud se naučíte hledat drobnosti a budete skutečně vidět detaily, může se z vás jednou skutečně stát dobrý programátor 🙂

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑