Pratele, na me kesi GC10Q26 vznikl zajimavy problem - kolegove mi referuji prodlevu pri PM notifikaci. Domnivam ze, ze to je zpusobem nastaveni notifikace : treba ja jsem si pri zrizovani notifikace bez velkeho premysleni zatrhnul kolonku "publish listing" (a jinou uz ne). Tak jsem se chtel zeptat zkusenejsich kolegu - mate zaskrtnute treba i enable listing ?
Uznavam, ze situace, kdy se cache zverejni jinak nez systemem "publish listing" je asi zridkava (napada me treba obnoveni disable cache, ale to asi neni zajimave pro lovce FTF (predpokladam, ze lov FTF je asi hlavni duvod notifikace), mate s tim nejake zkusenosti ?
Ahoj. Problémy s notifikací jsem měl celý listopad a prosinec, nechodilo mi vůbec nic ani vygenerované PQ ani přehled nalezených jednou týdně, prostě vůbec nic. V tomto roce už problémy nejsou, občas to také přijde pozdě, ale to mi nevadí. Nemám to kvůli FTF. Jinak mám ještě zatrhnuto i enabele listing.
Nejsa PM, s timhle neporadim, ale alespon tady muzu napsat, ze presny cas, kdy jsem zmercil nove kesky byl 22:11, tudiz podle Tveho predchoziho logu na kesce jen po par minutach od zverejneni. Tudiz ne vzdy je vyhoda byt PM a spolehat na notifikaci.
I me se prave vcera stalo, ze 5 lidi odlovilo novou cache a notifikace prisla az dnes rano. Jeste ze jsem se do tech 5 lidi vesel , ale diky notifikaci to nebylo. V nastevenem okoli neni tolik novych kesek abych mohl posoudit, ale posledni 2 opravdu prisli s min 12 hod zpozdenim. Asi ten system nestiha :-(, a snad se to zlepsi …
[quote]
Mafi5bj: Systém PM je technologicky zastaralý, současným hitem je systém včasného varování Colonel74. [:D][:D][:D]
[/quote]
No jo, ja proste sedim u [co] a jak neco [8-|], vypustim kontrolni [E] zbytku teamu a kdyz maji cas, jsme tam diky operativnosti rychle jako [ap] a tudiz mame cas jeste na miste to necim vhodnym [^] oslavit.
Nejspis slo o problem na gc.com zminovany v tomto threadu .
Pri podezreni, ze neco nefunguje, je dobre divat se do fora
Geocaching.com Web Site, vetsinou se tam upozorneni na problemy
objevuji rychle.
Cache byla publikovana standardnim zpusobem, jinak to ani neumim
- ze jsem si vyzadal cas na rozmyslenou a probrani teto nestandardni
mystery, to nema na typ publikovaciho logu vliv. Jeste se muze objevit
nova cache tak, ze reviewer odarchivuje starou.
OT:
napsat tady nekolikaradkovy post s html linkem je fakt utrpeni, uz jsem
se vcera tesil, ze tam admin dava normalni forum.
Podivejme se na to z pohledu programatora. Jaky je jeho ukol? V pripade zverejneni nove cache - "publish" listing" odesli emaily na adresy z databaze, ktere splnuji podminku vzdalennosti. Programator tedy polozi SQL dotaz databazovemu systemu a vytvori databazi emailovych adres. Ve druhem kroku spusti generator emailu, a pekne postupne na vsecny tyto adresy vytvori emailovou zpravu, postoupi SMTP serveru, vytvori dalsi zpravu, postoupi SMTP serveru ... A nyni jeden aspekt ...Jak jsou emaily razeny v databazi? Abecedne? Podle vzdalennosti od cache? Dalsi zdrzeni muze nastat na ceste ... nektery ze serveru na ceste neodpovi, email se vrati ... a poslednim krokem k obdrzeni SMS je SMS brana vaseho operatora ...
Tedy ... podle moji logiky ... neni mozne aby vsichni PM v okoli dostali zpravu ve stejny cas. (Natoz si ji precetli, je tu jeste lidsky faktor). Vezmeme-li za predpoklad, ze rewival publikuje jednu cache za druhou, ma "notification engine" a SMTP server co delat.
Pozn. aut.: toto je pouze zjedodusena hypoteza, navic netusim, jak skutecne funguje "notification engine", ale zaver je tak jako tak stejny, a timto zverejnuji Murphyho zakon o FTF notifikaci "Ve chvili kdy ctete zpravu o nove cache, uz o ni pravdepodobne nekdo vi."
Pažitkův postulat k Murphyho zakonu o FTF notifikaci:" ... a už je na cestě."
Takze FTF hunteri, vyrazte, kazda fteřyna je draha! :-)
PM notifikace se zřejmě generují postupně tak, jak servery vytahují postupně data ze seznamu vyhovujících adres, získaných dotazy z databáze. Tyto dotazy mohou být nějak sortované a tím může Groundspeak upřednostnit některé PM cachery před jinými. Ale kvůli minimalizaci zatížení si myslím, že při dotazu k žádnému dodatečnému setřídění nedochází a tak se maily odesílají v tom pořadí, v jakém databáze vrací jednotlivé vyselektované záznamy.
Záznamy s účty geocacherů budou s největší pravděpodobností seřazeny podle data založení účtu geocachera. K tomu je navíc nutné počítat s tím, že tak rozsáhlou celosvětovou databázi nespravuje jediný server, takže generování může probíhar paralelně na více strojích v lehce odlišných časech .
Seznamy notifikací ale zřejmě budou používat oddělené tabulky od "základních" tabulek s (PM) účty geocacherů - právě třeba pro případ rychlejšího vyhledávání podle zadaných kritérií PM notifikací. Pak je zřejmě tento seznam notifikací primárně setříděn podle data vytvoření konkrétní PM notifikace u daného geocachera. V tom případě kdo si dřív nastavil danou PM notifikaci, do které událost spadá, ten má vyšší pravděpodobnost, že mu e-mail dojde dříve.
Ale - tohle jsou všechno pouze mé spekulace. Databáze notifikací mohou být řešeny v reálu úplně jinak.
Možná by se to dalo vysledovat, pokud by se pár PM cacherů domluvilo a zveřejňovalo dodatečně informaci o přesném čase odeslání (tato informace by měla být nalezitelná v hlavičce e-mailu) jejich emailu s notifikací a pak se to porovnávalo např. s časem přihlášení na gc.com, s časem vytvoření PM účtu a s časem vytvoření notifikace. pak by se možná dala časem vysledovat nějaká zákonitost. Sledovat v notifikačních e-mailech čas doručení nemá valný smysl.
a spolehat na notifikaci.
, ale diky notifikaci to nebylo. V nastevenem okoli neni tolik novych kesek abych mohl posoudit, ale posledni 2 opravdu prisli s min 12 hod zpozdenim. Asi ten system nestiha :-(, a snad se to zlepsi …