Dependency Injection (DI) is a $25 word for a 5¢ idea, but it’s an idea that has become wholly foundation to how I write software. I want to take a look at some of the ways our team have been using DI in Swift.
It’s been so fun to watch the Swift developer community experiment with Swift and to experiment with what idiomatic Swift will look like. No one really knows the answer yet, but we’re starting to see some design patterns used more than others. We’re seeing some language features used in key ways that define idiomatic Swift, and other language features that are being mostly ignored.
Regrettably, one of my favourite features of Swift has not enjoyed the meteoric rise in popularity I believe it deserves: typealias.
GraphQL is something you may have heard in passing, usually from the web team. It’s a Facebook API technology, that describes itself as a A Data Query Language and Runtime. GraphQL is a spec, and there are multiple implementations of it. As mobile engineers, we can consider it an API, where the front-end team have as much control as the backend.
This blog post covers our usage of GraphQL, and what I’ve learned in the last 3 months of using it in Eigen.
We use CocoaPods, and we don’t check in our Pods directory for one of our fastest moving apps, Eigen. This sometimes can cause an interesting data churn inside the Podfile.lock when developers have different sha checksums for their Pods. This is weird, what gives?
I am a big fan of developer tooling, as spending time upfront on improving your process can pay a lot of dividends over time. I want to talk about one in particular: Paw. Paw is a native HTTP client with a bunch of features. I want to cover one that means that we can now introduce [AppName].paw files in our mobile projects, making it easy for us to discuss networking requests.
Eigen has hit the point where testing is a chore. This is a positive sign, the app has grown in terms of size, complexity, and number of developers considerably over the last 3 years. The test suite makes us feel comfortable making changes.
On my fastest computer, we’re just under a minute - Executed 1105 tests, with 1 failure (0 unexpected) in 43.221 (48.201) seconds for the whole suite. I think I could probably live with 20 seconds max. So I studied how AppCode handles running tests, and this will be an illustrated guide as to how you can easily run the subset of tests in Xcode based on their techniques.
I have ideas on how to improve time for testing in general, based on Code Injection, but they aren’t fully fleshed out and I expect it to be time-intensive to pull off. Time I haven’t made yet.
Artsy has now grown past 140 team members and our Engineering organization is a nimble 25. We’ve recently performed a large organizational change (I highly recommend reading “The Secret(s) to Company Re-Orgs”), so this is a good time to describe our updated Engineering organization, starting from the top - Artsy as a company and business.
So you’ve decided you’d like to give speaking a go, or perhaps you were always interested. By now you’re probably wondering where to start.
There are various options depending on what you’re looking for. Would you prefer a smaller, intimate audience or would you like to reach far and wide? Is the topic of your choice suited for a quick talk or would you rather discuss it at length? Let’s have a look.
At Artsy, sharing knowledge is heavily encouraged and so we write our code in the open, document using blog posts, and speak about our experiences. Many have bumped into us at various places around the world. And so I often get the question: “How did you get started? I’m interested in speaking too”.
In the name of sharing experiences with others, I can’t encourage this enough. Unfortunately though, public speaking is still considered man’s biggest fear.
I’d like to share with you the benefits of public speaking, tips on how to get started, and how to give great presentations.
I have been writing code for roughly a decade. A large chunk of that time has been sitting waiting for my project to compile. It’s a nice excuse to practice sword fighting in the office, but really, deep down. It’s frustrating. It’s so easy to become nerd-sniped when you wait for a long time.
As we integrate Swift into our projects, I’ve been seeing our compile times increase. So, I took some time to look at ways to improve this. The best option, so far, has been dynamic code injection via Injection Plugin for Xcode. In a gist: This means that we don’t recompile and re-launch, instead we inject new bits of code into a running application. This reduced the compile cycle on Eigen from 7 seconds to 1 second.
I took some time over the weekend to try and put together a video showing how I used code injection on a trivial app to create a view controller in code. It covers the technique I’ve started using in Eigen and talks a little bit about how the pieces come together.
Jump to YouTube for the video, or click more for a smaller inline preview.