Panel

Sam Soffes (twitter github blog)
Pete Hodgson (twitter github blog)
Ben Scheirman (twitter github blog NSSreencast)
Rod Schmidt (twitter github infiniteNIL)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:13 - Sam Soffes Introduction

Seesaw/@Seesaw

01:46 - Roon.io/@roon_app

Drew Wilson
Octopress

03:03 - Open Source in iOS

Writing Tests
Flurry
TestFlight
PLCrashReporter

09:00 - Open Sourcing Projects

cheddar-ios
Licensing

13:19 - Shared code between iOS and Mac

004 iPhreaks Show - Mac Development with Josh Abernathy
Categories

17:48 - Contributions, Pull Requests & Bug Fixes
 20:15 - Open Source Libraries

CocoaPods

28:40 - Finding Reliable Libraries

Rating
Activity
READMEs
Cocoa Controls

32:44 - Contributing to Open Source Projects

Consistency (tabs vs spaces)
Testing
Squashing Commits
Submitting Code/Changes

38:09 - Cleaning Up Pull Requests
 41:08 - Open Source at Seesaw

SEEActivityIndicatorView

Picks

semver.org (Ben)
Anker Astro3E Portable External Battery Pack (Ben)
Cards Against Humanity (Ben)
Travis CI (Pete)
Pete Hodgson: Using Travis CI and xctool to build and test iOS apps (Pete)
Reading Application Licenses (Pete)
AppCoreKit (Rod)
WatchESPN AppleTV App (Rod)
Put Objective-C Back On The Map (Ben)
David Siteman Garland: Create Awesome Online Courses (Chuck)
How to Write a Nonfiction eBook in 21 Days by Steve Scott (Chuck)
Amazon Prime (Chuck)
Kickoff App (Sam)
redcarpet (Sam)

Next Week
 Backends
 Transcript

[This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

CHUCK: Hey everybody and welcome to Episode 12 of iPhreaks! This week on our panel, we have Pete Hodgson.

PETE: Buongiorno from rainy San Francisco this morning!

CHUCK: Ben Scheirman.

BEN: I can give you a very jet lagged hello from Houston!

CHUCK: Rod Schimdt.

ROD: Hello from Salt Lake City!

CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we have a special guest and that's Sam Soffes. Alright!

SAM: Hello!

CHUCK: Do you want to introduce yourself real quick?

SAM: Sure! I live in Kentucky right now. I work in a company called "Seesaw". I'm working on a bunch of little projects; Roon had been my main side project right now.

CHUCK: Awesome.

BEN: That's Roon, R-O-O-N.io, right?

SAM: You got it!

BEN: Yeah, I'm primed I've got the best username. All I need to do now is blog a little bit.

[Laughter]

BEN: So Roon is like a blogging platform. What makes it kind of compelling in comparison to some of the other things that are out there?

SAM: It's a product I did with Drew Wilson. If you're not familiar with his work, he's a spectacular designer. I always wanted it that makes it really simple that we wanted to use, and hopefully other people wanted to use, too, so he just made something really simple that's really beautiful, and there's also a native iPhone app. The iPad app is like the universal, it's almost done; I'm submitting it, hopefully, this week. And we have a Mac app in the Pipeline. It's just like we wanted to make a really good writing experience that's simple and pretty and hopefully people like it.

CHUCK: Awesome.

BEN: Yeah,

 

the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

Hey everybody and welcome to Episode 12 of iPhreaks! This week on our panel, we have Pete Hodgson.

Buongiorno from rainy San Francisco this morning!

Ben Scheirman.

I can give you a very jet lagged hello from Houston!

Rod Schimdt.

Hello from Salt Lake City!

I'm Charles Max Wood from DevChat.tv. This week, we have a special guest and that's Sam

Soffes. Alright!

Hello!

Do you want to introduce yourself real quick?

Sure! I live in Kentucky right now. I work in a company called "Seesaw". I'm working on a bunch of little projects; Roon had been my main side project right now.

Awesome.

That's Roon, R-O-O-N.io, right?

You got it!

Yeah, I'm primed I've got the best username. All I need to do now is blog a little bit. [Laughter]

So Roon is like a blogging platform. What makes it kind of compelling in comparison to some of the other things that are out there?

It's a product I did with Drew Wilson. If you're not familiar with his work, he's a spectacular designer. I always wanted it that makes it really simple that we wanted to use, and hopefully other people wanted to use, too, so he just made something really simple that's really beautiful, and there's also a native iPhone app. The iPad app is like the universal, it's almost done; I'm submitting it, hopefully, this week. And we have a Mac app in the Pipeline. It's just like we wanted to make a really good writing experience that's simple and pretty and hopefully people like it.

Awesome.

Yeah, I got on the Octopress train and I really liked some aspects of that like Git Publishing and writing in mark down and that sort of thing. But I found that after I updated to Octopress, I blogged a whole lot less, and I don't know why that is. [Chuck laughs]

That's funny, I found the exact opposite.

Really?

Yeah. But I wasn't blogger before, which is pretty awful. So, maybe that's why. I haven't just done anything else.

The local cub scout counts or district, there aren't blogger and I keep telling them, "Look, I will pay for your hosting," [laughs] I feel move off a bit. So we brought you on the show today to talk about "Open Source". I think, open source is a little bit different from open source, say, in JavaScript or Ruby where the source code is effectively what you get and it just gets interpreted out in the open or even on the server as opposed to iOS where it effectively gets compiled down into an app and then pushed up to the device. Does that change the equation for you at all?

I think it makes it a better experiece, honestly. I spent a lot of my day job writing Ruby mostly now, and it's great because like those tests, we can integrate it into the test pass then into swine or whatever. Well, I guess if there's not test for it, then like who knows you're pretty much coding your app that, like who knows what it's going to do. But in like Objective C-land, everything compiles. If at least it compiles, you know it sort of going to work hopefully. If there's a syntax there or something in Ruby, then you could find that at a very unconvenient time and have some bad issues.

Yeah, that makes sense.

Yes, but the flip side of that, though, is that people in the Ruby community actually write tests. [Chuck laughs]

I mean like I'm being a little --

Zing! [Sam laughs]

Like if I get a pull request for a Ruby project and it doesn't have test, I can say, "Can you please add some test," and normally, they will add some test. If I go to pull request for an iOS project or for an Objective C project, I've never actually tried asking people to add test, but I'm not sure whether people would actually feel comfortable doing that.

I just did that yesterday actually, here pot it in and write a test, so I was --

It's possible!

For an Objective C project. I think the biggest thing is like no one really does test at all. But if there's already like some test in their projects, like an example though like follow them, it's pretty easy though, like write a test what you just made. But no one does test in general, so it's kind of tough.

So maybe it's my fault for not writing test in the first place and refusing core or press that don't have test or asking people to write a test.

One of the things with bringing on third party code in your application, like what I've used to do is send the Microsoft world of fairly rarely with components that you purchased or received somewhere would contain a source code, there would just be compiled binaries and you link them in and promise like there's usually bugs or there's things that you need to work around and you don't have the source to really even know that they better have good documentation. But then when moving to Ruby, everything is sort of implicitly open sourced because it's not compiled, so it seems like it was just a much better ecosystem for open source. Now, doing this same thing in the Objective C world, people have the ability to ship static libraries to you without source, and some of them do, like Flurry Analytics package or TestFlights component that you can embed in your app.

You really have no control over, no insights into what it's doing in your apps. So like bringing get into an app that you intend to ship to customers is kind of, I don't want to say risky, but you really have to think about it and trust the people behind that that they're not going to do something really stupid. CHUCK: Are there very many systems that actually do that, though? Or, do most of them actually provide you with the source you can modify if you need to?

These all are big companies. It's almost as if they feel like that's their secret sauce. But honestly -[Crosstalk]

Maybe. But think about Flurry for instance, my company wrote an analytics platform for a client, it was not that much code; you just hook into some exception handlers and you provide means of logging and you submit some network request to send the data. It's really not that complicated. So the real secret sauce, the values in the server that they have and the data that they're storing for you. Same with TestFlight --

Yeah.

Like sure, we can all write a client that does what TestFlight does on the mobile apps so I don't see any reason why it couldn't be open sourced.

Good example of that is the CrashReporting stuff. Almost all the iOS CrashReporters are based on that one open source library or --

PLCrashReporter?

Yeah! And that's open source and they're all based on it. But they all still manage to sustain a business model.

Yeah. So there is an issue with the TestFlight SDK. It was like almost a year ago where, I forget what it was, but somehow they're issuing too many network requests concurrently and it would like kill the networking stack for your particular app. And we noticed this in our app where all of our network request would fail. They would fail before leaving the device, like you inspect the response code, it'd be empty; the response code would be zero, which isn't valid. Over a trial and error, we eventually have realized, isolated the problem to the TestFlight SDK. I think there was like an AFNetworking issue that wasn't really, really the day of networking, but the TestFlight SDK guys kind of subverted the issue as a discussion place for resolving that because apparently, a lot of people were having that problem. So I think it just kind of underscores the notion that if they had been open sourced, I don't think [inaudible] a problem at all, and it probably would have land somebody in the community come along and say, "Hey, this is a problem and you guys should fix it, or I can submit a patch."

Well, the other thing is this, with Flurry and TestFlight, you're not just paying for the little library that you stick in your application, you're actually paying for the infrastructure they provide to gather and analyze your analytics, or to provide people an opportunity to try out your application. That's really what you're paying for so there's no risk if their APIs are secure in exposing the driver on the other end in open source.

I would say I open sourced one of my products, Cheddar, the iOS app because like it was a service you'd pay for. The services, obviously, is a close source, but the iOS apps is open source. It's like, "Who cares? It's a free app." For this thing, it's a free SDK from TestFlight; it's useless without their service. So if there's a bug or something like what someone figured out, there's really no reason to keep that closed because you're right, it's not like secret or anything.

By the way, I have to tell you a huge thanks for open sourcing Cheddar for iOS. I think it's a great kind of model real-world project. It's awesome.

Yeah, plus one.

Wow! Thanks so much!

So many people don't or like afraid to do that. Like, "Oh, no! Somebody could take your source and build the same application you built." My thinking is, the type of care and brand you built around that would mean many others based on the same technology wouldn't be as successful. And obviously, they don't have the server reader.

I had one guy, he took the exact design, icon, everything (didn't have the fonts though because in license 7, those are open source), and submitted it without the server component WIC with everything. And I was like, "Hey Apple, it's not cool he's using my icon," and they took it out from the store.

Nice.

So that was the only problem, I guess, but it wasn't like that big of a deal. The guy was nice about it, too; some Chinese guy. He was like, "Sorry," -[Ben laughs]

It's pretty cool.

Was he charging for the app?

I think it was free, or might have been a dollar, I can't remember.

What a weird thing to do...I wonder why he did that? [Chuck laughs]

Yeah.

Who knows?

I think more companies or more people or whatever should do that even if they're charging, even if they don't have a service eye component to that app and that they're charging like $2, I think there's only a very small number of people in the world that would actually rob them paying $2 for their own clone net and so the project can build it and put it on their phone and all that stuff, it's just no one's going to bother doing that. I don't know why will people don't open source iOS stuff. SAM: And they had to use app for a hundred dollars, too. If they're just like normal person, it's so much work.

Yeah. For like $2, press a button and it takes to opens me a bank account or $5 overload.

I think you underestimate the links people will go to avoid paying for something. [Chuck laughs]

I guess that those kind of people, I suspect -- there's kind of like the Android thing, like people who are not willing to pay for something, they're not really going to be very good customers of yours anyway so why bother? I guess that was always the what's he called, the guy Instapaper, the guy who always used to say that.

Marco Arment?

Yeah.

The thing that I think I worry the most about with open sourcing my iOS stuff is basically, not that they're going to take it and try and put it on their own device because, heck! I mean I'm out $2, or if it's free, then I'm out nothing. But the scenario that Sam brought up, where they compile it and stick it out on the iOS store, and basically, it's my app with a little bit of prettiness or added to it or taken out of it depending on what the situation is.

If you're sort of concerned, if you just like put a more check your license up, I think it's BSD or MIT, I forget which one to pick, because it's like I don't care to everyone. The BSD one, basically, is you can't use my name and I was just like, "Please don't be a jerk," and then README like, "Here's the stuff for free, please don't be a jerk." I only had one problem so I guess it's not that big of a deal. I don't know.

Actually, I want to find out if there isn't a license where you can not open source something, but -well, I guess I don't know if this counts as open source -- but put your code out there and say, "Anyone is welcome to look at it. You guys are welcome to send me pull request, you're just not allowed to make any money off of it." Like, you're welcome to install it yourself, you're welcome to improve it and install and improve those in yourself and put it up on wherever, but you're just not allowed to sell it. Because then you could legally stop people from doing that, but you'd still get the benefits of the community contributions and all that stuff. Although, probably people wouldn't want to contribute into that kind of project.

People contributed at Cheddar because they found a bug and they want to fix it. Like grounds are very small group of people that are developers and have that capability, but that was kind of my audience so it worked out. But sure there's license that has those stipulations.

Yeah.

It's also an example project that uses shared code between iOS and Mac. Can you talk for a minute about how that experience was?

I really hate Mac development. Just first off, it's the worst. [Ben laughs]

I think we did a whole episode on that [chuckles].

[Chuckles] We did.

Yeah, Josh Abernathy kind of plead to Apple to make it better.

On this random guy, I'm like "How you do this all day everyday?" I just can't understand like, "Ugh! It's -- Man!" Anyway, I've been wanting to make a Mac app and I was like, "Well, all the networking and core data is totally like 100% the same; I just have to redo the UI." For the long time, it was the same project, and it was just different targets. And then when I wanted to open source Cheddar for iOS, the Mac app wasn't anywhere near complete. So I switch it on to a static library so I could open source it separately and still work on Mac privately until all of this done. But for a long time, it was one project. I don't know. Is there anything specific you want to know?

No, I was following the development on Twitter, and just thought it was -- I also have this kind of desire to build a Mac app at some point, but I don't know, everytime I do file in the Mac app, I'm kind of lost.

If you're going to do a similar project again, would you stick with that kind of shared core stuff? Did you get a lot of benefits from that? That's why I'm interested in it; I'm interested in that whole idea of like reusing the core code, but then having a different face on it for different platforms.

Yeah! We're going to do a Roon Mac app, and it was kind of my plan because it worked really well for Cheddars because all of the core data and networking stuff is like totally the same because most of the business logic and stuff is in the models. Or right now, for that particular app, it's in the controllers, but that's because I'm doing it quickly. Anyway, you can erase a lot of stuff and just make like, "Okay, on iOS it's the FetchedResultsController; on Mac, it's an ArrayController," and there are list of things, you have to rewrite it yourselves whatever, but it works really well to share that stuff and I don't think there's hardly any conditionals with the exception of like including different frameworks.

That's pretty awesome.

Yeah! It works really well. We're going to round it or a couple of things because I had categories in each particular app so I have a category for my models that had like FetchedResultsController specific things or what not (I forget what specifically is in those). But I definitely had categories in each app to like add things since I've adding conditionals in the shared library, which maybe is a bad idea because it makes it less reusable for other folks. But realistically, I'm the only person that's using Cheddar kit and the thing I'm making for Roon, so I don't know; I thought that was clean or have been doing like #ifdefs all over the place.

I think it's a good way to like just kind of enforce your own separation also.

Yeah, it's true.

If you think I'm trying to separate all your stuff -- I mean even just like we're going to app is open sourced, you write better codes just because people are going to see it maybe -[Ben laughs]

And you're like, "Well, I don't think I'm terrible," that is even if you're just like, "I'm going to separate this part out and maybe open source, maybe not, whatever," it makes things much clear now, you can't like -- I worked on apps before like the models had stuff like controls and some random ScrollView and some random ViewController, and I was like, "Oh, gosh! This is so terrible! It was like a ScrollView outlet on a Core Data object, this is ridiculous!" So it prevents you from doing that silly, terrible things.

Yeah. Some of my friends are asking me if I'm going to open source the NSScreencast app that I've been working on for almost a year now. I've planned on rewriting it, I'm kind of considering that approach, but there's a security through obscurity with a service that I expect people to pay for. Like for instance, in-app purchases, it's not sufficient to just like Set A did purchase flag to yes and NSUserDefaults, you actually have to do some verification purchases and, I don't know, like things you might be able to get away with in rewon; I certainly wouldn't want to shift that open source just because it's kind of way too easy for people to fake.

Maybe I'm being a little naive and optimistic, but maybe if you did have a bug like that and you open sourced some of that she send you a pull request to -- some have found it, they send you a pull request to fix the bug rather than exploit it.

And you are an optimist, aren't you? [Sam laughs]

I live in San Francisco, come on! [Ben laughs]

You'd be surprised and think like, I was really worried and I was going to try to like draft a custom open source license to like "You can use it, but you can't sell it unless it's like very different than mine" and it's almost like well, how will you define them like a variable change or like enough like deviation from my work and I was like, "You're right. If I'm going to open source it, it's just like forget it. It's open source, it's still way free; you do however you want it." No one was like terrible, except for the one guy, but he was nice about it when I asked him to take it down so, I don't know.

Yeah.

Did you get many contributions that we could use? Did you get a lot of pull request that you ended up using for Cheddar?

Yeah, I would say at least 20+, and I have to look. But there was like, for a while, when I was actually working on it, I get a ton of contributions and bug fixes or even just like people reporting problems in GitHub issues were like very detailed things and like look into code like "I think this might be the problem, but I'm not sure," and I was like, "This is awesome!" like it can actually really help you versus like "It's crashing when I do this," and I'm like "I don't know, sorry." [Chuck laughs]

That alone was really nice just to have some like very good support tickets already in GitHub for me because that's what I was looking for anyway.

Did you have any issues where someone was like, "I think it should be doing this," and you're like, "Oh, actually, I don't think it should do." I guess that's the challenge of open source; it's walking outlined between being the benevolent dictator and encouraging people to contribute stuff, but also keeping the vision of the project.

Yeah, there is definitely a couple like no one actually -- I can't think of any cases someone has send a pull request that was already implemented for something I didn't want. But there is definitely several issues or like, I guess there was a couple, whatever. But anyway, people said a couple and I go like, "Well, thank you so much for your work. But I don't really think that fits so much with the vision of Cheddar right now, I'll consider it in the future." You just have to be like tactful about it and then everyone's like "Cool! I understand. Well, thanks for making it simple." I don't know, there is definitely tough to do.

I kind of want to tackle another angle on open source within iOS. We're kind of talking about open sourcing our apps, but what about open source libraries? First off, I think we all know about CocoaPods, are there other good places of getting open source libraries for your iOS apps that allow you to add certain functionality to it? What are kind of the pros and cons of using those?

I guess CocoaPods is the de facto standard. It's, those other systems out there, but CocoaPods has kind of got market share enough that people start actually registering them. If nothing else, you can use CocoaPods to search for a library because they have the website, right? CHUCK:

Uhm-hmm.

Or you can do that on the command-line app, too. You just pod search in --

Oh, yeah?

The search term, yeah.

Well, that's assuming you're using CocoaPods.

Well, sure. But the alternative is to download the code and either compile something as a static library and link it in. In which case, you have to manage the header search paths and other linker flags and perhaps, other build settings that you need to put in there. Or, what people ended up doing is just dragging and dropping source files into their own project, and I really, really hate that approach. However, it has the least friction for people, like if it matches your OS version and your project is using ARC or whatever, if certain things line up, that is the easiest way for people to pull in code; it just has the downside of being, "Let's bundled in your application," you might have to deal with ARC issues if they're different from your settings. There's some other weird things that you might run into like if it depends on frameworks that you haven't linked, I don't know, number of problems, and then really the update problem is like the biggest.

Yeah, that's what I was going to say.

Well, before CocoaPods it was using app, it's just I've got a submodule and then add the files directly in Xcode for like simpler libraries because you don't have to deal with like all of this silly dependency and tight library stuff. That works really well, especially pretty ARC, that works like amazingly well because there was really no things people could do that were like super crazy.

Yeah, but when would you ever update it, though? If you update it, would you --

What was that?

Would you like link the files directly? Or would you copy them into a project? [Crosstalk]

You just update the git submodule.

Yeah!

What about new files that get out --

Then you'd update it if there's an arrow like, "Okay, see if there's new files and just add them," but that was like a pretty rare thing.

My thinking is that like doing that for once or twice is not a big deal. But if you have like 10 dependencies, you just -- and I'm kind of a fan of like having some really awesome small dependencies that add value to the platform and you can bring those along to every project, so I don't think it's unreasonable to have 10 or 15 dependencies on various open source projects. If each one of those requires some sort of header search paths wonkiness or any kind of other build setting, it just seems like it loses its value quickly the more you have.

Definitely adds a lot of friction. If you're discouraged from using open source tools and if you have to do that stuff and you're discouraged from updating them because it's, "Oh, there might be a file added and I'll have to mess around with Xcode."

Yeah. And we're not even talking about versioning; there's basically no versioning in that scenario. [Crosstalk]

I've done that before using tags. In fact I do that I think today, there's some stuff that I do that doesn't use CocoaPods. The thing is I think that a lot of the people that of kind of vocally don't like CocoaPods are like pro-iOS developers; they're the kind of people that are kind of known in the iOS community so they always know what they're talking about. But in some, you could say that the target audience for CocoaPods is actually kind of Joe Developer who doesn't really understand what a header search path is and just wants to, some think to do, make his day job easier, or maybe make his afternoon or his evening job easier. I think CocoaPods does help with that, but the problem is it's such a big lumbering thing that tries to do a bunch of different things. No one can improve like one of the things that CocoaPods does because you'd have to change the whole thing in one big go. It doesn't really followed like the Unix like do one thing while kind of lost. The same way as bundle; if you wanted to change the way bundle works, you basically can't because you have to change the whole of bundler.

I have to say, though, that I do like the idea of "If I have to (I don't know) make a JSON API call and they have some pod in there that makes that a lot easier, obstructs away a lot of the APIs for that and things so that I don't really have to think too hard about it to make it happen," I'm all for that. But at the same time, if it has these pain points, then I have to weigh the time and effort it's going to take me to make the pod work against the time it would take me just to write my own.

I think there's no question of whether or not it's valuable to bring in like robust third-party libraries that add value to project because there's lots of fixed stuff out there that can help you do your job faster. And if it's trustworthy, then I don't see any reason why you shouldn't take advantage of that. However, on every new project you start, you're like, "Oh, I want to use this thing, and this thing, and this thing," how quickly can you get those things integrated into your project? And if it involves handful of manual steps, like go take a look at how to install Kiwi, it's just a little ridiculous. The same thing with the instructions on how to install Frank, it's just like the world that we live in. If we can make that as easy as add something to our file and run a command, I think that's a win.

I totally agree. I think it's kind of -- it used to always crap me out that whenever you go to the GitHub page for an open source iOS app, it was like the README was 700 kind of pages of screenshots of like, "Click here!" and there's a big arrow pointing to where you -- [Chuck laughs] [Crosstalk]

I saw a presentation on Kiwi at one of our local iOS meet ups, and half the presentation was setting it up.

I do the presentation on Kiwi at CocoaConf and that was pretty much 20% or 30% of the presentation --

Oh, wow!

And I was, "Alright! Now let's talk about header search!" But the thing is -[Crosstalk]

Because you need people to get going. That was my target audience, it sucks, but that's the nature.

If you're about to embark on a project that you know you're going to work on for like 6 months, then I'm okay with doing a little manual work up front to make your job easier down the line. But if you create apps to try out concepts on a daily or weekly basis or if you're constantly working on new projects, man, that stuff gets tedious real quick. I get really frustrated with just how difficult it is to do like to get started on new things. But once you have your sort of convention set up like your folder structure in Xcode and things linked up the way you like them, then you don't really have to worry about it. Perhaps, I have unique concerns because I create like a brand new sample project for NSScreencast every week and, god, that gets really old. [Laughter]

So are there ways that we could make this easier even just a bash script or something that could do it? Or is there a reason why that wouldn't work?

Well now, CocoaPods has like an Xcode gem for working with the Xcode project and just doing arbitrary things to it. That's a really nice foundation, I think, if you wanted to start going that's making around thing.

That's what Frank does. Because we can't use CocoaPods, as far as I know, we can't use CocoaPods because we need to mess around with things too much. So I think I'll use Regen, or Luke Redpath has a similar Xcode gem, and I just programmatically mess around a little bit of Xcode and then use xcodebuild to do some things and it works. But as a maintainer, it's a bunch more work than writing a spec, I think.

Do you guys ever run into libraries from CocoaPods or GitHub or anything that seem to not be reliable, that don't do what they say they do? Or don't reliably do what they say they do?

I think if you know what to look out for. I personally know because I kind of have a check list of things before I even consider using a library. So I think if you're smart about what you pick, you don't really have that problem.

Can I just ask you what some of the things on that check list are?

Yeah! Like more than 20 stars on GitHub or about that, like "Okay, at least someone is using this." And if it doesn't have commits in the last month or two, then I usually won't even consider it. Basically, I want to see that it's actually working. If the only activity in their repositories, just like when people complain in issues and no response in the maintainer, that's a huge red flag. So I mainly just, "Is this like decently reliable," or like "Is this decently active?" and then it does a README how to use it. If you don't know how to use it and it's not being maintained, it's probably going to be a waste of time if I get in there.

That makes sense.

In the Ruby community, you have something like Ruby toolbox, which you can say, "Oh, you want to part HTML here for gems to do it here and it will analyze those kind of stats; this one is actually maintained, this one looks like it has a lot of unresolved issues," it'd probably be interesting to have something like that for iOS community.

Yeah, it will be.

Because looking at Cocoa Controls, there's just a ton of stuff out there; cocoacontrols.com. I think we've picked it on the show before. It's got lots of visual components, but also just like CocoaPods, you can search for CocoaPods directly in there. And when I was doing a screencast on SlideMenu, it's kind of like the Facebook sort of left nav slider menu thing, I took a look at about 7 or 8 different components. One of the things is like in addition to this as general code quality and how strong is the GitHub repository in terms of stars, works, issues, and things like that, and the documentation, it's just like "How does that feel?" You have to have some sort of like a video or like a sample project you can download because I'm really picky about like the polish on these things. One of the things that I found that almost none of them do is if you are pulling, like when you pull to the right with your finger, it should open the menu like tracking underneath your finger. Some of them just implement the pan, just the recognizer when it finishes, and then does an animation to open it, and that just feels janky. If they do implement that one where it's tracking your finger and you do it really quickly and then let go, it should calculate the requisite velocity in order to complete the animation at the same velocity that your finger was moving. It's a little bit of math, it's not that hard. But it's the 'attention to detail' that you have to make sure that these visual components adhere to your standards as well. I sort of broke my own rule like Sammy called me up the other day where I've had this little component I wrote that I've used in a few projects. It just presents a picker view like modally, but it doesn't make screenshots unlike GitHub page, so I'm taking screenshots to put them up there this week.

I think it'd be nice if -- I mean there is so much who just like, "This is the standard, everyone follow it and everyone hopefully blindly follows." But for a visual some sort of UIComponent for iOS, you have to have at least one screenshot, and if anything are active like, "Please post the video," and like same old project that somebody can download and play with, I think, is really important. Because like you said, it's harder like sit down and if you want to evaluate what's the best pull request or something if they download all of these and put into project and play with it and sphere high and integrate it, it's like you just want to know which one is the best, like show me the stuff so I can make my decision and move on.

Do you have any tips on like contributing to these projects?

I can say from the perspective of like the repository owner, not necessarily as the perspective of a contributor...

No, that's what I mean. If somebody were to make a contribution to one of your projects, what are the things that you appreciate? What are the things that you want people to -- I don't know. One thing from my perspective is just like, ignore all of your current hang ups, like where braces go, where spaces in the method signature go, like follow the conventions of the project.

Totally. That's actually my number 1 thing. It's fine if you want to do something really silly like use 5 spaces or something like whatever. But if you're working on this project, please just match it so it's all consistent. Actually tabs for most things, just because Xcode is bar or tabs and spaces whatever, I prefer spaces about Xcode so I accept them. But everyone who still want to contribute with spaces and it's like really annoying and they're like, "Hey please, just change the tabs. Sorry, just please change the tabs and all merger thing," just like people is like, "Why you did all the stuff and you want me to like change my space?" It's like, "Well, yes, sorry. It's kind of like awkward interchange, but --" I guess the other thing is if there's test in a project and you're writing something that's like changing functionality or adding functionality like, "Please write a test for it if there's already tests," obviously a lot of things will have test so you don't worry about it. Anything, as Objective C developers, we don't really like think about tests, but --

Yeah. I mean to your point about like, "Oh, I did all this work, and now you're going to reject it for this thing?" or like earlier you said, "This isn't really fit in with our vision." There's no reason why you can't discuss this stuff with people at a time like open ignition, say, "Hey, I was thinking about doing this. But before I take my entire weekend doing it and making it perfect, maybe I should just run it by you first."

Totally. On the other hand, like wouldn't it be nice and then it's usually, "Yeah, sure send me a pull request," and then like implement it. I was like, "Well, actually --" [Ben laughs]

I don't know. I mean it's definitely more impressive if you're like, "Here's the pull request, implement my idea. What do you think?" but near to it if you just spend a lot of time on it. I get a lot of contributions and I just took it because there's a bunch of categories in there because this project is super old. I have categories when I wrote my very first app in 2008, and people like I always categorize it like I just really don't -- like there is one the other day for his iPad, and he was like, "There's a macro for that. I really just don't want this," and they're like, "No, I'll distribute it great," and I was like, "No, you can make your own library, it's okay. We don't have to agree on this. It's really okay, you can have your own library with your own categories, it's fine." That's always really hard to just like, "No, I'm sure I don't want this," and people like argue about it. But, I don't know. I don't really have any tips besides just try to do what the author would want; just be conscious of that.

What's your view on like when you use a branch like squashing commits and that sort of thing. Do have opinions on those?

I generally don't squash commits unless the author requests, and personally I don't care. Mainly because most people, especially people when they worked in development in general, which I think is a lot of the iOS community, more or so than other communities like Ruby for example, they're new to this development in general so asking them to rebase stuff is just like -- like I had a pull request just an hour ago and it was like, "I'm sorry, I can't rebase. Please close this and we'll make a new pull request. I'm just going to copy and paste it," and I was like, "No, it's fine. I know this is hard, and I don't really care that much. But I mean I contribute it to a couple real score Ruby projects," and they're like, "Yeah, after rebase, this isn't the one commit, we're not going to accept it," and I was like, "Fine, whatever. I'll go Google how to rebase," because I cannot remember. [Laughter]

At first, I think people here like just being silly, but -- I guess if it's a giant project like Rail or something, it makes sense because there's just so many commits and it's hard to dig through anything. But, I mean I don't care. I don't see many Objective C folks care. I know the only person I think that does it is Mattt Thompson, and I've seen it anyway. And he'll just merge it and then rebase it after that cracked, so like he'll adjust it for you, which is nice.

Yeah, I did that on somebody issued a pull request and change like 4 or 5 unrelated things, but the pull request was related to one of those things. I could tell that they don't really know the sort of intricacies of git and why you should keep them separate. But I still appreciated that pull request instance of volume that I get is way lower than somebody's more popular projects; I didn't line so much just fixing it up and merging it in.

I think that's good. I feel a lot of these contributions, especially those like in some my libraries are, someone's first contribution to GitHub, I'll see comments like, "Thank you for emerging thing. I've got a GitHub account, just why I contribute this." And I was like, "Well, yeah, thanks so much!" I'm trying to be nice to people, I'm not just like, "Usually you have to rebase this," I think it's important.

It is really daunting, like it's intimidating for people new to development to submit code that other people are going to see and judge, and I think those sort of live on GitHub. You should remember that when people are submitting changes. Sometimes, it's going to suck. Like, "Well, thanks for the idea," I'm going to do it myself because I like the idea, but the end of limitation isn't that great.

What do you guys feel about taking someone's pull request in and then cleaning it up afterwards? Because I always get back and forth for that; I kind of almost feel rude to like take it in there and be like, "Okay, this is cool. But now I'm going to change all the stuff that you did because I don't agree with it."

That's your project. I think that's -- at least you're incorporating their idea.

Yeah. And I was going to add that for me, it's not just that it's my project, my name's on it. Their name's on the pull request, but my name's on the project. So if somebody's going to pull it down, they're not thinking, "Oh, well, this piece was contributed by so and so and such and such." So if the code doesn't match style, I may or may not refactor it. But if the code could be done better, then I'll definitely refactor it because it has my name on it.

I used to go down that route, and now I kind of just don't merge anything. If it's something I have to redo, I usually just won't merge it because I don't have time to like do it anymore. But definitely every pull request I had merged and then have to go like clean up some little things because I'm super picky about coding, commits, and some stuff so I was like, "It needs to perfect." I don't know, I guess I'm caring less these days.

If you read through the AFNetworking, some of the more popular issues that are long-running, that has lots of conversation involved, Mattt will often close it and reopen it, giving all the conversation. But he's always super good at say, "Oh, thanks so much for your contribution. This is really awesome." To me, it seems like he was very welcoming of changes, but he does very often close up all requests and write it himself.

Yeah, he's in the number of my things. We talked about it in person and then he's the guy that really great. I'll implement and submit it and he'll close it and just redo it, and I was like, "Okay, whatever," it works. I'm happy that's there. [Ben laughs]

I don't really care if it's my code or your code.

Yeah.

Yeah. The other thing that I was going to say is that, if it's a significant amount of refactoring, I'm going to have to do it on it, then I won't take it. But if it's something that's like, "Yeah, we'll have to pull this in and then make a couple of minor edits," then [inaudible].

One thing that bugs me is like changes with the trailing whitespace and things like that. I use vim for Ruby and it shows me the spaces, like the invisibles or whatever that's called, and so I'm like religious about deleting all of that extraneous whitespace. But in the Ruby community, if I were to pull up in a project and start cleaning up a bunch of files that I ran across, that certainly be in a separate pull request, just as whitespace clean up sort of pull request. In Xcode, they don't show that to you. So when I open up any kind of Objective C file in vim, I don't know, my eyes hurt a little bit because it's so common for it to do that.

Yup. Alright, well, I think we're getting close to the end. Is there anything else that we need to talk about with open source and iOS?

I just had one last question. It was just in regards to the open source stuff you guys are doing at Seesaw.

Sure!

It seems like you guys have quite a few projects here like phone number format or your little Seesaw ActivityIndicatorView and things like that. Do you see that trying to continuing and what is the reason why you guys put this out there?

I just looked in our pod file for the Seesaw app and there's 17 pods. Several of those are internal projects and then we have a couple more that are just separated out that aren't their own repo yet. But we have a good couple little internal apps and I like open sourcing that; as leading engineer, I want to do as much open source as possible. Like little things, we're probably -- we have a couple of things on the list like the way we used our camera and like the interaction are wrapping up AVFoundation and stuff, it's like on our list of things. There are several things we do all over the place, it's like, "This is silly. We should just open source this because there's probably little problems. And if someone else can like use it and if they want to fix those one [inaudible] will edge case because they ran to it, too, that's awesome, too." I mean I just think it's really nice like there's no reason not to; it actually gets us. Like formatting phone numbers isn't really like our core business so like who cares if you use our code. Hopefully, you can enjoy it, too.

That's awesome.

Alright, well, let's go ahead and do the picks. Ben, why don't you start this off with picks?

My goal here is to take all of Pete's picks by the time I'm done.

I've already picked. Done! [Laughter]

Me first! Me first!

No, I'm getting banger.

We're getting Sam first.

I have one related to open source and that's "semver.org". It's Semantic Versioning and it's just a pretty widely accepted practice for versioning your libraries, and I think you should adapt it. I think it makes whole lot of things easier. The idea is that you have MAJOR.MINOR.PATCH, and when you introduce just kind of bug fixes here and there, there's your patches, when you introduce new features, there's your minor versions, and when you make breaking changes, you rev the major version number. In doing so, you can allow people to depend on specific versions of your library, but also receive all of the bug fixes. So using something like bundler and Ruby or CocoaPods, you can say, "I want to make sure I get 1.5.X, where X can increase as I update." But I don't want to get anything later than that because some other pods depends on this version or whatever. So take a

look at semver.org if versioning eludes you. Two other things I had from my trip to WWDC, I bought one of those battery charges. The one I bought is "Anker Astro3E", it's 10000mAh power high capacity battery pack. It'll charge 2 devices, that has got 2 USB ports on the bottom. Man! That thing was awesome! I could carry it in the pocket of my backpack and just plugged my phone while I was walking around San Francisco. It would charge my phone from nothing to full almost 5 times. It self charges in about 8-10 hours, you just plug it in overnight. I had to charge it once while I was there, and it just made it so that I didn't have to worry about battery the whole time I was in San Francisco. However, it's a little bit slippery and it slipped out of my bag somewhere when I was traveling in Berkeley and I lost it.

[Laughs].

Oh, no!

So I'm probably going to buy it again, it was only $40. It's totally worth it if you need to travel and you're going to use your phone a lot. So I'll add a link to that in the show notes. My last pick is a card game that I ordered 6 months ago on Amazon, but it was backordered. It's called "Cards Against Humanity". It's kind of like Apples To Apples if you've ever played that, but the description is 'free party game for horrible people'. [Chuck laughs]

So it gives you a card like, 'The Smithsonian Museum of Natural History has just opened an interactive exhibit on blank' and then one of the cards will be like, 'Living in the trash can' or 'Midget clowns' or something. Just kind of ridiculous combinations and it's fun.

Their website used to have a place where you could like see some of the cards together and stuff, though.

Yeah, you can print them out, it's free. But if you want the box set and the nice cards, it's $25. But they were backordered for the longest time so I just pre-ordered out on Amazon. When it finally came out, they shoot it to me.

Yeah, I got picked on Ruby Rogues and we spent like a half-hour after the show looking at all the combinations that it would bring up on the website [laughs]. And I actually have one of the Anker battery packs and I was charging 2 phones on it like all day long [laughs] while we were on vacation time. So, they're awesome. Pete, what are your picks? [Crosstalk]

Yeah, I was going to be all those ones that Ben did so I got no picks. [Laughter]

Just kidding. My first pick is "Travis CI for iOS", that was a lot of acronyms. Travis is this open source, oh, not open source. It's this publicly available continuous integration setup that you can use to do stuff like compile your application and run test against your application. It's super duper awesome when in GitHub because whenever you get a pull request for your open source library or whatever, then Travis will actually run a build against that pull request and tell you, "Hey, it compiles but the test on passing," or whatever. And they reasonably recently announced iOS support so I've been setting up Travis for some of my iOS stuff and it works out great. It's a great kind of first screen for pull request. I wrote a blog post about using Travis and Facebook's xctool, which I think I picked before. So yup, Travis is bueno. My next pick is "Reading Application Licenses". If you have an app on your phone, like the Facebook app or whatever, and you want to know what open source libraries they're using, generally, if you kind of go and find the legal section, which is normally in Settings or About or something like that, they kind of obliged, especially if they're big company and they actually follow the less with the [inaudible], they're obliged to include a lot of the licenses for the open source components they use. So if you want to know what tools and app it's using, you can just kind of go spelunking through that. And it's really interesting if you pick like a really big app like Facebook; they're using a lot of open source stuff and you can kind of see all of the different open source things that they're using. So that's my second pick, and that's my last pick.

Awesome! Rod, what are your picks?

Okay, I'll see. My first pick is going to be "appcorekit.net" or "AppCoreKit", it's a iOS framework that I ran across this week end that looks really interesting. It adds support for models and valid automatic validation and data bindings. It's got cascading style sheets for changing the appearance of your app and generic collection controllers and adds a whole bunch of stuff to Cocoa, so it looks interesting. And then my second pick, I'm a tennis fan and Wimbledon's gone alright now. ESPN just released their "WatchESPN" App for the Apple TV so I no longer have to stream my iPad to my TV, I can just use the WatchESPN App, and it looks a lot better on the TV than it does on iPad. And those are my picks!

Awesome! Ben, what are your picks?

[Laughs] I have one more quick one, it's called "objectivechackathon.appspot.com". It's at this week end so people listening to this recording, it will already had passed.

Sorry!

But the spirit of it is still fine. But the idea is that CoffeeScript is subplanted, Objective C is in the top 10 languages on GitHub, and there's a community pushed to reverse that, so they have to put Objective C back on the GitHub map. The idea is that people are going to contribute to open source, submit a pull request, create a new open source library, or just push Objective C code to GitHub this Saturday. So if you're hearing this after the fact, then just pick your own private Objective C Hackathon Day and do that as well, and hopefully, we'll get Objective C back on the map.

I'm guessing at least part of that has to do with the fact that Rails adapted a while ago CoffeeScript as its default JavaScript thing.

Yeah.

I think that's part of it. Anyway, I've got a couple of picks. The first pick, I've been looking into some more (how do I say it) more residual income types of things. I like doing consulting and I love writing code, but it'd be nice to have a little bit of just residual recurring income coming in. So I've picked up a couple of resources that I want to share. The first one, it's called "Create Awesome Online Courses". If you're a fan of The Rise to the Top, it's done by David Siteman Garland, who host that show and does a whole bunch of other stuff on the web. So far, it's been terrific so I'm definitely going to be going through that and doing some of the stuff that he recommends. And you can also keep an eye out for some courses coming up in the near future. Also, another one is, I found a book on Amazon and it's basically "Writing a Non-fiction Book in 21 Days" and it walks you through the process of outlining and writing a book, and it's been really good as well. And the last thing that I want to pick is "Amazon Prime". The reason I'm picking that related to these other two is that Writing an eBook in 21 Days book was free to borrow for Amazon Prime subscribers, so I just picked that up. It already saves me more than I pay for it in shipping and things so I'm pretty happy that I'd pay for it, but that was just another perk that I was pretty happy with. Anyway, those are my picks. Sam, what are your picks?

I have two. One is "Kickoff App", it's a Mac and iOS app for project management with small teams. Drew and I used it to build Roon and it's spectacular. It's super beautiful on both Mac and iOS. It's kind of an issue model because it's like a one-time paid app and like the service are free, but it's super great. Second is, "redcarpet", I don't know if this is okay, but I'm doing it. [Ben laughs]

It's a Ruby library, it's by GitHub for Markdown parsing. I use it in Roon and it's spectacular. I actually contributed some C code to add to Markdown features, which I was a little proud of myself because I'm really terrible at C. But anyway, it's super awesome! So if you're doing Markdown or other things, it's spectacular.

Alright, cool. You said it was redcarpet?

Yes.

Because I think redcarpet was initially written by Why the Lucky Stiff and I think it's based off of that.

But there's also bluecloth and some other one.

Yeah, it was redcloth, that what it was.

redcloth and then bluecloth and then redcarpet.

CHUCK: bluecloth came off of it, yeah.

Yeah. It's already in C, those are purely ones. It's like sundown as the internal C library as this --

There was kind of a controversy around those C Markdown parsing library, do you remember that?

No.

I can't remember what the name -- it was called like libupskirt, and it was kind of --

Yeah, it's that one. They renamed it to sundown.

Oh, okay. [Laughs] I remember the guy got all kinds of bad press for that name.

Yeah, now it's sundown. Kind of funny.

Yeah.

Yup. Alright, well, let's go ahead and wrap up the show. Thanks for coming, Sam! It was good discussion!

Yeah, thanks so much for having me!

Yeah! High fives!

Alright, we'll wrap the show up. We'll catch you all next week!