Technology

Pedantically commented Ansible playbook

Here is a nice example Ansible playbook with lots and lots of comments, showing how things work.

Continue reading Pedantically commented Ansible playbook

WordPress 4.5 “Coleman”

WordPress 4.5 “Coleman” – the newest WordPress version has been released (I’ve just upgraded). Some of the changes included in this release are:

New and improved user interface for editing links in posts and pages.
More Markdown-like shortcuts for formatting text (now with code and horizontal lines).
Logo support in themes
Much improved image optimizations (initially expected in WordPress 4.4)
Better embed templates
Update for underlying libraries, such as jQuery, Backbone, and Underscore.

If you already manage a WordPress website, you’ll find the notification of the update in your admin area. If not, then go and download it.

Red Hat Satellite

Here’s something I didn’t know about – Red Hat Satellite. From the FAQ page:

Red Hat® Satellite is a system management solution that makes Red Hat infrastructure easier to deploy, scale, and manage across physical, virtual, and cloud environments. Red Hat Satellite enables users to provision, configure, and update systems to help ensure that they are running efficiently andsecurely, and remain compliant with relevant standards. By automating most tasks related to maintaining systems, Red Hat Satellite helps organizations increase efficiency, reduce operational costs, and enable IT to better respond to strategic business needs.

Now Red Hat’s acquisition of Ansible makes even more sense. I guess, their satellite is looking for the galaxy.

Open Source software is so reassuring …

There’s nothing like working on a problem for a few days and getting to the reassuring code snippet like this:

sub PSGIApp {
    my $self = shift;

    # XXX: this is fucked
    require HTML::Mason::CGIHandler;
    require HTML::Mason::PSGIHandler::Streamy;
    my $h = RT::Interface::Web::Handler::NewHandler('HTML::Mason::PSGIHandler::Streamy');

    $self->InitSessionDir;

    my $mason = sub {
        my $env = shift;

        # mod_fastcgi starts with an empty %ENV, but provides it on each
        # request.  Pick it up and cache it during the first request.
        $ENV{PATH} //= $env->{PATH};

        # HTML::Mason::Utils::cgi_request_args uses $ENV{QUERY_STRING} to
        # determine if to call url_param or not
        # (see comments in HTML::Mason::Utils::cgi_request_args)
        $ENV{QUERY_STRING} = $env->{QUERY_STRING};

The first comment is misleading. It throws you off. Almost make you close the file and go somewhere else. But that’s just a little frustration from the last few days. The solution to my problem is here too… And that’s when the warm, cozy feeling I have for the Open Source Software kicks in.

P.S.: both the problem and the solution will be posted separately.

Support lesson to learn from Amazon AWS

I’ve said a million times how happy I am with Amazon AWS. Today I also want to share a positive lesson to learn from their technical support. It’s the second time I’ve contacted them over the last year and a half, and it’s the second time I am amazed at how good well it works.

In my experience, technical support departments usually rely on one primary communication channel – be that a telephone, an email, a ticketing system, or a live chat. The other channels are often just routed or converted into the main one, or, even, completely ignored. But each one of those has it’s benefits and side effects.

Telephone provides the most immediate connectivity, and a much valued option of the human interaction. But the communication is verbal, often without the paper trail. It makes it difficult to carbon copy (CC) people on the conversation or review exactly what has been said. It is also very free form, unstructured.

Live chat is also free form and unstructured, but it’s written, so transcripts are easily available. It also helps with the carbon copy, but only on the receiving end – supervisors or field experts can often be included in the conversation, but adding somebody from the requesting side is rarely supported.

Email makes it easy to carbon copy people on both ends. It provides the paper trail, but often lacks the immediate response factor. And it’s still unstructured, making it difficult to figure out what was requested, what has been discussed and whether or not there was any resolution. (Have you ever been a part of a lengthy multi-lingual conversation about, what turned out to be, multiple issues in the same thread?)

Ticketing/support systems help to structure the conversation and make it follow a certain workflow. But they often lack humanity and, much like emails, the immediate response.

Now, what Amazon AWS support has done is a beautiful combination of a ticketing system and a phone. You start off with the ticketing system – login, create a new support case, providing all the necessary information, and optionally CC other people from a single short form. The moment you submit it, the web page asks for your phone number. Once entered, a phone call is placed immediately by the system, connecting you to the support engineer. The engineer confirms a few case details and lets you know that the case is in progress and expected resolution time (I was asking to raise the limit of the Elastic IP addresses on the Virtual Private Cloud, and I was told it will be done in the next 15 to 30 minute. And it was done in 10!). I have also received two emails – one confirming the opening of the case, with all the requested details, and another one notifying me that the work has been done, providing quick information on how to follow up, in case I needed to.

Overall experience was very smooth, fast, to the point, and very effective. I never got lost. I never had to figure anything out. And my problem was attended to and resolved immediately.

I only wish more companies provided this level of support. I’ll sure try too – but it’s a bar set high.