Thursday, 17 December 2009

Tips on presenting at a conference

So I stumped up my £95 (+VAT) and decided to go to the Open Source and Finance eXchange. The day had some fairly interesting topics which unfortunately were (more often than not) ruined by poor presentations. This was particularly irritating as this was a paid conference and I expected a minimal level in the quality of speakers.

Of course the great value in going to a conference is always the interaction with the other attendees, but still it was a little disappointing.

So I thought I'd point out some tips for presenting at a conference:

  1. Be passionate in your delivery, no-one and I mean no-one is going to care about what you are talking about when you deliver it in a dull monotone.
  2. Don't let that screen saver/power saver cut out your presentation!
  3. Slow Down - Often people are nervous when they present, which is only natural, but it means that they have a tendency to speak far too quickly.
  4. Slow Down part 2 - If the language you are speaking in is not your first language, or if you know you have a strong accent, then again for the sake of clarity, slow down!
  5. If you're going to have graphics in your presentation, make sure they are readable when they are projected on the screen.
  6. Don't use complicated graphics, keep it simple! If in doubt get a Graphic Designer to take a look for you.
  7. Don't just repeat what are on your slides, the audience has already read them and you're adding no value.

Thankfully towards the end of the conference we had some good speakers including probably the best presentation I've ever seen at a conference. If you ever get the chance to see Simon Wardley (from Canonical) speak, then do yourself a favour and go and see him. The podcast of his talk will arrive here soon.

Tuesday, 8 December 2009

PCGen - An awesome online community

Hi all,

Just a brief note on one of the important points in running a successful Open Source community. A key ingredient is to give immediate feedback to users that post on your forums and mailing lists.

An attitude of 'Go and find it yourself Newb!' is not a particularly healthy way to attract new users to your community. Don't forget that a new user is potentially a new volunteer for your project!

PCGen _excels_ in this area, no question big or small is left to rot on its boards and the responses are always cheery and polite. If you're looking for an example of how to respond to your users, look no further than the various mailing lists that exist under the PCGen banner (you can find them via the website).

The Ubuntu forums are another fames place for this type of attitude and it's certainly helped build their popularity as well.

So here's a public thank you to the tireless volunteers and community users who take the time and effort to continuously reply to the tons of queries we get at PCGen, well done to you all!

Tuesday, 1 December 2009

How to be a Rock Star Developer

Here is the Google Wave text that was taken down by some helpful community members from my talk at the recent London Java Community Unconference.

I plan to expand greatly on this talk with hard examples of the various points, let me know if you've got any useful examples you'd like to add!

Get the Rock Star attitude


  • Be passionate, care about the code
  • Be a leader - look at new approaches e.g. BDD, New JVM Languages
  • Be personable, stop and listen! - The person who directs a project the most is one that is the most effective communicator
  • help newcomers, they give you a fresh perspective - explaining things helps your understanding

Be inspired by the rock gods


  • Don't reinvent the wheel, covers are rarely as good
  • Read blogs and community sites - stuff that is not part of your every day blogs - e.g. Kathy Sierra - high level thinking
  • Stand on the shoulders of giants - smart people have tread that path before, so use their insights

Be part of a band


  • dont code in isolation - everyone needs a team - coding in isolation leads to be lost in your own little world - very few ideas / service that you can build that a team can't do better
  • Talk to the users early
  • The developer who communicate has most influence - many ways to communicate, try do it as clearly as possible to be effective
  • Bounce ideas off others - a wider audience can give you a wider range of feedback than your local team

Play a Fender Stratocaster


  • Do development on a fast PC
  • Use a big tft screen or have several screens
  • Make your environment comfortable

Open your mind


  • Learn how to look up reference material, trying not to learn api's verbatim
  • Read books on development - podcasts, video clubs etc
  • Read code by the experts - many references externally and internally
  • Learn a different type of language e.g. if you work with an OO language, dabble with a functional language, shell script - avoids the Golden hammer

know your studio


  • Learn your ide inside out to be as productive as possible - saves 5,10,30 mins then hours a week
  • Run a continuous integration server - early feedback
  • Use source control - don't lose those songs - big investment bank lost all source code because of 2 primadonas keeping code locally and had a power glitch.
  • Know your OS/Hardware/System Architecture - sockets open, threads, etc

Rehersals


  • Go back and enhance your old code - how do you convince the management - discuss financial impact of leaving bugs / features in the system - continuous cycle of self improvement
  • Get cold hard feedback - dont be too precious about your code - OSS has the source of a thousand eyes - commits go to a committers mailing list so people know what to review and can give feedback early - using patch files - fisheyes - no one writes perfect code
  • At least briefly research yourself before asking others - use google instead of embarassing yourself on a public mailing list
  • Run test suites

Polish your songs before the album release


  • Keep source code neat and tidy (Checklist) - read The Daily WTF website for examples of bad formatting
  • Reduce the simple bugs (PMD, Findbugs and more) - use Find bugs to give you better ways to do things, like an expert on your shoulder
  • Comment you public apis (Javadocs) - if you provide an API define at least what to call and what to return, to otherwise people will not want to use it

Monday, 2 November 2009

Java Unconference

Hi all,

Brief post (I know, haven't updated in ages!) to advertise the London Java Community's first Unconference on the 28th of November! I'm helping organise this one and time permitting I'll also be presenting at a couple of the sessions with juicy? topics such as "How to run a successful Open Source project" and "How to be a Rock Star Developer!".

See http://londonjavacommunity.wordpress.com/ for details of the Unconference.

Hope to see you there!

P.S: For those of you who don't know what an Unconference is, see http://en.wikipedia.org/wiki/Unconference for details.

Friday, 12 June 2009

How to run a Successful Open Source project

So I never posted about the recent talks I did :). Since using ones blog is great for self advertisement here goes!

The talks were delivered to members of the London Java Community, London Open Source & Agile Community and the London Open Source Jam group, it's a shame that there isn't one overriding interest group that can get together for this sort of thing, but I guess it's human nature to build small tribes.

The first talk covered off a wide range of topics that you need to deal with when setting up a successful Open Source project including:

* Getting started (Choosing your project name, Mission Statement, etc)
* Setting up your technical, social and political infrastructure
* Money
* Communications
* Packaging, Releasing and Daily Development
* Managing your volunteers

It's a long and involved topic, so you're best off seeing the Podcast or reading Producing OSS by Karl Fogel.

The second talk was actually an open forum debate covering licensing and legal issues for Open Source projects. We had some great panelists come in for this one including:

* An actual IP Lawyer!
* The chairman of the UK Open Source Consortium
* An Apache project lead
* An expert in academic licenses.

I decided to switch off the video camera as we wanted a full and frank debate on the issues and it certainly proved to be interesting (the lawyer didn't cop too much flak)!

One overriding message that came out of this talk was that individuals really need to check their contracts for the IP clauses contained within. Often organisations use a default agreement which states that the work you do in your spare time is still owned by them. Most organisations are actually quite reasonable once you approach them about this, so don't hesitate to ask them!

Tuesday, 26 May 2009

Presentations - Argh!

So once more I find myself preparing to give a presentation to a group of (mostly) strangers, scary much? This time it's on "How to run a successful Open Source project", a topic that I have lots of opinions on having spent the last 8-9 years involved in several projects.

There is a ton of good literature on how to run an effective presentation ("talk like so", "make slides like that"), but since I'm a geek I'm just going to mention the help that modern technology has given me :).

Firstly on the way back from a Hi-Di-Hi! style holiday camp (much fun, go the Falconry lesson!), I was able to use my Wife's Samsung NC10 Netbook to hastily finish off the first draft of the presentation. It's amazing what you can type out on that little monster even when crammed into the back seat of a non people carrier. Oh and thank you good genes for not making me carsick, very useful trait that.

Next up is the use of MS Powerpoint. Yes it's much maligned but it still beats writing notes up on a whiteboard with your back to the crowd. It also helps to have a Wife who happens to be a Graphic Designer, pretty Powerpoint template heaven!

Then there's the borrowing of my Flatmate's Macbook Pro to run the presentation from (not all of us can wear turtlenecks ;p).

Last but not least there's the use of the iClicker utility for the iPhone. I can go back and forth through the slides and have a mini representation of each slide in front of my nose, again I don't have to turn my back on the audience which is a good thing. Bonus points to the developers of this utility for allowing you to swap between the notes for the slide and the slide contents itself.

I'll post the post-mortem on the talk sometime tomorrow, assuming I don't incite the crowd into rioting (IT people are generally far more passionate than people give them credit for).

Monday, 20 April 2009

Symbolic Linking ahoy!

Learned a handy new trick today! I was trying to roll out some pre-prepared Jboss servers with some symbolically linked directories. I completely forgot that when you unzip these that the symbolic linking is gone.

A quick hopeful trip to the man page for zip reveals this:

-y Store symbolic links as such in the zip archive, instead of compressing and storing the file referred to by the link (UNIX only).

They think of everything :). It's little things like this that remind me to RTFM before I go and blindly do things.

As a side note, applying customer patches for Jboss-eap-4.3 is not as straight forward as it should be. You effectively have to roll out brand new servers and their associated server instances and then copy your applications and configurations across (making sure of course that they're customer patch compatible). Jboss responded and say they're going to try and do better the next customer patch, will be interesting to see if they succeed...

Tuesday, 31 March 2009

Twitter just isn't enough

Well after a bit of thought I've decided that yes I will try to have one of these crazy blog things, I'm mean sometimes 140 characters isn't enough :)