| Autor |
Mensagem |
|
|
Putz!! 
Ía mostrar pra minha mãe essa classe e nem vou mais! hehe!
O que o sono não faz com uma pessoa. Essa escapou, mas as outras (oitocentos, etc.) estão certas, né? Melhor vocês verificarem, porque já estou dormindo aqui...
Quanto a generalização da classe, não é bem assim não! Cada língua tem as suas particularidades, suas regras. o que muda completamente o algoritmo. Fazer uma dessa em inglês é bem mais fácil, já em francês é mais difícil.
A única coisa que é possível generalizar é o nome dos métodos públicos, o que irá render no máximo uma interface.
Bem, o nome da classe... Sei lá! Acho que agora eu vou dormir, mesmo!
T+!
|
 |
|
|
Pronto!
Isso aqui:
deve resultar em:
Melhor deixar o usuário definir quais prefixos e sufixos usar, a moda DecimalFormat.
[EDITADO]
Atenção: esse código-fonte está desatualizado.
Para obter o código atualizado, utilize o CVS do projeto BrazilUtils em https://brazilutils.dev.java.net
[/EDITADO]
|
|
|
|
A saída do valor por extenso de um número negativo pode ser de dois jeitos:
ou apenas
Qual a melhor forma?
Só confirmando, o nome da classe é org.brazilutils.currency.br.ConvertToReais ?
|
|
|
|
Ironlynx wrote: Vamos discutir isso na lista ou lá no blog?
Pode ser que eu esteja viajando, mas acho que esse tipo de discussão, que envolve muita troca de mensagens entre muitos participantes, se dá mehor na lista de discussões do java.net ou num grupo como o yahoogrupos.
O blog do BrazilUTILS poderia ser uma espécie de canal de relações públicas. Você poderia deixar posts sobre o caminhar do projeto, planos futuros, suas impressões sobre os resultados. Daí os usuários do BrazilUTILS e nós mesmos íamos comentando.
E o guj é ideal para colocar códigos, tirar dúvidas, mostrar as primeiras idéias de requisitos para ver se a comunidade aprova. O guj facilita a colaboração, e mesmo o chumbo grosso de críticas (às vezes) é bem vindo, desde que não apenas critiquem, mas contribuam com uma solução.
Ironlynx wrote:Mas desses apresentados, quais vc acha que conseguiria tocar?
Todos. Aos poucos, espero que nem tão aos poucos assim, eles vão saindo. Depois isso é só o começo, tem muita coisa a ser feita e tenho certeza que não vou fazer tudo sozinho. Tem muita gente nesse projeto. O Dudaskank já está trabalhando neles também.
Ironlynx wrote:Deixa ConvertToText.Mas eu preferia ConvertToReais
ConvertToReais é bem melhor! Valeu!
|
|
|
|
RESPOSTA 1: E quem vai redefinir os requisitos?
RESPOSTA 2: Calma, rapaz! Um passo por vez. Aproveitei ao máximo um tempinho que arranjei. Como eu disse, nem essa primeira parte está pronta ainda. Se você ler novamente o passo-a-passo que fiz antes do código, vai ver que entre as etapas a serem feitas está "separar a parte inteira dos centavos".
RESPOSTA 3: E não, não estou pensando em localizar genéricamente a classe, porque meu grande interesse nesse projeto é mesmo as coisas especificas do Brasil.
Me dê uma sugestão pro nome da classe. Pode me sugerir, Inclusive, nomes de métodos e variáveis se achar necessário.
T+!
|
|
|
|
Leozin, sinceramente não entendi.
Que matisse no Eclipse? Tem plugin, coisa e tal? Qualquer coisa que triplique a produtividade é do meu interesse!
|
|
|
|
O que fiz até agora, com base num artigo que me passaram. Essa primeira parte está quase pronta.
Mas, tenho ainda que descobrir como fazer os milhões, bilhões e trilhões da vida ficarem no plural quando for o caso, colocar a vírgula quando necessário.
*EDITADO: esqueçam as vírgulas!!!
Depois, acho que fica mais fácil. A partir de um BigDecimal, verifica-se a escala. Se estiver beleza, separa a parte inteira dos centavos, transforma os dois em int e joga no método convert.
O resultado do método main (utilizado como teste):
|
|
|
|
E eu nem precisei quebrar a cabeça! Olha só o que vocês mesmo andaram sugerindo logo no começo do projeto:
Requisitos do pacote currency.br
Sugeridos pelo thingol:
- validação de módulo 10 e 11, de boletos bancários e de concessionárias públicas;
- validação de números de contas dos diversos bancos;
- validação de números de cartões de crédito (o algoritmo de Luhn vale para todas as operadoras, ou tem mais alguma coisa?)
Sugeridos pelo Douglas:
- cálculos padronizados de impostos federais, estaduais e municipais;
- valores de alíquotas de impostos como constantes;
- enquadramento nas faixas e cálculo do Imposto de Renda para sistemas de RH;
- GenericNotaFiscal e AbstractOrdemDeServico
- coisas como valor/percentual de retenção de imposto, qual imposto recolher dependendo do valor e outras.
Como ponto de partida, está ótimo.
|
|
|
|
dudaskank wrote: Mandarei mp pro Rafael ver o que ele está precisando pra eu ir dando uma ajuda... espero poder contribuir com algo útil neste projeto :p
Bem vindo!
Como disse ao Dudaskank, estou pensando em fazer algo parecido com o que o Douglas fez com as classes para inscrição estadual, cnpj, só que focando cálculos de impostos, etc. A parte financeira/tributária é bastante complexa no Brasil e, segundo um professor meu, que é administrador, sempre nos dá (programadores) muito trabalho.
Tenho que fazer um documento de requisitos para o currency.br, mas pretendo fazer algo além de conversões entre moedas. Se estiverem de acordo com esse proposto, poderemos seguir adiante.
|
|
|
|
dsiviotti wrote:Pessoalmente acho que deveríamos fazer na 1.4 e aumentar o leque de pessoas usando a API e dando retorno.
Douglas, compreendo isso.
Na minha visão limitada, de developer lidando com o pacote currency.br, Java 5 é a escolha sem sombra de dúvidas. O processamento das rotinas será pesado, e vamos utiilzar BigDecimal pra todo que é canto. Mas, além da velocidade, tem outros motivos pelo qual eu usaria o Java 5 aqui.
Note que é uma visão bem focada nesse caso específico, e reconheço que, ampliando a perspectiva, Java 1.4 pode ser a melhor solução.
Mas recomendo: vamos resolver essa questão e, assim que resolvida, todos terão que "vestir a camisa" para não voltar mais nesse assunto e partirmos para os outros problemas que nos esperam!
T+!
|
|
|
|
Além da Matisse, o Netbeans 5.5 tem umas características que para mim são importates: suporte para UML, permitindo até fazer engenharia reversa de código já escrito, um editor de xml fera, SOA e BPEL. Bem, na verdade, os dois últimos ainda não são importantes pra mim... Mas eles estão lá.
Tem um wizard que transforma as tabelas de uma base de dados em Entity Beans. Não me considero preguiçoso, nem mesmo "preguiçoso", só não curto perder tempo e penso que o que pode ser automatizado deve ser automatizado.
Eu acho o Eclipse mais bonito, e isso é motivo de orgulho pro pessoal envolvido com swt. O processo de compilação no Netbeans poderia ser parecido ou igual ao do Eclipse. Se bem que acho que os vínculos entre projetos funcionam melhor no Netbeans, como já foi dito aqui.
E fiquei muito curioso com as capacidades de code-completion do Eclipse, já que foi dito várias vezes aqui que isso funciona bem melhor no Eclipse do que no Netbeans. Vou ficar mais atento.
Mas, depois de ler toda essa thread, resolvi "partir pra ignorância": vou usar as duas IDE's, pelo menos por enquanto, dividindo por projetos que eu ache que funcionem melhor com as capacidades de cada IDE. Clientes desktop, por exemplo, estarão no Netbeans.
É um assunto bem espinhoso, digno de TCCs (trabalho de conclusão de cursos). Aliás, é justamente o tema de um dos meus colegas.
T+!
|
|
|
|
Eu comecei a usar o Ubuntu principalmente pela questão monetária, mas pela segurança e por curiosidade também. Sempre quis saber como é programar em cima do Linux.
Rapaz, não me decepcionei! Simplesmente, Java é muito mais rápido no Ubuntu do que era no Windows, mesmo não tendo suporte da Sun, assim como o próprio Ubuntu é mais rápido.
A maior dificuldade foi configurar todo o ambiente de trabalho: IDE's, servidores de aplicações e de banco de dados. Isso tomou muito tempo, mesmo!
Sugiro que você pesquise como montar o seu ambiente de trabalho no Ubuntu, com todas as ferramentas que você utiliza, depois migrar com calma, se for o caso, para o Ubuntu.
E deixar ao menos um computador com Windows, talvez esperar pelo Vista. Porque um dia, vai aparecer algo que só roda no Windows!
T+!
|
|
|
|
Ironlynx wrote:
Tá ok.. vcs venceram!Liberado o uso do Tiger!
Eu acho Desempenho mais importante que retrocompatibilidade, mas se preparem que eu vou redirecionar eventuais reclamações via email direto para suas respectivas caixas... 
Pode mandar! Eu trabalhei numa empresa grande e burocrática, já aprendi como agir nesses casos: é só fazer uma resposta padrão! hehe
Sr. ou Sra. Fula de Tal (Nome aqui! Não enviar Fulano de Tal!)
Entendemos a sua preocupação e sua vontade de usar essa incrível biblioteca de utilidades.
Mas, no momento não podemos atendê-lo. Isso porque ainda não descobrimos uma maneira de agradar a gregos e troianos. Não ficaremos ofendidos com os seus impropérios porque sabemos que é mais fácil nos xingar que xingar os seus chefes - a não ser, é claro, que você xingue seu chefe por dentro! E é mais fácil seus chefes fazerem você usar Java 1.4 (ou 1.3!) do que convecer os clientes da sua empresa a colocar a mão no bolso e usa o Java 5.
É uma situação triste, lamentamos por isso, mas não podemos fazer nada. Obrigado por nos deixar saber o que você pensa (mesmo que isso não adiante nada)!
Mas as nossas portas estão abertas para você. Além de chorar, você também pode coloborar com o BrazilUTILS! Descubra como fazer (o objeto da reclamação aqui) de forma compatível com a versão 1.4 e mande para o nosso CVS no java.net.
Atenciosamente!
Rafael.
|
|
|
|
Ironlynx wrote:Lembre-se de usar um StringBuffer(eu iria dizer para usar StringBuilder mas há muitos 1.4 ainda..) na concatenação.
Não posso mesmo usar o que é específico do Java 5?! Mas as classes do Douglas já usam Enum!
O que eu penso é que temos que tirar o melhor possível do Java, até para eliminar certas barreiras... Sem querer ser chato, mas quem tiver problemas de compatibilidade que veja o código e adapte as classes de acordo com a sua necessidade. E se mandasse pra gente melhor ainda! Já teríamos a nossa própria versão de Vector vs. ArrayList!
Chefe, você não pode dar um jeito? Compatibilidade é mais importante que desempenho mesmo? Vou esperar sua resposta para começar a programar.
dudaskank wrote:Bem, se você já tem ele em BigDecimal E puder usar java 5, tem os métodos:
Valeu! Como disse, espero poder usar o que já está no Java 1.5.
|
|
|
|
E aí, galera? Beleza?
Primeiro, parabéns pela iniciativa! Tenho trocado idéia com o Ironlyns, já estou cadastrado no java.net e fiquei responsável pelo pacote currency.
Estou preparando aquela classe que deixa valores monetários escritos por extenso.
Enfim, estou criando dois métodos sobrecarregados:
- public static String porExtenso(BigDecimal currency);
- public static String porExtenso(String currency);
*EDITADO: os métodos porExtenso não serão estáticos. Há bons motivos de sobra para essa decisão.
Deixei os nomes em português porque não tenho a menor noção de como fazê-los ter sentido em inglês.
A minha idéia é fazer os métodos verificarem se os parâmetros tem escala dois ou três. Se tiver outra escala, maior que três por exemplo, joga uma excessão.
Mas, meu problema mesmo é com as casas decimais. Eu preciso separar o valor inteiro do decimal. Ex: R$ 6.432,24 ficaria 6432 numa variável e 24 noutra.
Tive uma idéia, mas acheio tosca. Teria que converter para String, encontrar a vírgula e separar os "dois lados da moeda"... Mas daí, teria que voltar pra BigDecimal novamente para fazer os cálculos.
Vocês têm alguma outra idéia?
T +!
|
|
|
|
|
|