A melhor linguagem de programação

Eu tenho a felicidade de ter um sogro que trabalha com desenvolvimento de softwares. Ele tem a experiência de já ter sido empresário e de já ter visto de quase tudo nessa área.

Atualmente ele está trabalhando em um projeto para Web e comentou que está dando preferência a uma ferramenta proprietária que eu particularmente não gosto.

Numa conversa que achei muito produtiva, nós concordamos que, independente de gostar ou não, “software é bola na rede”, onde o importante é entregar o produto, atendendo as necessidades do cliente no menor tempo possível.

Eu trabalhei com PHP por dez anos, com Delphi por seis e estou indo para oito com Java, usando diariamente cada uma dessas linguagens. Já tive experiências com C e trabalho há anos com Ruby e JavaScript, atualmente tenho me concentrado em Clojure e, gostando mais de umas e menos de outras, conheço as forças e fraquezas de cada uma delas.

No final das contas, eu gosto da analogia de que o nosso trabalho se assemelha ao de um carpinteiro/marceneiro (desculpe, mas eu não sei muito bem a diferença entre ambos). Esses profissionais usam várias ferramentas para chegar ao produto final e, ao invés de perderem tempo em fóruns e discussões, eles buscam as ferramentas adequadas a cada tipo de tarefa, buscando entregar o melhor produto no menor tempo e menor custo (entenda ‘melhor produto’ como algo totalmente subjetivo).

Linguagens de programação são meras ferramentas, assim como serrotes, limas, martelos e sei lá que outras ferramentas os profissionais da madeira usam.

Assim sendo, o que é melhor? SASS, SCSS, LESS ou CSS puro? HAML ou ERB? A melhor é aquela que trouxer menos dor de cabeça, custo e tempo de desenvolvimento. Avalie com cautela aquilo que “está na moda” ou “que é o padrão de mercado” e escolha o que for melhor para o que você precisa, usando argumentos técnicos e financeiros, e deixando a paixão de lado.

Aprenda a sua linguagem de trabalho a fundo, e procure conhecer alternativas. Ao me tornar um bom desenvolvedor Ruby, eu aprendi a escrever um código Java melhor. Ao entender LISP, eu me tornei mais produtivo em JavaScript.

Quando for escrever ou comentar algo do tipo “Porque PHP fede”, ou perguntar num fórum “O que é melhor: PL/I ou FORTRAN 66?”, procure estudar mais, entender que nem todo mundo vive a mesma realidade que você e mesmo, algumas vezes, nem todo mundo tem o interesse em aprender tanto quanto você.

Às vezes, o que o outro desenvolvedor quer é apenas entregar o trabalho, receber o pagamento e ir para casa.

P.S.: de qualquer maneira, se você quiser e puder, aprenda o máximo de linguagens que conseguir. Eu acho divertido, e profissionalmente é algo que tem me dado bons resultados.

Publicado em questionamento, real world | Com a tag , | Deixar um comentário

O que eu aprendi escrevendo

Apesar de ter um livro e um curso publicados, eu ainda estou longe de ser considerado um escritor. Honestamente, nem ao menos sei o que é necessário para que eu, ou outra pessoa, me considere como tal.

Pretendo escrever outro livro ainda esse ano, mas ainda não tenho nada definido. Escrever um curso ou um livro é algo cansativo, mas muito gratificante. Como não dei espaço entre um e outro, acho que seria bom eu tomar um ar antes de me lançar novamente nessa empreitada.

Seguindo os próprios passos que descrevo abaixo, resolvi separar alguns pontos que considero importantes.

Escrever é um processo iterativo e incremental

O texto não nasce pronto. As vezes uma coisa ou outra está pronta na sua cabeça, mas na hora de colocar no papel a coisa muda. Você esquece algumas partes, lembra de outras, muda a ordem.

O importante é que você coloque suas ideias no papel (ou no site), e depois releia com calma. Mostre para outras pessoas, peça opinião. Eu pensei em um texto por mais de dois anos e publiquei aqui antes de adicionar no livro. O feedback dos leitores foi importantíssimo para que a versão final tivesse o mínimo de erros e o máximo de clareza possível.

Defina bem o seu público

Ao escrever sobre programação funcional em JavaScript, eu tinha bem claro quem é o leitor do 1up. Caso você não tenha definido quem será seu público e quais os requisitos necessários para que possam absorver seu conteúdo, você vai correr o risco de escrever um texto em aramaico para crianças de quarta série ou um texto de quarta série para doutores em línguas mortas.

Pior ainda é quando se tenta abraçar a todos. Seus braços são curtos para abraçar o mundo e, no final, alguma coisa vai acabar caindo no chão.

Trace uma linha

Como o Manifesto Ágil profere, responder a mudanças é mais importante do que seguir um plano, o que não quer dizer que você não precisa de um plano.

Eu costumo traçar um plano, seja como uma lista de tópicos, seja como um mindmap, e vou me guiando por ele até pegar o ritmo. Normalmente essa lista não permanece inalterada por mais de dois capítulos, mas ainda assim é importante você ter algo para te manter no caminho, por mais que esse caminho mude constantemente.

Concentre-se

Eu tenho problemas sérios de concentração, mas em algumas ocasiões consigo despejar quilos de texto ou código de uma única vez. Claro que uma revisão posterior é sempre bem vinda e necessária.

O problema são os culpados de sempre: família exigindo atenção (eles têm prioridade, não pense o contrário); Internet oferecendo todo o tipo de entretenimento; GTalk aberto e seus amigos ali, ao alcance dos dedos.

Escrever é um ato solitário. Lide com isso e concentre-se no que está fazendo.

Arranje tempo

“Eu não tenho tempo” é a desculpa preferida do procrastinador e do cara que quer que os outros acreditem que ele é muito ocupado.

Você tem tempo para conversar no GTalk, para acessar o 9gag, para ver os gols do Fantástico, mas nunca temos tempo para brincar com o filho, para conversar com a esposa (ou marido) ou para fazer aquela meia hora de esteira.

Um terço do meu livro foi escrito dentro de viagens em ônibus, táxis e aviões. Acho que produzi muito mais em uma hora de vôo até o Rio do que em uma tarde inteira jogada fora na frente do computador.

Quando você realmente quer fazer algo, o tempo aparece. Não ter tempo é uma outra forma de dizer “isso não é importante o suficiente para mim”.

‘Pronto’ é melhor do que ‘perfeito’

Depois do livro e do curso prontos e entregues, eu percebi coisas que poderia ter adicionado, frases que poderia ter mudado, assuntos que faltaram. Se existe a possibilidade de adicionar ou mudar, faça, mas não caia na armadilha de ficar polindo algo que já deveria estar em produção há tempos.

Pronto é melhor do que perfeito e, não importa o quanto você tente, seu trabalho nunca vai ficar perfeito.

Divirta-se

Principalmente, divirta-se.

Conheci muitas pessoas que sabem muito mais do assunto que estou escrevendo do que eu, pessoas que deram excelentes sugestões, ideias e me ensinaram a escrever melhor. E em tudo isso eu me diverti, aprendi, aproveitei o momento.

Não se leve tão a sério. É apenas um texto, um post, um curso, um livro. A vida é bem mais do que isso.

Abraço

Publicado em projetos, quick tips, real world | Com a tag , , , , | Deixar um comentário

Novos rumos

Depois de um 2012 movimentado, resolvi tirar minha certificação PMI e, a partir de hoje, trabalho como gerente da fábrica de software de uma conhecida consultoria, líder de mercado.

Pretendo aplicar, de maneira holística, processos definidos e reproduziveis que performem de maneira out of box a sinergia entre o levantamento de requisitos, desenvolvimento no chão de fábrica e posterior envio ao setor de testes, visando a garantia de qualidade do entregável.

=)

Publicado em cascata, novidades da semana, processos, waterfall | Com a tag | 3 comentários

Pair Programming remoto com Screen e Vim

Limitar a produtividade e colaboração interpessoal ao espaço físico de um escritório parece uma idéia cada vez menos viável no ramo de desenvolvimento de software.

Empresas de TI bem sucedidas como 37signals e Github apostam em times e colaboradores distribuídos pelo mundo trabalhando remotamente em seus projetos.

Usando as ferramentas e práticas certas é possível trabalhar remotamente e até mesmo parear com outro desenvolvedor à distância.

Requisitos

  • ssh
  • screen
  • vim
  • skype

Para compartilhar o mesmo “contexto” remotamente, ambos desenvolvedores deverão ter acesso ao mesmo ambiente de desenvolvimento, via ssh. Estando em modo texto, será necessário utilizar um editor compatível, neste caso o VIM.  E para compartilhar o terminal em tempo real, utilizaremos o Screen. Para comunicação, basta utilizar o Skype. Simples não!?

Instalação

Uma vez escolhido o ambiente de desenvolvimento comum (um servidor de homologação, por exemplo), instale o Screen:

$ sudo apt-get install screen

Em seguida, configure as permissões de execução:

$ chmod u+s /usr/bin/screen
$ chmod 755 /var/run/screen

O Screen roda como um daemon, mantendo um buffer da tela. Sendo assim, o primeiro passo é iniciar a sessão do Screen:

$ screen -S nomedasessao

Isso criará uma sessão com o nome “nomedasessao” e será exibido um shell “limpo”, o que quer dizer que você já está conectado a esta sessão. Para verificar, execute:

$ screen -ls
There is a screen on:
        8095.nomedasessao	(19-03-2013 23:32:54)	(Attached)
1 Socket in /var/run/screen/S-user.

A partir de agora, o buffer desta sessão pode ser compartilhado com outro usuário conectado. Basta que seu par se logue no servidor via ssh e execute:

$ screen -x nomedasessao

Pronto! O que você digitar, seu par vai ver e vice-versa. Assim, basta abrir o VIM e começar a parear remotamente.

Para se desconectar da sessão atual, execute:

# screen -d
[remote detached from 8095.nomedasessao]

Usando o Screen

O Screen é simples e poderoso. É possível criar abas (window), dividir a tela (split), rolar a tela (copy mode), etc.

Todos comandos começam com Ctrl + a, em seguida o comando ou atalho. Seguem alguns comandos e atalhos que serão muito úteis do seu dia-a-dia pareando:

Copy mode (scroll)
Inicie o modo de cópia com Ctrl-a + [ (colchete para esquerda)
Navegue pela tela com as setas ou pageup/pagedown;
Marque o início da seleção do texto com <espaço> e termine com <espaço> para copiar;
Cole com Ctrl-a + ] (colchete para direita);

Windows
Crie uma janela (ou aba) com Ctrl-a + c
Liste as janelas com Ctrl-a + ” (aspas)
Altere para a janela com Ctrl-a <numero de 0-9>
Feche (ou mate) a janela atual com Ctrl+a k

Split
Divida a tela horizontalmente com Ctrl-a + S
Divida a tela verticalmente com Ctrl-a + V
Mude de split com Ctrl-a + Tab
Feche um split com Ctrl-a + X

Para digitar um comando: Ctrl-a + :

Consulte o manual do Screen para a lista completa de atalhos/comandos.

Dicas e considerações

Esta é uma abordagem simplista da utilização do Screen. Deixei vários detalhes de fora do post para tentar ser o mais didático possível. Para informações mais completas como configurações, gerenciamento de sessões e usuários, consulte o manual oficial.

Existem outras alternativas como o tmux, mas o conceito envolvido é o mesmo apresentado aqui.

Se você estiver programando em Rails, provavelmente precisará de 3 contextos: console, server e editor (Vim). Recomendo utilizar cada contexto como “window” na mesma sessão do Screen.

Utilize o Skype (ou outro voip de sua preferência) durante todo o tempo em que estiverem pareando e estabeleça intervalos. Pomodoro pode ser uma boa opção.

Dúvidas, críticas ou sugestões nos comentários. Sucesso!

Referências

http://www.linux.com/learn/tutorials/442418-using-screen-for-remote-interaction
http://linux.die.net/man/1/screen
http://aperiodic.net/screen/quick_reference

Publicado em quick tips, real world, tutorial, web | Com a tag , , , | Deixar um comentário

O ano em que eu tirei a bunda da cadeira

TL;DR: 2012 foi o ano em que eu publiquei um curso num grande portal de tecnologia, palestrei em eventos relevantes e ministrei um curso em um lugar que eu mal conhecia no mapa.

De alguns anos para cá, passei a escrever uma pequena lista de metas para o ano seguinte e percebi que o simples fato de haver uma lista já era o suficiente para que eu não perdesse totalmente o foco.

A criação de uma lista, pequena, concisa, realista, também traz motivação para cumprir novas metas a cada vez que você completa algum dos itens. É a estratégia de alimentar o cérebro com pequenas recompensas para continuar em frente, como acontece num jogo.

Há pouco mais de dois anos, escrevi aqui um post em que eu dizia que deveríamos parar de chorar e reclamar e começar a correr atrás de nossos objetivos. Escrevi aquele texto especialmente para mim, como se uma parte do cérebro estivesse dando uma bronca na outra parte. Demorou, mas acho que a bronca fez efeito.

Usando a lista de metas, mesmo sem muita disciplina, consegui ir além do que eu previa, sendo que passei a considerar 2012 como o ano em que parei de reclamar, tirei a bunda da cadeira e as coisas começaram a acontecer.

Em 2011, resolvi que queria tentar participar de eventos como palestrante. Sempre tive dificuldade de falar em público e apresentar idéias, e achei que essa seria uma boa forma de corrigir essas limitações.

Em 2012 eu continuei, tanto para apresentar algum tema que eu considero interessante, como também como ferramenta de marketing pessoal. Tanto quanto ser competente e fazer um bom trabalho, é importante ver e ser visto.

Em Maio, apresentei um talk de 30 minutos, no 23º encontro do GURU-SP, demonstrando a simplicidade do LISP usando Clojure.

Em Agosto, para minha total surpresa, fui convidado a apresentar um lightning talk no QCON-SP, onde falei sobre todos os sabores conhecidos de Ruby e dialetos, incluindo o Elixir. Apresentar um tema em cinco minutos é como fazer um show de Punk Rock, e a adrenalina de ambos é sempre bem vinda.

Em Outubro, foi ao ar o meu curso Ruby on Rails do começo ao fim, pelo portal de cursos do iMasters. O curso nasceu como um tutorial que fiz para ajudar algumas pessoas próximas e acabou se tornando algo que me ajudou a conhecer mais pessoas.

Um dos frutos que colhi com esse curso foi o convite para palestrar e ministrar um treinamento durante a IV Semana de Engenharia do Norte do Espírito Santo, no campus do CEUNES/UFES, em São Mateus – ES, que aconteceu em Novembro. Um efeito colateral muito bem vindo dessa minha ida ao Espírito Santo foi a criação do Grupo de Usuários Ruby-ES, um irmão caçula do GURU-SP.

Ainda em Novembro, fui convidado a participar do evento 7masters Java, organizado pelo iMasters, no qual tive a honra de dividir o espaço com pessoas que eu admiro há anos, como Bruno “JavaMan”, Luca Bastos e a dupla dinâmica qmx/abstractj. Lá falei sobre os usos do Clojure no mundo real e compartilhei a experiência que tive em um projeto, utilizando a ferramenta.

Fechando o ano, tive meu livro Dominando JavaScript com jQuery publicado pela Editora Casa do Código. Aliás, a versão impressa do livro foi disponibilizada hoje no site. Agora só me falta plantar uma árvore.

Em breve, pretendo compartilhar minhas experiências ao escrever o curso e o livro.

Que mais realizações venham em 2013, e que os frutos do que plantei continuem nascendo, mesmo que dessa vez eu não tenha feito nenhuma lista de metas a cumprir.

Publicado em eventos, real world | Com a tag , , , | 2 comentários

Programação funcional com JavaScript

“JavaScript is LISP in C’s clothing” – Douglas Crockford

O que é programação funcional

Programação funcional é, assim como a orientação a objetos, uma forma de se pensar em como resolver problemas.

A base do que hoje é a programação funcional foi criada paralelamente por Alan Turing e Alonzo Church na década de 1930, antes mesmo da existência dos computadores como o conhecemos.

Infelizmente, a programação funcional passou muito tempo restrita aos meios acadêmicos, o que faz com que o iniciante no assunto fique assustado com toda aquela notação matemática e com os termos incompreensíveis.

ω := λx.x x
Ω := ω ω 
Y := λg.(λx.g (x x)) (λx.g (x x))

Felizmente, o conceito de programação funcional é muito simples. Assim como na orientação a objetos a menor parte de um sistema é um objeto, você pode atribuir objetos a variáveis, pode passá-los por parâmetro e ter métodos retornando objetos, na programação funcional a menor parte do seu sistema é uma função.

Isso implica que você pode atribuir funções a variáveis, pode passá-las por parâmetro e mesmo fazer com que uma função retorne outra função. Alguma linguagens implementam também imutabilidade, que é quando todo valor é tratado como se fosse uma constante, e outros conceitos periféricos, o que não é o caso do JavaScript. Todos os demais conceitos de programação funcional derivam do fato de você lidar com funções como se fossem um valor como qualquer outro.

High order functions

Uma high order function (não achei uma tradução decente para o Português), apesar do nome intimidador, é simplesmente uma função que recebe outra função como parâmetro ou devolve uma função como resultado. Quando você usa callbacks no JavaScript e no jQuery, você está fazendo uso de high order functions.

$("button.mallandro")
  .click(function() {
    alert("Ié ié!");
  });

O método click é uma high order function, e a função anônima que faz Ié ié! é um callback.

Mais para frente vou mostrar mais formas de usar high order functions.

Escopo

Apesar do conceito de escopo não ser exclusivo da programação funcional, é importantíssimo que você entenda como funciona o escopo no JavaScript para que não fique confuso ao ver closures e currying.

Como na maioria das linguagens comerciais, uma variável declarada em um escopo maior é visível em um escopo menor, enquanto o contrário não é verdadeiro.

Na prática significa que uma variável global é visível por todo mundo:

var x = 1;
 
function foo() {
  console.log(x);
}
 
foo();
 
// Saída:   1

Significa também que uma variável local só é vista dentro do escopo em que foi criada, mesmo que tenha o mesmo nome de uma variável global:

var x = 1;
 
function bar() {
  var x = 99;
  var y = 42
 
  console.log(x, y);
}
 
bar();
// 99 42
 
console.log(x);
// 1
 
console.log(y);
// ReferenceError: y is not defined

Quando uma função altera o valor de uma variável global, isso afeta toda a aplicação. Por isso o uso de variáveis globais não é considerado uma boa prática. Porém, uma variável global passada por parâmetro para uma função não tem o seu valor alterado:

var x = 1;
var y = 11;
 
function meh(x) {
  console.log("Dentro: ", x, y);
  x++;
  y++;
  console.log("Dentro: ", x, y);
}
 
meh(x);
// Dentro:  1 11
// Dentro:  2 12
 
console.log("Fora: ", x, y);
// Fora:  1 12

Closures

Outra característica do escopo é que uma função guarda as variáveis do contexto em que foi criada. Isso significa que uma função pode continuar acessando variáveis que só existiam no momento em que ela foi criada.

function counter() {
  var x = 0;
 
  return function() {
    return ++x;
  }
}
 
var count = counter();
 
console.log(count());
// 1
console.log(count());
// 2
console.log(count());
// 3
console.log(count());
// 4
console.log(x);
// ReferenceError: x is not defined

O que acontece aqui é que count recebe uma função que incrementa o valor da variável x, só que essa variável existe apenas dentro da função counter. O que aconteceu aqui é que a função armazenada em count se lembra da variável que foi criada em outra função, mas que não está mais sendo executada.

Ao tentarmos exibir o valor da variável x, recebemos um erro, pois ela não existe no escopo global.

Currying

Juntando tudo o que vimos até aqui sobre high order functions, escopo e closures, chegamos ao currying. Currying é uma operação em que você transforma uma função que receberia mais de um parâmetro em uma série de chamadas de funções com apenas um parâmetro cada.

Um dos usos dessa técnica é evitar, de forma elegante, que o mesmo parâmetro seja passado para a mesma função.

Vamos pegar um exemplo escrito de forma imperativa. Temos uma função hey, que recebe os parâmetros texto e nome e, a partir disso, imprime uma saudação.

function hey(texto, nome) {
  console.log(texto + ", " + nome);
}
 
hey("Bom dia", "João");
// Bom dia, João
 
hey("Bom dia", "José");
// Bom dia, José
 
hey("Bom dia", "Nicolau");
// Bom dia, Nicolau

Você pode dizer que poderíamos guardar “Bom dia” em uma variável. Concordo, mas isso não mudaria nada dentro do que estamos apresentando.

Reescrevendo a mesma função usando currying, teremos o código abaixo:

function hey(texto) {
  return function(nome) {
    console.log(texto + ", " + nome);
  }
}
 
var bomDia = hey("Bom dia");
 
bomDia("João");
// Bom dia, João
 
bomDia("José");
// Bom dia, José
 
bomDia("Nicolau");
// Bom dia, Nicolau

Programação funcional é muito mais do que os conceitos que apresentei aqui, mas como um primeiro contato já dá para fazer muita coisa bacana.

Recomendo que você estude e pesquise a respeito. Mesmo que você não use uma linguagem funcional no seu dia-a-dia, o fato de conhecer um novo modo de pensar acaba alterando a forma como você resolve problemas, fazendo com que você tenha idéias melhores e mais elegantes.

Update em 26/02:

Este artigo foi publicado também no iMasters, no endereço http://imasters.com.br/front-end/javascript/programacao-funcional-com-javascript/.

Esse texto é parte do livro Dominando JavaScript com jQuery, publicado pela Editora Casa do Código.

Publicado em tutorial | Com a tag , | 2 comentários

HTTP Monkey – lançado!

HTTP Monkey é um cliente http simples, com interface fluente, suporte a múltiplos adapters (Net::HTTP, Curb, HTTPClient, EM-HTTP-Request) e middlewares no estilo rack.

Pontos positivos:

Pontos negativos:

  • Gem nova. Ainda não tem um case em produção.
  • Falta de middlewares para funcionalidades como Cache, OAuth … etc.
  • Não suporta adapter que permite requisições em paralelo.
  • Tem o Faraday como concorrente, que tem base em produção e bastantes middlewares.
  • A comunidade nacional e internacional ainda não conhece o Monkey (comecei agora a trabalhar nisso).

Na página HTTP Monkey an alternative to Faraday, comecei um trabalho de “localizar” o desenvolvedor que está acostumado com o Faraday em como trabalhar com o Monkey. Lembrando que a DSL do HTTP Monkey, foi feita pensando em substituir o uso do Restfulie, muita usada nos projetos da Abril Mídia.

Tem também uns slides que apresentei na Abril em alguns tech talks.

 

 

Valeu e aceito numa boa sugestões e críticas referentes ao projeto, por favor comentem! :D

Publicado em marketing, projetos, real world, ruby, web | Com a tag , , , , | Deixar um comentário

Nos idos de 2012, UML, Design e Waterfall

Há alguns anos atrás não havia uma referencia forte e consistente sobre os processos de desenvolvimento de software que não fosse Waterfall. Embora movimentos ágeis, processos mais simples e eficazes venham sendo utilizados a muito mais tempo, eles não eram tão evidentes como agora.
Independente do processo ágil discutido Scrum, Lean, XP e etc, etc, etc… o movimento para remover as velhas e engessadas práticas de desenvolvimento de software cresce vertiginosamente e começa a movimentar grandes empresas, que ainda amarradas e processos internos pesadíssimos, entendem que algo precisa mudar para se conseguir maior flexibilidade e agilidade ao entregar novos serviços e funcionalidade a seus clientes, e obviamente, estar à frente da concorrência.

Em meio a corrida do novo ouro, me encontro em uma sala de treinamento, às vesperas de um novo ano, estudando, discutindo e demonstrando como analisar e modelar sistemas utilizando a mais famosa linguagem de modelagem: a UML.
Nunca consegui traçar uma ligação saudável entre os modelos criados com UML e código funcionando em produção. A idéia principal da UML é a de comunicar aos envolvidos em um projeto o que se planeja implementar; quais os detalhes que norteiam o desenvolvimento de uma solução e que requisitos funcionais e não funcionais devem ser implementados. O problema é que qualquer coisa diferente de código no desenvolvimento de sistemas, está fadada a diferentes interpretações, ao conhecimento e experiência de quem produz e consome tais artefatos.

A idéia de times multidisciplinares e autogerenciáveis trazida pelo movimento ágil distoa fortemente do modelo cascata, que delinea claramente o papel do analista de negócios/requisitos, o arquiteto/designer da solução e os pobres desenvolvedores que terão de seguir à risca todas definições impostas pelos modelos produzidos. E se durante o ciclo ágil os problemas identificados são priorizados para serem endereçados no próximo ciclo, como o processo formal gerencia isso? Hum… daí vem minha maior crítica quanto ao uso de modelos no desenvolvimento de software. Já que se decidiu por engessar o processo, seguí-lo fielmente deveria ser o preço a ser pago para manter tanta parafernalha de artefatos sem valor. Identificado o problema, o fluxo deveria voltar lá no início e corrigir requisitos, modelos, código e testes; mas o mercado não permite tanta demora, as linhas de negócio precisam colocar seu produto na prateleira e o fluxo controladamente perfeito que outrora se desenhou, na vida real não funciona mais.

É inviável manter a “documentação” do sistema em face a uma concorrência e volatilidade de negócios tão vorazes, então eu me pergunto: O que aquelas pessoas estavam fazendo trancadas numa sala, consumindo o tempo a um alto custo da sua empresa? Aprendendo a como não fazer? Pode ser. Constatando uma vez mais que embora no papel, no processo, tudo aquilo que a teoria diz é muito bonito e controlado mas não funciona no mundo real? Sim, pode ser também, mas o pior é que passados anos de experiências ruins, projetos fracassados e montanhas de dinheiro jogados no ralo, ainda terão coragem de propor um processo baseado em requisitos → modelagem → desenvolvimento → testes, faseados e interdependentes, ignorando o histórico de dores e prejuízos experimentado.

Publicado em projetos, real world, waterfall | Com a tag , | Deixar um comentário

Rails 4 – Novidades

O Rails 4 já está em desenvolvimento faz um tempo, na verdade um bom tempo, desde 20/Dez/2011, olha o commit do DHH aqui. No Ruby on Rails guides do edge, já tem muita coisa documentada do que vem por aí.

Segue um resumão:

  • Suporte somente a ruby 1.9.3 ou superior
  • Vendor/Plugins já era
  • Muita “magia” movida pra gems \o/ (Dynamic finders, Mass assignments, AR Session Store, ActiveResource … e muito mais)
  • Interface de Queue
  • Asynchronous Mailer
  • ActionController::Live
  • HTML5 tag helpers
  • Threadsafe on by default

O Santiago Pastorino, um dos commiters do Rails está mantendo um ótimo post sobre o desenvolvimento do Rails 4, que vale a pena acompanhar.

Sucesso!

Publicado em rails, real world, ruby, web | Com a tag , , | Deixar um comentário

MinionServer – a real server to mock servers!

MinionServer is a ruby gem to help you with integration tests. You can create an app using Rack Builder and start a tiny server very easy. Let me show you some code:

require 'minion_server'

# build your integration app
IntegrationApp = Rack::Builder.new do
  map "/" do
    run lambda { |env|
      [200, {"Content-Type" => "text/plain"}, ["Be happy!"]]
    }
  end
end

server = MinionServer.new(IntegrationApp)
server.start("localhost", 1620)  # default: localhost, 4000

# do your calls
system "curl http://localhost:1620" # => "Be happy!"

server.shutdown

You can see more examples at http_monkey‘s integration tests.
Hope that helps!

pt-br moment: Está em inglês porque eu publiquei no coderwall e depois tive a idéia brilhante de postar aqui, com a preguiça mais brilhante ainda de traduzir em pt-br.

Publicado em quick tips, rails, real world, ruby, web | Com a tag , , , , , , , | Deixar um comentário