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.
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 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:
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”.
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!
I just taught a two day in-person corporate training class that was a basic introduction to cloud development and databases for software developers. This class used Amazon Web Services (AWS), MySQL, MongoDB, and Java 8 for the core technologies. We built a microservice web application with the Spark microframework for Java that provided a RESTful HTTP API, and then deployed it to Elastic Beanstalk.
There was also a fair amount of Python, which is always a fun language if everyone knows it.
It’s also always fun to update courses and see what has changed over the course of a year. The biggest changes were to the S3 web interface (switch back to the old interface if you want to remember how it was), and to Elastic Beanstalk’s getting started landing page (which has about three or four different states). Other things barely changed, like MySQL Workbench and Spark Java. Of course, if everything stayed the same, teaching wouldn’t be nearly as much fun!
Austin’s no-kill animal rescue organization, Austin Pets Alive! had the honor of being selected as one of the possible projects for the ATX Hack For Change at St. Edwards University on June 2-4, 2017. My wife Cheri and I ran into one of the organizers at OSCON in early May, and we were able to submit a volunteer recognition app project that APA! needed, but hadn’t developed yet.
Austin Pets Alive! brought a team of hackers (Cheri Linwood, Beth Qiang, Walter Moreira, and myself), along with two dogs (Nimbus and Shorty). Nimbus and Shorty didn’t contribute much in the way of code or ideas, but they did provide puppy power for the hackathon.
As for the technical details – the volunteer recognition app uses Swift for the native mobile app on iOS, and Firebase as the back-end server for everything (Firebase Auth, Storage, Database). Check out the MIT-licensed source code here on my GitHub at https://github.com/jefflinwood/volunteer-recognition-ios. This was the result of about 12 hours of coding over the weekend. One of my big goals was to find a visual designer at the hackathon, but they were few and far between, so I did the visual design myself. Luckily, APA! has pretty strong colors, so that makes up for a lot.
Every year, I get the privilege of teaching a class at the University of Texas at Austin (with Robert Quigley) where the students get to decide what mobile application project they are going to bring to life, and how they are going to design, test, build, and market it! This is a really creative class that is completely team-based around one project. We split the semester up into two to three week sprint cycles, where the students set their goals and give a short status update presentation. We also tell all the students that they have to submit their apps to the Apple App Store by April 1 – in time to get them approved for the big Demo Day at the end of April.
This class combines journalism and computer science majors into small teams. The computer science majors typically do the programming (in Swift), and the journalism majors film and edit videos, do graphical design, blog about their projects, and become active on social media.
I’ll let the students tell the story of what they did through the whole semester – they blog on UT Apps Class Blog
I always look forward to this class – I’m glad so many of our students get a chance to learn how to work on a team and ship a product. Here’s to next year!