Programming

Recommendation: use explicit type names

I attended an excellent talk recently at Lambdale about teaching children to code (not just Scratch but actual computer languages) and one of the points of feedback was that the children found the use of names in type declarations and their corresponding implementations in languages such as Haskell confusing because frequently names are reused despite the two things being completely different categories of things.

The suggestion was that instead of f[A] -> B it was simpler to say f[AType] -> BType.

Since I am in the process of introducing Python type checking at work this immediately sparked some interest in me and when I returned to work I ran a quick survey with the team that revealed that they too preferred the explicit type name with the suffix Type rather than package qualifier for types that I had been using.

Instead of kitchen_types.Kettle the preference was for KettleType.

The corresponding function type annotations would therefore read approximately:

def boil(water: WaterType, kettle: KettleType) -> WaterType

So that’s the format we’re going to be adopting.

Standard
Programming

HyLang: Sorted

Sorted in Hylang reports as being a built-in but isn’t documented in the HyLang built-in documentation. After a bit of head-scratching I realised that this is just the Python built-in sorted.

Hy uses keyword parameters to bind keyword arguments in Python interop so to define a new sorting function you assign a lambda to the key keyword.

So to sort pairs by the second value…

(sorted :key (fn [[a b]] b) items)

This is pretty similar to Clojure’s sort-by except that you can’t define the comparator explicitly.

Standard
Programming

After having checked our privilege, how shall we continue?

I’ve been privileged enough to go to a number of development conferences last year (2018). I know that I’m privileged because almost every conference had a talk or many talks making clear my privilege in attending them.

I have a job where attending conferences makes sense as part of my work and I make enough money to be able to buy my own tickets and pay for my travel and accommodation. I’m often able to combine attending a conference with catching up with friends and family. I have the ability to choose which conferences I attend based on whether they allow me to achieve other things I value in my life.

I’m lucky and well-placed in life, and if I was unaware of that then fortunately every conference will have a speaker willing to point that out to me. Sometimes for as long as an hour.

An hour that I’m not unaware that I have paid a lot of money for, an hour that I have chosen to spend listening to this talk instead of doing something that I might enjoy instead.

Often these conferences talks have no particular point they want to make beside how privileged people in tech are and how little we understand people outside our tech bubble. They have no clear or sensible strategy as to how to change what they regard as disagreeable.

Often they feel very unclear about what exactly is wrong with the privilege enjoyed by their audience. Perhaps eliminating it a worthy goal in itself.

Its certainly not clear what audience the speakers would be happy to address about the topics that might be related to the notional agenda of subject of the conference they are speaking at.

The vagaries of conference programming committee means that there will often be another talk taking about how difficult it is to be a programmer: how prone to stress and burnout we are and how we need to prioritise self-care.

We are self-absorbed and toxic, while also being fragile and in need of nurture. No talk has addressed this contradiction.

Topics such as privilege and the self-absorption of tech are potentially worthy subjects but at the end of a year, having heard variations of these talks many, many times I want to stop.

I’m happy to nurture my privilege checking and think about the technology needs of the emerging world while taking steps to create an inclusive workforce.

In return, what I would like from the conferences that I pay to attend is some attempt to deliver a programme that reflects the prospectus that is laid out when you buy a ticket to say a Javascript conference or a Python conference.

The minimum I would like to have is that in every timetable slot there is a strong technology talk that will be relevant to my work and interests, preferably something informative and provided by a technology practitioner.

If this can happen then I’ll feel as if attending the conference was a good thing in itself rather than the peg on which to hang the chance to visit places and people.

Standard
Programming

Tackley’s law of caching

Tackley’s law of caching is that the right cache time is the time it takes someone to come to your desk to complain about a problem.

If you obey this law then when you open your browser to check the issue the person is complaining about it will already have resolved itself.

Tackers may not have invented this rule but I heard it from him first and it one of the soundest pieces of advice in software development I’ve ever had.

Standard
Programming

Slow SPAs are worse than NoSPA

I got a digital subscription to the Economist for my birthday last month so I’ve started reading a lot more content on their site. As a result I’ve noticed a lot of weirdness with their page loads that was hardly noticeable when I was using the free tier of a few articles per week.

The site seems to be built as a SPA with a page shell that loads quite quickly but takes far longer to fill with content and which has some odd layout choices and occasional pops and content shifts.

The basic navigation between the current issue index and the articles is hampered by what appears to be a slow load or render phase. Essentially it is hard to know whether the click on a link or the back button has registered.

By replacing traditional page navigation the experience is actually worse. The site would be better if the effort going into the frontend went into faster page serving.

I’m not sure if the page is meant to be doing something clever with local storage for offline use but it seems to need to be connected when browsing so I’m assuming that this is something to do with the need for a subscription and payment gateway that prevents a fast server load of content.

It still feels as if the page and the 200 words or so should be public and CDN-cached with the remaining content of the article being loaded after page-load for subscribers.

The current solution feels like someone has put a lot of effort and thought into making someone that is actually worse than a conventional webpage and that seems a shame for a site with relatively little content that is mostly updated once a week.

Standard
Programming

PyPika

PyPika is a DSL for creating SQL queries. It works by generating SQL from definitions that you create inline rather than by interpreting models or data classes or structures.

It makes it easy to define minimum projections and is also straight-forward to bind data to as you simply provide the values into the query that is generated rather than binding values to a query definition.

Once you have the query object constructed you call str on the object to obtain the actual SQL which you then need to pass to some execution context.

This also means that it is easy to test what SQL you are generating (although really using a DSL like this means you should really be trusting the library).

I have only had one real problem with the statements I have used to date and that is around the Postgres `RETURNING` statement that allows a generated key to be returned to the caller of an INSERT.

Apart from this using Pypika has been better than using a Python template or writing raw SQL.

Standard
Programming

Sustainable web development

This article about delivering a sustainable small website is one of the most inspiring things I’ve read in weeks. It made me think about the true costs of the web revolution and made me think again about the environmental claims we make about moving paper processes online. Green energy and clean websites are entirely possible but will people pay the premium for it?

Finally like all truly great pieces it offered some practical insight into problems I have been grappling with in my work. The observation that small, fast loading server-rendered pages are the same as client-side SPAs but more energy efficient is a great insight.

However the best was the idea of simplifying the navigation into its own page. This one thing is a piece of genius that hundreds of man-years of UX research have failed to discover.

Thinking about the energy cost of our websites is also a great proxy for thinking about the cost basis for our infrastructure and where we want to put our processing effort.

Standard