I dati sono ovunque, ma la capacità di strutturarli in informazioni intelligenti e architetture finalizzate, no.

In questo differenziale risiede il valore dell’Ingegneria dell’Informazione.

A quasi un anno dalla mia laurea ne ho finalmente trovato una definizione concreta!

The update will be available via OTA, but if you can’t wait, follow this guide!

1. Download the OTA Package from here: http://t.co/i8NjJoLo
2. Rename it to update.zip
3. Copy it to the root of the internal storage
4. Power off the device, hold Volume Up and Power to reboot into the bootloader
5. Select “recovery,” then hit the power button
6. Once the warning triangle appears, hold the power button and hit volume up
7. Select “apply update from /sdcard” and choose the update.zip
8. Once the process is finished, simply choose “reboot system now”
9. Once it reboots, BAM! You’ve got ICS. Congratulations!

Okay, how can I change mine? To edit/change/enable the login banner you need root access to the system. open up /etc/ssh/sshd_config in your favorite text editor and find the line that says “Banner …” in some cases this line is commented out, make sure to uncomment it.

I recommend changing the file it points to, I usually put mine in /etc/ssh/banner(Banner /etc/ssh/banner) this is a plain text file, so you can pretty much enter anything you want, but be aware that not everyone runs their ssh client in full-screen. after you’ve changed the banner file, you will need to restart your SSH server, in debian-based systems this can be done with /etc/init.d/ssh restart don’t worry, users will not be kicked out.

Click here to download he Ascii of my Hypno Toad in the above image.

DRY is usually the easiest principle to understand, but it is quite harder to apply. It means that when finding similar code in two or more places, we should abstract them into a new method and change the previous code fragments so they will now call the new method with the appropriate parameters.

DRY is maybe the most universal coding principle, I have never found a developer who would argue that repeating code is good, but, I have found developers that forget about this principle when coding.

2. Write short methods.

There are three very good reasons for writing short methods. In this way, Your code will be:

• easier to read.
• easier to reuse (short methods are likely to produce loose coupling).
• easier to test.

4. Use good names for your classes, methods, variables and everything else.

There is nothing nicer than using some other developer code and not having to read its documentation because the names of the classes and the methods are telling us everything, so, make everyone’s life easier and take this approach, expend always a few seconds before naming any element in your code. Please, do it.

5. Assign the right responsibility to each class.

One class, one responsibility. But not any responsibility, the right responsibility: so if we have the class ‘Customer’, we won’t assign to it the responsibility to create a new sales action, we will just assign it the responsibility to handle all the data related with a customer.

6. (Too many) Comments are evil.

Most of developers taught that comments are good, and actually it’s better to have a comment in an obscure piece of code than just having the code by itself. Even better than having a comment for an obscure piece of code is to not to have that code at all, just refactor it until is a nice and readable piece of code.

7. Respect the best practices of the design pattern you choose.

Be sure to respect the common best practices. In example, if you choose the MVC design pattern:

• never write SQL queries in the views.
• write skinny controllers and ‘fat’ models.
• the entire application logic must be in the controllers.

8. Test, test, test.

The most tests you have, the better, they are our safety net for all the changes we will have to perform in the code in the future.

9. Refactor often and sooner.

Software development is a continuous discovery process, in order to keep up to date with good code that matches the new/changing requirements is essential to refactor the code as we go. As this is a risky task there are 2 main preconditions to avoid entering new bugs into the system.

10. Have code reviews.

We all make mistakes, and there’s nothing better than asking some other person to have a quick and informal review in our code to find them. In order to make the reviews, it’s better not to wait until the code is completed, ask for reviews whenever some important part of the code has been completed (or when a few days have passed from the previous review).

La migrazione è avvenuta senza troppi problemi: articoli, tag e persino i commenti sono stati preservati!

Il tema che ho scelto poi è veramente figo e personalizzabile! La parte del Curriculum vitae è ancora da sistemare e pulire, ma la cosa bella è che il contenuto viene preso direttamente dal mio profilo LinkedIn!!

Ora la ToDo list prevede di:

• Inserire le immagini in evidenza nei post vecchi
• Sistemare le Gist di GitHub
• Inserire un sistema anti-spam nei commenti

Here is the error that I found:

The solution for me is to install gcc-4.4 that can happily co exist with the gcc-4.6 one.

sudo apt-get install gcc-4.4 g++-4.4 libstdc++6-4.4-dev

after installing the passenger gem, run:

rvmsudo CC=gcc-4.4 passenger-install-nginx-module

And this is the command for the Passenger standalone:

CC=gcc-4.4 passenger start