A Bitwise Magazine publicou um review do Chrome 1.5.
Monthly Archive for janeiro 2006
Ufa! Depois de algum stress, meu site já está em um novo host. Agora meus dominios estão hospedados no HostGator. Tive problemas com o host anterior, WebHost4Life, que no início parecia muito bom, mas nos últimos dias, todos os meus sites saiam do ar pelo menos uma vez ao dia e só voltavam quando eu abria um ticket de suporte. Que raios de serviço é esse?
Assinei o plano Baby do HostGator por US$ 9,95 por mês, sendo apenas US$ 0,01 no primeiro mês. Ele me permite hospedar dominios ilimitados neste plano. Quantos couberem nos 5GB de espaço em disco. 
O suporte deles também foi show de bola, tudo o que pedi foi feito em questão de minutos. Recomendo a todos que estiverem procurando um hosting de qualidade. O único detalhe é que é tudo em inglês, inclusive o suporte, portanto, aconselho bom conhecimento na lingua.
Se você tiver interesse no serviço e quiser colaborar comigo, compre usando um destes links para o HostGator, pois eu ganho uma comissão. Mas saiba que eu não estou recomendando o host por causa da comissão. Estou recomendando para que vocês não passem pela dor de cabeça que eu passei com outros hosts de má qualidade.
Acabei de descobrir que com o Delphi Pro não posso distribuir aplicativos que usem o driver Interbase do dbExpress para acessar servidores que não estejam na mesma máquina do aplicativo. Aposto que muito pouca gente sabe disso.
Qual a solução mais simples? Comprar um driver de terceiros para usar no dbExpress, pois na realidade a restrição é no driver produzido pela Borland, não no dbExpress ou no Delphi em si.
No final das contas o Pro continua sendo um ótimo negócio, pois comprando componentes de terceiros você consegue desenvolver praticamente tudo que as versões mais caras do Delphi oferecem, por um preço bem menor. Aplicativos multi-camadas por exemplo, você consegue desenvolver no Pro usando RemObjects SDK.
O Chrome é bem flexível e prático na declaração de variáveis. Ele permite que você utilize como no Delphi, declarando todas as variáveis no início de cada bloco, na seção “var”, mas também suporta o estilo C#, onde você declara a variável onde quiser.
class method ConsoleApp.Calculo;
var
A, B, C: Integer;
begin
A := 1;
B := 2;
C := B + A;
end;
class method ConsoleApp.Calculo2;
begin
var A : Integer := 1;
var B := 2;
var C := B + A;
end;
O primeiro trecho é igual ao Delphi, já o segundo usa declaração inline e inferência de tipo, ou seja, a variável B é automaticamente declarada como Integer devido ao valor que você está atribuindo a ela. O mesmo acontece para a variável C. No caso da variável A não usei inferência, especifiquei o tipo.
Qual a melhor forma? Dificil responder. Como eu procuro manter métodos sempre bem pequenos, acho que não faz muita diferença pra mim, pois não é dificil de identificar as variáveis em pequenos trechos de código. A única vantagem imediata que vejo da declaração inline é que você acaba escrevendo menos código, mas nesse caso, a diferença é muito pouca.
Desculpem por usar o blog para isso, mas estou vendendo meu GameCube no Mercado Livre. Se alguém tiver interesse, fale comigo.
Caramba, tive que desabilitar os comentários neste post porque todo mundo resolveu anunciar video-game aqui. Hahaha.
Se você ainda não está sabendo da nova interface, conhecida até agora como Ribbon, que o Office 12 trará, pode dar uma olhada nela nos screenshots disponíveis neste artigo.
Por que isso é importante para nós desenvolvedores? Porque históricamente, o Office dita a interface da maioria dos aplicativos Windows. Quem não quis deixar seu aplicativo com os menus e botões parecidos com os do Office?
Pois bem, já começaram a sair os componentes que implementam a interface. O primeiro que tomei conhecimento é o DotNetBar, disponível apenas para WinForms em .NET 2.0. Logo deve aparecer para VCL.
Você tem o Visual Studio 2005 instalado ai? Talvez testando o Chrome que venho comentando por aqui?
Não deixe de ler este artigo, que fala sobre os novos recursos para manipulação de DataSets do VS 2005. Muito legal mesmo, não conhecia isso e fiquei impressionado com o poder e facilidade.
Vou tentar fazer isso funcionar com o Firebird…
Uma das facilidades que o Chrome nos oferece é o recurso de propriedades implícitas. Veja a classe abaixo em Delphi:
Pessoa = class
private
FIdade: Integer;
FNome: String;
public
property Nome: String read FNome write FNome;
property Idade: Integer read FIdade write FIdade;
end;Em C# seria algo assim:
class Pessoa
{
private string nome;
public string Nome
{
get { return nome; }
set { nome = value; }
}
private int idade;
public int Idade
{
get { return idade; }
set { idade = value; }
}
}Em Chrome, a mesma classe, tirando proveito das propriedades implícitas, poderia ser escrita assim:
Pessoa = class
public
property Nome: String;
property Idade: Integer;
end;Ou seja, um terço do número de linhas se comparado a C# e quase a metade das linhas comparada a Delphi.
Há quase um ano atrás, eu citei aqui no meu blog a existência do Chrome. Ele é uma linguagem e compilador Object Pascal para .Net e Mono. Ele se integra no Visual Stdudio 2003 ou 2005 e lhe permite desenvolver aplicativos .NET 1.1 e 2.0 usando um Object Pascal moderno e com várias praticidades não vistas no Delphi .NET ou no C#.
Até hoje eu tinha dado pouca atenção ao Chrome, pois não via muito sentido em usar outra coisa senão C# caso eu precisasse utilizar o Visual Studio. Mas depois de dedicar um pouco de tempo para conhecer o Chrome melhor, não tenho tanta certeza que o C# seja a melhor opção para quem vem do Delphi e quer ou precisa usar Visual Studio.
Criei uma categoria aqui no blog para posts sobre o Chrome, o que pretendo fazer aos poucos, mostrando os pontos interessantes e os nem tão interessantes desta linguagem.
Uma das coisas que eu adoro no Linux, é o poder que temos no shell. Pra quem conhece, sabe do que estou falando. Talvez eu goste tanto porque isso me lembra muito a época em que o DOS era o senhor de tudo, e entravámos no Windows 3.1 apenas para rodar o Corel Draw. Nesta época, que também era dominada pelas BBS pois não existia Internet comercial no Brasil, eu usava o 4DOS, que era um shell muito mais poderoso que o MS-DOS, e me sentia um ás no teclado. 
A Microsoft simplesmente parou no tempo no que se diz a shell, o CMD que temos nos Windows de hoje é ridículo e absurdamente fraco se comparado a um shell do Linux.
Felizmente, a concorrência a está fazendo acordar e vem ai o Monad, codenome do novo shell do Windows, que promete compensar todo esse tempo de hibernação. A grande diferença e provavelmente vantagem do Monad é que ele rodará sobre a plataforma .NET e você trabalhará com objetos diretamente nos scripts e na linha de comando. Você conseguirá por exemplo executar um foreach em uma lista de arquivos acessando as propriedades de cada arquivo, que será uma instância de objeto. É um negócio realmente interessante.
A sintaxe é parecida com C#, e você pode obter mais informações aqui. Inclusive já existe uma versão beta disponível para download.
Como já comentei aqui anteriormente, iniciamos a migração de nossos aplicativos de 2 camadas para 3 camadas. Isso permitirá que os aplicativos rodem acessando os dados via Internet com ótima performance. Se você pretende fazer o mesmo com algum aplicativo seu no futuro, segue aqui algumas dicas:
Utilize apenas ClientDataSets para acesso a seus dados
O CDS é o componente chave para manipulação de dados na camada do usuário, e é ele que você vai usar em aplicativos 3 camadas. Felizmente ele é muito últil em qualquer aplicativo, então é provável que você já o utilize.
Não utilize SimpleDataSet
Este componente só funciona em 2 camadas. Ele pode parecer prático pois não te obriga a usar um DataSet, um Provider e um ClientDataSet separado, mas a praticidade não vale a pena. Não utilize este componente, pois quando for migrar para 3 camadas, terá que substitui-lo pelos 3 citados acima.
Mantenha o DataSet e o Provider juntos em um DataModule, porém separados do ClientDataSet
Ao contrário do que pensei, isso não é possível. Você precisa deixá-los no mesmo DataModule, senão o ClientDataSet não enxerga o Provider.
Evite enviar instruções SQL diretas ao banco
A camada cliente deve saber o mínimo possível sobre o banco, então não utilize comandos SQL diretos ao banco de dados a partir desta camada. Em algumas situações nós usávamos o ExecuteDirect do SQLConnection para disparar SQL direto no banco quando não precisávamos de retorno. Isso está sendo remodelado na migração 3 camadas, pois você não tem mais acesso a conexão com o banco a partir da camada cliente.
São algumas dicas que se seguidas, ajudarão bastante na migração para 3 camadas.
Firebird News. Criado pelo brasileiro Cantu, também do site FireBase.
Hoje precisei pela primeira vez colocar um aplicativo ASP.NET 2.0 em produção. Foi um pequeno aplicativo que usa Mobile WebForms, ou seja, para ser acessado por celulares e PDAs. Fiz com o Visual Studio 2005 com C#, pois no Delphi tentei usando Intraweb e só quebrei a cara. O interessante é que este aplicativo consome um WebService de um outro aplicativo meu, ASP.NET 1.1, feito em ECO no Delphi 2006, acessando Firebird.
Tudo isso rodando no mesmo servidor. Parece uma salada, não? Pois bem, quando coloquei tudo no servidor, comecei a receber a mensagem de erro:
It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.
A mensagem diz que preciso rodar aplicativos de diferentes versões do ASP.NET em processos diferentes. Acho que isso só acontece no IIS 6.
Recorri ao nosso amigo Google, e encontrei aqui passo a passo como criar um Pool diferente para meu aplicativo ASP.NET 2.0 e tudo funcionou. Fica a dica, caso alguém enfrente o mesmo problema.
Ok, os refactorings melhoraram muito no Delphi 2006 e certamente são melhores do que nada, mas os do Code Explorer são muito mais práticos e poderosos, veja dois exemplo:
Declare Variable (Delphi 2006) / Add Local Var (Code Explorer)
Tenho a seguinte linha de código:
SL := TStringList.Create;
Para eu consegui usar o refactoring do Delphi, eu preciso posicionar meu cursor no nome da variável, ou seja, no “S” ou no “L”. Se eu não posicionar no nome, ele nem habilita o refactoring. Além disso, quando eu disparo o refactoring do Delphi (Ctrl+Shift+V), ele não identifica o tipo (TStringList), sugerindo como TObject, então tenho que digitar o tipo manualmente:
Já com o Code Explorer, o cursor pode estar em qualquer lugar da linha, ou seja, você não precisa se preocupar com isso. Disparo o Add Local Var (Ctrl+L) do Code Explorer e ele já faz tudo certinho, identificando o tipo perfeitamente:
Depois disso, basta um Enter, e pronto:
Surround (Delphi 2006) / Try..Finally Wizard (Code Explorer)
Aqui é pura covardia, o Code Explorer mata a pau. Adicionei uma linha no meu código e agora tenho isso na tela:
procedure TForm10.FormCreate(Sender: TObject);
var
SL: TStringList;
begin
SL := TStringList.Create;
SL.Add('Refatorando');
end;O Delphi 2006 tem um recurso chamado Surround, que lhe permite envolver o código dentro de uma nova estrutura, entre elas, try..finally. Para eu usar isso, eu preciso selecionar minha última linha (antes do end), clicar com o botão direito, selecionar Surround e depois tryf:
O resultado mostrado abaixo precisa de uma leve formatação manual no código, e também da inclusão da instrução de liberação da variável (SL.Free):
Já no Code Explorer, basta eu posicionar na linha (não preciso nem selecionar):
E teclar Ctrl+Alt+J, olhem o resultado:
Perfeito, não? Inclusive a liberação da variável é incluída automaticamente. Show de bola!
Update: Para mais informações sobre estes refactorings do Code Explorer, dê uma olhada aqui e aqui, onde eles são melhor explicados.
Uma das ótimas melhorias do Delphi 2006 foi trazer o FastMM como seu novo gerenciador de memória. Isso tornou a IDE muito mais rápida, assim como os aplicativos compilados nela.
Uma dos recursos do FastMM é detectar vazamentos de memória (ou memory leaks), que são objetos criados pelo aplicativo, mas não propriamente destruídos.
Para sentir o poder deste recurso, crie um novo projeto VCL Win32 e no OnCreate do form principal coloque:
TStringList.Create;
Execute o aplicativo e feche. Nada acontece, mas houve um vazamento de memória porque você criou um objeto e não o destruiu. Agora adicione ao evento a seguinte linha:
ReportMemoryLeaksOnShutdown := True;
Execute o aplicativo novamente, e feche. Você verá um aviso que houve um vazamento de memória:
Esse recurso é simplesmente fantástico. Ele me ajudou a eliminar muitos memory leaks dos meus aplicativos. E não adianta. Por mais que você tenha familiaridade com criação e destruição de objetos, você sempre esquece de alguma coisa e vazamentos passam despercebidos. Com este recurso, eles não passarão mais.
Quer deixar ainda melhor? Então ao invés de deixarmos o aviso de memory leak ativado o tempo todo, talvez seja mais interessante que sejamos avisados apenas se estivermos executando o aplicativo dentro do Delphi, não? Você não vai querer usuários seus recebendo estes avisos. Para isso, basta mudar o código para:
ReportMemoryLeaksOnShutdown := DebugHook <> 0;
E se você ainda não está usando o Delphi 2006, pode usá-lo com outras versões do Delphi, só vai ter um pouco mais de trabalho. O FastMM é um projeto OpenSource mantido no SourceForge, criado e mantido pelo fera Pierre Le Riche, que inclusive ganhou o prêmio Spirit Of Delphi, na última BorCon, pela criação do FastMM.
Últimos Comentários
RSS