| Autor |
Mensagem |
|
|
Utilize os filtros do java como aqui: http://java.sun.com/docs/books/tutorial/uiswing/components/filechooser.html
E no método accept, abra a imagem, busque o tamanho dela (Image.getWidth() e image.getHeight()) e aceite se < 250X250.
|
 |
|
|
http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html
http://schmidt.devlib.org/jiu/index.html
|
|
|
|
Oi Paulo,
Tentou usar um resampling baseado no Lanczos? http://en.wikipedia.org/wiki/Lanczos_resampling
O Picasa usa ele, deve te dar bons resultados.
Posta aí se ficar bom 
|
|
|
|
Bom, eu já tentei conversar sobre uma fusão mais de uma vez com coordenadores do PJ e do GUJ. Eu até tenho em casa um documento de 3 páginas declarando como ficariam os servidores, coordenadores, projetos e demais atividades que cada portal realiza.
Infelizmente os 3 portais tem donos (como disse o urubatan), egos muito fortes e idéias equivocadas sobre várias pessoas, uma fusão é impossível.
|
|
|
|
hahahaha 
Cara.. joguem seus certificados no lixo, a partir de hoje MCP não vale mais nada
kkkkk
PS: Também Kid-Click é foda
|
|
|
|
scottys0 wrote:
vfpamp wrote:
- EJBs
Errado, tente evitá-los
Por que ? Ejbs não são melhores pra grandes aplicações
São, e não são..
Vai do que você fizer e como fizer. O problema do EJB é que ele é um elefante branco altamente mutável (Vide EJB2.0 e EJB3.0) e nada portável entre os servidores  . Além de, claro, ser chato e trabalhoso pra cassete.
My 2 cents
|
|
|
|
mister__m wrote:
louds wrote:LDAP é uma ótima escolha, só toma cuidado com o servidor que escolher.
Fuja da idéia do Vitor, gerenciamento de usuarios de verdade é usando LDAP.
+1. Pra qualquer coisa que você pretenda integrar, LDAP é bem melhor que aquela tabelinha sem-vergonha que você modelaria. Contudo, daí as empresas deixarem você usar LDAP... 
Se te deixam, comece já!
Po, será que é só eu que não gosto de LDAP? hehehe
Sei la... muita complicação para pouco resultado.. claro, a não ser que você realmente vá usar todos os recursos da LDAP, como validação em árvores e aquela coisa toda...
|
|
|
|
Vira de cabeça para baixo e reprocessa.
Vamos lá....
- começaria do basico, Utilizaria JAVA ....
COOL +
- EJBs
Errado, tente evitá-los
- Jldap para controle de usuarios com grupos e permissoes
????
Create table user (nome varchar(30), senha varchar(20));
- não gostaria de utilizar frameworks MVC (sugerido Struts pela empresa ... )
Errado, USE! Struts, WebWork, JSF, JBanana, etc
- Controles de Telefonia por applets acessando servidores por socket.
???? Nossa... Socket? Não da para usar WebServices não, ou um servlet?
- Relatorios on-line com jasper reports + JSP
É bomzinho, mas eu gosto mais do JFreeReport
- Logicas de acesso a a dados implementadas por stored procedures ( minhas DAOs ficariam mais simples ... ??!!)
Ficariam beeeem simples, aliás, vc nem precisa de DAOS ehehehhe. Dica... tente não usar essas stored procedures
- Logicas de geracao de relatorios implementados por stored procedures
Idem ao anterior
- Alta disponibilidade (3000 a 4000 acessos simultaneos )
3000 a 4000 acessos simultâneos? O que tu vai fazer, um Grid de reconhecimento de padrões das fotos tiradas a cada segundo dos satélites da nasa da Terra?
Não precisa exagerar... começe do início... do Java
|
|
|
|
Arcadex wrote:Cara, eu uso Hibernate a 6 meses.
Minha aplicação nunca gerou um SQL assim.
Acho bom vc revisar o motivo dessa doidera aí.
Eu uso ele a 2 anos na mesma aplicação
|
|
|
|
rodrigousp wrote:
Peraí !!! O "mapeamento + esquema do BD" tá caprichado demais...
Nunca consegui tal proeza!
Se você não quer salvar (ou atualizar) em cascata todas entidades penduradas... cascade=none (ou delete).
Acho que manter as chaves bem simples, também deve ajudar horrores.
Mas, precisaria ver o mapeamento para entender o problema.
Cascade está ativo só no detalhe do cara (uma tabelinha com 3 registros).
Mas, exato... o mapeamento e as classes do hibernate estão overpower, praticamente uma cópia do diagrama de classe da aplicação. Muita coisa interligada... e é por isso que da essas merdas aih.
|
|
|
|
cv wrote:Os nomes dos campos dessas tabelas precisam seriamente de uma revisao, ou vao comecar a perguntar onde foi parar o molho bolonhesa ao ver o diagrama 
Tirando isso, qual o problema do hibernate fazer selects e trazer dados em lazy-loading? Sabendo configurar o bichinho, o aumento de performance eh bem significativo 
O problema é que esses selects todos aih ele faz num UPDATE de registro. Não precisa nem verificar o lazy é só salvar.. saca, aquele update xxx set xx = xxx where id = x
E só fazer isso!!!
ah... o Objeto é um master / detail com certa de 10 campos e uns 3 many-to-one
|
|
|
|
urubatan wrote:se o cara aprender a configurar direitinho o que deve ser lazy load, para que a hierarquia de objetos não seja carregada toda na memoria de uma vez só, vai ajudar bastante
Olá galera..
Acontece que one-to-one e many-to-one não tem lazy e não adianta usar proxy. E essa coisa toda aih é durante um SAVE, ele está validando as dependências
Lipe, não é que o hibernate não saiba fazer select, é que ele adora fazer selects
PS: Notem que o jprogrammer copiou só metade do select
hum... e o que tu diz de um administrador do JavaFree respondendo no GUJ?
[]s
|
|
|
|
Rafael,
O CV disse tudo:
CV wrote:
Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.
Todo o framework tem um determinado nível de "genericidade", ou seja, ele é generico e configurável até certo ponto. Como o framework é para a sua empresa e nada mais, eu sugiro vc criar o framework fortemente acoplado as decisões da sua empresa.
Lembre-se que se acontecer alguma mudança nessas decisões, alguém da sua empresa pode alterar o framework em nível de código fonte. Vc não precisará criar inúmeros arquivos de configuração para utilizar o framework, e com isso, você ganha muito tempo de desenvolvimento.
Em outras palavras, fazer coisas genéricas nem sempre é a melhor saída, porque, além de esperar por uma mudança que talvez nunca aconteça, é possível que o código ainda esteja errado.
Como disse o CV, crie o seu framework ao longo do tempo em que desenvolve o sistema. Assim que detectar que algo pode ser "genérico" você o faz e separa dos fontes da aplicação.
Refactoring é a palavra mágica
|
|
|
|
Como eu disse, questão de escolha... Nada melhor do que você gostar do que estiver fazendo, seja com o que for.
Ueh.. tem gente que usa Delphi com Paradox para desenvolver ERP distribuído, porque eu não posso usar o Prevayler com Multipla Herança? Quem sabe acessando alguma coisa de CSP ou RE. Sei lá.. tem tantas loucuras por aih a fora que múltipla herança acaba sendo só um detalhe.
|
|
|
|
maresp wrote:
vfpamp wrote:Bom, ao meu ver, ainda da para adicionar uma série de coisas na linguagem para torna-la mais "escolhível": Múltipla herança, AOP nativo, evoluções no "for"...
 Herança múltipla? Vc não falou sério né?
Sério...
Embora muita gente odeie ela, eu gosto da agilidade que ela cria.
http://www.javafree.com.br/forum/viewtopic.php?t=10008&highlight=heran%E7a+multipla
É uma escolha, se vc souber usar fica tranquilo
|
|
|
|