I’ve heard the stories, read the reports, discussed and debated, disagreed and agreed, worked together and against each other; i think there may even have been blood spilled at one stage? I vaguely remember something about a keyboard and a dwarf… Indeed, if there ever was a word in the software industry which could raise the room temperature, it’s the little word “agile”.

HINT: If you ever find yourself listening to a techie and he/she/it is boring you with details from another universe and you don’t have a clue as to what they’re talking about (or what language they’re using even if it does sound remarkably close to your mother tongue), just randomly blurt “Agile!”- then stand back or run.

One of the concepts in agile is iterative development because iterative processes help achieve a goal efficiently by giving you the flexibility to change your trajectory as the goal itself moves. If you’re aiming at a goal that never moves, then this story is not for you. Also, check your goal for a pulse- it might be dead. Hence, it makes ironic sense to adopt agile in the same manner: iteratively. That is assuming you want to adopt it at all because if you don’t then there’s no point in proceeding any further. There are none so deaf and blind is how i remember the expression…

And the processes, practices and insights that agile opens us up to- testing, refactoring, pairing, reviews, continuous integration, dry, yagni and company- are also metaphors for adopting the very process itself. And even deeper, the metaphor for every software project should also be embraced for setting up your own company’s adoption of agile. Can you feel the power of recursion starting to make your head throb?

So think of adopting agile as a software project on its own and take it from there. Create stories like “get Paul* to integrate more than once a day consistently”. Get team players to estimate on the story. The team players in this case are those who actually want to get agile ticking along (volunteers). So it’ll probably take 2 weeks before Paul gets it right. Maybe if Igor* took the story he could “convince” Paul inside a week? Create your storyboard, organise the flow, derive a project plan, split it up into more iterations (if need be)- the usual. Then “code”.

Having trouble with Paul? Pair-up with someone. Tag-team it. Refactor. Check in your working “code” regularly. Review what’s been done. Write new stories. WARNING: You might actually start having fun. Role-playing is an essential survival trait of almost every developer. It’s addictive and to pretend that you’re actually the software is going to be a little mental for some, a little esoteric for others but hysterical for a geek. Oh, and don’t be surprised if your developers start to get a little carried away and come dressed as hexadecimal numbers to work. Just keep a straight face and say “Ah. Good morning, 1.6A09E667″.

On the serious flipside, when you start to setup a project plan for adopting agile in this manner you also get to eat your own 0xbaadf00d; practise agile more; refine valuable skills; learn lessons; incorporate it into team culture; get an empirical idea of how close you are to hitting the mark and have a working team at all times (this is most serious). All the feel good fluffy things you want to hear.

And on the negative, less fluffy, pessimistic , dark and evil side of things, when you start to overrun your estimates badly on a lot of stories, you also start to get some really good feedback on when to can the adoption and/or start again or try a new tact. Ok- that’s actually good news too. But how much you try will depend on the strength of the character flaws in your project leader.

And before you know it, you’ll be miles away from being the perfect agile team. Indeed, just like software, there’s always one more feature you can add or take away. There’s always that one routine that can be a little better. And over time, you need to make changes that help you stay relevant and marketable and profitable. It’ll always be perfectly imperfect. And so you keep coding, creating and evolving something even more beautiful (and useful) than you ever imagined in your wildest electric dreams.

zaFinTools has been updated with a new function: the statistics calculator. Given a dataset, zaFinTools will give you a descriptive breakdown of the numbers, statistically speaking, by working out and displaying the following information in one go:

Length, Median, Mean, Sum, Sum of Squares, Minimum, Maximum, Range, Variance, Standard Deviation, Co-variance, Mean Absolute Variation, and then the 3 quartile positions and values.

Shew.

Download zaFin for BlackBerry.

I posted about AR and thrift earlier (or late last year) and was reminded this morning that I didn’t follow up that post with the solution. So here it is: Download spike code.

Now it has been a while since i solved this, and the versions may have changed since then, but I do remember that the “tricksy” part was boot-strapping ActiveRecord. That was done using the supplied boot.rb. Once that’s done, you can happily run the thrift server daemon based on textbook instructions and the rest is history. Your models and all the ActiveRecord learnings you’ve had with rails can be re-used quite happily.

Happy coding.

A tres useful link for playing around with JSON parsing and data structures; a design tool if you like; the aptly titled Online JSON Parser.
And a useful library for Java ME. In fact, at the bottom of the landing page for JSON.org, there’s a list of implementations for a host of languages.

It’s expensive, mentally and resourcefully, but it’s rewarding. It also isn’t easy, which is probably why it’s not advocated by the populous, but it is rewarding. And it’s filled with all sorts of risks and dangers, but definitely rewarding. Rewarding if you get it right.

After months on Rails (web), Python (web), Objective C (iPhone) and C# (web) projects, i’ve settled my teeth into a juicy little BlackBerry project. It’s taken a lot of mental effort to switch, and in particular, switching to the following:
* the language: Java. New syntax, keywords and run-time nuances in memory management
* the frameworks J2ME and RIM: what do they offer where are all the packages
* the IDE (Eclipse): how does it work and how to customize your environment/experience, and then what else does it offer that no other IDE to date has offered
* the BlackBerry device: where, what, how does it do the things it does
* the unit tests (jmunit cross bunit): new language, new platform, new test harness, same procedures (more or less)
* runtime debugging tools with the simulator and component packs
* mobile development: patterns, architectures, design and development principles
* the UI: a whole new playing field where the only place in the world Managers are your friends
* automated building and testing (still getting there)
* code control and IDE integration

Every day is filled to the brim with slow progress punctuated by episodes of breakthrough bubbles, although a the days wear on, the bubbles are more frequent and the productivity increases naturally on a curve on its own.

The end result: another framework, platform, language, set of tools available at my fingertips to enable me to express a solution to a problem and then successfully execute that solution without too much limitation.

Spin-offs include restless nights, lots of “aarrggg’s”, a lot of debugging and a whole lot more muttering which usually starts with “now how do you do that?”. And that right there has been one of the greatest little nuggets- tackling a project like a n00b, a grom; with all the enthusiasm naivety brings, but with experience (ok, age).

It’s the infamous view state again. My my my. I knew there were reasons I really didn’t dig the complexity ASP.NET were trying to cover up. This time though, my sense of amazement reached new heights when the client browser crashed (yip-crashed) because the server picked up some dodgy view state. Read that again. Carefully.
Oh. And you probably might have already guessed which browser does the crashing. No prizes for getting it right, sorry. The correct and predictable, even appropriate response is: “The view state is invalid for this page and might be corrupted” which is what all the other browsers I’ve tested on so far show. On with the experiment…

We’ll start off with a simple ASPX page. Nothing complicated.

<html>
	<script language="C#" runat="server">
  public void Page_Load(Object sender, EventArgs E)
  {
  }

  public void Submit_Click(Object sender, EventArgs E)
  {
  }
	</script>
	<body>
		<form id="Form1" runat="server">
			<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
		</form>
	</body>
</html>

Click on the button and woohoo- no surprises. But now we add a little extra something. We modify the contents of the page after it’s loaded. Nothing special here either really. Standard AJAX behaviour.

<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
<div id="dynamic_content"></div>
<script type="text/javascript">
//<![CDATA[
  window.onload = get_dynamic_content;
  function get_dynamic_content() {
    //....
  }
//]]>
</script>

The JavaScript function get_dynamic_content() will make a request and then proceed to populate the div dynamic_content with some more HTML. The obvious solution is to do something along the lines of:

function get_dynamic_content() {
  document.getElementById('dynamic_content').innerHTML = '...some html...';
}

Incidentally, therein lies another rub in that div.innerHTML behaves differently for IE. Take a peek for yourself. And within all those comments, of this article, there lies a hack solution. You can read more about that debate there. Moving along.

So having hacked the little piece of innerHTML magic, you start populating your element with all sorts of dynamic content. Wonderful. Then during a series of development efforts, you get a buggy piece of HTML tagging along for the ride. A second form element- don’t worry, not a server-side form. More about why and why not here if you not too sure about how that fits into the scheme of things. Anyway, so you get an erroneous piece of HTML coming through- a valid bug in the development effort- and your second form contains an extra view state element. By now, you’ve also probably deciphered the design and architecture of this piece of handy work.

And i’ll recount here- this may be a valid bug, but it’s not about the bug. It’s the way the client browser handles a server-side bug.

So let’s assume that part of the payload (simplified) includes the following:

<form>
...
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" />
...
</form>

You click on Submit. Is this what you would be expecting?

Familiar Browser Crash

It’s not even bad HTML. In fact, if the dynamic payload didn’t include the extra form element, just the viewstate ala

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" />

You get the reasonable and correct behaviour. ASP.NET complains about the view state being fudged. Good. But wrap that extra view state input element in a form tag and IE client blows up. WTF? Incidentally, the form wrapper is arguably more correct.

Here’s the full code for your enjoyment. Modify the content variable and element type of dynamic_content and test across all your browsers.

<html>
	<script language="C#" runat="server">
  public void Page_Load(Object sender, EventArgs E)
  {
  }

  public void Submit_Click(Object sender, EventArgs E)
  {
  }
	</script>
	<body>
		<form id="Form1" runat="server">
			<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
			<div id="dynamic_content"></div>
      <script type="text/javascript">
      //<![CDATA[
        window.onload = get_dynamic_content;
        function get_dynamic_content() {
          var content = '<form><input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" /></form>';
          //document.getElementById('dynamic_content').innerHTML = content;
          swap_content_div(document.getElementById('dynamic_content'), content);
        }
        function swap_content_div(old_div, content) {
          someHtml = content;
          var newDiv = document.createElement(old_div.tagName);
          newDiv.id = old_div.id;
          newDiv.className = old_div.className;
          newDiv.innerHTML = someHtml;
          old_div.parentNode.replaceChild(newDiv, old_div);
        }
      //]]>
      </script>
		</form>
	</body>
</html>

The expression “software is hard” (a quote from Donald Knuth if I’m not mistaken) has seen a lot of mileage (yours truly contributing my fair share) over the years because of it’s simple truth. And in that, we’ve all searched and found (or not) some or other holy grail of methodology. And then the methodology wars began…

And with each new spin, a new skirmish emerged on the radar. Even some of the the tool-chain manufacturers got involved, either creating their own style or methodology (i suspect largely to suit their product rather than the process) or adopting their product to try and encompass the latest and greatest in fashionable methodology. Much ado.

Now software is both art and science. And as such, you need a healthy dose of both to get it right. The art demands your imagination and creative skills; the application of your emotional quotient and your ability to think beyond the four-sided. The science demands much the same plus discipline. Art, too, demands discipline (find me a great writer, painter, cartoonist, graffiti-artist, musician who did NOT practise and hone his/her ability each and every day- for hours each day). Art and science are much the same. Discipline is but one of the common threads.

Discipline to sit down each and every day, for hours, and get it right- get it perfect. That doesn’t mean just hours of random throwing paint at the canvas or the random plucking of guitar strings (which is my forte, by the by). And what about the scientist? Does she spend hours each day in the laboratory throwing random chemicals together into a test-tube to see what might happen? Maybe once in a while, that kind of activity is fun- but not a primary activity.

No. They all set themselves down each day, both scientist and artist, and constructively engage their brains, and think for themselves about what they are actually doing- or going to do. They know before the experiment or song or painting is completed- what to more or less expect. Sometimes it doesn’t turn out that way- and the results are either surprising or horrendous. Sound familiar? But by and large, it’s predictable- and it should be. Software is no different.

How you get there, and which methodology you use is largely irrelevant (i say largely, but you need to read the legal copy disclaimers in fine print carefully); as long as you have discipline. Following a set pattern so often that it becomes part of your autonomic nervous system is key. There’s good reason to do it, especially when you add in the one thing that distinguishes software: deadlines. Although, I am sure that in this day and age, professional artists and scientists suffer the same. Deadlines make the job more interesting- and the need for discipline even more critical.

A brief observation of any professional field where life and death are important will reveal the stand-out-in-your-face notion of REPEAT. In fact, it’s the only way we actually ever learn anything. You repeat the excercise over and over again (ad nauseum some might say) until you get it right blindfold. Why? Because when there’s a deadline, you go blind. And the more impossible the deadline, the more blind you become. You don’t have time to think- just time to do. And you need to make sure you are STILL doing it perfectly.

So, HOWTO Do Software. Pick a way. Find a way. Develop a style and method of delivery that embodies rational scientific reason to justify the “why” you do it that way. Don’t do something or end up doing something “just because it’s the way we do it” and not have a valid reason and purpose behind the behaviour (and I’m afraid if you don’t even recognise that, your opinionated delivery is just going to be that- opinionated). Add in your own artistic flair- but above all- be disciplined about it. Not just off beat, whacky, eccentric, random or out there. Notice i said “just”. Which means you can still be off beat, whacky, eccentric, random or out there- just be disciplined about it. Oh- and write quality tests

I stumbled across the Thrift framework not so long ago and have been intrigued ever since because of it’s promises. And it’s easy to fall in love with the marketing and promises of any framework when it tickles and uses the words and phrases you like to hear, not so?

So finally, I have the opportunity to test drive it: in a design that will become a product that will be released into production in the not so far future. So I want to make sure it’s ticking along as I would expect it to, especially if I want to test, implement, debug, deploy, maintain, scale and extend. And so far, i’m tres impressed.

On the server, I have the default Thrift server, Ruby flavoured, running on Mac OS X with a CSharp client on a Windows XP box (same LAN) and all with no extra tinkering; just as is, courtesy of the generator. Luverly stuff! And then, the implemented handler on the server uses ActiveRecord to handle the database lifting. No Rails: just Thrift and ActiveRecord. And it rocks (so far).

I’ll more than likely be documenting this implementation in more detail over time since the combination opens up many more opportunities in the space i love to work play in. And that’s including the spike project source code.

References and gratitude to the following authors/posts which assisted in getting this going:

• Slash Dot Slash
• nagarro
• agileadvisor
• ActiveRecord documentation
• And of course, Thrift

Morty py is the same Morty that was built using Ruby on Rails as part of a bigger scheme related to the basics of financial learning, specifically the concept of amortisation. Morty py, as it’s creative name suggests, is a Python implementation. Moreover, it’s also hosted on Google’s AppEngine.

In all, the differences between the frameworks and development experience are both varied and the same. It doesn’t really matter which is “better”- that discussion is a moot point. But in summary, i love the RoR implementation for it’s expressiveness in code and coherence of the MVC pattern. But Google’s AppEngine rocks when it comes to functionality and the tool chain. Performance (for this app) is much of a muchness. Python is really nice, and so is Ruby. Granted, getting to grips with Python was much easier, but that’s only because my multi-lingual skills have improved greatly. And being a multi-linguist is so much more satisfying.

Afterall, imagine, in one day, coding the backend in Python, some related services in Ruby, maybe an optimized service in C, with a front end in C#, possibly ASP.NET or WinForms, a mobile front end in Java and then some obligatory JavaScript to boot. Not forgetting the frameworks that come with each of those languages that make them ultimately productive. For me, seventh heaven

Maybe the guys at Nokia have different ideas about concepts such as “target market”, “market segmentation” or “target audience”?

Technocists? Really. This kind of thing should be outlawed. It’s the 21st century! But then again, the money votes always make the biggest difference. Bye, bye Nokia Music Store.