public static String GetIcone(Byte codSituacao){
String img="";
switch(codSituacao){
case VIGENTE:
img="icon_indicar.png";
break;
case HISTORICO:
img="icon_remover1.png";
break;
}
return "";
}

No Eclipse aparece a mensagem “case expressions must be constants expressions“, utilizando o javac dá a mesma coisa.

Agora, utilizando o tipo primitivo, o mesmo codigo funciona, como abaixo:

public static final byte VIGENTE = 1;
public static final byte HISTORICO = 2;

public static String GetIcone(Byte codSituacao){
String img="";
switch(codSituacao){
case VIGENTE:
img="icon_indicar.png";
break;
case HISTORICO:
img="icon_remover1.png";
break;
}
return "";
}

Alguem sabe explicar o porque disso? =)

É fácil se deparar com as limitações do double no Java e na maioria das outras linguagens: quando vamos trabalhar com dinheiro notamos que as contas não estão saindo exatamente como esperávamos:

double d1 = 0.1;
double d2 = 0.2;
System.out.println(d1 + d2);

O resultado é um estranho 0.30000000000000004, que pode acarretar em problemas graves dependendo da utilização e arrendondamento aplicado depois nesse número. O problema é que um número com 0.1 não pode ser representado em binário de maneira finita: ele vira uma dízima (no binário ficaria algo como 0.110011001100…) diferente do número 0.25, que pode ser representado perfeitamente (no binário 0.01). A representação é um pouco mais complicada que isso, a JVM segue o padrão IEEE 754 para trabalhar com números de ponto flutuante.

Como obter o esperado 0.3? A sugestão sempre é usar o BigDecimal. BigDecimal é uma classe que trabalha com números de ponto flutuante de precisão arbitrária: você pode escolher quanto de precisão você quer usar. Por padrão ele vai utilizar o que for necessário, e, diferente do double, ele consegue guardar números como 0.1, pois guardará isto como sendo 1 x 10ˆ-1 (isto é, usando a base decimal em vez de binária, evitando a dízima).

// nao use esse construtor:
BigDecimal big1 = new BigDecimal(0.1);
BigDecimal big2 = new BigDecimal(0.2);

System.out.println(big1.add(big2));

O resultado é uma nova surpresa, um incrível 0.300000000000000016653345369377…. O que fizemos de errado agora foi que tentar somar 0.1 e 0.2 sendo que esses dois números já estavam armazenados em memória como double, e, ao serem passados para o construtor do BigDecimal, foram transportados com imprecisão. O próprio javadoc desse construtor diz que “The results of this constructor can be somewhat unpredictable“. Na verdade o resultado é bem previsível pelas suas regras, mas não é o que gostaríamos.

Como resolver? Basta sempre usar o construtor que trabalha com Strings, assim o BigDecimal vai internamente fazer o parsing desses números sem que eles sejam armazenados em um double, evitando os problemas de precisão:

// atencao! usando String no construtor:
BigDecimal big1 = new BigDecimal("0.1");
BigDecimal big2 = new BigDecimal("0.2");

System.out.println(big1.add(big2));

Finalmente obtendo o resultado esperado. Há ainda importantes observações sobre o BigDecimal: por padrão ele não fará nenhum tipo de arredondamento, o que o obriga a lançar java.lang.ArithmeticException no caso de uma dízima decimal (tentar dividir 1/3 por exemplo). Nesses casos é necessário delimitar a quantidade de bits a serem usados ou escolher o modo de arredondamento:

BigDecimal big1 = new BigDecimal("1");
BigDecimal big2 = new BigDecimal("3");

System.out.println(big1.divide(big2, 3, RoundingMode.UP));

Resultando em 0.334. Vale lembrar também da imutabilidade da classe BigDecimal, que traz diversas vantagens mas deve ser usada com cuidado quando diversas operações serão realizadas em cima de um mesmo número dentro de um laço, já que diversos BigDecimals serão instanciados durante a operação, podendo acarretar no mesmo problema de performance do uso de concatenação de Strings. O Donizetti lembrou que esse assunto é bastante discutido no item 48 do Effective Java.

No JavaScript teremos o mesmo problema caso você precise realizar contas no lado do cliente, e aí podemos usar a BigDecimalJS, sugerida pelo Jefferson Girão, que funciona de maneira análoga ao Java.

O Rafael Ferreira lembra que podemos ir além, e como dinheiro é algo pertencente ao nosso domínio e lógica de negócios, criamos uma classe Money para encapsular todo esse comportamento e evitar que RoundingMode, MathContext e escalas se espalhem por todo seu código.

Fonte: http://blog.caelum.com.br/2010/07/15/arredondamento-no-java-do-double-ao-bigdecimal/

Algumas considerações:

1) cuidado ao dar um nome para salvar o seu relatório no iReport. Apesar da ferramenta não exigir que esse nome seja o mesmo que você forneceu ao criar o relatório, o engine Jasper irá usar esse nome, e não o nome do arquivo, para gerar o .jasper e o .jrprint (o default). Por exemplo, se o seu relatório se chama MeuRelatorio, e o arquivo se chama mrelat.jrxml, os arquivos gerados serão MeuRelatorio.jasper e MeuRelatorio.jrprint e não mrelat.jasper nem mrelat.jrprint!

2) Cuidado com campos cujos valores podem ser grandes. Nas propriedades do campo (duplo clique), selecionar a aba TextField e marcar a opção stretch with overflow. Atenção: na aba common, existe o Stretch type, mas esse tem a ver com a posição relativa às outras colunas e não com o conteúdo do campo.

3) É possível criar fontes de relatório, que são fontes com características pré-definidas e que depois podem ser usadas por todo o relatório. No iReport, para criar uma fonte nova, ir no menu Visualizar – fontes do relatório, apertando depois o botão new e configurando a fonte. Para usar uma fonte dessas, ir nas propriedades do texto, clicar na aba fonts. O primeiro campo dessa aba é o report fonts, basta escolher.

4) Uso do printWhenExpression: elementos com essa expressão, só são impressos se a expressão (tipo Boolean) for verdadeira. Um exemplo:

new Boolean ($F{codCliente}).intValue() % 10 == 0)

Faz com que o campo codCliente só seja impresso se for múltiplo de 10.

5) outro recurso, digamos, avançado é o de scriptlets. Scriptlets são classes que extendem JRAbstractScriptlet ou JRDefaultScriptlet, que extende a anterior. Essas classes servem para implementar algum tipo de cálculo que não os já existentes (soma, média, contagem, etc…). As classes base oferecem métodos que são disparados automaticamente cada vez que um “evento de relatório” acontece. Exemplos: beforeColumnInit(), afterDetailEval(), beforePageInit(), e assim por diante.

Para usar um scriptlet num relatório (aparentemente só é possível usar um), é preciso fornecer o atributo scriptletClass do elemento. Esse elemento é referenciado pela variável REPORT_SCRIPTLET.

No iReport, isso é configurado em visualizar – propriedades do relatório, na aba scriptlet.

Fonte: http://rederia.net/2010/04/21/dicas-para-jasperreportsireport/

Imagine uma linguagem de programação em que você só precisa do bloco de notas e um navegador (coisa que todo computador tem) para fazer as mais incríveis e inimagináveis proezas. Nutro paixão pela linguagem porque aprendi a programar com javascript, nos meus idos de 15 anos (época em que não tinha a menor idéia de como fazer um Borland C rodar, ou um Eclipse por exemplo).

Agora, que javascript não é perfeita ninguém discute. Não vou falar neste artigo no fato da linguagem não exigir declaração das variáveis, utilizar apenas o “var” para qualquer tipo primitivo, que não é segura, etc…

O que vou relatar é um bug assutador da linguagem:

Quanto é 1000.28 – 1000?

Pois é, para o javascript o resultado incrivelmente não é 28!

Ou 0.1 + 0.2?

Não espere um 3 exato!

Faça você mesmo o teste!

<script>
alert(1000.28 - 1000);
alert(0.1 + 0.2);
</script>


O que acontece é que os “números em Javascript são representados internamente com 64 bits e cada número pode ter no máximo 17 dígitos significativos”, palavras de Carlos Brando.

Para mais exempos e explicações, recomendo o blog do Carlos, acessando http://www.nomedojogo.com/2009/08/17/isto-e-um-bug-no-javascript/

Até a próxima!

Para quem não leu ainda, para entender o significado da pergunta fundamental, os personagens Arthur e Ford estão tentando formular a pergunta correta cujo resultado é 42. Tirando letras feitas em pedras numa toalha ao acaso, o diálogo é o seguinte:


– Q– disse Ford–, U, A, L... Qual! Piscou os olhos.
– Acho que está funcionando! – disse. Arthur lhe entregou mais três,
– E, O, R... Eor. Bom, talvez não esteja funcionando – disse Ford.
– Toma mais estas três.
– E, S, U... Eoresu... acho que não está fazendo sentido.
Arthur tirou mais três e depois mais duas. Ford as colocou em seus lugares.
– L, T, A... D, O... Eoresultado... É o resultado! – gritou Ford. – Está funcionando! É fantástico, está funcionando mesmo!
– Tem mais aqui – disse Ford, arrancando-as febrilmente o mais rápido que podia.
– D, E – disse Ford –, S, E, I, S... Qual é o resultado de seis... V, E, Z, E, S... Qual é o resultado de seis vezes... N, O, V, E... seis vezes nove... – fez uma pausa. –Vamos, cadê a próxima?
– Ahn, isso é tudo – disse Arthur –, eram todas que tinha.
Recostou-se, perplexo.
Vasculhou com as pontas dos dedos mais uma vez dentro da toalha mas não havia mais letras.
– Quer dizer que é isso? – disse Ford.
– É isso.
– Seis vezes nove. Quarenta e dois.
– É isso. Está tudo aí.

Após esse diálogo, o livro não cita mais nada a respeito, os personagens enfrentam outras aventuras no antigo planeta terra.

Muito curiosa, procurei em blogs e foruns de livros mas fiquei frustada por ver que muitos leitores que leram e recomendam a trilogia, sequer citaram esse fato inusitado (ou até mesmo nem notaram, como anda a sua tabuada?).

Cogitei erro de tradução, mas no livro na lingua original está da mesma forma.

Bom, até que um site sério (desciclopedia!) me clareou as ideias e me salvou da escuridão. O que acontece é que a conta é feita em base 13, e não em base decimal. Não, Douglas Adams não errou na conta!

Tanto que se passarmos o resultado de 6 x 9 (54) para base 13 o resultado é exatamente 42 (fiz o teste num coversor de bases, convertworld.com)

Ufa… muito bom descobrir que não estou ficando louca! Até mais pessoal!

Imagine a situação, você é contratado para fazer um sistema, faz toda a análise, estuda os requisitos, entrevista clientes e usuários, faz a modelagem, faz o protótipo, discute com o cliente, enfim… desenvolve o sistema do jeito que o cliente querm, atendento com perfeição às necessidades do cliente.

Aí algum dono de loja ou de estacionamento que não quer dar descontos para um cliente insistente, o que faz? joga a culpa no sistema! ou seja, não é que ele é um mercenário que só pensa no lucro, é que o sistema não permite dar um desconto!

Muita cara de pau não? se o sistema foi feito moldado exatamente para as necessidades do cliente, é a maior desculpa esfarrapada… e quem fica mau na história somos nós, analistas de sistemas, que somos cruéis e não queremos dar desconto para ninguém.

Pois é, isso é falta de coragem para a pessoa assumir que não vai dar desconto porque é uma política dela ou da empresa, sei lá, mas que o sistema não tem nada a ver com a história…

Um dia ainda vou ter esse diálogo quando ouvir a famosa desculpa:

- Desculpe não fazer isso por voce, o sistema não permite.
- Ah, não tem problema, sou analista de sistemas, é só eu dar uma alterada no código-fonte que o sistema vai permitir tudo que você quiser.

ou então:

- Desculpe não fazer isso por voce, o sistema não permite.
- Nossa sério? Vamos fazer o seguinte, já que o sistema é o problema e está engessando tudo, vamos discutir um orçamento para eu desenvolver um sistema melhor. Faço um desconto de 10% para pagamento feito à vista.

Só para chatear o atendente um pouquinho… afinal, tá na hora de pararem com essa conversa fiada de por a culpa no sistema!

Bom, mas tem aplicações em que é inevitável a utilização de cookies. Eu, por exemplo, estou desenvolvendo um sistema onde resumidamente, preciso pegar informações do banco de dados e passar para uma variável javascript, de forma que pelo código fonte não seja possível ver o valor desta informação.

Qual a solução? COOKIES!! Guardo o cookie com o valor confidencial por PHP, direto do banco de dados, e pelo javascript pego o valor do cookie e armazeno numa variável, de forma que ninguém que não acesse meu banco de dados saiba o valor da variável (muito diferente de utilizar os famosos campos “hidden”).

Em teste, tudo certo… e eis que ao passar para produção, claro, tinha que não funcionar direito… alias essa é uma premissa básica do desenvolvimento de sistemas: não importa o quanto você testa seu programa, ao passar para produção sempre terá um erro desconhecido no qual você perde horas, ou até mesmo dias, estragando de vez seu cronograma de entrega do sistema. (essa é aliás uma das maiores emoções de ser programadora =] )

Após muito mexer e debugar manualmente meu programa (”debugar” em php já viu, é um ctrl+c / ctrl+v / echo aqui / echo acolá que não acaba mais), descobri minha salvação! Por algum motivo não identificável (na verdade o que importa mesmo nestes casos é a solução do problema), muito provavelmente diferença de configuração do php, a função setcookie(…) do php só estava funcionando quando setada antes da TAG <HTML>… todos os cookies que eram criados após esta tag, em produção não eram criados.

Neste caso, a solução foi colocar logo no início da página, o comando “ob_start();” que ativa o output buffering, evitando o erro (que para mim era invisível) “Warning: Cannot modify header information”.

Então é isso, para quem for trabalhar com php + cookies, fica aí a dica!


<?php
session_start();
ob_start(); // linha milagrosa!
?>
<HTML>
<?
// agora posso criar meus cookies mesmo após a tag HTML
setcookie("cookieDaMelissa", "1000", 0, false);
$nome_do_cookie = "cookieDaMelissa";
if(isset($_COOKIE[$nome_do_cookie]))
{
echo "O cookie $nome_do_cookie existe! ";
}
?>
<HEAD>
....


Muita gente já deve ter visto um ‘expert’ em linux trabalhando no console listando os arquivos pelo comando ‘ll’, ao invés do tão conhecido ‘ls’. Para poder usar o ‘ll’ (no Debian), basta adicionar o alias no ~/.bashrc:

alias ll=’ls -lah’

Qualquer outro alias pode ser inserido, o limite é a sua imaginação!

Lembre-se: “O linux se ajusta ao usuário, não usuário que se ajusta ao linux.”

=)

Bom, serei breve (até demais) neste post… gostaria de informar que de agora em diante vocês, profissionais da área de TI e simpatizantes, podem contar com este espaço para ler artigos, notícias, trocar idéias, tirar dúvidas, e até perder tempo!

Espero conquistar a amizade e o interesse de vocês e juntos, contribuir para uma interent com mais conteúdo!

Irei abordar alguns assuntos de meu interesse, tais como linux, distros, java, struts, ajax, webdesigner, css, entre outros… Se tiver algum assunto que você, cara(o) leitor(a), gostaria de ver aqui, please let me know!

Fico por aqui…

Abraços e até a próxima!