WittyCoding

Following on from the previous post, I’m going to attack the technical tests now.

The aim of this post is not to make the umpteenth comparison of email providers.
That’s always subjective, depending on our needs.
The aim here is to study compliance with sending standards from a technical point of view.
Personally, I couldn’t find any comparisons, so to choose my future provider, I went on a provider tour.

And I was quite surprised…

Entity Framework Code First has introduced many included features that most team projects had to build manually, such as code and database schema synchronisation during the developement lifecycle using initializers (eg. DbMigrations) and data seeding. To use the later, the developer simply has to override the Seed Method of the initializer he has chosen to use. But the developer (or the architect) still has the responsibility to ensure that the seed code is well made, and easily maintainable. With a number of EF entities of dozens or even hundreds of table on most medium sized projects, the developer will have to think of an architecture that can divide the complexity of seeding the whole database. This article will focus on one architecture that can handle the complexity of the seed process without being too hard to use by the developer. As often, simpler is better.

Last Thursday, I had the opportunity to lead a conference for MUG (Microsoft User Group) of Lyon. This workgroup presented several advantages of websites with a Single Page Application (SPA) philosophy.

In WPF or Silverlight application, the vectorial is king. It is for this reason that as soon as I can, I use a Path instead of a picture.

One of the first times that I worked with Silverlight, I wanted refactoring my application and create a project named “MyProject.Client.Resources.”. This project should contains various style sheets and other common resources with the rest of the project.

It happens sometimes that you want to make a line break in XAML view. As this language is based on XML, it becomes problematic because traditional characters do not work.

If you do not have the chance to use Visual Studio 2012, you still have to suffer the vagaries of old designer. Heavy, slow and memory leaks, welcome to hell.

I propose two solutions to facilitate the modification of XAML files.

Now that all is up and running, we can start to generate the actual contracts.

As we will generate some ServiceContract interfaces, we have to add a reference to System.ServiceModel.dll in the current project.

In previous post about Model description, we discussed how we could describe webservices using a common XML file that will be used by the tools we will be writing in order to manage them. It is now time to start dealing with all the repetitive tasks and makes your hand dirty. We will start with a basic template to output all contracts in one C# file directly, and we will move to a cleaner solution as tutorials will go.