Much of my time over the past couple years has been spent working with DevOps tools such as Ansible, Puppet, Vagrant, and Packer, rather than the traditional programming I did previously. Since I work in the defense industry, there are some unique challenges applying these tools and DevOps techniques. I had a recent conversation with a colleague about these challenges and whether it DevOps is worthwhile in our business. Of course, I think it is, and I tried to explain some of the reasoning.

In a previous article I discussed why Apache Camel is a useful tool for building small modules to perform integration independent of any of the pieces being integrated. With that out of the way I can go straight into showing an example of using Apache Camel’s content enricher. The basic flow of our Camel route is to listen for data to come in via a publish-subscribe messaging destination and send it back out in a format that another consumer is expecting.

This is the third of three articles on using Apache Camel with its content enricher to handle transforming data on its way between two applications. The first article discussed Camel and its positive attributes; the second provided an example of using content enricher a straightforward way. To recap, Apache Camel provides a wealth of components and processors to interact with applications and services in all kinds of ways, including publish-subscribe messaging, REST, SOAP, file transfers, email, and many more.

A colleague and I were working through using Camel as an event-driven data router. Part of the work the router had to do was fetch additional information from a REST web service. This was a natural fit for Camel’s content enricher, but we had to work through a few bumps along the way, so it was a great learning experience. Apache Camel Let me start first with a brief discussion of Camel and the content enricher pattern.

I was reading an interesting article on DZone recently that pointed out how many different programming languages have a rich community producing modules that are available for reuse. In some cases this community is not strictly affiliated with the creators of the language itself. It’s instructive to see just how many examples there are out there. This is just a few that popped into my head without thinking hard. Perl has the Comprehensive Perl Archive Network (CPAN).

I happened to be working on a REST microservice recently, and ended up implementing it in the Go programming language. I was pleased by the experience, especially when it came to integrating the HTTP support with handling of zip archives. One of the functions of the microservice is to accept files in ZIP format and to process the files it finds inside. I wanted to find a way to avoid generating a lot of temporary files on disk, since once the service was done with the uploaded file it didn’t need to hang onto it any longer.

Suggested Zone: Agile TLDR: For a system to survive long-term incremental development, it helps to have one concept that stays true. I’ve been thinking and writing about simplicity in architecture and design as a result of reading Niklaus Wirth’s article on programming languages. The first article was about how arguments over design can result from having multiple kinds of simplicity, while the second was about the need for architects to communicate using one diagram.

Zone: Agile TLDR: Useful Git fixes for special circumstances. In a couple previous articles, I talk about features that go beyond the first steps in Git. In the first I discussed the working tree, index, and HEAD. In the second I discussed exclude and interactive add. Recently a couple other features became useful to me: bundle and retrospective branching. As always, I will discuss the “why” of the feature and how it should be used but much more information is available in places like this one.

Suggested Zone: Java TLDR: Why do we argue so much about which way is simpler? I was reading Niklaus Wirth’s On the Design of Programming Languages and was struck by his discussion of simplicity. It appeared to me to apply to a number of concepts in architecture and design beyond just programming languages, and even to explain why we so often disagree about design choices. One of the key insights of his paper is that there are multiple kinds of simplicity.

I was reading Niklaus Wirth’s On the Design of Programming Languages and was struck by his discussion of simplicity. It appeared to me to apply to a number of concepts in architecture and design beyond just programming languages, and even to explain why we so often disagree about design choices. To start, I want to write about a principle I think is very important for architects and one that has been helpful for me in architecting large systems.

Suggested Zone: Cloud TLDR: Despite the name, VRRP isn’t just for router redundancy. Over the past few articles, I’ve been showing the details of the Virtual Router Redundancy Protocol (VRRP). In the first article I introduced the technologies. In the second I showed a virtual lab using Vagrant, while in the [third3 I showed packet captures to reveal the details behind how it works. This time I want to discuss real-world applications.

The Virtual Router Redundancy Protocol (VRRP) provides a way for multiple hosts to communicate so that one of them at a time can hold a virtual IP. Since VRRP is useful for high availability and operates at the intersection of Layer 2 and Layer 3 of the OSI model, it’s an interesting topic for a better understanding of networking. In the first article I introduced VRRP and ARP, which is essential to its operation.

The Virtual Router Redundancy Protocol (VRRP) provides a way for multiple hosts to communicate so that one of them at a time can hold a virtual IP. Since VRRP is useful for high availability and operates at the intersection of Layer 2 and Layer 3 of the OSI model, it’s an interesting topic for a better understanding of networking. Last time I introduced VRRP, then spent some time on the Address Resolution Protocol (ARP), which is used to locate the Ethernet address for a given IP address.

The Virtual Router Redundancy Protocol (VRRP) is a useful approach to provide failover at the network level on a subnet. I thought it might be interesting to see the details at the individual packet and frame level, so I put together a set of virtual machines for the purpose. On the way there were some other interesting challenges, so I’ll spend a little time writing about those as well. To start, I’d like to introduce the technologies to show their purpose.

I’ve found myself advocating for Kanban methodologies as I’ve advised agile teams, and I’m working through my reasoning in the hopes of understanding it better myself. In the first article I talked about program oversight, in the second I talked about team dynamics, in the third I talked about principals and agents, and in the fourth I talked about presenting status. Working for a large, project based organization, I’ve done a bit of work on proposals and estimation, including estimation under both traditional and agile methodologies.