If you look at my resume, I'm kind of "all over the map". That said, I tend to be most comfortable working on UNIX and data-related technologies that provide the backbone for a well-functioning enterprise.
I first encountered UNIX systems in college around 1989. My initial reaction was, "this is not only not user-friendly, it's actually neophyte-hostile." However, the pig-headed part of me took that as some kind of masochistic challenge and I got to actually prefer working with UNIX-based systems.
UNIX systems have typically been used on the back-end of organizations. They've typically been what hosted the "big-data" and high performance applications. So, as part of becoming involved in UNIX, I've had to get involved with a wide variety of other technologies. Now, there's plenty of people that are happy to say, "I'm just a UNIX guy" (or whatever their technology of choice is) and stay in their little sandbox. However, what I've discovered is, if you really want to make your stuff work well, you have to know enough about all the other technologies it links to to optimize how "your stuff" and "that other stuff" work together. So, I've had to learn about storage, networking, naming and authentication services, various applications and even Windows.
Much of what I write about in this blog is for my own benefit: I know where I can go to remind myself how I previously solved a problem. At the same time, because I don't lock this blog down, if someone is having similar problems, they can find how I solved a given problem (if their search engine fu is strong enough). So, it's also sort of a way for me to "give back".
While there are plenty of good technical resources out there, many of them seem to be least-common-denominator oriented. They geared towards "how do I get my desktop to do 'X'" rather than "how do I solve enterprise-problem 'Y'?" I may sometimes talk about desktop stuff, but, mostly, what I'll talk about is how I approached the solution for a real-world problem encountered when getting things ready to go into a data center.
Because these posts will tend to be about problems encountered (and hopefully their solutions), there's a good likelihood that my statements about the problematic technologies will be less than charitable (probably even "snarky"). If you're a vendor and happen to read something ugly about your product, understand that it's nothing personal. I've found, over all of these years, if you use any product hard enough, you will find breakage in it. In the end, all technology sucks. Just know that if I'm bitching about your technology, it's because I've used it and found where it's wanting ...or, at least, where my particular manner of using it has found it wanting.
I make no certification that the way I tried to use a given technology is the way it was intended to be used or even the most optimal way of using it. It's simply how I've used it and worked around the shortfalls I've found in those use-profiles. The joys of the type of work I do is that it's often a "please figure this out" affair. So, it's entirely possible that my interpretations are wrong or sub-optimal. If you find what I've written is wrong or out of date, I'm more than happy to hear about "better ways." Just understand that what's a "better way" for you or your environment may not hold true in the environments I work in.
