Why web apps can get away with being in beta for a long time

An article was recently posted on the Wall Street Journal website entitled “WSJ.com - For Some Technology Companies, ‘Beta’ Becomes a Long-Term Label” which asked the question how can companies get away with leaving software in a “beta” state for so long. Google is notorious for doing it - Gmail has been around for at least two years and is still tagged as beta. In fact, many people are using Gmail as their primary email address. There are many real-world analogies as to why you wouldn’t do this in the article, so I won’t bother repeating them here.

It does bring up an interesting point though. How come web software can get away with, nay, thrive on, releasing beta software?

Traditionally, the main thrust of software was the underlying business logic. It has only been in recent times where user interfaces and user experience has become important. It is often impossible to know exactly how a user is going to react when they start to use an interface. Being in a constant state of beta allows designers to be constantly tweaking elements of the design. If things change drastically, users will put it down to the fact that the site is still in beta.

This is relevent when adding features. As a developer, you may find a new “must have” feature that you are sure that your web site requires. It is a more effective use of your time to build a version quickly, so that you can gauge it’s popularity, and then concentrate on making it robust if you know it is worth-your-while. You couldn’t get away with this without being in a beta state.

Obviously, this isn’t a mechanism for everyone. I would even think about using a security product that was in beta. But for web apps that aren’t doing anything mission critical then it should be fine.

Cookie-less sessions in PHP

Tags: php || 10 Comments

There is a fairly good chance that all but the most trivial dynamic sites will use sessions to emulate a stateful environment. Before the creation of sessions, the developer would have to manually pass all of the variables the next page needed via hidden input fields or cookies. As you can imagine, this is a bit of a security risk. Not to mention that cookies are limited to 4k each - if you have a large number of variables, this can quickly run out.

PHP, like most server languages can handle your sessions for you - but how does PHP keep track of sessions? There are two ways - using cookies and hidden fields. The former is the preferred way as it is easiest and is more secure (But not with out it’s risks. Check out the PHP session documentation for more info on the safe use of session variables). PHP writes a cookie which holds the PHPSESSID variable. It looks for this value when start_session() is called and if it exists, matches it to the stored session. But what happens when cookies aren’t available or are turned off? PHP is smart enough to work this out and will re-write all links and forms on the fly to ensure that the PHPSESSID is passed on every action that will refresh the page.

Well, almost. When I code, I prefer to postback to the same page, do some processing (such as error validation and storing of required session variables) and then use header(”Location: “) to re-direct the user. This makes coding much easier because all of the business logic for that page is kept in one file. Unfortunately, PHP isn’t smart enough to re-write these redirect, so we will have to help it out a bit.

append_sid

The following function will look at a URL (Whether it be relative or absolute) and append the SID if and only if PHP is in cookieless mode. I couldn’t find a PHP function that will tell you whether cookies are working, however after a bit of thought it was quite easy. PHP has a super-global called $_COOKIES. In this super-global, the PHPSESSID variable is referrenced. By checking whether it exists (After a call to session_start) we can work out whether we are in cookie or cookie-less mode:

function append_sid($link) {
    if(session_id() !== NULL && !isset($_COOKIE['PHPSESSID'])) {
        if(strpos($link, "?") === FALSE) {
            return $link . "?PHPSESSID=" . session_id();
        } else {
            return $link . "&PHPSESSID=" . session_id();
        }
    } else {
        return $link;
    }
}

Basically what happens, if the function checks to see if the session has been started - if it has, it then checks if the cookie entry exists. If it does, it just returns the link unchanged, otherwise it appends the session id. The inner most if statement checks for a ‘?’. If it exists, we can assume that the link already has some get parameters, so we will append the PHPSESSID using an ‘&’. Otherwise, just append it with a ‘?’.

JavaScript

Don’t forget that if you are re-directing client using javascript or using sessions when making AJAX calls you need to pass the session id as well. The best way to do that is client side, especically if you are generating parameters on the fly. The same theory applies, except we will use JavaScript this time:

function append_sid(link) {
    < ?php if(session_id() !== NULL && !isset($_COOKIE['PHPSESSID'])) { ?>
        var session_id = '< ?php echo session_id ?>';
            if(link.indexOf('?') == -1) {
                return link + '?PHPSESSID=' + session_id;
            } else {
                return link + '&amp;PHPSESSID=' + session_id;
           }
    < ?php } else { ?>
        return link;
    < ?php } ?>
}

The reason there is PHP code interleaved (I know. I hate it too) is because we need to work out whether the session has actually been started and we need the session_id. However, we don’t want to display the session id UNLESS there is a requirement for it as it can be a security risk.

A caveat - passing session id by URL requires the session.session.use_trans_sid tio be set to 1. Most shared hosts turn this off, but you can usually override it by putting:

php_value session.use_trans_sid = 1

in the .htaccess file. You can also try the function:

ini_set('session.use_trans_sid', '1')

On every PHP page.

Now, hopefully, you won’t be cutting off those users that don’t use cookies!

Ruby on Rails highlighting in Dreamweaver

I found this site that outlines how to setup code highlighting and hinting in Dreamweaver MX.

In short - the instructions for code highlighting is here and the xml for code completion is here. (I would duplicate it here, but my version of wordpress doesn’t allow xml :( )

The only thing I did different was to create a file called Ruby.xml in the CodeColoring directory with and cut and paste the code colouring xml inbetween codeColouring tags (Have a look at one of the other XML files to get what I mean).

Unfortunately, I still haven’t gotten the .rhtml files highlighting correctly. I’ll keep you posted.

Sub-directories on rails

I haven’t been able to find this anywhere in literature (I’m sure it is somewhere, I just haven’t figured a good enough google search string to find it), but I wanted to be able to use sub directories to partition different areas in Ruby on Rails.

e.g /admin /admin/articles etc

Ruby on rails uses the following mappings between the URL and the controller:

http://www.url.com/application/controller/action/id

which maps to a AcitonController class called controller which has a method called action

I wanted to have multiple a controller directories:

http://www.url.com/application/controller/subcontroller/action/id

You do this by creating a sub directory under the controller directory (in this case called controller) and creating file called subcontroller_controller.rb - The class declaration of this file should be Controller::SubControllerController < ApplicationController.

 

So, if you wanted to create a controller called articles in the sub directory admin you would create:

  1. The subdirectory “admin” under the controllers directory
  2. The file articles_controller.rb in the controllers/admin directory
  3. Declare the class as: Admin::ArticlesController < ApplicationController

You also need to create the corresponding .rhtml files in a sub directory in the views folder…

Developing for Accessibility

Tags: work || No Comments

Accessibility, as the name suggests is about making websites accessible to as many users as possible. Unfortunately, not everyone on the planet has 20/20 vision, or full use of their hands, which can make using traditional web sites difficult - why should they be disadvantaged by not being able to harness the plethora of information out in cyberspace? Even beyond that, there are many able-body web users that are using non-standard browsers and software to access websites. PDAs, mobile phones and hand held game machines (such as the Sony PSP) are examples of systems that have restricted screen sizes and memory footprints which makes packing a full blown web browser impossible. Another benefit of an accessible website is it makes the search engine robots’ job much easier.

Different ways of using the web

The web is no longer confined to the walls on universities, or geeky tech type people - 14 million people in Australia have access to the internet [Nielsen/NetRatings]. Even if you ignored 5% of that audience, that is potentially 700,000 people that cannot access your website. This is especially relevent to government websites who theoretically should be targeting everyone.

There is no way of guaranteeing that all of these users are using standard desktop setups either: some variations include:

  • Screen readers: These programs are used by sight-impaired users. They read in the HTML markup and read it out using a synthesised voice. These system tend not to understand JavaScript or Flash.
  • Braille readers: Again used by sight-imparied users. Very much like a screen reader, except they output the page in Braille
  • PDA/Mobile phone: very handy for those who are out on the road a lot. These usually have a reduced screen size, and limited memory. They also have different method of inputting data, so things like JavaScript menus will probably not work.
  • Slow internet connections: People out in the bush (Or even the suburbs) may not be able to get broadband, or reliable modem connections. So there may still be a number of people that try to reduce bandwith by switching off images.
  • Text-only browsers: Not really sure why you would still use these other than because you can - although, they can provide a good indication of what your site looks like to a search engine spider.

Accessibility and Standards

The basics of accessibility can be acheived by following the World Wide Web Consortium (W3C) standards documents. These standards are about creating semantic, structured layout that can easily be intepreted by any system that understands the standards. The standards break up the structure layer and the presentation layer, by usingl Cascading Style Sheets (CSS), which effectively gives the designer control over how an element looks without destroying the document structure. The names of HTML tags have been carefully selected to decribe document elements. Unfortunately, in the old days, many designers abused the default display properties of some elements, misusing them to present information in a certain style.

For example, an old trick to indent text would be to wrap it in tags. It is hard to image how a screen reader would handle this - it comes across some text it expects to be an un-ordered list, only to find a block of text. The correct way of doing this would be to wrap it intags, and use the CSS property padding-left to indent the whole block.

Before CSS, it was common to mix up the order of items in the HTML to fit the presentation of the page. This means that a user running a screen reader would have the contents read out in the wrong order… Not very usable at all.

Don’t rely on colour

Colour blindness is a condition that stops the sufferer for perceiving certain colours. This can create two potential problems for the web designer - foreground-background contrast and colour for notification. Any user with normal vision knows how hard it is to read dark blue text on a black background - because the contract between the two colours in not enough. However, there are certain colour combinations that would be fine for non-colour blind people, but would work for those that did have the deficiency.

To be continued… [I’ve to go to my exam now - this will be interesting]

« Previous Entries