por Daniel Franke,(traduzido por Eduardo Bellani)

Para qualquer um que tenha habitado a internet por tempo suficiente para diferenciar ICANN de 4chan ou um netcat de um LOLcat, não vai ser novidade que hackers são com freqüência libertários. A razão é normalmente entendiada como algo assim: hackers, por definição, gostam de coisas esquisitas, como desmontar o tocador de DVD ou pesquisar como uma bomba nuclear funciona. Legisladores, que falham cronicamente em entender o porque alguém iria gostar dessas coisas ou porque que elas teriam valor pra alguém, passam leis que interferem com essas atividades. Justificadamente irados, hackers adotam visões políticas que se opõem a estas intrusões.

A mais clara exposição deste modelo talvez seja o artigo de 2004 do Paul Graham chamado "A palavra `hacker'". A idéia geral entretanto já está tacitamente entendida a muito mais tempo. Ela é a base para o tom de várias histórias do site Slashdot. Observações da correlação hacker-libertário é ainda mais antiga; não da pra ler USENET antiga por 10 minutos sem perceber-la.

A rescrição de Gordon ao corolário de Newman sobre a lei de Godwin observa "Libertarismo (pro, contra, e lutas entre as facções) é o tópico primordial de discussões do net.news. Qualquer hora que o debate muda para outro lugar, ele precisa eventualmente voltar a esta fonte de combustível" (Não sei quando isto foi escrito. Não foi entes de 1990 que a lei de Godwin foi criada, e não depois de 1994 que Godwin a citou).

Hackers tem uma longa história de conflitos com governo. Uma lista incompleta:

• 1986: O ``Computer Fraud and Abuse Act" passa no congresso americano, tornando pela primeira vez cracking um crime. Enquanto ele é direcionado principalmente a crimes não controversos, abuso legal por autoridades ignorantes por atos perfeitamente legais como port-scanning se torna rotina na década de 90.

• 1993: Philip Zimmerman é o alvo de uma investigação criminal depois que o PGP é sai dos Estados Unidos, em violação de restrições de exportação para criptografia (que era classificada como munição na época).

• 1996: O ``Communications Decency Act" restringe severamente material "obsceno ou indecente" na internet. Esta lei é negada pela Suprema Corte dos Estados Unidos no ano seguinte

• 1998: O ``Digital Millennium Copyright Act" passa, tornando crime qualquer tentativa de passar pelas medidas de segurança que tem como objetivo proteger material com copyright, independentemente da intenção do tentativa.

• 1999: Jon Johansen et. al. libera o DeCSS, decodificando a `encriptação' ridícula usado praticamente em todos os DVDs e tornando possível assistir DVDs usando software open-source. No ano seguinte, a casa de Johansen é invadida pela polícia Norueguesa.

• 1999: Amazon recebe a notória patente do 1-click.

• 2000: 72 pessoas na Califórnia recebem uma intimação proibindo-as de usar uma camiseta contendo o código de uma parte do DeCSS.

• 2001: Dimitry Sklyrov, um programador russo visitando os Estados Unidos, é preso pela lei DMCA e detido por vários meses por ter escrito um leitor de e-book capaz de ler vários formatos com DRM.

• 2002: Sarbanes-Oxley torna quase impossível para pequenas startups web fazerem abertura de ações

• 2003: A saga legal da SCO começa. SCO exige que todos os usuários Linux a paguem $700 dólares de licença.

• 2003: O FBI invoca abusivamente o USA PATRIOT ACT para recuperar notas de repórteres que entrevistaram Adrian Lamo.

• 2004: No que Brad Templeton descreve como `spamlitigação', o RIAA começa a processar seus clientes em massa, distribuindo mais de 20000 processos legais, incluindo crianças, avós e falecidos entre os acusados.

• 2005: FEC Commissioner Bradley Smith afirma que `a exceção da imprensa' do McCain-Feingold Campaign Finance Reform Act não inclui bloggers.

Entretanto, estes casos são insuficientes para explicar as atitudes dos hackers. A cultura hacker existe desde que as universidades tiveram acesso aos computadores - desde os anos 60 - e mesmo antes era reconhecida pela sua incarnação anterior dos operadores de rádio amador. Foi uma cultura libertária desde sua concepção. Mesmo assim, a lista começa em 1986. Antes do CFAA, era difícil apontar para qualquer intrusão que incomodasse os hackers em particular. Uso civil dos computadores não estava no radar do congresso e da polícia até então.

Para não fazer injustiça a tese de Graham, ela é muito mais abrangente que qualquer lista de reclamações. Graham observa corretamente que hackers tem suspeita de toda a autoridade, mesmo onde a teoria libertária diz que esta autoridade é legítima. Hackers ficam tão nervosos com o chefe que controla seu departamento fala para eles que "Eu acabo de ler numa revista sobre algo chamado virtualização. Nós deveríamos usar isso." quanto vão ficar com algum agente do governo. Por isso os hackers já se incomodavam bastante antes de 1986. O governo chegou tarde para essa festa.

Mas a obvervação que hackers são um grupo de espertinhos reclamações não explica o porque disto. Se as reclamações não se limitam a intersecção entre governo e tecnologia, porque esta atitude tem relação com escrever código?

A resposta de Graham a isto é a seguinte:

Deixe-me colocar isto em termos que um oficial do governo iria apreciar. As liberdades civis não são apenas um ornamento, ou uma velha tradição americana. Liberdades civis fazem os países enriquecerem. Se você fizer um gráfico de PIB per capita vs liberdades civis, você verá uma forte relação. Poderia tais liberdades serem a causa, ao invés da conseqüência da riqueza? Eu penso que sim. Eu penso que uma sociedade em que as pessoas podem dizer e fazer o que quiserem irá ser uma onde as soluções mais eficientes venceriam, ao invés daquelas que fossem patrocinadas pelas pessoas mais poderosas. Países autoritários se tornam corruptos, países corruptos se tornam pobres, e países pobres se tornam fracos. Parece que existe uma curva Laffer para o poder do governo, assim como para impostos. No mínimo, é provável o suficiente para não se tentar um experimento para testar a hipótese. Ao contrário de impostos, você não pode repelir o totalitarismo se ele não funcionar direito.

É por isso que os hackers se preocupam. O governo espionando as pessoas não faz com que o código que eles escrevem se torne pior. Ele apenas leva a um mundo onde as idéias ruins vencem. E por causa que isto é tão importante para os hackers, eles são especialmente sensíveis a isto. Eles podem sentir o autoritarismo se aproximando a distância, como animais podem sentir uma tempestade.

Eu acho que isto é uma falácia petitio principii. É uma visão libertária sobre o porque os hackers deveriam ser libertários. Se alguém concorda com a premissa que as liberdades civis fazem as pessoas enriquecerem, então tudo seque tranqüilamente. Mas se o governo autoritário "não faz com que o código que eles escrevem se torne pior", então porque hackers tem uma chance maior de fazer esta conexão?

Uma resposta tentadoramente lisonjeira para esta pergunta vêm do post de 1992 de Stuart Reges. Resumidamente, Reges afirma que existem uma certa habilidade mental - "QI libertário" - que nos faz melhores em formar modelos mentais de como programas funcionam assim como formular como a sociedade funciona. A primeira habilidade nos faz bons hackers. A segunda nos da um entendimento intuitivo de como o libertarismo funciona.

Apesar de cortês, eu acho que este argumento erra o ponto da discussão. Toda a teoria econômica que vem junto com o libertarismo é um efeito secundário. Libertarismo não é sobre o que nos faz ricos; é sobre o que é certo. ``We hold these truths to be self-evident'' e tudo mais. Libertários não se opões ao governo porque é atrapalhado e ineficiente, se opõe porque é maligno.

Além disso, acho que Reges nos dá muito crédito. O conhecimento médio dos hackers sobre a escola Austríaca ou a de Chicago é mais medíocre do que eles se permitiriam em qualquer assunto técnico. Comece a falar de externalidades ou o problema do parasita e nós mudaremos de assunto. Claro, os mais sofisticados irão citar o Teorema de Coase, mas a maioria nem ouviu falar dele.

Eu acho que nós estivemos olhando para o problema do ângulo errado. Não é que hackers adotam políticas libertárias, nem que existe um terceiro fator que influencia libertários e hackers. Ao invés disso, pessoas com uma atitude anti autoritária tendem a serem atraídos para programação.

A frase "conhecimento é poder" é um clichê, mas é também verdadeira num sentido bem literal. Aquilo que você não entende tem poder sobre você. As pessoas que não tem interesse em entender os computadores estão totalmente acostumadas a serem mandadas por eles; é mais um fato da vida. Se você não sabe que você pode mudar o bit de apenas-leitura ao clicar com o botão direito e editar o atributo na janela de propriedades, então não ter a permissão de editar o arquivo não é fundamentalmente diferente de não ser capaz de tocar um arquivo .wma cifrado porque a Microsoft fechou seu servidor de licença. Tentar fazer com que pessoas leigas se importem com DRM é inútil. Eles são sujeitos as tiranias de seus computadores todo o tempo. Porque esta seria pior?

Mas para aqueles de temperamento libertário, isso é um estado inaceitável. Ser mandado pelo governo já é ruim o suficiente. Mas ser mandado por um objeto inanimado? Intolerável. Como eu posso controlar essa coisa?

Este modelo da psiquê humana explica bastante nossas idiossincrasias de personalidade. Quando você não tolera ser ignorante sobre uma tecnologia, aprender sobre ela é a única saída. A outra é se tornar um ludita. Hackers se tornam luditas com freqüência.

Para exemplificar, eu tenho o mais barato celular do mercado. Ele não pode nem fazer o download de tons. Mas é ótimo para fazer chamadas. Porque é isso que eles tem que fazer. Eles não são feitos para mandar email. Nem para jogar tetris. Nem para tirar fotos. São feitos para fazer chamadas. É bastante chato ter que descobrir como tirar meu telefone do modo de câmera. Eu não quero descobrir como tirar meu telefone do modo de câmera, porque telefones não são feitos para tirar fotos. São feitos para fazer chamadas.

Algumas pessoas riem dessa atitude, mas é o mesmo sentimento que hackers tem quando reclamam de inchaço de software. Todos já escutamos, se já não tivermos participado, de conversas como:

``Eu não quero que meu editor de texto leia email! Eu quero um editor de texto!''

``Então use-o como um editor de texto.''

``Mas ai vou ficar com todo esse lixo espalhado no meu computador.''

``Por quê você não ignora isso? Não está nem exposto na interface gráfica. Você tem que saber o comando correto para ativá-lo. São menos de 80MB de espaço, e você tem 1TB no seu disco, e a maior parte não chega na RAM até que você a invoca.''

``Mas é nojento!''

Pode parecer forçado chamar a atitude dos odiadores do emacs de ludismo, e mais forçado ainda chamá-lo de libertária. Mas a psicologia é a mesma. Ninguém quer tirar o tempo para entender alguma coisa que eles consideram supérflua. Racionalmente ou não, hackers irão encontrar qualquer tecnologia que eles não entendem com suspeita - não de seus mérito, mas de sua segurança. "I eu quero isso ai ferrando com meu sistema", nós iremos dizer para você, mesmo sabendo perfeitamente bem que ele irá apenas sentar em um canto do disco rígido. Já recompilou seu kernel apenas para desabilitar um módulo que você não necessita? A maior pare de nós já o fez, mas isso desafia qualquer base racional.

Mas essa irracionalidade é comum. As atitudes libertárias geralmente ultrapassam os princípios libertários. Essencialmente todos os libertários defendem o direito de portar armas, mas consideram o direito a propriedade privada mais fundamental. Então, nós compreendemos o direito do de proprietários de proibir armas em sua propriedade. Mas isso não impede libertários de ficarem perturbados cada vez que um proprietário exerce esse direito.

Ficamos perturbados com os hoplofóbicos (medo de armas de fogo) pela mesma razão que arrancamos aquele módulo do kernel: odiamos e tememos sermos controlados.

Hey there. Let's assume you have some set like this

class User < ActiveRecord::Base
  has_one :profile , :dependent => :destroy
end


class Profile < ActiveRecord::Base
  belongs_to :user
  validates_presence_of :first_name, :last_name
end

And you create the profile in the same view as your user. How do you validate those first_name and last_name fields with a friendly message for your user?
Well, you could use validates_associated, but you would end up with a message like "Profile is invalid". Now, how friendly is that?

To obtain a more precise message, use this on you user.rb

def validate
  if self.profile
    self.profile.errors.each do |error|
      self.errors.add_to_base error.join(' ')
    end
  end
end

Hi Sirs.

There is a difference between a bunch of methods that appear that they to the same job, but they won't.

The methods instance_of?, is_a? and kind_of? do related jobs, but not the same job.

For example is_a? and kind_of? do the same job, they return true if the caller is an instance of the method argument, if the caller is an instance of every superclass in his inheritance tree or if the argument method is a module included in the caller.

The instance_of? is more specific, it returns true just if the caller is an instance of the method argument.

Let me show some examples:

module Hand
end

class Animal
end

class Mamal < Animal
  include Hand
end

class Dog < Mamal
end

dog = Dog.new

puts dog.instance_of?(Dog)    # true
puts dog.instance_of?(Mamal)  # false
puts dog.instance_of?(Animal) # false
puts dog.instance_of?(Hand)   # false

puts dog.is_a?(Dog)    # true
puts dog.is_a?(Mamal)  # true
puts dog.is_a?(Animal) # true
puts dog.is_a?(Hand)   # true 

Remember that is_a? and kind_of? do the same job.

See you.

Um pequeno tutorial em português pra diferenciar melhor respond_to? e respond_to. Não parece ter muita não? Mas o tio Chuck Norris vai me ajudar a esclarecer melhor isso aqui.

respond_to? é um método do Ruby Core como você pode ver, e não do Ruby On Rails, ele basicamente verifica se determinado objeto responde a um método, como o nome sugere mesmo.

Por exemplo:

class Chuck < Object
  def norris
    puts "the man"
  end
end
chuck_norris = Chuck.new
p chuck_norris.respond_to?("norris") # true
p chuck_norris.respond_to?("mr_t") # false

Já o respond_to, sem o ponto de interrogação (eles fazem parte do nome do método) faz parte do ActionController do Ruby On Rails. Ele coloca suporte a Web Service na sua aplicação, isso quer dizer que ele consegue resolver o tipo do recurso que você deseja.

respond_to do |format|
  format.html # render por default nome_da_acao.html.erb
  format.js # render o nome_da_acao.rjs
  format.xml { render :xml => @chuck.to_xml } # coloca o chuck pra xml e envia
end

Com esse código na action você poderia usar, por exemplo:

http://localhost:3000/nome_da_acao.html

http://localhost:3000/nome_da_acao.xml

Ou realizar uma chamada JS unobstrusive usando AJAX.

Isso ai, espero ter ajudado.

Hi Sirs,

Many tutorials over the web shows how to load data from fixtures. But, if you want to migrate your mysql data to a postgresql database?

We can export our data to fixtures, and after that we can load the fixtures to every database management system we wish.

Let's go to the rake task:

desc "export the database models to YML fixtures" 
task(:models_to_fixtures => :environment) do 
  ActiveRecord::Base.establish_connection(
    :adapter => 'postgresql', # mysql, sqlite3
    :encoding => 'utf8',
    :database => 'cnxs_development',
    :username => 'username',
    :password => 'secret'
  )
  ActiveRecord::Base.connection

  if ENV['MODELS'].nil? || ENV['MODELS'].blank?
    raise "Please enter valid models names separated by coma. Ex: MODELS=User,Account"
  end

  models = ENV['MODELS'].split(',').collect { |arg| arg.camelize.constantize }

  models.each do |model|
    output = {}
    collection = model.find(:all)
    collection.each do |object|
      output.store(object.to_param, object.attributes)
    end
    file_path = "#{RAILS_ROOT}/tmp/#{model.table_name}.yml" # /tmp/
    File.open(file_path, "w+") { |file| file.write(output.to_yaml) }
  end
end

Here you need to fill your database attributes like you do in the /config/database.yml.

You will call the command line:

$ rake models_to_fixtures MODELS=<your model names separated by coma>

For example:

$ rake models_to_fixtures MODELS=User,Post

All your model data will be stored on /tmp/ directory.

Download this rake task here.

See you.

Hi Sirs.

An important trick on the famous ActiveRecord::Base find method.

When you are in development time of your application, and you do some query on your database query editor, is a good practice to use the limit clauses and selects just the columns you want.

In the find method we can do it with the :limit and :select arguments.

For example in our code when we try to authenticate some user we got it like:

find(:first, :conditions => [query, hash], :select => "id, email, login")

The returned object contains just the id, email and login attributes. Clean object.

Password and other attributes do not appears in the returned object =]

Simple development practice, but very important too.

See you.

I've been reading a great paper by Daniel J. Bernstein, the creator of a qmail, and wow, what a pearl of wisdom. One of the most clarifying and straight to the point works on code security I have ever read. He (quite correctly) makes a parallel between the code security and the amount on exploitable bugs (EB), stating that it is the major problem on the code, regarding security. And then gives some answers to that problem, along with a couple of common distractions of the programmer while coding that helps those EB creep on our code base (CB). Let's review then, starting with the distractions, and I'll try to make some links with my favorite unambiguous tool of choice, Ruby.

1. Chasing attackers. The point here is give some thought to respond to tomorrow's attacks, and not being trapped by the anti-virus mentality of being only responsive to aggressors. Perhaps the dynamic nature of Ruby would help with that, but I think it is more a personal posture problem than anything else.
2. Minimizing privilege. Here, what is being said is that the old principle of least privilege is fundamentally wrong. How so? Well, it might (!) reduce the damage done by security holes, but never fixes these. Plus, IMO, it might even give users a false sense of security. Again, it is more of a way of a personal way of thinking (but what isn't? :P ).
3. Speed, speed, speed. Here I think rubists have some advantage. Since we work on a language that is 'slow', usually we tend to not place emphasis on premature optimization. I think this quote summarizes the thinking here:

   Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. —Knuth in [13, page 268]

Now, to the answers. These are also 3, and they are codependent connected to each other:

1. Eliminating bugs. I think everyone saw that one coming. But even so, Daniel's down to earth advices on it are a very worthwhile reading. I think I can summarize him on this section by saying (and that is a plus to rubists too), simplify stuff. Simplify interfaces, UI, parsing. Elegance is not a luxury, it is a way to obtain security. Following that logic we come to.
2. Eliminating code. Heck, here I'll quote his quote, and be done with it.

   To this very day, idiot software managers measure 'programmer productivity' in terms of 'lines of code produced,' whereas the notion of 'lines of code spent' is much more appropriate. —Dijkstra in [9, page EWD962–4]

   But as our systems grow, and our time and budgets remain the same or are diminished, and as programmers get more dumb, something has to give right? Wrong (don't know about the last part though).
3. Eliminating trusted code. That is somewhat more difficult I think, but it says that a program should do what it is meant to do, nothing more, and trust as few sources of data as possible. KISS and all that stuff.

I would love to hear any input on that. Until next time people.