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).
segunda-feira, 29 de setembro de 2008
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.
Assinar:
Postagens (Atom)