Check out RailsClips!

02:28 - Samuel Giddins Introduction

• Twitter
• GitHub
• Blog
• Realm
  • @Realm

02:57 - The Limits of Modularity

05:53 - Where were/are cracks discovered?

• The 5 Whys

13:40 - Modularity in iOS/Swift Apps

• Dependencies
  • iOS 9 Beta Negative Reviews: MacBreak Weekly 463

16:48 - Boundaries

24:11 - Going Too Far With Modularity (Warning Signs)

35:45 - Getting Too Modular

• Too Many Views
• Networking
  • AFNetworking
  • NSURLSession
  • JXHTTP
  • ASIHTTPRequest Picks

RimWorld (Mike)Daniel Steinberg: Somewhere Between Tomorrowland and Frontierland (Alondo)AltConf 2015 Videos (Jaim)Joshua Marker: Mastering Time and Space: Testing the Objective-C Runtime (Jaim)remoteconfs.com (Chuck) God (Chuck) Jesus Christ (Chuck)The Church of Jesus Christ of Latter-day Saints (Chuck)Graham Lee: I Have No Idea What I'm Doing (Samuel)Tower (Samuel)Hopper (Samuel)opensource.apple.com (Samuel)

Transcript

CHUCK: Should we tell people that our podcast is in beta like iOS 9?[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York and L.A. bid on iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-15 introductory offers and an average salary offer of $130,000/year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It’s totally free for users, and when you're hired they also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]**[This episode is sponsored by DevMountain. DevMountain is a coding school with the best, world-class learning experience you can find. DevMountain is a 12-week full time development course. With only 25 spots available, each cohort fills quickly. As a student, you’ll be assigned an individual mentor to help answer questions when you get stuck and make sure you are getting most out of the class. Tuition includes 24-hour access to campus and free housing for our out-of-state applicants. In only 12 weeks, you’ll have your own app in the App store. Learn to code, it’s time! Go to devmountain.com/iphreaks. Listeners of Iphreaks will get a special $250 off when they use the coupon code IPHREAKS at checkout.] **CHUCK: Hey everybody and welcome to Episode 114 of the iPhreaks Show. This week on our panel we have Mike Ash. MIKE: Hello, good afternoon, from [inaudible]. CHUCK: Alondo Brewington. ALONDO: Glad to be back in North Carolina! JAIM: Hello, from Minneapolis. CHUCK: I’m Charles Max Wood from Devchat.tv, and we have a couple of things I just want to quickly announce. First off, if you’re interested in Ruby on Rails – I know this isn’t a Ruby podcast – but if you are, I just launched RailsClips so you can go check it out at railsclips.com. I’m going to put out two videos every week on Ruby on Rails. One will be ‘subscription only’ and the other will be free. So, at this point there are two free ones and one paid one; when this comes out, you can add to the list. And the other thing is I am looking for people who are struggling with getting started with testing Ruby on Rails, so if you know a company that needs somebody to come in and help them get things going, those are the people I’m looking for, so just let me know. We also have a special guest this week and that is Sam Giddins. SAMUEL: Hi, from San Francisco. CHUCK: You want to introduce yourself? SAMUEL: Sure, so I’m a Cocoa developer – Realm – Realm is a, well, you all know what Realm is, you had my co-worker JP on a couple of months ago. Long story short, I do heinous things to the Objective-C and Swift runtimes. I also work on a pair of dependency managers in my spare time – CocoaPods and [inaudible]. And I’m studying at the University of Chicago around all the other stuff. CHUCK: Very cool. Now, the topics that we have listed here is the limits of modularity. Do you want to give us a brief intro to that? SAMUEL: Sure. So, being someone who works on dependency managers, you can imagine that I like to argue that people should write modular code all the time. I love being that idealist who says, “You should do everything the right way,” and “It’s my way or the highway,” – you know, all those things. But I’ve seen – as I’ve worked more and more building bigger and more complex applications and tools – that there’s a downside to it, that there comes a time especially when going the modular code route where things can go horribly wrong just by doing the right thing. So this was an idea that I had after I launched the CocoaPods release a while back. Long story short, I forgot to update one of CocoaPods dependencies, release an update to CocoaPods, and CocoaPods stopped working, like you couldn’t have solved anything anymore. I said, “How could this happen? We run tests before doing every release, all these stuff is automated. We have everything in the [inaudible] sort of thing, so things are probably tested and I – I stepped back and I said, “Wait a second, this is happening because we’re doing everything the right way, I let my guard down, and oh, the test passed, the release passed – succeeded – everything’s got to be good.” You know, that was just an eye opener that maybe we were taking things too far. I had to think about that. CHUCK: So you have all these different pieces that kind of plugged in together, or were used? Are you talking specifically about different libraries? Or are you talking about language runtimes? Or–? SAMUEL: You know I really think that this is an idea that applies at any level. It’s most natural to think of it in terms of libraries because libraries have clear separations and you can clearly pick and choose between them, but it can happen for any sort of dependency, whether you think of it as a dependency or not. So when you’re building an iPhone app, you depend on a lot of stuff. You depend upon every framework that you link against, be it Apples or third party one; you depend upon, probably, specifics on how the device works. And there are all these different boundaries, and normally, when you start to build an app, all these boundaries, they fit together nicely like pieces of a puzzle. But as, you know, like imagine you’re doing a puzzle on a table and suddenly the topology of the table starts to change, you’re puzzle’s not going to fit together anymore, and the more different pieces that you have, the more you’re going to start to see cracks between them. ALONDO: Okay, so what you were mentioning in the example when you discovered this, that you were doing all the right things. So I’m curious as to, at this point, what pitfalls did you discover after going through a checklist maybe and saying, “Okay, we did all the things we were supposed to do, all the tests are working,” where were these cracks discovered? SAMUEL: We obviously weren’t doing everything perfectly correct. So the way the CocoaPods release process works, it automatically runs the test of the gem that we were trying to release. But what happened was it was running the test against the master branch of one of our dependencies – not the latest release version, and I forgot to release an update. So, the normal development process was fine but when it went to actually produce something that users would use, things turned out broken, in large part because I came to rely on the fact that, “Okay these dependencies all get releases when they need to; they all have their own test suites,” and stuff like that. Whereas if we had an automated things to that extent, I probably would’ve manually checked everything and discovered that, okay, I’m missing something. JAIM: Okay, are you familiar with the five ‘why’s? SAMUEL: No. JAIM: It’s a methodology – it’s originally from Toyota as part of a delete methodology. You know, something like if this goes wrong you step back and go, “Okay, why did this happen?”, “Okay, I didn’t update the dependency,” “Okay, why did that happen?” And the question is, you have to go back five times – ask five ‘why’ questions – to treat the root cause, like do you have any idea what that might be? It might [inaudible] said, Okay, we have someone – a single person working on this, and no one verified that he was doing it, which is a very common mistake that small team can do. SAMUEL: Sure, so in that case one of the answers you could get to was the CocoaPods team is not huge but it’s not a single person either. But that night I was doing a release I was sitting in a coffee shop by myself running the release script, you know, five or six times. So you could definitely say that the problem there was I was doing this alone. But to me, that isn’t really an interesting answer of what went wrong because that’s so often what goes wrong. Instead, I wanted to look at it as – as a situation in which – okay, I’m a developer, and so like most developers I’d like to give, out of my dish, pieces of advice because that appears to be worth the internet is for. You know, telling people they’re doing things wrong and to do your – things your way instead. So I love to do that and I was sort of following my own advice, and it became very apparent that things that fit together smoothly, or at least I though they did, weren’t really doing that. And instead of investigating what went wrong in this particular instance, I wanted to see what might actually be wrong with our development methodology, or what could be going wrong if we continue down this path of micro-frameworks, which has become all the rage; what could go wrong even if it looked like we were doing everything right. JAIM: So every time you say ‘right’, I envision scarecrows around the right. [Chuckles] Yes, there’s a right way of doing it and there’s a way that makes sense for what I’m trying to accomplish right now, or it’s what the business that I’m working with wants to accomplish. SAMUEL: I’m not sure if that’s – I mean, of course that’s hitting the problem, you know, hitting the nail on the head. There’s never a right answer but we love to come up with these, sort of, guidelines and call them the ‘scare quotes’ right thing to do. And of course the conclusion of this investigation was, do what makes sense for what it is you’re trying to build. Almost no one is, at the end of the day, trying to build up development methodologies. Of course not, you’re trying to build a tool or a product or satisfying your boss or fulfill that contract. At the end of the day that is your goal, and everything else is just a means to get there. So my goal is to build the best app that I can and give my users the best experience that I can. At the end of the day they’re not going to care how I got to that place. They’re not going to look at my code and see, “Oh, he built this app using Singletons. I can’t use this app anymore; I can’t enjoy it,” but I, of course, would argue that you can do a better job building a good experience if you stay away from things like Singletons, but that’s a means to an end. And, so of course building modular code is a means to an end; it’s a way for you to reuse code, it’s a way for you to better test the code that you have by splitting things out into more easily testable units. It’s a way for you to be able to reason about things independently. And instead of saying, “Okay, you know I have this whole huge app that does a million things,” instead, I’m going to focus on building up this – this one class that does a single thing and it can do it well and I can reason about how it works. And that’s all great, but what happens when you have a hundred of those, or a thousand of those that comprise your app? And, let’s say, believe it or not there’s a bug in one of them. You know, okay you can go and fix that bug – let’s say it’s all the way at the bottom of your dependency graph, how many changes are you going to have to make to make that to propagate to your app? CHUCK: Well, the other thing is, is if it’s at the bottom of your dependency graph – in other words it’s a dependency on a dependency on a dependency – then how hard is that to find? Because a lot of times I look at the stack traces that I get across much of my code is really – but I just ignore all of the code from the framework or the library and look at what I did wrong in my code, so if it’s clear down on my dependency graph, then it’s going to be tricky for me to find because I’m going to have to identify that the problem is in these libraries, you know, dependency on these libraries, dependency on this library and I’m going to have to track it down. But the flipside is though – and I just want to address this – is that I really like modular code. I mean, I like being able to pull on a component that sends e-mails. I like being able to pull on a component that handles specific responsibilities so that I don’t have to worry about them, and then provides me with a nice API. And I like being that glue code engineer. SAMUEL: Sure, I do, too. And, you know I tell those people that that’s probably the right way to go, but it’s not a silver bullet. Imagine, you know, you’re working on the Rails app and you run into a bug prodding into a webpage, how hard is that going to be for you to fix the bug that your users are experiencing? Because it’s in Rails, and then inside Rails it’s, you know, inside the router. Then inside the router it’s inside the specific part of the router. In all of that, over layers and layers away from code that you control, how hard is that going to be for you to make the changes that you need to? The answer is, it’s a lot harder than fixing a bug that is right there in your application code; and that’s something to keep in mind. CHUCK: Now, this is an iOS show. I know that CocoaPods, the web component of it is written in Rails, and that it has dependencies on other things outside of Rails. But I’m curious – have you seen this as much in Swift or Objective-C iOS apps? SAMUEL: Not quite to the same extent. I think the Cocoa community is still scared of dependencies in a way that many other communities are not. CHUCK: Well, you don’t have as many open constraints that you do in a web application. SAMUEL: Sure. I think one of the best things about being iOS developers that helps is we aren’t continuously deploying things and that gives us a lot of freedom to – we can use a library or not, we can use a library or – and then when we find bugs they’re typically not yet shipped and we can take the time to fix things or back changes out. But going back to properly answer your question, I’ve seen it to a certain extent in iOS apps, but that extent has been increasing overtime rather than decreasing. I’ve worked on apps that have way too many dependencies where developers have said, “All I want to do – ever – is just look at it.” And, you know, they find a dependency like they find a third party library for practically every view in their app. And, you know, they end up with four different networking libraries in their app because each dependency they have brings in its own networking library. And I’ve seen people start on apps like that and they just sort of close their eyes and sigh, and they know that their first month fixing that app is going to be hacking out this dependency hell. JAIM: Definitely have dealt with apps like that, but even if you’re writing custom apps like – the dependencies we depend are depending on change every year. We have a new version of iOS; if we’re doing anything, I’ll say the bounds of the simple things, it can break. So even though this is a much bigger problem, I mean the Ruby community which has tons more dependencies in a typical app, we still deal with this pretty regularly. CHUCK: Oh, totally. I was just listening to MacBreak Weekly, I think. I don’t know if it’s MacBreak Weekly or TWiT.tv but they were talking about the iOS 9 beta and they pointed out that some people were leaving negative reviews for apps that didn’t work on the beta. And you can’t release apps that are compatible with the iOS 9 binaries until they release iOS 9. And so – I mean this is a real problem that people really are going to encounter, and yeah, it may be a problem in one of the libraries or something you pulled off CocoaPods or Github that you brought in. It works great on iOS 8 and then fails on iOS 9. JAIM: It’s like we can barely run Xcode, [chuckles] and you want us to have the app that works? SAMUEL: Even worse, you can’t run Xcode 6 at all on El Capitan at the moment. Well, you can but–. JAIM: You’re not supposed to. CHUCK: It just depends on how brave you are. ALONDO: So I’m curious because this idea sort of hits home based on some stuff that I was working on yesterday – we were carrying on a project and it wasn’t dependencies, but it was actually all of our code within the – within our app. We were starting to do a bit of refactoring and we had – we’ve had some massive view controllers. And so we’re going in back to work of sort of creating, you know, lots of smaller classes with single responsibility. But I gave thought to this limit of modularity as well though, it’s just like it’s becoming – it can become a bit of a maintenance nightmare. Even debugging later because I’m having to jump through multiple classes to try to find out exactly where the root of a problem is, and then just organizing the code in Xcode because we’ve got two conflicting ideas about whether or not we should organize about function or organize it by, you know, type of box per class. Do you see the limits of having the same effects there within a project, not necessarily like a gem or some sort of external dependency? SAMUEL: Yeah, definitely. You know, again I don’t think it’s so much thinking about library – in terms of libraries or components but instead in terms of where are there boundaries between things? And it’s sort of engrained in us to think that boundaries between things are good. You know, boundaries make it easy to reason about the different pieces of something. But the limits that I’m thinking about are, what happens when there are a lot of these boundaries? And then at every one of them, maybe the code as you wrote it is perfect; it’s a beautiful code and everything is right at the right place and it’s great to look at – and then you need to change something. Maybe you’re pre-architecting what your views look like, and you discovered that, “Okay, so the way that I’ve organized this view hierarchy; it doesn’t work it. And all these view controllers that I have used to view models – like none of them match up with the way that I need them to anymore.” I’ve seen that happen quite a lot. And that’s actually kind of how we’ve end up as of view controllers because it’s a really convenient place to say, “Well, okay I just won’t have any boundaries between things so put everything in one place and I know if I need to change this detailed view, it’s all going to be there on that view controller somewhere.” And since it’s in that view controller, it’s not being used anywhere else, I won’t break anything else. And maybe it will be a bit harder to change things or editing a code, but it’s all there, I can see it all. You know, if I turn my 27 inch monitor sideways, use eight point font, I can see it all on one screen. CHUCK: So are you advocating that we, at least, until we have a need to encapsulate something so that we can reuse it, leaving it on the view controller or something like that? SAMUEL: No, I don’t think I – I didn’t get that. I actually don’t like being in the business of advocating [chuckles] for or against things. And instead I think it’s important that we treat writing code less as a proverbial monkey bashing up a keyboard and more of like an art where, for me, you start writing a single line, you take a step back and consider where does it belong? You know, what is the best approach to take to do this thing, rather than charging in and providing upon dogma to guide you? Instead, taking a step back and thinking, “What are the pros of doing it this way? What are the cons of doing it this other way?” And making conscious decisions about the way we did things rather that wildly charging forward. JAIM: Yeah, I think there’s a cark in every developer’s career. You start out just trying to get things to compile, and you try and get things to just work. And you get things to work, and then you realize, “Oh, maybe I should start refactoring some of these stuff,” and you start getting more modular code – you start doing that – and then you start over-thinking everything. [Chuckles][crosstalk] in some way. We might want this in the future, and then you go back to just getting things to work again until you know you need the modular or anything. But that’s something that everyone – I think every developer goes through that cark, and a lot of them get stuck and they make everything modular, but there’s an end to that. And if you pick the wrong boundaries, you’re making more headaches. A typical example of that is the collection view. You know, we’ve got a delegate and we got a data source, and it makes sense to split up – them into their own files. But if you do them separately, a lot of times I stop doing that. I just keep them all together, because in the weird sys where they depend on each other, or something that the client or the company I’m working for wanted to do and I’m like, “Oh, that’s made a big ball of mess because I wanted to separate the delegate and the data source in their own classes.” But it’s hard to find that line; it comes with experience, but what I’ve learned is that, don’t start doing that until you’re repeating yourself a number of times, but there’s other approaches. ALONDO: So in that scenario, Jaim, are you’re saying that now – or do you have the delegate and the data source still separated from the view controller in its own file? It’s just not having them separating into individual data source and delegate files? JAIM: Yeah, that’s pretty common horror factor that delegate-data source in one file and just call off the delegate. But being able to pull up both protocols, but they’re typically not in the view controller or I wouldn’t [crosstalk]. ALONDO: It just seems like a nice compromise, because I’m from a ping-pong in between the two extremes. I go – every other project, I go, “Oh, I really want to separate these stuff out,” then I go back to like, “No, I’ll put it all on the view controller.” But it seems like there’s a nice midway point in action. SAMUEL: Yeah, so about a year ago I was working on a small app from scratch, yeah, I decided, “Okay, I’m going to use this separate library that implements data sources in this really nice abstraction called ‘assess data sources’, and it was great until I needed to do something with, I think, custom table view headers. Yeah, I forgot exactly what it was but, you know there I was hacking on this app and I was just trying to get it done. And I needed to actually get the work done; I needed to make a change to this reusable data source class that was on a dependency. And so what would’ve been like five minutes to add a custom header viewer or whatever it was – instead it ended up being an hour of making the change in the library, documenting it, testing it, making a pull request, making sure to point my dependency at my fork until it was updated, pull request is accepted, point my dependency at master, a new release is made, update the dependency again – and all of these was just for this tiny app and I probably could’ve done it faster by copying and pasting the code. In the end it turned out well because now everyone else gets to use whatever delegate method it was that I input at it. But at that time it was definitely very frustrating of – it’s three o’clock in the morning and I’m a college student and I just want to get this thing finished. Instead, I was here taking the time to scare quotes – do things right and I, at that time, wishing for sleep and wishing I wasn’t doing that. JAIM: So how can you tell when you’re going too far at modularity? There’s some early warning signs? SAMUEL: Yeah, and I think that all the warning signs point to the same place. Whenever making a simple change starts to take way too much time, and not just one simple change. Whenever making any change takes too long and you see, “Okay, so I need to add this new label to my table view cell,” and that takes you a couple of hours, or “I need to add this new field to my API response format.” Or, “Okay, I need to switch some things around.” And if all those things start to take you forever to do, and it’s like ‘whoa’, conceptually the change I’m making is simple, it shouldn’t take that long. So when that starts to happen, it’s really – it’s usually a good sign saying, “Okay, put the mouse down, step away from the keyboard and just take a look at why simple things are turning out to be hard.” And usually it’s because there are just too many constituent parts to change anything. I know we love to make fun of Java programmers but by making up fine class names just by throwing in abstract and factory in – stuff like that – but if you’re looking through what you need to do and you see yourself having the set of classes that you should interact with each other and always interact with each other, that makes actually getting work done really difficult. So when I see that happen, I usually like to say, “Am I really getting a benefit out of this, or is it just costing me time frustration?” And if it’s just costing me time frustration, I’d go in and I’d copy paste code into one file or one class, and I could say, “Okay, now I can get work done again.” [Crosstalk] JAIM: It’s a universal symptom when something needs to change, when a simple thing becomes hard, and that’s the exact same problem you get when you dump all your code into the view controller, eventually, simple thing has become very hard. Singletons are dependent on each other depending on how you launched your app, you didn’t hang things and – things like that. But that’s a good point. If something simple becomes hard and it’s always hard, then it’s time to change the approach. ALONDO: Well I was also thinking about – in the scenario that’s given, is it possible that the answer’s not necessarily that the – that it’s sub-modular, or the number of abstractions, or that – that we originally conceive the abstraction alone. Maybe I wasn’t thinking through exactly that used case when that change is becoming difficult; that’s quite possible that maybe I didn’t take into account certain scenarios that I need to. Or maybe as a way to deal with that, maybe create composable abstractions made out of some of those modular parts that it was specific use case. SAMUEL: Yeah, that’s often the right way to go. It isn’t, you know, if you’re having a problem one way, don’t make yourself have the problem the other way. So if you have all your code in one massive view controller, don’t do the opposite and put each line of code in its own file. That’s just making it a different problem for yourself. I know that when Apple was originally developing UI kit as a framework for outside developers to use, they had this general rule of, “Is this a thing that’s being used in at least three of our different native applications?” If so, it probably belongs in UI kit. And I like to take that general idea of, “Is this an abstraction that’s actually being used in multiple places?” Okay, if so then it’s probably worth the pain of separating it out and dealing with wrangling code across these boundaries. But if it’s not, well why go through the extra trouble? Why put up barriers for myself if those barriers aren’t going to accomplish anything? JAIM: Yeah, that’s a good point. To get back to what you were saying, Alondo, that maybe you didn’t think through all the used cases for how you separate things out. And I use to run into these problems where I over-modularize things; I blame myself for not thinking of the future use cases. But that’s wrong thinking, because how can I possibly predict what this happens to be like in a year, or two years? You have no idea what the product donor or the business requirements will be. I used to blame myself but I realized no one could do that. Just wait until the patterns reveal themselves, like Samuel was saying. If you’re using it – this thing three times, then okay, maybe it’d make sense to re-think how we’re doing it, sort of copy paste, but it’s really hard to think through everything that might happen. ALONDO: Yeah, I definitely think that that’s, I think, expectation, because I have had the expectation that I would just – if I’m not making more modules then I’m doing it wrong, as if the maximum number of module or pieces is the ideal one. In reality, that’s really not, sort of like, continuum where you could move back along the extremes and you’re doing this piece somewhere in the middle, or maybe closer to one side or the other depending on your opinion. JAIM: Yeah, definitely. It just depends on whatever – what the problem you’re solving at the time is and what might change in the future. So that’s just – how hard can it change, it doesn’t matter what you do. SAMUEL: So interestingly, yeah, I went from building iOS apps for a while and there is typically – if I needed to do something, I could turn to a library and pull it in, and I got very used to that mode of development. And now here, working at Realm for very obvious reasons, we don’t just pull in dependencies when there are things we want to solve, and that’s a very interesting constraint to work with. And it’s not necessarily one that I’d recommend you to use for your big day app, but have you ever tried to build something and it’s like, “Whoa, this is probably a solved problem,” but instead, I’m going to try and resolve it. Sometimes you can come up with something that actually fits better than whatever dependency there is out there. So I’m trying to think of a good example of this. Nothing’s really jumping to mind but I love experimenting with stuff and rebuilding things, and I found that sometimes you can get something that’s a lot cleaner and a lot easier for you, personally, to maintain if you just build a small subset of features, rather than trying for that Swiss army knife solution. ALONDO: Yeah, I definitely agree with that. I think networking comes to mind with that. When there are a lot of popular libraries out there and they’re good, but sometimes the simpler solution is really all you need for your particular pace. And it goes back to your point about – in that situation that things change, you’re discovering that you’ve got these connected pieces, these dependencies, and they – because of your situation in your application, you’re going to have some issues, and we sometimes forget that most libraries were created – you know, they weren’t created at the backend; they were created to solve a problem that someone had. Even if they’ve added on additional features to accommodate various scenarios, they all sprung from some existing problem in reality. SAMUEL: I think you’d be surprised how many features don’t actually spring from real problems. ALONDO: Really? SAMUEL: Well, there are lots of developers like me who will start building something for fun and say, “Oh, this would be a cool feature to add.” And I’ve definitely written features that I’ve never used myself because there are always the broken ones. I remember when I was – back when I was in Tumblr, I was doing something with an API and a point that had existed for several years but it’d never been used. So you could say, “It’s in the API, it’s actually running on the publicly facing web servers, of course it works.” It didn’t. Yes it existed, but since no one had ever used it, it was totally broken. And I was working to a false sense of security of, “Oh, of course this API works because APIs always work; they always do exactly what they say they will.” And that’s generally only true for the things that are used. MIKE: That’s the best-suited point. I feel like that’s about 90% of my Github repositories. [Chuckles] Things I built for fun and then people started using them. And suddenly half the sphere that people are depending on things now, but I really want them to – [crosstalk] SAMUEL: Anything in particular coming to mind? MIKE: Uh, no not really. Pretty much all of it. SAMUEL: [Chuckles] Yeah, I know why. I’ve definitely written code and have said, “If you’re even thinking about using this in-production – whatever in-production means for you – like take a step back, turn off the computer, go to sleep, and then don’t use it. I’ve heard a half re-implementation of the Objective-C runtime, and I saw my Github, and sure it’s written and semi-documented and it works – there’s a test for it, but you’d be crazy to use that in production. JAIM: Just the man to do it. [Chuckles] SAMUEL: You know, there are two ends to this like knob-invented year syndrome. There are some people who say, “I will not use any code that I did not write.” And then there are the other people – and I was one of them when I was getting started – who said, “I’m really new to this; I’m not very good at development yet, if I’m honest with myself. This project has several hundred or a thousand stars on Github; I’m sure the person who wrote this is a lot smarter than I am,” and that’s a very dangerous trap to get into. It’s really – you want to be able to comfort yourself and say you can pick whatever is best even if you’re not the best, you can use code that the best developer wrote that, A, probably not as much better than you as you think and, B, what they were building wasn’t built for you. So this is something I run into fairly often working on frameworks. It is – I’m not actually user of the stuff that I build, so I work on building Realm everyday. And I’d like to think I do a reasonably good job, but I don’t actually have the perspective of one of our users. I use Realm through Realm’s unit tests. That is very – using something for its tests is very different that using it in an app. You solve a lot of different problems and you run into a lot of different use-case scenarios. And a challenge to keep that perspective when designing a library of – you don’t want to build something that’s really great to test because, guess what, there’s going to be one or two people writing a test for it, and there’s going to be orders of that kind to more people that are actually using it like a normal person. JAIM: So basically on your iOS experience, what are some of the common pitfalls for people who are getting too modular, like, the examples? SAMUEL: I think the number one example is people who are trying to create – in the iOS world, there’s definitely people who are trying to create too many different views to handle something. So you say, “Okay, so let’s think of how a dashboard, news feed type app works,” well you know, there’s going to be a post, and a post has a header. And the header has the user component of the header. And the user component to the header has the user profile view to it, and it has a couple of labels, and think how many views you could create with the view hierarchy for that. And it’s only ever going to be used in that one place. It’s really tempting to say, “Okay. So each of these different components is theoretically separate, so I’m going to put them in separate views,” and then when you go and change how that header is laid out, or you’re trying to add a new label, or you’re trying to add a new style that the view could be in, have fun, because you’re suddenly going to find yourself crossing all these different view boundaries, and you’re going to wish that didn’t flat to begin with, where everything was just a direct sub-view of the header view or whatever it is. JAIM: That makes sense. Can you think of other examples? SAMUEL: Networking as always. This is one where I think people having extra classes to handle different things, or networking-related, and you end up with having these single-used classes that end up all referencing each other, to do object mapping and json parsing, and constructing that work request and sending that work request, when in reality it’s all, sort of, one component, not a hundred different things. MIKE: [Inaudible] AFNetworking. [Chuckles] SAMUEL: You know I don’t like to point out the specific libraries, but I do think AFNetworking is an example of something that has been cargo culted for better or for worse. I know a lot of developers who have – who are as new as I am and they’ve never even seen NSURLSession or NSURLConnection, like they don’t know that those tools are ones that are available to them and built in. They go and say, “Networking is AFNetworking,” and they pull it in and they don’t ever take a step back and think, “Is there any other way to do networking?” MIKE: That’s an excellent point; I would bring this up. I had the pleasure of having [inaudible] at me, he said that to me, he said, “Just using an NSURLSession there, you don’t need all that other stuff.” He said it’s not that complicated to getting it to work. [Chuckles] JAIM: That’s true. But in those developers’ defense, pre-iOS 7, this thing have all the networking libraries, APIs were kind of painful to use. AF never really – it was a lot nicer back then. I think with iOS 7 and NSURLSession, that’s my default for most networking. Just do it and it works, it does everything I need to do, and I’ve worked on some pretty big apps so I’m pretty apt with, so I’d definitely say, “You know what, try this NSURLSession; works great.” SAMUEL: So at Tumblr, we actually didn’t even have – you know, with ARS there we didn’t even have the pleasure of AFNetworking, so our API client is – ‘their’, I suppose – I’m not there anymore – their API client is open source and it depends on this built in house networking library called JXHTTP that is used literally nowhere else but in the Tumblr API client which is used to the Tumblr app. And it was chugging along fine using NSURLConnection-based stuff. And that was all great until iOS 8 came, and shared extensions became a thing. And it suddenly became very important to try and be able to use NSURLSession. And because there were these layers of indirection, I ended up hacking in a way that the shared extensions could use like a different networking library, in this case it was just a single NSURLSession, but for the sake of expedience, I had to just subvert all of the existing stuff because it was the end of August and we obviously wanted to be on the app store with a shared extension Day 1 of iOS 8. JAIM: I’ve been through that pain whenever – what was the big networking library before AFNetworking? Like ASINetworking? MIKE: [Crosstalk] Yes I have – yes it was something – it was ASIHTTP or something like that. JAIM: Yeah, that’s the one that everyone used until the founder said, “You know what this is really hard. I can’t figure some of these same things out.” Use something else, and I have this code base which is just full of these code and I had to switch over to AFNetworking; and don’t do that, it’s painful. So I feel your pain. MIKE: Yeah, I had a similar experience of not working in that working library. When I first started at about being – 320 was popular, so I used that for a project and it was a nightmare trying to use the navigation and having to write our own anywhere. SAMUEL: Very fortunately that was before my time. I never got to experience the wonder that was 320. MIKE: You didn’t miss anything. [Chuckles] JAIM: Of course, even if you play in the rules and stick with Apple’s guidelines, if your app was designed for iOS 6 you were having a hard time when all of a sudden it came out. It’s just how it goes. ALONDO: Please don’t remind me. [Chuckles] SAMUEL: Yeah, the big one of those that I had was actually, again, last, last summer when we were fairly certain larger screen guy fans were coming. You’d be surprised how many of variations on the constant 320 there can be in a big enough app, so I literally spent a week taking these set of constants that weren’t actually constants in the Tumblr app, and trying to massage them to all the relative tool views with, and this was the case where I was cursing the fact that no one had done what could’ve previously been considered premature optimization, but in the grand scheme of things, it was probably the right call. We did the work we needed to do as it was needed instead of trying to predict the world happening. CHUCK: Nice. We’re about at our time. Any other things – questions that we should discuss before we get to picks? SAMUEL: I’d say my recommendation to people after hearing this isn’t ‘yes, do this’ or ‘no, do that’. It’s – think about what larger purpose your code exists for, and focus on that and let all the other development related stuff just be a means to that end. CHUCK: Very cool. Alright, let’s go ahead and get some picks. Mike, do you want to start us with picks? MIKE: Sure. This week, I’m going to pick a game called RimWorld, which is a lot of fun and I would like to share it with the world because other people don’t have the joy of running all the little ant farm, except it’s not ants, it’s people and they run around and shoot stuff and grow food and eat other people sometimes if you want them to. And it’s like Dwarf Fortress, which I think everyone might know about except it’s actually like, you can get in and play it without studying for getting a college degree and draw a fortress first. And it’s pretty cheap, it’s one of these really access games, it’s like one guy doing it all, does a great job, and it’s a lot of fun. I definitely recommend checking it out if you’re into crazy space things, except it’s not in space but it’s some sort of out-space it’s weird. It’s fun. CHUCK: Awesome. Is it on your Mac or–? MIKE: Yes, it’s a Mac and cross-platforms – so if you happen to run one of those evil platforms it can be really compare to not mobile, it’s not quite suited for that but it runs great on the Mac. CHUCK: Awesome. Alondo, do you have some picks for us? ALONDO: I have one pick this week and it is a talk from NSConf Daniel Steinberg did titled “Somewhere Between Tomorrowland and Frontierland”, and I really like it because it talks about solutions to a problem using object-oriented approach, and then do – solving the same problem using a functional approach. And then he takes it and does it – he makes a hybrid between the two, showcasing that you don’t really have to abandon object-oriented techniques just to embrace functional programming with Swift – the whole thing’s in Swift by the way, so it’s also a great talk. And Daniel Steinberg always does really great talks in my opinion, but this one really hit home this week just because I’m kind of learning Swift, and I think it was – it’d be useful to a lot of people. CHUCK: Very cool. Jaim, do you have some picks for us? JAIM: Okay, I’ve got one pick and most of you probably were not at AltConf but they just posted all the streams for all the talks, or most of the talks at least. So you can check out my talk, I talked about Swift developments for practical tips. Samuel, you’re out there as well as a lot of former guests on the show – Natasha the Robot, Michele Titolo – quite a few people – but the AltConfs talks are up so you could check them out. ALONDO: What’s your favorite one besides yours? JAIM: Mine, of course. [Crosstalk] SAMUEL: That goes without saying. [Chuckles] JAIM: Of course, and my second favorite was mine, but the third was – actually I got some practical use out of it. I don’t remember the name of it, it was at the same time as Natasha the Robot when he talked about how to test animations [crosstalk] we did that and that’s always the thing I was kind of haunted on. And I can give you the too-long-to-read or didn’t watch, but I never thought of it. Just click category on your UI view class and just call the complete block and, well, there you go, your animation’s are testable and you can do it, so that was a good talk. [Crosstalk] I didn’t get a link for it, but that’s my pick – all the AltConf talks. CHUCK: Alright, I’ve got a couple of picks. The first one is, I’ve been doing the online remote conferences, and I’ve decided to put them up into an RSS feed and host the videos on Devchat.tv. So, if you want to get them go to remoteconfs.com – I still need to put the RSS feed, URLs up. They are on iTunes, you can go find them in that way. So the JS Remote Confs are the ones that are going up right now. Ruby Remote Conf talks will go up after that. And then as I have other talks then we’ll see. So that’s what we got going on there. I also want to pick someone who’s been pretty involved in my life, and I feel like I have failed in not mentioning Him before. And this, you know, we pick things that make our lives better and God has made my life better so, I’m picking God. He sent His Son Jesus Christ, so I’m picking Him, too, to come and save us. So I just, I really appreciate everything that God does for me and my life, so I’m picking Him. If you’re also interested in more of how I look at God and my beliefs you can go at lds.org – that is the official website for the Church of Jesus Christ of Latter-day Saints. You can probably get a book of Mormon from there – not the musical, the actual book – the books are always better anyway. And if you’re interested we can also send missionaries out. Anyway, go check it out; you’ll find out a lot about the beliefs, Church leaders and all that stuff so–. Anyway, those are my picks. Sam, what are your picks? SAMUEL: Okay, so this actually isn’t one of them but – of the AltConf talks I’d say one of my favorites was Graham Lee’s about being comfortable asking questions as a developer. I believe the talk was entitled “I Don’t Know Anything” – something along those lines. So I have a pair of picks and I hope that’s okay. One of them is an app called Tower. It’s a GUI interface for Git. Yes, I know that command line is the canonical way to interact with Git, but sometimes it’s nice to be able to use a mouse to select things and selectively stage stuff for connects, so I use Tower everyday. It’s always open, except when it crashes, and that’s great. My other one is opensource.apple.com. So while most of the stuff that Apple does is not open source, we have to pop things like UI Kit and foundation into Hopper to see how they work under the hood. A lot of stuff is the large parts of the core foundation, especially – and also the entire kernel that runs on OS 10 is open source, so that’s called x and u, and I’ve spent days just reading that and trying to understand how everything works. CHUCK: Very cool. If people want to follow up on what you’re doing with CocoaPods or Realm or anything else, what do they do? SAMUEL: They can follow me on Twitter @scgiddins, or on Github which, I always joke, is my preferred social network, same username there. CocoaPods has a blog; blog’s at cocoapods.org. Realm has a blog, and of course all the things I do have Git reposts , so you can watch those as well. CHUCK: Very cool, I’ll give you a like and tweet about you on Github then. SAMUEL: [Chuckles] Excellent. CHUCK: Alright, well, I don’t think we have any other business, so thank you for coming– SAMUEL: Yeah. CHUCK: And we’ll wrap up the show, and thank everyone for listening.[This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter @MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]**[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]**[Would you like to join a conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]**