| Autor |
Mensagem |
|
|
LPJava wrote:hehe, faltou citar um fator importante, faixa salarial minima para a vaga  .
Quem responde isso é você, não? Eu sei o quanto quero pagar no máximo.
|
 |
|
|
Atualmente a Montreal Informática está com uma vaga em aberto para trabalho alocado na Petrobras Distribuidora. Seguem os dados:
Regime: CLT;
Benefícios: Pl de Saúde e Dentário SulAmerica, Vale transporte e Vale Alimentação ou Refeição. Seguro de vida.
Disponibilidade: Contratação imediata.
Requisitos: Java 1.4, EJB 2.1, JDBC
Desejado: Portlets, JSF, Websphere
O local de trabalho é:
Rua General Canabarro, 500
Maracanã, Rio de Janeiro
Favor encaminhar o curriculum para nicholas[arroba]br-petrobras.com.br com pretensão salarial.
|
|
|
|
hugleo wrote:Em um Set ou Get é sempre melhor dar sets e gets em todos os campos ou há alguns casos em que é preperível dar sets em uma estrutura que seria coleção de váriso dados?
Acho que depende muito da sua logica... Se voce permita o desenvolvedor acessar diretamente a sua coleção, ele pode adicionar um objeto sem que o seu controle seja realizado. O encapsulamento está todo quebrado nesse caso.
Um exemplo é uma associadao entre Turma e Aula. Uma Turma tem várias aulas associadas a ela. E uma Aula só pode ser associada a uma Turma. Imagine o codigo abaixo:
Voce possui a mesma Aula em duas Turmas distintas. Se voce fizesse um metodo
Isso poderia ser evitado por a validacao de que aquela aula estaria associada a outra Turma estaria garantida.
|
|
|
|
Aqui no trabalho passamos por esse problema e usamos a seguinte solução... Nao sei se eh a melhor porque ainda nao fizemos a migracao, mas parece funcionar bem.
1 - Como disse o rissato, todas as classes tem interface e um construtor padrao
2 - Elas sao mapeadas como atributos nos Managed Bean dos JSF
3 - Ao recuperar uma classe de negocio, vemos se a mesma foi "injetada" pelo repositorio. Caso contrario, usamos um ServiceLocator para buscar no Spring e entao no InitialContext.
Acho que atende...
|
|
|
|
|
Como disse, o Struts é mais tranquilo pois não me trava em nada na página! Posso usar o ActionForm só para receber os parametros do request e a volta para a página eu faço totalmente através de atributos. É trabalhoso, eu sei, mas não me obriga a usar o FW na apresentação. Já o JSF é um porre, pois sem a apresentação ser modelada para o JSF eu não consigo usar a camada de controle.
|
|
|
|
Estava discutindo hoje no trabalho sobre a separação entre as camadas de controle e apresentação no MVC. Pela proposta da arquitetura, eu poderia alterar completamente a camada de apresentação sem que isso fosse impactar na minha camada de controle afinal, tudo que ela veria seriam requests e responses. Na minha idéia, eu poderia criar uma camada de apresentação em PHP, Flex ou qualquer outra linguagem/framework enquando usaria meu framework de preferencia na camada de controle. Ai surgiram as minhas dúvidas...
Hoje umas das referências que temos em frameworks MVC são o Struts e o JSF. Mas nenhum dos dois permite que eu desacople totalmente as minhas camadas. O Struts ainda é mais flexível no que se trata da resposta a camada de apresentação pois faz o redirecionamento e posso passar os parâmetros pelo request para a página. Mas o JSF amarra completamente as duas coisas! Se eu não declaro um f:view no meu JSP (só posso usar JSP), o Servlet não funciona! Isso não está errado? Eu sou obrigado a usar os componentes X e Y na apresentação só porque adotei um framework na camada de controle?
Eu não cheguei a estudar mais a fundo... Mas como outros frameworks como o VRaptor ou o Menta se comportam nessa situação? Posso fazer a passagem de informações sem problemas?
|
|
|
|
|
Uma proposta interessante é você usar o Emma junto com o Selenium. Quando iniciar o WSAD, voce faz a instrumentação nele e depois executa os scripts gerados pelo Selenium para realizar os testes do desenvolvedor de forma automática. Nesse caso voce nao precisa implementar mais classe nenhuma pois o Selenium permite que os testes sejam gravados enquanto o analista os realiza pela primeira vez. Não sei se te atende, mas é uma soluçao que comecamos a adotar na empresa.
|
|
|
|
|
Teste unitario é apenas a aplicação que usamos aqui... O Emma trabalha como uma ferramenta de instrumentação da JVM, então é só você alterar a sua chamada do servidor para que a JVM trabalhe dessa forma. Mas ainda não entendi a sua necessidade de testar a cobertura da aplicação...
|
|
|
|
|
Aqui na empresa a gente usa integrando o Emma com os testes unitários da aplicação. Assim, mesmo os testes do EJB entram na cobertura e conseguimos ter uma idéia do que estamos testando ou não. Mas para que voce quer usar o Emma?
|
|
|
|
|
Como a solução é a médio prazo, acho que vale o investimento em algum outro framework que não o struts até mesmo porque voce possui tempo para capacitação da equipe. Investir em Struts 1 ou 2 e depois ver, no meio do projeto, que suas demandas não são atendidas é complicado...
|
|
|
|
|
Já que o trabalho é sobre o Struts em si, é interessante procurar fracassos com a utilização da ferramenta e se a mesma foi motivadora desses fracassos. Acho que acrescentaria bastante no trabalho final até como uma visão crítica.
|
|
|
|
|
Independente do cargo da pessoa, a principal caracteristica deve ser a vontade de aprender. Veja com a pessoa qual a forma dela se atualizar, se acompanha algum blog, alguma revista ou forum. Até porque um profissional de TI que nao se atualiza só vai trazer aporrinhação para a sua empresa. Mas cuidado com os mercenários, aqueles caras que aprendem todas as novas tecnologias mas não param em nenhum emprego pois estão sempre a procura de um salário maior.
|
|
|
|
mcbarsotti wrote:
bobmoe wrote:2) vc não pode compactar um arquivo js pq o browser não vai descompactar isso.
Errado, vc pode compactar usando gzip ou então vc pode tirar coisas inuteis para um .js em produção, por exemplo espaços em branco, comentarios e etc...
para fazer a compactação de tirar coisas inuteis do seu .js entra nesse site http://shrinksafe.dojotoolkit.org/, coloca o seu arquivo .js a ser compactado e salva oque ele retornar, pronto, já vai estar com o tamanho beeeemmmm menor!
boa sorte!
Cara, é justamente isso que eu quero... Mas nao quero deixar na maos do desenvolvedor fazer esse trabalho! Minha ideia eh integrar essa tarefa com o empacotamento do projeto WAR.
|
|
|
|
peczenyj wrote:Começando pelo seguinte: como vc compacta o javascript manualmente?
Manualmente na maquina eu nao conhecia nenhuma forma... A solucao era entrar em algum site que fizesse o serviço, mas normalmente são em PHP q nao encontrei fonte que fosse possivel adaptar para java. Até ficaria feliz em compartilhar esse trabalho mas nao tenho material suficiente.
peczenyj wrote:O ANT tem uma tag <exec> que pode servir para isso 
Nao posso amarrar a compactacao ao sistema operacional com um executavel porque quem gera o sistema é o cliente. Nós enviamos os fontes a ele e o resto do trabalho não é nossa responsabilidade. Agradeço a indicação do bobmoe mas nao posso usar...
|
|
|
|
criptografar, compactar, baixar o tamanho do arquivo, obfuscar... nao sei como voces chamam... acontece que tenho varios arquivos javascript q somam uns 200kb de download na pagina e queria diminuir essa carga para o usuário do site.
se eu deixar a tarefa de editar o fonte, compactar e publicar na mao do desenvolvedor, podem acontecer erros e até mesmo uma complicaçao do processo de desenvolvimento se o cara esquecer de compactar antes de publicar a versao do sistema.
|
|
|
|