The Changelog: Software Development, Open Source - AFNetworking, Helios, iOS Development (Interview)

Episode Date: August 6, 2013

Adam Stacoviak, Andrew Thorp and Kenneth Reitz talk with Mattt Thompson, Mobile Lead at Heroku, about his many contributions to open source.

Welcome back everyone This is The Change Log We're a member supported blog and podcast That covers what's fresh and what's new in open source You can check out the blog at thechangelog.com And our past shows at 5by5.tv Slash changelog This show is hosted by myself, Adam Stachowiak

And also Andrew Thorpe. Andrew, say hello. Yo, yo. Yo, yo, yo. We're also joined today by Kenneth Wrights. Hello there. Hello there. Not a yo, yo.

Yo, yo. Yo, yo. You can tune in live every Tuesday at 5 p.m. Central Standard Time right here on Five by Five. And today is episode number 98. We're joined by Matt Thompson. Matt is the mobile lead of Heroku. A lot of Heroku up here today. He's the creator of AF Networking, which we just mentioned in the

pre-show, and is hipster, Helios, Postgres app, and the list literally goes on and on. So Matt, welcome to the show. Well, hello, everybody. Thank you so much for having me on. Yeah, man, absolutely. So let's get started with how you got started in open source. Ooh, open source. You know, I really started diving into that with the Objective-C community. When I was working at Gowalla, I found that a lot of the stuff that I was working on, you know, it started to actually be generally useful. I think that's when I really, you know, started to pick up with everything. So AF Networking, for instance, came out as a project that we were using for Gowalla for iPhone.

And it was general purpose enough that we thought that other people would like it. And from there, it just kind of took on a life of its own. Yeah, so just wanted to give a quick rest in peace to Guala. I think that was an app that most of us loved and were sad to see it go. I really miss it. I had my whole life on there for two years. The whole passport, all the stamps that you had. It really told a story about every day that you went out and explored the world.

Yeah, it's something I definitely miss. I literally remembered driving when he and I went to Oklahoma City one time for a conference. We were on our way back. We were driving back. We had to stop somewhere. I forget where we had to stop and why we had to stop there, but he had to drop a pin or something like that. It was all about Gowalla.

He used to do a lot of Gowalla stuff, right? Didn't he reverse engineer their API? Yeah. He's a big Gowalla fan. I just remember Gowalla having a big presence in the early version of the changelog. It seemed like it. Yeah, absolutely. Definitely. Speaking of Gowalla, we have the big presence in the early version of the changelog it seemed like it yeah absolutely definitely so

so uh speaking of guala we have the af networking kind of is the main project we wanted to talk about here um it's a common thing that we've noticed in the last for some reason in the last you know i don't know five or six shows we've talked about like for-profit companies that have released um you know pieces of the company in open source, and AF networking is one of those things. Probably one of the questions I wanted to ask you right off the bat, Matt, is what is the AF in AF networking? Sure. So AF stands for Alamo Fire, which was the old name of Gowalla. So before Gowalla did what it did, it was a mobile games company. One of the projects was Pack Rat, which was the old name of Gowalla. So before Gowalla did what it did, it was a mobile games company.

Did some things called, one of the projects was Pack Rat, which was a, it's actually, you can still play it on Facebook. It got bought by another company. So it's a collectible trading game, really addictive, a lot of fun. And they also did Icon Buffet,

which was a social network based around collecting iconography. So little images of different themes. It was a social network based around collecting iconography. So little images of different themes. It was a really neat company. I mean, I joined Gowalla after being a fan of Alamofire for many, many years. It was sort of a dream come true. I'd been following their work for a long time. And so it was really humbling to get there and to be part of the team.

Yeah, really, really cool stuff. Again, miss it every day. I love how there's the Alamo in the logo, too. Oh, yeah, that's actually kind of repurposed from the Alamo Fire logo itself. The Alamo Fire, of course, is the official state flower of Texas. No, sorry, is it the blue belt? Either way, it's one of the important flowers of Texas. So I wanted to kind of mention that because you went from Alamo Fire to, or you didn't specifically, but the chain of Alamo Fire to Gowalla, and now you're at Heroku.

And so we have you and Kenneth both from Heroku. So Heroku isn't itself open source, so why don't you guys give us kind of an insight into Heroku and how you guys do what you do and how you guys work together and those things sure kenneth would you like to uh how much work do you would you say that we do together matt oh we cross paths we sort of have parallel tracks you know i think our stories are quite curious in that respect yeah we both we're both uh well known for doing http libraries for our respective languages. And we do a bit of evangelism. But besides that, I think we're kind of in silos, right? It's a shame. But, yeah, I mean, spiritually, I think we're kind of playing off one another.

I feel the vibes all the time. Absolutely. It's kind of cosmic intellectual bebop is what happens at Heroku. That's fantastic. Cool. So AF networking has nothing to happens at Heroku. That's fantastic. Cool. So AF networking has nothing to do with Heroku. This is something you maintain separately from Heroku in your spare time, is that right? Absolutely. I mean, it's interesting, though. I mean, my role at Heroku is to increase the

number of mobile developers on the platform. And a great way of doing that is increasing the absolute number of mobile developers. I'm very confident that Heroku provides a great way of doing that is increasing the absolute number of mobile developers. I'm very confident that Heroku provides a great development experience and people choose it because it's the best tool for their job. So getting the absolute number of developers out there who are making apps on iPhone, for instance, and most iOS apps consuming a web service in some respect, as far as AF networking enabling people to do that, I think that grows the business pretty directly. I assume we're going to be touching Helios as well, right? Sure. That's another piece of the equation. Yeah. Why don't you kind of elaborate on that a little bit for us to get started? Sure. So, again, kind of taking things a step back, when we talk about mobile, it's sort of this complicated, nuanced word that's become kind of a buzzword and poorly understood.

In a lot of ways, it's sort of a conflation of a lot of ideas. The idea that technology is more ubiquitous than ever and will become increasingly so. That we are dealing with different kinds of screen resolutions and different ways of presenting the same information in some common format. And again, when we're talking about mobile applications on these platforms, whether that's hybrid or native, we're talking about a client-server architecture. And increasingly, when you're developing for the web, that's sort of a rich client experience as well. You're connecting through a JSON API. You're making requests over HTTP. So actually, the whole architecture, the whole technology stack behind all of this is no different than the way that we're developing modern web applications. So mobile really isn't a different way of doing things. It's just focusing on the client.

So part of focusing on the client is that you're choosing to spend your time to polish that user experience, right? You're learning Objective-C, you're learning Cocoa and all of the tricks to make your application stand out. And that means that you don't have a lot of time or really desire to kind of spin cycles on figuring out sort of the plumbing of REST web services for push notifications, that sort of thing. And that's where Helios comes in. Helios is an open source extensible backend as a service, mobile backend as a service. And it's specifically focused on iOS right now because that's kind of the best place to start and the place where I'm most comfortable. But it's something that can extend and be used for rich web clients and Android

and pretty much anything else. So Helios is, if I'm not mistaken, it's built on top of Rack, is that correct? It is. Rack is actually one of my favorite architectures. You know, Sinatra also is one of my favorite things in Ruby, but Rack, the way that it can be composed, you know, a complex application into component parts that are each kind of modular, just ruthlessly modularized. I really like the approach of that.

So coming at it as a Rubyist, it seemed like a natural fit. So you said you came at it as a Rubyist. When would you say you made the transition from a full-time Rubyist to a full-time Objective-C guy? Let's see. So that was my first job out of college was at a company called Cerego. At the time, it was known as Smart FM or alternatively, iKnow. It was for language learning, Japanese speakers learning English. That was in Tokyo. companies do and did, especially back then, we wanted to make a mobile app. And somehow, you know, doing some past experimentations on Mac development, I found myself kind of inheriting that project. And eventually that's what I used to, you know, get my foot in the door at Gowalla. So that's when I started. That was about maybe four years ago.

Cool. So Helios kind of takes parts of what you loved about Ruby and also is built for some of the iOS Objective-C stuff. How does Helios and AF Networking work together, or do they? What's that relationship look like? Well, AF Networking is sort of the bread and butter when it comes to making HTTP requests. But there's a layer on top of that. It's a project called AF Incremental Store, which is kind of under the umbrella of AF networking as a technology. And AF Incremental Store combines AF networking with core data. And the idea is that you don't write networking code anymore. It just automatically translates the requests that you would make or any faults or

fetch requests that you'd make in core data to HTTP transparently and asynchronously, and then kind of load everything in the background. So it's a way to develop, you know, core data. It's an object, it's a graph persistence framework, sort of like an ORM, like active record. That's a good way to think about it. And if you can imagine, instead of it talking to a database, what it did is that it, well, consults a local cache to return stuff quickly and synchronously.

But then also in the background, it's going to query this web service. So mapping fetches to gets, creates to posts, that sort of thing. I assume it's using standard HTTP headers for that? Absolutely. It's building on standards. It's using headers in a cache-efficient way. Fantastic. It's a really cool framework. Would you recommend, if somebody were going and deciding they want to kind of get into mobile, would you recommend

Helios as a kind of a place to start? Helios, I think, is a great place to start if you are looking to build, you know, get up started very quickly. So those data services, again, just to kind of expand on that. So anti-fincremental store, building on top of core data. If you're using core data and starting kind of from the client, you can actually link your core data model to Helios, and it will automatically generate those REST web services for you. So that means that you have a server talking directly to your client, and you don't have to stub anything out, and you don't have to implement that later.

The plumbing is taken care of for you, and you can begin to develop a real application. So in that respect, it's really great. It's other components, it's other services, like push notification registration, like logging and analytics, like newsstand or passbook integration. Those are things that can kind of live alongside a more developed application, even as your application grows and probably gets out of the realm of basic CRUD responsibilities. So a Sinatra or a Rails application, you can keep

those backend services around a little bit longer. So yeah, it's a great place to start, especially if you're not as familiar or comfortable with web service development. Even if you're not a Rubyist, the code that it generates is rather friendly, and I think it's pretty easy to use. How long has Helios been around? I launched Helios, I remember, I think it was April 2nd. It was the day right after April Fool's Day.

I made a whole thing about making fun of iCloud, so I thought it was an appropriate response. Awesome. And it's still in active development under beta. I'm working with a designer and a couple of developers to really polish something for maybe a fall release, looking know, looking at September for a really proper polished release. I think that'd be really exciting. Are there any early users or like success stories so far or people that are planning on using it? That's the thing. I kind of liken it to buying a car. Not everybody really wants to start developing a new mobile application

all the time. Yeah. So it's really about kind of gathering this interest and getting people to kind of experiment with more and more substantial attempts at things. I'm excited to see what people build on top of it. It's really cool. You created this, but you created this

while you were at Heroku, right? This actually is a Heroku product? Is that right? Exactly. Heroku has been kind enough to sponsor the development of this. This is sort of a capstone project for a lot of the insights that I've kind of garnered over my experience of doing the job that I do at Heroku. So this is directly applied from my experience

of understanding what developers need and what they're looking for, and I'm hoping that this is a pretty compelling offering. It kind of has a Heroku feel on the website, the Helios.io website. Oh, I love that website, yeah. Yeah, it has a Heroku-esque feel, but it also feels different. Can you kind of speak to who worked on this? Sure. I hired this wonderful illustrator out of San Francisco.

Her name is Erika Sirotic. She does, actually, she does a lot of children's illustrations. And I wanted to kind of get away from, it seems like a lot of tech projects, maybe not recently. I think maybe this is coming around. But they're kind of too serious and not approachable. I found that her aesthetic really matched what I was looking for. And at the time, I was kind of going through a space kick. I don looking for. And at the time, I was kind of going through a space kick. I don't know.

Maybe it was looking at tweets from the space station or watching the rocket zoom around the San Francisco Bay on top of the, I guess, C-130 or whatever that was. It really, I don't know. I just was on a space kick, and maybe still am. It's funny because there was an old app, which I don't know. It was not an app. It was just like a little website you could use called Read or Not, and it was like a, it was...

Oh, I remember that, yeah. Yeah, I remember, I think it was for like reviewing books, and I think it was kind of play on words, like read or not like an astronaut, but read or not like should I read this or not, and it had a space theme for the logo, and the little guy on top of the Helios website, he reminds me of that, I like it.

I'm a big fan. You mentioned, you kind of alluded to this a little bit earlier, but I kind of wanted to hear what your thoughts are. Helios is in beta, so what does that mean and what do you kind of foresee as being the get-out-of-beta for Helios? The get-out-of-beta plan is improving on the documentation. There's a lot of kind of places that I can go with that. Right now, it's sort of a rather extended readme, but not much more than that.

And that's because we're still actively developing features. As we talk about the plans for AF networking 2.0, I can kind of expand on that. But it's sort of a coordinated effort to not only provide essential mobile services for how people are developing applications now, but anticipating their future usage. And I think that's a really important thing to look forward at how developers are going to create mobile apps, you know, not just today,

but in the next couple of years. Awesome. Yeah, so it's Helios.io. It's a really cool little framework. And if I know Adam Stachowiak at all, that you have already typed gem install Helios in your command line. That's why I was being so quiet. I was actually over here.

Yeah, I'm over here hacking on it right now as we speak. Yeah, I noticed that Adam has been quiet for the last couple minutes, so I said, okay, that's what he seems to do every show. And what we're talking about, he gets excited about it. And it's a good omen that you must you must know me well i was uh i was on point three of getting started on oss which is our osx which is you'll see your web apps web ui at localhost 5000 admin so so kind of a uh transition um i think the requirements of helios are rub 1.9+, I would imagine,

and Postgres is a requirement as well, which kind of brings me to what I think the very first time I ever saw your name was Postgres.app. So kind of speak to that and what that is and when that came about. Sure. So one of the most frustrating things I can remember from when I was first starting as a web developer was getting a database set up. I mean, I think a lot of us started with MAMP back when MySQL was maybe the best choice.

You know, PHP, MySQL, that sort of development. And I mean, I just could not for the life of me figure out how to get a Postgres instance installed on that. I was doing geospatial stuff and, you know, everybody insisted that this is the best way to do it but you know if you can't actually install and use it then what's the point and it's not that you know i'm not you know users aren't aren't aren't dumb they're just you know maybe they don't have time or the patience to figure out you know the problem if people can't use the software it's not the fault of the users there's nothing more discouraging when you're starting to like wanting to use a new technology and it's like, you know, it's getting in the way, right?

Yeah, exactly. Exactly. And it's a real shame because Postgres really is the best relational database out there, the best open source one. And it's powering a lot of stuff at Heroku, powers all of my projects. And I've just fallen in love with it. So I want to make sure that everybody's experience, you know, I'm taking it upon myself to figure out how the hell to get this thing working

in kind of a containerized app so that other people don't have to go through a similar process because it really is kind of an ordeal. And I guess a lot of people say, you know, what's so hard about brew install? But if you look at, you know, projects like Rails Girls or other projects, you know, kind of these meetups where people are starting to hack or new people

are coming on, what you find is that homebrew is not something that people intuitively get or really need to initially the terminal is a scary place and I think it's something that we forget as developers we just expect people to do it our way

I love homebrew. I mean, obviously, you know, we're not here to bash homebrew at all. But I think that homebrew does make some assumptions for, you know, for us, which is, like, we're comfortable in the terminal. We understand the command line. We are okay with, like, typing commands. You know what I mean? And I think that newcomers are not necessarily there and they're and that's just anything you can do to mitigate that hurdle in my opinion to get new

people into this is is incredible and um you know one of the one of the girls that we work with at pure charity her name's beverly and she's involved with like railsbridge and um dev chicks and stuff and she does a lot of pairing and helping newcomers out and i mean that's kind of what she preaches is you know personally myself i love vim i use vim i'm very comfortable in the terminal all this and that but newcomers are are it's hard enough to get them to even want to try programming so to like try and get them to understand the command line and this and that is not not necessarily worth doing so any tools like this that make that easier, I think it's absolutely necessary in this world right now. Right. And it's not just for beginners either.

I mean, I myself am a user of Postgres app, and that's because that's the interface that I choose to use things through. I mean, again, a lot of developers, at least on GitHub, it seems, are Mac users, and they appreciate a certain ease of use and kind of out-of-the-box experience. And I think that kind of apps are a great way to do that. So I don't really want to manage background demons or anything like that. I don't want to have to guess where my data is being stored. I like having that all in a knowable, reproducible place, and that's why I made it, and that's why I'm so happy to share it with everybody.

It's cool. It seems like Heroku almost has co-branded itself with Postgres at times, and I think that's really neat. Postgres.app was – well, just to clarify, do you call it Postgres app or Postgres.app? I usually call it Postgres app, but that's – actually, I think I interchange it. For some reason, that sounded weird coming out just then. So, yeah, call it whatever you want.

It feels like this obviously came out well before your time at Heroku. Is that right? What, Postgres.app or Postgres and Heroku's... Postgres.app. That was something I created on, I think on my fourth day at Heroku. Oh, okay, gotcha.

So it has kind of been sponsored by Heroku the same way that Helios was. It's interesting. So that was not as much sponsored. Well, I mean, yes, they did support it, and they did fund that delightful icon that goes along with it, and they have allowed me to work on that during my hours working there. But it really was more of a dare.

Somebody said, hey, Postgres is hard to install. Why don't we just have it as an app? And I just said, sure, I think I can make that. You understand how Mac frameworks work? I had no idea. That was my second Mac app. I don't understand how to do Mac development, really. I'm sure anybody who is worth their salt can look in there and see some hideous things. But boy, it's a really complex beast underneath. Again, like the more complexity that I put into it, the happier I am that other people don't have to deal with, you know, helper applications, relaunching stuff, you know, any of that. Do you want to touch on Induction App at all?

Oh, I would rather not because it's an embarrassing blight on my record. It's this promising, you know, polyglot database client. My first Mac application that I wanted to build, it started out as a Redis client, but all the Postgres people at Heroku thought it'd be cool to make a Postgres database client, a native Mac client for Postgres as well. So it just turned into doing all things for all people. And as far as ambition goes for first projects,

it's hard to imagine something more difficult and broad than that. And unfortunately, I haven't had much time or really have much expertise, sufficient expertise to really execute on it. But you did say it's got one of the, and I agree, it's got one of the coolest logos I've ever seen, or icons I've ever seen. Oh boy. David Lanham, brilliant iconographer out of the Icon Factory. He does not skimp. He is amazing. He came up with that whole concept just from the name and a few kind of simple guidelines on direction. I said, you know, Tesla and kind of electronics and industrial, and he came back with this.

Yeah. And it was just amazing. Well, not for an awkward transition, but let's move away from that now. Sure. So, okay, kind of on to what I'm really the most excited about, which is to kind of talk about the AF networking. This is something that just reading a little bit about, in a similar sense that Postgres app, it's not just for beginners, but it makes the task a lot easier. AF networking, and you can definitely correct me where I'm wrong because I am anything but an expert when it comes to this stuff. AF networking, it's built just on top of NSURL connection, right? So why not just use NSURL connection? That's a great question.

Actually, at the top of the FAQ, there's a full answer for that because that's obviously the first thing that responsible developers are going to ask before they incorporate a new dependency. And the philosophy behind AF networking is really simple. It's that NSURL connection is the highest level of abstraction that the standard library provides. And as Apple suggests, that's the one that you usually want to use unless there's some good reason that you should dip down to a lower level. So we're using that, but we're also combining it with one of my favorite classes in Objective-C, Cocoa, it's NSOperation. So NSURL connection manages all of the... So it's a couple of things.

NSURL connection, in order to be asynchronous and cancelable, or in order to monitor its progress and that sort of thing, you need to implement a number of delegate methods. And if you're doing that in your own application, it's sort of cumbersome that you have to do all this boilerplate work. I found that it was nice to combine that into NSOperation, which is basically a state machine that can be queued up and given priority. So you start a request, and then by the time it's finished,

you have all the data that you loaded from your remote resource available to you as an NSData object, or depending on the kind of request that you made, a JSON object, an XML document, an image, that sort of thing. So you're starting from an NSURL request, which is an HTTP verb, maybe some parameters and a body and a URL, and then you end up with exactly what you want in the format that you need it. So that's the sort of contract that you establish in AF networking, and it seems to be a pattern that a lot of people enjoy and prefer to work with. Gotcha. So it kind of takes the NSURL connection, combines it with other tools that are already readily available, makes it easy to do that in one place for you.

Exactly. And with Cocoa, it really is. I mean, of all the languages I've worked with, I think Objective-C has the best standard library by orders of magnitude. Just the amount of thought and thoughtfulness that's put into the design of those classes. And you can be guaranteed that everything will be fast, which is another great. Pretty much everything will be fast, which is another great, pretty much everything will be fast. It's really a great and freeing constraint to just use what Apple provides.

So it's building on those fundamental parts, not reinventing the wheel, at least as much as possible. And then translating delegate patterns to block-based callbacks. So that's the important thing, is that you're loading a request, and by the time you get it back asynchronously,

you execute a block of logic that's close to where you actually made the request in code. Has there ever been any discussion from Apple about including it in the standard library? So I talked to an Apple engineer at Labs during a WWDC a couple years ago, and their answer was actually quite interesting. So I asked them, you know, it seems like a lot of users are looking for this kind of functionality in their applications. Why not provide them these libraries yourself? And the engineer I was talking to, I was looking for Quinn the Eskimo.

That's his handle. Quinn, yeah, is the author of many of those libraries and a lot of the sample codes, so pretty well known. And I forget the person who I actually talked to, but his answer was that if you think of Apple's view of technology, they're taking a very long perspective on it. For instance, they didn't incorporate a JSON parser into the public API until iOS 5, just a couple years ago.

The reason for that is you can imagine that they didn't know if JSON was going to be a thing. Apple's been around for 30 years. It's impossible to really know what patterns are here to stay, and they have to be very conservative. For instance, they have a PubSub framework that I believe is extensively used in mail, but nowhere else. I think they expected PubSub to maybe be a bigger thing than it was, and now they have to publicly support that. So that's one of the trade-offs of

being, you know, kind of investing in a technology before it's really proven. So I guess they can kind of hedge their bets on the basic implementations of things and allow the rest of the world to create the details for them. Exactly. But the interesting thing is that Apple, in their recent forthcoming update with iOS 7, have implemented quite a number of the common patterns. So iOS 7 introduces a new networking construct called NSURL session, which actually supersedes and in some way deprecates NSURL connection. NSURL connection is still around.edes and in some way deprecates NSURL Connection. NSURL Connection is still around, so AF Networking, the current version, will work with iOS 7 just fine.

But NSURLSession is the new way forward and actually offers a lot of benefits. I guess I can go into that if you'd like. Yeah, definitely. Sure. So NSURL Connection is great. It's a high-level library that had these useful delegate methods, was fast and took care of a lot of the protocol management that you wouldn't want to do yourself, like redirection, automatic redirection, that sort of thing. However, it suffered from, the whole URL loading system suffered from kind of a singleton mentality, is that every NSURL connection shared a URL cache, it shared a cookie store, it shared

a set of NSURL protocols, so different ways to kind of inject logic as you're making requests, and it also shared session variables. So it was very easy to get yourself into a, especially with an application that communicated with many different services, to get into a situation where caches are not being invalidated where they should be, or sessions are getting munged, or, you know, it was just sort of a mess. So NSURL session offers per session configuration. And then on top of that, kind of abstracted out this asynchronous, you know, connection to a web service and provides data download and upload tasks. So the basic things that you'd want to do. Fortunately, there's a lot of stuff that

AF networking, I think, can improve upon that. And I'm really excited with what we have planned with 2.0. Yeah. So you kind of told me a little bit before that the 2.0 might be announced pretty soon. Is this kind of the driving force for 2.0, the change in the NSURL session? Yes, it's actually a great confluence of necessity and just sort of luck that AF Networking was in a place where I knew that I wanted to do different things. I knew I wanted to improve on the existing architecture

in sort of major ways. And there's no better reason than Apple providing you a better tool. So NSURL session, AF Networking adapts and applies its patterns on top of that now while maintaining vintage support or legacy support for NSURL connection, but it also improves upon those patterns. So in addition to being based on an URL session, it's abstracted away the concept of serialization. Before I talked about how you make a request and then by the end of the operation, you have exactly what you want, whether that's an image or that's parsed JSON object or XML, that sort of thing. Those serializers used to be just kind of baked into

the request operation itself. Now that I'm supporting request operations and URL sessions simultaneously, it made a lot of sense to abstract that out, extract that into its own class. So you have serializers that encapsulate all of the logic to transform NS data with a particular HTTP response to particular objects, like XML, like JSON, like message pack or image, or maybe even directly to your instances of your models. So it's actually a really powerful construct and cleans up a lot of the code, reduces the number of lines of code in AF networking, almost enough to offset the new features in the new version. Was it a complete rewrite or just basic evolution of the product? Well, it was...

So we've kept basically half of it, and a lot of it was kind of taking out the things where it was built on request operations instead of URL session and kind of building in the new part. So I think I threw away half of it first and then just built from the ground up. The first write took about a day, and it actually was quite easy to integrate the new APIs. Quite easy for somebody that's a genius like yourself, that is. No, no, no.

I've just been thinking about it for months and months. So you finally write it out, and it's just like, ah, all that is. No, no, no. I've just been thinking about it for months and months. So, you know, you finally write it out and it's just like, ah, all right, one sitting, not too bad. So when do you plan on actually releasing 2.0? The first release candidate is going out on Thursday. I'm actually here in New York. I'll be speaking at the iOS developer meetup at the New York Times building on Thursday. And that will be the first look that many developers get at 2.0, talking about its features and sort of the agenda that I hope to lay out with iOS networking in general in the future.

Cool. So just a few more days, and we'll get to play with the shiny and new. Absolutely. And if you can't wait, there's a branch hiding in plain sight. Just go to the Branches tab on GitHub and just click 2.0. It's amazing how few people have actually noticed this. Not to go off on a side topic, but finding different branches and versions and tags and stuff is

for some reason not the normal workflow for users consuming things on GitHub. So I don't know if there's a solution out there, but if you can solve that problem for me, that would be great. Well, now they have the new releases thing, so you can actually create a pre-release.

That's true. It's pretty nice. I haven't done it myself yet. You should do that, Matt, and see how it goes. Sure. I mean, I use CocoaPods to manage my releases. So if you just create a tag, yeah, CocoaPods, it's like RubyGems. Yeah, directly inspired by RubyGems.

It's actually the interesting thing about coco pods uh is that it is entirely based on github so all the infrastructure it's just that you're pointing to a specs repository and when you want to add a new spec uh if you want to add a new pod you just you know create a pull request for that pod or if you have commit access you just commit directly yeah i was actually looking into doing that for the Python community as well. I think that would be really great. I think that was, what's the name?

Eloy from CocoaPods? Yeah, I think he was actually on an episode of the Changelog a while back, wasn't he, Adam? Talking CocoaPods? I'm pretty sure, yeah. Maybe like 70s, late 60s. Yeah, a little while ago.

40 years ago. Episode number, yeah. Show numbers, not years, yeah. I just love the sound of that. So I'm number 98? Oh, man, you guys have, I'm sure, have something cool planned for 100 then. Yeah, we're planning on doing a show on a Tuesday at 5 p.m. Yeah, all day.

All day change, all day. So AF Networking has some, I don't know if you'd call it competition, but it seems like RestKit is another one, and that's the only other one I could find digging around that seems like it's actively maintained. So how does AF Networking differ from RestKit, if you have any idea? Different layers. Actually, RestKit is built on top of AF Networking.

Oh, well, there you go. So RestKit actually is more of a direct competitor to the AF Incremental Store in a way that it's doing automatic mapping between, it takes it a step further and does automatic mapping to basically your domain logic, your application models. But yeah, all the transport is handled by AF Network. I'm skeptical of large projects and monoliths, and I don't want to become a dinosaur, and I don't want to abuse the influence of AF networking or ever put the community in a position where they have a big tool that sucks. So I definitely encourage people to call me on that and to constantly challenge my assumptions and offer new suggestions because as much as I can be, I try to remain open to those new ideas and do my best to incorporate that. And I think a lot of those ideas, actually speaking of which, Blake Waters,

the author of Reskit, he was absolutely instrumental in, for instance, the design and architecture of the serialization modules in AF Networking 2.0. That was all his idea. I'll give absolute credit to him. It's because it benefited and aligned more with the way that he was designing things with REST kits. So, again, not competition. It's the best of what I've seen with open source, and I absolutely love the Objective-C community. Awesome, yeah.

So you were talking about not wanting to be like a dinosaur and kind of avoiding the monolith. And one thing that I noticed that was unique, which seems like it would help you in that is the like premium support package that you offer. It seems unique and I don't, you know, I'm not very involved in the Objective-C iOS community. So maybe it's more common there, but just offering like a flat, you know, hey, this is my open source product. I maintain it. But if you want support, I will do that. What made you kind of set on that model for support with this?

You know, I think I wrote a blog post maybe a year ago. Maybe that's the last thing I blogged about. There's definitely a tension between, and actually, Kenneth, while you're on, there was a guy who blogged about how you should be a billionaire. You remember that post? Yes, I saw that. I think it was only a millionaire, but yes. Oh, a millionaire. I did see that.

Well, still. That was ridiculous. The basic argument, I mean, it's an interesting argument that we're putting all this time and effort into things, and by golly, we should be compensated for it. But the reality is that open source functions and is actually possible to exist as a gift culture, not a market, you know, free market or sort of a monetary culture. It would be as if you went to somebody's house for dinner, they invited you over and you plop down a $20 bill on the table at the end of the meal. That would be the most inappropriate thing ever. What is not inappropriate, though, is offering a bottle of wine or offering to help clean up. So what we have is a sustainable model of cooperation, but just not on that level. I mean,

we're all, developers are well-paid and we're, you know, we have roofs over our head for the most part and, you know, we are often fed at work. I mean, we're not in need of that set of compensation. But at the same time, there is a need for companies and individuals to kind of transcend the sort of cooperative style. If people can't offer to help clean up the dishes, maybe, in fact, they do pay a little bit to have it catered or something like that. And that's what the premium support does. And a couple of companies have used that that and it's been great to allow, give them a framework to, you know, for instance, I'll sign an NDA if they want me to look at their softwares. So it gives them legal coverage. It gives them, it gives me obligation to actually

work on that. So it's actually a great model. I actually did the same thing with requests. I decided to do a request pro where someone can just basically decide to support it financially but there's no difference like with the license or anything like that yeah sure and it seems to be working really well to be clear uh kenneth does accept bribes for dinner but from the looks of it it would only be in black and white very funny um no but yeah it's a it's a very very cool uh i don't know what the word is uh you know don't call it a monetization strategy no it's all about sustainability yeah yeah absolutely we we talk about that a lot on the changelog about how to um not get burnout how to sustain the project how to you know it's all about sustainability and i think

this is a cool way to just, you know, to help that. And I think that's something that, you know, we should be trying different solutions to solve that problem. Man, that was a wordy, poorly constructed sentence. No, absolutely. That's a great point. Are you on GitTip, Matt? Am I on GitTip? I am not on GitTip. You need to be on GitTip.

Maybe. I don't know. That model is, well, I guess we can talk about that some other time i don't really have fully formed opinions about it but uh i don't know maybe it's just not for me i don't want people to feel obligated yeah it seems like that's kind of where we're at right now and we had we had chad on the show uh with kenneth actually you know a while ago and it seems like everybody right now is at a place where the opinion is not fully formed so it's up to chad and the in the get up guys to uh or the get it uh open source people to uh as he put it bring your own carrot and help to get people involved absolutely and uh yeah not to disparage him at all i think what he's doing is amazing work and you know i'm a big fan of him

personally uh yeah from what i read about him so yeah it yeah, it's a great effort. Just, yeah, very interested to see other ideas in this whole space. Matt Bunny, a chance, did you happen to catch Chad's article on the change law called Open Products? Open Products. Maybe. It was lengthy. It was definitely enlightening. Yeah, he's got a very unique view on just life and the world,

and it's an encouraging and inspiring one for sure. Tremendously. Sure. Cool. So, yeah, so AF Networking, we've got 2.0 coming out. Sure. Can I say one thing about 2.0 really quick? Yes.

So one of the responsibilities I feel kind of maintaining a project that's so widely used in the community is that, you know, the need to keep pushing forward, just like Apple does, you know, hopefully not as ruthlessly as they do, kind of deprecating things that people are still kind of using. But the direction I want to go forward is to kind of anticipate the needs for real-time communication. So a lot of iOS applications, what I'm hearing from people is that they need a way, a consolidated way to kind of reconcile this document-based paradigm with the stream of updates that come whenever you're in constant communication with the server. So AF Networking

2.0 will feature server-sent event support. So it's implementing basically an analog to the event source API that you're used to in the DOM with JavaScript. And it's actually part of this whole manifesto of how to develop web technologies that I'm calling Rocket. If you go to rocket.github.io, it's sort of my ideas about how modern applications should be built. It's hard to describe what this is. I mean, it's like a technique sort of like Comet or Ajax, where it's kind of up to interpretation. But the basic premise is this. Again, it's making the conceit that there are documents, and you make REST calls to those. And on top of that architecture, which a lot of applications are already built on,

you have a stream paradigm, where you're subscribing to changes for that particular resource. So you get resources, but you also get resources, but request a text event stream. And in that event stream, whenever a resource is created or updated or deleted, what you can receive in your connection back through service and events is another great standard that just came out a couple months ago from one of our Salesforce colleagues. It's called JSON patch, which is finally an RFC specification for how to model changes in a data set. So it's JSON encoded. You know, the text event stream is text, but the data aspects could be interpreted as JSON very easily.

And it gives you a very direct way to send changes, even complex changes. JSON patch supports add, remove, move, copy, delete, and test for existence. So it's actually quite versatile and can support, I think, a lot of different paradigms. And just using this persistent connection kind of in parallel with a document request response model, I think is a great way forward for existing applications to incorporate real-time functionality pretty easily. This is fascinating. I had never seen anyone use server-sent events outside of the browser before. Yeah, it was actually pretty easy to implement, but I don't think anybody else has really applied those directly. Server-sent events sort of gets overshadowed by WebSockets.

But the thing about WebSockets is we don't need the bi-deck directionality. So instead what we have is a unified HTTP-based solution that allows you to build applications right on top of how you're already building them. I think it's a pretty compelling offering, and I'd love to hear some more ideas on this. This is how I'm going to build things from now on. You're putting this directly into AF networking? Yes. So it's the event source and the JSON patch. That's going to be a kind of first-class extension

on top of things. And I will continue to maybe incorporate that into AF Incremental Store. And actually, these server-sent events solve one of the existential problems of AF Incremental Store store which is the unknown unknown in that if an if something gets deleted on the server side there's no great way to know about that on the client unless you ask for that resource directly and get a 404 or a 410 if you want to be

responded that if you want tweets to be deleted off of their feed in real time, you got to do that. So you said it's like a first class extension. And I wanted to kind of hit on this. Would you say, so you have your official and your third party extensions. So you support OAuth 1 and 2, S3, JSON RPC, and then you have your AF incremental store. And now what you're talking about, is that going to change at all with 2.0, or how much work has to go into the extensions with the changes, if any? Sure. Well, I do intend to upgrade all of the extensions to AF Networking 2.0. It shouldn't be that much work, though, because the API is relatively compatible, fortunately.

It was actually a really easy way to swap out one back end to another. So most people won't notice the change gotcha yeah so 2.0 coming out thursday very very exciting very cool project i uh i am i am very interested and excited to actually spend some time digging into this and uh learning it. Thank you. Again, I have to give a lot of credit to the community for their amazing support of the project. Again, two years in, over 100 contributors, maybe something like 2,000 forks, over 1,000 closed issues.

It's really the project that got me to where I am in the community. You learn so much from being part of a large project, and I'm extremely fortunate that I had the opportunity to learn so much, and hopefully people find it to be useful. Awesome. So you do have a hard out, so we don't want to hold you too long. So to the listeners that kind of know about the changelog, and to those that don't, we kind of have a few questions that we like to ask at the end of every episode. So go ahead and ask them. The

first question is for a call to arms. And for any of your products that you're kind of have out there, what would you like to see the community to kind of rally around and work on? Sure. I mean, as much as you can, if you're doing a new mobile project, I would encourage you to try out Helios, try out AF Networking, the new version, 2.0. I know a lot of people are going to be making either updates or new projects with iOS 7. Try it out. Let me know what you think. But in general, I think a greater call to action is to release stuff as much as you can in open source.

If you have a piece of code in your project that you find to be useful and think you can abstract out to general usage, I'd love to see a new Cocoa Pot out of that. I'd like to see a new gem out of that. The community grows, again, as a gift economy, that we give each other gifts and everybody succeeds together. It sounds sort of granola, maybe even communist-y, but really it's ideal because there's no materiality to it. We can just share information freely. It's a kind of a great way to benefit from everybody's expertise and their passion. And it really makes the open source community really special. Cool. If you weren't doing iOS development, what would you be doing instead? You know what? I think I found my passion just the other day. I tried hang gliding for the first time. Now, I don't know what it is. Maybe it's a quarter-life crisis, but I started doing a lot

of air sports. I'm working on my pilot's license. I went skydiving just a couple weeks ago. Probably be going again soon. But hang gliding, oh my goodness that is uh a russian thrill beyond belief and and it's just something that clicked instantly uh i would encourage you don't tell your parents about it but that you're going tell them afterwards but man or your wife or husband don't don't tell them until afterwards or take them with you i guess uh just really cool when you get your pilot's license, feel free to swing by Nashville and take me on out to the Heroku headquarters to hang out. That sounds great. And lastly, for your programming hero, something you want to give a shout out to? Shout out to Why the Lucky

Stiff, of course. Just a hero to a lot of us in the Ruby community. But also to Sean Inman, who is somebody that I look up to immensely. Kind of a triple threat that he's a designer, a brilliant pixel artist, a great programmer, and does his own music composition, writes thoughtful pieces on his process, and just an amazing guy. So definitely look up to him, and has been an inspiration my whole career. Yeah, his 8-bit or pixel stuff is some of my favorite, for sure. It's amazing.

What did you think about Why's somewhat return recently? You know what? I almost didn't want to get burned, or it was sort of like there was a closure to it all, and when you reanimate corpses, you sort of get a zombie effect, potentially. So I kind of wanted to let Sleeping dogs lie until the jury was still out. But I guess sending cryptic communications through postscript documents is a pretty cool way to communicate from the grave. Man, that's pretty much what you would expect.

Absolutely. And I'm not going to try to be controversial here, but I do believe that he was at PyCon last year. There you go. I met him in real life. He taught a class at Carnegie Mellon. There you go. I met him in real life. He taught a class at Carnegie Mellon. He was playing the auto harp the whole time. He lectured in song and verse.

It was a life-changing experience. Yeah, he was 4'10 gone. He was not gone from the world. I think he's still... It's almost like the Sasquatch. There's Y spottings all around the world. He's 4'10 gone. Not real gone. I like that. There's Y spottings all around the world. He's 4'10 gone. Not real gone. Yeah.

I like that. That's good. It's definitely been fun having you on the show, Matt. Man, so much, so many, I mean, we could have gone on and on, literally. I mean, I almost wanted to talk about some other things too, but I know that we got a time box here,

but definitely cool having you on the show. Thank you so much for everything that you do in open source and the way that you're supporting mobile development. To lament on what you said earlier in the show, I like your perspective versus what you said, your job at Heroku is to

help grow mobile development on there. Instead of trying to market, you're growing the user base of mobile development. there instead of trying to like market your growing the user base i guess of mobile development it's a really good perspective so oh thanks a lot and thanks for you know the changelog i think does a lot to humanize and give a voice to open source so thank you guys for uh really being a guiding voice for all that not to suck up too much but really you guys you know hats off thank you man man. We certainly appreciate it. It's what makes this worthwhile, that's for sure. Absolutely.

But we're live every Tuesday. This is the Change Log, Sunny House. Let's say goodbye, guys. See y'all later. Fare thee well. Au revoir. We'll see you next time.