Zádrhel u DNSSEC s vlastním NSSETem

V polovině února tohoto roku jsem si u active24 zaregistroval doménu mujpro.cz (golfový trenér). Ihned po registraci jsem (tak jako u všech ostatních) přenastavil u domény NSSET na naše nska. Aktualizoval jsem konfiguraci bindu, otočil a za pár hodin vše vesele fungovalo.

Po měsící vývoje jsem zveřejnil betu vyvíjené aplikace úzké skupině testovacích uživatelů. Jako feedback se ke mě dostala informace o částečné nedostupnosti aplikace. V některých případech se uživatel vůbec nedostal na obsah dané prezentace, v jiných se mu nezobrazila žádná grafika (veškerou grafiku umisťuju na doménu třetího řádu) a v těch ostatních vše fungovalo korektně.

Z počátku jsem tomuto problému nepřikládal velkou váhu. Neměl jsem žádné known issue které by s touto nedostupností korespondovalo.  Jiné domény se zcela stejným nastavením mi fungovaly korektně. Testoval jsem korektní dostupnost prezentace z několika strojů (i s pomocí jiných uživatelů a lokalit). A také jsem se nechal ovlivnit faktem, že popsaný feedback přišel ze strany více či méne BFU.

Na záležitost jsem skoro zapoměl, když jsem jednoho dne prezentoval web na veřejné WIFI v kavárně Savoy jednomu z klientů. A ejhle. O reálné existenci problému jsem se přesvedčil osobně.

Problém byl v překladu DNSka. Ping byl zcela mrtvý – nepodařilo se mu přeložit hostname. Zjištění pro mě šokující. Hlavně jsem v první chvíli nechápal, proč se toto dějě selektivně jen na straně určitých providerů. Obrátil jsem se tedy na registrátora (active24) s podrobným popisem problému.

Reakce byla vysvětlující a poučná:

Problémy může způsobovat aktivní KEYSet na doméně. Ve chvíli kdy jste doménu převáděl na vlastní DNS již byla podepsána naším KEYSetem a ten na ní zůstal aktivní. Ve chvíli kdy je na doméně aktivní zabezpečení DNSSEC a zároveň na autoritativních nameserverech není příslušný klíč, budou nameservery poskytovatelů, kteří se k této technologii chovají korektně, považovat DNS odpovědi za podstrčené a komunikaci přeruší.

Pomocí autorizovaného požadavku jsem nechal z domény odstranit KEYSet a vše již funguje jak má. Solved.

Seznamka a SEO

Již velmi dlouho jsem se díky nedostatku času (lamentování nad aplikačním vývojem, manažerské strasti nad novými projekty) nedostal k poctivé optimalizační výzvě. Však to znáte, máte zavedený web plný obsahu, návštěvnící jsou, ale nikoliv v požadované míře a na důležitá klíčová slova se umisťujete v nekonkrétní hloubce.

Tak a je to tu. Web, který se chystám optimalizovat je klasická textová seznamka. Seznamek (větších či menších) jsou tuny. Těch významných je jenom několik. Ona taková seznamka je na trafficu docela závislá. Když si zadáte inzerát, logicky očekáváte, že se Vám v nejbližší době dostane co nejvíce relevantních odpovědí. K tomu je však potřeba hodně návštěvníků.

Předmětný web měl co do korektní SEO optimalizace špatně mnoho věcí, především:

  • nelogická doména třetího řádu
  • shodný titulek napříč celým webem
  • crawler se neměl šanci dostat na dílčí textové obsahy
  • zbytečné linky pro vyhledávače (aplikace rel=nofollow)

Jak je vidět, jsou to všechno pouze onpage faktory. Předtím než se ve velké míře vrhnu na ty offpage, chci tomu dát chvíli na revitalizaci. Zajimá mě, do jaké míry stačí robotům pouze správně sestavený obsah.

V současné době je jich všechno upravené a zoptimalizované. Udělal jsem si graf denních hitů z výsledků vyhledávačů. Uvidíme, jak to dopadlo …

Dogmata, absolventi a kvalita výuky

V profesním světě mám několik dogmat. Rád je barvitě sděluji svému okolí, které se mně často ptá na rady jak toto či tamto. Víceméně se jimi i řídím, od toho je v podstatě mám. Jaká jsou to dogmata? Tak tedy:

  • Nikdy (nikdy!) se nespoléhat  na neověřené zdroje a nezadávat jim důležitou práci
  • Nic nedělat ad hoc – plánovat, analyzovat, projektovat (dobře, toto moc neplatí na soukromé projekty …)
  • Vždy počítat s dostatečným časem na testování a ladění (z praxe to se vším všudy bývá plus polovina vývojového času)
  • Vytvářet bezpečné a funkční aplikace
  • Využívat framework(y) a nepsat duplicitní bloky kódu

Teorie hezká. V praxi se občas nebere zcela vážně (kovářova kobyla), ale má své místo. Nicméně jsem si nedávno nad nedodržením výše uvedeného pěkně rozbil tlamu. Začalo to prvními dvěma body, ostatní se k tomu pěkně přisypaly.

Tvořil jsem projekt (soukromý, u jiného bych si to pochopitelně netroufl) na který bylo extrémně málo času (obecně, já na to neměl čas vůbec). Odzkoušený (známý) grafik dodal návrhy, ty se schválily a já řešil co dál. Muselo to být rychle, já neměl čas, všichni vývojáři v mém okolí neměli špetku času. Grafik se nabídl s tím, že má kamaráda (spolubydlícího) který studuje ČVUT a byl by schopný to převést z obrázku na web. Postupem jsme to rozšířili také o oživení kompletního webu plus primitivní CMS. Výhodou bylo, že si to ti dva šmoulové mohli vyřešit pěkně spolu (spolubydlící) a já měl dostat hotový produkt bez námahy a složitého domlouvání (kodér vždy nadává na grafika kvůli tomu, že nepočítá se všemi možnostmi a programátor na kodéra …).

Takový byl plán. Z počátku to mělo dobrý tón, HTML šablony spolu s relativně komplexním JS fungovaly (do kódu jsem raději moc nekoukal, byl ostudný) ale budiž, tam cílovka koukat nebude.

Vše se začalo komplikovat s prvními verzemi oživeného webu. Pomyslná kudla mi prořezala kapsu skrz na skrz. Vygradovalo to ve chvíli, kdy jsem mailem dostal hotovou verzi v zipu. Co bylo v dodané outsorcované práci tak špatně?

  • Ještě nikdy jsem neviděl odpornější kód.
  • Žádný framework, žádná DB třída, html vypisované pomocí echo, české názvy proměnných (někdy i ve skloňovaných variantách).
  • Url klasickým odstrašujícím způsobem: “page=sekce” a nasledně include(xxx/sekce.php) (bez ochrany!).
  • V každém modulu (page=) zvlášť (!) připojení do databáze (i přes použití centrálního nastavení konstant pro DB připojení stejně na několika místech natvrdo).
  • Přibližně 60% duplikovaného kódu
  • Pro jazykovou mutaci je nutné vytvořit paralelně kopii skriptu (page) s veškerým funkčním kódem a HTML

A jako třešnička:

  • Používání session proměnných stylem register_globals=on

To poslední mi pěkně zamotalo hlavu. Dělal jsem na webu vlastnoručně úpravu (potřeboval jsem z DB získat do skriptu o jeden sloupeček více) a vedlejším efektem bylo, že se každý návštěvník “automaticky” přihlásil (přepsání globální proměnné) rovnou s administrátorskými právy. Fajn.

Asi není třeba příliš poukazovat na efekt, že jsem s tím měl nakonec mnohem více práce, než kdybych si to vyřešil sám (a to beze srandy). Následující dva týdny jsem denně přicházel na špeky a disfunkce, které jsem pečlivě reportoval a den co den instaloval nové dodané verze. Navíc to vůči partnerům bylo silně neprofesionální. Přijít na prezentaci aplikace na to, že funguje silně náladově, není zrovna ideální. Vyčerpávající.

Mám z toho všeho dva dojmy. Za prvé: už nikdy nezadám práci neověřenému externistovi (jasně, to už tu bylo). Za druhé (a to je hlavní): jsem v šoku z kvality absolventů. Jistě, člověk může argumentovat, že z jedné špatné zkušenosti nelze soudit. Faktem je, že mám ve svém okolí hned několik známých, kteří zmíněnou školu a konkrétně mě profesně známé obory studují. Častokrát jsem jim pomáhal řešit úlohy do školy. Když jsem ale na vlastní oči (a zkušenost) viděl (zažil) co je tam učí za pakárny, bylo mi mdlo.

Vyučující totiž nedbají na žádný styl. Neznají coding style. Sami někdy ani nerozumí probírané problematice. Oblíbenou formou výuky je funkční rozšíření předané základní verze aplikace (vytvořené vyučujícím). Tato aplikace však v mnoha případech ani nefungovala (když už, tak nikdy ne zcela korektně) a nesla všechny příznaky popsané v bodech výše.

Achjo. Chápu, že profík který si díky své profesionalitě dokáže slušně vydělat nepůjde učit za almužnu. Ale ti, co předávají znalosti by měli mít alespoň nějakou úroveň. Jsem v tomto ohledu rád, že jsem se v tomto oborou nějaké VŠ vyhnul, a veškeré své aktuální know how jsem si nabyl metodou pokus/omyl sám, nebo od profesně zdatnějších kolegů z oboru. To je totiž ta nejlepší škola.