Colegas, gostaria de compartilhar com vocês o texto divulgado pelo colega Fábio Galuppo (MVP C++) sobre a nova linguagem F# anunciada pela Microsoft. Confiram o texto abaixo:

...

Acho que temos uma ótima notícia a ser divulgada aos MVPs e programadores .NET em geral.

Ontem fiquei muito contente em saber desta notícia: http://blogs.msdn.com/somasegar/archive/2007/10/17/f-a-functional-programming-language.aspx

Blog do Don Syme (criador do F#): http://blogs.msdn.com/dsyme/archive/2007/10/17/s-somasegar-on-taking-f-forward.aspx#comments

Já venho pesquisando e criando ferramentas de apoio com F# a uns 2 ou 3 anos. Sendo que a partir dela surgiu meu interesse em functional programming (OCaml, Haskell, ...).

Interessante saber que desde a incepção de anonymous methods no C# 2.0 e agora com o LINQ e lambda, o .NET Framework traz um novo estilo de programação, totalmente influenciado pelo paradgima funcional. A teoria matemática do Lambda Calculus de Alonzo Church foi a percursora deste paradigma de programação.

A saber, no ano passado, no evento sobre Linguagens de Programação realizado pela Tempo Real, eu falei sobre C++/CLI e C#. Porém introduzi a evolução do C# (3.0, lambdas e LINQ) e reforçei o poder dos anonymous methods - obviamente que introduzi superficialmente o F# e suas construções para contextualizar sobre a influência da programação funcional ao .NET em geral.

Não aconselho ao programador mediano ou grandes projetos comerciais migrarem para F#. Mas conhecer o paradigma funcional possibilita que um programador com fundamentos em linguagens tradicional (JAVA, C#, VB, Delphi,...) venha a resolver problemas que seriam complexos no paradigma imperativo de forma diferenciada e eficaz.

Vejo o emprego do F# nos segmentos de pesquisas em geral, aplicações visualização (2D ou 3D) e matemática aplicada, bem como na construção de ferramentas e bibliotecas da apoio e até mesmo como scripts para construção de jogos.

Grande abraço,

Fabio Galuppo
MVP Visual C++

Muitas aplicações .NET utilizam o Namespace System.Drawing.Printing para criar documentos de impressão (PrintDocument) e enviá-los para impressora ou para janela de PrintPreview.

Um cenário comum é encontrado em aplicações WindowsForms. Imagine um ponto de venda que utiliza uma aplicação WindowsForms para impressão de cupons, comandas entre outros jobs. Considere que o operador desta aplicação utiliza o teclado para executar todos os comandos e entradas de dados (o uso do mouse é minimizado). Em cenários como este, é comum que a tecla [ENTER] seja pressionada repetidas vezes para completar um processo de entrada de um novo pedido por exemplo.

Tive um cenário semelhante implementado no módulo de caixa de um restaurante, o volume de comandas entregues pelos garçons ao caixa é grande e o procedimento do caixa para inserir os pedidos no sistema é rápido e agilizado pelo uso do teclado. Ao final do processe de inserir uma nova comanda, o sistema verifica os itens inseridos e envia um job para diferentes impressoras dependendo dos itens, por exemplo, os itens "pratos quentes" são impressos na cozinha, enquanto as bebidas são enviadas para a impressora do bar para que o pedido seja atendido.

O problema é que com o tempo, o usuário do caixa, tende a digitar as entradas cada vez mais rápido. Isso faz com que a tecla [ENTER] seja pressionada repetidas vezes, algumas para avançar para o próximo campo e outras para acionar os botões de comando. Contudo, é comum que o usuário pressione esta tecla pelo menos 1 vez mais além do necessário. Se isso ocorre quando a janela de diálogo "Generating Previews" está sendo exibida, o job de impressão é cancelado.

Imagine a situação, você está na mesa, solicitou um prato, o garçon emitiu a comanda, entregou ao caixa, o caixa registrou o pedido, mas, sem perceber, pressionou a tecla [ENTER] mais uma vez cancelando o envio da impressão para a cozinha. Seu prato demora, você reclama para o garçon, ele reclama para o caixa, o caixa culpa a cozinha e no final de tudo a cupla recai sobre o sistema que devia ter previsto este cenário e utilizado uma implementação diferente.

A solução: A solução é simples, porém os exemplos de impressão na documentação do MSDN não aborda nenhum cenário semelhante. Basicamente o que você precisa é mudar o PrintController do seu objeto PrintDocument. Por padrão, o PrintController é um objeto do tipo PrintControllerWithStatusDialog, assim toda vez que o método Print() é invocado, o PrintControllerWithStatusDialog exibe a janela Generating Previews. Basta substituí-lo pelo objeto StandardPrintController que a janela não será mais exibida. A sintaxe correta para esta construção é:

pd.PrintController = new StandardPrintController();
pd.Print();

Simples assim!

O website Hansel Minutes (http://www.hanselminutes.com/default.aspx?showID=101) publicou o áudio da entrevista com Shawn Burke da Microsoft. Nesta entrevista, Scott Hanselman e Carl Franklin conversam com Shawn Burke sobre a nova versão do Visual Studio que possibilita que o desenvolvedor estenda a depuração de suas aplicações até as classes do .NET Framework. A entrevista está no idioma original (Inglês), mas vale a pena conferir.

 A Microsoft liberou nesta segunda-feira, dia 19/11/2007, a versão comercial do Visual Studio 2008 (RTM). Os assinantes MSDN serão os primeiros a ter acesso ao produto, que deve chegar às prateleiras das lojas em breve! Visite o MSDN para maiores informações.

Durante o TechEd Developers em Barcelona, Mr. "Soma" Somasegar anunciou que o Microsoft Visual Studio 2008 e o .NET Framework 3.5 chegará ao mercado ao final do mês de Novembro/2007. Esta nova versão permitirá aos desenvolvedores e empresas de desenvolvimento tornarem-se mais produtivos, explorar os mais novos recursos da plataforma Windows, do Microsoft Office 2007 e criar soluções inovadoras para a Web. Além disso o Visual Studio Team System 2008 oferece o ambiente perfeito para colaboração e gerenciamento eficaz do ciclo de desenvolvimento de softwares.

A WD5 Soluções Corporativas, agora é mais um Authorized Prometric Test Center, o único em Sorocaba e Região.

Verdadeiros programadores aprendem como trabalhar em equipe. Escrever código de forma legível é parte de ser um programador que trabalha em equipe.

O computador provavelmente lê seu programa tão frequentemente quanto outros membros da sua equipe o fazem, mas ele é muito melhor na tarefa de ler um código pobre do que as pessoas que trabalham com você.

Quando estiver codificando, como sugestão, tenha sempre em mente que outros colegas da equipe provavelmente terão que ler seu código.
Programar é, em primeiro lugar, comunicar-se com outro programador, em segundo lugar comunicar-se com o computador.

Existem vários níveis atribuídos aos programadores:

Nível 1: Principiante
Um programador Beginner é capaz de utilizar os recursos básicos de uma linguagem. Neste nível, o programador pode escrever rotinas, loops, estruturas condicionais entre outros recursos da linguagem.

Nível 2: Intermediário
Um programador de nível intermediário é capaz de utilizar os recursos básicos de várias linguagens e tem domínio para trabalhar confortavelmente com pelo menos uma linguagem.

Nível 3: Especialista
Um programador especialista domina todos os recursos de uma linguagem ou de um ambiente de desenvolvimento, ou os dois. Programadores neste nível são valiosos para suas empresas, e alguns programadores nunca vão além deste nível.

Nível 4: Guru
Um Guru, possui as características de um especialista (Nível 3) e reconhece que apenas 15% da tarefa de programar refere-se à comunicar-se com o computador e 85% refere-se a comunicar-se com pessoas. Estudos mostram que, em média, apenas 30% dos programadores desenvolvem trabalhos sozinhos. Um Guru escreve código para pessoas ao invés de escrevê-lo para máquinas. Os verdadeiros Gurus escrevem código verdadeiramente cristalinos e adequadamente documentado também. Gurus não tem interesse em desperdiçar suas células cinzas reconstruindo a lógica de uma seção de código que não foi devidamente escrito/documentado de forma correta.

Um grande programador que não se preocupa com a legibilidade do seu código, por maior que seja seu conhecimento, provavelmente nunca passará do Nível 3. Apesar que esta afirmação dificilmente é apresentada num cenário real. A principal causa de programadores escreverem código de má qualidade é que o código deles é ruim mesmo. Eles não costumam dizer “Vou escrever meu código de uma maneira difícil de entender”. Eles simplesmente não possuem conhecimento suficiente para escrever um código realmente legível, o que os coloca no Nível 1 ou Nível 2.

Exemplos de piores códigos que já tive oportunidade de examinar, incluiam variáveis com nomes como: X, XX, XXX XX1, XX2, T, Y, entre outros. Nomes de objetos como: TextBox38, DropDown22, e por aí afora.

Conclusão
Não é pecado ser um programador iniciante ou intermediário. Não é pecado ser um programador especialista ao invés de um guru. O pecado está em quanto tempo você se manterá entre os níveis de iniciante e especialista depois de saber o que tem que ser feito para melhorar seu código.

Code Complete, 2nd Edition
Steve McConnell
Microsoft Press

The Microsoft MVP Award is our way of saying thank you and to honor and support the significant contributions you make to communities worldwide. As a recipient of Microsoft’s Most Valuable Professional award, you join an elite group of technical community leaders from around the world who foster the free and objective exchange of knowledge by actively sharing your real world expertise with users and Microsoft. Microsoft salutes all MVPs for promoting the spirit of community and enhancing people’s lives and the industry’s success everyday. To learn more about the MVP Program, visit: www.microsoft.com/mvp.

Your extraordinary efforts in Visual Developer - Visual C# technical communities during the past year are greatly appreciated.

On behalf of everyone at Microsoft, thank you for your ongoing contributions to Visual Developer - Visual C# technical communities.

Sincerely,

Candice Pedersen, MVP Program Manager
Leonardo Tolomelli (leotolo@microsoft.com), your MVP Lead

A Microsoft contratou a VeriTest, uma divisão da Lionbridge Technologies, para medir as potenciais melhorias relacionadas à produtividade no desenvolvimento de aplicações entre as plataformas ASP e ASP.NET 2.0.

A abordagem utilizada neste estudo foi recrutar desenvolvedores experientes em ASP e ASP.NET 2.0. Foram formados dois grupos iguais com quatro desenvolvedores cada um. Os dois grupos receberam a mesma especificação para trabalhar. Durante o estudo as equipes tiveram cinco dias para implementar o máximo possível da especificação recebida.

O resultado deste estudo revelou que os programadores ASP.NET 2.0 conseguiram realizar 113% mais tarefas do que a equipe ASP dentro do mesmo período. Também foi concluído que os desenvolvedores ASP.NET 2.0 conseguiram criar páginas com conteúdo 357% mais rápido do que a equipe ASP.