Code Review

During past few weeks, I've been reviewing an old codebase. Some functions were in place since 2008. You may think that those functions are bug-free. After seven years of usage, every issue should have emerged.

But the story is different. The number of errors I've found is impressive. Memory leaks, files left open, checks on conditions that can never be true (see also the last Horror Code), and, worst of all, logical errors. What do I mean with logical errors? Let me give you an example.

A Logical Error

There is a file descriptor declared as a global variable (OK, this could be considered a logical error too, but please keep reading) and a function that does some elaborations and then writes the result in a file descriptor. Among the parameters of this function there is a file descriptor... unfortunately it is never used. The writing is done on the global variable.

Everything works fine just because the global fd is the only one used in that program. What if in the future someone would have used that function passing a different fd? How long it would have take to find the bug?

By the way, the compiler has signaled with a warning that a parameter of the function was not used but nobody cared. You should always take care of warnings!

Conclusions

A code review is always a good thing to do. Probably you won't find big bugs but surely the stability and the quality of your software will be improved. And maybe that strange situation so difficult to reproduce will never be reported again.

Image by Randall Munroe licensed under a Creative Commons Attribution-NonCommercial 2.5 License.

personal, working life Friday, June 26, 2015 No comments

The Day That Never Comes

The deadline is close. The customer is waiting for your fix. Your mate needs your patch before going home. No matter which of the above situations applies: the only way to accomplish your job is taking shortcuts and cutting corners.

You do not check some error conditions, use a fixed string instead of a localized one, do not properly free all allocated memory, etc. Your code compiles and seems to work fine but you know that it must be improved as soon as possible. So you tell your boss and/or the product manager. The response they usually give me is: "As soon as there will be some time, we'll fix it."

Guess what? That time never comes. There is always something more important or urgent to do, until a customer (usually an important one) reports an issue with the corners you have cut. Now the priority is to fix the problem as soon as possible, not to review the code to make sure it cannot happen again.

There is a logic in this: the customer doesn't care about code quality (even if he should). He just wants his software to work without errors. But for your company, it must be different. Why isn't it so?

Well, the answer I found is that for a customer is more important to have a quick solution than a bug-free software. It may seem pretty odd but just think about yourself. You buy a new smartphone and it just works as expected: you probably don't spam every social network to tell the world that your new iSomething is OK.

But I bet that if you find an issue and the customer service is really kind with you and the problem is solved in a couple of days, you'll tell your experience and suggest that brand to your friends.

This is called marketing and, on the past, there has been a PC producer that used to take advantage of this mechanism. But this is another story. At present, the only thing I can suggest you is to avoid shortcuts. At least unless you are in the marketing department.

Image by Nic McPhee licensed under Creative Commons Attribution-ShareAlike 2.0 Generic.

development, personal, working life Sunday, June 21, 2015 No comments

Code Will Tear Us Apart

There's nothing worst than read the code of someone you consider a good programmer and find tons of anti-patterns. Of course often there are good reasons behind some choices. Such as deadlines.

Jokes aside, I am conscious that my old code sucks too. This is because I continuously try to improve my knowledge and learn from my colleagues and from my mistakes. And also from my colleagues' mistakes.

Are We Writers?

Sometimes I read about parallels between novel writers and programmers (yes, I'm guilty too). It may work, but only on a superficial level. Because the code we write is not judged for the style. This is also why there are more "good" programmers than good writers.

From the customers' point of view, the only thing that matters is that the software does what he wants. But we know that this is quite impossible: bugs happen. In addition, new features are required.

From a developer's point of view, it's important that the code is understandable and easily extensible. The problem is that sometimes it's more convenient to rewrite a part of code instead of understanding and fixing it.

Just as an example, once in a file, I found a function called manage_parameters(). It was quite long, so I didn't analyzed in deep its code but it seemed correct. The next function in the file was manage_parameters_without_making_mess(). The developer that wrote the latter told me that he didn't have time to understand why the first function sometimes failed.

The Truth (?)

The truth is that we forgive (and often forget) our own mistakes, hiding behind poor excuses. But, at the same time, we are ready to point our fingers against other developers, especially if they are considered good programmers.

Bottom Line

If you think I've read your code and this post is about you, maybe you should spend some time to review what you have developed in the past.

Image by Miguel Angel licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic License.

development, personal, working life Wednesday, May 27, 2015 No comments

Which Programming Language You Should Not Learn

Lately, I've seen many times young developers asking which programming languages are worth learning. Obviously I've seen a lot of superficial answers, mainly because people tend to suggest things they like. Programming has many levels of complexity, so, before providing an answer, it's better to understand why you want to learn a new language.

What Is Your Goal?

If you want to find the best paid job, you should focus on languages that are old but with a large base of existing legacy code (such as ADA or COBOL or Fortran) or vice versa, on brand new ones (Go, Rust). Both choices have a couple of drawbacks. There are few workplaces in the world (this is why they are well paid) and you cannot know if your job will still be required in five years.

But maybe you just want to get a job quickly an not too far from home. In this case JavaScript is your choice. You can use it client-side, server-side, and even in mobile app development. Pretty cool, isn't it? Unfortunately for you, the world is full of good JS developers, so you'd better become a damn good one if you want to stay over the average and be noticed by some company.

Do you want to explore the Object Oriented paradigm? You have multiple choices: C++ (you'll need just some years to master it), Java (if security issues won't kill its virtual machine before) or Python (when you'll understand its concept of reference).

If you want to understand better how things works at a lower level, C is still a choice, especially in embedded systems but you have to be ready to deal with raw data management, dirty pointers, and memory leaks.

If you are an Apple fan, try with Objective C and Swift. If you love MicroSoft, C# and Visual Basic are for you. But be conscious that you are tighten to a single company that tomorrow can decide to completely change the language and make you throw away your old code (who said VB 6?).

Conclusions

I can go on with many others (Lua, Scala, PHP, Ruby, Perl...) but I think you have understood: the perfect language does not exist. In any case, having a good experience of a couple of widely used programming languages and knowing the basis of some of the newcomers is probably the best choice you can make.

development, personal Tuesday, May 12, 2015 No comments

Eclipse: Good Editor, Bad Build System

For a large C/C++ project I'm involved in, Eclipse has been chosen as default IDE.

I have to say that I really like the editor. It has some functions that make me save time, such as the automatic highlight of the variables, the search for references inside a single project or the whole workspace, the possibility to work with gdb remotely (you know, I work on embedded systems), etc. I also think that some other things can be improved, for example the search, but all in all it's a good tool, in my opinion.

There's only one thing I have to complain: the build system. Because:

• it is really slow,
• the management of dependencies doesn't work as expected, and
• errors and warnings are presented in a misleading way.

For this last point, I suppose this is because when running the compiler and the linker, stdout and stderr are parsed separately and then printed in the same window. The result is that error messages may appear after an unrelated build command.

The dependencies are another thing that in my opinion needs to be improved. For example, it would be great if the build stops as soon as one of the related builds fails. I'm really surprised this doesn't happen.

Speaking about the build speed and why it's so important, I totally agree with this post. Please consider spending five minutes of your time and read it.

The solution to these issues is to use custom makefiles. You may spend some time to set them up but, believe me, you'll save precious time when compiling and you won't be losing the concentration.

development, Eclipse, IDEs, personal Thursday, May 07, 2015 No comments

When Should I Create A Function (Or A Class)?

This is a damn good question. As I've suggested in this post, functions should be short and do just one thing. The Linux kernel coding style sets even a maximum length of fifty rows for a function.

But following to the letter these rules on big projects, leads to thousands of micro snippets that make the code almost impossible to understand. This situation is more evident in object oriented languages where you may be tempted to create classes even if a simple structure would be enough. One of the techniques that make this thing evident in C++ is to implement every trivial class in its own .hpp file.

The general rule is that, if a function or a class is used only in a single piece of code, maybe it doesn't need to be separated. It seems reasonable but it may lead to awful functions difficult to understand. Another exception may done if you have the feeling that, in the future, that function/class will be used somewhere else.

The truth is that it's all about your sensitivity as a programmer. In this case, the experience should guide you to the right choice, because

The rules are... there ain't no rules!

And, in any case, a good refactoring from time to time can improve your code.

development, personal Saturday, March 28, 2015 No comments

Happy 1st Birthday

Today this blog turns one. One year ago, when it started, I was not sure whether it would have survived more than few months. Conversely, with 68 published posts and more than 10.000 pageviews (many of those in the last month), I'm pretty satisfied.

To these newly arrived visitors, I want to provide a list of the seven posts I've written, that I consider the most important. This list doesn't match the one with the most viewed articles, but I'll get over it ;-)

• Stop Patching And Start Rewriting
• 4 Things to Do Before Starting a New Project
• 6 + 1 Tips to Write Easily Extensible Code
• You Are Not A Programmer
• 0 Errors - 0 Warnings
• Reliability First - Embedded Systems
• The 80-20 Rule: Pareto And The Devil

So now, what's next? More posts, of course. Maybe some guest-post (I've asked a couple of colleagues of mine but apparently they are lazier than me).

Thank you all for reading these pages, and, if you have some ideas on how to make them better, please share your thoughts.

Sincerely,
Luca

blogs, personal Sunday, February 01, 2015 No comments

VeryBello Is The New Italia.it

In the beginning (2007) there was Italia.it, a promotional website commissioned by the Italian government. Its main goal should have been attracting foreign tourists. The current version is not so bad, compared to the first one, but there are still some things that don't work.

I'm not referring to technical details (except the carousel that changes image too fast on my browser - and carousels are known to be an usability issue even at an average speed). The biggest marketing issue I see here is the fact that the site has been localized only in the major European languages. For example, Chinese, Russian and Arabic (three languages spoken by many tourists that visit Italy nowadays) are missing.

Back to the present. During last weekend, the Italian government presented a brand new site, named VeryBello!, with, more or less, the same purpose of the other. The bad news is that it's even worse.

Slow, not accessible, localized in Italian only, not to mention the name. Besides, in the first version of the top picture, a part of Italy was missing. I hope that no one in the world will judge Italian web designers and programmers basing on the quality of those institutional websites.

But, over all, I hope that nobody judges the whole Italy by the job of few people and the inability of its government to tell if that job is well done.

fail, optimization needed, personal, politics, usability Tuesday, January 27, 2015 No comments

The 80-20 Rule: Pareto And The Devil

Probably only the number of webpages with images of cats is greater than those talking about Pareto principle. Nevertheless I want to add my own just because I think this is not so clear to all my colleagues.

A rough definition of this law may be:

To accomplish the final 20% of a job, you'll need the 80% of the total time.

If you are close to the deadline of a big project, this sentence sounds quite depressing, isn't it?

But if you have some experience, you can say that this principle is absolutely correct. How much time have you spent in moving UI objects one pixel at time until the Project Manager is satisfied? And what about colors? And that damn string that doesn't fit the printed page? And the final comma to be removed from JSON arrays? And that strange bug that only happens on few PCs?

All these things are important - but not fundamental. They don't represent the core of the application, just some details. In fact, another way to express nearly the same concept is:

The Devil hides in the details.

In my opinion, it is all in the difference between a proof of concept and a real application. A software, in order to be given to a customer, must be:

• efficacious - it must do its job
• efficient - the job must be done in the best way possible (according to time constraints and remembering that perfection is impossible to achieve)
• reliable - it must handle failures in a proper way and always preserve user's data
• usable - the user must find it natural to use (*)

People that doesn't have experience in coding "real" applications usually underestimate the benefits of usability, reliability and sometimes efficiency. Without these characteristics, your software will be nothing more than a proof of concept. And you are not creating proof of concept, aren't you?


(*) = I know this is not the most complete definition of usability, but I think that it gives an idea about what should be the final intent of any user interface.

development, personal, working life Tuesday, December 23, 2014 No comments

Insanity And 4 Other Bad Things

Dilbert by Scott Adams

The definition of insanity is doing the same thing over and over and expecting different results.

Some say this sentence has been first pronounced by Benjamin Franklin, others attribute it to Mark Twain or Albert Einstein. They all are wrong. But the quality of the people to whom this quote is ascribed should tell you something about its correctness.

There is also an ancient Latin maxim (by Seneca) that states a similar concept:

Errare humanum est, perseverare autem diabolicum et tertia non datur.

To err is human; to persist [in committing such errors] is of the devil, and the third possibility is not given.

[Thanks to Wikipedia]

With this premises I have to conclude that the Devil is causing so much insanity in the world nowadays. Take this as a general discourse but it seems to me that many people keep doing the same things in the same old way, facing every time the same problems and delays without understanding that things can go really better just changing few things in their way of acting.

Excluding supernatural interventions, in my experience, this kind of behavior is mainly due to four reasons.

1. (Bad) Laziness

Not that kind that makes you find the fastest solution to solve a problem. This laziness is absolutely harmful; it's the concept of comfort zone amplified to the maximum. "I don't wanna change!" and "I don't wanna learn anything new!" are his/her mantra.

Every change in procedures is considered a total waste of time and a new developing environment is simply useless. If you have a couple of people of this kind in your team, you can be sure that every innovation will be hampered.

To overcome this behavior you can try to propose a total revolution in order to obtain a small change.

2. Arrogance

"I'm sure I've made the right choice!" no matter if this decision has been made years ago and now the world has changed. By the way, the initial choice may have been wrong from the beginning but nothing can make him/her change his/her mind. Probably this has something to do with self-esteem.

It's quite impossible to work together with this kind of developers, since they will never admit their faults and they'll try to put the blame on others.

Sometimes a good strategy may be to suggest things as they have been proposed by the arrogant himself.

3. Ignorance

There's nothing bad in not knowing something. The problem is when he/she doesn't care about his/her nescience (see point 1), when he/she doesn't want to admit it (see point 2) or when he/she doesn't trust others' suggestions.

This last point may seem a little strange: if I don't know something, I have to trust on someone that is more informed or skilled than me, right? Unfortunately it doesn't work this way. If you need a demonstration, search "chemtrails" on Google.

I don't have a suggestion on how to minimize the impact of these guys in your team. Maybe a training can be useful but the risk is that they don't trust the teacher.

4. Indifference

This is the worst, especially if referred to a manager. He/she doesn't care about the feeling of his/her subordinates. "There is no need they should be happy doing their job" and "It's not a problem if they spend more time than what's needed in trivial tasks that can be automatized" are his/her thoughts when someone is complaining.

I don't know if there is some sadism in this behavior, but it's quite frustrating. And it's very bad for the team and for the whole Company.

Conclusions

During my life, I've had the "opportunity" to work with people belonging to one or more of the above categories and I can assure that the last is the worst. You simply cannot team up with someone that doesn't care about you.

Suggested complementary read: Is Better Possible? by Seth Godin.

personal, working life Tuesday, October 14, 2014 No comments

You Are Not A Programmer

So you write code every day, maybe in a nerdy language like C or even in assembly. And a company is paying you for this job. When someone asks you "what do you do?", it's normal for you to reply "I'm a programmer", isn't it?

Well, let's see if you are a liar. This is a simple yes/no questionnaire about what you have done in the last two years.

The Real Programmer Test

1. Have you studied a new programming language?


2. Have you used a new technology?


3. Have you spent some time to optimize your code?


4. Have you programmed for your pleasure out of the working hours?


5. Have you eaten at least 50 pizzas?


6. Have you drunk at least 3 coffees every day?


7. At least once did you choose to not use your favorite programming language because you thought it was not the best choice for a project?


8. Have there been more happy days than sad days when doing your job?

If you replied "yes" at more than half of the above questions, congratulations, you are a real programmer!

Explanation of the Test

If you are not a real programmer, maybe you cannot understand how the above questions come from, so here there are some hints.

• A programmer is curious by nature: he likes to learn new languages and technologies, even if they are not required by his job (questions 1 and 2).


• A programmer knows that every code needs some refactoring at some point (question 3).


• A programmer is happy when he can write code (questions 4 and 8).


• A programmer is realistic: he knows that one-size-fits-all doesn't exists in computer science; in other words, for some purposes a language/technology can be better than another (question 7).


• A programmer needs to have it's brain constantly fed by carbohydrates (pizza) and sometimes powered by caffeine (questions 5 and 6).

Having said that, you may argue that many of these characteristics are innate. Well, you are right! Many people write code because they think it's just like any other job but they are wrong. Programming needs passion, devotion and the right way of thinking. And over all (as I've read in a pizzeria):

If it were an easy job, everyone would be able to do it

Image by icudeabeach

motivation, personal, working life Tuesday, September 09, 2014 2 comments

Authors In The Open Source World

Last week, Seth Godin wrote another great post. This time the argument is the difference between companies and authors. No company would endorse a competitor while writers often suggest books written by others.

The implicit message is that culture is not a product.

Image by Andrew

For FOSS developers it works almost the same. If someone is creating a good software, his project will be not only praised but also improved by other developers. And the good part is that they share their work for free.

For these reasons I think that with the following sentence, Seth is describing a situation wider than he thought.

It's not a zero-sum game. It's an infinite game, one where we each seek to help ideas spread and lives change.

open source, personal Thursday, September 04, 2014 No comments

Reliability First - Applications

What does reliability mean in computer science? Speaking about an application, how can we say it is reliable? I don't know if there is a shared opinion but mine has maturated after a scary situation.

Some years ago, on my previous workplace, we created a huge file with a very powerful and even more expensive third party software. But some seconds after having pressed the save button, the software crashed. Panic. We searched for the saved file and we found it. Don't panic. So we restarted the powerful-and-expensive-third-party-software to reopen the file but it failed. We tried several times even on other PCs without success. The (binary and proprietary) file seemed to be corrupted. Okay, panic!

Fortunately we also owned a licence of a similar software, much less powerful and much cheaper (about twenty times cheaper). We had nothing to lose so we tried to open the file with this cheap software and... it worked! All our job was there. So we saved the file with a different name in the cheap software and eventually we were able to open it with the expensive software.

After that incident I have a clear idea of what reliability means when speaking about applications. And you?

Image created with GIFYouTube. Scene taken from movie "Airplane II: The Sequel".

apps, personal, reliability, working life Monday, August 25, 2014 No comments

Horror Code: the Matryoshka Functions

Image by Fanghong and Gnomz007

Some years ago, when I was a Windows developer, the maintenance of a big project has been assigned to me. My job was to fix a couple of minor bugs and add some new functions. The problem was that the creator (and previous maintainer) have resigned years before, leaving absolutely no documentation.

The only thing I could do was to look the code and read the few comments. At some point, I found a call to the function GetName(). Changing the name returned by that function was one of the purpose of my job, so I looked for the implementation. And this is what I have found:

CString GetName()
  {
    return GetValue("Name");
  }

Pretty useless, don't you think? OK, let's see the implementation of GetValue():

#define MAIN_APP   "Main"

CString GetValue(CString szField)
  {
    return GetField(MAIN_APP, szField);
  }

Is this a joke? Well, let's see where the story ended:

#define MAIN_INI   "main.ini"

CString GetField(CString szSection, CString szField)
  {
    char szResult[100];

    GetPrivateProfileString(
        (LPCTSTR) szSection,
        (LPCTSTR) szField,
        "App",
        szResult,
        100,
        MAIN_INI
    );

    return szResult;
  }

Surprised? Now I'm sure you are wondering why someone had done this. I'm still wondering too.

horror code, personal Sunday, August 10, 2014 No comments

Write and Rewrite (and Make it Better)

I'm not comparing myself to Hemingway, but, when I write a new piece of software, for me it works the same. I usually write code in a quick-and-dirty way just to make things work. I have to follow my stream of consciousness and put down the basis of the algorithm.

Then, when something starts to work, I begin to make it look better. This means that I change variables like goofy, pluto, etc. with more descriptive and meaningful names. I try to see if I can move some piece of code into a function or if there is a more performing algorithm to be used. In the end, I look at errors, particular situations and memory leaks.

The final result is pretty different from the original code, but it's surely (?) better written, more readable and more performing. Maybe you can argue that I could write directly a better version and limit the modifications to small cosmetic things, so I would have saved time.

My answer is that it's not so easy. For example, managing error codes and particular cases or finding meaningful names for variables and functions is something that takes some time and, if the stream stops, it probably will take longer to accomplish the work.

What about you? Do you ever follow your stream of consciousness? Or do you prefer to immediately take care of all the details?


Image create with Pinwords - Picture of Ernest Hemingway taken from here (public domain)

development, personal, working life Tuesday, August 05, 2014 No comments

Details and Respect Make the Difference (for Me)

How many weather apps there are in the application store of your smartphone? And how many virtual keyboards? And browsers? There are millions of clones out there but you are using that particular app and you don't want to change it. Why?

[ Laziness may be an answer, especially if you are a developer like me ;-) ]

Jokes aside, often I like to see if there are alternatives to the apps I use everyday. Sometimes I find good things but most of the time I keep using my old apps. So, which are the reasons for (not) changing? For me, mainly two: details and respect.

Usually the main feature is something that works pretty well in all clones. Any feed reader is supposed to let you read your favorite blogs. But only few let you have a customizable sharing button. It's a very small feature, a simple detail, but to me it's absolutely convenient.

Honesty. Trust. Respect. Love.
Good rule to follow in business and in life.
Image by Zaneology

But before trying a new app and evaluate its details, I check its permissions. I consider them a form of respect. Why do a weather app want to access my contacts? Why do a dictionary need to know to my position?

I know the answer: nothing is free. But this is a wrong answer. It would be different if the developer tells me: I need to access your GPS data in order to propose custom ads and keep the app free.

Maybe he is just bribing me but al least he don't think I'm so stupid to not understand that the permissions the app is aking for are not related to its features.

apps, ethics, personal Tuesday, May 27, 2014 No comments

Horror Code: the Impossible Function

This is one of the less readable functions that I've found in my life. I've removed any reference to structures and variable names, according to the Italian law about privacy ;-)

I don't want to add any other comment. Enjoy!

static int my_function( /* Parameters */ )
{
  /* Some code */
  int j;
  for(j = 0; j < 2; j++) {
    /* Some code */
    if (j == 0) {
      /* Some code */
    } else {
      /* Some code */
    }
    /* Some code */
    if ( /* Condition */ ) {
      if ( /* Condition */ ) {
        /* Some code */
        if ( /* Condition */ ) {
          /* Some code */
          if ( /* Condition */ ) {
            /* Some code */
            if ( /* Condition */ ) {
              int i;
              /* Some code */
              for(i = 0; i < length; i++) {
                /* Some code */
                if ( /* Condition */ ) {
                  /* Some code */
                  if ( /* Condition */ ) {
                    if ( /* Condition */ ) {
                      /* Some code */
                      if ( /* Condition */ ) {
                        /* Some code */
                        if ( /* Condition */ ) {
                          /* Some code */
                          if ( /* Condition */ ) {
                            /* Some code */
                          }
                          /* Some code */
                          if ( /* Condition */ ) {
                            /* Some code */
                          } else {
                            /* Some code */
                          }
                        } else {
                            /* Some code */
                        }
                        /* Some code */
                      } else {
                        /* Some code */
                      }
                      /* Some code */
                    } else {
                      /* Some code */
                    }
                  } else {
                    /* Some code */
                  }
                } else {
                  /* Some code */
                }
              }
            } else {
              /* Some code */
            }
          } else {
            /* Some code */
          }
        } else {
          /* Some code */
        }
        /* Some code */
      } else {
        /* Some code */
      }
      /* Some code */
    }
  }
  /* Some code */
  if ( /* Condition */ ) {
    /* Some code */
  } else {
    /* Some code */
  }
  /* Some code */
  return 0;
}

The real function has 113 rows and most of the code in the else's is made of debug prints. The innermost code, the only one that actually does something, is indented 13 (thirteen) times.

Wasn't there a clearer way to write that function?

C, development, horror code, personal Sunday, April 27, 2014 No comments

The Month Lengths Problem

The first time I've heard of this problem, I was 14.

At school, during the math class, we started to learn the basics of programming using a language called L2P (no, you won't find it on Wikipedia and, no, it's not worth learning it).

Anyway, this is, more or less, the problem the teacher gave us to solve:

Write a function that returns the number of days of a month in a given year.

Plain Solutions

Any solution must start with the management of February.

if (month == 2) {
        if (!(year % 100) && (year % 400))
                days = 28;
        else if (!(year % 4))
                days = 29;
        else
                days = 28;
}

Once we have done with the most troublesome month, one solution can involve an array of twelve integers filled at design time with the right numbers. This is probably the way that I'd solve it today but I don't think the teacher would have liked it.

Another good solution is to check first the months with 30 days since they are only four: April, June, September and November.

if ((month == 4) || (month == 6) || (month == 9) || (month == 11))
        days = 30;
else
        days = 31;

Obviously the above solution can be rewritten, in a more readable way, with a switch statement. I'll leave it to you as homework ;-)

Well, you can say that the above code is the solution to the problem. And, when I was 14, I was convinced too. But the teacher was not satisfied. She had another solution.

C'mon, Show Me How Smart You Are

The management of February was the same, but for other months the code was a little tricky.

if (((month < 8) && !(month % 2)) || ((month > 8) && (month % 2)))
        days = 30;
else
        days = 31;

Have you understood the logic behind this? Basically, the months with 30 days are:

• the even ones between March and July and
• the odd ones after August.

You can tell this if you think deeply about the numbers (like a math teacher is supposed to do). But is this a good solution? No, it isn't. And probably it's the worst.

Keep It Simple, Schoolteacher

It has at least two weaknesses: performances and readability. Speaking about the execution speed, two comparisons and two modules are definitely slower than four comparisons.

But the biggest issue is the second: you don't have to show me that you are a good programmer. If you write code that is not easily understandable, you will never be a good member for a development team where everyone should be able to modify each others code.

So, dear teacher, you have been rejected in Computer Science.

A Final Confession

OK, I confess. I've been a little too trenchant. The teacher's solution is not so bad. It has a big quality: the spur to think different, to explore different solutions. Because only comparing different things you can choose the best one.

algorithms, development, personal Monday, April 07, 2014 No comments

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

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