O mercado de tecnologia da informação tem buscado profissionais capazes de analisar criticamente o ambiente de desenvolvimento web, com visão orientada para qualidade e melhoria de processos. Atento a esse cenário, o Centro Universitário Senac lança a pós-graduação Engenharia Web, a primeira dessa categoria no Estado de São Paulo. Duas unidades, Senac Lapa Tito e Senac Santo André, vão oferecer o curso no próximo ano, capacitando em 366 horas interessados em planejar e coordenar projetos nesse segmento.

“Definida como o uso sistemático da engenharia no desenvolvimento, na implantação e manutenção de aplicações web de alta complexidade, trata-se de uma nova área do conhecimento, ainda pouco explorada. No Brasil, percebe-se que esse trabalho representa uma parte significativa da produção de empresas de softwares”, comenta Richard Martelli, técnico da área de tecnologia da informação do Senac São Paulo. Além dessas organizações, o engenheiro web pode atuar em instituições de comércio eletrônico, de design, de publicidade, portais de conteúdo, comunidades virtuais, bem como órgãos governamentais e ONGs.

Apesar de fortemente baseado na engenharia de software, o curso apresenta como diferencial ao aluno o tratamento multidisciplinar, tendo como público-alvo é formado por profissionais de análise de sistemas, ciências da computação, sistemas de informação, engenharia de software, web design e mídias interativas, além de pessoas que já atuam na área e desejam uma compreensão mais abrangente.

Mais informações podem ser obtidas em www.sp.senac.br ou diretamente no Senac Lapa Tito e Senac Santo André.

1. Python: A linguagem mestre, sempre liderando qualquer projeto. Curiosamente, até em projetos onde o Python não é a linguagem principal, ele exerce sua influência: estou sempre pensando “Pythonicamente” para resolver problemas, aplicando o Zen que a comunidade e linguagem prega. Não é apenas linguagem: é Filosofia!
2. Django: Nem todos projetos são Web, ou 100% Web. Mas os que atendem a esse requisito, sempre tem esse maravilhoso framework direcionando os trabalhos.
3. Javascript: Para muitos, é algo bizarro. Para mim, que trabalho a maior parte com interfaces e interação do usuário com os sistemas, é a arma. E como já disse para muitos amigos de trabalho: “Para mim, Javascript é o Python rodando diretamente no Browser.
4. jQuery: Muitas vezes esse framework chega a se sobrepôr a própria linguagem. Em muitos projetos, dá até pra dizer que temos “mais linhas jQuery do que Javascript puro”. Mas o que isso quer dizer? Que Web sem jQuery realmente é muito mais difícil e demorado! Gosto tanto do framework que criei até uns plugins
5. Firebug: Se eu tiver de nomear um dos items como minha Shuriken, o Firebug seria sem dúvida! Muito prático, rápido e a ferramenta ideal para “prototipar” qualquer interface. Ainda mais se o cliente estiver do seu lado, esperando uma resposta sua: Você abre o console, algumas linhas e opções depois, você mostra pra ele como pode resolver  o problema… e negócio mais próximo de estar fechado!
6. Mercurial-HG: Devo confessar, antes usava SVN, e quando a vida me exigiu mudar para Mercurial, tive um pouco de resistência. Mas hoje, alguns meses depois, só vejo vantagens, principalmente  após usar os excelentes recursos do Bitbucket e saber que várias boas ferramentas que utilizo, inclusive o próprio Python, tem seu código armazenado por lá, e também que Mercurial é uma ferramenta escrita em Python.
7. Eclipse: Não vou morrer se o Eclipse não abrir… mas vou ganhar várias horas de lazer com algumas praticidades que ele traz: com essa IDE, eu centralizo diversas outras ferramentas, libraries, automatizo alguns procedimentos, debugs, vários ambientes de execução e depuração customizados com fácil acesso… enfim, um verdadeiro Canivete Suíço! Claro, ele tem que estar turbinado com alguns plugins, tais como: Aptana, PyDev, Mercurial, etc.

E assim como outros fizeram, vamos às menções honrosas de outras ferramentas que fazer uma pontinha no ambiente com menos frequência. Percebam que muitas ferramentas são claramente feitas para rodar em Windows, geralmente para suprir necessidades que são padrão no Linux

1. Ubuntu: Companheiro de cada dia! Geralmente uso Windows por conveniência (sempre compro notebooks com Windows original pré-instalado, e dá uma preguiça de instalar e configurar um novo sistema… apesar de que nas últimas versões de Ubuntu esse processo estar facílimo!). Certas coisas na vida de um desenvolvedor só são possíveis num sistema Linux, e Ubuntu é o mestre nesse aspecto. Um exemplo é um projeto recente que estou trabalhando que envolve processamento de vídeo, usando FFMpeg e PyFFMpeg. Praticamente impossível de rodar em Windows… porém, no Linux, é mamão-com-açúcar…
2. Google App Engine SDK: Ferramenta essencial para projetos dentro da plataforma do Google. Quando usando com Eclipse, basta integrar no ambiente ou no projeto e o Eclipse/Pydev faz toda a interface pra você.
3. Putty: Quando não no Linux, uma ferramenta essencial para conectar-se a sistemas remotos.
4. iPython: Mão na roda para agilizar alguns comandos experimentais e em testes (Experimentando o DreamPie também)
5. XAMPP: Outra ferramenta indispensável quando desenvolvendo fora do Linux
6. phpMyAdmin: Muita gente torce o nariz, mas essa ferramenta é muito boa e prática. Só não é melhor por não ser em Python, .
7. Skype: Para conversar com a equipe, clientes, e até fazer pequenos treinamentos
8. DropBox: Backup e compartilhamento entre máquinas remotas. Uso principalmente como backup automatizado do meu ambiente de desenvolvimento remoto e até apaga alguns
9. VMWare Player: Para rodar mais de um sistema de uma vez, permitindo testes (compatibilidade e usabilidade) mais rápidos e práticos
10. VNC / Win2VNC: Também para rodar mais de um sistema de uma vez, mas aqui, para controlar mais de uma máquina com um único teclado e mouse, não para visualização remota (inclusive, acho horrível…)
11. Pencil (Firefox Add-on): Para fazer Wireframes

Para dar continuidade, convido os amigos para seguir nesse trend:

@mauriciosl
@jeanwainer
@ergalassi
@marcelohonorio
@odranoel
@Ericgoes
@marcosriso

function zip() {
    var merged=[],arrays=[],lengths=[];
    for(var i=0; i<arguments.length; i++) {
        arrays.push(arguments[i]);
        lengths.push(arguments[i].length);
    }
    for (var i=0; i < Math.min.apply(null,lengths); i++) {
        merged[i] = arrays.map(function(value) { return value[i]; });
    }
    return merged;
}

Enjoy!!!

Qual webdeveloper nunca usou jQuery? Muito difícil… Bom, mas vamos falar de algo que nem todos os developers que usam jQuery se atentam ao programar. Eu mesmo fui pego hoje por um gap que me tomou alguns minutos da tarde…

Algumas funções (na verdade, a maioria nesse framework) recebem outras funções como callback, aquela função que será chamada assim que a instrução/função chamada acabar seu procedimento. Um exemplo muito utilizado em aplicações reais são as

Funções Ajax

load( url, data, callback )
Returns: jQuery. Load HTML from a remote file and inject it into the DOM.

jQuery.get( url, data, callback, type )
Returns: XMLHttpRequest. Load a remote page using an HTTP GET request.

jQuery.getJSON( url, data, callback )
Returns: XMLHttpRequest. Load JSON data using an HTTP GET request.

Ao usar a função load, você carrega um arquivo remoto (seja ele html puro ou um arquivo dinâmico, como PHP ou outra linguagem), mas o tempo que ele leva para ser processado nem sempre é igual. E se você precisa esperar que o conteúdo seja totalmente carregado antes de proceder com o script?Colocar um timeout? No way, uma vez que você não tem controle sobre o tempo de execução em todas as plataformas e clientes… Logo, o Callback está aí para sanar essa questão.

Porém…

Temos que tomar cuidado ao usar o Callback, uma vez que o desempenho dos sistemas ainda podem afetar a funcionalidade de seu código, e fazer você perder várias horas de seu precioso descanso…Veja esse trecho de código que trabalhei recentemente:

jQuery().ready(function() {
   jQuery.getJSON('/php/data.drafts.php?l=10&f=json', function(data){
      jQuery.each(data, function(i, item){
         jQuery('#latestDraftsTable tbody').append('<tr><td>'+item.id+'</td><td>' + item.title + '</td><td>' + item.date+ '</td></tr>');
      });
   });
   jQuery('#latestDraftsTable').tablesorter({widgets: ['zebra']});
);

Alguém consegue perceber o erro, ou melhor, a Zebra? Muito difícil. Mas ao rodar o código, não acontecia o esperado: que minha tabela apresentasse o comportamento de uma tabela ordenável que o jQuery UI tablesorter plugin proporciona (ou seja, deu Zebra e não ocorreu a Zebra). Aí eu descobri o problema: a penúltima linha do código nem estava sendo executada… Seriam Gaps de performance?

Diferentes paradigmas

Fosse uma linguagem das antigas qualquer, onde o paradigma procedural imperava, esse código não teria problema, pois cada instrução só seria disparada ao final da anterior. No Javascript, a coisa não é bem assim, ainda mais quando se trata de AJAX -Assynchronous Jacascript and XML – uma requisição que é disparada e outra estrutura interna fica encarregada de processar os resultados quando eles chegarem. Ao efetuar a função getJSON, a requisição é disparada, e já passamos para a próxima linha (onde eu chamo o tablesorter na tabela), porém, não deu tempo da requisição JSON retornar e popular a tabela. Resultado: minha tabela fica populada mas não fica ordenável.

Graças a um amigo developer fera em JS, eu consegui perceber isso e reordenaro código de maneira que ele funcionasse como o esperado:

Código corrigido

jQuery().ready(function() {
   jQuery.getJSON('/php/data.drafts.php?l=10&f=json', function(data){
      jQuery.each(data, function(i, item){
         jQuery('#latestDraftsTable tbody').append('<tr><td>'+item.id+'</td><td>' + item.title + '</td><td>' + item.date+ '</td></tr>');
      });
      jQuery('#latestDraftsTable').tablesorter({widgets: ['zebra']});
   });
);

Assim, o tablesorter vai ocorrer dentro do callback, logo após ter terminado de ser populada a tabela. Na realidade, os callbacks foram feitos exatamente para situações como essa: quando a coisa vai demorar um pouco e você não tem certeza do quanto…

Lembro até de campanhas internas para lembrar alguns desenvolvedores que o IE deveria estar instalado em suas máquinas para entrar no esquema de testes. Espero que o IE6 não esteja mais na maioria das máquinas, como acontecia também (afinal, ter um IE6 em sua máquina é um risco considerável…).

Como disse a editoria de Tecnologia do IG, a IBM adotou o browser por sua veia OpenSource (uma quebra de rotina dessas só poderia partir mesmo do braço livre da empresa), por ter melhor suporte para extensões (aqui com certeza os desenvolvedores quem bateram o pé) e a meu ver, principalmente por ser mais customizável (e assim, a gigante poder ter um melhor controle das ferramentas utilizadas por seus colaboradores, como recursos). Claro, podemos esperar outros motivos ainda, afinal, empresas desse porte nunca fazem mudanças globais sem antes calcular minuciosamente o quanto poderão economizar/ganhar com uma ação dessas. Talvez vejamos em alguns meses alguma nova ferramenta interna sendo vendida globalmente, baseada na tecnologia do browser.

Mas claro, quem conhece, sabe que os benefícios de adotar um browser mais robusto são muito bem vindos, seja sua empresa pequena ou gigante.

Confira mais no iG – Tecnologia

Quem acompanha o blog sabe que esporadicamente posto links para podcasts de assuntos relacionados a THLopes. E aqui está mais: o Nerdcast de hoje, cujo tema é Profissão: Programador. Como este que vos escreve atua nessa profissão, recomendo ouvir esse excelente podcast para fechar sua sexta-feira. Boas risadas e descobertas!

Com esse título (e com esse logo), poderiamos começar uma novela. Mas estamos falando de outra novela: a da migração de banco de dados MySQL para Cassandra. Depois do Twitter, agora é o Digg quem decidiu migrar suas bases de dados para esse banco com um nome bem interessante.

Cassandra é um banco de dados pós-relacional. Mas como esse termo não é muito conhecido, utilizaremos o termo NoSQL. Um repositório de dados leve, feito em Java, similar aos famosos CouchDB (outro projeto que, assim como o Cassandra, é incubado na Apache Incubator) e BigTable, utilizando ferramentas similares ao Hadoop (coincidência? Mais um projeto incubado na Apache) e conceitos como MapReduce (para bancos distribuídos). Agora vem o fato mais curioso: Esse projeto foi inicialmente desenvolvido pelo Facebook, e foi aberto (open source) em 2008. Mais uma rede social, crescendo e migrando para bases não-relacionais. Que ironia: justamente as redes sociais, onde as relações são muito valiosas.

Apesar do ganho no desempenho, sei que esse tipo de transição é muito “dolorosa”. Esses tipos de banco de dados não-relacionais realmente podem dar um nó no cérebro dos desenvolvedores. É muito complicado viver sem os joins depois de algum tempo trabalhando com eles.

Segundo os engenheiros do Twitter, precisavam de um banco de dados escalável que “crescesse sozinho”. Realmente, imaginar monstros como Twitter – que cresceu mais de 20 vezes em menos de um ano, alcançado a marca de 50 milhões de Tweets diários – e do Digg (onde muitos usuários compartilham notícias e comentários o tempo todo) e seus dba’s brigando todos os dias para conter a bomba do MySQL, enxertando cada vez mais hardware para que não exploda na cara dos usuários. Nessa hora, é questão de escolha: onde vamos quebrar a cabeça para resolver o problema? Os desenvolvedores decidem.

corMVC é um framework MVC para Javascript, baseado em jQuery. Voltado para aplicações web de uma página só, onde você executa todas suas operações em estilo Ajax, na própria página. Segundo os criadores, é execelente como ponto de entrada para aprendizado da arquitetura de ‘single-page application’ (aplicação de página única, como mencionado anteriormente).

É simples de começar a usar, não necessita de nenhum linha de comando, basta extrair tudo numa pasta e abrir no browser. Estou testando aqui e em breve posto meus comentários a respeito.

Encontrei esse projeto através do LinkedIn. Incrível, o autor consegue gerar um ambiente animado, onde você pode interagir com outros elementos, o cenário tem profundidade, e você pode guiar seu personagem através desse ambiente, usando o teclado, para qualquer direção. Até aí normal, porém, ele fez tudo usando apenas Javascript, sem nenhum Flash sequer. Ver essa audácia me relembrou a época em que desenvolvi um game 2d em Java, na faculdade, o K-Libre99, totalmente do zero.

O mais bacana é que ele demonstra que podemos sim ter coisas complexas feitas na web, com Javascript (que é nativo de qualquer browser hoje em dia), sem depender de plugins externos, como o Flash. Realmente, um trabalho excelente, demonstrando que a web não é dependente de Flash para criar experiências de usuário dinâmicas. Confira mais em http://www.geektestbox.com/devfiles/mdunham/brookside_beta/

Nos últimos dias, temos brigado muito por coisas muito pequenas, as vezes passageiras. Cada migalha desperdiçada é motivo para um nova discussão que acaba mudando o rumo das coisas… Calma gente, não estou tendo problemas de relacionamento não, são apenas discussões sadias de trabalho para se melhorar os níveis de performance nos aplicativos.

Quando se atinge um certo número de usuários de uma única aplicação, devemos tomar certos cuidados. Muitas vezes, ignoramos alguns pontos que podemos melhorar, deixando 1KByte, 2KB mais leves, pois afinal, para um usuário parece tão pouco, mas quanto representa 2KB multiplicado por 100 mil usuários? 195 MB. É, assusta, e as cifras só tendem a aumentar.

Com o advento da computação em nuvem, alguns perceberam que realmente deveriam otimizar suas aplicações, pois cada KB gasto vai representar algum valor que será, com certeza, debitado num cartão de crédito futuramente. Enquanto antigamente, bastava planejar a compra de uma máquina muito além das necessidades e ter um custo fixo, agora, a briga é para sempre diminuir a conta no fim do mês, como numa economia doméstica (certa vez, ouvi que toda economia é de migalhas. Concordo).

Mas muitas vezes, desenvolvedores de aplicações esquecem de alguns detalhes como por exemplo, o peso dos arquivos da camada de apresentação de suas aplicações. Na Web, isso também deve entrar na conta: tamanho do HTML, CSS, JS e imagens. E hoje em dia, são relativamente conhecidas técnicas para aprimorar esses estáticos para uma melhor experiência do usuário. Digo relativamente porque ainda me deparo com muitos websites, sistemas e gadgets por aí sem nenhuma otimização nesse sentido. No Brasil ainda temos muitos usuários que não dispõe de banda larga, e eles agradecem cada byte salvo.

Primeiro passo: Limpeza

Um arquivo limpo de tudo que não é necessário é muito melhor, sem dúvida. Elimine dos arquivos aquelas linhas velhas, cheias de comentários inúteis, atributos desnecessários, funções que não são usadas, variáveis zumbis (que estão ali apenas para … nada). Em minha última façanha do tipo, deu pra economizar cerca de 10KB. Como vamos usar uma ferramenta mais pra frente, não precisa deletar nada do arquivo ainda, a não ser que queira ver o quanto você ganhou com esse processo. Comentários podem ser mantidos, e métodos “depreciados” podem ser mantidos comentados também (eu faço isso para armazenar código que venha a ser útil ou que queira manter no histórico para referência rápida).

Reavaliação

Depois desse passo, é a hora de fazer uma certa mágica. Esse passo depende de experiência do usuário, e que tenha um bom conhecimento de lógica e da linguagem em si: reavaliar seu código, diminuindo estruturas de código sem aumentar a quantidade de cálculos, quando não diminuindo o custo computacional (análise assintótica). Isso pode envolver uma análise mais  matemática do código, estimando o número máximo de comparações e operações que ele pode executar. Por isso demanda um profissional graduado. Mas lembre-se: não sacrifique o processamento em troca de tamanho de código! Diversas vezes um código maior e mais específico pode rodar muitas vezes mais rápido. Também, outras vezes, uma simples instrução a mais pode representar um laço a menos.

Comprimindo o código: YUI Compressor

Esse compactador transforma seus arquivos JS e CSS em versões minificadas: com sintaxe reduzida, sem quebras e espaços desnecessários, sem comentários, tudo numa única linha. Isso pode reduzir drasticamente o tamanho do arquivo sem alterar seu conteúdo (eu consegui em minha última utilização a marca de reduzir um .js de 135KB para 84KB!!!), o que é o que buscamos (afinal, quem quer codificar duas vezes a mesma coisa? Otimizar tempo também é muito importante! O YUI Compressor é muito prático e rápido para essa tarefa.

Apenas para exemplificar: ele também altera as assinaturas das suas funções/classes:

function xyz(value_1, value_2) {
    this.param_1 = value_1;
    this.param_2 = value_2;
    ....

Ficará assim, num primeiro momento, assim:

function xyz(f, g) {
    this.param_1 = f;
    this.param_2 = g;
    ....

E depois, assim:

function xyz(f,g){this.param_1=f;this.param_2=g;....

Não se preocupe! Tudo vai funcionar normalmente. Mas podemos perceber que esse compressor realmente vai diminuir seus arquivos. Na tabela abaixo, pode ver o que esses três métodos podem fazer com o peso da sua aplicação:

Um ganho de ~50% no peso total da aplicação, apenas na parte de storage e fileserv.

A União faz a Força Velocidade

Se possível, junto todos os arquivos num único. Tem vários .js? Faça apenas um. O mesmo para os CSS. No protocolo HTTP/1.1, temos uma definição que recomenda não ter maiss de duas requisições sendo processadas ao mesmo tempo para o mesmo servidor. Alguns browsers, como o I.E., seguem isso a risca. Logo, quanto mais arquivos tiver para carregar, pior: mais conexões serão necessárias para atender a demanda, e como o browser só fará duas ao mesmo  tempo, o usuário vai ter que esperar. Aposto que você até teve aquele momento “lâmpada sobre a cabeça” agora, imaginando se poderia fazer isso também para as imagens… e poderá! Veja a seguir no próximo tópico. Uma outra dica para sanar esse problema das conexões simultâneas é manter arquivos em vários servers diferentes.

Sprites

Essa já é mais complicada (principalmente para os desenvolvedores não designers, pelo skill necessário), mas pode significar um gadget/site muito mais rápido para o usuário final. Assim, imagine você carregando vários arquivos .png, os ícones da sua aplicação, por exemplo. Seguindo esse conceito, eles vão ser carregados apenas 2 a 2, mesmo que o usuário tenha uma banda larga suficiente e seu servidor um canhão para carregar muito mais do que isso (falando em tamanho).

Para sanar essa deficiência indireta, uma técnica utilizada são os sprites: você coloca todas as imagens num único arquivo .png (pode ser outra extensão, se aplicável, mas eu recomendo essa), e com os comandos CSS, você seleciona apenas a parte que deseja. Assim será possível usar todo o potencial da banda disponível para trazer todos seus ícones numa única conexão com o servidor, enquanto a segunda concorrente pode ser uma fonte de dados essencial para seu funcionamento.

Nesse tutorial do A List Apart você encontra uma extensa referencia sobre a técnica de sprites.

Concluindo

Bom, com estas ações simples, aposto que sua aplicação será bem melhor carregada, economizará até alguns $$$ para poder me pagar uma cerveja. Sendo assim, deixe seus comentários e dicas nos comentários, caso eu tenha deixado passar alguma! Em breve, um artigo sobre otimização de banco de dados e de fluxo de aplicações.