| Autor |
Mensagem |
|
|
Marky.Vasconcelos wrote:Um #GUJ é muit simples, fora a divulgação, tem que ser uma camiseta legal de se usar, e ainda assim mostrar aos outros que não é nerd (assim como solicitaram :p)
Usar camiseta do GUJ = mostrar que é nerd
|
 |
|
|
Melhor argumento para se pedir um aumento: "Recebi uma proposta X de uma outra empresa, vocês cobrem?"
Não adianta vir com conversinha de certificação, de ser funcionário produtivo, etc., geralmente a única forma de ganhar um aumento substancial é conseguir outra proposta e pedir para a empresa cobrir a proposta.
E isso não é ser mercenário nem nada! Não tem nada de errado em buscar outras oportunidades no mercado se você não esta satisfeito com o seu salário.
|
 |
|
|
Pode te ajudar:
http://www.tectura.com.br/topics/abordagens_de_multitenant
http://msdn.microsoft.com/en-us/library/aa479086.aspx
|
 |
|
|
|
Se você desistiu de ser desenvolvedor de verdade vale a pena.
|
 |
|
|
Bem que eles podiam ter feito isso antes de criar o Struts
|
 |
|
|
esmiralha wrote:É impressão ou o velho hippie confundiu JSF com JSP? "Fizemos JSF como um clone de ASF"...?? Ele queria dizer JSP e ASP! Drugs are bad, Jimmy!
Não, ele quis dizer que JSF é um clone de ASP.net
|
 |
|
|
lina wrote:
2- Você sai de casa a noite?... tipo, balada?
3- Quais as baladas que você freqüenta?
Isso é uma entrevista ou uma cantada?
|
 |
|
|
Nenhum se o dinheiro for usado para o desenvolvimento nacional. Eu não acho legal ser usado para financiar o desenvolvimento de um framework Java redundante de qualidade altamente questionável (basta fazer uma busca no GUJ e na lista do SouJava para ver que a equipe técnica da PowerLogic até tentou argumentar, mas ficou bem claro os defeitos da ferramenta).
E agora ele é integrante da relação de Softwares Públicos do Governo Federal. Espero que com isso não comecem a aparecer milhares de licitações exigindo experiência em Jaguar... adivinha qual empresa possui profissionais com experiencia em Jaguar e jCompany?
|
 |
|
|
Uau... parece que pegaram dinheiro do BNDES de novo.
http://www.slideshare.net/Powerlogic/apresentao-executiva-5597571
|
 |
|
|
|
Pegaram dinheiro do BNDES pra fazer esse Jaguar também?
|
 |
|
|
JBoss continua sendo meu AppServer preferido
|
 |
|
|
asaudate wrote:
(aliás, já fui obrigado a engolir, de uma pessoa que teve péssima experiência com a arquitetura, que SOA nada mais é do que um engodo feito para vender produtos, quando não podia estar mais longe da intenção)
Fui eu que te falou usso né?
asaudate wrote:
Alguns vendors, aqui no Brasil, fazem questão de promover SOA para vender seus produtos. Eu mesmo tive uma péssima experiência com uma consultoria parceira da Oracle (obviamente, não vou revelar o nome dessa consultoria aqui), onde o próprio vendedor se encarregou de "empurrar" os produtos pela goela do cliente. Não tínhamos necessidade de NENHUM desses produtos, aliás, o uso dos mesmos, por ser empurrado, acabou prejudicando a arquitetura, atrasando o projeto e me forçando a pedir demissão da consultoria, pois não aceitava mais a situação como um todo.
Não sei se esse problema acontece apenas no Brasil.
kenobi wrote:
O que é SOA ? Simplesmente é uma maneira de você escrever sua API para ser utilizada por plataformas heterogêneas ou sua API usar "recursos", de outras plataformas.
Tão simples quanto isso e o maior Case de SOA hoje é : Google Maps. Quantas aplicações fazem uso dessa API, de diversas plataformas ?
Projetar sua API para outras plataformas consumirem, exige um pouco de planejamento e algumas técnicas.
Kenobi, o meu problema com SOA nunca foi o conceito em si e sim como "ferramentas SOA corporativas" e como geralmente é vendido. Google Maps, Facebook, Twitter, etc, são alguns dos exemplos de APIs a serem utilizadas por plataformas heterogêneas ou APIs que usam recursos de outras plataformas. Quantos desses caras usam ESB e BPEL para fazer integração? Tenho quase certeza que nenhum.
Acho que você não precisa de nenhum produto SOA para implementar "APIs para ser utilizadas por plataformas heterogêneas". Acho também que o mais difícil é definir como vai funcionar a troca de mensagens entre os sistemas (principalmente como vai ser as interfaces), a granularidade dos serviços e qual sistema deve possuir quais serviços. Se você conseguir fazer bem essas três coisas, você terá um ambiente em que as aplicações tem APIs bem definidas, que conversam entre si, resultando em reaproveitamento de funcionalidades entre os sistemas. E esse é um trabalho que nenhum produto pode fazer por você.
IMHO, os produtos podem teoricamente ajudar você a implementar a forma de comunicação entre os sistemas. Mas essa não é a parte mais difícil (nem mais crítica para o sucesso).
|
 |
|
|
(X) Todas as anteriores
De uma forma ou de outra, em maior ou em menor grau, tudo o que voce falou acaba acontecendo quase sempre em consultorias.
|
 |
|
|
saoj wrote:
Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.
Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box.
Quem conhece bem Hibernate e depois le o PoEAA percebe que ele implementa vários patterns complexos, alguns inclusive que você dificilmente se daria o trabalho de implementar na mão (principalmente o Unit of Work). Cache da forma como ele faz nem se fala. Lazy loading, carregar automaticamente relacionamentos, etc, são outras coisas bem legais dele. Sem falar nos projetos Hibernate Search, Hibernate Validator, etc.
Tudo isso tem um custo, ele tem uma forma de se trabalhar e você precisa configurar ele. Mas hoje em dia a configuração dele é ridiculamente simples. O Hibernate em si é um projeto grande, tem uma complexidade, devido ao conjunto de conceitos e funcionalidades que ele implementa. Por isso é preciso ler a documentação e consultar a documentação constantemente.
Eu vejo muito desenvolvedor que não tem muita paciência e vai reinventando a roda, codificando tudo do zero. Eu acho que quem faz isso não é por que já sabe SQL e JDBC, e sim por que não tem conhecimento das ferramentas disponíveis. Por preguiça, má vontade, gosto pessoal e outros motivos, prefere não gastar tempo aprendendo bem uma ferramenta bem estabelecida que já faz muito bem o que ele precisa.
E não da pra comparar Hibernate com VB e Maker. Abstrair e implementar conceitos encapsulando suas complexidades é uma coisa, ferramenta visual para gerar código é outra.
Não vejo problema nenhum em não gostar de ferramentas/conceitos bem estabelecidos. Mas quando falamos de tecnologia e desenvolvimento, temos que que ter um olhar mais técnico e menos emocional. Se não gostamos de uma ferramenta que todo mundo gosta, nós podemos estar certos, mas seria bom entendermos o que realmente não gostamos na ferramenta e ter a mente aberta, pode ser que nós simplesmente não conhecemos a ferramenta o suficiente ou nunca trabalhamos num ambiente em que ela é usada de forma correta.
|
 |
|
|
saoj wrote:
Ninguém vai fazer isso: usar JDBC puro, com o seu próprio pool de conexões é perda de tempo. Pra isso existe abstração.
Uau, que fantastico esse código.
Bem melhor que o equivalente em Hibernate:
Parabéns Sérgio! Você elevou o desenvolvimento Java a um outro patamar
|
 |
|
|
|
|