Jiggy Pete says

Charity Work

2011-03-03T01:35:00.000-08:00

As most of you will know myself and five friends are raising funds for Maggie's Centres as well as training for their Bike'n'Hike event.

From the Maggies webite
What is a Maggie's Centre?
A Maggie’s Centre is a place to turn to for help with any of the problems, small or large, associated with cancer.

One in three people are affected by cancer, that is a terrifying ratio. Having visited the Glasgow Centre it is clear how incredibly important this charity is to people at a harrowing time in their life.

So what do I intend to do to help raise funds I hear you ask?
I am offering my services as an Agile Coach and Developer to anyone who is willing to donate £500 or more per day to Maggies Cancer Centres.

What do you get for your donation over and above a warm fuzzy feeling for helping out a much in need charity?
Presumably the overarching goal for your company is that I can help your team make more ( or save more ) money faster.

How can I help achieve that with your software development team?
* Introduce Agile Techniques and the values of Communication, Feedback, Simplicity and Courage.
* Aid improvement of the teams current process
* Pair up with developers to improve technical skills like Acceptance Testing, TDD, and Refactoring.

I have added a section about my experience to date below. If it sounds like I could be of benefit to your company or development team why not get in touch and make me an offer?

In summary, I am offering my services for a period of up to 5 days to help your team or develop software. Ideally this would be in early April, and for each day onsite you would donate at least £500 to Maggies Centres via http://justgiving.com/jiggypete

The types of technology that I am most familiar with are Ruby, Rails and Java.
If you have any questions please do get in touch, this is all for a very good cause.

You can contact me via any of these methods,
Email: jiggypete at gmail .com
Twitter: @jiggy_pete
Website: jiggypete.com

My Experience:
For 10 years I have been working in XP teams and have been heavily involved with the Scottish Agile community.
The types of applications I have worked on are,
* Tools to create Blu-ray discs,
* Multi-million pound trading applications,
* Pension apps,
* Tools to allow bus drivers to submit timesheets
* and applications that run a repair line,

Thankyou for your time,
Peter Aitken

Mabies Aye

2010-10-18T03:55:00.000-07:00

For the last few weeks I've had a bit of extra time on my hands which I've been trying to put to good use by going out to play on my bike. Fun as it sounds there is a more serious reason for getting out on the bike more, six of us have signed up to participate in Maggies Monster Bike'n'Hike at the end of April 2011.

What does that involved?
A 30 mile bike ride plus one of an 8, 22 or 43 mile hike.
If you are feeling generous feel free to donate/sponsor our team at http://justgiving.com/jiggypete

See why I need to get some training underway?

Having got out for a number of runs round the Carron Valley and the Lochgoin Circuit at Whitelee Windfarm the odd bit of wear and tear appeared on the bike. The folks at Wheelcraft were a great help sorting my gears, brakes and chain.

Big Al and the guys were all friendly, helpful and incredibly knowledgable on everything bike related, I can't recommend them enough.

Prior to taking on something a bit more challenging I had a niggling concern. Ross, one of my biking buddies, had a bit of a crash landing at 25mph when going round the Carron Valley. He had pains in his wrists, elbows and previously broken ribs despite wearing a cosy piece of 661 body armour. If I was going to venture into something braver/stupider it seemed like a good time to pick up some body armour.

That was purchased on Saturday just in time for Sundays trip to the Mabie Forest!

Finally Sunday arrived and it was time to get the bike into the car, pick up Ross and head to Mabie.
An hour and a half later we arrived, got changed, put the bikes together and found the rest of the group all ready to take on one of the 7Stanes red routes.

20 meters from the car and the chain snapped. What a start.
5 minutes later and we're ready to go again.

The first section of the red route is the Butterhole Climb. It is well named and not the easy start I was hoping for. The downhill section is very lumpy and bumpy. You could easily loose some inner tubes on this section ( infact all of the forest ). Only one part caught me out where I was nearly over the handlebars.

The Countour Climb seemed a lot easier going, with a easy going firetrack leading to it....be careful of the little bridge with a tree root at the far side. It's a small manageable jump so get that front wheel up but it can cause a bit of a hold up on the route with riders stopping to push their bike over it. This section gets a bit harder towards the end again getting a bit steep for my legs and lungs.

Once at the top you enter the Descender Bender which has replaced a technical park. It's full of fast tight berms which is great fun!

Then we made it to Stan's Pond. Lots of nice tight single track through the forest. This is where I broke in the body armour over compensating when coming out of a berm and off I came.
Sure I've left a hole in the ground where I landed. The right shoulder took the brunt of the fall, just like the other crash that landed me in hospital a few years back. Fortunately the shoulders and elbows were protected by the armour so it was a case of getting up, catching my breath and climbing back on the bike.

The Scorpion, I have no idea why it is called The Scorpion. It doesn't matter what they call it, this section has the biggest, steepest climb of the red route. If you don't get off to push up this section I'd be astonished!

The Roller Coaster was the last part of the red route we took on. Any climb by this part of the day was getting done on foot, I was spent. The uphills weren't that steep but still beyond my fitness. Lots of nice rolling sections finished off with a pretty high drop off - be warned you'll need a bit of speed, if you're spent go round it.

Too finish off the day we followed a blue track back to the car park.

Phew, it was really hard going and great fun flying about the place particularly when on the bike.
Should be easier next time!
Wooo

Call to arms: Ban Case / Switch statements

2009-12-08T14:50:00.000-08:00

Of late I've been keeping up with the Hashrocket bookclub which is streamed on Tuesday evenings at 5.12pm GMT. Each week the folks discuss a chapter or two of the current book Refactoring: Ruby Edition

I noticed there was a running theme through a number of the 'Organising Data' refactorings which was removing case statements.

I've been at this coding game for about a decade now and I've only seen what I would call one valid use of a case statement. Every other use benefitted from being replaced by polymorphism.

With that in mind I'd like to see the case and switch keywords removed from all OO languages as it actively encourages poor design and less flexible code.

Any language designers out there reading?
The one case I mentioned above where a switch was useful could easily be replaced by an if, else if condition. Save yourself the hassle of implementing case or switch.

Girls and Mocks

2009-07-09T01:48:00.000-07:00

They both have expectations, high exepctations.
If their demands are not met they throw a fit until they get what they want.

How else can this be described?
'Childish' yes but that hardly fits with the analogy, how about 'High Maintenance'.

"Peter what should you do to solve the problem?"
Easy, avoid high maintenance girls/mocks.

Peters final thought: Don't completely close your mind to girls/mocks as they can be useful in the appropriate situation :o)

Mac Gem Jip

2009-04-15T13:27:00.000-07:00

I'm a bit of a newbie to Macs and finally took the plunge a few months back. The day job is still on a windows box to keep inline with the rest of the team so there hasn't been much Mac playtime.

The last few days I started to put together a presentation for Agile Scotland with coded examples and that is where I hit the wall - running the code.

Background to the problem:

About six months back I was poking at rspec and cucumber to get a feel for them. For my presentation I wanted to have the latest and greatest version of rails, rspec and cucumber available on my Mac.

When trying to run features for cucumber 0.3.0 it was expecting rspec 1.2.2 to be in place, which it was, however the rails environment had already picked up rspec 1.2.4. For the life of me I couldn't find out what where rspec 1.2.4 was being fetched. I decided to uninstall the rspec 1.2.4 leaving only one version in place and hopefully solving the problem. All looked good until you run

gem list

and there it is, still sitting there refusing to budge no matter how many gem uninstalls are run: rspec 1.2.4

What was wrong:

After much running around the short story is there are three places gems are stored. Depending on how you install the gems affects where the gems are stored and I managed to muddle them. Thanks to Jason Tennier post which helps explains where I went astray.

How easy is it to validate the format of an email address

2008-12-05T10:25:00.000-08:00

The other day I had to create an admin console for creating a user object which contained the usual fields,

username
forename
surename
email

etc.

When it came to setting up the active record object to ensure that the username, forename and surname are supplied I started spec'ing the behaviour. All was moving along well.

When it came to validating the format of the email address I realised this was something I'd not done this before. Off the top of my head an email address must

include only one '@'
not include spaces

There must be a lot more to it than that.
With a bit of help from google I found there was a helpful standard that specified exactly what is a valid email address. All of a sudden my nice task of creating a scaffold for a user object had grown to include 'implementing validation for email addresses' which was going to be slightly more than,

validates_presence_of :username, :forename, :surname

The folks in the team keep talking about Rails plugins for this, that and the other. Could there be some kind sole out there that has already solved this problem?

google 'rails plugin validate email format'

and there it is!

http://code.dunae.ca/validates_email_format_of.html
A plugin called validates_email_format_of by Alex Dunae.

There has got to be a catch, how complicated is it going to be to get into my codebase and make use of it?

Here is the user class before

class User
validates_presence_of :username, :forename, :surname
end

and here is the User class after

class User
validates_presence_of :username, :forename, :surname
validates_email_format_of :email
end

I'd a few failing tests sketched out to check the email validation....all of a sudden they all pass!

Job done.
Simple and elegant, what more could you ask for?

Working With Rails

2008-12-03T12:32:00.000-08:00

I've just started working with a new team on a Rails project. It seems very weird to be developing full time in Ruby after spending the last eight years where the main focus of the day job has been java development.

It is great to have all of these new things to learn in terms of rails, cucumber, rspec-rails and mysql. It is a little daunting being thrown that bit outside of my comfort zone with all this new technology at once even though I've been using ruby for the past 3 years.

I'll be sure to report back with all the interesting things I learn.

We've gone Groovy

2008-05-17T06:45:00.000-07:00

When we started our latest project about 6 months ago I was banging on about using Groovy. Nobody was convinced or should I say interested.

On Thursday the Mighty Gus and myself went along to a presentation on Groovy. We came back thoroughly enthused and were desperate to use it day to day.

Rather than placing Groovy code directly into the application we thought it would be good to introduce the language in the test suite. This would help familiarise the team with the language before introducing Groovy to the actual web application ( that is if we chose to go ahead and continue using the language ).

All of the developers on the team are competent with Ruby and would keen to use it within a web app. Having a Java web app places a bit of a restriction on introducing Ruby into the app code. This is the major win for Groovy, it seamlessly integrates with the Java code!

The main aim for Thursday afternoon was to

get Groovy up and running within our development environment,
write a test case for new functionality
update the continuous build and try to have minimal impact on the teams local environments.

Getting Groovy up and running locally
Only two downloads were required.

The Groovy compiler
JetGroovy, the IntelliJ plugin

Then we pointed the plugin at the Groovy home and added the groovy-all.jar to the test module path.

At this point we could run groovy test cases against our java codebase!
When running 'All Tests' in IntelliJ it automatically picked up the groovy test case!

Writing a test case for new functionality
Gus and I were half way though some work prior to going to the presentation.
We took the old Java test case and cloned it into a groovy test case ( updated the file and classname to avoid clashes).

At this point we were running groovy tests!

Yet we weren't taking advantage of any of the Groovy-ness, it was simply a renamed Java class.
What Groovy features did we make use of?

Remove semicolons ( as Ben described it, "the bald look" )
Removing method brackets ( this only works in certain situations)
Dropped types where they were not of value.
Introduce groovy lists for those ugly mock objects to return.
Replace the ugly mocks with some super-condensed stubs.

I should explain 4 & 5 above a bit more.
4: Due to the nature of some of our 'generic' interfaces that we were testing, the tests need to know about the 'generic' type. ( Does this sound like a contradiction to anyone else? )

For example:
We were testing a Spring Controller which adds the size of a list of items to the Model for display.
The list of items was retrieved from a Dao, which is injected into the Controller.
Standard practise on our project is to mock the Dao and, in the test, place expectations on the methods that will be called.


public class Controller
{
    private Dao dao;

    public Controller( Dao dao)
    {
        this.dao = dao;
    }
    public void handleRequest( HttpRequest request, HttpResponse response )
    {
        Map model = new HashMap();
        model.put( "number_of_items", dao.getItems().size() );
        return new ModelAndView( "viewname", model );
    }
}

public class TestControllerJava extends MockObjectTestCase
{
    public void testCorrectNumberOfItemsAreAddedToModel()
     {
        List items = Arrays.asList( new Item(), new Item(), new Item() );
        Mock mockDao = mock( Dao.class )    
        Controller testee = new Controller( (Dao)mockDao.proxy() );

        mockDao.expects( once() ).method( "getItems" ).will( returnValue( items ) );

        ModelAndView actual = testee.handleRequest( null, null );
        assertEquals( items.size(), actual.getModel().get( "number_of_items" );
    }
}

Here nothing in the Controller is particularly interested in the type Item. It is only concerned about the number of Items.

Which brings us to introducing Groovy lists.

class TestControllerGroovy extends MockObjectTestCase
{
    void testCorrectNumberOfItemsAreAddedToModel()
     {
        def items = ["one","two","three"]
        Mock mockDao = mock( Dao.class )    
        Controller testee = new Controller( (Dao)mockDao.proxy() );

        mockDao.expects( once() ).method( "getItems" ).will( returnValue( items ) );

        ModelAndView actual = testee.handleRequest( null, null );
        assertEquals( items.size(), actual.getModel().get( "number_of_items" );
    }
}

In this example the differnce may not be much, but consider the situation where the construction of the Item object is complex and needs a number of params.

This brings us nicely to further explaination of item 5 above. ( Replace the ugly mocks with some super-condensed stubs.)


class TestControllerGroovy extends TestCase 
{     
 void testCorrectNumberOfItemsAreAddedToModel()      
 {        
  def items = ["one","two","three"]        
  def dao = [getItems: { items }] as Dao         
  Controller testee = new Controller( dao );         
  ModelAndView actual = testee.handleRequest( null, null );        
  assertEquals( items.size(), actual.getModel().get( "number_of_items" );     
 } 
}

Here we have, line in Javascript, created a map instead of an actual typed object as the stub. We have satisfied just enough of the interface that we are interested in ( or that the source is interested in ).

The map is defined within the square brackets, the first item being the method call, then a colon, then a block ( which is defined in the curly brackets ) which will be executed when the method is called. You can have as many of these as you like, separated by commas. Another point to note is that, just like in Ruby, the result of the last statement executed will be returned by the method. Therefore there is no need to explicitly say {return items} as {items} will do perfectly well.

I'm not suggesting to use this as a rule, always aim for the clearest code/test possible rather than roping in as many new features of a language as possible.

The example above is a great deal simpler that the actual code and test we created on Thursday. It had 7 lists and 7 mock expectations and it looked absolutely hideous. It was so much nicer to see it condensed into 7 lines, however it felt really strange seeing so much functionality defined within 7 lines!

I suspect this is something we will get used to, it just felt weird.

Check in time - or is it?
How will this affect the other developers and the build box?

Our Team City build delegates to Ant. A quick look at the Groovy site gave some nice examples for compiling Groovy in Ant.

What we did forget to do was to add the groovy-all.jar to the ant classpath - D'oh.

We then updated the build box with the appropriate groovy install and jars and put together some info for the other developers about where to find the compiler and JetGroovy.

Job done.

I'll let you know how we get on!
WOOOO

Lazy Development

2007-10-01T17:50:00.000-07:00

For around the past 6 months I have been trying to nail down what the difference in attitude is between developers.

Paul Duvall has summed up what I have been trying to get across to colleagues in his post about troubleshooters and troublepreventors.

I describe myself as a lazy developer to anyone who cares to listen, however this needs some context.
By lazy I mean that I will put more effort into automating a task now rather than have to work out how to do it manually once a fortnight. (DRY)
Couple this with writing unit tests now to allow refactoring to take place safely at anytime in the future and it will aid you in developing great software.

Everytime these upfront payments get dodged it comes back to punish the dev team with obscene amounts of non-value add work.

Jiggy jumps into action after NFSJ

2007-09-05T07:14:00.000-07:00

Hello and welcome to my first blog post,

During my trip to London for the No Fluff Just Stuff eXchange (NFJS) I was introduced to a host of new tech toys to play with. The friendly nature of the presenters and attendees was great and I really want to share some of that experience with the wider world.

The overarching message I took from NFJS was that Polyglot Programming is the future of software development, encouraging the developer to use the right tool / language for the job thereby having many languages in your toolbox to draw upon.

Whatever your bag is Java, Ruby, Groovy or something more functional like Erlang or Scala, NFJS was keen to introduce you to them all and allow you to make an informed decision as to which language you should use to solve which problems.

Scott Davis was really excited about Groovy, which looks a lot like Ruby.

Scott was keen to point out that when he was working on a Ruby app in the morning and a Java app in the afternoon the context switching was a major source of pain. He finds using Groovy for both apps easier to deal with as it is so tightly coupled to Java and has all the expressiveness of Ruby.

To create a .groovy file you can take any .java file and rename it to .groovy. You now have a syntactically correct Groovy file. The only other change necessary at that point is to compile with the groovy compiler groovyc. Thereafter you can start taking advantage of closures and the scripting ability of the language!

Sounds and looks too good to be true. I'll let you know how I get on.

Graeme Rocher provided a Grails intro which looks very interesting although I don't think I'll get to play with it at work anytime soon.

Neil Ford was discussing DSLs and Language Oriented Programming. This is something that I've been trying to play with for a while with limited success so it was nice to get some pointers. The main thing being to keep a DSL small and focused, do not try and be all things to all men. This presentation left me immediately wanting to go and start playing with Antlr and the IntelliJ Metaprogramming System. ( You can find a similar presentation given by Neil and Martin Fowler at The Server Side. )

During NFJS there was a great deal of banner waving "Death to SOAP" and championing of REST :o)

Ted Neward showed off some of the monitoring tools that come with Java. I never even knew these existed! ( Well not along with your downloaded JVM at least.)

Scott Davies gave another couple of exciting talks on,

GIS web development
and Yahoo YUI Ajax library.

I had no idea so much free GIS data is out there!

In terms of the YUI here is what it has to offer,

All of the widgets shown were super-configurable. Great, less javascript to write.
There is a load of widgets - all free!
An excellent Logger widget to help debug any components you have been doing handy work on.

However there was one really strange thing about the widgets that troubled me. Each widget had it's own dir with library with three implementations!

widget.js
widget_min.js
widget_debug.js

Whats going on?
Well widget.js is the javascript implementation nicely formatted with comments.
widget_min.js is widget.js with comments and surplus white space removed so that download is quicker. Fair enough.
widget_debug.js is a version with logging output.

If you need to do some debugging of the file you have in production widget.js/widget_min.js, you need to change the reference in your html file from widget.js/widget_min.js to widget_debug.js.
This is a recipe for confusion if not disaster, replacing the file that is not working and needing examined with a completely different file!?

Venkat Subramaniam did a session on Functional Programming with Erlang. The main thing Venkat reinforced for me as a web developer is trying to have no ( or as little as possible ) state held within your application.

In brief summary, NFJS was,

very interesting,
introduced me to some knew ideas,
rekindled some old one ideas,
will definitely have me attending again!