Delivering Quality

If you’re interested in programming graphics on the web I recommend subscribing to Planet WebGL; it has a lot of great tutorials and instructional material for learning how to program graphics in a web environment.

WebGL is technically a JavaScript binding to OpenGL ES 2.0. If you already know OpenGL ES and JavaScript, you should be able to pick it up pretty quickly. If you know JavaScript but not OpenGL and are in a web development career, I encourage you to look into WebGL because it could be one key component of interactive web applications in the future.

A fairly common website optimization that a lot of web 2.0 dot com companies are doing is to remove the leading www from the domain name. Removing the legacy www leaves you with a domain like http://delicious.com. Ok so delicious has a modern domain name but should you switch also?

Reasons for non-WWW

First, the domain name is more concise, easier to remember and just looks better. One caveat: you will need to setup a 301 redirect for requests with the three w’s to go to the non www version (see below).

Hold on, is it that simple?

No, it’s not, there are some disadvantages to having a domain name without a leading www.

Cookies are stored in a web browser at a set domain name. If you are not using the www, the cookie is saved to root: example.com. This can be quite a large disadvantage because the cookie is then passed along for every single request that browser makes for any subdomain on example.com. Even if you setup an alternate server just for serving images (images.example.com), your users browser will sent the cookie to that domain while fetching images. Sure its not a lot, but it does add up and removes some flexibility from your setup.

Another area it impacts is a site specific search in google. Doing a google search like the following: managing complexity site:markdeepwell.com, will not only search your main example.com website, but also all its sub-domains.

Reasons for WWW

Just about every person on the planet can recognize a domain name if it starts with www.something. Yes the www is redundant and not needed anymore, but it is a bit more user friendly.

If your site has multiple sub-domains, then I’d definitely recommend you go with a www domain to keep them all separate. Large websites benefit more from having the leading www; alternatively, if you have an extremely simple website like upcomingholiday.com it would do no harm to remove the www.

If you have a domain that’s been around for a few years it is possible to switch from one to the other, as long as you setup 301 redirects for SEO purposes, or else your rankings will plummet.

No matter what, make sure you have a 301 redirect setup so that users only see one version of your site instead of two. Be consistent by picking one and sticking with it.

Here are some common htaccess rules for redirecting requests to the proper domain name.

Redirect www to non-www:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Redirect non-www to www:

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule (.*) http://www.%{HTTP_HOST}/$1 [R=301,L]

Vladimir Vukićević, the pioneer of bringing the well known OpenGL standard to the web, has just blogged using Firefox to render Spore creatures. Check it out, it’s a pretty impressive demo of this upcoming web standard.

Development on what would become WebGL started back in 2007 with Canvas 3D as an extension for Mozilla Firefox 3.0. Since then it has grown from a single project to an open web standard through the Khronos standards group. The standard is currently under development with a target release date of first half 2010.

Firefox isn’t the only web browser to be experimenting with WebGL, Google and Opera have also pledged to support this standard. The WebKit source code has recently picked up preliminary support.

The web has mostly stayed 2D, but with the advent of CSS Transforms and WebGL, the browser is moving into new territory. The web is evolving into the most important platform of the future.

Ever wanted your web application to be able to show notifications even if the user may be in another browser tab or application? Now you can!

The relatively new Yip extension for Firefox adds notification functionality. This is not a small JavaScript notification that pops up in the browser tab, but one that integrates directly with the users Operating System.

Yip uses libnotify/notify-osd on Ubuntu Linux, Growl on Mac, and Snarl or Growl for Windows on Windows. If none of these notification applications are installed, it will use Firefox's simple and not as pretty notification system. Ubuntu Linux users have notify-osd installed by default, Growl is popular with Mac users, yet Windows users probably don't have Snarl or Growler for Windows installed.

When building with notifications remember that they are meant to enhance the user experience, not require it.

The Yip extension supports both the Fluid and Prism APIs, but recommends Fluid because of support for an onclick callback function.

The API is simple and straight to the point:

Since Yip may not be installed on the users computer, just wrap it with a check for fluid. A complete example looks like this:

Related Projects

• Roar: Embed notifications into a web page (powered by MooTools).
• growl.js: Windows only notifications using Growl for Windows.
• NotificationAPI: Notifications in Google Gears

Of all these options, Yip is the best solution by far; its fully cross platform, has a simple to use API, and is ready to use. Install Yip now.

The symfony web framework provides two methods for building the database model files when using the Propel Object-relational mapping (ORM) toolkit. The recommended method by the symfony team is to use the schema.yml file, where you explicitly explain your table structure. The second method is to generate a schema.xml file directly from the database.

schema.yml:

Just edit config/schema.yml and list your tables, columns, column types, and foreign keys in YAML form. Build the model files by running:

./symfony propel-build-model

Pros:

• Interfaces better with plugins because most, if not all, plugins use the schema.yml method
• Can be used to create the database tables
• Overall easier to use because it is the most common method

Cons:

• Requires duplicate data by having the database structure in a text file, which can be outdated when the database is updated directly

schema.xml:

To create the model files simply run:

./symfony propel-build-schema xml
./symfony propel-build-model

Pros:

• Supports ALL  database features
• Supports the most complex schemas

Cons:

• Errors while building the XML file are cryptic and time consuming to track down (eg: om-template)

Comparison

The schema.yml method supports most projects with relative ease, but is limiting if you need to use more advanced database features that are not supported (propel only supports limited column types). Although, there are tricks to get around these limitations. For example, if you need to use column types that aren't supported, like ENUM, you can simply declare the column as a varchar and Propel won't know any better. This works fine for ENUM because it's simply a text field, but may work for other column types too.

I recommend the schema.xml file for projects that have a very complex schema that cannot be represented in the yml file, or for projects already using XML files to define the database scheme.

I have used both methods on different large projects and have found the schema.yml method to provide faster  application development, have more developer support, and easier to work with. I full recommend use of the schema.yml method in all but the most exceptional projects.