Atex Blog

Thank you for subscribing

Follow The Atex Blog

All Posts
Latest Posts
Most Viewed Posts


Atex Homepage

Building a pleasant developer experience

As an Atex engineer, I would like to share a couple of insights about Atex Polopoly Web CMS projects. In order to build high performance websites with a limited number of engineers the developer experience must be first-class. Over the last year, the Atex Web CMS platform powered by Polopoly has released significant news in this field.

The first impression is installation. Polopoly has one single command to install and run the software. If it notices that the binaries are stored on the local machine, it will not download them. If it notices that the project code is compiled, it will not compile it again. If it notices that the content is imported, it will not import it to database again. Yet installing from scratch every build in a Continuous Integration (CI) is a one-liner. This is what everyone should expect from a true build system.

The developer environment does not share the same goals as a production environment and is therefore in many aspects differently optimized.

Perhaps the most important productivity factor is the turnaround time from code change to browser request. Polopoly scans the incremental compilation of your integrated development environment (IDE) and loads changes on the fly. There is no deployment step, just refresh the browser. The load time can be cut even further with commercial Java Virtual Machine (JVM) plugins.

Hot deployment does not stop with Java byte-code. Polopoly content will be validated, boot-strapped and imported automatically, not to mention instant refresh of HTML templates, static web resources and Polopoly configurations. This is fast turnaround in a complete package.

By the way, there is a single log that outputs programming errors. A pleasant developer environment should require few context switches.

A lesson from real-life projects is that things don't work before they can be seen with your own eyes. With the new Polopoly text content format, it has become increasingly fast and easy in projects to create demo sites. The purpose of the demo site is to display features as they are developed. Apart from having test images/video/articles, it should look like the real site. It means that not only the product owner can click around and transparently know the state of progress, but also new developers can join the project and get an identical view from day one.

No one wants to do boring and monotonous QA. Providing the ability to write concise test content data reduces most integration tests to clean assertions. The test acceptance module runs a separate Polopoly instance and individual tests depend only on their associated content data. These tests are automated, isolated and repeatable; hence they give developers information about regressions. Well-covering test suites allow short release cycles.

The highly optimized Java platform has widely become regarded as the strongest link in the Java ecosystem. The JVM is today a polyglot environment with at least 80 programming languages [1]. With the strengths of Polopoly’s plugin system you can write plugins in your favorite programming language such as Scala, Groovy or Clojure. One word of caution: Self-developed plugins are not automatically covered by product support until they are validated, so you need to know what you are doing. If so, add the necessary language dependencies to your plugin.

Most of the features above were released in Polopoly Nitro.

Happy coding!


Bookmark and Share