I’ll be turning some of my UT Austin classes into free courses, so that others can benefit from them. There’s some translation to go from a one-semester upper division undergraduate course to a self-directed free course, so it’s not as easy as just recording lectures.

I also want to turn my attention to finding new ways of working as a remote team that let team members get into deep work. When I’m on remote teams that use Slack, Teams, or Discord as the primary method of communication, I find it difficult to tune out the noise from the problem I’m actively trying to solve. Others I’ve talked to have similar issues.

I also have some fun projects lined up for myself, so it’s not all super serious for the upcoming year. I want to get back into iOS app development for myself, with no focus on commercial projects. The Deep Dish Swift conference in 2023 really sparked my interest in some of the new things people were doing – I’d been out of the loop for quite a while.

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

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.

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.

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) gmail.com. Thanks!

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.

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!

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.

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!

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

https://jefflinwood.github.io/gdi-intro-to-swift/#/

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

https://github.com/jefflinwood/gdi-intro-to-swift

Improvements are always welcome!

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

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”.