Create IT Blog - odborné

 

 

Praha byla centrem blockchainového multivesmíruhttps://create-it.cz/Blog/Stranky/Gateway-to-Cosmos.aspxPraha byla centrem blockchainového multivesmíru<p>​​Na pražské konferenci Gateway to Cosmos jsme byli svědky otevření dveří do blockchainového multivesmíru. Podobně jako v posledním marvelovském filmu s Doktorem Strangem, je Cosmos branou do paralelních světů, které mají schopnost navzájem spolu komunikovat. Těmito světy jsou blockchainy vzniklé právě z mateřského Cosmosu.</p><p>Nekompatibilita a přenos inforací mezi jednotlivými blockchainy je jedním z kritických míst, které vývojáři řeší. Blockchain 3.0, jak se Cosmos nazývá, umožňuje programátorům plynule budovat nové blockchainy bez nutnosti následné tvorby tzv. mostů mezi nimi. Cílem celého projektu je vytvoření internetu blockchainů – sítě blockchainů a aplikací na nich postavených schopných vzájemně komunikovat decentralizovaným způsobem.<br></p><p> <img src="/Blog/PublishingImages/Stranky/Gateway-to-Cosmos/cosmos.jpg" alt="cosmos.jpg" data-themekey="#" style="max-width:690px;" /> <br> </p><h2>Napojení Cosmosu na da​lší blockchainy</h2><p> <strong></strong>Interoperabilita je pojem, který  v blockchainovém prostoru rezonuje již dlouhou dobu. Téměř každý den vznikají nové blockchainy nebo kopie těch starých a vzniká u nich dříve nebo později přirozená potřeba komunikovat s ostatními. I když funkce Cosmosu tento problém uvnitř svého ekosystému řeší, potřebuje pomoc s překladem do jiných jazyků a neměnným přenosem informací do jiných sítí.</p><p> <a href="https://axelar.network/">Axelar</a>, jeden z hlavních partnerů akce, představil, jak zajistit bezpečnou interakci s jakýmkoli aktivem, kteroukoliv decentralizovanou aplikací na jakémkoli blockchainu. Takže můžete poslat své NFT z Etherea do libovolného blockchainu Cosmos a naopak. Takto jsou přes axelar propojeny všechny hlavní blockchainy a v brzké době se chystá i přemostění s Bitcoinem.<br></p><p> <img src="/Blog/PublishingImages/Stranky/Gateway-to-Cosmos/dao.jpg" alt="dao.jpg" data-themekey="#" style="max-width:690px;" /> <br> </p><h2>DAO jako středobod decentraliz​​ovaných projektů</h2><p> <strong></strong>Zajímavou myšlenkou je, že skutečně decentralizované řešení by mělo vždy začínat vznikem <a href="https://en.wikipedia.org/wiki/Decentralized_autonomous_organization">DAO</a> – decentralizované organizace vytvořené podle pravidel zakódovaných jako počítačový program (Wikipedie). Jake Hartnell, spoluzakladatel <a href="https://www.junonetwork.io/">Juno</a> a <a href="https://daodao.zone/">DAO DAO</a>, demonstroval na svých projektech, že za funkční organizací nemusí stát žádný konkrétní investor či <a href="https://en.wikipedia.org/wiki/Venture_capital">VC</a>. Jsou čistě postaveny a sponzorovány svou komunitou. Rizikem je, že programovatelná pravidla  na nichž tyto struktury stojí, stále nemají dostatek příkladů použití, jak to udělat správným způsobem. Na druhou stranu i zde může být rozmanitost, jak to vidíme na současné politické scéně. Juno tento problém řeší vytvářením podskupin - tzv. subDAO. To se dá připodobnit firemní struktuře, kde má každý subjekt svou odpovědnost (CoreDev DAO, Event DAO, Hack DAO). Díky tomu by specifická rozhodnutí v rámci organizace měla být vykonávána kvalifikovanou částí komunity.<br></p><p> <img src="/Blog/PublishingImages/Stranky/Gateway-to-Cosmos/smart-contract.jpg" alt="smart-contract.jpg" data-themekey="#" style="max-width:690px;" />Agoricu, blockchainu vycházejícího z Cosmos SDK, představil řešení, které by mohlo zvrátit celou hru. Smyslem není přesvědčit vývojáře, aby se učili nový programovací jazyk, jako je Solidity u Etherea. Jde o to jim umožnit stavět na tom, co již znají. Hovoříme o 10 milionech vývojářů, kteří získají možnost budování Smart kontraktů v JavaScriptu. Díky Agoricu se tak programování aplikací na blockchainu stane dostupné i “běžným lidem".</p><p>Souhrnným poselstvím konference bylo “It's time to build", tedy iniciovat vývojáře a týmy po celém světě, aby začali tvořit svá řešení v Cosmosu. Díky <a href="https://rbf.capital/">Rockaway blockchain fund</a>, který byl hlavním pořadatelem, se podařilo na jednom místě propojit zakladatele blockchainů, tvůrce nástrojů, programátory aplikací, investory a další entity tohoto ekosystému. Přednášky se prolínaly s hackathonem a workshopy a kdokoliv měl možnost získat odpovědi na své otázky hned na místě.</p><p>Misí <a href="https://cleverlance.com/blockchain42">Cleverlance Blockchain 42</a> týmu bylo prohloubit znalosti o Cosmosu, přidružených nástrojích a především pak získání nových zkušeností s Agoric blockchainem a dalšími Cosmos-chainy. Mise dopadla úspěšně a náš tým pokračuje dál. Plní se nám náš dětský sen stát se kosmonauty. Brzy se ohlásíme s dalšími novinkami z tohoto vesmíru.<br></p><p> <em>Filip Dítě</em></p><p><br></p><p><em></em><span style="color:#242424;font-family:-apple-system, system-ui, "segoe ui", "apple color emoji", "segoe ui emoji", "segoe ui web", sans-serif;font-size:14px;">Z​droj fotografií: </span><a aria-label="Link https://gateway.events/" title="https://gateway.events/" href="https://gateway.events/" rel="noopener noreferrer" target="_blank" tabindex="-1" style="box-sizing:border-box;outline-style:none;color:#4f52b2;text-decoration-line:none;font-family:-apple-system, system-ui, "segoe ui", "apple color emoji", "segoe ui emoji", "segoe ui web", sans-serif;font-size:14px;">https://gateway.events/</a>​​​<br></p>odborné;#vzdělávání;#
Typescript: typy pro manipulaci s řetězcihttps://create-it.cz/Blog/Stranky/Type_script_3.aspxTypescript: typy pro manipulaci s řetězci<p>​Pojďme se tentokrát seznámit s vestavěnými typy, které nám usnadní práci s řetězci / proměnnými, a mohou být použity v šablonách (tzv. template string literals).<br></p><p> <b>Které typy to jsou?</b></p><ul><li>Uppercase<StringType> - transformuje vstupní řetězec do řetězce s pouze velkými písmeny</li><li>Lowercase<StringType>- transformuje vstupní řetězec do řetězce s pouze malými písmeny</li><li>Capitalize<StringType> - transformuje vstupní řetězec do řetězce s prvním znakem psaným velkým písmem</li><li>Uncapitalize<StringType> - transformuje vstupní řetězec do řetězce s prvním znakem psaným malým písmenem</li></ul><p>Každý z typů přijímá jeden parametr typu string. Pokud se pokusíme předat parametr jiného typu, pak dostaneme chybovou zprávu, upozorňující nás na porušení daného omezení.</p><p>Výše zmíněné typy jsou z výkonnostních důvodů poskytovány TypeScriptovým kompilátorem a nejsou definovány v TypeScriptovém .d.ts souboru. Implementace těchto typů využívá přímo JavaScriptové funkce pro manipulaci s řetězci a nebere v potaz locale běhového prostředí (je to soubor parametrů, které definují uživatelův jazyk, stát a jiné zvláštnosti, které se následně projeví v uživatelském rozhraní). Implementace v TypeScriptu 4.1 vypadá následovně:<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">function applyStringMapping(symbol: Symbol, str: string) { switch (intrinsicTypeKinds.get(symbol.escapedName as string)) { case IntrinsicTypeKind.Uppercase: return str.toUpperCase(); case IntrinsicTypeKind.Lowercase: return str.toLowerCase(); case IntrinsicTypeKind.Capitalize: return str.charAt(0).toUpperCase() + str.slice(1); case IntrinsicTypeKind.Uncapitalize: return str.charAt(0).toLowerCase() + str.slice(1); } return str; } </code></pre><p></p><h2> <strong>Uppercase<StringType></strong></h2><p>Transformuje vstupní řetězec do řetězce pouze s velkými písmeny.</p><p>Mějme typový alias PointsOfTheCompass, jehož definice je následující<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type PointsOfTheCompass = 'north' | 'west' | 'east' | 'south'</code></pre><p>Výsledkem následujícího př​​iřazení<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type Result = Uppercase<PointsOfTheCompass>;</code></pre><p>je typový alias se všemi položkami psanými velkými písmeny.​<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type Result = 'NORTH' | 'WEST' | 'EAST' | 'SOUTH'</code><br></pre><p></p><h2> <strong>Lowercase<StringType></strong></h2><p>Mějme typový alias PointsOfTheCompass, jehož definice je následující<br></p><span style="font-size:15px;"></span><pre><code class="language-typescript hljs">type PointsOfTheCompass = 'NORTH' | 'WEST' | 'EAST' | 'SOUTH'</code></pre><p></p><p>Výsledkem následujícího přiřazení<br></p><pre><code class="language-typescript hljs">type Result = Lowercase<PointsOfTheCompass>;</code><br></pre><p></p><p>je typový alias se všemi položkami psanými malými písmeny.<br></p><pre><code class="language-typescript hljs">​type Result = 'north' | 'west' | 'east' | 'south'</code><br></pre><p></p><h2> <strong>Capitalize<StringType></strong></h2><p>Mějme typový alias PointsOfTheCompass, jehož definice je následující<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type PointsOfTheCompass = 'north' | 'west' | 'east' | 'south'</code></pre><p>Výsledkem následujícího přiřazení<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type Result = Lowercase<PointsOfTheCompass>;</code></pre><p>je typový alias, kde každá položka má první písmeno psáno velkým písmenem<br></p><pre><code class="language-typescript hljs">type Result = 'North' | 'West' | 'East' | 'South'</code><br></pre><p></p><h2> <strong>Uncapitalize<StringType></strong></h2><p>Mějme typový alias PointsOfTheCompass, jehož definice je následující<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type PointsOfTheCompass = 'NORTH' | 'WEST' | 'EAST' | 'SOUTH'</code></pre><p>A výsledkem následujícího přiřazení<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type Result = Uncapitalize<PointsOfTheCompass>;</code></pre><p></p><p>je typový alias, kde každá položka má první písmeno psáno malým písmenem<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type Result = 'nORTH' | 'wEST' | 'eAST' | 'sOUTH'</code><br></pre><p></p><h2> <strong>Použití</strong></h2><p>Nejčastější použití nalezneme spolu s template literal type. Mějme typový alias Point, jehož definice je následující<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">interface Point {  <p> longitude: double; <span style="font-family:source-sans-pro, open-sans, sans-serif;"> </span></p><p> latitude: double;<span style="font-family:source-sans-pro, open-sans, sans-serif;"><br>}</span></p></code></pre><pre>Výsledkem následujícího přiřazení<br></pre><p></p><pre><br><code class="language-typescript hljs">type CapitalizedPoint = Capitalize<keyof Point>;</code></pre><p></p><p>pak je<span style="font-size:15px;"></span></p><pre><code class="language-typescript hljs">type CapitalizedPoint = 'Longitude' | 'Latitude'</code></pre><p>pokud náš příklad rozvineme dále a aplikujeme spolu s template literal type, pak můžeme například generovat další typ<br></p><pre> <code class="language-typescript hljs">type PointGetAccessoryNames = `get${Capitalize<keyof Point>}`;</code></pre><p></p><p>kde jako výsledek dostáváme<br></p><pre><code class="language-typescript hljs">type PointAccessoryNames = 'getLongitude' | 'getLatitude'</code></pre><p>pokud tento přístup následně nakombinujeme i s mapováním<br></p><pre><code class="language-typescript hljs">type PointAccessors = {  <p>​[K in keyof Point as `get${Capitalize<K>}`]: () => Point[K];<span style="font-family:source-sans-pro, open-sans, sans-serif;"><br>}</span></p></code></pre><p>pak dostaneme následující typový alias<br></p><pre><code class="language-typescript hljs">type PointAccessors = {    <p> getLongitude: () => number;   <span style="font-family:source-sans-pro, open-sans, sans-serif;"> </span></p><p> getLatitude: () => number;<br></p>}</code><p></p></pre><p></p><h2> <strong>Závěrem</strong></h2><p>Výše jsme představili typy, které můžeme použít pro manipulaci s řetězci a způsob, jakým je můžeme použít spolu s template string literals a jaké výhody nám to přináší. A na co se můžete těšit příště? </p><p>Typy, jako jsou Readonly<Type> ; Record<Keys, Type> ; Pick<Type, Keys> a Omit<Type, Keys><br></p><p><i>Václav Kandus​</i></p>odborné;#
Vývoj multiplatformních mobilních a webových aplikacíhttps://create-it.cz/Blog/Stranky/Multiplatform.aspxVývoj multiplatformních mobilních a webových aplikací<p>​​​​​​Chcete vlastní mobilní aplikaci? Všem je jasné, že je třeba myslet jak na platformu Android tak i na iOS, nestačí jedna z nich. A často se neobejdeme ani bez webového rozhraní​. Ovšem prakticky od příchodu mobilních zařízení na trh se proslýchá, že vyvíjet separátně pro jednotlivé platformy je nákladné. Proto se různé společnosti pokoušely přinést alternativy v podobě multiplatformních řešení, ovšem žádné z nich se výrazněji neujalo. Měla svá úskalí, byla zbytečně složitá​ a firmu, která chce vyvíjet své mobilní aplikace flexibilně, drží v pomyslné "kleci" omezených možností. Proto je u B2C aplikací velmi často preferován nativní vývoj, protože nejsou omezeny UX, možnostmi animací a dalšími detaily, které jsou pro tuto cílovou skupinu velmi důležité.​</p><p>V posledních letech se však objevují podnikové mobilní aplikace, u nichž není prioritou dokonalé uživatelské rozhraní a design, ale funkčnost, užitečnost, a především rychlost dodání a flexibilita úprav. A právě tady se ukázal prostor pro používání vybraných technologií, které nabízejí multiplatformní využití. Samozřejmě za dodržení určitých pravidel.</p><p>V Cleverlance se nám osvědčily tři způsoby implementace. Když to velmi zjednodušíme, hned na začátku se musíme rozhodnout, jak robustní back-end s MOA (<a href="https://en.wikipedia.org/wiki/Microservices">Microservice Oriented Architecture</a>) je k dispozici, nebo zda ho budeme potřebovat vytvořit a dále pak, jestli aplikace nebude mít příliš mnoho business logiky, ale bude spíše jen prezentační vrstvou. V tomto případě je vhodné použít <a href="https://flutter.dev/">Flutter</a>. Pokud potřebujeme v aplikaci fronty pro synchronizaci, business logiku a zavádíme určitou komplexitu mimo formuláře, osvědčil se nám <a href="https://kotlinlang.org/docs/multiplatform.html">Kotlin Multiplatform</a>. Nebo je tu ještě třetí hráč = PWA (<a href="https://en.wikipedia.org/wiki/Progressive_web_application">Progressive Web Applications</a>), který využívá silný základ moderních prohlížečů.</p><h2>Fl​​​utter</h2><p><strong></strong>Flutter považujeme za skutečně mnohakanálovou zobrazovací vrstvu, která nám umožňuje vytvářet jak mobilní, tak i webové a desktopové aplikace. Jedná se o flexibilní řešení, se kterým lze efektivně navrhnout B2B, a za určitých podmínek i B2C aplikaci. Příkladem budiž mobilní aplikace pro společnost BMW. Jestliže ale nechcete řešit problémy, je lepší se spolehnout na back-end a nechat na něm veškeré „přemýšlení“.</p><h2>Kotlin Multipl​atform</h2><p><strong></strong>Další možností je multiplatformní jazyk Kotlin. Výhodou je, že programujete "nativní aplikaci" pro Android, jejíž část se použije i pro iOS. Většinou je řeč o business logice a integrační vrstvě, která nám později ve fázi QA ušetří spoustu času. Vizualizační vrstva se pro systémy iOS a Android programuje nativně, a tak je možné dosáhnout „look & feel“ vzhledu platformy a přepoužít „one code base“ pro uživatelsky neviditelné části aplikace. U některých projektů lze takto využít až 70-80 % kódu.</p><h2>P​​WA</h2><p><strong></strong>Progressive Web Applications patří k nejnovějším trendům v oblasti tvorby webových aplikací. Do jisté míry stírají hranice mezi webovou a nativní mobilní aplikací díky možnosti práce offline, přístupu k hardwaru zařízení a to včetně možnosti příjmu push notifikací. Kombinují tak v sobě to nejlepší z obou světů, omezují nás pouze limity internetového prohlížeče. Otevírá se tak pestrá škála funkcionalit, například již v základu může využívat fotoaparát nebo čtečku otisku prstu. Požadavek na použití hlubších funkcí zařízení lze efektivně vyřešit pomocí nativní „obálky“, která je zpřístupní. PWA aplikace lze umístit do všech běžných aplikačních obchodů (Google Play, Apple Store, Huawei AppGallery i Microsoft Store) a mohou běžet na zařízeních s OS Android, iOS i Windows.<br></p><h2>​Kde to funguje?<br></h2><p>Jako dodavatel chceme samozřejmě kromě standardních technologií vývoje nabízet i ty „nové“ a o to více nás těší, že za námi chodí i naši zákazníci, kteří už na začátku požadují Kotlin Multiplatform. Jako příklad můžeme uvést americkou společnost Globstar, pro kterou ve skupině Aricoma dodáváme mobilní aplikaci na konfiguraci a správu satelitních modemů pro připojení k internetu. Využití Kotlin Multiplatform se v tomto případě skutečně osvědčilo, protože se jednalo o aplikaci náročnou na integraci i přenos dat. Integrace navíc probíhá pomocí BLE (Bluetooth Low Energy), která dokáže obsluhovat desítky zařízení najednou a aktualizovat jim například firmware. Technologie přesvědčila jak zákazníka, tak nás jako dodavatele a při vývoji aplikace se tak podařilo vytvořit fungující pracovní partnerství.</p><p>Technologii PWA jsme úspěšně využili například v online samoobsluze pro zákazníky SAZKAmobilu. Její hlavní výhodou je extrémní zkrácení Time-To-Market (času potřebného pro uvedení nových funkcí „na trh“) a velká základna vývojářů, kteří tuto technologii ovládají. Kromě toho se PWA nejlépe uplatní tam, kde není velký důraz na využití komponent samotného zařízení, například v interních firemních aplikacích využívaných pracovníky v terénu či ve výrobě.</p><p>Pokud by vás zajímaly technické detaily, přečtěte si na našem blogu <strong>mobile it</strong> <a href="https://www.mobileit.cz/Blog/Pages/kotlin-multiplatform-first-year.aspx">tento</a> článek, ve kterém se také <a href="https://www.mobileit.cz/Blog/Pages/choosing-mobile-app-technology.aspx">dozvíte</a>, na co si při výběru technologie pro vývoj mobilní aplikace dát pozor.<br></p><p><br></p><p><em>Milan Mitošinka​</em><br></p>odborné;#projekty;#
5 kognitivních zkreslení při vývoji softwaru a jak se jim vyhnouthttps://create-it.cz/Blog/Stranky/kognitivni-zkresleni.aspx5 kognitivních zkreslení při vývoji softwaru a jak se jim vyhnout<p>​​​​Kognitivní zkreslení jsou naučená pravidla vnímání a chování. V podstatě jsou to mentální zkratky, které nevědomě používáme. Při práci nás tyto skryté předsudky mohou nemile překvapit, proto je nutné si uvědomovat, jak fungují, a vědomě jim předcházet. V tomto článku se podíváme na 5 hlavních zkreslení a na užitečné techniky, které lze použít pro jejich minimalizaci.<br></p><p><br></p><h2>Optimistické ​zkre​​​slení</h2><p>Optimistické zkreslení (nebo také zaujatost) je tendence k přehnané optimističnosti ohledně okolních událostí. V softwarovém světě se vyskytuje hlavně při odhadech náročnosti úkolů, kdy můžeme přeceňovat vlastní dovednosti.​<br></p><p>Běžně se může při poradě stát, že váš kolega prohlásí, že daný náhodný úkol zvládne lehce udělat a nezabere mu to skoro žádný čas. Přitom nemá žádnou předchozí znalost o úkolu a vše zakládá na přehnaném optimismu. Jak jste určitě ve světě software už viděli, tyto odhady se často ukážou jako těžce podceněné. A malou třešničkou na dortu je tzv. snadné-obtížné zkreslení, kdy lidé odhadují obtížné úkoly optimisticky a ty snadné zase pesimisticky.</p><p>​Tomuto kognitivnímu zkreslení se dá vyhnout pomocí těchto přímých otázek:<br></p><ol><li>Vidíš na úkolu něco, co by mohlo způsobit problémy?</li><li>Vidíš nějaký důvod, proč by tvoje řešení mohlo být nesprávné?</li><li>Zamyslel ses nad závislostmi, které budou ovlivněny změnou tohoto kódu? <br><br></li></ol><h2>Konfir​​mační zkreslení</h2><p>Konfirmační zkreslení je dalším dobře známým zkreslením. Značí, že máme tendenci věnovat pozornost pouze těm informacím, které potvrzují naše existující přesvědčení a názory a naopak ignorovat ty informace, které našim názorům protiřečí. V podstatě je to stejné jako mít hlavu v oblacích a utíkat před realitou. Bystrost našeho myšlení se pod vlivem tohoto zkreslení nijak nezlepšuje, právě naopak.</p><p>Řekněme, že jeden z programátorů v týmu pevně věří, že dědičnost byla vždy základem <a href="https://cs.wikipedia.org/wiki/OOP">OOP</a>. Jiný kolega předloží argument, že tomu tak není. Dědičnost nebyla přijata jen tak a je stále zdrojem debat. Aby první programátor dokázal svoji pravdu, vygooglí třeba “dědičnost základem OOP" a hned první výsledek mu potvrdí jeho názor. Avšak jeho kolega má pravdu. Ani Alan Key, jeden ze zakladatelů OOP,  nechtěl implementovat dědičnost v první verzi jazyku Smalltalk.</p><p>Konfirmačnímu zkreslení se dá vyhnout následujícími způsoby</p><ol><li>​Pokusit se nalézt problémy, které mohou vzniknout, a nehledat jen pozitivní případy. V případě příkladu s Googlem tedy hledat i opačný názor.</li><li>Hledat logické opodstatnění každého předsudku (a nejlépe i zjistit, že jde o předsudek) a hledat i případy, při kterých může být logicky neplatný.<br><br></li></ol><h2>Kot​vení</h2><p>Kotvení popisuje skutečnost, kdy je přirozenou lidskou tendencí spoléhat se při rozhodovacím procesu na jednu informaci či skutečnost, od níž jsou poté odvozována další rozhodnutí. Tato informace však mnohdy vůbec nemusí být relevantní a může náš úsudek ovlivňovat negativním způsobem.</p><p>Toto zkreslení se může vyskytnout např. v následující situaci. Scrum master se zeptá týmu při odhadu pracnosti: “Jak dlouho zabere tenhle task? 2 týdny?". Díky efektu kotvení pak nebude záležet, jak je ten úkol ve skutečnosti obtížný, většina týmu se shodne na 2 týdnech. Byli ovlivněni první informací, kterou obdrželi. Stejná technika se využívá i při pohovorech, kdy je pro uchazeče klíčové navrhnout platové ohodnocení jako první.</p><p>A jak se kotvení zbavit?</p><ol><li>Neptat se přímo na odhad, ale na úkol samotný: “Kolik toho zvládnete udělat za 2 týdny?"</li><li><a href="https://en.wikipedia.org/wiki/Planning_poker">Planning poker</a> - všechny názory jsou dány anonymně ve stejný moment. Je to skvělá technika při scrumových odhadech! ​<br><br></li></ol><h2>Stád​ový efekt</h2><p>Stádový efekt je jev, který jedince nutí jít s davem a spíše přistupovat na názory, které viděl u ostatních. Může také označovat oblibu módních trendů - stačí se podívat na dnešní instagramovou kulturu bezcharakterních lidí. Pokud je myšlenka sdílena většinou populace, nabývá na důvěryhodnosti nezávisle na pravdivosti. Sociální sítě jako Twitter a Reddit jsou na to také velice náchylné. Na Twitteru je to ještě podpořeno omezeným počtem znaků, který podporuje povrchní názory a myšlenky.<br></p><p>Z hlediska softwarového vývoje se podívejme opět na příklad s poradou. Charismatická team leaderka argumentuje, proč by celý tým měl přejít z REST API na GraphQL. V prezentaci demonstruje technické výhody nové technologie pro celou firmu. Kolegové také vypadají, že novou technologii chtějí. Bohužel jde o stádový efekt. Team leaderka ve skutečnosti jen způsobila rozruch okolo nové technologie, ale nedokázala hodnotu svého nápadu. Bude to zajímat zákazníka? Uvidí nějaký rozdíl při používání? Přinese to více času, zákazníků nebo peněz firmě? Když jde o novou technologii, jsou pochopitelně všichni nadšení.</p><p>Jak se zbavit tohoto kognitivního zkreslení? Těmito otázkami:</p><ol><li>Software vyvíjíme hlavně pro podporu firmy. Nemá smysl používat novou barevnou technologii, pokud nepřinese žádnou extra hodnotu<br></li><li>Jaká je hodnota toho nápadu?</li><li>Jak přinese nové zákazníky, čas nebo nějakou jinou výhodu?</li><li>Převažují výhody nad cenou implementace?<br><br></li></ol><h2>Atr​ibuční chyba</h2><p>Atribuční chyba je zkreslení procesů přisuzování. Projevuje se tím, že při vysvětlování chování ostatních lidí má člověk sklon nadsazovat charakterové vlastnosti člověka a podceňovat kontext jeho životní situace nebo náhodnosti okolního prostředí.</p><p>Pro poslední zkreslení tohoto článku už vylezeme ze zasedačky a raději si sedneme zpět k práci. Při programování si však všimnete ošklivého bloku kódu. Pomocí <em>git blame</em> zjistíte, kdo je jeho autorem. Je to Lukáš. Samozřejmě. Lukáš je neopatrný, nezodpovědný a impulsivní. Nepřemýšlí nad tím co dělá. Vy byste to udělali lépe!</p><p>Ale uklidníte se a pokračujete v implementaci svojí feature. Za chvíli však narazíte na další blok otřesného kódu. Zase Lukáš, to je jasné! Avšak <em>git blame</em> tentokrát řekne jiný příběh - autorem jste vy. Všemožné otázky najednou naplní vaši  mysl. Jsem špatný vývojář? Jsem jako Lukáš? Ale tyto pochyby ihned zahodíte a začnou přicházet výmluvy. Samozřejmě, že nejste špatný vývojář, byla zrovna deadline, nebylo dost času, měli jste zrovna rýmu, a psa jste měli u veterináře. To je ve zktrace atribuční chyba - podceňování kontextu životní situace při souzení jiných lidí.</p><p>Jak se vyhnout atribuční chybě?</p><ol><li>Obviňování autora nepomůže. Zkuste zjistit příčinu toho špatného kódu.</li><li>Má Lukáš málo zkušeností v tomto segmentu vědění o programovacím jazyku/projektu?</li><li>Byl zrovna pod stresem? Blížil se deadline? Byl přepracovaný? Byl víkendový crunch?</li></ol><h2> ​Pozvěte ďáblova advokáta<br></h2><p>A to tedy bylo​ 5 hlavních kognitivních zkreslení. Co jsme se naučili? Kognitivní zkreslení se stávají nám všem. Co proti tomu můžeme dělat je naučit se všímat si jich a umět se jim vyhnout. Nejčastější zkreslení v softwarovém vývoji jsou optimistické, konfirmační a kotvící. Také je velice častý stádový efekt a atribuční chyba. Na softwarové projekty mohou mít katastrofální vliv. Hlavní metodou vyhnutí je vždy pečlivé zamyšlení se ​nad problémem a hraní si na "ďáblova advokáta" při jeho analýze, tedy snaha hledat nejen pozitivní případy, ale i ty opačné a negativní. Pro více informací o kognitivních zkresleních v softwarovém vývoji doporučují tuto <a href="https://www.researchgate.net/publication/328410759_Cognitive_Biases_in_Software_Engineering_A_Systematic_Mapping_Study">stud​ii</a>, kterou jsem použil jako zdroj pro tento článek. Doufám, že jste si článek užili, a zase příště!<br></p><p><em>Jan Jileček</em><br></p><p><br><br></p>odborné;#vzdělávání;#
Typescript: Required<Type>https://create-it.cz/Blog/Stranky/Type_script_2.aspxTypescript: Required<Type><p>​​​​​​​V úvodním článku našeho seriálu o TypeScriptu <a href="/Blog/Stranky/Type_script_1.aspx" target="_blank">Efektivní TypeScript​​​​</a> jsme se zaměřili na generický transformační typ Partial. <br> Jeho opakem je Required​, ale stejně jako Partial je aplikován pouze na položky na nejvyšší úrovni.</p><p> Pojďme si dát tentokrát za cíl vytvoření nového typu z aktuálního tak, že nově vytvořený typ má veškeré položky povinné.<br></p><p> Mějme typový alias User, jehož definice je následující:<br></p><pre> <code class="language-typescript hljs">type User = { firstName?: string; lastName?: string; age?: number; } </code>​<br></pre><p></p><p> výsledkem následujícího přiřazení<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs"> type RequiredUser = Required<User>; </code></pre><p></p><p> je typový alias se všemi položkami povinnými.<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type User = { firstName: string; lastName: string; age: number; } </code></pre><p></p><p> Pro demonstraci toho, že Required označí jako povinné pouze položky na nejvyšší úrovni, si zadefinujme adresu jako<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type Address = { street?: string; city?: string; } </code></pre><p></p><p> a uživatele včetně adresy následovně:<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type User = { firstName?: string; lastName?: string; age?: number; address?: Address; } </code></pre><p></p><p> Výsledkem přiřazení​<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type RequiredUserNoDeep = Required<User>; </code></pre><p></p><p> pak je<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type User = { firstName: string; lastName: string; age: number; address: { street?: string; city?: string; } } </code></pre><p></p><p> Jinými slovy, adresa sama o sobě je povinná, jednotlivé její položky však nikoli.</p><p> Pro úplnost se ještě pojďme podívat na implementaci a trochu si ji v krátkosti rozebrat:<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type Required = { [P in keyof T]-?: T[P]; }; </code></pre><p></p><p> Implemetace výše mapuje každou položku původního typu dle daného předpisu. V našem případě je odstraněn z každého klíče původního typu Elvis operátor “?“ a z volitelné položky je učiněna položka povinná. </p><p> V porovnání s Partial, probíraném v předešlém článku, a jehož implementace vykonává pravý opak, každý klíč původního typu označuje jako volitelný.<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type Partial = { [P in keyof T]?: T[P]; }; </code></pre><p></p><p> Je dobré si pamatovat, že pokud použijeme typ Required v projektu, kde TypeScriptový překladač má nastavenu hodnotu strictNullChecks: true, pak aplikace typu Required neodstraní pouze nepovinnost dané položky, ale též undefined. Pojďme si to ukázat na příkladu, definujme uživatele následovně:<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type User = { firstName: string; lastName?: string; thirdName?: string | undefined; age: number; } </code></pre><p></p><p> a proveďme následující přiřazení:​<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type RequiredUser = Required<User>; </code></pre><p></p><p> pak výsledný alias vypadá takto:<span style="font-size:15px;"></span></p><pre> <code class="language-typescript hljs">type Required<User> = { firstName: string; lastName: string; thirdName: string; age: number; }</code></pre> jinými slovy, při použití původního typu User jsme byli schopni uložit hodno​tu undefined do proměnných lastName a thirdName<span style="font-size:15px;"></span> <pre> <code class="language-typescript hljs">let user: User = { firstName: 'Adam', lastName: undefined, thirdName: undefined, age: 30 } </code></pre><p> zatímco po aplikaci Required již hodnotu undefined vložit do proměnných lastName a thirdName není povoleno a následující kód skončí chybou. Ušetřete si práce a mějte toto chování na paměti.</p><p></p><pre> <code class="language-typescript hljs">​let user: Required<User​> = { firstName: 'Adam', lastName: undefined, thirdName: undefined, age: 30 } </code></pre><h2>​​​Závěrem</h2><p> Tentokrát jsme si ukázali, jak se standardně Required chová a také jsme se seznámili se situací, jak se jeho chování změní, když je parametr strictNullChecks nastaven na hodnotu true. Příště se zaměříme na Capitalize a Uncapitalize.<br></p><p> <i>Václav Kandus</i> </p>odborné;#vzdělávání;#
Efektivní TypeScripthttps://create-it.cz/Blog/Stranky/Type_script_1.aspxEfektivní TypeScript<p>​TypeScript je velmi populární <a href="https://cs.wikipedia.org/wiki/Objektov%c4%9b_orientovan%c3%a9_programov%c3%a1n%c3%ad" target="_blank" style="text-decoration:underline;">oop</a> jazyk, jenž staví na JavaScriptu a poskytuje vývojářům mnohem širší spektrum technik v programování. První rozdíl, kterého si všimneme na první pohled, je silná typovost, která se v JavaScriptu nevyskytuje a umožňuje nám deklarovat typ parametrů, proměnných či návratových hodnot, jenž očekáváme, a případné chyby se dají odhalit již v době kompilace nikoli v „run time“ jako v případě JavaScriptu. Rozdílů mezi TypeSriptem a JavaScriptem je však více - například TypeScript oproti JavaScriptu musí být kompilován,  má podporu generik, volitelnost parametrů atd. Díky tomu je kód bezpečnější, robustnější a lépe udržovatelný.</p><p>V Cleverlance je jeho používání denním chlebem, píšeme v něm velké množství webových aplikací. Díky  svým rysům umožňuje psát efektivní, udržovatelný a abstraktní kód. Projekty, které řešíme za použití TypeScriptu i ve spojení s jinými knihovnami či frameworky, sahají od menších aplikací až po core systémy bank a pojišťoven.<br></p><p>Rozhodli jsme se, že se o své zkušenosti podělíme, a připravili jsme si pro vás seriál na <strong>tipy a triky používané při vývoji v TypeScriptu</strong>, který pro vás budeme na tomto blogu pravidelně na měsíční bázi zveřejňovat.</p><p>Jak víte, Utility types jsou vestavěné generické mapované typy, které nám usnadňují vytváření nových typů z již existujících tak, aby splňovaly naše požadavky, a jejichž deklarace můžeme naleznout například v lib.es5.d.ts či lib.es6.d.ts v závislosti na použité verzi jazyka. Kýženého výsledku je dosaženo voláním transformační metody nad původním datovým typem a využívaní funkcionalit, mezi které patří například keyof, typeof, indexace. Využívání těchto předdefinovaných typů nám umožňuje psát lépe čitelný a udržovatelný kód s menším množstvím chyb.</p><p>Mezi nabízené utility typy patří</p><ul><li>Partial<Type></li><li>Required<Type></li><li>Readonly<Type></li><li>Record<Keys, Type></li><li>Pick<Type, Keys></li><li>Omit<Type, Keys></li><li>Exclude<Type, ExcludedUnion></li><li>Extract<Type, Union></li><li>NonNullable<Type></li><li>Parameters<Type></li><li>ConstructorParameters<Type></li><li>ReturnType<Type></li><li>InstanceType<Type></li><li>ThisParameterType<Type></li><li>OmitThisParameter<Type></li><li>ThisType<Type></li><li>Intrinsic String Manipulation Types</li><li>Uppercase<StringType></li><li>Lowercase<StringType></li><li>Capitalize<StringType></li><li>Uncapitalize<StringType></li></ul><p>Pojďme společně postupně rozebrat jednotlivě nabízené možnosti a ukázat si také, jak naimplementovat vlastní typovou transformaci. V prvním díle našeho seriálu se budeme konkrétně věnovat  <strong>Partial<Type>.</strong></p><p> <strong>Dáme si za cíl v</strong>ytvoření nového typu z aktuálního tak, že nově vytvořený typ má veškeré položky volitelné.</p><p>Pokud chceme deklarovat položku rozhraní či parametr metody jako volitelný, tak pro tento účel použijeme Elvis operátor "?​" za názvem dané položky. Tento způsob deklarace je poněkud zdlouhavý a náchylný k chybám, jestliže chceme deklarovat veškeré položky rozhraní či třídy jako volitelné. V tento moment nám přijde vhod generický transformační typ Partial<Type>​, který můžeme naleznout například v lib.es5.d.ts. Podívejme se, jak tento typ funguje.</p><p>Mějme typový alias User, jehož definice je následující</p><pre> <code class="language-typescript hljs">type User = { firstName: string; lastName: string; age: number; }</code> </pre><p>výsledkem následujícího přiřazení <span class="pre-inline">type PartialUser = Partial​<U​ser​>;</span> je typový alias se všemi položkami označenými jako volitelné.</p><pre> <code class="language-typescript hljs">type User = { firstName?: string; lastName?: string; age?: number; }</code></pre><p>Pro demonstraci toho, že Partial<Type> označí jako volitelné pouze položky na nejvyšší úrovni, si zadefinujme adresu jako<br></p><pre> <code class="language-typescript hljs">type Address = { street: string; city: string; }</code></pre><p>a uživatele včetně adresy následovně</p><pre> <code class="language-typescript hljs">type User = { firstName: string; lastName: string; age: number; address: Address; } </code></pre> Výsledkem následujícího přiřazení <span class="pre-inline">type PartialUserNoDeep = Partial<User>;</span> pak je <p></p><pre> <code class="language-typescript hljs">type User = { firstName?: string; lastName?: string; age?: number; address?: { street: string; city: string; } } </code></pre><p>Jinými slovy - adresa sama o sobě je volitelná, pokud se ji však rozhodneme použít, tak musíme dodržet její rozhraní.</p><p>Pro úplnost ještě uvedeme implementaci</p><pre> <code class="language-typescript hljs">type Partial = { [P inkeyof T]?: T[P]; };</code></pre><h2> <strong>Kde se dá tahle vychytávka použít?</strong></h2><ul><li>Běžným případem je “update pattern", který můžeme například naleznout v knihovnách řešící state management a kde chceme zapsat jen určitou podmnožinu informací.</li><li>Dalším je případ, kdy nemáme nebo nechceme předávat celou strukturu, ale jen předat data, jež nás zajímají.</li><li>Deklarování parametrického konstruktoru s výchozími hodnotami.</li></ul><p> </p><h2> <strong>Závěrem</strong></h2><p>V článku jsme chtěli ukázat, jak se výše zmíněný typ chová, jak jej použít a na co si dát pozor, zvláště na vlastnost, kdy jsou označovány jako volitelné položky pouze ty, jenž jsou umístěny na nejvyšší úrovni.<br>Doufáme, že vás téma zaujalo. Mějte se, za měsíc se potkáme znovu a společně probereme téma týkající se Required<Type>.</p><p> <em>Václav Kandus</em><br></p><p> </p><p> <br> </p>​<br>odborné;#
TOP 3 technologické trendy pro rok 2022https://create-it.cz/Blog/Stranky/Trendy-2022.aspxTOP 3 technologické trendy pro rok 2022<p>​​Rok 2021 byl rokem digitalizace, AI, autonomních vozidel, NFT a rozvoje kryptoměn. Jen pro krátkou rekapitulaci: Elon Musk překonal Jeffa Bezose a stal se nejbohatším mužem planety. Dogecoin vzrostl o skoro 8 tisíc procent, a pak opět spadl. Clubhouse měl být revoluční VIP sociální sítí, jenže jak rychle vyrostl, tak rychle umřel. LinkedIn potvrdil, že ve velkém hacku byla kompromitována data 500 milionů uživatelů. Ransomware útoky ve světě se znásobily. Deepfake videa se stala mainstreamovými. Umělec Beeple prodal jeden svůj jpg obrázek jako NFT za 69 milionů dolarů. <a href="https://www.consumerreports.org/car-recalls-defects/tesla-recall-full-self-driving-software-phantom-braking-a5626328806" target="_blank" style="text-decoration:underline;">Bu​g</a> v autonomním řízení Tesly způsoboval náhodné brždění. A to hlavní - nedostatek čipů se ještě prohloubil, protože Taiwanské firmě TSMC <a href="https://fortune.com/2021/06/12/chip-shortage-taiwan-drought-tsmc-water-usage/" target="_blank" style="text-decoration:underline;">došla voda</a>, a tak se zhoršila dostupnost konzolí Playstation 5 a grafických karet GTX série 3000, a v podstatě všech dalších technologií závislých na 5nm čipech. Co pro nás má připraveno rok 2022?<br></p><h2>Web 3.0 - dec​​entralizovaná budoucnost internetu</h2><p> <a href="https://coinmarketcap.com/alexandria/article/what-is-web-3-0" target="_blank" style="text-decoration:underline;">Web 3.0</a>, nebo také decentralizovaný web, bude místem, ve kterém veškerá moderní technologie zkonverguje do jediného bodu. Má v něm být obsaženo vše od cloud computingu, chytrých kontraktů, NFT, AI, VR, blockchainu až po no-code (vizuální programování). Ovšem, že neznalí budou vidět Web 3.0 jen jako další hype co pomine nebo jako místo pro NFT scamy, ale je to v podstatě vize nové éry internetu, ve kterém bude všechno decentralizované a pevně v rukou uživatelů a ne korporací. Vše bude regulované přes chytré kontrakty a kryptoměny. Takže je to vlastně únik z dnešní dystopie ovládané Googlem, Facebookem, Applem a Amazonem. Díky obtížné manipulaci mají být např. mediální portály založené na Web 3.0 dobrou obranou proti vzestupu totality, jako je tomu např. v Číně. Bude nemožné cenzurovat a omezovat svobodu slova, nebude možné sledovat uživatele a monetizovat jejich soukromá data.<br></p><p>V decentralizovaných aplikacích, neboli DApps, uživatel vlastní všechna svoje data. Místo přihlašovacího jména a hesla se uživatelé identifikují přes svoje blockchainové peněženky (resp. svoje veřejné adresy, ke kterým vlastní privátní seed). Dnes se už běžně tato identifikace provádí přes prohlížečové addony, jako to dělá např. peněženka ​<a href="https://metamask.io/" target="_blank" style="text-decoration:underline;">Metamask</a>. Kód aplikace samotné pak žije na blockchainu ve formě chytrého kontraktu. Není zde tedy klasická dynamika klient-server.</p><p>Otázkou zůstává, zda moderní generace lidí ocení svobodné a decentralizované platformy. Baví je konzumovat obsah na cenzurovaných a ostře sledovaných a mysl otupujících sociálních médiích jako TikTok, který se nijak netají tím, že předává data přímo Čínské vládě.<br></p><p>​Hlavní součástí Webu 3.0 budou zejména technologie, o kterých si teď povíme více.<br></p><h2>Metaverse a VR</h2><p>Během roku 2020 a 2021 nastala rozsáhlá virtualizace pracovišť a kanceláří, protože kvůli koronavirové krizi bylo najednou potřeba pracovat plně vzdáleně. Metaverse chce tuto virtualizaci ještě urychlit a rozvinout. A co metaverse vlastně je? Podle <a href="https://www.matthewball.vc/all/forwardtothemetaverseprimer" target="_blank" style="text-decoration:underline;">definice</a> je to "Masivně škálovaná a interoperabilní síť 3D virtuálních světů vykreslených v reálném čase, kterou může synchronně a trvale prožívat efektivně neomezený počet uživatelů s individuálním pocitem přítomnosti a s kontinuitou dat, jako je identita, historie, oprávnění, předměty, komunikace a platby".</p><p>Posledních několik let je virtuální realita (VR) trendem nejen v herním průmyslu. A metaverse bude VR využívat a rozvíjet naplno. Během následujících 5 let budou vytvořeny celé virtuální světy, které budou mít vlastní ekonomiku, a budou existovat paralelně k reálnému světu. Uvnitř těchto metaversů budou účastníci provádět ty stejné úkony jako v realitě, jako je práce, socializování, tvoření nebo hraní.<br></p><p>Mark Zuckerberg nedávno přišel s jednou verzí těchto metaversů. Jeho první nápad tkví v tom udělat pracovní online meetingy více "lidské". Vadí mu, že při meetingu musíme koukat na něco jako Zoom nebo Google Meet, protože se mu často stává, že si plete lidi, když je ve velkém meetingu vidí jen ve 2D. Podle něj by lidé neměli prožívat tyto sociální interakce skrz "svítící obdélníky", jak tomu je teď. “Při klasickém online meetingu se člověk dívá na 2D mřížku tváří na obrazovce a vidí jen jejich torzo. Ale tak přece neprožíváme realitu. Jsme zvyklí na to být s někým v místnosti, mít nějaký smysl pro prostor okolo nás a vědět, kdo sedí vpravo a kdo vlevo od nás. A když někdo promluví, vím, že na mě mluví z mojí pravé strany například", řekl Mark.<br></p><p>​Podle <a href="https://www.theverge.com/22588022/mark-zuckerberg-facebook-ceo-metaverse-interview" target="_blank" style="text-decoration:underline;">Zuckerberga</a> se bude jeho verze metaversu blížit reálné teleportaci. V jeden moment můžete pracovat na virtuálních monitorech, které si mimochodem můžete díky virtuálním brýlím vzít kamkoliv, třeba do kavárny nebo do vlaku, a v moment další můžete být s kamarády na domácím promítání a pouštět si nový Matrix.</p><p>​<img src="/Blog/PublishingImages/Stranky/Trendy-2022/metaverse.jpg" alt="metaverse.jpg" data-themekey="#" style="max-width:690px;" /></p><p>Jak jsem již zmínil, důležitou součástí metaversu je VR, které je nutným nástrojem pro připojení se do​ metaversu. John Carmack, legendární tvůrce prvního 3D herního enginu, her jako Doom, Quake a prvního VR headsetu Oculus Rift, začal pracovat přímo pro Zuckerberga na VR technologii (Oculus byl koupen Facebookem v roce 2014). V roce 2019 se vzdal pozice CTO Oculusu a stal se konzultantem. Podle <a href="https://arstechnica.com/gaming/2021/10/john-carmack-sounds-a-skeptical-note-over-metas-metaverse-plans/" target="_blank" style="text-decoration:underline;">něj</a> není Zuckerbergův přístup ke stavbě metaversu správný, bude nutné začít odspodu, od technologie.</p><p>John Carmack má proto s VR další plány. Chce v budoucnu rozvinout virtuální realitu tak, aby nebylo nutné nosit VR headset, ale chce se čipem napojit přímo lidem do mozku a vysílat signály, které budou na neuronové úrovni vyvolávat vizuální odezvu. Uživatel tak doslova nebude schopen rozeznat skutečnost od virtuální reality. Jestli vám to zní jako noční můra ze seriálu Black Mirror, nebo naprosto proti přírodě, tak máme stejný názor.<br></p><p>Carmack má podle mě pokroucené chápání lidské mysli, sám o sobě v rozhovoru o VR ​<a href="https://open.spotify.com/embed-podcast/episode/6kOa4mSuZcIOEPaGmDZf9r" target="_blank" style="text-decoration:underline;">řekl</a>, že je filozofický materialista, tedy někdo, kdo vidí mozek jako stroj, který produkuje vědomí, a tím pádem lze přidat součástky a modulovat ho. Samozřejmě, že celá vize metaversu a VR může vést k snadnější manipulaci lidstva. Facebook (Meta) bude o svých uživatelích vědět už naprosto všechno. Už dnes Facebook nabízí reklamy až děsivě na míru, zdánlivě dřív, než člověka vůbec napadne něco koupit. Bude to dokonalá verze Orwellova dystopického světa 1984? <br></p><p>Tento postup je ale už nezadržitelný. Rok 2022 bude začátkem pro rozvoj metaverse světa. Zuckerberg si představuje, že během 5 let by měla jeho vize být realitou.<br></p><h2>Ethere​um 2.0, NFT a NFT gaming</h2><p>K masivnímu rozvoji dojde samozřejmě i u kryptoměn, zejména u Etherea. Nastane u něj totiž konečně přechod na Proof-of-Stake algoritmus a Ethereum se tak stane netěžitelným. Na tomto přechodu se pracuje již roky. Na přelomu prvního a druhého kvartálu 2022 má k "The Merge" (Velkému Sloučení) konečně dojít. Nynější Mainnet se sloučí s beacon chainem - implementační detaily o tomto Sloučení naleznete na <a href="https://ethereum.org/en/eth2/merge/" target="_blank" style="text-decoration:underline;">oficiálním webu zde</a>. A jen tak na okraj - těžařské farmy používají k těžbě mimo ASIC chipů také nové grafické karty GTX řady 3000. Nejvýdělečnější měnou pro těžbu <a href="https://2cryptocalc.com/what-to-mine-with-3090" target="_blank" style="text-decoration:underline;">zůstává Ethereum</a>, proto očekávám, že po přechodu na netěžitelnou verzi se začnou tyto karty aspoň částečně vracet do oběhu, až je začnou těžaři prodávat, a jejich nafouknutá cena se konečně vrátí do normálu. Pokud tedy plánujete upgrade svého PC, může být pro dobro vaší peněženky pár měsíců počkat.​</p><p>Kryptoměny, které stále běží na Proof-of-Work algoritmu, tzn. že jsou těženy a musí pro to být spáleno značné množství elektrické energie, jsou neustále předmětem kritiky environmentálních aktivistů. Ethereum 2.0 má po tomto "Sloučení" využívat o 99% méně <a href="https://forbes.cz/krypto-green-ethereum-2-0-chce-palit-o-9995-procent-mene-energie-nez-doposud/" target="_blank" style="text-decoration:underline;">elektrické energie</a>​, takže snad konečně nebudou jeho cenu negativně ovlivňovat mediální zprávy o globálním oteplování. Realisticky ale potrvá měsíce nebo roky, než si po této změně lidé přestanou asociovat Ethereum (a kryptoměny všeobecně) s environmentální katastrofou a globálním oteplováním. Po "Sloučení" se má též několikanásobně zvýšit rychlost sítě. Momentálně podporuje Ethereum 30 transakcí za sekundu, po přechodu na verzi 2.0 to má být až 100 tisíc za sekundu. Jako příprava na přechod z Proof-of-Work na Proof-of-Stake se od 5. srpna 2021 na Ethereovém blockchainu aktivně "pálí" část Ethereových poplatků. Ty už se zkrátka nepřipisují na účet těžařům, ale spálí se zasláním na tzv. eater adresu, v podstatě černou díru, kterou nikdo nevlastní. Sníží se tak počet nových ETH, které se dostanou do oběhu, a tím začne docházet k deflaci. </p><p>Dalším významným efektem bude podle mého názoru smrt tzv. "Ethereum-killers". Přezdívají si tak měny jako Solana, Cardano, nebo Polkadot. Jejich hlavní výhodou mají být nízké poplatky a rychlejší transakce, než u Etherea. Kvůli extrémní popularitě ETH a zahlcenosti sítě NFT hypem je momentálně průměrný "Layer 1" poplatek za transakci cca 15 dolarů, i když jde o poslání třeba 5 dolarů. Pro řádově nižší poplatky lze použít "<a href="https://l2fees.info/" target="_blank" style="text-decoration:underline;">Layer 2</a>". Zvýšení propustnosti sítě u Ethereum 2.0 by teoreticky mělo tyto poplatky snížit. Hlavním argumentem zmíněných měn je používání Proof-of-Stake, který je šetrný vůči životnímu prostředí. Všechny tyto měny ztratí svoji výhodu po příchodu Ethereum 2.0. Nebudou mít již žádné pádné argumenty, proč by měly být lepší než Ethereum. Osobně je vidím jako arogantního Kaina, který se snaží zabít vznešeného Abela.</p><p>O NFT, DeFi a NFT gamingu jsem psal v <a href="/Blog/Stranky/NFT.aspx" target="_blank" style="text-decoration:underline;">říjnovém článku</a> a vypadá to, že moje předpověď pádu NFT gamingu se začíná naplňovat. Prvním příkladem je marketingové fiasko 13 let očekávané hry Stalker 2. Její vydavatel GSC na svém twitteru oznámil integraci hry s NFT, kdy bude možné koupit si slot s NPC metahuman postavou, a tím zvěčnit svoji podobu ve hře (jinými slovy naskenovat člověka do hry jako herní postavu za kryptoměnový poplatek). GSC ovšem nečekalo, že toto oznámení způsobí pohromu ve fanouškovské komunitě. Pro statisíce hráčů byl další díl Stalkera jako poslední ostrov naděje na normální klasickou hru bez monetizací v hyperkorektní době a oznámení integrace s NFT tuto naději zničila. Desítky tisíc rozhořčených hráčů přestalo ihned sledovat sociální sítě GSC a zrušilo předobjednávky. Vydavatel si ihned uvědomil svou chybu a druhý den ​<a href="https://twitter.com/stalker_thegame/status/1471620399997886472" target="_blank" style="text-decoration:underline;">vydal oznámení</a> o zrušení jakékoliv integrace s NFT. Veřejné mínění komunity je zhruba takové, že NFT a kryptoměny jsou zkázou pro životní prostředí. Samozřejmě, že se lidé bojí toho, čemu nerozumí. Jak jsem popisoval výše, změny v kryptoměnovém světě zajistí nízkou spotřebu energie. A NFT je revoluční koncept, který je ale bohužel využíván pro podvody, a proto má negativní reputaci.</p><p>Dalším příkladem je <a href="https://www.pcgamesn.com/ghost-recon-breakpoint/ubisoft-quartz-nft-games-platform" target="_blank" style="text-decoration:underline;">Ubisoft Quartz</a>, NFT platforma Ubisoftu. Ihned po oznámení obdržel jejich trailer na youtube 38 000 "disliků" - to bylo ovšem předtím, než Google začal cenzurovat počet "disliků" na YouTube, aby <span style="text-decoration:underline;">"</span><a href="https://blog.youtube/news-and-events/update-to-youtube/" target="_blank" style="text-decoration:underline;">vytvořil inkluzivní a bezpečné prostředí, které ochrání menší tvůrce před nenávistí</a>". Každopádně, veřejný konsenzus je takový, že NFT v gamingu jen zhorší situaci okolo mikrotransakcí a Pay-To-Win her.</p><h2>​2022​</h2><p>Rok 2022 bude tedy rokem decentralizace a boje za svobodu slova. I když metaverse zní jako noční můra, měl by být implementován na decentralizovaném systému, nebo minimálně používat kryptoměny ve svém ekosystému. NFT scamy doufejme ustanou a mainstream média začnou psát o NFT v pozitivním světle. Ethereum 2.0 přinese naprostou změnu ve světě kryptoměn. Web 3.0 bude hlavním tahounem tohoto rozvoje. Kdo se rychle adaptuje a začne se učit psát pro něj aplikace a využívat jeho decentralizovanost, bude u zrodu nové éry internetu, kde bude teoreticky nemožné kohokoliv cenzurovat, technologické korporace nebudou mocnější než celé státy, politická korektnost bude udušena, odpovědnost jednotlivce bude rozvíjena, a kolektivní vědomí lidstva se posune daleko od nebezpečí totality.<br></p><p> <i>Jan Jileček​</i></p><p> <br> </p>odborné;#hobby;#vzdělávání;#
Pantone barva roku 2022https://create-it.cz/Blog/Stranky/pantone_2022.aspxPantone barva roku 2022<p>Pantone Colour Institute, zabývající se již přes 20 let predikcí barev, si po loňské barevné dvojici opět připravil překvapení. Svět je plný změn a nejen v Pantone věří, že to budou změny příjemné. Novým odstínem se stala barva Very Peri. Jak přijmou Češi odstín květů brčálu?</p><p> V Pantone Colour Institute vytvořili a spravují standardizovaný systém barev, který disponuje přes 2,5 tisíci přesně definovaných odstínů. Jsou kategorizovány podle druhu potiskovaného materiálu (mají vzorníky pro natírané i nenatírané papíry, textil nebo plast, či vzorníky podle druhů barev –⁠ speciální pro metalické nebo zářivě neonové palety a další). Ani tato velká knihovna ale nestačila pro reflexi blízké budoucnosti. Pantone poprvé v historii vytvořilo zbrusu nový odstín, který akcentuje naši dobu změn a inovací. Doteď byla barva roku volena ze stávajících vzorníku na základě aktuálních společenských a kulturních událostí.<br></p><p> Nacházíme se v době změn, po všemožných lockdownech a odloučení se naše vnímání světa a standardy mění. Digitální technologické sliby se postupně stávají skutečností, naše hranice reality se rozšiřují s virtuálním a digitálním prostorem. Dynamicky objevujeme nové trendy v herním průmyslu, metaverse nebo možnosti digitálního umění přes NFT.<br></p><p style="text-align:center;"> <img src="/Blog/PublishingImages/Stranky/pantone_2022/pantone-0639-2.jpg" alt="pantone" data-themekey="#" style="max-width:690px;" /> <br> </p><p> Celý tento digitální přechod jen akceleroval kreativitu v Pantone Colour Institute, jehož odborníci přišli s odstínem nazvaným Very Peri (PANTONE 17-3938). Vytvořili světlý odstín fialové, který snoubí modrou (znamenající vděčnost a stálost) s podtóny červené (symbolizující energii, život, nové možnosti a nadšení z nových zítřků). Barva roku 2022 má posílit naši sebedůvěru a stimulovat zvídavost a kreativitu. Peri v názvu odstínu vychází z Periwincle – česky barvínku, stálezelené rostlinky s fialovými květy (tedy v barvě Very Peri)​, možná ji znáte pod jejím lidovým názvem brčál. České spojení brčálová zelená vychází z latinského pojmenování barvínku a naráží na to, že rostlina vítězí nad zimou a je zelená po celý rok.  Angličtina se naopak zaměřuje na barvu květů a Periwincle blue/violet odkazuje ke krásnému odstínu fialkové. </p><p> V západní společnosti fialová symbolizuje majestátnost a odkaz na církevní hodnostáře a je přijímána s nadšením. V průzkumu agentury STEM/MARK z roku 2017 obsadila v oblíbenosti barev mezi Čechy 5. příčku. Snad se nenecháme ovlivnit názvem spojeným s brčálem a tuto krásnou živou barvu necháme zářit v designech příštího roku. V digitální agentuře QUB už jsme na designování s novou barevnou paletou připraveni a moc se těšíme na neotřelé kombinace, které tento odstín nabízí. Jak by se vám třeba líbila aplikace v barvách Very Peri v kombinaci s trendy khaki zelenou? Barva roku 2022 bude super v dark i light modu! </p><p> Za <a href="http://qub.digital/">QUB Digital</a>,</p><p> Ivana Stránská </p> <br>odborné;#vzdělávání;#
​​​Pro DevOps je důležitá celková změna myšleníhttps://create-it.cz/Blog/Stranky/DevOps.aspx​​​Pro DevOps je důležitá celková změna myšlení<p>​Přesná definice a vymezení DevOps je velice těžká otázka často i pro odborníky, kteří se tímto oborem zabývají polovinu své profesní kariéry. Zkusíme v tomto krátkém článku přiblížit, co tato role zahrnuje a čemu se naopak snaží vyhýbat. V centru pozornosti jsou vývojáři (developers) a systémoví administrátoři a správci pro nasazování do prostředí (operations).<br></p><p> V počátcích technologického vývoje, se projektový tým, který vytvářel aplikace, skládal z vývojářů, analytiků, testerů, systémových administrátorů, síťařů a specialistů na hardware. Pokud byl tento tým sehraný, bylo z poloviny vyhráno. Velice zjednodušeně: Lidé zodpovědní za vývoj vytvořili aplikaci (vývojáři) a předali ji systémovým administrátorům, kteří ji nasazovali (jakkoliv automatizovaně) na hardware v serverovně. </p><p> Ne zas tak dávno přišel ke slovu tzv. agilní přístup k vývoji. Ten se tím rapidně zrychlil a komunikace mezi vývojáři a operations byla čím dál složitější. V podstatě pak stačilo málo aby produkt, (nebo jeho verze) na který klient netrpělivě čeká, nebyl vůbec doručen. Produkt, nebo jeho verze byla případně doručena, ale se značnou chybovostí. Na vině byla, a většinou stále je, komunikace mezi různými částmi týmu. </p><p> Existují tedy vývojáři a operations. Tyto dva tábory se spolu možná sice snaží komunikovat a domlouvat, ale v praxi je to velice složité. Každý mluví takříkajíc vlastním jazykem, případně jiným nářečím. To, co je jednoduché z pohledu vývoje, nemusí být implementovatelné na serverech z pohledu infrastruktury. A to, co je velice snadno řešitelné v infrastruktuře bude zase velice těžký oříšek pro vývojáře. </p><p> Co by se stalo, kdybychom měli vývojáře a poslali ho na studia k operations? Nebo z druhé strany, měli někoho z operations a poslali ho na výzvědy k vývojářům? Tímto krokem nakonec vznikne někdo, kdo si může říkat DevOps specialista. Aby si tento titul ale opravdu „zasloužil“, musí pochopit více, než z čeho projekt je a kam se implementuje. Musí změnit zejména způsob myšlení. </p><p> Mluvíme o celé sadě postupů, které automatizují a standardizují procesy mezi vývojem software a operations, tak aby bylo možné SW “buildovat, testovat a releasovat” rychleji a spolehlivěji. </p><p> <b>New Mindset + New Tools + New Skills = DevO​​​ps</b></p><h2> You build it, you run ​it!</h2><p> Základní myšlenkou je, že DevOps není jen technologie, ale celé paradigma vývoje. Aby to ve firmě fungovalo, je třeba změnit nejen používané aplikace, ale celý přístup k vývoji, testování i nasazování do produkce a vůbec celé uvažování nad tímto procesem. </p><p> Dříve by to byla utopie, ale dnes už je možné pronajmout a nechat si spravovat celé clustery s propojením na nejrůznější služby od databází (např. PostgreSQL, MySQL nebo CockroachDB), přes fronty (jako Kafka či RabbitMQ), analytické systémy (Hadoop), logovací a monitorovací infrastrukturu (Elasticsearch, Kibana, Grafana) až po nejrůznější IoT služby a REST API. A jak jinak urychlit celý proces od vytvoření až po nasazení aplikace, než tím, že si budete umět tyto aplikace spouštět sami.<br></p><p> <img src="/Blog/PublishingImages/Stranky/DevOps/Hybrid%20Cloud%20Architecture.png" alt="Hybrid Cloud Architecture.png" data-themekey="#" style="max-width:690px;" /> <br> </p><h4 style="text-align:center;"> Hybrid Cloud Archite​​​​cture </h4><h2> Virtual Private Clo​​​​ud</h2><p> Pokud firma provozuje nějakou aplikaci, je dnes trendem místo vlastní on-premise infrastruktury používat cloud. Cloudová infrastruktura dnes už může být optimalizovaná pro vysokou dostupnost, pro nízkou latenci, dokonce lze nastavit, že například zákazníci z Čech budou využívat datový cloud v Německu a zákazníci z Francie ve Francii. Moderní cloudy splňují vysoké standardy zabezpečení a další výhodou je možnost používat řadu technologií spojených s jejich provozem jako službu. V reálu to znamená, že si firmy nemusejí držet specialisty, kteří se budou starat o infrastrukturu, její údržbu a instalaci, protože to vše dostanou jako službu, ve které formou tzv. microservices provozují své aplikace. Šetří se tedy (dnes tak nedostatkové) lidské síly i peníze. Důležité je vyvíjet nové aplikace jako cloud native. Nejčastější cloudy, se kterými se setkáte, jsou Azure, AWS a Google Cloud. </p><p> <img src="/Blog/PublishingImages/Stranky/DevOps/iot.png" alt="iot.png" data-themekey="#" style="max-width:690px;" /> <br> </p><h4 style="text-align:center;"> Internet of Things Arc​hitecture <br></h4><h2> Microservice architectu​​​re</h2><p> Dříve se většina aplikací vyvíjela jako monolitická. Dnes se dělají aplikace z menších částí, které spolu přes jedno rozhraní vzájemně komunikují. Výhoda? Ty monolitické startují třeba čtvrt hodiny, menší aplikace v řádu desítek vteřin. U microservice architektury se vždy snažíme, aby byla nasazovaná jako Platform as a Service nebo Software as a Service. </p><p> Oblíbenou metodologií je v této oblasti "The Twelve-Factor App", která je vlastně souhrnem pravidel, která zásadně zpřehlední vývoj, pokud je dodržuje celý tým. Popisuje, jak zacházet s kódem, kde ukládat konfigurace, co se zálohami, buildy, jak na škálování, logy či administraci.<br></p><p> <img src="/Blog/PublishingImages/Stranky/DevOps/Caching%20Cluster%20Architecture.png" alt="Caching Cluster Architecture.png" data-themekey="#" style="max-width:690px;" /> <br> </p><h4 style="text-align:center;"> Caching Cluster Arc​​​hitecture <br></h4><h2> Serverless architect​​​ure</h2><p> Další velice zajímavý stavební kámen architektury moderních aplikací je „serverless”. Z výše zmíněných malých aplikací se zkrátka vezme část kódu, která může být výpočetně náročná, nebo naopak není potřeba její neustálý běh, použije se k tomu interface, který vystavuje jak AWS (AWS Lambda) tak Azure (Azure Functions), ten si nastartuje malé subprocesy, spočítá výsledky a vrátí je zpět do servisy. Dokáže se škálovat i na úrovni funkcí, které mohou běžet paralelně a nezávisle. </p><p> <img src="/Blog/PublishingImages/Stranky/DevOps/Serverless%20Application%20Architecture.png" alt="Serverless Application Architecture.png" data-themekey="#" style="max-width:690px;" /> <br> </p><h4 style="text-align:center;"> Serverless Applic​​ation Architecture<br></h4><h2> Automati​​​zace</h2><p> Nezmínili jsme ještě jednu vhodnou vlastnost pro DevOps a tou je lenost. DevOps si snaží maximálně ulehčit život automatizací. A automatizace je alfou a omegou dnešního DevOps vývoje. Automatizujeme nasazování, pracovní procesy, testování, infrastrukturu, i správu a revizi uživatelských práv a přístupů, prostě všechno. Kdy s automatizací začít? Pokud je potřeba jakoukoliv činnost opakovat víckrát, než jednou.</p><h2> Automatizované tes​​tování kódu</h2><p> Abychom mohli vyvíjet rychle a měli jistotu, že jsme nikde nic ne​rozbili, musíme mít vše pokryté testy, které si píší sami vývojáři. Tato myšlenka dotažena ad absurdum znamená, že by se měl naprogramovat nejdřív test a pak až funkce. Test Driven Development ostatně není v oblasti vývoje softwaru žádná novinka. Nečekat na testery a psát si testy samostatně patří to k tomu výše zmiňovanému DevOps přemýšlení. </p><p> Ve světě Javy za tímto účelem používáme JUnit, Mockito, MockMvc, Selenium, Sonar atd. Nástrojů je tedy dost, častěji chybí ochota vývojářů se touto činností zabývat.</p><h2> Automatizace wo​​rkflows</h2><p> Pro automatizaci pracovních postupů používáme nástroje jako Jenkins (CI/CD), GitLab, Container Registry, Jira. V praxi to vypadá tak, že vývojář umístí svůj kód do GitLabu, automatická pipeline nad ním spustí unit testy, zkompiluje program a nasadí ho do prostředí na server, kde pak bude kontinuálně monitorovaný. V ideálním případě opravdu vše běží samo. </p><h2> Automatizace infrastruktury: Infrastruktur​​​a jako kód!</h2><p> Ideální konečný stav je, aby na všech prostředích vše běželo vždy stejně a aby se tato prostředí vytvořila na pouhé kliknutí. Nikdo tedy neinstaluje operační systém, všechno by mělo být naskriptované pomocí různých šablon. Abychom mohli vytvořit infrastrukturu jako kód, musíme nejdříve odstínit aplikaci od hardware. O to se starají například nástroje jako Docker a Podman. Vytvořenou aplikaci vezmeme a nasadíme do nějakého ekosystému – dnes nejčastěji buď Kubernetes nebo OpenShift. Všechno může běžet i on-premise, ale to není tak zásadní, oč v DevOps běží. Jak Kubernetes, tak OpenShift lze provozovat po několika kliknutích. Kubernetes běží hostovaně u všech velkých poskytovatelů (AWS EKS, Azure AKS, nebo Google GKE).</p><p> U infrastruktury máme několik možností. Můžeme „naklikat“ infrastrukturu z pohodlí webového prohlížeče, nebo, a to je více preferované, vytvořit šablonu, podle které bude poskytovatel vytvářet infrastrukturu přímo přes API vrstvu. </p><p> Nejrozšířenější univerzální šablonový software je Terraform. Obsahuje napojení na všechny velké poskytovatele, nebo je možné použít on-premise servery. Snazší a mnohdy lepší, je napsat tyto šablony v nativních scriptech (u AWS např.​ CloudFormation v YAML a JSON, nebo nově AWS CDK, kde je možné popsat infrastrukturu např. JavaScriptem, v JAVA nebo Python). Tím se možnosti poskytovatele využijí na maximum. Tuto šablonu pak stačí pustit a lze s ní vytvořit identické prostředí i několikrát za sebou (vhodné pro různé environmenty dev/test) Samotné aplikace lze do prostředí dodávat pomocí všech známých nástrojů od Jenkins, Gitlab, Bitbucket.</p><h2> Mě​​​ření</h2><p> Aplikaci máme v produkci, ale tím to nekončí. Je potřeba ji začít vyhodnocovat, analyzovat a opravovat chyby, potřebujeme tedy kontinuální metriky a nástroje pro analýzu. Ke sběru logů a jejich vizualizaci lze využít ELK Stack, což je celý balík nástrojů pro tyto účely. Kibana je nástroj, který umožňuje procházení logů ve vizualizované formě na jednom místě, což perfektně umožňuje zjistit výkon aplikace i případně odhalit, kde je přesně problém, vedle filtrování chyb lze zobrazit i metriky z CPU atd.</p><h2> Meto​dika</h2><p> Dříve tak oblíbený a často používaný vodopádový přístup sice umožňuje pečlivý, ale v žádném případě ne rychlý vývoj. Proto se dnes používají tak často skloňované agilní metodiky, které umožní rozdělit vývoj na malé části a provádět ho po kouscích. Když se nad tím zamyslíte, je to v zásadě podstata celé DevOps filozofie - od infrastruktury až po metodiku a naopak. Praktikujeme tedy denní standupy a vývoj běží v krátkých sprintech. Důležitá je standardizace celého vývojového procesu, počínaje analýzou, přes vývoj, testování, nasazování až po monitorování výkonu hotové aplikace.</p><h2> Zá​věr</h2><p>​​​​Pro úspěch DevOps projektu je potřeba kombinace odborných znalostí, kvalitní technologie, řemeslné zkušenosti, ale hlavně změna nastavení fungování týmu a uvažování vývojářů. Ale pak to stojí za to. Dobře nastavený projekt pak umožňuje rychlejší inovace, je schopen obratem reagovat na požadavky byznysu, spolupráce týmu je efektivnější, stoupá celková kvalita kódu a výsledkem jsou častější releasy.<br></p><p> <em>Vojtěch Kijenský</em><br></p>odborné;#
NFTs, DeFi, chytré kontrakty a jaká je jejich budoucnosthttps://create-it.cz/Blog/Stranky/NFT.aspxNFTs, DeFi, chytré kontrakty a jaká je jejich budoucnost<p>​Hlavními trendy ve světě kryptoměn jsou teď decentralizované finance, DeFi, a non-fungible tokens, NFT. Obě technologie mohou využívat tzv. chytré kontrakty. V tomto článku se podíváme na všechny 3 zmíněné pojmy, popíšeme si, co znamenají pro vývoj kryptoměn a kde se používají, a také zvážíme jejich výhody a nevýhody. Všechny 3 technologie se točí hlavně okolo Etherea, platformy, na které dnes stojí hodně altcoinů. Doporučuji přečíst si také moje starší články o tom, jak funguje <a href="/Blog/Stranky/Blockchain.aspx" style="text-decoration:underline;">blockchain</a>, a dva díly (<a href="/Blog/Stranky/altcoiny1.aspx" style="text-decoration:underline;">I.</a>, <a href="/Blog/Stranky/altcoiny2.aspx" style="text-decoration:underline;">II.</a>) o alternativních kryptoměnách.<br></p><h1>DeF​​i<br></h1><p>DeFi je zkratka pro decentralizované finance. Tento pojem pod sebou zastřešuje různé finanční a blockchainové aplikace, které mají za cíl zbavit se prostředníků v transakcích.</p><p>DeFi se inspiruje zejména blockchainem, tedy technologií, na které stojí většina dnešních kryptoměn. Jen pro zopakování, blockchain umožňuje více entitám držet kopii historie transakcí, takže není pod kontrolou jednoho centralizovaného zdroje. To je důležité, jelikož centralizované systémy mohou omezovat rychlost a sofistikovanost transakcí, a zároveň omezit uživateli kontrolu nad vlastními penězi. DeFi rozšiřuje funkcionalitu blockchainu z jednotlivých transakcí na komplexnější finanční systémy.</p><p>Přímé prodeje nejsou jediným typem transakce nebo kontraktu mezi velkými společnostmi; finanční aplikace jako půjčky, pojištění, crowdfunding nebo sázení jsou také pod jejich kontrolou. Zbavení se prostředníka v těchto transakcích je jednou z hlavních výhod DeFi.</p><p> <b>Podívejme se na pro a proti DeFi ve srovnání s klasickým bankovním systémem:<br></b></p><h2>Ty držíš svoje peníze VS banka drží tvoje peníze</h2><p>Ano, člověk má absolutní moc nad svými penězi. Je tu ale nebezpečí, že ztratí nebo zapomene svůj seed, a všechny kryptoměny jsou navždy ztraceny. U bank je určitá jistota, že se o klientovy peníze postarají v případě nějakého hacku. Pak je tu samozřejmě inflace, ale ta existuje v obou případech. Kryptoměny jsou v bezpečí alespoň do příchodu dostatečně výkonných kvantových počítačů (což zabere minimálně dalších 50 let), schopných <a href="https://en.wikipedia.org/wiki/Post-quantum_cryptography" style="text-decoration:underline;">překonat</a> asymetrické šifrování. Až se to stane, tak bude mít problém celý technologický svět, nejen kryptoměny, u kterých najednou půjde odvodit seed z veřejné adresy peněženky. (více o seedech v <a href="/Blog/Stranky/Blockchain.aspx" style="text-decoration:underline;">prvním článku</a>).</p><h2>Transakce zabírají minuty VS transakce mohou zabrat dny</h2><p>U kryptoměn jsou transakce velice rychlé. Tedy v případě, že není zahlcena síť, jak tomu bylo např. na konci roku 2017, kdy průměrný poplatek za transakci dosahoval 42 dolarů. Pokud jste zaplatili méně, na transakci jste mohli čekat hodiny až dny. Vše je ovlivněno transakčními poplatky. Čím vyšší poplatek za transakci, tím dříve se uskuteční. Ethereum 1.0 podporuje až 30 transakcí za sekundu, Ethereum 2.0 bude zvládat až 100 tisíc transakcí za sekundu a Bitcoin zvládá 7 transakcí za sekundu.</p><h2>Transakce jsou pseudo-anonymní VS transakce jsou svázané s identitou</h2><p>Kryptoměny nejsou svázané s identitou, jako je tomu u bank, takže se často používají pro vyhnutí se daním a pro nelegální činnosti. Pokud by byly kryptoměny dále neregulované a opravdu by nahradily klasické peníze ve velkém měřítku, tak by mohly vést k rozpadu států, protože by do státní kasy neproudily daně od občanů. Kryptoměny jsou ve své podstatě anarchistické, a toto jejich jádro by se manifestovalo v reálném světě. Na druhou stranu, ve státech s utlačujícím totalitním režimem jsou kryptoměny cestou ke svobodě.</p><p>Potenciálně nebezpečné následky lze vidět i u novinky ze Severní Korei. Virgil Griffith, jeden ze zakladatelů Etherea, se tento týden <a href="https://www.bleepingcomputer.com/news/security/ethereum-dev-admits-to-helping-north-korea-evade-crypto-sanctions/">u soudu přiznal</a>, že v roce 2019 pomáhal Severní Koreji, aby se za použití Etherea vyhnula sankcím USA a učil je jak prát peníze. Griffith byl v minulosti vyhozen z týmu Tor vývojářů za prodávání de-anonymizovaných dat, takže je zřejmé, že není naivní a Koreji pomáhal vědomě. Severní Korea <a href="https://www.csfd.cz/film/923232-krtek-spionem-v-severni-koreji/recenze/">nemá finanční zdroje</a> a anonymita kryptoměn by jim mohla velice pomoci ve zbrojení a rozšíření svého vražedného totalitního režimu za hranice. Takových příkladů je možné použít více, např. ze světa organizovaného zločinu. Bude také zajímavé sledovat, jak dopadne pokus v <a href="https://www.nbcnews.com/news/latino/el-salvador-hits-snags-adopts-bitcoin-official-currency-first-country-rcna1910">El Salvadoru</a>, kde tamní prezident uzákonil Bitcoin jako hlavní měnu.</p><h1>NFT​​​​s</h1><p>NFTs, non-fungible tokens, jsou nenahraditelné nebo nezaměnitelné tokeny. Například jedna mince je zaměnitelná, protože představuje to stejné jako další mince stejné hodnoty.</p><p>Většina kryptoměn je také zaměnitelná. Jeden Bitcoin se rovná jednomu Bitcoinu. Nezaměnitelné tokeny však, jak název napovídá, nelze zaměnit. Tyto digitální soubory, vyražené (“<a href="https://coinmarketcap.com/alexandria/article/how-to-mint-an-nft#header-6">minted</a>") do blockchainu, představují majetek, který je jedinečný a vzácný.</p><p>Záznam vytvořený na blockchainu dokáže ověřit kdo je kdo a hlavně kdo jej vlastní. Při převodu vlastnictví dochází také k záznamu. Lze si snadno představit, jak tento systém může změnit způsob, jakým zaznamenáváme a přenášíme digitální vlastnictví. Soubory dnes běžně posíláme online, ale NFT přidává další vrstvu ověřování dat, tudíž lepší zabezpečení.</p><p>Existují i chytré kontrakty (o těch si povíme níže), kdy tvůrce může kódovat licenční poplatky do svých NFT, takže kdykoliv bude aktivum znovu prodáno na trhu, bude mu připsán výdělek za přeprodej díla. Tento záznam je na blockchainu uložen na věčnost, takže tvůrce může obdržovat legální výdělky z díla po celý zbytek života.</p><p>Umělec Beeple <a href="https://www.theverge.com/2021/3/11/22325054/beeple-christies-nft-sale-cost-everydays-69-million">prodal</a> v březnu svoje NFT za 69 milionů dolarů. NFTs se však netýkají jen umění, mohou držet jakýkoliv druh dat. Jsou skoro jako nový formát souboru.  NFTs jsou jen pár kroků od toho, aby byly použity pro jízdenky, prodej pozemků a možná i cenných papírů. Je tu však stále možnost, že NFTs jsou jen další bublinou, dalším výstřelkem, který rychle pomine. Zatím to vypadá, že NFT využívají hlavně influenceři, kteří jsou schopni díky svému rozsáhlému publiku prodat i umělecké kýče.</p><p>Některé altcoiny se také snaží spojit NFT s herním světem. Pak by herní předměty, jako např. meče ve WoW nebo lodě v EVE Online, byly navždy majetkem hráče. Podle mého názoru jsou však tyto snahy až přehnaně ambiciózní a neskončí úspěšně. U umění mají NFT smysl, ale hráčům je víceméně jedno, jakým způsobem vlastní herní virtuální předměty. Záleží hlavně na herní ekonomice a trhu (jak tomu je u Team Fortress 2 klobouků nebo CS:GO skinů, trhů, které mají <a href="https://www.youtube.com/watch?v=t8QEOBgLBQU">větší kapitalizaci než některé reálné státy</a>). Přechod na blockchain by vyžadoval masivní předělání základů hry, a u starých her jako WoW je toto skoro vyloučeno. Většina her má jen omezenou podporu ze strany vývojářů a i u fenoménů jako je CS:GO se po čase přejde hlavně na kosmetické změny. Proto by tyto altcoinové projekty musely vyvinout i svoje AAA herní tituly nebo doufat, že jejich systém využijí vývojáři pracující na nové hře velikosti Fortnite.</p><p>Velké herní distribuční platformy jako je <a href="https://www.nme.com/news/gaming-news/steam-is-removing-nft-games-from-the-platform-3071694">Steam už dnes banují NFT hry</a> ze svého obchodu. Určitě totiž nebudou podporovat něco, co je může ochudit o výdělky. Jak Valve, tak Apple i Google si berou 30% z příjmů z vnitřní herní ekonomiky. Takže těmto NFT projektům nebude stačit vyvinout AAA herní tituly, ale dokonce budou muset vybudovat distribuční systémy a jejich reputaci, aby byli schopni konkurovat platformám Epic Store a Steam. Zkrátka, adopce blockchainu bude pomalá, a je dost možné, že tento výstřelek NFT gamingu rychle pomine. Ale možná se mýlím.</p><h1>Smart Contracts</h1><p>Smart contracts, neboli chytré kontrakty, jsou jednoduché programy, které běží na blockchainu. Je to sbírka funkcí a stavů, které jsou spojeny s určitou blockchainovou adresou. Nejpopulárnější implementací tohoto protokolu je měna Ethereum, proto se budeme věnovat hlavně jí. Dají se využít jak v DeFi, tak v NFT.</p><p>Chytré kontrakty jsou typem Ethereového účtu, tzn. že mají nějaký zůstatek a mohou posílat transakce přes síť. Nejsou nicméně pod kontrolou uživatele, ale jsou nasazeny do sítě a běží podle svého programu. Uživatelské účty pak mohou s těmito kontrakty komunikovat zasíláním transakcí, které provedou funkci definovanou v kontraktu. Chytré kontrakty mohou určovat pravidla, stejně jako běžný kontrakt, a automaticky vynucovat jejich dodržení. Interakci, která s kontraktem proběhne, už nelze vzít zpět.</p><p> <a href="https://en.wikipedia.org/wiki/Nick_Szabo" style="text-decoration:underline;">Nick Szabo</a>, který v 90. letech přišel s konceptem chytrých kontraktů, tedy dlouho před vznikem Bitcoinu, popisuje tyto kontrakty jednoduchou metaforou - jako automat na kávu. Pokud kontrakt obdrží správný vstup, vygeneruje určený ​výstup. Níže uvádím příklad kódu takového c​hytrého kontraktu, v jazyce Solidity.<br></p> <img src="/Blog/PublishingImages/Stranky/NFT/eTe7.png" alt="eTe7.png" data-themekey="#" style="margin:0px;max-width:690px;height:735px;" /> <p></p> Stejně jako reálné automaty na kávu nevyžadují zaměstnance pro prodej kávy, chytré kontrakty mohou nahradit prostředníky v mnoha oborech. <p>- - - - -</p><p>To je o dnešních trendech vše. Původně jsem chtěl psát další článek o alternativních kryptoměnách, jako je Solana nebo Polkadot, jimž se přezdívá “Ethereum-killers", ale zvolil jsem abstraktnější přístup. ​​​U Solany totiž nedávno nastalo masivní fiasko, kdy se ukázalo, že je naprosto centralizovaná (vývojáři byli schopni vypnout celou transakční síť). Tyto přehnaně ambiciózní projekty skoro vždy vedou k nezdaru, jak se za roky ukázalo u měn jako byla např. IOTA. Proto při investicích doporučuji staré známé a ověřené coiny, které tu zaručeně budou i za 10 let, tzn. Bitcoin, Ethereum a Cardano. ​<br></p><p> <em>Jan Jileček</em><br></p><p> <br> </p>odborné;#hobby;#vzdělávání;#