Last weekend I was playing around with a way to represent null-terminated UTF8 strings in Rust. Rather than just toying with it forever, I decided to clean up a minimal version and publish it to crates.io. Creating the crate went smoothly, exactly the same as the 11 prior crates I’ve published. I closed up my laptop and called it a day.

Well, everything only seemed the same until an hour later when I got this tweet:

Lately I’ve been thinking about a new way to generate Objective-C type encodings from Rust. The Objective-C runtime needs these encodings when declaring methods and instance variables, and in Objective-C they’re simply generated via the @encode() compiler directive, but that’s not available in Rust!

Since I started automatically testing my Rust crate with Travis, I had always wanted to test on iOS as well. Unfortunately, the default Rust compiler on Travis doesn’t support iOS, and compiling one from scratch takes a prohibitively long time. With Rust’s improved cross-compilation support, it’s now possible!

I previously wrote about how to interoperate between Objective-C and Rust and use a Rust macro to pass a variable number of arguments to objc_msgSend. Well, there’s a problem with this: objc_msgSend isn’t a variadic function!

Since the Objective-C runtime exposes a C interface, it’s actually pretty easy to interact with from Rust. Over the past months I’ve worked on a Rust wrapper around the Objective-C runtime and some classes of the Foundation framework, creatively called rust-objc. I had hoped to learn more about Rust’s foreign function interface and the Objective-C runtime, but along the way I also encountered some interesting challenges in API design.

For documenting and testing large APIs, response mocks can be a very useful tool. They not only provide examples for the users of your API, but they can be used in automated tests as if you had received real data without actually hitting the network.

Creating and maintaining a large collection of response mocks can be greatly simplified by preprocessing them with a template engine like Python’s Jinja. Although this adds another step to your build process, it allows some really useful functionality!

The next version of Octopress is packed full of awesome improvements. Octopress will change massively to be more extensible and customizable while still being as powerful and easy as ever; as such, this update has been in development for a long time, still not having released officially.

In anticipation of this update, I periodically check the Octopress Twitter for news and have encountered many release date estimates. Estimating time for development is notoriously difficult, so I’ve compiled a lighthearted Twitter history of Octopress 2.0’s successor and its estimated release dates.

I really like git; if I could keep everything under version control, I would. I’ve started writing all my papers in LaTeX instead of Word, not only because it’s cleaner and can provide more control, but because then I can version control them. Hell, I’ve even started keeping my Borderlands 2 game saves backed up in a git repository.

Imagine my delight, then, when I discovered Octopress. Octopress is a framework that makes it really easy to generate a blog just from a set of markdown files that can be hosted on GitHub pages. I’ve already been using GitHub to host my personal website, and using it to host a blog would be pretty swell.

I’ve worked through the documentation to get a blog up and running; after all, I have homework to be working on right now, so I need to find something else to do. Nevermind the fact that I never actually put in the effort to blog or can come up with interesting topics; if nothing else, this was just an exercise to test out Octopress and to become more familiar with the features of GitHub pages.