I got some spare time, so I decided to give TPTP a try. After all I was thinking about it for some months.
I got the chance to apply TPTP to an applet I’m working to. The applet’s main task is to upload a set of file to a remote server giving the user some useful feedbacks, mainly including a nice interface that represent the upload process and a log window. Here you can see some screenshots to have an idea.

So, the first rule of optimization is usually to discover which is the section of code that behaves badly, that provides the worst performances. I run TPTP and I obtained the following report.

Performances of FileApplet before any optimization took place.

Quite surprisingly the worst performance is from the writeLog() method. This is a private method invoked inside a org.apache.commons.logging.Log implementation that implements an Observable/Observer pattern. This pattern is used to allow the user interface to receive notifications when the log is written. Apart of any technical consideration, the bad things here is that the performances of the code that manages the log system has the main responsibility of making the application run slower! This is absolutely a nonsense, since logging is not the application core business and the user does not want to trade performances for log capabilities, definitely!

So, I tried to discover how to improve the performances of this method, and I stumbled on ByteArrayOutputStream . This is a class from Apache Commons IO that provides the same interface of the classic java.io implementation. The project already included the apache commons IO jar, so it was really easy to change the dependency. I also made some minor fixes in the class.

So, I applied the second rule of optimization. Remove the bottleneck and measure the improvements, to understand if the update was worthwhile. I run again the TPTP an I obtained the following situation.

The performances of the bottleneck have increased considerably. Afterward the writeLog() method lasted for ≈14% of the total run time, against a smaller ≈10%. Then I though about the reason why the method writeLog() was invoked even when the user did not visualize the log panel. What stroke me was that I never though about it, and I used the Observable/Observer pattern only to set the link between the interface and the log system. So I refactored the code to make the log interface start observing the log only when the user press the log button, and, obviously, it stops observing the log when the user leaves the log view. This makes the code a little more trickier, but removed completely the main source of poor performances. Any doubt ? Here’s the TPTP report obtained after the refactoring.

File Applet performances after bottleneck has completely removed.

So, we can quite unsurprisingly conclude that the better improvement in performances comes from not using at all the bottleneck methods (at least when it is not strictly needed).

I just terminated a short stint in a project with the goal of produce an iPhone application that gives access to the services provided by an hospital. The app had a lot of forms and, since all the development team considered quite painful the form management in iPhone application, we came out with a sort of framework to manage form backed by an UITableView.

The framework should be considered a very early release and since we extracted it from a working application it is currently not fully generalized.

Here’s a video that show the basic features of the framework including:

• prex / next buttons;
• backed by UITableView;
• prebuilt fileds: plain, password, dates, credit cart expiration;
• customizable by provided implementation, as show in the “numeric lock” field.

If you’d like to evaluate if FormFramework can be useful for you, just give a look at the following short video showing how to include the framework in a new iPhone app.

The project is available at https://github.com/danidemi/FormFramework . Just give me a feedback if you think it can be useful or if you’d like to join the project.

This is a quick SVN reference I update regularly, with the commands I use more. I hope you’ll find it useful.

Task: Browse a remote repository

Task: create a directory on a remote repository

Task: import a directory

Task: check out

If you installed a MantisBT instance on a system with a recent PHP version, there’s the chance you get a warning saying:

SYSTEM WARNING: date_default_timezone_get(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Europe/Berlin’ for ‘CET/1.0/no DST’ instead

A quick way to get rid of this is to set an explicit time zone.

Just open the config_inc.php file and add the date_default_timezone_set() line.

Please refer to this list to discover the available time zones.