As the application deals with more data, it becomes harder to cope with scalability and efficiency. Similarly, as the database schema becomes more complex, the complexity of the code handling it also increases, and we have to put more effort in optimizing our communication with the database. In particular, the maintenance of SQL statements embedded in the source code can become very cumbersome. Fragments of query strings are usually scattered throughout the source code and we never really see the final SQL statements assembled and sent to the database.
Other Cool Stuff
TypeScript's traction continues to grow for a number of reasons. For starters, it is a joy to use, and it is not getting in your way. Its type safety makes it ready to use in large-scale applications for the web, the backend, and for the desktop. Even extensible IDEs like Eclipse Theia, Visual Studio Code, and JupyterLab are written in TypeScript.
M2Doc is a document generator for creating high-quality Office Open XML (OOX) documents from models and Sirius representations. It uses OOX-based templates where static text authoring benefit from the WYSIWYG capabilities of the usual tools (e.g. Microsoft Word). With M2Doc, users can also leverage the Sirius support to insert diagrams and table automatically into their generated document.
When working as a software developer — as well as in any other job — it’s important to be productive and to get things done. You want to increase your development speed, focus on what adds value and cut out all the cumbersome, boring and repetitive tasks.
This session shows 20 ways of how to accomplish the goal of being more effective and efficient as a software developer using certain tools, approaches and mindsets. The session is brought to you by a German — from the country of efficiency.
Are you a new committer or project lead for an Eclipse, LocationTech, or PolarSys project? Are you thinking about proposing a new open source project? In this session, Eclipse Foundation staff members will walk you through the information that you need to know to be an effective open source project committer. The discussion includes an overview of the Eclipse Development Process, the Intellectual Property Due Diligence Process, and the Tools and IT Infrastructure made available to open projects by the Eclipse Foundation.
Running an open source project is easy. All you have to do is make your source code available and you’re open source, right? Well, maybe. Ultimately, whether or not an open source project is successful depends on your definition of success. Regardless of your definition, creating an open source project can be a lot of work. If you have goals regarding adoption, for example, then you need to be prepared to invest. While open source software is “free as in beer”, it’s not really free: time and energy are valuable resources and these valuable resources need to be invested in the project.
Autonomous driving solutions introduce a new complexity into the development of embedded systems in a car. This complexity rises with each level of control and autonomy. New tool categories have to be added like machine learning, but also existing technologies, like simulation, are stretched to their current limits. E.g., it is expected that the validation of a fully autonomous driving solution requires test drives in the amount of billions of kilometers.
Over the years, like many of us, I have progressively found a few tips & tricks to help me save some time and boreness every day working on that (mostly) rectangular thing.
From that neat CLI tool I've become addicted to to jump quickly between common directories I work in, to that little script I've written to automatically open the JIRA issue associated to a bug I'm working on, this cool custom Docker image hidden behind an alias, and many others in the middle, I will walk you through those findings.
This talk summarizes our experiences from building language servers and integrating and using them across Eclipse, VS Code, and Atom. We talk about the good parts, e.g.:
- building lightweight tooling
- the freedom of starting fresh
- building the tooling once and reusing it across various environments
- isolated testing
The bad parts, e.g.:
- no communication among language servers
- do the work twice or more, ship libraries twice or more
And the really ugly parts, e.g.: