Controle de versão: Introdução II

Se você ainda não leu a primeira parte sugiro que confira o post “Controle de versão: Introdução I” antes de continuar.

Agora que sabemos o que é um branch e como funcionam, podemos seguir um pouco mais e aprendermos a padronização da estrutura de diretórios do controle de versões.

Oficialmente é recomendado que cada projeto seja criado em um repositório exclusivo, para que ele possa evoluir sem interferir nos demais projetos.

Em cada repositório, devem-se criar três pastas, segundo a recomendação oficial:

• trunk
• branches
• tags

Cada pasta tem uma finalidade muito específica e vamos abordar duas hoje (não vamos abordar a tags porque existirá um post apenas para isto).

Inicialmente, vamos para a trunk que é a mais prática de se aprender, justamente por ser a mais comum de se trabalhar.

No diretório trunk estará, de forma simplificada, o código mais recente do projeto. Sim, é pura e simplesmente isto.

Será nesta pasta que os seus programadores irão fazer o checkin do código que foi recentemente alterado, e será dela que o último código deverá ser obtido (geral).

No entanto, imaginem o que aconteceria se um ou mais funcionários receberam a tarefa de criar uma alteração grande. Por exemplo, migrar o sistema inteiro de arquivo de dados (exemplo: TXT ou algo do tipo, mesmo que mais evoluído) para um SGBD.

Se eles submeterem as alterações ali constantemente, pode acabar gerando várias falhas em clientes ou repassar código não-final para outros programadores.

A primeira solução seria uma gambiarra, mas é proposta pelo próprio tutorial do Subversion: os programadores se isolarem (nao realizarem checkin). Pulando alguns problemas que eles levantam, vamos diretamente para dois pontos críticos:

1. O computador deles geralmente é mais suceptível a falhas que o servidor, ou seja, o risco de se danificar o código e perder todo o trabalho será elevado.
2. Se alguma outra alteração for realizada no sistema no período em que eles não realizaram contato com o sistema CVS a versão deles se tornará defasada e na hora final de checkin pode gerar imprevistos, como incompatibilidade entre métodos que foram alterados durante este tempo.

É nesta hora que chega o segundo diretório de hoje, o branches.

Nele será criada uma nova versão do projeto, isolada, para cada programador que estiver fazendo uma modificação maior e que não queira afetar os demais programadores, pelo momento. Assim ele pode acompanhar a evolução do sistema (pois está realizando checkin/checkout do código-fonte normalmente), terá menos chance de perder ou danificar o código, evitará imprevistos de última hora durante o processo de merge do código alterado.

De fato, o diretório branches contém muito mais que isto. 

Um exemplo é uma boa-prática realizada por alguns projetos onde a versão testada e estável está em branches/stable. Assim, o diretório trunk conterá o código mais recente, porém, ainda não totalmente testado. Assim que testado e que a qualidade seja comprovada, ele migra para o branches/stable.

Versões personalizadas de cada cliente podem compor um ramo mais complexo, surgindo em branches/projeto_1 por exemplo, e contendo a estrutura trunk/branches subordinada ao mesmo.

Controle de versão: Introdução I

Pessoal, depois de meu sumiço, finalmente estou de volta. A falta de tempo, cansaço excessivo e preguiça acumulada me deixaram inativo aqui por algum tempo. Agora estou realmente de volta à ativa e continuando com o blog diariamente.

Dando continuidade à série que se iniciou no post anterior (Controle de versão), agora vamos aprender alguns conceitos sobre o controle de versão.

O guia será montado de forma bem devagar porque é importante que vocês entendam como funciona perfeitamente bem o CVS (controle de versão) ou, caso contrário, poderão causar falhas no programa que estiverem utilizando ou até mesmo perder suas alterações no código.

Primeiramente, vamos supor uma árvore. No tronco, a parte principal da árvore. A partir do tronco surgem os galhos primários, destes, os galhos secundários, e assim por diante.

No sistema de controle de versões, as versões são criadas de forma bem parecida.

Quando você submete (checkin) de um código ele gera uma nova versão que irá atualizar o repositório (local onde está a versão que se está trabalhando). Seguindo a analogia, coonsidere que estamos trabalhando com a versão principal (tronco). Ao realizar o checkin, o tronco se expande (sobe), crescendo.

No entanto, vamos supor que um cliente solicita uma determinada alteração, totalmente específica para ele. Não compensaria, portanto, alterar o sistema por completo, já que os outros usuários não vão querer a modificação específica. Nesta caso, criamos uma versão exclusiva, um galho separado (na analogia), que se chama BRANCH.

No controle de versão cada um dos “galhos” recebe o nome de Branch. É possível se ter, como na árvore, inúmeros branches e deles, criar-se outros branches, e assim por diante.

Voltando ao exemplo, criaríamos um branch baseado no branch original, e, a partir de então, este branch seguiria seu próprio caminho, evoluindo de acordo com alterações feitas nele.

No entanto, suponhamos um BUG detectado em uma determinada parte do programa comum a todos os usuários inclusive este com a versão diferenciada. Não vou explicar ainda COMO realizar isto mas já adianto que é possível replicar uma determinada alteração nos branches-filhos, o que facilitaria muito nosso trabalho.

A figura abaixo (terceira figura do blog *-*) ilustra o nosso exemplo:

           

Créditos: Anderson Luiz Mendes Matos, 2009. Título: Branches CVS.

Esta imagem pode ser livremente reproduzida mas não alterada.

 

Se repararem, o branch principal e o secundário estão no presente (ponta da seta) separados entre si, funcionando como que completamente isolados. No entanto, eles compartilham partes em comum, que pode ser vista na hora em que o branch secundário se separa do primário.

Repetindo as palavras do próprio SVN, “não se preocupe com o crescimento do repositório pois não são criadas cópias físicas dos arquivos. o sistema armazena apenas a cópia original e as diferenças (alterações, DIFF) que esta cópia sofreu, eviando repetição desnecessária. Na hora de realizar checkout é feita a comparação e a partir da diferença armazenada é gerada a versão final do arquivo, correspondente à última versão de checkin.”.

Não vou prolongar o post por hoje, basta que vocês tenham em mente que no controle de versões são criados os branches e deles, surge o que será controlado. Estes branches (primários) podem dar origem a outros (secundários), e assim indefinidamente, para atender as necessidades específicas de cada ambiente.

Também é importante lembrar que é possível “matar” um branch, voltando ele como parte do código original (merge), e vice-versa. Isso permite espalhar atualizações de código, alterações ou modificações mais profundas.

Controle de versão: histórico dos arquivos

Já tiveram um sério problema de saber o que mudou na alteração que o funcionário Asdrúbal de Oliveira fez na semana passada? E o que os demais fizeram, também na mesma data?

E aquele probleminha incômodo de duas pessoas alterando um mesmo código?

Bom pessoal, estes e vários outros problemas são cotidianos e precisam ser corrigidos se a empresa tem a perspectiva de crescimento. Isto é fato. Mas como fazer?

Subversion é um programa complexo, antigo e extremamente funcional. É, hoje, sem sombra de dúvidas, um dos sistemas de controle de versão (SVN – CVS) mais utilizados mundialmente, lado a lado com outros como Mercurial, Bazaar e vários outros.

Basicamente temos um programa que mantém um histórico de tudo o que foi submetido para ele armazenar. Ou seja, se você submeter um arquivo TXT ele, tendo uma versão original, criará uma entrada dizendo quais linhas foram alteradas, quando e por quem, incluindo uma mensagem (opcional) que o responsável por submeter o arquivo pode colocar.

Vale a pena conferir: http://subversion.tigris.org

Existem ferramentas para ambos ambientes Windows e Linux. 

Ele funciona em conjunto com o Apache, podendo disponibilizar o repositório (local dos arquivos) via HTTP ou HTTPS. Também permite aceitar submissões (PUT) através do Apache (Cuidado! Isto comente funciona corretamente em versões 32 bits. Encontrei alguns erros em ambientes x64 para este recurso).

Uma boa prática é ler o guia introdutório que, apesar de estar em inglês, está bem claro e legível. O capítulo 1 explica detalhadamente como funciona um sistema CVS (Controle de Versão) como o SVN, explica os pontos abordados (alterações simultâneas em um arquivo, várias versões do mesmo arquivo, enfim…). 

De forma geral, bastará instalar o Subversion, um cliente (recomendo, para Windows, o TortoiseSVN) e aprender a trabalhar fazendo checkout (download) e checkin (upload) do código para um servidor central.

Vantagens? Várias:

• Evita que, quando duas pessoas submetam um mesmo arquivo, prevaleça apenas a versão do que submeteu por último. Existe um complexo controle aqui mas de forma geral, se o arquivo for editável (texto) o SVN mostra as incompatibilidades e solicita uma açado. Em caso de arquivos binários (imagens, executáveis, dll, etc) ele pergunta por uma ação (sobrescrever, por exemplo) se estiver disponível ou cancela o update, caso seja configurado para não permitir este caso.
• Permite que você possa controlar diferentes versões de um mesmo arquivo. De forma geral, é possível obter uma versão passada bastando fornecer o número da versão desejada.
• Permite você centralizar o código, permitindo que as pessoas tenham acesso ao mesmo de forma organizada. Também permite, logicamente, um controle de usuários para TODOS os códigos armazenados, bem como um controle de usuários POR PROJETO armazenado no SVN.

Isso dentre várias opções.

É um modelo aprovado, importante e bem reconhecido. Vale a pena estudar um pouco, aprender como funciona. Inclusive se você trabalhar sozinho(a). Imaginou ter, ao mesmo tempo, várias versões ligeiramente distintas do mesmo código (exemplo: vários clientes com pequenas alterações entre eles no mesmo código) e replicar uma alteração comum para todas as diversas versões, preservando essa individualidade?

Threads: execução simultânea?

Já repararam que alguns programas costumam travar após se clicar em um botão?

Já perceberam que algumas ações demoradas, como, por exemplo, fazer um download de um arquivo grande, pode, em algumas versões do Windows, deixar a aplicação esbranquiçada e com o lindo título de “Não respondendo…”?

Não, isto não é uma falha do Windows. Muito menos da Internet. Isto é um erro muito comum de nós, programadores. De forma geral, dificilmente separamos Threads de execução e quando o fazemos, nem sempre OBEDECEMOS esta separação.

Uma boa definição de Thread: 

Considerando que a aplicação como um todo seja um livro, Thread seria cada página do livro. Algumas, maiores (dobradas) que as outras, algumas com mais conteúdo, mas ainda sim, todas são independentes entre-si e juntas, formam o livro.

Outra forma de compreender Thread é pensando nelas como um ambiente separado de execução. Basicamente é isto. Thread é um ambiente, uma camada na qual o programa está executando ou será executado. Você pode abrir várias Threads, para evitar alguns problemas como os famosos botões afundados quando se clica e a ação demora muito tempo para ser finalizada.

Thread, na realidade, é bem mais poderosa que isto.

A melhor forma de entender o poder de uma Thread é entender COMO DEVERIA ser feita a aplicação (nossa! outra imagem!):

Créditos: Anderson Luiz Mendes Matos, 2009. Título: Threads.

Esta imagem pode ser livremente reproduzida mas não alterada.

 

É importante perceber que existe uma Thread “mãe” chamada Event Dispatcher (Iniciadora de Eventos, ou apenas Thread Principal). Ela representa a primeira e principal Thread do programa, onde DEVE ficar APENAS a interface gráfica.

Isto mesmo, é nela (Event Dispatcher) que fica a sua interface, o seu contato com o usuário, a sua interface.

As demais Threads (T1, T2, T3, …, Tn) são Threads criadas durante a execução, para executar ações diversas. Idealmente, todas as classes que fossem Model (padrão MVC) deveriam ter seus métodos chamados em Threads isoladas, mas isto gerão não é feito (complexidade, dificuldade de troca de informações entre Threads, preguiça, enfim…). De forma geral, o mais importante é colocar em Threads isoladas todos os recursos que precisem esperar algo (por exemplo, que precisem monitorar um determinado local no HD esperando que um determinado arquivo seja criado) ou que seus métodos sejam tão demorados que level mais de 0,5 segundos para serem executados, o que pode ocasionar em travamentos na interface do usuário.

“Ah, mas o botão tem que ficar travado. Imagine se o usuário clicar várias vezes no mesmo botão e ele execuar várias vezes o mesmo processo?”. Isto é “desculpa pra boi dormir”. Um programa bem feito pode facilmente bloquear o botão (e APENAS o botão), executar a Thread nova e a própria Thread, ao ser finalizada, desbloqueia o botão, evitando assim que um mesmo método seja executado múltiplas vezes.

“E como eu faço para que Threads diferentes não acessem o mesmo arquivo ao mesmo tempo?”. Locks. Toda linguagem tem sua forma de aplicar um lock ao arquivo. Se você vai LER apenas o arquivo, não há maiores problemas. Se a informação é volátil (por exemplo, um número que, de tempos em tempos pode ter seu valor alterado ou outra Thread) o ideal é implementar uma Thread que verifique o conteúdo do arquivo de X em X milissegundos (dependendo da volatilidade do conteúdo). Esta Thread repassa o valor lido para outra Thread (por exemplo, a Event Dispatcher, exibindo o conteúdo do número). 

Se o problema é gravar no arquivo, o ideal é através de Locks (Cursores/CURSOR). Assim você garante a integridade do arquivo.

Mas então, porque é interessante usar Threads?

Sua principal força está em executar partes do código distintas, ao mesmo tempo. 

Você pode, pode exemplo, executar dois ou mais downloads (exemplo de um sistema de controle de downloads) simultaneamente, ou várias partes de um mesmo download. 

Pode, em outro caso (exemplo de um sistema de geração de boletos bancários) permitir ao usuário que ele clique em “Imprimir boletos” (o que, no exemplo, geraria uma impressão de 400 boletos frente-e-verso), fechar a tela e continuar trabalhando em outra coisa, até que a impressão estivesse concluída.

Enfim, Threads são fortes em execução paralela.

Mas cuidado com as Threads. Elas não possuem QUALQUER garantia. Por exemplo, uma Thread que esteja em “sleep” (adormecida, pausada) pode simplesmente acordar antes da hora, se o sistema operacional achar que ela morreu. Outro detalhe é que iniciar uma Thread A antes de uma Thread B não garante que A seja finalizada antes. Nem mesmo se A possuir maior prioridade. Dependerá apenas da boa vontade do processador, que, de forma geral, tenta ser aleatório quanto à execução das Threads. Elas não são garantidas de não “morrerem” (travarem), embora isso seja mais um problema de programação que de execução.

Threads são amigas. Chatas, teimosas, complicadas, mas amigas. 

Linguagens mais recentes como C# ou Java (nem tão recente assim) dão um forte enfoque às Threads. Sistemas mais antigos, como Delphi, C++, Clarion e outros, possuem foco em outros pontos. 

De forma geral, cada linguagem utiliza Threads de seu próprio jeito, mas é importante que o programador saiba utilizá-las com sabedoria e com calma. Threads em excesso podem causar sérios problemas em DEBUG.

MVC: Essa moda ainda vai pegar você.

Toda vez que mudamos de linguagem é a mesma velha história:

• Orientada a Objetos
• Reaproveitamento de Código
• Facilidade de Migração
• Facilidade de Debug e Correção de Erros
• …
• …
• …

Mas pessoal, convenhamos, quando a gente migra de linguagem o que menos vemos é isto. Parece mais discurso de político, não é mesmo?

Pois é, mas isto somente ocorre com quem está desenvolvendo de forma ANTIGA em ambiente NOVO. Seja sincero, não aqui no Blog porque não quero ninguém pagando mico, mas consigo mesmo(a). Você desenvolve de forma errada. De forma geral, se você reparar no seu trabalho, parece que continua desenvolvendo em uma linguagem Procedural, não é mesmo? Ou em uma Orientada à Gambiarra, estou certo?

Pessoal, há algum tempo resolveram criar um modelo de desenvolvimento. Uma estrutura que permitiria EFETIVAMENTE criar programas reaproveitáveis, códigos mais simples, bem mais organizados, de uma forma extremamente produtiva e (pasmem!) muito mais simples do que seria antigamente.

E o melhor: O padrão está tão bem documentado e foi tão bem elaborado que pode ser usado em qualquer linguagem de programação, embora seja especialmente produtivo para linguagens OO.

Observem o modelo MVC de pertinho (nossa! uma imagem!):

Créditos: Anderson Luiz Mendes Matos, 2009. Título: Modelo MVC. 

Esta imagem pode ser livremente reproduzida mas não alterada.

De forma geral, temos três entidades pertencentes ao modelo MVC:

1. Controller ou Controlador: Representa (óbvio) o “C” do “MVC”. Este componente representa a parte controladora da aplicação. Tá, eu sei que ficou redundante. Digamos que o Controller é responsável, em uma aplicação Desktop (standalone) por CHAMAR os métodos, por INSTANCIAR as devidas classes, por DECIDIR o que será feito naquele momento, enfim, ele não FAZ as coisas acontecerem, ele apenas COORDENA o processo para que ele ocorra normalmente.
2. Model ou Modelagem de Negócio: Mais óbvio ainda, representa o “M” de “MVC”. O Model é quem vai EXECUTAR as tarefas. Por exemplo, é quem vai pegar uma informação no SGBD, é quem vai calcular um somatório, é quem vai conferir se o CPF é válido, é quem vai gerar o PDF conforme solicitado, enfim, ele FAZ as coisas. Somente isto. Somente FAZ. Ele não sabe o que tem a ser feito, ele apenas sabe como fazer.
3. View ou Interface: É, logicamente, o “V” do “MVC” e é encarregado de receber um recurso “raw” (sem formatação, sem qualquer preparo, somente o dado puro) e exibí-lo de forma organizada, correta, “bonitinha”, estruturada.

Veja abaixo um exemplo do funcionamento do MVC:

1. Usuário clica no menu “Gerar relatório de todos os usuários”.
2. O Controller decide qual tela irá exibir, no caso, ele vai, antes de qualquer outra coisa, perguntar se o relatório vai ser em impressora ou PDF.
3. O usuário decide por PDF e o Controller então “solicita que a interface se apresente”. O correto seria falar isso mas soa estranho, então de agora em diante eu vou dizer apenas “exibe a interface de …”.
4. O usuário digita qualquer que sejam os dados necessários ao relatório (exemplo: filtros para não ser necessário imprimir todos os registros).
5. Quando o usuário clicar em “Imprimir” o Controller é informado e, então, solicita ao Model que processe as informações e retorne os dados do relatório.
6. O Model relativo ao relatório (exemplo: uma classe Java, um embed em Clarion, uma unit em Delphi, enfim…) recebe os parâmetros vindos da interface e processa o relatório, buscando os dados relevantes no SGBD e organizando-os, por exemplo, em uma matriz.
7. O Model retorna o resultado para o Controller que, então, chama outro Model, agora responsável por gerar o PDF. Este Model é capaz de receber, por exemplo, uma matriz e, sabendo que se trata de uma matriz ele monta um PDF padrão para relatórios. Após o PDF montado e pronto, o Model pode decidir entre salvar o PDF (por exemplo) ou exibí-lo em tela. Suponhamos que ele decida exibí-lo. Assim sendo, ele devolve o PDF para o Controller.
8. O Controller, por último, inicializa e exibe a interface de apresentação de PDFs. Esta tela possui o único trabalho de receber um arquivo PDF e exibí-lo (renderização). Mais nada.
9. Fim da jornada. O usuário feliz e saltitante pode ver seu relatório em PDF.

Simples? Nem tanto. A idéia é simples, mas a implementação é um pouco difícil. Não na questão de complexidade, mas na nossa própria teimosia. “Ah, eh só uma variável, vou por ela aqui, depois eu arrumo direitinho”. Se isto acontecer, pode saber que você acabou de quebrar o MVC. Para sempre. Tenha CERTEZA que você nunca vai voltar para arrumar esta pequenina quebra, principalmente se o sistema compilar e funcionar corretamente.

O MVC é um padrão fundamental hoje em dia, para qualquer desenvolvimento de qualidade. Seus principais benefícios são:

• Isolamento da camada de negócios e da camada de interface. Isto permite coisas bem interessantes, tais como equipes distintas (uma trabalhando com design de interfaces/usabilidade e outra trabalhando com código apenas), permite que a interface possa ser facilmente alterada (por exemplo, migrar o programa para WEB nunca ficou tão simples. Em algumas linguagens, como Java ou .NET, bastaria trocar a interface desktop por páginas HTML + CSS + JavaScript/Ajax).
• Este isolamento também favorece o desenvolvimento modular, ou seja, você pode criar bibliotecas. Suponhamos um sistema de controle financeiro. Você poderia criar bibliotecas isoladas, por exemplo, de pessoa, de bancos e de estatística, que poderiam ser reaproveitadas em outros sistemas. A biblioteca consiste-se apenas de código funcional (de forma geral, uma série de funções e variáveis necessárias).
• Criar sistemas “personalizados” também fica bem mais simples. Imagine criar um sistema inteiro para cada cliente de uma mesma atividade comercial, por exemplo. Agora, imagine se o código funcional para ambos fosse exatamente o mesmo, mas a interface completamente diferente. Isto permite que um patch de correção do programa seja o mesmo para todos os clientes, e que a interface seja única, deixando cada cliente satisfeito com sua personalização do sistema.
• Contratar funcionários fica simplificado. Agora, seu funcionário vai trabalhar em um determinado ponto do sistema, não em um ponto que ele julgar necessário.
• Corrigir falhas fica simplificado. Como eu falei, uma correção se aplica a todos. Testar o programa também fica mais simples, porque o código funcional é exatamente o mesmo. Erros diferentes para uma mesma ação não ocorrem mais, já que a ação sendo a mesma, desencadeará os mesmos processos internamente ao sistema. A diferença agora não está mais no programa como um todo, mas apenas na interface gráfica do mesmo. O código também está organizado. Você sabe onde está a ação, porque o local dela é exatamente no Model respectivo à ação. Não existe mais código espalhado em toda a aplicação. Tudo está em seu devido lugar.
• Acrescentar ou remover um item na interface (por exemplo, uma opção de menu, um botão, enfim) fica extremamente mais simples. Isto porque agora a interface é apenas a interface. Recompila-se apenas a interface, atualiza-se apenas a interface. Isto reduz tempo, trabalho, tempo de upload, tempo de download, enfim, simplifica o processo drasticamente. Além de que se o item representar um novo Model, não é preciso recompilar todo o sistema, somente a interface e o novo Model…

Existe, na realidade, uma enormidade de vantagens. E o melhor: todas são inteiramente gratuitas, funcionam em todas as linguagens de programação modernas, são “implementáveis” (nada burocrático ou impossível… o maior trabalho é de se policiar para evitar que você faça coisa errada por puro vício de programação).

Vale a pena. Quem é grande já adotou. Quem é médio está adotando. Quem é pequeno também está adotando. 

E você, está esperando o que?

Engenharia de Software: métricas.

Todos nós já passamos por isto, ou iremos passar. E, sem dúvidas, vamos ficar com um enorme ponto de interrogação em cima de nossas cabeças, não importa o quão experiente sejamos.

Quanto cobrar pelo nosso sistema?

Será que devo cobrar pelo tempo que levei para montar o programa? Pelas minhas horas de trabalho? Se for, então os sistemas que levarem muitas horas podem acabar se tornando inviáveis.

E se cobrar pelo trabalho que tive para montar o sistema? Será que saberei medir corretamente o quão difícil foi para que eu montasse o sistema por completo? Não estaria me subestimando ou superestimando?

Cobrar pelo número de máquinas no cliente? Mas e se a empresa for imensa e somente usar o sistema em um único computador?

Cobrar pelo tamanho do banco de dados? Será que seria justo cobrar de uma empresa visivelmente pequena pelo enorme banco de dados que ela possui, de clientes, dependentes, ex-clientes, ex-funcionários, peças, serviços, … … …

Cobrar pelas linhas do programa? Bom, neste caso, como calcular a diferença entre um programador bem experiente, com várias técnicas de otimização e um programador iniciante, que ainda não conhece bem as “artimanhas” da linguagem?

Depois de finalmente escolher pelo que iremos cobrar, falta ainda a pergunta: QUANTO?

Seria um preço justo o valor de R$1,00 por linha de código por exemplo? Por registro no banco de dados? Por minuto de trabalho?

Pessoal, esses problemas são antigos e sempre acompanharam a evolução da nossa área. Justamente por isto que hoje, mais do que nunca, o que não falta são métricas oficializadas, bem documentadas e padronizadas, que servem de base para se calcular a complexidade do sistema e, consequentemente, o valor final do mesmo. 

Algumas delas são:

• LOC (Lines of Code) ou Linhas de Código: Forma simples, mas que se for bem pensada pode funcionar e já vai te ajudar. Basicamente, a solução para o que falei mais acima (níveis de conhecimento da linguagem diferentes) pode ser contornada com uma prática muito adotada na CLC que é a adoção de PESOS no cálculo. Quanto maior for a experiência do programador na linguagem, maior o seu peso. No final, teremos um resultado com relativa precisão que pode servir de uma base inicial para um cálculo. É, no entanto, uma métrica muito simplista e, mesmo para empresas pequenas e iniciantes ou programadores curiosos, existem técnicas melhores…
• FPA (Function Point Analysis) ou Análise de Pontos de Função: Uma técnica que revolucionou o mercado por um bom tempo, ajudou muito a todos mas hoje começa a apresentar certas incompatibilidades com a realidade atual. De forma geral este método é focado em I/O, sendo que o Input pode ser de várias formas (bancos de dados, arquivo, teclado, etc) e o Output também é variado (impressora, email, tela, outro programa, etc). No entanto, hoje mais do que nunca, os programas começam a evitar I/O por vários motivos e recorrem a outras técnicas mais complexas, o que deixa essa métrica problemática, principalmente em ambientes no padrão MVC (vou explicar no próximo post, aguardem).
• UCP (Use Case Points) ou Pontos de Caso de Uso: Sinceramente, a minha favorita. Pré-requisito de se compreender a notação UML, pois você irá trabalhar com conceitos de Classe, Entidade, e outros. Através da UCP você pode saber a complexidade de cada parte do programa, medir corretamente os esforços e extimar o esforço total (e, a partir daí, o valor a ser cobrado, por exemplo).

Existem várias métricas na realidade, bem como vários programas voltados para esta tarefa. Alguns são internos às IDE’s, outros externos. De forma geral, no fundo, todos fazem o que pode facilmente ser feito manualmente, com um pouco de paciência. A vantagem é que eles automatizam a tarefa.

A partir da complexidade, eu, particularmente, defendo que se crie o número gerado como peso de cálculo. 

No meu caso eu gosto de levar em consideração o número de campos totais em uma tabela. Cálculo na seguinte regra (métrica pessoal):

• Somatório da quantidade de células em cada tabela (linhas x colunas)
• Ao somatório, multiplico 2 e divido todo o total por 3, arredondando sempre para CIMA.

Com os dois números em mãos, você terá o valor da complexidade do sistema e o porte do banco de dados de seu cliente. 

A partir daí use a criatividade. Cada um pode desejar fazer de alguma forma ligeiramente diferente. Um bom começo é fazer testes com a multiplicação destes fatores. 

Outra opção é criar regras do tipo 

(1 + complexidade_software) * (porte_bd / 10) + porte_bd.

Enfim, criatividade, pessoal. O importante é que vocês testem os valores e percebam se a fórmula gerou um número economicamente interessante para ambos os lados. Afinal de contas, o cliente quer pagar um preço justo e você precisa pagar suas contas. Faça um breve cálculo para saber se o valor cobrado paga ou tem a expectativa de pagar seus investimentos, seja a curto, médio ou longo prazo.

Redes: o caminho para os seus dados

Seja apenas para compartilhar a Internet, seja para um complexo sistema organizacional, os computadores, mesmo domésticos, estão em grande número inseridos em uma rede.

De forma geral as redes são suas amigas, servem para lhe auxiliar na hora de trocar um arquivo com outro computador, na hora de tirar um backup, na hora de centralizar os esforços em uma empresa, na hora de acessar um recurso (por exemplo, a internet).

As redes servem para unir computadores e dispositivos compatíveis para que um acesso entre eles possa ser estabelecido. Esta é, digamos, a definição amigável de uma rede. Logicamente que tem muito mais possibilidades, a rede pode ser bem mais simples ou bem mais complexa que isto.

Não vou comentar de redes antigas como o modelo anel, coaxial. São redes que provaram ser funcionais mas que caíram em desuso porque apesar de geralmente apresentarem um custo menor, são altamente intolerante a falhas (uma falha paralisa totalmente a rede, tornando-se um meio não-confiável e difícil de se encontrar a falha). Portanto, vamos para os dispositivos usados atualmente, bem como os tipos de rede mais importantes hoje:

Dispositivos

1. HUB: Este é, sem dúvidas, o quebra-galho de toda empresa. Se ele ainda não passou na sua vida, com certeza irá passar. São baratos, práticos e funcionam. Não maravilhosamente bem, mas funcionam, sem dúvidas. É a forma mais simples de ligar os computadores da rede. Não permite unir meios distintos (exemplo: duas redes diferentes, como a sua rede interna de seus computadores e a internet, que nada mais é que uma rede externa).
2. SWITCH: São hubs, digamos, inteligentes. Não confundam com hub-inteligente, este é outro dispositivo que não vou citar porque dificilmente vocês vão encontrar um. Os switchs são bem mais que um mero HUB, eles são capazes de saber qual computador está em qual porta, portanto, não precisam enviar a informação para TODAS as portas, eles a envia apenas para a porta onde está o computador de destino. Isto melhora a performance da rede porque permite que várias duplas de computador conversem ao mesmo tempo (desde que as duplas possuam computadores distintos entre elas).
3. ROTEADOR: São os TOP na linha de concentradores. Basicamente eles encontram rotas. Eles encontram o destino. Não interessa aonde ele esteja. Se ele existe, pode ser encontrado. Roteadores são extremamente inteligentes, calculam caminhos mais rápidos para os dados, permitem unir redes diferentes (outro exemplo: unir uma rede coaxial com uma rede par-trançado, esse fio azul comum hoje em dia). Alguns são repletos de recursos, como firewall, VLAN, VPN, Virtual Server, Port Forwarder, DMZ e muito mais, mas de forma geral quando mais recursos, mais caro. Se o seu roteador faz muita coisa e custa barato, provavelmente é um D-LINK, TP-Link ou similares, e este tipo de roteador somente funciona em ambiente doméstico, NUNCA coloque a sua empresa dependente de um destes…

Ambos SWITCH e ROTEADOR possuem uma importante característica, que precisa ser obedecida: Capacidade de Roteamento. Isso quer dizer que eles precisam ser capazes de enviar os dados na velocidade que sua rede requer estes dados, senão, embora a rede FUNCIONE, isto irá causar grandes “gargalos” (pontos de lentidão no tráfego dos dados).

Existem hoje, principalmente, os seguintes tipos de meio para o tráfego dos dados:

• Cabo Par-trançado não-blindado Categoria 5: permite montar redes até 10/100/1000, mas a rede gigabit (1000) aqui se torna uma árdua tarefa e praticamente inviável. Muito comum em redes 10/100.
• Cabo Par-trançado não-blindado Categoria 5e: permite montar redes igualmente ao Categoria 5, mas neste meio a rede Gigabit funcionará melhor, com menos problemas de performance.
• Cabo Par-trançado não-blindado Categoria 6: permite montar redes, teoricamente, até 10 gigabits. Hardware para este tipo de rede ainda é um problema. Algumas redes gigabit funcionam no Categoria 6 por pura comodidade, já que o meio suporta melhor esta velocidade.
• Fibra-óptica multi-modo: permite redes de até 111Gbps, mas geralmente são utilizadas entre 10 e 40Gbps, em distâncias bem interessantes (550 m). Não são caras em si, mas o equipamento ainda é BEM mais caro.
• Fibra-óptica mono-modo: sua principal diferença é o alcance BEM superior à multi-modo, chegando a atingir até 10KM. Seu maior uso está em redes nacionais e links internacionais (exemplo: link submarino). As velocidades geralmente são as mesmas da fibra multi-modo.
• Rádio: funciona em várias frequências, depende um pouco do tamanho da rede, da legislação do país (para não haver interferência com outras transmissões de rádio, por exemplo), dos aparelhos utilizados, enfim. São basicamente as redes Wireless, de forma geral.
• Blootooth: Famosas por serem redes pessoais, sem fio. Funcionam bem, mas tem pequeno alcance. Ideais para um celular transmitir dados para outro celular, ou para um fone de ouvido se conectar ao celular, ou ainda para conectar o teclado ao computador.
• 3G: Funciona relativamente parecido com um celular, é um futuro relativamente promissor. Eu particularmente não acredito muito no 3G por causa da próxima tecnologia da lista, mas SEM DÚVIDAS é um ótimo mercado e está em grande expansão.
• Wi-max: São redes de porte metropolitano. Grandes, funcionais, rápidas, seguras. Funcionam via UHF. São de baixo-custo de implantação, requerem hardware barato, são estáveis e, repetindo, possuem longo alcance, o que melhora drasticamente o problema do wireless tradicional, que requer dezenas de access-points estratégicos para atingir uma grande área. São a solução do futuro, alguns países já começaram a implantar.

3G nem chegou ao Brasil e, em breve, acredito que já cairá em desuso por causa desta tecnologia. O grande problema é que o governo brasileiro está travando a chegada do Wi-max, mas tem um bom monivo: ele quer se assegurar que gigantes não comprem os direitos de utilização. Duas, no entanto, já comparam (se não me engano, embratel e intelig). Agora o governo quer que somente empresas menores sejam capazes de adquirir esta tecnologia, favorecendo a competição e melhorando a qualidade e os preços de internet no Brasil.

Bom, agora existem muitas formas de se implementar uma rede. 

A forma mais simples é através de uma rede em estrela (um concentrador central e os computadores se conectando à ele), utilizando-se o protocolo TCP/IPv4. Esta é a forma mais utilizada hoje em dia.

No entanto, o IPv6, já suportado por todos os sistemas operacionais modernos, é uma alternativa bem interessante, principalmente porque ele reduz drasticamente o trabalho do roteador. Resultado? O melhor de todos: maior performance. Com menos trabalho na hora de identificar a dupla DE/PARA o roteador pode encaminhar o pacote de informação muito mais rapidamente. Logicamente isto requer um roteador (ou switch) compatível IPv6.

Wireless possui, hoje, três velocidades comerciais: 54mbps, 108mbps e 300mbps. 

Não se engane, estas não são as velocidades reais, que geralmente ficam em 48mbps, 90mbps e 280mbps, quando o sinal está decentemente forte. 

Sinceramente, a única vantagem do wireless é ele ser wireless, ou seja, ele não requer cabos. De forma geral ele perde em desempenho, em segurança, em preço, em qualidade, em estabilidade. Vence em estética.

Gigabit tem seu preço. Sua maior sensibilidade à interferências e sua maior sensibilidade às curvas (em comparação à Fast Ethernet) deixa sua infraestrutura ligeiramente mais complicada. Seu hardware também é ligeiramente mais caro (um switch inteligente, com as mesmas funcionalidades, de 48 portas, custa certa de R$ 800,00 para Fast Ethernet e R$ 1500,00 para Gigabit).

Fibra também tem seu preço. Curvas são uma dor-de-cabeça e requerem um raio enorme de curvatura mínima. Também são MUITO problemáticas em emendas, que precisam ser feitas com uma pasta especial, na qual o técnico alinha as duas fibras via microscópio e as une através de nada menos que uma FUSÃO, derretendo as fibras para que a união seja perfeita.

Enfim, cada jogo tem suas regras.

Eu estou trocando a rede da empresa aqui para Gigabit. Estamos usando Cabo par-trançado categoria 5e Nexans com conectores Furukawa. Ainda preciso trocar as placas de rede dos computadores (não é caro) e preciso comprar o switch (aproximadamente R$ 1500,00). O roteador eu montei (um computador que vou comentar em outro post) totalmente personalizado, focado em possibilidade de união de várias WANs (internet) para load-balancing (distribuição da carga… funciona “COMO SE FOSSE” uma única internet bem mais rápida) e failover (se uma internet falhar eu tenho outra para evitar que tudo pare por completo). Load-Balacing e Fail-Over são uma dupla MUITO importantes no dia-a-dia de uma empresa atualmente. Principalmente quando se trabalha com WEB.

Enfim, tenham cuidado e carinho com suas redes, pois sua empresa (e talvez sua casa) depende do bom funcionamento delas. 

Sempre que forem implantar uma rede por inteiro, vale a pena procurar pela Internet nas mais novas tecnologias, meios físicos disponíveis, vantagens e desvantagens de cada uma.

Hardware: do que exatamente você precisa?

Eu não me canso de rodar lojas de informática (e, não sei porque, supermercados também resolveram embarcar na área, como se um computador fosse um aparelho que basta colocar no carrinho, levar para casa e ligar na tomada) e ver computadores com um super-processador, moderno, rápido, econômico, e acompanhado de uma quantidade ínfima de memória RAM e um HD monstruosamente imenso.

Mas do que exatamente precisamos?

Processador? Memória? HD? Rede?

Primeiro precisamos entender que um computador não é apenas um conjunto de partes que conectam processador, memória, HD, teclado e mouse. Existem muitas, muitas partes importantes em um computador, que não podem ser compradas sem um mínimo de conhecimento.

 

Processador: 

Esta é uma parte muito importante, sem dúvidas, mas cuidado aqui. Processador é responsável por processar. Fazer as coisas funcionarem, executar tarefas, transformar uma coisa em outra, calcular. Ele não precisa ser monstruoso se você não tiver muitas coisas executando “ao mesmo tempo” (por exemplo: ouvindo música, navegando na internet, trabalhando em um editor de textos, conversando no msn, etc). 

Não adianta triplicar a velocidade do processador para deixar seu computador mais rápido se o seu uso de processador estiver abaixo de aproximadamente 60% do consumo dele… Será um investimento que, claro, vai dar algum efeito, mas não irá justificar o valor.

Memória: 

Um componente barato, não justifica sua economia aqui. Memória é uma parte crucial no computador porque é dela que o processador recebe os trabalhos a serem executados e é pra ela que ele devolve os resultados. De forma geral, quanto mais rápido e em maior quantidade melhor, mas fique atento para algumas normas abaixo:

• Sistemas 32 bits (também chamados de i386 ou x86), os mais comuns ainda atualmente, suportam um máximo de 4GB de memória. Não adianta tentar colocar mais, eles não vão “enxergar” mais do que 4GB.
• Sistemas 64 bits suportam bem mais memória, mas trazem consigo um problema de compatibilidade com algumas aplicações. Nem tudo (ainda) funciona em x64. Os maiores culpados são os drivers para 32bits. Windows possui um modo de compatibilidade que ajuda, mas ainda sim não resolve. Aplicações 16 bits ou anteriores nem precisa tentar, não rodam e ponto final. Compilar sistemas também é um problema, porque compilar em x64 pode transformar sua aplicação em 64bits, tornando-a incompatível com ambientes 32 bits.
• A placa-mãe (vou falar mais abaixo) traz limitações de quantidade de memória. Isto se deve principalmente pelo público-alvo definido para a placa. Geralmente placa mais simples (mais baratas) suportam menos memória que as placas melhores (e mais caras). Atualmente é comum placas suportarem algo entre 2GB e 4GB máximo em memória. Placas de servidor costumam suportar algo em torno de 16 ou 32GB, dependendo do modelo.

Placa-mãe: 

Esta é, literalmente, a mãe dos componentes. A compra do computador deve começar com a escolha da placa-mãe e deve terminar com a conferência da placa-mãe. 

Antes esquecida, finalmente os técnicos começaram a enteder que este componente é responsável pelo BOM funcionamento de TODOS os demais. Literalmente todos. Uma placa-mãe ruim não apenas deixa seu computador mais lento, mas instável e incompatível com algumas aplicações. 

Marcas simplistas (em especial, PCCHIPS) estão começando a decair justamente porque os técnicos aprenderam que montar computadores com estas placas é econômico mas cansa. Cansa tentar arrumar algo que não tem como consertar. 

Lembre-se de algumas coisas na hora de escolher sua placa-mãe:

• De forma geral, não se encontra placa-mãe de BOA qualidade por menos de R$ 400,00.
• Não se prenda a nomes. Marcas famosas (por exemplo, ASUS) ultimamente têm se tornado uma tremenda dor-de-cabeça. Em especial a ASUS, traz consigo uma estranha incompatibilidade nas portas USB que precisa ser corrigida com um patch direto do site deles… 
  

  Por outro lado, uma antiga marcha, Gigabyte, está se tornando ponto de referência atualmente, com sua melhora surpreendente de qualidade e durabilidade.
  
• FSB indica a velocidade de transferência de dados. Não adianta comprar um processador de FSB 1333MHz, memória de 1333MHz e placa-mãe de 667 MHz. Prevalecerá sempre a menor velocidade, portanto, escolha velocidades compatíveis.
• Chipset é o componente que “liga” os demais componentes. Chipset Intel geralmente é muito bom mas não é o único. nVídia é um fabricante bem famoso atualmente porque o chipset possui ótimas taxas de leitura/escrita de dados. 
  

  VIA é um fabricante clássico, genérico e de baixo custo (e baixa performance).
  
• Slots PCI / PCIe são muito importantes. Não despreze-os. Pelo menos 1 PCI é FUNDAMENTAL para um computador. Dê preferência para algo que se aproxime de 3 PCI e 1 PCI-express.
• Você vai precisar de uma placa-mãe compatível com o processador que for comprar. GERALMENTE as placas compatíveis com uma determinada linha de produtos (exemplo: Core 2 Duo) são compatíveis com todos os processadores daquela linha, mas isto não ocorre em todos os casos. O fabricante da placa-mãe tem SEMRPE uma lista de modelos de processadores suportados. Antes de montar o computador, CONFIRA. SEMPRE.

HD: 

Este componente é importante e nem sempre é bem conferido. 

Existem uns números quase nunca observados, que são a verdadeira parte importante de um HD. Eles são as latências, read (leitura), write (escrita) e rates (taxas). As unidades de medida são em nanossegundos. Muito rápido, mas acredite, INTERFERE na sua experência de uso.

• Latência: Indica o tempo de deslocamento do HD. 
  

  O HD é um componente físico em um conjunto de componentes eletrônicos. Ele precisa deslocar um “braço” para ler os dados, que são gravados em algo que parece alguns CD’s (feitos de metal) empilhados. A latência representa o tempo de deslocamento do braço. Geralmente considera-se também o tempo de início de giro do disco.
  
• Leitura: Indica a tempo para leitura de um dado. Geralmente é informado o tempo médio de leitura, que é o mais importante.
• Escrita: Indica o tempo para gravação de um dado. Assim como no read, geralmente é informado um tempo médio, que aqui também, é o mais importante.
• Taxa nominal: indica a velocidade máxima suportada pelo HD para transferência de dados. Embora o SATAII opere a 3Gbps, isso não quer dizer em momento algum que o HD consiga transferir a 3Gbps. O que está em buffer, sim, transfere a 3Gbps, mas o que está em disco sempre leva mais tempo. Uma velocidade boa aqui está acima de 2,1Gbps (270MBps).
• Taxa de transferência sustentada externa: Indica a velocidade real com a qual o seu HD irá funcionar, na vida prática. Dificilmente você vai conseguir este dado, a maioria dos fabricantes não disponibiliza a não ser no manual do aparelho que, dificilmente, o acompanha. Use as taxas nominal e sustentada interna como referência, já que esta será bem complicada de se obter.
• Taxa de transferência sustentada interna: Indica a velocidade de transferência de dados dentro do próprio HD. Porque isto é útil? Exemplo prático: copiar dados de um lado para o outro, de uma partição para outra. Não é crucial, mas não é dispensável.

Existem hoje 4 principais tecnologias de HD:

• Paralelo ATA (pATA ou simplesmente ATA), é o modelo antigo e já caindo em desuso atualmente.
• Serial ATA (SATA e SATAII), é o novo modelo, de baixo custo mas com algumas semelhanças ao SCSI
• SCSI (Lê-se algo como “scûzi”), é uma tecnologia focada em desempenho. Muito conhecida em servidores, não se popularizou pelo seu elevado preço. HD’s SCSI não são grandes (em GB) como os IDE/SATA mas são tremendamente mais rápidos. Se não bastasse o elevado preço, eles não podem (geralmente) ser ligados diretamente no computador, e precisam de uma placa especial, chamada Controladora, que também é cara.
• SAS (Serial Attached SCSI) é a evolução do SCSI antigo para que ele fique mais rápido, esquente consideravelmente menos e economize muita energia. Assim como o antigo SCSI, os SAS geralmente não podem ser ligados diretamente na placa-mãe (existem excessões), requerindo uma Controladora. São (proporcionalmente) muito mais baratos que antigamente, embora ainda sejam BEM mais caros que os SATA.

O HD parece com uma pilha de CD’s feitos de uma liga metálica, com um pino achatado que fica entre eles. Este pino (braço) serve para sustentar o minúsculo componente que realiza a leitura/gravação no HD. 

De forma geral, quanto mais rápido o HD girar, mais rápido ele vai ser para ler, gravar e buscar uma informação. 

Hoje em dia existem quatro principais velocidades:

• 5400rpm, muito comum em HD’s IDE (antigos) e em HD’s de notebook.
• 7200rpm, tornaram-se populares nos SATA, são extremamente comuns hoje em dia principalmente em HD’s SATAII (3Gbps). HD’s SAS estão usando esta velocidade, atualmente, para promover um HD de alta durabilidade e confiabilidade (para servidor) em um preço sensivelmente mais barato, sendo muito útil como forma de backup ou armazenamento de arquivos.
• 10000rpm, surgiram como uma forma de baratear o SAS. Antigamente era algo exclusivo SAS, mas hoje já existem HD’s SATA nesta velocidade. Existe um modelo em especial de SATA que consegue ser superior aos modelos SAS de mesma rotação (rpm). Vou comentar o motivo em breve.
• 15000rpm, é atualmente o topo de velocidade. Somente SAS operam nesta velocidade, que proporciona transferências antes somente vistas nos seus sonhos… 
  

  No entanto, o preço parece um pesadelo…
  

Outra coisa que interfere na velocidade do HD é o número de discos e o tamanho físico dele. Sim, o tamanho físico. 

O número de discos interfere pois quando mais discos e mais cabeças de leitura/gravação, mais dados são lidos/gravados ao mesmo tempo, agilizando o processo. 

O tamanho físico interfere pela distância total que o braço tem que se movimentar para localizar/ler/gravar um dado no disco. 

É pela união destes fatores (mais de uma cabeça de gravação, tamanho reduzido e alto rpm) que um modelo de HD’s da Western-Digital (WD) está conquistando mercado. A sua linha de HD’s SATAII 10.000rpm está se mostrando mais rápida que a linha SAS também de 10.000rpm. Eu vi, comprei, testei e comprovei. São muito rápidos.

Placa de vídeo: 

Pois é, não se assuste aqui quando eu contar que a placa de vídeo pode interferir no seu dia-a-dia. 

Meu pai é prova disto: no dia que experimentou rolagem do texto sem tremidas na tela, nunca mais deixou de comprar placas de vídeo com alguns detalhes mínimos. 

Placas de vídeo possuem algumas características importantes:

• Memória: Dedica (exclusiva para a placa de vídeo) é mais rápida (geralmente) que compartilhada (usam parte da memória RAM do computador). 
  

  Faixas entre 128MB e 256MB são ótimas para um computador normal, embora jogos possam consumir mais (1, 2GB).
  
• Taxa de bits: Geralmente variando de 64 até 256, muito comum em 128. É uma ótima taxa para uma placa de vídeo normal.
• Velocidade da GPU: Dificilmente isto vai afetar um computador normal, mas é aqui que fica a principal diferença entre uma placa “normalzinha” de uma “super-placa” para jogos.

Placa de rede: 

Geralmente não vai afetar muito sua vida, mas lembre-se que em servidores, uma placa de rede deve SEMPRE possuir seu próprio controlador. Em computadores desktop isto geralmente fica por conta do chipset. Em servidores, esta diferença representa um custo bem maior, mas um sensível aumento de performance na rede.

Fonte: 

Não se esqueçam dela! Sim, a fonte! A responsável por fornecer energia de qualidade (ou sem) para seu computador. 

Evitem, sempre que possível, fontes genéricas. Fontes chamadas de “fonte real” ou “fonte de aproveitamento real” são as ideais. 

Basicamente, funciona assim: 

A fonte obtém uma determinada quantidade de energia, e SEMPRE perde um pouco (ou muito) na forma de calor e para ela mesma funcionar. O restante é repassado ao computador. 

Fontes genéricas dizem ser 350W (por exemplo) mas funcionam em algo em torno de 30% disto, ou seja, 105W (por exemplo). Se o seu computador precisar de mais energia, ele não vai funcionar. Isto sem considerar o enorme desperdício (70%) da energia inicialmente obtida da tomada. 

Fontes reais possuem aproveitamento entre 75% e 90%, além de possuírem um sistema muito mais elaborado de segurança, qualidade do sinal energético e, em alguns casos, redundância (mais comum em servidores). 

Lembre-se que uma fonte ruim pode falhar e transmitir um surto de energia elevado para o computador. O primeiro componente a sofrer com isto será a super-sensível placa-mãe. Demais componentes como HD, DVD, placas de vídeo mais avançadas, coolers, etc, também vão sofrer. Isto pode resultar em uma perda total do computador.

 

Bom, agora que vocês tiveram uma super-aula de hardware, como saber o que vamos precisar para montar um computador?

Bom, vou montar um exemplo aqui para descrever passo-a-passo uma mini-configuração, e vou usar alguns preços de exemplo aqui para vocês saberem o preço final de um computador assim (aqui em Belo Horizonte).

Para o exemplo, vamos propor o seguinte usuário: EU. 

Porque eu? Porque eu jogo, trabalho com linguagens .NET e com Java, tenho sempre um servidor MySQL rodando aqui, tenho sempre um aplicativo Torrent conectado, estou sempre com MSN aberto, iTunes toca rádio aqui 24h por dia, tenho um anti-vírus ativo (Kaspersky), geralmente algo em torno de umas 30 abas do Google Chrome estão abertas, uma janela do Windows Explorer, algumas vezes estou com o “kit” Photoshop-Fireworks-Illustrator aberto com imagens de 1800x1600 dpi. 

Enfim, eu sou basicamente um INMetro ambulante.

Antes de falar a minha configuração atual, vamos refletir.

• Eu tenho sempre muita coisa aberta, portanto preciso de mais de um CORE (núcleo) de processador. Preciso de um FSB elevado porque estou sempre movimentando entre estes aplicativos e os dados precisam se “movimentar” rapidamente no computador para que fique parecendo uma ação instantânea para mim (usuário), algo acima de 800MHz de FSB.
• Tenho MUITA coisa ativa, portanto vou precisar de memória. Cada janela do Chrome geralmente ocupa 20 ~ 30MB de memória. Cada imagem de 1800x1600 ocupa uns 40MB (considerando que estamos em modo edição, com várias informações além da pura imagem). As próprias ferramentas de imagem consomem os seus 100MB. Preciso de 70MB pro meu iTunes. Até agora, pouco mais de 1GB de memória OCUPADA. Precisamos de 512MB pro Windows Vista Business que estou usando. E preciso de uma coisa chamada de “espaço de reserva”, algo em torno de 512MB, para que eu possa utilizar futuramente, sem que o sistema precise parar. Ou seja, pelo menos 2GB.
• Preciso de um HD mediano. Não fico fazendo muitas cópias de arquivos, nem gravando constantemente, mas não quero levar dois dias carregando um jogo, ou dois dias para salvar uma das imagens que fiz no Photoshop. Portanto, preciso de um SATAII (3Gbps) padrão, 7200rpm. Mas preciso de espaço. Jogos ocupam consideráveis GB em disco. Minhas músicas, também. Assim como meus vídeos. Tenho ainda os meus programas de uso menos cotidiano, o próprio Windows Vista. Enfim, nada menos que 500GB, que, por segurança, performance e comodidade, estão separados em 2HD’s de 250GB.
• Não sou um servidor, portanto, placa de rede normal, on-board mesmo. Nada mais do que isto.
• Placa de vídeo mediana. Eu jogo, mas não quero “entrar dentro do jogo”, não sou viciado a este nível. Quero apenas algo que me permita jogar com um mínimo de decência. Uma placa BEM simples, boa para se jogar (de forma básica), e que serve bem aos demais aplicativos é a nVidia 9400 GT (que estou usando…)
• Preciso de uma placa-mãe compatível com tudo isto, claro, sem arrombar meu bolso. Conseguimos ótimos custo-benefícios com placas Gigabyte, portanto, estou (ultimamente) bem focado nesta marca. Sinceramente, cansamos dos problemas que enfrentamos ultimamente com as nossas ASUS. Outros fabricantes, como ABIT, também são interessantes. 
  
  Vou precisar de uma placa que suporte pelo menos 4GB de memória (já que vou precisar de pelo menos 2GB, e é sempre bom ter um espaço para um crescimento). Já que não vou ter uma placa de som externa, a placa-mãe precisará de uma placa de som on-board (coisa comum hoje em dia e com relativa qualidade, devo adicionar).
  
• Para menter tudo isto rodando, preciso de pelo menos 300W reais. Ideal uma fonte, portanto, de seus 400W. Escolhi uma de 450 por segurança e porque se eu precisar colocar alguma outra peça (como estou neste exato momento), não corro riscos.

Tudo isto me leva ao seguinte computador:

• Core 2 Duo, pouco mais de 2GHz, pelo menos 4MB cache.
• 2GB RAM, DDR2
• 2 x 250GB SataII 7200rpm
• Vídeo PCIexpress nVidia 9400GT 256MB/128bits
• Placa-mãe compatível (no meu caso, GA-P35-DS3 rev 2.0)
• Fonte 450W reais

Na loja WAZ (aqui em BH, referência em hardware, site www.waz.com.br), montei o seguinte:

• Intel Core 2 Duo E7200 S775 2,53GHz FSB1066 3MB, 36 meses de garantia, R$459,00
• DDR2 667MHz 2GB Kingston ValueRAM, 12 meses de garantia, R$115,00
• 2 x (250GB SATA II SamsungSpinpoint 8MB NCQ), 24 meses de garantia, R$159,00 (cada)
• NVIDIA 9400GT 512MB/128bits Evga, 12 meses de garantia, R$245,00
• Gigabyte GA-EP31-DS3L BR - Rev 1.0, 12 meses de garantia, R$299,00
• Fonte Huntkey 450W Green Star, 12 meses de garantia, R$169,00

Total do computador: R$ 1605,00 se fosse comprado hoje. Lembrando que falta gravadora de DVD (aprox. R$100) e falta o gabinete (também aprox. R$100). Talvez seja necessário pagar um técnico pela montagem, que deve custar aproximados R$50,00.

Aspectos importantes: 

A configuração não apenas atende à demanda, como atende BEM. Estou rodando nesta configuração há algum tempo (pequenas mudanças, como a placa-mãe, já que na época não existia este modelo…), e está me atendendo perfeitamente desde que o computador foi adquirido. 

Reparem que os HD’s são um ponto caro, portanto, se precisar reduzir o preço prensem em reduzir para, por exemplo, apenas 1 HD de 160GB, que já atende a maioria dos usuários.

Experiência de uso: 

Eu trabalho normalmente, sem qualquer travamento ou lentidão. iTunes se mantém tocando a rádio que eu ouço sem qualquer interrupção. As aplicações respondem ao meu comando, sem aqueles comuns travamentos e “O aplicativo não está respondendo…”. 

Os jogos são normais, sem nenhum requisito avançado de imagem 3D ou renderização de qualidade semi-real. Apenas jogos com qualidade. A água possui o efeito de reflexo de qualidade real garantido pelo suporte nativo da placa de vídeo ao Directx10, o que melhora drasticamente a minha experiência nos jogos. A placa + monitor suportam, juntos, 1280x1024 dpi, o que me atrapalha nas imagens que faço mas não impede o uso de um prático zoom no photoshop, que, falando nisso, faz uso dos recursos de hardware da placa de vídeo para consumir menos do computador e renderizar melhor as imagens. 

Enfim, ganhei pontuação 5.0 na classificação do Windows Vista (até algum tempinho atrás, não muito, o máximo era 5.9. Não sei mais como está atualmente.).

Poderia melhorar drasticamente a performance colocando os HD’s em RAID (mas na minha placa atualmente, GA-P35-DS3 não posso, pois os drivers são para vista pré-SP1 e como estou usando Vista Business 64bits, ele é mais restrito quanto à drivers e se o driver não for totalmente 100% completamente compatível o sistema se torna instável) e aumentando a memória para 4GB (como fiz recentemente, me deixando com 1,8GB de memória em uso constante e o restante livre para as aplicações “brincarem”. Como estou usando sistema 64bits, ele reconhece toda a memória (4GB) e se apresentou BEM mais eficiente para trabalhar com arquivos grandes e com “coisas em grande número” (por exemplo, possuo um diretório onde se concentra todas as minhas músicas, vídeos, seriados, desenhos, enfim… o que gera um lindo número de 97 GB, distribuídos em 14.026 arquivos e 6.195 pastas. Em um sistema 32bits como era antigamente, ao entrar na pasta raiz desta árvore de diretórios o windows levava aproximados 4 minutos e meio para finalmente me permitir entrar em uma subpasta. Atualmente levo aproximadamente 2 segundos. Não, não são números arbitrários, nem é força de expressão. A diferença foi esta mesmo). Nas demais situações, percebi diferenças na hora de inicializar aplicações (que sejam compatíveis x64, claro) e na hora de inicializar/finalizar tanto aplicações quanto o próprio windows.

Na hora de comprar um computador, usem este guia como referência, bem como vários outros guias pela Internet. Uma parada obrigatória é o Clube do Hardware (www.clubedohardware.com.br), onde vocês conseguem reviews, testes, comentários e muito mais sobre as peças disponíveis no mercado brasileiro.

Mas pessoal, o mais importante, é BOM SENSO. 

Computador trabalha em CONJUNTO. Portanto, não comprem um super-processador, muito HD e pouca memória. Não comprem muita memória e um processador de telefone celular. Não comprem 1TB (1024GB) de HD SAS se o restante do computador é da época do Windows 95. 

No computador sempre prevalece as taxas mais lentas, portanto, não comprem um processador de 1333MHz, memória DDR3 1333MHz e placa-mãe de 667MHz porque neste caso, todo o FSB será de 667MHz, e os demais componentes mais caros estarão subutilizados.

Montar computador é uma arte. Tem que ser feito com calma. 

Eu citei um exemplo de configuração e preço. Não estou fazendo propaganda. Aliás, se eu fosse montar de verdade, faria uma cotação em outras lojas aqui de Belo Horizonte, dentre elas as que eu tenho preferência pessoal: DHCP, Oficina dos Bits e Euromaster, além claro da WAZ. Cada loja tem suas vantagens, pessoal. Explorem isto sabiamente.

E lembrem-se: Garantia TAMBÉM faz parte do produto. Não vejam garantia como um bônus, mas sim como uma das características e diferencial do produto. SEMPRE comparem as garantias ALÉM do próprio componente e seu preço. Um preço menor pode se refletir em uma garantia menor e, consequentemente, um risco maior de perder seu dinheiro todo.

Cuidado: você está preparado para o futuro?

Belo Horizonte é realmente um ovo. De conorna. De uma codorna de Bonsai. Em miniatura. Enfim, é basicamente uma cidade-átomo.
Aqui as coincidências são parte comum de nosso dia a dia. E por isto me refiro a TODOS os tipos de coincidência.

Aqui na empresa estamos trabalhando duro, sempre, para atender nossos clientes (e isso não é um marketing via blog). Sempre tivemos este ponto como nosso diferencial, sempre nos dedicamos à esta tarefa, sempre tentamos deixar o cliente o mais à vontade possível, dentro da nossa realidade.

Vou falar brevemente sobre uma outra história para que vocês entendam o que está rolando.

A Universidade FUMEC nem sempre foi Universidade. E na época de várias faculdades avulsas, a FUMEC funcionava. Não maravilhosamente bem, mas funcionava.
Como parte de sua migração ela precisava unificar as diversas faculdades e isto inclui a biblioteca e o sistema acadêmico.

Os problemas começaram com a biblioteca mas isto é irrelevante aqui, então vamos direto ao sistema acadêmico.
Foi solicitado um sistema acadêmico inteiramente novo, totalmente desenvolvido em Java, repleto de recursos interessantes para a Universidade.

Tudo faz parecer um projeto normal, de grande porte, mas a parte curiosa começa agora.
Uma empresa aqui de Belo Horizonte, foi a contratada para este projeto. O prazo começa. Um mês, nada. Dois meses, nada. Seis meses, nada. Um ano, nada. Depois de muita enrolação, finalmente começaram a desenvolver um sistema que, por estar em cima da hora, adivinhem? Não sofreu qualquer tipo de teste. PASMEM!

Ao final de dois anos, um sistema acadêmico foi entregado. Agora eu pergunto: ele funciona?
Podem acreditar que NÃO. Os professores são prova real disto: Diários somem, notas não são lançadas, partes do sistema param de funcionar. Isto quando o próprio sistema não resolve descansar, retornando um carinhoso erro 404 na hora que se tenta acessá-lo. Fora os inúmeros outros erros possíveis. Sinceramente, foi a melhor aula sobre HTTP que eu já presenciei.

Sistema horrível, todos odiaram e ainda odeiam.
Um grande Mestre lá da Universidade resolveu, então, cancelar o contrato e levar o código para dentro da Universidade, para que uma equipe de professores, monitores e alunos possam manter este código. O resultado foi interessante.
Primeiro, revelou a total e completa falta de ética do fornecedor: MEROS DOIS DIAS depois do cancelamento do contrato o sistema mostra um erro FATAL durante um ambiente que DEVERIA ter sido testado mas, bem, err, também não foi… E eles ainda queriam cobrar, se não estou enganado, R$ 120,00 a hora de trabalho de cada funcionário para corrigir este problema.
Segundo, demonstrou a capacidade produtiva da Universidade. Código melhor, mais bem elaborado, agora funcionando.

Agora voltamos ao início do post.
Estamos trabalhando em um complexo sistema de controle de sindicatos, e estamos levando em consideração pontos importantes de nosso atual know-how na área.
O sistema foca a total integração com sistemas já existentes, incluindo futuros sistemas nossos, também em java.

Outro dia meu pai recebe um email de um de nossos clientes:
Um novo sistema de sindicato está na área.
O mais bacana? É DAQUELA MESMA EMPRESA QUE EU FALEI! ELA MESMA!

Eu não sei se rio ou se entro em desespero.
Parece que rir é o mais adequado, porque os sindicatos vão adquirir um sistema totalmente obsoleto, sem completas funcionalidades, faltando partes, sem testes, sem organização (e, pasmem novamente, pelo que sei da empresa, totalmente sem documentação), sem um mínimo de compromisso, sem suporte decente e muito mais.
Vão morrer de ódio do fabricante.
Isso sem considerar que eles desenvolveram um sistema de sindicato totalmente WEB mas agora eu pergunto: Existe algum tipo de criptografia dos dados enviados?
HA-HA-HA. Quero só ver quando o primeiro cliente chegar alegando que os dados foram roubados porque o sistema é completamente desprotegido.
Pessoal, sistema sem segurança? Hoje?
Bincareida, não??
…

Então, surgiu uma idéia, que fez aparecer outra, que fez aparecer outra, e outra, e outra, e culminou na gente divulgando o sistema em nível nacional.

Interessante. Bem interessante. Aliás, poderia ser um ponto maravilhoso, mas vou pontuar dificuldades aqui, para todos entenderem que desenvolver a nível nacional requer um pouco mais que apenas um sistema bonito:

• Seus clientes são remotos. Seu suporte vai precisar ser remoto. Prepare-se para implantar sistemas remotamente.
• Seu help-desk está em dia? Prepare seus atendentes. Agora eles precisarão lidar com todos os tipos de cliente, ambientes muito mais heterogêneos e situações antes inimagináveis.
• Sua segurança está reforçada (parte 1)? Proteja seu código. Se trabalhar com taxa de uso, mantenha SEMPRE uma tabela bem organizada de inadimplência e mantenha contato com seus clientes. Se eles sumirem muito tempo sem explicação pode ser indício de quebra de segurança/pirataria.
• Sua segurança está reforçada (parte 2)? Lembre-se que no tradicional HTTP os pacotes são enviados sem qualquer segurança. Isto quer dizer que se o seu sistema funciona na WEB, via HTTP, as senhas, registros do banco de dados e várias outras informações trafegam livremente por aí afora. Isto pode ocorrer também em sistemas standalone, dependendo dos recursos que você usar.
• Teste. Teste novamente. Teste outra vez. Teste até não conseguir ouvir mais este termo. Depois, teste mais uma vez. Basicamente, sempre tem gente afim de causar problema. E sempre tem gente que causa problema naturalmente. Quanto maior a abrangência da sua divulgação, maior a quantidade destes dois tipos de usuários. Receita certa para aparecerem diversas falhas críticas no sistema.
• Atualização do sistema. Ponto extremamente crítico e de difícil controle aqui. Como atualizar seu sistema sem parar com os acessos?
  Bom, em um sistema WEB isto é relativamente simples. Basta atualizar o servidor e PIMBA, todos se atualizam instantaneamente. Ou não. Lembre-se dos malditos caches dos browsers, que podem lhe trazer graves problemas com atualizações nas interfaces (javascript, css, etc). No caso WEB, atualizar o banco de dados é fácil, mas interface traz problemas.
  No caso de sistemas standalone é uma situação bem mais complicada. Os seus clientes possuem cache de dados do sgbd? Se não, se todos os dados são sempre obtidos, o problema se reduz, mas se você efetua cache, ao atualizar você terá um problema com a integridade dos arquivos cache x sgbd. Cuidado com isto. Lembre-se também que recursos compartilhados (por exemplo, se o seu sistema usar TopSpeed no Clarion, Paradox no Delphi, DBASE no Clipper, etc), TODOS os acessos PRECISAM ser finalizados, e SOMENTE UM sistema deve ser responsável por atualizar o arquivo de dados. Isto foi um problema com um sistema nosso: Ao tentar acessar simultaneamente o arquivo, 3 computadores tentaram atualizar a estrutura do mesmo para a nova versão, danificando o arquivo. CUIDADO com recursos compartilhados. CUIDADO MESMO.
• Como cobrar? O ideal é se fazer um estudo da complexidade do software e, para isto, existem inúmeras técnicas. Uma delas, uma das mais bem aceitas atualmente, é a Análise de Pontos de Caso de Uso. No entanto, em algumas linguagens fica complicado montar esta análise, então como fazer?
  Bom, “cada um no seu quadrado”, o que realmente importa é achar uma forma de calcular um valor. Seja ele único para todos os clientes ou uma tabela dinâmica baseada no porte do cliente, ache seu preço e se mantenha nele. Cuidado apenas para não dar um preço A para o cliente B e um preço B para o cliente A.

Bom pessoal, no nosso caso, como o sistema é java e o back-end será inteiramente em SWING (desktop) vamos usar uma coisa chamada JWS (Java WebStart), que inicializa a aplicação por um servidor WEB, faz o download para a máquina local e sempre que o sistema local é executado, ele confere se houve atualização no servidor (e atualiza APENAS o que mudou no código). Em conjunto, vamos trabalhar com um cache volátil (temporário) de alguns tipos de registros não-críticos e vamos manter o sistema isolado do banco de dados, de forma a assegurar uma atualização bem sucedida. A segurança a gente deixa pelo framework Spring Security, até porque é da família do Spring Framework, que já estava nos planos de desenvolvimento do sistema.

No caso dos sistemas Clarion, a gente utiliza FileManager, que mantém os arquivos sempre na versão atualizada. Também utilizamos o SecWin, que permite controlar a segurança do sistema, embora não trabalhe na criptografia de dados transmitidos.

De forma geral nosso desenvolvimento de agora em diante será focado em um sistema front-end WEB e back-end standalone. Assim sendo a gente consegue uma interface bem amigável do sistema para os usuários, enquanto mantemos opções de acesso WEB para os clientes (como, por exemplo, conferir o seu próprio cadastro).

No fundo no fundo, a única dois certa é que:

“O tempo passa, o tempo voa, e a poupança Bamerindus…”
Opa, Bamerindus??

Virtualização: sucesso garantido.

Quando se pensa em servidor pensa-se em máquinas super poderosas, com vários processadores, uma enorme quantidade de memória RAM e um HD de alta velocidade.

Fato é que a maioria das empresas de pequeno e médio porte precisam de um servidor. Seja para organizar os processos, para servir de fonte de dados, para alguma aplicação já existente ou futura, para disponibilizar serviços ou meramente para falar que se tem um servidor.

O grande problema, nem sempre levado em consideração, é que em alguns casos precisa-se de mais de um servidor rodando simultaneamente. Imagine um cenário onde se precisa de um banco de dados SQL Server (Microsoft, portanto ficamos atrelados a sistemas Windows) e um sistema de VOIP (por exemplo, o Asterisk, totalmente gratuito, para Linux). Poxa, precisamos de dois servidores executando ao mesmo tempo.

Quem já comprou servidor já sofreu como eu sofri há pouco tempo: como montar um servidor balanceado. Isto porque, gente, hardware de servidor não é hardware de desktop! Servidor possui hardware bem mais robusto, especializado em se manter ON por meses sem ser interrompido, sempre focando performance e durabilidade.
Isto se reflete em um grande problema: Não existe harware de servidor barato, tampouco de menor performance. Um servidor (desses de verdade, claro) sempre vai ter uma performance extremamente superior a um desktop e, por várias vezes, superior à sua real necessidade.

Ou seja, teríamos dois servidores sub-utilizados. São dois servidores físicos consumindo energia, refrigeração, administração. Mas o pior de tudo: dois investimentos caros que estão sendo disperdiçados.

Tudo muda quando se pensa em virtualização. Basicamente, consolidação de datacenter. A empresa VMware sempre foi um destaque nesta área, embora hoje existam dezenas de ferramentas para tal finalidade.

Eu, particularmente, testei algumas disponíveis, incluindo-se:

• VMware ESXi
• Microsoft Hyper-V
• Linux + KVM
• Linux + VMware Server 2

Posso falar com sinceridade que nunca estive tão satisfeito quanto agora, depois de colocar todos os servidores da empresa em cima do ESXi.

Bom gente, eu não vou entrar em detalhes a fundo do funcionamento de cada um, nem vou descrever vantagens e desvantagens, mas de forma bem simplificada existem duas formas de virtualizar:

1. Na primeira, você cria um sistema HOST (hospedeiro) que conterá o sistema de virtualização. O sistema host é um sistema operacional e o virtualizador é, por exemplo, o VMware Server 2. A vantagem é que a instalação é sensivelmente mais compatível com diferentes hardwares, o gerenciamento pode ser feito local. Funciona bem, mas o principal público para esta solução são micro-empresas e usuários domésticos.
2. Na segunda, você usa um hypervisor. Basicamente, um virtualizador “bare-metal”. Ou seja, ao invés de um sistema operacional host (Linux, Unix, Windows, Mac, …) temos o próprio virtualizador como o host. Ele funciona diretamente no harware, sem um sistema inteiro por baixo dele. Claro que isto traz sérias restrições de compatibilidade de hardware mas também traz profundos ganhos em gerenciamento, performance, automação e, principalmente, organização.

O ESXi faz parte da segunda categoria. De certa forma o Hyper-V da Microsoft também, mas no fundo no fundo ele está em cima de um Windows Server, o que traz algumas desvantagens.

Bom, uma breve introdução do meu caminho, para que vocês possam entender pelo que passei, o motivo da minha escolha e possam se guiar quando forem montar o primeiro (ou último) servidor:

1. Tudo começa com um começo, claro. Fomos na WAZ (aqui em Belo Horizonte, a WAZ é uma loja-referência, sempre com hardware top). Compramos um servidor com as características abaixo:
1. Placa mãe Tyan Tempest I5400PM. Uma ótima placa, repleta de recursos e acessórios.
2. Processador Intel Xeon E5405 FSB1333 12MB/cache 2GHz.
3. 2GB DDR2 667 Corsair server – FBDIMM, porque estavam em falta deste tipo de memória, mas já encomendamos mais 2GB.
4. HD SataII 300GB 10.000rpm WD (WD3000HLFS), simplesmente um dos melhores HDs que eu já vi.
2. Quando o computador finalmente chegou aqui, começaram os trabahos em configurá-lo. Logicamente eu tentei Windows Server 2008. A grande pergunta foi: R2 ou não R2? Bom, testei ambos. R2 é tremendamente mais rápido e mais leve, mas está inteiramente em inglês, beta e é bem mais chato de se configurar. Demais aspectos são bem parecidos. Vale lembrar que (nossa!) no R2 o Active Directory possui um recurso de lixeira compartilhada, enquanto que na outra versão do 2008, não existe este recurso. Quase morri, principalmente porque eu não uso lixeira.
3. Depois de mais de 3 dias instalando e re-instalando Windows, aprendendo na marra o que os livros nunca ensinam, descobri alguns problemas, chatices, incompatibilidades e muito além, na minha instalação do sistema da MS. Resultado?
4. Corri então para o ESXi. O grande problema é que ele não funcionou. Simplesmente não deu boot e ponto final. Duas instalações a partir de 2 CD’s diferentes e um mesmo resultado: nada. Parti para outro sistema.
5. Resolvi adotar um Linux. Particularmente o Fedora (porque eu vou dar um curso justamente sobre Fedora em breve…).
6. Alguns dias e muitos comprimidos para dor-de-cabeça depois eu finalmente consegui deixar o Fedora 10 funcionando. O principal problema foi a união de um sistema x64 com um tal de “Bonding” (união de 2 links, por exemplo, 2 placas de rede, para funcionar como uma só em backup/failover e load-balancing). No fim das contas o Bonding funcionou, mas foi pelas metades. Ele funciona de forma bem lógica: cria-se uma placa de rede virtual, que responde a requisições diversas e possui um IP na rede. Ao usar esta placa virtual, o linux automaticamente distribui os pacotes e envia pelas placas “slave” desta placa virtual. Simples. Mas quem disse que eu consegui fazer a placa virtua APARECER? Ela estava lá mas não aparecia. O resultado foi o esperado: não consegui fazer VMware server funcionar corretamente, tampouco meus serviços diversos. Somente o próprio host se conectava à rede.
7. Algum tempo depois (enquanto isto me dediquei ao caos, perdido em uma pilha de tarefas a serem concluídas), meti na cabeça que o ESXi tinha que funcionar. Poxa, eu havia comprado um servidor. Não foi um DELL mas foi tão servidor quanto. Hardware de servidor, sem restrições. TINHA que funcionar. E? Funcionou! Opa, funcionou? Pois é, não me perguntem porque mas funcionou sem qualquer problema. Simplesmente funcionou. Parece até que a versão do ESXi mudou mas o maior detalhe é que é a mesma versão de antes… De qualquer forma, funcionou. Agora sou capaz de rodar múltiplos servidores em um ambiente totalmente automatizado, auto-gerenciável, simples e o mais legal do mundo: não requer meu deslocamento ao servidor para NADA além de LIGAR o servidor. O resto todo eu faço remotamente, inclusive instalar um sistema inteiramente novo (isso inclui a ausência de necessidade de ir no servidor para, por exemplo, colocar o CD do sistema a ser instalado).

Depois de configurar o ESXi que, milagrosamente, passou a funcionar, me surpreendi com seu desempenho. Apesar do seu gasto ligeiramente maior do que o esperado em memória (ele consome os seus quase 400MB inicialmente), ele compensa isto em vários pontos. Um deles é a praticidade de se estabelecer reservas, ou seja, quantidades mínimas que cada máquina virtual (ou conjunto delas através de um Resource Pool) vai possuir. Isto se extende também para limites máximos (tanto de memória quanto de processamento, respectivamente em MB e MHz).

Fato é que estou apaixonado pelo ESXi. No bom sentido, claro. Funciona, funciona super bem, é estável. Enfim, é um produto excelente de um clássico fornecedor de sistemas de virtualização, e o mais interessante é que é inteiramente gratuito.

Legal, não? Diminuir os custos de um datacenter incluindo não apenas os recursos físicos (hardware) mas também o investimento em software…

Bom, agora estou trabalhando em configurar melhor os servidores. Por alguma razão ainda não bem especificada estou vivendo uma redução de performance em algumas operação e, acredito eu, não estar relacionada à questão de máquinas virtuais mas sim à questão de particionamento distinto (em especial ext3 x ntfs).

Ah, vale lembrar que tudo isto está aliado a um software que funciona com máxima segurança, como todo datacenter deve ser: não se pode simplesmente desligar o host, tampouco efetuar qualquer alteração sem o devido logon. Requisitos que são deixados de lado em alguns sistemas como o Linux (claro que podemos configurar, mas é uma etapa a mais em um ambiente já complicado).

Bom pessoal, vou parando por aqui hoje.

Em breve vou comentar sobre os sistemas que experimentei aqui, apontando coisas reais que pude perceber neles. Afinal, cada sistema tem inúmeros benefícios e inúmeras desvantagens, mas o que vale mesmo são as nossas experiências com eles, não o que eles dizem saber fazer.