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
Thursday, January 17, 2008
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.
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!
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.
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
"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.
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?
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...
.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...
Subscribe to:
Posts (Atom)