Estamos agora estreando o blog Not For Dummies, blog sobre desenvolvimento mantido por diversos autores. Vamos falar de XHTML, CSS, PHP, Ruby On Rails, Usabilidade, e muito mais. Com vários autores, o blog vai ficar menos tempo parado.

Então a partir de hoje vou passar a escrever sempre por lá. Ainda não sei o que vou fazer com este blog, mas com certeza vai ficar parado por um tempo até eu me decidir.

Então se você assina o feed deste blog ou visita com frequência, passe a visitar o Not For Dummies. Você vai gostar.

No related posts.

Recebi o link para este site pela web designer da empresa onde trabalho. O site contém um “guia de como ter sucesso online” (em inglês), mas o site é um grande exemplo do que NÃO fazer ao se criar um site. Começando pelo fato do site ser todo feito em flash.

Fazer site todo em flash, com navegação “diferentinha” é bem coisa de web designer (não os bons, vocês estão perdoados). Criar um site assim é o mesmo que pegar todo o avanço que tivemos na usabilidade na web até agora, e jogar fora.

Vamos analisar. O site dá as dicas numa animação em flash no formato de um livrinho, onde o usuário clica no canto para virar a página e continuar lendo. Agora vamos analisar o show de problemas de interface e usabilidade.

• A fonte é pequena demais. Uma pessoa com visão boa tem que espremer os olhos para ler. Quem quiser ver maior tem que clicar na lupa e usar um péssimo sistema de zoom que implementaram no livrinho. Se não fosse em flash, a pessoa teria total liberdade de aumentar o texto como quiser.
• Clica clica clica. Cada página tem pouca informação, e são MUITAS páginas. A pessoa tem que ficar clicando, e clicando, e clicando para poder ler tudo. Não chega nem perto da facilidade de rolar com o mouse.
• Não dá pra escanear a página com os olhos. As pessoas não lêem na web como lêem um livro. Elas vão escaneando o site rápido com os olhos em busca da parte mais interessante do conteúdo. E não dá pra fazer isso neste site. Você não pode ir rolando até ver um conteúdo que te interesse, porque você não pode rolar! Não pode escanear rápido o site com os olhos.
• Você não pode usar a busca do seu navegador para encontrar alguma coisa. Na verdade, você não pode buscar nada! Se você está na página 70 (de 337) tem que clicar 69 vezes até voltar ao índice e procurar o que você quer.
• Não dá pra usar os botões de Voltar e Avançar do navegador, e nem seus respectivos atalhos de teclado. Você fica preso à navegação que a pessoa implementou no flash, e só. Se a navegação feita no flash for ruim, não tem como fugir. O clica-clica-clica é péssimo.
• Sites de busca não podem indexar o conteúdo. O google até tá inventando jeitos de indexar flash, mas tá mais na tentativa ainda. Sites em flash não podem ser indexados corretamente. Não dá pros robôs entenderem o que o site diz.
• Um flash gigante. Em sistemas operacionais que não tem um suporte tão bom do flash (linux e mac, olá?) essa página vai ficar muuuito pesada. E lenta. Vai irritar o usuário e ele vai fechar. E isso significa uma média de 10% dos visitantes que você vai ter mandado embora sem ler seu conteúdo.
• Só funciona com quem tem flash! A quantidade de acessos através de celulares inteligentes tem aumentado num ritmo alucinante (principalmente graças ao iphone). E uma boa parte desses acessos vindos de celular não podem ver flash. Isso significa que aquele site vai aparecer vazio pra essas pessoas. Uau, legal. Mostra mesmo que o criador NÃO tem visão e não está preparado pro futuro.

Eu poderia ainda citar muitas outras coisas. Não permite que o usuário selecione e copie conteúdo com o mouse, não permite que alguém aponte um capítulo específico pra alguém, etc etc etc. É apenas um grande exemplo de como se criar uma péssima interface.

Eu achava que os sites feitos todos em flash tinham ficado em 1995, mas parece que continuam surgindo uns aqui e ali. Eu me pergunto como um site desses pode ousar dar dicas para a web. Mas também não é nenhuma surpresa que não tenha nenhum site em flash entre os mais famosos e conhecidos.

Vocês conhecem mais algum desses péssimos exemplos de sites feitos por designers ruins?

No related posts.

URL Aliasing

Há uns dias eu postei como capturar missing_actions (quando o usuário acessa uma URL com action que não existe) e redirecionar para um controller que lidaria com o problema. Muito legal, mas não resolve o problema quando a URL aponta também para um controller que não existe.

O plugin URL Aliasing resolve exatamente esse problema, fornecendo um meio bem simples de lidar com erros de missing_controller.

Link: URL Aliasing

Symbi0nt’s Model Validation

Este não é exatamente um plugin, e sim um app_model.php pré-construído com métodos que facilitam bastante a parte de validação de dados do Model.

O principal é que ele define uma série de constantes com validações pré-definidas. Em vez de escrever suas validações, você usa constantes como VALID_IF_NOT_EMPTY, e VALID_IF_EMAIL. A mensagem de erro é especificada por você, então pode ser usado perfeitamente em projetos que não sejam em inglês.

Link: Symbi0nt’s Model Validation

Link: Exemplos de uso

No related posts.

Eu gosto do meu código muito certinho. Indentação correta e consistente, e um uso inteligente de linhas em branco para separar e organizar tudo em blocos. Mas tem gente que faz uma coisa bizarra, e sai escrevendo o código todo junto, como se os parâmetros precisassem ficar colados uns aos outros para não morrer de frio ou solidão. Aí fica um troço assim:

div{padding:10px;border:1px solid #CCC;width:485px;height:37px;background:#EEE}

Se você faz isso, eu te odeio. Pura e simplesmente. Te odeio e nunca te convidaria pra tomar chá com biscoitos. Pronto, falei.

Agora vá lá ler o post do tableless, que é muito bom.

No related posts.

Essa semana um trouxa moço muito simpático aqui do trabalho queria uma forma de redirecionar pra uma certa página caso o usuário digitasse um endereço inexistente dentro do site criado com o cake. A primeira coisa que se pensa é procurar um jeito de fazer isso através das rotas, mas eu procurei e não encontrei nenhuma forma de criar uma rota específica para controllers ou actions não existentes.

Como fazer, então? A solução é usar um misto dos recursos do Cake, com o básico do próprio PHP. Que venha a nós o beforeFilter e a herança de classes.

Como Redirecionar Endereços Inválidos

O CakePHP permite que você defina um método beforeFilter nos seus controllers, que será chamado antes da action (método do controller) ser chamada pelo framework. E como queremos que TODOS os nossos controllers saibam responder a um endereço inexistente, a melhor opção é criar o método beforeFilter no app_controller.php

Se seu projeto no cake ainda não tem o app_controller, é só você criar um arquivo chamado app_controller.php dentro da pasta app (e não na pasta controllers), e dentro dele colocar o código:

<?php
class AppController extends Controller {
 
}
?>

E dentro da classe vamos adicionar nosso beforeFilter:

<?php
class AppController extends Controller {
    function beforeFilter() {
        if( !empty($this-&gt;params['action']) &amp;&amp; !method_exists($this, $this-&gt;params['action']) ) {
            $this-&gt;redirect(array('controller' =&gt; 'main', 'action' =&gt; 'missing'));
        }
    }
}?>

O que fizemos acima? A função method_exists é um recurso do PHP que testa se um método existe em um dado objeto. Passamos $this como o objeto, e $this->params['action'] como o método a testar. Se retornar false significa que a action não existe, e o usuário está tentando acessar uma action inexistente. Então o beforeFilter redireciona o usuário pra um lugar que realmente existe, antes mesmo que o framework tente chamar a action. Do exemplo acima, você pode trocar o controller ‘main’ e a action ‘missing’ pelo que for melhor para o seu projeto. Basta ter certeza de que está redirecionando pra um controller e uma action que realmente existam.

Note que isso só funciona se o usuário tentar acessar um endereço que aponte para uma action inválida, mas em um controller válido. Se o usuário acessar apenas site.com/pudim, o CakePHP vai buscar um controller pudim e aí vai dar erro mesmo. Uma solução possível seria criar uma rota definindo que caso acessem um endereço com apenas um parâmetro depois do domínio, ele redirecione pra um controller específico e passe aquele parâmetro único como rota. Pra quem não sabe configurar as rotas, amanhã eu explico.

No related posts.

Mas a Super Loja não é perfeita. Pra maioria das situações ela funciona muito bem, mas se você precisar ser um pouco mais específico ao listar os produtos, ela não ajuda. Algumas vezes você quer exibir o resultado da busca por um produto, mas acaba vindo muito lixo junto. Por isso, resolvi criar meu próprio script de loja do mercado livre, também em PHP.

A Mega Loja é um script completo em PHP que usa usa a API do Mercado Livre para fazer uma busca por produtos. O Mercado Livre retorna uma lista de produtos em XML, e então o script usa essa listagem para montar uma vitrine de produtos, onde você ganha em dinheiro uma porcentagem do preço de cada produto vendido.

A Mega Loja terá compatibilidade com o sistema de URLs dinâmicas da Super Loja. Ou seja, se você já usa o script do Jobson, poderá trocá-lo pela Mega Loja e todos os links continuarão funcionando. A maior diferença se encontra no fato de que agora você terá a possibilidade de usar a URL também para definir a categoria do mercado livre onde deseja buscar os produtos, e a faixa de preço.

Por exemplo, se você quisesse listar iPhones, ordenando pelos mais vendidos, na Superloja você adicionaria /iphone/ven/ no final da URL. Com a Mega Loja, você poderá fazer /iphone/ven/39328/1000:2000/para também definir que quer buscar apenas na categoria 39328 (iphone), e apenas resultados entre R$1000 e R$2000. É claro, qualquer parâmetro é opcional, e você pode simplesmente usar da mesma forma que usa a outra loja atualmente.

Se posso usar da mesma forma, porque usar a Mega Loja? Existem outras vantagens! Uma delas é que você pode configurar uma lista de produtos recomendados em um menu lateral. Não importa por qual URL a pessoa entre na loja, os produtos recomendados aparecerão sempre os mesmos ali na lateral. Muito útil para recomendar os produtos da moda, ou para usar como acesso rápido para os mais vendidos.

Uma outra e útil diferença é na exibição dos produtos. A Mega Loja exibe os produtos com uma aparência melhorada, mais agradável. Em uma versão futura vai inclusive ser possível configurar as cores da loja, se quiser.

Ainda estou terminando de trabalhar no sistema, mas ele vai ser liberado para qualquer um utilizar em seu site, e é totalmente open source. Se você se preocupa pela loja do Lemos rodar as partes importantes no servidor dele sem você ver o que está acontecendo, meu script da Mega Loja é totalmente transparente, e roda 100% no seu próprio servidor.

Quem é desenvolvedor e sabe usar repositórios git pode dar olhada no projeto enquanto desenvolvo, pois a Mega Loja está no github. Qualquer pessoa interessada em contribuir para o projeto é só entrar em contato. Até agora meu maior contribuidor foi o Xaxá, que escreve comigo no Tomate Cru e mantem o blog Quinquil.

Mais notícias sobre a Mega Loja em breve.

No related posts.

Tudo começou quando o meu maravilhoso host me deu a possibilidade de ser um dos primeiros transferidos para um novo servidor, diferente dos anteriores, que me permitiria ter espaço ilimitado, e transferência mensal ilimitada. Havia um aviso de que aplicativos poderiam deixar de funcionar na transferência, mas pra ter hospedagem ilimitada vale tudo, não? Aceitei na hora, e fiquei torcendo para tudo dar certo.

Depois disso, esqueci do assunto. Um ou dois dias depois a transferência de todos os meus sites para o novo servidor começou e, no mesmo dia, tive uma entrevista de emprego. Fui mostrar o emprestei.com para o entrevistador e, para minha surpresa, o site estava fora do ar. Uau, o que teria acontecido? Foi só quando voltava pra casa que me lembrei: a transferência pro novo servidor! Que droga. O Emprestei acabou saindo do ar, e meu repositório subversion também. No dia seguinte o repositório voltou, mas o Emprestei não.

Ainda não tive tempo de ver exatamente porque o Emprestei parou de funcionar depois que foi movido para o novo servidor, mas o que importa é que está dando algum problema com o Rails e ele não inicia mais. Eu poderia buscar o erro e colocar o site de volta no ar ainda hoje, mas resolvi fazer outra coisa.Já tem um tempo que eu estou querendo melhorar o Emprestei. Originalmente ele havia sido feito para participar do desafio Rails Rumble, onde você deve construir um site em no máximo 48 horas.

Pois é, o site inteiro foi feito em dois dias, e até que ficou bem feito. Mas ele foi feito bem antes de sair o Rails 2.0, que trouxe vários novos recursos, então eu já precisava melhorá-lo há tempos. Esse erro que o deixou fora do ar é a desculpa perfeita pra eu finalmente parar de enrolar e criar uma versão maior, melhor, e mais verde.

Acredito que a nova versão estará online ainda essa semana, e terá tudo que uma boa aplicação rails deve ter. Será todo RESTful, e ainda permitirá exportar em XML as coisas que você emprestou, para que outras aplicações possam ler sua lista de empréstimos e integrá-la a outros serviços.

Como diria o senhor Didi Mocó Sonrisal Colesterol Novalgino Mufumbo, aguarde e confie.

No related posts.

Veja abaixo o cupom de desconto, e um guia de como assinar.

O serviço de hospedagem da Dreamhost suporta PHP e Ruby, com banco de dados MySQL. Eles possuem um ótimo painel de controle, e possuem várias aplicações web prontas para instalar com um simples clique, incluindo o próprio sistema Wordpress que uso neste blog. Mas o melhor de tudo é que eles não são daqueles hosts chatos que proibem um monte de coisa. Na Dreamhost, você é bem livre, e ainda pode se conectar por SSH para realizar algumas operações mais rapidamente.

Código de desconto: TOMATECRU.

Se você está pensando em assinar, aqui vem o melhor de tudo: Nós do Tomate Cru estamos oferecendo um cupom de desconto! Ou seja, estamos anunciando uma hospedagem sem limites, e ainda vamos dar desconto! Basta assinar a dreamhost e usar o cupom TOMATECRU, e já ganhará desconto. Se você assinar o plano mensal, vai ganhar $50 dólares de desconto (mais de R$100 de desconto!!). E se assinar o plano anual, você ganha $67 dólares de desconto. Independente do plano que assinar, você ganha direito a um domínio internacional de graça!

Deixa eu explicar direito aqui… o plano anual custa $120 dólares. Nosso cupom dá um desconto de mais de 50%! O preço cai abaixo da metade! Assine agora! Eu quero saber o que você está esperando! Eles só tem mais 30 vagas pra hospedagem ilimitada, corra para assinar!

(Clique abaixo para ler o restante do texto e ver um guia passo a passo de como assinar uma hospedagem ilimitada na Dreamhost. Se não quiser ler o guia, a parte de inserir o cupom de Desconto está na etapa 7 do registro).

Como assinar a hospedagem da Dreamhost

Este é um passo a passo de como assinar uma hospedagem ilimitada na dreamhost.

Primeiro, você vai acessar a página de assinatura da dreamhost. Você vai ver uma tela com duas opções. A prmeira é para assinar a hospedagem (o que você quer), e a segunda é para registrar um domínio. Clique na primeira opção, que diz “host a domain”.

A página vai mostrar então vários passos (steps) para concluir o processo. Vamos a um resumo de cada step do formulário.

Step 2 – Tipo de Pagamento

Aqui você vai escolher com que frequência quer pagar. Mensalmente (monthly), Anualmente (Yearly), ou a cada 2 anos, 3 anos, 5 anos ou 10 anos. O pagamento mensal possui um custo de instalação de $50 dólares, mas com nosso cupom de desconto TOMATECRU você não vai pagar a instalação.

Step 3 – Private Server

Um servidor privado serve apenas para aumentar o desempenho de sites com um volume de acessos muito, muito grande. Como provavelmente este não é o seu caso, basta ignorar essa parte.

Step 4 – Serviços Adicionais

O passo 4 serve para adicionar alguns serviços extras. O serviço Google Apps integra algumas funcionalidades do Google no seu domínio, e é de graça. De resto, nenhum dos outros serviços aí é realmente necessário ou interessante para um site que está começando.

Step 5 – O Domínio

Um domínio é o endereço pelo qual seu site vai ser acessado. O que você vai escolher aqui depende se vc já tem um domínio ou se quer registrar um novo (de graça). Se você não sabe bem o que é isso, ou se você tem um, então escolha a primeira opção. Se você já tem um domínio, escolha a terceira opção.

Então, no campo de texto, você vai preencher o domínio desejado. No campo abaixo, preencha o login que você quer usar na dreamhost.

Step 6 – Dados Pessoais

Nesta etapa você precisa preencher seus dados pessoais. E-mail, senha, e outros dados como seu endereço. Preencha tudo com seus dados reais, pois serão usados na cobrança do cartão de crédito e para contato.

Step 7 – O Cupom de Desconto!

Nesta etapa, no primeiro campo eles perguntam como você ficou sabendo da Dreamhost. Podem preencher com o endereço do blog, ou deixar em branco.

No segundo campo da etapa 7, é onde você pode preenchero cupom de desconto. Basta preencher com TOMATECRU, e ganhar o maior desconto da sua vida!

Bom, é isso. Agora é só marcar a caixinha ao lado do texto “I agree to abide…” e clicar no botão grande. Fim do processo, e você agora será um assinante do melhor serviço de hospedagem ilimitada que existe. Espero que goste.

No related posts.

Todo o código necessário pra fazer o treeview funcionar pode ser visto abrindo o código fonte da página no seu navegador, mas o trecho importante é este:

<script type=”text/javascript”>
//<![CDATA[
function mytree_Init() {
var tree = new YAHOO.widget.TreeView("mytree");
var parent_top = new YAHOO.widget.TextNode({ label: "Grupo Empresarial XYZ", href:"#" }, tree.getRoot(), false);
var empresa1 = new YAHOO.widget.TextNode({ label: "Empresa 1", href:"#" }, parent_top, false);

var filialA = new YAHOO.widget.TextNode({ label: "Filial A", href:"#" }, empresa1, false);
new YAHOO.widget.TextNode({ label: "Gerente Geral", href:"#" }, filialA, false);
new YAHOO.widget.TextNode({ label: "Gerente de Operações", href:"#" }, filialA, false);

var filialB = new YAHOO.widget.TextNode({ label: "Filial B", href:"#" }, empresa1, false);
new YAHOO.widget.TextNode({ label: "Gerente Geral", href:"#" }, filialB, false);

var empresa2 = new YAHOO.widget.TextNode({ label: "Empresa 2", href:"#" }, parent_top, false);

tree.draw();
}
YAHOO.util.Event.addListener(window, "load", mytree_Init);
//]]>
</script>

Apesar de um pouco feio, é um código simples que monta a estrutura da lista em árvore. Podemos tornar este código mais bonito? Sim! Usando as facilidades permitidas pelo Ruby on Rails, a mesma lista pode ser montada desta forma:

var test_data =
[0, { label: "Grupo Empresarial XYZ"},
1, { label: "Empresa 1"},
2, { label: "Filial A"},
3, { label: "Gerente Geral"},
3, { label: "Gerente de Operações"},
2, { label: "Filial B"},
3, { label: "Gerente Geral"},
1, { label: "Empresa 2"}];

Muito melhor, não é mesmo? Esta formação é possível quando criamos um método que vai pegar a estrutura acima e escrever o código javascript correspondente. Estas intruções de como criar este método no rails podem ser lidas neste blog.

No related posts.

No caso da exibição em Treeview, a melhor solução é utilizar a biblioteca Yahoo User Interface, ou YUI para os íntimos. Ela fornece todo o mecanismo necessário para a criação deste tipo de lista, e o Rails nos fornece os meios práticos e rápidos de gerar dinamicamente estas listas. Todo o procedimento para usar o treeview da YUI em conjunto com o Rails pode ser visto neste endereço. Os Helpers do Rails nos dão o meio necessário de tornar este processo o mais indolor possível. O resultado visual é como na imagem abaixo abaixo:

Quanto aos CMS, o mais usado parece ser o Radiant, usado em sites como na da SurgeWorks, empresa voltada ao desenvolvimento web com Ruby On Rails. Entre suas qualidades, o Radiant apresenta uma interface elegante, possibilidade de organizar páginas hierarquicamente, sistema de caching, gerenciamento de permissões de usuários, e um sistema de plugins de comportamento. Este CMS possui suporte a um sistema de tags especial, chamado Radius, e também suporta Textile, Markdown, e nosso antigo conhecido HTML na hora de desenvolver o conteúdo das páginas. Radiant CMS é distribuído sob a MIT License.

Outros sistemas de CMS podem ser encontrados na Web, mas nenhum deles parece maduro o suficiente pra ser usado em um site de producão de uma empresa. Mas caso haja curiosidade, vale a pena citar o Typo e Mephisto pra quem quer ter um blog, e Streamlined e Rubricks para quem está atrás de um site mais tradicional.

No related posts.

Nesta última sexta-feira minha placa de rede morreu-se. Acabou-se do nada, foi para o céu dos hardwares junto dos meus trinta e oito drives de CD e DVD*. Como estava sem internet, e um computador sem internet é como um carro sem pneus, resolvi instalar o Windows no meu PC.

Nunca gostei do Windows Vista, mas como possuo duas cópias originais dele e nenhuma cópia original do Windows XP, resolvi instalar o Vista. Eu tinha deixado uma partição de 60GB no meu HD pra instalar o windows algum dia, e essa era a hora. Inseri o DVD do Vista, iniciei a instalação, preenchi o serial e já vi logo a frase dizendo “copiando arquivos”.

Fiquei encucado, porque ele não tinha nem perguntado em que partição eu queria instalar, mas deixei. Estava pensando “ahh, ele não apagaria minhas partições atuais assim do nada, sem nem perguntar ou dar algum aviso”.

Ah, como sou ingênuo.

Terminou a instalação, abri o meu computador, e vi lá só uma letrinha C:, com 308Gb livres. Quase tive um ataque cardíaco. SEM PEDIR PERMISSÃO, SEM AVISAR, sem nem apitar a campainha irritante do gabinete, o Windows Vista apagou tudo do meu HD e se instalou em uma única partição do tamanho total do HD.

Não, sério… maldita microsoft. O Linux há anos permite que você escolha e até modifique as partições antes de instalar. Se não querer permitir isso, podiam ao menos dizer que seus dados serão apagados se instalar o Windows Vista. Essa microsoft é fogo, é uma falta de respeito com os usuários que não é brincadeira não.

PS: A parada dos DVDs é quase verdade. Eu tenho meio que um toque de midas, mas em vez de transformar coisas em ouro, eu transformo drives de DVD em porta-copos.

No related posts.

Deixando de lado o desenvolvimento para desktop que abordei no capítulo anterior, vamos para o tema principal do artigo, desenvolver para a web. Provavelmente você já viu alguém falar que a web é o futuro, e todo este blá blá blá que não vou repetir aqui, apesar de achar que é verdade. Vale ressaltar todos os pontos fortes, que é a facilidade de escrever um aplicativo que vai rodar em todo tipo de Sistema Operacional, e até em celulares, sem muito esforço.

Dentro da área do desenvolvimento web existem tantas opções que é fácil ficar perdido. Você pode desenvolver programando em Java, ASP, .NET, PHP, Python, Ruby, pra citar as principais. Pode também ser o cara que programa scripts que rodarão no lado do cliente, que é o caso do javascript. Pode desenvolver aplicações irritantes em flash ou silverlight. Ou pode ser o gay o cara que desenvolve “a cara” do site, que é o gay designer. Caraca, quantas opções.

Conhecimentos Básicos

Existem algumas coisas que você deveria saber, independente de qual área dentro do webdesign você escolheu. Todos os envolvidos no processo deveriam ter uma boa noção de XHTML e CSS. Sim, eu disse XHTML. Esqueça o HTML, ele é feio, antiquado, bugado, e o principal: não tem regras rígidas, o que faz com que cada browser interprete o HTML do seu próprio jeito. O XHTML está aí há anos, aprenda.

Porque precisam desse conhecimento? Bom, porque todo mundo envolvimento no desenvolvimento web vai se deparar, mais cedo ou mais tarde, com a estrutura básica de toda página, que é o XHTML (pro conteúdo) e o CSS (pra aparência deste conteúdo).

Não importa em que linguagem você está desenvolvendo seu site, tudo aquilo sempre vai ser convertido pra XHTML na hora de enviar pro navegador do visitante.

As Camadas do Site

Todo site geralmente envolve três principais áreas na parte do desenvolvimento: linguagem de servidor, linguagem de cliente, e apresentação.

A linguagem de servidor, ou server-side scripting, é a linguagem que vai rodar “por trás dos panos”, fornecendo a lógica principal da aplicação. Funciona assim, sempre que o usuário faz um request (entra numa página, clica num link, etc), o pedido é enviado pro servidor. A linguagem server-side, então, recebe o request e faz o processamento. Depois, transforma o resultado final num XHTML e envia pro navegador. é a linguagem server-side que vai verificar se o usuário está logado, vai buscar informações no banco de dados, e por aí vai.

Como a linguagem server-side processa as coisas ANTES de enviar para o navegador, isso significa que uma vez que a página foi enviada ao navegador do usuário, não há mais nada que a linguagem server-side possa fazer até um novo request seja enviado. Ou seja, não é possível usar estas linguagens para manipular a página do usuário em tempo real. Para o usuário, a linguagem server-side não importa, e ele nem tem como descobrir qual linguagem está sendo usada.

A linguagem de cliente, ou client-side scripting, é a linguagem que é executada no próprio computador do usuário, e por isso é usada nas situações em que a linguagem server-side não tem alcance. Entre as linguagens client-side, temos o javascript, que é a única linguagem que realmente roda no navegador do usuário. Através do javascript é possível manipular a página do usuário diretamente, fazendo coisas dinâmicas que vão desde mudar o valor de um campo do formulário até criar uma área redimensionável que pode ser arrastada pela página.

Como todo o código javascript está no próprio navegador, o usuário pode ver o código e pode também, através do uso de uns programas, manipular o código. Isso faz com que as linguagens client-side sejam inseguras pra fazer coisas como acessar um banco de dados. Juntas, as linguagens server-side e client-side se complementam.

Existe mais uma forma de client-side, que são os aplicativos feitos em Flash ou Silverlight. Estes podem ser muito irritantes para o usuário, e deveriam ser usados apenas em situações bem específicas, como exibir vídeos ou criar um player de música.

Por último, no lado da apresentação, temos a parte em XHTML e CSS. Os navegadores são feitos para entender XHTML e HTML, e por isso todo conteúdo deve vir neste formato. O designer fica responsável por organizar os dados num XHTML, e criar um arquivo CSS que vai definir a aparência destes dados.

Na próxima parte, começarei a falar sobre cada linguagem específica, na área da web. Até lá…

No related posts.

Recebi uma sugestão do cara que é provavelmente meu mais antigo leitor aqui no blog, o Victor Mendes. E a sugestão dele é mesmo muito boa. Tão boa que resolvi criar uma série só com isso. O Victor, assim como muitas outras pessoas, está na faculdade, aprendendo essa coisa complicada que é a programação, e não sabe muito bem o caminho que vai escolher. O principal motivo disso, claro, é que as opções existentes simplesmente são mal explicadas, cheias de boatos e meias informações.

O melhor meio de resolver isso, então, é mostrar tudo o que sei dos caminhos a tomar, com seus prós e contras. Eu queria deixar claro pra todo mundo que tudo que vou falar aqui é sem frufrus, curto e grosso. Você pode discordar das coisas que falo, mas não me venha com papo de fanboy de que “minha linguagem é a melhor de todas”, porque não tenho mais paciência pra esse tipo de gente.

O foco vai ser o desenvolvimento web, mas antes disso preciso falar sobre duas linguagens muito usadas no desenvolvimento de aplicações desktop: C++ e Java. Principalmente porque você VAI ver estas linguagens na faculdade, e nada melhor do que ouvir opiniões sobre elas.

C++

Pessoalmente eu classifico as linguagens de programação entre dois extremos. Se imaginarmos que toda linguagem é um veículo que serve pra te levar do Rio de Janeiro pra São Paulo, podemos imaginar os extremos assim:

Temos as linguagens são como um caça. Se você souber os botões certos, elas podem te levar pra São Paulo bem rápido. Mas saber os botões certos é o principal problema. Quando você entra num caça e olha pro painel, vê que tem tanto botão, tanto mostrador, tantas alavancas que é complicado até mesmo fazer aquilo começar a se mover. Por outro lado, temos as linguagens que são como um trem. Basta entrar na cabine, empurrar a alavanca pra frente e garantir de que está nos trilhos certos, e você chega a São Paulo.

C++, pra você entender, é o caça. Não só o caça, mas é o caça com a maior quantidade de botões, painéis e alavancas. Pra você realmente fazer um caça C++ levantar vôo, voar rápido e chegar em São Paulo você precisa ser um senhor programador, e tem uma paciência de Jó. O código C++ é visualmente feio, cheio de códigos ilegíveis, você tem que ficar se preocupando com os malditos ponteiros… e mesmo que aprenda tudo isso, as ofertas de emprego são poucas.

É sério, as pessoas preferem outras linguagens pra desenvolver programas desktop, justamente pra evitar o trabalho extra e a dor de cabeça. Apesar disso tudo, nas mãos do programador certo, os programas C++ podem ser bem leves e rápidos.

Java

Ah, o java, o queridinho das empresas. Não posso garantir daqui a muitos anos no futuro, mas sabendo Java você terá facilidade de arranjar emprego, já que a impressão que se dá é de que toda maldita empresa usa java. Voltando à nossa analogia, Java ainda está muito mais pro lado do caça, só que é um caça com menos botões e alavancas. A desvantagem? É um caça com um único motor, e esse motor foi adaptado de um Fusca ‘87.

A menos que você tenha um computador bem rápido e moderno, os programas Java vão ser pesaaaaados lentos. Mas mesmo assim são bastante usados. Estou falando sério, nos computadores aqui onde trabalho eu não posso nem sonhar em usar uma IDE feita em java, porque basta abrir a IDE que todo o computador pára.

Mas se você quer seguir o caminho do desenvolvimento pra desktop, muito provavelmente vai ter que aprender Java. Ao menos fique feliz que Java não é C++, e você não terá que ficar se preocupando com os ocultismos bizarros necessários pra se fazer um programa em C++.

E na web?

Bom, escrevi demais… isso fica pras próximas partes.

Escrevi outras partes deste artigo. Leia aqui a parte 2, e a parte 3.

No related posts.

1 – Interface fora do padrão

Os elementos padrão de interface – links, botões e radio buttons – são as unidades lexicais que formam o vocabulário do design. Mudar a aparência ou comportamento destes elementos é como introduzir num texto palavras numa língua estranha. Alguém pode até entender, mas det vil gøre læserne forvirrede (ou, em português, “fazer isso vai confundir seus usuários”).

Mesmo que você seja capaz de mudar a interface padrão e torná-la ainda melhor que a original, muitos usuários se sentirão confusos com ela, justamente por ser diferente das interfaces que já viram até agora, e diferente do que esperam.

2 – Inconsistência

A confusão acontece quando uma aplicação usa diferentes palavras para se referir à mesma coisa, ou quando usa uma palavra para se referir a várias coisas diferentes. Quando você se refere a algo com um nome numa página e com outro nome em outra página do mesmo site, seu usuário fica confuso.

Usar a mesma palavra para a mesma coisa no mesmo lugar torna as coisas mais fáceis.

Lembre-se: diferente = difícil.

3 – Nenhuma funcionalidade perceptível

Por “funcionalidade”, eu me refiro ao que cada elemento da interface pode fazer. Um checkbox tem a funcionalidade de marcar e desmarcar. Uma barra de rolagem tem a funcionalidade de arrastar pra cima ou pra baixo. Funcionalidades perceptíveis são as funcionalides que você percebe só de olhar para um elemento da interface.

Numa aplicação com interface visual, onde tem tanta coisa colorida e diferente na tela, é muito importante que o usuário possa entender as funcionalidades dos elementos só de olhar para eles. Os que mais sofrem com isto são os elementos de “arrastar e soltar”, que geralmente não fica claro para o usuário o que ele pode arrastar, pra onde pode arrastar ou o que acontece quando o arrasta.

4 – Nenhum feedback

Um dos pontos mais importantes de qualquer interface é oferecer algum tipo de feedback, um retorno ao usuário como resultado de sua ação. É necessário deixar claro para o usuário três coisas: o estado atual da aplicação, como a ação do usuário foi interpretada, e o que está acontecendo.

Sites feitos em ajax que não possuem indicativos visuais são um belo exemplo disso. O usuário clica no botão e a ação está sendo processada em paralelo por trás dos panos, mas nada é mostrado para o usuário e ele se pergunta se o botão tem algum defeito ou se o site está lento.

5 – Péssimas mensagens de erro

Mais cedo ou mais tarde algum erro acontece, e é preciso explicar ao usuário exatamente o que aconteceu, e como evitar que aconteça de novo. Até hoje temos um número enorme de aplicações com mensagens enigmáticas de erro ou, pior, apenas uma mensagem do tipo “erro 42″.

6 – Pedir a mesma informação duas vezes

O usuário só deveria ter que inserir cada informação apenas uma vez. Os computadores são muito bons em lembrar coisas, e se o usuário precisa inserir mais de uma vez uma informação é porque algum programador não fez seu trabalho muito bem.

7 – Nenhum valor padrão

Sempre que possível, todo tipo de elemento que necessite de algum input do usuário deveria ter valores padrão já preenchidos. Isso traz muitas vantagens, como acelerar a interação do usuário com a aplicação, demonstrar para o usuário qual o valor mais provável para ensinar através de exemplo, e direcionar usuários novatos para um resulto mais seguro ou comum.

No related posts.

Tenho prestado atenção há tempos num vício que a faculdade cria em nós de sempre responder a uma avaliação da forma mais extensa possível, pra não dizer que é de forma “enrolativa” (sim, eu gosto de neologismos). Não basta apenas responder o que foi perguntado, para ganharmos a nota máxima precisamos dar três voltas em torno do assunto a passos arrastados, nos aproximar com cautela e só então dar a resposta.

No mundo de verdade lá fora, no mundo real das empresas onde os profissionais estão sempre correndo contra o relógio, os problemas devem ser solucionados de forma rápida, direta. As pessoas precisam ir direto ao ponto. Nas universidades, por algum motivo completamente desconhecido, parece que todos os professores decidiram em uníssono seguir o caminho completamente oposto. Uma solução direta para um problema é punida com uma nota apenas parcial. Você não consegue a nota máxima sem enrolar e resolver o problema de um jeito extenso e demorado.

Até reparei isso recentemente ao fazer uma entrevista de emprego. Sorte minha que foi com algo simples. Ao ter que escrever uma query em SQL, eu precisava unir duas tabelas. Eu poderia ter colocado uma simples vírgula entre os nomes da tabela, e eu tinha noção disso, mas viciado pelas avaliações de faculdade eu tive todo o trabalho extre de escrever por extenso “INNER JOIN” para uni-las. Pior ainda que o entrevistador citou este fato, me lembrando que teria sido melhor ter apenas colocado a vírgula.

Ao sair da faculdade, todos os vícios que eles levam 4 (ou 5) anos pra enfiar na nossa cabeça precisam ser eliminados. É preciso botar muita coisa pra fora e reaprender a fazer muita coisa do jeito certo, sem enrolar. E depois acham estranho quando as empresas reclamam que muita gente da área de TI sai da faculdade sem estar apto pra trabalhar…

PS: Este post saiu muito mais fraco do que eu esperava. Provavelmente é por estar há tanto sem escrever. Acreditem que os próximos textos vão ser melhores. Eu juro pelo Bill Gates mortinho.

No related posts.