Jeff Linwood

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.

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.

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

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.

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!

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.

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!