Five years ago, I showed you how to export a list of members of an Active Directory group, using a command line query. One issue I’ve run into using this query, is that I get their user name, not their actual name, which tends to make the resulting list hard to parse. As I had a need to export a relatively large number of group members names as part of a recent ticket, I needed a solution that gave me what I wanted straight out of the box.
Thoughts on many things Posts
I recently picked up a new Kindle, and wanted to ensure that the new device had the same content as the one I replaced. As it turns out, this is rather easily accomplished. Here’s how:
The title of this post might seem a bit on the conceited side. After all, who am I to claim to be a DevOps practitioner, much less thinker? I will simply say that I am working to implement DevOps principles in my day to day life, am spending more than a little time reading, thinking, and writing about DevOps, and though I may not be considered a DevOps thinker today, I certainly aspire to join their ranks. The title, then, is a statement of aspiration, more than a statement of achievement.
When I wrote my blog post about important features of a service management tool, I wrote “I am increasingly coming to believe that the change management process is perhaps the most important one for success in ITIL – not to mention DevOps – adoption” – and I stand by that assessment. Not because change management is such a revolutionary idea in and of itself, but because of what true management of change means for a business.
Last week, I showed you how you can quickly and easily create a coherent Twitter thread. Reading Twitter threads can be a bit of a hassle, though, so of course someone made a web app to hep with that. The site is called Thread Reader App. Useful though it is, it could have been a bit more intuitive to use, so here’s how you unroll a thread:
I have recently gotten back into using Twitter, after having left it as little more than a channel through which I promote the posts on this blog for a fairly long time. In the past, when I have had something on my mind taking more than 140 (well, 280 now) characters to say, I’ve simply written a tweet, then replying to it and replying, in turn, to the reply until I’m done.
I celebrated my 35th birthday this past week. As I was getting ready for work one morning, I looked into the mirror and realised that – barring some drastic, and highly unrealistic, changes in approaches to retirement – I will likely be part of the work force for (at least) as long as I have presently been alive. Counting my service as a conscript in the Royal Norwegian Navy, I have been part of the workforce for fifteen years, which means that I will have been part of the workforce for a total of (at least) fifty years when I eventually retire.
My first IT job was a one day per week internship with a pharmaceutical company while I attended my last year of high school. It was the first time I was exposed to the constant stream of support and service calls that makes up a large part of the day to day life of a support technician. I remember having a distinct impression that the IT department was constantly over-worked, always having too many things to deal with.
Kanban (capital-K, as in the method) uses a kanban (lowercase-k, as in the board) to visualise and reduce work in progress (WIP for short). This is the most well-known, and visible, part of Kanban. It is achieved by limiting how many pieces of WIP any one work centre can have assigned. At first glance, this may seem to be incompatible with IT support work. This is as erroneous as assuming Kanban is incompatible with knowledge work in general, whereas it has been proven to be an excellent match for software development (for details, I recommend David Anderson’s book “Kanban: Successful Evolutionary Change for Your Technology Business”).