Product Development in Brisbane

Archive for the ‘Development’ Category

Example of a Good Open Source Project Website

Wednesday, June 13th, 2007

Open Source projects are known for dodgy websites, and rubbish documentation. I was overjoyed to see a project that got it right (URL Rewrite Filter). There are a number of things that I really appreciated with this site, and in the hope that people might take notice, I’m going to list the good bits here.

The landing home page has a nice concise description of what the project is all about. When I get to the front page, I can read the overview of the project, and get an understanding of what problems it was created for, and the goals of it. The front page told me enough to want to see more, but didn’t overwhelm me. I got a good feeling from the front page.

The other nice thing about the front page is the navigation structure. The side navigation bar provides the links which I am most interested in. One click to get to a download link (which has a direct link to the files). One click to the source code page (with instructions on svn access via http and the commandline). One click to the documentation. One click to get to the community support.

The documentation is excellent, and provides a good baseline for what documentation of a project this size should look like.

There are good examples of what the configuration file looks like, annotated in a way that makes it easy to understand what the code is there for.

The documentation provides a good reference for how to do the configuration.

It is a great site and provides a good example of what most open source project websites should look like.

Pretty URLs for any J2EE framework

Wednesday, June 13th, 2007

Making the browser location work like a command prompt is a good goal for any web application, and is possible for any J2EE web framework, even Struts 1.

To do this, having Rails style friendly urls is required. Traditionally J2EE frameworks and applications have not done a good job of providing friendly urls. It is easy to wander around the net and guess at what framework people used by the urls (e.g. anything .do is probably struts, .action’s are probably webwork etc.)

Of course one doesn’t have to be tied to this world. Pretty much anything is possible with Apache and mod-rewrite. This is handy when you are behind Apache, but that isn’t always the case. From time-to-time you may want to dot his completely within your J2EE application, making it independant of where you are running. The Servlet spec is powerful enough to make this possible, but for the lazy (like me) it is nice to know that someone has already done the hard work. The URL Rewrite library provides a filter which does the heavy lifting for you. There is a simple XML configuration file, which provides a rich language for customising your redirects using the Java Regex library, or a familiar directory traversal wildcard style syntax.

The library makes it possible to easily map urls like: products/1 to products.do?productId=1 or from: /australia/queensland/brisbane to: worldMap.jspa?country=australia&state=queensland&city=brisbane. There is a rich syntax for specifying the url rewrite conditions, as described in the comprehensive manual, and shown in the samples.

Advice to an XP Customer

Thursday, June 7th, 2007

I have been working hard at developing an understanding of what it means to be a product manager how to do this.  A part of the role has been to step in as an XP customer.  Recently I had a great IM conversation with Dan North about what the role is all about, and how to best do the job.  Dan was my XP coach when I was working on a project in London, is the father of BDD, one of the lead developers behind JBehave, and RBehave and an all round great guy.

Here are some of the highlights of what Dan had to say:

Focus on your outcomes.

Work out what it is you want to achieve, and how much you think that's worth.

Everything else is detail. If the project goes "over budget", it just means you didn't predict the future. As long as you're within your comfort zone for the benefit you're going to get then you're still ok.

Likewise the feature list is just detail as long as you and the development team are on the same page

The most useful thing you can do is inspire the developers with your vision.  Ideally find a way of sharing any success, so they feel vested in the outcome

Try to stay focused on the "what". As a techie, you will be really tempted to get involved in the "how",but you have to trust the team to do the right thing. Once you let go of the technical detail you can really get into "character" as a product manager!

Good Management

Sunday, June 3rd, 2007

Warning: if you are looking for an angry rant you won't find it here, instead this is a article about a truly good manager.

Like most people who have been in IT for as long as me, I’ve worked with some pretty dodgy management over the years. There have been times where I was sure Scott Adams was sitting in my cube farm, stealing ideas for dilbert.

I came to Ephox knowing that this wouldn’t be the case. I came knowing that I was going to be working for a good manager, Brett. Brett takes management, leadership and people seriously, as you can see in his recent blog post about a leadership course he is attending. Here he talks about what he has been learning about management and leadership, and how much he already understands and implements. You may read it, and think that he is perhaps self-deluded, but as someone who has been working for Brett, I can vouch for the fact that this isn't the case. Brett really does get people management. He understands the importance of putting people over process, and it makes a huge difference. It is his valuing of people that played a key part of my wanting to come to Ephox in the first place, and makes being a part of his team great.

Another thing that Brett does well is keeping commitments. In a recent InfoQ article on agile, there was the quote: ”…one of the quickest ways to take the wind out of a person’s sails is to break a commitment…”

I can’t think of a single commitment that Brett hasn't worked really hard to keep. He does well at making the right commitments, and sticking by them. One real instance of this that really sticks out in my mind was when I was nearing the end of my time in support. I could see that there might be value in me holding off transitioning (and I was willing to do so), but Brett stuck with his word, and made sure that I was able to transfer to development. It was great that Brett put in the work to ensure that this happened, and this commitment help keep my motivation high.

Brett spent time working on his management skills, and I really think this investment has paid off. Brett does really well at leading his team of developers, and creating an environment where we want to be. Having a good engineering manager is going to be a key part of helping Ephox to grow, enabling us to hire and keep good engineers.

Memory Constipation (not memory leaks)

Monday, April 30th, 2007

This post is the first in a series of efforts to clean up my list of drafts.  This particular post is probably about a year old.  It is somewhat fitting that it is the first in my effort to clean out my drafts ;).  Before making each post in this series I'll edit the post to clean it up, and add new comments in italics, or footnotes).

I often spend time talking about different things with my wife, Suzanne. We both like learning, and sharing from our different experiences (in fact I'd almost call Suzanne a compulsive learner). 

I was recently struggling with an application with memory leaks1. When explaining this to Suzanne (who is currently working in a hospital setting treating a lot of kids with enuresis and encopresis)2, she pointed out that it is probably more of a case of memory constipation.

Especially in an environment with Garbage collection. The issue is that the rubbish ain’t getting out of the system.

1 - That was two years ago, in a Swing fat client.  Two years later at Ephox we getting OutOfMemoryExceptions in Java Applets

2 - actually now she is a full time Mum, and doing some Enjo demos on the side.

 

Emergence

Thursday, April 26th, 2007

I picked up a copy of the book Emergence a month or so ago while browsing a local bookstore.  It's about emergent behavior, and complexity theory, not (as my wife seems to think every time I mention the title) about coming out of the closet.

I've found it to be quite interesting read, filling in many of my missing bits of understanding around the world of complex systems.  I've read about it before, spending a fair amount of time at QUT working with a guy who is doing alot of work in Security Risk Simulation and modelling in complex systems.

It's interesting because Computers on their own are becoming increasingly complex.  I'm not going to say that a web application is a complex system, but the interactions between browsers, operation systems and JVM's does seem to cause behavior which is at least approaching emergence.

Thinking in these terms can be useful when doing bug-fixing.  The bizarre side effects and bugs that can happen in different configurations can be thought of emergent behavior, removing some of the blaming that can happen.  So perhaps sometimes the bugs aren't Sun's/Microsoft's/Mozilla's fault, rather behavior that has emerged from the way in which the agents (browse/operating system/jvm) have interacted.

This then makes bug fixing  a case of preventing agents from getting into situations that cause the bad behavior to happen.

Some of the interesting examples are the ant colony studies, which have shown how the ants interact to create the behavior which is like the ants are all working under a centralized controller.  Long term studies of the ant colonies show the colony displaying properties which are greater than any one ant does. Basically the idea is that the collective behavior is not controlled centrally. This type of reasoning is often used to remove the need for a creator/God figure in control of things.

People who make these statements normally skip over the fact of the need for the initial behaviors to be initialized in the first place.  While these behaviors are relatively simple, each ant does still have some quite intricate (almost designed) rules that are being used.

As the book says of a computer simulation of emergent systems (specifically talking about modelling the behaviour of slime cells), "Of course, on the most fundamental level, StarLogo is itself a centralized system: it obeys rules laid down by a single authority — the programmer.  But the route from Resnick's code to those slime mold clusters is indirect.  You don't program the slime mold cells to form clusters; you program them to follow patterns in the rails left behind by their neighbors.  If you have enough cells, and if the trails last long enough, you'll get clusters, but they're not something you can control directly.  And predicting the number of clusters — or their longevity — is almost impossible without extensize trial-and-error experimentation with the system." and continues "Systems like StarLogo are not utter anarchies: they obey rules that we define in advance, but those rules only govern the micromotives.  The macrobehavior is another matter."

This matches my current view of the world.  I don't think that emergent behavior acts to prove or deny the existence of a creator.  It would be possible to match most (if not all) belief systems with Emergence, which for me means that I am happily able to be a Christian and someone who uses and applies the principles and lessons from emergent behavior throughout my life, especially while coding.

Minor Updates

After gentle feedback from Suzanne (OK so she laughed at me, not with me), I've made some minor updates to the wording above, to improve the readability.

Five things I learnt about Javascript this month

Monday, April 23rd, 2007

In the past month at Ephox, we have been doing some heavy JavaScript (in this article JavaScript == ECMAScript 3.0) work, the effects of which will be seen in the next release of EditLive! I’ve learnt a bunch of new things, and thanks to a nice internal Continuous Learning seminar by AJ, much of the background theory has gelled for me.

1. this is the current object at execution time (think python and self).

An almost obvious statement which doesn’t really suprise initially. Java guys will look at that and be thinking, so what. It gets more fun when you think about the dynamic nature of java script and that you can assign functions as variables and pass them around as a reference. Assigning variables to objects is possible, and allows the dyanmic definition of behaviour.

This all becomes important when you are assigning functions to variables for reuse. For example if you are to override a funtion, and keep the original for later use, you need to be careful not to loose the context.

So if you override the onsubmit handler of a form, but want to keep the original onsubmit handler around you might want to do seomthing like this:

 form.originalOnSubmit=form.onSubmit;
 form.onSubmit=newSubmissionFunctionThatCallsOriginalSubmissionFunction;

2. Function is a way of creating a function object—pass in a string, get a function out.

Pretty much as expected: 

myFunction = new Function(“arg1", "arg2" "{alert(arg1 +arg2);}”);

That will create a function with arguments arg1 and arg2, and will raise an alert with arg1+arg2.

For more details see here.

3. eval evaluates a string as javascript

yep it does

See here

4. prototype is the way that Objects are created in javascript.

JavaScript is a prototype based language. A  prototype function is specified by the following syntax:

MyObject.proptoype.myFunction = function(arg){
 //javascript function
}

see here for more info.

5. innerHTML rationalises the content being set

Browsers will parse the contents of the text being set via innerHTML, which will cause the contents to be changed in various minor ways. For example comments in the middle of attributes will be escaped.

There is much to learn about Javascript, and the above are a couple of the bits that I have learnt recently. 

Update:

As Tom has pointed out in the comments, be careful with the Python/JavaScript analogy.  Python binds the self early, so the analogy falls in a heap early on.

Ruby File Generation

Monday, April 9th, 2007

Join me on a journey through using ruby to generate java, learning how to use the built in ruby templating tool erb, and some of the rubyish techniques that erb leverages.

 Our adventure starts with a need to generate a large number of very simple java classes in order to have a nice simple test case for the boys at sun.  The requirements for the classes are:

  1. they are some how different
  2. it is easy to tell when each class is loaded by the class loader
  3. it is easy to tell when each class is instantiated

These requirements would be painful to meet (when creating 1000+ classes) even in the most powerful java IDE.  An automated technique for generating code.  In steps Ruby and erb.

A basic ruby script which has a simple template to base the files on, and creates the java classes.

require 'erb' #we are using the erb library.

# create an erb template using the multiline string starting after EOF,
# and finishing at the EOF below.
template=ERB.new <<EOF
package
ephox; 

public class SimpleClass<%=class_number%> {
    static {
        System.out.println("static SimpleClass<%=class_number%>");
    }
    public SimpleClass<%=class_number%>() {
        super();
        System.out.println("init SimpleClass<%=class_number%>");
    }
}
 

EOF

5.times do |counter| # perform code in this loop five times, remembering the counter.
    class_number=counter+1
    File.open "src/ephox/SimpleClass#{class_number}.java" ,'w' do |file|

         # open the file for writing.
        file.puts template.result(binding)

                   #merge the template into the file, passing in the current binding.
    end
end

 

In looking back over the example, you can see some interesting rubyisms.  These are some of the spots where ruby is revealed. Note the following:

  • the use of closures (File.open, and 5.times),
  • everything really is an object (the method times being called on the object literal 5),
  • heredoc notation (<<EOF )
  • the ease of templating with erb (which keeps normal ruby syntax in the template),

The statement I made above about everything being an object is pushed to its limits when looking at the method call: template.result(binding).  The binding method is available as a part of the Kernel, a mixin(providing methods for use) that is a part of Object, the mighty superclass of everything in Ruby.  This method will return a Binding object, which erb uses to get data to merge into the template.

The File.open line opens a file in write mode, overriding the contents of the file.  For more examples of how to do this, look at the PLEAC site, which has a good set of ruby file examples, and quite a complete set of ruby examples.  This is an excellent resource for learning a language.

In all, Ruby does a good job of working with files, and templating.  Erb is a great tool for templating, and forms the backbone of many well known ruby programs.

Dreyfus Model of Skill Acquisition At Ephox

Thursday, March 29th, 2007

I recently read PragDave's blog talking about the Dreyfus model of skill acquisition. As I am generally interested in going back to first principles, I went to the library and borrowed the book From Novice to Expert: Excellence and Power in Clinical Nursing Practice, which Dave cites. It makes for an interesting read discussing the way in which expert nurses use a mixture of intuition, and observations to come to conclusions, and to guide their treatment of patients.

The book presents the research of Dreyfus into learning, and the five stage progression of learning from Beginner to Advanced used in the Dreyfus model (Orginally mentioned in a 1980 paper by Dreyfus and ,Dreyfus ). 

  • Novice/Advanced Beginner (Advanced Beginner was added in From Novice to Expert), 
  • Competent, 
  • Proficient, 
  • Expert, and 
  • Master (not listed in From Novice to Expert), this is a state that experts enter into from time to time.

It has been obvserved that people display different performance characteristics (especially problem solving techniques) at each level. Novices use basic rules, and often struggle in working out how to best apply the rules to a situation, where as Experts often use a strong sense of intuition gained through experience to guide what they do. The concept is that as one gains more mastery in a skill, they are increasing in their ability to apply abstract rules to concrete situations.

While reading about these levels, I have been trying to apply them to Software Development, and my understanding of myself and the situation I am in currently (of course I am not the first to do so). The Dreyfus model is not the most cutting edge, and a search of http://scholar.google.com will show much of the controversy about this. It does, however, seem to work for me, and has been useful in helping me understand myself and the world.

In self-reflection, I know that I would consider myself as at least nearing the expert status in some areas of software development (particularly in web development). I will often move in an intuitive way when building new features in a test driven way.

I would also see myself as being pretty close to being an expert in the use of IntelliJ. It is a great IDE that I can now intuitively use to navigate through code, write code, and improve code.

When it comes to the Ephox EditLive! codebase, however, I am painfully aware of the fact that I am not an Expert. At best I would approach a degree of being proficient, and this is mainly based on my experience in other areas.

There are probably two main reasons for my not firing on all cylenders currently. We are using Eclipse (I know that it is much closer to IntelliJ than in the past, but I am not yet thriving in this environment) I am still learning the Ephox codebase, and the specifics of this environment. Just as nurses need to adopt to different clinical environments, I am having to adapt to the EditLive! codebase, and the domain of Applet based html editing.

AJ is currently the true expert in the EditLive! codebase. He has been around while most of the code was written, has a strong sense for where the pain points are, particularly in some of the libraries we are dependant on. When working out a solution to a problem he will often use his intuition to guide where he is going with his analysis.

There is more to the Dreyfus model than a way of categorising people. There are some interesting implications for the learning strategies that people should try and apply based on what stage of proficiency they currently are at. The ways in which a beginner moves on to being a novice are very different to what will help a proficient person move on to being an expert. The general learning techniques are:

  • Novices and Advanced Beginners need to learn the basic rules, and be given feedback to help bring behaviour into conformance with the rules. In IT, Pair Programming is a great technique for this.

     Interestingly the Dreyfus article talks about a compentent person being able to the perceive the meaning phrases or aspects — such as a pilot talking about "verging on stall conditions" — and being able to respond to these aspects following guidelines. This seems to dovetail nicely in with the ideas of the pattern movement. So perhaps the advanced beginner should start learning some basic patterns. 

  • Competent people benefit from simulations that help them further develop their application techniques. Being able to apply the patterns that they have learnt, and through the use of simulations know how to apply them.
  • Proficient people learn best through case studies.
  • Experts will also learn through their experience, and continue to learn and develop their understanding, occasionally entering the state of Mastery.

I am going to be taking some of the lessons learnt form the Dreyfus model, trying to create situations where I can learn in appropriate ways. As I would see myself as at least nearing the proficient stage, I will be pushing myself towards learning through the use of case studies. For the work at Ephox this will involve questions like:

  • How did you isolate and fix a particular bug? 
  • Talk to me about the integration with Alfresco.
  •  What did you learn through adding "Track Changes" support in the editor?

I believe this will be the best type of learning for me to be doing, and the fastest way for me to move on to a better standard of performance.

Another application point is in documentation. We have a rich Advanced API, with a decent volume of documentation, but it doesn't always make it easy for people to know how to use it.  The advanced Java Developer would be looking for the examples of how to use the EditLive! API.

A final application point I wonder about is the use of the "Guideline for Reporting Critical Incidents" to help gather good case studies for developers to work with.

The Dreyfus Model of learning is a useful tool for software developers, and I think we should try and use these techniques to work towards being better developers of software.

InvoicePlace.com

Thursday, March 22nd, 2007

I was pleasantly surprised to see a blog entry pop up in my feed reader mentioning subscription accounts for InvoicePlace. As I was one of the guys who helped write the code that is behind InvoicePlace (using a Java Web stack), I take pride in seeing it move closer to being a great success. InvoicePlace provides a great, simple, easy to use tool to help enter and keep track of invoices. It works really well for people and businesses send invoices, and want to be able to manage these electronically.

I've been sipping the InvoicePlace Champagne for quite a while now (it tastes much better than dog food), starting to use InvoicePlace to bill Growthbase before the name InvoicePlace had formed more than a glimmer in Scott's eye. I found InvoicePlace really useful, and expect that it will continue to grow and evolve in positive ways. Some of the features that I was able to exploit to help manage my invoicing needs in my development version were nice, and I expect that in due time they will be released and made available to the public.

I definitely have fond memories of my time working on the project, and the late nights spent adding functionality, and working hard at trying to push the test coverage and quality up. I look forward to following the continuing progress of InvoicePlace, and will use this site whenever I need to issue invoices.