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!

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!

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.

Agradeço ao Lucas Catón por ter filmado e feito a edição. Valeu Lucas!

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!

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

- 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:

1. Escreva um caso de teste
2. Assista o teste falhar (ok, eu raramente sigo esta etapa, vou direto prá próxima)
3. Escreva o código mais simples possível capaz de fazer o teste passar.
4. Refatore, se for o caso.
5. 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.

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!

Máquinas / Sistemas Operacionais

Uso um MacBook Pro 13″ como minha máquina principal para desenvolver. Tenho outro notebook com Ubuntu que no momento está fora de combate, com o HD danificado. Quando estou com ambas as máquinas funcionando uso o Sinergy para compartilhar teclado e mouse entre as duas máquinas, funciona muito bem. Quando estou em casa mantenho o Mac ligado o tempo todo a um monitor externo de 22″, deixando no monitor do Mac somente um terminal aberto com algum log que precise acompanhar ou coisas do tipo.

Terminal

Inicia automaticamente quando ligo a máquina. Tentei usar o zsh mas acabei voltando pro bash. Talvez tenha sido falta de paciência para configurar melhor as coisas e parar para aprender de verdade. Ou não. :)

Mantenho sempre pelo menos 3 abas abertas. Se estou trabalhando em um projeto Rails, por exemplo, mantenho uma aba só para os logs, outra rodando uma sessão do tmux dividida ao meio, um lado para rake tasks, rodar testes, etc, e o outro lado com o console do Rails. A terceira aba deixo para uso geral, independente do projeto. Às vezes posso ter mais uma outra aba aberta conectada a algum servidor via ssh. E como citado acima, às vezes mantenho outra janela do terminal aberta no monitor do notebook.

Editor

Passo 100% do tempo com o MacVim aberto. Já era usuário do Vim antes de usar Mac e comecei a usar bem antes da nova moda :) Não cheguei a usar TextMate porque quando usava Linux já me virava bem com o Vim e não vi porque aprender outro editor quando fui pro Mac. Tenho estudado Objective-C e estou tentando usar o XCode só para interagir com o projeto e criar as telas, mas tento editar o código sempre pelo Vim também. Sempre que tento usar outro editor, digito como se estivesse no Vim e só faço besteira. Esse foi um dos motivos que me fez usar o Eclim para desenvolver em Java, quando preciso, o que tem sido raro.
Tenho usado o PeepOpen para abrir arquivos no MacVim e tem sido legal. Mas em aplicações Rails ainda prefiro bem mais usar os atalhos do Rails.vim.

Browser

Mantenho o Chrome 100% do tempo aberto e uso como browser principal enquanto estou desenvolvendo. Só abro outros browsers para testar o resultado final das coisas (e fecho o mais rápido possível). Preciso me educar melhor e tentar manter menos abas abertas ao mesmo tempo, mas quando tenho 20 abas abertas, considero que estou me controlando :)

Outros softwares

• Tunnelblick: Cliente opensource para VPNs que usem o OpenVPN. Preciso estar conectado o dia todo à rede de um dos meus clientes e esse programinha funciona perfeitamente bem.
• Adium e Skype: Indispensáveis para quem trabalha remotamente como eu e precisa fazer reuniões com a equipe, falar com os clientes, etc
• iTunes: Aberto 100% do tempo.
• Git: Porque eu versiono tudo que posso, não só projetos mas também documentos pessoais

Música

Ouço música 100% do tempo quando estou trabalhando. Além de ser viciado (quem não gosta de música é louco), por trabalhar em casa e ter N distrações que podem me atrapalhar, a música ajuda a me manter concentrado e manter o foco.

É isso. Acho que meu ambiente é bastante simples, nada que fuja do normal acredito eu. Passo a bola agora pro @jtadeulopes, pro @thiagopradi e pro @qmx.

Imagine o seguinte controller:

class FoosController < ApplicationController
  before_filter :do_something_complex

  protected
  def do_something_complex
    # dezenas de linhas ...
  end
end

Esse é o esquema padrão de escrever filtros em Rails. Mas pode ficar ainda pior…

class FoosController < ApplicationController
  before_filter :do_something_complex

  protected
  def do_something_complex
    check_whatever
    destroy_the_world
  end

  def check_whatever
    # dezenas de linhas ....
  end

  def destroy_the_world
    # dezenas de linhas...
  end
end

Haja código bagunçando nosso controller!

Filtros como objetos

O Rails permite o uso de classes como filtros, para tirar a lógica do controller. Algo mais ou menos assim:

class FoosController < ApplicationController
  before_filter MyAwesomeFilter  # continua aceitando as opções :only e :exclude
end

class MyAwesomeFilter
  def self.filter(controller)
    # ...
  end
end

Já é melhor do que entupir nosso controller com código que não deveria estar ali, mas ainda não é o ideal, visto que usa métodos de classe, transformando nosso filtro em nada mais do que um namespace para funções procedurais. O fato é que o before_filter aceita qualquer objeto que responda ao método filter(controller) (lembre-se que em Ruby uma classe é também um objeto!). Podemos melhorar o design fazendo algo como:

class FoosController < ApplicationController
  before_filter MyAwesomeFilter.new 
end

class MyAwesomeFilter
  def filter(controller)
    # sua lógica, mas seja bacana e refatore!
  end
end

Bem melhor! Mas ainda temos um problema. Nosso filtro é uma classe comum e não possui acesso direto à nada disponível dentro do nosso controller, pois o escopo aqui é outro. A prática comum é usar a instância do controller que o método filter recebe:

class MyAwesomeFilter
  def filter(controller)
    SomeObject.run controller.params[:foobar]  
    controller.flash[:notice] = "Some message"
    controller.redirect_to some_path
  end
end

Estamos delegando um monte de chamadas para o nosso controller, mas acho que não é necessário escrever controller tantas vezes. Vamos delegar da maneira Ruby:

require 'forwardable'
class MyAwesomeFilter
  extend Forwardable

  def_delegators :@controller, :redirect_to, :render, :params, :flash # .. e qualquer outro método que você queira 

  def filter(controller)
    @controller = controller
    flash[:notice] = "Some message"
    redirect_to some_path
  end
end

Com o module Forwardable podemos declarar quais chamadas serão delegadas e para quem. Ele é nativo do Ruby, dê uma olhada na documentação.

Mas e se formos criar outros filtros? Vamos ter que declarar os delegators novamente? Não!

require 'forwardable'
class MyBaseFilter
  extend Forwardable

  def_delegators :@controller, :redirect_to, :render, :params, :flash

  def filter(controller)
    @controller = controller
  end
end

class MyAwesomeFilter < MyBaseFilter
  def filter(controller)
    super(controller)

    # sua lógica de filtro
  end
end

Com essa estratégia, você pode criar outros delegators usados somente em um filtro específico. Esses delegators serão somados aos já declarados na classe base:

class MyAwesomeFilter < MyBaseFilter
  def_delegators :@controller, :foo, :bar
end

Onde salvar esses arquivos com os filtros? Eu gosto de criar uma pasta em app/controllers/filters e colocar os filtros ali. Para facilitar as coisas, adicione essa nova pasta ao autoload do Rails:

module YourApp
  class Application < Rails::Application
    config.autoload_paths << "#{Rails.root}/app/controllers/filters"
  end
end

Espero que com isso você possa organizar um pouco melhor seus controllers, além de poder testar melhor os filtros.