Programování v C#.Net » Xabatcha blog - Live and let live

Snažím se automatizovat provádění buildů na našem dev serveru. Pro CI používáme free verzi TeamCity.

Pro řízení buildu jsem nakonec vybral MsBuild. Zatím jsem jen na začátku a funkcionalita skriptu je dost omezená. Skripty momentálně umí provést release build, deployment a případnou kopii do cílového adresáře. Taky jsem zprovoznil twitter notifikaci o výsledku buildu.

Ještě potřebuji změnit některé hodnoty v config souboru a případně udělat backup do podadresáře pojmenovaném podle file version.

Tsunami development...

Odvážím se tvrdit, že toto je další typ metodologie, která se používá k vývoji sw. Tato metodologie se jmenuje Tsunami, jelikož Waterfall byl, v kontextu, příliš slabý název.

Podstatou tsunami development metodologie, je narušení normálního vývoje okamžitým releasem. Většinou netrpělivým investorem, který položí vašemu šéfovi nůž na krk.

Takže jakožto vývojář máte 24 hodin na dodělání základních (životních) funkcí a produkt, software, je vržen na produkční server. S testováním, které proběhlo maximálně na počítači vývojáře a když dobře, tak na builder serveru, na kterém je nainstalovaný CC nabo TC.

Po jakžtakž vypadajícím realeasu, který se nějak rozběhl na produkčním serveru,dochází ke kumulaci fatálních chyb. Takže následující dva týdny opravujete chyby nebo zjišťujete, kde všude vyskakuje NotImplementedException nebo se objevují vámi nedefinované exception.

U korporátních toto chování asi nebude projevovat tak často. V případě začínajících firmiček to bude asi běžný jev a zmateně pobíhajících lidiček rvajících si vlasy bude povícero.

Do které patříte VY?

Pokud uživatel zadá adresu bez začátečního www, tak se velmi pravděpodobně načtou žádané stránky, ale může dojít ke dvěma nežádoucím věcem. Pokud doména používá ssl certifikát, může dojít k chybě načtení certifikátu, jelikož nebude souhlasit adresa nastavená v certifikátu. A taktéž dochází k rankování adresy bez www, což je ve své podstatě nechtěné, pokud používáte doménu včetně www.

Co tedy dělat? Použít redirect 301 pro adresu bez www. Jak? Tady je ukázka použití v Aps.net.

protected void Application_BeginRequest(object sender, EventArgs e){

string authority = Request.Url.Authority;
if (authority.IndexOf("www.") != 0) {
Response.StatusCode = 301;
Response.Redirect("http://www." + authority + Request.Url.AbsolutePath, true); }

}

Vložením kódu do Global.asax docílíme požadovaného přesměrování.

Každý kdo vytváří webové stránky, aplikace se jistě dostal do stádia, kdy musel řešit optimalizaci pro SEO . Minimální podpora SEO spočívá v použití META tagů. V tomto případě Keywords a Description.

<meta name="description" content="Popis stránek s výstižným obsahem.">
<meta name="keywords" content="heslo, heslo, dalsi heslo">

Tímto je pokryta minimální implementace SEO v rámci webové aplikace a její indexace ve vyhledávačích. Samozřejmě toto je jen jedna část optimalizace SEO. V druhém kroku musíte nastavit samotné hodnoty tagu keywords a description.
V tomto příspěvku autor popisuje minimální tři kroky pro optimalizaci SEO vašich stránek. Využití DIV pro design stránek před použitím TABLE elementů. Nastavení meta tagů Keywords a Description a nastavit redirect pro zrušené stránky, pokud jsou již zaindexovány vyhledávači.

V klasickém ASP.Net je objekt RadioButtonList. Možnosti tohoto objektu jsou však omezené. Mým cílem bylo zobrazení seznamu voleb spolu se zobrazením obrázku, textu a to vše plně formátovatelné pomocí css.

Možným řešením je použití asp.net objektu Repeater, pokud ovšem nepoužíváte něco z placených balíčků. I tady to má háček, jelikož při použití Repeater a RadioButton dochází k modifikaci id jednotlivých RadioButton a tím nefunguje grupování. Tedy zaručení výběru jedné volby. Toto se dá však obejít implementací javascriptu, který lze nalézt zde a to včetně detailního popisu implementace. Ale touto cestou jsem se nevydal, zvolil jsem trochu jiné řešení.

Aneb co dělat s 'The server committed a protocol violation. Section=ResponseStatusLine' chybou

Narazil jsem na problém při komunikaci s webovou službou přes http protokol. Co mě ale na chybě zaráželo, že se objevovala jen při opakovaném volání. Při prvním requestu komunikace proběhla v pořádku a odpověď se zpracovala tak jak má. Při druhém zkolabovalo zpracování odpovědi na výše zmíněnou chybu.

Při googlování jsem většinou narazil na to, že se jedná o chybu zpracování hlavičky requestu. Tato chyba se pak řeší pomocí přidáním (tajného, vlastnost není standardně přístupná v kódu) konfiguračního elementu do config souboru. Viz.

<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing = "true"/>
</settings>
</system.net>

Tak jak se seznamuji s JQuery...tak zjišťuji, že se s tím opravdu dají dělat pěkné kejkle. Potřeboval jsem nějak implementovat jednoduché pseudo vyhledávání. Píši pseudo, jelikož mi šlo jen o zvýraznění vyhledaného textu. Původně jsem představoval, že zvýrazním vždy jednotlivé slovo, ale pak jsem tomu něco obětoval a zvýrazňuji jenom odstavec. I tak jde o efektní výsledek, vzhledem k tomu, že všechno probíhá na klientovy. A jak, že to vlastně funguje...

Tak jak to bývá, tak všechno většinou funguje lokálně na mašině programátora, ale jakmile se aplikace nahraje na produkční server s operačním systém Windows Server 2003 sp2, tak to všechno padá a nikdo neví proč. Momentálně jsem teď řešil problém s logováním na produkčním serveru. Na logování používám Logging z Enterprise Library. Kdo nezná, nechť následuje link.

Měl bych tu pro vás jednu vypečenou otázku z přijímacího pohovoru. Vyzkoušeno na vlastní kůži :-)

Já jsem měl k dispozici jen tabuli, fixu a představivost, tak jestli to budete zkoušet, tak to nejdříve zkuste nanečisto bez googlování.

A otázka zní: Vytvořte kód, který obrátí pořadí slov ve vstupním řetězci. Tedy něco jako toto:

public string ReverseWords(string input){

string output;

// vase implementace

return output;

}

Tak schválně, kdo bude mít nejkratší implementaci. Řešení bude publikováno do týdne, tedy neděle 9.11.2008.

P.S> tak jsem řešení stáhl na tři řádky....

Tak jsem se trochu vrtal v šablonách a upravil jsem použití transakce a pár jiných drobností. Zdroják viz níže.

Původní způsob použití v minulém příspěvku je stále platný a funkční. Na zde zmiňovaném způsobu použití transakce se mi líbilo využití USING klausule, která provede automaticky Dispose. Chci jen upozornit na jednu chybu, viz zkrácená verze SqlException: