Saturday, January 22, 2011

Agile vs Waterfall

Recently I found myself coding less and “planning” more. It took me a while to work out why, and when I did I thought I would write this so that others may avoid the trap I was in.

Firstly, some background. As you may or may not be aware, I am writing an API in java for read an OData source.  Now, I am using TDD principals to code the API (basically write a test case and then write the code that makes this test pass).  This means that I need to think in small increments, write a test for the small increment, then write a small increment that satisfies that test, then write another test for another small increment, then write that small increment and so on,  you get the idea.

Now back to the present.  I encountered the next part of my code requirements, implementing XML namespaces within my code.  This is where my problems started.  I did the right thing by researching some things on XML namespaces, to make sure that I understood how they were implemented and make sure my code didn’t vastly differ what it should be.  Then I did the wrong thing, I tried to plan the entire implementation of the XML Namespace component, rather than looking at the small piece I was dealing with (in this case pulling the namespace and storing it in the required format).

I was planning the reading dtd and metafiles and how that would work.  Looking at the manner that dtd’s could be delivered.  How would I know which was an internal namespace and which was an external? How would I register the external namespace in my code (for example the $metadata of an OData source)? And so on and so forth.  That is not how I am wanting to write my code.  I want to write a test for a small part, then write that small part.  In this case the small part was identifying the namespaces and putting them into a useful format.

This got me thinking about agile and waterfall practices.  Agile methodologies would say that you get the requirement and break it down into smaller pieces, and those into smaller pieces until you have something that can be done in a defined period of time (for example, in scrum you would break it down into smaller pieces that would be done within an iteration).  Whilst you know what the requirements are, you don’t design the entire solution for what may or may not happen, nor do you plan everything out at the start.  You break the requirement into smaller chunks and that into smaller chunks into a requirement that you can complete within a week or 2.

Waterfall is very different to this.  In the waterfall approach, you define every requirement that you can think of, plan the end result to the finest detail, then you start coding to the fine details that you have planned to deliver.  You don't start coding until you have the UX defined, the web services documented and the classes worked out and what each class properties and methods are.

Now, without going into a discussion about waterfall vs agile development practices, I will say my thoughts.  While there are parts of one in the other and vice versa, the two can not coexist.  For example, when your doing agile you need to know the end result, what is the stakeholder asking for.  That you can break down into smaller requirements and so on until it is small enough to complete in iteration or sprint.  And conversely in waterfall development, you can not say “deliver the whole project at once”, you need to break it down into smaller chunks that a developer can work on.

The main point of difference for me is that in my opinion, agile is about meeting the requirements that you have been asked to deliver.  No more no less.  You cant tell the stake holder what they want, you can only guide them along as you code and as they see the work.  This doesn't mean that if they say they want a field you don't do any error checking on it, or that you just make it work and not deliver a quality product.  What it does mean is that you don't enlarge the requirements to what you can see being needed down the track.  You meet the current need. If the database table needs a title, description and timestamp, don't add a link to a status that is then part of a different requirement.  By the same token you can guide the requirements along by asking questions like “where is this going to be reported?”, “Is there a need to report on this?”, “ Who should be able to edit this?”

Waterfall projects on the other hand you can vastly change the requirements because you are part of the planning process.  Nothing gets done until everything is defined and some form of specification documented.  You research to make sure that it is future proof, so that you can work on another project and this one wont need any attention.  You tend to guide the requirements and specifications, rather than the development.  But, once it is locked in, it takes a lot to change one line of the specifications that your working to.

Personally, I prefer agile development processes over waterfall process because you can be flexible, if you code something that the user changes their mind on you can adapt. (Hence, why it is called agile.)  You also only deliver what is needed, not what you think is best.  The issue with stakeholders is that they don’t always communicate it well to developers, project managers or product owners.  Hence the need to ask questions and listen to the answers.  You also end up with leaner code (it does what is needed, and nothing it doesn't) rather than bloated code with parts that are rarely, if ever, used.

Sunday, January 16, 2011

BlackBerry DevCon

I had the opportunity to attend the BlackBerry DevCon Asia over the last few days in Bali. There was a lot there, but I thought I would share a few of the highlights for me. [Note: I’m a developer, not a reporter, so this is just my thoughts, not an article for a publication.

Playbook

There is a new tablet coming to the market called the BlackBerry Playbook.  Over the conference I had the opportunity to play with one and I must say I was very impressed. The graphics on the device look amazing, even with 3 rendering engines being used at the same time there is little discernable lag in playback in all three at the same time.  It has a 7” screen which might be a tad on the small, but works with the device.

Also, the OS is based on QNX which is a different approach to the other 2 main OS’s used on tablets, iOS for iPad and Android for other tablets.  I like this move because it keeps separate the tablet and the phone.  They might be similar, but to use the same OS is like using Windows XP as a server.  It can be done, but it isn't what it was designed to do.

My main criticism is that there is no bar along the top or bottom when your in an application.  For example,in the Android OS there is the top bar that has the time and notifications, an also has the ability to be pulled down to interact with those notifications.  This is missing in the device. Once you open an application the entire bar goes and the application is full screen. In some cases like games and remote desktop applications that is ideal, but most of the applications (not games) that I use leave that bar there.

Why is this important? Let me give you a real life example. I'm sitting down and turn on my playbook, I open twitter and my emails, then start composing a blog.  As there is no notification bar I cant see if I get any emails nor any twitter DM’s or mentions that I might want to have a look at.  To check, I have to go out of one app and into the other.  Today people are use to reviewing the notifications area to see if there is something that they need to deal with.  That said, that is basically my only criticism.  I think that this device will be one to watch as it gets closer to the release date.  The specs are changing, but the current specs can be found here.

SuperApps

This is an oldie but still one that was pushed heavily over the conference.  The idea is that the applications that you write are linked to the native operating system, contextual application menus (both location and from the apps point of view), and linking with other applications as well.  An example of this is a translating application.  As a normal app, this would be a notepad like application that you would open, type one language and then translate the text, then copy the text translation to the program that you want.

With super apps, you would create a menu item in your email application.  The user would then type the text of the email in their language, in the email program. Then the user would go to the menu, select the translation software (which might pop up a dialogue to ask which language to translate to), and it would do the translation for you and put the text in your email.

I guess a new part of this is that you can do this into third party apps.  For example, with the translation application, you could tell the OS that it should add the Translate contextual menu item for every text field it displays.  Then when your timesheet program fires up, every text box will be able to be translated to a different language.

WebWorks Programs

This one is rather interesting.  What this allows for is the ability for a developer to use HTML and javascript (including jQuery and some other third javascript api’s) to write an app, then the WebWorks API will bundle that into a native installable file.  It is hard to tell the difference between a Java based app and a WebWorks based app.  This, in my opinion, allows for speed of development to increase (its just HTML and javascript, which while tricky are not unique to any device, so debugging becomes easier).  Using AJAX you can perform client/server operations, and some native functionality has been exposed to the javascript API so that you can make your application run as though it were running like a Java based one.

There are 2 other things to note.  Firstly, the WebWorks environment will be on both the BlackBerry mobile phone OS’s (I think 5.0 and up, not sure about 4.6) and the PlayBook (along with Adobe Air).  The other is more exciting.  Using CSS and Javascript, you can write the one application and build one version for the PlayBook, and one version for the Phone OS, and the application will determine the which device you are using and allow you to customize the experience for each.  (Just like we do for different browsers at the moment.)   Yes, I guess that you would expect that from something based in HTML, but I still think it is exciting (and powerful) none the less.

HTML Debugging

A side note to this, you can also debug HTML in an browser on an emulated phone though Chrome or Firefox/Firebug dynamically on your desktop. Makes working out the odds and ends of the HTML issues easier to deal with.  This uses the WebKit engine on both to link them together.

These were just some of the things that I heard and saw that I think will be cool to use when you need to.  Look out for more information on that PlayBook, I think it has the capability to be a game changer for the tablet device market.

Saturday, January 8, 2011

Running a single test with JUnit and Eclipse

So, I had a slight problem with using TDD in Eclipse.  Not a problem as such, more an obstacle that I needed to overcome.  What I wanted to do was to write a test, get that working, then re-run all the tests, check that the changes to the code hadn’t caused another error to correct, then move on to the next test.  I found a few odds and ends about how this could be done, but nothing seemed to work.

After some looking and seeing I was able to get this working.  Here’s how I did it.  For this example, I am using JUnit 4 and Eclipse 3.6.1 (Helios).  Please note, to see the images more clearly just click on the image.

Firstly, go to Run –> Run Configurations

Then, right click the JUnit node in the tree and select New

Enter the name for the run configuration (I have called mine XMLSourceRepository_GetTokensTest)

Select the Method that you would like to test (default is all methods).

Now, I have Android JUnit and Eclipse JUnit launchers, so down the bottom I need to press the hyperlink and the following dialogue box appears. Select the Use Configuration specific settings and then Eclipse JUnit Launcher.

And your done.  Press the run button to run the test, and now it is in your run and debug button menus

So there you have it.  Using JUnit and Eclipse Helios (3.6.1) I have been able to select a single test to run without the overhead of other tests being run as well.

Now, to me, this is rather complex and time consuming if you write a test, change the run configurations to add or alter an existing configuration, make a few changes to change the code, then have to do the whole process again.  It would be easier be able to do this via the source or a test list of some kind.  I am not saying that this isn’t possible, but I couldn’t get it to work.  If you know how to do that, please let me know so that I can correct this post with the easier way of managing tests!

Sunday, January 2, 2011

Java Open Data Protocol API

Recently, I have played with Open Data Protocol (OData) using Java and I am not entirely happy with the API’s that I have had to use.  So, in true developer style I am going to attempt to write my own.  Have called it JOCU (Java OData Consuming Utility). I figure that by doing this I will learn the OData Protocol, touch up on my Java coding, practice TDD and JUnit, and maybe play with GIT or some other source control.

Open Data Protocol

Now for some understanding.  The Open Data Protocol was put together by various organisations to surface data in a consistent way that was manageable cross platform.  It allows for updating and retrieving of data to the data store via the URI conventions.  I wont go into it in detail cause I am likely to get it wrong, and that isn't the idea of this post.  For more information, go to http://www.odata.org/.

So, on with the show… my first hurtle

I have started the API and have already come across something worth noting down.  I had written a function to get the source code for a file, called GetSource.  The original code is below:

public String GetSource(String URIForSource) throws  MalformedURLException, IOException  {

URL url = new URL(URIForSource);
HttpURLConnection URLConn = (HttpURLConnection)url.openConnection();
BufferedReader in = new BufferedReader(new InputStreamReader(URLConn.getInputStream()));

String str;
String result = "";
while ((str = in.readLine()) != null)
result = result + str;
in.close();
return result;
}

Now for HTML files and for static XML files this is fine.  However, when you use this for an OData source, it dies (returns a 400 Bad Request error).  I then thought that there was something wrong with my URL so I copied it into a browser and it worked!  I was left with the question: why would the URL work in a browser yet not in code?  After some investigating, I found that I needed to identify the types of responses that I would accept.  As a result, I added one line to my code and came up with the below:

public String GetSource(String URIForSource) throws  MalformedURLException, IOException  {

URL url = new URL(URIForSource);
HttpURLConnection URLConn = (HttpURLConnection)url.openConnection();
URLConn.setRequestProperty("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
BufferedReader in = new BufferedReader(new InputStreamReader(URLConn.getInputStream()));

String str;
String result = "";
while ((str = in.readLine()) != null)
result = result + str;
in.close();
return result;
}

As you can see in line 5, I set the connection to accept xml, along with other types that I needn’t go into.  As a result, the code is now working perfectly (under what tests I have written to date that is).


Next is to manage the tokens that the XML returns.