boas práticas

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

Update: o que estou estudando?

Como faz tempo que não posto nada no blog (falta tempo), resolvi fazer este post meio que para iluminar um pouco o que tenho estudado ultimamente.

Comecei a aprender Scala. Na verdade, peguei esse tempo para estudar linguagens interessantes, que há tempos quero estudar como Scala, Haskell e Lisp. Criei um repositório de testes para brincar com essas linguagens no meu github: https://github.com/mauricioszabo/learning. Futuramente, farei posts sobre Scala também, que é uma linguagem interessante para substituir Java.

Comecei também a estudar desenvolvimento para Android. Instalei o emulador, fiz uns “hello, worlds” com Scala, Java e JRuby (Ruboto), o suficiente pra descobrir que rodar algo em Ruboto é inviável de tão lento…
(more…)

By Maurício Szabo, ago

Como eu Entendo BDD

Test Driven Development, ou Behaviour Driven Development… duas “buzzwords” que, só de serem pronunciadas, trazem milhares de sentimentos. Porém, isso não mostra uma cruel realidade:

Poucas pessoas concordam com o que é, de fato, “teste de software”.

Em uma apresentação que fui, no AgileBrazil, com cerca de 150 pessoas na platéia, o apresentador lançou a pergunta: “o que é teste de software para você?”. O experimento era escrever em um papel sua resposta, e trocar com a pessoa do lado. Estranhamente, apenas 5 pessoas, na platéia toda, receberam um papel com uma explicação que batia com a sua.

Então, acho que seria interessante citar o que eu entendo por Teste de Software, e porque eu considero que pratico “Behaviour Driven Development”.
(more…)

By Maurício Szabo, ago

SOLID e SQL

Para os que não conhecem, o princípio SOLID é uma “sigla de siglas”, uma tentativa de formalizar códigos limpos, flexíveis e funcionais principalmente para linguagens orientadas a objeto. Os princípios são Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle e Dependency Inversion Principle. Sendo bem sucinto:

  • SRP indica que todo objeto deve ter apenas uma responsabilidade. Ou seja, fazer uma classe para atender apenas uma função específica.
  • OCP indica que toda classe deve ser aberta para adição de novas funcionalidades, mas fechada para modificação. Ou seja, quando for preciso adicionar mais funcionalidades, isso deve ser feito apenas adicionando novos métodos, sem precisar alterar os que já existem.
  • LSP indica que deve ser possível substituir um objeto por seus filhos, na herança, sem dar problema. Na prática, significa que um objeto filho altera a forma como o objeto pai funciona, extendendo ou não suas funcionalidades, mas nunca alterando o comportamento geral
  • ISP indica que todo código deve organizado de forma que jamais seja necessário implementar métodos que não são utilizados. A idéia é melhor explicada (com exemplos) neste post.
  • DIP indica uma necessidade de depender de classes abstratas, não de classes concretas. Ou seja, ao invés de, em um código, receber num método uma classe concreta, receber uma classe abstrata e, quando o método for chamado, passar uma classe concreta

Ok, e aonde o SQL entra nisso? Ele não é orientado a objeto, não é “turing-complete”, é apenas uma linguagem de busca num banco de dados, certo? E sim, eu tou falando de SQL, não de PL/SQL ou qualquer coisa semelhante. A explicação é muito simples: Clean Code
(more…)

By Maurício Szabo, ago

Closures, Functions e Programação Funcional em Javascript

Estes dias, tive que fazer um código que achei que seria muito complicado, e que deveria rodar num browser. A idéia é que, dependendo do que foi digitado em uma determinada caixa de texto, um pedaço de uma página deveria mudar. Até aí, tudo bem, o problema é que o pedaço que deveria mudar deveria agrupar informações de outras caixas de texto, e outras regras confusas. Achei uma solução muito simples e prática, e gostaria de dividí-la. Mas antes, vamos simplificar o escopo:

Imagine que há uma página, no qual há um botão “adicionar”. Ao clicar nele, ele adiciona um “select” (sexo) e uma caixa de texto com observações ou qualquer outra coisa. Podem ser adicionados tantos elementos como se achar necessário. Para cada elemento alterado, deve ser exibido um sumário na tela de baixo (observações), digamos, concatenando o sexo e as observações. A parte difícil é: quando qualquer elemento for mudado, APENAS o sumário relativo àquele conjunto de elementos (sexo e observação) deve ser alterado, e também, quando eu estiver editando as observações (ou o sexo), o sumário deve ficar em negrito. Para simplificar (e rodar em vários browser) usarei a biblioteca Javascript chamada Prototype (não usarei o JQuery porque seria jogar uma bomba numa mosca), e a idéia é escrever apenas o código relativo às edições (porque é isso que pega). Portanto, para quem quiser, basta pegar o gist do Github http://gist.github.com/658668 para ter um esqueleto do programa (basta abrir o .html em qualquer browser).
(more…)

By Maurício Szabo, ago

Monkey-Patch seguro, em Javascript

Continuando os estudos com Javascript, diversas coisas interessantes, que pareciam acessíveis apenas aos programadores de Ruby, Perl e outras linguagens mais flexíveis podem ser feitas também na linguagem. O problema é que, normalmente, é difícil de usar isso em bibliotecas que já existem, principalmente porque a maioria dos códigos em Javascript ou não seguem boas-práticas ou simplesmente são escritos de forma diferente do que vou apresentar aqui, porém vale pela dica. Um exemplo bem simples, pensando na seguinte API:

objeto = {
  valor: 10,
  incrementar: function(v) { 
    if(!v) v = 1;
    valor += v;
  },
  raizQuadrada: function() {
    Math.sqrt(incrementar(4));
  }
}

Para implementá-la, em Javascript, há várias formas. Simulando o comportamento que eu fiz no post passado, é possível usar o seguinte formato:
(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

FISL – Minha palestra, e Code Golf

Pretendo ainda fazer um resumão do FISL, mas por enquanto vamos a palestra e ao Code Golf.

Durante o FISL, apresentei a palestra “Lapidando Ruby”, um estudo de boas práticas em programas Ruby e em Rails. Basicamente, uma apresentação sobre as diversas práticas que eu percebi que levavam a um código melhor. Como eu disse na apresentação, parte do estudo é que as pessoas discordem de algumas coisas que eu faço. Pela reação do pessoal, acho que muitas pessoas concordaram com a maioria do que eu falei. A apresentação está no slideshare, e está abaixo (nota, que é melhor baixar o arquivo do SlideShare, fica um pouco melhor do que a apresentação que eles colocam lá):
(more…)

By Maurício Szabo, ago

Resumo do Agile Brazil – Segundo Dia

No segundo dia, o evento começou mais tarde devido ao jogo. A primeira palestra que vi foi “Refatoração de Testes”, com Eduardo Guerra. Foi uma palestra razoável na minha opinião, mas achei interessante justamente a preocupação com a refatoração. Um dos pontes fortíssimos da palestra foi a definição das partes de um teste: “Setup” (deixar o programa numa determinada situação), “Assertion” (a verificação propriamente dita), e o “Teardown” (limpar os dados que o programa fez). De acordo com Guerra, o teste pode mudar completamente, mas as “Assertions” devem manter-se íntegras.
(more…)

By Maurício Szabo, ago

Resumo do Agile Brazil – Primeiro Dia

Semana passada, fui ao evento AgileBrazil, promovido pela PUC do Rio Grande do Sul. Foi um evento de quatro dias, embora os dois primeiros tenham sido reservados apenas para mini-cursos (XP, Coaching, etc – infelizmente, quando fiz minha inscrição não haviam mais vagas para estes cursos). Apesar de algumas falhas na organização (eu, particularmente, achei muito ruim o número de palestras simultâneas – no geral haviam quatro palestras ao mesmo tempo, além de Open Spaces entre outros. Achei ruim não ter conseguido participar de nenhum open space, mas é a vida), o evento contou com um nível técnico muito bom, ao meu ver, com palestras extremamente interessantes.

O evento começou com um Keynote do Martin Fowler, no qual ele apresentou três pequenas apresentações. Em uma delas, ele apresentou os perigos da gerência de software da forma como tem sido feito, fora do mundo ágil, apresentando que no passado, o sucesso era definido se o plano inicial foi seguido (o que ele considera um absurdo, pois um sistema pode ter sido bem-sucedido sem sequer ter sido posto em produção). Em seguida, ele citou sobre “Technical Debt”, um termo para indicar quando as boas-práticas são ignoradas, no desenvolvimento de software, em prol de uma série de coisas tal como “precisamos atender o prazo”, etc. Ele cita que tal débito precisa ser cuidadosamente controlado, caso contrário fica a produtividade começa a cair (e cita que o tempo que este débito pode sair do controle é medido em semanas, e não em meses como se achava). Por fim, sua última apresentação falou sobre integração contínua, no qual ele citou como faz seus “deploys”, no qual em cada Commit ele gera um executável que vai para uma bateria de testes (Smoke Tests, e Aceptance Tests), para depois cair em uma segunda bateria (mais Smoke Tests e Performance Tests) para, por fim, ir para produção (com mais Smoke Tests). Citou também o software Cruise, mas não entrou em muitos detalhes.
(more…)

By Maurício Szabo, ago