A Vagrant SaltStack example

Vagrant is a wonderful tool for building realistic development environments, and part of that is being able to use the same configuration code as production systems with tools like Puppet, Chef, Ansible, and SaltStack.

To that end, I’ve built a proof-of-concept / sample project to help myself and others bootstrap projects using a Vagrant SaltStack combination to produce a simple and lightweight virtual machine.
Continue reading →

The DevNotes book, update April 2016

This month’s update to Hutch’s Big Book of DevNotes is completely behind the scenes.

I’ve been working on…

  • collating notes for the AEM book – yes I’ve finally made a start
  • working with OpenStack and DevStack for a sandbox environment
  • Experimenting with SaltStack and Vagrant for development tooling
  • generating images with Processing – very much basic stuff so far but it’s proving useful to be able to programmatically create images as well as being a lot of fun
  • Writing integration tests with Spock/Prosper for AEM

None of this is release-grade material for the book, yet. In fact, the AEM notes are primarily an export of my bookmarks.  I’ve also started writing a reference guide to Sightly. I haven’t yet decided if I’ll spin this off as a separate book (there is enough material) or keep it small enough to be a chapter or two of this book.

You can find the book on the book page.

AEM best practices for component development

Four years ago I wrote an article about best practices when developing CQ5 components. It’s time to update this for Adobe AEM 6. These ‘best practices’ focus on component development – the craft of building the front-end of AEM for the author and the end-user.

They should help if you need to know how to structure code within AEM and use the available features to your advantage. There’s lots of technical documentation on the product itself and the core open source frameworks; elements of these are useful for developers.

Mostly, this guide only applies if you are using pure, clean, ‘vanilla’ AEM without the addition of exotic ‘helper’ frameworks, most of which are not needed. Continue reading →

The DevNotes book, update February 2016

This month’s update to Hutch’s Big Book of DevNotes is fairly minor. I’ve added some new content to help with testing in Varnish, particularly how to test that you’ve removed a header. I’ve also spent a bit of time on the overall layout, so that printing individual chapters makes more sense. Putting the chapter name in the header helps, as does having the free-culture license in the footer.

Continue reading →

The DevNotes Book

I’ve put together a book containing a few chapters on some of the technology I’ve been using based on notes and actual experiences. It’s early days, and I plan to improve and expand upon this beginning, but I hope that it’s useful. The topics I’ve included for this initial draft are Docker, LaTeX, Magnolia CMS, and Varnish Cache v4, and while there are plenty of notes and pages both online and in print for the first two, there’s scant little on Varnish 4 (it’s mostly for earlier versions), and not all that much on Magnolia CMS either beyond the official documentation. I hope that you find something useful here that helps you.
Continue reading →

Agile performance testing

At some point in the SDLC it becomes necessary to carry out performance tests to make sure that what you are building will function to an acceptable level. 

There are a few things you can take from this statement:

  1. “at some point” doesn’t have to be the end of development
  2. it should be part of the lifecycle
  3. you have to do it, it’s necessary
  4. tests don’t just happen, you have to perform them
  5. “what you are building” implies that you focus on the things you can control
  6. and finally, “at an acceptable level” means you should have a goal or objective.

In the vast majority of projects, these considerations are left until the end. I think it’s worth discussing the implications of this, as it’ll really help make the tests worthwhile and help you get the most out of the developed software.

Continue reading →

Steam Link and Steam Controller

Finally, after many months of waiting, I received my Steam Link & Steam Controller. For those who don’t know what this is, the Steam Link is more-or-less a wireless HDMI connection with some bells and whistles, a sort of reverse Chromecast. It connects to a PC and streams the display, audio, and controls so that you can use a living room television without having to drill holes in walls and run cables, or move the computer. Because it’s for gaming, it needs to be extremely low latency and for the most part it succeeds. The controller, as you might have guessed if you haven’t already seen one, is a wireless handheld device designed to work with traditional keyboard and mouse games. It too succeeds in some ways, but both have flaws and rough edges that really need polishing to make it appeal to those used to more mainstream offerings from Sony and Microsoft. Continue reading →

A simple link checker built with Rust

I needed a lightweight, simple, fast tool to check a long list of URL links from a plain text file, so I decided to write a small application in Rust. If you’ve not come across Rust before, it’s a high-performance, low-level language that offers memory safety without garbage collection, type inference, and great concurrency support. It’s a young language but shows great promise, and is ideal for this kind of application.

Having produced a simple first version of the application and posted it on GitHub (https://github.com/antonyh/link-checker) I thought it might be useful to look at the code and explain how it works.

Continue reading →