def require_once path
    require File.expand_path path
end

And just use “require_once” instead of “require”:

require_once 'lib/file' # loaded
require_once 'lib/file' # not loaded
require_once './lib/file' # not loaded

Django

Para isso, antes de ficar desconectado, baixe a versão desejada do Django na sua máquina, 1.1.1 no meu caso.

$ wget http://www.djangoproject.com/download/1.1.1/tarball/

Descompacte:

$ tar xvf Django-1.1.1.tar

Acesse o diretório da documentação

$ cd Django-1.1.1/docs

Instale o Sphinx, o criador de documentações para projetos Python.

$ sudo easy_install -U Sphinx

* Caso também não tenha o easy_install, instale ele primeiro.

Construa e leia a documentação

$ make html

Abra, através do seu navegador, o arquivo: _build/html/index.html.

Com essa característica, é possível criar estruturas hierárquicas em seus programas, onde alguns processos podem supervisionar outros processos, e manter certo controle. Por exemplo: reiniciar processos terminados por alguma falha.

Basicamente, existem duas formas de monitorar processos em Erlang: utilizando interligações e monitores.

Monitoramento por interligações

Esse tipo de monitoramento é realizado através de processos interligados: os processos a serem monitorados, e o processo que os monitora.

Process1 = spawn(?MODULE, loop, [0]),
spawn(?MODULE, monitor, [Process1])

Aqui, chamamos o nosso processo de Process1, armazenamos o seu Pid, e logo criamos outro processo, que será utilizado para monitorar o processo Process1.

loop(10) ->
    exit(reason_here);

loop(Counter) ->
    timer:sleep(random:uniform(500)),
    loop(Counter + 1).

Temos acima, a função loop/1, que é a responsável pelo processo Process1. A função loop/1 nada mais é do que um contador, que espera um determinado número de milisegundos antes de cada contagem. Ao chegar em 10, ela emite um sinal de erro: reason_here.

Sabendo que o comportamento de um processo em Erlang, em caso de falhas, é: emitir o sinal de erro, através de todos os processos interligados, o que devemos fazer aqui, é interligar o processo do monitor, ao processo Process1. Fazemos isso através da função link/1, como abaixo.

monitor(Pid) ->
    link(Pid).

O que a função link/1 faz aqui é ligar o processo atual, ao processo passado por parâmetro

Agora temos dois processos interligados: o Process1 e o seu monitor, com isso, dizemos que quando o Process1 terminar, ele informará ao processo monitor que ele também deve terminar, pois estão ligados.

Em Erlang, por padrão, quando um processo termina com um motivo diferente de normal, todos os processos interligados a ele devem terminar também, com o mesmo motivo. Mas você pode contornar isso, especificando uma flag no processo.

process_flag(trap_exit, true)

A flag trap_exit, faz com que todos os sinais de saída sejam transformados em mensagens. Assim podemos trata-los.

* Nota: A flag trap_exit não faz efeito caso o sinal de saída tenha o motivo kill. Saídas com o motivo kill fazem com que os processos interligados interminem incondicionalmente.

monitor(Pid) ->
    process_flag(trap_exit, true),
    link(Pid),
    receive
        {'EXIT', Pid, reason_here} ->
            io:format("* process exit: ~p~n", [Pid])
    end.

Agora podemos dizer sim, que o nosso processo monitor está monitorando o processo Process1.

O código completo do módulo de exemplo, ficaria assim:

-module(proc_link).
-compile(export_all).

start() ->
    Process1 = spawn(?MODULE, loop, [0]),
    Process2 = spawn(?MODULE, loop, [0]),
    spawn(?MODULE, monitor, [Process1]),
    spawn(?MODULE, monitor, [Process2]),
    ok.

loop(10) ->
    exit(reason_here);

loop(Counter) ->
    timer:sleep(random:uniform(500)),
    loop(Counter + 1).

monitor(Pid) ->
    io:format("start monitoring: ~p~n", [Pid]),
    process_flag(trap_exit, true),
    link(Pid),
    receive
        {'EXIT', Pid, reason_here} ->
            io:format("* process exit: ~p~n", [Pid])
    end.

Monitoramento através de monitores

A vantagem do monitoramento através de monitores, é que você pode criar, facilmente, vários monitores para um único processo, devido ao fato dos monitores serem unidirecionais.

Ao contrário da função link/1, que chamada repetidas vezes não causará efeito. A função erlang:monitor/2, chamada repetidas vezes, criará uma série de novos monitores, retornando uma referência diferente para cada um deles.

Process = spawn(?MODULE, loop, [0]),
Ref = erlang:monitor(process, Process)

Aqui não é necessário especificar uma flag para o processo, com process_flag(trap_exit, true).

Nesse exemplo, criei um monitor que, ao verificar que determinado processo falhou, o iniciará novamente, e assim monitorando-o novamente também, infinitas vezes.

monitor(Ref) ->
    receive
        {'DOWN', Ref, process, Pid, reason_here} ->
            io:format("- process exit: ~p~n~n", [Pid]),
            NewRef = start_process(),
            monitor(NewRef)
    end.

O código completo do módulo de exemplo, ficaria assim:

-module(proc_monitor).
-compile(export_all).

start() ->
    Ref = start_process(),
    monitor(Ref),
    ok.

start_process() ->
    Process = spawn(?MODULE, loop, [0]),
    Ref = erlang:monitor(process, Process),
    io:format("| started process: ~p~n", [Process]),
    Ref.

loop(10) ->
    exit(reason_here);

loop(Counter) ->
    timer:sleep(random:uniform(1000)),
    loop(Counter + 1).

monitor(Ref) ->
    io:format("| start monitoring process~n"),
    receive
        {'DOWN', Ref, process, Pid, reason_here} ->
            io:format("- process exit: ~p~n~n", [Pid]),
            NewRef = start_process(),
            monitor(NewRef)
    end.

Qualquer módulo pode ser estendido, sem a necessidade de adicionar qualquer atributo a ele, apenas ao módulo que está estendendo-o, vejamos.

-module(test).
-extends(lists).

Veja que nesse caso, criamos um módulo chamado test, que estenderá o módulo lists.

$ erlc test.erl

Compilamos, e temos:

1> lists:sum([2,2]).
4
2> test:sum([2,2]).
4

Agora, indo para um exemplo mais prático, temos um módulo chamado product (produto), que será estendido posteriormente pelo módulo tshirt (camiseta).

-module(product).
-export([new/2, name/1, value/1]).

-include("product.hrl").

new(_, Value) when not is_float(Value) ->
    {badarg, Value};

new(Name, Value) ->
    #product_info{name=Name, value=Value}.

name(#product_info{name=Name}) ->
    Name.

value(#product_info{value=Value}) ->
    Value.

Observe que nesse módulo, exportamos 3 funções:

• new/2 – cria e retorna um novo produto
• name/1 – retorna o nome de um produto
• value/2 – retorna o valor de um produto

Vale notar também, que utilizamos um arquivo externo (product.hrl), que contém informações a serem compartilhadas entre os módulos “filhos”.

-record(product_info, {name, value = 0.0, type = undefined, details = undefined}).
-record(product_details, {sizes, colors}).

Podemos abrir a shell do Erlang para apreciarmos o nosso novo módulo:

$ erl

1> c(product).
{ok,product}
2> Produto = product:new("Camiseta", 20,0).
{product_info,"Camiseta",20.0,undefined,undefined}
3> product:name(Produto).
"Camiseta"
4> product:value(Produto).
20.0

Até aqui, o que temos é um registro de um produto genérico, sem detalhes. Para adicionarmos mais detalhes a esse produto, sugiro estender esse módulo, adicionando tais detalhes.

Pode-se ver que já foram reservados 2 espaços no registro do produto, preenchidos por padrão com o valor undefined.

{product_info,"Camiseta",20.0,undefined,undefined}

Ambos serão preenchidos com os respectivos valores: type (tipo) e details (detalhes).

Criamos então um novo módulo, chamado tshirt (camiseta), que estende o módulo product (produto).

-module(tshirt)
-export([new/4,sizes/1,colors/1]).

-extends(product).

-include("product.hrl").

-define(base, ?BASE_MODULE).

new(Name, Value, Sizes, Colors) ->
    case ?base:new(Name, Value) of
        {badarg, _} = Fail ->
            Fail;
        Product ->
            Details = #product_details
            {
                sizes=Sizes,
                colors=Colors
            },
            Product#product_info{type=tshirt,details=Details}
    end.

sizes(#product_info{details=#product_details{sizes=Sizes}}) ->
    Sizes.

colors(#product_info{details=#product_details{colors=Colors}}) ->
    Colors.

Aqui, defini um macro para facilitar o desenvolvimento, chamado base, que nada mais é que um atalho para outro macro chamado BASE_MODULE.

Prosseguindo, sobrecarreguei a função new/1 do módulo product, adicionando o tipo do produto, e alguns detalhes como sizes (tamanhos) e colors (cores).

1> c(tshirt).
{ok,tshirt}
2> Camiseta = tshirt:new("Camiseta", foo, [small, large], [black, white]).
{badarg, foo}
3> f(Camiseta). % limpar a variável, já que já foi utilizada.
ok
4> Camiseta = tshirt:new("Camiseta", 15.90, [small, large], [black, white]).
{product_info,"Camiseta",15.9,tshirt,
              {product_details,[small,large],[black,white]}
5> tshirt:name(Camiseta).
"Camiseta"
6> tshirt:sizes(Camiseta).
[small,large]
7> tshirt:colors(Camiseta).
[black,white]
8> tshirt:value(Camiseta).
15.9

Se quiser praticar um pouco mais, que tal criar outro módulo? Outro tipo de produto? Boa prática.

O PHP faz isso a um bom tempo já, e um bom exemplo é a função error_reporting, onde podemos utilizar uma série de regras para denominar quais os erros devem ser reportados.

error_reporting(E_ERROR | E_WARNING);

No exemplo acima, foi denominado que somente os tipos de erro E_ERROR e E_WARNING devem ser reportados. Se quiséssemos que o tipo de erro E_PARSE fosse reportado também, bastariamos adiciona-lo na regra:

error_reporting(E_ERROR | E_WARNING | E_PARSE);

Mas como isso funciona?

Utilizando como exemplo, essas contantes do PHP contém os seguintes valores:

E_ERROR		1
E_WARNING	2
E_PARSE		4

O operador | é uma operação “Or” inclusiva, o que indica que, todo bit que estiver presente em A ou B, será utilizado.

0001 ou
0010
=
0011

Podemos verificar o valor em binário de cada uma das constantes, utilizando a função printf:

$ php -r 'printf("%04b", E_ERROR);'
0001
$ php -r 'printf("%04b", E_WARNING);'
0010
$ php -r 'printf("%04b", E_PARSE);'
0100

Portanto, voltando ao exemplo inicial da função error_reporting, temos:

E_ERROR | E_WARNING

E se fizermos a operação, obteremos 0011, vejamos:

$ php -r 'printf("%04b", E_ERROR | E_WARNING);'
0011

E como verificamos se E_ERROR esta contido em E_ERROR | E_WARNING?

Simples. Basta utilizar o operador &, que realiza uma operação “And”, onde somente são utilizados os bits presentes em A e B.

(E_ERROR | E_WARNING) & E_ERROR

Traduzindo em bits, ficaria:

0011 e
0001
=
0001

Veja que o resultado tem o mesmo valor de B, e é assim que funciona, basta comparar E_ERROR com o resultado de (E_ERROR | E_WARNING) & E_ERROR.

Agora em PHP, já que um exemplo vale mais que mil palavras:

if (E_ERROR == ((E_ERROR | E_WARNING) & E_ERROR))
{
	echo 'E_ERROR presente nas regras';
}

Criando a sua própria série de regras

Imagine uma situação, onde você possui um sistema com vários usuários, e cada usuário pode conter as permissões P_READ (leitura), P_WRITE (escrita), P_REMOVE (remoção).

Criamos então, uma permissão “base”, chamada P_NONE (nada).

define('P_NONE',	100);

E em seguida, as outras permissões:

define('P_READ',	P_NONE << 1);
define('P_WRITE',	P_NONE << 2);
define('P_REMOVE',	P_NONE << 3);

Logo, podemos criar uma regra para um usuário:

$mode = P_READ | P_WRITE;

E armazena-la em um banco de dados. Aqui utilizei um campo int, em um banco de dados MySQL.

mysql_query("update users set mode = $mode where id = $id");

Posteriormente, você pode listar os usuários que tem permissão para escrita:

$mode = P_WRITE;
$users = mysql_query("select * from users where (mode & $mode) = $mode");

Para verificar com PHP:

if (P_READ == ($user->mode & P_READ))
{
	echo 'Este usuário possui permissão para leitura.';
}

Conclusão

Você pode especificar várias e várias regras, utilizando apenas um valor, uma variável ou um campo no banco de dados. Basta utilizar alguns bits e operações lógicas.

Para maiores informações sobre os Bitwise Operators do PHP, basta acessar a URL:

http://br2.php.net/language.operators.bitwise

servidor

Repositório local

Crie um repositório local normalmente, caso já tenha, pule esta etapa.

$ mkdir meusite.com.br
$ cd meusite.com.br

$ git init

Repositório remoto

Neste exemplo, vou utilizar a estrutura que o Plesk utiliza para aos domínios.

Precisamos de uma pasta que fique fora de visibilidade da web, portanto, utilizarei a pasta private, que fica na raiz do domínio.

$ cd /var/www/vhosts/meusite.com.br/private

Criamos a pasta do repositório:

$ mkdir meusite.git/
$ cd meusite.git/

Iniciamos um repositório “crú” no mesmo local:

$ git --bare init

E então configuramos o Git com as seguintes opções:

$ git config core.worktree /var/www/vhosts/meusite.com.br/httpdocs
$ git config core.bare false
$ git config receive.denycurrentbranch ignore

Configuramos também o Hook que será executado após toda atualização:

$ cat > hooks/post-receive
#!/bin/bash
SITE_PATH=/var/www/vhosts/meusite.com.br

cd $SITE_PATH/httpdocs
git --work-tree=. --git-dir=$SITE_PATH/private/meusite.git checkout -f

E colocamos permissão para execução:

$ chmod +x hooks/post-receive

Processo de atualização

O processo para atualização é bem simples. Primeiro criamos outro “master” branch, chamado “web”.

$ git remote add web ssh://meusite@servidor.com.br/var/www/vhosts/meusite.com.br/private/meusite.git

Em seguida, realize qualquer alteração:

$ echo "funcionou!" > teste.html
$ git commit -am 'teste'

$ git push web +master:refs/heads/master

Tente acessar: http://meusite.com.br/teste.html

Após isso, você pode atualizar somente com “git push web”, configurando:

$ git config push.default current

Quaisquer dúvidas sobre o Git, podem ser retiradas através do canal #git na irc.freenode.net.

Este material foi baseado no Using Git to manage a web site.

A explicação demonstra como requisitar links, como criar uma página de erro personalizada, e como utilizar o seu domínio para acessa-los.

Porém não há limites. Basta usar o seu conhecimento junto da sua criatividade para criar o seu próprio encurtador, sem maiores preocupações.

Faça o download do código completo.

Vamos tomar como exemplo o seguinte cenário:

Você possui um blog ou uma agência digital, e quer espalhar os seus links através de um domínio próprio, no qual os seus clientes confiem meramente, e que não tenham medo de acessar achando que é algum vírus.

Neste tutorial, teremos 4 arquivos:

.htaccess

Para melhor o “visual” das URL’s

307.class.php
Classe para manipulação de links do 307.to

shorturl.php
Onde utilizamos a classe do 307.to

404.php
Página de erro personalizada

A classe do 307

A classe class307 possui os seguintes métodos:

public function set_format($format)

Específica o formato do retorno, podendo ser json ou text.

public function set_account_key($key)

Específica a chave da sua conta.

public function get($u)

Requisita um link.

public function post($u)

Cria um link, se account_key for específicado o link será anexado a sua conta.

Utilizando a classe

Esse é o script principal do sistema, onde é utilizada a classe do 307 para requisitar os links.

Como você pode ver abaixo, o método set_account_key foi comentado para fins de demonstração, porém ele é extremamente importante, pois permita que somente os links criados por você possam ser acessados através do seu domínio.

<?php

require '307.class.php';

$class307 = new class307;
// optional
//$class307->set_account_key('<YOUR ACCOUNT KEY>');

try
{
	if (is_array($_GET['link']) || empty($_GET['link']))
	{
		throw new Exception();
	}

	$link = $_GET['link'];
	$url = $class307->get($link);

	//header('Location: ' . $url, TRUE, 307);
	header('Location: http://307.to/' . $link);
}
catch (Exception $error)
{
	include '404.php';
}

Indo logo para a parte mais importante do código, verificamos se a variável “link” é do tipo Array ou se esta vazia. Caso um dos dois casos ocorra, geramos uma exceção.

if (is_array($_GET['link']) || empty($_GET['link']))
{
...
}

Logo depois, requisitamos o endereço através do método get:

$url = $class307->get($link);

Caso o link não exista, o método get gerará uma exceção, caso contrário continuará a execução.

Veja que ocorrendo alguma exceção, o arquivo 404.php será chamado e logo em seguida a execução terminará.

Utilizando a URL retornada

Se o método get conseguir encontrar a URL, ela será armazenada na variável $url, no script de exemplo, eu somente utilizei o método get para verificar se o link existe ou não, e então redirecionei para a página do próprio 307.to onde serão geradas estatísticas de acesso e tudo mais. Mas nada impede que você faça a sua própria coleta de estatísticas e então redirecione o usuário para a página final.

Testando o script

Para testar o script, basta realizar as seguintes requisições:

http://seusite.com.br/shorturl.php?link=rG

e

http://seusite.com.br/shorturl.php?link=ESSE_LINK_NAO_EXISTE

Veja que a primeira requisição irá redirecionar para http://307.to/rG, enquanto a segunda exibirá uma página de erro (404.php).

Personalizando a URL (Escondendo o shorturl.php)

Para encurtar o link, você pode usar algumas regras no .htaccess, que permitem que você esconda o nome do arquivo, no caso “shorturl.php”.

.htaccess

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ shorturl.php?link=$1

Agora para acessar o seu link, basta requisitar o endereço:

http://seusite.com.br/rG

Personalizando a página de erro (404.php)

Para personalizar a página de erro, basta ter um pouco de conhecimento de HTML:

404.php

<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
</head>
<body>

<h1>Erro - Link não encontrado</h1>

<em>
<?php
printf('%d - %s', $error->getCode(), $error->getMessage());
?>
</em>

</body>
</html>

Download do código

Para fazer o download do código completo citado, basta clicar no link abaixo:

Download

Um Overlay é uma árvore separada da árvore principal de pacotes do Gentoo, mantida por terceiros.

O Overlay onde o emesene esta disponível, chama-se dottout, e requer a instalação do git.

Portanto, primeiramente instale o git:

# emerge dev-util/git

* Vá tomar um cafézinho, pois demora um pouco!

Depois do café, adicione o Overlay, através do layman:

# layman -a dottout

Depois disso, antes de instalar o emesene, é preciso satisfazer uma dependência, que é a libmimic.

Crie o arquivo /etc/portage/package.keywords/libmimic, especificando a arquitetura da sua máquina, no meu caso “~x86″:

# cat >/etc/portage/package.keywords/libmimic
media-libs/libmimic ~x86

E em seguida dê emerge:

# emerge media-libs/libmimic

Após a instalação, especifique também a arquitetura da sua máquina para a instalação do emesene:

# cat >/etc/portage/package.keywords/emesene
net-im/emesene ~x86

E então, dê emerge:

# emerge emesene

Vá até o diretório do emesene, normalmente localizado em /usr/share/emesene, e execute o setup.py:

# cd /usr/share/emesene
# python setup.py build_ext -i

emesene instalado!

* Lembre-se, o emesene não roda como usuário root.

Primeiramente, baixe e instale o Subversion.

Caso você utilize Ubuntu/Linux, Debian, ou alguma distribuição parecida, você pode instalar através do terminal, usando o comando:

sudo apt-get install subversion

Caso você utilize outra distribuição, ou Windows, mais informações para download estão disponíveis em http://subversion.tigris.org/getting.html#binary-packages

Após a instalação

Após instalar o Subversion, caso esteja no Linux, abra o terminal.

Caso esteja no Windows, vá em Iniciar > Executar, digite “cmd” e execute.

Crie uma pasta, no lugar que desejar. Aqui eu optei por ~/kohana.

Esta é a pasta onde você baixará os arquivos do site do Kohana, para fazer isso, vá até a pasta e execute o comando abaixo:

svn co http://source.kohanaphp.com/branches/website/application kohana-website

Esse comando baixará somente a pasta application, pois fora dela, não há conteúdo a ser traduzido.

Após o término, você terá os arquivos em sua máquina.

Realizando o primeiro Patch

O Patch, ou Correção, nada mais é que a diferença entre o arquivo antigo e o novo (modificado).

Portanto, você irá modificar o arquivo em questão, e realizar o patch através do SVN mesmo. Ele possui uma ferramenta que faz isso.

Para montar esse Mini How To, eu realizarei um patch, no arquivo: i18n/pt_BR/layout.php

Realizei algumas alterações no arquivo, comparando com a versão atual em inglês i18n/en_US/layout.php, adicionei duas traduções que faltavam: menu_redmine e menu_projects.

Após isso, é bastante simples. Somente fui até a pasta, através do terminal e gerei o patch, com o comando:

svn diff i18n/pt_BR/layout.php > patch_i18n_pt_BR_layout.patch

Eu acho importante manter uma padronização no nome dos patches.

Finalizando, envio do Patch

Foi criado um Ticket no site do Kohana, onde devem ser adicionados os patches, para isso basta se cadastrar no site, ir até o Ticket e enviar o arquivo.

O Ticket criado para isso, foi o #1799.

Espero que esse documento seja de bastante utilidade, e que todos consigam compreender bem.

PHP

O que são Hooks?

Hooks são arquivos que são carregados na inicialização do Kohana, permitindo você adicionar ou modificar funções, chamadas callbacks, que são disparadas pelo Kohana.

Essas funções (ou callbacks) são colocados em uma lista dentro do seu evento específico, chamada Event Queue.

O que são Eventos?

Durante a inicialização, e até mesmo durante a execução, em alguns casos, o núcleo do Kohana dispara vários eventos. Eventos que são definidos pelo próprio núcleo.

Você pode ver a lista completa de eventos disparados pelo Kohana, na documentação: http://docs.kohanaphp.com/general/events

Habilitando os Hooks no Kohana

Para começar a brincar com os Hooks, é necessário habilitá-los. Para isso, basta configurar a opção enable_hooks no config/config.php, para TRUE:

$config['enable_hooks'] = TRUE;

Exemplo de utilização de Hooks

Suponha que tenhamos um site com sistema de autenticação.

Quando um visitante chega, ele é logo direcionado ao controller padrão, definido em config/routes.php, pela seguinte linha:

$config['_default'] = 'site';

O controller site, contém os métodos (páginas): Home (com formulário de autenticação), Quem Somos, Ajuda…

Agora, o que fazer quando este visitante já estava autenticado anteriormente, e retorna ao site?

A solução mais simples a se fazer, é criar uma verificação no controller site, e caso o usuário já esteja autenticado ele será redirecionado à outro controller, chamado painel.

Problema

A cada redirecionamento do controller site ao controller painel, seria realizado outra inicialização do sistema completo.

Solução

Uma solução elegante e correta para isso, é utilizar um Hook para informar ao Router, o controller correto a ser chamado.

O Router é quem define através da URL, qual controller deverá ser chamado, portanto a única coisa que terá de ser feita, é dizer à ele qual controller ele deverá chamar.

Criamos então, o arquivo hooks/site.php, o nome não importa, a não ser por fácil identificação posteriormente.

No arquivo, é especificado que no momento do evento system.routing, uma função (leia-se callback) será chamada, antes do Router::setup.

Esse callback definirá o controller correto à ser carregado.

<?php defined('SYSPATH') OR die('No direct access allowed.');

function hook_define_controller_padrao()
{
	if (!empty(Router::$current_uri)) return;
	if (Session::instance()->get('user'))
		// usuário logado
		Router::$current_uri = 'painel';
}

Você pode também impossibilitar o acesso à página de autenticação, quando o usuário já estiver autenticado, modificação a função callback acima, da seguinte forma:

function hook_define_controller_padrao()
{
	$logado = Session::instance()->get('user');
	if (empty(Router::$current_uri) && $logado)
		// usuário autenticado
		Router::$current_uri = 'painel';
	elseif (Router::$current_uri == 'site/login' && $logado)
		// exibir "página não encontrada"
		Event::run('system.404');
}

Criada a função, é necessário que seja adicionada à lista de eventos a serem realizados, isso pode ser feito logo abaixo da função, ou no final do arquivo Hook.

Event::add_before(
	'system.routing',
	array('Router', 'setup'),
	'hook_define_controller_padrao'
);

Existe também como definir novos eventos, mas isso fica para outro artigo, pois este é somente uma introdução sobre o assunto.

Utilize os Hooks sempre que possível, eles poderão reduzir inúmeras linhas no seu código, tornando-o mais enxuto, legível e organizado.