79 komentářů k článku Jak budeme psát webové aplikace za tři roky?:

  1. balki

    Good enough

    S clankom suhlasim, je to asi prvy raz, co pan maly napisal nieco rozumne. Cloveko-hodiny su drahe, to si casto hackeri neuvedomuju.

    Ale bohuzial, tie nastroje nie su este stale vseliekom. Robil som s RichFaces v Jave. Vacsinou vyvoj aplikacii urychlia, ale stava sa, ze nefunguju tak, ako by sa od nich ocakavalo. Aplikacia je hotova skoro hned a vacsinu casu potom zaberie chytanie bugov. Potom prijde na rad vrtanie sa v css, javascripte a html, ladenie na kazdy browser extea atd…

    Aby som to zhrnul – „good enough“ je spravna cesta, ale „koderina“ aj tak nevymrie.

    1. blizzboz

      Re: Good enough

      V ideálnom svete je HTML / CSS je záležitosť tvorcu šablóny frontendu aplikácie. Programátor vytvára logiku aplikácie, a to či aplikácia bude komunikovať s užívateľom cez webové rozhranie alebo cez nejaký desktopový frontend, programátora viacmenej trápiť nemusí.

      Inak za ten odkaz na CoffeeScript vyzerá to zaujímavo. Ja na JS používam toto: http://projects.nikhilk.net/ScriptSharp

      1. balki

        Re: Good enough

        V javaserver faces (resp. richfaces), o ktorych som pisal sa prezentacna vrstva vytvara ako sablona. Ale v tejto sablone sa nepouzivaju html tagy, ale komponenty javaserver faces. O nizkourovnove zalezitosti, ako je session, ajax, rendrovanie html sa stara samotny framework. Spravanie sa vyslednej aplikacie sa ovela viac podoba potom desktopovej. Aj kodenie sa potom daleko viac podoba kodeniu desktopovej aplikacie.

        Teoreticky by v jsf malo byt mozne napisat tu istu sablonu aj pre rendrovanie na web, aj na generovanie gui desktopovej aplikacie. Ale este som nikoho nevidel, ze by to robil.(Bol by to na desktopove aplikacie overkill).

        Nevyhodou jsf je, ze zdrojovy kod vygenerovanej stranky je velmi skaredy, volnym okom bez nastrojov typu firebug necitatelny. A ani generovany javascript by som si do vitriny nevystavil.

        V idealnom svete by to fungovalo na 100%, stare verzie prehliadacov by sa nepouzivali a tie nove by standardy implementovali vsetky uplne rovnako.

    2. Biktop

      Re: Good enough

      „Cloveko-hodiny su drahe“ – to si uvědomí každý blbec. Ale málokdo si už uvědomuje, že výtvor, který se má prakticky používat, bude velmi pravděpodobně nutné také udržovat – třeba 5-10 let. A že každá člověkohodina nevhodně ušetřená během jednoho roku vývoje se mi několikrát připomene během následujících 10 let, kdy bude třeba něco dodělat, předělat, opravit, ale protože jsem to tenkrát „nějak“ zbastlil aby to bylo „good enough“, tak se s tím teď budu muset s..t několikrát déle a tedy dráže. Až se to dostane do stavu, kdy je to nadále neudržovatelné a je třeba to udělat zgruntu nové – tomu říkám ekonomické řešení… :-) Zvlášť když si pro tuto zakázku objednatel vybere třeba úplně jiného dodavatele. Není nad rozumy lidí z marketingu – kterým dělá nepřekonatelné problémy pochopit, jak to ten šachista dělá, že ví dopředu, co udělá protihráč, a plánování do budoucna je pro ně nějaké sprosté slovo snad z dob reálného socialismu…

          1. balki

            Re: Good enough

            Lepsie dodat good enough a nacas a postupne refaktorovat kod podla poziadaviek, ako si robit nadpracu ,predpokladat „co keby“ a dodat miesto mikrovlnky jadrovu elektraren.

            Refaktoring je seriozna cinnost, to nie je bastlenie len tak mirnix-dirnix.

            1. Biktop

              Re: Good enough

              „Lepsie dodat good enough ako si robit nadpracu ,predpokladat „co keby“ a dodat miesto mikrovlnky jadrovu elektraren.“ – to je 100% pravda!
              „Lepsie dodat good enough a nacas a postupne refaktorovat kod podla poziadaviek“ – to už je pitomost.

              Potřeba refaktorace je příznakem, že jste si někde v návrhu přimyslel omezení, která nijak neplynou ze zadání – tedy jste si zbytečně a nechtěně zkomplikoval práci. ;-)

              1. Satai

                Re: Good enough

                Refaktoring = zmena struktury kodu bez zmeny jeho funkcnosti. Pokud by si nekdo primyslel omezeni, tak by zmena struktury nepomohla.

                Ja bych to tak neprozival. Refaktoring je proste symptom toho, ze neumime byt perfektni napoprve. Nekdy staci udelat male refaktoringy hned po dopsani kodu (typicky prejmenovani promene, vyjmuti kodu do metody a podobne drobnosti), jindy potrebuje kod trochu (nebo trochu vic) ulezet, aby se prislo na to, ze tady se bude hodit visitor a tamhle je potreba zavest factory. Ze refactorujete az po delsi dobe neni symbol selhani, je to projev toho, ze uz vite neco navic o svem kodu.

                1. v6ak

                  Re: Good enough

                  Někdy je navíc dost těžké být perfektní napoprvé. K jednomu projektu jsem se dostal s úkolem to dokončit co nejméně po termínu (předchozí programátor to nezvládal a utekl). To je přímo učebnicová ukázka. Ano, mnohé by určitě šlo napsat lépe. (V některých případech jsem to tak později přepisoval.) Ale kdy bych to pak odevzdal? To byl typický příklad „Napiš funkční kód a až později z něj udějel dobrý kód.“, místy dokonce „a později ho zahoď a napiš to pořádně“.

            2. Aleš Roubíček

              Re: Good enough

              Jenže správný okamžik na refactoring je jakmile dopíšete kousek kódu. Ne až v budoucnosti. Hned. Protože v budoucnosti už se do hnoje nikdo chtít ponořovat nebude. A když bude muset bude hodně drahý.

      1. Zilogat0r

        Re: Good enough

        Moudre pravis, 251, 201. S IT to pujde od 1010 k 0101 tim rychleji, cim vice do toho budou lide z marketingu kecat sva clovekomesicni a mandayova moudra. Aneb duchaprazxdne empiricke poucky, casove omezene, s nulovym vhledem do toho, jak to funguje, a co je vlastne nutno udelat, aby to fungovalo. Protoze o to tu jde predevsim.

        1. bauglir

          Re: Good enough

          Takovéhle IT je fajn…. na škole… V praxi k ničemu. Představa, že programátoři ví, co zákazník potřebuje, že ví, jak produkt nabízet, jak produkt prodávat je naivní… Produkt je potřeba prodat, protože když né, můžete si ho strčit pod kámen (nebudete mít ani na ten šuplík).
          Nechápu bitvu mezi programátory a marketingem… jde jenom o ego a představu, že jedna strana je více, než druhá.

          1. Zilogat0r

            Re: Good enough

            Stale jsem presvedcen, ze prograqm by mel predevsim fungovat. Teprve az pak se prodavat. A casto se zjisti, ze kdyz je zdarma, je lidstvu k jeste vetsimu uzitku.

      2. bpbp

        Re: Good enough

        Martin Maly pise o koncept good enough jako o ekonomicke zralosti technologie tak aby zapouzdrila jine.

        Problem udrzby aplikaci tu zustava, ale je to jina uroven debaty.
        A zejmena u webovych aplikaci jde o trh, kde technologie zastaravaji pred ocima.

        1. František Kučera

          Re: Good enough

          Rozlišoval bych mezi webovými aplikacemi a webovými prezentacemi – ty prezentace je většinou* lepší po čase zahodit a udělat znova, ale u aplikací to tak neplatí. Když je dobře navržená a dobře vrstvená, není problém vyměnit jen některé vrstvy (prezentační vrstva, xicht, který vidí uživatel) a zbytek zachovat a jen rozšířit na základě nových požadavků (datový model, aplikační logika).

          *) i když taky to nemusí platit vždy – můžu mít třeba web postavený na Drupalu a v rámci redesignu si jen pořídím novou šablonu a přeuspořádám strukturu. Upgrade na novou verzi systému se taky dá běžně zvládnout – to neberu jako zahození všeho a stavění znova.

  2. Voy

    Je tohle skutečně třeba?

    V některých věcech s autorem souhlasím, jiné se mi zdají jako divoké spekulace. Např. nemám pocit, že by některá ze zmiňovaných technologií získávala zásadní pozornost vývojářské komunity – OpenLaszlo, GWT či třeba Pyjamas. Buď ještě nejsou v dostatečně použitelném stavu nebo to je prostě slepá cesta. Ale to vem čert.

    Zastavil bych se u tónu jakým je článek napsaný. Neustále navážení se do publika Zdrojáku, různé poznámky o soudných čtenářích a v protikladu stojících magorech posedlých validitou (znáte nějaké?). Nevím jak vám, ale přijde mi to zcela zbytečné. Pochopil bych to někde na blogu Radka Hulána, ale tady dostávám pocit, že autor má nějaký mindrák, který si takto pravidelně léčí (ostatně viz i twitter účet @adent). Prosím, zkuste to v sobě tlumit.

    1. Blossom

      Re: Je tohle skutečně třeba?

      Precti si diskuse a uvidis za jake kraviny se tu topi na lzici vody. nevim jestli to je nutne nebo omluvitelne, ale je to pochopitelne.

    2. Martin MalýAutor příspěvku

      Re: Je tohle skutečně třeba?

      Máte pravdu, příteli. Zapomněl jsem na to, pro koho píšu, a text jsem raději upravil. Omlouvám se.

    3. kert

      Re: Je tohle skutečně třeba?

      ad GWT: je zcela použitelné a určitě ne slepá cesta. Pokud vyvíjíte RIA web aplikaci (reusable ui komponenty, interaktivita, dialogy, wizardy, spousta javascriptu a ajaxu) a Java pro vás není sprosté slovo, pak GWT je možná nejlepší volba. Včetně výborného debug módu.

  3. mikiqex

    Stále totéž

    Pokud sleduji vývoj, za posledních několik let se vylepšila především prezentační stránka. Stínování, animace pomocí JS (s vytlačením animovaných GIFů) atd. Nicméně vývoj PHP a MySQL nejde dostatečně kupředu, abych si mohl myslet, že za dva, tři roky tomu bude jinak. Šablonovací systémy a abstrakci kódu jsem řešil již někdy před osmi, devíti lety.

    1. Jiří Kosek

      Re: Stále totéž

      Ale on vývoj PHP a MySQL nemusí jít dopředu. Stačí udělat nějakou „good enough“ nadstavbu, která na základě nějakého popisu na vyšší úrovni nebo klikátka vygeneruje tuny PHP kódu, které „vývojář“ nikdy neuvidí.

      U klientských skriptů je tohle teď zcela běžně, na serveru zatím tokolik ne, ale to se (bohužel?) asi opravdu brzy změní.

      1. mikiqex

        Re: Stále totéž

        Jde mi hlavně o Unicode jádro PHP a o podporu oddělení databázové logiky od kódu v MySQL. Nemyslím si, že překládání mnoha tisíců řádků nějakého frameworku při každém spuštění skriptu i na Hello World je optimální řešení. U kompilovaných jazyků to zas takový problém není, ale zrovna u PHP to ve finále může být problém. Dalo by se to řešit selektivními frameworky, které by si pro produkční nasazení zjistily, co vše potřebují (a jak) a podle toho upravily volání příslušných knihoven.

        1. v6ak

          Re: Stále totéž

          Částečně ten problém v PHP lze řešit pomocí různých cache a optimalizátorů, ale není to nejlepší. On je tu problém i s životním cyklem aplikace (vytvořit prostředí, zpracovat jeden požadavek a zahodit). Ale v jednovláknovém PHP to asi moc lépe nepůjde.

        2. Josef Richter

          Re: Stále totéž

          Zaujala mě poznámka „Nicméně vývoj PHP a MySQL nejde dostatečně kupředu“ – PHP možná ne, ale ostatních jazyků a jejich frameworků rozhodně jo – chce to dívat se víc kolem sebe. Přece web aplikace nejsou jen zdaleka PHP.

          A s tím MySQL – pokud myslíš tu jednu konkrétní firmu a její databázi, tak máš možná pravdu, ale zrovna na poli databází poslední dobou probíhá bouřlivá revoluce (jestli správným směrem, to si netroufám hodnotit). Vyskakuje nám tady tolik nových a zajímavých databází, že to člověk nestíhá sledovat. Namátkou redis, tokyo, voldermort, riak, couchdb, mongodb, memcachedb, cassandra, neo4j, orientdb a ještě asi milion dalších. A nevznikají jen tak ze srandy, ale protože řeší reálné potřeby webu a mobilních zařízení.

        3. Jiří Kosek

          Re: Stále totéž

          Pokud bude výkon problém, tak se vyřeší na jiné vrstvě. Už deset let pro PHP existují různé cache a akcelerátory, Facebook udělal kompilátor PHP do nativního kódu. Je snažší, když pár vývojářů napíše dobrý kompilátor PHP, než naučit desetitisíce vývojářů psát přehledný a efektivní kód v PHP.

          1. František Kučera

            Re: Stále totéž

            To je sice pravda, ale pomalost aplikací často není důsledkem pomalosti jazyka/platformy, ale špatného návrhu (dělají se zbytečné úkony, transformace, načítají se zbytečná data, aby se vzápětí zahodila atd…) a to kompilace do nativního kódu nespraví.

      2. Pavel

        Re: Stále totéž

        Řešit to nadstavbou je nesmysl, tím se všechno jen zpomalí a až začne zase kód bobtnat tak se to vyřeší nadstavbou nadstavby? Řešením je jedině psát co nejjednodušší a nejpřehlednější kód bez zbytečností.

  4. ra.ri.ta

    mimo terč

    Mám obavy, že autor je tak trochu dost mimo. Ono by to bylo krásné, ale! WEB 2,0 se jaksi vytratil a už je tu WEB3,0. Musíme připustit, že nevnikne nic, co běžný občan, tedy dav nepřijme. Neodvedu si dost dobře představit, že někdy někdo přijde a řekne, ZDROJAK uděláme novou technologií. Sice výsledek bude stejný, ale efektivněji udělaný.

    Člověk má omezené schopnosti a potřeby, a ty jaksi jdou mimo přání tvůrců.

    Uzavřu toto následovně:
    Kdo má nadbytek peněz a času, a potrpí si na problémy, zvolí asp.net.
    Kdo má nadbytek méně peněz a času, a potrpí si na problémy, zvolí OOP PHP.
    Kdo se uvedené nesnáší, volí procedurální PHP.

    K tomuto závěru po čase většina těch, co to platí, stejně dojde.

    1. Josef Richter

      Re: mimo terč

      Co si představuješ pod Web 2.0 a Web 3.0? Já bych řek, že to je jen novinářský škatulkování, který zas nemá až takovej význam ;-)

      Ad „výsledek bude stejný, ale efektivněji udělaný“ – tohle se přece děje docela běžně. Běžně někdo zmigruje blbej blog z Joomly na WordPress, protože už mu Joomla nestačila, ale na front-endu změnu nepoznáš. Nebo třeba Twitter a Facebook, který se vnitřně překopaly od hlavy až k patě, přestože z pohledu uživatele je to pořád stejná služba (když nepočítám poslední redesign twitteru). Ale nedělá se to ze srandy, ale protože těch dat bylo tolik, že to museli nějak řešit.

  5. chleba

    webmasterina nevymre

    Dokud tady mame x.ruznejch prohlizecu tak bude koderina potrebna spolecne se specifickejma grafickejma navrhama ktery by ruzny prekladace nebo nadstavby jen tak neudelali nebo udelali ale zase se zbytecnejma obrazkama nebo dalsima vecma.

    To samy nevim jak by fungovaly takovy mapy v prohlizeci napsany skrz nejakej takovej program jako Cappucino. S prichodem HTML5 bude javascript jeste vice potrebnej pro ovladaci prvky audio a video tagu + canvas.

    Jenze mozna se mi tento pohled mlzi ciste na specificky zalezitosti a v clanku je to mysleno na male projektiky typu web pro Frantu coz samozrejme v takovym pripade usetri vyvojari milion hodin prace a hlavne stresu.

    Podle me je absolutni nadsazka rict ze do dvou let koderina nebude potreba.

    1. David

      Re: webmasterina nevymre

      To je právě otázka – samozřejmě nejlepší je, když si každý design ručně převedu a zminimalizuju, tak, aby tam pro jiné prohlížeče bylo to opravdu jediné potřebné. Na druhou stranu už dnes existují knihovny, které emulují chování moderních prohlížečů na starých prohlížečích a se zvětšující se rychlostí internetu, více datech na proxy serverech a v cachích už to není zas tak palčivý problém. Dneska třeba ještě může být, ale zítra už vůbec. Pak může být aplikace postavena na základu, který se zobrazí dobře všude a případné lepší fičury nechat jenom pro moderní prohlížeče, kterých je většina. Pokud to tak není, a chceme zajistit stejnou funkčnost i pro staré prohlížeče, tak můžeme buďto sáhnout po knihovnách, a nebo dodatečně nakódovat něco ručně – ale už je to jenom dodatečná, vedlejší a detailní záležitost v případě, že se to vyplatí, ne mainstream.

      Specifikovat to přesně v letech je opravdu nebezpečné, ale stejně tak je nebezpečné tvrdit, že se to nestane jenom protože je tu x prohlížečů. S tím si vývoj už nějak poradí. Zbytečné věci, které jsou tam navíc, jsou zbytečné jenom dokud způsobují významnou procentuální zátěž. Určitě se to otevře spoustu nových polí působnosti, ale budou třeba vypadat úplně jinak než dnes a s jinými technologiemi.

      Ono v podstatě je to tak často i dnes – buďto se chce člověk věnovat vývoji cms a pak pracuje na tom a hlavní náplní je ho prodávat a nebo člověk prodává e-shopy koncovým zákazníkům a pak mu jde spíš o to, využít existující technologie a vyprodukovat hodnotu. Stejně tak kodér v budoucnosti může najít svoji působnost třeba v tvorbě nějakého frameworku – v rámci filozofie jednou a dost – tam se html třeba bude řešit, při tom konkrétním návrhu obecných komponent. Ale ti, co tyto komponenty budou používat k doručení hodnoty – tzn. tvorby stránek a aplikací už na to budou muset sahat málokdy.

      Samozřejmě, jenom čas ukáže, ale vývoj jde směrem k automatizaci a standardizaci toho co už umíme (resp. uhlazování a stabilizace podloží) a přidávání nových věcí, které jdou vidět na tom rozvětveném povrchu.

  6. Eric Force

    Jako byste mi z duše mluvil

    Jak je vidno dle titulku, musím souhlasit.
    Zrovna před pár dny jsem byl na přednášce pana Koska o server skriptech.
    Bylo to velmi inspirativní a podrobné shrnutí těch nejdůležitějších nástrojů, postupů a hlavně „jazyků“, které se používali/pou­žívají. A přesně to mě donutilo přemýšlet o věcech o kterých píšete. Pravdou je, že dnes oblíbená práce „webdesigner na volné noze“ nebo taky freelacer se stanou výjimečnými
    , protože dorbnější projekty už půjdou udělat za pár šupů.. (už dnes nám dává wordpress sežrat své, že) a ty složitější budou řešit specializované a ekonomicky optimalizované společnosti, jako jsou dnes běžné softwarové společnosti.

  7. Ifo

    Asi to je pravda. Ale!

    Pravděpodobně to tak dopadne, je však otázkou, jestli to skutečně bude úplně dobře. I moderní nástroje na generování HTML/CSS/JS trpí tím, že generovaný kód je až několikanásobně větší, než kdyby se to napsalo ručně. Nehledě k tomu, že vývojáři, kteří toho málo vědí o HTML/CSS/JS, můžou právě k tomuto nárůstu zbytečně velikosti kódu úspěšně přispět. Na druhou stranu se toto řeší „brutální silou“ – zvyšuje se výkon serverů, zrychlují se připojení k internetu. Takže ve výsledku budeme mít mraky zbytečných dat, které se budou přenášet, ale nikomu to nebude vadit, protože to bude „good enough“ (což se děje už i dnes). Bude to „good enough“ i pro mobilní zařízení? Ze začátku asi ne, ale pak to dopadne jako s Netbooky, kde na začátku byl celkem jasnou platformou Linux, ale jak na těchto „slabých“ strojích narůstal výkon usídlily se tam na výkon náročnější Windows XP. Když se na to podívám z pohledu uváděných příkladů z praxe – zatímco například dělání levnější čočky pro školní mikroskopy šetří zdroje a je dostatečně dobré pro výuku, tak v tomto případě povede strategie „dostatečně dobré“ spíše k plýtvání zdroji jinde (nároky na HW, přenosové rychlosti, s tím související zbytečné plýtvání elektrickým proudem na udržování HW v běhu …).

    1. mikiqex

      Re: Asi to je pravda. Ale!

      Je to jako s hrami… „když ti to neběží, kup si lepší mašinu!“ místo „tyjo, nedokázali bychom to nějak lépe optimalizovat?“.

      Zrovna u webových technologiích je problém, že každý je hned profík, udělá si živnosťák a začne bastlit. Z tohoto pohledu mě mrzí, že XHTML se stalo slepou vývojovou větví, protože osobně jsem zpřísnění pravidel vítal.

    2. Josef Richter

      Re: Asi to je pravda. Ale!

      Já myslím, že ten článek uvádí spíš opačnou kauzalitu. To znamená, že už máme natolik rychlý a silný stroje a natolik rychlý javascript enginy, že si u většiny běžných zakázek můžeme dovolit vykašlat se na spoustu ladění, který bychom třeba ještě před rokem dělali.

      Ale samozřejmě to platí oboustranně a je pár technologií, kterým ten hardware a ty javascript enginy nestačí a ty to naopak táhnou. Typickej příklad za všechny jsou Google Docs, nepochybně napsaný v nějakým složitějším JS frameworku, kvůli kterýmu Google zamakal na vývoji JS engine. Rychlost JS engines se za poslední dva roky snad zdesetinásobila :-)

    3. David

      Re: Asi to je pravda. Ale!

      Já bych i řekl, že to dobře je. Dobře by to asi nebylo ve chvíli, kdy bychom html/css/js měli jako konečný formát, s kterým se už nic nestane. Pak by se určitě vyplatilo utahovat kohoutky až na doraz. Jenže ono je dost pravděpodobné, že ty technologie tak jak je známe teď se časem buďto změní a nebo třeba i zmizí. A v takovém případě je podle mě mnohem efektivnější udělat abstrakci ve chvíli když už je to podle článku „good enough“ a jít dál. S tím, že to co leží pod tou abstrakcí se v průběhu času bude optimalizovat s mnohem větší rychlostí než kdybychom to optimalizovali my sami pokaždé ručně – resp. s daleko větším přínosem. A bude se to optimalizovat sice ne třeba 100%, ale s takovým tempem, aby to stačilo. Jde o to, že dnešní nasazení technologie, která je „good enough“ je v případě, že nevíme, jak bude vypadat budoucnost a nemůžeme na ní spoléhat, mnohem ekonomicky i efektivně výhodnější než optimalizovat na 100% to co je dnes. To si můžeme dovolit jenom v případě, že už opravdu nemáme nic jiného na práci. Protože optimalizovat na 100% to co je dnes může znamenat 100% náklady navíc ve chvíli, kdy se technologické poměry změní. Je to podobné jako když si člověk koupí osmijádro ve chvíli, kdy ho nutně nepotřebuje a stojí ho to ohromné peníze. Přitom druhý člověk si koupí čtyřjádro a za dva roky si to osmijádro koupí taky, bude mít pořád takový výkon, který dokáže využít a vyplatí se mu – v rámci principu good enough, ale bude ho to ve výsledku stát mnohem méně.

      1. David

        Re: Asi to je pravda. Ale!

        Navíc jak už jsem naznačil v jedné reakci výše, často se může vyplatit hybridní přístup – to hlavní se udělá automaticky a ručně se dolaďují až detaily na kterých opravdu záleží. Asi jako robotické auto – je drahé ho udělat naprosto soběstačné, ale jsme schopní ho vybavit takovými technologiemi s rozumnou cenou, která zajistí 80% případů a zbylých 20% speciálních přenecháme člověku – s tím, že výsledek bude mnohem efektivnější, protože se člověk bude moct soustředit jenom na ty opravdu vyjímečné a důležité věci.

        Pamatuji si jak v době kdy přicházely css frameworky byla plamenná diskuze o sémantice. Na jedné straně stáli ti, kterým to bylo jedno a na druhé straně ti, kteří nechtěli povolit ani jednu nesémantickou třídu. Přitom není nic jednoduššího než vytvořit vzhled ve frameworku a pak to nějakým automatickým nástrojem před publikací převést na sémantické třídy. S takovým přístupem to bude ideální pro stroje – z pohledu dodržování systému, a zároveň ideální pro člověka – z pohledu přehlednosti a jednoduchosti práce.

        1. keff

          Re: Asi to je pravda. Ale!

          Tohle napsal hezky Joel Spolsky:

          „that’s where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you’re writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it’s fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)“

          http://www.joelonsoftware.com/articles/fog0000000026.html

          1. Josef Richter

            Re: Asi to je pravda. Ale!

            Jasně. Aneb stručněji řečeno: pokud píšu něco, co už existuje, tak použiju existující nástroje. Pokud píšu něco „novýho,“ tak na to ty nástroje prostě ani neexistujou a musím jít „hlouběji.“

            1. keff

              Re: Asi to je pravda. Ale!

              Trochu jinak – klíčovou vlastnost, která mě má odlišit od konkurence, si napíšu sám a nepoužiju na to hotové řešení (jehož omezením se přizpůsobují všichni ostatní). Na ty ostatní věci klidně můžu použít už vymyšlené.

    4. ra.ri.ta

      Re: Asi to je pravda. Ale!

      „brutální silou“, kde je napsáno že to tak bude navždy. Ona ta „brutální silou“ je energeticky náročná a taky do budoucna velmi, ale velmi drahá. Kdo nebude šetřit daty, nebude.

  8. v6ak

    Binární formáty?

    Pokud se nebude kódovat ručně, mohou sem přijít binární formáty. Tipuji to na Google. Otázka je, co na to konkurence apod.

  9. Josef Richter

    s názorem v článku souhlasím

    Jen doufám, že to přijde ještě rychleji :-)

    Už dneska v „čistým“ javascriptu žádnej běžnej kodér nic nepíše a vezme si na pomoc minimálně jQuery.

    V html a css už taky většinou nezačínáme z čistým listem, ale bereme si aspoň nějakou šablonu, která má pořešenej css reset a většinu hacků pro Idiot Explorer, nebo přímo po nějakým „frameworku“ jako Blueprint, 960.gs nebo lessframework3. Případně do toho ještě zamícháme něco jako haml, sass, less, apod.

    Ten odhad „napsal bych to možná někde líp, ale trvalo by mi to 3x tak dlouho“ je možná ještě hodně optimistickej. Přecejen i blbej Bluepritnt css framework je něco, co se postupně vyvíjí už snad několik let a někdo do toho vložil možná stovky hodin vývoje, aby poladil věci, na který se prostě přijde až v praxi.

  10. Karel Mašát

    Souhlas

    Souhlasím, že je to cesta, kterou se vývoj (zcela logicky) bude ubírat. Příklady technologií beru pouze jako příklady, může to jít jinudy, ale myšlenka zůstane zachována. Osobně mě hodně mrzí neúspěch SilverLightu .. psát aplikace, jejichž „byte code“ je HTML a JSScript .. ach jo. Díky, za tenhle článek.

  11. dc

    ano i nie

    Clanok je zaujimavy ale ci uplne vymyzne programovanie vo web „assembleri“ (hmtl/css/js) je otazne. Pri beznych desktopovych app, ak idu pomaly, tak navysenie vykonu pocitaca moze pomoct ale na webe aj su stranky generovane zle a je v nich kopec bordelu tak cisto len navysenie vykonu nepomoze, dost zalezi aj na linke a dalsich faktoroch ktore casto zakaznik nemoze priamo ovplivnit. Nehovoriac o momentalne masivnom nastupe mobilnych zariadeni a prehliadania webu z nich. Tam stale treba optimalizovat na vykon (aj ked mnohe zariadenia su uz porovnatelne vykonne s beznym kancelarskym pc).

    1. v6ak

      Re: ano i nie

      To záleží na mnoha věcech:
      * koncoví uživatelé (Někteří uživatelé web z mobilních zařízení prostě neprohlížejí.)
      * očekávaná použití (Někdy, i kdyš spíše výjimečně, nelze očekávat použití z mobilu.)
      * náročnost aplikace (Optimalizovat nenáročné aplikace nemá moc smysl.)

      Vidím to ale spíše tak, že tyto optimalizace budou stále méně úkolem pro koncového programátora, když tu budou k dispozici automatizované 20/80 nástroje.

  12. shMoula

    Generatory kodu

    Mel jsem moznost si chvili hrat s jednim MDA nastrojem (Acceleo) a rekl bych, ze je to docela zajimave, jen je potreba to jeste hodne dopracovat (i kdyz uz to existuje uz hodne dlouho) a predevsim je potreba komunita, protoze o tom nikdo nic nevi :-(

  13. gege

    Buducnost je WEB 3.0 - semanticky web a ontologie

    V poslednom čase je možné na internete nájsť stúpajúci počet článkov na tému sémantický web. Spolu s týmto výrazom sa skloňujú pojmy ako napr. revolúcia vo vyhľadávaní, web s významom, nová forma aplikácií či databáz využívajúca metódy umelej inteligencie a podobne. Ak sa však niekto bude snažiť dozvedieť, čo to vlastne sémantický web je, vôbec to nebude mať ľahké.

    Súčasný web – záplava textov

    Čo je to sémantický web? Skúsme si to vysvetliť na jednoduchom príklade – nech existuje nejaký používateľ internetu, ktorý na sebe pozoruje príznaky vysokej teploty a súčasne aj únavy. Ak vloží tieto kľúčové slová do dnešného vyhľadávača, tak prostredníctvom neho získa obrovské množstvo nájdených odkazov, ktoré bude musieť sám preštudovať a na ich základe usúdiť, akú chorobu pravdepodobne dostal, pretože cíti, že na neho takpovediac „niečo lezie”. Avšak táto úloha je neľahká, časovo veľmi náročná, subjektívna a bez záruky relevantného výsledku. Nájdené odkazy, ktoré používateľ pravdepodobne navštívi, budú stránky opisujúce rôzne choroby, napr. chrípku, nádchu a mnoho iných ďalších chorôb. Nájde aj rôzne odporúčania, ako je možné chorobu liečiť.

    Súčasný priestor internetu je teda záplavou textov, či už vo forme blogov, správ, štruktúrovaných textov vo forme XML, tabuliek a podobne. Vyhľadávanie je v súčasnom internete veľmi málo efektívne, hlavne z dôvodu, že vyhľadávač (stroj) týmto textom nerozumie a súčasne ani nechápe, prečo hľadáme to, čo hľadáme.

    Sémantický web – obsah s významom

    Ako bolo spomenuté, hlavný problém súčasného internetu je v tom, že stroj nerozumie jeho obsahu. Stroj nerozumie žiadnym jazykovým výrazom a ani ich vzájomným vzťahom. A toto je práve miesto, kde prichádza na pomoc umelá inteligencia (znalostné inžinierstvo), ktorá využíva filozofickú disciplínu ontológiu, ktorá sa práve zaoberá vymedzením významu jazykových výrazov a ich vzájomných vzťahov.

    1. pas

      Re: Buducnost je WEB 3.0 - semanticky web a ontologie

      To je samozřejmě hodně zajímavé téma, ale vůbec nesouvisí s článkem, který je o „webových aplikacích“, přičemž tučně by mělo být uvedeno „aplikacích“. Čili jde o mnohem méně vznešené téma – o prachobyčejné GUI aplikací, o rozhraní pro lidi, ne pro stroje. Míchání těchto dvou rozhraní dohromady bylo typické pro „před-RIA“ generaci webu a doufám, že to už patří definitivně minulosti. Lidé a stroje mají přece jen trochu jiné nároky. :)

      1. Josef Richter

        Re: Buducnost je WEB 3.0 - semanticky web a ontologie

        Taky mi to na první pohled přišlo zcela nesouvisející s článkem. Na druhý pohled tam pár souvislostí je.

        Předně bych nechápal „webové aplikace“ tak uzavřeně, jako je to v případě těch desktopových, kde si každej hraje na svým písečku. To je jedna z vlastností webových apps, že jsou silně propojeny – když si vezmu třeba ten Twitter, tak je to jedna velká halda sdílených dat, nad kterou pracujou miliony „klientů“ a vlastně si jen filtrujou, co chtějí zobrazit, atd. Tímhle prolinkováním se zvyšuje užitnečnost sémantickýho popisování i pro aplikační data.

        S tématem to souvisí tak, že zatímco dneska musíme do kódu ručně dopisovat nějaký RDFa tagy nebo microformats, v budoucnu to za nás snad nějak inteligentněji udělají nějaký nástroje. Nikdy to nebude dokonalý, na druhou stranu v Google si to asi taky uvědomujou a pravděpodobně průběžně pracujou na „umělé inteligenci“ googlebota, kterej i bez RDFa tagů bude schopnej tomu obsahu přiřadit sám nějakej hlubší význam než dosud. Takže zatímco dneska to vyžaduje precizní ruční kódování RDFa / mikroformátů (což se nikomu nechce a nikdo to nedělá), tak zítra může stačit „good enough“ – něco vygeneruje framework a se zbytkem si poradí google.

    2. Jiří Kosek

      Re: Buducnost je WEB 3.0 - semanticky web a ontologie

      A teď tu o Červené karkulce, prosím.

      Takovéhle vize sémantického webu slýcháme už přes deset let a skutek pořád utek.

      Tomu, že stroje budou rozumět přirozenému jazyku, věří jen největší „umělí inteligenti“. V praxi dává použitelné výsledky jen hrubá síla a statistika. A to už dnešní top vyhledávače v menší či větší míře používají.

      1. v6ak

        Re: Buducnost je WEB 3.0 - semanticky web a ontologie

        Google square a Wolfram alpha? Vím, že to ještě dnes není běžně používané, ale kdo ví, co bude za pár let? Dovedu si celkem dobře představit, že to Google zakomponuje do běžného vyhledávání.

        Jinak WolframAlpha opravdu není jen matematický nástroj.

        1. Pavel

          Re: Buducnost je WEB 3.0 - semanticky web a ontologie

          Umělá inteligence prostě není a v nejbližších padesáti letech pravděpodobně nabude. Smiřte se s tím. Tohle jsou jen nadšená prohlášení marketingových oddělení, ale ty se nezakládají na skutečnosti. Nikdo neví jak na to, dokonce to zašlo tak daleko, že pár lidí chce jako poslední zoufalý pokus zkusit simulaci celého mozku, ale k tomu zatím nejsou technické možnosti. Jestli to povede k něčemu co by mělo schopnosti odpovídající příspěvku výše je taky otázka.

        2. Huge

          Re: G square a W alpha

          Pro jednoduché (jednoslovné nebo frázové) podněty jsou výsledky těchto engines relevantní. Problém nastane, pokud je výraz komplikovanější a je nutné se vytvořit nějaké propojení mezi kombinovanými výrazy. Zadám do Wolfram Alpha třeba „cryptographic cube“, ale dostane se mi odpovědi, že kostka má 8 vrcholů a úhlopříčku sqrt(3) s~~1.73205 s. Mě jako člověka, ale napadlo, že se dá Rubikova kostka využít jako jednosměrná funkce pro šifrování, nic podobného si ale WA engine domyslet nedokáže. Zadal jsem dále třeba „word tree“ nebo „potato juice“, ale nikdy jsem nedostal žádnou informaci o celém výrazu. Takže tohle je ta výzva.

    3. Ivan Nový

      Re: Buducnost je WEB 3.0 - semanticky web a ontologie

      To ano, bude-li sémantický web, tak dostanete informace, které umí chápat stroj, ale člověk nedostane informace, které potřebuje k vytvoření inovace, člověk se sníží na úroveň stroje. Tedy pokud stroj nebude chytřejší než člověk. Ale to hned tak nehrozí. A další nebezpečí je, že všichni budou dostávat stejné odpovědi na stejné, či podobné otázky. Což povede k nežádoucí synchronizaci myšlení lidí.

    4. Pavel

      Re: Buducnost je WEB 3.0 - semanticky web a ontologie

      Jakou mají marketingoví šašci vykazující činnost souvislost s obsahem článku?

  14. Jan Kodera

    dobrý článek

    Autor má pravdu. Pokud někdo chce takhle vyvíjet, tak může už teď. Nástroje existují. GWT vám umožní napsat plně funkční aplikaci pro HTML/JS a nebudete muset napsat jediný html tag. Dokonce i rozvržení vám dodá v pořádku. Jediné co budete muset dodělat je CSS omalovánky . Kód bude rychlejší, menší ale také přehlednější než psaný v čistém JS nebo jakémkoliv v JS frameworku(např jQuery apod).
    Ale také nemusíte, můžete si udělat kostru HTML a říct si, které části doplní GWT. Také to bude fungovat.

    Není otázka kdy to bude fungovat, ale kdy vy přejdete.

  15. Ivan Nový

    Za tři roky žádný web nebude, bude Facebook

    Obchod, služby, maily, všechno … kde budou konzumenti, tam bude web, a to bude Facebook, který překročil kritickou velikost. Na izolovaném PC taky kraloval MS, na síti bude od teď kralovat Facebook. No nevím jak teď, ale kdysi práce s CASE nástroji byla celkem otravná, prakticky spočívala v naplňování tabulek daty, které měly popsat výslednou aplikaci.

  16. bq

    nj, optimalizovat neni potreba vzdycky ...

    … ale nedokazu si nejak predstavit aplikaci, na kterou leze tisic lidi najednou napsanou v nejakym takovymhle hybridu, ten hw by to polozilo. Nejednou jsem porovnaval vykony a zatez hw mezi mejma vlastnima specializovanejma frameworkama s ruznejma jinejma obecnejma a je to kolikrat fakt des. Na ruzny zrudny sablonovaci systemy bych sahnul leda v nouzi a v dobry vire, ze na ten web fakt neprijde vic nez 20 lidi za den nebo u nejakyho intranetovyho firemniho reseni.
    Navic zkuste si vysledek takovyho hybrida otevrit v prohlizeci na mobilu, cekani na data, cekani na vykresleni, miliarda podivnyho javascriptu, kterej lame slabsimu hw na strane prohlizece vaz. optimalizovat, optimalizovat, optimalizovat… nic neni dost dobry !!!

    1. Zilogat0r

      Re: nj, optimalizovat neni potreba vzdycky ...

      Presne tak. Neexistuje predcasna optimalizace. V dnesni dobe je kazdy takovy pokus stejne hodinu po dvanacte – takze optimalizovat. HW neni nafukovaci.

        1. Zilogator

          Re: nj, optimalizovat neni potreba vzdycky ...

          Nepletete si to nahodou s predcasnou ejakulaci? To je totiz problem. Vetsiny tzv. „web developeru“. A tento zlozvyk zatahuji i do tvorby software – svoui polofunkcni zpatlaninu releasuji svetu vstric, aniz by splnovala zakladni vlastnost algoritmu – deterministicky fungovala nad vsemi vstupnimi daty.

          1. pas

            Re: nj, optimalizovat neni potreba vzdycky ...

            Žádný program ve skutečném světě není deterministický. Občas prostě spadne. A když zavoláte programátora, tak nespadne. Při naprosto identicky reprodukovaném vstupu. :)

          2. balki

            Re: nj, optimalizovat neni potreba vzdycky ...

            Deterministicky mozu fungovat len algoritmy, ktore su formalne specifikovane matematickym sposobom. (Napada mi, co s algoritmami ktore su nedeterministicke vo svojej postate :) ).

            Ak by sa vsetko vyvyjalo tymto sposobom, bolo by to strasne drahe pracne a pomale :) Moze si to dovolit akurat tak NASA a podobne institucie.

            Ano, zvycajne sa pisu testy, ale tie negarantuju, ze tam nebudu chyby.

            „deterministicky fungovala nad vsemi vstupnimi daty“ – to je utopia, ked uvazime, co vsetko moze dojst ako vstupne data. Niekedy je to az za hranicami fantazie.

    2. ijacek

      Re: nj, optimalizovat neni potreba vzdycky ...

      U kazde technologie je jen otazka casu, nez se najdou typicka uzka hrdla a vzniknou na to specializovane knihovny a nastroje. Ty sice sezerou par procent na vykonu, ale vzhledem k tomu, ze ten jde exponencialne nahoru, tak je to ve vysledku navrat par mesicu, nanejvys treba rok zpatky.
      Jinymi slovy, to co ted optimalizujete, na to bude za rok knihovna, ktera to udela stejne rychle na novym hw a pak uz se s tim malokdo bude parat. Bylo to tak vzdy a na webu se to vyviji stejne.

      Ostatne cely ten OS, browser a interpret js jsou vrstvy a kazda si neco nejake to procento vykonu vezme. Pred davnymi casy by to nebylo mozne provozovat, ale dneska si nikdo nepise vlastni alokatory pameti, vykreslovani atd. protoze je ten hw vykon nekde jinde. Sice by to tu stranku vykreslilo 10x rychleji kdyz by server poslal rovnou exe binarku (kterou nekdo brutalne zoptimalizoval), ale koho to zajima kdyz 10x nic je porad skoro nic.

      1. Pavel

        Re: nj, optimalizovat neni potreba vzdycky ...

        No já bych ten optimismus trochu brzdil. To že zatím výkon počítačů exponenciálně rostl neznamená, že to tak bude navždy. Jednou to skounčit musí. A ta doba může přijít klidně překvapivě brzy.

  17. Honza

    good enough

    Koukám, že redakce roota už dospěla k názoru, že pan Malý je „good enough“ na to, aby psal pro roota. Jen doufám, že také nedojde k logickému závěru, že např. pan Tišnovský je zbytečně kvalitní.

    Jinak v assebleru se pořád tu a tam ještě ladí. Zase taková hrůza to není. Nebo minimálně se člověk občas koukne, co z překladače C(++) vyleze a zkusí to pak napsat v tom C(++) líp. Jistě, ne každý den, ne každý programátor, ne v každé firmě, ne celý kód, ale jen kritická místa a samozřejmě to nedělají lidí, co v „good enough“ nástrojích vytvářejí klikáním weby nebo informační systémy.

    1. ToSnadNe

      Re: good enough

      > Nebo minimálně se člověk občas koukne, co z překladače C(++) vyleze a zkusí to pak napsat v tom C(++) líp.

      Co k tomuto dodat? Proč tedy nepoužíváte assembler na všechno? Není to tím, že C(++) je pro vás ve většině případů „good enough“, takže nemusíte trávit všechen svůj čas psaním ručně optimalizovaného kódu v assembleru?

      Pan Malý je velmi kvalitní autor. Bohužel, čím větší publikum, tím těžší je napsat „good enough“ článek pro všechny zúčastněné. A bohužel konkrétně pro vás „good enough“ nebyl, protože jste ho vůbec nepochopil. Pro většinu ostatních lidí „good enough“ byl, což svědčí o vysoké kvalitě autora (myslím si, že je výrazně těžší uspokojit velkou masu různorodých lidí, než malou vyhraněnou skupinu).

      Tak mě napadá, že problém je možná v tom, že to psal v příliš nízkoúrovňovém jazyce. Měl by to příště možná napsat v nějakém meta-jazyce a ten by se pak překládal každému člověku do jemu srozumitelné podoby, např. podle ankety zmiňované níže ;). Něco jako GWT, které generuje speciální optimalizovanou verzi JavaScriptu zvlášť pro každý browser :).

  18. bauglir

    Hehe

    1/ Pan Malý měl přidat pod článek anketu „Jsem programátor, který neviděl klienta ani z vlaku: ano/ne“

    2/ je srandovní sledovat, jak si „good enough“ čtenáři vykládají jinak, než je napsáno v článku a to přesně tak, jak se jim hodí: aby bylo se do čeho navést :)

    1. pixy

      Re: Vynikajici clanek

      btw, vrcholem ironie je, ze pod tuhle podivnou debatu lidi, co si casto nevidi na spicku nosu, se zobrazi kontextova reklama „Snadné webové aplikace, vytvořte si firemní aplikaci bez znalosti programování“… Google v tom ma celkem jasno. ;). Aneb kterak kolem hloucku hadajicich se formanu projel vlak a zvolna zmizel za obzorem.

  19. covex

    A kdo bude psat a optimalizovat ty zaklady?

    V clanku je polozena otazka zda si myslime, ze zrovna nase prace bude za par let jeste potreba. Ale ona bude, protoze kdo by psal a opravoval ty technologie, ktere lezi pod temi frameworky? A vite proc jeste budeme potreba? Protoze 1. cast utece k tem nadrazenym vrstvam, 2. cast vymre a ta 3. se bude muset postarat o ty asemblery.

  20. 1>0

    Thick clients

    Thick clients je buducnost. Vsetko bude na strane klienta. UI ovladacie prvky samozrejme bude generovat nejaka kniznica (napriklad ExtJS). Klient bude komunikovat so serverom len cez ajax vo formate mozno JSON, alebo XML. Web aplikacia proste bude len data provider. Povedzme RESTful. To je vizia pre web aplikacie a nie pre web stranky. Klientske masiny su dostatocne vykonne, aby zvladli business logiku. Ja na strane servera nevidim ziadnu revoluciu ani velku buducnost pre programatorov. Buducnost je na strane klienta a nie na strane servera. Generovat clientsky kod z PHP, hmm ale naco?? Naco mam nieco vygenerovat, ak rovno mozem pisat v JavaScripte? Html nemusim pisat, lebo mame ExtJS, css tiez nie. O tom je to cele. Na take robustne klientske aplikacie urcite JQuery kniznica je nevhodna. Dojo Framework, alebo YUI.

    Je samozrejme rozdiel v tom, pre koho je urcena web aplikacia. Ak to bude na webe , ako napriklad basecamp, tak urcite neuspejes s ExtJS. V takom pripade vzdy UI DESIGN a usability bude na provom mieste!!! Ak to robis pre nejaku firmu, tak design nemusi byt unikatny.

  21. narmer

    pravda

    Je to dobrý článek. A pravdivý. Kdysi jsemč programoval ve starém dobrém céčku. Když přišly vizuální aplikace, říkal jsem si, co je to za úpadek, jenom se tahaj tlačítka a pořádě se neprogramuje. Dnes si myslím totéž ;-), ale když potřebuju rychle něco napsat, je to velmi efektivní. A aplikace funguje bez problému, rychle, napsaný je to taky rychle, prostě je to „dostatečně dobrý“.

  22. Alda

    a tady je výsledek

    Vím, že už jsem časově mimo aktuální mozkobouření, ale výsledky těchto postupů jsme zažívali a zažíváme jako občané státu. Geniálně nefungující, ale draze placené projekty Úřadu práce, registr vozidel (a o kolika jich ještě veřejnost neví). Úroveň celého tohoto „řemesla“ jde do kytek, protože je to prostě doooost dobré. Kdyby se takto chovali výrobci jiných komodit, to bylo řevu:-)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3368