Maurício Szabo

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

A saga da busca em bancos de dados

Num mundo perfeito, todos os sistemas de armazenamento se conversariam, a nível do servidor e não do cliente, e jamais precisaríamos manualmente definir por “joins”, ou seja lá qual a forma que seu banco de dados faz.

Claro, o mundo não é perfeito.

Nesse caso, precisamos no mínimo padronizar uma forma de buscar dados. A maioria dos sistemas relacionais entende SQL, embora isso também não seja padronizado. Pior ainda, se for necessário buscar uma informação que está em uma tabela da base de dados X, e uní-la (join) com uma da base de dados Y, temos que fazer a busca manualmente.

Entra, aí, uma idéia.
(more…)

By Maurício Szabo, ago

Curiosidades sobre Procs em Ruby

Esses dias, estava montando um código para Ruby usando Procs (blocos de código), salvando esses procs em variáveis e depois rodando-os sobre “bindings” diferentes. Talvez tenha ficado um pouco complicado de entender, mas na prática é algo mais ou menos assim:

class UmaClasse
  def self.callback_qualquer
    ...#alguns códigos aqui....
    @@bloco = proc do
      break if condicao_qualquer
      ...#códigos do meu callback
    end
    ...#mais algumas coisas
  end

  def salvar
    instance_eval(&@@bloco)
    puts "Rodei"
  end
end



Ou seja, eu posso criar um bloco definindo um callbackqualquer, e depois rodar esse bloco no contexto da “instância”, não da classe (o código que eu fiz, na verdade, é bem mais complexo). Mas, surpreeendentemente, esse código não funciona – ele lança um LocalJumpError se a condição do Proc for satisfeita. Por quê?


 (more…)
By Maurício Szabo, ago

Lazy Evaluation

Existe um conceito, muito utilizado por programadores de linguagens funcionais e pouco utilizado em outras linguagens, chamado Lazy Evaluation. Para não extender muito a definição, basta dizer que no caso do Lazy Evaluation, um resultado só é computado quando ele é necessário ao programa. Exemplos explicam melhor o conceito, então segue um:

100.times do |iterador| #Equivalente ao "for" de outras linguagens
  n = fatorial(iterador)  #Calcula o fatorial
  if(iterador.even?)       #Se for um número PAR
    print "Resultado da operação: #{n}" #Imprime o resultado do fatorial
  end
end

Lembrando que Ruby não trabalha com Lazy Evaluation, portanto o código acima não seria adequado. Mas, digamos que a linguagem acima suporte Lazy Evaluation: o resultado de n só seria calculado se o iterador for par. Ou seja, embora estejamos sempre definindo que n = fatorial(iterador), o programa não calcula o resultado do fatorial até que precisemos dele – neste caso, até que ele seja impresso na tela. Ou seja, em linguagens como Haskell, que suportam Lazy Evaluation por padrão, o código acima seria perfeitamente válido e não seria ineficiente. Normalmente, quando você usa Lazy Evaluation o código que só rodará depois é chamado de “promisse”, pois ele é uma promessa que o valor será calculado.

Mas porque isso é tão interessante?

(more…)

By Maurício Szabo, ago