Gestão do Caórdico e do Invisível

Conforme havia falado neste post sobre a Gestão do Caórdico e do Invisível, aqui vai um post mais detalhado sobre esse assunto. Mas gostaria de deixar bem claro que não sou nenhuma autoridade no assunto, seja sobre os assuntos do título e até mesmo sobre gerenciamento de projeto, muito aquém disso, porém estive lendo uns artigos e pesquisando um pouco mais sobre o assunto e com isso percebi que essas coisas se encaixam muito bem no nosso mundinho da TI. E sobre gerenciamento de projeto, falo sobre as experiencias que vivi, ou que vivenciei, ou que escutei, não sou gerente e realmente não posso falar com a experiencia de um gerente.

Embora, sejamos desenvolvedores e lidamos diariamente com aspectos tecnicos, conceitos de administração não servem apenas para o trabalho, estes conceitos são empregados em toda a sua vida pessoal, e acho que é um conhecimento muito válido para se ter.

Enfim, este assunto surgiu de uma entrevista que eu ví na Marilia Gabriela na GNT (não sei qual o nome do programa dela exatamente). Naquele dia ela entrevistava o Oscar Motomura, fundador da empresa chamada de Amana-key esta empresa é um centro de excelência em Gestão aplicada e inovações radicais na área. Enfim, a partir desta entrevista tomei conhecimento sobre estes temas, e ao começar a ler me identifiquei com os pensamentos, e com novos termos.

Bom, a idéia de Caórdico surgiu em 1999 (ou talvez um pouco antes, não sei a data exata) por Dee Hock fundador e Diretor Executivo Emérito da Visa Internacional, no livro que ele lançou entitulado Birth of Chaordic Age.

A palavra caórdico tem sua origem em duas palavras Caos e Ordem. Significando:

Comportamento de qualquer organismo, organização ou sistema autogovernado que combine harmoniosamente características de ordem e caos.

Este conceito não é uma coisa nova, é apenas uma observação sobre o universo, já feita por outras pessoas, para outras áreas, como pode-se notar em Física Quantica, ou mesmo na Teoria do Caos, ou ainda numa vertente de Psicologia chamada Gestalt (essa minha irmã que me ensinou =]). Ele ajuda a compreender que não se pode analisar o todo analisando uma parte, isoladamente. Não podemos entender o funcionamento do corpo humano por intermédio da análise de uma célula do fígado, dos fenômenos do universo por intermédio da análise de uma partícula subatômica, ou de uma cultura organizacional apenas olhando seu departamento de contabilidade. É necessário uma análise do todo, começando do relacionamento entre seu pessoal, até chegarmos nos relatórios estatísticos.

"Caórdicos somos, caórdicos vamos continuar sendo, caórdico é o mundo e caórdicas as instituições devem se tornar. Esse é um caminho para um futuro vivível nos séculos que virão." Dee Hock

Outra definição que nos faz compreender melhor, foi da origem do caórdico por Dee Hock, da fonte de suas idéias, que foram de um fenômeno físico que trata sobre o delicado equilíbrio entre o caos e a ordem no exato momento antes da mudança do estado líquido para o gasoso dos componentes químicos. Isto se chama estado caórdico, ou seja, entre o caos e a ordem e é o momento onde a energia do sistema atinge seu ponto máximo.

Este conceito, como já disse no outro post, me levou a pensar em como os projetos de TI são, e de como eles são gerenciados hoje, e me fez ver que caórdico tem tudo a ver com a TI, e é claro que deve ter muito a ver com outras áreas tbm, mas como eu sou um cara muito especialista, apenas sei de TI. =)

Contudo, em algum artigo que li por ai sobre este assunto, o cara da um exemplo do Surf, e mostra quantas variáveis imprevisíveis e caóticas um surfista tem que lidar para se equilibrar na prancha e "dropar" uma onda, como por exemplo, o vento, a força da onda, o movimento da onda, a altura da onda, etc etc. Sendo estas coisas, todas conhecidas, porém impossíveis de se determinar com precisão.

Isto nos leva a fazer uma analogia com os projetos e o gerenciamento de projetos. Quantas coisas são previsíveis, mas indeterminadas? Como um gerente consegue lidar com tanto caos, e mesmo assim conseguir organizá-lo? São muitas coisinhas, que podem acontecer no meio do caminho, que agora eu realmente consigo ver, o porque este modelo antigo de Waterfall é tão precário. Eu acho que é um pouco desta comparação com as outras áreas que falta a nossa área, principalmente neste quesito.

Não é de se admirar que a maioria dos projetos segue o mesmo padrão de atraso na entrega, qualidade deixada de lado por causa de prazo, e correria na reta final. Realmente é impossível prever o que vai acontecer num projeto, no começo dele, quando normalmente é feita a estimatíva, e os prazos são estabelecidos, e muitas vezes isso é feito com o conhecimento de apenas uns 50% do que precisa ser feito, e isso é perigosíssimo. Sei que existem as "porcentagens de cagaço", o levantamento dos riscos, e tudo mais, mas ao meu ver este tipo de planejamento perde de longe para uma metodologia ágil.

Outra coisa que achei bem interessante, é sobre a Gestão do Invisível. Já tinha ouvido falar, mas acho que quando li sobre o assunto, não compreendi realmente. Este artigo do Oscar Motomura, fala muito bem sobre este tipo de gestão, e como isso pode influenciar de maneira positiva e negativa uma empresa, e como ela pode estar fadada ao fracasso por um simples erro, ou falta de atenção em um ponto que pode ser crucial. Em seu artigo, Oscar Motomura da alguns exemplos simples, como por exemplo:

Um grande grupo financeiro, conhecido por seu pioneirismo na área de tecnologia, realiza uma profunda reorganização. Num efeito colateral imprevisto, seus funcionários perdem a confiança no conjunto de valores que fazia da empresa um dos melhores lugares para se trabalhar. O grupo continua como um dos mais avançados do mercado em tecnologia e seus resultados ainda são bons, mas seus melhores talentos estão aos poucos deixando a empresa e os universitários, que antes faziam fila para juntar-se ao grupo, agora parecem preferir outras opções.

Ao final de seu artigo, ele traz uma lista de algumas coisas que podem ser levantadas para a gestão do invisível, alguns pontos importantíssimos que a maioria das vezes passa desapercebido. Então abaixo, seguem os itens que achei mais interessantes.

• Custo da desarmonia e dos desgastes interpessoais no dia-a-dia
• Custo da competição predatória, da ausência de cooperação
• Custo da desconfiança e dos controles excessivos
• Custo da não-reciclagem
• Custo da desmotivação, da falta de pique das pessoas
• Custo da acomodação pelo sucesso alcançado no passado
• Custo da falta de diálogo e de sintonia
• Custo do não se importar com o amanhã e focar no curto prazo
• Custo do turnover de pessoal
• Custo da “taxa de urgência” e do fazer na última hora
• Custo da falta de criatividade
• Custo do refazer, do corrigir, do compensar erros
• Custo da tecnologia obsoleta
• Custo da manutenção excessiva
• Custo da baixa produtividade
• Custo da burocracia

"Estamos num ponto do tempo em que uma era de quatrocentos anos está morrendo e outra está lutando para nascer – uma mudança de cultura, ciência, sociedade e instituições muito maior do que qualquer outra que o mundo já tenha experimentado. Temos à frente a possibilidade de regeneração da individualidade, da liberdade, da comunidade e da ética como o mundo nunca conheceu, e de uma harmonia com a natureza, com os outros e com a inteligência divina como o mundo jamais sonhou." Dee Hock

Links sobre o assunto:
Éra Caórdica (Blog)
Você S/A
Oscar Motomura
Site Caórdico
Google

Fábula dos Porcos - Desenvolvedores de hoje

Bom, faz tempo que queria escrever um post sobre esta fábula, nem que fosse apenas para "colá-la" na íntegra aqui. Vou aproveitar para fazer uns comentários também, mas vou fazê-los antes de você ler a fábula, então se você não estiver entendendo nada, depois de ler o texto tudo fará mais sentido, ou leia primeiro a fábula depois meus comentários, ou só leia a fábula, ao

Sobre esta estória tenho as seguintes opiniões:

Estamos virando especialistas em ferramentas e tecnologia, e estamos nos esquecendo do principal: a "solução". Não falo como se estivesse de fora do grupo, falo apenas como uma das pessoas que está se dando conta dessa situação, como tantas outras já perceberam, e tantas outras que estão percebendo. Tomando um exemplo simples, hoje vemos 99% das empresas contratando "Desenvolvedores [escreva-aqui-alguma-tecnologia]". No meu caso, eu sou um "especialista" em Java, mas mais que isso, sou um desenvolvedor de soluções, e tenho me dando conta disso a pouco tempo. Vejo hoje, aquele pessoal mais velho que eu, que ficou estagnado em certas "liguagens/ferramentas", como delphi, VB, Cobol, C, etc, e não faz mais nada além daquilo, e eles reclamam: "Po, não tem mais emprego na minha área.". Mas afinal, qual é seu emprego/área? Manipulador de ferramenta, ou desenvolvedor?

Mas por que o desenvolvedor está se tornando especialista? Na verdade o que está empurrando isso, é justamente o mercado ou os empregadores. Por exemplo, as empresas agora, estão numa corrida para SOA e BPM, como se isso fosse resolver todos os seus problemas. Ao menos mostra pra "fora" que a empresa investe em sí mesma. Mas até que ponto isso é bom? Um problema que vejo, é justamente essa corrida. Conheço pessoas que entraram em empresas agora, ou a pouco tempo atrás para participar de uma reestruturação de processos e arquitetura da tal empresa. "Vamos fazer uma nova arquitetura baseada em SOA e BPM! Isso fará com que garantamos uma integração contínua de novas soluções.". Aí é que está o grande erro, BPM hoje, segundo seus conceitos básicos, requer que a empresa seja re-estudada (insight) e que os processos sejam levantados, e não que a empresa seja reestruturada, creio que esse seja o maior erro cometido hoje em cima desses conceitos.

Uma coisa importante, e que muita gente não leva em consideração, é que TI é um MEIO e não um FIM, e está fadada ao fracasso a empresa que emprega a TI desta maneira. Ela não deve atrapalhar, e sim te ajudar e te dar agilidade, ao menos é isso que se pensou no começo quando inventaram os computadores. Contudo hoje somos escravos da TI, temos que moldar nossas maneiras, e processos de acordo com a TI e não ao contrário. Tive uma experiência esses dias atrás, na verdade não foi comigo esta experiência, mas me contaram o que aconteceu, e acho que serve como um simples exemplo. Um cliente de um certo projeto, agora só pode usar Gtalk para comunicação externa, então os desenvolvedores precisariam ter acesso ao gtalk para conversar com o cliente, e AGILIZAR a comunicação, porém na empresa onde eu trabalho o uso do gtalk é bloqueado. A gerente do projeto requisitou então que fosse liberado o uso do gtalk para os desenvolvedores do seu projeto o que foi negado. Isso mostra que as pessoas trabalham para a TI, e não o contrário. Não quero dizer que IMs devam ser liberados e tudo mais, justamente por causa de poucos "nonsenses" que abusam do seu uso, e os outros 90% pagam por isso, mas digo que a TI tem que trabalhar para você, agilizar a sua vida, e não atravancá-la. Não era esse o conceito principal de quando foi criado o computador?!

Esta fábula ainda me lembrou, sobre uma vertente da Administração, que está ganhando muito espaço nos últimos anos, que é a administração do caórdico, e a administração do invisível. Esta vertente de Administração se reflete hoje nas metodologias ágeis, que nada mais é, que "ter organização no caos", e administrar variáveis caóticas. Acho que administração do caórdico vale um outro post (fica pra próxima).

Contudo, a área de TI ainda é nova em comparação com outras áreas, que existem a séculos, e dentre as décadas tem evoluído. Apenas a TI precisa olhar um pouco mais pra fora, e não tentar reescrever toda a historia própria, até chegar no ponto onde o resto das coisas estão, e acho mesmo que é isso que está sendo feito, citando o exemplo da comparação da Administração e das metodologias ágeis, o que precisa mesmo é as pessoas envolvidas prestarem mais atenção no externo, e não serem apenas especialistas. É isso que garantirá o contínuo sucesso.

A Fábula dos porcos assados

---

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque... Até que descobriram um novo método.
Mas o que quero contar é o que aconteceu quando tentaram mudar o SISTEMA para implantar um novo. Fazia tempo que as coisas não iam lá muito bem: as vezes, os animais ficavam queimados demais ou parcialmente crus. O processo preocupava muito a todos, porque se o SISTEMA falhava, as perdas ocasionadas eram muito grandes - milhões eram os que se alimentavam de carne assada e também milhões os que se ocupavam com a tarefa de assa-los. Portanto, o SISTEMA simplesmente não podia falhar. Mas, curiosamente, quanto mais crescia a escala do processo, mais parecia falhar e maiores eram as perdas causadas.
Em razão das inúmeras deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de reformar profundamente o SISTEMA. Congressos, seminários e conferencias passaram a ser realizados anualmente para buscar uma solução. Mas parece que não acertavam o melhoramento do mecanismo. Assim, no ano seguinte, repetiam-se os congressos, seminários e conferencias.

As causas do fracasso do SISTEMA, segundo os especialistas, eram atribuídas a indisciplina dos porcos, que não permaneciam onde deveriam, ou a inconstante natureza do fogo, tão difícil de controlar, ou ainda as arvores, excessivamente verdes, ou a umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.
As causas eram, como se vê, difíceis de determinar - na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: maquinário diversificado, indivíduos dedicados exclusivamente a acender o fogo - incendiadores que eram também especializados (incediadores da Zona Norte, da Zona Oeste, etc, incendiadores noturnos e diurnos - com especialização matutina e vespertina - incendiador de verão, de inverno etc). Havia especialista também em ventos - os anemotecnicos. Havia um diretor geral de assamento e alimentação assada, um diretor de técnicas ígneas (com seu Conselho Geral de Assessores), um administrador geral de reflorestamento, uma comissão de treinamento profissional em Porcologia, um instituto superior de cultura e técnicas alimentícias (ISCUTA) e o bureau orientador de reforma igneooperativas.

Havia sido projetada e encontrava-se em plena atividade a formação de bosques e selvas, de acordo com as mais recentes técnicas de implantação - utilizando-se regiões de baixa umidade e onde os ventos não soprariam mais que três horas seguidas.
Eram milhões de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores arvores e sementes, o fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, alem de mecanismos para deixa-los sair apenas no momento oportuno.
Foram formados professores especializados na construção dessas instalações. Pesquisadores trabalhavam para as universidades para que os professores fossem especializados na construção das instalações para porcos. Fundações apoiavam os pesquisadores que trabalhavam para as universidades que preparavam os professores especializados na construção das instalações para porcos etc.
As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo depois de atingida determinada velocidade do vento, soltar os porcos 15 minutos antes que o incêndio médio da floresta atingisse 47 graus e posicionar ventiladores gigantes em direção oposta a do vento, de forma a direcionar o fogo. Não é preciso dizer que os poucos especialistas estavam de acordo entre si, e que cada um embasava suas idéias em dados e pesquisas específicos.

Um dia, um incendiador categoria AB/SODM-VCH (ou seja, um acendedor de bosques especializado em sudoeste diurno, matutino, com bacharelado em verão chuvoso) chamado João Bom-Senso resolveu dizer que o problema era muito fácil de ser resolvido - bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então numa armação metálica sobre brasas, até que o efeito do calor - e não as chamas - assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor geral de assamento mandou chamá-lo ao seu gabinete, e depois de ouvi-lo pacientemente, disse-lhe: "Tudo o que o senhor disse esta muito bem, mas não funciona na pratica. O que o senhor faria, por exemplo, com os anemotecnicos, caso viéssemos a aplicar a sua teoria? Onde seria empregado todo o conhecimento dos acendedores de diversas especialidades?". "Não sei", disse João. "E os especialistas em sementes? Em arvores importadas? E os desenhistas de instalações para porcos, com suas maquinas purificadores automáticas de ar?". "Não sei". "E os anemotecnicos que levaram anos especializando-se no exterior, e cuja formação custou tanto dinheiro ao pais? Vou manda-los limpar porquinhos? E os conferencistas e estudiosos, que ano após ano tem trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Heim?". "Não sei", repetiu João, encabulado. "O senhor percebe, agora, que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução ha muito tempo atrás? O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotecnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas! O que o senhor espera que eu faça com os quilômetros e quilômetros de bosques já preparados, cujas arvores não dão frutos e nem tem folhas para dar sombra? Vamos, diga-me?". "Não sei, não, senhor". "Diga-me, nossos três engenheiros em Porcopirotecnia, o senhor não considera que sejam personalidades cientificas do mais extraordinário valor?". "Sim, parece que sim". "Pois então. O simples fato de possuirmos valiosos engenheiros em Porcopirotecnia indica que nosso sistema é muito bom. O que eu faria com indivíduos tão importantes para o pais?" "Não sei". "Viu? O senhor tem que trazer soluções para certos problemas específicos - por exemplo, como melhorar as anemotecnicas atualmente utilizadas, como obter mais rapidamente acendedores de Oeste (nossa maior carência) ou como construir instalações para porcos com mais de sete andares. Temos que melhorar o sistema, e não transforma-lo radicalmente, o senhor, entende? Ao senhor, falta-lhe sensatez!". "Realmente, eu estou perplexo!", respondeu João. "Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por ai que pode resolver tudo. O problema é bem mais serio e complexo do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia - isso poderia trazer problemas para o senhor no seu cargo. Não por mim, o senhor entende. Eu falo isso para o seu próprio bem, porque eu o compreendo, entendo perfeitamente o seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo, não é mesmo?".

João Bom-Senso, coitado, não falou mais um "a". Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu.

TV Digital e JavaTV

Como alguns devem saber a TV Digital de alta definição (HDTV) foi lançada oficialmente no Brasil neste domingo dia 02 de Dezembro, porém ainda tem muito pra ser feito, alterado, e para termos um sistemas 100% HD vai demorar alguns anos, segundo as próprias emissoras, prevendo custos e a própria tecnologia interna, isso sem contar é claro a massa da população brasileira, que deverá se adaptar para tal.

O padrão para a transmissão adotado pelo governo, que encabeçou essa migração, para TV Digital foi o Japonês. Este sistema japonês segundo as emissoras, é mais robusto, e por isso foi o escolhido. Contudo, a transmissão é apenas uma parte da infra-estrutura necessária, existem várias outras coisas envolvidas, como citado abaixo:

• Gravação - exige equipamentos especiais e diferentes da parafernalha que existe hoje nas emissoras.
  
• Codificação - O padrão adotado aqui no Brasil, foi o MPEG-4 (primeiro no mundo a adotar este padrão), melhor do que o padrão mundial que é o MPEG-2.
  
• Multiplexação - Equipamentos mais robustos, terão que ser empregados, sendo que será necessário empacotar junto, uma imagem maior, um som com mais qualidade (podendo até´ser um Surround 5.1) e os programas de interatividade.
  
• Transmissão - Aqui que entra a tecnologia japonesa de transmissão, o tal do ISDB.
  
• Recepção - As TVs estão prontas para decodificar sinais UHF normais, e isso é um problema que será resolvido com um outro decodificador.

Mas existe uma boa notícia para nós desenvolvedores, um novo nicho de mercado está se abrindo aqui no brasil. A plataforma Java, já há anos disponibiliza uma api para se trabalhar com tais coisas, a JavaTV, a qual é construída em cima da tecnologia JME. Esta nova API, requer sobretudo conhecimento nas tecnologias de transmissão de dados, na API JMF (Java Media Framework) e nas tecnologias de codificação de imagens como é o caso da MPEG.

Para quem não conhece a tecnologia JME, vai aqui uma breve explicação sobre ela. A tecnologia JME, é subdividida em Configuration e Profile. Em configuration, podemos encontrar o tal do CLDC que é o que existe em celulares hoje, e o CDC, que é uma configuration mais avançado, que roda em equipamentos mais avançados, como PDAs e os tais dos SET-TOP Boxes, que para quem sempre ficou curioso em saber o que é, é o tal do aparelhinho de TV. Já em Profiles encontramos o MIDP que é encontrado nos celulares e roda em cima do CLDC, e outros profiles como o Personal Profile, usado nestes equipamentos mais avançados, que roda em cima de CDC. Para quem já deu uma olhada em JME, nem que seja por curiosidade já se deparou com esta figura, que da uma explanação geral dobre a tecnologia Java. (Mais informações sobre JME ou aqui)
Agora, voltando a JavaTV API, temos a seguinte ilustração, que mostra como é a arquitetura da tal da java TV:

Como os caras que dão nomes para as coisas não costumam ser muito originais, as aplicações para JavaTV são chamadas de Xlets, seguindo a idéia das MIDlets, Servlets e Applets. =)

Tá, tá... Vamos ao que interessa. Como eu desenvolvo para essa tal de JavaTV?
Primeiro de tudo vc precisa das bibliotecas para o desenvolvimento, e uma leitura sobre o que é e para que serve cada coisa da API, e para isso um bom lugar é a Home do JavaTV.

Após uma breve leitura sobre algumas coisas, mas ainda está se perguntando, "what the hell i need?" Ok. Você irá precisar da biblioteca da JavaTV, de um emulador, e de uma IDE. Segue abaixo os links:

• XletView - emulador para aplicações Xlet
• IDE Eclipse - minha ide favorita

Bom, a princípio o que vc precisa é isso. O XletView, já vem com a lib do javaTv, assim como a do JMF e JavaAssist. Tudo o que vc precisa a princípio.

Para fazer uma aplicação e rodá-la, é bem fácil e nada fora do comum, basta seguir os passos abaixo:

1. Faça o download do XletView e Descompacte-o em qualquer diretório.
   
2. Na sua IDE, crie um novo projeto, Java (Java Project no eclipse)
3. No Build Path do projeto adicione as seguintes libs:
1. xletview-0.3.6/xletview.jar
   xletview-0.3.6/jars/javassist.jar
   xletview-0.3.6/jars/metouia.jar
   xletview-0.3.6/jars/nanoxml-2.2.3.jar
   xletview-0.3.6/JMF2.1.1/lib/customizer.jar
   xletview-0.3.6/JMF2.1.1/lib/jmf.jar
   xletview-0.3.6/JMF2.1.1/lib/mediaplayer.jar
   xletview-0.3.6/JMF2.1.1/lib/multiplayer.jar

Pronto, projeto configurado com as bibliotecas necessárias.

Antes de botarmos a mão na massa, vamos apenas conhecer um pouco da arquitetura do JME e do Xlet, apenas para desmistificar o negócio. Antes de mais nada vai uma breve explicação sobre o ciclo de vida de um Xlet.
Sendo ele, construido em cima da plataforma JME, não é de se adimirar que o ciclo de vida dele, imita aplicações construidas para celulares, ou seja em cima de MIDP (ao menos para os celulares de meros mortais, onde não roda um CDC+PP).
Como estava dizendo, o ciclo de vida é parecido com o de uma MIDlet (MIDP), para quem já conhece um pouquinho, segue uma simples comparação (paralelo):

MIDLET

1. Herança padrão: MIDlet (aqui tem que ser extends)
   
2. Ciclo de Vida
1. public void startApp() - método chamado pelo ApplicationManager para startar a aplicação
   
2. public void pauseApp() - método chamado pelo ApplicationManager para pausar a aplicação, ou pelo usuário, ou quando chega uma chamada, etc.
   
3. public void destroyApp() - método chamado assim que a aplicação vai ser destruida.
   
3. Interface de Listener de botões: CommandListener

XLET

1. Interface pdrão: Xlet (aqui é melhor, sendo apenas um implements)
2. Ciclo de vida
1. public void initXlet(XletContext) - método chamado antes de todos para inicialização dos componentes da aplicação, e a manipulação do XletContext.
   
2. public void startXlet() - método chamado para iniciar a aplicação para o usuário
   
3. public void pauseXlet() - método chamado quando houver um evento que cause uma pausa na aplicação
   
4. public void destroyXlet() - método chamado na destruição da aplicação.
   
3. Interface de Listener de botões: ActionListener (aquele do AWT)
   

Basicamente, os Xlets tem um método a mais que MIDlets, que é o initXlet. Abaixo, segue um diagrama de estados mostrando o ciclo de vida de um Xlet:

Para este post não ficar muito grande, a implementação do primeiro exemplo segue num próximo post. (em breve)

Abraços.

Fazendo um Multi-interactive-touch screen com o Wiimote

Bah, vi esse post no Hackaday e achei muito cool!

Acho que vou brincar com um negócio desses, e parece ser simplex de fazer =)

ps: alguém tem um wiimote para me emprestar? =)

Abraços!

Problemas com Hibernate e MySQL

Ontem, estava ajudando um amigo com um problema que estava acontecendo num sistema que ele estava desenvolvendo. O escopo era o seguinte:

Um software de controle Web, utilizando o banco de dados MySQL 5, utilizando Hibernate. Outro pequeno software que fica rodando no servidor, como um daemon, executando algumas tarefas, e caso aconteça um erro ele insere um registro em uma certa tabela, no mesmo banco MySQL que o sistema Web utiliza.

Até ai tudo bem. O que acontecia é que, o software daemon inseria coisas no banco, porém o software Web, não conseguia enxergar estes novos dados inseridos. Começamos a quebrar a cabeça pensando que era problema no hibernate, mudamos toda a parte de cache, desabilitamos o cache L2 do hibernate, tiramos o cache daquela consulta, tiramos o cache total da session, e nada. E realmente não podia ser aquilo, porque o mesmo esquema de configuração usado lá é o mesmo esquema usado em outros softwares que estamos desenvolvendo.

Então, após muita busca, encontramos a seguinte documentação:
http://mysql2.mirrors-r-us.net/doc/refman/5.0/en/innodb-transaction-isolation.html

O problema que ocorria era justamente no MySQL, pois ele por padrão usa um modo de cache interno para otimização de desempenho, que realmente não é muito interessante. E quando a aplicação Daemon comitava o registro, a aplicação web não via aquele registro, por causa do cache do MySQL.

A solução foi então aplicar a configuração referida no link acima, que é:

1. Baixar o MySQL
2. Editar o arquivo [dir-install-mysql]/my.ini
3. Procure a linha [mysqld]
4. adicione o seguinte, logo abaixo:
   

   transaction-isolation=READ-COMMITTED

5. Startar o MySQL
   

Isso fará com que o MySQL atualize o seu cache, com os dados gravados por outras aplicações ou conexões/sessões.

obs: Tem uns comentários interessantes, no final da página do mysql.

Espero que isso ajude alguém!

Valeu.