Blog

Posté le dans Blog
Alex Lagarde, EclipseCon Europe 2012 “Documentation sucks because most of the time it’s outdated: it never reflects the recent changes you made on your software, and sooner or later no one will trust (and hence read) it anymore. By providing tooling to efficiently update documentation when a change occurs (in your models, your code…), Mylyn Intent gives to your documents the abillity to react to changes, turning them into true Agile documents. Moreover, as we’re in 2012 Intent provides advanced tooling to write/query your documentation with everything you would expect from a modern IDE (completion, quick-fixes, quick-outlines to browse through documents…). Icing on the cake, you can also collaborate in real time to write your documentation, preventing you from sending documents through mails or handle SVN conflicts. During the Eclipse Juno release, we used Mylyn Intent to document models describing Enterprise Architectures, computed through the use of the Obeo SmartEA Modeling Tool. In...

Posté le dans Blog
image
Most of the time, when you are working on a Java application you are not starting from scratch. You have to integrate your code in an existing project or you wish to use an existing framework and as such, your main problem is working with an existing piece of code. We will see how we can use Eclipse to help us write, fix and navigate in our code with, among other features, code completion, quick fixes, automatic imports, search and code templates. This post will start slowly as the most important tips will be explained first so I will take some time to detail their behavior. Let’s consider the following use case. You are working on a brand new piece of code that depends on an existing Java application. It can be a library, a framework or an existing project. You have read the documentation, you saw a blog post about a nice piece of code or one of your coworkers gave you some information to start. In our case we will consider that our goal is to use the framework EMF to “loa...

Posté le dans Blog
image
For this first post, I will start slowly with the creation and configuration of a brand new Java project. Then we will have a look at the various option to set up our project from the configuration of the JVM to the different source folders that we want to use. We will see how we can organize our Java projects and after that we will move on to the creation of our first packages and classes. Finally we will conclude with the project dependencies. Dozens of screenshots are also available in order to illustrate the information provided in this blog post, don’t forget to click the links. 1.1 - New project wizard In order to start working on a new Java application, you need to create a new Java project. For that, you have access to the new “Java Project” wizard from the “File” menu. In the first page of the wizard used to create the new Java project, you have to choose the name of the project. You also have the ability to select the location where the project ...

Posté le dans Blog
As an Eclipse committer on Acceleo, I am using Eclipse all the time and I have now learned various tips and tricks for Eclipse. During the last couple of weeks, I had the opportunity to go back to my old university to teach the future generation of software developers and by being surrounded with newcomers in both Java and the Eclipse ecosystem, I came to realize that I could share some information that I have acquired using Java and Eclipse all day long. Most of the time, when learning Java development, people are only taught about the language itself and some frameworks but not that much about the tooling. Yet you will spend most of your time developing in Java with an IDE that provides you with tons of features. The Java Development Tools project is one of the best Eclipse-based tools ever built. Thousands of developers from all around the world are using the JDT everyday. Yet most users of the JDT only use a fraction of its true potential. Over the next few weeks, I will detail mos...
“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.” - Kent BeckLien d'origineAuteur d'origine: sbegaudeau...