Cloud as a Story - Vunvulea Radu

Intr-un post anterior am promis ca o sa revin cu cativa pasi ce trebuie facuti pentru a putea face handling corect la o aplicatie ASP.NET MVC 3. Mai jos o sa gasiti cei 3 pasi care trebuie facuti pentru a face handling la erorile de tip 404 cat mai bine, fara sa avem surprize neplacute cand aplicatia este deja in productie. Exista mai multe variante. Varianta aleasa de mine nu necesita existenta sau modificarea unui base controller. 1. Pentru toate erorile care apar in sistem avem nevoie de un loc comun Toate erorile trebuie sa fie controlate dintr-un loc comun. In cazul in care vrem sa vedem la ce erori se face handling sau care este modalitatea prin care se face handling, ca sa nu cautam prin controale, cel mai usor este sa ne facem un controller care se ocupa doar cu acest lucru. public class ErrorController { public ActionResult Http404(string url) { Response.StatusCode = (int)HttpStatusCode.NotFound; var model = new ErrorViewModel(); model.Reque

Cat de mult va place ecranul galben intr-o aplicatie web? Cred ca e la fel de faimos ca si ecranul albastru din Windows. Mai este numit si YSOD – Yellow Screen Of Death. Acest ecran nu ar trebuii sa apara niciodata in productie. Mai jos o sa vorbim despre doua modalitati cum putem sa evitam acest ecran. MVC 3 ne aduce o functionalitate build-in pentru handling la erori. Atributul HandleErrorAttribute se ocupa de acest lucru pentru noi si face o treaba foarte bine atata timp cat este folosit corespunzator. Putem sa il folosim in doua metode. O metoda este sa decoram controlerele sau actiniile cu acest atribut. In acest mod, orice eroare care apare in controlerul/actiunea noastra o sa fie prinsa de catre MVC 3. O alta variant este sa adaugam in lista de GlobalFilter si atributul nostru – acest lucru se face in Global.asax.cs - Application_Start . In acest fel nu are importanta de unde vine eroare, o sa fie facut handle la eroare de catre MVC 3. [HandleError] public class HelpCon

Ma uitam zilele astea peste un cod si am vazut de mai multe ori cod de genul acesta: string v2 = v1 + "\n"; Scopul la acest cod este de a trece pe o linie noua. Desi functioneaza si este folosit de catre foarte multi dezvoltatori nu este cea mai buna solutie. Pentru a trece la o linie noua cei de la Microsoft au adaugat o propietatea Environment.NewLine . De fapt aceasta este o constanta ce ne returneaza "\r\n" pe Windows. IL care se genereaza face un call la System.Environment::get_NewLine() care in spate are urmatoarea implementare pentru Windows: .method public hidebysig specialname static string get_NewLine() cil managed { .maxstack 8 L_0000: ldstr "\r\n" L_0005: ret } In functie de platforma NewLine poate sa difere, o implementare pentru UNIX ar contine doar "\n". Desii Environment.NewLine este mult mai clar in cod, nu cred ca se va renunta la "\r\n" deoarece nimeni nu va uita ce inseamna "\r&q

Intr-un post anterior am discutat despre AppFabric Cache, care are la baza mecanismul de DataCache pentru Windows Cache Server. Intr-un mediu in care avem mai multe masini care scriu pe acelasi cache trebuie avuta grija destul de mare la urmatorul caz: In acelasi timp 2 sau mai multe masini doresc sa scrie acelasi element in cache( aceiasi cheie). Cuvantul cheie la aceasta problema este "IN ACELASI TIMP". In mod normal am avea urmatoarea implementare pentru a scrie un obiect in cache: DataCacheFactory cache = new DataCacheFactory(); cache.Put(key,value); Totul ar functiona fara nici o problema pana cand 2 sau mai multe instante ar incerca sa scrie in acelasi timp un element cu aceiasi key in cache. In acest caz se arunca o exceptie de tip DataCacheException , cu error codul setat DataCacheErrorCode.RetryLater . Pentru a rezolva aceasta problema avem doua solutii, in functie de cat de probabil e sa apara un astfel de caz putem sa folosim una din solutii, sau o combin

De cate ori nu v-ati lovit de cerinta urmatoare: Sa se converteasca un stream intr-un sir de bytes. Am vazut diferite implementari la aceasta solutie. Cea mai comuna este cea in care se itereaza prin stream. byte[] bytes = new byte[10000]; int temp; int offset; while ((temp = ms.Read(bytes, offset, bytes.Length - offset)) > 0) {      offset += temp; } Aceasta solutie o sa functioneze, dar putem sa ne folosim si de alte functii, care sa simplifice putin codul si sa eliminam sansele ca un bug sa apara. O alta varianta este sa folosim metoda GetBuffer . Aceasta ne returneaza sirul de bytes din care a fost creat streamul. Trebuie avut grija la doua lucruri aici: nu se face o copie a sirului de bytes lungimea sirului care ne este returnat nu reprezinta lungimea reala a streamului. De exemplu daca avem un stream de 10 bytes si apelam GetBuffer , o sa ne fie returnat un sir de lungime 256 din care 246 de elemente nu sunt folosite. byte[] bytes = ms.GetBuffer(); Ul

In acest weekend in Cluj-Napoca a avut loc Hackathon organizat de catre Microsoft Student Partents. Am participat la acest eveniment ca si membru din juriu. La finalul celor 24 de ore, cele 14 echipe care s-au inscris in concus au  avut niste aplicatii foarte reusite. Ne-a fost destul de greu sa alegem echipele castitoare. Locul intai a fost ocupat de echipa DOTDOTDOT cu aplicatia TweetThePlace . Aplicaţie care permite să laşi mesaje (şi poze) într-un anumit Place. Nu poţi vedea/posta un mesaj dacă nu te aflii în apropierea Place-ului respectiv. Suportă şi live stream folosind push notification astfel încăt dacă te aflii lâncă un Place şi se postează un mesaj la acel Place, eşti notificat.  Vreau sa felicit toate echipele pentru ca au reusit in 24 de ore sa scrie niste aplicatii formidabile. Sper sa vad o parte din aceste aplicatii pe Marketplace. Poze de la acest eveniment: http://www.facebook.com/media/set/?set=

Exista mai multe versiuni de Exchange Server, majoritatea serverelor care exista la ora actuala sunt 2007 SP1 si 2010. Daca vrem sa scriem o aplicatie care acceseze direct contul de Exchange puteti sa folosim un client care consuma serviciile expuse de acest server precum EWS - Exchange Web Service . Aceasta este doar un assembly pe care trebuie sa il adaugam la proiect. Pregatesc in aceasta luna mai multe tutoriale despre EWS. In postul de azi vreau doar sa subliniez o problema pe care EWS o are. O sa vorbim mai in detaliu cu alta ocazie despre cum sa il folosim. Exchange Server 2010 a adus cateva schimbari la nivelul entitatiilor care exista. De exemplu pe 2010 un contact poate sa aibe atasata o poza sau modul in care sunt grupate contactele difera fata de 2007. Din pacate EWS ne aduce datele in functie de versiune de Exchange pe care o accesam. Un exemplu destul de bun, pentru a arata problema care o are EWS este cand vrem sa aducem lista de contactele a unui account. O sa ne trez

In ultimu timp lucrez de mult cu serverul de Exchange. Astazi lucram cu un obiect de tip Contact si am descoperit doua propietati cu nume destul de interesant. string YomiGivenName { get; } string YomiSurname { get; } In lista de propietati deja aveam GivenName si Surname. Denumirea este destul de interesanta. Am cautat pe msdn, dar ca de obicei descrierea este destul de vaga: Gets the Yomi given name (first name) of the contact - sursa Dar tot nu am inteles de la ce vine Yomi. Am cautat si pe google mai multe informatii si iata ce explicatie am gasit: Modul in care caracterele asiatice( chinezesti) sunt citite - din punct de vedere fonetic. Primul rezultat returnat de google a fost de pe wikipedia si era: Yomi (黄泉 ? ), the Japanese word for the underworld in which horrible creatures guard the exits; according to Shinto mythology as related in Kojiki , this is where the dead go to dwell and apparently rot indefinitely - sursa

In EF 4.xx operatiile de tip CRUD sutn foarte usor de executat. Dar ce se intampla daca avem nevoie sa executam o procedura stocata. De exemplu dorim sa populam un tabel, iar pentru acest lucru trebuie sa rulam o proceduta stocata. Pentru acest lucru avem doua posibitati. Prima din ele este sa ne cream un obiect de tip SqlQuery care poate sa contina orice comanda sql, iar apoi sa il executam. DataContext.Database       .SqlQuery<int>("EXEC PopulateTable @param1 @param2",             new SqlParameter("param1", "100"),             new SqlParameter("param2", "1/12/2011")); Aceasta modalitate este perfecta cand stocata/comanda pe care o executam ne returneaza date. Cand folosim aceasta comanda, data context stie ca datele au fost modificate. In cazul in care comanda pe care o executam nu ne returneaza valori si nu ne intereaza ca data contextul sa fie aware ca datel