Davide Scaramuzza: Flying robots
From swimming robots to flying robots! Davide was the man for us boys in the audience. Unlike our toystore helicopters, Davide's robots can fly without motion capture system or remote control. In order to navigate autonomously they need to know where they are, however, GPS is not used since it's not a reliable system. While it flies the helicopter constructs its own map of the environment. Several helicopters can fuse their maps. Besides all play, what's the real interest in autonomous flying robots? -They can be taken to environments where human beings cannot fly or flights would not be economic, e.g. search for survivors after an earth quake or do environmental monitoring using helicopter swarms. The great presentation was crowned by a live show (behind safety net).

If you are a developer it is almost certain that you had to refactor code at some point. Refactoring is no joy, especially if it is not your code and badly written.

The three code states

I like to think that the code we write can have three states:

• stable code: code that is subject to almost no changes, and at the same time permits to easily add new functionality.
• code to be refactored: this is the code that we are working on, or it is marked with @todo and a comment regarding why and what should be refactored.
• bad code: code that should be refactored, but nobody is aware of it - at least not yet... You will only notice when the client reports a bug or a feature request that cannot be implemented without changes in that portion of code.

Managing @todos

This does not give a clue what the code does now or why the code should be changed. You should always point out the reason why the code needs to be refactored.

 

 

Refactoring

Then, when the time comes to actually refactor the code, the question is: How do you refactor? It depends on the code that has to be refactored, but most of the time it involves moving code into a separate function, changing the structure of a classes tree or moving the implementation from a function oriented to an object oriented approach.

Finally, you have to check if your refactored code really works. Because you refactored the code, this does not mean that you fixed the bugs. You could even have introduced new ones. So to ensure this didn't happen, the best thing is  to have automated tests that you run on your code, which is not always a trivial task to do.

 

The five conclusions

1. If possible, try to avoid having many @todos in your code, especially in the one that goes to production.
2. Always write good documentation for what you have to refactor. It would be good to specify why the code has to be refactored, the priority and optionally why you've chosen not to refactor yet. 
3. Refactor the code as soon as possible. Ideally is in the development stage.
4. Always test the new code. If you refactor it, it does not mean that that code is correct.
5. Avoid writing code you know that you will have refactore it in the future.

If you are looking for a more general blog post on code refactoring you should take a look at SourceMaking's "Introduction to Refactoring".

A few hours ago, the Drupal Security Team informed about a highly critical Drupal 7 core issue: http://drupal.org/node/1815912

The vulnerability allows an attacker to reinstall an existing Drupal site with an external database server and then execute custom PHP code on the web server.

As usual, to mitigate a highly critical vulnerability, a new Drupal 7 version (7.16) was released which fixes this issue. Since it is not always possible to update or patch every customer website immediately there is an accepted workaround for this: Deny access to install.php.

Add this to .htaccess the file:

This will prevent everybody from accessing install.php and rule out that an attacker can use it for an attack.

But overall it is best to update Drupal as fast as possible and also deny write access for settings.php as described in the Drupal security best practices.

You can deny the access to install.php by using this patch and applying it with: "patch < SA-CORE-2012-003_deny_access_install_php.patch"

Here comes the traditional collection of stories that caught our weekly attention. Enjoy!

Drupal

Drupal Association: Election Results
This week the results for the community election to choose two at-large Directors for the board of the Drupal Association were announced. Congratulations to Morten Birch Heide-Jørgensen and Pedro Cambra!

Social Media

Beevolve: An Exhaustive Study of Twitter Users Across the World
Beevolve, a provider of a Social Media Monitoring platform shares some statistics of its mined data.

AllThingsD: Very Pinteresting! Facebook Cranks Up Another (Potential) Revenue Stream With “Collections.”
Remember the times when every Facebook update included many Twitteresque features? Now the world largest social network turns its attention to Pinterest.

Food for thought

Wired: Fend Off Trolls, Bots and Jerks With ‘Empathy’ Test
CAPTCHAs can be annoying. Why not use that opportunity to stand up for human rights.

Tweets that cut through the noise

News organizations falling over themselves to offer apps seems a little like when everyone wanted a Flash intro page to their '98 website.

— DHH (@dhh) October 8, 2012