The idea is basically to create a simple CRM for Open Source projects. As there’s a great diversity of Open Source tools, and depending on its nature (low level API, build server, office suite) the development team may need different features, the ideal is that it has some kind of plug-in API, or modules.

It could help organizing donors, events, meetings, file exchange, among other things. And it would be useful if it was a SaaS (and cheap/free!).

The idea came after a tweet by @agentdero.

There’s a plethora of plug-ins for Jenkins, that’s well known. But there are way more modules in CPAN. One way to visualize all the modules in CPAN is with Map of CPAN.

The idea here is to create similar map for Jenkins plug-ins (Map of Jenkins plug-ins). It could use the plug-in type (plugin-labels) and show its growth through the time. That would be interesting, especially if it was possible to create a video (like this one below) showing what happened since the fork from Hudson.

Map of CPAN – The Movie from Grant McLean on Vimeo.

The code for the CPAN map generator is hosted at GitHub: https://github.com/grantm/cpan-map. And it uses the Hilbert curve for plotting those geometric forms.

Update 26, oct. 2012

The map generation is started with a Perl script cpan-map that downloads a tar.gz file from MetaCPAN and creates a map of namespaces and its modules. Then it creates an image with Hilbert curves. It assigns different colors for each namespace.

For Jenkins plug-ins map we could use update-center.json file, and group plug-ins by its label. We could get the author picture from Gravatar (like Map of CPAN), and use the same interface of Map of CPAN - it uses sammy.js and jQuery.

Links for Hilbert curves and Java

Muita gente posta no Instagram fotos dos pratos que está comendo. Uma ideia seria utilizar uma base e um algoritmo de reconhecimento de padrões para identificar qual o prato. Tentar cruzar com informações do lugar da foto e, cruzando o tipo de prato (doce, salgado, chique, pobre, etc) com o valor dele e estabelecimento, recomendar ao usuário outros restaurantes.

Digamos que alguém peça costela no Outback, tire uma foto e poste. O que esse sistema precisaria fazer é:

• Classificar a comida
• Extrair informações sobre o perfil do usuário
• Encontrar informações sobre o estabelecimento atual
• Com base nos dados que possui, recomendar pratos em outros estabelecimentos

Com algum treinamento (see: Machine Learning), seria possível que o site recomendasse a esta pessoa experimentar a costela no AppleBees também. Já que o tipo de estabelecimento é semelhante, o prato e o valor também. Talvez o usuário pudesse pedir uma recomendação menos calórica mas semelhante (see: Fuzzy), ou mais barata (see: Tio Patinhas).

This is an interesting case that I received via e-mail from G. M. after he read the post . Basically, using an approach similar to the testlink-plugin for Jenkins, one could send the coverage results to TestLink.

TestLink has requirements x test case coverage information, and Sonar, Jenkins, Cobertura and other tools give you source code x test coverage. Crossing these information could be interesting.

I’m working in an Apache Nutch project that involves some new plug-ins and customization in existing parts parts of Nutch, however, after reading Nutch’s code base and learning about its plug-in architecture, I believe someone could use part of Jenkins API to enhance the plug-in API in Nutch.

Nutch uses a similar concept, with the same name as in Jenkins, Extension Points. However, it’s quite hard to create a plug-in project separate from the core project (it uses Ivy and plug-ibs have some dependencies to the core project). And you have to extend certain classes and configure XML files to prepare your plug-in.

Part of this could be automatically done with inheritance + Java annotations. I’ll have a cycle for Open Source in the next days, and will give it a try to see if that really makes sense.