Writing Go CLIs With Just Enough Architecture

As someone who has written quite a few command line applications in Go, I was interested the other day when I saw Diving into Go by building a CLI application by Eryb on social media. In the post, the author describes writing a simple application to fetch comics from the XKCD API and display the results. It looks like this:

$ go-grab-xkcd --help

Usage of go-grab-xkcd:
  -n int
        Comic number to fetch (default latest)
  -o string
        Print output in format: text/json (default "text")
  -s    Save image to current directory
  -t int
        Client timeout in seconds (default 30)

I came away a little disappointed though because I felt like the final result was both a little undercooked and a little overcooked: undercooked in that it didn’t handle errors robustly enough and overcooked in that it created some abstractions speculatively in a way that I felt were unlikely to pay off in the long run.

Naturally, one thing lead to another, and I forked and rewrote the demo app myself to demonstrate what I consider to be just enough architecture for a Go command line app.

Read more…

Reddit · Why does all() return True if the iterable is empty?

The other day on Reddit someone asked this:

Why does all() return True if the iterable is empty? Shouldn’t it return False just like if my_list: would evaluate to False if the list is empty? What’s the thinking behind it returning True?

They have since removed their question, but it sparked a long discussion thread, and my comment was heavily upvoted, so I thought I would record it here:

This is literally a 2,500 year old debate in philosophy. The ancients thought “all unicorns are blue” should be false because there are no unicorns, but modern logic says it is true because there are no unicorns that aren’t blue. Python is just siding with modern predicate logic, but your intuition is also quite common and was the orthodox position until the last few hundred years.

Read more…

How to Use Netlify to Deploy a Free Go Web Application

Netlify is an web host that specializes in hosting static files. That makes it ideal for hosting a developer blog, a brochure site, or even just a one-off joke. It even has built-in support for Hugo. But Netlify also has various solutions for dynamic hosting, and their “Functions” service turns out to be a very easy way to host a Go web application, often for free. In this post, I will walk through a demo repo I’ve made that shows how to do this.

Netlify’s documentation is pretty good, so I definitely recommend to consult them for more in-depth information, but here I would like to walk through a basic scenario for why you might want a Go backend service and how to set it up. You can see the final version of all of the code on Github and a live demo on Netlify.

Read more…

Matt Stoller · Will Spotify Ruin Podcasting?

Matt Stoller at Big has a newsletter post about Spotify’s attempt to take over podcasting that also includes a great history of the death of publishing on the web:

Why the Open Web and Publishing Began Dying

Anyone trying to understand modern media or monopoly has to spend a lot of time understanding Google and Facebook, because they are the pace-setters in our economy. Every corporate leader, from agricultural to podcasting, sees what they have done, and tries to reproduce their success in their own industry.

While Google and Facebook are framed as tech companies, they are in fact advertising companies and middlemen in the flow of information.

Google and Facebook did this through two key techniques. The first was to acquire gatekeeping power in distribution. Google is gatekeeper in search, online video, and maps, whereas Facebook is a gatekeeper in social networking. To get to users, you have to go through Google and Facebook.

The second was to use this gatekeeping power to vertically integrate into dominant advertising platforms. Google and Facebook both sell large amounts of advertising, and they both bought up adtech companies in a merger spree from 2004-2014. They force partners to hand over data - and data is a key input into advertising - as a condition of getting access to their networks.

The result of these public policy decisions was Google and Facebook, the death of the open web, and increasingly, independent publishing on the internet.

What do you call the parts of a story? Or: why can’t journalists spell “lead”?

I’ve been working as a journalism-adjacent programmer for some time. It’s an area I find very rewarding, but no job is without its downsides. Let’s face it: for people whose job involves writing professionally, journalists are bad at spelling.

“Hed”, “lede”, and other bits of jargon are just part of the problem. The deeper issue is that every publication has its own nomenclature, and jargon has drifted in meaning since the switch to web publication. “Slug”, for example, began as a literal slug of lead melted into a row of letters by a Linotype machine. Now, it generally refers to a “short label for something, containing only letters, numbers, underscores or hyphens”, and it might mean the keywords in a URL or an internal ID system used by a publication for editorial workflow. Those two meanings overlap but aren’t actually the same, which leads to confusion when developers talk to journalists and editors.

I have been working on the website for Spotlight PA, and I wanted to try to give the parts of an article more-or-less standard names in our CMS. There was only one problem: just what are the standard names? To find out, I made a survey and asked in chatrooms and on Twitter for other news nerds to fill it out.

Read more…

Maciej Cegłowski · Privacy Rights and Data Collection in a Digital Economy

For sixty years, we have called the threat of totalitarian surveillance ‘Orwellian’, but the word no longer fits the threat. The better word now may be ‘Californian’. A truly sophisticated system of social control, of the kind being pioneered in China, will not compel obedience, but nudge people towards it. Rather than censoring or punishing those who dissent, it will simply make sure their voices are not heard. It will reward complacent behavior, and sideline troublemakers. It’s even possible that, judiciously wielded, such a system of social control might enjoy wide public support in our own country.

But I hope you will agree with me that such a future would be profoundly un-American.

The Ethical-Trained Programmer Sells Out

As all tech industry observers are aware, the twin pillars of a successful startup are cost shifting (i.e. user generated labor) and regulatory arbitrage (i.e. tax avoidance).

For years, Facebook had its users write its content for it, and Amazon has avoided sales tax. Google’s famous “PageRank” algorithm gets every website in the world to do the hard work of ranking links for them, and Apple successfully avoided billions of dollars in taxation at the cost of a few awkward meetings. The greatest unicorns do both, like Uber and AirBnB, which avoid fare taxes and hotel taxes respectively, while pushing the costs and risks of car and property ownership onto their “partners.” YouTube and Instagram have even managed to work around child labor laws by the simple expedient of not paying their content producers. It’s win-win!

Looking at this competitive landscape, it is clear that if The Ethically-Trained Programmer is ever going to “exit”, I need to find a novel tax to scofflaw and a way to force my inventory costs onto my “partners”.

Read more…

John Millikin · No Haunted Forests

Fresh graduates often push for a rewrite at the first sign of complexity, because they’ve spent the last four years in an environment where codebase lifetimes are measured in weeks. After their first unsuccessful rewrite they will evolve into Junior Engineers, repeating the parable of Chesterton’s Fence and linking to that old Joel Spolsky thunkpiece about Netscape3.

Be careful not to confuse this reactive anti-rewrite sentiment with true objections to your particular rewrite. Remind them that Joel wrote that when source control meant CVS.

3. The real reason Netscape failed is they wrote a dreadful browser, then spent three years writing a second dreadful browser. The fourth rewrite (Firefox) briefly had a chance at being the most popular browser, until Google’s rewrite of Konqueror took the lead. The moral of this story: rewrites are a good idea if the new version will be better.

The Joel article bugs me for a number of reasons, and the fact that his core example is totally demonstrably historically wrong is one of them.

Rewriting software is something you should only do if you can answer the question, “Why will it be better this time?"

New programmers to a code base think the answer is “because the last people working on this were idiots.” Sometimes that’s true! If you’re inheriting, e.g., some PHP code written by people who weren’t really web developers but just learned by copy-pasting, you might be smarter-enough to have a rewrite work. However, that’s the exception, and typically, you’re not any smarter than the people who wrote the code in the first place, so you’re not going to do any better.

Another answer that’s possible but unlikely to be correct is “they made bad technology choices.” Yes, some technology choices really are so bad that correcting them can make a difference, but moving, e.g., from Rails+MySQL to Node+Mongo is unlikely to make things better.

A good answer is “the business requirements they built this product for no longer apply.” For example, Microsoft Office vs. Google Docs or iTunes vs. Spotify. The former product in both cases is more robust, more complete, technically capable of doing it all, but the latter product by virtue of not having to do things that are no longer necessary can be radically simplified.

Anyway, John Millikin is correct: no haunted forests!

More Than a Dozen Command Line Tools I've Written—and So Can You!

Way back in 2013, I wrote Google Go: The Good, the Bad, and the Meh, which means I now have more than the job-recruiting-required “at least five years of experience” using Go. But I don’t want to write about that. I want to write a little about a baker’s dozen of the many small tools I’ve written in Go to scratch personal itches since then.

Most of these programs were the result of some passing enthusiasm, now mostly forgotten. They tend to be work-adjacent but not actually part of my direct job responsibilities. (That is to say, I was never asked to write any of these by a boss, and probably my bosses would see them as a waste of time if they knew about them.) Some of them I use a lot, and others I wrote and then forgot about completely. Mostly though, they’re just fun to write and satisfying to look back on.

Read more…