Create IT Blog - vzdělávání

 

 

Testing Clever Akademiehttps://create-it.cz/Blog/Stranky/testing-akademie.aspxTesting Clever Akademie<p style="display:none;">​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​Vstup s námi do světa IT a pojď se naučit testovat software!​ Naši průvodci tě provedou cestami a stezkami až na tvou pomyslnou K2 – získáš svou příležitost v jiném oboru, ve kterém zúročíš své analytické a kritické myšlení.<br></p> ​<div class="ms-rtestate-read ms-rte-wpbox" unselectable="on"><div class="ms-rtestate-notify ms-rtestate-read 7011e392-79f3-4920-88bc-448b0e5808ac" id="div_7011e392-79f3-4920-88bc-448b0e5808ac" unselectable="on"></div><div id="vid_7011e392-79f3-4920-88bc-448b0e5808ac" unselectable="on" style="display:none;"></div></div><p>​​<br>​<br>​<br></p>vzdělávání;#
V Cleverlance mě to nepřestává bavit ani po 12 letechhttps://create-it.cz/Blog/Stranky/rozhovor-petra-m.aspxV Cleverlance mě to nepřestává bavit ani po 12 letech<p>​​​​​​Dělat rozhovor s mladou a chytrou ženou je vždy radost. Pokud je to vaše kolegyně, se kterou máte možnost se potkávat v Cleverlance již 12 let, je ta radost dvojnásobná. Dnes vám představíme Petru M., které jsme se zeptali, co se za její profesní kariéru změnilo a jaký má na práci v Cleverlance pohled.<br></p><h4>Ahoj Petro, jak​​​​ se máš?​​​</h4><p>Mám se skvěle, děkuji. (smích)</p><h4>Jaká byla „tvoje cesta“ do Cle​ver​lance?</h4><p>Studovala jsem Softwarové inženýrství na ČVUT a už během studia jsem měla možnost vyzkoušet si různé projekty a role. Práce v IT se mi líbila už tenkrát, tak jsem po vysoké škole nastoupila do firmy, která vyvíjela software. Tam jsem byla asi tři roky, ale protože jsem se chtěla více rozvíjet v analýze, začala jsem se poohlížet po dalších možnostech. Ve finále jsem se rozhodovala mezi dvěma společnostmi, které o mě měly zájem. Obě firmy dělaly na podobných projektech, obě měly dobrou pověst, co se odbornosti týče, ale při návštěvě v Cleverlance mě více oslovilo její pracovní prostředí, a kultura, kterou jsem tam vnímala. A letos v květnu je to už 12 let.</p><h4>Takže jsi dala na svůj pocit?</h4><p>Ano, a nelituji toho. Cítila jsem, že v Cleverlance je komunita lidí se stejným cílem. Nejdříve jsem pracovala spíše na projektech u zákazníků a neměla tak možnost se s dalšími kolegy vidět každý den, naštěstí se ale v Cleverlance dělá maximum pro to, aby se měli šanci všichni potkávat. Organizují se různé akce, společné obědy, nebo snídaně s managementem, abychom věděli, co je nového. Já nejvíc oceňuji nabídku různých školení a dalších vzdělávacích „aktivit,“ na kterých mám možnost se potkat s ostatními.</p><h4>Na co ráda vzpomínáš?</h4><p>Zhruba po roce se situace výrazně změnila, kdy jsem z menších projektů u zákazníka, začala pracovat přímo v kancelářích firmy na vývoji softwaru pro nové pilíře penzijního pojištění. Projekt byl velmi náročný, protože musel být dokončen ještě před začátkem platnosti nové legislativy. Práce bylo sice hodně a někdy jsme pracovali i o víkendech, ale v týmu jsem poznala spoustu skvělých lidí, se kterými jsme měli společný cíl, na který jsme se soustředili. Nikdy například nezapomenu na tradici společných obědů, kterou jsme ještě ve starých kancelářích v pražských Holešovicích měli, a rituál vybírání, vyjednávání a smlouvání, na co a do které restaurace vyrazíme. To byl tenkrát asi nejvýraznější rys naší firemní kultury. (smích)</p><h4>Takže jsi tu našla, co jsi hledala?</h4><p>Ano a poznala jsem, že v Cleverlance jsou dva typy lidí: jedni, kteří přijdou s cílem pracovat na konkrétním projektu a po jeho dokončení pokračují dál, a druzí, kteří tu pracují dlouhodobě na různých projektech. Ta druhá skupina je daleko větší i díky tomu, že v Cleverlance je velké množství zajímavých projektů pro široké spektrum zákazníků v různých odvětvích a je tedy z čeho vybírat. S některými z nich pracuji na různých projektech stále, se spoustou dalších lidí se sice běžně nevídám, ale víme o sobě, a potkávám je třeba na školeních, na akcích nebo minimálně na vánočním večírku. A je to vždy velmi příjemné setkání. (smích) </p><p>Pokud se na to podívám z pohledu business analýzy, podařilo se nám společně po několika letech práce spoustu věcí nastavit – postupy, metodiky, standardy. Myslím, že nás hodně spojil i ten pocit spoluvytváření, společných inovací, nebo projekty, kde jeden navazuje na výstupy předchozího.</p><h4>A z odborného hlediska? Co si myslíš o možnostech profesního růstu v Cleverlance?</h4><p>Za prvé je to podle mě o zkušenostech. Děláme na zajímavých zakázkách pro velké zákazníky, takže tu o ně není nouze. Jako B​usiness analytik jsem si například musela zorganizovat spoustu workshopů se zákazníkem, s budoucími uživateli vyvíjeného softwaru. Mnohokrát se mi stalo, že přišla skupinka lidí, kteří mi dokázali úplně zničit agendu a vůbec jsme se nedostali k tomu, co bylo vlastně cílem setkání. To byl hlavně můj problém, nedokázala jsem to správně zkorigovat a zabývat se tématem toho konkrétního workshopu. To mě naučilo, jak důležité je si správně naplánovat agendu a jasně komunikovat cíl a proč jsme se vlastně sešli. Důsledně schůzku vést, držet se cíle a nedat prostor ničemu, co by mohlo workshop „rozbít.“</p><p>Za druhé Cleverlance nabízí spoustu skvělých interních školení, která jsou k dispozici pro každého a skvělé je, že si je vytváříme „sami pro sebe“. Osobně jsem těchto školení využila už jako student, později i jako lektor. V Cleverlance je samozřejmě i možnost absolvovat externích školení. Konkrétně v mém případě, kdy jsem se po několika letech jako Business analytik chtěla posunout do role Product ownera, tak mě Cleverlance v kariérním postupu podpořila a zaplatila mi externí školení i certifikaci.</p><h4>Vážně? A jak se tedy podle tebe změnila business analýza jako obor, za tu dobu, co jsi tady?</h4><p>Když jsem před lety nastoupila do Cleverlance, používala se při řízení projektů jen metodika waterfall, ale protože nastávaly komplikace s řízením projektů, přešli jsme postupně na agilní způsob práce a máme lepší výsledky. Pracovala jsem na mnoha projektech v bankách, které tímto způsobem změnily nejen vývoj IT systémů, ale celou svojí organizaci. Týmy mají v současné době k dispozici Product ownera, který definuje požadavky zákazníka. Tento trend již funguje nějakou dobu a podle mne konečně umožnil porozumění mezi zákazníkem a týmem, který software vyvíjí.</p><h4>Jaký je podle Tebe vlastně rozdíl mezi Business analytikem a Product ownerem?</h4><p>Business analytik se obvykle zaměřuje na analýzu a porozumění potřebám zákazníka. Na to, jak mohou být tyto potřeby naplněny v podobě vyvíjeného softwaru. Business analytik pracuje s vývojovým týmem, aby vypracoval specifikaci a po celou dobu projektu zajišťoval, že jsou naplněny potřeby zákazníka. </p><p>Product owner podle mne více řeší, proč software vlastně vzniká, k čemu bude sloužit. Vytváří „vizi“ výsledného softwarového produktu a snaží se ji předat celému týmu. Na denní bázi řeší priority jednotlivých požadavků, jak jsou důležité pro „business“, do kdy musí být hotové, a plánuje vydávání nových verzí.</p><p>To je důvod, proč je pro mne tahle role současným vyvrcholením mojí profesní cesty. Postupně jsem si vyzkoušela různé role v rámci IT a uvědomila si, že otázkám „co máme dělat“ a „jak to máme udělat“ musí předcházet otázky jako „proč to máme udělat,“ „proč je to důležité“ a „jak je to důležité…“. Myslím, že v Cleverlance si lidé velmi cení možnosti získávat zkušenosti při práci pro různé zákazníky, v různých oborech, na různých projektech. Neumím si představit, že bych strávila celých 12 let stejnou prací na jednom místě, pro jednoho zákazníka.</p><h4>Co tě teď v nejbližších měsíc​ích čeká?</h4><p>Hodně práce. (smích) Začala jsem participovat na novém projektu jako Product owner několika produktů. Zatím se rozkoukávám, sbírám informace a znalosti, rychle bych ale chtěla být pro zaběhnutý tým přínosem. A jelikož dovolenou pro své dobrodružnější cesty do Maroka a Uzbekistánu plánuji až po prázdninách, krásně to do sebe zapadá.</p><p>Tak ať se ti daří, příjemné léto.</p><p>Díky za rozhovor.</p><p> <em>Kateryna Sakovska​</em><br></p><p> <br> </p>​<br>odborné;#vzdělávání;#projekty;#
Barevné modely a jak je využívathttps://create-it.cz/Blog/Stranky/barevne-modely.aspxBarevné modely a jak je využívat<p>​​​​​​​Asi jste někdy zaznamenali zkratky jako CMYK, RGB nebo RAL ve spojitostí s barvou. Jedná se o rozdílné modely, které umožňují barvy míchat a popisovat. A každý systém má také odlišné použití. Ale hezky popořádku, než si popíšeme jednotlivé modely, uděláme si nejdříve pořádek v pojmech.<br></p><h2>Pojmy</h2><p>Průměrný člověk dokáže vidět okolo milionu barev. Nicméně, ne vždy dokáže barvy přesně odlišit. Dvě podobné barvy můžeme vnímat jako stejné. Nebo naopak vidíme rozdíly v barvě objektů stejné barvy, pokud jsou v jiném úhlu nebo různém osvětlení. </p><p>Aby výrobci a designéři mohli reprodukovat požadovanou barvu pokaždé přesně, potřebují způsob, jak kvantifikovat vlastnosti barvy a určit numerický rozdíl mezi nimi. A to je přesně důvod, proč vznikly barevné modely. Abychom mohli barvy definovat, popsat a katalogizovat. Díky barevným modelům máme jistotu, že pokud si koupíme modrou barvu s daným kódem, například na nátěr plotu, je to vždy ta samá modř. S barevnými modely pracují např. designeři, kteří musí přesně definovat barvy v návrhu a také tiskaři, kteří musí namíchat správné barvy k tisku. Bez barevného modelu bychom vlastně neměli ani barevné monitory nebo televizi.</p><p> <strong>Barevný model</strong> (nebo také systém) je tedy abstraktní matematický model popisující barvu viditelného spektra pomocí čísel. Barva v modelu se skládá obvykle ze 3 čísel, vzniká kombinací těchto 3 hodnot. Na obrázku níže je například konkrétní barva určena 3 hodnotami intenzity barev červené, zelené a modré.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely1.png" data-themekey="#" alt="" /><br></p><p> <strong>Barevný prostor</strong> je naproti tomu podmnožina dostupných barev, které daný barevný model nabízí. Stručně řečeno, barevný model říká, jakým způsobem barvy vznikají a barevný prostor pak definuje soubor barev, kterou je schopno určité zařízení nasnímat nebo zobrazit. Nejpoužívanější barevné prostory byly vyhlášeny jako celosvětové standardy a zařízení pracující s barvami (monitor, display, projektor, digitální fotoaparát, skener, tiskárna a další) podporují právě některý z těchto standardů. </p><p>Většina zařízení využívá pouze 1 barevný prostor. Ovšem existují například monitory pro profesionály, které mají k dispozici více barevných prostorů, mezi nimiž lze přepínat. Výrobce vždy uvádí, v jakém barevném prostoru zařízení pracuje a na kolik procent jej pokrývá. Pokud je uvedeno, že daný standard plní na 90 %, znamená to, že zařízení umí zobrazit pouze 90 % barev definovaných barevným prostorem. Rozsah barev u konkrétního zařízení se nazývá gamut. Barva, které je mimo rozsah gamutu, dané zařízení neumí zobrazit a vykresluje jí pak jako nejbližší možnou dostupnou barvu v gamutu.</p><p>Pro pochopení barevného prostoru a gamutu je důležité porozumět diagramu CIE. Je výsledkem rozsáhlého výzkumu lidského zraku. Je také známý jako "diagram podkovy". Horní křivka ohraničuje tvar podkovy a obsahuje jasné barvy, jak jdou za sebou ve spektru. Spodní hrana diagramu je přímka, která se nazývá "purpurová čára" a spojuje opačné barvy spektra, fialovou a červenou. Barvy na této přímce v duze nenajdeme. </p><p>Z obrázku níže je patrné, že reálně zobrazovaná množina barev zařízení je průnik množiny barev využívaného barevného prostoru (jeho standardu) a gamutu daného zařízení.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely2.png" data-themekey="#" alt="" /><br></p><p>Není to úplně jednoduché, že? A nyní se pojďme již podívat na základní barevné modely.</p><h2>Barevný model RGB</h2><p>RGB je neznámější barevný model. Je založen na vnímání barev lidským okem. V sítnici uvnitř oka jsou umístěny čípky, což jsou foto-receptorické světločivé buňky. V jednom oku je jich asi 7 milionů a rozlišují se na tři druhy: L, M a S čípky. Liší se barevnými pigmenty a citlivostí na vlnové délky, které odpovídají primárním barvám:</p><ul><li>červená (vlnová dálka 625 až 740 nm) – tu snímají L-čípky<br></li><li>zelená (520 až 565 nm) – tu snímají M-čípky<br></li><li>modrá (430 až 500 nm) – tu snímají S-čípky<br></li></ul><p>Tyto 3 typy receptorů vysílají do mozku signál, jaké intenzity je primární barevné světlo a mozek si namíchá výslednou barvu, kterou pak skutečně „vidíme“. Protože naše barevné vidění je realizováno třemi typy čípků, nazývá se <strong>trichromatické vidění.</strong></p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely3.png" data-themekey="#" alt="" /><br></p><p>Na tomto principu je založen <strong>RGB barevný model</strong>. Definuje, že každá barva vzniká mícháním tří primárních barev, červené (Red), zelené (Green) a modré (Blue). Tento model pracuje se zdrojem světla. Skládáním červeného, zeleného a modrého světla o různých intenzitách vznikají kombinace barev. Jednotlivé složky barev se sčítají a výsledek je světlo větší intenzity. Smícháme-li všechny 3 barevné složky v maximální intenzitě, vznikne bílá barva. Naopak pokud nepustíme do barevných složek žádné světlo, výsledkem bude tma, černá barva.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely4.png" data-themekey="#" alt="" /><br></p><p>Jak ale intenzitu primárních barev převést na čísla? Jednoduše. Intenzita se může pohybovat mezi minimem (nic nesvítí) a maximem (svítí naplno). Minimum je nula a maximum většinou číslo 255, což je největší číslo v počítači reprezentované 1 bajtem, tedy 8 bity. Mluvíme zde o <strong>bitové hloubce 8 bitů</strong>. Grafické SW počítačové jazyky většinou používají pro RGB model zápisy:</p><ul><li> <strong>RGB decimální</strong> – intenzita primární barvy je 0–255, pak např. žlutá vzniká plnou intenzitou červené a zelené a má RGB kód (255, 255, 0).<br></li><li> <strong>RGBA</strong> – stejné jako RGB, jen ke třem základním barvám přidáváme ještě Alfa kanál (hodnota 0–1), který definuje průhlednost barvy. 0 říká plně průhledné, 1 pak zcela nepropustné. Například žlutá napůl průhledná má RGBA kód (255, 255, 0, 0.5).<br></li><li> <strong>Hexadecimální</strong> (v šestnáctkové soustavě) – intenzita primární barvy je 0 – FF, pak žlutá má RGB HEX kód #FFFF00. Toto je nejčastější zápis barvy na webu.<br></li></ul><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely5.png" data-themekey="#" alt="" /><br></p><p>Barevný model RGB je <strong>aditivní barevný model</strong>, protože funguje na principu skládání barevného vyzařovaného světla. Tento model využívají všechny zařízení, které vyzařují obraz. Je tedy s výhodou používán pro televize, monitory, displeje nebo projektory. Je tak jedním z nejdůležitějších a nejznámějších systémů pro barvy v digitálních médiích.</p><h3>Barevný prostor sRGB</h3><p> <strong>sRGB</strong> je nejrozšířenější barevný prostor RGB modelu. Tento standard vznikl v roce 1995 ve spolupráci společností Hewlett Packard a Microsoft pro použití na monitorech, tiskárnách a internetu. Je podporován konsorciem <a href="https://www.w3.org/" target="_blank">W3C</a> pro vývoj na webu a významnými společnostmi jako je IBM, Intel, Adobe, Corel nebo <a href="https://www.pantone.com/" target="_blank">Pantone​</a>. Můžeme se s ním setkat u většiny grafického softwaru. Barevný prostor sRGB v současné době kraluje internetu, většina fotografií a ilustrací na webu byla vytvořena právě díky němu. Drtivá většina běžných současných monitorů podporuje právě tento standard.</p><h3>Barevný prostor Adobe RGB</h3><p>Prostor sRGB je sice široce používaný, ale je poněkud limitovaný. Nedokáže totiž zobrazit některé odstíny zelené a gradienty (přechody barev) působí tmavým dojmem. A tak přišla v roce 1998 společnost Adobe s vylepšeným barevným prostorem <strong>Adobe RGB</strong>. Využití má hlavně v digitální fotografii, kde fotky mají pak sytější a realističtější barvy. Ale abychom si je mohli správně vychutnat, musíme použít monitor, které tento barvený prostor podporuje. Jinak jsou barvy standardně přepočteny na sRGB.</p><h3>Barevný prostor ProPhoto RGB</h3><p>S rozvojem digitálních technologií se čím dál více používá barevný prostor ProPhoto ​​RGB, který vyvinula společnost Kodak pro své foťáky. Tento prostor nabízí speciálně široký rozsah barev, který by měl pokrýt všechny barvy povrchů reálného světa (<a href="https://tftcentral.co.uk/articles/pointers_gamut" target="_blank">Pointer’s gamut​</a>). Je proto ideální ve většině případů pro využití v digitálním světě. Pokud upravujeme obrázek v ProPhoto, minimalizujeme riziko zbytečného ořezávání barev. Ale pozor, exportovat nebo navěsit na web výslednou fotku bychom měli opět v sRGB, protože pokud si jí bude někdo prohlížet v softwaru, který neumožňuje přepočet barevných prostorů, barvy budou vypadat opravdu „divně“.<br></p><p> ​<img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely6.png" data-themekey="#" alt="" /><br></p><h2>Barevný model HSB</h2><p>Barevný <strong>model HSB</strong> byl vytvořen v roce 1978 jako jiná reprezentace aditivního RGB modelu. Umožňuje lepší a jednodušší míchání barev v digitálním světě, protože odpovídá lépe lidské představivosti a barevnému myšlení.</p><p>Představme si, že potřebujeme ladit sytost růžové barvy. Pomocí RGB modelu je to ale složité a neintuitivní. Nevíme, zda máme přidat více červené anebo jiné barvy pro výsledný efekt. Bylo by fajn ovládat přímo sytost barvy. A na tomto je HSB model založen. HSB model se skládá ze 3 složek:</p><ul><li>Odstín barvy (Hue) – hodnota 0–360 (°), odpovídá stupni na barevném kole, kde jsou za sebou uvedeny všechny základní barvy spektra. Popisuje zabarvení, barevný tón. <br></li><li>Sytost barvy (Saturation) – hodnota 0–100 (%) určuje čistotu barvy. 100 znamená plný sytý odstín barvy, naopak 0 představuje šedou. Někdy se tato vlastnost nazývá chroma, síla nebo bohatost barvy. Představuje množství šedi v poměru k odstínu, např. červená s 50 % sytostí je růžová.<br></li><li>Jas barvy (Brightnes) – hodnota 0–100 (%) řídí množství bílého světla. 0 udává vždy černou, 100 představuje jasný odstín. Pokud je jas 100 i sytost na 0, pak vidíme bílou a je jedno, jaký odstín byl zvolen. Tato veličina vyjadřuje, kolik světla barva odráží neboli poměr černé v základní barvě.<br></li></ul><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely7.png" data-themekey="#" alt="" /><br></p><h2>Barevný model HSV</h2><p> <strong>Model HSV</strong> je tentýž jako předchozí barevný model HSB. Pouze zde se složka pro jas nazývá hodnota (Value). Oba jsou to tzv. válcovité modely, kdy se namíchaná barva nachází jako bod uvnitř válce. Úhel kolem osy určuje odstín, vzdálenost od osy odpovídá sytosti a výška ve válci určuje jas nebo hodnotu. <br></p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely8.png" data-themekey="#" alt="" /> <br> </p><h2>Barevný model HSL</h2><p>Barevný <strong>model HSL</strong> je podobný modelu HSB, výsledná barva se také skládá ze tří složek. První dvě složky jsou naprosto stejné jako HSB, ale třetí se liší. Místo saturace se objevuje jako 3. složka světlost:</p><ul><li>Odstín barvy (Hue) – hodnota 0–360 (°).<br></li><li>Sytost barvy (Saturation) – hodnota 0–100 (%).<br></li><li>Světlost (Lightness) – hodnota 0–100 (%) určuje, jak moc bude barva světlá nebo tmavá. Světlostí nastavujeme podíl černé a bílé složky ve výsledné barvě. Nízká hodnota odpovídá tmavé barvě, 0 představuje černou. Naopak vysoká hodnota určuje světlé tóny, 100 odpovídá bílé.<br></li></ul><p>Jedná se také o cylindrický model, rozdíl v míchání je ale vidět na předchozím obrázku. Světlost odpovídá výšce ve válci. Je vidět, že plná světlost odpovídá bílé barvě na celém povrch válce. Je tedy jedno, jak jsou zbývající 2 složky nastaveny. To samé platí pro černou na spodu válce.</p><p>Výhody barevného modelu HSL spočívají v symetrii světlosti a tmy. To znamená, že sytost (saturace) jde vždy od plné syté barvy k ekvivalentu šedé. Ovšem podíváme-li se na válec HSB, tam sytost jde od syté barvy k bílé a mění se kontrast barvy. Takže pokud potřebujeme ladit pouze chromu barvy (míchat s šedou), aniž se mění výsledný kontrast, je výhodnější zvolit právě model HSL. </p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely9.png" data-themekey="#" alt="" /><br></p><p>Navíc světlost v tomto modelu má vždy od černé přes zvolený odstín až k bílé. Naopak v HSB, pokud budeme měnit jas, jdeme poloviční cestou, od černé k volenému odstínu. Je zřejmé, že HSL model má své výhody, kdy můžeme systematicky a velmi přesně míchat požadované barvy. Měnit jejich odstíny po velmi malých krocích a ladit přesně ten parametr barvy, který potřebujeme. Používáním HSB budeme při míchání barev efektivnější a rychlejší. </p><p>V grafickém softwaru je RGB model obvykle reprezentován uživateli ve formě lineárního nebo kruhového výběru odstínu a dvojrozměrné oblasti, kde si můžeme zvolit sytost a jas. Tedy pracuje defaultně s modelem HSB. A většina programů umí také přepnout do modelu HSL, což nám může ulehčit práci. Obrázek níže ukazuje různé modely mixu barev ve <a href="https://www.figma.com/" target="_blank">Figmě</a>, kdy poslední je model HSL. </p><p>  <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely10.png" data-themekey="#" alt="" /><br></p><h2>Barevný model HWB</h2><p>Další barevný <strong>model HWB</strong> opět reprezentuje RGB míchání barev a vznikl celkem nedávno, v roce 1996. Je možná ještě jednodušší na pochopení než vychvalovaný HSL model. Definuje, že barva se skládá ze 3 složek:</p><ul><li>Odstín barvy (Hue) – hodnota 0–360 (°), zde se nic nemění.<br></li><li>Bělost (Whiteness) – hodnota 0–100 (%) určuje stupeň přimíchání bílé barvy. 0 znamená, že zůstává základní odstín, 100 definuje čistě bílou.<br></li><li>Černota (Blackness) – hodnota 0–100 (%) řídí množství černé. 0 udává původní odstín, 100 100 zcela černou.<br></li></ul><p>Zní to jednoduše, že? Vyberu odstín barvy a doladíme bílou a černou. Tento model má ale zajímavou vlastnost, že pokud nastavíme bělost i černotu na plno, dostaneme poloviční šedou (#808080). Funguje to, jako bychom namíchali pouze černou a bílou. Aneb čím více zvyšujeme hodnotu bělosti i černoty, tím více přebíjí tyto barvy základní odstín a barva se mění v šedou. A to není úplně intuitivní. Možná právě proto se v grafických programech HWB model moc nepoužívá.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely11.png" data-themekey="#" alt="" /><br></p><h2>Barevný model CMYK</h2><p>Zcela odlišný od RGB je barevný <strong>model CMYK</strong>, který je velmi využívaný zejména v tisku. Je založen na CMY modelu, který míchá výslednou barvu jako poměr 3 primárních pigmentů:</p><ul><li>modrá azurová (Cyan) – hodnota 0–100 (%)<br></li><li>červeno-fialová (Magenta) – hodnota 0–100 (%)<br></li><li>žlutá (Yellow) – hodnota 0–100 (%)<br></li></ul><p>Na rozdíl od RGB se jedná <strong>subtraktivní barevný model</strong>. Je založen na principu mícháním pigmentů, které pohlcují barevné spektrum. Pokud bílé světlo dopadne na žlutý pigment, modré světlo se pohltí a zpět se odrazí pouze červené a zelené. A jak víme z RGB modelu, červená a zelená dává výslednou žlutou barvu. Nebo pokud smícháme žlutý a azurový pigment, dostaneme zelenou. Proč? Žlutý pigment pohlcuje modré světlo, azurový zase červenou. Výsledné odražené světlo je tedy zelené.</p><p>Překrýváním barevných pigmentů na bílém pozadí se výsledná barva ztmavuje. Pokud smícháme všechny primární pigmenty v plné dávce, dostaneme teoreticky černou. Je to dané tím, že výsledný pigment pohltí celé barevné spektrum, neodrazí žádné světlo a vznikne černá barva. Naopak pokud nenaneseme žádný pigment, podklad zůstává bílý.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely12.png" data-themekey="#" alt="" /> <br> </p><p>Barevný model CMYK přidává ještě jeden pigment:</p><ul><li>černá (Key nebo blacK) – hodnota 0–100 (%)<br></li></ul><p>Je to z důvodu, že v reálném světě pro vznik černo černé nestačí mix primárních pigmentů CMY. Zkoušeli jste někdy smíchat všechny temperové barvy dohromady? A vznikla černá? Vždy se nám podařilo namíchat takovou špinavou hnědo-šedou. Takže abychom uměli vykreslit čistou čerň, přidává se jako další barva do modelu.</p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely13.png" data-themekey="#" alt="" /><br></p><p>Jak bylo řečeno, tento model se používá s úspěchem v tisku. Např. inkoustové tiskárny mají vždy kromě primárních barev ještě zásobník s černou barvou. Je to také z ekonomických důvodů, protože většinou potřebujeme černo-bílé dokumenty, které tiskárna tiskne pomocí černého pigmentu a barevné tak šetří. Dalším důvodem je také to, že nános 3 plných pigmentů na jedno místo na papíru prosakuje a tisk déle schne.</p><p>Tiskárny dále používají tzv. <strong>rastrování</strong>. Pro nástřik barvy nižší sytosti se pigment rozpráší do malých teček, které jsou pod rozlišovací schopnosti lidského oka. Například z meganty tištěné s 20 % rastrem, vzniká růžová barva. Pigment se tak vlastně míchá s bílou barvou podkladu a výsledkem jsou světlejší barvy.</p><h3>Barevný prostor CMYK</h3><p>Barevný prostor CMYK využívají výhradně tiskárny a slouží také pro popis samotného tiskového procesu. Tento prostor je vždy závislý na daném zařízení a používaném pigmentu. Má menší rozsah barev než sRGB a při tisku tak musí dojít k přepočtu barev. Ty barvy, které prostor CMYK neobsahuje, jsou nahrazeny dostupnými. </p><p> <img src="/Blog/PublishingImages/Stranky/Barevne_modely/barevne_modely14.png" data-themekey="#" alt="" /><br></p><p>Existují 3 tipy přepočtu na CMYK:</p><ul><li>Perceptuální – používá se pro fotografie, kdy se plynule modifikuje gamut tak, aby byly barvy co nejvěrnější.<br></li><li>Kolorimetrický – převádí se pouze barvy, které jsou mimo rozsah cílového gamutu tak, že nahradí nebližší barvou z gamutu. Není tak vhodný pro fotografie, protože slívá různé barvy do stejné.<br></li><li>Saturation (sytost) - snaží se vytvořit živé barvy na úkor přesnosti barev. Hodí se pro obchodní grafiku a marketing, kde přesné vztahy mezi barvami nejsou tak důležité, jako dosažení jasných, sytých barev. Pro fotografie je tato metoda opět nevhodná.<br></li></ul><p>Z technologie míchání barev pomocí subtraktivního modelu CMYK, kdy výchozím stavem je bílý papír, vyplývá, že tisk nikdy nezobrazí dostatečně syté a zářivé barvy. Má problém se ztvárněním zejména ostré fialové a zelené. Naše fotografie, vytištěné na domácí inkoustové tiskárně za pomocí CMYK prostoru, tedy nebudou nikdy tak krásně barevné a jasné jako na LCD display. Naštěstí existují profesionální tiskárny a fotolaby, které pracují s jinými barevnými prostory a větší množinou barev.​<br></p><h2>Pokračování</h2><p>Článek bude pokračovat, v dalším díle se podíváme na princip oponentních procesů a barevné modely z něj vycházející. Dále se seznámíme s nejpoužívanějšími barevnými systémy, jako je RAL nebo Pantone. <br></p><p> <em>Jan Čermák</em><br></p>​<br>odborné;#vzdělávání;#
Když se řekne analytik, znamená to, že…https://create-it.cz/Blog/Stranky/analytici.aspxKdyž se řekne analytik, znamená to, že…<p>​​Z pohledu IT být analytikem znamená několik různých pracovních pozic s různou náplní práce. Patří sem role IT analytik, který bývá také označován jako systémový analytik, nebo business analytik, datový analytik či test analytik. Co ale vlastně člověk v té které pracovní pozici dělá a za co zodpovídá? Podívejme se na jednotlivé role chronologicky, tak jak vstupují do průběhu IT projektu.<br></p><h2>Business analytik​​<br></h2><p>První analytickou pozicí, která se zapojuje do projektu, je <strong>business analytik</strong>. Jeho zodpovědností, velice zjednodušeně řečeno, je komunikace s klientem, se zástupci businessu u zákazníka​. Cílem jeho práce je sběr potřeb klienta, jejich transformace do požadavků a seřazení dle důležitosti. Následně analytik vypracovává návrh řešení, tj. de facto staví software z pohledu uživatele. Svůj návrh zaznamenává do business analýzy, což znamená tvorbu procesních diagramů, Use Case modelů nebo User Stories, aktivity diagramů, popsání uživatelských rolí, nakreslení drátěných modelů obrazovek atd., tedy všeho, z čeho bude možné vyčíst, jak má systém fungovat z pohledu uživatele. Co všechno musí znát dobrý business analytik se můžete dočíst <a href="/Blog/Stranky/analyza.aspx">zde</a>.<br></p><h2>IT analytik​​<br></h2><p><strong>IT analytik</strong> neboli také systémový analytik, vstupuje do procesu projektu záhy nebo společně s business analytikem. Jeho zodpovědností je návrh technického řešení systému. Při své práci intenzivně komunikuje jak s IT architektem, který má na starosti návrh konceptu vývoje aplikace, tak s business analytikem, který mu předkládá funkční požadavky a popis řešení z pohledu businessu. IT analytik pak navrhuje a popisuje detaily technického řešení, jednotlivých modulů systému, datových a objektových struktur včetně jejich vazeb, definuje rozhraní, modeluje sekvenční diagramy atd. Výstupy IT analytika jsou společně s výstupy business analytika zadáním, dle kterého vývojáři programují požadovaný systém. I proto je u IT analytika standardním požadavkem znalost programovacích jazyků jako např. Java, .NET, SQL nebo XML. Oč​​​ekávaná je také znalost metodik jako RUP a ITIL nebo v poslední době rozšířeného <a href="/Blog/Stranky/DevOps.aspx" target="_blank">DevOps</a> přístupu k vývoji software.<br></p><h2>Test analytik​​<br></h2><p><strong>Test analytik</strong> zpracovává test analýzu. Nastuduje si vstupy business a IT analytika, projde s nimi procesy a logiku celého očekávaného řešení tak, aby pochopil, jak má ve výsledku systém fungovat. Z toho vyplývá, že do projektu vstupuje buď až po zpracování business a IT analýzy, nebo před jejím ukončením. Po seznámení se s analytickými dokumenty vypracovává testovací scénáře (Test Case), test suits (logické seskupení testů, které spolu souvisí) a testovací skripty. Může se také stát, že při tvorbě testovacích scénářů narazí na nějaký nedostatek v business či IT analýze. V daném případě na tuto skutečnost upozorní, aby mohl business nebo IT analytik zjištěný nedostatek do analýzy dopracovat. Test analytik také v průběhu tvorby testovacích scénářů definuje potřebná testovací data pro otestování software. Ve finále je schopen navrhnout plán testování, tj. pořadí testování jednotlivých testovacích scénářů. Někdy také bývá tím, kdo testovací data připravuje, případně se účastní samotného testování software.<br></p><h2>Datový analytik​​<br></h2><p><strong>Datový analytik</strong>, jak již vyplývá z názvu, pracuje s daty. V každém systému jsou tisíce, někdy i miliony datových záznamů, ze kterých lze pro potřeby businessu vytěžit množství zajímavých informací. Jedná se o číselné hodnoty, ale také data textového charakteru. Datový analytik pracuje jak s primárními zdroji dat, tj. daty z hlavního systému, tak sekundárními, například s daty ze systémů, které řeší méně důležité, tedy podpůrné procesy. Analytik data třídí, čistí a analyzuje prostřednictvím standardních statistických nástrojů. Vytváří různé typy reportů a vizualizace pro business nebo management. Navrhuje a tvoří relační databáze, definuje korelace a vzorce v komplikovaných datových setech. Mezi primární znalosti datového analytika patří navrhování databází, orientace v datových skladech a BI platformách, SQL, data mining, schopnost vizualizovat výsledná data a prezentovat zjištěné výsledky. Ale také znalost statistických technik, matematické vědomosti a orientace ve finančnictví. Datový analytik se může do projektu zapojit vlastně kdykoliv. Může být součástí týmu téměř od začátku, pokud se například jedná o projekt, kterého součástí je migrace dat z původního systému do nového. Nebo se může zapojit do projektu po nasazení systému do produkce, aby vydoloval a zpracoval první výstupy pro business či management klienta, přičemž v této práci může pokračovat a průběžně připravovat různé reporty a vizualizace.</p><p>Jak je z popisu výše vidět, do vytvoření návrhu systému vstupuje hned několik analytiků, přičemž jejich práce na sebe navazuje. I proto je pro všechny důležitá průběžná více či méně intenzivní komunikace. Vlastně by se dal návrh nového software popsat jako hra symfonického orchestru, kdy housle doplní flétna či hoboj, sem tam do toho zazní lesní rohy nebo bouchne tympán. Pokud jsou všichni sladěni, zní nádherná melodie, no a pokud ne, pak si všichni kolem zakrývají uši. V případě software by se „falešná hra“ projevila nefunkčním řešením, které by nesplňovalo potřeby klienta a navíc nejspíš nebylo použitelné.​<br></p><p><i>Zuzana Drotárová​</i></p><p><br></p>odborné;#vzdělávání;#
Květen ve jménu designuhttps://create-it.cz/Blog/Stranky/grafika-pro-deti-II.aspxKvěten ve jménu designu<p>​​Všechny květnové středy a první červnovou jsme zasvětili grafice a designu. Kreativní oddělení QUB si připravilo pětidílný kurz grafiky pro děti. Lekce jsme nachystali jako pět hodinových online setkání a byli jsme nadšení, co všechno 11 malých designerů ve věku 7–12 let během kurzu zvládlo. Ostatně možná jste četli <a href="/Blog/Stranky/grafika-pro-deti.aspx">článek od dvanáctileté Viky</a>.<br></p><p> Postupovali jsme od základů – vysvětlili jsme si základy barevné teori​e, prošli jsme zajímavosti z tvorby pigmentů a první hodinu zakončili tvorbou barevné palety, bez které se začátek žádného designového projektu neobejde. </p><p> Při druhém setkání jsme se lehce dotkli historie. Od piktogramů, hieroglyfů a jeskynních maleb jsme se dostali až k rozdělení typografie na expresivní a funkční a děti se naučily mimo jiné rozlišit mezi patkovým a bezpatkovým písmem. Buďte připraveni, až vás malí designeři doma ohromí zajímavými fakty o stavbě písma a budou správně tvrdit, že některé znaky mají bříška, chvosty a oka a že kuželka nemusí být jen ta na bowlingu! Lekci jsme zakončili tréninkem správného prostrkání písma. </p><p> Na třetím setkání jsme společně vypátrali, že styl komixových hrdinů s černou obrysovou linkou má původ v japonském tradičním dřevořezu a secesních plakátech. Nasdíleli jsme si pár tipů na přidání dynamiky do příběhu, práci s bublinami a ujasnili si, že komix by měl mít hrdinu, zápletku, prostředí a vybraný jednotný grafický styl. Společně jsme tvořili krátký strip na téma Překvapení. </p><p> Ve čtvrté lekci jsme zabrousili do obalového designu, procvičili jsme si nabyté dovednosti o barvách a typografii a postavili jsme malé designery před nelehký úkol ­– design obalu sáčku na bonbony. Opět jsme postupovali stejně jako v běžné praxi, začali jsme rešerší a všímali si detailů a rozdílů například mezi designy ovocných a čokoládových bonbonů. Děti ukázaly ohromnou míru kreativity a kromě designu obalu přišly i s nápady na názvy nových bonbonů – zaujaly by vás v obchodě třeba Slepičí zobáky?<br></p><p> V prvních čtyřech lekcích jsme se záměrně vyhýbali počítači a pracovali s návrhy na papír (o​pět stejně jako v designové praxi). V páté poslední lekci jsme zkusili zabrousit do grafického editoru a představili jsme dětem <a href="https://www.figma.com/">Figmu</a>. Vyzkoušeli jsme si převést svůj návrh bonbónového sáčku do počítače. I touhle poslední zkouškou ​téměř ohněm děti prošly a my v současné sobě sbíráme všechny jejich výtvory. </p><p><i>​​ Za <a href="https://qub.digital/en/index/">QUB Digital</a> Ivana Stránská, Michal Hořava a Jan Čermák<br></i><br></p>odborné;#vzdělávání;#
Grafika pro děti očima Vikyhttps://create-it.cz/Blog/Stranky/grafika-pro-deti.aspxGrafika pro děti očima Viky<p>​Dvanáctiletá Viky napsala skvělou autentickou reportáž z kurzu grafiky pro dě​​ti pořádaného Cleverlance.​ Publikováno bez úprav.​​​<br></p><h2>1. lekce​<br></h2><p>Úplně na začátku 1. lekce jsme se představili ostatním jako na jiných kurzech, ale k tomu jsme ještě řekli co bychom se chtěli naučit. Jakmile jsme se představili lekce mohla začít. Nejdřív nám řekli barvu roku (která se jmenuje Very Peri) a jak je pro designéra důležitá. Vlastně designér používá barvu roku skoro všude. Taky jsme se bavili o kole barev, kde je krásně vidět kontrast barev. Potom jsme měli historii barev. Je hodně zajímavé že už v pravěku používali bílou barvu, protože bílá se získává blbě a ještě pomocí nějakých chemických látek. A třeba Římané měli rádi různé odstíny hnědé takže takový romantický styl. Další téma byl pigment. Podle toho jaké dáme pojidlo do pigmentu vzniknou různé barvy. Dřív se jako pojidlo používal med, olej nebo vajíčko. Třeba když se dá do pigmentu jako pojidlo med tak vzniknou akvarelové barvy nebo taky to stejné akorát s vajíčkem tak vzniknou tempery. Poslední téma bylo z jakých různých kamenů se dělají různé barvy. Třeba žlutá se dělá ze sopečného kamene nebo je zajímavé že bílá se dělá z černého kamene sice je tam nějaká chemická úprava, ale to je věc vedlejší. Na konci hodiny jsme dostali “domácí úkol" vymyslet vlastní barevnou paletu do příštího týdne. Mě to hrozně moc bavilo a těším se na další lekce grafiky.</p><p> <img src="/Blog/PublishingImages/Stranky/grafika-pro-deti/obrazek-1.jpg" alt="paleta" data-themekey="#" style="max-width:690px;" /><br><br></p><h2>2. lekce​<br></h2><p>V 2. lekci jsme se bavili o typografii. Nejdřív jsme probírali historii psaní. Úplně první písmo byly hieroglyfy, které vymysleli v Egyptě.Tenhle druh písma byl časově náročný. Si představte kdybyste museli kreslit třeba kachnu kvůli jednomu slovu. Další písmo vymysleli Féničané a bylo to první hláskové písmo a z něho potom vznikla Latinka, kterou píšeme i v dnešní době. Jedno z předposledních témat bylo to že jsme si vysvětlovali co je patkové a nepatkové písmo momentálně píšu nepatkovým. Dále co jsou versálky a mínusky. A předposlední co jsme dělali bylo že nám vysvětlovali plakátové a takové to které se dává do novin a tak dále. Plakátové má zaujmout a udělat dojem, ale někdy je skoro nečitelné. Zase naopak to novinářské se musí dobře číst. Poslední co jsme dělali bylo to že nám poslali odkaz na webovou stránku do chatu. Tam jsme si mohli cvičit rozmístění písmen v nadpisech a tak dále. Jako minule nám dali “domácí úkol" ale tentokrát jsme měli nakreslit nebo namalovat svoje jméno (viz obrázek v záhlaví článku). Zase jako minule mě to fakt hodně bavilo a těším se na příště.</p><h2>3. lekce<br></h2><p>Ve 3. lekci jsme se zajímali o komiksech. Úplně první téma co jsme probírali byly takové ty okénka a říkali jsme si že ty okénka můžou být různě uspořádané tak aby čtenáře zaujali. Potom takové stínování v černobílém komiksu, že třeba 1. okénko je do šeda, 2. a 3. okénko je do bíla a tak dále. Nějak uprostřed hodiny jsme si zkoušeli si namalovat svůj komiks, ale jenom strip. To je komiks s dvěma nebo třemi okénky. Jakmile jsme dodělali svůj “komiks" tak hodina skončila. I teďka mě to moc bavilo a těším se na příště.</p><p>​<br><img src="/Blog/PublishingImages/Stranky/grafika-pro-deti/komix.jpg" alt="komix" data-themekey="#" style="max-width:690px;" /><br><br></p><h2>4. lekce<br><br></h2><p>Na 4. lekci jsme malovali a vymýšleli svůj pytlík bonbónů. Nejdřív jsme museli vymyslet název, já jsem vymyslela Japonky. Potom styl písma a když jsme měli hotový náčrt tužkou tak jsme si vymysleli paletu barev. Jakmile jsme vybarvili název, tak jsme udělali design jako třeba obrázek příchuti: meloun, marshmelouny atd. Kolem toho lístky nebo něco jiného. Taky jsme tam museli napsat kolik to váží jaká je to příchuť (pro jistotu). Během toho nám říkali Michal s Ivanou o kontrastu a zlatém řezu. Naše pytlíky bonbónů jsme jim na konci hodiny ukázali. Pochválili nás a řekli ať tomu doděláme nějaké zajímavé pozadí a vyfotíme jim to. Jako každá lekce grafiky mě bavila a navíc na tomhle jsme si procvičili typografii a výběr barev, které se k sobě hodí.<br><br></p><h2>5. lekce​ <br></h2><p>Na 5. lekci jsme pracovali s Figmou. Předělávali jsme pytlík bonbónů do počítače, který jsme dělali minule. Nejdřív jsme si nastavili formát papíru a nastavili mu barvu. Potom jsme udělali nadpis a upravili ho. Taky jsme tam dali různé tvary a na jedné webové stránce jsme našli různé vektorové obrázky. Do dalšího týdne jsme to měli dodělat a poslat. K tomu ten co to měl nejhezčí tak dostane pytlík bonbónů. Všechny lekce grafiky byly super a asi nejvíc mě bavila 3. lekce. Pokud by byly další tak bych se určitě zapojila.<br><br></p><p> <i>Viky</i><br></p><p><br>Sledujte nás a v brzké době vám přineseme výtvory i ostatních účastníků kurzu - protože kdo by nechtěl vidět nejhezčí pytlík bonbónů!​<i></i></p><p><i><br></i></p><p> <br> </p>hobby;#vzdělávání;#
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í;#
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í;#
​​Ukraine Testing Academyhttps://create-it.cz/Blog/Stranky/TCA_UA.aspx​​Ukraine Testing Academy<p>​​​​​​​Text v češtině pro vaši informaci naleznete ​​ <a href="#cesky">ZDE​</a>. <br></p><h1 class="lang-UA">Увійдіть у світ ІТ ра​​​зом з нами навчившись тестувати програм​не за​безпечення​​!​<br></h1> ​ <p>Хвиля співчуття та благодійності щодо ситуації на Україні прокотилася усім суспільством Чехії.​ Разом з Cleverlance ми думали, як з нашого боку допомогти Українцям, крім грошей. Ми вирішили полегшити людям, які приїжджають із зони бойових дій, знайти шлях до нового майбутнього. Шлях до праці, яка принесе їм гідну професійну кар’єру в Чеській Республіці і яку вони також зможуть продовжити у рідній країні після повернення.</p><p>Протягом багатьох років Cleverlance допомагає людям Чеської Республіки увійти у світ ІТ, навіть, якщо до цього вони працювали в іншій сфері. Ми попросили наших колег з тестингу, які вільно володіють українською та російською мовами, дати своїм співвітчизникам базу у цій галузі. Тому спільно з ними ми організуємо Ukraine Testing Academy.</p><p>Ця навчальна програма триватиме 3 дні і є для учасників академії безкоштовною. Вона відбудеться з понеділка 2.5. до середи 4.5.2022 онлайн, завжди з 16:00 до 18:00. Завдяки цьому фактору ви легко поєднаєте навчання з доглядом за дітьми або поточною роботою. Ми не можемо обіцяти вам роботу над нашими проектами, але порадимо, як її знайти на чеському ринку праці.</p><p>Тож, як можна взяти участь у цьому заході?</p><p>Спочатку з’ясуйте, чи є у вас задатки тестера. Скільки помилок ви знайшли на цих квитках? </p><p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Shrnutí.svg" alt="Shrnutí.svg" data-themekey="#" /> <br> </p><p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Letenka%201.svg" alt="Letenka 1.svg" data-themekey="#" /> <br> </p><p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Letenka%202.svg" alt="Letenka 2.svg" data-themekey="#" /> <br> </p><p>​Надішліть своє рішення разом із резю​​ме Марії Павловій через <a href="https://www.cleverlance.com/cz/kariera/Stranky/Skoleni/ukraine-testing-academy.aspx" target="_blank">форму заявки на вебсайті Cleverlance</a>.<br></p><p>Марія зв’яжеться з вами, та інформує, чи прийняті ви до подальшої співбесіди, – і якщо так, то вас чекатиме спільна ро​​змова близько 30 хвилин. </p><p>Після виборчого процесу ви от​римаєте письмове запрошення на подію. Перед самим курсом ви та інші учасники, зустрінетесь на так званому семінарі, щоб перевірити якість вашого інтернет-з’єднання.</p>Навчання проходитиме онлайн, але ми всі обов’язково побачимось через камери.<br> <p>Ми познайомимо вас з основами тестингу програмного забезпечення, а також інструментами та технологіями, які використовуються при тестуванні. Ви дізнаєтеся, що таке тестовий анал​із і як підготувати тестовий сценарій. Це і є усе те, що повинен вміти кожен зацікавлений у вакансіях Junior Tester.</p> <br>Ми з нетерпінням чекаємо на вас у Cleverlance.​ <p id="cesky"></p> <br>​<br> <h1>Vstup s námi ​do světa IT a pojď se naučit testovat software!</h1>  <p></p><p> Napříč celým Českem se v důsledku války na Ukrajině vzedmula vlna charity. V Cleverlance jsme se zamysleli, jak můžeme pomoci i jinak než penězi. Rozhodli​​ jsme se lidem přicházejícím z válečné zóny na Ukrajině usnadnit cestu k nové budoucnosti. K práci, která jim přinese důstojné profesní uplatnění v České republice a kterou budou po návratu moci vykonávat také ve své rodné zemi.</p><p>Už řadu let v Cleverlance pomáháme v ČR zájemcům z jiných oborů vstoupit do světa IT. Požádali jsme své kolegy v testingu, kteří ovládají ukrajinštinu a ruštinu, aby umožnili svým krajanům získat vhled do tohoto oboru, a tak spo​​lečně organizujeme Ukraiina Testing Academy.</p><p>Tento vzdělávací program zabere 3 odpoledne a je pro účastníky akademie zdarma. Bude se konat od pondělí 2.5. do středy 4.5.2022 online vždy v čase ​​od 16:00 do 18:00 hod. Díky tomu se dá skloubit s péčí o děti nebo současným zaměstnáním.</p>Nedokážeme vám přislíbit práci na našich projektech, ale poradíme vám, jak najít uplatnění na českém pracovním trhu.<br> <br>A jak je možné se této akce zúčastnit?<p>Nejdříve zjistěte, zda máte p​​ředpoklady hledat chyby v aplikacích. Kolik chyb najdete na těchto letenkách?</p>  <p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Shrnutí.svg" alt="Shrnutí.svg" data-themekey="#" style="max-width:690px;" /> <br> </p><p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Letenka%201.svg" alt="Letenka 1.svg" data-themekey="#" style="max-width:690px;" /> <br> </p><p> <img src="/Blog/PublishingImages/Stranky/TCA_UA/Letenka%202.svg" alt="Letenka 2.svg" data-themekey="#" style="max-width:690px;" /> <br> </p><p>Své řešení se pošlete spolu se svým životopisem Marii Pavlove přes přihlašovací <a href="https://www.cleverlance.com/cz/kariera/Stranky/Skoleni/ukraine-testing-academy.aspx" target="_blank">formulář na webu Cleverlance​</a>.<br></p><p>Mariia vás bude kontaktovat s informací, zda postupujete do výběrového řízení - a pokud ano, zavolá vám a čeká vás společný asi 30 minutový​​ pohovor.</p><p>Když budete vybrán/a, dostanete písemnou pozvánku na akci. Před samotným kurzem se ještě s ostatními účastníky sejdete na tzv. secvič​​né, abychom si vzájemně ověřili kvalitu připojení na internet.</p>Výuka bude probíhat on-line, všichni se uvidíme na kameře.<br> <p>Seznámíme vás se zákl​​ady testování softwaru a v testingu používanými nástroji a technologiemi. Zjistíte, co je test analýza a naučíte se připravovat test scénáře. Tedy vše, co by zájemce o pracovní pozici Junior Tester měl umět.</p> <br>Těšíme se na vás v Cleverlance.<br> <p></p>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í;#

​