Něco o mě – znalosti a dovednosti – programátor a webový analytik

Weby a PHP

S weby jsem začal experimentovat již na vyšší odborné škole, nějakých 20 let zpátky. Tehdy to byly sice jen takové testování, jak to funguje a díky tomu, že vývoj vysokorychlostního internetu byl ještě v plenách, tak s připojením na internet přes modem byly možnosti z části omezené.

Ze začátku jsem testoval různé technologie, PHP, .NET, JAVA a k tomu přidružené technologie, jako javascript, css, atd. Zjišťoval jsem, co jaká technologie nabízí a v čem budu dále pracovat a rozvíjet své zkušenosti a dovednosti.

Již v té době, řekněme po 2 letech zkoušení, jsem si našel první zakázku – vytvoření objednávkového systému pro nákup CD disků pro jednoho vokalistu, který si svá CD sám nahrával a sám vydával. Zakázka celkem za 3000,- (pro studenta dost peněz pro začátek) obsahovala nákup na internetových stránkách s možností platby bankovní kartou a jednoduchou administrací. Byla napsána v PHP za použití jednoduchého javascriptu a dnes již zastaralého vkládání designových značek přímo do kodu HTML (tedy bez CSS).

Předtím neexistovaly žádné platební systémy, jako GoPay, či PayU. Vše se muselo projednávat s bankou (tuším s Českou spořitelnou) a napojení bylo přes, v tu dobu, nové API 3D Secure.

Tato zakázka se vydařila a zároveň byla pro mě odrazovým můstkem v PHP. Od té doby pracuji výhradně v PHP.

Nette

S Nette jsem přišel do styku nedávno, asi tak před 6-sti lety, kdy se rozhodovalo, na čem se bude stavět nové jádro eshopu pro firmu, ve které jsem pracoval. Zajistil jsem si školení přímo u profesora Nette Davida Grudla, kde jsem teprve poznal kouzlo Nette frameworku a od té doby experimentuji s jeho nasazením všude, kde je to jen možné. Ještě nyní se mi někdy zdá, že je to až moc “magic” a některé metody úplně nechápu, ale je to přirozený vývoj a mám takový pocit, že i pan Profesor Grudl někdy tápe a zjišťuje, jak daná věc vlastně funguje.

Mým prvním výsledkem Nette eshopu je http://www.vyfuky-pema.cz . Zakázka, která byla mimo standardní pracovní proces, se vlivem mnoha změn trošičku protahovala a nakonec jsem práci odevzdal zdarma, neboť mým hlavním cílem bylo naučit se fungovat a zvládat první krůčky a nástrahy, které mě povedou k dokonalému vývoji webů v Nette frameworku. 

S Nette jsem pokračoval také v práci, kterou jsem vykonával pro firmu Religis, kde je na něm postaveno celé nové jádro e-shopů. Byl jsem u zrodu tohoto jádra, pomáhal jsem vymýšlet moduly a vůbec funkčnost celého systému. Celý systém má pak na starosti kolega, ale často jsem se k němu vracel a dodělávál k němu nové moduly.

Můj nový počin v eshopech na Nette je letos vytvořený soukromý projekt https://www.domaci-nakupy.cz. (projekt uzavřen, ale kody mohu ukázat).

Laravel

Asi 1 rok si hraju s tímto skvělým frameworkem, v Moraviu jsme na něm vytvořili několik webů a informačních systémů. Jeví se mi daleko lepší, než Nette a to díky široké dokumentaci a také mnoha uživatelů tohoto frameworku – daleko lépe se hledají případné moduly a rozšíření.

Docker

Výborná technologie, která dala základ tomu, že se již nemusí pokaždé nastavovat localhost na spuštění projektu. Stačí si jej pullnout z Gitu, nastartovat Docker a může se testovat, programovat, prostě cokoliv. Samozřejmě je nutné jej nejprve pro daný projekt nastavit, ale již jsem jich dělal tolik, že to dnes již není žádný problém.

Dockerem jsem se začal zabývat tak před 2- mi lety, od té doby mě jej používám pro každý projekt, který vytvářím.

Databáze – Mysql

Kde by byl vývoj PHP, kdyby nebylo pořádného a rychlého databázového enginu, jako je MySQL. Jasně, je to v celku jednoduchá databáze, oproti například Oracle, či PostgreSql, ale pro weby absolutně vyhovující. Tak, jako jsem se zabýval PHP, tak jsem se i zabýval MySQL. Jsem zručný ve vytváření i složitých dotazů s výbornou indexací a tedy i rychlostí. Často důmám nad dotazama a zjišťuji, jakým způsobem by šlo dotaz předělat tak, aby byl ještě o malinko rychlejší. Obecně totiž zjišťuji, že MySQL má největší podíl na rychlosti jak stránek, tak hlavně i serveru jako takového (ono to jde krásně vidět na vytíženém serveru, kdy proces mysql zabírá na 6 procesorů a např. Apache s PHP sotva procesor jeden).

Čím lépe jsou dotazy vytvořeny, tím rychleji fungují stránky (i když jsou používány různé keše, tak databázové dotazy musí běhat rychle) a server obecně dokáže přijímat více požadavků.

Ze začátku jsem pracoval pouze s enginem MyISAM, nyní již vše řeším s INNODB a plně využívám jeho potenciálu na poli cizích klíčů a zamykání řádků namísto celé tabulky. Nyní, když od verze 5.6 je možné v INNODB vytvořit fulltext (který jsem předtím řešil krkolomně přes jinou tabulku v MyISAM), je možné již zcela zavrhnout zastaralý engine MyISAM.

Apache

Webový server Apache je samozřejmou součásti mého webového vývoje. Snad jednou jsem zkoušel i IIS (informační internetovou službu systému Windows), bleskurychle jsem přešel zpět na Apache, který je, dle mého názoru, o mnoho jednodušší a navíc jej využívá většina serverů na světě. 

Zkušenosti s rozběháním a nastavením běhu serveru mám dlouholeté, i když mě vlastně stačí znát jen pár konfiguračních direktiv, které nutně potřebuji pro nastavení funkčnosti Apache a PHP. Další moduly Apache, pokud jsou potřeba pro funkčnost webu, vetšinou řeším nakouknutím do dokumentace a testováním uvedených příkladů.

Důležitou součástí webového serveru je možnost přesměrování webové stránky na jinou, kterou Apache řeší modulem mod_rewrite, který často využívám pro přesměrování například pěkných URL adres a nebo pro vytváření obrázkové keše.

Dalším modulem, který využívám, je mod_headers, kterým dokáži automaticky posílat hlavičky pro nakešování požadavků na straně klienta dle typu souboru.

NGINX

I když pro přímý přístup na web používám Apache, tak Nginx mi slouží jako proxy a to i mezi https a http na lokálním serveru. Nginx mám také spuštěn na lokálním developerském počítači a přes něj se snadněji napojuji na spuštěné dockery. Základní nastavení nginxu umím provést i pro weby, ale zřídka kdy jej použiji.

Javascript

Tak jako jsem spjatý s PHP na straně serveru, tak stejně využívám i možnosti JavaScriptu na straně klienta. Vlastně celou svou administraci pro https://www.nakupy-detem.cz se snažím vytvářet tak, aby byla co nejkomfortnější pro administrátory a tím pádem se bez Javascriptu, a hlavně JQUERY knihovny, neobejdu.

Často využívám knihovny třetích stran, jako fancybox (pro vyskakovací okna), nebo Caroufredsel (pro pěkné posuvníky obsahu), tak i základní knihovnu pro JQUERY – UI pro lepší vzhled a funkčnost webu.

A co AJAX (nebo raději AJAJ?). Ano, i toto je mým denním chlebem. Snad vše, co lze, provádím nyní AJAXem a to jak v administraci, tak i na frontové části webů. Vlastně Nette s AJAXem pracuje velmi dobře, proto jej mám rád a často jej využívám.

Dalším mým přáním je vyzkoušet si Web Sockets – ale prozatím jsem nenašel vhodný projekt, na kterém by to mělo smysl dělat.

ReactJS

Je to necelý 1 rok, co jsem s tímto skvostem přišel do styku a hned na to naprogramoval (tedy byl jsem součástí týmu) počasí pro jeden portál (pocasi.centrum.cz). Od té doby jsem udělal ještě asi 3 aplikace (například interní aplikace pro kontrolu strojů v hale) a dnes, kdy pracuji na redesignu svého eshopu nakupy-detem.cz, ho používám taktéž.

V rámci reaktu zvládám jak react samotný, tak i se spojením s Reduxem či React Routerem.

Fulltextové enginy – elastic search a Sphinx

S těmito fulltextovými enginy jsem se již setkal dávno a s oběma nadále experimentuji.

Sphinx se mi zdá trošičku horší na konfiguraci, kdy indexy je nutné zadávat do konfiguračního souboru a poté engine restartovat. Kdežto elastic search dovoluje vkládat index pěkně za chodu.

Oba enginy se ukázaly jako velmi rychlé a dobře tak nahrazují MySQL fulltext. Navíc díky použití těchto enginu klesá zátěž na databázi, která je na produkčních serverech velmi vytížená.

Co se týká experimentace ohledně fulltextových filtrů a možností – já jsem si prozatím vždy vystačil se základy. Prozatím jsem se nemusel pouštět do složitějších dotazů na fulltextové enginy tak, aby mi vyhazovaly „zvláštní“ výsledky, vždy mi stačily jednoduché dotazy, které mi ve výsledku vracely Idečka, které jsem obratem poslal do databáze.

Linux a server obecně

V Religisu jsem měl na na starost chod všech serverů, i když byly menežované, tak je nutné zajistit a hlídat jejich chod a v případě přetěžování z jakéhokoliv důvodu, najít příčinu a snažit se o co nejrychlejší odstranění příčiny pomalosti serveru. K tomu mi pomáhá znalost základních příkazů Linuxu a často pracuji v SSH přimo na serverech.

Někdy je nutné přenést weby ze serveru na server, což je pro mě již rutinní záležitost (včetně přenostu databáze, DNS záznamů a přenos případných emailů). Dále, zakládání FTP účtů, vytváření databází v MySQL, či jiné přímo serverově věci mi nejsou v žádném případě cizí.

Mimo to mám vlastní server, který je menežovaný a umístěn u firmy VSHOSTING. I když veškeré služby spojene s instalací serveru, či softwaru na něj, provádí zmíněný VSHOSTING a jeho administrátoři, i já často chodím na server přes SSH a pracuji přímo tam. 

S tímto souvisí i správa certifikátu. Spravuji server, který není menežovaný a všechno si tedy musím obstarávat sám, včetně přidávání certifikátu. Proto mám i s tímto zkušenosti. Navíc si spravuji i vlastní certifikáty pro mé soukromé eshopy, takže nákup, vytvoření a použití certifikátů pro zapnutí HTTPS na webu je maličkostí.

Nyní, co mám Ubuntu na svém vývojovém notebooku, tak je nyní používaní linuxu hračkou, i když někdy nastavení opravdu bolí, vždy pomůže Stackoverflow.

Navíc, jelikož používám pro develop Docker, tak základem každého dockeru je správné nastavení běhového prostředí a to právě v linuxu za použití i některých skriptů psaných v SH.

Verzovací systémy – Git (svn)

Bez verzovacího systému se nedá vyvíjet, to je přece jasné. SVN jsem používal dříve v začátcích, avšak jeho nutnost být neustále napojen na Internet, když chci něco commitnout, mě přinutila začít používat GIT. A dobře jsem udělal, rychlý, bezpečný, perfektní. Díky tomu se vývoj v mém působišti mnohonásobně zpřesnil a zrychlil, jelikož nemusíme řešit věci jako “Kdo to smazal z toho kodu?”. Já jsem si na něj navykl tak, že když si zakládám nějakou složku, kde si budu jen psát třeba jen nějaké zápisky z výletu, tak ihned ji dávám do GITu.

Pro své projekty navíc používám službu www.bitbucket.com – takže vše mám ihned všechny kody z jakéhokoliv místa k dispozici.

Jen poznámka pro mne: trošku mě mrzí, že jsem si ještě nepřivykl používat funkci Stash – možná  někdy konečně na to najdu důvod …..

Styly – CSS

Pro své projekty si sám vytvářím HTML šablony (ne grafiku, tu přenechávám grafikovi), proto vím a umím používat CSS. Také se snažím nalézat rozdíly v prohlížečích ( i když např. IE verze nižší než 9 statečně ignoruji) a přizpůsobit tak web všem. Rovněž  mám nemalé zkušenosti s vytvářením responzivních webů.

CSS jako takové se mi jeví nějak moc neohrabané, proto raději používám jazyk SASS (http://sass-lang.com/) což je software, napsaný v RUBY, který zavádí lepší organizaci a psaní souborů CSS a zpříjemňuje tak práci se styly.

Ruckus

Tak jako pro zdrojové soubory existuje GIT (nebo SVN), pro databáze existuje Ruckus.

Jde o verzovací nástroj pro databázi, napsaný v PHP, a používá se hlavně pro práci v kolektivu a hlavně pro Deploy projektů. I když jej pro své soukromé projekty nepoužívám (na projektech pracuji pouze já, takže prozatím nemám důvod jej použít), tak ve firemním prostředí je shledávám velmi účinným řešením databázových verzí projektu. Jelikož jsou soubory pro vytvoření, změny databáze uložené v souborech, tak spolu s využitím verzovacího nástroje (GIT či SVN) je pak zaručena určitá bezpečnost a rychlost vývoje projektu v týmu v oblasti změn v databázi.

Testy – testování softwaru

Testování jsem pro sebe zavedl celkem nedávno. Již kdysi jsem testoval za pomocí PHPUnitu, ale až s příchodem Nette testeru jsem se testování naučil mnohem líp. I když zase, své soukromé projekty ještě pod testem nemám (kde vzít na to čas, že?), ale nové projekty, které vytvářím, se již snažím vždy testovat a to za pomocí právě zmíněného Nette testeru.

Ještě mám v hledáčku testování přímo ve vebovém prohlížeči za podpory Selenium testů, také jsem zkoušel, dokonce i některé testy mám vytvořeny pro projekt www.nakupy-detem.cz, ale bojím se, že již jsou testy zastaralé a nefunkční. Mám však v plánu se k nim co možná nejdříve vrátit.

Další znalosti na poli pozice programátora webových projektů:

Souhrně zde uvedu další mé znalosti, které snad nepotřebují širší popis.

– správa DNS – mám vlastní stránky, proto si také sám spravuji k nim DNS

– hardware počítačů – každý správný ajťák si musí umět vytvořit svůj vlastní počítač (samozřejmě ze zakoupených komponent)

– nastavení routerů a síťových služeb – znám problematiku, starám se o síť ve firmě + o domácí routery

– znalostí produktů Atlasianu – Jira, bamboo, wiki, …  – např. přes Bamboo ve firmě deployujeme všechny projekty – výborný software.

– Photoshop – na stříhání grafiky a občasné vytváření bannerů apod.

Analýza

V nadpisu píšu „Programátor a webový analytik“, co to pro mě vlastně ta analýza znamená?

Před tím, než vůbec začnu cokoliv psát, si musím dobře rozmyslet, jakým způsobem kód povedu, jaké jsou případné překážky, zádrhele, jaké k tomu potřebují další nástroje. To všechno musím analyzovat a snažit se najít všechny možné problémy a nedostatky, které daná specifikace/projekt obsahuje.

Z minulosti vím, že se ne úplně na 100% dají předpovídat všechny problémy, které při vývoji mohou nastat, ale z analýzy vyplynou ty hlavní a důležité věci, na které si dát pozor a kterým se bezprostředně při realizaci vyhnout. Z těchto analýz také v závěru vzniká kalkulace a nacenění zadané práce.

autocomplete=”off” – firefox již nepodporuje, jak to obejít?

Firefox od nějaké novější verze již nepodporuje u inputu autocomplete=”off”. Někdy je však zapotřebí, aby prohlížeč automaticky nedoplňoval data do políčka ze svojí cache paměti. Jednak je to zapotřebí u políček pro zadání hesla, kdy nechceme aby se hesla automaticky doplňovala (a tím pádem každý, kdo má přístup k tomuto počítači, aby se jednoduše nedostal tam, kde nemá co dělat) a také u určitých formulářů, kdy po odesílání a následném redirektu zpět na formulář nechceme, aby byly hodnoty v inputu stejné, jako byly před odesláním na server.

Existuje však jednoduchá pomoc, vytvořil jsem tento skript, který právě autocomplete=”off” plně nahrazuje ( a funguje ve všech prohlížečích stejně – za předpokladu, že existuje knihovna JQUERY):

$( document).ready(function () {

$(‘input[type=”password”][autocomplete=”off”]’). each(function () {

var $this = this ;

$ (‘<input>’ ).attr({
type : ‘password’
}) .keyup (function () {
$(
$this). val($(this).val());
}) .insertAfter( this);

$ (this ).hide() ;
});

});


Tento skript funguje na políčko pro heslo, ale asi již pro vyvojáře nebude problém ho předělat na jakýkoliv input, kde je potřeba vypnout autocomplete.

Záhada s MySQL, kdo ji rozluští?

Nyní jsem strávil asi 3 hodiny hledáním chyby v jádru systému pro eshopy, kdy nakonec oprava (jak už to tak bývá) zabere jen nějakých pár sekund dopsáním jednoho řádku kódu. Takže kde byl problém?

Mějme dotaz do DB:

SELECT `id`
FROM `product`
WHERE (`id` IN (2, 30, 5403, 11640, 11652, 11642, 11653, 12421, 11641, 12404, 12392, 12400, 11654,
12394, 11643, 12405, 9841, 12401, 11656, 12393, 11645, 12407, 11666, 12403, 11655, 12396, 11644,
12406, 12399, 12402, 11657, 12397, 11646, 12398, 11647, 12395, 11650, 11663, 11648, 11664, 11649,
11665, 11651, 12244, 984, 985, 983, 986, 5754, 5753, 3340, 5404, 2781, 1966, 2782, 401, 2806, 1967,
2780, 400, 2807, 3561, 3562, 981, 982, 12667) AND `state` = ‘enabled’ AND `price_vat` > 0)
ORDER BY `php_price_display` DESC, `price_vat` DESC

Jehož výsledkem je (kupodivu):

12244,2,2806,2807,3340,3561,3562,5403,5404,5753,5754,12667,2782,2781,2780,400,401,981,982,983,984,985,986,1966,1967,30,11649,11651,12399,11666,12398,11648,11647,11650,11646,11657,11656,11645,12397,12421,11655,11644,12393,11665,11654,11643,12396,11642,9841,12395,12407,12403,12402,12406,12394,11664,11653,11641,11663,12401,12405,11652,11640,12392,12400,12404,

Ok, na tom asi není nic zvláštního, dobře dále, přidejme k dotazu:

LIMIT 6

a jaký teď dostaneme výsledek??? No přece takový:

12244,2,400,12667,981,982,

Pro ty co nechápou, oč se jedná. Druhý výsledek totiž vůbec nekopíruje výsledek první (od čísla 2 jsou výsledky jinak, než v prvním případě), přitom jsem jen databázi řekl, ať mi z celého výsledku zobrazí jen 6 čísel. Nic víc. No, tuhle chybu v systému nalézt, to byl fakt oříšek. A já blbec prolézal všechny možné napojené moduly, submoduly, porovnával sortovací mechanizmy a nakonec z toho výjde takováhle blbost.

Aby záhada byla kompletní, přídám k dotazu ještě:

OFFSET 12

a jaký je výsledek teď?

12244,2,400,12667,981,982,

ano, vidíte správně. Výsledek je stejný jako dotaz bez OFFSETu. Proto jsme taky na chybu přišli, najednou nám totiž stránkování v systému vyhazovalo stejné výrobky na jiných stránkách.
Ok, teď otázka pro Vás, jakým způsobem tento nešvar MySQL opravíme??? (ne že bych nevěděl, už to opravené mám, jen by mě zajímalo, jak jste si s tím poradili vy)
Omlouvám se zároveň těm, co tohle znají a mají mě za nevzdělaného hňupa – na mou obranu, chybama se člověk učí. Ještě se mi to nikdy nestalo a do budoucna si už na tento nesmysl dám určitě pozor!!!

Přechod webu na SSL

Moje první nasazování SSL jsem rozepsal v mém předchozím článku, nyní, již trošku poučený s chyb, jsem nasazoval SSL certifikát na náš e-shop www.nakupy-detem.cz. Vlastně jsem tento web musel přenést z jednoho serveru na druhý, když už jsem byl u takových změn, tak jsem se rozhodl o větší změnu a zabezpečit tak stránky před “šmejdama” na internetu.

Zásadní otázka: Proč implementovat SSL?

Internet je spojení počítačů ať již kabelem, nebo dnes “bezkabelově” a nikdy nevíte, který “parchant” se dokáže hecknout do Vašeho routeru, nebo na síť spojující Vás a ISP, nebo nedejbože přímo do počítače ISP (Internet Service Provider) přes kterého jste do sítě internet napojeni. Tímto dokáže útočník celkem v pohodě odposlouchávat síť a tím tak získávat data ohledně všech přenosů, které uživatelé na internetu uskuteční. Tak například, chcete snad vědět, jakou pizzu si soused objednává? Není problém, připojte se na jeho router a jelikož jeho oblíbená pizzerie zřejmě nebude mít zabezpečené připojení přes SSL, tak v klidu zjistíte, jakou pizzu si objednal. Ba co víc, díky tomuto spojení není problém mu objednávku změnit a objednat mu na jeho jméno, pod jeho účtem, nějakou pizzu, avšak s dovozem na Vaši adresu.

Jak tomu zamezit? Stačí, aby sousedovic oblíbená pizzerie instalovala na svůj web SSL certifikát a tím by zajistila přenos všech informací šifrovaně. Ano, vy by jste to sice odposlechli, ale místo “heslo: aaa” by se vám objevilo něco jako “lkjls515dafk lkds” – prostě kódováná zpráva, která nejde ničím rozkodovat.

Toto je pouze názorný příklad, banalita s objednáváním pizzy, ale co kdybychom toto udělali s jeho oblíbenou bankou? Tady už je situace jiná. (i když banky již mají šifrované připojení, ale né všechny jsou úplně bezpečné viz. výzkum odborníka na webovou bezpečnost Michala Špačka – Banks & HTTPS in the Czech Republic 2015-03-18)

Na eshopu nakupy-detem.cz zadávají zákazníci (pro někoho) citlivé informace, jako adresu a své jméno, později přibude na webu možnost se zaregistrovat a využívat více možností nákupu výrobků. Tam se samozřejmě budou přihlašovat svým jménem a heslem a pokud by tyto důležité informace nebyly dostatečně zabezpečeny, mohlo by rychle dojit k jejich zcizení a nemalým problémům jak ze strany zákazníka, tak samozřejmě ze straný nás, jako provozovatele obchodu. Zabezpečení stránek certifikátem je tedy jasná a správná volba.

Získání SSL certifikátu a jeho nasazení

Je důležité si nejprve rozmyslet, které domény (subdomény) chci zabezpečit. Pro zabezpečení našeho webu potřebuji ochránit celkem 3 subdomény (nakupy-detem.cz, www.nakupy-detem.cz, a administrační část webu).
K tomu jsem si opatřil certifikát, který je právě pro tři domény. Wildcard by byl taky vhodný, ale zbytečně dražší (navíc implementace je těžší a někdy to nefunguje, jak má, viz. můj minulý článek)
Po získání certifikátu pak stačilo jej poslat kolegům ze server hostingu, aby jej nasadili.

Přechod webu na SSL

U webu jako takového je nutné změnit všechny absolutní vnitřní odkazy, aby směřovaly na HTTPS. Pokud je web, či eshop, postaven na nějakém frameworku, tak většinou stačí jen změnit někde v konfiguraci hlavní url webu (baseUrl), některé frameworky si to i samy detekují a automaticky všechny odkazy k tomu přizpůsobí. Důležité je věnovat pozornost informačním stránkám (vlastně všem místům na stránce, kde se obsah negeneruje, ale je dodáván manuálně, např. wysiwyg editorem v administraci), tam je nutné tyto odkazy buď manuálně změnit, nebo všechny tyto texty prohnat nějakým skriptíkem/filtrem.

Poté je důležité nastavit web tak, aby veškerou komunikaci automaticky směroval na HTTPS. V htaccess souboru se to dělá těmito dvěmi řádky:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  [R=301,L]

Problémy s obrázky:

Standardně s obrázky při přechodu webu na SSL nejsou problémy, ovšem na webu nakupy-detem.cz jsem pro optimalizaci kdysi udělal to, že se obrázky stahovaly z různých subdomén (např. img1.nakupy-detem.cz, img12.nakupy-detem.cz0). Tím se standardně obchází maximální počet souběžných připojení prohlížeče na jednu doménu (různé prohlížeče mají různě nastavené omezení, např. Firefox má max 6 souběžných připojení, Internet Explorer verze 10 jich má 8). Problém však nastal, kdy díky certifikátu, který je vystaven pouze na 3 subdomény, toto jaksi přestalo fungovat a prohlížeč odmítal zobrazit obrázky, které přišly z neznámého zdroje. Na subdoméně img2.nakupy-detem.cz vystavený certifikát není, a když se prohlížeč snaží tuto sobdoménu kontaktovat, tak dostane sice certifikát, ale který není ověřený u centrální autority (tzv. self signed) a tím pádem se standardně odmítne ke zdroji připojit. Nyní jsem celkem litoval, že jsem si nezakoupil Wildcard certifikát. Jediný způsob, jak se toho zbavit, bylo odstranění této “subdoménovsko obrázkové” funkčnosti.

Co na to vyhledávače?

Implementováním SSL na web se změnila adresa webu a to na https://www.nakupy-detem.cz. Tohle vyhledávače jako google, či seznam, berou jako úplně novou adresu, avšak díky přesměrování pomocí hlavičky 301 vezmou vyhledávače adresy rychle zpět do svých indexů. Teoreticky by se přechod na tyto nové adresy neměl dotknout pozic ve vyhledávačích, ba co více, google prý hodnotí zabezpečené weby lépe.
Po 12 dnech, co web jede na SSL, jsem v google analytics zaznamenal mírné zvýšení návštěvnosti. Samozřejmě je ještě brzo na nějaké závěry, navíc to může být i jinými okolnostmi. Důležité však je, že žádné snížení návštěvnosti se nekoná.
Jediný problém je pouze v google web masters tools, který okamžitě zaznamenal pokles indexovaných stránek. Je to celkem logické, google bere web s HTTPS jako novou doménu a tudíž už starou neindexuje. Je tedy nutno v toolsech založit nový web s doménou HTTPS. Tam lze již vidět, že to, co verze HTTP ztratila v indexu, to HTTPS nabrala.

Přechod na SSL aneb jakých chyb by jste se dopouštět neměli

Hodně se dnes mluví o bezpečnosti a o zabezpečení zadávaných informací na web, ať již před útočníky v podobě různých hackrů, znuzených studentíků ajťáků, tak i před výzvědnými službami, jako např. ochrana před CIA či NSA. Nedávno, při auditu zabezpečení ve firmě bylo rozhodnuto, že se musí zabezpečit pomocí SSL přístupy na důležité weby v rámci firmy a k tomu i subdomény, na kterých provozujeme demo internetového obchodu. Toto demo se vždy vytváří jako subdoména k demo.firma.cz, tedy například zidle.demo.firma.cz.

Úkol tedy zněl jasně. Zabezpečit firma.cz, ale zároveň i demo.firma.cz ale i např. prodejzidli.demo.firma.cz Jelikož počet subdomén je v tomto případě nekonečný, bylo nutno vytvořit tzv. wildcard certifikát. Pro pořádek jen připomenu druhy certifkátů, které pro zabezpečení webů existují:

standardní SSL certifikát
– je nejlevnější a zajišťuje ověřený certifikát pro jednu doménu, zde nutno připomenout, že doména domena.cz je něco jiného, než www.domena.cz. Pro zabezpečení obou domén je tedy zapotřebí dvou těchto standardních certifikátů

certifikát s podporou SAN

– jsou standardní certifikáty, ale je zde možnost na jeden certifikát mít zabezpečeno více domén (na webech se uvádí až 99, ale myslím, že je to neomezené)

– tento certifikát je pochopitelně o něco dražší i v závislosti na zvolené variantě počtu domén, na které se aplikuje

certifikát wildcard

– speciální druh certifikátu, který zabezpečuje jak doménu samotnou, tak i její subdomény. Doména se v tomto případě do certifikátu vkládá jako např: *.domena.cz

– hodí se na domény, u kterých vzniká mnoho subdomén a přesně nevíme jejich počet

Takže, jak jsem postupoval a jakých chyb jsem se dopustil?

Již nějakou dobu hlavní web firmy běžel na HTTPS pod svým vlatním certifikátem. Já jsem jej však chtěl rozšířit tak, aby fungoval i na ostatní subdomény. Proto jsem úplně na začátku musel vytvořit nový certifikát.

Na internetu je hodně obchodů nabízejících certifikáty, mě se líbily stránky ssls.cz, jelikož mají podporu mnoha certifikátů od pár stovek korun až do několika tisíců. Já si vybrál nějakej wildcard něco kolem tisícovky (ono je celkem jedno jaký, pokud vyloženě nechci mít zelený proužek v adresním řádku prohlížeče, to jsou pak za certifikáty vyšší sumy). Po nákupu je nutno přejít k výrobě takového certifikátu. Stránky jsou celkem přehledné a nabízejí jednoduché vytvoření privátního klíče a CSR žádost, který je potřebný pro žádost o podepsání certifikátu CA autoritou.

Již při vytváření těchto dvou klíčů je nutné zadat doménu, pro kterou se certifikát tvoří. Já tam dal “*.firma.cz”, tím jsem pevně doufal, že tím se certifikát bude používat i pro test.demo.firma.cz. No, ale o tom dále. Po podepsání certifikátu jsem vše zaslal na server hosting, a oni jej přidělili na stránku firma.cz a zároveň pro demo.firma.cz.

Vše tedy běhalo normálně, firma.cz běžela pod https, demo.firma.cz běžela pod https, ale když jsem přešel s prohlížečem na stránku test.demo.firma.cz tak mi vyběhla ta ošklivá stránka upozorňující mě na to, že mě zřejmě chce někdo hacknout a přihlásit mě na stránku, kterou systém nezná (však to znáte, takové to RADĚJI TO HNED ZAVŘI, BO PŘÍJDEŠ O DATA!!!!)

Chyba číslo 1. – nesprávné pochopení wildcard certifikátu:

Aha, a tady je kámen úrazu. Nikde jsem si totiž nepřečetl, že wildcard certifikát funguje pouze na přímé subdomény domény, na kterou je vystaven. Tedy na subdomény subdomény domény již nefunguje. Ono totiž všude se uvádí certifikát jako *.firma.cz a nějak logicky mi přislo, že je jedno kolik subdomén přidám za hvězdičku. Ale opak je pravdou.

No nic, moje chyba, měl jsem si zjistit více informací o tomto. No nevadí, na serveru uvádějí možnost vrácení peněz do 30 dnů, takže jsem je mailem požádal, aby certifikát zrušili a já si tak mohl vytvořit nový, s již správně zadanou doménou.

Chyba číslo 2. – certifikát zrušen bez náhradního:

Zrušení certifikátu proběhlo na mě až nezvykle rychle, což způsobilo, že firemní stránky přestaly fungovat. Je to celkem logické, najednou měly vypovězený certifikát a jiný tam nebyl. Oni totiž administrátoři serveru při zavádění nového certifikátu ten starý zrušili/smazali (což samozřejmě nebyla jejich chyba, prostě se domnívali, že již nebude potřeba). Asi Vám nemusím říkat, co se ve firmě dělo, když vypadla hlavní výloha firmy na webu. Najednou se všichni přiřítili, co se to jako děje, obchoďáci v terénu, co když se teď chlubí webem, co když zrovna teď nějaký zákazník brouzdá na firemním webu. NO PROSTĚ PRŮSER JAK MRAKY. Takže rychle, zavolat na serverhosting, poprosit je, ať tam ihned nahodí starý certifikát.


Chyba číslo 3. – někdy se vyplatí mít zalohované certifikáty na určitém místě:

Čekám, čeká, co tak dlouho na tom serveru dělají? Volám znovu, aha, oni ten starý certifikát hledají – v zálohách pry není. No dobře, jdu za kolegou, který jim před časem certifikát posílal. Kolega hledá v mailech, přeposílá nějaký privátní klíč, posílám webmasterům, čekám. Telefon, “Bohužel, ke klíči potřebujeme také certifikát, bez něho je nám privátní klíč na houby”. Aha, říkám si, vlastně jo. Jdu zase za kolegou, hledá v mailech vydané certifikáty, nějaké mi přeposílá, já posílám na server hosting a zase telefon: “klíče které jste poslal v mailu dříve se neshodují s vydaným certifikátem, který jste poslal nyní !!!!”. Kruci !!!! To už byla tak půlhodinka pryč, co firemní web pořád nejede. No dobře. Je třeba rázného řešení.

Chyba číslo 4. – přílišná horlivost se někdy nevyplácí

Jdu rychle na web pro nákup nového standardního certifikátu. Vybírám takový, u kterého uvádějí, že je automaticky s www i bez www. Ok, beru ho , platím, vytvářím klíče – do políčka pro doménu uvádím: “firma.cz”, vystavuji certifikát. Hmm, ale kde se zadává druhá doména? Tedy doména “www.firma.cz”? Nikde žádné políčko nevidím, asi to bude nějak automaticky…

Posílám webmasterum na hostingu a doufám, že jsem to stihl rychle, než zase někdo příjde, že web stále nejede. Zvoní telefon, na druhém konci zase webmaster: “Certifikát jsme na server instalovali, ovšem tento je určen jen pro doménu firma.cz, www.firma.cz nebude fungovat!!”. KRUCI!!!, Jak to, vždyť tam měli u nákupu napsáno, že bude fungovat i pro www…. No nic, není čas se zabývat drobnostma. Jdu zase rychle na web pro nákup již 3. certifikátu, vybírám stejný standardní certifikát, při vytváření klíčů pro doménu zadávám: www.firma.cz, vystavuji certifikát, posílám webmasterům a již se modlím, aby se web už konečně rozjel.

Blýská se na lepší časy:

Ok, hurá, web se rozjel, nyní již bez problému. Supr, nyní jsem měl konečně trochu času popřemýšlet, proč vlastně ten první (vlastně druhý) certifikát nefungoval pro www.firma.cz? S tímto dotazem se obracím emailem na stránky, kde jsem certifikát objednável. Odpověď přišla záhy, prý se musí do políčka uvést doména ve tvaru s WWW, poté se automaticky vystaví i pro bez WWW. Aha, ale proč to nemají nikde při výrobě certifikátu napsané? Asi proto, aby si lidé koupili certifikáty hned dva!!! No, teď už to vím, tak snad příště už to bude bez problému….

Po těchto zkušenostech musím konstatovat, že přidat šifrování na stránky není zas tak těžké, jen je třeba pamatovat na základní pravidla:

– wildcard certifikat (*.firma.cz) funguje pouze na první subdoménu, na ostatní v řadě již ne !!!!

– při zneplatňování certifikátu je nutné se postarat o to, aby stránky, které tento certifikát mají nainstalovaný, byly schopné provozu i bez něho!!!

– raději si někde bezpečně zalohovat vydané klíče a certifikáty, člověk nikdy neví, kdy je znovu bude potřebovat

– při vytváření standardního certifikátu zadat doménu ve tvaru “www.domena.cz”, automaticky se tak vytvoří certifikát i pro doménu “domena.cz”

– vše dělat pomalu s rozmyslem, při stresu vydá člověk, v mém případě, 2x více peněz za certifikáty, než je třeba

PS: firma.cz či domena.cz nejsou opravdové domény, jsou samozřejmě smyšlené a uvádím je zde jen jako příklad, ale to jste asi pochopili, tak jako by jste tohle PS nikdy nečetli, díky.


Zařízení ipad/iphone a použití :hover

Použití :hover pseudo classy je na dotykovém zařízení celkem pasé, jelikož nedokáži emulovat to, že přes element jen přejíždíme, ale nechceme na něj kliknout.

No jo, ale většina stránek s tímto CSS prvkem počítá a někdy se bez tohoto elementu nedá web ovládat, hlavně u takových,  které mají určité prvky schovány pod najetím kurzoru na určité místo na stránce (např. hover menu).

Apple si to na svých zařízeních vytvořil tak, že hover se snaží emulovat  a to tím, že pro aktivace se provádí kliknutím na element, tím se aktivuje hover efekt a po druhém kliknutí se hover efekt vytratí.

Problém nastává, pokud je hover efekt použit na A HREF elementy. Jelikož zde kliknutím aktivujeme pouze hover efekt, ale stránka zůstává pořád na stejné adrese a nepřesune nás na místo, na které odkazuje HREF. To se provede tzv. dvojklikem, tedy rychlejším dvojkliknutím na daný element.

U jistého projektu mi toto dělalo problém ve vyjíždějícím menu (hover menu). Stávalo se, že na vyjeté menu se na jednotlivé elementy nedá kliknout, a to ani dvojklikem. Nevím přesně, čím to je, snad nějaký hover v CSS, který toto zabraňuje. Nicméně jsem to vyřešil jednoduchým javascriptem:

$('.submenuContent-in a').live('touchend', function (e) {
  e.preventDefault();
  location.href = $(this).attr('href');
});

Nyní mi tlačítka funguji tak, jak mají a na desktop to nemá vliv, jelikož eventa TOUCHEND funguje pouze na dotykových zařízeních.

Více se o tomto problému dočtete třeba zde

Jquery – serializace elementů bez formu

Někdy je třeba serializovat prvky formulářů, které nejsou uvnitř tágu form. Například při vyskakovacím okně, kde všechno probíhá ajaxově a není třeba poutívat form, pouze jeho elementy input, select, atd.

Pokud použijeme příjaz $(element).serialize() na jiném elementu, než na form, dostaneme prázdný string, jak toto obejít?

Na webu jsem chvíli brouzdal a našel jsem toto:
function makeSerializable(elem) {
return $(elem).prop(‘elements’, $(‘*’, elem).addBack().get());
}

var element = $(this).closest(‘tr’);
serialized = makeSerializable(element).serialize();

Funguje bezvadně. Díky ti google vyhledávači….

Kontinuální výstup skriptu ve firefoxu

Každý, kdo pracuje s dlouhotrvájícími skripty ví, že pro lepší kontrolu, co se vlastně v pozadí děje, potřebuje kontinuální výstup. Já si kupříkladu co například 100 cyklů pošlu na výstup počet již zpracovaných položek. Tím si také kontroluji, že se skript nikde neseknul a krásně funguje.

Jelikož PHP používá pro svůj výstup buffer, je nutno pro kontinuální výstup použít funkci:

ob_implicit_flush(true);

Tím je zajištěno, že veškerý výstup skriptu je ihned předán na STDOUT.

U prohlížeče google chrome toto funguje bezvadně, ale pro svůj vývoj mám radši Firefox (má podle mě lepší debugovací nástroj – firebug) – jenže v tomto prohlížeči to nefunguje podle očekávání. Trošku jsem musel googlit a nakonec jsem nalezl způsob, jak přesvědčit firefox, aby ihned zobrazoval to, co mu pošlu. Stačí v kodu specifikovat kodování stránky:

header('Content-Type: text/html; charset=utf-8');

Jquery plugin qtip – ajax obsah

QTip je celkem dobrý plugin, který nahrazuje zobrazení TITLE u prohlížečů.  Použití je jednoduché:

$(‘.qtip’).qtip();  — tim nastavim p2kn0 TITLE zobrazení po najetí myší na všechny elementy, které mají CLASS=qtip

Nicméně jsem si dlouho nevěděl rady, jak udělat, aby se qtip aplikoval i na AJAXem nahraný obsah. Protože, když po nahrání obsahu znovu zavolám předešlý příkaz, tak qtip se aplikuje také na již qtipnuté prvky a následně zobrazuje u těchto prvků jakoby dva qtipy přilepené přes sebe.

V api u qtipu existuje příkaz “destroy”, který qtip z prvků zruší a logicky poté lze znovu volat příkaz na jejich znovu nabindování. Jenže qtip má takovou vlastnost, že při jeho spuštění si vytáhne z atributu tagu TITLE to, co má pak zobrazit ve svém okně a pak title smaže. Tedy, když znovu nabinduji qtip tak vlastně již nemají co zobrazit, protože je TITLE prázdné.

Řešení je celkem jednoduché:

$(document).ready(function () {
qtipAll();
});

function qtipAll()
{
$(‘.qtip’).each(function () {
var title = $(this).attr(‘title’);
if ($(this).hasClass(‘qtipAlready’)) return true;

$(this).qtip({text:title, style:”cream”, position: {
corner: {
target: ‘bottomRight’

}
}});
$(this).addClass(‘qtipAlready’);
});

}

Hádanka pro programátory PHP

Jaký je rozdíl mezi těmito obrázky?

Odpověď je:  jiný server

(samozřejmě taky jiný prohlížeč, ale ten tady nehraje roli)

A teď trošku vysvětlení. Na nový server jsem nakopíroval web z jiného serveru, tedy kopie 1:1. Stejné skripty, stejná databáze – všechno zdá se být stejné. Když jsem pak začal testovat chod webu na novém serveru, tak se mi nechtěly zobrazovat obrázky. Udělal jsem si proto tyto výstupy. Skript vypadá nějak takto:

Když ho volám z původního serveru, tak mi správně vypíše pole dle preg_match, když ho však volám z nového serveru, tak mě STRING neprojde eregem a tudíž nic nevypíše.

Celkem zajímavé.  Servery se akorát liší ve verzi PHP:

Server 1: PHP 5.2….

Server 2: PHP 5.4….

Nevíte někdo, co to může způsobovat? Už se tady s tím 2 hodiny trápím.