Shiju Varghese's Blog

Unlike other engineering industries, the software engineering industry is really lacking maturity. The lack of maturity can see in different aspects of entire software development life cycle. I think other engineering industries are well organised and structured with common, proven engineering practices. The software engineering industry is greatly a diverse industry with different operating systems, and variety of development platforms, programming languages, frameworks and tools. Now these days, people are going behind the hypes and intellectual thoughts without understanding their core business problems and adopting technologies and practices for the sake of technologies and practices and simply becoming a “poster child” of technologies and practices. Understanding the core business problem and providing best, solid solution with a platform neutral approach, will give you more business values and ROI, instead of blindly adopting technologies and tailor-made your applications for the sake of technologies and practices. People have been simply migrating their solutions in favour of new technologies and different versions of frameworks without any business need.

In this blog post, I will take a look at Git source control integration provided by Windows Azure Mobile Services. Windows Azure Mobile Services is great framework for mobile backend development on the Windows Azure platform, which provides a Node.js based programming model for writing server-side scripts. You can write the mobile services scripts in browser window provided by Windows Azure developer portal. Windows Azure Mobile Services also provides you to setup source control with Git, which lets you clone the Git repository for Mobile Services scripts, in your local machine where you can work on the  Mobile Services scripts in your favourite IDE or text editor and later you can commit and push the source code back to Windows Azure production environment. The source control integration lets you easily work as a team for working on Mobile Services scripts.

In this blog post, I will take a look at Open Web Interface for .NET (OWIN) and will also demonstrate how to deploy ASP.NET Web API app on Windows Azure Worker Role using OWIN and OWIN HttpListener server provided by OWIN self host infrastructure. The OWIN HttpListener server lets you host ASP.NET Web API within your own process. In this demo, I will host the ASP.NET Web API app within a Windows Azure Worker Role.

In this blog post, I will write unit tests for a ASP.NET Web API controller in the EFMVC reference application. Let me introduce the EFMVC app, If you haven't heard about EFMVC. EFMVC is a simple app, developed as a reference implementation for demonstrating ASP.NET MVC, EF Code First, ASP.NET Web API, Domain-Driven Design (DDD), Test-Driven Development (DDD). The current version is built with ASP.NET MVC 4, EF Code First 5, ASP.NET Web API, Autofac, AutoMapper, Nunit and Moq. All unit tests were written with Nunit and Moq. You can download the latest version of the reference app from http://efmvc.codeplex.com/

I am pleased to announce that I have been awarded as a Microsoft MVP 2013 award. This is the fourth Microsoft MVP award since 2010.

One of the key features of the Cloud is the on-demand scalability, which lets the cloud application developers to scale up or scale down the number of compute resources hosted on the Cloud. Auto Scaling provides the capability to dynamically scale up and scale down your compute resources based on user-defined policies, Key Performance Indicators (KPI), health status checks, and schedules, without any manual intervention. Auto Scaling is an important feature to consider when designing and architecting cloud based solutions, which can unleash the real power of Cloud to the apps for providing truly on-demand scalability and can also guard the organizational budget for cloud based application deployment. In the past, you have had to leverage the the Microsoft Enterprise Library Autoscaling Application Block (WASABi) or a services like  MetricsHub for implementing Automatic Scaling for your cloud apps hosted on the Windows Azure. The WASABi required to host your auto scaling block in a Windows Azure Worker Role for effectively implementing the auto scaling behaviour to your Windows Azure apps. The newly announced Auto Scaling service in Windows Azure lets you add automatic scaling capability to your Windows Azure Compute Services such as Cloud Services, Web Sites and Virtual Machine. Unlike WASABi hosted on a Worker Role, you don’t need to host any monitoring service for using the new Auto Scaling service and the Auto Scaling service will be available to individual Windows Azure Compute Services as part of the Scaling.

In this post, I will demonstrate how to scale out real-time Socket.IO apps with Windows Azure Service Bus by leveraging the Node.js module Socket.IO-ServiceBus. The Node module Socket.IO-ServiceBus lets the Node.js developers scale out the Socket.IO apps to multiple servers, which will work with Socket.IO store, provided by Windows Azure Service Bus Topic. The only Windows Azure component you need to scale out your Socket.IO apps with Socket.IO-ServiceBus, is Windows Azure Service Bus Topic. You can deploy your Socket.IO apps into any cloud platform or on-premise servers and, the apps deployed in multiples servers, that will be work through the Windows Azure Service Bus. This blog post assumes that you have already worked with Socket.IO apps and will be focused on how to scale out Socket.IO apps with Windows Azure Service Bus.

C# is the most powerful static type programming language which can be used for developing wide variety of applications. Node.js is a server-side JavaScript platform which can be used for building high performance scalable applications on the V8 JavaScript engine. .NET provides more than 11,000 packages via NuGet and Node.js provides more than 30,000 modules via NPM. It would be great if we could use both .NET and Node.js platforms in one place. Edge.js is a Node.js npm module that lets the developers to run .NET and Node.js code in one process, where you can call  .NET functions from Node.js and Node.js functions from .NET. With Edge.js, you can call C# async lambda from node.js. Both .NET and Node.js are using different threading models, but Edge does handle the threading models of single threaded V8 and multi-threaded CLR. Currently Edge.js supports to use JavaScript with C#, F#, Python, and PowerShell. Edge.js was developed by Tomasz Janczuk. The Edge.js framework hosted on Github at https://github.com/tjanczuk/edge