Para quem (assim como eu) começou com o PHP, uma das opções mais viáveis para servir projetos na web sempre foi o Apache. Open source, prático e disponível em quase toda hospedagem de respeito (afinal, ele vem por padrão em quase toda distro Linux), há anos que ele faz a famosa tríade "AMP" (Apache, MySQL e PHP).
E quem nunca precisou adicionar ou remover alguma coluna, nas tabelas do seu banco de dados, depois que a aplicação já estava em produção? Os riscos existem (e são altos), e podem ser diminuidos através de processos automatizados.
Meses atrás, escrevi sobre como era fácil criar objetos em Javascript. Devo confessar que, a minha visão sobre a utilização da Orientação a Objetos em Javascript era muito superficial, e que uma dúvida muito pertinente surgiu na época: Onde usar object literal e onde usar classes?
Mesmo que você possa verificar a qualidade do seu código com pep8, Pylint e Pyflakes, uma das virtudes de um projeto de software é não possuir código duplicado (leia mais sobre DRY). O fato é que tanto intencionalmente como propositalmente, podemos duplicar um trecho de código e acabar prejudicando manutenções futuras (atire a primeira pedra quem nunca deu aquele CTRL+C e CTRL+V, e prometeu um refactoring depois).
Se você precisa de uma ferramenta mais poderosa que o pep8, talvez você precise do Pylint.
Convenções de código! Já tive a oportunidade de escrever sobre elas no Profissionais TI. Benção ou maldição? Há quem goste, há quem ache uma perda de tempo…
O Google Chrome há muito já provou ser um fantástico navegador, me fazendo largar o Firefox já na sua primeira semana de lançamento (olha que eu ainda usava Windows).
E na mesma linha dos closures, eu passei a saber realmente o que são decorators depois de utilizar o framework Django. Se você está trabalhando com Orientação a Objetos e até agora não se deparou com este recurso, te garanto que um dia você precisará dele… afinal, é um dos Design Patterns mais bacanas (e úteis) que já vi.
No post anterior, conhecemos as ferramentas default para construção de testes automatizados em Django. Acontece que você pode “sair um pouco da caixa” e usufruir de ferramentas “third-party“, que enriquecerão o seu ambiente de desenvolvimento e lhe trarão maior segurança em seus testes de software.
