1. Praktický test prakticky – Takhle ne

interview-icon

Pohovory jsou fajn a chodím na ně rád. I když zrovna nic aktivně nehledám a firmy si mě pouze pozvou jen „kdyby náhodou“, tak nemám nic proti oboustrannému rozšíření obzorů, jak to může fungovat jinde.

Mám rád, když jsou v uvolněném stylu a víc než pohovor připomínají malý dev meet up, kde se obě strany baví o tom co dělají, jak řeší různé výzvy a jak se můžou navzájem posunout dál. Pak většinou příjde na řadu praktická část a tu už tak rád nemám.

Čím to je? Programuji rád a výzvy v podobě zadání, při kterém jsem nucen rozšířit své know how, mám ještě raději.

Odpověď je docela jednoduchá, ale její pochopení a zároveň správné uchycení celé problematiky, už tak jednoduché není.

Read More…

Bez dockeru ani ránu

Docker_(container_engine)_logo

V článu Docker server snadno a rychle, kde jsem shrnul jednoduchý způsob, jak rozchodit hlídané docker kontejnery za pár vteřin, jsem nezmínil, jak moc důležitou roli v mém vývoji samotný Docker hraje, proč by si měl získat i vás a taky proč by měl být Dockerfile či Docker Compoer (možná kromě node.js) nedílnou součástí všech repozitářů vašich projektů.

Nebudu tu rozebírat milionkrát omílané tutoriály s hello wordy. Spíš se zaměřím na pár jednoduchých poznámek a rad, které mě nakonec motivovali natolik, že jsem na dockeru začal stavět téměř všechno nové a připravil na něm také vývojové zázemí pro všechny aktivní stávající projekty u svých klientů. Read More…

AMQP – Potenciál fronty bez bolesti hlavy

rabbitmq_logo

Žádná microservis architektura se dřívě či později neobejde bez přidání frontovacího systému. S tím ale souvisí velké utrpení, protože než člověk vstřebá veškeré know-how a poté si osvojí best practice, uplyne dlouhá doba a stejně nakonec neví, zda to napsal tak jak se má a sluší.

Jak jsem již psal v článku s mým balíčkem na loadování configů, tak z velké částí je prvotní motivací, pro vytvoření nového package, sjednocení a až pak méně časté inovování a shana vytvořit něco, co se bude používat, protože je to lepší, nové a cool. Z prvního důvodu vyznikl také můj balíček amqp-model.

V desítkách projektů, ke kterým jsem se dostal, byla stále omýlaná téměř stejná funkcionalita práce s frontami a exchangemi, ale pokaždé jinak pojatá a ve výsledku těžce uchytitelná.

Proto jsem se pokusil sjednotit všechny požadavky našich servis a výstupem je snadno použitelný NPM balíček, který má vše potřebné pro práci s AMQP protokolem.

Docker server snadno a rychle

Docker_(container_engine)_logo

Každý developer si při vývoji projektu musí položit dříve či později otázku, jak budou aplikace, které jsou jeho součástí, běžet. Při větších projektech je vhodné si postavit architekturu na Rancherovi a při těch úplně největších klidně celou automatizovanou flow na Mesosu s Maratonem.

Někdy je ale jasné, že toto by byl zbytečný overengeneering a uchýlí se k jednodušší, byť méně škálovatelné či ošetřené variantě. Mě osobně 90% projektů běží v docker containerech na několika desítkách VPS s tím, že jejich běh hlídá jediný supervisor s webovou adminsitrací a nic víc. Spousta projektů totiž nic víc ani nepotřebuje.

Proto se pro mě stalo docela rutinou, že jsem potřeboval na čistý VPS server nainstalovat docker, pak supervisor a taky vše ostatní, co je k tomu potřeba. Instalace probíhala většinou tak, že jsem do googlu dal vyhledávat jednotlivé tutorialy a pak jsem nakopíroval defaultní configy z jiných svých serverů. Všeho všudy práce na hodinu i s kafem.

Nicméně mě jednoho dne přešla trpělivost a práci, která se dala zautomatizovat jsem si našel nějaký čas navíc a zautomatizoval jsem ji. Vznikl script, který tuto rutinní práci udělá během pár minut bez nutnosti vyhledávat a copy/pastovat příkazy z tutorialů.

Celý repozitář i s použitím můžete najít zde: https://github.com/bouchal/docker-master-install

Nutno podotknout, že jak tomu zákon schválnosti chce, tak od doby co jsem ho napsal, jsem měl potřebu ho použít mnohem méně, než tomu bylo dřív.

NPM environmentconfig

DtHsMG5

Když jsem před několika lety začal pracovat pro větší společnosti, které už neměly problém vybudovat si docela obstojné zázemí pro správu, buildování, deploy a samotný běh několika stovek, až tisíců servis, začal jsem vnímat nesourodost mezi tím, jak každá jednotlivá servisa načítala svůj config na základě prostředí ve kterém běžela.

Jak už to tak bývá, tak většina servis běží v pár základních prostředích … produkce, development, test a localhost. Někdy je navíc stage nebo nesou zkratku místo celého názvu ( development => dev ).

Propracovanější nástroje potom také při deployi k projektu připojí „.env“ soubor, kde jsou například connection stringy, které by se neměly ukládat do repozitáře a nebo jsou součástí většího poolu, kdy je každý z nich přiřazený k několika servisám dle potřeby.

Z toho důvody jsem pro své potřeby vytvořil NPM package envitonmentconfig.

Hlavní goaly tohoto balíčku jsou:

  • Načítání .env
  • Parsování více formátů s přípravou pro jednoduché rozšíření na další pro další contributory
    • Prozatím CSON, JSON
  • Watherfall loadování configu
    • Všechno z konfigu produkce se promítne do developmentu, ale může být přepsáno
  • Vlastní definice prostředí
    • Jednoduché rozšíření o další prostředí než jsou jenom defaultní, případně jejich vlastní pojmenování