Jak budeme psát webové aplikace za tři roky?
Pokud se podíváme na tvorbu webových aplikací z nadhledu, zjistíme, že možná mnoho věcí, které pokládáme za základ webařiny, během několika let ztratí svou fundamentální pozici. POZOR: Ke čtení tohoto textu potřebujete schopnost chápat nadsázku a dívat se na neochvějné pravdy vlastní práce z nadhledu.
Nálepky:
Všiml jsem si zajímavého jevu. Jestli si vzpomínáte, tak před pár lety dávali tvůrci webů na svá díla takové malé ikonky, které hlásaly: Validní HTML, Validní CSS, Validní RSS… Dnes pomalu mizí. Dílem proto, že validní kód začal být samozřejmostí a už ho nelze prodat jako „konkurenční výhodu“, ale hlavně proto, že žádného čtenáře taková informace nezajímá, protože je pro něj zcela zbytečná.
U obsahových webů, ale hlavně u webových aplikací, začalo být důležité, CO to dělá, víc než JAK to je uděláno. Pokud je webová aplikace funkční ve většině prohlížečů, dobře ovladatelná a dělá to, co od ní uživatel čeká způsobem, jakým to uživatel čeká, tak je jedno, jestli je ve Flashi nebo v HTML5. (Odkaz je na hru PONG, kde je půl hracího pole vytvořeno ve Flashi a půl v HTML5.) Webové aplikace přestávají být „klenotem webařiny“ – tedy: konečně! – a stávají se aplikacemi, se všemi vedlejšími efekty, které z toho vyplývají. Například se mění přístup autorů k tvorbě a přibližuje se způsobům známým z tvorby spotřebního komerčního SW či jiného zboží, kde mezi důležitými zásadami stojí na prvním místě zásada good enough.
Good enough
Zásada good enough vyjadřuje jednoduchou myšlenku: Produkt je přijatelný ve chvíli, kdy je dostatečně dobrý. Jakékoli zbytné vylepšování nad hranice „dostatečně dobrého“ je neekonomické. Co je „dostatečně dobré“ záleží na trhu, pro který je produkt určen. Když budete vyrábět čočky, bude hranice good enough jiná pro trh výrobců průmyslových mikroskopů, pro high-end optiku do kamer, a jiná bude i pro trh, na němž nakupují výrobci školních souprav pro výuku optiky na středních školách. Ne že by čočky pro školní soupravy mohly být vysloveně špatné – jen nemusí být tak přesné a kvalitní jako pro profesionální teleobjektivy. Zásada good enough tedy neznamená „dělejte špatné věci“ (jak si mohou mnozí myslet), ale dělejte věci (jen) dostatečně dobré pro zamýšlené použití. Co je dostatečně dobré, to není třeba v tuto chvíli vylepšovat.
Co znamená zásada good enough pro psaní webových aplikací a software vůbec? Software je tak dobrý, jak musí být, aby byl prodejný, ale ne lepší (názor lidí, co se řídí heslem „jenom to nejlepší je pro mne dost dobrý“ je tu opominutelný). Lepší může být další verze, až se ukáže, co zákazníci opravdu potřebují (software má tu výhodu, že jeho vývoj lze iterovat po malých krocích; viz agilní programování). Software musí fungovat na „dostatečně dobrém“ vybavení. No a konečně lze tutéž zásadu aplikovat i tak, že pro vývoj software jsou použity „dostatečně dobré“ nástroje.
Dostatečně dobrý nástroj
Dostatečně dobrý nástroj je takový, v němž jsou náklady na vývoj (tj. čas a zkušenosti vývojáře) minimální pro dosažení „dostatečně dobrého“ výsledku. Nepřekvapí, že řada je sestupná – od nejnovějších vizuálních nástrojů a jazyků velmi vysoké úrovně abstrakce přes běžné vysokoúrovňové jazyky, přes nízkoúrovňové jazyky a přes „lepší makra“ až k assembleru. Čím nižší úroveň abstrakce, čím hlouběji se jde, tím dražší je vývoj – a tím jemnějších výsledků lze dosáhnout. Nástroje by šlo přirovnat k výtvarnickým: od hrubého dláta a rašple přes pilníky až k nejjemnějším smirkovým papírům.Nikdo si nebude brát na dvoumetrovou sochu, která bude stát kdesi v parku, smirkový papír, ani nepůjde tvořit náušnici dlátem. Vezme si „dostatečně dobrý nástroj“.
Vývojáři také používají (alespoň v ideálních podmínkách) většinou „dostatečně dobrý“ nástroj – tedy takový, v němž dosáhnou „dostatečně dobrého“ výsledku s nejmenšími náklady. Jednoduchý webový CMS napíšou v Djangu nebo RoR a nebudou se patlat s assemblerem; naopak modul do jádra systému napíšou v C (nebo právě v assembleru). Použijí takový nástroj, který jim umožní vytvořit to, co vytvořit potřebují, s nejmenšími možnými náklady (do kterých se započítávají i faktory jako „náklady na učení“). Čeština pro to má úsloví „brát kanón na vrabce“, angličtina používá slovo „overkill“.
Vývoj přináší stále nové a nové nástroje, které se (většinou) řadí na začátek řady „dostatečně dobrých“, a postupně ubývá věcí, pro které je nutné sahat k velmi jemným (a složitým, pracným, …) nástrojům. Dnes už nikdo nesahá do asm kódu, který vypadne z překladače C, proto, aby ručně optimalizoval některé konstrukce; překladače optimalizují velmi dobře a je jen velmi, velmi málo situací, kdy se vyplatí ruční optimalizace (a jen velmi málo lidí, kteří ji opravdu umí líp než překladač). Výkon dnešních procesorů a paměť počítačů posunuje hranici „good enough“ pro většinu aplikací daleko za cokoli, co bychom mohli „dooptimalizovat“ ručně v assembleru.
Není nejmenší důvod pochybovat o tom, že vývoj webových aplikací půjde stejnou cestou. Lze se tedy s celkem slušnou mírou pravděpodobnosti opřít do jednoho z axiomů tvorby webů a říct:
Psaní v HTML, CSS a JavaScriptu bude zítra overkill
Nebylo to na vás moc radikální, doufám?
HTML, CSS i JavaScript jsou technologie srovnatelné s makroassemblerem. Jsou na té nejnižší úrovni nad virtuálním strojem (=prohlížečem). Je velmi pravděpodobné, že se prohlížeče jako aplikační platforma nakonec prosadí, ať si o tom už myslíme cokoli; navzdory tomu, že by bylo mnohem lepší začít na zelené louce s opravdovou aplikační platformou. Bohužel, než se jakákoli aplikační platforma prosadí, budou prohlížeče o generaci dál a vývojáři budou tvořit aplikace právě pro ně, protože se jim nevyplatí čekat na novou platformu (a ještě riskovat, že vsadí na tu špatnou). Prohlížeče jsou dnes typická good enough platforma.
Stejně jako nikdo příčetný nepíše přímo bytekód pro JVM a místo toho používá Javu nebo Scalu, tak nemá příliš smyslu do budoucna psát aplikace přímo ve webovém bytekódu, tedy v JS/HTML/CSS. Na dveře už dnes ťukají první nástroje, které jsou „o generaci dál a o stupeň výš“.
Máme tu GWT – nástroj od Google, který umožňuje napsat webovou aplikaci v Javě a přeložit ji pro „platformu web“ – tedy do HTML, CSS a JS. Je tu OpenLaszlo, v němž lze popsat aplikaci pomocí XML a skriptů a přeložit ji do swf (FLASH) nebo do HTML/CSS/JS. Jsou tu i další nástroje, například Cappuccino nebo haXe, které překládají z nějakého „jazyka s vyšší úrovní abstrakce“ do JavaScriptu. Je tu CoffeeScript. A všechny tyto nástroje začínají být dostatečně dobré – JS enginy jsou už velmi rychlé a renderovací jádra prohlížečů také, takže kód, který vypadne z těchto nástrojů, je good enough i bez toho, aby se někdo ručně hrabal v HTML/CSS/JS a upravoval ho. Ostatně i VisualStudio produkuje poměrně použitelný kód – resp. webové aplikace napsané v ASP.NET nemá nikdo potřebu „optimalizovat“ na úrovni HTML/JS, protože jsou dostatečně dobré.
I pro tvorbu „obyčejných“ obsahových stránek jsou už „dostatečně dobré“ nástroje. Zapomeňte na tragický FrontPage nebo GoLive; nové nástroje, vytvářené a laděné zástupem webdesignérů, vytváří dostatečně kvalitní kód, validní, bez podivností, navíc dokážou optimalizovat zápis a ušetří i práci s psaním hacků či vendor-specific vlastností.
Prasečina, klikači, pro lamy…
Může se vám to zdát jako úpadek řemesla, ale to patří k vývoji. Co dnešní generace považuje za úpadek, to bude pro další přijatelný nástroj a pro další pak klasika. První opravdoví programátoři, zvyklí zadávat kód pomocí přepínačů a tlačítek, mohli považovat terminály a FORTRAN za úpadek řemesla. FORTRANovští programátoři považovali za úpadek Pascal, C i Smalltalk. Desktopoví programátoři považují za úpadek webové jazyky. Atakdál. Časem se „úpadková“ technologie stane mainstreamem, hlavně proto, že je dostatečně dobrá, tudíž ekonomicky výhodná.
Můj soukromý tip je, že do tří let budou technologie postavené nad HTML, CSS a JS dostatečně dobré k tomu, aby získaly významný podíl na trhu. Podobně jako se v posledních letech staly třeba PHP frameworky dostatečně dobrými. V roce 2003 každý rubal PHP tak, jak se to naučil: přímo do HTML, knihovny byly „fuj“ a ti největší guruové hlásali, že „knihovny zdržují a můj čas je příliš drahý na to, abych ošetřoval cizí chyby“. Dnes jsou frameworky v PHP good enough. Totéž platí třeba pro šablonovací nástroje: Před pěti, sedmi lety „zbytečnost, zpomalení, komplikovanost“, dnes už běžně přijatelná věc, která šetří práci. U jiných jazyků (Ruby, Python, …) platí totéž.
Stejně tak odejde třeba i dnešní PHP. Neříkám že zmizí, na to je příliš rozšířené a příliš používané. Ale frameworky postupně vytlačí psaní „surového PHP“; další logický krok budou generátory kódu, které z nějakého jazyka s vyšší úrovní abstrakce vytvoří dostatečně dobrý PHP kód nad nějakým frameworkem (a přestane být důležité nad jakým: prostě nad dostatečně dobrým). Vývoj se zrychlí a zlevní; psát PHP kód bude stejná podivnost jako dnes psát assembler.
V nadsázce řečeno spolu s jednou postavou známého filmu: Dávám psaní v HTML rok, nejvýš dva!
Kodéřina: vymírající řemeslo
Nechci tvrdit, že znalost HTML a CSS bude do tří let zbytečná, to v žádném případě. Jen nebude nezbytně nutné znát je do hloubky, protože nebudou denním chlebem. Převod návrhu od designéra do HTML/CSS postupně nebude při vývoji webových aplikací tak důležitá záležitost jako dnes. Nástroje, které budou dejme tomu v roce 2013 (a berte toto datum cum grano salis) k dispozici, budou pravděpodobně schopné vytvořit dostatečně dobrý kód z nějakého zápisu chování v jazyce velmi vysoké úrovně a z vizuálního návrhu UI (a to tvrdím s vědomím rizika, že za tři roky tento článek někdo najde a bude se mi posmívat). Je docela dobře možné, že třeba Flash Builder (dříve Flex Builder) nebo Visual Studio dostane přepínač „ Přeložit do HTML/JS/CSS“ – a nikoho nebude trápit, že výsledný HTML kód nebude tak krásný, jako kdyby ho psal opravdu dobrý kodér. Bude „dostatečně dobrý“, ale bude vytvořen a odladěn mnohem rychleji a laciněji než od opravdu dobrého kodéra.
Mimochodem: nespoléhejte na to, že si dnes připadáte jako vysoce kvalifikovaní odborníci – trh, a tím i vývoj, jde vždy nakonec cestou minimálních nákladů, a věřit, že ocení kvalitu, znamená často zavřít krám. Na trhu je jen omezený prostor pro drahou ruční práci – proč myslíte, že to bude zrovna ta vaše?
V oblasti webových aplikací bude pravděpodobně posun k podobným nástrojům, ke „generátorům kódu“, markantnější než u obsahových webů, kde se kodérské řemeslo bude držet delší dobu; obsahové weby bývají unikátnější a podíl ruční práce bývá vyšší. Už dnes ale vím o webdesignérech, kteří jsou perfekcionalisté a dokáží si hrát s detaily – a používají (třeba) Dreamweaver, protože jim umožní soustředit se na dílo, ne na implementační detaily. Pracují rychleji, produktivita jim roste, protože se nezabývají opakovanými prázdnými činnostmi, ale přitom mají stále možnost zasáhnout do detailů. Zbytek kódu, o který se za ně postará nástroj, je i pro ně „dost dobrý“ – jeden z nich mi řekl: Napsal bych to asi někde líp, ale trvalo by mi to třikrát tak dlouho.
A přesně to vyjadřuje princip good enough, a taková bude podle všeho i budoucnost nástrojů pro vývoj webových aplikací.
Jaký je váš názor na budoucnost vývoje webových aplikací? Myslíte si, že se bude dál psát tak, jak píšeme dnes, jen s novými verzemi jazyků, nebo že porostou schopnosti a vliv „generátorů kódu“ natolik, že překročí hranici good enough a stanou se primárním nástrojem pro vývoj? Nebo si myslíte, že webové aplikace v prohlížečích budou nahrazeny jinou platformou? Podělte se o svůj názor na toto téma!
Martin Malý
Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.
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.
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
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.
„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…
Dalsie sproste slovo – „refaktoring“ poznate ?
Tím jste chtěl říci přibližně co?
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.
„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. ;-)
„Tím jste chtěl říci přibližně co?“
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.
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ě“.
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ý.
Trosku vacsi kusok kodu. Refactoring je o zlepsovani struktury.
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.
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á.
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.
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.
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.
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.
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.
Máte pravdu, příteli. Zapomněl jsem na to, pro koho píšu, a text jsem raději upravil. Omlouvám se.
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.
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.
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í.
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.
Čá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.
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í.
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.
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í.
Ř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í.
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.
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.
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.
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.
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.
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 …).
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.
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 :-)
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ě.
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.
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
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.“
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é.
„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.
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.
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.
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.
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).
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.
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 :-(
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.
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. :)
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.
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í.
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.
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.
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.
Ano, taky to beru spíše jako náznak budoucnosti.
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í.
Jakou mají marketingoví šašci vykazující činnost souvislost s obsahem článku?
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.
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.
… 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 !!!
Presne tak. Neexistuje predcasna optimalizace. V dnesni dobe je kazdy takovy pokus stejne hodinu po dvanacte – takze optimalizovat. HW neni nafukovaci.
http://www.c2.com/cgi/wiki?PrematureOptimization
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.
Žá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. :)
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.
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.
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.
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.
> 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 :).
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 :)
Vytecny clanek, diky moc za nej.
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.
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.
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.
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ý“.
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:-)