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)
A while ago I had a discussion with a colleague on what the structure of our code repository ought to be. At the time, I couldn’t find the words to explain why I prefer one strategy over another, so I’ve given it some more thought.
In this case we’re talking about several Visual Studio Solutions (.sln) and their C++ projects (.vcxproj). If I were to choose a directory structure, my considerations would be as follows.
Ownership and containment
A solution contains projects that it may or may not own. I expect a solution like MyApplication.sln to contain a project MyApplication.vcsproj. The solution owns this project, the main project. The project could have dependencies on other projects of course. These dependencies are either specific for this project, or generic and reusable. The solution contains all projects that the projects it owns directly or indirectly depend on. I.e. My Applicaiton depends on MyApplicationLib, which in turn depends on GenericLib. The solutoin contains all three projects. It may seem obvious, but it’s quite common to find a project that depends on a library that is not included in the solution, causing a linker error unless you built this additional dependency manually beforehand. Not pretty.
“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)