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.

Bush It!

Um amigo postou um vídeo, e através deste vídeo, garimpando, cheguei a estes outros abaixo.

Vejam estes vídeos:

Crítica muito boa.


E para representar a atual situação do País. É... hoje só amanhã!



"É mole?! É mole mais sobe..."

Ahhhh e pra quem não conhece, os caras são os tais de: Os Barbixas

C++ Sucks! (by Linus Torvalds)

Primeiro pensamento: "Ahhhh que facada!"

Alguns amigos irão dar pulos mais altos que eu a hora que lerem isso, especialmente um =)

Mas enfim, este post me levou a esta discussão, que tornou-se mais "quente" quando Linus Torvalds (é... aquele do tal do GNU/Linux) respondeu o seguinte:

C++ is a horrible language.

Ele continua:

In other words: the choice of C is the only sane choice. (...)
I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices.

E diz mais:

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.

Achei que este tipo de "flame war" sobre linguagens, IDEs, times de futebol, etc... só acontececem entre os mortais =)

Deixo duas frases:
"Use a melhor ferramenta para o trabalho"
"Para quem só tem um martelo, todo parafuso parece prego."

Grupo de Usuárias de Programadores

Este post é apenas uma homenagem a este grupo ou GUPRO =) Eu vi esses dias no Blog do Urubatan.

Demais! Parabéns! Muito legal todos os posts!

E o testesinho para saber "How Nerdy you are" também é bem legal.

Este foi o meu resultado:



Bom, ao menos meu resultado foi menor que do urubatan =) UFA! =) hahahaha

SCEA - JEE5 Beta Exam

É... descobri só hoje (já meio atrasado) que abriu a nova prova SCEA atualizada à nova versão JEE5. E ela está na versão Beta, o que por tradição da Sun é FREE. Já que é "de grátis" então vamos fazer né =)

Então, se você quer se arriscar nesta certificação, ao invés de investir na SCWCD, SCBCD e tantas outras... invista seu tempo nesta =)

As inscrições abriram no dia 20/09 no site da prometric. Então, logue lá, e entre na opção Schedule an Appointment, vai pedir algumas coisas, e depois irá aparecer uma caixa com a certificação que vc quer fazer. A SCEA Beta JEE5 é a última opção.

A prova I deve ser feita até dia 20 de outubro, ou seja, muito pouco tempo para estudar =) E são 160 questões, e o candidato terá 4h para fazer a prova. Como a prova é beta, tem muita questão mesmo, e a cada questão tem um espaço para um comentário sobre a questão.

O prazo para a fase II começa em Novembro e termina em Dezembro juntamente com a parte III.

Então, boa sorte a quem for se aventurar. Segue abaixo alguns links, que podem ajudar nesta empreitada:

Site Oficial

Link de divulgação no JavaRanch, com algumas informações
MailGroup criado para a prova
NYCJAVA - SCEA Study Group

Se alguem souber de algum material interessante e/ou informação útil, favor postar aqui!

Valeu!

Clustering de Jboss - Parte 1

Há algumas semanas atrás eu estava estudando a melhor arquitetura para uma nova aplicação que estamos fazendo. Esta aplicação a princípio deveria por obrigatoriedade rodar clusterizada e distribuida, sendo ela dividida em algumas partes distintas. OK, pensei comigo mesmo, a melhor maneira de fazer isso, é com EJB mesmo, não vai ter como fugir desta vez.

Embora, EJB tenha um certo overhead na parte de lookup e tudo mais, me pareceu a melhor saida no momento mesmo. E analisando melhor a aplicação, a melhor saida ainda, era usar JMS. Devido ao Assincronismo da aplicação. Enfim, para isso tive que estudar certinho como é que o jboss trabalha com o cluster dele, e como fazer funcionar, além de ter que verificar como fazer para que os MDBs e a Fila ficassem clusterizados também.

Então, resolvi postar aqui como fazer tudo isso funcionar, pois a documentação do JBoss não é lá grandes coisas, embora tenha ajudado muito, e o material na internet não é tão abundante assim.

Colocando o Jboss em Cluster

Bom, para utilizar o Jboss em cluster, primeiro é claro você precisa de 2 máquinas ligadas em rede. Da até pra utilizar na mesma para fazer testes, mas da muito empenho, vai por mim, mas se você precisa mesmo utilizar, você precisa trocar TODAS as PORTAS que o Jboss usa, que não são poucas, e para isso precisa garimpar nos milhares de .xml que ele tem (boa sorte =]). Este post pode te ajudar em algumas, porém ele fala de Jboss rodando na configuração default, mas na all que é onde ele já tem as configurações de cluster, tem muito mais portas =).

Então temos, 2 máquinas ligadas em rede e conversando entre si. Simplesmente o que precisamos fazer para colocá-las em Cluster é levantar o jboss de uma máquina e depois de outra, utilizando a configuração all, assim:

run.bat -c all -b 10.77.6.26 (coloque o ip da maquina aqui)

Como pode se notar, o parametro -c indica qual configuração ele vai utilizar, e o parâmetro -b qual será o IP utilizado para identificar a máquina. Caso não seja passado o ip, o default assumido será 127.0.0.1.

Quando "subir" um jboss você notará nas mensagens de log que ele reconheceu que é o primeiro nó do cluster, ou que ele não conseguiu achar nenhum outro nó "no ar" para formar um cluster. Este Jboss estará rodando OK, porém sozinho esperando encontrar algum outro nó para formar o cluster. O próximo passo então, é subir o outro Jboss. Na hora que ele estiver subindo, irá mandar uma mensagem em multicast (ip=228.1.2.3 porta=45566 via UDP) o servidor que já está no ar irá receber esta mensagem, e então inicia o "handshake" e pronto, eles entram em cluster. Tudo isso será mostrado no log do seu jboss, então para isso deixe o cosole aberto e vá vendo as mensagens que vão aparecendo. Irá aparecer algo assim para o primeiro nó:

16:12:40,828 INFO [DefaultPartition] Number of cluster members: 1
16:12:40,828 INFO [DefaultPartition] Other members: 0
16:12:40,828 INFO [DefaultPartition] Fetching state (will wait for 30000 milliseconds):
16:12:40,828 INFO [DefaultPartition] State could not be retrieved (we are the first member in group)

Você pode inclusive ter vários "clusteres" em uma mesma rede, basta para isso mudar o nome do cluster (no arquivo /server/all/deploy/cluster-service.xml), que por default vem com o nome de DefaultPartition. Para verificar se os seus Jboss estão em cluster, além de ver no console que o cluster foi formado, abra o jmx-console e procure por DefaultPartition e clique nele. Lá você encontrará os IPs das máquinas que estão fazendo parte do Cluster na opção CurrentView.

Vale a pena ressaltar que a comunicação padrão entre os nós do cluster é feita via UDP com Multicast. No meu caso, eu enfrentei problemas para que os nós se achassem, havia muita demora para formar o cluster, e o farm-deployment raras vezes acontecia. Por um problema de Windows (eu li em algum lugar alguma coisa assim), ou do elemento de rede entre os pontos (a nossa rede é uma bosta), não sei bem o que poderia ser, mas não me surpreenderia com nenhuma das possibilidades. O que me deu esta luz, foi justamente este post, ao menos ele estava tendo o mesmo problema que eu. Lembre-se disso caso esteja tendo problemas, isso pode te economizar muito tempo =)

Enfim, o que tive que fazer para funcionar foi alterar o protocolo de UDP para TCP. Fiz isso no arquivo /server/all/deploy/cluster-service.xml). Logo no começo do arquivo existe uma tag chamada < attribute name="PartitionConfig" > , e dentro desta tag tem um outro elemento chamado < Config >. O que vem habilitado (descomentado) por padrão é o UDP, e (graças a Deus) logo abaixo vem a configuração de TCP comentada. Então o que precisa fazer é descomentar um e comentar o outro. E alterar o elemento TCPPING para que ele contenha os IPs dos principais nós do seu cluster, os quais ele acha no começo, depois você pode incluir outros. Então ficaria algo mais ou menos assim:

< tcpping initial_hosts="${jboss.bind.address}[7800],10.77.6.40[7800]"

Sendo que o próprio jboss substituirá jboss.bind.address pelo seu endereço de IP, e o ip que aparece ali, é o IP do outro nó do seu cluster, ou quantos nós você tiver.


Farm Deployment

Outro aspecto interessante do JBoss, é o deployment em farm. Que nada mais é, você precisar apenas se preocupar com um dos nós, e este cuida de replicar o seu estado para os outros. Então, basta apenas você ter sua aplicação publicada em um dos nós e este copiará a todos os outros a aplicação. O mesmo acontece quando você fizer undeploy de uma aplicação em um dos nós.

Para publicar uma aplicação no farm, basta você copiá-la para o diretório /server/all/farm ao invés de copia-la para /server/all/deploy como é o padrão. Caso você copie para o diretório deploy a sua aplicação será publicada apenas na máquina em questão e o farm-deployment não será executado.

Conclusão

Eu não esperava, mas este será o primeiro de uma série de 3 posts (possivelmente), pois senão iria ficar um post muito grande, e eu não gosto de ler posts muito grandes. Então pretendo nos próximos posts falar sobre como configurar sua fila JMS no esquema de High Availability. E ainda uma aplicação de exemplo para testar este esquema. E como deixar seu Jboss mais "tunado" =)

Até!

[edited]
O Paulo Jerônimo tem um screencast bem interessante sobre como rodar mais de um jboss em cluster na mesma máquina.

Photosync - Amazing!

Eu não sei quem já conhecia esta "ferramenta/tecnologia" mas pra mim isso é novo. Posso dizer que fiquei realmente impressionado, e achei bastante interessante do aspecto tecnológico... E pasmem, não é coisa da Google hehehehe a MS saiu na frente e comprou os caras =(

O que isso faz? Ele pega milhares de fotos "tagueados" com uma certa palavra e sintetiza as imagens pegando pedaços de cada uma, juntando tudo, formando assim uma imagem tridimensional. Pense nas possibilidades?! ;) cool! Agora assista o vídeo!

Vídeo da Apresentação do Photosync no TED

Quem sabe depois vc queira dar uma testadinha:
Try it - Photosync

ps: Eu não consegui testar, o programa não conseguiu carregar "a Collection...", nem com o IE funfou essa parada.

Testando Servidor de Email via Telnet

As aplicações de hoje, em quase sua maioria compreendem aplicações para internet ou com alguma interação com internet, e normalmente utilizam-se de serviços que enviam emails. Como as linguagens hoje, possuem API´s para tudo que é coisa, não podia deixar de faltar API´s para envio de email. Essas API´s, já fazem muitas coisas que não nos interessa saber de como é feito. No caso de Java existe a JavaMail API, ela já faz parte da especificação e já vem como parte da espec. JEE. Mas mesmo assim existem API´s complementares para envio de email, como é o caso da Email-API da Apache. Aproveitando este post, um código simples para mandar emails é mais ou menos assim:



O que muitos desenvolvedores não sabem, é como funciona um servidor de email (smtp), principalmente como ao menos testar se ele está funcionando. Exporadicamente eu preciso testar um servidor de smtp localizado em algum servidor, e para isso eu sempre preciso pesquisar quais são os comandos exatos para fazer um teste via telnet neste servidor. Mas como um cara esperto que sou, eu anotei (depois da enézima vez que precisei) e humildemente vos posto esta maneira simples de fazê-lo, e agora vocês já sabem onde achar (e eu também) =)

telnet ipDoServidorSmtp 25
mail from: email@domain.com [enter]
rcpt to: seuemail@domain.com [enter]
data [enter]
[aqui vai o corpo do email]
. [enter]
quit

Just another Tip & Trick.
Valeu

The Dark Tower - Finished

Este post é um useless post.

Terminei ontem o último livro da série a Torre Negra do autor Stephen King. Foram 7 livros, mais de 4000 (Quatro mil) páginas, de uma história envolvente, muito bem bolada, que te transportava para um mundo (vários mundos) cheio de aventuras e particularidades.

Stephen King (site oficial, wikipedia) é muito conhecido por ser o mestre do Terror/Suspense, muitos dele nem tanto terror e suspense assim, diria que ele é um autor bem completo, passando por Suspense, Terror, Drama, Aventura, Épico. Mas queria deixar claro que seus filmes não são um terror do tipo "Massacre da Serra-Elétrica", ou muito menos aqueles filmes de terror de adolescentes americanos, ou como dizia um amigo (que trabalhou na Wise comigo em Curitiba) o Marcão, "filme de galerinha" =).

Algumas obras de Stephen King são muito conhecidas, alguns já clássicos, outros bem contemporâneos, como O Iluminado (The Shining com duas versões), A coisa (It), Um sonho de Liberdade (The Shawshank Redemption), À Espera de um Milagre (The Green Mile), A Mansão Marsten (Salem´s Lot), A tempestade do Século (Storm of the Century - que é continuação do Salem´s Lot), Conta comigo (Stand By Me), Cemitério Maldito (Pet Sematary), Carrie a Estranha (Carrie), Christine (Christine) esses que lembrei agora de cabeça, mas existem muitas obras mesmo, deste grande autor, muitas delas transportadas para Televisão e Cinema.

Bom, já deu pra perceber que sou um grande fã de Stephen King. Apesar de não ser fanático, este Livro A Torre Negra, é sem dúvida a grande obra dele, até mesmo reconhecida assim por ele. Um aspecto interessante de se observar nas obras de Stephen King, é que todas, mas muito mais principalmente esta, estão interligadas, ou tem algum personagem ou faz referência a outras de suas obras. Por isso não se surpreenda, caso você comece a ler esta história e achar que já viu/leu algo assim em outra história de King. Afinal, o mundo é uma roda. =)

A idéia original da história surgiu de um poema épico do século XIX de Richard Browning chamado Childe Roland A Torre Negra Chegou (Childe Roland The Dark Tower Comes). Porém sua história também foi baseada no universo Imaginário de J. R. R. Tolkien, lendas como a de Rei Arthur e seus cavaleiros, usando ainda muitas referencias atuais (ao mundo atual), e ao Faroeste.

Eu resumo esta história como uma intersecção (ou por que não mistura?) de Senhor dos Anéis e de Matrix. Se você conseguir pensar em misturar tais coisas.

O principal personagem desta história é chamado de Roland, o qual é um Pistoleiro. Os pistoleiros são uma estirpe quase extinta, e eles são, digamos assim, os guardiões do Mundo. A Torre Negra, o objeto de maior desejo e o principal objetivo deste pistoleiro, está no centro de todos os mundos, e estes mundos são sustentados por Feixes de Luz, que são interligados no centro pela Torre Negra. Os mundos são ameaçados pelo Rei Rubro (Le Roy Russe), e por seu fiel mago, que assume vários nomes e formas, durante toda a história, uma delas é o Homem de Preto. E a história da Torre Negra, é iniciada assim:

"O Homem de Preto fugia pelo deserto. E o pistoleiro ia atrás."

A partir desta singela frase, um mundo (vários mundos) tomam forma, e personagens nascem e morrem. Há muita morte (menos pra você pistoleiro), sangue, aventura, drama, tensão, amor, paixão, lealdade, aprendizado, ódio, raiva, inteligência, brincadeiras... Realmente uma história completa.

Para quem gostaria de se aventurar com esta magnífica história, eu preciso dizer antes mais umas coisinhas. O primeiro livro, foi escrito em 1970, quando o autor ainda era um estudante universitário, e o segundo livro foi sair apenas em 1987 quando o autor, já estava mais maduro. Por isso se você não gostar do primeiro livro, leia-o inteiro mesmo assim (são apenas 200 páginas), então leia o segundo, se logo no começo você não gostar da história, dai sim, você poderá desistir, mas não antes disso OK?!

Além dos livros, no começo deste ano saiu pela Marvel Comics os quadrinhos do Pistoleiro chamado A Torre Negra (claro!).

Bom, pra finalizar uma lista dos livros da série a Torre Negra:

1. Volume I: O Pistoleiro (The Gunslinger)
2. Volume II: A Escolha dos Três (The Drawing of the Three)
3. Volume III: As Terras Devastadas (The Wastelands)
4. Volume IV: Mago e Vidro (Wizard and Glass)
5. Volume V: Lobos de Calla (Wolves of Calla)
6. Volume VI: Canção de Susannah (Song of Susannah)
7. Volume VII: A Torre Negra (The Dark Tower)

É... infelizmente é isso, me despeço hoje do Pistoleiro e de seu ka-tet e de sua busca (eterna). Não sei se queria mesmo que chegasse ao fim. É muito boa a história, e era bom sempre ter algo pra ler que fosse realmente agradável. Realmente, o que satisfaz é a busca e não o resultado da busca. =)

Longos dias e belas noites a todos!

Analogias de Desenvolvimento de Software

Achei uns artigos muitos bons navegando por ai.
Um dos que me "chocou", chamou mais a atenção, espantou... sei lá, um dos que gostei foi este artigo.

Ele me levou a lembrar que lá atrás na faculdade, quando nos era ensinado Análise de sistemas num esquema puramente WaterFall, utilizando abordagens Bottom-Up e Top-Down, nos era dito também, que para construir software deveríamos fazer como o pessoal de Construção Civíl, o qual fazia todo o projeto de um prédio, e depois começava a construir. Se eles conseguem/podem fazer isso por que um simples software não pode ser feito assim?!

No Artigo do primeiro link, ele começa contando uma historinha, contando quando foi para uma construção, ou para uma aula de engenharia civíl, não entendi direito, mas vou traduzir aqui:

"O que você está fazendo aqui?" - Eles perguntaram

Eles eram Encarregados, Gerentes de Projeto, Superintendentes, e estavam fazendo um projeto no Lean Construction Institute (LCI) (o que é isso ai não tenho a mínima idéia, mas eu acho que era pra ser conhecido). Verdade, que que o cara estava fazendo la?

Então o cara começou a explicar: "No desenvolvimento de Software, nos é ensinado que devemos gerenciar projetos como os projetos de Construção Civíl. Onde uma construção é planejada no início, custos e prazos são previsíveis, e os clientes recebem o que eles esperam receber."

Silêncio... "Você está brincando, certo?" "Não! Verdade, é assim que nos é ensinado."

Então, incredulidade torna-se em grades gargalhadas!

Quem já fez alguma construção, ou já precisou de que alguém construisse algo para você (o que é bem mais provável, visto que somos desenvolvedores de software), sabe que a obra sempre custa mais do que no início seu pedreiro disse que custaria, e a maldita obra parece não ter fim. Minha mãe está passando por uma reforma em sua casa, e já fazem quase 2 meses, isso que era pra terminar em 2 semanas. Sem contar, que obras externas sempre dependem das condições climáticas.
Outro artigo que achei legal, simples e direto foi este de Joel Spolsky. Tem ainda este.
Mas realmente uma Analogia mais real é a que Marcos Pereira, descreveu em: Desenvolver Software é igual a dirigir. Um dia ainda será assim em todo o lugar, e a paz mundial reinará! Mas até agora, poucas pessoas tem se beneficiado disso.
Outra pedrada, é um post do Thiago Arrais, onde ele diz que Fábricas de Software são uma analogia levada longe demais.

Acho que uma outra analogia boa para desenvolvimento de software como é feito atualmente neste modelo de WaterFall, está na agricultura. De que depende a agricultura e que o seu plantio tenha um bom rendimento? (Porque sejamos francos, tudo gira em torno do dinheiro. Ok, eu não sou nenhum agrônomo, mas vou tentar não falar merda)

1. De um bom preparo do solo no princípio - Ter bons profissionais, Análise e Arquitetura inicial
2. Plantar em época correta. - Saber o que usar.
   
3. Cuidado no início, com pesticidas, fungicidas e tudo mais. - Ser maleável quanto a arquitetura incial, pois ela pode mudar conforme o entendimento do que é pra fazer vai aumentando.
   
4. Rezar para não chover demais, nem de menos, em tempo de germinação. - Literalmente, rezar para que o entendimento inicial, realmente tenha previsto quase tudo, e que não surjam problemas muito complicados
   
5. Saber a hora de colher.
   
6. Rezar para não chover demais nem de menos em época de colheita. - Rezar para mostrar pro cliente na hora certa o software, para que ele não se decepcione de início. =)
   
7. Conseguir estocar ou vender em uma época que o preço está bom. - Ter um ótimo departamento de Relação com o cliente, para fazer ele enxergar o software mais belo do que realmente é. =)

Talvez não tenha sido feliz em todas as analogias, mas era pra ser um pouco engraçado =)

Enfim, eu ainda trabalho em um modelo WaterFall, não tenho como mudar isso facilmente. Não vou ficar falando por ai, que sou contra tudo, que vamos revolucionar o mundo, matar todos os gerentes que não pensam igual a nós, como muitos falam por ai. Mas quem sabe com o tempo, ou conhecimento necessário, ou status necessário, ou apoio necessário, ou todas essas coisas juntas, eu consiga ir fazendo esta mudança.

E por fim, não poderia faltar aquela velha analogia de desenvolvimento de software.

Sim o Google também "Buga" [OFF]

Esta foi a resposta a uma consulta simples que fiz ontem:

Configurando Virtual Host e Default Context no Tomcat

Bom, este post veio porque ontem ajudei um grande amigo meu com um probleminha neste aspecto. Queira aproveitar a oportunidade para deixar um grande abraço aqui pra ele, Daniel Kühl Lima, um dos únicos LPI3 do Brasil.

Normalmente quando você publica um servidor com um tomcat servindo uma aplicação, o que costuma-se fazer é simplesmente publicar a aplicação e passar a url para o usuário, por exemplo: www.meudominio.com.br:8080/aplicacao, e o usuário para acessar sua aplicação precisa digitar a url como consta ali, caso ele digita até o / ele irá cair naquela página default do tomcat, com links pra o Administrador e Manager.
Isso é beeem feio. Existe algumas maneiras de se fazer isso de uma forma mais "descente".
Primeiro, para melhorar, o usuário não precisa saber qual a porta para acessar a aplicação, então passar 8080 na url, é feio. Então o mais comum para arrumar isso é levantar o Tomcat com a porta 80. Para isso, é necessário alterar o arquivo [tomcatdir]/conf/server.xml trocando a porta na seguinte linha (normalmente está ~ pela linha 76):

< port="8080" maxhttpheadersize="8192">

trocar a linha pela

< port="80" maxhttpheadersize="8192">

Com isso resolvemos o problema de o usuário ter que digitar a porta 8080 na url. Porém, se o usuário digitar somente o seu domínio ele ainda acessará a página default do tomcat.
O que muita gente faz para corrigir isso, é instalar um Apache + Conector para Tomcat (para saber como configurar ver a documentação dos Connectors da Apache), e assim, ele configura para que o apache intermedie requisições para o tomcat, para que quando for acessado o raiz (www.meudominio.com.br) ele redirecione para a aplicação e pronto, o usuário não precisa mais saber qual o nome da aplicação.

Isso funciona. Mas para que ter que configurar mais uma coisa para acessar o tomcat, mais um possível ponto de erro!?
O que muita gente não sabe é que o próprio Tomcat tem suporte a Virtual Hosts.
Por default, o tomcat já vem com um Host configurado, que é justamente o raiz da aplicação, que é aquele host que está no arquivo server.xml.

< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">

< !-- UM MONTE DE COMENTÁRIO AQUI-- >

< /host >

Para configurar então o tomcat para que assim que o usuário digitar a url do seu domínio ela acesse diretamente sua aplicação, você pode apenas definir o Default Context.

< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">

< path="" docbase="aplicacao">

< /Host >

O path="" significa que será o context default, ou seja, assim que o usuário acessar o raiz de seu domínio, ele acessará a aplicação que você definiu no docBase.
Isto funciona para a maioria dos casos onde você tem apenas uma aplicação no servidor. Mas se você tiver um servidor que serve para vários domínios, você então precisará configurar Virtual Hosts, assim como era feito no Apache, quem administra servidores, sabe o que, e como fazer isso. Então, para fazer isso no Tomcat, basta você adicionar um novo Host, parecido com o do exemplo acima, porém, passando o domínio como name do host. Ex:

< name="www.meudominio2.com" appbase="/caminho/aplicacoes">
< path="" docbase="aplicacao2">
< /Host >

Agora, este novo host, você pode definir um context default ou não, isso depende da sua configuração. Caso você tenha multiplos domínios e apenas um servidor, basta ir adicionando eles a este arquivo. Lembre-se que todos os elementos Host ficam dentro do elemento Engine.

Nota importante:
Fiz alguns testes, e o tomcat se comportou de maneiras distintas em algumas versões diferentes. O que notei foi que o / tanto no appBase do Host, quanto no docBase do Context, faziam diferença. Então, caso não esteja conseguindo configurar, tente remover, ou inserir as barras tanto no início do caminho, quanto no final.

Bom, é isso, hoje não estou muito inspirado para escrever, então, eu sei que o post ficou com um português meio ruinzinho... Mas, sobretudo, espero ter ajudado alguém. Qualquer dúvida poste ai que eu tento responder.

[Update]
Para fazer isto no tomcat 6 mudou um pouquinho na parte de deixar o tomcat responder na porta 80 (primeira parte deste post). Mas não tem segredo, procure um "Connnector" no mesmo arquivo server.xml que contenha 8080, e altere para a porta 80 =) O resto continua a mesma coisa. Valeu.

JavaFX Script

Gostaria aqui de fazer um complemento sobre o meu post anterior sobre JavaFX onde falei basicamente sobre o JavaFX Mobile.

Estive no evento Falando em Java do pessoal da Caelum e teve uma excelente palestra sobre JavaFX com o Sérgio Lopes, onde ele demonstrou algumas coisas legais do JavaFX que na realidade eu não tinha visto no meu primeiro contato com ele, devido ao fato de eu estar mais focado na parte Mobile dele.
Vou relatar algumas aqui:

• Declarative Syntax
• Como era em Swing:

       var win = new Frame();
   win.title = "Hello World JavaFX";
   win.width = 200;
   var label = new Label();
   label.text = "Hello World";
   win.content = label;
   win.visible = true;

• Como é em JavaFX:
  import javafx.ui.*;
  
  Frame {
         title: "Hello World JavaFX"
         width: 200
         height: 50
         content: Label {
             text: "Hello World"
         }
         visible: true
  }

• Data Binding
• Você passa um objeto.atributo como valor de um campo e ele automáticamente atualiza este atributo de tal objeto.
  
• Facilidade de Leitura
• Facilidade de visualizar a estrutura da tela já no Código, por que fica algo bem "hierárquico" em código, e não aquela coisa bagunçada do Swing

Para obter mais informações sobre JavaFX veja o post da Caelum, veja ainda os links no final do post. Aguarde ainda os exemplos de código implementados pelo Sérgio Lopes na palestra.

Segundo o Sérgio, o JavaFX ainda está em uma versão "super-early-alpha", e NÃO DEVE ser usada em produção ainda. Mas pelo jeito haverá muito investimento nela neste e no próximo ano.

Tutorial sobre JavaFX Script
-----
Estava com este post enroscado por mais de uma semana esperando que o pessoal la da Caelum postasse sobre esta palestra =)

Eclipse 3.3

Como todos sabem o eclipse 3.3 (aka Europa) lançou a algumas semanas atrás (eu sempre atrasado) e está bem legalzinho. Com algumas firulinhas a mais e com uma carinha mais "clean" eu achei =)

Bom algumas features me chamaram a atenção:

• Começando pela página de download! (que maravilha aquilo né!?)
• Não precisa mais baixar todos os milhares de plugins básicos
  
• Integração nativa com o Mylyn (Antigo Mylar) Task-Focused Development
• Copy Qualified Name (ao menos eu acho, ou veio junto com meu workspace antigo)
• Melhoras no Refactoring e Quick-Fix
• Suporte nativo a JPA, WebService...
• Suporte para Annotation (com auto-complete =] )

Mas a melhor coisa de todas, é que eu pude usar o mesmo workspace que eu possuia, sem ter que fazer imports e todo aquele trampo de baixar projetos novamente do repositório, plugins e tudo mais. A única coisa que tive que baixar foi o plugin do Subversion (subclipse). Me parece que o eclipse adotou o Subversive como padrão para as próximas versões, não o conheço e não sei se ele realmente é bom. Ele trouxe tudo já, configurações específicas de cada projeto, "Servers", Runtimes... enfim, tudo redondinho! ;)

Ahhh, gostei desta dica do Rafael Carneiro.

Problema ao gerar Jar com suas dependencias

Bah... eu não sou nem um pouco bom para fazer esses títulos ;)

Mas é o seguinte, esses dias estava em um projeto com um colega de trabalho, e estava desenvolvendo uma aplicaçãozinha que iria ficar rodando num servidor verificando alguns erros, e interagindo com uma outra aplicação. Fizemos a app e pusemos ela rodar no servidor, maravilha!

Rodamos ela fez o que tinha que fazer e beleza. Depois fomos testar ela novamente e misteriosamente não rodava mais! Nem a que estava na minha máquina de desenvolvimento resolvou não rodar mais. Dava um monte de erro de NoClassDefFoundError e NullPointerException.

Depois de algum tempo verificamos que tinha um monte de dependencias faltando, os xalan-xerxes da vida e todas aquelas dependências. Maravilha colocamos a app rodar e foi =) Problemas resolvidos, correto?!

Errado! Começou a gerar outros erros de .properties faltando! Fui procurar no build.xml e na hora que ele fazia o unjar dos .jar de dependencias do projeto, para depois jogar tudo dentro de um jar só no final, ele tinha uma propriedade que só pegava os .class dos jars e excluia tudo o resto. Ok, retirei a linha de restrição, e tudo passou a funcionar normalmente.

Pergunta: Porque funcionou da primeira vez?!

Agora uma outra historinha. Sabe o projeto de onde copiei o build? Então, este projeto está em produção a mais de 1 ano! Exatamente (pasme). Ele foi uma das heranças dadas a mim assim que entrei na empresa.

Coincidentemente uma semana após eu ter arrumado este erro no primeiro projeto, aquele que já estava em produção pipocou! Não rodou mais, começou a dar falhas, e não fazia mais o que tinha que fazer, foi um desesperto geral ontem aqui, pq era um problema seríssimo. Fui então correr atrás da causa, e me lembrei do ocorrido na semana passada, verifiquei que alguns erros que geravam era por causa de .properties que estavam faltando no .jar do projeto que roda la no servidor.

Guardamos arquivos de logs diários, dos ultimos 3 meses, e fui verificar os logs, este erro era recorrente. Sempre aconteceu, mas resolveu que de uma hora pra outra resolveu parar. O mais estranho, é que dei um kill no processo la no servidor, e então levantei o processo novamente, e tudo voltou a funcionar normalmente.

Pergunta: "Como pode uma porra dessa bátima?!"

Alguém já passou por isso? Alguém já viu algo parecido? Eu achei estranhíssimo! Por que o negócio sempre rodou, já faz mais de 1 ano, e agora resolveu pipocar de uma hora pra outra. E era uma coisa que estava faltando que deveria afetar sempre!

Por favor, alguém tem uma explicação racional para isso?! Agradeço se puder postar aqui.
-------------
ps: vou fazer um post sobre como gerar um build.xml descompactando os .jars e colocando tudo em um .jar só. Mas eu ainda acho mais correto exportar o Classpath colocando tudo em um diretório .lib as dependências. Muito mais "seguro" =)

A re-Introduction to JavaScript

Como vi no blog do Guilherme Chapiewski (oh nomezinho difícil de escrever=] ), resolvi postar aqui também este link para um ótimo artigo sobre JavaScript.

Como JS está muito em alta hoje, ele tem grandes chances de perder a má fama que ganhou ao longo dos anos, e pra quem tem estudado e aplicado ele hoje em dia, tem se surpreendido com o seu poder, e o pensamento mais comum é: "Bah! E isso sempre existiu!"

Então pra quem é desenvolvedor web, esta é uma leitura essencialmente obrigatória.

Um link interessante ainda para dar uma olhada é o da especificação da linguagem JavaScript pela ECMA.

Valeu =)

Java e C++ Benchmark

Devido ao fato de muitos amigos c-maniacs ficarem, ainda nos dias de hoje, baseando suas opiniões sobre Java nas velhas VM's 1.3-1.4 (no melhor dos casos), resolvi escrever este post. Não, não sou eu quem farei os benchmarks, mas fiz uma simples pesquisa no google sobre "c +java +benchmark" e dei uma lida em alguns artigos que falam sobre este tema, alguns de versões um pouco mais antigas da VM e outros sobre versões mais novas (1.5+).

Sei que este assunto é muito delicado e nada é decisivo, existem muitas variantes a serem consideradas e existem muitos testes diferentes. Mas o que realmente vemos, se quisermos ver é claro, é que o Java HOJE não é mais igual aquele antigo Java 1.1 de que tantas pessoas baseiam suas opiniões.

Well "Talk is cheap. Show me the code."

Antes de mais nada, vamos lembrar que não adianta querermos comparar um C com Java, mas sim C++ com Java, e é isso que a maioria destes benchmarks faz.

Para começar, utilizo o recente post de Paul Buchheit (criador e Lead Developer do Gmail), onde o primeiro parágrafo do seu post ele diz:

"A lot of people seem to be taking this post to be the "Ultimate C vs Java shootout". It's not. Performance is a very complex topic. My only real point is this: Java (which used to be slow) has reached the class of "fast languages". For the majority of applications, speed is no longer a valid excuse for using C++ instead of Java."

Em suma, ele diz que não é sua pesquisa o ultimato neste assunto de benchmark, mas que Java hoje, está na classe das "Linguagens Performáticas" e que "Velocidade ou Performance" não é mais desculpa para usar C++ ao invés de Java.

Ainda no post de Paul Buchheit, ele ressalta, que muitos testes atualmente contam o tempo de "start up" da VM como tempo de processamento, e simplesmente o que ele fez, foi fazer a iteração 3 vezes para cada código, e isto fez com que Java, fosse um pouco mais rápido que C na segunda e na terceira iteração.

Outro site que achei interessante, e que já tinha visto a uns 2 anos atrás, é este e ele tem um gráfico (abaixo) bem legalzinho sobre o desempenho em várias coisas, e isto usando a VM 1.4.2.



Outro ótimo artigo, que recomendo a leitura, é o do J.P.Lewis and Ulrich Neumann, onde além de colocar seus resultados, ainda desmistificam algumas coisas como:

1. GC is it worse... or better?
2. Run-time Compilation
3. Why is "Java is Slow" so Popular?

Não usei mais sites, porque acho que estes 3 satisfizeram minha idéia. Apesar de que em cada link deste post, existem muitos outros links para outros artigos sobre benchmark. E algo importante a ressaltar é "Não tome por verdade apenas 1 estudo sobre benchmark".

Concluindo, este não é um post que porá fim a questão, mas ao menos tenta abrir um pouco a mente dos "bitolados". Parar no tempo não é nem um pouco bom, ainda mais na nossa área. Entretanto, este também não é um post para dizer "Larguem C++ usem Java e sejam mais felizes", existe sempre a melhor escolha, e é impossível escolher o melhor caminho numa bifurcação se você só conhece um dos caminhos.

Garota de 7 anos cria um Pet Shop usando Java

WTF?!?!

Sim, foi o que pensei ao ver a notícia no InfoBlogs, e quando clico no link, me deparo com esta foto! Hahahaha muito boa =)

Créditos ao Rafael Benevides

Funcionalidade de Thread/Timer em JavaScript

Bom, digamos que o título não está exatamente bom, mas não consegui pensar em nenhum melhor =/

Ontem estava precisando fazer um lance parecido com o "Thread.sleep(numero);", ou melhor, acho que era mais parecido com o "Timer.schedule()", porém em JavaScript, e lembrei do tal conhecido método setTimeout(). Ele funciona, de uma maneira simplificada, assim:

<>
<>
 var contador=0;
 function testeTimeout()
 {
  document.getElementById('contador').innerHTML = contador++;
  setTimeout('testeTimeout()',1000);
 }
< /script>

< onload="testeTimeout()">
 < id="contador">
 < /div>
< /body>
< /html>

O que ele faz é "agendar" a execução do método passado no primeiro parametro, depois do tempo setado (que é em milisegundos) no segundo parametro. Ou seja, no exemplo acima ele iré executar o metodo testeTimeout(), e irá "agendar" uma próxima execução deste método para daqui a 1 segundo.

Um exemplo prático do uso disso seria fazer um agendamento de processamento de método (function) javaScript, para por exemplo, ficar fazendo um pooling via ajax em um determinado Serviço publicado pelo Application Server.

Outro aspecto interessante ainda sobre essa função é:
"Ela é blocante ou não?"
A resposta para esta pergunta é NÃO. Existem 2 situações onde ela poderia bloquear:
ter mais instruções no método logo abaixo da chamada de setTimeout
chamar outro método através de um evento qualquer por intervensão do usuário por exemplo.

Segue abaixo um exemplo para comprovar os dois exemplos. O timeout agora foi setado para 10 segundos para que seja possível a interação do usuário (clicar no botão):

<>
<>
 var contador=0;
 var contador2 =0;
 function testeTimeout()
 {
  document.getElementById('contador').innerHTML = contador++;
  setTimeout('testeTimeout()',10000);
  for(i=0; i<10; i++)
  {
   contador2++;
   document.getElementById('contador2').innerHTML =
    document.getElementById('contador2').innerHTML+' '+contador2;
  }
 }

 function alerta()
 {
  document.getElementById('contador2').innerHTML = 'outra função';
  alert('teste');
 }
< /script>

< onload="testeTimeout()">
 < id="contador">
 < /div>
 < id="contador2">
 < /div>
 < type="button" value="Alerta" onclick="alerta()">
< /body>
< /html>

Concluindo, você pode, por exemplo, deixar um "serviço em background" na sua aplicação e ele não irá interferir no funcionamento geral, dentre outras inúmeras funcionalidades.

------
Pode até não ser tão grande novidade, mas agora quando precisar algo já tenho os exemplos prontos aqui (o que é uma coisa que normalmente perco) =)

Programação Orientada a Gambiarras

Uma histórinha para iniciar a semana (ao menos aqui em SP) bem gostoso...

Sei, que a maioria já ouviu falar nisso, e outras ainda não. No entanto hoje de manhã, depois de um feriado prolongado no estado de SP, em que eu passei bebendo e dormindo, me deparo com uma situação que me lembrou este fluxograma:

Sim... isso mesmo. Logo cedo um email na minha caixa, falando que uma certa funcionalidade não estava OK num dos sistemas que herdei assim que entrei na atual empresa em que trabalho. Dai pensei comigo: "Bah... se eu mexer nessa bagaça vai dar mais merda! Vai começar a pipocar tudo! E dai sim EU serei o responsável!"
Uma conclusão que eu cheguei aqui, junto com um amigo, é que está aplicação está "fundamentada sobre gravetinhos", ou seja, vc tenta colocar um gravetinho a mais para sustentar a bagaça e o começa a quebrar os gravetinhos do outro lado...
É aquelas horas que vc grita: "PQP, assim não dá, vou refazer toda essa bosta aqui!", mas teu gerente te olha de longe com aquele olhar de "4 letrinhas" NTNB (No time, No Budget). =(

Bom, Boa semana a todos!
Desejem-me sorte!

--
Já que falei de POG segue o link para referência: http://desciclo.pedia.ws/wiki/POG

Rodando mais de um Jboss na mesma máquina

Bom, hoje precisei rodar dois jboss numa mesma máquina com aplicações diferentes neles para alguns testes, apesar de no final eu ter descoberto que para as aplicações que precisava não iria dar certo, a não ser que eu modificasse o código das classes principalmente as que fazem lookup de ejb. Mas enfim, depois de pesquisa daqui, pesquisa dali, testei e funcionou, pena que não especificamente para o que eu queria, mas segue ai o que é necessário fazer:
(ressaltando que JBOSS_HOME é o diretório de instalação do Jboss, o Jboss que estou usando é o 4.0.3)

• Para mudar apenas a porta do Tomcat no JBoss, modifique o arquivo:
• JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/server.xml
• Troque a porta de 8080 para, por exemplo, 8081
• Para alterar o JBoss modifique os seguintes arquivos:
• JBOSS_HOME/server/default/conf/jboss-service.xml
• WebService - modifique a porta 8083 para, por exemplo, 18083
• Naming-Service - modifique a porta 1099 para, por exemplo, 11099
• RmiPort - modifique a porta 1098 para, por exemplo, 11098
• RMI/JRMP - modifique a porta 4444 para, por exemplo, 14444
• PooledInvoker - modifique a porta 4445 para, por exemplo, 14445

• JBOSS_HOME/server/default/deploy/jms
• ServerBindPort - modifique de 8093 para, por exemplo, 18093

Bom, esta configuração abaixo eu não tenho certeza se é necessário, mas por via das dúvidas vou colocá-la aqui:

• JBOSS_HOME/server/default/conf/jboss-minimal.xml
• Naming-Service - modifique a porta 1099 para, por exemplo, 11099
• RmiPort - modifique a porta 1098 para, por exemplo, 11098

Espero ter ajudado, qualquer comentário, ou sugestão, ou outra dica, favor postar que adiciono no post.

Valeu.

JavaFX - Killer Application?

A poucos dias foi lançado o JavaFX no JavaOne em San Francisco. Uma simples divulgação deixou toda a comunidade fervorosa, justamente pelo que promete ser o JavaFX. Agora, se ele vai ser ai é outra história.
Segundo este desenho da macro-arquitetura do JavaFX podemos ver a sua aplicação:
Será que ela será a Killer Application e solução definitiva? Ou será uma outra vergonha como o MIDP, que para interface é realmente uma vergonha?

Podemos ver seu uso em alguns demos listados na Home do Projeto. Eu achei beeem estrainho a forma como é feito isso (vide o primeiro demo). Pra mim uma maneira mais descente de se fazer, seria usando coisas que já existem hoje, principalmente para as definições de estilo, porque não usar o padrão CSS? Porque não usar algumas coisas como DIV´s? Porque não definir uma folha de estilos e você poder reusar isso? Pra que reinventar a roda? Aprender mais uma nova maneira de se fazer o que já consegue se fazer. Será que vai ser igual a programar em Swing? Cria botão, seta layout, seta posição, etc etc etc... aquela coisa massante e chata.

Uma das coisas que ainda estão no ar são: OpenLazlo e Sun com o projeto Orbit. Será que toda essa plataforma FX será utilizada em cima do lazlo? Seria legal, pois ele tem se mostrado bem portável e bem estável. Se não for usado, pra que manter então projetos paralelos?!
O que passa pela minha cabeça é que, a Sun nem sabe bem ao certo como será, mas lançou toda essa JavaFX para segurar um pouco o mercado e para que o povo não vá investindo tudo o que tem na nova MS SilverLight, Apollo, Flex, etc.

Conversando com o Erko hoje ele me mostrou várias coisas legais sobre essas tecnologias RIAs. Uma das coisas que pareceu bem bacaninha foi o tal do Flex, pois utiliza CSS por exemplo. Quem quiser saber mais sobre este tipo de assunto, aconselho a acompanhar o blog do cara, é bem rico neste conteúdo.

Bom, acho que agora é aguardar e ver que que vai rolar com tudo isso, e torcer para que seja realmente algo bom.

-----------
PS: Queria colocar mais uma opinião aqui, agora que dei uma olhada melhor no javaFX, neste Tutorial.
Eu achei Horrível a forma como codificar. Vejam este tutorial ai, e me digam o que acham... bah, se for assim, eu acho que não vai pegar muito não, tlvz até caberia dizer que já nasce morto... mass.... não sou o dono da verdade e tbm, o conhecimento que tenho sobre o javaFX é bem superficial então fica apenas como uma primeira impressão.
Até.

Como começar e como manter o foco (parte2)

Normalmente pessoas me perguntam como começar, pois se deparam com uma nuvem enorme de siglas que, vamos concordar, não são poucas. Mesmo que você pegue apenas uma tecnologia, ao exemplo de Java.

Como minha maior especialidade é Java, vou usá-la como exemplo para este post, voltando-me mais para web, sendo que é isso que está em alta hoje no mercado. Apesar de que para iniciar em programação não exista exatamente um caminho das pedras, vou tentar citar o que eu acho importante saber e em seguida como começar com java.

1. Orientação a Objetos - Precisa saber muito bem. Não se engane, aprenda mesmo, aplique, leia muito sobre o assunto, aplique, refaça, mude, modele, remodele... Hoje, creio que o pior problema de programadores, é não saber realmente OO, acham que sabem, e criam sistemas que "desmoronam" mais tarde. A hora que vc disser, eu sei OO, to "bão" no negócio, então estude novamente tudo o que havia estudado e mais. Saiba como aplicar OO a sistemas, como desenvolver sistemas OO. Com este conhecimento, você será um bom profissional, note que nem estou falando em Java até agora.
2. Design Patterns - Aquela coisa que para os iniciantes parece ser o "santo graal", não é nada de mais, são apenas formas de como se fazer as coisas, como modelar teu sistema, para que você consiga manter a qualidade e sobre tudo, eles são alguns padrões de como fazer as coisas, documentados por pessoas que passaram pelo mesmo problema, e descreveram a melhor forma de solucionar um certo problema. Lembre-se, não force o uso de um DP, mas sim, depois que você tiver a maioria deles bem estudados, e bem conceituados em sua cabeça, o seu uso será natural em seus sistemas. Note novamente que Java nem entrou ainda em seus estudos. Queria enfatizar que você irá ler muito até aqui, mas leia com atenção, não desanime porque ainda não está pondo a "mão na massa".
   
3. UML - Acho bem interessante o aprendizado de UML e seus diversos diagramas, mesmo que inicialmente você não venha a ser um Analista/Arquiteto de sistemas, mas você irá responder a um, que, deus-queira, monte um diagrama de classes, de seqüencia, ... para que você possa trabalhar "consciente" do que está fazendo. Ainda não entramos em Java.
4. Conceitos de Web - Se você irá trabalhar com Web, antes de aprender o que quer que seja, Java, .Net, Ruby, ou seja lá o que, aprenda os conceitos de Web. Como funciona, que tipo de protocolo usa, o que é um Request, Response, Session, métodos Post, Get, Head, etc. Ou seja, estude legal estes conceitos, pois muitos dos problemas que os iniciantes tem, são com estes conceitos.
5. Plataforma Java - Este estudo não precisa necessariamente vir depois de todos os anteriores, normalmente ele vem seguindo em paralelo com eles. Porém ATENÇÃO, NÃO comece a desenvolver antes de ter aprendido os 4 primeiros. Aprenda o que é a plataforma completa, como ela está dividida, e então comece a aprender a linguagem em si, sintaxe, loops, if´s, coisas básicas. Normalmente, um iniciante se perde nesta parte, pois a Plataforma Java é bem abrangente. Um direcionamento profissional seria interessante, um curso, ou mesmo algum material disponível na internet, mas procure algo bom, existe muita coisa ruim pelo mercado. Eu sempre indico o material da Caelum, é o melhor material que eu conheço. Depois de ter aprendido bem a linguagem, existe algumas coisas ainda que são importantes, como:
1. Collection API
2. JDBC
3. Thread e Sincronização
   
4. ...
   
6. Java WEB - Só então comece a aprender Java para web. Esqueça Frameworks, você não precisa deles agora, ainda não está pronto para eles. Aprenda primeiro, como é a estrutura de uma aplicação Java para Web, como fazer uma JSP, como fazer um Servlet e como fazer uma JSP e um Servlet conversarem, como fazer um Post, um Get e como trabalhar com Session. Depois, aprenda para que serve o tal arquivo web.xml e o que da pra fazer com ele, o que é um Filter, os Listeners possíveis e como aplicá-los. Tente então juntar os conhecimentos adquiridos até agora, OO, DP, UML e os Conceitos de Web com o Java e fazer um sisteminha simples para testes. Após feito e ele funcionando legalzinho, comece o mesmo sistema, de outra maneira, estudando e tentando melhorar alguns aspectos, tentando aplicar outros conhecimentos adquiridos com o primeiro projeto.

É..., não falei que iria ser fácil e que o tempo de estudo seria curto, porém, esta não é necessariamente a curva de aprendizado do Java em si. Mas sim a curva de aprendizado de um bom profissional. Não só na minha opinião, mas em todos os aspectos da vida, se uma coisa não tem uma base forte, o que for construído por cima dela, uma hora ruirá.

Enfim, esta é minha opinião hoje sobre o assunto, não sou o dono da verdade, porém hoje vejo que se tivesse seguido alguns caminhos assim, minha vida teria sido muito mais fácil =). Sei que alguns concordam, outros discordam, e ainda outros tem muitas coisas a acrescentar, mas isso foi o que me veio a cabeça em quanto estava escrevendo este post. Agradeço as opiniões.

Como começar e como manter o foco

Este post foi motivado por este post.

Manter o foco no começo é meio complicado, principalmente para aqueles que são "fuçadores", normalmente o cara sabe lidar com hardware, instalar programas, configurar, alguma coisinha de redes, alguma coisinha de programação e com isso também algumas coisas sobre Banco de Dados, o famoso "micrero". Antes de explanar sobre isso, queria deixar claro que quanto maior seu conhecimento melhor, quanto mais você conhecer melhor, pois ser extremamente especialista não é bom.

Nesta área de TI, temos muitas especialidades que requerem muito estudo para cada. Vamos citar duas, Desenvolvimento e Suporte (servidores, rede, etc). Estas duas áreas, podem ser consideradas "Macro áreas", pois dentro de cada área tem muitas subdivisões. Quando uma pessoa começa a trabalhar (quer deixar de ser micrero para virar um profissional de verdade) fica meio perdido sem saber pra que lado seguir, por isso antes de mais nada você precisa definir exatamente que lado quer seguir.
Digamos que você quer desenvolvimento. Ok, agora precisamos definir qual liguagem você irá adotar como a principal. Particularmente, acho necessário ter uma principal senão você não deixará de ser um micrero =) , porém você precisa aprender mais liguagens com certeza, para não ser uma ferramenta de uma única utilidade. Além de uma linguagem de programação, você precisará ainda interagir com banco de dados (quase que 100% das aplicações precisam). Então você acaba tendo que aprender SQL, um pouco de linguagem para escrever procedures e functions no banco de dados que você for trabalhar. Porém, é aqui que muitos desenvolvedores se perdem, muitos começam a partir para estudos aprofundados do banco de dados. Para isso existe um especialista chamado DBA. Normalmente um DBA, sabe tanto de banco de dados, como de infra-estrutura e um pouquinho de desenvolvimento. Porém não é trabalho de um desenvolvedor saber dessas coisas. (mas lembre-se do que falei antes de começar este texto.) Digamos então que você escolha Java para sua linguagem principal, você já terá muito estudo pela frente, porém, lembre-se de conhecer outras principais no mercado, como a plataforma .Net (C# de preferência), e ao menos alguma outra, uma emergente se possível, como o Ruby nos dias de hoje, ou ainda outra de sua preferência. Contudo evite aprender coisas que estão saindo de uso, principalmente no começo de sua carreira. Caso seja necessário depois, será bem mais fácil para aprender, no começo só irá confundir.
Concluindo, defina uma macro-área, especialize-se na MACRO AREA, assim que você se sentir seguro o suficiente, ou seja, estiver trabalhando com tranquilidade com isso, então parta para avançar em seus estudos. Normalmente leva-se no mínimo uns 3 anos para isso, então tenha paciência e aprenda o máximo que você conseguir, sem perder muito o foco.

Espero com este email ter ajudado um pouco, com minha pouca experiência. Pode ser que eu esteja errado, porém isso hoje me parece o mais correto. Qual sua opinião sobre o assunto?

------
devido ao primeiro post abaixo resolvi editar este post, e adicionar o link a este site:
http://mundo.it/blog/
Para mais artigos sobre esse assunto pesquisem por Carreiras, tem muita coisa legal.
Obrigado Yuri.