Living in the programming world

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

Paradigmas do MongoDB

Esses dias trabalhei firme no meu mapeador para MongoDB, o MongoParadigm. O código dele, como sempre, está disponível no GitHub. Atualmente estou me esforçando para integrar ele com Rails, e depois disso tudo pretendo finalmente implementar o “has :many” e o “belongs_to”. Pensei como seriam essas associações, e percebi que elas era a parte menos importante do MongoDB.

Isso porque eu acho que estou entendendo o que exatamente é uma base de dados orientada a “documentos”, finalmente – trabalhando na UFABC, é fácil de ver esse tipo de coisa: O registro de um aluno é um documento (no caso, de uma pessoa). O histórico do aluno é outro documento – e essa é a parte interessante, o histórico é um documento que pertence a um aluno, e não o contrário. Isso deve ficar bem documentado no MongoDB, porque apesar de não parecer, as bases de dados relacionais levam a gente a pensar de forma não-natural. Por exemplo, quando você vai armazenar um histórico de notas de um aluno em uma base relacional, normalmente você não armazena UM histórico, e sim um monte de registros que estão ligadas a um aluno por uma chave. Agora, é perfeitamente simples de entender porque o MongoDB não implementa trasações – afinal, no caso dele, se fosse necessária uma alteração se está mexendo em UM documento, e não em 20 registros, por exemplo.

(more…)

By Maurício Szabo, ago

Usando frameworks Java com JRuby

Estes dias, estava vendo uns projetos antigos e lembrei de um framework bem legal para Java chamado ZK. O problema do ZK é que você consegue aproveitar o máximo dele quando você programa usando Servlets, e não usando o modelo ZUL dele. Lembrei de alguns projetos que fiz, de algumas coisas interessantes que ele fazia e também lembrei que eu cheguei a programar com Servlet em Ruby, e aqui vai como eu fiz mais esse trabalho para evitar Java. NOTA: Isso funciona com qualquer framework Java, seja ele ZK ou Echo2 ou qualquer outro, porque na verdade o que você faz é escrever algumas linhas de código de “cola” e depois passa o controle para o JRuby

A primeira coisa que você precisa é do JRuby instalado, e de um compilador Java. Crie seu projeto normalmente, e provavelmente você terá uma classe que será responsável por instanciar a primeira classe (janela, página, seja lá o que for) do seu Servlet. Nesse ponto que a “mágica” acontece. Para simplificar as coisas, que vou criar uma classe (chamada Inicial) que instanciará uma JFrame. Toda a JFrame será definida em JRuby.

(more…)

By Maurício Szabo, ago

A importância de vegetar um pouco

Parece estranho o título de um post assim, mas vamos lá:

Quem nunca parou para olhar o céu, imaginar desenhos nas nuvens? Quem nunca ficou escutando uma música, e parou tudo o que estava fazendo só para ouvir a letra, imaginar um cenário, sei lá? Pegar uma folha de papel, encher ela com desenhos de bonecos ou escrever as primeiras palavras que vem na sua cabeça, por menos sentido que elas façam?

Pra que tudo isso? Vegetar faz bem, por menos sentido que isso pareça fazer. Faz bem não pensar em nada de vez em quando, liberar sua mente de qualquer idéia, e deixar que as coisas fluam. Parece meio loucura isso, mas eu sempre sinto que eu produzo mais quando não estou pensando ativamente naquilo que estou fazendo, simplesmente deixando “fluir”. É como tocar piano – quanto mais você tenta acertar o movimento das duas mãos, mais difícil fica. Mas quando você “esquece” de prestar atenção, parece que a coisa vai mais fácil.

(more…)

By Maurício Szabo, ago

Linguagem de Programação GO

Hoje, algumas pessoas no twitter e até mesmo aqui na UFABC me mandaram um link: http://golang.org/. Parece que é uma linguagem desenvolvida pelo Google, para procedimentos internos, sejam lá quais eles forem.

Resolvi dar uma olhada no site, nos exemplos, para ver o que há de novo. Primeiramente, o típico “Hello World” em Go:

package main
import "fmt"

func main() {
  fmt.Printf("Hello, world\n")
}

Minha primeira impressão foi: meu Deus, reinventaram o Java! Sintaxe C/C++, construções estranhas (fmt.Printf?). Mas fica pior:

func nextInt(b []byte, pos int) (value, nextPos int)
func ReadFull(r Reader, buf []byte) (n int, err os.Error)

Percebem? Uma função chama-se nextInt, a outra ReadFull. Me lembra do PHP e suas funções sem padronização de nomes… e a sintaxe?
(more…)

By Maurício Szabo, ago