This was the first WorldCon that I'd ever been to, and since it was in my erstwhile home town for only the fourth time in its 68th iteration, it was a chance I was not going to miss. I had been involved in conventions before, but usually as a presenter, and working while not presenting to ensure the conference was a success. To be a spectator was a bit of a novelty.

For the uninitiated AussieCon 4 is the 68th World Science Fiction Convention (WorldCon) held in Australia (and specifically Melbourne) for the 4th time. The first (AussieCon, with no suffixed numeral) was in 1975. To be honest I was an ardent fan of Science Fiction from before then, and I am amazed that I hadn't realised that these events had taken place in my city. It is easy to forgive the first one as I was just a teenager, but then there have been another two in the intervening 35 years, and I managed to miss both of them. Well not this time.

Like all WorldCons, AussieCon 4 is entirely run by volunteers, and they do a fantastic job. Registration was a breeze and even when problems arose the organisers handled it with simple yet effective solutions that meant that nobody was grumbling. The only problems I heard of from other members were of the venue, and not of the convention. And even then they were minor - like not having freely available WiFi, and the fact that the seating provided in the foyer was deceptively uncomfortable.

I only managed to get to two sessions (apart from the opening ceremony) as I wanted to sit in on a session that conflicted with that of Cory Doctorow, so I managed to get a ticket to his session on the same topic (Copyright and Creativity) at the Melbourne Writers Festival. Even so, the sessions I did attend were well attended and provided an interesting contrast. The first ("Spoiler Alert: reviewing plot-driven fiction without giving the story away") was a panel of reviewers (mostly fans) and their experiences and tips on reviewing. It reawakened my interest in reviewing and I'm sure KC will be happy to hear that! (As one who takes her reviewing duties very seriously KC has very strong opinions about my rather more casual attitude to the task).

The next panel was "Perfectly packaged: designing and marketing science fiction". Four panelists from publishing houses explained how they see their role in bringing a work to market. A lot of the discussion was around cover art, and the differences in different markets. An example was that the American covers tended to have more text on them (with at least three or four "selling points") and tended to be more action oriented, while British markets tended to shy away from too much text on the cover. The importance of the cover was then countered by the stats that admittedly were off-the-cuff but suggested that 99% of books were passed by without a reader viewing more than their spine. It was suggested that you had less than a second for the book to capture interest - then perhaps two or three seconds for the cover art to entice the prospective buyer to turn the book over or flip open the cover. I guess the most interesting idea that I took away from this session was that the cover art is there to give the reader what it feels like to read the book, and not try and be descriptive about the story.

Then I had to hot foot it up to the Capitol Theatre in Swanston Street. Although I did manage to confuse myself and walk around 1km too far as I headed up to the LaTrobe Street end before having to come back down to the Collins Street end. Yes, both ends have RMIT campus buildings, and Capitol Theatre is one of them.

Cory Doctorow's talk on Copyright and Creativity was, as usual, insightful, commanding, and entertaining. If you are a writer and have ever been convinced by your publisher that E-books are going to kill the industry and strong DRM (Digital Rights Management) is going to save the day, take the time to search out one of Cory's talks. I think you may come away with at least a more balanced perspective on the state of the art in DRM and the size of the problem it is supposedly trying to solve. This is a man who has released all his books both in traditional published paper form and as electronic books covered by a Creative Commons license, and done so successfully to both the amazement and delight of his publisher.

Points that Cory covered (and forgive me if my rendering of them has changed the sense or intent - all errors are my own):

Copyright has gone beyond its traditional role of regulating the entertainment industry to becoming an all pervasive regimen for controlling the lives of ordinary citizens. Good use of copyright makes good sense - pervasive use makes no sense.

Art has never been a discipline that followed the rules of economic rationalism and virtually no artist ever got into it to get rich. While Cory didn't mention it I might make the point that Vincent van Gogh died virtually unknown and never made a fortune (or even a decent living as far as I can tell) from his art, as did many artists we now know as greats. Cory was quick to point out that this is not how he would like it to be, but it is how it is. The extending of copyright will not change this dynamic as it doesn't address the underlying problem.

The current discussion on DRM is actually not about copyright, but about distribution control and putting more control into the hands of the distributors of works and not the creators.

No DRM works. Or more correctly it can never work as intended. Consider DRM on an ebook. Since you must still be able to read the book there is no way to stop you (using DRM) from retyping the book, effectively getting around any and all DRM no matter how supposedly secure or strong it may be.

It is difficult to monetise fame, and impossible to monetise obscurity. To take something that I know a bit more about as an example, MySQL in its early days had as its prime aim "ubiquity". That is, make sure everyone that is doing anything with data thinks of using MySQL first. Then the money will come later. Building an audience and then connecting with them in real ways is more important than trying to treat everyone as a potential criminal and expecting to "protect" revenue that way.

Looking forward to tomorrow's feast and wishing I could clone myself so I don't miss anything!

In my job I get to see a lot of resumes. Being the grumpy dev in the corner, it is usually my task to take a first cut of the resume pile and weed out those who don't have the technical skills required for the job. Only after that happens does someone who can actually make the hiring decision get a look at your resume. So you need to get past me, and I have to say there are a lot of bad resumes out there. In the interests of being a good netizen, I'm going to give you some tips that might mean you don't end up in the slush pile.

Proofread

Don't send me a resume that says you have excellent English communication skills and then spoil it by spelling errors, gramatical mistakes or just plain bad English. It isn't going to fly. Even if the rest of the resume is up to standard, the fact that you don't care enough to proofread means that you likely don't care about your code either. I don't want to have to clean up your typos or syntax errors, so I'm not going to recommend you.

Be Specific

State not only what your position was but give some detail about the work you did, the tools you used and the level of involvement you had. I want to get a sense of how you think and work. I want to understand the challenges you faced and how you overcame them.

Developed websites using PHP, MySQL.

Sorry, that tells me nothing.

Built eCommerce website, including researching various payment gateways and writing interface to meet customer's needs. Other challenges included privacy agreements and data security constraints. Code written in PHP with interfaces using RPC-XML, and backed by a MySQL database.

Better! I can see that you needed to think through problems and overcame them. I can see that you have an understanding of interfacing requirements, and I can see you have thought about topics I am interested in (privacy, data security).

Be Honest

If you have built websites using a CMS and most of your job was in building the theme and configuring modules, say so. Don't hide it behind words like

Site built as CMS in PHP

Yes, it was built as a CMS in PHP, but if you didn't write the CMS, it could have easily been written in Fortran or LISP - it has no bearing on your resume. I'd rather you stated what you were capable of and then if you wanted to get into PHP development say that.

I have been learning PHP over the past x months and would like to extend my skills in this area

Is a better approach.

Be Passionate

Have you done something you are really proud of, even if not as part of your work? Say so! It takes passion to be a good programmer as much as skill, and in fact passion can get you over the hump even if your skill set is on the light side. Tell me why you did things as well.

Fill the Gaps

Don't leave unexplained gaps in your employment history. If you weren't working, tell me what you were doing. Even if it was walking in the Andes, or sunning yourself on the beach. I'd rather know a bit more about you and therefore how well you will fit into the team than have a gaping hole that I have to guess about.

Be Pertinent

If the job is for a web developer, don't highlight your excellent work as a hardware engineer. By all means tell me about that, as it rounds out who you are, but don't make it a highlight. Similarly if the position is a Web Developer, don't put in the intro that you are looking for a Director or Manager level position. That isn't on offer, so don't ask for it. If your skill set or your aspirations don't match the position, ask yourself why would anyone bother to read the resume, and then ask yourself why you would bother submitting it. Are you that desparate, or did you just not read the position description?

Supply a Portfolio

When I look at a resume I want to find someone who will be an asset for the company, and maybe even someone I can learn from. I also want to understand how you approach and solve problems, and what your level of skill is. Think about supplying examples of code, documentation or even links to some websites that you've worked on. But make sure that you aren't breaching copyright.

Make sure the code sample is something you are proud of. I don't want to see a simple function that you could have copied out of a How-To book. And please, comments are not there to tell me what you did, that is what the code is for. Comments are there to explain why you did it that particular way. Less comments and well thought out code is better than inane comments and a complete mess of badly conceived spaghetti.

Please, do yourself a favour and make sure that you have no obvious security flaws in your code. Anyone can write a snippet of code in an arbitrary language, what I want to see is that you truly understand that language, how it fits into the work you do, and what its constraints are. Creating an example without thinking through the consequences or the vulnerabilities is suicide. I will read your code, and I am looking for problems. If you really thought that only the hiring manager was looking at this and nobody was going to double check that you knew what you are doing you are on a hiding to nothing.

If you are providing links to websites, explain exactly what you did on that site.

Think about Open Source

Allied to the above, have you thought about getting involved in an Open Source project? This is a great way to get practice in your chosen field and to give your prospective employer a real insight into your coding style, your skill level and your ability to work in a team. If you are straight out of college this is a great way to strut your stuff and counter the usual complaint of lack of experience.

Remember your Audience

Remember that your resume is likely to hit at least three people's desks. The hiring manager or recruiter, the department manager, and me (or rather a person of technical competence who is looking forward to have someone share the load). Don't just put in headlines for management and forget detail that explains your technical skill level. Similarly make sure there is a summary section that covers the highlights so the recruitment officer can quickly put you in the right pile.

Hit all the Points

If the job spec asks specifics, answer each and every one of them. If you can't then you aren't going to get past the first cut. This is not only for the techincal requirements, but also for the work conditions. If the job states a distributed devlopment team, or that you should be a self-starter, then ask yourself honestly if you can work unmanaged. There is no shame in knowing your strengths and your weaknesses. Quite the reverse.

Don't Panic!

It takes time to get through the pile of resumes. Don't expect to hear back within a few days. Even if you do fail the cut, don't despair. Take a look at your resume and see if you can see why you failed. Better still, pass your resume around to others for comments before you submit it for a position. Try not to take any negative comments to heart - think instead of how you can address them. You may even be able to ask the employer why you were rejected. Not all will be willing to comment, but some will, and getting it from the horse's mouth is far better than dreaming up reasons yourself.

What's the difference between these two pieces of code:

dojo.addOnLoad(function() {
    dojo.connect(dijit.byId('mainTabContainer').tablist,
       'onButtonClick', tabClick);
});

and:

dojo.addOnLoad(function() {
    var container = dijit.byId("mainTabContainer");
    dojo.connect(container.tablist, 'onButtonClick', tabClick);
});

Nothing I hear you say? Well, I'd guess that as well. After all, the second simply sets a variable that is then used in the following line exactly as it was in the previous piece of code. Yet Internet Explorer (at least version 7 and 8) doesn't agree. It will fail on the second example.

Now my guess is that it is trying to do a pre-compile, and evaluating the first line at parsing, instead of when the function actually runs (which is after the onLoad event triggers). It certainly thinks that the variable container does not contain an attribute called tablist in the second version, but has no trouble finding it in the first. Now all I can say is WTF!?!

Every other browser treats both pieces of code as identical, yet IE consistently fails.

In the modern world you may often see busy people sitting in a cafe or airport lounge checking email or updating their Facebook or Twitter status. Just how far the world has come is of no surprise to those of us who are old hands in the work from anywhere stakes. In the days of MySQL AB (now a part of Sun Microsystems, a wholly owned subsidiary of Oracle Corporation) around 70% of the workforce worked from home. In fact, the title of this piece, Freedom to work anywhere, is a direct steal from a MySQL jobs campaign, and I have several MySQL T-shirts with the slogan on it.

Is it important? You betcha it is. With a solid technology base you can easily have a highly motivated (and highly mobile) workforce that will give you far more in output than you have a right to expect, and at a cost that is dramatically lower than the traditional work environment.

Think about it. What is the cost of office space, a desk, chair, air conditioning, lighting, staff amenities, etc, compared to the cost of an internet connection?

With technologies like OpenVPN, IRC, Skype, Asterisk, and of course all of the Mozilla suite of web tools, you can have a distributed and productive work force that can react quickly to demanding schedules and rapid changes in priorities. Your main web server decides to act up during the night? No problem, chances are your head web dev is online anyway or is in a timezone conducive to tackling the problem.

This technology lowers the barrier of entry for startups, allowing them to compete in a global market from day one without having to build the bricks-and-mortar structures of the past before you can attract staff. I notice that an old colleague of mine has taken this to heart, with whatever he is up to at Empire Avenue. Might be worth keeping an eye on these guys.

You really have to wonder about those companies that don't embrace the Work From Anywhere meme, and are stuck in the mindset that predates the modern communication era. (I was going to say it is 20th century thinking, but my first stint of telecommuting was in the 1980's).

I have done my daily work from a variety of places, and solved problems remotely from Lake Tahoe, heaps of coffee shops, and even more recently at 100km/hr down the Western Hwy (no, I wasn't driving). My employer is happy, and so am I.

Title: RED SEAS UNDER RED SKIES
Publisher: Gollancz
Author: Scott Lynch
Edition released: 2007
ISBN: 978-0-575-07925-0
586 pages
Reviewed by: Adam Donnison

RED SEAS UNDER RED SKIES is book two of the GENTLEMAN BASTARD SEQUENCE, following on from THE LIES OF LOCKE LAMORA.

Locke Lamora is a con-man and thief, the consummate Gentleman Bastard. Teaming up with Jean Tannen again for the ultimate con, against the ultimate gambling house, the Sinspire. Jean is the brawn to Locke's brains, and together they get themselves into (and quite often out of) all manner of trouble.

The set up is coming along quite nicely when Locke and Jean are sidetracked, and forced into piracy with a unique and deadly threat. When you don't know how to sail, nor the difference between a binnacle and a barnacle, you know that things are going to get hairy.

In this almost madcap escapade, Scott Lynch has created a rather fun world where Locke and Jean run rampant. The twists and turns, while sometimes comedic, are always entertaining and there were only one or two places where the pace slowed. All in all a great read and this reviewer will be on the lookout for future Gentleman Bastard Sequence titles.