Taking the Long Way ‘Round

Remember Eclipse Two? Yeah, that was a lot of fun. Not sure anyone cares what happened to it. It made quite a splash back at the beginning of the year which proved to me that there is interest in a new tools platform for the desktop. Well, it’s been an interesting journey since then and I thought I’d give you an update.

First, I do firmly believe that Electron as a combination of Chromium for UI and node.js at the core will be a great tooling platform for the future, if not sooner than that. You look back when Eclipse started, and I think Mike mentioned this in a recent article, Java was the cool new kid on the block. Everyone wanted to learn it and use it and with SWT, it finally became performant and good looking enough to build the next great IDE platform that we have today.

You look around today, and ask that same question. What is the cool kid on the block that everyone wants to learn and work with? Well, I think it’s obviously HTML5. There’s no doubt there’s lots of hype to it. And with hardware accelerated rendering in Chromium and the native look and feel you can get with Electron, I think it’s ready to be the next next gen.

But a funny thing happened along the way. We released our latest QNX Software Development Platform with the culmination of all the work we’ve done the last few years with our Eclipse-based IDE Momentics. And our customers like it. They like it a lot. CDT is still the best C/C++ IDE in the industry and the user experience improvements we and the rest of the Eclipse community have delivered is paying off for us and them.

As much as I’m interested in seeing the next generation IDE platform, it has to be as good or better than what we have today. And personally, I think we’re a long way from that. Knowing how much work that has gone into the CDT to have it’s great static analysis engine and it’s clean debugger integrations and the clean up of launch workflows that we’ve achieved with the Launch Bar, you would need a very strong community to duplicate that. And you would need community leadership to bring all the different interested parties together to work towards a common goal. I struggle to see how that comes together and I look forward to discussing with fellow CDT’ers at EclipseCon Europe to understand where their visions lead.

For now, along with working on improvements to Momentics and CDT, I am continuing to work with Electron on some other tooling ideas. I think we have something cool in the works for system tracing, an area that a lot of us embedded systems vendors have struggled with in Eclipse and SWT. A lot of custom code has been written to make our System Profiler and Eclipse’s Trace Compass look good and navigate well. That could be an area where we could grow a community.

It will take us a long time before we know where to go next and I’m convinced that’s a good thing. If anything my work on Electron-based tooling has taught me is that we have a lot to learn with these new technologies. They are so new and constantly changing. It’s tough to build an IDE platform for the next twenty years when JavaScript frameworks come and go every couple. But the good news is that we have time. Eclipse is still going strong and giving our customers the great user experiences and the productivity improvements we promised them. We can afford to be choosy on the next one that will give them the same.

The Containerization of Dev Environments

As a veteran tools architect working for a veteran embedded systems platform vendor, we’re getting pretty good at building cross development environments. You get all the speed and integration with other native tools that today’s rich host platforms can provide. Combine that that with a good installer and software maintenance tool, and it’s super simple for users to get setup and keep their installs updated with the latest fixes and patches. It’s worked for many years.

So of course, I was a bit taken back with recent talk about delivering development environments in containers and distributing them to users for use with cloud IDEs. The claim is that the installation process is simpler. But I have to ask, while yes it is simpler for the provider, is it also simpler for the user?

I work with embedded software engineers. Their systems are complex and the last thing they want to do is fight with their tools. That doesn’t pay the bills. And that’s why we work so hard to make that management simpler. And if you don’t have the experience creating cross development environments, it is certainly appealing to only have to worry about one host platform, 64-bit Linux, as you do with Docker which, BTW, just happens to be the easiest to support especially relative to Windows.

But do I really have to teach my embedded developer customers about Docker? How to clean up images as updates are delivered? How to start and stop containers, and in the case of Windows and Mac, the VMs that run those containers? And that’s not to mention cloud environments which are a whole new level requiring server management, especially as the developer community scales. Embedded development tools require a lot of horsepower. How many users can a server actually support and how do customers support the burstiness of demand?

So, while I get it, and as vendors take this path and as users do get used to it, I do need to be prepared to support such environments. I’ll just feel a bit sad that we are giving up on providing our users the great experiences that native cross development tools provide.

A Thought on a Componentized Future of IDEs.

If you haven’t heard of the Language Server Protocol and the language servers they inspire, take a Google around. There’s something very interesting happening here. The direction the LSP starts, and we’ve had discussions around a Debugger Server Protocol as well, opens the door to the componentization of IDEs.

And this is quite different than the plug-in model we have with Eclipse. Instead of creating a UI platform and having plug-ins add menu items, preference pages, editors, views, etc., build your IDE from the other direction. Take a collection of components that don’t have UI, that implement IMHO the hard things about IDEs, language parsers, build systems, debugger frameworks, and wrap them with your own custom purpose IDE “shell”.

Eclipse suffers to a significant extent the “Tragedy of the Commons”. There is a large amount of inconsistency between plug-ins that do similar things but do it in different ways. Why is there a Perspective for every language? Because each language plug-in developer has different ideas on how the “Code” perspective should be laid out. And maybe, for their users, they’re right.

An alternative reality has language plug-in providers provide APIs that allow IDE builders to provide their own user experiences. Yes, that would be a lot more work and probably not practical. But as the doors open to a new generation of IDEs, language plug-in providers need to think about how they’d plug into many of them. It’s not clear which one will be the winner or even if there will be a winner.

It’s a brave new world. And we have a way to go before we figure it all out. But it’s a great time to think outside the box and see what sticks to the walls, or in my case, what I don’t erase from my whiteboard ;).

Achieving Web Integration in the IDE with Electron

It’s no secret that the modern developer’s favorite tool is Google. See a compile error you’ve never seen before, hell, cut and paste it into google.com and see if someone else has seen it and figured it out. It’s crazy how many times that works. That information sharing via blogs and forums makes the Internet an everyday part of a developer’s lives.

And, of course, it doesn’t end there. The Web makes it very easy to build services around shared data and artifacts. We put our bugs in Bugzilla or JIRA, our code in Github or some other git repo on a server somewhere, run our builds in Jenkins, code reviews on Github or Gerrit. These web based tools are indispensable for developers.

Now, it’s not entirely without merit that you would want to put your IDE up on the Web as well. It could be just another tab in your browser that you already have open for these other tools. But people who know me know that I’m not sold that that’s a good answer for everyone. And I especially look to embedded developers who have boards hooked up to their development machines and have installed a bucket of tools, as old as they may be, that do a great job helping build software for those boards. That, and you’re laptop has a lot of power that you own and can do what you want with without sharing with dozens of other developers who want to do whatever they want to.

For me the best solution for now would be to find a way to merge all the great tools on the Web with all the great tools on your desk into seamless workflows where you forget where the tools reside and you just do. And that’s where my experimentation with Electron and my Two IDE are showing a lot of promise. Let’s walk through an example with Github.

Have you ever opened up a Github page and clicked on the “Clone or Download” drop down? It’s pretty interesting that one of the choices is “Open in Desktop”. Click it in your browser and it takes you to a page to download Github’s developer tool. I’ve never used it but it sparked a similar idea I had for Two. It would be really cool to have a button that triggers the clone and sets it up in the IDE all in one click and a quick wizard for local settings.

So how would we go about that. Looking at the HTML source for the page, I was able to find the elements that created the Open In Desktop button. What I’d love to do is munge it somehow to say Open in Two IDE and add a click handler that would trigger the rest of the clone action.

One of the coolest things about Electron is that it has Chromium built in. And you can take full advantage of that and use the special features that Chromium has that the other browsers don’t. One of those is the webview element. It essentially creates a new rendering process that renders into an element managed by another process. I use it in Two to add a Github browser.

One of the attributes of the webview element allows you to specify a preload script. This script is run by the new rendering process before anything else in the new context. And this script has full access to the node.js environment. It lets you do some crazy things, like this:

import { remote } from 'electron';

window.onload = () => {
  const box = document.querySelector('.mt-2');
  if (box) {
    const a: HTMLAnchorElement = <HTMLAnchorElement> box.children[0];
    a.textContent = 'Open in Two IDE';
    a.href = '#';

    const input = box.previousElementSibling.children[2].children[0];
    a.onclick = () => {
        type: 'info',
        message: `Cloning ${input.getAttribute('value')}`

Now, this is TypeScript. But what I’m doing here is ‘require’ing the electron node module with the import statement which gives me access to the Electron remote API to call back to the main process. Whenever a page loads, I search the page for the element that contains the “Open in Desktop” element. I essentially hijack it and change the text and href and add a click handler to it. I get pretty sneaky looking for the URL for the clone by walking around the DOM a bit. I finally show that URL in a dialog box by calling the remote API to do that. Only the main process can open native dialogs.

Of course, I’ll eventually ask the user for a destination file path and any other arguments and then call the local git to make the clone happen and add it to the list of paths to show in the FIle Explorer. But for now, this is what I see:

Of course, you should be quick to point out that this is very fragile. If the Github gang redo the layout of the page, this breaks. But my theory is that if this type of integration becomes popular, you have a bit more leverage to go to them and create APIs, by having fixed classes or element ids that are more robust. Then any IDE trying to do this would benefit.

At any rate, this was a pretty early experiment that I haven’t spent a lot of time with. But it shows the path. By manipulating the content of the pages provided by web services, you can create workflows that span those services and the local development environment. And the user sees one tool. Click the Open in IDE button and it all magically gets set up and the IDE can switch automatically to the Code page to let you start working with it. Imagine what else you can do like this…

What is Two? Much more than yet another Eclipse IDE

It’s been a wild few weeks on the journey I now simply call “Two”. (Until it becomes an Eclipse project, I can’t call it one. And rightly so). The feedback I’ve received, especially as it hit the presses, was fantastic. It’s driven a lot of traffic to my github repo. I’ve even received a few pull requests from people cleaning up my mess as I plow through it. At the very least, people are intrigued by idea of an IDE built with Web UI technologies running locally under Electron.

As I work through the vision, I don’t think it’s fair to simply call it yet another Eclipse IDE. It’s much grander than that. For me, Two is about that vision. It’s more than a code editor. It’s more than just taking the existing Eclipse IDE and implement it in HTML5 running locally. It’s about a whole new way for developers to work with their tools and access the resources available to them on the web.

Developers today have access to many powerful web services. Github is a huge one. At Eclipse we use Bugzilla for bug tracking. A lot of companies use JIRA. People may be using Gitlab as their private Github. You may be using Gerrit for code reviews. I notice LLVM is using Phabricator for code reviews. And there’s the venerable Review Board still active today. Jenkins for continuous integration. And don’t tell me you don’t cut and paste error messages into Google searches to find others who’ve seen the same problem and worked out a solution. The Web is a critical tool in the developers belt.

I was intrigued by an article written by the creators of a tool called Ship. It’s a Mac native, i.e. Cocoa, app that integrates with the Github issue tracker. This quote hit me:

“A point of pride for us is that many people we have shown Ship 2.0 haven’t been able to tell where the web-based content ends and the native Cocoa stuff begins.”

That’s exactly it. If we can say the same for Two, where you can’t tell where the web ends and integration with local tools begin, then we’ve hit a home run.

Integrated Development Environments provide the most value when they have integrations between tools, which the developer has had to do manually for years. The IDE’s role is to automate workflows that transgress all the tools the developer has to use, where the workflow becomes the key, not the individual tools themselves. This focus makes it much easier for them to accomplish their objectives, so they don’t have to learn all the intricacies of underlying environments, but provide a unified language.

And that’s what Two needs to be, a tools integrator that includes not only the tools the user has installed locally, but also integrates with these super powerful web resources in seamless workflows.

The other important factor with IDEs that so many forget, is that experienced developers will always have a bit of mistrust in their IDE no matter how good it is. They need to be able to get close to the iron and run the underlying tools manually at a place where their trust is higher. An IDE that hides that, or makes those tools hard to get to, will struggle being universal. That’s why I’m not a fan of Cloud or Docker hosted tools. In making deployment easy for the provider, they make it hard for the user to touch the bits they’re creating.

The main reason I don’t want to call this Eclipse Two is that this isn’t just about a next generation Eclipse IDE. That IDE was my One, the first IDE that I’ve had a hand in creating. I want to rethink the whole developer experience and create an IDE that works well in the modern world, now almost 20 years after One. This is Two.

Looking Forward to 2017

I know a lot of people didn’t like how 2016 turned out, especially Americans, but for me it was a year of reflection and renewal.

As the state of the art for user interface frameworks gel around hardware accelerated graphics, I have been worrying for the future of Eclipse. It’s age is really starting to show and it’s getting harder to find tools developers that want to work with it. And with the murky future of JavaFX and Java as a desktop application technology, It’s time to start looking for the next thing in desktop IDE frameworks.

I also spent a lot of the year learning more about what embedded software engineers do. I’ve been building tools for them for many years but haven’t had a chance to use them myself. As Arduino and Raspberry Pi become cheap yet powerful and accessible devices, I bought a few of them and am starting to see how fun it is to program these devices to interact with the real world.

There are a few areas where I will be focusing my time in 2017. Here are some quick highlights. One New Years resolution I definitely have is to write more so I’ll be adding details as the year progresses.

Eclipse Two

Those who follow me on Twitter will notice me working on a new project that has grown from my fascination with Electron. Electron is the combination of Chromium and node.js in a desktop application framework. It’s what Visual Studio Code is written with along with many new and upcoming desktop applications, like Slack. It’s given me a fun opportunity to really learn HTML, CSS, and JavaScript and think of how I’d build an IDE with it. I have a couple of things running and you can follow along here on my github account.

Of course people have asked why not just extend one of the many text editor frameworks, like VIsual Studio Code, for what I need. There is a big difference between text editors and IDEs. Text editors seem to focus maniacally on being just text editors. IDEs add different types of visualizations and graphical editors that abstract away some of the more complex aspects of systems development. Web developers may not appreciate it much (yet), but embedded software developers really need the help that these abstractions provide.

My hope is that this work with an Electron-based IDE bears fruit and attracts IDE developers who are excited about the same idea. I’ve called it Eclipse Two (and it’s not e2, BTW, it’s Two), since it’s my full intention that if the Eclipse community is interested, we’ll bring it there. As it was in the days Eclipse One was introduced in 2001 and CDT in 2002, we can’t build this by ourselves. It only succeeds with a strong community and with strong architectural leadership that Eclipse is famous for.

CDT and the Language Services Protocol

The Language Services Protocol (LSP) is quickly becoming the accepted architecture that enables IDE’s to acquire language knowledge users expect as well as allows us to experiment with new IDE front ends, like Eclipse Two. Since it’ll be a few years before a new desktop IDE enters prime time, we’ll need to keep Eclipse and the CDT alive and thriving.

One thing we’re starting to see, thanks to Dr. Peter Sommerlad and friends on the C++ Language committee, is the C++ language continuing to evolve and modernize with new language constructs introduced every three years. It’s going to be very difficult for the small CDT team to keep up.

We need to look for alternative language providers and work with other IDEs, possibly leveraging the LLVM project’s libclang or some other parser that we could hook up to the LSP. That will likely be a lot of work since we rely on the CDT’s parsers for many features that the LSP doesn’t currently support but I think it’s a long term direction we need to investigate and a number of us CDT committers feel the same way.

Arduino and the Electronic Hobbyist

I am still fully committed to the Arduino plug-ins I’ve built for CDT and will continue to enhance them as the Arduino community and the mainstream Arduino IDE evolves. I am still hoping that members of the community will help with code along with their fantastic bug reports. The feedback has been nice to see and I’m glad the plug-ins have been useful.

The more I look at the work that embedded software engineers do and the incredible complexity of the systems they are working with, the more I am reassured that these developers do indeed need the help a good IDE can give them. Of course, it has to be a good IDE and I continue to work to understand what that means and help make it happen.

BTW, I had started on some plug-ins I was using to program the ESP8266 I used in my demos in 2016. Since then I’ve been in conversation with the ESP32 community and it’s been great to see that they are already adopting Eclipse and the CDT. Instructions are here if you’re interested. The good news for me is that it’ll give me a chance to stop working on my own plug-ins and to give me more time to focus on the other things in this list :).

Use an RTOS for your Real Time system

Programming the ESP8266 gave me some experience with FreeRTOS. In the demo, I have an ultrasonic sensor that I use to trigger different colors in the NeoPixels I also have attached to the chip. All of this is very real time sensitive. I need to measure the time between two interrupts to calculate distance from the sensor, and the NeoPixel communications depend on sending a serial stream of data at a very sensitive clock rate. Real time matters.

As part of the demo, I was showing CMake and the Launch Bar and how easy it was to switch from building and launching for one system to another. I took the real-time code for the ESP8266 and pretty much ran it as is on my BeagleBone running the QNX Neutrino RTOS, including the interrupt handlers and the NeoPixel code. I can’t imagine doing that on Linux. I know I work for the company, but it really helped me appreciate the Neutrino microkernel architecture and how easy it is to build an embedded system with the tools and APIs we provide.

The problem is, not enough people know about Neutrino and what a good RTOS can offer. Too many people are using Linux in real-time systems because it’s easier to get started, because it’s what they know, not because it’s the right architecture. One thing I hope to do is to help with the cause and spread the word and make it easier for the community to try it out. What that means, we’ll have to see in the upcoming months.

Beyond the IDE

I’ve made my career as a tools developer to do what I can to help other software developers build systems. But tools alone isn’t enough. Tools need to be combined with education through demos and tutorials and other types of instruction. Now imagine combining the two, a tutorial you access on the web that drives your desktop IDE as you learn.

And with that we come full circle as that’s one of the use cases I hope we can achieve with Eclipse Two! An IDE that not only helps you write and test code and build systems, but teaches you how best to do that as well.

Happy New Year and all the best in 2017!

It’s going to be a great year for the Eclipse community and technology and I look forward to helping where I can.

Using Eclipse CDT with MSYS2

MSYS2 is a relatively new distribution to support the MinGW compiler on Windows. It’s actually grown beyond that and has a pretty rich set of packages that include CMake, clang and gcc, and a huge set of libraries including Qt and SDL. It’s kept reasonably up-to-date and I’m sure if we can grow the community even more, we could get things even faster (e.g. Qt is one minor release behind).

On Windows, the CDT loves MinGW and MSYS. As Eclipse is a native application, it really expects things like path names and such to be native Windows things. Cygwin, being a Linux emulation layer, and the recent Bash for Windows are actually hard for CDT to integrate with because they hide away the native.

For Eclipse Neon, CDT has added support for automatically detecting the MinGW compilers in an MSYS2 installation. This article will give a quick guide on how to set up MSYS2 with the proper set of packages to start building C++ projects on Windows.

First a quick rant about their choice of package manager, pacman. I’m sure people who use Arch Linux love pacman. It’s pretty powerful. But I worry that it’s a tough fit for Windows users. The problem gets worse as there are actually three sets of packages, msys (common), mingw32 (for 32-bit tools), and mingw64 (for 64-bit tools) and some packages are in multiple of those. pacman makes you pick each time you install a package. And it gets worse installing the toolchain since mingw32 and mingw64 each have toolchains that target 32-bit and 64-bit. Now you’re up to five combinations.

But it’s what we got so we’ll have to make due. Hopefully we can simplify this a bit.

First, most people are on 64-bit Windows these days and for that, just select the mingw64 packages and the x86_64 toolchains. If you are on 32-bit Windows, go mingw32 and i686 toolchain. If you are targeting both 32 and 64 bit, simply add the other toolchain. But also make sure you add all the libraries for that architecture too.

MSYS2 starts with a pretty decent installer. It’s available from https://msys2.github.io/. The instructions on that page are a good description on how to do the initial setup. After finishing that, you still have no toolchains or libraries. To set up your development environment, run the following command. This gives you gcc and make, enough to build a hello world project.

pacman -S make mingw64/mingw-w64-x86_64-gcc

A couple of quick notes on that. The toolchain comes from the mingw-w64 project which produces both 32-bit and 64-bit compilers. Confusing? Yes. Also, pick the make from the default package set since it’s a more full featured make than the mingw32-make that comes with the mingw64 package set.

That should be enough to get started. Feel free to poke around and add library packages you’d like to use. Qt projects should just work with CDT’s new (and still very young) Qt plug-ins.

More later as we figure out the right configuration for CMake and for other libraries.

EclipseCon Europe 2016 So Glad to be Back

I spent a good chunk of the week trying to figure out the last time I was at EclipseCon Europe. The last thing I remember was spending a night in the Nestor bar until 5 a.m. with a handful of attendees, including Torkild, with the honored presence of Dave Thomas, the spiritual founder of Eclipse. That was 2008! It’s been eight years! I’ve missed so much. But I’m so glad that things in my life have cleared up to enable me to attend and I don’t expect I’ll miss another one for a while.

My biggest take away from the conference is simply the diversity of the people interested in Eclipse and the diversity of things happening at Eclipse. There’s still a large chunk of it related to the RCP platform and the IDE we build on top of it. But there’s really cool things happening with the Science and IoT groups as well. And the OSGi lego train display was mesmerizing but really showed off OSGi’s roots in the industrial space.

The week started with the CDT Summit on Monday. We had a good representation from different companies who build tools based on the CDT. We had a mini demo camp where they had the opportunity to show off what they’re doing. There’s some really cool stuff happening. It’s great to see them trying to make the complex world of embedded development simpler to understand through some great visualizations. We also noticed a couple of areas where the different vendors are building the same functionality. Those are great opportunities to collaborate in the open and the CDT project is very welcoming to new things. Finally it was very interesting to see how all the vendors really rely on our managed build GUI to simplify compiler and other build settings for users. That’s something we’ll need to carry forward into the new Core Build system (which I still need to blog about, stay tuned for that).

On Tuesday, I had my talk where I showed off Eclipse for embedded. It’s really a showcase of all the hard work we’ve done to simplify CDT for embedded development and to support open frameworks that users are using today, including Arduino, Qt, CMake, ESP8266, etc. It also shows why Eclipse is so important to us in the embedded world. IoT is a marketing buzzword, but it’s also an architecture that many of us have used in the past and which is growing thanks to accessible cloud platforms. These days, you need to program both your Arduino and your cloud service and Eclipse lets you do those things with a single IDE.

The rest of the week was spent chatting with my open source collegues, building relationships, getting a feel for the current state of the Eclipse IDE and where we need to go in the future. The Visual Studio Code keynote from Dirk Baeumer we very eye opening. I’ve been studying VS.Code for a few months trying to get a sense of what it’s appeal is and whether a desktop IDE based on a Web frontend is the new modern way of building IDEs. Now VS.Code isn’t an IDE, or at least it’s not as much an IDE as the Eclipse IDE is. We have a lot of tools that render different sorts of data visually in Eclipse and those high value things need to carry forward in any new world. But it’s food for thought and I’m going to invest some time to see what can be done there.

As Mike loves to say in his keynotes, Eclipse is many things. I think first and foremost, it’s a community. Technologies come and go, and individual people come and go, but there always seems to be a great energy when we come together. The task for us is to carry that energy forward into our day-to-day work and keep momentum going on all the great things we talked about. It’s not easy, but it’s why we need to be there.

Pushing the Eclipse IDE Forward

It’s been a crazy week if you follow the ide-dev mailing list at Eclipse. We’ve had many posts over the years discussing our competitive relationship with IntelliJ and the depression that sets in when we try to figure out how to make Eclipse make better so people don’t hate on it so much and then how nothing changes.

This time, though,  sparked by what seemed to be an innocent post by Mickael Istria about yet another claim that IntelliJ has better content assist (which from what I’ve seen, it actually does). This time it sparked a huge conversation with many Eclipse contributors chiming in with their thoughts about where we are with the Eclipse IDE and what needs to be done to make things better. A great summary of the last few days has been captured in a German-language Jaxenter article.

The difference this time is that it’s actually sparked action. Mickael, Pascal Rapicault, and others have switched some of their focus on the low hanging user experience issues and are providing fixes for them. The community has been activated and I love seeing it.

Someone asked why the Architecture Council at Eclipse doesn’t step in and help guide some of this effort and after discussing it at our monthly call, we’ve decided to do just that. Dani Megert and I will revive the UI Guidelines effort and update the current set and extend it to more general user experience guidance. We’ll use the UI Best Practices group mailing list to hold public discussions to help with that. Everyone is welcome to participate. And I’m sure the ide-dev list will continue to be busy as contributors discuss implementation details.

Eclipse became the number one Java IDE with little marketing. Back in the 2000’s developers were hungry for a good Java IDE and since Eclipse was free and easy to set up (yes, unzipping the IDE wasn’t that bad an experience) and worked well, had great static analysis and refactoring, they fell in love with it.

Other IDEs have caught up and in certain areas passed Eclipse and, yes, IntelliJ has become more popular. It’s not because of marketing. Developers decide what they like to use by downloading it and trying it out. As long as we keep our web presence in shape that developers can find the IDE, especially the Java one, and then keep working to make it functionally the best IDE we can, we’ll be able to continue to serve the needs of developers for a long time.

Our best marketing comes from our users. That’s the same with all technology these days. I’d rather hear from someone who’s tried Docker Swarm than believe what the Docker people are telling me (for example). That’s how we got Eclipse to number one, and where we need to focus to keep the ball rolling. And as a contributor community, we’re working hard to get them something good to talk about.

See you in Ludwigsburg at EclipseCon Europe!

It’s been many years since I’ve been to EclipseCon Europe. It hasn’t been from a lack of desire. There’s just been a few personal and business reasons that made it difficult. But this year, the road is clear and my talk, “Arduino, Qt, and Iot with the Eclipse C++ IDE” has been accepted as one of the early bird selections. I was really proud of that and can’t wait to get there.

This last year or so has been a very active one for me and the team here at QNX with our contributions to Eclipse. The Launch Bar, which proved popular with BlackBerry 10 developers, has been made more general and is now hosted at Eclipse for all projects to use. It greatly simplifies the launch and build experience, especially when dealing with remote machines.

We are actively working on support in CDT for Qt, which has proven popular with QNX customers and other embedded systems developers. The highlight is the addition of a QML editor which we will continue to add content assist and other features expected of good Eclipse editors. While these things are good for QNX users, we think these things will be good for all users of Eclipse and also support Qt on Windows, Mac, and Linux.

I have switched my personal focus on embedded real-time systems and working on making Eclipse and the CDT much easier for developers making software for those systems. My Arduino C++ IDE bridges the gap between professional embedded developers and the hobbyist working with Arduino boards. It’s a great exercise in providing a user experience that can satisfy both and I think we’re making strides there.

My talk will attempt to cover all of that. It’s a tall order, but I have a simple, yet somewhat contrived example that shows an Arduino board with sensors and lights talking to a BeagleBone board running QNX with a touchscreen showing status from the board. The BeagleBone then communicates with a MQTT server which is watched by a vertx.x Web server to show the same information on web page. All of that is built with Eclipse and the massive ecosystem we’ve built over the years. It’s a great showcase.

It should be a great time. It’ll be good to see a lot of my European friends I haven’t seen for years or have only met on mailing lists or who I’ve never met but have an interest in the CDT and other Eclipse IDE projects. We have a CDT summit planned for the Monday and I hope to see everyone there and share what we’re planning and to see what you’re interested in.

It will be a great week. And now I really can’t wait!