A URL shortening service takes any URL and "shortens" it. The website TinyURL is the most famous. It's being used everywhere around the web, from blog posts to tweets. Since the creation of TinyURL there have been numerous copy-cat sites.

What I really wanted to talk about briefly was how these services work. It's probably not too to difficult to figure out. Basically you have a database table with an ID field and a URL field. When someone requests a URL with an ID, you map it to the URL and perform the redirect.

But notice how these sites are using the base 36 number system rather then base 10 (our decimal system). This makes it possible to create very short URLs even when the ID's in the database are huge. Base 36 is most convenient because it can be encoded using plain ASCII characters 0-9 and (case insensitive) letters A-Z. Using base 36 we can represent an ID of 1000000 (1 million) as "LFLS" which is both shorter, and easier to write out then a long series of numbers.

Since it is easy to convert between base 36 and base 10 (using PHP's built-in base_convert function), we can still take advantage of the efficient indexes database systems have to offer on integers.

(Even more efficient might be to use base 64 which makes a distinction between upper and lower-case letters, but that is less user-friendly/portable.)

Have you ever thought of using base 36 to encode your ID's? Do you think it is really any more user-friendly than decimal numbers? One might argue it's less user friendly because you introduce ambiguous characters like 1/i and 0/O. But certainly for some cases it is something to consider.

Just some food for thought!

I purchased this book before it was published. I love php|a. I subscribe to their magazine, and I've purchased a few of their other books. But this publication is just way below par.

First point: I didn't much care for the writing style. I've heard it described as "light" or "humorous", but to me it just seemed amateur. It was as if a bunch of articles were taken off a blog and bound together into a book. Just imagine if my blog posts were published (well, my writing sucks, so perhaps not that bad). Add in the numerous obvious spelling/grammatical errors, I couldn't help but think who the hell was the editor?

Let's put that aside, though. I don't really care about how the book is written or if it had some typos. I buy a book to learn about a topic. So it all comes down to did the book deliver? and the answer, in my opinion, is a big no.

The author only covers the bare basics of each topic. After reading each chapter I was filled with questions like "but how does x work" or "how would I change x". Not until I Google'd for further reading did I totally understand how each part of the MVC components actually worked. For example, in the MVC chapters there's no mention at all about routing or dispatching, and no mention of plugin hooks.

I'm one of those people who needs to understand the big picture before I can feel comfortable using something. After reading this book, my mind was full of fragmented bits of information that I was having trouble piecing together. The book explained some things fairly well, but others were just glanced over or you were expected to just "accept" that the code did what it was supposed to.

My final thoughts: The book feels very rushed. It is only about 200 pages, not nearly enough to cover ZF. It lacks depth and doesn't fully explain certain things. The online documentation over at the Zend Framework website is easily 10x better. The title of this book should be Primer to ZF or Overview of ZF.

My Rating: 4/10

The Zend PHP Certification is basically a badge that says "I know my stuff". Zend's site actually has a pretty good summary of the benefits of becoming certified.

I became certified for a couple of reasons (other than me being an egotistical bastard). I wanted to test myself and make sure I was actually up to date with everything. I came into the world of PHP around version 4.1. Since then a lot has changed, especially with the advent of PHP5. Taking the practice exams I discovered that there were a few areas I definitely needed to improve upon. For example, primarily working on products that needed to run under a PHP4, I never had much experience with the new XML features.

The other reason was that the exam was really cheap for the possible benefit. Noted, the Zend PHP Certification is hardly mentioned at all by employers. It is relatively new as far as certifications go. But by sticking that badge on your resume, you automatically have a one-up over your adversaries. PHP programmers are a dime a dozen these days, and most of them only know enough to slap together something that barely works. If a possible client knows you've passed the official PHP Certification exam, it gives you some credibility. $125 is a small price to pay. You can make that back in just a single job.

Preparation

I know you're thinking it. Everyone whose asked me about the exam always asks "was it hard?". For me, it was simple. I found it really easy. But I've been working with PHP for a long long time, so obviously your milage may vary (it's all relative, after all).

What you really need to do is a little research. I ended up buying the bundle which included the study guide, 10 practice exams, and the actual exam voucher. It's a pretty good deal, I encourage anyone interested in taking the exam to do the same.

The study guide was not bad. It's basically a quick walkthrough over the entire language. But the practice exams were really useful. The practice exams tell you if you're really ready to take the real thing. I can tell you, they are very very close to the real exam; they are actually a bit harder. If you pass the practice exams, you will surely pass the real exam.

After you finish a practice exam, you get a scorecard telling you which areas you passed, which you failed, and which you did excellent in. For me, this scorecard revealed I needed to brush up with SimpleXML.

I should mention that the exam is a pass or fail thing. There are no grades. My PHP Certification can not be better than yours. So just because you get "pass" instead of "excellent" doesn't really matter unless your ego requires it (like mine!).

What you should know

The Zend website has an overview of the topics covered by the exam. Of course you need to know every inch of PHP, but I will point-out/stress:

• Regular expressions: You should know some basic regex.
• SQL: You will need to know some basic SQL, and how it works (i.e., fetching rows with PDO). Some topics you might need to brush up on include indexes, table joins and transactions. You don't need to be a DBA to pass the exam, but you should know how to work with a database.
• How numbers are represented in hex or octal notation. I mention this here because a lot of us don't need to worry about hex or octal notation in PHP.
• How the bitwise operators work.
• Differences between PHP4 and PHP5. There are a bunch of little nuances here that you may be asked about.
• Security: You should know things like how to avoid XSS, session fixation, filtering input, validation etc.
• XML: There may be a number of questions about XML, XPath, SimpleXML etc. If you've been working with PHP4 a lot, then it's time to get in tune with the improvements PHP5 introduced.
• PDO: If you've been working with a database abstraction layer (which is probably just about everyone reading this), then you probably will need to read up on how PDO works.
• There may be a few questions regarding software architecture such as design patterns (MVC for example), OOP principals etc.
• Streams and network programming is something you will probably need to look into a bit.

Who should take the exam

You should only take the exam if you actually know PHP well. It does an excellent job at weeding out the half-assed PHP programmers, so don't even attempt it unless you know your stuff already. If you are just starting out, or are of average skill, your money would be best spent buying some other material like Advanced PHP Programming.

You should take the exam if you are a freelancer, or looking for work. I think it definitely does give you a heads up over your competition. Even if you have other credentials. Case in point: recently I was looking for a new programmer to help develop a product I work on. One applicant was a CS major, but was an absolutely horrible programmer. You might have passed a few college classes, but that doesn't mean much to me. I need to know that you can deliver.

You should take the exam if you want to test yourself, like I did. It is certainly a good way to discover your weaknesses and your strengths. You might find multiple areas where you had no experience.

So with all that said, good luck!

The solution that I came up with was to use Flash. Seeing as how over 98% of all users have Flash installed, it was the perfect solution.

I ended up finding an open source project called Sound Manager. You just embed the Flash movie on your page somewhere, and talk to it with plain old Javascript. You don't need Flash installed, you don't need to create your own movie -- all you do is use the API provided by Sound Manager.

For the curious ones amongst you, the API is really simple (taken directly from the linked page above):

The only problem I had with using Sound Manager is that it requires MP3's, and all of our sounds were WAV's. No biggie. Converting the files to MP3's was simple, and the resulting filesize a bit smaller anyway.

Even more accessible?

98% of internet users have Flash. That's a pretty good percentage. But I still wanted to make sure those rare 2% of users didn't get some "install this plugin" popup.

Basically what I ended up doing was using a Flash sniffer (some JS to determine if Flash is installed, and which version) to see if the user can use the Sound Manager. If they could use it, then great -- we're all set to go. If they couldn't, then the app reverts back to using good ol'd <embed>'s (except for IE7; no sound is better then an annoying security popup!).

About Zend Framework

The Zend Framework is a free (BSD-like license) PHP framework. It contains components to tackle many common problems including authentication, cacheing, mail, sessions, and of course MVC.

ZF is simple. It is a "use at will" framework, meaning you can take specific components and use them wherever you want. You can, for example, take just the Mail component and stick it into your already existing PHP application. This decoupled architecture is contrary to some other frameworks (including symfony or CakePHP to certain extents) where you are forced into using a single paradigm.

This framework is written for PHP5 only, so it is not encumbered by the limitations of PHP4. It is written using the best OOP principals, is thoroughly tested, and has a marvelous community of maintainers that keep it up to date.

Zend Framework versus other frameworks (symfony, CakePHP etc)

Typically when you think of a framework, you envision a completely developed codebase that includes its own of configuration, its own conventions, and specific programming paradigms. Many frameworks including symfony, CakePHP, Code Igniter and Ruby's Rails, follow this kind of thinking.

Zend Framework is a collection of loosely coupled components. As mentioned earlier, you can use any one of the components separately without running into any problems. Even so, the components still work very well together (for example, Zend_Auth can seamlessly use Zend_Session for persistence).

You need to do a bit more work to use ZF initially. ZF is not all tied together, so if you want to use MVC (for example) then you have to create your own bootstrap, and create your own directory structure etc. When you download ZF it's simply a directory that contains the library files, you're the one who has to initialize and use everything. Compare this to symfony (or many others) where everything is ready to go after you edit a couple configuration lines.

I prefer ZF because I feel like I have more control. I am not tied into any one paradigm, I don't need to play around with configuration files and I can mix and match my code to my hearts content.

Please note that I am not belittling the other frameworks, I am just trying to explain what sets ZF apart. If you read some of my previous posts, you'll see I'm also an advocate of symfony.

The Parts

MVC with Zend Framework is quite easy. Here's a brief overview of each part and how they relate to each other.

1. Front Controller

Most people will use a Front Controller. Using a Front Controller means that all requests come through a central starting point (usually a single index.php file).

The Front Controller starts up your whole app. If there are certain things you need to initialize, here is where you'd do it (loading config for example).

If you've been developing on the web for a while, you've probably seen lots of scripts that have many entry points. For example, you might have index.php, login.php, article.php etc. Most of the time you also have a global.php file that is included at the top of each script. When you have all these entry points, it can quickly become hard to manage and you also start to get a bunch of code duplication.

A Front Controller solves this. Instead of physical files on the disk defining how a request should be handled, the request itself is entered through the Front Controller and then analyzed to see what should be done with it.

2. The Request Object

Each request made has a corresponding Request object. This object wraps up the entire request environment. For example, the default HTTP environment contains things like request parameters from GET and POST. The Request object also contains which controller and action should be called upon.

3. The Router

The Router is what actually inspects the incoming request and decides which Controller and Action should be called up. For example, it will look at a request of /login and decide that the Login Controller should handle the request, and the Index Action should be called.

ZF comes with a default router, so you don't need to change anything unless you want special behavior. By default, the incoming URL is analyzed and the parts are mapped to specific controllers and actions: /:controller/:action. If they are not provided at all, then they are assumed to be 'index'.

3. The Dispatcher

Dispatching is the process of looking at the requested controller and action, and actually including the correct Controller file, instantiating it, and calling on the action. The Dispatcher is in a loop. That means you can run as many controllers and actions as you like.

Again, ZF comes with a default dispatcher that sets down some naming conventions that we'll explore in a bit.

4. The Controller

Finally there is your actual controller. A controller handles a specific part of your app (for example, working with articles) and can have multiple actions (for example, listing articles, viewing a single article, viewing a printable version etc).

The Process

A request is handled like so:

1. A web request is made to a single entry point (usually an index.php file)
2. The entry point creates a Front Controller and runs it
3. The Front Controller creates a Request object that wraps up the environment. At this point there is no controller or action set.
4. The Front Controller uses a Router to inspect the request to figure out which controller and action should be called upon. It sets these values in the Request object.
5. The Front Controller starts the Dispatcher loop which includes the correct Controller source file, instantiates it, and runs the correct Action.
6. A Controller does what it does. It can handle forms, get database info, render HTML etc.
7. Any Controller can also modify the Request object and set a different Controller or Action, so the Dispatch loop is run again. If no change is made, then the Dispatch loop ends and the result is served to the user

You can get a visual representation of the process by viewing this image.

Let's Get Started

The File Structure

I like to separate my files into two parts. One part for the actual application files (controllers, libs, views, functions etc) and then public files that the user needs access to (javascript, css, images etc).

For the sake of simplicity, I also like to package ZF with my app. If you have a shared directory where you place libraries (PEAR, for example), then you of course don't need to include it with your own files.

Here's the structure I use:

• root
  • /client
    • /css
    • /images
    • /js
  • /appfiles
    • /application
      • /controllers
      • /views
        • /scripts
    • /lib
      • /Zend
  • /.htaccess
  • /index.php

This also makes it easy to split up the appfiles from the public files. For example, may people like to place the application source files outside of the document root on the webserver.

The /appfiles/application directory contains all of your controller and view files. We'll talk about the naming convention the default Dispatcher expects in a sec.

The /appfiles/lib directory is where I personally like to keep the Zend Framwork files.

You can of course have any other directories you'd like. On one of my recent projects I had /appfiles/functions and /appfiles/classes for some various custom code files.

Rewrite URLs

To create friendly URL's like /login or /article/view, you need a way to rewrite all URL's to go through the main index.php file. If you are using an Apache webserver and htaccess is a viable option, then the following simple code snippet should work fine for you:

If you are on a different server, there are other ways to rewrite URLs.

Note that you can still use ZF's MVC components without rewriting URL's. Refer to the documentation for info on how to do this.

Create Bootstrap

The bootstrap file is the "single entry point" I've been talking about. It contains the code that launches the Front Controller. In this case, our bootstrap file is index.php.

Here's the code for a simple bootstrap file:

Line 7 defines the ROOT constant to be the full path to the appfiles/ directory. If you were to move the appfiles/ directory somewhere else, you'd want to edit this line so the path stays correct.

Line 8 sets the PHP include path so that the Zend files are all included without any problems. We need this line because we are distributing ZF with the project, we need to tell PHP where to look for the files when we include them.

Line 15 and 16 include Zend_Loader and register it's autoload functionality. PHP5 introduced the ability to autoload classes. Whenever a class is used but has not been defined, PHP will try and find the file and include it for you. This saves you from having to manually write all of the require_once()'s you would normally write under PHP4.

Line 23 fires off the Front Controller which starts up your whole application. As a parameter you need to pass the path to your controller files which in our case is /appfiles/application/controllers.

If you run this now (http://yoursite.com/path/to/project/), you'll see an exception because ZF can't find your controller file to handle the request. So let's write it.

Controllers and Actions

What are Controllers? Actions?

Lets get this question out of the way for those who are new to this kind of website architecture. A Controller is a class that handles the business logic of a given part of your website. It fetches data from a datasource, interacts with output, and then passes any calculations to the View to be displayed to the user (usually as HTML). Some examples of Controllers might be: LoginController, ArticleController and SearchController. Before you might have had files like login.php, article.php and search.php -- now you have classes that control all of this behavior.

Each Controller has a set of Actions, which is just a method you define within the Controller class. An Action is something specific the Controller needs to do. Using our examples listed before, this might be processing a login, displaying an article or performing a search. Before you might have used a variable in the URL to determine what needed to be done. For example, "article.php?do=display" now becomes the ArticleController with the 'display' Action.

Naming Conventions

So you know that controllers are classes, and actions are methods in the controllers. Now the only thing left to cover is how ZF knows which file to load, and which method to call.

You defined the location of the controller files when you called Zend_Controller_Front::run() in the bootstrap. In our example, it is /appfiles/application/controllers.

The Dispatcher (explained above) is responsible for loading the appropriate files, instantiating the correct class, and then calling the correct method. The default Dispatcher that comes with ZF uses a naming convention so you can add controllers and actions easily (instead of say, creating a configuration file that defines it all).

There are two very simple rules:

• All controllers need to be called SomethingController where "Something" can be whatever you want. The class source code needs to be in a file called "SomethingController.php".
• All actions need to be called someAction() where "some" is anything you want.

The default Router and Dispatcher will route a URL /something/some to the SomethingController and the someAction() action. (Meaning: Remember that the default URLs are /:controller/:action).

If a controller is not specified, then the 'index' controller (IndexController class) will be assumed. If an action is not specified, then the 'index' action is assumed (indexAction() method).

Just to hammer it into your head, let's have a few examples of how some possible URLs might be loaded using the default Router and Dispatcher:

• /: IndexController class, indexAction() method
• /login: LoginController class, indexAction() method
• /login/lostpass: LoginController class, lostpassAction() method
• /article/new: ArticleController class, newAction() method

You can also use hyphens in your URL's if you use camelCase in the naming of controllers or actions:

• /download/message-attachment: DownloadController class, messageAttachmentAction() method
• /sign-up/confirm-email: SignUpController class, confirmEmailAction() method

Views

What are Views?

A View is the thing that you give back to the user after they request something. Usually this is an HTML page, but it can be other things like XML or RSS feeds, file downloads etc.

File Locations

Controllers will try to render a view script automatically. It will search for view scripts in /views/scripts/ in the directory above the controller directory (for us that means /appfiles/applications/views/scripts/). Each controller is expected to have a directory of its own, and each action is expected to have a .phtml file that is the actual PHP script to render. For example, LoginController's indexAction() will have a view in views/scripts/login/index.phtml.

View Files

The default view scripts in ZF are plain old PHP. You can add a different templating system if you'd like (like Smarty), but for simplicity, this article will use the default.

In the controller you can set variables to be available to the view, so you can do all of the usual stuff you'd expect like looping, formatting etc.

An Example Page

Time for a really simple example page that demonstrates everything you've just read.

First step is creating a new controller. This controller will be located at: /appfiles/application/controllers/IndexController.php with the following code:

Next we need to create a view script to render the HTML page. The view script will be located at: /appfiles/application/views/scripts/index/index.phtml with the following code:

Now if you run this in your browser, you'll get a simple page that displays a name. So what is going on here?

The Controller

The IndexController is a class the extends Zend_Controller_Action. All of your controllers must extend this base class (or a child of this base class -- you can create your own if you needed to). And on line 4 we have defined the indexAction() method to handle the default index action.

By defining both the index controller with an index action, we now have a default page do display whenever there was no URL supplied (remember that the dispatcher assumes 'index' if no controller or index was supplied).

On line 6 you'll notice we are assigning a name to a variable $this->view->name. This is how you pass values to your view script. You can assign any values. The view script is just PHP remember, so it doesn't matter if you assign arrays, objects, integers or strings.

The View

The view in our case is very simple. I just wanted to highlight how we use the variables assigned in the controller. All values assigned in the controller are available as $this->varname.

Finished

That's all there is to it. Click here to download the sample files used in this article (note that you need to add your own Zend library to the /appfiles/lib directory).

Next article I will go over some more advanced techniques including subclassing the front controller, action controllers, creating plugins and creating helpers.

About Regular Expressions

Regex is a powerful language used to process text. It allows you to define a pattern that a regex engine uses to examine a string of data. The engine applies your pattern to the supplied string and matches the text that was specified in the pattern. What you do with regular expressions depends on the circumstance:

• Matching / Counting: Check if a string matches a pattern. For example, check if the user inputted a correctly formatted email address.
• Replacement: Replacing parts of a string with another. For example, parsing BB-Code into HTML.
• Extraction: Extracting parts of a string. For example, you might want to extract all of the href's in an HTML document.

In this post I am only going over the regex language briefly. See the end for some links to further reading. This article is simply a precursor for another post I wanted to write on using regex with PHP.

The Basics

A regular expression pattern is made up of several simple parts:

• Characters: The actual characters you want to match. You can insert literal strings like "chris", or define a list of characters ("only a, e, i, o and u"), or use the wildcard meta-character to match anything. There are also sets of character types you can use like "any digit" or "any whitespace character".
• Alteration: Used to define a set of alternatives like "chris or christopher or christoph".
• Quantification: Used to explain how many times a character or characters should appear. For example, "only a, e, i, o and u once".
• Grouping: Group a part of a pattern into larger chunks, to define scope, and to specify quantity of a larger chunk.
• Assertions: An expression that is applied to the left or right (that is, before or after) the current matching position. This makes it possible to do patterns like "chris not followed by 'topher'".
• Anchoring: Anchoring a pattern to the start of end of a string lets you define the context; where you want the pattern to match. For example, "match 'chris' at the beginning of the string".

Characters

There are several ways you can define characters that you want to match.

The first way of course is a literal string:

This would match the string "chris", "christopher", "thechris" etcetera.

The second way is to define a character class. A character class is a list of characters that can (or can not) be matched:

The first will match any vowel. The caret (^) in the second example means "not", so it makes the pattern match anything but a vowel. The third example you see the use of a dash. This creates a range of characters. "a-z" means "any letter from a to z", just like "0-9" means "any number from 0-9". Thus, the two last patterns mean the exact same thing. If you want to insert a literal dash (ie. "match a dash character") you must escape it, as demonstrated in the last example.

The third way is to use the wildcard character, or a pre-defined character type:

The first pattern (the dot) simply matches any character. The second pattern is the special escape sequence that means "any word character" (a word character is something like letters or numbers). The final patterns is another escape sequence that means "any digit" (that is, any number 0-9).

You can combine these to make up a fairly complex pattern:

This would match "tchris9" and "zchris7", but not "chris", "chris98" or "zchris". You might wonder why the latter strings would not match. It is because we have not defined any rules for repetition, so the pattern literally means "a single word character followed by the string 'chris' followed by a single number".

Alteration

Alteration is a simpler concept. You simply use the pipe character to separate alternate expressions:

You will see some more useful examples of alternation soon when we talk about grouping.

Quantification

There are three ways you can define the quantity of characters.

First way is by providing no quantification at all. When there is none, it means once:

The first pattern means "one lowercase letter" and the second means "one lower or uppercase letter".

The second way is by using a meta-character. There are three different meta-characters to choose from:

• The asterisk (*) means "zero or more times". The first pattern means "any letter, any number of times".
• The question mark (?) means "zero or one". The second pattern means "u is optional".
• The plus sign (+) means "one or more". The third pattern means "any digit one or more times".

The third way is by explicitly defining the minimum and maximum times the character can be repeated:

The format is {min,max}. Either of the numbers can be excluded. For example, by not defining the maximum number, you just define the least number of times the character matches. The fist pattern means "any lowercase letter 1 to 5 times". The second pattern means "exactly 1 u". The third pattern means "at most 5 digits" (since there is no minimum, this would also match no digit!).

Grouping

Grouping characters is done with parenthesis. There are three situations where you might want to group characters together.

The first is to define the scope for an alteration:

Compare these two patterns. The first means "a word character followed by 'chris' OR 'christopher' followed by a digit". The only way to make the "chris" part alternate is by grouping it together. The second pattern means "a word character, followed by 'chris' or 'christopher', followed by a digit".

You can also group entire subpatterns for quantification:

This means "any letter 1-5 times followed by at least one digit, at least once". It would match "a5", "a5b2", "zs49bf9" etcetera.

The final use is for capturing. When you group an expression, the matching characters are saved and can be re-used later in the pattern:

The first group matches either "b" or "strong". Then later in the pattern you see "\1" (an escaped '1') to represent that match. So that pattern will match a properly formatted "b" or "strong" tag. Here's another example you might use to extract a single or double quoted string:

This would match things like:

1. "hello"
2. 'world'

But not:

1. "hello'
2. 'world"

The second set doesn't match because the quote characters are not the same, so the match would fail.

Assertion (aka Lookahead and Lookbehind)

Assertions are used to test the preceding or following characters against some expression, without actually consuming the characters. Let me explain that a bit more.

When the regex engine tries to apply a pattern to a string, it "consumes" the string as it goes. It has an internal pointer that moves along the string to keep the current position. Matching "(chris|christopher)" against the string "chris98" would put the internal pointer right after the "s", because thats where the pattern stops. Using an assertion simply checks back or forward, without moving the internal pointer.

For example, let's say I want to match my name "Chris" only when it's part of "Christopher". That is, I don't want to match "christoph" or "christine" or anything else. Here's how I might do it with a so called lookahead:

This would match the "Chris" part of "Christopher Nadeau", but would not match "Christine Doe".

The way the regex engine applies this pattern is to look ahead at the starting point to see if all of the characters ahead are "Christopher". The internal pointer is not moved at all. So by the time the lookahead is finished, the engine applies the rest of the pattern "Chris" as normal, starting from the beginning. When the whole pattern is finished being applied to "Christopher Nadeau", the internal pointer is after the "s".

As programmers, we are used to using escape sequences. For example, to insert a double-quote character within a double-quoted string, we escape it like so: "Hello Chris \"Chroder\" Nadeau".

As an example, let's say we are writing some custom parser and need to do the same thing. We want to capture all of the double-quoted strings. This is easy, right?

That captures any character (the dot meta-character means "anything" remember), any number of times when it appears within double-quotes. But what if we wanted to allow the user to escape the double-quote so strings like the one above would be read correctly? That pattern would match "Hello Chris\", which isn't what we want.

We can use a lookbehind to make sure the preceding character is not a backslash:

By using the lookbehind, we make it so the regex engine will not match the ending quote when it is preceded by a backslash.

There are four types of assertions, two of which I have already demonstrated:

• Positive lookahead: (?=expression)
  The pattern is successful if the expression matches the characters to the right of the current position
• Negative lookahead: (?!expression)
  The pattern is successful if the expression does not match the characters to the right of the current position
• Positive lookbehind: (?<=expression)
  The pattern is successful if the expression matches the characters to the left of the current position
• Negative lookbehind: (?<!expression)
  The pattern is successful if the expression does not match the characters to the left of the current position

Anchoring

The last concept, anchoring, is very simple to understand. Say you wanted to match "chris", but only when it was at the very beginning of the string. You do this by anchoring the regular expression to the beginning of the string. What if you wanted to match only at the end of the string? Yup, you need to anchor to the end of the string. Here are three examples:

The caret (^), when it is the first thing in the pattern, anchors it to the beginning of the string. The dollar sign ($), when the last thing in the pattern, anchors it to the end of the string.

The first pattern means "chris or christopher at the start". The second patterns means "chris or chirstopher at the end". The third pattern means "chris or christopher at the beginning and end", which just means "the string is exactly chris or exactly christopher".

You might be thinking, "why is anchoring important?". Well, let's say you want to validate a number that is in the form of ####-##-## (ie. year-month-day). You might want write:

This would work. It matches "1988-12-30". Success? No! It also matches "Blah blah 1988-12-30 blah". The pattern is only telling the regex engine to look for that one expression, it will just skip over all of the non-matching text. So to properly validate the string, you need to anchor it to the beginning and end:

By anchoring to both the beginning and end, you are essentially saying "the entire string must match this pattern".

Further Reading

I think one of the best sites available on the subject of regular expressions is regular-expressions.info. You might find their reference page particularly useful.

If you're a book person, you should definately pick up a copy of Mastering Regular Expressions from O'Reilly.

The easiest way I've found to do this is with Javascript. It's dreadfully simple code. Here's a sample of what I usually put at the footer of my pages that uses Javascript and PHP:

How It Works

First you get the time offset that the user has entered into your application, the one you have on record. You need to get the timezone selection and then the current DST offset. For example, if DST is "on" then that just means you +1 to the users selected timezone.

Javascript has something your server-side scripts might not: it knows about the users locale. So using this fact, we can get the users current timezone offset. This is the "real" offset, the one we know is correct, regardless of what they inputted into your application.

Finally, you simply add the offset your application has on record with the users "real" offset. If the result is exactly -1 or 1 (here I used Math.abs, so -1 becomes 1), that means the information you have on record is incorrect, and the DST status needs to be toggled.

In this example I use a jQuery AJAX call to request a page that would toggle the users DST setting.

There is no formal way to actually define member visibility in Javascript (no "public" and "private" keywords like you might see in Java). Instead we just use the language features in such a way that it creates the same public/private situation as we'd expect in other languages (or nearly the same).

Public

A member is public if "the world" can access it. For methods this means anyone can call on it, and for properties this means anyone can use its value or change it. If you are creating object-oriented programs, having nothing but public members breaks a lot of the ideology. In many languages, like PHP before version 5, programmers used conventions to denote members were private and not to be used. Sometimes this works, but true encapsulation is much better.

There are two ways you create public members:

Constructor

Using 'this' binds the variable to the object, so anyone can use it.

Prototype

Adding a method or property to the prototype also makes it public.

Private

A member is private if only the object itself can access it.

To create private members, you define them within the constructor:

In this example there are two private properties for first and last name, and one private method to return a full name.

Some Issues...

There are a couple of issues you have to be aware of when using private members.

Only methods defined in the constructor can use private members. That is to say, we cannot do something like this:

The scope of the private members are in the constructor only. To get around this problem, you must use what is called privileged methods.

Privileged

As stated before, only methods defined within the constructor have access to private members. Given that many objects are built around using 'prototype', this is problematic. The solution is to create privileged methods.

A privileged method is a method defined in the constructor but assigned to a public variable. Since it is defined within the scope of any other private members, it has access to them. Here's an example:

You can guess that you will be able to retrieve the 'alertName' method or reset it. You might think that it would be possible to redefine the method to take control of some other private member. Not so! The method is a closure and retains the scope in which it was defined. Since it was defined in the scope of the other private members, it has access to them. There is no way to recreate this scope, so even reassigning a completely new function will not allow you to expose any private members.

The 'this' reference

Another thing to be aware of is that functions defined within the constructor have "this" pointing to themselves, and not the object itself. Thus if you need to call other public methods, you cannot. For example, let's make the fullname() method privileged and modify alertName() to call it:

To get around this problem, Javascript programmers assign another private property with the value of 'this' inside the constructor, and use that variable as a reference to the object. The two most common names are 'self' and 'that'; I prefer to use 'self'. Here is the final object, working as expected:

CSRF Explained

CSRF is a type of exploit that allows an attacker to send a request to your application with the authority of another user and without that users consent. Sometimes these requests might mean little (i.e., the user is a guest so they can't do any harm) but other times the requests can be very dangerous and destructive (i.e., the user is an administrator).

How It's Done

There are a number of ways that a request can be made against your server without any user interaction. The most basic and probably most often used technique is with a simple HTML image tag:

Even though the script handling the request ("somescript.php") might not be a valid image, it doesn't matter. The request is still being made. And by providing a width/height of 1 pixel, we can be certain the user doesn't even suspect anything is wrong.

Other ways might include using an iframe in the same way, or using automatic redirects.

How It's Dangerous

By being able to make requests so easily and without any interaction on the users part leaves services open for attack. As an example say we have an administrators control panel that lets admins delete articles on a website. An attacker might somehow get an admin to visit his website with an image tag on it:

The danger comes when the admin happens to have an active session. If the session is controlled by cookies or IP address etc. then this request will be made with all of the authority of the admin. It would be as if the admin made the request purposefully.

You might be thinking that it would be a simple matter to prevent such an attack by using POST data instead of GET data. If you used POST data then the ID in the URL would not be accepted. While it does create another barrier for a potential attacker (which is always good), it doesn't solve the problem. Consider this code fragment: