Vamos começar 2012 falando sobre uma ferramenta que pode salvar vidas (tá, estou exagerando, mas pode salvar carreiras hehe) de quem desenvolve em .NET. Quando você pega um projeto que usa algumas bibliotecas feitas pelo desenvolvedor anterior, você PRECISA fazer algumas alterações nela ou, no meu caso, compilar o projeto com um componente mais atual porque se for usar a biblioteca original ele OBRIGA A USAR a versão antiga e que o fonte foi pras cucuias?

De posse da biblioteca original você poderá ver o código-fonte usando uma ferramenta oferecida pelo próprio Visual Studio: IL Disassembler, ou IL DASM para os mais chegados. Mas tem um porém: ela apresenta o código na Common Intermediate Language (CIL), o código que o compilador JIT do .NET Framework traduz para código de máquina e por fim é executado. Bem, não é nada produtivo ficar tentando entender a IL, certo?

Há algum tempo atrás, existia uma ferramenta gratuita chamada .NET Reflector. Esta ferramenta traduzia a IL para C# ou outras linguagens da plataforma .NET e exportava para um projeto, prontinho para compilar. Um porém desta ferramenta é que ela forçava os updates automáticos, de forma que se a rotina de atualização fosse cancelada o programa “matava a si próprio”, ou seja, era apagado do disco. E não adiantava reinstalar. No fim, o desenvolvedor vendeu o .NET Reflector para a empresa Red Gate, que continua o seu desenvolvimento porém o aplicativo agora é pago e a versão Standard custa US$ 35,00 (fonte: http://www.reflector.net/).

Dando uma pesquisada por aí, achei um substituto legal e que cumpre ao meu propósito: o IL Spy. Ele também é um “disassembler” para .NET, que traduz o código em IL para C# e permite salvar o projeto. Só que com um detalhe: é de código-aberto e grátis (lembre-se que uma característica não implica em ter a outra ).

Com ele, consegui pegar todas as classes que precisava, colar em um novo projeto, referenciar as bibliotecas mais atuais e compilar. Mas nem tudo são flores: Ele traduz o código de algumas propriedades, principalmente indexadas, colocando no lugar da propriedade a chamada para seu método ancestral, “getter” ou “setter”, por exemplo:

//Como a propriedade é colocada no código original:
MeuDataSet.Tables[i];
MeuArrayList.Count;
MeuDataRow["CAMPO"] = valor;

//Como ela é traduzida pelo IL Spy
MeuDataSet.get_Tables(i);
MeuArrayList.get_Count();
MeuDataRow.set_Row("CAMPO",valor);

Quando compilava sem fazer o devido ajuste ocorria um erro de compilação, pois os getters e setters das propriedades exemplificadas acima não são métodos públicos, portanto não poderiam ser acessados de fora da classe onde foram declarados.

Tirando esse pequeno atormento (que dependendo do código se torna um grande atormento…), repito que a ferramenta atendeu os meus objetivos e a recomendo em casos de emergência ou até mesmo para estudo de fontes (desde que não estejam ofuscados, claro!).

Onde baixar? Aqui: http://wiki.sharpdevelop.net/ILSpy.ashx

Olá caro leitor do NM Tech! Você, como desenvolvedor de sistemas, já precisou desenvolver um sistema de votação eletrônica pela Web? Se sim, você já parou para pensar qual seria a carga de acessos deste sistema e uma forma de permitir uma votação segura e confiável?

Algumas amigas minhas inscreveram seus filhos para participarem do Concurso “Bebê Hipoglós 2011”, onde a criança irá ser o “bebê-propaganda” do referido produto. Para votar basta entrar no site http://bebehipoglos2011.com.br/, escolher o bebê, clicar no ícone “Votar”, preencher um captcha e dar OK. Sim, é só isso mesmo.

Ah, Léo.. você fazendo jabá da promoção aqui no NM Tech? Epa, calma lá, rapá! Agora vou responder as duas perguntas que fiz acima: Sim, eu já desenvolvi um sistema de votação eletrônica que era aberto ao público e que a carga era moderada. E a votação era segura e confiável graças a alguns mecanismos que foram implementados.

Continuando no caso do site Bebê Hipoglós 2011, a página da campanha no Facebook (http://www.facebook.com/bebehipoglos) está cheia de comentários negativos à respeito do sistema de votação. Muitas pessoas estão reclamando que o site cai toda hora e que em pouco tempo de promoção existem crianças com mais de 10 mil votos.

Sim, constatei por mim mesmo que o sistema está sobrecarregado, e uma das coisas que me chamaram a atenção nos meus comentários foi:

“Olá pessoal estou desde as 07:15 da manhã consegui votar 511 x na minha filha mas realmente esta muito complicado votar”

Isso mesmo, a MESMA pessoa votando várias vezes em seu bebê. Então COMO as pessoas querem que a votação seja confiável e que o sistema não tenha sobrecarga? Não foi só essa pessoa que teve essa ideota de jênio*, né?

E para votar, como eu disse anteriormente, o sistema pede para preencher um captcha, muito tosco, facilmente decodificável por ferramentas de OCR, e como sabemos, já existem robôs que possuem esta funcionalidade. Com um (um não, vários… muitas pessoas podem ter tido essa idéia) robô desses fazendo várias requisições ao servidor Web, não há estrutura que aguente.

Nenhuma forma de identificação do votante é requerida.

No sistema de eleição que fiz, antes de votar o usuário tinha que preencher seus dados, confirmá-los no sistema e aí sim escolher seu candidato. Tal sistema NÃO permite que o mesmo usuário vote novamente. E mesmo com o cadastro, o voto era computado de forma totalmente anônima, sendo IMPOSSÍVEL saber quem votou em quem.

Por que não implementar, como disse um comentarista no Facebook, um passo onde o usuário registraria alguns dados pessoais e o CPF (obrigatório) antes de votar e permitisse apenas UM voto por CPF? Aí sim aumentaria e muito a confiabilidade do sistema e a farra dos robôs diminuiria bastante. Bloqueio de voto por IP não resolveria, já que muitas casas hoje em dia já contam com uma pequena rede onde a conexão à Internet é compartilhada.

Quer ver como isso é uma coisa SIMPLES de ser implementada? Vou mostrar um modelo básico, com 2 tabelas e os passos necessários (não código) para realizar a votação:

Veja só: apenas duas tabelas, e não há ligação nenhuma entre elas. Para gravar um voto, crie uma StoredProcedure no banco de dados com os parâmetros de entrada do eleitor (Nome, CPF, Email e o ID do candidato que ele votou) Coloque o modo de isolação de transação no modo Repeatable Read (recomendado), abra uma transação, faça um select no eleitor baseando-se no CPF para verificar se ele já já existe na tabela “Eleitor” (se sim, dispare uma exceção informando a interface desta situação), dê um select no candidato baseando-se no ID passado como entrada (para travar o registro, já que isolamos a transação como Repeatable Read), faça um Update no Candidato, incrementando 1 no campo “QtdVotos”, faça o Insert na tabela Eleitor e dê commit na transação.

Simples assim, não? Ah, e antes que venham com o “Ah, mas o DBA ou outra pessoa pode alterar o campo QtdVotos e tal…”, não estou contando que esta intervenção humana venha a acontecer, por que daí já é caso de Justiça e tal, são outros quinhentos.

Isso vai burocratizar o processo de votação? SIM. E este é o preço a pagar por uma maior confiabilidade no sistema de votação. O que é mais vantajoso para a sua empresa: Um sistema que é um pouco “chato” para votar porém os usuários falam que é confiável ou um totalmente escancarado dando margem para inúmeras reclamações quanto a idoneidade do concurso? Lembrem-se que um comentário negativo viaja milhares de vezes mais rápido que um positivo! E se não fossem pelos comentários negativos (que minhas amigas que inscreveram seus bebês fizeram e fui conferir o sistema), nem escreveria este post!

Eu não me conformo como um sistema que dá uma premiação em dinheiro, mexe com as emoções de milhares de mães/pais que cadastraram seus filhos (sim, porque as crianças ainda não entendem) na expectativa de vê-los em um comercial de TV e se tornarem famosos, ser modelado de uma forma TÃO TOSCA???

Um abraço!!!

*com “J” de JUMENTO

Eu diria que em partes, dependendo de como o cálculo é feito. Em se tratando apenas de SQL Server o nosso primeiro impulso é calcular essa diferença usando a função datediff(), passando como argumentos que queremos o resultado em anos e as datas envolvidas.

Calcular idade NÃO é apenas uma simples diferença entre o componente ANO das datas, que é o que a função datediff faz se passarmos como primeiro argumento que queremos a diferença em anos. Nesse caso o cálculo da diferença não leva em consideração os dias e os meses, fundamentais para o cálculo de idade. A questão que devemos ter em mente é: “A pessoa já completou determinada idade no dia atual?”

Para facilitar este cálculo montei uma UDF em Transact-SQL, que retorna um valor escalar que é a idade baseada na data de nascimento informada e no dia atual, que leva em consideração que tal data de aniversário foi atingida ou não. Vamos a ela:

create function [dbo].[CalculaIdade](@DataNascimento Datetime)
returns int
AS
BEGIN
	declare @idade int;
	--Coloca o dia e mês da data de nascimento no ano atual
	declare @DataNormalizada datetime;
	--Volta a data em 01/01 do ano atual sem utilizar concatenação de strings (evita lembrar usar o SET DATEFORMAT)
	set @DataNormalizada = dateadd(dd,0,datediff(dd,0,dateadd(dd,(-1)*day(getdate()) + 1,dateadd(mm,(-1)*month(getdate()) + 1,getdate()))));
	--Agora sim, calcula a data de aniversário no ano atual
	set @DataNormalizada = dateadd(dd,day(@DataNascimento) -1,dateadd(mm,month(@DataNascimento) -1,@DataNormalizada));

	--Calcula a idade em anos (o SQL Server irá apenas subtrair o componente ANO, sem considerar os dias)
	set @idade = datediff(yy,@DataNascimento,getdate());

	--se ainda não chegou no dia de nascimento, subtrai 1 da idade, já que ainda não estará completa.
	--O cálculo acima com datediff não leva isto em consideração.
	if( @DataNormalizada > getdate())
	begin
		set @idade = @idade - 1;
	end
	return @idade;
END
GO

Primeiramente declaramos uma variável @DataNormalizada, que nada mais é que a data de aniversário no ano corrente e para calculá-la sem concatenar strings (para não nos preocuparmos com formatação de data) “voltamos” o ano atual para 01/01 e em seguida acrescentamos o mês e o dia da data de aniversário. Nessa adição, necessitamos subtrair 1 do dia e do mês porque como começamos o valor em “1” e não em “0”, necessitamos compensar essa diferença.

Em seguida fazemos o que o nosso impulso manda: calculamos a diferença em anos utilizando a função datediff().

Agora que vem o pulo do gato: Lembra que calculamos a data de aniversário da pessoa no ano corrente? Pois bem: Verificamos se a data de aniversário é maior que a data atual. Se sim, significa que a pessoa ainda não fez aniversário e que a idade em anos calculada acima está incompleta, portanto, temos que subtrair 1 ano da idade.

Esse pequeno detalhe do cálculo da idade é crucial (sim, dependendo da área de negócio, exemplos como sistemas de gestão de saúde, a idade correta de uma pessoa é muito importante e é um dado dinâmico sempre calculado a partir da data de nascimento), portanto, preste MUITA atenção e bora utilizar a função acima para calcular!

Pois bem, você possui neste DataSet uma (ou mais) tabela com um campo DateTime, e no seu banco de dados está gravado o valor, por exemplo, 17/10/2011 08:00, mas a sua aplicação exibe o valor 17/10/2011 09:00.

O que!!! Quer dizer que a aplicação está exibindo este valor uma hora ADIANTADA? Exatamente isso, meu querido! Se fomos extrair este campo para uma variável DateTime e verificarmos o resultado do método IsDayLightSavingTime(), o mesmo retornará True, indicando que a data em questão cai no horário de verão.

Se fomos olhar isso mais a fundo na aplicação cliente, veremos que o valor já considerando o horário de verão (no nosso caso, 1 hora adiantada) já vem do próprio DataSet que recuperamos via WCF do servidor. Se a aplicação cliente extraísse esse valor diretamente do banco de dados ele seria exibido corretamente. E se quisermos exibir o valor do banco de dados, como faz?

Na máquina que executa a aplicação cliente, caso você esteja utilizando o Windows XP, dê um duplo clique no relógio, acesse a guia “Fuso Horário” e desmarque a opção “Ajustar automaticamente para o horário de verão” e o seu problema estará resolvido e a aplicação passará a exibir as horas conforme estão gravadas no banco de dados.

Maaaaaaaas… tem um pequeno grande porém nesta “solução”: E se este flag do horário de verão não puder ser desabilitado pelo usuário (permissões no sistema, entre outros) e não acho um meio na aplicação cliente de fazer as horas serem exibidas corretamente, sento e choro?

Sentar e chorar é uma hipótese dependendo de como você modelou a parte servidora do seu sistema. Mas a solução definitiva é a seguinte: Ao obter um DataSet do banco de dados, devemos modificar uma propriedade chamada DateTimeMode das colunas DateTime das tabelas deste DataSet para DataSetDateTime.Unespecified, que informa para o WCF não recalcular as datas para a zona de horário das aplicações clientes na hora da serialização.

Vamos ao código!

public DataSet RetornaDataSet()
{
	DataSet ds = new DataSet();
	//Preencher o DataSet com os valores do banco de dados aqui

	//Agora, iremos modidicar as colunas DateTime das tabelas para ignorarem o recálculo de data/hora no momento da serialização WCF
	foreach (DataTable tabela in ds.Tables)
	{
		foreach (DataColumn coluna in tabela.Columns)
		{
			if ((coluna.DataType == typeof(DateTime)) || (coluna.DataType == typeof(DateTime?)))
			{
				coluna.DateTimeMode = DataSetDateTime.Unspecified;
			}
		}
	}
	return ds;
}

Com este código modificamos todas as colunas com o tipo DateTime para que quando o DataSet for serializado via WCF, as datas não sejam recalculadas conforme a zona de tempo do usuário cliente (horário de verão, fuso-horáro, etc.).

É isso aí!

Errado! Um RequiredFieldValidator apenas irá disparar se o campo NÃO estiver preenchido. O que queremos é que numa condição X em que um textbox esteja vazio, o validator execute, e em outra não.

Para isso podemos utilizar um CustomValidator e atribuir a propriedade de argumento de evento IsValid no evento ServerValidate para que seja True se as nossas condições forem obedecidas.

Porém (sempre tem um porém!) justamente quando você quer validar quando o  campo está vazio utilizando um CustomValidator o evento ServerValidate não dispara nem a pau, mesmo você chamando diretamente o método Validate() do mesmo. E você não pode usar um RequiredFieldValidator. O que você faz, ajoelha e chora?

Com exceção do RequiredFieldValidator, TODOS os demais validators não executam quando um textbox na propriedade ControlToValidate está vazio. Este é um comportamento padrão. Vamos dar uma olhada na caixa de propriedades de um CompareValidator e um CustomValidator:

Além das propriedades inerentes a cada tipo de Validator, temos uma propriedade curiosa no CustomValidator: ValidateEmptyText. Se colocarmos ela em True, o evento ServerValidate irá ser executado ao verificar a propriedade IsValid da página ou outra rotina de validação. Os outros tipos de validator não validam quando o texto está vazio. Com isso podemos testar, por exemplo, a obrigatoriedade de um campo em determinada condição em nosso sistema.

Dica fácil essa, né? Quando pesquisei sobre o assunto, vi uma sugestão em que era necessário derivar uma classe do “pai” dos validators!

Espero que esta dica seja de bom proveito

Assistam ao vídeo contendo uma pequena demonstração deste compilador.

Caso queiram testá-lo por si mesmos, visitem o site http://phalanger.codeplex.com/

Para fazer um controle de permissões básico com as quatro permissões fundamentais em um sistema (Visualização, Inclusão, Alteração e Exclusão) quantos campos são necessários em uma tabela de banco de dados? No mínimo quatro, você poderia dizer.

Vamos fazer uma modelagem de uma tabela que armazena a relação entre perfis de usuários e módulos de um sistema:

Basicamente criamos um campo booleano para cada permissão básica. Para verificar se um usuário de determinado perfil tem permissão em um módulo, basta puxarmos o ID do módulo, o ID do perfil do usuário, fazer uma consulta à base de dados (ou em algum local onde estas permissões são guardadas em cache – o que melhora o desempenho) e verificarmos se a permissão adequada tem valor Verdadeiro ou Falso.

Agora pensa uma coisa comigo: Não é fácil para um usuário qualquer entrar no banco de dados e alterar a permissão? Sim sim, isso é possível e existe uma forma de “ofuscar” as permissões armazenadas em banco de dados: gravar TODO o conjunto de permissões como um único campo do tipo Integer e extrair dele as permissões utilizando operações bit a bit dentro da aplicação. Como faz, com mágica?

Mágica não, meu querido! Faz-se com Matemática! Que tal pegarmos aquelas aulinhas no começo da faculdade sobre operações booleanas e aplicá-las em algo mais “palpável”?

Primeiro vamos remodelar a nossa base de dados, onde no lugar de quatro campos booleanos de permissões teremos apenas um inteiro que gravará todo o conjunto (vamos utilizar apenas as quatro permissões fundamentais para ficar mais didático ).

Ah, já sei! Vamos atribuir “1” para Visualização, “2” para Inclusão, “3” para Alteração e “4” para Exclusão, né safadinho! Na na ni nã NÃO! Isto é muito feio! hehe.

Não vamos pensar no campo ConjuntoPermissões como um mero inteiro. Dependendo do banco de dados (e da linguagem que iremos utilizar, que no nosso caso é – adivinha – o C#), o tamanho físico de um campo do tipo Integer é de 4 bytes, 32 bits. Com isso podemos guardar até 32 permissões em um único campo!

Vamos ver a matemática da coisa agora:

Iremos utilizar 4 bits para guardar o nosso conjunto de permissões. Para ficar mais fácil de entender, vamos desenhar:

No esquema acima temos o número 15 representado no sistema binário. Cada bit representa uma permissão. Um bit ligado significa permissão concedida. Para revogá-la, basta desligarmos o bit correspondente. Note que cada bit tem um “peso”, e que da direita para a esquerda esse peso corresponde a uma potência de 2. Dois elevado a zero até dois elevado a três.

Vamos representar neste esquema um usuário apenas com permissões de Inclusão e Alteração:

Neste conjunto de permissões apenas o segundo e o terceiro bit (contando da direita para a esquerda) estão ligados. Vamos saber agora como extrair as permissões de um usuário neste esquema.

Como eu disse acima, cada bit tem o seu peso representado por uma potência de 2. Vamos representar cada uma das permissões seguido o mesmo modelo que fizemos acima:

Para descobrir se um usuário tem determinada permissão, fazemos uma operação “AND” bit a bit entre o conjunto de permissões e o valor da permissão desejada e verificar se o resultado desta operação é MAIOR que zero. Vamos verificar a permissão de Alteração fazendo um “AND” bit a bit utilizando os dois esquemas acima:

Fazendo essa operação (o “AND” equivale a uma multiplicação, mas fique atento que fizemos a multiplicação entre os bits e não com o inteiro) vemos que o resultado é exatamente aquele bit que coincide com o que queremos procurar, e que o resultado final é maior do que zero. Com isso verificamos que o usuário tem a permissão adequada. Que tal vermos a permissão de Exclusão?

Como vimos no esquema, o resultado do “AND” bit a bit deu zero, ou seja, o usuário NÃO tem a permissão adequada.

Beleza, agora sei como extrair as permissões. E agora, como faço para montar o conjunto de permissões? Essa parte é bem simples: basta fazermos uma operação “OR” bit a bit entre as permissões que você quer dar para o usuário. Vamos dar as permissões de visualização, inclusão e alteração?

A operação OR é equivalente a uma soma. Note que embora o resultado no sistema decimal seja equivalente (o que não é no caso do AND) fizemos esta conta bit a bit.

Depois dessa demonstração matemática, que tal aplicarmos este conceito em um programa C#? Serve qualquer banco de dados, então os detalhes de conexão fogem do escopo deste artigo.

Para representar as permissões você pode pensar em atribuir  números igual ao que fizemos na demonstração matemática. 1 para Visualização, 2 para Inclusão e assim por diante, sempre crescendo em potência de 2. Vamos fazer isso, porém iremos representar as permissões através de uma enumeração. Além de ser uma boa prática de programação, o código ficará muito mais legível para os mantenedores. Assim:

public enum PermissoesAcesso
{
	Visualizar = 1,
	Inserir = 2,
	Alterar = 4,
	Excluir = 8
}

Note que encapsulamos os valores inteiros (números “mágicos”, em linguagem mais acadêmica) na enumeração PermissoesAcesso, muito mais legível.

Vamos criar um método que verifica se um determinado perfil passado como parâmetro tem a permissão que iremos indicar em outro parâmetro, para um módulo indicado em um terceiro parâmetro:

public bool VerificaPermissao(int IdPerfil, PermissoesAcesso Permissao, int IdModulo)
{
	//...conecte com o BD aqui e crie os parâmetros...
	int ConjuntoPermissoes = (int)MeuCommand.getScalar("select ConjuntoPermissoes where IdPerfil = @PERFIL and IdModulo = @MODULO");
	//...feche a conexão...
	return (ConjuntoPermissoes & (int)Permissao) > 0;
}

Para podermos fazer o “AND” bit a bit do conjunto de permissões (que é um Integer) com o valor inteiro da enumeração PermissoesAcesso, devemos fazer um cast da variável Permissao para inteiro.

Agora vamos criar um outro método, que recebe um array com as permissões que serão atribuidas a um perfil, o perfil e o módulo, monta o inteiro correspondente ao conjunto de permissões e salva na base de dados:

public void SalvaPermissoes(int IdPerfil, int IdModulo, PermissoesAcesso[] Permissoes)
{
	int ConjuntoPermissoes = 0;
	foreach(PermissoesAcesso perm in Permissoes)
	{
		ConjuntoPermissoes |= (int)perm;
	}
	StringBuilder sql = new StringBuilder("update Permissoes set ConjuntoPermissoes = @PERM where IdPerfil = @PERFIL and IdModulo = @MODULO");
	//...Crie os parâmetros e execute o SQL.
}

O laço foreach do código acima vai somando (vale a pena lembrar que um OR bit a bit é uma operação de soma), bit a bit, cada permissão do array e acumulando na variável ConjuntoPermissoes. Para fazer o OR bit a bit de um inteiro (variável ConjuntoPermissoes) com o inteiro da enumeração Permissoes, precisamos fazer um cast da segunda para inteiro. Exatamente como fizemos na demonstração matemática.

Para atribuir duas (ou mais) permissões de forma isolada, basta fazer o OR bit a bit entre elas:

int Permissoes = (int)PermissoesAcesso.Visualizar | (int)PermissoesAcesso.Inserir;

Com isso, vimos como melhorar o nosso sistema de armazenamento de permissões de forma eficiente e eficaz. Este recurso de operação bit a bit é utilizado, por exemplo, na API do Windows, ou até mesmo no C#, onde temos funções em que um parâmetro admite vários flags (representado por enumerações ou até mesmo constantes inteiras) concatenados. E essa concatenação dos flags é feita justamente com o operador OR bit a bit.

Um abraço!

Há um tempo atrás, li na revista .NET Magazine nº 42 (de 2007!) uma resenha sobre diversos componentes para ASP.NET e um dizer logo no penúltimo parágrafo do artigo me chamou a atenção:

Tome cuidado com componentes gratuitos, podem ser um problema, principalmente se não vierem acompanhados do código-fonte.

Em princípío achei que esse dizer representava um preconceito do articulista com componentes grátis, que ele poderia estar “levando um por fora” para desmerecer o trabalho de várias pessoas que disponibilizam seu tempo na confecção destes componentes. Mas foi só eu sentir na pele o que um erro bem simples que um componente grátis causou em um sistema que percebi que a afirmação tem fundamento.

Recentemente necessitei fazer uma aplicação web que gerasse boletos bancários que deveriam ser pagos em um banco de origem espanhola famoso, com o pequeno detalhe que isto deveria ser feito “pra ontem”, ou seja, o tempo era BEM curto. Quando recebi a especificação do banco, dei uma tremida nas bases. Tinha que calcular digitos verificadores, fator de vencimento, código de barras, linha digitável e o escambau, e além disso tinha que fazer o layout do boleto em HTML!

Como não sou um às do HTML, pensei: F*DEU! Não vou conseguir entregar isso nem a pau…

Dei uma pesquisada na net e achei um componente em C# chamado “Boleto.Net” no Codeplex. Pensei: Me salvou a pátria! Baixei o danado, vi os exemplos e implementei-o na minha aplicação.

Daí tinha que homologar os boletos no banco, né? Até aí continua tudo bem, gerei os boletos e mandei para a homologação. Recebi a resposta do banco e os boletos estavam homologados, já poderiam entrar em produção.

O sistema entra em produção, e uma pessoa que gerou um boleto e foi pagá-lo no homebanking não conseguiu, pois estava dando “código de barras inválido”. WTF? O banco não disse que tava certo?

Aí fui “depurar” o boleto com uma app para iPhone (BoletoScanner): O código de barras era lido normalmente, porém  um bloco da linha digitável não estava batendo com o do boleto impresso, aquele número que fica sozinho e que corresponde ao DV do código de barras.

Mas pô, o cara do banco disse que estava certo, ou seja, ele HOMOLOGOU os boletos com esse erro na linha digitável! Daí foi uma correria para o cara do banco falar que realmente estava errado, baixar o código-fonte do componente, fazê-lo compilar no Visual Studio 2010, depurar, e finalmente corrigir o erro na linha digitável.

Com esse erro grave corrigido (e olha que o sistema já estava em plena produção!) novamente levamos os boletos para homologar no banco, e eu também estava fazendo testes paralelos com a app do iPhone, e finalmente atualizei a aplicação no servidor com os boletos corrigidos.

E quem já tinha gerado o boleto com erro (o sistema era aberto ao público), como que fica? Ainda bem que eu tive a idéia de fazer uma função de reimpressão, bastando informar um documento. Era só a pessoa gerar novamente o boleto e ir pagar (sem refazer todo o processo que culmina na geração do boleto), simples assim.

E isso tudo que eu contei foi causado por um erro em um componente grátis em que a última versão é de 14/06/2010 (quase um ano já), e na descrição fala que ele está homologado para trabalhar com o banco espanhol que falei acima.

Já pensou se ele não tivesse o fonte para eu alterar e gerar a linha digitável correta? Só por UM dígito? Eu estaria f**ido!

Então, devemos testar bem os componentes que utilizamos, sejam gratuitos ou pagos, para podemos aproveitar melhor os seus recursos.

Um abraço!