Valdis Iljuconoks

Jauns gads, jaunas idejas

2013-01-07T22:19:00Z

Vēl viens gads ir pagājis.

Aizvadītais gads ir bijis ražens netikai man, bet arī dotnet.lv grupai kopumā. Ir lasītas neskaitāms lekcijas gan grupas ietvaros, gan arī ir notikuši intensīvi universitātes apmeklējumi visā Latvijā visa gada garumā. Atsauces un iespaidi ir bijuši lieliski un to noteikti arī atkārtošu šajā gadā.

Aizvadītajā gadā cītīgi stradāju un dienas gaismu ieraudzīja ATM Finder aplikācija Microsoft platformām – Windows Phone un Windows 8. Gada laikā ATM Finder aplikācija sasniegusi gandrīz 10k lejupielādes. Saņemts ir daudz atsauksmes no Jums. Paldies!

Darbi arī norit pie nākamajām interesantajām aplikācijām gan mobilajai platformai, gan ari Windows 8 darba virsmai.

Tomēr..

Sekojot Agile Results ietvaram jauns gads ir jauns sākums un iespēja ko mainīt, izvirzīt jaunus mērķus un intensīvi strādāt pie tā lai tos sasniegtu.

Šajā gadā ir izvirzīti augstāki mērķi un idejas.

Šis gads iesākas ar personisko ikubācijas projektu laboratoriju, kas plašāk pazīstama kā Tech Fellow Consulting. Tā ir apvienība, kurā darbojas pieredzējuši problēmu domaina eksperti, nolūkā palīdzēt klientiem programmatūras izstrādes procesu sakārtošanā, arhitektūras definēšanā un modelēšanā, kopējās tehniskās vīzijas skicēšanā un citās interesantās lietās.

Bet galvenokārt, tā ir apvienība, kuras pamatā ir ideja – fun & passion – par lietām, ar kurām nodarbojamies – Software Development.

http://www.tech-fellow.lv/

https://twitter.com/tech_fellow

Keep coding!

[x]

‘ATM Finder’ privacy policy

2012-10-04T07:09:35Z

Privacy:

ATM Finder respects user privacy and therefore no user information is collected nor stored. ATM Finder uses location services to detect device location to provide information about closest ATM machine or bank office. Data collected from location service are not stored or forwarded. User always is able to turn off permissions for ATM Finder application to use location services.

If you would like to report any violations of this policy, please contact us at valdis.iljuconoks@dotnet.lv

Author:

Valdis Iljuconoks, Microsoft MVP

http://www.dotnet.lv/blogs/vi/

Delete Team Project from TFS hosted service (tfspreview.com)

2012-10-01T18:53:00Z

While making some demos and playing around with TFS in the cloud (tfspreview.com) I noticed that it’s not actually possible to permanently delete the team project from user interface. This particular “red cross” besides team project name actually just removes project from MRU (Most Recently Used) list.

What you need to to is to use tfsdeleteproject.exe from Command Line tool.

First of all you need to have permission to Delete team project. That one you can easily set in Administration page in your TFS account. Just click on “gear” icon in the right-upper corner. You can set this permission either on team project or team project collection level, for the user or for the group to which user is member of.

Open Visual Studio Command prompt. And type:

tfsdeleteproject /collection:https://{your-subscription-name}.tfspreview.com/defaultcollection {project-name}

Sometimes you may see some error messages while deleting team project.

Deleting from ProjectServer ...
TF294000: Access denied. Windows Live ID\valdis.iljuconoks@dotnet.lv needs the A
dminister Project Server Integration privilege to perform this action. For more
information, contact your administrator for Team Foundation Server.

This could be ignored for the moment – team project gets deleted regardless of errors.

Remember that you have to use VS 2012 Command Line tools instead of 2010. Because later does not have forward compatibility with tfspreview.com services.

Hope this helps!

Story behind ‘ATM Finder’ v2.0

2012-09-24T19:09:00Z

After a while I’m pleased to announce that “ATM Finder” application has been finally pushed out and published on Windows Phone Store.

This has been incredible learning and exploring period to get things done and up and working. So I think this is good time to share some story behind the scene of “ATM Finder v2.0”.

User interface hasn’t been changed so much. Some small enhancements and polishing.

ATM Finder 1.*	ATM Finder 2.0

So what are the new cool features for the new version? Here goes the list:

1. As more settings switches were coming, I decided to split up “Settings” page into multiple pages grouped in single pivot.

2. Now you can turn on to show map immediately after application start. This mode is usually used when you need to navigate directly to nearest ATM and want to look where it is exactly on the map.

3. Now you can see GPS coordinates on main screen. Some feedback received on this – this could sometimes pretty useful because there is rarely any application that is exposing GPS coordinates to the user.

4. For those guys who are traveling and roaming is generating some expenses – offline (local data stored driven) mode is also still available. Local storage will be a bit out-dated. I’m considering to offer offline-download mode – which would provide a way to download data to local storage for particular area when on WiFi.

5. Now you can select multiple “My home bank”. The feature request was pretty obvious as nowadays in modern world we are having more than one bank and credit card.

6. If there unfortunately some misleading data or location for the ATM is invalid then user has possibility to report this issue to the author and data will be fixed.

And of course feature still remains unchanged – you can still get directions to ATM of your choice using Bing Maps directions services.

A bit longer story goes for the backend.

In previous version “ATM Finder” was driven by local data storage. All the ATMs were stored in local storage, loaded up asynchronously and “some-how in parallel” (are you kidding – that’s a single core phone!, for this I’ll share more details in upcoming posts). The change is that data now in v2.0 is retrieve from Windows Azure cloud service. This change was driven by idea that uploading new ATMs or removing some obsolete ones should not trigger client application update. Now any changes made to the list of the ATMs are done on server side and immediately distributed to the clients on-demand. Data also is cached on the server side not to hit SQL server and generate additional costs. For this in more details – another post is pending.

So in honor to ATM Finder application I though that it’s a good time to share some more details on each of the aspect which I faced during design and development phases in following series of blog posts:

Overall design and planning phase (planning).
Source code and project layout and source control system (planning).
Screen layout and application navigation schema (planning).
Binding and Model-View-View/Model approach (planning).
Reactive Extensions and asynchronous programming on that small device (planning).
Location services (planning).
Working with Bing Maps (planning).
Application state, settings and isolated storage (planning).
Consuming Windows Azure cloud services (planning).
Performance and asynchronous operation model.
Unit testing and UI testing (planning).
Packaging, marketplace certification and publishing (planning).

Also I wanted to give a big thanks to my beta testers for invaluable feedback on early versions of ATM Finder app. Thanks goes to (alphabetical order)

1. Āriņš Ivars (@PiRXlv)

2. Bicāns Jānis (@janisbic)

3. Linkēvičš Gusts (@gstgusts)

4. Maciņš Aigars (@Owandir)

5. Andres Sirel (@asirel)

Cheers! Hope this helps. Take a look at http://bit.ly/atmfinder and waiting always for feedback how cash finding process could be improved and enhanced :)

Product Backlog ātrais pievienošanas panelis

2012-09-18T12:02:40Z

Jaunais Team Foundation Server 2012 (kā arī Services – tfspreview.com) nāk kopā ar ļoti daudz svarīgām un noderīgām iespējām tieši produkta master To-do saraksta (angl. product backlog) pārlūkošanai un plānošanas. Principā TFS piedāvā diezgan plašu klāstu ar lietām, kas nākušas klāt tieši šajā sfērā, bet tas ir atsevišķs stāsts.

Viena no jaukā feature klāsta ir iespēja on-fly pievienot jaunu Product Backlog Item (PBI). Zemāk redzams ātrās pievienošanas panelis, kas dod iespēju ātri un ērti pievienot jaunu lietotāja scenāriju (user story) sarakstam.

Sekojot labākajām Agile praksēm, pārsvarā pietiek tikai nosaukumu, kurā tiek minēti visi nepieciešamie un svarīgākie atslēgas vārdi, kas apraksta šo user story.

Tomēr brīžiem šķiet arī, ka aptuvenais novērtējums ir pietiekami svarīgs, lai to ievadītu uzreiz pie jauna PBI ievades.

Lai nodrošinātu šādu iespēju, jāķeras pie procesa šablona mainīšanas (Process Template Customization).

Lai ķertos klāt pie šablona izmaiņām pastāv divi varianti, kā to darīt:

Lejupielādēt visu procesa šablonu. Šis gadījums noder situācijās, kad grib mainīt iebūvētā šablona uzvedību un iegūt šīs veiktās izmaiņas projektos, kas tiks veidoti TFS serverī, izmantojot šo modificēto šablonu.
Lejupielādēt tikai nepieciešamo definīciju failu. Šis variants noder situācijās, kad nepieciešams mainīt jau esoša projekta uzvedību un izskatu.

Tātad ķersimies pie 2. varianta, jo projekts jau eksistē un vēlamies veikt izmaiņas esošā projektā.

Vispirms nepieciešams atvērt Visual Studio Command Prompt (NB! atceramies, ja ir instalēta arī VS 2010, tad jālaiž ir 2012 komandrinda, jo 2010 šīs jaunās iespējas nebūs un izpildot komandas atpakaļ saņemsim tikai kļūdas paziņojumus).

Visas darbības ar TFS serveri, lai modificēt procesa šablonu, tiek veiktas izmantojot witadmin.exe komandrindinas programmu.

Procesa šablona fails, kas mums nepieciešams, lai modificētu ātrās pievienošanas paneli, iegūstams ar exportagileprocessconfig programmas operācijas parametru.

Jāizpilda sekojoša komanda:

witadmin exportagileprocessconfig /collection:http://{server}:8080/tfs/{collection} /p:{project} /f:agile.xml

Šajā gadījumā jāizpilda bija sekojoša komanda:

witadmin exportagileprocessconfig /collection:http://localhost:8080/tfs/defaultcollection /p:ScrumTest2 /f:agile.xml

Kā rezultātā iegūstam agile.xml failu, kas ir jaunievedums TFS 2012 versijā, lai nodrošinātu šīs jaunās Agile planning iespējas jebkuram procesa šablonam.
Failā jāmeklē ir sekojoša hierarhija:

Šajā kolekcijā atrodas lauki, kuriem jāparādās ātrās pievienošanas panelī.

Sarakstu ar pieejamajiem laukiem ir iespējams iegūt eksportējot PBI definīcijas failu.

witadmin exportwitd /collection:http://localhost:8080/tfs/defaultcollection /p:ScrumTest2 /n:"Product Backlog Item" /f:pbi.xml

Un meklējot sadaļu:

Jāizmanto ir lauka refname atribūta vērtība, lai pievienotu lauku ātrās pievienošanas panelim.

Effort lauks slēpjas zem refname “Microsoft.VSTS.Scheduling.Effort”.

Lai augšielādētu izmaiņas un mainītu esoša projekta izskatu un uzvedību, jāizmanto tā pati witadmin komanda tikai ar importagileprocessconfig komandas operācijas parametru.

witadmin importagileprocessconfig /collection:http://localhost:8080/tfs/defaultcollection /p:ScrumTest2 /f:agile.xml

Ja komanda izpildās bez kļūdas paziņojumiem, tad jaunās izmaiņas ir stājušās spēkā. Pārbāudīt tās ir iespējams vienkārši ejot uz ātrās pievienošanas paneli.

Jāpiemin gan, ka šāda veida izmaiņas nav iespējams Team Foundation Services risinājumā, jo Microsoft neļauj procesa šablonu izmaiņas mākoņrisinājumā.

Cerams, ka noderēs!

Calling a service from Windows Phone application reactively

2012-06-20T06:36:59Z

If you are creating connected Windows Phone application then most probably have noticed that mostly interface what Visual Studio (VS) generates for you in client proxy class is event-based async pattern.

For instance we have defined service (usually this is WCF implementation) method:

public class AtmFinderService : IAtmFinderService       
{       
    public ServiceResponse FindNearby(double latitude, double longitude)       
    {       
        ...       
    }

Generating the client proxy class we can see that VS generated event based approach, when we do have an incredible opportunity to use DoSomethingAsync() method in our favor and then try to catch event which is raised immediately after operation has been completed.

Using this method and event code does look pretty much readable (we will touch body of the event handler later on as well).

proxy.FindNearbyCompleted += (sender, args) =>      
                                 {       
                                     // do something       
                                 };

Suppose if you are sharing the proxy class (for instance, as static member of your service façade). Then for sure you will need a mechanism how you can unsubscribe from the event after method has been executed successfully. More info on subscribing and unsubscribing to the events here - http://msdn.microsoft.com/en-us/library/ms366768.aspx.

So, what we can do is to define event handler and store the reference to the body in class field or member. We can define variable as delegate:

EventHandler<FindNearbyCompletedEventArgs> delg = delegate(object sender, FindNearbyCompletedEventArgs args)       
                                                      {       
                                                          // do something       
                                                      };

or we can define to store as EventHandler:

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
                                                              {       
                                                                  // do something       
                                                              });

Then I figured out that the most easiest way to subscribe only once per call is to unsubscribe first and then subscribe:

proxy.FindNearbyCompleted -= delg;      
proxy.FindNearbyCompleted += delg;

When next time method will be executed event handler added from previous call will be removed first, and then added new one.

Then we can proceed with the actual service method call. So the complete code is:

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
                                                              {       
                                                                  // do something       
                                                              });       
      
proxy.FindNearbyCompleted -= delg;       
proxy.FindNearbyCompleted += delg;       
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

This is more or less everything you need to call service method from Windows Phone in async event-based pattern.

One more note about event handler body. Usually there is requirement to execute event handler on the Dispatcher if that updates something in user interface from another thread (that may happen if event handler is called later on).

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
            {       
                if (Deployment.Current.Dispatcher.CheckAccess())       
                {       
                    Deployment.Current.Dispatcher.BeginInvoke(/* method */);       
                    return;       
                }       
      
                // do something       
            });

Here comes another problem that we need to call the same event handler body only within the Dispatcher context.

Easiest way to implement this requirement would be to implement additional method as event handler and then perform dispatcher check there and if call requires dispatcher context, invoke the same method once more within dispatcher context.

So we are implementing the event handler method first.

private void ProxyOnFindNearbyCompleted(object sender, FindNearbyCompletedEventArgs args)       
{       
    if (!Deployment.Current.Dispatcher.CheckAccess())       
    {       
        Deployment.Current.Dispatcher.BeginInvoke(new Action<object, FindNearbyCompletedEventArgs>(ProxyOnFindNearbyCompleted),       
                                                  sender,       
                                                  args);       
        return;       
    }       
      
    // do something       
}

And then the original code that attaches the event handler and calls the method remains almost the same:

proxy.FindNearbyCompleted -= ProxyOnFindNearbyCompleted;      
proxy.FindNearbyCompleted += ProxyOnFindNearbyCompleted;       
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

However for me this all seems already converting into unreadable spagetti-like code set.

There is a more elegant way to accomplish this. I’m going to use Reactive Extensions for Windows Phone – Microsoft.Phone.Reactive. Library is coming with Windows Phone SDK.

At first we are defining observable from the event-based async pattern.

var completedObservable = Microsoft.Phone.Reactive.Observable.FromEvent<FindNearbyCompletedEventArgs>(       
    ev => proxy.FindNearbyCompleted += ev,       
    ev => proxy.FindNearbyCompleted -= ev);

Those two arguments for FromEvent() method is used to add event handler and to remove event handler for FindNearbyCompleted event. This is also an elegant way how to write code that subscribes to the event only once.

When observable has been created we are able to subscribe to to the event and provide handler to execute when event is raised.

completedObservable.Subscribe(result =>      
                                  {       
                                      // do something       
                                  });

The complete code looks like following:

var completedObservable = Observable.FromEvent<FindNearbyCompletedEventArgs>(      
    ev => proxy.FindNearbyCompleted += ev,      
    ev => proxy.FindNearbyCompleted -= ev);      
      
completedObservable.Subscribe(result =>      
                                  {      
                                      // do something      
                                  });      
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

Pretty straight forward and what’s important – code is readable and understandable.

One more thing, if you require to run event handler on Dispatcher thread, than that’s far more easier than previous implementation with direct checking dispatcher access. You just have to tell reactive extensions that you need to observe events on dispatcher thread rather than on current context.

completedObservable.ObserveOnDispatcher().Subscribe(result =>      
                                                        {       
                                                            // do something       
                                                        });

In summary, code gets reduced, more readable and understandable.

Hope this helps!

When you need something stronger..

2012-06-04T22:22:51Z

Have you seen code fragment like this? I mean there are lot of interfaces that provide stringly-typed access to some of the internals of the entity. This particular code fragment could be seen a lot in EPiServer Relate+ product code samples.

var instance = new SampleType();         
instance.SetAttributeValue("ThisIsTheAttribute", value);

Accessing something that’s not pretty strong enough could be very easy and fast. Not a big deal – just type in attribute name and value.

Here goes why I don’t like interfaces like these:

When you will margin for a grammar error when typing attribute name – that could be discovered only during runtime.
You cannot use static code analysis tools. Like to search for all attribute usages.
You cannot use some of the refactoring tools –> like rename attribute name.
You can easily change type of the attribute and forget about code that uses that, effect –> runtime error.
Use cannot leverage all the power of Visual Studio (for instance to provide Intellisense over available attributes)

So as we see – there a lot more troubles around stringly-typed interfaces than benefit you gain.

We are going to change this in this blog post.

First of all we would need to define client API – that’s how we are going to use our strongly-typed interface to talk to your stringly friend.

I would like to see following things in client API:

There should be an object that would describe structure of the stringly-typed object. Like enumerating all the properties that we would like to have access to. I would call it – a metadata object.
There should be an easy way to convert stringly-typed object into this metadata object.
Metadata object will be used to talk to stringly-typed object via strongly-typed metadata object.

I would see client API and some code snippets as following:

var instance = new SampleType();         
var metadata = instance.AsAttributeExtendable<SampleAttributeMetadata>();         
metadata.SampleAttribute = value;

Metadata class could be described like this:

public class SampleAttributeMetadata         
{         
    public object SampleAttribute { get; set; }         
}

This metadata object is just an object that will provide us strongly-typed access later on.

First things first.

To convert stringly-typed object into some more meaningful instance we would need something “attachable” to original object. Extension methods will come to rescue today.

So we are able to write static method that will attach to original object and behave as instance method for that object. No matter which is your original object (for sake of integrity I’ll use EPiServer Relate+ ‘IAttributeExtendableEntity’ interface).

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()

This means that we are defining extension method for objects that implement ‘IAttributeExtendableEntity’ interface (those are almost all entities in EPiServer Relate+). This ‘IAttributeExtendableEntity’ interface provides stringly-typed access to attributes that you can set or get.

Generic type parameter T – that will be our metadata object class.

Next –> we need to somehow take a control over the metadata object that as given away to the caller of the extension method defined earlier.

For this reason one of the most easiest way to accomplish this is to use some sort of interceptor infrastructure. What interceptor does? Idea behind the interceptor is that client who got back the metadata object thinks (an result object really looks alike) that object that was given back is of defined metadata object type. And so do all code analysis tools (therefore Intellisense is available) and compiler as well.

Actually using interceptors we are giving back fake metadata object that has lot of injections in it in order to for us to gain control over the further client’s interaction with the object.

One of my favorite library to accomplish this is ‘Castle project’. Pretty easy to use and straightforward.

So what we need is to create a fake metadata object with our injections to control what’s going after we return the object. In order to get this done we need to define our interceptor and return a class proxy created using this interceptor.

So the code for AsAttributeExtendable() method is like this:

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()           
{           
    if (entity == null)           
    {           
        throw new ArgumentNullException("entity");           
    }           
          
    var interceptor = new DefaultInterceptor<T>(entity);           
    var gen = new ProxyGenerator();           
    var options = new ProxyGenerationOptions(new ProxyGenerationHook());           
          
    var proxy = gen.CreateClassProxy<T>(options, interceptor);           
    return proxy;           
}

UPDATE:

NB! Lessons learned! Actually it’s not quite a good idea to create proxy generator, generation hook and class proxy on each request. Just got through support ticket on memory leak and huge memory consumption. Which ended-up with lot of dynamically generated assemblies loaded into application domain and lot other stuff.

A better solution is reuse ‘ProxyGenerator’ class instance and cache generated class proxies for particular types.

First of all need to define static instance of the proxy generator class and store where cached class proxy instances will be stored.

private static readonly ProxyGenerator gen = new ProxyGenerator();         
private static readonly ProxyGenerationOptions options = new ProxyGenerationOptions(new ProxyGenerationHook());         
private static readonly ConditionalWeakTable<IAttributeExtendableEntity, object> table =         
    new ConditionalWeakTable<IAttributeExtendableEntity, object>();

Then we can implement updated method to generate class proxy for particular class of particular type:

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()        
{        
    if (entity == null)        
    {        
        throw new ArgumentNullException("entity");        
    }        
        
    object classProxyCached;        
        
    // try to find already created class proxy from the cache        
    // this is required to increase speed a bit and not to create new class proxy for the same class more than once        
    table.TryGetValue(entity, out classProxyCached);        
        
    if (classProxyCached == null)        
    {        
        classProxyCached = GenerateClassProxy<T>(entity);        
        table.Add(entity, classProxyCached);        
    }        
        
    return classProxyCached as T;        
}

And proxy generation method remains almost unchanged:

private static T GenerateClassProxy<T>(IAttributeExtendableEntity entity) where T : class, new()         
{         
    var interceptor = new DefaultInterceptor<T>(entity);         
    var options = new ProxyGenerationOptions(new ProxyGenerationHook());         
    var proxy = gen.CreateClassProxy<T>(options, interceptor);         
        
    return proxy;         
}

Let’s spilt them up into smaller pieces:

DefaultInterceptor – this is the class that will contain the logic that will be called if client code will try to access something that we marked as interceptable in class ProxyGenerationHook class.
ProxyGenerationHook – class that describes what is going to be intercepted and what should be passed to the underlying intercepted object.

Let’s look at hook class (it should implement ‘IProxyGenerationHook’ interface):

public class ProxyGenerationHook : IProxyGenerationHook         
{         
    public void MethodsInspected()         
    {         
    }         
        
    public void NonProxyableMemberNotification(Type type, MemberInfo memberInfo)         
    {         
        throw new InvalidOperationException(string.Format("Property named '{0}' for type '{1}' is not marked as virtual.",         
                                                          memberInfo.GetProperty().Name,         
                                                          type));         
    }         
        
    public bool ShouldInterceptMethod(Type type, MethodInfo methodInfo)         
    {         
        // we are interested only in properties for now         
        return methodInfo.Name.StartsWith("get_", StringComparison.Ordinal)         
               || methodInfo.Name.StartsWith("set_", StringComparison.Ordinal);         
    }         
}

This hook is instructing Castle dynamic proxy generation engine that interceptor will intercept *only* properties (setters and getters). Btw, properties are compiled into methods anyway. This particular hook logic of course can be modified and adjusted to meet precise requirements.

Otherwise (method NonProxyableMemberNotification()) will be called if some of the metadata object members could not be intercepted. This is particular useful for error checking. NB! What Castle actually does is that behind the scene another object is created that *inherits* from our defined metadata object. Therefore members (in this case only properties) must be marked as virtual – because Castle tries to override those with its own logic. If that fails - NonProxyableMemberNotification() method is called.

Let’s look into DefaultInterceptor code (it must implement ‘IInterceptor’ interface):

public class DefaultInterceptor<T> : IInterceptor         
{         
    public void Intercept(IInvocation invocation)         
    {

It only has single method – Intercept(). The most interesting part of interception is parameter – invocation, that gives us lot of info about method client code is calling.

Usually code within Intercept method starts with checking what kind of method client is calling, like:

if (invocation.Method.Name.StartsWith("get_", StringComparison.InvariantCultureIgnoreCase))         
{

if (invocation.Method.Name.StartsWith("set_", StringComparison.InvariantCultureIgnoreCase))         
{

Just to check either user is getting value from the property or setting value for the property.

Actual interception code really depends on situation and requirements but usually some of the properties of IInvocation class are used:

invocation.Method – is the method that is going to be called.
invocation.Arguments – is list of arguments passed the call of the method.
invocation.ReturnValue – set the result of the interception.

Trick for interceptors – if you want to interrupt interception and return immediately to the caller – just return from the method. Otherwise you’ll need to call invocation.Proceed() method that will call next interception or ultimately will call target object’s method.

And within the interception code you can convert called method (getter or setter for properties) into call to stringly-typed object (Substring(4) will remove ‘get_’ or ‘set_’ from the name of the called method):

Entity.SetAttributeValue(invocation.Method.Name.Substring(4), invocation.Arguments[0]);

or for retrieving something and return that value to the caller’s code:

var methodInfo = Entity.GetType().GetMethod("GetAttributeValue");         
var genericMethod = methodInfo.MakeGenericMethod(invocation.Method.ReturnType);         
invocation.ReturnValue = genericMethod.Invoke(Entity, new object[] { invocation.Method.Name.Substring(4) });

Sequence diagram of final call stack could look something like this:

Sample project where Castle interceptors are used to provide strongly-typed access over EPiServer Relate+ entities can be found there.

Hope this helps!

Kad darbs mijas ar hobiju..

2012-06-01T22:47:20Z

Ikdienas gaitas šobrīd aizņem vairāk vai mazāk ļoti interesanta platforma ar nosaukumu EPiServer, kas ir balstīta pārsvarā uz Microsoft produktiem. Par cik rakstus publicēju dotnet.lv mājas lapā un negribas uzturēt vairākus emuāru kontus, tad iespējams, ka ir pa laikam varētu parādīties, kāds ziņojums ar tagu ‘EPiServer’.

Mēģināšu šīs sērijas rakstos likt informāciju, kas varētu būt ari saistoša cilvēkiem, kas tieši vai netieši nav saistīti ar šo sistēmu. Rakstus plānots veidot, atklājot kādas interesantas nianses sistēmā, daloties ar personisko pieredzi un filozofiju.

Sistēma ir pietiekami liela un sarežģīta, lai tajā nebūtu interesanti atklājumi gan no iedoloģiskā viedokļa, gan no praktiskā. Daudz laika sanāk pārlūkojot dekompilētu kodu un ir pērles, ko var atrast arī nopietnā produktā.

Cerams, ka netraucēs nevienam! :)

Team build un Windows SDK kļūda

2012-05-23T12:54:39Z

Ja kādreiz sanāk ieraudzīt šādu kļūdu savā build log failā (parasti tas mēdz gadīties, kad notiek build serveru migrācijas), tad ir zināmas zāles pret šo.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2249, 9): error MSB3086: Task could not find "sgen.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed

Tas ko izdarīju es, lai atbrīvotos no šīs kļūdas (kaut gan Windows SDK bija instalēts jaunajā build serverī), bija:

Eksportēt ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A’ reģistru uzstādījumus.
Importēt tos jaunajā build serverī. Drošības pēc es importēju arī visu to pašu zem ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node’ atslēgas. Lai to izdarītu nākas nodublēt visus uzstādījumus un samainīt reģistra atslēgas ceļus .reg failā. It kā ir izdarāmas arī ar ‘regedit32.exe’, bet risinājums nebija pa rokai.
Pārkopēt ‘C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A’ (parasti ceļš ir šāds, ja build serveris ir x64) direktoriju no vecā build servera uz jauno.

Augstāk minētā kļūda pazuda pēc šīm darbībām.

Cerams, ka noderēs!

Debugging locally, testing in the cloud..

2012-05-15T21:01:12Z

Dažreiz sanāk kaut ko pameistarot Windows Phone 7 platformai (piemēram, http://bit.ly/atmfinder) un nesen saskāros ar interesantu problēmu. Izmantot spraudni SlowCheetah (lejupielādēt var šeit), tīmekļa projektos var ērti veikt Xml failu transformācijas, ja tādas ir nepieciešamas. Transformācija var būt katrai projekta konfigurācijai sava – piemēram, lokālā izstrādes vide izmanto vienus uzstādījumus, bet savukārt kopējā testēšanas un skaņošanas instalācijai nepieciešami pavisam citi uzstādījumu. Šo uzstādījumu regulācija un kontrole notiek izmantojot risinājuma uzstādījumus (Configuration Settings).

Izmantojot šo lielisko iespēja, nodomāju, ka varētu ieviest vairākas konfigurācijas arī manai aplikācijai: piemēram, ar vienas konfigurācijas palīdzību (pārsvarā tiek izmantots emulatorā) es varētu testēt un skaņot sistēmu, izmantojot lokālos tīmekļa pakalpojumus (WCF servisa adrese būtu http://localhost/..), savukārt ar citu uzstādījumu palīdzību, varētu regulēt konfigurāciju, ka tīmekļa pakalpojumu atrodas kaut kur – ārā (WCF servisa adrese sāktos ar http://<kaut kāds mistisks id, kas laikam domāts Azure instances identificēšanai>/..).

Šim nolūkam WCF klienta bibliotēka jau savu konfigurācijas fragmentus saglabā ServiceReferences.ClientConfig failā, kas ir parasts Xml fails. Šāda veida Xml faili ir ļoti labs kandidāts Xml transformācijai dažādās konfigurācijās dažādām vajadzībām.

Konfigurācijas faili izskatās šādi:

Oriģinālais fails:

     <configuration> 
  <system.serviceModel> 
    <bindings> 
      <customBinding> 
        <binding name="CustomBinding_IAtmFinderService"> 
          <binaryMessageEncoding/> 
          <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" /> 
        </binding> 
      </customBinding> 
    </bindings> 
    <client> 
      <endpoint address="http://localhost:81/AtmFinderService.svc" 
          binding="customBinding" bindingConfiguration="CustomBinding_IAtmFinderService" 
          contract="CloudServiceReference.IAtmFinderService" name="CustomBinding_IAtmFinderService" /> 
    </client> 
  </system.serviceModel> 
</configuration> 
   

Viens no transformācijas failiem, kas uzstāda servisa adresi uz to mākoņa pakalpojumu:

     <configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
  <system.serviceModel> 
    <client> 
      <endpoint address=http://azure-instances-id.cloudapp.net/AtmFinderService.svc name="CustomBinding_IAtmFinderService" 
                xdt:Transform="SetAttributes(address)" xdt:Locator="Match(name)"/> 
    </client> 
  </system.serviceModel> 
</configuration> 
   

Sākotnēji likās iespēja tiešām lieliska un eleganta, bet pēc neilgiem eksperimentiem atklājās, ka SlowCheetah tiek izpildīts sekmīgi, bet XAP failā aiziet oriģinālais Xml / .config fails no source direktorijas (direktorijas, kurā atrodas projekta sakne), savukārt spraudnis transformē oriģinālo failu no source direktorijas pārveidojot to kopē vietā, kur tiek novietoti arī pārējie projekta izejas artefakti.

Šis fakts traucē Xap failā iekļauj pareizo jau *transformēto* failu.

Izstaigājot Silverlight MSBuild konfigurācijas definīcijas failus, sapratu, ka labāk nemēģināt pārtaisīt, bet gan pielāgoties Xap faila pakošanas procesam.

Beigu beigās sanāca .targets fails, kas domāts tieši priekš šādam situācijām, kad nepieciešams WCF klienta konfigurācijas failus transformēt un rezultātu iekļaut Xap failā.

     <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
  <Target Name="BeforeBuild"> 
    <CallTarget Targets="TransformAllFiles" /> 
    <Exec Command="attrib -r ServiceReferences.ClientConfig" WorkingDirectory="$(MSBuildProjectDirectory)" /> 
    <Exec Command="xcopy &quot;$(OutDir)ServiceReferences.ClientConfig&quot; ServiceReferences.ClientConfig /y" WorkingDirectory="$(MSBuildProjectDirectory)" /> 
  </Target> 
</Project> 
   

Šo .targets failu var iekļaut savā projektā:

     <Import Project="ServiceReferences.Transform.targets" /> 
   

Ja slinkums pārrakstīt faila saturu, tad fails pilnā saturā pieejams šeit.

Šim paņēmienam ir gan viena neliela problēmiņa, kuru man nav izdevies vēl atrisināt –> pēc sekmīga būvējuma, oriģinālais fails satur transformētā faila saturu. Jāatdzīst, ka man neizdevās sameklēt notikumu, kas tiktu izsaukts pašās build procesa beigās (AfterEndToEndIteration notikums nestrādā). Savukārt, ja transformācijas ir rakstītas pareizi, tad šai niansei nevajadzētu sagādāt nekādas problēmas.

Cerams, ka noderēs!

TPL (Task Parallel Library) prezentācijas source code.

2012-05-07T19:54:36Z

Pēc Latvijas Universitātes auditorijas lūgumu izvietoju prezentācijas demo source code. Pieejams šeit.

Ja rodas kādi jautājumi, iebildumi vai filozofiskas pārdomas – noteikti gaidu jūsu feedback: valdis punkts iljuconoks at dotnet punkts lv.

Happy parallelisming!

Schedule

2012-04-18T21:09:00Z

Kā izrādās, tad aprīļa pašas beigas un maija mēnesis izvērties par diezgan aizņemtu laika posmu. Katrā ziņā, var noķert mani kaut kur tur

Aprīlis 2012:

2012.04.26: Transporta un Sakaru Institūts:

18:15 – 19:15 “MSF & Agile”

19:15 – 19:45 “TFS 2012 Overview (Dev ‘11)”.

Maijs 2012:

2012.05.07: Latvijas Universitāte:

18:15 – 19:15 “Parallel Computing in Visual Studio 2010”

2012.05.08: Vidzemes Augstskola:

10:00 – 10:55 “Asp.Net MVC”

11:00 – 11:55 “Funkcionālā programmēšana - F#”

12:00 – 12:55 “Visual Studio 2012 - What's new?”

13:00 – 13:55 “Requirements Management in TFS”

2012.05.14: Latvijas Universitāte:

18:15 – 19:15 “Funkcionālā programmēšana - F#“

2012.05.17: Ventspils Augstskola:

11:00 – 11:45 “Designing Software Architecture in VS 2010”

12:45 – 13:30 “C# 3.0 & C# 4.0”

13:40 – 14:25 “MSF & Agile”

14:35 – 15:20 “Requirements Management in TFS”

2012.05.21: Latvijas Universitāte:

18:15 – 19:15 “C# 5.0 – async”

2012.05.28: Latvijas Universitāte:

18:15 – 19:15 “Ievads jQuery“

Cerams, ka noderēs!

`Fakes’ iekš VS Dev ‘11

2012-04-06T19:45:35Z

Interesanta lieta, kas varbūt nav tik bieži un daudz apskatīta lasot par jaunās versijas iespējām un jaunajām “fīčām” – Fakes Framework.

Šī platforma paredzēta tieši vienumu testu efektīvākai un vieglākai rakstīšanai.

Dažkārt vienumu testu veidošanas laikā ir nepieciešams simulēt kādas izmantotas komponentes uzvedību vai funkcionalitāti. Ja programma, kuru vēlas notestēt un pārējās komponentes ir veidotas ar ņemot vērā vienumu testu īpatnības (piemēram, komponentes paļaujas un izmanto funkcionalitāti, kas slēpjas aiz klašu interfeisiem, kurus “saņem” no ārpuses), tad lielas grūtības pareizu vienumu testu uzrakstīt parasti nesagādā problēmas.

Problēmas parasti rodas situācijās, kad nepieciešams simulēt uzvedību kādai no komponentēm, kurai nav pieejams izejas kods, kurai nav iespējams pārrakstīt uzvedību (virtuālās metodes) vai arī kuras paļaujas uz kādu konkrētu iekodētu implementāciju, kuru izmainīt parasti sagādā problēmas.

Pieņemsim, ir neliela metode, kas pārbauda entity “derīguma termiņu” un nosaka, vai šo entity var dzēst no sistēmas. Pieņemsim, ka entity no sistēma var tikai tad, kad tā tur pabijusi vairāk par 5 dienām, t.i., entity pievienošanas datums ir par 5 dienām mazāks nekā {sistēmas pašreizējais} datums. Un šajā vietā sākas interesantākais. {Pašreizējais datums} ir lieta, kuru parasti implementē ar DateTime.Now.

Viss ir kārtībā un sistēma visticamāk arī uzvedīsies pareizi run-time laikā, bet jautājums: kā, lai pārbauda šāda veida kodu no vienumu testiem. Un vienumu testi noteikti gribēs pārbaudīt abus loģiskos zarus – kad entity pievienošanas laiks ir mazāks un kad ir lielāks par definētajām 5 dienām, tādā veidā tiešām pārliecinoties, ka abi loģikas zari nostrādā pareizi.

public bool CanEntityRemove(Entity entity)
 {
     if (entity == null)
     {
         throw new ArgumentNullException("entity");
     }
 
     var delta = entity.Added.Subtract(DateTime.Now);
     return delta.Days > 5;
 }

Viens no variantiem, būtu definēt pašiem savu datuma piegādātāja klasi, kas varētu atgriezt virtuālo laiku, ar kuru varētu veikt nepieciešamās manipulācijas pirms atgriešanas. Bet jautājums, ko darīt, ja vēlamies pārbaudīt *tieši* šādu kodu? Talkā nāk Fakes Framework, kas pieejams Visual Studio Dev ’11 versijā.

Lai aizvietotu DateTime.Now īpašības vērtības, nepieciešams vispirms vienumu testa projektam uz nepieciešamo references bibliotēku, kur definēta klase DateTime, izpildīt komandu “Add Fakes Assembly”.

Šī komanda ģenerēs jaunu bibliotēku {OriginalName} + “.Fakes”. Par cik DateTime ir definēts mscorlib bibliotēkā, bet pēc noklusējuma tā nav redzama references sarakstā, tad pēc Fakes bibliotēkas ģenerācijas, pieejama ir mscorlib.4.0.0.0.Fakes bibliotēka, kas satur stubs vai shims objektu veidus.

Microsoft Visual Studio Dev ‘11 pašlaik izmanto divu klašu “izbāžņu” veidus:

Stub: ir veids, kurā ģenerētā klase pilnībā ir spējīga aizvietot mērķa klasi, piedāvājot noklusēto uzvedību un funkcionalitāti visām virtuālajām vai abstraktajām metodēm, īpašībām un notikumiem. Šīs klašu “izkārtnes” iespējams ģenerēt arī interfeisiem un nemarķētām (non-sealed) klasēm. Savukārt pārējiem gadījumiem: statiskām vai ne-virtuālām metodēm jāģenerē būs Shim veida aizbāžņi.
Shim: ar šī veida palīdzību ir iespējams simulēt uzvedību statiskām vai ne-virutālām metodēm. Šī veida “izbāžņi” pārķers visus orģinālos izsaukumus un pāradresēs to alternatīvajai implementācijai.

Abu šo veidu klašu “izbāžņi” ļauj izmantot delegates, lai implementētu vai pārrakstītu nepieciešamo funkcionalitāti.

Direktorija “Fakes/” satur sarakstu un papildus informāciju par bibliotēkām, kurām ir jāģenerē klašu “izbāžņi”.

Ja gribam simulēt DateTime.Now īpašības vērtību, tad nozīmē, ka jāizmanto būs Shim veida ģenerācija, jo īpašība ir statiska.

Lai darbotos Shim veida ģenerētās klases, vispirms nepieciešams ieslēgt Shim kontekstu vienuma testa izpildes laikā. Shim konteksts paļaujas uz speciāli veidotu TraceProfilerInstrumentationProvider, kas arī nodarbojas ar izsaukumu pārķeršanu.

Tātad, ja vēlamies izmantot Shim veida klašu ģenerāciju, tad no sākuma jāieslēdz:

[TestMethod]
 public void CanEntityAddedOnJanuaryRemoved_Test()
 {
     using (ShimsContext.Create())
     {

Ja aizmirsīsim kontekstu ievietot using blokā, tad simulācija būs spēkā visa AppDomain dzīves laikā. Tāpēc svarīgi ir atcerēties kontrolēt Shim konteksta scope. Pēc tam, kad Shim konteksts ir uzstādīts, ir nepieciešams nodot instrukcijas klasei, kura jāsimulē.

Tas notiek ar lambda izteiksmes palīdzību:

using (ShimsContext.Create())
 {
     ShimDateTime.NowGet = () => new DateTime(2012, 1, 1);

Šajā gadījumā tiek simulēts DateTime.Now īpašības uzvedība un atgrieztā vērtība.

Izpildot vienuma testu redzams, ka Shim konteksts strādā un patiešām DateTime.Now property atgriež nepieciešamo vērtību.

Ja nepieciešams, piemēram, aizvietot vispār EntityValidator loģiku un testēt pavisam kādu citu sistēmas apgabalu pieņemot , ka vienumu testā šai klasei vienmēr ir jāatgriež true vērtība?

Tas nozīmē, ka iespējami ir 2 scenāriji:

Izmantojam Shims ģenerācijas veidu un pielietojam jau apskatīto tehnoloģiju, kā modificēt vērtības klasēm, kurām nespējam piekļūt vienkāršā veidā.
Pārdefinējam metodi CanEntityRemove() par virtuālu un izmantojam Stub klašu “izbāzeņu” ģenerācijas veidu, lai simulētu, ka dzēst no sistēmas var entity ar jebkādu datumu.

Lai šāda veida uzvedību nosimulētu, nepieciešams atkal Stub ģenerētajai klasei noinstruēt, ka vienmēr neskatoties uz kādu entity pievienošanas datumu, jāatgriež vienmēr true.

[TestMethod]
 public void CanEntityRemove_StubTest()
 {
     var stub = new StubEntityValidator();
     stub.CanEntityRemoveEntity = (entity => true);
 
     var result = stub.CanEntityRemove(new Entity {Added = new DateTime(2012, 12, 12)});
 
     Assert.IsTrue(result);
 }

Šāda veida Stub ģenerētu uz noinstruēt klases instance var padot tālāk jau citām komponentēm, kurām nepieciešama šis objekts.

Cerams, ka noderēs!

Marta knockout.js prezentācijas materiāli

2012-03-09T00:22:00Z

Marta prezentācijas materāli Microsoft .Net user group pasākumā par knockout.js bibliotēku, kas dod lielisku iespēju vienkārši un deklaratīvi veidot interakctīvas aplikācijas. Ar šīs bibliotēkas palīdzību iespējams ērti un viegli veidot sarežģītas aplikācijas, kurām nepieciešamas sarežģītas klieta puses DOM manipulācijas.

Knockoutjs UG meeting presentation

View more PowerPoint from Valdis Iljuconoks

Pielikumā prezentācijas ppt - šeit.

Kā arī izejas kods, ja nu kādam tiešām ieinteresēja, iespējams papētīt - šeit.

Cerams, ka noderēs!

Izejas koda review process made easy VS 11

2011-10-25T20:53:51Z

Nesen Microsoft laida klajā Visual Studio 11 Developer Preview, kas paredzēts dažādiem agrīnās programmas interesentiem, kuri neskatoties uz pieļaujamajām kļūdām un runtime exception studijas darbošanās laikā, tāpat instalē, pēta un skatās, ko Microsoft ir šoreiz saražojis un ko jaunu piedāvā.

Āri Team Foundation Server nav palicis maliņā un arī šai brīnišķīgajai programmatūrai ir pieejama 11 versija, kas paredzēta, lai mēs varētu ieskatīties, kas mūs sagaida pēc kāda laiciņa.

Šoreiz aplūkosim, kas notiek ar code-review procesu, kas līdz šim īpaši atbalstīts pašā studijā netika. Pie izejas koda checkin procesa bija viens vienīgs text box lauciņš, kurā var ierakstīt kaut ko par code-review procesu, kas notika pirms šī konkrētā check-in. Ir pieejami arī visādi rīki un trešās puses spraudņi, kas šo procesu mēģināja iedzīvināt studijā, bet līdz šim tas nav bijis 1st class citizen VS programmā.

Ar Dev 11 versiju viss izskatās, ka nedaudz ir pamainījies un code review process nu ir kļuvis daudz ērtāks un pārskatāmāks un tuvāks izstrādātājiem, jo integrējas tieši TFS serverī.

Btw, TFS serveris ir palaists arī mākonī (Windows Azure) un atrodams tfspreview.com.

Tātad viss code review process, protams, sākas ar check-in procesu. Pagaidām neatradu check-in politiku, kas aizliegtu izejas koda ievietošanu iekš repozitorija, nepaprasot kādam source code review akceptu, bet domājams, ka šāda veida politikas sāks ražot, kad platforma būs tuvāk kādam publiskākam un daudz stabilākam jūdžakmenim.

Pirmāmkārtām, ir jau mainījies viss darbs ar TFS source code repozitoriju. Sadarbība ar TFS notiek pārsvarā caur Team Explorer logu.

Izejas koda repozitorijā ievietošanas laikā ir iespējams uzsākt izejas koda pārlūkošanas procesu.

Šī komanda savukārt atver jauna code review pieprasījuma formu, kurā iespējams diezgan ērtā veidā pievienot izejas koda pārlūkotājus no projekta komandas biedriem.

Šajā forma ir iespējams uzrādīt nosaukumu code review pieprasījumam, kā arī pievienot kādus papildus komentārus, kas palīdzētu ātrāk reviewer’im saprast, kas un kā ir jāpārlūko un kā efektīvāk un ātrāk dot savu akceptu, lai neizveidotos kaut kādi pudeļu kakliņi vai citi aizcietējumi.

Pagaidām gan īsti neatradu veidu, kādā varētu ērti parakstīties uz notikumiem TFS serverī, kas dotu iespēju momentā, kad kāds ir pieprasījis veikt code review no manas, es par to uzzinātu savā e-pasta kastītē vai kādā citā sociālo tīklu notifikācijas veidā.

Atradu gan vienu notikumu, ka varētu strādāt šajā gadījumā, neesmu vēl līdz galam izmēģinājis vai tas strādā ar TFS Services Preview, kurā īsti SMTP serveri nav iespējams konfigurēt. TFS notikums ir:

Lai nu kā, bet otrs lietotājs, no kā tiek pieprasīts veikt code review, savā darāmo darbu sarakstā ierauga sekojošu ainu:

Šajā logā pārskatāmā veidā redzams, ka kāds ir pieprasījis veikt code review kādai komponentei. Atverot konkrēto code review pieprasījumu, iespējams ieraudzīt detalizētāku informāciju par to, kas ir pieprasīts pārskatīt, kurš to izdarīja, kāds ir status un vai ir vēl kāds, kam tika nosūtīts šāds pats code review pieprasījumus (un ja ir bijis nosūtīts, tad iespējams arī ērtā veidā uzreiz redzēt citu pārskatītāju sniegtos verdiktus, ja nu pašam raustās vienpersoniski pieņemt lēmumu).

Un starp citu, pārsteigums man bija, kad divreiz nospiedu uz “Program.cs”. Es gaidīju, kad atvērsies automaģiski WinMerge vai kāda cita jauka rīka logs, kurā varētu redzēt faila veiktās izmaiņas. Bet šoreiz izmaiņu fails tika atvērts tieši Visual Studio 11 logā.

Šāda veida funkcionalitāte manuprāt ir liels solis uz priekšu Visual Studio feature sarakstā. Izmaiņas var aplūkot dažādos režīmos: pārklājošais, viens otram blakus, rādīt tikai labo pusi vai arī rādīt tikai kreiso pusi.

Vēlāk kad visas izmaiņas ir aplūkotas, pārbaudīts un akceptētas, ir iespējams noslēgt code review procesu. Šim nolūkam kaut kādā veidā ir jāģenerē code review request response TFS work items, kas sniegtu informāciju par izejas koda pārlūkošanas procesa gala rezultātu. Šo darbību ir iespējams izdarīt no paša Team Explorer.

Pozitīvi ir tas, ka katrai darbībai ir iespējams pievienot kādu komentāru. Ir iespējams pierakstīt savus komentārus par izejas koda pārlūkošanas pieprasījumu kopumā, kā arī ir iespējams atstāt komentāru par katru atsevišķo failu arī.

Pozitīvi ir tas, ka viss paliek TFS arhīva datubāzē. Šajā gadījumā code reviewer ir iespējams atbildēt uz pieprasījumu ar kādu no iespējamajām atbildēt:

Looks Good – Viss ir forši, turpini darbu.
With Commens – Man ir pāris jautājumi.
Needs Work – Es, protams, saprotu, ka es gudrs un smalks programmētājs, bet nu tādus mēs*** no Tevis nebiju gaidījis.

Pēc tam, kad code reviewer ir beidzis savu darbu - atzīmējis savas domas par veiktajām koda izmaiņām – kontrole tālāk nonāk pieprasītāja rokās, kur viņš var izlemt, ko iesākt tālāk ar šo code review pieprasījumu.

Ja izvēlas “Complete”, tad code review process ir noslēdzies un sākotnējais autors izmainītos izejas failus var ievietot repozitorijā. Pie izejas koda ievietošanas procesa tiek arī pierakstīts, kādā code review kontekstā šis konkrētais labojums via papildinājumus ir nonācis izejas koda repozitorijā. Šo ierakstu(-s) var aplūkot, kad skatāmies uz changeset izmaiņām.

Starpcitu, noskaidroju, ka code review procesu var iedarbināt arī pēc tam, kad izejas kods ir ievietots repozitorijā. Piemēram, šajā gadījumā sūtām source code review pieprasījumu par veselu changeset’u.

Visi šie code review pieprasījumi galu galā TFS serverī parādās kā parasti WI (Work Item), kas nozīmē, ka šiem WI ir papildus meta datu informācija, kas satur vitālu informāciju par šo labojumu. Piemēram, TFS serverī ir iespējams sameklēt un atvērt šo code review pieprasījumu kā jebkuru citu WI.

Kā arī ir iespējams šo code review pieprasījumu atvērt ar Team Explorer (nospiežot saiti kreisajā augšējā stūrī – “Open Code Review in Team Explorer”), kas dod sākotnējo code review skatu, kurā var aplūkot visus iekļautos failus un komentārus, ja tādi bijuši.

Izskatās, ka Microsoft cilvēki nopietni sāk domāt par koda kvalitāti un ievieš tik vitāli svarīgu procesu kā code review jau kā pirmās klases Visual Studio ģimenes locekli. Dzīvosim un redzēsim kā tas viss attīstīsies tālāk!

Cerams, ka noderēs!