Tuesday, January 20, 2015

Using a on-premises / Azure VM server for Visual Studio Online builds

We're running low on CI build minutes, actually, I spent the 60 minutes in 1 day. So I'm setting up a build controller on an on-prem VM. Turns out it's a breeze to hook the build controller up to the Visual Studio Online account. Check out this post by Anthony Borton on how it's done.




HP DL380 G5 with ESXI 5.1 - processor options

So I took my 5th generation HP DL380 to my new job and because of the static IPs I had assigned to the ILO interface and ESXI, I couldn't get anything done anymore. So I removed the battery from the main board which did a nice reset of the ilo inerface but also reset the BIOS processor options. Thanks to the VMWare forum I found the options I had to configure to run ESXI on the box:

https://communities.vmware.com/message/2388160



If you forget the no-execute memory protection, you'll get purple error message. Below is how to solve these BIOS issues.

http://blog.vmpros.nl/2012/09/17/vmware-esxi-requires-the-execute-disableno-execute-cpu-feature-to-be-enabled/


Saturday, January 17, 2015

Console Application argument parsing: solved

I'm working on a codebase which has a lot of console applications and has several lines of code to deal with parsing the command line arguments. Well ... that can be removed since I found this little friend on NuGet: https://www.nuget.org/packages/CommandLineParser/


First of all - I can remove all the command line argument parsing code and just use the code demonstrated below.
Second of all - with 3 lines of code, a --help will be implemented showing you all the possible options for the command line tools.



Friday, January 16, 2015

Playing with JSON Schema

All the new ( 'vNext' ) stuff coming from Microsoft seems to be using JSON configuration files and less XML configuration. Today I was looking into my Azure Scheduled Job configuration and saw this:

{
  "$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
  "webJobName": "myjob-dev",
  "startTime": "2015-01-15T00:00:00+01:00",
  "endTime": "2015-01-16T00:00:00+01:00",
  "jobRecurrenceFrequency": "Day",
  "interval": 1,
  "runMode": "Scheduled"
}

Following the link to the JSON schema file shows you what it looks like:

{
 "title": "JSON schema for Azure Webjobs configuration files",
 "$schema": "http://json-schema.org/draft-04/schema#",

 "type": "object",
 "required": [ "runMode" ],

 "definitions": {
  "shared": {
   "properties": {
    "webJobName": {
     "type": "string",
     "description": "The name of the Azure Webjob."
    },
    "startTime": {
     "type": "string",
     "format": "date-time",
     "description": "The start time of a scheduled job. Example. 2014-06-11T00:00:00-08:00"
    },
    "endTime": {
     "type": "string",
     "format": "date-time",
     "description": "The end time of a scheduled job. Example. 2014-06-12T00:00:00-08:00"
    },
    "jobRecurrenceFrequency": {
     "type": "string",
     "enum": [ "Second", "Minute", "Hour", "Day", "Week", "Month" ],
     "description": "The frequency metric used with the 'interval' property."
    },
    "interval": {
     "type": "integer",
     "description": "The interval of how often the Azure Webjob should run. Use it with the 'intervalType' property."
    }
   }
  },
  "scheduled": {
   "required": [ "webJobName", "startTime", "endTime", "jobRecurrenceFrequency", "interval" ],
   "allOf": [ { "$ref": "#/definitions/shared" } ],
   "properties": {
    "runMode": {
     "type": "string",
     "enum": [ "Scheduled" ],
     "description": "Determines the run mode of the Azure Webjob. \n\n Triggered: manually triggered \n Scheduled: runs on a specific schedule \n Continuous: runs all the time"
    }
   }
  },
  "notScheduled": {
   "required": [ "runMode" ],
   "allOf": [ { "$ref": "#/definitions/shared" } ],
   "properties": {
    "runMode": {
     "type": "string",
     "enum": [ "Continuous", "OnDemand" ],
     "description": "Determines the run mode of the Azure Webjob. \n\n Triggered: manually triggered \n Scheduled: runs on a specific schedule \n Continuous: runs all the time"
    }
   }
  }
 },

 "oneOf": [
  { "$ref": "#/definitions/scheduled" },
  { "$ref": "#/definitions/notScheduled" }
 ]
}

So - JSON Schema for JSON is what XSD is for XML: you define a schema in which you define what information must or can be present inside an element.

I have to say I'm not sure what my position is on this. I'm a strong believer in 'the right tool for the job'. So if you want to write a textfile with information but want to enforce a schema - shouldn't you just use XML? XML with an XSD solved this problem.
You want to send data back and forth between a webserver and a client, without a lot of hassle and overhead and which works great with JavaScript ? Use JSON. JavaScript lets you get away with everything - so does JSON.

Don't get me wrong - I like all the developments in software and this surely adds to something. JSON configuration files wouldn't be possible in a product like Visual Studio if not for a schema. But one should not be affraid of it's dynamic nature and therefore make everything strongly typed. Embrace the dynamic nature of JavaScript and JSON or pick a different tool IMHO.

Anyway - I played around with it a bit and here are some interesting resources:

So here's my attempt at a schema:


{
   "definitions":{
      "car":{
         "title":"Car schema",
         "type":"object",
         "properties":{
            "make":{
               "description":"The manufacturer of the car",
               "type":"string"
            },
            "model":{
               "description":"The model of the car",
               "type":"string"
            }
         },
         "required":[ "make", "model" ]
      },
      "person":{
         "title":"Person schema",
         "type":"object",
         "properties":{
            "firstName":{
               "description":"The firstname of the person",
               "type":"string"
            },
            "lastName":{
               "description":"The family name of the person",
               "type":"string"
            },
            "cars":{
             "type" : "array",
             "items" : [ { "$ref":"#\/definitions\/car" } ]               
            }
         },
         "required":[
            "firstName",
            "lastName",
            "cars"
         ]
      }
   },
   "$ref":"#\/definitions\/person"
}

Which validates this JSON:


{
 "firstName" : "John",
 "lastName" : "Doe",
 "cars" : [
 { "make" : "Ford", "model" : "T" },
 { "make" : "Ford", "model" : "Galaxy" }
 ]
}


Note the $ref thing - makes everything nice and structured. Other than that it's all pretty straight forward.

We're going to see a whole lot more of JSON schema in the future I think - so you might as well read up on it!



Thursday, January 15, 2015

Visual Studio ALM Rangers: get your branching strategy right

We've moved source control over to TFS Online with GIT as the version control system. This is a good way to re-think our branching strategy. I was looking for some resources on the internet, because I think I want to move over to GitFlow but I need to read up on the pros and cons.

So if you don't know what GitFlow is - here's a great explanation: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow.

Then I found this CodePlex site that offers several guide for Application LifeCycle Management (ALM) on TFS. Check it out here: http://vsarbranchingguide.codeplex.com/ - go to the downloads page and find the PDF guide.