Tuesday, January 15, 2013

AngularJS $scope vs Controller Inheritance

I wrote this article because I was confused about what 'Controller Inheritance' actually was.  First let's look at $scope inheritance.

Example1 - $scope inheritance

Note) The ChildCtrl is nested within MainCtrl in the html.  AngularJS responds to this by ensuring that the $scope passed to ChildCtrl inherits properties and methods from the $scope passed to and decorated by MainCtrl.

Also Note) AngularJS does not introduce any inheritance (prototypical or otherwise) between the actual controllers themselves.

If you want your controllers to actually inherit properties and/or methods (that are not exposed on the $scope), then you can do this perfectly well by employing standard, non-AngularJS javascript prototypical inheritance between the controllers.

Example 2 - Rolling your own Controller Inheritance

   Note) I changed for the way I create my controllers from an anonymous approach utilising the controller method to a named function approach.  This is necessary because you need the named function in order to access and extend its prototype.

Also Note)  I forced the ChildCtrl to inherit from the main MainCtrl using prototypical inheritance. I was then able to do is extend the $scope of the ChildCtrl with a method that made use of the inherited method.

Thursday, January 10, 2013

Continuous Integration vs Code Modularisation

I was writing out some conditions of satisfaction today and was about to write one about code modularisation. Some rubbish like
As a developer, I want to be able to independently release my code so that I can fulfill my obligations.....
As an Agilist, the 'As a developer' bit immediately rang an alarm bell, so I decided to recast this with the dicipline of thinking about real users.. do they care.. this is what I came up with.
As a business owner, I expect that different teams with different schedules and deliverables, can produce and release software independently so that each team can deliver value as soon as possible.
My first thought was that this was a 1:1 translation of the code modularisation argument but then I got to thinking about continuous integration. If you are doing CI properly then surely this real condition is fulfilled. You could in theory have multiple teams working on the most interrelated rabbit warren like codebase in the world but still manage to release small incremental changes independently. +1 for agile discipline.

Friday, May 08, 2009

RuleClarity Brochure site now up

The software is still under development but the brochure site is up :)
You can check it out at http://www.RuleClarity.com

Thursday, January 22, 2009

Tech Preview - Semantic Rules

I'm very excited about this new video. It previews new technology that I have been working on. Feel free to comment good or bad. I apologise in advance for my abuse of clip art and slide transitions ;).

Monday, July 07, 2008

Gui Dazzles, Backend Frazzles

This is one of those truths that just hit me on the train this morning. You put a solution in front of a user, its the interface that gets them excited. All of the clever, performant and robust backend processing in the world won't impress them one bit. The backend is just 'stuff that can go wrong'.

For a case in point, Metastorm. I build applications for the financial services industry. A workflow solution has always been a good fit(document centric, process heavy etc...).

A few years ago, i was involved in a pilot of IBM's workflow solution. I was really impressed, it was well structured and the intrinsic use of MQ made orchestrating human and system processes seamless. The Pilot tanked.

Fast forward to last year, there was a crazy buzz in the business. Everyone was talking about Metastorm. What is it, its a workflow solution. I was confused, why the excitement now about a workflow/orcestration. I was lucky enough to work on our Metastorm implementation and now I understand where the excitement came from.

It's the GUI. The Metastorm workflow designer is fantastic easy to use and intuitive, the front end 'todo list' GUI is web based and similarly very nice.

I'm pragmatic about software. While I really like several aspects of the IBM solution but my customers are exited about Metastorm. Its already working for them and is capable enough to support all sorts of new solutions so I am working with it.

So just remember, if you want to build software that builds excitement, that can 'get in the door'. Get the GUI right.

Wednesday, May 28, 2008

Building Blocks

Building software is a bit like building a house with bricks (please, for a moment, forget my brilliant cake analogy described earlier in blogtime).

For a long time I have been using Visual Basic to build software. Building with VB is a bit like building with leggo bricks. The pieces are colorfull and easy to snap together. You can build almost anything but if you try to build anything too big, people will either say 'wow, i dont believe you managed to build a 2 story villa with lego!' or they will just snigger at you.

Building with Java is like building with house bricks. Nice and square. You have to use mortar but you can build big and small and you can put your house anywhere with pride. Building with C# is exactly like building with Java but the bricks have a little logo on them ;)

I dabbled with Ruby. Ruby bricks are pretty, they are translucent and have an odd otherworldly inner glow about them. To build with Ruby bricks, you dont need mortar and they dont snap together, you simply 'talk' them into place using a mystically mangled version of english.

'Ruby bricks, form of a payment....no...Payment class with ruby bricks create!....no...Please, sniff, just work...no...dang'.

Building with Ruby/Rails is like building a house...with a house. The only variable is how long it will take you to come up with the house. There is a demo on the internet that shows you how to do it in 10 minutes. It took me 2 hair pulling, eye scratching, forum crawling days to get close to the same result.

Most recently (about 2 months) I have been building with C/C++. I am finding this to be infinitely more fun than Ruby/Rails. So far I have managed to build, well, a brick.

keep you posted :)

Thursday, November 15, 2007

You are living in a box

If you are like most people, you will be reading this humble blog post from within a browser application. If you are like most people, you are probably taking for granted many of the utilities and functions afforded to you by your browser, the toolbar with its convenient visually indicative images, the menu with its comprehensive and logically arranged functions.

You are also probably entirely comfortable with the way you are interacting with this blog post. You are reading it. Your browser is eminently capable of supporting this mode of interaction.. its a 'browser' after all, you can scroll through the post, change the font size, even print it.

This is all very comfortable and familiar but what if you wanted more. What if you thought this blog post was so fantastic that you wanted to capture it, ads and all. Say you wanted to add some notes to it, circle some of the more insightful passages, squiggle a mustache on the image of the author and then email it to your mates. Firefox cant do all that, neither can Internet explorer. These applications are not free form editors, they are merely browsers.

'But wait' you say, 'I can get this done!'. And you are correct, you can achieve this a number of ways. For example, you could print the post, edit the printout, scan or photograph the printout and create an image file. You could then open an email application, attach the image file and send it. Also, you could print-screen the image, Open a paint program, paste the image, edit the image, save as an image file, open an email application, attach the file and send it. You could also send an email to Microsoft or the Firefox community requesting free form editing, notation and highlighting and email integration features for their respective browsers, you could then wait a long time.

That these operations are doable is not at issue. All of the necessary tools to achieve this outcome, this deliverable, already exist on your computer. The point I want to make is how these tools are arranged. They are stuck inside applications, inside boxes. This blog post is the thing you are interested in right now (I assume this because you are still reading). If you want apply all of these wonderful tools to this artifact, you need to export, transform, import the artifact into each application in turn. This is horrible! You take this for granted, you cop this on the chin because, like most people, you have grown complacent and accepting about the limitations of software and the operating system.

Why cant we make software better. Why cant we make the artifact, the thing you are interested in right now, the most important thing? Why cant we free up these tools from their application boxes make the computing experience more intuitive?