Scala, Traversable, e Implicits

Meu primeiro post bem técnico sobre Scala, vamos ver no que dá (rs).

Bom, primeiro, um pouco de “background”: comecei o fantástico curso de Machine Learning no site coursera.org, e todas as lições que estão no site são em Octave/Matlab. Não conhecia Octave, muito menos Matlab, e quando programei nestas linguagens descobri algumas coisas meio estranhas (bom, eu pelo menos considero estranho que, ao esquecer de colocar um “;” no final de um comando, ele imprima o resultado na tela), além, claro, de não ser possível programar pra Android, por exemplo.

Como estou estudando Scala, e como já consegui fazer Scala rodar no Android de um jeito menos “doloroso” (mais sobre isso em outro post), resolvi fazer os códigos em Scala. Há bibliotecas boas de multiplicação de matrizes em Scala, porém comparadas com as versões Java, elas são BEM mais lentas. Foi aí que pensei: por que não encapsular uma dessas bibliotecas Java em Scala?

Tudo correu bem, até o momento que resolvi que queria que cada matriz funcionasse como um Traversable. Para quem é de Ruby, o Traversable é equivalente ao Enumerable, com algumas coisas a menos e outras a mais. Só para comparar, vamos ver o código dos dois (para simplificar, vou omitir alguns códigos, mas a API é a seguinte: Matrix#rows e Matrix#cols para saber o número de linhas e colunas, Matrix#* multiplica matrizes ou uma matriz com um número. Também, a matriz possui um atributo, “list”, que contém um array de arrays com os elementos internos da matriz).

class Matrix(list: List[List[Double]]) extends Traversable[Double] {
  def cols = 3 //Só pro nossos códigos de exemplo compilarem...
  def foreach[B](function: Double => B) = list.flatten.foreach { e => function(e) }
}
class Matrix
  include Enumerable
  def each(&b)
    list.flatten.each &b
  end
end

Repare que o código é semelhante nas duas linguagens, a diferença básica é que em Ruby não precisamos definir tipos, em Scala precisamos (não que nesse caso faça alguma diferença). Só que temos um caso engraçado tanto em Ruby como em Scala: se queremos um método que, digamos, eleve todos os elementos ao quadrado, elemento por elemento, ao usar “map” para fazer esse processo, ele vai nos retornar, em Ruby, um Array, e em Scala, um Traversable[Double]. E pior, os elementos vão ficar “achatados”. Em ambos, é possível resolver isso fazendo o “each” (ou o “foreach”) retornar uma lista de elementos que está em cada linha, mas ainda assim temos o problema que nosso retorno será semelhante a um “array de arrays”, não uma matriz. O que fazer?

Bom, em Ruby, a gente se ferrou, literalmente. Não temos uma maneira de fazer isso que não envolva sobrescrever o map, e todos os métodos que constrõem uma lista a partir de outra. Em Scala, temos “implicits”, e um conceito “canBuildFrom”.
(more…)

Extraindo o Máximo do Android

Bom, estes dias comprei um Android, um Samsung Galaxy S2, e como todo bom usuário de Linux, já fiz algumas modificações no sistema. A coisa que achei mais diferente é a dificuldade de achar informações sobre como fazer as alterações, tal como “root” ou instalações de ROMs customizadas. Então, resolvi postar aqui como fazer estas alterações.

Em primeiro lugar, vale mencionar algumas coisas sobre o Android. Como todo Linux, ele possui um “kernel” separado do sistema. Além disso, o Android é dividido em um sistema base que fica montado em “/system”, e uma área para os dados dos aplicativos (possível de ser escrita pelo usuário) montado em “/sdcard”. No meu caso, ainda, ele possui um cartão SD externo, que fica montado em “/sdcard/external_sd”. Além disso há uma sopa de letras tipo “FactoryFS”, “Modem”, “Secondary Kernel” e outras coisas que eu entendo só por cima.

Para adquirir acesso “root”, há várias formas diferentes. Uma delas consiste em instalar um kernel diferente, mas aí você ganha um triângulo amarelo no seu celular quando você vai iniciá-lo, então todo mundo fica sabendo que você fez uma modificação. A outra, consiste em instalar um sistema de arquivos diferente. Basicamente o processo é fazer um “flash” no celular, com um kernel modificado (no primeiro caso) ou com um sistema modificado (no segundo). Para o Linux, uso o software “heimdall” (http://www.glassechidna.com.au/products/heimdall/). A versão 1.3.2 me deu problemas, então instalei a 1.3.1 e passei ao processo de flash. Eu recomendo o segundo método, pois o triângulo amarelo não fica presente, e basicamente consiste em baixar esta imagem: http://brasildroid.com.br/galaxy-s-ii-i9100-geral/6187-tutorial-root-ics-firmware-claro-tim-vivo-and-unbranded-oi.html. Depois, basta descompactá-la (usando zip ou rar), e você vai ter um arquivo .tar.md5 ou um arquivo .tar. Para descompactar esse arquivo, basta usar “tar -xf arquivo”, e finalmente a imagem está pronta para o processo de flash.

O processo de flash é bem simples, mas antes de fazê-lo, lembre-se de algumas coisas: primeiro, o suporte técnico da Samsung VAI encher o saco se descobrir que você fez uma modificação dessas no celular, e você pode perder a garantia. Segundo, faça o processo, de preferencia, de um notebook, e SEMPRE com o celular com bateria cheia ou quase cheia-não queremos que ausência de energia (tanto do PC como do celular) estraguem o processo todo, certo?

Então, para fazer o flash, basta deixar o celular num modo específico (modo de download) desligando-o e segurando “power+home+abaixar volume”. Ele pedirá uma confirmação, basta confirmar com o “aumentar volume”, e usar o heimdall. Eu rodei-o com o comando:

sudo heimdall flash --primary-boot boot.bin --cache cache.rfs --dbdata dbdata.rfs --factoryfs factoryfs.rfs  --modem modem.bin --param param.lfs --secondary-boot Sbl.bin --kernel zImage

Caso algum problema aconteça, não se desespere-basta tirar a bateria do celular e colocá-la novamente, e de novo deixa o celular em modo de “download” com a sequencia acima.

Enfim, com esse passo, seu celular terá acesso “root” e coisas interessantes podem ser instaladas (rastreadores que ligam automaticamente o GPS, por exemplo, ou o “Scala Installer” que pré-instala Scala no seu android e permite programar em Scala ao invés de Java, sem o processo de build demorado do proguard… mas mais sobre isso num outro post). Mas, se você quer algo mais hardcore, talvez seria interessante testar o CyanogenMod
(more…)

Android x iOS

Bom, comprei um android, depois da quebra do meu iPhone. Com três semanas de uso, acho que é interessante mencionar uma comparação dos dois, tentando ser o mais imparcial o possível.

Adiantando, eu estou gostando mais do android-mesmo reconhecendo que há pontos muito superiores no iPhone. Como forma de comparação, vou usar equipamentos com preços semelhantes (no caso, o aparelho android que tenho é um Samsung Galaxy S2). Termos como “o iPhone usa melhor o hardware porque um iPhone de 800mhz é comparável a um Android 1.2ghz” não fazem sentido aqui-de que adianta o processador ser mais fraco se, no fim, o preço do aparelho é o mesmo?

Enfim, começando pelo ponto mais positivo do Android-nada de iTunes. Sorry, folks, mas sinceramente o iTunes me lembra o Adobe Acrobat PDF Reader-um software que deveria fazer algo relativamente simples, e é pesado, lento, precisa de diversas atualizações (uma mais pesada que a outra) e necessita de uma super máquina pra rodar. Além disso, a idéia de “sincronizar músicas” do iTunes é uma porcaria-afinal, se eu tenho dois computadores, eu só posso sincronizar de um, caso contrário tenho que deletar TODA a minha playlist e começar de novo… não sei se no iTunes novo isto está corrigido (porque, como usuário de Linux, eu não usava o iTunes quase nunca).
(more…)

Ensaio Sobre a Violência – Dois

Bom, antes de voltar ao ritmo habitual do site, talvez seja interessante mencionar algo que há algum tempo tem me incomodado (e mais ainda agora, já que sofri um assalto que me deixou bem assustado com algumas coisas, mas enfim).

A violência encanta. Não adianta tentar dizer o contrário, ela está em novelas, em filmes, em praticamente qualquer obra de ação que olhemos. Ela encanta de tal forma que nos acostumamos com ela, que “é normal” ouvir um tiroteio de vez em quando, que “não sei quem foi assaltado, colocaram uma arma na cabeça dele”, e outras histórias que são ditas e repetidas pelas mais diversas pessoas, e que todos acabam ouvindo eventualmente numa conversa de ônibus, numa pessoa falando muito alto no celular, ou algo semelhante.

Exceto que não deveria ser deste jeito.

Quando as coisas acontecem com você, parece que alguma coisa muda. Olhando bem, você fica imaginando-se, naquela situação, relembrando os atos, sendo deixado sozinho no meio de uma rodovia, sem documento nenhum, sem absolutamente nenhuma forma de comunicação, e fica dependente da bondade de estranhos que também têm medo de serem assaltados e provavelmente não vão confiar em alguém pedindo ajuda à noite numa rodovia, certo? E depois desta tortura, a segunda tortura que é ligar para a polícia, através de um telefone emprestado de alguém, pedindo ajuda e esperar, e esperar, e esperar, até finalmente se tocar que a viatura que eles disseram que iam mandar pra te ajudar não vai chegar. E então você consegue uma carona de uma alma bondosa que não vai aparecer em jornal algum embora merecesse uma grande recompensa, vai até uma delegacia, e lá começa a retratar e reviver o que aconteceu para um escrivão que te olha com cara de “por que você está aqui me fazendo perder meu tempo”, até o momento em que você se sente não a vítima, mas o culpado. E de repente, finalmente um estalo no seu cérebro que lhe diz que não, não vai adiantar nada chamar a polícia e que você só está fazendo boletim de ocorrência por causa do seguro… e você percebe que aqueles que lhe assaltaram vão ficar impunes, e que provavelmente a punição deles virá no dia em que assaltarem a pessoa errada, que provavelmente vai estar armada e vai reagir… mas isso, se acontecer, vai demorar ainda, e enquanto isso você vai voltar pra casa, tirar todos os seus documentos de novo, comprar um novo veículo e sair de casa com medo de ser assaltado de novo…

É… pessoalmente, a violência não tem NADA de encantadora.
(more…)

Unobtrusive Javascript

Um monte de gente tem falado sobre Unobtrusive Javascript (ou UJS, para simplificar), mas há poucos que mencionam COMO fazer. Da mesma forma, o próprio Rails parece não ser muito decidido às melhores práticas (o que, sinceramente, é uma pena dada a idéia original do Rails de facilitar o desenvolvimento web). Aliás, talvez algumas mudanças do Rails valeriam para outro post, mas por hora, vamos para UJS.

A idéia do UJS, basicamente, é não misturar Javascript com HTML nas views. O que, sinceramente, é uma ótima idéia ao meu ver. O problema é como fazer isso de forma não-traumática. Para este exemplo, vamos ver inicialmente qual era a abordagem que eu usei, no passado, sobre UJS:

Antes, eu usava algum helper do Rails e criava as tags tipo <a href="algumaUrl" data-remote="true>, e no controller eu pedia para renderizar um template .js.erb. Isso trazia diversos problemas, por exemplo:

$('div').html(&quot;&lt;%= @user.name %&gt;&quot;);

Mas se o usuário tiver espaços no nome, precisaremos de "escape_javascript"… e aí começam alguns antipatterns (imagine HTML+ERB, mas dessa vez com todos os problemas de Javascript incorporados).

O ideal, e algo que tanto o Twitter como outros serviços web estão fazendo, é manter uma API web que renderiza os dados, e seu ambiente web nada mais é do que uma interface que consome esses dados (e renderiza algo na tela). Para esse exemplo, só vou usar jQuery e nada de Rails/Ruby/Whatever…
(more…)

Efeitos Colaterais e Códigos

Esse assunto é bem complexo, e envolve certas situações interessantes. Mas antes, precisamos de uma definição do que é um efeito colateral em código: quando se escreve um código em uma linguagem, cada procedimento/função/método deveria fazer uma, e apenas uma tarefa. Mais do que isso, e estamos inserindo um efeito colateral no código. Quando programamos em linguagens puramente funcionais, como por exemplo Haskell, fica evidente que estamos mexendo com uma função com efeitos colaterais porque ela fica, de certa forma, “marcada”.

Ok, e em Ruby, por exemplo? Como saber? A idéia é simples (e talvez isso possa até ser uma definição formal): “Uma função não tem efeitos colaterais quando não importa quantas vezes ela é chamada, ela sempre traz os mesmos resultados”. Embora simples, na teoria, identificar uma função assim nem sempre é fácil. Por exemplo, imaginemos um caso bem interessante: a função “save” do ActiveRecord. Ela parece, em teoria, não ter efeitos colaterais, mas ela possui um: vamos para um código na prática:

class Person &lt; ActiveRecord::Base
  validates_uniqueness_of :name
end

me = Person.new :name =&gt; &quot;Maurício&quot;
myself = Person.new :name =&gt; &quot;Maurício&quot;
me.save #true.
me.save #false. FALSE?

Tecnicamente falando, as duas funções deveriam retornar true: eu passei dois objetos exatamente iguais para elas. O segredo, se é que há algum, é que o método “save” na verdade faz duas coisas: valida os objetos e salva-os no banco. O principal problema é o “salvar no banco”, na verdade: estamos definindo um estado “global”, digamos assim. Todos os nossos novos objetos “Person” vão, automaticamente, ter que consultar o banco (nosso “estado global”) e verificar se a propriedade “name” já existe. Como se, por causa desse “estado” todos os saves automaticamente ganham um “if” a mais. Outra coisa também que o “save” faz que indica um efeito colateral é mudar o “id” do objeto:

me = Person.new :name =&gt; &quot;Maurício&quot;
p me.id #retorna nil
me.save
p me.id #retorna um número qualquer

(more…)

O Método “Extend” e Seus Usos

Provavelmente muita gente conhece o método “extend”, usado principalmente em classes para adicionar métodos, tais como:

module Nameable
  def set_name(name)
    @name = name
  end
end

class MyClass
  extend Nameable
  set_name &quot;Foo Bar&quot;
end

Claro que há pessoas que fazem verdadeiras aberrações, tipo um “module” que define o callback “included” que chama um “extend”, tipo essa situação:

module Nameable
  def self.included(klass)
    klass.extend Nameable::ClassMethods
  end

  module ClassMethods
    def set_name(name)
      @name = name
    end
  end
end

class MyClass
  include Nameable
  set_name &quot;Foo Bar&quot;
end

Mas vamos ignorar esse tipo de coisa e pensar em outras formas de usar o “extend”. Digamos que temos uma classe como a seguir:

class Authenticator
  def login(username, password)
    if User.find_by_username_and_password(username, password)
      return true
    else
      return false
    end
  end

Ok, temos uma regra para autenticar (aviso: não use isso em produção, o código prevê que os usuários tem suas senhas gravadas no banco sem criptografia nenhuma). Digamos, agora, que em um determinado cliente, esse código só não é o suficiente: o cliente quer que, antes de autenticar no banco, se autentique no sistema

Uma solução é usar monkey-patch. Nesse caso, teríamos um código em outro lugar que redefiniria a classe e adicionaria novos métodos, tipo:
(more…)

Testes de Controller – a Saga

Semana passada comecei finalmente um projeto do zero usando Rails 3.1. A experiência foi novidade para mim, que por causa de uma série de legados (e também por questão de performance) estava preso no Rails 2.3, e não tive a oportunidade de ver como os testes funcionam no Rails 3.

Mas antes de chegar no assunto, vamos rever que o Rails não é puramente MVC. O “Controller” do Rails agrega coisas que deveriam ser feitas na view (basicamente, buscar o objeto para ser exibido). Para mais detalhes, ver meu post anterior.

Por esse motivo, e unicamente por este motivo, eu não acredito ser possível fazer teste unitários de controllers.

Um teste unitário deve, em teoria, testar um pedaço do sistema, isoladamente de outras partes. Como fazer um teste unitário de algo que é, essencialmente, um “glue code”, ou seja, um código que une regras de negócio (Models) e interfaces (Views)?

Antes do Rails 3, eu usava uma abordagem mais “integrada” para esses specs. No controller, eu usava a palavra-chave do rspec-rails “integrate_views”, e testava o par “controller-view”. Os specs ficavam mais ou menos assim:

describe PeopleController do
  integrate_views

it 'should show people on &quot;index&quot;' do
    sessions[:user_id] = Factory(:user).id
    Factory :person, :name =&gt; &quot;Foo Bar Baz&quot;
    get :index
    response.should be_success
    response.body.should include(&quot;Foo Bar Baz&quot;)
  end

it 'should render &quot;new&quot; view if validation failed&quot; do
    sessions[:user_id] = Factory(:user).id
    post :create, :person =&gt; { }
    response.should render_template(&quot;new&quot;)
  end
end

Claramente, isso não é um teste unitário, mas há um grande ganho nessa abordagem: se eu resolver mudar a variável “@users” para “@records”, e atualizar a view, não preciso mexer em nenhum spec. Na prática mesmo, eu não preciso mexer em nenhum SPEC se eu mudar o layout, adicionar mais informações na view, buscar mais registros no controller e atualizá-los na view, enfim, em qualquer momento eu sei, exatamente, se o teste está falhando ou passando, sem as fragilidades que mocks podem oferecer.
(more…)

Model View Controller

Ultimamente, Rails tem se popularizado, e com ele o famoso (e já antigo) MVC. Porém, como todas as coisas, a prática acabou sobrepondo a teoria, então achei que seria interessante falar um pouco sobre MVC, já que parece-me que algumas confusões começaram a acontecer. Esse post é imensamente baseado nesse post do Martin Fowler sobre arquiteturas GUI, então seria interessante ler ele também.

Enfim, vamos lá: no Rails, quando fazemos um “scaffold”, é criada uma combinação de coisas para nós: uma “migration”, que cria uma tabela no banco. Um “model”, que basicamente é o mapeamento dessa tabela para um objeto. Um “controller”, que faz a busca do registro certo e repassa para a renderização da tela. Por exemplo, a ação “edit”:

  def edit
    @foo = Foo.find(params[:id])
    render :action =&gt; 'edit' #Isso é redundante, mas deixa explícito um aspecto importante.
  end

Além disso, há uma série de boas-práticas, tais como não concentrar código de regra de negócio no controller, não colocar lógica nas views, enfim. Porém, essas “regra gerais” pecam em um ponto:

Rails não é 100% MVC…
(more…)