Often times in chess you will see a beautiful sequence of moves where you wish with all your might that your opponent cooperatively follow it. This is one of the times where my opponent did.
This game the engine did not like at all, scoring me at 21.5% accuracy to my opponent's 74.1%. Nevertheless I found it interesting as one of the more tactics-heavy games I've played, and was surprised to see at a certain point the engine actually thought the game in my favor despite me feeling pressed up against the wall. Goes to show the difference between cold blooded machines playing chess versus that of an emotional human.
A couple months ago I was browsing YouTube and stumbled across a recording of a Twitch + Chess.com Pogchamps chess match between Twitch streamers @Hafu and @Fintan Hand. After unexpectedly watching that video in it's entirety (prior to this point I did not consider chess a spectator sport), I was surprised to find myself re-motivated to play chess. I had played chess as a kid, going to after-school classes and enrolling in tournaments and at the time I was probably good enough to hold my own against a random person off the street, but was by no means competitive on say, a state-wide stage.
Since then I've immersed myself back into chess, spending many of my evenings and weekends watching, studying, and playing chess. Fast forward to today, and I thought it might be both beneficial and fun for me to blog analyses of some of my games, both to help improve my own gameplay, but also perhaps to revive this blog.
One of my favorite things about Nix is using the nix-shell to provision the development tooling for a project
without infecting the rest of the system. Even if the project itself isn't built with Nix, I will often have a
shell.nix just to provision tools like Cargo and SBT. This becomes especially helpful with Rust
where each of my Rust projects can have a different
rustc version without needing to switch my rustup toolchain.
In the age of modular microservices, data pipelines, serverless, and IoT, handling data serialization has become a major design decision. While monolithic architectures are well, monolithic, coordination between components is simply a function call away. In contrast, components that are separated by a network or run as different stages in a workflow must communicate by serializing and deserializing data. Add in questions like how much data is being serialized, how often it needs to be serialized, how many languages are in play, and how various components evolve, and we can see how data serialization has turned from an incidental problem to a central one.
For the past couple of weeks I have been using Rust for a project at work and enjoying it a lot. The emphasis on systems programming aligns well with my interest in systems, the unique type system keeps the programming languages enthusiast in me interested, and the use of expressive types, as always, keeps me in check and makes me confident in my code.
I spend a lot of my time reading papers and over the years a couple have always stuck out to me. For this post I wanted to write about an oldie but goodie: Saltzer, Reed, and Clark's "End-To-End Arguments in System Design."
I am excited to say my short paper "The Limitations of Type Classes as Subtyped Implicits" has been accepted at Scala Symposium 2017!