Setting up Emacs spell checking on OS X

As I mentioned in yesterday’s post, I’m trying to improve my blogging workflow by using org2blog to draft my posts before pushing them to my WordPress blog. When I posted yesterday I had the basic workflow going, could edit posts in Emacs, save them, update drafts and push them to WordPress. The last piece that was missing was getting spell checking to work.

I’ve actually never spent much time thinking about spell checkers until I discovered that OS X doesn’t come with a spell checker that ispell recognises. A little research led me to Joel Kuiper’s blog post on spell checking in Emacs on Mac OS X. I decided to install Hunspell as it seemed to be modern, supported and able to do the job. Plus, it’s available via Homebrew which I’m already using to install other Unix software on my OS X machine. A quick

brew install hunspell

followed by me grabbing the German and English dictionaries from and I was in the spelling business. Just make sure that you unzip the .oxt files containing the dictionaries, copy/move the .dic and .aff files into either ~/Library/Spelling or /Library/Spelling (I prefer the first one) and run hunspell -D to check that it’s picking up the files. Oh, and don’t forget to set up soft links from default.dic and default.aff to your default language’s dictionary files.

Now I should be able run M-x flyspell-mode and we’re in business, correct? Only we weren’t, because my Emacs setup couldn’t find hunspell. Oops. Turns out I had neglected to add the Homebrew installation directory to the exec-path, with predictable results. The following code in my .emacs fixes that:

;; On OS X/Darwin, make sure we add the path to the homebrew installs
(when (string-equal system-type "darwin")
  (setq exec-path (append exec-path '("/usr/local/bin"))))

With the above in place and Emacs being able to find the hunspell executable, it was time to add the following code to my .emacs to ensure that ispell and flyspell use hunspell if it’s available:

(when (executable-find "hunspell")
  (setq-default ispell-program-name "hunspell")
  (setq ispell-really-hunspell t))

Now flyspell-mode is happily running using Hunspell at it’s time to crack open an adult beverage.

Improving my blogging workflow using Emacs (of course)

I try not to post too many metablogging posts. Other people do it better and I’m trying to focus on journalling what I learn as a software engineer and manager, not what tools I use for blogging. However after losing another post to WordPress’s built-in editor I decided Something Must Be Done. I think this is only the second post I lost, but it’s a fairly regular occurrence for a journalist friend of mine and I really don’t have that much time to retype blog entries that ended up in Bit Nirvana.

My first attempt was to resurrect the weblogger-mode setup I used to have a while ago but after switching the admin interface on my WordPress install to https, I couldn’t quite get it to work again. Plus it was a bit of a half hearted attempt as I never quite warmed to this mode in the first place. It’s actually quite odd as I tend to use gnus semi-regularly and the interface is very similar, but it never quite clicked for me for writing blog posts.

If I would exclusively blog on Windows, I’d just use Windows Live Writer, but as I switch between Windows, OS X, Linux and FreeBSD depending on which machine I’m on, Windows only software just isn’t going to cut it.

As everybody raves about org-mode (which I admittedly have never used) I decided to give org2blog a chance. It’s probably not the smartest idea to try to learn too many new tools at the same time but at least Emacs doesn’t occasionally eat my scribblings. Plus, I’ve started using Jekyll for another one of my experimental blogs, so using org mode and having they ability to publish to a Jekyll blog is also very useful.

So far I’ve got the basics up and running and the main blog configured. I’m using visual-line-mode to do automatic line wrapping and now will have to set up flyspell on the machines that haven’t got it installed yet so I can have basic spell checking.

So far, the basic workflow I’m planning is:

  • Sketch the post(s) and write the drafts in Emacs in the comforts of my local machine
  • Publish them as drafts to my standalone WordPress install
  • Do the final editing and spill chucking in WordPress
  • Ignore or heed the recommendations from the WordPress SEO plugin. That’ll be mostly ignore, then
  • Schedule the final publishing on the WordPress admin console

Hopefully that should work better than the “log into WordPress and start typing” approach I’ve used so far.

Go read Matt Kline’s post on Shipping Culture, now

Over on, Matt Kline has an interesting blog post on how Shipping Culture is hurting us as an industry. Hop over there and read it now, because he addresses another case of the pendulum having swung too far. Your developers take a long time to get a new version out? I know, let’s make them ship something half baked. Quality is overrated anyway. Especially when you don’t have a reputation to lose as a maker of quality software.

If you only read one section of the post, read the part about Anti-Intellectual bandwagons. It summarizes one of my big annoyances with this industry, namely that we seem to dabble in collective amnesia combined with a side helping of AD… oh look, shiny!

That said, we are good at reinventing the octagonal wheel with a slight wobble around the axle.



Three top tips to ensure your resume gets read

We all know good people who can’t get a job for some odd reason, but whenever I find myself on the other side of the table I am amazed at how people don’t even bother to follow a couple of simple steps to massively increase your chances for a response. Yes, a lot of big companies seem to have their jobs email address hooked up directly to /dev/null but small companies still make up the majority of the software development landscape. With a small(er) company, there’s a good chance that your email ends up directly with the hiring manager. Somebody like me, for example.

Put yourself in my shoes. I have a job ad out because I want/need to hire a developer. I’m trying to actually fill the position, but it’s not my day job to do so. I also have made it easy for you to apply. Make it easy for me to pick out your resume from the piles of scatter-gunned resumes from the people who seem to apply to every position advertised, ever, and you’ll massively increase your chances of getting hired.

Yet the majority of the people who send in their resume seem to actively trying to prevent themselves from getting hired, so I put together a couple of tips for you to massively increase your chance at making it past the Cerberus at the front door.

The “method” is so simple I am constantly amazed that people don’t seem to do it, so here are my top three tips to make sure that someone like will look at your resume.

Read The Job Ad

I know, this sounds extremely simple, doesn’t it? Yet I am amazed that every time I post a job ad, I get ample proof that people are either unable to or unwilling to read the job ad all the way to the end to the end.

Not a good idea if the instructions for sending in the application are at the end of the ad, is it? And yes, they are in that particular spot for a reason, namely to determine if take your application seriously enough to actually bother reading the job ad before scatter gunning your resume to everybody.

Be considerate enough to write a short introduction

It’s the age of email. I’m not looking for a cover letter printed on 150g handmade paper – although that would certain pique my interest – but at least give me a hint as to why I should look at your resume. I’m constantly amazed at how many people don’t even bother with a short, to the point cover email.

My current “favourite” cover email read “resume attached”. Oddly enough, I could see that without any help. It also triggers my giving-a-shit filter – if the applicant can’t give enough of a shit to introduce themselves and write a couple of lines as to why I should consider them for a position, I have a hard time giving enough of a shit to open their resume, let alone read it.

If you’re not a perfect match, tell me why I should consider you anyway

Yes, most job ads these days seem to be overly specific right to the colour of the plaid hipster shirt you have to wear to work, but given the shortage of really good developers most people look for three qualities:

1. Are you a competent, well-rounded developer? Not a “competent developer in language X that nobody has ever heard of using frameworks Y and Z that only three people on the planet have ever used” competent but “show me you grasp the concepts, are able and willing to learn new tools” competent. Grasping the concepts is something that seems a bit old-fashioned these days, but trust me, it actually will help you have a long and fruitful career.

2. Can you get things done? Most companies’ development teams are short-staffed because there’s a surprising number of candidates that can’t get over hurdle 1). Because of this, teams need to do a lot with fewer people than they want to have on staff so the ability to deliver is highly rated. Plus, being fluent in thirty languages and sixteen frameworks is nice, but won’t help if you can’t deliver that user stats page that I’ve been bugging you about for three weeks now. So yes, a proven track record of putting things out there that don’t break the first time they’re exposed to sunlight is rather useful.

3. Can you and do you want to work with my team and vice versa? The longer I am in this business the more I really deeply understand the fact that it’s a people business. If I get the impression “oh yes, I really want to work with this person” after reading your resume and talking to you on the phone, you’re more than halfway to landing the job.

If you can clear these hurdles, then most of us will happily overlook the fact that we supposedly want someone with ten years’ experience writing Swift code.

I also like to see people who demonstrated that they are curious and were happy to work in very different environments with very different technologies. Curiosity is an integral part of being a good, well rounded developer so I’m happy to see people’s curiosity following through their career rather than the traditional “I’ll do the same thing for the next twenty years because it pays the bills”.

In fact, I’ll guarantee that if you follow the points in the three sub-headings when applying to a job on my team, you will at least get a response from me. That’s a lot more than you’ll get from most companies.