March 2015 | while (2)

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

3 Ways To Open A Lock - Part 2

In the previous post, I've talked about guessing your password. Now I'm gonna cover another case.

Stealing Your Key

Now you have a super secure password and you feel calm and safe, right? But thieves are in ambush. Whenever you use your password in an app or online site, they can steal it: this is a man-in-the-middle attack.

It can be possible if your credentials are transmitted in plain text through a unencrypted connection (for example the WiFi of hotels or airports) but there are some situations where it succeeds even over a secure connection (SSL/TLS).

Of course, your password can also be stolen if the thief can access a website database. You may argue that if someone has the access to a server content, it should not care about passwords: all your data are in his hands. This is not completely true: hackers know that many people use the same password across different services, so, for example, knowing your email password can lead them to access also your bank account. This is why it's a good practice to use a different password for every service.

Nowadays, I don't think any online service is crazy enough to save password in plain text. Simple hashing has been quite common in the past years, until someone discovered that it can be overtaken by hash dictionaries and rainbow tables. For this reason, a bit of salt has been added to plain hashing. Salting, in this situation, means adding few random characters (called "salt") to passwords before hashing. To increase security, salts are stored in a separate database.

In any case, a weak password can easily be discovered, no matter the server security, so the suggestion is always the same: use strong passwords!

security Monday, March 23, 2015 No comments

The Worst Problems Of IoT

Security and privacy. Well, this post could have ended here, but since I'm a bit talkative (just a bit), I'll try to argument.

First of all, Internet of Thing

[...] is the network of physical objects or "things" embedded with electronics, software, sensors and connectivity to enable it to achieve greater value and service by exchanging data with the manufacturer, operator and/or other connected devices.

via Wikipedia

This short description should be enough to make you understand why privacy is a serious issue. If you don't feel the risk, just think that smart TVs send everything you say to a remote data center - and some of them don't even encrypt it.

The security risk needs some more explanations. Since embedded devices are usually not so powerful (mainly for a matter of cost), it's not possible to apply all the best practices needed to ensure a top level of security.

In addition, as new exploits and security flaws come out, those devices should be updated, but the producer may decide to not provide patches for devices considered too old. This is what happens today with many smartphone producers that don't distribute new Android versions for relatively old devices.

Don't get me wrong, I'm sure that IoT can improve our houses and be wealthy for the environment. But, this should not make us forget the other aspects.

Suggested read: An Internet of Things that do what they’re told

IoT, security Wednesday, March 18, 2015 No comments

Coding Is Funny, Debugging Not So Much

Measurement of code quality

I have to admit it. I have some problems with dynamically typed languages. Even if I love Python, I'm always worried about using one of those languages in a production environment. It's not because I absolutely want to define the type of variables but because I don't trust other developers. And with "other developers" I mean also myself in the past.

My colleague +Daniele Veneroni provided me a great example with his funny post a couple of weeks ago. I'm sure that he is smart enough to never write such a function, but out there there are lots of bad programmers.

Let's take a close look to the function.

local function isStaticPlugin(pluginName)
  if staticPlugins[pluginName] then
    return true
  elseif dynamicPlugins[pluginName] then
    return false
  else
    return 'WTF'
  end
end

This violates at least three golden rules:

every function must do a single thing (and do it well),
the name do not match what the function does (in fact it does also check if the plugin is dynamically loaded or it's not present), and
the name suggests that the possible returned values are just true and false.

You may object that it's just a matter of style. No, sir, it isn't. Now I'll show you why.

Bugs Hard To Find

Just to be clear, these issues are not specifically related to Lua or to dynamically typed languages. You can do the same mistakes in C by returning an int. Someone using this function may check only for the true value and then put an else to handle the condition of dynamic plugins. This obviously will lead to unexpected situations or an error whether the plugin does not exist.

Dynamically typed languages aggravates the situation. If the value returned by the function is stored in a variable, every time that variable will be used in the code, there will be the risk of type mismatch errors.

In addition, in Lua ('WTF' == true) evaluates to false but 'WTF' evaluates to true in a if condition. So, depending on how the checks is made you may have false positives both on static and dynamic plugins.