Continuous delivery with Azure App Service

Update:

Click here for the SoCalCode camp presentation about this topic.

Introduction

This post would introduce you to continuous delivery pipeline using Azure app services. We would take a use case and implement the steps that we need to take in order to establish a build pipeline.

What is Continuous Delivery?

In simple words “Constantly develop, automatically build and automatically deploy”. This means that as soon as code is checked in a system would automatically build the application and deploy.

Azure App Services

Azure app services is a set of technologies that enable development of cloud centric Web Apps, Mobile Apps, API Apps and Logic Apps. There is a great introduction to App Services presented at: https://azure.microsoft.com/en-us/documentation/articles/app-service-value-prop-what-is/ .

Power of App Services

To understand the power of Azure App Service you have to compare to a classic Web Application with any of the technology such as Azure App Service Web App. In a classic Web App, a web server such as IIS is the main component. The Web App is installed on IIS and the pages are served through IIS to internet audience. This is a typical on premises infrastructure implementation. You are responsible for managing the security, availability, scale and instrumentation. Part of the classic web app infrastructure is the responsibility of not only delivering the web app but maintenance of the web server. This includes the separation of environments such as development site, QA site, UAT site and the production site. Also, since web server maintenance is part of this infrastructure, you have to also think about the actual server where that web server is installed. The environment that server offers greatly effects how the web server would work. This is another layer of responsibility that a web developer has to keep in mind.

With the App Services, the IIS part has been abstracted away. This means that management of web server (for example IIS) is not the focus but the focus is the delivery of web app. As an application developer we can easily create on App and have it hosted in different deployment slots. These deployment slots makes it easy to create environments such as development site, QA site, UAT site and production site for the same web app.

Continuous delivery pipeline for Azure App Service

Since web server and the server hosting the web server is not part of Azure App Service, the establishment of continuous delivery pipeline is very easy to establish.

Our focus for this post is to list the steps and design patterns that we can use to establish the continuous delivery pipeline.

There are three major steps to establishment of continuous delivery pipeline for Azure App service. These are:

Establishment of development slots

Once you have created an Azure Web App, you have to define its deployment slots. Usually the deployment slots are representation of your different environments. For example, in a typical web development effort you would have following environments:

1.      Development: This is the environment that is used by development team to help them develop different aspects of the project. Typically this is referred simply as “dev”.

2.      QA: This environment is used by the QA team to test the web app separate from the development environment. This is great for providing isolation and also to do better validation testing. Typically this is simply referred as “qa”.

3.      UAT: This environment is used by product owners or stake holders to validate different features after the QA has signed off. Again an isolation from dev and QA allows the UAT to test the web app irrespective of the test data that QA has used to valid. Typically this is simply referred as “uat”. Usually a separate database is attached for the UAT environment.

4.      Staging: This sometimes also known as pre-production. Typically is used to validate the build process and once the build is validated, this environment is swapped with production. Usually the staging environment uses the same production database. This allows the swapping from staging to production seamless without any down time. Typically this is simply referred as “staging”.

5.      Production: This is the actual web application that represents the production environment. Typically this is simply referred as “prod”.

The Azure App Service gives each deployment slot a unique URL. This essentially means that each of the deployment slot is a separate web application. Each of the web app URL representation of the environment is used by different team members. Development team members use the dev URL, QA uses the QA URL, and UAT uses the UAT URL for the web app.

Here is an example of different deployment slots for our API web app.

Establishment of branching strategy

There are a lot of different branching strategies that are used in the industry. The branching strategy is designed or sometimes evolved based on respective objectives. One of those objectives is the environment. What it means is that for different environments different braches are established. To simplify let us take the following branching strategy.

Master branch – For Development environment

QA Branch – For QA and UAT environments

Production – For staging environment

Importance of branching strategy means for continuous delivery

Since the main tenant of continuous delivery system is to automatically we build and automatically from a code check in, we have to pay extra attention to where the code check in takes place. If we look at our branching strategy, it would mean that if we check in the code in the master branch then dev environment should be build. If we check in the QA branch then it means that QA and UAT environments would be build. Same goes for the staging environment. This is why your branching strategy should be representative of your build environments. Let us take a typical scenario to explain more:

Joe (Backend developer) completes first part of the story and checks in the code to master branch. This kicks off a fresh “dev” build.

Jessica (Front end developer) completes the second part of the story and checks in the code. This kicks off another fresh “dev” build. Since the second part of the story completes the story. The build manager merges the master branch into QA branch. This kicks off a QA build and a UAT build for both QA and UAT team members.

Establishment of build/publish process

Azure App Service deployment

There are multiple ways to deployment apps on Azure App Service.  There are:

FTP

This is a most direct and classical way of deploying any web app. The major drawback is that this a total manual process. If you need to automate this, you have to write quite complex scripts.

Web Deploy

This tool allows you to directly deploy web apps to azure app service from visual studio. Although you do not have to use FTP for this scenario but you still have to do actual deployment manually.

Kudu

This build engine is used where we want to have automatic build/publish execution when a source code repository is attached. This means that as soon as a check in take place on a branch (established in step 2), the kudu build process would kick in a do the rest.

Code checked-in to repository  >>  Kudu initiates the build >> Kudu publishes the website

Multiple web apps challenge

The above mentioned steps would work great if you have only one web app in your code repository. For example, you have create a dedicated branch for one web app that has one solution file (.sln). The challenge comes in the shape of a scenario where you have multiple web apps and they all share the same code repository. For example, in a typical business application, you might have one web app that serves the pages and one Web Api app that is consumed by the web app. You might have different release pipeline for WebApi and web App. In this scenario the visual studio solution would contain both projects as part of the solution.

To accommodate the scenario of multiple web apps projects in a solution, you have to take some extra steps.

Step 1. Add app setting to your App Service to uniquely identify your app. This is to give Kudu a way to kick start the build and complete the publishing once code has checked in.

Step 2. Add “.deployment” file to the base of your source code repository. The “.deployment” file gives Kudu a starting point to start the deployment process. Here is a sample:

As you can see what the “.deployment” file is asking Kudu to do is just to call deploy.cmd file. We would look at this in next step.

NOTE: 

Before proceeding further it is important to note that following are prerequisites for the next steps:
1. Nodejs: https://nodejs.org/en/

2. azure-cli: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-command-line-tools/

Step 3. Create deploy.cmd file. This is the file that would tell Kudu how many different web apps or web Api apps are available in your code base that needs to be built as part of continuous integration pipeline. 

Here is an example of deploy.cmd file:

If you look at this file, you would notice that there are three web apps that are mentioned in the code. These are the three projects that are part of same solution file. What this code is doing is checking which App Service has kicked started the build process. This essentially means the branch where the code check in has happened. The SITE_FLAVOR comes very handy here as we use this App setting to identify the application.

After the app service identification, the deploy.cmd is just calling the corresponding individual deployment files. In our examples there we have three different deployment files. Those are:

deploy.customersapi.cmd

deploy.customersweb.cmd

deploy.anotherapi.cmd

In our next step we would see how you create these individual deployment files.

Generating Deploy.customer.cmd

 Step 1:

Assuming that your customerapi’s project file is at c:\sites\CustomerApi\src\CustomerApi.csproj and customerapi’s solution file is at c:\sites\CustomerApi\src\CustomerApi.csproj and c:\sites\CustomerApi\CustomerApplication.sln. Execute the following command using elevated Administrator mode either on command prompt or Powershell prompt. I always prefer PowerShell because of ease use.

azure site deploymentscript --aspWAP c:\sites\CustomerApi\src\CustomerApi.csproj  -s c:\sites\CustomerApi\CustomerApplication.sln

      Step 2:

Running the above command would yield a file called deploy.cmd. Rename file deploy.cmd to deploy.customersapi.cmd.

Step 3:

Repeat steps 1 and 2 for customersweb and anotherapi projects.

Conclusion

Azure App services are set of very powerful technologies that gives a very clear pathway to establish a continuous delivery pipeline.

SocalCode Camp presentation

The following presentation about this topic presented at the 2016 SocalCode camp.

Continuous delivery with azure app service from Nabeel Khan

Mobile User Membership Architecture with Mobile Services Backend

Introduction

We have reached to a point where mobile apps have become essential. The two big groups of mobile apps are natives and mobile web apps. There is a separate discussion about which type would make more sense, when that would be the case and why in general. The thing to takeaway is that mobile web app is actually a type of web site. So when talk about user membership architecture, we are essentially talking about user membership for a website. But when we are talking about native apps, the user membership architecture is different from mobile web because of the capabilities a native app contains in itself. In this blog, I am going to focus on the user membership architecture for native app site of mobile world.

Mobile User Membership Architecture

A user membership architecture is a design that shows how a user of an app is formally defined as "User" of that mobile app. The reason I put emphasis on word 'user' is because there is a very essential process that has to take place which will qualify user of an to app to a "User". When the qualification has taken place then the "User" is now identifiable as an entity to the Mobile Service Backend. To understand that let us take a scenario where you have developed an App and distributed the App to the market. To user that App, anyone can download the app and use it. The App does not know anything about the user. On top of that the Mobile Services Backend does not know anything about the user of the App either. So when the Mobile Services Backend does not know about the user then there is no analytics related to users of the app. Also, if you wanted to have a provisioning feature in the app, you cannot do that because there is no distinction between the users. So User Management Architecture is the path that you an use to define and qualify a user of an App. 

The main components of Mobile User Membership Architecture are:

• User creation or signing up process
• User authentication process
• Mechanism for user logging in
• User logging out mechanism
• Mechanism to retrieve/reset user password or any other property of user entity
• Optional: Mechanism to let anonymous user to log in
• Optional: If anonymous user is allowed then there should be mechanism to convert them to regular users if requirement exists

Fig. Mobile User Membership Architecture

Conclusion

User membership is way too important to be ignored for any mobile device app. This is a vast field. In this post I have tried to explain in simple terms what choices we have. But there are more details and intricacies that are in the play for user management on mobile devices. This post gave you a high level introduction. In my subsequent post, I will try to go in more detail for each of the components and explain with code examples. Stay tuned.

One of the great ways to acquire knowledge is to share knowledge. Please do share your experience and knowledge by commenting so we all can better design great mobile applications.

Why cloud-based mobile backends makes sense

Update:

Due to the announcement by Parse to shutdown it is services, the examples mentioned in this article related to Parse are no longer valid. However, the same principals are valid on other cloud platform such as as Microsoft Azure.

Background

For the past half year, I have been delving into iOS and developed and release three iOS apps to App Store. The main reason of delving into iOS was close the native mobile app gap that I was ignoring for a long time. I have been doing mobile web development for past three years but somehow (may due to my laziness), I did not get opportunity to develop a native app. I thought of choosing android instead of iOS but then due to some facts on the ground I decided to take the iOS path. Now when I developed the apps for iOS using Swift programming language. My main purpose was to learn and prove my learning by developing and releasing the apps to app store. The apps were pretty simple and did not require any mobile services back-end. But as I added more features in my apps, I started to feel more need to have mobile service back-end. I started to look into different mobile services offerings and this led me to Parse SDK. This is the background of this post.

Mobile Services Backend

What is meant by Mobile Services Backend?

Mobile Services Backend also referred as Mobile Backend by some vendors is a set of services, APIs and SDKs that enable a mobile app to interact with central resource (usually a cloud service) in order to leverage features like:

1. Push notifications
2. Membership Management
3. Storage
4. Security
5. Analytics
6. Social network services

So in simple terms a mobile app is a client that requests for the mobile services from the Mobile Services Backend.

Why we need Mobile Services Backend? 

1. One simple reason is for the mobile developers to focus of providing client side of mobile app and be more of consumer of services and not the developer.
2. Ability to switch mobile services backend without rewriting a whole lot of code. Today you are using one Mobile Service Backend and tomorrow you want to switch to another, due to market condition, usage of your app or missing feature of mobile service. By keeping the mobile backend service as separate implementation from front-end app code, we get the separation of concern that enable to switch mobile backends as need dictate.
3. Easy to add more features on mobile app if that feature is supported by the Mobile Services Backend.

So now we know what is Mobile Services Backend and why we need it. Now its time to look into why Parse SDK makes sense.

Reasons

1. Quick start: It is very quick and easy to get started on Parse SDK. The process simply is to
   
   • sign up for Parse SDK,
   • choose the platform and mobile app front end that would be consuming the Parse cloud service features.
   • download and unzip the SDK
   • Incorporate the Parse SDK feature per your app requirement.
2. Features: There are more features that Parse clouds offers than other offerings. These include:
   
   • File Storage,
   • Database Storage,
   • File Transfer,
   • A/B testing,
   • Custom segmentation,
   • Scheduling,
   • Custom Events,
   • Instant Breakdowns,
   • Advanced Reports
   These features are present in some of the other offerings but what I like about the Parse is that it makes it very easy to use these features. For other offerings you have to write more code which might be a powerful feature but that also leads the app developer to go through a steeper learning curve.
3. Division of services/features: Instead of considering all the features as a monolithic collection of features to incorporate, you as a app developer have an easy choice to choose from 'Core','Push' or 'Analytics'
4. Segregated SDKs: Parse SDK features the selection of SDK based on the platform that is used by your mobile app. Following are the different platform for which there is a separate SDK:
   
   • iOS,
   • Android,
   • Java Script,
   • OS X,
   • Unity,
   • PHP,
   • .NET + Xamarin,
   • Arduino,
   • Embedded C
5. Pricing: This is a major feature that led me to delve in Parse SDK in the first place. I like that they let you start free and stay with free subscription as long as limits are not reached. This is similar to Heroku cloud's offering. As developer, I like it a lot. This lets me to fully use a framework without worry about the expiration of free trial period.
6. Quality: This might be an overlapping feature amongst all the top Mobile Service Backend providers. The reason that I am calling it out here is because, whatever I have seen experienced on Parse SDK has been of very high quality. From the SDK usage, tutorials, Dashboards and scale that is provide seems to be top notch.

 I do want to mention on thing that I do not like about the Parse SDK. When you include the Parse SDK in your iOS app, you have to include a lot of iOS libraries along with it. If I just want to use local storage then why I need to include all other libraries. This makes me thing that it would result in bloated binary. May be someone from Facebook take notice of that and correct me or correct the documentation/SDK.

Conclusion:

These are my opinions based on my limited experience looking into few of the top Mobile Services Backend provides. There might be some Mobile Services Backend provides that are better than Parse and I might have missed features that might make other Mobile Services Backend provides better than Parse. Having said that I think Parse SDK is formidable offering and it should be seriously considered in greater scheme of thing for Mobile App Architectures.

One of the great ways to acquire knowledge is to share knowledge. Please do share your experience and knowledge by commenting so we all can better design great mobile applications.

 

Interaction Design between user and the operating system - Part 2

Taking our discussion further, in this blog we would explore options for programming the user interaction with operating system.

User action programming

In part 1 of this series we focused on the direct user interaction with the operating system. But fact of the matter is that most of the user interaction on a computer or a device happens through a custom software or app. So it is very important to focus on the programmability of the operating system functions.

"Any programmed interaction must make use of most of the operating system supplied functions."

The above statement is the essence of this discussion. Let us establish one thing here before we go any further.

The best (in terms of ease of use and reliability and probably others) interaction experience is through operation system supplied functions.

For example: If I want to open folder and view its contents, the operating system has a command for it. It would have a user interface and set protocols (steps) to invoke that command and the experience that user gets would be standard and consistent. A programmer can write a custom software that would accomplish exactly the same thing but using different user experience and different protocols (steps). Another programmer can write another software that accomplishes exactly the same thing but using another set of different user experience an different protocols (steps) and so and so forth.
The thing to note here is the impact on the user. Since custom software uses its own user interaction and protocols, it is responsible for the acceptability and reliability of its functions. What is meant here is that the programmer would have to consider so many things to create such a software. The user is totally dependent on the knowledge and the interface engineering provided by the programmer through the custom software. This is where we start loosing the battle. This is where we as engineers or programmers have to ask ourselves, are we taking the user out of misery or putting them in misery? If we use the operating system supplied functions in our code, then we would not have to worry about so many other things.

As a reader you must be thinking that this would end  all the programming and programmers especially the application programmers. Well that is true, in a perfect world. We as technologists are not as developed yet. We have a long way to go. But this is what should we strive for.

Let us get back to our current era and talk about the points againts the above statements.

1. What about those interactions that operating system does not provide?
That is a very valid point. Let us take an example to elaborate more on it.  The application that user is using requires a certain interaction of moving the position of the window from right to left with in the time span of 2 seconds as a result of a user action. This user action would always yield the same result of moving the position of the window. The operating system that user is using does not define it a function. Means there is not a similar interaction provided by operation system as a function. In the case the obvious solution would be to write a custom code that does such interaction. A programer writes a such a code. Same task is given to another programmer and another programmer. We would have a result using different solutions that accomplishes the same thing. Since the solutions or the written custom code is different, we have to assume that one of them is better then all the others. What if we just had one programmer and he/she was the one who tasked and the solution the he/she wrote was not the one that was the best. It means we have a software code is not best code. This is the point that mentioned earlier as the point that we as technologists start loosing.

So what should be the solution. The solution should be that the operating system should be augmented with the best solution (code) for the moving the window from right to left within a set time. This would become an augmented function of the operating system and should be made available publicly to other progammers.

2. So we keep adding functions to OS but for how long?
This is another valid argument. We cannot keep adding any new interaction that anyone's mind can think of. This is where we have to make a distinction between valid and invalid interactions. We have to draw a line in the sand and define these two types of interactions. We should design software using such that user would not need to make use of an invalid interaction. This is another high point in this discussion. The interaction design should be so smooth and natural that user does need to think of an interaction that in fact is an invalid interaction.

Conclusion

The point of this part was not that we do have software that do not make use of operating system defined functions. But to point out the places where we cannot. The two main points are: A) that operating system should be rich in respect that all its functions should be valid and available. B) the second point is that we should design the interaction so smooth and natural that use would not need to make use of interaction that is not defined as a valid interaction.



 

Dart from .NET - Unit testing

Introduction

Unit testing as an aspect of software development is essential tool to keep the code  valid. This means that when we develop software or write code, we need an automated way (programmatic way) to validate the written code. QA can help with validating the results but cannot take place of automated scripts that run the unit tests. Also, we need to have something written by programmers that validate what programmers have written so far, looking from programmers' perspective.

Unit testing with Dart

Unit testing with dart is pretty straight forward. Here is what you need to do to write a simple unit test using dart language.

1. Import unit test package 'package:unittest/unittest.dart'.
2. Setup main() function to launch the test
3. Arrange code to prepare for test
4. Write code for test.
5. Assert the results.
6. Establish the testing infrastructure (or simple create a web page that would call the test code).
7. Run the tests in the browsers.

Here is an example:

 import 'dart:html';  
 import 'dart:convert' show JSON;  
 import 'dart:async' show Future;  
 import 'dart:math' show Random;  
 import '../lib/attempt_helper.dart';  
 import '../model/attempt.dart';  
 import 'package:unittest/unittest.dart';  
 import 'package:unittest/html_enhanced_config.dart';  
   
 List offlineSymbols;  
   
 main() {  
  useHtmlEnhancedConfiguration();  
  //useHtmlEnhancedConfiguration(true);  
  var path = 'symbols.json';  
  //HttpRequest.getString(path)  
  //  .then(_getOfflineListFromJSON)  
  //  .then(_launchOfflineTests);  
  HttpRequest.getString(path)  
   .then(_parseSymbols)  
   //.catchError(_getFailsafeFeaturedSymbol)  
   .then(_launchAttemptHelperTests);  
  //_launchAttemptHelperTests();  
 }  
   
 List _parseSymbols(String jsonString) {  
  offlineSymbols = JSON.decode(jsonString);  
  return offlineSymbols;  
 }  
   
 void _launchAttemptHelperTests(List symbols) {  
  AttemptHelper attemptHelper = new AttemptHelper();  
  List<Attempt> attempts = new List<Attempt>();  
  Attempt newAttempt = new Attempt()  
   ..answers.add("1")  
   ..answers.add("2")  
   ..answers.add("3")  
   ..answers.add("4")  
   ..correctAnswerIndex = 1  
   ..givenAnswerIndex = 1;  
  attempts.add(newAttempt);  
  Random random = new Random();  
  group('Attempt Helper Tests ->', () {  
      test("Test to check if list has any item", () =>  
       expect(attempts.length > 0,isTrue)  
      );  
      test("Test to check if returned attempt from helper is not null", () =>  
       expect(attemptHelper.getAttempt(attempts, symbols) != null, isTrue)  
      );  
      test("Test to check if returned attempt's answers from helper is not null", () =>  
       expect(attemptHelper.getAttempt(attempts, symbols).answers != null, isTrue)  
      );  
      test("Test to check if returned attempt's answers are greater than 0", () =>  
       expect(attemptHelper.getAttempt(attempts, symbols).answers.length > 0, isTrue)  
      );  
      test("Test to getScore", () =>  
       expect(attemptHelper.getScore(attempts) > 0, isTrue)  
      );  
      test("Test to check if returned randon answer is not null", () =>  
       expect(attemptHelper.getRandomAnswer(symbols, random, newAttempt.answers) != null, isTrue)  
      );  
      test("Test to Post a wrong given answer", () =>  
       expect(attemptHelper.postGivenAnswer(attempts, "10") == false, isTrue)  
      );  
      test("Test to Post a correct given answer", () =>  
       expect(attemptHelper.postGivenAnswer(attempts, "1") == true, isTrue)  
      );  
      test("Load test by running 10records", () =>  
       expect(get100Attempts(attemptHelper, 10) != null, isTrue)  
      );  
     });  
  }  
   
 List<Attempt> get100Attempts(AttemptHelper attemptHelper,int numberOfInterations) {  
  List<Attempt> hundredAttempts = new List<Attempt>();  
  for(int i = 0; i < numberOfInterations ; i++) {  
   attemptHelper.getAttempt(hundredAttempts, offlineSymbols);  
  }  
  return hundredAttempts;  
  }  
   

As you can see from the above example it is pretty simple to write the unit tests in dart programming language. Also you can see how similar it is to unit tests that we write using C# in .NET.

Running the unit tests

As mentioned in point 7 and 8 in the previous section, we have to establish the unit test infrastructure which essential the host for the tests. In our example it is a simple web page. You can use command line app to host your unit tests.

Here is the code of the web page that establishes the infrastructure and runs the unit tests:

 <html>  
  <head>  
       <meta charset="utf-8">  
       <meta name="viewport" content="width=device-width, initial-scale=1.0">  
   <title>tests</title>  
  </head>  
    
  <body>    
   <p id="text"></p>  
   <script type="application/dart" src="tests.dart"></script>  
   <!-- for this next line to work, your pubspec.yaml file must have a dependency on 'browser' -->  
   <script src="packages/browser/dart.js"></script>  
  </body>  
 </html>  

That is it!

Here is how the results look like:

Dart from .NET - Why Dart?

Introduction

I have been a Microsoft .NET developer since .NET came out as Beta back in late 2000 and Visual Basic developer before that. Over the past fifteen years I came across many languages and technologies that pose challenge to .NET and its development framework. They were good but usually they were good in one particular aspect and again at some level you have to fall back to IIS or .NET framework for other features. I am not claiming that over the past fifteen years there was no language or technology that did all what .NET does. They might have done all but they were not as good as .NET or in some cases the development environment was not as easy to use as Visual Studio.

And then came Google's Dart

 As I mentioned in my intro that .NET provided a complete solution for most of the programming projects. That meant that in some cases we as developers had to work through some of the challenges that .NET framework posed. I always looked for a language that would be close enough to C# and at the same time development would be easy in it should provide a complete solution and not just one aspect. 

Elephant in the room

Let us talk about the elephant in the room first. By the elephant in the room, I mean the following:

1. Dart is not even supported by Chrome

At the time of writing this article, the Google's chrome does not support dart in its default setting. But there is a version of Google Chrome called Chromium that does come with Dart support. You can visit https://www.dartlang.org/docs/dart-up-and-running/contents/ch04-tools-dartium.html for further details.

2. Why not just use java script?

Google has been improving java script for a long time. Java script has come a long way. The fastest java script engine that I am aware of is called V8. Having said that Java script has some language features that put Java script in some disadvantage. If not disadvantage then at least cause the slowness. Google's dart language has language features that allow it be faster than javascript. Just that alone is an advantage that makes a whole lot of sense when thinking about scalable mobile applications. Also, let us say you use dartToJs to convert dart code to Java script. That too is faster than traditional java script. 

Screen shot from : https://www.dartlang.org/performance/

3. What about the Google's Go programming language?

This one is a tough one. Per my knowledge Google's Go language or golang was developed to make programmers more productive. So it means it is not a language comparable to C# or VB but a language to fix a part of problem. I do not think that if I should invest time and energy in learning golang. If you compare that with Dart then dart appears to be more general purpose and more evolved than golang.

 4. What about jQuery?

If you take the evolution of a language as a factor then jQuery seems to be quite evolved. Google Dart seems to have been "inspired" by many features of jQuery if you go through some development using Dart. With all the good stuff that jQuery does,  underneath that it is essentially java script. So the same disadvantages Also, if jQuery would have been filling all the gaps that java script has then I do not think Google dart would have been developed.

So since I have explained the negative things that are said about Google's Dart language, I can now talk about the good stuff.

Amazing Dart Features

Now let us talk about the aspects that makes language of choice for modern web apps.

Scalable Web app development:

When the dart was being developed, it appears that only the 'good parts' of other languages like 'C#' and 'Java script' were taken into consideration. At the same time the 'bad parts' of the other languages were avoided. What resulted is a language that is highly tuned for scalable web application development. Here is one example:

import 'dart:math' as math;

import 'dart:convert' show JSON;

The above two examples show a feature that is quite amazing. What it does is that it enables a program to include a particular library but not all of what is present in a library. It allows select part of library that your program would be concerned with. Imagine the situation where System.Web in .NET. The system.web is a huge a library about 8 megs. In ASP.NET we use system.web a lot but we do not need all the features of system.web. What ends up happening is that the application becomes bloated. 

So language features as one mentioned above allow us developers to create scalable web applications using Google's dart language.

Mobile development:

Like or not more and more applications are being developed for mobile. Which means that more and more of the logic is being sent on the browser end and less of  running the logic at the server side. This is pushing the envelop on web development. You do not have much memory at the same time you cannot rely on chatty architecture as mobile environment is not always available with internet (that is why SPA "Single page application" gained popularity). So what it means that you want to provide rich experience to users but not rely on heavy web controls. Dart fills this gap very well. It is robust like jQuery for provided rich experience at the same time it is fully refined language as C#.

Language feels like C#:

Why this is an amazing language feature? That is because most of the .NET developers including me love C#. So when you see a language similar to C# then you feel at home and learning curve does not seems intimidating. Let us say if the dart's syntax was very different from C# then for me personally it would have been a major turn off or I had to prepare myself for steep learning curve. Now let us see some of the examples where dart language feels like C#.

Server side programming:

This is huge. We have been living in a web echo system where UI logic was written in different language then middle tier logic or the back-end logic. Example, a web site that has front end developed using jQuery or Java script, talking to a web service that is written using C#. That certainly meant that you have to have expertise in both languages in order to produce an excellent result. Which often meant two different types of developers.With dart you can have a developer who is expert for both back-end and front-end developer. There is an interesting analogy that helps explain this. In the world of military aviation, those air force who have more variety of aircraft are considered less efficient than those who have less variety. This is because for more variety you have to have more skill personal in different technology who translates into more expensive maintenance.

In my next few blogs I will share my experience and knowledge with regards to dart.

Troubleshooting System.BadImageFormatException - Changing Target platform - A hack that might work

Introduction

Often times, we run to case where we are trying to load a dll from third party vendor that is not matching our development configuration. 

For example, we might have a .NET 4.5 solution or project that is trying to load a third party library in form of a .dll file but run into System.BadImage.FormatException error.

According to MSDN there might be any number of reason for this error. The details are listed on the following link:

http://msdn.microsoft.com/en-us/library/k7137bfe(v=vs.90).aspx

But I found another solution which is not listed anywhere on MSDN and sites that I googled.

Details

Here is the scenario. I had a project that was written in .NET 4.5. I was trying to reference a library that was specific to .NET 64x platform. I added the reference to the library and complied the project. The compilation was successful. So far so good. But when I ran the application I was getting the following error:

System.BadImageFormatException

"Could not load file or assembly 'blahblah.x64, Version=x.x.xxx.xxx, Culture=neutral, PublicKeyToken=xxxxxxxxxxx' or one of its dependencies. An attempt was made to load a program with an incorrect format."

I did a lot of research and found that one reason might the mismatch in the target .NET framework. My assumption was that I might have a library that is written in .NET 2.0. 

So, the solution that I found was that I changed the target framework of my solution to .NET 2.0. I ran the application the loading of the dll worked fine. But some part of my application that were using features in .NET 4.5 stared to break. So it was a catch 22 kind of scenario. So what I did is that by pure luck I switched back my platform to 4.5 and ran the application. This time I did not get the terrible error that I mentioned above.

That seemed odd. So I created a brand new application using .NET 4.5 as framework and repeated the steps mentioned above. On adding the library for the first time and running the application, I got the error. Then I switch the framework to .NET 2.0 and rebuild the solution and ran the application and it worked. I then swithched back my solution to .NET 4.5 and this time no error. 

I do not exactly know why it starts working after switching the framework a couple of times. My guess is that when we switch framework from .NET 2.0 to .NET 4.5, I think there is a kind of upgrade that Visual Studio is doing that fixes the error.

Conclusion

If you get in similar situation where you cannot figure out the fix for the BadImageFormatException and have tried all different kinds of solution and it does not seem to work then you might try the solution that I have mentioned in the details section. That might work.