A year or so ago, my partner and I said to eachother “Wouldn’t it be cool to create a LED wall for our living room?”. We then set about to buy an Arduino and some required components for the first prototype. It took a while for us to actually get started, but my phone tells me that on the 7th of June I sent my technogeeky friends a photo over WhatsApp of my breadboard experiment:
Frankly, I’m surprised that I can’t find more blog posts on this topic.
I can’t imagine that I’m the only software engineer who has encountered dependency management of the form “it’s somewhere on the K: drive”. And yet, when I search online, I can’t find anyone griping about this. All I can find is this one blog post by Sonatype that goes on to advertise their Nexus repository manager.
In this case, we use environment variables for all our builds.. or so I thought. Last week, I encountered one project that was making an exception and doing its own thing: It was explicitly calling a tool on the K: drive and linking against libraries on that drive. Not only that, it didn’t use environment variables but hardcoded the path to the network drive in the build script and VS project settings.
I prefer expressing the difference between project a solution owns and projects it does not own (dependencies) with the help of Visual Studio’s solution folders. It’s a trick I didn’t come up with myself, I’ve deftly stolen it from a former colleague.
There are four categories:
- The main project (in most cases a library or application)
- Other projects the solution owns, that the main project depends on.
- Test projects
- Dependencies: projects the solution does not own
For a little dummy project like this it seems like a lot of overhead, but I’ve experienced that the list of dependencies can become quite large and the number of test projects grows with the number of projects under 1. and 2. What I like most about this approach, is that if you consistently apply this across your solutions, you always know what to expect when opening a solution; at a glance you’ll see what it’s all about. All in all I find it worthwhile to apply this grouping.
A issue that occurred has been fixed with some help from other plugin developers. This problem was that WordPress doesn’t have a hook to add fields to the Appearance > Menus page. I used to fix this by just overriding the function that created this page, but this way of working means more risk of conflicts with WordPress (updates / changes to the markup) and other plugins (only one can ultimately create the HTML that way). Thanks to the plugin author of Max Mega Menu, who pointed out a workaround other plugin developers have been using, this is no longer such an issue. I intended to implement their suggestion for some time now, and today I got around to it.
In the next release, my plugin now supports the wp_nav_menu_item_custom_fields hook and should be compatible with other plugins. See original support question here: Is there any way to use this with Max Mega Menus?
Those who need this functionality right away can grab the latest development version at the plugin page on WordPress.org
“Jensen discovered (and many subsequent experiments confirmed) that many animals — including fish, birds, gerbils, rats, mice, monkeys, and chimpanzees — tend to prefer a longer, more indirect route to food than a shorter, more direct one. That is, as long as fish, bids, gerbils, rats, mice, monkeys, and chimpanzees don’t have to work too hard, they frequently prefer to earn their food. In fact, among all the animals tested so far the only species that prefer the lazy route is — you guessed it — the commendably rational cat.”
— Dan Ariely, The Upside of Irrationality (62)
“When you don’t really know how long it is going to take to add a feature and you suspect that it will be longer than the time you have, it is tempting to just hack the feature in the quickest way that you can. Then if you have enough time, you can go back and do some testing and refactoring. The hard part is actually going back and doing that testing and refactoring.”
— Michael C. Feathers, Working effectively with legacy code (59)