MongoDB: validace schématu

Byť je MongoDB bezschématová databáze, a pane Bože díky za to, čas od času se objeví diskuse a témata, jak do ni roubovat nějaké schéma, nebo něco, co by se mohlo podobat definici struktury tabulek. Ono je už tohle zcestné, protože Mongo žádné tabulky nemá. Má kolekce. A kolekce je přesně to, co to slovo říka…

Takže pokud ani po té, co jste si uvědomili význam skova tabulka a kolekce a dál ve vás přetrvává potřeba do kolekce roubovat sloupce, pak mám pro vás dobrou zprávu 😀 Mongo má Schema Validation, což je jeho interní funkcionalita, která vám umožní na úrovni collections definovat validace schématu při vkládání, nebu updatování dokumentů.

Při pokusu insertnout, nebo updatovat dokument, který neprojde validací získáte info o tom, co je špatně.

Pro validaci ukládaných dat pak nepotřebujete žádné další ORM, nebo CRM, nebo logiku někam dál šněrovat…

Google Chrome: dark mode v MacOS

Pokud běžíte na Mekovi, pak už určitě používáte MacOS ve verzi Mojave, a jednou z jeho největších novinek je určitě dark mode. Samotný MacOS můžete přepnout do tmavého módu a některé aplikace, jako například Safari, už také umí dark mode a vše vypadá skvěle.

Nicméně ne všechny aplikace dark mode už podporují. Jednou z těch, které skutečně denně používám a dark mode zatím neumí je Chrome od Googlu.

Dobrou zprávou je, že Google chce dark mode do svého prohlížeče implementovat během přístího roku. 

A ještě lepší zprávou je, že Chromium už dark mode umí teď 😀

Jak na to?

Chromium --force-dark-mode

Pokud budete chtít spustit Chromium v dark modu jen v případě, že máte aktivovaný dárk mode v MacOS, pak spusttě následovně:

Chromium --enable-feature=DarkMode

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 😀

MongoDB: $expr

MongoDB od verze 3.6 umí expressions, které, pokud jste je chtěli využívat, tak doposud jen přes agregační framework.

$expr vám umožní sestavit dotaz, ve kterém můžete porovnávat pole, klíče toho stjeného dokumentu v prohledávané kolekci, stejně jako $match v agregaci.

Příklad

Dejme tomu, že máme kolekci s následujícími dokumety:

A dejme tomu, že chceme s kolekce získat jen ty dokumenty, kde spent je větší než budget. To zní logicky a jednoduše, ne?

Špatná zpráva, tedy až doposud: bez agregace jen jednoduchým query tohle nejde.

Od verze 3.6 díky $expr ano 😀

Výsledkem pak bude následující pole dokumentů:

Holla!

Zdroj: MongoDB dokumentace

.prettierrc.json

Tento JSON stačí umístit do root adresáře projektu uložit do souboru .prettierrc.json

Mohlo by se hodit

Options
Konfigurační soubor
Ignoring code
ESLint integration
Watching changes

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.

Zrychlete si svého Maca

Pokud trpíte nedostatkem výkonu na vašem Mekovi, pak zkuste pár těchto triků, které mu pomohou trochu ulevit a ušetřit něco výkonu pro vaše aplikace.

Všechna nastavení se provádějí skrze terminál zadáním následujících příkazů:

Vypnutí animace oken

Vypnutí animace při změně velikosti okna

Vypnutí animace rychlého náhledu

Okamžité skrytí docku

Vypnutí animace při spouštění aplikace

Event driven

Abyste se někdy jednou mohli zabývat Event Driven Architecture, je dobré, abyste někdy před tím věděli, co je to třeba event, a že nutně nemusí znamenat jen třeba propagaci změny v DOMu, ale obecně jakoukoliv událost.

No a pokud se pohybujete na backendu a k tomu píšete jako já v JavaScriptu, či TypeScriptu, bylo by dobré vědět, že NodeJS má vlastní knihovnu Events.

Ale asi vůbec nejlepší ze začátku bude zkusit si, třeba i takto najivně, napsat svůj vlastní event driven kód. Třeba něco jako simulaci práce finanční burzy 🙂

Nepřekvapivým výsledkem pak může být toto:

Asi nejhezčím na tomto je, že logiku jak obchodníka, tak samotné burzy, můžete řešit zcela separátně a eventy řeší jen komunikační kanály mezi jednotlivými entitami. Celá myšlenka se dá silně rozvíjet a odměnou vám pak bude aplikace, která má úplně jiné parametry, chování, možnosti, než by vám nabídla nějaké mono-spagegy-super-truper-apka-se-silenou-sdilenou-logikou-a-modelem 😀

Je dobré vědět, že even driven nemusí být cloud, lambda funkce, nebo něco, na co si jako normální developer nesáhnete, ale můžete začít pěkně od sebe, bez jakéhokoliv frameworku, či externí knihovny.

MongoDB: ObjectID

ObjectID je výchozím primárním klíčem každého dokumentu ukládaného do MongoDB. Tento klíč _id je automaticky přidán driverem do každého objektu, který pošlete do databáze, pokud si jej tedy sami v objektu nenastavíte. Jinými slovy: pokud cokoliv uložíte do jakékoliv collection v Mongu, pak pokud sami nenastavíte klíč _id, bude automaticky vygenerován driverem.

Výhodou tohoto je, že _id je unikátní nejen na úrovni collection do které ukládáte, ale na úrovni celého MongoDB clusteru. To znamená ne jen nad tabulkou, nebo databází, ale hned nad všemi MongoDB servery do vašeho clusteru zapojenými. Je skvělé umět jednoznačně identifikovat dokument, data bez ohledu na tom z jaké tabulky přicházejí… 😀

ObjectID je jedním z datových typů dle specifikace BSON.

Podle oficiální dokumentace je ObjectID 12ti bajtová hodnota skládající se z následujících komponent:

  • Zleva první 4 bajty timestamp
  • Dalších 5 bajtů náhodný string
  • A poslední 3 bajty pak počítadlo startující náhodnou hodnotou

Podle neoficiální dokumentace, pak těch 5 bajtů s náhodným stringem se skládá z :

  • 3 bajtů, které specifikují stroj
  • a zbylě 2 bajty identifikují samontný proces na tomto stroji

Samotná funkce generující ObjectID je extrémně jednoduchá, a proto i velice rychlá.

Získat, či vygenerovat si ObjectID můžete i sami ve své NodeJS aplikaci velice jednoduše:

Nebo pokud holdujete Pythonu, pak třeba takto:

Nad samotným objektem pak můžete volat pár metod:

Tou nejzajímavější pak může být funkce generationTime, která získa z klíče jeho timestamp.

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑