Eclipse Finance Day 2014: Sirius – create your own graphical designers for IT and EA

3. November, 2014

Etienne Juliot from Obeo, demonstrated Sirius, a tool to create your own modeling tools in Eclipse. Under the hood, the new UI editors work on EMF models. If you struggled with EMF (and it’s … uh … “basic” set of default editors), you should definitely have a look.

The tools also work well with Xtext, so you have a mix of textual (detail) and graphical editors (overview) in your product. The magic sauce in EMF makes sure that updates on one side propagate to the other.

Better code with MoDisco

18. November, 2010

I’m always thinking about better ways to create software. Create. Sculpt.

Code generation? Maybe. But I’ve left kindergarten. Creating thousands of identical sand pies doesn’t make them more tasty. Or useful.

A few days ago, I had a long talk with a guy at an Xtext presentation. Xtext can create EMF models out of computer languages. Why is that useful? Because you can get at the guts of a language.

Look here:

... some complex setup

for( Item item : list ) {
    ... do something smart with item...

But the guy (who wrote this code — that’s me, thank you) made a mistake: For some reasons, items with a value < 5000 should be ignored. No problem, we can simply add that. If we have the source. But imagine you had a tool to “patch” the code. Like so:

for( ... ) {
    if( 5000 > item.value() )

The “…” are actual code. They mean “anything”. So this reads: “Skip code until you find a for loop and add a new condition at the front of the loop. Leave everything else intact.”

Pretty hard to do today. If we had a tool that could create an EMF model for the Java code. Enter MoDisco.

MoDisco can create a model for a software. What all those CASE tools did but the other way around. It creates a model for the software as it is now. Not very useful at first glance but think about the example above.

Or think that you’ve identifier a dangerous pattern in your code base. Now you want to fix it. MoDisco can search for these patterns for you.

Eclipse Modeling Day

29. October, 2010
Figure 4-3: Data Modelling Today

Image via Wikipedia

Yesterday was Eclipse Modeling Day here in Zürich. There were a couple of talks from people who were using modeling for projects and talks from project leaders of modeling projects like EMF and CDO.

Eclipse Modeling Platform for Enterprise Modeling

If you’ve used the Eclipse modeling projects, you’ll know the pain: Where to start? Which project is worth to spend time with? Caveats? Things like that. It seems that’s not a superficial problem. Eclipse Modeling is a big, unsolved jigsaw puzzle. The new project “Eclipse Modeling Platform” sets out to close the major gaps in the next two years. On the road map are things like authentication, large scale models, comparing models, etc.

For me, the list of topics looked more like an MBA’s wish-list than something that will make life easier for software developers. Their standpoint was that the funders call the shots. My standpoint is that the we need tools to help us solve the basic issues like good editors for (meta-)models and a useful debugging framework for code generators.

Interesting projects: Sphinx and Papyrus.

User Story: Models as First Class Citizens in the Enterprise

Since many people didn’t seem to be aware that modeling can do, Robert Blust (UBS AG) showed an example. Like most banks, the UBS has tons of legacy code. And tons of rules. Rules like: Any application A must access data of another application B via a well-defined interface. Their product would collect a couple of gigabytes of data from old COBOL code and use that to determine dependencies (like the DB tables it uses).

The next step would be to define which tables belong to which application and the end result is an application which can show and track you rule violations. Or which can show a Java developer which tables he must care for if he has to replace an old COBOL application.

There was the question of authentication: Who can see what of the model? This is going to be some work to solve in a way that it’s still manageable. For example, a part of the model could be accessible via a roles-based model. A software developer should be able to see all the data which is relevant to his project. But what about bug reports? Should a reporter be allowed to see all of them? What about the security related ones?

If we go to fraud tracking, individual instances in the model might be visible to just a very few people. So authentication is something which needs to scale extremely well. It must be as coarse of fine-grained as needed, sometimes the whole range in a single model.

Eclipse Modeling Framework for Data Modeling

Ed Merks introduced EMF. Not much new here for me. I tried to talk to him during the coffee break but he was occupied by Benjamin Ginsberg. Benjamin was interested to get a first rough view on modeling. Apparently, I made some impression on him, because he came back later to see me.

Textual Modeling with Xtext

Sven Efftinge showed some magic using Xtext: He had his meta-model open in two editors, a textual and a graphical one. When he changed something in the graphical view, it would show up in the text editor after save. Nice. I couldn’t ask him how much code it took to implement this.

Under the hood, Xtext uses Guice for dependency injection.

Graphical Modeling with Graphiti

Michael Wenz from SAP showcased Graphiti. It’s a graphical editor framework for models like GMF but I guess there is a reason why SAP invented the wheel again. Several people at the event mentioned GMF unfavorably. I’m not sure why that is but I remember that EMF generated huge, non-reusable blobs of Java code when I asked it to generate an editor for my models. Ed wasn’t exactly excited when I asked to change that.

Graphiti itself looks really promising. The current 0.8 is pretty stable and has a graphical editor for JPA models which allow to define relations between instances via drag-and-drop. No more wondering which side is the “opposite.” It also creates all the fields, gives them the right types, etc. From the back of the room, it looked like a great time-saver.

User Story: The Usage of Models in an Embedded Automotive IDE

A guy from Bosch showed some real-life problems with modeling, especially with performance. They have huge models. Since they didn’t look at CDO, their editors had to load the whole model into RAM. Since Java can only allocate 1.5GB of RAM on a 32-bit hardware, they are at the limit of what they can handle (some projects have 400MB sources).

It’s a good example how an existing technology could have made their lives easier if they only knew about it. Or maybe EMF is too simple a solution (as in “A scientific theory should be as simple as possible, but no simpler.” — AlbertEinstein).

Modeling Repository with CDO

Eike Stepper was glad, though. It gave him a perfect opportunity to present CDO which solves exactly this problem. CDO connects a client to a repository server. Any change to the model in the client is sent to the server, applied and then confirmed for all connected clients. So things like scalability, remote access and multi-client support come for free.

Over the years, CDO has collected a big number of connection modes like replication and an off-line mode. They even solve problems like processing lists with millions of elements. Promising.

One problem Eike mentioned are the default EMF editors. Not reusable, not exactly user-friendly. Since that didn’t change for the last four years, it’s probably something the modeling community doesn’t deem “important.” For some people, XML is apparently good enough.

Project Dawn is trying to improve the situation.

User Story: Successful Use of MDSD in the Energy Industry

RWE (one of the largest European energy companies) showed how they used model driven software development (MDSD) to create software to automatically handle all the use cases of their energy network. He stressed the fact that without strict rules and their application, MDSD will fail just like any other methodology. Do I hear moaning out of the agile corner? 😉

Anyway. My impression was that these guys don’t come up with stup…great new ideas every five minutes and expect that they are already implemented. Delivering electricity isn’t something that you entrust just on anybody. These people are careful to start with. So I see it that there are in fact industries where strict rules work. Anyway, MDSD is another arrow in the quiver. Use it wisely.

User Story: Nord/LB – Modeling of Banking Applications with Xtext and GMF

The last speaker was from Nord/LB, a German bank. He dropped a couple of remarks about GMF. Seems like he hit some of the gaps mentioned earlier.

Their solution included several DSLs which allowed them to describe the model, the UIs, the page flow in the web browser, etc. Having seen Enthought Traits, I’m wondering which approach is better: Keep everything in a separate model (well, Xtext can track cross-references between models just like the Java editor can) or put all the information in a single place.

If you keep everything in a single place (i.e. every part of the model also knows what to tell the UI framework when it wants to generate the editors), that makes the description of the model quite big and confusing. The information you want to see is drowned in a dozen lines. If you keep the information separate, you must store that in your memory when you switch editors.

I guess the solution is to create an editor which can display that part of the information which you need right now.

The Reception

After the talks, I had a long talk with Eike Stepper and Ed Merks. One of my main issues is that models are pretty static. You can’t add properties and methods to it at runtime. At least not to Ecore-based models. Or maybe you could but you shouldn’t. Which seems odd to me. We have plug-in based architectures like Eclipse. We have XML which stands for Extensible Markup Language. Why does modeling have to start in the stone age again without support for model life-cycle, migration, evolution?

When I presented my use case to Eike, he said “never heard that before.” So either the modeling community is going for the long hanging fruit or my use cases are exceptional. All I’m asking is a model which I can attribute with additional information at runtime. Oh, yes, I could use EMF annotations for this. Which EMF default editor supports that? Hm. So if my users want to extend the EClass “Person” with a middle name? Something that HyperCard could do, hands down, in 1987?


When you’re right, there is no middle ground

15. January, 2010

Yesterday, I attended a talk by Tom Schindl (he’s the guy behind UFaceKit and Qooxdoo, QxWT, etc.) And he’s working on e4.

During our little conversation after the talk, he stressed the fact many people aren’t willing to pay for bugfixes in Eclipse. He’d be willing to work on many of them but someone has to pay the bills. I nodded like everyone else. And we talked about Eugene Ostroukhov and his complaint ““Participate in community!” they said…“. And I immediately saw a parallel in my own history. I had a similar, painful experience with Ed Merks a while ago. That was about EMF and how badly it sucks. And that he didn’t listen to me.

I was mad because I was right and he just didn’t get it.

Yesterday, on the train home, I understood.

I’d like to introduce two new categories of programmers. Both are passionate and enthusiastic about software. The difference is that one group is pragmatic and the other idealistic.

Ed and Tom are pragmatics. They think: “Great feature, I like it, how much will it cost?” If it’s too expensive, they don’t get upset. They think about it, mull it around, consider their options. If there just is no viable way to do it, they can accept that. These people get money to write software.

I’m an idealistic programmer. I get money to stop writing software. That is, I get money to stop writing the software in my head and to start writing the software someone else wants. Not getting what I envision drives me up the wall.

Things can get pretty ugly when those two kinds meet. Because both are egoistic and both are right. It would make sense to make all the changes to EMF that I want. For me and probably a few others. It would cause quite a few problems for Ed, though (mostly because he’d get a lot of complaints by those people who are happy right now).

I’m asking for changes because I have problems. I’m not complaining about petty things. I need to bend EMF and SWT more than the API allows. To solve my problems, I just can’t accept the status quo. The API has to move. But my solution would cause problems for many other people.

Right now, I’m writing software which doesn’t have a lot of customers, so a stable, reliable API is not one of my goals. I can change my API at a whim and no one bothers. Eclipse has millions of customers and every change to any API will cause a tremendous amount of pain around the globe. Say 0.1% have a problem now? That would be at least 1’000 people complaining. One happy, 1’000 after your head. At least. How big is the pressure on Ed to make me happy?

So how to win? I think Linux has the best solution that you can get today. Linux has several release streams that strive in parallel. It’s not a bunch of forks, it’s a bunch of branches. People can hand in stuff that really isn’t ready for prime time. It can be incomplete. It can break other APIs. It can be an experiment. It can evolve. In Linux, there is the next tree.

In Eclipse, evolution is hard. You have to get new features and patches past people you don’t know, who have more experience in evolving APIs, little time and little incentive to hurt themselves. API in Eclipse is hard to evolve because IBM pays many of the core developers. If someone wants some obscure API and the Lotus Notes team will have a problem with that, who will win? The bug report (even with a patch) or your next pay check? There are only a few big commercial products on Linux. Eclipse, OTOH, was created to form the basis for commercial products (hence the EPL). Products that have life cycles between five and ten years. Ten years ago, we had Linux 2.2, KDE 1.0 and SuSE 6.3.

For IBM and SAP, the one year release cycle of Eclipse is way too fast. They have to spend a lot of money on developers just to keep up with all the changes going on in Eclipse and this is for things that can’t be sold to customer (i.e. which don’t earn any money).

So I agree with Bjorn Freeman-Benson that Eclipse needs a set of public git repositories and a low-barrier entry to these repositories (which means one-click install for the build system, no IP checking). It should be a playground, a place where ideas can grow. Not all of them will make it into the mainstream but at least, people can solve their problems without hurting too many others.

At the same time, I’m afraid what will happen when this comes true. But then, I’m an idealistic programmer. I believe that time will tell who was right and that we shouldn’t bother too much upfront.

%d bloggers like this: