Blog Surfer

Gears 0.2 is in the wild, in production
We have talked before about Google Gears 0.2. Now, it has been fully released and has been updated on users machines so you can rely on the APIs. The API changes include: New modules: HttpRequest and Timer. The main reason for these modules was that developers told us they wanted to make HTTP requests and create […]

We have talked before about Google Gears 0.2. Now, it has been fully released and has been updated on users machines so you can rely on the APIs. The API changes include:

• New modules: HttpRequest and Timer. The main reason for these modules was that developers told us they wanted to make HTTP requests and create timers inside Gears workers. But these modules can also be used outside of workers. For example, one advantage to using the Gears HttpRequest module instead of normal XMLHttpRequest is that Gears HttpRequest module addresses a common problem making comet-style applications work on IE.
• Improved support for handling errors in workers. This is an area where we received a lot of good feedback. Now, errors from workers are automatically bubbled up to the main page by default so that you can see them in the error console or in Firebug. Or, you can handle them explicitly with the new onerror event.
• Ability to load workers from a URL, even cross-domain URLs. We’ve long wanted the ability to load workers from a URL. We’ve also wanted to provide a way for different domains to communicate safely. This is useful in the case of mashups, or when an application spans multiple domains. The new createWorkerFromUrl API solves both these problems.

Now 0.2 is in production, the Gears team can look to 0.3 and items such as:

• Added initial Desktop module.
• Factory changes:
  • Added the hasPermission property.
  • Added the getPermission() method.
• LocalServer changes:
  • Added the oncomplete, onerror, and
    onprogress events to the
    ManagedResourceStore class.

And hopefully some really interesting items such as those that I have been chatting about.

What would you like to see?

DOMAssistant 2.6 Released
DOMAssistant 2.6 has been released and the team focused on performance for this version. They have their own version of slickspeed which includes their library. The CSS changes include: Where querySelectorAll and getElementsByClassName aren’t available, DOMAssistant resorts to XPath to select elements, which is an approach that also has very impressive performance results, not to mention native web […]

DOMAssistant 2.6 has been released and the team focused on performance for this version.

They have their own version of slickspeed which includes their library.

The CSS changes include:

Where querySelectorAll and getElementsByClassName aren’t available, DOMAssistant resorts to XPath to select elements, which is an approach that also has very impressive performance results, not to mention native web browser support. The only web browser not supporting XPath is Internet Explorer, where the only option is “regular” looping through elements.

The new version includes a new plugin architecture and an update of the magic methods:

The $ method

Accepts either a CSS selector or an object reference. E.g. $("#container .external-links"), $(document). Fails silently if you try to call a method when the selector didn’t return any matches; i.e., $("input[type=text]").addClass("text-fields") won’t throw an error trying to call the addClass method, even if the $ selector didn’t match any elements.

Returns: A collection of one or several nodes for CSS selectors/object reference when an object was sent in.

The $$ method

Accepts a string parameter, expected to be the id of an element. E.g. $$("container"), $$("navigation"). Will throw an error if you try to call a method, if there wasn’t any match.

Returns: A direct reference to the DOM element.

Bad Documentation is a Killer
Almost every developer has run into some bad documentation in their day. I can’t even remember how many times I’ve had to talk to a disgruntled tech support guy about an issue that should have been easy to find. Two of the companies I’ve worked with have even stopped using otherwise good software due to […]

Almost every developer has run into some bad documentation in their day. I can’t even remember how many times I’ve had to talk to a disgruntled tech support guy about an issue that should have been easy to find. Two of the companies I’ve worked with have even stopped using otherwise good software due to bad documentation.

The challenge with documentation is that most developers really have no desire to write it. For those of us working on the web, we’ve had it easy because documentation hasn’t been critical for many web projects. Most of my clients don’t need instructions on how to navigate their sites or use the basic admin tools I provide. However, things have been changing.

As websites and web-based tools have become more advanced, I’ve found myself working on more projects that require documentation. I’ve written documentation for external APIs and services, instructions for other developers on my team and tutorials for end-users. Most of my early attempts were unsuccessful and I ended up being the disgruntled support tech. To prevent this from happening to you; here are a few ideas to help make your documentation better and save you some time in the process.

Know Your Audience

Just like any other project, you need to know who you’re writing for. If you’re writing for tech-savvy end-users or other developers, you can usually cut out a certain amount of introductory content. Likewise, you don’t want to confuse average web surfers with details about how you handle complex data handling or memory allocation.

If you find that you have separate groups of users, don’t be afraid to write multiple sets of documentation. It may seem daunting at first, but in many cases writing shorter, more concise documents for specific user groups takes less time than trying to make everybody happy with one. A good example is CMS vendors, most of the them provide separate documentation for developers, IT admins and end-users.

Make use of Automated Tools

Most languages have systems in place for automating documentation to some extent. Usually these systems don’t create anything good enough for end-users, but the documentation is usually right on target for other developers. In most languages, the tools generate documentation based on comments in your code. Integrating them is just a matter of changing your commenting style to fit what the documentation generator is expecting. I actually found that this provided the added benefit of making me write more consistent comments.

Make Documentation a Community Effort

Some of the most useful references for programming include a group of people. A completely user driven system, like a wiki, or a documentation system like the MSDN Library that allows users to attach content to existing article can both increase the effectiveness of the documentation and reduce the amount of effort required to maintain it. Wikis are also a great tool to use internally for preparing documentation. As you’re developing, it’s easy to add quick notes to the wiki then compile the content into documentation at release time. Even if it’s a system that is only editable by employees, it provides a central reference for workarounds, bugs and common pitfalls.

Leave Time to Write Documentation

Most of the disasters I’ve seen are the result of rushing through the process. It’s tough to cut a feature or push back a deadline to make time for documentation, but it will be worth it. Whether you end up with a tech support nightmare or spending weeks trying to get new developers up to speed, you will regret not spending the time to write things down.

As web applications become more complex and web services and APIs become more wide spread, writing documentation is a skill that will become increasingly more important for developers. Hopefully these pointers will help you become a more effecient and effective documentation author.

This article provided by sitepoint.com.

Measuring the state of Mobile Ajax Performance
Reposted from Thesis: A thorough study on the state of Mobile Ajax Performance on devphone Mikko Pervilä has released a thesis for his MSci at the University of Helsinki titled Performance of Ajax Applications on Mobile Devices: This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and […]

Reposted from Thesis: A thorough study on the state of Mobile Ajax Performance on devphone

Mikko Pervilä has released a thesis for his MSci at the University of Helsinki titled Performance of Ajax Applications on Mobile Devices:

This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and Nokia models N95 and N800. Performance is benchmarked through user-experienced response times as measured with a stopwatch. 12 Ajax toolkit examples and 8 production-quality applications are targeted, all except one in their real environments. In total, over 1750 observations are analyzed and included in the appendix. Communication delays are not considered; the network connection type is WLAN.

Results indicate that the initial loading time of an Ajax application can often exceed 20 seconds. Content reordering may be used to partially overcome this limitation. Proper testing is the key for success: the selected browsers are capable of presenting Ajax applications if their differing implementations are overcome, perhaps using a suitable toolkit.

There is a large amount of detailed information here across several vectors.

Mobile device / platform differences

Mikko has gone into detailed testing on the Nokia 800, N95, and the iPhone. Within the N800 he tests Opera, Mozilla, and WebCore. On the N95 he tests Opera Mobile and the mini map interface.

Ajax libraries and their support

Here Mikko compared a large number of libraries:

• Prototype
• Script.aculo.us
• jQuery
• Yahoo! UI
• Dojo
• Ext JS
• Gears
• DWR
• MooTools
• moo.fx
• ASP.NET Ajax
• Frost Ajax library

Comparing large websites on mobile phones

Here Mikko runs up against properties such as:

• Gmail
• Google Maps
• Yahoo! Mail
• Flickr
• myAOL

You can look through the study to see the details, but what about conclusions?

One can not yet assume that applications sup-
ported by the desktop browsers would be consequently supported by the mobile
browsers. Browser fragmentation seems to flow over to the mobile devices
with the shared code bases of the mobile and desktop user agents.

If we take a look at the grouping of grades for the various tests, you see that the browsers in question are across the map. All of them have issues, across the board.

Mikko does have this to say about the browsers:

By far, the fastest browser is Opera Mobile on the N95. This seems to be well in line with the overall worst capability in the capability evaluations. This combination seems to be indicative of ignored program directives, meaning that the browser gains speed by not executing some parts of the application code. Safari’s high number (14) of slow results is caused by the browser’s distinctive performance variation, specifically of pairwise high and low values. This phenomena has not yet been satisfactorily explained.

The two things that strike me are:

• Mobile browsers are very different, and I hope they get closer (feels like a few years back with desktop browsers)
• There is room for a mobile specific toolkit (or a mobile piece of a current toolkit) to help out like they did in desktop land. Frost is an early library here.

As you go through the thesis you will see a great set of graphs that show you the performance characteristics of micro elements of the Ajax experience on the phone. Thanks for the work Mikko!

Other related news

• Mobile Comet: Got some server on your phone?
• Flash on the iPhone
• Small is beautiful on the iPhone if you want a good cache

YUI 2.5 released - Layout Manager, File Uploader and graphical JavaScript Profiler - and that is just the start
Version 2.5 of the Yahoo User Interface Library (YUI) was released today. You can get all the details on the official blog post, but here’s the “change log”: The new Layout Manager allows you to create multi-pane user interfaces that are collapsible and resizable. The Flash-enhanced File Uploader control might be known to you from Flickr and […]

Version 2.5 of the Yahoo User Interface Library (YUI) was released today. You can get all the details on the official blog post, but here’s the “change log”:

• The new Layout Manager allows you to create multi-pane user interfaces that are collapsible and resizable.
• The Flash-enhanced File Uploader control might be known to you from Flickr and and allows you to easily batch-upload files and images with progress bars.
• The JavaScript Profiler now has a graphical front-end to make the information more easily understandable
• The YUI Data Table performs faster and got new features, including horizontal and vertical scrolling, a paginator class, drag and drop columns and an API to access, add and remove columns.
• The Image Cropper control allows you to pick a part of an image to be cropped server-side
• The Cookie Controller provides a wrapper for all things to do with cookies
• The Slider Control got updated to support multiple handles to define a range rather than just a state.

In addition to that, some of the components left beta status. These are the Get Utility to retrieve scripts and style sheets on the fly, the ColorPicker Control, the JSON Utility to validate JSON, the ImageLoader Utility to load images on-demand to increase page performance and the YUI Test Utility.

The really detailed report on all the changes is available on the YUI list/forum.

If you want to have a quick glimpse of what the Layout Control allows you to create, check out the demo application interface simulating simulating Yahoo Mail.