The latest expert opinions, articles, and guides for the Java professional.
Not sure about you, but I’m personally one of those guys who swears by an IDE and usually doesn’t like to work with just a text editor. My IDE decreases development turnaround time for me.
However, I’m getting sick of everything being crammed into one window/application (see image above). And what if you suddenly need to use a new tool, but it is not integrated into your IDE? Or maybe you like to build a Maven project from command line because the IDE integration doesn’t make building easy. Just Alt+Tab (or equivalent) to the right terminal window, press Up to get last command again, and rebuild.
Stop! Well, no, don’t stop. I can’t stop doing this, but I want the UX to be better. What if we had a tool that had a wider awareness of our development environments than what single applications can bring? What if the tool just ran in the background, not requiring any window to be open, and was aware of our projects and tools?
The WIDE (Wired Development Environment, called so because it appears to be “wired” into our OS and because it knows how to wire different projects together) is a Humane Interface. It mostly consists of commands, not UI. And when possible, it doesn’t even make you type a command. It monitors and can communicate with other applications. Based on this, my future WIDE should:
- Enable the discovery of wiring between different artifacts in your environment
- Let you run something like Incremental Builds for your whole environment
- Give programmers a humane interface for software development work
- Provide more helpful notifications/pop-ups
Let’s get down to some examples, starting with what it would do after it is installed and starts monitoring stuff. I will use mostly Eclipse & Maven stories as a base for my examples, but the WIDE could have plug-ins for all kinds of tools.
Reason 1: A WIDE would automagically discover artifacts, wires and incremental builds
When you open up Eclipse with a workspace, the WIDE will remember this workspace, and scan it for “source artifacts” (checked out projects). If any of those “source artifacts” happen to have a pom.xml, it will remember that too and analyze it.
If any of the POMs have dependencies between them, the WIDE will mark it down as a “wire” between the projects. Later you can ask it for a visualization of the wires if you want.
Let’s say one of your projects cannot have all the Maven dependencies on the classpath in the normal way (khm PDE khm), and has to use copy-dependencies or something similar. The WIDE will detect that.
If the same artifact being copied now also appears as a “source artifact” somewhere, there will be a wire between the two projects. Whenever you successfully build the source project (just by running Maven like you normally do), it will copy the single fresh artifact (assuming the Maven GAV matches), without you having to trigger a whole Maven build in the other project. Also, it knows that Eclipse is open with a workspace containing the project, it will refresh that specific folder in Eclipse.
Similarly, what if one of your projects has a .zip “assembly” that contains native binaries for different platforms. The binary comes from some other project that you want to build for your platform on your own machine. But you don’t care about the other platform binaries while you are developing. If you have the .zip assembly exploded somewhere (maybe you need to tell your WIDE about this), it can wire the two together again and copy the .dll, .so or .dylib over when you build the native code, following whatever rules the Maven “assembly” had, but just for that single file.
And just to mention it: If you have JRebel installed, your WIDE will figure out how to configure it for each Java project to give you as little downtime as possible.
Reason 2: Devs could work with a more humane Command Line Interface
The WIDE will have a single shortcut key that will open a command prompt where you can type commands, which are provided by plug-ins; the same command may have specific implementations for different tools. Here’s what I imagine to be able to command:
build <project name>
If the WIDE knows where <project name> is, but not how to build it, it will ask how to build it and remember that. If it doesn’t know where the project is, maybe it knows where you usually check out projects from (e.g. bitbucket.org/yourcompany) and will check it out, asking you which workspace you want to put it in.
If it knows everything already, it will just run the build, maybe opening a terminal if you want.
open <file name>
This command will use search indexes built into your OS or IDEs (or maybe the WIDE will have its own index) to quickly find files matching the name. If you already have it open in an editor, that editor will be opened. Otherwise, it will be opened with an IDE that contains it in its workspace (similar to Open Resource in Eclipse).
open type <type name>
Similar to “open <file name>”, it will do a search-based on type name. Likely it will ask all open IDEs if they can find that type (similar to Open Type in Eclipse).
You could also assign specific shortcuts to partial commands, e.g. Ctrl + Shift + T would open the command prompt with “open type “ already filled in (or maybe it will have a custom UI provided by a plug-in).
Reason 3: Devs would get helpful, actionable notifications
You could opt-in to have your WIDE give you helpful pop-up notifications in your peripheral vision (maybe you don’t want them if you only have a single monitor). The pop-ups would mostly all be actionable, and there would be two shortcut keys that could give either positive or negative answer to the proposed action, without changing window focus. For example Ctrl + Alt + Y for “do it!” or Ctrl + Alt + N for “go away!” (and Ctrl + Shift + Alt + N for “go away forever”). The actions would become available a short time (2 seconds) after the pop-up showed, to avoid focus stealing by another pop-up you didn’t see yet.
Here are some example pop-ups:
- <project name> source was modified. Rebuild? Yes / No
- <project name> passed unit tests. Commit and push? Yes / No
- Rewiring <artifact A> to <project B> in 3 seconds… Cancel
- Change in <project A> caused compile errors in <project B>. Open files?
Final thoughts: the future is with human interface
I strongly feel that human interface is the future. Applications with lots of things crammed into a single window do not always give a great user experience. The WIDE would have a humane interface with a rather narrow focus, but there have been other projects that are meant for general computer users, such as Enso and Archy.
Your new WIDE would also make use of the fact that some tools have forced users do things their way (like Maven), and thanks to that fact it could analyse the dependencies between projects in a rather comprehensive way. But to not much avail: now you would be more empowered to escape the limitations provided by those tools in the first place!
Leave a comment