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

Globalization se refera la formatarea elementelor precum data, ora, moneda, valori numerice . Localization se refera la afisarea textului si a continutului in limba dorita. Localization != Internationalization Internationalizarea se refera la procesul de desing a unei aplicatii a.i. sa poata suporta limbi diferite. Pe cand localizarea se refera la procesul de adaptare a unei aplicatii pentru o anumita limba.

Durata de viata a unei sesiune se poate seta din fisierul de configurare. Valoarea minima pe care o poate avea este 1 minut: <sessionState   mode = " InProc "   timeout = "1" / > Cand setati durata de viata la sesiune trebuie sa avegi grija ca IIS, by default face recyle la AppPool odata la 120 de minute. Ambele valori trebuie modificate daca doriti ca durata de viata a sesiunii sa fie mai mare. Dintr-o aplicatie ASP.NET, folosid metoda Session_End din Global.asax nu o sa puteti prinde mereu acest eveniment. Pentru mai multe detalii: http://vunvulearadu.blogspot.com/2011/11/when-sessionend-is-called.html. Pentru a putea detecta daca o sesiune este noua putem sa verificam valoarea propietatii Session.IsNewSession.Aceasta propietate este TRUE cand sesiune este noua. Folosit aceasta propietate pe ASP.NET MVC3 ne putem declara un action filter prin intermediul caruia sa detectam daca sesiunea a expirat. public   class   Sessi1onExpireFilterAttribute  :

Astazi vreau sa vorbim despre ViewBag. Daca nu l-ati folosit pana acuma, in MVC 3 acesta este un dictionar dynamic, in care se pot pune valori pentru a fi trasmise de la controller la view date. Cel mai nice lucru la el este ca este un tip de data dynamic. Cea ce inseamna ca putem sa facem get/set la date folosind propietati pe post de keys. In loc de:     ViewData["DateNow"] = DateTime.Now;     ViewData["Age"] = 55 ; Avem:     ViewBag.DateNow = DateTime.Now;     ViewBag.Age = 55; Sa trecem la lucruri mai interesante. Daca avem un View care contine un partial view in care populam ViewBag-ul( desii nu e sanatos poate sa apara cazul acesta), o sa observam ca in view-ul parinte sau in _Layout, ViewBag-ul nostru nu contine elementele pe care le-am adaugat. Prima reactie este sa spunem ca este sa spunem ca este un bug. Daca ne uitam putin peste cum functioneaza MVC 3 o sa descoperim ca de fapt la partial view primeste propiul sau ViewBag. Solutia pentr

Care sunt avantajele/dezavantajele folosirii Server.Transfer in loc de Resposese.Redirect? Server.Transfer nu trimite la brower un mesaj prin care ii spune sa incarce o alta pagina. Din aceasta cauza nu se mai face un drum pana la client pentru a face redirectarea. Prin acest mecanism serverul nu mai trebuie sa rezolve atatea cereri HTTP. Trebuie avut grija deoarece Server.Transfer pastreaza URL original la client. Cea ce poate sa ne induca in eroare la debug sau daca vrem sa facem SEO. Daca vrem sa redirectam userul spre o pagina externa( de exemplu www.google.ro), atunci Server.Transfer nu o sa poate sa fie folosit. Server.Transfer are un parametru optional denumit “preserverForm”, care daca este setat pe TRUE, query-ul string-ului si toate variabilele din forma sunt trimise mai departe. Exista un bug care apare uneori cand vrem sa transferam aceste valori. Pentru a evita aceast bug putem sa setam "enableViewStateMac" pe TRUE pe pagina spre care facem redirectare.

Intr-o aplicatie web, avem doua metode in Global.asax.cs care se apeleaza in momentul in care o sesiune este creata sau cand aceasta se termina: Session_Start Session_End Daca Session_Start este apelat cand o sesiune este create, trebuie avut grija cu Session_End . Exista cateva cazuri cand aceasta metoda nu este apelata: Este apelata doar daca sesiune este “InProc”. Daca tinem sesiune in AppFabric Cache sau pe SQL Server atunci Session_End nu o sa fie apelat. Cand userul inchide browerul. Din cauza ca protocol HTTP este stateless, nu aveti cum sa detectati acest eveniment by default. In functie de brower acest eveniment se poate detecta, dar nu va face trigger la Session_End by default. Daca in sesiune nu aveti nici o informatie atunci metoda Session_End nu o sa fie apelata. Aceasta metoda este apelata de catre un worker processor. Din aceasta cauza pe thread-ul respective nu o sa aveti acces la toate resursele, chiar daca in Session_Start le-ati avut pe toate. De