Aquileo | Herman Schaaf

Aquileo | Sky Lobby

2026-06-04T00:00:00+00:00

Sky Lobby is a game where you design elevator routes through a busy skyscraper. Place stops, build sky lobbies, and keep people moving as each tower becomes more crowded, more complex, and less forgiving. If you like games like Mini Metro or Mini Motorways, you should like this as well.

I'm proud of releasing my first game and think it turned out quite well. If you want to show support and try it out, that would be amazing!

Elevator dings

Links

Sky Lobby trailer

Aquileo | What we lost when we stopped programming

2026-05-24T00:00:00+00:00

Today I want to share something quite personal, and more emotional than I would typically post on this blog. I have been living in a mild state of malaise, and for me, it took deep self-reflection to realize what the root cause was. Some time in the last year, slowly but surely, the world lost something important to me: the art of programming.

I started programming when I was about 11 years old. It captured me pretty much instantly. It was just so much fun to be able to make games, interactive desktop wallpapers, and websites. I loved being able to make interactive experiences that I could share with others. I devoured every book about programming I could find, to the point where my parents got mildly concerned. And eventually I fell in love with the more theoretical side of programming as well: algorithms, data structures, and how to design and structure code so it's as clean and maintainable as possible. This led to competitive programming competitions, where I loved the thrill of participating in both local and global contests and putting my skills to the test against others. All the rounds of Google Code Jam, Hash Code, and other contests were yearly events I marked on my calendar in eager anticipation. And of course, programming became my career. An activity I greatly enjoyed and was lucky enough to be paid well for being good at it.

And then came AI. Powerful models are now capable of writing code faster than any human ever could. They know every algorithm that's ever been invented. They solve most problems you throw at them. Those programming contests I used to mark on my calendar? Most of them don't exist anymore. A key reason is that if you were to now copy-paste the question into ChatGPT, you're very likely to get a working answer within seconds. Previously, even the fastest humans couldn't produce it in under 5 minutes, and the more difficult challenges took hours. And our dayjobs have transformed for the same reason: nobody can write code as fast as Claude or Codex can.

On the one hand, AI is allowing us to create new software at previously unimaginable speeds. Shouldn't I be deriving my joy from that? I fell in love with programming because it allowed me to make things I could show others. I can still do that, and now even faster, right? In a sense, yes. And that aspect really is great. I love it.

On the other hand, it cuts deeper. A whole class of things I used to spend most of my life on now feel pointless. Why bother learning Rust / Zig / Haskell if I won't be the one writing it? Why bother knowing anything at all? After all, I know I'll just keep prompting until the AI figures it out, even if sometimes it will have to Google something along the way. In the end something I used to pride myself in knowing and being good at (writing quick code that solves a problem or produces something amazing) is now something a robot can do much better and faster in 99% of cases.

I still think I can do that 1% better, for now at least, such as architecting the system and designing the code to be as minimal and maintainable as possible. I can also understand and clean up what the robot builds, whereas a non-programmer couldn't. Arguably I am also more likely to think of the greater system and all its potential failure modes, and make sure the AI is thinking about it and testing this too. But the value of this is difficult to demonstrate to non-programmers. Heck, it can even be difficult to demonstrate to programmers. It takes a lot of time working with a codebase before you understand whether it is well-architected or not. As long as the code isn't a complete mess, you first need to understand the domain well enough to see whether any complexity in the code is warranted, or whether it is inherent to the domain. It can take days or weeks to do this, in a brave new world where we are getting used to working in timescales of minutes and hours.

For a long time, I attributed my mild malaise to the general uncertainty these technological advancements bring for the future, in tandem with large political changes we are currently seeing across the world. While that definitely factors in as well, for me personally, that is only half of it. I have lost the joy in practicing the art of programming. Coding a large system over hours, days or weeks, taking a step back, and being genuinely proud of my work, is a feeling I may rarely get to enjoy again. Not when you can, at least from the outsider's point of view, achieve the same result within hours with AI. We all know the end result is not really identical, but as it turns out, the economic incentives just aren't aligned to doing it the slow, thoughtful, artisanal way. Like a carpenter being replaced by machines and assembly lines, if I want to create some artisinal hand-crafted code now, it would either have to be on my own time, or I need to be able to set myself apart through what I produce in a way that no AI could. And even then, to stretch the carpenter analogy a bit more, I would be wasting time if I didn't at least use some power tools.

This is quite a big change, and one that, it turns out, I'm still getting to grips with. Am I in the fourth stage of grief, and the next stage will be acceptance? Perhaps. Time will tell.

A scene from The Six Million Dollar Mon

In an episode of Futurama called "The Six Million Dollar Mon", Hermes Conrad gets replaced by a robot called Mark 7G. In a futile attempt to stay relevant, Hermes starts replacing more and more of his body with robotic components. Until finally the only part he hasn't replaced is his brain. He then decides to replace the last bit of humanity left in him, and get a robot brain as well. It remains to be seen whether we as programmers will be fully replaced by robots, like Hermes with Mark 7G, or merely use AI as power tool-like augmentation of our existing skills to stay competitive.

Personally, I'm more in the power tools camp. These new tools are exciting, giving us superpowers to build even greater things, and as participants in the process we can still be proud of the result. I'm sure, in time, we'll learn to wield them with great skill. However, it was important for me to reflect on what we have lost along the way. For some, like me, well-designed code can be a beautiful thing. Artisanal, hand-crafted software will still have its place, but choosing that path will be an artist's life from now on.

Aquileo | My Mental Model for “Is It Worth Automating?” Has Changed

2026-05-17T00:00:00+00:00

So, to set the backdrop: It's May 2026, and we're all talking about AI, all the time. Well, some of us, anyway. And there was an inflection point in the abilities of coding agents around January 2026, to the point where they are now good enough to be trusted with writing a lot of code. This could be good or bad, depending on your view, and maybe you shouldn't trust AI with your entire codebase yet.

Something I haven't seen discussed much is just how useful AI can be outside of your main codebase: we can let AI write code to automate things that previously would have had a terrible work-to-time ratios. Obligatory XKCD:

The above XKCD comic was from January 2014. Now, in 2026, the "reality" graph may very well look like the "theory" graph from before.

To illustrate, I'd like to highlight some examples from a game project I've been working on. There were many instances where I asked AI to create automation for problems where I previously would not even have considered automation at all.

Automation gone wild

During development of a solo dev game, Sky Lobby, I tasked AI with automating the following, among other things:

1. Bots to playtest the game, simulating different player styles and skill levels

Sky Lobby is a puzzle game that involves both strategy and reflexes. Before real playtesting started, I wanted to get a quick feel for how difficult every level was, without spending hours playing the full game myself (however fun that may have been... time is a solo developer's most precious resource!). So I asked AI to write a bot that played the game.

It was to implement and compare four strategies: passive, random, a sweep that brute-forces a floor-by-floor tour, and a heuristic that actually plays well. Each strategy ran repeatedly across multiple reflex tiers, generating win rates and engagement flags per level. As the bots play at a sped-up rate, it takes about three minutes to finish the simulations, and then I get a markdown report showing which levels are too easy (the simple strategies win), too hard (no strategies win), or too boring (long periods of not needing to do anything). This was useful for getting an initial baseline for all the levels, and it allowed me to fine-tune them before playing through them myself and later sending them to human players.

Cost to automate with AI: 15 minutes

Time saved: Days, either of manual testing, or developing similar bots

Previously I may also have written such bot playtesters, but it would have taken a few days, at which point it probably would have been faster and better to play the game through a couple of times.

In addition to the markdown file, I wanted to see how the bots played, to make sure they weren't getting stuck or doing something silly. So AI wrote a shell script that drives Godot headless with --write-movie, records each level, and concatenates them into one playthrough video. In addition to giving me further ideas for refining the game and bot behavior, this was great for getting a feel for what it is like to play the game from start to finish, condensed into a few minutes.

Cost to automate with AI: 5 minutes

Time saved: Hours, maybe days

Would I have done this at all, before? Probably not.

2. A script for syncing Game Center entries

Game Center provisioning means 11 leaderboards, 2 global achievements, and per-level 3-star achievements, each in 10 localizations with its own icon. The official tool is App Store Connect's web UI. I spent 10 minutes manually entering data until I thought, "I'm spending a lot of time on this task...". I asked AI to write code that hits the App Store Connect REST API directly, reads every localization from a CSV, and provisions it all idempotently. This is one of those things that I, as a solo dev working on a small project and only expecting to do this task once or twice, probably would not have automated before, but since it's so easy to automate now, it suddenly made sense and ended up saving me a lot of time.

Cost to automate with AI: 10 minutes

Time saved: 2-3 hours of manual entry, or 2-3 hours of writing a similar script by hand

3. Screenshots of the game for every iOS simulator

Early beta testers reported empty areas on the top and bottom of the screen that I had trouble reproducing on my own iPhone. I asked AI to write a script that takes screenshots of the game being played on every possible device. It came up with a bash script that picks from available simulators, installs the build, launches it with a --shoot-gameplay flag I added, waits six seconds, and grabs a screenshot per device via simctl. The whole sweep takes a couple of minutes.

The same Sky Lobby level captured across a dozen iOS simulators in a single run: from the tiny iPhone SE up to the iPad Pro 13" M5. A few layout bugs stood out immediately.

Cost to automate with AI: 10 minutes

Time saved: At least a few hours of me figuring out how to write such a script myself, or hours of me testing manually.

The quality of the game benefited from this AI-built automation, without AI changing any of the game code directly.

Instead of editing a trailer in a video editor, the game promo is a GDScript file that drives a live tower simulation through a 17-second storyboard. Doors open, humans walk on, the tower builds, the camera follows, a title card lands. I had a vision of what I wanted the trailer to be like, I collected the assets I wanted to use for it, and I let AI program the specifics. It's not going to win any Oscars, but it worked, and allowed me to spend more time focusing on the game itself.

The resulting trailer, rendered straight out of Godot from a GDScript storyboard.

That said, this one did take a lot of iterations to get right. I went back to ask the AI to tweak it somewhere between 50 and 100 times before I was (more or less) satisfied with the result. Early on I tried editing the code myself, but it quickly became clear that this was not going to happen: the code was one 1,700-line ball of mud, relying on hundreds of inscrutable functions and constants.

Cost to automate with AI: A few hours, spread over a few days

Time saved: Hard to say. Maybe a few hours?

As an aside: one nice consequence of using Godot for this was that when I changed the cabs or added details to the buildings, the trailer automatically picked them up in the next render. It's always showing the current build. Which is how Godot's --write-movie is intended to be used, I guess, but it was new to me, and being able to let AI write the promo was much more successful than my earlier attempts at recreating the game's feel in external Lottie software.

What this means

Now, AI saved a lot of time here, and that's not so surprising. But the main thing I want to point out about these examples is that most of these are throw-away scripts; code that lives outside the main codebase. It doesn't really matter if it's poorly architected or not maintainable, as long as it does the job the one or two times I need it. This sidesteps one of the common objections against AI coding tools, which is that they are not (yet) able to build clean, well-architected systems. Plus, if AI didn't write these, probably no one would have, because it just didn't make sense before.

On the other hand

Still, some objections remain. And they are clearer when viewed through the lens of the examples we went through above. Here are a few:

You miss out on learning opportunities. I now don't know how to automate iOS screenshots, or the intricacies of converting avi to mp4. I'm still not able to use Lottie animation software properly. I do have some AI-written examples to learn from if I did ever need to learn these skills, but they tend to be inscrutable. Which brings me to the next point,
You become reliant on AI. When I tried to edit the code for the promo video, I simply... couldn't. Sure, given a few hours and maybe some questions to the agent about how it all works, I could've gotten there. But at the point it would probably have been better to write the code from scratch myself. With the sunk cost fallacy firmly forgotten, I kept prompting away for hours to get it to match my original vision. AI becomes the only lense through which you can understand the code.
It doesn't consistently save time. In some of these examples, the time savings were obvious and immediate. In the promo video case, I'm not so sure. I guess what I take away from this is that, since it's quite easy and fast to try, it's worth asking the AI to see if it works, but when you get 5-6 prompts in and it's still not looking good, then perhaps it's time to suck it up and do it yourself.

Updating our mental models

The Automation XKCD comic was released in 2014, and it has, despite obvious exaggeration for humorous effect, been part of my mental model about what is worth automating and what is not ever since. The threshold for “worth automating” has collapsed, and this mental model now needs to be updated.

A script that once required half a day of context-switching, setup, and debugging can now often be produced in minutes. For the first time, the "Theory" part of the comic really does match reality (or can, at least).

An old, invisible category of software will now experience a quiet growth: disposable automation. Small, messy, highly specific tools that exist only to solve one problem and then quietly disappear. Historically, many of these tasks stayed manual because the overhead of writing the automation outweighed the benefit.

There's a parallel here with MCP servers and OpenClaw, where you let AI connect to services to perform mundane tasks for you. The small difference is that you're asking AI to write code, executing that code only once, or a few times, and then throwing it away. This may also be one of the safest and most effective uses of AI coding tools right now. Throw-away scripts do not need perfect architecture, long-term maintainability, or elegant abstractions. They just need to work well enough to save time.

About the game

Thanks for reading. If you're interested, the project mentioned in this post is a mobile game called Sky Lobby. You design and dispatch elevators in ever-growing skyscrapers. You need to place stops, build sky lobbies, and keep people moving as each tower becomes more crowded, more complex, and less forgiving. It's pretty fun, and I had a lot of fun developing it.

Aquileo | A Free Chinese Dictionary, and Why I Built One

2026-04-16T00:00:00+00:00

A few weeks ago I launched the Moya Chinese iOS app, the spaced-repetition Chinese flashcards app that, eleven years after my first attempt, finally seems to be working for me. I'm on a 50-day streak, and I can barely believe it! Since the initial launch, I've released several more versions with lots of improvements, including listening and character writing modes and an integrated dictionary.

And today I'm launching its companion: a free web dictionary at moyachinese.com.

If you're excited about the idea and just want to try it, great, please go ahead! Or if you want to know why a perfectly good world full of perfectly good Chinese dictionaries needed yet another one, read on.

Yet Another Chinese Dictionary?

I love a good Chinese dictionary. MDBG, Pleco, LINE Dict — I've used them all, and they're all wonderful in different ways. So I want to be upfront about it: the Moya Chinese dictionary is standing on the shoulders of giants, and I owe a lot to MDBG in particular.

But here is what Moya Chinese does differently:

Clean design. As much as I've loved using MDBG over the years, its design really felt like it was leaving a lot to be desired, and I don't think it's been updated in the 15 years I've been using it. With the Moya Chinese dictionary I wanted to address this, first and foremost.
Fine-tuned search algorithm. It's hard to create a dictionary search that works the way users expect, and often with other dictionaries I couldn't find what I was looking for. So I put a lot of thought into how to do this for Moya. By combining factors like how common the word is, its HSK level, and how well it matches the search term, I think I've landed on something that works well most of the time.
120,000+ words, with pinyin, English, and a breakdown of each character's components.
Search in Chinese, pinyin, or English. No need to switch input methods to look something up.
Paste a whole sentence and it will break the sentence down into words and translate each. Useful when you're squinting at a Chinese subtitle and the dictionary lookup is happening in your head one syllable at a time.
Example sentences for every word in the HSK and TV/Movie frequency lists (sourced from Tatoeba)
Interface in English, French, Spanish, Japanese, or Korean. Same as the iOS app.
Free, no ads, no account. I just wanted to provide something useful to the community. Bookmark it, and use it when you want to look up a word.

That's roughly it. The design goal was the same as for the iOS app: useful, clean, no nonsense. And the plan is to (soon) integrate the two, so that when you look up a word in the dictionary, you can easily add it to your flashcard study queue.

The Long Tail, Revisited

In my post about the iOS app, I related how I built a website called ChineseLevel on the premise that knowing the top 1,000 most common words would let you understand 95% of a newspaper. This is a tempting and very wrong idea, and I now believe it has done some damage to a lot of beginners (sorry).

It's tempting because the underlying math really does work. The first ~590 Chinese characters cover about 80% of running text, ~940 cover 90%, and ~2,400 cover 99% (Chinese character frequency, Wikipedia). You can see the curve flatten out quite dramatically:

The shape of that curve is roughly Zipfian, the same distribution that shows up in word frequencies in pretty much every language ever measured (SUBTLEX-CH, Cai & Brysbaert, PLOS ONE 2010). And it really is true that if you know the top 940 characters, you'll recognise 9 out of every 10 characters on a page.

The problem is that the one in ten you don't recognise is, almost without fail, the character that carries the actual information. The rare word "indictment" matters more to a news article than the next thousand instances of "the". A linguistic version of the Pareto principle seems to apply here: a small fraction of the words do most of the work, but a different small fraction of the words carries most of the meaning.

This is why a 120,000-word long-tail dictionary is, in my opinion, exactly the kind of dictionary a learner needs by their side. The first 2,000 words you can get from your textbook. It's the next 100,000 that decide whether you can read a novel or follow a TV series.

The HSK That Was, and the HSK That Will Be

If you're learning Mandarin in any structured way, sooner or later you're going to bump into the HSK (汉语水平考试), the standard Chinese proficiency test. The current syllabus, HSK 2.0, has six levels and tops out at around 5,000 words. The new HSK 3.0 standard, published in November 2025 and effective from July 2026, keeps the lower levels but extends the ladder all the way to 11,000 words across nine levels:

That's more than doubling the official upper bound, and the new levels 7–9 are designed to take learners well into the long tail. I think this is great.

But even the new HSK doesn't quite plug all the gaps. A recent post on the Moya Chinese blog, The Words HSK Forgot, is about exactly this: I crunched subtitle frequency data against the HSK lists and found that roughly half of the most common words in Chinese media don't appear in HSK at all. Words like 女孩 (girl), 男孩 (boy), 加油 (the universal cheer), 之前 (before), 之后 (after) — all conspicuously absent. The HSK and the subtitle corpus simply have different goals: one optimises for cultural breadth and exam-fairness, the other reflects what people actually say to each other. HSK 3.0 closes the gap a lot — top-1,000-word coverage jumps from 48% to 76% — but a gap remains.

Robots, Buddies, and Other Joyful Compounds

Long-tail vocabulary is also where Chinese is at its most fun. The other post I want to point you to is Machine Person: All the Ways to Say "Robot" in Chinese. The standard mainland word for "robot" is 机器人 jīqìrén, literally machine person. In Hong Kong, it's 机械人 jīxièrén, mechanical person. A humanoid robot is a 人形机器人, a human-shaped machine person, which is delightful.

English borrowed "robot" from the Czech robota (forced labour), via Karel Čapek's 1920 play R.U.R. (Wikipedia: Robot). Chinese, characteristically, just describes the thing. The same instinct gives us 飞机 (flying machine = airplane), 手机 (hand machine = mobile phone), and ancient automatons called 木人 (wooden person). Once you start seeing the pattern, every new word feels a bit like solving a tiny cryptic crossword clue.

There are a few more posts up already, including one on why spaced repetition works for Chinese and one introducing Word Snake, a small puzzle game where you chain HSK words across an 8×8 grid of characters. I'm planning to write more along these lines — short, opinionated, hopefully useful, with a leaning towards the kind of vocabulary the textbooks skipped.

Try It

The dictionary is at moyachinese.com. The iOS app is on the App Store. Both are free. If you give either of them a try, I'd genuinely love to hear what you think: what works, what doesn't, what words you wish were there. Send me a note, and I'll keep tinkering.

再见 zàijiàn!

Aquileo | Moya Chinese

2026-03-03T00:00:00+00:00

Today, I'm super happy to launch my new iOS app for learning Chinese, 11 years in the making. But before I say more, let me tell you the story of how I got here.

As an English-speaker, Mandarin has a steep learning curve, with its reliance on tones and thousands of characters. My Mandarin-learning journey started 17 years ago, and it was slow-going initially. But as time went on, and I got over the initial hump, things started clicking. At least the grammar is quite simple really, without many irregularities, and once you remember the hundred or so basic components of characters, they become easier to learn as well.

Of course, traveling to China and living in Taiwan for many years also helped a lot; there's nothing like constant immersion to get the brain into gear. But eventually my time there came to an end, and since then I've found it hard to keep the muscle practiced.

So 11 years ago, over a weekend, I built a simple spaced-repetition flashcard app as an initial experiment with React Native. It became, as far as I know, the first React Native app to be published on the iOS app store, outside of Facebook. I wrote a very excited technical blog post about the experience at the time. The post was well-received by the programming community, and a few intrepid Chinese learners even paid the $0.99 to try it out. I was thrilled!

But it didn't help my Chinese very much, I'm afraid. The first version of the app only had relatively simple words. It failed to form a learning habit for me, I never developed it further, and eventually I stopped learning Chinese altogether. But I've always been fascinated by language learning and acquisition, and in the intervening years I have accumulated many thoughts about it. One, which is backed by a lot of science, is that consistency is king. It's far better, in terms of long-term retention, to learn a little bit every day than it is to cram the same amount in a short period of time. Another is that long-tail vocabulary is actually really important. Let me explain.

Another website I developed, a few years before the React Native flashcard app, was called ChineseLevel. It operated on the idea that if you knew the first 1,000 words in order of the frequency that they appear in texts, then you should be able to understand, say, 95% of a newspaper. With 2,000 words, 99%, and so on. So I wrote a little online test you could do to check your level, and then recommended newspaper articles of that approximate complexity, as far as possible. It worked, and proved fairly popular actually.

But it had a fatal flaw: that idea is wrong. Why? Well, it IS true that you would only need to look up maybe 1% of the words in the article, so that is useful, but it is NOT true that you would actually understand 99% of what is written without looking anything up. In fact, you will probably understand around 0%. That's because all the critical information you need for understanding is very likely to be contained in exactly that one word you don't know. In fact, the rarer the word is, the more information it carries! So while learning words in the order of frequency is a reasonable approach, I guess, learning long-tail vocabulary is actually really important for any kind of understanding in real-world situations.

That brings us to the present day. After many years of living in England and not practicing Chinese at all, I wanted to start improving it again, but I wasn't willing to relocate my family to Asia (my kids probably wouldn't have been very thrilled either). So, next best thing, I wanted an app that combined those two insights: consistency, and long-tail vocabulary, so that I can build a habit of learning new words. I've tried flashcard apps like Anki before, and often I would spend a few hours building decks, but then run out of steam actually learning them after a few days. It's especially demotivating if you miss a few days, then come back to a huge backlog of words that would take hours to go through. Often my habit stopped right there.

And that's where Moya Chinese came from. It's a Chinese-learning app for learners that have at least basic familiarity with Chinese, and it helps them build their vocabulary further. It is best paired with some other form of immersion, like classroom learning, videos and movies, or actually visiting places where Mandarin is spoken. For me, that's Chinese TV series—they can be really good!

To make habit-forming natural, the app has some very minimal gamification. You start with a bamboo seedling, and every day you reach your goal, it grows a tiny bit. After a few months of consistent learning, it will grow into a huge, thriving bamboo plant: a visual metaphor for the growing you have been doing yourself. And to add a teeny bit of excitement, the app also rewards you with random items along your journey that you can use to decorate the room around the plant. These gameplay elements are very minimal on purpose: I don't want to waste your time, and the app is focused on learning. It won't have ads, and I want users to only spend a few minutes a day, but every day. Consistency is king.

I also worked out a new spaced repetition algorithm for the app so that you don't get the Anki problem of backlog fatigue. I won't go into the details here, but it's meant to better balance the competing goals of resurfacing words just as you're about to forget them and habit-forming with a constant amount of time spent every day. I relied on the HSK system for determining your approximate level and building relevant vocabulary from there.

If you know anyone learning Mandarin, I'd be very grateful if you told them about Moya Chinese and encouraged them to try it and send me some feedback. I'm actively looking to improve it further, the app even ships with a way to vote on what the next features should be. (You can also vote here.) It's free to download on the Apple App Store. (Sorry Android users: no Android support yet, but you can vote for it on the roadmap).

In any case, even if I remain the only person to ever use this app, I'd still be happy. Throughout the beta-testing period I've built solid recall for hundreds of new words, and it's exciting to recognize them in the series we watch, and know my comprehension is improving. And I'm just as excited to see where this will lead. Thanks for reading, 再见 zàijiàn!

Aquileo | New Game: Picnic on the Moon

2026-02-07T00:00:00+00:00

I've added a new game to the site: Picnic on the Moon. 🚀 It's a daily puzzle game where you need to figure out the hidden connection between the items that a robot is bringing on a picnic. Try to solve it in as few guesses as possible, and check back every day for a new puzzle!

This is part of a new section of the site called "Fun & Games". The other section there, also added this week, is the Spelling Bee Analysis, a more data-driven look at the New York Times Spelling Bee, inspired by the blog post about solving every Spelling Bee puzzle, now and forever.

I'm planning to add some more experimental puzzle games in the coming months. Claude Code is making it easier than ever to try new ideas and see what's fun. It's exciting to finally get a chance to materialize some of the ideas for puzzle games I've had floating in my head around for years! Stay tuned for more, and let me know if you have any feedback or ideas for fun puzzles you'd like to see.

Aquileo | Should Makers Still Care About Code Quality?

2026-01-31T00:00:00+00:00

For a long time now, it's been possible to divide the software world into two camps: those who see code as a craft, and those who see code as a means to an end. For the purposes of this post, let's call them Coders and Makers.

Coders vs Makers

At the one extreme, Coders believe that code should be clean, as described in books like Robert C. Martin's (a.k.a. Uncle Bob's) Clean Code or Steve McConnell's Code Complete. At the micro-level, this means variable, class, and function names should be self-documenting, comments should make intentions clear, and code re-use should be the default. At the macro-level, components should have clear separation of concerns, clean interfaces, and code should be thoroughly tested at every level.

At the other extreme, Makers pride themselves on shipping fast. They believe that clean code doesn't matter; what matters is that it works. Ship fast, ship often, worry about the code quality later (if ever). Software requirements are inherently poorly-defined and malleable, so rather than waste time building the wrong thing perfectly, build it imperfectly, get user feedback, and iterate towards the solution that users really want. If you don't, the Makers reason, you will be left in the dust by your competitors who do.

Now, I've caricatured these viewpoints, and there are many possible shades in between. In my view, the "best" viewpoint is the one that says "it depends" and adapts its approach according to context. And even though I enjoy writing code and like it to be clean as much as the next person, I just as often find myself siding with the Maker point of view in business settings, especially in startups. Of course, if you're developing software for serious use cases, like banking or healthcare, then the risks are greater and quality matters much more. But on the other hand, if you're developing a prototype to see if there's market fit for a SaaS idea, then arguably moving fast matters more. Still, Coders and Makers often struggle to see eye to eye, and product discussions can get heated when one engineer believes they should refactor the codebase, leading to better developer experience, and the other would rather ship the next feature, leading to better user experience.

…And Then Came the Agents

Okay. But this is a decades-old debate at this point. Why am I bringing this up now?

With Vibe coding becoming a thing, I think this debate is more important now than ever. It is becoming increasingly possible to leave coding entirely to LLM-powered agents such as Claude Code. And many of my programmer friends say they are doing exactly that: they hardly write a line of code themselves anymore. Their jobs now are to write the prompts that produce the code. Ideally they would review the code and correct the agent if it is going down the wrong path… but do you have the patience to carefully review thousands of lines of code with changes across a codebase, generated within a few minutes of Claude pontificating and reticulating? I don't think most of us do. So we tend to read the summary of what the LLM tells us it did, or is planning to do, and if it sounds good, we let it implement the code. And we believe we're increasing our productivity, because there's no way we could have written that much ourselves in such a short amount of time.

Taken in isolation, usually most code written by the LLM looks reasonable. Every pull request LGTM, so to speak. At the micro-level, LLMs mostly follow the good practice guidelines loved by Coders: well-named variables and functions, comments making intentions clear. But zoom out one level, and quickly you find that at the macro-level, things are a mess. Code re-use? It's more likely the LLM has defined two functions in different parts of the codebase that do the same thing, although implemented subtly differently. Clear separation of concerns? Unlikely, but maybe if you're lucky. Tests? Hopefully, if you asked for them. But do the tests have sensible assertions, or do they just run the code? Or maybe they check every minutia of the underlying code in hundreds of fine-grained test cases, losing the bigger picture. You better check. Dead or unreachable code? All over the place.

Perhaps the problem lies with me: did I provide a detailed enough specification of what needs to be done? Indeed, I could spend time writing several pages of clear design specifications, and then have the LLM implement it in one shot. Done from scratch on a new codebase, I think this may turn out okay. But when let loose on an existing codebase, my experience has been that the LLM's lack of full visibility of the big picture quickly leads to a mess. At this point in time, LLM-based systems are highly capable of handling simple tasks like basic algorithms. However, when presented with large projects over hundreds of files, they struggle to maintain order.

When recently developing the first version of a bank statement converter, I wrote almost all the code by hand, with some help from GitHub Copilot or ChatGPT here and there for completing small sections. One HackerNews observer memorably compared this approach to "banging rocks together" when compared to more agentic approaches. But I carefully desiged the interfaces, components, and individual units to a level of polish that I was satisfied with. And, to me, the codebase was relatively clean, well-tested and easy to modify. But, fearing I need to speed things up, I let Claude Code inspect the codebase and asked it to implement a new feature. Within 15 minutes it had disabled CSRF protections (to get rid of those pesky "Forbidden" errors!) and implemented a dozen new functions, hundreds of lines each, that subtly recreated already-existing functionality for user authentication but with minor modifications. It all worked, but changes it made to authentication were only applied to its new endpoints, not the existing code, so users could run into errors depending on which sequence of pages they visited. Clearly, this relationship was not meant to last, and I soon went back to my old rock-banging methods.

Yet from the Maker's point of view, what happened was all fine, right? The application after Claude's modifications did what it's supposed to. After all, I didn't explicitly ask it to keep CSRF protections intact, or to ensure existing endpoints worked consistently with the new functionality. And when I asked it to do so, it tried tirelessly until it had spent all my credits, and probably would have succeeded eventually (but never quite did, by the way).

So we're moving fast and breaking things, as Mark Zuckerberg (in)famously put it. But with LLMs, I fear we may be taking the "breaking things" part a bit too far. There is a hidden cost to messy code: development velocity decreases, because every change introduces a new bug or inconsistency somewhere else. We also risk serious security vulnerabilities. It's not just Claude's disdain for CSRF. In March 2025, Matt Palmer, an engineer at Replit, wrote a report finding that 170 out of 1,645 Lovable-created web apps were suffering from a security flaw, easily allowing hackers to extract highly sensitive information. (It should be mentioned here that Replit is a competitor of Lovable, but the vulnerability pointed out, it seems, was indeed real.)

So even the Makers, at some point, will be forced to reconcile the reality that while they were able to move incredibly fast initially, eventually the untidiness of the approach started slowing them down, perhaps to the point where they have to start looking at the code themselves, or turn to someone with the experience who can. And this is where the wisdom of "it depends" becomes so important. Maybe the fast approach was fine for the MVP (Minimum Viable Product) or MLP (Minimum Lovable Product, perhaps the more appropriate term in this setting), but be prepared to either start over or pay down that technical debt in the future, should your application gain some traction.

So what can we do?

Clearly, LLMs are extremely useful tools. And Vibe coding, still in its infancy today, very well may replace traditional "artisanal" coding in the long run as AI systems continue to improve. But we also can't (or at least, shouldn't) simply let them loose on our codebases today.

So here's an idea: what if we developed a way to measure the "cleanliness" of a codebase, both at the micro- and macro-levels, and then let the AI Agents tirelessly optimize, like only they can, until the codebase is certified as 100% "clean"? We can fight fire with fire and let the agents tidy up their own spaghetti code. Sure, it will cost us some more tokens, but it will work, right? …Right? Well, maybe.

While it definitely can help to provide AI assistants with more tools: linters, code coverage, maybe even cyclomatic complexity, I think the problem you'll run into with this is that all these tools tend to operate at the micro-level. Taking a step back to the macro-level, it becomes increasingly difficult to tell whether code is complex because the domain it's operating in is inherently complex, or the code is complex because it was poorly designed. This distinction has also been called Accidental or Essential Complexity.

But perhaps this issue, too, is not insurmountable. If we define clean code (at the macro level) as code that is easy to modify in new directions safely and correctly, then perhaps we can measure the cleanliness of a codebase. Well-designed code should be easy to understand, verify and modify, or at least as easy as the underlying domain allows. That has always been the case, and it is still true for coding agents.

So what if we created a measure that said, essentially, for a given set of changes in functionality, how many lines, functions and files need to be modified to implement it, including tests? We could have an LLM generate 100 hypothetical changes in functionality that a codebase might require in the future, implement each one, and then measure the average of this number. We could even, somehow, express the number as a percentage of the size of the codebase. Then we can optimize to get this number as close as possible to 0% (though obviously never quite reach it), and either accept or reject alternative architectural designs for the codebase based on whether this number is lower or higher.

I don't know. Maybe that could work. But the computational cost (not to mention the token cost) would make such an approach prohibitively expensive today.

I think there may be some simpler tricks worth trying first, like perhaps giving LLMs a means to "visualize" the graph of components in a codebase, and asking it to ensure the dependency graph at various levels (files, classes, functions) remains as tree-like as possible, with no cycles. And we can highlight to it, using vectorized representations, spots where code duplication seems to be high, and ask it to refactor while maintaining the tree structure and keeping the interfaces between components as clean as possible and ensure all the tests continue to pass. I'm keen to try this, and would be interested to know if others have had success with such ideas already. Maybe some MCP tools for this already exist.

Conclusion

To answer the question in the title of the post, in case it needed answering: Yes, Makers should care about code quality. And likewise, Coders should care about real-world impact. But as to how much they should care… it depends. And sometimes maybe they don't need to care at all. The goal and context of a project should always be taken into account.

With LLMs now writing so much new code, it's tempting to believe that code quality is going to matter less and less, because, after all, that will be the LLM's problem to deal with now. But low code quality can have knock-on effects with real-world impact down the line, whether it's slower velocity, bugs or security vulnerabilities. And even if extreme Makers don't care about code quality directly, they should at least care about those things.

My experience with this has been much the same as described in Mo Bitar's blog post, After two years of vibecoding, I'm back to writing by hand. From where we stand today, it seems like LLMs just cannot deliver high quality at the macro-level yet. Given the right tools, or context far beyond what they are capable of today, maybe one day they will, and I'm keen to see how we can push the boundaries of this problem. I laid out some ideas in this post that I'll be keen to try in the near term. But for now, for anything even vaguely important, I'll continue being the architect of my code and only let the LLMs sweat the small stuff that I can easily verify, thank you very much.

Aquileo | Cryptic Crosswords: What They Are and How to Solve Them

2026-01-30T00:00:00+00:00

I still remember the first time I tried doing a cryptic crossword. The clues seemed completely impenetrable.

Duck as light motorcycle loses one wheel? (6)

Resentful air spoiled farewell observances (7,5)

Highest standards of ladies' dancing (6)

What? 😂

Accepting defeat without completing even a single answer, I decided to look up the answers ^*. Maybe I'm just stupid?

Duck as light motorcycle loses one wheel? (6): SCOTER

Resentful air spoiled farewell observances (7,5): FUNERALRITES

Highest standards of ladies' dancing (6) IDEALS

What!? 😂😂😂

Clearly, these were not the crosswords my mother taught me.

I sat down and tried to make sense of this madness. Eventually, after some trial and error, it clicked. And you know what? Now I actually love solving these. Maybe exactly because they seemed so, well, cryptic, before?

Don't get me wrong: they are still very, very difficult. But no longer impossible! And if, through this post, I can help you take the same step from impossible to merely improbable, then I would have succeeded.

The Principle

Cryptic crosswords follow a simple principle once you know it: every clue has two paths to the same answer. There’s the definition, which works like a standard crossword clue, and the wordplay, which gives a coded instruction to assemble the answer from letters, abbreviations, or rearrangements. Both are present in every clue, and both lead to the same solution.

Spotting the Definition

Definitions usually sit at the beginning or end of a clue.

Example:

Duck as light motorcycle loses one wheel? (6)

Definition: "Duck" (a kind of bird)
Wordplay: "light motorcycle loses one wheel": SCOOTER → drop one O → SCOTER
Answer: SCOTER (a Common Scoter is a kind of duck)

Both the definition and the wordplay lead to the same answer, but from different angles.

Wordplay Indicators

Indicators are the puzzle’s instructions in disguise. Words like wild, holding, returning, or reportedly signal an operation to perform on letters. Recognizing this turns cryptic crosswords from random words into a kind of language that you can learn to decode.

Common types:

Anagrams: e.g. "mixed," "confused," "wild"
Containers: e.g. "inside," "around," "holding"
Deletions: e.g. "without," "losing," "missing"
Reversals: e.g. "back," "returning," "reversed"
Homophones: e.g. "heard," "aloud," "reportedly"
Palindromes: e.g. "back and forth"

Examples of Wordplay

Anagrams

Highest standards of ladies' dancing (6)

"Dancing" indicates an anagram
Rearrange ladies → IDEALS
Definition: "Highest standards"

Resentful air spoiled farewell observances (7,5)

"Spoiled" indicates an anagram
Rearrange Resentful air → FUNERALRITES
Definition: "Farewell observances"

Intuit a chess blunder, making up for it (12)

"Blunder" indicates an anagram
Rearrange Intuit a chess → ENTHUSIASTIC
Definition: "Making up for it" (this definition seems a bit of a stretch to me, maybe I'm missing something)

Containers

Don't be cruel to old comedian, simple at heart (2,4,2)

"Simple at heart" -> EASY as the middle word
"Old comedian" -> GOON, from The Goon Show
"Don't be cruel to" -> GO EASY ON

EASY needs to be placed inside GOON, leading to GO EASY ON.

Charades

Charades are a combination of synonyms or abbreviations.

Qualify to get drink for ID (8)

"Qualify" = PASS
"Drink" = PORT
"ID" = PASSPORT (PASS + PORT)

Deletions

Duck as light motorcycle loses one wheel? (6)

"duck" = SCOTER
"light motorcycle" = SCOOTER → loses one wheel → SCOTER

Double Definitions

Sometimes the answer simply comes from two different definitions. Here we need to look for overlap.

The Great Escape - film and book (6)

"Escape" = "EXODUS" → 1960s film
"Escape" = "EXODUS" → Book in the Bible

Another example:

Doubt the gospel? (8,4)

Doubt the gospel: QUESTION MARK - Mark being a book in the New Testament.
Doubt: QUESTION MARK - the "?" symbol.

Palindromes

There's some hint that the answer reads the same backwards.

Holy woman going back and forth (3) "Holy woman" = NUN - it reads the same back and forth

How I Approach a Clue Now

Look at the letter count in the enumeration
Identify the likely definition (start or end)
Find indicator words
Break the rest into wordplay units
Use crossing letters to confirm or adjust

Why Cryptic Crosswords

Cryptic crosswords are not easy. But they start making sense when you realize that every clue is a small, self-contained puzzle. The sense of order hidden in the chaos is addictive. The first few puzzles felt impenetrable, but once I started understanding the conventions, solving them felt like cracking a code rather than guessing at random words.

If you are willing to spend a few hours learning the patterns, cryptic crosswords open a new world of challenge and satisfaction. Start small, track the indicators, and have a scratchpad handy.

Cryptic crosswords can be frustrating and rewarding in equal measure. Have fun!

Notes

Most of the examples in this post are from The Guardian's Cryptic crossword No 29,916.

If you're keen to try a cryptic crossword after reading this (as you should be!), The Guardian's website has a large archive of puzzles to try.

Aquileo | Solving Every NYT Spelling Bee Puzzle, Now and Forever

2025-01-05T00:00:00+00:00

The New York Times Spelling Bee is a fun little puzzle game that asks you, given seven letters, to find as many words with those letters as you can.

Example of a past New York Times Spelling Bee game

There are a few restrictions:

the letter in the center must always be used
other than that, letters can be used any number of times
valid words must have least 4 letters

You get a score based on the number and length of words you found. For each puzzle, you get a ranking based on the total number of words that are possible, with "Genius" being the highest. There is also a special "Queen Bee" crown for finding all the words in a particular day's puzzle.

After playing this game for a while, I had many questions. How many unique games of Spelling Bee are there? Which combinations would have the most possible words? And which ones the fewest? What is the highest possible score? And can we solve all the puzzles programmatically? In this post, I will answer all these burning questions, and more.

Bringing all The Bees to the Yard

There are quite a few possible games, as it turns out. 4,604,600, to be exact. That's enough to have a unique game every day for the next 12,000 years. So it's unlikely that the New York Times will need to start repeating puzzles any time soon.

I wrote some code to first generate all the possible puzzles, then solve them.

The straight-forward way to generate all the possible puzzles is to take the center letter as constant, then generate all combinations of six letters chosen from the remaining 25 letters in the alphabet. Repeat this for every center letter, and you have all the possible puzzles.

Finding all valid solutions to a particular puzzle is also not difficult. The brute force method is to write some code that goes through the word list, and for every word check if it: 1. contains the center letter at least once, and 2. only consists of one of the seven valid letters. If so, add it to the list of valid words for that puzzle.

The tricky part, however, is checking all 4,604,600 puzzles. I estimated how long the naive method would take on my laptop, and got a number measured in years. Since I didn't want to wait around that long, I made a few optimizations. The main one was to create 26 different word lists: one for every "must-have" center character. This cut the number of words we need to check down by approximately 96%. I also removed words of length 3 or less, which removed another percentage point or two. These changes, plus a few more Go-specific tweaks, got the total time down to around 45 minutes, just enough to grab some dinner. I wrote all the results to a local DuckDB database, so I could analyze them at my leisure later.

Harvesting the Honey

Boy, were the results interesting! The graph below summarizes the maximum, minimum and average number of words for the 26 possible center letters. You can click on the labels to see each one more clearly. Friendly advice: if you see a "Q" in the center of one of these puzzles, run.

There are a few interesting things to highlight from this graph. It's hard to believe, but based on the minimums, if the center letter is an A, then there will always be at least one word, no matter what the other letters are. Here's one such example. Can you find the single word that is to be found? (Center letter in Bold) (Hint)

AOQUVXZ

Here's another one. This one actually has two valid words. (Hint).

AJOUVXZ

On the other end of the spectrum, if Q is the center letter, then in the majority of cases there are no words to be found, at all. Here is one such impossible puzzle.:

QCGHJIU

The puzzle with the most possible words has an E in the center. It weighs in at a whopping 1,390 possible words, and has a maximum score of 9,982. Here it is:

EAINRST

A Dance-off with the Official Puzzles

If you often play Spelling Bee, you may have noticed that in the above analysis, we did not account for the fact that official puzzles always have at least one pangram. (That is, at least one word that uses all the letters.) So the New York Times will never publish some of the puzzles shown earlier, like the one with Q in the center, or even the ones with A. This restriction brings down the maximum number of puzzles as well.

How many are there if we don't allow for puzzles that don't have at least one pangram? When taking the pangram rule into account, there are approximately 119,609 possible puzzles that the NY Times could publish. That's still 327 years worth of daily puzzles, but it means that quite soon, NYT will already have published 2% of all possible Spelling Bee puzzles!

As far as official puzzles are concerned, let's see what the most common center letters are. And has there ever been a puzzle with Q as the center letter? It turns out that yes, that happened on 17 November, 2023. But, surprisingly, two letters have never been the center of attention, at the time of writing: S and X:

This came as a big surprise to me, and I went back to check the data several times. But it's true! S and X have never appeared in the center of an official puzzle. Statistically speaking, it's about time—even J and Q have been in the spotlight at least once. New York Times editors, if you're reading this, here's a puzzle with both S and X, with X in the center, that will certainly get everyone talking. It has a maximum score of 538: high, but not that high. It even features 2 pangrams! (3 if you allow for a rare word.) (Hint)

XAEILST

So that's the history center letters in official puzzles. What about the frequency of letters featuring anywhere in previous official puzzles? Here's what that looks like:

Well, now I'm just getting upset! What do they have against the letter S? Is this some kind of conspiracy!? Even X has featured 109 times! In normal English text, the frequency of the letter S is 6.3%. In dictionaries, it's 8.7%. My guess is that the NYT team thinks it would be boring to be able to add S to pluralize many of the words, but that often happens with other suffixes as well, like -d or -ed. I also found that this had been noticed by others before. It's striking how similar the two graphs above look. It seems like they must drawing letters from the same distribution, one somehow different from normal English distributions, and never includes S. NYT team, if you're reading this, please consider using the letter S in a puzzle. If it helps, here is one with a maximum score of 438 and a great pangram. (Hint)

SDFGILN

For a long time puzzles also did not feature ER or ING, but eventually it did happen. In fact, ING was featured in the puzzle on the day I was writing this! (January 5, 2025)

Flight of the Four Million Bumble Bees

Spelling Bee fans can rest easy: as long as you don't go to the lengths I went to, and write code to generate and solve all possible puzzles, you have another 327 years of daily puzzles to enjoy. But I leave you with one final puzzle: one the NYT will (probably) never publish, and perhaps my favorite. It has only a single valid word, its pangram. Can you find it, and crown yourself Queen Bee of the smallest future puzzle? (Hint)

XBEJKOU

Notes

I didn't have access to the official word list used by the New York Times, so I used an open source word list for game developers. The official Spelling Bee puzzles often remove words that the authors deem obscure or offensive. My analysis showed that they have, at the time of writing, accepted 10,468 unique words, and ruled out 10,517 from my word list as being official. This still left 94,387 words about which I couldn't be sure, so in this post I assumed that all words from the word list were accepted.

Another interesting thing that came out of this analysis was that about 300 words were accepted in some official puzzles, but not in others! I suppose it's up to the puzzle author, or maybe they update their official word list over time. Anyway, I hope you had fun reading this. If you have further thoughts or insights, I'd love to chat about it! Feel free to reach out using the contact details below.

Update (6 Feb, 2026)

I recently went over this data again to see if anything changed. And it did! The letter S has finally made it to a puzzle, albeit not yet as the center letter. On 12th March, 2025 the puzzle was FABLOSU (can you find the pangram? Answer), and on the 1st of September 2025 the puzzle was BCHKLOS (2 Pangrams).

I've also added a new section to this site, Daily Spelling Bee Hints and Analysis, for daily stats that update automatically.

Comments

On 11 April, 2025, Sofia wrote in noting that since this article was originally published, NYT did actually publish a puzzle containing the letter S. Hooray! The pangram was FABULOUS, and the other letters were chosen such that there weren't too many plurals that could be formed with -S.

Sofia was also interested in the fact that no puzzle containing both E and R has ever been published, and asked what this meant for the total number of possible puzzles. If we assume this to be a steadfast rule for official puzzles, the number of possible puzzles reduces from 119,609 to 85,729. That would mean that, at the time of writing, well over 3% of all the possible puzzles have already been published.

Thanks for your delightful note and questions, Sofia!

On 22 Nov, 2025, Stephen wrote in asking what the longest possible Spelling Bee word would be, both for official and hypothetical puzzles. The longest he had come across was nationalization (15 letters).

Well, Stephen, I'm happy to report that you were right! nationalization is the longest word that's ever appeared in an official puzzle, and it appeared on January 8, 2024. Looking forward to future puzzles, the maximum would be 17 letters for a word most people would know (disinterestedness), and 18 letters for a more obscure word (coccidioidomycosis). Here are the longest possible words I found:

Count	Words
18	coccidioidomycosis
17	disinterestedness
16	antitotalitarian, associationistic, antinationalists, stereoisomerisms
15	citriculturists, transparentness, sententiousness, snippersnappers, inoffensiveness, inconveniencing, unconsciousness, semiretirements, antinationalist, electroreceptor, suspensefulness, associationists, nonindependence, defenselessness, anticlimactical, ultrastructural, inattentiveness, nonintervention, inexpensiveness, interestingness, overengineering, interconnection, micrometeoritic, nontotalitarian, nonengineerings, insensitiveness, nationalization, stereoisomerism, remorselessness, contortionistic

I removed some words ending in -esses, like disinterestednesses (19), as I think these are too rare to be accepted in official puzzles. coccidioidomycosis (18) may also be a bit rare, to be fair, and I think the real winner should be disinterestedness (17).

Thanks for the great question Stephen!

Aquileo | 3 Books for New Engineering Leaders

2024-12-21T00:00:00+00:00

It's almost the end of 2024, making it a good time to reflect on the past year. The biggest change, for me, was taking on a new role as director of engineering at CloudQuery. Coming from a staff software engineering role, then team lead, and now organizational lead, I suspected it would be a mistake to treat this new role as just another day as a software engineer. The skills I had built up on the Individual Contributor (IC) track wouldn't all translate to the new responsibilities that come with this role. And hang on, what even were my responsibilities now? I would need to do a lot of learning and growing, and not in the technical way of learning new technologies that I was used to. This was—I'll freely admit—scary. But it was also an exciting opportunity, and I decided to approach it as such.

Over the last couple of months I have read as much as I can about engineering leadership, and in this post I wanted to share with you a few of the books I found most useful, with great advice I could put into practice almost immediately. Whether you are thinking about making the transition from IC to engineering manager, from engineering manager to director of engineering, from director to VP of engineering or CTO, or even if you are an experienced engineering leader, there are lots of valuable insights packed into all these books.

1. Become a Great Engineering Leader - Build Effective Skills to Lead and Grow

by James Stanier

This book is excellent, and I was very lucky to have picked it up first. It is very pragmatic. It first explains how the different roles are defined ("VP, Director, What?") and the responsibilities that come with them. Then it moves on to practical tools and techniques for your day-to-day, and finally to strategy, planning and execution. I first read this in the weekend leading up to my first day in the role, and by following the advice, I often felt a few steps ahead, which was great.

If you've been in an engineering leadership role for a long time and are doing well in it, perhaps most of the advice in this book will not be new to you, but there should still be some ideas you can apply. The book frequently references other popular business books and briefly summarizes the key ideas (books like Team Topologies and Finite and Infinite Games), so it can also be a good entrypoint for further topics to explore.

I still return to this book frequently.

2. Scaling People - Tactics for Management and Company Building

by Claire Hughes Johnson

On a scale of pragmatism to idealism, if Become a Great Engineering Leader is all the way on the pragmatic side, Scaling People would be further towards the idealistic side. Perhaps this is not quite fair: Scaling People also comes with lots of practical, tactical advice. But the advice and wisdom is buried far deeper inside stories and anecdotes than is the case for Become a Great Engineering Leader. This made Scaling People a book that was a bit harder to get into, and one that is probably more worthwhile from a longer term perspective. It also comes with checklists and worksheets to help you on your journey.

The author, Claire Hughes Johnson, is an accomplished leader of some of the biggest, most successful software teams. First at Google, then later at Stripe. This is probably also what made the book feel less pragmatic to me, someone at an earlier stage company. But there are still plenty of good lessons for leaders at all scales. I was able to apply a lot of the advice about hiring in the last few months.

The last thing I'll say about this--something I didn't realize at the time of purchase--is that this book is published by Stripe Press. Yes, a publishing arm owned by the very same Stripe the author works at. The result is, unfortunately, that many sections of the book, however well-intentioned, read like sales material trying to convince the reader to join Stripe. I didn't count exactly, but roughly half the book is dedicated to sections laying out Stripe's values, documents and history.

3. How Big Things Get Done - The Surprising Factors Behind Every Successful Project, from Home Renovations to Space Exploration

by Professor Bent Flyvbjerg, Dan Gardner

By my own criteria from a blog post 6 years ago, I probably shouldn't have picked up this book, as it includes the word "surprising" on the cover. But I listened to this book in audio format, and so I didn't see its cover, and at least it did well on the other two criteria, by having generally great reviews and being written by an expert in the field. And it just goes to show, heuristics are just that: heuristics! I'm glad I picked it up.

This book is not as directly applicable to engineering management as the previous two on the list, but my main take-away from it is in how to better estimate how long complex projects will take: a critical skill for any engineering manager who needs to negotiate and communicate this with other parts of the business.

A very natural mistake we often make when estimating how long projects will take is to think about all the individual tasks that make up the project, estimate how long each of those should take, and then add them up to guess how long the project should take overall. If we have some experience in project estimation, maybe we'll add a fudge factor, like 2x, to account of unknowns, or try to account for Hofstadter's law.

But the authors argue, quite persuasively, that a better approach is to use what is called reference-class forecasting (RCF), a framework initially developed by Daniel Kahneman and Amos Tversky (and won them the Nobel Prize in Economics, by the way). RFC is a fancy name for what is essentially the idea that you should look at previous projects of a similar class to estimate how long your project will take. You can then add or subtract some time based on any factors that make your project (or team) special or different. For example, if you are planning on adding customizable dashboards for your SaaS product, the best way to estimate how long that will take is to look at how long it took to add in other products, and then adjust from there. Now, this information is often hard to come by, and that's probably the fatal problem with this approach, but with some creativity, it can usually be done with some degree of accuracy, which is enough for decent forecasts.

Honorable Mentions

Supercommunicators

by Charles Duhigg

Supercommunicators explores the art and science of effective communication, revealing the strategies and techniques used by skilled conversationalists to navigate challenging topics, build connections, and guide decisions. Through real-world examples, the book uncovers how to turn difficult conversations into successful outcomes.

Good Strategy / Bad Strategy

by Richard Rumelt

The main message is that good strategy stems from a clear understanding (or hypothesis) of what the biggest problem is to solve, and coming up with a set of actions that will solve this problem. Good strategy amounts to more than simply setting ambitious goals or thinking positively.

Closing Thoughts

There are many more books that could have made this list; books like An Elegant Puzzle, The Manager's Path and The Engineering Executive's Primer, for example. I would also recommend these. At the end of the day, it's good to know where to start, but I believe it is just as important to read widely, both in categories directly applicable to your field and in those adjacent. Build a picture of the full spectrum of ideas, in order to form your own opinions.

There's already a long list of books on my reading list for 2025. Some of these include books that challenge how we think, explore new ways to lead, or dive into technical details that might not directly apply to my daily work but still spark fresh ideas. Reading broadly doesn't just expand your knowledge—it helps you see problems from new angles and come up with creative solutions. My 2025 reading list is already growing, and I’m excited to discover new insights that could shape how I work and grow in the coming year.

Aquileo | Moving my Blog from Hugo to Zola

2024-12-15T00:00:00+00:00

After a brief 6 year hiatus, I felt it was time I started posting to my blog again. Six years is a long time in software, so when I ran hugo serve with the latest version of Hugo, all I got was a blank page. No errors, no logs, just a blank page. Hmm.

Hugo, in case you don't know, is now a very popular static site generator, written in Go. But back when I started using it, it was a relatively young upstart with a lot of promise. It comes with some nice-looking templates, live-reload features and a very active community. But right now I was getting a blank page, with no hints where to go next. So, naturally, I went to Google.

After some Googling and browsing through the Hugo changelogs and issues (there were not supposed to be any breaking changes between the version I had last used and the latest), I still didn't know why I was getting a blank page. Well, I thought, maybe 6 years ago this would have taken ages to solve, but this is 2024, we have AI assistants now, right!? This is a great chance to try out Aider! Aider is an AI coding assistant that runs in your terminal and can use all your code as context. I installed it, and asked it to fix the blank page I was facing. Amazingly, within a few iterations, Aider was actually able to update the code in a way that at least resulted in more specific errors. A few more iterations and a bit of Googling later, my blog was working again. Hooray!

Except that the styles were all wrong. The theme I was using also wasn't compatible with this version of Hugo anymore, so it needed to be updated. I spent about 30 minutes trying to do so, without success, and it was at this point, 2 hours in, that I was reminded of Hugo's terrible templating system (which, to be fair to Hugo, is based on Go's terrible templating system). Aider wasn't able to come to my aid here. So then a thought occurred: "Hey, writing a static site generator can't be that hard, can it? What if I made my own, with some Jinja-like templating? That would be nice."

All memories of actually wanting to write a blog post were long gone by this point, so I cracked open my Go IDE and started coding. After about 30 minutes I had something going with Pongo, a template engine for Go with Django-like syntax. It had been a few years since I used a non-standard template engine for Go, and it seemed like Pongo didn't really support template inheritance, one of the most important features of Django templates. This is when it became clear that this was going to be a bigger project. And maybe Go isn't the best fit for this... I've been wanting to start a project in Rust for a while now, maybe I should do that?

I was just about to run cargo new, but then thought, maybe, just maybe, someone else had the same idea before me. And indeed, when looking for static site generators written in Rust, I found a few candidates. The most promising of those turned out to be Zola. And that, kids, is how I met your ~~mother~~ static site renderer written in Rust.

It seemed like the creator of Zola shared my dislike of Hugo's template engine, which instantly made me like it more:

This tool and its template engine tera were born from an intense dislike of the (insane) Golang template engine and therefore of Hugo that I was using before for 6+ sites.

Zola comes with most of the same features as Hugo: single binary, live-reload, syntax highlighting, Sass compilation, and more, but with a Django-like template syntax (that actually supports template inheritance). I couldn't believe it. Another dream crushed before it even began. I pressed Ctrl+C on the incomplete cargo new command in my terminal, and typed zola init blog instead.

Zola's documentation is okay, and I'm not about to bash a free and open source project for not having great documentation, but I did have some trouble initially figuring out the lay of the land, and the documentation didn't really help there. What helped most was finding some example projects, helpfully listed in EXAMPLES.md. After looking through a few of those (and their source code), I got the basic idea. You have a content directory, which has subdirectories containing markdown files. In each subdirectory, you can place an _index.md file to control some options and (optionally) render a page at the root of the directory. For example, I put my blog posts in a posts directory like this:

├── posts
│   ├── 2014-04-14-the-popularity-of-go.md
│   ├── 2014-04-16-why-is-go-popular-in-china.md
│   ├── 2014-05-03-efficient-string-concatenation-in-go.md
│   ├── 2014-05-19-running-the-go-race-detector-with-cover.md
│   ├── 2014-12-13-solving-regex-crosswords-using-go.md
│   ├── 2015-01-26-open-source-go-projects-to-learn-from.md
│   ├── 2015-04-03-building-a-flashcard-app-with-react-native.md
│   ├── 2017-10-01-bit-manipulation-in-go-1-9.md
│   ├── 2018-07-09-rules-for-choosing-nonfiction-books.md
│   └── _index.md

And inside _index.md, I have this:

+++
title = "Herman Schaaf"
description = "Herman Schaaf's personal blog and website"
page_template = "post.html"
redirect_to = "/"
[extra]
+++

Something that tripped me up a bit is that there are two similar settings available: template and page_template. It turns out that template is for controlling the template that renders the root page, while page_template refers to the template used by all the other markdown files in the directory.

To ensure consistency with my previous Hugo website and not have broken links, I added a path to the frontmatter of all my markdown files, to ensure they are still available at the top-level, like this:

---
title: The Popularity of Go
description: Some observations from Google Trends
path: /the-popularity-of-go
slug: the-popularity-of-go
date: 2014-04-14
---

Overall, moving from Hugo to Zola was quite easy. I decided to take the opportunity to also write my own styling, rather than use an off-the-shelf theme like I had done previously with Hugo. I had to make some small changes to the markdown frontmatter and content for compatibility with Zola. For example, Zola didn't recognize text or plaintext as a valid language for code snippets, but txt works fine. In the frontmatter, I had to use description rather than subtitle. I also ran into an issue where the hot-reloading feature of Zola sometimes hid errors from me, which took me a while to figure out. After this I learned to stop and restart zola serve if something wasn't acting like I expected, to make sure I'm getting all the errors. But that was basically it.

With 14k+ stars on GitHub at the time of writing, I clearly wasn't the first person to come across Zola. But the work put into it by a passionate community has clearly paid off, and I want to thank everyone who contributed to the project so far. I could have spent the next couple of ~~months~~ years developing this myself, but truth be told, I'm glad I didn't have to. And, hey, look, in the end I actually did write that blog post.

Aquileo | 3 Rules for Choosing Nonfiction Books

2018-07-09T00:00:00+00:00

I love reading nonfiction. But, as I am sure you can relate, I only have limited time. Even if we were able to make enough time to read one book a week on average—certainly not the case for me right now—we would still only be able to read around 3,000 books in our entire adult lives. At my current pace, the real number will likely end up being far lower.

With this in mind, I want to spend my time reading good books! But how can we identify those, without first reading them? Today I want to share my heuristics for choosing good nonfiction books to read. I will also evaluate them against the books I have read in recent years, to see if they generally match up with my ratings.

Before I start, a disclaimer: All of this is, of course, highly subjective. I read nonfiction for enjoyment, and I enjoy nonfiction most when I am learning interesting things, or am guided to think in new ways. Preferably, claims should be backed by peer-reviewed studies, or presented as speculation otherwise. Either way, the author should be clear about this, and unbiased enough to present different sides of the issue.

With that out of the way, let's look at the rules.

Rule #1: Prefer books by experts in the field

The best nonfiction books I have read have invariably been by folks who spent their lives researching that particular issue. A couple of books in this category immediately come to mind: Why We Sleep, The Language Instinct, Gödel Escher Bach.

Positive indicators of this in a blurb may include "Professor in [field directly related to the book's topic]", "Long-time researcher in [field directly related to the book's topic]". Similarly, be wary of terms like "expert", "thought leader" and "journalist".

Yes, no books by journalists, unless it's about journalism. If the author is not an expert in the field, they should at least be a long-time practitioner. Malcolm Gladwell's books are enjoyable—there is no denying he tells compelling stories—but ultimately they rely heavily on anecdotal evidence. In general, I find that books by journalists cherry-pick examples to fit the argument, and gloss over (or completely ignore) evidence to the contrary.

Rule #1 does not apply to Biographies. Biographies are different. You do not need to be a professor of history to write a compelling and informative biography on John D. Rockefeller, nor do you need to have known him personally. I have read many excellent biographies written by journalists. Journalists are experts in the skill of using many disparate sources and weaving it into a compelling narrative. Certainly, this often results in opinionated character depictions, but I believe these are subjective by nature.

Rule #2: Only accept Goodreads ratings of 4.0 and up

An average rating on Goodreads higher than 4.0 with at least 100 ratings is always good sign. This XKCD comic explains this phenomenon well:

Unfortunately, Goodreads ratings are often not unbiased, and many of the reviews are from readers who received free copies in exchange for their reviews. That's why this is only Rule #2. It's also a good idea to read some of the lowest-rated reviews first, to see what the main complaints about the book are, and whether they would put you off reading it.

Rule #3: No books with the word "surprising" on the cover

This is targeted at books that market themselves as "the surprising truth" or "the surprising science" behind such and such. Often these books are already discarded by Rule #1 and #2. But for when they are not, Rule #3 exists to protect against over-simplification and one-sided arguments. I have not read all books with "surprising" on the cover, but the ones I have, I have found to be lacking.

Case studies

The following list of books was chosen from my Goodreads history, and I tried to choose a range of books that I rated between 1 star and 5 star. If you are wondering, the ratings were given shortly after I finished the books, and I had not created the 3 rules at that point. Let's see how the rules do against my subjective evaluations of some books I have read:

My Rating	Notes
5 stars	✓ Written by an expert ✓ Goodreads rating above 4.0 ✓ No "surprising" Why We Sleep: The New Science of Sleep and Dreams by Matthew Walker is hands down the best nonfiction book I have read this year. It is also the most terrifying. An experienced sleep scientist explains the ins and outs of sleep and the effects of sleep deprivation on human health. I tell just about everyone I meet about how fantastic this book is. And luckily, it also meets all the criteria for a good nonfiction book. Phew!
5 stars	✓ Written by an expert ✓ Goodreads rating above 4.0 ✓ No "surprising" Gödel, Escher, Bach: An Eternal Golden Braid ranks among my favorite books of all time. It takes dedication to read it, but the insight (and humor!) in this tome is priceless. Written by a professor of cognitive science and comparative literature at Indiana University, Gödel, Escher, Bach explores common themes in the lives and works of logician Kurt Gödel, artist M. C. Escher, and composer Johann Sebastian Bach, and expounds concepts fundamental to mathematics, symmetry, and intelligence.
5 stars	✓ Written by an expert ✓ Goodreads rating above 4.0 ✓ No "surprising" The Lean Startup: How Constant Innovation Creates Radically Successful Businesses, by Eric Ries. As a startup founder, Eric Ries was arguably not an expert in startups when he wrote this book, but he was a long-time practitioner. This book gives excellent advice, and has been a manual used by many successful businesses across the world.
4 stars	✓ Written by an expert ✓ Goodreads rating above 4.0 ✓ No "surprising" Endless Forms Most Beautiful is by an expert in evolutionary development, and both its subject and its prose are, indeed, most beautiful.
4 stars	✓Written by an expert ✓Goodreads rating above 4.0 ✓No "surprising" In The Gene: An Intimate History, Siddhartha Mukherjee relates stories from his childhood and family to bring the realities of the diseases he spent his life studying into focus. It's rare that a book is both as moving and enlightening as this.
3 stars	❌ Written by an expert ✓ Goodreads rating above 4.0 ✓ No "surprising" Inferior: The true power of women and the science that shows it, by Angela Saini. This one, being written by a journalist, breaks rule #1. Although it was a compelling read, and I learned some interesting things, the argument was one-sided and ignored a lot of evidence against it. See this review for a thorough explanation.
3 stars	✓It's mostly a biography ❌ Goodreads rating above 4.0 ✓No "surprising" Alibaba: The House That Jack Ma Built, by Duncan Clark. An enjoyable read, but not very memorable, nor does it provide much insight into Alibaba itself.
3 stars	❌ Written by an expert ✓Goodreads rating above 4.0 ✓No "surprising" Outliers: The Story of Success by Malcolm Gladwell was an entertaining read, there is no denying that. But like other Malcolm Gladwell books, it cherry-picks examples and tries to draw grand conclusions from them. We are left with interesting ideas, but only anecdotal evidence to judge them by.
2 stars	✓ Written by an expert ❌ Goodreads rating above 4.0 ✓ No "surprising" How the Mind Works, by Steven Pinker, covers a topic that I am endlessly fascinated by. It is also written by the author of one of my favorite books, The Language Instinct, so I really expected to enjoy this. However, I found it rather dry. You can read my full review on Goodreads, but I gave it 2 stars at the time. And with a Goodreads rating of 3.97, it only meets 2 of the 3 criteria for choosing good nonfiction books.
1 star	❌ Written by an expert ❌ Goodreads rating above 4.0 ✓No "surprising" Money: Know More, Make More, Give More, by Rob Moore. I don't even want to talk about how bad this book is. But the fact that it broke two rules is a good indication that the rules are on solid ground.
1 star	❌ Written by an expert ✓ Goodreads rating above 4.0 ❌ No "surprising" I found The One Thing: The Surprisingly Simple Truth Behind Extraordinary Results by Gary Keller to be very repetitive, and every example was explained as the person focusing on "one thing", when instead they were clearly focusing on multiple things. Also notice the use of the phrase "surprisingly simple" in the title! In fairness, Goodreads users don't agree with my opinion: they give it an average rating of 4.16. That's fine, and also why I don't rely solely on Goodreads ratings. I'd encourage you to read at least a bit of the book, and see whether or not you agree.

For this small sample of books, the three rules perform remarkably well. I'll admit, I am surprised! On average, I rated books that meet all three criteria 4.6 stars, two out of three criteria 2.75 stars, and one out of three 1 star. Of course, my ratings are completely subjective, but I did give these ratings long before coming up with the rules, and they seem to be a very good guide.

Do you use a different set of rules? Or do you have a system that covers fiction books as well? I would love to hear about it.

You can also read replies to this on Hacker News.

Aquileo | Efficient Bit Manipulation in Go 1.9

2017-10-01T00:00:00+00:00

Go 1.9, released in August 2017, introduced the maths/bits package. This package provides optimized functions for bit counting and manipulation of unsigned integers. These are useful in low-level environments where the individual bits stored in an integer are of importance. Let's take a look at some of the functions.

First up, Len returns the minimum number of bits required to represent a value x.

package main

import (
	"fmt"
	"math/bits"
)

func main() {
	var a uint = 31
	fmt.Printf("bits.Len(%d) = %d\n", a, bits.Len(a))

	a++
	fmt.Printf("bits.Len(%d) = %d\n", a, bits.Len(a))
}

Which outputs:

bits.Len(31) = 5
bits.Len(32) = 6

Playground link

This is because 31 is 11111 in binary, and 32 is 100000. The first significant bit is in each case is in position 5 and 6, respectively, when counting positions from the right.

This also allows us to easily illustrate the OnesCount function, which returns the number of bits set to 1 in a given number:

package main

import (
	"fmt"
	"math/bits"
)

func main() {
	var a uint = 31
	fmt.Printf("bits.OnesCount(%d) = %d\n", a, bits.OnesCount(a))

	a++
	fmt.Printf("bits.OnesCount(%d) = %d\n", a, bits.OnesCount(a))
}

which outputs:

bits.OnesCount(31) = 5
bits.OnesCount(32) = 1

Playground link

We also have LeadingZeros, TrailingZeros, Reverse and ReverseBytes. Let's use all of these in a single program to demonstrate how they work. In the next example, we use the uint16 version of these functions to keep the output short and readable. We could just as easily use the 32-bit, 64-bit or unspecified versions.

package main

import (
	"fmt"
	"math/bits"
	"os"
	"text/tabwriter"
)

func main() {
	// read an unsigned integer from stdin
	var i uint16
	_, err := fmt.Scanf("%d", &i)
	if err != nil {
		i = 100
		fmt.Println("Defaulting to 100")
	}

	// create a tabwriter for formatting the output
	w := new(tabwriter.Writer)

	// Format in tab-separated columns with a tab stop of 8.
	w.Init(os.Stdout, 0, 8, 0, '\t', 0)

	fmt.Fprintf(w, "Binary:\t%0.16bb\n", i)
	fmt.Fprintf(w, "Len:\t%16d\n", bits.Len16(i))
	fmt.Fprintf(w, "Ones count:\t%16d\n", bits.OnesCount16(i))
	fmt.Fprintf(w, "Leading zeros:\t%16d\n", bits.LeadingZeros16(i))
	fmt.Fprintf(w, "Trailing zeros:\t%16d\n", bits.TrailingZeros16(i))
	fmt.Fprintf(w, "Reversed:\t%0.16bb\n", bits.Reverse16(i))
	fmt.Fprintf(w, "Reversed Bytes:\t%0.16bb\n", bits.ReverseBytes16(i))

	w.Flush()
}

An example run with 123 as the input gives us the following:

$ go run bits.go 
123
Binary:         0000000001111011b
Len:                           7
Ones count:                    6
Leading zeros:                 9
Trailing zeros:                0
Reversed:       1101111000000000b
Reversed Bytes: 0111101100000000b

Playground Link

It's not difficult to see what these functions do: LeadingZeros returns the number of zeros to the left of the most significant set bit. TrailingZeros returns the number of zeros to the right of the least significant set bit. Reverse returns the number with all bits in reverse order, and ReverseBytes reverses the number byte-by-byte, that is, in 8-bit blocks.

How does it perform?

This is all good and well, and it can be useful at times. But some of these functions are relatively simple to implement manually. How much more efficient are the library implementations, really?

Let's compare the performance of OnesCount64 with that of a naive algorithm for counting the number of set bits. Below is a simple benchmark that compares a naive implementation of OnesCount64, which uses bit shifting to count the number of set bits, to the built-in bits.OnesCount64:

package main

import (
	"math/bits"
	"testing"
)

func NaiveOnesCount64(x uint64) int {
	var c, i uint64
	for i = 0; i < 64; i++ {
		c += (x >> i) & 1
	}
	return int(c)
}

var numbers = []uint64{
	0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
	100, 200, 300, 400, 500, 600, 700, 800, 900,
	11111, 22222, 33333, 44444, 55555, 66666, 77777, 88888, 99999,
	190239012390, 123901312, 6549654, 45904059,
}

// Output is a global sync variable so that test outputs
// do not get elided by the compiler.
var Output int

func TestNaiveOnesCount64(t *testing.T) {
	m := len(numbers)
	for n := 0; n < m; n++ {
		x := numbers[n%m]
		got := NaiveOnesCount64(x)
		want := bits.OnesCount64(x)
		if got != want {
			t.Errorf("NaiveOnesCount64(%d) = %d, want %d", x, got, want)
		}
	}
}

func BenchmarkNaiveOnesCount64(b *testing.B) {
	// run NaiveOnesCount b.N times
	var s int
	for n := 0; n < b.N; n++ {
		// use &31 to avoid modulo operation
		s += NaiveOnesCount64(numbers[n&31])
	}
	Output = s
}

func BenchmarkBitsOnesCount64(b *testing.B) {
	// run NaiveOnesCount b.N times
	var s int
	for n := 0; n < b.N; n++ {
		// use &31 to avoid modulo operation
		s += bits.OnesCount64(numbers[n&31])
	}
	Output = s
}

Running the comparison on a 64-bit Linux machine, we get:

$ go test -bench=Count
goos: linux
goarch: amd64
BenchmarkNaiveOnesCount64-4   	20000000	        71.6 ns/op
BenchmarkBitsOnesCount64-4    	2000000000	         1.15 ns/op
PASS
ok  	_/home/code/bits	3.946s

The built-in OnesCount is orders of magnitude faster! This is because the built-in function uses an algorithm called Parallel summing of adjacent bits. A full description of this is given in Chapter 5 of Hacker's Delight, Counting Bits. (Correction: on x86-64 systems, it actually uses POPCNT instructions, see note at bottom of this post).

Below is another benchmark comparison, this time for TrailingZeros64:

package main

import (
	"math/bits"
	"testing"
)

// NaiveTrailingZeros64 returns the number of trailing zero bits in x;
// the result is 64 for x == 0.
func NaiveTrailingZeros64(x uint64) int {
	var c, i uint64
	for i = 0; i < 64; i++ {
		if (x>>i)&1 == 1 {
			break
		}
		c++
	}
	return int(c)
}

var nums = []uint64{
	0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
	100, 200, 300, 400, 500, 600, 700, 800, 900,
	11111, 22222, 33333, 44444, 55555, 66666, 77777, 88888, 99999,
	190239012390, 123901312, 6549654, 45904059,
}

// Output is a global sync variable so that test outputs
// do not get elided by the compiler.
var Output int

func TestNaiveTrailingZeros64(t *testing.T) {
	m := len(nums)
	for n := 0; n < m; n++ {
		x := nums[n%m]
		got := NaiveTrailingZeros64(x)
		want := bits.TrailingZeros64(x)
		if got != want {
			t.Errorf("NaiveTrailingZeros64(%d) = %d, want %d", x, got, want)
		}
	}
}

func BenchmarkNaiveTrailingZeros64(b *testing.B) {
	// run NaiveOnesCount b.N times
	s := 0
	for n := 0; n < b.N; n++ {
		s += NaiveTrailingZeros64(nums[n&31])
	}
	Output = s
}

func BenchmarkBitsTrailingZeros64(b *testing.B) {
	// run NaiveOnesCount b.N times
	s := 0
	for n := 0; n < b.N; n++ {
		s += bits.TrailingZeros64(nums[n&31])
	}
	Output = s
}

Running this we get:

$ go test -bench=Trailing
goos: linux
goarch: amd64
BenchmarkNaiveTrailingZeros64-4   	300000000	         5.86 ns/op
BenchmarkBitsTrailingZeros64-4    	2000000000	         1.00 ns/op
PASS
ok  	_/home/code/bits	4.460s

Again, we see that TrailingZeros64 is significantly more efficient than the naive solution, though not by as much in this case. This time the reason is that it implements an algorithm first described by Charles E. Leiserson, Harald Prokop and Keith H. Randallin in 1998, using what is called De Bruijn numbers. It's a neat trick, and I recommend reading the original paper. (Correction: Again, it was pointed out that this is not true on most 64-bit systems, see note at the bottom of post)

Example Use Case

Now that we have seen that the built-in functions are much faster, you may still be asking "why should I care?" Bit manipulation isn't all that common of a thing to need, and we still have to shift left and right with the << and >> operators when we do need it, so this is a fair question.

One example where this has already made an impact is in Will Fitzgerald's bitset package. A blog post by Daniel Lemire shows how changing to use the new bits package made the Count function run twice as fast, and the previous implementation relied on hand-tuned assembly code!

$ go test -run=XXX -bench Count >old.txt
$ git checkout go19
$ go get golang.org/x/tools/cmd/benchcmp
$ go test -run=XXX -bench Count >new.txt
$ benchcmp old.txt new.txt
benchmark                  old ns/op     new ns/op     delta
BenchmarkCount-4           2676          1352          -49.48%
BenchmarkLemireCount-4     2569228       1401137       -45.46%

Bitsets are commonly used in all sorts of applications that are memory or space-aware, from databases (e.g. bloom filters) to priority queues and examining stream data. The use of the new bits package in bitsets provides an example of the positive impact this will have on the performance of many Go applications.

Conclusion

The new bit manipulation package in Go 1.9 wasn't celebrated all that much, but it is pretty exciting if you do low-level programming in Go. It can provide quick efficiency gains if you are already using some of these common functions in a hot path in your code. Kudos to Robert Griesemer, Roman Budnikov and Lynn Boger, who worked on getting this into the standard library.

Update: some great feedback from giovannibajo and klauspost on r/golang - apparently a lot of the efficiency of the OnesCount and TrailingZeros on 64-bit systems comes from calling POPCNT and BSF instructions when the CPU supports it. The algorithms mentioned in the article are a fallback if the system does not support these methods.

Aquileo | Diary of Building an iOS App with React Native

2015-04-03T00:00:00+00:00

When news broke that React Native was open sourced on Friday, I felt elated. This was the moment I had been waiting for. Ever since the React.js conference videos introduced React Native in late January, I couldn't wait to get my hands on it.

If you don't know React Native, it's a new open source framework by Facebook that allows you to write iOS (and, eventually, Android) apps using HTML-like code (called JSX) and JavaScript. It's based on the popular React.js JavaScript framework, but you can't run normal React.js code directly as an iOS app. Instead, once you are familiar with the basics of React.js, you can use the same knowledge, but slightly different components, to assemble iOS and Android apps. They refer to it as "Learn once, write anywhere", as opposed to the "Write once, run anywhere" approach advocated by other frameworks, like PhoneGap. The paradigm employed by React Native allows it to use native iOS components, and bring about changes to the UI through a JavaScript thread running in the background. In theory, this means the experience should feel native and appear very smooth, even though it's powered by JavaScript. And I was about to find out whether that is true in practice.

I downloaded a copy, followed the instructions for creating an app, and within minutes after learning about the launch, I had my first React Native iOS app running.

If the rest of the process were to be as easy as the start, I was in for a grand time. And React Native did not disappoint.

The first screen

I set out to build a simple app for learning simple Chinese phrases, a very basic spaced-repitition flashcard app. Using Sketch, I quickly came up with what I wanted the study screen to look like:

With only that in hand, I started assembling components in React. First, the card:

var Card = React.createClass({
  render: function() {
    var card = this.props.card;

    return (
      <View style={styles.card}>
        <Text numberOfLines={2} ref="definition" style={styles.definition}>{card.definition}</Text>
        <Text numberOfLines={1} style={styles.chinese}>{this.props.simplified ? card.simplified : card.traditional}</Text>
        <Text ref="pinyin" numberOfLines={1} style={styles.pinyin}>{card.pinyin}</Text>
      </View>
    );
  },
});

I had never worked with flexbox before, but I found these tutorials particularly useful. React Native's flexbox implementation departs from the browser-equivalent in some small ways:

The shorthand form, e.g. flex: 1 100%, is not valid in React Native. Instead, specify the properties separately: flex: 1; width: 100%. Flex values can be integers or doubles (0, 0.3, 1.0 etc), indicating the relative size of the box. So, if you have multiple elements they will fill the relative proportion of the view based on their flex value. If you had two views, one with flex 0.25 and the other with flex 0.75, it would split into quarters. Or you could also get an identical effect using flex 25 and flex 75.
Item-based styling is limited: flex-basis, flex-shrink and flex-grow are not available. I hope this will change in the future, but as of now the workaround is to use container properties to achieve the same effects.

For the card, this is what my styles looked like at first:

  card: {
    flexDirection: 'column',
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: 'white',
    shadowColor: "black",
    shadowOpacity: 0.3,
    shadowRadius: 3,
    shadowOffset: {
      height: 0,
      width: 0
    },
    width: 290,
    height: 290,
  },
  definition: {
    fontSize: 30,
    textAlign: 'center',
  },
  chinese: {
    flex: 1,
    fontSize: 80,
  },
  pinyin: {
    flex: 1,
    fontSize: 40,
  },

No big surprises there.

There is a bug in the current version of React Native that causes shadows to not work on iPhone 5 and up, but hopefully that will be fixed soon. I might even take a stab at it myself.

The rest of the items on the screen were similarly created; buttons, progress bar, all were simple React components drawn onto the screen and styled by flexbox. If you are somewhat familiar with React.js, this should prove to be very easy.

Adding a ListView

With the study screen cleared, I decided to move on to adding a ListView, for choosing which deck of cards you would like to study. I didn't even design this in Sketch, I had a look at the Movies example to see how they did it there, and used a similar approach.

The important part is the render function, which returns something that looks like this:

return (
      <View style={{flex: 1, flexDirection: 'column'}}>
          {header}
          <ListView
            ref="listview"
            dataSource={this.state.dataSource}
            renderFooter={this.renderFooter}
            renderRow={this.renderRow}
            onEndReached={this.onEndReached}
            automaticallyAdjustContentInsets={false}
            keyboardDismissMode="onDrag"
            keyboardShouldPersistTaps={true}
            showsVerticalScrollIndicator={true}
            style={styles.list}
          />
      </View>
    );

Notice the this.renderRow and other functions. These I had to implement, but it was as easy as creating elements on the study screen. Here is what the renderRow method looks like:

  renderRow: function(deck: Object)  {
    return (
      <DeckCell
        onSelect={() => this.selectDeck(deck)}
        deck={deck}
      />
    );
  },

DeckCell is a simple component I defined to display the deck's title and the progress percentage, like this:

Upon selecting the DeckCell row, we call this.selectDeck(deck), which looks like this:

  selectDeck: function(deck){
    // onPress is what we do when the deck is selected. We bind it to the current scope.
    var onPress = function(){
        this.setState({loaded: false});
        DatabaseManager.loadDecks(this.loadDecks); // we will talk about this in a second
        DatabaseManager.loadProgress(this.loadProgress);
    }.bind(this);
    this.props.navigator.push({
      title: deck.title,
      component: StudyScreen, // the screen with the cards we created earlier
      passProps: {deck: deck, onPress: onPress},
    });
  }

With this in place, clicking on a deck in the list will load the study screen, sending it a deck object so that we know which deck is intended to be used. So far so good. The last step that remained was to hook up a database. This was the part I was really curious about!

Hooking up a database

After clearing the first hurdle of drawing some items onto the screen and setting up a ListView with dummy objects, my attention turned to hooking up a database and having it communicate with React Native. I noticed that there is an AsyncStorage class, but this is intended for simple key-value storage (like LocalStorage on the web). I needed to do some heavy lifting, so I turned to my trusty friend, SQLite. The question was just, how do I hook SQLite up to the React app? I already alluded to the answer in the previous code snippet.

I made use of the RCTBridgeModule interface described in the React Native docs. First, this meant defining a DatabaseManager.h header file:

#ifndef ReactCards_DatabaseManager_h
#define ReactCards_DatabaseManager_h

#import "RCTBridgeModule.h"
#import "DBManager.h"

@interface DatabaseManager : NSObject <RCTBridgeModule>
@property (nonatomic, strong) DBManager *dbManager;
@end

#endif

Next, I implemented an initialization function to load up the SQLite database and save the connection as an instance variable. The SQLite-specific code was kept in another library, SQLiteManager, which could easily be replaced with a wrapper for Core Data or Realm.


#import <Foundation/Foundation.h>
#import "SQLiteManager.h"
#import "RCTLog.h"
#import "SuperMemo.h"

@implementation DatabaseManager

- (id)init {
    return [self initWithDB:@"collections.db"];
}

- (id)initWithDB:(NSString*)databaseName
{
    self = [super init];
    if (self) {
        self.dbManager = [[SQLiteManager alloc] initWithDatabaseFilename:databaseName];
    }
    return self;
}

Now, I could define a loadDecks method that takes a callback function, and export it to the JavaScript code by putting a line at the top of the file

RCT_EXPORT_MODULE();

and adding a call to ~~RCT_EXPORT(); on the first line~~ the RCT_EXPORT_METHOD macro (RCT_EXPORT is now deprecated in favor of RCT_EXPORT_METHOD):


RCT_EXPORT_METHOD(loadDecks:(RCTResponseSenderBlock)callback
{    
    // returns an array of NSDictionary objects, with fields id, title, count and percentage
    NSArray *decks = [self.dbManager loadDecks];

    callback(@[[NSNull null], decks]);
}

I didn't expect this to work at all, but I'd gone this far, so there was no turning back. In the JavaScript code, I added lines to first import the DataManager class, and then call the loadDecks function, giving it a callback function the logs the result.

var DatabaseManager = require('NativeModules').DatabaseManager;
...
DatabaseManager.loadDecks(this.loadDecks);
...
loadDecks: function(error, decks){
  if (error) {
    console.error(error);
  } else {
    console.log(decks);
  }
}

To my own astonishment, it worked! On first try! In the logs, I could see:

RCTJSLog> [{"title":"Descriptions","id":"1","count":"0","percentage":"0"},{"title":"Phrases","id":"2","count":"0","percentage":"0"},{"title":"Time","id":"3","count":"0","percentage":"0"},{"title":"Actions","id":"4","count":"0","percentage":"0"}]

I now had all the basic components necessary to make a React Native app backed by a SQLite database. It was plain sailing up to this point, and it was plain sailing from there on out. React Native is awesome.

Submitting the app

I spent some free hours here and there over the next couple of days to finish the app and bring all the parts together. There were no big surprises, and that's a good thing.

But before I could submit my app to the app store, I needed to turn off developer mode and enable performance optimizations. It took me some digging to find out how to do this, but this turned out to be quite easy, once you know how. First, inside the project AppDelegate.m, uncomment the line below the OPTION 2 comment:

jsCodeLocation = [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];

This causes the app to load from pre-bundled file on disk. Next, with the development server running (started with npm start), you can curl the URL in the comment, adding an extra dev query parameter:

curl http://localhost:8081/index.ios.bundle\?dev\=0 -o main.jsbundle

The dev query parameter may be set to either 0 or false (or similarly, 1 and true). When you next build the app, the log should indicate that development mode is now turned off and performance optimizations are turned on:

RCTJSLog> "Running application "HSK1 Chinese" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === false, development-level warning are OFF, performance optimizations are ON"

With this out of the way, I could build an archive and submit it to the app store. Again, easy as pie.

I had some friends beta test the app on different platforms through TestFlight, and all seemed well. And today, one week after the launch of React Native, I submitted the app to be reviewed for the App Store. Wish me luck!

Closing remarks

As a web application developer that was already somewhat familiar with both React.js and iOS, React Native was a total breeze to work with. The things I did not know before I started were easy to learn, thanks to these attributes of React Native:

Error messages are clear and descriptive. I can't stress the importance of this enough. The React Native error messages would point to specific lines in the JavaScript code, describe the problem exactly, and sometimes even suggest ways to fix it. Once, I did something stupid (I forget what exactly), and it even warned me that what I was doing is an anti-pattern, and should be avoided. Amazing.
Instant reload with Cmd+R. Yup, no need to compile again and again, wasting precious minutes and breaking your concentration. With React Native you can press Cmd+R, and the simulator immediately reloads. This is a huge boon for development.
No more storyboards. Storyboards are great, but they have their downsides. For one, they don't play well with version control systems like Git. For another, I never really liked dragging lines from UI components to lines in the code to indicate a relationship, only to later accidentally remove that line and be faced with an incomprehensible error message. By allowing UIs to be designed with something similar to HTML+CSS, building these just got a whole lot easier and less painful.
It's smoooothhh. Even on my iPhone 4S, the app runs as smooth as the flight of a dream. By running JavaScript in a background thread that doesn't cause the UI to hang, React Native delivers on its promise to make coding iOS apps as easy as writing JavaScript, without the performance problems associated with running it in a WebView. It totally feels just like a native app.

React Native is truly one of the most exciting developments in technology I have seen in a long time, and the wait was worth it. +1, will use again.

~~PS If you'd like to check out the app, it's on the app store right now for $0.99. Or if HSK1 is too easy for you, you can sign up to be notified when other levels become available.~~ Update: Since this was published years ago, iOS introduced some breaking changes that wasn't worthwhile for me to address, and I decided to take the app down. It was fun working on this, thanks for all your support and feedback over the years!

Thanks to Spencer Ahrens from the React Native core team for corrections to this post.

Aquileo | Excellent Open Source Go Projects

2015-01-26T00:00:00+00:00

Something I often hear new Go developers say is that they are looking for some good projects to study, learn from and contribute to. Normally I suggest reading the Go source: it's easy to read, you can pick a part you are interested in, and is probably bound to be the best example of idiomatic Go. But this past weekend presented itself with an opportunity to find more open source Go projects that are of the highest quality.

I participated in Gopher Gala, a 48 hour-long worldwide hackathon for Go. Our team built a project called Go Report Card, and it aims to rate the quality of any open source Go project on Github. The tool uses various other Go tools: gofmt -s to judge basic formatting, go vet to check for suspicious constructs, gocyclo to measure the cyclomatic complexity of the code, and so on. It then averages these results to get the final grade.

My teammate Shawn Smith and I have been hitting all of the most popular Go repos on Github, and saving the results to a Mongo database. Right now, we have checked 276 of the most popular Go repositories on Github. In order to find the projects of highest quality, I selected the ones with at least 100 Go files, and ordered them by their rating. Here are the results:

Rank	Name	Github Repo	Go Files	Score
1	go-github	google/go-github	107	97.1%
2	Cockroach	cockroachdb/cockroach	204	89.5%
3	golang/net	golang/net	243	87.6%
4	xGo	exercism/xgo	142	86.2%
5	Kubernetes	GoogleCloudPlatform/kubernetes	636	83.6%
6	syncthing	syncthing/syncthing	146	83.0%
7	Packer	mitchellh/packer	656	82.8%
8	Drone	drone/drone	189	82.5%
9	etcd	coreos/etcd	211	82.3%
10	Docker	docker/docker	881	81.4%
11	GoLearn	sjwhitworth/golearn	111	80.8%
12	NSQ	bitly/nsq	116	80.8%
13	GoConvey	smartystreets/goconvey	160	79.5%
14	golang/tools	golang/tools	452	79.2%
15	Fleet	coreos/fleet	151	79.1%
16	LimeText	limetext/lime	150	79.0%
17	Flynn	flynn/flynn	229	78.4%
18	godropbox	dropbox/godropbox	157	78.1%
19	consul	hashicorp/consul	182	77.4%
20	terraform	hashicorp/terraform	454	74.2%

A lot of these are indeed fantastic projects. And if you are looking for a smaller project to start with, here are the highest-rated open source repos with at most 100 Go files:

Rank	Name	Github Repo	Go Files	Score
1	httplogger	ernesto-jimenez/httplogger	2	100.0%
2	Google Analytics Beacon Analytics	igrigorik/ga-beacon	1	99.6%
3	s3cache	sourcegraph/s3cache	1	99.4%
4	watchreadlisten	shawnps/watchreadlisten	1	99.3%
5	go-loggly	segmentio/go-loggly	1	99.3%
6	Exercism CLI	exercism/cli	27	99.0%
7	TextQL	dinedal/textql	1	98.7%
8	exercism/arkov	exercism/arkov	9	97.2%
9	go-prompt	segmentio/go-prompt	6	95.8%
10	SSCC	pblaszczyk/sscc	14	94.64%
11	mewmew/playground	mewmew/playground	96	91.9%
12	go-stats	segmentio/go-stats	3	91.6%
13	localtunnel	progrium/localtunnel	3	91.6%
14	freegeoip	fiorix/freegeoip	9	91.6%
15	negroni	codegangsta/negroni	11	90.9%
16	MAST	ikawaha/mast	27	90.7%
17	martini	go-martini/martini	16	90.6%
18	Bolt	boltdb/bolt	42	90.4%
19	LLVM	mewlang/llvm	21	90.4%
20	notify	rjeczalik/notify	41	90.2%

If Go Report Card is to believed, any of these projects a great place to start learning high-quality, idiomatic Go!

To see how your own open source repo measures up, you can try it out on goreportcard. For example, this is what the output looks like for our hackathon project:

Goreportcard is free and open source, you are welcome to check out the Github repo and run checks for your own repo.

Aquileo | Solving Regex Crosswords using Go

2014-12-13T00:00:00+00:00

I first discovered regular expression crosswords two weeks ago, when RegexCrossword.com appeared on the Hacker News front page. I thoroughly enjoyed the nerdy 30 minutes I spent doing the puzzles, but soon enough my natural inclination towards making computers do my hard work got the better of me: I wanted to solve this with code. This morning I had some free time and decided to give it a shot. It was perhaps even more fun, and definitely more exciting, than solving the puzzles by hand!

The end result is about 150 lines of Go code that solves most puzzles in only a few milliseconds. By showing you how I solved it, I hope you'll learn some interesting things about solving puzzles programatically, how regular expressions work and specifically, how they work in Go. Let's dive in.

The algorithm

My first instinct was to solve this with brute force, by iterating over every possible answer to the puzzle, until a solution is found. This would work fine for small puzzles, like when the grid is 2x2. The solutions always use upper case characters, but they may also contain numbers and punctuation. So if we consider those 62 ASCII characters at every cell, the number of possible answers would be 62^4 for the 2x2 grid. At 14,776,336, that's still a manageable search space for a brute force solution. But let's make the grid 4x4, what then? Then we have 62^16, which is around 4.76x10²⁸. Not so manageable anymore!

Then I thought about the strategy I use when solving these puzzles as a human. For every cell, I check what characters might satisfy the regular expressions for that cell. I then guess one of the options, and continue with the assumption that it's correct. I do this until I find a contradiction, in which case I would go revisit my assumptions. It seems like this strategy of making assumptions and then backtracking when contradictions are found would work well as an algorithm, but there's a snag: regular expression libraries don't normally offer a way to tell whether the expression is matched only at a specific position. You either have to match the entire string, or nothing.

It would therefore be great if we had a function that could validate, for any given cell, whether a character could possibly satisfy the regular expression at that position. Let's call this function satisfiesAtPos. It takes a regular expression expr, a character r and a position pos, and tells us whether the character is a possible match for this regular expression at position pos. For example, if we had this simple puzzle:

then the first cell (in the left-hand upper corner) would be satisfied by H, L, or O based on the horizontal regex HE|LL|O+, so satisfiesAtPos should return true for these characters. Anything that's not in the set {S,P,E,A,K} would satisfy vertical regex [^SPEAK] at position 0, so satisfiesAtPos would return false for {S,P,E,A,K}, and true for all other characters. This means only H will have satisfiesAtPos return true for both regexes at position 0. We can continue in this fashion for every cell, until we reach the end of a row or column, where we should then validate our assumptions for the independent cells. If the row or column doesn't match the regular expression, we backtrack and try other options for the cells where there is more than one possibility.

Regular Expressions and Go

We have an algorithm! Now we just need to figure out how to write the function satisfiesAtPos. In Go, it's frighteningly easy if you understand some regular expression theory and have the patience to scratch around in the source code. For understanding regular expression theory, this article by Russ Cox is an excellent introduction on the subject. And since the author is also one of the core contributors to Go, the algorithm described in this article is also the one implemented in the Go regexp package. Convenient!

I'm not going to re-iterate everything said in that article, and I highly recommend reading it. But as long as you know that regular expressions can be expressed as state machines, you should be able to follow the rest of this discussion.

Normally when you use regular expressions in Go, you call the regexp package. Specifically, you might call regexp.Compile, like this:

re, err := regexp.Compile(`HE|LL|O+`)

which gives you re, a *Regexp you can use to call Match, Find, or Replace. But what does Go do internally to get you that Regexp struct? It's very interesting.

When you call regexp.Compile, a number of things happen:

first, syntax.Parse gets called. This parses a regular expression string s, controlled by the specified flags, and returns a regular expression parse tree. Next,
the regular expression gets simplified by calling Simplify, which returns a regexp equivalent to the given one but without counted repetitions and with various other simplifications, such as rewriting /(?:a+)+/ to /a+/. And last,
syntax.Compile compiles the regexp into a program that can be executed. This step returns a syntax.Prog, which is a state machine, and it's what gets used to run match checks. It has a String() method that spits out its internals in human-readable format, and this is really useful in understanding regular expressions in Go.

Here's a simple program that performs the steps described above, and prints out the resulting program (state machine):

package main

import (
	"fmt"
	"regexp/syntax"
)

var flags = syntax.MatchNL | syntax.PerlX | syntax.UnicodeGroups

func main() {
	re, err := syntax.Parse("(NA|FE|HE)[CV]", flags)
	if err != nil {
		panic(err)
	}

	re = re.Simplify()
	prog, err := syntax.Compile(re)
	if err != nil {
		panic(err)
	}
	fmt.Println(prog)
}

(Go Playground)

Running this gives us the following output:

  0	fail
  1*	cap 2 -> 9
  2	rune1 "N" -> 3
  3	rune1 "A" -> 10
  4	rune1 "F" -> 5
  5	rune1 "E" -> 10
  6	alt -> 2, 4
  7	rune1 "H" -> 8
  8	rune1 "E" -> 10
  9	alt -> 6, 7
 10	cap 3 -> 11
 11	rune "CCVV" -> 12
 12	match

This may seem cryptic at first, but it's actually not hard to understand. The output describes a state machine. The first number on each line is the ID of the node. The next word describes the type of node. It could be cap, which is short for capture, and corresponds to the start and end of match groups in the regex. rune1 describes a node that exactly matches a specific rune. alt describes a node that merely exists to create a fork in the road: one path leads to the first argument, and the other to the second argument. And so on for different types of nodes. Every node has an output, described by the final number, which tells us the ID of the next node after this one. All in all, the above gives us a state machine diagram that looks more or less like this:

You'll notice that I annotated the above state diagram with three steps. What are they? They are what we need to solve our initial problem: determinining whether a given character can be a solution to the regex at a particular step. If we want to know whether 'N' satisfies the regular expression at position zero, we check whether 'N' is a possible match at step one. If it is, satisfiesAtPos should return true, otherwise false. The problem is almost solved.

I conveniently structured the state machine diagram so that rune matches fall on the same step for every position in the string. How do we do this in code? We can build up a list of runes at a particular step by stepping through the state machine, starting at the starting node. We start with a queue containing only the starting node, and we iterate until the queue is empty. If the next node in the queue is a rune node, we add it to our list of nodes at this step. If the node is not a rune, but rather an alt (alternative, or fork in the road) or cap (capture), we add this node's output nodes to the queue. Ideally, the queue should be a set, so that we can't add the same node to it twice. And that's how it's done; we can now complete our satisfiesAtPos function. In Go code, it looks like this:

func satisfiesAtPos(expr string, r rune, pos int) bool {
	re, err := syntax.Parse(expr, flags)
	if err != nil {
		panic(err)
	}

	re = re.Simplify()
	prog, err := syntax.Compile(re)
	if err != nil {
		panic(err)
	}

	var el int
	s := 0                          // current step
	step := []int{}                 // states in this step
	queue := set([]int{prog.Start}) // queue of states to check

	for s <= pos {
		for len(queue) > 0 {
			el, queue = queue[0], queue[1:]
			inst := prog.Inst[el]
			switch inst.Op {
			case syntax.InstAlt:
				// alternative, so add both nodes to queue
				queue.Add(int(inst.Out))
				queue.Add(int(inst.Arg))
			case syntax.InstCapture:
				// capture group, just add next node to queue
				queue.Add(int(inst.Out))
			case syntax.InstRune, syntax.InstRune1, syntax.InstRuneAny:
				// rune, add instance to step
				step = append(step, el)
			}
		}
             
                // range over the nodes we found in this step
		for i := range step {
			inst := prog.Inst[step[i]]
			if s == pos && inst.MatchRune(r) {
                                // if this is the step we want and 
                                // the rune matches, return true
				return true
			}
			// add rune's out to queue
			queue = append(queue, int(inst.Out))
		}
		step = []int{}
		s++
	}

	return false
}

Putting it all together

Now that we have a working satisfiesAtPos function, the rest is relatively easy. For every cell, we guess a character and call satisfiesAtPos for both the horizontal and vertical regular expression. If the character satisfies both regexes, we go on to the next cell. If not, we guess the next character, and repeat the process. At the end of a row, we validate the row's regular expression, and if it doesn't match, we backtrack and keep making different guesses until it does. We also do the same for the columns. Even though we are still iterating over possible answers, we quickly find out when an answer cannot lead to a correct solution, and stop the search in its tracks. This reduces the search space considerably.

If you are interested in the code for this function, feel free to check out the Github repo.

Caveats

If you read the article by Russ Cox I recommended earlier, you might have noticed the section on backreferences. Specifically, how they cannot be implemented in the way described in the article. This is why Go does not support regular expressions with backreferences at the moment. A "particularly clever" solution might one day combine the two algorithms so that the fast Thompson NFA is used when backreferences are not present, and only bring out backtracking when needed. Unfortunately, this also means that my current solution for regex crosswords, though simple, short and reasonably efficient, does not support backreferences. I'm still thinking of ways to remedy this without making the code horribly complicated. Let me know if you have any ideas!

We also technically don't need to build the program every time inside the satisfiesAtPos function. A simple, but effective, optimization would be to build the program only once, and then compile the steps only once. This will surely make the solution much faster, but so far, for all the puzzles I tried, solutions were found in reasonable time, mostly within a few milliseconds.

I have also not yet gotten around to adding support for puzzles with regular expressions on all four sides. I see no reason for it to be difficult, though.

Grab the code

The code is available on Github. It is not hard to hook up Selenium (or something similar), but let me not encourage such anti-social behavior :) Have fun!

Aquileo | Running the Go Race Detector with -cover

2014-05-19T00:00:00+00:00

There are two test options that make testing in Go especially powerful: one is -cover, which generates test coverage reports, and the other is -race, which warns of possible race conditions in your code. If you haven't used them yet, you should. They are very useful tools, and both are covered well (so to speak) by official blog posts: The cover story and Introducing the Race Detector.

A subtle problem arises, however, when you use these two together. Suppose we have this simple function that adds one a hundred times inside separate goroutines and returns the result of this summation:

package coverrace

func add100() int {
	total := 0
	c := make(chan int, 1)
	for i := 0; i < 100; i++ {
		go func(chan int) {
			c <- 1
		}(c)
	}
	for u := 0; u < 100; u++ {
		total += <-c
	}
	return total
}

We can place the function in a file called coverrace.go, and write a test for it in coverrace_test.go. The test might look like this:

package coverrace

import "testing"

func TestCoverRace(t *testing.T) {
	got := add100()
	if got != 100 {
		t.Errorf("got %d, want %d", got, 100)
	}
}

It just asserts that we get a 100 when calling the function, and raises an error if we don't. So far so good, let's run the test:

$ go test
PASS
ok  	github.com/hermanschaaf/coverrace	0.005s

Test passed! Nice. Let's check out our coverage:

$ go test -cover
PASS
coverage: 100.0% of statements
ok  	github.com/hermanschaaf/coverrace	0.005s

100% test coverage, not bad. Now let's use the race detector to make sure we didn't make any silly mistakes:

$ go test -race
PASS
ok  	github.com/hermanschaaf/coverrace	1.053s

The test took a wee bit longer to run this time, but it looks like our implementation is OK as far as race conditions are concerned. Time to put it all together and get ready for uploading this to production! Let's just run everything one more time to be sure:

$ go test -race -cover
==================
WARNING: DATA RACE
Write by goroutine 5:
  github.com/hermanschaaf/coverrace.func·001()
      github.com/hermanschaaf/coverrace/_test/coverrace.go:10 +0x45

Previous write by goroutine 4:
  github.com/hermanschaaf/coverrace.func·001()
      github.com/hermanschaaf/coverrace/_test/coverrace.go:10 +0x45
...
==================
PASS
coverage: 100.0% of statements
Found 1 data race(s)
exit status 66
FAIL	github.com/hermanschaaf/coverrace	1.059s

Wait, what just happened? The code remained the same, but now we have a race condition! How is this possible?

The tests are actually running on a copy of the source code, made by the cover tool to insert counting lines in code blocks. We can see this from the fact that the test errors are coming from a _test folder that we didn't create. The code, after adding the coverage lines, looks like this:

package test

func add100() int {
	GoCover.Count[0] = 1
	total := 0
	c := make(chan int, 1)
	for i := 0; i < 100; i++ {
		GoCover.Count[3] = 1
		go func(chan int) {
			GoCover.Count[4] = 1
			c <- 1
		}(c)
	}
	GoCover.Count[1] = 1
	for u := 0; u < 100; u++ {
		GoCover.Count[5] = 1
		total += <-c
	}
	GoCover.Count[2] = 1
	return total
}

So cover added some extra lines to check off when any specific block of code is reached. It might be a bit old-school, but it works just fine. The only problem is that it is also setting a global variable inside a goroutine (GoCover.Count[4] = 1), and the race detector doesn't like that at all. What can we do if we want to run both cover and race detector at the same time?

Luckily for us, there is a simple solution to this problem: we can run the tests using the special -covermode=atomic flag, like this:

go test -race -covermode=atomic

Doing this, the generated code uses the sync/atomic package instead of setting a global variable, and it looks like this:

import _cover_atomic_ "sync/atomic"

func add100() int {
	_cover_atomic_.AddUint32(&GoCover.Count[0], 1)
	total := 0
	c := make(chan int, 1)
	for i := 0; i < 100; i++ {
		_cover_atomic_.AddUint32(&GoCover.Count[3], 1)
		go func(chan int) {
			_cover_atomic_.AddUint32(&GoCover.Count[4], 1)
			c <- 1
		}(c)
	}
	_cover_atomic_.AddUint32(&GoCover.Count[1], 1)
	for u := 0; u < 100; u++ {
		_cover_atomic_.AddUint32(&GoCover.Count[5], 1)
		total += <-c
	}
	_cover_atomic_.AddUint32(&GoCover.Count[2], 1)
	return total
}

var _ = _cover_atomic_.AddUint32

, which is safe from race conditions, as shown by the new output of running the tests with this flag:

$ go test -race -covermode=atomic
PASS
coverage: 100.0% of statements
ok  	github.com/hermanschaaf/coverrace	1.055s

Crisis averted!

Protip: when running go test with both -cover and -race, also add the -covermode=atomic flag - it might just save you an hour or two of unnecessary race condition-hunting.

If you'd like to play with the source code of this post, it's on Github.

Update: Good news, everyone! @shawnps pointed out that from Go 1.3 the atomic mode will be enabled by default when -cover is run with -race, so this will not be an issue for much longer :)

Aquileo | Efficient String Concatenation in Go

2014-05-03T00:00:00+00:00

In this article I investigate the computational performance of various string concatenation methods in the Go programming language.

To evaluate the options, I prepared some typical Go benchmarks using the Go testing package. A benchmark looks something like this:

func BenchmarkBufferString(b *testing.B, numConcat int) {
	var ns string
	for i := 0; i < b.N; i++ {
		next := nextString()
		buffer := bytes.NewBufferString("")
		for u := 0; u < numConcat; u++ {
			buffer.WriteString(next())
		}
		ns = buffer.String()
	}
	global = ns
}

For the purposes of these benchmarks, I imagined having a process that returns string segments one by one, and these segments need to be concatenated to form one string. To represent such a process, I created a simple iterator that returns the string version of its current index on each call:

// nextString is an iterator we use to represent a process
// that returns strings that we want to concatenate in order.
func nextString() func() string {
	n := 0
	// closure captures variable n
	return func() string {
		n += 1
		return strconv.Itoa(n)
	}
}

Every method we evaluate will call this function in a loop so that the fully concatenated string looks something like 0123456789101112131415.... There is function call overhead to take into account in this, but since all the benchmarks will have the same overhead, the comparison is still fair. Now that we have the basic setup for the benchmark, let's see what the methods are we'll be evaluating.

Method 1: Naive Appending with +=

This is the most obvious approach to the problem. Use the concatenate operator (+=) to append each segment to the string. The thing to know about this is that strings are immutable in Go - each time a string is assigned to a variable a new address is assigned in memory to represent the new value. This is different from languages like C++ and BASIC, where a string variable can be modified in place. In Go, each time you append to the end of a string, it must create a new string and copy the contents of both the existing string and the appended string into it. As the strings you are manipulating become large this process becomes increasingly slow. In fact, this method of naive appending is O(N²).

Method 2: strings.Join

The Go strings standard library package provides a Join function that takes a slice of strings and concatenates them. In our case, this requires first building a slice of strings and then calling the function on the slice. Building a slice takes time if you don't already have one, and we therefore count this as part of the time taken to perform the concatenation in our benchmarks. The final concatenation will be O(N), but building the slice is O(N) (average) and uses O(N) memory.

Here is an example of using strings.Join:

s := []string{}
for i := 0; i < 1000; i++ {
	s = append(s, "a")
}
fmt.Println(strings.Join(s, ""))

See full code on the Go Playground

Method 3: bytes.Buffer

The last method we'll be evaluating is using the Buffer type from the bytes package. bytes.Buffer implements io.Writer, and can concatenate strings in O(N) time without requiring us to build a new slice.

Here is an example of using bytes.Buffer:

var buffer bytes.Buffer
for i := 0; i < 1000; i++ {
	buffer.WriteString("a")
}
fmt.Println(buffer.String())

See full code on the Go Playground

Now that we've defined the methods we want to test, let's proceed to run the benchmarks. I'd like to skip right to the end and start with the winning approach. Then we'll work back to see how and when this method is best.

And the Winner Is...

Method #3 (bytes.Buffer) is the winner! But not by far, and not in all cases. Here is a graph of how the methods compare in the case with a 10000 strings with a total size of 37kB (small strings of <= 5 characters):

It shows how bytes.Buffer is the winner by quite a large margin in this case. Let's see how the methods compare when the strings are a bit longer, at a total size of 244kB (25 characters each):

With longer strings strings.Join doesn't perform so badly, but it's still not as good as using bytes.Buffer.

I also ran benchmarks on small numbers of concatenations, and in that case naive concatenation gets the job done slightly faster than the other methods, so it's still fine to use for small numbers of concatenations and small segments.

Lastly, how big of a factor does building a string slice play in Method #2? We can exclude slice building from the strings.Join benchmark, but make it still call nextString on every iteration so that the tests remain fair. In this case, the results look like this:

When we don't count the time it takes to build a string slice, strings.Join edges out bytes.Buffer and rules supreme.

In Summary

In summary, for very few concatenations of short strings (fewer than hundred, length shorter than 10), using Method #1, naive string appending, is just fine and can actually perform slightly better. For more heavy-duty cases where efficiency is important, Method #3, bytes.Buffer is the best choice out of the methods evaluated. That said, strings.Join is a good choice when you already have a string slice that just needs to be concatenated into one string.

Get the Code

Below are the raw results of running go test -bench. for the different methods and different number of concatenations on my machine (Go 1.2 on Ubuntu 64bit, Intel® Core™ i7-3667U CPU @ 2.00GHz):

BenchmarkNaiveConcat10	  500000	      6403 ns/op
BenchmarkNaiveConcat100	   20000	     77001 ns/op
BenchmarkNaiveConcat1000	     500	   3105361 ns/op
BenchmarkNaiveConcat10000	       5	 236872134 ns/op
BenchmarkJoin10	  200000	      8129 ns/op
BenchmarkJoin100	   50000	     51891 ns/op
BenchmarkJoin1000	    5000	    465179 ns/op
BenchmarkJoin10000	     500	   5911317 ns/op
BenchmarkBufferString10	  200000	      7688 ns/op
BenchmarkBufferString100	   50000	     45027 ns/op
BenchmarkBufferString1000	    5000	    398311 ns/op
BenchmarkBufferString10000	     500	   3702906 ns/op

You can play around with the benchmarks, run them yourself and check my implementation on Github. A typical benchmark looks like this:

var global string

// benchmarkNaiveConcat provides a benchmark for basic built-in
// Go string concatenation. Because strings are immutable in Go,
// it performs the worst of the tested methods. The time taken to
// set up the array that is appended is not counted towards the
// time for naive concatenation.
func benchmarkNaiveConcat(b *testing.B, numConcat int) {
	var ns string
	for i := 0; i < b.N; i++ {
		next := nextString()
		ns = ""
		for u := 0; u < numConcat; u++ {
			ns += next()
		}
	}
	// we assign to a global variable to make sure compiler
	// or runtime optimizations don't skip over the operations
	// we were benchmarking. This might be unnecessary, but it's
	// safer.
	global = ns
}

Aquileo | Why is Golang popular in China?

2014-04-16T00:00:00+00:00

Earlier this week I wrote a post titled The Popularity of Go. The post itself turned out to be quite popular, and I received a lot of great feedback from the Go community (thanks!). One thing I brought up in the post, and that a lot of folks commented on, was the apparent popularity of Go in China according to Google Trends. The graph above shows the searches for "golang" by country on Google Trends. Impressive, right? So many more searches for "golang" in China than anywhere else in the world. Like many others, I too wanted to know why. I'm not much of an investigative journalist, but I decided to do some of my own digging anyway. Is Go really that popular in China, or are we seeing skewed data? And if the data is skewed, why, and how much?

One redditer suggested that, perhaps, "golang" is in fact a word in a dialect of Chinese. Being able to speak and read Mandarin Chinese myself, I was intrigued by this idea - it seemed plausible, at least. So I hopped onto Baidu.com, and did a search for "golang" (Baidu is, for those of you who don't know, by far the most popular search engine in China). The first one hundred results all related to the Go programming language in some way. So perhaps it doesn't have a different meaning in China after all.

But we don't need to rely on anecdotal search results for evidence, we can confirm that Chinese searchers genuinely are interested in Go, the programming language, by seeing what percentage of visits to golang.org are reported to be from China on Alexa.com. This is what we find:

The US weighs in at 18.9% of the total visitors to golang.org, with China coming a reasonably close second, at 12.1%. This is already enlightening: the Google Trends graph made it look like the US interest in "golang" was nowhere close to that of China, but here we see that more visits to the main Go-related website come from the US than from China.

But wait a minute. Is golang.org really the main Go-related website in China? Is it even available in the Chinese language? Whoops, doesn't look like it. Even on Baidu it's the only English result on the page:

This makes the argument much weaker: maybe Chinese gophers are using a reference site in their native tongue, not golang.org, and that would explain why golang.org shows a smaller percentage of Chinese users. Sounds reasonable. So let's dig deeper, and find out where Chinese gophers do hang out.

There are a couple of popular Chinese sites related to Go. The first is studygolang.com. Another is Golang中国. Another is golang.usr.cc. I'm sure there are more, but as far as I can see those are the most prominent sites that are only about Go, and not about programming in general. Let's see how these stack up in terms of rankings on Alexa, and how they compare to golang.org, as of this writing:

Site	Rank in China
studygolang.com	6,928
golang.org	14,932
golangtc.com	17,606
golang.usr.cc	51,897

So studygolang.com seems to be the clear leader in terms of visitors, and is even more popular than golang.org, as we suspected some site might be.

Now that we know which sites are popular in China, can we use this information to glean something about how popular Go is there in general, compared to the rest of the world? I think we can. Below are tables containing the most popular keywords to find the different Go-related websites. See if you can spot the odd one out:

If you look at the top search term for each site, you'll notice that golang.org gets disproportionately many of its search visitors from the keword "Go" (74.30%), whereas the other popular sites in China have as their top keyword "Golang", some as their most popular term by far and others only by a little bit (13.29%, 80.67% and 12.12%), but with the term "Go" never featuring for any of the Chinese sites. golang.org gets ~25 times more visitors from the search term "go" than it does from the term "golang". It is therefore reasonable to estimate that when we were looking at the Google Trends graph for "golang", we were really seeing only about 4% of the full picture. At the same time, Chinese sites, for whatever reason, get very few hits from "go", and most of their hits come from "golang". It is likely that Chinese users are using "golang" as a search term more often - even more often than other countries' users - and this in turn results in us seeing the Google Trends data showing China as the origin of the most searches for "golang".

So Is Go Popular in China or Not?

So now we have seen why, at least to some extent, there are more searches for "golang" in China than elsewhere. But we are yet to find out whether Go really is popular in China. Like everything else so far, this too is difficult to know for sure. But we can do some back-of-the-napkin math to see where the biggest online Go community lives: China or the US?

We saw earlier that 18.9% of golang.org's visitors come from the US, while 12.1% come from China. We also saw that golang.org is ranked 14,932th in China, and studygolang.com 6,928th. Assuming that a halving in rank constitutes a doubling in monthly visitors, we can guess, back-of-the-napkin-style, that studygolang.com receives about twice as many Chinese visitors as golang.org. That would translate to 24.2% of golang.org's total number of visitors that visit studygolang.com every month - more than the monthly number of US visitors to golang.org.

Now, there are so many assumptions being made here, both stated and unstated, that it would be most unwise to take any final numbers seriously. But it looks like the conclusion is nevertheless unavoidable: even conservatively, it is very likely that there are at least as many Go coders in China as there are in the US. Sure, China has a much bigger population too, but it's still a surprising result considering that the main Go site, golang.org, does not have a Chinese version available (yet).

So how did Chinese gophers hear about Go, and how did it spread so quickly in China? To be frank, I don't know. But I'd like to know, and they say that the quickest way to get to the correct answer on the Internet is not to ask a question, but to post an incorrect answer. In that spirit, I'll venture a guess.

A Chinese blogger called Liigo recently wrote an article on why he decided to abandon Go (text in Chinese). He specifically mentions why he, and other admirers like him, first showed interest in Go back in 2009: because it was "made by Google". It seems like that would be as a good a reason in China as anywhere else, but maybe it played a big role in the adoption of Go in China, as opposed to, say, Rust or Node.js. He also goes on to mention how he was initially excited to join the thriving Go community. We can only assume that he is referring to the core Go developers, but perhaps he is alluding to the thriving Go community in China as well.

Another popular post on Quora-like Chinese Q&A site zhihu.com asks "Why should I use Go?", and it has some interesting answers. It can be directly compiled into machine code, it's easy to learn, it has a simple concurrency model, is suitable for server programming, etc. Basically, all the reasons we know and love. But nothing that stands out as a particularly unique reason to China.

From the scarce evidence available, there is one conclusion to be drawn: Go is popular in China for the same reasons that it is popular in the US, with one extra strengthening factor being a high reverence in China for things made by Google. We can demonstrate this last point by looking at the popularity of other Google technologies in China. Here's Google App Engine's world map on Google Trends:

And here's the same graph for Node.js, for comparison:

Google App Engine is also way more popular in China than anywhere else, and the same does not go for Node.js, so we can discount population size distortion.

tl;dr? From an outsider's perspective, it seems like Google technologies are popular in China for no reason other than that they were made by Google. I'd be very happy to be shown wrong, or to hear from Chinese gophers themselves!

Update: Dave Cheney pointed out on Reddit that he is under the impression that Go is popular in China for its usefulness in writing programs for rooted Android phones. Very interesting point, and I tend to believe what Dave says about Go. Seems like it only took a couple of hours for me to be proven wrong on the Internet, and I'm happy about that. Any more theories (or better, proof) out there? Let me know! @ironzeb

Also on Reddit, zx9597446 pointed out that golang.org is often blocked by the Great Firewall, and that many Chinese gophers are forced to access resources through a proxy. There might be even more gophers in China than it seems!

Aquileo | The Popularity of Go

2014-04-14T00:00:00+00:00

When you look at the Google Trends graph above, it would seem like the Go programming language, also known as Golang, is on its way to big things. But let's not get ahead of ourselves, Go fans. Let's first have a cup of java to put things into perspective:

Golang's popularity as a search term might be growing faster than bamboo in springtime, but it's still dwarfed by the massive overgrowth that is the Java programming language. But interestingly, we can see in the graph how dramatically Java's popularity has fallen in recent years. Maybe it has something to do with the worrying decline in programming interest?

Hmm. Not sure what to make of that, considering my career choices. Anyway, while Go's popularity is on the rise, it's worth pondering whether it will ever grow to the heights that Java once enjoyed. It doesn't look likely to happen any time soon.

Another interesting tidbit is that Go is enjoying surprising popularity in China, as shown by the fact that most searches on Google related to Golang originate from there:

It makes at least some sense, since a few interesting Go libraries have come from Chinese developers, like beego and gorm.

What does Go's future have in store? It's hard to tell. But it sure is an exciting time to be involved.

Disclaimer: These trends are by nature wildly inaccurate. I share them as food for thought. Please don't use it for anything important. And if you do, it's on you :)

Aquileo | Rugby

2014-01-19T00:00:00+00:00

Rugby is a sport close to my heart. I have always enjoyed watching, playing and discussing this fast-paced game of grit, strategy and strength. I am, however, also an avid fan of computer science, and my upper body strength is not quite what it used to be. I believe that no topic, no matter how interesting, can not be made even more interesting through the use of math, science and algorithms, without any need for upper body strength. Indeed, I will prove that rugby is no exception to this rule.

For the uninitiated, in rugby, there are four types of scores: penalty goal (3 points), drop goal (3 points), try (5 points) and converted try (7 points). It is easy to show that from this, all points totals are possible, except for 1, 2 and 4. In this post, I’ll be answering a bunch of hypothetical questions that can be asked about these scores, and applying algorithms from computer science to do it as efficiently as possible.

To kick off, let’s find out what the minimum number of scoring opportunities a team needs to achieve a specific points total. For example, for a team to reach a score of 8, the minimum number of scoring opportunities they need is two, because they need one try and one penalty or drop goal, and there are no other ways to reach that points total.

We can tackle this problem with a dynamic programming approach. Dynamic programming is a technique by which optimal solutions are first found for smaller sub-problems, and a recurrence relationship then used to calculate the solution for the bigger problems. In this case, we can start by calculating the minimum number of scoring opportunities needed for smaller scores, and use these solutions to build up to bigger scores.

We have already noted that all totals are possible except 1, 2 and 4. We can therefore initialize some data with the minimum number of scoring opportunities needed for certain totals:

0 points: 0 opportunities needed
1 point: impossible
2 points: impossible
3 points: 1 scoring opportunity (drop kick or penalty kick)
4 points: impossible
5 points: 1 scoring opportunity (try)

We can now continue and note that for any total, the minimum number of opportunities must be equal to the minimum for a previous total, plus one extra scoring opportunity needed to reach this new total. For example, to reach 8, the minimum is one extra opportunity (a drop kick, 3 points) plus the minimum for achieving 8-3=5, which happens to be 1. The minimum for 8 is therefore 2. Being the particularly mathematically-inclined rugby enthusiasts that we are, we prefer things in equation form:

This is where you can see the recurrence relationship clearly; to calculate the solution for a new total points x, for every score s (either 3, 5 or 7), we check the previous minimum totals calculated at x-s and see which one is the minimum needed. If we were to now calculate the minimum for all totals from 1 up to n, we can create a table of minimum scoring opportunities needed in O(n) time and O(n) space. Here is this table up to 20 points:

Total Points	Minimum Scoring Opportunities
0	0
1	Impossible
2	Impossible
3	1
4	Impossible
5	1
6	2
7	1
8	2
9	3
10	2
11	3
12	2
13	3
14	2
15	3
16	4
17	3
18	4
19	3
20	4

Full table

Putting our algorithm in use, we can see that New Zealand needed a minimum of 21 scoring opportunities in their record-breaking game against Japan in the 1995 World Cup to reach their final points total of 145. This makes it all the more remarkable that they did, indeed, score 21 times, achieving maximum efficiency, something we programmers can surely appreciate (Simon Culhane managed to convert all but one of the 21 tries in that game).

Okay, that was fun! But we’re only warming up. In that silent moment huddling down for a scrum, have you ever wondered, for a given points total, what are all the possible ways was that the game could have played out? I know I have.

Let’s extend our algorithm a bit to answer that question, and find all scoring combinations to achieve any one total score. This is very similar to what we were seeking before, except that now, instead of looking for the minimum number of scoring opportunities, we want to find all the possible combinations of scoring opportunities. For our purposes, it’s okay to assume that a penalty conversion and a drop kick conversion is one and the same, as they amount to the same score of 3.

We can again use a dynamic programming approach, but this time we have to be a little more careful: if we were to simply add the combinations of previous totals to obtain the new total, we might count the same combination twice. For example, for a total of 3 there is only one combination: one penalty (or drop) kick. For a total of 5, there is also only combination: one try. Following our earlier algorithm, for a total of 8, then, we could look at the score 8-5=3, and find one combination. Next we look at 8-3=5, finding one combination again. We then look at 8-7=1, which has no combinations. So the total combinations is two. Right? Wrong! In using this dynamic programming shortcut, we accidentally counted the same combination twice: 3+5, and 5+3, which we consider to be the same thing. A total of 8 points can have only one combination, a try and a penalty kick. Therefore, we need to keep track of the combinations we found before, and ensure that any new combination we add is unique. Luckily this isn’t so bad, and in running our algorithm we can optimize memory by only keeping track of the combinations we found at 4 positions: i, the current total, i-3, i-5 and i-7. From these combinations we can build all possible unique combinations for i. You can see an implementation of this in Go by reading the source code for this post.

With the results calculated, let’s see the table of combinations for all the scores up to 20!

Score	Kicks	Tries	Tries + Conversions
0	0	0	0
3	1	0	0
5	0	1	0
6	2	0	0
7	0	0	1
8	1	1	0
9	3	0	0
10	1	0	1
	0	2	0
11	2	1	0
12	4	0	0
	0	1	1
13	2	0	1
	1	2	0
14	3	1	0
	0	0	2
15	5	0	0
	1	1	1
	0	3	0
16	3	0	1
	2	2	0
17	4	1	0
	1	0	2
	0	2	1
18	6	0	0
	2	1	1
	1	3	0
19	4	0	1
	3	2	0
	0	1	2
20	5	1	0
	2	0	2
	1	2	1
	0	4	0

Full table

From this table we can see that for a points total of 20, four different combinations are possible: 5 kicks and 1 try, 2 kicks and 2 converted tries, 1 kick, 2 tries and 1 converted try, or 4 tries. If we let the program run up to 145, the same highest score in a test match by New Zealand we saw earlier, we see that there were 119 different ways that the match could have played out so that New Zealand still ended on 145.

And we haven’t even talked about permutations! How many ways could that famous game have played out to reach the same 145 points total? In other words, in how many ways can we order each of the combinations to get the same result? If we have a game with 8 points total, a try and a penalty kick, that game could have played out in two ways: either first the try and then the penalty kick, or first the penalty kick, then the try. We can easily adapt our solution from the previous question to answer this for any total, but the numbers will grow very big very fast. I’ll leave this as an “exercise for the reader” ;)

What have we learnt?

Algorithms make everything more interesting.
To score a total of 145, you need to score at least 21 times.
The 1995 New Zealand World Cup Team were both formidable and efficient, and would make good computer scientists.
Dynamic programming is a useful technique in your programming toolkit.

You can find the full source code for this post here.

Aquileo | Integer Square Root Implementation

2013-12-23T00:00:00+00:00

Problem

Find the square root of a given number rounded down to the nearest integer, without using the sqrt function. For example, squareRoot of 9 should return 3, and squareRoot of 17 should return 4.

Solution

Let us consider what it means for a number x to be the square root of a number s. If x is the square root of s, x^2 is equal to s. Therefore, stated differently, the problem is to, given a number s, find a number x so that x is the biggest number for whichx^2 is either equal or smaller than s.

We may consider this to be a search problem. We have a number s, and we have to find a number 0 <= x <= s that satisfies certain conditions. Since the search space is the number line, which is already sorted, binary search is well-suited. We start our search with the full search space, with a number low := 0, and a number high := s. We then guess x to be in the middle of high and low, at (high + low) / 2. If x^2 is larger than s we narrow our search space by setting high to a lower value. If x^2 is smaller than s we do the same by setting low to a higher value. This is just like a normal binary search, except that instead of an array of integers, we are searching all integers between 0 and s.

The fact that we are only required to find an integer square root means that we do not need floating point calculations, which boosts efficiency. However, because the problem statement requires the square root be rounded down, we need to check two conditions:

that the square of the x we have found is either smaller or equal to v, and
that the square of x+1 is larger than v.

When these two conditions are met, we have found the square root of v, rounded down to the nearest integer.

Solution

Here is an implementation of the algorithm, written in Go:

func SquareRoot(v int) (i int, err error) {
    // use Newton's method to narrow in on the nearest
    // integer x where x*x is closest to v.
    var low, high int = 0, v

    // we have special cases for 0 and 1
    if v == 0 || v == 1 {
        return v, nil
    }

    // if v is negative, return an error
    if v < 0 {
        return 0, errors.New("Cannot find the square root of a negative number")
    }

    // choose x to be in the middle of high and low
    x := (high + low) / 2
    xs := x * x // x squared

    // keep looping while x squared is not the nearest rounded
    // down integer of any squared integer
    for !(xs <= v && (x+1)*(x+1) > v) {
        if xs > v {
            // if x squared is bigger than v, set the value of high
            // to the middle of high and low, which is where x is now
            high = x
        } else if xs < v {
            // if x squared is smaller than v, set the value of low to x
            low = x
        }
        // set x to the middle of high and low
        x = (high + low) / 2
        // calculate and store x squared to save some cycles
        xs = x * x
    }

    return x, nil
}

Follow-up question

How would you adapt your integer square root algorithm from the problem above to return the floating point square root of a given number, instead of an integer?

Aquileo | Minimum Palindrome Partitions

2013-12-23T00:00:00+00:00

Problem

Given a string s, partition s such that every substring of the partition is a palindrome.
Return the minimum cuts needed for a palindrome partitioning of s.

For example, given s = “aab”, return 1 since the palindrome partitioning [“aa”,“b”] could be produced using 1 cut.

Analysis

The first thing we need to do is write a function that is able to determine when a string is a palindrome. A palindrome is a string that reads the same from left to right as from right to left. Therefore, a simple way to test whether a string is a palindrome is to loop over every character in the string and compare it to the string at the same position from the other end. For example, if we have the string “madam”, we start by looking at the first character, m, and comparing it to the last character, which is also m. Since they are equal, we continue and look at the second character, a, and compare it to the second-to-last character, in this case also m. We continue in this fashion either until we find a pair of characters that is not equal, in which case we return false (not a palindrome), or when we reach the middle of the string, in which case we return true. Here is an implementation of this algorithm in Go:

func IsPalindrome(s string) bool {
    // convert to rune to account for non-ascii strings
    r := []rune(s)
    ln := len(r)
    for i := 0; i < ln/2; i++ {
        if r[i] != r[ln-i-1] {
            return false
        }
    }
    return true
}

Now that we have a function for determining whether a string is palindromic, we can get to the crux of the problem. We desire an algorithm that is able to find the minimum number of cuts we need to make to a string to turn all its parts into palindromes.

First, let us consider the brute force solution. This would be to attempt every possible partitioning, and then storing the number of cuts made if it is smaller than any previous number we have found and all the partitions are palindromes. There are N-1 positions where we can cut the string, and we need to consider every combination of these positions.

For the string abcd, for example, we can cut it in 3 different positions at once: a|b|c|d. We can also cut two at a time: a|b|cd, a|bc|d, ab|c|d, or one at a time: a|bcd, ab|cd, abc|d, or no cuts at all, for a total of 8 combinations. In general, it is possible to prove that there are 2^N possible partitionings for a string of length N. So the complexity of the brute force solution will be O(N.2^N), because we will need to check every partitioning (2^N combinations), and for each partitioning whether every partition is a palindrome (checking N characters in total, worst case). O(N.2^N) is not very good, and we can do better. Let’s try to find a more efficient solution.

As a rule of thumb, whenever a problem requires us to find the “minimum” or “maximum”, a dynamic programming solution should be considered early on. Let us see if we can formulate this problem in a way that leans itself to a DP solution. We start by looking at a section of the full string, from index i to j. If the string from i to j is palindromic, we don’t need any more cuts, and the answer is 0. Otherwise we need at least one cut, and the total minimum number of cuts needed to make this section palindromic will be one plus the minimum number of cuts needed to make the two new subsections palindromic. In mathematical notation, it looks like this:

f(i,j) = \begin{cases}
        min[f(i,k)+f(k+1,j) + 1 \mbox{ for } i \leq k \lt j]& \mbox{if }str[i:j] \mbox{ is not a palindrome}\\
        0& \mbox{otherwise}
        \end{cases}

You will notice that this definition is recursive, which is why it is a dynamic programming solution. We break the string up into smaller subsections, and apply the same algorithm on those substrings. If we implement this as a recursive solution however, the time complexity will be polynomial on the length of the string, which will be unacceptably slow for longer strings. We can instead build a NxN matrix of values calculated up to that point, and solve the problem in O(N^2) time and O(N^2) space. The matrix will be filled from the diagonal outwards, so that the final solution will reside in the corner of the matrix.

For example, if we have the string “abbaa”, the matrix will look like this:

[0 1 1 0 1]
[0 0 0 1 1]
[0 0 0 1 0]
[0 0 0 0 1]
[0 0 0 0 0]

The zeroes on the diagonal represent the fact that the string from index i to i+1 will always be palindromic, because it’s only one character long. At index 0, 4 we have a value of zero again, because s[0:4] (“abba”) is palindromic. The minimum number of cuts is therefore 1, at index 4.

Solution

The following solution is implemented in Go:

func MinPalindromeCuts(s string) int {
    // convert to rune to account for non-ascii strings
    r := []rune(s)
    l := len(r)

    table := make([][]int, l)
    for i := range table {
        table[i] = make([]int, l)
    }

    for u := 1; u <= l; u++ {
        for y := l - u; y >= 0; y-- {
            i := l - u - y
            j := i + u - 1
            if IsPalindrome(string(r[i : j+1])) {
                table[i][j] = 0
            } else {
                minCuts := 1 << 7 - 1
                for k := i; k < j; k++ {

                    m := table[i][k] + table[k+1][j] + 1
                    if m < minCuts {
                        minCuts = m
                    }
                }
                table[i][j] = minCuts
            }
        }
    }

    return table[0][l-1]
}

Follow-up questions

What is the time complexity of the solution?

The solution runs in O(N^3) time: there are two loops present in the main function, and they run the IsPalindrome function, which is itself O(N). Therefore, the solution is O(N^3).

How would you improve upon the solution above? (Hint: the solution can be improved both in terms of efficiency and in terms of memory usage)

One quick optimization we can make is to check, at the start of the function, whether the full string is already a palindrome. If it is, we can immediately return 0 for a total cost of O(N), the cost of checking that the string is a palindrome.

We can improve the solution further by noting that a substring str[a:b] is only a palindrome if the characters at a and b are equal, and str[a+1:b-1] is also a palindrome. We may therefore build an NxN table to store whether every substring of str is a palindrome or not. We could do this during preprocessing at a cost of O(N^2), and then use this table during our main function execution to do lookups in O(1), which brings the total time complexity down to O(N^2).

If memory constraints are tight, we may also improve on the solution above by using a one-dimensional array instead of a 2D array. This removes some of the memory overhead of storing separate arrays.

Aquileo | I Rewrote my Blog in Go

2013-08-14T00:00:00+00:00

Wow, this hit Hacker News front page! Thanks for all the encouraging feedback; I added some thoughts and clarifications to the bottom of the post for those who asked.

The short version

The full story

As part of my recent interest in learning Golang, I decided it would be a good idea to rewrite the IronZebra blog that, funnily enough, was itself the result of my venture to get acquainted with Django three years ago. The Revel framework looked like a good fit for this, and I decided to give it a go.

Overall, the experience was great. I had become familiar with the basics of Go before through writing a bunch of solutions to Euler problems, and this provided a good enough knowledge baseline for building a site in Revel.

I skimmed through the Revel docs to see how things like URL-routing work, and decided to plug mgo into it as an interface to my Mongo database. mgo is an excellent driver for MongoDB, and working with it was a breeze except for one or two surprises where the syntax deviated from the normal MongoDB structure. For one, the FindOne method was dropped for a chained combination of Find and One:

collection.Find(bson.M{"title": title}).One(&result)

Regarding Revel: Revel’s code reload is nice, and I like the way it simplified URL routing by allowing you to edit a well-structured text file which then gets compiled into Go code before serving the site. It’s a good solution to a problem that might have looked much more ugly had it been done only in Go. The one downside to Revel at the moment (although this is on the wishlist) is that it only ships with the default Go template language. Documentation on this isn’t all that good, and I felt like it doesn’t solve website templates nearly as well as Jinja2 or Django templates. The template inheritance, for example, seems clunky and I ended up with files containing only closing html tags – ugly. Maybe I should have read the documentation more closely, but I wanted to iterate fast and get things done. Plugging in your own template system is surely also possible, but for a first-time exploratory project this prospect seemed like a bit much.

I spent most of the time creating the admin functionality for editing and creating new posts. The admin section allows for markdown input (using blackfriday) and logging in with a bcrypt-encrypted password that gets stored in a user collection in Mongo. To give you an idea, here’s what the admin editor looks like:

The results

The speed improvement was staggering.

As differences between the two versions go: Both for the old Django site and for this Revel-based Go site, I never did anything along the lines of caching - no static page generation, no memcache, no groupcache - you can call it laziness, but either way, it makes for a more fair comparison between the two now. Secondly, I am now loading less static assets. I removed the Disqus comments and the many many lines of CSS from the old site and replaced it with only a couple of lines of CSS alongside a CDN-hosted copy of Twitter Bootstrap. Finally, the Go site is deployed to a free instance of Heroku and the MongoDB hosted on a developer version of Mongolab, while the old Django site was hosted on a Webfaction shared server. All these things influence the validity of a direct speed comparison between the two versions, but the speed improvement is nevertheless too overwhelming to attribute only to these small changes. And in fact, many of these changes might even have negatively impacted the speed of the new version in exchange for saving on the monthly bills.

But the end result: pages that load up to a 100 times faster on average, according to Google’s Webmaster Tools. Search traffic has also been steadily increasing this last month, possibly influenced by Google giving higher weight to sites that load really fast.

If you are interested in using this yourself or contributing, or even collaborating on making this into an open blog-engine written in Go - send me a ping on Github - this project is open-source and on there in its entirety. Enjoy!

Edit on 15 August 2013:

Afterthoughts

This hit Hacker News front page yesterday and it seems like this humble post started somewhat of a flame war in the comments section. I decided not to jump in, especially since I couldn’t really provide experimental answers to their very valid questions while 500 visitors were hitting the site every minute. Regardless, I also received so much encouraging feedback, emails and tweets; thanks all!

I hope to offer some small clarifications:

A lot of folks on HN commented on the Disqus removal. I’m afraid the graph was only for the time Googlebot took on average to download the HTML. I mentioned the removal of Disqus in the post, but that wouldn’t have a significant impact on this graph’s page load time, as others also later pointed out in the comments.
Yes, the old site was incredibly slow. Anything would be better. That’s part of the reason I rewrote it. I never spent any time making it efficient, which is why I didn’t even have caching. It was also hosted on Webfaction, which is, in my eyes, the most likely source for the slowness. If your Webfaction app is not in memory right now, it seems to take an incredibly long time to load it back in. User Jgrubb also wisely pointed out how much of a difference switching servers can make. He’s right, those graphs look mightily similar!
All this said, I think a lot of folks missed the point of this post, if there was any point at all :) I didn’t mean to imply “Go, and nothing but Go, made my blog 100x faster”. I meant to just say: “I rewrote this blog in Go, streamlined a bunch of other things, and now it’s 100x faster, yeay.” I realize that the graph was suggestive of the first one, my apologies for that.
There are good reasons for writing a blog from scratch and not using some existing solution for serving static files. One, learning. Two, fun. Three, a blog engine of this kind is like the “Hello World” of web applications. It covers a lot of the common things you’ll normally need to do in a bigger, product-oriented web application. Basic GET and POST, user login and database connections. Proving that it’s easy to write a CRUD blog like this is an early exploratory exercise in determining whether it would be easy to write larger-scale applications that scale.
And hey, after all is said and done, the Go-based IronZebra blog survived being posted on the front page of Hacker News on a free Heroku instance (pretty well at that, never even taking long to load), all without caching. If this were still Django, and still hosted on Webfaction, I don’t believe it would have been the case. That’s all I’m saying :)
I also added some more details in a presentation on slideshare - I’ll be presenting this in Tokyo tomorrow, drop by if you can!

Aquileo | Lessons Learnt from Startup Weekend

2011-12-05T00:00:00+00:00

This past weekend, I attended the Startup Weekend event in Hsinchu, Taiwan. It was a great event, well-organized and a lot of fun. The premise of Startup Weekend is simple: On the Friday night, anyone can pitch their idea in 60 seconds. The participants then vote on their favorite ideas, of which 10 are chosen, and everyone then divides themselves into groups for these ideas. Then you have the Saturday and Sunday to create a first-iteration business: Determine the Idea and Target Market, do Surveys for validation, Design, Build, get feedback, iterate, and try and have a working business by the Sunday evening, where you have 5 minutes to pitch your achievements to a panel of judges.

My team was named TakeMyRoute, a tool to help you plan your travels or daytrips, share it with friends, and have others gain advantage from your research and give their own experiences while traveling the route. On Friday night we only had a basic idea of what the site needs to do, but by Saturday afternoon we had determined a marketing strategy and monetization strategy, done surveys, designed the pages for a Version 1.0, and started coding. My responsibility was to design and code the front-end of the site within 24 hours. Tall task, but by Sunday afternoon we had a live site up and running, and ended up getting 2nd place in the competition.

Here are some lessons I took from the experience that I hope can be useful to future participants of Startup Weekends across the globe, specifically those who are responsible for building the prototype.

Lesson 1: It’s a demo, not Version 1.0

The judges don’t look at your code, but they definitely like seeing a working demo. In fact, the teams that placed first, second and third all had basic demos of the concept up and running, and either demoed it live, or showed a video of it in use. So it’s clearly important to really have code working, and not just some designs that show the idea.

However, you only have 24 hours. In all probability, what you build in that 24 hours will have to be rewritten if you choose to go on with the project after Startup Weekend, no matter what you do. So dont’ worry about making the code understandable. Don’t worry about maintainability. Don’t worry about standards compliance. Don’t worry about efficiency. Don’t worry about browser bugs. If it works in just one browser, fine, you’ll just show that one browser. As long as one browser understands what you wrote and displays it correctly, you’re fine. Realizing this early on can save a lot of time. Our demo, for example, was just three files, each with around 500 lines of code, javascript, css and html all mixed together. But it works fine, and illustrates the concept well.

Lesson 2: Design is just as important as code, if not more

Make sure you have good (really good) designs for the prototype, and if you have time, add some nice visual effects to the demo. It gives the illusion of a well-rounded, working project. In the end, that’s what people are going to fixate on, and they’ll be quite forgiving if one part of the code is a bit buggy or not implemented yet. You can even make sure they just don’t see those parts, but are impressed by the quality and attractiveness of the designs that are already built into your product.

Lesson 3: Use API’s and existing code where possible

This is mostly about saving lots of time. Before you start implementing something, first google if there exists an API or plugin that does exactly what you want. If there does, it can save you hours (or days) of development. We used Panaramio’s API for images, Google Places for populating the map with suggestions, and of course Google Maps for the actual map and Directions for the route planning. This gave us a working, extremely impressive prototype in a matter of hours. Another thing that helps is to use some code snippets available online, or even better, some of your own that you wrote for other projects. It saves you time thinking about how to implement something if you can just copy-paste.

Lesson 4: Delegate

You have all the skills to build the whole project? Great! But you can’t. Choose the part you’re the best at or that’s the most important to finish for the Demo (for me, that’s front-end), and give other parts to team-members who are even just partly skilled in that area. You can’t do it all yourself. And even if your team-mate is not an expert, he has 24 hours to figure things out as necessary. He’ll still achieve more than you would have, since you’ll have no time at all to spend on that.

As for anything you come across that you realize you’ll now need to spend time on, but someone else could have done it (maybe changing an image from .jpg to .png, for example), delegate. Ask someone to do it and send it to you, while you carry on coding.

Lesson 5: Good Lighting

This is more of a practical lesson that I personally learnt: Good lighting in the room you are working is crucial. We had some really strong lights in our room, and that (along with ample caffeine) caused us to not become tired so quickly, my eyes to not feel as tired as they usually do and able to achieve a great amount in just a day.

Just got one basic feature working? Be glad about it, and tell your team to come have a look as you demo it. This boosts team spirit greatly, gives you some quick feedback on the direction you’re heading in, and makes sure everyone stays motivated. It’s always really encouraging to see your team members achieving things - it inspires you to also have something great to show off. By the end of Startup Weekend, our team spirit was really high, and I think that’s due in a large part to our focus and constant achievements, right from the beginning.

Conclusion

Overall, Startup Weekend was a great experience, and I’ll definitely recommend it to anyone. If you’re a web developer / designer / app developer, your presence will be greatly appreciated, you’ll learn a lot of new things, and meet a lot of cool people. And if you’re lucky, you might just ignite a business that ends up growing to global scale.

Score	Kicks	Tries	Tries + Conversions
0	0	0	0
3	1	0	0
5	0	1	0
6	2	0	0
7	0	0	1
8	1	1	0
9	3	0	0
10	1	0	1
	0	2	0
11	2	1	0
12	4	0	0
	0	1	1
13	2	0	1
	1	2	0
14	3	1	0
	0	0	2
15	5	0	0
	1	1	1
	0	3	0
16	3	0	1
	2	2	0
17	4	1	0
	1	0	2
	0	2	1
18	6	0	0
	2	1	1
	1	3	0
19	4	0	1
	3	2	0
	0	1	2
20	5	1	0
	2	0	2
	1	2	1
	0	4	0

Score	Kicks	Tries	Tries + Conversions
0	0	0	0
3	1	0	0
5	0	1	0
6	2	0	0
7	0	0	1
8	1	1	0
9	3	0	0
10	1	0	1
	0	2	0
11	2	1	0
12	4	0	0
	0	1	1
13	2	0	1
	1	2	0
14	3	1	0
	0	0	2
15	5	0	0
	1	1	1
	0	3	0
16	3	0	1
	2	2	0
17	4	1	0
	1	0	2
	0	2	1
18	6	0	0
	2	1	1
	1	3	0
19	4	0	1
	3	2	0
	0	1	2
20	5	1	0
	2	0	2
	1	2	1
	0	4	0

Aquileo | Herman Schaaf

Aquileo | Sky Lobby

Links

Aquileo | What we lost when we stopped programming

Aquileo | My Mental Model for “Is It Worth Automating?” Has Changed

Automation gone wild

1. Bots to playtest the game, simulating different player styles and skill levels

2. A script for syncing Game Center entries

3. Screenshots of the game for every iOS simulator

4. A promo video as code

What this means

On the other hand

Updating our mental models

About the game

Aquileo | A Free Chinese Dictionary, and Why I Built One

Yet Another Chinese Dictionary?

The Long Tail, Revisited

The HSK That Was, and the HSK That Will Be

Robots, Buddies, and Other Joyful Compounds

Try It

Aquileo | Moya Chinese

Aquileo | New Game: Picnic on the Moon

Aquileo | Should Makers Still Care About Code Quality?

Coders vs Makers

…And Then Came the Agents

So what can we do?

Conclusion

Aquileo | Cryptic Crosswords: What They Are and How to Solve Them

The Principle

Spotting the Definition

Wordplay Indicators

Examples of Wordplay

Anagrams

Containers

Charades

Deletions

Double Definitions

Palindromes

How I Approach a Clue Now

Why Cryptic Crosswords

Aquileo | Solving Every NYT Spelling Bee Puzzle, Now and Forever

Bringing all The Bees to the Yard

Harvesting the Honey

A Dance-off with the Official Puzzles

Flight of the Four Million Bumble Bees

Notes

Update (6 Feb, 2026)

Comments

Aquileo | 3 Books for New Engineering Leaders

1. Become a Great Engineering Leader - Build Effective Skills to Lead and Grow

2. Scaling People - Tactics for Management and Company Building

3. How Big Things Get Done - The Surprising Factors Behind Every Successful Project, from Home Renovations to Space Exploration

Honorable Mentions

Supercommunicators

Good Strategy / Bad Strategy

Closing Thoughts

Aquileo | Moving my Blog from Hugo to Zola

Aquileo | 3 Rules for Choosing Nonfiction Books

Rule #1: Prefer books by experts in the field

Rule #2: Only accept Goodreads ratings of 4.0 and up

Rule #3: No books with the word "surprising" on the cover

Case studies

Aquileo | Efficient Bit Manipulation in Go 1.9

How does it perform?

Example Use Case

Conclusion

Aquileo | Diary of Building an iOS App with React Native

The first screen

Adding a ListView

Hooking up a database

Submitting the app

Closing remarks

Aquileo | Excellent Open Source Go Projects

Aquileo | Solving Regex Crosswords using Go

The algorithm

Regular Expressions and Go

Putting it all together

Caveats

Grab the code

Aquileo | Running the Go Race Detector with -cover

Score	Kicks	Tries	Tries + Conversions
0	0	0	0
3	1	0	0
5	0	1	0
6	2	0	0
7	0	0	1
8	1	1	0
9	3	0	0
10	1	0	1
	0	2	0
11	2	1	0
12	4	0	0
	0	1	1
13	2	0	1
	1	2	0
14	3	1	0
	0	0	2
15	5	0	0
	1	1	1
	0	3	0
16	3	0	1
	2	2	0
17	4	1	0
	1	0	2
	0	2	1
18	6	0	0
	2	1	1
	1	3	0
19	4	0	1
	3	2	0
	0	1	2
20	5	1	0
	2	0	2
	1	2	1
	0	4	0