código-fonte

Clojure, LightTable, e uma nova forma de programar

Esses últimos meses tenho estudado Clojure, ClojureScript, e me entendendo com o ecosistema de tudo isso. Mas sobre a linguagem fica para outro post. Por hora, vamos a uma frase famosa: A language that doesn’t affect the way you think about programming, is not worth knowing, ou Uma linguagem que não afeta a forma que você pensa sobre programar, não vale a pena aprender. Essa frase, de Alan Perlis, mostra muita coisa do que eu penso antes de aprender uma nova linguagem, e vai explicar muito ao aprender sobre Clojure.

Antes de mais nada, vejamos como as linguagens evoluíram – C++ e Java são linguagens orientadas a objeto. Ruby, Python, e Scala também. Mas vejamos como usar uma lista em Java: abrimos o Java, numa IDE lenta como o Eclipse (que precisa de instalação, etc), importamos a lib…. qual lib mesmo? Bom, entramos num Javadoc, procurarmos a lib…. isso em C++ é pior ainda, já que em Java, pelo menos a IDE completa automaticamente os métodos (e algumas vezes, até os imports) pra nós.

Em Scala e Ruby? Abrimos o console, criamos uma lista, atribuímos a uma variável e digitamos: variable., seguido de alguns tabs e o console completa para a gente. Esse é o poder de um REPL (Read-Eval-Print-Loop, ou console, IRB, etc), e o REPL muda completamente a forma de escrever, explorar, entender e até mesmo de pensar em programação. Precisamos um dado no banco de dados? Entramos no REPL, digitamos User.create!(login: “foobar”), e voilá – temos um objeto criado. Não precisamos criar uma tela de cadastro para criar esse dado, não precisamos abrir o gerenciador do banco, etc.

Isso, com Clojure, é elevado ao limite.

(more…)

By Maurício Szabo, ago

Sou um Anti-Identação

O título desse post parece estranho, mas vamos lá. De fato, eu sou um anti-identação, não gosto de ver meu código identado.

Não estou dizendo que eu não idento meu código-longe disso. Apenas que eu prefiro evitar a identação sempre que for possível. Mas vamos por partes…

Primeira coisa, isso começou há algum tempo quando uma pessoa propôs o seguinte problema: montar uma lista encadeada (Linked List) com as seguintes regras:

1) A lista deve validar se ela está vazia, e lançar um erro caso tente-se retirar um item da lista vazia
2) Cada método pode ter, no máximo, uma linha
3) Não se pode usar “if” em momento algum

Claro que é uma bela loucura, mas depois que eu consegui resolver esse código, pensei: se eu consegui resolver um problema desses com apenas uma linha por método, será que meus códigos não tem coisa demais?

Aí, comecei a experimentar isso em código de produção. Isso meio que criou um estilo de codificar bem interessante, e vou tentar mostrar aqui com alguns exemplos:
(more…)

By Maurício Szabo, ago

Orientado a Objetos versus Funcional

Bom, esses dias estava estudando Scala. Uma linguagem multi-paradigma, mas que parece mais “funcional” do que “imperativa”. Scala cai numa posição ainda nebulosa para a maior parte das pessoas (e acho até que para o mercado também). Afinal, imutabilidade é “programação funcional”? Scala não faz nada que impede “side-effects” no código, como Haskell por exemplo, então ela é funcional mesmo?

Como mesmo eu não tenho muitos conhecimentos em linguagens funcionais, resolvi propor um problema para mim mesmo: implementar uma árvore binária em Ruby, e depois portá-la para Scala, tentar uma abordagem imutável em Scala, e depois portar para Haskell. O código está no github, mas algumas coisas vão ser discutidas aqui.

Primeiramente, a árvore imutável é feita recriando a árvore inteira. Claro, não podemos re-criar apenas um nó e apontar, digamos, a referencia de seu pai para esse novo nó, porque o pai é imutável (assim como qualquer outro aspecto do programa).

class Node[A <% Ordered[A]](value: A = None, left: Option[Node[A]] = None, right: Option[Node[A]] = None) {
    def insertNew(newValue: A): Node[A] = value match {
        case v if(newValue < v) => insertLeft(newValue)
        case _ => insertRight(newValue)
    }

<pre><code>private def insertLeft(newValue: A) = new Node(value, newChild(left, newValue), right)
private def insertRight(newValue: A) = new Node(value, left, newChild(right, newValue))
private def newChild(child: Option[Node[A]], newValue: A) = child match {
    case Some(child) =&amp;amp;gt; Some(child insertNew newValue)
    case None =&amp;amp;gt; Some(new Node(newValue))
}
</code></pre>

}

(more…)

By Maurício Szabo, ago

Em Patópolis, Programe como os Patos

Este é um post sobre “Duck Typing”, e finalmente eu escrevi ele (estava enrrolando para fazê-lo). Acho esse post bem importante porque eu percebi, com a experiência em Ruby, que poucas pessoas sabem lidar com o dinamismo da linguagem (e aproveitá-la ao máximo).

Então, vamos falar um pouco sobre Duck Typing. O básico, a maioria já sabe:

def imprimir(objeto)
  print objeto.falar
end

Ou seja, na declaração do método eu não defino nenhuma regra do que aquele objeto pode receber; apenas chamo os métodos que eu o objeto passado como parâmetro deveria implementar, e confio que vai dar certo. Parece simples, e até um pouco inseguro, então tem gente que prefere fazer umas checagens antes (tipo usando objeto.is_a?(Pessoa) ou objeto.respond_to?(:falar)), mas eu acho que isso quebra a idéia de Duck Typing. Para mim, tudo se resume a uma palavra: Protocolo.

(more…)

By Maurício Szabo, ago

AgileBrazil 2011 – parte 2

Essa parte é sobre minha palestra no AgileBrazil 2011. Sexta-feira, resolvi que apenas apresentaria minha palestra, depois iria curtir Fortaleza (sério, aquele lugar é muito bom!).

Enfim, minha palestra foi Mantendo a Qualidade dos Códigos de Teste, e nela resolvi arriscar duas coisas novas: primeira, em fazer uma palestra para pessoas de nível intermediário, para não ter que ficar explicando o que são mocks, stubs, etc. Segundo, que a palestra seria de duas horas, para dar tempo de falar tudo o que eu queria.

Claro, a segunda opção quase me deu um tiro no pé. Primeiro, porque para não soar irreal, eu resolvi que todo o código da palestra (que por sinal, está disponível no link acima. Recomendo que vocês baixem o link, a versão do slideshare esconde algumas coisas) ficaria disponível no Github, com exemplos reais (assim, qualquer pessoa poderia rodar os códigos e ver que é possível sim fazer testes daquela forma). Segundo, porque essas duas idéias me tomaram um tempo absurdo para escrever a palestra. Demorei MUITO para fazê-la, bem mais do que eu esperava. E terceiro, porque descobri que duas horas também não é muito tempo…
(more…)

By Maurício Szabo, ago

Otimizando com Javascript

Inicialmente, o nome desse post era pra ser: “otimizar ou escalar?”, mas acabei optando por este outro nome. Afinal, a postagem é sobre como foi otimizado, então…

Há algum tempo, aqui em meu trabalho, sofríamos com um sistema meio problemático: o sistema em questão é um sistema montado para que alunos possam escolher disciplinas, e é feito em duas fases. Nosso problema específico era com a segunda fase: um aluno só pode escolher uma disciplina desde que ela possua vagas, e como há certas disciplinas que muitas pessoas querem, isso vira uma corrida contra o tempo: praticamente metade da universidade acessando o sistema ao mesmo tempo, para conseguir sua vaga, e o sistema demorando muito tempo para completar cada requisição, enfileirando requisições, e um tempo absurdo para atender cada uma…

Enfim, foi jogado mais poder de processamento, mas para cada um processador que acrescentávamos, entravam mais quinheitos alunos, e cerca de cem disciplinas. Claramente, não haveria load-balancer que aguentasse, nem máquina que pudesse aceitar. Estudamos uma base não-relacional, diversas soluções, até chegar em uma: processar a página no cliente.
(more…)

By Maurício Szabo, ago

Estudos com Javascript

Recentemente, comprei o livro Javascript – the Good Parts, do Douglas Crockford. A principal motivação, não vou negar, foi o node.js (e o fato que muitas pessoas na net têm falado de Javascript como uma das mais “novas” maravilhas. Mas isso fica pra outro post). O livro, embora tenha uma série de problemas (e o principal é a ausência de exemplos claros, além de dar pouca ênfase ao “Javascript way”, na minha opinião) é muito bom e traz algumas definições no mínimo diferentes sobre Javascript.

Basicamente, o que é Javascript? Javascript é orientado a objeto? Javascript é funcional? Javascript suporta classes, suporta….?

Para começar, Javascript é uma linguagem de programação com sintaxe semelhante a C++, dinâmica, com tipagem absurdamente fraca, pseudo-orientada a objetos, orientada a protótipos e funcional. Wow… um de cada vez.
(more…)

By Maurício Szabo, ago

Ensaio Sobre Tesouras de Plástico sem Ponta

Pode parecer estranho o título deste post, mas na verdade ele não é apenas sobre aquelas tesouras de criança, mas sobre segurança e como ela afeta nossa vida. Mas, para isto, é melhor começar com uma história simples de diferença de cultura:

Na pré-escola, professores e professoras sempre insistiam para usarmos “tesouras sem ponta”, que normalmente significava aquelas tesouras minúsculas com cabo de plástico e que não cortavam nem uma folha de papel direito. Quando você é criança, porém, tudo é divertido (até o fato da tesoura não cortar), e no fim você ou pede emprestada uma tesoura de outra criança, que ainda não perdeu o corte, ou acaba cortando na mão, quando o corte for reto.

Agora, vamos para outra cultura: Japão. Em animes, você normalmente vê crianças e adolescentes com aulas de culinária, prendas domésticas, ou semelhantes. Nestas aulas, os adultos supervisionam, mas são os alunos quem realmente acendem o fogo, usam facas pontudas, etc. A idéia, até onde eu sei, é ensinar desde pequeno como usar uma ferramenta que pode potencialmente ser perigosa, como ensinar a ter cautela.

Imagine, agora, você com trinta anos, um cabeleireiro, estilista, artista plástico, sendo obrigado a usar uma tesoura de plástico sem ponta? Um cozinheiro que precisa de “provadores”, “acendedores de fogão”, porque, ora, no primeiro caso ele pode queimar a língua, no segundo, ele pode explodir o fogão. Ou então, usando o fogão X, porque ele tem um acendedor automático de bocas, e assa um bolo em alguns dias, afinal, com um fogo BEEEM baixo, a chance de queimar o bolo é bem menor… certo? O que isso nos diz? Na minha opinião, tudo se resume a apenas uma palavra:

Confiança.
(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