act_as_newbie

Esse é o primeiro! Eu sei que demorou mas esse é o piloto e o piloto é sempre mais difícil!

Versão em flash:

Download do .mov original, qualidade melhor: jQuery, screencast 00 – Isso é só um piloto!!

Como não tem código funcional ainda nem vou postar nada, aguardem o episódio 01 que será bem melhor e mais completo que esse =)

PS: Por favor critiquem a vontade, eu sou muito novato nisso e preciso de idéias pra melhorar \o/

Bom, eu não vou ensinar o básico do básico do aqui, então eu vou começar isso partindo do princípio que você já saiba programar em JavaScript.

Javascript e a não-obtrusividade

Bom, eu não encontrei uma palavra adequada na nossa língua para traduzir o termo unobtrusive então eu traduzi livremente como não-obtrusivo.

Certamente se você (ou o designer da sua equipe) é preocupado com web standarts e coisas do tipo você não costuma misturar HTML, CSS e JavaScript, essa separação física garante apenas organização, a não-obtrusão vai um pouco além, e prega que essas 3 partes devem interagir mas não ser DEPENDENTES umas das outras (o html sendo a excessão, sem ele você não tem nada).

Por exemplo, se eu deletar meu css, eu continuo com um HTML funcional, que pode ser feio, ter a navegação difícil, mas funciona.

Sendo assim temos HTML definindo o que são os elementos da página, o CSS definindo como eles serão apresentados e o JavaScript como eles deverão se comportar

E essa é a chave: comportamento, é isso que devemos fazer com nossos arquivos.js adicionar comportamento às partes dos nossos sistemas que já são funcionais sem ele(lembra da independência?).

Devemos sempre lembrar uma coisa, JavaScript é uma melhoria e não uma funcionalidade segura. Devemos usar JavaScript apenas para melhorar funcionalidades que já existam na nossa aplicação, assim garantimos a operabilidade do nosso sistema mesmo sob condições desfavoráveis, como browsers de celular, por exemplo.

Resumindo:

• HTML O que são meus elementos? O que eu quero mostrar?
• CSS Como eu vou mostrar isso? Qual é minha estratégia de apresentação?
• JavaScript Como eu faço meus elementos, definidos no html e “vestidos” pelo css ganharem comportamento?

(Eu sei que eu falo muito, tente não se irritar, exemplos aparecerão em breve =) )

Ontem eu ouvi a pergunta: jQuery é muito melhor que Prototype? Bom, a resposta a essa pergunta é a mesma que você dá quando te perguntam, Java é melhor que C#? Depende!

Depende do que você quer, do que você precisa e do que você gosta.

Eu andei pesquisando alguns benchmarks para embasar esse post e pelo que eu pude ver o desempenho das duas frameworks é bem parecido, com uma pequena vantagem para o prototype. Então velocidade não é um fator de decisão aqui.

Outra coisa, se você precisa de funcionalidades extras. Como novos helpers para arrays, strings, numbers e etc. Fique com o prototype. O jquery não tanta funcionalidade assim.

Ok, o prototype é mais rápido e tem mais coisas, Rafael, então porque diabos jQuery? É simples, é uma preferência pessoal. Eu acho muito mais bonito se trabalhar com jQuery, acho que o código final fica muito mais limpo, elegante e fácil de entender. E pra matar a pau, jQuery, assim como Ruby, é divertido de se trabalhar. Por conta disso eu uso jQuery!

Essa pergunta sobre ser melhor ou pior me deixou com a pulga atrás da orelha, por isso que estou fazendo esse discurso todo, a partir daqui eu vou começar a postar uma série de tutoriais sobre como ser feliz usando jQuery, entretanto, a idéia aqui é apresentar um jeito de se fazer as coisas. Sem jamais negar que existam outros ou afirmar que este é o melhor de todos.

Vamos ao que interessa!

Bom, finalmente esse blog tá estável de novo. As turbulências foram por conta da troca de servidor. Eu saí da TeHospedo e tô num vps cedido gentilmente pela galera da Fireho. Um agradecimento especial ao Marcos Augusto que me deu uma grande força na transição.

Galera o Fábio Akita declarou iniciada a “tradução em comunidade” do livro Why’s (Poignant) Guide to Ruby que talvez não seja o melhor livro sobre ruby, mas com certeza é o mais divertido.

Para participar é só entrar na página do projeto no github e fazer um fork.

Ah sim, cadastre-se no grupo” para ter acesso a planilha de tradutores, acrescente seu nomezinho lá antes de começar a traduzir pra evitar que duas pessoas traduzam o mesmo capítulos (são 86, tem pra todo mundo).

Depois que você traduziu um (ou mais) capítulos, é só mandar um pull request pro Carlos Brando que assim que ele ver ele junta seu código lá.

Se você já viu algum screencast sobre rails feito em um mac (quase todos eles) viu o output do script/server todo colorido.

Se vc tentar no windows a maravilha que vai ser apresentada a você é assim: (as imagens se foram na mudança) Não é bonito né? Mas ele pode ficar um pouco melhor, não passa nem perto de um terminal de mac com anti-aliasing ligado, mas é melhor que essa loucura que mal dá pra entender.

Você vai precisar da gem win32console

gem install win32console

Depois basta acrescentar isso ao environment.rb

begin
  require 'Win32/Console/ANSI' if PLATFORM =~ /win32/
rescue LoadError
  raise 'Você precisa da gem win32console para usar cor no windows!'
end

Olha como fica melhor: (as imagens se foram na mudança)

Bom, a minha idéia inicial era publicar isso aqui em inglês (e com as 5 dicas necessárias) pra participar do concurso da RailsCasts, mas eu acabei me enrolando com outras coisas e não consegui postar a tempo. Sendo assim eu vou postar as 3 dicas que eu já tinha escrito, assim o trabalho não será perdido =)

#1 – respond_to com jQuery

Eu apesar de não desgostar do Prototype, sou fã do jQuery e sempre que posso uso ele nos meus projetos. Como o suporte no Rails ainda é ao prototype você perde algumas funcionalidades quando troca de biblioteca. Existe um plugin chamado jRails que faz a substituição da framework usada nos helpers de javascript. Pra quem quer usa eles, é a melhor alternativa, mas talvez você não precise de todos eles, ou como no meu caso precise apenas que o respont_to funcione e a solução é muito mais simples do que parece.

No final do application.js insira

jQuery.ajaxSetup({ 
  'beforeSend': function(xhr) {
      xhr.setRequestHeader("Accept", "text/javascript")
  } 
})

#2 – Foreign Key Migrations

Esse plugin da RedHillsOnRails cria as constraints de foreign keys no banco de dados a partir das migrations, nada mais de execução direta de sql. Para instalar:

ruby script/plugin install http://redhillonrails.rubyforge.org/svn/trunk/vendor/plugins/redhillonrails_core
ruby script/plugin install http://redhillonrails.rubyforge.org/svn/trunk/vendor/plugins/foreign_key_migrations

A partir daí ele vai criar as constraints sozinho, se você quiser um controle mais fino, o site deles é recheado de exemplos.

#3 – UTF-8 mysql vs. postgresql

Essa aqui é bem simples e específica. O encoding utf-8 tem nomes diferentes para os dois bancos de dados.

No database.yml

#mysql
  encoding: utf8
#postgresql
  encoding: UTF-8

Eu sou do mundo PHP, onde encontrar sistemas que mantém nossas senhas abertas ao mundo no banco de dados é quase lugar comum. Quando algum programador um pouquinho mais ajuizado passava pela equipe as vezes eu encontrava um md5(‘senha’); no meio do caminho. Isso melhorava a situação, mas ainda deixava muito a desejar. Em rails o pessoal costuma usar SHA1, que apesar de mais avançado que md5, possui uma vulnerabilidade comum a todos os sistemas de criptografica simples: as Rainbow Tables.

[Quem quiser saber o que são e como funcionam as rainbow tables, eu aconselho uma olhadinha na wikipedia , e nesse blog .]

Existe uma forma bem simples de se contornar isso. E ela não é nada nova, segundo esse especialista essa implementação existe dentro do Unix desde 1976!

Qual é a grande sacada?
A idéia é adicionar uma string aleatória à senha antes de criptografá-la e salvá-la no banco de dados. Essa string costuma ser chamada de ‘salt’ (sal, em português) e apesar de não impossibilitar completamente o uso das rainbow tables, torna-o difícil o suficiente para garantir seu sono.

“Salgando” models
Eu retirei o código a seguir do livro do DHH que eu citei antes, foi o exemplo mais simples e fácil de entender que eu achei.

Criando o salt

def create_new_salt
    self.salt = self.object_id.to_s + rand.to_s
end

Nesse exemplo usamos o id do objeto mais uma string aleatória para gerar o nosso sal. Qualquer coisa vale aqui. Com o salt em mãos, basta criptografar a senha usando ele e salvar ambos (a senha criptografada e o salt limpo) no banco.

Para retornar a senha utilize

def self.encrypted_password(password, salt)
    string_to_hash = password + "wibble" + salt # 'wibble makes it harder to guess
    Digest::SHA1.hexdigest(string_to_hash)
end

Aquele “wibble” ali no meio também pode ser qualquer coisa, ele aumenta “um pouquinho” a dificuldade de um ataque ser bem sucedido.

Essa solução é extremamente simples, tanto que ela é apresentada em um dos livros mais “hands-on” de rails que existem, mesmo assim eu ainda sou surpreendido todos os dias ao saber que “sistema X ou Y” ainda usa md5 puro para criptografia, isso quando usam alguma coisa.

Vamos cuidar mais da segurança dos nossos usuários ;)

Olá cidadão, seja bem vindo! O intuito desse blog é compartilhar o conhecimento que eu for adquirindo conforme me aventuro no mundo rails. Não tem muito além disso. Let the games begin...