Content-Disposition: attachment; filename="filename.mp3"

Tested in: Firefox, Safari, IE, Opera, and Google Chrome

I wanted my users to remain logged in while navigating from www.example.com to site1.example.com. By default PHP will treat these domains as two separate sites and users would have to login to each subdomain.

All you have to do is to either set the following setting in your php.ini file:
session.cookie_domain = .example.com

Or, set it from within your code before you create your session:
ini_set("session.cookie_domain", ".example.com");
session_start();

Each Facebook request to your application contains a number of parameters that you can use to authenticate if the request really came from Facebook and if the user is actually logged in. These parameters looks like this:

Array
(
    [fb_sig_in_canvas] => 1
    [fb_sig_request_method] => GET
    [fb_sig_friends] => 12345678,123456789,...
    [fb_sig_locale] => en_US
    [fb_sig_in_new_facebook] => 1
    [fb_sig_time] => 1265247656.6432
    [fb_sig_added] => 1
    [fb_sig_profile_update_time] => 1261813927
    [fb_sig_expires] => 1265248900
    [fb_sig_user] => 1234567
    [fb_sig_session_key] => 2.18zPq2sNPEE6sn0wpMLc5w__.3600.1265248800-1234567
    [fb_sig_api_key] => ab6c2d2604ae9604be0efef88315c53e
    [fb_sig_app_id] => 289424642699
    [fb_sig] => 575ed0ccd0c9b3ea2d5d7c5417187de6
)

If you create an iFrame in your facebook page, the parameters will be passed to the iFrame but by will not automatically be passed from one request to the next. Once the user clicks on a link or you try to do an ajax request, you will not be able to validate the user. The simple trick to keep the authorization is to pass the fb_sig_* parameters to request. A handy PHP function like this will help:

If you append the result of that function to the query string of each request, the $facebook->require_login() call and the $facebook->validate_fb_params() can then successfully validate if your user is from Facebook.

CSS Orientation Properties

Web applications look and feel is defined by a CSS file, so therefore the Firefox developers made it super easy to tie current orientation and screen dimensions into which CSS file to load.

For examaple: If the browser is in portrait mode, a single CSS media parameter will specify which styles to use:

In the same way, you can create a custom CSS stylesheet for users who are browsing with a screen size between 500 and 700 pixels:

Orientation Events

Firefox 3.6 adds support for orientation events in JavaScript, so you can get current updates of how the user is holding their mobile device:

Once you register the event handler, the handleOrientation function will receive an object specifying the x, y, and z value of the devices current position:

With those parameters and a game timer, you can probably build the Labyrinth game.

For those of your that are ready to start experimenting with this API right away, Mozilla Developer Center has the full Firefox orientation documentation.

Firefox, Safari, Google Chrome, and soon Opera all support the HTML5 video tag with the ability to play Ogg Theora encoded videos (except Safari). On the other hand, H.264 is only supported by Google Chrome and Safari. Both of these formats do the same thing, they specify a compression standard that allows for efficient playback at relatively small file sizes. There are a number of technical differences, but generally, they preform relatively the same. The big difference between the two is that Ogg Theora is royalty free and available for anybody to use, while H.264 is encumbered by patents held by the MPEG LA association. This same organization will charge anybody who uses it a hefty royalty fee starting in 2011.

If you have a personal blog and want to put a video on your website using H.264 this means you need to have to hire a lawyer to create a deal with the MPEG LA to allow you to use their codec. This will either cost you a lot of money, or they will not allow you to do it. They do have the right to simply deny you if they don't feel like it.

However, if you use the open Ogg Theora format, you are free to simply upload the video to your website to start using it, the same as uploading an image. Ogg Theora is not covered by any patents and is royalty free.

I don't understand why both YouTube and Vimeo are both going the non-free route. Is it simply because they have the money to pay MPEG LA? Whatever the case, endorsing H.264 encoded videos as the format for video on the web is an option for large companies with money to pay, but it's completely the wrong choice for blog writers and any small or medium sized organization.

When developing an application you must learn Rule #1 Facebook is the gatekeeper. Everything you do, be it HTML, CSS or JavaScript, is restricted by Facebook. Only the commands, functions, CSS properties, HTML tags etc. that Facebook allows are permissible. If you have an error in your HTML such as an unclosed tag or if you try to use a CSS property that does not exist, Facebook will render a very nice message saying you made an error.

Rule #2 The never ending cycle. The Facebook platform is constantly changing and APIs that you are using in your application could disappear one day without any notice. It's the life of a Facebook application, working one instant, inexplicably broken the next. Be prepared for irregular maintenance just to keep your application working.

A Facebook Application lives in the world of Facebook and while it might initially seem like you're developing a standard web application you are not. Rule #3 You're application is on the Facebook web. It's not a regular web application which is a very slight but critical distinction. Facebook has used their powers as the gatekeeper to make modifications to the web. Some HTML tags are allowed, some are not. JavaScript has been altered to remove a lot of its power and replace only some of them with Facebook specific functions and even CSS has restrictions. Don't expect existing code to function when placed in the Facebook web.

Additional Caveats

• You cannot include any external JavaScript or style sheet files, they must be included in-line. This is so Facebook can parse them and allow only approved commands. Yes it enhances the security of the social networking site as a whole, but it will slow down your development time.
• Facebook will filter, compile, and drastically alter your original code. Clicking view-source on a Facebook page with your application will show your JavaScript code mushed into awkward Facebook functions.

Do you see that it's a bit of a battle of you against the mighty Facebook? Don't sweat too much, other developers have persevered and with a few wounds and time you can build and maintain a successful Facebook application. Good luck!

UpcomingHoliday.com is an application that tells you what and when your next federal holiday is. Currently it's available for people in: Australia, Canada, France, Germany, India, Nigeria, United Kingdom and United States.

The posts were originally posted on Senses and reproduced here for archival purposes. They touch on a lot of basic information for software developers including software design, upcoming technologies and useful tips to make your life easier.

Check the Quality Software page for links to each article.

So what are the visible user centred differences between high and low quality software?

It's quite easy to see when software is shoddy. This could be OEM bundled software, custom intranet applications, or even a well known enterprise product that has taken over the market. I'm sure you have memories where software blue screened or stopped working before you could save the document. Applications that were not throughly tested by QA and were not written with a clear understanding of the business requirements are loaded with bugs. When these software applications are used in the real world the bugs appear and cause intense frustration to the poor users.

The applications we use that are true quality are the ones that we hardly notice. Quality software has an intrinsic property of not getting in the way and allowing the user to focus on their action, instead of focusing on the application. It's as simple as that.