Category Archives: programming

Let’s help people go to PyCon Namibia

PyCon Namibia is coming up. I think it’s a great idea and I’m planning to go.

I’m currently somewhat budget constrained while I sort out the early days of my new business. But… I’m self-employed, right? If I want more money, I can just work more (Technically correct. The best kind of correct). So lets do that!

Of course, there are plenty of other people who want to go and are vastly more budget constrained than I am. There are travel grants, but there are a lot more people who need budget than there is budget. So if I’m helping myself go by working more, perhaps I can lend a hand with that too?

A plan emerges.

This is how it goes:

  1. I will be going to PyCon Namibia regardless. If this plan somehow fails spectacularly, I’ll just suck up the cost.
  2. I’ll be doing a Hypothesis and Python testing tutorial there, so if you want to attend that go buy a ticket.
  3. At any point between now and when I physically set foot on the plane to go to Namibia (currently pencilled in at 22nd of January), my Hypothesis training courses (details below) are available for the fairly heavily discounted price of £2000 (if that sounds like a lot to you, me too. It’s a sign that neither of us should be put in charge of a training budget, because for advanced software training courses this is dirt cheap).
  4. Of that £2000, I will be donating 50%, i.e. £1000, to the PyCon Namibia travel fund to help bring people there. I shall not further earmark it but leave it up to the judgement of the organisers as to who most needs it.


What does the training course entail?

My training courses are designed for groups of up to ten people. In theory an even number of people is better because I like to organise people to pair during it, but in practice that usually breaks down so any number up to ten people is fine.

The primary training course I am currently offering is a very hands on workshop. It’s structured around helping you test your code better using Hypothesis – there is some theory, but it is mostly going to be about your engineers working to improve the quality of your testing, with my being there to point them in the right direction, answer questions, and generally offer advice that will help them avoid false starts and dead ends.

I am in the process of developing a more theory heavy course, some material of which will be in my proposed session in Namibia, so if you are interested in something that involves a lot more theory and working through examples I provide, we can talk about that, but it’s not quite ready yet.

Where can you do the training course?

Anywhere that I can get to, really. For now, that definitely restricts it to the UK (and, really, England). If it’s in London or within about two hours drive of Cambridge, it’s probably fine. If it involves more travel than that scheduling starts to become more complicated. If you don’t fit this description, read on to the next section for the ability to schedule a course for after the conference at a still reduced rate.

When can you do the training course?

I have a moderate amount of availability between now and PyCon Namibia. Realistically I can almost certainly fit in 5 courses between now and then, and I can probably fit in up to 10 but it will start to be tight. These will be available on a more or less first come first served basis, so getting in touch soon is a good idea.

If we simply cannot find a mutually agreeable schedule between now and the conference, I’m happy to offer the following fall back plan:

For up to ten additional clients, if you become a sponsor and donate £1500 directly to PyCon Namibia’s travel funds between now and the start of the conference, I am prepared to offer you a one day training course for only £1000 to be claimed at any mutually convenient date in 2016.

Note: Unlike the main offer, this offer is also available to people outside of the UK, but I will also require travel expenses in this case. Also if you don’t get in touch with me before donating this may turn out to no longer be an option, so get in touch first (although feel free to donate even if this is no longer available!)

How can I take you up on this offer?

Drop me an email at [email protected] with the subject line “Hypothesis training” or similar.

Are you affiliated with PyCon Namibia in some way?

Not even slightly. Until yesterday morning I wasn’t even totally sure I was going. I have talked to them a bit about this plan though.

Are you going to change any details of this plan?

I may update some of the details of how funds will be directed if things go very well and e.g. we swamp the travel fund. All funds that I’ve currently said will be going to PyCon Namibia will go to them or a charity of their choice in some capacity though.

Why are you doing this?

Because it’s a good deed, because I can, and because I’m in the right place at the right time. I like the idea of PyCon Namibia a lot, and I suddenly saw the possibility of doing a thing that helps both of us, so I decided to do it.

Have you considered this other worthy cause?

My plan is that once my business is reasonably profitable I will be donating a significant amount of its revenue to charity (probably around 10%), but plans are still TBD. For now, this is what I’m doing.

I have another question

Please either email me privately or post any additional questions in the comments, and I’ll do my best to answer them and keep this post updated.

This entry was posted in programming, Python on by .

Anyone want a speaker?

I’m in the process of doing a lot of speaking and putting together a lot of talks. This means I’m always up for new places to speak at. So if you’re looking for tech speakers at your meetup group, conference or company, read on.

The following are talk subjects I currently have ready to go (or could have ready to go on short notice):

  1. Various things on property-based testing in general and Hypothesis in particular. I’ve got two talks prepared for this: “Finding more bugs with less work” and “The plural of anecdote is not test suite”
  2. Gory details of how Conjecture works and why this is cool
  3. “Writing libraries is terrible”. A short rant about all the social and technical problems one runs into when writing open source libraries plus some things I think might help.
  4. “Your CI is the wrong shape”. A piece about designing your CI to fit with your developer workflow instead of spending all your time waiting on CI. Somewhat based on my empirically derived testing principles post.

I’ve done a large number of variations on the first one at this point. They’ve all gone very well, but I’m keen to try some of the others.

Also, I have plenty of other things I can speak on (if you’re at this blog you’ve probably noticed I have a few opinions to share) and haven’t turned into a talk yet, so if none of those quite fit feel free to get in touch anyway and I might have something for you.

I do have some (fairly reasonable) requirements:

  1. If you’re a meetup group or conference, you must have a code of conduct (which I will look at before agreeing).
  2. If you’re a paid conference, I require a free ticket if I’m speaking (I’m self-employed and on a budget until I manage to get my income variance way down from where it currently is, so this is particularly important, but I also think it’s just appropriate to not make speakers pay for tickets).
  3. If you’re somewhere that is not easily accessible from Cambridge UK (London is fine) I’ll probably need travel and accommodation expenses (see above. A London train fare is fine, but anything more than that starts to hurt).
  4. Half hour or longer speaking slots. I can do and have done shorter talks, but it’s just not worth it unless it’s at an event I’m going to be at anyway.
  5. If you’re a company then I’m still happy to do a free talk, but I’m going to want to sell you training and/or consulting services, so I’ll happily trade a talk for a meeting with e.g. someone who has access to training budget.

All that sound good? Great! Do get in touch.

This entry was posted in programming, Python on by .

Free work is hard work

As has previously been established, I’m a big fan of paying people for labour and think you deserve to get what you pay for when it comes to software (yes, I do run a free operating system. And yes, I get what more or less precisely what I pay for).

But… honesty compels me to admit that paying for work is no panacea. If you compare open source software to similar commercial products, the commercial ones are usually really bad too.

They’re often bad in different ways, but they’re still bad. Clearly being paid for work is not sufficient to make good software.

I think I’ve figured out a piece of this puzzle recently: When working for free, the decision making process looks very different from paid work. The result is that you can be good at things that people aren’t good at when writing commercial software, but it’s also that you just do a lot more work that you would otherwise never have bothered with.

Consider the question: “Should I do this piece of work?”

Free answer: “Well… people seem to think it’s important, and it looks a bit shit that I haven’t done it. I guess I can find some free time to work on it.”

Paid answer: “Will I earn more money from the results of doing this work than the work costs me?”

The result is that in free work, a lot of things happen that if you put your hard nosed businessperson hat on and looked at objectively make absolutely no sense.

A concrete example: Hypothesis supports Windows. This isn’t very hard, but it does create an ongoing maintenance burden.

Personally, I care not one whit for Python on Windows. I am certain that near 100% of the usage of Hypothesis on Windows is by people who also don’t care about Windows but feel bad about not supporting it. I only implemented it because “real” libraries are cross platform and I felt bad about not running on Windows.

In a business setting, the sensible solution would be  to not do the work until someone asked for it. and then either quote them for the work or charge a high enough license fee that you can soak the cost of platform support.

So what to do about this?

Well, on the open source side I think it makes sense to start being a bit more “on demand” with this stuff. I probably shouldn’t have supported Windows until I knew someone cared, and then I should have invited the person who cared to contribute time or money to it. Note: I am probably not going to follow my own advice here because I am an annoying perfectionist who is hurting the grade curve.

On the business side, I would advise that you get better software if you do sometimes do a bunch of stuff that doesn’t make immediate business sense as it rounds everything off and provides an over-all higher user experience even if any individual decision doesn’t make much sense. But honestly almost everyone writing software who is likely to read this is off in startup and adtech la la land where none of your decisions make any financial sense anyway, so that’s not very useful advice either.

So perhaps this isn’t the most actionable observation in the world, but now that I’ve noticed it’s going on I’ll be keeping a watchful eye out to observe its mechanisms and consequences.

This entry was posted in life, programming, Python on by .

My favourite language feature

I’ve been writing mostly Python and C for a while. This means that the features I’m used to are mostly Python ones, because C doesn’t really have any features so it’s hard to get used to.

And this means that when I write other languages I’m surprised because there are things that are ubiquitous in Python that I’ve forgotten aren’t ubiquitous everywhere. Most of them aren’t that important, but there was one that popped out at me that on thinking about I decided that I really liked and thought it was a shame that not every language implemented it.

That feature is named arguments with defaults.

It’s definitely not a Python specific feature – there are a bunch of other languages that have it – but Python is the language where I’ve really gotten used to how useful they are, and it’s far from ubiquitous.

I don’t really like Python’s implementation of it that much to be honest, but most of the flaws in it are easy enough to work around (and PEP 3102 makes life much better, or would if I didn’t have to write Python 2 compatible code), and when you do it makes it much easier to create extremely useful and flexible APIs. See my usage in hypothesis.strategies for example. e.g. the lists has 6 (ok, 5 really. The first one is only defaulted for legacy reasons) default options, all of which are useful and all of which play well together. Trying to do something similar with overloading or with different function names would be a complete horror, and really the best way to do it without default arguments is some sort of builder object which emulates them.

In my ideal world, I think this is how named arguments with defaults would work:

  1. There is a hard separation between named and positional arguments. The names of your arguments are not significant unless you declare them as named arguments, and named arguments cannot be passed positionally. A function may take both positional and named arguments, there’s just a clear delineation between the two. This is basically essential if you want it to be possible to make forwards compatible APIs.
  2. Named arguments are not required to have defaults.
  3. Positional arguments cannot have defaults (I’m not heart set on this, but it seems like a feature that is very much of limited utility and it’s cleaner to not have it)
  4. Defaults arguments are evaluated as expressions in the defining scope (not the calling scope) each time they are used. None of this ‘You can’t use [] as a default argument because it’s only evaluated once and then you’re sharing a mutable object’ nonsense from Python.
  5. Default arguments may not depend on other named argument values. Sorry. I know this is useful, but it messes with evaluation order in the calling scope really hard and it just doesn’t make sense as a feature.
  6. Optional: Default arguments may depend on positional argument values. This seems like an acceptable compromise for the preceding.

That’s pretty much all I have to say on the subject of named arguments with defaults: They’re great, more APIs should make extensive use of them where possible, and more languages should implement them.

Runners up

There are a bunch of other features that I think are great. Some of them made it on to my wish list but a lot didn’t for the same reason they didn’t claim top place for this post: They’ve already won. Support isn’t always ubiquitous, but it’s close enough that languages that don’t support them are weird and backwards outliers. Examples include:

  1. Namespaces with renaming on import available (If you don’t have renaming on import then you don’t have namespaces, you have implementation hiding and are still shoving APIs into the global scope).
  2. Local named and anonymous function definitions (“lambdas” or “closures”, but also nested functions).
  3. Parametrized types and functions over them (for statically typed languages).

I’d probably take any of those over named functions with default, but fortunately i mostly don’t have to.

This entry was posted in programming, Python on by .

So who wants a Hypothesis port?

For those just joining us: Conjecture is a radical simplification of property based testing, as popularised by QuickCheck. It emerged as a simplification of my work on Hypothesis, which is probably the second most advanced property-based testing system (after Quviq‘s QuickCheck for Erlang, and Hypothesis has a number of innovations over their work as well), and certainly the most advanced open source one.

Conjecture has some moderate usability advantages over Hypothesis, but its real advantage is ease of implementation in a new language: Hypothesis is almost impossible to port due to its extreme implementation complexity, while Conjecture is both easier to port and also can easily be written as bindings to a C library.

I’ve been holding off on progressing Conjecture out of its current research prototype state while I try to figure out the whole making open source work profitable thing, which is why it hasn’t seen any progress in a few months.

Unfortunately it turns out I’m really bad at not being allowed to work on software projects I’m interested in. What ends up happening is that I just write them in my head instead.

…which means that I accidentally figured out all the remaining questions for how to make Conjecture work. Then I cracked and couldn’t resist putting code to computer. As a result, I’ve put together a new prototype in Python and it has better data quality and shrinking than Hypothesis does. I now essentially consider the design of Conjecture a solved problem, and the open questions of whether it works answered with a resounding yes.

Moreover, it didn’t take me very long to implement at all. It took me so little time to implement that I’m reconsidering whether it’s actually even worth writing Conjecture as a C library. It’s almost easier just to port it.

So, uh, would you like one? Because I can write you one. My current estimate is that I can probably do a pretty solid implementation in a new language in not more than a month of work.

To be concrete about what I am offering:

  1. In almost any language of your choice, I am prepared to write something that is reasonably close to the Hypothesis core API (say, something akin to given, note + most of hypothesis.strategies). It will probably have some additional functionality, but the Hypothesis API is well proven in terms of its usefulness which makes it a good starting point.
  2. I do not anticipate that this will take more than a month, and a pretty usable prototype should emerge after about a week.
  3. I would charge you a day rate for my work. In exchange you would get a license to use but not redistribute all future released versions of Conjecture for that language without complying with the terms of the GPL (which it is otherwise released under).

Exact details are somewhat negotiable, but if you’re potentially interested, drop me a line.


This entry was posted in programming on by .