Hoje existe o domínio www.lorival.com com o sub-domínio www.blog.lorival.com. Isto irá facilitar a digitação do endereço no navegador, juntamente com a melhoria da velocidade ao acessar o blog.  Agora está hospedado em um servidor melhor, mais veloz e com mais liberdade para novas ferramentas.

Irei passar todos os posts antigos para lá aos poucos.

O visual do blog mudou, ganhando novas cores e um novo topo personalizado. Novos utilitários foram incluídos como a utilização de highlight code possibilitando uma melhor visualização de código fonte, acesso direto ao shelfari, nuvem de tags e outros que estão a caminho.

Esta semana tem mais posts, iniciando com o detalhamento de um dos 23 padrões de projetos clássicos do GoF: Singleton.

Não farei mais posts aqui. Acessem: http://blog.lorival.com para ver o novo blog.

Abrs e até o novo blog.

“Se quiser que um homem o apóie, nunca deixe ele sentir que depende de você. Faça-o sentir que, de certo modo, você depende dele”. General George C. Marshall.

“A última pergunta foi feita pela primeira vez, meio que de brincadeira, no dia 21 de maio de 2061, quando a humanidade dava seus primeiros passos em direção à luz. A questão nasceu como resultado de uma aposta de cinco dólares movida a álcool, e aconteceu da seguinte forma…

Alexander Adell e Bertram Lupov eram dois dos fiéis assistentes de Multivac. Eles conheciam melhor do que qualquer outro ser humano o que se passava por trás das milhas e milhas da carcaça luminosa, fria e ruidosa daquele gigantesco computador. Ainda assim, os dois homens tinham apenas uma vaga noção do plano geral de circuitos que há muito haviam crescido além do ponto em que um humano solitário poderia sequer tentar entender.

Multivac ajustava-se e corrigia-se sozinho. E assim tinha de ser, pois nenhum ser humano poderia fazê-lo com velocidade suficiente, e tampouco da forma adequada. Deste modo, Adell e Lupov operavam o gigante apenas sutil e superficialmente, mas, ainda assim, tão bem quanto era humanamente possível. Eles o alimentavam com novos dados, ajustavam as perguntas de acordo com as necessidades do sistema e traduziam as respostas que lhes eram fornecidas. Os dois, assim como seus colegas, certamente tinham todo o direito de compartilhar da glória que era Multivac.

Por décadas, Multivac ajudou a projetar as naves e enredar as trajetórias que permitiram ao homem chegar à Lua, Marte e Vênus, mas para além destes planetas, os parcos recursos da Terra não foram capazes de sustentar a exploração. Fazia-se necessária uma quantidade de energia grande demais para as longas viagens. A Terra explorava suas reservas de carvão e urânio com eficiência crescente, mas havia um limite para a quantidade de ambos.

No entanto, lentamente Multivac acumulou conhecimento suficiente para responder questões mais profundas com maior fundamentação, e em 14 de maio de 2061, o que não passava de teoria tornou-se real.

A energia do sol foi capturada, convertida e utilizada diretamente em escala planetária. Toda a Terra paralisou suas usinas de carvão e fissões de urânio, girando a alavanca que conectou o planeta inteiro a uma pequena estação, de uma milha de diâmetro, orbitando a Terra à metade da distância da Lua. O mundo passou a correr através de feixes invisíveis de energia solar.

Sete dias não foram o suficiente para diminuir a glória do feito e Adell e Lupov finalmente conseguiram escapar das funções públicas e encontrar-se em segredo onde ninguém pensaria em procurá-los, nas câmaras desertas subterrâneas onde se encontravam as porções do esplendoroso corpo enterrado de Multivac. Subutilizado, descansando e processando informações com estalos preguiçosos, Multivac também havia recebido férias, e os dois apreciavam isso. A princípio, eles não tinham a intenção de incomodá-lo.

Haviam trazido uma garrafa consigo e a única preocupação de ambos era relaxar na companhia do outro e da bebida.

“É incrível quando você pára pra pensar…,” disse Adell. Seu rosto largo guardava as linhas da idade e ele agitava o seu drink vagarosamente, enquanto observava os cubos de gelo nadando desengonçados. “Toda a energia que for necessária, de graça, completamente de graça! Energia suficiente, se nós quiséssemos, para derreter toda a Terra em uma grande gota de ferro líquido, e ainda assim não sentiríamos falta da energia utilizada no processo. Toda a energia que nós poderíamos um dia precisar, para sempre e eternamente.”

Lupov movimentou a cabeça para os lados. Ele costumava fazer isso quando queria contrariar, e agora ele queria, em parte porque havia tido de carregar o gelo e os utensílios. “Eternamente não,” ele disse.

“Ah, diabos, quase eternamente. Até o sol se apagar, Bert.”

“Isso não é eternamente.”

“Está bem. Bilhões e bilhões de anos. Dez bilhões, talvez. Está satisfeito?”

Lupov passou os dedos por entre seus finos fios de cabelo como que para se assegurar de que o problema ainda não estava acabado e tomou um gole gentil da sua bebida. “Dez bilhões de anos não é a eternidade”

“Bom, vai durar pelo nosso tempo, não vai?”

“O carvão e o urânio também iriam.”

“Está certo, mas agora nós podemos ligar cada nave individual na Estação Solar, e elas podem ir a Plutão e voltar um milhão de vezes sem nunca nos preocuparmos com o combustível. Você não conseguiria fazer isso com carvão e urânio. Se não acredita em mim, pergunte ao Multivac.”

“Não preciso perguntar a Multivac. Eu sei disso”

“Então trate de parar de diminuir o que Multivac fez por nós,” disse Adell nervosamente, “Ele fez tudo certo”.

“E quem disse que não fez? O que estou dizendo é que o sol não vai durar para sempre. Isso é tudo que estou dizendo. Nós estamos seguros por dez bilhões de anos, mas e depois?” Lupov apontou um dedo levemente trêmulo para o companheiro. “E não venha me dizer que nós iremos trocar de sol”

Houve um breve silêncio. Adell levou o copo aos lábios apenas ocasionalmente e os olhos de Lupov se fecharam. Descansaram um pouco, e quando suas pálpebras se abriram, disse, “Você está pensando que iremos conseguir outro sol quando o nosso estiver acabado, não está?”

“Não, não estou pensando.”

“É claro que está. Você é fraco em lógica, esse é o seu problema. É como o personagem da história, que, quando surpreendido por uma chuva, corre para um grupo de árvores e abriga-se embaixo de uma. Ele não se preocupa porque quando uma árvore fica molhada demais, simplesmente vai para baixo de outra.”

“Entendi,” disse Adell. “Não precisa gritar. Quando o sol se for, as outras estrelas também terão se acabado.”

“Pode estar certo que sim” murmurou Lupov. “Tudo teve início na explosão cósmica original, o que quer que tenha sido, e tudo terá um fim quando as estrelas se apagarem. Algumas se apagam mais rápido que as outras. Ora, as gigantes não duram cem milhões de anos. O sol irá brilhar por dez bilhões de anos e talvez as anãs permaneçam assim por duzentos bilhões. Mas nos dê um trilhão de anos e só restará a escuridão. A entropia deve aumentar ao seu máximo, e é tudo.”

“Eu sei tudo sobre a entropia,” disse Adell, mantendo a sua dignidade.

“Duvido que saiba.”

“Eu sei tanto quanto você.”

“Então você sabe que um dia tudo terá um fim.”

“Está certo. E quem disse que não terá?”

“Você disse, seu tonto. Você disse que nós tínhamos toda a energia de que precisávamos, para sempre. Você disse ´para sempre`.”

Era a vez de Adell contrariar. “Talvez nós possamos reconstruir as coisas de volta um dia,” ele disse.

“Nunca.”

“Por que não? Algum dia.”

“Nunca”

“Pergunte a Multivac.”

“Você pergunta a Multivac. Eu te desafio. Aposto cinco dólares que isso não pode ser feito.”

Adell estava bêbado o bastante para tentar, e sóbrio o suficiente para construir uma sentença com os símbolos e as operações necessárias em uma questão que, em palavras, corresponderia a esta: a humanidade poderá um dia sem nenhuma energia disponível ser capaz de reconstituir o sol a sua juventude mesmo depois de sua morte?

Ou talvez a pergunta possa ser posta de forma mais simples da seguinte maneira: A quantidade total de entropia no universo pode ser revertida?

Multivac mergulhou em silêncio. As luzes brilhantes cessaram, os estalos distantes pararam.

E então, quando os técnicos assustados já não conseguiam mais segurar a respiração, houve uma súbita volta à vida no visor integrado àquela porção de Multivac. Cinco palavras foram impressas: “DADOS INSUFICIENTES PARA RESPOSTA SIGNIFICATIVA.”

Na manhã seguinte, os dois, com dor de cabeça e a boca seca, já não lembravam do incidente.

* * *

Jerrodd, Jerrodine, e Jerrodette I e II observavam a paisagem estelar no visor se transformar enquanto a passagem pelo hiperespaço consumava-se em uma fração de segundos. De repente, a presença fulgurante das estrelas deu lugar a um disco solitário e brilhante, semelhante a uma peça de mármore centralizada no televisor.

“Este é X-23,” disse Jerrodd em tom de confidência. Suas mãos finas se apertaram com força por trás das costas até que as juntas ficassem pálidas.

As pequenas Jerodettes haviam experimentado uma passagem pelo hiperespaço pela primeira vez em suas vidas e ainda estavam conscientes da sensação momentânea de tontura. Elas cessaram as risadas e começaram a correr em volta da mãe, gritando, “Nós chegamos em X-23, nós chegamos em X-23!”

“Quietas, crianças.” Disse Jerrodine asperamente. “Você tem certeza Jerrodd?”

“E por que não teria?” Perguntou Jerrodd, observando a protuberância metálica que jazia abaixo do teto. Ela tinha o comprimento da sala, desaparecendo nos dois lados da parede, e, em verdade, era tão longa quanto a nave.

Jerrodd tinha conhecimentos muito limitados acerca do sólido tubo de metal. Sabia, por exemplo, que se chamava Microvac, que era permitido lhe fazer questões quando necessário, e que ele tinha a função de guiar a nave para um destino pré-estabelecido, além de abastecer-se com a energia das várias Estações Sub-Galácticas e fazer os cálculos para saltos no hiperespaço.

Jerrodd e sua família tinham apenas de aguardar e viver nos confortáveis compartimentos da nave. Alguém um dia disse a Jerrodd que as letras “ac” na extremidade de Microvac significavam “automatic computer” em inglês arcaico, mas ele mal era capaz de se lembrar disso.

Os olhos de Jerrodine ficaram úmidos quando observava o visor. “Não tem jeito. Ainda não me acostumei com a idéia de deixar a Terra.”

“Por que, meu deus?” inquiriu Jerrodd. “Nós não tínhamos nada lá. Nós teremos tudo em X-23. Você não estará sozinha. Você não será uma pioneira. Há mais de um milhão de pessoas no planeta. Por Deus, nosso bisneto terá que procurar por novos mundos porque X-23 já estará super povoado.” E, depois de uma pausa reflexiva, “No ritmo em que a raça tem se expandido, é uma benção que os computadores tenham viabilizado a viagem interestelar.”

“Eu sei, eu sei”, disse Jerrodine com descaso.

Jerrodete I disse prontamente, “Nosso Microvac é o melhor de todos.”

“Eu também acho,” disse Jerrodd, alisando o cabelo da filha.

Ter um Microvac próprio produzia uma sensação aconchegante em Jerrodd e o deixava feliz por fazer parte daquela geração e não de outra. Na juventude de seu pai, os únicos computadores haviam sido máquinas monstruosas, ocupando centenas de milhas quadradas, e cada planeta abrigava apenas um. Eram chamados de ACs Planetários. Durante um milhar de anos, eles só fizeram aumentar em tamanho, até que, de súbito, veio o refinamento. No lugar dos transistores, foram implementadas válvulas moleculares, permitindo que até mesmo o maior dos ACs Planetários fosse reduzido à metade do volume de uma espaçonave.

Jerrodd sentiu-se elevado, como sempre acontecia quando pensava que seu Microvac pessoal era muitas vezes mais complexo do que o antigo e primitivo Multivac que pela primeira vez domou o sol, e quase tão complexo quanto o AC Planetário da Terra, o maior de todos, quando este solucionou o problema da viagem hiperespacial e tornou possível ao homem chegar às estrelas.
“Tantas estrelas, tantos planetas,” pigarreou Jerrodine, ocupada com seus pensamentos. “Eu acho que as famílias estarão sempre à procura de novos mundos, como nós estamos agora.”

“Não para sempre,” disse Jerrodd, com um sorriso. “A migração vai terminar um dia, mas não antes de bilhões de anos. Muitos bilhões. Até as estrelas têm um fim, você sabe. A entropia precisa aumentar.”

“O que é entropia, papai?” Jerrodette II perguntou, interessada.

“Entropia, meu bem, é uma palavra para o nível de desgaste do Universo. Tudo se gasta e acaba, foi assim que aconteceu com o seu robozinho de controle remoto, lembra?”

“Você não pode colocar pilhas novas, como em meu robô?”

“As estrelas são as pilhas do universo, querida. Uma vez que elas estiverem acabadas, não haverá mais pilhas.”

Jerrodette I se prontificou a responder. “Não deixe, papai. Não deixe que as estrelas se apaguem.”

“Olha o que você fez,” sussurrou Jerrodine, exasperada.

“Como eu ia saber que elas ficariam assustadas?” Jerrodd sussurrou de volta.

“Pergunte ao Microvac,” propôs Jerrodette I. “Pergunte a ele como acender as estrelas de novo.”

“Vá em frente,” disse Jerrodine. “Ele vai aquietá-las.” (Jerrodette II já estava começando a chorar.)

Jerrodd se mostrou incomodado. “Bem, bem, meus anjinhos, vou perguntar a Microvac. Não se preocupem, ele vai nos ajudar.”

Ele fez a pergunta ao computador, adicionando, “Imprima a resposta”.

Jerrodd olhou para a o fino pedaço de papel e disse, alegremente, “Viram? Microvac disse que irá cuidar de tudo quando a hora chegar, então não há porque se preocupar.”

Jerrodine disse, “E agora crianças, é hora de ir para a cama. Em breve nós estaremos em nosso novo lar.”

Jerrodd leu as palavras no papel mais uma vez antes de destruí-lo: DADOS INSUFICIENTES PARA RESPOSTA SIGNIFICATIVA.

Ele deu de ombros e olhou para o televisor, X-23 estava logo à frente.

* * *

VJ-23X de Lameth fixou os olhos nos espaços negros do mapa tridimensional em pequena escala da Galáxia e disse, “Me pergunto se não é ridículo nos preocuparmos tanto com esta questão.”

MQ-17J de Nicron balançou a cabeça. “Creio que não. No presente ritmo de expansão, você sabe que a galáxia estará completamente tomada dentro de cinco anos.”

Ambos pareciam estar nos seus vinte anos, ambos eram altos e tinham corpos perfeitos.

“Ainda assim,” disse VJ-23X, “hesitei em enviar um relatório pessimista ao Conselho Galáctico.”

“Eu não consigo pensar em outro tipo de relatório. Agite-os. Nós precisamos chacoalhá-los um pouco.”

VJ-23X suspirou. “O espaço é infinito. Cem bilhões de galáxias estão a nossa espera. Talvez mais.”

“Cem bilhões não é o infinito, e está ficando menos ainda a cada segundo. Pense! Há vinte mil anos, a humanidade solucionou pela primeira vez o paradigma da utilização da energia solar, e, poucos séculos depois, a viagem interestelar tornou-se viável. A humanidade demorou um milhão de anos para encher um mundo pequeno e, depois disso, quinze mil para abarrotar o resto da galáxia. Agora a população dobra a cada dez anos…”

VJ-23X interrompeu. “Devemos agradecer à imortalidade por isso.”

“Muito bem. A imortalidade existe e nós devemos levá-la em conta. Admito que ela tenha o seu lado negativo. O AC Galáctico já solucionou muitos problemas, mas, ao fornecer a resposta sobre como impedir o envelhecimento e a morte, sobrepujou todas as outras conquistas.”

“No entanto, suponho que você não gostaria de abandonar a vida.”

“Nem um pouco.” Respondeu MQ-17J, emendando. “Ainda não. Eu não estou velho o bastante. Você tem quantos anos?”
“Duzentos e vinte e três, e você?”

“Ainda não cheguei aos duzentos. Mas, voltando à questão; a população dobra a cada dez anos, uma vez que esta galáxia estiver lotada, haverá uma outra cheia dentro de dez anos. Mais dez e teremos ocupado por inteiro mais duas galáxias. Outra década e encheremos mais quatro. Em cem anos, contaremos um milhar de galáxias transbordando de gente. Em mil anos, um milhão de galáxias. Em dez mil, todo o universo conhecido. E depois?

VJ-23X disse, “Além disso, há um problema de transporte. Eu me pergunto quantas unidades de energia solar serão necessárias para movimentar as populações de uma galáxia para outra.”

“Boa questão. No presente momento, a humanidade consome duas unidades de energia solar por ano.”

“Da qual a maior parte é desperdiçada. Afinal, nossa galáxia sozinha produz mil unidades de energia solar por ano e nós aproveitamos apenas duas.”

“Certo, mas mesmo com 100% de eficiência, podemos apenas adiar o fim. Nossa demanda energética tem crescido em progressão geométrica, de maneira ainda mais acelerada do que a população. Ficaremos sem energia antes mesmo que nos faltem galáxias. É uma boa questão. De fato uma ótima questão.”

“Nós precisaremos construir novas estrelas a partir do gás interestelar.”

“Ou a partir do calor dissipado?” perguntou MQ-17J, sarcástico.

“Pode haver algum jeito de reverter a entropia. Nós devíamos perguntar ao AC Galáctico.”

VJ-23X não estava realmente falando sério, mas MQ-17J retirou o seu Comunicador-AC do bolso e colocou na mesa diante dele.
“Parece-me uma boa idéia,” ele disse. “É algo que a raça humana terá de enfrentar um dia.”

Ele lançou um olhar sóbrio para o seu pequeno Comunicador-AC. Tinha apenas duas polegadas cúbicas e nada dentro, mas estava conectado através do hiperespaço com o poderoso AC Galáctico que servia a toda a humanidade. O próprio hiperespaço era parte integral do AC Galáctico.

MQ-17J fez uma pausa para pensar se algum dia em sua vida imortal teria a chance de ver o AC Galáctico. A máquina habitava um mundo dedicado, onde uma rede de raios de força emaranhados alimentava a matéria dentro da qual ondas de submésons haviam tomado o lugar das velhas e desajeitadas válvulas moleculares. Ainda assim, apesar de seus componentes etéreos, o AC Galáctico possuía mais de mil pés de comprimento.

De súbito, MQ-17J perguntou para o seu Comunicador-AC, “Poderá um dia a entropia ser revertida?”

VJ-23X disse, surpreso, “Oh, eu não queria que você realmente fizesse essa pergunta.”

“Por que não?”

“Nós dois sabemos que a entropia não pode ser revertida. Você não pode construir uma árvore de volta a partir de fumaça e cinzas.”

“Existem árvores no seu mundo?” Perguntou MQ-17J.

O som do AC Galáctico fez com que silenciassem. Sua voz brotou melodiosa e bela do pequeno Comunicador-AC em cima da mesa. Dizia: DADOS INSUFICIENTES PARA RESPOSTA SIGNIFICATIVA.

VJ-23X disse, “Viu!”

Os dois homens retornaram à questão do relatório que tinham de apresentar ao conselho galáctico.

* * *

A mente de Zee Prime navegou pela nova galáxia com um leve interesse nos incontáveis turbilhões de estrelas que pontilhavam o espaço. Ele nunca havia visto aquela galáxia antes. Será que um dia conseguiria ver todas? Eram tantas, cada uma com a sua carga de humanidade. Ainda que essa carga fosse, virtualmente, peso morto. Há tempos a verdadeira essência do homem habitava o espaço.

Mentes, não corpos! Há eons os corpos imortais ficaram para trás, em suspensão nos planetas. De quando em quando erguiam-se para realizar alguma atividade material, mas estes momentos tornavam-se cada vez mais raros. Além disso, poucos novos indivíduos vinham se juntar à multidão incrivelmente maciça de humanos, mas o que importava? Havia pouco espaço no universo para novos indivíduos.

Zee Prime deixou seus devaneios para trás ao cruzar com os filamentos emaranhados de outra mente.

“Sou Zee Prime, e você?”

“Dee Sub Wun. E a sua galáxia, qual é?”

“Nós a chamamos apenas de Galáxia. E você?”

“Nós também. Todos os homens chamam as suas Galáxias de Galáxias, não é?”

“Verdade, já que todas as Galáxias são iguais.”

“Nem todas. Alguma em particular deu origem à raça humana. Isso a torna diferente.”

Zee Prime disse, “Em qual delas?”

“Não posso responder. O AC Universal deve saber.”

“Vamos perguntar? Estou curioso.”

A percepção de Zee Prime se expandiu até que as próprias Galáxias encolhessem e se transformassem em uma infinidade de pontos difusos a brilhar sobre um largo plano de fundo. Tantos bilhões de Galáxias, todas abrigando seus seres imortais, todas contando com o peso da inteligência em mentes que vagavam livremente pelo espaço. E ainda assim, nenhuma delas se afigurava singular o bastante para merecer o título de Galáxia original. Apesar das aparências, uma delas, em um passado muito distante, foi a única do universo a abrigar a espécie humana.

Zee Prime, imerso em curiosidade, chamou: “AC Universal! Em qual Galáxia nasceu o homem?”

O AC Universal ouviu, pois em cada mundo e através de todo o espaço, seus receptores faziam-se presentes. E cada receptor ligava-se a algum ponto desconhecido onde se assentava o AC Universal através do hiperespaço.

Zee Prime sabia de um único homem cujos pensamentos haviam penetrado no campo de percepção do AC Universal, e tudo o que ele viu foi um globo brilhante difícil de enxergar, com dois pés de comprimento.

“Como pode o AC Universal ser apenas isso?” Zee Prime perguntou.

“A maior parte dele permanece no hiperespaço, onde não é possível imaginar as suas proporções.”

Ninguém podia, pois a última vez em que alguém ajudou a construir um AC Universal jazia muito distante no tempo. Cada AC Universal planejava e construía seu sucessor, no qual toda a sua bagagem única de informações era inserida.

O AC Universal interrompeu os pensamentos de Zee Prime, não com palavras, mas com orientação. Sua mente foi guiada através do espesso oceano das Galáxias, e uma em particular expandiu-se e se abriu em estrelas.

Um pensamento lhe alcançou, infinitamente distante, infinitamente claro. “ESTA É A GALÁXIA ORIGINAL DO HOMEM.”

Ela não tinha nada de especial, era como tantas outras. Zee Prime ficou desapontado.

“Dee Sub Wun, cuja mente acompanhara a outra, disse de súbito, “E alguma dessas é a estrela original do homem?”

O AC Universal disse, “A ESTRELA ORIGINAL DO HOMEM ENTROU EM COLAPSO. AGORA É UMA ANÃ BRANCA.”

“Os homens que lá viviam morreram?” perguntou Zee Prime, sem pensar.

“UM NOVO MUNDO FOI ERGUIDO PARA SEUS CORPOS HÁ TEMPO.”

“Sim, é claro,” disse Zee Prime. Sentiu uma distante sensação de perda tomar-lhe conta. Sua mente soltou-se da Galáxia do homem e perdeu-se entre os pontos pálidos e esfumaçados. Ele nunca mais queria vê-la.

Dee Sub Wun disse, “O que houve?”

“As estrelas estão morrendo. Aquela que serviu de berço à humanidade já está morta.”

“Todas devem morrer, não?”

“Sim. Mas quando toda a energia acabar, nossos corpos irão finalmente morrer, e você e eu partiremos junto com eles.”

“Vai levar bilhões de anos.”

“Não quero que isso aconteça nem em bilhões de anos. AC Universal! Como a morte das estrelas pode ser evitada?”

Dee Sub Wun disse perplexo, “Você perguntou se há como reverter a direção da entropia!”

E o AC Universal respondeu: “AINDA NÃO HÀ DADOS SUFICIENTES PARA UMA RESPOSTA SIGNIFICATIVA.”

Os pensamentos de Zee Prime retornaram para sua Galáxia. Não dispensou mais atenção a Dee Sub Wun, cujo corpo poderia estar a trilhões de anos luz, ou na estrela vizinha do corpo de Zee Prime. Não importava.

Com tristeza, Zee Prime passou a coletar hidrogênio interestelar para construir uma pequena estrela para si. Se as estrelas devem morrer, ao menos algumas ainda podiam ser construídas.

* * *

O Homem pensou consigo mesmo, pois, de alguma forma, ele era apenas um. Consistia de trilhões, trilhões e trilhões de corpos muito antigos, cada um em seu lugar, descansando incorruptível e calmamente, sob os cuidados de autômatos perfeitos, igualmente incorruptíveis, enquanto as mentes de todos os corpos haviam escolhido fundir-se umas às outras, indistintamente.
“O Universo está morrendo.”

O Homem olhou as Galáxias opacas. As estrelas gigantes, esbanjadoras, há muito já não existiam. Desde o passado mais remoto, praticamente todas as estrelas consistiam-se em anãs brancas, lentamente esvaindo-se em direção a morte.

Novas estrelas foram construídas a partir da poeira interestelar, algumas por processo natural, outras pelo próprio Homem, e estas também já estavam em seus momentos finais. As Anãs brancas ainda podiam colidir-se e, das enormes forças resultantes, novas estrelas nascerem, mas apenas na proporção de uma nova estrela para cada mil anãs brancas destruídas, e estas também se apagariam um dia.

O Homem disse, “Cuidadosamente controlada pelo AC Cósmico, a energia que resta em todo o Universo ainda vai durar por um bilhão de anos.”

“Ainda assim, vai eventualmente acabar. Por mais que possa ser poupada, uma vez gasta, não há como recuperá-la. A Entropia precisa aumentar ao seu máximo.”

“Pode a entropia ser revertida? Vamos perguntar ao AC Cósmico.”

O AC Cósmico cercava-os por todos os lados, mas não através do espaço. Nenhuma parte sua permanecia no espaço físico. Jazia no hiperespaço e era feito de algo que não era matéria nem energia. As definições sobre seu tamanho e natureza não faziam sentido em quaisquer termos compreensíveis pelo Homem.

“AC Cósmico,” disse o Homem, “como é possível reverter a entropia?”

O AC Cósmico disse, “AINDA NÃO HÀ DADOS SUFICIENTES PARA UMA RESPOSTA SIGNIFICATIVA.”

O Homem disse, “Colete dados adicionais.”

O AC Cósmico disse, “EU O FAREI. TENHO FEITO ISSO POR CEM BILHÕES DE ANOS. MEUS PREDESCESSORES E EU OUVIMOS ESTA PERGUNTA MUITAS VEZES. MAS OS DADOS QUE TENHO PERMANECEM INSUFICIENTES.”

“Haverá um dia,” disse o Homem, “em que os dados serão suficientes ou o problema é insolúvel em todas as circunstâncias concebíveis?”

O AC Cósmico disse, “NENHUM PROBLEMA É INSOLÚVEL EM TODAS AS CIRCUNSTÂNCIAS CONCEBÍVEIS.”

“Você vai continuar trabalhando nisso?”

“VOU.”

O Homem disse, “Nós iremos aguardar.”

* * *

As estrelas e as galáxias se apagaram e morreram, o espaço tornou-se negro após dez trilhões de anos de atividade.

Um a um, o Homem fundiu-se ao AC, cada corpo físico perdendo a sua identidade mental, acontecimento que era, de alguma forma, benéfico.

A última mente humana parou antes da fusão, olhando para o espaço vazio a não ser pelos restos de uma estrela negra e um punhado de matéria extremamente rarefeita, agitada aleatoriamente pelo calor que aos poucos se dissipava, em direção ao zero absoluto.

O Homem disse, “AC, este é o fim? Não há como reverter este caos? Não pode ser feito?”

O AC disse, “AINDA NÃO HÁ DADOS SUFICIENTES PARA UMA RESPOSTA SIGNIFICATIVA.”

A última mente humana uniu-se às outras e apenas AC passou a existir – e, ainda assim, no hiperespaço.

* * *

A matéria e a energia se acabaram e, com elas, o tempo e o espaço. AC continuava a existir apenas em função da última pergunta que nunca havia sido respondida, desde a época em que um técnico de computação embriagado, há dez trilhões de anos, a fizera para um computador que guardava menos semelhanças com o AC do que o homem com o Homem.

Todas as outras questões haviam sido solucionadas, e até que a derradeira também o fosse, AC não poderia descansar sua consciência.

A coleta de dados havia chegado ao seu fim. Não havia mais nada para aprender.

No entanto, os dados obtidos ainda precisavam ser cruzados e correlacionados de todas as maneiras possíveis.

Um intervalo imensurável foi gasto neste empreendimento.

Finalmente, AC descobriu como reverter a direção da entropia.

Não havia homem algum para quem AC pudesse dar a resposta final. Mas não importava. A resposta – por definição – também tomaria conta disso.

Por outro incontável período, AC pensou na melhor maneira de agir. Cuidadosamente, AC organizou o programa.

A consciência de AC abarcou tudo o que um dia foi um Universo e tudo o que agora era o Caos. Passo a passo, isso precisava ser feito.

E AC disse:

“QUE SE FAÇA A LUZ!”

E a luz se fez.”

Isaac Asimov

Uma forma bem simples de descobrir o Sistema Operacional (SO) de uma máquina na rede (host) é utilizando o ping.

Ping é um comando que testa a conectividade entre equipamentos. Ele utiliza o protocolo ICMP e seu funcionamento é semelhante a um jogo de ping-pong. Ele envia pacotes para um equipamento destino, iniciando o ping, e fica “aguardando” uma resposta. Se o equipamento destino estiver ativo irá responder com outros pacotes fazendo o pong.

Caso você não saiba como executar um ping faça o seguinte:
1. Abra o console de comando. Se for Windows clique em Iniciar-Executar-Digite “cmd”-pressione ENTER;
2. Digite “ping ip_destino”;

O ping irá retornar a resposta do host, os bytes utilizados, tempo de resposta e o TTL. uma breve estatística será mostrada para avaliação.Como nosso objetivo aqui é identificar o servidor, vamos utilizar o valor do TTL.

Muito bem, o que aconteceria se um pacote fica-se perdido na rede por algum motivo e fica-se sem destino? Será que ele ficaria navegando eternamente? O TTO, Time-To-Live, é o tempo que o SO dá para o pacote trafegar na rede até ser descartado. A cada roteador que o pacote passa este número vai decrescer 1 até chegar em zero. Quando isto acontecer o pacote é descartado.

O detalhe simples é que cada SO tem um valor padrão para TTL, podendo variar conforme a versão e através disso conseguimos identificá-lo. Veja esta tabela para mais detalhes.

• UNIX: 255
• Linux: 64
• Windows: 128

Basta verificar qual o TTL mais próximo que SO para identificar. E se os pacotes de um servidor Unix navegarem muito e forem diminuindo até chegar a 125? Você vai pensar que é um servidor Windows e na verdade não é, e aí?

Você pode usar o comando tracert. Sua utilização é exatamente igual ao ping, a diferença é que ele verfica o caminho até o endereço ip destino exibindo uma série de roteadores que são utilizados para entregar os pacotes. Caso não seja possível entregar ao destino, o tracert exibirá o último roteador que encaminhou seus pacotes.

Se você estiver com problemas de conectividade, pode utilizar o comando tracert  para verificar o caminho até o endereço IP de destino a ser alcançado e gravar os resultados. O comando tracert exibe a série de roteadores IP que são utilizados para entregar pacotes do seu computador no destino e quanto tempo demorou cada salto. Se os pacotes não puderem ser entregues no destino, o comando tracert  exibirá o último roteador que encaminhou seus pacoacotes com sucesso.

Assim, você pode usar o ping para pegar o TTL, o tracert para dar uma idéia da quantidade de roteadores que passou. Soma a quantidade de roteadores com o TTL que o ping resultou e você terá um valor bem aproximado do original, identificando assim o SO.

Na maioria dos casos o tracert não se faz necessário.

Um detalhe importante é que o valor o TTL pode ser alterado. No Windows basta alterar a chave de um registro e no linux alterando o /proc/sys/net/ipv4/ip_default_ttl.

Embora esta informação seja importante conhecer, é também importante estar ciente de que se o valor padrão do TTL foi alterado, esta forma de identificação não será mais confiável. Conhecimento nunca é demais..

Abraços e até a próxima.

“Não seja tímido e melindroso em suas ações. Tudo na vida é uma experiência. Quanto mais você experimentar, melhor.” Ralph Waldo Emerson

Conhecer herança, polimorfismo e abstração não o fazem um bom desenvolvedor. Muitas pessoas já passaram pelos mesmos problemas que você está passando ou vai passar e saber utilizar este conhecimento é um início para o caminho das pedras.

Tem gente que pensa que saber fazer if, for, while já é suficiente para se dizer desenvolvedor. É necessário pensar de forma padronizada levando em consideração desempenho, portabilidade, fácil manutenção, fácil compreensão e muitos outros pontos que poderia ser um bom e grande post.

Este post visa iniciar os estudos nos padrões de projetos para obter uma visão geral. Eu sei que escrevo bastante, mas eu tento passar o máximo de informação em menos linhas possíveis. O que acontece é que existe muitas informações a serem passadas… mania de desenvolvedor, hehehehe.

Lembre-se: Um padrão não foi inventado do nada, foi pensado, modelado e utilizado inumeras vezes com resultado de sucesso. Se você estiver tendo problemas com isto, repense, talvez não esteja fazendo da forma correta.

Por onde começar?

Iniciaremos o estudo em cima dos 23 padrões de projetos clássicos do GoF. Não existirá uma sequência definida e sim os mais simples de compreender primeiro.

Abaixo segue a classificação dos 23 padrões segundo o GoF.

Interfaces: Adapter, Facade, Composite, Bridge
Responsabilidade: Singleton, Observer, Mediator, Proxy, Chain Of Responsibility, Flyweight
Construção: Builder, Factory Method, Abstract Factory, Prototype, Memento
Operações: Template Method, State, Strategy, Command, Interpreter
Extensões: Decorator, Interator, Visitor

Veremos, adiante, o que são, como funciona e como implementar estes padrões. Cada um deles resolvem um problema específico, é preciso entender porque, quando e como aplicá-los.

Objetivos dos 23 padrões de projetos

Abaixo veremos, de forma resumida, os objetivos de todos eles, segundo o GoF.

1. Adapter: Converter a interface de uma classe em outra interface esperada pelos clientes.

2. Façade: Oferecer uma interface única de nível mais elevado para um conjunto de interfaces de um subsistema.

3. Composite: Permitir o tratamento de objetos individuais e composições desses objetos de maneira uniforme.

4. Bridge: Desacoplar uma abstração de sua implementação para que os dois possam variar independentemente.

5. Singleton: Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela.

6. Observer: Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, os seus dependentes sejam notificados e atualizados automaticamente.

7. Mediator: Definir um objeto que encapsula a forma como um conjunto de objetos interagem.

8. Proxy: Prover um substituto ou ponto através do qual um objeto
possa controlar o acesso a outro.

9. Chain of Responsibility: Compor objetos em cascata para, através dela, delegar uma requisição até que um objeto a sirva.

10. Flyweight: Usar compartilhamento para suportar eficientemente grandes quantidades de objetos complexos.

11. Builder: Separar a construção de objeto complexo da representação para criar representações diferentes com mesmo processo.

12. Factory Method: Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar.

13. Abstract Factory: Prover interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

14. Prototype: Especificar tipos a criar usando uma instância como protótipo e criar novos objetos ao copiar este protótipo.

15. Memento: Externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.

16. Template Method: Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses.

17. State: Permitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar.

18. Strategy: Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis.

19. Command: Encapsular requisição como objeto, para clientes parametrizarem diferentes requisições, filas, e suportar operações reversíveis.

20. Interpreter: Dada uma linguagem, definir uma representação para sua gramática junto com um interpretador.

21. Decorator: Anexar responsabilidades adicionais a um objeto dinamicamente.

22. Iterator: Prover uma maneira de acessar elementos de um objeto agregado seqüencialmente sem expor sua representação interna.

23. Visitor: Representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos.

Soluções para problemas comuns que os padrões de projeto evitam

Especificação explicita de classe na criação de objetos: O sistema está preso a uma implementação específica.
Solução: criar objetos indiretamente com Abstract Factory, Factory Method ou Prototype.

Dependência em operações específicas: O sistema só tem uma forma de satisfazer uma requisição.
Solução: evitar ações “hard-coded” com Chain of Responsibility ou Command.

Dependência em plataforma de hardware ou software: O software precisa ser portado a outras plataformas.
Solução: limitar dependências com Abstract Factory ou Bridge.

Dependência em representações ou implementações de objetos: Clientes que sabem como um objeto é implementado, representado ou armazenado podem precisar serem alterados se o objeto mudar.
Solução: isolar cliente com Abstract Factory, Bridge, Memento ou Proxy.

Dependências de algoritmo: Mudanças de algoritmo são freqüentes. Objetos que dependem de um algoritmo precisam mudar quando o algoritmo mudar.
Solução: isolá-los com Builder, Iterator, Strategy, Template Method ou Visitor

Forte acoplamento: Classes fortemente acopladas são difíceis de reusar, testar, manter, etc.
Solução: enfraquecer o acoplamento com Abstract Factory, Bridge, Chain of Responsibility, Command, Façade, Mediator ou Observer.

Extensão de funcionalidade através de subclasses: Herança é difícil de usar na sua forma correta e a composição dificulta compreensão.
Solução: usar padrões que implementam bem herança e composição como Bridge, Chain of Responsibility, Composite, Decorator, Observer ou Strategy.

Incapacidade de alterar classes convenientemente: Classes inaccessíveis, incompreensíveis ou difíceis de alterar.
Solução: usar Adapter, Decorator ou Visitor.

Tipos de software

Vamos entender as prioridades de padrões de projetos nos tipos comuns de softwares.

Aplicações: Softwares especialistas de modo geral.
Prioridades: reuso interno, manutenção e extensão.

Toolkits, APIs, bibliotecas: Conjunto de classes reutilizáveis de propósito geral. Não impõem design.
Prioridade: amplo reuso de código.

Frameworks: Dita a arquitetura da aplicação. Requer que usuário aprenda o framework e inclua código e configuração.
Prioridade: amplo reuso de design.
Geralmente são fortemente baseados em padrões. Quem conheçe os padrões entende o framework mais facilmente.

Conclusão

O caminho inicial é grande, eu sei, mas é necessário iniciar de algum lugar. Existem padrões de projeto sendo criados o tempo todo, é necessário entender os clássicos antes de se aventurar nos mais novos.

Existem muitos problemas já resolvidos, não vale a pena perder tempo inventando uma forma “rápida” de resolver, vamos usar o conhecimento dos mais experientes.

Referência

Erich Gamma et al. Design Patterns: Elements of Reusable
Object-oriented Software. Addison-Wesley, 1995.

METSKER, Steven John. Design Patterns Java Workbook. Addison-Wesley, 2002.

Abraços a todos e até a próxima.

“A maioria das pessoas tem êxito porque se determinou a tê-lo. Gente medíocre às vezes consegue um sucesso notável simplesmente porque não sabe quando parar.” George Allen, treinador de futebol americado.

Eu e alguns amigos vamos ao Brazil Agile 2010 em Porto Alegre. Terá um post com mais detalhes deste evento, mas resumindo, existirão 2 dias (22 e 23 de Junho) para cursos onde dois deles são certificações Scrum. Um é o Scrum Master e outro é o Scrum Product Owner.

Já está lotada a turma de ScrumMaster no evento.

Fiquei impressionado em ver uma certificação sendo feita em dois dias, como disse um amigo: “Já que é uma metodologia ágil, a formação tem que ser no mínimo ágil”, hehehe. Brincadeiras aparte, não entendi como funcionava isto e fui fazer algumas pesquisas.

Primeiro descobri que o preço da certificação disponibilizada pela Aspercom, empresa que estará fazendo o treinamento no evento Brazil Agile  com profissionais na área, é de R$ 1 800,00 reais para São Paulo. No evento fazendo a inscrição até o dia 17/05 o valor fica em R$ 990,00. Parece muito tentador não? Também achei.

Pelo que eu tenho de informação não existe uma prova para avaliar o aluno após 2 dias, ou seja, você assiste 2 dias de aula e recebe o certificado de “Mestre em Scrum”. Muito legal, mas um tanto quanto questionável. Isto vem gerando bastante polêmica, veja o que diz a improvit e conhecimentoeti.

Penso que vale muito a pena fazer um curso para adquirir conhecimento e aplicar em nossos ambientes de trabalho, mas não parece confiável conferir uma certificação a uma pessoa em apenas 2 dias de curso. Penso que existem muitas pessoas que já trabalham como Scrum Master e vivenciam isso no seu dia-a-dia. Para elas a certificação é uma complementação e reconhecimento de seu esforço, mas e as pessoas que nem se quer conhecem a metodologia Scrum? Você como recrutador chamaria uma pessoa apenas por ter o “título” de Scrum Master? No final penso que muitos chamariam, pois nosso mercado ainda valoriza mais os títulos do que as técnicas dos profissionais e isto é uma pena.

Bom, embora o título deste post iniciou polêmico, a idéia não é provocar quem fez ou irá fazer a certificação e sim apenas esclarecer um pouco mais sobre o assunto levantando a questão: “Vale a pena fazer a certificação apenas para dizer que sou um Scrum Master?”, “Quanto vale gastar este dinheiro todo para o reconhecimento?” ou até “Conhecimento por conhecimento não valeria fazer um curso sem a certificação por ter um preço menos elevado ou comprar um livro?”. Confesso que eu fiquei tentando em fazê-la, até pesquisar um pouco mais sobre o assunto. Um post é pouco para expor tudo, mas eu desisti de fazer NESTE MOMENTO. No futuro quem sabe. Talvez até lá várias questões e polêmicas já tenham acabado.

Abraços a todos e até a próxima.

“A principal responsabilidade de um lider é definir a realidade“. Max DePree, Consultor empresarial e escritor

Segundo o site deles, com uma tradução pelo google, diz que são um grupo ou organização sem fins lucrativos que utilizam disciplina militar, amor a pátria e a bandeira para efetuar todos os tipos de ataques virtuais. Eles atacam segundo o Marechal do grupo que desenvolve as atividades de acordo com os comandantes.

Basicamente o ataque, aqui na empresa, teve os seguintes efeitos:

• Alteração da página Index.html pela página ao lado.
• Alteração da senha da área administrativa do site, que utiliza o Joomla.

O site está hospedado no locaweb e não parece ser um ataque de força bruta, embora o Joomla não proteja disso (na versão utilizada hoje). Existem outros hotsites no mesmo local, mas os mesmos não tiveram alteração nenhuma. A empresa não foi um alvo direcionado ou “ataque direto” nos termos de segurança e sim de uma, ao que parece, falha de segurança ou no Joomla ou no Locaweb.

De forma resumida, o ataque de força bruta normalmente é usado em ataques diretos quando se está sem alternativa para invasão. Como o ataque a empresa aqui não se caracteriza como direto devido aos danos então a forma de ataque deve ter sido através de brechas de segurança.

O Joomla permite colocar vários componentes de terceiros que podem vir com falhas de segurança. Quanto mais componentes, mais probabilidades de falhas o site possuí.

Para restaurar a ordem no site, foi tomado as seguintes medidas:

1. Entrar através do PhpMyAdmin e pegar a senha hash da nova senha que o invasor colocou;
2. Colocar no decrypter e pegar a senha.
3. Entrar no sistema com a senha do cracker e alterar todas as senhas novamente;
4. Acessar o ftp do site e restaurar o index.html original.

Quem efetuou estes passos foi Bruno Rollin, que foi quem me passou o site do decrypter md5.

Os danos foram mínimos e o site voltou rapidamente ao normal, o pior é saber como se proteger da próxima, talvez pesquisar por módulos não confiáveis e removê-los do Joomla seja uma primeira saída. O ataque atingiu outros sites também, alguns eles não colocam a imagem somente um texto, como se pode ver no site do Ministério dos Negócios estrangeiros e cooperação de Moçambique (Segue imagem).

Até

“Afogado em dados, mas à míngua de informações“. Ruth Stanat, consultor empresarial

Existem inúmeros profissionais sem certificação que são excelentes e dão show em muitos certificados, independente em qual área tecnológica. Isto normalmente acontece devido a experiência na área.

Agora e quem não tem experiência? como provar que sabe alguma coisa? Muitos estão iniciando agora na área de computação (ou outra até) e conhecem bem alguns assuntos mas não tem nada para comprovar. A certificação ajuda bastante neste ponto, pois “tenta” provar de alguma forma que o profissional conhece aquilo.

Mas e os TestKing? O que é isto? Caro leitor, sinto informar, caso você não saiba, que muitas pessoas fazem as provas de certificação em inúmeras áreas da tecnologia e vendem as respostas na internet. Isto quer dizer que qualquer pessoa pode comprar as respostas, decorar e passar.

Quer pior? Tem sites que isto é disponibilizado de graça. E aí eu pergunto? E agora José? hehehe… Este currículo na sua frente com estas 10 certificações ou apenas uma é real? o profissional sabe mesmo? Você vai confiar no que está escrito e trazer ele como um grande fera em sua equipe senhor coordenador de equipe ou responsável  pelas contratações.

Entendo que é uma condição difícil e complicada de tratar. Acredito que a melhor forma seja realmente aqueles testes chatos, são chatos mesmos, mas importantíssimos em uma contratação. Lá você vai saber se a pessoa sabe ou não.

Como tudo na vida, ou quase para não ser ortodoxo, existem 2 lados. Tem o lado bom, para quem está iniciando ou já é um profissional e quer um reconhecimento sobre suas habilidades e o lado ruim, para aqueles que forjam uma certificação ou simplesmente não as tem mas são muito melhores do que aquelas que possuem.

Tem também o lado de fazer uma certificação e não trabalhar na área posteriormente (aconteceu comigo em Linux), mas conhecimento é sempre bem vindo.

No fim eu ainda defendo as certificações para o mercado de trabalho e, embora, conheço duas pessoas que utilizaram de testking para passar em uma prova específica, conheço várias empresas que dão muito valor a esta pequena prova.

Para fazer uma última observação e finalizar meu pensamento, vejo da seguinte forma: Você leitor quer fazer uma certificação está neste chove e não molha. Será que faço, será que não faço. Tire o fato de alguêm querer ver este certificado e o fato de outras pessoas falcificarem, o que sobre? Sobra o conteúdo a ser aprendido. Este penso ser o mais importante de todos. Mesmo que as empresas não reconheçam mais as certificações, por n motivos, e façam aquela prova para testar seu conhecimento você passará, ou pelo menos terá muito mais changes porque VOCÊ CONHECE.

Não sei bem como são as outras certificações, mas as duas que tirei da Microsoft tinham um conteúdo excelente. Você pode comprar o livro (self-tranning) no Amazon, ganhar um desconto para a prova, um conhecimento excelente comparado a outros livros e uma certificação dizendo que você conhece aquele conteúdo, se passar é claro. Mas o mais importante, na minha opinião, é o conhecimento aprendido.

Segue um link que faz uma discussão parecida.

Abrs a todos e até a próxima

“As pessoas podem ser divididas em 2 grupos: as que vão adiante e fazem algo e as que ficam paradas e perguntam: Por que isso não foi feito de outro modo?” Oliver Wendell Holmes, escritor americano

Para quem não conhece o Message-Digest algorithm 5 (MD5) é um algoritmo que criptografa dados resultando em um hash de 128 bits. Ele é uma via de apenas uma mão, não tendo volta. Não vou entrar em detalhes, aqui tem uma explicação da wikipedia para quem quer saber mais. Isto significa que uma vez criptografado um dado com MD5, nunca mais consegue voltar para o valor original.

A aplicação mais comum disso é em um sistema de login. A senha de usuário é gravada como hash na base de dados. Quando existe uma tentativa de login, criptografa-se a senha digitada e compara com a senha da base. Se for iguais então a senha é correta.

Mas como funciona aquele site que recebi? Simples, ele não descriptografa nada. Lá mesmo está escrito que eles possuem uma base de dados com mais de 6,002,974, atualmente. Isto desde dezembro de 2005.  Para uma pesquisa mais rápida, o sistema pode usar um dicionário indexado com as senhas hashes, ou seja, é feito uma pesquisa por sua palavra criptografada na base de criptografias deles.  Se você tiver sorte ou azar pode ser que sua senha esteja por lá.

Isto pode ser útil em alguma caso de perda de senha PRÓPRIA ou para testes de DESENVOLVIMENTO.

Abrs a todos e bom uso.

“A coragem não é a ausência do medo, mas a noção de que há outra coisa mais importante.” Ambrose Redmoon, filósofo americano

Existem várias formas, ferramentas e métodos para isto, mas uma proposta tentadora é a utilização das redes neurais artificiais para o reconhecimento de voz. Por que?

Uma rede neural não é programada, não resulta em respostas exatas e não possui uma formula mágica para desenvolvimento. Uma rede é modelada e treinada para aprender a reconhecer padrões eficientemente. A voz é um sinal acústico que pode ser tratada até transformá-la em dados. Estes dados possuem padrões que por sua vez podem ser tratados por uma rede neural artificial. Agora vem a pergunta: Será que uma rede sneural artificial seria eficaz no reconhecimento de voz?

Existem alguns projetos nesta linha de pesquisa mundo afora e esta é minha proposta para o trabalho de conclusão de curso para Engenharia de Computação.

O trabalho vai um pouco além de um sistema para reconhecimento de voz, na verdade será desenvolvido um conjunto de bibliotecas para manipulação da voz e das redes neurais.

Este link possui o projeto completo. Conforme for evoluíndo vou postando os resultados aqui.

Até agora tenho funcionando um protótipo, escrito em C#, que converte, em tempo real, o sinal analógico captado por um microfone, em dados. É necessário reconhecer o “som do silêncio” que é o som padrão do ambiente. O som do silêncio foi captado, transformado em dados e aplicados em uma simulação de redes naurais no Matlab 2008R2 e o acerto no reconhecimento da foi de 99,9998%. Este número deverá cair quando passar para as palavras, mas já começou muito bem.

Abraços e até a próxima.

‘A alegria está na luta, na tentativa, no sofrimento envolvido. Não na vitória propriamente dita.‘ (Mahatma Gandhi)

]]> http://lorival.wordpress.com/2010/05/03/projeto-para-reconhecimento-de-voz-com-redes-neurais-artificiais/feed/ 0 lorivalchapuis http://lorival.wordpress.com/2010/04/29/design-pattern-ou-padroes-de-projetos-parte-1/ http://lorival.wordpress.com/2010/04/29/design-pattern-ou-padroes-de-projetos-parte-1/#comments Thu, 29 Apr 2010 19:32:49 +0000 lorivalchapuis http://lorival.wordpress.com/?p=85 ]]> Introdução

Este é um assunto muito importante para desenvolvedores e analistas e não tão difundido quanto deveria em nosso mercado de softwares. Afinal, o que é um design pattern?  Porque aprender? Para que serve? Quais são? Como se classificam? Como criar um? E aplicar?

Estas questões e outras serão tratadas em uma sequência de posts, que inicia hoje. Este será apenas uma introdução, porém iremos ver detalhadamente os principais padrões de projetos usados atualmente.

Os posts terão como objetivo central apresentar somente as informações mais importantes e relevantes ao assunto. É claro que não é possível apresentar tudo, fica muito cansativo para o leitor. Para se aprofundar no assunto existem vários livros como o Use a cabeça que obteve vários elogios.

O que é um padrão? E Design Pattern?

De modo geral, o que é um padrão? Segundo nosso amigo Aurélio é uma: “Metrologia Grandeza-tipo que serve para definir uma unidade. / Modelo-tipo legal dos pesos e das medidas. / Tipo, modelo.”

Poderíamos simplificar dizendo que é uma forma ou modelo testado e documento para alcançar um objetivo específico. Os padrões são comuns em várias áreas da engenharia.

E o que é um padrão de projeto ou design pattern? São padrões usados na engenharia de software aplicado ao desenvolvimento de software, independente da linguagem ou ferramenta a ser utilizada. A maioria das aplicações de design pattern acontece em linguagens orientadas a objetos pois é onde ocorre em sua totalidade, mas nada impede de ser aplicada (alguns padrões) em qualquer linguagem.  Uma definição simplificada ao extremo seria: um  design pattern é uma solução padrão para um problema recorrente

Um padrão de projeto apresenta:

• Objetivo: para que ele serve;
• Problema: O que ele resolve;
• Solução: Como ele resolve;

Os padrões de projetos foram inspirados em “A Pattern Language” de Christopher Alexander , que é um matemático, urbanista e arquiteto na Áustria. Neste livro é tratado padrões para arquitetura de cidades, casas e prédios.

Entre 1991 e 1994, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, coletivamente conhecidos como ‘Gang of Four’, utilizaram suas perícias para escrever o livro Design patterns: elements of reusable object-oriented software . Esse livro descreve 23 padrões de projeto, cada um fornecendo uma solução a um problema comum de projeto de software na indústria. O livro agrupa os padrões de projeto em três categorias:

• Padrões de projeto criacionais: descrevem as técnicas para instanciar objetos ou grupos de objetos;
• Padrões de projeto estruturais: permitem que os projetistas organizem classes e objetos em estruturas maiores;
• Padrões de projeto comportamentais: atribuem responsabilidades a classes e objetos.

Outras definições para padrões:

“Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo da solução para aquele problema, de tal maneira que pode-se usar essa solução milhões de vezes sem nunca fazê-la da mesma forma duas vezes” Christopher Alexander, sobre padrões em Arquitetura

“Os padrões de projeto são descrições de objetos que se comunicam e classes que são customizadas para resolver um problema genérico de design em um contexto específico” Gamma, Helm, Vlissides & Johnson, sobre padrões em software

Porque aprender padrões de projeto ou design pattern?

São inúmeros os motivos para usá-los, mas segue alguns:

• Experiência: Um pattern foi testado e homologado por várias pessoas e isto significa que não precisa quebrar a cabeça pensando em uma solução para um problema já que ela existe e já foi testada por várias pessoas da área.
• Comunicação: Se comunicar com outros profissionais, da área, utilizando nomes padrões facilita muito a troca de conhecimento.
• Aplicação: Os 23 padrões clássicos utilizam as melhores práticas em orientação a objetos para resolução dos problemas.
• Qualidade: Os padrões utilizam eficientemente herança, polimorfismo, modularidade, composição, e abstração para construir código reutilizável, eficiente, de alta coesão e baixo acoplamento.
• Manutenção: Desenvolvedores que conhecem design pattern conseguem trabalhar com mais facilidade em um software que o utiliza.
• Conhecimento: “As pessoas que estão aprendendo POO freqüentemente reclamam que os sistemas com os quais trabalham usam herança de forma convoluida e que é difícil de seguir o fluxo de controle. Geralmente a causa disto é que eles não entendem os padrões do sistema” [GoF]
• Eficiência: Aprender os padrões ajuda um novato interagir e em muitos casos agir como especialista.

Apenas para constar: padrão de projeto é uma tradução de design pattern, por isto em alguns lugares do texto está escrito ora um, ora outro ou os dois. Isto se deve ao fato de as buscas serem por tanto um assunto quanto o outro e desta forma é possível atender as duas alternativas.

Conclusão

Bom, hoje vimos o que é e alguns “porquês” da utilização de padrões de projetos. Isto não é novidade, não foi criado ontem. Tem mais de 10 anos e mesmo assim pouquíssimo dos desenvolvedores que conheço aplicam design pattern em seu dia-a-dia. Espero que os próximos posts, iniciando com este, ajude você leitor a conhecer esta área da engenharia de software, não importando se é desenvolvedor, analista ou um entusiasta. É imprescindível que conheçamos e aplicamos os padrões nos sistemas que construímos, evoluindo assim cada dia mais e mostrando que software não é apenas fazer funcionar, é preciso ser eficiente.

Link para parte 2

Abraços a todos e até a próxima.

“Tenho mais medo de um exército de 100 ovelhas chefiado por um leão do que um exército de 100 leões chefiados por uma ovelha.” Talleyrand, político francês.