Thoughts on Software Engineering

If you have an Azure Virtual Machine (VM) that you work with frequently, you would typically try to manage this experience through the Azure Portal. The user experience is pretty intuitive and easy to work with. Simply press the Start button to startup a new instance and Stop button to shutdown the instance. However, I must admit that this approach still does not satisfy my desire to save time. After all, this is the era of Automation and Microsoft Azure must have a better approach to this problem! The following are the steps you can take to automate this experience. Step 1 : It is not a good practice to use our own account to do this work because it is usually a Global Administer role with full rights. Thus, let's create another user account via Azure AD as a Limited Administrator. Step 2 : Grant the user the Role of Service Administrator. Step 3 : Create the following powershell file. The bat files are created to start and stop your Azure virtual machine. St...

When you start an Azure Virtual Machine (VM) instance, you will get a Public IP Address. This allows you to remote-desktop into the Azure VM instance. Naturally, you may try to reconnect back with the same IP Address at a later time after you disconnect from it. However, if you are using the default setting of dynamic IP, the old IP would not work since a new IP would be assigned. There are two approaches to trying to solve/minimize the problem of reconnecting without changing the Remote Desktop Connection. If you navigate to the Public IP Address page on the Azure portal, you will find 2 options: Option 1: You can setup a static IP Address. This approach means you can always rely on a known IP Address. This is a good choice especially if you have some firewall configuration that relies on a known static IP Address. Whether you choose to go with dynamic or static, please take note of the pricing implications . Option 2: Setup a FQDN (fully-qualified domain name)....

The Azure WebJob SDK provides a lot of helper functionalities that we can leverage. One example is the QueueTrigger API, that provides the ability to read messages from a queue when a message comes in. Just as a comparison, if you are not using the QueueTrigger API, you will probably have to write some timer, and/or loop code to read messages from a queue periodically. This is not fun. Let's take a look at a usage example below. public class Foo { ... public void ProcessMessage([QueueTrigger("MyQueueName")] string message) { // Do something with message. ... } The code above is pretty self explanatory. This class will be invoked when a message appears on "MyQueueName". However, what if we want to handle a bunch of messages coming from different queue names? Would we have to repeat this code in a couple of places? Certainly not! We can handle this by implementing INameResolver. public class NameRe...

Integration testing is a technique employed to assert whether an end-to-end scenario is working - where all pieces of the software components (typically non-user-interaction interface) are being tested together. For the article today, I am going to talk about how we can achieve integration testing with the Web API we have created - that is secured by Azure AD OAuth. Let's start off being evaluating some sample Web API code we have written. [RoutePrefix("account")] public class AccountController : ApiController { ... [HttpPut, Route] public AccountDto Add(AccountDto accountDto) { ... } ... } When we think about integration testing on the Web API level, we are really interested in the response returned when an API is being invoked. For clarity, I have removed the code within the Add Account API for now, so we can concentrate on the signature. So, the first question is, should we simply in...