No início do ano meu notebook estragou. Demorei uns 4meses para mandar arrumar. Mas consegui! :D:D:D
Então, resolvi mudar e largar de mão o windows vista.
21 de set. de 2009
10 de jun. de 2009
Faça a mudança acontecer. Não mude.
Mudança é sempre uma palavra complicada. Nós, profissionais de TI, sempre adoramos mas organizações nem tanto.
Depios de uma certa experiência, que relaciono com as "vivências" não com o tempo, aumentamos nosso poder de obsevação e nossa análise crítica. Apartir daí, somos capazes agregar valor ao nosso trabalho de forma mais intensa.
Quando trocamos de empresa essa vontade de trazer nossas experiências a tona é dispertada. Normalmente nos deparamos com diversos pontos que podemos melhor, agregar, modificar, etc, no novo contexto. Isso acontece devido às experiências carregadas na mocihla.
Neste momento vejo o primeiro equívoco.
Trazer as crenças da empresa para nós, não trazer a nossas crenças para a Empresa
Não é bom chegar em um lugar e querar mudar diversas coisas. Apontar diversos falahs. Não e bom porque mal entendemos o ambiente, o contexto, como as coisas funcionam.
Viver a rotina da empresa para depios apontar pontos de melhoria é um bom começo. Dessa forma, é possível projetar o impacto das mudanças. Ao conseguir projetar o impacto das mudanças pode-se argumentar para que elas sejam efetuadas.
Devemos fazer parte do negócio, enteder os fluxos de trabalho, conhecer as causas e efeitos, o porquê as coisas são como são.
A partir daí...
Faça a mudança a contecer, não mude
Normalmente temos idéias que, com certeza, vão mudar o mundo. A empresa vai lucrar muito mais, eu vou ganhar uma promoção, tudo vai melhorar. Mas...
Apesar da mudança ser uma constante, ela tem que ser controlada pelas organizações. Afinal, qualquer mudança tem custo. Se cada funcionário que entra resolver mudar tudo, a empresa ta ferrada!
Por isso, para fazer com que suas idéias possam ser atendidas não proponha simplesmente mudanças. Provoque a inquietude nas pessoas. Provoque a mudança nas pessoas. Seja um agente de mudanças. Levante faíscas para que todos envolta possam acender o fogo. Isso sim que vai fazer todoas ganharem.
Ser um agente de mudanças
Acredite nas pessoas. Seja humilde. Ouça o que os outros têm a dizer.Valorize o conhecimento de quem está a sua volta.
Se você mostrar estas características ANTES de sair mudando tudo, será ouvido.
Pense fora da caixa
Um dos passos para ter idéias novas é questionar.
Não seja "palpiteiro". Questionar sem argumento é palpite. Isso não agrega nada.
Questione, entenda, reflita, então provoque a inquietude nas pessoas. Para que todos façam os mesmos questionamentos.
Resumindo, tenho três idéias principais sobre mudanças:
Não sei porque resolvi escrever isso...
Mas... são 3h da madruga e veio a inspiração... amanhã eu leio como ficou... heheheh
Abraço!
Depios de uma certa experiência, que relaciono com as "vivências" não com o tempo, aumentamos nosso poder de obsevação e nossa análise crítica. Apartir daí, somos capazes agregar valor ao nosso trabalho de forma mais intensa.
Quando trocamos de empresa essa vontade de trazer nossas experiências a tona é dispertada. Normalmente nos deparamos com diversos pontos que podemos melhor, agregar, modificar, etc, no novo contexto. Isso acontece devido às experiências carregadas na mocihla.
Neste momento vejo o primeiro equívoco.
Trazer as crenças da empresa para nós, não trazer a nossas crenças para a Empresa
Não é bom chegar em um lugar e querar mudar diversas coisas. Apontar diversos falahs. Não e bom porque mal entendemos o ambiente, o contexto, como as coisas funcionam.
Viver a rotina da empresa para depios apontar pontos de melhoria é um bom começo. Dessa forma, é possível projetar o impacto das mudanças. Ao conseguir projetar o impacto das mudanças pode-se argumentar para que elas sejam efetuadas.
Devemos fazer parte do negócio, enteder os fluxos de trabalho, conhecer as causas e efeitos, o porquê as coisas são como são.
A partir daí...
Faça a mudança a contecer, não mude
Normalmente temos idéias que, com certeza, vão mudar o mundo. A empresa vai lucrar muito mais, eu vou ganhar uma promoção, tudo vai melhorar. Mas...
Apesar da mudança ser uma constante, ela tem que ser controlada pelas organizações. Afinal, qualquer mudança tem custo. Se cada funcionário que entra resolver mudar tudo, a empresa ta ferrada!
Por isso, para fazer com que suas idéias possam ser atendidas não proponha simplesmente mudanças. Provoque a inquietude nas pessoas. Provoque a mudança nas pessoas. Seja um agente de mudanças. Levante faíscas para que todos envolta possam acender o fogo. Isso sim que vai fazer todoas ganharem.
Ser um agente de mudanças
Acredite nas pessoas. Seja humilde. Ouça o que os outros têm a dizer.Valorize o conhecimento de quem está a sua volta.
Se você mostrar estas características ANTES de sair mudando tudo, será ouvido.
Pense fora da caixa
Um dos passos para ter idéias novas é questionar.
Não seja "palpiteiro". Questionar sem argumento é palpite. Isso não agrega nada.
Questione, entenda, reflita, então provoque a inquietude nas pessoas. Para que todos façam os mesmos questionamentos.
Resumindo, tenho três idéias principais sobre mudanças:
- Entenda o contexto. Não "jogue" tudo que você conhece propondo mudanças em tudo.
- Provoque mudanças em quem está a sua volta.
- Pense fora da caixa.Questione, entenda e refilta sobre o contexto.
Não sei porque resolvi escrever isso...
Mas... são 3h da madruga e veio a inspiração... amanhã eu leio como ficou... heheheh
Abraço!
22 de mai. de 2009
RMI e HIbernate... lições aprendidas
Estou participando de um projeto onde decidimos utilizar RMI para conversação de dois módulos do sistema. A decisão não vem ao caso agora, mas achei interessante gurdas alguns "causos"...
RMI e Hibernate, onde tudo começou
Como falei anteriormente, decidimos utilizar RMI para integrar dois módulos do sistema. Um módulo responsável pela parte de negócio( persistência também) e outro por uma parte específica bem baixo nível (baixo nível = bytes.. 01010101...etc...).
Então, o gênio projetista teve a seguinte idéia: "Vamos utilizar as classes persistentes para trafegar via RMI".
Resultado: LazyInitializationException -LIE.
Em um determinado método de uma classe acessada via RMI o retorno era um objeto que foi buscado do Hibernate. Este objeto tinha outros objetos, que tinham outros objetos, que tinham outros objetos... blá blá blá...
Soluções:
1º) Colocar "transient"(do java não do JPA) nos atributos que não deveriam trafegar via RMI. Puramor de Deus, Nãããão!!!
Imagina ficar colocando transiente em tudo que é atributo espalhado pelo código inteiro. Loucura!!!
2º) Modificar o design
Interessante... muito interessante...
O Design... (não é de moda porr!!)
Tentei fazer algo que representasse o problema. Então abaixo estão algumas classes de domínio, mapeadas no hibernate.
OBS: Para quem não sabe, em RMI devem existir interfaces comuns nos dois lados da comunicação. Então a interface PessoaData é conhecida pelos dois módulos.Agora, viram o que o projetista gênio fez ?!?!?!
A classe Pessoa implementa a interface PessoaData. Na imagem acima temos somente um exemplo, mas no contexto real são umas 20 classes que irão trafegar via RMI. Todas essas classes são entidades persistentes.
Observe que a interface PessoaData retorna byte[]. Isso mesmo.. o "carinha" que utiliza estas classes vai precisar dos dados convertidos em bytes. Guarde esta informação.
Confesso que o projetista gênio(agora já deve-se saber quem é o projetista... :D ) percebeu a burrada somente quando ocorreu o erro com hibernate.
O que vocês conseguem enchergar ai?
Bom, vou dizer o que eu consegui enxergar:
- Uma classe persistente implementa uma interface utilizada para comunicação entre sistemas. Acomplamento! Entidade persistente conhece uma interface onde o objetivo é comunicação de dados entre sistemas... "nada a vê"
- Pelo motivo acima, a entidade persistente é responsável por converter String, Integer, Date em bytes. Coesão! Tava tudo misturado, conversões com bytes em uma classe onde o objeto é enviar e obter informações do banco de dados.
Solução tomada
Utilizamos os famosos Transfer Objects. Segue o exemplo:
Matamos o problema de coesão, onde a classe PessoaTo é responsável por trabalhar os dados para comunicação.
Matamos o problema de acomplamento onde a classe Pessoa não sabe que a classe PessoaTo existe.
Matamos o LazyInitializationException. A classe TO contém apenas o que será necessário para transferência.
Lições aprendidas
- Colocar tudo em uma classe é diferente de economizar tempo
- Preguisoço trabalha em dobro... :D
- Projetos iterativos minimizam os erros. Descobrimos o problema no início e retrabalho foi de aproximadamente 5hs.
- Enviar objetos utilizados para persistência via RMI-> ... LazyInitializationException
- Spring RMI exporter facilita muito!
- Cuidar as dependências das classes
Era isso..
Abraço!
17 de abr. de 2009
Quer aprender Adobe Flex?
Acabei de chegar de uma palestra de demonstração do Adobe Flex na T@rgetTrust.
Eu não sei nada sobre Adobe Flex, mas achei muito interessante o que vi hoje.
Segue algumas referências para quem estiver afim de iniciar os estudos:
Referências:
Listas Brasileiras
Bibliotecas (outros componentes):
Frameworks para integração com Java:
- BlazeDS – Free
- OBS: O spring tem um projeto para integração com BlazeDS
- LCDS - Pago
Tutoriais:
- http://www.adobe.com/devnet/
flex/flex_java.html - http://www.javaworld.com/
javaworld/jw-01-2009/jw-01- javaee-flex-1.html?page=1 - http://www.adobe.com/devnet/
livecycle/articles/blazeds_ gettingstarted.html - http://blog.digows.com/integrando-adobe-flex-blazeds-springframework-hibernate-uma-soluo-opensource-para-sistemas-web-parte-1/ (Muito Bom!!!)
IDE
- Flex Buildes ($249)
- Flex Builder plugin para Eclipse ($249)
- Flex SDK (Gratuito)
- Flex versão para estudante
Esse post é mais para eu anotar em algum lugar os links do que qualquer outra coisa..
Abraço
Assinar:
Postagens (Atom)