31
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
32
Studium a uplatnění / Re:Softwarové inženýrství - jaká je metodika?
« kdy: 11. 06. 2015, 10:54:27 »
hawran: Tak k tomuhle koštěti potřebuješ (dle platných právních předpisů v ČR) ještě tento diagram (pokud letíš do Prahy): http://lis.rlp.cz/ais_data/aip/data/valid/a2-pr-ils06.pdf
33
Studium a uplatnění / Re:Softwarové inženýrství - jaká je metodika?
« kdy: 11. 06. 2015, 10:51:07 »
Cypi, vy si z toho děláte zadek. Ale co jste kurde čekali, že se bude učit na magisterském studiu? Jak napsat if/else v PHP, Javě a Pythonu? Nebo že na státnici se bude někdo ptát "Je podle vás lepší napsat otevírací závorku IFu na stejný řádek jako podmínku nebo na další?"
Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají teoreticky, jak tlustá musí být nosná železobetonová stěna pokud v tom betonu bude tolik a tolik železné armatury... Že u rodiného domku to trefíš od oka? Supr. Ale u výškové budovy? Věř mi, budeš rád, že to projektoval někdo, kdo ten titul Ing. má.
Fakt, že celkem dost ajťáků tyto znalosti nepotřebuje a nevyužije ... je to až tak chyba školy? Všichni jsme přeci dostali možnost skončit už po bakaláři (nebo na školu vůbec nejít).
Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají teoreticky, jak tlustá musí být nosná železobetonová stěna pokud v tom betonu bude tolik a tolik železné armatury... Že u rodiného domku to trefíš od oka? Supr. Ale u výškové budovy? Věř mi, budeš rád, že to projektoval někdo, kdo ten titul Ing. má.
Fakt, že celkem dost ajťáků tyto znalosti nepotřebuje a nevyužije ... je to až tak chyba školy? Všichni jsme přeci dostali možnost skončit už po bakaláři (nebo na školu vůbec nejít).
34
Studium a uplatnění / Re:Softwarové inženýrství - jaká je metodika?
« kdy: 11. 06. 2015, 10:13:34 »Kdyz to ctu ... a jak se obsluhuje koste vis? Nebo na to nejdriv budes delat analyzu a vyvojovej diagram?
Na obsluhu koštěte není potřeba žádná složitá analýza ani vývojový diagram, protože se nejedná o žádný vývoj.
Ale diagram aktivit určitě bude potřeba, bo práce s koštětem zcela jistě aktivitou je. Statový diagram též, neboť je potřeba zachytit změnu stavu podlahy ze zaprášené na méně zaprášenou po každém máchnutí koštětem. Stejně jako zachytit opotřebení chlupů na koštěti...
35
Studium a uplatnění / Re:Softwarové inženýrství - jaká je metodika?
« kdy: 11. 06. 2015, 08:55:32 »
Tipl bych, že FEI VŠB-TUO - tento příspěvek mi nápadně připomíná borce, který tento týden přesně na tomto vyletěl od inženýrských státnic. 
Drobný rejpanec: UserStory není UML diagram - ta otázka od té ženské prý byla na UML diagramy.
Nicméně UserStory i UseCase samozřejmě patří do sběru požadavků (obecně UserStory u agilních metodik, UseCase u OpenUP a RUP).
UseCase je textový dokument s přesně definovanými náležitostmi (viz příklad: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html ); UseCase UML diagram zobrazuje pouze vztahy aktéři <-> případy užití a mezi případy užití samotnými, ale scénáře samotných případů užití nikoliv.
Samufaj: Dá se tam kromě UseCase diagramu (který se AFAIK může a nemusí dělat) použít i diagram aktivit. Sekvenční bych jim osobně řekl že ne, že to je spíš do návrhu.
V praxi platí, že pokud Ti pomůže v komunikaci se zákazníkem, tak ho udělej - pokud popisuješ business procesy pomocí UML, tak ten sekvenční lze použít (viz např. předmět MSPS). Jenomže škola není praxe a p*ča co v životě neviděla reálný projekt k tomu bude přistupovat jinak. Zkus zajít za Štolfou, který má vlastní firmu a slušnou praxi, ale ptej se ho na konkrétní otázky - je to totální bordelář a jeho studijní materiály, výklady, projev i přednášky se vyznačují extrémně vysokou mírou entropie
, což ale asi víš. Z odpovědi na obecnou otázku se nedozvíš nic, ale konkrétní otázky jsou v pohodě a fakt dokáže pomoct. (Měl jsem ho jako vedoucího diplomky ... no chvilu mi trvalo, než jsem si na jeho styl zvykl.)
Jinak Štolfa by IMHO na tuto otázku chtěl slyšet odpověď něco v tom smyslu, že výstupem fáze definice požadavků jsou artefakty (to slovo "artefakt" je pro něj důležité), které jsou v řádku "outputs" v tabulce v tomto dokumentu: http://epf.eclipse.org/wikis/openup/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements_90D272B9.html?nodeId=e1fcc9d0
On je hodně zatížený na OpenUP, celý ten framework i s dokumentací najdeš tady: http://epf.eclipse.org/wikis/openup/
Je na to možno koukat jako na trochu odlehčenou (a bezplatnou) verzi Rational Unified Process a lze s tím pracovat i bez drahého a nákladného školení, nicméně se hodí jen pro menší týmy. Jo a není to agilní metodika, tam to probíhá jinak.
Petriho sítě jsem nikde při samotném vývoji softwaru neviděl použité. Ale při vývoji, validaci a optimalizacích byznys procesů ano - na základě takto optimalizovaných procesů můžeš vyvinout řídící software nebo informační systém. Těžko říct, jestli to u státnic zmiňovat či nikoliv.
Drobný rejpanec: UserStory není UML diagram - ta otázka od té ženské prý byla na UML diagramy.
Nicméně UserStory i UseCase samozřejmě patří do sběru požadavků (obecně UserStory u agilních metodik, UseCase u OpenUP a RUP).UseCase je textový dokument s přesně definovanými náležitostmi (viz příklad: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html ); UseCase UML diagram zobrazuje pouze vztahy aktéři <-> případy užití a mezi případy užití samotnými, ale scénáře samotných případů užití nikoliv.
Samufaj: Dá se tam kromě UseCase diagramu (který se AFAIK může a nemusí dělat) použít i diagram aktivit. Sekvenční bych jim osobně řekl že ne, že to je spíš do návrhu.
V praxi platí, že pokud Ti pomůže v komunikaci se zákazníkem, tak ho udělej - pokud popisuješ business procesy pomocí UML, tak ten sekvenční lze použít (viz např. předmět MSPS). Jenomže škola není praxe a p*ča co v životě neviděla reálný projekt k tomu bude přistupovat jinak. Zkus zajít za Štolfou, který má vlastní firmu a slušnou praxi, ale ptej se ho na konkrétní otázky - je to totální bordelář a jeho studijní materiály, výklady, projev i přednášky se vyznačují extrémně vysokou mírou entropie
, což ale asi víš. Z odpovědi na obecnou otázku se nedozvíš nic, ale konkrétní otázky jsou v pohodě a fakt dokáže pomoct. (Měl jsem ho jako vedoucího diplomky ... no chvilu mi trvalo, než jsem si na jeho styl zvykl.)Jinak Štolfa by IMHO na tuto otázku chtěl slyšet odpověď něco v tom smyslu, že výstupem fáze definice požadavků jsou artefakty (to slovo "artefakt" je pro něj důležité), které jsou v řádku "outputs" v tabulce v tomto dokumentu: http://epf.eclipse.org/wikis/openup/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements_90D272B9.html?nodeId=e1fcc9d0
On je hodně zatížený na OpenUP, celý ten framework i s dokumentací najdeš tady: http://epf.eclipse.org/wikis/openup/
Je na to možno koukat jako na trochu odlehčenou (a bezplatnou) verzi Rational Unified Process a lze s tím pracovat i bez drahého a nákladného školení, nicméně se hodí jen pro menší týmy. Jo a není to agilní metodika, tam to probíhá jinak.
Petriho sítě jsem nikde při samotném vývoji softwaru neviděl použité. Ale při vývoji, validaci a optimalizacích byznys procesů ano - na základě takto optimalizovaných procesů můžeš vyvinout řídící software nebo informační systém. Těžko říct, jestli to u státnic zmiňovat či nikoliv.
36
Vývoj / Re:V jaké verzi Visual Studia vyvíjíte komerčně?
« kdy: 09. 06. 2015, 20:12:12 »
A community edition taky, pokud to licence dovoluje (je tam omezen počet členů vývojového týmu).
Community edice podporuje pluginy, takže např. ReSharper funguje. Ty merge moduly jsem ale nezkoumal nikde - vědomě jsem to nikdy nepoužil a to už jsem si sáhl i na deployment komerčních desktop aplikací.
Community edice podporuje pluginy, takže např. ReSharper funguje. Ty merge moduly jsem ale nezkoumal nikde - vědomě jsem to nikdy nepoužil a to už jsem si sáhl i na deployment komerčních desktop aplikací.
37
Vývoj / Re:V jaké verzi Visual Studia vyvíjíte komerčně?
« kdy: 09. 06. 2015, 14:22:25 »
2013 Community edice je zdarma, obsahuje všechny vlastnosti Prof. edice. Je použitelná i komerčně - pro jednotlivce a malé týmy (tuším do 5 lidí). Rozhodně to není crippleware typu jiných vývojových nástrojů, kde třeba v nejslabší (byť těžce placené) edici se nelze vyvíjet programy pracující s databází.
Pokud někoho zaměstnavatel nutí vyvíjet v Express edici, která neumí skoro nic, je to na vážný pohovor. Buď o tom, zda-li se mu ten vývoj softwaru skutečně tolik nevyplácí, aby do toho neinvestoval peníze za alespoň Profi+ReSharper, nebo je na na místě zvážit jiného zaměstnavatele. Express edice se hodí opravdu jenom pro výuku či pro jednoduché projekty.
Ad "pro zaměstnavatele bych vyvíjel v 2010" ... proč? V mnoha případech k tomu důvod není...
Pokud někoho zaměstnavatel nutí vyvíjet v Express edici, která neumí skoro nic, je to na vážný pohovor. Buď o tom, zda-li se mu ten vývoj softwaru skutečně tolik nevyplácí, aby do toho neinvestoval peníze za alespoň Profi+ReSharper, nebo je na na místě zvážit jiného zaměstnavatele. Express edice se hodí opravdu jenom pro výuku či pro jednoduché projekty.
Ad "pro zaměstnavatele bych vyvíjel v 2010" ... proč? V mnoha případech k tomu důvod není...
38
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 01. 06. 2015, 08:26:58 »
Jak to po sobě čtu, říkám si, že o Dalviku jsem asi neměl mluvit v minulém čase. :-) Hodně lidí (vč. mě) má v kapse Android 4.4, což je poslední verze, kde by (dle plánů) Dalvik měl být.
39
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 01. 06. 2015, 08:24:14 »
Sun měl svýho času podporu Javy v hardwaru. Tím pádem (subset) bajtkódu = asm ;-) .
A ano, byl to finanční fail.
BTW v nových verzích Androidu už Dalviku odzvonilo, místo toho je tam ART. Hlavní rozdíl (pro uživatele) je v tom, že se celá aplikace kompiluje do nativního kódu při instalaci. U Dalviku se použil JIT na hodně využívané části, zbytek bajtkódu byl interpretován.
A ano, byl to finanční fail.
BTW v nových verzích Androidu už Dalviku odzvonilo, místo toho je tam ART. Hlavní rozdíl (pro uživatele) je v tom, že se celá aplikace kompiluje do nativního kódu při instalaci. U Dalviku se použil JIT na hodně využívané části, zbytek bajtkódu byl interpretován.
40
Hardware / Re:Bude grafika do USB 2.0 použitelná
« kdy: 29. 05. 2015, 16:05:00 »
FullHD přes VGA bude rozmazané/méně kvalitní pořád. To je prostě technické omezení.
41
Vývoj / Re:Rady pre zacinajuceho android programatora
« kdy: 26. 05. 2015, 07:09:10 »
AFAIK Xamarin stojí nějaké peníze a platí se každý měsíc používání. Android SDK a Android Studio od Googlu jsou zdarma. Tohle by byl můj hlavní motivátor, proč zkusit "tu jejich" Javu. Jen je třeba dát pozor na to, že Oracle HotSpot VM je jiná než Dalvik, kde dost věcí není podporováno.
42
Studium a uplatnění / Re:Vzít si na pohovor společenský oblek?
« kdy: 25. 05. 2015, 07:32:40 »
Nejlepší odpověď je asi toto: http://forum.root.cz/index.php?topic=11248.msg131223#msg131223
Já osobně jsem na pohovory do menších firem chodil v business casual (tedy neformální košile a kalhoty, ne jeansy a ne sportovní obuv), ostatní u pohovoru (ředitel + technický poradce) byli taky takto. Světlý oblek (šedá, béžová) je asi tak nejlepší, to jsem použil když jsem se hlásil do korporace - manažer měl též světlý oblek, technik košili a rifle.
Pokud takový oblek nemáš, je lepší přijít v jeanách (rozhodně dlouhé kalhoty), slušné triko (ne tux, ne "forget google, ask me") nebo polokošile. Tmavý oblek udělá více škody než "slušné ajťácké", zvlášť když Ti nesedí dobře nebo ho neumíš nosit. Přijímací pohovor není příležitost pro večerní společenský oděv. A mít smoking, který se nenosí před 6. večer, znamená, že ses právě vrátil z nějaké snobácké chlastačky - to je úplně mimo.
Já osobně jsem na pohovory do menších firem chodil v business casual (tedy neformální košile a kalhoty, ne jeansy a ne sportovní obuv), ostatní u pohovoru (ředitel + technický poradce) byli taky takto. Světlý oblek (šedá, béžová) je asi tak nejlepší, to jsem použil když jsem se hlásil do korporace - manažer měl též světlý oblek, technik košili a rifle.
Pokud takový oblek nemáš, je lepší přijít v jeanách (rozhodně dlouhé kalhoty), slušné triko (ne tux, ne "forget google, ask me") nebo polokošile. Tmavý oblek udělá více škody než "slušné ajťácké", zvlášť když Ti nesedí dobře nebo ho neumíš nosit. Přijímací pohovor není příležitost pro večerní společenský oděv. A mít smoking, který se nenosí před 6. večer, znamená, že ses právě vrátil z nějaké snobácké chlastačky - to je úplně mimo.
43
Vývoj / Re:Vyvoj J2EE aplikaci
« kdy: 19. 05. 2015, 09:47:24 »
Ivane, to s PHP bylo myšleno jako humor. Živelnost a nekonzistence vývoje je na něm velmi znát, což mi nejvíc vadí (+ extrémně krátká doba podpory verzí - 3 roky - když nejsou zpětně kompatibilní) ... no a pak neefektivita téměř všeho. Fakt, že přebírá věci z Javy/Pythonu, není až tak na škodu. .Net taky vykrádal Javu jak se dalo (včetně knihoven, namátkou log4net, NHibernate (v době před Linq to SQL a Entity fwk nebylo nic jiného) atp). Na durhou stranu Javová Stream Library nápadně připomíná Linq, knihovna ModelMapper je převzetí konceptu AutoMapper apod.
Co se týče cyklů a rekurze, podle mě je rekurze jednodušší a na složitější algoritmy čitelnější, ale záleží na zvyku - nejsi-li na to zvyklý, určitě můj názor sdílet nebudeš :-) . Kde rekurze ztrácí na přehlednosti je podle mě pouze jednoduché zpracování prvků kolekce, na složitější věci je IMHO paradoxně mnohem jednodušší - pokud ovšem nenapíšeš 100 a více řádkovou rekurzivní funkci.
Pokud chceš jen projít kolekci prvků a transformovat ji na jinou (běžné použití cyklů v imperativním jazyku), ve funkcionálním jazyce máš většinou funkce jako map/filter/reduce. (V PHP jsou taky - array_map, array_filter, array_reduce.) Tím odpadne většina použití cyklů. Kdyby ještě existovala funkce jako array_foreach (což AFAIK v PHP není), odpadly by téměř všechny. Jinak tohle není jen záležitost funkcionálního programování, mluví se o nich i v knížce GoF Design Patterns (viz interní iterátory).
U rekurze je nepříjemné, že pokud nemáš tzv. koncovou rekurzi (tail-call recursion) a překladač jazyka ji nedokáže optimalizovat (obě podmínky musí být splněny), pak velice rychle zapráskáš zásobník. Nevím, jak velký je u PHP, ale u 64bitových ASP.Net aplikací je 512KB. Dost málo. Proto se většinou nepoužívá jinde než ve škole pro jednoduché algoritmy, mnozí programátoři (ani vysokoškoláci) na ni nejsou zvyklí a když vidí zápis složitějšího algoritmu (kde by rekurze mohla pomoct), tak se toho zápisu spíš leknou.
Clojure, stejně jako Scala, je plná kompromisů. Clojure je poměrně čistý jazyk, ale konstrukce jako loop-recur byly nutné kvůli JVM, které právě optimalizaci koncové rekurze nepodporuje. Stejně tak je potřeba komunikovat s Java knihovnami a proto tam jsou procedurální a objektově orientované prvky. Když je to neúnosné, řeším to tak, že kolem Java knihovny udělám příjemnější rozhraní pro použití v Clojure. Leiningen podporuje kombinované projekty v Clojure/Java celkem slušně. Většinou to nezabere až tolik času - knihovnu místo z Clojure zavolám z Java kódu a rozhraní své funkce si udělám tak, aby bylo snadno zavolatelné z Clojure.
Co se týče cyklů a rekurze, podle mě je rekurze jednodušší a na složitější algoritmy čitelnější, ale záleží na zvyku - nejsi-li na to zvyklý, určitě můj názor sdílet nebudeš :-) . Kde rekurze ztrácí na přehlednosti je podle mě pouze jednoduché zpracování prvků kolekce, na složitější věci je IMHO paradoxně mnohem jednodušší - pokud ovšem nenapíšeš 100 a více řádkovou rekurzivní funkci.
Pokud chceš jen projít kolekci prvků a transformovat ji na jinou (běžné použití cyklů v imperativním jazyku), ve funkcionálním jazyce máš většinou funkce jako map/filter/reduce. (V PHP jsou taky - array_map, array_filter, array_reduce.) Tím odpadne většina použití cyklů. Kdyby ještě existovala funkce jako array_foreach (což AFAIK v PHP není), odpadly by téměř všechny. Jinak tohle není jen záležitost funkcionálního programování, mluví se o nich i v knížce GoF Design Patterns (viz interní iterátory).
U rekurze je nepříjemné, že pokud nemáš tzv. koncovou rekurzi (tail-call recursion) a překladač jazyka ji nedokáže optimalizovat (obě podmínky musí být splněny), pak velice rychle zapráskáš zásobník. Nevím, jak velký je u PHP, ale u 64bitových ASP.Net aplikací je 512KB. Dost málo. Proto se většinou nepoužívá jinde než ve škole pro jednoduché algoritmy, mnozí programátoři (ani vysokoškoláci) na ni nejsou zvyklí a když vidí zápis složitějšího algoritmu (kde by rekurze mohla pomoct), tak se toho zápisu spíš leknou.
Clojure, stejně jako Scala, je plná kompromisů. Clojure je poměrně čistý jazyk, ale konstrukce jako loop-recur byly nutné kvůli JVM, které právě optimalizaci koncové rekurze nepodporuje. Stejně tak je potřeba komunikovat s Java knihovnami a proto tam jsou procedurální a objektově orientované prvky. Když je to neúnosné, řeším to tak, že kolem Java knihovny udělám příjemnější rozhraní pro použití v Clojure. Leiningen podporuje kombinované projekty v Clojure/Java celkem slušně. Většinou to nezabere až tolik času - knihovnu místo z Clojure zavolám z Java kódu a rozhraní své funkce si udělám tak, aby bylo snadno zavolatelné z Clojure.
44
Vývoj / Re:Nejlepší prostředí pro Linux a C vývoj
« kdy: 18. 05. 2015, 22:43:33 »
To nemusí platit univerzálně.
Instalace Eclipse Luna mi na disku zabírá cca 390MB. NetBeans 8 630MB. Visual Studio 2015 2,8GB.
Co se týče pomalosti, řekl bych, že Eclipse a VS jsou na tom stejně, NetBeans je (minimálně pocitově) trochu rychlejší.
Emacs 24.4 mi zabírá 170 MB. Nelze říci, že by byl 16,5x rychlejší než Visual Studio.
Instalace Eclipse Luna mi na disku zabírá cca 390MB. NetBeans 8 630MB. Visual Studio 2015 2,8GB.
Co se týče pomalosti, řekl bych, že Eclipse a VS jsou na tom stejně, NetBeans je (minimálně pocitově) trochu rychlejší.
Emacs 24.4 mi zabírá 170 MB. Nelze říci, že by byl 16,5x rychlejší než Visual Studio.
45
Vývoj / Re:Vyvoj J2EE aplikaci
« kdy: 18. 05. 2015, 14:30:12 »
Tady to vypadá na další flamewar :-D .
V podstatě existují 2 přístupy k návrhu programovacích jazyků (vlastně 3, ale to v poznámce "pod čarou"). Jeden vezme asembler a přidává abstrakci, druhý vezme matematiku (třeba lambda kalkul) a ubírá na abstrakci. Jazyky jako Java, C, C++, C#, Pascal jsou příkladem prvního přístupu. Až do nedávna to v podstatě byla jediná možná volba, pokud člověk nechtěl mít Hello World, který poběží 10 minut a zabere 3x více místa v paměti, než je operační paměť počítače. Haskell je spíše druhý přístup.
Průšvih, který se před pár lety stal, tedy že se narazilo na fyzikální omezení rychlosti procesorů a tedy zvyšování výkonu je snadno možné jen přidáváním více jader/procesorů, znamená zvýšený zájem o funkcionální programování. Funkcionální prvky pronikají do "mainstreamových" jazyků již celkem dlouho - i Java nebo C++ mají v nejnovější verzi lambda výrazy (jazyky jako Python nebo C# je mají už dlouho) atd. Rozhodně to není tak, že by se funkcionální programování za 50 let neprosadilo, tak už se neprosadí. Jen k tomu nebyly podmínky, teď začínají být. Problém je již napsaná spousta aplikací a knihoven, což nelze jen tak zahodit.
----------
Třetí přístup k návrhu programovacích jazyků je vzít Perl, udělat v něm DSL a nechat to samovolně a nekontrolovaně se vyvíjet. Vznikne PHP.
V podstatě existují 2 přístupy k návrhu programovacích jazyků (vlastně 3, ale to v poznámce "pod čarou"). Jeden vezme asembler a přidává abstrakci, druhý vezme matematiku (třeba lambda kalkul) a ubírá na abstrakci. Jazyky jako Java, C, C++, C#, Pascal jsou příkladem prvního přístupu. Až do nedávna to v podstatě byla jediná možná volba, pokud člověk nechtěl mít Hello World, který poběží 10 minut a zabere 3x více místa v paměti, než je operační paměť počítače. Haskell je spíše druhý přístup.
Průšvih, který se před pár lety stal, tedy že se narazilo na fyzikální omezení rychlosti procesorů a tedy zvyšování výkonu je snadno možné jen přidáváním více jader/procesorů, znamená zvýšený zájem o funkcionální programování. Funkcionální prvky pronikají do "mainstreamových" jazyků již celkem dlouho - i Java nebo C++ mají v nejnovější verzi lambda výrazy (jazyky jako Python nebo C# je mají už dlouho) atd. Rozhodně to není tak, že by se funkcionální programování za 50 let neprosadilo, tak už se neprosadí. Jen k tomu nebyly podmínky, teď začínají být. Problém je již napsaná spousta aplikací a knihoven, což nelze jen tak zahodit.
----------
Třetí přístup k návrhu programovacích jazyků je vzít Perl, udělat v něm DSL a nechat to samovolně a nekontrolovaně se vyvíjet. Vznikne PHP.
