Monthly Archive for agosto 2008

Migração VMWare Server para Hyper-V

Aqui na Cadena nossa máquina de build é virtual. Isso é absurdamente prático e recomendo a todos. Nosso “builder” já rodou em umas 4 ou 5 máquinas host diferentes aqui, desde Linux a Windows XP e 2003 Server. Sendo que o único trabalho foi fechar a VM, copiar a pasta e abrir em outra máquina.

Essa semana compramos um novo servidor, um Core 2 Duo E8500 3.16 GHz com 4GB de RAM. Instalei o Windows Server 2008 Standard 64 bits nele e resolvi testar o Hyper-V, que é a nova tecnologia de virtualização da Microsoft.

Para minha surpresa foi muito simples migrar uma máquina do VMWare para o Hyper-V. Achei este post do Ken Schaefer que ajudou bastante. Basicamente o que fiz foi:

  1. Desinstalei o VMWare Tools da VM antes de desligá-la.
  2. Utilizei o conversor da vmToolKit para converter o disco virtual do VMWare para o formato de disco virtual da Microsoft.
  3. Criei uma nova máquina virtual no Hyper-V mandando utilizar o disco convertido.
  4. Bootei a VM e instalei o “Integration Services”, que é o VMWare Tools do Hyper-V, através do menu “Action -> Insert Integration Services Setup Disk”.

Simples assim. E já está rodando no Hyper-V perfeitamente e muito mais rápida. O tempo dos nossos builds foram reduzidos em 50%. Porém esse ganho de performance certamente está muito mais ligado ao upgrade no hardware do host do que na mudança de plataforma de virtualização.

Segue um screenshot do console de gerenciamento do Hyper-V:

Hyper-V Manager

Hyper-V Manager

SmartInspect 3.0 lançado

Uma das ferramentas que eu mais uso no dia a dia é o SmartInspect. Ele te ajuda a entender muito melhor como seu aplicativo se comporta internamente. Quando você começa a incluir log nas operações internas do seu aplicativo, você descobre que ele se comporta de forma muito diferente do que você imaginava. :)

A nova versão foi anunciada e lançada com muitas novidades.

Anunciado o Delphi 2009

Ontem foi anunciado oficialmente o Delphi 2009, que também vinha sendo conhecido como Tiburon.  Ele já está disponível para pré-venda nos EUA, mas ainda não no Brasil, pelo menos não na loja virtual da Borland/CodeGear/Embarcadero.

Para nós usuários do Delphi uma nova versão é sempre uma esperança renovada de que a ferramenta esteja melhor e nos dando mais produtividade. Entre as novidades dessa versão, estão melhorias importantes na linguagem como Generics, que para mim é a principal novidade e o que tenho esperado no Delphi há muito tempo.

Ele tras também novos controles da VCL, como o Ribbon, que serve para criar barras de tarefas estilo Office 2007. Pra quem já utiliza os componentes da DevExpress, pouco importam essas novidades. Inclusive nós já temos o Ribbon lá há muito tempo.

Existem melhorias no DataSnap, que são muito interessantes, principalmente para quem usa o DataSnap atual puro do Delphi, que depende de COM e sempre só ouvi reclamações. Digo DataSnap atual puro, pois eu utilizo o DataSnap com RemObjects para camada de comunicação, então nunca dependi do COM e nunca passei as dificuldades que isso trás.

E claro, Unicode, que praticamente nenhum desenvolvedor brasilieiro precisa, mas que é importante para que a ferramenta atender o maior mercado possível suportando qualquer conjunto de caracteres.

Junto as novidades, sempre vem um pouco de melhoria na estabilidade e performance da IDE. Isso eu diria que pra mim é um dos itens mais importantes. O meu Delphi 2007 por exemplo, ele dá pau pelo menos entre duas a três vezes por dia. São aqueles erros inexplicáveis que te obrigam a fechar a IDE e recomeçar o trabalho.

Vale a pena atualizar seus Delphi para o 2009? Na minha opinião vale. Eu com certeza atualizarei o quanto antes. Meus principais motivos são:

  • Generics vai permitir que eu elimine muito código.
  • IDE mais rápida e estável, reflete em maior produtividade do desenvolvedor.
  • Suporte ao produto. Não podemos negar que a CodeGear está se esforçando de verdade para melhorar o produto e parece que está cada vez mais na direção certa. Pare e pense qual seria o tamanho do prejuízo se você tivesse que migrar seus projetos para uma outra plataforma no caso do Delphi ser abandonado. Pensou? Pois é, você vai ver que o custo do Delphi é insignificante perto desse custo. Então temos que suportar o produto, comprando as licenças.

Mais informações sobre o anúncio:

Delphi 2009 apenas Win32 e futuro Delphi .NET

Nick Hodges, gerente de produto do Delphi, explicou em seu blog que o Delphi 2009 (Tiburon) será um produto apenas para desenvolvimento nativo, ou seja, Win32.

Acho uma ótima notícia. O Delphi Win32 ainda tem tanto potencial que merece com certeza toda a atenção possível.

Porém, o que mais me chamou a atenção foi que o .NET não foi abandonado, e um novo roadmap será divulgado em breve, além de um produto suportando as últimas tecnologias e frameworks .NET. Humm. Será que vão realmente investir pesado em uma IDE paralela ao Visual Studio ou vão finalmente desenvolver um plugin para ele?

E ao contrário dos que pensam que teriam que comprar o Visual Studio separadamente para rodar o Delphi plugin, isso não é necessário não. O Oxygene (ex Chrome) da RemObjects já vem com a IDE, ou seja, se você não tem o Visual Studio, quando instala o Oxygene, é instalado um Visual Studio apenas com a linguagem Oxygene.

A CodeGear poderia tranquilamente fazer a mesma coisa. São apenas especulações da minha parte. Mas faria muito sentido.

Quer mais um pouco de especulação? Quando a RemObjects mudou o nome do Chrome para Oxygene, disse que simplesmente não podia explicar o motivo. Disse apenas que era um bom motivo e que só faria o bem ao produto. Hum.. teria essa mudança algo a ver com as mudanças de planos da CodeGear para a plataforma .NET? Quem sabe? :)

Novo DataSnap x RemObjects SDK

O Tiburon (ou Delphi 2009) trará boas novidades em DataSnap. Isso me deixou contente, visto que uso DataSnap em todos os meus aplicativos.

Fui questionado como essas novidades se comparam ao RemObjects SDK mas ainda é um pouco cedo para comparar os dois, visto que o que vimos do novo DataSnap até agora é muito pouco. O que me parece é que o DataSnap ainda será mais simples do que o RemObjects SDK, o que não poderia ser muito diference, visto que o RO já tem muito mais tempo e maturidade.

Steve Shaughnessy deu um preview das melhorias do DataSnap em seu blog e as discussões nos comentários ficarem bem interessantes também.

De início o que ficou meio confuso para mim e para outros é que aparentemente os métodos remotos precisam ser chamados sempre como stored procedures. Os parâmetros dos métodos (tanto de entrada como saída) seriam parâmetros das “stored procedures”.

Além disso, por padrão, não existe nenhuma checagem de tipo pelo compilador, apesar que nos últimos comentários o Steve já disse que isso pode estar disponível até o lançamento do produto.

Vamos aguardar mais novidades para poder comentar melhor.