Adobe Experience Manager (AEM) is an enterprise web content management system that, like many other enterprise applications, is a complex piece of software to set up and configure.
We can't eliminate this complexity completely, but we can reduce it for many use-cases. AEM OpenCloud is an open source project being led by Shine Solutions that automates the setup of a complete ready-to-use AEM environment in the cloud within 15 minutes.
However, testing and verifying that an AEM installation is working correctly is laborious and time-consuming. Done manually, testing can certainly take longer than the 15 minutes required to actually build the environment in the first place.
Fortunately, automated testing was identified early on in the project as an important part of OpenCloud's modular design, as is made clear by this diagram created by Cliff Subagio, one of the project founders:
However, it's one thing to say that testing is important, it's another thing to actually do it. In this post I'll talk about why and how we used InSpec to implement automated testing in OpenCloud.
Anyone who’s ever had to support server infrastructure of any kind knows the value of having a comprehensive, automated monitoring solution in place. With this in mind, we have begun to roll out the New Relic platform to monitor all our AWS based servers. New Relic comes with many great monitoring metrics straight out of the box, but still has the flexibility for software developers to create their own plugins for customized metrics on just about anything your users will care about.
A little while ago I did an internal talk at Shine describing the use cases and benefits of using asynchronous web technologies. As part of the talk I showcased a little demo I'd put together called Haloworld.
Haloworld is a simple web-based chat application with a chatbot called Hal (inspired by the infamous movie bot) who can answer various questions you throw at it.
At the time, I used Atmosphere on top of Jetty for the demo, in order to illustrate that these sort of applications are now easy to build on top of the JVM. While it was relatively painless, it still seemed quite heavyweight compared to using something like Socket.io or SockJS with Node.js.
Not long afterwards, I came across Vert.x, a new JVM based framework for developing highly scalable networked applications. Vert.x seemed a much better fit for Haloworld, so I decided to port the demo across to it. You can find the results on our Github repository along with details on how to get up and running with the demo.
On an early Rails project I elected to use instantiated fixtures. My rationale was that it would make my test code cleaner and easier to understand. Sure, test_helper.rb warned me that they would be slow, but how bad could it be?
This is a short one, but we've had to do it a couple of times so I thought I'd put it up.
As you may be aware, Rails 2.2 introduced a new format for test names. Where you once might have had:
Not that long ago I gave a demo in which I showed how it was possible to control iTunes from my laptop using native Ruby code.
This was all possible because of a great little gem called rb-appscript.
rb-appscript is a really neat Ruby to AppleScript bridge...
A while back we had a Flex client that needed to be able to display search results received from a server. The server was designed RESTfully, returning XML results to the client. The Flex client would display these results nicely to the user, and...
Following on from Tom's post on Handling AJAX Errors using Prototype & Rails, I thought I'd take a look at how to ensure that all Ajax calls are subject to decent error handling - or any other sort of handling you want to do.
I recently did a presentation to the Melbourne Ruby Users Group entitled 'Flex and Rails'. It demonstrates how we've used Flex to build a rich web interface for a real-world Rails application. It includes a demo and code snippets. I've made a streaming screencast of...