What can Eclipse developers learn from Team Sky’s aggregation of marginal gains?

The concept of marginal gains, made famous by Team Sky, has revolutionized some sports. The principle is that if you make 1% improvements in a number of areas, in the long run the cumulative gains will be hugely significant. And in that vein, a 1% decline here-and-there will lead to significant problems further down the line.

So how could we apply that principle to the user experience (UX) of Eclipse C/C++ Development (CDT) tools? What would happen if we continuously improved lots of small things in Eclipse CDT? Such as the build console speed? Or a really annoying message in the debugger source window? It is still too soon to analyse the impact of these changes but we believe even the smallest positive change will be worth it. Plus it is a great way to get new folks involved with the project. Here’s a guest post from Pierre Sachot, a computer science student at IUT Blagnac who is currently doing open-source work experience with Kichwa Coders. Pierre has written an experience report on fixing his very first CDT UX issue.

Context

This week I worked with Yannick on fixing the CDT CSourceNotFoundEditor problem – the unwanted error message that Eclipse CDT shows when users are running the debugger and jumping into a function which is in another project file. When Eclipse CDT users were running the debugger on the C Project, a window was opening on screen. This window was both alarming in appearance and obtrusive. In addition, the message itself was unclear. For example, it could display “No source available for 0x02547”, which is irrelevent to the user because he/she does not have an access to this memory address. Several users had complained about it and expressed a desire to disable the window (see: stack overflow: “Eclipse often opens editors for hex numbers (addresses?) then fails to load anything”). In this post I will show you how we replaced CSourceUserNot FoundEditor with a better user experience display.

Continue reading “What can Eclipse developers learn from Team Sky’s aggregation of marginal gains?”

Getting Started With Gerrit on Eclipse CDT

This is a guest post from Yannick Mayeur, a computer science student at IUT Blagnac who is currently doing open-source work experience with Kichwa Coders. It was originally one of his weekly write-ups which can be found here.

You are probaly familiar with the pull request system of GitHub that programmers use to contribute to an open-source project. Gerrit (named after its designer Gerrit Rietveld) is basically an improved version of this system. Gerrit allows the committer to give more precise feedback on each line of code edited, and allows other members of the team to review those changes. Gerrit is used by the Eclipse CDT community. In this blog post I will show you how to efficiently get started with it.

The required tools & knowledge

Having Git is basically all you need to clone the sources, and push them. If you want to edit them in a good environment use the Eclipse JAVA IDE. Knowing the basics of Git is also required, though I think you could pick up Git as you go along with a bit of trial and error.

How to get the sources of CDT

Cloning the sources to your computer is an easy but essential task.

The link of the repository is: git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt

To clone use the following command:

git clone git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt

Once you have the files, go to Bugzilla and find a bug you want to fix.

Pushing the changes to Gerrit

Now comes the tricky part. In order for you to be able to push your change a few things have to be respected. Continue reading “Getting Started With Gerrit on Eclipse CDT”

Technical Debt: How Do You Unfork a Fork?

filled_cirle_point_style_graph

Everyone knows how to fork that interesting open source project, it’s simple and handy to do. What’s not so easy to do is to merge back a fork that has over the years taken on a life of its own and for many reasons has diverged drastically from the original repo.

This is a case study of an ongoing project we are doing with SWT XYGraph, a visualisation project that is now part of Eclipse Nebula. It is the story of a fork of SWT XYGraph maintained by Diamond Light Source, the UK’s national synchrotron. But mostly it is a story about the efforts to merge the fork, reduce technical debt, and work towards the goal of sharing software components for Science, a key goal of the Eclipse Science Working Group. Continue reading “Technical Debt: How Do You Unfork a Fork?”

Visualizing Docker Containers in Eclipse Che with Weave Scope

7scope.png

Last Thursday, at the London PaaS User Group (LOPUG) meetup and heard the best type of technical talk: the kind that immediately inspires you to try out the technology you’ve just learnt about. Stev Witzel showed a demo of a mash-up of Cloud Foundry tools (BOSH) with Weave Scope, an open source tool for visualizing, managing and monitoring containers. In the demo, Weave Scope provided a very slick visualization of the individual components and apps running on the Cloud Foundry platform and instantly gave me a deeper comprehension of the complex system.

I was keen to try out Weave Scope so asked myself “Can I quickly and easily use WeaveScope to visualise the Docker containers in Eclipse Che?

The answer was a resounding yes! First of all the Weave Works documentation is terrific (note to self: guides with Katacoda are my new gold standard for documentation). I found this  getting started article which I could adapt for my use-case. Given I already had Che installed & running on my Windows 10 laptop, installing & running Weave Scope was straightforward.

docker-machine ssh default
sudo wget -O /usr/local/bin/scope \
   https://github.com/weaveworks/scope/releases/download/latest_release/scope
sudo chmod a+x /usr/local/bin/scope
sudo scope launch

 

To my pure joy and delight, it JUST WORKED!!

In one browser I had Eclipse Che up and running, I created a few different workspaces

2scope

In a separate browser I had Weave Scope running.  As I created workspaces in Che, I would see them automagically appear in the scope tool.

1scope.png

Incidentally, when I first started working with Che it took me a while to understand each Eclipse Che workspace is a separate Docker container, but with this visualisation the understanding is immediate. Weave Scope is a great tool for those new to the technologies to quickly grasp some key concepts.

I love, love, love visual representations of systems; it’s a more natural way to quickly gain insights into a system, not to mention commit things to memory in the imagery part of my brain. Weave Scope let’s you monitor CPU usage:

3scope.png

You can also monitor memory usage as workspaces loaded up:

4scope.png

Plus it has a nice way to inspect containers, even attach or exec a shell on them:

5scope.png

In this case the system is relatively small and everything is running locally. However, I can easily see how it would be really useful to use Weave Scope when you want to troubleshoot Eclipse Che running in a production environment in the cloud by comparing it with a system running on a local development machine.

Weave Scope is open source, licensed under Apache-2.0.

Key Takeaways

Weave Scope is a great, slick, open source tool for visualizing & monitoring containers and is really super simple to get started with and use.

Eclipse Che, based on the ubiquitous Docker containers, allows leveraging of a whole world of awesome container-related technology, including the Weave Scope visualisation tool.

Creating a new stack in Eclipse Che from an existing Docker image

title_che_custom_whalesayIn Eclipse Che, stacks are runtime configurations for workspaces.  Eclipse Che 5.0 provides the ability to quickly create a new stack based on an existing Docker image. There are a few requirements, with the main one being that the image must include a bash shell (fortunately most already do). Additionally, Docker images used with Che must have a non-terminating CMD command so that the container doesn’t shut down immediately after loading. However, we can do this in Che without having to modify the Docker image.

This article outlines how you can create a new stack based on the docker/whalesay image, the Docker image many folks would have come across when going through the Docker tutorial.

Step 1: Create a new Runtime Stack

  1. Install and launch Eclipse Che. (This article is based on 5.3.1)
  2. In the left-hand menu, click on ‘Stacks’ then ‘Add Stack’stacks1
  3. In the new stack page, fill in the ‘Name’ field e.g. Eclipse Che Whalesay stacks2
  4. For good measure, in the Tags section, delete the Java 1.8 tag and you can add in any preferred tags (press Enter after each tag to turn it blue).

From now your stack is available on the dashboard or stack list, but it doesn’t yet do anything impressive.

Step 2: Reference the Docker Image

  1. To reference the Docker image, in the stack editor, first scroll down to the ‘Raw Configuration’ section and click ‘Show’. Find where it says ‘image’ and replace the existing entry with the docker/whalesay one. Click ‘Save’.stacks3
  2. As the whalesay image normally shuts down after running, we need to make it so it keeps running. We can do this using Docker Compose syntax that is now supported in the stack editor. To do this we add the following command to the content.
    command: [tail, -f, /dev/null]

    stacks5.png
    Whitespace matters so check the recipe preview in the ‘Runtimes’ section to ensure it looks like correctly formatted Docker Compose syntax.  Although this is a bit hacky, it is great because it means we can reuse the docker image completely unchanged. stacks7.png

Step 3: Add a Custom Command

Next we will create a command to allow us easily run the whalesay image within the browser IDE.

  1. In the Commands section, click Add. Fill in the name and command fields. In this case we’ll simply make the command just say ‘boo’.
    • Name: cowsay
    • Command: cowsay boostacks8

Step 4: Test the Stack

  1. That’s it, now we can test it straightaway by clicking on the ‘Test’ button. A dialog will pop-up, click ‘Test Workspace’, no need to import any projects.
  2. This should pull the whalesay image and launch up a workspace with it configured.stacks9.png
  3. Click on the play icon next to the cowsay command and you should whalesay in the terminal saying boo!stacks10.png

Bonus Step: Use Macros

  1. We can also use macros in commands, try editing the command to have the whale say the name of the selected file like this:
    • Name: cowsay
    • Command: cowsay ${explorer.current.file.name}

    A full list of macros can be found here: https://www.eclipse.org/che/docs/ide/commands/#macros

  2. Then test the workspace again, this time including one or two example projects. Click on a file, then run the command. This time whalesay should say the name of any selected files. stacks11

And that’s it, an unchanged Docker image easily integrated into a new runtime stack!

whalesaystack