Month: November 2017

Posted on

The Eclipse Debug Perspective just got a lot better

A Debug Menu!
The next major release of Eclipse (4.8 aka Photon) due in June 2018 has a small – but significant – new feature. The next version will have a Debug menu!

DebugMenu

This improves things in two ways:

  • No more going to awkwardly names Run menu when you want to Debug
  • A less full Run menu as the sometimes overlong Run menu is now split into two distinct and logical parts.

Better Default Layout in Debug Perspective

The first thing I do whenever I create a new workspace is change to the Debug Perspective and do most of my work in that perspective, rarely changing to other perspectives. I re-position the views in the perspective in my own special way, or so I thought until I found out that lots of other developers also prefer roughly the same layout as I have. The new default layout gives more place to the editor and more vertical space to the Debug view (the one with the stack traces).

Here is what the new layout looks like with a few additional views open:

debug_extra_opened_views

So what?

“So what?” I hear you say, “these are small changes, not earth shattering new features.” Changes like this are a big deal, thanks to the marginal gains principle. Eclipse has been a very stable top class IDE for years, but you may have noticed that things haven’t been changing as much in the last number of years. Part of this is down to it being a great IDE already, but other stuff is at play here. Making fundamental changes like the default layout to probably the most commonly used perspective and changing the top level debug menu is a sign that the Eclipse community is alive and well, that the ideas are still coming in. But it also means that the leaders in the community are open to change and evolution. If we don’t evolve we die.

What this means for extenders and plug-in writers?

If you, like me, are developing and extending Eclipse there is some impact on you to. For example, if you are contributing a clearly debug related task to the Run menu, you probably want to start contributing it to the Debug menu going forward. Both so your users can find it and so it does not stand out as being in the wrong place. You probably also want to consider the default opening location for any additional views you provide to the Debug perspective to ensure they pop-up in the logical place.

Of course it goes further than this. You should also take a step back and consider how your tools work. Perhaps it is time to do a Lean Design Critique?

Can’t wait until June?

If you can’t wait until June to get a hold of these improvements, you can pick them up in the latest nightly build, or wait until the Photon M4 milestone build in a few weeks. You can download the full packages from https://www.eclipse.org/downloads/index-developer.php or the Eclipse Platform/SDK on its own from http://download.eclipse.org/eclipse/downloads/

Thanks!

Finally thank you to the Eclipse Platform committers and contributors who are taking the bold steps to change and evolve. A particular thanks to Andrey Loskutov, from whom I borrowed the screenshots from (via Bug 464898 and Bug 513355), see Andrey announcement on the Eclipse mailing list: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14986.html

Posted on

Beware diversity-led marketing (& three cheers for these companies doing diversity right)

IMG_20171025_133846

There’s an increased level of discussion on improving diversity in tech communities. Or maybe it was always there and I just started paying attention. Either way, it’s a really good thing. But in the mix there is definitely a certain amount of diversity-led marketing e.g “We need more women-in-tech! Women, sign up for this tech course here…”.  Some are more obvious than others.

What about tech conferences? Take the case of a tech conference getting some promotion off the back of free diversity tickets. Is that just diversity-led marketing and a bad thing? After all it’s great to get underrepresented folks into conferences, right? The answer is if it is done in isolation then it is probably just self-serving marketing and pr. Underrepresented folks aren’t merely props for your agenda

Diversity is complicated. It’s easy to get it wrong and end up like the conference organizers who violated their own code-of-conduct and had a speaker cancel their talk.  Or fall into the Google case of  trying to inspire teen girls to code while simultaneously systematically limiting the careers of women in your company.  Again diversity is complicated, so we all want to focus our energies on those doing it the right way.

Open source has a worse record than most when it comes to diversity.  At this year’s Eclipsecon Europe, as with every tech conference I attend, I did my own evaluation of what’s being done well and not so well. This year, I noticed a few companies who are doing something right as evidenced by the women and underrepresented minorities that are in leadership positions.

  1. IBM – IBM had a noticeably improved presence at this year’s conference. I learnt that they actively encouraged speaker proposals. If a talk is accepted, there are good company policies in place to ensure speakers can travel and attend the conferences. As a result we had four awesome women speakers from IBM, not just any speakers, but experts in their respective fields: Eclipse JDT leads Noopur Gupta and Sarika Sinha, Eclipse SWT committer Lakshmi Shanmugam and Eclipse Microprofile committer Emily Jiang.
  2. OBEO – OBEO specialize in graphical modelling and are well respected in the community. Melanie Bats is one of the rockstars in the community, doing terrific and imaginitive tech talks and also recently took over as the Eclipse Planning council lead. OBEO recently promoted Melanie to CTO, which is written about beautifully here: Zero-to-CTO.
  3. BREDEX – BREDEX specialize in testing and are well represented at EclipseCon by the indefatigable Alex Schladebeck. Alex can be found leading the highly enjoyable Kahoot quiz at EclipseCon as well as heading up the Project Quality day. Doing great things in the testing world, it was great to learn that Alex has been promoted to  ‘Head of Software Quality and Test Consulting’ at BREDEX.

These three companies set a great example for the rest of us, not to mention make us better at our work as a community. Which brings me to the picture at the top of this blog post. I like to get setup really early before I do a tech talk, especially one in a huge room with a massive screen. So while getting setup, Jonah Graham of Kichwa Coders and Sarika Sinha of IBM got into a discussion about debugger protocols and threading issues. To discuss the finer points my laptop was commandeered and out came the code. It was one of those serendipitous moments and I didn’t want my pre-talk nerves to stop them. So I took a seat and took pictures while taking deep breaths. I think my talk went well anyway. That one conversation really informed our thinking on our work on the future of debuggers. And really it reminded me in a powerful way how things are always better the more different types of people you get involved. And little moments like these make it all worthwhile, and worth doing right, in the best way possible.

Posted on

Debug Protocol: Coming soon to an IDE near you

Our absolute favourite type of talk to do is one where we’ve been working on something so cutting-edge that we don’t have all the answers yet. This was the case with our work on the debug protocol and our talk at EclipseCon Europe. We got to take where we’d gotten to and present it to a room full of smart people who were generous enough to show up, ask questions and give us their insightful feedback.

The talk gives an overview of the debug protocol then demonstrates it working in:

  • VS Code
  • Eclipse IDE
  • Eclipse Che

We demo 7 different types of debug functionality as supported by the protocol: Continue reading “Debug Protocol: Coming soon to an IDE near you”

Posted on

Debug Protocol vs Language Server Protocol

It is safe to say that the language server protocol (LSP) is the future of developer tools.  When it comes to the equivalent for debug, the debug protocol is ‘LSP for debuggers’. It is a useful tagline but here are three key differences to be aware of:

  1. State – the big mindshift with LSP is that servers are stateless. The clients store all the state e.g. the files themselves and settings (what language, classpath, etc). Any state kept on the serverside (e.g. the index) is usually purely for performance reasons. What this means is that, for instance, servers can be restarted and carry on seamlessly without having to know anything of what happened in the system beforehand. On the other hand, the debug protocol is not stateless, servers need to know all sorts of state and sequences of what has happened, so the design space is different for this protocol.
  2. JSON RPC 2.0 Spec (and cancellable requests) – The LSP defines JSON-RPC messages for requests, responses and notifications. The debug protocol was created before JSON RPC 2.0 spec was finalized, debug protocol uses a similar structure, but it is not cross compatible. For example, the JSON field name for the method to call is command in debug protocol and method in JSON RPC 2.0. The type of message (event, request, or response) is explicit in DSP in the type field, but is implicit in JSON RPC 2.0 (based on presence of the combination of method, id, result and error fields). However using a library like org.eclipse.lsp4j.jsonrpc can hide such differences and provide equivalent higher level abstractions (like Java interfaces) and leave the library to handle the differences. The LSP has a nice feature, cancellable requests, that is an extension to JSON RPC2.0 that is also not available in the debug protocol: https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#-cancellation-support
  3. Ubiquity – although the LSP was defined originally for use in VS Code do you know that the 2 flagship languages for VS Code are not based on LSP? Typescript and javascript language tooling is not done using LSP. On the other hand the debug protocol does underpin all the debugger implementations in VS Code, including the flagship node debuggers for V8 and Chrome.

All that being said, it’s worth repeating the common benefits of both protocols which are:

  • good separation of client/server
  • building the tooling once and reusing it across IDEs and editors i.e. vs code, eclipse, atom, etc
  • better unit/isolated testing
  • write in language most suited to the job
  • more effective way for tool developers to keep pace with underlying tools
Posted on

The language server protocol will revolutionize how you code

lsps

The next generation Spring Boot tooling has been completely refactored to be based on the language server protocol (LSP). The tooling covers things like code assist for the Spring Boot property file, support for Cloud Foundry manifest files as well as Spring Boot support for Java files with typical features such as validation, content-assist and quick-fixes.

Beyond IDEs

Continue reading “The language server protocol will revolutionize how you code”