fredag 6 november 2015

JetBrains shot themselves in the foot with their new pricing model

I've been an avid Intellij user since ~5 years back when I finally took the dive and walked away from Eclipse. Suffice to say I've been very impressed with the tooling and consider myself as a better developer when I'm armed with it.

The IDE has also been instrumental in showing me the "right way" to develop with it's hints, auto completion etc. I can therefore probably say that it has helped me shape the type of developer I am today and how I like to get stuff done.
Jetbrains domination over the JVM IDE tooling market has been all but complete as nowadays you hardly see any other IDE's being used, especially not if you look at what conference speakers and other types of influencers use.

This type of monopoly is always dangerous as it is really easy to get locked up with one vendor which is seldom a very good thing. Recently Jetbrains announced their new pricing model (latest update) which will mean that it becomes quite a lot more expensive for the typical Intellij Ultimate user. The backlash was not late to be seen in their forums and on blogs as users were anxious about how a "rent-your-IDE" model would hurt them in the end.

I can only speak for myself, but the first thing I did after I read the announcment was to give Netbeans a second (or perhaps tenth?) chance at winning me over. What I saw was a fairly complete IDE that except for some styling warts nowadays seems to work pretty well. We're all still waiting for the ES6 support, but once that is in place I think that I definitely could use it during my day to day work.

Just this day another thought crossed my mind though:

Intellij IDEA comes in two flavors, a community edition as well as the Ultimate edition.
If you look at the comparison matrix you'll see that the biggest missing features of the free community edition are:

  • HTML / Javascript support
  • Server support (Run Tomcat / JBoss / Websphere et al.)
  • Framework support (Spring beans / xml context, Java EE etc..)

Now I don't know about you, but these features are stuff that I'm more than willing to give up as the typical software stack of a JVM developer has changed quite radically lately.

  • As we're all building runnable JAR types of applications you really do not have the need to manage the typical Tomcat / Java EE servers anymore.
  • Frameworks are loosing their significance as well as more of the open source world is moving towards a library mindset rather than heavy frameworks to adapt to. Take Spark, Ratpack, RxNetty, Spring boot etc as examples.
  • HTML / Javascript is a bummer to loose, but personally I've been using Sublime coupled with some favourite plugins for that kind of environment. Sublime is mature, fast and has a lot of momentum going for it. It's a perfect solution to HTML/JS development with its abundance of linters, language and framework plugins etc.

It just strikes me that a feature complete IDE's is not as relevant in the modern JVM developer toolbox and it will be interesting to see how adoption of the new pricing model will turn out.

I'm predicting that the outcome of the pricing change is that modern JVM developers will probably do one of the following:

  • Switch to Netbeans one it's Javascript support is up to par
  • Use Intellij Community coupled with Sublime text for the front end development
  • Toss the JVM, drink the cool-aid and join the Node team

And no Eclipse, we will not let you fool us to coming back again. Don't even consider yourself as an alternative.

What's your take?

tisdag 14 april 2015

Ok, ok I get it... So this Node thingy IS actually quite cool...

I consider myself a polyglot developer who typically uses the best tools for the particular task at hand. Nevertheless when it comes to actually building production ready applications my main language has historically been within the JVM, more times than not relying on the always trusty Java ecosystem with it's abundance of libraries and frameworks.

Today I really got one of those OMGOD moments when you realize just how easy alternative technologies makes your life comparing to what you usually have to keep up with.

At my current customer project we unfortunately have to deal with a remote external SOAP service, which in my and most developers opinion is a protocol born out of hell and is the perfect example of an over engineered solution to something that should be pretty simple.

After dealing with a botched release due to threading problems and bugs within the SOAP framework we used I intended to switch to CXF, which is probably the most popular JAX-WS implementation in Java land.

Many hours later I had a working client after tearing my hair out fighting questions such as:

  • How do we authenticate using WS-Security
  • Which JAR's to include in the Maven build? (CXF has a lot of modules)
  • How to make the JAXB code generation behave well and produce the types of classes we need
  • How to intercept and log relevant request / responses over the wire
  • How to cope with threading, JAX-WS is not thread safe while CXF as an implementation claims to be
  • How to configure CXF to use our logging framework of choice
  • etc...

You get the idea, a lot of ceremony just to create something that could send structured data over the wire and parse responses into something that we can work with.

Just out of curiosity I went ahead and started investigating how you would create a soap client in Node.js land as I have previously built a couple of lightweight internal Node apps for testing, service bridging etc. My first thought was that the cool JS kids would probably never even poke a stick at something like SOAP, so I did not expect to find any good NPM modules for it.

Turns out that even JS developers aren't immune to the protocol madness of SOAP and someone actually went ahead and wrote a very clean and simple client and service module. After reading the example ( and about 5 minutes of experimenting I was up and running. This was what it took to create the same thing I fought for hours with CXF.
npm install soap

  var soap = require('soap');
  var url = 'gateway.wsdl'; //local file, could also be a remote http url
  var args = {};

  soap.createClient(url, function(err, client) {
    //WS-Security UserNameToken out of the box
    client.setSecurity(new soap.WSSecurity('myUser', 'myPassword'));
    //GetProducts is an operation in the wsdl
    client.GetProducts(args, function(err, result) {
      if (!err) {
        //Do something valuable with the response, for now just log.
        //Each XML element in the response would become a corresponding field on the result object
        console.log(JSON.stringify(result, null, 2));
      else {

So, I guess Java and CXF lost this one. And for Node... well it's something you probably should consider learning ASAP. Even if you're a grumpy old-school JVM developer like yours truly.