.NET – Seznamte se, prosím 1. díl

No nevim, vzdy kdyz jsem dostal do ruky nejaky uzasny nastroj jak zjednodusit vyvoj WWW aplikaci, tak jsem skoncil na UltraEditu (oblibeny progr. editor) a nakonec i u php (pruhledne, primocare s moznosti zjistit co dela jejich zdrojak) i kdyz jsem zacinal na ASP. Take si pamatuju, ze v ASP byla i VBS a JS moznost volani funkci na serveru prostrednictvim JAVA appletu. Byla to dost obludnost. Take nejak moc nechapu, proc by se z melo z programovani WWW melo udelat programovani ala Win, nemam pocit, ze by vytvareni projektu filosofii WWW bylo nejak slozitejsi a problematictejsi nez vytvareni GUI aplikaci. Proste je z podstaty trochu o necem jinem. Faktem je, ze ASP.NET zrejme umozni programovat pekne vypadajici klikaci aplikace laikum. To zas bude nedorozumeni az zjisti, ze to neni tak jednoduche jak se to tvari. Proste je tady technologie WWW a ta vyzaduje jiste postupy (a ty musi byt z podstaty pruhledne, protoze v sitich ne vzdy vse funguje jak ma). Proc na to sroubovat neco jineho? Pouzijte terminal services a mate to stejne a myslim si, ze i efektivnejsi.
Vzdyt jde o prenaseni obrazovek, pripadne tisk, nic jineho. A ze na tom pojede i WAP. Tak to chci skutecne videt, jak MS skloubi potreby a moznosti tak odlisnych zarizeni jako je pidiobrazovka mobilu s barevnym displayem PC a mysi, aby to vubec k necemu bylo a plnilo puvodni ucel, proc se vlastne tohle deje. Nicmene, ta myslenka je zajimava a hlavne lakava, ale asi tak jako makra v dokumentech. Urcite bude nekdo, komu se bude hodit. Pruhledne to ale asi nikdy moc nebude.

Super clanek, predevsim hodnotim usporadani informaci a textu, je snadno citelny a pehledny. Ten kluk co to pise musi bejt ale hlava . Co by za takovyho dali treba v Americe ,Vsak Tomas

hmm...

VB6 a nize nebyl zas tak sqely z pohledu vyvojaru pisicich v jinych jazycich. Ale toto uz nelze rict o VB.NET, ktery je jiz opravdu konecne 100% objektove orientovany.

Podporuje vse co od OOP ocekavate. Inheritence, overloading, overriding atd., atd. Prinasi do VB mnoho C++ prvku jako je strukturovane zpracovany vyjimek, pouzivani zkracovani bool vyrazu, zkracena syntaxe matematickych operaci a mnoho dalsi.

Prichazi i s novinkami o kterych se drivejsim VB vyvojarum ani nezdalo (nebo spise jenom zdalo). Jedna se napr. o freethreading, delegates, bezproblemova konverze datovych typu mezi VB.NET a ostatnimi .NET jazyky (i kdyz toto je spise diky .NET Frameworku).

Pokud se na VB.NET podivame hodne zblizka, tak muzeme rict, ze VB.NET je "spise C++ v kabatu VB".

Ne, když už tak Java s podivnými klíčovými slovy...

Proti C++ neumí multiple inheritance, templaty, redefinice operátorů, obecné pointery, kontrola nad alokací paměti atd.

Jenze na to ten VB.NET neni vubec urceny, nehlede na to, ze spravy pameti za nej prebira kompletne .NET framework...

Prominte, ale tady se ZASADNE pri srovnavani jazyku zapomina na to nejdulezitejsi - kazda aplikace by mela slouzit ucelu, ke kteremu je urcena! Je preci uplne jedno, v cem je vytvorena!

Na co proboha silne objektove orientovany pristup na jednodussi app? Vec budto funguje k uspokojeni uzivatele, nebo ne - budto pretezuje system, nebo ne. A kdyz to ma ten programator ve VB rychleji, usetri se tim penize, protoze cas na vyvoj jsou penize.

Ja nejsem rozhodne zaden poradny programator - prestoze pri jednom projektu pouziva kolega ASM, jiny zase umi C/C++ a ja vim, ze mi ten low-level trochu chybi, neznamena to ze jsem guma, co je k nicemu. K OOP strongly typed jazyku jsem se dostal pri databazich - CA Visual Objects. OOP ma smysl tam kde ma smysl, ale taky dokaze byt pekne na ho..., dokaze byt pekny trade-off, komplikace, whatever. Pak se nedivim, ze si nekdo necha platit nakych 130KKc za projekt - staci vec udelat tak slozitou, ze se v ni vyzna jen skutecne par zasvecenych

Myslim ze by si tady mel nekdo precist jedno srovnani objektoveho Cobolu, SmallTalku a C++, kdyz uz se tu o VB hovori jako o klikadlu. Asi by pak treba vyslo najevo, ze C++ byl vlastne jakysi hybrid.

btw: umi C++ skutecne multiple inheritance? Je to jen dotaz, nesleduju C++

Co jsem take kdysi cetl byla skutecnost, ze kdyz naka spolecnost presla na C++, X krat se jim zvedly naklady a kod napuchl do nebyvalych rozmeru ...

Kazdy nastroj ma sve cilove uzivatele a svuj ucel a misto nasazeni. Chtit najit nastroj pro vsechny situace je nesmysl ...

Zdravicko,
-pekr-

Nevím, jak je to v normě C++, ale MS Visual C++ multiple inheritance umí, už dávno.

Knihovna ATL určená primárně pro implementaci COM objektů na tom dokonce vyloženě staví. Eventy se v ní zpracovávají tak, že se dědí vlastnosti z interface dispečera událostí. A když chcete odchytávat události z několika zdrojů, dědíte to interface několikrát.

MI by nemusela být špatná, i když se mimo ATL používá vyjímečně. U dvojnásobné dědičnosti se to dá přirovnat k běžné situaci - dítěti dvou rodičů. Programátor ale obvykle o objektové dědičnosti uvažuje jinak než jako o šlechtění.  tam jde o to, že stavíš na tom, co už máš. A MI je jako když se klonováním k objektu přidávají další vlastnosti. Ovšem ve výsledku pak aplikace není sestavena z jednoduchých stromů, ale ze složitých genealogií. Nemusí být snadné se v tom orientovat.

Kdyby člověk přijal tu filosofii za vlastní, mohlo by to být zajímavé. Ale v .NET máme asi nadlouho smůlu, protože IL dnes nativně MI nepodporuje. Samozřejmě by to šlo ošidit, ale bylo by to neefektivní.

Dále je nutné mít Internet Explorer 5.01 nebo vyšší.

Co tohle znamena? ASP.NET nefunguje s jinejma browserama?

Bingo!

Takze je to uplne na hovno. Vyborne to sem chtel slyset. Dal se tim nemusim zabejvat. I kdyz pak, ale vubec nechapu hlasku:

Druhá část definuje, jak bude daný formulář vypadat. ASP.NET zamění tagy za odpovídající HTML kód v závislosti na typu klienta a podporované verzi HTML. Toto je jedna z klíčových vlastností ASP.NET – kód se vždy přizpůsobí možnostem klienta. Tím je umožněno vytvářet stránky, které např. ošetřují události pomocí JavaScriptu na straně klienta, nebo pokud klient tyto možnosti nepodporuje, vyhodnocení proběhne na serveru.

Toto je potreba uvest na pravou miru.

Pro prohlizeni ASP.NET aplikaci (nebo-li aplikaci napsanych pomoci WebForms) potrebujete LIBOVOLNY prohlizes, ktery podporuje HTML 3.2!!!! Dokonce je renderovani ASP.NET stranek natolik inteligentni, ze rozpozna typ zarizeni, ze ktereho na stranky pristupujete a dle tohoto zarizeni upravi i vystup. Takze kdyz na stranku pristoupite z mobilu, tak je vystup automaticky upraven pro dany typ mobilu!

IE 5.x je potreba pouze v pripade, ze na ASP.NET strankach pouzivate WinFormsControly! Je to obdobna situace, jako kdyz jste ve starych strankach pouzivali ActiveXDocumenty, ktere byly podporovany taky jenom v IE.

Samozrejme, ze je IE potreba pro beh vlastniho Visual Studia.NET, ale to je pouze vyvojove prostredi.

OK, to dava smysl, thanks

Hmm, ja z toho spis mam pocit, ze je v te specifikaci spousta
mista pro implementaci klicek, ktere naprosto znemozni browsing
cimkoliv jinym nez IE. A ten mechanismus, co kolega prirovnava
k ActiveX, vubec nebude nepodstatnou soucasti cele veci.

Lepsi zprava je ale tady: ;)
http://www.codeweavers.com/~jwhite/tunney.html

Koukam, ze jste neverici tomas :) Prijdte se presvedcit na vlastni oci a usi na akci ASP.NET Developer Conference (http://www.microsoft.cz/akce/asp.net/).

Je to tak, ze pro tvorbu aplikaci muzete pouzit WebForms, ktere jsou urceny pro webove aplikace. Jejich vysledkem je vystup v cistem HTML 3.2 (tedy ani zadne CSS, DHTML ci skripty na strane klienta). Samozrejme, ze lze prednastavit jaky typ HTML bude pouzit pro generovani stranek.

A nebo muzete pouzit pro vyvoj WinForms, ktere ale uz potrebuji pro svuj beh .Net framework. A pokud chcete pouzit ve webovych aplikacich kousek kodu z WinForms, tak pak teprve je nutne mit IE. Jenze programovaci sila WebForms je tak mohutna, ze vubec uz neni nutne pouzivat kontroly ci jine klient-based kody.

Zdravím všechny, rád bych objasnil celou situaci :

Pochopitelně ASP.NET generuje kód který vám poběží na jakémkoli prohlížeči podporující HTML 3.2 . IE 5.01+ je pouze nutní mít instalované na servru - tz. tam kde kde se Framework instaluje fyzicky. Klienti framework nepotřebují.

ASP.NET generuje HTML na základě možností klienta. V příštím díle si ukážeme jak například ASP.NET umožňuje verifikaci formulářů. Klasický příklad je, když někdo zadává do formuláře data a vy se chcete ujistit, že do políčka skutečně něco zadal. ASP.NET si nejdříve ověří možnosti klienta a na základě např. podpory JavaScriptu proběhne buď kontrola na klientovi, nebo se formulář odešle na server, kde proběhne následné vyhodnocení. Výsledek vypadá úplně stejně, všechno je ale automatické - program tedy dostane data teprve v případě, že byl formulář správně vyplněn.

Funfuje v pohode!

- ASP.NET webovou aplikaci jde nastavit tak, ze je kompatibilni s vsemi klienty HTML 3.2 kteri k ni pristupuji.
- Pomoci Mobile Internet Toolkitu muzes navic delat aplikace kompatibilni s WML 1.1, cHTML 1.0 a zarovem HTML 3.2
- Admin pracujici na serveru s .NET Framaworkem nebo clovek vyvijejici ve VStudiu.NET musi mit IE5.01 a vyssi.
- Pro vyvoj ASP.NET aplikaci muzes pouzit NOTEPAD.EXE

Delam uz skoro 10 let v Asm a Visual C++ (hlavne se soustredim na vyvoj driveru pro robotiku). Taky jsem si hral s tou zrudnosti Visual Basicem a rikal jsem si, ze tohle snad ani neni pro programatory a DOPOSUD nechapu, jak v tom nekdo muze programovat - neni to zadny programovaci jazyk, jen klikadlo.

Proto jsem doufal, ze s objevenim se C# aspon tihle pseudoprogramatori prejdou na neco poradnejsiho. No zda se, ze tahle zrudnost jeste neni mrtva. Kdyz uz nic, tak aspon do tohlohle "nastroje" prosadte trochu profesionalni koncepty, ktere kazde prostredi a jazyk MUSI mit, ne bezduvodne se jim venovalo mnoho genialnich panu na univerzitach! Jen se tim degraduje programovani a prakticky zadny programatorVB NIC nezna o optimalizaci, programovacich algoritmech, ma minimalni matematicke zazemi, pak ten vyvoj podle toho vypada a taky proto jsou tihle klikaci na tomhle desnym toolu.

Hehe... tohle být měli číst kamarádi javisté. To mi připomíná spory Linux / Windows / Mac. Pro linuxáky jsou Windows moc grafické, pro Macisty moc textové.

Realita je taková, že ve Visual Basicu se dá programovat úplně stejně profesionálně nebo neprofesionálně jako v assembleru nebo třeba v PL/SQL. Žádný jazyk není dokonalý a je vhodný na něco jiného.

Sice teda v Jave neprogramuji, ale zajimal jsem se o ni a musim rict, ze je 1000x lepsi nez cely patlaniny co se jim rika VB. To ma aspon dobrou logiku a koncept (i kdyz napr. me jako kovanemu systemakovi tak chybi prima prace s pameti ), ale kdyz jsem videl tu specifikaci, tak to bylo docela dobre vymysleny.

Jak to souvisi s Javou, to teda nechapu...

Ale poznamka - ve VB se NEDA programovat stejne dobre jako treba v C++ - zkusil si nekdy napsat neco co ma tisice radek kodu??? Ve VB docela spaghetti, Java a C++ v pohode   Ve VB se mozna daji psat (spis klikat:) jednoduchy desetiminutovy GUI, ale kazdy rozsahlejsi program chce zodpovednejsi pristup; VB je totiz koncipovany tak, aby za kazdou enu neco udelal.

Jinak by me osobne zajimalo, co vyleze z J#. Zatim to vypada jenom na dalsi "skin" k  .NET:)))

Já osobně jsem ve VB tisíce řádek kódu nenapsal, to mám za sebou jenom v ASP, v Pascalu a hlavně ve Visual C++. Ale Petr Paleta jinde v této diskuzi píše o projektu, který má cca 100.000 řádek kódu a je napsaný ve Visual Basicu. Petr je jeden z těch, kdo řídí jeho vývoj.

Něco o tomhle projektu vím a mohu jeho slova potvrdit. Já ten výsledný program totiž používám. Rozhodnutí vyvíjet ho ve VB bylo jednoznačně správné, z mnoha hledisek. V C++ by to trvalo mnohem déle a kód by byl čitelný hůře.

>Proto jsem doufal, ze s objevenim se C# aspon tihle pseudoprogramatori prejdou na neco poradnejsiho. No zda se, ze >tahle zrudnost jeste neni mrtva. Kdyz uz nic, tak aspon do tohlohle "nastroje" prosadte trochu profesionalni koncepty, >ktere kazde prostredi a jazyk MUSI mit, ne bezduvodne se jim venovalo mnoho genialnich panu na univerzitach! Jen se >tim degraduje programovani a prakticky zadny programatorVB NIC nezna o optimalizaci, programovacich algoritmech, ma >minimalni matematicke zazemi, pak ten vyvoj podle toho vypada a taky proto jsou tihle klikaci na tomhle desnym toolu.

A jeste navic casto vydelavaji vic nez ja, hajzlove

Kolego, jestli berete jako ja 130kKc na smlouvu, tak potom prosim. Ale ja moc takovych VB smudlalu neznam

Vazeny pane, tady nejde o penize.Ja sice osobne ve VB nedelam, takze se me to primo netyka, ale vadi mi velkohuba prohlaseni o VB smudlalech. Pokud si nekdo klika a to co vyklika je zivotaschopna aplikace, je to stejne dobre odvedena prace jako ta Vase, moje, nebo posledniho kopace vykopu.

Vice pokory by Vam rozhodne neuskodilo.

Ano, to s Vami souhlasim. Ja jen prezentuji to, ze podle me je VB opravdu HODNE ale HODNE nekvalitni produkt a zel je odchytavan lidmi, co nemusi (neznamena to ze VSICHNI jsou takovy!!!) mit nejake schopnosti a schovavaji se za tohle udelatko. Kazdopadne klidne muze byt schopny programator, co jen chce udelat obalku pro svoji aplikaci a VB je na delani obalky ok.

Nic vic k tomu nemam co rict.

Tak s timhle lze jen souhlasit, diky a pekny den

Nevím, kolegové právě dokončují hodně rozsáhlou aplikaci dělanou ve VB a rozhodně to nebyla žádná hromádka kliknutí myší. Spíš tvrdá práce s objekty, kešováním binárních objektů, velice pokročilé XSLT transformace, replikace databází... Jednotlivé komponenty systému např. komunikují pomocí speciálně navrženého synchronizačního protokolu postaveného na XML..

Všechno to jede na VB.

Nevíte, o čem mluvíte.

veru veru, rozsiahle aplikacie vo VB to nie je ziadna brnkacka, pardon, par kliknuti mysou.. - a hlavne ta sprava a rozsirovanie takychto aplikacii - to je zalezitost ktora vzdy uzivi peknu kopku hard-core (=velmi odolnych:) programatorov ! ;)

Tohle je deklarace názoru, který může být podložený nějakými zkušenostmi se špatnými programy napsanými ve Visual Basicu. Ale zdůrazňuji, že to musely být programy napsané špatně.

V jakémkoliv jazyku můžete psát programy nerozšiřitelné a programy snadno rozšiřitelné. Samozřejmě to v některých jazycích jde lépe a v jiných hůře. Např. v assembleru to jde obecně o něco hůře než v C, v C o něco hůře než v C++ nebo ve Visual Basicu a ve Visual Basicu o něco hůře než v Javě a v C#.

Ale princip je takový, že rozšiřitelný a srozumitelný program (bavíme se o složitých obchodních aplikacích, ne o prográmcích) můžete napsat i v assembleru (o VB nemluvě) a naopak špatný program můžete napsat i v Javě.

A ta podstatná, rozlišující kritéria (která neokecá ani Java) jsou:

a) Zkušenost a sebekázeň programátorů.

b) Kázeň vývojového týmu (standardy psaní kódu, revize kódu atd.).

jasne, sedi, pridal by som este bod c) (podla mna najdolezitejsi) - schopny a skuseny projektovy management (resp.software architekti a pod.).
No a k bodom a)a b) - spoliehat sa v lubovolnom projekte len na "sebekazen programatorov" je imho sialenstvo :)
Druha vec je, ze napisat humusny a neprehladny a nevyocitatelny bordel (a to najma pri projektoch s radovo 10-kami (a viac) koderov) vo VB je omnoho omnoho jednoduchsie (a beznejsie) ako v Jave... btw. C# sa v tomto smere rozhodne dalej (ako Java) nedostal, skor naopak (properties, unmanaged code atd.) :)

Pozor, nepleťte si unmanaged a unsafe code. Unsafe je managed, ale umožňuje pointry. Jinak je to normálně managed kód, běžící v IL V C# můžete dělat kód unsafe, ale nikoliv unmanaged.  Jako projektový manager bych mimo vyjímečné případy unsafe zakázal a bylo by to. Unsafe je ale daleko méně nebezpečné, než JNI, takže vidíte, že na Javě musí někteří projektoví manažeři taky řešit tyhle věci.

Properties vidím spíš jako věc pozitivní. Ostatně v Javě je samozřejmě používáte taky, akorát je musíte okecávat pomocí get/set syntaxe, což je (opět) myslím horší. :)

Unmanaged (tedy nativní Win32) kód můžete ve Visual Studiu .NET programovat výhradně v C++.

A ve Visual Basicu.NET nemůžete dělat ani unsafe.

ad properties:
nie je to sice az take podstatne, ale... bavili sme sa o prehladnosti kodu a k tomu urcite neprispeju volania metod, ktore sa ale tvaria ako pristupy k clenom triedy (a od naozajstnych prisupov k clenom tried sa na oko nelisia...). Mne to teda prehladnejsie nepripada...
Vygenerovat get- a set- metody v J. je otazka dvoch kliknuti v IDE, takze to myslim nie je take hrozne..No a takym pretazovanim operatorov (v C#) sa da tiez pekne zmrvit kod. Nie, ze by to bola nejaka zla vec... Nakoniec zmrvit sa da vsetko, ked sa chce :)

To máte takto:

Properties. Věc, kterou v Javě běžně děláte, potřebujete a ... musíte řešit trikem (get/set).

Nativní přístup k platformě. Věc, kterou v Javě běžně děláte, potřebujete a ... musíte řešit trikem (JNI).

To jsou dvě konkrétní věci, které v C# budete dělat pravděpodobně úplně stejně často jako v Javě, ale elegantněji a lépe kontrolovaným způsobem.

no ja si stale myslim, ze properties v C# nie je ani lepsi ani elegantnejsi sposob, resp. nevidim dovod, preco riesenie v J. nazyvat trikom :)

Tak to mate pravdu, ze NASTESTI nevim o cem mluvim. NASTESTI vzdy jsem ten, co programuje systemove pozadi prave pro tyhle packaly ve VB a kdyz pak vidim co s tim delaji a jak ja musim opripominkovavat ten vyvoj, tak me jima des.

To, ze nekde pouzivaji cachovani nebo XML/XSL  no nenechte se vysmat, to preci nemuzete myslet vazne, ale to neni VUBEC nic sloziteho. Ad replikace databazi, pokud si ti Vasi hosici nepsali vlastni SQL server, tak potom to neni VUBEC jejich praci. Jeden muj byvaly spoluzak prave dela v backoffice tymu a i pro nej (a to i pres to ze je v MS) je VB jen uboha vec a jen proto, aby se mohlo zivit dalsi oddeleni MS. Jinak NIKDO, SLOVY NIKDO v jadru backofficu ve VB nedela (krome te obalky a to i tam to jsou jen nektere casti). Vsechno je psano v asm+C/C++ a to vypovida o tom, ze proste nejde napsat kvalitni produkt ve VB. Jde napsat libivou obalku, muze to i delat napr. to ze 1+1=2 a tim padem v tom muze byt nejake to ucetnictvi, ale NIKDY napr. v tom nebude psat skutecne narocnou aplikaci. A to nejen na vykon, ale i na moznosti, co tahle vec nabizi a na prumerne znalosti co ma vyvojar ve VB.

Proste je to jen smudlaci vec, co by mela brzy zmizet ze sveta, jako chyba MS. Jen to skodi produktum MS a to me vadi, ptz je pokladam v mnohych vecech za kvalitni. Ale VB je neco, co je proste zrudnost, ktera preziva jen diky tomu, ze ji muze pouzivat kdejaky klikac a jen se do programatorske obce dostavaji desny neumetelove.

Kecáte. Člověk, který tomu rozumí, to po přečtení vašeho příspěvku zřetelně vidí. A kdo tomu nerozumí, tomu to stejně nevysvětlím.

Nekecam, kecate vy. Kazdy ve vasich prispevcich muze videt typ fanatismu, ktery se snazi utlouct ostatni, kteri vidi neco jineho. Ale klidne si v tom zijte. Fanatismu zdar.

Je to možné, každý máme co zlepšovat.

Ehm, a co to jako je, tak uzasne slozita, bozska, komplexni, neprustrelna, megarychla aplikacka, co tam nekde za tech svych 130 kCZK smudlate? A jaky ze je duvod, proc by to neslo napsat na M$/VB platforme? Necham se rad poucit, par business aplikaci (podotykam newizardovacich, neklikacich atp.), mam uz za sebou..... Tak povidejte

V mem pripade se jedna o psani umele inteligence do prumyslovych robotu (konkretne jsou to systemy pro roboty Daewoo, ktere se pouzivaji pri vyrobe spotrebni elektroniky). Vyvoj je presunuty sem a je tu tym asi 30 lidi, co na tom delaji. Ja pracuji v robotice a umele inteligenci, jinak jsou zde i kolegove, co maji mnohem lepsi prijem (i nekolikanasobne vyssi) nez ja - a jsou to technici-programatori+hwerari.

.NET Visual Basic ma stejnou vyjadrovaci silu jako C# (dedicnost, vyjimky, thready,...). C# je velice blizko Jave. Navic se dost (i syntakticky) vzdalil od Visual Basicu z Visual Studia. Tyto dva jazyky jsou ekvivalentni, jde jen o sympatie. Myslim, ze by jsi se mel s tim co kritizujes nejprve alespon trosicku seznamit.

Sakra, Peter, tohle nepiš. Vypadáš jak blbec, a to hned třikrát:

- Veřejně jsi ukázal, že nevíš nic o VB. Teď zrovna děláme ve VB docela velký projekt, asi 100 000 řádek a žádné klikání (jde o serverovou aplikaci). Kdybychom to dělali v čemkoliv jiném, trvá to mnohem déle.

- Dále si veřejně ukázal, že nevíš, o čem dnešní programování je, tedy aspoň ty oblasti, kde se VB používá (hlavně business aplikace) - to není moc o optimalizaci, jenom trošku o matematickém zázemí, ale hlavně o datovém modelování, spolehlivosti, rychlosti vývoje a snadné údržbě

- A to pdoceňování lidí, které neznáš... Ve firmě máme 18 programátorů ve VB a každý z nich zná sakra hodně o optimalizaci, programovacich algoritmech, a ma znacne matematicke zazemi. S těmi nejlepšími zcela určitě prohraješ.

Ale jinak nic proti C++ nebo assembleru v robotice.

kdyz uz je ten VB tak senzacni, tak bych rad vedel, jestli na ty Vasi aplikaci (100000 radek) dela vsech tech 18 VB-programatoru nebo 3 ??. Potrebovali -by jste pro totez 36C++ programatoru ?? V jednom rozhovoru (16.06.95) se ptali pana Stroustrupa (C++) jestli je C++ vyhodnejsi nez ostatni jazyky. Odpovedel: jestlize mas 5 vyvojaru, kteri delaji v lispu, tak ten projekt delej v lispu!! Jestlize tedy mate VB-programatory - nu dobra - provedli jste kontrolu tim, ze na stejne uloze dela tym lidi napr. s C++, aby jste mohl o tom zvanit, ze VB je lepsi??

Super nápad!!!

Já osobně bych Petrovi doporučoval udělat na každý větší projekt šest týmů - assemblerovský, céčkovský, visual basicovský, javovský, perlovský a prologovský. Všichni by dělali přesně totéž. Současně by další tři týmy dělaly databázi současně v Oracle, MS SQL a mySQL. Pak by se vybrala nejlepší implementace aplikační vrstvy a nejlepší implementace databáze a zkombinovalo se by se to.

Dám si to patentovat a nazvu to Hyper Programming Invention Plus, zkráceně HP Invent +.

Juch, a svět programátorů již nikdy nebude jako dřív!

Ja chci Pascal a FoxPro! :)

trosku si odporujete. rikate, ze programovani dnesni programovani neni moc o optimalizaci (coz je uprimne nesmysl), ale hned v dalsim odstavci rikate, ze vasi programatori vi sakra hodne o optimalizaci.

ale k cemu jim to je??? krome toho, ze se podle vas optimalizace v programovani nepouziva, tak hlavne, jak pouzit optimalizaci ve VB??? ano jde to, ale dost spatne, protoze uz samotny interpetr VB je pomaly!!!

a programovaci algoritmy jsou taky hezka vec, ale vetsina z tech 'lepsich', ktere najdete pouze v odborne literature, je ve VB naprosto nepouzitelna, protoze VB je proste a jednoduse pomaly a 'nedostatecny' jazyk.

Hm, na této úrovni skutečně nemá smysl se bavit.

A: VB není pomalý a není to interpreter. Používá stejný generátor kódu jako Visual C++ a výsledný kód je vpodstatě stejně rychlý. 95% času stejně program stráví v systémových voláních nebo volání databáze, takže to není až tak důležité.

B: VB pracuje na rozdíl od C++ na logické úrovni COMu (volání COMu=volání funkce, v C++ to neplatí). To je jeho největší výhoda - v té oblasti, pro kterou je určen, samozřejmě

Petře, pozor, nepoužívá VB v COMu výhradně late-binding? (Nejsem si tím jistý.)

Pracovat s COMem je z VB skutečně daleko snazší, než z VC++, ale není to náhodou také výrazně pomalejší?

Samozřejmě je spousta věcí, které se v klasickém VB udělají obtížně, třeba free-threading tam nejde, a je to často velice užitečná věc. Ale ve VB.NET to už je v pohodě.

Ne. Pokud má VB referenci a proměnná je deklarovaná typem, ne jako Object (=IDispatch), používá samozřejmě early binding. U objektů deklarovaných jako Object používá late binding.

Scriptovací jazyky používají pouze late binding.

Aplikace napsané ve VB podle metodiky Microsoftu free threading nepotřebují, protože využívají MTS a COM+. Ale jak víme, Davide, podle této metodiky se nic trochu složitějšího napsat nedá.

Pokud se nepletu, VB je kompilovaný v posledních třech verzích, je to tak?

(Nevím to přesně, protože tehdy jsem dělal ve Visual C++ a vývoj VB jsem moc nesledoval.)

Myslim, ze pomerne dost dobre chapu tvuj problem. Ty jsi totiz vubec nepochopil k cemu je VB (a jemu podobne jazyky) urcen a jake jsou jeho vyhody/nevyhody. Precti si odpoved od Petra Palety at ti nemusim psat to samy.

velkou cast programu je proste nejefektivnejsi naklikat a VB se pro ne hodi

psat tyto programy v C/asm je asi stejny nesmysl jako psat drivery pro roboty ve VB

Vypada to zajimave, proto bych se chtel zeptat, kolik bude pokracovam? Jinak stazeni z MSDN slo rychle, cca 3minuty, prumerna rychlost prenosu 600kByte/sec.

Hoci podla mna je je dine spravne unix+apache+php+mysql , ocenujem tento clanok, je dobre vediet co sa deje na druhej strane, zda sa ze aj bill hybe rozumom, je to zaujimave, ale asp jednoducho nikdy nemoze  prekonat jednoduchost a krasu php kodu  a relativna stabilita apachu asi nikdy nebude prekonana absolutnou nestabilitou a deravostou iis

Apache, PHP, MySQL - jedine spravne????

No to jsem nejak nepochopil, jsi presvedcenej o tom, ze PHP je bezpecne a neprustrelne?

Rád bych ti řekl, že .NET se nedá porovnávat ani s ASP ani s PHP. Ne snad kvůli tomu že by byl tak fantastický ale kvůli tomu, že se jedná o něco ZCELA jiného... O naprosto jiný způsob myšlení při programování na internetu....

to jen tak okrajem....

unix... ok, ale apache+php+mysql je pekne zastarala technologia v porovnani z .NET

Skoda ze autor clanku najskor neukazal moznosti .NET ako celku a nenapisal co to prinesie. Urcite by viacerym ludom aj tuto radovi svitlo v hlave.

Ale aj bez toho... doteraz sa porovnavali klasicke aspcka z phpckom a bol to nerovny boj, jedno bolo lepsie vtom, druhe v onom. Ale kazdy co vie o com je rec uz nemoze porovnavat php z asp.net lebo to je uz uplne ina podstatne vyssia kategoria. Ako keby ste chceli porovnavat trabanta z bmw

Rozhodně bych neporovnával ASP.NET a PHP, spíš ASP:NET a servlety/JSP. Jinak byste došel k porovnávání procedurálního a objektového programování.

Myslím, že ASP.NET v některých ohledech teprve dohání náskok JSP + JB + J2EE 1.3. Ono je to nastřídačku, před J2EE měl např. díky transakčnímu serveru výrazný náskok MS.

Teď je MS zase vepředu, myslím docela výrazně.

Ovšem chce to nejmíň rok, než se .NET pořádně prověří a ověří.

ak je asp.net "vyrazne" vpredu pred J2EE 1.3, su sucastou asp.net, resp.net aj veci ako messaging (a~la JMS, prip. je mozne objekty v trans.servri kombinovat s messagingom - a~la message-driven EJBs), dalej distribuovane transakcie, dvojfazovy commit transakcii, nejaka obdoba J.Connector Architecture a pod. ??? A co napr. taka podpora web-services, uz MS zvlada SOAP ktory sa dorozumie aj s ne-MS okolim ? :)

.NET stavi na COM+ services, ktere velice uspesne implementuji distribuovany messaging, distribuovane transakce, dvojfazovy commit... o web services ani nemluve! Marketing .NET je vlastne cely postaveny na "web sevices". SOAP zvlada, dokonce sme implementovali SOAP komunikaci mezi Tomcatem a IIS/.NET. Svete div se, fungovalo to!

Proste Microsoft, se zda, vykrocil tim spravnym smerem - viz dalsi aktivity jako standardizace .NET CLI a C#.

F.

tak potom OK ! :)
co sa Soapu tyka, tak reagujem len na to, co som kdesi cital o nekompatibilnych MS rozsireniach Soapu v BizTalku a pod.

Co se tyce BizTalku a Microsoftich rozsireni SOAPu, tak to neni uplne az tak nepravda. Kazdopadne, se to da bez problemu rozchodit, jak rikam, Tomcat a IIS se ani moc nepohadali.

F.

Pozor, tak to není. Souhlasím s tím, že COM+ je relativně dobrý soubor služeb. Je to dokonce asi tak, že .NET vznikl z toho, co měl být původně COM+ 2.0.

ALE: .NET není COM a nestaví na COMu. Je to zcela nezávislá a nová věc. Téměř všechno, co umí COM, je v .NET naprogramováno od základů znovu (a samozřejmě spousta věcí navíc).

.NET je pouze s COM+ skvěle kompatibilní. Taky C# je s COM+ skvěle kompatibilní. MS to zpočátku tak zdůrazňoval, až někteří získali dojem, C# je použitelný pouze s COMem. Ale není to tak - .NET (a tedy i C#) je na COMu naprosto nezávislý a má COM postupně nahradit.

btw. ked uz sme pri COM+ a podobnych zalezitostiach.. zvlada uz .NET (ak teda vie vsetko co COM+ a viac) aj veci ako automaticku persistenciu obejktov (a la container managed persistence v Jave ?) ? a co "stateful" komponenty ? Este stale nasadit komponent v appl.servri znamena zapisovat do globalneho OS registru (! - este k tomu s nazvami na sposob 0x18F4F25E5C002E75BA420001FE63C218) a restartovat server ? (aspon toto posledne uz v .net neplati, ze ??). Btw. existuju vlastne na trhu produkty typu aplikacny server pre COM/COM+ alebo .Net ? (mam na mysli samostatne, prip. MS-nezavisle produkty - tj. ci je nejaka moznost volby apl.servra ? - mari sa mi, ze som nieco pocul o Sybase(??))

Persistence objektů: .NET persistenci objektů umí, ale jestli je to jako v Javě, to nevím.

Stateful compomenty: Nápodobně. Nevím, co přesně tím myslíte, ale "nějak" to .NET umí.

Deployment komponenty: Komponentu v .NET instalujete stejně jako stránku v ASP.NET, tj. zkopírujete ji do adresáře aplikace a je to. Můžete přitom taky klidně přemazat starou verzi, v takovém případě běžící procesy nadále pracují se starou verzí komponenty, ale nové už pracují s novou. A jakmile ty staré doběhnou, je stará verze odstraněna z paměti a je fuč.

Aplikační servery pro .NET: Samotné jádro .NET je aplikačním serverem. Na windows se AS nikdy moc neprosadily, protože samotný OS zajišťuje většinu služeb, které na jiných platformách musí poskytovat AS. Pokud potřebujete dělat v Javě, potřebujete na Windows AS, ale pokud děláte v COM+, AS de facto nepotřebujete. (Resp. na něco ano, ale dá vám to jenom malou hodnotu navíc a za ty peníze to většinou nestojí.)

ad Persistence objektů:
tak som sa na to medzitym zbezne pozeral - a nenasiel som nic o tom, ze by .net vedel automaticku persistenciu objektov (cize - instancia komponentu automaticky (app.serverom) ukladana (obvykle DB server) t.j. bez programoveho riesenia persistencie v komponente (persistencia sa riesi na urovni konfiguracie app.servera). Cize celkom skvela vec, ktora umoznuje velku flexibilitu vo vybere "perzistujuceho" (fuj:) servra (tj. databazy).
Nasiel som ale par komentarov o tom, ze prave toto .net nevie...

ad Stateful compomenty:
Myslel som na podporu pre komponenty, udrzujuce status (obykle pocas trvania session) - t.j. kazdemu pristupujucemu spojeniu zodpoveda (zjednodusene) jedna instancia. Cize nieco ako Statefull Session EJB v J2EE.
ad Deployment komponenty:
Fajn, tomu hovorim pokrok :) (Java app.servre (vacsina) funguju podobne uz davno)

ad Aplikační servery pro .NET
to je prave to, ze na srandicky je MS app-server dodavany s OS (COM+, .Net) urcite dostacujuci (a samozrejme obykle lacnejsi nez top app.servre) - ale otazke bola, ci dokaze nahradit aj konkurenciu (ktora vraj vsetko kopiruje od MS :)) - a mne to zatial tak nepripada :) Btw. otazka ceny je tiez dost nepodstatna, napr. JBOSS (open-source J2EE aplikacny server) poskytuje to, co .Net ako aplikacny server (a viac (messaging, persistence..)) celkom zadarmo :)

Teď s vámi budu souhlasit: Pořádný aplikační server skutečně COM+ ještě pořád nemá a že to je potřeba! Uznal to i MS, když uvedl produkty App Server, Operation Manager... nechápu, proč je to několik produktů a ne jeden!!!

Ale to, co dělají javovské AS jako SilverStream, BEA nebo Oracle AS, skutečně do značné míry ve Windows už máte v ceně. Ale chybí tomu těch pár detailů, které z toho celého dělají dobře spravovatelný celek a to je DOST VELKÝ průšvih.

Persistence objektů v DB na úrovni konfigurace - to opravdu vypadá jako zajímavá vlastnost a nevím o tom, že by to .NET umožňoval, ale nejsem si jist, moc dobře ho neznám.

Statefull objekty - začínám to chápat. Nevím, jestli to .NET umí, nikdy jsem neslyšel, že by to uměl. V COMu se to dá ošidit. Ale ono právě jde o to, nemuset to šidit, že...

ALE: .NET není COM a nestaví na COMu. Je to zcela nezávislá a nová věc. Téměř všechno, co umí COM, je v .NET naprogramováno od základů znovu (a samozřejmě spousta věcí navíc).

Ano .NET neni COM ale momentalni Microsofti implementace stavi na Windows API. No a Windows API je uz prospikovane COM jako cednik a mnohe COM interfaci se vlastne povazuji za native Windows API. Na venek to sice neni videt, ale .NET je tezde zavisly na COM/COM+! Jen se podivejte do import tabulek .NET dll knihoven!

.NET je pouze s COM+ skvěle kompatibilní. Taky C# je s COM+ skvěle kompatibilní. MS to zpočátku tak zdůrazňoval, až někteří získali dojem, C# je použitelný pouze s COMem. Ale není to tak - .NET (a tedy i C#) je na COMu naprosto nezávislý a má COM postupně nahradit.

Jiste, ze je .NET skvele kompatibilni s COM+ kdyz vlastne COM+ pouziva! .NET neni na COM nezavisly, jen uzivatel .NET je odstinen od COM a tedy "nezavisly na COM". Ale to, ze by .NET reimplementoval temer vsechno, co umi COM je holy nesmysl! Vzdyt to ani nedava smysl! Proc bych reimplementoval neco, co je osvedcene, odzkousene a funguje?

F.

Většinu těchto věcí Sun okopíroval od MS, MS je uměl o několik let dřív (viz MS Message Queue, MS Transaction Server a integrace obojího v COM+, třeba message-driven EJB jsou přesně kopií COM+). Windows je dnes silná platforma, která spoustu těchto věcí podporuje standardně.

.NET samozřejmě může využívat služeb COM+ a platformy Windows. Třeba messaging podle mého názoru není v .NET ještě nativně implementován, ale na platformě Windows samozřejmě každý programátor zcela intuitivně použije existující služby systému. .NET platforma se službami Windows výborně komunikuje.

Pokud jde o SOAP - Microsoft SOAP vymyslel. Člověk, který SOAP vymyslel, skutečně pracuje v MS.

S tim vymyslenim SOAP od MS bych trosku pribrzdil :)

Ve standardizacni komisi je MS, IBM, DON BOX a dalsi. Don Box spoluvlastni Californskou firmu Developmentor, ktera dela mj. jedny z nejlepsich a taky nejdrazsich skoleni pro vyvojare. Spousta zamestnancu teto firmy je podepsano pod nekolika standardy z oblasti XML.

A teprve nedavno se Don Box stal zamestnancem MS :)

SOAP nevymyslel Don Box, ale někdo jiný, to jméno si nepamatuji, jinak bych ho tady uvedl.

Dona Boxe znám, dost věcí jsem od něho četl a byl jsem na jeho přednáškách v Praze a v Barceloně. Zvláště půvabné bylo, jak vysvětloval, proč je C# lepší, než Java. )

Don Box pracuje na jádru .NET. Má vizi, že procedurální jazyky jsou mrtvé a nahradí je transformační servery ve stylu XSLT, ale podle mne je to blbost. Boj proti procedurálním jazykům vedl už Prolog a pohořel. Myslím, že lidé prstě uvažují procedurálně a chtějí uvažovat procedurálně.

Nevim jestli ten clovek z MS neni Jonathan Marsh? Ale ted si opravdu nejsem moc jist. Na strankach W3C se mi uz nepovedlo najit "zakladajici dokument SOAPu".

dobre, ale messaging ani transakcny server samozrejme nevynasiel MS. ani tomu, ze by message-driven EJB boli "presnou" kopiou COM+ moc neverim (ale fakt je, ze COM+ az natolko nepoznam...). Reci typu "Windows je dnes silná platforma" su sice pekne, ale zostava tu stale problem prave samotnej platformy - tj. obmedzenost MS technologii na vlastne produkty a platformu (jasne, uz pocujem, ze je tu SOAP a pod...ten to vytrhne :) - btw. SOAP nevymyslel MS (ale o to tu nejde)) - proste pri velkych heterogennych rieseniach je nepostatne, ci bol MS prvy alebo druhy, ale to ci nejaky konkretny produkt/server splnuje nejake konkretne poziadavky (robustnost, stabilita, moznost behu na silnych unixoch a pod.) - napr.(ked uz sme pri tom messagingu) ci je MS Message Queue robustnejsi a stabilnejsi system ako napr. IBM MQ Series (mam taky pocit, ze produkt MS lepsi nebude :). Proste v tejto oblasti je moznost volby (najvhodnejsieho produktu) a pokial mozno aj nezavislost na jednom vyrobcovi velmi dolezita - a prave preto sa imho MS asi v tejto oblasti stale vyraznejsie chytat nebude :)

Ale já s vámi souhlasím, že tyhle věci jakožto základní ideje nevymyslel MS! Nevymyslel! Tak jako Apple nevymyslel myš, Netscape nevymyslel internetový browser, Sun nevymyslel garbage collector ani hardwarově nezávislý interpretr...

To jsou všechno původně velmi staré akademické ideje. Samozřejmě. Samozřejmě. Samozřejmě.

Nezávislost na jednom výrobci opravdu je relativně důležitá. Relativně. Možná, že když všechno děláte na Wintelu, jste k té platformě připoutáni hodně, kdežto když to děláte na kombinaci Java + AS od BEA + DB od Oracle + HW od Sunu, jste naprosto svobodný. Ale opravdu je to tak?

vtip je prave v tom, ze ak robite v Jave, tak prave na kombinacii AS od BEA + DB od Oracle + HW od Sunu zavisli NIE STE ! :)

Tož to nevím. Fakt na tom nejste závislý, nebo to spíš jenom tvrdí marketing těch firem?

Tak třeba zrovna včera jsem četl v aktuálním čísle časopisu Oracle, že když děláte složené indexy v Oracle 9i, je v některých případech dobré dávat nejméně selektivní sloupec tabulky jako první. Díky skippingu a kompresi indexů to totiž může vést ke zvýšení výkonu.

Ale kdybyste totéž udělali na Oracle 8i, bude výkon slabý. A takový MS SQL Server by - hádejte co - by takový index nejspíš vůbec nikdy nepoužil. Protože obecná databázová metodika samozřejmě velí dávat na první místo vždy nejvíce selektivní pole.

Na většině databází je totiž index obsahující třeba pohlaví (dvě hodnoty - Male/Female) úplně k ničemu a neměl by se vytvářet. Jeho použití vede ke zhoršení výkonu. Index Scan Skipping u Oracle 9i (a jenom u verze 9i) s tím naopak umí skvěle pracovat.

Tak co na to řeknete? Že je to detail?

A víte třeba to, že u Oracle 8i uložené procedury podporovaly jinou verzi jazyka SQL, než když jste přímo zadal SQL dotaz? Ano, Oracle měl do verze 8i DVA parsery SQL. Ne zcela kompatibilní. Sranda, co?

Ať žije kompatibilita.

Tak o jaké

hmm, zaujimave, tu sa clovek aj nieco uzitocneho dozvie...:)
inak, napisal som, ze to ide aj bez Oraclu a vy mi na to odpisete studiu o nekompatibiltach DB servrov..:) Ale inak s tym, ze si kazdy vyrobca robi veci po svojom len preto, aby priviazal zakaznikov k vlastnym rieseniam, my tu asi nic nezrobime :) Ide skor o to volit technologie (ak je ta moznost), ktore umoznia tieto problemy so najviac eliminovat...

Naprosto souhlasím!!!

Ale ale, to bych se podivil! Ono to nebude zas az tak cernobile jak se na prvni pohled zda! Vetsina AS jsou mezi sebou nekompatibilni! Ano ano, existuji sice standarty, jenomze kdyz to vezmeme do dusledku, na kazdem AS existuje spoustu extensions. Proc asi? Aby ulehcily vyvojari zivot? Nemyslim! Hlavne proto aby si baca vyrobce rozmazlil a ochocil svoje ovecky, presne tak jak to dela Microsoft.
Uz jen kdyz povazime CORBAu. Moc bych se divil kdybyste nasel dve 100% kompatibilni implementace.

F.

Zdravicko,

Fakt zaujimavy clanok a ak by prave nebolo 2:42 = cas ist do postele, urcite by som ho docital :)

Nemuzu si pomoct ale visual studio vypada vzdycky jako Delphi o 2 verze zpatky.

Honziku... asi si s novym Visual studiom este nepracoval vsak? priznaj sa

Honzíku,
to je zajímavé, já jsem mě podobný pocit když jsem nedávno zkusil Delphi - jako kdybych najednou pracoval
s Visual Studiem 5, možná i 4. A dokonce mi více připomínalo VB než C, což je trochu škoda...

škoda je, že ti to nepřipomíná packal

ale samozřejmě, vidím v tom paskal, ale já myslel spíš chování programu (ne zápis) a výsledného kódu (hlavně ta velikost, uff - měl jsem přitom vypnuté všechny debug-součásti), to jsem asi neuvedl dost jasně...

Rád bych řekl, že ačkoliv jsem naprostý příznivec vývojového prostředí od Borlandu, nové Visual Studio se mi docela líbí... Snad už proto, že je dílkem vývojářů Delphi, které Microsoft koupil....

čauky tom

Ja som tiez zastanca Borlandu a c++, pretoze doteraz ak som skusil Visual C 5ku alebo 6ku, tak to sa neda porovnat s RAD Buildera... dufam, ze nove visual studio uz ma RAD aj v C++!! (a nie iba v basicu a podobnych somarinach... )

Prosiiiiiiiim neprekladat veci jako inheritance, exception handling, language, structure, event, whatever.... diky!

Krasty:
Na diskusnim forumu cestina-na-netu@pandora.cz najdes jiste dalsi prispevky na dane tema. Ano ano, pocitac neni computer a vubec.

"A prosim lidi, v mejlech zasadne posilejte hačkz, nedá se to pak číst a je to DESNE zabavny."

Ja sem uz teda neco anglicky i cesky psal a tohle co tu zminujes je stejne neresitelny. Neco proste neprelozis.

Konec threadu.

dedicnost, osetreni vyjimek, jazyk, struktura, udalost, cokoliv... jsou krasna ceska slova a daji se docela dobre pouzivat :o)))

Ať to přeloží:
inheritance=dědičnost
exception handling=zpracování výjimek (nikoliv obsluha)
language=jazyk
event=událost
whatever=atd.
Spíš jsem zvědavý na garbage collector (správce volné paměti?) a delegate (zástupce?)

nojo, jenomze pak ten dotycnej zahlasi v nejakym development teamu, ze ma trebas bezvadnou metodu na "zpracovani vyjimek" a nasledne mu nikdo nebude rozumet. Anebo vy vsichni ctete MSDN v cestine?

Chcel by som podotknut, ze ludia, ktori citali o niecom vo svojom rodnom jazyku a poznaju aj anglicku terminologiu, su zvyknuti na preklad anglickej terminologie do rodneho jazyka a neposobi to na nich "nepresne" alebo "smiesne". Ale ti, ktori zacali s anglickymi vyrazmi, mnohe vyrazy im mozu pripadat smiesne (napr. explorer=prieskumnik). Niektore dokonca neprelozitelne. Napr. garbage collector je naozaj neprelozitelny termin, pretoze v beznej anglictine sa vobec nevyskytuje a anglicky hovoriaci programatori si ho skrotili (cesky: ochocili) - pripisali mu novy vyznam, ktory len z dialky pripomina povodny nazov. Ja by som garbage collector prelozil ako "upratovacka" (cesky: uklizecka) a po istom case by to bolo podobne zauzivane ako sucasne pouzivany termin "prislusenstvo" (ako preklad z "accessory", co je v podstate dosahovac (nejakeho ciela)(opravte ma, ak sa mylim)).

Ale vzdyt je to jasny garbage collector se cesky rekne: duchodce.

DOOOOST dobry..

whatever = atd.? ne, dik.

Uz i plno nasich serveru nabizi .NET hosting . Za vsechny napr. Czechie

anonym se stydi, ja ne.

http://pro.mujweb.cz je .NET hosting 1 mesic zadara, za urcitych podminek i dele. Samozrejme na ostrem .NET Frameworku.

Pane Blaha, vyuzivam Vasi pritomnosti zde a chtel bych Vam verejne podekovat za ty GB porna, co se daji stahovat  z Mujwebu. Dekuji.

Ctete archiv NetMagu 1996-2000, pres 1000 clanku on-line !