The Titanium open-source platform lets Web developers leverage their Web skills for creating desktop applications.

Titanium is an open-source platform that enables developers to build rich desktop applications using standard Web technologies. Titanium applications run natively on inux, Mac OS X and Windows operating systems. At a high level, Titanium competes directly with Adobe AIR, although it differs from AIR in three major ways. First, Titanium is open source; it’s licensed under the Apache Public License (version 2). Second, Titanium is fully extensible; Titanium extensions can be written using a number of popular languages, including C++, JavaScript, Ruby and Python. Finally, Titanium opens up user interface programming to popular languages like Ruby and Python— a job typically reserved only for JavaScript. Both Ruby and Python have full access to the Document Object Model (DOM), which puts these languages on par with JavaScript for building rich, dynamic user interfaces. It is important to note that Titanium is not a system that provides a point-and-click ability to build a single application that runs both on the Web and on the desktop; however, that is not to say code sharing across the Web interface and desktop interface is impossible. Some developers may choose to develop with a share-andsegregate pattern: write a common set of shared libraries, then write platform-specific code for use in a Web interface and other code for use in a desktop interface. In this case, you’ll still have a single codebase, but you’ll end up with two different apps. Other developers may choose to develop using progressive enhancement. With progressive enhancement, you start by implementing a basic set of features, then as new resources become available, you build up functionality to make use of these new resources.

A good example is Google Docs. There’s a basic set of features you can access on-line, but if you install Google Gears, you get off-line access and other features as well. The same goes for Titanium apps. Developers can enhance their Web applications progressively by adding features and functions that will be available only when the app is run on a Titanium instance. Using this approach you have just a single app. Both of these techniques are valid choices when it comes to developing apps. Both techniques have pros and cons, and it’s up to you as the developer to choose which method to use. No matter which technique you choose—two separate codebases, one codebase and two apps, or one app—at the very least, Titanium allows you to leverage your Web development knowledge to build desktop applications. It lets you use HTML and JavaScript, as well as other languages most often associated with Web development, to develop desktop applications.

No More Limits on Web Development
Titanium is a development platform with one clear goal: leverage Web technologies to create rich, cross-platform desktop applications. Using Titanium, you can create desktop applications using HTML and JavaScript, yet still get features not available on browser applications. For example, Titanium Web applications built for the desktop can access the filesystem and interact with the underlying operating system. The idea behind Titanium isn’t new, but Titanium clearly separates itself by giving you something unique: unlimited possibilities with open-source choices. You aren’t forced to use anything proprietary—you can use any library or framework you want. All technological decisions are yours to make. Although I mainly program with JavaScript for Web applications, it isn’t the only technology that powers the Web. Titanium works well with Python, PHP, Ruby, Java, Flash and Flex, and Silverlight. So whatever technology you’re using right now to develop your Web applications, you’ll likely be able to use it with Titanium. Because Titanium is distributed under the open-source Apache Public License v2, you can download the source code, play with it, fork it and extend it. It’s this extensibility that makes Titanium a platform that developers can grow with in the future. The platform can morph and evolve into different forms as new needs emerge.

Rapidly Evolving Web Development Platform
Titanium is evolving rapidly and has experienced several major changes to its architecture in the past few months. The initial preview release of Titanium (PR1) incorporated WebKit and a modified version of Google Gears. Essentially, Titanium PR1 used WebKit as its main component, and additional features were exposed to the runtime via a native extensions system, which gave developers access to features from a modified version of Gears. Soon after this initial preview release, the Titanium team started to re-architect the platform. Google Gears was removed, and instead, a new system for exposing new features was created: Kroll. Kroll is the microkernel that powers Titanium and extends the framework. This compact microkernel, written in C++, is a cross-language, cross-platform “binding” and invocation framework that enables mixing and matching code within the kernel. All the features that Titanium exposes are accomplished via Kroll modules. By using Kroll, Titanium gains the ability to support a multitude of languages and technologies. And, because Kroll is fully extensible, anyone can add more features to the platform, using any technology. You don’t need to be a C++ guru to extend Titanium. You can create new modules using Python and Ruby, or even just plain-old JavaScript. Titanium’s use of WebKit was retained during the rewrite from PR1, and for good reasons. Not only is WebKit one of the best, standards-compliant engines available today, but it also features lots of goodies, such as HTML5 client database storage, CSS transformations and animations, and a fast JavaScript engine. All of these, of course, are available on Titanium.

A Rich API for Rich Application Development
As you saw in the code above, all languages supported by Titanium have a window object. This is the shared global object and is used to bind methods and objects that need to be available on all languages. The main namespace for the Titanium API is also bound to this global object and can be accessed via window.Titanium. Aside from WebKit goodies, such as client-side database storage and CSS animations, Titanium’s current API also contains many of the necessary features needed for desktop application development:

• Titanium.Desktop: for launching third-party applications and opening URLs on the default browser.

•Titanium.Filesystem: for working with the filesystem for things like reading and writing files, creating and managing directories and so on.

• Titanium.Media: for working with media files, such as audio and video.

• Titanium.Network: for working with network-related tasks, such as socket connections and IRC clients.

• Titanium.Notification: for custom system notifications, as well as hooks to platform-dependent notification systems like Growl and Snarl.

• Titanium.Platform: for getting information about the Titanium.Process: for working with system processes, as well as launching and executing system commands.

• Titanium.UI: for working with native windows, menus and system chrome.

Unfortunately, going over all of these APIs would require an article (or two) in itself. Fortunately, the official Titanium site provides documentation with more details.

Source of Information : Linux Journal 185 September

• 0 comments »

Sometimes you’ll need to run SELECT queries against very large tables (containing millions of records), with several WHERE conditions on columns that have poor index selectivity (i.e., return too many rows for a given WHERE condition) or could not be indexed at all. Common examples include searching for users in a social network and
searching for items on an auction site. Typical search interfaces let the user apply WHERE conditions to 10 or more columns, while requiring the results to be sorted by other columns.

With the proper schema and query optimizations, MySQL can work acceptably for such queries, as long as the WHERE clauses don’t contain too many columns. But as the number of columns grows, the number of indexes required to support all possible searches grows exponentially. Covering all the possible combinations for just four columns strains MySQL’s limits. It becomes very slow and expensive to maintain the indexes, too. This means it’s practically impossible to have all the required indexes for many WHERE conditions, and you have to run the queries without indexes. More importantly, even if you can add indexes, they won’t give much benefit unless they’re selective. The classic example is a gender column, which isn’t much help because it typically selects half of all rows. MySQL will generally revert to a full table scan when the index isn’t selective enough to help it. Sphinx can perform such queries much faster than MySQL. You can build a Sphinx index with only the required columns from the data. Sphinx then allows two types of access to the data: an indexed search on a keyword or a full scan. In both cases, Sphinx applies filters, which are its equivalent of a WHERE clause. Unlike MySQL, which decides internally whether to use an index or a full scan, Sphinx lets you choose which access method to use.

To use a full scan with filters, specify an empty string as the search query. To use an indexed search, add pseudokeywords to your full-text fields while building the index and then search for those keywords. For example, if you wanted to search for items in category 123, you’d add a “category123” keyword to the document during indexing and then perform a full-text search for “category123.” You can either add keywords to one of the existing fields using the CONCAT( ) function, or create a special full-text field for the pseudokeywords for more flexibility. Normally, you should use filters for nonselective values that cover over 30% of the rows, and fake keywords for selective ones that select 10% or less. If the values are in the 10–30% gray zone, your mileage may vary, and you should use benchmarks to find the best solution. Sphinx will perform both indexed searches and scans faster than MySQL. Sometimes Sphinx actually performs a full scan faster than MySQL can perform an index read.

Source of Information : OReIlly High Performance MySQL Second Edition Jun 2008

• 0 comments »

MySQL’s full-text search capability* is fast for smaller datasets but performs badly when the data size grows. With millions of records and gigabytes of indexed text, query times can vary from a second to more than 10 minutes, which is unacceptable for a high performance web application. Although it’s possible to scale MySQL’s full-text searches by distributing the data in many locations, this requires you to perform searches in parallel and merge the results in your application. Sphinx works significantly faster than MySQL’s built-in full-text indexes. For instance, it can search over 1 GB of text within 10 to 100 milliseconds—and that scales linearly up to 10–100 GB per CPU. Sphinx also has the following advantages:

• It can index data stored with InnoDB and other engines, not just MyISAM.

• It can create indexes on data combined from many source tables, instead of being limited to columns in a single table.

• It can dynamically combine search results from multiple indexes.

• In addition to indexing textual columns, its indexes can contain an unlimited number of numeric attributes, which are analogous to “extra columns.” Sphinx attributes can be integers, floating-point numbers, and Unix timestamps.

• It can optimize full-text searches with additional conditions on attributes.

• Its phrase-based ranking algorithm helps it return more relevant results. For instance, if you search a table of song lyrics for “I love you, dear,” a song that contains that exact phrase will turn up at the top, before songs that just contain “love” or “dear” many times.

• It makes scaling out much easier.


Source of Information : OReIlly High Performance MySQL Second Edition

• 0 comments »

Sphinx can complement a MySQL-based application in many ways, bolstering performance where MySQL is not a good solution and adding functionality MySQL can’t provide. Typical usage scenarios include:

• Fast, efficient, scalable, relevant full-text searches

• Optimizing WHERE conditions on low-selectivity indexes or columns without indexes

• Optimizing ORDER BY ... LIMIT N queries and GROUP BY queries

• Generating result sets in parallel

• Scaling up and scaling out

• Aggregating partitioned data

We explore each of these scenarios in the following sections. This list is not exhaustive, though, and Sphinx users find new applications regularly. For example, one of Sphinx’s most important uses—scanning and filtering records quickly—was a user innovation, not one of Sphinx’s original design goals.


Source of Information : OReIlly High Performance MySQL Second Edition

• 0 comments »

Sphinx (http://www.sphinxsearch.com) is a free, open source, full-text search engine, designed from the ground up to integrate well with databases. It has DBMS-like features, is very fast, supports distributed searching, and scales well. It is also designed for efficient memory and disk I/O, which is important because they’re often the limiting factors for large operations.

Sphinx works well with MySQL. It can be used to accelerate a variety of queries, including full-text searches; you can also use it to perform fast grouping and sorting operations, among other applications. Additionally, there is a pluggable storage engine that lets a programmer or administrator access Sphinx directly through MySQL. Sphinx is especially useful for certain queries that MySQL’s general-purpose architecture doesn’t optimize very well for large datasets in real-world settings. In short, Sphinx can enhance MySQL’s functionality and performance. The source of data for a Sphinx index is usually the result of a MySQL SELECT query, but you can build an index from an unlimited number of sources of varying types, and each instance of Sphinx can search an unlimited number of indexes. For example, you can pull some of the documents in an index from a MySQL instance running on one remote server, some from a PostgreSQL instance running on another server, and some from the output of a local script through an XML pipe mechanism.


Source of Information : OReIlly High Performance MySQL Second Edition

• 0 comments »

Now that you have the W3C checker installed on your own server, you can feed it URLs that aren’t open to the public. But, if you are developing an application in Ruby on Rails, you can go one step better than this, integrating the W3C validator into your automated testing.
In order to do this, you need to install the html_test plugin for Rails. Go into your Rails application’s root directory, and type:

script/plugin install
_http://htmltest.googlecode.com/svn/trunk/html_test

With this plugin in place, you now can use three new assertions in your functional and integration tests: assert_w3c returns true if the W3C validator approves of your HTML;
assert_tidy returns true if you’re using the HTML Tidy library, described below; and, assert_validates calls both of these. So, if you have a FAQ page you want to check with an integration test, you can write something like this:

def test_faq
get '/faq'
assert_response :success
assert_w3c
end

If the HTML for this page is approved by the W3C validator, everything is fine. If this page is not valid, you will get quite a bit of output, which you should redirect to a file. This file will contain not only the results of your tests, but also the same HTML output that you would have gotten from the public, Web-based W3C validator. This means you’ll get a complete and easy-to-read description of what you did wrong. You’ll often discover that a large number of validation errors can be fixed with a small number of corrections. For example, when I ran this test against a sloppy FAQ page, I got six validation errors. I was able to fix all of them by indicating the appropriate namespace in my tag and removing an extraneous

from the end of the file.

Checking HTML validity in this way is nice and easy. (It can be time consuming, however, to invoke the validator on every single page; I think the trade-off is worthwhile, but you might disagree.) If you always want to check HTML validity, you can change your test environment’s configuration somewhat, so that it’ll happen automatically, without having to invoke assert_w3c each time.

To do this, you need to modify test_helper.rb, which sits at the top of the test directory, and which is included into every test program. All you have to do is add:

ApplicationController.validate_all = true
ApplicationController.validators = [:w3c]

You also can check the validity of URLs and redirects; although these aren’t checking HTML validity per se, they do come with the html_test plugin and are quite useful:

ApplicationController.check_urls = true
ApplicationController.check_redirects = true

With these four lines in your test_helper.rb, you can run your integration tests once again. If any of the validation tests fail, you can look at /tmp/w3c_last_response.html, which will contain the complete output of that failure. This doesn’t help very much if you have multiple failures, however. If you have designed your templates using the DRY (don’t repeat yourself) principle, fixing HTML markup problems shouldn’t be too bad. In many cases, you will need to change only one tag in the layout to fix everything.

Source of Information : Linux Journal Issue 182 June 2009

• 0 comments »