Tvorba webových aplikací není jako práce s buzolou

Už nějaký ten pátek se zabývám tvorbou webových aplikací. Už na základní škole jsem se poprvé setkal s HTML a díky nejmenovanému časopisu jsem objevil první editory, které byly pro začátečníka dostačující. V té době jsem se ale na Internet dostával pouze ve škole a webové stránky si tvořil pro zábavu nebo pro výstup mnou naprogramovaných desktopových „agentů“ běžících napozadí. Až na střední škole jsem se začal pomalu rozvíjet a zpracovávat určité webové projekty a dále se rozvíjet a vzdělávat.

Ona to není ani tak potřeba jako nutnost se stále rozvíjet. Neustále se objevují nové věci, zajímavé věci, které je dobré se naučit kvůli jejich funkci do budoucna. Jak se ale někteří staví k webovému programování a co pak následně nabízejí? To mi někdy zůstává rozum stát. Avšak on je problém zcela zřejmý.

Proč se učit něco nového, když umím tohle!

Už dříve jsem se setkával s tím, že když se někdo naučil tvořit HTML, často mu to nestačilo a začal pátrat, jestli by nešlo dělat komplexnější webové aplikace i s možností ukládat a zpracovávat data. Objevilo se tak PHP a MySQL. Jenže jsem se často setkal i s tím, že to bylo tak všechno. Maximálně do toho přibyla základní funkčnost JavaScriptu (ať už čistě napsaného) nebo pomocí některého jQuery frameworku.

Pak se můžeme setkat s tím, že některé webové aplikace jsem nedostatečně zabezpečené, protože základní znalosti PHP často nestačí k bezpečnostnímu ošetření webové aplikace. Proto vznikly a stále vznikají frameworky, které tuto rutinu usnadňují a předkládají použitelné a používáním oveřené řešení. Jenže proč se naučit něco nového, když si myslím, že to umím dobře? Když mi to jde a nějakou kačku jsem na tom už vydělal? Ono to není bezpečné – no tak to za nějakou kačku opravím.

Ano, každý má jiné potřeby a proč vyvíjet nějakou činnost, když mi to takhle nějak funguje. To si řekne každý v každé profesi.

Práce s buzolou může být pro někoho náročná

Použil jsem záměrně titulek tohoto článku. Letos v létě jsem jel se školou na povinný kurz k Orlické přehradě, kde jsme měli v rámci zápočtu orientační běh. Dostali jsme mapu, buzolu a měli jsme 9 stanovišť na trase 6 kilometrů. A někdo si s buzolou opravdu nevěděl rady (v dnešním světě GPS navigací se není co divit) a proto si do kapsy na cestu přibalil i mobilní telefon s navigací.

Ona i samotná tvorba a udržení si použitelných znalostí pro tvorbu zajímavých webových aplikací není jen o tom, naučit se nějaké základní kroky a pak produkovat „nějaké“ webové aplikace. Z webového vývojáře se pak nemůže stát příliš úspěšný tvůrce, ale pouze distributor nějakého řešení bez širšího použití.

Narazil jsem například na redakční systém, který vytvořil absolvent jedné technické vysoké školy v Praze, který prodával za 15 tisíc korun. Tato webová aplikace vypadala zajímavě, ale měla jeden problém. Dalo se do ní dostat, aniž by bylo potřeba vlastnit uživatelský účet. Daný uživatel si nasbíral nějaké znalosti, ale redakční systém ani správně neošetřil a teď se českým internetem prohánějí o tomto redakčním systému informace o jeho nedůvěryhodnosti a některé weby běžící na tomto systému začínají mít problémy (z venku).

Jak si tak projíždím různé magazíny a sleduji vývoj webových technologií nebo knihoven, stále se objevují nové a zajímavé věci, které jistě stojí za použití a přidávají do webových aplikací nevšední prvky. Takové aplikace se pak také dobře používají a lidé se k nim často vrací. Nejsou s nimi, pokud jsou dobře udělané, ani žádné větší problémy.

Webová platforma je značně náročná

Dříve jsem zkoušel i desktopové aplikace, které jsem pak dával na zkoušku tehdejším spolužákům. A dostával jsem odpovědi, co by se třeba mohlo upravit, co přidat a co např. odebrat. Vlastně takový feedback od uživatelů. To je samozřejmě naprosto běžná věc. Stačilo akorát dodat novou verzi, ale protože to běželo na jednom operačním systému, nebylo potřeba si hrát s uživatelským rozhraním, přidávat různé efekty, zajímat se nějak hlouběji o možnosti narušení aplikace, apod.

Na webu je to ale značně odlišné. Kód aplikací může být z větší části dostupný na pohled všem návštěvníkům a kód běží na serveru, kam se může někdo kouknout. Proto mě třeba i zaráží, že občas na Twitteru zachytím tweet o skvělých JavaScriptových knihovnách pro MD5 nebo SHA1 hashování přímo v JavaScriptu. A věřím tomu, že jsou lidé schopní podobné „knihovny“ ve svých aplikacích použít.

Pro web je právě také důležité stále sledovat trendy, novinky a možnosti. O webu se na webu přece hovoří hodně a je zde plno zajímavých názorů obrovské internetové komunity. Je možné tak najít zajímavé řešení nebo nástroj, který by mohl pomoci při tvorbě zajímavé webové aplikace. Chce to ale odhodlání naučit se něco nového. A hlavně, podobné věci používat a pochopit hlavní smysl. Často se můžeme setkat s tím, že si někdo někde stáhne nějakou knihovnu, použije řešení z examples a pokud s danou knihovnou nastane problém, není schopen jej ošetřit.

Často se může i stát, že přijde „neočekávaný“ uživatel, který způsobí neočekávaný požadavek. U některých webových aplikací jsem se setkal i s tím, že vývojáři přemýšleli pouze jako psavci kódu (nepřemýšleli jako vývojáři, ale ani jako uživatelé). Že se například může kód přepsat v adresové řádce a může tak nastat neočekávaný požadavek, který může něco způsobit (např. že se vývojář nezabýval nutností ošetřovat aplikaci proti SQL injection).

Webovou aplikaci je také nutné rychlým způsobem dopravit ke svému uživateli. Na desktopu je to přeci poměrně snadné. Vyvinu nějaký program, ten se nahraje do operační paměti a díky rychlému hardware se s ním pak pracuje rychle a odezva je takřka okamžitá. Ale co s webovou aplikací, která je dostupná online a je k ní potřeba připojení k Internetu. Co když uživatel nebude mít dostatečně rychlý internet? Máme se na takového uživatele vykašlat a nechat ho čekat? Nebo udělat vše pro to, aby se aplikace nahrávala co nejrychleji každému uživateli? Na to se také často zapomíná a může to být problém (např. i vzhledem k trafficu). Můžeme se pak také dostat na webové stránky, které se načítají i několik sekund a to je to většinou pseudodynamická stránka typu blog nebo osobní prezentace.

Často může vyvstat dilema, zda můžeme nějakou technologii. Například zde bude mít zapnutý JavaScript (dnes je to kolem 95%), zda bude mít prohlížeč podporující HTML5, CSS3 a nebo bude mít nainstalovaný nějaký softwarový doplněk.

Všechno jde, když se chce

Chtěl jsem se v tomto článku zamyslet nad tím, kde můžou vznikat základní problémy v aplikacích. Většinou to je v nedostatečné informovanosti nebo špatném přístupu samotných tvůrců aplikací. Často rád říkám, že není problém v aplikacích, ale v lidech (buď v těch co jí stvořili, nebo v těch, co jí používají).

Pokud by se webový vývojáři více zaměřili na svůj obor a více sledovali aktuální možnosti své platformy, sice by tomu věnovali poměrně značné množství času, ale v budoucnu by z toho mohli i více profitovat. Nemuseli by pak porušovat např. licenční podmínky redakčního systému WordPress odmázáním všech informací vztahujících se k tomuto systému a následné distribuci za 20 tisíc korun.

Komentáře

  1. Ono je to také o způsobu, jakým to kdo dělá. Pokud někdo za nakódování webu požaduje 2tis Kč, tak tyto věci opravdu neřeší. Takže ve výsledku je nutné buď dělat stránku „pro sebe“ a nebo dát vyšší cenu, což ale většina lidí nezaplatí, když jim stejný výsledek zařídí Franta za 1/3 cenu…

  2. Daniel Máslo: no protože je kód v JavaScriptu transparentní. Pokud jej minimizuješ, stejně řekneš algoritmus, kterým se to hashuje a takovédle věci by měli být umístěné na serveru. Pokud se projede obfuskátorem, dá se najít deobfuskátor, který jej převede zpět. A proč říkat, jak schraňuješ svoje data?

    Radek: určitě máš pravdu. Ale proč pak takový klient nadává na práci webových vývojářů obecně, když mu to Franta udělal za babku. Jsou ale i ti, co to udělají za dost peněz a stejně to stojí za starou bačkoru. Jak říkáš ty i já v článku, je to o přístupu (způsobu).

  3. Princip MD5 nebo SHA1 je veřejně známý, tam nemá cenu něco skrývat. Přijde mi fajn hashovat některé věci přímo na vrstvě klienta. Co se pak s hashem děje na serveru už nikdo neví. Není nad kombinace md5(sha1(md5($var)));

  4. Daniel Máslo: myslel jsem jako obecně něco hashovat na straně klienta. To, že někdo používá pro hashování již dávno prolomené MD5 je věc druhá (SHA1 snad zatím prolomena nebyla, ale jsou pro tento algoritmus obsáhlé rainbow tables). Já osobně nejsem zástánce několikanásobného hashování. Co je podle tebe dobré hashovat už na straně klienta?

  5. MD5 a SHA1 na straně klienta je obecně špatný a JS zvlášť.
    Šíření blbostí by mělo být napravováno na mučidlech.

  6. Rainbow tables tu jsou, ale na vícenásobném hashi pohoří. Když už tedy někdo hashuje bez saltu.

    V prostředí bez SSL mi přijde hashování hesla na straně klienta docela vhodné.

Napsat komentář