Developer Advocate at Flightcontrol: 8 Months In

It’s been about 8 months since I joined Flightcontrol as the Developer Advocate. Flightcontrol is a developer-first platform that lets you deploy and run applications on your own AWS account without having to use AWS yourself. It’s a little bit different from a startup I might have expected to join or start myself, as the focus is on DevOps, platform engineering, and AWS.

The position I have is probably a little bit different from what other people with a Developer Advocate title do – I’m really focused on customer success, and making sure that users who get started with Flightcontrol can deploy their projects! A lot of this is writing docs for the Flightcontrol web site, but a decent part of this is helping out our users directly on Slack or Discord. Usually if they run into a somewhat generalized problem, it’s a good candidate for the docs.

This position puts me much closer to the users than my previous developer educator position at Twilio (employee and contract), where users reached out to support first, and then things filtered into the docs team for action later. I also tend to identify a lot better with the Flightcontrol users than the Twilio users – I wasn’t the ideal customer for most Twilio products, so it was hard to figure out what the actual pain points were.

In addition to docs and customer success, I also enjoy being user zero for a lot of our new features, usually so I can write up a docs page, and ship them in our changelog. I’ve also gotten to attend some great conferences, such as React Miami, Write the Docs, Deep Dish Swift, and the last Strange Loop and talk to folks about Flightcontrol.

As always, reach out to me here, or over email, or on Twitter/X/Whatever as @jefflinwood


Spring 2021 Mobile Apps Class

For the 2021 spring semester, I’ll be teaching the Mobile News App Design class at UT Austin that I’ve co-taught with Robert Quigley for the past 8 years (2013-2020). This class is online this semester, and available as CS 378 or J 335 – cross-listed between Journalism and Computer Science.

The students in the class get the opportunity to form cross-functional teams and work on their own iOS or Android app projects. That means that journalism students will work with computer science students – and most alumni of the class say that this is one of the best things they did at UT Austin to prepare them for the real world work environment.

Journalism students do not need to have prior programming experience. Computer Science students don’t need to have specific mobile development classes or programming languages.

Student teams in the past tend to create native iOS apps using Swift (which requires a Mac), but they are welcome to create an Android app using Java, Kotlin, or React Native if they want. It’s less about the specific technology and more about creating an app that people want to use.

There are also cross-functional assignments, where the journalism students will take on a programming challenge, and the computer science students will do a writing assignment.

The class is structured into four sprints, with short demo presentations after each sprint from each team to the class. The goal is to progress towards submitting the app to the Apple App Store or the Google Play Store.

At the end of the semester is a demo day, where the teams will show off what they’ve build.

This class is a lot of fun, and I’m excited to teach it online this semester.


Adding Error Monitoring to Rails on Heroku with Airbrake

Once you start running web services on a test, staging, or production server, it’s important to keep an eye on errors and exceptions.

Several solutions exist for this – your choices depend on which technology stack you use, and where you host. I prefer to host my Rails applications on Heroku, as it’s very easy to update the servers from my command line. Heroku has add-on partners in its ecosystem, so that you don’t have to set up separate accounts and billing with each and every provider. Looking through the options, I decided to try Airbrake, as they had a reasonable free tier plan I could use for development and testing.

I followed the instructions on Heroku’s DevArticle – the only thing that didn’t work was the next to last step:

rails g airbrake

The Rails generator for Airbrake was supposed to load my project configuration information from Heroku’s config, but that didn’t work.

I had to manually specify my Airbrake Project ID and API Key:

rails g airbrake <project-id> <api-key>

So try that out if you have issues following the install – it was easy enough to figure out, and the instructions on Airbrake’s site also worked for me, by showing the command line arguments.

I’ll follow up on this post once I see more of how it works on Heroku – I may end up sticking with Airbrake, or trying something else out.


Useful Skills for Junior iOS Developers

I’ve taught seven years of a mobile apps development class at the University of Texas. Computer science students form teams with journalism students, create a mobile app, publish it on the App Store, and then show it off at the end of the semester to a panel of judges. We tie it all into a sort of agile/scrum format, but that’s hard to really pull off in a class that meets for 75 minutes twice a week.

This has been one of the most rewarding things I’ve done in my career – students come back after graduating and tell myself and Robert Quigley, the other instructor, that this was one of the best classes they took during their college careers. They learn how to work with team members who aren’t like them, whether they are journalism majors or CS majors. They have to ship something – for those of you in the software world, you know that’s a hard skill to learn. And it’s all their work – I debug Swift, answer Firebase questions, give advice, and offer suggestions, but it’s their projects, and they can take it or leave it.

Still, no matter how much I mention these things at the beginning of the semester, I always see at least one or two teams stuck on them! Here’s my list of things that junior iOS developers need to know to ship an app to the App Store:

  • Testing on all iOS phone sizes, including the iPhone SE/iPad – Apple’s reviewers use an iPad, which won’t show as much of the app as the iPhone 11 Pro Max it’s easy to design your app for in Storyboard.
  • Multiple storyboards and storyboard references – Apple’s XML format for storyboards does not work with source control. End of story. Breaking your huge storyboard into one storyboard per view controller isn’t too hard, and helps with source control.
  • Pull requests and git branching – if you don’t have a strategy for working on features in branches and merging to master, it’s going to be really hard to work as a team.
  • Understanding asynchronous calls and closures. Coming from other programming languages or environments, where everything happens in order, moving to a world of networked API calls, blocking on the UI thread, and closures can be difficult. You’ll end up with weird race conditions, code that never executes, and it will all be really hard to debug.
  • Speaking of debugging – the Xcode debugger isn’t that hard to use – breakpoints are straightforward, inspecting local variables is easy unless they are subclasses of subclasses, and there is a command line to interact with your app. Definitely a skill worth learning.
  • Bringing in crash reporting and analytics tools (like Firebase). Once you release an app, even to TestFlight, it’s really useful to find out if users can reach parts of your app, if it crashes when people use it, and what devices your audience uses.

This is my first take on a list – there are lots of other things I could add, but these tend to be what I spend time on in class. That said, I’ve noticed that every year the level of development talent increases – maybe there’s more tutorials and better documentation, or their other classes are teaching them these skills.

Have anything you would add to the list? Let me know at jlinwood (at) Thanks!


Intro to Mobile App Development Class 2019 Published

I published the syllabus, assignments, and weekly slides for my Fall 2019 Intro to Mobile App Development class at the University of Texas.

This year, I changed things around from being 4 months of Swift and iOS application development to being a little more well rounded. We did an introduction to Swift, and an introduction to Android development. Then we covered version control with GitHub, user research and prototyping, and mobile application design.

This was the 7th year of this class, and for me, it was interesting to mix it up. The feedback from the students through the semester was that they found it more interesting than just focusing on one thing for the entire class. The downside is that we never got very deep into one topic to really give an in-depth explanation of why things work they way that they do.


Quirk with Rails 5.2 Encrypted Secrets and Slack Client IDs for OAuth

I’m building a Slack App on top of ZapCircle, so that you can leave status updates from Slack, and also publish them directly from Slack. Part of this is managing flow for OAuth, so you can add the ZapCircle app to your Slack team, and there is a connection.

OAuth requires a client ID and client secret – from Slack, my client id happened to be all numbers with a period in the middle. I didn’t happen to notice this when pasting it into the Rails 5.2 encrypted secrets file, which is YAML.

Unfortunately, YAML coerced that client ID into a float type, and then rounded off after the significant digit. That number didn’t match anything Slack had, so I had to debug it.

The simple fix was to wrap the Slack client ID in double quotes in my YAML file.

I don’t know if this is a common bug, but hopefully this saves you (or future me) a few minutes of debugging in the future!


ZapCircle: Status Updates for Remote Teams

I work with a lot of different companies and teams as a remote software developer – sometimes it’s just a handful of us, all in different cities, sometimes everyone is in Austin, but never goes into the office. I work remotely when I write code, and have done so for about six years now.

TLDR: My new SaaS web application is ZapCircle – go ahead and get started now!

One of the common threads between all of these different teams is communication about the different projects everyone is working on. There are many different ways to solve this problem – daily in-person standup meetings, conference calls, emails out to the whole group at the end of the day – none of which I’m personally thrilled about.

Sample Status Update for ZapCircle.

I decided to try and focus on building a software tool for status updates for teams. For those of you coming from a Unix background, it’s basically the equivalent of the .plan file. Coming from an agile background, this is a replacement for a standup meeting. There are definitely other pieces of software you can use to solve this problem – Slack is probably the most obvious – but I wanted to build something for just this need.

To that end, I focused on small teams (probably up to ten people), and two different areas – status updates, and important project dates.

It’s easy to get started:

  • Create an account, and name your team
  • Invite your team members
  • Setup the important project dates (due dates, reviews, trips)
  • Write a status update when you’ve accomplished something!

You can also change the questions ZapCircle uses for your team, if the standard ones don’t work.

It’s been a long development process so far, but I’ve taken all of the “must haves” for a 1.0 release out of the Trello backlog, and moved them to Done, so I’m happy to launch the project today!

Teaching Training

Girl Develop It Class: Intro to Swift and iOS Development

I had the honor of teaching a class for Girl Develop It (GDI)’s Austin chapter this past weekend. Many thanks to GE for sponsoring the class with meeting space – we had a great space to work and learn in.

I made slides using GDI’s template, which you can view at:

You can also use, modify, or improve my slides – they are open source (using Reveal.js), and available in this repo:

Improvements are always welcome!

I hope everyone taking the class enjoyed it as much as I enjoyed teaching it.

iOS Development Teaching UT Austin

Intro to iOS Development: Part Way through the 2017 Fall Semester

I thought I would drop an update here on my Intro to Swift class at the University of Texas at Austin – this is the fifth time that I’ve taught the class (two years in Objective-C, this will be the third year with Swift). This year has been a lot smoother than previous years because I’m using Apple’s App Development with Swift e-book as a learning resource for the class.

Note – I didn’t really like the confusingly titled “Intro to App Development with Swift” book because it focused too much on strange Xcode playground exercises, and didn’t really get into mobile app development as quickly as I liked.

This year, I’m also focusing on more group exercises in class. Last year, the FDA issued a call for a design for an opoid overdose prevention app that we used as the basis for a design exercise in class – it was extremely topical. I’d like to find something similar for class as well.

Another big change for this semester is that class is now one 3 hour class per week, rather than two one and a half hour classes per week. I’ve found that there is a lot more time to focus on class with this longer format, plus I can split up classes more effectively if we can do review plus learning in the first half, and then exercises, labs, or reinforcement in the second half.

As always, this class is changing – it’s an introduction to programming class for students who aren’t programmers, so I really enjoy teaching it. The challenge is trying to figure out how to make these concepts approachable and to really teach the “How” behind iOS development, not just the “Follow this tutorial”.

iOS Development MapRhino

MapRhino 1.0.5 Released – Now with route support on the iPad

One of the frequent feature requests I got for my iOS app MapRhino (Listing on the App Store) was to add the route to the view that the kids get.

MapRhino is an app for parents in the front seat of the car to share where they are going with kids in the back seat of the car. The kids’ iPads will show where they are on a map, show the car moving as it goes, and how long it will take to get there!

What the iPads didn’t show before was the route on the kid’s iPads. The app uses two different mapping technologies – Apple’s MapKit, and MapBox’s maps. The routes aren’t directly compatible between the two, and the data also has to be serialized, sent over a multipeer connectivity broadcast, and then deserialized on the iPads. I learned more about MKMapPoint and coordinates than I really needed to know, and had to do a C-style malloc for an array – yay for sticking with Objective-C on this app so far.

I added the feature over the course of an afternoon, tested it out, and it works pretty well. Hopefully more users will like it too!