I haven’t really found the time to test OpenWrap thoroughly, but knowing the thrills and pangs one get on setting up a package management system for .NET, I immediately acknowledged the importance of this project. Sure, there are other cool alternatives being developed right now such as Bricks and WebGAC; you can even set up Ivy to play nice with .NET, as we’ve successfully done at Locaweb. But regarding the emergence of competitive solutions for package management in the .NET ecosystem, Sebastien couldn’t put it a better way:

(…) Package management is going to be the next Vietnam war on .net, and many people will come up with different solutions. It’s all for the best, and most projects, as they have done many times before, will die off on their own. This is to be expected. As such, I implore the .net world to let enough time for each of those projects to compete purely on the quality and functionality they provide, and let the best one eliminate naturally the other ones. Don’t succumb to the belief that standardizing early will help, or that popularity would be a distinctive factor. If we fuck-up the package management story on .net, we may never recover, so give it a bit of time and be circumspect in your analysis.

That being said, this post aims only at showing what’s out there regarding package management, with a special emphasis on OpenWrap. Sebastien has been posting several articles on his blog about how the project is developing, so it should be interesting to watch his progress. Last but not least, it is an open-source project, so feedback/contribution from the community should be more than welcome.

The lectures are anywhere between 30 to 60 minutes each and are based on the Haskell language–for which Meijer has special feelings. He even goes as far as leaving one or two homework assignments at the end of each session, which often involve comparing C# to Haskell and fiddling around with the latter.

• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 4
• Chapter 5
• Chapter 6
• Chapter 7
• Chapter 8
• Chapter 9
• Chapter 10
• Chapter 11
• Chapter 12
• Chapter 13

This is truly a “Can’t Miss” and I recommend it to anyone who wants to learn more about the origins of functional programming and how it works. As a bonus, you even end-up learning Haskell… “YOU KNOW!” lol

* * *

This is the first installment of a series of micro-posts about things I happen to stumble upon on the Internet and which should be of interest to people. If you like it, follow the “Can’t Miss” category to get updates.

* * *

A primeira palestra, “Ruby on Rails Insurgency”, foi do Chad Fowler (de longe esse cara me lembra o Seth MacFarlane) e ele fez uma introdução do eco-sistema cobrindo várias falácias que os concorrentes (ou os “trolls”) falam.

Alguns highlights:

If you’re gonna switch technologies (…) you might as well do things differently.

(…) Rails is about taking crap that you should be doing out of software development.

Support contract doesn’t guarantee anything.

Stop doing things you know are wrong. Stop.

– Chad Fowler

A segunda palestra, “On The Edge of Rails Performance”, foi do Gregg Pollack que apresentou algumas dicas de otimização do Rails e alguns plug-ins interessantes que, parafraseando o Gregg, “can just might save your ass”. Do blog dele e das poucas anotações que consegui fazer, os plugins são:

• Bullet: reduz o número de queries com alertas (no growl);
• Rails Indexes: tarefas do Rake para encontrar índices faltando;
• Scrooge: otimizador de queries SQL, para que se consulte apenas o que a página necessita;
• rack-bug: barra de ferramentas para debug de aplicações Rack implementada como middleware;
• memorylogic: adiciona o id e utilização de memória do processo nos logs do Rails;
• oink: faz parse do log a fim de encontrar actions que causam aumento do tamanho da pilha da VM;
• rubber: um plugin para Capistrano e para Rails que auxilia a publicação, gerenciamento e escalonamento de aplicações EC2;
• cloud crowd: gerencia processamento paralelo através de jobs em segundo-plano;
• Mad Mimi: aplicação de e-mail marketing com uma API muito interessante.

Na terceira palestra vim ver o Ilya Grigorik com a “Real-Time Ruby for the Real-Time Web”, que falou sobre Real-Time Ruby e coisas das quais sou fã como AMQP. Os slides já estão disponíveis. Na outra sala, o Carlos Brando está falando da construção de um framework com Ruby e de como o Rails funciona por dentro.

Na quarta palestra do dia, escolhi o Glenn Vanderburg, que falou do Tarantula, uma ferramenta para geração de testes fuzz em Ruby. Acabei passando um pouco por cima da palestra porque fiquei trabalhando pela VPN, mas achei especialmente interessante porque a Microsoft também está para lançar algo parecido para o mundo .NET e devo postar mais sobre o assunto em breve.

Depois fui na palestra do David Chelimsky, que passou várias dicas sobre Cucumber, RSpec etc. Destaque para a gem spork, que eu não conhecia e parece bastante útil quando usada junto com o Cucumber.

A palestra do Fabio Akita, como sempre, trouxe uma grande variedade de assuntos que levam algumas semanas para serem digeridos. Basicamente ele falou sobre a Teoria do Caos e como levá-la em consideração durante o gerenciamento de empresas, equipes e projetos pode fazer mais sentido do que trabalhar com modelos fechados, previsíveis e, portanto, limitados. Por isso que agilidade tem se mostrado eficiente onde paradigmas clássicos falharam. A teoria ajuda a justificar a necessidade de práticas como interações curtas, realimentação etc. Parafraseando o próprio Akita, o foco está no “porquê” e não no “como”.

Para finalizar, o Matt Aimonetti falou sobre o Ruby 2, Rails 3 e as tecnologias interessantes que os rodeiam. A plataforma promete coisas muito interessantes para o futuro.

* * *

No segundo dia, resolvi “cabular” as palestras e aproveitei que os palestrantes estavam pelo saguão para me juntar ao pessoal da InfoQ Brasil (Felipe Rodrigues e Ricardo Almeida) e entrevistar alguns. A InfoQ Brasil deve postar as entrevistas em forma de vídeo em breve, mas transcrevi dois trechos interessantes de perguntas que fiz para o Matt Aimonetti e o David Chelimsky. Por enquanto, é só uma prévia do que há por vir.

O Matt falou bastante das novidades do Ruby 2 e Rails 3 e destacou algumas das dificuldades que esse processo de evolução pressupõe:

InfoQ: As pessoas sempre lhe perguntam para quando elas podem esperar o Rails 3.0 ou o Ruby 2.0. Como você lida com isso?

Matt Aimonetti: Bem, o Ruby 2.0 vai levar algum tempo até que seja lançado, porque o Ruby Core Team ainda não começou a trabalhar nele. Então, após o Ruby 1.9.2, que deve ser lançado próximo do Natal, eles vão focar e começar a trabalhar nele. O Rails 3.0, por outro lado, é uma história diferente, porque nós estamos chegando perto do lançamento. Conforme eu disse na minha palestra, ele foi disponibilizado para os desenvolvedores de plug-ins e agora nós logo poderemos falar sobre a API. A maioria do trabalho já foi feita. Nós falaremos sobre a integração destes diferentes aspectos e nos certificaremos que ele é estável o suficiente para que as pessoas possam usá-lo.

É sempre um desafio trabalhar com open-source, porque tem-se voluntários, pessoas trabalhando que não são pagos para isso e elas trabalham em projectos diferentes. Você tenta manter os deadlines, mas é realmente complicado ter um deadline, então…

InfoQ: Você considera que não ter um deadline é uma barreira de entrada para que as empresas comecem a utilizar o Rails? Isso é um problema? A comunidade está preocupada com isso?

MA: Eu não acho que seja realmente um problema, porque nunca anunciamos um deadline. O que existe uma idéia de deadline… algo que gostaríamos de atingir. Isso não quer dizer que podemos realmente atingí-lo. Agora, as empresas gostam de estabilidade. Você não vai querer falar do (Rails) 2.0 uma vez que nós ainda estamos migrando para o 1.9. E o 1.9 é a direção que devemos seguir. As pessoas ainda utilizam o 1.8 porque elas consideram que ele é estável, então você precisa fazer as coisas aos poucos.

Você não vai querer lançar algo muito cedo e ele está quebrado. Nós não queremos lançar o Rails 3 cedo e depois as pessoas não conseguem migrar, pois isso não faria nenhum sentido. Então nós queremos nos certificar de que a comunidade está andando connosco e o produto é estável o suficiente antes de nós o lançarmos. E eu acho que isso é algo que as empresas valorizam.

O David Chelimsky, por outro lado, focou bastante em testes e estava particularmente curioso em como o RSpec e outras bibliotecas de testes influenciaram as que existem fora da plataforma Ruby e como está a adoção da cultura de BDD e TDD no Brasil. Aproveitei o assunto para falar de testes fuzz:

InfoQ: O Glenn Vanderburg falou ontem sobre o Tarantula na sua palestra e nós estamos nos perguntando qual é sua opinião sobre Testes Fuzz. Eles tem sua utilidade?

David Chelimsky: Totalmente! Mas eles tem sua utilidade. Um dos problemas que todos temos é que há várias formas de se testar que possuem cada uma seu valor dentro de um mesmo projeto. E eu acho que as pessoas tendem a procurar uma solução única e definitiva que elas possam sempre aplicar, mas o desafio é realmente achar a combinação ideal para um projeto específico. E eu também acho que muitas pessoas acabam dizendo que “nós tivemos sucesso em determinado projeto utilizando uma determinada combinação de ferramentas e técnicas, então devemos utilizá-las em todos os próximos projetos”, mas elas podem não ser as ideias nestes próximos projetos.

No caso do Tarantula, eu pessoalmente ainda não o utilizei, só ouvi falar dele. E eu não estive na palestra do Gleen porque a minha era logo depois da dele, mas eu conversei com ele esta manhã. O que ele me disse foi que na sua empresa, a Relevance, eles utilizaram o Tarantula em muitos projetos e não houve um único caso em que a ferramenta deixou de achar alguma coisa que eles deixaram passar. O Tarantula tem um baixo custo de entrada: só leva 10 minutos para ligá-lo na sua aplicação. Se você só tem 10 minutos para testar e ele encontra alguma coisa, então você já saiu ganhando.

InfoQ: Mas você não acha que existe o perigo de as pessoas pararem de pensar nos seus testes e passarem a confiar apenas na ferramenta para fazê-los para eles?

DC: Totalmente. Mas se deixássemos de fazer tudo por causa do perigo, nenhum de nós estaria escrevendo Ruby hoje. É necessário uma discussão pública a respeito disso e as pessoas precisam compartilhar suas experiências.

Certamente há esse perigo e as pessoas são pegas a todo momento porque elas ouvem “você deveria usar isso”, mas elas não entendem o real sentido do que é aquilo. Então eu posso imagina que uma pessoa que não faz nenhum outro teste além de testes fuzz terá, sim, problemas.

I’ve been working – both academically and professionally – with the .NET stack since 2003 and although I didn’t meet the rough edges of .NET 1.0 and Visual Studio 2002, I did saw the steep transition from Framework 1.1 to 2.0 and the smoother 3.0 and 3.5 steps. Right now we’re once again in a period of transition which seems to stale the .NET world for a couple of months at every release cycle. It seems the world is waiting for .NET 4.0 and whatever wasn’t good enough on the previous version–such as the Entity Framework–is not going to be further developed by the community. While in theory this represents a golden opportunity for alternative libraries to gain some momentum, in practice corporate developers do realize that the cost of changing legacy applications they simply don’t want to touch outweighs the cost of sitting still while Microsoft puts the latest bells and whistles to the “branded” library and the mainstream community starts blogging with some useful prototypes people can reproduce.

That said, what seems to be wrong? Well, for starters, it is important to point out that the Microsoft ecosystem, while extremely diverse and rich, could be said to have roughly two kinds of developers: those who by and large are using exclusively the System.* and Microsoft.* namespaces, and dragging-and-dropping like crazy; and those who are producing more exotic code by relying on third-party–free and commercial–libraries. The latter will necessarily be coming from or occasionally wandering off to a non-Microsoft platform. Additionally, if you think in terms of the Dreyfus model, you’ll most likely find more individuals with ‘proficient’ or ‘expert’ skill levels among the group not relying solely on the Microsoft stack. Microsoft has come a long-way in order to provide to such a heterogeneous community and for that it had to make compromises: shall always be agnostic; shall never be opinionated; will always feel like a duck–can’t seem to fly, swim nor walk properly, but does it all.

At the end of the day, what’s the product of this policy? Pulverization, it seems. If you look at what the community has produced to specialize the loose ends Microsoft left in its framework, you’ll find a mess. A mess of great code, but a mess nevertheless. While Ayende Rahien, Jeff Brown, Jimmy Nilsson, Miguel de Icaza and others may be strong voices on the community, it doesn’t feel like they’ve ever sat down and met each other. But why should they? Has Microsoft set an example in the first place? One thing is for certain: if the community has grown up like that, it has only done so because it was following Microsoft’s steps. There are many areas where it’s easy to see overlapping bits in the framework where you don’t feel collaboration and reuse took place: Linq to SQL vs. Entity Framework, PLINQ vs. CCR, ASP.NET vs. ASP.NET MVC, WCF vs. ASP.NET MVC . . . the list goes on. None of the elements of each pair are exactly like the other (and it was never intended that they should), but I guarantee you’ll find repeated functionality. The point is: if Microsoft is repeating itself and some of its many areas are evolving at some extent unaware of their neighbor’s progress, why shouldn’t the community? Hey, why reuse if we can come up with a new wheel, right? Well, wrong . . .

The very community Microsoft fed and raised could be what is holding .NET back today. And if that is so, then Microsoft itself is to blame. While it’s useless to compare the .NET community to others, I’m sure that it wouldn’t hurt if we had the Java maturity and scope or the RoR openness. Instead, what we have is some great software being produced by individuals who sadly can’t embrace the whole world, some great software being produced by companies, but which stay proprietary (and will remain so because it cost them a lot of money to develop and because, to put it simply, they’re just too damn afraid of open-source), and no cohesion whatsoever. (The reason universities aren’t producing more with the Microsoft stack despite their aggressive programs such as DreamSpark, ImagineCup and MSDNAA is beyond me. Maybe the company is simply trying too hard to fit in.) Meanwhile, Microsoft’s policy has been (up until now, read along) of watching what’s a must-have in the community and either bringing it in or recreating it (ORM, IoC and logging comes to mind). Kind of a crazy self-embrace-and-destroy-ish strategy.

Folks like Scott Guthrie and Erik Meijer, however, have been pushing a different agenda. They and their colleagues (Hanselman, Haack, Block etc.) have realized that Microsoft hasn’t been leading the evolution of this industry for some time and that the grass on the other side could indeed be greener. Microsoft has a lot to teach and certainly has a lot to learn, and those guys were the ones who step up and started making a difference. This is a generation of bloggers, start-ups and self-management models, and where accountability and transparency are prime values. Microsoft, I think, has caught up with that, a sign that the times have changed and that Ozzie is indeed continuing where Gates left off, taking the company into the future. The important thing is that the industry, as whole, ends up better at the end of the day.

Microsoft has to keep in that track. Opening ASP.NET MVC, embracing jQuery and the Mono Project, for example, were great moves and, not surprisingly, they came on Guthrie’s watch. While Microsoft has made some design decisions for the developers–and make no mistake: some of them, namely the agnostic die-hards, won’t like these decisions–they’ve reached a tipping point in the history of the ecosystem. Microsoft’s somewhat controversial new endeavor, CodePlex Foundation, is rapidly gaining popularity and will be subject of a lot of scrutiny by the community in the next months. What has changed in the strategy, is that instead of messing around with what the community has produced, Microsoft is indirectly providing guidance (with processes, techniques, legal mechanisms etc.) for commercial and open-source developers to lift themselves (and their work) up by their own bootstraps. As reported by Jon Tørresdal at InfoQ, Scott Bellware explains:

Microsoft has been forced to build new products from scratch to provide Microsoft customers with the value that open source projects have proven and delivered. These projects are often far less robust and mature as the open source that inspired them. The protections offered by the CodePlex foundation are also a turning point that frees up Microsoft resources to focus on integrating existing value rather than duplicating it, and risk missing the value targets offered already by open source.

All of this points to an evolving shift in culture and values toward the freedom to choose solutions based on merit rather than mere intellectual property risk mitigation.

This shift in culture and values toward meritocracy and the benefits that come from open competition that stands a chance of taking Microsoft and Microsoft customer community in a brand new directions that can provide more value from the Microsoft stack than we’ve seen yet.

When collaboration and cooperation start taking place (hey, isn’t it high time people started seeing value on using distributed-VCS?), projects can evolve naturally and in an orderly fashion. No reason why it should be different from what’s already been happening for ages in the unix-like open-source front. In the future, there’s a great chance we’ll see things like a package manager for libraries, common repositories, self-organizing and integrated communities, and flourishing projects. In the end, my take is that, under this strategy, Microsoft’s ecosystems grows stronger, gains market share, and all that without compromising the company’s business model.

* * *

This blog is about technology, business administration and engineering. I’ll be watching how the Microsoft ecosystem evolves from here on and I hope to be writing again soon about some predictions I guessed right. Meanwhile, I’ll focus on how to create great software by mashing .NET stuff up, I’ll be visiting different platforms either by professional necessity or by sheer curiosity (the latter more often than the former), and I’ll occasionally be visiting topics on business models and human relations. That’s sharpshooting.