melreams.com

Nerrrrd

I Google things professionally

in development, opinion

It’s pretty common to hear developers joke about how they get paid to Google things. Fun fact: we’re only kind of kidding. An enormous part of my job is Googling stuff.

Tech changes so quickly it’s just not possible to know everything. It’s definitely not possible to keep up with everything, and it’s especially not possible to know the entire tech stack a new job uses. No two company’s tech stacks are the same (we use AWS, play, Java, Ember, javascript, and bootstrap, just to name a few of the languages and frameworks in our app. At my last job we used spring, jetty/tomcat depending on the app, an internal front end framework, Facebook’s hideous sdk, and Flash (AS3) and Unity on the front end), and even if you did magically know all of those technologies before you started, given a few months it wouldn’t matter. No matter what you use right now, things are going to change. You’ll try out a new front-end framework, integrate with a new system, be asked to build a feature that requires a new library, something will happen that means you’ll need to learn something new.

two women of colour working together at an Apple laptop
Photo provided by WOCInTechChat under a CC Attribution-ShareAlike License

This is why developers spend so much time Googling. We have to learn new stuff constantly. Don’t feel bad about not knowing everything, no one else does either.

Even if your tech stack didn’t change, you would still get asked to build new stuff all the time and honestly, your problem is probably not unique. Even if you already have a plan, it’s not going to hurt to do a quick search and see if someone else has a better way to solve your problem. If you don’t already know how to solve it, Google is here for you. Why reinvent the wheel? You could call that laziness but honestly it’s inefficient to fight with a problem for hours when you could just ask Google for a hint. Work is not an exam, you’re getting graded on how much you produce and how solid it is, not the intellectual purity of your solution. Plus, next time you have to solve a similar problem you’ll remember what you did last time.

Now, you do need to make sure you actually understand the code you found (and that you’re not violating any licences or anything), but if you’re a professional you’re doing that anyway, right? If you don’t understand your code you’re just going to end up wasting time chasing down weird bugs. Don’t forget that software is at least 90% maintenance, you will touch that code again and you need to understand it when you do.

Of course, I’m being a little bit flippant when I say I Google things professionally. A big part of being a professional is knowing how to search, what to search for, and how to tell useful results from dead ends. Learning how to look stuff up is a real skill and it’s one that takes practice. You also need a bit of a knowledge base to tell good results from bad ones. That is, the more you know about, say, Java, the easier it is to tell a good solution from a bad one. A combination of having a feel for the way Java does things and knowing what good Java looks like makes it much easier for me to tell whether that Stack Overflow result is actually a clever solution or whether it’s a filthy hack. Sometimes you do need to use the filthy hack but you should at least know that’s what you’re doing and add a comment about it.

Software development is at least as much about knowing how to learn as it is about knowing stuff in the first place. If you can learn how to search effectively and are willing to brute force (seriously, a huge amount of my college education was banging my head against java until it started to make sense) the conceptual framework that lets you make sense of the results you’ll get when you search, you can be a programmer. It’s not all Google but honestly if you’re good at Googling and are weird enough to actually enjoy programming, you can do it professionally. We like to pretend we’re wizards but it’s mostly Google :)

“Show me what you build, and I will tell you who you are.”

in development, opinion

I think this talk by Eric Meyer is really interesting and worth watching. Be warned, he does discuss his daughter Rebecca’s death of brain cancer (not in detail), so maybe you don’t want to watch this one at work.

Aside from the crushingly sad part, he has some really interesting stuff to say about how the way we build the tools we do (social media like twitter, facebook, linkedin, for example) reflects our values and how that will shape the next generation’s view of what’s normal on the internet. Like he says in the talk, “Show me what you build, and I will tell you who you are.”

When is it done?

in career, development, opinion, project management

“Done” is a surprisingly ambiguous word in software development. Back when I was in college I thought an assignment was “done” if it compiled and produced more or less the result I was expecting. Then I got a job in the industry :)

It turns out “it compiles” doesn’t mean much when you need to ship software that handles edge cases correctly and works in more than one browser and doesn’t throw exceptions when it’s used just slightly differently from the way I assumed it would be when I built it.

Another complication is that people use the word “done” to mean a lot of different things. I’ve heard people say “it’s done, I just need to test it” and “it’s done, I just need to integrate it” and “it’s done, it just needs to go through QA” and “it’s done, I just need to fix a couple of bugs.” It’s certainly useful to know what stage of development a feature is in, but none of those are done.

To me the only meaningful definition of “done” is “ready for production.” That is, is when the developer has tested the feature, QA has passed it, it’s been merged onto the production branch and any regression testing that needed to happen is done. When it’s ready to be deployed it’s done and not before.

That may seem overly picky but imagine how far off the rails things go when one person thinks done means “ready for QA” and someone else on the team thinks done means “ready for production.” If your feature (or project or report) isn’t actually done, your team lead needs to know that whatever other task they give you might get bumped if your original task comes back from QA with bugs. Obviously you should aim for bug free features but in reality things don’t always go according to plan. That’s why we have a QA department in the first place.

And to go on a bit of a rant, that example above of “it’s done, I just need to integrate it” is not even slightly done and is almost always a terrible idea. If you’ve developed something outside of the system it’s going to be a part of, you’ve exposed yourself to an enormous risk of terrible surprises. Sure, you’ll be fine if you just happen to have a perfect understanding of every little quirk of the larger system, but let’s be honest; you do not. Unless it takes a truly intolerable amount of time to compile the main system, you will actually save time in the long run by building your feature directly where it’s going to be used and just getting up for a drink of water or something while your project compiles. You’re almost guaranteed to have to compile repeatedly while you get your feature integrated anyway, so you’re really not saving any time by developing in isolation. Now, the plural of anecdote is not data and other people have probably had different experiences, but I have personally never seen that turn out well and strongly advise against it. Okay, rant over.

We like to pretend software development is perfectly logical and unambiguous, but you’ll actually run into issues like different definitions of done all the time. Even if you feel dumb doing it, it’s often really helpful to ask teammates exactly what they mean. A surprising number of the problems you’ll run into developing software are just miscommunications that could have been cleared up with a five minute conversation at the beginning of the project. Interfaces between client and server code in particular can be tricky. I’ve personally had to throw out work because I misunderstood what the client team actually needed and built something that was pretty close but not quite right.

Just because you think you know what your teammates mean when they say something as simple as “done” doesn’t mean you actually do. I’d love it if we could all agree what done actually means, but until then you can save yourself a lot of trouble by asking questions.

Ember tip of the day

in ember, facepalm, tip of the day

If you happen to find some example code that elegantly solves your exact problem, check which version of Ember it uses. Sometimes that perfect example is a few versions ahead and will do absolutely nothing for you. If you’re smarter than I am and check the version number right away, you can save yourself a good half hour of cleaning, rebuilding, and cursing.

On the upside, if you need to iterate over a map with {{#each foo in bar}}, you can hammer together a workaround using Ember.keys(map) – but again, only if you have the right version of ember. Ember.keys() was deprecated in 1.13, use Object.keys() instead if your version of Ember is later than 1.13.

 

Android app of the day

in android, android app of the day, tip of the day

Smartphones are freaking amazing for absent minded people like me. I’ve been able to give people the totally false impression that I’m organized because I put reminders for absolutely every appointment into my calendar :) Another way I trick people into thinking I can remember to do things is by using a handy little android app called toastr (sorry iOS users, there doesn’t seem to be a version for you).

Toastr does one thing and one thing only. Every time you unlock your phone, it pops up a little notification with whatever text you set. That’s it. The interface is gloriously simple and requires absolutely no screwing around in convoluted settings menus. If you need a quick, easy reminder to do something (calendar reminders are great but they’re slow to enter and sometimes you don’t know exactly when you’re going to be able to do the thing), toastr is just about the perfect solution.

Toastr is also really satisfying from a design perspective. It knows what it’s for and doesn’t try to be all things to all people. It’s not pretty, but it doesn’t waste my time asking what it should look like. You can get a pro version of toastr for 99 cents that does have some largely useless notification customization features, but I can understand why the developer felt compelled to add more features to the pro version and at least it doesn’t beat you over the head with them.

If you need a really simple reminder now and then, give toastr a try.

Why your QA department is smarter than you

in development, opinion

Something that’s baffled me for a long time is the animosity some programmers have for the QA department. It’s incredibly frustrating to try to get a feature out and have QA find bugs over and over, but that’s not the QA department being jerks, that’s them doing their jobs properly. QA people actually do a lot of awesome things for us developers. They protect us from releasing a broken product and looking like dumb jerks who don’t care about doing good work. They give us bug reports that actually make sense and can be reproduced. They protect us from the wrath of the thousands of angry people who just wanted to be able to use the thing we released.

QA just wants the project to work when it comes out, which is the exact same thing I want. I don’t want end users to have to wonder whether I’m terrible at my job or whether I just don’t care. Personally I’m a terrible tester, but if a product comes out broken there’s no way for end users to tell a dev who tries really hard but isn’t good at testing from one who counted the minutes until they could go home. I don’t want to look like a fuckup. QA protects me from that, which is basically the nicest thing they could possibly do for me.

Another great thing the QA department does is produce usable bug reports. If you don’t appreciate good bug reports, you haven’t worked in the industry for very long. I have had to try to work with terrible bug reports that had none of the details I needed, were not reproducible, were duplicates, and even reports of totally predictable problems caused by continuing to work with a broken account. A good bug report is a thing of beauty and you should appreciate it! Having a clear set of steps that reliably reproduce a bug saves you so much work. So much! This is extra true of game development where the lack of a single linear path through the product produces some truly weird bugs.

Aside from protecting me from looking like I’m bad at my job, QA also protects the whole team from the many angry people who will flood your customer service and social media with rants about how your product is junk and you should be ashamed of yourselves and they want a refund yesterday. Nobody wants to disappoint their customers, and no one wants to deal with that kind of PR nightmare. You might think that a few angry people are no big deal, but they can really hurt your business and they can hurt your whole industry’s reputation. Toward the end of 2014 so many big-budget AAA games shipped broken that it shook customer’s confidence in the entire industry. Obviously no-one’s releasing numbers about how doing a bad job hurt their sales, but it only makes sense that there is now a huge pool of people who simply will not buy a game until they hear from other players that it actually works.

Given all the great stuff QA does, why don’t they get more respect as a group? Well, in general the tech industry has a problem with fixating on developers to the exclusion of basically every other job title. It’s also not unusual for project managers and team leads to see QA as an obstacle to release the features that upper management is pressuring them for, which leads to nobody else on the team giving QA the respect they deserve.

QA is not just important, they want the exact same thing you do: to put out a good product. But if the rest of this post didn’t convince you, read How to lose $172,222 a second for 45 minutes and then tell me QA isn’t important :)

SMTP testing tip of the day

in SMTP, 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);
mailServer.start();

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!

in opinion

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, votetogether.ca will tell you which candidate in your riding has the best chance of beating the conservative candidate.

Play framework tip of the day

in 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?

in development, play framework

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}             Clients.show

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 Clients.show 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.