VM role - o noua dimensiune pentru Windows Azure

Windows Azure permite pana in acest moment doua tipuri de instance:

• web role - similar cu 'Web Application', in principiu orice ce merge pe http si https;
  
• worker role - similar cu un 'Windows Service', ruleaza neincetat prelucrand date;

Nu vreau sa intru in amanunte pe aceasta tema. Pe langa aceste doua, Microsoft ne pregateste un nou rol, denumit VM role. In momentul de fata este in ultima faza de testare, urmand sa apara pe piata cat de curand.
VM role-ul o sa ne permita sa controlam in intregime masina. Este nevoie sa cream local local un VM role pe care apoi sa il copiem in cloud. Pe el o sa putem pune de exemplu Windows Server 2003, putem sa controlam tot ce este instalat pe el. Singurul dezavantaj este partea de administrate care o sa fie facuta in totalitate de utilizator. O parte din pachete de update de exemplu nu o sa mai fie facute automat sau configurarea nivelului de securitate. Iar cloud-ul NU ne ofera back-up la aceasta instanta in mod automat. In cazul in care instanta moare, imaginea care o sa fie folosita este cea pe care am trimis-o ultima data spre cloud. Imaginea care este pusa pe cloud si care este folosita de catre instance pentru a initializa un VM role se numeste "golden image".
Putem sa controlam totul pe aceste intante, de la sistemul de operare la ce aplicatii ruleaza si in ce fel. Dar acest lucru se poate intoarce impotriva noastra, trebuie sa facem si partea de administrare, care poate sa fie uneori costisitoare, nu doar din punct de vedere a timpului cat si financiara.
Se recomanda folosirea acestor tipuri de instante in cazul in care configurarea unui web/worker role ia mai mult de 5 minute. Aici nu stiu ce sa zic, s-ar putea ca noi sa nu fi gandit corespunzator modul in care noi facem deploy.
Chiar daca VM role poate sa para pentru unii un vis devenit realitate, eu il vad mai mult ca in compromis. Trebuie din nou sa facem partea de administrare, licentiere si alte lucruri care cresc pretul final si complexitatea proiectului. Trebuie sa avem un motiv intemeiat cand dorim sa alegem aceasta optiune( poate se preteaza pentru aplicatiile deja scrise, in cazul carora costul portarii pe cloud ar fi destul de mic).

Read More

Code Contracts

Este un tool pentru definirea specificatiilor si pentru validarea acestora in cod.
Are la baza conceptul definit de Vienna Development Method( VDM) care defineste o metoda formala pentru definirea specificatiilor unui soft si definirea integritatii acestuia.
VDM defineste trei elemente:

• invariantii - un set de conditii ce trebuie sa fie adevarate in orice moment pe durata de viata a instantei;
• preconditii - un grup de conditii folosite pentru validarea datelor de intrare;
• postconditii - una sau mai multe conditii care valideaza rezultatul;

Code Contracts nu ne asigura ca programul este corect, doar ne asigura ca un set de reguli sunt indeplinite( iar o parte din specificatii sunt respectate).
La baza Code Contracts sta Spec# care apare in 2007.Aceasta librarie este integrata cu Visual Studio 2010 in 2009. Echivalentrul in Java este Eiffel, care apare cu mult inainte de Spec#.
Mai jos o sa dau un exemplu de cod scris fara Code Contracts care concateneaza o lista de cuvinte:

public string Stick(string[] args)
{
if(args == null)
{
throw new ArgumentNullException();
}
if(args.Lenght < 1 || args[0] == null) { throw new ArgumentException(); } return args.Agregate(string.Empty, (current, r) => current + r);
}

Exista doua IF-uri, care reprezinta preconditiile, iar daca am avea nevoie sa validam rezultatul ar fi nevoie sa salvam rezultatul intr-o variabila, iar apoi sa facem validarea acestuia. Cu Code Contracts totul este mult mai simplu. Orice dezvoltator care o sa vina dupa noi o sa inteleaga cu usurinta care parte din cod reprezinta validarea specificatiilor(pre/post-conditii) si care partea de cod care prelucreaza informatia.

public string Stick(string[] args)
{
Contract.Requires(args != null);
Contract.Requires(args.Lenght < 1); Contract.Requires(args[0] == null);

Contract.Ensures(String.IsNullOrWhiteSpace(Contract.Result()));

return args.Agregate(string.Empty, (current, r) => current + r);
}

La inceput verificam preconditiile ca sa fie valide. In cazul in care una din ele nu este valida aruncam o exceptia pe care o trimitem prin "<..>". Folosind Contract.Ensures putem sa verificam postconditia. Pentru a putea accesa valoarea pe care o returneaza metoda este nevoie sa apelam Contract.Result. Nu are importanta unde plasam Contract.Ensures in interiorul metodei, acesta va fi apelat mereu in momentul in care rezultatul este returnat.
Pentru a putea definii invariantii avem nevoie sa scriem o metoda in interiorul clasei care sa nu primeasca nici un parametru si sa returneze void. Aceasta trebuie sa fie decorata cu atributul ContractInvariantMethod.

[ContractInvariantMethod]
void CustomQueueInvariant()
{
Contract.Invariant(_list != null && _list.Count >0);
}

In exemplul dat mai sus, se va verifica mereu daca _list este diferit de null si contine cel putin un element. Trimiterea unui mesaj custom se face exact la fel cum se face pentru Assert, se poate trimite prin al doilea parametru la fiecare metoda un string care sa reprezinta mesajul custom pe care noi vrem sa il trimitem.
Urmatoarea intrebare este cand se face aceasta validare?
In functie se setariile sistemului, aceasta validare se face la compilare, iar dezvoltatorul o sa fie notificat printr-un warning sau o eroare( depinde de setari). O alta optiune este ca aceasta validare sa se faca in momentul in care cineva foloseste assembly-ul pe care noi l-am oferit. De exemplu daca se apeleaza Stick fara a se face o validare ca args sa fie diferit de null, in cazul acesta un warning poate sa apara. Nu este nevoie sa se faca inainte de apel "If (args !=null) ... ", compilatorul verifica automat daca se poate ajunge la acest apel iar parametrul sa fie null. Daca exista aceasta posibilitate el ne va notifica.
Cel mai tare lucru care mi s-a parut este posibilitatea de a definii invariantii pentru o interfata, iar orice alta clasa care va implementa interfata data va fi nevoita sa respecte invarianti definiti. De exemplu vrem ca orice dezvoltator care implementeata interfata IIdentifiable sa aibe Id-ul diferit de valoarea default. Pentru acest lucru putem sa avem:

public interface IIdentifiable
{
Guid Id{get;set;}
}

public class IdentifiableValidator : IIdentifiable
{
public Guid Id{get;set;}

[ContractInvariantMethod]
void CustomInvariant()
{
Contract.Invariant(Id != Guid.Empty);
}
}

Orice clasa care va implementa interfata definita de noi va fi obligata sa respecte conditia pe care noi am definito. Iata un exemplu umpic mai complicat:

public interface IIdentifiable
where TType : class
{
TType Id { get; set; }
}

public class IdentifiableValidator : IIdentifiable
where TType : class
{
public TType Id { get; set; }

[ContractInvariantMethod]
void CustomInvariant()
{
Contract.Invariant(Id != default(TType));
}
}

Exista cateva metode de baza pe care o sa le enumar mai jos:

• Contract.Requires() - definire preconditii;
• Contract.Ensures() - definire postconditii;
• Contract.Invariant() - definire invarianti;
• Contract.Result() - se obtine rezultatul returnat de metoda;
• Contract.OldValue(T) - se obtine valoarea vechie a unui field, propietati a clasei, inainte de apelul metodei curente( se poate folosii pentru a ne asigura va valoarea unei propietati s-a modificat - valoarea unui contor de exemplu s-a schimbat);
• Contract.Assert() - assert definit prin intermediul Code Contracts;
• Contract.ForAll() - iterarea unei liste pentru verificare unei pre/post-conditii;

Nu o sa intru in detalii despre modul in care se poate configura Code Contracts pentru fiecare proiect in parte, va las pe voi sa descoperiti.
Code Contracts nu a fost creat pentru a inlocuii testele, nu renuntati niciodata la ele. Code Contracts poate sa ajute la definirea specificatiilor in cod si pentru a ne asigura ca acestea sunt mereu indeplinite.
Puteti sa gasiti un mic demo aici:
http://ronua.ro/CS/groups/ronua-cluj-napoca/media/p/217648.aspx

Read More

Intalnire RONUA: 2 martie 2011

Comunitatea RONUA din Cluj-Napoca a ajuns la a doua intalnire in acest format. Cei care doresc sa participle ii rog sa imi dea un reply la acest email pentru a putea sa stim la cate personae sa ne asteptam. Va asteptam.

Oricine e interesat in a afla si discuta subiecte interesante din lumea .NET si nu numai, e asteptat in data de 02 martie (miercuri), de la orele 19:00, la urmatoarea intalnire RONUA Cluj.

In urma votului, au ramas doua subiecte:
• ESB (enterprise service buss) - un mecanism prin care mai multe module (aplicatii) pot comunica intre ele, trimitand un fel de notificari http://en.wikipedia.org/wiki/Enterprise_service_bus (Radu Vunvulea)
• Customizable (desktop) applications design (Dragoș Andronic)
* se da un produs (desktop, windows, .net)
* 80% din functionalitate este ok pentru toti clientii insa fiecare client vrea altceva de la restul de 20% (adica doreste ca aplicatia sa ii fie customizata conform propriilor nevoi)
* ca sa realizam asta va voi prezenta 2 idei arhitecturale (exemplificate cu cod) prin care:
o deschidem spre customizare "main application workflow-ul" prin "pre action hooks" si "post action hooks". Tot legat de acest subiect voi prezenta si un model de organizare a codului (layere si assembliuri) pentru a usura astfel de customizari
o permitem clientului sa customizeze structura de meniuri a aplicatiei (main menu, toolbar menus. context menus): componenta meniurilor, aspectul lor, functionalitatea lor
(durata: ~ 1h)
Fiecare prezentare va fi urmata (daca se doreste) de discutii libere pe marginea subiectului.
Locatia: Evoline, Sigma Tower (fostul IEIA), Strada Republicii, nr. 109, etaj 3.
Cart. Zorilor, intersectia dintre Republicii si Observatorului; acess cu autobuzele 35, 46, 50, 43.
Map: http://www.wikimapia.org/#lat=46.7562728&lon=23.5945129&z=17&l=0&m=b&v=8
(Va trebui sa rugati jos la receptie sa va "trimita" cu liftul la 3 deoarece lifturile merg doar cu cheie.
In caz ca nu va descurcati, gasiti "suport tehnic" la 0751569435 :) - Dragos Andronic (ando)).

Sursa: http://ronua.ro/CS/groups/ronua-cluj-napoca/forum/t/8067.aspx

Read More

SOLID - Design patterns

SOLID este un acronim de la:
SRP - The Single Responsibility Principle: o clasa ar trebui sa aibe o singura responsabilitate;
OCP - The Open Closed Principle: o clasa trebuie sa fie deschisa la extindere fara a necesita modificarea ei;
LSP - The Liskov Substitution Principle: clasele derivate pot sa fi inlocuite de clasele de baza;
ISP - The Interface Segregation Principle: interfete cu granulatie fina, specifice unei anumite responsabilitati, specifice unui anumit client;
DIP - The Dependency Inversion Principle: dependintele trebuie sa fie definite prin interfete si clase abstracte si nu prin clase concrete;

The Single Responsibility Principle( SRP)

"There should never be more than one reason for a class to change." — Robert Martin

O clasa trebuie sa faca doar in singur lucru si nimic mai mult. Fiecare clasa in parte trebuie sa aiba o singura responsabilitate. O clasa care are o singura responsabilitate este mai usor de modificat, mult mai usor de inteles si mai usor de testat. Totodata daca o clasa are mai multe responsabilitati avem mai mari sanse ca acelasi cod sa apara si in alte clase.
O clasa care are mai multe functionalitati este prea mare, face prea multe si este mult prea complicata. Cel mai usor lucru pentru a rezolva aceasta problema este sa facem split la clasa.

Open Closed Principle( OCP)

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." — Robert Martin

O clasa trebuie sa fie deschisa spre extindere si inchisa spre modificare. Comportamentul unei clase ar trebui sa fie modificat prin mostenire si prin compozitie. Principala idee este ca functionalitatile logice sa fie cat mai bine definite, iar daca este cazul acestea sa fie mutate in alte clase si referite prin intermediul interfetelor.
De exemplu daca avem o clasa ce face validarea unui obiect, aceasta nu trebuie sa contina si regulile de validare. Acestea pot sa fie referite prin intermediul unei interfete si transmise prin constructor. In felul acesta daca regulile se modifica, nu o sa fie necesar sa modificam clasa care face validarea. Astfel regulile de validare o sa poata fi schimbate mult mai usor.

Liskov Substitution Principle( LSP)

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." — Robert Martin

Ideea de baza este ca putem inlocui instanta unei clase cu subclasa fiu si totul sa functioneze normal. Nu este tocmai usor de facut acest lucru, deoarececlasa poate sa aibe un set de actiuni specifice care sa nu se mai regăsească in clasa fiu.
Un bun exemplu este exemplu clasic cu dreptunghiul si patratul, unde un patratul poate sa mosteneasca din dreptunghi dar laturiile deja difera ca denumire si logica.
Dar asta nu inseamna ca nu trebuie sa incercam sa respectam LSP. Trebuie sa incercam sa facem clasele de baza cat mai generice. Aceasta regula nu se aplica mereu, dar exista cazuri cand este foarte utila. De foarte multe ori nu putem modela obiectele exact la fel cum sunt in lumea reala prin mostenire, dar ne putem folosi de compozitie pentru acest lucru.

Interface Segregation Principle( ISP)

"Clients should not be forced to depend upon interfaces that they do not use." —Robert Martin

Fiecare interfata trebuie sa fie cat mai simpla si sa defineasca un singur lucru( sa fie specifice). In cazul in care avem o interfata foarte mare, cel mai bine este ca aceasta sa fie sparta in functie de ce responsabilitati are. In cazul in care avem mai multe functionalitati intr-o clasa, atunci in clasa respectiva va fi nevoie sa implementam toate interfetele de care avem nevoie. De multe ori daca avem o interfata foarte mare, clientul nu o sa aibe nevoie sa implementeze toate functiile, ci doar o parte din ele, a.i. se ajunge ca o mare parte din metode sa nu fie implementate.

Dependency Inversion Principle( DIP)

"A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions." — Robert Martin

Daca o clasa are dependinte fata de alte clase, acestea ar trebui sa fie prin interfete si clase abstracte si nu prin clase concrete. Prin acest mod clasele se pot modifica mult mai usor, o sa fie mult mai decuplata si mult mai usor de testat.
Daca respectam acest principiu, putem folosi Dependency Injection fara nici o problema. Totodata putem mult mai usor sa separam nivelele unei aplicatii.

Read More

Metoda marcata cu abstract si override

O metoda sau o propietate poate sa fie marcata ca abstracta cand aceasta nu contine si implementarea.
O metoda sau o propietate poate sa fie marcata ca override cand vrem sa modificam implementarea si sa oferim o noua implementare pentru un menbru mostenit din clasa de baza.
Pana aici nimic deosebit, OOP pur. Oare putem sa avem o metoda care sa fie marcata atat abstracta cat si override? Raspunsul este DA. Desi pare ciudat, putem sa marcam o metoda cu aceste doua atribute:

public void abstract override DoWork();

Cand putem sa avem acest caz?
Cand avem o clasa abstracta care contine o metoda virtuala.

public abstract Actiune
{
   public virtual void DoWork()
   {  
       Console.Write("Actiune1.DoWork");
   }
}

Aceasta clasa poate sa fie mostenita de o alta clasa care sa ofere o alta implementare de baza la metoda DoWork.

public abstract Actiune2 : Actiune
{
   public abstract override void DoWork();
}

Orice clasa ce va implementa clasa abstracta Actiune2 o sa fie obligata sa ofere o implementare la metoda DoWork(), chiar daca Actiune2 mosteneste din clasa abstracta Actiune1 care ofera o implementare pentru metoda noastra.

Read More

IComparer generic - propietatea Default

De obicei cand dorim sa putem compara doua obiecte de acelasi tip folosim IComparar. Aceasta ne pune la dispozitie metoda

int Compare(T x, T y);

Valorea returnata de aceasta metoda poate sa fie:

• >0 - daca x este mai mare ca y;
• =0 - daca x este egal cu y;
• <0 - daca x este mai mic ca y;

In cazul in care una( sau amandoua) din valori, metoda poate sa returneze:

• >0 - daca y este null;
• =0 - daca x so y sunt null;
• <0 - daca x este mai mic ca y;

Dar pentru a putea face aceasta comparatie una din valori trebuie sa fie diferita de null, atlfel o sa avem parte de NullReferenceException. Pentru a putea rezolva aceasta problema putem sa avem ceva de genul:

var valoare = x == null ? ( y == null ? 0 : -1 ) : x.CompareTo(y);

Este necesar sa verificam daca una din valor este null. Valoarea lui y nu trebe sa o verificam obligatoriu, dar cea a lui x trebuie sa o verificam mereu.
Pentru a rezolva acest neajuns, avem la dispozitie propietatea Default pe IComparable. Aceasta va crea automat comparatorul default pentru tipul de data dat. De exemplu daca lucram cu un obiect de tip nullable, putem sa evitam sa facem verificarea descrisa mai sus folosind aceasta propietate:

int? x,y;
// ...
var valoare = Comparar<int?>.Default.Compare(x,y);

Acesta va crea instanta in regim de Singleton, o instanta a clasei Comparer. Tipul de data T pe care il folosim trebuie sa implementeze interfata IComparable.
Aceasta propietate ne poate scapa de grijile de a verifica fiecare element daca este null inainte de a face compararea.

Read More

AutoMapper - object to object mapper

Acest mic framework ne ajuta cand trebuie sa mapam doua entita cu aceleasi propietati. In mod traditional pentru a face acest lucru trebuie sa scriem ceva de genul:

CarDb carDb = LoadFromDb(id);
// ...
Car car = new Car()
     {
          Type = carDb.Type,
          Number = carDb.Number,
          Owner = varDb.Owner,
          RegFrom = carDb.RegFrom                            
     };

Acest caz apare mai ales cand avem o aplicatie pe mai multe nivele, iar modelul care persista in baza de baza de date si modelul care ajunge la client sunt diferite.
Ce poate sa faca AutoMapper, este sa faca automat copierea valorilor proprietarilor, fara sa mai scrim noi cod. In cazul in care propietatea primeste o alta valorea sau are un nume diferit, putem sa scriem o expresie lambda care sa faca conversia.
Mai jos o sa gasiti cateva exenple:
1. Mapare intre doua entitati Car si CarDb

// Creare mapare.
Mapper.CreateMap<CarDb,Car>() ;
// Conversia propriu-zisa.
Car car = Mapper.Map<CarDb,Car>(carDb) ;

In loc sa avem o lista de propietati la care sa facem atribuiire, a fost nevoie sa apelam doar metoda CreateMap.
2. Maparea a doua propietati de tipuri diferite.
Sa presupunem ca Car contine o propietate IsHit de tip bool, iar CarDb contine aceiasi propietate, dar este de tipul int.
Pentru acest lucru este nevoie sa cream un nou ValueResolver care sa stie sa convertească din int in bool. ValueResolver este un tip de data definit de AutoMapper, folosit pentru a face conversii intre date.

public class HitIntToBoolResolver : ValueResolver<int,bool>
{
     protected ovveride bool ResolveCore(int val)
     {
          return val==1;
     }
}

Iar pentru a face maparea trebuie pe CreateMap sa adaugăm resolver-ul custom:

Mapper
     .CreateMap<CarDb,Car>()
     .ForMember(
          car => car.IsHit,
          x => x.ResolveUsing<HitIntToBoolResolver>().FromMember( m => m.IsHit));

In acest moment, pentru propietatea IsHit, se va face o conversie automata din int in bool.
3. Cum sa atribuim o valoare custom la o propietate.
Sa presunem ca entitatea Car are o propietate FullNumber de tip string formata din RegDate+Number. Pentru a putea seta aceasta valoare in AutoMapper este nevoie sa scriem urmatorul cod:

Mapper
     .CreateMap<CarDb,Car>()
     .ForMember(
          car => car.FullNumber,
          x => x.MapFrom( e => e.RegDate.ToString() + e.Number ));

In acest fel putem genera valori custom orice propietati.
4. In cazul in care entitatea are propietati care la randul lor trebuie mapate, ajunge sa definim maparea tuturor tipurilor de date implicate, in ncazul nostru este nevoie sa definim o mapare in plus pentru tipul de data Builder( presupunem ca entitatea Car are o propietare cu numele BuildBy de tip Buildder.

Mapper.CreateMap<BuilderDb,Builder>

AutoMapper va detecta automat ca aceasta propietate este deja mapata si va folostii maparea definita deja.

Mapper.CreateMap<BuilderDb,Builder>();
Mapper .CreateMap<CarDb,Car>();
Car car = Mapper.Map<CarDb,Car>(carDb) ;

Din punct de vedere a vitezei, nu va asteptati sa fie la fel de rapid. In spate AutoMapper se bazeaza pe Reflection. Fata de o mapare manuala este undeva de 6-7 ori mai lent. In cazul in care nu aveti nevoie de mii de conversii pe secunta, cred ca AutoMapper este o solutie foarte buna. Obtinem un cod mai usor de intretinut si mult mai clar.
Link:

https://github.com/jbogard/AutoMapper

http://automapper.codeplex.com/

Read More