Headphone sexism

Of all things I have an opinion on, the shape of headphone jacks is perhaps one of the most benign. I prefer L-shaped jacks, as opposed to straight ones. The reasoning is simple:

Women's jeans have stupidly small pockets, and the only way you're going to fit a phone in there is if you put it in sideways. This means that there will be a snug fit for the headphone jack.

The cable inevitably needs to fold at around 90 degrees to go out the pocket, which inevitably stresses (and breaks) the headphones.

The L-shaped jack solves this problem by bending the cable with no stress. Perfect for women's trousers.

CNET recently spoke with Sean Garret, VP at Bose, about the shape of a headphone jack (L-shaped vs straight), explaining why all modern jacks are straight:

You naturally slide your phone into your pocket so the cable comes straight out of your pocket first.

I see nobody in Bose's design team wears women's clothing.

Samsung gets creepy


Samsung has been granted a patent in South Korea for contact lenses with a display that projects images directly into wearer's eyes

Questions about how the eye is supposed to focus on the image without causing eye strain aside, here's the creepy bit:

A built-in camera and sensors are controlled by blinking.

At least, Samsung holding the patent might hold back masters of Creep, Google.

Maybe we could tone down the JavaScript

Something that's been on my mind for some time, but have never been able to find a way to put it across. Eevee does it perfectly:

Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can.

Yes! We have (largely) moved on from noscript tags, but javascript can (and does) do weird things in weird ways, simply because you can't control the environment.

So whenever you can, don't expect your scripts to download, or work.

Or, as I like to think about it: if you are rewriting a browser control, ask yourself why.

Speaking: McrFRED 35

It's McrFRED next week, and it's lightning talks. I will be practicing my talk about code reviews.


So, you do code reviews, and that’s great. But there’s always more that you can check during the review. More places you can check for any potential bugs or problems before deployment, before you find yourself with technical debt. Or worse: unforeseen downtime.

In this talk Clair will be going through the things that you should be checking to ensure confidence for developers, project owners and stakeholders. We’ll be looking at documentation, commit messages, and common code problems, with examples and tips along the way.


How to brick your phone

9 to 5 Mac:

Several users have discovered that if you change your iOS device’s date to January 1st, 1970, your device will be permanently bricked

Oh, Apple.

Apple finds new bug in News


[Apple] mistakenly has been underestimating the number of readers using the News app since its launch, and passing that inaccurate information on to publishers.

Eddy Cue, Apple’s senior vice president of Internet Software and Services, said the company missed the error as it focused on other aspects of the product. The company didn’t explain how the problem occurred or say exactly when it might be rectified

Another in a long line of embarrassing problems in Apple services because of poor testing.

[B]ut he added that it was better to undercount than overcount traffic.

And to show just how out of touch some Apple execs can be, Cue says how it's better to have publishers undervalue their advertising, and potentially lose revenue.

Does anyone trust Apple services anymore?

Stop doing Agile. Stop pretending

It’s not worth it. Again, either you commit to the principles, practices, and the mindset of solid agile development OR you don’t. There should be no try! Trying is a waste of your time and it belittles the efforts of all of those folks who are working hard at the methods and getting solid results.

The worst kind of agile is half-hearted agile.

Other processes have their uses. But Agile is too often seen as a buzzword. It's fine to not follow Agile process. Just follow something.

Searching for emails by date/time in Google Mail

I've recently had need to search for emails received after a specific time: as in, "After 3pm on the 1st January 2016", and not "After the 1st January 2016".

Google's documentation isn't very helpful with this, and all I could find on Google's help pages areunhelpful "nope" answers.

I disbelieved that this is something Google would neglect to allow for so long. Luckily, I was correct.

You can achieve this if you use the Epoch timestamp instead. For example, to get all emails sent/received since 3pm on the 1st January 2016 (in GMT), all I need to do is search for:


QA is more important than you think

Often, I hear people say how they don't need testers. Thay aren't at the stage where they need to consider QA. They want to get a minimum viable product launched, and they just want something done as quickly as possible.

Sure, you may not be able to afford a dedicated QA engineer in your team: that money sometimes isbetter spent on development talent instead. But, my belief is, you can't not have some kind of QA process in your team.

First, a quick definition of 'QA' and 'Testing', so that we're both on the same page:

  • QA — The practices of ensuring that the product is the best it can be. No one person is responsible for QA. It casts a wide net and includes (but is not limited to) standards compliance, accesibility, user testing and feedback, knowledge of systems, website copy, speed of application, security, and quality of code.
  • Testing — The process of checking an application: this can be both automated or manually performed, usually by a Test Engineer. It's a small part in the overall QA process.

The importance of QA

Let's say, I've got myself a brand new toaster. I'm proud of this toaster. It looks awesome, it came in a really nice box, and it can toast four slices of bread at the same time.

I proudly unbox my toaster and plug it in, ready for the next morning's breakfast.

Fast forward to the next morning, I excitedly get some bread out and put it into my fancy new toaster. The bread doesn't quite fit, because the slices are pretty thick. Nevermind, with some effort I can get them in.

The dial is a bit fiddly... it's towards the bottom so I have to lift up the toaster to move it to the setting I want. But that's ok, I only need to set it once.

But it isn't ok. It's the small things, like how little effort it takes to put bread into a toaster, which make a product great. It's what makes people enjoy making their morning breakfast.

QA is the process in making sure everything is as good as possible, given constraints. That toast which was slightly too thick? QA is all about asking "But how thick is sliced bread?"

It's the same in software. You want people to enjoy using your product. Afterall, wouldn't they just go somewhere else if they didn't?

It's not like a toaster where nobody is likely to return it if it's not quite right. If I don't quite like Firefox, then I'll just dowmload and start using Chrome. If I didn't quite like Twitter, I would no longer use the service.

The importance of testing

I'm not saying that you need to carefully consider everything about your product, and to never release anything until it's perfect. It's not possible to do that. But I am saying, you need to make sure that everything works.

Don't just write code, save it, perhaps quickly check it and then deply your changes. You need to check to make sure nothing is broken. Developers are humans and very often make mistakes.

You need to test it.

Automate it

Automation is no replacement for a real test engineer, but it's a pretty close second. A developer can relatively quickly write automated tests, which can (and should) be ran often. That way, if anything goes wrong, the developer will quickly find out if anything doesn't work as expected.

Automation can even have its advantages: automated tests don't get tired, hungry, grumpy, or bored.

Takeaway (aka. tl;dr)

Yes, QA can be a rabbit hole you can easily fall into if you want to. But testing is important. Crossing your fingers and hoping for the best isn't the best strategy: when you make changes, you need to make sure everything is still working as you expect.

The more consistant, and cheaper, way to do this is through automated testing.