Saturday, June 24, 2017

Mr. Cole, Please

David Bowie died while I was stuck in traffic in Baltimore, which is probably an OK place to be when someone who's work you've, on occasion, admired, dies. You can bet on the local listener-supported public radio station to quickly assemble a memorial playlist, replete with the appropriate mix of hits and "deep cuts." But most of Bowie's work is "deep cuts" in the age of streaming music and digital audio. No one wants genius anymore.

Baltimore traffic is horrific, you should know. But it's nothing compared to D.C. traffic, which is almost enjoyably bad. Gridlock gave me time to, as the millennials say, process the Thin White Duke's passing. But it was less process and more shruggie, because why shouldn't Bowie die? We're all dying. Then I realized the traffic had gotten to me, so I exited the highway somewhere in Columbia to find a Wawa. Coffee fixes everything that a bad commute can break.

Back in the car now, and re-focused on my destination: a technology road show in downtown D.C., where tie-less executives would espouse the benefits of Azure and attempt to dazzle world-weary engineers with simply stunning stats on cloud adoption. I've forgotten all of them. But I'm fairly sure they were stunning at the time. At least all of the attendees sporting Microsoft logos and product names seemed stunned.

But before I arrive at the hotel that was hosting the event, my father calls to tell me my grandmother has died. His mom, my gram, my last grandparent. We expected this, as her last weeks in hospice were awful, like watching a flower wilt. My father spoke in a voice that fathers use when they don't want their children to know they're heartbroken. Hearing that voice was as devastating as hearing that gram had died.

I was somewhere on New York Avenue, in NE, where the construction rearranges lane markings in a manner that befuddles even those of us who could drive D.C. blindfolded. I don't remember how I got there, but suddenly I was in the lower levels of a hotel, I can't remember which one. I know that we're supposed to remember more about days when something significant happens; I've listened to Season 1 of Serial more times than most people. But I can't remember getting from place to place on January 10, 2016. I just remember being places.

I attend the tech event, and as usual I walk in after the lights have dimmed and the keynote speaker has taken the stage. In a former life, I curated my professional brand to support a nascent career as an influencer, so I was supposed to go bananas over events like these. But I looked too closely at the world of influence marketing, recoiled at the use of words like "goodness" and "expert," and quietly moved on.

The short version is that the Azure Roadshow was terrible, and I felt terrible, so I left.

I could have taken the elevator down to the garage below, found my car, paid whatever ridiculous parking fee one pays to park in D.C., and went home. Maybe I should have.

Instead, I notice that the National Gallery of Art was only a few blocks away, and I remember that when I think of who I think I am, I think I'm the kind of person that visits art galleries often, even though I don't. And of course there was the opportunity to drink hot coffee outside in the cold. Never pass those up.

I set out towards the NGA, with a specific idea of what to admire while there. It's a series of paintings I had learned about while struggling in my senior studio art class so long ago, a series of four paintings depicting the stages of a man's life. You've likely seen one or more of these paintings, even if you don't care for art much, because they pop up everywhere. It's Thomas Cole's The Voyage of Life, and once you've lived through a crisis or two, it'll evoke all of those pent-up emotions you've been evading.

Security in Smithsonian museums requires the inspection of bags, and that backpacks be worn on a single shoulder, not both. This isn't a vestige of security theatre in the beltway sense; it's a matter of protecting artwork from the accidental bump that's likely with a large backpack behind you. I didn't have a backpack anyway, but I always thought it strange. I only know this because I just looked it up.

At the information desk, just beyond the security station, I see a docent, a woman, enjoying the whimsy of her encore career as an unpaid evangelist of the arts. I resist the temptation to use my phone to locate the four paintings; talking to people is still a favorite pastime. I walk up and announce the reason for my visit: "Mr. Cole, please."

She knows exactly what I'm looking for. And after she shares the room number with me, she says, reassuringly, "It's always good to know which boat you're in."

She's right.


To be continued.

Wednesday, June 21, 2017

How to Read Documentation at Work

Reading. It's awesome. You're doing it now, and good for you. Also, thank you.

What you may have forgotten is that reading is more than just pointing your eyes at some text and recognizing that text as language. Reading incorporates comprehension of what you're reading. As one of my former co-workers told me years ago, "If you read something, and don't understand it, you haven't read it."

In technical circles, reading is a near-constant activity. We're reading release notes on patches, we're reading installation guides for new software, we're reading messages from colleagues. Reading requires dedicated time and 100% of your attention; it's not something you can multi-task. It's not. No. No, YOU'RE wrong.

The problem with devoting your attention to reading is that, to the pointy-haired types and nosy cube neighbors of the world, reading sure looks an awful lot like doing nothing. Personally, when I'm reading something at work, I slouch in my chair and rest my left hand against my chin. I mean, it really does look like I'm kirked out or whatever the kids say these days. But I'm not. I'm learning.

So to provide some cover for my fellow at-work readers, I present to you the most stupid PowerShell script I've ever written. It's also the best.

My goal was to find a simple command that would produce the busiest wall of rapidly changing text that I could let go without worrying about it. And since update-help is something we should all run on occasion, I went with it. The -verbose makes it noisier, and the -force makes it run more than once in a 24 hour period. The while statement is just the stupid part that makes the do loop run as long as you can get to www.google.com, which is always.

Run this, move the window to whichever monitor you think is most visible from the doorway to your workspace, and read in peace. It'll look like you're busy doing... something? If someone asks what you're doing, just say it has to do with cloud services and the compiler in the micro segmentation containerized SDN topology. That'll chase them away.



via GIPHY

Saturday, June 17, 2017

Charles Town

we’ll follow a sparrow, an owl, and a hawk,
you’ll scrawl all your visions on vacants in chalk,
then i’ll carve a totem i cannot explain,
and we’ll never go back to our old house again.

Saturday, April 15, 2017

Killing the Witnesses

while i paced in long ovals, flicking ashes into the hedges,
the trees, too old to bend to capricious gusts of wind,
waited and pretended not to listen
to phone calls with realtors and repairmen.

like witnesses, with canopies stretched out over my head,
like the first moments of an embrace, paused.




Friday, March 17, 2017

In Defense of Shadow IT

Spend any measurable amount of time listening to a vendor presentation, and you'll hear undoubtably hear the phrase "Shadow IT." If you're not familiar with the term, it's used to describe a situation in which users circumnavigate corporate or centralized technology teams and solutions in favor of other services, primarily public cloud services.

For example, a user may opt to deploy an application to AWS instead of going through the in-house development and operations channels. Or a developer might spin up some test applications in Google Cloud Platform because her IT organization didn't know their kubernetes from their vmkernels.

Vendors hold up Shadow IT as a perfect example of what's wrong with technology, namely cloud computing, and will happily share with you their solutions intended to stop it.

In the eyes of the vendor, shadow IT is the problem.

In fact, shadow IT is a solution. The real problem is officious, ineffective delivery organizations hellbent on dictating how IT should be consumed. More specifically, the real problem is IT organizations that, instead of listening to the needs of its customers, continue to offer the same catalogue of services from a decade ago.

Oh, you'd forgotten about HoJo? Me, too.
It's the same type of problem that forced Howard Johnson's restaurants to nearly disappear from the map: the problem wasn't that people weren't eating at HoJos, the problem was that HoJos had excruciatingly shitty food. No amount of begging customers to come back will make a difference when your product doesn't directly address their needs.

It's Not Your Customers, It's You

If you work in an organization that views shadow IT as a problem to be addressed, you work in a broken IT organization. Your users aren't the problem; you are. Users don't embrace shadow IT (and really, we shouldn't even call it that anymore, because users don't think to themselves, "I think I'll circumvent my company's IT policies and not use their servers," they think, "I need to get my work done and my company's IT shop can't, or won't, help me."), they embrace creative problem solving when faced with hang-wringing and stonewalling from their internal IT department.

IT exists to enable application delivery in support of the business. And application developers will find a way to deploy their apps no matter how incapable their IT shops may be.

Wednesday, March 8, 2017

How to Get-OverYourself and Learn PowerShell

If you listen to the evangelists, you'd probably think that in 2017, there is only one person who isn't using PowerShell: you. Everyone else not only gets it, but uses it to automate all of their work, including manipulating databases, monitoring systems, interviewing candidates, and filing IPOs. And the simple fact that you don't use it makes you a dinosaur. Frankly, it's amazing that you're even employed.

Luckily, you don't listen to evangelists. They spend too much time on Twitter and not enough time in the trenches.

So let's quit talking about PowerShell like it's the harbinger of change in the technology world. It's a scripting language1. Not the first, not the last, not the best, not the worst. It's not going to change your life. If you're unhappy with your job, learning PowerShell may be a temporary distraction from your unhappiness, but it's not going to change your sentiment with regard to your work.

I'm telling you this because you should have realistic expectations, in general, but specifically with new technology.

Once you've taken a moment to reconsider your opinion of PowerShell as panacea, continue reading.

Ready?

Now that you've gotten rid of the anxiety surrounding PowerShell, you are ready to see its strengths and weaknesses more clearly. For example, if you're looking to make a simple change to a number of servers, PowerShell is a great tool. If you're looking to deploy patches to a mission-critical database server, you're better off with another solution. PowerShell, like most automation solutions, is ideal for 1:many actions. The work is front-loaded; spend time developing a solution, then use automation to scale that solution out.

This is all to say that you should not consider PowerShell as a foreign language to learn only to remain relevant in IT. You should consider it as a technology that can change how you approach your work, especially when you're managing an infrastructure at scale.

Consider a timely example that we're dealing with in the Microsoft shops of the world: the mass disabling of SMBv1. In Server 2012 and newer, there's a PowerShell cmdlet that can be used to enable and disable SMB on a remote server. And even though you immediately think to yourself, "I can do this in a GPO," I submit to you that PowerShell is a much cleaner way to implement this type of minor change, if for no other reason than you're avoiding GPO hell, which is like .dll hell, but with a GUI.

With PowerShell, you can query AD for a list of computers, filter out the server running 2012 and newer, and invoke a remote cmdlet to disable SMBv1 on as many servers as you'd like, all in one fell swoop2. You don't need to worry about WMI filtering in GPOs, or wondering if your custom method of settings registry values will work on all versions of Windows Server. You just put a few lines of PowerShell together, and go.

The point of this post is not to show you the script itself (although I'll follow this post up with a post that includes the deets, because I oscillate wildly between essays and engineering). The point is that PowerShell really is an amazing chunk of code, and once you get your mind right about why you'd use it, learning PowerShell is fun.

1 - PowerShell MVPs and enthusiasts of all stripes just rolled their eyes so hard they can see their own brain stem.
2 - Your high school English teacher would really appreciate it if you'd read Macbeth, really read it, not just skim the first act and confuse it with Hamlet, which you should also read. Thanks.

Tuesday, February 21, 2017

Maryland VMUG Gets Real

A few years ago, I complained that VMUG meetings were too heavy on pres-sales and product-
pitches to suffer through in order to get any useful technical information, and that the technical information on current VMware offerings was increasingly irrelevant to a customer base that wasn't keeping up with vSphere releases. The VMUG formula was predictable and tiring: vendor sales presentation, vendors sales presentation, food, and a brief discussion on actual VMware products. Sometimes the sales presentations were only tangentially related to vSphere or vRealize.

VMUG images hosted on AWS? lolwut
But the worst part was that the users group wasn't really a users group. It was a small group of interested technologists listening to VMUG leaders and vendors. Few and far between were the interactive, informative, informal conversations between fellow vSphere or vRA (or View, if that's your thing). You had to wait until the meeting was over before you could really network with your fellow VMUG members. Sad!

In fact, I'd stopped attending the local meetings as a direct result. I still browse the agenda for the meetings, but they haven't caught my attention.

Until now.

Tomorrow afternoon at 4pm, the MDVMUG is trying something new: no vendor presentations, just HOL and NSX.


This is a much welcomed change from the typical format of these meetings, and I'm very glad to see the focus rightly returned to sharing knowledge and encouraging professional development and networking among VMware users.

Show your support for your local VMUG, especially when they're taking steps to address criticism. I'll be there tomorrow night!