ALTERthought Blogs Archives: Articles
next page ·
18 September 2009
Grails and Cloud Computing: Part 1 – Amazon EC2
Progress to Date
This entry is a part of the ‘What can you build in 40hrs‘ series– which, in a nutshell, involved an experiment to see what we could build in about typical weeks worth of work. In the last post we effectively completed the basic functional requirements of the application, and now have a [...]
continue reading... » 9 Comments
3 September 2009
Grails App in ~40 hrs (part 5)
Welcome back to our effort to build a Grails app in less than a week. This post will cover the final functional aspects of the application, after which we can move on to trying to deploy the app into a Cloud Computing platform.
To recap briefly our progress to date:
Part 1: We introduce the basic [...]
continue reading... » 10 Comments
17 August 2009
Grails App in ~40 hrs (part 4)
The last post covered the kickoff to the ‘twodo‘ application– where we created our Grails application, wired in JSecurity via plugin, and created a few of the core Domain objects the system will need.
In this post we will refine the general look and feel of the User Interface, as well as start building the core [...]
continue reading... » 5 Comments
10 August 2009
Building a Grails App in ~40 hrs (part 3)
In part 1 and part 2 of this series we introduced a challenge to build a reasonably non-trivial application in just a week. We have decided on Grails as the primary technology framework, and once we have a prototype working, we hope to deploy it to a cloud computing platform like Google’s AppEngine [...]
continue reading... » 7 Comments
3 August 2009
Building A Grails App in 40 hrs
In a prior post, I talked about an experiment — to build a working task management application in about 40 hours.
The high-level constraints governing the experiment were as follows:
The application should be web-based and ‘modern’ (AJAX, friendly URL’s, etc)
It should be reasonably non-trivial.
It should be developed as it were going to someday become a Software [...]
continue reading... » 9 Comments
15 July 2009
Beyond velocity: issue metrics
Continuing our series on beefing up the Agile dashboard with ‘leading indicator’ type metrics, let’s discuss project issues. First, let’s get on the same page on the definition. A good way to understand the definition of an issue is to compare to that of a risk. So, what’s the difference between and issue and a [...]
continue reading... » 2 Comments
7 July 2009
What can you build in ~40 hours?
My biz partner and I were relaxing over a few beers the other week and discussing recent trends in software development, agile methodology, etc (and our use of these trends over the past 7-10 years). At some point in time, we started talking about how little time 40 hours (i.e., a ‘typical’ work week) really [...]
continue reading... » 3 Comments
7 July 2009
Genius in small things and the pruning of mail …
Admission: I’m over thinking the release of a new Gmail feature, but I’m thinking its genius (little ‘g’). Given our experience with interactive transaction businesses on the Web (gaming, search, on-line advertising, etc.), I can sort of theorize with imaginary whiteboards and obligatory what-ifs, the benefit of said feature. And, I can see the practical [...]
continue reading... » 0 Comments
19 June 2009
Velocity (plus, plus) – Beefing up the Agile dashboard
First of all, how in the world did I temporarily forget how to spell out the ‘+’ symbol? It ‘looked’ correct with two s’s; sad, really. Earlier, I hinted at some other measures to add as _support_ to the Agile toolkit . To be clear, the raw measure that matters the most when it comes [...]
continue reading... » 26 Comments
16 June 2009
Velocity is not enough, expand the Agile dashboard …
So, one of the most powerful tools in the Agile Project Management Manifesto is the concept of velocity (and burn charts). Fundamentally, what you’re measuring is what your team is accomplishing over what it planned to accomplish. While this is a terrifically succinct and clarifying — and indeed the bottom line — with regard to [...]
