lundi 28 juin 2010

3 Good Reasons to use the Helios Modeling Package

Now that the entire world noticed that I don't know even one thing about soccer and I'm even trying to cheat, I should get back in sharing what I understand instead of those silly forecasts.

Helios has been out for a little while now, the mediatic storm is pretty much gone and it's a good time for me to have a look back.

This year one of my goal was : "I want to transform the Modeling Package in a product which I would use myself". I've been using it quite extensively lately and I'm pretty happy with the results, the Galileo package is far from being usable but the Helios version is just great :)

Why ? a few reasons...

1. because it's including hidden EMF goodness !

EMF generates code... which is good as any code you don't need to write means less bugs. But sometimes you don't even want to see that code !

If so, you're lucky, there is a specific filter for your workspace !

And the integration goes even further, code you manually changed is highlighted with different colors !

Oh, and you can compare and merge any kind of emf model, starting from the Ecore ones.

2. It provides Class diagram support

As a developper you always ends up needing some kind of graphical support for your communication, a class like diagram is well known by others, the modeling package includes support for Ecore thanks to the EcoreTools project.

And you even have specific views to browse your design hierarchy or usages.

While I'm at it, if you're interested in contributing to this project which is highly popular, you should really get in touch with Ed ! We're looking for fresh people to reboot this project, it's not as active as it deserves to be !

3. It's an SDK

As the modeling project provides a lot of high quality frameworks, you often need to have access to their source and as such it's one of the few packages providing SDK's.

All those reasons are making the modeling package the best one to get started with any modeling task but also any RCP development planning to leverage those great frameworks.

Oh yes, that should make this package a nice starter for e4 too :

post scriptum : 4. It's easily extensible

Of course the modeling community is way more active than that, I would strongly encourage you to have a small click on this button and have a try on the latest hot contributions which were not part of the Helios release the Agent Modeling Platform :

And the Papyrus UML modeler

And now it's time for you to download this package !

Forecasts Comparison For The World !

I have to admit I know nothing about soccer. Yes I'm a french guy, but I know nothing about soccer. That said I'm not against having a few beers in front of this broadcasted green field and I'm always in when its about having fun with a small game leveraging Eclipse technologies.

Obviously I played with the EEF based rich client for the forecasts, and from the moment the source code has been made available I started hacking the code.

The forecasts, matchs and results are all kept in a model accessible through an http uri, and as EMF rule them all, find them, bring them all and in the darkness bind them, you can leverage any Eclipse Modeling component to hack something quite easily.

That's what I did with Compare.

I extended the EMF editor adding a specific action, "Compare with / Player with Best Rank"

This action allows you to compare your own forecasts with the best ones, and then merge your own forcast with the best player one (Noooo, that's not cheating ! )

And here is the user interface you get for free*, with a pure semantic comparison :

* you have to depend on EMF Compare though...

Here is the logic needed to launch the comparison :

I had to use a few tricks, I had to provide a specific match engine enforcing the match of two players, otherwise the Compare component stop matching the forecasts from the beginning as the players are differents.

That's all for today, If I can free more time for this hack I'll provide a diff extension to change the score delta representation to a more meaningfull one, so far it's left as an exercise for the reader ;)

vendredi 18 juin 2010

Eclipse Modeling Survey results

The survey has been going on for more than one week now and the trends are only enforcing themselves. Let's summarize it:

First, the audience represents many non-commiters (2/3) though the commiters are still quite represented. That's quite consistent with what I was expecting, the survey was published on the planet, some newsgroups and through twitter and as such targeting commiter or adopters following quite closely what's happening in Eclipse Modeling.

Concerning the package size, we're right now at 250MB, it looks like it's mostly ok but being a bit smaller would still be nice.

As the package is an SDK we could probably drop most of the dupplicated javadoc in the plugins.

This one is interesting, it's something we're hearing and hearing again at each Eclipse conference, users do want more documentation, moreover best practices are hard to reveal through the wiki, newsgroup and online help jungle.

There is probably something to do here but, hey, there is an EMF Book already, an Eclipse Modeling one and everybody can contribute on the wiki, so why isn't this urgent need covered yet ?

It might be because:
  • People are not even aware of these books or books are old fashioned now : all content should be on the web !
  • It's so hard to understand what each project is providing that one really needs some Modeling Guide.
  • As a user you always want doc even if you won't ever read it, it just gives you the confidence that the technology is not going to vanish in a glimpse.
  • [ ] <----- any opinion expressed through the comments
It's even more disturbing when ...

yes, most people would be willing to give time to make this happen. We might need to do something here, maybe crowdsourcing the doc would do the trick... What is pretty sure is I wouldn't like it if Eclipse Modeling commiters spent half of their time documenting : we should make it easier for the adopters to contribute back.

And yes, writting doc and books takes a huge amount of time !

I asked another related question in the survey about "examples". In fact examples are way easier to provide and in my opinion are more valuable in most cases. And when you look at it, each project is already building its own examples, but these examples cannot be composed in some way. Just like Toast is a best practices application for OSGi, we would need a modeling one.

At its beginning the Amalgam project was providing some; yet since these examples were not part of their target Eclipse project (EMF examples in EMF, ATL examples in ATL) they were not maintained correctly. As a result they are not reflecting the "state of the art" of Eclipse Modeling anymore... Maybe for the next release !

I'm done for the strong trendes, others questions like "Having on the shelf design and generation tools" or "Domain focused UI instead of component focused one" were quite uncertain.

A few more ideas or questions have been given through this survey,
It will take another blog post to describe those.

Thanks again for your feedback !

mercredi 9 juin 2010

Eclipse Modeling Package Survey

I've been quiet in the planet lately, it doesn't mean I've been inactive, quite the contrary in fact, just like all the other commiters I've spent the last few weeks polishing the Eclipse Modeling Helios release. (As a sidenote, I'm giving more update from here --> )

And now the final bits are almost here ! More info about what's new in the Modeling Package soon, but you might have already seen that we have a pretty good feedback :) .

Helios is almost public now, we're already wondering what shape Eclipse Indigo will have, and to do so I'd like to have your opinion. I compiled a tiny survey, 6 questions you can fill in seconds.

I'f you're interested in Modeling in General, and Eclipse Modeling in particular, please spend the next seconds filling this survey.

the survey is embedded in the post or accessible here