Cartão da Natal da Empresa.
Desejamos feliz natal para vocês todos!
quinta-feira, 25 de dezembro de 2008
domingo, 14 de dezembro de 2008
Recomendações de Leitura
Olá pessoal,
Depois das minhas pequenas férias no Rio, estou de volta com duas recomendações de livros que encontrei ao visitar a Siciliano no Shopping .
Esse eu ainda vou comprar pra ler, mas pelo que eu já li é indispensável para gerentes e líderes de equipes que desejam implantar o desenvolvimento ágil dentro do seu modelo de desenvolvimento de software.
O outro, é a história "do negócio de mídia e tecnologia de maior sucesso dos nossos tempos", o google, que mostra a trajetória de Larry Page e Sergey Brin, dois dos mais fantásticos personagens desta década. A Internet não seria a mesma sem eles.
...esse eu comprei, e já estou terminando. Excelente! :-)
terça-feira, 18 de novembro de 2008
Dica: Renderizando páginas HTML no ASP.NET MVC
Olá pessoal,
Nessas últimas semanas tenho feito um mergulho profundo no ASP.net MVC Beta, e confesso que estou muito entusiasmado com o resultado. Sei que cada um tem o seu gosto por paradigmas e eu não sou diferente, e nessa semana percebi que me encontrei no MVC, e posso dizer um adeus sem remorso para os WebForms.
Acho até que foi uma escolha meio tardia, tardia em função da escolha de acompanhar especificamente o MVC da Microsoft, pois talvez se tivesse experimentado o Monorail, esse adeus teria acontecido alguns meses atrás.
Por fim, recomendo este artigo do Samir Mamude . A "história" que ele conta pode representar bem o estado de espírito de uma transição.
Bom, mas vamos pra nossa dica!
Para desenvolver controllers, quase sempre você está enviando Dados e Submetendo Views, mas existem casos onde o que você quer enviar seja simples markup, HTML. Será que necessito mesmo enviar para uma ViewPage para ser processada? Hum, Não!
Até enviei um e-mail pra equipe do MVC, vamos ver o que eles respondem. Mas o que eu gostaria de colocar é que existe uma maneira talvez um pouco mais "eficiente" de exibir esses dados casos eles sejam apenas text.
Nos controllers, um dos possíveis retornos (ActionResult's) são através da propriedade Content.
public ActionResult Home()
{
return Content("Olá Mundo");
}
Até aí, tudo bem, mas você pode enviar um arquivo HTML inteiro por ele se preferir, mas seu código poderia ficar um pouco sujo, além de enfrentar problemas na separação de competências.
Então, uma alternativa interessante (O Eder achou POG :-P) , seria de criar um resource file e inserir nele todos os arquivos HTML que não necessitam de nenhum tratamento ou manipulação, ou seja, são renderizados "as is".
Dessa forma:
public ActionResult Home()
{
return Content(ContentPages.Home);
}
...e uma página HTML inteira é renderizada através de um Controller MVC. Obviamente o conceito é o mesmo para partes de uma página HTML. Talvez isso saia mais rápido do que fazer a ViewEngine processar o conteúdo de uma View, que, pelo que percebi, não difere muito de uma classe Page do WebForms em alguns aspectos.
Nessas últimas semanas tenho feito um mergulho profundo no ASP.net MVC Beta, e confesso que estou muito entusiasmado com o resultado. Sei que cada um tem o seu gosto por paradigmas e eu não sou diferente, e nessa semana percebi que me encontrei no MVC, e posso dizer um adeus sem remorso para os WebForms.
Acho até que foi uma escolha meio tardia, tardia em função da escolha de acompanhar especificamente o MVC da Microsoft, pois talvez se tivesse experimentado o Monorail, esse adeus teria acontecido alguns meses atrás.
Por fim, recomendo este artigo do Samir Mamude . A "história" que ele conta pode representar bem o estado de espírito de uma transição.
Bom, mas vamos pra nossa dica!
Para desenvolver controllers, quase sempre você está enviando Dados e Submetendo Views, mas existem casos onde o que você quer enviar seja simples markup, HTML. Será que necessito mesmo enviar para uma ViewPage para ser processada? Hum, Não!
Até enviei um e-mail pra equipe do MVC, vamos ver o que eles respondem. Mas o que eu gostaria de colocar é que existe uma maneira talvez um pouco mais "eficiente" de exibir esses dados casos eles sejam apenas text.
Nos controllers, um dos possíveis retornos (ActionResult's) são através da propriedade Content.
public ActionResult Home()
{
return Content("Olá Mundo");
}
Até aí, tudo bem, mas você pode enviar um arquivo HTML inteiro por ele se preferir, mas seu código poderia ficar um pouco sujo, além de enfrentar problemas na separação de competências.
Então, uma alternativa interessante (O Eder achou POG :-P) , seria de criar um resource file e inserir nele todos os arquivos HTML que não necessitam de nenhum tratamento ou manipulação, ou seja, são renderizados "as is".
Dessa forma:
public ActionResult Home()
{
return Content(ContentPages.Home);
}
...e uma página HTML inteira é renderizada através de um Controller MVC. Obviamente o conceito é o mesmo para partes de uma página HTML. Talvez isso saia mais rápido do que fazer a ViewEngine processar o conteúdo de uma View, que, pelo que percebi, não difere muito de uma classe Page do WebForms em alguns aspectos.
sábado, 18 de outubro de 2008
Interfaces e Extension Methods: Uma Combinação poderosa (parte 2)
Olá Pessoal,
Finalmente consegui terminar! Essa parte do post demorou um pouco porque o trabalho apertou. Espero que curtam.
Agora que vocês estão familiarizados com Extension Methods, então vale a pena mostrar do que ele é capaz na prática no sentido de facilitar e viabilizar desenhos arquiteturais antes de difícil implementação.
No nosso exemplo, a idéia é mostrar como se cria uma biblioteca de controles herdada da biblioteca padrão System.Web.UI.WebControls e adicionar aos controles uma propriedade chamada DataBinder do tipo IDataBinder.
public interface IDataBinder
{
}
public class MeuTextBoxHerdado : System.Web.UI.WebControls.TextBox
{
public IDataBinder DataBinder{ get; set; }
}
A classe que implementará a propriedade nesse cenário é o que menos irá importar. O importante é que DataBinder será um ponto onde nós poderemos pendurar Extension Methods. A idéia lembra um pouco as "Interfaces de Marcação", que são utilizada em algumas situações no ASP.NET para indicar que uma classe deve receber alguma implementação especial que será controlada por outra classe (procure saber sobre INamingContainer), só que sem a necessidade do uso de reflection.
A diferença é que o ponto de marcação não é uma classe atributo, mas sim uma propriedade, e a partir dela poderemos implementar uma gama de recursos, que poderão ser facilmente portados para outros controles. Para isso, basta que os mesmos possuam uma propriedade qualquer que seja daquele tipo.
Assim, podemos começar a construir nossa biblioteca de extension Methods.
public static BibliotecaDataBinder{
public static void BindText(this IDataBinder control, object dataSource)
{
}
public static object Read(this IDataBinder control)
{
}
...
}
Para usar, basta referenciar o namespace, e finalmente:
MeuTextBoxHerdado h = new MeuTextBoxHerdado();
h.DataBinder.BindText("Olá");
Assim, você pode usar vários métodos úteis através da propriedade. Cabe a você como arquiteto decidir quais os métodos e propriedades que a interface deve mandar implementar para ter o trabalho feito.
Nesse aspecto, dependendo do caso, sería até uma estratégia interessante manter a própria classe como implementadora da interface IDataBinder, assim, os membros da classe vão poder ser acessados diretamente pela nossa biblioteca.
Reconheço que essa parte é um pouco complicada de abstrair, mas a flexibilidade do modelo faz ele valer a pena. Com essa arquitetura, recentemente migramos do modelo WebForms para MVC com uma simples adição de uma propriedade.
Finalmente consegui terminar! Essa parte do post demorou um pouco porque o trabalho apertou. Espero que curtam.
Agora que vocês estão familiarizados com Extension Methods, então vale a pena mostrar do que ele é capaz na prática no sentido de facilitar e viabilizar desenhos arquiteturais antes de difícil implementação.
No nosso exemplo, a idéia é mostrar como se cria uma biblioteca de controles herdada da biblioteca padrão System.Web.UI.WebControls e adicionar aos controles uma propriedade chamada DataBinder do tipo IDataBinder.
public interface IDataBinder
{
}
public class MeuTextBoxHerdado : System.Web.UI.WebControls.TextBox
{
public IDataBinder DataBinder{ get; set; }
}
A classe que implementará a propriedade nesse cenário é o que menos irá importar. O importante é que DataBinder será um ponto onde nós poderemos pendurar Extension Methods. A idéia lembra um pouco as "Interfaces de Marcação", que são utilizada em algumas situações no ASP.NET para indicar que uma classe deve receber alguma implementação especial que será controlada por outra classe (procure saber sobre INamingContainer), só que sem a necessidade do uso de reflection.
A diferença é que o ponto de marcação não é uma classe atributo, mas sim uma propriedade, e a partir dela poderemos implementar uma gama de recursos, que poderão ser facilmente portados para outros controles. Para isso, basta que os mesmos possuam uma propriedade qualquer que seja daquele tipo.
Assim, podemos começar a construir nossa biblioteca de extension Methods.
public static BibliotecaDataBinder{
public static void BindText
{
}
public static object Read(this IDataBinder control)
{
}
...
}
Para usar, basta referenciar o namespace, e finalmente:
MeuTextBoxHerdado h = new MeuTextBoxHerdado();
h.DataBinder.BindText
Assim, você pode usar vários métodos úteis através da propriedade. Cabe a você como arquiteto decidir quais os métodos e propriedades que a interface deve mandar implementar para ter o trabalho feito.
Nesse aspecto, dependendo do caso, sería até uma estratégia interessante manter a própria classe como implementadora da interface IDataBinder, assim, os membros da classe vão poder ser acessados diretamente pela nossa biblioteca.
Reconheço que essa parte é um pouco complicada de abstrair, mas a flexibilidade do modelo faz ele valer a pena. Com essa arquitetura, recentemente migramos do modelo WebForms para MVC com uma simples adição de uma propriedade.
quarta-feira, 15 de outubro de 2008
Silverlight 2 Released!
Olá pessoal!
O recado de hoje é que o Silverlight 2 já está liberado na versão final. É uma ótima oportunidade de começar a experimentar novos paradigmas, desenvolvendo a próxima geração de interfaces web.
[]'s!
PS: Ainda estou escrevendo a segunda parte do post sobre Interfaces e Extension Methods ( muito trabalho essa semana e foi complicado de avançar)
O recado de hoje é que o Silverlight 2 já está liberado na versão final. É uma ótima oportunidade de começar a experimentar novos paradigmas, desenvolvendo a próxima geração de interfaces web.
[]'s!
PS: Ainda estou escrevendo a segunda parte do post sobre Interfaces e Extension Methods ( muito trabalho essa semana e foi complicado de avançar)
domingo, 5 de outubro de 2008
Interfaces e Extension Methods: uma combinação poderosa (parte 1)
Dividi esse post em três partes para que quem estiver vendo ExtensionMethods pela primeira vez possa digerir e aplicar a informação para que se siga para a segunda e terceira parte.
A primeira parte (esse post) explica os coneitos básicos de Extension Methods.
A segunda parte (que vou terminar de escrever ao longo da semana) vai procurar mostrar como implementar um modelo de validação de controles distintos através de interfaces comuns com extension methods.
A terceira parte (que pretendo escrever em breve) vai mostrar a importância do uso de extension methods com interfaces na arquitetura do linq. Procurando dissecar a estratégia usada na classe IQueryable.
Extension Methods (Vamos lá!)
Se eu pudesse enumerar um motivo para não deixar o C# 3.0 por qualquer versão anterior no .net, esse motivo seria Extension Methods. Definitivamente!
Extension Methods é uma maneira muito elegante de incorporar em classes métodos que não são própriamente da classe, mas sim de uma classe de "extensão".
Para escrever extension Methods, devemos ter em mente algumas regrinhas básicas:
Pois bem, para quem nunca viu um Extension Method, funciona da seguinte forma:
Se imagine no C# 2.0, onde você tem sua função "CpfValido" que faz a verificação de um CPF a partir de uma string de entrada e retorna bool (true se o CPF for válido):
Confesse! :-) O que você realmente gostaria de usar seria:
mas afinal, isso era impossível! EhCpf não é um método da classe string, e sim de uma classe utilitária que não tem nenhuma relação de herança com a classe string. E até esse ponto (C# 2.0) não há nenhuma forma de produzir tal efeito se não fosse através de mecanismos de herança (e no caso da classe string, que é selada, nem isso! Então como fica?). Mas o panorama mudou no C# 3.0...
na sua classe utilitária, que era algo do tipo:
Agora fica:
A primeira parte (esse post) explica os coneitos básicos de Extension Methods.
A segunda parte (que vou terminar de escrever ao longo da semana) vai procurar mostrar como implementar um modelo de validação de controles distintos através de interfaces comuns com extension methods.
A terceira parte (que pretendo escrever em breve) vai mostrar a importância do uso de extension methods com interfaces na arquitetura do linq. Procurando dissecar a estratégia usada na classe IQueryable.
Extension Methods (Vamos lá!)
Se eu pudesse enumerar um motivo para não deixar o C# 3.0 por qualquer versão anterior no .net, esse motivo seria Extension Methods. Definitivamente!
Extension Methods é uma maneira muito elegante de incorporar em classes métodos que não são própriamente da classe, mas sim de uma classe de "extensão".
Para escrever extension Methods, devemos ter em mente algumas regrinhas básicas:
- Extension Methods devem contidos em classes estáticas, ou seja, uma classe que contenha apenas membros estáticos.
- Assim, não é difícil concluir que Extension Methods são métodos estáticos. :-P
- Pela natureza dessa funcionalidade, há possibilidade de colisão de identificadores, então, o compilador C# adota padrões de precedência.
Pois bem, para quem nunca viu um Extension Method, funciona da seguinte forma:
Se imagine no C# 2.0, onde você tem sua função "CpfValido" que faz a verificação de um CPF a partir de uma string de entrada e retorna bool (true se o CPF for válido):
string cpf = "822.232.339-99";
...
if ( MinhaClasse.EhCpf(cpf) ){
//código válido...
}
Confesse! :-) O que você realmente gostaria de usar seria:
string cpf = "822.232.339-99";
...
if ( cpf.EhCpf() ){
//código válido...
}
mas afinal, isso era impossível! EhCpf não é um método da classe string, e sim de uma classe utilitária que não tem nenhuma relação de herança com a classe string. E até esse ponto (C# 2.0) não há nenhuma forma de produzir tal efeito se não fosse através de mecanismos de herança (e no caso da classe string, que é selada, nem isso! Então como fica?). Mas o panorama mudou no C# 3.0...
na sua classe utilitária, que era algo do tipo:
namespace MeuNamespace{
public static class MinhaClasse{
public static bool EhCpf(string cpf){
//Trata se eh CPF
}
}
}
Agora fica:
namespace MeuNamespace{Só isso! Agora sua classe "MinhaClasse" pode ser usada como um extension method da classe string. Mas para isso, você deve referenciar o namespace com a clausula using no contexto do código, como descrito no exemplo.
public static class MinhaClasse{
public static bool EhCpf(this string cpf){
//Trata se eh CPF
}
}
}
quarta-feira, 1 de outubro de 2008
Dica: Application Idle
Quando se fala de processamento background em .net, você pode encontrar toneladas de formas diferentes de executar operações. A grande maioria delas envolvem threads diferentes da thread principal do programa (Application Pool, ThreadStart etc...).
Mas uma maneira interessante realizar atividades que não demandam de tanta carga de processamento pode ser o uso do evento Application.Idle.
Esse evento existe porque o .net tem como saber quando a thread principal está entrando no modo Idle (ocioso), e a execução do evento permite que se faça "alguma coisinha a mais" antes de entrar no modo idle.
Tenho utilizado o idle para implementar a persistência de um buffer de log de atividades de um sistema, e o desempenho é bem satisfatório, afinal, você deixar essa operação no evento Idle significa que ela não vai ficar sendo executada toda hora, e sim quando a aplicação teoricamente "não tiver nada de mais importante pra fazer", o que já é legal:
Mas uma maneira interessante realizar atividades que não demandam de tanta carga de processamento pode ser o uso do evento Application.Idle.
Esse evento existe porque o .net tem como saber quando a thread principal está entrando no modo Idle (ocioso), e a execução do evento permite que se faça "alguma coisinha a mais" antes de entrar no modo idle.
Tenho utilizado o idle para implementar a persistência de um buffer de log de atividades de um sistema, e o desempenho é bem satisfatório, afinal, você deixar essa operação no evento Idle significa que ela não vai ficar sendo executada toda hora, e sim quando a aplicação teoricamente "não tiver nada de mais importante pra fazer", o que já é legal:
int contador = 0;
private void Form1_Load(object sender, System.EventArgs e)
{
Application.Idle += ( o, e) => { contador++ ; };
}
Esse é só um exemplo, mas aviso que nesse caso, o "Form1" em questão é o principal e
quando ele fecha, é porque a aplicação fecha, então tudo bem ter um lambda expression
aí (anônimo). Mas possivelmente não será uma boa prática para outros casos.
A razão disso está no fato de que como o evento Idle é estático, é muito importante que
no momento em que você vincula um delegate do tipo EventHandler a ele, é necesário
que você mantenha uma rotina de desvinculação preparada para retirar o evento, senão
isso pode se tornar um memory leak.int contador = 0;
EventHandler myHandler = new EventHandler(Contar);
private void Contar( object sender, EventArgs e)
{
contador++;
}
private void Form1_Load(object sender, System.EventArgs e)
{
Application.Idle += myHandler
;
}
//o código de desvinculação pode ficar associado ao destrutor
~Form1()
{
Application.Idle -= myHandler ;
}
segunda-feira, 29 de setembro de 2008
E-mail deve ser extinto até 2015, diz especialista: Comentários
Na lista vi uma profecia meio bombástica do respeitado Cezar Taurion.
Posso ter entendido mal, mas realmente é um tiro que, depois de pensar pouco, na minha opnião pode não ir no alvo.
Tentando me ver em 2015, acredito que e-mail será a base de dados com informações PESSOAIS (não públicas) mais vasta que alguem da nossa geração possa ter, já que sistemas como o gmail doutrinam isso: "arquive seu e-mail aqui e ache quando quiser através dos mecanismos de busca do google", e a maioria do pessoal da minha geração faz isso naturalmente.
Para comunicar informações em forma de broadcast (um-pra-N) para um grupo, realmente BLOGs e redes sociais já são e devem continuar sendo a melhor ferramenta pra passar esse tipo de informação em 2015.
Para colaboração, ferramentas como wiki, sharepoint são tendências, e vieram pra ficar. Principalmente no ambiente coorporativo.
E os e-mails? Ao invés de serem extintos, creio eu que servirão pra dois propósitos:
1- Estabelecer negociações tradicionais 1 a 1. Que é e sempre será uma necessidade das pessoas.
(Afinal de contas, você vai publicar no blog uma mensagem endereçada só pra um amigo seu? E vai ser fácil de achar depois tamanha a quantidade de meios de comunicação que poderão existir?)
2- Receber notificações de todos os outros serviços descritos acima. Por e-mail, você pode monitorar todos os BLOGs, ferramentas coorporativas, atualizações dos seus feeds RSS e armazenar informações de chat e até responder questionários para atualizar uma planilha. Então, sendo ele o agente concentrador, se for extinto, vamos ter que inventar outra coisa pra fazer o que ele faz e bem (o que é meio ilógico).
Posso ter entendido mal, mas realmente é um tiro que, depois de pensar pouco, na minha opnião pode não ir no alvo.
Tentando me ver em 2015, acredito que e-mail será a base de dados com informações PESSOAIS (não públicas) mais vasta que alguem da nossa geração possa ter, já que sistemas como o gmail doutrinam isso: "arquive seu e-mail aqui e ache quando quiser através dos mecanismos de busca do google", e a maioria do pessoal da minha geração faz isso naturalmente.
Para comunicar informações em forma de broadcast (um-pra-N) para um grupo, realmente BLOGs e redes sociais já são e devem continuar sendo a melhor ferramenta pra passar esse tipo de informação em 2015.
Para colaboração, ferramentas como wiki, sharepoint são tendências, e vieram pra ficar. Principalmente no ambiente coorporativo.
E os e-mails? Ao invés de serem extintos, creio eu que servirão pra dois propósitos:
1- Estabelecer negociações tradicionais 1 a 1. Que é e sempre será uma necessidade das pessoas.
(Afinal de contas, você vai publicar no blog uma mensagem endereçada só pra um amigo seu? E vai ser fácil de achar depois tamanha a quantidade de meios de comunicação que poderão existir?)
2- Receber notificações de todos os outros serviços descritos acima. Por e-mail, você pode monitorar todos os BLOGs, ferramentas coorporativas, atualizações dos seus feeds RSS e armazenar informações de chat e até responder questionários para atualizar uma planilha. Então, sendo ele o agente concentrador, se for extinto, vamos ter que inventar outra coisa pra fazer o que ele faz e bem (o que é meio ilógico).
domingo, 28 de setembro de 2008
Microsoft anuncia suporte a jQuery
Hoje saíu uma notícia muito bacana, o time do ASP.net anunciou que o jQuery, uma biblioteca javascript open source muito popular, vai ganhar suporte da Microsoft e servirá de base para a implementação de controles para o AJAX Toolkit e helper Methods Ajax para o ASP.net MVC.
Segundo o Scott Guthrie, o time do ASP.net encontrou no jQuery todas as funcionalidades que procuravam, então concluíram que não haveria a necessidade de duplicar funcionalidades, resultado: se juntaram ao time.
Para os mais céticos, vale esclarecer ainda que não haverá nenhum fork do projeto, a biblioteca será distribuída com o Visual Studio e será default para projetos utilizando ASP.net MVC, e terá amplo suporte a recursos como intelisense. A licença continuará sendo a licença MIT.
Fonte: Scott'Gu
Segundo o Scott Guthrie, o time do ASP.net encontrou no jQuery todas as funcionalidades que procuravam, então concluíram que não haveria a necessidade de duplicar funcionalidades, resultado: se juntaram ao time.
Para os mais céticos, vale esclarecer ainda que não haverá nenhum fork do projeto, a biblioteca será distribuída com o Visual Studio e será default para projetos utilizando ASP.net MVC, e terá amplo suporte a recursos como intelisense. A licença continuará sendo a licença MIT.
Fonte: Scott'Gu
Orientação a Objetos: De religião a ferramenta
Me lembro muito bem que nos primeiros anos de faculdade, as tendências rumavam para a tecnologia J2EE da Sun, em torno de uma forte linguagem que se consolidou, naquela época, que foi o Java. Isso foi entre 2002 e 2003.
Junto com a linguagem Java, o paradigma de orientação a objetos consolidou uma legião de adeptos, e é de uma parte desses adeptos principalmente que eu dirijo esse post.
Naquela epoca, embora a OO já possuísse um conjunto de regras que a delineava, alguns grupos insistiam em seguir certas doutrinas como uma religião. Cansei de ouvir alguns gurus comentando sobre features presentes no C# (delegates, partial classes, etc..) em seus comparativos inevitáveis algo como: "isso é uma implementação que foge os princípios da orientação a objetos. [ponto final]" (como se isso fosse algum demérito!) - na minha opnião, dane-se!
Afinal de contas, quem está a serviço de quem? Não me lembro de ter assinado nenhum contrato de escravidão com a OO. Além do mais, dogmas são extremamente nocivos para a inovação, pois enquanto você para de questionar algo, como você vai evoluir?
Design patterns? Será que só Gof sabem pensar, se você usa o seu padrão nas suas aplicações será que só porque você produziu, ele não é bom o bastante? Para alguns desses gurus, se não é um dos padrões altamente conhecidos, então é muito provável que você seja visto como alguem que não mereça crédito.
Semana passada eu li num artigo um comentário de um cidadão defendendo ferrenhamente que o Java se mantenha como está, utilizando o argumento de que é a implementação mais fiel da OO.
Na minha opnião, é o maior tiro no pé que o Java poderia dar (além de ser uma p... burrice). Pois isso significa parar no tempo e não se adaptar as novas tendências. Em outras palavras, suicídio.
É que tendências seriam essas?
Na minha opnião, a resposta está ficando cada vez mais fácil de ver: linguagens dinâmicas.
Não estou dizendo aqui que elas se tornarão a base de todo o código desenvolvido nas coorporações. O que eu acredito é que durante essa evolução dos últimos anos na tecnologia do desenvolvimento de software, apareceram alguns abismos causados principalmente por paradigmas distintos ( OO x ER e outros ) . Esses paradigmas necessitam de "pontes", e o uso de práticas de desenvolvimento advindas de linguagens dinâmicas atendem bem a esse propósito.
Com esse cenário, no fim de 2006 a Microsoft apresentou o a sua estratégia dentro dessa tendência, que seriam novas implementações na sua linguagem principal, o C#. Daí tivemos a chance de conhecer implementações que "dinamizaram" a linguagem com muitos elementos que são encontrados nas linguagens dinâmicas e até nos scripts, mas a grande diferença (que continuo a batendo) é a tipagem forte e a conservação de todas as características OO não como fator restritivo, mas sim funcional.
Então, se o Java tem juízo, vai acabar seguindo a tendência da mesma forma, a custo de ficar para trás na evolução das ferramentas de desenvolvimento. :-)
A bem da verdade, andei lendo em alguns fórums que features idênticas aos delegates do C# serão finalmente implementadas na próxima versão do java, a 1.7 (já é um começo, afinal de contas, qualquer linguagem que queira implementar recursos mais complexos de interação de coleções, que é a base do "Linq", necessita começar pela base: uma estrutura como um delegate ). Não duvido muito que estruturas similares a Extension Methods e Anonymous Types também venham no pacote.
Concluíndo, já estamos vendo que todas as novas funcionalidades advindas de bons feedbacks aprendidos das experiências com linguagens dinâmicas estão trazendo as linguagens de programação OO tradicionais para um novo patamar, onde a OO continua importante, mas agora sua doutrina fica em segundo plano.
Então observamos que ao longo do tempo, o que antes era visto como dogmas de uma religião ("não romper os princípios da OO!") começou a se tornar uma ferramenta. E podemos ainda concluir que a maior resistência a evolução para as novas tendências parte de quem mais defendeu os "preceitos religiosos" aqui referidos. Em termos práticos: A comunidade java tem uma ligação muito mais forte com os princípios puros da OO e Design Patterns, acredito eu que é em função disso que até agora ainda não possuem uma ferramenta que possa concorrer com o Linq no .net.
Junto com a linguagem Java, o paradigma de orientação a objetos consolidou uma legião de adeptos, e é de uma parte desses adeptos principalmente que eu dirijo esse post.
Naquela epoca, embora a OO já possuísse um conjunto de regras que a delineava, alguns grupos insistiam em seguir certas doutrinas como uma religião. Cansei de ouvir alguns gurus comentando sobre features presentes no C# (delegates, partial classes, etc..) em seus comparativos inevitáveis algo como: "isso é uma implementação que foge os princípios da orientação a objetos. [ponto final]" (como se isso fosse algum demérito!) - na minha opnião, dane-se!
Afinal de contas, quem está a serviço de quem? Não me lembro de ter assinado nenhum contrato de escravidão com a OO. Além do mais, dogmas são extremamente nocivos para a inovação, pois enquanto você para de questionar algo, como você vai evoluir?
Design patterns? Será que só Gof sabem pensar, se você usa o seu padrão nas suas aplicações será que só porque você produziu, ele não é bom o bastante? Para alguns desses gurus, se não é um dos padrões altamente conhecidos, então é muito provável que você seja visto como alguem que não mereça crédito.
Semana passada eu li num artigo um comentário de um cidadão defendendo ferrenhamente que o Java se mantenha como está, utilizando o argumento de que é a implementação mais fiel da OO.
Na minha opnião, é o maior tiro no pé que o Java poderia dar (além de ser uma p... burrice). Pois isso significa parar no tempo e não se adaptar as novas tendências. Em outras palavras, suicídio.
É que tendências seriam essas?
Na minha opnião, a resposta está ficando cada vez mais fácil de ver: linguagens dinâmicas.
Não estou dizendo aqui que elas se tornarão a base de todo o código desenvolvido nas coorporações. O que eu acredito é que durante essa evolução dos últimos anos na tecnologia do desenvolvimento de software, apareceram alguns abismos causados principalmente por paradigmas distintos ( OO x ER e outros ) . Esses paradigmas necessitam de "pontes", e o uso de práticas de desenvolvimento advindas de linguagens dinâmicas atendem bem a esse propósito.
Com esse cenário, no fim de 2006 a Microsoft apresentou o a sua estratégia dentro dessa tendência, que seriam novas implementações na sua linguagem principal, o C#. Daí tivemos a chance de conhecer implementações que "dinamizaram" a linguagem com muitos elementos que são encontrados nas linguagens dinâmicas e até nos scripts, mas a grande diferença (que continuo a batendo) é a tipagem forte e a conservação de todas as características OO não como fator restritivo, mas sim funcional.
Então, se o Java tem juízo, vai acabar seguindo a tendência da mesma forma, a custo de ficar para trás na evolução das ferramentas de desenvolvimento. :-)
A bem da verdade, andei lendo em alguns fórums que features idênticas aos delegates do C# serão finalmente implementadas na próxima versão do java, a 1.7 (já é um começo, afinal de contas, qualquer linguagem que queira implementar recursos mais complexos de interação de coleções, que é a base do "Linq", necessita começar pela base: uma estrutura como um delegate ). Não duvido muito que estruturas similares a Extension Methods e Anonymous Types também venham no pacote.
Concluíndo, já estamos vendo que todas as novas funcionalidades advindas de bons feedbacks aprendidos das experiências com linguagens dinâmicas estão trazendo as linguagens de programação OO tradicionais para um novo patamar, onde a OO continua importante, mas agora sua doutrina fica em segundo plano.
Então observamos que ao longo do tempo, o que antes era visto como dogmas de uma religião ("não romper os princípios da OO!") começou a se tornar uma ferramenta. E podemos ainda concluir que a maior resistência a evolução para as novas tendências parte de quem mais defendeu os "preceitos religiosos" aqui referidos. Em termos práticos: A comunidade java tem uma ligação muito mais forte com os princípios puros da OO e Design Patterns, acredito eu que é em função disso que até agora ainda não possuem uma ferramenta que possa concorrer com o Linq no .net.
sábado, 27 de setembro de 2008
Chrome não abre Silverlight
Quem resolveu baixar o Chrome e tentou abrir um site com conteúdo silverlight já percebeu: simplesmente o conteúdo ou não abre.
O engraçado é que apesar de não abrir, o Chrome realmente acredita que o silverlight abre, tanto que o processo do silverlight através do Silverlight.js é executado, utilizando o pipeline de processos do Chrome, etc etc.
Um ponto interessante que vale mencionar sobre a Microsoft é que o posicionamento oficial dela é de não dar suporte a produtos em beta (o que não é nada de outro mundo, e o firefox também enfrentou problemas com Silverlight quando esteve em beta, mas a versão final ficou ok).
Só que o Google vem usando o termo beta em seus produtos por anos, de uma certa forma com o objetivo de dar uma idéia de que o produto está melhorando, e assim vão deixando os seus usuários mais tolerantes a possíveis falhas.
Embora creia que essa falha específica já será corrigida na próxima versão do Chrome, isso de uma certa forma mostra que em termos práticos não haverá muita cooperação da MS (com uma certa legitimidade) com o Google no desenvolvimento de seus produtos, pelo menos enquanto forem "beta". :-)
domingo, 21 de setembro de 2008
Anders Hejlsberg
Procurando pelo Blog desse gênio para acrescentar na minha lista de feeds do google reader, acabei achando essas duas entrevistas super interessantes sobre o Anders Hejlsberg.
Pra quem não conhece, Anders é o criador de nada menos que ferramentas como o Turbo Pascal e Delphi . Contratado pela Microsoft em 2006 por um trocado ($ 40.000.000,00) para desenvolver uma linguagem de programação totalmente nova que preparasse a Microsoft para aquilo que seria o .net, o C#.
Chanel 9: Life and Times of Anders Hejlsberg (2006) e What Influenced The Development of C# ( 2004)
Ahh.. Não achei o blog dele :-/
Pra quem não conhece, Anders é o criador de nada menos que ferramentas como o Turbo Pascal e Delphi . Contratado pela Microsoft em 2006 por um trocado ($ 40.000.000,00) para desenvolver uma linguagem de programação totalmente nova que preparasse a Microsoft para aquilo que seria o .net, o C#.
Chanel 9: Life and Times of Anders Hejlsberg (2006) e What Influenced The Development of C# ( 2004)
Ahh.. Não achei o blog dele :-/
A evolução dos delegates
Ao longo das versões do C#, uma das funcionalidades que mais me reteve atenção como desenvolvedor foram Lambda Expressions. Desta forma, resolvi fazer um artigo expondo uma abordagem evolutiva sobre o tema (nada muito didático, meramente informativo):
C# 1.0
Quando tínhamos que escrever “ponteiros para uma função/método” no C# (óbvio que muitos não conhecem por esse nome, que é muito popular em C++, vou explicar melhor mais a frente), nós podíamos (e ainda podemos) adicioná-las em estruturas denominadas delegates da seguinte forma:
1- Se escreve o delegate, que é uma estrutura que funciona como um tipo, o qual aquele método vai ser vinculado, ou seja, se define uma referência com assinatura de método específica.
2- Se cria o método o qual se quer que o ponteiro aponte.
3- Com isso você pode adicionar (e remover) nessa referência qualquer método que tenha essa mesma assinatura, como se fosse uma lista de execução.
A conclusão que podemos chegar com delegates é que são mecanismos que permitem o agrupamento de vários métodos de diferentes classes para um pipeline execução. E justamente por isso, ele é utilizado em várias partes do .net framework, como threading, eventos, serialização etc.
Eventos
Como falei, no topo da estrutura de delegates está construída uma arquitetura de invocação implícita que ficou muito popular: eventos de componentes. Eventos são delegates especiais. Ele tem uma assinatura restrita que não deve retornar nada a não ser void, e só podem ser executados pela classe que os possui (classes filhas não executam diretamente eventos da classe pai). Essa especificidade é atribuída ao declarar a referência delegate a palavra chave event.
C# 2.0
As coisas ficaram um pouco mais práticas com o advento dos Anonymous Methods...
1 – Em muitos casos se deseja simplesmente executar uma operação vinculada a um evento de um componente (ex: setar visible=false no click do botão).
Isso significa que escrever um método unicamente pra fazer essa operação ser “burocracia demais”.
Pensando nisso, na versão do C# 2.0 foi criada, entre outras funcionalidades, Anonymous Methods, que é uma forma simplificada de escrever um método no contexto de um delegate:
Realmente simplificou mais, mas ainda não terminou...
C# 3.0
Tudo estava indo bem, até que apareceram essas tais lambda expressions, mas afinal, o que são lambda expressions? A resposta que mais gostei e a que uso é que é uma forma simplificada de escrever um delegate:
if ( querSaberMais?) {
goto: especificação do C# 3.0
if ( naoEntendiMuitoBem) {
Console.WriteLine(" Vou explicar com o nosso exemplo :-) ");
}
}
Na versão 2.0, criar um método anônimo para isso era a possibilidade mais ágil. Mas agora é possível proceder para resolver o mesmo problema com lambda expressions. A diferença é meramente uma questão de sintaxe:
Assim, assinar eventos simples como click’s de botão ficaram tão mais fáceis, que começei a inscrever muitos "onclicks" manualmente. Detalhe: a inferência de tipo é que faz o compilador procurar saber o tipo de "obj" e "e", o que é muito legal para quem tem dificuldades (como eu) de ficar decorando todos os XXXXEventArgs que tem poraí para cada evento diferente em função da vasta quantidade de XXXEventHandlers diferentes que os controles usam. :-)
Bom, é isso pessoal, no próximo post falarei sobre interfaces e Extension Methods, aguarde!
C# 1.0
Quando tínhamos que escrever “ponteiros para uma função/método” no C# (óbvio que muitos não conhecem por esse nome, que é muito popular em C++, vou explicar melhor mais a frente), nós podíamos (e ainda podemos) adicioná-las em estruturas denominadas delegates da seguinte forma:
1- Se escreve o delegate, que é uma estrutura que funciona como um tipo, o qual aquele método vai ser vinculado, ou seja, se define uma referência com assinatura de método específica.
2- Se cria o método o qual se quer que o ponteiro aponte.
3- Com isso você pode adicionar (e remover) nessa referência qualquer método que tenha essa mesma assinatura, como se fosse uma lista de execução.
A conclusão que podemos chegar com delegates é que são mecanismos que permitem o agrupamento de vários métodos de diferentes classes para um pipeline execução. E justamente por isso, ele é utilizado em várias partes do .net framework, como threading, eventos, serialização etc.
Eventos
Como falei, no topo da estrutura de delegates está construída uma arquitetura de invocação implícita que ficou muito popular: eventos de componentes. Eventos são delegates especiais. Ele tem uma assinatura restrita que não deve retornar nada a não ser void, e só podem ser executados pela classe que os possui (classes filhas não executam diretamente eventos da classe pai). Essa especificidade é atribuída ao declarar a referência delegate a palavra chave event.
C# 2.0
As coisas ficaram um pouco mais práticas com o advento dos Anonymous Methods...
1 – Em muitos casos se deseja simplesmente executar uma operação vinculada a um evento de um componente (ex: setar visible=false no click do botão).
Isso significa que escrever um método unicamente pra fazer essa operação ser “burocracia demais”.
Pensando nisso, na versão do C# 2.0 foi criada, entre outras funcionalidades, Anonymous Methods, que é uma forma simplificada de escrever um método no contexto de um delegate:
Realmente simplificou mais, mas ainda não terminou...
C# 3.0
Tudo estava indo bem, até que apareceram essas tais lambda expressions, mas afinal, o que são lambda expressions? A resposta que mais gostei e a que uso é que é uma forma simplificada de escrever um delegate:
if ( querSaberMais?) {
goto: especificação do C# 3.0
if ( naoEntendiMuitoBem) {
Console.WriteLine(" Vou explicar com o nosso exemplo :-) ");
}
}
Na versão 2.0, criar um método anônimo para isso era a possibilidade mais ágil. Mas agora é possível proceder para resolver o mesmo problema com lambda expressions. A diferença é meramente uma questão de sintaxe:
Assim, assinar eventos simples como click’s de botão ficaram tão mais fáceis, que começei a inscrever muitos "onclicks" manualmente. Detalhe: a inferência de tipo é que faz o compilador procurar saber o tipo de "obj" e "e", o que é muito legal para quem tem dificuldades (como eu) de ficar decorando todos os XXXXEventArgs que tem poraí para cada evento diferente em função da vasta quantidade de XXXEventHandlers diferentes que os controles usam. :-)
Bom, é isso pessoal, no próximo post falarei sobre interfaces e Extension Methods, aguarde!
terça-feira, 16 de setembro de 2008
Segurança no Mercado Livre
Olá pessoal, hoje recebi dois e-mails que me causaram um susto a princípio:
Um ataque bem feito, por sinal. Afinal de contas, foi usado um domínio "mercadolivre.com" entre outras coisas.
Muita gente deve cair, entrar com login e senha e entregar a senha para o cracker.
Tomem cuidado com essa.
Um ataque bem feito, por sinal. Afinal de contas, foi usado um domínio "mercadolivre.com" entre outras coisas.
Muita gente deve cair, entrar com login e senha e entregar a senha para o cracker.
Tomem cuidado com essa.
sexta-feira, 12 de setembro de 2008
Chrome usa código Open Souce da Microsoft em sua implementação
Essa semana o Scott Hanselman nos presenteou com um post muito legal sobre o Chrome, que faz parte do que ele chama de "jornada de leitura de código para se tornar um programador melhor" e ele observou algumas coisas interessantes na implementação do Chrome.
Uma delas é que o Chrome usa uma biblioteca que denominada Open Source Windows Template Library, para executar algumas macros e mapear algumas funcionalidades do sistema.
A WTL é uma versão "lightweight" da biblioteca MFC (Microsoft Foundation Classes) escrita em C++.
Além da WTL, que foi liberada como open source em 2004, o projeto "Chromium" utiliza mais de 20 outros componentes open source de terceiros.
Outras coisas interessantes que foram achadas:
Uma delas é que o Chrome usa uma biblioteca que denominada Open Source Windows Template Library, para executar algumas macros e mapear algumas funcionalidades do sistema.
A WTL é uma versão "lightweight" da biblioteca MFC (Microsoft Foundation Classes) escrita em C++.
Além da WTL, que foi liberada como open source em 2004, o projeto "Chromium" utiliza mais de 20 outros componentes open source de terceiros.
Outras coisas interessantes que foram achadas:
"// Completely undocumented from Microsoft. You can find this information by
// disassembling Vista's SP1 kernel32.dll with your favorite disassembler.
enum PROCESS_INFORMATION_CLASS {
ProcessExecuteFlags = 0x22,
}"
Mas afinal, é por uma boa causa. (Segundo Hanselman, isso permite que o browser fique mais seguro nos sistemas operacionais Windows), apesar de que a "documentação inexistente" não é tão inexistente assim. :-) E também tem aqui , e aqui.
Se quiser ler o post na íntegra, acesse aqui.
E-Tinta
Direto do "De volta para o Futuro 4?": e-Ink :-)
É realidade, e é uma edição especial de aniversário de uma revista nos Estados Unidos.
É gente, daqui a pouco aparecem uns carros voadores também poraí :-D
É realidade, e é uma edição especial de aniversário de uma revista nos Estados Unidos.
É gente, daqui a pouco aparecem uns carros voadores também poraí :-D
quinta-feira, 11 de setembro de 2008
Dica (velha) da Semana: Google Reader
Não posso ser considerado um early adopter no que se diz respeito a software (com exceção dos que eu trabalho diretamente, .net, MVC, C#, Visual Studio etc.. ), então alguns podem achar esse post meio fora do tempo.
Nas últimas semanas tenho percebido que acesso muias informações que poderiam ser visualizadas através de uma ferramenta visualizadora de RSS (que eu sempre ouvia falar, mas nunca usei). Daí, já tinha lido que o Google Reader era uma boa ferramenta boa para visualizar conteúdo de blogs, mas nunca me motivei a usá-lo.
Essa semana resolvi experimentar, e não me arrependi. Exelente programa. Rapidamente inseri as minhas principas fontes de informação
Pra quem não conhece, o google reader centraliza em uma interface todos os seus RSSs dentro de uma página Web. Assim, você pode ter em apenas um site todas as informações que você acessa com mais frequência em uma página.
Como alguem ligado em tecnologia, me sinto na idade da pedra em descobrir isso apenas agora. Mas fazer o quê, né? :-P
[]'s!
Nas últimas semanas tenho percebido que acesso muias informações que poderiam ser visualizadas através de uma ferramenta visualizadora de RSS (que eu sempre ouvia falar, mas nunca usei). Daí, já tinha lido que o Google Reader era uma boa ferramenta boa para visualizar conteúdo de blogs, mas nunca me motivei a usá-lo.
Essa semana resolvi experimentar, e não me arrependi. Exelente programa. Rapidamente inseri as minhas principas fontes de informação
Pra quem não conhece, o google reader centraliza em uma interface todos os seus RSSs dentro de uma página Web. Assim, você pode ter em apenas um site todas as informações que você acessa com mais frequência em uma página.
Como alguem ligado em tecnologia, me sinto na idade da pedra em descobrir isso apenas agora. Mas fazer o quê, né? :-P
[]'s!
Ponto para o Google
Sobre a questão dos termos de uso dos produtos do Google, de certa forma esse gesto mostra a boa fé do pessoal de Mountain View:
http://googleblog.blogspot.com/2008/09/update-to-google-chromes-terms-of.html
[]'s!
http://googleblog.blogspot.com/2008/09/update-to-google-chromes-terms-of.html
[]'s!
quarta-feira, 10 de setembro de 2008
Nova Série no Blog: "Falha Nossa"
Vou criar uma série "falha nossa" :)
Com o post "Oops" resolvi dar continuidade e criar uma série "Falha nossa" de sites importantes na Web, divulgando indisponibilidades e falhas nos sistemas Web que todos nós usamos e conhecemos.
E na segunda edição, temos o Banco do Brasil e seus servidores rodando IBM WebSphere, com um clássico Erro 500 :-)
É só dar o reset nesse servidor de $ 1.000.......000,00 que ele volta ao ar :-)
Com o post "Oops" resolvi dar continuidade e criar uma série "Falha nossa" de sites importantes na Web, divulgando indisponibilidades e falhas nos sistemas Web que todos nós usamos e conhecemos.
E na segunda edição, temos o Banco do Brasil e seus servidores rodando IBM WebSphere, com um clássico Erro 500 :-)
É só dar o reset nesse servidor de $ 1.000.......000,00 que ele volta ao ar :-)
segunda-feira, 8 de setembro de 2008
Firefox 3 - Primeiras Impressões
Recentemente baixei o FF 3 para usar definitivamente. Achei vários recursos melhorados, principalmente na barra de endereços, que ficou mais inteligente em relação ao FF 2. Mas de cara, a frequência que eu recorria ao IE7 por questão de bugs e travamentos em sites específicos diminuíram bastante. O visual também ficou mais clean, e as abas abrem de forma smoothless com efeitos legais.
Não achei (nem sei se existe) a função para abrir a aba ao lado da aba que a originou, como no IE 7 e IE 8 beta. Quando você tem mais de 10 abas abertas, explorando a primeira e tentar abrir uma nova aba, vai ter que percorrer até a 11ª.
No meu caso, a única bola na trave mesmo foi o firebug. Que não é compatível com a nova versão, e o plugin da nova versão está no beta. Aliás, se eu soubesse disso, nem teria trocado, pois como desenvolvedor web, uso bastante o firebug. Apesar do beta, preferi não arriscar.
Não achei (nem sei se existe) a função para abrir a aba ao lado da aba que a originou, como no IE 7 e IE 8 beta. Quando você tem mais de 10 abas abertas, explorando a primeira e tentar abrir uma nova aba, vai ter que percorrer até a 11ª.
No meu caso, a única bola na trave mesmo foi o firebug. Que não é compatível com a nova versão, e o plugin da nova versão está no beta. Aliás, se eu soubesse disso, nem teria trocado, pois como desenvolvedor web, uso bastante o firebug. Apesar do beta, preferi não arriscar.
domingo, 7 de setembro de 2008
Strong typing com jeito de weak typing no C#
Pegando o gancho no último post sobre Javascript:
Acredito que o leitor deve ter percebido que uma coisa que pessoalmente não me agrada (com raríssimas exceções em casos específicos) são linguagens de programação que encorajam que seus tipos sejam "weakly typed"(fracamente tipados) .
A bem da verdade, produzir scripts que necessitam ligar um aplicativo, passar parâmetros de datas pra lá e pra cá, tarefas que realmente não necessitam propriamente de uma linguagem de programação robusta, basicamente uma linguagem dinâmica de script é o suficiente.
Agora quando você necessita de uma linguagem que, além de ser facilmente legível e ágil como as linguagens dinâmicas, mas que permita um encadeamento lógico necessário para se construir blocos de código estruturais, internos aos aplicativos, onde processo de construção necessita de uma abordagem diferenciada. Aí não há como dizer que tipagem forte não representa a opção mais sensata.
Alguns argumentos em favor disso:
- A gerência da memória de dados é simplificada, afinal, quem define os tipos é o programador (não estou contando com reflection). Geralmente numa linguagem dinâmica, o tipo muda de acordo com o valor da variável, e é necessária uma estrutura extra pra cuidar desse processo.
- Os recursos de intelisense ficam simplificados na implementação e 100% precisos, nada de “sugestões”. O javascript e outras linguagens sofrem bastante com esse problema.
- Aumenta a facilidade de leitura, pois você já consegue identificar o tipo pela declaração.
- A tipagem forte permite a você garantir que problemas inerentes ao tipo (conversões, chamadas de métodos, etc) não serão passados para a versão final do programa, uma vez que esse modelo também é efetivo contra a filtragem de erros e tempo de compilação/verificação de sintaxe.
No C# 3.0 conseguiu-se um meio termo muito interessante entre os principais argumentos de quem tem preferência por tipagem fraca (principalmente referidas a escrita) mas mantendo a solidez do modelo fortemente tipado.
Type Inference (Inferência de Tipo)
Observe:
Uma novidade no C# é a nova sintaxe para deixar que o compilador infira para você o tipo do objeto, com a palavra reservada var.
Na prática, o compilador (e o intelisense também) inferem que você inicializou o objeto com o tipo int, então o tipo daquela referência é int.
Datalhe: se você for querer passar para a variável, após o momento da inicialização algum valor que não seja do tipo inferido, ocorre um erro de compilação.
Type Inference + Anonymous Types
Mas se tem alguem ainda insatisfeito porque adoram o jeito "JSON" de programar das linguagens dinâmicas, saibam que o C# incorporou na sua versão 3.0 uma forma bastante interessante de declaração de dados:
O tipo é anônimo, mas é um tipo forte,o intelisense mostra isso: podemos acessar as variáveis internas do tipo anônimo sem delongas.
Conclusão
Embora uma implementação de linguagens com tipagem fraca careçam de alguns elementos importantes para o processo de desenvolvimento de software básico, existem princípios que podem ser bem aproveitados em linguagens como C# a fim de torná-la uma linguagem completa sem aumento de complexidade.
sexta-feira, 5 de setembro de 2008
Javascript Engines Vs. Silverlight 2
Com o lançamento do Chrome e com o alpha da versão 3.1 do Firefox, tem se observado que as engines javascript tem feito o IE 8 comer poeira.
Esse aumento de velocidade tem uma razão bem simples: o javascript começa a ter características de um programa compilado em detrimento do modelo interpretado. Podemos dizer que será o novo paradigma para engines javascript dos browsers modernos.
V8 e Minefield (engines javascript do Chrome e do FF respectivamente) são engines que encabeçam esse novo paradigma, onde código javascript é compilado. Isso é uma evolução que não existe no IE 8 , pelo menos não nos testes (o que pode fazer parecer que o IE se isolou), não concordo, e estou incrédulo se ninguem na MS não acompanha a algum tempo o Minefield, afinal, não é um projeto de 10 dias atrás, é um projeto que já tem bastante história inclusive.
So que no caso da MS o que uns vêem como inconpetência ou falta de criatividade, eu vejo como estratégia. Afinal você tem que ser realmente ingênuo para acreditar que a MS não focaria numa engine que consiga atingir os mesmos resultados simplesmente por "falta de criatividade" em função do isolamento. É como achar que desenvolvedores MS nunca tiveram história dentro do Open Source: balela. Desenvolveram muito mais projetos Open Source do que muitos atuantes defensores do Software Livre (não quero levantar polêmica, mas é uma verdade).
Mas então porquê não focar no javascript? Vamos investigar:
Olhem esse comentário:
http://www.udm4.com/forum/showthread.php?t=696
Chris Wilson, arquiteto do IE, dizendo que o javascript tem que ficar como está??
Isso quer dizer que a MS está procurando meios de embarcar no browser tecnologia necessária para rodar aplicações WEB. Bingo!
Ela procurou focar num subset do .net framework que terá o mesmo princípio de compilação de código, mas não de javascript APENAS (Silverlight 1), mas de qualquer linguagem do .net framework. Então, é bem simples o ponto: enquanto o Google corre pro javascript, a MS vai correr por fora com o Silverlight 2.
Eu não sei sobre você, leitor, mas frequentemente sou obrigado a trabalhar em códigos javascript é visível que a linguagem carece de uma estrutura sólida para ser uma linguagem de desenvolvimento de um framework (tanto é verdade que o próprio Brendan Eich chefe da divisão de tecnologia da Mozilla quer remodelar completamente o javascript pra próxima versão).
E sejamos racionais: se eu, desenvolvedor .net, pudesse trabalhar em C# no cliente, assim como já trabalho no servidor, seria muito melhor, e isso será feito! Programar no cliente com C#, manipulando DOM, e fazendo tudo aquilo que você faria com javascript, e com o desempenho de uma tecnologia também compilada, com o mesmo ganho de performance das novas engines javascript. Aí se vai ver aplicações cada vez mais ricas na Web.
Vamos ver se essas previsões se concretizam, os dados estão rolando.
Esse aumento de velocidade tem uma razão bem simples: o javascript começa a ter características de um programa compilado em detrimento do modelo interpretado. Podemos dizer que será o novo paradigma para engines javascript dos browsers modernos.
V8 e Minefield (engines javascript do Chrome e do FF respectivamente) são engines que encabeçam esse novo paradigma, onde código javascript é compilado. Isso é uma evolução que não existe no IE 8 , pelo menos não nos testes (o que pode fazer parecer que o IE se isolou), não concordo, e estou incrédulo se ninguem na MS não acompanha a algum tempo o Minefield, afinal, não é um projeto de 10 dias atrás, é um projeto que já tem bastante história inclusive.
So que no caso da MS o que uns vêem como inconpetência ou falta de criatividade, eu vejo como estratégia. Afinal você tem que ser realmente ingênuo para acreditar que a MS não focaria numa engine que consiga atingir os mesmos resultados simplesmente por "falta de criatividade" em função do isolamento. É como achar que desenvolvedores MS nunca tiveram história dentro do Open Source: balela. Desenvolveram muito mais projetos Open Source do que muitos atuantes defensores do Software Livre (não quero levantar polêmica, mas é uma verdade).
Mas então porquê não focar no javascript? Vamos investigar:
Olhem esse comentário:
http://www.udm4.com/forum/showthread.php?t=696
Chris Wilson, arquiteto do IE, dizendo que o javascript tem que ficar como está??
Isso quer dizer que a MS está procurando meios de embarcar no browser tecnologia necessária para rodar aplicações WEB. Bingo!
Ela procurou focar num subset do .net framework que terá o mesmo princípio de compilação de código, mas não de javascript APENAS (Silverlight 1), mas de qualquer linguagem do .net framework. Então, é bem simples o ponto: enquanto o Google corre pro javascript, a MS vai correr por fora com o Silverlight 2.
Eu não sei sobre você, leitor, mas frequentemente sou obrigado a trabalhar em códigos javascript é visível que a linguagem carece de uma estrutura sólida para ser uma linguagem de desenvolvimento de um framework (tanto é verdade que o próprio Brendan Eich chefe da divisão de tecnologia da Mozilla quer remodelar completamente o javascript pra próxima versão).
E sejamos racionais: se eu, desenvolvedor .net, pudesse trabalhar em C# no cliente, assim como já trabalho no servidor, seria muito melhor, e isso será feito! Programar no cliente com C#, manipulando DOM, e fazendo tudo aquilo que você faria com javascript, e com o desempenho de uma tecnologia também compilada, com o mesmo ganho de performance das novas engines javascript. Aí se vai ver aplicações cada vez mais ricas na Web.
Vamos ver se essas previsões se concretizam, os dados estão rolando.
quinta-feira, 4 de setembro de 2008
Vulnerabilidades no Chrome
http://ultimas-noticias.org/tecnologia/vulnerabilidade-no-google-chrome-expoe-usuarios
Parece que um IE ganhou um forte concorrente... em todos os sentidos :-)
Brincadeiras a parte, essa vai ser uma experiência muito interessante porque vai nos permitir
observar como as duas empresas (Google e Microsoft) se comportam com relação a tratamento de vulnerabilidades em seus aplicativos. Varrer para debaixo do tapete pode não ser mais uma opção por questão de concorrência.
Outro aspecto interessante que observo é que o Chrome será muito mais visado do que o Firefox e quase tão visado quanto o IE, então será um bom laboratório para validar toda a ideologia open source sobre qualidade, etc etc etc. (Eu disse open source! Não Software Livre!).
Minha aposta é que esse jogo vai ficar empatado.
Acredito que a credibilidade de uma empresa do mercado de software depende muito pouco dos bugs (a MS teve um tempo que abusou, mas está muito melhor). O que importa mesmo é como e quão rápido a empresa reage para corrigir as falhas. Isso gera a segurança necessária para o cliente aderir uma solução. A transparência também conta.
Parece que um IE ganhou um forte concorrente... em todos os sentidos :-)
Brincadeiras a parte, essa vai ser uma experiência muito interessante porque vai nos permitir
observar como as duas empresas (Google e Microsoft) se comportam com relação a tratamento de vulnerabilidades em seus aplicativos. Varrer para debaixo do tapete pode não ser mais uma opção por questão de concorrência.
Outro aspecto interessante que observo é que o Chrome será muito mais visado do que o Firefox e quase tão visado quanto o IE, então será um bom laboratório para validar toda a ideologia open source sobre qualidade, etc etc etc. (Eu disse open source! Não Software Livre!).
Minha aposta é que esse jogo vai ficar empatado.
Acredito que a credibilidade de uma empresa do mercado de software depende muito pouco dos bugs (a MS teve um tempo que abusou, mas está muito melhor). O que importa mesmo é como e quão rápido a empresa reage para corrigir as falhas. Isso gera a segurança necessária para o cliente aderir uma solução. A transparência também conta.
quarta-feira, 3 de setembro de 2008
Como (não) lidar com DataBinding Bugs
Estudando a fundo ADO.net para windows forms, percebo algumas coisas muito chatas dentro da Microsoft. Principalmente na forma como se encara pedidos para corrigir bugs incrivelmente simples de solucionar e que poderiam estar no .net 3.5 SP1.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=263812&wa=wsignin1.0
Aliás, falando de Bugs, Windows Forms DataBinding no .net está infestado deles, é como um campo minado: funciona aquilo que está nos exemplos do MSDN e um pouco mais, mas se você quiser entrar a fundo, vai ter que lidar com alguns workarounds. Funciona, mas existem tweeks delicados.
Toda vez que vejo um link para esse site do programa connect, nunca tenho sorte, todos os bugs realmente reconhecidos pela corp ficam marcados como fechados e nao solucionados.https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=263812&wa=wsignin1.0
O desenvolvedor que postou esse bug ainda se deu ao trabalho de fornecer a solução, mas vejam a resposta do funcionário da MS.
“Para garantir nossos releases futuros na mais alta qualidade, estabilidade e facilidade de instalação, nós estamos evitando realizar mudanças arquiteturais significativas em algumas partes do produto. Baseada em nossa investigação, a correção mais indicada requereria tais mudanças”
“To ensure our next release is of high quality, stable and easy to install we are refraining from making significant architectural changes in some parts of the product. Based on our investigation, the most reasonable fix for this bug would require such changes.”
Arquiteturais significativas??? É só trocar um método pelo outro, pois a implementação que foi realizada não contempla interfaces, e a proposta de solução contempla.
terça-feira, 2 de setembro de 2008
Oops
Alguém esqueceu de setar custom errors... :-) Prato cheio para hackers...
Será que o trace tá ligado também?
ASP.NET MVC Preview 5
Saindo do forno essa semana está o Preview 5 do ASP.NET MVC.
O Projeto caminha com um numero de inovações cada vez maior, embora num nível de abstração superior a dos primeiros previews. Pouca coisa mudou na estrutura. O time começa a preparar agora as funcionalidades de alto nível. Ainda não chegamos no AJAX, mas funcionalidades como validação, formas melhores de escrever código e novos auxílios necessários para o controle de estado estão contemplados.
Uma coisa muito interessante é a criação de Model Binders, que tornam o processo de binding de dados vindos de um formulário web bastante extensíveis, com muito pouca linha de código escrita. Abaixo está um dos três modos (esse é inline) que possibilitam o controler validar dados de entrada.
Fonte: Blog do Scott'Gu.
Vale a pena ler o blog do Scott'Gu (que voltou de férias) e conferir as últimas novidades.
Um grande abraço!
O Projeto caminha com um numero de inovações cada vez maior, embora num nível de abstração superior a dos primeiros previews. Pouca coisa mudou na estrutura. O time começa a preparar agora as funcionalidades de alto nível. Ainda não chegamos no AJAX, mas funcionalidades como validação, formas melhores de escrever código e novos auxílios necessários para o controle de estado estão contemplados.
Uma coisa muito interessante é a criação de Model Binders, que tornam o processo de binding de dados vindos de um formulário web bastante extensíveis, com muito pouca linha de código escrita. Abaixo está um dos três modos (esse é inline) que possibilitam o controler validar dados de entrada.
Fonte: Blog do Scott'Gu.Vale a pena ler o blog do Scott'Gu (que voltou de férias) e conferir as últimas novidades.
Um grande abraço!
terça-feira, 26 de agosto de 2008
Community Zone 2008
Olá galera.
Esse fim de semana a comunidade curtiu o Community Zone. O evento foi bacana pacas, deu pra ver, conversar e trocar idéias com o pessoal que faz e acontece nas comunidades. Este ano, a realizou paralelamente o encontro dos MSPs (não sei o nome do evento).
Muitas idéias rolaram nas mesas redondas sobre como ajudar a Microsoft a atingir um grau de adesão maior as tecnologias. Achei extremamente produtiva a conversa com o Danilo Boldini e o Alexandre Prado na mesa de Open Source, procurando sempre buscar alternativas para expor da melhor forma as iniciativas de interoperabilidade da Microsoft. Se nossos posicionamentos forem realmente ouvidos, muita coisa começará a mudar pelo MSDN e no TechNet. Sugerimos a utilizarem como referência o modelo de sucesso do portal http://asp.net.
Conheci muita gente legal das comunidades no evento e vou mandar um abraço especial pro pessoal que eu conheci, principalmente pra "equipe 5" :-), para o André Luis Cerosi, o Bruno Velaz, Rodrigo Kono, Marco Aurélio de BH , o Gustavo de Campo Grande, Felício de Recife e o meu grande conterrâneo Emílio Mansur. Abração pra vcs!
Agora, perceberam uma coisa na Foto? Quem e o cara que mais ocupou espaço nessa foto? Tinha que ser o Jenner mesmo né? :-))))
quinta-feira, 31 de julho de 2008
Dissecando Win Forms Binding e BindingSource
Navegando pela internet procurando informações sobre o funcionamento de binding em Windows Forms (que é um pouco diferente do ASP.net) encontrei uma joia rara no code project, com direito a comentários sobre o funcionamento interno dos recursos do binding source. Para quem quer se aprofundar no assunto, é imperdível.
http://www.codeproject.com/KB/miscctrl/databinding_tutorial.aspx
Realmente é uma obra de um doente, deus dos nerds, mas quem disse que ele não é? Afinal, quem começa a desenvolver aos 11 anos (ele diz isso no profile dele) não pode ser considerado um cara normal!
Eu estava jogando bola e empinando papagaio quando eu tinha 11 anos. :-)
http://www.codeproject.com/KB/miscctrl/databinding_tutorial.aspx
Realmente é uma obra de um doente, deus dos nerds, mas quem disse que ele não é? Afinal, quem começa a desenvolver aos 11 anos (ele diz isso no profile dele) não pode ser considerado um cara normal!
Eu estava jogando bola e empinando papagaio quando eu tinha 11 anos. :-)
sábado, 19 de julho de 2008
ASP.NET MVC (Melhores momentos)
Olá pessoal!
Depois de um bom tempo sem blogar, agora, formado :-)
surgiu mais tempo para retormar alguns projetos, e um deles é o blog.
Nesse post, vou mudar um pouco o foco e falar sobre desenvolvimento MVC. Que é um modelo muito usado em projetos Open-Source:
http://en.wikipedia.org/wiki/Model-view-controller
Vendo o crescimento de plataformas como o Rubi-on-Rails baseados nesse padrão arquitetural, a Microsoft se preparou logo para a criação de um padrão de desenvolvimento Web que atendesse a esse público e criou o ASP.NET MVC. Vale atentar para o fato de que já existe um padrão MVC para .NET: o MonoRail.
Como nos últimos tempos muita gente tem falado sobre MVC, resolvi preparar um guia de links para intruduzir as pessoas nessa tecnologia e apresentar blogs que falam sobre o tema:
Considerações iniciais sobre o ASP.NET MVC Framework (Ricardo Oneda): http://www.linhadecodigo.com.br/Artigo.aspx?id=1602
Desvendando o MVC (Ricardo Oneda):
http://www.linhadecodigo.com/Artigo.aspx?id=1634
Criando Aplicativos Web Sem WebForms (Chris Tavares):
http://msdn.microsoft.com/pt-br/magazine/cc337884.aspx
Bom, depois desses artigos, muita coisa rolou no desenvolvimento do projeto ASP.NET MVC. Vieram os Previews 2 e 3, e nos últimos dias, liberaram o preview 4, e segundo os comentários do Scott Guthrie ( o Beta 1 não deve demorar muito ).
Para acompanhar o que há de mais quente nessa tecnologia, o blog dos Scotts (o Guthire e o Hansellman) são as melhores fontes de informações. Um com as novidades e alguns tutoriais, e o outro com vídeos e aplicações completas.
Scott Gu
http://weblogs.asp.net/scottgu/search.aspx?q=MVC&o=Relevance
Scott Hanselman
http://www.hanselman.com/blog/
Vale lembrar que se você gosta de WebForms e "não quer se separar dele", não se preocupe, os dois modelos coexistirão.
O que ninguem ainda sabe é se o ASP.NET vai sustentar duas bibliotecas de controles diferentes ou se os projetos MVC e WebForms convergirão nesse ponto.
Acho complicado unir as duas tecnologias, afinal, o comportamento de um System.Web.UI.Controls.TextBox (com viewstate e tudo mais) seria um pouco diferente no MVC, já que o viewstate não é suportado, e todo o ciclo de vida de um WebForm não é seguido dentro do padrão MVC. Talvez eles mantenham as tags "asp:" por questões de portabilidade de código, mas seu funcionamento interno será distindo. Em paralelo a isso, o MVC tem implementado uma coletânea de ExtensionMethods denominados HtmlHelper methods para renderizar controles. Nesse ponto, voltamos a era ASP.
Outra coisa que intriga um pouco é a forma como o time do projeto ASP.NET MVC vai lidar com AJAX, que foi uma das grandes investidas do ASP.NET 3.5 e mantém uma comunidade atuante, mas não é compatível com MVC. Acredito que o MVC vai procurar ser "plugável" nesse ponto, mas que vai passar a bola para o ASP.NET AJAX através de alguns "açúcares sintáticos". Se eu pudesse apostar, diria que eles vão utilizar um novo recurso denominado Filters Interceptors para implementar funcionalidade ajax nos Controllers, mas tenho grande curiosidade em ver como as views vão tratar isso.
O grande problema que envolve o AJAX é que ele pode desvirtuar a filosofia MVC se ele aproximar demais a View dos Controlers. Afinal, Em teoria, um controller deve ser "agnóstico" quanto a views. E o ajax é uma tecnologia que funciona nas views e não deveria, em tese, ter qualquer relação com os controllers clientes, mas não acredito que tenha um meio de descascar esse abacaxi facilmente.
Para não dizer que tudo são flores, indico também a leitura de um artigo do Dennes torres apresentando sua análise sobre o padrão:
http://www.devaspnet.com.br/colunas/coluna0136.aspx
Eu não concordo em tudo do que ele fala, principalmente na conclusão, acredito que grandes projetos tem um potencial de serem melhor escritos em MVC do que WebForms através de TDD, mas acho uma leitura importante para manter um olhar crítico sobre a tecnologia e não se encantar apenas por ser novidade, em outras palavras, manter seus pés no chão. :-)
Até a Próxima!
Depois de um bom tempo sem blogar, agora, formado :-)
surgiu mais tempo para retormar alguns projetos, e um deles é o blog.
Nesse post, vou mudar um pouco o foco e falar sobre desenvolvimento MVC. Que é um modelo muito usado em projetos Open-Source:
http://en.wikipedia.org/wiki/Model-view-controller
Vendo o crescimento de plataformas como o Rubi-on-Rails baseados nesse padrão arquitetural, a Microsoft se preparou logo para a criação de um padrão de desenvolvimento Web que atendesse a esse público e criou o ASP.NET MVC. Vale atentar para o fato de que já existe um padrão MVC para .NET: o MonoRail.
Como nos últimos tempos muita gente tem falado sobre MVC, resolvi preparar um guia de links para intruduzir as pessoas nessa tecnologia e apresentar blogs que falam sobre o tema:
Considerações iniciais sobre o ASP.NET MVC Framework (Ricardo Oneda): http://www.linhadecodigo.com.br/Artigo.aspx?id=1602
Desvendando o MVC (Ricardo Oneda):
http://www.linhadecodigo.com/Artigo.aspx?id=1634
Criando Aplicativos Web Sem WebForms (Chris Tavares):
http://msdn.microsoft.com/pt-br/magazine/cc337884.aspx
Bom, depois desses artigos, muita coisa rolou no desenvolvimento do projeto ASP.NET MVC. Vieram os Previews 2 e 3, e nos últimos dias, liberaram o preview 4, e segundo os comentários do Scott Guthrie ( o Beta 1 não deve demorar muito ).
Para acompanhar o que há de mais quente nessa tecnologia, o blog dos Scotts (o Guthire e o Hansellman) são as melhores fontes de informações. Um com as novidades e alguns tutoriais, e o outro com vídeos e aplicações completas.
Scott Gu
http://weblogs.asp.net/scottgu/search.aspx?q=MVC&o=Relevance
Scott Hanselman
http://www.hanselman.com/blog/
Vale lembrar que se você gosta de WebForms e "não quer se separar dele", não se preocupe, os dois modelos coexistirão.
O que ninguem ainda sabe é se o ASP.NET vai sustentar duas bibliotecas de controles diferentes ou se os projetos MVC e WebForms convergirão nesse ponto.
Acho complicado unir as duas tecnologias, afinal, o comportamento de um System.Web.UI.Controls.TextBox (com viewstate e tudo mais) seria um pouco diferente no MVC, já que o viewstate não é suportado, e todo o ciclo de vida de um WebForm não é seguido dentro do padrão MVC. Talvez eles mantenham as tags "asp:" por questões de portabilidade de código, mas seu funcionamento interno será distindo. Em paralelo a isso, o MVC tem implementado uma coletânea de ExtensionMethods denominados HtmlHelper methods para renderizar controles. Nesse ponto, voltamos a era ASP.
Outra coisa que intriga um pouco é a forma como o time do projeto ASP.NET MVC vai lidar com AJAX, que foi uma das grandes investidas do ASP.NET 3.5 e mantém uma comunidade atuante, mas não é compatível com MVC. Acredito que o MVC vai procurar ser "plugável" nesse ponto, mas que vai passar a bola para o ASP.NET AJAX através de alguns "açúcares sintáticos". Se eu pudesse apostar, diria que eles vão utilizar um novo recurso denominado Filters Interceptors para implementar funcionalidade ajax nos Controllers, mas tenho grande curiosidade em ver como as views vão tratar isso.
O grande problema que envolve o AJAX é que ele pode desvirtuar a filosofia MVC se ele aproximar demais a View dos Controlers. Afinal, Em teoria, um controller deve ser "agnóstico" quanto a views. E o ajax é uma tecnologia que funciona nas views e não deveria, em tese, ter qualquer relação com os controllers clientes, mas não acredito que tenha um meio de descascar esse abacaxi facilmente.
Para não dizer que tudo são flores, indico também a leitura de um artigo do Dennes torres apresentando sua análise sobre o padrão:
http://www.devaspnet.com.br/colunas/coluna0136.aspx
Eu não concordo em tudo do que ele fala, principalmente na conclusão, acredito que grandes projetos tem um potencial de serem melhor escritos em MVC do que WebForms através de TDD, mas acho uma leitura importante para manter um olhar crítico sobre a tecnologia e não se encantar apenas por ser novidade, em outras palavras, manter seus pés no chão. :-)
Até a Próxima!
Assinar:
Postagens (Atom)