| Autor |
Mensagem |
|
|
Amigo, eu procurei nos e-mails aqui e não achei o endereço, mas se você procurar por Stefanini no twitter deve encontrar com facilidade.
Lembre-se apenas de poder comprovar experiência nas tecnologias citadas (no caso das features do Java EE 6, não precisa ser experiência profissional, mas durante a entrevista será provavelmente questionado sobre tecnologias da stack). E acima de tudo, inglês fluente. Fluente mesmo - neste aspecto somos rigorosos, e por incrível que pareça, é um dos aspectos que mais tem reprovado candidatos. Experiência profissional no exterior pesa positivamente nesse quesito.
Abraço! (e desculpe a chatice =)
|
 |
|
|
Olá pessoal,
Desculpem-me desde já se este não é o forum apropriado para isto, mas a empresa onde trabalho está precisando de profissionais Java para um projeto internacional importante. Precisam de experiência em Java EE 5/6, inglês fluente, JSF (1.2 e 2.0), JPA. Experiência com Seam/CDI é um plus muito interessante.
Está difícil de encontrar estes profissionais em Curitiba, então me pediram uma força para "recrutar" na comunidade. Se algum de vocês se interessar, podem enviar currículo para o meu e-mail (javabeats@yahoo.ca), ou podem entrar em contato direto com a Stefanini (Curitiba). Acredito que a vaga esteja sendo anunciada no twitter e nos portais de costume da Stefanini, e lá podem haver mais detalhes que a minha parca descrição.
Sobre a forma de contratação, sei que estão preferindo CLT, mas não acredito que estejam recusando ofertas PJ. Prefiro não entrar no mérito salarial (para evitar desviar o assunto do tópico), e posso dizer que o cliente é muito bom, que mantém seus sistemas em constante atualização (nota-se pelos requisitos de plataforma), e mantém uma parceria interessante com os terceiros que emprega. Sei que eu estou bem satisfeito em trabalhar aqui 
Abraço!
|
|
|
|
Olá pessoal,
Alguém sabe me dizer onde está a documentação do Mojarra Scales?
Eu incluí a biblioteca em WEB-INF/lib, consigo ver e usar as tags, mas assim que acesso a página, o navegador faz download do código dela, e não renderiza nada. Crente de que eu estou fazendo algo errado ou que o meu setup está incompleto, fui buscar ajuda no site do projeto no Kenai - mas, cadê a documentação?
A propósito, a única razão para eu procurar o Mojarra Scales no momento é a falta de suporte JSF 2 no RichFaces... estão em alpha ainda, se sem estimativa de datas (pelo menos é o que se lê na página oficial do projeto na JBoss). Fiquei surpreso, afinal, a spec está aí há tempos (apesar de ser liberada oficialmente apenas recentemente). Imaginava que já trabalhavam em branches com suporte JSF 2 a mais tempo... 
|
|
|
|
O mercado está mais comedido ao contratar, e realmente, vagas com salários mais altos em boas empresas são mais raras em Curitiba do que já foram uma vez. Entretanto, a faixa que você citou é risível - mesmo para o perfil Jr de diversas empresas daqui. Talvez você tenha se equivocado, ou a pessoa que lhe informou os valores lhe informou errado, mas as faixas em Curitiba são, por experiência, de 1.7 a 4 mil (CLT), e 3 a 6 mil (PJ). Dificilmente está abaixo ou acima desses valores.
A não ser, é claro, que você tenha recebido proposta de alguma terceirizada, que atende a um certo banco, que usa tecnologias um tanto ultrapassadas e costuma absorver e dispensar profissionais aos montes, alta rotatividade, conservando só o pessoal do FORMOL... digo, COBOL.
|
|
|
|
Uma boa conclusão que podemos tirar dessa discussão é a necessidade de refletir bastante antes de começar a codificar, sobre quais as reais necessidades do seu projeto. E não adotar tecnologias e padrões baseados em o quão legal isso vai se encaixar no seu currículo, ou o quão complexo o sistema PODERÁ ficar no futuro (pseudo-requisitos), etc.
O que acontecia com frequência até pouco tempo atrás é o uso exagerado de "buzzwords" no ciclo de desenvolvimento, em caráter experimental, afim de se familiarizar com uma tecnologia/pattern para conhecimento próprio/da empresa, sem avaliar a real necessidade da aplicação da mesma a longo prazo no projeto. Tenho encontrado esse comportamento cada vez menos em equipes de novos projetos, o que me leva a crer que a comunidade está se conscientizando nesse sentido, e arquitetos malucos estão perdendo espaço para projetos funcionais e ágeis 
|
|
|
|
O real benefício dos DAOs pode ser melhor visualizado quando você tem mais de uma fonte de dados (além do tradicional banco de dados relacional). Imagine recuperando informações sobre seu modelo de mais de uma fonte - você vai perceber os benefícios do DAO e do DomainStore.
Ser capaz de abstrair o acesso aos dados utilizando componentes comuns e reutilizáveis é uma grande vantagem. Sem contar que, aliado a um modelo de entidades bastante coeso e bem modelado, você facilita muito o desenvolvimento das camadas superiores. Eu tenho sempre DAOs "genéricos" disponíveis no código, e eles facilitam muito o desenvolvimento. O que eu NÃO faço é construir DAOs para diferentes entidades sem haver uma necessidade justificável para isso.
Acho que o grande problema com DAOs é que hoje eles estão supervalorizados; serviços com acessos à contextos de persistência costumam substituir código de DAOs com facilidade e presteza.
|
|
|
|
|
Estou especialmente interessado na integração nativa com serviços. E a promessa de velocidade no consumo desses serviços. Essa noção de uma máquina "sempre online", sincronização de conteúdo local com conteúdo remoto. É isso que eu quero ver funcionando legal, porque é nisso que eu quero apostar na carreira
|
|
|
|
Acho que em meados do ano que vem acontecerá apenas a abertura do código fonte. Levaria mais um tempinho até que alguns netbooks apareçam no mercado com o Chrome.
Uma das preocupações é o overlap com o Android, mas a Google deve ser capaz de integrá-los adequadamente.
A filosofia adotada para os requisitos é muito boa, espero que, ao menos, faça a "concorrência" rever alguns velhos conceitos... :cough: hardwarenolinux :cough:
|
|
|
|
Bom saber que já portaram! Já tava na hora
Sou usuário Netbeans, tanto em casa quanto no trabalho. E outra coisa que não gosto é não darem a opção de baixar a IDE com suporte completo à Java EE, mas SEM os servidores "embutidos" no download. Nada contra o empacotamento deles, mas deveria haver a escolha de não baixá-los.
Uso o glassfish todo customizado, e não me interessa o bundle que vem com o Netbeans. Sem contar que eu poderia usar qualquer outro servidor que não o Glassfish. "Forçar" seu download é exagero. E sim, eu sei que é possível baixar a versão Java SE e instalar os plugins separadamente... mas, por favor, não quero fazer isso.
|
|
|
|
andreban wrote: :shock:
Por essa eu também não esperava. Não só ainda não conseguiram portar a SDK para Linux (corrijam-me se eu estiver desatualizado), e agora a versão mais recente da IDE da Sun não traz suporte à tecnologia que querem disseminar no mercado. WTF?
|
|
|
|
marcosalex wrote:Também achei muito lento. Qual vocês acham que tem melhor performance, IceFaces, RichFaces, MyFaces ou outro?
Hoje em dia estamos migrando pra JSF puro mas, como já disseram, não é tão produtivo.
Eu discordo. Conhecendo o RichFaces, é possível desenvolver interfaces com bom desempenho.
Mas, se você tem necessidades específicas de desempenho, dê uma olhada no RichFaces com o skin 'plain', no Gravel, que também é da JBoss.
|
|
|
|
É possível otimizar muito o que é renderizado pelo RichFaces. Além disso, geralmente, o problema está com o uso que se faz dos componentes, e não nos componentes em si.
Se você tem uma página com duas dúzias de componentes, mal distribuídos, sem o uso adequado de ajax regions, ajax requests, parameters, etc... Não vai ter um desempenho legal mesmo.
Sugiro que leiam o developer guide... muitas dicas importantes que fornecem informações para superar a maioria dos problemas com JSF e ajax.
|
|
|
|
Os requisitos devem orientar a escolha de um stack de tecnologias. Não faz sentido escolher uma bazuca para martelar um prego, ou um martelo para ir à guerra.
Você precisa analisar a aplicação sobre vários aspectos: não só o que interfere no desenvolvimento da primeira versão, mas também a manutenção contínua e a flexibilidade para inclusão de novas funcionalidades.
Esse é o meu conselho: antes de pensar em qualquer tecnologia, pense no projeto. Qual a previsão de crescimento? Escalabilidade necessária? Quais os papéis que você tem na sua equipe? etc.. etc.. etc..
[edit: gramática...]
|
|
|
|
Cara, tá estranho... mapeamento das entidades?
Meu palpite é que sua entidade tem algum relacionamento Lazy, que ao ser serializado para o cliente, usa o contexto de persistência, e como ele já está fechado (afinal, seu bean é stateless), o erro é gerado.
Para testar, caso sua entidade tenha relacionamento lazy, traga-os já na consulta, ou faça a inicialização - via get() - antes de adicionar o resultado à lista. Isto deve confirmar se o meu palpite está correto ou não.
|
|
|
|
|
Parece que o problema está no seu cliente. A referência do bean, como você obtém?
|
|
|
|
|
|