Close
Written by
Konrad Łukasik

Konrad Łukasik

Technology Radar

Nowadays, in a fast-moving world, it is increasingly difficult to stay up-to-date with technology. From our ‘IT’ perspective it is important to know what’s available on the market – sometimes out-of-the-box and often for free – to not reinvent the wheel or repeat mistakes of others. As Tim Lister said “You’ve got to surf the technology wave, or you’ll drown“. Lastly, for you own career, it is worth knowing in which direction the world is evolving to develop your own skills to gain future work benefits.

Me and my fellow architects really liked the idea of the technology radar. It was originally publicized by a company called ThoughtWorks. The radar itself is a circle with dots representing different technologies. Each dot is placed in one of four quadrants logically grouping elements (Techniques, Tools, Platforms or Languages & Frameworks) and in one of four rings indicating its trend (Adopt, Assess, Trail, and Hold). The hold ring means to stay away from a particular technology because it has known flaws. The assess ring indicates new promising technology, but one that is not fully understood yet, so some investment (like a development spike or reading a book or watching a presentation) is required to assess its usefulness and impact. The trial ring is for technology you understand but have never tried in real project (enterprise, in our case), so it should be proven first in a Proof-Of-Concept or small project to reveal its weaknesses. Finally, the adopt ring, to quote Mike Mason, is for when technologies are so good that “I will make fun of you at the pub if you aren’t using them”. A more detailed description of the radar and on how it is built can be found here.

So, we built our own radar; here are the results with a brief description for some of the technologies. We hope it will serve you well!

Radar

Techniques

[Assess] 1. Visual regression for testing – The growing graphical complexity of web applications has triggered invention of testing tools for visual regression. CSS Critic, dpxdt, Huxley, PhantomCSS, and Wraith are a few examples.

[Assess] 2. Reactive Frameworks – Most probably you have heard about the Reactive Extensions (Rx) library for .NET. It allows one to define complex, asynchronous workflows on events. Rx is particularly good at describing pipelines of data. Some say it is “LINQ for events”. Declarative and functional code are certainly easier to understand (everything in one place) and test. Currently, the reactive paradigm enters other languages (like Objective C, Java, or JavaScript).

[Assess] 3. Micro-services – To some extent this is a reincarnation of SOA. A new architectural style oriented towards building applications as sets of services, independently deployable and scalable, even allowing implementation in different languages and using diverse data storage (like NoSQL). Obviously micro-services are “small“, but interestingly it’s the functional size that is limited, not the technical size (LOC, memory, whatever). More on Folwler’s site.

[Assess] 4. ESB – We broadly share the views of Jim Webber and Martin Fowler of ThoughtWorks regarding the use of an Enterprise Service Bus. Poor implementation may lead to overly-complex middleware that can represent a significant risk to a system. The integration and orchestration of these products requires Big Up-Front Design and specialised skills from the team. However, we do not totally rule out the Service Bus concept – lightweight SB (MassTransit or NServiceBus, for example) providing reliable message routing might be the best option in some scenarios.

[Trial] 5. Configuration in non-XML files – We have learned that configuration kept in XML files is troublesome, error-prone and difficult to maintain. Now we are experimenting with other formats, like INI and DSL, to find the best one.

[Trial] 6. Feature toggles – The concept of controlling application functionality through configuration setting is getting more common due to the popularity of Continuous Delivery.

[Adopt] 15. Enterprise Scheduler – In every enterprise system there is a need to run certain jobs at predefined times; for example, one may need to generate invoices at the end of month or send task-related e-mail notifications to users. It is unwise to write such a scheduler on your own whilst paying attention to high availability or load-balancing. The preferred approach is to use a library like Quartz.NET.

Tools

[Hold] 16. TFS – Almost everybody knows that TFS sucks! – auto-merge is poor, workflows in XAML are difficult to edit and it requires “hacks” (like baseless merges) to live with. Unfortunately, it is not always our decision to select Version Control and a CI system.

[Hold] 17. Jenkins – Objectivity’s chosen CI platform is TeamCity; therefore, we migrate all Jenkins projects to it and Jenkins itself is “on-hold”.

[Trial] 18. TFS 2013 – “Some light at the end of TFS tunnel”. A product worth evaluating since Microsoft is currently a much more open, community-oriented company.

[Trial] 20. JS code analysis – The reality is that we write more JavaScript code. Its quality needs to be built-in if we want to have high-quality from the start. Tools like JSLint, JSHint and Plato help us keep code quality at high level.

[Trial] 21. CSS code analysis – CSSLint is a tool to help point out problems with CSS. It does basic syntax checking as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency.

Platforms

[Hold] 26. Windows Workflow Foundation – Defining compound workflows visually is not a trivial task. World is going ‘reactive’ and we feel it is much better way to define and maintain essential complexity. Learning curve for the tool is steep and migration support is poor. In short, it doesn’t provide enough power, flexibility, or productivity gain to justify its use.

[Hold] 27. CMS as a platform – A pattern we now try to avoid due to our experiences in Ascentric / Royal London (Orchard) and Imex (Sitefinity). Custom development on CMS foundation slows us down and does not give much in return (only should-have or could-have functionality). Want to know more? Talk to your colleagues from those projects.

[Hold] 28. SharePoint – Simple functionalities are easily achievable in SharePoint but difficult ones are often a nightmare for developers. The product itself is cumbersome and it takes a long time to set up a SharePoint solution on developer’s machine. The benefits do not outweigh the drawbacks. For those and many other reasons, we will try to avoid it in future.

Languages & Frameworks

[Trial] 35. DSC (PowerShell 4) – In October 2013, Microsoft released version 4 of PowerShell. One of the new features is “Desired State Configuration” (DSC) – declarative language extensions that enable deployment and configuration management. What DSC handles perfectly is the topology. Microsoft is investing strongly in PowerShell and there are already several resource kits available giving you the means to: configure IIS, change Active Directory, install SQL Server and manage a cluster or firewall rules. We currently try to incorporate it in our CI framework (a.k.a. PSCI). Beware: PowerShell 4 cannot be installed and used in every environment due to the limited versions of the Windows operating system that it supports.

[Trial] 36. AngularJS – This is, in our opinion, the best JavaScript MV* framework on the market. It is a full MVC / SPA framework. It defines the structure of code but it is not too restrictive in comparison to other frameworks (like Backbone). It has a corporate sponsor you have probably have heard of – Google. The latest popularity graph on Google Trends shows that it is far ahead of other frameworks.

[Trial] 39. CSS frameworks – Building a CSS for a complex, responsive web site can be challenging. Luckily, CSS frameworks exist and Bootstrap is one of the most widely used. It has a great grid system, base styling for most HTML elements, is built with LESS and has good documentation.

[Trial] 40. WebAPI over WCF – RESTful services (and therefore, by extenstion, Web API) are lightweight, truly interoperable (being based on HTTP), scalable (reverse proxy cache), and faster (no XML payload). That’s why they are our preference.

[Adopt] 41. JS MV* frameworks – Presumably every enterprise-class web application with rich UI needs one of the JavaScript MV* frameworks to organize code and provide, at the very least, a ‘data-binding’ building block. There are many options, which is both a blessing (we have plenty to choose from) and a curse (too many choices may lead to frustration and confusion – see Yet Another Framework Syndrome). Some implement an MVC pattern (AngularJS), some an MVVM (KnockoutJS) – hence the name MV*. Fortunately, sites like http://www.ToDoMVC.com, providing implementation of the same functionality in different frameworks, might help you to choose the right one.

[Adopt] 43. PowerShell – Microsoft’s task automation framework consists of a scripting language built on top of the .NET Framework. It is the bread and butter of release engineers and Objectivity’s language of deployment automation, as an interpreted language shortens the development-test cycle. It is appearing more and more often in our daily work and is definitely worth knowing.

Share this post on

Tags

Leave a Reply

Your email address will not be published. Required fields are marked *

Read next

The Horror

This was a regular morning on a regular Wednesday. I was heading to my lab (which is really a standard office that I share with one very talkative guy… a “lab” sounds more professional, though), when I heard a heart-breaking cry from one of the rooms. When I looked inside I saw a terrible scene. One of my colleagues […]

Read more