I’m currently reading the book Effective Programming: More Than Writing Code by Jeff Atwood and I’ve recently found this really nice text there: Sharpening the Saw. It basically talks about how we, as software developers, should be improving our skills to perform better in our jobs.

Sometimes we are so busy and involved in our daily work that we don’t dedicate any time to learn new things and improve our skills by our own. But it turns out that improving your skills will make you a better programmer and probably make you much more productive in your daily job, just like the story of the lumberjack that didn’t sharp his saw because he was too busy and spending too much time trying to cut trees with a dull saw.

My idea with this post is to talk about ways to sharpen your saw and how can you become a better programmer by dedicating some of your time to competence development and then performing better in your daily work.

One nice way that is quick and effective is to make some kind of coding kata every day. It can involve problem solving techniques, using some different programming language or anything that will make your brain work and learn something new every day, even if it’s a minimal syntax quirk of a language.

Problem solving is always fun, and there are some sites where you can go and find cool problems. Some of those are huge database of problems that you can pick randomly like:

• UVa Online Judge
• Project Euler

While there’s also some that already have the “problem of the day” where there’s not really a validation process but people can share their solutions and learn from the others, like:

• dailykata

Or you can also participate in competitions:

• TopCoder
• Facebook Hacker Cup*
• Google Code Jam*

*happen just once a year

Another way to grab new knowledge is to attend some of the amazing online courses from Coursera. I’ve attended the Algorithms Part I from Stanford and I’m currently oh the Functional Programming Principles in Scala by the University of Lausanne where the professor is the creator of Scala and it’s being really nice to learn new things and remember the things that were rusty and dusty in my mind since the university.

There are courses for all different levels in programming there, and I’m pretty sure you’ll find at least one that will interest you: https://www.coursera.org/category/cs-programming.

Another way to sharpen your saw is more old-school, but still very efficient, and it is: READING!

There are so many amazing books about software development out there that wouldn’t fit in this blog nor in my bookshelf, but I’ll mention some of my favourites:

• Programming Pearls - Probably my favourite book about programming, it covers some different topics in a nice and compact way and IMHO it’s a must-read for any coder
• The Algorithm design manual - If you like algorithms you’ll probably like this book, it’s not so dense but it can still give you a nice background for problem solving without making you dizzy :)
• Programming Collective Intelligence - Also a really accessible approach to the resolution of some problems that in theory can be complex

And you? How do you sharpen your saw? Is there any other thing that you would add to this list? Feel free to add as a comment!

Mastering a tool means much more than just knowing how to use it. When you know something really well, you should also know the problems and limitations it has. In other words, you know exactly why and why not use it in certain circumstances.

To exemplify the idea I will illustrate with a coding question:

“You have a string containing parentheses. Write a function to validate if the parentheses are properly nested”

The answer that comes from 9 out of 10 programmers is, without even thinking: ”REGEX!”

And if asked to elaborate the answer they get stuck and keep struggling with this alternative that is not appropriate for this case - it requires some recursive pattern trick that is not implemented in every regex engine and is expensive in terms of memory usage. Also it’s against the idea of finite automata that is the basic theory behind regexs - while there’s a dead simple algorithm that can do that with the best performance possible O(n) in one single traversal through the string and with constant memory space:

1
2
3
4
5
6
7
8
9
10
11
12
13

//O(n) and constant space
func nesting(s string) bool {
    x := 0
    for i := 0; i < len(s); i++ {
        if s[i] == '(' {
            x++ // Increments when '(' is found
        } else if s[i] == ')' {
            x-- // Decrements when ')' is found
            if x < 0 {return false}
        }
    }
    return x == 0
}

Bringing this idea to daily situations, how many times developers are choosing their preferred tool/language/framework to use in a project without really thinking about the problem they need to solve and the limitations the tool has, just to don’t leave their comfort zone?

Things like: using PHP-GTK to build desktop apps; Rails to highly trafficked websites with a lot of user-generated content where you can’t really cache that much the generated pages; using NoSQL databases to store data that is naturally relational (and vice-versa), etc… that when used in this kind of improper way usually imply in a high cost of maintenance, and in many cases require rewriting whole systems from scratch when problems start to pop everywhere.

But everybody has preferences, so how to avoid those biased decisions? In my opinion it can be avoided by not letting the decision be influenced by hype and not restricting the possible solutions by just the one or two that decision makers already feel comfortable with. Take some time to analyse the nature of the problem and the many different ways to attack it.

Assuming that good developers don’t take things for granted they might be able to understand how things work internally, (if they’re mature enough, they will also accept that their favourite option might not be the best one) and adapt themselves to a tool that might come as a better solution.

Related links

• http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html
• http://blog.feliperibeiro.com/2012/06/taking-things-for-granted.html

Pretty much every week there’s a new article trending in HackerNews with someone’s rants on PHP. Some are well formulated and strongly grounded while others are just vague texts with no real arguments, just basically saying “PHP is broken” without any strong reasons, alternatives or solutions.

I’ve been working with web development and mainly PHP for around 10 years now, I’m a Zend Certified Engineer (as if the term “PHP Engineer” makes any sense) and also a Computer Scientist (which theoretically means I’m supposed to know how to build software in the “correct” way), so I believe I have enough base to write a neutral and realistic analysis of PHP and that’s the idea of this post.

One third of the web runs on PHP, it’s used in small and big websites, pretty much every hosting service supports PHP and it is usually a valid option to consider when all you need is to get things done ASAP. But just like anything else in the world, it has problems.

There are only two kinds of programming languages: those people always bitch about and those nobody uses.

–Bjarne Stroustrup

If we look closely and without any prejudgement there are somethings we need to analyse: PHP is popular but it’s not cool. And that is quite a bad position to be, it’s the same situation of MS Windows for example: both are OK, accessible and serve a lot of people reasonably well, but people don’t usually enjoy them nor are really proud of using them and everybody loves to hate them.

However, it’s not difficult to understand the origin of PHP’s problems, they come from the very first days of the language with the philosophy around it. Unlike most of the traditional programming languages, there wasn’t brilliant people involved nor much thought put into it:

I don’t know how to stop it, there was never any intent to write a programming language […] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way. [1]

–Rasmus Lerdorf

So, it is definitely not a language for purists or scientists, but it lets you get things done in a quick way and, if you are a decent programmer, with a short and clean code and also with a decent performance in most of the cases.

The fact is that any language has its quirks [2] and it’s up to you, as a developer, to know well the tool you are using. The biggest issue here is not that the language you use has problems (because all of them have) but instead, that you don’t know which are those problems and pitfalls. That is something really typical of ”mono language programmers” and people that take things for granted [3] who, for the lack of deeper knowledge, don’t realise what’s going on and that things can be done in a better way.

In a very personal opinion, I believe PHP is a game changer in the history of the Web as it changed the way we develop software in this era and the whole paradigm of this industry. But with the poor decisions and indifference to the “state of the art” displayed by the core developers, PHP is now behind the others in many aspects and honestly, at least for me, it’s no longer my personal language of choice if I would start a new project or my own company/startup.

References

1. Interview with Rasmus Lerdorf
2. WAT – Destroy All Software Talks
3. Taking things for granted

During the last two years I have interviewed some candidates for software engineer positions and after analyzing those people I came up with the conclusion that the average programmer knows very little about computers.

As languages and frameworks evolve, programmers seems to know less about how computers work. Fifty years ago men went to space with less computing power than what we have today in the mobile phones we take in our pockets. In the 70’s and early 80’s, Atari games developers had to cry tears of blood to make those cool games fit in a 4KB cartridge, run with 128 Bytes of RAM and no VRAM.

Nowadays we have an extremely high level of abstraction that allows programmers to write code almost in human language without taking into consideration what’s behind it. As, for example:

• How many Ruby coders think about what it takes to sum two numeric variables with a dynamically typed language where numbers are objects and + is not an operator, but a method that can be overwritten even for an specific instance?

• Or how many Node.js coders know how an operating system scheduler works to make it possible for them to implement those asynchronous I/O thingies?

• How many jQuery coders consider what the browser and its JavaScript engine need to do in order to execute that animation effect he called in a single line of code?

Is it a bad thing? IMHO: yes and no.

You don’t need to know the mechanics of your car to drive it, but you will be a better driver and take the best of your car if you know how its engine works.

A high level of abstraction usually boosts programmers productivity, but there is a balance that needs to be measured. Treating programming languages, libraries and frameworks as black boxes won’t really help you compare different tools and pick the best one for a given problem. Also, as a software engineer you’re supposed to understand the engineering of the software you’re building and make the best decisions about it based on the analysis you do.

Looking on the bright side we can think that there will always be people working with the nitty-gritties of Computer Science and providing abstractions that make programming accessible for the masses, giving more people the opportunity to code and build web sites with pictures of catz.

P.S.: This post reminded me this amazing, and not so related, video:

P.P.S.: I’m not old, I just like looking at things with a critical eye! :)

I really like coding, for me it’s not just something that pays my bills but it’s specially something that I enjoy and have loads of fun by doing it.

During the last year I’ve dedicated a bit of my free time to develop some ideas, proofs of concept and learn new languages by writing real code instead of just reading artificial tutorials. So, as a kick-off for this new blog I’d like to talk a little about some of my pet projects that I’ve done recently and then share some of my ideas and knowledge I’ve acquired by doing them.

PHP Algorithms

Rasmus Lerdorf himself uses to say PHP is not a language for computer scientists, and indeed it’s not. It “just works”, but it also lacks in many points regarding elegancy and academic principles. Although I’ve been working with it for many years now and so I decided to check what could be done with it in terms of algorithms and data structures, so every time I remember some classic problem I try to implement in PHP and add to this repo.

What I’ve practiced/learned: I’ve remembered some classic algorithms and also took a look on PHP’s native Data Structures

URL expander

As soon as I’ve heard about Node.js and all its “wonders” I’ve decided to give it a try, so this was my first code using Node and Express.

It basically gets shortened URLs, makes an HTTP GET request and fetches the Location HTTP header of the response, helping you to don’t be RickRoll’d :)

What I’ve practiced/learned: It was my first contact with Node, so it helped me get the hang of it.

URL shortener

Now it was time to try Sinatra, Redis and build a REST interface.

It’s a quite simple project. All it does is handle the HTTP requests to calculate a hash for the URLs sent by POST (with this really simple hash function) and store it in Redis. And when a shortened URL is requested through GET, it retrieves from Redis and returns an HTTP response redirecting the user to the normal URL.

What I’ve practiced/learned: I got my first contact with two things I really started enjoying later on, and those are Sinatra and Redis. Also I’ve deployed it in Heroku and used it for some time as my personal url shortener frnb.in (no longer online)

Presley - PHP Micro-framework

After playing with Sinatra and really having fun doing it, in a long airplane trip I decided to make something to help time pass. So I’ve built this micro-framework that’s just a simple clone of Sinatra and all it does is map URLs to callback functions and routes the requests to execute those functions.

It’s ridiculously simple but can be a nice way to build simple REST interfaces.

What I’ve practiced/learned: It was extremely simple, nothing really new :)

Nodecached - A memcached server in Node.js

Node.js is not a silver bullet as many people think, but it’s really cool for this kind of application that is meant to be fast dealing with sockets and possibly a lot of open connections. I also took the chance to have a first contact with CoffeeScript.

So, I got the specification for the memcache protocol and implemented it from scratch without looking for the current C/C++ implementation of memcached and started by just storing keys/values in a JavaScript object and it now has a known issue that you can not store things with “prototype” as key :)

I’ve also started implementing a cache expiration and memory management engine using the LRU principle but it’s still not ready.

What I’ve practiced/learned: I’ve enjoyed a first contact with CoffeeScript and started thinking about efficient ways to manage memory (still in progress)

My Go Fulltext

Go is the language that most caught my attention recently. It has everything I like in a programming language, but unfortunately I couldn’t dedicate more time to really learn it.

Although during one specific afternoon I’ve decided to go through its tutorial and build something on my own, so I’ve implemented this text files indexer.

I haven’t researched how Fulltext indexes work, but if they don’t do any magic there, I assume it’s not so different from what I came up with.

What I’ve practiced/learned: Go is an awesome language, I really got amazed with it and also this small project made me think about efficient ways to index content.

Image lazy loader

Looking for some brazilian news at Globo.com I noticed they were using a nice way to save bandwidth by loading low-res images in the whole site and substituting by the originals in hi-res mode only when the images are in the browser visible area.

So I came up with this implementation for the idea in CoffeeScript that is not compatible with older versions of IE, but is enough to prove the concept.

What I’ve practiced/learned: It was quite a simple project that I did in two hours or something, the new thing I’ve learned with it was mainly the DOM events I needed to handle.

And that’s all! The idea of this post was mainly show that coding in your free time is not just fun but you can also learn a lot by doing it!

Hey there!

If you used to read my old blog in the past it might look weird that it’s now empty and in English, but have no fear, the old content will remain available at http://old.feliperibeiro.com.

The idea of this new blog is to have it more active, more technical and in English. Since I’ve been living abroad and having contact with hackers from many countries for the last two years, it made no sense to keep writing just in pt-BR.

This won’t be a blog about any specific language, my idea is to just post random geeky things, related to IT career, hacks, tech book reviews, tips & tricks and anything that can possible come in handy for myself or someone else later on.

So, I hope I can keep up with this idea and try to share some awesome stuff here :)