Zprávičky

Workshop na téma GIT pro začátečníky i pokročilé, který jsme pořádali dne 26. 2. 2020, měl, podobně jako naše předchozí workshopy, velký úspěch. Tento verzovací nástroj byl probrán od základů. Ti, kteří nebyli přítomni, nyní dostávají druhou šanci, a to díky dalšímu příspěvku na našem odborném blogu.

Základní charakteristika Gitu

Git je distribuovaný verzovací systém. Stejně jako ostatní verzovací systémy (např. CVS, SVN) slouží pro evidenci historie změn a umožňuje spolupráci více členů týmu na jednom projektu.

Hlavní částí je tzv. repository, které obsahuje uložené soubory. Dále obsahuje potřebná dodatečná data umožňující evidovat a procházet změny souborů v průběhu času v různých fázích vývoje projektu.

Na rozdíl od jiných systémů (např. výše zmiňované SVN) umožňuje i práci bez trvalého připojení k centrálnímu serveru. Každý uživatel má svoji lokální kopii repository s kompletní historií.

Stejně jako jiné verzovací systémy je i Git používán typicky pro uložení zdrojových kódů napsaných v některém z programovacích jazyků. Důležitou funkcí každého verzovacího systému je vytváření a udržování paralelních větví a jejich opětovné slučování. Tyto operace lze rozumně provádět pouze s textovými soubory. V tomto případě jde o výše zmíněné zdrojové kódy.

Typy použití systému Git

Pokud plánuji používat Git na projektu sám a pouze na jednom stroji, je možné vytvořit si pouze lokální repository. V tu chvíli stačí Git zprovoznit pouze na daném stroji a vše potřebné je připraveno.

Bude-li na projektu pracovat více lidí nebo jej chci mít dostupný na více strojích, je nutné vytvořit vzdálené repository. Na výběr jsou dvě možnosti:

• vlastní server, na kterém si zprovozníme repository
• služba nabízející hostování repository

Úvodní vytvoření repository

Vytvoření lokálního repository provedeme příkazem:

git init 

Tímto příkazem se vytvoří složka .git, ve které se bude uchovávat vše potřebné pro repository. Současně nám tento příkaz vytvoří novou větev s názvem master.

Chceme-li vytvořit repository v již existujícím projektu, použijeme příkaz:

git init <adresar>

Vlastní server

Na serveru si zprovozníme Git a založíme repository úplně stejným způsobem, jako bychom to udělali na lokálním stroji. Přidáme pouze příznak --bare.

git init --bare

Příznak --bare zajistí to, že není možné přímo editovat soubory v tomto úložišti a změny následně nahrát do repository.

Na lokálním stroji si pak toto repository zkopírujeme, tzv. naklonujeme.

git clone <adresa_vzdaleneho_repository>

Tím se nám vytvoří v aktuální složce kopie vzdáleného repository.

Služba

Další možností, jak si zajistit vzdálené repository, je využít existujících služeb, např. github.com nebo gitlab.com. Výhodou těchto služeb je, že je možné je za určitých podmínek využívat zdarma. Tyto služby navíc poskytují, kromě přívětivého uživatelského rozhraní, další užitečné nástroje, jako je např. nastavení přístupových práv. 

Lokální repository ze služby se vytvoří stejně jako z vlastního serveru:

git clone <adresa_vzdaleneho_repository>

Základní operace s lokálním repository

Máme-li zprovozněné lokální repository, můžeme s ním začít pracovat. Pro začátek k tomu budeme využívat následující sadu příkazů:

• git status
• git add
• git commit
• git reset
• git diff

První příkaz, který budeme využívat téměř neustále, je:

git status

Status nám vypíše základní informace o našem repository:

• na jaké větvi se nacházíme a jaký je jeho stav vůči vzdálené větvi
• soubory se změnami ve working directory, které můžeme přidat do stage area
• soubory ve stage area připravené pro commit

Status vypisuje změny vždy vůči aktuálnímu adresáři. Pokud jsme v kořenovém adresáři, vidíme informace všechny. Pokud se ale přepneme do nějakého podadresáře, informace, které se vypíší, jsou platné pouze pro tento podadresář.

Náš lokální Git se skládá ze 3 základních částí:

• working directory
• staging area
• repository

Všechny změny, které v projektu tvoříme, se dějí ve working directory. Předtím, než je můžeme uložit do repository, musejí se přidat do staging area. To je v podstatě výběr změn, které chceme nahrát.

Pro přidání změn do staging area slouží příkaz:

git add <co>

Soubory nebo složky můžeme přidávat buď postupně:

git add <nazev_souboru_s_cestou>

git add index.php

git add <nazev_slozky_s_cestou>

git add app/router

Nebo přidat všechny změny z aktuálního adresáře najednou:

git add .

Jakmile jsou přidány všechny změny ve staging area, můžeme je nahrát do repository. K tomu použijeme příkaz:

git commit -m “popis commitu”

Po commitnutí změn se nám vytvoří první commit. Commity jsou základní jednotkou, která nám verzuje náš projekt. Mezi commity se můžeme přepínat, čímž se můžeme vracet do starších verzí našeho projektu.

Přidáme-li do staging area soubor, který ale ještě nechceme commitnout, použijeme pro jeho odstranění příkaz:

git reset <soubor>

Pro odstranění všech změn v daném adresáři slouží příkaz:

git reset .

Soubory se tímto vyjmou ze staging area. Změny v nich ale stále zůstanou.

Pro zobrazení všech změn v souborech, které jsou ve working directory, použijeme příkaz:

git diff

Pokud nás zajímá pouze konkrétní soubor, pak použijeme příkaz ve tvaru:

git diff <soubor>

Pokud nás zajímají změny v souborech, které již jsou ve staging area, přidáme příznak --cached:

git diff --cached

Novější verze mají alias --staged:

git diff --staged

Tímto jsme si osvojili základní příkazy, které potřebujeme pro snadné používání Gitu na lokálním stroji. V dalším článku si pak ukážeme pokročilejší věci, abychom mohli pracovat v týmu.

V principu máte tyto 3 možnosti, které si probereme.

1. odesílat z “localhostu“
2. SMTP server poskytovatele
3. externí aplikace – např. MandrilAPP

1. Odesílání z „Localhostu“

Dle mého názoru může dnes z localhostu odesílat jen blázen nebo odborník s „nekonečným“ množstvím času. Vzhledem k tomu, že dnes více než 99 % e-mailové komunikace je označeno jako SPAM, je velmi těžké e-mail „kvalitně“ odeslat.

Jen naznačím, co vše je třeba zajistit.

• Blacklisty IP adres
• Podepisování e-mailů (DKIM)
• Řešení stížností
• Globální blacklisty na providera
• atd.

Dle mého názoru, pokud někdo na svůj server nainstaluje Postfix v defaultním nastavení, nemůže zákazníkovi garantovat, že mail bude doručen. Může tak maximálně garantovat, že bude odeslán.

2. SMTP server poskytovatele

Asi nejčastěji používaná možnost. „Každý“ hosting poskytuje nějaký SMTP server. Většinou zdarma. Nevýhody jsou tyto:

• U serveru je často limit na počet zpráv za hodinu. Např. náš poskytovatel active24.cz provozuje server smtp.active24.cz, který má limit 100 zpráv za hodinu. Současně ještě další s limitem 1000 zpráv za hodinu, u kterého ale avizuje horší kvalitu doručení.
• Nelze trackovat email (tzn. nezjistíte, zda byl e-mail doručen, přečten, případně prokliknut)
• Kvalita odeslání je často špatná, souvisí to samozřejmě s cenou.
• Neexistující dohody s globálními hráči. Tzn. z českých SMTP serverů se špatně doručuje na O365 a gmail. Prostě jsme pro ně primárně nedůvěryhodní.

3. Externí aplikace

U nás v RTsoft u většiny aplikací používáme k odesílání transakční pošty službu mandrillAPP. Mandrill je součástí Mailchimpu, který se specializuje spíše na hromadný e-mail.



Jaké výhody a nevýhody MandrillAPP má?

Největší nevýhodou je cena.  K odesílání přes mandril potřebujete účet u mailchimpu a ještě tarif na Mandrill. Ceník je zde. Např pro 20 000 e-mailů měsíčně zaplatíte cca 600 Kč.

A teď k výhodám.

• Nemusíte se starat o kvalitu odeslání. Mandrill zajistí vše potřebné. Vzhledem k dohodám s velkými příjemci pošty je Mandrill vysokou garancí doručení. Na druhou stranu, pokud porušíte pravidla, Mandrill Vás bez milosti zařízne, resp. sníží limit množství odesílání pošty.
• Mandrill zajistí, že nebudete vícenásobně odesílat na hardbounce adresy.
• Budujete si reputaci, pokud odesíláte e-maily, které lidi čtou. Dostáváte globálně kladná hodnocení.
• E-mail můžete trackovat. Tzn. u každého e-mailu vidíte, zda byl doručen a zda byl přečten.
• Možnost API, informace o trackování můžete číst do aplikace.
• Možnost AB testů včetně vyhodnocení.
• Různé vymazlené statistiky.

Pro správné fungování Mandrill musíte každou doménu nastavit. Důležité je nastavení SPF a DKIM. DMARC je bonus navíc.

Odesílat samozřejmě můžete z více domén i z různých adres.

Vzhledem k tomu, že naši zákazníci jsou kriticky závislí na tom, aby transakční mail za aplikace či eshopu byl doručen, je pro nás použití aplikace typu Mandrill nutnost. Existuje samozřejmě velké množství alternativ, ale my jsme s Mandrill spokojeni. Domnívám se, že hledání podobného řešení zdarma je zbytečná práce. S odesíláním e-mailu je práce a ta něco stojí. Navíc cena za mandrill není nijak kritická vzhledem k použití na transakční emaily. Pokud bychom se bavili o odesílání newsletterů, tak to je úplně jiná pohádka. Ale o tom někdy příště.

Pokud píšete aplikace, do které uživatel zadává čísla účtů, je vhodné číslo validovat, abyste chránili uživatele před sebou samými, tzn. v tomto případě před jejich překlepy.

Z čeho se tedy takové číslo účtu skládá?

Jde o maximálně 16 číslic ve dvou částech nazvaných předčíslí (max 6 číslic) a základní část čísla účtu (max 10 číslic) + kód platebního styku, který má 4 znaky (0100 je např. KB, 5500 je Raiffeisen bank atd..)

Příklad čísla účtu, které patří společnosti T-Mobile, je např. 19-2235210247/0100 (je uvedeno veřejně na www). Dále vyhláška říká, že kód platebního styku (=kód banky) musí být jasně oddělen. Je zvykem používat znak „/“

V IT pohledu tedy (6+10+4 číslice)

0000192235210247 / 0100

0100 není moc zajímavé, existuje seznam kódu bank, které vydává ČNB, např. zde, stačí ověřit, zda je v seznamu.

Budeme tedy ověřovat, zda je platné číslo 0000192235210247.

Číslic je 16 (2 na 4 ? náhoda?) tak si je očíslujeme, správný programátor čísluje samozřejmě od 0 ? a odzadu.

Jasné?

Nyní potřebujete váhy jednotlivých číslic. Máte teď 2 možnosti. Pokud je jen chcete znát, přeskočte odstavec. Pokud jste alespoň trochu duší matematik, popíšu pro Vás výpočet.

Pro výpočet váhy potřebujete vědět, jak umocňovat a co je to modulo ?. Vzorec je snadný pokud chcete znát váhu u n-té číslice, umocníte 2 na N a z toho celého uděláte modulo 11. Řečí Excelu =MOD(POWER(2;N);11)

Např. tedy u patnácté číslice (z hlediska zákazníka první, z hlediska programátora poslední) je to 2 na 15 MOD 11 tzn. 10

Zde jsou vypočtené váhy.

A teď je to už snadné. Každou číslici v čísle učtu vynásobíte jeho váhou a výsledek sečteme. Na závěr ověříte, zda výsledek je bezezbytku dělitelný 11 (MOD 11 = 0). Potom je číslo účtu validní. To ale samozřejmě neznamená, že existuje a vůbec to negarantuje, že toto číslo účtu patří dané společnosti.

Příklad s účtem T-mobile:

7 (nultá číslice v čísle účtu=poslední)*1(váha nulté číslice) + 4*2 + 2*4 + 0*8 + 1*5 + 2*10 + 5*9 + 3*7 + 2*3 + 2*6 + 9*1 + 1*2 = 143 a světe div se / 11 = 13 bezezbytku

Proč to všechno? Lidé často dělají překlepy. Tato validace zajistí, že pokud se zákazník splete právě v jedné číslici, tak číslo nebude validní a hned na to budete upozorněni. S velkou pravděpodobností, pokud spletete 2 číslice, stále se asi netrefíte do jiného čísla. Pokud 2 číslice prohodíte, číslo nebude skoro určitě validní.

Tento systém vůbec neřeší, zda dané číslu účtu už neexistuje u jiné banky, takže opravdu můžete mít stejné číslo jako někdo jiný u banky konkurenční. Banky to často používají jako konkurenční zbraň ?. Některé banky do čísla účtu kódují další informace, jako např. číslo pobočky atd.

Příště si něco povíme o validaci IBAN ?.