Under the Radar

00:00:00 ◼   ► Welcome to Under the Radar, a show about independent iOS app development.

00:00:03 ◼   ► I'm Mark O'Arment.

00:00:05 ◼   ► And I'm David Smith.

00:00:06 ◼   ► Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10 ◼   ► So after a couple of weeks of having topics that are a bit more conceptual and a little

00:00:15 ◼   ► bit more topical, I thought it would be fun to dive into something a little bit more technical.

00:00:19 ◼   ► Not too technical, don't be afraid if you're, if you listen to the show but you're not a

00:00:22 ◼   ► programmer, but something a bit more in the weeds.

00:00:26 ◼   ► And specifically, I kind of wanted to talk about code reuse.

00:00:31 ◼   ► And the degree to which it makes sense to take aspects of our programs and turn them

00:00:39 ◼   ► out and sort of cut them out and put them into libraries.

00:00:42 ◼   ► So you know, take a functionality and rather than having it be tailor-made for a particular

00:00:47 ◼   ► app, try to make it sort of somewhat more generic or reusable.

00:00:52 ◼   ► And specifically, this is something that I've been really, I would say, struggling with

00:00:57 ◼   ► recently as I've been working over this summer with my app updates.

00:01:02 ◼   ► Because I'm now in a position where I have a bunch of different apps that largely do,

00:01:07 ◼   ► they have very similar aspects to them at their core, but are very different in their

00:01:13 ◼   ► actual use.

00:01:14 ◼   ► You know, so but most of my apps now, all these health and fitness apps, all the plus

00:01:17 ◼   ► plus apps, use health kit in one way or another, for example.

00:01:23 ◼   ► And I keep finding myself going back and forth on whether or not I should take my, all my

00:01:30 ◼   ► sort of my health kit management and front-end code that deals with, you know, pulling data

00:01:35 ◼   ► in and out of health kit and authorizing things, and I should pull that out and turn it into,

00:01:39 ◼   ► you know, some grand unified library to deal with health kit.

00:01:43 ◼   ► Or if I should do what I have been doing right now, which is taking the approach of learning

00:01:49 ◼   ► lessons each time I kind of implement it, but ultimately having custom tailored solutions

00:01:55 ◼   ► for each of my apps.

00:01:57 ◼   ► And I feel like this is one of those things where ultimately there's probably not a right

00:02:01 ◼   ► answer.

00:02:02 ◼   ► It's sort of like a Vi and Emacs kind of a problem where there's just different ways

00:02:08 ◼   ► to do it.

00:02:09 ◼   ► Because both sides, you always have these pros and cons.

00:02:12 ◼   ► If you take something and make it super generic and like this is a great library that's super

00:02:18 ◼   ► reusable, that's great in concept and can sometimes give you some great benefits in

00:02:23 ◼   ► terms of, you know, if you find a bug, you can fix it for lots of different places.

00:02:27 ◼   ► But then you also have the downsides of now you have all these other complexity to manage

00:02:33 ◼   ► in terms of if you make a change in your library, it could potentially affect all your apps

00:02:37 ◼   ► at once and in ways that you aren't expecting.

00:02:40 ◼   ► Maybe one of the apps is expecting that bug to be there because it's sort of had coded

00:02:44 ◼   ► around it or against it.

00:02:46 ◼   ► And it can make things really complicated, but intellectually or academically, it seems

00:02:50 ◼   ► like that's a better thing to not repeat your code or similar code in multiple places.

00:02:56 ◼   ► Or you can be super pragmatic and say like each of these apps has the tailor-made solution

00:03:02 ◼   ► for it.

00:03:03 ◼   ► And in some ways that seems really good.

00:03:06 ◼   ► And so I keep going back and forth about it.

00:03:08 ◼   ► And ultimately, I think I tend to almost always go on the side of just tailoring a custom

00:03:15 ◼   ► solution to each of my applications and just giving myself permission to be okay with the

00:03:20 ◼   ► fact that that means that I have in my code base at large, there are bits of code that

00:03:25 ◼   ► are repeated and just say like that's okay.

00:03:30 ◼   ► That's not theoretically or academically the best, but that kind of works for me.

00:03:33 ◼   ► But I was curious to hear what you do, Marco, because obviously you don't have as many different

00:03:37 ◼   ► apps as I do, but you have built a number of apps for long enough that I imagine you

00:03:42 ◼   ► have a lot of things that you could kind of turn into libraries and reuse them.

00:03:47 ◼   ► And how do you tend to approach doing that?

00:03:50 ◼   ► I mean, so you're right.

00:03:52 ◼   ► I don't really face it as much as you do because I just don't have very many apps I'm working

00:03:57 ◼   ► on at any given time.

00:03:59 ◼   ► But I do build up common libraries, frameworks, things like that just over time.

00:04:06 ◼   ► I think many programmers do this, if not most.

00:04:10 ◼   ► I hesitate to say all because who knows what everyone else does, but I would guess this

00:04:13 ◼   ► is very, very common that everybody kind of builds up their own kind of personal collection

00:04:17 ◼   ► of utilities and things that they like to use.

00:04:21 ◼   ► There's always, as you said, there's always this kind of balancing act where if you try

00:04:25 ◼   ► to make something that is generic and reusable and stable for use in multiple apps and everything

00:04:32 ◼   ► and it handles all the various edge cases that any kind of different use could have,

00:04:37 ◼   ► it is a lot more work to make that thing.

00:04:39 ◼   ► To make whatever component that is, it's more work and you might never save that work.

00:04:46 ◼   ► You might never reap the benefits of that because you might put all this effort into

00:04:49 ◼   ► making something reusable and then never reuse it.

00:04:51 ◼   ► Or reuse it in one other place where a copy paste would have been fine or re-implementation

00:04:56 ◼   ► wouldn't have been that much work or whatever else.

00:04:58 ◼   ► So there's the whole angle there of whether you make something reusable and generic at

00:05:04 ◼   ► all or not or whether you just kind of stick it into your app in some kind of semi-orthogonal

00:05:09 ◼   ► way that is semi-generic and just kind of hope for the best and just keep going and

00:05:14 ◼   ► get your work done.

00:05:15 ◼   ► And so I find myself doing this with a small collection of things.

00:05:19 ◼   ► So in Overcast what I do is, I have my public collection of open source utility things called

00:05:28 ◼   ► FC utilities for my company Full City Utilities.

00:05:33 ◼   ► And we'll talk about open source a little bit later.

00:05:35 ◼   ► I've actually debated pulling it down and closing the source again just because maintaining

00:05:39 ◼   ► it is kind of a pain in an open way.

00:05:42 ◼   ► But we'll get to that.

00:05:43 ◼   ► So I have FC utilities as like this kind of separate collection of generic utilities.

00:05:49 ◼   ► And then in Overcast I have a private, just a folder, like a group in Xcode, just a folder

00:05:55 ◼   ► of files that I call FC utilities extras, which is like components that I make that

00:06:01 ◼   ► I think might be reusable someday.

00:06:03 ◼   ► It's kind of like a staging area before they go into the main library of my open source

00:06:08 ◼   ► and shared components.

00:06:09 ◼   ► Kind of like a staging area of things that, you know, I'm making this code that this might

00:06:14 ◼   ► be useful.

00:06:15 ◼   ► I might reuse this.

00:06:16 ◼   ► I'm going to write it in a way that it could be reused.

00:06:18 ◼   ► I'm going to write it in that kind of generic, reusable, edge case compatible way of a level

00:06:24 ◼   ► of quality that I would expect from that.

00:06:26 ◼   ► But I might never release it.

00:06:28 ◼   ► Or I might never use it anywhere else.

00:06:29 ◼   ► So I kind of had this kind of middle area that helps me decide or that gives me a place

00:06:33 ◼   ► to put things like that that are kind of, you know, in the middle or in a gray area

00:06:36 ◼   ► or underdeveloped in that way.

00:06:39 ◼   ► And I do find myself needing to reuse things between Overcast and occasional other things.

00:06:48 ◼   ► So occasionally it might be something else in iOS, although that's rare because I don't

00:06:51 ◼   ► usually do multiple iOS apps at once.

00:06:55 ◼   ► But I do have now, as I mentioned last episode, I am making a Mac MP3 kind of toolkit app

00:07:04 ◼   ► for putting chapters in podcasts and stuff.

00:07:07 ◼   ► And so I am dealing with a lot of the same kind of low level audio handling, MP3 handling,

00:07:13 ◼   ► reading and writing of chapter metadata, stuff like that.

00:07:16 ◼   ► I am having a lot of things now where I need code reuse.

00:07:20 ◼   ► And I have faced this dilemma multiple times.

00:07:22 ◼   ► Do I consolidate, you know, Overcast tag reading thing into this tag reading thing and make

00:07:27 ◼   ► it one thing?

00:07:29 ◼   ► Or do I share this low level audio reading code or not?

00:07:33 ◼   ► And then when I do want to share it, what are the mechanics of that?

00:07:38 ◼   ► Do I just copy the .c and .m file over?

00:07:40 ◼   ► Or the .h and the .m file over?

00:07:44 ◼   ► And copy it into the new directory?

00:07:45 ◼   ► And that has a lot of advantages in simplicity and in lack of any kind of external dependency.

00:07:52 ◼   ► But that also kind of sucks from a version control standpoint where if you then improve

00:07:57 ◼   ► it in one place, the other one doesn't get that improvement.

00:08:00 ◼   ► Or if you fix a bug, the other one doesn't get that bug.

00:08:01 ◼   ► And you have to either just not backport it or manually switch it over or copy it back.

00:08:07 ◼   ► And obviously we try to avoid those kind of hacks in programming these days because we

00:08:12 ◼   ► know as a practice that's generally a bad thing.

00:08:17 ◼   ► So then do I make a library?

00:08:20 ◼   ► Do I make an actual, like...

00:08:24 ◼   ► Do you actually use dynamic libraries in iOS?

00:08:29 ◼   ► I never have, no.

00:08:30 ◼   ► Like you can talk about things in, like, when you build stuff with Carthage or you could

00:08:34 ◼   ► build them manually.

00:08:35 ◼   ► Like, I've never gone down that road.

00:08:37 ◼   ► Because I always find myself thinking, the inertia I have to overcome before I was like,

00:08:42 ◼   ► "Okay, this is worth going through this process."

00:08:45 ◼   ► Where now suddenly it's this whole, like, building my app is not just as simple as hitting

00:08:49 ◼   ► build in Xcode.

00:08:50 ◼   ► Like, there's dependencies I need to manage and version control that I need to keep track

00:08:54 ◼   ► of.

00:08:55 ◼   ► And if I want to rebuild a particular version of my app, that's now a more complicated question.

00:09:01 ◼   ► It's not just like, check out of Git, the tagged version for that release, and say,

00:09:07 ◼   ► like, this is the code.

00:09:08 ◼   ► And I also then need to make sure that it's pulling in the right dependencies and all

00:09:11 ◼   ► that kind of stuff.

00:09:13 ◼   ► So I've never gone down that road.

00:09:14 ◼   ► But I know what you're talking about, where you turn it into something that's a much more,

00:09:18 ◼   ► you know, into a concrete version of that dependency and say, like, this is the library

00:09:25 ◼   ► that I'm going to add into my project.

00:09:27 ◼   ► Yeah.

00:09:28 ◼   ► I mean, I generally have a kind of allergic reaction to any kind of overhead of fighting

00:09:35 ◼   ► with my tools on things like module management and, you know, submodules, libraries, any kind

00:09:44 ◼   ► of, like, dependency managers.

00:09:46 ◼   ► Like, these things can so often become such massive time sinks and such pains in the rear.

00:09:52 ◼   ► And a lot of times, I don't feel like the benefit I'm getting by dealing with that is

00:09:58 ◼   ► worth all that pain.

00:09:59 ◼   ► You know, a lot of times, I feel like I'm just fighting the tools for, like, an hour

00:10:03 ◼   ► or more to just do something simple, like, okay, I want to reuse this code in a way that

00:10:07 ◼   ► is, like, you know, academically sound, like, that is, like, principally sound.

00:10:13 ◼   ► You know, so maybe it's a Git submodule or a subtree or maybe it's, you know, just requiring

00:10:20 ◼   ► a second checkout that's, like, in parallel with this one, like, you know, at the top

00:10:24 ◼   ► level directory.

00:10:25 ◼   ► Like, oh, just include dot dot slash utilities slash whatever and just require you to always

00:10:30 ◼   ► have that checked out, which is also a terrible solution.

00:10:34 ◼   ► And then you have, you know, whether you build it as a library or whether you just link it

00:10:38 ◼   ► all in as, you know, from source files into every app that uses these things.

00:10:42 ◼   ► And there's all these kind of, like, technical and management different decisions you can

00:10:46 ◼   ► make about how you incorporate code from other places, whether you just copy it in, you know,

00:10:52 ◼   ► just copy the files in or whether you do it, quote, properly with some kind of submodule

00:10:55 ◼   ► or subtree or library kind of system.

00:10:58 ◼   ► And, again, it's just so much overhead.

00:11:01 ◼   ► And I just so often when I do that, I feel like I'm just fighting the tools and moving

00:11:06 ◼   ► paper around.

00:11:07 ◼   ► I mean, it feels like administrative work.

00:11:09 ◼   ► It doesn't feel like I'm actually producing much.

00:11:12 ◼   ► And so often that work is not worth it because it brings on such an incredible level of complexity

00:11:18 ◼   ► and just fiddliness and fussiness and fragileness or fragility, whatever the word is, to just

00:11:24 ◼   ► something simple.

00:11:25 ◼   ► Like, okay, I want to check out everything required to build this app from the source

00:11:29 ◼   ► repository and then I want to build it.

00:11:31 ◼   ► How hard is that?

00:11:32 ◼   ► How many steps does that take and how many ways can that break?

00:11:36 ◼   ► And so often when you get into some of these systems, it just gets unwieldy.

00:11:39 ◼   ► Sure.

00:11:40 ◼   ► And even you start to think about things where you say, oh, like, I don't actually do that.

00:11:44 ◼   ► I mean, this is the kind of thing that I say to myself a lot.

00:11:46 ◼   ► Like, I'm one developer.

00:11:48 ◼   ► I don't have to deal with, like, a lot of the usual complexity even of if I have to

00:11:53 ◼   ► check this out and get a building.

00:11:56 ◼   ► Because when you have a larger team, keeping everybody in sync is a much more difficult

00:12:02 ◼   ► problem.

00:12:03 ◼   ► But I certainly run into this situation a lot where, say, I'm going out of town for

00:12:09 ◼   ► a week or for a couple weeks, or I'm going to WWDC or something like that.

00:12:13 ◼   ► I want to make sure that I can build my main apps when I'm on the road in case something

00:12:19 ◼   ► comes up.

00:12:20 ◼   ► You never know.

00:12:21 ◼   ► I've done release builds to the app store while I was on vacation because some weird

00:12:26 ◼   ► situation occurred.

00:12:27 ◼   ► Like, that's not what I try to do, but that's certainly something I want to be able to do.

00:12:31 ◼   ► And the worst thing that you can run into that situation is when you're doing that kind

00:12:34 ◼   ► of work, and then all of a sudden you're like, oh, I don't have that file that I need from

00:12:39 ◼   ► my main Mac because it wasn't checked into the main repository or something.

00:12:46 ◼   ► And even just being a one-man shop, I'll still run into that problem.

00:12:50 ◼   ► And so I always find it's this weird tension too.

00:12:53 ◼   ► I feel like in so many things in programming you have this tension between doing it the

00:12:59 ◼   ► right way.

00:13:01 ◼   ► And the supposed benefit of doing it the right way is that it's like in aggregate or over

00:13:12 ◼   ► the course of the whole development project, you'll end up better.

00:13:15 ◼   ► And you'll think yourself two years down the line when you've saved yourself all this time

00:13:20 ◼   ► or hassle or saved all these bugs or issues.

00:13:24 ◼   ► That's the promise that all this work is paid off by.

00:13:29 ◼   ► But it's the weird thing of that it sounds good when I was learning computer science

00:13:35 ◼   ► in college or something, where you get into design patterns.

00:13:39 ◼   ► And it's like, well, what you really should do is have this really generic system by which

00:13:44 ◼   ► you can have a factory that creates observers that are loosely coupled to your actual model

00:13:51 ◼   ► objects and then you can dynamically change that in and out if you change database backends.

00:13:57 ◼   ► You can invent all these systems that sound academically really cool and have these abstract

00:14:03 ◼   ► benefits that are tangible and sound sweet.

00:14:08 ◼   ► But I was so rarely--maybe there's a slight selection bias to it, but I don't think that's

00:14:15 ◼   ► actually the case.

00:14:16 ◼   ► And I think more often than not, I've never really reaped those benefits down the road.

00:14:21 ◼   ► I don't look back and be like, "Oh man, I'm so glad I went through all this effort to

00:14:25 ◼   ► put all these armatures in place to make my app work better rather than just coding and

00:14:33 ◼   ► just putting it together."

00:14:34 ◼   ► And certainly there's some amount of that.

00:14:38 ◼   ► It's probably kind of like if you're a chef or something like that, where if you watch

00:14:44 ◼   ► cooking shows and you watch chefs cut vegetables with ridiculously sharp knives, ridiculously

00:14:49 ◼   ► close to their fingers, it's not the way that you teach your kid to cut vegetables in the

00:14:57 ◼   ► kitchen.

00:14:58 ◼   ► For them, you're like, "Hold the carrot way on the other end and keep the knife far away."

00:15:04 ◼   ► And maybe that's what you would need to do.

00:15:07 ◼   ► And when you're starting out programming, everything's safer, everything's a bit cleaner.

00:15:13 ◼   ► But as you get good at it, after you've been a professional developer for a long time,

00:15:18 ◼   ► I feel like I kind of have more of an intuition for these types of problems, where I look

00:15:23 ◼   ► at it and sometimes I will make things more abstract, or I'll pull things out.

00:15:27 ◼   ► And sometimes I'll just copy-paste the same function twice, sometimes even in the same

00:15:33 ◼   ► project.

00:15:34 ◼   ► I'll have this basic, very similar functionality repeated a couple times, and it's like, "I

00:15:38 ◼   ► could take this and make it generic, but if I did that, I'm aware of all of the downsides

00:15:44 ◼   ► of that and all the issues that are later going to come and bite me."

00:15:49 ◼   ► And often those issues are more direct and practical, rather than the kind of abstract

00:15:53 ◼   ► benefits and things that I'm avoiding by being abstract.

00:15:59 ◼   ► And I feel like that intuition is the thing that's so unsatisfying to me about this, because

00:16:03 ◼   ► I wish I could put it into a rule.

00:16:05 ◼   ► I wish I could say, "When you're doing this, if you're writing code that would..."

00:16:12 ◼   ► I try to come up with rules like, "Would this make sense if Apple released it as an addition

00:16:18 ◼   ► to Foundation or an addition to UIKit?"

00:16:21 ◼   ► And if they would, if I could imagine Apple adding something like that, then maybe it

00:16:26 ◼   ► makes sense as a library.

00:16:28 ◼   ► I run into this with date comparisons or things like that.

00:16:31 ◼   ► A lot of my apps have a concept of, "What's the start of today?

00:16:36 ◼   ► What's the end of today?"

00:16:37 ◼   ► Very basic date operations that I do a lot for, in pedometers, saying, "Which range of

00:16:43 ◼   ► steps should I display?"

00:16:45 ◼   ► It's like, "Well, it's from the start of today till the end of today."

00:16:48 ◼   ► And I have pulled those into a bit of libraries because I would be entirely reasonable if

00:16:53 ◼   ► NSDate had a function on it that said "Start of date" or "End of date."

00:16:58 ◼   ► And so that seems like that makes sense, but anything that wouldn't make sense that isn't

00:17:04 ◼   ► like...

00:17:05 ◼   ► It's almost like you need...

00:17:06 ◼   ► Maybe the better rule is to say, "In order for it to make sense to have a generic solution,

00:17:10 ◼   ► it has to be a generic problem rather than a generic solution to a specific problem,"

00:17:17 ◼   ► or something like that.

00:17:18 ◼   ► Maybe that's kind of where I'm ending up as I'm talking this through, for turning something

00:17:23 ◼   ► into something that's a generic reusable thing only makes sense if it is a truly generic

00:17:28 ◼   ► problem that it's trying to solve.

00:17:29 ◼   ► Yeah, I'd say that's a very good rule, and we'll get into open sourcing and how that

00:17:33 ◼   ► plays in in a second.

00:17:35 ◼   ► But I also just want to add a little bit, just to clarify a point you made a few minutes

00:17:38 ◼   ► ago, which is I think we put in all this work to make things correct, the correct way to

00:17:44 ◼   ► do things, or the professional way to do things.

00:17:47 ◼   ► A lot of this work of avoiding duplication and trying to make things reusable and making

00:17:51 ◼   ► things modules and all the work that goes into that, it is kind of like to avoid this

00:17:57 ◼   ► boogeyman of future bugs or future inconvenience even, future manual labor.

00:18:04 ◼   ► We are all so averse to that that we're willing to put in a large amount of work now upfront

00:18:11 ◼   ► to prevent possible future work down the road.

00:18:15 ◼   ► But a lot of times the amount of work required that we're doing upfront is not worth it,

00:18:20 ◼   ► because we might have to put in lots of work now to avoid a potential future inconvenience

00:18:27 ◼   ► or bug that in reality will probably never happen.

00:18:31 ◼   ► And we have to always keep in mind, what is that balance?

00:18:37 ◼   ► Is what we're doing really demanding, or is the work we're putting in now really

00:18:44 ◼   ► worth it compared to the problem that we're going to avoid down the road?

00:18:48 ◼   ► How bad will that pain be if it comes?

00:18:51 ◼   ► And is that worth doing all this work now and spending all this time now?

00:18:56 ◼   ► Anyway, our sponsor today is CocoConf.

00:19:00 ◼   ► The upcoming March 20th to 23rd CocoConf will be returning to Yosemite National Park for

00:19:05 ◼   ► its third Yosemite event.

00:19:07 ◼   ► Man, I hear great things about these, I hope I can go this year.

00:19:10 ◼   ► This event will be held again at Yosemite Lodge at the Falls in Yosemite National Park.

00:19:15 ◼   ► Speakers include Ashley Nelson Hornstein, friend of the show David Smith, Andy Anotko,

00:19:22 ◼   ► Matt Drance, Jamie Newberry, Brent Simmons, and Daniel Steinberg.

00:19:26 ◼   ► That's a great lineup.

00:19:28 ◼   ► Sessions run in the mornings and evenings.

00:19:30 ◼   ► Afternoons will be spent exploring Yosemite National Park with activities including ranger-led

00:19:35 ◼   ► hikes, a bus tour of the valley, and a photo walk led by TED photographer James Duncan

00:19:39 ◼   ► Davidson, also a great person.

00:19:41 ◼   ► There will be music by James Dempsey in the Breakpoints, another great person.

00:19:45 ◼   ► And Jonathan Songadayman, man, this is a great lineup.

00:19:48 ◼   ► You can use the code UnderTheRadar, that's once again code UnderTheRadar to save 20%

00:19:53 ◼   ► on your tickets to Yosemite.

00:19:54 ◼   ► Head on over to CocoConf.com/Yosemite to register.

00:19:59 ◼   ► Man, that's a great event, great lineup.

00:20:02 ◼   ► Anybody who can go to this should go.

00:20:04 ◼   ► CocoConf.com/Yosemite, code UnderTheRadar for 20% off.

00:20:08 ◼   ► Thank you very much to CocoConf for sponsoring UnderTheRadar.

00:20:12 ◼   ► So I want to talk a little bit about the role that open source has in common functionality,

00:20:19 ◼   ► open sourcing your common libraries, things like that.

00:20:21 ◼   ► I have a little bit of experience with this, not a lot really, but a little bit with things

00:20:26 ◼   ► like my database layer FC model, which is kind of like an alternative to core data that

00:20:31 ◼   ► uses SQLite more directly.

00:20:33 ◼   ► I also have, as I mentioned, my open source utilities, FC utilities.

00:20:38 ◼   ► One thing that's changed a lot for me recently is when GitHub recently switched their pricing

00:20:44 ◼   ► model for private repositories.

00:20:45 ◼   ► And it used to be that you could do as many repositories as you want in the open for free,

00:20:51 ◼   ► but they had these paid plans and they were tiered based on how many private repositories

00:20:57 ◼   ► you needed, plus a few other things that didn't affect me.

00:21:00 ◼   ► So it's like you could pay X dollars a month for five private repositories, and then if

00:21:04 ◼   ► you wanted six, you had to jump up to another price tier.

00:21:07 ◼   ► So it basically had this incentive to not create very many private repositories.

00:21:11 ◼   ► And they recently changed that so that now it's basically like if you pay them at all,

00:21:15 ◼   ► you can create as many private ones as you want.

00:21:17 ◼   ► So what I've been doing recently is for these kind of small utility libraries and things

00:21:24 ◼   ► like that, I've just been creating private Git repositories and then using submodules.

00:21:30 ◼   ► And I mentioned earlier, submodules can be a big pain, but every alternative that people

00:21:35 ◼   ► have told me to use over the last few months as I've been exploring this kind of functionality,

00:21:40 ◼   ► I find every alternative to be either the same or worse in complexity.

00:21:44 ◼   ► So here's my top tips for using submodules.

00:21:47 ◼   ► Number one, use Git Tower.

00:21:49 ◼   ► It is an app, it's a GUI app for Mac and I think soon to be Windows.

00:21:54 ◼   ► It's called Tower or Git Tower, depending on what page you look at.

00:21:57 ◼   ► It's something like, I don't know, 60 bucks.

00:21:59 ◼   ► Just get it.

00:22:00 ◼   ► It is so much better than dealing with command line for submodule management.

00:22:04 ◼   ► Second thing that I recommend is, so use it to add your submodules.

00:22:08 ◼   ► For any Git repository that you have any control over whatsoever, whether it's a fork of some

00:22:15 ◼   ► public one or whether it's one of your own, always connect to it using the Git SSH URL.

00:22:21 ◼   ► Don't use the HTTPS URL.

00:22:23 ◼   ► If you do those things, if you use Git Tower and always use the Git SSH checkout URLs,

00:22:29 ◼   ► then you get this amazing balance of functionality where you have all these submodules in your

00:22:34 ◼   ► project.

00:22:35 ◼   ► You can easily check them all out at once using Tower because for some reason Git doesn't

00:22:37 ◼   ► do that by itself because I don't know why because Git is just obtuse and hard to use

00:22:42 ◼   ► by itself.

00:22:44 ◼   ► But then you can, so you have like version stability because it's part of your checkout

00:22:48 ◼   ► is what version of all these things you're using and then if you want to work on one

00:22:53 ◼   ► of those submodules from that checkout, from within the app that is using it, you just

00:22:58 ◼   ► change the file.

00:22:59 ◼   ► You just make the edit and you just go into Git Tower, go into that submodule and commit

00:23:02 ◼   ► it and you can do all that without having to like, all right, first back out to my main

00:23:06 ◼   ► checkout of this thing and do the edit there and then copy it back or whatever.

00:23:10 ◼   ► It's so much better and I've tried so many other ways to do this and believe me, the

00:23:13 ◼   ► other ones are mostly terrible.

00:23:15 ◼   ► If you're doing a lot of code reuse, especially if it's mostly your own code and especially

00:23:19 ◼   ► if it's a private code, Git submodules with private Git repositories managed by Git Tower

00:23:24 ◼   ► is fantastic.

00:23:25 ◼   ► >> Whoa.

00:23:26 ◼   ► >> Yeah, sorry.

00:23:27 ◼   ► >> Yeah, no, that's, it's, I've, my only experience with submodules has always just been I try

00:23:36 ◼   ► it for like a couple hours to try and get something to work and then I just give up

00:23:40 ◼   ► and like check it out, copy the files over and move on with my life.

00:23:43 ◼   ► >> Yeah, I mean just never touch the command line when it comes to Git submodules.

00:23:46 ◼   ► Like and you know, I am command line heavy with so many things.

00:23:50 ◼   ► Like I mentioned before, like I always use MySQL, MySQL, I always use that through the

00:23:54 ◼   ► command line.

00:23:55 ◼   ► I never use, you know, GUI apps to do MySQL stuff.

00:24:00 ◼   ► I will use the command line for almost everything that can be done by the command line but I've

00:24:04 ◼   ► slowly converted over to using Tower for any kind of Git operation and it is just, once

00:24:09 ◼   ► you just give in and just do it for everything, it's so much nicer.

00:24:12 ◼   ► It's really great and for the submodules thing, do as I said before and it's great.

00:24:17 ◼   ► Open sourcing, we have a few minutes left about this.

00:24:20 ◼   ► Have you done any open sourcing?

00:24:21 ◼   ► >> I've never open sourced anything, not a thing.

00:24:25 ◼   ► So as I mentioned, I've only open sourced a couple things.

00:24:29 ◼   ► I've had mixed success.

00:24:30 ◼   ► I would say FC model, my database layer has been the most successful open source project

00:24:35 ◼   ► and it doesn't even have that much external contribution or external bug reporting.

00:24:42 ◼   ► As far as I can tell, there's only a handful of people even using it.

00:24:46 ◼   ► The main challenge with open sourcing things is that there is a cost to doing it.

00:24:51 ◼   ► You are adding work for yourself by open sourcing things.

00:24:54 ◼   ► You are exposing yourself to possible liabilities of weirdness of legal stuff or functionality

00:25:00 ◼   ► stuff or hacking stuff.

00:25:01 ◼   ► That's not too much of a concern for most people but it's mainly you're just adding

00:25:05 ◼   ► work for yourself.

00:25:07 ◼   ► You also might be giving advantages to your competitors but that's also kind of not really

00:25:10 ◼   ► a concern for most people for the kind of things you'd be open sourcing.

00:25:14 ◼   ► I have found that the value you get out of open sourcing of oh, you'll have other people

00:25:18 ◼   ► contributing improvements and fixing bugs and maybe facing security problems, that only

00:25:23 ◼   ► happens if you're open sourcing something that a lot of other people will need and use.

00:25:29 ◼   ► For most stuff that you're going to be open sourcing, that just doesn't happen.

00:25:32 ◼   ► I open sourced my FC utilities utility library as I mentioned earlier and one of the reasons

00:25:37 ◼   ► I thought about closing it back down is just because I don't really get anything out of

00:25:41 ◼   ► that.

00:25:42 ◼   ► Almost no one else uses it but occasionally I get a pull request to change something and

00:25:45 ◼   ► usually it's a change that I might not even need and so this is just more work for me

00:25:49 ◼   ► or adding functionality that I wouldn't do or that I don't need or that is done in a

00:25:55 ◼   ► way that I wouldn't have done it.

00:25:57 ◼   ► And it's just kind of like what's the value there really and most people don't need your

00:26:02 ◼   ► personal utilities.

00:26:03 ◼   ► Most people have their own personal utilities and so it only makes sense if you're going

00:26:08 ◼   ► to be open sourcing something that a good number of people will use.

00:26:13 ◼   ► Otherwise the benefit to you as the person doing the work and taking the risk of open

00:26:18 ◼   ► sourcing it is really small to non-existent.

00:26:21 ◼   ► And so I found that generally speaking like most of the stuff I write would not benefit

00:26:28 ◼   ► from being open sourced.

00:26:29 ◼   ► And that's also why like completely open sourcing an application is not incredibly useful for

00:26:34 ◼   ► most people.

00:26:36 ◼   ► You know it's just like there's lots of nuance to like what makes a good open source or what

00:26:40 ◼   ► makes a useful open source project.

00:26:42 ◼   ► And it's not always what you think and it mainly comes down to like am I open sourcing

00:26:47 ◼   ► a component that a lot of people will actually need and that they will find and choose to

00:26:51 ◼   ► use mine.

00:26:53 ◼   ► And if the answer to that is no, if you have like limitations on your time and stuff it's

00:26:58 ◼   ► probably not worth it.

00:26:59 ◼   ► But when the answer to that is yes it is pretty nice.

00:27:03 ◼   ► And you know for the most part you do have the risk of like you're going to get pull

00:27:06 ◼   ► requests you're going to have to deal with them.

00:27:08 ◼   ► You're going to like it is going to add work but hopefully it's also going to add some

00:27:13 ◼   ► kind of value if you get enough people to use it.

00:27:14 ◼   ► But as I said that's a huge if and of the I don't know five or ten things of open source

00:27:21 ◼   ► of open source so far only one of them has really gotten that and only just barely.

00:27:26 ◼   ► So it's a mixed bag.

00:27:29 ◼   ► Yeah because I think the biggest reason that I've never really gone down the road of open

00:27:33 ◼   ► sourcing things is that tension of if it's unique enough to be useful to someone else

00:27:41 ◼   ► then there's a good chance it's something that I wouldn't want to open source.

00:27:47 ◼   ► Like it's something that's kind of unique to what I the way that I approach things or

00:27:51 ◼   ► is part of what makes my app special.

00:27:54 ◼   ► And so it's like say I'm imagining something like your smart speed system in overcast right

00:27:58 ◼   ► would I'm sure there would be many people who would love to use that in their applications

00:28:03 ◼   ► if it were open sourced.

00:28:04 ◼   ► But the nature of open sourcing it like completely diminishes the value of it to your own application.

00:28:11 ◼   ► And so that weird tension in open source is like if it's super cool and interesting and

00:28:15 ◼   ► other people would want to use it then you may not want to then give it to them because

00:28:21 ◼   ► it's special and unique and kind of something you want to hold on to a little closer like

00:28:26 ◼   ► it's more of a trade secret in that way.

00:28:28 ◼   ► And then the things that are not that special are not that unique to yourself that you then

00:28:34 ◼   ► would be fine to open source maybe aren't as useful like you're if you're adding you

00:28:40 ◼   ► know it's like hey I have this way that I do like HUD pop ups like great but there's

00:28:45 ◼   ► also like 10 of those already and that's a weird process circular problem that you kind

00:28:50 ◼   ► of run into at least any time I've ever thought about it and so usually I just say you know

00:28:54 ◼   ► that's that's not for me and I don't really use much open source in my apps I just tend

00:28:57 ◼   ► to just kind of like write it myself and it works for me.

00:29:00 ◼   ► Yeah it's always a balance of strike and you know just like just like any kind of you know

00:29:04 ◼   ► code reuse situation like there's a balance of strike here there is no one answer all

00:29:09 ◼   ► the time and that's incredibly useful information I'm sure for everybody.

00:29:14 ◼   ► The answer is it depends.

00:29:16 ◼   ► It depends but hopefully you can make a slightly more informed decision about exactly why it

00:29:21 ◼   ► depends.

00:29:22 ◼   ► Exactly.

00:29:23 ◼   ► All right we're out of time this week thank you everybody for listening and we will talk

00:29:26 ◼   ► to you next week.

00:29:27 ◼   ► Bye.

00:29:27 ◼   ► Bye!