Se você já teve contato com Laravel ou AngularJS, sabe muito bem que um dos maiores motivos de orgulho desses (e de tantos outros) frameworks é a "Injeção de Dependência", ou do inglês, Dependency Injection. Imagine-se em uma reunião, o seu Product Owner pede soluções para problemas complexos, e você manda logo um "precisamos usar injeções de dependências"... É aumento salarial na hora!
Sim! Esse é mais um post sobre Vagrant, entre tantos outros espalhados pela Web. Sim! Se você já conhece a ferramenta, provavelmente não terá nada de novo para você nesse artigo.
Já falamos um pouco sobre ambientes virtuais, e as vantagens são numerosas. A "atomicidade" de poder construir e destruir um ambiente inteiro, sem acarretar efeitos colaterais ao seu ambiente de trabalho, traz agilidade sem perder segurança e sanidade.
Já falamos sobre o virtualenv há muito tempo atrás, aqui no blog. Tirando alguns detalhes técnicos, a bem da verdade é que de lá para cá, pouca coisa mudou.
Apesar do seu uso ser completamente trivial, ter virtualenvs espalhados pelo seu disco rígido pode ser chato de gerenciar. Que tal uma forma simples e centralizada de manipular os seus ambientes Python?
No post anterior, vimos um dos cenários de testes utilizados por times da Globo.com, onde não escrevemos testes "isolados" (famigerados microtests), e abusamos da integração entre classes e serviços.
Mas até mesmo para nós existe um limite que não podemos ultrapassar: O caso de uma consulta a uma API externa, por exemplo. Nesse cenário, precisamos fingir que estamos fazendo isso, sem perder a segurança em nossas asserções.
Certa vez, estava eu atualizando o meu LinkedIn quando o @davidsonfellipe me indagou sobre o título de "Analista e Desenvolvedor Web" que possuo atualmente. Segundo ele, "Front-end/Back-end Engineer" é mais atrativo para que headhunters cheguem a um perfil.
Em tempos onde discussões envolvendo a relevância dos testes têm causado furor nos diferentes campos da área do desenvolvimento de software, nada mais justo do que "chovermos no molhado", e falarmos sobre testes, mocks, stubs e todos os seus primos menos famosos.
Neste mês de Maio, faz 3 anos que deixei Schroeder (SC) e me mudei para o Rio de Janeiro, para trabalhar na Globo.com. Não tinha como ser diferente: Eu estava estudando as tecnologias utilizadas pelo "plim-plim" há quase 1 ano, e idealizava como seria trabalhar para uma das maiores empresas de mídia da América Latina.
O Django é de longe o meu framework Python favorito. Fácil, extensível, com uma série de "baterias inclusas" que tornam o desenvolvimento de aplicações Web muito mais fácil e divertido.
Mas verdade seja dita, para algumas soluções, é como se utilizássemos um canhão para matar um mosquito. Existe toda uma preocupação no que diz respeito a persistência, caching, serviço de aplicação e serviço Web, que em determinados contextos não passa de "overhead".
No dia 03 de agosto de 2013, tive o prazer de participar do Front in BH, edição 2013. Organizado pelo @davidsonfellipe e @keppelen, o evento contou com palestrantes de peso e com uma organização que, além de surpreendente, tirou um "gosto ruim" que eu tinha em relação a eventos de front-end.
Há um bom tempo que eu trabalho com o Vim, tanto tempo que quando estou em qualquer outro editor escrevo :wq para salvar e sair.
Mas não comecei a utilizar o Vim por gostar de desafios… foi pura necessidade! Trabalhei em uma empresa onde desenvolvíamos em uma máquina remota, através de linha de comando. Logo, entre o Vim e Emacs (ou ficar subindo arquivos via FTP ou SSH), optei pelo mais fácil de usar. É claro que no início eu não conseguia encontrar facilidade de jeito nenhum. Navegar pelas teclas h, j, k e l não fazia sentido nenhum para mim, sem falar que (segundo os meus colegas de trabalho) utilizar o PageUp , PageDown, Home e End era praticamente uma heresia.