Archive for programming
Awesome tools for rapid UX prototypes – Letting you focus on the solution!
June 18th, 2009 • 3 comments Internet, agile, gtd, portal, programming, software development
Comic Life is great for creating story flows in a rough and ready way, with a little style.
Balsamiq is an excellent tool for rapidly creating purposefully low-fi wireframe mockups
Napkee enables you to import Balsamiq mockups and turn them into HTML prototypes! Lovely!
Axure is excellent for rapidly creating interactive prototypes.
Liferay Portal is a pretty awesome portlet container that, with a bit of UX (HTML, CSS and JSP) hacking, enables you to rapidly produce fully functional portals. It comes with a vast array of portlets out of the box, saving you a whole load of time.
JQueryUI is a lovely toolkit for quickly developing interactive prototypes. I’m not completely convinced by it as a production tool (heavy JS? but i could be wrong), but excellent for prototyping
Important iPhone Push Notification consideration
April 16th, 2009 • Apple, Business, Internet, Objective C, iPhone, programming, software development
Tags: linkedin
A point worth noting by all iPhone developers considering the exciting opportunities of cloud-side iPhone app notifications – how much will it cost you to provide this service?
An important point to consider.
Presenting BDD Story-driven delivery to project and account managers
April 15th, 2009 • agile, bdd, dsl, programming
Tags: linkedin
Today, i had the true pleasure of presenting my view of how BDD stories offer real business value to project delivery, quality and to the lives of everyone on a software delivery project.
Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)
It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.
What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.
Part 2: Clarify what documents are written and the associated risks and costs
When the whiteboard was complete, I asked the attendees to consider a number of things:
- At what points during the process are documents produced and by who?
- Of those documents produced, which are directly focused on the business and user requirements?
- Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
- Of the many documents produced, which were open to interpretation and translation?
- What are the perceived risks of having so many documents and periods of documentation translation?
When this work was complete, a few points became clear to the group:
- The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
- Interactions between actors were mostly through written documents
- Few actors following this project process retained a direct focus on the business and end user requirements
- A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
- Vast amounts of document interpretation and translation was going on to produce each document
Part 3: Consider stories
After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:
- I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
- I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
- I then came in with the ace
Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!
It was an awesome session. A lot was discussed and understood.
Hudson, Sonar & Ruby: Continuous integration of a Rails app
April 15th, 2009 • 2 comments agile, programming, subversion, version control
Tags: linkedin
I’m currently playing (well battling at times – VMWare can be an arse at times – or maybe i’ve been away for too long) with plugging a rails app into Hudson and Sonar.
My intention is to have the Rails app on a separate server from the Hudson server and have the Rails app return Hudson-friendly XML from RSpec and Cucumber tests. When i get this to work, it’ll enable me to roll this out at work, with a central Hudson server (perhaps) that interacts with multiple app servers of various technologies and, along with the wonders of Sonar, gives a view into code test coverage, pass rate and complexity. I feel that i might struggle convincing Sonar to play with Ruby, but we’ll see.
Why Hudson?
To be completely honest, at work, i didn’t make that decision and am yet to chase down exactly why it was chosen over CruiseControl, but I completely trust those that made the decision on their project. I’m a big believer in standardising and am as such following suit and trying out Hudson.
Furthering the quest to *get* agile
April 15th, 2009 • 1 comment Productivity, Uncategorized, agile, programming
Tags: linkedin
My academic learning focus has been a bit off recently, what with the amount of work i’ve had on. But, no excuses – my quest to grasp the academic history of agile delivery is taking steps forward, with my digging into DSDM. I’ve decided to focus on DSDM due to its UK-centricity, which I feel will have the greatest short term impact. I’ll get to SCRUM, XP, RUP, et al when i get to them.
I started the quest ages ago and have progressed it, but more in practice than in reading. Now’s the time for the reading to pick up again…