Přejít k navigační liště

Zdroják » Různé » Jaká je budoucnost webového a internetového vývojářství?

Jaká je budoucnost webového a internetového vývojářství?

Články Různé

Konec roku přímo vybízí k obecným úvahám. Pojďme se i my zde na Zdrojáku pro jednou zamyslet nad vývojařinou jako takovou. Jak se mění náš pohled na věci spojené s vývojem webů? Jak dlouho si ještě vystačíme s tím, co umíme? A jestli si s tím nevystačíme, tak co se máme naučit? Kudy půjde vývoj?

Pročítám si poslední dobou články na Zdrojáku a diskuse u nich a snažím se nevšímat si konkrétních slov a technických detailů, ale spíš zachytit ducha doby, nějaký jednotící pocit, převládající tendence, směry… A když se nad tím zamyslím, vychází mi jako ústřední prvek změna.

Což není nijak překvapivé, protože svět IT se neustále mění. Co platilo před několika lety je dnes beznadějně zastaralé a včerejší IT odborník musí leckdy zahodit podstatnou část toho, na čem donedávna stavěl, a začít stavět znovu, chce-li zůstat odborníkem i zítra. Tak jsme i na Zdrojáku svědky změny a posunů stylů, postupů a priorit. Včerejší jistoty se dnes drolí a kdo si vsadí, že se zítra rozpadnou, pravděpodobně neprohraje, i když bude podobná sázka někomu připadat jako čiré šílenství. 

I proto je jakákoli predikce vývoje v IT věštěním z křišťálové koule. Říct, co bude ve vývoji webů za dva, tři roky „in“, je čiré plácání do vody. Ale přesto lze na základě určitých obecných tendencí s poměrně vysokou měrou pravděpodobnosti říct, kudy se bude ubírat „mainstream“ (který má vždy několikaleté zpoždění za novinkami v oboru) a které z dnešních novinek budou zítřejšími (či pozítřejšími) „standardy na trhu“. Leckdy stačí jen sledovat intenzitu diskuse k jednotlivým tématům.

Konec „webdesignu“

Například taková grafika webu. Když se řekne „udělat web“, představí si spousta lidí především grafický návrh. Vypadá to logicky a pochopitelně, přesto však někteří, v oboru respektovaní, tvůrci otevřeně hovoří o tom, že grafický vzhled webu je v porovnání s ostatními aspekty vlastně nepodstatná věc. Že je v zásadě úplně jedno, jestli je web vzhledově takový či onaký. Ostatně: Jakou „grafiku“ měl e-shop, kde jste naposledy nakupovali? A jakou „grafiku“ má vaše elektronické bankovnictví? Jakou „grafiku“ má web vašeho oblíbeného zpravodajství?

Je jasné, že grafickou stránku člověk vnímá a „ten svůj“ web podle ní pozná. Ale pokud mu web „sedne“ do ruky a do hlavy, pokud se na něm bez problému orientuje a pokud získá to, co požaduje, tak je mu jedno, jestli boxy mají stíny nebo kulaté rohy. Důležitější je, zda ho něco ruší nebo zda se cítí pohodlně. Stránka může být vizuálně škaredá jak upomínka od finančního úřadu, ale když se na ní uživatel cítí „jako doma“, tak se na ni bude vracet. Grafika totiž nedokáže udělat ze spatlaného návrhu použitelný web, a ani sebeošklivější (míněno esteticky) kombinace barev nedokáže sama o sobě „zabít“ web, který funguje. Nepochybujme o tom, že grafika dokáže použitelnost webu podtrhnout (v obou smyslech toho výrazu), ale není při návrhu webu tím hlavním. Hlavní jsou věci jako „použitelnost“, „přístupnost“, „uživatelský prožitek“… Přesto stále řada lidí (nejen klientů, ale i tvůrců) zužuje „návrh webu“ jen na to, aby byl „hezky namalovaný“. Snad proto, že „obrázek“ dokáže posoudit i laik z oddělení PR a od oka řekne, zda web je v „korporátních barvách“, ale použitelnost nebývá z grafického návrhu zřejmá. O to horší (a dražší) jsou pak důsledky chyb. A jednou z největších chyb u webdesignu je dělat web tak, aby se vzhledově líbil zadavateli.

Rozdrobení

Jiná, a poměrně zásadní, změna se odehrává už řadu let a ovlivňuje velké množství oblastí, od metodiky vývoje přes vývojářské nástroje až po samotnou infrastrukturu a technologie. Klíčová slova, určující tuto změnu, jsou „decentralizo­vaný“, „distribuovaný“ či „paralelní“. Tato změna je tak zásadní, že jsem ji v jedné diskusi před několika dny přirovnal ke změně, kterou přinesla Brunova teorie o mnohosti světů. Stejně jako ona rozbila představu o výsadní pozici Slunce ve vesmírném uspořádání a hierarchii, tak i tato změna boří tradiční modely fungování systémů – a tady mám na mysli nejen ty počítačové.

Od modelu „Centrální počítač – mnoho terminálů“ se přechází k síti vzájemně propojených služeb. Tomuto přechodu napomohl internet, který, ačkoli je mnohými subjektivně vnímán jako nějaká uzavřená entita, k níž se připojujeme (něco jako když si pořídíme průkazku do knihovny a chodíme si tam půjčovat knihy), je čím dál zřetelněji sítí propojených uzlů, kde každý, kdo se připojuje, je zároveň její součástí. Analogie „každý návštěvník knihovny je zároveň knihou“ je sice přesná, ale těžko představitelná – což leckdy svádí lidi k domněnce, že to tak není, přesně podle myšlenkového schématu „Co si nedovedu představit, to není možné“.

Webexpo 2009 - ilustrace
S nejnovějšími trendy a novými pohledy na webový vývoj jsme se mohli letos zblízka setkat například na WebExpu  (Ilustrační foto: Ivana Dvorská)

Internetový partyzán

Ztráta hierarchické struktury, spojená s decentralizací, se dá přirovnat k transformaci armády v autonomní partyzánské oddíly. Klasický voják se bude stále ptát: „No ano, ale kdo tomu bude velet?“ – Nikdo – „No a jak budeme vědět, co máme dělat, když nedostaneme rozkazy?“ Změna myšlení z vertikální hierarchie nadřízený – podřízený na hierarchii síťovou, kdy nelze předem říct, kdo bude velet ani co se bude dělat, se ukazuje jako nezbytná podmínka pro další rozvoj oboru („všechno zbourat, stavíme znovu!“) Podobně jako v neuronových sítích či v jejich biologických předobrazech není struktura předem dána ani známa, neví se, kdo bude velet, neví se kam se půjde ani kudy – a přesto to funguje a dokáže to produkovat smysluplné výsledky. A nejen to: Adaptabilita, kterou přináší zrušení pevně daných struktur, se ukazuje být evoluční výhodou.

Například v organizaci práce se tato změna projevuje přechodem od „modelu vodopád“ (tj. lineární postup, kde na začátku je zadání, analýza, vývoj, testy, opravy a nakonec hotový produkt) k agilním postupům, které fungují v krátkých iterativních cyklech, kdy se po malých dávkách postupuje k cíli. Nevýhody těchto postupů (hlavně ta, že nelze dopředu říct přesnou cenu ani termín) jsou v klasické „strukturované“ organizaci fatální. V reálném světě však začínají převažovat výhody – tedy možnost změnit zadání kdykoli během vývoje, pružně reagovat na vnější vlivy či reálně opustit model „programátor sedí osm hodin v kanceláři, má měsíc dopředu daný úkol, píše kód a při odchodu musí udělat commit do CVS“. Velké softwarové firmy takový model za svůj přijmou dnes jen stěží, protože staví na hlavu jejich zaběhnuté metodiky, normy, systémy řízení a postupy práce. Pro menší týmy je ale agilní metodika výhodou (pokud doopravdy pochopí princip Agile, ne pokud slepě aplikují poučky z příruček).

Konec tradičních hodnot

S rozpadáním monolitů na drobné jednoduché části souvisí třeba i nástup NoSQL databází – jednoduchých úložišť, která uloží jakákoli data, aniž by bylo zapotřebí předem specifikovat, jakou budou mít formu a jaké budou mít vazby. Proti obřím databázovým strojům mají několik podstatných výhod – jsou flexibilní, levné, snadno škálovatelné a rychlé. Díky těmto vlastnostem razantně nastupují do světa webových aplikací, kde naráží na velmi tuhý odpor – zejména ze strany vývojářů. Leckteří se naučili perfektně normalizovat databázi, znají všechny fígle a vychytávky Toho Svého Oblíbeného Systému, vědí, jak optimalizovat dotazy a jak využít indexy (a jsou v tom opravdu dobří), tudíž je pro ně představa, že o tohle všechno přijdou, velmi těžká.

Ne snad že by to byli omezenci či že by měli zkostnatělé myšlení, to ne. Spíš to jsou lidé, co jsou opravdu dobří v navrhování modelů relačních databází a dokáží vidět v duchu strukturu databáze už na úvodním setkání se zákazníkem. Struktura databáze je pro ně nejen denním chlebem, ale i jistotou, ke které se lze vrátit vždy, když při vývoji něco selže. NoSQL (přesněji „non-schematic“) databáze tuhle jistotu bere. Místo jasně dané kostry, kde je hned vidět, že tohle souvisí s tamtím a v objednávce jsou položky a ty mají tahleta políčka jsou najednou nějaké amorfní shluky dat, nad nimiž nelze kouzlit s LEFT JOIN a HAVING a WHERE. Data zdánlivě ztrácí řád a mění se v chaos. Ovšem chaos jen zdánlivý – stačí si stoupnout o kus dál a podívat se z jiného úhlu. Což ne vždy bývá snadné, obzvlášť pokud jste velmi dobří v pozorování a navrhování struktur.

Pilní hlupáci

Kdysi jsem v knize o psychologii četl zajímavý postřeh, který zněl zhruba tak, že pracovitý debil je pro společnost užitečnější než psychopatický génius. To, co tato (mimochodem: pravdivá) sentence říká o lidské společnosti nechme stranou a zkusme ji aplikovat na svět IT.

Čím dál víc se odděluje opravdová tvůrčí práce od hrubé síly. Ano, pamatuju se na dobu, kdy počítač měl několik kilobajtů paměti a každý větší program bylo umělecké dílo sui generis. Ano, pamatuji se na časy, kdy každý server obsahoval databázi, webový server a filesystém a kdy každý návrh databáze byl unikátem (ne přímo „klenotem“). Kdy každý web byl od základu napsán na zelené louce. Ostatně, není to tak dávno. 

Dnes je ale „hrubá síla“ dostupná a levná. Mnohem důležitější, než odhadnout nároky aplikace za rok či dva je schopnost napsat ji tak, aby fungovala pro dvě stě uživatelů i pro dvě stě tisíc uživatelů plus mínus stejně, aby stačilo jen přidat několik dalších strojů a říct: Ty budeš databáze, ty HTTP server. Neméně důležité je ale použít takovou infrastrukturu, která podobné čarování umožňuje – jako například cloud.

Armáda jednoduchých a levných strojů udělá pak požadovanou práci levněji, rychleji a spolehlivěji než jeden geniální výtvor geniálního autora. Nehledě na to, že jednoduché a levné stroje je snazší nahradit, přikoupit, rozprodat, opravit, přeskupit, spravovat, provozovat… Čímž nijak nepopírám nenahraditelnou roli intelektu, jen tvrdím, že by se měl realizovat někde jinde než v oblasti „šetření levné námezdní síly“. Ušetřený megabyte prostoru je dobrý možná někde… někdy… ale pro většinu aplikací je námaha, vynaložená na tuhle úsporu, mnohem dražší než onen megabyte prostoru.

Změna úhlu pohledu

Není to tak dlouho, kdy mi jeden velmi uznávaný tvůrce webů říkal: „Ne, frameworky a knihovny nepoužívám! Nechci trávit čas tím, že hledám chyby někoho jiného, to si raději udělám svoje!“ Po relativně krátkém čase, po pár měsících, mi líčil své nadšení z jQuery a z toho, že se konečně nemusí hodiny zabývat kompatibilitou mezi různými prohlížeči a tajuplnými chybami, a místo toho opravdu tvoří. Ovšem přechod k tomuhle poznání byl jistě velmi náročný – znamenal pro něj změnit pohled na to, jak se má web dělat.

Učeně se tomu říká změna paradigmatu. Pokud chceme dál rozumět tomu, jak se vyvíjí (pro) web, je nezbytné dřív nebo později změnit svůj úhel pohledu na spoustu věcí, které jsme se dodneška učili téměř jako základy řemesla, a které mohou leckomu připadat až svatokrádežné­. Třeba:

  • Na webu není potřeba čarovat s grafikou, ale s logikou.
  • V cca 98 % případů se výkřik „ten web dělal kretén!“ nevztahuje ke sladění barevné palety ani k použití určitého fontu, ale k ovládání služeb a dostupnosti údajů.
  • Nikoho nezajímá váš názor na prohlížeče. Lidi zajímá, jestli jim váš web bude fungovat na jejich zařízení. A to zařízení nebude vždycky jen PC!
  • Webová aplikace potřebuje rychle dostat data a předat je dál. Nikoho neokouzlí, že umíte napsat stored procedure a optimalizovaný JOIN přes pět tabulek.
  • Uživatel webu neřeší, jestli FLASH nebo ExtJS nebo Silverlight, zajímá ho, jestli mu to bude k něčemu dobré.
  • Server není unikátní osobnost, k níž si budujete vztah, server je stroj, co posílá data z místa A do místa B. Nebo dva stroje. Nebo osm strojů. Nebo jiných osm strojů.
  • Databáze webové aplikace není výpočetní středisko, ale skladiště dat. Nemusí být chytré, stačí že je rychlé, dá se snadno zvětšit, když data přibudou, a dá se snadno upravit, když se data změní.
  • Dělejte věci tak jednoduché, jak jen mohou být, ale ne jednodušší. (Když se něco má chovat jako pole, použijte pole, když je něco tabulka, použijte tabulku. No a na web se třemi statickými stránkami nepotřebujete Zend Framework a RDBMS!)
  • Programátor webových aplikací většinou nepotřebujete databázi jako takovou, ale perzistentní objekt a session.
  • Programátor má řešit problémy, ne psát stokrát to samé. To se dělá ve škole za trest.
  • Spousta problémů, které programátoři řeší, jsou dávno vyřešenými problémy někoho jiného.
  • Potřebujete na svůj web (třeba) diskusní fórum? Špatný vývojář si ho napíše. Dobrý vývojář použije už hotový balík, který přizpůsobí svým potřebám. Rozumný vývojář si ho koupí jako službu a ušetřený čas věnuje opravdu tvůrčí práci.
  • Neptejte se „jak udělám na serveru náhled nějaké stránky v PNG“, zeptejte se kdo to umí a za kolik. Naopak (pro)dávejte to, co umíte vy. Tam, kde si každý dělá všechno sám a znovu po svém a pro sebe, nakonec mají všichni míň, než by mohli mít.
  • Nejsou věci „bezpečné“ a „nebezpečné“, jsou jen různé míry rizika. Různí lidé akceptují v různých situacích různou míru rizika.
  • Nikdo vám neřekne co máte dělat. Musíte si na to přijít sami
  • Až zjistíte, že nad vámi ani pod vámi nikdo není, zkuste se rozhlédnout okolo sebe.

Možná vám to ve vaší firmě, kde se třeba ještě dohadujete, jestli přejít na XHTML a o kolik dražší je dělat aplikace „i pro Mozillu“, připadá jako hudba budoucnosti. Nebo jako nesmyslné novoty, na které nemáte čas… Třeba to hodíte do škatule s nápisem „módní hlouposti, po kterých za pět let pes neštěkne“ a „věci, co tu jsou už dávno, jen jim dal někdo nálepku a všichni o nich mluví“. Možná máte pravdu. Možná mají pravdu hlasatelé změn. Uvidíme v dalších týdnech, měsících a letech. Já osobně sázím na změnu a gratuluji všem vývojářům, pro něž jsou výše popsané věci „současné“. Vězte, že to není ani zdaleka samozřejmé!

Pojďme tu změnu sledovat společně!

Pokud s touto úvahou nesouhlasíte, můžete ji brát třeba jako žertovný „Silvestrovský speciál“, můžete se jí od srdce zasmát nebo zanadávat autorovi v komentářích; autor slibuje, že je stejně nebude číst.

Komentáře

Subscribe
Upozornit na
guest
33 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
JersyWoo

Autor skvěle v posledním odstavci v mnoha „el íčkách“ vyjádřil paradigmata současného vývoje

Jáá

Nemůžu si pomoct, ale „použitelnost“, „přístupnost“, „uživatelský prožitek“ jsou jen plácání odborníků, kteří se musí taky něčím živit.

V konečným důsledku je pro většinu návštěvníků nejdůležitější to, jak se web používá a jak vypadá (na čemž má grafika zásadní podíl), než to, jestli je správně sémanticky napsaný a jsou správně odstupňovaný nadpisy.

Jáá

PS: Tím jsem chtěl možná neobratně vyjádřit to, že v konečném důsledku je nejdůležitější jak se web používá a jak je uživatel spokojený, než slepě lpět na všech možných standardech, přístupnosti a použitelnosti.

Když bude perfektně napsaný web dle všech zásad použitelnosti, přístupný pro zrakově postižené, sémanticky správně atd. ale bude to jen černý fornt na bílém pozadí, tak to pořád bude stát za starou belu.

Jinak se vším v článku souhlasím.

ra.ri.ta

Ano, cítím ten posun naproto stejné. Jen v jednom bych polemizoval „Rozdrobení“.

Zdá se mi, že je výhodnější (obecně) cesta další centraliazce tam, kde je to přínosné (pronájmy prostoru a času) a DEcentraliazce toho samého. Přirozeně s celkovým snížením „provozních“ nákladů. Nakonec další nadpisy to potvrzují.

Bude třeba připustí, že „skoro“ vše je již vymysleno a nezbývá to než začít smysluplně používat.

jj

V článku lze s mnohým souhlasit, s mnohým nesouhlasit (u těch „bordel db/ne-db“ by to chtělo nějaký příklady), ale cloud, to bude leda bezpečnostní smrt jedinců i firem:
http://securityworld.cz/…alizace-2185

D3T

Ja bych byl opatrny. Souhlasil bych s tim, ze skoro vsechno v clanku popsane, je dobre mit napameti. Ale pokud to nekdo vezme slepe a hloupe za „dogma“ (k cemuz autor jiste zamerne nevybizi), dobre to nebude (ostatne jako kazde dogma…). Hlavni problem, ktery v clanku vidim, je, ze se da (zdanlive jen, kdyz to clovek „schvalne“ nechape) cist jako obhajoba nazoru „na vsechno se vykaslete, nic chytreho ani sloziteho nema smysl, nic tvorit nema smysl, vsechno uz existuje, jen to vezmete a pouzijte, a kdyz to nahodou neexistuje, zjednoduste zamyslenou funkcionalitu tak, aby uz to existovalo. Proste pokud si ty „rady“ a „trendy“ vsichni vezmou „moc k srdci“, za chvili tu nebude (ne absolutne, ale relativne) zadny posun, zadne nove chytre vecicky, nad kterymi se nekdo opravdu zamyslel a venoval tomu cas, ackoli neco podobneho uz existovalo, ovsem nebylo to tak dobre, aby to resilo dany problem vyborne. To, ze existuje tisic implementaci weboveho fora, podle me neznamena, ze nema smysl udelat implementaci tisic prvni. Pokud ma clovek novou myslenku, a nebo treba to jen lip nez vetsina ostatnich naprogramuje (i kdyz treba az po roce, dvou, peti implementovani…), muze se casem stat jeho implementace jednou z nejpouzivanejsich a celkove nejlepsich. Kdyz vsichni budou spokojeni (tzn. budou pouzivat a budou si „paradigmaticky dokazovat“, ze uz nema smysl psat nic noveho), pak zustaneme, kde jsme. Proste stavajici dobre implementace nemuseji byt ty nejlepsi a klicem ke vsemu je aktivita. Navod z clanku se da, podle me, aplikovat slepe jen v byznysu, a ani tam dlouhodobe nemusi vest k zadoucimu stavu.

Honza Sládek

Martine, díky za pěkný článek.

Těším se na články na Zdrojáku v příštím roce. Změna chápání slova web design více po americku (tedy jako kompletní návrh a tvorba webu, nejen jeho grafika), důraz na uživatele, noSQL databáze, SAAS… Ty jo, to bude jízda!

DanekA

„problémy někoho jiného“ – Jako ve smyslu z The Hitchhiker’s Guide to the Galaxy – něco, co člověk nemá šanci vidět, jedině když přesně ví, kde to je? :o)

koudi

Článek jsem jen tak prolétl, víceméně se s ním dá souhlasit. Nicméně (zvláště na konci) je pár bodů, které jsou přinejmenším diskutabilní.

Asi nejvíc mi vadí bod
Potřebujete na svůj web (třeba) diskusní fórum? Špatný vývojář si ho napíše. Dobrý vývojář použije už hotový balík, který přizpůsobí svým potřebám. Rozumný vývojář si ho koupí jako službu a ušetřený čas věnuje opravdu tvůrčí práci.

Toto rozhodně neplatí obecně a jsou případy, kdy je to i přesně naopak. Podívejme se na (podle mě hodně špatně zvolený) příklad fóra. Mějme nějaký vlastní systém, se spoustou uživatelů, do kterého chceme přidat fórum.

Takže ideální je varianta je koupit si službu? A jak provedu napojení na vlastní databázi uživatelů? Opravdu chci mít takováto data „někde u někoho“? Integrace do vlastního portálu bude probíhat jak?

Nebo si stáhnu hotové řešení a zaintegruji ho? To by znamenalo se nejdřív zorientovat v kupě cizího kódu (asi by nebyl problém, pokud by byl dobře napsaný a okomentovaný) a pak ho „nějak“ propojit se stávajícím systémem.

V případě fóra (jakožto poměrně jednoduchá záležitost) mi tedy nejlépe vychází si ho napsat sám. Ano, je sice už asi milion napsaných fór, ale v rámci integrace do stávajících systémů to bude vždy o něco náročnější.

Toto je celkem konkrétní případ, na kterém jsem chtěl ukázat, že to neplatí vždy a na 100%. Jako mnohem vhodnější příklad by podle mě byl hned následující bod „jak udělám na serveru náhled nějaké stránky v PNG“. To je přesně ten příklad služby, kterou se vyplatí si kopuit a nepsat sám.

A jen drobná otázka na konec: Jaká tvůrčí práce by vlastně zbyla na rozumného programátora (který si koupil službu), když „Spousta problémů, které programátoři řeší, jsou dávno vyřešenými problémy někoho jiného“? :)

Dále už jen pár drobných poznámek (snad to nebude vypadat jako přílišné rýpání) :)

Webová aplikace potřebuje rychle dostat data a předat je dál. Nikoho neokouzlí, že umíte napsat stored procedure a optimalizovaný JOIN přes pět tabulek.

Ano, ale dobře napsaný a optimalizovaný join může být prostředkem k dosažení cíle (rychlejší doručení dat), takže to poměrně souvisí :)

Uživatel webu neřeší, jestli FLASH nebo ExtJS nebo Silverlight, zajímá ho, jestli mu to bude k něčemu dobré.

Uživatel to neřeší do té doby, dokud si nemusí donistalovat potřebnou komponentu.

Databáze webové aplikace není výpočetní středisko, ale skladiště dat. Nemusí být chytré, stačí že je rychlé, dá se snadno zvětšit, když data přibudou, a dá se snadno upravit, když se data změní.

Ona ale taky nesmí být naopak příliš hloupá. Rychlost není vše, je také dobré, když zůstane zachována konzistence dat apod.

Na webu není potřeba čarovat s grafikou, ale s logikou.
Ano, ale opravdu odporná grafika člověka dokáže velice rychle odehnat.

MarekTP

<b>Souhlasím s výhradami</b>, speciálně u toho napsání vlastního kódu.
Používat vždy řešení třetích stran není rozumné, ale psát věci tak, abych je mohl používat znovu smysl má. Zrovna fórum a shop jsou sice náročnější úkoly, nicméně nasazovat ZenCart, OSCommerce, … na prodejce, kteří mají řádově desítky položek je dost šílený overkill. Prostě musím vědět, která cesta je v danný moment schůdnější, nenasadím fórum, když potřebuji triviální poradnu (na otázku jedna odpověď), ale pro jiný projekt nebudu psát celou funkčnost phpBB (nebo jak se jmenuje nějaký rozumný bazmek na fóra).

kraag

S tim forem presne souhlasim.
Resil jsem tenhle problem. Na strankach bylo mizerne forum a potrebovalo se nove. Po vyhledani nejvhodnejsiho free fora se udelal seznam pozadavku, ktere bude zapracovat. Propojeni se strankama a zapracovani vsech nutnych pozadavku by dalo extreme moc prace a hlave by to bylo pomale a tezko upravitelne. Nakonec to pro nas naprogramoval externi programator za par tydnu. Vse funguje jak chcem a je po problemu.

Kdybychom „chytre“ pouzili neco hotoveho, tak jsou s tim jen problemy.

PS: koupit si forum jako sluzbu bych fakt nechtel. Nejen ze data budou jinde, urcite to bude i pomalejsi a navic by to byla dalsi sluzba, ktera muze vypadnout…

Zara

Já myslím , že to jsou dobrá rýpnutí ,i když článek sám je celkem zajímavý podnětný..Zkusím další Ohledně implementace Fora – určitě souhlas , že jde o poněkud trivialní věc ,ale proč třeba například už dneska nezvážit API do Facebooku … a využít jeho forum v Mashup aplikaci .. ? Třeba to je ten směr co měl na mysli ..

František Kučera

Předně díky za inspirativní článek. S chutí jsem si ho během snídaně přečetl :-)

„a ani sebeošklivější (míněno esteticky) kombinace barev nedokáže sama o sobě ‚zabít‘ web, který funguje.“
Ne všichni, mají technologický pohled na věc a ne všichni se zajímají jen o funkce. Lidé jsou různí, proto si také často kupují hezké mobily a hezká auta a ne jen chytré (a škaredé) mobily a výkonná/úsporná auta. (čímž nechci říct, že použitelnost, přístupnost… nejsou důležité)

„internet … je čím dál zřetelněji sítí propojených uzlů, kde každý, kdo se připojuje, je zároveň její součástí. Analogie ‚každý návštěvník knihovny je zároveň knihou‘“
Přesně. A tohle je podstata Webu 2.0 (ne všechny ty AJAXy a jiné technologické cypoviny). Je ale zajímavé tenhle problém sledovat ve dvou rovinách – v té logické (obsahové) rovině je to pravda, stírá se rozdíl mezi autorem obsahu a jeho konzumentem, všichni jsme autoři i konzumenti zároveň (zatímco dřív byl někdo autor, vyvěsil na web svoje statické stránky, a někdo jiný byl konzument a četl si je – maximálně mohl autorovi poslat e-mail, což byl vrchol interakce).

Ovšem v té technologické (fyzické) rovině dochází k trendu přesně opačnému – dochází k centralizaci. Internet (fungující na IP protokolu) ztrácí svoje původní kouzlo, velká část uživatelů je za NATy a firewally a navázat přímé síťové spojení z jednoho uzlu (např. můj laptop) na druhý uzel (např. tvůj počítač), abychom si poslali třeba nějaký soubor po IM nebo navázali VoIP hovor, je téměř nemožné. Trochu se to změní s rozvojem IPv6. Snad… V technologické (síťové) rovině je ten rozdíl server vs. klient čím dál výraznější. Snad nebudu sám a označen za staromilce, když řeknu, že chci ten původní decentralizovaný internet zpátky (na síťové úrovni). Kromě toho dochází i k centralizaci majetkové – není to jen Google, který vlastní kde co a člověk u něj (u jednoho ekonomického subjektu) může mít prakticky celý svůj internetový život, ale i velcí hráči, kteří si rozparcelovali český internet (významné zpravodajské a zájmové servery). Z tohoto pohledu je jasným trendem centralizace.

„Proti obřím databázovým strojům mají několik podstatných výhod – jsou flexibilní, levné, snadno škálovatelné a rychlé.“
Škálovatelné a rychlé? Kde jsou k tomu nějaké benchmarky a testy? Relační SŘBD se vyvíjejí dvacet a více let, za to dobu jsou vysoce optimalizované a mají řadu pokročilých funkcí. Stihly je některé z těch mladších a modernějších systémů dohnat a předehnat v oblasti výkonu? Nemyslím si, že by to tak bylo. Výhoda může být ale v tom, že ušetří práci kodérovi, který nemusí přemýšlet nad SQL a oddře to za něj procesor na serveru. Pokud se to finančně vyplatí (procesory jsou levné), tak budiž, dělat opak by bylo nerozumné, ale pokud se za chvíli ukáže, že ten úžasně cool a moderní framework/databáze, nad kterým jsme aplikaci napsali za 15 minut (a ještě jsme na to mohli najmout toho nejlevnějšího opičáka, protože psát nad tím je opravdu jednoduché), neumí škálovat a že nestačí přikoupit RAM a procesory, a je potřeba celý systém přepsat, tak to možná nebylo tak moudré. (I když kompletní přepsání aplikace taky nepovažuji za prohru, jako někteří – někdy to může být to nejlepší rozhodnutí, které člověk udělal. Aneb aplikace nemusí fungovat deset let, může nám být k užitku třeba jen 1–2 roky a pak ji, až naše firma vyroste, přepíšeme, i to je dobré.)

Co se týče nerelačních databází, zajímavé mi přijdou XML databáze, ovšem jejich výhoda, dokumentová orientace (která tam z principu je), je i jejich největší nevýhoda a někdy znemožňuje jejich nasazení (resp. dají se našroubovat téměř na všechno, ale nemá to smysl). Asi nejlepší je hybrid mezi relační a XML databází – do relační DB jsou dopsané funkce pro práci s XML a kromě klasických sloupečků máme v tabulkách i sloupeček obsahující XML data. Tím člověk může získat „to lepší z obou“.

„Potřebujete na svůj web (třeba) diskusní fórum? Špatný vývojář si ho napíše. Dobrý vývojář použije už hotový balík, který přizpůsobí svým potřebám.“
Je to vždy o hledání nějaké „rozumné míry“. Na otázku, zda používat cizí a hotové nebo psát vlastní, neexistuje obecná odpověď. Někdy to dopadne tak, že si člověk zbytečně přidělává práci psaním vlastního, a jindy jako když pejsek a kočička vařili dort, nastrkají tam všelijaké dobroty (knihovny, frameworky), které jsou samy o sobě fajn, ale dohromady je z toho nesourodý blívajz. Aneb nabít hubu si člověk může tak jako tak :-)

„Databáze webové aplikace není výpočetní středisko, ale skladiště dat.“
Tohle mi přijde trochu v rozporu s předchozím bodem (nepsat si zbytečně vlastní věci). Databázový systém je cizí kód (tzn. ušetřili jsme si práci), kód psaný těmi nejlepšími programátory, a my si ho zahrneme do své aplikace, místo abychom si psali vlastní SŘBD. Je ale škoda, nevyužívat možnosti, které nám DB dává a degradovat ji na pouhé úložiště dat, protože to, co neuděláme v DB, musíme udělat v aplikaci (případně v nějaké mezivrstvě). A teď je otázka, jestli jsme lepší programátoři než ti profíci, kteří psali daný DBMS nebo jestli radši necháme pracovat jejich kód a naopak „degradujeme“ svoji aplikaci na „zobrazovač dat z DB“ + něco málo té klíčové byznys logiky.

„Nikdo vám neřekne co máte dělat. Musíte si na to přijít sami“
jj :-)

Karel Minařík

Jen úplně na okraj:

> Škálovatelné a rychlé? Kde jsou k tomu nějaké benchmarky a testy? Relační SŘBD se vyvíjejí dvacet a více let, za to dobu jsou vysoce optimalizované a mají řadu pokročilých funkcí. Stihly je některé z těch mladších a modernějších systémů dohnat a předehnat v oblasti výkonu? Nemyslím si, že by to tak bylo.

Ono nejde moc o to, co si kdo z nás „myslí“ :) Nové formy databází vznikají _hlavně_ kvůli nedostatečnému výkonu tradičních/re­lačních db – prakticky všechny ty „nové“ databáze napsal někdo, kdo ten větší výkon _potřeboval_.

Benchmarků je samozřejmě milión, je to opravdu jeden z hlavních důvodů proč použít XYZ a ne tradiční stack. Například Redis má pěkně zpracovanou benchmark page na http://code.google.com/…i/Benchmarks: „Results: about 110000 SETs per second, about 81000 GETs per second“

Podobné stránky vč. zdrojových kódů benchmarků najdete snadno pro Tokyo Cabinet, CouchDB, MongoDB, etc.

Karel Minařík

Zapomněl jsem samozřejmě dodat, že srovnávat primitivní key:value store jako Redis s jakoukoliv *SQL je nesmysl – ale ten bod s výkonem platí.

František Kučera

Asi mluvíme každý o něčem jiném, proto je těžké se shodnout. Struktura klíč-hodnota (asociativní pole, v lepším případě hash table a DHT) je daleko víc datová struktura než databáze (byť bude persistovaná na disku) a systém, který se o tyhle struktury stará, bych nenazval DBMS (It must address problems such as security, accuracy, consistency among different records, response time, and memory requirements.) Nikdo tu sice netvrdil, že to DBMS je, ale vzhledem k tomu, jak se v obecné mluvě slučují pojmy „databáze“ a SŘBD (DBMS)…

„Results: about 110000 SETs per second, about 81000 GETs per second“

Tím benchmarkem/testem jsem myslel spíš nějaké srovnání – jeden scénář-aplikace, která bude realizovaná jednou nad relační databází a podruhé nad něčím jiným.

Tohle tvrzení je asi na úrovni jako říct: „Moje kolo je milionkrát úspornější než tvoje auto.“ Ale už nám neříká nic o tom, že na kole na nás bude pršet, že když dojde ke srážce s jiným autem, na kole je daleko větší pravděpodobnost, že nepřežijeme… a v neposlední řadě to, že na kole musíme šlapat (tzn. věci, které neřeší DB, musíme řešit ručně v aplikaci). Hádat se, co je lepší nemá smysl – stejně jako v reálném světě vedle sebe lidé vesele jezdí v autech i na kolech a nevypadá to, že by jedno z nich vyhynulo, stejně tak v počítačovém světě budou existovat jak relační i nerelační databáze a i primitivní datové struktury… každé se hodí na něco jiného a každé má své smysluplné využití – chyba nebývá v technologiích, ale spíš v lidech, pokud pro daný účel používají špatné technologie.

„Zapomněl jsem samozřejmě dodat, že srovnávat primitivní key:value store jako Redis s jakoukoliv *SQL je nesmysl“

Souhlas.

…ovšem když tu vznikla diskuse relační vs. nerelační, tak bychom měli srovnávat srovnatelné – proto si pod nerelačním SŘBD představím spíš databázi objektovou nebo hierarchickou nebo třeba XML databázi… ve kterých lze uchovávat strukturovaná* data a kde systém nabízí bohatší paletu funkcí (srovnatelnou s relačními DBMS) než jen „načti“ a „ulož“. Taková databáze může plně nahradit tu relační a pak má smysl je srovnávat a bavit se která je vhodnější (rychlejší, bezpečnější, pružnější…) Zatímco „databáze“ typu klíč-hodnota nemohou plně nahradit relační databázi, ale mohou se využít jen jako doplněk k jinak strukturovaným datům. Použít jen tyto „databáze“ (bez strukturovaných dat někde jinde) by bylo (alespoň u většiny aplikací) velice nešťastné (všechnu práci, kterou za nás DBMS dělá by musel oddřít náš programátor a naše aplikace). Věci jako Redis jsou fajn, ale hodí se pro specifické případy a pro specifická data (obvykle tedy jen část dat, která máme) a není to obecná náhrada jiných DBMS nebo nějaký další vývojový stupeň – budou tu fungovat vedle sebe, stejně jako ta kola a auta :-)

*) strukturovaná složitěji než primitivní „klíč-hodnota“.

Petr

Mluvíte mi z duše, především vyjádření „… není to obecná náhrada jiných DBMS nebo nějaký další vývojový stupeň…“ je trefné. Ve svém předchozím příspěvku jsem se něco podobného snažil vyjádřit, ale mnohem obecněji (k celému programování).

Těch „buzzwordů“ (…nová ekonomika, všechny aplikace budou webové, web 2.0, teď nové databáze a v budoucnu přijdou určitě další) je vždy nějak více, než skutečně principiálních změn. Asi my lidé neustále toužíme po něčem novém, úžasném (co už bude ono a nejlépe na všechno), že když to nepřichází (a tak rychle to fakt nejde), tak si to alespoň sami sobě „nabulíkujeme“.

keff

Ne všichni, mají technologický pohled na věc a ne všichni se zajímají jen o funkce. Lidé jsou různí, proto si také často kupují hezké mobily a hezká auta a ne jen chytré (a škaredé) mobily a výkonná/úsporná auta. (čímž nechci říct, že použitelnost, přístupnost… nejsou důležité)

Podle mě jsou hezký vzhled a použitelnost ortogonálními veličinami – a u zmiňovaných mobilů můžete imho najít levné a použitelné (takové ty lepší základní), levnější hezké ale těžce nepoužitelné (měl jsem teď v ruce jednu z levnějších dotykových nokiích, majitelka se přiznala že na tom píše sms 10× pomaleji, ale je to cool a animované), a za kombinaci hezkého vzhledu a použitelnosti si chytří lidé připlatí (a hloupější nechápou jak může stát mobil tolik, a patlají svůj touchscreen :)). No, to jsem se rozepsal trochu zbytečně, ale to důležité je, že grafický vzhled a použitelnost mají minimální míru korelace.

MD

No, to jsem se rozepsal trochu zbytečně, ale to důležité je, že grafický vzhled a použitelnost mají minimální míru korelace.

To je asi pravda, a zaroven je take oboji stejne dulezite, ac se to mnohdy nezda. Souhlasim prave s nazorem, ze lide jsou ruzni a pro kazdeho je dulezite neco jineho. Nekdo se rad opaji logickou strukturou, konzistenci a organizovanosti systemu, jiny necha pusobit barvy a animace na sve emoce. Oboji ma svuj vyznam.

Petr

No, tak jsem si přečetl článek i diskusi a musím naopak říct, že je to pořád stejné. Například, co si pamatuju, tak se při vývoji softwaru vždy zvažovalo zda použít již hotové knihovny nebo napsat vlastní. Obdobně se lavírovalo zda ponechat centralizované nebo to distribuovat, popř. dokonce decentralizovat. Tehdy I dnes platí, že pokud není nezbytné, tak se to dělá centralizovaně, protože se snáze ukočíruje robustnost. A tak bych mohl pokračovat s dalšími body. Zamyšlení je to hezké, ale věřte tomu, že stejných zamyšlení v bleděmodrém se v historii programování udělalo a napsalo už spousta. Takže nic převratného se neděje a neuděje (alespoň do doby než někdo objeví něco principiálně odlišného a bude ochota nebo nutnost to použít).

A nenechte se mýlit svou uzavřeností v tzv. webových aplikacích. Webové aplikace jsou totiž v podstatě pouze uživatelská prostředí. A jednoduché aplikace jsou opravdu tvořeny jen uživatelským prostředím (+ nějaká triviální perzistence, jak bylo zmíněno v článku). Například na diskusní web nebo seznamku opravdu nepotřebujete ani SQL server. Ale počkejte až se na web dostanou větší aplikace (např. klient/server, kde je klient i server netriviální). Tak vám tyto dnešní (jednoduché, neomezující atd.) prostředky stačit nebudou a rádi sáhnete po těch tradičních a vypiplaných (dle vás zkostnatělých).

Jan Kodera

Aha, takže vy máte pocit, že třeba Facebook je triviální aplikace? Trochu soudnosti prosím, to co bylo vyvinuto před 20 léty je vypipláno, ale pro jiné úlohy. Rozhodně se nestane, že by někdo šáhnul pro staré dobré klient server řešení, spíše se webové technologie zlepší, tak aby umožnily lepší aplikace.

Petr

„…Aha, takže vy máte pocit, že třeba Facebook je triviální aplikace?…“ Ano, třeba ten slavný Facebook, Twitter nebo samostatná webová aplikace e-shopu jsou v podstatě jen evidence (chcete-li katalogy) s minimálním transakčním (natož složitějším) zpracováním. Prostě se naťukaná (popř. naklikaná) data uloží, aby se v zápětí prezentovala zpět v prohlížečích – toť vše.

„… to co bylo vyvinuto před 20 léty je vypipláno, ale pro jiné úlohy…“ Tady s vámi souhlasím, pro jednoduchou evidenci dat a jejich prezentaci opravdu nezbytné nejsou (to jsem psal už v předchozím příspěvku). Při složitějších aplikacích se však bez nich neobejdete.

„…Rozhodně se nestane, že by někdo šáhnul pro staré dobré klient server řešení…“ Naopak, bežně se to stává a stávat bude. Znovu opakuji, nenechte se mýlit svou uzavřeností ve webových aplikacích (ne všechny aplikace jsou tvořeny v podstatě jen uživatelským rozhraním).

A ano, webové technologie se zlepší. Například tak, že sáhnou právě po starém dobrém klient/server řešení. Jak se už dnes začíná dít. Proč myslíte, že se začíná klást důraz na JavaScript a proč vznikají prostředky jako Silverlight, AIR, JavaFX? Protože netriviálního klienta bez nich neuděláte! Netriviální server se v mnoha případech (naštěstí už dlouho) dá postavit na nějakém pořádném SQL serveru a nějakém mezikusu v Javě nebo C# (popř. PHP + uložené procedury). Je to zatím nejlepší cesta, jak dostat složitější aplikace na web a přitom zachovat jejich robustnost.

Jan Kodera

Ano to je logické, že bez rychlého javascriptu nepůjdou dělat lepší aplikace. V tom rozpor není.

Ale kde se hluboce mýlíte je Facebook. Backend který pohání Facebook a zaručuje, že lidé budou mít své informace v rozumném čase je složitější než nějaká klient server aplikace. Právě u Facebooku dochází SQL dech. Facebook má skoro vše uloženo v paměti, protože technologie o kterých mluvíte nejsou schopny něco takového zvládat. A z paměti se to pak propaguje na permanentní úložiště. Podobný případ je Twitter.

Kit

Uložení dat v operační paměti nepovažuji za významný technologický pokrok. Je to jen změna úložiště na rychlejší médium. Úspěch Facebooku a Twitteru bych viděl v něčem úplně jiném. Je to volba vhodného algoritmu zpracování pro danou úlohu. Při použití vhodných cache může fungovat stejně dobře i na diskovém úložišti.

Netvrdím, že SQL je to jediné správné řešení. Je mnoho aplikací, ve kterých je key:value vyhovující a přináší maximální výkon systému.

LACO

Vůbec nejsem IT profesionálem, můj byznys je jinde, ale článek jsem si přečetl s velkým zájmem. Mnohé pravdy v něm obsažené lze totiž vztáhnout i na řadu jiných oborů.

Martine, PALEC NAHORU!

Martin Michálek

Martine, není zcela jasné co vlastně v „grafický vzhled webu“ myslíte grafickým vzhledem a co vlastně webem. Pokud jsou u vás grafikou zmiňované ornamenty typu zaoblené rohy, pak máte ve velkém množství případů pravdu. Není to ale pravda na webu univerzální.

Denně používanou aplikaci určitě nepřítomnost grafiky nepokazí, ale představte si, že byste o grafice jako nepodstatném aspektu mluvil třeba u mikrosajty pro mobilního operátora nebo webové hře pro děti.

Určitě souhlasím s tím, že se energie mnoha tvůrců a ještě více klientů zaměřuje zcela nesprávně tímhle směrem, ale to zobecnění není myslím správné. „Web“ je dneska stejně konkrétní označení produktu jako „potravina“. :-)

Díky a doufám, že si podobných článků z nadhledu přečtu na Zdrojáku více.

Břetislav Passinger

Také myslím, že je to silné tvrzení. Je aplikace a aplikace.

Ale chápu ho jako pojmenování začátku jednoho konce. A to konce období kdy se vymýšleli stále nové a nové designové přístupy. Možnosti technologií ve webdesignu (html, css, javascript) jsou prozkoumány a vytěženy a je patrný trend návratu k základům – aplikace zjednodušovat a nezahlcovat uživatele množství podnětů. A grafiku použít tak aby byla někde na pozadí nevnímána a usnadňovala to co uživatel doopravdy chce a potřebuje.

Takže pokud si nepamatujete vzhled svého posledního internetového obchodu, je vše na dobré cestě :).

Doporučuji související (a výbornou) přednášku by Giles Colborne from cxpartners http://www.cxpartners.co.uk/…mplicity.htm

Existuje někde i video, ale teď ho nikde nemůžu dohledat.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.