Archive for January, 2008

Entrevista sobre Domain-Specific Languages

Tuesday, January 29th, 2008

O Laércio Queiroz me entrevistou sobre DSLs. O resultado você vê no blog dele.

Congratulações Atrasadas

Tuesday, January 29th, 2008

Acho que deu ara perceber como minha vida anda corrida. Além do fato de eu ter começado todo post recente com essa mesma ladainha creio que dê para imaginar o trabalho que dá mudar de idioma, continente e empresa de uma vez só. No meio do caminho eu esqueci de fazer uma coisa: dar os meus mais sinceros parabéns ao Tiago Peczenyj.

O Tiago começa na Globo.com estes dias mas o parabéns não é pelo emprego. Apesar de realmente gostar da empresa e das pessoas com quem ele vai trabalhar -e principalente saudades de comer pastel de queijo no chinês 4pm- a evolução do Tiago foi sensacional. Impressionante o que se consegue com um objetivo claro. Espero encontrá-lo para um chopp no downtown em algum momento.

Você Pergunta: RAD

Thursday, January 24th, 2008

Uma pessoa me escreveu um email sobre o tópico anterior. Novamente não vou citar nomes porque não pedi permissão (e não tenho motivos para expôr esta):

Shoes, beleza cara?

Então, lendo sobre a discussão sobre o Maker eu cheguei no seu blog e li sobre RAD.
Aquela ferramenta no NetBeansLixo pra fazer GUIs é um RAD? Ele desenvolve parte de um software, eu sei, não é um modelo de processo de desenvolvimento, né??

Enfim, acredito que existam mais algumas por aí como Maker e queria saber da sua opinião: todas essas ferramentas são RADs e todas elas cometem gafes? Onde quero chegar é na pergunta: Hoje em dia, SEMPRE teremos um desenvolvedor por trás da solução?

É que eu sou totalmente contra essas ferramentas de gerar códigos automáticos… não confio muito nessas coisas… prefiro eu mesmo fazer os códigos, mas tenho a dúvida: estou muito antiquado (no sentido de muito atrasado e não acompanhando as tecnologias que estão evoluindo hoje) ou estou no caminho correto?

Bom, se você respondeu que sim na primeira pergunta (do NetBeans sobre GUIs), a principal desvantagem das ferramentas RAD (se é isso que aquele Lixo é) é a manutenção e evolução, certo? Uma vez, fazendo um trabalho pra faculdade, tive que usar aquele NetBeans. Quando fui usar Refactoring… nossa cara, que coisa mais chata… tive que refazer praticamente toda a interface gráfica.

Abraço.

Apesar de usar, eu odeio o termo RAD. Ele significa um grupo enorme de coisas e ao mesmo tempo não significa nada. O livro Software Development: Building Reliable Systems define RAD:

For the last ten years, many software projects have incorporated the use of “Rapid Application Development” methodologies in an effort to decrease development times. RAD, as it is generally referred to, incorporates an umbrella of methodologies based on spiral, iterative development technologies. RAD techniques range from the simple use of GUI development tools to quickly build prototypes, to processes incorporating complete, cross-functional business analysis. [...]

Então vou considerar que você quer dizer por RAD “ferramentas geradoras de código” do contrario este post nunca vai acabar. Sim, o Matisse do Netbeans é uma ferramenta geradora de código.

Ferramentas geradoras, em geral, são úteis quando não querem dominar o mundo. Eu adoro quando o Hibernate ou o Rails gera meu DDL SQL e eu não tenho que escrever CREATE TABLE. Eu adoro quando o Eclipse gera meus getters e setters e coisa do tipo. O problema é que esses geradores não costumam sobreviver num projeto de verdade.

O grande problema do gerador de código padrão, como o citado, é que ele possui diversos vazamentos de abstração. O Joel Spolsky fala especificamente sobre geradores:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

Como pode-se perceber pelas discussões citadas o mercado destas ferramentas é… complicado. Um desenvolvedor que entende como a plataforma funciona (Java EE, no caso) dificilmente se encantaria pela ferramenta. Ele pode utilizar algo como um Spring IDE para gerar arquivos de configuração mas sabe que isso não é tão simples assim.

Os programadores mais recentes na plataforma Java podem não ter consciência disso mas uma ferramenta chamada xdoclet era muito usada quando sofríamos diariamente com EJBs 2.1. O que o xdoclet faz é gerar código, ele gerava todo o mapeamento do EJB (uns 3 arquivos XML diferentes, pelo menos) a partir de anotações JavaDoc (não existia Java 5 naquela época). O xdoclet era a salvação da lavoura, conseguia abstrair muitos problemas mas.. não era perfeito, nem pretendia.

Eu já trabalhei em projeto onde 50% do código era gerado pelo xdoclet e do restante ele não dava conta. A ferramenta não possui o tal do round-tripping então não dava para misturar código gerado com modificado. A solução foi optar por uma arquitetura que isolava as duas partes em módulos diferentes e só conseguimos chegar até ela porque –como disse o Joel- sabíamos como a ferramenta funcionada. Essa é uma ferramenta de automação, não de “geração automática de sistema”. Ela automatiza o trabalho que você teria, não te livra do fato de conhecer o que… bem… é sua profissão.

Acho que o Matisse se enquadra neste tipo.

O problema é que essas ferramentas –e seus persuasivos vendedores- dizem que irão abstrair todo o desenvolvimento. Para os cenários ideais elas podem fazer todo o prometido mas não houve até hoje uma ferramenta que conseguisse real sucesso fora dos casos mais simples e isso porque não é assim que construímos sistemas hoje. Nossos sistemas são uma salada de linguagens, conceitos, mapeamentos e configurações que uma ferramenta deste tipo não consegue acompanhar.

O que geralmente elas fazem é te prender à uma ou algumas arquiteturas genéricas que servem razoavelmente para alguns casos -geralmente sitezinhos CRUD de intranet- mas não para todos ou sequer para a maioria. Como arquitetura não é commodity não se pode simplesmente aplicar a mesma estrutura em todos os cenários.

Apos algum tempo em TI você começa a entender que o dia-a-dia desse mercado é um grande “mais do mesmo”. Você sempre está criando as mesmas coisas. Da última vez que contei eu já tinha criado uns sete gerenciadores de conteúdo web. Dá para utilizar a mesma arquitetura em todos? Não. Uns eram simples formulários, outros se integravam com back-ends complicados, outros era assíncronos, outros tinham integração com legado… cada um tinha uma história. Se há oito anos atrás eu comprasse uma ferramenta dessas e a tivesse aplicado nestes projetos eu teria que fazer personalização (i.e. sair do maravilhoso mundo do fluxograma) a cada projeto.

Mas eu estou falando de desenvolvimento de software de um tipo, não do mercado todo. Quando estive na faculdade pela última vez (antes da segunda fuga) estudei com uma pessoa de 43 anos que desde os anos 80 vive fazendo software em coisas como CLIPPER para lojinhas e boutiques. Ele não ganha mal. Pelo que entendo dos softwares deste tipo (já trabalhei neste ramo) a arquitetura é quase sempre a mesma. Talvez ele se favorecesse de algo assim nos seus negócios, apesar de que eu ainda acharia um risco desnecessário.

Então sim, hoje precisamos de desenvolvedores para projetar um sistema. Desenvolver sua arquitetura, seu design e verificar para que tudo seja eito da maneira mais adequada para o projeto (que nem sempre é a técnica mais adequada). Mas e o futuro?

O futuro prevê o uso de ferramentas de um nível mais alto, mas de maneira diferente. O ponto crucial é que essas ferramentas não são geradores de código Java (ou C#, ou Ruby ou o que for), elas mudam a visão sobre o código. Ferramentas como Domain-Specific Languages aumentam o nível da linguagem não tornando-a mais abstrata apenas mas sim levando para perto do negócio. Ferramentas de visualização criam pontos de vista diferenciado sobre o mesmo artefato, dependendo de com que olhos se enxerga.

Tudo indica que para desenvolver softwares no futuro o desenvolvedor não terá o mesmo papel que tem hoje. Ao invés de criar o código do sistema em si iremos criar as ferramentas que dão suporte à criação de sistemas pelos usuários.

Seja qual for o futuro ele não é sobre gerar código. Isso nós já fazemos à décadas e serve apenas como quebra-galho para nos livrar da complexidade que nós mesmo criamos.

Problemas nos Acentos

Wednesday, January 23rd, 2008

Muita gente reclamando de problemas nos acentos no feed. A data do início dos problemas parece coincidir com quando eu comecei a usar o Mac, hoje chequei todos os feeds, do WordPress e feedburner e todos estão setando o conteúdo curretamente para UTF-8.

Não tenho idéia sobre o que pode ser :( Estou procurando respostas, se alguém possuir alguma dica avise.

Follow-Up

Tuesday, January 22nd, 2008

O Guilherme Chapiewski postou um texto legal sobre entrevistas. No meu tempo na Globo.com nós começamos umas estratégias ‘diferentes’ e o pessoal está evoluindo a abodagem. Leitura obrigatória.

Programação RADioativa

Sunday, January 20th, 2008

Há alguns anos, quando era consultor independente, eu fui chamado por uma empresa bem grandinha do ramo de telefonia. Eles tinham produtos em C++ e queriam migrar para o Java. Na verdade já haviam migrado, mas estavam com problemas.

A primeira tentativa deles foi transferir toda a parte gerencial do sistema -que era vendido por alguns milhões de Euros- para Java. Para fazer esta etapa eles haviam contratado há um ano uma consultoria especializada canadense. Os canadenses sugeriram a compra de uma ferramenta RAD -por um acaso de outra empresa canadense- que permitiria que os desenvolvedores C++ criassem a aplicação em pouco tempo. Em três meses, tempo recorde, a aplicação já estava rodando no cliente, em produção. Durante os testes eles verificaram que a coisa era muito lenta mas como o mercado de telefonia tem muito dinheiro eles simplesmente aumentaram o número de máquinas.

A coisa foi passando até que alguém foi fazer a primeira manutenção. O sistema era um grande catálogo de assinantes, dependentes e registros de ligação, as regras pesadas mesmo ficavam no sistema em C++. As primeiras manutenções foram correção de bugs. A ferramenta funcionava dentro do Eclipse, você definia um modelo de entidades parecido com o modelo relacional, depois dizia quais operações precisava (criar, ler, listar, etc.), isso gerava o código. Se você precisasse de uma regrinha de negócio diferente, digamos que cada vez que um novo cliente fosse adicionado alguém recebesse um email, ia ter que alterar o código gerado. Como a aplicação -como todas- tinha suas peculiaridades muito código era escrito a mão. Mesmo assim o ato de criar toda a infra-estrutura (o scaffolding) poupava muito tempo.

Qual não foi a surpresa quando alguém reparou que a ferramenta só gerava código, ela não o lia de volta? Se você alterar o código e fizer alguma alteração o fornecedor deu duas escolhas:

  1. Alterar o código usando a ferramenta gráfica, regerar o código e depois adicionar novamente nossas alterações
  2. Abandonar a ferramenta e fazer tudo no código

Neste ponto que eu fui chamado. O fornecedor sugeria fortemente a segunda opção, por incrível que pareça. Eu concordei com eles, recomendei ao cliente que assumisse o prejuízo de ter escolhido uma ferramenta ruim e refatorasse o sistema enquanto inseria novas funcionalidades.

O mundo adora ferramentas RAD. Elas provocam a ilusão de que você não precisa de conhecimento ou de um profissional para criar programas. Não é assim que a banda toca.

Essas ferramentas surgem todos os anos. Todos se dizem revolucionários, quase nenhum diz que é um gerador de código, e todos dizem que servem para 87% dos casos. Puro marketing.

Geradores deste tipo existem há décadas. É até engraçado que o mais novo representante desta leva se gabe de ‘revolucionar’ usando o conceito de programação visual por fluxograma. Ahm? Isso existe praticamente desde que surgiram IDEs gráficas. Qualquer coisa que gere código via UML vai ter um fluxograma. A diferença é que não vai ter só fluxogramas, exatamente porque essas coisas foram abandonadas.

Na UML utilizamos o diagrama de atividades para um fim muito específico: representar transição entre estados dos objetos. É um dos diagramas mais raramente utilizados em um projeto OO simplesmente porque ele é procedural demais. Um sistema OO foca na interação entre objetos, não em algoritmos em si -que estão encapsulados dentro dos objetos.

Ao utilizar um fluxograma como unidade principal do seu sistema você está abandonando a OO. Isso pode ser uma coisa boa, depende do caso. para sistemas genéricos décadas de pesquisa da indústria apontam que Orientação a Objetos traz os melhores resultados na modelagem de negócios. Para um caso específico (BPM por exemplo), fluxogramas podem ser melhor. Estas ferramentas vendem trinta anos de retrocesso em modelagem.

Ainda assim, elas oferecem um bom scaffolding, não? Você não precisa saber nada sobre arquitetura, basta gerar o código na ferramenta! Bem, não exatamente. A maioria destas ferramentas vai seguir o exemplo acima: possuem poucos pontos de extensão e quando possuem não conseguem se integrar a eles. A primeira pergunta a fazer para um fornecedor desses é se a ferramenta suporta round-tripping. Round-tripping é o ato de gerar o código na ferramenta, editar o código e a ferramenta ser capaz de lidar com o código alterado. Quase nenhum RAD possui esta característica.

Outro problema é a arquitetura. Eu tenho certeza que uma arquitetura web simples pode ser utilizada por 87% dos casos mas tenho mais certeza ainda que cada um destes casos vai evoluir de uma maneira diferente. A arquitetura tem que ser flexível o suficiente para permitir todas estas formas de evolução. Obviamente que nenhuma destas ferramentas oferece nada parecido. Nós já vimos antes sobre o problema de se estabelecer uma arquitetura única para tudo, o problema com estas ferramentas é muito pior. Quando se define uma única arquitetura para todos os sistemas de uma empresa é ruim mas o que estas empresas estão vendendo é uma arquitetura única que funcionaria em diversos tipos de aplicações de diversos domínios sem sequer saber as necessidades delas antes.

Infelizmente em busca do cálice sagrado as empresas e -pior ainda- governos vão continuar gastando dinheiro nestes engodos. Eles prometem inovação mas fazem retrocesso de três décadas no tempo. Como conseguem montar um CRUD em 30 minutos são vendidos como a última bolacha do pacote, e lá vão os gerentes desinformados comprar estas coisas.

Se você está procurando este tipo de ferramenta esqueça qualquer um desses produtos ‘revolucionários’. Para começar entenda que a Ciência da Computação ainda não tem uma resposta definitiva para você. Sinto muito, estamos trabalhando nisso (é uma das partes da minha pesquisa). O campo mais avançado nesta área chama-se MDA. Eu não acredito em MDA mas isso não me faria negar que ela é a proposta mais plausível para este tipo de ferramenta atualmente. MDA possui implementações livres e proprietárias, é um padrão do OMG, utiliza UML, é baseado em um conceito de transformação de modelos e não de geração de código, é extremamente extensível e pode ter as características de produtividade dessas ferramentinhas de garagem. Só não baseie sua estratégia nele.

Os problemas de MDA: (1)ele eleva o nível de abstração mas não gera programação intencional e (2)ele usa uma ferramenta que não foi criada para isso, UML. São problemas muito menores do que os que você vai enfrentar com estes softwares ‘revolucionáros’ de ‘programação por fluxograma’.

Não caia no conto do vigário.

Quando eu crescer quero ser Analista de Sistemas

Tuesday, January 15th, 2008

Este tópico está na minha fila de posts há meses, hora de sair algo. Eu vou me basear num e-mail que recebi de uma pessoa do GUJ (cujo nome não será mencionado pois não pedi autorização para tal):

Sobre o “polêmico” manjado tópico de que o java pode acabar.

Você postou o seguinte (na primeira página):

Software é programar. Se você que gerenciar uma equipe de desenvolvimento você tem que estudar matérias relacionadas à gestão de pessoas. Isso não é uma evolução do programador, um desenvolvedor de software é sempre um desenvolvedor de software.

Será que alguém que se forma em Ciência da Computação (como eu, se Deus quiser) não consegue o cargo de gerência de equipe? Eu vejo isso pelo meu tio… ele é formado em Engenharia Química e hoje é gerente de um empesa aqui, mas porquê? Porque ele conhece como as coisas funcionam… todo gerente que conheço ou que já ouvi falar aconteceu o mesmo… gerentes de supermercado geralmente sabem tudo o que se passa dentro do maldito mercado! Concorda? Logo, começa-se como programador, pra depois passar pra cima. Ou não? Você já foi programador? Estou em dúvida porque parece que o salário de um programdor (caso eu seja programdor pra vida inteira, que é algo que eu não quero) é baixo e não dê pra sustentar uma família, entende? Da maneira que eu digo faz parecer que eu não quero ser programador JAMAIS, mas eu quero… putz, amo programar, tenho um tesão gigantesco por programação… mas o problema é se vai me sustentar bem e minha família pro resto da vida, entende? Acredito que se um dia eu chegar a um cargo que não envolva programação eu ainda assim vou programar, pra me divertir mesmo.

E aí, o que você acha?

Este é um problema bem grande. Vamos começar sobre algo que não está explícito no e-mail acima mas que existe: aquilo que alguns chamam de analista de sistemas.

Quando eu estava na faculdade pela primeira vez (ou seja: antes de abandoná-la pela primeira vez) lembro de ter aula com um daqueles professores com anos de COBOL nas costas. Ele se lamentava sobre como o mercado confundia analistas e programadores e como estava surgindo a bizarrice do ‘progranalista’- alguém que combinava os dois papéis. Na comunidade em geral você vê este pensamento, eu tenho muitos conhecidos que querem ser ‘analistas’, e isto para eles significa desenhar UML ou fluxogramas que são passados para os programadores.

Creio que já tenha escrito sobre este assunto neste blog mas, resumindo, não há justificativa para este papel existir no desenvolvimento de sistemas nos últimos dez anos. O papel do analista seria, teoricamente, converter um modelo abstrato (de negócios) em um modelo lógico, geralmente expresso de forma gráfica. O modelo lógico então passa a um modelo físico, que é a implementação.

Agora vamos analisar o caso de uma plataforma moderna de desenvolvimento como Java, .Net ou Ruby - ‘moderna’ aqui significando algo como “inventada nos últimos dez anos”. Um modelo abstrato é composto por conceitos de negócio. Geralmente estes conceitos não possuem uma estrutura que um computador entenda, logo o analista vai traduzir este conceito em lógica, provavelmente usando UML. Ora, UML é apenas uma notação gráfica para classes e objetos, e sua linguagem favorita já trabalha com classes e objetos! A tradução entre um modelo lógico e o modelo físico é desnecessária: o modelo lógico já é o modelo físico. A diferença é que UML não executa, por mais que os evangelistas de MDA cismem do contrário.

A solução? Modele em código. Caso seja necessário gerar diagramas basta utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.

“Analista de sistemas” é algo que não existe. Pode ter existido um dia, não sei, mas não faz mais sentido há muitos anos. O modelo lógico é expresso em linguagens de alto nível que modelam muito bem o negócio: Java, Ruby, C#… Quem converte o lógico em físico é o compilador, que traduz as abstrações em código de máquina.

Alguém colocar na sua assinatura de e-mail ou ter a carteira assinada (como eu já tive!) como “Analista Java” está se enganando e colaborando para a criação de papéis que só existem na burocracia das empresas e das pessoas.

Ok, sem diagramas de objetos então, mas e a parte do papel do analista de resolver problemas de negócio? Sinto informar mas se você fazia isso como parte das suas tarefas de “analista de sistemas” você estava ou se enganando ou enganando seu cliente. É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema, mas isso não é papel de analista de sistemas, é papel de analista de negócios.

Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e provavelmente mais especializado em um domínio como bancos, marketing, telecomunicações e etc.

Mas e o gerente? Uma das piores coisas que podem fazer em uma empresa é promover um bom técnico à gerente (coordenador, o que for) apens porque ele está há muito tempo na casa. Querem estimular a pessoa? Transormem em um líder técnico, aumentem seu salário e o deixem em paz.

Gerência não é brincadeira. Não é porque alguém programa muito bem que vai ser um bom gerente. Se você é desenvolvedor mas sonha em dizer para a paquera no barzinho que é gerente de algo (nem que seja do McDonald’s) invista nisso. Aprenda sobre liderança, sobre mercado, plano de negócios, luxo de caixa, lean e todas as dezenas de disciplinas envolvidas. Vai levar algum tempo.

Só não encare isto como uma evolução. Você não está evoluindo, está mudando de carreira -da área técnica para a gerencial. Considerando que conseguir bons salários como técnico é complicado, pode ser uma boa escolha. Mas não necessariamente é a melhor escolha, se você é um bom técnico e não quer deixar isso de lado existem opções…

Engenharia de Build

Tuesday, January 15th, 2008

Eu já trabalhei em projetos com vários tipos de sistemas de build. Uns usam um build completamente automático, uns usam um build interativo (um jeito carinhoso para se referi à porcaria do build em que você tem que apertar ‘enter’ constantemente). Uns demoram 1 minuto ou menos, outros 59 minutos. E alguns nem sistema de build criam! Acham que usar a função ‘Export as JAR’ da IDE é algo aceitável (dica: não é).

A maioria dos projetos tinha ma coisa em comum: não levavam o build a sério. O build de uma hora que mencionei começou com segundos e passou para minutos em algum tempo. Lembro numa reunião onde um grupo de desenvolvedores levantou a questão de que estávamos chegando em 30 minutos, todos na empresa ficaram preocupados. Aí a coisa esfriou e ninguém fez nada, nem ninguém reparou quando esse build chegou em uma hora.

A primeira medida aplicável é tratar o build como parte do seu software, como seu código. Praticamente todos os grandes projetos que participei tinham builds desnecessariamente complexos. Já vi casos onde arquivos build.xml eram gerados on-the-fly através de transformações XSTL, já vi empresas com frameworks de build, onde seu build.xml tem que importar um build.xml criado pela sempre infame ‘equipe de arquitetura’, já vi builds que usam Mavem como se fosse ant e até mesmo um build.xml que usava AWK para fazer a maioria das coisas. Tudo isso é mau sinal.

Seu build deve ser simples. Rake, ant, maven, make não importa: simples. Arquitete-o como faria com sua aplicação: divida em módulos e crie um arquivo de build para cada módulo. Idealmente deve ser possível fazer o build de um módulo em isolamento. No topo, crie um arquivo que faz o build de toda a sua aplicação apenas chamando os builds de cada módulo. Pense na interface dos seus builds, nos parâmetros de entrada e de saída. Encapsule seus módulos.

Testes unitários devem ser executados imediatamente após a compilação (se existente). Se o build falhar porque o teste unitário não passou é melhor que isso seja rápido e não após gerar o pacote de instalação. Testes de integração rodam após esse e os de aceitação na sequência.

Cuidado com testes de aceitação e integração. Pense no que você está testando, já vi casos onde a maioria dos testes de aceitação apenas repetia o que os testes de integração já faziam. Não esqueça que o papel dos testes de desenvolvedor não é substituir a homologação, você como desenvolvedor testa em caixa-branca e sabe quando um teste substitui o outro

Mantenha os artefatos gerados em diretórios temporários até que sejam copiados para seu destino final. Não misture artefatos temporários (arquivos .class soltos, por exemplo) com artefatos versionados (código-fonte). Use os .cvsignore da vida com sabedoria.

Pense sempre no desenvolvedor novato. Quanto tempo o novato precisa para ter um build funcionando na máquina dele? Se a resposta for mais que uma hora você precisa refatorar o build. Convencer os analistas de negócio e clientes que o build deve ser refatorado é duro. Provavelmente é a parte do código onde eles menos vêm valor. Antes de usar a força (ou a clandestinidade) para fazer suas mudanças tente ter uma conversa séria, tente msotrar o valor preto-no-branco.

O build de 60 minutos citado era um problema real. Enquanto o CruiseControl executava o bichinho o desenvolvedor tinha que ficar de braços cruzados porque poderia haver um problema n o commit dele e ia ser bem ruim identiicar o que houve se ele continuasse alterando o fonte. Também, após 60 minutos já haviam vários outros commits na fila, o próximo build levaria mudanças de muitas pessoas diferentes. O assunto era levantado requentemente para o ciente, que ignorava.

A solução que nosso time deu foi interessante. Começamos a escrever em um mural tempo que perdíamos com o build. Em algumas semanas descobrimos que pelo menos 8 horas de deenvolvimento por dia eram perdidas no processo. Fizemos uma estimativa de quanto de código poderia ser entregue usando essas horas desperdiçadas e fomos conversar novamente com o cliente. A postura foi outra, vendo os números as pessoas começam a dar valor. Conseguimos 8 horas por semana para trabalhar no build, o que ez com que ele reduzisse para 30 minutos. Não é o ideal, pelo contrario, mas 30 minutos a menos já foi suficiente para entregarmos mais valor e, principalmente, levantar a moral das pessoas.

Por que um blog em inglês?

Saturday, January 5th, 2008

Muita gente me questionou quando eu criei o blog em inglês e ainda questiona hoje em dia porque eu mantenho dois blogs. O número de blogs em língua inglesa é muito mais alto e é uma consequência que o número de posts aqui vai cair (e já caiu).

O ponto é que existem dois públicos diferentes. No fragmental.com.br eu escrevo para os brasileiros que possuem poucas referências (1)em português e (2) escrita por alguém que conhece a nossa realidade, mercado e cultura, Especialmente referências sobre pontos obscuros do desenvolvimento.

No Fragmental.tw eu me dedico à tópicos um pouco mais avançados. Estes assuntos não são tão bem documentados e/ou eu preciso de opiniões de pessoas que não falam português.

Muitas leitores do .com.br lêem também o .tw, dá para ver pelo Goole Analytics de ambos, mas não são todos. Dificilmente uma pessoa que se interessa sobre adaptar uma linguagem de programação, um assunto bem avançado, teria qualquer problema por algum material estar em inglês.

Hoje eu parei para ler meus feeds no bloglines e cheguei no texto já velho do Charles Nutter sobre os problemas que existem no fato do time que implementa o coração da linguagem Ruby só falar japonês. Eu não tenho a pretensão de ter algo tão importante saindo de nenhum dos dois blogs mas penso quão frustrante deve ser para um chinês cair no site que possivelmente tem a resposta para o problema dele e ter que usar um tradutor automático porque o site não está em inglês, uma língua amplamente falada no nosso meio.

Desde que mudei para a Austrália isso é frequente…

Wednesday, January 2nd, 2008

Ruby 11:41 PM:
hello, happy new year

Phillip Calcado “Shoes” 11:41 PM:
hello, happy new year u2

Ruby 11:42 PM:
Thank you. Are you busy now?

Phillip Calcado “Shoes” 11:42 PM:
not really

Ruby 11:42 PM:
ok. That’s good.

Ruby 11:42 PM:
So, Can i talk about shoes with you?

Phillip Calcado “Shoes” 11:43 PM:
actually i don’t think so. i have no relation to the shoes industry, that’s just a nickname

Ruby 11:43 PM:
ok. haha. Sorry. i misunderstanding.

Phillip Calcado “Shoes” 11:43 PM:
:) np

Ruby 11:44 PM:
But why you use “shoes” as your nickname?

Phillip Calcado “Shoes” 11:44 PM:
i’m brazilian and my surname actually means ’shoes’ in portuguese

Ruby 11:46 PM:
Oh, i see. it’s being the case.  

Phillip Calcado “Shoes” 11:46 PM:
:)

O cara me adicionou com nick de ‘ruby’ eu, sinceramente, achei que fosse a linguagem de programação :P