Prevod sa vykonáva zrušením starej zmluvy a podpisom novej zmluvy, čo je podľa pracovníčky v HTK Mobile (ID predajného miesta ID374GPB20) úkon spoplatnený 9,90 EUR. Zmieril som sa s týmto poplatkom (ale príde mi absolútne neadekvátny), podpísal som zmluvu a šiel domov. Doma som zistil, že ale pracovníčka „Lamperová Ivana2“ zabudla niektoré údaje v zmluve vypísať, na niektorých miestach moje meno vypísala zle a svojvoľne zrušila šifrovanie elektronickej faktúry. Hneď som im písal sťažnosť a druhý deň som musel ísť zase na predajné miesto zmluvu opraviť. Na moje prekvapenie zmluvy sa neopravujú – zase sa jedna zruší a spraví nová. Podľa inej pracovníčky „Otrubčiaková Ina1“ nedá sa povedať, či aj za túto opravu mi budú účtovať 9,90EUR. Mám počkať do ďalšej faktúry… (Nejako som sa dopočítal k tomu, že ten poplatok s daňou bude 11,8364 EUR, v skutočnosti podľa cenníka od 1.1.2012 to je 11,95 EUR s daňou.)

Odpoveď na reklamáciu mi došla celkom rýchlo a čo ma prevapilo – spomínaný poplatok 11,95 EUR mi vôbec nemá byť účtovaný:

Dobry den pan Izso,
dakujeme za vyuzitie nasej sluzby.
Reagujeme na Vas e-mail ohladom vzniknutej situacie na predajnom mieste ohladom reorganizacie telefonneho cisla.

Z nami dostupnych informacii sme zistili, ze dnesnym datumom 20.12.2011 doslo k naprave udajov na Zmluve. Za vzniknutu situaciu sa ospravedlnujem.

Pokial ucastnik vyuziva cislo ako fyzicka osoba nepodnikatel a meni udaje na fyzicku osobu – podnikatela s rovnakym menom, jedna sa o bezplatnu reorganizaciu.

Verime, ze do buducna uz budete mat len dobre skusenosti a zachovate nam Vasu priazen.
V pripade akychkolvek otazok nas mozete kontaktovat na nasej Zakaznickej linke 905 (0905 905 905) 24 hodin denne, pripadne vyuzit nas kontaktny formular na www.orange.sk/otazky.
S pozdravom
Ing. Erika Murgasova
Usek sluzieb zakaznikom
Orange Slovensko, a. s.

V januári, ďalší deň po skončení fakturačného obdobia, som zrazu ani na jednom mobile nemal signál. Nepomáhalo znovu pripojenie sa do siete a v predajni mi povedali, že o 2:00 som bol odpojený, o 3:00 prebehla zmena v službách a o 4:00 som mal všetky služby znova aktívne a bol som pripojený do siete. Čo je síce fajn, ale o 11:00 telefóny stále nefungovali. Tak že mám počkať do 12:00, že „výnimočne“ sa stáva, že prevod trvá a do obeda. O 12:15 skúšam a nič, ani jeden telefón o 12:30 stále nefunguje, tak som čakal a až niekedy o 13:10 nabehla sieť na oboch telefónoch. O chvíľu mi volá neznáme číslo (nie blokované, ale neznáme), potom ďalšie neznáme. Veľmi som sa divil, prečo zrazu telefón nie je schopný rozpoznať ľudí, ktorých mám v kontaktoch. Po skúšobných prezvoneniach som mal potvrdené, že CLIP nefungoval. Tak som rýchlo otvoril zmluvu, aby som sa ubezpečil, že medzi „novými“ službami mám aj CLIP. Bol tam a keď ani o 15:00 som nevedel, kto mi volá, zase som sa vrátil na pobočku.

Nový pracovník už len krčil plecami a absolútne nevedel, čo sa deje a ako má prípad riešiť. Skúsenejšia pracovníčka – Ivana2 mi povedala, že CLIP ešte potrvá, kým nabehne. Absolútne obarene som na nich pozeral, či to myslia vážne a že či je podľa nich normálne, aby o 4:00 som mal aktívne všetky služby a potom mi sväto-sväte tvrdili, že mi to bude fungovať všetko až po 12:00 a nakoniec mám ešte čakať do konca dňa? Kedže sa zmohli iba na „je to normálne“, napísal som sťažnosť a odišiel som. Samozrejme nefungoval ani 3G internet.

Služby postupne nabiehali, ja som medzičasom predýchal aj fakt, že zrazu som dostal nové fakturačné obdobie a že dalšia faktúra bude totálny bordel. Keď mi teda došla faktúra 2× vyššia ako zvyčajne, ani som sa nevidil, že tam bude niečo zle. Orange-u sa podarilo ma napriek predpokladaniu chybných položiek na faktúre šokovať ma – poplatok 11,65 EUR si fakturujú za každé jedno telefónne číslo – nie za zmluvu.

Vďaka tomu, že som náhodne zistil, že daný poplatok vôbec nemá byť účtovaný, volal som hneď na 905, kde mi operátor okrem iného povedal svoje skúsenosti s nákupom tovaru, kedy sa mu stáva, že mu niekto zaúčtuje tovar dva krát, čo je jeho osobná vec a nechápem, ako súvisí s mojimi sústavnými problémami so službami v Orange. Nakoniec sa dopracoval k tomu, že mi vedia dať dobropis k ďalšej faktúre.

Takže na rekapituláciu – zmena vo fakturačných údajoch pre Orange znamená, že zákazníka odpojí, že nebude mať pracovný telefón dostupný počas veľkej časti pracovnej doby, že musí strácať čas sústavnou návštevou ich predajného miesto, kde ho chybne informujú a za toto všetko si zaúčtujú 11,95 EUR za každé jedno telefónne číslo, ktoré u nich verný zákazník má. Áno, za výpadok služieb si sú schopní účtovať poplatok! A satisfakcia z ich strany? Dostal som zľavu neuveriteľných 0,48? za 11 dní v prechode medzi dvoma fakturačnými obdobiami.

V súťaži SexyWeb.sk sa súťaži pomocou Facebookových „Like“ hlasov. Za dva týždne sa mi podarilo získať iba okolo 35 hlasov. Moja stratégia bola prezentovať súťaž a moju aplikáciu na Facebook Wall, aby moju známi mohli hlasovať. Toto nebolo moc úspešné a konverzia bola minimálna. Potom som skúšal osobitné rozposielanie správ individuálnym kamarátom, čo prienislo konverziu na úrovni 90% a získal som vlastne takmer 30 hlasov z tejto formy propagácie súťaže. Malo to však aj svoje negatíva – niektorí kamoši sa pomýlili a zahlasovali za cudziu stránku :)

Včera však do súťaže pribudla nová konkurencia: asi 5 graficky výborných webov. Za necelých 24 hodín však stihli získať stovky hlasov. Jeden z webov – KM Studio – získal až 250 hlasov, čím sa extrémne rýchlo dotiahlo na Dexorixa, ktorý mal po 3–4 týždňoch 260 hlasov. A ďalšie z týchto webov mali takmer po sto hlasov. Teraz večer, po niečo vyše 24 hodinách má KM Studio 527 hlasov a ostatné nové weby niečo vyše 150 hlasov. Začal som sa teda zaujímať, ako je možné, že takto extrémne rýchlo dokáže niekto získať hlasy.

Zavítal som preto na stránku dokumentujúcu Facebook Like Button aby som zistil, či sa dá pozrieť, kto a ako hlasuje v súťaži. Pomocou Insight funkcie si hlasy môže pozrieť iba správca domény, na ktorej prebieha hlasovanie. V časti FAQ som sa však dočítal veľmi podstatnú informáciu: ako sú vlastne počítané tieto Facebook Like hlasy.

What makes up the number shown on my Like button?

The number shown is the sum of:

• The number of likes of this URL
• The number of shares of this URL (this includes copy/pasting a link back to Facebook)
• The number of likes and comments on stories on Facebook about this URL
• The number of inbox messages containing this URL as an attachment.

Veľmi zaujímavé: hlasy sa dajú získať aj ináč, ako len používateľmi, ktorí vám budú klikať na Like tlačidlo na stránke. Započítavajú sa aj Like hlasy priradené k správam (posts, stories) ktoré obsahujú hlasovaciu URL adresu a aj počet komentárov. Toto sú celkom legitímne metódy počítania hlasov: musí prinútiť používateľov aby klikli na nejakú správu, ktorá súvisí s hlasovaním a súťažov a dostanete hlas.

Posledný spôsob získania hlasov je však veľmi diskutabilný: stačí odoslať správu, ktoré obsahuje hlasovaciu URL adresu a bude vám započítaný hlas. Nikto nemusí nikde klikať a hlasovanie je plne v rukách „spammera“. Jeden hlas za každú jednu správu s URL, ktorú odošlete. A stačí, keď tú správu odošlete sami sebe! Žiadne verejné informácie o súťaži, žiadne otravovanie známych, žiadne trápenie sa s konverzným pomerom a spôsobom, ako prinútiť ľudí, aby klikali. Jednoduché spamovanie správ so správnou adresou. Chýba vám pár hlasov? Pošlite si ich sami sebe :)

Boli hlasy na SexyWeb.sk „zmanipulované“? Možno áno, možno nie. To by vedel povedať iba správca, ktorý má prístup k Facebook Insight údajom (ak je pri hlasovaní aj informácia o zdroji hlasov). Ale osobne som dosť skeptický k tomu, že sa niekomu za 24 hodín podarí získať vyše 1000 hlasov cez bežnú konverziu.

PS: Nezabudnite hlasovať na stránke Sexy web-u, priamo na stránke Real Estate aplikácie, alebo priamo na tejto stránke.

Mini dumpy kernel aj full memory dumpy som síce mal k dispozícii, ale nemal som ich ako zanalyzovať. Pri jednom BSOD som si však všimol, že spadol ovládač eamonm.sys ktorý je z ESET NOD32 antivírusu. Na počítači bol nainštalovaní Eset Smart Security Business Edition 4.2, čo je aktuálna verzia a bol aj riadne aktualizovaný, takže bolo veľmi podozrivé, že práve tento ovládač spôsoboval pád systému. Pri obyčajnom reštarte bolo všetko v poriadku. Problém nastával iba vtedy, keď boli práve pripravené nejaké aktualizácie na inštaláciu.

Kolega z Esetu mi spravil službičku a pozrel sa na mini dumpy, avšak nikde v nich nebola zmienka o prítomnosti nejakého Eset modulu v spadnutom procese. BSOD však hovorilo jasne o eamonm.sys a tak sme skúsili pozrieť, či je všetko s NODom v poriadku. Okno O programe zobrazovali niektoré moduly s veľmi starými dátumami a bolo možné, že sa niektoré nesprávne aktualizovali. Po vyčistení cache aktualizácií (Nastavenie (F5) > Aktualizácia > Vyčistiť aktualizačnú cache), následnom vymazaní em_*.dat súborov z inštalačného priečinku NODu počas behu Windows v Safe Mode a spustení aktualizácie NODu sa znovu stiahli moduly, ktoré vyzerali byť až príliš staré.

Skúsil som teda radšej stiahnuť úplne novú verziu inštalácie NODu a preinštalovať celý produkt. Z verzie ESS 4.2.58.5 som produkt upgradoval na ESS 4.2.71.2. Aktu­alizáciou sa stiahli nové moduly a i keď verzia Self-Defense modulu zostala na verzii z konca roku 2010, vyzeralo to, že všetko je v poriadku. Neostávalo v tej chvíli len skúsiť, či sa problém s ovládačom odstránil. Nechal som Windows Update stiahnuť a nainštalovať všetko čo chcel a pri reštarte sa aktualizácie úspešne nakonfigurovali. Medzitým sa mi aj podarilo nájsť jeden príspevok o tom, že vo Windows Vista SP2 môže byť problém s niektorou verziou NODu a po upgrade na najnovší 4.2.71 sa problém odstráni. Kolega mi takisto potvrdil, že táto chyba v eamonm.sys už bola odstránená. Notebook momentálne pekne funguje, je vyaktualizovaný a podľa dostupných informácií bola príčina chyby skutočne odstránená.

PS: Neviem nakoľko je popísaný spôsob zmazania cache aktualizácií korektný a podporovaný. Vykonávajte ho iba na vlastné riziko a dajde si pozor, aké dátové súbory mažete.

Podľa príspevkov na MSDN fóre Cannot open CSS file in VS2010, VS2010 not opening CSS files; drag & add not working, či na StackOverflow css file not opening in visual studio 2010 sp1? stojí za problémom zle nainštalovaný balík Web Standards Update for Microsoft Visual Studio 2010 SP1. Jeho reinštalácia naozaj pomohla odstrániť problém.

V tomto prípade bol prvý identifikátor {786C830F-07A1–408B-BD7F-6EE04809D6DB} a rýchle googlenie zistí, že sa jedná o Portable Class Library projekt.

Je škoda, že Visual Studio nepoužíva nejaké človekom čitateľné identifikátory pre typy projektov, prípadne že samotné Visual Studio nedokáže z GUIDu načítať pomocou web služby o aký typ projektu sa jedná.

Veľkou zmenou voči Subversion 1.6 je nový formát working copy (WC-NG) priečinkov – čiže súborov, ktoré máte na svojom počítači stiahnuté zo serveru. Po prechode na nový WC-NG pomocou príkazu svn upgrade už bude špeciálny .svn priečinok uložený v koreňovom priečinku celej working copy. V novom .svn priečinku bude SQLite databáza s metadátami o súboroch pre rýchlejšiu prácu celého Subversion na klientovi.

Na serverovej časti pribudol nový HTTPv2 SVN protokol, ktorý zefektívňuje komunikáciu medzi serverom a klientom. Bude použitý ak server aj klient sú vo verzii 1.7 alebo novšej. Staršie kombinácie serverov či klientov budú používať pôvodný DeltaV WebDAV protokol.

Rýchle googlenie ma priviedlo k článku KB 2545227 ktorý popisuje túto chybu. Pri tvorbe obrazu inštalačných DVD pre Windows 7 SP1 a Windows Server 2008 R2 SP1 sa táto WMI query dostala omylom do systému a je možné ju zmazať. Podobný problém sa nachádza aj vo Windows Vista SP1 a Windows Server 2008 SP1 a je popísaný v článku KB 950375. Problém môžete odstrániť pomocou skriptu priloženého v spomínaných článkoch, alebo vo Windows 7 respektívne Windows Server 2008 R2 môžete spustiť FixIt opravu, ktorá automaticky opraví systém.

Táto chyba s WMI query nie je nijako škodlivá a iba zbytočne zapĺňa Event Log chybovými hláškami. Bohužiaľ ju však treba odstraňovať na každom novom nainštalovanom Windows systéme, pokiaľ chcete mať pekný Event Log. :)

Pri vývoji Windows Phone 7 aplikácie, ktorá bude používať FogBugz API, som najprv mal vytvorený Phone 7 projekt, do ktorého som prepisoval moju existujúcu implementáciu klienta pre FogBugz API. Tento klient bol obrovský, napísaný cez WCF a so synchrónnymi volaniami. Pre Phone 7 bolo potrebné kompletne prepísať veľkú čast kódu, pretože tak ako Silverlight, aj Phone 7 API obsahuje iba asynchrónne volania pri prácii s I/O a sieťou. Mohol som sa zároveň zbaviť závislosti na WCF a kód poriadne zoštíhliť. Keď som mal Phone 7 knižnicu hotovú, tak vyšla finálna verzia Portable Library Tools nástrojov a rozhodol som sa, že projekt zmením tak, aby som ho v budúcnosti mohol použiť kdekoľvek. To so sebou prinieslo niekoľko zmien v kóde, ktoré nie sú na prvý pohľad jasné a vyžadovali si trochu googlenia.

Boolean.ToString()

Jedna pomocná metóda používala volanie Boolean.ToString(CultureInfo.InvariantCulture);, ktoré nie je v PLT podporované. InvariantCulture som použil z „best-practices“ dôvodov. Boolean hodnotu som formátoval do query stringu a POST dát, takže som použil InvariantCulture, ktorá zabezpečí, že primitívny dátový typ bude naformátovaný do takéto textového formátu, ktorý bude bez problémov spracovateľný inou aplikáciou. PTL však podporuje iba Boolean.ToString() metódu. Podľa dokumentácie pre Boolean preťaženie metódy, ktoré som ja volal, úplne ignoruje parameter IFormatProvider a teda je jednoduché opraviť volanie na jednoduché ToString() bez zmeny chovania kódu.

PS: Pôvodná idea za použitím CultureInfo.In­variantCulture bola, aby som vždy dostal iba „true“ alebo „false“ stringy. Lokalizované .NETy dokážu vracať texty ako „Pravda“ a „Nepravda“. A samozrejme FogBugz server nedokáže spracovať takýto lokalizovaný text. Nemám však momentálne dôkaz, že Boolean.ToString() naozaj vráti lokalizovaný text v niektorých špeciálnych prípadoch a MSDN dokumentácia v iných jazykoch hovorí o „true“ a „false“ stringoch. Predpokladám teda, že o tento potencionálny bug sa vôbec nemusím starať, lebo neexistuje :)

Uri.EscapeUriS­tring(string) a Uri.EscapeDataS­tring(string)

Ako webový vývojár som zvyknutý používať triedu HttpUtility na zakódovanie textu do správne formátu, ak má byť text súčasťou URL adresy, HTML obsahu alebo atribútu. Táto trieda je však z knižnice System.Web.dll ktorá je dosť veľká a nie je vhodná ani pre desktopové aplikácie, a už vôbec nie pre Silverlight či Windows Phone. HttpUtility trieda je v týchto dvoch platformách ale prítomná v System.Window­s.Browser.dll knižnici. V Portable Library Tools ju však nenájdeme a potrebujeme náhradu. Existujú však nové metódy v triede Uri, ktoré boli pridané v .NET 3.5 SP1, ktoré rátajú s tým, že vývojári často pracujú s HTTP protokolom aj mimo webových aplikácií. Máme teda k dispozícii dve nové metódy: Uri.EscapeUriString(string) a Uri.EscapeDataString(string) ktoré sú súčasťou základnej systémovej knižnice a umožnia nám správne kódovať URL/URI adresy, query stringy a POST dáta.

Uri.EscapeUriString(string) metóda slúži pre prácu so stringami, ktoré budú súčasťou URL/URI adresy – napr. cesta k súboru na serveri a query string dáta.

-    fullServiceUrl.Query = "cmd=" + HttpUtility.UrlEncode(command);

+    fullServiceUrl.Query = "cmd=" + Uri.EscapeUriString(command);

Uri.EscapeDataString(string) metóda zase zakóduje správne stringy, ktoré budú súčasťou POST údajov.

StreamWriter writer = new StreamWriter(webRequest.EndGetRequestStream(asyncResult);

-    string name = HttpUtility.UrlEncode(param.Key);
-    string value = HttpUtility.UrlEncode(param.Value);

+    string name = Uri.EscapeDataString(param.Key);
+    string value = Uri.EscapeDataString(param.Value);

writer.Write(name + "="+ value + "&");

Synchronizati­onContext

Všetky API pre prácu s I/O sú v Silverlighte a na Windows Phone výhradne asynchrónne. Treba si preto uvedomiť, že kód aplikácia si vyžiada údaje zo serveru a tieto údaje dojdú späť asynchrónne – v inom threade. Ak teda používateľ klikne na tlačidlo „Načítaj údaje so serveru“ a handler metóda zavolá WebClient.Dow­nloadStringAsyn­c(), tak metóda okmažite skončí a grafické rozhranie aplikácie nezamrzne, lebo nečaká, kým sa stiahnu údaje zo serveru. Namiesto toho treba počkať, kým sa nezavolá ďalší handler, ktorý už dostane stiahnuté údaje. Toto sa však deje v samostatnom vlastné, ktorý je iný od UI vlákna. Načítané údaje teda môžu byť spracované a grafické rozhranie aplikácie stále nemusí byť blokované. Až po spracovaní môžeme aktualizovať UI – napr. zobraziť stiahnutý text. Toto však nemôžeme urobiť kedykoľvek. UI sa vykresluje vo svojom vlastnom vlákne a preto musíme vyslať požiadavku o zmenu UI pomocou triedy Dispatcher. Dispatcher je špeciálna trieda, ktorá vie, ako sa vykresľujú WPF, Silverlight a Phone 7 aplikácie a nie je dostupná v Portable Library Tools. Pretože PLT knižnica môže bežať v rôznych prostrediach, treba použiť namiesto špeciálneho Dispatcheru všeobecnú triedu, ktorá zabezpečí správnu synchronizáciu kódu, ktorý potrebujeme vykonať. Takouto triedou je SynchronizationContext s dvoma metódami: Post() a Send(). Ide o asynchrónny a synchrónny variant spustenia kódu v správnom vlákne, ktoré môže upravovať aj grafické rozhranie. PLT knižnica získa aktuálny synchronizačný kontext pomocou vlastnosti SynchronizationContext.Current a podľa toho, či je aplikácia napísaná pre Win Forms, WPF, Silverlight či Phone 7, tak sa použije správny synchronizačný kontext na vykonanie kódu.

Portable Library Tools sú zaujímavá vec, pokiaľ potrebujete vyvinúť aplikáciu pre rôzne .NET platformy a použiť v nich spoločný zdieľaný kód. Samozrejme treba mať namysli, že PLT sprístupnia v projekte iba tie API, ktoré sú dostupné na všetkých platformách, pre ktoré je knižnica vytvárané a z počiatku to môže byť dosť obmedzujúce. Mnohé veci sa však dajú napísať v .NETe veľmi univerzálne, avšak treba použiť správnu sadu API. Toto bol hlavne prípad odstránenia HttpUtility, na ktorú som ako webový vývojár veľmi zvyknutý. .NET sa vyvíja a niekedy je ťažké udržať krok so všetkými novými a lepšími API. Na druhej strane táto evolúcia .NETu so sebou prináša aj duplicitu API a treba sa vedieť správne zorientovať, ktoré triedy a metódy použiť v danom projekte.

Google mi však veľmi rýchlo objasnil, že sa jedná o podvodný poplatok za zápis do Registra obchodu a živnosti. Firma FIRMDATA Slovenská Republika s.r.o., a jej podobné podvodné firmy ako Informatik s.r.o., či INFODAT, prevádzkujú duplicitné, neoficiálne, nepoužiteľné a zbytočné kópie obchodných registrov a žiadajú za zápis do týchto ich kópií správne poplatky. V prípade e-mailov by sa hovorilo o phishingu, či scame, kedy firma uvádza prijímateľa do omylu.

O neserióznosti firmy FIRMDATA a jej registra hovorí samotný list, ktorý nijako nepredstavuje firmu, jej portfólio a v čom je register také „terno“, že by sa novozačínajúci podnikateľ do neho mal zaregistrovať. To že ponúkajú nejaký CD-ROM za poplatok 100? a označujú to ako databázu, podľa ktorej firmy môžu sledovať svoju konkurenciu, nebudem rozoberať, lebo je to zbytočné. Jedná sa o prázdne žvásty, ktoré majú nalákať ľudí, aby nadobudli pocit, že ich produkt má nejakú hodnotu.

Ich zavádzajúci list obsahuje len suché informácie o ponuke zápisu informácií o živnosti do Registra obchodu a živnosti, ktorý príjemca potvrdí zaplatením poplatku. Ľudia takto nadobudnú pocit, že sa jedná o poplatok, ktorý musia zaplatiť. Vzhľadom na to, že rakúsky majitelia firmy FIRMDATA majú firmy aj v iných štátoch – Rakúsku, Českej republike, Chorvátsku a Bosne a Hercegovine, predpokladám, že text listu je z právneho hľadiska korektný. Z morálneho hľadiska je to však iba trápne obohacovanie sa na základe nevedomosti a neskúsenosti iných.

Takýto list pripomína „60-eurové faktúry, ktoré SOI označila ako nekalú obchodnú praktiku“. Znovu však pripomeniem, že tieto prípady sú zrejme právne strašne odlišné, ale z hľadiska dobrých mrav úplne totožné. A záver? Treba si dávať pozor na poplatky od podivných spoločností, či už prídu klasickou poštou, alebo do e-mailovej schránky. A list buď zahodiť, alebo sa pokúsiť podať podnet na SOI.