Quando instalamos o pacote, normalmente ele é encontrado do diretório /usr/local/mysql/support-files. Aqui é possível encontrar uma série de scripts que podem facilitar muito a vida de que utiliza o mysql. Inclusive o arquivo mysql.server que contem as diretivas para iniciar, reiniciar e parar. Normalmente tentaria-mos encontrar esses arquivos no diretório /etc/init.d/.

Esse erro acontece que nas libs do JBoss já existe a mesma biblioteca. Quando é feito o deploy, ou executado standalone, esse erro acontece. Não adianta remover a lib do classpath da aplicação. Pode ater dar certo mas, se sua aplicação depende dela, talvez os testes automatizados não sejam executados corretamente.

Para solucionar esse problema em uma aplicação web simples, é necessário informar ao JBoss que essa lib é necessária para o projeto. Para isso, é só incluir a linha abaixo no arquivo MANIFEST.MF: Dependencies: org.dom4j. No momento do deploy o JBoss ler esse arquivo para tentar encontrar diretivas utilizadas para gerenciar o ClassLoader da aplicação e gerenciar a dependência de módulos.

Espero ter ajudado.

Nesse caso, a melhor ferramenta é a nossa cachola. Encontrei nesse blog um número repleto de dicas para solucionar os problemas de Anti-Pattern que utilizamos no dia-dia. Desde dicas de performance até soluções para determinados problemas. Vale a pena dar uma olhada. Odi’s Blog.

Terminei de ler o livro essa semana e queria escrever alguma coisa sobre o que eu li. Também expressar  minha opinião sobre a figura de Steve Jobs.

Acredito que não exista nada melhor do que olhar pra trás e ver seus feitos, criações, ideias que foram concretizadas. Também, acredito que deve ser a mesma coisa quando olhamos em volta, no próprio presente, e vemos os frutos de nossos esforços que foram feitos no passado. Uma vez, ao ler a biografia de Albert Einstein, li uma frase fabulosa; “Quando olhamos para uma fórmula, nos deparamos com números, constantes e símbolos para que nos trás um determinado resultado. Mas, muitas coisas se escondem através dessas formulas, noites em claro, um certo distanciamento dos seus familiares, críticas e esforço pra prova-las para pessoas incrédulas, lágrimas e um pouco de cabelos brancos.  Se conseguíssemos olhar profundamente em cada criação humana poderíamos ver a dor e o sacrifício, que, são sempre maiores que o mérito atribuído pela criação”.

A biografia de Steve Jobs contada por Walter Isaacson teve um grande sucesso em alcançar exatamente o ponto do sacrifício, foco e a dor que envolvem uma criação. Em cada ponto da obra existe conflitos e principalmente a explosão do temperamento de Jobs em diversas situações e momentos, no trabalho, família e amigos. Mesmo assim, em alguns momentos, são feitos que contém méritos, pois, ele conseguia tirar o máximo dos seus funcionários. Coisas que eram declaradas como impossíveis de serem realizadas, eram feitas e no tempo estabelecido por ele. Realmente, devia ser uma coisa estressante trabalhar a base do grito e com um líder que tinha uma constantes explosões de personalidade.

Muitos podem afirmar que Jobs era um tremendo de um mal caráter salafrário sem coração. Sim, depois que eu li sua biografia é essa a conclusão que tirei. Até mesmo de leitura das primeiras cinquenta páginas é possível tirar essa conclusão. Mas a questão é: porque isso tudo? Porque ele teve tanto sucesso? Bom. Eu nunca saberei responder porque eu não trabalhei com ele, mas a minha suposição é que: ele utilizava a abordagem do chicote pra tirar todo o potencial de uma pessoa. Se ele visse potencial naquele indivíduo ele iria descasca-lo até conseguir o que queria. Isso não é uma boa abordagem, mas funcionava com ele.

Enquanto estamos tentando diminuir o máximo possível o tempo das reuniões, as suas duravam no mínimo três horas. O fato de ser meticuloso e da necessidade de ter o controle da situação por completo levava ao limite  as pessoas de sua confiança. Uma coisa é certa, o mesmo olhar que via no Senna quando ele conversava com os engenheiros e em suas reuniões. Isso é possível ver em Jobs nos poucos momentos que se deixou filmar trabalhando. A seriedade e a atenção, quase que hipnótica, era perceptível em suas feições quando travam de assuntos do seu interesse. Para Senna, isso era imprescindível, pois tinha um carro inferior aos demais, portanto, era necessário conhecer seus limites ao máximo para poder lava-lo a vitória. Para Jobs, sua ânsia  de criar produtos e, ao mesmo tempo,  a vontade de derrubar IBM tornou-se seu principal elemento de motivação.

A Paixão. Isascson, em muitos pontos do texto, cita a paixão como ponto fundamental para a motivação de Jobs. Acredito que até mesmo para o seu time. Ele conseguia ver isso nos demais. Olhava nos olhos dos seus de seus funcionários tentando encontrar a paixão por produzir coisas novas, de tirar o que tinha em sua cabeça e pode materializar em alguma coisa inovadora. Ele conseguia fazer isso como ninguém.

Uma das coisas que Jobs sempre falava era de ter amor e orgulho do que se fabricava. Isso não está na biografia, mas no livro “A Cabeça de Steve Jobs”; quando ele voltou para a Apple, se deparou com inúmeros funcionários falando mal dos produtos que foram criados. Isso deixou Jobs com uma raiva enorme e sempre que escutada isso de algum funcionário ele “estevava” (termo criado pelos funcionários da Apple quando das humilhações que eram feitas em público aos seus funcionários) o sujeito lá mesmo. Só que, em várias reuniões ele mesmo afirmava que os produtos que a Apple fez, até o momento que ele estava fora, era tremenda porcaria. Mas o que ele queria despertar nas pessoas era o amor. A paixão e o orgulho ao ver uma coisa concluída, em fazer parte de um time de estrelas. Acredito que era isso que ele sempre quis enfatizar.

Normalmente, quando fazemos alguma coisa de valor, seja a mínima possível, gostamos sempre de receber um parabéns, nem que seja um simples tapinha nas costas seguido de um “bom trabalho”. Nesse ponto, não tenho do que critica-lo. Quando Jobs brilhava, seu time pegava carona no seu no seu brilho. Quando um trabalho era bem feito, ele sabia reconhecer o esforço. No texto do Isaacson, ele afirma que Jobs mandou gravar o nome de todos das sua equipe a parte interna do Macintosh, afirmando que aquela era a assinatura do artista.

Em diversos pontos, isso segue com controvérsias. Existem algumas histórias que põe abaixo toda essa afirmação acima. Entre as mais famosas, inclusive contado pelo próprio Woz, foi a redução de uma placa de circuito que Woz fez para Jobs. Jobs levou para a Atari, a empresa que trabalhava na época, e ganhou os méritos e o prêmio em dinheiro devido a esse feito e não contou e também não repassou nada para Woz. Outros histórias, está nas idéias sobre o design dos produtos. Essas reuniões eram constantes que tinha com Ive, porém, em muitas situações, as idéias que Ive tinha Jobs afirmava que eram dele. Não repassava o crédito sobre tais fatores. Muitos vão dizer que era assim que ele era, mas, muita coisa poderia ser feita de forma correta por ele. São pontos que não são importantes, acredito que os devidos méritos poderiam ser dados, já que, os acrescentaria muito para a sua equipe.

Depois do seu diagnóstico do câncer, até o seu tratamento, ficou perceptível a sua doença, principalmente pela rápida perda de peso. Porém, uma coisa de se admirar em pessoas complexas, principalmente em Jobs, é o fato da doença não o deixar-se abalar. Era perceptível que havia alguma coisa errada. Porém, poucas vezes se deixou abalar. Em suas apresentação, apesar da perceptível perda de peso, ele nunca expôs seus problemas de saúde a público. Até o ultimo momento que suas forças permitissem ele trabalhou. Se a empresa que ele criou é dessa forma, acredito que seja por essa força que foi reerguida está onde está. A cara da Apple e Pixar está um Jobs, carrancudo, mal criado, agressivo, astuto e falastrão, mas funcionou (It’s work).

Só mais uma coisa (Just one more thing). O fato da teimosia de prevalecer o controle e da convergência de hardware e software o levou a batalhas estremas. No início da Apple, ele levou isso até o seu limite. Após a fundação da NeXT, seu lema continuou. Quando voltou para a Apple, levou isso com sangue. Ao olhar para trás, quando o mundo corria para a liberdade do software para ambientes padronizados e sem controle, Jobs acreditava que o controle estava na convergência do hardware com o software. Vendeu poucos produtos e perdeu mercado, porém, seus produtos funcionavam e bem. Utilizar a convergência, ter o controle do início ao fim da experiência do usuário no uso do computador deu certo para Jobs. Nos últimos dias de sua vida até Bil Gates reconheceu seus feitos, porém, afirmou que isso tudo funcionava apenas com Jobs. Jobs discordou. Mas na minha opinião, Gates estava certo. Acho que poucos teriam a teimosia de manter esse pontos integrados com tanto vigor.

A informática é  uma ciência ainda jovem. Vemos seus protagonistas irem embora a cada ano que passa. Pessoas boas, como Dennis Ritchie, acredito eu como principal colaborador dessa ciência. Porém, temos que dar méritos também a esse louco. Criar produtos, cujo termo mais propício para descreve-los seria “humanizados”, que eram sucesso a cada lançamento não são feito por pessoas comuns. Não que eu diga que Jobs era uma pessoas diferente de nós, mas o que nos difere de pessoas como essas é que a paixão estava nas coisas que ele fazia. A vontade de mudar o mundo “Pensando Diferente” são pontos de méritos.

Recentemente, foi disponibilizada a relase 2 do versão 7 do AS, porem, a questão a ser tratada é a reformulação da estrutura do produto em comparação com as versões anteriores. O time de desenvolvimento praticamente refez todo o core do servidor, modificando desde a estrutura de carregamento das classes (classe loadin) até a forma de gerenciamento de dependência.

A interface de administração, apesar de não ser o forte deles, está mais limpa e direta. Através dele é possível ter total informação do que está instalado no servidor, datasources, módulos, dependências,  web services, etc. Lembro que no JBoss 5/6 havia uma interface que mostrava os webservices que estavam disponíveis na aplicação. Nessa versão, esse tipo de informação está disponível na própria interface de administração.

- VELOCIDADE AO SUBIR

Alguns pontos que se destacaram logo a primeira vista, entre esses, o mais perceptível é a velocidade que o JBoss é iniciado. Ao verificar os detalhes, me deparei na principal mudança ocorrida no núcleo do servidor. Ele está trabalhando inteiramente com OSGI, ou seja, no momento do boot o servidor sobe apenas os módulos necessários para tal. Esses elementos são lidos no arquivo de configuração domain.xml ou standalone.xml respectivamente.

Isso justifica o fator da velocidade de carregamento. Porém, quando for necessário incluir mais um módulo que sua aplicação necessite, um REST ou um Web Service tradicional por exemplo, será necessário editar o arquivo de configuração para que o módulo seja incluso.

- OS MÓDULOS

Essa informação está bem explícitas nos arquivos de configuração das instâncias, logo na primeira sessão está presente as extensões necessárias para o funcionamento da instância. Mais embaixo, quase no fim do documento, estão os módulos.

Os drivers de conexão JDBC são também tratados como módulos. Portanto, para utilizar um driver de conexão com um determinado banco de dados, será necessário incluí-lo como um módulo e importa-lo do projeto. Isso é feito criando uma hierarquia de diretórios, adicionar o jar do driver no diretório main, conforme o padrão, e criar um documento de descrição do módulo em questão, como o exemplo abaixo:

- INSTÂNCIA

A versão 7 suporta uma característica muito útil que para organizar as aplicações. O conceito de instância. Quem já trabalhou com o Oralce Application Server (hoje em dia Web Ligic) e com o WebSphere sentia bastante falta desse conceito no JBoss para efetuar configurações específicas de uma aplicação específica.

No primeiro momento, a opção por executar o jboss no modo standalone, mesmo em ambiente de produção, torna-se a melhor opção pelo fato da facilidade, ou melhor, ser um processo parecido como o que tinha nas versões anteriores.  Isso não quer dizer que não funcione, pelo contrário, funciona perfeitamente, tanto que temos aplicações rodando com essa configuração.

Acredito que, além da quantidade de recursos existentes nessa nova versão, uma outra característica que vem implícita com o servidor de aplicação, mesmo nas versões anteriores, é a simplicidade. A curva de aprendizado para configurar e disponibilizar um servidor de aplicação JBoss é bem baixa.

O JBoss apresentou um servidor de aplicação robusto e simples de utilizar. Acredito que com essa ultima versão deixou muito dos seus usuários otimistas, mesmo com as mudanças drásticas realizadas em sua estrutura.

]]> http://www.nelsonalone.com.br/2012/01/22/jboss-7-reformulacao-completa/feed/ 0 http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/ http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/#comments Mon, 26 Sep 2011 15:08:18 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=595

(More)…]]> A equipe de desenvolvimento do Twitter disponibilizou nessa segunda a ultima versão do storm. Pra quem não conhece, assim como eu a duas horas atrás, é uma API do Twitter, desenvolvida pela BackType, utilizada para solucionar problemas de processamento em tempo real com tolerância a falhas.

Referências abaixo:

Artigo na Infoq: Link

Repositório no GitHub: Link

Wiki: Link

Fuçando na internet, encontrei o blog do Fabien Sanglard’s que transcreve todos os passos para rodar os fontes do Quake II. Em seu post são descrito os passos necessários para compilar e executar os fontes, contem também os detalhes do módulos, arquitetura e etc. O post está mais completo que o meu sobre o Quake III. Vale a pena dar uma olhada.

]]> http://www.nelsonalone.com.br/2011/09/22/codigo-do-quake-ii/feed/ 0 http://www.nelsonalone.com.br/2011/09/22/hibernatejpa-%e2%80%93-utilizando-sql-sem-perder-o-vinculo-dos-objetos-relacionados/ http://www.nelsonalone.com.br/2011/09/22/hibernatejpa-%e2%80%93-utilizando-sql-sem-perder-o-vinculo-dos-objetos-relacionados/#comments Thu, 22 Sep 2011 16:51:37 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=581

(More)…]]> Não há dúvidas de que o hibernate é um excelente ORM, se não o melhor que há no mercado. Porém, muitas pessoas, satisfeitas com os procedimentos iniciais de aprendizado do framework, não se dão conta das demais funcionalidades disponíveis para o desenvolvedor. A lista é vasta, confesso que posso não conhecer a metade, mas alguns dias atrás, uma dessas funcionalidades me ajudou muito.

Um objeto persistente, para o hibernate, é uma entidade que contem relacionamentos com outras entidades que juntos formam uma relação. Em diversas situações, na maioria das vezes no mundo real, essa relação se torna complexa quando existe a necessidade de relação com outras entidades, somado com o numero enorme de dados relacionados. Existem várias formas de obter essas esses dados relacionados, uns que permitem obter todo o conjunto de dados relacionados ao carregar o objeto (eager), outro no momento que a relação é obtida (lazy). Outras alternativas podem ser utilizadas em conjunto, como, as consultas nomeadas atreladas ao carregamento do objeto. Porém, apenas obter a lista de desses informações não é suficiente para a aplicação, fazendo com que o desenvolvedor utiliza consultas mais elaboradas com HQL ou criteria.

A forma como o framework monta as consultas é na maioria das vezes genérica e pouco intuitiva, fazendo com que o desenvolvedor opte por utilizar o SQL nativo, ou portar a consulta para uma Stored Procedure para construir uma consulta mais elaborada. É uma estratégia plausível quando a aplicação necessita de desempenho mas, isso tiraria a principal vantagem do framework; o acesso as relações que são representadas pelo relacionamento entre os objetos. Existe uma maneira muito simples de executar uma consulta SQL mantendo o relacionamento entre os objetos.

Para o framework, os objetos persistentes são de extrema importância. Quando o framework é executado pela primeira vez, ele adiciona uma série de funcionalidade nos objetos persistentes que permite realizar as operações em suas relações. A maneira com que o framework realiza essa tarefa é pela Instrumentação de código. A instrumentação nada mais de uma técnica de incluir alterações do código do programa mesmo após a sua compilação. O conceito pode ser semelhante com Reflexão e AOP, mas existem particularidades que tornam os conceitos bem distintos. Por ser um assunto muito pesquisado e com referencias em abundância, é um assunto para ser tratado outra hora. No hibernate, isso é feito através da lib ASM, que é um extenso conjunto de utilidade que permitem a plicar esse conceito nas classes escritas em linhagem Java.

Bom, para que o framework compreenda que o resultado de uma consulta SQL possa ser vinculado a um objeto é necessário que o retorno corresponda aos atributos do objeto, sendo que o objeto possa ser reconhcido pelo motor de consulta. Ex:


List<ClasseQualquer> planos = new ArrayList<ClasseQualquer>();
String queryStr = queryUtils.findValue(nome_da_query); //obtem a string de consulta
Query query = entityManager.createNativeQuery(queryStr, ClasseQualquer.class);

Obtendo um objeto Query configurado como acima, é possível realizar operações como essas abaixo:


List dados = instanciaObjetoQualquer.getDadosParticulares();

Esse simples macete pode ajudar bastente para obter objetos, que necessitem manter o acesso aos objetos relacionados, através de consultas bem elaboradas e com o desempenho do SQL.

Recentemente, precisei de um repositório que fosse aberto para uso, mas, que fosse possível manter projetos fechados com possibilidade de abrir para uma determinada quantidade de usuários. Encontrei o Assembla. O Assembla permite trabalhar com SVN ou Git, possui trambém recursos para trackin de projetos, wiki e outras ferramentas de colaboração que podem ser utilizadas de forma integrada com o repositório. Muitas dessas ferramentas estão disponíveis também para o pacote free, porém, diminui consideravelmente os recursos de armazenamento.

A administração é feita inteiramente Através do site, tornando possível atribuir e remover acesso aos usuários ao projeto, inclusive gerenciar permissões.

Achei essa ferramenta muito boa. É ideal para quem tem um projeto com vários colaboradores e que tem necessidade de mante-lo fechado. Taí a dica: Assembla; monte seu plano, pague baratou ou utilize de graça.

[]s.

Vale a pena dar uma olhada: Link.

Comentem.

[]s