Cloud Foundry / Iron Foundry app & service limits

[Note this is correct for version 1.2 of the MCF/MIF]
If you're running Cloud Foundry (or Iron Foundry) locally (ie the "Micro" or MCF VMs), and you get this error when provisioning a service or application :

Error 504: Too many Services provisioned: 4, you're allowed: 4

Or

Error 601: Too many applications: 4, you're allowed: 4

Then you need to alter the config on your MCF instance.
This can be done by editing /var/vcap/jobs/cloud_controller/config/cloud_controller.yml

and altering the default values displayed below :


admin_account_capacity:
memory: 1024
app_uris: 32
services: 4
apps: 4
default_account_capacity:
memory: 512
app_uris: 8
services: 4
apps: 4

ASP.NET MVC4 Web API

Just checked out ASP.NET MVC4 Web API. Pretty impressed. We've been quite happily using OpenRasta so far for our restful stuff.
I'm not going to do full comparison, because I've not used web api in anger yet, and I don't want to be arguing for or against either frameworks, but here is some info on how to do some of the stuff you're going to want to know if considering a move from OpenRasta to ASP.NET MVC4's Web API (or perhaps just starting out in the resful framework space and have chosen Web API).

Pipelines
One thing I love about OpenRasta is the pipeline stuff - very easy.
But I have to say, Web API's making it pretty easy too ...
Note I'm injecting in a service ... its as easy as it should be

    public class MyPipelineInterceptor : System.Net.Http.MessageProcessingHandler
    {
        readonly ISomeService _service;

        public MyPipelineInterceptor(ISomeService service)
        {
            _service = service;
        }

        protected override HttpRequestMessage ProcessRequest(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            return request;
        }

        protected override HttpResponseMessage ProcessResponse(HttpResponseMessage response, CancellationToken cancellationToken)
        {
            return response;
        }
    }

Dependancy Resolution
Again pretty darned easy, and I have to say (sorry Seb), easier to inject your favourite DI framework than OpenRasta 2's.
This is using Structuremap :

            GlobalConfiguration.Configuration.ServiceResolver.SetResolver(
                 t =>
                 {
                     try
                     {
                         return ObjectFactory.GetInstance(t);
                     }
                     catch (Exception)
                     {
                         return null;
                     }
                 },
                 t =>
                 {
                     try
                     {
                         return ObjectFactory.GetAllInstances(t).Cast<object>();
                     }
                     catch (Exception)
                     {
                         return new List<object>();
                     }
                 }

                ); 

Pretty easy to configure :

            GlobalConfiguration.Configuration.MessageHandlers.Add(new MyPipelineInterceptor(ObjectFactory.GetInstance<ISomeService>()));

Handlers
Handlers are minimal, and feel a lot like OpenRasta's.
Instead of OperationResult you have HttpResponseMessage.
The routing is handled automagically via a single call

            routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

    public class ValuesHandler: ApiController
    {
        readonly ISomeService _someService;

        public ValuesHandler(ISomeService someService)
        {
            _someService = someService;
        }

        public HttpResponseMessage Get()
        {
            return new HttpResponseMessage(new[] {"value1", "value2"}, HttpStatusCode.OK);
        }

        public HttpResponseMessage Get(int id)
        {
            return new HttpResponseMessage("value1", HttpStatusCode.OK);
        }

        public HttpResponseMessage Post(string value)
        {
            return new HttpResponseMessage(HttpStatusCode.Created);
        }

        public HttpResponseMessage Put(int id, string value)
        {
            return new HttpResponseMessage(HttpStatusCode.NoContent);
        }

        public HttpResponseMessage Delete(int id)
        {
            return new HttpResponseMessage(HttpStatusCode.NoContent);
        }
    }

Pipeline injection
So one of the patterns we use (see https://github.com/agilex/agilex.persistence.openrasta) is injecting a repository into OpenRasta's CommunicationContext's PipelineData before any request, and disposing it after every request (kinda AOP style).
Chucking *global* resources into your pipeline is easy in Web API too ... in your interceptor (the first class in this post) :

request.Properties.Add("thing", new MyThing());

And then you can just access the properties in your handler/controller too, or on the response method on your pipeline interceptor.

So overall, pretty impressive so far.
As I said, I've not used it in anger yet, so not sure how it stacks up with trickier usuage (like complex model binding, or one-to-many route relationships - ie /users/123/orders), but to be fair, considering the model binding stuff is from asp.net mvc, and the routing is pretty similar, I'm sure it will be fine.

Alternative to MVC Routing

This dll takes some of the pain away from registering routes in ASP.NET MVC (including having to alter your routes when you rename a controller !)
It's on Nuget as "Mvc.Routing"

So instead of registering routes like this :

 routes.MapRoute(
     "foobar route",
     "foo/{someParam}/bar",
     new { controller = "Foo", action = "Bar" }
 );

You can just call :

 Routing.Register(typeof(MvcApplication).Assembly);

And then tag your controllers :

public class FooController : Controller 
{
 [Get("foo/{someParam}/bar")]
 public ActionResult Bar(string someParam) {
  // whatever
 }
}

There are attributes for Get, Post, Put, Patch and Delete
The attributes behave like the normal HttpGet, HttpPost (etc) attributes - ie if you tag an action as Get(), then you can't post to it

You can use them in conjunction with the normal Http* attributes, for example :

public class FooController : Controller 
{
 [Get("foo/new")]
 public ActionResult New() {
  // whatever
 }

 [HttpPost]
 public ActionResult Create(Bar bar) {
  // whatever
 }
}

If you don't use the HttpGet / HttpPost attributes for your actions, you can still register routes like so :

public class FooController : Controller 
{
 [Route("foo/{id}")]
 public ActionResult View(Guid id) {
  // whatever
 }

 [Route("foos")]
 public ActionResult List() {
  // whatever
 } 
}

Testing your routes is also pretty simple, below is an example using Mspec (Machine.Specifications) :

    [Subject(typeof(TestController), "Given a test controller has marked the Index method as Get")]
    public class when_registering_routes : register_route_context
    {
        Establish context = () =>
        {
            theExpectedRouteUrl = "all/routes/are/mine";
            theExpectedActionName = "Index";
            theExpectedControllerName = "Test";
        };

        Because of = () =>
        {
            Routing.Register(typeof(TestController).Assembly);
            theRoute =
                RouteTable.Routes.Select(x => x as Route).Where(x => x.Url == theExpectedRouteUrl).FirstOrDefault();
        };

        Behaves_like route_should_be_registered;
    }

See the project specs here for more examples : https://github.com/benjaminkeeping/Mvc.Routing/tree/master/src/Mvc.Routing.Specs/registration

Openrasta : Binding arrays / enumerables from form data

In ASP.NET MVC if you submit a form that looks like :

myarr[0]=11111&myarr[1]=22222

Then a controller that takes IEnumerable will have the form data parsed in successfully.

Looks like the default binder in Openrasta behaves a bit differently. You need to format your form data like this instead :

myarr:0=11111&myarr:1=22222

This works with posting/putting arrays of objects as well (ie myarr:0.Name=Dave), aswell as being supported in posting/putting models which contain arrays within them

Nodejs, express, jade and express's app.bodyParser() (nodejs 0.6.8)

So you're using the nodejs modules express and jade, and you're posting some form data, and you can't work out why 'req.body' is undefined.
You've read the docs, and you're using app.use(express.bodyParser()) and its not working still.
You're config looks like this :


But you need it the other way round, like this :


What you've done wrong is have the bodyParser() line after the app.router line.
Make sure you put the bodyParser() line before the app.router line, and you're gravy.

Note that after a twitter exchange with the express developers, this isn't a bug, but a feature of express's middleware config - a side-effect of the flexibility of their middleware injection.
This 'fix' works for me - I'm pretty new to express, so I've no idea on the impact on other middleware you may have configured.

I'm sure after more playtime with express I'll understand why routing config blat's body parsing if done in that order.
PS - If anyone does know the answer, I'd welcome a full explanation, or link to the docs on it.

Nodejs Tedious Sql Server Driver and GUID / UNIQUEIDENTIFIER

So you're using SQL Server / SQLEXPRESS with nodejs for some odd reason, and you're trying to pull back Ids from a table that is has the field declared as UNIQUEIDENTIFIER, but you keeping getting an error like :

Unrecognised data type 0x24 at offset 0x0009

But its OK when you pull back nvarchar's etc.

Nasty hack that works (considering js doesn't know what a GUID is anyway) :
Change :

select Id from table
to:
select convert(varchar(38) , Id) from table

and all is well.

The debate on software craftsmanship

So this one keeps rumbling on. Are programmers software craftsmen ? Are we employed to execute a craft ? What does that even mean ? If it is a craft, does that mean some people are not in the club ? Does it matter if we are ? Or are not ?

I've written some really shit code over my years, and I've written it for some terrible reasons. And some good reasons. What do those reasons mean as a person ? Or a programmer ? Or a craftsmen ?
I've written code that was crap for the following main reasons :
1) I didn't know any better, and was doing as best I could
2) I was under krazy-with-a-K timescales, the company didn't give a rats arse about quality, and just wanted it, *anything*, out the door
3) I was lazy and/or disinterested in the task at hand

Uncle Bob (and I'm a big fan - "Clean code" was a wake-up call for me a few years ago) would most likely say that those 3 reasons for writing crap code are what made me not a craftsmen - I was a disgrace to my name as a programmer.
He wants to be able to distinguish between script monkeys banging out that kind of crap code, and the people who actually give a rats arse. And fair play to him - I get the sentiment.

Dan North would also say those 3 reasons for writing crap code are inexcusable too - but for differrent reasons. I'm guessing his argument would be that none of those reasons for writing code was actually focused on business value. If I understand his position (and I may not!), he would possibly argue that the main reason for writing code is to give the business employing you value - in terms of cost, return, and investment.

What's funny is that to me, I would guess (and I say guess, because this is all just conjecture - I don't actually know Mr North or Mr Martin) that both of those guys would agree that code should be focused on business value/deliverables, and also on code quality.... with a slight caveat ....

Business value isn't always equal to code quality. It *usually is* - but not always.
(Side topic - who the frick makes that decision eh ? Most times a dev makes it, they've got it wrong in my experience).

So why all the hoo-ha ? Who gives a frick if we're craftsmen or not ? Well, Uncle Bob and Dan North seem to, but I just don't get why.
As I see it, crap coders will write crap code all the time. Thats not a craft, nor is it adding business value.
Good coders will write good code, that adds business value.
Good coders, under pressure, will mostly write good code, sometimes crap code.
Great coders under pressure will write crap code - but will go and fix it asasp - and will lay awake at night, worrying about it.

Now to me suddenly, that does sound like a craft - in as much as novices do crap stuff, intermediates do much good stuff, experts write great stuff most of the time (no-one writes good stuff all the time).
There was a talk that Dan North did ages ago that talked about the transition from novice to expert - its a sociology thing ... can't remember it right now - think it was a oredev 2008/9 talk.

Good coders focus on the value to the business.
If we're good coders, then we use the principles laid out in "clean code", and other great books by luminaries in the programming world. We adhere to SOLID (unless we have a reason not to), we employ our refactoring techniques, we test our code, we drive our code from the business endpoint. We are "craftsmen" by default. But are we ? Are we not just doing *** our job ***. Surgeons don't get a pat on the back and a badge just because they did their homework on (sorry, I don't mean it) "best practice", and keep their tools clean and sharp. You know what they get ? They get "yeah - you did your job ... again. Cheers. Next please".

We're not l33t mofos that are at one with the ways of the coding ninja.
We've got a job, that some of us enjoy, and some don't.
Good companies hire good programmers.
Shit companies hire shit programmers (and good ones sometimes).

Being good at your job doesn't make you a craftsmen, it just makes you good at your job. It doesn't mean you can't take pride in your job, or mean you can't consider yourself to be expert (or journeyman, or novice or whatever). It just means we're doing a job like any other - its just that the people best at our job are the ones that are in-tune with the business, and also know how to write clean code.