Do Windows para o Ubuntu

Certo dia, anos, resolvi usar linux. Eram muitas distros diferentes, pouca informação na web, e muita confusão.
Fui instalar, e… nada funcionava. Acho que instalei o Red Hat (não me lembro qual release): demorado, complicado, a interface gráfica pesada demais.
Deixei de lado, pois não tinha tempo na época de ir a fundo e me dedicar a usar um novo sistema operacional.

E o tempo foi passando, e jamais que eu encontrei esse tempo. Até que, por indicações de amigos e vendo muitos artigos na web, me deparei com o Ubuntu. Uma distro do linux que promete, entre outras coisas, primar pela usabilidade e acessibilidade (independente do país e língua de origem do usuário), ser de fácil uso para os usuários domésticos (prometendo uma fácil adaptação para quem vem de outros sistemas operacionais) e ser totalmente livre – e grátis.

Quando fui instalar, já vem a primeira surpresa. Você pode baixar do site (que, inclusive, tem versões em várias línguas – versão em português-br) ou pedir para enviarem o CD de instalação para sua casa. Tentei a segunda opção e, voilá, 1 semana depois estava o CDzinho em casa pronto para eu usar.

A instalação é simples (tão quanto a do Windows) e mais rápida.
Tudo muito fácil de configurar, intuitivo, e já vem por instalados padrão com navegadores (Firefox e Opera), editores de texto, planilha, etc… (Open Office), players de vídeo e música, e muito mais.
Um ponto muito positivo é que, se você precisar instalar um novo software, não é necessário baixar o arquivo de um site ou ftp, rodar um script de instalação, configurar, etc… só é necessário escolher em um gerenciador de atualizações novos softwares a serem instalados, e o próprio Ubuntu faz o trabalho de ir ao servidor, buscar, instalar e tudo mais. E, também, procurar no futuro atualizações.

Com tudo isso, para quem é desenvolvedor web – deixando de lado aqueles que usam tecnologias proprietárias (leia-se Microsoft na maioria dos casos)-, acabou aquele problema de usar uma cópia pirata do Windows, uma outra pro Photoshop, outro do Office, outra do Macromedia Studio, e por aí vai…

Algumas ressalvas apenas:
– se você é desenvolvedor Flash, não há o que fazer. O choro é livre, e ter o Macromedia Flash é essencial.
– quer testar as seus sites no IE? Existe um aplicativo chamado IEs4Linux, que pode ser baixado aqui. Funciona bem, mas só tem até a versão 6. Há um tutorial nesse site, http://webexpose.org/2007/01/07/internet-explorer-7-on-linux/, explicando como expandir o IEs4Linux para o IE7. Testarei em breve (prometo cumprir essa promessa!).

Existe, ainda, a opção de rodar o Windows através da Virtualbox, dentro do Linux. Nunca usei, sei apenas que é necessário ter uma boa máquina (e quando digo boa, quero dizer uma excelente máquina) e uma versão original do Windows…

Resumindo: se você usa Windows e desenvolve para web e já está acostumado a usar tecnologias livres (PHP, Java, Ruby), migrar para o Ubuntu é muito pouco traumático e é interessante – até para conhecer novas ferramentas e novos recursos 🙂

Como fazer um login em ASP sem banco de dados

Buenas povo!

Aqui vai um exemplo prático de como fazer um sistema de login simples em ASP[bb] , com dois níveis de usuários (e apenas dois usuários) mas sem utilizar Banco de Dados[bb]

Vamos iniciar fazendo o formulário de login, que ficará no arquivo default.asp, e será assim:

 

<form action="login.asp?a=login" method="post" name="flogin" id="flogin">
<p>Usuário
<input type="text" name="usuario" id="usuario">
</p>
<p>Senha
<input type="text" name="senha" id="senha">
</p>
<input type="submit" name="Login" id="Login" value="Login">
</form>
<%
response.write session("mensagem")
session("mensagem") = ""
%>

 

 

Perceba que a página do formulário imprime a sessão "mensagem", logo você vai entender o motivo. Com o formulário criado, precisamos de uma página que vá:

  1. Receber os dados do formulário
  2. Verificar o usuário e a senha
  3. Criar os cookies ou sessões para autenticar o usuário

A página que fará isso se chamará login.asp, e o código dela:

<%
if request.querystring("a") = "login" then
    dim user
    dim senha
    user = request.form("usuario")
    senha = request.form("senha")
    ´Verifica se é o administrador
    if user = "andafter" then
        if senha = "senhaaqui" then
            ´ Se usuário e senha conferem cria as sessões e redireciona para a página logado.asp
            session("usuarioOD") = "andafter"
            session("nivelOD") = 10
            response.redirect "logado.asp"
        else
            ´ Se a senha não conferir manda devolta para o formulário, com a sessão mensagem informando erro no usuário ou senha
            session("mensagem") = "Usuário ou senha não encontrados"
            response.redirect "default.asp"
        end if
    end if
    if user = "odesenvolvedor" then
        if senha = "blabla" then
            session("usuarioOD") = "odesenvolvedor"
            session("nivelOD") = 5
            response.redirect "logado.asp"
        else
            session("mensagem") = "Usuário ou senha não encontrados"
            response.redirect "default.asp"
        end if
    end if
    ´Se não veio com ação nenhuma envia para o formulário
    session("mensagem") = "Usuário ou senha não encontrados"
    response.redirect "default.asp"
end if
%>

Agora o usuário já está "logado" e o que falta é impedir o acesso as páginas restritas para quem não estiver logado. Vamos fazer isso verificando a existência da session "nivelOD".

Como essa verificação é necessária em todas as páginas, vamos criar um arquivo chamado seguro.asp que fará a verificação, depois usando include vocêd eve adicionar esse arquivo em todas as páginas restritas do site.

Código do seguro.asp:

<%
if session("nivelOD") = "" then
    session("mensagem") = "Você não está autorizado a acessar esta página."
    response.redirect "default.asp"
end if
%>

Pronto, os usuários que não estiverem logados serão redirecionados para a default.asp, tudo o que você precisa fazer é dar um include da página seguro.asp no início de todas as página protegidas.

Fácil, não?

Se tiverem dúvidas perguntem pro Chris Benseler, críticas e sugestões utilizem os comentários.

Criando um auto-completar (ajax) com PHP e MYSQL

Escrevi esse texto acho que um ano atrás, para um outro site (acabou não dando em nada). Estou reeditando o mesmo 🙂

Vamos ver como fazer o básico para um auto-completar de um input (parecido com o Google Suggest). No nosso caso, vamos procurar por usuários em uma tabela de um banco de dados. Para isso, utilizarei PHP[bb] no lado do servidor. Mas, a linguagem do lado do servidor não é o que realmente importa. Uma funcionalidade que utiliza a metodologia o modelo ajax[bb] deve ser: um cliente javascript acessando um serviço que está no servidor (tanto faz a tecnologia).

No nosso caso, criei uma página PHP (name.php) que:

  • recebe um parâmetro para ser utilizado como filtro na nossa consulta: $name = $_GET["name"];
  • conecta ao banco de dados (no caso, utilizei o MySQL), acessando uma base que contenha uma tabela pm_users (essa tabela tem duas colunas, id e fullName);
  • efetua uma consulta à tabela utilizando $name como filtro na busca pelo campo fullName;
  • monta um array com os registros que satisfazem a busca;
  • retorna esse array no formato JSON (http://json.org/). JSON é um tipo de formato de troca de dados amplamente utilizado na web hoje em dia (tem vantagens e desvantagens com relação ao XML. Em um post futuro falo a respeito de cada um. Por hora, pode-se achar na web bons textos a respeito). Para transformar o array no formato JSON, utilizei uma classe do Zend Framework (http://framework.zend.com/).

Feito o nosso serviço no lado do servidor, vamos nos preocupar agora com a apresentação: criei uma página simples, que contém um formulário com um label e um campo input. E ainda uma área (div), a qual será usada para mostrar os resultados do auto-completar.

Depois, foi criada a formatação CSS. O mais importante no CSS é ver que a div#usersList tem sua posição definida como absoluta, e não está visível quando se entra na página.
Ela só ficará visível quando o usuário estiver digitando na caixa de texto e retornarem resultados.

Agora, temos toda a parte de layout pronta. Falta ligarmos isso com o serviço.
Como faremos? Há inúmeras formas.
A grande maioria das pessoas que utiliza PHP no lado do servidor, ou usa algum frameworks como o Sajax e o Xajax para criar a chamada às funções automaticamente, ou cria arquivos PHP que geram arquivos XML e no lado do cliente, criam na mão javascript para ler e tratar esse XML.
Eu quis, nesse nosso exemplo, dar uma outra forma a vocês de como fazer; na página 1, fiz uma página em PHP que retorna dados no formato JSON. Se eu fiz isso lá, no cliente vou ter que ler os dados também no formato JSON.

Antes de chegar lá, vamos ver como fazer para chamar o serviço criado.

  • um listener foi criado no onload do documento: sempre que o evento onkeyup for disparado na nossa caixa de texto, faremos a requisição no servidor;
  • caso o campo de texto não tenha pelo menos 3 caracteres, garantimos que a lista de resultados seja escondida e saímos da função (esperando que tenhamos 3 caracteres pelo menos);
  • se tiver pelo menos esses três, caracteres, definimos a URL do nosso serviço (no caso, a página PHP name.php) e os parâmetros a serem passados na requisição (no caso, o parâmetro name com o valor a ser usado para filtrar); Obs.: no caso, passamos um parâmetro "rnd=" + Math.round()*4 , isso é necessário para evitar cache na requisição, problema comumente encontrado nos browsers IE6-;
  • então, usamos o método Request do objeto Ajax da biblioteca Prototype (http://prototype.js). Note que esse método é uma espécie de wrapper para a criação do (objeto) XMLHttpRequest. Se você, usuário, quiser, pode continuar com sua implementação na mão do XMLHttpRequest. O impacto é mínimo. Segue link da documentação da API, dessa classe utilizada: http://www.prototypejs.org/api/ajax;
  • em caso de sucesso na requisição, a função de callback onSuccess é chamada, passando transport como parâmetro; transport possui o conteúdo do que foi retornado pelo request. No nosso caso, lembram-se dos dados no formato JSON? Por isso que utilizamos o método evalJSON(boolean) para transformar esses dados em formato compreensível pelo javascript. Obs.: evalJSON(boolean) é um método da Prototype. Se você tiver implementado o XMLHttpRequest, deve fazer a conversão utilizando uma biblioteca adequada. Uma boa procurada no Google lhe trará ótimos resultados a respeito.
  • uma vez com os dados transformados num formato compreensível pelo javascript (no caso, um array), só o que nos é necessário é percorrer esse array, sabendo que cada item do array possui um array de duas posições, onde a primeira é o id e a segunda o nome do usuário (olha só aí o porque o JSON é um belo formato de troca de dados: os dados que vieram do SELECT lá no PHP seguem a mesma ordem agora no javascript; não é preciso criar um XML, usar um DTD, percorrer nós, ver atributos, etc…). Voltando ao nosso array, ao percorrê-lo, criamos um elemento do tipo a para cada registro, e vamos definindo seus atributos (href, title, innerHTML…) e adicionando (appendChild) à lista, formando assim o nosso auto-completar

Pessoal, no final teremos uma página (ok, layout está bem simples, mas o propósito é mostrar a funcionalidade) onde o usuário vai digitando num campo input e através de uma rotina em PHP vão sendo feitas consultas no banco de dados, com filtro de usuários

Os arquivos estão disponíveis para

download

. Podem mexer, utilizar onde quiserem, modificar.

Google Chart

No post sobre estatísticas de uso de browser que fiz semana passada, usei o serviço de gráficos do Google.

O Google Chart (http://code.google.com/apis/chart/) é um serviço free para que você, desenvolvedor, possa embarcar no seu site, blog, whatever, um gráfico sem precisar de uma biblioteca server-side que faça isso – no final do artigo vamos considerar alguns pontos a respeito.



O uso do Google Chart é bem simples: você coloca na sua tag img do html o caminho da imagem que o serviço gera como gráfico (não é necessário importar nenhuma biblioteca javascript, nada de requisições assíncronas, etc…).

O serviço disponibiliza uma grande variedade de gráficos, desde os mais simples (de linhas), até os mais complexos (tipo radar) passando pelos muito utilizados gráficos de pizza.

Sendo que há, também, uma boa quantidade de opções de customizações que vão além do tipo do gráfico: dimensões, cores, visão 2D ou 3D, tipos de preenchimentos de barras, etc…

Um exemplo: como montar um gráfico como os que estão no artigo referenciado ali em cima?

O formato da url que deve ser usada para gerar o gráfico é o seguinte:

http://chart.apis.google.com/chart?cht=[tipo de gráfico]&chd=[valores]&chs=[dimensões]&chl=[rótulos]



O tipo de gráfico a ser usado é o de pizza 3D, logo [tipo de gráfico]=p3

Os valores, são representados por uma lista separada por vírgula, precedida pelo tipo de encoding a ser utilizado (ver a referência aqui). Pegando os dados de Abril/2008, são eles:

IE7: 19,4%

IE6: 61,2%

Firefox: 14,4%

Outros: 4%

Logo, [valores] será igual a t:38.6,39.8,18.8,2.8
Nota: t é o tipo de encoding. Na documentação da API, existe uma explicação completa sobre ele e outros tipos

Se não forem definidades dimensões, são usadas as padrão do sistema. No caso, setei [dimensões] como um par de valores igual a 250×100

Os rótulos (conhecidos popularmente entre programadores como labels) são definidos por uma lista que utiliza o caracter | (pipe) como divisor.

Com isso, chegamos a url http://chart.apis.google.com/chart?cht=p3&chd=t:38.6,39.8,18.8,2.8&chs=250×100&chl=IE7|IE6|Firefox|Outros

Colocando em uma tag img, seria o equivalente a <img src="http://chart.apis.google.com/chart?cht=p3&chd=t:38.6,39.8,18.8,2.8&chs=250×100&chl=IE7|IE6|Firefox|Outros" alt="Acessos por Browser / 2008" />



Vale a pena dar uma explorada nessa API, ver o que dá pra fazer (existem muitas outras customizações possíveis) e até onde é possível ir 🙂



E, como havia dito lá em cima, vale a pena ponderar rapidamente um assunto: quando usar o Google Chart e quando usar uma biblioteca server-side?

Vou dar a minha opinião: o Google Chart é bom por ser uma aplicação free – apesar de que pode-se achar em PHP e Java, por exemplo, uma infinidade de bibliotecas free (já em ASP eu não conheço do assunto) -, ser de rápido aprendizado, ser desenvolvida por uma empresa que é sinônimo de excelência em serviços web. E ajuda muito quando você não tem uma linguagem de server-side disponível para ser utilizada (por exemplo, está escrevendo um artigo em um sistema de terceiros ao qual você não tem acesso às funcionalidades do mesmo).

Por outro lado, eu ainda sou favorável a utilizar bibliotecas embarcadas na sua aplicação, por motivos óbvios: não fica dependente de um serviço que está fora do seu servidor sem necessidade (o mesmo não se aplica ao Google Docs, né?), tem certeza que o serviço estará disponível sempre que seu site estiver no ar, pode customizar o serviço (se a licensa da biblioteca lhe permitir) se necessário….
Mas, essa é uma discussão que deve ficar para um artigo mais específico, só sobre "usar ou não webservices e APIs de terceiros?".

Por enquanto, é isso 😉

IE6, 7 e Firefox nos últimos anos

Fiz um levantamento usando as estatísticas de um site no qual trabalho, pegando os dados de acesso dos últimos anos. Só por curiosidade mesmo, para ver a evolução no uso dos browsers.

Em Abril de 2006:

Browsers - 2006

IE7: 0,1%
IE6: 84,5%
Firefox: 11,5%
Outros: 5.4%

 

Em Abril de 2007:

Browsers - 2007

IE7: 19,4%
IE6: 61,2%
Firefox: 14,4%
Outros: 4%

 

Em Abril de 2008:

Browsers - 2008

IE7: 38,6%
IE6: 39,8%
Firefox: 18,8%
Outros: 2.8%

 

Nota-se que o Firefox vem tendo um crescimento gradativo – 3% no primeiro período, 4% no segundo. E a plataforma Windows, usando ou o IE6 ou 7, ainda manda no mercado.

Lembrando que isso é a análise de um site apenas, no Brasil. Não deve corresponder fielmente às estatísticas globais (na Europa, pelo que sei, o uso dos browsers IE vem caindo). Serve apenas para termos uma idéia da participação de cada navegador.