33 komentářů k článku Jaká je budoucnost webového a internetového vývojářství?:

  1. JersyWoo

    Změna úhlu pohledu

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

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

      Re: Změna úhlu pohledu

      Přesně tak. Doporučuji ale menší exkursi po několika českých firmách „od webu“… To že jsou paradigma „současná“ ještě neznamená, že jsou „samozřejmá“. Bohužel.

  2. Jáá

    Grafika

    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.

    1. Jáá

      Re: Grafika

      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.

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

        Re: Grafika

        „v konečném důsledku je nejdůležitější jak se web používá a jak je uživatel spokojený“. Ano. Tím, jak se web používá, se zabývá „použitelnost“, tím jak je spokojený se (taky) zabývá „user experience“. A tyhle obory, stejně jako třeba SEO nebo Agile, lze dělat dvěma způsoby: Způsobem tupé aplikace několika pouček („zapneme vám SEO za 100 Kč/měsíc“), anebo kreativně.

        Chtěl bych, aby kreativní odborníci z těchto oborů v průběhu příštího roku na Zdrojáku ukázali, že „použitelnost a UX“ nejsou jen tupě aplikované poučky, ale právě zjištění, jak se web uživatelům používá a jak jsou spokojení.

  3. ra.ri.ta

    Záslužné

    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.

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

      Re: Záslužné

      Ano, v tom se shodneme. Viz ten poslední „seznam“ – co je pole, nechť je pole, co je tabulka, nechť je tabulka. Takže: Kde se centralizace vyplatí, nechť je centralizováno (ve Vašich příkladech spíš „sjednocováno“ a „seskupováno“). Viz třeba cloud – je to SESKUPENÍ (neřekl bych „centralizace“) výpočetního výkonu… :)

      A s poslední větou souhlasím, do kamene ji tesat!

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

      Re: No...

      Příklady budou, nebojte… :) Zůstaňte čtenářem Zdrojáku, a jednoho pěkného příkladu se dočkáte hned příští týden.

      A ad „bezpečnostní smrt“: Není nic „nebezpečné“ ani „bezpečné“, je jen přijatelná nebo nepřijatelná míra rizika. A tu hranici přijatelné/nep­řijatelné má každý někde jinde – nehledě na to, že znalý člověk dokáže případné následky rizik zmenšit na přijatelnou míru. Ostatně: Jezdíte autem? :)

  4. D3T

    Opatrne

    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.

  5. Jan Sládek

    Díky

    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!

  6. DanekA

    problémy někoho jiného

    „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)

  7. koudi

    Dobré, ale mám výhrady

    Č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.

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

      Re: Dobré, ale mám výhrady

      Je dobré, že máte výhrady. Máte v mnohém pravdu, a především se shodneme v tom, že je potřeba ZNÁT ROZUMNOU MÍRU. Proto jsem záměrně zvolil nadsazené vyjádření. Mým cílem nebylo provokovat lidi, kteří dokáží vidět rozumnou míru, ale trošku postrčit ty, co všechno to, o čem jsem psal, hodí do pytle s nápisem „to je zbytečné, to my tu neděláme!“

      Ostatně, původně byl v tom seznamu ještě poslední bod, který zněl: „Spoléhejte se hlavně na vlastní rozum a neberte nic doslova a dogmaticky.“ :)

    2. MarekTP

      Re: Dobré, ale mám výhrady

      <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).

    3. kraag

      Re: Dobré, ale mám výhrady

      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…

    4. Zara

      Re: Dobré, ale mám výhrady

      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 ..

  8. František Kučera

    Frantův komentář

    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 :-)

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

      Re: Frantův komentář

      Jak píšu v odpovědi o komentář výš: Ano, správná míra je naprosto nezbytná. Přiměřenost je v těch bodech taky (tak jednoduché jak jen lze, ale ne jednodušší).

      Proto jsem například postavil tvrzení o „barvách, co nezabijou fungující web“ jako protiklad k tvrzení, s nímž se často setkávám (lépe: S nímž jsem se setkával) v praxi, totiž k požadavku, aby web byl „pixel-perfect omalovánka“. Hodiny dokázali „webdesignéři“ řešit, jestli je modrá správně modrá (půjčili si někde i kalibrační sondu na monitor a nastavovali), ale například v login formuláři neměli tlačítko „přihlásit“. Ale to prý nebyla jejich starost. :)

      K těm databázím: Nechci se o tom rozepisovat nějak víc v komentáři, ale – není zvláštní, že nové obrovské servery (co do objemu dat a počtu požadavků) nepoužívají RDBMS, ale různé varianty „prostých úložišť“, ať už dokumentově orientovaných, nebo „klíč-hodnota“? Za Facebookem, LinkedIn, Twitterem, za Googlem, za Amazonem, za těmi všemi nestojí SQL stroje, ale nerelační databáze. Na příští týden mám naplánovaný k vydání jeden „user case“, který to hezky ilustruje.

      To o „databázi coby výpočetním středisku“ není v rozporu se zbytkem. Pokud použiješ RDBMS, napsané NEJLEPŠÍMI programátory, potřebuješ DOBRÉHO SQL programátora, co tu tvoji byznyslogiku nacpe do SQL (a většinou ji tam ani nenacpe celou). A ten člověk, co dělá web, bude muset transformovat data ze vstupu do formátu pro SQL a SQL to transformuje pro DB. A požadavek musí formulovat v SQL a RDBMS mu vrátí nějak data a on je zase transformuje… Mně to připadá jako velké množství vysoce kvalitní práce – – – vyhozené naprosto zbytečně! :) (Prosím, ponechme stranou aplikace, kde DB server přímo zobrazuje webové stránky a podobné zhůvěřilosti. Nechme stranou i svět ENTERPRISE aplikací – bavíme se o webu.)

      A hlavně – je Silvestr. Pojďme, pobavíme se příští týden u článku… :)

    2. Karel Minařík

      Re: Frantův komentář

      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.

      1. Karel Minařík

        Re: Frantův komentář

        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í.

      2. František Kučera

        Re: Frantův komentář

        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“.

        1. Petr

          Re: Frantův komentář

          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“.

    3. keff

      Re: Frantův komentář

      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.

      1. MD

        Re: Frantův komentář
        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.

  9. Petr

    Konstantní změna, nebo změnová konstanta?

    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).

    1. Jan Kodera

      Re: Konstantní změna, nebo změnová konstanta?

      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.

      1. Petr

        Re: Konstantní změna, nebo změnová konstanta?

        „…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.

        1. Jan Kodera

          Re: Konstantní změna, nebo změnová konstanta?

          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.

          1. Kit

            Re: Konstantní změna, nebo změnová konstanta?

            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.

  10. LACO

    BEZ HRANIC

    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!

  11. Martin Michálek

    "web" může být na grafice závislý

    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.

    1. Břetislav Passinger

      Re: "web" může být na grafice závislý

      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.

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=3144