Valdis Iljuconoks

AppFabric beta 2

2010-03-03T14:42:00Z

Tiem, kas nav pamanījuši, tad bijušais projekts ar koda nosaukumu “Velocity” kādu laiciņu atpakaļ ir ticis pārsaukts par “AppFabric”. Varbūt ne pats veiksmīgākais buzz-words šim projektam, bet anyway galvenā ideoloģija un iespēju sets ir saglabājies un nākušas tikai klāt jaunas iespējas.

Tātad vakar (2. martā) klajā tika laista beta 2 versija, kas ir bināri savietojama ar VS 10 RC būvējumu.

Kopsummā var just, ka “Velocity” projekts šā vai tā “skrien” pakaļ nu jau aizbraukušajam vilcienam :) Cerams, ka ar VS 11 versiju, kešatmiņas un scalability risinājums tiks iekļauts pilnvērtīgi jau platformā un tiks pakļauts vienotai laidienu politikai, kā tas pamazām notiek ar visām vairāk vai mazāk svarīgām bibliotēkām.

Tātad, ja ir vēlme paspēlēties un saprast, kas ir AppFabric, ir vērts iegādāties beta 2 versiju – šeit.

Cerams, ka noderēs!

Grāmatvedību uzticam pašam objektam

2010-02-28T21:30:00Z

Līdz ar RC versijas izlaišanu jaunajai vizuālajai studijai ir iespēja papētīt jaunās iespējas, kas līdz šim bija pieejamas tikai dažādās spēka pakotnēs (angl. power packs) vai nākotnes vīziju (angl. feature preview) saturošās instalācijas paciņās.

Šoreiz stāsts par jaunā Entity Framework (EF) iespēju – “Self-Tracking Entities”. Šī iespēja piedāvā veidot datu modeļus, kuri paši parūpējas par datu izmaiņu grāmatvedību iekšienē pašā objektā.

Lai uzskatamāk nodemonstrētu šo iespēju vislabākais veids ir to salīdzināt ar līdz šim pieejamajām EF iespējām.

Piemērs ir pavisam triviāls, bet uz vienkāršākajiem piemēram parasti tēma ir saprotamāka un uztveramāka :)

Tātad datu modelis ir pavisam vienkāršs (klienti un to adreses).

Pieņemot, ka mums ir jau izveidots EF datu modelis, varam veikt kādu konkrētu objekta instances atlasi.

using (var ctx = new ClientDataEntities())
{
    client = ctx.Clients.Single(c => c.Name.Equals("Jānis"));
}

Pieņemsim, ka ārpus ielādes konteksta (mainīgais ctx) ir nepieciešams veikt ielādētā objekta manipulācijas – rediģēšanu mainot tā datus un statusu.

client.Surname = "Bērziņš";

Veicot objekta datu modifikāciju, objekta status mainās uz “Modified”, kas arī ir pareizi un loģiski sagaidāma uzvedība no EF.

Un pēc tam izmantojot citu kontekstu veicam modificētā objekta saglabāšanu:

using (var ctx2 = new ClientDataEntities())
{
    ctx2.Clients.Attach(client);
    ctx2.SaveChanges();
}

Pēc objekta pievienošanas pie jaunā konteksta redzams, ka tā status tiek uzstādīts pa jaunu uz “Unmodified”, kas arī atbilst dokumentācijai.

Lai novērstu šo nelielu “īpatnību” EF platformai, nākas nedaudz pasvīst. Pirmāmkārtām jau sameklējot pareizo dokumentāciju par šo tematu. Galu galā šai iespējai ir divi risinājumi. Viens – “pievienot objektu un naturāli pateikt, ka tas ir mainīts, pat īsti neuztraucoties par to, vai ir vai nav mainīts”. Kodā tas izskatās apmēram šādi:

using (var ctx2 = new ClientDataEntities())
{
    ctx2.Clients.Attach(client);
 
    ObjectStateEntry stateEntry = null;
    if (ctx2.ObjectStateManager.TryGetObjectStateEntry(client.EntityKey, out stateEntry))
    {
        stateEntry.ChangeState(EntityState.Modified);
    }
 
    ctx2.SaveChanges();
}

Šis piegājiens neizskatās diez ko iepriecinošs un lasāms. Pastāv arī otra iespēja – “ielādēt oriģinālo objekta versiju un izmantojot jaunā objekta versijas datus izmainīt esošo”. Kodā tas izskatās apmēram šādi:

using (var ctx2 = new ClientDataEntities())
{
    var originalClient = ctx2.Clients.Single(c => c.Id == client.Id);
    ctx2.Clients.ApplyCurrentValues(client);
    ctx2.SaveChanges();
}

Šai pieejai ir daudz uzskatāmās un lasāmāks kods, bet starpība ir tāda, ka šī pieeja prasa vēlreiz griezties pie datubāzes, lai iegūtu vēlamā objekta oriģinālās vērtības. Iedomājieties, kas notiek, ja nepieciešams saglabāt lielu un apjomīgu objektu grafu.. ?!

Šis piemērs ir pavisam triviāls, bet iedomājieties, kāds kods ir jāuzraksta, lai pareizi saglabātu saites starp objektiem, kas mainīti ārpus konteksta? Jo reti kura reālas dzīves biznesa aplikācija aprobežojas tikai ar vienu objektu un tā īpašību maiņu :)

Bet pašlaik noteikti jūs domājat par vienu – kāda hr*** pēc nepieciešams ielādētu vienību mainīt un saglabāt ārpus saistošā konteksta? Daudzas reizes man nācies mutiski pamatot pielietojuma jēgu un scenāriju. Šoreiz to darīšu ar diagrammas palīdzību. Viens no klasiskākajiem scenārijiem, kur rodas šāda veida pielietojums – ir no prezentācijas slāņa ielādēta (vai nu sākotnēji vai arī pēc lietotāja manipulāciju veikšanas) EF objekta nodošana apstrādei kādai no biznesa loģikas slāņa komponentēm. Arhitektūras diagrammā tas izskatās apmēram šādi:

Sarkanā bultiņa nozīmē, ka prezentācijas slāņa komponentēm (web lapām vai kādam citam koda fragmentam) klasiskajā scenārijā ir jāparūpējas par sekojošām niansēm:

dati jāizgūst no datu avota;
datus parasti atmiņā reprezentē kādā noteiktā objektu modelī (šajā gadījumā – tas ir EF);
tie jāparāda klientam jeb sistēmas lietotājam, tātad jāveic iegūto datu attēlošana;
ja sistēma piedāvā arī atpakaļ saiti prezentācijas slānī ar iespēju veikt arī kādu objektu modifikāciju, tas nozīmē, ka prezentācijas slānim ir jāparūpējas par iegūtu jauno datu sasaisti ar objektu modeli;
ja sistēma ir veidota pēc labākajām praksēm un vadlīnijām, tad prezentācijas slāņa komponentes neatbildēs par objektu jauno vērtību saglabāšanu datu bāzē, bet pretēji – nodos tās kādam zemāk stāvošajam slānim pēcapstrādei;

Šeit arī parādās problēma par ko ir runa – kā veikt pareizi jauno vērtību saglabāšanu datubāzē. Šai problēmai ir potenciāli vairāki “nesmukie” risinājumi:

ielādes konteksts, caur kuru notiek objektu ielāde, ir vienmēr pieejams visu slāņu komponentēm. Neatkarīgi no tā vai sākotnējā ielāde notiek no biznesa loģikas vai prezentācijas slāņa, visām komponentēm ir pieejams šis konteksts. Panākt šādu iespēju var vai nu “vazājot” sākotnējo kontekstu visur cauri visiem slāņiem (parasti realizē, kā extra parametru visām nepieciešamajām metodēm) vai arī turēt kontekstu kādā no kešatmiņas risinājumiem (iedomājieties, kā varētu bez papildus piepūles nodrošināt to arī pie mērogojamas (angl. scalable) vides).
vai arī izmantojot kādu no augstāk minētajiem paņēmieniem.

Tomēr, jaunā EF versija mums piedāvā pilnvērtīgi izmantot T4 (Text Template Transformation Toolkit) iespējas, ko mums piedāvā EF kopā ar VS10 versiju.

Tātad, viss ko atliek izdarīt – izveidot “Self-Tracking Entities” koda ģenerācijas failu.

Izveicams tas ir spiežot labo peles pogu uz EF modeļa un izvēloties “Add Code Generation Item...”.

Un izvēloties “ADO.NET Self-Tracking Entity Generator”

Pēc koda ģeneratora failu pievienošanas risinājuma pārlūks (angl. Solution Explorer) var izskatīties nedaudz dīvaini.

Redzams, ka pievienojot šos koda ģeneratora failus ir izveidojušies jauni 2 faili:

SelfTrackingClientDataModel.Context.tt. Šis fails atbild par konteksta ģenerāciju un visu ar “Self-Tracking” funkcionalitātes nodrošināšanu saistītām lietām.
SelfTrackingClientDataModel.tt. Šis fails nodrošina EF modelī eksistējošo vienību ģenerāciju, lai tie atbalstītu iebūvēto grāmatvedību un pareizi sadarbotos ar parējām ģenerētajām jaunajām lietām.

Kādā no konferencēm atceros, ka bija diskusija par to, vai šos failus turēt atsevišķi vai panest zem kopējā datu modeļa faila, tādā veidā ilustrējot, ka tie ir neatņemama šī objektu modeļa sastāvdaļa. Laikam vēl joprojām ir palikusi vecā versija :)

Klienta kods pēc savas būtības gandrīz nemaz neizmainās. Lai izmantotu jaunās iespējas un saglabātu izmainītos datus kods ir apmēram šāds:

using (var ctx2 = new ClientDataEntities())
{
    ctx2.Clients.ApplyChanges(client);
    ctx2.SaveChanges();
}

Tomēr, kā rāda SQL Profiler, izmaiņas netiek saglabātas datu bāzē. Tas ir saistīts ar to, ka ChangeTrackingEnabled netiek uzstādīts uz true pēc noklusējuma un patiesībā tas arī nav nepieciešams (tas ir saistīts ar objektu de-serializāciju un citām kosmiskām lietām). Tas kas ir nepieciešams, pirms izmaiņu veikšanas nepieciešams explicity uzsākt grāmatvedības procesu.

client.StartTracking();
client.Surname = "Bērziņš";
client.StopTracking();

Pēc šīm izmaiņām, programmas kods strādā kā plānots.

Client client = null;
 
using (var ctx = new ClientDataEntities())
{
    client = ctx.Clients.Single(c => c.Name.Equals("Jānis"));
}
 
client.StartTracking();
client.Surname = "Bērziņš";
client.StopTracking();
 
using (var ctx2 = new ClientDataEntities())
{
    ctx2.Clients.ApplyChanges(client);
    ctx2.SaveChanges();
}

Ja mums EF objektu modelī ir arī kādas saites starp objektiem, to nodrošināšana ar pareiziem statusiem un tālāka saglabāšana uz datu bāzi ir tik pat vienkārša kā ar elementārām objekta īpašībām:

client.StartTracking();
client.Surname = "Bērziņš";
 
var address = new Address
{
    Id = Guid.NewGuid(),
    Street = "Miera",
    House = "7",
    Client = client
};
 
address.MarkAsAdded();
 
client.StopTracking();

Atliek tikai pareizi parūpēties par jaunpievienotā objekta stāvokli.

Tas arī viss. Tātad jaunās T4 iespējas mums dod pievienot savus koda ģeneratorus, kas veiks nepieciešamo darbu. Šajā gadījumā pozitīvi ir tas, ka Microsoft darbinieki paši laiž klajā daudz dažādus noderīgus šablonus.

Cerams, ka noderēs!

Kopējam pirmkodu ar jauno VS versiju

2010-02-28T18:29:00Z

Katram kārtīgam bloggeim noteikti ir jābūt CopySourceAsHtml vizuālās studijas spraudim, kas ir ļoti noderīgs, kad vēlas pārējai pasaulei pastāstīt par kādu koda fragmentu vai kādu jaunu iespēju to lieliski noformējot ar visām krāsām un atstarpēm.

Līdz šim nebija sanācis kaut ko īsti no VS 10 versijas izkopēt un piedāvāt savā blogā. Rakstot nākamo postu saskāros ar faktu, ka šis lieliskais spraudnis nemaz nav pieejams priekš jaunās studijas versijas.

Neesmu eksperts studijas spraudņos, bet aplūkojot esošā spraudņa konfigurācijas failu, nemaz nevajag divas augstākās izglītības, lai saprastu tā struktūru un mēģinātu vismaz pielāgot esošā spraudņa versiju jaunajai studijai. Nedaudz paspēlējoties ar failu, pāris reizes pārstartējot studiju un secinādams, ka spraudnis nelādējas, nonācu līdz risinājumam.

Risinājums ir vienkārši samainīt vizuālās studijas versijas numuru, kas minēts spraudņa konfigurācijas failā:

Pēc vizuālās studijas versijas numuru nomaiņas viens no foršākajiem mazajiem spraudnīšiem :) ir ielādējies studijā un pieejams darbam:

Cerams, ka noderēs un happy copying source as html! :)

F# spēka paka

2010-02-19T10:59:00Z

Nesen laists klajā jauna programmēšanas valodas F# spēka paka jeb Power Pack, kas apvieno dažādas interesantas un noderīgas lietas, kuras nav ietvertas standarta valodas bibliotēkās.

Neliels ieskats power pakas saturā, kas sastāv no vairākām bibliotēkām:

FSharp.PowerPack.dll
- Vairākas jaunas maināmi (immutable, atceramies, ka pēc noklusējuma F# tipi nav maināmi) datu tipi, piemēram, HashMultiMap, kā arī vairākas paplašinātās metodes, kuras sniedz funkcionālu pieejas interfeisa tādām datu struktūrām, kā piemēram, List<T>.
- Dažādi matemātiskie datu tipi (Vector, Matrix, utt).
- F# SI mērvienību definēšana izmantojot mērvienību valodas konstrukciju.

[<Measure>]      
/// hertz, SI unit of frequency       
type Hz = s^-1

- Kā arī papildinājumus Async programmēšanai, piemēram, asinhrono I/O paplašinājumus, kā arī dažādas palīdzības funkcijas.
Ir pieejams F# dokumentācijas ģenerators (FsHtmlDoc.exe).
FSharp.PowerPack.Linq.dll – piedāvā F# pieeju dažādām .Net 3.5 platformas iespējām.
- Konvertātori uz izteiksmju kokiem

let adderExpr = <@ fun i -> i + 1 @>.ToLinqExpression ()      
let adder = <@ fun i -> i + 1 @>.Compile()

- Pieejams jauns query operators.

let db = new NORTHWND(connString)      
let sameCountry =       
    query <@ seq { for e in db.Employees do       
                       for c in db.Customers do       
                           if e.Country = c.Country then       
                               yield (e,c) } @>

FSharp.PowerPack.Parallel.dll – piedāvā dažādas paralēlās operācijas uz datu kopām, kuras ir jau pieejamas kā bāzes klases .Net 4.0 platformas versijā.

let nums = [|1..500000|]      
let finalDigitOfPrimes =       
    nums       
    |> PSeq.filter isPrime       
    |> PSeq.groupBy (fun i -> i % 10)       
    |> PSeq.map (fun (k, vs) -> (k, Seq.length vs))       
    |> PSeq.toArray

Power paka pieejama šeit - http://fsharppowerpack.codeplex.com/.

Cerams, ka noderēs!

Beta 2 –> RC

2010-02-12T12:06:00Z

Pienācis laiks ieboototies savā virtualizētajā Windows 7 image failā un pārinstalēt Visual Studio 2010 Beta 2. Kopsummā pāriešanas process no Beta 2 versijas uz Release Candiate ritēja diezgan gludi, bet lieliem izaicinājumiem un problēmām, prestatā Beta 1 -> Beta 2 pāriešanas procesam.

Secība kādā jādara Beta 2 noņemšanai ir:

Visual Studio 2010 Ultimate Edition Beta 2
Visual Studio 2010 Tools for Office Runtime Beta 2
Microsoft .Net Framework 4 Extended Beta 2
Microsoft .Net Framework 4 Client Profile Beta 2

Pēc VS 10 un .Net 4 noņemšanas nepieciešama darba stacijas pārstartēšana.

Pēc tam var likt virsū jau RC versiju.

Sākam no viena gala pārlukot RC izmaiņas un kļūdu labojumus.. ;)
Cerams, ka noderēs!

VS 2010 RC!

2010-02-09T18:11:16Z

Notikumi gan ātri attīstās. Ir pieejama jau VS 2010 RC (Release Candidate) versija. Tiesa gan pašlaik tā ir pieejama tikai MSDN abonementiem, bet vēlāk būs pieejama arī pārējai pasaulei ;) Šeit var sākt lejupielādi, ja ir MSDN abonements.

Gaidām ar nepacietību RTM versiju ;)

Happy!

2009-12-30T13:05:35Z

Priecīgus un jaukus visiem aizgājušos Ziemassvētkus! :)

Tik pat raženu un vēl raženāku, laimīgu un priecīgu Jauno gadu!

Gaidām ar nepacietību jauno gadu un cerams, ka VS10 izlaišanas datums netiks aizbīdīts līdz pat Jāņiem

Ir plāni šajā sakarā :)

Cheers!

Lietotāju grupai var sekot tvīterī :)

2009-12-08T21:06:21Z

Sakarā ar dažādām tehnoloģiskās iespējām, esam nolēmuši svarīgākos momentus piefiksēt arī tvīterī.

Latvijas Microsoft .NET tehnoloģiju grupas notikumu un svaigāko jaunu saraksts ir iegūstams šeit.

Tvīteris atspoguļos jaunākos notikumus, plānotos pasākumus, kā arī vienkārši stāstīts, kas grupā notiek un tiek plānots.

Cerams, ka noderēs!

jQuery prezentācijas materiāli

2009-11-29T16:23:00Z

Sveicins visiem!

Ir pieejami ir pagājušās .Net lietotāju grupas sanāksmes, kas norisinājās 2009-11-26 Kongresu namā, prezentācijas materiāli par “jQuery” šeit.

Cerams, ka noderēs!

Html parsētājs

2009-11-16T06:29:00Z

Ja gadījumā, kādreiz nepieciešams kaut ko iesākt ar Html atbildes dokumentu, kas saņemts no kāda servera un mēģināt izanalizēt, cik slikti izstrādātājs drāts otrā galā ir konstruējis Html dokumentu un cik ļoti tas neatbilst visiem standartiem, tad noteikti varu ieteikt Html Agility Pack, kuram pēdējā beta versija ir parādījusies šī gada oktobrī, kas liecina par sava veida dzīvīgumu šajā projektā. Nu vismaz nav galīgi palicis novārtā ar atzīmi, ka pēdējās aktivitātes veiktas projekta ziedu laikos kaut kad tālu tālajā 2004. gadā :)

Pirms uzdevuma izpildes bija doma arī izmantot WatiN projektu, lai darbotos ar atbildes Html dokumentu, bet tomēr biju pa slinku, lai līdz galam izpētīti šīs platformas iespējas apstrādāt dokumenta atbildi bez IE iesaistīšanas.

Html Agility Pack kods izskatās pavisam vienkārši. Kopsummā kods neatšķiras ne ar ko no parasta Xml dokumenta apstaigāšanas un struktūras pārlūkošanas pilnvērtīgi izmantojot XPath iespējas.

HtmlWeb site = new HtmlWeb();
var document = site.Load(queryString, "get");
 
var table = document.DocumentNode.SelectNodes("html/body/table/tr/td[2]/table/tr");
 
foreach (var row in table)
{
    var cell = row.SelectSingleNode("td");
    ...
}

Protams, ir jāuzmanās no nepareizi veidotiem un konstruētiem Html dokumentiem, kuru pārlūkošana varētu arī pirmajā piegājienā aizņem mazliet vairāk laika, lai saprastu, kā Html Agility Pack bibliotēkas šo Html dokumentu ir sapratušas.

Cerams, ka noderēs!

Es sarunājos ar Tevi, Apache!

2009-11-15T14:03:00Z

Ir reizes, kad jāpārkāpj sava komforta zona un jāintegrējas ar kaut ko pavismaz *nefamilāru* :) Ir jau nācies darboties ar citu firmu izstrādājumiem, bet tomēr pēdējā laikā ir pārsvarā MS produkti lietošanā tikai.

Tā nu lūk vienā no projektiem nācās sarunāties ar Apache serveri. Drāts otrā galā atradās RESTful serviss, kas nodrošināja zināmu funkcionalitāti, kuru nepieciešams bija izsaukt no .NET platformas.

Pirmajā acu uzmetienā izskatās uzdevums pavisam vienkāršs: izveidojam WebRequest klases instanci, saliekam visus nepieciešamos parametrus un iegūstām atbildes plūsmu. Uzdevums pavisam vienkāršs.

Pirmā mēģinājumā izveidojam visu nepieciešamo support koda bāzi, saliekam nepieciešamās īpašības WebRequest klasei un mēģinām iegūt atbildes plūsmu.

string requestContent =
    string.Format("<xml/>", "arg1", "arg2");
 
var request = WebRequest.Create("http://server/service.xml");
request.Method = "post";
request.Credentials = new NetworkCredential { UserName = "user", Password = "password" };
 
byte[] byteContent = Encoding.ASCII.GetBytes(requestContent);
request.ContentLength = byteContent.Length;
 
Stream stream = request.GetRequestStream();
stream.Write(byteContent, 0, byteContent.Length);
stream.Close();
 
request.GetResponse();

Pēc pieprasījuma izpildes, serveris atgriež sekojošu kļūdu: "(501). Not Implemented.", kas no HTTP standarta nozīmē, ka serveri ir uzprasīts kaut kas tāds, ko šis nav ar mieru darīt.

Tālāk sekoja vairākas stundas dažādos .NET platformas tumšajos koda bibliotēku nostūros, kas tieši vai netieši atbild par dažāda veida komunikācijas veidiem pa drāti. Beigās pat tika izmēģināts WCF RESTful pašrakstīts klients, kas nemaz nebija tik īss, kodolīgs un vienkāršs, kā apgalvoja raksta autors :)

Pa vidu pat tika noimplementēts PHP proxy serviss, kas darbojās līdzīgi kā “man in the middle”, pārķerot visus pieprasījumus no .NET platformas un izpildot tos pret gala serveri un atbildi vienkārši forwardējot atpakaļ .NET klientam. Šis risinājums vismaz strādāja, bet tomēr nebiju ar mieru, ka savā zoodārzā ir jāuztur vēl viens dzīvnieciņš. Jautājums bija gluži kā Madagaskaras pingvīniem: “Nu kur jūs esat redzējuši pingvīnus Ņujorkā??”

Nācās tomēr pētīt tālāk šo problēmu.. Ieejot lieliskajā VS atkļūdošanas un skaņošanas režīmā papētot catch() zaru secinājums ir, ka serveris atgriež sekojošu kļūdu:

"Method <xml/>POST is not defined in RFC 2068 and is not supported by the Servlet API"

Parokoties nedaudz pa interneta plašumiem beidzot uzdūros šīs problēmas risinājumam, kas saistīts ar to, ka Apache serverim ir zināmas problēmas dažreiz atbildēt ar pareizo HTTP statusa atbildi. Klients savu pieprasījumu veido ar “Expect: 100-continue” galvenes ierakstu. Ideja šim ierakstam ir, ja serveris būs gatavs apstrādāt šo pieprasījumu, serverim būtu jāatbild ar “100 Continue” atbildi. Ja turpmākie pieprasījumi tiktu atteikti, tad serverim būtu jāatbild ar izbeigšanas atbildi un attiecīgo statusu (rfc 2616).

Beigu beigās viss beidzas labi un šai problēmai ir risinājums:

string requestContent =
    string.Format("<xml/>", "arg1", "arg2");
 
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(http://server/service.xml);
..
request.ServicePoint.Expect100Continue = false;
 
.. 
request.GetResponse();

Viss ir labi, kas labi beidzas.

Cerams, ka noderēs!

Analītiķu karš

2009-10-30T20:11:37Z

Nesen bija izcēlies neliels kariņš par to, ko lietot analītiķiem UML diagrammēšanā firmā, kas ir MS partneris. Galdā tika liktas dažādas kārtis, rīki, domas, prasības un iemesli. Potenciālais risinājums (bet tomēr vēl neapstiprinātais) – vizuālā studija. Ja nu kādam ievajadzēsies kādreiz kādu špikeri pamatojumiem, vai vienkārši trūks ideju, kā nomotivēt firmu iztērēt pāris štukas iso faila, tad here you go why:

VS10.0 būs pa brīvu anyway (šī ir tikai daļēja patiesība arī partneriem).
VS10.0 būs rīks, kuru lietos developeri, potenciāli arī testētāji. Kāpēc, lai to nelietotu arī analītiķi un arhitekti?
Repositorijam vairāk nevajadzētu būt problēmai. Ir pilnvērtīga integrācija ar. Esošais TFS pakļaujas ikdienas backupiem, ir iespējama web pieeja, utt – tā teikt, viss vienā un pierastā veidā.
Ja UML diagrammas atrodas TFS respositorijā, tas automātiski nozīmē, ka tās tiek versionētas un atsekošana kļūst arvien vieglāka, kurš ko ir mainījis (failu salīdzināšana arī iespējama, jo fails vairs nav binārs).
Ir potenciāli iespējams veidot work itemus atsaucoties uz pašu diagrammu, ja tas protams ir nepieciešams. Veidot sasaistes ar dažādām prasībām, ja tās tiek uzturētas TFS serverī.
Ja diagramma būs TFSā, tas nozīmē, ka potenciāli tā arī būs tuvāk developmentam.
Sadalījums ir pa failiem – viena diagramma ir vienā failā, kas, cik es saprotu no problēmas cēloņa, daudzlietotājus atrisina, kā tas varētu būt citu rīku risinājumos, kur vienā failā ir vairākas diagrammas.
VS10.0 pašlaik nodrošina sekojošas diagrammas:
- class diagram
- sequence
- use case
- activity
- component
- layer
- directed graph
Tas nav tikai analīzes fāzes mistisks orbitāls dokumenta fragments, kura dzīves cikls izbeidzas kopā ar analīzes fāzes beigām – modelēšanas diagrammas dzīvo līdzi kodam un reālai programmatūras attīstības dzīves ciklam.
Ja visas diagrammas ir vienā solution - pieejams ir arī UML explorer, kas piedāvā sarakstu ar visiem artifaktiem minētiem risinājumā.
VS10.0 nav tikai UML diagrammas – ir arī arhitektūras diagrammas, kuras varbūt netiek intensīvi izmantotas analīzes fāze, bet noteikti var tikt izmantotas īsi pirms vai izstrādes laikā (konkrēts piemērs par slāņu diagrammu – Layer Diagram).
Visi analītiķi zina vienu rīku un ir lielāka iespējas resource reusability – iespējama ir lielāka resursu cirkulācija.

Pagaidām mīnusi VS10.0:

Nav izteiktas state-chart diagrammas (var izmantot aktivitāšu diagrammu).
Pagaidām ir – VS10.0 ir Beta2, kas nozīmē, ka var būt gļuki, bet Beta2 ir ar GO-LIVE licenci, kas savukārt nozīmē, ka veidotās diagrammas varēs migrēt uz VS10.0 RTM versiju.
Nevar dažas diagrammas izexportēt kā bildi pagaidām (toties smuki kopējas vai arī var veidot screencapture)

Cerams, ka noderēs!

The best place to hide is at the tip of the nose

2009-10-28T17:55:11Z

Nesen sanācis bija darboties ar WCF ziņojumu inspektoriem un citām interesantām un varbūt brīžiem nesaistītām lietām.

Ziņojumu inspektori ir interesanta vieta, kur ievietot savu plumbing code un veikt nepieciešamos vingrojumus pirms pieprasījuma izsūtīšanas otram saņēmējam un pēc atbildes saņemšanas – labākā vieta, kur veikt izejošo un ienākošo ziņojumu žurnalizēšanu.

#region IClientMessageInspector Members
 
public void AfterReceiveReply(ref Message reply, object correlationState)
{
    // do something
}
 
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
    // do something
    return null;
}
 
#endregion

Kods ir ērts, mazs un pārskatāms.

Problēma rodas apstāklī, ka patiesībā starp šīm abām metodēm ir nepieciešams veikt tā saucamo korelāciju – jeb BeforeSendRequest metode veic izejošā ziņojuma žurnalizēšanu (piemēram, INSERT operācijas izpilde kādā Log tabulā) un pēc brītiņa, kad no endpointa ir saņemta atbilde – tiek izsaukta ziņojuma inspektora AfterReceiveReply metode, kurai attiecīgi ir jāveic pirmajā metodes izpildes laikā ģenerētā ieraksta modifikācija.

Pagāja pāris stundas kamēr pāraku MSDN, forumus un citas interesantas vietnes.. :)

Līdz beidzot izdomāju vēlreiz pārlasīt implementētā interfeisa dokumentāciju, kurā skaidri un gaiši (melns uz balta) stāv rakstīts: tas, ko jūs atgriezīsiet BeforeSendRequest metodes rezultātā, tiks padots AfterReceiveReply metodei, kā correlationState parametrs. Microsoft iesaka šajā vietā izmantot Guid.NewGuid() metodi, lai nodrošinātu, ka konkrētās aktivitātes korelācijas identifikācija ir unikāla :)

Nu ko, labākā vieta kur paslēpties, ir pašā degungalā :)

Cerams, ka noderēs!

Jaunais treniņa inventārs

2009-10-26T05:34:00Z

Līdz ar otrās betas publisko parādīšanos Microsoft ir laidis klajā arī atjauninātu treniņa inventāru (iepriekšējā versija šeit), kas noteikti palīdzēs ātrāk un efektīvāk apgūt sekojošas tehnoloģijas:

C# 4.0
Visual Basic 10
F#
Parallel Extensions
Windows Communication Foundation
Windows Workflow
Windows Presentation Foundation
ASP.NET 4
Windows 7
Entity Framework
ADO.NET Data Services
Managed Extensibility Framework
Visual Studio Team System

Treniņa inventārs pēc labākajām tradīcijās iekļauj sevī prezentācijas, laboratorijas darbus, kā arī dažādas demonstrācijas.

Cerams, ka noderēs!

VS2010 b2

2009-10-21T15:42:04Z

Lasot cauri elektroniskā pasta thread’iem par beta divi instalācijas pieredzi no dažādām pasaules malām (pieredze patiesībā nebija nemaz tik iepriecināšana) tomēr ir izdevies iegūt uz sava VHD-ezētā Windows 7 operētājsistēmas virsū beta divi versiju gaidāmajai jaunai studijai.

Tuvākā laikā plānojams atjaunināts skats uz esošajā iespējām no beta viens un jaunievedumiem, kas parādījušies otrajā betā. Kā arī apskatīšu jaunās iespējas, kas ir parādījušās tikai ar otro betas versiju.

Btw, jaunā beta ir ieguvusi brīnišķīgu infinity logo ar zilganām un violetām krāsām.

Cheers!