BrazilUtils 0.2

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Ironlynx wrote:

Bom, quanto as features, eu vou prosseguir com o pack de métricas(já tem umas centenas para entrar), e eu estava esperando idéias do pessoal principalmente na parte de Datas(que muitos reclamam, reclamam, mas não dizem direito o que querem) e talvez, Criptografia(ago + ou - básico).

Isso de datas vai mesmo entrar ? Qual seria a vantagem/diferença para as outras API de data ?

A meu ver a vantagem seria se focasse o calendário usado aqui , possivelmente com hipotese de consultar feriados e funcionalidade de dias úteis/ de trabalho

Algumas ideias seria:
o)Uma classe genérica chamada Interval para trabalhar com intervalos de qualquer classe que seja comparable ou tenha um comparator. Esta seria util em geral tb para a parte de moeda e de quantidades/métricas

Interval
start():Object
end():Object
construtor Interval(Object a, Object b , Comparator)
construtor Interval(Comparable a, Comparable b)
contains(object)
isEmpty();
intersect(Interval) Interval
union(Interval) Interval

o) Um TimeInterval que herde de Interval para intervalos de tempo em especifico. TimePoint para pontos no tempo que seria as estremidades do intervalo.
o)Depois classe para data sem hora, hora sem data e hora com data.
o)Conversão fácil para objetos do pacote sql.
o) class Month e Year que seriam TimeInterval e a classe Day
o) Month e Year seriam iteraveis Year itera os meses e Month os seus dias
o) permitir calculos de datas/ horas

TimeInterval extends interval
startPoint():TimePoint
endPoint():TimePoint
toPeriod():Period

TimePoint implements Comparable
until(TimePoint):Timeinterval

Month implements TimeInterval, Comparable
iterator()Iterator // de Day
getName();

Day
number(); // 1,2,3... etc..
isWorkingDay()
isWeekend()
isHolyday() // para feriados...
asDayOfWeek():DayOfWeek

DayOfWeek
SUNDAY // são singletons explicitos e constantes como um Enum
MONDAY
...
number()
getName() // Segunda, terça , etc..
isWeekend()

Period // para calculos
static days(int d);
static months(int m);
static years(int y);
plus(Period ):Period
minus(Period ):Period
days()
hours()
...

CalendarDate implements TimePoint / / subjudago a um Calendar
day():Day
year():Year
month():Month
static today():CalendarDate
static tomorow():CalendarDate
static yesterday():CalendarDate
previous():CalendarDay
next():CalendarDay
plus(Period)
minus(Period)

Exemplos de uso

P0000-07-01T12:23:14 <- padrão iso para periodos que significa que falta 7 meses , 1 dia , 12 horas , 23 minutos e 14 segundos para o dia 2008-01-01 à meia-noite.

-----

Para criptografia algo simples como
byte[] hash = CriptoUtils.md5("stringdeteste");
e
String hashbase64 = CriptoUtils.md5AndBase64("stringdeteste");

O primeiro devolde o hash propriamente dito, o segundo devolde o hash codificando em base64. Este é muito usado para passwords por exemplo.
claro que teriamos tb CriptoUtils.base64(byte[] bytes);

----
Dinheiro
Vamos trabalhar com várias moedas ou só reais ?

Money
ammount
java.util.Currency
// operações de soma etc..
// operações de divisão inteira e parcelada.

java.util.Currency é importante se for para várias moeda, porque contém a informação de quantas casas decimais a moeda aceita (nem todas as moedas tem centavos... algumas tem milésmos e algumas não tem parte decimal)

O truque do Money é usar um long internamente e não um BigDecimal que junto com Currency mantém tudo ok. E a importancia dele é na hora da divisão porque não pode desaparecer/ser criado dinheiro durante a operação.

uma classe abstrata para conversão entre moedas seria interessante tlv possamos fazer uma implementação simples com JDBC (tabela de cotações) para exemplificar. Ou lendo de um xml que seria bom para teste.

Teriamos tb Money m = Brasil.reais("124587") e Money m = Brasil.reais(1458,87) para facilitar as construções.
Formatação já existe com CurrencyFormat

---
pack de metricas: o que é isso a final ?
Pelo codigo parece-me que é conversão de unidades, mas é só isso ?
Espera-se poder converter todas as unidades para todas as outras da mesma especia ? qual é o objetivo e a necessidade aqui ? envolve calculos também ?

A meu ver a vantagem seria se focasse o calendário usado aqui , possivelmente com hipotese de consultar feriados e funcionalidade de dias úteis/ de trabalho

É esse o ponto.Não temos por objetivo concorrer com Time and Money ou Joda.
São apenas coisas específicas que o pessoal pede.
O Philip e o Fernando se não me engano tinham idéias sobre isso também.

Esta seria util em geral tb para a parte de moeda e de quantidades/métricas

Para datas me parece perfeito.

Para criptografia algo simples como

Eu já tinha exposto aqui outrora(ná época pensei até em Bouncy Castle), e eu acho essa abordagem mais simples melhor.

Vamos trabalhar com várias moedas ou só reais?

É inegável a preferencia por reais, mas se alguém tiver algo pronto para implementar, não vejo o porquê de não fazê-lo.

Pelo codigo parece-me que é conversão de unidades, mas é só isso?

No que tange a conversão, sim é só isso, até pq a API mais completa existente nisso é feita em javascript.Não existe nada disso em Java. Isso é uma feature que pode parecer imbecil(até pq é um mero conversor), mas todas o são até a necessidade de usá-las.
A maioria das pessoas não sabe por exemplo, que não existe KMH ou km/hora e sim km/h.

qual é o objetivo e a necessidade aqui ? envolve calculos também?

Poderá envolver, mas não no momento.É apenas um simples conversor de unidades relacionadas.

Nós não julgaremos as features(o q é idiota para um, é útilpara alguém) eu por exemplo, poucas vezes precisei de algo relacionado a datas, no máximo:

ou
Mas sei q muitos precisam de coisas mais sofisticadas do que isso.

Sérgio, você gostaria de implementar algumas dessas suas idéias para nosso projeto? Como Criptografia ou datas para os dias úteis?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Ironlynx wrote:

A meu ver a vantagem seria se focasse o calendário usado aqui , possivelmente com hipotese de consultar feriados e funcionalidade de dias úteis/ de trabalho

É esse o ponto.Não temos por objetivo concorrer com Time and Money ou Joda.
São apenas coisas específicas que o pessoal pede.
O Philip e o Fernando se não me engano tinham idéias sobre isso também.

Se o objetivo não é "concorrer" , então qual seria ?
Para o básico que vc exemplificou o java base chega e sobra....

Sérgio, você gostaria de implementar algumas dessas suas idéias para nosso projeto? Como Criptografia ou datas para os dias úteis?

Concerteza. Conto em pode enviar alguma coisa no fim de semana, baseado na estrutura que mostrei,mas até lá esperava por sugestões/criticas/ ideias e mais informação sobre o objetivo dessa parte da API.

Se o objetivo não é "concorrer" , então qual seria ?

Essas API´s são focadas só nisso(datas), por isso serão sempre muito mais especializadas.A função da BU é ser um "cinto de utilidades" do programador.É ajudar no dito "trabalho de corno" do dia-a-dia.

Conto em pode enviar alguma coisa no fim de semana, baseado na estrutura que mostrei,mas até lá esperava por sugestões/criticas/ ideias e mais informação sobre o objetivo dessa parte da API.

O objetivo é podermos prover soluções simples para problemas cotidianos(e outros nem tanto) para o dia-a-dia de um javaman.No fim de semana eu dou uma olhada na sua estrutura, reinstalei meu eclipse só agoradepois de uns bugs com o 3.3M3...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Ironlynx wrote:

Se o objetivo não é "concorrer" , então qual seria ?

Essas API´s são focadas só nisso(datas), por isso serão sempre muito mais especializadas.A função da BU é ser um "cinto de utilidades" do programador.É ajudar no dito "trabalho de corno" do dia-a-dia.

O qual seria esse "trabalho de corno" do dia-a-dia ? Eu queria exemplos do que está falando, pq não tou entendendo a diferença / utilidade dessa API

O qual seria esse "trabalho de corno" do dia-a-dia ?

A BrazilUtils visa aumentar a qualidade e produtividade de programadores que precisem de rotinas específicas ligadas ao dia-a-dia brasileiro.

Serve para que eu e outros colegas não tenhamos que escrever cada um por sua conta rotinas para validar Inscrição Estadual, CPF/CNPJ, conversão de valores métricos, colocar valores em Real por extenso, além de outras features que vêm por aí.

Afinal, duas ou mais cabeças fazem algo melhor do que uma.

Eu queria exemplos do que está falando, pq não tou entendendo a diferença / utilidade dessa API

Agora eu não entendi. Então qual o seu interesse aqui? Mais uma vez, sugiro que você estude um pouco melhor a API - nem estou falando da implementação - e veja os últimos posts na primeira thread sobre a BrazilUtils. Terá respostas para muitas de suas perguntas.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

RafaelRio wrote:

O qual seria esse "trabalho de corno" do dia-a-dia ?

A BrazilUtils visa aumentar a qualidade e produtividade de programadores que precisem de rotinas específicas ligadas ao dia-a-dia brasileiro.

Serve para que eu e outros colegas não tenhamos que escrever cada um por sua conta rotinas para validar Inscrição Estadual, CPF/CNPJ, conversão de valores métricos, colocar valores em Real por extenso, além de outras features que vêm por aí.

Afinal, duas ou mais cabeças fazem algo melhor do que uma.

Eu queria exemplos do que está falando, pq não tou entendendo a diferença / utilidade dessa API

Agora eu não entendi. Então qual o seu interesse aqui?

Um subconjunto de uma API ainda é uma API...Eu estava especificamente falando da API de datas !
Como a BrazilUtils para datas seria usada na prática , exemplos de casos de uso para que eu entenda a diferença entre ela e outras API de data que existem. Uma vez que o objetivo não é inventar a roda então qual é o objetivo dessa parte da API ?
Deu para entender ?

Sim, agora ficou claro!

Acontece que nós não temos um conjunto fechado e pronto de requisitos. Nós estamos aberto para solicitações de features a partir da comunidade, e entre essas funcionalidades estava algo relacionado a datas.

Mas exatamente o que relacionado a datas, isso nunca ficou claro e é por isso que não temos nada sobre isso ainda na BrazilUtils.

Damos prioridade aos requisitos que já estão bem definidos. Por exemplo, assim que eu terminar de escrever o tutorial da versão 0.1, começarei a implementar a normalização de endereços.

Essa normalização de endereços depende do Douglas. Trata-se de padronizar a forma escrita de um endereço num software. Por exemplo, quando alguém escrever "R. ERNESTO da SilvA, 168", após a normalização o endereço poderá ficar "Rua Ernesto da Silva, 168".

Isso é bem trabalhoso por causa da quantidade de logradouros e da imensa variedade com que são escritos, além de ter que que contar com flexibilidade de configuração - talvez alguém possa querer normalizar tudo para maiúsculas.

Se você tiver interesse em colaborar, acho que pode começar por aqui, nos ajudar nessa feature. Mas, como disse, essa funcionalidade de normalização depende do Douglas, o que equivale a dizer que ele tem o know-how sobre isso e tudo passa sobre o crivo dele.

Então a primeira coisa que temos que fazer antes de enviar código é obter maiores informações para que isso não fique dependendo demais dele e fique parado caso ele não tenha tempo de trabalhar na BrazilUtils.

A BrazilUtils visa aumentar a qualidade e produtividade de programadores que precisem de rotinas específicas ligadas ao dia-a-dia brasileiro.

Exato.Esse é o ponto.

Imagine só o tempo que se perde só procurando requisitos para essas rotinas...

Douglas, essa é pra você. Estava fazendo testes adicionais como combinado, daí encontrei um erro.

Esse modo está retornando falso quando o CPF é verdadeiro e vice-versa. Segue o código corrigido (só troquei != por ==).

Aí Sérgião, o pessoal do Ohloh discorda de você!

BrazilUtils API is written mostly in Java.

Across all Java projects on Ohloh, 35% of all source code lines are comments. For BrazilUtils API, this figure is 45%.

This high number of comments puts BrazilUtils API among the highest one-third of all Java projects on Ohloh.

A high number of comments might indicate that the code is well-documented and organized, and could be a sign of a helpful and disciplined development team.

Sobre normalização de endereços:
1 - Qual é a lista dos Tipos de Logradouro que será adotada? tem uma que eu estava usando na versão que não fo disponibilizada que era baseada no site do correio). Essa questão parece boba mas não é. O que fazermos com tipos de logradouro de sistema legados? No meu sistema, aqui, tem "Buraco", "Vala" e "Trincheira" entre outros

. Todos aceitos pelos correios.
2 - Quais são os campos usados no endereço? Estava assim: TipoLogradouro, NomeLogradouro, Numero, Complemento, Bairro, Municipio, UF e CEP. Devemos usar País também? Mais algum?
3 - Tinha pensado em 2 classes pra fazer isso (além do endereco) Normalizador e Normalizacao. Onde um normalizador aplica uma (ou mais) normalização sobre um endereço. O Normalizador contém uma ou várias Normalizações. Assim o cliente da API pode implementar uma NormalizacaoEspecializado oumemso um NormalizadorEspecializado que já é iniciado com algumas Normalizações dentro dele. Normalizador tem add e remove pra colocar e tirar Normalizações. algu assim ...

4 - Os Tipos de Logradouro virão em um XML ou similar? A lista de municípios também? Em resumo: O que fazer com as listas?

Esses três pontos já são um bom ponto de início. Gostaria da opinião de vocês.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

dsiviotti wrote:Sobre normalização de endereços:

A Lista de logradouros está hardcoded nos fontes, mas seria interessante realmente usar xml. A ideia da normalização é boa , contudo voto a favor de usar Format como base de tudo o que seja mexer con texto. Normalização seria FormatRule ou mesmo NormalizationRule
Se vc der uma olhada no codigo verá divisão do endereço , veja tb o codigo que eu deixei antes e compare. Eu acho que deveria ter pais sim
e cep e como campos especiais, porque isso permitirá implementar um serviço de busca de endereço pro cep.

Minha opinião:

1) Os logradouros suportados pela API devem ser os mesmo que os Correios aceitam, sem tirar nem pôr. Se acrescentarmos ou retirarmos algo, um carteiro novato pode se perder.

2) País também, com certeza! E se algum exportador utilizar a API?

3) Esse "algu assim" é um começo. Podemos implementar isso, testar e ver onde podemos melhorar. Acho melhor debater em cima de algo concreto. Temos que literalmente experimentar, só filosofar não vai levar a nada.

4) XML. Vamos ter que compilar os oitocentos milhões de municípios brasileiros?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

RafaelRio wrote:
4) XML. Vamos ter que compilar os oitocentos milhões de municípios brasileiros?

Não é um XML com os nomes dos lougradouros, é um XML com os tipos de logradouro.

Enquanto não ha nada concreto para discutir sobre, deixem-me so chamar a atenção para 2 pontos:
1) Normalização de endereços é um assunto complicado. tanto que ha programas proprietários para isso. Tudo bem que façamos uma normalizaão simples, que acaba sendo quase que apenas uma formatação, mas acho que não podemos ir muito mais longe... Ou seja, descobrir a 1001 formas de escrever rua ou avenida não é tão simples quanto parece. (envolve ter um banco de dados ou vários e processá-los)
2) Nem todos os endereços têm a mesma estrutura. E já que se falou de colocar o pais, então cada pais tem a sua estrutura. Mas mesmo apenas no brasil existem várias estrutura, por exemplo como eu separo este endereço dos campos municipio/bairro/logradouro/numero/complemento ?

Estrada Ponta Leste, Km 07
Estrada Parque ? Km 17 ? Abobral

A resposta é: não separo. Posso dizer que o logradouro é do tipo estrada e o nome e dizer que km X é o numero ou o complemento, mas não terei bairro , por exemplo. Tlv nem municipio. E numero/complemento é em quilometros ? Como eu formato isso depois ?

A API de endereços parte do principio que todos os endereços tem esse campos, mas isso não é verdade para o Brasil e muito menos para os outros paises.

A validação de CNPJ e afins é muito util realmente , mas Datas e Endereços dava uma API por si mesma. E o pior é que excepto as validações , o resto é muito susceptivel de internacilização/localização o que dificulta muito o problema.
Agora , alguém pode dizer para focar apenas no Brasil e esquecer os outros paises. Tudo bem, mas então no brasil ninguém manipula endereços/telefones/unidades de outros países ?
Acho que vcs têm que ficar conscientes do trabalho em que se vão meter se quiserem fazer algo minimamente util. Colocar municipio/bairro/logradouro/numero/complemento num bean e jogar um formatdor em cima não vai resolver o problema... afinal isso é o que todo o mundo faz porque provavelmente tem um banco com esses campos.

Então, eu acho que poderiamos fazer :
1) API de validação de CNPJ , CPF e afins - é realmente util ter isto pronto
2) API de manipulação de dinheiro - é simples de fazer e é util.
3) Criptografia simples - tb util pois deve ser usado para passwords e todo o sistema que se preze te password.
4) API de tempo - Aqui temos vários graus conforme o problema que queremos resolver ( que ainda ninguem disse qual é...)
4.a) Uma classe que extenda Calendar e possibilite as operações isHoliday(), isWorkingDay() e isWeekend() - simples demais, mas util
4.b) Uma classe que não herde de Calendar , mas o use internamente e possibilite as mesmas operações - simples tb , na realidade a questão está na compatibilidade deste classe
4.c) Uma API simples para escreve datas sem hora, etc.. junto com a classe de 4.b) destinando-se a facilitar o transporte de datas e tempos entre camadas com suporte para conversão para datas do java.sql algo como CalendarDate date = new CalendarDate(2007,1,1);
java.sql.Date sqlDate = date.toSQL(); Também o suporte a intervalos de datas e horários, o que tb é simples e util.
4.d) A API de 4.c mais um mecanismo de calcular diferença e soma de temos com e sem timezone. Tb conversão de horas entre time zones
4.e) A API de 4.d mais facilidade de conversão entre os diversos tipos de objectos definidos.

5) API de Quantidades/Unidades aka Métricas (cuidado que esta palavra não se usa neste como sinônimo de medida física) - Esta tb é dificil deêm uma olhada em JScience para terem uma ideia de onde pode chegar a complexidade.
Aqui é muito importante o objectivo! Pelo que foi dito o objectivo é a conversão. Ora mas isso é exactamente o mais dificil!
5.a) Tal como está agora o negocio seria ter uma classe para cada dimensão e métodos para converter essa dimenção entre N combinações de unidades, por exemplo: Temperature.celciusToFahrenheit() e Temperature.fahrenheitToCelcius() e Temperature.kelvinToCelcius() e
Temperature.celciusToKelvin() e assim vai.
5.b)Tudo bem, mas isto implica num código imenso e pouco organizado.
Tlv seja uma boa pensar no conceito de conversor

Converter
convert (numero)
invert():Converter

Ali eu escrevi numero pq não sei em que classe colocar. double é RUIM , mas tb não sei que precisão é necessária. Suspeito, contudo, que se tratando de unidades especiais como de energia, o uso é cientfico, então tvl seja bom usar BigDecimal.
5.c) Ou criar um objeto semelhante a money que agrega um valor e uma unidade. E por falar nisso uma classe de unidade.

Com os conversores não temos que ter uma classe para cada dimensão e poderemos ter um registro central (padrão registry) para obter os conversores exemplo:

Mesure x = new Mesure(40, Unit.CELCIUS)
Converter converter = ConversionUtils.getConverter(Unit.CELCIUS , Unit.FAHRENHEIT);
Mesure y = converter.convert(x);
Mesure x = converter.invert().convert(y); // isto resultaria em x de novo

Ou
Mesure x = new Mesure(40, Unit.CELCIUS);
Mesure y = ConversionUtils.convertTo(x, Unit.FAHRENHEIT);

E poderiamos fazer
Mesure x = new Mesure(40, Unit.CELCIUS);
Mesure y = new Mesure(60, Unit.CELCIUS);

Mesure media = x.plus(y).divide(2); // 50 ºC

e
Mesure x = new Mesure(4, Unit.METER);
Mesure area = x.time(x); // 16 metros quadrados

5.d) permitir operações com unidades diferentes mas que são da mesma especie, por exemplo grama com quilo ou km com milha.

5.e) permitir conversões por translação. Por exemplo, se não tiver o conversor km -> milha , poderia ter km -> pé e pé -> milha , o sistema concatenaria os dois para constuir um conversor km -> milha (esta é bem mais avançada mas diminuir a necessidade de criar muitos conversores)

O trabalho forte é criar os conversores para os pares de unidades e registrar no ConversionUtils

6) Sistema de endereços. Aqui o negocio é bem mais complexo. ´8E necessário definir um escopo para isto.

Proponho que se lista listagem como TODO pela ordem. Apenas os itens mais avançados de 4,5 e 6 podem ser bem complicados. o resto é simples, simples

P.S. ainda não vi comentários às classes que enviem ...

Notícias, artigos e o maior fórum brasileiro sobre Java