Todo mundo que trabalha com a biblioteca jQuery conhece a chamada:

$(document).ready({
//seu código javascript
});

Ela diz ao browser para executar o bloco interno somente quando o DOM do seu documento tiver sido totalmente carregado, isso permite que ele faça o parser de seu documento utilizando os seletores sem esquecer de nenhum item. Porém quando carregamos estruturas externas ao DOM, como uma imagem, não temos garantia de que o código dentro do bloco anterior será executado quando a imagem já tiver sido carregada.
Dessa maneira, caso você precise de informações sobre a imagem, seu script falhará.

Para contornar isso, podemos utilizar uma outra chamada, que é disparada somente quando TODO o documento tiver sido carregado:

$(window).load({
//seu código javascript
});

As duas diferenças, além do comportamento são:

1. Saí o ‘seletor’ document para a entrada do window;
2. Saí o evento ready para a entrada do load;

A primeira alteração ocorre por conta da segunda, já que o evento load não pode ser associado a um document.

Com essa pequena alteração você garante que seu script rodará apenas quando todo o documento tiver sido carregado – o que é essencial em algumas situações, como a citada anteriormente, porém dispensável na maioria das vezes.

Fonte: http://api.jquery.com/load-event/

Acontece que após a adição de uma nova funcionalidade (submissão de trabalhos) aquele sistema de permissão começou a ficar ineficiente, e apesar de eu ter dito nos comentários que o ideal era implementar o Acl para este controle no sistema, acabei por implementar a solução sugerida pelo grande Humberto – que, tomando como ponto inicial o que tínhamos, era o jeito mais simples de solucionar os problemas.

Então o que mudou?

• Os usuários não possuem mais um “tipo”, agora eles pertencem a “grupos” (um ou mais);
• A verificação de permissão é feita na classe AppController, de forma genérica, o que elimina a necessidade de reescrever a função de autorização a cada controlador;
• Os grupos que um usuário pertence ficam definidos em um campo “groups”, do tipo varchar e são guardados codificados no formato json
• Defini um método protegido no AppController para verificar se o usuário logado pertence a um grupo qualquer, facilitando essa operação quando necessário. (o método chama-se AppController::__checkGroup($string) )

O que não mudou?

• As ações continuam tendo como prefixo o grupo que pode acessa-la, sendo assim, a ação ProposalsController::participant_add() está disponível a todos os usuários que pertençam ao grupo “participant”
• Todos os usuários registrados pertencem inicialmente ao grupo ‘participant’, porém podem vir a pertencer a outros grupos posteriormente (em adição ao grupo ‘participant’)
• Continua sendo muito fácil saber se o  usuário logado pode ou não efetuar uma ação, basta usar o método supracitado __checkGroup.

Exemplo de como verificar se o usuário é administrador

if($this->__checkGroup('admin'))
    echo 'O usuário logado é administrador';
else
    echo 'O usuário logado não é administrador';

Mas o objetivo deste post não é dizer o que já foi dito, quero iniciar uma série de posts onde vou explicar o funcionamento de alguns recursos dentro do Comitiva, convidando todos os desenvolvedores a opinar sobre implementação e contribuir com o projeto.

O assunto de hoje é controle de acesso, então vamos ao que interessa.

Como funciona o controle de acesso no Comitiva?

Utilizamos o componente Auth do CakePHP para cuidar da autenticação (efetuar login, verificar se o usuário está logado e efetuar logout).
Mas precisávamos ir um pouco além da configuração básica, definindo diferentes opções para diferentes tipos de usuários. Para isso, consideramos duas opções iniciais: usar também o Acl Behavior ou ficar apenas com o AuthComponent e criar diferentes actions para diferentes tipos de usuários.

Como possuímos apenas dois tipos de usuários (admin e participant) decidimos pela que seria mais simples inicialmente – mesmo sabendo que a manutenção no futuro poderia ser mais complicada – que foi criar diferentes actions para os tipos de usuários.

Para criar essa funcionalidade, definimos inicialmente um prefixo para cada tipo de usuário (prefixos ‘admin‘ e ‘participant‘). Em seguida configuramos o AuthComponent desta maneira (código extraído do AppController):

//Configure AuthComponent
$this->Auth->authorize = 'controller';
 
if( !isset($this->params['prefix']) || !( in_array($this->params['prefix'], Configure::read('Routing.prefixes')) ) )
{
	// all non-prefixed actions are allowed
	$this->Auth->allow('*');
}

Ou seja, toda ação que não tiver prefixo ou o prefixo não estiver definido nas configurações de rota serão públicas (assim é possível, por exemplo, deixar uma página com instruções acessível à qualquer usuário).

Mas como fica essa verificação de tipos no controlador? Como definimos o método de autorização do Auth como ‘controller’, precisamos definir em todos os controladores o método isAuthorized que deve retornar true quando o acesso é aprovado e false caso contrário.
Seguindo a ideia de que cada tipo de usuário possui um prefixo próprio nas ações, nosso método isAuthorized fica desta forma:

if($this->userLogged == TRUE && $this->params['prefix'] == User::get('type'))
{
	return true;
}
 
return false;

Onde o atributo $this->userLogged pertence a classe AppController e sua função é reduzir chamada ao método $Auth->login() e na segunda parte da condição temos uma comparação entre o prefixo da url acessada e o tipo do usuário – se ambos forem iguais, então o acesso está liberado.

Por fim, devemos criar nossas ações para cada tipo de usuário, onde o prefixo será usado para validar o acesso à aquela ação, veja o exemplo da ação “listar pagamentos”:

// ação exclusiva para admin - tem acesso aos pagamentos de todos os outros usuários
public function admin_index($event_id = null)
{
	$this->Subscription->recursive = 0;
 
	if(is_numeric($event_id))
	{
		$this->paginate = array(
			'conditions' => array(
				'event_id' => $event_id
			)
		);
	}
 
	$this->set(compact('event_id'));
	$this->set('subscriptions', $this->paginate());
}
 
// ação exclusiva para participant - tem acesso somente aos próprios pagamentos
public function participant_index()
{
	$this->Subscription->recursive = 0;
	$this->set('subscriptions', $this->paginate(array('user_id' => User::get('id'))));
}

Como podem ver, isso permite a criação de diferentes regras de negócio para os diferentes tipos de usuários e embora aumente a quantidade de código “redundante” por repetir alguns procedimentos para todos os tipos de usuários, a leitura e entendimento do código é facilitada – basta ver o prefixo do método (ação) para saber quem terá acesso a ele.

No lado do restaurante, o serviço cria mais um canal de venda sem a necessidade de se investir um grande volume de dinheiro para criar um e-commerce.

O serviço é resultado de uma parceria entre a Radig (onde tenho prazer em trabalhar) e dois grandes amigos, Samuel e Habib.

Faça uma visita, cadastre-se e peça sua comida preferida com todo o conforto que a internet lhe oferece.

Não deixe de seguir o Delivery Fácil no twitter para acompanhar as novidades e promoções que realizarmos: @deliveryfacil

Porém os anos passaram e algumas coisas começaram a fazer falta: como faço quando estou desenvolvendo algo grande, fico sem commitar até ter algo estável/usável? crio um branch para isso? mas e depois para unir os branches, e os conflitos? além disso, se só eu estou trabalhando em cima disso, porque commitar para todo mundo algo não pronto?

Foi aí que descobri o GIT, um sistema de controle de versão distribuído, open source e gratuito. Ok, ele é gratuito e open source, mas isso não é motivo suficiente. Como disse, ele é um sistema de controle de versão distribuído, isso quer dizer que cada um que tem uma cópia do repositório tem de fato uma cópia dele, e pode servir outras pessoas, ver histórico, tudo localmente.

Então de quebra, ele resolve o problema de ter de criar um branch para desenvolver uma funcionalidade que só eu vou mexer, posso controlar cada alteração minha localmente, e quando quiser – se quiser – posso sincronizar meu repositório local com um outro central (que eu considero central, já que essa figura não existe no GIT). E mais, ele é MUITO RÁPIDO. Acho que para ajudar na argumentação de que é rápido basta dizer que ele foi feito por alguns desenvolvedores do Kernel Linux, e gerencia todo o código trabalhado por eles – e não é pouca coisa.

Ainda estou caminhando com o GIT, tenho aproveitado minha ânsia de aprende-lo junto com a de contribuir com softwares open source para criar e disponibilizar projetos no GitHub.

A grande maioria dos projetos é voltado ao CakePHP, mas há outras coisas também. Alguns projetos que podem interessar são:

• Comitiva – Sistema construído em CakePHP 1.3 para gerenciamento de eventos;
• Plugin Mailer – Um plugin que ajuda na utilização da biblioteca PHP SwiftMailer dentro do CakePHP;
• Behavior Locale – Um behavior para transformar dados vindo do usuário de seu padrão local para um padrão internacional (de banco de dados)
• Libs – uma coleção de pequenos scripts PHP que fui fazendo ao longo da vida. Há coisas boas, coisas úteis, coisas não tão úteis, mas tudo pode ser usado ao menos como ponto inicial para uma implementação mais elaborada.

Em nosso caso, cada prefixo representa um tipo de usuário.

A ideia ia bem, até termos que criar um link explicitando uma rota.

Por padrão, a classe Router reconhece o prefixo em uso no momento e adiciona ele na url que você está construindo, desta forma se eu estiver acessando um endereço http://comitiva/participant/events  e quiser criar um link para a url http://comitiva/admin/users  eu terei um problema (não documentado): a segunda url ficaria http://comitiva/partipant/users , por causa da página que está ativa no momento.

A solução foi me apresentada no IRC, canal #cakephp-pt pelo padeiro Danielpk: adicione um índice com o nome do prefixo associado ao valor TRUE no array de endereço.  Fica algo assim:

$this->Html->link('Administre os usuários', array('controller' => 'users', 'action' => 'index', 'admin' => true));
// ou, caso queira forçar o prefixo participant
$this->Html->link('Veja os usuários', array('controller' => 'users', 'action' => 'index', 'participant' => true));

Como comentei no post anterior, dessa vez minha participação foi focada em um ponto: criar uma solução para gerenciar as inscrições do evento.

Dessa necessidade surgiu o Comitiva, um sistema de gerenciamento de eventos, que nasceu a pouco e já passou pela sua primeira prova de teste (o próprio workshop).

No momento ele pode ser usado para cadastrar um evento, permitir que usuários se cadastrem e se inscrevam nos eventos cadastrados, mas vários outros recursos já estão em andamento.

A parte boa é que o sistema é livre – sim, open source, é gratuito e feito em CakePHP 1.3. Estamos utilizando o Github para gerenciar o código e hoje criei uma conta no LighthouseApp para gerenciar as tarefas. Aliás, queria agradecer e recomendar ambos os serviços que suportam, sem custos, projetos open source. Valeu =]

Veja um demo na versão instalada para o PHPMS: http://comitiva.phpms.org

Bom, como uma andorinha só não faz verão, o Comitiva contou com alguns colaboradores/apoiadores que gostaria de citar e agradecer aqui:

Zé Agripino: fez boa parte do trabalho sujo, hehehe. Criar as views, traduzir textos, corrigir bugs. Ajudou em todo o sistema, é O cara;
Felipe V. Rigo: começando a trabalhar com CakePHP agora, apanhou um pouco para conseguir rodar o sistema em sua máquina, mas graças a isso e sua persistência descobrimos e corrigimos vários bugs do sistema;
José Ricardo: estava ocupado no inicio do projeto, porém após o workshop ficou animadão e já fez algumas contribuições importantes, como a configuração do Migrations para o sistema;
Bruno Porkaria: também estava bem corrido e cuidando de outras coisas do workshop, mas testou bastante o sistema e teve a paciência de reportar problemas e sugestões sempre que estas apareciam.

É isso aí, espero trazer mais novidades em breve, principalmente sobre o projeto =]

Para quem me acompanha há algum tempo, sabe que participo do grupo e sempre ajudo de alguma forma no evento, dessa vez não seria diferente.
O evento terá 4 excelentes palestras, sendo duas de nossa celebridade convidada, Guilherme Blanco.

Tenho ajudado bastante no desenvolvimento de uma ferramenta para a gestão de eventos do grupo, que terá seu código liberado tão breve quanto fique pronto (ou seja, sem data, mas não deve demorar muito, hehehe). O nome dele é Comitiva.

Confira abaixo o release oficial:

O 3° Workshop do PHPMS será realizado no dia 27 de março no SENAC/MS, das 08:30 até 17:50. O evento vai contar com a presença de Guilherme Blanco que hoje trabalha na empresa sul-africana MIH/SWAT, desenvolvedor do core do projeto Doctrine, bem como nas frameworks Zend e Symfony. Ele vai apresentar duas palestras, “Overview do Doctrine 2.0″ e “Usando o Doctrine 2.0 com Zend Framework 1.10″.

Vamos ter também duas palestras sobre WordPress, a ferramenta de blog mais usada no mundo, Flávio Ricardo irá apresentar o tema “Gerenciando blogs e websites de forma flexível com WordPress MU” e em seguida Gabriel Novaes aborda o tema “WordPress SEO: Práticas e plugins para robos de busca”.

Sem falar na tradicional mesa-redonda para debater assuntos de interesse da comunidade de desenvolvedores PHP do estado, que vem nesse workshop com o tema “Perfil do programador PHP no estado de MS”.

Informações para inscrição no evento, grade completa, você encontra no hotsite do evento http://www.phpms.org/workshop/

Desde o primeiro momento fiquei pensando em como fazer meu notebook e sua placa de video NVidia 8400M trabalhar com a tela de 1440×900 do notebook juntamente com a tela de 1920×1080 do monitor, sem perda de perfomance.

Por quase um ano utilizei os dois em conjunto abrindo mão da aceleração de hardware (efeitos 3d, performance e etc), acreditando que esta era a única maneira. Qual era minha configuração? Eu usava o Xinerama do X.org, e neste caso, não há aceleração por hardware. Aliás, pelo que me parece é uma tecnologia abandonada e defasada.

Depois de várias pesquisas e tentativas, achei uma configuração ideal, trocando o Xinerama pelo Twinview e XRand. Agora tenho aceleração de hardware, detecção de resolução e não preciso me preocupar ao utilizar só a tela do notebook (antes precisava editar o xorg.conf para ajustar a resolução).

Para quem estiver na mesma situação, aqui está meu xorg.conf

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Samsung"
    ModelName      "Samsung SyncMaster"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 60.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8400M GS"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "1"
    Option         "TwinViewOrientation" "RightOf"
    Option         "metamodes" "CRT: 1920x1080, DFP: 1440x900; CRT: NULL  DFP: 1440x900; CRT: 1280x720, DFP: 1440x900"
    SubSection     "Display"
        Depth       24
        Modes       "3360x1080" "2720x900"  "1920x1080" "1440x900" "1280x720"
    EndSubSection
EndSection

Bom, a conclusão que tirei do comparativo foi de que a velocidade de execução é importante, mas mais do que isso, o programador é essencial. No exemplo da thread supracitada, o PHP perdia feio para as outras linguagens, mas olhando para o código escrito em PHP, dava para notar  vários erros de uso da linguagem e suas funções (ponto para o Begnini que viu o código antes de todos).

Então a dica de hoje é: estude bem a linguagem. Procure a saber o funcionamento das funções e construções da linguagem, isso é essencial para se tornar um bom programador.

Exemplos de código

//uso comum
for($i = 0; count($var) < 0; $i++)
  ...
 
//forma mais adequada
for($i = 0, $c = count($var); $c < 0; ++$i)
 ...
 
//outro caso, ao invés de forçar várias verificações
if( $a > 100 )
 ...
if( $a < 100 )
 ...
if( $a == 100 )
 
//use a estrutura adequada
if( $a > 100 )
 ...
else if( $a < 100 )
 ...
else //não precisa fazer o último teste
 ...
 
// esse último caso que me inspirou a fazer o post
 
// a pessoa só queria saber se o array $var tava vazio, e para isso contou todos os seus elementos
if ( count($var) > 0 )
 ...
 
// enquanto ela poderia ter usado uma verificação direta como
if ( !empty($var) )

Este último caso, que motivou o post foi visto no changelog da versão 1.2.6 do CakePHP. Neste caso o “erro” foi encontrado e corrigido pelo brasileiro Juan Basso neste commit.

O intuito do post não é meter o dedo na cara de ninguém, apenas alertar para situações onde culpamos uma determinada linguagem pelo desempenho de nossa aplicação quando o problema na verdade é o mal uso que estamos fazendo.