What is it like to work in Open-source?

Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. – Wikipedia

Yannick_opensource

I am Yannick Mayeur, a French computer science student currently gaining work experience at Kichwa Coders in the UK, and this is how I feel about working with Open-source.

Why Open-source ?

Let me tell you a story. A company asks someone in their software team to build some software to do a certain task. It takes him a lot of time but he manages to do it. He is the only one working on the project so there are no comments in the code nor any documentation to help maintain the code. He later leaves the company, the software slowly becomes useless as nobody else knows how to use it.

If this company had created an Open-source project instead, this problem wouldn’t have occurred.

Help spread Open-source – or ensure a job for life by using this guerrilla guide on how to write unmaintainable code. But seriously don’t.  Continue reading “What is it like to work in Open-source?”

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.