Living in the programming world

Conectando Javascript e Ruby

Bom, a algum tempo vi uma biblioteca chamada Harmony, para Ruby, que tenta fazer esse processo. Porém, eu achei alguns problemas na biblioteca que meio que me impediam de usá-la do jeito que eu queria, então acabei encontrando uma outra alternativa: The Ruby Racer.

Esta biblioteca usa o interpretador V8, o mesmo usado no Google Chrome, para interpretar Javascript. Possui uma API bem simples, e consegue incorporar objetos Ruby no Javascript de uma forma bem transparente. Como exemplo, digamos que queremos expor uma classe Ruby para o Javascript. Basta usar o código a seguir:

require 'v8'

class UmaClasse
  def initialize(nome)
    @nome = nome
  end

  def imprimir_nome
    puts @nome
  end
end

js = V8::Context.new
js['uma_classe'] = UmaClasse.new
js.eval('uma_classe.imprimir_nome()')

Este código conectará, no Javascript, um objeto chamado uma_classe. Para instalar a biblioteca, um simples “gem install therubyracer” basta, na maioria das vezes. Quando isso não funciona (que nem o meu caso)…
(more…)

By Maurício Szabo, ago

Dá para fazer tipagem estática em Ruby?

Bom, resolvi começar uma série – coisas que você NUNCA quis fazer com Ruby, e tinha medo de perguntar. Basicamente, pensei em montar códigos absurdos de coisas que são completamente contra a filosofia da linguagem, ou que pelo menos são muito esquisitas, e publicar aqui os resultados. As regras são simples: os resultados devem ser testáveis (com RSpec, de preferência) e devem ser escritas puramente em Ruby, de preferência sem nenhuma biblioteca auxiliar (e, se for necessário usar, é obrigatório que a biblioteca tenha sido escrita puramente em Ruby também).

Como primeiro da série, vamos simular uma tipagem estática em Ruby. Como é impossível sobrescrever o operador “=” em Ruby, resolvi usar uma função – static – para simular o mesmo comportamento. Para simplificar, vamos meio que definir uma “variável global” com “static.”, e definir que esta terá tipagem estática. Começamos definindo uma função chamada “static”

def static
  Static.instance
end

(more…)

By Maurício Szabo, ago

Porque o Rubinius é importante.

Muita gente já falou sobre o assunto, e eu percebi, até agora, que não dei minha opinião então…

Para as pessoas que estão interadas, Rubinius é uma implementação de Ruby sobre Ruby. Parece estranho, e é um pouco mesmo, então vale a pena mostrar mais como isso funciona. Nos outros interpretadores, uma boa parte das classes padrão da linguagem são implementadas em C (ou Java, no caso do JRuby). Em Rubinius, estas classes são implementadas em Ruby sempre que possível, e a máquina virtual (VM, atualmente estão usando o LLVM) é extremamente simples e otimizada. Com isso, além de Ruby ficar muito mais flexível (mais? sim, é sempre possível) ainda se ganham alguns conceitos interessantes. Para fazer esta “mágica”, é necessário um compilador que traduz código Ruby para bytecodes que serão executados na LLVM – e Rubinius escreveu este compilador totalmente em Ruby. Pode parecer um conceito absurdo, mas não é – o próprio compilador C da Gnu, o GCC, é escrito em C.
(more…)

By Maurício Szabo, ago

Ensaio Sobre a Violência

Este será um post totalmente off-topic*, mas tudo bem.

Quando eu era mais novo, lá para a minha pré-adolescencia, lembro de ter assistido ao filme “Ghost – do outro lado da vida”. Muitos já devem tê-lo assistido também. Lembro que na época, meu pai estava começando a seguir o espiritismo, e não lembro mas acho que foi por este exato motivo que estávamos assistindo ao filme. Lembro também de ter comentado que os vilões meio que se matavam sozinhos, e meu pai concordou comigo, mas por algum motivo aquilo não me pareceu certo… parecia que tinha algo muito errado com o filme, com a forma como o personagem principal enfrentava os vilões, mas antes de explicar direito o que eu pensei, vamos para outro filme: “Jogos mortais”. Numa primeira comparação, parece que o vilão de Jogos mortais é bem mais cruel e perverso do que o mocinho de Ghost, porém fazendo uma comparação mais completa, isso não é verdade.

Vendo pelo seguinte lado: em Ghost, o personagem principal morre, e como fantasma caça seus assassinos. Quando os encontra, os assombra até que eles, assustados como nunca, acabam se matando “sozinhos”. Soa familiar? O estranho é que, para a maioria das pessoas, Sam (de Ghost) não é um “vilão” como o de Jogos mortais, por exemplo, embora a atitude de ambos os personagens é exatamente a mesma. Talvez possam vir papos do tipo “mas os personagens que Sam mata são assassinos, e ele faz isso sem intenção, blá blá”, mas a verdade é que isso não importa a mínima – a reação que parecemos ter quando uma pessoa é morta difere demasiadamente dependendo se a pessoa era “boa” ou “má”.
(more…)

By Maurício Szabo, ago

Ascenção e Queda de Scrum

Bom, para os que não sabem ainda, eu trabalho como Analista de TI na Universidade Federal do ABC. Ano passado (2009), tive a difícil missão de criar uma divisão de desenvolvimento de sistemas, de forma que ela atendesse um monte de demandas. Além disso, o TI já tinha 3 anos de existência e nunca tinha-se sequer rascunhado uma divisão de desenvolvimento, porque as primeiras chefias do Núcleo de TI tinham a idéia de que não haveria desenvolvimento de software dentro da UFABC. Enfim, problemas à parte…

Estudos foram feitos. Já havia uma série de scripts escritos todos em Ruby para facilitar um número de tarefas, e também já existiam dois projetos de Rails publicados, então parecia no mínimo estranho usar uma linguagem ágil, com um framework ágil (que inclusive possui geradores de código) e adotar uma metodologia tradicional. Artigos também com o do professor Xexéo, da UFRJ, auxiliaram a mostrar que existe uma frente acadêmica que abraça mudanças (já escrevi em posts anteriores que o Brasil é um país que valoriza mais do que deveria os diplomas e títulos). Anyway, aos fatos:

(more…)

By Maurício Szabo, ago

A importância do código-fonte

Talvez o nome deste post seja estranho, em um blog tão focado à programação. Porém, vale um pouco de história.

De duas semanas para cá, estou escrevendo um artigo para tentar apresentar no Workshop Brasileiro de Métodos Ágeis. Inclusive, eu recomendo a todos que trabalham a um certo tempo com uma linguagem, tecnologia, etc, que escrevam um artigo sobre o assunto, mesmo que não seja em formato científico, só para organizar as idéias. Ajuda bastante a focalizar seus próximos passos. Porém, esse não é o assunto. O assunto é bem simples, na verdade:

Design de Software.

Tentei traçar as origens da tal “metodologia em cascata”, e não consegui. O artigo mais antigo que eu cheguei foi de Winston Royce, em 1970 (sim, 1970 – é difícil de acreditar que a maioria das metodologias de desenvolvimento de software de hoje se baseiam numa idéia que surgiu a 40 anos atrás), e Royce sequer nomeia a metodologia. Na verdade, ele apresenta o desenho típico de uma metodologia em cascata e comenta: “a implementação acima é arriscada e convida à falhas”. Seria possível que, na informática, alguém em 1970 apresenta o modelo que mais tarde seria chamado de “cascata”, diz para as pessoas não usarem, e as pessoas começam a usá-lo? Bom, sendo informática, eu não duvido de nada (nem de doutores em engenharia de software citando que até uma metodologia em cascata é melhor do que as metodologias ágeis – sim, eu ouvi isso). Enfim…

Mas, voltando ao tópico – a metodologia que Royce propôe enfatiza a documentação. Mais tarde, essa documentação seria unificada pela UML, e uma série de estudiosos iriam “contribuir” para a tal UML, criando mais e mais diagramas… além daquelas coisas obsoletas, tipo fluxograma, “teste de mesa”, etc etc. Aqui, vale a pena citar Jack Reeves, que pergunta em seu artigo (de 1992): “O que é design de software?”. O artigo é extenso, mas transcrevo umas partes aqui:

O objetivo final de qualquer atividade de engenharia é algum tipo de documentação. Quando um trabalho de design foi completado, a documentação é entregue à manufatura. Eles são um grupo completamente diferente, com habilidades completamente diferentes do time do design. Se a documentação realmente representa um design completo, o time da manufatura pode proceder para construir o produto. De fato, eles podem proceder para construir uma grande parte do produto, sem qualquer intervenção dos designers. Depois de revisar o ciclo de desenvolvimento de software, da forma que eu entendo, eu concluo que a única documentação de um software que, na verdade, satisfaz o critério de uma documentação de design é o código-fonte.
(more…)

By Maurício Szabo, ago

Orientação a documentos em SQL

Antes de mais nada, vale lembrar que o MongoParadigm é um projeto ainda em desenvolvimento, que precisa ser deixado mais simplificado em alguns pontos. Porém, e isso é a parte que realmente é importante, não é fácil achar um plano de hospedagem que suporte MongoDB, e principalmente, é provável que estes planos sejam caros ou fora do Brasil. Normalmente, os planos suportam MySQL, PostgreSQL, ou outra base de dados relacional (na ausência delas, ainda há o SQLite, que para pequenas aplicações atende bem). Portanto, na maioria das aplicações que desenvolvemos por hobby, simplesmente não há onde hospedá-las.

Foi então que encontrei este artigo: How FriendFeed uses MySQL to store schema-less data. A proposta é simples, montar uma base de dados que rode semelhante ao MongoDB (obviamente sem certas features, como “atomic updates”, auto-sharding, etc) usando YAML para fazer as serializações, e suportando índices tal como MongoDB.
(more…)

By Maurício Szabo, ago

A arte de desenvolver

Pode parecer estranho, mas desenvolver aplicativos é uma arte. É difícil, de verdade, fazer as pessoas entenderem isso.

Programação precisa de conceitos? Ótimo, música e pintura também. Também é necessário aprender a pensar da forma que a ferramenta que você usa para desenvolver (ou tocar, em caso de música) pede. Provavelmente, o improviso que você faria em um violão não será o mesmo de um violino, ou de um piano – da mesma forma, o código que se escreve em uma linguagem não segue os mesmos padrões de outras linguagens, e tentar negar isso é absurdo no mínimo.

Para os que programam mesmo, sempre há aquele amigo que quando lê um código, praticamente em qualquer linguagem, aponta na hora aonde está o erro. Ele está simplesmente adivinhando? Há uma máxima que a maioria das pessoas de desenvolvimento de sistemas esquece: “O código é muito mais lido do que escrito”. Da mesma forma, há uma citação atribuída à Donald Knuth, professor de renome da universidade de Stanford que diz: “Code is written for humans to read and only incidentally for computers to execute”. Continuando com o compacto, ao mesmo tempo em que um desenhista precisa ver muitos desenhos, visitar galerias de arte, ver as tendências, o programador deve também estar atento a essas coisas. Há um framework muito legal que as pessoas estão falando? Leia o código dele. Faça um pequeno projeto. Aprenda uma nova linguagem, nem que seja Haskell, Lisp, Smalltalk, ou outras linguagens que quase não tem repercursão comercial. No mínimo, você terá feito algo inútil. No máximo, você estudará uma linguagem nova e tentará aproveitar conceitos interessantes dela em outros projetos.

(more…)

By Maurício Szabo, ago

Smalltalk, e a noção de objetos

Em outro artigo meu, citei como uma linguagem como Java pode ser usada para programação procedural, mesmo sendo “orientada a objeto”. Esses dias, brincando um pouco com Smalltalk, acabei achando um e-mail do Alan Kay sobre o que ele considera “programação orientada a objeto”, e o que isso difere do que conhecemos.

Primeiro ponto: na programação orientada a objetos que a maioria de nós conhecemos, a abstração é mais ou menos assim: um objeto é uma “coisa”, e essa coisa possui métodos. Na hora em que você roda o programa, a “classe” é definida, um ou mais objetos são instanciados, e a partir daí você pode chamar os métodos dos objetos.

Em Smalltalk, as coisas são um pouco diferentes
(more…)

By Maurício Szabo, ago

Liberdade – fora com ela!

Imaginemos uma situação hipotética: você vai até uma loja de roupas famosa, que possui as roupas mais duráveis e bonitas e escolhe uma calça. Na hora que você vai pagar, você tem o seguinte diálogo com o atendente:

Atendente: Bom dia, senhor. Antes de pagar, o senhor sabe que você não pode usar essa calça para ir para festas, não sabe?
Você: Desculpe… como assim?
A: O fabricante dessa calça proíbe terminantemente de usar a calça em festas, baladas, raves, ou similares…
V: Como é?
A: E também, você vai encontrar na etiqueta da calça um site. Note que apenas as roupas listadas naquele site podem ser usadas com essa calça…
V: Desculpe, do que você está falando? Quer dizer que o fabricante recomenda as roupas que eu posso usar com essa calça?
A: Não, senhor, o senhor entendeu mal. O fabricante proíbe que você use qualquer outra roupa com essa calça. Caso o senhor seja pego usando uma roupa diferente do que ele citou no site, confiscaremos a calça e o senhor terá que pagar uma multa…
V: Desculpe, eu gostaria…
A: Aproveitando, o senhor não pode modificá-la, alterá-la, tingí-la…….

Parece absurdo? Bom, de fato é. Mas então, por que as pessoas concordam que a Apple faça isso com seus produtos? O mais novo brinquedinho deles, o iPad, é tão restritivo quando o iPhone, que por si só já é o maior absurdo tecnológico da história – mas não, é Apple! Tem que ser bom, não?

(more…)

By Maurício Szabo, ago