Ak pracujeme s CSS knižnicou bootstrap, skôr či neskôr sa dostaneme do situácie, kedy potrebujeme nastaviť CSS štýl nejakému komponentu/tagu … podľa rôznej veľkosti obrazovky prehliadača. Slúži na to kľúčové slovo @media. Bootstrap rozlišuje 4 základné veľkosti (nájdeme ich aj vo vnútri knižnice):

.container {
}

@media (min-width: 768px) {
    .container {
        width: 750px;
    }
}

@media (min-width: 992px) {
    .container {
        width: 970px;
    }
}

@media (min-width: 1200px) {
    .container {
        width: 1170px;
    }
}

Základné veľkosti podľa bootstrap-u sú teda štyri:

1. veľkosť do 768 pixelov
2. veľkosť od 768 do 992 px
3. veľkosť od 992 do 1200 px
4. veľkosť nad 1200 pixelov

Toto nie je žiadne tajomstvo. No týmto blog postom by som chcel upozorniť na jednu drobnosť. A to použitie reverzného princípu pomocou @media (max-width: x). Definovanie štýlu nie od minimálnej šírky ale do maximálnej šírky. Tu treba dať pozor na jednu vec a tou je jeden pixel. Ak definujeme štýl od minimálnej šírky pomocou min-width:x tak k nemu opačná definícia pomocou max-width je max-width:x-1. Pre úvodný kus kódu by to bolo nasledovne:

@media (max-width: 767px) {
    /* Custom definitions ...*/
}

@media (max-width: 991px) {
    /* Custom definitions ...*/
}

@media (max-width: 1199px) {
    /* Custom definitions ...*/
}

A ešte jedna poznámka na záver:

• @media (max-width: 767px) platí pre šírku od 0 do 767 pixelov 
• @media (min-width: 768px) platí pre šírku od 768 pixelov a viac

Pri konfigurácií mailového servera resp. riešení dôveryhodnosti sa nám určite ešte hodí vedieť spôsob ako si správnosť našich krokov a celkové fungovanie overíme. Dobre nám na to poslúži Gmail. Stačí, keď odoslaný mail z konfigurovaného servera otvoríme v Gmail schránke. Následne po kliknutí na možnosť “Show original”:

Sa nám zobrazí nasledovný zdrojový kód emailu:

Kde vidíme že Gmail za nás overil/neoveril správnosť nastavenia SPF a DKIM (v tomto prípade overil  pass).

Aby naši klienti mohli naplno využiť e-mail marketing a to bez horibilných poplatkov za mailové služby typu SendGrid, MailChimp, rozhodli sme sa implementovať/rozbehnúť vlastný mailový server (komponent e-Mail Marketing v našom eShope). Pre predstavu Sendgrid si účtuje $80 mesačne za 100tis. mailov (o slovenských firmách a ich cenách ani nehovorím, veď posúďte sami email marketing site:sk), čo je naozaj veľa, keď vezmem do úvahy, že je celkom bežné (aj u našich klientov), že ich mailing listy obsahujú bežne 50tis adries. To by si klient poslal 2 newslettre mesačne za $80 a dosť. Pre klientov, ktorí dostávajú nový tovar 2-krát do týždňa a chcú o tom informovať svojich zákazníkov prostredníctvom e-mailu, sme vyšli v ústrety a rozbehli vlastný mailový server, vďaka čomu nie sú naši klienti obmedzení počtom odoslaných emailov. Ale čo je najdôležitejšie, majú túto službu bez obmedzení zadarmo (resp. v cene balíka).

Mail Server – konfigurácia

Konfigurácia mailového servera je téma tiež zaujímavá na rozpísanie (možno nabudúce). V tomto poste by som sa chcel zamerať na iný problém, ktorý s vlastným mailovým serverom prichádza. Ku konfigurácií mail servera len spomeniem oblasti/komponenty, s ktorými sa treba zaoberať:
V prvom rade treba mať server (virtuálny, dedikovaný, v cloud-e) a následne si vybrať jeden z dostupných mail serverov alias mail aplikácií. V našom prípade to bol ***** bohužiaľ kvôli bezpečnosti to neuvediem. O bezpečnosti mailového servera ešte určite napíšeme minimálne jeden článok, pretože to je dôležité a stojí to za zmienku. S bezpečnosťou na “mailovom” porte 25 sa stretávame každý deň.
Ale vráťme sa nazad. Ďalej je potrebné mať rozbehnutý nejaký databázový server, v našom prípade MsSQL, s ktorým bude mail služba pracovať. Po inštalácii nasleduje dlhá konfigurácia a testovanie :

• DNS nastavenia domén – MX záznamy,
• konfigurácia mailových schránok na mail servery info@vasadomena.sk, vasemeno@vasadomena.sk, …
• protokoly a porty – 25, ***, ***, + šifrované porty ***, ***, ***
• firewall,
• certifikáty SSL,
• z bezpečnosti napr. spam-assasin, antivírus
• filtrovanie cez blacklisty …
• nastavenie pravidiel pre bodovanie SPAMu
• logovanie,

A určite veľa ďalších vecí, na ktoré si momentálne nespomeniem … neskôr sa zamyslím a asi ešte pár blog postov o tom spíšem. Ale ani o konfigurácií som nechcel hovoriť. Chcel som trocha načrtnúť problematiku dôveryhodnosti mail servera pre ostatné mail služby ako Gmail, Hotmail (Outlook, LiveMail … proste Microsoft mail ), a slovesné ako Azet, Centrum …

Mail Server – dôveryhodnosť

Rozbehnúť mail server bola jedna vec, no v krátkej dobe sa ukázalo, že z ostatných mailových služieb prichádzali chybové kódy o nemožnosti doručiť e-mail. A čo bolo zvlášte, tak chyby prichádzali sporadicky. Až vďaka Gmailu sme tento problém vyriešili. Aj keď musím povedať, že support od Google je nepoužiteľný, teda aspoň pre nás bol. Asi sme im nestáli za to, aby sa obťažovali a odpovedali na naše emaily, ktorých bolo požehnane.
No vďaka ich Google Knowledge Base sme nasledovný problém vyriešili.
Jediný Gmail nás upozornil na problém v našich mailoch nasledovnou hláškou “550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for more information.” po kliknutí sa url sa dostaneme na Google KB, konkrétne článok Bulk Senders Guidelines, podľa ktorého nám chýbali nasledovné 3 veci:

1. podpísanie emailu pomocou DKIM
2. nastavenie SPF záznamov na naše domény
3. nastaviť DMARC policy

Keďže v tejto oblasti sme mali medzery, museli sme najskôr naštudovať danú problematiku, aby sme to doklepli do úspešného konca. V skratke ide o toto:

1. DKIM

Ide o podpísanie emailu private kľúčom a vypublikovanie public kľúča do TXT záznamov. Prijímateľ si tak ľahko vie spojiť private a public key a následne otvoriť email. Ideálne je vygenerovať kľúče o sile 1024 bajtov a viac, napr . pomocou Open SSL alebo online cez tool stavaný priamo na generovanie kľúčov pre DKIM - port25.com. Kľúče vyzerajú napr. nasledovne:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC99PThBf099kgR8mnsAwqkpzBr
5geiVkqeUABUMErFSsaTrRgtUCRkgSHbHHBT0OwY6aCd8TDZh7ekvwTJ/0SK3/Xm
ihzfVZANT4l4CIdvBj1GDFQ7PzNIXQwvDcE9St3kw5MDyirIdA9xUVUc6xze4T2A
yqM3fIsCNUSr6ksBDQIDAQAB
-----END PUBLIC KEY-----

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQC99PThBf099kgR8mnsAwqkpzBr5geiVkqeUABUMErFSsaTrRgt
UCRkgSHbHHBT0OwY6aCd8TDZh7ekvwTJ/0SK3/XmihzfVZANT4l4CIdvBj1GDFQ7
PzNIXQwvDcE9St3kw5MDyirIdA9xUVUc6xze4T2AyqM3fIsCNUSr6ksBDQIDAQAB
AoGAfbcZPbeGAzT0O5Rwj3bv20qe3DnvwXtUhPOzVARl5652P5PmFU8d1rozmtx2
ZrI1HsO3ve+7Aaw1WL3mwHzFcfEfpgc1c+CtcdgU6ehWQ1qDI2ZtrwkxIZX0CaEz
XCxT7GRgSNmyfXf7qSJ2DVJrxcLTuPgdZgSOVUxw02DG0UECQQD7effWpv+s/MM2
CZUApY88ycXAcJgXabkAoExgGiZ26xlimr7mgu7EbK+9JCQV1U+A9e0+vMcnJiuh
MWd2vFzxAkEAwV+x6ge5gV1SXZh/2+pH5hMKYhBJEEiPlbYV6im78L6/7TRGviH/
Suya2/A8qlP4tG58RlPj2/5Yhklqgv8V3QJBALm1F3X3u0X3Hv2v0843dPCyHIwB
Wf+oPkudFOm/Rfp5oTR1DFbUCBkcHidyIgfRj7WvZvT2madqg7u07S/86DECQA03
/XGCFaxCNN8xDYx6929C3fLWKihyzV3ulJDtSWurnnMYn71flZQJmIxwX7VFCDtN
UjF8ipb/TA3h9uX9igECQQCobXaHmcXiBDPvCnVQCyoDol1ecpTkpahE5luEAQ3z
uXewFoQ+vI8c6jfnDY5DaMzjgVltAdJKAvC4utJzylia
-----END RSA PRIVATE KEY-----

Private Key je potrebné uložiť do súboru a zimplementovať na mail servery, aby bol súčasťou každého odoslaného emailu.
Public key je potrebné vložiť do TXT záznamov v tvar:

server1._domainkey.vasadomena.sk IN TXT
"k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC99PThBf099kgR8mnsAwqkpzBr5geiVkqeUABUMErFSsaTrRgtUCRkgSHbHHBT0OwY6aCd8TDZh7ekvwTJ/0SK3/XmihzfVZANT4l4CIdvBj1GDFQ7PzNIXQwvDcE9St3kw5MDyirIdA9xUVUc6xze4T2AyqM3fIsCNUSr6ksBDQIDAQAB"

2. SPF

Ide o pomerne jednoduchú vec, v skratke povedané : pomocou TXT záznamov vieme nadefinovať server, z ktorého je email odoslaný. Slúži to ako určitý stupeň bezpečnosti z kategórie Domain-based. Kedy na doméne nastavujeme server, ktorý je oprávnený odoslať email z danej domény a žiaden iný. Pri definovaní nám pomôže nasledovný tool - SPF Record Testing Tools.

3. DMARK policy

Je opäť ďalší stupeň zabezpečenia z kategórie Domain-based authentication. Ide o nadstavbu pre DKIM a SPF, ktorú definujeme opäť pomocou TXT záznamov. Technika je pomerne dobre rozpísaná na dmarc.org.

Ta-dá!

Po týchto krokoch môžete veselo odosielať tisíce mailov a mať istotu, že skončia v mailovej schránke prijímateľa a nie v spam filtri mailového servera.

Pre tieto účely – optimalizácia html stránok - je veľmi užitočný tool priamo od google s názvom Webmaster tool a konkrétne jeho súčasť PageSpeed Insights. Ten vie prebehnúť požadovanú url adresu a poskytnúť nielen výslednú štatistiku, ale aj návrhy ako dané nedostatky riešiť.

Tie najdôležitejšie nedostatky sme riešili nasledovne:

1. Minifikácia Css a Javascript súborov

Minifikácia súborov Css,Js ale napr. aj HTML je vo Visual studiu skutočne jednoduchá v spojení s toolom s názvom Web Essentials. Stačí v Solution explorer nájsť požadovaný súbor a v kontextovej ponuke vybrať minifikáciu nasledovne:

Tool vygeneruje rovnomenný súbor s koncovkou .min.css, resp. .min.js do rovnakého priečinka a zavesí ho ako sub-node daného súboru. Web essentials je veľmi užitočný tool .
Takto minifikované súbory sme ešte pomocou tzv bundlingu (referenčná kližnica System.Web.Optimization) zabalili do jedného výstupného súboru:

public class BundleConfig
    {
        public static void RegisterBundles(BundleCollection bundles)
        {
            // CSS
            bundles.Add(new StyleBundle("~/Styles/Css").Include(
                "~/Styles/Bootstrap.min.css",
                "~/Styles/Fonts.min.css",
                "~/Styles/font-awesome.min.css",
                "~/Styles/font-iconpack.min.css",
                "~/Styles/Bootstrap-cutom.min.css",
                "~/Styles/Animate.min.css", 
                "~/Styles/Technologies.png.min.css",
                "~/Styles/Main.min.css"));

            // JS
            bundles.Add(new ScriptBundle("~/Scripts/Js").Include(
                "~/Scripts/jquery-{version}.min.js",
                "~/Scripts/jquery-Lightbox.js",
                "~/Scripts/jquery-viewportchecker.min.js",
                "~/Scripts/jquery-typed.min.js",
                "~/Scripts/modernizr-{version}.min.js",
                "~/Scripts/detectizr.min.js",
                "~/Scripts/bootstrap.min.js",
                "~/Scripts/respond.min.js",
                "~/Scripts/Site.min.js"));

            BundleTable.EnableOptimizations = true;
        }
    }

Výsledok:

2. Caching na strane klienta

Aby prehliadač klienta nemusel pre každú stránku ťahať po sieti aj zdroje, ktoré už má, musíme mu to povedať cez hlavičku HTTP requestu. V ASP.NET to zabezpečíme veľmi jednoducho. Do priečinkov, ktoré cheme zacacheovať na strane klienta doplníme nasledovný web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <staticContent>
            <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" />
        </staticContent>
    </system.webServer>
</configuration>

3. Caching na strane servera

Na cacheovanie na strane servera sme využili tzv. OutputCache a to nasledovnou konfiguráciou vo web.configu projektu:

<system.web>
	<caching>
    	<outputCache enableOutputCache="true"></outputCache>
    	<outputCacheSettings>
    		<outputCacheProfiles>
        		<add name="Cache1Hour" location="ServerAndClient" duration="3600" enabled="true" varyByParam="*" />
            	<add name="Cache1Day" location="ServerAndClient" duration="86400" enabled="true" varyByParam="*" />
       	 </outputCacheProfiles>
    	</outputCacheSettings>
    </caching>
 </system.web>

<%@ Page Language="C#" %>
<%@ OutputCache CacheProfile="Cache1Hour" %>