Hoje apresentei minha palestra “Porque você não deve usar os callbacks do ActiveRecord”, na trilha de Ruby do TDC 2012.
Resolvi testar o SpeakerDeck e coloquei os slides lá. Sempre achei a interface do Slideshare muito poluída, mas não estou conseguindo colocar os slides aqui no blog, então vai na base do link mesmo :)
Infelizmente a palestra não foi filmada. Vou tentar apresentar novamente em algum evento do GuruSP ou outro evento, vamos ver…
Obrigado a todo mundo que esteve presente!
https://speakerdeck.com/u/cassiomarques/p/porque-voce-nao-deve-usar-os-callbacks-do-activerecord
Há dois anos atrás eu escrevi um post sobre o uso de objetos como argumento para filtros nos controllers do Rails. Acontece que de lá pra cá eu me vi repetindo o mesmo código em vários projetos, de forma totalmente burra. Hoje eu estava à toa em casa e após reescrever pela trocentésima vez o mesmo código base para usar filtros dessa forma, resolvi criar uma gem.
Ok, fui burro e poderia ter feito isso antes. A questão (eu acho) é que o código é realmente muito simples e idiota. Mas pensando bem aqui ainda assim faz sentido usar uma gem ao invés de ficar criando tudo novamente :)
Eu só testei com Ruby 1.9.3 e Rails 3.2, mas não uso nada de muito diferente então acho que deve funcionar sem grandes problemas em outras versões.
Nos dias 19 e 26 de Novembro, 03 e 10 de Dezembro vou ministrar um curso sobre Imersão JavaScript pela e-Genial. O curso ocorrerá em 4 sábados, com 3 horas de aula por dia, totalizando 12 horas de curso.
Mais detalhes sobre a grade e preços podem ser vistos em http://www.egenial.pro/pt/javascript.
JavaScript é uma das linguagens do momento. Presente em praticamente qualquer aplicação web e sendo também cada vez mais usada no servidor, saber JavaScript já se tornou requisito obrigatório para qualquer desenvolvedor. O problema é que ainda hoje muitas pessoas usam JavaScript como uma “linguagem de brinquedo”, sem realmente conhecer todos os detalhes da linguagem e como a mesma realmente funciona. A idéia do curso Imersão JavaScript é resolver esse problema.
Provavelmente você já escreveu código JavaScript que apresentava um ou mais dos seguintes problemas:
– Funções muito longas e dificeis de entender
– Variáveis globais que mudavam de valor em momentos inesperados e introduziam bugs
– Código JavaScript inline nos seus elementos HTML
– Código procedural, com muitas funções bagunçando o escopo global
– Falta de organização
JavaScript não é uma linguagem perfeita. Diversos problemas em sua implementação criam riscos para o código escrito, como efeitos inesperados, problemas de manutenção, entre outros. Porém, é possível criar aplicações organizadas e com código seguro seguindo-se alguns padrões e evitando-se as características ruins da linguagem, usando somente a parte boa. Neste curso vamos aprender diversos recursos do JavaScript, tais como:
– Conceitos básicos da linguagem
– Como o JavaScript implementa orientação a objetos
– Programação funcional com JavaScript
– Tratamentos de exceções
– Metaprogramação
– Design Patterns
– e muito mais!
O curso tem como público alvo desenvolvedores e estudantes com ou sem experiência em JavaScript que queiram aprender como escrever código JavaScript seguro, organizado e fácil de manter, além de entender como são implementados alguns conceitos dos frameworks JavaScript utilizados atualmente.
Para participar do curso é necessário que você já tenha experiência em pelo menos uma linguagem de programação. Já ter alguma experiência prévia especificamente com JavaScript é desejável, mas não é um requisito obrigatório. Caso você não conheça a linguagem essa será uma excelente oportunidade para aprender!
Vejo vocês nas aulas!
UPDATE:Já estou trabalhando na :)
Estamos mudando algumas coisas na estrutura da DailyDigital e vou passar a trabalhar menos horas por dia no projeto. Como resultado passei a ter mais horas livres para desenvolver outros coisas. Inicialmente acredito que terei cerca de 6 horas diárias para dedicar a esses trabalhos, mas dependendo do projeto posso trabalhas em tempo integral.
Se você tem algum projeto bacana usando Ruby, Rails, JavaScript, BDD, etc, entre em contato! Meu email é cassiommc arroba gmail ponto com.
Obrigado!
Sempre usei esse blog para falar sobre desenvolvimento de software, mas como é um dos melhores canais de comunicação que possuo, vou utilizá-lo para me manifestar quanto aos imensos transtornos que o Banco Santander vem me causando. Peço desculpas a todo mundo que lê o blog e garanto que isso não se tornará algo frequente. Esse continuará sempre sendo um blog sobre programação de computadores.
Há 4 meses venho tendo problemas com o Banco Santander. Sou cliente deles desde 2003, mas infelizmente chegou em um ponto que não dá mais para manter. Por trabalhar para uma empresa americana, preciso realizar uma operação de câmbio a cada 15 dias, período no qual recebo as remunerações pelo meu trabalho. Desde a primeira vez esse processo se mostrou extremamento complexo e desorganizado. É necessário levar o contrato que eu tenho com a empresa, tive que levar minha declaração de imposto de renda, preencher trocentos papéis, perder dia de trabalho, perder horas e mais horas dentro da agência… E cada vez que recebo dinheiro dessa forma eles cobram uma taxa de R$ 90,00.
Para que esse processo funcione, é necessário que seja feito um cadastro, indicando que eu estou apto a receber dinheiro do exterior (e que não sou um laranja servindo para lavar dinheiro ilícito, etc). Até ai tudo bem. Mas, como as coisas funcionam super bem, fizeram meu cadastro de forma errada e não conseguem corrigir. Resultado? A cada 15 dias preciso voltar ao banco, levar novamente o meu contrato, que é enviado por FAX (2011, alguém?!) e preencher um papel que eu preciso assinar na agência. O processo todo, desde quando o dinheiro é enviado dos EUA até que eu consiga tê-lo em minha conta leva cerca de 6 dias. Absurdo, pra dizer o mínimo, pois mesmo o dinheiro já estando liberado na central de câmbio do Santander, ainda preciso esperar 3 dias para que o mesmo caia na minha conta.
O cúmulo do absurdo aconteceu agora, no pagamento que eu deveria ter recebido até o dia 15. No dia 13/07 fui até a agência assinar novamente o boleto de câmbio e levar meu contrato para ser enviado por FAX para a central. Com isso, acreditava que até o dia 15 estaria com o dinheiro. Até ontem, dia 18, nada do dinheiro. Liguei novamente, falei com a gerência da minha conta, na agência da cidade de Caieiras-SP (agência n° 0821) e apesar da boa vontade de quem está me atendendo, nada foi feito. O Santander possui uma organização estúpida, onde um gerente e nada é a mesma coisa, pois eles não possuem alçada nenhuma para resolver os problemas, tendo que enviar EMAILS e aguardar que a central de câmbio resolva.
Sabem o que aconteceu? Ontem à noite, 18/07, o SANTANDER COBROU A TAXA DE R$ 90,00 PELA OPERAÇÃO DE CÂMBIO, *ANTES* DO VALOR SER CREDITADO NA MINHA CONTA. Esse foi o cúmulo do absurdo. Já se passaram 6 dias desde que fui ao banco assinar o boleto de câmbio, tenho contas que venceram e das quais terei que pagar multas, etc. Quem arca com isso? E meus planos? E meu orçamento? Santander, vocês são um lixo. Possuem um slogan “Vamos fazer juntos?”, que com certeza significa “fazer piada”. Aliás, “juntos” deve ser vocês e meu dinheiro, que está sendo investido para vocês lucrarem, ao invés de devidamente depositado em minha conta. Fica aqui minha tremenda insatisfação com o serviço prestado por vocês. Vocês não merecem me ter em seu banco, pois não respeitam seus clientes. Santander nunca mais.
No último dia 11 de junho ocorreu o 16º encontro do Guru-SP, onde fiz uma rápida palestra sobre a gem VCR. Seguem o vídeo e os slides da apresentação.
Agradeço ao Lucas Catón por ter filmado e feito a edição. Valeu Lucas!
Há um ano e meio atrás topei aceitar um convite para trabalhar com a equipe da Surgeworks. Aceitei imediatamente, era um chance muito boa de aprender coisas novas e trabalhar com uma equipe de pessoas experientes. Eu só tinha a ganhar. Antes disso, tinha passado 3 anos trabalhando sozinho. Sentia falta de trabalho em equipe.
Eu não deixei de trabalhar nos meus outros projetos durante esse tempo. Continuei desenvolvendo soluções para o Serviço de Hemoterapia de São José dos Campos, dividindo meu tempo diário entre esses dois clientes. No começo tudo ia bem, afinal eu gosto muito de programar e os projetos eram divertidos. O problema veio com o passar dos meses. Fui ficando cada vez mais cansado, mas não fisicamente, mentalmente. O corpo se acostuma rápido com essas coisas, acordar 07:30h e ir dormir 01:30h rapidamente se torna algo natural. Mas a cabeça, pelo menos a minha, começa a sentir. Nos últimos meses fiquei esgotado. Problemas que sei que sou capaz de resolver rapidamente levavam horas. A criatividade foi diminuindo. E eu, muito idiota, continuava trabalhando feito doido. Muitas vezes aos fins de semana.
Durante esse período muitas propostas de trabalho me foram feitas, e agradeço por todo o interesse que as pessoas e empresas demonstraram por mim. Acabei recusando todas elas, por estar muito envolvido nos projetos e ter diversas expectativas com os mesmos.
Essa semana recebi uma proposta interessante, de uma pequena empresa americana chamada Daily Digital. O projeto me pareceu interessante e eu teria a oportunidade de trabalhar em um único projeto, me focar de verdade e fazê-lo evoluir. Nos outros clientes, eu vinha mantendo 5 projetos diferentes, todos de grandes dimensões. Isso, somado ao meu total cansaço mental, me fizeram repensar o que eu estava fazendo com a minha vida. No fim escolhi mudar. Não foi uma decisão fácil, definitivamente.
Gostaria de deixar aqui registrado o meu mais sincero carinho e respeito por todas as pessoas com quem trabalhei no Serviço de Hemoterapia de São José dos Campos e na Taoweb/Surgeworks. Aprendi muito durante todos esses anos, fiz amigos e me diverti.
Agora é a hora de colocar as coisas no lugar por aqui e seguir nessa nova empreitada!
O Rspec2 fornece um novo tipo de spec group chamado requests. Esses testes ficam em spec/requests e são uma boa opção para escrever testes de integração. Comecei a usar por aqui e tem me ajudado bastante em casos onde usar o Cucumber seria overkill.
Em um projeto atual um dos meus controllers usa HTTP Basic Authentication. Esse controller serve apenas como endpoint de uma API que a aplicação fornece e nunca será acessado via browser. Como a API será consumida apenas por um único cliente, dentro de uma rede conhecida, acho que HTTP Basic Auth está de bom tamanho neste caso. O problema foi pra descobrir como testar isso. Para os testes de controller costuma ser fácil, basta fazer algo como:
describe FoosController, "handling PUT /foos/123/save" do
it "is successful with correct username and password" do
request.env["HTTP_AUTHORIZATION"] = ActionController::HttpAuthentication::Basic.encode_credentials('some_username', "some_password")
put :save, {:some => parameter}
response.should be_success
end
end
O problema é que nas request specs não temos acesso direto ao request. Tentar fazer o que mostrei acima não funciona, pois request é nil. A solução foi usar Rack::Test diretamente na minha spec. Primeiro, fiz a inclusão dos métodos do Rack::Test nas minhas request specs. No spec_helper.rb:
require 'rack/test' Rspec.configure do |config| config.include Rack::Test::Methods, :type => :request end
E no meu teste, bastou usar o método authorize do Rack::Test para enviar as credenciais para autenticação:
describe "my API endpoint" do
let(:username) { 'valid_username' }
let(:password) { 'valid_password' }
it "should work with valid auth credentials" do
authorize(username, password)
put "/my/path/123/save", {:some => parameter}
response.status.should == 200
end
end
Esta é uma pergunta frequente:
– Devo testar meus métodos privados?
E minha resposta é sempre a mesma:
– Não.
Aliás, essa é a resposta que muitas pessoas darão à pergunta acima. Mas porque raios não é uma boa idéia testar métodos privados?
Considere o fluxo básico do TDD:
- Escreva um caso de teste
- Assista o teste falhar (ok, eu raramente sigo esta etapa, vou direto prá próxima)
- Escreva o código mais simples possível capaz de fazer o teste passar.
- Refatore, se for o caso.
- Repita para novos casos de teste, até que sua mente cruel não seja capaz de criar novas formas de sacanear seu código.
Definir métodos como privados é algo que faz parte do processo de refatoração. Um método não deve nascer como privado pura e simplesmente. Na maioria das vezes, se você começa a escrever a implementação que faz um teste passar definindo métodos como privados, você está pensando demais. Ou seja, está se concentrando em detalhes de implementação e deixando o comportamento em segundo plano. Lembre-se: você deve inicialmente escrever o código mais simples possível capaz de fazer o teste passar. Ou seja, não esquente a cabeça em escrever o código mais elegante do mundo logo de cara. Escreva algo simples e até mesmo feio, mas que você seja capaz de compreender e que faça o teste passar, ou melhor, que implemente o comportamento esperado. Após isso feito, identifique pontos de possível refatoração. Geralmente, extrair métodos a partir de trechos de código repetidos leva à criação de métodos privados.
Outro efeito negativo de se testar métodos privados é que os mesmos estão frequentemente sujeitos a mudarem ou até mesmo desaparecem. Conforme seu código evolui e mais refatorações são realizadas, muitos métodos privados podem não fazer mais sentido, o que fará com que você tenha um monte de testes quebrados, inúteis e que não refletem a realidade.
Por fim, lembre-se que além de testar o comportamento do seu código, testes unitários podem ser utilizados como documentação executável. Assim como ocorre com a documentação escrita através de comentários especiais no código (como feito com o Rdoc, Javadoc, etc), você não deve exportar documentação que contenha métodos privados, pois os mesmos são detalhes de implementação e não devem ser acessados diretamente. Infelizmente muitos programadores não são suficientemente educados e, se você mostrá-los como, eles vão invadir as entranhas de seus objetos e usar coisas como my_object.send(:some_private_method). Além disso, incluir métodos privados na documentação só faz com que a mesma seja mais bagunçada e difícil de consultar.
No fim das contas, seus métodos privados estarão sendo testados, mas indiretamente. Eles não são o objetivo final, mas sim apenas um meio, uma etapa na execução do método sendo testado. Este última sim é importante, pois provavelmente faz parte da API pública do seu objeto.
No dia 26 de fevereiro de 2011 irei palestrar no Ruby Masters Conf.
O Ruby Masters Conf será uma maratona de palestras on-line que será realizada nos dias 25 e 26 de fevereiro de 2011 e que contará com grandes nomes da comunidade Ruby e Rails internacional e Brasileira. O evento tem por objetivo compartilhar o conhecimento e ainda arrecadar fundos para projetos opensource. Serão 12 palestras on-line ao vivo em dois dias, usando um ambiente de eventos multimídia onde os palestrantes vão compartilhar seus temas através de recursos de áudio, vídeo, slides e chat.
A idéia é doar toda a renda arrecadada com as inscrições para projetos opensource, ajudando assim os desenvolvedores a continuarem trabalhando em projetos que facilitam nossa vida diariamente. O legal é além de poder assistir no dia, quem participar ainda poderá fazer download das gravações e assim posteriormente.
As doações podem ser feitas em três valores diferentes: R$ 35,00/45,00/55,00. Qualquer um deste valores já dá direito a assistir o evento integralmente. Mas se você está se sentindo generoso e acha que o trabalho em projetos como o RubyInstaller e o Passengermerecem todo o seu apoio, doe o valor máximo!
Me senti extremamente honrado por ter sido convidado a participar deste evento e palestrar junto com profissionais tão relevantes.
Minha palestra: Analisando Complexidade de Código Ruby
A idéia é falar um pouco sobre os tipos de complexidade/smells do código (complexidade clicomática, métricas ABC, duplicação, smells conhecidos, etc, etc). Falar sobre ferramentas para identificar essas coisas no código (basicamente o metric_fu, mas explicando em maiores detalhes as técnicas empregadas em cada uma das gems que o compõe), além de abordar também algumas técnicas para eliminar os problemas encontrados.
Você também pode ajudar a divulgar o evento colocando em seu site/blog um banner.
Abraço e até o evento!
Cássio Marques 