That was a long night

Wow, how hard is that! Getting back to work after quite a while. Things like setting up a Debian virtual guest seem to be tricky. No step can be made without a google search. And why am I not cheetah fast on my vim? Ups... the client is waiting, so at least there is a whip.

I stepped out of programming in Ruby when the version was... OMG! I've completely lost the track on software versions and it was just a year and a half. So I read magic like: The current stable version is 2.1.0. I remember a talk by (wait, what was his name), right, Matz! Yes, in 2011 in Berlin, he said something about Ruby 2.0. I've left around 1.9.4 I guess. Rails was before version 4. Jesus.

My market value went from 50k €/year to 6k (in programming field). I've changed, OK. Let it be. But still, I'm a third engineer in line after my grandfather and dad. So I'll fight for the family name as if it was a Game of Thrones season five.

I've travelled and I ended up meeting people from Jiva Institute. Ou, I remember – I stepped out of programming to become a human system engineer (gems, magic, reiki...) and now I go to India to work as a software team lead/brainstormer on Ayurvedic ideas. At the end, not everything got vanished, I've just lost the sense of a productive software developer. Well, the internal journey had to happen and it has a price. And value.

It's not that bad. I've looked through my past posts and different blogs I've managed. They surprised me and made me happy – there is nothing about myself. It's just work and interests. They are like a footprint that stands for – this guy was very curious about the world. That's good. Now it's just about time management and finishing tasks one by one.

In the meantime I wrote a book (releasing this year), I've sold everything and traveled with a backpack (which you can check at soldnpacked.com), I had a lot of fun and finished off gracefully like a brave Apache. Changing continents soon and posting on WIFI! Cheers from Peterborough, Cafe Nero.

The Clean Coder

I enjoyed this tiny book very much. Robert C. Martin lays down here many important issues that many programmers should be aware of.

I will not even try to write a review of the book - I just want to point out some things that influenced me. In general, I like soft-software books, I mean without the code, just mentoring. I like that Mr Martin is recalling the days of his early programming adventures, when he was a high school geek or 2* years old passionate hacker. That means to me that he has a distance to what he does even though he is a passionate and claims himself being a professional. Someone I want to learn from about programming.

Number one (and this an interpretation, not a quote) you don't have to be experienced to be a professional. I know it sounds silly. But there is, I guess, a space for unexperienced-professionals. What I mean is that everyone can behave professionally. Experienced-professionals for me are the ones who tried to behave professionally, they succeed, and they follow their path no matter what. The attitude is the power.

When I was 19 years old I remember working with so called "experienced" programmers. They were supposed to teach me, and I was supposed to learn. Thankfully there are many sources of knowledge and I could take a different path. I can easily see now the difference between an experienced and experienced-professional developer. Thanks to that book I can also define it.

Second thing is about prioritizing and learning. Never more ocasional priority inversion. If there is a task that is more important, don't do other one because it's easier. Don't even follow the internal dialog, about how right is it to work on another task while the most important one can wait a bit.

One sentence was really nice. It was about practicing after work. He recommends 3 hours a day (quite a lot I must admit). I will put it in bold: Practicing is what you do when you aren't getting paid. You do it so that you will be paid, and paid well.

And one more thing. If you don't follow TDD (or any other discipline that is as effective as TDD), you can stop calling yourself a professional. I like that he says that with no illusions, that there may be another way of being a good programmer who doesn't write automated tests for his/her code. No, there is not.

Anyway, I recommend that book a lot. I'm still on my way to be professional, but I guess that this book indicates one of the best ways to succeed.

And the cover is there for a reason, astronomy has a lot to do with programming.

Basic needs of programmers

If anyone thinks that the most important thing for programmers is the ability to code - they're wrong. Even if it is a super interesting project that involves millions of users it will fail if programmers have no possibility to meet their basic needs. And I'd like to stress the word possibility.



How many of us, programmers, were sitting in front of a computer for hours without eating, drinking or going to the toilet? Do you remember this project that you had once, when you just have to finish in three day and one test is not passing or you want to make this query run even faster that it could? Or just refactor the code before pushing it so it shines more that it needs? And you were this hacking-freelancer that will do the best project ever! Yes - a freelancer working from home.

It works completely different in the office. You start working with a coffee, water, little chitchat with everyone. You see people going one after another to the toilet, eating snacks, walking around. And then on of them brings the news: there is no running water in the builiding! OMG!! Panic!! How are we gonna pee after first three coffees? We have to go home!! Everyone needs to pee in the exact same moment! Dear God!! I didn't drink anything but maybe I'll need to pee! I have to go home! There is no water running!! NO WATER!!

Forget about programming. This is not freelancing at home, this is working in the office. Even if you don't have to pee, you will leave just because the toilet is out of order. And there is always that argument of Maslow's pyramid.

BTW. I need to pee (excrete) and I'm the only one left in the office... shit...

How to re-implement a cartesian product algorithm

Yes. So did I waste my time, or not? Of course not. I just got a big slap in my programming face. Un pollazo. I over-implemented a cartesian product, without even noticing it. But it's fantastic, I can learn every day :)
I was even showing it around to my friends at work. They didn't notice too! Maybe this algorithm could be used for something else. But I have no fucking clue where :D
Of course I learned a lot, but still, feel a bit stupid. Do not overdo and read more - that is the lesson of today!

Ou programming... my dear...

Fast! iterative algorithm for generating permutations from sets' single elements

I like it. I like this one. Last algorithm for this problem (here) was O(n^3). Now it's O(n). It may mean two things: first one was very shitty, or that the second one is really good. Probably both are true.

I came back home, without a laptop. With one hand holding the Algorithms book (I really recommend that one) and with notebook and a pen in the other. I choose notebook and pen. It did the trick.

I know I masturbate on that issue, but it's fun. After some furious paper programming I got here:


I asked myself 3 questions at the beginning:

1. How many times "1" will be first?
2. How many times "4" will be in the result?
3. How many times "5" will be in the result?"

I wanted to answer that questions without the use of any offset indexes kept in memory in other array. Keep it simple: what do I know about my input data?
So my answers were like that:

1. If I take all the sizes of following tables and multiply them, I'll get 12.
2. Always, cause it's a single element array, so 36 (total possible permutations.
3. The same as answer number one. 6 times in cycle of 3, 18.

The main conclusion was that I can fill the results array column by column instead of row by row. All permutations will be fully calculated at once, at the very end. No gathering the permutation by permutation and then pushing it to the results. No no no, that needs indexes and traveling across the array many times. This idea dropped the complexity from O(n^3) to O(n).

Cycles, subcycles, offsets. The most important thing was to calculate a proper index in the result table and stick the current argument element exactly there (IBID). No more talk, code is below and benchmark is on the gist comment.

I'll try again. Polyrhythms and programming.

Welcome again to my regular blog. Keeping the frequency of one post per year is very difficult. Still, I manage.

I opened myself a door to blog not only about programming. All those posts about JavaScript and "so on" that I did through whole last year... life is much more interesting than that.

Recently I started drumming lessons. I played for two years some time ago and then after another two years gap I picked up the sticks again. This time with a different attitude: regular lessons with a teacher. It's been three months by now that I practice 1,5 hour twice a week + almost everyday exercices on the practice pad. I learned the important lesson: regular practice is the ONLY way. Maybe that will help me to maintain a blog.

I also moved to Barcelona, Spain. I work here as a software developer (mostly doing Ruby on Rails) at XING AG. That also gave me a big possibility to even more regular programming and a new approach to it. I'll leave this subject for later though.

Polyrhythms. Strange rhythms. Transposed rhythms. That is where my head is lately. Many times I practice patterns that at the beginning seem impossible (for me) to follow. I still lame (only three months of classes) but I realized that these practices have a big impact on my analytical part of brain. It is a funny feeling. When I started classes, first thing when I got a new pattern to learn I tried to analyze it somehow. I counted at loud and did the beat with my feet and hands. It worked, but...

...sometimes this approach fails! Once I could feel really hard the limitation of analytical approach to try to grasp a rhythm. Everything was fine until I started to learn bossa nova rhythm with paradiddle on hands. When I tried to analyze it before (or while) playing my brain was just frying. All the programming cells tried to accomplish the parsing of the partiture, but with big red failing dot at the end.

The way was, as my teacher told me, to let it go. Close the eyes, reset the mind. Keep the beat with legs only for half a minute. Slowly. Use the body to understand it. And then do the sticks rudiment on top of it. Without thinking!

I was amazed. It worked just fine, the body knew what to do. I knew the bossa nova, I knew the paradiddle, but I had to let it be to make it happen together...

The great part of this story it that now (after two months from what happened...) I can analyze this rhythm with no single problem. Play it with pure analytical approach, no art-spirit involved. Of course it sounds worse this way, and I prefer go with da flow... I wish to know how all that drumming thing impacts my programming skills... it has to be deeply connected.