Misc

Azure: Do never use EF automigrations when working in teams

de Misc , , ,

Todays number one approach in building database access libraries on ASP.NET based applications is the Entity Framework. Since Microsoft supports migration based database updates, which mostly look like copied from the approach Ruby on Rails offers since ages, it’s possible to use them in scenarios where continuous deployment is key.

The core model which fits perfectly into a development process around continuous delivery & deployment is a code-first approach. This means that the developer creates so called POCOs (Plain Old C# Object) and the system is able to generate the needed SQL changes, based on the current state of the database.

The Entity Framework has two options to generate the migration:

  1. Auto Migrations
    The Entity Framework tries to generate the database changes on runtime without any specific migrations implemented as code. Everything happens magically 😦
  2. Explicit Migrations
    The Entity Framework just runs the migration scripts written in a .NET based special DSL for database operations. Nothing happens magically 🙂 This needs the developers brain but is controllable even in large teams.

When you work in a team Auto Migrations are really a bad idea and should be disabled from the beginning. Assume developers do changes manually in the database which means the magic around AutoMigrations will generate a different set on instructions against this database as the next developer will get. The results of auto migrations in team environments are not reliable and repeatable.

So it’s a really good idea to disable automatic migrations from the start:

public Configuration()  {
AutomaticMigrationsEnabled = false;
}

Auto Migrations do not have a win at all when it comes to projects with more than one developer or projects which are deployed automatically. Continuous deployment relies on a strict unit of work and as less magic as possible. This will also help to troubleshoot when the continuous deployment breaks the production and a rollback is required.

Microsoft also published a nice article with more information at the MSDN: http://msdn.microsoft.com/en-US/data/jj554735.aspx

Advertisement

Azure Storage: Is the Geo Redundant Mode really required?

de Misc , ,

Microsoft Azure offers different replication modes for Azure Storage. Every mode approximately doubles the costs for a TB of data. During a great workshop with Patrick Heyde we talked about stamp copies and I asked myself which mode I really needed.

First I took one step back, to identify all requirements I typically have in my projects for a highly scalable, fault safe, redundant storage :

  • When a hard-drive in a storage server brakes, my data still needs to be usable.
  • When Microsoft has huge power outage on a whole datacenter, I want to bring my app up and running again in another datacenter.
  • When I (or my customers) are removing data by accident, there needs to be an option to revert to a former snapshot.

So a review of the different replication modes compared to these requirements leads me to the following results:

When a hard-drive in a storage server brakes, my data still needs to be usable:
The Local Redundant Storage fulfils this requirement perfectly. Microsoft writes 3 different copies of every bit within one single data center. When a hard drive on a stamp or the whole stamp goes down, another one can take over and all data is available without any interruption.

When Microsoft has huge power outage on a whole datacenter, I want to bring my app up and running again in another datacenter:
Microsoft offers a geographical redundant storage mode that stores another 3 copies in another datacenter a hundred miles away. This helps a lot, because every application can use the secondary location to access to the data – but is it worth the price? The price for GRS is three times higher then for LRS.
An automated replication between two different LRS storages, hosted in a Azure WebJob might be a good solution the fulfill the requirement as well.

When I (or my customers) are removing data by accident, there needs to be an option to revert to a former snapshot:
Globally Redundant Storage is not helpful when it comes to removing data by accident. As soon as the data is removed from the primary storage, the system removes the data in the backup location as well, often within seconds.
But this requirement can also be fulfilled with a replication between two different LRS storages, as already described above. The whole application needs to be designed for this use cases.

So this review brings me to the conclusion that in my personal opinion GRS storage is not needed in most of the use cases. Normally several LRS storages and an application logic optimised on the specific data security requirements works well and preserves the budget.

What’s your opinion? Do you have use cases where GRS and Read-GRS are hard requirements? If you like, leave a short comment …

Understand your service types in the Azure Cost Monitor

de Misc , ,

The Azure Cost Monitor is able to analyse and manage every existing Azure service. In the past sometimes the different service types could have become unclear, especially for people with big subscriptions and a lot of services. This was because the Azure Cost Monitor was only using an icon to explain the service type:

nontooltip

Starting today the Azure Cost Monitor also offers a tool tip with a clear explanation of the the service type, whenever a user moves the mouse over the icon. It also works on tablets or smartphones, whenever users touch the icon on a specific service.

tooltip

This little feature should really help to reduce service type confusion in the Microsoft Azure Cloud.

Validate authentication_token from Microsoft LiveID with node & express-jwt

de Misc

Microsoft offers with live.com a service which can be used as identity provider for your application. I lost a couple hours when I tried to validate the issued authentication token from Microsofts IdP with the help of express-jwt in my node application. 

When an application requests a token from live.com via the oAuth2 implicit flow an access_token will be issued which needs to be used for the live service as self. In addition to that an authentication_token will be issued in the standard JWT format. This token can be used as authentication token in your node server. 

Normally validating a JWT token is very simple with node+express+express-jwt stack. Just configure a middleware and enter your application secret:

var jwt = require(‘express-jwt’);

app.use(jwt({secret: ‘<<YOUR SECRET>>, audience: ‘<<YOUR AUDIENCE>>’, issuer: ‘urn:windows:liveid’ }));

 

The Microsoft dashboard offers an application/client secret for your live application. This secret will be used in a very specific way from Microsoft as the key for generating the signature of your JWT token. I found the following solution in the history of the LiveSDK GitHub repository. 

The signing key for the token is a SHA256 hash of the given application secret plus the fixed string “JWTSig”. I ended up with the following code to generate the real secret for validation:

var crypto = require(“crypto”);
var secretTxt = ‘<<YOUR APPLICATION SECRET>>’;
var sha256 = crypto.createHash(“sha256”);
sha256.update(secretTxt + ‘JWTSig’, “utf8”);
var secretBase64 = sha256.digest(“base64”);
var secret = new Buffer(secretBase64, ‘base64’);

The generated secret can be used in the expres-jwt middleware as follows:

app.use(jwt({secret: secret, audience: ‘<<YOUR AUDIENCE>>’, issuer: ‘urn:windows:liveid’ }));

With this little piece of code it’s super simple to verify JWT tokens from live.com. I hope Microsoft starts documenting this little secrets better in  the future. 

 

private bower components, a simple solution

de Misc , , , ,

Bower is an amazing solution to bring structure into javascript based projects. Without bower the reusing of components on git repositories would be a mess. During my current project I searched for a solution to integrate private bower based components into my closed source project. All I had was a private git server with the option to create infinite repositories.

 

 

When you google you find many options to setup a separate bower registry which means the backend behind bower. This is very useful if you want to search in a database for a component. This approach also helps bigger organisations to allow everybody to publish a component and the rest of the research and development department should be able to find it.

In our case the situation was more simple. We are a very small team and everybody is able to see our official git repositories on our centralized git server. Only repositories on this server are allowed to be used in customer facing projects. There are many private git repositories but these do not contain public code. Coming from this situation we wanted a solution which comes without an extra server component.

Searching again made me sure that it should be possible to add a git url into the bower.json file. Our git server is configured for the https protocol only and for this just copying the repository url did not work. After checking out the bower code base a solution was on the horizon:

git+https://YOURGITREPO

The important thing here, git+https. This gives the bower code the hint to use the git protocol over http. Just using https:// would not work because bower thinks it’s a http based directory download.

Small teams should be able to work well with this solution, especially when the git server is part of a team management system which contains wiki and document components as well.

Ensure two div-elements will get the same height (jquery solution)

de Misc

Currently I’m working on a small web application with the requirement to bring the height of two side-by-side div elements on the same level. The content of this two elements are different and the width depends on the browser window. This means the div content floats in the elements and the height depends on the height of the inner content. I tried to find a working solution based on CSS only. At the end I want to share a jquery based solution which works well for me

  1. The following markup can be found in many web apps
    https://gist.github.com/3965331/77a38858b214ae71c2cf521fa3ee0c0048e1bca8
  2. First I added  jquery and code to identify the div with the maximum height. After that this height will be set at the second div element as well
    https://gist.github.com/3965331/1fbbfbbd2a3116ad48ed03f874695d9bfb4d7589
  3. Finally moving out the code into a separate function helps to reuse this code in other apps as well. It could als be a good idea to build a small jquery plugin
    https://gist.github.com/3965331/81308dec45be018cd4f29220460ee6f770fa5005

 

 

HockeyApp your Rails App

de Misc ,

I’m an excited user of HockeyApp and we are really successfully with collecting crash dumps and deploying our apps to beta users. Since I’m working on different rails backends I’m wondering why not using the same infrastructure for collection crash dumps as well. Based on the amazing airbrake gem I was able to hack an extension which redirect the crash report directly to HockeyApp. Check this out and feel free to give feedback, open issues or fork the project:

https://github.com/dei79/hockeybrake

Happy to get feedback 🙂

git-tf for Homebrew

de Misc , ,

A couple weeks ago Microsoft released a tool chain called git-tf. It’s a great working git-TFS bridge which is working much better then the old SVN-Bridge. The best at all now active component on the TFS server needs to be installed. Check out the blog comment and the project on codeplex:

http://gittf.codeplex.com/

http://www.infoq.com/news/2012/08/git-tf_oss

I’m using this tool for our MAC OS X Development and it’s awesome. To simplify the setup of this java based implementation I created a Homebrew Formula and created a pull request for merging  into the master. Cross the fingers and vote for it 🙂

https://github.com/mxcl/homebrew/pull/14423

If you want to use my fork in your brew installation pleas use the following command line

cd `brew --prefix`
git remote add git-tf-fork https://github.com/dei79/homebrew.git
git pull git-tf-fork master
brew install git-tf

Comments and contributions to this Homebrow Formula ar welcome