sfeldman.NET

If every future 0.1 update will be like this, I don’t dare to imagine what 1.0 update will be like. So far it was a very pleasant experience. In the past updates where more of a roller-coaster: you expected a lot, got some of that, and eventually found that there’s still a lot that was missing. For the first time that I have windows phone an update contained more than I have expected to see.

For those who were fast to bury it, here’s some update:

If you’re running into a bug like I did, there are good and bad news. Good – Microsoft acknowledged this bug and will fix it, bad – it will happen in the next release (not sure then). In MS favour I have to admit that they turn things really quick, so who knows, it might be already in the release notes of the next release :)

The idea behind this is extremely simple: to run a deployment machine in Azure that will be used to deploy updates to production. In my environment we get everything packaged on build server, but deployment has to happen in a controlled environment and from a manual kick-off. Deployments are not performed at night, hence compute time is wasted. To save 50% (at least) of compute time, VM has to be down.

Plan for solution: get a single instance VM down during night and up at work hours. My initial thought was to use Azure Cloud Services auto-scale feature.

Pros:

- Defined under Cloud Service VM instance belongs to

- Scaling is a property of Cloud Service

Cons:

- Requires Availability Set to be created and associated with VM instance

- Requires at least 2 VM instances to run Auto-Scaling (deal breaker!)

Fortunately, with the new release of Azure Automation, this can be done with Runbooks (a Runbook is a workflow that contains a PowerShell script, that can also call child Runbooks).

Pros:

- Doesn’t require multiple instances of VM (hence saving money)

- Runs under the context of subscription, therefore has access to all resources

Cons:

- Scheduling is not as flexible as with Auto-Scaling and needs to be associated with a Runbook

What I ended up doing was quick and dirty, but it does the job for now.

1. Create an automation object (Virtual-Machines)

2. Imported two Runbooks into automation (Start-AzureVMsOnSchedule and Stop-AzureMVsOnSchedule)

Note that “import” is as simple as importing PS script wrapped in workflow name_of_workflow { #powershell script }

3. Published imported runbooks

4. Associated a schedule with each runbook

5. Specified for each schedule to execute on a certain time daily (for Start runbook to run at 7AM, for Stop runbook to run at 7PM). BTW, parameters can be passed to individual runbooks, so that job (executed runbook) becomes a parameterized job. Also, resources can be used from all

6. Once a job (schedule runbook) was executed, it’s logged (you can drill into details of each command – can see Bruce`s eyes light up)

7. Job executed (spike at 7AM) and VM is up and running. Big Success *Borat accent* :)

Note that when you edit Draft of your runbook, you can run (test) it before publishing. Also, you can import existing modules (Azure module is imported by default) using command toolbar at the bottom, add settings that can be shared by multiple runbooks, and insert Activity (powershell command) / Runbook / setting.

Azure Automation is a great feature to leverage. Excited to see all of these things shaping up and making work easier, allowing to cut down costs at the same time.

A year ago I have started looking and evaluating cloud options. AWS and Azure were two options. I have decided to go with Azure for a couple of reasons that are still valid today (even more than a year ago)

Early testing is amazing. I am not talking about TDD and developers testing their own creation. I am talking about testing performed by professional QAs with mindset to hack the heck of your system (code, server, deployment, you name it). The value of early testing vs. late testing in SDLC is very easy to show to those that deal with with software on a daily basis and live it everyday. But how do you translate it to the business? Visualize it. One is high level – show one approach vs another and start asking questions.

We are ramping up on our development of a new version of existing system that will utilize NServiceBus for communication between its various parts. Learning NServiceBus is a great resource to get going, especially if you need in short time to go from 0 to 100. The books falls a little short on testing IMO, but it gives you enough to move in the right direction. In case you are planning to deviate from a standard transport (MSMQ), you won’t find a lot of help in this book. Though frankly, outstanding NServiceBus team and amazing community behind it will answer any of your questions, if those were not already answered. Since NServiceBus is now under Particular, this is the new user group you want to send your questions to.

In the marketing world tag (or pixel) is used for tracking purposes. Historically it was based on a call to retrieve a 1x1 transparent image. Rational behind this was to retrieve client side information of a site visitor on a 3rd party server. Information would include browser standard information including cookies. There’s a lot of things that can be done with this information from analytical and marketing point of view.