Rule the Slack! Do not let it rule you.

I noticed a while ago I have a problem with Slack. It is by far the biggest source of distraction at work for me. I work as a Tech Lead so I need to be among other things available to my team and to a degree on top of things. That implies following many topics, keeping the alignment, propagating information and correcting incorrect information. But then Slack makes it so easy to go down the rabbit hole of following and contributing to all kinds of conversations and before you know it the day is gone and little was done on the side of actual work. One may feel busy and useful and one can argue that a lot of people were helped but that is not what a whole day should look like. 

After reading Cal Newport's Deep work two years ago I restarted my efforts to have distraction free time for deep, focused work as that is where most value is created in engineering (planning every half an hour of the day up front helps a lot). I would also recommend actually doing the Eisenhower matrix (the urgent unimportant vs. the not so urgent but important) on a piece of paper and try to quantify what and why is so important or urgent. You may find that being on Slack does not score that high as the reality at times shows us.

Additionally, Slack does not make itself easy to ignore (probably by design). Even if you turn the notifications off a blue/red dot will lit on the tray icon. When you open Slack you will see "more unread" shining at you in all directions. Being used to zero inbox it does not come to me naturally to leave highlighted channels unopened and mentions of my name unread. So let's see what can one do to keep some level of sanity and work throughput with Slack being the main channel of communication in the company. 

How often?

The most important question to ask is: How long can a message stay unread? Five minutes, five hours, five days? If you say five minutes and truly believe that you cannot stay away from Slack for more than that you have a trouble I cannot help with. I believe that two hours is a reasonable number (people go for lunch and may have a meeting around lunch). Also I would highlight here our CPO, Georgie Smallwood, who's leading by example by having her Slack status set to "I check Slack once a day". So assuming you have a number you can adjust and try my current Slack routine:

1. Start the day by not opening Slack and working for an hour (One uninterrupted hour of work for free. Think of it as if you came one hour later to work).
2. Set timer for ten minutes.
3. Open Slack and check what's up. Since the time is running I join only conversations where I really have to.
4. Anything that is on fire so I need to drop my plans? If yes, check if it is really the case and if so do it.
5. Time is up. Close Slack.
6. Set timer for one hour.
7. Rinse and repeat.

Of course it does not work 100% as I also have meetings but it does help me create several blocks of time free of Slack interruptions.
One common failure mode is that I would open a Slack the moment I realize I need to write to someone. I make a note instead. It also gives my ten minutes on Slack purpose as I typically actually need to write to few people.

Which channels?

I would recommend leaving as many channels as you sensibly can and mute as many of the remainder as you can. Than star the few you want to really pay attention to.

How?

Just how to use Slack really? I am not alone in concluding there is a hell lot of noise over signal. It feels overwhelming trying to keep up with all the conversations. Actually, Slack allows you to have ten parallel 1-1 conversations while trying to follow up what's going on in 20 different rooms full of random people. Try to do any work in such a setting.

Curated channels

But one problem at the time. One thing one can actually do is to set ground rules for how people communicate in channels. Slack offers threading. That is great but if not curated it only helps with not having interleaving messages on different topics. It still makes you go through all the threads if you want to know what's going on. My ideal channel looks like this:

1. Any message is either standalone announcement or a start of a thread.
2. Start of a thread contains description detailed enough to know what is it about.
3. The person starting a thread is responsible for adding conclusion once discussion is over so every thread has a conclusion on it.

Then a channel is less busy and less noisy. I can choose to contribute to topics where I have something to say. I can see what was discussed and what was the outcome quickly. If I need more details I can read the full thread.

1-1 conversations.

It does not hurt to reiterate that Slack has this neat feature for calling including a video-call. I try to be mindful of the time I spend in a written conversation and where it is still useful to articulate better my points in written and have the time to think about the problem at hand or collect more data and where I should jump on a call. That also solves the problem of having several long conversations in parallel and constantly context switching as calls can help resolve them.

Summary

1. Turn it off
2. Follow only what you absolutely must
3. Curate channels
4. Call more often

I'm curious what other tips to tame Slack helped you. Feel free to leave a comment!

Žádost o český rodný list v Německu

Narození dítěte v Německu

Musím říct, že jsem doufal v lepší integraci v rámci EU, v sice větší, ale rozumnou administrativní zátěž spojenou s pohybem osob. Například přestěhování do Německa za prací bylo poměrně jednoduché - přihlásit k pobytu, přihlásit na pojišťovnu, a bylo. Před týden se nám narodil syn. Popíšu, co je třeba pro získání českého cestovního dokladu.

Naše situace je na první pohled jednoduchá, dva sezdaní Češi žijící méně než dva roky na území SRN.

Krok první - německý rodný list

V první řadě je třeba zajít na Bürgeramt a získat německý rodný list. K tomu je potřeba:

• Papír od Hebamme (porodní asistentky) se záznamem o porodu, ve kterém člověk musí vyplnit volbu jména, volbu práva, dle kterého se bude určovat příjmení (zajímavější u dívek) a přidat podpisy obou rodičů
• Do němčiny úředně přeložený oddací list
• Do němčiny úředně přeložené rodné listy obou rodičů
• Občanské průkazy obou rodičů (vyřizoval jsem sám, stačilo mít s sebou občanku od manželky)

Měli jsme nějaký problém s formulářem od Hebamme, takže jsem byl na úřadě dvakrát, ale pak mi paní na počkání vydala čtyři papíry:

• Potvrzení pro zdravotní pojišťovnu
• Potvrzení pro sociálku kvůli příspěvku na děti
• Potvrzení pro sociálku pro rodičovský příspěvek
• A konečně německý rodný list (10 euro)

Druhý krok - český rodný list.

Postupoval jsem dle informací na stránkách konzulátu:
zadost_o_vystaveni_ceskeho_rodneho_listu

Doufám, že mezitím článek, třeba i na základě mé zpětné vazby, vylepšili. Já jsem z něj pochopil, že potřebujeme k německému rodnému listu apostilu, obojí přeložit, přidat vyplněný nějaký formulář od ambasády a přijít. Ukázalo se, po výměně cca 10ti emailu s konzulátem (naštěstí paní reagovala velmi rychle), že formulářů je třeba víc a je to celé složitější.

Papíry

• Německý rodný list dítěte a apostila s úředním překladem (měli jsme od překladatelky s německým razítkem za 20 eur, jenže to pak konzulát doověřuje za 6 eur za stránku, tedy dalších 12 eur)
• Rodné listy obou rodičů
• Oddací list
• Občanské průkazy obou rodičů (v případě, že se nedostaví oba, tak kopii občanky absentujícího rodiče s větou "Souhlasím s pořízením kopie mého OP/CP" a podpisem)
• Formulář č. 6 (prohlášení o st. občanství zletilý) od obou rodičů
• Formulář "Osobní údaje", aby nás mohli kontaktovat, až obdrží z ČR vystavené dokumenty
• Zápis narození
• Žádost o zjištění občanství ČR a dotazník ditě do 15 let
• Dvě pasové fotky dítěte, pokud chcete rovnou zažádat o cestovní průkaz pro dítě

Plus dalších 20 euro - 12 za ověření občanství, 8 za rodný list.

Celkem, počítám-li apostilu, rodný list a jejich překlady zvlášť, je to 14 dokumentů. A na jejich získání a uznání jsme vydali 81 euro viz výše, plus 900,- Kč překlad rodné listy, oddací list z češtiny (v Čechách, naštěstí Němci neřešili české razítko, s německým by to stálo 3x42 euro), plus tisk.

Proces

• Získat apostilu - vyřizuje se na Friedrichstrasse 219, Berlin, na počkání, čekací doba cca 30 minut, cena 19 euro
• Přeložit rodný list a apostilu.
• Je třeba si smluvit termín. V emailu na termín je třeba uvést místo bydliště v SRN, neb referenti mají země mezi sebou rozděleny.
• Vyplnit několik formulářů.

Rodný list vyřizuje brněnská matrika a prý jí to trvá cca čtyři měsíce!!! (z doslechu jsem slyšel o dvou)! Paní na konzulátu říkala, že jim to chodí z celého světa a že toho mají moc. WTF. To jako když dělám v bance a budeme mít postupně moc klientů, tak jim řeknu, nezlobte se, ta příchozí platba vám bude zapsána za měsíc, máme toho moc? Ale prý to můžeme urgovat (kontaktní informace pro urgování - Brno - kontakt. Kontakt na paní vedoucí v Brně Iveta Palánová (iveta.palanova at brno-stred.cz), nám to při prvním pokusu nikdo nebral na žádném z těch telefonních čísel, tak jsme poslali email.

A teda rozumím, že německý úřad potřebuje přeložené rodné listy a oddací list, ale nechápu, že na konzulátu potřebují tolik papírů. Třeba osobní údaje, které jsou jen pro kontaktování, mohly být přidány do zápisu o narození. Dále nerozumím, proč musíme dokládat občanský průkaz a rodný list. Řekl bych, že údaje z občanky by úředníkům měly stačit na naši identifikaci a tedy dohledání čehokoliv dalšího nutného (mimo jiné sňatku, rodných listů, jmen prarodičů apod. - rozumím, že tyto potřebuje německý úřad, protože o nás nemá databázi údajů). Rovněž nerozumím, proč musí rodiče vyplnovat prohlášení o státním občanství. To tedy ČR není zpravena, když je mi uděleno jiné občanství? A kdyby ne, proč je to povinné? Přišel by mi rozumný default, že pokud máme jen to jedno české občanství, nemusíme nic dokládat. Navrch pak i paní na úřadě musí snad pětkrát vyplnit, že byla ověřena totožnost žadatele/prohlašovatele.

Sehnání všech dokumentů a podání žádosti nám i při dobré snaze trvalo necelé dva týdny (úřední hodiny na německém úřadě, dostupnost překladu, příprava všech papírů, termín na konzulátě) a to bydlíme v Berlíně, takže máme spoustu služeb dostupných či za bukem. Nicméně hlavní problém je, že nám brněnská matrika vyřídí žádost za čtyři měsíce. Očekával bych dva týdny, pochopil bych obvyklých zákonných 30 dní. Čtyři měsíce jsou naprostý nesmysl. (edit: matrika už sama navýšila počty zaměstnanců a doba by měla postupně klesat. Žádost však jde ještě přes ÚMČ Praha 1 kvůli občanství, takže celkově to bude stále cirka šest týdnů)

Takže odhadem rodný list dostaneme 5 měsíců po narození potomka (pro srovnání u prvního dítěte narozeného v české porodnici byl vydán rodný list za 6 dní od porodu a v ruce jsme ho měli záhy na to).

Proč je to problém

• Bez rodného listu se s dítětem nevyřídí vůbec nic
• Manželka je OSVČ a musí na pojišťovnu nahlásit do osmi dnů narození dítěte - nahlásila, ale bez rodného čísla se jim to nevejde do tabulek
• Nelze zažádat o český rodičovský příspěvek (na který je zpětná lhůta 3 měsíce)
• Manželka by ráda měla podnikání jako vedlejší činnost, ale na to je třeba mít vyřízený rodičovský příspěvek
• Nelze cestovat - nevydají nám pro dítě občanku ani pas - nemá rodné číslo. Tedy lze požádat na konzulátě o cestovní průkaz. Je na to třeba dvou pasových fotek dítěte a občanského průkazu rodiče. Termín dodání doplním, až ho získáme. Problém cestovního průkazu je, že slouží jen k jedné cestě směrem do ČR a ne už zpět.
• Zdravotní pojištění - zde naštěstí já jsem pojištěn v Německu a dítě bude se mnou v rodinném pojištění. Na to máme papír od Bürgeramtu a už máme registraci a měla by přijít kartička. Ale snadno může nastat situace, kdy dítě prostě nemá kartičku pojištěnce 5 měsíců - přičemž u takto malých dětí jsou návštěvy u doktorů prostě časté - prohlídky, testy, očkování, kašlíčky...
• Chceme na vítání občánků :)

Francie

Pro srovnání situace pro francouzské občany. (Kamarádka Češka má manžela Francouze, takže dcerka má obě občanství. Po přečtení článku na konzulátu zhodnotili, že francouzské papíry budou jednodušší a že začnou těmi.)

Potřebné dokumenty:

• Německý rodný list (bez překladu, bez apostily)
• Jeden formulář - 1 strana, na které je všechno potřebné
• Kopie občanských průkazů rodičů
• Pokud byla svatba méně než tři měsíce zpátky a francouzské úřady o ní neví, tak kopie oddacího listu
• Známka na 1.45 euro, aby jim mohli poslat rodný list dopisem

Pak si sjednali schůzku. Dali jim termín cca za 2-3 týdny. Požádali o rodný list. S potvrzením o požádání šli na pasové a požádali o pas. Za dva týdny měli doma pas a mohli cestovat apod. K tomu ještě doplním, že ani nepotřebovali pro německé úřady překlad svých rodných listů a oddacího listu. Teda paní se nezdál československý rodný list kamarádky, ale její muž jí řekl, že bez připomínek uznala jeho francouzský a ČR je přímý soused Německa a bylo. Takže celkový náklad 10 eur za německý rodný list a 1.45 za známku... (O české občansví pak zažádali v Čechách a platili 100,- Kč a papírování bylo o řád menší).

Ideální stav

V ideálním případě bych tedy očekával následující.

Papíry:

• Německý rodný list (bez překladu neb nežádáme v Burundi, ale v zemi Evropské unie a němčina je oficiální úřední jazyk - mimo jiné na spoustu úkonů s prvním dítěte po přestěhování do Německa Němcům stačil český rodný list). Plus Němci umí vydat rodný list i v jiných jazycích (angličtina, francouzština, španělština, polština a možná nějaké další)
• Formulář (jeden) s kontaktními údaji, a dalšími nutnými informacemi plus podpisy obou. (Pravděpodobně bude třeba několika verzí formuláře podle situace rodičů, ale čekal bych 2-3 verze). Formulář je zároveň žádostí o občanský průkaz nebo pas (jen se zaškrtne volba) - v zahraničí bych řekl vždy člověk potřebuje krom rodného listu i doklad
• Můj občanský průkaz (event. kopie občanky manželky s podepsaným souhlasem k jejímu pořízení)

Proces:

• Získám německý rodný list
• Napíšu na konzulát o termín s popisem kde bydlím a v jaké jsme situaci (např. dva sezdaní Češi)
• Pošlou mi příslušný formulář
• Vyplním a přijdu ve sjednaném termínu

Nejpozději do měsíce si budu moct vyzvednout rodný list a občanku/pas. Po úplnost dodávám, že jsem první napsal ideální stav, a pak dostal přesnou informaci o francouzském procesu, shodou okolností vypadají hodně podobně...

Postupné řešení s českými úřady

Urgence na matrice v Brně

Tak v prvé řadě jsme zkusili (dle doporučení konzulátu) urgovat na matrice v Brně. Psala manželka:

Dobrý den paní Palánová,

XY jsme podali žádost o vystavení českého rodného listu pro syna Jméno Příjmení - nar. dne XY v Berlíně na berlínském konzulátu.

Ráda bych se zeptala, kdy a jak nám bude rodný list doručen?

Potřebovala bych jej co nejdříve, neboť je na český rodný list navázána žádost o rodičovský příspěvek, také jsem měla do 8 dnů od narození nahlásit změny na zdravotní pojišťovně a správě sociálního zabezpečení kvůli mému podnikání, kde potřebuji nahlásit podnikání jako vedlejší činnost. V neposlední řadě chceme se synem jet na Vánoce do ČR a bez rodného listu nemůžeme požádat o občanský průkaz a konzulát nám dokáže vystavit pouze cestovní průkaz, který je jednosměrný, takže bychom se neměli jak vrátit. (V Německu trvale žijeme, manžel zde pracuje.)

Mám očekávat standardní lhůtu 30 dnů na vyřízení nebo to stihnete dříve?

Děkuji a jsem s pozdravem,
Podpis

Už se nám dostalo i odpovědi:

Vážená paní XY,

Vaše podání zaslal konzulát nejdříve na ÚMČ Praha 1, Vodičkova 18, za účelem vystavení osvědčení o státním občanství České republiky dítěte. Po vystavení osvědčení nám ÚMČ Praha 1 postoupí spis k vystavení českého rodného listu dítěte.
Z důvodu velkého nárůstu doručených žádostí a nedostatečného personálního obsazení jsou bohužel v současnosti doručená podání vyřizována na zvláštní matrice v delších než zákonem stanovených lhůtách, kdy není možné jednotlivá podání jakkoli upřednostňovat. O termínech vyřízení pro jednotlivá podání je možné informovat se přímo u pracovnice zvláštní matriky, která bude mít Vaše podání v řízení. Kontakt na příslušnou pracovnici jsme schopni zjistit až po doručení podání z ÚMČ Praha 1, tj. cca za měsíc.
Rodný list bude po vystavení doručován dle požadavku berlínského konzulátu v průvodním dopise, tj. dle Vaší domluvy s konzulátem.

S pozdravem

Iveta Palánová
pověřena vedením oddělení zvláštní matriky

Tedy české úřady si to nedělají jednoduché a věc se ještě zdrží na ÚMČ Praha 1. Plus matrika dle všeho postráda pružnost z hlediska personálního a díky tomu není schopna dodržet zákonné lhůty. Nemluvě o tom, že paní Palánová musí trávit čas odpovídáním na náš a pravděpodobně mnohé další dotazy.

Po doručení z ÚMČ na matriku 13. 11. jsme dostali kontakt na paní, která bude naši žádost vyřizovat. Manželka jí napsala dotaz, jak a kdy nám bude dopis doručen (obávali jsme se, aby se nezdržel třeba cestou přes konzulát), že jej potřebujeme brzo z důvodů výše uvedených a jestli jej stihne matrika vydat v zákonné 30-ti denní lhůtě. Brzy nám přišla odpověď:

Dobrý den paní XY,

pokusím se aby rodný list byl vystavený ve lhůtě do 30 dnů, dřívější termíny opravdu nejsou možné, protože naše lhůty se nyní pohybují okolo dvou měcíců zdůvodu zahlcení.

S pozdravem

podpis
matrikářka

Ministerstva

Ministerstvo zahraničních věcí

Dále jsem se obrátil s prosbou o zlepšení procesu na MZV. V podstatě jsem je odkázal na tento článek. Moc jsem od toho nečekal, ale záhy se mi dostalo odpovědi:

Ministerstvo zahraničních věcí České republiky
Čj. 312195/2017-K4

Vážený pane Burkerte,

obdržela jsem Váš dopis zaslaný elektronickou poštou dne 5. 11. 2017, který se týkal výtky na komplikovanost řízení ve věci zápisu narození do zvl. matriky Brno a vydání cestovního pasu pro Vašeho syna na velvyslanectví ČR v Berlíně.

Dovolte, abych Vás informovala, že jsme si vědomi složitosti a mnohokrát i zdlouhavosti při vyřizování osobních dokladů občanů ČR. Česká velvyslanectví jsou však v této oblasti vázána stávající právní úpravou, která není vždy tak flexibilní, jak by bylo častokrát žádoucí, zejména ve vztahu k občanům, žijícím v zahraničí. Ujišťuji Vás, že je naši snahou poskytovat občanům ČR co nejlepší pomoc a konzulární služby. Proto i v jednáních s jinými rezorty upozorňujeme na potřebu změn v některých oblastech legislativy, které by zohledňovaly specifika postavení občanů žijících v zahraničí.

Pokud jde konkrétně o Vaši žádost, informuji, že gestorem shora uvedené problematiky je Ministerstvo vnitra ČR, konkrétně odbor všeobecné správy (agenda státního občanství a matrik) — mailová adresa: ovs(at)mvcr.cz a odbor správních činnosti (agenda osobních dokladů) — mailová adresa: osc(at)mvcr.cz . Doporučuji proto obrátit se na tyto odbory. Věřím, že tuto moji odpověď přijmete s pochopením.
S pozdravem

JUDr. Markéta Meissnerová
ředitelka konzulárního odboru

Ministerstvo vnitra

Dle doporučení z ministerstva zahraničních věcí jsem se tedy obrátil s prosbou o zlepšení procesu na ministerstvo vnitra na příslušné dva odbory. Odpovědi doplním.

Ministerstvo vnitra

Z ministerstva vnitra mi jako první přišla odpověď k dlouhým termínům zvláštní matriky v Brně od vedoucí brněnské matriky:

Vážený pane Burkerte,

dovoluji si odpovědět na Váš emailový podnět ve věci žádosti o český rodný list v Německu a to v části dotýkající se činnosti zvláštní matiky, když mi tento Váš emailový podnět byl z MV ČR doručen dne 22.11.2017.

Působnost zvláštní matriky a provádění zápisů do zvláštní matriky a následné vystavení českým matričních dokladů je mimo jiné upraveno zákonem č. 301/2000 Sb., o matrikách, jménu a příjmení a o změně některých souvisejích zákonů, ve znění pozdějších předpisů. Kdy je nezbytné, aby jsme se jako správní úřad vykonávající státní správu v přenesené působnosti při své matriční činnosti tímto právním předpisem řídili a požadovali předložení zákonem stanovených dokladů (když úprava právních předpisů není v kompetenci našeho úřadu).

Zvláštní matrika se od roku 2014 dlouhodobě potýká se značným skokovým nárůstem podání žádostí o zápis do zvláštní matriky způsobeného především změnou právní úpravy nabývání státního občanství ČR k 01.01.2014 (kdy u všech osob které nabyly státní občanství ČR a jejich matriční událost /narození, uzavření manželství nebo partnerství/ nastala v cizině musí dojít k zápisu matriční události do zvláštní matriky). Náš první předpoklad z roku 2014, že se jedná o jednorázové navýšení agendy byl bohužel mylný a tak jsme i vzhledem ke skutečnosti, že příspěvek ze státního rozpočtu na výkon zvláštní matriky byl dlouhodobě nedostačující a naše městská část hradila část nákladů spojených s výkonem zvláštní matriky z vlastního rozpočtu (byť se jedná o tzv. "čistý" výkon státní správy s působností pro všechny občany ČR), požádali o navýšení neinvestičního transferu ze státního rozpočtu, které by nám umožnilo navýšení počtu funkčních míst na zvláštní matrice. K tomuto navýšení finančních prostředků došlo k 01.01.2017. Jelikož jsme měli toto navýšení finančního transferu avizováno předem, probíhala již koncem roku 2016 výběrová řízení na obsazení pracovních pozic matrikářek zvláštní matriky. Všechna nově zřízená funkční místa se podařila obsadit do konce května 2017. Žádná z nově přijatých pracovnic neměla splněnu kvalifikaci pro výkon funkce matrikářky, kterou je ze zákona zkouška odborné způsobilosti k vedení matričních knih a k plnění úkonů zabezpečovaných v souvislosti s vedením matričních knih a sbírek listin (dále jen "zkouška"). Ve spolupráci s Magistrátem města Brna, který je příslušným úřadem provádějícím předmětnou zkoušku pro náš úřad, jsme zajistili přípravu a složení zkoušky u nových pracovnic v co nejkratším možném termínu a tak dvě pracovnice složily zkoušku koncem měsíce května a dvě v měsíci říjnu. Tím došlo k úplnému navýšení počtu funkčních míst matrikářek, i když jejich další zapracování a získávání praktických odborných zkušeností samozřejmě bude nadále pokračovat, jelikož výkon funkce matrikářky zvláštní matriky vyžaduje velmi odborné a specifické znalosti.

Náš matriční úřad si je vědom dlouhodobě nastalé neuspokojivé situace (nepřiměřeně dlouhých lhůt pro vyřízování podání doručených zvláštní matrice) a snažil se ji řešit již v minulost navýšováním počtu funkčních míst, kdy v letech 2013-2016 byly náklady s tímto spojené hrazeny především z rozpočtu městské části. Při navýšení počtu funkčních míst o 3 pracovnice, bylo v roce 2016 vyřízeno o 41% matričních podání více oproti roku 2013.

Závěrem přijměte mé ujištění, že personálnímu obsazení zvláštní matriky věnujeme dlouhodobě zvýšenou pozornost a péči, a že všechnny pracovnice zvláštní matriky přistupují k vyřizování matiční agendy zvláštní matriky zodpovědně a s maximálním pracovním nasazením.

Dle mé emailové komunikace s Ministerstvem vnitra ČR Vám bude v části Vašeho podnětu, systémových opatření, (pokud se tak ještě nestalo) odpovězeno z úrovně MV ČR.

S pozdravem

Bc. Markéta Tintěrová
vedoucí odboru matrika

Úřad městské části města Brna, Brno-střed

Tedy dobrá zpráva. Personální obsazení zvláštní matriky by mělo být už zlepšeno a postupně snížit čekací dobu pod zákonnou 30-ti denní lhůtu. Raději bych však byl pro zlepšení, zjednodušení procesu jako takového.

Ministerstvo jsem urgoval o odpověď. Nakonec přišla (20. 12. 2017). Bohužel není moc povzbudivá.

Dobrý den, na základě Vašeho e-mailu ze dne 18.12.2017 Vám sdělujeme následující:

Děkujeme Vám za Váš podnět, Ministerstvo vnitra v současné době nepřipravuje v této oblasti novelu právní úpravy zák. č. 301/2000 Sb., o matrikách, jménu a příjmení a o změně některých souvisejících zákonů, ve znění pozdějších předpisů.

K tomu dodám snad jen, že zákon je z roku 2000 a vstup do EU v roce 2004 změnil situaci. Řekl bych, že i tak by mohl být postup obecně jednodušší (i pro země mimo EU), ale v rámci EU by měl být proces blízký tomu v ČR. Tedy s cílem dodat rodný list třeba do sedmi dnů.

Máme rodný list

Tak 15. 12. 2017 dorazil rodný list! Hip, hip, hurá. Dorazilo s ním i potvrzení o státním občanství platné jeden rok. Ehm... Nechápu. Nevadí. Každopádně list máme. V ČR přes Vánoce zažádáme o občanku (možná tam užijeme to potvrzení o občanství?) a snad dobrý.

Ministerstvo vnitra ČR se mi stále neozvalo (edit, 20. 12. jsem dostal odpověď). Jdu je urgovat a případně se jde za politiky. 8 týdnů od narození je možná nový český rekord, ale vyhovující mi to nepřijde. Například nerozumím, proč není matrika přímo na konzulátě. V Německu žijí desetitisíce Čechů (někde jsem četl cca 60 tisíc) a matrika na konzulátě není. Zato je samostatná matrika i v sídlech jako je Světlá Hora s 1400 obyvateli...

Ansible and Vault

Let's start with a cliché. Everyone agrees that security is important, right? We work on deployment process and we need to get secrets into the system securely. Secrets can be passwords and private keys, for instance.

We use Ansible for configuration management so we started with ansible-vault. It has some drawbacks so we found a compelling contender - Vault made by Hashicorp. I would like to describe how we made Ansible work with Vault.

Ansible

Ansible (https://www.ansible.com) - automation for everyone. Dubbed as the most developer friendly automation tool it sports easy syntax, it is simple to translate from what devs are usually most acquiented - Bash - and it runs masterless so one does not need a special master node to handle updates like in cases of Chef and Puppet. The learning curve is favorable.

Vault

Vault (https://www.vaultproject.io) - a server application for storing securely secrets and to allow access to them via remote API. It supports host of features like access tokens, fine-grained access rights, auditing, revoking only secrets which were compromised, certificates provisioning on demand and more.

Running Vault

We use Vault in development configuration since setting up production Vault is more complicated and hard to automate by nature. Development configuration suffice to get you started.

We will provision it locally with Ansible and we will directly set it up with some access policy, enter secrets and get a token which will give us read-only access to some of the secrets.

The structure will be following:

A simple playbook that invokes the vault role.
vault.yml:

It can be invoked with ansible-playbook vault.yml.

We leverage that we are working with Docker (v1.12.5) and we use Ansible Docker integration (available in Ansible v2.2). We deploy official Vault image on Docker first and then perform operations on it.
The steps are:

• Run the image with Docker.
• Get the image logs.
• Grep them for the root token.
• Run the setup-vault.sh.
• The script outputs an access token for the specified read policy and we save it to ~/.vault-token file where the Ansible Vault lookup plugin expects it.

The setup-vault.sh script:

The setup creates the access policy, enters two secrets and creates a token which has the aforementioned policy so one can only read these secrets with the token.

The read-policy.json:

You can check the setup works by running:

• export VAULT_TOKEN=$(cat ~/.vault-token) - to export the file content to env variable.
• curl -H "X-Vault-Token: $VAULT_TOKEN" localhost:8200/v1/secret/app/test/ldap-pwd. - to hit the Vault API.

Ansible with Vault

Now that we have Vault up and running let's get secrets into Ansible. It is surprisingly easy thanks to the good work of Johan Haals on his ansible-vault lookup plugin (https://github.com/jhaals/ansible-vault). I would say that the name is confusing (being the same with ansible-vault tool) but other than that the plugin works very well. I also read that the chances are the plugin will make it into Ansible so you wouldn't have to install it manually.

ansible-vault installation

Let's say we stick with default Ansible plugins' location as outlined in the configuration.

• sudo mkdir /usr/share/ansible/plugins/lookup
• sudo vim /etc/ansible/ansible.cfg and uncomment the line lookup_plugins = /usr/share/ansible/plugins/lookup.
• sudo git clone https://github.com/jhaals/ansible-vault.git /usr/share/ansible/plugins/lookup/ansible-vault

Well, you're done!

Retrieving Secrets

In our case we have configuration templates and we want to replace hard-coded secrets with lookup. A typical template in our case is an XML file or a properties file. It may look like this:

We put the password in Vault and modify the template:

Ansible template_module uses Jinja2. We wrap variables in {{ }}. We put in the lookup call where we invoke our freshly installed vault lookup plugin.
We can also see how to use variable within Ansible lookup. Simply put it without any quotation. In case you need some literals around it like we do, concatenate it with +.

The last step is to use to invoke the template module from a playbook:

And the role:

The source application.properties can be found in the /files.

That's it! Personally, I struggled a bit with Vault setup, its API calls syntax. But the documentation was helpful and once I had that running making Ansible use Vault was very smooth.

Building Docker Images with Packer and Ansible

I recently worked on a project where we were explicitly asked to combine these three technologies. While I'm not hundred percent convinced it is the right pick for the customer it may be useful in some cases so I'll outline how to use them together.

Let's start with what they are.

Docker

Docker (https://www.docker.com) - build, ship, run. It is a tool made for running many small services. It replaces now common paradigm of hardware with VMs with containers in the operating system. It is useful when developing microservices, a generic service oriented architecture or when one has a few dependencies of the system and wants to decrease the dev-prod disparity and have it all the same from bottom up.

Packer

Packer (https://www.packer.io) is a tool for creating machine and container images for multiple platforms from a single source configuration. The configuration is excodessed with a set of provisioners which can be any combination of shell, Chef, Puppet, Ansible, Salt, you name it. The target platform is excodessed with a build. One can provide multiple builders at once though I guess it won't be as straightforward but we will get to that.

Ansible

Ansible (https://www.ansible.com) - automation for everyone. Dubbed as the most developer friendly automation tool it sports easy syntax, it is simple to translate from what devs are usually most acquiented - Bash - and it runs masterless so one does not need a special master node to handle updates like in cases of Chef and Puppet. The learning curve is favorable.

Why Would One Use Combine Them?

In our case we have a few services (2-5) which need some other services (LDAP, RabbitMQ, database) and need to be highly available (so everything needs to run at least twice and an ambassador pattern comes in handy). There is also a DMZ part with reverse proxies for SSL termination and loadbalancing. We have tens of environments but there are probably three categories of these environments and then they differ only in secrets - database, passwords, certificates. The rest can be configured using convention over configuration. We decided to bake the environment specific configuration into our images at the deployment time.

Now we need to build the Docker images we deploy. We already knew Ansible and as it turns out one can leverage that knowledge (and the Ansible tools like templates, Vault plugin, and more) to configure and to some extent build Docker images when one employs Packer. Another reason is that the customer is not hard set on Docker and may turn to AWS for instance. Then, so far teoretically, part of the job is done and we only need to configure another builder.

I would say it may also be handy for operations in bigger organizations where they need to maintain base images used by several teams with different target platforms. Then one may be able to output different images on demand relatively smoothly. Also one may leverage different provisioners (like all the main four - Chef, Puppet, Ansible, Salt) if say security team one and sysadmin team likes the other.

Anyway, for us it was requirement and this is how we made it work.

Putting Things Together

In our case we have a Packer configuration that contains Ansible provisioner and Docker builder. packer build first starts the base image in local Docker engine, then runs Ansible provisioner on it and then can tag the resulting image and push it to a Docker registry.

Packer

Packer is configured with a json file. The build is then started with packer build config.json.

In our case it looked like this:

Let`s go over it section by section since it was not as evident to figure it out.

Variables

• One need to declare any variable that will be used in the config even if it is passed as a parameter. The parameters are passed into the build like this:
  packer build -var "env=$ENV" configure-web-app.json
• Variables are referenced in the Packer configuration with {{user `app_version`}} placeholders.

Provisioners

• type ansible for saying we will use Ansible. Sounds obvious but there is also ansible-local which invokes Ansible on the image but then one needs to install Ansible on the image.
• playbook_file - references an Ansible playbook. The path is relative.
• groups - needs to match with hosts in the playbook.
• extra_arguments - here one passes variables that get into the playbook as well as some Ansible related configuration. The particularly hard ones were:
  • ansible_connection="docker" since the default is ssh and the documentation around Docker does not even mention another type.
  • ansible_user="root" since otherwise it throws some weird error and one finds the right answer in some bug reports. Again, sadly, not much help in the documentation.

Yes it is annoying to have to enumerate all the variables. We assume that the ansible_connection and _user would have to be overridden to something else for other builders.

Builders

We use only the Docker builder. We define:

• image - the base image to start from.
• run_command - it may look cryptic at start but these are just parameters to invoke docker with. The result would look like: docker -dit --name default run my-registry/web-app:1.0.42 /bin/bash. Hence it will not output standard output (-d/--detached), it will run interactive (-i/--interactive) so it will not terminate immediately, it will allocate pseudo tty (-t/--tty), the container will be named default so you know what to remove if you terminate Packer in the middle of the run, the base image will be what you've specified. It will run Bash.
• commit - means the image will be commited (Packer does not say really what that means) but it can later be tagged and pushed so I assume it will be commited to the docker engine harbor or how they call the store of built images.

Post-processors

Post-processors allow you to say what should happen with the build result. We tag the image and push it to the local repository where it is picked up by the deployment (docker-compose).

Ansible

We should mention that running Ansible implies Python has to be installed on every image built which may bloat them a bit.

An Ansible playbook can be something simple like: The role tasks/main.yml can contain following:

Just a bit on what we are doing. We deploy a Java Spring web application running on Tomcat so the deployed image is based on a base image with Java, Tomcat and some helper scripts installed (like wait-for-it.sh). Then we add the application WAR file and configuration like environment properties or logback XML.

Since the configuration may differ for different usecase a bit we support different profiles. It may also as application evolves so it needs to be versioned. As I discussed here I find it useful to have such configuration separated from the source code so I used Spring Cloud Config Server backed with a Git repository (Spring Cloud Config example).

Secrets - Vault and ansible-vault

There are people who don't like secrets in Git in plaintext. We found so far two ways to do it:

• ansible-vault - a built-in tool in Ansible that allows encrypting and decrypting files.
• Vault (by Hashicorp) - an application that is storing securely secrets and allows access to them via remote API. It supports host of features like access tokens, fine-grained access rights, auditing, revoking only secrets which were compromised, certificates provisioning on demand and more.

Ansible-vault

Any file can be encrypted with ansible-vault encrypt file. ansible-vault also supports operations edit and decrypt.

If you look at our Ansible role at include secured variables task it references a file in files folder with name like sec-vars-my-env-5.yml which is encrypted with ansible-vault. When Ansible encounters such a file it decrypts it and then uses it. The password can be provided manually but to avoid having it floating around in commands one can specify a password file. Have a look in the Packer configuration JSON for --ansible-vault-password-file option.

The downside of ansible-vault is that one can use only one file to secure all files in one context - so the most fine-grained it gets is one password for every environment if there is no generic encrypted file for all of them. Also there is hardly any auditing of changes since one can only tell the file was changed. One can only dream about revoking someone's access etc.

So we used it only to showcase we can secure some parts of the configuration and it also helped us identify what all needs to be secured.

Vault

We are yet to probe in the Vault direction so there may be another post about that. I think it is also not relevant for this post.

Issues

Combining few tools with different abstraction inevitably introduces some problems.

Building Debian-based Image on CentOS

For instance, we work for a big company who provided us with VMs with latest CentOS. We run locally mostly Debian based distros. Everything works fine. At some point we need to build an image on such a host. Now one may want to install a package in the Ansible role. The base image is Debian. The build fails with:

Internet is silent. Digging did not help so I had to resolve to thinking and documentation :) Turns out Ansible's package module abstracts from different package managers but under-the-hood uses its modules like apt or yum which then call real apt-get or yum. But there is a catch - the apt module requires python-apt and aptitude on the host that executes the module. In our case the CentOS host. So our builds run only if underlying host has the right architecture. Well, we can (and did) revert to Dockerfiles for these kinds of tasks but it breaks the whole abstraction. We can also probe ansible-local Packer provisioner since it runs on the very machine it configures.

The Documentation Could be Better

Case in point, the whole setup of the magic of Packer config. When it is set up it's done for good but the lack of documentation on things like ansible_connection and ansible_user may repel some right at the very beginning.

Proxy

How to run a Packer with Docker behind corporate proxy? Well, so far we don't know and we resolved to run these tasks with plain Dockerfiles running docker build --build-arg http_proxy which propagates the system proxy setting to Docker for image build.

Using Spring Cloud Config Server

Problem definition

I have already described why do we need external configuration management.

In short, let's say we have several environments (production, simulation, test). As the development goes we run different versions of our application on these environments. Part of the configuration of the application is specific to an environment and may change out of sync with our releases. So it is bound to the application version and the environment but should not be stored in the same repository as the code.

We used to have a tool to handle such external configuration management but since it was in-house developed and I moved away from that company I would have to write it from the scratch. We also made some design mistakes (detailed in the aforementioned blog post). So I looked around and found Spring Cloud Config server which can be backed with Git repository to store configuration. The beauty of having Git repository for configuration is that every configuration change is tracked and hence audited. Also tools to edit the configuration are already out there - file managers, IDEs, text editors. Moreover it should be easy to set up since it is just a Spring Boot application.

Spring Cloud Config

I gave it a try. I created a project which has only the dependency to Spring Cloud Config. I set the URL to the Git repository with configuration, deployed it and was ready to go.

pom.xml

    4.0.0

    com.company
    config-server
    1.0-SNAPSHOT

    
        
            org.springframework.cloud
            spring-cloud-config-server
            1.1.2.RELEASE
        

        
            org.springframework
            spring-core
            4.2.6.RELEASE
        
    

    
        config-server
        
            
                org.springframework.boot
                spring-boot-maven-plugin
                1.4.0.RELEASE
                
                    true
                
                
                    
                        
                            repackage
                        
                    
                
            
        
    

application.properties

server.port: 8888
spring.cloud.config.server.git.uri: ssh://git@hostname:1111/our-app-config.git

The server supports API calls like

• /{application}/{profile}[/{label}]
• /{application}-{profile}.yml
• /{label}/{application}-{profile}.yml
• /{application}-{profile}.properties
• /{label}/{application}-{profile}.properties

One can also provide an Accept header to get for instance binary file:

-H "Accept: application/octet-stream"

.

Versioning

Since we strive to get continuous delivery working the version is assigned with every commit. Consequently, any commit can be deployed up to production. This version is derived from the last annotated tag (e.g. 1.0), number of commits since then, and the commit SHA. It may look like: 1.0.42-gda31562.

We have four environments:

• Test - for our testing
• Acceptance - for customer testing
• Simulation - production hotfixes
• Production

And two external configuration files:

env.properties - environment specific properties
logback.xml - Logback configuration

We use Ansible for automating the deployment. It places these two files to the lib folder of Tomcat.

The configuration Git repository that is used by Spring Cloud Config contains these files in the root folder:

env.properties - with defaults
app-acc-env.properties
app-simu-env.properties
app-prod-env.properties
app-logback.xml
app-prod-logback.xml

Ansible makes API calls like: http hostname:8888/app/acc/master/app-env.properties to retrieve app-acc-env.properties from master branch. So far so good.

Branching

Ansible can either ask for master branch and get the latest configuration (we use that to deploy local builds to 'test') or it can use the 'label' to get configuration for specific version (hence we use version as a 'label'). That forces us to create an annotated tag everytime we release to the Artifactory - so everytime we release to acceptance or higher.

If ever we need to change the configuration for a version we convert the tag for that version to a branch and make changes on the branch.

Changing Configuration

We expect there will be two scenarios:

• One needs to add/modify a property because of a new feature, new code. Then we can commit the changed configuration to master branch in the configuration repository. When the next version with the change is released the property is there. That is also one of the main benefits of having the external configuration management.
• One needs to change a property for running version on one or more of the systems. Then it gets a bit tricky. Let's say we have tags: 1.0.0, 1.0.10, 1.0.25, and 1.0.40 I have 1.0.10 running in production and want to set say new email server URL. Then I need to convert tags 1.0.10, 1.0.25 and 1.0.40 to branches and make my change in all the three branches. That may get rather annoying eventually especially if we do not release to prod often and there are many tags.

Problems

The main problems I see with this approach are:

• The need to tag every release.
• The need to change potentially many of these tags - convert them to branches and perform the same modification.

Our versioning scheme produces monotonously increasing versions (with slight caveat for branches but we deploy to customer facing environments only from dev branch which mitigates this issue). Hence in our case these problems can be solved with the notion of version ranges. If I have versions 1.0.0, 1.0.10, 1.0.25, and 1.0.40 and there was no configuration change since 1.0.0 I will have just the one configuration for version 1.0.0 and it will be used for all the versions. If I introduce configuration change in 1.0.42 I create next version of configuration but everything in between will still get the configuration for 1.0.0. When I need to modify some property from version 1.0.25 I can create branch from the version bellow - 1.0.0 - and change it there. Then even 1.0.40 would get this change. Out of luck for 1.0.42 but at least I would not need to change the setting in too many places.

I'm new to Spring Cloud Config so maybe I missed something obvious. Let me know your thoughts.

Benefits

• Configuration can be altered outside of the release cycle of the code.
• Configuration changes are audited and documented (with commit messages).
• It is possible to look up what the configuration was at the point of the deployment - the deployment script logs time of deployment and version so one can look up corresponding configuration.
• We don't need to think about all the configuration changes necessary for given release since they are performed in advance and then updated as the changes occur and not at the point of the release.

SonarQube Integration Test Coverage with Cargo plugin

I already described how to get integration test coverage into your Sonar when your application runs on Tomcat here. I came to a project that uses Cargo Maven plugin to deploy the app on a Tomcat for integration tests. I wanted to see how much these tests actually cover. The answer to that turned out to be 'not that much really' but I'd like to share with you how to adjust configuration of the Cargo Maven plugin to make it work with Sonar.

Let's go.

Sonar properties

So in our case we have a multimodule Maven project. In order to collect usage over the project just set following sonar properties:

The default configuration puts jacoco.exec in the target of a module. We want to collect code coverage over several modules (including cases when code from one module calls code from another module) so we have to put Jacoco output files up the folder hierarchy and configure Jacoco plugin to append to these files.

In order to collect integration test coverage from deployed app we configure the Jacoco offline instrumentation to get a WAR file with instrumented classes. Jacoco agent deployed along with the war can then collect coverage data to specified file.

Jacoco Offline Instrumentation

The Sonar profile which configures offline instrumentation in the main pom looks pretty much the same as in the previous blog post:

Cargo plugin

Cargo plugin needs to deploy jacoco agent jar along with the application WAR. It also needs to set system property for jacoco-agent.destfile so that the agent can write collected coverage data to it.

Then just run:

Enjoy!

Why do we need a configuration management tool?

I spent some years developing web applications in Java for the corporate world. The apps always used some webcontainer or application server and we used different staging environments to show our work to testers, managers and customers before we went to production. Unfortunately, there are always some differences between these environments, be it a feature turned off or a database password or a mail server URL. So one needs to provide, ideally external, configuration file for every environment.

The usual way to do that few years ago was to define whatever configuration necessary, place it on the server and be done with that. In our case we put a logback.xml and an app-env.properties to the lib folder of Tomcat. Whenever a property is introduced or needs a change one asks a fellow ops guy and he performs this change on the day of the deployment. It worked most of the time but there are couple obvious issues with this approach:

• Error-prone – typos, missed changes, missing properties.
• Unknown configuration – in corporate world it is the ops who have access to production so there is no way to know the actual content of a configuration file for a poor prod-issue-solving developer.
• Impossible full deployment automation – since a manual step is needed from time to time.

We lived with these downsides for a while, suffered some break downs of the app, or the RabbiMQ broker (our OPS never really embraced the 'infrastructure as a code' principle), or a broken database. Ultimately, the change came along and we started the internal DevOps pilot. One goal was to do automated deployments. Now you can write a script that stops a Tomcat, copies over the war and starts it, you can use Flyway or other database migration tool and run a command to do the database migration for you, but what about the external per environment configuration?

Surprisingly, lot of people I talked to thought that configuration is easy. You just check in the version control system the configuration changes along with the feature. I believe they miss couple interesting corner cases. Let's use an introduction of a mail server as an example. A developer implements first feature which sends emails. He tries it out locally with a postfix server and adds mailServer.url property and wants to check it in but:

• The value is not known for all environments as ops may be able to provide you the right mail server URL weeks (and I saw months:)) after you've finished the ticket.
• The value may change in the future.
• Additionally, the value should be there only since the very first version which includes the commit.

If you want to get close to continuous delivery you may want to maintain that any commit that builds successfully can be delivered up to production. But then again, where and how should you store the configuration?

Given the example above we concluded that the configuration files have different lifecycle from the code. They are changed at different times. Moreover, they are shared between dev and ops teams since they both maintain certain parts of the configuration.

We decided we needed a configuration management tool with following properties:

• The deployment tool can get from it a zip file via an HTTP GET call. The tool provides project name, environment name and version.
• The zip contains all files in the correct structure that can be extracted to a designated folder.
  • e.g. /lib/certificates/server.jks
    /lib/logback.xml
    /lib/application-env.properties
    /conf/server.xml
• Only authenticated users can change files.
• Every action is audited – no more shrugging and not knowing who changed a value and when. No more what version of configuration was there when an issue happened a week ago.
• (Optional) Support for 'secrets' – e.g. production database password visible only for certain group of users (ops).

At the point of the decision there were no obvious solutions out there so we developed in-house a simple web application. Obviously it was a web app since when one has a hammer everything looks like a nail:). The app had a UI for listing files per project and environment. It had some neat syntax highlighting, it allowed you to add, copy, diff, edit, delete files, etc. It stored files in the database. The UI part needed a lot of maintenance and feature work yet it was clumsy to work with. It offered HTTP API to get the zip with configuration. It solved most of our problems. Since its roll-out we could finally see how are the customer facing environments configured. When a new property was introduced we could make the change, commit, take the version of that commit and create respective versions of the property files in all environments leaving TODOs where we did not know the right value. No more documentation about what all needs to be changed with the next deployment. No more figuring out what kind of configuration do I need locally to be able to run certain version of application.

I will elaborate a bit on how the versioning of files work by providing following example. Let's say the app is released in version 1.0. There are two files for each environment 'logback.xml' and 'app-env.properties'. We decide we want to change logging a bit in version 1.0.10 so we add updated logback.xml for version 1.0.10 and higher. Then a mail server needs to be added. The feature is implemented in version 1.0.42 so we add updated app-env.properties for version 1.0.42 and higher. So far our configuration management contains four files for each environment:

• app-env.properties/1.0.0
• logback.xml/1.0.0
• logback.xml/1.0.10
• app-env.properties/1.0.42

If one needs app configuration for given environment for version say 1.0.5 he will get the initial two. If one needs app configuration for 1.0.32 he will get app-env.properties/1.0.0 and logback/1.0/10. For version 2.0 he will get app-env.properties/1.0.42 and logback/1.0.10. So there is a requirement that versions can be lexically ordered.

The above described approach worked fairly well and we were autodeploying for more than a year with great success. Downtime of 40 seconds and the peace of mind were totally worth it. But on the hindsight, we spent one hell of a time developing features of the configuration management tool which could be covered by choosing another approach which came to our minds. Let me present it to you. Most of the work on the configuration management tool was spent on the UI and all the file management, syntax highlighting, and diffing. Despite all that work it is still not great! Yet there are so many tools around that can do parts of that work much better, namely our beloved IDEs. There are also good file storing solutions out there with auditing and we happen to call them version control systems:) So why not to pick Git with vim or Idea, create a predefined folder structure and let some daemon loose on top of it to serve the configuration zip file?

Our plan is to try just that at techdev, try it on shypp.it first and then open source it. We will keep you posted.

Also if you know about such a tool please let us know! We don't want to reinvent the wheel all that much.