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 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.

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.

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á…

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.

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.

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.

Com arquivos muito grandes, se você quiser atualizá-los você normalmente precisa criar uma nova versão deste arquivo, com as mudanças. Acontece que nesta nova versão, muita informação é repetida. Tudo que não foi mudado acaba sendo repetido. Imagine um arquivo de 2Mb, onde vc mudou apenas o equivalente a 5Kb de informação nele. Normalmente você teria que enviar um novo arquivo completo com os 2Mb pra todo mundo que precisa ter a nova versão. Com as ferramentas diff e patch, você pode fazer diferente.

Um método mais prático não seria poder enviar apenas um arquivo contendo informações sobre as mudanças realizadas no arquivo, e deixar o computador realizar as modificações necessárias? Pois isso é possível, com estes dois recursos do linux. Para entender melhor, vou dar um exemplo.

Criamos uma lista de frutas, e chamamos o arquivo de frutas1.txt. Nele, colocamos o seguinte conteúdo:

Banana
Uva
Limão

Criamos então um segundo arquivo chamado frutas2.txt, com o conteúdo do frutas1, mas adicionando uma nova fruta no final da lista:

Banana
Uva
Limão
Melancia

O comando diff nos permitir descobrir a diferença entre dois arquivos, e esta diferença é feita de um modo que o linux pode entender também. Digitando “diff frutas1.txt frutas2.txt” temos o seguinte resultado:

3a4
> Melancia

Interessante, não? Ele encontrou exatamente a diferença entre os dois arquivos e descreveu esta diferença. O mais interessante é que podemos exportar essa diferença para um arquivo de texto. Assim temos o que queríamos ali em cima, um arquivo contendo apenas as informações do que foi alterado, sem ter que repetir todo o conteúdo. Isto é feito com o seguinte comando:

diff frutas1.txt frutas2.txt > diferenca.001.patch

Assim criamos o arquivo diferenca.001.patch contendo as informações sobre as alterações em um arquivo. Então, a qualquer momento, podemos usar este arquivo de patch para aplicar estas informações no arquivo original. Para isso usamos o comando patch disponível no linux, da seguinte forma:

patch frutas1.txt < diferenca.001.patch

Se checarmos o conteúdo do arquivo de texto frutas1.txt novamente, veremos que ele contém as quatro frutas, ou seja, tornou-se idêntico ao arquivo frutas2.txt.

Este recurso é uma ótima ferramenta para desenvolvedores, principalmente se você vai trabalhar com diferentes versões de seus projetos. Outra grande utilidade, por exemplo, é se você estiver criando um projeto open-source que aceitará ajuda de terceiros. Em vez de ter que enviar uma nova versão de um arquivo, outras pessoas poderiam colaborar enviando apenas o patch. Este recurso possui mil e uma utilidades, basta que você dê a ele um bom uso.

A web, por sua natureza, á uma plataforma muito melhor do que o desktop para as aplicações universais, que rodem exatamente da mesma forma em qualquer sistema operacional. Basta você fazer uma única aplicação web, e ela rodará no Windows, Linux, Mac, Solaris, React OS, e muitos outros sistemas operacionais. E ainda com a vantagem de seus dados do programa poderem ser acessador de qualquer computador, já que todas as informações estão salvas na web.

Mas… criar aplicações que rodem em todo lugar não é justamente a proposta do java? Nós temos aqui, então, uma concorrência, uma disputa entre duas plataformas que, embora distintas, possuem um mesmo objetivo. Sendo ainda que o java perde pontos por ser lento como um dinossauro de pantufas.

A previsão de muita gente na área é de que o Java será usado cada vez menos, sendo substituído pelas aplicações online. E, pelo que parece, isto já começou. A nova versão do Mac OS (Leopard) não possui qualquer suporte ao Java 6, e ainda possui um suporte mínimo (e insuficiente) ao Java 5.

A reação de muitos usuários do Mac a isso não foi tão ruim. Muitos só disseram que nem usavam java mesmo, e seguiram adiante. Se pararmos pra pensar, o Java realmente faria falta hoje em dia? Quanto programas java você usa que não possuem um substituto equivalente para seu SO, e nem possuem um correspondente online? Será que ele não poderia ser reconstruído como uma aplicação web e você nem sentiria a diferença?

Eu queria ver opinião de leitores sobre isso, e o que acham do futuro as aplicações java e das aplicações online. Será que o java continua pelos próximos anos sem perder uma boa parcela do mercado?

Se interessou pelo assunto? Encontre livros de java com os melhores preços no JáCotei!

Nos primórdios da web, quando o conhecimento era pouco e os recursos disponíveis eram menores ainda, havia um recurso bastante usado para montar a estrutura (layout) dos sites: a tabela. A pessoa montava uma grande tabela, com várias linhas e colunas, e ia colocando o conteúdo do site lá dentro. Era o único jeito de fazer o site ficar com a aparência desejada em todos os navegadores.

O tempo passou, o mundo mudou, e algumas pessoas começaram a usar outros recursos para montar a estrutura dos seus sites. Deixaram de usar tabelas e adotaram padrões web, e chamaram a isso de tableless. Se você está se perguntando por quê, temos muitas respostas. Em primeiro lugar, e mais importante, é o fato de que cada tag tem seu propósito, e a <table> não é exceção. Uma table (tabela) serve para exibir dados tabulares para o usuário. Dados parecidos com o que você vê numa planilha do excel. Usar table para montar o layout é usar uma tag fora de seu propósito, como usar um cachorro para pintar a parede. Você pode até conseguir molhar o cachorro na tinta e pintar a parede com ele, mas será que é pra isso que os cachorros foram feitos?

Em segundo lugar, por serem complexas de construir, as tabelas precisam de muito código para serem montadas. Então usar tabelas para montar seu layout acaba entupindo seu site de código html, aumentando o tamanho da página que o usuário precisa baixar. E se o usuário precisa baixar mais coisa, seu site será mais lento. Em terceiro e último lugar, o CSS já estava sendo suportado em todos os principais navegadores do mercado, além de economizar código e tornar mais prático o trabalho de desenvolvimento.

Para quem se interessa em SEO, há um outro motivo muito importante: como usar tabela no layout é errado, seu site acaba sendo “penalizado” por buscadores como o google. Ninguém quer que seu site se saia mal nos resultados de busca apenas porque o designer tem preguiça de aprender CSS.

E isso foi há anos atrás. Com o tempo, construir um site sem tabelas deixou de ser um diferencial dos bons profissionais e se tornou um requisito essencial de um designer. O tempo passou mais ainda e, hoje em dia, pessoas que ainda montam seus sites com tabelas são vistos por profissionais e empresas como grandes amadores, como pessoas que estão apenas brincando de “fazer sitezinho”, como um engenheiro veria você se fosse procurar emprego de engenharia dizendo que sabe montar casinhas com lego.

Você não quer ficar pra trás, você não quer perder a chance de conseguir aquele emprego só porque ainda está construindo sites como se vivêssemos em 1999. O CSS2 já está aí há anos, e o CSS3 está vindo. Se você ainda está montando seus sites com tabela, está na hora de rever seus conceitos.

Se interessou pelo assunto? Encontre livros de Web Design com os melhores preços no JáCotei!

Quem tem conta no feedburner e no google adsense pode agora entrar na opção Monetize do feedburner, e ativar a exibição de anúncios da sua conta do adsense nos feeds. Esta é uma ótima forma de se ganhar dinheiro online através dos feeds do seu blog.

O local onde trabalho atualmente já é o segundo em que sou obrigado a suportar computadores pré-históricos para desenvolver, e ainda esperam que eu seja produtivo. É difícil programar em uma máquina que, só de abrir o dreamweaver, trava por mais de um minuto. Dreamweaver e firefox aberto ao mesmo tempo? Só sonhando.

Programar pra web num Windows XP Professional com apenas 256MB de RAM? Só pro Chuck Norris e Capitão Nascimento. Não é tão caro comprar uma máquina decente. Não estamos falando de um PC pra jogos, só um pc que aguente rodar uma IDE mediana junto de alguns outros programas necessários sem travamentos.

Pessoas de TI, em geral, sabem ser improdutivas. Não que seja de propósito, mas é que temos tantas fontes de distração em um computador que mesmo nas condições ideias é difícil estar concentrado no trabalho o tempo todo. Dê a um programador um computador que só aguenta rodar paciência, e só o que ele vai fazer é jogar paciência. Ou blogar.

Quer comprar um computador? Compare preços de computadores no JáCotei!

Pessoas de todas as profissões acabam sofrendo com a falta de tempo, mas eu acho que ele é um inimigo muito mais cruel de quem trabalha na área de TI. Além de trabalhar, temos que continuar estudando e nos atualizando todo o tempo, pois 1 ou 2 anos trazem avanços e mudanças que podem revolucionar toda a sua área e fazer com que um profissional de TI que não estuda há alguns anos fique totalmente desatualizado e despreparado.

Não podemos comprar tempo, roubar tempo e nem alugar. Da mesma forma, não podemos criar tempo para nada. Só o que podemos fazer com o tempo é transferi-lo de uma atividade para outra. Se você quer passar a frequentar a academia 3 horas por semana, terá que tirar 3 horas semanais de outra(s) atividade(s). Saber gerenciar seu tempo diário é o que pode fazer a diferença entre um bom profissional e um mau profissional.

Acho que uma das melhores frases sobre este assunto eu encontrei na revista Você S/A, onde diziam que o tempo é um dos únicos recursos realmente democráticos do mundo. Porque não importa sua condição financeira, social ou cultural, a todos é dado exatamente 24 horas em um dia, e cabe a cada um de nós decidir o que fazer com o que nos foi dado.

Em questão de efeitos visuais, o Kubuntu se dá melhor. Pequenas animações e brilhos tornam o sistema bonito de usar mesmo sem instalar compiz ou semelhantes. No início não gostei muito de ter apenas uma única barra na tela, ao invés das duas barras do gnome. Claro que podemos mudar, mas com o tempo me acostumei e passei a gostar da barra.

Só achei que, comparado ao gnome, o KDE tem uma usabilidade muito ruim. No gnome as tarefas rotineiras podem ser feitas com menos cliques do mouse, o que é um ponto positivo. Por outro lado, a principal vantagem do KDE é uma maior integração de diversos programas entre si, e com o próprio sistema.

Por último, uma outra desvantagem no KDE é que ele é mais pesado que o gnome, mas nada que realmente faça uma grande diferença. No fim das contas, vou ficar mesmo com o KDE, porque o KDE 4 que vem aí vai ser fantástico. Outro dia escrevo sobre ele.

Entre as novas vantagens do sistema está algo que eu sempre senti falta ao instalar o linux em computadores de pessoas com menor poder aquisitivo: um bom suporte a softmodens. Sabe, aqueles modens mais baratos de conexão discada. Agora o Ubuntu detecta automaticamente seu softmodem e se oferece para instalar um driver não-livre para suportá-lo. Perfeito.

Além disso, o driver da placa de vídeo é detectado e instalado automaticamente. Isso é para suportar o Compiz, que já vem ativado por padrão nesta versão do Ubuntu. Falando no compiz, ele já era leve na versão 7.04, e nesta versão ele ficou ainda mais leve, conseguindo rodar numa em um notebook Positivo M25, que é um computador bem modesto.

Suporte total nativo a interfaces wireless é uma das outras vantagens do Gibão Valente (Valente, e não Sacudo!!). Sua rede wireless será rapidamente detectada, e conectar a ela será o mais simples possível. Tão simples quanto isso é instalar sua impressora, que é detectada assim que plugada na porta usb.

E, ainda, uma novidade pra quem usa notebooks: ele instala um driver para melhor suportar o touch pad, permitindo ainda usar o recurso de scroll horizontal e vertical nestes dispositivos. Já falei “perfeito”?

Várias outras vantagens te esperam, como instalação automática de codecs, suporte nativo a escrita em partições NTFS, mudanças na interface de configuração, e a lista continua. Quem quiser mais informação sobre o Ubuntu 7.10 pode ler esta análise mais profissional feita pelo ZumoBlog.