And we’re back! With lesson three of the beginners’ Swift-at-Artsy course. To recap, Orta and I led a course at Artsy to teach our colleagues Swift last August, and we’re doing it again. I’m leading the stream for people who’ve never programmed before.
Yesterday was lesson three and I have a screen recording of my walkthrough of the material.
I arrived fashionably late to the React Native party in Artsy. I had been a part of our Auctions Team, where we worked in Swift with some light-FRP. We were not affected by the 4 months of simultaneous work on moving to React Native, at all.
It was a quiet revolution. I did not have to install npm, I made zero changes to the code for auctions and the whole app’s infrastructure barely changed. Yet we moved to making all new code inside our 3 year old iOS app use React Native. What gives?
Well, first up we weren’t planning a re-write, we don’t have that kind of luxury and the scope of our app is too big compared to the team working on it. Second, we reused existing dependency infrastructure to support JavaScript based apps. Read on to find out what that looks like.
And we’re back! With lesson two of the beginners’ Swift-at-Artsy course. To recap, Orta and I led a course at Artsy to teach our colleagues Swift last August, and we’re doing it again. I’m leading the stream for people who’ve never programmed before.
Yesterday was lesson two and I have a screen recording of my walkthrough of the material.
I’m an old school TextMate user, who has also been using Xcode for the last decade. These two sit at a very opposite ends of an “editor” spectrum.
TextMate is extremely bare bones at the core, but introduced the idea of bundles as plugins. Making it really easy for others to build their own plugins for their own contexts. Xcode on the other-hand includes a 3D scene editor, the best interface builder I’ve seen, super rich debugging tools and close to zero support for improving it yourself.
As we agreed on moving to React Native, we needed to decide what the team should use for working in that environment. After experimentation with many editors, we decided on Microsoft’s Visual Studio Code.
We wanted to keep a lot of the best features from Xcode, while working in a completely JavaScript environment. For example: debuggers, inline errors, auto-complete, symbol mapping and to ideally have them all inside a single editor.
Let’s dig into the principals of how Visual Studio Code works, what makes it a better option for us, and what parts of it really shine.
Last August, Orta and I led a course at Artsy to teach our colleagues Swift. There were two parallel groups of learners: a “beginners” group who had never coded before, and an “informed” group who already knew how to code. This year, we’re leading the course again with a slight twist: we’re repeating the course for absolute beginners, and we’re introduce a new course for anyone who completed last year’s beginner course.
We’re really excited both to help new colleagues take their first steps into programming, and to help returning colleagues continue their journey.
Today was lesson one of the beginner group, and I have a screen recording of my walkthrough of lesson one’s material.
As the Artsy iOS app grew larger, we started hitting pain points:
It took us about a year to start resolving these issues. Ideally, we wanted to find a solution to our architectural issues that would also improve the user experience. Notably we wanted more efficient networking, due to mobile device constraints.
It would have been an easy leap to start using Swift and, as a matter of fact, we do use Swift in parts of our flagship application and entirely in 2 other apps.
However, while Swift is a great language, it’s also just that: another language. It does not do much in terms of new paradigms that solved our architectural needs, it does not help in terms of cross-platform - as most of our code is building views and thus very framework specific, and it did not really offer anything in terms of more efficient network data fetching.
We’ve seen that the web teams integrate React in their projects with really great results. We’ve been paying attention to React Native since it came out; the solutions provided by the React ecosystem ticked all of our boxes.
Six months ago we took the plunge, and last month we formalized that this is the direction we want to go.
Hello everyone! Orta here, over the summer I’ve started a series of interviews with the entire development team at Artsy. They’re all on different topics, notably around technical and cultural issues. I’ve recorded a few of them already, and will be sporadically releasing them. I’m still getting the hang of editing and recording side of this, so give me some slack.
Anyway, I’m pumped to introduce the first in the series - Craig Spaeth.
Craig has been at Artsy for 6 years, moving from the first on-site developer to Director of Web. Our interview covered how Artsy’s development team has adapted over time to the changing demands of a growing company. When he joined, Artsy was 6 people, we’re now at ~145 people, ~20 developers and 3 businesses.
Jump to YouTube for the video, or click more for a inline video.
In late June, the Artsy auctions team launched our Live Auction Integration (LAI) product. It allows people to participate online in live sales held at auction houses that partner with Artsy. It was a big project, begun in December, involving both brand new software and extensive integration work with the rest of our systems. This is the first in what will be a series of blog posts discussing the engineering work we did to get a complex product from inception to launch in such a brief time window, with a go-live deadline set in stone weeks in advance. In this, I’ll dig into what we shipped on a high level, as well as some of the overarching technical decisions.
I help maintain big OSS projects: from a third-party dependency manager used in most iOS apps (CocoaPods), to the most popular Objective-C testing framework and the most popular Swift networking API client. I’ve been doing this for years.
Projects with this much impact are big time-sinks. This time comes from ensuring infrastructure continues to work, support tickets need replies, new code needs reviewing and releases need coordinating.
Last September, almost a year ago, I started work on a new project, Danger. Danger fixes a problem we were seeing in the Artsy mobile team around adding “process” to our team.
As a part of discussing Danger internally, I’ve referenced that building CocoaPods has greatly influenced Danger. This blog post is about the way I’ve built Danger, knowing fully well that I cannot afford the level of time to maintain it at the scale it may get to.
It was only three months ago that I came to the conclusion of just how much time I had wasted on code compilation cycles, once I started to play with Injection for Xcode. I still feel guilt about the time I wasted. However, I’m trying to turn that into something constructive. In order to do that, I need to have a solid understanding of the fundamentals on how Injection For Xcode works.
Ash says one of the best ways to learn is to teach. So I’m going to try take you through a guided tour of the code-base. You need some pretty reasonable Objective-C chops to get this, but anyone with an app or two under their belt should be able to grok it.