Greenyho pracovní zápisníček

SEO: Odkud přicházejí naši zákazníci?

2010-09-28T13:26:00Z

O SEO (Search Engine Optimalization) už byly sepsány megabyty textu. Pro zájemce o hlubší poznání SEO jsou velmi zajímavé články na jakpsatweb.cz.

Já bych se s vámi rád podělil o jednoduchou techniku, která zjistí, jak je optimalizace úspěšná a odkud k nám přicházejí cenní zákazníci. Cenným zákazníkem nemyslím kteréhokoliv návštěvníka našeho webu, myslím tím návštěvníka, který si něco koupí v našem eshopu nebo je nám jeho návštěva jinak prospěšná.

Abychom zjistili, co se s našimi stránkymi děje, je velmi vhodné zvolit nějaký monitorovací nástroj. Nejběžnější dostupné nástroje jsou: Google Analytics a TopList. To jsou ale plošné monitory, které nám sice krásně zanalyzují celkovou návštěvnost, ale už nám neřeknou, jak se k nám dostávají cenní zákazníci. Nástroj, který nám na tyto otázky částečně odpoví, je nástroj „Sledování konverzí“ v seznamáckém Skliku. Ten mi ale přišel ne úplně domyšlený a navíc nepoužitelný s jinými reklamními systémy, například bannery nebo Google Adwords.

Jako nejjednodušší řešení mi přišlo si monitoring cenných zákazníků napsat sám.

Co o nich tedy můžeme zjistit?

Pokud na naši stránku přišli z vyhledávače, pak z jakého a jaká klíčová slova použili.
Pokud na naši stránku přišli prostřednictvím nějaké naší reklamní kampaně, pak která to byla.

Tyto zjištěné informace pak mohu lehce asociovat s konkrétní objednávkou. Následnou analýzou pak zjistím, které reklamní kampaně generují zisk a které jsou jen vyhazováním peněz.

Jak na to?

Pro zjištění názvu vyhledávače a klíčových slov použijeme atribut Request.UrlReferrer. V něm je uloženo URL stránky, na které je odkaz na naši stránku, na který zákazník kliknul, aby se k nám dostal. Z URL nás zajímají dvě části:

referrer.Host – doména vyhledávače
parametr „q“ – dotaz zadaný do vyhledávače (google, seznam, jyxo)

Příklad: Člověk se chce stěhovat po Praze, tak zadá do googlu „stehovani praha“. Dotaz se přeloží na URL http://www.google.cz/search?q=stehovani+praha. Host je „google.cz“, parametr „q“ je „stehovani praha“. Po kliknutí třeba na www.mula.cz se dostanete na titulní stránku, která si do Session uloží obsah parametrů Host a „q“.

Určení použité reklamní kampaně se děje obdobně. Do URL odkazu na inzerovanou stránku nebo produkt se vloží identifikátor kampaně. URL by mělo být ve tvaru "http://{url-inzerovaneho-produktu}?campaign={id-kampane}", tedy například http://www.mula.cz/?campaign=vyvojar. Po kliknutí na odkaz pak s parametrem „campaign“ zacházíte jako s výše zmiňovaným parametrem „q“.

protected void Page_Load(object sender, EventArgs e)
{
	if (!IsPostBack)
	{
		// ... do your stuff
		ProcessSeo();
	}
}
private void ProcessSeo()
{
	string campaign = Request["campaign"];
	if (!string.IsNullOrEmpty(campaign))
	{
		Session["seo-campaign"] = campaign;
	}
	Uri referrer = Request.UrlReferrer;
	if (referrer == null) return;                   // referrer je neznamy => end
	if (referrer.Host == Request.Url.Host) return;  // referrer neni cizi => end
	Session["seo-referrer"] = referrer.Host;
	if (referrer.Query == null) return;
	NameValueCollection pars = HttpUtility.ParseQueryString(referrer.Query);
	string q = pars["q"];                           // vyhledavana klicova slova
	if (string.IsNullOrEmpty(q)) return;
	Session["seo-query"] = q;
}

Všechny zajímavé parametry máme nyní uloženy v Sessions. Když nastane ta správná chvíle, třeba zákazník odešle objednávku vybraného zboží, sáhneme si do Sessions a parametry společně s akcí uložíme.

protected void OnSomeAction()
{
  // get the action
  
  SomeAction action = ... ;
 
  // associate SEO information with that action
  string campaign = Session["seo-campaign"];
  string referrer = Session["seo-referrer"];
  string query = Session["seo-query"];
  SaveSeo(action, campaign, referrer, query);
}

To je celý kód, nic složitého. Složitá je až analýza výsledků a upravování reklamních kampaní. SEO je běh na dlouhou trať, kde žádný krok není zadarmo.

Na závěr ještě dotaz:
Máte někdo praktické zkušenosti s tím "během na dlouhou trať" a chtěli byste nám pomoci s bojem o lepší pozice a vyšší návštěvnost?
Pište na daniel.smolka(kyselá ryba)gmail.com.
Díky.

Source Control na malých projektech

2010-06-22T18:10:00Z

K napsání tohoto článku mě inspiroval můj kamarád, taky programátor. Říkal jsem mu něco jako: „Dělal jsem teď jeden projekt s použitím Subversion a hodně mi to při vývoji pomohlo.“ A on na to něco jako: „Jo, taky už jsem o tom slyšel. Je to ale moc složité a stejně mi to k ničemu není.“ Myslím si, že se mýlí. Ano, níže popsaný postup přináší do projektu nějakou režii. Ta ale není zase až tak velká, aby byla na překážku při každodenním používání. A výhody z postupu plynoucí tu režii plně vyváží.

Co je to ten source control?

Source control (známý též jako Revision control nebo Version control) je postup, který umožňuje se vrátit ke kterémukoliv předešlému stavu projektu. Source control systémy pro vývoj software mají kromě této základní funkce ještě další. Z těch nejdůležitějších to jsou funkce, které:

umožňují současnou práci více lidem na jednom projektu;
udržují centrální úložiště kódu (repository), které slouží hlavně jako zdroj jediné aktuální verze zdrojového kódu.

Způsob použití repository je nakreslen na následujícím obrázku:

Každý člen vývojového týmu se přes internet nebo místní síť připojí na repository, které je umístěno na Source control serveru. Z repository si stáhne na svůj počítač tu část zdrojového kódu, kterou potřebuje ke své práci. Po vykonání svého úkolu, který typicky obnáší nějakou úpravu kódu a její testování, odešle změny zpět do repository. Během společné práce v týmu by měly být dodrženy následující základní pravidla:

Každý člen týmu by měl svou kopii zdrojového kódu pravidelně aktualizovat z repository (nejméně jednou denně).
Práce členů týmu by se neměla překrývat. Práce více lidí na téže věci vede k nepříjemným konfliktům, které jsou častým zdrojem chyb. V nejlepším případě vedou konflikty k zahození práce některých lidí.

Zatím jsem zde psal pouze o práci v týmu. Vyplatí se použití source control i pokud na projektu pracuje pouze jeden člověk? Na tuto otázku není jednoznačná odpověď, protože v tom případě nemá význam hlavní výhoda source control, a sice možnost práce v týmu. Stále ale zůstávají ve hře další dvě důležité funkce. Zaprvé možnost vrátit se ke kterékoliv historické verzi zdrojového kódu. Zadruhé zdrojový kód je pravidelně zálohován na JINÉM počítači, než na kterém člověk vyvíjí. Zdá se to jako nepodstatný detail, ale kolik jste už za život potkali smutných lidí s crashlým diskem nebo ukradeným noutbukem?

Používané source control

Následující seznam source control systémů není úplný, obsahuje pouze systémy, s nimiž jsem měl možnost pracovat. Když tak mě prosím v diskusi doplňte:

MS SourceSafe – Source control systém od společnosti Microsoft. Před lety byl hojně používán, ale trpí některými neduhy, jako je krkolomná obsluha a tragicky dlouhé odezvy při práci přes internet. Vývoj byl před pár lety zastaven.
CVS – Open source Source control systém. Před lety taktéž hojně používán, ale vývoj byl také před pár lety zastaven.
MS Team Foundation Server – Enterprise řešení od společnosti Microsoft, nástupce SourceSafe. Vhodný pro střední až velmi velké projekty. Výhodou je široké spektrum podporovaných funkcí, zejména s důrazem na řízení projektu. Nevýhodou je cena licence.
Subversion – Open source Source control systém, nástupce CVS. Vhodný pro malé až středně velké projekty. Výhodou je podpora více platforem (Unix i Windows) a nulové pořizovací náklady. Nevýhodou jsou chybějící funkce pro řízení projektu, které ale při malých projektech nejsou nutné. Můj níže popsaný projekt je realizován právě s použitím Subversion v kombinaci s TortioseSVN, které je jeho výborným a praktickým grafickým rozšířením.

Organizace repository

Repository lze uspořádat několika způsoby. Konkrétní uspořádání záleží na zejména na složitosti projektu, na způsobu testování kódu a na deploymentu aplikace. Zde se budu zabývat pouze dvěma nejjednoduššími způsoby:

Trunk only – Přírůstek kódu je lineární, tedy v průběhu vývoje aplikace nedochází k žádnému větvení verzí. Toto je úplně nejjednodušší uspořádání, které je vhodné pouze tehdy, když si jsou vývojové, testovací a produkční prostředí velmi podobné a je možnost častého update aplikace na produkci.
DEV-PROD – Vlastní vývoj probíhá stejně jako v předchozím případě. Pokud ale má dojít k nasazení na produkčním prostředí, je z hlavní vývojové větve DEV (tedy výše popsaného Trunku) oddělená verze PROD, jejíž obsah je nasazen na vývojové prostředí (na obrázku DEV.3 na PROD.1). Výhoda tohoto uspořádání spočívá v tom, že je možné kód automaticky přizpůsobovat produkčnímu prostředí, které může být trochu jiné než vývojové. Lze také opravovat chyby v nasazené verzi, zatímco již probíhá vývoj nové funkcionality na DEV větvi (na obrázku PROD.1 na PROD.2). Navíc je stále k dispozici kompletní zdrojový kód aplikace nasazené v produkčním prostředí.

Vývojová prostředí

Při aplikačním vývoji se osvědčil způsob, kdy aplikace během svého životního cyklu prochází následujícími prostředími:

Vývojové prostředí – Zde probíhá vývoj aplikace. Může to být buď lokální počítač programátora nebo virtuální prostředí přístupné přes vzdálené připojení (typicky Remote desktop).
Testovací prostředí – Zde se nanečisto zkouší, jak se bude aplikace chovat v praxi. Testovací prostředí by tedy mělo být co nejpodobnější produkčnímu prostředí.
Produkční prostředí – Zde aplikace pracuje. Na produkční prostředí by měla být nasazená aplikace pouze tehdy, když se osvědčila při fungování v testovacím prostředí. Píšu měla by, protože se tak často neděje. Většinou se přeskočením testování ušetří čas. Občas se ale stane, že se přeskočení testování vymstí a vzniklé ztráty jsou pak větší než náklady na regulérní testování.

Použití source control

Používání source control v praxi budu demonstrovat na konkrétním příkladu, kterým je nedávno releasnutá webová aplikace www.mula.cz (zatím v beta verzi). Při jejím vývoji je používaná konfigurace:

Source Control Server – Starý počítač hozený pod stolem, na kterém jsou Windows 2000. Na nich je nainstalován Apache 2.2, který je využíván Subversion source control. Repository využívá uspořádání DEV-PROD. Počítač je připojen do internetu tak, aby měl pevnou IP adresu.
Client A – Vývojové prostředí na mém počítači.
Client B (není na obrázku) – Vývojové prostředí dalšího programátora.
Testovací prostředí – Subdoména v rámci hlavní domény aplikace. Důležité na testovacím prostředí je, aby bylo co nejpodobnější prostředí produkčnímu. Projeví se tak problémy, které se na vývojovém prostředí neprojeví. V mém případě to byly problémy způsobené zvýšenými požadavky na bezpečnost a integrací s ostatními systémy (odesílání emailů). Testovací prostředí má svou vlastní aplikační databázi, aby testy neovlivňovaly aplikaci nasazenou v produkčním prostředí.
Produkční prostředí – Hlavní doména na web hostingu.

Běžný vývoj probíhá tak, že vývojáři A, B až X kutají, jak je popsáno v úvodní kapitole. Když dokutají do určitého bodu, vývojář A ho označí v DEV repository tzv. tagem, který jednoznačně identifikuje aktuální verzi zdrojového kódu (třeba „Release 123“). Vývojář A pak svou aktuální verzi kódu zkompiluje, zabalí a vystaví na testovacím prostředí. Tam je nějakou dobu testována, zda vše funguje správně. Vývojáři mezitím dál kutají...

Pokud se na aplikaci v testovacím prostředí vyskytují chyby, provede se jejich oprava, která je označena novým tagem (třeba „Release 124“), a která je opět nasazena na testovací prostředí.

Pokud je aplikace v testovacím prostředí v pořádku, provede se merge (spojení verzí). Merge promítne změny aplikace nasazené v testovacím prostředí (označené tagem „Release 124“) do PROD repository. Po zkompilování a nasazení aplikace z PROD repository se by na produkčním serveru měla ocitnout stejná (nebo velmi podobná) verze aplikace jako na testovacím.

Navíc, jak jsem psal výše, pokud máme rozpracovanou implementaci nějaké nové funkcionality a zjistíme nějaký závažný problém na PROD aplikaci, pak můžeme opravu provést přímo nad PROD repository. Nejsme nuceni dělat release rozpracované DEV aplikace, protože ten by určitě nedopadl dobře.

Závěrem

Při vývoji software se vyplatí řídit se určenými procesy. Pod pojmem proces si nemusíte představovat nějaké hroznosti. Pod pojmem proces si představte postup, který si sami definujete, aby jeho výsledkem byl spolehlivý kód. Důležitým bodem je, že proces je jednou daný a už se nemění. Takže nad ním již nemusíme přemýšlet a jeho provádění můžeme svěřit počítači ve formě skriptů, které vyžadují minimální manuální zásahy.

Pokud se vývoj žádnými procesy neřídí, pak se tomu říká pankárna. A výsledek pankárny je stejně spolehlivý, jako je spolehlivý typický pankáč.

Výše popsaný proces je samozřejmě jen jednou z možných cest. Tento článek Vám má hlavně posloužit jako vysvětlení některých běžných pojmů a jako inspirace založená na případové studii.

A na úplný závěr reklama: Pokud chcete něco převézt nebo přestěhovat, jděte na www.mula.cz. Snad vám portál bude sympatický, když teď víte, jak vznikal. Plánuju ještě navazující článek o jeho architektuře, konkrétně o použití Linq2Sql v ASP.NET aplikaci.

Update (1.7.2010)

Po diskusi s uživatelem rarous jsem dospěl k závěru, že výše navrhované řešení je zbytečně komplikované a nepraktické. Projekt jsem překopal a buildovací workflow nyní vypadá takto:

Úprava se řídila následujícími pravidly:

Dvě repository jsou nesmysl, jedno bohatě stačí.
DEV, TEST i PROD aplikace by ideálně měly být stejné a lišit se pouze konfiguračním souborem.
Aplikace nasazovaná na PROD vždy musí pocházet ze stejného buildu jako aplikace nasazovaná na TEST, protože TEST slouží k prověření funkčnosti nasazované aplikace.
Projekt je tak malý, že mi přijde zbytečné rozbíhat build server a automatické buildy. Tuto funkcionalitu zastává ručně developer na Client A.

Důsledky úprav jsou:

Zjednodušení celého buildovacího workflow.
Client A může dělat úpravy na TESTu a PRODukci i bez přístupu k source repository.
Vždy je nasazovaná otestovaná verze (pokud Client A tento krok záměrně nepřeskočí).

32bitová ASP.NET aplikace na x64

2009-12-06T12:20:00Z

Přešli jste z 32bitové platformy na 64bitovou a najednou vám vaše ASP.NET aplikace začala vyhazovat divné chyby? Pracujete na 64bitovém prostředí, ale potřebujete z ASP.NET aplikace volat 32bitové knihovny/ovladače?

Přesně tyto problémy jsem řešil po přechodu na x64 Windows7. Najednou mi přestaly chodit ASP.NET aplikace využívající 32bitový Oracle client. Produkční servery stále běží na 32 bitech, takže změnou ovladačů na x64 cesta nevede. Naštěstí mi jako obvykle pomohl pan Google. Nejprve jsem narazil na spoustu příspěvků, kde si lidé pomalu rvali vlasy, protože problém ne a ne vyřešit. Což ostatně dalo podnět i k vzniku tohoto krátkého příspěvku.

Pak jsem narazil na [1]. Autor popisuje několik cest, jak se dobrat k cíli. Pro mě nejjednodušší cesta byla prostě si řešení naklikat:

Otavřít IIS7 Manager.
Na položce "Application Pools" vybrat "Add Application Pool..."
Nový pool pojmenovat třeba "x86".
Kliknout na něj v seznamu a zvolit "Advanced Settings..."
Vlastnost "Enable 32-Bit Applications" změnit na True.
Application pool problematické webové aplikace pomocí "Basic Settings..." změnit na "x86".

Zdroje

[1] Rakki Muthukumar - IIS7 - Running 32-bit and 64-bit ASP.NET versions at the same time on different worker processes
http://blogs.msdn.com/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx

Dotazování Active Directory

2009-12-06T10:48:00Z

Potřebovali jste někdy zobrazovat uživatelům intranetové aplikace funkcionalitu omezenou podle jejich příslušnosti do určité skupiny (manager, editor, lopata)? Zkoušeli jste to někdy dělat pomocí Active Directory? Jde to docela snadno.

Co je to vlastně to Active Directory?

Active Directory je implementace adresářových služeb LDAP firmou Microsoft pro použití v prostředí systému Microsoft Windows. Active Directory umožňuje administrátorům nastavovat politiku, instalovat programy na mnoho počítačů nebo aplikovat kritické aktualizace v celé organizační struktuře. Active Directory ukládá své informace a nastavení v centrální organizované databázi.

Adresářová služba Active Directory je rozšiřitelná a škálovatelná adresářová služba, která umožňuje efektivně uspořádat síťové prostředky.

vyžaduje instalaci služby DNS
je založena na standardních internetových protokolech
jednoznačně definuje strukturu sítě
organizuje skupiny počítačů a domén

LDAP (Lightweight Directory Access Protocol) je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru. Podle tohoto protokolu jsou jednotlivé položky na serveru ukládány formou záznamů a uspořádány do stromové struktury (jako ve skutečné adresářové architektuře). Je vhodný pro udržování adresářů a práci s informacemi o uživatelích (např. pro vyhledávání adres konkrétních uživatelů v příslušných adresářích, resp. databázích).

Více detailů naleznete na Wiki (viz [1] a [2]), odkud jsem si také vypůjčil výše uvedené definice.

V tomto článku se nebudeme podrobně zabývat všemi možnostmi Active Directiry, ale zaměříme se jen na informace o uživatelích.

Co se dá z Active Directory zjistit o uživatelích?

No, skoro všechno. Nejzajímavější atributy jsou tyto:

jak se uživatel jmenuje (displayname)
jaké má uživatelské jméno (userprincipalname)
jakou má emailovou adresu (mail)
jaký má pracovní telefon (mobile)
kterého odboru je členem (department)
kdo je jeho nadřízeným (manager)
do kterých skupin patří (memberof
a další volitelné atributy (extensionattributeX); každá organizace může definovat své vlastní

Jak se Active Directory dotazovat?

Špinavou práci za nás už naštěstí odvedl Microsoft. Objekty pro práci s Active Directory implementovány v rámci .NET Frameworku v namespace System.DirectoryServices.

Nejvíce nás bude zajímat třída DirectorySearcher, která v Active Directory vyhledává. Této třídě nejprve musíme říct, co a kde chceme vyhledat.

Co chceme najít, specifikujeme pomocí nastavení filtru. Jedná se v podstatě o jinak zapsanou WHERE podmínku, kterou používáme pro dotazování do databází (v tomto případě hierarchické databáze). Dotaz na nalezení konkrétního uživatele může vypadat takto:

(&(objectCategory=user)(userPrincipalName=karel.ctvrty@domain.net))

Kde chceme hledat, je vhodné určit co možná nejpřesněji. Čím přesnější cesta, tím kratší doba vyhledávání a lepší výsledky. Cesta (Path) je zadávaná v notaci uvedené např. v [5]. Pokud chceme hledat ve všech uživatelích v doméně, můžeme cestu definovat jako „LDAP://DOMAINNAME“.

A nyní prakticky...

K článku jsou přiloženy dva projekty.

ActiveDirQuery – rozšířené [3]

vyhledávání uživatelů, počítačů a tiskáren podle jejich jména (uživatelů podle přijmení)
implementováno jako WinForm aplikace

ActiveDirListing

vypsání všech dostupných atributů právě přihlášeného uživatele
implementováno jako ASP.NET aplikace

aplikace musí mít aktivovanou authentikaci „Windows Authentication“ a zakázanou „Anonymous Authentication“
správci IIS 7 musí komponentu „Windows Authentication“ ručně doinstalovat, protože v základní instalaci není obsažena
„Windows Authentication“ funguje pouze v kombinaci s Internet Explorerem

Hmm, a odpověď na úvodní otázku? Jak teda vlastně zjistím, do kterých skupin patří aktuálně přihlášený uživatel? Nejsme v mateřské školce, proto si kód musíte vytvořit sami. K řešení můžete použít následující kousky:

zjištění aktuálně přihlášeného uživatele – ActiveDirQuery.
formulace Active Directory filtru – tamtéž
příslušnost ke skupině v Active Directory – pomocí atributu „memberof“, implementace je v [4]

Závěrem

Active Directory je mocným nástrojem, zejména pokud chceme nahlížet do organizačních struktur. Dá nám odpovědi na mnoho otázek a jeho využíváním se vyhneme duplicitním definicím skutečností, které jsou již definovány jinde.

Nicméně nic se nemá přehánět a složitější dotazy do Active Directory mohou naši aplikaci citelně brzdit (viz diskuse v rámci [4]). Proto je pro náročnější aplikace vhodné zvážit, zdali není vhodnější místo přímých dotazů do Active Directory stáhnout každou noc aktuální stav věcí, které nás zajímají a dotazovat se raději našich vlastních databázových struktur.

Zdroje

[1] http://cs.wikipedia.org/wiki/Active_Directory

[2] http://cs.wikipedia.org/wiki/LDAP

[3] Sriram Chitturi - Querying Active Directory using .NET classes and LDAP queries
http://www.codeproject.com/KB/system/activedirquery.aspx

[4] silentthread - Check if user is a member of an Active Directory Group
http://www.vbforums.com/showthread.php?t=415856

[5] LDAP Pathnames - Distinguished Names
http://www.selfadsi.org/ldap-path.htm