25 comments

[ 3.2 ms ] story [ 63.4 ms ] thread
I believe this is the third Radar in a row with Snowplow (https://github.com/snowplow/snowplow) on it - really stoked about that. I liked the reference to "Scala, the good parts" too.
"Scala, good parts" - is classic mentioning in that pdf. I couldnt agree more on that. As a startup, we had burnt ours several times with the mix of people who had "scala-eye" and dont.
I really think Docker should be more toward the center of the radar.
In six months, since the Jan radar, it went from Assess to Trial, so that's a pretty rapid advance.
Nice to see some tools that I've really enjoyed using lately. Docker, Packer and Ansible.
Wow that is a really high quality and nice list of interesting technology trends. Saw some very interesting service related tools that I want to look at it in more details. Thanks!
I'd love to be using Java 8 but I can't because we deploy to an app server. The latest version of the app server has some critical bugs that prevent us from upgrading and we can't use Java 8 until we upgrade. We also can't switch to a different app server because the app server dictates which implementation of JPA you use and we wrote a lot of code tied to the implementation.

This makes me wonder if Java EE app servers have ever been marked as "Hold" on any of the previous ThoughtWorks Tech Radars. I certainly wouldn't recommend them.

The enterprise loves J2EE, given the tooling they provide to manage resources, application deployment and monitor usage.

For them to go on hold, Java needs to go on hold on the enterprise.

At least on context of the enterprise, I very much doubt they will ever go away. Only as a side effect of the said companies replacing languages.

Just like CORBA only went away, as the same type of companies moved from C++ to Java/.NET ecosystems.

I would think that such app servers would fall under the "the big enterprise solutions" that is "on hold" in this radar.
Java EE 7 web profile is pretty light. If you consider they put JSF on hold then it points to other bits of Java EE that are probably persistent:

Java EE Web profile, hibernate (via JPA), JAX-RS. That's a pretty good stack.

No JSF, servlets, JSP or EJB and it's all good.

As for Java 8 and containers, what are your issues? Just interested.

Stories like this really make the case for open source app servers for me. The breadth of functionality they offer is so wide that when something does go wrong not only is it way easier to debug the issue and find out whether your code or the application server is at fault but also once you found the issue you can actually fix it yourself.

We run a custom patch set against our application server (which we contribute upstream) and I couldn't imagine using a closed source app server. We have other teams that work with closed source app servers and they really envy us.

We are using an open source app server: Glassfish.
Can't you just backport the Java 8 fixes and build from source?
I haven't researched it, but I figure if the glassfish developers themselves aren't willing to put in the effort, it must be a big effort.
What is vumi? Google top 2 results:

vumi.org - mobile phone-based voter registration system.

github.com/praekelt/vumi - SMS messaging engine, active, but 164 stars only, no where near the other "adapt" platform of Hadoop 2.0's popularity.

Yep, it's the Vumi.org one -- they tweeted that it was great to see themselves moving up ThoughtWorks radar;

https://twitter.com/vumiapp/status/430605363360960512

But ThoughtWorks describes them a bit different than your synopsis:

> Vumi facilitates SMS, IM and USSD interactions between companies and their clients, health services and their patients, governments and citzens, and more. Vumi integrates with telcos and allows you to build apps on top of it easily. You only have to pay for carrier charges.

Hah. Worked with ThoughtWorks for a year as a client on a particular project, and fought tooth and nail for many of the things highlighted here (Postgres, living style sheets). Liking this vindicated feeling right now
Can anybody comment what's special about ThoughtWorks besides that one of its founders had published some popular books? Isn't it just yet another CRUD app dev shop?
Disclosure: An ex-employee who loves the organization.

CRUD is a very generic label that could be applied to many interesting apps. I could classify Facebook as CRUD, but that does not mean that it is a seriously exciting system from an engineering perspective. There are a gazillion factors that make large systems interesting and at TW I have had opportunity to work on what I thought were interesting systems (though obviously not at the scale of Facebook)

The single most important thing that I consider special about TW is their Social Impact Program http://www.thoughtworks.com/social-impact.

Crux of the story. Whether an organization is special or not is a multi-dimensional question subjective to individual perceptions.

No they're not. I've worked with them. They are pretty good at turning around typical enterprise tech platforms that are in trouble. I'm not talking about CRUD stuff but heavy integration and workflow stuff with hundreds to thousands of tables that scales to thousands of concurrent users. They know the tech very well and know how to get from A to B cheaply which is incredibly difficult. They know how to organise large teams as well and have a good tech relationship with a lot of vendors which is really important.

Not joking but what we threw at them had a codebase that would scare a lot of people and they sucked it up and spat it out in good shape and they did the same with the team too.

As for Fowler, the analysis and formal descriptions he wrote up for PoEEA are rather good. Read the book at least once. You'll understand why things like hibernate were written and what problems they solve.

Datensparsamkeit under "assess"? As in "Let's assess whether we'd like to follow the law"?
;-) More, assess whether to apply the approaches outlined in the German legislative framework to other jurisdictions, e.g. the US. Could be both a risk mitigator and a market differentiator.