NaBloPoMo #16

I’m going to do a quick review of a piece of code with 12 commits. It implements a fairly basic example of the Game of Life. Reading the rules of that game will be helpful if you haven’t read them yet.

In this blog, I’m going to try to guess what each commit does. Tomorrow we’ll compare and learn a valuable lesson about writing good commit messages.

Continue reading

NaBloPoMo #15

Day + 1 of a diagnosis of Asperger’s Syndrome, which also happens to be Day 0 of my new role.

Oh, also: weeknotes! Let us slip into the familiar format, the way you do with your skin when you wake unencumbered on a Saturday morning.

Five things that happened this week

1I got a diagnosis of Asperger’s Syndrome and wrote about my immediate reaction. I didn’t write about the outpouring of love and support I’ve received from everyone I’ve told, but it was there, and I’m grateful to all of you. I got the diagnosis on Thursday morning and it – well, it didn’t feel strange at all. It didn’t feel different, and I didn’t feel worried. This is apparently symptomatic, and I need to reflect on how much of my personality to this point has been performative. How much of it is the friendly flesh-wrapper around something that’s human-esque but not quite there. At the same time, mind you, this may be a drastic over-reaction. The pendulum of human emotion makes big swings, and while it’s right to re-examine one’s life in the light of the knowledge that one has always been a little different, it is also true to say that not everything was false. We cannot avoid the re-examination, but I’m leaving this here as a reminder to be generous with myself. Like everyone else I’ve constructed a shell from cast-off words and my parents’ cloth and the things I thought I should say. I am going through the process of peeling those sections back to see what they covered up, and whether I should prefer to expose that part of myself, and in so doing carry less weight. At least thanks to my diagnosis I, unlike many, know what to expect in certain places.

2I abandoned my team. I left without saying goodbye. It felt strange to say goodbye, since I was moving no more than twenty metres, and yet I feel sure that I should have done so. Goodbyes are hard. Well. Early goodbyes are hard. Final goodbyes are easy. A bridge you leave standing is a temptation to return to the past; an ambiguity to be despised. A bridge that you’ve set alight will illuminate your way forward.

3I got really quite stuck on a technical challenge that I haven’t managed to figure out yet. I’ve also noticed already how much I miss coding, so if you’re reading this and wondering if some kind of technical solution might be a way of meeting a need then let me know. A good way of working out if you have unmet user needs is looking at your spreadsheets. If you need loads to manage all your data, then you might need me to code something for you. Please get in contact. I need to write something for a computer.

4I received mail! A letter from a friend who’d sat down and thought about me and written loads of words. It is the nicest thing in the world. I know us weeknoters say this a lot, but letter are absolutely lovely. Actually, now I reflect on it, is there a correlation there? That we’re naturally people who like writing and also like receiving considered pieces of writing from other people? Or is it that the desire for letters is universal, and it only appears that weeknoters are more eager for letters because we express that desire in public? Answers, please, in the format of epistles. And to my dear friend, I am writing your response, and I am grateful beyond words for your thoughtfulness.

5I started with a new therapist. Together we are going to explore the peculiar pathways of my brain. I am seeing this therapist on the advice of a dear friend whose opinion I trust without question. I wish I could have come to the conclusion by myself, but then it’s quite nice to let friends help you every once in a while. Besides, my brain is the thing that means I earn enough money to allow me to – let me check my email – yes, continue to not move into my new flat. I am a recent convert, and like all recent converts something of a zealot. Do, if you can, hire the services of a therapist. It is astonishingly powerful, if you can find one you can get along with. Mine has a dog companion called Eddie who is remarkably skilled in knowing the precise point at which the comforting weight of a canine skull is exactly the thing a fellow needs. Dogs are almost as good as therapists. The both together are a surely a winner.

Other writing this week:

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.

NaBloPoMo #13

A first draft recursive function to solve a problem I found on codewars. I am happy with the recursion, but I’m finding that it struggles when the initial row is up to 100,000 characters long. I think that means there’s a secret to working this out – or, at least, a more efficient way than just brute-forcing it. Comments welcome!

Problem Description

A coloured triangle is created from a row of colours, each of which is red, green or blue. Successive rows, each containing one fewer colour than the last, are generated by considering the two touching colours in the previous row. If these colours are identical, the same colour is used in the new row. If they are different, the missing colour is used in the new row. This is continued until the final row, with only a single colour, is generated.

My code

class Triangle:
    def __init__(self):
        self.colours = {'R', 'G', 'B'}

    def triangle(self, row):
        if len(row) == 1:
            return row[0]
            new_row = []
            for i in range(len(row) - 1):
                parent_colours = set(row[i:i + 2])
            return self.triangle(new_row)

    def child_colour(self, parent_colours: set) -> str:
        if len(parent_colours) == 1:
            return parent_colours.pop()
            return self.colours.difference(parent_colours).pop()

So: this class has two methods, triangle and child_colour. triangle calls itself until it reaches its exit condition. The exit condition comes when we’ve only got one letter in row – that is to say, we’re down to the bottom level of the triangle.

If we’re not at that point yet, the method works out what the next row would be and passes it to a new instance of the same method.

Before very long, it’s triangles all the way down – until at last one reaches the exit condition. At this point I imagine all the methods snapping back together in exactly the way Terry Pratchett described the Cabinet of Curiosity. A cabinet where the first shelf contains another shelf that shoots off at a right angle, and that shelf branches another, and another, and another – until the answer is found. Then the first shelf draws back, and then the second, and then the third which somehow passes through the sixth and ninth because human brains can’t even see the eighth colour of the rainbow.

And then, at last, in the only drawer in the cabinet, is the answer you were looking for.

Look, he does it much better than I do. This is really just a recommendation to read Making Money. Ignore the code entirely.

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.

NaBloPoMo #12

I was hoping to build a library. I’m going to write about how far I got, where the barrier is, and what I plan to do next. This follows from the introduction to Munkres I wrote earlier this month.

The algorithm requires manipulation of the elements in a grid as well as it’s rows and columns. I’m going to start this series by explaining how I tried to make the rows and column manipulable1completely guessed at that, genuinely amazed it’s a real word by extending the pandas class Series.

This is probably going to be moderately technical. I’m going to be walking through the code so there’s no need to go and look for it, but if you’d like to you can find it on Github.

import pandas as pd

class PandasMunkresAccessor:
    def __init__(self, pandas_obj):
        self._obj = pandas_obj
        self.covered = False

    def cover(self):
        Marks all elements in this series as 'covered' and also itself
        self.covered = True

    def uncover(self):
        Marks all elements in this series as uncovered and also itself
        self.covered = False

This is the first class I’m using. It uses a decorator, which is a sort of magic thing we have in Python. I’m going to avoid explaining decorators for the moment2because I don’t fully understand them myself yet and just say that this is a way of extending an existing class in Pandas – the Series class. It adds two methods and an attribute that I can access through Series.munkres – you can see where the “munkres” part comes from in the second line of code.

The way I’ve modified it is by adding an attribute, covered. There are also quasi “setter” and “getter” methods – one that covers all the objects in the Series and itself, and one that does the reverse.

I’ve added this because part of the algorithm involves covering rows and columns in a grid, and I thought this would be the simplest way to implement that in code. I am not yet sure whether I’m right, so I’m writing tests to check my understanding of how a Series is actually initialised.

(This is by far the best thing about writing code: if you don’t know how a thing works, you can construct a test to check. Most things in life aren’t like that.)

You’ll notice that when the extended Series.cover method is called, it calls another method – .apply. This is a method in the base Series class, and it allows you to apply a function to every element in the series. In this case, I’m applying a method from the MunkresElement class, which is just as well because all the items in the Series are MunkresElements. We know this because when we initialised the object in which we find the Series, we fill it with MunkresElements.

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.

NaBloPoMo #11

We are more than a third of the way through the month and I’m starting to hit the first barrier. This is a very tiring exercise.

Here’s one I’ve been ruminating on since last weekend.

Excel workbooks are where you should look for your next internal product.

The most effective strategy you can have for building internal, and possibly external tools, is running a workshop for your colleagues to improve their Excel skills. Ask them to bring their problems. Welcome them.

You will find that one team is running a thousand-person development programme with spreadsheets that reference each other in ways that will make your head spin. You will discover convergent evolution in the form of ten different, but functional, versioning systems. You will find out that there is a hole in a firewall because someone once wrote some VBA that needed database access, and you will need a quiet moment by yourself as you question your life choices.

But if you reframe these as opportunities – as low-hanging fruit where business processes can be smarted up, made more streamlined, and more repeatable – then you will have a user-centered roadmap of the internal tools you should be building.

I believe wholeheartedly that spreadsheets, where there is autonomy and power to change fields and do powerful calculations on the fly, are the bleeding edge evidence of what your organisation needs. A tiny example – if your organisation is using 14 spreadsheets to keep track of its room bookings, then you have identified a user need that could be met by the market but instead is being met internally with a custom product.

If you poke that long enough, by the way, the question becomes “Why do people feel they need to meet this user need through a massive, custom-built spreadsheet, the upkeep of which has become 25% of someone’s job, when there’s a bunch of products out there that can meet this need?” and that’s a different but equally important question.

Now, since spreadsheets are highly decentralised in terms of power – the person using them can add columns and remove them – they are quite different from your next step, which is an MVP database-backed service. So the second thing I’d counsel here is that your MVP absolutely must have a way of giving back a slice of the data in a CSV, so that it can be put back in Excel. If you insist instead that the new product will do everything, you’ll get low uptake (because it won’t if it’s an MVP) or you’re angling for a three-year million pound contract and that’s not an MVP, that’s your retirement fund. Stop it.

Your new product will need to almost be a micro service, a little slice where data goes in – possibly even in CSV format – and comes out again, and somewhere else some processing happens. Maybe emails get sent. Maybe some complicated calculation happens.

Or maybe a form that used to be emailed out to everyone in Excel that could instead be offered as a web interface. Basically, carve out a tiny slice of the user’s journey and replace it with something they’ll prefer to use.

In mapping parlance, you’re taking an element of a value chain and moving it to a product space. The more you do this, the more value you’ll be able to move up the value chain – value here being your colleagues’ time.

Of course with the extra time they’ll make more spreadsheets, but then that’s sort of the point of the bleeding edge. It’s always moving.

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you ran very fast for a long time, as we’ve been doing.”

“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”

Lewis Carroll, Through the Looking-Glass

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.

NaBloPoMo #10

I’ve had a purple beard for less than a week, and in that time at least once a day somebody has complimented me on it.

And that’s nice. Don’t get me wrong, it feels absolutely bloody lovely to have people compliment you on how cool you look. All the same, I’m struck by the sudden change in character of otherwise dour Londoners. Why has my purple beard got tongues wagging?

So this lead to a sudden startling conclusion: that I am experiencing a tiny peek into the life of anyone who deviates from the white heterosexual male appearance. Further than that, I think what I’m experiencing is that deviation from that perceived “norm” is considered public performance. And public performance means that critique is permissible or even welcomed.

The phrase I’m thinking of is:

Well, if you didn’t want people to notice, you wouldn’t do it, would you?

a dickhead, probably

And to be fair I do, kind of, want people to notice. Suddenly attractive people are chasing me down the street and asking if I have plans for dinner. Babies laugh uproariously. Beauties on Vespas stop traffic to stare.

But: that’s a choice I’ve made. The assumption that everything that deviates from the “norm” is for public consumption – be it the hair of people of colour; the clothing choices of women; or the appearance of people who don’t feel comfortable at the extremes of the gender spectrum – is, for me, at the root of street harassment.

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.

NaBloPoMo #9

My mentee asked me recently what an API is, and my fellow traveller-in-NaBloPoMo Alex asked me to try to cover a crunchy technical thing.

Let us see if we can solve both of these.

This blog is put out as the limit of my current knowledge. If I’m wrong, or you think I’ve skimped on detail, I’d be really grateful if you could let me know so I can make it better. I won’t be covering versioning APIs, although it is important and I recommend reading up on it.

Okie dokes.

An API is a description of how a thing can be interacted with programmatically. That is, by a computer-y shaped thing, rather than a person-y shaped thing. If a person-y shaped thing is interacting with your thing you will need a User Interface, or UI.

This is true at every level of abstraction.

This is also made slightly annoying by the way Python disregards concepts like encapsulation and instead lays itself open for anyone to abuse its internals, like a dog that rolls onto its back and exposes its soft belly because it trusts you implicitly.

There are, however, some nice conventions that discourage those who are not aggressively invested in fiddling with the insides. But I’m getting ahead of myself. Let’s talk about the API for a class, Dog.

class Dog:
    def __init__(self, age, colour):
        self.colour = colour
        self._age = age
        self.__goodest_boi = True

    def age():
        self._age += 1

    def bad_boy():
        print("Impossible, is always goodest boi")

Alright. Here’s our Dog class. There are three attributes: colour, _age, and __goodest_boi. There are also methods to change these attributes. Well, to try and change these attributes.

The API of this object is the methods and attributes other computer-y type things can use to try to manipulate the object. In this case, they can reach in and alter colour by just setting it, eg

>>>rufus = Dog(age=1, colour='a sort of white with black smudges')
>>>rufus.colour = 'a muddy brown with eyes like amber'
# rufus has been playing in the river again!
'a muddy brown with eyes like amber'

so colour is part of the API of this object.

We can also set Rufus’ age directly, because a single underscore prefixed to an attribute is more of a guideline than a rule:

>>>rufus = Dog(age=1, colour='a sort of white with black smudges')
>>>rufus._age = 14
# it's weird how time flies; you blink and the puppy is now 
# a hoary old fellow with a frosted chin 
# who still raises his head when you call

The single underscore suggests to other developers that they ought not to try messing around with this attribute, so I would say it’s not part of the API.

We’ve also got a method to make our Dog older, called age, which is called as normal:

>>>rufus = Dog(age=1, colour='a sort of white with black smudges')
# happy birthday Rufus! 🎉

So our age method is definitely in the API, because we can use it to manipulate the object.

We’ve also got a method bad_boy, for when our Dog has been naughty. Since it’s a public method it forms part of the API. Let’s see what happens when we call it:

>>>rufus = Dog(age=1, colour='a sort of white with black smudges')
'Impossible, is always goodest boi'

Oh no! We can’t punish our Dog! But wait. We could directly manipulate the attributes above. Let’s try to change __goodest_boi to False:

>>>rufus = Dog(age=1, colour='a sort of white with black smudges')
>>>rufus.__goodest_boi = False
AttributeError: 'Dog' object has no attribute '__goodest_boi'
# gasp! but we definitely put that attribute in when we made Dog!
# it is essential to Dog, and should not be accessed by anyone
# without it, what is Dog but Wolf?

It turns out we can’t easily mess around with a double underscored attribute. Instead, we get an error and our Python interpreter pretends it’s never heard of such a thing.

It can be hacked around, but I’m not going to show you how. You’ll only try to make my Dog into a Bad Dog and that’s not a good use of technology.

The point of this slightly meandering stroll through a fictional Dog class is to show that the API of a Python class comprises its publicly accessible methods and attributes.

Alright, says my mentee, but that’s not what people mean when they say ‘API’ is it?

Bugger. No, it’s not. It’s a terminological inexactitude. When people say ‘API’ they mean ‘web-based API’. But it’s the same concept: it’s the collection of public methods, this time exposed over the internet, that computer-y things can use to interact with your thing (except this time ‘your thing’ is probably your software as a whole, rather than individual classes).

For example, suppose you had to register your Dog with an organisation for some reason. You might want to do that programmatically or, rather, your vet would probably want any Dogs that passed through the surgery to be automatically registered. So there might be a web-based API for registering a Dog that the vet’s surgery’s appointment booking software would link to.

In Flask, which is a Python web framework, it might look like this:

from flask import Flask
from app.models import Dog 
# our Dog is inside a file called
from app import db 
# oh yeah, we've got a database

app = Flask(__name__)

@app.route('/api/register', methods=['POST'])
def register():
    if not request.json or not 'age' in request.json:
        # it's okay if there's no colour, but we can't 
        # register ageless dogs. 
        # So if there's no age we abort the request
    dog = Dog(
            age = request.json.get('age'),
            colour = request.json.get('colour', '')
            # defaults to empty string if no colour
    return 201

if __name__ == '__main__':

So as you can see, the only API the software is exposing is a method to register a new Dog. There’s no access to the Dog API.

Alright. That’s a big, boring block of text about APIs. What did I get wrong? What else could I talk about? You should let me know.

November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 – some short and sweet, others long and boring.