The panelists interview Josh Brown about teaching other to build iOS applications and using Swift.

 

Hey everybody and welcome to episode 74 of the iPhreaks Show. This week on our panel we have Andrew Madsen.

Hi, from Los Angeles.

Alondo Brewington.

Hello, from North Carolina.

Pete Hodgson.

Hello, from San Francisco.

I'm Charles Max Wood from DevChat.tv and this week we have a special guest, Josh Brown.

Hello, from Indianapolis!

Indianapolis, huh?

Yeah, my family’s here, so that’s what brought me here.

Makes sense. I've actually been to Indiana once.

Anyway, we brought you on to day to talk about teaching other people to build iOS apps and teaching Swift. I'm assuming you have some experience with that?

Some, but not a whole lot as I'm sure you can imagine.

[Chuckles] So you want to give us a brief introduction of who you are and what you're about?

Sure. Again, I'm Josh Brown. I've been doing iOS development for almost five years now and most of that with Objective-C as I'm sure you know.

I've been doing Swift since it came out. When they announced it at WWDC, I was just really excited about this new language to go out and learn and teach other people. I guess that’s me in a nutshell.

Awesome. So have you been teaching other people to build iOS?

I've been teaching people for about a year now. I started teaching one-day workshops here in Indianapolis last August, I believe. I've taught a few of those locally, and now I've been teaching some online as well. So yeah, a little over a year of teaching it, I guess.

Who are the kinds of people who sign up for these classes? Are they people who are new? I've always wondered this. Are they people who are new to programming in general, or does it tend to be people who are already experienced in some other technology, but they just want to learn how to build an iPhone app, or iPad app or whatever?

It really varies from person to person as I'm sure you can guess, but we've had people in our classes who are designers, who are other technology people but not necessarily developers, and then of course we've had a whole lot of developers, so the vast majority are already developers who just want to learn how to do iOS development and build apps.

I guess there must be a difference in the way that you teach iOS for someone who already knows how to write software but just not Objective-C or Swift or whatever, versus someone who doesn’t know what a for loop is or doesn’t know what a variable is.

Right. My classes have mostly been focused on teaching people who already know how to do development, so the designer who came and other people – they came in with the understanding that this was for developers and we’re not going to cover the basics of programming with for loops and conditionals and whatnot.

Gotcha. Makes sense.

Mm-hm.

So what is the format of this? Is this like a single-day or a multi-day course structure for these [inaudible 03:46]?

We started teaching half-day workshops, and then found that that just wasn’t long enough to cover even the very basic foundation of iOS development. That extended into a full day, so now it’s fullday, and they're online so I just use some online meeting software. We meet online, people join and then they can jump in and ask questions. It’s still a live workshop, but it just happens online now.

How do you like the online format as opposed to being in person? Does it present challenges?

Oh yeah, absolutely, like technical challenges, for one. I had a lot of technical issues with just different meeting software and trying to figure out what works best.

There's also the challenge of not being able to look around the classroom and see, “Are people getting this? Do they understand? Am I going way too fast? Are they bored?” Those sorts of things I can’t really get with an online class, so it is definitely more challenging.

Are you using any tools that allow users to sort of do the raise-their-hand function, for instance, inside of a certain meeting software program to allow you to do that? It’s not ideal, but it does give you some sort of optional [inaudible 04:59].

I find it, in the past, when I've done it with workshops that the students have been over hesitant to do that for fear of interrupting their classwork.

Yeah, I haven’t tried that. What I've done is just told people – they're on audio and they can talk, they can jump in at any time and kind of interrupt. I've told people that they're free to do that. Some people are comfortable doing that; others, I think, aren’t so it just depends. But yeah, that solution sounds like a good one.

One of the challenges I've had with trying to do workshops in the past is getting people to have all of the stuff they need on their computers. You might need Xcode, for example. Have you figured out any cunning tricks that you can share to make my life easier in terms of getting everyone set up the same way before the class rather than spending an hour at the beginning of the class, kind of futzing around, downloading 2Gb Xcode images?

What I've done is basically – I email everyone before the class and tell them all of the things that they need to do to get prepared. One is downloading Xcode and another is downloading the meeting software – things like that. I try to make sure that people know in advance that, “You need to have this stuff, because we’re going to be writing in Xcode right away, so you need to have it downloaded beforehand.” I also tell people to show up 15 minutes early so that we can work out any sound issues or technical issues, or if they have a fast connection hopefully they can download Xcode in that time – things like that.

When I've done it with different technologies, I've just made a virtual machine image and just put everything on there to make sure everyone’s got the same setup, but it’s hard to do that with Macs because you can’t – Xcode is not something you can install on a Ubuntu VM, for example.

Right. Well luckily for me, teaching iOS – basically you just need Xcode installed. That’s the only real thing, environment set up. It’s just one thing to install, at least.

Yeah.

So I'm kinda curious – what kind of backgrounds do you get then? If you're looking for people who are developers, do you get web developers? Do you get desktop developers, backend developers, utility – Linus utility developers, embedded system developers? I mean, there are all kinds of people, right?

Right. Mostly it’s been web developers and backend developers, so people who have backgrounds in Java, C#, Ruby on Rails, JavaScript – those are kind of the big groups of people that come to these workshops.

And how proficient can you get in a single day of training?

Well, we start with the basics of course, and we build an app that does networking, JSON, Table Views. We talk about View Controllers and the App Delegate, and the application life cycle. There's a good bit of foundation stuff that you just need to know for pretty much every app, so that's what we cover.

Gotcha.

I'm curious to know what the motivations for these people are, mostly. Why are they interested in starting iOS development, as opposed to whatever it is that they do normally? Is there a broad range? Do you see a lot of people that are kind of getting into it because they're doing enterprise development, or they want to strike it big in the App Store? What do you find?

Yeah, those two things, I think, basically. One is people who want a new job. They're bored with what they're doing, for one reason or another; they want to get out of it, they want to go do iOS apps for their job. The other type of person is the type who wants to strike it rich on the App Store, or just build an app. Sometimes they just want to build it as a side project, as a hobby, so they take the class and learn the basics so that they can go build their side project. It’s a little bit of both.

Okay, I guess that’s to be expected. I wonder though, because I think there are a lot of people, of course, with no knowledge of the market, that have unrealistic expectations like you build a decent app and now you're rich. Hopefully real developers don’t have that delusion.

Yeah.

Or they're already rich.

Yeah, or that.

Or they had the delusion and had since lost it.

Right.

So where do you find people struggle if they're not already an iOS developer?

I think part of it is the frameworks. There are tons of them, and probably a lot of us take those for granted. We know UIKit for the most part and we know some of the other frameworks, foundation, et cetera, but people who are just getting started don’t know anything about UIKit. They don’t know the View Controller life cycle; the ViewDidLoad, ViewWillAppear, ViewDidAppear – all these methods – and so people get overwhelmed really quickly with those sorts of things, that again, those of us who have been doing this for a while just sort of take this for granted and think they're easy.

BrainDidOverload.

Yeah, yeah. So I think it’s mostly the frameworks that people find difficult. Nobody likes Objective-C who takes my classes; they all hate it and wish that they didn’t have to do it, and now with Swift, they don’t.

But really, what takes the longest to learn for people is those frameworks – all the Cocoa Touch frameworks.

Have you found that the access to the playgrounds in Swift – have they made that learning curve a little bit less steep?

I think for learning Swift, the language, they have, but I think a lot of people don’t use the playgrounds for learning their frameworks and learning the UIViewController life cycle and things like that. I think, for the most part, people – to learn, those people need to build apps even if they're just basic, simple apps.

And in your experience, is that where most of the challenge is, or most of the work is in learning the frameworks rather than learning the language itself be it Swift or Objective-C?

Yeah, I think so. I really think there are just so many frameworks and so many APIs in Cocoa Touch that that’s what people struggle with the most. People can pick up the language pretty quickly and easily at first and write some actual code, but then they don’t know where to put it and so that’s where people struggle.

Since you’ve been teaching people this stuff with Swift rather than Objective-C, have you noticed that there's a problem with the mismatch between the APIs and the language? Because it feels like – I mean, obviously all of the Cocoa APIs were built for an Objective-C language and so they don’t line up particularly well with Swift as a language. Is that a challenge when new people come into the ecosystem where they kind of – there's this cognitive distance between the Swift style of programming and the Objective-C APIs?

Yeah, I definitely think so. One of the big ones is optionals. Especially people who haven’t used optionals in another language before, they just don’t really get, “What does this exclamation point mean? Why do I have to put a question mark here?” Things like that. It seems like you have to do a lot of that when using the Cocoa Touch frameworks with Swift.

Yeah, it’s kind of a shame because I definitely really like the fact that there are optionals in the language, but the reason for them being valuable is because they push out the null checks to the edge of your system and then once you’ve don’t that null-checking you don’t have to do it anymore. But once with all of the APIs also potentially producing null objects, you find yourself having to use optionals everywhere because you can’t push it out just to the boundaries of the system.

It’s kind of a shame that one of this – this is a really nice feature, the language, but I think a lot of Objective-C developers, or a lot of developers in general, are going to get quite frustrated with this feature because it actually gets in your way quite a lot while these APIs are still nilling.

Yeah, absolutely. Mm-hm.

I guess it will improve over time.

But overall, has Swift made teaching iOS easier or harder?

I think it’s made it a lot easier because part of the workshop that I taught before was just on the Objective-C syntax. Sure, I have to teach the Swift syntax now, but the Objective-C syntax is just so weird for people. People call it arcane; it’s just like with the square brackets everywhere. People just really don’t get it: minus and plus signs, the @ signs – there's all this strange stuff about Objective-C that other languages don’t really have.

Swift, too – when you go to Swift, you use dot notation like you’ve used in other languages. You use parenthesis to call methods like you’ve used in other languages. I think Swift is just a lot more natural to use as far as the syntax goes.

Somebody and I were having this discussion over the weekend, and he said he thinks Swift will really help people that are starting out with iOS, that it’ll be a lot lower barrier to entry to get into it. I sort of disagreed at first, because I think – what we were talking about earlier – that the frameworks are actually the hard thing to learn. But it sounds like you are saying that just the syntax differences, which, in my mind are sort of superficial, are a pretty big barrier to some people.

Yeah, I really think they are. A lot of people complain about those a whole lot, so I do think that’s a big deal.

I think also the blocks – I don’t know. I imagine the blocks syntax is also just really, really hard to wrap your head around.

Mm-hm.

Or at least it is for me. I still can never remember how to write the type signature for a block; I just end up typing in random characters until it compiles.

[Chuckling] Right. Yeah.

That’s actually most of my development techniques, so.

Mash on the keyboard [chuckling].

To press keyboard with face.

But I feel exactly the same way about the block syntax, and teaching it to people still hasn’t – it’s still not ingrained in me. I still have to go look it up with that one site I'm sure you know about. But that’s not such an issue in Swift. Blocks or closures are just much simpler; the syntax is much simpler.

I mean, you’ve got the type inference as well so you don’t have to remember the type signature [inaudible 15:17] in a lot of the cases.

It’s GoshDarnBlockSyntax.com.

Yes. [Laughter] Thank you.

There's another similar problem I've seen with people picking up Objective-C in the post-ARC era, which is –. Sorry, the ARC era – not the pre-ARC era. It feels to me like ARC is this leaky abstraction where, yes, it does the release/retain stuff for you but you still need to understand how that release/retain mechanism works because of things like blocks and weak holding onto self and all that kind of stuff.

When you're teaching these classes, have you found that you need to spend time explaining that stuff or you can get away with not really understanding what was going on behind the curtain, as it were?

That’s something that we don’t really cover in the class, because it’s just over their head; it’s kind of out-of-scope for the one day. But yeah, definitely something that even I still kind of struggle with myself in development.

So where do you start? Do you start with the language, or do you start with the way that iOS works?

We start with Hello World. My goal for the class is for people to be engaged right away, so I don’t want to start with a lecture about how things work in iOS or anything like that.

We just jump in and write a Hello World app. We drag some labels onto the screen and do some connections to the code and interface builder and things like that. And then we kind of pull back and look at it and talk about, “Okay, what's going on here?” We talk about the App Delegate life cycle and the View Controller life cycle and things like that. Then we go on to building an actual app that pulls JSON from the iTunes API and list the books and movies – the top books and movies – and things like that. That’s kind of the structure of the class.

You know I really think that’s a great way to keep people engaged and get small wins along the way so they don’t feel intimidated. I know a lecture would be pretty daunting on the outset.

Mm-hm. I don’t want to be up there lecturing; I want people to be sitting behind their computers and actually writing code, because I think that's the best way to learn it, is to actually write it and practice, learning how to type this stuff, how to do the syntax and things like that. I want people on their keyboards, typing as much as possible.

So what type of feedback have you gotten? Have you gotten – former students have come back and wanted to showcase an app that they’ve been particularly proud of, or just said that you’ve made it so much easier for them to pick up iOS development?

Yeah, one guy told me – and this was the best feedback I ever got. He said that after building this books and movies app that we do that pulls the data from the iTunes API, he said he felt like he could go out and build any app now, because he knows how to do Table Views, he knows how to parse JSON, and he knows how to do networking. And that lets you, as he said, build a huge number of possible apps because you can do so much with just those few things.

That’s true.

And you guys talked about the mechanics of getting stuff into the App Store and things that are not going to get you through the review process and that kind of thing?

That’s another thing that we don’t cover, although I've had feedback from people that said they would like to cover that. There's just not enough time in a day to cover that; that's something that –. Sometimes I've sent out and email afterwards and said, “Here’s how you get into the App Store and here’s the app review guidelines” and things like that, but it’s to something that we covered during the one-day workshop.

Gotcha. Yeah, I can imagine it’s a real challenge to figure out what to pair [inaudible 18:51]. There's a lot of stuff that you can learn about this, so squeezing it into a short period of time would be a challenge.

Mm-hm, absolutely.

You'd definitely dampen the excitement of building a new app when you have to deal with provisioning profiles. [Laughter]

Well that’s why I don’t cover it in the workshop [chuckles] [crosstalk 19:10]

I feel like I could go to a one-day workshop just to explain provisioning profiles; that would be helpful for me.

Oh, yeah.

Well maybe that wouldn’t be enough time to cover it properly [chuckling]. I guess the challenge is not spending all the time talking about everything, but at least planting the seed in people’s heads so they know that there's this thing that you're going to have to do before you release.

There's this thing called Memory Management – don’t worry about it right now, but be aware of it because at some point you're going to need to come back to this and learn some more.

Yeah.

Have you considered doing a follow on workshop, kind of an intermediate iOS rather than beginners’ iOS?

Yeah, I have actually. I don’t know what topic I would talk about because there are so many. There are so many intermediate things that we could discuss.

One of the things that I do after the workshop is I offer a four-week – I call it an exercise program – that people can take. I send assignments every week, at the beginning of the week; they work on them and then they can come to office hours and ask me questions at the end of the week. People, at least that way, get a little bit more experience; four more weeks of writing iOS code and building another app and things like that. It’s probably still beginner level, but it’s getting closer to the intermediate level there.

You sounded like you do some of these in person and some of them online. What are the advantages or disadvantages of doing it one way or the other?

The advantage to me of doing it online is that I can reach people anywhere and I've had people take my classes in California, in Minnesota and all over the US, at least. That's one big advantage that’s great for me, because then it’s easier for me to sell the tickets and communicate about it and things like that.

Doing it in person – I haven’t really actually done it in person for almost a year now, and I'm not sure that I will again just because it’s so hard to reach people locally. I guess I just don’t know how to do that, and I find it easier to reach people online through my blog posts and things like that – Twitter, et cetera.

So going back to the Swift aspects of this, have you been seeing a lot of challenges with bugs and with people learning and they don’t really know something’s not working because it’s a bug or because they're using the language wrong?

That’s something I noticed when I was helping some people learn iOS and Swift at the same time. It was early on when Xcode was definitely very buggy in terms of the Swift support, and there were a lot of cases where something wouldn’t compile, or something wasn’t – the syntax wasn’t right, but it was really hard for people to understand whether the syntax was wrong or whether Xcode was just having a freakout.

Yeah. I didn’t teach Swift in my workshop other than kind of a brief overview – more like a lecturestyle – until it was out of Beta, because I didn’t want to worry about that sort of thing. People who are new to this, you're right – they don’t know if they got the syntax wrong, if there's a bug in Xcode or whatever, so I made sure that we’re just going to do Objective-C in the workshop until Swift is out of beta, and that helped a little bit with those sorts of issues. But still then people had syntax errors in Objective-C that we had to figure out.

So what kind of questions do you get during your office hours? I'm assuming, since the main event is one day, you have it pretty well-set. “Here’s what we’re going to get through and here’s what we’re not going to get through.” What do people run into after the fact?

The assignments are basically to build a Twitter app, and so as they're going through these, people just don’t know, “Where do I go? Where do I look to find how to do this? How do I fetch tweets from Twitter, et cetera?” They just don’t know still where to look for these sorts of things.

Sometimes, they're able to Google it; sometimes they're not. But those are the things I think people still sort of struggle with, like “Where do I go to find good information about how to do x in iOS?”

That makes sense.

So what are some of those resources that you point them to? Is there some kind of canonical thing that you suggest everyone to go to first?

Well, I always recommend that people look in the docs – the Apple docs – right inside of Xcode, because I found that those are really great at explaining what happens when you call a method or how to use a class or things like that. So I always, always, always tell people, “Go look in the docs first. If you can’t find it there, Google’s fine.”

I also like Ray Winderlich’s tutorials. Those are really good for doing very specific things and figuring out how to do those, so I send people there as well. I think those are the main things that I recommend.

Is there something in Swift that you think they should add or remove to make it easier for a beginner to learn the language? I think you probably have an interest in perspective, having seen a lot of people go through that learning curve.

Again, I think the thing that I see people struggle with the most is optionals. I don’t know if they can do something about that, but I guess maybe reworking some of the APIs – at least some of the common ones – so that they're easier to call from Swift, maybe really writing some of those in Swift or just making them, again, easier to call from Swift. I think that would help new people a lot.

If people didn’t have to see all these exclamation points and question marks and things, then I

think they'd be better off and be able to jump into it a little more easily, a little more quickly.

Interesting. It’s a tough, bootstrapping problem. I think – and I already said this, I guess – optionals are a great feature, but it’s tough to get people excited about it when they get in your way at first.

And [crosstalk 24:50] those APIs.

Mm-hm. There was a tweet that I saw the other day that said – it was about Swift, and someone was stuck. It said, “Have you tried adding or removing question marks or exclamation points? Just go ahead and try this. Try adding them, removing them; maybe it’ll work.” And I think a lot of beginners, that’s kind of what they do. They just, “Well, this doesn’t work; I’ll add or remove a question mark or exclamation point.”

Have you done any teaching of just Swift to people who already do iOS development?

A little bit. I do some mentoring, some one-on-one mentoring, as well. So yeah, I guess I've done a

little bit of that, too.

How was that different from teaching people who are new to iOS development, how to do it?

That’s easier, again because they already know the frameworks. People who have done ObjectiveC know the Cocoa Touch framework; it’s just a matter of calling them in a different language. People don’t really struggle with that. There's a little bit of syntax change and things that people find strange, but again, that’s a lot easier for them to get than it is for a new person to pick up all these frameworks.

It’s actually kind of surprising to me. I guess it’s not surprising, overall, including the frameworks, but I had this kind of assumption that it’s actually easier for someone who doesn’t have the baggage of wanting things to –. The existing mental framework of Objective-C, I kind of assumed that would actually get in the way of picking up Swift because you kind of just want it to work the way Objective-C works, particularly that stuff around optionals.

Right.

I guess just understanding some of the concepts of blocks and stuff helps you learn Swift?

Yeah, absolutely. If you know what a block is in Objective-C, and maybe you have to go look up the syntax, what I found that in my two, three months of doing Swift, I don’t have to go look up the block syntax or the closure syntax for Swift. When there's a block, I know how to do it in Swift. Versus Objective-C, again, how many years after blocks were introduced, I'm still looking up the syntax.

Yeah. Have you had people who are learning Swift and coming in from a different language, have you noticed their specific languages that people compare it to? Because I've heard a lot of people say, Scala or JavaScript, or I think Rust was one that kept on coming up for some people.

Do you see similar analogies, or are there other analogies people make?

Yeah, absolutely. Those come up a lot, and especially Scala, I think. I did a very little bit of Scala back a couple of years ago, and to me, Swift looks a lot like it, so I think that’s a big one, and one that other people have confirmed as well.

Yeah, I definitely –. By coincidence, having been done a lot of Scala in the last couple of years, definitely there are some very familiar parts of Swift. Luckily, it isn’t the ridiculously huge language that Scala is. I think we dodged [crosstalk 27:42].

Right.

Well that would have taken them a lot longer to build it if they had as many language features in Scala.

Alright, so I've got like a dozen questions now. I'm kind of curious about the day-long format, and if it can be adapted to some of the technologies that I know a little bit better than iOS, that I could do the same kind of thing with.

For me it was just like, starting with figuring out what do people really need to know about iOS in order to build apps. The first workshop was awful, actually, just because we didn’t really know what to teach people, I guess – what people needed to know about iOS.

22] come up and hook them up, but we didn’t –. I guess part of the issue with it was we didn’t end with anything substantial. People ended with this Hello World app that looked like a Hello World app with controls all over the place, and it didn’t really do a whole lot.

So I think building something practical, at least in my experience, that has been much better than just trying to teach stuff and doing some simple Hello World.

Did they take more than one workshop to sort of ferret that out and figure out what was going to work?

Yeah. After the first one, we kind of rehashed. For a while, I was teaching this with another guy, a business partner. He and I, after the first one, just talked about, “Okay, what did people like? What did they not like?” We made sure to ask for feedback and got a lot of feedback from the ten people who took that first class.

Based on that feedback and our thoughts, we decided to redo it and actually build an app in the class rather than build some Hello World.

I'm kind of curious – it doesn’t say on here how much it costs.

Mm-hm, it’s $499 for the one-day workshop, and then there's an additional $150 for the four-week exercise program.

Okay. And I guess it makes sense if you're teaching other developers. It seems like half the people I'm talking to have not coded anything ever in their life.

Yeah, that’s [crosstalk 29:44].

So to teach them, like if I wanted to do a Rails course, which is kind of where I'm thinking, I have to teach them HTML and CSS an JavaScript and Ruby.

Yeah, right. That’s a multiple-day thing, it seems like.

Yeah, but if I just assumed that they understood the generalities of the web technologies, and I could probably do a day and then do the same structure.

Mm-hm, yeah.

I might just totally swipe this.

Yeah, okay.

Oh it is – it does say it right here. [Crosstalk 30:11] price of $499.

The price is on there. It’s – yeah. I want people to read the whole page before they see it. A lot of people just scan for the price; I want people to read the page, what it’s all about, before they try to make a decision based on price.

Yeah. So how do you market it? How do you get the word out about it?

That’s the hardest part of teaching, in my opinion – at least teaching on my own. Basically, it’s all email.

I took a class called 30x500. Are you familiar?

Mm-hm. Amy Hoy.

Yup, okay. I took that and learned a ton. I mean, it was a really, really great class. From that, I learned to – well that’s how I came up with that marketing page; that’s how I've come up with ideas for things to write about on the blog, and then the blog has drawn more subscribers to my newsletter. And then through the newsletter, every couple of months or so, I send out a few emails and launch this workshop again, so that’s the main way that I market this.

I don’t really even try to sell tickets to people on Twitter or anywhere else; it’s just all – basically, if you're on the mailing list, you can buy a ticket. Otherwise, it’s going to be hard for you to find out how to get one.

Yeah, that makes sense.

It’s not that I'm trying to exclude people; it’s just I've – in the previous workshops, posting on Twitter and things like that haven’t sold any tickets, so I don’t find any reason to spend my energy there.

I have recorded the bootcamp in the past that I teach, and at one point I sold that to people on the mailing list. If they couldn’t make it to the bootcamp, they could buy the recording and watch it and learn the basics that way.

I'd almost rather continued doing that, and then just sell that, or even give it away for free, but then teach people the more intermediate or advanced topics in iOS.

Yeah, it seems like there's a lot more content or a lot more content out there for beginners.

Yup.

Anyway, lots of stuff to brainstorm. We should ask, where do people go to sign up for your course?

They can go to roadfiresoftware.com – that’s my website. R-O-A-D-F-I-R-E-software (dot) com, and then you can click on the Learn iOS link at the top.

So wait, what's the origin of Roadfire as a name?

[Chuckles] Great question [chuckling].

Hey, asphalt burns!

Yeah, I had this weird mental image as you –.

Yeah, it sounds strange in English. It’s actually from a Thai word, and the Thai word is Rt_hf_, and it means “train.”

I lived in Thailand for a year and I like trains, so I like the word Rt_hf_ and sort of translated it into English – or transliterated it, I guess, is the word, and it’s Roadfire. So that’s where it comes from.

I was so going to say it was Thai [chuckles]. Alright.

I'm having Thai food for lunch in 10 minutes’ time.

Ugh, jealous.

No roadfires. And roadfire – I think it’s hilarious that roadfire.com was already taken so you had to use roadfiresoftware.

Yeah, yeah.

Oh, wow! Roadfire.com is an awesome website! [Chuckling] Oh my gosh!

Now people are going to go to it and get rick-rolled or something.

Yup [chuckles].

Oh, this is great. This is my pick! [Chuckling]

It’s all Pete’s fault. Alright, well let’s go ahead and do some picks. Pete, do you want to give us some picks?

[Chuckling] My first pick is roadfire.com, which is just an awesome Internet experience. Things like this – I love living in a connected world, is all I can say [laughter]. I love seeing insights into other cultures that I would always not get if it wasn’t for the glory of the World Wide Web, so that’s going to be my pick number one, is roadfire.

I keep on rebuilding this same application over and over again, it’s kind of like my coding kata kind of thing. So bus is the public transit system, or one of the public transit systems in the Bay Area; it’s a Bay Area Rapid Transit. It’s also a subway. And I have just recently built yet another BART – when’s my next BART train coming – application, and it is NXTBRT.com. NeXT BaRT, but without any vowels. NXTBRT.com.

In my usual shameless self-promotion style, I'm going to pick that. It’s free; it does one thing. Hopefully it does it really well. I mean, you would like people to use it and then give me feedback as to what they wanted to do other than the very simple things it does right now.

Freeze Dried Ice Cream Sandwiches. I had these a while ago; I'd never had a Freeze Dried Ice Cream Sandwich before. It is a marvel of modern technology, the likes of which I had never had before. So if you’ve never had a Freeze Dried Ice Cream Sandwich, I recommend you try a Freeze Dried Ice Cream Sandwich. Those are my picks.

Alright. Alondo, what are your picks?

Two picks this week. My first pick is a nice tutorial on UIKit Dynamics and CollectionViews. Something that came in handy this week; I started implementing one of the – a little bit of UIKit Dynamics into an app I'm currently working on at work. It’s a really good explanation by Ash Furrow, along with a sample project.

And then another project that I'm working on in meatspace is, I've just finished the deck and I'm building patio furniture from pallets. I found a great tutorial on how to do that as well, bit of a DIY patio furniture, and looking forward to get that done this weekend. Those are my two picks.

Alright. Andrew, what are your picks?

I've got two picks also. I actually was at CocoaConf at Las Vegas this past weekend as we record, and I had a great time, and met a lot of cool new people and even learned a few things from sessions. I want to pick CocoaConf, and I guess more generally, pick independent conferences in general.

I think there's two types of conferences – there's WWDC or Google I/O, that kind of thing, and there are the smaller conferences, and they have a completely different feel, and there's a lot of value in going to those small conferences, so highly recommend it.

And then my second pick is App Camp For Girls. I think this has probably been picked before on the show, but the founder of App Camp For Girls was at Cocoa Conf and spoke. I had a chance to talk to her and they're just doing some really cool stuff and she’s a great person. She’s really excited about it, and it got me excited about the things that they're doing.

They're only in Portland, in Seattle, right now but they're looking to expand and doing cool stuff. Those are my picks.

Awesome. I've got a couple of picks. One is – I don’t know how this is going to go over, because I'm going to pick another framework for iOS development. It’s called famo.us, and we talked about it on JavaScript Jabber. The week before, we actually talked about the ionic framework, which is also another JavaScript framework for building iOS apps. So I'm going to pick both of those.

I've also been reading – I read a lot or I listen to a lot of books – and the latest one that I listen to, it’s kind of a fun book. I don’t take them super seriously, but it’s just kind of an easy listening, interesting story. It’s Michael Vey and the Jade dragon. There are three books before it, and basically it’s teenagers with electrical powers is kind of how I describe it. But you know, it’s kind of an interesting and fun story, so yeah, I’ll pick that as well. Yeah, I think that’s all I've got. Josh, what are your picks?

Yeah so I have three picks. The first one is, I know you’ve had this on the show before; this has been a pick, but Functional programming in Swift, the book, by the team at objc.io. For me, it was just an excellent way to get started with functional programming. I haven’t done functional programming before, and so this book was just a really good introduction for me, and taught me some of the basic functional concepts like map filter and reduce.

It’s an excellent book, totally worth the price. I highly recommend that.

My next pick is Parsing JSON in Swift. This is an article by Chris Eidhof, and he talks about how to strongly type JSON parsing in Swift. Some of it is still over my head, but it’s an excellent article and looks like a great approach to parsing JSON and Swift.

My third pick is Error Handling in Swift, which is another article that I read. I really like his approach to error handling there. Instead of returning or passing in an error pointer and things like that and checking that for nil, his functions, he suggests returning a single, generic result type that has either a success or a failure in it, and then that makes it easier to handle switching on success and failure when you get the result back. So a really good article there, too. Those are my picks.

Awesome. Well thanks for coming.

Thank you, thanks for having me.

That was a fun talk and hopefully people are getting some ideas on how they can either better learn or better teach iOS.

Thank you very much!