Passwords are the new era plague. They are everywhere. Every system relies on passwords. People, unfortunately, are not designed to memorize all of them. The most common solution? Use one password for everything. If you ask one to create a password, one will use the very same password.

Passwords have some intrinsic problems:

• difficult to create
• difficult to remember
• spread across several systems

Jeff Atwood wrote about the advantages of passphrases over passwords, but I’m still not convinced that it correctly addresses the problem. Using more robust brute force techniques, it will be, in fact, easier to break it, even if has several digits.

But when the person uses the same password over and over, there are some extra problems:

• cross site vulnerability when one is hacked

Some use password wallets; programs that stores all your passwords in one place. However, you are putting all the eggs in a single basket. If this program gets hacked, all your passwords are exposed. Also, you have to keep a record of all sites you use, which facilitates even more the job a malicious hacker.

PasswordMaker

Suddenly I found about PasswordMaker on the FLOSS Weekly 84 on Twit, which opened my mind for a nice solution. The idea is to create a password generator using a central password combined with a unique id for each site, which can be its actual address! So, your job relies only on remembering one single password, and it will recalculate the actual password each time. One password to rule them all.

It solves some problems.

complex password generation

It can automatically generate very, very, very strong passwords using a several possible characters. the default 8 digits and 99 characters possible, generate 1 password in 9 227 446 944 279 201, much better than 110 075 314 176 passwords possible using a simple lowercase letters only. I personally use very long passwords. Configuring it to create a 20 digits password, it will be one in 8 179 069 375 972 310 000 000 000 000 000 000 000 000! much safer!

cross site safety

If Facebook is hacked, your Gmail account wont be compromised. If Flickr is invaded, your bank account will still be intact. Because each site uses a different password, you will be protected on all the others. And believe me, it’s site invasion and password leakage very common.

multiple profiles

Some sites have different password policies. Some require using letters and numers, some forbids special characters. Some require at least 8 digits, others restrict to 20. Using thie tool, you can change easily the different profiles and generate, each time, a password for each situation.

browser extensions

In their site, there are several plugins for all major browsers. They facilitates a lot the tool usage. I personally created a Chrome extension that uses the same algorithm. I hope people like it.

no central repository

Nothing is stored in the computer nor the internet. You don’t have to keep track which sites you have accounts. It still require non-software measures to make it work. You have to change your password in a regular basis (yearly maybe), among other atitutes. It is not a silver bullet solution, but it addresses several problems.

just saw the news about the Drupal 7 Release Candidate. I could not be more perplex with the length of its cycle. The code freeze was announced in September 15, 2009, so its more than a year!

I’m perplex mostly because of the nature of this software: an internet application. Because the internet environment changes in an incredible pace, its really counterproductive to stop accepting deep modifications for so long time. NoSQL databases are getting more and more used, JavaScript techniques getting more refined and the whole HTML5/Video is dominating news. Two years to launch a new version is quite a lot.

I have a hunch: Drupal 5 was a true revolution but had a quite short life cycle, coz Drupal 6 was released soon after. I believe several developers got pissed with that as they were forced to make a long conversion process from Drupal 4 to 5 and than from 5 to 6. Drupal 6 took quite some time to actually be used by old sites, because several important modules (Views and CCK mainly) delayed the port to see what direction D7 would take. The result is that Drupal 6 was coined “Drupal Vista: wait for the 7”. This might be forced Drupal core guys to extend the cycle.

The whole problem is now gone since most sites are now ported to D6. But I really believe that was not matter of the short-cycles-that-pressure-developers, but the lack of clear support from project managers. I say that because some even more complex programs are getting big supporters, despite the apparent paradox.

The most enlightening example is Google. Google’s most popular softwares adopted the strategy of the “fast iterations”. The idea is not to aim “quality at all cost” (typical for projects that release when it is ready) but “to fix as soon as possible”. Chrome is 3 years old or so and it is in version 9! The adoption rate is even bigger than Firefox! Android is in version 2.2 already and gaining more and more support of developers. Can you imagine a more complex software with a faster release cycle?

Faster cycles have several advantages:

• Gain easy testers with the early adopters
• Avoid that small enhancements being postponed for years just because is a “new feature”
• Avoid the proliferation of hacks-as-plugins that implement the small enhancements I just mentioned
• Revert wrong decisions often
• Encourage more people to participate to the core development, since their suggestions might be implemented soon after
• Avoid analysis-paralysis loop of each change
• Reduces the possibility of forks (what is the advantage of Pressflow if Drupal 7 was released quite after?)

I think Drupal community still is somewhere between The Cathedral and the Bazaar. They are still in CVS mentality of a centralized control and serialized development of features. We have to make features in parallel, not in series. So no more “feature freeze”, “guys, lets think about the next version… ideas?”. Every time is time to release a new features. It has to create several forks (and not only patches) that will work on each features and, when any of them are ready, commit into mainstream and launch as a new small version, like 7.1, 7.2, 7.3…

One last comment for those that think several people want stability over cutting edge stuff. It’s just to maintain a similar concept used by Ubuntu: time to time a given release will be considered “long term support”. And if Drupal 7.2 is LTS, for example, it could be released several other “features-releases” like 7.3, 7.4 and several “bug-releases” for 7.2, like 7.2.1, 7.2.2, 7.2.3… Fixed time support also gives business and people the right information for a proper planning.

We prices of hardware are getting cheaper and cheaper. If we werent using legacy computers, the whole world could be buying massive amounts of power.

General processors (cpu) and specialized processors (video cards) are really powerful and affordable. We now can create a super fast computer with a fraction of the price of a few years ago. A HUGE potential is simply wasted. Except for gaming, video creation and some other situations, a person will not use it at full power 99% of the time.

Both permanent storage (hard drive disks) and non permanent (RAM) are also very affordable. A terabyte HHD is cheaper than two 500 GB, which are cheaper than 4 of 250 GB. The current inflexion point is around 1.5 TB, but is progressing.

With so resources available, good programs are getting less and less relevant. Algorithms are for people who don’t know how to buy computers.

We are now focusing on extract the most of our bottlenecks. Power consumption, wired and wireless connections speed are probably the biggest ones. We still are about to see a ground breaking technology to deal with these. Meanwhile, solutions like cache and problems like lack of synchronization between devices will persist.

Started recently to play with Unity 3D, an IDE/Platform to develop games. I’ve heard about it because they recently decided that the indie version to be free. And because this version is quite similar to the Pro version and the Pro version is affordable, I decided to give it a try.

I am really impressed with the package. It is solid in features but what impressed me most is the easy user interface. Generally, programs that strive to be easy to use also make things too restrictive. Unity 3D is not one of them. It is a super intuitive IDE but also can be changed through code.

As I discussed before, the competition of engines should be irrelevant to game makers because we have a lot of data demonstrating that while the technology might help, the actual implementation is what matters. Good games with old/bad engines and Bad games with state-of-the-art engines are quite common.

The main reason to choose one is� current knowledge. Learning things all over again is costly, and Unity address this by adopting several standard technologies. For scripting, you can use C# (very close to Java and C++), JavaScript or Boo. For 3D models, it imports the most used formats (3DS, Max, Ma, Blender�). The same goes for 2D (which also includes importing Photoshop native files), sound and music. All that means that your workflow and suite of programs will remain basically the same.

With the indie version being free, a huge increase of documentation and community support is expected. The same for professional assistance. I’m happy to move from Torque (which uses several conceptual dogmas that I’ve never liked) to Unity.

PS: with the web player, its possible to create games for web pages just like Flash� take a look in the demos.

After creating several sites using several CMSes, one single thing still annoys me: the lack of a proper export settings feature. Putting a local testing site in the official online server is always a nightmare, since we have basically try one of the options:

• Copy the whole database: it also copies several testing data we used.
• Step-by-step replication: After 3 days, you will still discovery several options that were not copied
• Manually select DB table-by-table to copy: unless you really know of are you doing, its quite crazy

In Drupal world, one of my most admired companies, Development Seed, created both Features�and Strong Arm�that try to address this, but the lack of broad and ubiquitous support we still feel that we will miss something.

There are 3 types of data that a computer program might have:

• External: the spreadsheet for Excel, html to a browser, the image for Photoshop� its the reason why the program exists.
• Internal: the data that makes the program works. It’s the settings.
• Temporary: stuff that the program creates in order to gain performance. It, by definition, don’t need to be backed up because the program can recreate everything

Every program that is a platform should provide a Settings API. It would help on 4 big scenarios

Local / Production

There are several situations that we need to maintain a testing site for development new features without testing in the real production site. But time to time, we are satisfied with the test results and we and to apply the modification into the production site. For some business, like 3rd party site development, its the daily job, so its a must to make this workflow faster and painless.

Debug

After installing several plugins, its each to get a very unstable site, because they are changing same data. It would be much easier to monitor modifications and find solutions. A settings comparison tool would be great, so we could see what were overwritten.

Distribution / Template

Platforms, by definition, allow us to build stuff over it. But quite often projects are similar. So why not create a template for other people to use it? For a site builder like Drupal, we could create eCommerce, Blog, Forum templates for an easy deployment. It’s an extraordinary feature for newcomers.

Stack

If the program is settings aware, a good extra feature is to apply in a stack. It’s a similar concept of CSS, cascading settings based on specific variables. Imagine, for example, a site about football teams. While the site has a main theme, each team’s page can have one and the users can have a personal one. We could enabled this cascaded settings for each setting.

Multidimensional settings

If we have different content types in a site (ex: static pages, forum pages and news pages), we could have a page to change all settings related to each content type and have a page to change a specific setting of all content types.

As we can see, settings is a very important part in a program. We have to think it with more care to leverage its potentials.