Pred pár mesiacmi som sklepkal takú malú peknú zaujímavú a dosť obtiažnu
logickú hru. V lete som sa po rokoch strávených v Java lande
preorientoval na C# a .NET a chcel som si v novo-naučenom jazyku niečo
pekné naprogramovať. Už sa mi to povaľuje na disku nejakú dobu a ešte
som to vlastne nikde poriadne nezverejnil.
Hlavne z toho dôvodu, že na rozdiel od mojej predošlej hry v Jave vo forme appletu - Forest Defender - sa toto nedá načítať a hrať priamo v internetovom prehliadači (browseri). Túto hru s dominami si budete musieť stiahnuť v ZIP archive, rozbaliť a spustiť. K celej hre preto dodávam aj zdrojový kód pre zvedavcov alebo nedôverčivých ľudí.
Upozorňujem, že pre túto hru potrebujete mať nainštalovaný .NET
framework verziu 3.5 (asi), no na to vás už hra samotná upozorní keď sa
ju posnažíte spustiť bez prítomnosti .NET. To je už taká pliaga dnešných
hier. Na webovky potrebujete poväčšine Flash plugin. Na Java applety
potrebujete mať nainštalovanú Javu (JVM) a pre veci v C# alebo VB budete
potrebovať mať .NET framework. Ale každý Windows užívateľ celkom určite
aspoň nejakú verziu .NET nainštalovanú má.

Ako sa to hrá
No... prvá časť logickej hádanky je práve tá, že by ste odpoveď na otázku "Ako sa to hrá?" mali nájsť sami. Takže veselé hranie prajem tým, čo teraz
prestanú čítať a pokúsia sa prísť na to ako na vec sami. Veľa zdaru!
Pre tých čo by však radšej vedeli o čo ide samozrejme uvediem viac
podrobností: Na hracej doske je rozsypaná kompletná sada domino kociek
(blokov). Teda všetky od 0-0 po 6-6. Ty však nevieš ako sú kocky
poukladané a tvojou úlohou bude pospájať páry súsediacich štvorčekov aby
tvorili domino bloky. Vyhrávaš vtedy, keď sa ti podarí pospájať úplne
všetky na hracej ploche.
Ono sa mi to ťažšie vysvetľuje než to v skutočnosti je. Stačí stláčať
kocky a všimnete si, že keď označíte napr. kombináciu 3-3 tak sa vám
možno nejaké kocky kde inde (čo ste už predošle označili) ODznačia. A
aha, sú to kocky 3-3. Treba to potom poskladať nejak inač. Treba dosť
pohútať.
Veselé Kódovanie a šťastný Nový Rok!
== DOWNLOAD GAME ==
== DOWNLOAD SOURCE ==
Vyhľadával som určitú frázu na slovenskom Googli a vo výsledkoch sa
zobrazil odkaz na článok na mojich stránkach. Keď som na neho
klikol, zobrazila sa odporná výstražná stránka Firefoxu s upozornením o
nebezpečenstve návštevy mojej stránky. Niečo o tom, že nebol nájdený žiaden certifikát pri pripájaní sa na server cez HTTPS. O čom to je toto? Moja osobná stránka je založená na CMS systéme Joomla! a neposkytujem žiadnu užívateľskú sekciu, ani nemám žiadnu zabezpečenú zónu, v ktorej by užívatelia komunikovali cez protokol HTTPS.
Zázračne, Google v niekoľkých prípadoch uvádza vo svojich výsledkoch hľadania odkazy na správne stránky pod nesprávnym protokolom.
Upozorňujem, že tento článok sa týka len tých, čo majú stránky podávané Apache Web Server-om.
Keďže pochybujem, že by náhodný návštevník chcel pridávať bezpečnostnú výnimku do svojho prehliadača pre moju stránku, prv než ju navštívi, som presvedčený o tom, že ma takéto výsledky vyhľadávania penalizujú na návštevnosti mojej stránky. Bolo treba s tým niečo robiť. Príčinu som síce nezistil, ale so symptómami som si poradil. A to nasledovne:
Aby sa mi Google, či iné roboty, nešplhali po stránkach cez https, pridal som na svoje stránky sekundárny súbor robots.txt, s názvom robots_ssl.txt.
Obsah tohto súboru je jednoduchý:
User-agent: *
Disallow: /
Zakážeme všetkým robotom prístup k celej stránke. Zadaním lomítka by mala byť nedostupná celá stránka, jej hlavný adresár, aj všetky podadresáre.
Ako však povedať robotom prichádzajúcim cez HTTPS na súbor robots.txt, aby si pozreli moju alternatívnu verziu robots_ssl.txt? Zavŕtame sa do .htaccess súboru a pozrieme, či je zapnutý RewriteEngine, ak nie, potrebujeme pridať tieto riadky:
RewriteEngine On
RewriteBase /
Pridáme RewriteRule pre Apache, pomocou ktorého roboty prichádzajúce cez port využívaný pri komunikácii HTTPS protokolom budú presmerované na správny robots.txt súbor, teda v mojom prípade robots_ssl.txt vyhradený práve pre tieto roboty:
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^robots.txt$ robots_ssl.txt
Toto pravidlo ich nasmeruje na správne miesto, odkiaľ by už nemali pokračovať v prehľadávaní mojich stránok, pretože som nastavil Disallow: / Takto nastavené robots.txt súbory by v budúcnosti mali zabrániť tomu, aby sa vo výsledkoch hľadania zobrazovali linky na stránky s HTTPS protokolom. No čo s tými, čo Google už má vo svojom indexe a stále zobrazuje ľuďom pri hľadaní?
Vyhľadával som určitú frázu na slovenskom Googli a vo výsledkoch sa
zobrazil odkaz na článok na mojich stránkach. Keď som na neho
klikol, zobrazila sa odporná výstražná stránka Firefoxu s upozornením o
nebezpečenstve návštevy mojej stránky. Niečo o tom, že nebol nájdený
žiaden certifikát pri pripájaní sa na server cez HTTPS. O čom to je
toto? Moja osobná stránka
je založená na CMS systéme Joomla! a neposkytujem žiadnu užívateľskú
sekciu, ani nemám žiadnu zabezpečenú zónu, v ktorej by užívatelia
komunikovali cez protokol HTTPS.
Zázračne, Google v niekoľkých prípadoch uvádza vo svojich výsledkoch hľadania odkazy na správne stránky pod nesprávnym protokolom.
Upozorňujem, že tento článok sa týka len tých, čo majú stránky podávané Apache Web Server-om.
Keďže pochybujem, že by náhodný návštevník chcel pridávať
bezpečnostnú výnimku do svojho prehliadača pre moju stránku, prv než ju
navštívi, som presvedčený o tom, že ma takéto výsledky vyhľadávania
penalizujú na návštevnosti mojej stránky. Bolo treba s tým niečo robiť.
Príčinu som síce nezistil, ale so symptómami som si poradil. A to
nasledovne:
Aby sa mi Google, či iné roboty, nešplhali po stránkach cez https,
pridal som na svoje stránky sekundárny súbor robots.txt, s názvom
robots_ssl.txt.
Obsah tohto súboru je jednoduchý:
User-agent: *
Disallow: /
Zakážeme všetkým robotom prístup k celej stránke. Zadaním lomítka by
mala byť nedostupná celá stránka, jej hlavný adresár, aj všetky
podadresáre.
Ako však povedať robotom prichádzajúcim cez HTTPS na súbor
robots.txt, aby si pozreli moju alternatívnu verziu robots_ssl.txt?
Zavŕtame sa do .htaccess súboru a pozrieme, či je zapnutý RewriteEngine, ak nie, potrebujeme pridať tieto riadky:
RewriteEngine On
RewriteBase /
Pridáme RewriteRule pre Apache, pomocou ktorého roboty prichádzajúce
cez port využívaný pri komunikácii HTTPS protokolom budú presmerované na
správny robots.txt súbor, teda v mojom prípade robots_ssl.txt vyhradený
práve pre tieto roboty:
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^robots.txt$ robots_ssl.txt
Toto pravidlo ich nasmeruje na správne miesto, odkiaľ by už nemali
pokračovať v prehľadávaní mojich stránok, pretože som nastavil Disallow:
/ Takto nastavené robots.txt súbory by v budúcnosti mali zabrániť tomu,
aby sa vo výsledkoch hľadania zobrazovali linky na stránky s HTTPS
protokolom. No čo s tými, čo Google už má vo svojom indexe a stále
zobrazuje ľuďom pri hľadaní?
Prečítajte si prosím
zvyšok článku na mojich stránkach, kde by ma potešilo keby kliknete na facebook "Like" tlačidlo. Dúfam, že vám môj článok poslúži, ako i ostatným, čo sa mi už stihli na tento článok pozitívne vyjadriť.
Jedna z novších čŕt jazyku C# (od C# 3.0) sú anonymné typy (vytváranie objektov neznámeho typu, respektíve objektov žiadneho deklarovaného typu). Sú vynikajúce pri použití s technológiou LINQ, no je problém s konzumovaním týchto objektov po navrátení z funkcie. Anonymné objekty sa dajú navrátiť jedine ako typu object, ktorý potom však nemáme ako využiť bez toho aby sme ho explicitne pretypovali (explicit cast). No do akého typu - ako - chceme pretypovať objekt, keď je anonymný a jeho typ bol vytvorený takzvane on-the-fly (za behu)?
Mnohokrát si užívateľ musí vybrať jednu položku z množstva v ponuke ListBox alebo ComboBox a je to nesmierne uľahčenie života, keď môže označiť požadovanú vec priamim zadaním jednotlivých písmen. Teda napríklad pri výbere krajiny zo zoznamu všetkých krajín sveta v ComboBoxe je najjednoduchšie označiť ComboBox a začať vyťukávať "Slove"... a to by už malo stačiť na označenie položky "Slovensko" v zozname.
Nedávno som si naprogramoval malú utilitku na prehľadávanie (atď.) prednastavených farieb ktoré sú nadefinované v triede System.Windows.Media.Colors
Do ListBoxu som potom nasypal jednotlivé farby napojením ItemsSource na ObservableCollection triedy ColorVM (ktorá zastáva ViewModel jednotlivých farieb). Nastavil som DataTemplate pre datový typ ColorVM aby jednotlivé objetky boli zobrazované v ListBoxe (a všade inde) ako obdĺžnik farebnej vzorky, vedľa ktorého je umiestnený text s názvom farby.
<DataTemplate DataType="{x:Type local:ColorVM}" >...
Takto nadefinovaný DataTemplate v App.xaml zaručuje že všetky objekty typu ColorVM v rámci aplikácie budú zdieľať rovnaký vzhľad.

Prichystal som si aj políčko do ktorého užívateľ môže vpísať časti názvu farbieb a ListBox sa podľa zadaného textu prefiltruje. Avšak, po označení ListBoxu som si všimol, že sa nedajú označovať farby v ňom jednoduchým vyťukávaním názvu farby. Teda, ak by som dal Focus ListBoxu na obrázku, a začal vyťukávať "Toma", položka s farbou "Tomato" by sa neoznačila automaticky.
Ako teda donútiť ListBox (alebo ComboBox) aby označoval položky ako sme na to zvyknutí? ListBox v mojom príklade obsahuje objekty typu ColorVM a automatické označovanie položiek vieme, že funguje pri zoznamoch, v ktorých sú textové položky. Jednoduché riešenie teda aby aj náš zoznam sa dal prehľadávať automaticky postupným zadávaním písmen od začiatku slova nasleduje:
Stačí aby dátový typ jednotlivých položiek prekryl (override) metódu ToString. Keďže moja trieda ColorVM mala vlastnosť (property) Name, stačilo triedu ColorVM obohatiť o nasledovný kód:
public override string ToString()
{
return Name;
}
A hneď sa položky v našom ListBoxe dajú označovať automaticky vpísaním niekoľkých začiatočných písmen.
K tomtu článku som pripojil prílohu (Attachment) v ktorej nájdete celý VS2010 projekt WPFColors (utilitka spomínaná vyššie).
Keď padne rozhodnutie používať vo vašom projekte NHibernate, môžete si
v mnohých ohľadoch uľahčiť život (teda hneď potom, čo si omotáte hlavu
okolo tejto zázračnej technológie). V tomto blogu vám ukážem ako
dohovoriť NHibernate, aby automaticky udržiavalo timestamps na
vami-zvolených poliach (teda reálne budete potrebovať mať nanájvyš
jedno pole automaticky timestampované).
Tento článok nájdete aj na mojom technologickom Google blogu
Ako príklad si uvedieme nasledovné: Užívateľ vašej (webovej)
aplikácie uverejní komentár. Tento komentár bude vo vašej aplikácii
obsahovať samotný text komentára a časové pole DateUpdated, v ktorom
budete chcieť udržiavať dátum a čas zverejnenia/poslednej úpravy
komentára. Zakaždým keď užívateľ komentár zverejní, alebo upraví, a
obsah komentára je vpísaný/aktualizovaný v databáze, chceme aby sa
zaznamenal aj aktuány časový údaj. Toto by za vás mohlo robiť
NHibernate, stačí si ho tak nastaviť. Dobre sledujte nasledujúcich pár
riadkov kódu, alebo si tie riadky skrátka len skopírujte a použite.
Najprv vás zasypem kódom a potom trošku pokecáme o tom ako to
funguje. Budeme potrebovať triedu implementujúcu dve NHibernate
interface-y: IPreUpdateEventListener, IPreInsertEventListener. Táto
trieda bude potrebovať dva namespace-y, ktoré si môžeme pridať medzi
ostatné základné namespace-y ktoré dostaneme pri vytvorení novej čistej
triedy:
using NHibernate.Event;
using NHibernate.Persister.Entity;
Trieda samotná bude vyzerať takto:
1 public class TimestampOnInsertUpdate : IPreUpdateEventListener, IPreInsertEventListener
2 {
3 public bool OnPreUpdate(PreUpdateEvent @event)
4 {
5 return !AutoUpdateTimestamps(@event.Entity, @event.Persister, @event.State, true);
6 }
7
8 public bool OnPreInsert(PreInsertEvent @event)
9 {
10 return !AutoUpdateTimestamps(@event.Entity, @event.Persister, @event.State, false);
11 }
12
13 private bool AutoUpdateTimestamps(object entity, IEntityPersister persister, object[] state, bool isUpdate)
14 {
15 var dateTimeProperties = entity.GetType().GetProperties().Where(p => p.PropertyType.Equals(typeof(DateTime)));
16 var autoTimestampedProperties = dateTimeProperties.Where(p => p.GetCustomAttributes(false).OfType().Any());
17 if (!autoTimestampedProperties.Any())
18 {
19 return true;
20 }
21
22 IEnumerable propertiesToTimestamp;
23 if (isUpdate)
24 {
25 propertiesToTimestamp = autoTimestampedProperties.Where(p => !p.GetCustomAttributes(false).OfType().First().InsertOnly);
26 }
27 else
28 {
29 propertiesToTimestamp = autoTimestampedProperties;
30 }
31
32 if (!autoTimestampedProperties.Any())
18 {
19 return true;
20 }
34
35 var timestamp = DateTime.Now;
36 try
37 {
38 foreach (var propertyToTimestamp in propertiesToTimestamp)
39 {
40 Set(persister, state, propertyToTimestamp.Name, timestamp);
41 propertyToTimestamp.SetValue(entity, timestamp, null);
42 }
43 }
44 catch (InvalidOperationException)
45 {
46 return false;
47 }
48 return true;
49 }
50
51 private void Set(IEntityPersister persister, object[] state, string propertyName, object value)
52 {
53 var index = Array.IndexOf(persister.PropertyNames, propertyName);
54 state[index] = value;
55 }
56 }
Ďalej si budeme potrebovať nadefinovať svoju vlastnú atribútu (custom attribute)
AutoUpdatedTimestampAttribute, ktorej definícia bude veľmi jednoduchá:
[AttributeUsage(AttributeTargets.Property, AllowMultiple=false)]
public sealed class AutoUpdatedTimestampAttribute : System.Attribute {
public bool InsertOnly { get; set; }
public AutoUpdatedTimestampAttribute()
{
InsertOnly = false;
}
}
Naša modelová trieda bude potom môcť takto jednoducho
prehlásiť, že niektoré z jej vlastností (properties) potrebujú mať vždy
automaticky aktualizovanú časovú známku (timestamp). Príkladná trieda
dole napríklad našepkáva NHibernate, žeby bola rada keby sa jej ktosi
ujal a aktualizoval jej DateUpdated vlastnosť (pri každom uložení zmeny
alebo vytvorení nového záznamu v databáze). Taktiež sa zmieňuje, že by
bolo fajn keby pred vložením záznamu (ale len pre vložením) do databázy bola vlastnosť DateCreated nastavená na aktuálny dátum/čas.
...
public virtual string Comments { get; set; }
public virtual DateTime DateLastUsed { get; set; }
[AutoUpdatedTimestamp]
public virtual DateTime DateUpdated { get; set; }
[AutoUpdatedTimestamp(InsertOnly=true)]
public virtual DateTime DateCreated { get; set; }
...
Ešte nám treba objasniť NHibernate, že kde bolo tam
bolo, žila raz jedna trieda TimestampOnInsertUpdate, ktorá sa zaujíma o
dianie v NHibernate mechanizme pred insert-om/update-om. Stačí pár
riadkov medzi nakonfigurovanie NHibernate a vytvorenie ISessionFactory:
var nhConfig = new NHibernate.Cfg.Configuration().Configure();
var timestamper = new TimestampOnInsertUpdate();
nhConfig.EventListeners.PreUpdateEventListeners = new NHibernate.Event.IPreUpdateEventListener[] { timestamper };
nhConfig.EventListeners.PreInsertEventListeners = new NHibernate.Event.IPreInsertEventListener[] { timestamper };
return nhConfig.BuildSessionFactory();
Mohli by sme ich tu zaregistrovať viac než dosť, keďže
priradzujeme pole event listernerov. Mohli by sme si zostaviť celú radu
listenerov takto:
nhConfig.EventListeners.PreUpdateEventListeners = new NHibernate.Event.IPreUpdateEventListener[] {
timestamper, id_generator, some_other_listener, nonsense_generator, ...
};
...
Ale to hádam všetci vieme :-)
Ako to funguje
Naša
NHibernate IPreInsertEventListener a IPreUpdateEventListener
implementujúca trieda je asi najzaujímavejšia časť z toho čo som tu
uviedol. Preto som k jej kódu pripojil aj čísla riadkov, aby sa mi na
ňu lepšie komentovalo. (Ak vám čísla riadkov prekážajú pri copy-paste
robote, vedzte, že nie je prečo robiť paniku: Visual Studio má
schopnosť stĺpcovej editácie a tak si pokojne vložte
kód aj s číslami do Visual Studia a potom stlačte a držte Alt a myškou
označte celý stĺpec čísel a tabulátorov. Zmažeme a práca hotová.)
Najprv
však v skratke popíšem všetko ostatné a prečo sme to nakódovali tak ako
sme to nakódovali a nie nejak ináč (v článku uvedenom na spodku blogu
je uvedený trošku iný príklad používajúci IAuditable interface (ak sa
nemýlim)). Využitím vlastnej atribúty a neskôr reflection mechanizmu
získame flexibilitu - naše modelové triedy nemusia implementovať žiaden
konkrétny interface, ich DateTime vlastnosti nemusia mať také-či-onaké
konkrétne predpísané meno, ale je celkom na nás, ktorú vlastnosť
označíme našou atribútou. Ak by sme časom odpojili náš
IPreInsertEventListener / IPreUpdateEventListener od NHibernate
(rozhodli sa nepoužiť NHibernate na udržiavanie časových známok
(rozhodneme sa použiť default values na databázových poliach, resp.
databázové trigger-y alebo inú metódu), naše modelové triedy môžu
pokojne zostať nezmenené, pretože atribúty ani nemusíme odobrať - ak
nie sú nikým využité, nevadí.
Náš listener sa dá jednoducho
zapojiť / odpojiť z mechanizmu NHibernate, ako sme videli vyššie.
Samozrejme si podobným spôsobom môžeme naprogramovať iné aspekty
našej aplikácie a pripojiť ich do mechanizmu. V našej aplikécii sa
začne diať mágia :-) Tieto listenery musíme zapojiť do NHibernate
konfigurácie ešte pred požiadaním o konštrukciu ISessionFactory.
Implementácia
našej vlastnej attribúty je jednoduchá, stačí (ako pri každej vlastnej
atribúte) vytvoriť uzavretú - sealed - triedu dediacu od
System.Attribute a dodať tých pár základných riadkov. Komentár utratím
už len na nôtu tohto riadku:
[AttributeUsage(AttributeTargets.Property, AllowMultiple=false)]
Obmedzíme
použitie našej atribúty na vlastnosti (čiže aby sme nimi neokrašľovali
triedy / metódy atď.) a tiež aby sa mohla uplatniť len jedna atribúta
thoto typu na jednu vlatnosť (property). Bol by to chaos, keby môžeme
anotovať vlastnosť dvoma protichodnými atribútami:
[AutoUpdatedTimestamp]
[AutoUpdatedTimestamp(InsertOnly=true)]
public virtual DateTime MyProperty;
Náš zázračný listener by nevedel čo s takou vlastnosťou.
Náš
listener TimestampOnInsertUpdate na prvých dvanástich riadkoch len
implementuje metódy, ktoré musí, sú predpísané v
IPreInsertEventListener / IPreUpdateEventListener interface-och. Z
oboch metód zavolá magickú metódu AutoUpdateTimestamps a pošle jej to
čo treba na celý trik. To sú argumenty entity, persister, state a
isUpdate. Entity je náš modelový objekt ktorého stav sa snažíme vopchať
do databázy. Persister je objekt zodpovedný za vykonanie samotného
úkonu (emituje SQL príkaz(y)), state je aktuálny stav entity, ktorý
NHibernate extrahoval z entity a pokúsi sa ho persistovať (uchovať v
databáze) pomocou persisteru. Booleanská hodnota isUpdate len informuje
o tom, či sa koná insert alebo update (potrebné pre vlastnosti kde
atribúta má vlastnosť InsertOnly=true).
Riadok 15 získa z
entity všetky vlastnosti typu DateTime. Riadok 16 prezrie tieto
vlastnosti a vyberie z nich len tie, ktoré sme označili atribútou
AutoUpdatedTimestamp. Ďalej, ak v tomto bode entita nemá žiadne
pre-náš-listerner zaujímavé vlastnosti unikáme z metódy s návratovou
hodnotou true - všetko OK - vybavené.
Ďalej, od riadku 22 sa
venujeme tomu aby sme pri update-ovaní nemenili vlastnosti označené ako
InsertOnly. Vyfiltrujeme ich preč, aby sme nemenili to čo nemáme.
Na
riadku 32 sa znova pozrieme, či máme čo meniť, ak nie, padáme preč s
pozitívnou správou TRUE. Ďalej už je takmer všetko jasné: zaobstaráme
si timestamp (r.35) a ideme na vec - každej vhodnej vlastnosti zmeníme
hodnotu na aktuálnu časovú známku (1.)priamo na entite r.41, (2.) v
stave entity (argument state), ktorý bude persisterom zapísaný do
databázy r.40.
Na zmenu stavu entity si zavoláme na pomoc malú
metódku r.51, ktorá za pomoci informácií o persisterovi nastaví správnu
časť objeku state na patričnú hodnotu.
Krok na riadku 41 je
veľmi dôležitý: ako vysvetľuje stránka uvedená na spodku tohto článku,
vynechaním tohto kroku by sme si mohli privodiť veľa veľa starostí
debugovaním ťažko nájditeľných problémov. Hoci na databázovom servri by
sme mali časovú známku nastavenú správne, nebola by v synchróne so
stavom našej entity (náš objektový model by nebol zhodný s modelom
persistovaným v našej databáze), čo by očividne mohlo napáchať škodu v
rámci aplikácie. (Alebo aj nie, ak máme šťastie... radšej ani
neskúšajme.)
A to je všetko. Je to v podstate celé
jednoduché ako detská hračka, len človek sa samozrejme nenarodil s
inštinktívnou znalosťou NHibernate a C#, tak si pomáhame blogmi ako
tento. Dúfam, že som niekomu pomohol. Happy coding!
Niektoré časti tejto implementácie boli založené na kóde nájdenom v tomto
článku: Ayende Rahien a jeho článok o IPreInsertEventListener a IPreUpdateEventListener
Malá ukážka práce s Twitter API (užívateľský status), jQuery, a cross‑origin AJAX volaniami. Keď si chcete kamsi decentne umiestniť svoj (alebo niečí iný)
najaktuálnejší Twitter status, stačí vám malá troška JavaScriptu a
zázrak je hotový.
- Na svojom (alebo niekoho iného) twittri nazrite do zdroju stránky (View Source / View Page Source) vyhľadajte "id": a okopírujte si vaše ID. Ozaj neviem z kade ho inač vykopať.
[napr. moje id je 44183405]
- Požiadajte twitter API o statusy napríklad takto:
http://twitter.com/statuses/user_timeline/44183405.xml
- Alebo takto:
http://twitter.com/statuses/user_timeline/44183405.json
JSON sa mi viac pozdáva a dá sa z neho jednoducho vykopať to čo
potrebujeme v prípade, že výsledok spracuvávame v JavaScriptovej
funkcii (čo predpokladám) - Ak sa vám zdá byť navrátených dobrôt priveľa, stačí prikvačiť na koniec požiadavky
parameter ?count=2
Prečo práve 2? Čo vám ja viem? jeden nefunguje (vracia sa prázdny výsledok), dva vám
dá práva jeden posledný Tweet. Tak žiadajme o dva.
Za
predpokladu teda, že vo vašej web stránke máte zapojené jQuery a chcete
načítať svoj status do span-u s ID "twitter-status", bude vám stačiť
nasledovných pár riadkov:
$(function(){
$.getJSON("http://twitter.com/statuses/user_timeline/44183405.json?count=2&callback=?",
function(data){
$("#twitter-status").text(data[0].text);
});
});
Na tejto adrese nájdete tento príspevok aj s funkčnou ukážkou vyššie-uvedeného príkladu.
Na
tomto príklade je ešte jedna vec hodná povšimnutia: keďže AJAX
požiadavky musia byť vždy cieľené na server, z ktorého stránka prišla
(aby sa zabránilo rôznym cross-site scripting (XSS) attack-om)
teoreticky by toto nemalo byť možné. jQuery sa s týmto obmedzením
vysporiadalo tak, že stačí na záver URL pridať &callback=? jQuery
si potom namiesto otáznička dosadí názov vygenerovaného callbacku,
ktorý použije aby umožnilo cross-origin resource request. Samá mágia.
Ešteže nám stačí vedieť toľko, že pripojením magického slovka na záver
URL môžeme spytovať rôzne Web API ako twitter, flickr, facebook etc. a
nelámať hlavu nad nepeknými obchádzkami cez server-side proxies a tak
ďalej.
Dúfam, že spokojní, nie je toho veľa. Nemám čo dodať. Snažím sa radšej poradiť veľa zaujímavého, než málo do hĺbky rozbrblaného.
Programujem. Dobrovoľne a s piesňou na perách.
Peter Perhac (personal website, [SK])
Peter Perhac (blog on programming [EN])
Práve sa mi podarilo prísť na to, prečo mi môj malý skúšobný programík
s NHibernate nechcel ani za svet fungovať. Prv než zabudnem ako som
problém vyriešil a na čo všetko som cestou k riešeniu naďabil, chcel by
som si o tom urobiť záznam.
Problém spočíval v tom, že nech som sa snažil ako som sa snažil, stále
NHibernate vyhadzoval chybu "NHibernate.MappingException: No persister
for <class name>".
Užil som si pekné trápenie hľadaním problému. Preliezol som internet
krížom-krážom a našiel viacero možných príčin pre toto chybové
hlásenie, ale "no joy". Dosť frustrujúci bol fakt, že v práci pracujem
na projekte, kde úspešne mapujem s NHibernate a všetko klape. Prezrel
som niekoľko hodín video tutoriálov, prečítal niekoľko kratších aj
dlhších textov na NHibernate/Hibernate a už-už som si začínal myslieť,
že všetkému rozumiem, keď tu som doma narazil hlavou do steny a nemohol
som sa s NHibernate ani pohnúť. Neustále sa NHibernate sťažovalo na "No
persister for..."
Možné príčiny chyby NHibernate.MappingException
Message: No persister for <class name>
Chýba mapovací súbor (mapping file)
Proste
ste ho ešte nevytvorili alebo ste ho vytvorili mimo Visual Studio a
nepridali ste mapovací súbor do svojho projektu pomocou Solution
Explorer-u.
Možné riešenia
Uistite sa, že teda naozaj mapovací súbor pre danú entitu máte v
projekte. Je to XML súbor s názvom v tvare
"MenoMapovanejEntity.hbm.xml". Pokiaľ sa nemýlim, v názve súboru
ne*musí* byť meno mapovanej entity, ale musí mať koncovku ".hbm.xml"
(hibernate mapping.xml). V jednom mapovacom XMLku môžete mať
zmapovaných niekoľko entít naraz, ale neodporúča sa to, aby ste sa
potom vyhli chaosu.
Pokiaľ tento súbor existuje niekde v zložkách projektu, skontrolujte
ešte či vo Visual Studiu váš projekt zahŕňa tento súbor. V Solution
Exploreri kliknite na ikonku Show All Files, navigujte k mapovaciemu
súboru, urobte jeden pravý klik :-) a zvoľte Include in Project.
Build Action nastavená na Content
Jeden
z ďalších dôvodov prečo sa vám NHibernate môže stále sťažovať, že No
persister for... môže byť práve taký, že hoci mapovací súbor máte, aj
je Included vo vašom projekte, jeho Build Action je ešte stále
nastavená na "Content".
Riešenie
Toto musíte v okne Properties zmeniť na Embedded Resource, aby sa váš
xml súbor vkompiloval do výstupného .dll alebo .exe. Skontrolujte si,
či ste nastavili Embedded resource pre všetky vaše .hbm.xml mapping
files.
NHibernate konfigurácia nevie v ktorej knižnici (assembly) má hľadať mapovacie info
Ďalšia
často odporúčaná rada pri problémoch tohto typu je pridať element
mapping do session-factory konfigurácie v NHibernate konfiguračnej
sekcii vášho app.config súboru (ak teda je vaša NHibernate konfigurácia
umiestnená práve tam).
Riešenie
Vlastne, pokiaľ ste si zvolili metódu konfigurácie založenú na XML, tak
je jedno ci máte nastavenia v nejakom zvlášť súbore, či v ako sekciu v
app.config. Budete v nich potrebovať element mapping.
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="... />
...
<mapping assembly="Kniznica"/>
</session-factory>
</hibernate-configuration>
Tento element uvediete v poradí až posledný, každopádne po všetkých
"property" elementoch, ktoré nastavujú NHibernate session factory. Nič
viac v ňom nie je potrebné, len názov knižnice (assembly), ktorá
obsahuje mapované triedy a do ktorej sú vkompilované mapovacie súbory
.hbm.xml. NHibernate to pomôže v tom, že bude pri zavolaní metódy
Configure() vedieť ktorej knižnice sa ujať a prezrieť jej metadata.
NHibernate.Cfg.Configuration objekt nie je nakonfigurovaný
Tento
problém ma strašil niekoľko hodín. Kôli tomuto som sa vlastne odhodlal
napísať tento článok. Aj keď máte úplne všetko pre NHibernate nastavené
tak ako sa patrí a všetky mapovania máte namapované správne a
pozapájané do svojho projektu podľa všetkých múdrych rád, stále je
šanca že vám nič z toho nebude fungovať a že sa vám NHibernate stále
bude sťažovať, že No persister for... Ešte aj Stack Trace je
zavádzajúci. Popreklínal som si tvorcov NHibernate dosť keď som zistil
v čom bol problém.
Riešenie
Problém môže byť v tom ako si vytvárate NHibernate ISessionFactory. Tak napríklad mne sa podarilo nasledovné:
var nhConfig = new NHibernate.Cfg.Configuration();
ISessionFactory sessionFactory = nhConfig.BuildSessionFactory();
Problém
spočíval v tom, že hoci som svoj nový objekt NHibernate kofigurácie
vytvoril, nenakonfiguroval som ho zavolaním metódy Configure(). Možno
mi jedného dňa niekto vysvetlí, prečo volanie funkcie
BuildSessionFactory v nanakofigurovanom stave nevedie k
InvalidOperationException. Hore-uvedený kód krásne funguje, teda okrem
toho, že pri prvom pokuse o získanie perzistentnej entity cez interface
ISession (volaním metódy Load, Get, etc...) sa NHibernate sťažuje na No
persister for... Kôli tomuto čudesnému správaniu som zabil niekoľko
hodín vŕtaním sa v mojom kóde a prezeraním konfigurácií a mapovacích
súborov a vlastností projektových súborov. Pri tom jediné, čo bolo
treba urobiť pre odstránenie problému, bolo zavolať Configure() na
objekte Configuration
skôr než ho požiadame o vytvorenie ISessionFactory.
var nhConfig = new NHibernate.Cfg.Configuration().Configure();
...
Paráda,
tak a je po problémoch. Kto narazí na NHibernate.MappingException so
správou "No persister for..." a má v projekte všetko podľa vyššie
uvedených rád, ozvite sa mi, rád sa pokúsim pomôcť, resp. ak máte
riešenie, tak popis problému aj s riešením môžeme pripísať na zoznam.
Veselé kódovanie!
Programujem. Dobrovoľne a s piesňou na perách.
Peter Perhac (personal website, [SK])
Peter Perhac (blog on programming [EN])
Viac príspevkov