| Autor |
Mensagem |
|
|
Olá
Há algumas opções de DP free:
http://www.patterndepot.com/put/8/JavaPatterns.htm
http://www-106.ibm.com/developerworks/edu/j-dw-javapatt-i.html
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/ <-- Mais para C++
Este aqui em português:
http://www.globalcode.com.br/content/gdc/apostilas/index.jsp
CV,
Patterns of Enterprise Application Architecture, Martin Fowler.
Há tempos venho namorando este livro. Já tenho DP do Gamma et all (gang of four) e o Core J2EE Patterns. Realmente vale a pena comprar mais este?
[]s
Luca
|
 |
|
|
Olá
Uso o omondo para fazer os diagramas de classe de programas prontos ou em desenvolvimento. Vejo diagramas de códigos feitos por outros integrantes da equipe (que não documentaram).
Com omondo e DJ Java Decompiler percebo como é importante usar um URLClassLoader com criptografia.
[]s
Luca
|
|
|
|
Olá
1) Não há diferenças nos browsers quanto ao aspecto de assinatura de applets.
2) Trecho de build.xml com vários jars sendo assinados para que lembre de assinar TODOS que vão para a applet:
[]s
Luca
|
|
|
|
Olá
Se você vai comparar ferramentas free e usa o eclipse não deixe de experimentar a versão free do plugin "omondo" (http://www.omondo.com/). Permite fazer diagramas de classes prontas coisa que a versão free do poseidon não permite. Comecei a usar há pouco mais de um mês, ainda estou maravilhado.
[]s
Luca
|
|
|
|
Olá
Quando seu patch contém diretório com brancos no nome como é o caso do Documents and Settings é de bom alvitre coloca-lo entre aspas no classpath. Por exemplo:
set classpath=.;C:\"Documents and Settings\eduardo\My Documents"\PUC\Projeto\GraphEditor_exec\diamante.jar;%classpath%
Mas seu problema talvez seja a localização de classe dentro de pacotes. É isto que você precisa rever. Qual o comando que está usando para executar o sistema? Aí deve estar o erro.
[]s
Luca
|
|
|
|
Olá
Meu problema não é fazer os cronogramas e sim ler aqueles feitos por outros que usam o Project. Um dos únicos motivos porque não largo de vez o Windows e troco pelo slack é não saber abrir arquivos do Project fora do MS Project.
Algum destes freewares consegue abrir e eventualmente alterar arquivos do Project? Alguém conhece algo assim para o Linux? Se conseguir abrir já resolve 90% dos meus problemas.
[]s
Luca
|
|
|
|
Olá
1. Notas fiscais
As notas fiscais devem ser impressas em impressoras fiscais, as famosas ECFs. Isto vale tanto para as vendas como para os boletos de cartão de crédito.
Antigamente a gente para imprimir em uma ECF precisava programar em C ou assembler para cada impressora em particular. Eu mesmo fiz isso em assembler. É óbvio que ficava um legado dificil de manter. Colocar uma nova funcionalidade significava mexer nos programinhas de todas as impressoras. E havia um monte delas no mercado.
Logo alguém viu que seria melhor criar uma interface padrão que TODOS os fabricantes deveriam respeitar. Assim cada fabricante desenvolve sua biblioteca compartilhada (dll no windows, shared library no Unix) que pode ser acessada pelos sistemas de frente de caixa ou de TEF na captura de cartões de crédito.
Pelo exposto, os sistemas tanto em Java como em qualquer outra linguagem não devem acessar diretamente a impressora fiscal. Devem trocar informações com a biblioteca compartilhada fornecida pelo fabricante da ECF.
O Java não consegue chamar diretamente um método dentro de uma "dll" ou uma "so". Precisamos usar como intermediário o nosso amigo das horas dificeis que é o JNI. É isso que você deve estudar e não é tão dificil assim.
2. Relatórios
Todas as ferramentas que tentei usar para fazer relatórios direto do Java me decepcionaram. Quem não ficar satisfeito criando relatórios em PDF e contando com o Windows (ou Linux) para imprimir o PDF sem avisar ao Java se deu certo ou não, sabe o que pode fazer?
- Criar uma aplicação em uma outra linguagem própria para relatórios e deixa-la rodando direto no cliente. Ela ficará lendo o conteúdo de um diretório qualquer ou recebendo conteúdo por sockets.
- O Java cria o relatório em txt, xml ou qq outro formato. Envia para o programinha por sockets ou grava o tal arquivo, neste caso de preferência criptografado.
- A criação pode ser feita no próprio servidor ou no cliente se for uma aplicação do tipo applet. A gravação no cliente precisará de uma applet com permissões para tal. Se nossa aplicação for do tipo com interface web, precisaremos na página HTML de javascript para falar com a applet usando JSObject. Ou então que a aplicação que imprime relatório escute HTTP para receber GETs ou POSTs da página HTML.
- A outra aplicação lê o tal arquivo, formata o relatório bonitinho como o chefe pediu, imprime e avisa ao sistema Java que a impressão terminou.
Complicado? Se nosso trabalho fosse simples a gente ganhava só mil real...
[]s
Luca
|
|
|
|
Perfeito!
Melhor ainda se usar o tailme para acompanhar as saídas. É o velho e bom tail do Unix versão windows. Procure no google por tailme. Fiquei conhecendo esta gracinha hoje.
[]s
Luca
|
|
|
|
CV
Morri de rir com seu post.
O que um CEO que mesmo são notas fiscais. O que eu e você fazemos para ele é custo, assim que puder ele reduz isso.
Mas nossos CEOs estão perdidos porque quando vão comprar uma solução para as notas fiscais vendem para eles "ambiente integrado de execução de aplicações de e-business on demand conectadas através de webservices e redes peer-to-peer escaláveis, robustas, seguras e gerenciáveis" e agora tudo isso em grid.
Nossos empregos só estão garantidos porque eles gostam de citar tudo isso durante o jogo de golfe e precisam da gente para traduzir as siglas de última geração.
[]s
Luca
|
|
|
|
Olá
Recomendo a própria documentação do keytool e que leia o artigo em: http://www.das.ufsc.br/jacoweb/restrito/documentos/assinatura/#introducao
[]s
Luca
|
|
|
|
Olá
1) Em Windows se quiser deixar um processo aberto em execução basta iniciar o programa e não fechar a janela "command" de emulação do DOS.
Em Linux há muitas variáveis e você precisa entende-las. Não basta eu ficar dando receitas de bolo falando em usuários e seus poderes, & (processo em bg), nohup (não interrompe processo ao fechar sessão), redirecionamento de saída, etc. É realmente mais produtivo que você adquira um mínimo de informação. Veja o manual de administração do sistema Unix da editora Bookman. Lá tem tudo que precisa e mais um tiquinho que é sempre bom saber.
2) O modo de executar um método main é usar o link já indicado no post anterior.
[]s
Luca
|
|
|
|
Olá
Sou rato das reuniões do SouJava. Parafraseando um outro gujeiro, tem papo de Java, estacionamento grátis, coffee break, tô dentro!
[]s
Luca
|
|
|
|
Olá
1) Que sistema operacional está usando?
Serve uma thread? Ou precisa ser um processo controlado pelo sistema operacional?
2) Para executar qualquer programa a partir do Java veja: http://www.guj.com.br/forum/viewtopic.php?t=7865
Nos ajude a ajuda-lo.
[]s
Luca
|
|
|
|
Olá
Vi a reportagem não muito elogiosa no caderno de informática da folha. O que vai vir de pedrada por aí não está no mapa.
O que a Sun pretende? Ser mais uma empresa distribuidora de Linux? Ou este será apenas um balão de ensaio para o Linux nas máquinas Sun?
Será que pretendem pavimentar a estrada para a adoção do JSF nos desktops não windows? Porém, para isto acontecer, o Java precisa conseguir se comunicar com os periféricos e a gente conseguir emitir uma nota fiscal nos quadradinhos certos. Será que seguiremos necessitando de sockets com servidorzinhos locais para saber se a impressora tem papel?
Desculpem, ainda estou com o texto da outra pasta na cabeça e com raiva de poder usar generics mas não poder fazer um relatoriozinho qualquer.
[]s
Luca, no aguardo do J2SDK 1.6
|
|
|
|
Olá
1) What are J2EE's strong points? Java's strong points?
J2EE ponto forte = é Java e portanto roda em qualquer plataforma. No momento bastante abrangente para contemplar um grande número de necessidades de uma empresa. É suportado por alguns aplicativos open source como maven (ou mesmo o ant) e framewoks como struts, hibernate, etc
Java ponto forte = tem um monte de APIs. Quase sempre encontramos solução free para nossos problemas de programação.
2) How do you see the industry leveraging them today? Tomorrow?
As grandes empresas seguem apostando alto. Como remar contra Oracle, IBM, BEA e outras.
Amanha? Empresas deste porte são ágeis mas não tanto para mudarem de rumo em pouco tempo. Mais do que a Sun, são estes nossos mais fortes aliados de seguir feliz sem precisar aprender C#. E se esse dia de aprender .NET chegar, podemos ter certeza que estes grandões nos ajudarão a decidir que rumo tomar.
3) What are J2EE's weakest points? Java's weak points? What do you think the solution might be?
J2EE pontos fracos = complexidade de algumas partes, dificuldade de migrar de um servidor para outro de forma indolor e processo de evolução lento e centralizado. Não duvido que uma IBM em futuro próximo perca a paciência com a burocracia da Sun e lance suas próprias inovações.
Java pontos fracos = A própria Sun. Vejam a ameaça da versão 1.5 com fortes mudanças que não prometem responder aos reais anseios da comunidade. Algumas deficiências do Java seguirão na mesma como a inadequação do Java (quando comparado ao Fortran) para o processamento científico. A dificuldade de uso de periféricos seriais ou a impossibilidade de acesso na porta paralela quando necessário tratamento da resposta. A API javax.comm estacionou no tempo e continua com o bug no acesso bi-direcional na porta paralela. Todo comércio e todos os bancos usam periféricos. Faltam APIs para relatórios. Em vez de resolver estas deficiências a Sun prefere investir em generics. Será generics algo imprescindível para os bancos escolherem Java nas suas milhares de agências?
Para mim a solução seria a Sun abrir mão do controle do Java. O futuro da linguagem depende da adequação aos anseios da comunidade e não da cabeça de meia duzia de cientistas. A Sun está um pouco perdida e ainda não sabe como ganhar dinheiro com Java. Se morde de ciumes da Oracle e da IBM que enchem os burros com a invenção da Sun. O declínio da Sun pode ser uma ameaça se a Sun continuar mantendo o Java como coisa somente sua.
4) Do you think the J2EE application server market is saturated at the moment? Too many servers? Too few servers?
Mercado de servidores não está saturado. Na verdade está pouco segmentado. Não atende às necessidades dos diferentes consumidores. Ficou igual à antiga disputa dos vídeo cassetes para ver quem incluia mais funções que ninguém aprendia a usar.
Se um banco quiser conectar suas agências a um poderoso servlet engine e usar JDBC ou hibernate na camada de persistência, são poucas as soluções disponíveis. A própria IBM ainda não percebeu que alguns clientes podem querer apenas comprar um carro veloz e confiável e não toda uma carreta de 36 rodas. Alguns arquitetos de sistema tem dúvidas quanto às reais vantagens do uso de EJBs. Então para que levar de contrapeso um caríssimo EJB engine?
5) How would you advise someone looking for a J2EE app server to evaluate all the choices?
Como avaliar os servidores = nada como a experimentação. O planejamento da capacidade de servidores, as métricas e os modelos matemáticos, erlang, a teoria das filas, simulação, todo este ferramental precisa de dados reais. Para avaliar se nossos servidores serão adequados ao níveis de serviço prometidos ao cliente não vejo outra alternativa senão testar um a um em um hardware mais próximo possível do que vai ser usado na produção. Até aqui nada de novo.
Mas quero enfatizar que esta questão tão crucial nos negócios as vezes é decidida apenas pela colocação do dedo no vento ou pela simpatia do diretor por determinada marca. Nem sempre o servidor escolhido atende bem a um custo correto aos níveis de serviço que ocorrerão no dia a dia do negócio. Conselho: não use um rolo compressor de 16 rodas apenas para dobrar uma folha de papel.
6) What value-add do you see the new open-source server putting in to the J2EE community?
Para mim os servidores open source são exatamente aqueles mais adequados aos clientes pois é neles que as aplicações são desenvolvidas. A migração para os servidores comerciais na homologação ou na produção geralmente procura manter a compatibilidade com os ambientes de desenvolvimento.
O nosso amado tomcat mesmo com seus probleminhas de performance quando mantido na configuração default e sem uma correta sintonia fina na JVM 1.4.x, segue soberano para servlets e JSPs. Não sei até que ponto a nova versão 5.0.16 melhorou em termos de performance. Mas vai ser o primeiro já pronto para as novas versões das especificações. E deve ser o primeiro a servir as tão aguardadas Java Server Faces.
7) What do you see J2EE being in a year? Two years? Three?
Futuro. Java + J2EE estão sendo largamente utilizados hoje e é isto que garante nosso futuro próximo, com certeza por mais de 2 anos. Tudo vai depender da capacidade da Sun responder aos anseios da comunidade.
A longo prazo outras tecnologias surgirão não sei de onde num tempo em que J2EE e .NET já estarão obsoletas. Quando? No mínimo daqui 3 ou 4 anos, mas no máximo daqui a 5 ou 7 anos. Mesmo depois do Java/J2EE estiver decrépito e enterrado, esta grande massa de aplicações já desenvolvidas ou em desenvolvimento garantirão serviço Java / J2EE para alguns por mais 10 anos.
É o que penso. Será que esqueci de muita coisa? Aguardo adendos e comentários
[]s
Luca
|
|
|
|