rarouš.weblog

Jednoho osvíceného popůlnočního období posilněn podporou kamaráda Johnyho jsem se rozhodl, že sociální sítě už ee. A šel na Twitter a dal zrušit účet, šel na Facebook a dal zrušit účet. A šel na FriendFeed a podobnou volbu nenašel. Ostatně ji nemáme ani na Tropu. :) (Pokud někdo účet na Tropu zrušit chce, nechť se ozve nejbližšímu adminovi, ten to jistě zvládne.)

Twitter je dost nekompromisní, oznámí vám, že tato akce je nevratná a všechny vaše tweety budu smazány. Jak řekl, tak se stalo. :)

Facebook na to jde jinak. Všem těmhle miloučkým lidičkám se po tobě bude stýskat! Ale pokud si to rozmyslíš, všichni na tebe budou čekat, profil budeš mít stejnej, jako si ho tu zanechal. Stačí se jen znovu přihlásit a vše je jak bylo. Tedy skoro vše. Ty kurvy resetujou nastavení notifikačních e-mailů. Takže potom, co se mi přilogoval Trillian na Facebook Chat, který jsem zapomněl odebrat, byl můj profil zpět a FB mě začal spamovat notifikačním hnusem…

Co z toho plyne? Pokud toužíte po mém Twitter spamu, stále je produkován na FriendFeedu. Občas tam vaše tweety komentuju nebo to se mi líbíuju. A člověk má najednou o trochu víc času na lepčí věci. Fakt!

Považuji se za C# vývojáře, ale každý den používám spoustu dalších jazyků. Je znalost jazyka opravdu to, co z nás dělá programátory?

C#

Jazyk, který používám pro psaní serverových částí webových aplikací, konzolových utilit a služeb. Imperativní objektový jazyk s funkcionálními vlastnostmi se hodí skoro na všechno.

Boo

Boo používám hlavně na části, které se mohou u aplikace měnit i po zkompilování aplikace. Jeho silnou vlastností je tvorba DSL a díky tomu je konfigurace aplikací příjemnou záležitostí.

JavaScript

Původně jsem se JavaScriptu vyhýbal a neměl jsem ho rád. Pak jsem mu ale přišel na chuť a zjistil, jak moc pěkný jazyk to je a co všechno se s ním dá dělat. Používám výhradně na oživení webových stránek.

PowerShell

S tímto jazykem teprve začínám, ale některé jeho vlastnosti jsou opravdu zajímavé. Snažím se v něm psát scripty pro automatizaci některých rutin na serverech.

MSBuild

XML jazyk, který používám pro build a deployment scripty. V nové verzi podporuje i vkládání PowerShell scriptů a stává se tak ještě zajímavějším nástrojem.

XHTML

Další XML jazyk, který používám pro tvorbu prezentační části webových aplikací.

CSS

Ovládnutí tohoto jazyka může vypadat jako hračka, ale často rozeznáte mistry od obyčejných dělníků. Používám pro stylování prezentační části webových aplikací.

T-SQL

Dotazovací jazyk do databází není mojí nejsilnější zbraní, ale přesto v něm dokážu napsat některé zajímavé věci. S tím, že používám NHibernate, se mi nutnost jeho použití trochu snižuje, ale stejně člověk potřebuje občas udělat nějaké změny ve schematu nebo nějaký report.

Texy!

Tahle syntaxe mi pomáhá při psaní textů na web takřka denně.

Sešla se mi tu sbírka devíti jazyků, které používám takřka denně ke svojí práci, a to jsem schválně opomněl všechny ty XML dialekty pro různé konfigurace. :)

Jazyk je pouze nástroj a každý se hodí k jinému účelu. Stává se, že některé jazyky si najdou cestičku, jak se dostat do jiných a mnohdy je to výhoda. Obzvlášť, pokud oba známe. Samozřejmě je dobré mít povědomí i o jiných jazycích, jejichž myšlenky nás mohou obohatit i v našem oblíbeném jazyce.

Občas není na škodu být lenivý, mnohdy se to vyplatí! To platí i o našich programech, zejména o těch, které zpracovávají veliké množství dat. Jistě si říkáte, jak může být můj program lenivý, já přeci chci, aby byl co nejvýkonnější. Ano, to se nevylučuje, právě naopak! :)

Když jsem nedávno psal o tom, že Vracet list je špatné, neshledal jsem se s velikým porozuměním. Tento článek byl o návrhu rozhraní našich tříd. Dneska se podíváme na implementační detaily a výhody plynoucí z vracení (zvracení?) IEnumerable<>.

LINQ2SQL a metoda ToList()

Začněme tedy u nevýhod užívání generického listu v LINQu. Vsadím se, že většina z vás pro vykonání LINQového dotazu do databáze zavolá metodu ToList(). Okamžitě se tím vykoná dotaz a jeho výsledek je natažen do paměti, konkrétně jako položky generického listu. Jistě se tím zvýší výkon při iteraci přes výslednou kolekci. To je super, ale pro pro výpis používat velice drahý obal v podobě listu? List umožňuje kolekce snadno modifikovat, to je jistě skvělá vlastnost, ale také sebou nese zbytečně alokovanou paměť navíc.

Mnohem výhodnější je volat metodu ToArray(), která vykoná dotaz úplně stejným způsobem, ale vezme si jen tolik paměti, kolik opravdu potřebuje, nehledě na to, že samotný .net runtime je na práci s Array optimalizovaný. Jednoduchou změnou můžeme ušetřit spoustu paměti a zlepšit tak výkon naší aplikace. Pokud jsme však do našich rozhraní zanesli IList<>, musíme teď měnit spoustu kódu, protože náš původní návrh byl krátkozraký.

Zpátky k lenivosti

To, co jsme si popsali v předchozích řádcích, nemá s lenivostí stále nic společného, jde jen o malou optimalizaci dychtivého přístupu k datům (eager loading). Ten samozřejmě nemusí být z principu špatný, ale hodí se pouze pro data omezeného rozsahu. Pokud zpracováváme velké nebo předem neznámé množství dat je lepší zlenivět. Tím se opět vracíme k IEnumerable<>.

Vezměme si hypotetický příklad že náš program bude zpracovávat nekonečný zdroj pravdy:

static IEnumerable<Boolean> GetInfinityTruth() {
  while (true) {
    yield return true;
  }
}

Fůj, napsal jsem nekonečnou smyčku. Hele, ale jak jinak byste chtěli udělat nekonečný zdroj pravdy? Pomocí listu? Těžko. ;) Takovýhle kód je zcela validní a bezproblémový. Tedy do doby, než se najde někdo šikovný, komu se hodí list, a nad GetInfinityTruth() zavolá ToList(). Asi nám vyskočí OutOfMemoryException. :)

Vážně, výhodou tohoto kódu je, že (teoreticky) vrací nekonečné množství dat a přesto se s ním dá v klidu pracovat, aniž by nám sežralo adekvátní množství paměti (opět nekonečné). A to díky lenivosti! S takovýmto přístupem se nám totiž vyhodnocuje vždy jen jeden prvek z kolekce a to až v případě, že je opravdu potřeba. Oddalujeme načítání prvku do doby, kdy s ním opravdu budeme něco dělat.

Další výhodou je, že zcela bez problémů, můžeme celou tu nekonečnou pravdu popřít:

static IEnumerable<Boolean> Disclaim(this IEnumerable<Boolean> source) {
  return source.Select(value => !value);
}

Samozřejmě bych to mohl napsat i takhle:

static IEnumerable<Boolean> Disclaim(this IEnumerable<Boolean> source) {
  foreach(bool value in source) {
    yield return !value;
  }
}

Ale to je příliš mnoho psaní. Nepište zbytečný kód!

Teďka, když zavolám GetInfinityTruth().Disclaim(), dostanu nekonečný zdroj nepravdy, tedy samé lži. :) Opět to funguje tak, že je popřen každý konkrétní prvek, až když na něj dojde, ne všechny najednou, to by bylo moc práce. On se totiž příjemce naší nekonečné pravdy může kdykoli rozhodnout, že už ho to nebaví. A co my pak s tím, že jsme mu dopředu připravili krásné lži? Nic. Byla to zbytečná práce. V tomto případě se lenivost vyplatila.

Závěr

„Poslouchaj Roubíček, oni jsou nejspíš blázen. Nás tu krměj o nekonečné pravdě, co my s tím?“ No, je to určitá abstrakce. ;)

Související

• Lazy, eager, explicit loading – o co jde?
• Lazy evaluation
• Lazy evaluation (and in contrast, eager evaluation)
• Lazy LINQ and Enumerable Objects

1. Pokud máte nápad, je vám to prd platné, dokud ho neuvedete v život. Nerealizovaný či nerealizovatelný nápad nemá žádnou hodnotu. Realizace sebeblbějšího nápadu je mnohem hodnotnější.
2. Pokud máte sebemenší realizaci nebojte se s ní jít ven. Nečekejte až budete mít dostatek featur, které jsou přidanou hodnotou oproti konkurenci. Je totiž velice pravděpodobné, že o ně nikdo nestojí.
3. Pokud něco máte, snažte se to vyladit. Nesnažte se přidávat další vlastnosti, které budou stejně nekvalitní jako ty současné.
4. Nedávejte prioritu na vyřeší chyb, které se stávají jednou za měsíc nebo dva. Řešení takových chyb právě teď je nepřiměřeně drahé.
5. Pokud máte možnosti levně/zdarma promovat váš web, nečekejte až bude vhodnější. Udělejte to hned. Udržovat povědomí o službě musíte neustále. Obzvlášť pokud začínáte. Využijte každé možnosti se zviditelnit. Nečekejte na příhodnější dobu, ta už nikdy nemusí přijít.

Po delší době přicházíme s dalším buildem Tropu, který je tentokrát ve znamení Facebook Connect. Od dnešního dne se můžete na Trop.cz přihlašovat pomocí vašeho Facebook účtu. Facebook se tak zařadil mezi Seznam, Google, Twitter a další OpenId poskytovatele přihlašování, kteří už na Tropu jsou.

Facebook Connect

Stávající uživatelé

Stávající uživatelé si mohou svůj účet propojit s Facebookem v editaci profilu. Jak na to, se můžete podívat v následujícím krátkém videu: Jak propojit účet s Facebookem.

Můžete si všimnout, že jsem potvrzoval práva na publikování. To proto, že Trop nyní umí posílat vaše recenze na zeď. Pokud při propojování s facebookem potvrdíte publikování, budou se vaše nové recenze posílat i na Facebook. Nemusíte psát, že se vám někde líbilo/nelíbilo dvakrát, stačí to napsat na Trop a vaši přátelé se o tom dozvědí.

Noví uživatelé

Noví, ještě neregistrovaní uživatelé mají nyní další možnost, jak se snadno na trop zaregistrovat a nezatěžovat se s vyplňováním profilu. Vše potřebné se vyplní z Facebooku.

Recenze

Dalších změn se dočkaly recenze. Nyní konečně můžete vaši recenzi zpětně upravit včetně tagů a rozšířených hodnocení. Textové pole pro editaci je nyní větší a úprava je mnohem pohodlnější. Další z novinek je hodnocení recenzí. Pokud se vám něčí recenze líbí, můžete jí posunout nahoru svým hlasem. Samozřejmě můžete poslat dolu i recenze, které nemají žádnou užitnou hodnotu. Každý registrovaný uživatel má právo jednou zahlasovat k recenzi někoho druhého.

Tlačítka pro editaci a hlasování najdete v pravém horním rohu po najetí na recenzi.

Twitter

Ode dneška můžete sledovat, co se o Tropu štěbetá na Twitteru. Na domovské stránce máme nyní widget s Twitterem. Podobně přibyl widget s Twitterem na profilové stránky uživatelů, kteří mají svůj Twitter spojený s Tropem. Můžete tam snadno vidět, čím se tropáci zabývají i mimo psaní zajímavých recenzí. :) Pokud chcete vědět, co štěbetá Trop, můžete ho sledovat také. Najdete zde mimo jiné i seriál tipů na zajímavá místa.

Přání a oprava bugů

Snažili jsme se splnit vaše přání, která nám můžete posílat (a posíláte) na náš uservoice. Některé z nich jsem již zmínil výše, mezi dalšími je oprava hledání, nyní opět můžete hledat i mimo Prahu. Byl vylepšen způsob jakým se posílají chybové stránky, nyní už by měly být jednotné a brzy i o něco použitelnější.

V každé aplikaci, kde se pracuje s daty, se dostaneme do situace, kdy se nad daty potřebujeme dotazovat. Pokud přijmeme za svůj vzor Repository, můžeme se dostat do situace, podobné té v následující ukázce:

public interface IArticlesRepository {
  Article FindById(long id);
  IEnumerable<Article> FindAll(PagingInfo paging);
  IEnumerable<Article> FindByCategory(Category category, PagingInfo paging);
  IEnumerable<Article> FindByAuthor(User author, PagingInfo paging);
  IEnumerable<Article> FindByTag(string tag, PagingInfo paging);
}

Jak vidno s každým typem dotazu, rozšiřujeme rozhraní naší repository. Což porušuje Open/closed principle – jeden z pilířů Solidní architektury. Ten nám říká, že objekt by měl být otevřený k rozšíření, ale uzavřený k modifikaci. Přidáváním dalších metod ho očividně rozšiřujeme. Jak na to?

Jedním z možných řešení je zavedení dotazovacích objektů, kde využijeme kompozice k docílení lepšího návrhu. A protože jde o obecný mechanismus, můžeme ho pěkně generalizovat. Dále budu předpokládat, že pracujeme vůči datovému zdroji podporujícímu LINQ dotazování, jako je NHibernate.Linq, LINQ2SQL nebo EntityFramework.

public interface IQueryObject<T> {
  int Count(IQueryable<T> table);
  IEnumerable<T> Fetch(IQueryable<T> table);
  T FetchOne(IQueryable<T> table);
}

Dotazovací objekt má tři metody. První spočítá kolik objektů splňuje podmínky dotazu. Druhá vrátí kolekci vybraných objektů a poslední vrací jedinečný záznam. K takovému rozhraní si můžeme vytvořit bázovou třídu, která nám pomůže s rychlejším vytvářením konkrétních dotazů.

public abstract class QueryObjectBase<T> : IQueryObject<T> {

  protected QueryObjectBase<T>(PagingInfo paging) {
    Paging = paging;
  }

  public PagingInfo Paging { get; private set; }

  protected abstract IQueryable<T> CreateQuery(IQueryable<T> table);

  public virtual int Count(IQueryable<T> table) {
    return CreateQuery(table).Count();
  }

  public virtual IEnumerable<T> Fetch(IQueryable<T> table) {
    return CreateQuery(table).
      Skip(Paging.Skip).
      Take(Paging.PageSize).
      ToArray();
  }

  public virtual T FetchOne(IQueryable<T> table) {
    return CreateQuery(table).FirstOrDefault();
  }
}

Konkrétní dotazovací objekt pak ve většině případů implementuje jedinou metodu, která vrací LINQ dotaz. V případě potřeby si však konkrétní implementace může připravené metody změnit k obrazu svému. Máme zde zavedenou i konvenci stránkování, která předchází generování neomezených dotazů do databáze. A teď už nám zbývá jen zabalit to pěkně do nějakého DAO objektu.

public interface IQueryExecutor<T> {
  int Count(IQueryObject<T> query);
  IEnumerable<T> Fetch(IQueryObject<T> query);
  T FetchOne(IQueryObject<T> query);
}

DAO objekt jediný zná konkrétní implementaci datového uložiště, kterou předává do dotazovacího objektu jako IQueryable<T>. Výsledné použití v praxi může pak vypadat následovně:

var articles = _articlesDao.Fetch(new CategoryArticlesQuery(category, pagingInfo));

Kde konkrétní implementace dotazovacího objektu vypadá takto:

public class CategoryArticlesQuery : QueryObjectBase<Article> {

  public CategoryArticlesQuery(Category category, PagingInfo paging)
    : base(paging) {
    Category = category;
  }

  public Category Category { get; private set; }

  protected override IQueryble<Article> CreateQuery(IQueryable<Article> table) {
    return from article in table
           where article.Category == Category
              && article.IsPublished
           orderby article.PublishDate descending
           select article;
  }
}

Výhodou i je, že pokud potřebujeme upravit dotaz, děláme to vždy jen jednou na jednom místě.

Pokud se dostanete do situace, že budete potřebovat lokalizovat URL adresy vaší webové aplikace, máte hned několik možností, jak to řešit.

Jedno z možných řešení, které se mi ani trochu nelíbí, popsal Augi ve svém článku ASP.NET MVC – lokalizace URL. Já mám raději jednoduchá řešení, která nepotřebují hackovat systém. :)

Když jsme začali psát Trop, byl celý v angličtině. Díky konvencím, které jsem popsal v článku Pojmenované routy v ASP.NET MVC, měla naprostá většina stránek svojí vlastní routu. A protože definice routy není nic jiného než textový řetězec, přesunul jsem jej do resource souboru Routes.resx. To byl první krok.

Když jsme vymýšleli, jakým způsobem poběží jednotlivé jazykové mutace, bylo jasné, že každá mutace bude mít vlastní top-level doménu a bude to samostatná instance aplikace. To je super, protože se pak dá využít konfigurační sekce globalization, kde se nastaví jazyk prostředí konkrétní instance, podle kterého se i vybírají konkrétní resource soubory.

Česká instance pak má ve web.configu následující řádek:

<globalization culture="cs-CZ" />

Díky tomu se použijí routovací pravidla z Routes.cs.resx a URL adresy se generují česky, aniž bych musel v kódu cokoli změnit. Samozřejmě nejsou přeložená všechna routovací pravidla, spousta akcí, které jsou pouze POST, překlad nepotřebuje, protože nejsou součástí prezentační vrstvy.

Nakonec veškeré úsilí, které bylo k implementaci lokalizovaných URL potřeba, bylo v tom, embedovat definované routy do resource souboru, s čímž mi ochotně pomohl Refactor! Pro. :) Zbytek je věc konfigurace v deployovacím scriptu. Ale to už je na jiné povídání.

Co je to za blbost, říkáte si.

Každý cvičí

Když se podíváte do jakékoli oblasti lidského působení, zjistíte, že všichni mistři pravidelně cvičí, aby se zdokonalovali nebo jen udržovali formu. Proč by programátoři měli být něco extra? I programátoři musí cvičit! Jen cvičením dosáhnete požadované formy.

Katy

Pro cvičení programátorů dnes vznikají různé katy (znáte z karate nebo juda), které jsou v podobě zadání, které byste měli zvládnout naimplementovat pomocí TDD za určitý čas. Cvičení takové katy by vám mělo přejít do krve, každý stisk klávesy by měl být zcela automatický a intuitivní, podobně jako se cvičí katy v karate. Abyste to vše stihli, musíte minimalizovat saháni na myš na úplné minimum. Musíte se naučit ovládat vaše vývojové prostředí a dostat z něj maximum. Musíte se naučit dělat věci co nejjednodušeji, ale výsledek musí být uspokojivě kvalitní. Čistý kód.

Hudba

U katy byste měli mít správný rytmus, aby vše odsejpalo jak má. Proto je důležitý výběr správné hudby, která udává rytmus a podporuje správné flow vašeho cvičení. Mnozí si vybírají nějakou klasiku, třeba Rachmaninova. Já si vybral taneční klasiku Pryda – Aftermath (Original Extended Mix), která má zajímavé progresivní pasáže a navíc trvá celých 15 minut. Na jedno 30minutové cvičení mi tedy vyjde poslech přesně 2×. Můj cíl, je dát celou katu na jeden jediný poslech.

Výzva

Když si vytyčíte nějaké cíle, musíte jim něco obětovat, sáhnout si na dno svých možností. Pojďte do toho také! Pojďte cvičit a staňte se mistry! Někteří budou nuceni doinstalovat lepší nástroje, které zvýší jejich produktivitu, jiní přijdou na to, že jazyk, ve kterém píší, je zdržuje a budou muset switchnout na produktivnější. :) Pojďte se poměřovat, každé ráno po cvičení hoďte svůj výsledek na štěbeták s tagem #tddkatacz.

Co cvičit

Já osobně začínám cvičit StringCalculator katu od Roye Osherova, ale je jich víc. Jsou tu katy na počítání prvočísel, výpočet výsledku bowlingu, převod římských čísel na arabská apod. Pokud se chcete inspirovat doporučuji navštívit stránky http://katas.softwarecraftsmanship.org/.

Každá aplikace se může dostat do stavu, kdy není vše, jak má být, a nastane chyba. Tyto stavy bychom neměli ignorovat, ale pečlivě ošetřovat. Jak na to se podíváme v tomto spotu.

ASP.NET obsahuje poměrně sofistikovaný mechanismus na zpracování chyb. Ukazuje celkem podrobné chybové výpisy, které jsou nám vývojářům velice užitečné. Nicméně nejsou užitečné naším uživatelům a ještě mohou leccos prozradit našim útočníkům. Proto by v produkci měly být tyto hlášky zakázané.

Konfigurace

Každá aplikace v produkci by měla mít nastavené pěkné chybové stránky, bez podrobností, co se stalo, ale s informacemi, kam dál uživatel může pokračovat. Popřípadě mu pomoci nalézt to, co hledal. K tomu slouží konfigurační element customErrors, kde můžeme nastavit režim zobrazování a jednotlivé stránky, které se mají zobrazit na určitý chybový kód.

Bohužel, systém je navržen zcela kokotsky a pokud chcete v konfiguraci nastavit pro 404 a 500 jiné stránky, jsou vraceny s kódem 200. Proto využijeme jen následující konfiguraci. Zbylá je celkem k ničemu.

<customErrors mode="RemoteOnly" />

Tím docílíme toho, že všechny requesty, které nejsou z tohoto serveru obdrží pěkné chybové stránky. Dotaz z daného serveru dostane podrobný chybový výpis, což se může hodit.

Zpracování chyb

ASP.NET MVC má v sobě základní mechanismus pro ošetřování chyb. Je jím ActionFilter HandleError, který renderuje pohled Error.aspx, pokud dojde k probublání neošetřené výjimky až do akce řadiče.

[HandleError]
public class MyController : Controller {
}

Procento chyb, takto zachytitelných, jistě není malé, ovšem není 100%. Nemusíme chodit pro příklad daleko a stačí udělat chybku v šabloně pohledu. Hned tu máme nepěknou chybovou stránku.

Takovouto chybu odchytíme až v Global.asax:

protected void Application_Error() {
#if DEBUG
  return;
#endif

  Exception exception = Server.GetLastError();

  Response.Clear();

  RouteData routeData = new RouteData();
  routeData.Values.Add("controller", "Error");

  if (IsPageNotFoundException(exception as HttpException)) {
    routeData.Values.Add("action", "NotFound");
  }
  else {
    routeData.Values.Add("action", "Error");
  }

  Server.ClearError();

  IController errorController = new ErrorController();
  errorController.Execute(new RequestContext(new HttpContextWrapper(Context), routeData));
}

Pokud máme aplikaci v debug modu (typicky u vývojáře) je vhodné nechat chyby probublat až k němu. Pokud jsme ale v releasu musíme chybu zpracovat. Na výpis chybové stránky nám poslouží ErrorController, který má dvě akce: NotFound pro 404 a Error pro 500.

public class ErrorController : Controller {

  [StatusCode(HttpStatusCode.NotFound)]
  public ActionResult NotFound() {
    return View();
  }

  [StatusCode(HttpStatusCode.InternalServerError)]
  public ActionResult Error() {
    return View();
  }
}

Díky způsobu hledání šablon v ASPX View enginu, můžeme na Error využít stejnou Error.aspx ve složce Shared jako pro chyby zachycené už na řadiči.

Neplatná referenční identita

Teď se ještě dostaneme k tomu, proč tu máme zpracování HttpException s kódem 404. Kde se vezme?

Typicky, když máme nějakou detail page, snažíme se pomocí nějakého jedinečného identifikátoru natáhnout zobrazovanou entitu. Pokud žádnou nenajdeme je vhodné vyhodit výjimku a protože jsme na úrovni webové aplikace, měla by to být HttpException s kódem 404, která říká, že hledaná stránka nebyla nalezena.

Její zpracování už máme výše vyřešeno. A to je snad pro dnešek vše. :)

Už je tomu tak, každá správná sociální služba se má šířit všema kanálama a dnes přibyl další.

Dneska najdete Trop skoro všude:

• Trop na Facebooku
• Trop na Twitteru
• Trop na Friendfeedu
• Trop Blog

Původně jsem chtěl blog nasadit na některý z existujících redakčních systémů. Výbíral jsem z Wordpressu, Oxite, AtomSite a nakonec nevybral ani jeden. :) Instalovat na server další databázový stroj (MySQL) jen kvůli blogu mi přišlo zbytečné – Wordpress padl. Oxite se zdá být zajímavým, protože na něm jsou postaveny prezentační weby Microsoftích konferencí a navíc je to napsaný v ASP.NET MVC (stejně jako Trop). Bohužel je to celé dost nepoužitelné a navíc chybí podpora pro správu uživatelů. Což je velký problém, kterým trpí i jinak zajímavě vypadající AtomSite.

Velké ostřílené distribuce jako SubText, BlogEngine.net nebo dasBlog se mi už zkoušet nechtělo a sáhl jsem po tom s čím dokážu dělat snadno a rychle. Ano, po stařičkém Gryphoonovi, který pohání i tento blog. Chtělo to jen pár drobných úprav a frontend, který byl jen a pouze na tomto blogu, už je nasaditelný i na jiné domény než rarouš.net. :) Možná ho o prázdninách dám nějak do kupky a vydám bastl hybrid Gryphoon 1.90. :)

Stay tuned.