They say you learn something new every day.

Archive for February, 2012

How to Write a Report (29/02/2012)

I did something in the description of this blog (and edited it into the very first post) that I’ve realised I need to reuse.

Elevator Conversation

They say you learn something new every day. This is my attempt to document that.

More Detail

If you do learn something new every day, how long do you remember it for? That’s a lot of things to store. This is my store of “learned things”. I like Steve Makofsky’s description of his blog as “backup of my brain”.

Even More Detail

My other thought was about Steve Yegge’s comment that “I sucked, and I still do, although hopefully less every year.” Steve’s talking about coding, but I think it works for every aspect of your life.

After all, replace the word “code” with your chosen profession in this quote from Jeff Atwood and you’ve got what this site is all about:

“You should be unhappy with code you wrote a year ago. If you aren’t, that means either A) you haven’t learned anything in a year, B) your code can’t be improved, or C) you never revisit old code.”

I was somewhat frivolous when I did it, but there’s something really useful about this style.

You capture everything in the first iteration, and people can stop reading there. Or, if they want more information, they can keep reading. It suits different audiences.

I think this is a good way of putting together reports and documents:

This report in one line.

Then:

This report in one page

Then:

This report in graphs and charts

Then:

This report in detail

Then:

This report in technical detail

Or something like that. It allows readers to get the gist of it all at once, and then jump to the level of detail they require. Obviously, you could do some even cleverer things if you delivered it in web format or something like that. Sadly, at the moment, people are still printing things off, but I think this can still work in the printed format.

I’m going to try it the next time I have to put something together.

There’s been a couple of times now when I’ve prepared a page report and people have wanted a 10 page one or a 10 page one and people have only really wanted a page one. This way, you can allow people to easily flow from one category to another.

Advertisements

Less Wordy (28/02/2012)

A very quick thing today, still about proof reading though. (Something I will move off soon).

I’ve noticed in first drafts I tend to write sentences like this:

It’s one of those things I’ve come to accept.

Yuck! Kind of passive and ugly. Obviously the thing to do is turn it around like this:

I’ve come to accept it

When you’re aware of it, it’s easier to start spotting and changing it.

Couting Words (27/02/2012)

So, as I said, proof reading is hard. Really, to misquote Douglas Adams, hard. You just won’t believe how vastly, hugely, mind-bogglingly hard it is. I mean, you may think doing maths is hard, but that’s nothing compared to proofreading.

One of the things I find difficult to spot is duplicate words. Being a techie sort, I decided to code myself out of it, so I wrote a little internet app: the repeated word finder.

Basically it searches for cases of the same word being used in close proximity and highlights them. Obviously, there are lots of legitimate uses for repeated words (like both the ones in the illustration), and I know that you can never code better writing, but it helps you see the errors. My hope is that by highlighting these things  it’ll help me spot them.

It’s interesting – there are some things humans are good at, and some things computers are good at. Humans are very good at reading what should be there, and improving phrasing etc. Computers are very good at reading what is actually there and highlighting things that humans would just gloss over.

Hopefully, this is just the beginning of a larger proof reading tool. It’s something of a sister to the uber-wordcount tool, which needs a bit of a rewrite really. My plan is to handle all of this sort of thing – stats, wordcounts, etc, in one javascript based application. There’s no need to do anything server side with this at all.

I’ve written the app in javascript, and I have to admit, my javascript is rusty. I was quite exicited to find a javascript minifier. This is the original:

function countit(){

var formcontent=document.wordcount.words.value
formcontent = formcontent.replace(/\n/g, “

”)
formcontent = formcontent.split(” “)
var recentbits = “”

for ( var i = 0; i < formcontent.length; i++ )
{
if ( recentbits.toLowerCase().indexOf(” ” + formcontent[i].toLowerCase()) > 0)
{
formcontent[i] = “” + formcontent[i] + “
}

recentbits = “”

for (var count=0; count < 20; count++)
{
recentbits = recentbits + ” ” + formcontent[i-count]
}

}

var totalwords = formcontent.length

document.getElementById(‘totalwords’).innerHTML = “Output: (” + totalwords + ” words)

” + formcontent.join(” “)

}

And this is after minifying:

function countit(){var a=document.wordcount.words.value;a=a.replace(/\n/g,”

”);a=a.split(” “);var b=”“;for(var c=0;c0){a[c]=””+a[c]+””}b=”“;for(var d=0;d<20;d++){b=b+” “+a[c-d]}}var e=a.length;document.getElementById(“totalwords”).innerHTML=”Output: (“+e+” words)

”+a.join(” “)}

Obviously, you can’t read it, but it’s so much more compact.

Going through it, I don’t think it does anything cleverer than renaming all the variables to consecutive letters and getting rid of all the space. But it’s pretty nifty for loading into the live system.

Proof Reading (26/02/2012)

I wrote something this week for a magazine.

It’s only a couple of thousand words. I’ve been meaning to write it for something like eight months now, and it was only because I didn’t have the internet that I got round to doing it.

I’m quite happy with it, partly because I did a lot of proofreading. I took out so many adverbs, adjectives and qualifiers. I know it’s a cliché, but it’s so true. I suspect in the first draft you put a lot in just qualifiers and adjectives in to give you more time to think. They’re sort of literary “ums”. Almost a type of phatic phrase.

Even then though, I missed a number of typos that L and M picked up when they read it.

Proof reading is really hard, because you read what you meant not what you’ve actually written. It’s a really tricky psychological problem. Obviously, misspellings are easy, because Word puts a helpful little red line underneath them. What’s tricky is when you write the wrong word by mistake – a typo that results in a different word. Word tries to put a green or blue underline for these, and Word 2010 is certainly a lot better than 2003, but it still gets a number of false positives, and also misses a lot.

I’ve been thinking about how to solve this problem – how to get better at spotting these. I think all you can do is:

  1. Get someone else to read it, or ideally, lots of other people.
  2. Be aware of what words you’re likely to mistype. It’s my experience that there are certain words I tend to mistype (probably because of some sort of finger memory, or repeated error) and be especially vigilant around those.

For example: I think I must have slightly dyslexia around “p” and “b”. I remember I’ve always got these slightly confused since I was small – but only in the middle of words. Maybe it’s their shape or their sound. In some ways, it doesn’t matter. I can train myself a bit harder to get them right, but also I need to make sure I read very carefully when I get to a word like “crumbled”, that I do mean “crumbled” and not “crumpled”. In Thinking Fast and Slow Language I need to engage my second level of thinking which is slower and more thorough – looking at what is actually there, rather than what I think is there.

The other things I tend to mistype are:

  • “Now” and “not”  – this one is quite bad, since it turns the sentence completely round, but it’s easy for both me and proofreaders to miss.
  • “to” and “and” – I know it’s slang, but I still sometimes write “sit down and listen” instead of “sit down to listen”. The former is valid, but I mean the latter. In some cases, the former isn’t valid.
  • Tenses. I don’t mean I don’t get tenses (I do. I did. I will – see, easy), what I mean is I write “she’d” instead of “she’s”. Very easy one that one.
  • Repeated words. This one is terrifying, and I think I might write a bit of software to help me with this one. My first sentence was:

I get up to get a cup of tea. When I get back David Jason is sitting in my seat.

Did you spot it? It might be easier since I’ve isolated it and sit it aside, but I read that so many times, L read it, M read it, and in fact, I never noticed it until R pointed it out:

I get up to get a cup of tea. When I get back David Jason is sitting in my seat.

Three “get”s in two sentences. The fix is easy enough:

I get up to buy a cup of tea. When I come back, David Jason is sitting in my seat.

It doesn’t even change the rhythm or the scansion of the line – but you have to notice it to make the change. And three well educated, English-graduates missed it! And it’s in the first sentence.

Proof reading, as I say, is tough.

Client side (25/02/2012)

I was reading an article in .Net Magazine the other day and someone had asked a developer:

“Is it better to run your code on the server side or the client side?”

 And the developer said something along the lines of:

“Client side. This will scale better since the users’ computers will do all the work”.

It’s kind of obvious really, but I realised I’ve been doing this wrong. Take my wordcount tool, for example (the design of which is beginning to look a bit crappy to me, which is good, because it means I’m getting better at designing things). It’s built in PHP, which means it uploads all the content to my server and runs the commands on my server.

If you think about it, this is kind of stupid for two reasons:

  1. I’m having to submit a load of data over the internet, which is slow.
  2. I’m having to run all the commands on my server. Which doesn’t scale and means my computer is doing the work.

This is a prime example of when doing it on the user’s computer would be better.

So I’ve started rebuilding it in javascript. It turns out I’m a bit rusty at javascript, and also PHP has some “lovely” built in functions (like a wordcount functions). I think I see what Jeff meant about PHP now. It’s such a weird language:

PHP isn’t so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory

Nevertheless, I still quite like it, but it makes it quite difficult to translate form PHP to javascript. I’m going to have to rewrite my wordcount code more or less from scratch.

This is no bad thing though – it’ll be some good javascript practice.

Internut (24/02/2012)

I’ve moved house.

My new flat is lovely, but I’ve spent the last four days without the internet at home. And you know what? I actually loved it! It’s really changed my life.

I remember now that I’ve felt this way a few times when I’ve been without the internet. I’ve suddenly had… time! There’s, like, five hours between getting home and going to bed.

I usually fill a good part of this with the internet. Without it, I have time to do stuff! Loads of stuff. I’ve taken up listening to Radio 3 (oooh, classy!) which is incredibly relaxing. And I’ve done some writing, and reading and just got on with things.

I don’t think I can give up the internet fully, but I think I may try to go one day without it.

But how have you been writing this without the internet, you may ask. I wrote a couple at home and posted them at work, and one on my iPhone. It’s really not that much of a problem.

Comparing (23/02/2012)

Someone reminded me the other day of the importance of having some way of identifying changes.

I guess this is part of my discovery of how important monitoring is, because then you really know what is going on.

I discovered today that you can compare differences between two Word documents in word. You click on Review then the drop down Compare button then add the two documents.

It’s a really useful feature.

Tag Cloud