This class explores simple and effective techniques for achieving those goals in any kind of presentation.

The first half of the class focuses on preparation, content selection, visual design, delivery, handling questions and effective techniques for presenting various kinds of technical information (code, data, statistics, charts, structure diagrams etc.)

The second half of the course is an in-depth tutorial on improving the ‘look and feel’ of presentation materials – especially Powerpoint/Keynote/Impress presentations. In particular, it demonstrates practical techniques for making your slides not suck!

Places are limited – early booking is essential Early-bird rates available until 15th March 2012.

http://www.flossuk.org/Events/PresentationSkills2012

A most enlightening session with some lovely people!

Having been a Fedora user since way back when it was Redhat 4.2, what I want is the Fedora / Redhat way of putting all of my rules into a single file and having the damn thing do an ‘iptables-restore’ from the file I create.

I finally got really irritated with ufw, went hunting for a solution and found the ‘iptables-persistent’ package within apt which does exactly what I want. Rather than the Fedora ‘/etc/sysconfig/iptables’ you have ‘/etc/iptables/rules’ which does exactly what I both want and expect.

Perhaps this Ubuntu thing isn’t all that bad after all, I’m just still learning how to smack it in the right way to make it do what I want though.

What you’re looking for is the server.prefs file line:

webproxy: proxy.example.com:8080

This caused me some aggravation to find, so I hope it will help you.

IronMan was and continues to be a project to promote the Perl programming language by encouraging a community of bloggers to post on a regular basis and offering a token reward for their efforts (link needed here). Each of these blogs is then agregated to a single point for the community and the world at large to read, and of course for the assorted search engines to index.

The IronMan hack day 2009.

On Saturday 12th December 2009, the North West England Perl Mongers gathered together at the Shadowcat offices in Lancaster for our first hack day to work on the IronMan project.

The Enlightened Perl Organisation established the IronMan project and were very keen to see an archive so that all the posts that were being aggregated could be viewed retrospectively.

It was felt that the current organic architecture wasn’t shaping up in the best way for the direction that the project needed to take so a new approach was envisaged.

Who turned up?

In person:

mst, mdk, idn, iain, fade, grim, acid2, Leigh, epitaph

By the magic of the intarweb (IRC):

castaway,

Sorry if I’ve missed anyone, it wasn’t intentional. If I’ve missed you shout up and I’ll add you on.

Someone had the inspired idea to draw a small diagram of the room and who was sitting where to enable us to look like we knew everyones names

What are we working on?

mst talked to us about the existing and proposed architecture making extensive use of the conference room white boards as we went along.

The legacy used Plagger to collect blog feeds and aggregate them into a statically generated planet. New feeds are signed up via a basic web form. The feeds data was stored in a SQLite database file via DBIx::Class, while the post data was stored in CSV files by Plagger.

The new would replace Plagger with Perlanet, and the statically generated content with a dynamic Catalyst web UI. The CSV files would move into the SQLite database and be stored in a table to enable the dynamic generation and archive ability.

Who was doing what?

mst took the overall role of technical architect and had a good idea of where he wanted to go with the project flitting from one place to another as needed.

acid2 picked up Perlanet & Perlanet::IronMan and proceeded to hack it into shape for our particular needs.

fade and iain continued working on the IronMan::Web aspect which they’d already started working on prior to the hack day. Some might say this is cheating, I say that it’s a good way to know what you’re doing in advance.

grim & castaway took the original DBIx::Class IronMan::Schema and modified it to support holding the blog posts. Alongside this, they began working on tools to import the legacy Plagger CSV data into the new schema.

Leigh sat amongst us and worked on her NaNoRiMo, and why not.

Refreshments and the essential caffine, pizza and beer.

Tea and coffee from Lancasters premier coffee shop Atkinsons fuelled a coding haze that saw us write some Good Shit(tm). Sadly, being coding geeks means that your supply of coffee needs to be plentiful and strong. mdk had to make a trip to fetch more coffee when we drained the office supplies dry!

Towards the end of the day, Shadowcat shelled out to further fuel the session with pizza, beer, nibbles and awesomeness.

What did we learn from the IronMan hack day?

Whilst much has been written about software development both in the commercial world and in the open source community, I’m taking this opportunity to reflect on my own view of the only open source project that I’ve been involved with.

So why bother to stop and reflect? It mostly went well!

The Prince 2 project management framework refers to a “Lessons Learned” log, it’s something you keep as a project progresses so you have something to review at the end. Problems encountered to avoid in future, that kind of thing.

We all examine our own code, if we’re lucky any documentation and such things, but do we take enough time to examine the organisational aspects of the process that brought us to this point?

These are my notes and ramblings on how we might have done things better.

Supporting infrastructure – laying the foundations.

Whilst it’s certainly possible to do these tasks on the day, it’s dead time for almost all of your developers. Do what you can to prepare as much as possible in advance and keep everyone in the zone for as long as possible.

Publicity and marketing.

There’s lots of information online on how to market events. Yes. I said the M word.

It’s important. If people don’t know about your event, they definitely won’t come even if it’s something they’d want to help out with.

Start pimping your event early and often. We had a good physical and electronic turnout. Even though we were all in the same room, we tended to use IRC for communication anyway, which allowed extensive contributions from outside the room.

Who?

Scope is all important as we all know. I’ve said already you can probably do all the suggestions here on the day and that’s certainly simple if you have four people.

What if you have two hundred? Hack days are a wonderful thing, but organising for two hundred and then having four turn up would be as bad as organising for four and having two hundred turn up. This could be really bad for you and for your project.

Knowing who you’ve got showing up allows you to think ahead and discuss aspects of your project that you want to split up into manageable chunks. With a little planning, the required information can be given to the right people who can then talk to others on the day. Think scalability and resilience, try to eliminate your single points of failure The more others know about the plan, the less the chance of a Guru Meditation Error.

Remember that physical presence is not required and extend your invitation to those who may not be able to physically attend but still wish to contribute.

Network and connectivity.

Now you know how many you’re expecting, you can think about the capacity of any network that you need to provide for the event. Can you get away with a sinlgle domestic wireless access point for your four people, or do you need something more substantial for your two hundred?

Despite his best efforts, epitaphs fight with the wireless and LAN through the course of the day resulted an a few outages stopping us all working.

Version control.

I don’t care to argue which one you use, but you should use a VCS of some kind. We chose to use subversion. Regardless, the following points are still valid.

Create your repository or use an existing one.
Set appropriate permissions on the newly created or existing repo.
Find out who’s coming so you can create user accounts in advance.
Make sure its something your target group may be familiar with!

We lost time to repository creation and user setup that we could have reasonably been done beforehand.

Venue.

Our venue not only provided very nice refreshments, but a large number of white boards. Never underestimate the power of explaining things with a whiteboard! It not only tells everyone else what you’re thinking, but helps to solidify your own thoughts.

Don’t underestimate how many 13A sockets you’re going to need for laptops.

What are we working on?

Turnout was good, we had a number of physical attendees along with people joining us via IRC. Everyone was fired up and ready to go. There was one major problem. We didn’t all understand why we were there, what we were working on or what the objectives for the day were.

Several hours were spent hashing out design, which might well have been needed, but some of the other fundamentals were missing.

1. What are we working on?

IronMan is a blog agregation service to promote Perl. A shop window for the world.
2. Why are we working on it?

We want to streamline the management of the existing service by replacing plagger with a new model based around Perlanet for feed collection.

We’re going to replace the existing static page creation with a Catalyst based web application that will display the content dynamically and permit people to view the blog post archives for specific days or months.
3. What are we hoping to achieve in the timeframe?

In the day, we’re going to:
* Get a good fundamental understanding of the existing architecture so that everyone knows how things work.
* Review and implement changes to the database model.
* Begin working on the Perlanet collection code.
* Begin working on the Catalyst web UI code.

It’s easy to list these things in retrospect, but we could have saved a large amount of time and effort if we’d have thought about these things before we all got together.

Test deployment.

During the course of the day, we didn’t have a defined checkpoint to deploy what we had so that everyone else could see it.

Take the time in advance to configure a staging system so that at pre-defined points during the day, everyone commits their changes and the staging system updated and restarted as required.

Try not to break the build…

Beyond the hack day.

Upon these sage words of wisdom, your hackday went well, right? Remember to look back at what you’ve learned at each step of the process, what worked and what didn’t.

Once your hackday has been and gone, you’re left with the inevitable job of continuing to support the project you’ve been working on. This is a whole new set of challenges in much the same way as the organisation of the hack day itself.

Documentation.

Nobody likes writing it, everybody likes reading it. Well, most people.

To quote castaway: “documentation is hard”. She’s right of course.

If you’re lucky you’ll have a documentation whiz like castaway on your team, but if you don’t you either need to find one or try your hardest to make do with the people you have. In order to get people interested, you need to have a basic level of documentation in place or it will put people off from contributing to your project.

Document your version control system structure. Doesn’t matter how you lay things out as long as it’s clear what’s going on.

Once you have your repository structure documented, then document how you move through the different stages of release. I’m a simple bloke and generally like to roughly document the commands I use to ‘svn copy’ things from one area of the repository to another. It’s a simple thing, but it’s something that will save you time and keep you consistent in your naming.

If you don’t do the above, your repository may end up looking like a dogs breakfast and people will be put off contributing patches simply because they don’t have time to try and work out what’s going on. Post deployment of the IronMan project, it took around a mans day worth of work to get things into a sensible state, in the mean time several people were unable to contribute because they couldn’t work out which files they should be working on.

I’ve mentioned staging your development for the period of the hack day, you should do this all the time. Not only does it allow you to check that things will work on a machine that isn’t yours, it checks other peoples committed chanmges and gives the project visibility. If you don’t have visibility before you deploy to your live service, then you can’t get feedback from your user community.

Organising your next hack day.

So following your last successful hack day, you’re mad for organising another, right!?

I’m making one major change for this year. The North West England Perl Mongers haven’t decided what hack day 2010 will be yet, we’re asking the membership to present lightening talks for their project at the September technical meeting. This does a few very important things:

You can’t present on your project and sell it if you haven’t thought about it and what you want to achieve
If you want your project worked on this year, you need to sell it to the membership who will be voting at the end of the evening.

It might solve some of the preparation issues, it might not. Perhaps this time next year I’ll finally finish some more reflections…

Armed with your reflections and thoughts, bring free software to the masses, because we can and because it’s the socially responsible thing to do. Plus all th ecool kids are doing it….

The problem stems from the assumption (you know this is going to be good…) that the authors field retrieved from a post should not be null. Indeed, this seems sensible, but there seem to be a number of feeds that don’t observe this for some reason (which I frankly don’t care about, especially now I have a different way to assume it).

If the author field on a post is undefined, it is now taken from the title given to your feed when you signed up for IronMan. This seems to be the sensible fall back in the absence of the data on the feed.

As always, comments appreciated.

Ian & the IronMan dev team.

I’m once again struck by the number one failing of open source and free software products, I can’t work out what it does! What features does it offer? How will it make my life easier/faster/longer/stronger (delete as appropriate)?

Your project might be the best ‘X’ since the concept was invented, but if you don’t tell me why I should spend my time to download it and install it then I’m going to move on and look at the next one. I don’t want to spend a couple of hours getting something working when it doesn’t offer some basic feature that I absolutely cannot live without, that’s dead time to me.

Please take a moment to look at your project. Compare it to it’s commercial offering (if appropriate). How does it compare by face value? Do you have headline top five and complete feature listings that someone can look over quickly to see if it fits their needs? Does your site focus on the technical detail of the project and provide no higher level information? Do you actually say what your project, Perl module or doodad does in a simple one line summary that your mother could understand?

Seriously. If someone can’t tell these things in five minutes of looking at your site/module, you’ve probably lost them forever. That’s their loss too remember as your doodad is the best ‘X’ ever available!

There are two outstanding issues that we’re aware of:

• The signup page templating needs fixing
• Post tags are being removed

Assuming no major issues in the next 36 hours, this will be the live ironman on Saturday to celebrate the first anniversary!

See my original post at http://idn.per.ly/2010/04/03/12/ for the full low down.

We’ll be having an online hack on the IronMan code tomorrow night starting at around 19:00 BST and putting it live once we’re happy any show stopping issues are dealt
with.

Come and help out – we’ll be online at irc.perl.org in our very own
#northwestengland.pm

Remember that you don’t need to be an expert in the project or code to make valuable contributions in how things look and operate, features that we’ve missed or things that look a bit unfamiliar compared to the existing site.

The project todo list can be found at:

http://dev.catalyst.perl.org/repos/bast/ironman/branches/mk-ii/IronMan-Web/todo.pod

See my original post at http://idn.per.ly/2010/04/03/12/ for the full low down.

Seems I screwed up posting the original article, so apologies to those who saw it but were unable to read the contents when it was posted.