As an excuse to play around with some web stuff, I pretended my website was getting so much traffic it was costing me an arm and leg to host it, and that my users complained it was too slow for them. Because my website is statically generated, optimizing it was pretty low hanging fruit, so I set out to do a few tweaks to optimize it, and wrote them down here for future reference.

While looking at the demo site of Twenty Fifteen (the theme I use for this blog), I noticed it used infinite scrolling, where more articles get automatically loaded when you reach the end of the page. It looked like a neat thing to have, but since I didn’t actually use WordPress, I couldn’t use the plugins that provide infinite scrolling. Writing it myself seemed like more effort than it was worth, so I dismissed it at the time.

In a previous post, I played around with monad do-notation in Scheme (well, Racket) to have a nicer syntax to play with asynchronous callbacks. This do-notation is actually quite fun to use with other monads as well. What’s interesting is that the same notation gets entirely different meanings and forms depending on which monad you use it with. There are many interesting monads, and this post shows only a couple of simple ones in action in Scheme (for which you can find the code here).

A few unrelated topics on my reading list made me want to randomly experiment with a few things. I wanted to understand monads a bit better, see how they applied to callback-based asynchronous programming, and play around with macro programming in a Lisp dialect. This is a partial log of the theoretical-and-probably-not-directly-applicable-but-nevertheless-fun rabbit hole I dived into. The Callback Pyramid Problem JavaScript (and especially Node.js) uses lots of asynchronous APIs. These are implemented by adding an extra callback parameter to asynchronous methods, where the callback parameter is a function that receives the result of the call when it’s finished.

With Google rolling out an update penalizing non-mobile friendly sites, and my non-responsive website theme dating from 2009, I thought it was a good time to give my nanoc-based static blog a makeover. I looked around for something lightweight, minimalistic, responsive, and easy to customize, and finally settled on using the latest default WordPress theme, Twenty Fifteen. Although it’s is a bit light to my taste on larger screens, it really shines on mobile devices.

Because of the high demand, we created a widget for one of the most classic games out there: the jigsaw puzzle. Jigsaw puzzles are not only exciting to put together, they also trigger reasoning, analyzing, and problem solving, making them a fun way to learn and develop basic skills.

Ah, Christmas holidays: that time of the year when we visit our friends and relatives, and reminisce all night about “when we were young”. This year turned out no different for me. While visiting my parents, I took a trip in between dinner courses to their attic to dig for childhood memories, and I found this little gem buried below layers of dust:

“Bingo!” Who doesn’t like the thrill of finding the last item on your list, jumping out of your chair, and shouting you won? Bingo is an incredibly fun game to play in group, is very easy to play, and can help rehearse anything from language vocabulary to math and historical facts. Everyone can play the game together, regardless of level. And best of all, you can create your own, customized Bingo cards for iPad in only a few minutes using the Bingo widget.

After considering several software build systems for Swift a few years ago, we ended up settling on SCons for its correctness, power, and maintainability. The main thing we traded this for was speed: although we could get a no-op build down to only a few seconds by using the right flags, those few seconds can still get in the way when doing very short build/test/debug cycles during daily development. To shorten the turnaround time during development, I created a script to use SCons to generate a build file for Ninja, a small but very fast build system, which gets our no-op builds down to a fraction of a second.

As a weekend project, I created JsnPrsr, a fast, small and lightweight JSON parser (and serializer), written in Java, with no external dependencies. I played around with Caliper to microbenchmark different snippets of code to squeeze some more performance out of it, within bounds of keeping the code readable. Running some artificial performance benchmarks against the json.org reference implementation and minimal-json, another fast and minimal JSON parser, resulted in the following timings: