Portál AbcLinuxu, 30. dubna 2025 11:21
19.2.2009 21:48
| Přečteno: 2373×
| Abíčko
|
V tomto blogu shrnu dvě témata týkající se Abíčka. První je drobná změna funkce monitoru, která zabrala nečekaně moc času, druhá je žádost o pomoc při hledání důvodu, proč načítání strának někdy zdržuje průzkum návštěvnosti NetMonitor, respektive servery gemius.
Bug číslo dvě v bugzille se týkal chybějícího seznamu stránek, které sledujete. Tato stránka nešla napsat, protože informace o uživatelích sledujících konkrétní objekt se ukládala do XML. Tak jsem vytvořil novou tabulku, přepsal ukládání dat, napsal migrační program, vytvořil makro pro zobrazování monitoru na stránce, nachystal cache pro lepší výkon, přepsal controller pro změnu monitoru, vyřešil problém se zobrazováním smazaných uživatelů a také vytvořil stránku se seznamem sledovaných stránek. Přibyla i funkce pro smazání všech monitorů jedním kliknutím. No, nakonec jsem změnil 50 souborů a zabralo to přes týden. Tak ať se vám stránka líbí.
Druhé téma je netmonitor. Jelikož Abíčko žije z reklamy, je pro nás kritické, abychom v něm byli zapojeni a návštěvníci jej neblokovali. Pro inzerenty jsou totiž jeho údaje velmi důležitým faktorem při rozhodování, kam zadají reklamu. Bohužel se nám stává, že měřící kódy zdržují načítání stránek, nebo je přímo zablokují. Pomalá reakce má pro nás dva negativní dopady. Za prvé uživatelé mohou ze stránky odejít rychleji, než se jejich návštěva zapíše. Druhý dopad je ještě horší, někteří uživatelé server úplně blokují a jsou tak pro naše inzerenty neviditelní.
Tento problém je reálný, viz tato diskuse. Nebo o něco starší komentář. Snažili jsme se to řešit, ale zřejmě to netrápí nikoho jiného, než jen nás. Nevšiml jsem si na žádném českém webu, že by je netmonitor, respektive gemius.pl zpomaloval. Proč jenom nás? Čím se lišíme? Z agentury mi napsali:
kolegove z Gemiusu mi poslali zpravu o tom, ze pri testech nepozorovali podobne chovani mericich skriptu. Muzete prosim rici, od kdy je podobne chovani pozorovano, jestli se vyskytuje napr. v nejakou urcitou dobu, za jakkoli specifickych podminek, pripadne jakekoli blizsi informace?
Zkuste prosím sledovat, zda se vám tyto problémy ještě dějí a pokud ano, tak za jakých okolností. Zkušenější uživatelé mohou použít síťové nástroje pro detekci problému. Když se vám to zpomalí stane, jděte třeba na centrum či lupu a otestujte, zda je gemius.pl bude blokovat či ne. Velmi nám pomůže, pokud tento problém vyřešíme.
Tiskni
Sdílej:
19.2.2009 22:35
=^..^= AmigaPower® | skóre: 30
| blog: BLB
| Praha
Nevšiml jsem si na žádném českém webu, že by je netmonitor, respektive gemius.pl zpomaloval. Proč jenom nás?Gemius.pl zpomaluje skoro všechno kde se nachází, vypozoroval jsem to na více stránkách, věř mi, že ábíčko je na tom s rychlostí ještě dobře... Děje se to za záhadných okolností a bez žádné logiky, nezáleží to na čase. Já bych to laicky svedl na přetížení jejich serverů...
19.2.2009 22:37
=^..^= AmigaPower® | skóre: 30
| blog: BLB
| Praha
20.2.2009 06:38
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Co se týče zpomaleného načítání, tak to prý někdy dělá jakýsi google - analytics nebo něco takového.Nezažil jsem, aby to brzdil kód Google Analytics. Mám ho na několika webech a nikdy jsem nenarazil na jev, na který narážím tady na abíčku. Ostatně, nebylo by od věci nechat puštěný Wireshark a po tom zaseknutí se podívat, jak probíhala komunikace.
22.2.2009 10:40
brk | skóre: 29
| blog: broukoviny
20.2.2009 11:04
=^..^= AmigaPower® | skóre: 30
| blog: BLB
| Praha
Jak se pozná, jestli jakýsi ten gemius.pl zpomaluje načítání nebo nikoliv ?...že ti dole na stavový liště 2 minuty svítí "čekám na hit.gemius.pl"
22.2.2009 10:27
multi | skóre: 38
| blog: JaNejsemOdsut
můžu potvrdit, že spousta českých stránek, na které chodím s tím má problémy..
jestli jsem to dobre pochopil, tak kdyz budu neco blokovat, tak tim mohu uskodit abclinuxu. Nemohl by tedy nekdo poradit, jak se da to blokovani nastavit?
20.2.2009 13:05
jirkaqwe | skóre: 11
| blog: blog_jirkaqwe
Asi měl spíš na mysli jak konkrétně nastavit prohlížeč např Firefox s Adblock plus a NoScript aby nekazil abíčku statistiky navštěvnosti a abíčko nepřicházelo o peníze.
Inzerenti nejsou hloupi, takze jakakoliv hratka s blokovanim / nezobrazovanim reklam ci mericich kodu ma dopad. Napriklad kdyz budete stahovat reklamy, ale nezobrazovat je (coz pry adblock umi), tak budete kazit statistiky uspesnosti reklam a inzerent ztrati zajem priste k nam nejakou reklamu zadat. Pro nas je tedy nejlepsi, kdyz takove tooly vubec pouzivat nebudete 
20.2.2009 15:19
David Ježek | skóre: 83
| blog: Mostly_IMDB
Není pravda.
Za prvé v dnešním javascriptovém marastu se obrázky natahují přes klientský skript, který zrovna tak může (více méně) kontrolovat, zda obrázek a jeho nadřízené elementy nejsou skryté.
Za druhé rozumný zadavatel „měří“ účinnost reklamní kampaně vzhledem k nově získaným tržbám, aby věděl, jestli nevyhazuje peníze oknem (webového prohlížeče).
Netvrdím, že se tak skutečně ve významnějším množství děje, ale ta možnost tu je.
Pokud připustíte, že by se mohla vyskytnout i taková reklama, která vás zaujme, pak už to jedno není.V tom případě nechávám zobrazování obrázků stahovaných z adarbo a spol. zablokované, ještě jsem nenarazil na reklamu, která by mě zaujala něčím jiným, než že mě rozčiluje to blikání.
Já jsem samozřejmě psal o rozdílu stáhnout/nezobrazit a zobrazit/nekliknout.Jak se to vylučuje s "V tom případě nechávám zobrazování obrázků stahovaných z adarbo a spol. zablokované"? (Teda až na ten detail, že, jak jsem zjistil, se ani nestahují)
Podle mne je blokování reklamy stejné, jako třeba jízda v MHD načerno.To v žádném případě není. U MHD je smlouva mezi cestujícím a provozovatelem, cestující je podle ní povinen za přepravu zaplatit. Na druhou stranu web pouze nabízí nějaký obsah a jeho stažení je dobrovolné. A vzhledem k principu tohoto stahování je dobrovolné i to, které části webu si stáhnu.
pokoutně blokovat reklamu, ale zároveň dál konzumovat obsah, to mi nepřipadá fér.To už je něco jiného.
19.2.2009 23:02
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
20.2.2009 01:14
Prcek | skóre: 43
| Jindřichův Hradec / Brno
. U nás ve škole se objevila Fedora 10 a KDE4, tak jsem si k tomu sednul, že konečně vyzkouším nový KDE. Když chci zobrazit nějakou stránku z abclinuxu.cz, tak to strašně dlouho loaduje a stránka se nechce načíst - jakmile dám ale reload, tak se načte. Problém je, že při reloadu přijdu o nepřečtené příspěvky, no a taky je to dost otravné pořád klikat na reload 
.
20.2.2009 06:39
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Problém je, že při reloadu přijdu o nepřečtené příspěvky, no a taky je to dost otravné pořád klikat na reloadNepřečtené příspěvky občas zmizí i bez reloadu. Uvažuji to ohlásit jako bug, ale nevím o žádných konkrétních okolnostech, za kterých se to vyskytuje.
Nemuze to byt omezenim poctu navstivenych diskusi,? Tusim je to neco kolem 60-80. Ty nejstarsi proste odpadnou pryc a tudiz system nevi, ze jste je navstivili a nema podle ceho urcit, zda hvezdicku zobrazit ci ne.
20.2.2009 07:45
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Když chci zobrazit nějakou stránku z abclinuxu.cz, tak to strašně dlouho loaduje a stránka se nechce načíst - jakmile dám ale reload, tak se načte.To je bug#180631 - bylo to opravené až po vydání 4.2. Bohužel se mi tato regrese objevila těsně před vydáním 4.2, takže to bylo nahlášené relativně pozdě a opravené až po vydání. Zkus kontaktovat maintainery KDE ve Fedoře, ať aplikují r926999.
AbcLinuxu je jediny web, kde mam podmíněně vypnutý AdBlock. Sice mě ty všechny gemiusy otravují a nejraději bych je zakázal, ale AbcLinuxu je plné geeků, kteří pravděpodobně bez AdBlocku nedají ani ránu, takže každý zaevidovaný hit se počítá.
Na webech typu idnes a aktuálně na výjimky kašlu, tam je dost BFU, co o AdBlocku nemají páru .
20.2.2009 09:11
Vojtěch Trefný | skóre: 24
| blog: Blog
| Praha
20.2.2009 00:48
bazil | skóre: 33
| blog: sluje
| Miroslav
Ne, flash se ani nestahuje. Ale z pohledu reklamnich kampani to neni dulezite, protoze samotne pocitadlo, jestli se reklama zobrazila nebo ne byva zpravidla v samostatnem JavaScriptu u reklamy a ten se provede i s FlashBlockem.
20.2.2009 07:26
bazil | skóre: 33
| blog: sluje
| Miroslav
Jeste bych k abcmonitoru dodal, ze nejaktivnejsi uzivatel ma 8552 monitoru, druhy 3121, treti 2002, ctvrty 1692 a paty 994.
21.2.2009 09:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
21.2.2009 23:21
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Prostě se mi nové komentáře mnohem lépe čtou v emailovém klientu než kdybych měl refreshovat stránku v prohlížeči.Tak to každý používáme ABCMonitor jinak
. Já si sledované objekty, co mi přijdou mailem, otvírám v prohlížeči (hlavně proto, abych viděl celé vlákno).
20.2.2009 09:30
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Ale presmerovava, zkousel jsem http i https (ktere ale presmeruje na http://www.abclinuxu.cz)
20.2.2009 13:51
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Svet neni dokonaly, smirte se s tim Pro mne je existence https velky ustupek, ladit takoveto drobnosti se mi opravdu nechce Kdo zna rozdil mezi https a http, ten bude schopen to s tam doplnit rucne. Navic stejne to URL na 97% zadaval rucne nebo z bookmarku, protoze vsude uz mnoho let presmerovavame na www.
20.2.2009 13:49
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To nie je bug, ale normálna očakávaná reakcia.
20.2.2009 13:16
jirkaqwe | skóre: 11
| blog: blog_jirkaqwe
Nešlo by udelat nějaké upozornění, že prohlížeč blokuje statistiku navštěvnosti, třeba malá červená ikonka. Po kliknutí na upozornění by se objevila nápověda jak se má případně prohlížeč nastavit, aby to neblokovalo. Třeba to tu řada lidí blokuje a ani o tom neví.
zdravim Leosi,
uvadis v blogu, ze je pro Vas kriticke mit zisky z reklamy a ze je velmi spatne, kdyz navstevnici blokuji reklamy.
Tak ci tak si myslim, ze tech par procent lidi, co blokuji reklamy neni dulezitych a nestoji to za to resit. To je podle me zbytecne vysilovani.
Pochybuji, ze lide budou zodpovedni a ze jim pomuze domluva.
Porovnam -li ceny ve Vasem media-kitu, tak jste v plusu i s naklady (nechci resit).
Nebo se mylim ? A pokud ano, tak v cem ?
Abicko neni urcite jedine, kdo ma problem s obcasnym nedodanim obsahu ze strany gemihnusu. Nicmene abicko to taha fakt hodne na zacatku, takze skutecne zustane cele viset, takle vypada abicko:
http://www.ohnesorg.cz/foto/screenshot10.png
A takle vypada lupa, kde uz je zobrazen text, zatimco se ceka az na strane gemiusu po uspesnem connectu prideli nejaky worker, ktery ho odbavi.
Jmenuje se to YSlow, plugin do firefoxu 3, vyvijeji to v yahoo pro ladeni vykonu jejich web serveru. Poskyuje to furu informaci, od tehle grafu pomalosti/rychlosti, pres pocty objektu, informace o tom jak se cachuji.... proste takovy profiler.
21.2.2009 21:25
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
22.2.2009 17:22
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
22.2.2009 17:23
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
iptables -A FORWARD -p tcp -s 192.168.253.3 -d 62.168.44.124 -j REJECT --reject-with tcp-reset iptables -A FORWARD -p tcp -s 192.168.253.3 -d 62.168.44.125 -j REJECT --reject-with tcp-resetA je uklizeno.
A je uklizeno.Neřekl bych. Spíš jste zametl smetí pod postel.
Právě že jste nikomu nic neřekl.Ale? Tak to abych si ten skript pro nastavování firewallu překontroloval. Hm, zajímavé, vždycky jsem si myslel, že když příkaz iptables selže, tak taky vypíše proč.
Jak se asi má provozovatel toho reklamního kódu dozvědět, že je něco špatně, když mu nic neřeknete a jenom ustřihnete komunikaci?To je jeho problém. Jestliže kvůli načítání reklam musím pět minut čekat na zobrazení celé stránky, tak neváhám ani chvíli a volím nejjednodušší a nejrychlejší řešení. Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu, ale takhle fakt ne.
Kdyz se takhle zachovaji vsichni, budou nam klesat prijmy z reklamy a my nebudeme tusit proc. Minimalne upozornit provozovatele na problem by bylo solidarni a ve svem dusledku prinosne i pro tebe. Jak bychom asi zareagovali, kdyz bychom nemeli penize na honorare? (upozornuji, ze jde o hypoteticky priklad) A podobne kdyz najdes chybu treba ve firefoxu, z dlouhodobeho hlediska je lepsi ji nahlasit nez nadavat v hospode
Kdyz se takhle zachovaji vsichni, budou nam klesat prijmy z reklamy a my nebudeme tusit proc.Ale jo. Ve chvíli, když by všichni zablokovali brzdící adarbo, tak by jim asi došlo, že někde udělali chybu. Nebo možná ne, ale je to jedno, protože by tak jako tak šli od válu - kdo by objednával reklamu od někoho, komu se reklama nezobrazuje - a na jejich místo by nastoupila jiná firma. A ti by se třeba poučili a zajistili bezproblémový chod této "služby" A nebo taky ne, v takovém případě GOTO 10
A podobne kdyz najdes chybu treba ve firefoxu, z dlouhodobeho hlediska je lepsi ji nahlasit nez nadavat v hospodeCož jsem, alespoň podle mého názoru, vyjádřil větou "Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu"
Což jsem, alespoň podle mého názoru, vyjádřil větou "Nebýt to reklamy ale něco užitečného, tak bych možná investoval ten čas a hlásil chybu"Potíž je v tom, že pro AbcLinuxu.cz jsou reklamy užitečné - jakkoliv se nám nelíbí - protože to je jediný zdroj příjmů.
22.2.2009 22:09
Jendа | skóre: 78
| blog: Jenda
| JO70FB
defer=true, je normované chování prohlížeče – prohlížeč nemůže tušit, zda v tom skriptu nebude třeba document.write() (a v těch reklamních skriptech dost často je), takže musí přerušit parsování HTML a nejprve načíst a vykonat skript.
prohlížeč nemůže tušit, zda v tom skriptu nebude třeba document.write()
Prohlížeč netuší spoustu věcí a dokáže spekulativně vykreslovat i tak (chybějící obrázky, veškeré javaskriptové aplikace).
Skripty se často procházejí po stromě, takže před jejich vykonáním musí být strom již hotový. To je samozřejmě neřešitelný případ, když skriptů běží více, takže běh nad rozpracovaným stromem musí být nějak implementován.
Proč toho nevyužít a nerozeběhnout parsování a vykreslování spekulativně vedle čekání na stažení dalších dokumentů – obzvláště, když se čekání ukáže dost dlouhé v řádu několika sekund?
Prohlížeč netuší spoustu věcí a dokáže spekulativně vykreslovat i tak (chybějící obrázky, veškeré javaskriptové aplikace).Je rozdíl v dotažení obrázku a v kompletním přebudování celého DOM stromu. Ten skript totiž nemusí vypsat jen uzavřený tag (uzel v DOMu), ale může vypsat cokoli -- dohromady s volnými pravidly pro parsování HTML a "domýšlení" uzavíracích a chybějících tahů to pak může znamenat, že ten skript úplně změní stukturu dokumentu.
Skripty se často procházejí po stromě, takže před jejich vykonáním musí být strom již hotový. To je samozřejmě neřešitelný případ, když skriptů běží více, takže běh nad rozpracovaným stromem musí být nějak implementován.To je řešitelný případ a jedna ze základních věcí práce s JS v prohlížeči. Skript, který pracuje s DOMem, musí počkat na dobu, než je DOM vybudován -- a je k tomu dost událostí. Pokud jde o tenhle druh skriptu, je rozumné, aby autor skriptu přidal onen atribut
defer. Ale musí to udělat autor, prohlížeč nemůže tušit, co v tom skriptu bude.
Proč toho nevyužít a nerozeběhnout parsování a vykreslování spekulativně vedle čekání na stažení dalších dokumentů – obzvláště, když se čekání ukáže dost dlouhé v řádu několika sekund?
Protože za místem vložení skriptu je jenom náhodné smetí, teprve až se skript vykoná, dá se to, co je za ním, interpretovat jako HTML kód. Myslíte, že následující kód může prohlížeč parsovat dál a výstup skriptu tam nějak doplnit?
<script>
document.write("<"+"!--");
</script>
<img src="obrazek.jpg" />
<script>
document.write("--"+">");
</script>
<table>
<tr><td></td></tr>
<script>
document.write("<"+"/table"+"><"+"table"+">");
</script>
<tr><td></td></tr>
</table>
Rozumím, že skript může strom úplně předělat, ale to přeci nebrání prohlížeči vykreslit strom před skriptem a znovu po skriptu.
Vždyť bohaté ajaxové aplikace přesně tohle dělají. Proč by nemohl prohlížeč dělat „náhledy“ v časech, kdy skript nic nedělá?
Dokážu si představit, že při paralelním zpracování mohou nastat ošklivé souběhy, ale to je snad problém skriptů, že nepoužívají nějakou formu synchronizace.
Nakonec se může stát, že se první skript zacyklí a co pak? Tohle je to úžasné HTML, které se umí zotavit z chyb a vykreslovat se za běhu, jak tvrdí zastánci volného HTML?
Beru to jako polemiku se současným standardem, který v podstatě říká, dělejte to sekvenčně, ať programátoři nemají bolesti hlavy.
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?
(Mimochodem konstrujce typu "<"+"!--" je co? Chorobný strach, profesionální deformace nebo sarkasmus?)
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?(Mimochodem konstrujce typu
"<"+"!--"je co? Chorobný strach, profesionální deformace nebo sarkasmus?)
Abicko reklamni kody nepise, naopak do nich nesmi nijak zasahovat.
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů reklamních kódů?
Tohle jsem neřekl:
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jeho programátorů Ábíčka?
Nakonec se může stát, že se první skript zacyklí a co pak?Aspoň trochu rozumný prohlížeč má ochranu proti zacyklení skriptu -- třeba počítá počet instrukcí, a pokud překročí určitý počet, dovolí uživateli skript zastavit.
Beru to jako polemiku se současným standardem, který v podstatě říká, dělejte to sekvenčně, ať programátoři nemají bolesti hlavy.Ne, současný přístup říká: nepokoušej se uhodnout, jak ten skript asi bude vypadat, ale použij informaci, kterou ti dal programátor v atributu
defer.
Mám tedy chápat reklamní kódy v Ábíčku jako lenost jejich programátorů?Vzhledem k tomu, že ty kódy zpravidla používají
document.write(), tak je čekání na skript správné. Jinak by kód musel vypadat tak, že by se na příslušné místo vložil třeba div s nějakým ID, a ten by si pak vyhledal skript v DOMu -- to by šlo dělat i bez čekání na skript. Ovšem zase by se muselo řešit, jakým způsobem vložit do jedné stránky víc reklamních pozic.
Takže prohlížeč by se nejprve prokousal náhodným shlukem znaků, interpretoval to jako HTML, vykreslil, pak by zpracoval JS, vše předchozí zahodil a vykreslil znovu něco úplně jiného.
Přesně tak.
Rozdíl mezi dotahujícím skriptem a obrázkem je ten, že obrázek nemění strom, takže se ušetří parsování, ale stránka se stejně musí překreslit, protože nový obrázek může třeba vytlačit plovoucí boxy.
Přitom pokud skript neovlivňuje parsování stránky, stačí, aby autor přidal jeden atribut, a hned je to vyřešené.
Je to vyřešené, jen když věci jdou dobře. Pokud ne, uživatel nedostane nic. Kolikrát se mi už stalo, že v „Zobrazit zdrojový kód“ jsem obsah měl, ale na plátně jsem neměl nic.
Aspoň trochu rozumný prohlížeč má ochranu proti zacyklení skriptu
A proto bych chtěl takové chování i v případě čekání na Godota.
Jedním řešením je nabídnout vykreslení nedoskriptované stránky, druhým řešením je zobrazovat stránku průběžně.
Vzhledem k tomu, že ty kódy zpravidla používají document.write(), tak je čekání na skript správné.
Když jsem viděl zde uvedená schémata zpoždění, tak jsem se zhrozil. Prohlížeč 15 sekund nic nedělal. Za tu dobu už mohl uživatel vyhodnotit, že ho stránka nezajímá a opustit ji. Proto mi přijde současný způsob špatný.
Jinak by kód musel vypadat tak, že by se na příslušné místo vložil třeba div s nějakým ID, a ten by si pak vyhledal skript v DOMu -- to by šlo dělat i bez čekání na skript.
To už BBmedia dělá.
Nebo taky je možné identifikátor přiřadit elementu script a nově vytvářené elementy připojovat ze něj ve směru osy following-sibling. Nebo se lze orientovat podle script[@src].
Ovšem zase by se muselo řešit, jakým způsobem vložit do jedné stránky víc reklamních pozic.
Za to dnes je stránka prošpikována elementy script, které volají jedinou funkci na vložení pozice.
Pokud se web vydá cestou klientského skriptování a všelijakých kombinovaných stránek, které si vypůjčují kód a obsah odevšad (mesh-up), bude problém se zlobivými skripty nabírat na síle a vývojáři webových prohlížečů se jím budou muset zabývat. Občas nedestupný reklamní server je jen první vlaštovka.
Mohli bychom se vratit k tematu? Tedy za jakych okolnosti vam gemius zpomaluje stranky? Minimalne je vhodne nahlasit presny cas, trosku pokrocilejsi svou IP adresu, stredne pokrocili vystup z pingu a traceroute no a guruove zmenu konfigurace na strane gemiusu Tohle je reseni, (pomoci) zjistit, v cem je problem.
23.2.2009 00:03
Jendа | skóre: 78
| blog: Jenda
| JO70FB
24.2.2009 00:40
Prcek | skóre: 43
| Jindřichův Hradec / Brno
24.2.2009 00:41
Prcek | skóre: 43
| Jindřichův Hradec / Brno
Pozoroval to ještě někdo?Občas. Ale nedokážu vysledovat nějakou pravidelnost, takže jsem proti tomu nic nepodnikal. Prostě Brownův pohyb na síti
.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.