In the 256’th day we celebrate programmer’s day, so for all those concerned: Happy programmer’s day!

Packt Publishing launched Open Source Awards 2010.

This Open Source award is an online event held by Packt to distinguish excellence among the various projects within the community.

This is a great opportunity to vote for your favorite Open Source software. The main categories are:

• Open Source CMS Award
• Hall of Fame CMS
• Most Promising Open Source Project
• Open Source E-Commerce Applications
• Open Source JavaScript Libraries
• Open Source Graphics Software

You can nominate until November 6! After that voting will take place.

This is a good opportunity to show your gratitude to your favorite open-source software!

So go to Packt Publishing – Open Source Awards 2010 and play your part!

When it comes to Android and PHP a lot has been written about PHP for Android.

The concept is simple, Google launched Android Scripting Environment (ASE).

ASE is as the name suggests, a scripting environment, and the apps are not compiled and they can be modified at all times by the user.

Over ASE there are extensions installed for different languages like: Python, LUA, Perl, JavaScript or JRuby.

Unfortunately there isn’t official support for PHP from Google, but there is PHP for Android, project which allows the integration between PHP CLI and this environment.

The installation is very simple and is done directly on the phone. For development Android SDK simulator can be used.

One of the issues is that the app can’t be packed as an APK, so it can’t be posted on Android Market.

Basically this was the only issue raised so far everywhere, issue that doesn’t seem exactly big considering the facilities available in this environment.

I’ve searched for apps build with PFA, I’ve found only a few, actually I found only a few even in other languages using ASE. Why aren’t the users eager to develop in this environment? Simple, using the scripting environment you can access a lot of facilities of available on the phone, like vibrating for instance and about all the available dialogs. But there is an essential feature which is totally lacking (or at least at the time this blog is written), there isn’t a graphical interface, like any kind of window that isn’t a dialog.

So what is the purpose of adding an app to Android Market if there is no graphic interface? I don’t believe there is almost no real consistent reason at this point.

But what are the developers doing in this environment then? Well Cellbots for instance.Basically you can do some interesting toys, but don’t expect to do real apps (yet). Another project it was sending a NexusOne into space.

So the project is interesting, but I don’t think it has the purpose of developing traditional apps just yet.

Recently I’ve changed my “old” HTC Diamond running Windows Mobile 6.1 with an HTC Desire running Android 2.1.

Why Desire? Mainly for Android. There are 3 platforms out there which deserve attention:  iPhone, Android and Windows Mobile. There is Blackberry two, but I’m not a big fan.

Briefly, I’ve chosen  Android for the multitude of ways in which you can write an app.

The native language for Android is Java, but for web developers there are alternatives like: Titanium, Phonegap, PHP for Android or Adobe AIR.

I what to explore these alternative technologies to see what and how easy is to develop whit each one of them.

All I can say at the moment is that my first app took me almost 2 days to build, but the result is interesting.

There are whole books about optimization, but few mention when is the right moment for the optimization to take place.

There are several perspectives with fundamental differences:

• during development
• at the end of the development cycle
• never

What is the correct answer? In fact there are only less correct or inadequate.

During development

This answer has the most potential to be wrong.

Even though is the most common method and it shouldn’t be interpreted as being wrong, it has the potential to cause issues.

When it may cause issues? When instead of optimization, micro-optimization is used in excess.

Micro-optimization can come in many shapes, depending on how the project is developed. Some write “bulk” code or procedural code, others use frameworks and ORMs. When your deviating from the general rule of writing code to do optimization you should think about the consequences. It will be harder for the next guy that looks at your code to understand what’s going on, and if you make a rule out of that, with time the project will become indecipherable.

For instance if your using ORM and you start typing SQL you are already losing the purpose of the ORM. In ROM there are several steps for each interrogation:

Building the objectual interrogation -> Parse to SQL -> Execute interrogation -> Parse result -> Loading the resulting objects

vs.

Building the SQL interrogation -> Execute interrogation -> Parse result

The steps may varies depending on the implementation.

A lot of the times the second approach looks simpler and is faster for sure. But why use the first approach? For the architectural advantages! You can set triggers when accessing or setting the properties for instance.

A mature developer is the one that writes “readable” code, not just optimum.

At the end of the developing cycle

The advantage is that there are no architectural compromises during development.

This is usual the best method, because you have the finished product, developed without compromise and you can see which points should be optimized. When you have all the components is much simpler to reorganize them then during the development when changes may appear, which in turn can generate for instance code redundancy.

The disadvantage is that at the end is sometimes difficult to find the week points of the application.

Never

First of all let’s make it clear, I mean “serious” projects.

There is a general rule that’s saying “hardware is cheap, programmers are expensive”. More broadly this means that a lot of the times is easier to scale an application using hardware then doing major compromises in the code.

A lot of companies and projects support this perspective. Correctly applied this principle has the advantage of having a well organized code, easy to read and with few hacks.

The advantage is at development, few hacks make a project more organized (in theory) and easier to extend.

Unfortunately looks like there is also a different interpretation: “if must work, it doesn’t have to be perfect”. Where can this lead to? Basically is the best excuse for dirty code.

The major difference is that you never optimize, and the code will look just as bad as when you do excessive micro-optimization.

Conclusion

In general, project that use excessively micro-optimization, have a great potential to be often rewritten, either partially of full, because there is another rule that says “rather then repair, a lot of the times is easier to rewrite”. Unfortunately projects with bad written code suffer the same fate.

A major disadvantage to bad code is that it slows the development cycle, in other words minor tasks tend to last longer and longer to be accomplished.

Projects don’t have to be always optimized. But when we have to do that, compromises regarding the architecture must be at minimum.