SMTP testing tip of the day

Through painful experience, I’ve learned that most dummy SMTP servers you can use for integration tests do not support SSL. This is more than a little irritating if you want to automate testing for SSL connections. Fortunately, there is one dummy email server that I’ve found that actually supports just about any protocol you could want, including SSL: GreenMail.

The GreenMail examples are very helpful, but there is one more piece you need if you’re going to test sending email over an SSL connection:

Security.setProperty("ssl.SocketFactory.provider", DummySSLSocketFactory.class.getName());
GreenMail mailServer = new GreenMail(ServerSetupTest.SMTPS);

That first line of code prevents you from getting a giant SSLException stack trace when your email sending code tries to connect to the GreenMail dummy server. Thank you stackoverflow!

Get out there and vote!

If you didn’t already vote in the advance polls, get out there and vote! Remember, if you don’t vote you don’t get to complain about the government ;)

If you’re not sure who to vote for, have a look at these 25 reasons Harper is bad for Canada, or Harper Watch, or shit harper did. Or just look at the news lately. If that’s not a reason to vote Anyone But Conservative, what is?

But wait, there’s more! In terms of reasons to vote for anyone else, Harper is the gift that keeps on giving:

Harper’s “old stock Canadians” line is downright racist and xenophobic

Harper: Niqabs ‘Rooted In A Culture That Is Anti-Women’

A detailed timeline of Stephen Harper’s weird, racially divided vision of Canada

The day Canada’s white supremacists saluted Stephen Harper

Harper’s proposed terrorism travel ban borders on racism: Toronto activist

Harper’s new Australian spin doctor is a raging anti-immigrant racist

Stephen Harper’s War On Women

Stephen Harper’s comments on missing, murdered aboriginal women show ‘lack of respect’

Canada’s Prime Minister Refuses To Take Additional Refugees After Backlash Over Drowned Syrian Boy

Premiers Say Ottawa Cutting Health Funding By $36 Billion Over 10 Years

C-51 will remake Canada in Harper’s paranoid image

It’s official – second class citizenship goes into effect

Harper Named World’s ‘Worst Climate Villain’ After Damning Report

Thanks to the All the Canadian Politics tumblr for that list of links.

Obviously you have the right to make up your own mind, but those are some pretty compelling arguments to vote Harper out. I am not going to pretend every political party is equally good for Canada when that is just not true. If you agree that anyone but Harper would be better, will tell you which candidate in your riding has the best chance of beating the conservative candidate.

Play framework tip of the day

Sometimes Eclipse will randomly decide not to rebuild your project, insist you haven’t added something that you just added, and throw errors all over the place. You can trick it into behaving itself by closing and reopening the project. I don’t know why that works but sometimes it helps when nothing else does.

So what is the play framework anyway?

The Play framework is a super scale lightweight java (and Scala) web app framework. It’s built on top of Akka, a toolkit and runtime, which, to quote their website: helps you build highly concurrent, distributed, and resilient message-driven applications on the JVM.

So why is Play special and what makes it so different from something like Spring?

Play gets all kinds of nifty async features from Akka. Normally java is all synchronous – if you need to get something from the database or from another system, your app blocks until it gets a response. Play doesn’t block, it just picks the request back up when the response comes in (or times out), allowing it to serve other requests instead of just standing around. This means you can serve more requests without paying for more servers.


Another cool thing about Play is that it’s RESTful by default. Play’s endpoint configuration lends itself really easily to clean REST interfaces.

Here’s an quick little example of how Play endpoint config works:

# Display a client
GET    /clients/{id}     

Isn’t that pretty? It’s so clean and shiny :)

GET is the HTTP method accepted for this endpoint, surprisingly enough. /clients/{id} is the URL (relative to your project). {id} is a placeholder for the client id that gets passed in as part of the URL, and is the controller and method that handle this request. Compared to old-school Spring xml config this is freaking amazing. I even like it better than Spring 3 annotations because all my routes are clearly defined in one file. If I need to look up the exact parameters a route needs so I can test it or document it or whatever, there’s one and only one place I need to look.

Play also has an awesome php-like “just refresh” workflow. Yes, if you can get Eclipse to talk to your local app server you can make a very limited amount of changes without doing a full rebuild and redeploy, but Play does it so much better. Once in a while I have needed to do a full clean and rebuild but only if the code has changed a lot, like when I switch from a feature branch with a major refactor back to the staging branch. If you haven’t done that, then Play will load your changes as soon as you make another request.

Another thing I really like about Play is its non-maven build tools! Play uses sbt (scala build tool), which unlike maven actually works. When you add dependencies, sbt pulls them in! every time! In the entire 8ish months I’ve been working with Play, I have never (not even once!) needed to delete my entire local repo and re-download everything like I used to have to do with maven all the time. I’d honestly rather manage dependencies manually by checking them all into my repo than use maven ever again, so you may want to take the maven hate with a grain of salt, but sbt really does work well.

Play’s config file syntax is in HOCON (Human-Optimized Config Object Notation, looks a lot like JSON), which is so much easier to read and edit than xml. It takes some work to write an invalid config, and even if you manage it it’s much easier to figure out what you did wrong and how to fix it than it is with verbose xml tag names.

As for the actual code, Play hasn’t been that hard to adjust to. I’ve been using Spring and Struts for years and the basic controller/action setup isn’t that different. The async stuff like Promises is pretty weird to get used to, but if you’ve done much of any javascript then it won’t be totally new. It’s not so very different from making an AJAX call – you know what you’re supposed to get back, just not exactly when you’re going to get it.

One thing to keep in mind though is scope, particularly if you’re also using a dependency injection framework like Guice. Every time you hand off computation to another thread you lose the previous scope. Things can get ugly when you thought you had a user account id in scope but it turns out you don’t – that might sound like a stupid mistake but it’s pretty easy to do if you’re trying to put together a complicated result with data from different subsystems. Thanks to the magic of dependency injection everything will compile happily and you won’t know you lost your id until you start getting dependency injection errors all over your logs.

All in all I’m really enjoying working with the Play framework and recommend trying it out.

Cold & Flu tip of the day

Get the fancy tissues with lotion. Yes they sound stupid. Get them anyway, they are really and truly worth it. And don’t push yourself too hard, you’ll just make yourself sicker. I’m still working on that one myself, but it’s good advice in general.


There’s no way I can possibly say everything about debugging in just one blog post, but I can certainly share a few useful tips.

First, let’s talk about what debugging fundamentally is. It’s the art of seeing what actually is, not what you meant or what you thought. It’s going to be uncomfortable, and if you get too tied up in your own ego you won’t be able to do it at all. Years ago one of my teachers at Camosun told us (I’m paraphrasing heavily here because I don’t remember the exact words) that there’s no point insisting you didn’t change anything. If it used to work and now it doesn’t, you obviously changed something. Just accept that you broke it and start trying to fix the problem.

One of the first things you need to do when you’re debugging is to make sure you can reproduce the problem reliably. If you can’t do that, then you don’t really know what the problem is (or you’ve got some sort of unholy race condition bug and you’re beyond my help :) ). If you’re not the one who found the bug, ask the person who did if they can show you, or ask for more information if it came through a helpdesk and you don’t have direct access to the user who found the bug.

Once you can reproduce the problem, you’ll be able to track down what’s going wrong and figure out whether a fix actually… fixes the problem. The first step I recommend after reproducing the issue is double checking all of your inputs, even the most stupid simple stuff you’re sure you couldn’t possibly have gotten wrong. Last week I thought I had broken staging when I actually just hadn’t chosen the right value in a dropdown box. Garbage in, garbage out, as they say.

After that, you’re going to be very tempted to just read through your code and hope you can spot the problem. Resist this temptation! I’m always pretty sure I know where the problem is or that it’ll jump out at me right away, but it almost never does unless it’s an extremely simple bug. Read over the code once if you really want to, but then move on to narrowing down exactly where the bug is. Believe me, it’s faster than staring blankly at your code and feeling dumb.

If you have a particularly chatty log, you may be able to start narrowing things down while you reproduce the issue. Start looking after the last log message you see before the bug happens. If you’re very lucky something will be obviously wrong close to the log line you were looking for.

If you’re not quite as lucky, you’re going to need to run the code locally and start commenting things out. Assuming you have some idea where the problem is happening, start dividing the method it could be in, in half. Either comment half of it out or add a log line half way through and see if you see that log line before or after you reproduce the problem. Keep narrowing it down until you know exactly where the problem is. Once you know exactly where the problem is, you should now know what’s going wrong if not exactly why. It’s not unusual to have to trace back through your code to find the place that set up the issue that wasn’t triggered until later. Bad config, for example, may not cause an actual bug until long after it’s saved.

The most important things you can remember when you’re debugging are to be systematic and to not make assumptions. Don’t assume that your input is good. Don’t assume that a certain piece of code can’t be the problem because it hasn’t been changed in ages/just passed testing/doesn’t seem to be related. Don’t assume that your config is what you think it is. Don’t assume that you know what’s going on – if you did, you wouldn’t have written a bug in the first place :)

Ember tip of the day

If you use Ember.js and you need to update one element of an array inside you rmodel, you need to use the .replace() method. Getting and updating your array will not work, neither will trying to use this.set(‘model.array[index]’). Ember won’t register your changes unless you call the .replace() method, so do that :)

And yes, I’m writing this blog post to remind myself, I spent a good hour or two earlier this week trying to figure out why Ember wouldn’t re-render anything when I tried to update part of my model.

Let’s try it and see what happens

On Saturday I mentored at the Ladies Learning Code workshop for National Learn to Code Day. As usual it was a great experience, although pretty draining for an introvert like me, but what I want to talk about is the single phrase I used most often with my learners: let’s try it and see what happens.

Now, I’ll freely admit that a good portion of the times I said that were because I didn’t have a lot of experience with the language we were using (python, if you’re curious) and just didn’t know what would happen :) But the bigger part was that I wanted to show the learners that it’s okay to not know what’s going to happen and to mess around and try stuff.

It’s normal to be worried that you’ll look stupid or completely break your program, but the only way you can learn a new programming language (or any language, for that matter), is by trying things and making mistakes. The great thing about programming languages is that failure is just about consequence free. If you get an error message, so what? It’s not even a waste of time, you learned something that doesn’t work. That gives you one less thing you need to try next time.

Even if you’re an experienced developer, you need to keep that willingness to try things and see what happens. Analysis paralysis is what happens when you’re afraid to try something. If you’re working on a large project it’s true that you need to plan it out carefully and run your idea past other developers, but sooner or later you’ve got to start building something even if you’re not absolutely sure it’ll work. The sooner you try it, the sooner you can figure out whether or not it’ll work and the sooner you can try something else. Thinking things through is great but you can’t let it stop you from doing something.

Sometimes no amount of planning can tell you more than a few hours of trying. This is especially true when you’re just starting out, but it doesn’t stop being true just because you’ve got a solid handle on how loops work. And honestly, even the most experienced developers get off by one errors sometimes :)

When you’ve been a developer for long enough, sometimes you lose track of what it was like to be a beginner. We start assuming that we should know exactly what will happen before we even write a line of code even though that’s not even slightly how it works. I feel like I’m raining on new devs parades here, but the uncertainty never goes away. You just work on a different scale when you’re more experienced. Instead of “what happens when I change this == to a >=?” it’s “what happens when I try to use this new library?” or “what happens when we try to make our system talk to this other system?”

The next time you catch yourself slipping into analysis paralysis (and I do all the time), just try something and see what happens.

Awesome Chrome extension of the day

I recently started using StayFocusd and it rocks! StayFocusd is a productivity tool that stops you from visiting websites where you waste time. Whatever your timesinks are (for me feedly and reddit are some of the worst), you just add them to StayFocusd’s blocklist and after 10 minutes (or whatever time you set), it blocks them. By default it also blocks links that you clicked while on a site in your block list. For example, if you follow a link from reddit, that still counts toward your 10 minutes of browsing for that day.

I’m not sure how I feel about having to outsource my self-control to a Chrome extension, but on the upside I get a lot more done when I don’t have to make the decision between doing work and checking feedly again for shiny new blog posts. Try it, you’ll probably hate it but you’ll probably get more done :)

The mythical man month

In the programming field, it’s pretty rare to find a book that’s still relevant even five years after it was published. The Mythical Man-Month is still useful forty years after it was first published, which is either amazing or depressing depending on how you look at it.

What depresses me about how useful the book still is so long after it was written is that in the forty years since, we clearly haven’t learned that much about how to run projects. I first tried to read The Mythical Man-Month ages ago, and I got so frustrated about how little we’ve learned since it was published that I had to set it down. Then I completely forgot about it for a few years because I’m just that organized :) I finally finished it this year, and it’s just as relevant as ever. By all rights everything in that book should be totally obvious and taken as a given by every project manager out there, but sadly it’s not. It is, however, kind of comforting to know that other people have run into the same problems I have.

The amazing part of The Mythical Man-Month is how clearly it shows that the actual programming is the easiest part. Code is simple compared to trying to coordinate a large team and hit a deadline, but as programmers we seem to get hung up on the easy part and largely ignore the hard part. One of the many terrible ironies of programming is that a field that attracts introverts who just want to be left alone to code actually requires huge amounts of communication if you want to get anything meaningful done. For me and probably for most other programmers the code is the fun part, so it’s understandable that we’re not as good at communication as we should be but eventually we’ll grow up as an industry, right?

As sarcastic as that sounds, I think a large part of what we need to do as an industry is accept that things just aren’t as easy as we wish they were and learn to work around it. It’s pretty similar to the way children grow up and understand that the world isn’t as simple as they thought and learn to work around it. I and every other programmer ever have massively underestimated how long something was going to take, and no doubt  we’ll all keep doing that. But understanding that underestimating tasks is common allows you to leave extra space in the schedule and/or prioritize features so you know what can be cut if you aren’t going to hit your deadline.

Basically we just need to learn to account for human nature. Should be easy :)