{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Unit-testy v DB \u2014 ako to rob\u00edme v \u0160portmastere, druh\u00e1 \u010das\u0165","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prv\u00e1 \u010das\u0165 \u2014 tu<\/a><\/noindex>.<\/i><\/p>\n

\"Unit-testy<\/a><\/noindex><\/p>\n

Predstavte si situ\u00e1ciu. Pred vami je \u00faloha vyvin\u00fa\u0165 nov\u00fa funkciu. M\u00e1te podklady od svojich predchodcov. Ak predpoklad\u00e1te, \u017ee nem\u00e1te \u017eiadne mor\u00e1lne z\u00e1v\u00e4zky, ako by ste sa zachovali?<\/p>\n

Naj\u010dastej\u0161ie sa v\u0161etky star\u00e9 podklady zab\u00fadaj\u00fa a v\u0161etko za\u010d\u00edna odznova. Nikto nem\u00e1 r\u00e1d hrabanie sa v cudzom k\u00f3de, a ak je \u010das, pre\u010do sa nevenova\u0165 vytvoreniu vlastn\u00e9ho syst\u00e9mu? To je typick\u00fd pr\u00edstup a v mnoh\u00fdch oh\u013eadoch spr\u00e1vny. Ale v na\u0161om projekte sme sa rozhodli inak. Z\u00e1kladom bud\u00faceho syst\u00e9mu automatick\u00e9ho testovania sme postavili na podkladoch testov unit-testov na utPLSQL od predchodcov a potom sme i\u0161li pracova\u0165 v nieko\u013ek\u00fdch paraleln\u00fdch smeroch.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Obnova star\u00fdch unit-testov.<\/b> Pod obnovou rozumieme prisp\u00f4sobenie testov s\u00fa\u010dasn\u00e9mu stavu syst\u00e9mu lojality a prisp\u00f4sobenie testov \u0161tandardom utPLSQL. <\/li>\n
  2. Rie\u0161enie probl\u00e9mu porozumenia, ak\u00e9 konkr\u00e9tne met\u00f3dy a procesy m\u00e1me pokryt\u00e9 automatick\u00fdmi testami. <\/b>Mus\u00edme si bu\u010f t\u00fato inform\u00e1ciu uchov\u00e1va\u0165 v hlave, alebo robi\u0165 z\u00e1very na z\u00e1klade samotn\u00e9ho k\u00f3du automatick\u00fdch testov. Preto sme sa rozhodli vytvori\u0165 katal\u00f3g. Ka\u017ed\u00e9mu automatick\u00e9mu testu sme priradili jedine\u010dn\u00fd mnemonick\u00fd k\u00f3d, vytvorili popis a zaznamenali nastavenia (napr\u00edklad, v ak\u00fdch podmienkach by sa mal spusti\u0165, alebo \u010do by sa malo sta\u0165, ak spustenie testu zlyh\u00e1). V podstate sme vyplnili metadata o automatick\u00fdch testoch a umiestnili sme ich do \u0161tandardn\u00fdch tabuliek sch\u00e9my utPLSQL.<\/li>\n
  3. Defin\u00edcia strat\u00e9gie roz\u0161\u00edrenia, t.j. v\u00fdber funkci\u00ed, ktor\u00e9 maj\u00fa by\u0165 overen\u00e9 automatick\u00fdmi testami.<\/b> Rozhodli sme sa zamera\u0165 na tri veci: nov\u00e9 vylep\u0161enia syst\u00e9mu, incidenty z produkcie a k\u013e\u00fa\u010dov\u00e9 procesy syst\u00e9mu. T\u00fdmto sp\u00f4sobom sa vyv\u00edjame paralelne s vydan\u00edm, zabezpe\u010dujeme vy\u0161\u0161iu jeho kvalitu, roz\u0161irujeme objem regresie a zabezpe\u010dujeme spo\u013eahlivos\u0165 syst\u00e9mu na kritick\u00fdch miestach. Prv\u00fdm tak\u00fdmto \u00fazkym miestom sa stal proces rozde\u013eovania zliav a bonusov na \u00fa\u010dtenkach.<\/li>\n
  4. Samozrejme, zaoberali sme sa v\u00fdvojom nov\u00fdch automatick\u00fdch testov. <\/b>Jednou z prv\u00fdch \u00faloh po vydan\u00ed bolo vyhodnotenie v\u00fdkonnosti preddefinovan\u00fdch v\u00fdberov syst\u00e9mu vernostn\u00fdch programov. V na\u0161om projekte je blok pevne stanoven\u00fdch sql dotazov, ktor\u00e9 vyberaj\u00fa z\u00e1kazn\u00edkov pod\u013ea podmienok. Napr\u00edklad z\u00edska\u0165 zoznam v\u0161etk\u00fdch z\u00e1kazn\u00edkov, ktor\u00fdch posledn\u00fd n\u00e1kup bol v konkr\u00e9tnom meste, alebo zoznam z\u00e1kazn\u00edkov, ktor\u00fdch priemern\u00e1 suma n\u00e1kupu je vy\u0161\u0161ia ako stanoven\u00e1 hodnota. Nap\u00edsan\u00edm automatick\u00fdch testov sme overili preddefinovan\u00e9 v\u00fdbery, zaznamenali referen\u010dn\u00e9 parametre v\u00fdkonnosti, a navy\u0161e sme vykonali aj z\u00e1\u0165a\u017eov\u00e9 testovanie.<\/li>\n
  5. Pr\u00e1ca s automatick\u00fdmi testami by mala by\u0165 pohodln\u00e1<\/b>. Naj\u010dastej\u0161ie sa vykon\u00e1vaj\u00fa dve akcie: spustenie automatick\u00fdch testov a vytvorenie testovac\u00edch d\u00e1t. Tak sa v na\u0161om syst\u00e9me objavili dva pomocn\u00e9 moduly: modul spustenia a modul generovania d\u00e1t.\n

    Modul spustenia je predstaven\u00fd ako jedna univerz\u00e1lna proced\u00fara s jedn\u00fdm vstupn\u00fdm textov\u00fdm parametrom. Ako parameter je mo\u017en\u00e9 odovzda\u0165 mnemo k\u00f3d automatick\u00e9ho testu, n\u00e1zov bal\u00edka, n\u00e1zov testu, nastavenie automatick\u00e9ho testu alebo rezervovan\u00e9 k\u013e\u00fa\u010dov\u00e9 slovo. Proced\u00fara vyber\u00e1 a sp\u00fa\u0161\u0165a v\u0161etky automatick\u00e9 testy, ktor\u00e9 spl\u0148uj\u00fa podmienky.<\/p>\n

    Modul generovania d\u00e1t je predstaven\u00fd vo forme bal\u00edka, v ktorom pre ka\u017ed\u00fd objekt testovan\u00e9ho syst\u00e9mu (tabu\u013eka v datab\u00e1ze) bola vytvoren\u00e1 \u0161peci\u00e1lna proced\u00fara, ktor\u00e1 vklad\u00e1 \u00fadaje. V tejto proced\u00fare s\u00fa maxim\u00e1lne vyplnen\u00e9 prednastaven\u00e9 hodnoty, \u010do zabezpe\u010duje vytvorenie objektov doslova jedn\u00fdm kliknut\u00edm. A pre pohodln\u00e9 pou\u017e\u00edvanie boli vytvoren\u00e9 \u0161abl\u00f3ny vytv\u00e1ran\u00fdch d\u00e1t. Napr\u00edklad, vytvori\u0165 z\u00e1kazn\u00edka ur\u010dit\u00e9ho veku s testovac\u00edm telef\u00f3nom a uskuto\u010dnen\u00fdm n\u00e1kupom.<\/li>\n

  6. Automatick\u00e9 testy by sa mali sp\u00fa\u0161\u0165a\u0165 a pracova\u0165 v prijate\u013enom \u010dase pre v\u00e1\u0161 syst\u00e9m. <\/b>Preto bol organizovan\u00fd ka\u017edodenn\u00fd no\u010dn\u00fd sp\u00fa\u0161\u0165, po ktorom sa vytv\u00e1ra spr\u00e1va o v\u00fdsledkoch a rozosiela sa cel\u00e9mu v\u00fdvojov\u00e9mu t\u00edmu prostredn\u00edctvom firemnej po\u0161ty. Po obnoven\u00ed star\u00fdch automatick\u00fdch testov a vytvoren\u00ed nov\u00fdch celkov\u00fd \u010das prev\u00e1dzky predstavoval 30 min\u00fat. Tak\u00e1to v\u00fdkonnos\u0165 v\u0161etk\u00fdch uspokojila, preto\u017ee sp\u00fa\u0161\u0165anie prebiehalo mimo pracovn\u00e9ho \u010dasu.\n

    Av\u0161ak optimaliz\u00e1cia r\u00fdchlosti pr\u00e1ce si vy\u017eiadala \u010dasto extra \u00fasilie. Aktualiz\u00e1cia vernostn\u00e9ho syst\u00e9mu sa uskuto\u010d\u0148uje cez noc. V r\u00e1mci jednej z verzi\u00ed bolo potrebn\u00e9 vykona\u0165 naliehav\u00e9 zmeny po\u010das noci. Polhodinov\u00e9 \u010dakanie na v\u00fdsledky automatizovan\u00fdch testov o tretej r\u00e1no neprinieslo \u0161\u0165astie zodpovedn\u00e9mu za verziu (ve\u013ek\u00fd pozdrav Alexejovi Vasyukovovi!), a nasleduj\u00face r\u00e1no sme po\u010duli ve\u013ea pochvaln\u00fdch slov smerom k n\u00e1\u0161mu syst\u00e9mu. Nakoniec bol zaveden\u00fd 5-min\u00fatov\u00fd \u0161tandard na vykon\u00e1vanie pr\u00e1ce.<\/p>\n

    Na zr\u00fdchlenie v\u00fdkonu sme vyu\u017eili dve met\u00f3dy: automatizovan\u00e9 testy sa za\u010dali sp\u00fa\u0161\u0165a\u0165 v troch paraleln\u00fdch pr\u00fadach, \u010do n\u00e1m ve\u013emi vyhovuje vzh\u013eadom na architekt\u00faru n\u00e1\u0161ho vernostn\u00e9ho syst\u00e9mu. Rozhodli sme sa tie\u017e vzda\u0165 pr\u00edstupu, pri ktorom automatizovan\u00fd test nevytv\u00e1ra vlastn\u00e9 testovacie \u00fadaje, ale sna\u017e\u00ed sa n\u00e1js\u0165 nie\u010do vhodn\u00e9 v syst\u00e9me. Po vykonan\u00ed zmien sa celkov\u00e9 \u010dasov\u00e9 n\u00e1roky zn\u00ed\u017eili na 3-4 min\u00faty.<\/li>\n

  7. Projekt s automatizovan\u00fdmi testami je potrebn\u00e9 vedie\u0165 nasadi\u0165 na r\u00f4znych prostrediach.<\/b> Na za\u010diatku sme sa pok\u00fasili nap\u00edsa\u0165 vlastn\u00e9 scriptovac\u00ed s\u00fabory, ale \u010doskoro bolo jasn\u00e9, \u017ee vlastn\u00fd automatizovan\u00fd in\u0161tal\u00e1tor je \u00faplne stra\u0161n\u00fd, a tak sme sa obr\u00e1tili k priemyseln\u00fdm rie\u0161eniam. Vzh\u013eadom na to, \u017ee v projekte je ve\u013emi ve\u013ea priamo k\u00f3du (predov\u0161etk\u00fdm uchov\u00e1vame k\u00f3d automatizovan\u00fdch testov) a ve\u013emi m\u00e1lo \u00fadajov (hlavn\u00e9 \u00fadaje s\u00fa metad\u00e1ta o automatizovan\u00fdch testoch), implement\u00e1cia Liquibase bola ve\u013emi jednoduch\u00e1.\n

    Je to datab\u00e1zu nez\u00e1visl\u00e1 kni\u017enica s otvoren\u00fdm zdrojov\u00fdm k\u00f3dom na sledovanie, spr\u00e1vu a aplik\u00e1ciu zmien v sch\u00e9me datab\u00e1zy. Riadi sa prostredn\u00edctvom pr\u00edkazov\u00e9ho riadku alebo r\u00e1mcov ako Apache Maven. Princ\u00edp fungovania Liquibase je pomerne jednoduch\u00fd. M\u00e1me usporiadan\u00fd projekt, ktor\u00fd sa sklad\u00e1 zo zmien alebo skriptov, ktor\u00e9 je potrebn\u00e9 aplikova\u0165 na cie\u013eov\u00fd server, a kontroln\u00e9 s\u00fabory, ktor\u00e9 ur\u010duj\u00fa, v akom porad\u00ed a s ak\u00fdmi parametrami maj\u00fa by\u0165 tieto zmeny nasaden\u00e9. <\/p>\n

    Na \u00farovni datab\u00e1zov\u00e9ho syst\u00e9mu sa vytv\u00e1ra \u0161peci\u00e1lna tabu\u013eka, v ktorej Liquibase uchov\u00e1va log zmien. Ka\u017ed\u00e1 zmena m\u00e1 vypo\u010d\u00edtan\u00fd hash, ktor\u00fd sa zaka\u017ed\u00fdm porovn\u00e1va medzi projektom a stavom v datab\u00e1ze. V\u010faka Liquibase \u013eahko aplikujeme zmeny na\u0161ej syst\u00e9mu na ak\u00fdko\u013evek kont\u00far. Automatizovan\u00e9 testy sa teraz sp\u00fa\u0161\u0165aj\u00fa na testovac\u00edch a uvo\u013e\u0148ovac\u00edch kont\u00faroch, ako aj na kontajneroch (osobn\u00fdch kont\u00faroch v\u00fdvoj\u00e1rov).<\/li>\n<\/ol>\n

    \"Unit-testy
    \n
    \nTak\u017ee, po\u010fme sa porozpr\u00e1va\u0165 o v\u00fdsledkoch pou\u017eitia n\u00e1\u0161ho syst\u00e9mu unit-testovania. <\/p>\n

      \n
    1. Samozrejme, predov\u0161etk\u00fdm sme presved\u010den\u00ed, \u017ee sme za\u010dali vyv\u00edja\u0165 kvalitnej\u0161\u00ed softv\u00e9r. Automatizovan\u00e9 testy sa sp\u00fa\u0161\u0165aj\u00fa denne a pri uvo\u013enen\u00ed nach\u00e1dzaj\u00fa desiatky ch\u00fdb. A \u010do je zauj\u00edmav\u00e9, niektor\u00e9 z t\u00fdchto ch\u00fdb s\u00fa len nepriamo spojen\u00e9 s funk\u010dnos\u0165ou, ktor\u00fa sme skuto\u010dne chceli zmeni\u0165. M\u00e1me ve\u013ek\u00e9 pochybnosti, \u017ee by tieto chyby boli n\u00e1jden\u00e9 manu\u00e1lnym testovan\u00edm. <\/li>\n
    2. T\u00edm z\u00edskal presved\u010denie, \u017ee konkr\u00e9tna funk\u010dnos\u0165 funguje spr\u00e1vne... Predov\u0161etk\u00fdm sa to t\u00fdka na\u0161ich kritick\u00fdch procesov. Napr\u00edklad, za posledn\u00fdch \u0161es\u0165 mesiacov sme nemali probl\u00e9my s rozde\u013eovan\u00edm zliav a bonusov na \u00fa\u010dte, napriek uvo\u013e\u0148ovac\u00edm zmen\u00e1m, hoci v predch\u00e1dzaj\u00facich obdobiach sa chyby vyskytovali s ur\u010ditou pravidelnos\u0165ou.<\/li>\n
    3. Podarilo sa n\u00e1m skr\u00e1ti\u0165 po\u010det iter\u00e1ci\u00ed testovania. V\u010faka tomu, \u017ee automatizovan\u00e9 testy s\u00fa p\u00edsan\u00e9 na nov\u00fd funk\u010dn\u00fd modul, sa k analytikom a s\u00fa\u010dasne testerom dost\u00e1va k\u00f3d vy\u0161\u0161ej kvality, preto\u017ee u\u017e bol overen\u00fd.<\/li>\n
    4. \u010cas\u0165 v\u00fdsledkov automatizovan\u00e9ho testovania pou\u017e\u00edvaj\u00fa v\u00fdvoj\u00e1ri. Napr\u00edklad, testovacie \u00fadaje na kontajneroch sa vytv\u00e1raj\u00fa pomocou modulu generovania objektov.<\/li>\n
    5. Nie je zanedbate\u013en\u00e9, \u017ee sa u n\u00e1s vytvorilo \"prijatie\" syst\u00e9mu automatizovan\u00e9ho testovania zo strany v\u00fdvoj\u00e1rov. Existuje porozumenie, \u017ee to je d\u00f4le\u017eit\u00e9 a pr\u00ednosn\u00e9. A zo svojich sk\u00fasenost\u00ed m\u00f4\u017eem poveda\u0165, \u017ee to nie je tak. Automatizovan\u00e9 testy je potrebn\u00e9 p\u00edsa\u0165, je potrebn\u00e9 ich udr\u017eiava\u0165 a rozv\u00edja\u0165, analyzova\u0165 v\u00fdsledky, a \u010dasto s\u00fa \u010dasov\u00e9 n\u00e1klady na to jednoducho neopodstatnen\u00e9. Ove\u013ea jednoduch\u0161ie je \u00eds\u0165 na produkciu a tam rie\u0161i\u0165 probl\u00e9my. U n\u00e1s sa v\u0161ak v\u00fdvoj\u00e1ri stavaj\u00fa do frontu a \u017eiadaj\u00fa o pokrytie ich funk\u010dnosti automatizovan\u00fdmi testami.<\/li>\n<\/ol>\n

      \u010co \u010falej<\/h2>\n

      \n\"Unit-testy
      \n
      \nPo\u010fme sa porozpr\u00e1va\u0165 o pl\u00e1noch rozvoja projektu automatizovan\u00e9ho testovania.<\/p>\n

      Samozrejme, pokia\u013e je syst\u00e9m vernosti Sportmastera akt\u00edvny a na\u010falej sa vyv\u00edja, m\u00f4\u017eeme takmer nekone\u010dne rozv\u00edja\u0165 aj automatizovan\u00e9 testy. Preto hlavn\u00e9 zameranie rozvoja je roz\u0161\u00edrenie pokrytia.<\/p>\n

      S narastaj\u00facim po\u010dtom automatizovan\u00fdch testov bude neust\u00e1le rastie aj celkov\u00fd \u010das ich vykon\u00e1vania, a op\u00e4\u0165 sa budeme musie\u0165 vr\u00e1ti\u0165 k ot\u00e1zke v\u00fdkonu. Najpravdepodobnej\u0161ie bude rie\u0161en\u00edm zv\u00fd\u0161enie po\u010dtu paraleln\u00fdch vl\u00e1kien.<\/p>\n

      Ale to s\u00fa zjavn\u00e9 cesty rozvoja. Ak hovor\u00edme o nie\u010dom menej trivi\u00e1lnom, vy\u010dle\u0148me nasleduj\u00face:<\/p>\n

        \n
      1. Aktu\u00e1lne je spr\u00e1va automatizovan\u00fdch testov realizovan\u00e1 na \u00farovni DBMS, to znamen\u00e1, \u017ee potrebujeme znalosti PL\/SQL pre \u00faspe\u0161n\u00fa pr\u00e1cu. Ak je to potrebn\u00e9, m\u00f4\u017eeme spravovanie syst\u00e9mu (napr\u00edklad vykon\u00e1vanie sp\u00fa\u0161\u0165an\u00ed alebo vytv\u00e1ranie metad\u00e1t) prenies\u0165 na nejak\u00fa administr\u00e1torsk\u00fa aplik\u00e1ciu, vyu\u017eij\u00fac Jenkins alebo nie\u010do podobn\u00e9.<\/li>\n
      2. V\u0161etci maj\u00fa radi kvantitat\u00edvne a kvalitat\u00edvne ukazovatele. Pre automatizovan\u00e9 testovanie je tak\u00fdm univerz\u00e1lnym ukazovate\u013eom Code Coverage alebo metrika pokrytia k\u00f3du. Pomocou tohoto ukazovate\u013ea m\u00f4\u017eeme ur\u010di\u0165, ak\u00e9 percento k\u00f3du na\u0161ej testovacej s\u00fastavy je pokryt\u00e9 automatizovan\u00fdmi testami. Od verzie 12.2 Oracle poskytuje mo\u017enosti na v\u00fdpo\u010det tejto metriky a navrhuje pou\u017e\u00edva\u0165 \u0161tandardn\u00fd bal\u00edk DBMS_PLSQL_CODE_COVERAGE.\n

        N\u00e1\u0161 syst\u00e9m automatizovan\u00e9ho testovania m\u00e1 nie\u010do vy\u0161e roka a mo\u017eno je teraz ten spr\u00e1vny \u010das na vyhodnotenie pokrytia. V mojom predch\u00e1dzaj\u00facom projekte (projekt nie je Sportmaster) to takto dopadlo. Po roku pr\u00e1ce s automatizovan\u00fdmi testami vedenie zadalo \u00falohu zhodnoti\u0165, ak\u00e9 percento k\u00f3du pokr\u00fdvame. Pri pokryt\u00ed nad 1% by vedenie bolo \u0161\u0165astn\u00e9. My, v\u00fdvoj\u00e1ri, sme o\u010dak\u00e1vali v\u00fdsledok okolo 10%. Pripojili sme code coverage, zmerali sme to a dostali 20%. V radosti sme sa vybrali za pr\u00e9miou, ale ako sme za \u0148ou i\u0161li a kam sme sa vybrali nesk\u00f4r, to je \u00faplne in\u00fd pr\u00edbeh.<\/li>\n

      3. Automatizovan\u00e9 testy m\u00f4\u017eu overova\u0165 vystaven\u00e9 webov\u00e9 slu\u017eby. Oracle to bez probl\u00e9mov umo\u017e\u0148uje, a my u\u017e viac nenaraz\u00edme na mno\u017estvo probl\u00e9mov. <\/li>\n
      4. A samozrejme, n\u00e1\u0161 syst\u00e9m automatizovan\u00e9ho testovania je mo\u017en\u00e9 aplikova\u0165 na in\u00fd projekt. Na\u0161e rie\u0161enie je univerz\u00e1lne a vy\u017eaduje si len pou\u017eitie Oracle. Po\u010dul som, \u017ee na in\u00fdch projektoch Sportmasteru existuje z\u00e1ujem o automatizovan\u00e9 testovanie a mo\u017eno sa k nim vyberieme.<\/li>\n<\/ol>\n

        <\/p>\n

        Zhrnutie<\/h2>\n

        \nZhr\u0148me to. Na projekte vernostn\u00e9ho syst\u00e9mu v Sportmastere sa n\u00e1m podarilo implementova\u0165 syst\u00e9m automatizovan\u00e9ho testovania. Jeho z\u00e1kladom je rie\u0161enie utPLSQL od Stevena Feiershteina. Okolo utPLSQL je k\u00f3d automatizovan\u00fdch testov a pomocn\u00e9 vlastn\u00e9 moduly: modul sp\u00fa\u0161\u0165ania, modul generovania d\u00e1t a \u010fal\u0161ie. Automatizovan\u00e9 testy sa sp\u00fa\u0161\u0165aj\u00fa denne a, \u010do je najd\u00f4le\u017eitej\u0161ie, funguj\u00fa a prin\u00e1\u0161aj\u00fa \u00fa\u017eitok. Sme presved\u010den\u00ed, \u017ee sme za\u010dali vyd\u00e1va\u0165 softv\u00e9r vy\u0161\u0161ej kvality. Z\u00edskan\u00e9 rie\u0161enie je pritom univerz\u00e1lne a m\u00f4\u017ee by\u0165 vo\u013ene aplikovan\u00e9 na ak\u00fdko\u013evek projekt, kde je potrebn\u00e9 zorganizova\u0165 automatizovan\u00e9 testovanie na datab\u00e1ze Oracle.<\/p>\n

        P.S. Tento \u010dl\u00e1nok nie je pr\u00edli\u0161 konkr\u00e9tny: je tu ve\u013ea textu a takmer \u017eiadne technick\u00e9 pr\u00edklady. Ak je t\u00e9ma zauj\u00edmav\u00e1, sme pripraven\u00ed pokra\u010dova\u0165 a vr\u00e1ti\u0165 sa s pokra\u010dovan\u00edm, kde povieme, \u010do sa zmenilo za posledn\u00fdch \u0161es\u0165 mesiacov a uvedieme pr\u00edklady k\u00f3du.<\/p>\n

        P\u00ed\u0161te koment\u00e1re, ak s\u00fa nejak\u00e9 body, na ktor\u00e9 by sme sa mali v bud\u00facnosti zamera\u0165, alebo ot\u00e1zky, ktor\u00e9 potrebuj\u00fa objasnenie.<\/i><\/p>\n

        Len registrovan\u00ed pou\u017e\u00edvatelia sa m\u00f4\u017eu z\u00fa\u010dastni\u0165 prieskumu. Prihl\u00e1ste sa<\/a><\/noindex>, pros\u00edm.<\/p>\n

        P\u00ed\u0161eme o tom \u010falej?<\/h2>\n