Mês: setembro 2010

XSS na mídia

Thiago Burgos Programação, Tudo , , ,

Nos últimos dias quem acompanhou as notícias do mundo de TI deve ter visto ou ouvido sobre o bug do on mouse over do twitter ou do Bom Sabado do Orkut.

Entrando um pouco mais em detalhes sobre a causa do problema vamos ver que a falha de segurança foi ocasionada pelo famoso Cross-Site Scripting ou simplesmente XSS (é famoso mas muita gente não conhece, inclusive eu não conhecia 😛 #ShameOnMe). Para começar, vamos a uma rápida definição de XSS:

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pagesviewed by other users.

Quem já ouviu falar em SQL Injection? Pois bem, XSS é uma vulnerabilidade semelhante só que utilizando javascript, algum usuário insere código javascript malicioso (pegar as sessões de usuário, redirecionar navegação para outro site mais malicioso ainda, etc) em algum formulário na web, e BANG! quando alguém vizualizar aquelá informação no sistema, o código malicioso será executado (e possivelmente propagado, como no caso do bug do orkut).

Meu amigo Edwin Carlo me apresentou o OWASP (Open Web Application Security Project) que é uma organização focada em melhorar a segurança dos sistemas web, e eles mantém um rank das vulnerabilidades mais comuns, e adivinha? XSS é a segunda (só perde para injections tipo sql injection).

A boa notícia é que existem soluções fáceis para evitar ataques do tipo XSS, e aqui vai um redirect para outro amigo meu, Tiago Farias que fez um post bem legal e detalhado sobre como criar um Filtro Anti-XSS em Java. Você, meu amigo desenvolvedor, por favor atente para isso a partir de agora 🙂

O Desafio do Sprint Planning 2 no Scrum

Thiago Burgos Agilidade, Tudo , ,

Uma boa sprint começa com um bom planejamento!

Para quem não está familiarizado com o scrum, no fluxo normal  nós temos dois passos que iniciam a execução da sprint chamados “Sprint Planning 1” e “Sprint Planning 2” (representados na imagem acima pelos dois primeiros blocos de fundo verde).   No Sprint Planning 1, é onde acontece a escolha de quais itens de backlog (IBL) serão feitas na sprint. Nesta reunião é muito importante a presença do product owner pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido, na grande maioria das vezes ele que tem o conhecimento do negócio e que tem a visão mais acertada de onde quer que o produto/projeto chegue. Essa escolha das IBL’s é feita de pelo time todo, ou seja, todo o time tem que concordar que terão condições de implementar aquelas estórias escolhidas. Uma vez escolhidas as estórias que serão feitas na sprint, chega o momento da Sprint Planning 2…

Na reunião de “Sprint Planning 2” todo o time concentra seus esforços em quebrar aquelas IBL’s (estórias) em unidades menores de trabalho que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its (nada contra, mas tenho pena das árvores 😛 vamos começar o movimento #RecyclePostIts). Bom, é nesse momento que acontece a explosão de tarefas, a sprint começa sem ter nenhuma tarefa a ser feita e na sprint planning 2 as tarefas são levantadas. A importância dessa fase do scrum é a seguinte: O que você levantar como tarefa aqui vai guiar seu desenvolvimento da sprint toda (e é claro que você pode lembrar/criar mais atividades no decorrer da sprint, mas essa visão inicial ajuda muito e já pode antecipar alguns problemas que poderiam acontecer).

É aí que aparece a pergunta: Mas como eu quebro as estórias em tarefas?  Qual a granularidade? E é justamente para tentar responder essas perguntas que eu vou tentar listar algumas dicas ou instruções de como quebrar as tarefas.

  • 1) Granularidade grossa: Uma das primeiras recomendações para a quebra de tarefas é sempre criar tarefas que possam ser feitas em 1 dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa com o objetivo que ela caiba em 1 dia de trabalho. O objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder visualizar o trabalho diário no burndown, que nesse caso vai se mover dia a dia, ao invés de ficar parado uns dias e depois se mover.
  • 2) Granularidade fina: O ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma tasks (lembrando que para que isso aconteça é preciso uma análise detalhada da estória a ser desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes, etc, etc, etc). Cada detalhe então vai virar uma task e isso facilita a vida de quem desenvolver a estória pois as tarefas já são quase que um guia e a finalização das tasks da estória simbolizaria que não falta mais NADA para aquela estória. Ex.: Se você sempre acaba a estória e vê que a equipe não fez uma validação javascript em um formulário, então na próxima sprint você já inclui a validação como uma tarefa (pois-it) a parte.
  • 3) Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas a relidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá por base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, junta mais coisa em um tasks só (que façam sentido estar junto obviamente). Caso a granularidade tenha sido muito grossa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais.

Bom, acredito que com essas coisas em mente vamos conseguir planejar melhor nossas sprints, e consequentemente finalizá-las melhor também! Você tem alguma dica a respeito da separação de tarefas no sprint planning? Deixa tua dica aqui como comentário 🙂 valeu!

“Ctrl+Shift+R” no Visual Studio

Thiago Burgos Programação, Tudo , ,

Só quem já utilizou o eclipse e conheceu o “Ctrl+Shift+R” que sente sua falta quando vai pro VisualStudio.net  da microsoft.

O “Ctrl+Shift+R” serve para localizar e abrir rapidamente arquivos, basta digitar “Ctrl+Shift+R” que uma janela já é aberta e você pode começar a digitar o nome do arquivo que está procurando. Pois bem, existem opções para o visual studio 😛

O plugin do visual studio se chama ‘VsOpen’ e maiores detalhes podem ser encontrado aqui:

http://techne.cesar.org.br/?p=473

A dica foi do Pedro, do C.E.S.A.R e está no blog de tecnologia deste Centro de Pesquisa.

Refactoring x Rework

Thiago Burgos Agilidade, Programação, Tudo

Estava comentando sobre práticas ágeis com um amigo e disse que gostava muito de coisas como Design Evolutivo, KISS (keep it simple stupid), essa coisa de acolher as mudanças (embrace changes), e falei na palavra chave Refactoring. Pra que eu fui falar isso? 😛 Na mesma hora eu ouvi: “Refactoring ou Rework? para mim é  mesma coisa!“.

Desde aquele dia tive vontade de escrever um post falando sobre isso, e tentando explicitar as diferenças ( porque na minha cabeça é completamente diferente ). Apesar de soarem como coisas similares para algumas pessoas, e algumas outras pessoas até confundirem dizendo que estão fazendo refactoring quando estão fazendo rework e vice-versa, existem diferenças entre essas atividades.

Vamos começar com a definição do que é refactoring:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Como a própria definição já fala, a idéia do refactoring é modificar a estrutura interna (design) do código de forma a melhorá-la ou ajustá-la para algum comportamento que não tinha sido previsto anteriormente (embrace changes). O Refactoring se encaixa perfeitamente no mundo das práticas ágeis justamente porque a idéia do desenvolvimento ágil é se preocupar com o AGORA, então o design da aplicação vai ser feito pensando nas coisas que se conhecem hoje, e que são precisas hoje, e esse mesmo design evolui a medida que o conhecimento vai aumentando, ou que

as mudanças forem chegando . Esse é o famoso design evolutivo, que anda de mãos dados com o refactoring, pois o refactoring dá subsídio a evolução do design.

Só para ficar mais claro do que é design evolutivo e refactoring eu queria falar de como seria o oposto disso tudo. O oposto disso seria nós começarmos um projeto com uma tela

de login, e um usuário que loga e mostra a tela principal e no momento de fazer o design das classes eu já criar (isso mesmo, cedo assim)  diversos componentes do sistema, criar interfaces para meio mundo de coisa, criar classes abstratas que vão representar objetos que só vão ser criados daqui a 6 meses, ou 1 ano. Como você pode notar eu já teria uma “arquitetura” pronta desde o início do projeto, e isso pode acarretar algumas coisas como: 1) Aceitar mudanças vai ser tornar um problema maior do que o normal, pois você já preparou seu sistema para um determinado comportamento (mesmo sem te

r muito conhecimento, pois normalmente no inicio do projeto se tem pouco conhecimento a respeito do negócio/domínio); 2) Provavelmente algo do que você fez NUNCA será usado, e talvez ainda esse algo (NUNCA usado) seja causa de bug e de dificuldades no design da aplicação (mas novamente, mudar já se torna bem mais dificil pois já tem muita coisa pronta).

Bom, acredito que já está mais claro o que é refactoring e como ele está diretamente relacionado com agilidade e com desenvolvimento iterativo/incremental. Acredito que não preciso nem falar muito sobre Rework, mas como é o título desse post então vamos lá. Começando com a definição:

Rework is to rewrite or revise; To work over again.

A própria definição já diz muita coisa, é reescrever algo, refazer, fazer de novo. Aí você pode perguntar: mas no refactor você também não refaz? E eu respondo, isso mesmo, só que o propósito de refazer do refactoring é diferente, é melhorar e ajustar e não corrigir algo que foi feito errado. E é justamente aí onde entra o rework, se eu fiz alguma coisa errada, vou ter que fazer um rework para corrigir. Se criei algo de forma errada tenho que refazer (rework). Então vamos lá… Toda correção de Bug é um rework. Toda correção de um requisito é um rework. Isso tudo porque você está gastando tempo de novo com algo que teoricamente já devia estar bom. Se no seu refactoring você introduzir bugs, vc terá que fazer um rework do refactoring para corrigir esses bugs ( e isso sim é perder tempo/dinheiro). Vamos continuar…. Toda mudança de requisitos ou requisito novo que for impactar o design do sistema é rework ou refactoring? Refactoring, pois o requisito estava OK até a mudança ou até a chegada do requisito novo.

É isso aí, espero que tenha ficado mais explícita a diferença entre essas duas palavras tão parecidas.

Morte a estruturação de HTML com Tables

Thiago Burgos Programação, Tudo , ,

HTML é muito bom, mas tem seus problemas. Ao meu ver, um dos maiores problemas do HTML é em termos de estruturação das páginas, pois a GRANDE maioria das páginas utilizam o famoso <table></table> como forma de estruturar/alinhar/organizar seus itens na página.

Nenhum problema até aí certo? Errado! Existe alguma coisa estranha nisso tudo, afinal a tag table deveria servir para criar tabelas (ao invés de ser usada para estruturar o sistema) . O problema todo de se usar tabelas é que simplesmente elas não foram feitas para fazer estruturação, como por exemplo, organizar inputs de um formulário um embaixo (ou ao lado) do outro. E aí é onde mora o problema, não existem tags disponíveis (pelo menos eu não conheço, quem conhecer me avise pelo amor de Deus) para fazer tais estruturações.

Quem nunca precisou ajustar uma página e perdeu um tempo ridiculamente alto para posicionar um item por conta dos milhares de <table>’s, <tr>’s, <td>?É simplesmente uma tarefa difícil, custosa, e estressante.

Para ficar mais claro ainda o problema, eu vou falar das soluções que já existem. outras tecnologias disponibilizam componentes para estruturar outros elementos da página (verticalmente, horizontalmente, ou por posição absoluta na tela).

O primeiro exemplo, é o nosso querido flex. O flex tem o componente para criar tabelas (grid), mas ele não é o mesmo componente usado para estruturar os elementos na página. Para estruturar os elementos na página são utilizados outros componentes, conhecidos como layout containers como: Caixas verticais (VBox), Caixas Horizontais (HBox), Canvas livre (para posicionamento absoluto utilizando as coordenadas X e Y para posicionar), etc…

Ainda existem outros do flex, mas só esses 3 que eu citei já dão pra fazer quase tudo (senão tudo) em termos de estruturar seus elementos na página.

Outro exemplo é o nosso querido WPF da querida Microsoft, que também disponibiliza componentes semelhantes (containers) aos que o flex disponibiliza: StackPanel, DockPanel, Canvas e etc.

Tudo bem, eu sei que WPF é da microsoft e não é free nem é padrão como HTML. Sei também que o flex apesar do core ser free, mas a IDE é paga então também é uma dificuldade a mais. De qualquer forma, bem que o HTML5 poderia ter algo do tipo né?  (Eu não conhece e procurei rapidamente e não encontrei, mas se existir algo do tipo no HTML5, por favor me avisem! :D)