Voc? j? percebeu que, em qualquer grupo, algumas pessoas s?o naturalmente levadas a s?rio, e outras n?o? E isso raramente tem rela??o com ser ou n?o sisudo – o indiv?duo de gravata com mais cara de brabo e sem gra?a numa equipe pode n?o ser levado a s?rio por ningu?m, e o colega que est? sempre de bom humor pode ser visto com respeito por todos.

E o que os outros v?em em n?s, por interm?dio das nossas atitudes, come?a nas nossas escolhas e no modo como n?s mesmos nos vemos – em outras palavras, o caminho come?a quando n?s mesmos come?amos a nos levar suficientemente a s?rio. O artigo “5 Reasons People Don’t Take You Seriously and How to Fix It” apresenta uma s?rie de raz?es pelas quais as pessoas podem n?o estar levando voc? a s?rio, e convido voc? a pass?-las rapidamente em revista neste meu resumo.

Vamos a elas:

N?o manter a palavra

N?o dar continuidade

N?o separar trabalho e vida pessoal

Dar mais desculpas do que resultados

Andar com a turma errada

No começo de 2007 eu (Daniel) fiz a escolha de trabalhar por conta própria ao invés de continuar na estabilidade de um emprego. Desde o inicio, minha intenção era poder experimentar mercados diferentes, conhecer novas tecnologias, aprendizado e também retornos financeiros.

Assim comecei a Área Criações em sociedade com a Designer Tânia Azze. A empresa correu muito bem durante os anos que trabalhamos juntos e sempre fizemos desenvolvimento de sotware em paralelo com design em geral.

No entanto, apesar de também trabalhar como designer em nossos projetos o meu maior interesse sempre foi a área digital e no campo de design de interface com foco em desenvolvimento de software.

Tenho me especializado o máximo possível nessas áreas nos últimos anos e por essa razão, eu e minha antiga sócia, optamos por interromper as atividades da Área Criações e cada um voltar suas atenções para seus campos de maior interesse.

Objetiva Software

Eu ainda contínuo com os mesmos objetivos de 2007 e ainda não pretendo trabalhar como contratado em um futuro próximo.

Em 2010 tive a oportunidade de trabalhar novamente com o meu amigo Jeffry Degrande. Um excelente desenvolvedor com bastante experiência em Agile e Ruby, com quem eu já tínhamos trabalhado em projetos no passado e em 2010 fizemos parte da mesma equipe do Rails Rumble.

A partir dos bons resultados dos nossos trabalhos em equipe e dos interesses semelhantes, eu e Jeffry, resolvemos juntar nossa vontade em criar software de qualidade e fundamos uma nova empresa chamada Objetiva Software.

Nosso foco é unir a experiência que temos em desenvolvimento de software e design de interfaces para criar produtos que possuam alta qualidade em todos os aspectos, desde o código, testes, infra-estrutura até o posicionamento dos elementos na tela e aparência do sistema.

Seja através da criações de produtos para startup, coaching, treinamento ou desenvolvimento de projetos já existentes, o nosso objetivo é sempre manter os princípios que acreditamos na indústria de software e fazer o melhor trabalho possível.

A parte boa de tudo isso que apesar de apenas alguns meses de vida, nosso novo negócio tem corrido muito bem e já estamos alocados para vários projetos nos próximos meses, então aguardem algumas novidades em pouco tempo.

Nosso blog

No antigo site da Área Criações, eu era o responsável pelo blog, que movimentei com assuntos técnicos desde 2007. Muito do material que escrevi ainda é válido, principalmente os posts relacionados a Ruby e desenvolvimento em geral.

Por essa razão nós resolvemos importar alguns dos posts que condizem mais com as atividade da Objetiva e evitar a perda de todo esse material que ainda possui bastante utilidade. Nos próximos dias o site da Área Criações sairá do ar mas grande parte do material já está importado para o novo blog da Objetiva.

Mas vamos precisar que vocês atualizam os feeds para o novo endereço

Para qualquer vitória duas coisas são essenciais: ação e ousadia Ficar sonhando a vida inteira não leva alguém a algum lugar, a qualquer conquista. É preciso agir, após um período de reflexão e planejamento, mesmo que apenas mental. Mas é raro ver uma ação sem uma certa dose de coragem. Não é fácil sair da [...]

Saudações pessoal! Algumas informações do mundo do VXTra.org. ======================================================================= 1. Artigo fresquinho Quero largar meu emprego! Será que consigo? Resumo: Vou aqui fazer um exercício, no qual vou me imaginar trabalhando em uma empresa e completamente insatisfeito com o meu trabalho atual. Pode ser que eu goste da empresa, tenha uma remuneração adequada, tenha boa [...]

Caro amigo leitor, depois de muito muito tempo, aqui estou novamente escrevendo a você. Depois das minhas desculpas do ano de 2009 (dois posts atrás), por causa de TCC e outras coisas, mal sabia eu o que o ano de 2010 me reservava. Vou resumir: Treinamentos, casamento, reforma de imóvel, viagens e dois empregos formais. Pois é, a coisa pegou e o ano acabou. E nada do que havia prometido para o ano de 2010 eu consegui cumprir (em relação ao blog, claro!).

Por outro lado, pelos mesmos motivos (Treinamentos, casamento, reforma de imóvel, viagens e dois empregos formais) o ano de 2010 foi excelente! Tive muitas experiências novas em minha vida pessoal e profissional. O que posso destacar aqui são as aulas de desenvolvimento web que comecei a ministrar para o curso de Sistemas de Informação na Universidade de Franca, como sempre digo, treinamentos e cursos são uma via de mão dupla, onde todos aprendem de forma colaborativa, é sensacional!

No momento estou me atualizando em Flex, desvendando os segredos do Flash Builder Burrito. Fiz uma versão mobile da Agenda de Contatos que deixo o código fonte disponível no blog. Até agora estou achando ótimo! Veja os prints:

A única coisa que ainda não consegui foi fazer o deploy da aplicação, nem no celular nem no emulador do Android, por isso ainda não postei o código fonte pra vocês. Assim que resolver todos os problemas, ele aqui estará.

É inacreditável a facilidade de desenvolver as aplicações mobile com o AIR. Neste exemplo estou usando o serviço remoto da agenda mesmo, usando as classes Remote Object da mesma forma de uma aplicação Flex, sem alterar absolutamente nada.

Agora, o que anda me interessando mesmo é o Android em si, depois de ver a apresentação do TCC do Marcos Rezende, que se tratava de uma aplicação que controlava o consumo de veículos, datas de revisão, tinha integração com o GPS e tudo mais (genial!), resolvi aprofundar os meus estudos na plataforma do Google, e vou ser sincero, estou gostando bastante. Creio que neste ano teremos posts sobre isso rolando por aqui.

Enfim, aproveitando o título do post, gostaria de agradecer a todos os amigos, parceiros, clientes, alunos, familiares e esposa que fizeram este ano de 2010 tão especial e desejar a todos que em 2011 todos os nossos objetivos sejam alcançados.

FELIZ 2011!!!

Começou um certo barulho na comunidade de desenvolvedores brasileiro em volta do plano de certificação Pomodoro. Isso não é novidade mas só agora crio um certo barulho.

Já há a bastante tempo venho usando a metodologia e em todos os casos que uso por completo o benefício é gigante.

O benefício real do pomodoro não está na idéia ridícula de ter um timer de 25 minutos. O intervalo na verdade pode ser qualquer tempo, contando que você consiga passar esse tempo todo sem distração.

A grande vantagem está no planejamento e revisão dos seus resultados. A medida que vai trabalhando com Pomodoro, começa a conhecer com mais precisão quantos pontos consegue fazer por semana. Outra vantagem é poder analisar seus resultados e ver porque na semana X você foi mais lento que na semana Y.

Estas análises tem me ajudado a perceber que trabalho melhor sem música, na parte da manhã e com skype/ichat fechados. Também passei a abrir o email apenas 3 vezes ao dia com base no que aprendi com os meus Pomodoros.

Na prática, eu não vejo diferença nenhuma de Pomodoro e métodos ágeis. Ou seja, releases menores, feedback, review, foco e etc. No meu ponto de vista as únicas diferenças são que o Pomodoro é aplicável em qualquer coisa, é individual e mais antigos que Agile.

De fato coisa é bem mais complicada que um timer bobo. Se você trabalha em um escritório com 10 pessoas, como deve proceder para a metodologia continuar tendo benefícios? Como você evita distrações em escritórios? Se você não usou um dia será quer perdeu suas métricas da semana toda? E se um cliente te liga para explicar uma funcionalidade, isso quebra o Pomodoro?

Essas perguntas só tem boas respostas quando respondidas por quem já usa há bastante tempo. Razão pela qual sempre achei interessante os cursos e material sobre Pomodoro do Francesco Cirillo.

Na prática eu vejo a aplicação do Pomodoro algo tão discutível como emprego de métodos como Scrum e principalmente Kanban. A diferença é que o foco é no indivíduo.

Também é importante lembrar que não adianta nenhum método ágil se o membro da equipe, sozinho, não for ágil o bastante para administrar o seu dia e cumprir suas tarefas.

Quanto a cerfiticação, é claro que sou contra. Mas sou contra por motivos diferentes do que as pessoas tem falado.

Percebi pessoas dizendo que isso é ridiculo mas no sentido da técnica ser simples de mais para caber algo como uma certificação. Se o raciocínio é este então eu descordo completamente e acho que faltou bastante pesquisa antes de formar uma opinião qualquer.

A razão pela qual sou contra a certificação é a mesma que me faz ser contra certificações Scrum, Ruby ou quem sabe, um dia, Kanban. Pelo simples motivo de não garantir nada e de que para ser produtivo uma pessoa pode usar vários métodos, Pomodoro é um deles.

Twitter!

Boas práticas e testes no nosso dia-a-dia de desenvolvimento

Testes unitários já foram vistos com maus olhos pela comunidade de desenvolvimento de software quando surgiram, e hoje em dia é uma das práticas obrigatórias no desenvolvimento da maioria dos sistemas. Mas afinal o que fez todo mundo mudar a maneira de pensar e trabalhar? O que motiva um desenvolvedor a “perder tempo” escrevendo testes unitários?

As respostas hoje em dia são bem claras na cabeça de muitos desenvolvedores, por isso vamos passar por temas que vão além dos testes unitários e abordar como nos beneficiamos a longo prazo com uma política de testes e boas práticas bem definida.

Testando sempre, corrigindo sempre

Já que todos concordam (a grande maioria pelo menos) que testes nos beneficiam, porque não testar em todo o processo de desenvolvimento? Uma dúvida que surge assim que a equipe resolve testar suas classes: devemos estimar também o tempo que levaremos para escrever os testes? A resposta é simples, sim e não. Sim porque com certeza o tempo para executar a tarefa será diferente quando resolvemos escrever testes para nossas classes, e não porque não devemos separar a estimativa, como se escrever testes fossem uma tarefa diferente. Inclusive deveríamos considerar que uma tarefa só é concluída se existem testes unitários que garantem o funcionamento da mesma, e que tais testes estejam passando.

Podemos pensar que se para cada funcionalidade que implementamos garantimos o funcionamento da mesma, estamos seguros para implementar uma nova funcionalidade sem interferir no progresso do sistema até então. A única maneira de garantirmos que toda funcionalidade nova estará de acordo com as já existentes é testando ao longo de todo o projeto. O mesmo vale para testes de uso, feitos por uma equipe de testes, pois se pensarmos que os testes unitários nos protegem de nossos próprios erros, ainda assim não estamos protegidos de erros de sistemas externos que serão usados par integração com o nosso projeto.

O fator mais crítico em se testar sempre, é que quando nos deparamos com um determinado erro, nossa cabeça ainda está no contexto da tarefa ao qual o teste falhou, e portanto está mais claro em nossas mentes como corrigi-la, acelerando a correção de erros e o desenvolvimento de novas tarefas mais futuramente.

Relatórios de Cobertura

Os relatórios de cobertura de testes a primeira vista parecem um ferramenta de controle sobre como estamos desenvolvendo. Muito pelo contrário, porque os relatórios de cobertura apenas expoem as linhas e blocos do código que são executados durante os testes, escondendo muitos outros fatores relevantes no desenvolvimento, além do que é bem fácil “roubar” no teste para obter uma cobertura alta.

O relatório de cobertura serve como ferramenta de alerta para a equipe como um todo, para que a qualquer momento, qualquer membro da equipe possa consultar o relatório e se certificar que dado a cobertura de testes, ele pode continuar o desenvolvimento de suas tarefas ou então, notificar toda a equipe que existem partes do código não testadas e que devem receber mais atenção para garantir uma evolução contínua do sistema.

FindBugs e PMD

O FindBugs é uma ferramenta que nos auxilia no desenvolvimento prevendo possíveis pontos problemáticos do sistema. O FindBugs funciona com o Java mas existem versões para diversas plataformas.

No mesmo espírito do relatório de cobertura, os possíveis bugs apontados pelo FindBugs servem como alerta para a equipe para pontos do sistema que talvez mereçam mais atenção, e da mesma forma é possível “roubar” e sempre deixar o FindBugs “contente”, por isso é essencial a consciência da equipe para manter o FindBugs dentro da linha.

O relatório gerado pelo PMD é mais um guia de boas práticas que deveriam ser seguidas durante a implementação do código. O PMD é bem menos intrusivo que o FindBugs no sentido de que a análise feita por ele é mais voltada a estilo de programação, e pode ser configurada e ajustada de acordo com o projeto e a equipe. O ideal seria que conseguíssemos estabelecer uma configuração do PMD e do FindBugs para a DClick, garantindo que se mudarmos algum desenvolvedor de equipe, o desenvolvedor iria estar familiarizado com as práticas e padrões do novo projeto, afinal seriam os mesmos padrões exigidos no projeto em que o desenvolvedor estava.

Site do FindBugs

Site do PMD

Checkstyle

Um dos principais objetivos de se empregar boas práticas de programação, é garantir uma linguagem comum entre equipes de desenvolvimento. Para facilitar tal compreensão, seria interessante que o código implementado independente da equipe, seguisse uma mesma identação e organização. Dessa forma um desenvolvedor novo no projeto consegueria “se encontrar” no código de maneira mais rápida, porque a estrutura adotada seria a mesma em todos os projetos.

Para facilitar e garantir que o padrão está sendo seguido, existe por exemplo, o plugin de ‘checkstyle’ do eclipse. O plugin nada mais faz do que colocar warnings no código, nos trechos em que o padrão de identação e organização definido não está sendo seguido. O plugin consegue ir um pouco mais longe do que meramente validar formatação de código, e consegue “cobrar” o emprego de algumas boas práticas mais básicas, como por exemplo encapsulamento e gerenciamento de variáveis.

Site Oficial do Checkstyle

Documentação

Se escrever código de maneira padronizada, organizada e compreensível é essencial para comunicação, o mesmo se aplica para a documentação das classes.

Por isso que existem ferramentas como o javadoc, que é uma das ferramentas mais difundidas na comunidade. Isso porque garante a geração de uma documentação livre de código de maneira automática e simples. O que deveríamos ter em nossas classes, é uma documentação na qual não seja necessário ler o código para entender o funcionamento da classe. A única maneira de garantir um nível de documentação desses, é sempre manter a documentação atualizada e constantemente mudá-la conforme desenvolvemos o sistema.

No Java existe o Javadoc que é tão difundido que já vem integrado com o Eclipse IDE, e existem versões disponíveis para todas as grandes plataformas, inclusive Flex.

De modo geral

Apesar de citar algumas tecnologias usadas no Java, o objetivo principal do post é mostrar que o emprego de tais ferramentas nos ajuda no dia-a-dia de desenvolvimento em geral, não importando a tecnologia utilizada. A idéia é atingir um nível de qualidade geral, independente de plataforma. Se atingirmos um nível aceitável e conseguirmos seguir um padrão, conseguiremos migrar entre projetos tendo que apenas entender a regra de negócio do projeto, já estando familiarizado com as práticas de desenvolvimento.

Por vezes, nem todo o bom conteúdo tem de ser pago!

Neste mundo da Internet, há vários sítios onde podemos encontrar verdadeiros compêndios sobre cada tipo de tecnologia. Quer seja em blogs, fóruns de discussão ou mailing-lists, há sempre um conjunto de locais onde podemos procurar informação sobre o mais variado tema.

No caso deste post, vamos indicar um outro tipo de veículo de conteúdos que existe no mundo digital, o e-book.

É verdade que, neste momento, os e-books estão a ter a sua maior ascensão devido a dispositivos como o Kindle ou o iPad que nos permitem ter verdadeiras bibliotecas na palma da mão e nos permitem, entre outras coisas, pesquisar por palavras de uma forma muito mais rápida.

Mesmo assim, neste aspecto, confesso que sou um pouco antiquado e adoro comprar livros em formato papel…

Aqui ficam três propostas de três livros, em versão completa, totalmente grátis para download!

Web Style Guide: Basic Design Principles for Creating Web

Considerado um dos melhores livros no que concerne ao web design, já vai na sua terceira versão e tenta transmitir uma boa dose conceitos bases para qualquer aspirante a web designer. Criado em colaboração com vários profissionais da área, podem contar com um livro rico em ilustrações e conteúdo que vai desde a tipografia, passando por técnicas de CSS e terminando em conceitos de usabilidade universal.

Take your talent into the web

A versão paga deste livro atingiu as cinco estrelas na Amazon desde o momento em que foi lançado em 2001.

Segue uma abordagem um pouco diferente e tenta fazer a ponte entre os designers / artistas e a web.

web designer’s Success Guide : how to profit from freelance web design

O web designer’s Success Guide, como o nome indica, tenta demonstrar como podemos lançar o nosso próprio negócio como freelancer neste mundo da web. Fala da transição de um emprego “normal” para um em nós próprios controlamos o nosso tempo, como nos “mostrarmos” aos outros, como controlar os tempos dos projectos e até como chegar a um preço final por cada trabalho que nos é pedido! Um livro interessantíssimo para ler!

Espero que tenham gostado das dicas e partilhem também outros livros e conteúdos interessantes que hajam pela web!

Cumprimentos, Mauro.

Olá Pessoal. Quem acompanha o meu blog percebeu que há tempos não publicamos nada. A dedicação Flex era apenas na venda dos livros e no suporte dos mesmos. Isso ocorreu porque eu estava finalizando o meu emprego CLT, no qual trabalhava exclusivamente com DotNet. Agora que pedi demissão, estou voltando com força total, e me dedicando plenamente ao Flex e ao desenvolvimento RIA como um todo. Se você tem dúvidas ou quer ver exemplos, escreva para nós. Na página de exemplos já temos diversos itens para fazer e eu aguardo mais, OK?

Esta semana eu estava dando uma olhada na grade do curso de Frontend da Egenial que vai começar neste sábado. Lendo sobre o curso veio novamente aquela lembrança de como o mercado, principalmente brasileiro, é fraco em produtos agradáveis de serem usados.

Por exemplo, eu não conheço nada semelhante ao Shopify em português, muito menos algo como o Basecamp. Que existem concorrentes brasileiros existem, mas por que todos são extremamente inferiores e conseguem até gerar ódio dos usuários?

Não entendo e nem quero entender nada de design

Muitos desenvolvedores criam seus projetos, abrem empresas, montam startups ou entregam produtos para clientes sem ter a consciência que talvez o seu código suado não tenha valor nenhum.

Alegando o contrário, você vai dizer que fez a analise do que era necessário, possui testes, empregou as melhores tecnologias, conversou com o cliente em todas as etapas e agora está tudo exatamente como combinado.

Porém existe uma coisa que a grande maioria das pessoas da área de TI não se preocupa. A interface, ou seja, como será usado seu sistema.

Amor a primeira vista

Em um produto material (não virtual) várias coisas contam, por exemplo a textura, como as coisas funcionam, a matéria prima empregada, como foi empregada, os encaixes e etc. O contato com o produto é físico e apenas por tocar um produto você consegue dizer se ele é uma porcaria ou não e se tem utilidade ou não.

No caso de produtos virtuais esse contato não existe e o mais próximo que temos da situação acima é contato com a interface do sistema.

Agora imagine o seu código lindo e maravilhoso embrulhado em telas cinzas e com 50 campos de formulário sem nenhuma lógica ou explicação?

Qual reação o usuário terá? Com um único olhar ele vai entender isso tudo como uma grande porcaria que é obrigado a usar pois faz parte do seu cotidiano. Quantas vezes você não vê pessoas reclamando que é uma falha no sistema? A grande maioria das vezes são apenas dificuldades que esta pessoa está tendo para entender como as coisas devem fluir naquele emaranhado de botões e campos.

Pensar como as telas vão ser desenvolvidas, quais são os passos lógicos que o usuário deve tomar, quais telas devem existir e quais não devem é sim parte do trabalho do desenvolvedor.

Para entregar um produto de real qualidade para quem vai usar seu sistema todos os dias é necessário que todas as pessoas da equipe entendam que a interface e o design são no mínimo 50% do produto e que o usuário deve abrir seu sistema e se sentir confortável. É assim que você se sente ao ligar seu Macbook ou seu iPhone. Você também não usa seu Gmail com medo de fazer uma bobeira por não saber onde está clicando. No seu produto não deve ser muito diferente.

Você não precisa se tornar um exímio desenhista e criar logos e ícones mas você precisa ter o censo crítico para identificar que seu produto é uma porcaria ou uma maravilha. Também deve ser capaz de conversar com os designers da sua equipe de igual para igual se aquela barreia que existe na maioria das empresas.

Design de UI NÃO É ARTE!

Design de software é quase nada de trabalho artístico e muito, mas muito, trabalho racional. Se ainda está relutante se deve entender algo sobre design ou não eu recomendo fortemente este vídeo para você entender porque um negrito em local é mais importante que um itálico:

<object height=”360″ width=”540″><param /><param /><param /><embed src=”http://vimeo.com/moogaloop.swf?clip_id=6702766&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=0&amp;show_portrait=0&amp;color=b30000&amp;fullscreen=1″ height=”360″ width=”540″></embed></object>

Por onde começo?

Com tudo isto em mente, se tornar um “Devgner” (como costuma dizer Lee Brimelow) é extremamente complexos (se ainda não viu o vídeo acima veja logo).

Voltando ao começo deste post, este curso de Frontend é algo que venho sugerindo ao pessoal da Egenial e conversando com eles a bastante tempo por todos estes motivos acima. Recomendo que você comece fazendo os seus softwares melhores através deste primeiro passo com o curso.