Eclipse Finance Day 2014: Modernisation of Software

3. November, 2014

In his talk “Modernisation of Software“, Georg Pietrek of itemis AG shows the key points when you need to modernize software (= make large, disruptive changes). Karsten Thoms then demonstrated those points in a practical example in his talk “Model based migration of Oracle Forms applications”.

  1. Analyze the old code
  2. Create DSLs that describe the pieces of the old code which you want to migrate
  3. Write a small demo what the new app should look like
  4. Develop code generators which take the DSLs to generate the demo

After you have proven that you have covered all important bases this way, you can expand the DSLs (or rather write more code using the DSLs) to migrate the rest of the old code. You can reuse the small demo from step #3 to test any changes to the DSLs and code generators on a small code base.

The big advantage of using models to modernize is that manual migration often runs into a death spiral: Developers start with little knowledge (especially, when the original developers aren’t around anymore). They learn as they migrate code. But as this process advances, it becomes more and more expensive to fix early mistakes. With the model driven approach, you fix the bug in the code generator and thousands of lines of code are corrected at the push of a button. This means you can make abstraction work in your favor.

The advantage over exiting tools to migrate an old code base is that the model based approach is more flexible.

A quote from the talk: “Software doesn’t rot but it’s environment changes.” Eventually, the software no longer meets the needs.


Designing DSLs

16. July, 2012

Hello and welcome to a new series of blogs called “Designing DSLs” or DDSL for short. If you have used or designed a DSL before, then you’ll know that there are a couple of pitfalls. This blog series aims to provide tips how to build “great” DSLs – whatever that might be 😉

What are the most common pitfalls for designers of DSLs?

  • The DSL is too broad
  • The DSL is too limited
  • The syntax has weird quirks (a.k.a. backwards compatibility syndrome)

Why is it so hard to design a great DSL? They should be simple, right?

Well, as Einstein (“Everything should be made as simple as possible, but no simpler“) and Blaise Pascal (“I would have written a shorter letter, but I did not have the time.“) already knew, it’s always easy to make something complicated – simplicity is hard.

On top of that, every mathematical system is either incomplete or inconsistent. And let’s not forget that each DSL is a model, too. And as you might know, all models are wrong but some are useful.

Should we abandon all hope? No. Just always remember that a good DSL is hard work.

First, a general tip: Look at existing examples. There are thousands of examples out there; use them. Knowing several programming languages yourself is a big bonus (everyone should know more than two languages).

“Wait a minute,” I hear you ask, “these are real programming languages!” So? A lot of brainpower went into designing them (or working around shortcomings), which makes them a great source of inspiration. Bonus: A lot of people know these languages which gives you a larger audience to discuss ideas (as opposed to the 3-4 people who will use your DSL in the beginning).


Some Software You Should Know When You Work on DSLs

8. August, 2011

DSLs is all the rage but it seems the technology is actually useful 🙂 So here is some stuff that you’d probably want to know about:

Intentsoft created a workbench which can capture business information in the way the business wants.

JetBrains did something similar called Meta Programming System or MPS.

Want to know more about your own code base? Try MoDisco or Moose.

Lastly, using LL parsers is usually a big pain. Syntax Definition Formalism or SDF is another approach to define a syntax which avoids many of the problems of context-free grammars.


Jazoon 2011, Day 2 – JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

26. June, 2011

JavaFX 2.0 With Alternative Languages – Groovy, Clojure, Scala, Fantom, and Visage – Stephen Chin

Stephen showed how to use JavaFX 2.0 with other programming languages like Groovy or Scala. This is possible because the next version of JavaFX has a pure Java API for everything.

It was nice to see how well Groovy and Scala fared versus JavaFX itself. Even a dedicated Xtext-based DSL might not yield much better results.

Links:


Jazoon 2011, Day 1 – Cross-Platform Mobile Development with Eclipse – Heiko Behrens and Peter Friese

26. June, 2011

Cross-Platform Mobile Development with Eclipse – Heiko Behrens and Peter Friese

The duo showed a nice example how a DSL (created with Xtext, of course) can be used to generate code for an iPhone app, an Android app, a standard Java web app and an app for the Google App Engine from the same source.

The point here is not to emulate all features on each platform but to fall back to sensible replacements if a platform doesn’t support something.

It also showed the blazing speed of the new Xtext 2 code generator.

Links:


Jazoon 2010, day 3

7. June, 2010

The last post of the series (day 1, day 2).

The Gaia satellite and Data Processing by William O’Mullane

The day started with some astronomy. Gaia is another effort for a complete sky survey (like it’s predecessor Hiparcos). It’s a “cheap” mission by ESA which costs “only” 600 Million Euros (most space missions start at 1 Billion). It’s interesting how they keep pushing the limits today. Gaia will orbit L2, 1.5 million km away from Earth (the Moon is only 300’000km away). If something goes wrong, there is no way to fix it (which is why most systems are redundant except for the main mirror, for example). The main camera has 170 CCD chips. A huge effort is taken to determine the exact position of the satellite, it’s rotation speed, precise orientation, the position of the components (like the main camera in relation to the main mirror).

It will generate such an enormous amount of data that most of it will have to be thrown away on the craft before it is downloaded. The data will be available to anyone … anyone who can store a couple of petabytes at least (1 petabyte = 1000 terrabytes).

The mind boggles 🙂

Essentials of Testing: The Tools You Need to Know by Bettina Polasek and Marco Cicolini

My topic 🙂 The talk showed how they selected a couple of tools from all the available ones out there by functionality, how they support and complete each other and how well they are supported. Here is the list they came up with:

  • jDepend to know who uses what
  • GlassFish as a means to run J2EE tests out- and inside a container
  • HtmlUnit for testing web pages outside the browser (faster than Selenium but doesn’t catch all kinds of errors)
  • Selenium for testing web pages inside the browser. Slower than HtmlUnit but can test browser specific quirks.
  • PMD to keep your code clean.
  • FEST stands for “Fixtures for Easy Software Testing” and is a library to make testing more simple. For example, you’ll find code here to test Swing UIs or mock the classes you need outside the scope of your test.
  • Mockito, a mocking framework. It takes mocking to the next level with fluent interfaces.

Rapid Application Development with Apache Wicket by Andrew Lombardi

Again a tough one. I’d have loved to attend Using Software Metrics to detect refactorings by Thomas Haug.

Wicket is another web framework for Java. “Why another one?” I hear you wail. Because they all suck? Being an Apache project, Wicket tries to suck less. It’s fully mavenized and builds upon a component framework (the simple ones are built in and you find extensions on wicketstuff.org).

Wicket revolves around the idea that you give it a plain HTML (with almost no extensions) and a piece of Java which connects parts of the HTML with the code so you can simply render your pages from these components.

I’m not 100% sold, yet. Wicket was started around 2005 and has been under the radar most of the time. This can mean that it doesn’t solve all the problems. We’ll see.

Lunch break.

Building DSLs with Eclipse by Peter Friese

I’m a huge fan of code generation. A lot of code that we write is actually pretty repetitive and I really miss my preprocessor from the good old C days. Of course, today, it’s called Model Driven Development and we use XML and model transformation and EMF and the like but still.

Peter showed how to build a small DSL with Eclipse Xtext and generate code with the help of Xpand.

Kids, when you play with DSLs, always remember:

  1. They should be limited. Don’t build general-purpose programming languages with it. Less is more (less time spent debugging and hair pulling in this case).
  2. Know what you want to achieve. The tools won’t help you there.
  3. Know your tools. You can write Towers of Hanoi in SQL but it’s not as much fun as using JavaFX instead.

After the talk, I had a long chat with Peter about DSL debuggers. To make them work, we must have (at least) the following information:

  • Position in the input stream
  • Which DSL rule was applied
  • Which template contributed code
  • The state of the session at this time (values of all parameters, etc)
  • All user supplied transformations which were applied
  • Position in the output stream
    1. Only this huge amount of data will allow us to create meaningful “stack traces” if we want to debug DSL modeling problems.

      Spring ROO – A New Level of Enterprise Java Productivity by Eberhard Wolff

      I skipped most of the talk because I juggled ideas with Peter about DSL debuggers.

      Most of my problems are still there and will be solved by Roo 1.1 (couldn’t find out a release date for that).

      My major objection with Roo: It actually generates all the code. With Grails, for example, I get a controller but the class is empty. This makes it obvious where the defaults are being used. Roo, OTOH, copies a whole slew of code and files into your project when you create a new controller. This is code that you don’t know but which you’ll have to maintain.

      High Performance File IO: the Perl/Java battle by Daniel Eichhorn and Stefan Rufer

      How well does Java fare against Perl when it comes to filtering files if you use NIO? It seems that for big files, say 500MB, Java is just 25% slower which amounts to 24s vs 19s. 24 seconds to process a 500MB file twice isn’t that bad, is it?

      Mifos – the Grameen Foundation’s Java-based Microfinance application by Michael Vorburger

      Motto: Making the world better one line of code at a time. If you heard about microfinance, this is a software which helps to run it. Next time you find yourself with some time at your hands, how about helping fight poverty and join the Mifos open source project?

      Software in the service of handicapped people: Research & Development at Otto Bock by Hans-Willem van Vliet

      Along the same lines as Mifos, Otto Bock tries to make the world better by helping disabled people with wheelchairs and prostheses.

      It was interesting to hear how complex something like a smart leg is and how much people still want to look like everyone else.

      And That’s a Wrap

      With that, Jazoon 2010 ended. For me, it wasn’t as exciting as the last three years, mainly because the keynotes were somewhat weak. Well, see you all back in 2011.


Jazoon 2010, day 1, part 2

7. June, 2010

Here is the rest of day 1 (cont’d from previous post):

Construction Techniques for Domain Specific Languages by Neal Ford

I’ve seen this talk before. Maybe in 2008?

Slides aren’t on Neal’s homepage nor on his github.

Do you really get class loaders? by Jevgeni Kabanov

Nice talk with lots of exceptions you’ve never seen before. It’s a good, real-world example how something simple (like class loading which is basically just loading streams of bytes from a list of places) can turn into a nightmare if you just add one single, innocent rule (like the web guys did back then with JSP 1.0 when they decided to reverse the order of lookups).

97 Things Every Programmer Should Know by Kevlin Henney

Kevlin has been busy with a new book: 97 Things Every Programmer Should Know (link goes to a page with the ToC which links to the content which is CC’d).

Some examples:

Best of all: Many of these rules date back to the 1960’s! Time to apply some of these rules 🙂

That was day 1. On to day 2!