Question based debugging

This is a debugging technique which I imagine many developers just do in their head. I’m afraid I desperately lack the attention span though, and so find this method of debugging inscrutable anomalies really useful.

Here’s a simple breakdown, of what’s really a very simple system.

Ask a question to yourself, and write it down. The question should be about the problem you’re experiencing and should start very basic. It should question a premise which you expect to be true. More often than not the first question should be “does this bug still exist?” (Forcing yourself to see the bug is something that a surprising number of developer don’t do – jumping straight into the code instead.) Next to the question draw a checkbox. Later on the question might be “is the form sending the full file path?”

2016-03-17 21.49.25
Paper from Present and Correct, pen from Muji.

Do what you can to answer the question. This should be your only goal for the moment. Don’t get distracted by potential other avenues the bug could be hiding down. Even if you spotted something that looks worthwhile to follow. Just try to answer your question in the affirmative or otherwise. There’s no reason to skip over an obvious questions if it only takes a few moments to answer – you’ll just lower confidence in the rest of your debugging journey.

The reason to not get distracted is that you’ll forget how far you got with the first line of debugging. When the distraction turns out not to be correct, you’ll have no idea how to get back onto the track you were on ten minutes ago.

Write down the answer, and then tick the box. Writing down the answer is important for a number of reasons.

First off, if you’re debugging a particularly messy situation you’ll quickly forget the answer to the previous question, leaving you with fewer clues.

Second, and more importantly, is that writing is dog slow. You’ll be pausing, hands away from the computer, and giving yourself time to process what you just learned. Maybe you’ll realise that you’ve been thinking about it wrong, or that you’ve been debugging the wrong thing for the past half an hour. It’s very easy to get swept up in the flow of data when your head is keeping track or every bit of state.

This is also really important whilst pairing. Your partner may not be keeping up – or maybe you’ve decided something wrong. Having it written down is a lot clearer than “well the previous revision is overridden by the next revision because the author of the previous, uh, no, the next revision is the same as the first revision, see?” Write it down so that there’s always a checkpoint for your pair to catch up. If they’re a good pair they’ll ask you to explain anything that looks odd.

Ticking the box is important too! I’ve been lost on many two day long debugging sessions, which left me drained and stressed. Although slowly making progress, there’d be no specific point to celebrate. Instead, now that we have tiny units of work to complete, each tick is a mini-celebration.

Ask the next question.

Keep doing this until you realise, “dammit, it’s just a typo!”

At the end of this, not only will you have fixed your bug, but you’ll have learn a lot about your system, with some semi-decent notes.

Developing with Symfony 2 and Docker

I had a couple of aims for my most recent quick project, Dashli:

  • be able to avoid polluting my machine with PHP, MySQL, and those other services which quickly get littered around,
  • be able to really quickly deploy to a service, without having to ssh in and set everything up

Docker works well with both of these points.

There’s a simple Dockerfile which lets you write down the steps you’d take to build a box and set it up for your application. That means that during development, Docker knows how to build a virtual machine which’ll let me keep the entire server infrastructure hidden away from my “local” OS. No more worries about which PHP version I need for different applications and I don’t need to keep a MySQL server running for no good reason.

Together with tools like Docker Cloud (free with one private instance) and Digital Ocean (not free, but you can get $10 – enough for two months of a small server – when you sign up with this link), it’s super easy to have my project uploaded to a cloud instance and running without me even having to know how to SSH into the box.

I had this all set up and running brilliantly. The problem was when I came back to my machine to continue development.

Tiny change, rebuild. Tiny change, rebuild.

The most frustrating part of this new flow for me was finding a simple typo and then having to redo my docker build . step, which isn’t quick since it has to do a full composer install again.

The fix here was mounted volumes – let the virtual machine mount my project directory as nginx’s root directory. This is simple, actually. When running your docker, do this instead:

docker run --publish 80:80 --volume /local/project/path:/virtual/machine/path/to/project .

Now, when you update a file in your local project, it’ll be instantly reflected inside the docker. Refresh your browser and you’ll notice the updates.

composer files getting thrown away

You’re probably building your composer.phar install inside your Dockerfile. That will still happen. However, when Docker goes ahead and swaps out the VM’s /virtual/machine/path/to/project with your local one, it basically deletes all that is in there. That will include you vendor/ folder, which will now be empty.

That’s obvious why – you’ve never run composer locally, you don’t even have PHP installed locally so how could you! You need composer to be run within the Docker, and hopefully without having an affect on your local machine.

To do this, we can move our vendors outside of the project. I know, right. Weird. Composer has support for this though. In my composer.json you’ll seen this:

"config": {
"bin-dir": "bin",
"vendor-dir": "/tmp/dashli/vendor"

This tells composer to download the vendors in the /tmp/dashli/vendor directory (I chose /tmp/ as everyone can write to it – this might not be the smartest place to put it). I also had to edit my app/autoload.php so Symfony knows where the autoloader is.

$loader = require '/tmp/dashli/vendor/autoload.php';

Now your dependencies can be installed on the virtual machine, out of the way of your local machine.

Getting around root created files

The huge downside of this is that any file written by www-data user inside your container is actually going to be written locally by root. You’ll now find your local project’s var/cache/, var/session/, etc. full of files owned by root. You’ll have to sudo rm them to get rid of them, which is not something that is a part of a healthy development flow.

Symfony comes fully equipped to handle this problem though: in your app/AppKernel.php, you’ll have to change some of the overridden methods to point them to your /tmp/ directory, just like we did with composer dependencies above.

You can actually read more about this here on the Symfony docs.

Hopefully that leads you to an easy development experience with Symfony and Docker!

Past year or so in Notebooks

My first more-than-£1.50 notebook was quite recent. A few years ago I came across a baby blue Leuchtturm1917. You know the type. I felt almost guilty about spending almost £15 for a book of paper. I did ultimately buy it due to some of its fancier features: numbered pages and table of contents to fill out. Although I continued feeling guilty, I’m aware of the worth now.

The problem I have though was being unable to fold it over. A notepad with a wire binding was quite important for me, for practical reasons. How else are you able to comfortably use both sides of the book and have it lie flat?

Around this time I discovered Whitelines Link. Fancy paper which allows you to take a photo and archive the pages electronically with a mobile app. This is less and less useful now though as Evernote does a commendable with any piece of paper given. I am delighted by the grey paper and white lines of the pages though – less harsh on the eyes.

Until recently, the notebook you’d find in my bag would have been a wire-bound Oxford Black and Red or a more luxury nuco elite. Since they’re just A5 notebooks, they take up little space in my bag. The hard covers let them stand up for themselves in the midst of the warzone in my bag. The wire-bindings fold flat.

I can’t spot any Black & Red’s at the moment, but I do have a trusty, brown nu elite. The stock in it is a good paper, with a little too much gloss. This means that wet ink doesn’t bleed through, but is a lot more likely to bleed and a touch slower to dry. Looking through this book, I’ve got many ink smudges.

Christmas arrived this year, and with it my boyfriend brought me a Moleskine notebook. A4, soft shelled, section sewn, and rather somewhat thin paper. The opposite of what I usually carry.

To my surprise though, I’ve switched to this notebook almost exclusively. Writing in an A4 book seems a lot more pleasant. Less worry about when to break a line, and fewer interruptions to turn the page. Despite the larger size, my bag is more than capable. Even the soft cover helps out here – it molds into whatever curve I need it to.

The folding flat issue was a genuine one to start with, but I’ve fixed that with a change of habit. Why bother writing on both sides of the book? I’ve never found writing on the left side of the book particularly comfortable anyway. Thinking back, the only reason I do write on the back sides of each sheet is because it was drilled into me in a cost-saving high school.

The paper maybe thinner than I’m used to, but the quality certainly isn’t lacking. A blue fountain pen is visible on the opposite side, but it certainly doesn’t bleed.

This Moleskine is lovely.

Showering cold

Four days in, it’s quite easy to do something everyday of the year, but I’m hoping this is something I’ll stick to.

I’m very much enjoying cold showers in the morning for a number of reasons.

It takes a huge amount of bravery to stand next to the running shower and see the water, which you know, and in some cases can feel, is very cold. Once you jump in, there’s a moment of proudness which is quickly replaced by shock as the water hits you.

The experience after that is as if on a plane with a lot of turbulence or skimming down a zip wire. Your heart literally beats faster, adrenaline bursts through your torso and into your legs. Before long, you find yourself dancing not to stay warm but just out of excitement!

It also takes a bunch of high speed self-reinforcement. I’ve found myself giggling each time I’ve done it this year.

I definitely leave the shower a lot happier and more awake than when I go in.

Some other benefits:

  • Mirrors stay clear for post-shower shaving, as there’s no condensation
  • Save energy
  • Showers are twice as fast (no procrastinating under the warm waves)
  • No need to waste water waiting for it to warm up

Here’s a video I found to back this up.

Helping “Real People”

I have a note in my notebook, a quick quote: “talk about real issues, that affect real people.” That’s how you’re supposed to capture the hearts of the people you’re trying to persuade. Putting that idea in the scope of the Human Rights Act is tricky for me, because so many of the rulings that have come directly from the European Court of Human Rights don’t affect “real people”, the British-every-man.

Taking a look through RightsInfo’s stories and you’ll read stories about a prisoner who was falsely accused being denied representation, or victims of slavery being forced to manage cannabis crops, or children fighting to live in their home whilst their parents are threatened with deportation. Can you put yourself in any of those shoes? Can you foresee yourself being in one of those situations?

You just can’t. For one thing, many people who are being protected by the ECHR in high profile cases aren’t even British. And these situations must happen so rarely, in such bizarre circumstances. Don’t feel bad about being unable to emphasize with the people in those situations. I can’t either. Most people won’t be able to.

We’re fortunate enough to have the European Convention of Human Rights though. During a time of experience, just after the worst war the world will ever see, where many were in horrible situations, these freedoms were decided. We don’t need to decide those freedoms now, completely out of context of the suffering they’re designed to protect against. We saw the horrors and we vowed never to see them again within our borders. That’s why we have these set in stone ideals, which don’t need to be subject to amendments.

We must protect anyone who falls below this standard of care. Be happy that these cases are rare. They’d be much more common without access to the ECHR through the HRA.

The European Court of Human Rights, miles away, in Strasbourg