My 2014 in Side Projects

Inspired by similar posts, I decided to recount my last year in side projects. This is helpful for me because it puts the year in perspective, and perhaps hearing about some of these projects will be interesting for other people.

First, what is a side project? To me, a side project is any work that is not your main source of income. That's not a great definition, because reading a book would therefore be a side project. When it comes to side projects, perhaps it's more apt to say, as Justice Stewart did about obscenity, "I know it when I see it."


In early 2014, I ported chess.js from JavaScript to Dart. I had previous experience with chess programming both in graduate school and through one of my oldest still active side projectschess.dart began as a line for line translation of the original JavaScript source code, but evolved into something more. Initially, the Dart version was several times slower than the JavaScript version (largely because it relied on maps, as in the JavaScript version, rather than custom classes). I was lucky enough to have one of the godfathers of Dart, make contributions to the project that refactored it in a more Dart-like fashion. Of course after this software maestro touched the project, it significantly outperformed its JavaScript counterpart.

I haven't had much of a reason to work on chess.dart since it reached feature parity with the JavaScript version. It even passes all of the same hundreds of unit tests. I have ideas for future projects based on it, but what really delighted me was its use by Anders Forsell in chessboard.dart and chesschallenge. Both of them are really awesome projects that show off the power of Dart and web components. Anders wrote a couple blog posts about them.

Dart for Absolute Beginners

Dart for Absolute Beginners took about 9 months to write and came out in the early summer, published by Apress. It was the first book (and I believe remains the only) written about Dart designed for people learning it as a first programming language. I believe in the book and it has been very well received by reviewers. One reviewer recently called it, " of the best introductory texts on computer programming in general; bar none."

Writing the book by myself was a lot of work, but Apress provided a ton of editorial support. Everyone at Apress was pleasant, professional, and helpful. I think we put out a great product. Being a beginners' book, I stuck to core concepts that will not become outdated as the language evolves. However, I did manage to stick in an interview with the founders of Dart, Lars Bak and Kasper Lund. That chapter (chapter 18) is a real gem that even experienced programmers will enjoy.

I created a 12 hour video series based on the book for Apress, but its current status appears to be in limbo after a reorganization of the company. I'm as in the dark as anyone about what will happen to the series, and I am anxiously awaiting some kind of resolution regarding the matter (it was a lot of work to create!). For some reason it seems like you can buy it on Springer's website, although I haven't yet received my advance...

Kopec's Chess Camp 2014

My dad is a well known International Master in chess. He had run fairly successful chess camps since 1994 (with a dedicated business partner, NM Hal Terrie) but took a five year hiatus prior to this year's camp. He asked me to basically run the camp this year from an administrative perspective including marketing, book keeping, handling registrations, medical forms, insurance, making/mailing the brochure, etc. We held the camp at the beautiful New Hampton School near Lake Winnipesaukee in Eastern New Hampshire. While the numbers weren't huge (there's a lot of chess camp competition these days that didn't exist when my dad was a pioneer two decades ago, and the location was a bit remote), everyone had a great week.


I started working on an 80s style arcade game over the summer to help me learn Swift as part of the Summer of Swift. I used Tiled to edit the levels and the well made JSTileMap to render them with SpriteKit. I got to the point where I had a pretty cool concept and working gameplay. However, once I encountered a rendering bug, I kind of gave up on the project as other work took my time and the contest seemed to be fizzling out (was there even a winner declared?). The (currently showing a black screen) repository is still up - maybe I'll get it rendering again when I have a little more time.


Splip is an iPhone app I released in the early fall for turning a photo into two encrypted negatives that can only be recombined to view the original when you're in near geographic proximity to the person you shared one of the negatives with. It's a cool concept and the app store version totally works (using email to send negatives and Multipeer Connectivity to recombine them) but I'm not sure there's much of a market for it.


Restaurants is a native Mac Yelp API client that's super fast and integrated with OS X features like Continuity and Maps. I released it in November and it's been selling pretty well. It made it as high as #4 in the top grossing apps in the Lifestyle category on the Mac App Store (which doesn't take much apparently). I wrote a blog post about my experience writing it in Swift that was pretty popular (at least as far as this blog goes!).


SwiftGraph is a graph data structure library written in Swift that I created in a few days in November. It recently got a positive mention on a major iOS dev blog. Although it's not battle proven or fast, I did a lot of best open source project practices when making the library - like including copious in-source documentation, unit tests, and a fun example program. I attribute the recent interest in it to these factors.

A side note about SwiftGraph is that despite recently getting about 30 stars in a 24 hour period on GitHub, it never showed up in GitHub's trending Swift repositories. I think the algorithm they use favors projects that already have hundreds of stars, which leads to a lot of inertia. The trending page on GitHub is a place where open source projects get a lot of exposure. It's sad that its cards seem stacked against young projects. There are projects that only have 5 stars in the past 24 hours that show up in the trending 24 hour section. I emailed GitHub about what it takes to trend and they replied that they don't reveal their algorithm - I think it would be great if they were more transparent about this.

Crafting a Course

I took a job as adjunct faculty at a local community college. I'll be teaching an advanced Java class and a database course next semester. It's a side project because it won't be my main source of income, that will still be consulting projects, but I figured it would be fun and provide some great teaching experience (and maybe even inspiration for my next introductory programming book). My boss there asked me to redesign the database course I'll be teaching, so I spent some time doing that this Fall. I'm coming into it with a lot of enthusiasm and excitement. I hope the students feel the same way.

So, that's my 2014 in side projects. Back in my Dartmouth days, we might've called a blog post like this a giant "self call" which is a negative term. But to be popular in tech they say you need to master the humble brag, right? It was quite a productive year for me with regards to side projects, but I hope to exceed it in 2015. With that regard, I rather do a few less and have them be as successful as Dart for Absolute Beginners, than necessarily do as many as I did in 2014.

Incidentally, if you have potential consulting projects that are related to anything covered in this post, do get in touch with me through Oak Snow Consulting. I'm pretty booked for the next couple of months, but let's get the conversation started if there's a good fit.

My Experience Building a Small Mac App in Swift

I dabbled with a Mac Sprite Kit game over the summer and was generally pleased with the experience. The last couple of weeks I put together a small full Mac app(Restaurants) currently under review on the Mac App Store (Update: now released) written largely in Swift. Here are a few notes from my experience. As you read them, please keep in mind that the last Mac Cocoa app I built was in 2003 (pre Cocoa Bindings even!). Since then all my Cocoa programming has been iOS. Also keep in mind, while I have a formal CS graduate education, I am a very applied guy, so I might not always get the theory parts/terminology right here.

Cocoa Bindings
Having not built a Mac Cocoa app since pre-Cocoa Bindings, I was amazed with how convenient this technology is (and a little disappointed that it never made its way to iOS). It relies on KVO/KVC of course, which feels like a bit of a hack in Swift (make sure to use the dynamic keyword). It would seem that there is a lot of room for improvement/new innovation in Swift with more advanced versions of property notifiers like didSet/willSet taking the place of KVO/KVC somehow (although I haven't yet figured out how). Ultimately everything did "just work," including doing Bindings between Swift interface elements with Swift objects that have properties which are Objective-C objects, which speaks to how well the two languages really do integrate.

Objective-C Integration
Speaking of Objective-C, the library for interacting with Yelp used in Restaurants is written in Objective-C. I modified it a bit as I worked and once again it was impressive how things "just worked" when called from Swift. Clearly this language was designed for that purpose. The bridging header is short and simple enough, but like dynamic, it also feels a bit hacky.  Once when I created it manually (and even setup the project settings correctly I thought), the linker didn't recongnize it. It seemed like only when Xcode created it for me, was everything setup correctly (yes I specified the name of the bridging header). It could be that I made a mistake in the project settings - but I do think things should be more automatic. Can't the bridging header be created for us at build time when Xcode detects the project has a mixture of Objective-C and Swift code in it?  Ah... first world problems.

Sometimes it was unclear to me as a Swift newbie how some Objective-C method parameters should be provided from Swift as far as type signatures go. Better hints in Xcode would be helpful.

Although I've worked in a lot of different languages over the years, I never have worked in one that made such extensive use of optionals (Haskell has maybe - feels like sorta the same thing to me, but I only did Haskell for a few months). Do optionals make the code safer? Yeah it feels like they do - a little bit - although I still created errors for myself occasionally by unwrapping nil optionals - so clearly we can't completely protect ourselves from ourselves. But I also now have an inoordinate amount of boilerplate if let statements.

The big problem with optionals though is interacting with the Cocoa frameworks. I feel like Swift was designed for most variables to be non-optional, non-nullable values (I could be wrong of course) and optionals are supposed to be the special cases. But instead, due to having to work with the Objective-C Cocoa frameworks, almost everything is an optional. It's annoying - the boilerplate is annoying, the unwrapping is annoying, and the cognitive overhead of deciding what should be !, ?, etc. is annoying. Personally, while I feel I fully grasp the concept and I appreciate the safety, it hasn't been worth the loss in productivity for me when dealing with Cocoa.

There have been a lot of comparisons saying "it's like this or that language." For me, someone who has spent the last few years programming professionally in C, Objective-C, Java, Dart, JavaScript, Python, Ruby (so mostly C-like languages except the latter two) but with significant exposure to some more academic languages, Swift doesn't quite feel like any of them. It does feel fresh. It does feel like an amalgamation of some of the best ideas of each. Just the lack of @ symbols and headers makes it more compact than Objective-C (and I like Objective-C a lot). I honestly think it's the optionals again that stops it from being perfect for me. It feels like there are too many ?s, !s, and if lets littering my code. Frankly I think that sort of stuff is what makes a language a bit hard/not fun for a beginner to grasp (and I'm the author of an absolute beginners programming text and do teach beginners professionally so I know something about this - this might be the only opinion of mine here that shouldn't be taken with a grain of salt).

Like every mainstream new language out there, Swift tries to bring the best of the functional world to object-oriented programmers. I think it largely succeeds. I'm even worried the community is going too far in the functional direction. I'd like to see more of an emphasis on the object-oriented features of Swift in the future. On a day-to-day basis, that's the world I think/work in, and I think that's true for most Mac/iOS developers. It's great to see the energy, enthusiasm, and contributions of the functional folks who have gotten involved with Swift. I look forward to taking advantage of it. However, my work is so much more about building intelligent class hierarchies than it is about building cool recursion tricks (ha that sounds awful and debasing - didn't mean it that way!).

Also, I appreciate the dynamacism of Objective-C. Like many have said, Swift feels more like C++ (and my understanding is that its method dispatch is more similar to it than Objective-C (please correct me if I'm wrong)) than Objective-C. Maybe we need that for the speed advantages, but that's awkward when we have to deal with these huge Objective-C frameworks all_the_time. I saw someone propose on the Apple developer forums that the dynamic keyword should be default. No, I don't think we want that slowness by default. I think what we want is to take full advantage of new, better ways of doing things, than what we had available to us in Objective-C. But we're handcuffed by Cocoa. I think Swift won't start to really have its own voice/come into its own until we have Apple frameworks written in Swift.

I had Source Kit crashes. I had weird, unexplainable errors. I had bad syntax highlighting. Generally things got slightly better over time but some of them I still can't explain. Unfortunately it's not very easy to explain how to reproduce all of these bugs in Radars. I feel like it would be helpful if it was easier to just share full projects with the team somehow. Here's a radical idea - what about adding a built in screen capture video tool in Xcode that could also send your source code (with your permission of course) straight to Radar. Too much potential for hackers maybe?

Working on a small app, I didn't encounter some of the slow compilation issues that a lot of other people have. In general, I found the actual compiling/running process to be pretty pain free.

The Swift team at Apple has been awesome on the Apple developer forums. Some cool sites have popped up on the Web like and others that aggregate high quality material. However there's also been a lot of negativity, which is understandable given how invested some people have become in the language given the obviousness of its future as the premier Apple sanctified language. A lot of the tastemakers who are updating their Cocoa books for Swift have been particularly vocal. I appreciate that - I wrote a book about Dart starting when it was still in beta and nothing is more frustrating than changing something big when you're going to print. But that language faced relatively few changes/bug issues compared to Swift in its early development (they also made the first public beta release a full 2 years before I started, so it's not a fair comparison).

Swift has attracted an interesting combination of long time Apple developers, brand new Apple developers, and people from the functional programming world. Sometimes it feels like these three groups are speaking Greek to each other. There are regularly code snippets on the Apple developer forums that I, a long time developer, don't fully grasp without careful study. We need coding standards, and we need more direction from Apple regarding conventions and style. We need more sample code. We need the first few books by the people most invested in Swift to come out from the major publishers. Then we'll see where the cards fall and which of these groups will get the most pull in the Swift world.

Anyway, that's it for now. I will not be doing my next big client project in Swift, but I will continue to use it in my personal projects. I also posted this on the Apple developer forums.

Network Connection Required

One thing I see time and again in mobile app development is bugs caused by syncing a local persistent data store with centralized data on a server accessed via API calls. An incredible amount of software development time goes into making the sync process smooth, elegant, and robust. Yet, in a mobile world with nearly-always-on network connections, we need to ask ourselves if the effort makes sense for all apps, especially for MVPs (Minimum Viable Products) of apps focused on content consumption.

Why is sync hard? Generally, it's a matter of the server and the client having radically different data store technologies. The translation that needs to mediate that disconnect can be complicated. A common scenario is for a mobile app developer to use a BaaS (Backend as a Service) like Parse. To take the example and run with it, Parse has an arguably excellent, easy-to-use API. Yet once the mobile app pulls data down from Parse, which will be in the form of Parse objects (PFObjects), he needs to translate it into a format suitable for storage in something like Core Data or SQLite.

This translation needs to happen in two directions (SQLite -> Parse and Parse -> SQLite). Further, consider the situation where the client accesses the application from two different devices simultaneously. Perhaps device one makes changes to the same piece of data as device two in their respective local data stores, and then both are synced with the Parse data store. Which revision should take priority? There are solutions to this problem (of course), and they're not necessarily complicated - but they are intricate when one considers corner cases.

Parse together with SQLite was just one example - perhaps the server-side is using an ORM wrapping around MySQL and the client-side is using Realm. Perhaps the client-side is just using NSUserDefaults... It really doesn't matter. The bottom line is it gets complicated. So complicated in fact that the well-known and highly regarded Mac/iOS developer Brent Simmons wrote a "diary" about his experience implementing sync for the note taking app Vesper.

Is it worth it? I don't believe so for the majority of apps, especially when they're in the get traction phase. It's not worth the potential bugs and it's not worth the development time. What's the alternative? Keeping the local data in a more flexible in-memory store - essentially a cache - and requiring a network connection to do any content creation.

The advantage here is that it takes away a step in the translation process. After the data is deserialized from the remote server, it can be used instantly and we're not beholden to worrying about multiple devices. The copy on the server is always the canonical copy when it's the only permanent data store. If the user tries to post a comment/post a rating when not connected to the net, we simply tell him he needs a network connection. Keep it simple. It's not ideal, but in a content consumption app, it's probably a minor annoyance rather than a deal breaker.

This doesn't work for apps that feature long form content creation (such as a note taking app like Vesper - or perhaps a video sharing app). They need something robust that ensures even if the network connection dies the user will not lose his work. But for apps that are all about consumption of content not produced by the user, or where the user's data input will never be more than a short blurb, perhaps the syncing madness is unjustified. I rather the user have the risk of once in a blue moon losing a star rating than be subject to a crash-prone MVP.

It goes without saying that as apps move from the MVP phase to the "we have more resources" phase, syncing becomes a much larger priority. The point here is that early on, sometimes syncing is just too much of a distraction.

A Purposeful Personal Loss of Anonymity

This blog has existed for nearly three years and it's time for its author to stand behind its writing. Up to now, it's been unsigned. Sure, if one wanted to lookup who owned the domain name, the authorship could be easily obtained. However, it was purposely presented as anonymous to offer the subject matter a certain degree of freedom.

Yet, retrospectively, none of the content has been that controversial and there is certain merit to signing one's work:
  • It informs the reader about the biases of the author. Some may even argue it's a more ethical way of writing.
  • It may help to create a sense of connection between the author and the reader.
  • It may pique the reader's interest in continuing to read if he finds the author somehow relatable.
  • It lets the reader know what other works are by the author so that he can judge the work in the right context.
  • It allows the reader to judge whether the author is a reliable source.

So, my name is David Kopec, and I'm the author. I'm a software consultant in New York. That means I build iOS and Web apps (mostly for startups). I'm also the author of Dart for Absolute Beginners which in my highly biased opinion is an excellent starting point for learning how to program. I haven't yet written about politics or foreign affairs here and I don't plan to. I hope to keep the hate mail to a minimum. I also plan to start using this blog as a platform to write about more technical topics.

I started this blog in early 2012 when I was quite interested in the concept of anonymous content creation. Just a few months before that, I had launched the anonymous poetry app Poemz as an experiment, which has been mildly successful. As its sole moderator, having to read thousands of mostly anonymous poems, I've learned a lot about the strengths and weaknesses of anonymous content creation. The biggest feature requests are for less anonymity - users want to have profiles and commenting systems. They want to have some sort of identity and voice. Some users find ways to link to their real-life online profiles, which is of course against the anonymous spirit of the app.

In that time period we've also seen the rise of anonymous social networks like Secret. Anonymous content certainly has its place. It gives voice to those with something valuable to say who for whatever reason can't risk their reputation by putting their name behind it. The Federalist Papers were famously published by Alexander Hamilton, John Jay, and James Madison anonymously. Was there ever a better collection of thoughts on governmental theory?

I recently met with a startup founder focused on an "anonymous social network for positivity." They had built a cool app that was out in the wild and had some good ideas. The anonymous space is hot right now. Yet, positivity is not usually what people want to use anonymity for. Usually they want to use it for negativity. Think Reddit, 4Chan, black-hat hackers, and violent flash mobs.

I used to believe that the future of the Web was anonymity. The Web boom of the '90s focused on anonymous content consumption. The '00s were all about signed content creation (think Facebook, YouTube). I thought the third era would be a combo of the two - anonymous content creation. But anonymous content creation has its limits. We want to trust our sources, so we need to know who they are. We want to connect with other people, not just ideas.

For most long-form writing, for all of the reasons stated above, you should sign your work. That's what I've come to believe and that's what I'm now going to practice. I think Poemz and Secret are great platforms for short-form expression. I think long-form expression should usually be coupled with ownership/authorship. Especially, if it wants to be taken seriously. And I do.

Put a Date on Your Blog Post

There's nothing more irritating than reading a blog post, looking for a date, and being utterly unable to find a trace of one. There's a good reason for associating a time-stamp with a piece of writing, and that's context.

A lot of writing is a product of the time period from which it was created. That time period encompasses trends, motifs, and current events that fluctuate. Understanding those fluctuations helps one understand the motivation and biases of the author. It also informs an understanding of the author's conclusions and opinions.

Can you imagine reading Joseph Conrad's Heart of Darkness, not knowing it was published over a century ago, and questioning where the author's racial attitudes come from? No, because every book is dated and therefore you don't have to ask yourself that question. Knowing when it was published, helps you better understand Heart of Darkness through your understanding of the world from whence it came based on your outside knowledge.

Now consider a blog post about a technical subject, politics, or science. Its value is directly correlated with the context from which we understand it. We may not have any prior knowledge of the author, so that's a piece of context we may have to go without. He should at least give us a date!

Build Neighborhoods with Cafeterias

Do you know what's really inefficient? Every house/apartment having its own kitchen. It creates such duplicative effort, such overuse of energy (one big kitchen uses less energy than thirty small kitchens), and is such a missed opportunity for community building that it's positively bonkers.

Consider a world where new neighborhoods are built with communal cafeterias and new dwellings are built by default without kitchens. Neighborhood members would be offered membership plans (meal plans) in the communal cafeteria and would play a role in its management through a voting system. Private kitchens would not be illegal in these neighborhoods (people with special needs would still have them) they would just not be the norm.

The communal kitchens would help solve a lot of societal problems:
  • A sense of isolation that people feel with the rise of the Internet. Neighbors would actually see each other every day.
  • A lot of modern folks have terrible diets. A community could choose to only serve healthy food in its communal kitchen. It would make eating healthy "easy."
  • The exercise of walking to the communal kitchen/cafeteria would be beneficial to everyone involved.
  • Neighbors would be more likely to identify at risk youth/people who need help before a crisis occurs.
  • The lack of refrigerators in homes (by default) would certainly help with the obesity epidemic. So would the social pressure of neighbors seeing how each other eat. One would not want to be gluttonous in front of the Joneses.

Neighborhoods could also choose to use their communal kitchens for doing good - helping low income families put food on the table for example - or creative purposes like using the physical space for putting on local theatrical productions. How would the communal cafeteria be funded? Neighborhood residents could pay for a meal plan, or volunteers could cook each day, or tax dollars could be used to fund them. They could also be a-la-carte (pay by the meal) like restaurants, just subsidized in some way with reduced rates for residents versus non-residents and non-profit. Really many models could work.

There are many reasons not to have neighborhood cafeterias/communal kitchens (easier spread of disease, lack of privacy, economic concerns) but it would certainly be an interesting experiment for all of the above reasons. How appealing they sound to you may depend on how you felt about your college's dining halls.

About Me

I teach Computer Science to college students, develop software, podcast, and write books about programming including the Classic Computer Science Problems series. I'm the publisher of the hyper local newsletter BTV Daily.

You can find me on Twitter and GitHub. Check out my podcasts Kopec Explains Software and Business Books & Co. You can subscribe to my very low volume newsletter to find out about my future book, media, or software projects.


©2012-2023 David Kopec. As an Amazon Associate I earn from qualifying purchases.

Based on tdSimple originally by Lasantha Bandara and released under the CC By 3.0.