Perguntas assim são normais mas é muito difícil saber exatamente a melhor resposta. Por isso, resolvi botar em prática uma iniciativa que estou planejando faz bastante tempo: A minha ideia é fazer uma pesquisa nacional. Como se fosse um censo, onde poderemos buscar de forma mais correta essas respostas e assim ajudar o mercado e principalmente os profissionais, auxiliando-os a tomarem melhores decisões para sua carreira.

Essa pesquisa é para qualquer profissional que trabalhe com web. Não queremos que fique restrito a apenas front-ends. Queremos que designers, programadores, profissionais de acessibilidade ou qualquer um que trabalhe com web participem também.

Por favor, divulgue para quem você puder. Quanto mais respostas tivermos, melhor a qualidade do resultado. Vamos fazer essa pesquisa todos os anos. Espero que ajude a comunidade. Não sei quando irei liberar os resultados, mas acho que daqui um ou dois meses é um bom tempo.

Chega de blá blá blá e vá responder a pesquisa:
http://tableless.com.br/survey/2013/

O post Survey do mercado web nacional foi originalmente publicado em Tableless.

Neste artigo vamos falar sobre complexidade ciclomática e mostrar uma ferramenta para análise de códigos JavaScript, a biblioteca Plato.

Complexidade Ciclomática

A primeira regra de funções é que elas devem ser pequenas. A segunda regra de funções é que elas devem ser ainda menores.
— Uncle Bob

Funções devem fazer uma coisa apenas. Fazê-la bem. Fazer somente ela.
— Uncle Bob

Explicando de forma bem direta, complexidade ciclomática é uma métrica do número de caminhos possíveis no seu código. Por exemplo, vejamos o código abaixo:

function authenticate() {
  if (user.isValid() === true) { 
    user.login(); 
  } else { 
    showMessage('Invalid credentials', 'error'); 
  } 
}

A função authenticate possui valor 2 de complexidade ciclomática. Na prática, isso quer dizer que precisaríamos escrever dois testes unitários para cobrir todos os possíveis caminhos. Ou seja, quanto mais caminhos, maior a complexidade ciclomática e, quanto maior a complexidade ciclomática, mais difícil será de manter/testar seu código.

Estudos recomendam 10 como o valor máximo que você deve permitir de complexidade ciclomática no seu método ou sua função. Este é um bom valor, mas tenha em mente que 10 já é uma complexidade alta e não deve, de forma alguma, ser a média de complexidade do seu projeto.

Bad Fix

Outra métrica tirada a partir da complexidade ciclomática é a probabilidade de uma correção injetar novos bugs no seu código. O pessoal da Aivosto, uma empresa especializada em ferramentas para desenvolvedores, chegou a seguinte tabela:

Segundo a pesquisa da Aivosto, uma correção aplicada em um método com complexidade ciclomática 25 tem 20% de chances de introduzir um novo bug na sua aplicação. Tente lembrar quantas vezes isso já aconteceu com você? E tente lembrar também do tamanho do método ou função que você estava “corrigindo”. Por isso é muito importante tentar medir tudo a respeito do seu código.

Plato

Desenvolvida por Jarrod Overson, a ferramenta Plato aplica na prática todas as teorias de medição de complexidade ciclomática, exibindo na forma de gráficos dados como taxa de mantenabilidade, bugs estimados e erros de lint.

A instalação é feita através do npm, gerenciador de pacotes do nodejs:

npm install -g plato

A forma mais básica de uso é a seguinte:

plato -d report src

Onde -d report é a flag para indicar o diretório report como saída do seu relatório e src é o diretório dos arquivos JavaScript a serem analisados.

Outras opções importantes são as flag -r para ler o diretório recursivamente e -x <regex> para excluir arquivos baseados em uma regex.

Os relatórios do Plato armazenam históricos e é bem interessante ver os números subindo e descendo durante o desenvolvimento do seu projeto. Uma prática legal é guardar e exibir o relatório em algum lugar disponível para todo o seu time.

Exemplos de relatórios

Abaixo temos alguns exemplos de relatórios disponibilizados no repositório do projeto, gerados a partir de bibliotecas e utilitários populares:

• jquery
• grunt
• marionettejs

Bugs estimados

Um gráfico que chama a atenção nos relatórios do Plato é o de bugs estimados. Afinal de contas, entregar um produto sem bugs é (ou deveria ser) o objetivo final de qualquer desenvolvedor.

Maurice Howard Halstead criou um conjunto de fórmulas para medir coisas como volume, esforço, dificuldade e bugs estimados em um código. As fórmulas são baseadas nos números únicos e totais de operadores e operandos.

Não vou entrar muito em detalhes sobre os valores e as fórmulas, mas é bem interessante ler sobre esse assunto (não precisa ser o livro, a Wikipedia mesmo fornece uma página bem completa sobre as fórmulas).

Integração com Grunt

Overson também desenvolveu um módulo que disponibiliza uma task Grunt para relatórios Plato.

A instalação segue o padrão de pacotes Grunt:

npm install grunt-plato --save-dev

Uma vez instalado o pacote, basta carregar a task no seu Gruntfile.js e rodar a task com o comando grunt plato:

grunt.initConfig({
  plato: {
    your_task: {
      files: {
        'report/output/directory': ['src/**/*.js', 'test/**/*.js'],
      }
    },
  },
});
grunt.loadNpmTasks('grunt-plato');

Métricas, métricas e mais métricas

Medir o código do seu projeto ajuda você e seu time a entender e prevenir problemas. Com a ajuda de métricas você vai conseguir manter um código fácil de ler e entender. Além de métricas dos níveis de complexidade também é importante possuir um relatório visível de cobertura de testes e uma documentação simples e direta do seu projeto.

Apesar do nome pomposo e de muita teoria, não é pra ninguém ficar assustado. Pode parecer um conceito avançado, mas na verdade é uma coisa muito básica: o que você estará fazendo é medir se é fácil (ou difícil) manter o seu código.

E lembrem-se: nunca refatore um código sem que ele possua uma cobertura de testes satisfatória!

O post Medindo a complexidade do seu código JavaScript foi originalmente publicado em Tableless.

A importância das histórias

Pense em colocar um pedaço de limão bem azedo na boca. Algumas pessoas conseguem praticamente sentir o gosto apenas ao imaginar. Estudos recentes de neurociência apontam que a mente humana ativa as mesmas áreas ao viver uma situação ou acessar uma memória. Ou seja, não existe uma distinção entre a maneira que processamos fatos reais e situações imaginárias. Ao visualizarmos mentalmente algo que remeta a uma informação arquivada na memória – como o limão do inicio do paragrafo – criamos uma associação sensorial e emocional maior do que com um dado científico isolado. E este é um recurso muito utilizado na aprendizagem. É muito mais fácil decorar uma fórmula de física da escola através de uma musiquinha ou situação engraçada do que tentando memorizar apenas o código numérico. Isto acontece por que narrativas ricas em linguagem figurada acessam sentidos que informações lógicas sem contexto emocional não alcançam. É por isto que histórias são poderosas. Histórias conseguem estimular áreas responsáveis pelos sentidos e criar relações – e portanto memórias – mais duradouras.

E isto ocorria muito antes da era da informação ou até mesmo do advento da escrita. Nossos ancestrais eram contadores de história e passavam assim o conhecimento de geração em geração. Os homens das cavernas faziam desenhos nas paredes e assim relatavam os acontecimentos de seu dia-a-dia. É através de histórias, arquétipos, mitos, lendas e símbolos que o ser humano atribui significado ao mundo.

Storytelling e Design

Que “storytelling” é a expressão em inglês para “contar histórias” você provavelmente já sabe. Mas este conceito, transportado para o universo do design, não precisa ser necessariamente algo literal. Não estamos falando aqui de abrir um layout com “Era uma vez” (embora isto possa até funcionar em alguns contextos). Na realidade o storytelling acaba sendo uma camada invisível do design. Algo planejado intencionalmente para ser o tom ou a voz da sua marca, mas que não é tão óbvio para seu usuário. O storytelling pode estar na personalidade do seu discurso, no uso inteligente de imagens e ilustrações, na sequência de elementos da interface que vai guiar o visitante e convida-lo a explorar o conteúdo, etc.

Parte do trabalho de um webdesigner é pegar uma informação “crua” e transforma-la em uma mensagem interessante. Ao adicionar o elemento emoção o valor desta mensagem aumenta. As vantagens disto são inúmeras. Podemos criar um maior senso de ordenação de conteúdo, conforto cognitivo, aumento de empatia e maior absorção de informação. A web não é feita de pixels nem de fatos isolados. A web é feita de histórias.

OK. Tudo isto é muito bonito e legal, mas como utilizar estes conceitos na prática?

A boa notícia!

Você provavelmente já utiliza alguns elementos de storytelling em seus trabalhos de design sem saber. Dicas visuais e calls to action são uma maneira de conduzir o fluxo da informação e instigar a curiosidade do usuário como os clifhangers de livros, filmes e seriados. Uma boa formatação de títulos, resumos e parágrafos também é uma dica visual da estrutura narrativa. Coerência entre a navegação, instruções claras em campos de formulário e links bem identificados garantem que o leitor não se perca.

A história de um produto

Pessoas acreditam que produtos esteticamente bonitos são mais úteis e efetivos porque elas se tornam emocionalmente atraídas por eles. E tomamos decisões com base em nossos sentimentos, utilizando a razão apenas para justificar o por que estas decisões foram tomadas.

Para contar uma história que crie uma ligação emocional podemos explorar três esferas:
Aspiração: Como esperamos que aquele objeto funcione.
Função: Como aquele objeto pode ajudar a resolver um problema.
Memória: Lembranças positivas de uso.

Um exemplo disto é o design da Apple. O trecho abaixo é da página sobre o iPhone.

Aspiração: Amar o produto.
Função: Tecnologia, câmera, bateria de longa duração, facilidade de uso.
Memória: As imagens grandes do produto em sequência, sempre inseridas em contextos de momentos felizes como viagens, família, amigos e momentos de lazer despertam a memória de felicidade e coisas que pessoas amam fazer, associando estas lembranças ao produto.

Outros elementos gráficos como vídeos e ícones complementam a história do produto. Em cada bloco de informação sobre o iPhone existe um link para continuar a navegação e ler os próximos capítulos da narrativa.

Imagens Sequenciais

Este é provavelmente um dos recursos mais comuns de storytelling, presente em diversos meios como storyboards, histórias em quadrinhos e livros ilustrados. A página Ben the Bodyguard é um exemplo clássico de narrativa utilizando imagens sequenciais. O produto em questão é um aplicativo de segurança, apresentado pelo mascote da empresa – Ben, o guarda costas. A ambientação de cenários e os diálogos do personagem reforçam o clima de mistério e perigo. A navegação vertical ativada pela rolagem de mouse é o que dá movimento ao personagem e determina o ritmo e o tempo da história, transmitindo ao usuário um maior controle de interação.

Narrativas Lineares

Um modelo tradicional de histórias compreende a apresentação de personagens em uma aparente normalidade, o surgimento de um conflito, o clímax e uma conclusão que resolve os conflitos apresentados.

Um exemplo bacana de uso desta estrutura tradicional de narrativa é The Story of Jess and Druss. O site conta através de textos, ilustrações e uma linha de tempo a história de como o casal – Jess and Druss – se conheceu, apresentando as dificuldades de viver sozinho e como o amor aconteceu. As ilustrações, a tipografia, as cores e todos os outros elementos de design servem de suporte para contar a história do casal.

A lineriadade da história é reforçada novamente pelo uso de uma navegação vertical e outro recurso interessante: a linha do tempo. O efeito de navegação parallax ajuda a transmitir um senso de continuidade para a história que possuí um clímax – o momento do pedido de casamento – e uma resolução em forma de um convite para os amigos do casal comparecerem ao evento. Final feliz para nossos personagens!

Narrativas não-lineares

Se você viveu sua infância nos anos 90 provavelmente se lembra de livros-jogo do tipo “Escolha sua própria Aventura”. Para quem não conhece eram livros que ao final de cada capítulo ofereciam múltiplas escolhas de desfechos possíveis. O leitor podia então tomar suas próprias decisões e ir para a página X para continuar a história de uma maneira ou ir para a página Y para revelar outra trama. Os finais variavam de acordo com as escolhas e, se tudo desse errado, bastava começar a ler de novo e tomar decisões diferentes. A internet é como um grande livro-jogo! Todos os elementos estão aí. Múltiplos pontos de entrada para uma página (links), narrativa truncada não-linear (textos espalhados em diferentes sessões) que deve trabalhar em conjunto para transmitir uma mensagem (objetivo do site). A cada escolha de navegação de um site o leitor abre um capítulo diferente e assim vai construindo sua própria história.

Um exemplo concreto de site que faz uso deste tipo de recurso é o Cadillac ATS vs The World. Logo na página inicial é possível escolher entre os destinos possíveis (Patagonia, Marrocos, Monaco ou China) e embarcar em uma viagem virtual para cada local. Fotos panorâmicas servem como cenário, mas os depoimentos da equipe e dos moradores locais são o verdadeiro coração da história. As demais imagens, vídeos e informações em uma linguagem turística ajudam a complementar o tema viagem.

Seja o herói!

Toda história tem um protagonista. E protagonistas precisam de antagonistas, conflitos, dificuldades, problemas… Exponha claramente quem é do time do bem (você) e como solucionar um problema do usuário. Faça o público torcer para o sucesso da sua empresa, produto, serviço. Crie ações, metas e objetivos claros para ter um final feliz. Você não precisa ter um mascote para fazer isso. O seu serviço pode ser o herói.

Um case bacana de storytelling é o site da Dropbox. A metáfora de história permeia todo o design da página Tour.

Eles exploram claramente o que é o serviço (“Um lugar para todos os seus arquivos, onde quer que você esteja”), quem são os possíveis personagens (“não importa se você é estudante ou profissional, um pai ou um avô.”), existe um vilão concreto (o medo de “derramar café sem querer no laptop”), um herói (a própria Dropbox) e um final feliz (“Relaxe com a certeza de que todos os seus arquivos estão seguros no Dropbox e nunca se perderão”). Para reforçar o conceito de história temos elementos esqueumórficos como metáforas (o livro, navegação por páginas, o próprio ícone da dropbox como uma caixa de arquivos) e ilustrações lúdicas para reforçar o ideal de segurança do final feliz.

Cada página do livro é em si uma história completa. Seguindo as páginas temos mais alguns elementos interessantes de storytelling como recursos de balõezinhos que remetem diretamente a história em quadrinho, elementos de humor, atribuição de super poder ao herói (máquina do tempo) e novamente vilões concretos (computador pegando fogo).

O usuário também é um personagem

Se você for contar uma mesma história para seus pais em uma reunião de família, para um possível empregador em uma entrevista de emprego ou para um grupo de amigos em um bar provavelmente vai escolher diferentes abordagens. Em essência a história permanece igual mas decisões como o uso de palavrões, gírias, jargões técnicos, humor, etc vão determinar o tom da linguagem de acordo com a situação social. O truque para saber qual variação linguística utilizar é conhecer o seu público-alvo.

Você que está lendo este texto tem 80% de chance de ser homem e 77% de chance de ter entre 16 e 34 anos. Não, não tenho uma bola de cristal. Eu li o Media Kit do Tableless antes de começar a escrever estes artigos. Mas muitas vezes, ao lançar um serviço novo, estas informações não estão disponíveis. E para estas horas o que ajuda é imaginar o seu usuário também como um personagem. Dar uma cara para a figura misteriosa por trás do monitor vai te ajudar a escolher o tom da sua história.

Um recurso muito utilizado é a criação de personas. Essencialmente você deve pensar em quem, quando, onde e por que alguém vai querer utilizar o seu serviço. Mas o grau de complexidade das suas respostas pode variar muito. Você pode simplesmente elencar alguns dados demográficos ou ir mais longe e criar um nome, imagem e biografia para este usuário hipotético. Conhecendo quem é o seu público alvo fica muito mais fácil descobrir o que ele busca e desta forma entregar um conteúdo mais relevante. Não esqueça de elencar também os possíveis cenários e situações que este personagem irá interagir com a interface.

Quer saber como construir suas próprias personas? Aqui no Tableless temos um artigo muito interessante justamente sobre Personalidade no Design.

Saber disto pode te ajudar a projetar a navegação de maneira mais inteligente. Você não pode controlar as escolhas do usuário, mas pode fornecer uma estrutura lógica coesa para que ele construa seu próprio caminho. Uma história nunca é percebida exatamente como foi imaginada. Cada pessoa entende histórias de maneiras diferentes, adicionando seus próprios pensamentos, sentimentos, percepções e experiências. Interfaces como a do Windows 8 e do Google Now estão em alta hoje não apenas por que o design minimalista é uma tendência visual da moda, mas por abrirem espaço para que narrativas pessoais possam existir. Ações como criar, escolher, modificar e ordenar blocos de conteúdo permitem um nível de personalização muito maior e assim criam o cenário perfeito para estas narrativas.

O Google Now oferece uma variedade de informações em cartões de conteúdo que variam de acordo com a localização geográfica da pessoa e seu histórico de pesquisas no Google. Assim é possível exibir informações sobre o clima, trânsito, mapas, fotos, etc de acordo com o uso. Este é um exemplo de estudo de persona levado a sério! O sistema a partir de inputs automáticos traça um perfil de maneira inteligente e como consequência fornece um conteúdo mais relevante.

Mostre o que é único sobre você

Uma imagem vale mais do que mil palavras. Mas uma imagem genérica e sem personalidade equivale a um discurso sobre o nada. Bancos de imagens são um recurso valido, mas muito cuidado ao utilizar indiscriminadamente este tipo de imagens (principalmente os gratuitos). Isto pode passar ao seu usuário a impressão de frieza e falta de personalidade. Todo mundo sabe que aquela moça de headphones gigantesco não trabalha de verdade no callcenter da sua empresa… a não ser que ela trabalhe em todos os callcenters do mundo ao mesmo tempo. Pense em qual é o seu público e tente se relacionar com ele. Por que não mostrar a cara da sua equipe de verdade? E do seu escritório? Desta maneira o público consegue conhecer (e sentir empatia) por você de verdade.

Se não possuir recursos para ter imagens próprias tente procurar por registros marcados como Creative Commons (com licença de uso comercial) em sites como o Flickr. Este tipo de imagem transmite mais autenticidade do que aquela tipica família americana em um estúdio branco (que não lembra em nada as famílias brasileiras).

Você pode ainda utilizar outros recursos visuais como ilustrações ou até mesmo uma tipografia diferente. Além das imagens, elementos do layout como formas, linhas, cores, texturas, padrões, peso, movimento, espaço e proporção são as principais ferramentas para compor o tom. Dependendo do seu contexto letterings expressivos e caligrafia são boas opções e transmitem o sentimento de algo feito a mão com carinho e cuidado. O site Forefathers Group é um exemplo disto. O uso de lettering, o ar de mistério dos textos, a paleta de cores e ilustrações remete ao tema principal de grupos itinerantes e companhia de circo.

Storytelling transmídia

É importante lembrar que a história de uma marca transcende os limites de uma página na internet. Toda a identidade visual e linguagem verbal empregada deve ser consistente e partir de um mesmo contexto lógico. De nada adianta uma empresa se esforçar para parecer simpática e amigável em seu site e depois tratar mal os clientes nas redes sociais, por exemplo. Se você é um freelancer a responsabilidade é ainda maior já que a sua marca é você mesmo! Muito cuidado com a imagem que você está transmitindo. Parece senso comum, mas muita gente acaba perdendo ótimas oportunidades profissionais ao reclamar do trabalho no Facebook ou Twitter.

Um exemplo de storytelling transmídia é a campanha de e-mails marketing da empresa Meu Móvel de Madeira. Cada e-mail foca em uma persona de usuário em uma situação específica. No exemplo a seguir o personagem hipotético acabou de comprar uma casa e deseja mobiliar a sala:

Além de um website, redes sociais e e-mails existem muitos outros recursos de mídia para continuar sua história dentro e fora da internet. Aplicativos, blogs,livros, cartões de visita, posters, adesivos, videos… Todos estes recursos são formas validas de comunicar sua mensagem e dar ao seu interlocutor a chance de participar de uma experiência completa. Cabe a você torna-la incrível! Boa sorte na sua jornada.

Saiba mais:

The Missing Element of Redesign: Story – Smashing Book #3⅓ — The Extension
Better User Experience With Storytelling
10 Ways To Incorporate Storytelling In Web Design

O post Storytelling foi originalmente publicado em Tableless.

Quantas vezes você se pegou copiando e colando aquele monte de classes identadas com mais de 15 linhas repetidamente e pensou: podia existir uma maneira mais rápida de fazer isso.

Agora eu te digo: tem!

Eu conversei com alguns amigos desenvolvedores e fui saber quais dos frameworks tem sido mais usados, e a disputa ficou bastante acirrada entre o LESS e o Foundation. Ainda assim, na mesma semana acabei lendo um artigo técnico sobre o uso do Sass e por isso resolvi também testá-lo para entender como ele funciona.

Basicamente você começa “instalando” ele em sua máquina. Para os usuários de MAC é bem mais tranquilo que para os usuários de PC, porque para o Sass “rodar“ precisamos que o  Ruby também esteja instalado e isso já é nativo no MAC. De qualquer forma, não é nenhuma experiência traumática. No próprio site do Sass você encontra os dois métodos de instalação.

Eu uso MAC e escolhi instalar o Sass através do Git.

Após clonar o repositório, criei no diretório escolhido um novo arquivo com o nome de “style.scss”. Neste arquivo de folha de estilo, escrevi as seguintes linhas de código:

.content {
backgoround: #000;
font-family: Arial;
font-size: 15px;
p{ line-height: 20px;}
}

Depois abri o terminal, no diretório onde o arquivo .scss foi salvo e digitei:
sass --watch style.scss:style.css

Pronto! A mágica está feita.

Este comando cria um novo arquivo style.css no mesmo diretório traduzindo as linhas digitadas acima em:

.content {
  backgoround: #000;
  font-family: Arial;
  font-size: 15px; }
    .content p {
   line-height: 20px;
}

Neste momento você pode estar pensando: Ah, é legal, mas não vi tanta mágica assim.

Então vamos incrementar um pouco as coisas.

Digite em seu arquivo .scss:

.varios-elementos{
       background:#ccc;
       p{ color:red}
       a{ color:pink}
       input{
         -moz-border-radius: 20px;
         border-radius: 20px;
         -webkit-border-radius: 20px;
         border-left:solid 1px #eaeaeb;
         border-right:solid 1px #eaeaeb;
         border-bottom:solid 1px #eaeaeb; 
         border-top:solid 3px #ccc;
       }
    }

Salve e em seguida seu arquivo style.css estará com:

.varios-elementos {
  background: #ccc; }
  .varios-elementos p {
    color: red; }
  .varios-elementos a {
    color: pink; }
  .varios-elementos input {
    -moz-border-radius: 20px;
    border-radius: 20px;
    -webkit-border-radius: 20px;
    border-left: solid 1px #eaeaeb;
    border-right: solid 1px #eaeaeb;
    border-bottom: solid 1px #eaeaeb;
    border-top: solid 3px #ccc; }

Percebeu? “.vários-elementos“ foi a classe que criamos, em seguida começamos a escrever as características desta classe e dos elementos que nela continham, de forma bastante intuitiva e direta.

Não tem muito segredo né?

O Sass também permite o uso de variáveis. Por exemplo:

$main-color: #d5d5d5

.botao{
   background: $main-color;
}

O uso de pseudo-elementos:

a {
   color: #ce4dd6;
   &:hover { color: #ffb3ff;}
   &:visited { color: #c458cb; }
  }

O uso de Operações e Funções

#navbar {
        $navbar-width: 800px;
        $items: 5;
        width: $navbar-width;
        li {
            float: left;
            width: $navbar-width/$items - 10px;
            }
        }

E o uso de interpolação: você pode utilizar variáveis não apenas para valores, mas também propriedades ou seletores:

$vert: top;
$horz: left;
$radius: 10px;
.rounded-#{$vert}-#{$horz} {
       border-#{$vert}-#{$horz}-radius: $radius;
       -moz-border-radius-#{$vert}#{$horz}: $radius;
       -webkit-border-#{$vert}-#{$horz}-radius: $radius;
    }

Também é permitido importar outros arquivos, como já é possível nos arquivos CSS tradicionais e também o uso da diretiva “@mixin” que é umas das features mais valorizadas do Sass, onde você pode aproveitar pedaços de códigos com elementos, seletores ou propriedades, simplesmente importando através diretiva “@include“ no arquivo .scss:

@mixin rounded-top-left {
        $vert: top;
        $horz: left;
        $radius: 10px;
        border-#{$vert}-#{$horz}-radius: $radius;
        -moz-border-radius-#{$vert}#{$horz}: $radius;
        -webkit-border-#{$vert}-#{$horz}-radius: $radius;
}
#navbar li { @include rounded-top-left; }
#footer { @include rounded-top-left; }

Legal né?

Pois então, enquanto eu testava o Sass me perguntava: vale a pena aprender um novo jeito de escrever CSS? E a resposta foi: vale, dependendo do seu objetivo.

Se o tempo para o desenvolvimento for curto, o ideal é manter-se no que você já conhece e sabe fazer. Experimentar, pode dar muito certo e te fazer adquirir ainda mais conhecimento, mas também pode dar errado e você não ter tempo de arrumar, além de atrasar seu cronograma.

Pondere isso, mas não deixe de estudar. Quem sabe numa tarde sem muito job você pode usar o Sass, aprender a aplicá-lo em sua plenitude e dar tudo muito certo quando você for desenvolver projetos a valer.

Até a próxima.

OBS: Pessoal, conforme o comentário abaixo do Duke, existe uma correção a ser feita no que diz respeito à “dependência” do Ruby para a instalação do Sass:

O post Sass – Um outro método de escrever CSS foi originalmente publicado em Tableless.

Depois de muito esforço, finalmente lançamos um guia definitivo sobre o assunto chamado browserdiet.com e vim compartilhar um pouco da experiência de ter liderado esse projeto irado.

Motivação

O ano de 2012 foi um ano bem diferente pra mim, passei 1/3 dele viajando e me deparei com muita conexão ruim em hotel e aeroporto. Isso me deixava muito irritado. E é claro que eu sempre xingava o hotel/aeroporto, até perceber que a culpa na verdade é nossa.

Nós desenvolvedores somos egoístas. Passamos o dia todo no escritório com uma alta velocidade de conexão e esquecemos que existem outras pessoas no mundo enfrentando velocidades bem diferentes daquela.

O Início

Comecei a estudar mais sobre performance para escrever minha monografia e me deparei com o seguinte cenário. Em inglês, excelentes referências como os livros High Performance Websites e Even Faster Web Sites, ambos do Steve Souders. Além, é claro, dos guias da Yahoo! e Google. Já em português, uma dezena de blogposts soltos por aí.

Pensei: “E se eu fizesse um guia foda de performance voltado pra comunidade?” Mas não fazia sentido fazer aquilo sozinho, então de pouquinho em pouquinho fui conversando com uns amigos.

Concepção

Uma coisa estava muito clara pra mim, queria fazer um projeto divertido.

Convenci primeiro a designer Briza Bueno (Americanas.com) a me ajudar. Ela elaborou uma identidade muito mais divertida do que aqueles guias chatos que existem hoje. Isso tudo com base nas ilustrações do Scott Johnson, a quem eu pedi autorização para utilizar as imagens.

Depois chegou a hora de elaborar a estrutura desse site, nessa parte o Iraê Lambert (Yahoo!) me deu uma mão escrevendo um static generator em Python. Só que eu não dominava aquele código e as barreiras que eu encontrava por não saber manipular aquilo foram me afastando do projeto, ao mesmo tempo em que outras ideias iam surgindo.

Resultado: o projeto ficou parado por 1 ano até que eu decidi retomar reescrevendo todo código usando um outro static generator em Node.JS chamado DocPad. Como todo projeto open source, se você quiser fazer algo que tenha a colaboração das pessoas precisa eliminar o maior número de barreiras possíveis. Por isso, inspirado no HTML5 Please, decidi que todas as dicas seriam escritas no formato mais simples do planeta, em Markdown.

Conteúdo

Design e implementação estavam prontos, só faltava o que realmente importa, o conteúdo. Convidei então grandes amigos que enfrentam muitos desafios de performance no seu dia-a-dia, Davidson Fellipe (Globo.com), Giovanni Keppelen (Peixe Urbano) e Jaydson Gomes (Terra). As categorias iniciais divididas entre nós foram HTML, CSS, JavaScript e jQuery.

Meu eterno dilema entre português e inglês também persistia nesse projeto. Cheguei a comprar o pequenino domínio comoperderpesonobrowser.com.br, mas ele claramente não funcionaria para um conteúdo em inglês também. Por isso, optei por algo mais curto e universal.

Revisão

Depois de muito aprimoramento resolvi convidar outros caras sinistros para revisarem, como o Marcel Duran (Twitter), Mike Taylor (Opera), Renato Mangini (Google) e Sérgio Lopes (Caelum). Todos ficaram animados e contribuiram insanamente. O legal foi que a discussão não ficou apenas na parte do conteúdo, questões relativas ao código do site foram extremamente debatidas como usar CSS Sprites vs Lazy Load.

Lançamento

Eu estava planejando lançar esse projeto no mínimo em Abril. Só que quando vi que os primeiros colaboradores (Briza, Davidson, Giovanni, e Jaydson) do projeto estariam presentes no Rio.JS, mudei o tema da minha palestra e comecei a correr contra o tempo.

Felizmente deu tudo certo e lançamos o projeto!

O resultado final você pode conferir em: browserdiet.com. E o código fonte, como sempre, está aberto no Github.

PS: Os slides também estão online para quem quiser conferir.

Conclusão?

Estou bem animado para ver como a comunidade vai receber e se beneficiar desse aglomerado de dicas iradas que preparamos.

E aí, vamos fazer uma web mais rápida?

Reações

iMasters – Guia que conscientiza desenvolvedores sobre a importância da performance é lançado

love this new project: browserdiet.com

— Stoyan Stefanov (@stoyanstefanov) March 11, 2013

Stoyan Stefanov, Engineer – Facebook

How to lose weight in the browser — the definitive front-end performance guide: browserdiet.com

— Mathias Bynens (@mathias) March 11, 2013

Mathias Bynens, Web Developer – Freelance

Some of Brazil’s brightest front-end devs created and just launched browserdiet.com. Check it out!

— Mike Taylor (@miketaylr) March 11, 2013

Mike Taylor, Web Opener – Opera

O post Como perder peso (no browser) foi originalmente publicado em Tableless.

Nomeando Cores

Dar nome a cores sempre foi um problema. Linguagem é uma coisa extremamente subjetiva e arbitrária. Cada grupo cultural possui uma visão de mundo diferente e portanto dá nome ao objetos a sua própria maneira. Com as cores não podia ser diferente.

Outro grande problema é que a percepção física de cores varia de pessoa para pessoa. Cor é a maneira que o olho interpreta a luz refletida nos objetos. O ser humano possuí células chamadas cones. Estas células são responsáveis por entender os diferentes padrões de comprimento de onda e entregar esta informação ao cérebro. E esta percepção pode variar individualmente. Pesquisas mostram que existe uma diferença na maneira com a qual homens e mulheres classificam as cores, por exemplo. E até pessoas com super visão que enxergam milhões de cores a mais que alguem comum.

A Era Web Safe

Nos primórdios da web tudo era relativamente mais simples. Os chips gráficos trabalhavam com apenas 8-bits e eram capazes de reproduzir exatamente 256 cores diferentes. 216 delas ganharam um nome em inglês (o restante ficou reservado para uso interno de cada sistema) e precisávamos consultar uma tabelinha na hora de escolher a matiz mais bacana. Mesmo com a evolução das placas de video a preocupação com acessibilidade e retrocompatibilidade forçou alguns desenvolvedores a se prenderem aquele esquema inicial. Estas eram as cores “web safe”, ou seja, aquelas que supostamente seriam exibidas corretamente em todos os browsers. Posteriormente foi descoberto que apenas 22 destas cores eram realmente seguras. Mas isto é outra história… Felizmente a tecnologia evoluiu e os monitores coloridos atualmente tem 24 bits e são capazes de renderizar exatamente 16,777,216 cores. Os dias de web safe ficaram para trás. Mas catalogar milhões de cores em um computador com base em seus respectivos nomes e suas variações em cada língua através de uma tabela passou a ser impossível! É mais prático entender a mecânica por trás dos códigos para assim usarmos as cores na internet de maneira efetiva.

Mas se você ainda precisa de um nome humano para se sentir mais feliz pode utilizar alguma ferramenta como Color Name & Hue para descobrir um (em inglês) a partir de seu respectivo código. Uma opção em português é navegar em uma lista como a da Wikipedia. Não que isto tenha algum aspecto prático no dia-a-dia. Explicar para o seu cliente qual é a cor Feldspato pode ser mais complicado do que simplesmente mostrar o trabalho, mas você pode impressionar os seus amigos na próxima vez que jogar Stop.

Sistemas de Cores

RGB

O RGB (Red, Green e Blue – ou Vermelho, Verde e Azul) é um sistema de cores aditivo projetado para ser utilizado em dispositivos eletrônicos. Monitores são pretos e iluminados por pontos de luz. Portanto você parte da ausência de cor e vai “somando” pontos de luz vermelhos, verdes e azuis até chegar na cor desejada.

A estrutura é composta por 3 pares de números de 3 dígitos cada variando do 0 ao 255, quanto mais alto é o número mais clara é a cor. Através destas combinações podemos chegar a mais de 16 milhões de cores (256 x 256 x 256).

É possível utilizar cores do sistema RGB em layouts diretamente de suas folhas de estilo. Para isto basta declarar o valor dos canais vermelho, verde e azul separados por virgula.

Vamos imaginar que o seu layout possui um título azul. A sintaxe em CSS ficaria assim:

h1 {
color: rgb(0, 0, 255);
}

Com as novidades do CSS3 o RGB ganhou um upgrade e tornou-se RGBA. O canal A (alpha) é responsável por controlar a opacidade das cores dos elementos em CSS sem afetar outros itens afiliados. Para isto basta declarar um valor de 0.1 a 1 separado por ponto. Este valor corresponde ao nível de transparência sendo 1 sólido e 0 invisível.
O mesmo título do nosso exemplo com 50% de transparência ficaria assim:

h1 {
color: rgb(0, 0, 255, 0.5);
}

O sistema Hexadecimal

Se você está lendo este artigo provavelmente já está familiarizado com os tripletos hexadecimais. São sequências numéricas que representam cores formadas a partir de uma combinações de 6 caracteres precedidos de uma hashtag. Mas você sabe a lógica por trás do sistema?

Os códigos hexadecimais são compostos através de uma combinação de três conjuntos de pares formados a partir de números de 0 a 9 e letras de A a F. Quanto mais alto o número mais clara é a cor e quanto mais baixo o número – você adivinhou! – mais escura. Por isso que #000000 é preto. Se o código for composto de pares que se repetem como no caso de #444444, por exemplo, é possível utilizar a formula abreviada #444. O simbolo # serve apenas para informar que se trata de um código hexadecimal.

A sintaxe acredito ser já conhecida de todos:

h1 {
color: #0000ff;
}

Cada campo pode conter apenas um caractere. A função das letras é representar os números de dois dígitos, algo como o que acontece com o valete, dama e rei em cartas de baralhos. E é daí que vem o nome hexadecimal. São números de base 16. Ou seja, o A representa o 10, o B o 11 e assim por diante até a letra F. Por isto que a cor mais clara de todas, o branco, é representado por #FFFFFF.

Cada par é responsável por uma cor aditiva do esquema RGB. Os primeiros 2 números controlam o vermelho, os 2 seguintes o verde e os dois últimos o azul. Ou seja #ff0000 é o vermelho mais claro, #00ff00 é o verde mais claro e #0000ff é o azul mais claro.

Como saber isto pode te ajudar? Simples, através deste mecanismo você pode fazer ajustes de cores no seu design diretamente do CSS de maneira prática e lógica. Você pode deixar uma matiz mais clara ou escura apenas alterando o valor dos pares numéricos.

Para esquentar uma cor basta aumentar a quantidade de vermelhos (primeiro par) e diminuir a quantidade de azul (último par). Para esfriar basta fazer o processo inverso.

HSL

A escala das cores tanto em RGB quanto em códigos HEX varia entre o eixo claro-escuro. Estes modelos deixam de lado outras maneiras mais intuitivas de classificação de cores como matiz e saturação. O HSL surgiu para preencher este vácuo. A idéia aqui é distribuir as cores não em um eixo vertical mas sim em um modelo de cilindro. As cores não são somadas ou subtraídas, mas sim distribuídas ao longo de um circulo cromático. Cada matiz representa um grau do cilindro entre 0 e 360.

A sintaxe dele é da seguinte maneira:
hsl (hue, saturation%, lightness%);

Sendo o primeiro valor a matiz, o segundo a saturação e o terceiro a quantidade de iluminação. O nosso título azul ficaria assim:

h1 {
color: hsl(240, 100%, 50%);
}

Da mesma forma que o RGB o HSL também pode ser utilizado em CSS e possui um canal alpha (HSLA). O mesmo título com 50% de opacidade:

h1 {
color: hsl(240, 100%, 50%, 0.5);
}

Embora possua suas vantagens, principalmente para quem esta acostumado com divisões mais artísticas de cores, o HSL ainda não se popularizou… Suponho que a razão é por que alguns softwares gráficos utilizados por designers, como o Photoshop, simplesmente não possuem um misturador de cores compatível com o formato. Todas as cores utilizadas no layout teriam que ser convertidas manualmente para HSL, o que poderia significar um gasto a mais em tempo. Existem alguns plugins que prometem facilitar o processo, mas as outras alternativas (RGBA e HEX) já funcionam muito bem. Até que os programas gráficos mais populares sejam compatíveis, o HSL não deve ganhar muito espaço.

CMYK

Já aconteceu de você abrir uma foto no computador e reparar que as cores estão bem estranhas? Pois é, o estagiário provavelmente fechou o arquivo em CMYK. Este formato foi pensado exclusivamente para pigmentos de impressão.

CMYK é uma sigla para Cyan, Magenta, Yellow e Black (Ciano, Magenta, Amarelo e Preto). Se você está se perguntando por que a sigla para preto é K existem duas explicações provavéis. A primeira é que o K representa Key já que o preto é uma cor-chave. A outrea é simplesmente para não confundirem com o B de Blue no RGB.

O CMYK é um sistema de cores subtrativo já que você parte do branco e vai retirando luminosidade até chegar na cor desejada. A impressão em CMYK é a partir de pontos coloridos chamados retículas. Como nosso foco aqui é a internet não vou entrar em muitos detalhes sobre este sistema. Mas vale a pena conhecer para saber como não salvar arquivos para a web.

Qual sistema utilizar?

Tudo depende das características do seu layout. Considerando esquemas de cores flat o hexadecimal serve muito bem. Alias, inspirada pelo visual minimalista do Windows 8 as cores vivas e sólidas são uma grande tendência em 2013. Mas se o seu layout faz uso de transparências, gradientes e sombras o RGBA vale bastante a pena.

Mas você não precisa prender-se a apenas uma opção. Você pode combinar, em um mesmo CSS, sistemas diferentes. Uma prática comum é utilizar HEX para cores sólidas e RGBA apenas para situações onde o canal alpha é importante. De qualquer maneira ter a mão uma tabela de equivalência pode ser útil. Sorte que existem conversores automáticos como o ColorHexa para ajudar nesta tarefa. Basta digitar um código de cor (de qualquer tipo) ou um nome em inglês para descobrir os valores equivalentes em HEX, Binário, RGB, CMYK, HSL, HSV, CIE-Lab, Hunter-Lab, CIE-Luv, CIE-LCH, XYZ e xyY. Só isto já seria ótimo, mas a ferramenta ainda tem outras informações interessantes como sugestões de esquemas de cores e alguns snippets de CSS para você visualizar aquela cor aplicada a um texto, borda e background de uma div. Outra função bacana é a possibilidade de visualizar como uma pessoa com daltonismo enxergaria aquela cor.

Acessibilidade

Estima-se que 8% dos homens do mundo e 0.5% das mulheres sofre de algum tipo de dificuldade de percepção de cores como o daltonismo. Para garantir que estas pessoas poderão acessar o conteúdo da sua página é importante não depender da cor para indicar elementos importantes. Por exemplo, indicar campos de formulário com erros apenas com a cor vermelha não é distinção suficiente. Seria interessante, neste caso, complementar a informação com algum outro recurso gráfico como um ícone. Se você tem um amigo com daltonismo é interessante pedir para ele navegar no site e dizer se encontra algum problema. Como nem sempre temos a oportunidade de realizarmos este tipo de teste uma experiência que pode ajudar é retirar a saturação de todas as cores do layout em um programa gráfico. Se as informações importantes ainda estão claras e com bom contraste apenas em tons de cinza o seu layout é acessível. Você pode ainda utilizar alguma ferramenta online como o Color Filter para checar como pessoas com os tipos mais comuns de daltonismo enxergam sua página.

Inspiração

Cores de Marcas

Na hora de criar um layout um designer sempre tem a mão sua própria paleta de cores. Mas quando é preciso utilizar as cores de outras empresas a coisa complica! Qual é exatamente o tom de azul do Facebook? E do Twitter? E o código hexadecimal do verde Android? A missão do Brand Colors é justamente servir como um catálogo de cores dos gigantes da internet. Além de ser útil para descobrir rapidamente as cores de marcas famosas, a ferramenta é um bom panorama de quais são os tons mais utilizados na rede.

Cores da Web

Que tal ir um passo além da cor predominante e descobrir a paleta de cores completa de uma marca? Através do Webcolour Data você pode explorar as cores de qualquer site na internet. Basta inserir a URL e se inspirar no esquema de cores do seu site favorito. A ferramenta exibe resultados (e seus respectivos códigos HEX) em gráficos interessantes com base em porcentagem de uso, distribuição de tons, roda de cores e sites com paletas de cor semelhantes. O Webcolour Data também pode ser útil para realizar uma análise de design e verificar se as cores de um site estão consistentes com aquelas propostas na identidade visual.

Cores de Fotos

O Color Thief tem uma proposta semelhante. Mas a idéia aqui é explorar paletas baseadas em fotos. Basta realizar um upload de imagens que a ferramenta captura o esquema de cores predominante.

Cores de Filmes

O Tumblr Movies In Color pode ser uma grande fonte de inspiração para quem curte cinema. A idéia aqui é conhecer a paleta de cores utilizada na cinematografia de filmes como 2001 – Uma Odisséia no Espaço, O Fabuloso Destino de Amélie Poulain, Clube da Luta e Inception. Você pode navegar por imagens, títulos dos filmes ou nome do diretor de fotografia. Vale o clique!

Criando suas próprias paletas

Criar esquemas de cores pode ser uma tarefa mais prática utilizando algum gerador como o Kuler da Adobe ou o Color Scheme Designer. Através destas ferramentas você pode criar esquemas monocromáticos, complementares, análogos, etc. Se você criou algo realmente legal e deseja compartilhar com o mundo ou simplesmente quer navegar por diversas paletas e se inspirar a rede social Colour Lovers pode ser um lugar interessante.

Games

Quem disse que você não pode aprender se divertindo? Alguns webgames como o Color Method testam o seu conhecimento e percepção de cores com base em tom, saturação, cores complementares, análogas… Cuidado, pode ser viciante!

Saiba mais:

CSS3 Breve Introdução a RGBA
RGB e HSL
The Code Side of the Color

O post Sobre Cor e Webdesign foi originalmente publicado em Tableless.

O que significa desenvolvimento ágil?

Desenvolvimento ágil é um conjunto de estratégias para gerenciamento de projetos incremental e com ciclos de desenvolvimentos rápido. As vantagens disto são: melhoria continua de um projeto, frequente resolução de problemas e aumento da produtividade. O conceito surgiu em em oposição ao método cascata, no qual o desenvolvimento é linear.

O que é Scrum?

O Scrum é um framework para a resolução de problemas. Ou seja, um conjunto de diretrizes e ferramentas que podem auxilia-lo a gerir um projeto. A vantagem do Scrum em relação a outros métodos agéis é que ele é relativamente simples de implementar e extremamente útil em situações onde é difícil prever os problemas futuros. O método também é mais democrático já que as opiniões de todos são igualmente ouvidas e desta maneira fica muito mais fácil estimar prazos, definir funções e criar soluções.

A base do Scrum é o empirismo. Ou seja, a teoria de que só conhecemos algo de fato através da experiência. E isto é muito visível no nosso mundo de desenvolvimento web, por exemplo. Os clientes fatalmente vão pedir alterações no escopo inicial, bugs vão acontecer, imprevistos vão surgir e negar mudanças pode não ser o melhor caminho para entregar um produto final de qualidade para a sua equipe, os clientes e usuários. Mas é necessário um conjunto de regras para acomodar estas mudanças ou você pode cair em um ciclo de perda de tempo sistematico. O Scrum basicamente é um conjunto de estratégias que vão te ajudar a vencer este tipo de cenário, comum a todas as profissões. O conceito foi criado inicialmente para ser utillizado em empresas de fabricação de automóveis, mas por sua natureza interdisciplinar acabou sendo adaptado para diversas outras áreas. Existem pessoas utilizando metodologias inspiradas no Scrum para organizar empresas, planejar festas, e até para lidar com problemas familiares.

O termo Scrum surgiu do rugby. No jogo a palavra scrum descreve a formação ordenada dos jogadores em determinados momentos da partida. A inspiração aqui vem da união que equipes esportivas necessitam para vencer o jogo.

O que você precisa para colocar na prática

Se você pesquisar por “Scrum” vai encontrar diversas cursos, livros e ferramentas online gratuitas e pagas. Mas é importante ressaltar que você não precisa necessariamente pagar por qualquer serviço. Você pode utilizar planilhas de dados, documentos de texto, quadros de notas ou até – pasmem! – folhas de papel. Obviamente não sou contra e não estou desvalorizando qualquer curso / certificado / ferramenta / etc. É claro que qualquer iniciativa de buscar mais conhecimento é válida e estes recursos podem agilizar ainda mais o seu trabalho. Mas você não precisa ser um Mestre Certificado XYZ ou qualquer título pomposo para utilizar esta metodologia. Você só precisa sentar com a sua equipe e organizar as tarefas. E é isto que vai gerar resultados positivos no seu empreendimento.

Com isto em mente vamos conhecer um pouco sobre como o Scrum funciona!

O Time Scrum

O Time Scrum é um conjunto multi-disciplinar de profissionais. Estes times devem ser autogeridos, ou seja, não existe hierarquia ou a figura de um líder. O time deve decidir, em conjunto a melhor forma de completar o seu trabalho ao invés de receber ordens externas de alguem que não faz parte da equipe e por isto não tem o conhecimento empirico para determinar prazos, por exemplo. A opinião de todos deve ser igualmente ouvida e respeitada. Mas existem alguns papéis fixos para auxiliar o bom andamento do trabalho.

Product Owner

A responsabilidade do Product Owner, ou Dono do Produto, é garantir a qualidade do trabalho. Este cara representa a voz do cliente, do dono da empresa, dos investidores, enfim, de todas as pessoas externas a equipe… Ele é responsável por traduzir as histórias dos usuários em uma lista de tarefas concretas, expressar claramente quais são as funcionalidades a serem desenvolvidas e definir a prioridade de cada uma de uma forma objetiva.

Scrum Master

O Scrum Master, ao contrário do que o título pode sugerir, não manda na equipe. Muito pelo contrário, o Scrum Master serve a equipe. A função dele é facilitar o bom andamentos dos jobs e garantir que todos tenham as ferramentas necessárias para cumprir suas tarefas. Tipicamente o Scrum Master é o cara que conhece melhor as regras do Scrum e portanto consegue organizar o jogo de maneira mais efetiva. Ele é uma mistura de professor, gerente e ombro amigo.

Equipe de desenvolvimento

Um pequeno grupo de pessoas (os tradicionalistas sugerem de 4 a 9) com cargos diferentes que vai trabalhar junto para cumprir as metas estabelecidas. É a galera que vai por a mão na massa e entregar um produto “pronto” ao final do ciclo de desenvolvimento. No caso de desenvolvimento web teríamos designers, programadores, front-enders, profissionais de UX, etc. Não importa o seu cargo todos tem o mesmo título: desenvolvedor.

Eventos

Quem nunca perdeu tempo em uma reunião longa e sem propósito? As vezes conversar demais (e fazer de menos) pode ser prejudicial para qualquer empresa. Pensando nisso todos os eventos Scrum são time-boxed, ou seja, tem uma duração fixa de tempo. Desta forma a comunicação é sempre mais clara, objetiva e ágil.

Sprint

Se você puder lembrar apenas de um termo do Scrum lembre-se deste: Sprint. As pessoas comuns dividem o tempo em dias, meses, horas… Os adeptos do Scrum dividem o tempo em ciclos de desenvolvimento chamados Sprints. Basicamente uma Sprint é período de tempo que você determinou para cumprir uma determinada tarefa, uma corrida para atingir uma meta. A idéia é ter algo concreto e funcional no final da Sprint. Estes ciclos devem ser períodos de tempo curtos e fixos. Você estipula anteriormente a duração das Sprints (recomenda-se de uma semana a 1 mês). Uma sprint deve começar imediatamente após o termino de outra.

Durante a Sprint não é possível alterar os objetivos estabelecidos para aquele ciclo ou os profissionais integrantes da equipe. Isto é super importante para garantir a produtividade. Mas se os objetivos tornarem-se obsoletos o Product Owner pode simplesmente cancelar a Sprint.

Sprints são divididas em etapas menores: reunião de planejamento, reuniões diárias, o trabalho de desenvolvimento em si, revisão e retrospectiva.

Reunião de Planejamento

Nesta reunião serão definidos todos os objetivos da Sprint. Nas regras oficiais, considerando um sprint de 1 mês, esta reunião tem a duração de 8 horas. Você pode adaptar isto proporcionalmente de acordo com o seu ciclo de Sprint. Se o seu Sprint é de 1 semana, por exemplo, esta reunião terá a duração máxima de 2 horas. Em cada metade da reunião duas perguntas devem ser respondidas:

- O que será entregue como resultado?
- Como o trabalho necessário para entregar o produto será realizado?

Reunião Diária

A idéia da reunião diária, ou stand-up meeting, é juntar a equipe para um bate-papo de 15 minutos no máximo para revisar o andamento do projeto. Cada membro da equipe deve responder as seguintes perguntas:

- O que eu consegui completar ontem?
- O que farei hoje?
- Quais obstáculos estão impedindo o meu progresso?

A função do Scrum Master é moderar a dinâmica e tentar ao máximo solucionar os obstáculos apresentados para que a Sprint seja bem sucedida.

Ah, e se você está se perguntando o por que do nome é que a recomendação é que estas reuniões sejam realizadas com todos de pé (do inglês stand-up). Desta maneira a reunião não se prolonga por muito tempo e todos ficam mais focados. Na minha opinião pessoal isto é um pouco formal e austero demais. Se você está sentado, de pé ou de ponta-cabeça em marte não é tão relevante quanto responder as perguntas e o respeito ao limite de tempo… Muitas vezes pausar para tomar um café (sentado) pode tornar estas reuniões muito muito mais confortáveis, agradáveis e divertidas para todos.

Revisão da Sprint

A idéia aqui, obviamente, é revisar todos os itens desenvolvidos e demonstrar o produto final. A duração desta reunião considerando um sprint de um mês é 4 horas.

Retrospectiva da Sprint

A sprint acabou! Agora é hora de olhar para trás e repensar o que deu certo, o que deu errado e planejar o que pode ser melhorado no futuro.

Artefatos

Vamos ser sinceros: artefato é só um nome mais estiloso para documento ou ferramenta. Mas eles ajudam a facilitar a sua vida…

Product Backlog

O product backlog é uma compilação de tudo o que o seu cliente gostaria de realizar no projeto. Pense com uma grande wishlist com todos os recursos e funcionalidades que os usuários gostariam de ver presentes no trabalho final. Esta lista deve ser organizada pelo Product Owner de acordo com valor, risco, prioridade e necessidade. Por natureza o backlog é algo dinâmico e muda constantemente para incluir as novas solicitações dos clientes, usuários e do mercado em si. Desta forma os produtos são sempre aperfeiçoados em cada Sprint.

Sprint Backlog

Certo, agora que já sabemos tudo o que precisa ser realizado, a equipe define as tarefas a serem desenvolvidas na próxima Sprint. Esta listinha é conhecida como – surpresa! – Sprint Backlog. O Sprint Backlog é necessariamente um afunilamento mais detalhado do Product Backlog.

Incremento

É o produto que deve estar “pronto” após a Sprint. Pronto aqui é uma palavra relativa já que o incremento pode (e deve) ser aperfeiçoado em próximos Sprints. Cada equipe vai definir anteriormente o que pronto significa de acordo com o contexto. É importante, no entanto, que o incremento seja algo concreto e utilizável. Uma demo de software ou uma página que possa ser navegada pelo usuário, por exemplo.

Burndown Chart

É um gráfico que tem a função de monitorar o desenvolvimento da equipe. Funciona da seguinte maneira: todos os dias você anota quantas tarefas do seu Sprint Backlog foram efetivamente cumpridas. Desta maneira você pode saber com antecedência a velocidade que sua equipe trabalha. Este gráfico facilita a previsão de prazos futuros e até mesmo deduzir se a deadline vai estourar. O Burndown Chart é criado tendo como base dois eixos: um vertical representando a quantidade de trabalho que existe a ser feito e um horizontal para o tempo. A linha diagonal mostrará a velocidade da equipe ao completar as tarefas. Você pode utilizar alguma ferramenta para gerar automaticamente este gráfico ou até mesmo montar um utilizando lápis e papel. De qualquer forma a Burndown Chart é uma ótima maneira de medir o nível de produtividade do seu projeto. Lembrando sempre que não dá pra adivinhar o futuro com precisão. A base do Scrum ainda é a experiência empírica.

Kanban Boards

Não é tradicionalmente parte do Scrum, mas é uma boa ferramenta de planejamento e funciona bem em conjunto com o framework. Basicamente é um quadro – ou um app, folha de papel, parede em branco, etc – com quatro lista de tarefas: “para fazer”, “em progresso”, “esperando verificação” e “feito”. Esta é uma ótima maneira de visualizar rapidamente o status de um projeto, independentemente do uso do Scrum.

Um exemplo concreto

Artefatos, mestres, papéis. A primeira vista tudo isto pode parecer mais um jogo de RPG do que um framework de gerenciamento de projetos… Mas na verdade tudo é mais simples do que parece. Vou exemplificar com uma situação real.

A sua empresa tem um cliente X que quer lançar um novo site. Um gerente de projetos (Product Owner) faz um briefing e levanta todas as necessidades do site (Users Stories). Ele se reúne com os profissionais de design, front-end e back-end (Equipe de Desenvolvimento) para definir todas as tarefas necessárias para produzir o projeto (Reunião de planejamento) e formaliza isto em uma lista de tarefas (Product Backlog). Você (Scrum Master) fica encarregado de organizar as reuniões e garantir que todos entendam as tarefas. A equipe decide democraticamente que vai entregar a página inicial pronta (Objetivo) até o final da semana (Sprint). A equipe então divide o objetivo em tarefas menores (Sprint Backlog) como criar o layout, desenvolver o HTML e CSS, implantar um sistema de administração de conteúdo e testar tudo em diversos browsers. Cada um escolhe que tarefas gostaria de realizar, define um prazo de duração em horas para cada tarefa e diariamente vocês se reúnem por 15 minutos para acompanhar o andamento do projeto (Reunião Diária). Ao final da semana vocês apresentam o resultado (Revisão da Sprint) e refletem sobre dificuldades e quais melhorias podem ser feitas na próxima semana (Retrospectiva da Sprint). Mas mais importante de tudo vocês entregaram um produto parcial, porém funcional (Incremento) para o cliente. A partir do feedback de todos vocês decidem qual vai ser a tarefa a ser realizada na próxima semana. E assim o ciclo recomeça!

Scrum But…

Algumas pessoas mais tradicionalistas consideram praticamente uma heresia modificar alguns conceitos do Scrum, prática esta que foi apelidada pejorativamente de “Scrum But” (no sentido de “Eu uso o Scrum, mas XYZ…”). Eu sou da filosofia que você deve adaptar o que for útil para você, sua equipe e seu ambiente de trabalho. Sem dogmas.

Scrum solo?

O Scrum é uma ótima metodologia para equipes, mas se você é um desenvolvedor solitário ainda pode aproveitar boa parte dos conceitos de gerenciamento de projetos. Neste caso obviamente você cumpre todos os papéis ao mesmo tempo, mas, bem… se você é um freelancer já está acostumado com isto, certo? Reuniões Diárias também não acontecem da mesma maneira (a não ser que você curta falar sozinho), mas é interessante tirar 15 minutos do seu tempo para repensar o projeto, revisar as tarefas e verificar se você está de fato conseguindo concluir as metas no prazo estipulado e determinar os próximos caminhos. Os artefatos e processos continuam os mesmos. É necessário ter mais disciplina para organizar e documentar o projeto, afinal você é praticamente um exercito de um homem só. Mas trabalhar sozinho pode ter suas vantagens. No final do dia o lucro é só seu…

É para você?

A proposta destas ferramentas é agilizar os processos de desenvolvimento de projetos, mas devemos tomar cuidado para que estas regras não engessem o fluxo de trabalho. Frameworks como o Scrum podem facilitar o desenvolvimento ou burocratizar processos. Tudo depende da forma que você coloca estas regrinhas na prática. É necessário possuir flexibilidade e visão critica para decidir o que funciona melhor para a sua equipe. Estes fundamentos foram criados tendo como base desenvolvimento de softwares, algo que costuma demandar bem mais tempo do que webdesign, por exemplo. Considerando uma empresa que possua múltiplos projetos simultaneos a coisa pode ficar ainda mais complicada.

Pode ser constrangedor explicar para um cliente por que ele não pode ter uma mudança simples como a correção de um erro de ortografia imediatamente só por que este requisito não estava no Backlog da Sprint (como bem demonstrado nesta sátira). Eu pessoalmente gosto de separar um tempinho para resolver pepinos que não estavam previstos no Sprint. Outras pessoas preferem o suporte psicológico de métodos fixos com etapas de tempo mais bem delineadas. De qualquer forma é fundamental determinar metas a longo e médio prazo com estimativas de tempo realísticas. E acompanhar de perto se estas metas estão sendo cumpridas e, caso a resposta seja não, verificar o que deve ser corrigido. Ainda assim é interessante conhecer frameworks agéis. Pequenas mudanças no fluxo de trabalho, como as propostas pelo Scrum, podem ter um impacto super positivo no seu dia-a-dia.

Saiba mais

Scrum Guide

O post Desenvolvimento ágil utilizando Scrum foi originalmente publicado em Tableless.

Objetos Literais

Este é o tipo básico de objetos JavaScript. É o formato popularizado através do JSON (JavaScript Object Notation). O objeto é criado utilizando um par de chaves ({}) e suas propriedades e métodos são todos públicos. Este tipo de objeto também é chamado de objeto estático.

var tableless = {
    init: function (artigos) {
        this.artigos = artigos;
    }
};
var tableless2 = tableless;

Todo objeto literal é um objeto único e, mesmo que você armazene ele em diferentes variáveis todas apontarão para o mesmo objeto. No exemplo acima, caso você altere/adicione propriedades em qualquer uma das variáveis (tableless ou tableless2), as modificações valem para ambas.

Seu uso é recomendado em situações onde não podem existir mais de uma instância do objeto, como por exemplo, objetos de configurações do projeto ou coleções de objetos. Além disso, este tipo de notação é muito utilizado para definir o namespace do seu código JavaScript.

// Objeto Literal definindo namespace
var tableless = tableless || {};
// Construtor para Artigo utilizando o namespace tableless
tableless.Artigo = function (titulo) {
    this.titulo = titulo;
};
var artigo = new tableless.Artigo('Mais um artigo sobre JavaScript');

Construtores

Um construtor nada mais é do que uma função. Ela pode ser executada como uma função ou pode ser utilizada para instanciar um objeto utilizando a palavra reservada new.

(Caso você execute a função como uma chamada normal, vale realçar que o this dentro da função, nesse contexto, será o objeto global window.)

function Categoria(nome) {
    this.nome = nome;
}

var categoria = new Categoria('Livros');

Ao executar a função Categoria com new estamos fazendo quatro coisas:

1. criamos um novo objeto JavaScript ({});
2. definimos o construtor do objeto categoria como Categoria – definindo também o tipo dele (retornado no instanceof);
3. definimos o protótipo do objeto categoria como Categoria.prototype;
4. executamos a função Categoria dentro do escopo do novo objeto, criando assim uma nova instância.

Uma outra particularidade das funções construtoras é a possibilidade de criar métodos e propriedades privadas.

function Categoria(nome) {
    var totalProdutos = 0,
        self = this,
        atualizaTotalProdutos() {
            self.totalProdutos += 1;
        };
    this.nome = nome;
    atualizaTotalProdutos();
}

A variável totalProdutos e o método atualizaTotalProdutos só existem no escopo do objeto Categoria criado e podem ser utilizados apenas por métodos do objeto.

Aqui utilizamos um “truque” importante. Como cada função possui o seu próprio contexto e o this dentro do método atualizaTotalProdutos referencia a própria função e não o objeto Categoria precisamos armazenar o contexto do objeto dentro da variável self. (Outra forma seria utilizar os métodos call e aply para definir o this da função, mas isso é papo para outro artigo.)

Utilizando a cadeia de protótipos, podemos atualizar propriedades ou inserir novos métodos em objetos criados a partir de funções construtoras.

Categoria.prototype.exibeProdutos = function () {
    var html = '',
        i;
    for (i = 0; i < this.produtos.length; i++) {
        html += this.produtos[i].nome;
    }
    return html;
};

O código acima adiciona o método exibeProdutos ao protótipo de Categoria e também a todos os objetos da cadeia, instanciados ou não.

As funções construtoras, portanto, são ideais para objetos que podem existir como múltiplas instâncias no mesmo contexto.

Uma observação: para melhor organizar seu código uma boa prática é utilizar a primeira letra maiúscula nos nomes de funções construtoras, diferenciando-as de funções comuns.

–

Entender conceitos de orientação a objetos em JavaScript pode levar um pouco de tempo e pode parecer bem estranho no início. Mas, uma vez entendido o funcionamento desses conceitos você descobrirá que é possível fazer diversas coisas legais e diferentes e que JavaScript é uma linguagem extremamente flexível.

O post JavaScript: Objetos Literais vs. Funções Construtoras foi originalmente publicado em Tableless.

Os desenvolvedores do browser para Mac resolveram cancelar oficialmente o desenvolvimento do Camino por causa da lentidão da sua produção. Muito por causa de browsers modernos como Chrome e Firefox que tem uma ritmo de atualização frequente. Hoje em dia um browser não pode ficar um segundo sem alguma novidade. Nem que essa novidade demore para ser lançada, mas serve pra mostrar aos seus usuários que o seu desenvolvimento está a todo vapor.

Embora eles tenham dado a notícia apenas agora, a última atualização que o browser recebeu foi em Março do ano passado.

Muito triste. Era um bom browser. Eu cheguei a usá-lo durante algum tempo e desisti exatamente pela falta de novidades, embora fosse um dos únicos browsers a ter a interface com o look and feel da Apple.

Fonte

O post Bye bye Camino foi originalmente publicado em Tableless.

Mas sempre senti que faltava um lugar para divulgar coisas que vão além só de notícias, como por exemplo quais as ferramentas mais me ajudaram nesse mês. Essa série reune o que de melhor eu encontrei no mês.

Melhor projeto: Pure

Essa foi a semana dos lançamentos de projetos open source das grandes empresas. A Adobe lançou um framework de CSS chamado Topcoat. O Facebook lançou o React, sua biblioteca de JavaScript usada em serviços como Instagram.  E, por fim, a Yahoo! apresentou o Pure, um conjunto de módulos de CSS.

Isso não quer dizer que você deva abandonar seu amado Twitter Bootstrap, cada um deles tem objetivo um pouquinho diferente. Mas o que mais me chamou atenção foi o Pure que, apesar de não ser um projeto maduro ainda, tem potencial para revolucionar a UI dos produtos da Yahoo!.

Melhor palestra: Angelina Fabbro

Além do Google I/O que mostrou coisas absurdas, outra conferência importante para o mundo do JavaScript está acontecendo nesse momento, é a JSConf US na Flórida.

Inúmeros desenvolvedores palestraram por lá, mas eu gostaria de destacar a palestra da Angelina Fabbro, que inclusive virá ao Brasil para JSConf BR. O tema da palestra foi como ir de iniciante à expert.

Melhor artigo: Caio Gondim

Um das novas propriedades do CSS que eu mais estou animado é a position: sticky. Ela aplica um efeito de position: fixed quando você atinge determina posição Y no scroll da página, coisa que antes você só conseguia simular com um pouquinho de JavaScript.

O Loop Infinito foi lá e explicou em pt-br como funciona.

E você?

Quais foram os melhores projetos, palestras, artigos desse mês?

O post Dicas do Zeno – Maio foi originalmente publicado em Tableless.