TED: Don't Miss it

Last Saturday I've had the pleasure to attend a TED conference: TEDxRoncade. The leading argument was the biodiversity but the interventions have been very various: computer science, technology applied to health care, art, history, psychology, and obviously nature and our interactions with it.

Spokesmen (and spokeswomen) were all at high level and the format of this kind of events (fifteen minutes to everyone) is ideal to avoid boredom and to provide only main points to the audience. I have to congratulate with the promoter of this event +Luca De Biase for his excellent work!

Do yourself a favor: locate the next TED event near you and take part. It will be worth it!

personal, TED Wednesday, February 26, 2014 No comments

Stop Patching And Start Rewriting

I bet you know "Back to the Future", the famous movie trilogy by Robert Zemeckis. It's the story of the time travels of the young Marty Mc Fly, played by Erich Stoltz, and... wait! Erich Stoltz? I know what you are thinking: "No, it was Michael J. Fox!". And you're right. That is what we all have seen on the screen.

But when Zemeckis started filming, Michael J Fox was not available, so, for five weeks, Erich Stoltz was the hero of Back to the Future. But Zemeckis was not satisfied. Stoltz hadn't the characteristics he was looking for. So he went to the producer (Steven Spielberg) and asked his permission to change the lead actor and throw away more than one month of work. Spielberg said yes (and provided some more money) and today we can say that he made the right choice.

Back to the Code

Now I guess you are thinking: "what is the relation between this story and computer science?" Thank you for the question. Let me answer with a couple of questions: how many times have you thought that it would be easier to totally rewrite a piece of code instead of modifying it to include new features or to fix a bug? And how many times did you eventually rewrite it?

My answers are respectively "too many" and "too few". But the problem is not that many times I've had the temptation to throw away weeks of work. You know, when you start writing a non-trivial program, it's impossible to know all cases and anticipate all the future developments and avoid every bug. Moreover, as the time goes by, you learn new techniques and change your mind about what is considered good programming. So it's absolutely normal to look at some code you have written three or four years ago and feel the need of changing it.

The problem is when you leave the structure untouched. There can be many reasons for these but usually the time is the main. And for your boss, "time" means "money". But what your boss pretends to ignore is that a software continuously patched will be less performing and less error-proof. And probably there will be the need to change it again in few time.

Conclusions

I'm not saying that you should rewrite your code at every modification. Instead you should spend some time to design the software to be easily extensible. My point is: when you modify a piece of code always ask yourself if it would be better to rewrite it. And, if the answer is yes, go to your boss and tell him about Erich Stoltz.

development, movies, working life Friday, February 21, 2014 No comments

The Puzzle of Motivation

Dan Pink during his TED talk

The man you see in the picture is Dan Pink, a career analyst that uses a scientific approach to investigate the mysteries of motivation. The results of his researches are summarized in this TED talk.

Spend twenty minutes of your day to view the video (it also has subtitles in forty languages).

It lasts eighteen minutes. Then, use the remaining two minutes to reflect.

Enjoy: The Puzzle of Motivation

motivation, TED, working life Sunday, February 16, 2014 No comments

Goto Is Your Friend

Yes Sir, that's what I'm gonna say!

I've started coding when I was 13. In Basic. And no, I'm not gonna say "good old times". Going back to those days, the only things I remember are the command AUTO to automatically create line numbers and the (ab)use of the GOTO statement.

Few years later, at the high school, my computer science teacher told me that goto is evil but luckily its use can be always avoided (see the Structured Program Theorem). One of the reasons for its bad reputation is that usually the code that uses goto is less readable and the program flow is difficult to follow. In two words: spaghetti code.

Only a couple of years ago I realized that this is not true. Goto is not evil by itself and in some (many) situations its use can produce a code that is more readable, optimized, and with small memory footprint.

Do you want some examples? How do you exit from multiple nested loops? Without using goto you should have at least a variable and an if for every loop that encloses loops and then you should have a bunch of breaks. And what is a break? A masked goto.

And what about multiple exit conditions that need to free allocated memory? Without using goto, you should duplicate the cleanup code with the risk to forget something every time you need to modify the code in the future.

These are only a couple of examples about the usefulness of the goto statement. If you are not fully convinced, have a look to this thread.

C, development Tuesday, February 11, 2014 No comments

Git Rulez

Every project developed by more than one person needs a versioning control system. And, in my opinion, it's a good idea to use a VCS for all non-trivial projects.

According to wikipedia:

Revision control, also known as version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information.

In my developer life I've used three VCS:

• CVS (Concurrent Version System)
• Borland StarTeam
• Git

And from the title of this post you should have understood that I believe the last is the best. It has a lot of features that help to manage big projects ran by hundreds of developers, since it was created by Linus Torvalds with the purpose to maintain the sources of the Linux kernel.

How It Works

Git is a distributed VCS, this means that when you clone a repository, you have the whole history and the all the branch tree in your PC. You can do your work offline on the repository and when you are done, push it to the remote repository. And it's not said that the remote repository you are pushing to is the main repository. It can be the repo of another developer that is working with you on a specific feature. In this way two or more persons can do their work without impacting the whole dev team.

Another difference with other VCS, is that Git does not track files but changes, even in different files. How many times your new features or bug fixes are made in a single file? Usually, adding a new feature means change several files; when you commit them, they remain together so it's easier to identify all the files changed and, if needed, revert the modification with just one command.

Moreover, this behavior lets you view an history of all the commits and lets you easily go in a well-known repository state even without having set a tag.

Branching

A Git book I've read says that books explaining other VCS talks of branching in the latest chapters. But in every Git book, you'll find branches treated within the first three or four chapters. Why this difference?

Simply because branching is a very powerful feature and in Git the creation a new branch is a very cheap operation. An with "cheap" I mean that there is no data duplication or hidden overhead. Simply two commits will have the same ancestor.

When you work with branches (in whatever VCS) a typical need is to do the same modification (for example an urgent bug fix) on different branches. Git provides the cherry-pick command to do exactly this: to replay a commit (i.e. the changes made to one or more files) in another branch.

Conclusions

This posts is only an overview of Git but I hope it's enough to make you understand how powerful this tool is. In the future I plan to write some posts about useful but almost unknown Git functions.

Git, versioning Thursday, February 06, 2014 1 comment

Long Life to Blogs

Someone said that blogs are dead because they have been defeated and overwhelmed by social networks. I believe this is not completely true. I'm not an Internet analyst or a social researcher and what I'm going to say only comes from my everyday experience.

Probably the only blogs that have disappeared in the last years are the ones talking about someone's everyday life. In this case, Facebook and Google+ are surely the winners. But the story ends here.

I'm a Linux developer and many of the resources that I need (documentation, samples, tutorials, troubleshooting, etc.) can be found on blogs. But also for non-technical arguments, such as politic or science, blogs still rock.

For this reason I decided to create this place. I plan to fill it with a lot of computer science, developing tips, and something about my passions.

So, long life to blogs!

The above image has been created with Tagxedo web app with many of the arguments I plan to treat in this blog.

blogs, personal Saturday, February 01, 2014 No comments