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

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!

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!

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 :-)

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.

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.

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.