Com a popularização da tecnologia e da Internet ao longo dos últimos anos, temos observado que a rede é usada tanto para fins legítimos como para outros nem tanto assim. Uma mesma tecnologia pode dar acesso a uma grande fonte de conhecimento e conteúdos compartilhados como também pode ser utilizada para causar danos, já seja de maneira consciente ou como parte de um jogo.

Por isto, cada vez mais, o uso cívico e respeitoso da rede torna-se uma questão prioritária. Além da diversão e do aprendizado proporcionados durante a semana de celebração da Campus Party, este é o momento de agir e sermos responsáveis, fazendo nossa colaboração para que a tecnologia seja usada em benefício da humanidade e demonstrando que Internet não é apenas uma rede de computadores,
e sim, de pessoas.

É o momento de iniciar um movimento de conscientização e de iniciar e impulsionar #somethingbetter.

Durante meses, a equipe da Campus Party, junto a colaboradores e amigos de todo o mundo, desenvolveram um manifesto fundacional no qual acordamos em prol de um objetivo concreto e em prol da criação de um projeto maravilhoso, o programa de voluntariado tecnológico “GeeksansFrontieres” . Este projeto atuará em países realmente necessitados. Estamos construindo este ambicioso projeto com organizações amigas.

Como campuseiros podemos ser um coletivo chave para a mudança. Temos o conhecimento, a vontade e um grande alcance, algo que traduz-se em uma grande responsabilidade para conseguir mudar o mundo para o bem. Isto é dito constantemente mas, poucas vezes, temos a chance de transformá-lo em ações concretas. Em outras palavras, esta é uma oportunidade única.

Através do #somethingbetter, unidos, poderemos marcar a diferença na vida de muitas pessoas de forma positiva e a longo prazo.

Durante as próximas semanas, por meio do manifesto fundacional, iniciaremos um processo aberto para determinar ações em conjunto, para levá-las ao cabo e fazer deste mundo um lugar melhor.

Haverá premiação? Sim, claro!

Na categoria Campuseiros Inventam haverá um prêmio de R$100.000 (cem mil reais) para que o campuseiro possa se dedicar durante o ano, a fim de desenvolver seu produto! Uma ótima oportunidade para quem tem uma grande idéia e quer colocá-la em prática.

Além disso, haverá convite para participar de 5 Campus Party a sua escolha: incluindo o bilhete de avião, entrada VIC (Very Important Campusero), acampamento com barraca e 3 refeições diárias.

Para mais detalhes sobre o evento, premiações e inscrição, é só visitar a seção Campuseiros Empreendem no site da Campus Party.

Sintam-se a vontade para opinar e contribuir com suas próprias experiências!

Equipe

O primeiro passo (e mais importante) certamente é a formação da equipe, no qual são definidos os profissionais que contribuirão para a área e deve-se ter em mente quais são os pré-requisitos para preenchê-la.

Procure por pessoas que tenham o mínimo de conhecimento e tenha uma filosofia de trabalho parecida com a sua, ou seja, tenha os mesmos princípios e demonstre facilidade para atender o que se espera do trabalho a ser executado. No meu caso, gosto muito de profissionais que pesquisem, se interessem em aprofundar suas habilidades e busquem maneiras de inovar em seu trabalho.

Infelizmente encontrar bons profissionais hoje em dia ainda é difícil, então uma ótima maneira é pegar alguém “cru” que tenha uma boa base, para ser formado de acordo com as necessidades da equipe / empresa.

Mantendo esses pré-requisitos citados acima, teremos uma base sólida para a equipe, facilitando a continuidade dos procedimentos que citarei na seqüência.

Padrões

Em qualquer equipe é necessário padronização, seja para escrita de código como até organização de arquivos e pastas.

Ao longo destes (quase) dois anos, percebi como é importante essa etapa, já que muitas vezes participamos de um projeto mas, na seqüência, só outra pessoa está disponível para dar continuidade. Então se você conseguir engessar o processo de Desenvolvimento (ou até mesmo Criação), é uma das melhores coisas a se fazer (note que falei em engessar o processo, não o resultado final, algo que impactaria diretamente no trabalho da Criação).

Porém deve-se sempre deixar em aberto espaço para novas possibilidades; acredito que todas as decisões deste tipo devem ser tomadas em conjunto com sua equipe, nunca tomando atitude autoritária, assim todos se sentem importantes como parte não só da execução, mas na evolução do setor.

Documentação

Este é um item que pode estar junto com os Padrões, mas acredito que seja melhor analisado separadamente.

A documentação é uma etapa necessária durante todo o projeto: ao receber os layouts, o ideal é que eles sejam documentados, ou seja, sejam definidas todas as variações que o Designer definiu para que ao iniciar o Front End, já esteja tudo previsto com antecedência.

Já durante o projeto é interessante criar uma planilha (ou outra forma qualquer de controle) que mostre o andamento, mostrando o que já foi feito, o que falta e até mesmo itens que são necessários para que a atividade seja concluída. Isso vai ajudar, principalmente, a equipe de Planejamento, prevendo se tudo será entregue no prazo ou haverá atraso no cronograma.

Além disso, a boa documentação do código garante que ele será compreendido por outros membros da equipe (por exemplo, no setor de Back End), o qual precisará entender como tudo foi estruturado para integrar com o sistema desenvolvido. Isso tudo também está ligado diretamente aos Padrões adotados pela equipe!

Processos

Se você já teve aulas básicas sobre Administração, deve ter ouvido falar sobre a metodologia dos 5S, para melhor organização do ambiente de trabalho. Em qualquer área a formalização dos processos é muito importante e, é claro, que na equipe de Desenvolvimento Front End não seria diferente.

A modularização do trabalho ajuda a aumentar o rendimento, organizando as atividades em etapas, por exemplo:

1. Validação do layout;
2. Mapeamento dos elementos e planejamento do HTML;
3. Desenvolvimento HTML;
4. Corte das imagens (já utilizando padrão para nome de imagens);
5. Desenvolvimento CSS;
6. Validação das páginas nos browsers requeridos;
7. Desenvolvimento jQuery;
8. Validação dos comportamentos nos browsers novamente.

É obvio que o processo pode variar de equipe para equipe, mas este é um pequeno exemplo de como as atividades podem ser organizadas, dependendo do tipo de projeto requerido.

Além do processo interno no Desenvolvimento Front End, deve-se haver uma boa integração com as outras equipes da empresa (ex: Planejamento, User Experience, Criação, Desenvolvimento Back End, etc.), criando uma sincronização de como os conteúdos devem chegar para vocês e como seu trabalho deve ser entregue para a próxima equipe, prática que também diminui os possíveis problemas e imprevistos que podem aparecer durante o projeto!

Por fim é extremamente válido criar um processo de QA para todos os setores, garantindo que o projeto seja entregue sem bugs e diminua as possibilidades de refação.

E você tem outras formas de organização? Compartilhe através dos comentários

O problema é que devemos ter organização tanto na metodologia de trabalho, como no aproveitamento de tempo, assim não gastamos tempo desnecessário com refação e nosso orçamento acaba condizendo mais com a realidade!

Para aqueles que já estão iniciando, ou até mesmo quem já tem uma boa experiência, mas busca melhores soluções de trabalho, vou indicar algumas ferramentas que facilitam (e muito) meu trabalho no Mac:

Coda: editor de códigos

Quando mudei para a plataforma Mac passei um bom tempo procurando a solução definitiva, que ficasse no nível do que tenho com o PSPad (para Windows).

Acabei encontrando o Coda, já citado aqui anteriormente, o qual possui os pré-requisitos que julgo serem extremamente necessários para meu trabalho render o esperado:

• Envio de arquivos por FTP, permitindo atualizar arquivos remotamente de forma automática
• Snippets (ou Clips, como são chamados no aplicativo)
• Fácil administração de projetos
• Plugins
• Find / replace em múltiplos arquivos
• Find / replace de múltiplas linhas

Além de outros tantos recursos interessantes que apresentei neste vídeo.

Preço: U$99

FileZilla: cliente FTP

Já conhecido no mundo do Windows, FileZilla é um cliente FTP que cumpre bem com seu objetivo básico.

Há a possibilidade de criação de contas para cada site, facilitando sua organização.

iBiz: time tracking

Depois de alguns projetos finalizados percebi que deveria contar o tempo gasto em cada atividade, para comparar com o orçamento feito ao cliente e mensurar se estava lucrando ou perdendo dinheiro.

iBiz é a melhor solução que encontrei até o momento, já que possibilita uma ótima organização de clientes e, dentro deles, projetos distintos. Dentro de cada projeto podemos inserir atividades e listas do que fazer (to do list).

Os clientes podem ser sincronizados com contatos na Agenda do Mac, além das tarefas serem sincronizadas com o iCal, outra funcionalidade bem interessante!

Além disso, podemos aplicar um valor por hora e fazer a conta final, baseado no tempo gasto. É uma boa alternativa para quem faz manutenção, por exemplo.

Há outras diversas opções como a contagem de tempo gasto em cada aplicativo aberto, assim podemos saber se realmente estamos sendo produtivos ou não!

Preço: U$39,99

Automator: tarefas automáticas

Automator foi uma grata surpresa encontrada no Mac. Aplicativo que já faz parte do sistema, possibilita uma gama enorme de fluxos de trabalho que otimizam seu tempo.

Por exemplo, com o auxílio do Automator criei um aplicativo que executo sempre no início de um novo projeto. Defino um nome para este novo site e, automaticamente, são criadas pastas para o html, layouts, conteúdo, scripts, etc., apenas com um clique!

Esse é só um exemplo, mas você pode automatizar envio de e-mails, tratamento de imagens, entre tantas outras tarefas… Há uma página específica com download de ações no site da Apple.

Para quem ainda não entendeu muito bem, o Automator executa “macros” no sistema operacional, assim como fazemos em editores de texto. Além disso podemos mesclar com AppleScript, assim desenvolvemos um aplicativo realmente completo!

Adobe Kuler: paleta de cores

Dificuldades para a definição da paleta de cores do seu site? Adobe Kuler é um serviço muito conhecido, o qual funciona como uma rede social para compartilhar paleta de cores, servindo como inspiração.

Para automatizar o processo de criação, a Adobe disponibilizou o Kuler em Adobe Air, assim você pode instalá-lo e rodá-lo diretamente no Mac (ou PC). Conectando-se ao serviço podemos fazer pesquisas nas paletas e importá-las diretamente para o Photoshop!

É uma verdadeira mão na roda para os Web Designers!

VMWare Fusion: rodando Windows no Mac

Infelizmente nós, Web Developers no mundo Mac, ainda não podemos deixar de usar o Windows, já que devemos testar nossos sites no Internet Explorer e Firefox. Também cito o Firefox, pois há diferenças de renderização, mesmo que pequenas, entre a versão para Mac e Windows.

VMWare Fusion se mostrou uma ferramenta extremamente confiável para essa tarefa, além de sua praticidade, não sendo necessário reiniciar a máquina para entrar no Bootcamp.

Falando em Bootcamp, o VMWare Fusion permite que os dois utilizem a mesma instalação do Windows, poupando espaço no hd!

Também há opções para otimizar seu desempenho como a quantidade de memória utilizada, processamento, drives, etc. Enfim, é a solução definitiva para quem quer testar seus sites no Internet Explorer, mesmo desenvolvendo em um Mac.

Preço: U$79,99

Outros programas que também utilizo e dispensam apresentação são: Safari (e seu Inspetor Web), Photoshop, Illustrator, suíte de aplicativos iWork e Microsoft Office.

Caso você tenha outras opções ou indicações, compartilhe conosco enviando seu comentário!

O blog não é atualizado há algum tempo, mas como acredito que este não é o tipo de site que precise ser atualizado frequentemente, estou dando prioridade a outros projetos e, claro, os freelances, sempre nos “atrapalhando” nos projetos pessoais

Como já comentei aqui, criei um blog sobre Nintendo Wii, algo que me interessa muito e vai muito bem obrigado!

Além deste site, voltei a tocar com a minha banda e aproveitamos para inaugurar nosso site, por isso também estou me dedicando no desenvolvimento deste, principalmente na otimização para os sistemas de busca.

Em breve atualizarei a seção Portfolio, com diversos trabalhos desenvolvidos ao longo de 2008 que, por falta de tempo, não pude atualizar.

Um grande abraço a todos os visitantes!

Já escrevi por aqui um artigo bem interessante sobre como melhorar seu rendimento profissional, além de outro fator que influencia diretamente no assunto deste post, a colaboração que deve ocorrer entre Web Designer e desenvolvedor CSS.

Agora falaremos de algo que envolve a organização do trabalho, seja numa equipe com várias pessoas, como um simples freelancer: a padronização.

Como foi comentado no evento da W3C, o brasileiro geralmente não gosta da palavra padrão, pois pode parecer “engessado”, algo que realmente não combina com as práticas em nosso mercado de trabalho. Mas com o tempo a gente aprende e vę que a organização do desenvolvimento e fluxo de trabalho garante um resultado mais preciso e, conseqüentemente, com nível de qualidade superior.

Digamos que chegue um grande site para desenvolvermos e, logicamente, existe um prazo a ser cumprido. No entanto, deveremos tomar algumas providęncias para que o tempo não seja excedido e, em casos extremos, não percamos o cliente.

Supondo que o layout já esteja feito, assim já pulamos a parte de briefing, Arquitetura da Informação e Criação, indo diretamente ao desenvolvimento HTML e CSS. Então, deve-se iniciar pelos códigos HTMLs, focando totalmente nesta parte, mantendo sempre os princípios do KISS (keep it simple stupid) e semântica do código pois, como sempre digo, o código HTML bom é aquele que não precisa ser ajustado de acordo com “firulas” do layout.

Padronização de HTML

Na etapa do HTML devemos adotar uma padronização no desenvolvimento, como por exemplo estabelecer um estilo de DOCTYPE dependendo do foco do site (grandes portais tendem a ser administrados por uma ferramenta, por isso o XHTML 1.0 Transitional é o mais indicado por ser mais tolerante a erros no código) e um arquivo padrão, com um header e suas meta tags pré-escritas. O modo pelo qual inserimos o CSS também deve ser padronizado: alguns preferem utilizar @import com estilo inline, enquanto a maioria (como eu) preferem utilizar o <link rel="stylesheet"... />.

Segue abaixo o exemplo de “template” HTML que utilizo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-br" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="keywords" content="" />
<meta name="description" content="" />
<meta name="author" content="Carlos Eduardo de Souza" />
<title>T&#237;tulo do site</title>
<link href="css/estilo.css" rel="stylesheet" type="text/css" media="screen" />
<!--[if IE 7]><link rel="stylesheet" type="text/css" href="css/estilo_ie7.css" media="screen" /><![endif]-->
</head>
<body>
</body>
</html>

Além do código propriamente, deve haver um consenso entre os desenvolvedores da nomenclatura dos arquivos e organização de pastas, assim com o decorrer do projeto e sua manutenção, não perde-se tempo para encontrá-los.

Fica também a sugestão do controle de versőes, ítem importante principalmente em equipes numerosas como aqui na agęncia e, para este fim, utilizamos o Eclipse.

Padronização de CSS

Já na parte do CSS a padronização é um pouco mais complicada, pois muita coisa é subjetiva, ou seja, está relacionada com as preferęncias de cada desenvolvedor. Ao começar pela escrita das regras: muita gente prefere escrever uma regra com uma propriedade por linha, enquanto outros aderem a prática de uma regra por linha, com todas as propriedades seguidas lado a lado. Particularmente prefiro esta última opção, pois o documento fica muito menor e para encontrar as regras fica muito mais fácil.

Também temos que nos ater aos comentários, também estabelecendo um padrão para que o documento fique mais legível:

/*
Cliente: Nome do Cliente
Projeto: Nome do Projeto
*/

/*
--------------
ELEMENTOS e CLASSES
--------------
*/

/* ------- GERAL ------- */

Este é um exemplo do início de código CSS que adotei em meus projetos pessoais e na agęncia. Pode-se observar que o código começa com o nome do cliente e projeto, seguido de um “comentário principal”, para os elemtentos e classes aplicados a todo o site. Já o comentário “geral” é um exemplo de código utilizado para separar as seçőes, algo como um “comentário secundário”.

Além da escrita dos comentários e regras, também temos que mentalizar a forma que iremos exibir as propriedades. Muitos desenvolvedores optam por escrever as propriedades em ordem alfabética, mas eu prefiro escrever em ordem de relevância, por exemplo, colocando as propriedades de posicionamento, float, display, width, height, margin, padding, etc., na frente, enquanto as outras relativas a fontes, alinhamentos de texto, etc., ao final de cada linha. Assim todos os desenvolvedores da equipe encontrarão as informaçőes principais em primeiro lugar.

Também temos que nos ater aos hacks pois há diversas soluçőes, principalmente no que se diz a respeito de Internet Explorer. Há a possibilidade de usarmos conditional comments ou os famigerados hacks dentro do CSS. O importante é que haja uma padronização e a equipe siga o mesmo caminho para solucionar tais problemas.

Padronização é a chave para o sucesso

Sei que este artigo não é direcionado aos novatos da área, até porque envolve aspectos mais administrativos de nossa profissão, mas nada impede que estas dicas sejam seguidas desde seu começo na área.

O importante é que saibamos a relevância de seguirmos certas regras e que, com elas, nosso rendimento aumentará, além de termos uma base para que não aconteçam ou, pelo menos, diminuam as chances de erros durante o processo do projeto.

Em uma iniciativa pioneira, pelo menos em termos de Brasil, o setor de otimização para sistemas de busca aqui da agęncia realizou um campeonato interno para [tag]SEO[/tag], iniciado em Março e finalizado no final de Julho.

A proposta era fazermos, em duplas, blogs sobre esportes diferentes, e conseguirmos colocar determinados termos na primeira página do Google. Obviamente, quanto melhor a posição, mais pontos eram somados.

Cada dupla contava com a ajuda de um “técnico” e com certeza, boa parte do nosso mérito, foi por conta da competęncia do Marcelo Ribeiro (blog sobre perfis de aviőes), sempre disposto a nos ajudar e deixando a gente tranquilo quando, do nada, nosso blog despencou da primeira página em todos os termos

Para competir, eu e o Lincoln criamos o Jogue Diferente, blog voltado a estes esportes exóticos, mas sempre deixamos a porta aberta a sugestőes de jogos inventados por nossos leitores.

Com uma boa regularidade de visitantes e postando constantemente, inclusive produzindo vídeos da prática destes esportes, conseguimos fechar o campeonato com uma ótima vantagem sob o segundo colocado.

Como pręmio, ganhamos um iPod Shuffle 1gb mas, o que interessou mais, foi fato de não terem divulgado o pręmio anteriormente. Assim, quem participou do campeonato foram aqueles que justamente estavam interessados em aprender.

E como nós pudemos aprender! Muito obrigado pelos responsáveis do evento, por nos ajudar a compreender e até mesmo, poder oferecer serviços da área.

E esse assunto sobre a freqüęncia de posts não poderia ter um momento melhor para ser utilizado, já que neste ano não tenho conseguido postar tantas vezes como antes.

Os motivos são vários, desde dedicação a outros blogs, experimentando os conhecimentos adquiridos no Campeonato de SEO aqui da Mídia Digital, até um número expressivo de freelances nos últimos meses, diminuindo (e muito) meu tempo hábil para escrever por aqui.

Creio que isso acontece com qualquer blogueiro que mantenha seu blog por mais de um ano no ar mas, como sempre, há aquela preocupação acerca da atualização constante do site, etc.

Mas será que a freqüęncia dos posts é tão relevante assim? Vamos discutir sobre o assunto.

Em blogs como este, que abordam muitos temas que envolvem conhecimento, a qualidade dos posts sobrepőe a freqüęncia na qual são escritos, principalmente neste caso, que há centenas de textos que podem ser encontrados através dos sistemas de busca, sem dificuldade. Ou vocę acha que um texto bem elaborado, rico em conteúdo, escrito uma vez por męs, não vale mais do que 10 posts sem algo que lhe acrescente?

Concordo que há blogs e blogs, assuntos diversos que são tratados, mas no caso daqueles que abordam temas mais informativos, a freqüęncia da postagem não é tão relevante.

É só imaginar um programador que quer aprender mais sobre Microformats e, ao procurar no Google, acaba encontrando um post de 2006 sobre o assunto. Esta data da sua postagem tira sua credibilidade? Claro que não.

Desta forma, aproveito a oportunidade para aconselhar os novos blogueiros, principalmente desta área de Desenvolvimento Web, que não fiquem tão preocupados com a freqüęncia de suas postagens, pois os textos, mesmo que não estejam na página inicial de seus blogs, ainda podem ser encontrados!

Para marcar a nova versão do navegador, foi inaugurada a campanha Download Day 2008 visando bater o recorde no número de downloads em um único dia.

Este movimento, acima de tudo, ajudará a divulgar ainda mais este nome que, ao lado de Opera e Safari, são os melhores browsers do mercado, sem dúvida.

Por isso, não se esqueça que amanhã é dia de baixar a nova versão do Firefox e batermos este recorde!

A entrada é gratuita e aberta a todos mas, para poder comparecer, basta fazer o credenciamento pela Internet. Caso queira mais detalhes, visite a página oficial do anúncio.