Je nerozumné psát v prostředí, za kterým není silná firma. Vždyť jde o investici vašeho úsilí (která se dá přepočítat na peníze). Pokud jste Ruby použili, zde máte (ještě zdaleka ne kritický) výsledek: prostředí se nevyvíjí, a když nakonec vyjde nová verze, má odlišnou syntaxi od staré. Konverzní nástroj neexistuje. Implementace Unicode je příšerná. Bugů je podle všeho požehnaně. Vypadá takhle vyspělé prostředí?
SAP to před časem udělal taky, že prohlásil starou verzi za nepodporovanou a v nové verzi změnil znakové kódování všech dat na UTF-8, tak, že to nešlo automaticky převést.
Nedávno jsem mluvil s lidmi, kteří mají aplikaci napsanou v legálně koupeném Kylixu, Borland to přestal vyvíjet a oni chudáci neví co s tím, vypadá to, že to budou muset celé přepsat. V tomto případě, zaplatit si někoho na odbugování Kylixu (kdyby byl free) by bylo o dost levnější než zaplatit si znovu vývoj celé aplikace.
Já měl za to, že upgrade SAPu byl běžným projektem - pokud někteří experti neměli v jedné tabulce data v různých code pages.
Borland holt dávno není tou silnou firmou. V době vydání Kylixu už bylo zjevné, že jde o dost rizikovou věc (jakkoliv příznivci Linuxu tvrdili, že vše bude OK). Rozhodnutí vyvíjet v novém prostředí firmy, která je na ústupu, pro nový OS, bylo velkým riskem. Pokud ti lidé daný risk akceptovali, mají zde výsledek - z úspory nic nebude.
Rozsah aplikace psané v Kylixu by musel být skutečně extrémní (pak o to větší risk před lety bylo použít Kylix), aby vyšlo levněji udržovat a podporovat staré vývojové prostředí. Navíc je to teoretická diskuze, protože Kylix nejspíš nikdo v nejbližších letech neuvolní.
S tím SAPem to tu někdo popisoval dost nešťastně --- šlo o to, že velká mezinárodní firma měla statisíce textů ve spoustě znakových sad (protože mají pobočky po celém světě). Člověkem to nešlo všechno přečíst a rozhodnout v jakém je to kódování. Tak na to ta firma vymýšlela různé algoritmy, co to kódování z textu hádaly, celkem hnus.
Ad ten Borland, po bitvě je každý generál, to je snadné teď říct "věděl jsem to, že Borland špatně skončí". Komerční program může zkrachovat úplně stejně jako free software projekt. U free projektu aspoň můžeš někoho zaplatit, aby ti ho upravil, když to originální vývojáři nechtějí udělat (já jsem momentálně za tohle placen).
Světe div se, pokud máte v jedné tabulce (která má být v jedné dané CP) záznamy v různých code pages, jde o prasárnu, a časem se to vymstí. Pobočky mohou používat různá SAP prostředí s různými code pages (například prostředí USA+EU, azbuka, arabský skript). To ale museli vědět, a rozhodli se akceptovat rizika.
Ano, výrobce komerčního SW se může klidně složit. Bohužel v tomto případě jde o málo používaný nástroj pro tak turbulentní prostředí, jakým je Linux. Kdyby pánové zůstali v Delphi, možná by to dnes nebylo úplně ultra, ale zase byli by na tom o dost lépe. Kdyby použili MS Visual Basic, který už také není podporovaný, mohli své binárky provozovat bez problémů ještě řadu let. Že se rozhodli pro celkem neznámý Kylix, který byl podporovaný na dvou distrech Linuxu, mají smůlu. Kdyby měli větší smůlu, v mezičase přestal existovat Linux.
Ještě jednou: Kylix není free projekt. A i kdyby byl, jeho údržba a rozvoj by byly velmi drahé, a těžko by to zákazník zatáhnul (kdyby CodeGear vyděli možnost z toho dostat peníze, asi by do toho šli). Kde není údržba a rozvoj, je třeba dříve či později odejít k něčemu jinému.
V daném případě nešlo o tabulky, ale o celé texty.
Ono provozovat binárku řadu let se dá na tom nepodporovaném Kylixu i na nepodporovaném Visual Basicu --- problém nastane při pokusu o rozšíření toho programu --- až jednoho dne budete chtít používat knihovnu X a zjistíte, že knihovna X vyžaduje verzi systému >= Y a nepodporované prostředí vyžaduje verzi systému < Y.
"údržba a rozvoj by byly velmi drahé, a těžko by to zákazník zatáhnul"
Údržba a rozvoj celého prostředí jsou dost drahé. Ale zakázky typu "potřebuju do free softwaru featuru X --- zaplatím za to 30000" nebo "neběží to pod verzí systému Y --- zaplatím za to, aby to běželo" tak drahé nejsou. Člověk si to může udělat sám, pokud umí programovat, nebo si to nechat napsat za méně než by byl měsíční plat zaměstnance. Výhoda je, že v tomto případě firma platí jen za featury, které skutečně potřebuje, a ne za blbosti typu poskakující sponka.
Binárku napsanou ve VB můžete provozovat bez problémů, a nestane se vám, že nové distro má jinou verzi glibc.
Samozřejmě další vývoj aplikace v prostředí, které není podporované a rozvíjené, je velký problém. Spousta věcí se dá obejít, ale nakonec stejně musíte přejít na jiné prostředí. To platí i v případě, že máte od prostředí zdroják, a necháte někoho, ať vám něco dobastlí.
Mimochodem v desítkách tisíc Kč toho opravdu moc nekoupíte, nejvýše jednotky dnů.
Binarku ve VB sice můžete používat bez problémů, ale také se může stát, že systém má jinou verzi knihoven *.dll. Zrovna pro VB se to stává. V tomhle nemáte pravdu.
Druhak, tady nejde o binárku. To Vám snad BLEK vysvětlil dost jasně.
A do třetice, pakliže k projektu máte zdrojáky, tak Vás vůbec nemusí trápit, zda je prostředí dále podporované, nebo vyvíjené. Můžete si to prostředí udržovat při životě sám. Ostatně je to jen charakteristický rozdíl mezi aplikací, kterou máte celou ve své režii, a prostředím, kde hostujete cizí aplikace. Dokonce takové udržování není nijak drahé. V tomto opět žel nemáte pravdu.
Doporucuji se s clovekem "LO" vubec nebavit, je to ztrata casu. On ma nactenych par marketingovych materialu a umi nekolik slov z kerneltrapu, ale jinak je to looser, co umi jen blafovat.
Jeho nazor nezmenite ani exaktnim dukazem -- logika je pro nej nezavazna.
Prosim o to, s nim vubec nediskutovat. On se pak nauci dobre blafovat a chodi nam po firmach a oblbuje nakupci softwaru. Odberatel a poctivi dodavatele pak susi hubu.
Dekuji.
Udrzovani prostredi neni drahe? Zkuste si spocitat na kolik by vas vyslo inhouse udrzovat napriklad Python (kuprikladu prepsat ho tak, aby umel nativne thready a nemel Global lock), o prostredich velikosti Javy SE uz vubec memluvim.
Inhouse udrzovani jiz neudrzovanych prostredi je docasne nouzove reseni, to se rozhodne neda delat dlouhodobe. Kde napriklad sezenete lidi co umi delat jiz v 5 let mrtvem prostedi? Ano mohou se to sice naucit, ale to je pomale a tudiz drahe.
K tem embedded zarizenim, tohle delavaji dva druhy firem: Jedny proto, ze pouzivaji linux/gcc/whatever jako svoji platformu (kterou dale prodavaji) a vetsinou tim padem i tyto forky udrzuji, druhou skupinou jsou firmy, co na Linuxu stavi nektera sva zarizeni a vetsinou si pouze drzi jednu konkretni verzi kernelu/gcc/distribuce s prislusnymi patchy a dal je neudrzuji, protoze proto pro ne neni duvod. Ani jedno neni prilis narocne.
Coz je ovsem uplne neco jinyho jako pokracovat v vyvoji neceho, co je postavene na zastarale, nestabilni ci jinak spatne technologii technologii. A to je prave to, co se muze setsakramentsky prodrazit... Ale jako vzdycky, zalezi, co vyvijite a pro koho. Opravdu uplne jine rozhodnuti budete delat v pripade SW, co budete muset supportovat mnoho let nez u par utilitek ci webu na vicemene jedno pouziti :)
Ono jde o to, že to odprasení kódu je časově výrazně náročnější, ale ušetří čas při dlouhodobé správě.
Nemůžeš třeba do platformě-nezávislého souboru ve zdrojácích Linuxu napsat "#ifdef toto_je_uplne_progresivni_mips_platforma_na_kterou_bastlime". S tím bys z konference linux-kernel vyjel jak namydlenej blesk. Kdyby tohle do zdrojáků dopsal každý, kdo vyvíjí nějakou embedded krabičku na Linuxu, tak si asi dokážeme představit, jak by ty zdrojáky vypadaly.
Správně se musí vymyslet nějaké rozhraní a platformě-závislé věci držet na jednom místě. Jenomže to vymýšlení rozhraní bere dost času. Pokud to uděláš, budeš mít svůj kód v hlavním stromě udržován vývojáři Linuxu, jinak si ho musíš spravovat sám.
Pro dost firem je jednodušší ta varianta "spravuj si to sám" --- a tak v krabičce koupené před měsícem mám kernel 2.4.17 kompilovaný v dubnu 2007. A ono to ani moc nevadí, stejně to funguje.
Mně taky někdo kdysi poslal port Linksu na Playstation, ale já mu řekl "všechny věci týkající-se playstation musí být na jednom místě (v souboru os_dep.c), jinak to nevezmu", on se už neodhodlal to předělávat, tak má z Linksu fork.
- První jsou mé zkušenosti, kdy jsem sám udržoval několik(2-3) takových prostředí. Není to žádný problém. Pravda, nebyli to obludy, jako je JSE, ale to je extrém.
- Za druhé je třeba si uvědomit, co si vlastně na těch prostředích, případně i zmiňovaný JSE chcete udržovat? Pokud nechcete nahradit původního vývojáře, o čemž není řeč, tak děláte jen dvě věci: 1/ Opravujete chyby, 2/ vyvíjíte nové fičury, ale obé jen v případě, že na ně narazíte v použití Vaší aplikace. Díky tomu to zdaleka není tak hrozné.
Dokážu si představit, že péče o toto přijaté prostředí by nevyžadoval víc jak třeba dvacet procent času vývojáře.
Pravda je ta, že, časem většina projektů dospěje do stádia, kdy jsou neudržitelné. Ale tomu se nevyhnete. A přepisovat se bude každá aplikace, ať už je closed, nebo open source. Na druhou stranu u open source máte mnohem větší možnosti.
No tak má systém jinou verzi DLL knihoven. Například v případě Common Controls je to i velmi pravděpodobné. Vadí to snad něčemu?
Je pěkné, pokud mám IDE, a aplikaci lze přeložit. Ale výslednou aplikaci také potřebujete provozovat - jde i o ni.
Údržbu a rozvoj si zaplatíte sám? Borlandu se na obojí skládala hromada zákazníků, a nějak se to nezaplatilo. CodeGears to vzdali, protože by to zákazníci nezaplatili. Ale vy na sebe vezmete ten finanční balvan jako maličká firma. Mnoho úspěchů. A opět jen teoreticky, protože zdrojáky ke Kylixu vám nikdo nedá.
Napadá mě, když je to s tou údržbou a rozvojem tak jednoduché, proč nenecháte někoho implementovat CLX do Free Pascalu? Jeden člověko-rok (tedy částka v řádech milionů až desítek milionů), a už máte kousek hotový.
Člověko-rok je taková jednotka ve světě projektového managementu. Jde o množství práce, které odvede jeden člověk za rok, dva za půl roku atd. Pro úplnost, 365 lidí tu práci nikdy neodvede za den, protože narůstá overhead.
Ty jednotky až desítky milionů samozřejmě nedostane autor SW. Rozdělí se mezi stát (sociální a zdravotní pojištění), nájem kanceláře, amortizaci techniky, plat managera a účetní... V ČR si lze přijít na jednotky milionů ročně. Zahraničí už na tom není o tolik lépe, rozdíly už nejsou řádové. Řada lidí vychytala ten správný moment, a v zahraničí vydělala na naše poměry obrovské peníze.
Ano, vadí. Protože pak mi ta aplikace nefunguje, žejo.
Měl by jste pochopit, že zdrojáky k programům nejsou proto, aby měli programátoři radost. Jsou pro zákazníky. Oni by je sice teoreticky nepotřebovali. Ale je to jediný rozumný a funkční důvod, jak zajistit, že bude mít zákazník aplikaci stále použitelnou i v případě změněných podmínek. (Například změna DPH.)
A i z Vašeho popisu jasně vyplývá, že není jiná cesta. Buď si zákazník koupí closed aplikaci, a pak riskuje, že tyto peníze vyhodí oknem (téměř jistota), a nebo si koupí open aplikaci a zaplatí možná o něco málo navíc, ale ty peníze budou opravdu zužitkované.
Bohužel použitelné české účto pod GPL ještě nikdo nevydal. A víte proč? Protože jakmile si ho koupí jeden uživatel, může ho legálně dát komukoliv dalšímu. Autor by pak umřel hlady. Autor správně ví, že na zdrojáku závisí jeho obživa. A když už dá (da velké peníze) zdroják z ruky, musí se ujistit, že ho zákazník nebude šířit, protože by byla smrt businessu.
On za Apache zřejmě nezaplatil nikdo nikdy nic. Jeho kvalita tomu také odpovídá. Můžete namítat, že se hodně používá. Jistě, ale to je věc nulové ceny (která například u ISP hraje obrosvkou roli - nejsou schopni zaplatit ani lidi, natož SW), nikoliv kvality.
Vývoj Apache platí nadace Apache Software Foundation, které přispívá ponejvíce Google, Yahoo a HP. A samozřejmě se jedná o bývalý univerzitní projekt, který Apache Software Foundation pouze udržuje a rozvíjí.
Možná až budete vyrábět účto, podaří se vám přemluvit Google a Yahoo, aby vývoj zaplatili. Nebo zkuste Seznam a Jyxo ;)
Já vím. Ale Váš včerejší příspěvek to dostatečně vyvrací. Protože jste tam nehovořil o tom, kdo bude vývoj financovat, jako, že nebude z principu. A to jste mi dnes potvrdil, že není pravda.
Zkuste se nad tím zamyslet. Každý vývoj každého produktu musí někdo financovat. A platí to i o GPL. O tom tu nikdo nepochybuje. GPL není zadarmo. Minimálně si ho budu financovat já sám.
Vzhledem k Vašemu náhledu na problematiku financování GPL bych rád poukázal na filozofii GPL tak jak ji nastínil Richar Stallman. "Platit se má za služby, ne za produkt." Když se nad tím hlouběji zamyslíte tak si všimnete rozdílu Vámi zmiňovaných společností Google, Jyxo, Seznam (ale i to Yahoo a HP) oproti Microsoftu.
Co se týče kvalit, tak to je - obávám se - čistě Věc vašeho názoru. Ne-li vkusu.
"Mimochodem v desítkách tisíc Kč toho opravdu moc nekoupíte, nejvýše jednotky dnů."
To možná tak u nějakejch předraženejch kravaťáckých firem (viděl jsem takhle nabídku zaměstnání nějaké konzultantské firmy --- 1e5 Kč měsíčně). Tam samozřejmě platíte nejen za práci, ale i za oblek prodávajícího, za jeho luxusní kancelář, za jeho luxusní auto ... aby na Vás působil dost reprezentativně.
Já za 10000 přežiji jeden měsíc (čímž netvrdím, že bych za to celý měsíc byl ochoten programovat). Nemám ženu ani děti a nepořizuji si luxusní zboží, protože mám poruchu osobnosti a emocionálně mě to nevzrušuje.
No a za kolik jste ochoten měsíc pracovat na dané aktivitě? Spočítejte alokaci (jakou část času dostanete opravdu zaplaceno od zákazníka), a vydělte částku alokací. Započítejte sociální a zdravotní pojištění (tj. vynásobte částku dvěma). Rozpočtěte cenu kanceláře, židle a stolu, počítače, kávovaru, započtěte vodu, plyn, topení. Započtěte, že máte 6 týdnů dovolené, jdete za rok 15x k lékaři (to je tuším český průměr), jste pár týdnů nemocný s chřipkou apod., jinými slovy vynásobte částku nějakými 1.2-1.3. Někdo vám musí sehnat kšeft (a ano, auto je k tomu třeba, protože většina jednání skončí neúspěchem, a on jich musí absolvovat hromadu), někdo musí vystavit faktury a vést účetnictví. Z toho všeho se skládá částka, za kterou si vás lze měsíčně koupit.
A jste schopen předem říci, na kolik vyjde výsledek, nebo prostě říkáte "až to bude, tak to bude"? Když potřebuji práci hotovou k nějakému datu, mohu se spolehnout, že bude hotová? Jste schopen se zákazníkem mluvit, nevypadat u toho jako socka (mít sako a kravatu)? Budete fakt zjišťovat, co ten zákazník vlastně chce, a snažit se mu pomoci, i když zákazník nebude mít potřebné znalosti (lama zkurvená, RTFM, že), nebo nebude vědět co chce? Nebo si budete něco kutit na svém stroji, nikdo nebude vědět, co děláte, a nebudete mít žádný výsledek, za který by někdo byl ochoten zaplatit?
Když se vám problém nepodaří vyřešit, vyjde to na dost peněz. Má se za vás kdo odborně postavit, přispět zkušenostmi, a pracovat na řešení problému, nebo v takovém případě prostě spálíte peníze bez výsledku?
To jsou některé důvody, proč kravaťák asi dostane mnohonásobek vašeho platu. A když si jako firma koupíte nekravaťáka, je to stejně nerozumné, jako psát aplikaci v Kylixu pro Linux, jenom na jiné úrovni.
Ono ale firmam nejde v prvni rade o to platit mene. Jim jde o to, aby vyresili v rozumne dobe svuj problem (to jest projekt se musi zdarne dokoncit), meli k tomu support a aby tato investice mela ROI.
Myslite ze si nekdo najme jednoho nekravataka byt za 10k mesicne, kteremu se ale nechce moc delat? Jake jsou zaruky ze bude projekt dokoncen v terminu, a bude vubec uspesne dokoncen? Bude k tomu support, dokumentace a zaruky?
Takže je to ve stylu "nevěřím, že mi to člověk udělá dobře --- najmu si kravaťáka". Ale pokud mu věříš, a pokud on opravdu práci umí a nepodrazí tě, tak ten kravaťák už moc potřeba není.
No, ono to vetsinou neni o tom, ze by to delal ten kravatak, ale ze ten kravatak (resp. presneji firma) zajisti realizaci, komunikaci s zakaznikem, QA etc ... Coz vetsinou, kdyz si najmes toho "nekravataka", musi vsechno delat sam - a to stoji penize
Jak chceš komunikovat se zakaznikem, když máš poruchu osobnosti? Zákazník je Láma a chce mluvit s někým kdo je na úrovni a neblekotá pořád o poruše osobnosti.
Dělal jsem na větším projektu ve Flashi. Pak vyšel nový flash a v něm nový jazyk: Action Script 2.0. Prezentovaný jako geniální řešení všech problémů. Sice bylo možné provozovat i staré skripty v AS 1, ale komponenty už byly jen v nové verzi, takže staré projekty nešly ani "zkompilovat". Tak jsme to přepsali do AS2.
A přišla další verze a s ní opět nový jazyk: Action Script 3.0. A nové sady nových komponent. Zpětná kompatibilita opět 0.
Bohužel platí, že kdo chce větší komfort pokročilého jazyka, nemůže se spolehnout na nic. Jistoty a prosperita čekají jedině u C.
Dělat v AS1 větší projekt si nedovedu představit. :-)
Mimochodem kdo Vás nutil ten projekt přepsat do AS2/AS3? Flash Player je zpětně kompatibilní až k FutureSplash (de facto SWF1)! Takže když už jste byli tak schopní napsat něco velkého v AS1 není problém to zkompilovat a provozovat dále i ve FP9.(vyjímku tvoří snad jen security model od verze FP7). Dobré by bylo říct o které komponenty šlo, protože nevěřím, že by ty komponenty přepsali tak, že by byly absolutně nekompatibilní..
"When you use certain programs to edit files on a home computer that uses Windows Home Server, the files may become corrupted when you save them to the home server," Microsoft said in a support document posted last week.
The document went on to list the software, which includes Windows Vista Photo Gallery, Windows Live Photo Gallery, OneNote 2003, OneNote 2007, Outlook 2007, Microsoft Money 2007 and SyncToy 2.0 Beta. Others programs, however, may also corrupt files stored on a home server powered by Microsoft's operating system.
Takze bud neni MS dost velka firma, nebo neni rozumne pouzivat zadne prostredi, bez ohledu na to jaka firma za nim stoji ...
Pokud vnimas jako problem, ze developement verze nema odladene vsechny bugy
a zaroven beres jako samozrejmost, ze prodavana finalni verze nema odladene vsechny bugy,
tak mas docela zajimavy zpusob uvazovani ....
Nebo to mam chapat proste tak, ze bugy v developement verzich OSS jsou problem, protoze za nima nestoji velka firma,
zatimco bugy v prodavanych finalnich verzich MS softu jsou normalni, protoze za nima stoji velka firma?
Proste tvuj pristup nechapu ... zavaznost problemu asi zavisi na tom, jestli je zpusobuje MS, nebo nekdo jiny ....
Není to tolik let, co takový kotrmelec předvedl Microsoft s VB6. A pokud si dobře vzpomínám tak .NET1 se tu ani neohřál, a už je tu nekompatibilní .NET2. Některé jeho části byly zabugované, nehotové a bez dokumentace. Rád vždy slyším kritiku od toho pravého.
.NET Framework má slušnou kompatibilitu, a MS vývojové nástroje nabízí převod kódu do nové verze. Navíc můžete provozovat aplikaci psanou pro .NET Framework 1.0 i na Vistě, která má .NET Framework 3.0 (jeden stroj může mít více verzí .NET Frameworku).
Kotrmelec s VB6 si nějak nepamatuji. Pamatuji si, že MS prohlásil, že další vývoj bude probíhat pro .NET, což bylo strategické rozhodnutí. A dnes je vidět, že správné.
Když jsme u toho, třeba Java není plně zpětně kompatibilní. A ten cirkus s různými GUI, newio apod. je také dost ostudný. Sun zjevně nevěděl, co dělá, a výsledkem byl v řadě ohledů pěkný guláš.
O jakém přerušení kompatibility to mluvíte? V případě VB6 máte možnost běžet výsledné binárky bez problémů do dneška, a zřejmě ještě dlouhou řadu dalších let. VB.NET nabízí (nabízel) možnost převodu kódu z VB6, migrační cesta je jasná.
Srovnejte s případem Kylixu: aplikace v něm napsané byly podporované na dvou distrech Linuxu (síla), produkt byl zastaven, a migrační cesta neexistuje.
Obávám se, že to není tak docela jak říkáte.
Když budete mít binárku a nainstalované potřebné prostředí pod windows, tak bych předpokládal, že poběží. Ale to samé se dá říci o Kylixu. Máte snad nějaké zkušenosti, nebo příklad aplikace napsané v Kylixu, binárky, která po nainstalování potřebného prostředí by neběžela? Měl bych o takovou zájem. Alespoň bych si to vyzkoušel a ověřil co říkáte.
Ja mam Net 1.0 a soucasne s nim dvojku nenainstaluju protoze mi spadne instalak. Musim jednicku odinstalovat a pak to jde. Nektere aplikace ovsem vyzaduji jednicku a nektere dvojku... Myslim ze i ta Java ma s timhle mene problemu.
Nanestesti dulezita aplikace ktera vyzaduje net 1.0 se uz nevyviji a tak verze pro 2.0 nebude.
Chtelo by to smlouvu typu kdyz s vyvojem dodavatel sekne doda k tomu zdrojaky. Otazka je kdo na tohle pristoupi.
Ja vidim docela dost casto, ze se dava napsat nova aplikace misto toho aby se upravila stara a stara se upravit nemuze protoze dodavatel s tim seknul a sources nejsou. Chce si to proste vybirat perspektivni dodavatele a ne se rozhodovat pro ty nejlevnejsi. On se to management po par techto zkusenostech snad nauci.
Tak to máte někde problém. Ale od toho je tu log z instalace (msiexec /?, tam už najdete potřebné), případně support.
Někteří dodavatelé dávají zdrojáky, a zavazují zákazníka, že je nebude šířit. Tím pravda také přicházejí o business, ale není to tak hrozné. Lepší je "firemní závěť", kde zdrojáky leží v trezoru, a pokud firma zanikne, nebo není schopna dostát závazkům, zdrojáky zákazník dostane.
cili jinymi slovy Ruby se pro Microsoft stava konkurentem, soude podle sily (a demagogicnosti) reakce
BTW, jak muze nakonec vyjit nova verze, kdyz se prostredi nevyviji?
jinak tady je mala ukazka toho, co lze pomoci "nevyspeleho prostredi" vytvorit