This class allows lazy loading of classes upon request. This will in place prevent you from having to manually include the files that you will need in your application.

To use the autoloader you have to first include the file and then create an instance of it. This will usually be done in your bootstrapping class.

1
2
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();

Once your autoloader is ready you can use any class you need without having to manually include the file it belongs to. For example, if after calling autoloader you had this line of code:

1
$frontController = Zend_Controller_Front::getInstance();

Zend framework will replace underscores (_) with directory separators (/) and look for the file Zend/Controller/Front in your include path(get_include_path()), if the file is found it will be loaded, if it is not found an error will be issued.

In most of the Internet applications there is a need to have a configuration file to store static information that the application needs to work. An very common example of this information is credentials to connect to a database.

There are a lot of ways you can store this information and make it accessible to the application. Zend framework includes four classes for parsing four different kind of configuration files: Zend_Config_Ini, Zend_Config_Json, Zend_Config_Xml and Zend_Config_Yaml. In this article we will focus on Zend_Config_Ini for parsing files in the INI format.

When I first saw this programming pattern I found very difficult to understand why would people want to make their code so confusing. When I finally understood why this is used I knew I had to write about it someday. Today is that day.

Self executing functions are useful because using them you avoid creating global variables that could interfere with other parts of your code.

To understand this better I will give three examples of how you pollute and avoid the pollution of the global space.

For the ones of you who didn’t know (I didn’t know either), Apache has a limit on the number of back references you can use when rewriting a URL.

For the people who don’t know I will explain what is a back reference when talking about apache rewrites.

When you do a rewrite of a URL using apache mod_rewrite you translate a URL into an actual resource that apache can find.

For my examples I will use the domain http://ncona.com. If I wanted that the URL http://ncona.com/file loaded the file other_file.html located in my web root I would use a rule like this one:

1
RewriteRule ^file$ /other_file.php

That is a static rewrite but you can also use back reference to make dynamic URLs:

1
RewriteRule ^product/([0-9]+)$ /product_details.php?id=$1

XSLT (Extensible Stylesheet Language Transformations) is a language used to transform XML documents. It is mostly used to transform an XML document into a different XML document with a different XML Schema.

XHTML (eXtensible HyperText Markup Language) is an XML version of the HTML markup language. It was created so websites could be parsed using standard XML processors instead of having to depend on specific HTML processors.

The problem

So far everything sounds good, but there are some problems. Following the standard you should be able (as a matter of fact you must) to send an XHTML document to the browser with a mime type of “application/xhtml+xml”. The problem here is that some browsers (IE) don’t understand that mime type and thus don’t render your document.

Git hooks

From git documentation:

Hooks are little scripts you can place in $GIT_DIR/hooks directory to trigger action at certain points. When git-init is run, a handful example hooks are copied in the hooks directory of the new repository, but by default they are all disabled. To enable a hook, make it executable with chmod +x.

If you take a look at your .git/hooks folder you will probably see a bunch of hooks created by default. In my current version of git all my hooks have a .sample extension. To make a hook executable you must remove .sample and make it executable. If you don’t want to remove the default example you can create a new file without .sample.

This post is basically a copy of pimping out git log. I just made some modifications to Bart’s alias to fit my personal preferences.

This code creates an alias named lg for the git:

1
git config --global alias.lg "log --graph --pretty=format:'%Cred%h -%C(yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)<%an>'"

Here is an explanation of what that command does:

1
git config --global alias.lg "..."

It has happened to me more than once that I make a commit without verifying the changes I am committing. Time after that I review the commit and I notice that there is something in the commit that doesn’t belong there.

In those times what I want to do is make a patch with the changes of the commit, delete the commit, apply the patch and then redo the commit only with the changes I intended. In this post I will only explain how to delete a commit in your local repository and in a remote repository in case you have already pushed the commit.

Once you have created an extension, you will probably want to make it easily available to the public.

For my tntfixer extension that I explained in some previous posts I had a folder structure similar to this one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/tntfixer
|----chrome.manifest
|----install.rdf
|----README
|----/chrome
|    |----/content
|    |    |----tntfixer.js
|    |    |----tntfixer.xul
|    |
|    |----/skin
|    |    |----overlay.css
|    |    |----/images
|    |    |    |----status-bar-icon-active.png
|    |    |    |----status-bar-icon-inactive.png

If you have sent e-mails in a different language than English or using characters outside the ASCII range you have probably already used utf8 to send them.

Specifying the use of UTF-8 in the body of an e-mail is very similar to doing it for a HTTP response. You can specify the content-type in an e-mail header like this:

1
Content-Type: text/plain; charset=utf-8

But there is catch. The subject line of an e-mail is a header by itself, and headers must contain only ASCII characters. Happily, there is a work around. RFC 1342 is a recommendation that provides a way to represent non ASCII characters inside e-mail headers in a way that won’t confuse e-mail servers.