Cocoa Touching


So as I promised, I jumped into Objective-C again last week. I think I skipped about a month, and when one is learning a new language, this could be disastrous. I tried to prevent that, but I didn’t really know where to start over.

lrg (1)

Learning all the knobs and levers

Since I had to focus on iOS, and I also bought another O’Reilly book, Programming iOS 7, so I thought I go with that, which proved to be a mistake. Compared to to Learning Cocoa with Objective-C, this book is more like a dry reference. It doesn’t even have a learning curve. It picks a topic and tells you almost everything about it. In a CodeSchool lecture I heard a really good analogy for this:

“If I were to sit you down to the navigator seat [of a submarine] and if I were to teach you all the knobs and levers and instrumentation, well, we wouldn’t be diving for a long time.”   Gregg Pollack

It took me a full afternoon to figure this out, that I couldn’t continue like this. The problem is not with the book. It is for higher level iOS developers who want to have all the latest iOS stuff around in a readable format. I was really disappointed, since I wasted a lot of time on this. What could I do?

Continue reading

Think Before You Code


Last night I watched a great presentation from Leslie Lamport, a famous computer scientist. He was talking about the importance of thinking before coding and creating specification for your functions.

Writing specification saves time

Many programmers like to jump into coding right away, saying ideas will come on the way. Think about how a road would look like, if the engineers decide to change the course every now and then. Ok – you might say – but this is the best in coding, you can always delete the bad parts and do it the right way or refactor it later. Yeah… with several times the time and effort!

Planning ahead not just saves you precious time and the need for later refactoring, but could also reveal conceptual failures. If you create a working model for your function, you might find errors you would’ve never thought about, but I don’t wan’t to steal Mr Lamport’s show, watch the video!

The problem

What I really want to write about is a recent example, how I solved a problem with thinking, before coding. I wrote about Talentbuddy a few days ago. I went on doing their exercises, and found one among the early (easy?) ones, that gave me a real headache. The problem is about an online service, that can serve a certain amount of requests, and you also have three locations with the number of requests coming from each. The task is to count the unique possible service configurations.

Take this example: if your server can serve n = 2 requests, and your locations try to send a = 2, b = 2, c = 2, then there are 6 unique possible configurations: (0,0,2), (0,1,1), (0,2,0), (1,0,1), (1,1,0), (2,0,0).

This is a combinatoric problem, so I jumped into coding and tried to solve it with factorials and combination, but it just didn’t work… I was doing it all wrong. I tried to do it fast (like a pro?), and ended up struggling for an hour (more like a loser). Finally I gave up and went to sleep.

Then last night after watching Lamport’s presentation, I realized that I was learning the same specification first method at University for almost a year now. So today I sat down with pencil and paper, and tried to specify the problem.

SPOILER ALERT: If you want to solve this on your own, then you might want to skip the second part.

Continue reading

Online Coding Dojos

Screen Shot 2014-04-13 at 21.52.59

Last week I saved a link for further investigation. It was Talentbuddy a coding exercise website.

Coding should be fun and power

Day to day programming work is not always fun. It can get really boring sometimes, but coding itself shouldn’t be like that. It’s one of the most powerful tools in humanity’s possession, every programmer hopefully reached a point while learning, when they felt this power. The power to solve a difficult problem, something that would’ve taken centuries to solve a few decades ago. One can find such problems for example in Project Euler.


Project Euler

In Project Euler (PE) you’re given problems on the scale of hard to really hard. You can use whatever language you want, they only ask for the answer. While some knowledge in computer science is required in most cases the challenge is not understanding the problem, but writing a solution that runs in a reasonable amount of time. What is reasonable you might ask, well… your first try would do pretty well on a smaller set of input values, but expect problems which require calculation on a set of millions of items. Doing it under a few seconds instead of weeks, dodging stack overflows and out of memory errors is the real fun in this game.

With its 2001 start PE was among the first of its kind. It was intended to be a game for grownups, a somewhat experienced lot, who are expected to focus on efficiency, not just brute force solutions. If you are learning a language (maybe your first) then PE is not in your league. You’re goal is to establish a solid foundation in the language, which is best achieved through easier problems.

Screen Shot 2014-04-13 at 21.52.59


The first real coding dojo I tried was Codewars. This site is a true dojo, with a working kyu and dan ranking system. If you’re not familiar with martial art systems, kyus and dans are ranks of expertise. Every beginner starts with a high (8) kyu rank. With every successful level jump, the kyu rank decreases, until 1 kyu. After surpassing this level the progress is measured in dans, which grows with every further new level. And one more important thing, you should challenge opponents with the same or slightly higher ranks in the hope of success.


In Codewars the programming challenges are called Kata (which is a term for exercise in martial arts). These kata are your opponents, so they also have a level. If you solve one you receive points calculated from your and the opponents levels by an algorithm. You reach a new level if you gather enough points. You can level faster if you solve much larger level problems than your own. There are many kind of problems: bug fixes, algorithms, game logics, and so on. Right now you can solve a problem in JavaScript, CoffeeScript and Ruby, but I just checked the site when writing this post and they’re planning to add a lot of new languages. Your code must pass a certain amount of black box tests to enable submission. After you submit a working solution, you can check out how others solved the problem and discuss it with them in the forums.

I managed to solve really interesting problems here, for example implementing a simplified version of the leveling algorithm I mentioned above, some complicated string analysis or a special kind of sorting. There were also fairly easy ones among the lower levels, which give a great point of entry for beginners and a large amount of room for success. Right now 2 and 1 kyu challenges are almost real world tech problems, but definitely candidates for interviews, you make yourself a great favor completing them… I wonder what dan level problems will be like.

Screen Shot 2014-04-13 at 21.53.32


Time has come to introduce Talentbuddy, which I found lately. They are much like Codewars, but they chose a simpler gamification theme. Here you solve groups of gradually hardening problems. You get fixed amount of points for a working solution and you level and earn achievements by collecting these points. Beginner problems start with the sum of two parameters, which might seem childsplay, but checking the issues section you will find that even these could pose a problem for a beginner.  You can solve the problems in a large variety of languages, but only the first successful solution counts. After completing an exercise you can ask a code review from fellow members.

Both Talentbuddy and Codewars is a growing community effort. Members can send in their challenges, which are curated by higher level members and then integrated into the system. While Project Euler is a great thing I think these new coding dojos will be the future of spreading programming knowledge. You should definitely go and spend some time honing your skill with them, but be careful they are massively addictive!

See you at the dojo, Coding Ninjas!

I hate when a language makes no sense to me

You know what happened more than a month ago? I said I’m gonna learn Objective-C…

Oh, yeah – you might say – this guy wants to be an(other) iOS developer because this is the awesome hipster shit out there lately, and people are flappy birding themselves to the top of the money mountain and such. Well, you would be wrong!

Of course, Objective-C is more popular than ever, we (at Prezi) use it too to make our iOS apps for example, and there is a certain aspect of popular languages that I really hate, when they don’t make any sense to me! As a backend developer I regularly find myself sitting next to a client developer, looking at me with puppy eyes, having a hard time working with the service I wrote. And when they show me their Objective-C magic I was lost… this is what I really hate.

But seriously, how confusing could it be? Objective-C is just C… with… some Smalltalk object-oriented messaging interface @property blaaaargh! Look at this!

- (int)changeColorToRed:(float)red green:(float)green blue:(float)blue;
[myColor changeColorToRed:5.0 green:2.0 blue:6.0];

Now, this is a method message declaration and a call. Makes sense? For me it does now, because I started learning this language. My first step was buying Learning Cocoa with Objective-C (4th edition) from O’reilly. I’m old fashion. I like to learn form books… ebooks… on my iPad.


Let’s stop here for a second, because this purchase made me feel like an ass! This is a quite fresh release, updated for the latest Xcode, ergo no free download. No problem, O’Reilly has nice discounts… guess what, I didn’t find any. I was out of options and in a rush, so I bought it on full price. Next day, on my way to clear the useless crap from Gmail’s promotions tab… there was a mail from O’Reilly, sitting there for a week then: buy iOS development ebooks 50% off! Fffffff… Arrggghh!!!

Ok, bought the book and jumped right in. I must say it’s a pretty good one. Had the grasp of the syntax in a few hours. There are nice OS X and iOS examples, I could even go on and have some fun enhancing them a bit. We also figured out with my engineering manager that my interest in Obj-C is a great, but Hello World! is for babies, I should do something that counts, like an iOS app that controls the RaspberryPI-s in the office!

That… was a few weeks ago… I had some exams and a C++ homework, and… I’m a slacker, playing Heathstone at night. So no more excuses.

Commitment: I’m going start the app, and next week write about how far I got with the project!


This site is #include. It was created to be a blog about my profession.

My profession is software engineering. I do web development since 2005, and I did that mostly with PHP. Nowadays I code Python. I work at Prezi as a backend developer. This involves some other languages like Scala, Java, Ruby (Chef), Shell Script, SQL. I also love to tinker on the client side so JavaScript, HTML, CSS are really close to my heart. I once started to learn myself a Haskell… which will definitely happen sometime.

I resumed… well, more like started over my University studies. There was some PowerShell and a lot of C++ so far. I also attended some Coursera courses last year where I did SML and Racket, and I have a goal to learn Objective-C, Cocoa and iOS development in the coming months.

That was 16 different programming languages in 7 sentences, and I think that’s awesome! I’m going to write about coding here. All kinds of problems, easy ones and difficult beasts, interesting solutions and boring day-to-day struggles. There will be some philosophy now and then, and you should’t be surprised to find some serious shit on display here.

There is always things to write about, so my commitment is to write stuff here regularly, and I mean that! If you happen to read this and my last post is older than a month, please drop me a line telling me to do my shit! Thanks!

With that I announce that #include is born, and it’s committed to coding.