Showing items from Tooling

Interoperability of web-based modeling tools

While doing some research on web-based tool, I recently found this excellent article by the team at EclipseSource. I like the way they present the differences between web and desktop-based tools focusing on the following axes:

  • Installability
  • Portability
  • Performance and responsiveness
  • Usability
  • Cost

I recently started studying these web-based tools to implement some personal projects and I found that there is another dimension worth mentioning: interoperability. As they note, both technologies have their pros and cons in each axis, but in the axis of interoperability, web technology are just on a league of their own.

Continue Reading

The toy example as a specification device

Agile methodologies are pervasive in today’s development culture. The ideas are used not only in software development but in other domains as far from software as sales. However, when we develop model-based tools, we are usually faced with the challenge to develop a DSL, or several in small iterations. This creates several challenges, but today I am going to be focusing on the specification of the requirements. Agile methodologies require to implement the software in small iterations where I think that one of the best ways of specifying part of a feature in a complex model-based engineering tool is through a toy example. Let me explain why.

Continue Reading

From Eclipse to VS Code: First impressions

I have been developing using the Eclipse IDE basically since college. In those days, being able to use a complex IDE was seen as the mark of the professional developer. Freshmen coded using a simple editor and the compiler directly from the console, geeks used an editor like Vim and some build tool to automate the build process, but to code “like a professional”, you used the mighty IDE.

In one of my latest classes, there was a even a teaching assistant that insisted that we use an IDE for one of the big projects in the last year of Computer Science. We were required to learn to use it well, this is, learning the shortcuts and going beyond just using it as very heavyweight editor. This was very useful later for my professional career, indeed, using the tools of the trade and going beyond just “programming” meant that you were ready to enter the workforce.

Continue Reading

What do we mean by software for engineers?

In this post I’m presenting a very broad overview of what I consider to be tooling for engineers, which is the main subject of this blog. Software for engineers has many names, some people call them modelers, others, IDE, and others just “tools”. In this blog post we will stick with the generic label “software for engineers”.

In the grand scheme of things, software for engineers requires mostly the same principles of design that other software. As most business software, software for engineers uses a layered architecture. The main difference is that, for standard business software the three standard layers: presentation, business logic, and back-end contain some common and standard components, while software for engineers uses another set of components.

Continue Reading

The rise of the super editor

When I first learned to program in the late 90s, it was with JavaScript. I was 16 years old, and I did not understand the underpinnings of programming and the tooling that is behind. I remember searching Yahoo and Altavista for explanations on what is a compiler and how does it work. In the end, I ended up learning JavaScript, because you only needed an editor (the good old Notepad did the job) and a browser.

Continue Reading