Thursday, January 17, 2008

TIOBE index again!

Esta segue o link no blog do Marco Cantu. Como ele diz "está longe de ser científico" mas mostra bem o que está acontecendo! ;-)

http://blog.marcocantu.com/blog/delphi_tiobe_jan2008.html

Friday, January 11, 2008

Mais futurologia....

Entre meus colegas de trabalho sou reconhecido defensor do Delphi com relação a outras linguagens/IDE's. Hoje tive uma rápida conversa com um colega que me disse: "Lá para 2010 software nativo será como o DOS era para o Windows e rodará em modo de compatibilidade (mal e porcamente)".
Sendo assim teremos os seguintes "softwares" que rodarão "mal" e em "modo de compatibilidade":

- Todos os softwares servidores da M$ incluindo o SQL Server cujo core é 100% native code e deve ter um zilhão de linhas de C/C++ escritas!
- Aplicativos servidores da ORACLE, IBM...
- Java Virtual Machine
- .NET, FCL
- Todos os aplicativos MS-Windows - out of the box

Ou alguém acha que a ORACLE, por exemplo, irá reescrever os seus servidores de BD em VS.NET??? LOL!!!

O interessante é ver como a propaganda da MS é forte. Como é possível convencer tantos desenvolvedores que um software escrito para usar a API do sistema operacional pode ser forçado a rodar em "modo de compatibilidade" sendo que o próprio framework .NET da M$ usa exatamente a mesma API, da mesma forma???!!! Quem sabe o diagrama da arquitetura .NET ajude?

Talvez 90% dos desenvolvedores Windows que conheço precisem ler um pouco mais de informação e menos PROPAGANDA, tipo o site do Steve Trefethen AQUI.

Este camarada já passou longos anos na Borland e é um insider da M$. Então, com certeza, sabe muito mais o que fala do que os marketeiros da M$, é ou não é?

Saudações por hoje.

Unicode no Tiburon

O blog da CodeGear está bem agitado estes dias. Allen Bauer comandando! Tudo sobre Unicode no Tiburon:

http://blogs.codegear.com/abauer/2008/01/09/38845/

http://blogs.codegear.com/abauer/2008/01/09/38846/

http://blogs.codegear.com/abauer/2008/01/10/38847/

http://blogs.codegear.com/abauer/2008/01/11/38848/

O Allen fala em um dos posts: "Mudança pior aconteceu quando houve a transição de 16 bits para 32 bits, Delphi 1 para Delphi 2."

Isto é fato. Foi muito mais drástico do que agora. E mesmo assim, mais fácil do que se previa. Ao contrário da M$, que não teve a menor piedade dos desenvolvedores VB6, a Borland (CodeGear) sempre primou pela manutenção da compatibilidade.
Eu vivi esta experiência de transição de sistemas 16/32 bits e posso afirmar: Valeu cada hora de trabalho recodificando a aplicação.
E outra: "Não se pode fazer uma omelete sem quebrar os ovos", já dizia minha vovozinha - que Deus a tenha!

Tuesday, January 8, 2008

IIS e ASP.NET: +Erros no Deploy de WebServices

Mais alguns probleminhas com WebServices em ASP.NET no BDS 2006: Este pode tanto acontecer no deploy quanto no debug:

Unable to load type 'Global.TGlobal'.

ou em bom português

Não foi possível carregar o tipo 'Global.TGlobal'.

Vez por outra encontrei este erro quando tentei debugar o WebService rodando pelo IDE, usando o IIS, sendo que o diretório virtual no ISS foi criado no próprio IDE. Por default, o BDS cria uma pasta bin abaixo da pasta onde se encontra o projeto do WebService. Desta forma, ele "espera" que o assembly seja salvo nesta pasta bin.
Se não houver nenhuma configuração adicional do projeto, o assembly será salvo no mesmo diretório dos fontes, e neste caso poderá haver este erro.
Basta copiar, ou mover o assembly gerado para a subpasta bin e o aplicativo poderá ser debugado normalmente.
Convém alterar as opções do projeto direcionando o "Output dir" para esta subpasta bin.

IIS e ASP.NET: Erros no Deploy de WebServices

Criando aplicações ASP.NET no BDS 2006, me deparei com alguns erros no momento do deploy. Um deles foi:

"Server cannot access application directory "APP_DIR". The directory does not exist or is not accessible because of security settings.


Por incrível que pareça a mensagem de erro é de fato informativa, e é bem plausível que seja realmente permissão insuficiente para acessar o diretório da aplicação (APP_DIR). Logo de início dei permissões de leitura a "Everyone" (Todos) e a aplicação funcionou corretamente. Obviamente esta não é a solução ideal e de fato não é necessário conceder esta permissão tão abrangente. Basta conceder permissão de leitura na pasta da aplicação ao usuário [Machine_Name]\ASPNET, e voilá!


Ambiente de referência:
- Windows 2000 Server - SP4
- .NET Framework V 1.1.4322

Friday, January 4, 2008

Futuro do DataSnap

Conversa rápida com o John Kaster (CodeGear Internet Services Architect) no newsgroup da CG hoje:

Pergunta minha a ele: "Will DataSnap remain tied to COM?"

Resposta: "I think it's safe to answer "no" for this one. Steve (Shaughnessy) is definitely
looking at eliminating COM as a required technology DataSnap solution,
and what he has in mind is 100% feasible and achievable."
...
"What I want to see is "native" (supported by the respective
platform/language frameworks) interop among data operations, REST,
"skins", user ids, tagging, commenting, searching, and so on for all
these platforms."

Fiquei feliz! :-) O DataSnap precisa se livrar da infraestrutura COM para então alcançar outro patamar.

Agora é esperar a revisão do roadmap do Delphi que o Nick Rodges disse que sai até o fim do mes de Janeiro, e ficar de olho no que o Tiburon trará de novidade.

Thursday, January 3, 2008

As nuvens estão chegando

Amazon.com

Por US$ 288,00 / mês você pode "ter" um super servidor com

7.5 GB of memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB of instance storage
64-bit platform

*One EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor

Os pequenos DataCenters estão com os dias contados?

Wednesday, January 2, 2008

Gerenciamento de memória e Garbage Colector no .NET

Três páginas muito interessantes que garimpei em newsgroups:

.NET Memory Management and Garbage Collection

Is .NET suitable for real-time projects?

Performance .NOT, a look at .NET Memory Performance Counters

O assunto tratado é sério e me preocuparia muito se eu estivesse no meio de um grande projeto corporativo usando .NET. Vejo um monte de aplicações ASP.NET simples, Client/Server, desktop, e até mesmo utilitários escritos em .NET. Mas pouco se fala de grandes aplicações distribuídas.
Os problemas relatados nas páginas acima: Qual a "verdade"? Qual o impacto disso neste tipo de aplicação?
Vale uma investigação...