Como retirar o index.php das urls do Code Igniter

Acho que não comentei por aqui ainda, mas tenho usado bastante o Code Igniter ultimamemente junto com o Guilherme num projeto pessoal nosso. O Code Igniter é um framework PHP para implementação MVC do seu projeto.
Em breve pretendo fazer um post completo sobre ele e como tenho utilizado, por enquanto vou dar uma dica rápida de como resolver uma questão que envolve o CI: quando você cria URLs personalizadas nele, por adrão você precisa montá-las da seguinte forma:

http://[url base]/index.php/[nome do controller]/[método]

Para retirar esse index.php da url, se você estiver usando (o webserver) Apache, faça o seguinte: crie um arquivo .htaccess na raíz da instalação e insira:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

Abraços!

Verificar se uma string é vazia com javascript

Depois do post sobre performance no Javascript aqui vai um  fastpost , também falando de javascript. Hoje vou mostrar uma função simples que utiliza uma expressão regular para verificar se o valor passado é nulo ou não.

Não há muito o que explicar, então segue o código:

function notNull (x){
        if(a!="" && !(a.match(/^\s+$/))){
            return true;
        }else{
            return false;
}


Para verificar se alguma string é nula é só chamar a função notNull(string).

A primeira verificação do if é para ver se a string passada (x) não é vazia, depois a expressão regular  (/^\s+$/) se encarrega do resto, verificando se x não é composta apenas de espaços.

Utilizei esta função para validar um campo de busca, já que neste caso o usuário não poderia buscar apenas espaços ou dar submit na busca vazia.

A função retorna true quando a string é válida (não é vazia e não é composta apenas por espaços) e false quando o contrário ocorre.

Aqui vai um exemplo (utilizando jQuery) de como validar um form de busca, onde o input com id search é o campo de busca.

if(notNull($("#search").val()){

    $("#searchForm").submit;

else{

    alert("A busca está vazia.");

}
 

E para quem quer aprender funções regulares, já li e recomendo o livro Expressões Regulares: uma abordagem divertida.

Performance – preciso me preocupar tanto?

Este post surgiu quando eu ia publicar aqui a apresentação Extreme Javascript Performance, do autor do script.aculo.us, Thomas Fuchs. O post é mais amplo, não trata de javascript e nem do código em si, mas sim da importância (ou não) de levar em consideração possíveis problemas de performance que poderão causar problemas no futuro.

Quando comecei a "programar"¹ eu não ligava muito para performance. Ok, eu não ligava nem um pouco. 

Motivos que levam um desenvolvedor (noob) não ligar para performance:

  • Ele não sabe bem o que está fazendo
  • A aplicação terá poucos usuários (sobra de recursos)
  • Eventuais problemas de performance não vão causar prejuízo financeiro
  • Pensamento POG: funcionou, deixa assim

Pois bem, guri novo que era, tinha os 4 elementos que precisava para fazer cagada. E obviamente fazia. Fiz meu primeiro blog em PHP, funcionava, postava, subia imagem… o código era uma porcaria, mas funcionava.

 Fazer bem feito...

Fazer bem feito para fazer só uma vez, né?

 

Performance – porque se preocupar?

Com o tempo cresci (apenas no modo de pensar e programar, na altura quem me conhece sabe: nada.), aprendi coisas novas e coisas que eu já deveria saber, brinquei fazendo "mini-serviços", desenvolvi o And After e testei e produzi uma ferramenta que inicialmente era só para o And After mas acabei abrindo e foi utilizada por centenas de publishers – a Vitrine Fácil.

Nesta época eu já dava importância para performance, código bem escrito, mas ainda faltava experiência de gerenciar de "cabo a rabo" uma aplicação que fosse utilizada por diversos usuários, e eu tinha uma tremenda inexperiência com uma coisa importantíssima quando se fala de performance: cache.

Mas mais do que aprender como melhorar performance (isso a gente aprende programando e lendo, mas as vezes "esquece") eu aprendi os motivos para se preocupar com performance dos nosso códigos. E segue uma listinha:

  • Downtime custa CARO quando a ferramenta é lucrativa
  • Downtime suja o nome do serviço (lembram do No Donut for you?)
  • Se o sistema/aplicativo for bom ele terá usuários
  • Você não pode freiar o crescimento do sistema (é o mesmo que freiar os lucros)
  • Muitas vezes é impossível prever o crescimento

 

Como melhorar a performance do código?

Já que optei neste post por não tratar de nenhuma linguagem específica, para alguns leitores as dicas podem ficar uma coisa superficial, mas espero que de alguma forma ajudem na forma de um guia inicial para começar a se preocupar com performance…

  • Cache é importante
  • Estude e domine a linguagem que está utilizando (siga as boas práticas recomendadas)
  • Acompanhe o crescimento do seu serviço / site
  • Realize testes de stress no servidor
  • Monitore "de perto" como está o seu servidor (consumo)
  • Lembre-se denovo: cache é importante
  • Verifique: é necessário otimizar? Não vai prejudicar a manutenção do código ou o desenvolvimento de novas features?

 

Cada caso é um caso, otimizar é importante e pode fazer você economizar com servidor porém não deve lhe causar muita dor de cabeça na hora de fazer uma alteração ou aumentar as funcionalidades do sistema… 😉

Recomendo um posto do meu xará, Guilherme Chapiewski: A falácia da otimização prematura, que aborda a célebre frase “A otimização prematura é a raiz de todo o mal” – e muitas vezes não é bem assim.

 

E você, se preocupa com performance? Discorda do que foi dito acima? Concorda?

Comente, gostaria de saber opiniões dos leitores também 😀

 


¹ As aspas são para indicar um fato simples e que não precisa de maiores explicações: comecei a programar sozinho, like a noob.

Extreme JavaScript performance

Faz algum tempo que comecei a escrever sobre performance no javascript, como introdução a uma apresentação de slides deste neste post, mas achei que o assunto era bastante pano pra manda e resolvi repartir as coisas.

Comecei a escrever tanto sobre a importância de alguns cuidados com perfomance que o post deixou de ser direcionado a Javascript e se tornou um relato da minha curta experiência com cuidados com performance – backend e frontend. Meu post inicial virou um rascunho para um post que sairá em breve: Performance – preciso me preocupar *tanto*? –  linko-o aqui quando publicar.

Voltando ao Javascript, nunca me preocupei tanto com questões de performance no Javascript – pois não fazia coisas muito complexas até um tempo atrás, e sempre me preocupei mais com questões de performance no backend.

Porém quando a aplicação é maior e você precisa manipular bastante interface, informações e tem interação direta com o usuário acaba percebendo que você já tem diversas classes e todas elas precisam funcionar perfeitamente para não comprometer o funcionamento de nada. Não se preocupar com performance neste caso é perigoso, errado, chato bobo e feio.

Thomas Fuchs (o ninja autor do script.aculo.us) realizou uma série de testes comparando métodos de executar uma mesma ação no JavaScript, e fez isso em quatro navegadores: Firefox, Internet Explorer, Ópera e Chrome.

Javascript ninja

Javascript ninja

A apresentação respondeu algumas curiosidades e dúvidas, mostrando qual a forma mais performática de executar um loop, um contador, criar arrays e objetos, declarar variáveis, etc…

 

 

Achei a apresentação e testes realizados bem legais, dá para entender melhor e – na medida do possível – alterar o método de desenvolver para uma forma mais performnática.

Compreendo e concordo que performance não é tudo, pois alguns dos métodos mais performáticos não são os mais produtivos – como por exemplo evitar chamar funções dentro de funções.

Mas de qualquer forma, pensar em performance – e endender um pouco melhor como nossos precioso script vai ser interpretado sempre é interessante!

Álbum em PHP utilizando a API do Picasa, JQuery e FancyBox

Esses dias surgiu a oportunidade de um trabalho, o cliente precisava reformular o site, melhorar o processo de publicação de conteúdo, entre outros… Ao acessar o site para dar uma olhada no tipo de conteúdo, me deparo com o link álbum, cliquei pra conferir e fui parar no picasa, no álbum do cara.

Muito empolgado com as funções de XML do PHP resolvi aproveitar a API do picasa para implementar um álbum com a cara do site do meu cliente mas com a infraestrutura do picasa 😀 .

O código é bem simples, coloquei comentários onde pudesse gerar dúvidas.

Segue:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Álbum usando a API do Picasa + JQuery + FancyBox</title>
    <style type="text/css" media="all">
        html, body {margin: 0px;    padding: 0px;}
        body {background: #EAEAEA; font-family: "Trebuchet MS",Verdana,Arial,sans-serif; font-size: 14px; line-height: 1.6;}
        a {outline: none; margin-right: 20px;}
        a img {border: 1px solid #CCC; padding: 2px; margin: 10px 5px 10px 0;}
    </style>
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>
    <link rel="stylesheet" type="text/css" href="http://fancybox.net/js/fancybox/jquery.fancybox-1.2.6.css" media="screen" />
    <script type="text/javascript" src="http://fancybox.net/js/fancybox/jquery.fancybox-1.2.6.pack.js"></script>
    <script type="text/javascript">
        $(document).ready(function() {
            $("a.zoom").fancybox();
        });
    </script>
</head>
<body>
<?php
 /* Álbum usando API do Picasa... :D v. 0.1
  *
  * Auhor: Felipe Furst
  * email: [email protected]
  */
    $picasaUser = "mobilemechanics"; // usuário do picasa
    /* ----------------- daqui só mexa se souber oq está fazendo ---------------- */
    if(!$_GET["id"]) {
        $tt = file_get_contents("http://picasaweb.google.com/data/feed/api/user/{$picasaUser}"); // busca os álbuns
        $xml = simplexml_load_string($tt);
        echo "<div id="albuns" align="center">";
        for($i = 0; $i < count($xml->{"entry"}); $i++) {
            $gphoto = $xml->{"entry"}[$i]->children("http://schemas.google.com/photos/2007"); // pega os nodos filhos do namespace http://schemas.google.com/photos/2007
            $media = $xml->{"entry"}[$i]->children("http://search.yahoo.com/mrss/"); // semelhante à linha acima
            echo "<a href="".$_SERVER["PHP_SELF"]."?id=".$gphoto->{"id"}.""><img src="".$media->{"group"}->{"thumbnail"}->attributes()->url."" alt="" /></a>";
        }
        echo "</div>";
    }
    else {
        $tt = file_get_contents("http://picasaweb.google.com/data/feed/api/user/{$picasaUser}/albumid/{$id}"); // busca as fotos de um determinado álbum passado por parâmetro
        $xml = simplexml_load_string($tt);
        echo utf8_decode($xml->{"title"})."<br>".utf8_decode($xml->{"subtitle"})."<br>";
        echo "<div id="album" align="center">";
        for($i = 0; $i < count($xml->{"entry"}); $i++) {
            $media = $xml->{"entry"}[$i]->children("http://search.yahoo.com/mrss/"); // esse cara aqui vc já conhece ...
            echo "<a class="zoom" rel="group" title="".utf8_decode($media->{"group"}->{"description"})."" href="".$media->{"group"}->{"content"}->attributes()->url.""><img src="".$media->{"group"}->{"thumbnail"}[1]->attributes()->url."" alt="" /></a>";
        }
        echo "</div>";
    }
?>
</body>

O bom disso tudo é que você organiza tuas fotos em uma aplicação específica para esta função, não consome tempo desenvolvendo, não consome espaço no servidor e mantém a identidade visual do site.

Claro, há o que melhorar, mas o básico tá aí. Até…

Links de APIs e bibliotecas utilizados:
http://code.google.com/intl/pt-BR/apis/picasaweb/overview.html
http://br.php.net/manual/en/book.simplexml.php
http://fancybox.net/