/dev/notes

While there is scant sign of the current general economic malaise breaking, Developers, and Web Developers in particular are enjoying strong demand for their skills. So with good opportunities available for talented developers it's worth making the effort to differentiate yourself and take advantage of the favourable job market. Perhaps the most important tool at your disposal, is your CV.

It's good to think of your CV as like a tool, no different from a programming language or an IDE. Like any tool it has to be rigorously tried, tested and possible refactored if it is to be successful and help you achieve your goals. In the case of a CV its purpose is two-fold, a) to get yourself past a recruiter and onto the actual client and b) to impress the client sufficiently that they want to interview you. So in the spirit of the new year and everyone having 'ten things' lists, here's mine for what to avoid in a modern CV for an IT role:

1. Don't send an old CV. If you haven't updated your CV in months, let alone years, it isn't going to sell you as effectively as it can. As a developer or even a recent graduate you're learning all the time. Detail and demonstrate as much of that learning (that is pertinent to the job at hand) as possible. As you get older, more experienced, your perception of what is and isn't important improves. While recently reviewing my own CV I found I had added a significant amount of detail, while actually reducing the overall bulk of the document.
2. Please, do not include an interests section. This point is somewhat subjective I grant. But of the CVs we've been forwarded all but one had an interests section. Not one of these contained anything relevant to the job being applied for, and in some cases actually contributed to us ruling the candidate out. When hiring, a client is seeking a professional. Telling them you spend a lot of time playing 'World of Warcraft' in your spare time isn't going to get them jumping out of their skin to interview you - particularly if you don't qualify how that interest is relevant to you performing the duties required.
3. Avoid sending a generic CV. Applying for jobs is tedious, time consuming and not immediately rewarding. But sending a generic CV detailing every subject you did at GCSE and A levels doesn't tell the client why they should hire you, and you specifically, for the job at hand. Oh and most clients seeking developers don't care if you worked at Subway or have a Tesco certification in fish mongering, it's simply not relevant.
4. Web 2.0 extravagance might be 'in' right now, but try to keep your CV conservative, well spaced and using a minimum of fonts. Giant mastheads, fancy bullets, a giant mess of fonts, it isn't impressing anyone, seriously, and most recruiters gut your CV into a standardised format anyway. Do be mindful of how it is to read. Clean and clear is the key, but save the extra special effort for the content.
5. Don't go on for longer than two pages. Trying to cheat this rule by making the font so small that a microfiche reader is required is only going to annoy the recruiter. That means your CV gets forwarded to the 'round file' not the client's inbox.
6. Don't list every course you did at University and expect the client to care. Of our graduate applicants not one has detailed what the courses actually contained. Database Systems 1. Cool - and you did what exactly in that course that is relevant to the job? It's often difficult for graduates to pad out their CV in the same way as someone with a few years' experience. Treat your degree like a job, work out what specific skills you got from your courses and detail the skill qualified with a practical example of how you applied it in your course work. Start doing that for all of your courses and very quickly you'll bang into the two page rule. Keep going, but when you're finished pare down the text into bullet points that are directly relevant to the job spec.
7. Spelling mistakes! Simply do not forget to proof read your CV. This really ought to go without saying. Get your sister, mother, girlfriend, house mate, anyone, to read your CV before sending it. Read it backwards, turn the zoom up to 400% and read it one word at a time. Anything to ensure that what you send out is as professional as you are. A sloppy CV leads to a sloppy impression. 'The Halo Effect', while not always fair, is something you have to deal within the real world. If a client's first impression of you is a bad one, all subsequent impressions will be shaded by it.
8. Don't include a picture of yourself. Like ever. It's simply not necessary.
9. Don't ramble, don't generalise, don't make statements without qualification. Good use of English is one of the best indicators of a good developer. Good code is succinct, clear and well qualified (unit tested). Like PHP, Java, indeed any programming language, English has a grammar, a vocabulary and patterns of use. Make best use of these attributes in your CV. Constantly refactor your CV to weed out redundancies, group like concepts, simplify and support the concepts. Like good code, a good CV goes through many iterations until it's 'good enough' for the real world. Mercilessly refactor your CV as you would your program code.
10. Don't accept everything you read on the net about CVs as gospel. This caveat applies to everything in life and not least this blog itself. If you listen to every top ten list of what not to include in your CV you'll quickly find out there's absolutely nothing you should put in your CV. Critically consider what you read suggested about what a good CV looks like and make your own mind up based upon the supporting arguments made and your own CV's feedback. For example if you disagree about point two and decide to include an 'interests section' ask recruiters when they call you what they think about it, did it provide value or was it noise? If you're getting interviews ask the recruiters what in your CV is standing out. If you're not, then ask what, if any, feedback there is from the client - and react to it.

I really do think of a CV like program code or a developer's utility. As a good developer you always need to evaluate your tools to ensure they are providing the maximum value. And like program code there is always an element of entropy to catch and counter over time. A CV, like program code, can sometimes be brittle and break with additions. Using and maintaining one is a matter of constantly reviewing, refactoring and responding to user feedback. For some good resources on CV writing I really recommend the following links: http://www.harveynash.com/uk/hnit/jobs/articles_cv_basics.asp http://www.lifeclever.com/give-your-resume-a-face-lift/ And for graduates especially: http://www.kent.ac.uk/careers/cv.htm

Now after the hype surrounding the language has died down somewhat, I'm getting acquainted with Ruby and learning the ropes.

To guide me through the Ruby syntactic jungle is O'Reilly's 'Learning Ruby' book. I checked out the ubiquitous Pragmatic Programmer's 'Programming Ruby', but the third edition seems more suited to stopping doors than teaching Ruby.

Reading through the first few chapters of 'Learning Ruby' has left me a little nostalgic of the early 90s when I was going through my first programming book 'Learning Perl'. Maybe it's the title similarities but mostly it's that Ruby's syntax feels as slippery to me as Perl's did.

I don't mean that in an endearing way.

While I'm in love with blocks (or closures whatever you prefer) and Procs and Mixins (Traits), a simple thing scares me. Constants.

Constant, the word is pretty clear in its meaning. It is a value which remains stable over time. Wikipedia says: 'a constant is a special kind of variable whose value cannot typically be altered by the program during its execution'. Collins dictionary says: ‘something that does not or cannot change or vary’.

Ruby though, says no. Constants are just global variables declared capitalised. Oh sorry that should be capitalized. Ruby doesn’t speak English, only American. A constant in Ruby is about as constant as your discipline. If you REALLY want to change its value, Ruby wont stand in your way, or even make it that hard to do.

That really, really concerns me. Part of the appeal of Ruby, I guess, is that it lets you do things you want, your way. Maybe it’s ‘Fear’ but I really don’t want to have to worry about my constants changing. Ruby makes a big deal of its ‘duck typing’ You know, if it quacks like a duck, it is a duck. Unfortunately in Ruby a constant quacks like a duck but it bites like a hippo.

Hopefully this saves s'one some time, when trying to get an oauth token from salesforce use the login server instance, not your regional one

Another #salesforce timesaver, when making your oauth login request, ensure you DO NOT submit it a multipart form request.

Native OSX SOQL Tool! http://bit.ly/fBoKia

If you're working with salesforce, definitely checkout the force api explorer app, great to quickly test soql queries: http://bit.ly/hov5qo

Zend Framework life saver Zend_Db_Select::assemble() - outputs the objects current sql state.

If you're a design challenged developer like myself http://www.colourlovers.com/ will help you pick a cohesive colour palette for your application.

Some people using #VIM comes naturally. I.e. they have been using it for 25 years. For the rest of the world there is http://vimcasts.org/

RT @oliklee: Just finished the #phpunit mock #cheatsheet for my workshop at #t3con10: http://bit.ly/dcru3c

Handy method Zend_Db_Select::assemble() will output the select object's state as sql. Very handy when debugging.

Sometimes you don't have the unix util seq available (i.e. macosx). 'jot' is your friend, note the args are backtofront: seq 1 12 = jot 12 1

RT @shiflett: I never knew the Google Cheat Sheet Existed. I see myself using the synonym operator often. http://j.mp/googcheat /via @gnat

Many PHP programmers today fall into two camps: those that are self-taught and learned PHP to make a website, or those coming out of university Comp Sci courses heavily grounded in strictly typed OO (I.e Java).

This is, of course, not absolute, there are camps of reformed Perl sys-admin monkeys that haven’t been seduced by Python. And of course a rare breed of ex systems programmers versed in C and C++.

It is actually this last group of coders that tend to get on with PHP the best.

This makes sense, because PHP was originally designed to be a template engine to produce HTML with a core C backend doing the grunt work. This seems a ridiculous idea now, as CPU cycles are much cheaper than man hours. But in the late 90s native code ran circles around dynamic, interpreted alternatives.

These days C is a little bit like ASM was in the 90s. Being proficient in it is handy, but not essential. I would argue though, for PHP coders it is an important environment in which to be familiar.

Many of PHP's eccentricities can be traced to it’s C roots. The strange and inconsistent function parameter orders, right down to the sometimes peculiar way it handles memory and references.

The file and string functions marry up almost 1:1 with standard C. Experience of and understanding of how these low level functions work will immeasurably improve your application of their PHP counterparts.

Networking is another area where PHP and C are very similar. Indeed you can write a simple tcpclient in PHP, get rid of all the $ variable identifiers and have a recognisable C fragment.

The biggest benefit though of learning a bit of C or C++, is to get an “appreciation” of memory management. C is unique among the programming environments of today in that it does not manage memory for you. Arguably this is what makes C so painful to develop in. But similarly, a sometimes useful characteristic that makes the environment still relevant today.

By way of example, strings in C are represented by an array of chars, terminated by a NUL ‘\0'.

In C, you would declare a string like  this: char str[20];

This declares a string of 20 characters, and str itself points to an address in memory where 20 bytes have been reserved for itself. Now if we try to write 21 characters to this string, C wont autoexpand the array to fit, or do anything so helpful as to warn you that you’ve gone out of the bounds of your allocated storage. No, C will do what you tell it, and in this case it means overwriting someone else's data.

This is quite a powerful characteristic and as such requires a programmer to be responsible.

Generally if you have a 20 char string defined but want to store a 25 char string, you need to reallocate memory. You could declare a new array or do a concatenation operation. Either way, this costs CPU time.

So when in PHP you are spamming '.' concat operators everywhere, you can appreciate that PHP is doing a lot of memory re-allocation under the hood to provide that syntactic sugar.

As mentioned above, PHP was originally intended to be a purely templating language for C web applications. Which is where PHP modules / extensions come in. These originally were where your business logic was to go. PHP extensions are compiled to native code, and as such run FAST. You can then access these functions in PHP just like the other core functions and classes. Yahoo, Facebook, use PHP in this way.

So can you. A great way to dabble in a bit of C is to write your own PHP extension. The benefit of getting your hands dirty in this way is the nice speed boost for the functions in your extension. But the more important benefit is how it can greatly improve your understanding of what PHP does for you under the hood. This lets you make informed design choices when writing your regular PHP code.

As a starting point, I can thoroughly recommend starting out with the Zend engine hacker's guide on the main PHP site. Becoming familar with the structure of the internals is the first step to appreciating all the of the magic PHP does for you under the hood.