But you never truly know how good a tool will be until you try it. In the last few days I have used Bootstrap for two small projects – one internal project at SiteHost where I work, and then again today when I built a webpage for my mothers shop in a couple of hours: www.chandelle.co.nz.

I have to say I am impressed and will be using Bootstrap again for sure. It does for CSS layouts what jQuery does for JavaScript – streamlined, elegant, and so easy to use. Highly recommended.

[fixed] In large PHP files (over 2000 lines) code parsing was very slow.
[fixed] Built-In PHP executables crashed on Warning or Error during local run/debug.
[fixed] JavaScript Validator threw Java Null Pointer Exception.
[fixed] Error "Unsupported Content Type" occurred when opening a PHP file from the SVN Repositories or CVS Repositories view.
[fixed] Using the keyboard shortcut Toggle Breakpoint (Ctrl+Shift+B) resulted in a breakpoint of a wrong type (JS instead of PHP). NB: the fix will work only after workspace reset.
[fixed] Hyperlinks in tooltips were not working.
[fixed] Code Formatter used to remove the leading backslash in namespaced paths.
[fixed] When opening the Project Properties through the main menu (Project | Properties) the Remote Server Support page was not available.
[fixed] Refactor/Rename keyboard shortcut (Shift+Alt+R) was not working due to a conflict.

[improvement] Remote Server Support does not perform full re-scan of the remote resources, unless necessary.
[improvement] The Remote Search page has been removed from the Search dialog, because this functionality does not exist.
[improvement] Added keyboard shortcuts for file upload/download in Remote Server Support (Shift+Alt+P,U and Shift+Alt+P,D).
[improvement] PHP 5.3 is the new workspace default.

[update] Zend Framework Example Project (Guestbook) has been updated to the latest version from the Zend Framework project site.

Use Alias Shortcuts

The 'alias' command allows you to create an alias, or shortcut, to a longer command. For example you could create a shortcut to open TextEdit from the command line like so:

• Open the Terminal app
• Type  the following: 
  
alias te='open /Applications/TextEdit.app/'

• Press Enter
• Now type "te". TextEdit should open

So how can we use the alias command to replace the convenience of PuTTY and log into servers easily?

We can create shortcuts for servers that we frequently log into. For example in the Terminal type the following:

Where:

• myserver = the name of your alias/shortcut
• username = a valid user on the server
• xxx.xxx.xxx.xxx = the server IP address

Now you can ssh to that server by simply typing "myserver". This should prompt you for your password – enter that and you're in!

Use .bash_profile to save aliases

At the moment if you close your Terminal, and then re-open it, your aliases will have been forgotten. So how do we tell Terminal to remember them permanently? The trick is to create a .bash_profile file for your Mac user. This file should exist in your Mac home directory. To create this file follow these steps:

• Open the Terminal app
• Type the following:
  
vi ~/.bash_profile

• This will open a new blank file in the "vi" editor
• Press "i" once – this puts the editor into "insert" mode
• Put your alias command into the file (same as above) – paste using Ctrl+V, or type it
• Press the Esc key once
• Type ":wq" to finish editing the file and save it to disk
• Now close your Terminal app, and reopen it. Your alias should now be working.

Note: If you have TextMate installed (which I highly recommend) then at the command line just type "mate ~/.bash_profile" (instead of using "vi"). This will open a blank file in TextMate. Then type in the alias command as above and save the file. Then close and reopen the Terminal app.

This was just a quick overview for those who can work out the details from the clues above. Even if you do not use aliases to shortcut logging in to servers they are handy to know about.

Happy aliasing!

As a result of collaberation between Ext JS and Adobe, several impressive enhancements to the Ext.air package were just released. These enhancements allow even better control of AIR and the desktop via easy to use JavaScript calls.

For example to play a music file:

Or to tell your application to launch on system startup:

Additional enhancements allow you to easily control desktop windowing, video, system notifications and alerts and even the clipboard.

You can learn more about Ext JS here.
You can learn more about Adobe AIR here.

If you have not been challenged by this behaviour yet, don't worry – you will! And when you do, here is the solution.

Instead of the typical "print()" command in JavaScript, use:

Or if you are wanting to print a document inside an iFrame you can use something like:

Note: This solution is for Internet Explorer 7 only – I leave it up to you to do the browser detection.

It turns out that we do not need the Zend Platform at all. As part of the PDT Eclipse project Zend has made available a standalone version of their debugger. This can be downloaded from here: http://downloads.zend.com/pdt/server-debugger/

Then you just need to put the .so or .dll file in the correct location and add a few lines to your PHP.INI file and you are away. Here are the lines I had to add to my PHP.INI, which is running inside a Debian VMWare image. Note the commas separating the IP numbers – this took me a few goes to work out as the examples showed spaces or forward-slashes which didn't work for me.

Why did Zend make this so hard to work out? Reading on different blogs and through the Zend forums highlights that this issue has been a source of frustration for many developers. Grrrr…

What problem does it solve?

Web developers write software for … the web. For applications that run via a browser that is connected to the Internet. Google Gears will take web applications to the desktop – enabling Web applications to work offline. A user will not be required to be connected to the Internet to use the application.

How does it work?

First of all web applications will need to detect whether or not Google Gears is installed on a user's machine. If Gears is installed, then the application will be able to access the Google Gears APIs from JavaScript code. If Gears isn't installed, the user can be directed to a customized installation page.

The APIs can then be used to access Google Gears three core features:

• A local server, to cache and serve application resources (HTML, JavaScript, images, etc.) without needing to contact a server.
• A SQLite database, to store and access data from within the browser.The Database module is used to persistently store an application user's data on the user's computer. Data is stored using the same-origin security policy, meaning that a web application cannot access data outside of its domain. Standard SQL can be used to access the data, and full-text indexing is supported using SQLite's fts2 extension.
• A worker thread pool, to make web applications more responsive by performing expensive operations in the background. In web browsers a single time-intensive operation, such as I/O or heavy computation, can make the UI unresponsive. The WorkerPool module runs operations in the background, without blocking the UI.

What browsers are supported?

The final release will run on the following browsers:

• Apple Mac OS X (10.2 or higher)
  • Firefox 1.5 or higher
  • Safari
• Linux
  • Firefox 1.5 or higher
• Microsoft Windows (XP or higher)
  • Firefox 1.5 or higher
  • Internet Explorer 6 or higher

What next?

To find out more about this project you can visit the Google Gears website. From there you can download Gears and then install some of the sample applications available.

Some developers are already playing with Google Gears and sharing their experience and their plans. For example you can listen to a podcast about Dojo Offline being ported to Google Gears, or take a look at RSS Bling moving to Google Gears.

This is definitely a project to watch. With Google obviously coordinating with the efforts of popular projects such as Dojo, as well as supporting all the major browsers, there are some interesting possibilities opening up for web applications.

Linus Upson, the engineering director at Google, stated that the goal of Google Gears is to "create a single, standardized way to add offline capabilities to Web applications." Google is certainly on the right track … I'm off to have a play!

• HTML
• Excel
• XML
• CSV
• SQL

There is an online demo available that is limited to 200 results. Click here to find out more…

With the next generation of Web Applications upon us the challenges faced by the average web developer have broadened. Understanding and confronting issues like memory leaks, bandwidth, load times and JavaScript processing time is becoming more of an everyday focus for web developers than ever before.

Fortunately we now have the tools available to help. On the developers machine the Web Developer Toolbar and Firebug for example are essential. And within the applications themselves we find increased usage of JavaScript libraries such as Dojo, jQuery, Prototype, YUI and widget frameworks like Ext, which provide a layer of abstraction and freedom for developers from some of these issues.

The increased usage of JavaScript however brings other challenges. Particularly in the world of Web Applications where the use of Widgets (tabs, grids, menus etc) is more likely, it is not uncommon for the volume of JavaScript and CSS to quickly accumulate from tens to a few hundred kb of code. This is a far cry from ideal, but is also to a certain extent unavoidable if that is the type of application you are supporting.

What can a developer do to minimise this issue? There are several very effective methods that can be explored:

Compacting Your Code
This is acheived by stripping out comments and unneccesary white-space which can drastically reduce the size of your files – sometimes cutting them in half. Recommended tools: Dean Edwards Packer or Douglas Crockford's JSMin. You could apply the same theory to your CSS as well.

File Compression
Using GZIP or Deflate can drastically reduce the downloaded file size (but should be used wisely). You can read more on this here.

Combining Multiple Files
In general browsers download only two or four files in parallel per hostname, depending on the HTTP version of the response and the user’s browser. On top of that it seems that JavaScript files are loaded synchronously and sequentially as they appear in your code. This means that only one JavaScript file can be downloaded at a time – and each file must be completely downloaded and then interpreted before the next download can begin. Reducing the number of HTTP requests by combining your JavaScript and CSS files into single files will definitely help improve your applications response times. Using CSS Sprites to combine your images into a single file and re-use with CSS is also an extension of this principle and is a very effective technique.

Caching
Server-side caching can help speed the up the delivery of page content. Also understanding browser caching and how to control this using file headers can make a difference – but again should be used wisely.

These techniques have been around for quite a while now. But this leads me to the real point of this post!

"Injection" Introduced

When it comes to the world of Web Applications (as opposed to a "website") where the use of Iframes is more likely, there is another technique that can be explored – "Code Injection".

I became aware of this technique while trying to interpret some very lengthy posts from Choleriker on the Ext forums. I thank Choleriker for taking the time to explain the concepts. I thought I would share my interpretation of this technique, as well as provide some examples to see it in action as requested by other developers in the forums.

First of all – what is this "code injection" that I am referring to?

Explained
In breif, the technique basically involves loading your JavaScript and CSS only once and then re-using it inside any iframes without downloading it again. This is acheived by loading your code "inline" inside the top level page of the application. The top page then makes the JavaScript and CSS available as two variables that can be called from the iframes directly. So the code is passed or "injected" from the top level page into any iframes using JavaScript.

Benefits?
There are several benefits to this technique – the most obvious being that you only download your JavaScript and CSS once, no additional downloads required. If you normally compress your JavaScript files using GZIP you likely know that there is a performance hit in the client browser to decompress the code before it can be used. This is no longer an issue for the reused code. And there is no longer any concerns with browser caching issues. Another big plus is that the CSS and JavaScript is being loaded as part of your actual page – i.e. there are no other additional files to download, which will improve the response times as described above.

Downsides?
I guess that the technique requires iframes. In time I guess/hope the principles of the technique may be able to be used in other perhaps more elegant ways that I haven't thought of yet. Another downside is the need to load your JavaScript and CSS inline. This was initially repugnant to me, mainly due to my background in website development. But in an Application is it really a big deal? I have decided it does not outweight the benefits.

Another perceived downside is that you have to get all of your JavaScript and CSS into a format that is loaded inline – but of course you still want to work with your separate "clean" files as you are used to. This should be viewed as an opportunity! It is likely time to implement a number of techniques as discussed above. My recommended technique is to have a server-side script that does the following:

• Combines the required JavaScript and CSS files
• Compacts the code by stripped white-space, comments etc
• Caches the output code to a file on the server
• Include the code inline using PHP or some other scripting language

I may provide some code for doing this in PHP in the future. In the meantime you might want to look at the "Combine" script from Niels Leenheer to get started.

Sample Application
So – how about an example? Click on the image below to see this technique in action. The example is built using Ext 1.0 Beta 2. It is a top level page which generates an Ext Layout with panels. The right-hand panel contains an iframe which receives the JavaScript and CSS from the top level page – it has not downloaded any files except the required images.

The secret to this working is the following code in the Top Page:

A look at the files downloaded reveals the benefits – the iframe had nothing to download but the basic page itself. The JavaScript and CSS were downloaded only once as part of the top page. This top page was a reasonable size – but Ext is not small, and we can see the GZIP compression kicking in:

Conclusion
So – should you use this technique? That depends on your application and your preference. The objective of this post was to simply introduce a concept that was new to me, and I am sure is new to many others. It is simply another technique to add to a developers toolbox.

PS: I am very interested what other developers think of this technique and what they perceive as the advantages and disadvantages. I also have a question – does this technique expose any security holes I should be aware of?

Stefan Esser’s, widely regarded as an authority on PHP security issues, plans to make daily disclosures on buffer overflows, double free vulnerabilities and trivial bypass bugs in PHP’s protection features as part of a wider goal “to make people and especially the PHP developers aware that bugs in PHP exist.”

Some of these bugs have already been addressed in PHP 5.2.1. Others are fixed by the Suhosin patches and extensions from Stefan Esser, which are freely downloadable here. Others hopefully will be addressed in the very near future by the PHP development team.

To find out more about this initiative visit the PHP Security website.