MacKuba

Last month I read a great book from the Pragmatic Bookshelf – “The Passionate Programmer”, another book in the not-directly-technical series of their books started with the original “Pragmatic Programmer”, which deal not as much with specific technologies and languages, but rather with programming and programmer’s life in general.

The book, written by Chad Fowler, a well-known Ruby expert, is a second edition of a book that was previously titled “My Job Went to India: 52 Ways To Save Your Job”. The first edition’s main idea was helping US developers find a new place for themselves in the globalized world where more and more projects are outsourced to some remote countries. The second edition is more of a redesign than an update, and instead of showing you how to be good enough not to be fired, its aim is to show you how to be awesome: how to become an expert in your field, a well-known, respected developer, and how to have fun on the way.

I’ve found a lot of great ideas and made tons of notes, but if I shared everything that would be definitely TLDR, so instead I’ll try to sum it up in a few points which were repeated in various forms throughout the book. (If some of these seem too obvious to you, I’m pretty sure you’ll find some other tips that will make more sense for you in the book.)

There are many posts and articles that compare available open source licenses. A lot of them aren’t objective and are biased towards some kinds of licenses based on author’s own preferences.

Well, I have to disappoint you, this one isn’t going to be any different :)

After the VLC incident last week I got kind of fed up with GPL. I had licensed a few of my projects under GPL before, but I decided I don’t want to use a license that’s so restrictive that it makes it impossible to put an app on AppStore, even if it’s shared for free and the source code is available. So I did some research to find what other licenses made sense for me. As usual, I spent way more time on this that I should have, and the notes below are the result. (Note that I haven’t actually read the whole text of most of these – I’m not that crazy.)

Update (6.07.2017): I’ve added a section below about the “Very Simple Public License” (VSPL) that I started using in my projects as a simpler replacement for MIT.

I came across a problem recently. I have a project called xBlip which I’ve described before – it’s an iPhone client for a Polish Twitter-like service Blip. This project has a backend part which I keep in a subdirectory “ObjectiveBlip” and which I’ve tried to keep as separate from the rest as possible, with the intention that it might be one day extracted as a separate project.

Now I got the idea that I could write a desktop application for Mac that does the same – and of course I could reuse that backend part for that. I would also like to create a separate project on Github with just the backend, so that theoretically someone might use it in future for some purpose.

But this means that I would be maintaining three separate copies of the same code, which I’d have to keep in sync somehow. So the question is, how to do this best?

There are a few ways in Git to share code between projects (for example, git submodules) – but most of them are intended only for one-way communication, i.e. downloading updates to a library maintained by someone else into your project. Here, I want to have a two-way communication: I could extend the backend code while working either on the iPhone or the Mac application (working directly on the backend-only project wouldn’t usually make sense), and then broadcast the changes into the other two projects. I also don’t want the solution to be inconvenient to people who download the project, as is the case with git submodules – you have to manually update them once you download the main code, initially their directories are empty.

So I started looking for a way to pull this off – and I found a script called “git subtree” which seems to do exactly what I need (confusingly, there’s another plugin also called git subtree which is completely unrelated to the first one…). It took me some time (and a few emails to the author, Avery Pennarun) to figure out how to use it, so I thought I’d post a tutorial here in case anyone has a similar situation.

So, here’s what we need to do… (grab a coffee, it’s going to be long):