mod_mono version: 2.6.3

Download

32-bit: i386
64-bit: x86_64

Before we get to the code, validate you have the Ruby Subversion bindings installed correctly by running irb from a terminal:

irb(main):001:0> require 'svn/client'
=> true

Onto the source code. Start it off by including the required svn modules:

Then setup the context with your subversion credentials:

Now you can run any of the following commands on a remote subversion repository.

SVN Info

SVN Checkout

SVN Log

SVN List

That should get you started with the ruby bindings. If you want to know how to do anything else let me know in the comments.

The symfony debug toolbar will look like this when there is a validation error in one of the forms on the current page. This is one of the most incredibly useful features I've seen and greatly improves productivity while building forms in the symfony framework. Congratulations to the symfony developers who came up with this tool!

Have symfony 1.1 or 1.2? read catch symfony form errors.

I foresee a new framework will be created to make developing fully interactive AJAX applications as easy as it is to write current MVC applications. Current frameworks like Ruby on Rails and Symfony provide everything you need to develop a modern application without having to build plumbing infrastructure; however, they do not provide nice components for interactive applications. In addition to a robust server core, this new framework will have a client side JavaScript component that simplifies the process of building interactive web 2.0 applications. Some critical components would be:

• Form Validation. Libraries do exist to validate forms in JavaScript, but they don't integrate with the server side form validation. In this new framework you won't have to write form validation code twice.
• Paginated Lists. Almost all web applications have at least one page where data needs to be searched and listed with pagination. We need to have this same functionality in JavaScript to skip a full page reload and provide local caching of the results.
• Animation Library. While script.aculo.us and jQuery have made simple animations and visual effects much easier to do, I believe we can go even farther. Web applications also need to gain that fluidity and soft animations that desktop applications such as Exposé have had for a couple of years.

I also see huge resources being directed towards mobile development because ALL current generation smart phones are built for an incredible web browsing experience. As home users have switched from desktop computers to laptop computers in the last few years, people will slowly start switching to hand-held devices for their primary communication and Internet needs. Most likely this will have one primary effect: web frameworks will have a mobile optimized version of the site done automatically. Little to none developer intervention will be required as only resolution, text sizes, and layouts will be modified for the mobile version.

Lastly I see tools and libraries around 2D and 3D drawing elements. Most likely these libraries would be rendering to a Canvas or a WebGL element but something better could be created. Both of these are young standards right now that show a lot of promise on delivering the ability to draw pixels directly in a native HTML web page. While they will be used first in simple computer games, I am very interested to see what libraries are created to facilitate these elements being used appropriately inside next generation web applications.

What do you think the next 5 years will bring?

Start your script with She-Bang header:
#!/bin/bash

Variables are assigned by a key-value pairing:
FILENAME="~/docs/input"

You can print to the console by using echo:
echo $FILENAME

An IF statement:
if [ ! -s $FILENAME ] ; then
  touch $FILENAME
fi
The bang ! negates the result, and the -s parameter checks if a file exists.

Example of a function:
function getFile
{
  # function contents here
  # the hash symbol makes the rest of this line a comment
}

Call this function by using its name:
getFile

You can pass a variable to a function:
getFile "/home/user/docs/file.txt"

And use it within the function by reference to $1
function getFile
{
  echo $1
}

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.