Microsoft Platform Ready Delivers Partner Success

November 2nd, 2011 by Adi S.

We have been a member of the Microsoft Platform Ready (used to be called “Front Runner”) for over a year now and it is a fantastic program for all of the Microsoft partners out there. Some of the benefits are obvious, such as development resources and marketing materials available for the tested solution. Here are few more we discovered by using the program: 

-          It helps deliver the success message to the customers and prospects alike quickly and ahead of the official testing by VeriTest.

-          We actually received substantial savings on our Certified for Microsoft Dynamics CRM test for eSign365 based on the fact that our product was already platform ready for Microsoft Dynamics CRM 2011.

-          Achieving platform ready qualifies partners for the Silver ISV competency if product is platform ready for the Windows Azure platform.

-          Last but not least MPN has been giving us hints of the upcoming Gold Windows Azure Platform Ready certification for our products running in the cloud. I wonder if that test will also be administered using the Microsoft Platform Ready program?

It seems that the Platform Ready program is here to stay. It has been constantly growing and adding benefits during our participation and we are excited to see what it has to offer in the future.

Scrum for Distributed Teams

April 29th, 2010 by Adi S.

Distributed teams give companies access to talent that they may otherwise not have access to locally.  Projects can be completed in a faster manner if people in different time zones are continuously working on a particular project.  Lastly, but certainly not least, companies can obtain significant cost savings if they work within a distributed team environment.

One of the biggest challenges to overcome when implementing Scrum within a distributed team is that of communication.  Within a formal Scrum environment, everyday person-to-person conversation is a valued part of the process. Consequently, it is important to have that face-to-face time during vital points in the project - such as the planning and design phase of the project. For that reason CompuSight attempts to bring its distributed teams together during those crucial planning phases in order to achieve the design consensus and gain that initial momentum based on a common project understanding. Even during the implementation phases CompuSight Scrum masters are quite open to briefly unite the teams if they notice any “wear” on the team velocity due to the lack of the common requirement and design understanding.

Script# - Part I

April 29th, 2010 by Can B.
Introduction to OO Javascript

JavaScript development can become quite complicated if/when you are dealing with more than just onclick or on mouseover events. If you are working on a client-side-heavy web application with full of dynamic html elements, AJAX calls, validation etc. it is already time to think about OO javascript implementations.

There are various types of javascript OO implementation, the most popular and accepted of which is the employment of the prototype property. By this most of the OO logical properties can be emulated/applied.

MyNamespace.MyClass = function()
{
    // Implement the member variables
}

MyNamespace.MyClass.prototype.MyPublicFunction = function(value)
{ this.MyMemberVariable =  value; }

MyNamespace.MyClass.MyPublicStaticFunction = function()
{...}

However,  the implementation of this type of logic is hard to keep track of, you cannot have a complete overview of your classes, properties and functions which causes your code to become redundant and gets loaded with typos.

Introduction to Script#

In my quest for the most suitable javascript editor which can keep track of the class structures, entities, method implementations, something really interesting came up: Script#. It was described as:

“Script# empowers you with a development methodology and approach that brings software engineering, long term maintainability and scalable development approaches for your Ajax applications, components and frameworks.”

which attracted my attention immediately. As I was reading through the whole story my interest grew. It was a free tool that has “full” integration to Visual Studio which lets the user write C# code, using the accompanying mock libraries for either the DOM or ASP AJAX. The libraries or so-called scriptlets are compiled into javascript on the compile-time and attach to the related web project. The developer then have full access to the Visual Studios features (except for unit-testing) that increases the maintainability of the projects and efficiency. 

Also, from the architectural point, the code can have namespaces, types, structures, encapsulation, inheritance, interfaces basically most of the items on the must-have list of an OO language.

On top of the common javascript development, there are other  mock libraries that are included to ease ASP AJAX development and also a library if you are working with Silverlight.

Well, script# was the missing piece in full-scale, content-rich asp application development with VS where you actually do not need some other 3rd party tool just to be able to edit the javascript code. (Note: Visual Studio does have intellisense and javascript editor but neither of them is powerful or reliable enough) .

There are of course down sides of the story. With Script# projects, you basically include the sscorlib.dll instead of the mscorlib.dll. This mock library is really elegantly set up to give the developer most of the capabilities in DOM and javascript, however not all .NET classes are implemented (note: the js compiler is pretty powerful but it is still missing the support for generics and implicit variable declarations and so on which ironically are the basics of JavaScript, thinking about it.) The unit tests which I was actually hoping to be able to use (naively enough), are not yet supported but the author promises them to be included soon. (note: script# is still not yet open source, as I understood, there are plans for this).

Rumor has it Microsoft had actually employed this “tool”/framework (however you call it) in some of their projects like Live Messenger, Office Word (?), MSDN Gadgets. In fact, the package has included a library for Live Messenger API and also project template for MSDN Gadgets.

Conclusion

Well, overall, it looks really promising. The library has been just updated a month or two back so let’s cross our fingers for an open source version. Meanwhile, I will be writing couple of more tutorial-like posts on Script#.

Hybrid Pricing Models for IT Outsourcing

April 29th, 2010 by Adi S.

All the rage in the world of outsourcing as of recent has been the pricing models that strike the right balance between the incentives and risks for both the provider and the client. Fixed price projects often carry a risk for the provider due to the vague or assumed requirements. On the other hand the time-and-materials pricing model is often seen as a risk by the customer due to the lack of visibility into the projected cost and undefined timelines.

 

Recently a hybrid model that combines the two has become popular where the initial, well defined requirements are implemented based on the fixed cost. The requirements unknown at the start or that come up during the initial phases are implemented subsequently based on the time-and-materials pricing model. This hybrid model allows for the both sides to hedge their risk.

 

Interestingly enough CompuSight has been using a similar model for several years. It is actually quite common in the “build and enhance” scenarios. Furthermore, CompuSight is often recruited in a reverse hybrid model of the one described. Our consultants help establish the architectural approach and perform feasibility studies as the initial phases of the project based on the time-and-materials model. Once the anticipated technological and integration challenges are solved and the proof of concept exists we are able to perform the implementation work based on the fixed cost basis. This approach has proven quite successful and well received by our clients.

WCF PerCall Service Implementation

September 22nd, 2009 by Can B.

InstanceContextMode

InstanceContextMode enumeration can take 3 different values each of which defines a different instance management scenario. PerSession services are created when the client proxy is opened and the service instance is destroyed when the client proxy closes the connection. Singleton services are created when the host is created and lives until the host shuts down. Last but not least, PerCall service implementation which I will try to talk about.

[ServiceContract]
interface IExampleContract
{
    // Operation and DataContracts
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class ExampleService : IMyContract
{
    // Service Implementation
}


PerCall Service

PerCall service instances are created and destroyed with every method call on the server side. This fact in any ways does not depend on usage of different proxy instances or different endpoints on the client side.

Different Usages of PerCall Services

Figure 1 – Different Usages of PerCall Service

One important fact about the per call services is that, the connection between the client and the server is not severed even if the service (i.e. server side object) instance is destroyed right after the method call in the first diagram. This implementation really eases the resource usage on the server side since creating and destroying a service instance repeatedly on the service side without tearing down the connection to the client (with its client-side proxy) is a lot cheaper than repeatedly creating an instance and a connection.

This of course makes it crucial to implement the IDisposable interface on the service class. The client can be holding important resources such as a database connection, a certain port or a file handle which can be disposed of on the dispose method. This way the service load can be minimized if the environment requires many different clients connecting and using this service. In other words, it would be ideal to use PerCall services in environments where scalability is an important factor, when you want an adaptive system to growing workloads and resource usage.

PerCall vs. PerSession

The easiest way to distinguish between the two is to think about two conversations; a conversation in a box office when you are buying a ticket, and a conversation with a friend that you meet for coffee. You would not like if the person in front of you starts a “friendly” conversation with the salesman in the box office when the queue is growing. However, thinking the other way, unlike your friend the salesman would not even remember your face if you had to ask him something additional and you would have to start from the top again.

As in the analogy, PerCall services do not hold onto their states and if you need some info to be persisted during the operations, you would have to implement some custom way to persist this data. However, in a situation where the number of clients grows, PerCall services can save valuable resources for you. Following the analogy, you would not want to hold the line, while others are trying to “buy tickets”.

Custom Persistence Store

If you really need/want to use a PerCall service, and you want to hold on to certain data between the method calls, then creating two methods in your service (GetState, SaveState) would do the work. However, you somehow have to know the state of which service instance you are accessing. For this purpose, the client method calls can be made with an additional parameter for identifying the service instance.

[ServiceContract]
interface IExampleContract
{
    // Operation and DataContracts
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class ExampleService : IMyContract
{
    // Service Implementation

    private void GetState(instanceId)
    {
        // Load data from the persistence store
    }

    private void SetState(instanceId)
    {
        // Save the data for persistence
    }
}

The instance id can be either carried explicitly with the method calls or you might try using the HeaderClientBase<T,H> to carry the instance id in the message header and GenericContext<T> to retrieve it on the server side. This approach might even give you the marshaling your service calls and preparing the basis for a synchronization context.

The other way to create a persistence store is to use the DurableService attribute on your service implementation and configure the persistenceProvider in the service behaviors.

Optional and Named Parameters in C# 4.0

September 10th, 2009 by Can B.

C# 4.0 is coming soon and as usual brings some syntactic sugar along to make our programmers lives a little happier. One of the new features is named and optional parameters.

Optional parameters

The optional parameters feature is not new in other languages. VB 4.0 had it already in similar form so you could declare something like:

Public Sub MyMethod (Optional MyParameter as Variant)

EndSub

C++ also had this feature for a while:

void MyMethod(string msg, bool isTrue = true)
{
//...
}

What is the purpose of optional parameters? Optional parameters are useful to replace overloading. Often by overloading methods, we would do several version of a method just to call some other version with passing some default parameter, like for example:

public class MyClass
{
    public static void SomeMethod(string str, bool isTrue)
    {
        // This method does the actual work
    }

    public static void SomeMethod(string str)
    {
        MyMethod(str, <strong>true</strong>);
    }
}

With optional parameters this is not necessary, because we can declare the isTrue parameter as optional and have only one method:

public static void SomeMethod(string str, bool isTrue = true)
{
    // Do the work
}

The syntax for this is to follow the parameter name with “=” and provide the default value (like in C++).

There are of course some limitations. For example, what is going to happen if we say following:

public static void SomeMethod(string str="Default" , bool isTrue )
{
    // Do the work
}

Sorry, this won’t compile, because optional parameters must appear after all required parameters.

The first thing I tried and got disappointed in a way, was the initialization of a custom type. For example:

// This won't compile!!!
public static void MyMethod(string stringParameter = "[Default]",
                                        bool isTrue=true,
                                       CustomClass myType=
                 new CustomClass("Created as optional parameter"))
{
    Console.WriteLine(stringParameter);
    Console.WriteLine(isTrue);
    Console.WriteLine(myType);
}

Nope, this is not gonna compile.

Default parameter value for ‘myType’ must be a compile-time constant.

The default value must be known at compile time.

OK, now the time is for the full truth. It was possible to declare optional parameters in C# prior version 4.0, by putting a [Optional] attribute (System.Runtime.InteropServices) and a [DefaultParameter] attribute, but it was not possible to invoke it in optional manner from a C# application. Here is an example:

public static void MyMethod(
[Optional]
[DefaultParameterValue("[First Default]")]string firstStringParameter,
[Optional]
[DefaultParameterValue("[Second Default]")]string secondStringParameter,
[Optional]
[DefaultParameterValue(true)]bool isTrue)
{
    Console.WriteLine(firstStringParameter);
    Console.WriteLine(secondStringParameter);
    Console.WriteLine(isTrue);
}

or in C# 4.0 fashion

public static void MyMethod(string firstStringParameter = "[First Default]",
string secondStringParameter = "[Second Default]", bool isTrue = true)
{
    Console.WriteLine(firstStringParameter);
    Console.WriteLine(secondStringParameter);
    Console.WriteLine(isTrue);
}

if we dissect the IL code we will notice that the output is the same for both approaches.

.method public hidebysig static void  MyMethod(
[opt] string firstStringParameter,
[opt] string secondStringParameter,
[opt] bool isTrue) cil managed
{
.param [1] = "[First Default]"
.param [2] = "[Second Default]"
.param [3] = bool(true)

//...

} // end of method Program::MyMethod

Named parameters

Named parameters is a feature that allows to call a method and map the value being passed with a certain parameter. As you can imagine this allows you to pass the parameters in any order you like. The syntax is simple, just name the parameter you would like to initialize and suffix it with “:” and then provide a value:

int sum = Sum(parameterOne: 7, parameterTwo: 5);

// public int Sum(int parameterOne, int parameterTwo){ }

or you can turn them around, so they don’t have to match the order in the method signature:

int sum = Sum(parameterTwo: 5, parameterOne: 7);

For example if we take the MyMethod with optional parameters from the previous example, we can demonstrate the named parameters. For example if we call the method in this way:

MyMethod( "Don't take the default one on first parameter");

the output would be:

Don't take the default one on first parameter
[Second Default]
True

As you can see the parameters are optional, and the firstStringParameter will be replaced with an actual value. If we call MyMethod in the following way, we can say “Call MyMethod and pass to secondStringParameter the following string”:

MyMethod(secondStringParameter: "The second one should not be default");

[First Default]
The second one should not be default
True

As you can see, even if we passed only one parameter the second, we pass it to secondStringParameter

This feature comes handy when interacting with COM types that have large signatures, mostly with optional parameters. Beside this it improves the readability of the code.

Localizing SQL Server Reporting Services

April 6th, 2009 by Can B.


Localization is a normal requirement for any project accessed around the world, and although Microsoft has not provided a way to add a ‘resx’ fileinto SSRS in order to localize the report , they have provided a way to use custom assembly and through it import the .resx files. 
After you have created your original report, to localize it you need to do several things. First create a new project – a Class Library with a .dll file and .resx files for the default and any other necessary language(s). Write your code to access the .resx files based on the culture name passed.

The assembly you created then needs to be trusted and deployed in Reporting Services, here are the steps to do it:

1.       Copy your .dll , .pdb files and the language folder (en-GB in my case) to the Report Designer folder. The default path for the Report Designer folder is: C:Program FilesMicrosoft Visual Studio 8Common7IDEPublicAssemblies.

 

2.       Launch the Microsoft .NET Framework 2.0 Configuration program from the Administrative Tools section of your Control Panel.

 

3.       Click Configure Code Access Security Policy - > Increase Assembly Trust - >Make changes for this computer -> Next.

 

4.       Click Browse. Browse to the PublicAssemblies folder and select CallCenterReportUtil.dll Click Open, and then click Next.

 

5.       Select This one assembly and click Next.

 

6.       Change the Trust level slider to Full Trust and click Next -> Finish.

 

7.       Also you need to add the language folder and .dll to the c:ProgramFilesMocrosofSQLServerMSSQL.2ReportingServicesReportServerbin folder. (Or to MSSQL.3)

 

The only thing left to do is to change the static labels in your report to use this new functionality In your report.  In order to do this you need to add a reference to the assembly.

 

1.       Open your report , click on Report - > Report Properties - > References and add the assembly you created

 

2.        To localize the table name fields in the report, right click on each textbox and select Expression…. Type:

=AssemblyName. ClassName.MethodName. (“FieldName“, User!Language)

 

Once you have done this in all table name fields, deploy the report and it should appear in the appropriate language depending on the regional settings of the computer.

TechEd Gadget: development lessons learned

March 26th, 2009 by Adi S.
 
In my previous post on TechEd 2008 Countdown implementation I promised to share development lessons/tips learned and this post serves that exact purpose.
 
Gadget development turned out to be most development fun I have had in a while. Even though it is fairly straightforward there are several exceptions to the standard Web page development that I would like to share in order to save you research time in the future:
  1. Make sure to use both pairs of tags when specifying the location of your script file. A self-terminating tag such as <script…/> will not cut it and your gadget will not function as expected.
  2. OnMouseOver event seems to be disabled as far as opening of the flyout window goes. The onClick event will have to do. If somebody has a solution for this one please let me know as I hate to disappoint my friends who requested this feature.
  3. I was not able to set the background color of the gadget pages via bgColor property or the background-color style in a CSS file. However, the color specified in the style embedded in the BODY tag worked fine.
  4. Opening flyout window with another one already open creates this weird “loss of focus” effect. In order to avoid this check if the flyout window is already open and if so simply refresh the information contained within it. Code below demonstrates this much better than my narrative.
if(System.Gadget.Flyout.show)
     //flyout already open - call its function that loads the data
     System.Gadget.Flyout.document.parentWindow.loadPost();
else
     //display the flyout
     System.Gadget.Flyout.show = true;
 

The time spent researching these items is nothing compared to the joy of seeing the final result in action (as shown below) and reading all of the great posts by the TechEd community members. The final product can be downloaded here or by clicking any one of the images below. Enjoy!

  TEDev   TEGen   TEITPro

 

SQL Server 2008 to the rescue: user defined aggregate solution recovered

March 6th, 2009 by Adi S.
In my introductory post on user defined aggregates I mentioned that Merge() method will be an interesting point of discussion. The Merge() method is called any time SQL decides to split up the workload, process it on separate threads, and eventually merge all of the results. It seems perfectly desirable to be able to maximize the use of computer resources.
 
We have also decided to create a user defined aggregate that calculates the median which means that we will need some kind of data structure to hold all of the values in a group. For the sake of simplicity we could use an array of type double. The implementation using an array of type double will compile fine but upon the deployment to the instance of SQL Server you might receive one of the following two error messages depending on the data structure used.
 
Type {…} is marked for native serialization, but field {…} of type {…} is of type {…} which is a non-value type. Native serialization types can only have fields of blittable types. If you wish to have a field of any other type, consider using different kind of serialization format, such as User Defined Serialization.
 
Type {…} is marked for native serialization, but field {…} of type {…} is not valid for native serialization.
 
SQL Server has to be able to serialize UDAs in order to communicate/pass them between the threads. In fact, native serialization only supports following data types for native serialization: bool, byte, sbyte, short, ushort, int, uint, long, ulong, float, double, SqlByte, SqlInt16, SqlInt32, SqlInt64, SqlDateTime, SqlSingle, SqlDouble, SqlMoney, SqlBoolean. Since our array type is not acceptable for native serialization we will need to mark the Format attribute to use UserDefined serialization and provide our own implementation of Read() and Write() methods as defined in the IBinarySerialize interface.
 
The next issue that comes into play is that the maximum size of a serialized object cannot exceed 8000 bytes in SQL 2005. That does not allow too many double type values to be aggregated and the UDA execution will throw the following error if the size of serialized UDA exceeds 8000 bytes.

A .NET Framework error occurred during execution of user-defined routine or aggregate {…}: System.Data.SqlTypes.SqlTypeException: The buffer is insufficient. Read or write operation failed.
 
One suggestion I found was to force SQL to use on processor/core at the time via OPTION (MAXDOP 1) directive. That did not seem to resolve the issue as SQL Server does not seem to always accept aforementioned query hint. Needless to say this limitation greatly reduced the effectiveness of my solution.
 
Luckily the good folks working on SQL Server 2008 have decided to solve my problem and increase the size of the serialization buffer. SQL Server 2008 now allows CLR components to be serialized up to whooping 2GB as outlined in the TechNet BOL article titled “Requirements for CLR User-Defined Aggregates”. Way to go SQL Server team and thanks for saving my project.
 
 

SQL Server User Defined Aggregates

March 5th, 2009 by Adi S.
Statistical calculations are quite important in the implementation of financial applications. Surprisingly SQL Server does not support many unless the process is running within the Analysis Services framework. Few months ago I was in a need of calculating a median in several stored procedures performing statistical risk calculations. While I could have used SQL approach like shown in the listing 1 below I would have to replicate the same piece of code in numerous stored procedures.
 
Listing 1: Median using T-SQL and SQL 2005 CTE, ranking
WITH data AS
(
    SELECT someID, someValue,
    ROW_NUMBER() OVER(PARTITION BY someID ORDER BY someValue) AS RowNum,
    COUNT(*) OVER(PARTITION BY someID) AS NumRows
    FROM dbo.someTable
)
SELECT someID, AVG(someValue) AS Median
FROM data
WHERE RowNum IN ((NumRows + 1) / 2, (NumRows + 2) / 2)
GROUP BY someID;
 
Instead I decided to write my own median function using CLR that can be used similar to the AVG built-in aggregate. Visual Studio makes things easy by providing a convenient template to get you started. In order to create an aggregate CLR function you first create a SQL Server Project and then add a new item/class based on the Aggregate template as shown below.
 
NewDBProject.JPG   NewAggregate.JPG
 
There are four methods listed below that the aggregate requires. The Init() method is called once per group and we can use it to instantiate our own variables, such as an array holding all of the values we are looking to find a median for. The Accumulate() method is called on every value addition of the group (think grouped records in a table) and Terminate() returns the aggregate value once the group aggregation completes. The Merge() method is used by the SQL engine itself which might decide to split the aggregation work to multiple threads and merge the results of which prior to executing Terminate() and returning the result.
 
public void Init()
public void Accumulate(double Value)
public void Merge(Median Group)
public double Terminate()
 
The Merge() method is especially interesting and will lead to further discussion in part 2 of this blog. If you are interested in my own implementation of percentile/median function please contact me via “Send a message” on my Spaces page and I would be happy to share my experiences with you in regards to this or any other user defined function.