I recently started working on an Apache Camel project at work. The application in question would, I imagine, have been an atypical use case for Apache Camel. It was used primarily for the DSL definition of a series of RESTful calls to dependent services. These routes were leveraged by the application’s controller layer. My approach at the beginning and my approach by the end were pretty different. Unless stated the below are examples are taken from the Apache Camel Wish I’d Known sample code on GitHub.

While looking at various microservice patterns I found I wanted a playground for playing with components of a microservice based system in isolation. Coincidentally, in the halcyon days of winter 2019 I got an idea to binge all the James Bond films. Over the years I had seen them all. I generally watched them on television but never in any order and usually having missed the start. After having re-watched one of the movies I wrote down a very short hot take on each film.

My team recently had a requirement to build a persistence mechanism that had a unique constraint on a combination of columns. It needed to behave in an idempotent manner. If the same request was received to created an entity multiple times it would simply respond that the items existed. I spent a considerable amount of effort researching a solution and wound up with something immeasurably simpler than some of my early stabs at it.

While in the process of doing some HTML emails recently I had some issues with Outlook. Stinky, sneaky Outlook. I learned a few little techniques though that are worth sharing. Only show this on Outlook First and foremost, only show the content between the conditionals on Outlook. <!--\[if gte mso 9\]></pre> <div class="only on outlook"></div> <!\[endif\]--> Don’t show this on Outlook (v1) Anything with the style mso-hide: all will be hidden on Outlook.

I recently found the WP-CLI library and have been investigating ways I can integrate it into my workflow. I should note here that we use shared hosting extensively. Ideally the preferred solution would be to use a true migration tool. This is not always possible with shared hosting. To use the tool the following commands would be issued: migrate_wordpress.sh dev production This command would pull the latest version of the wordpress database from the production server.