Simple Swift Promises

Recently, I’ve been working on cleaning up the networking code in Tusker, my iOS client for Mastodon/Pleroma and I briefly played around with using the new Combine framework as well as the built in URLSession.DataTaskPublisher helper. Combine, much like SwiftUI, uses Swift’s incredibly powerful type system to great advantage because it’s a Swift-only framework. It’s quite efficient, but because there are so many generic types and implementations of different protocols, the API (in my experience) isn’t the most pleasant to work with. I was thinking about other asynchronous programming schemes and the one that came to mind as being the nicest to use was JavaScript’s Promises. It has a fairly simple API, so I started wondering how much work it would be to build something similar in Swift. Turns out: not that much.

Faking the Mongo Eval Command

One of the changes in MongoDB 4.2 was the removal of the eval command. While a reasonable security measure, this is rather annoying if you’re building an app for interacting directly with a Mongo database. If you want to be able to run commands directly on the database, you now have to go through the mongo shell. This seems straightforward, but actually getting the data back into a format that’s usable is a bit of a hassle.

Mocking HTTP Requests for iOS App UI Tests

I recently decided to start writing User Interface tests for Tusker, my iOS app for Mastodon and Pleroma. But I couldn’t just write tests that interacted with an account on any real instance, as that would be far too unpredictable and mean my tests could have an impact on other people. The solution to this problem is, of course, mocking. The core idea is that instead of interacting with external things, your program interacts with mock versions of them, which appear to be their real counterparts, but don’t actually perform any of the operations they claim to. This allows for very tight control over what data the application receives, making it much more amenable to testing.

Unfortunately, if you search around, some of the most common solutions on the internet recommend using the environment variables (one of the only ways of sending data directly from the test to the application under test) to insert the mocked response into the app. Meaning, for every API response you need to mock, you would have an environment variable that contains the response data. This isn’t a great solution, because it leaves whole code paths untested (everything after the request URL would be generated). It would also mean that there’s no way of testing things like what requests are actually made by your app.

The solution to this problem is to actually run a local HTTP server that functions as the API server. This way, the app can communicate with the web server exactly as it would in the normal operating environment, but still have strictly controlled data. Of course, actually doing this isn’t quite so straightforward.

Building a JavaScript-Free Slide-Over Menu

Slide-over menus on the web are a pretty common design pattern, especially on mobile. Unfortunately, they seem to generally be accompanied by massive, bloated web apps pulling in megabytes of JavaScript for the simplest of functionality. But fear not, even if you’re building a JavaScript-free web app, or simply prefer to fail gracefully in the event the user has disabled JavaScript, it’s still possible to use this technique by (ab)using HTML form and label elements.

Learning Elixir

About a year ago, I set out to learn the Elixir programming language. At the time, it was mainly so I could contribute to Pleroma, but I’ve since fallen in love with the language.