Long range heat wave forecasts

What if I could tell you today that we’d have a major heat wave on June 11? A recently-published study could make that possible. Researchers analyzing heat waves over several decades have found a signal that improves the reliability of long-range heat forecasts. Will it be useful for forecasting specific days? I have my doubts, but we’ll see. They apparently plan to use it quasi-operationally this summer.

The more likely scenario is that it will help improve probabilistic forecasts on a multi-day-to-month scale. For example, the one month and three month outlooks issued by the Climate Prediction Center. There’s clear value in knowing departure from normal conditions over the course of the next few months, particularly for agricultural concerns but also for civic planning. I’m not sure I see much value in knowing now that June 11 will be oppressively hot as opposed to June 4.

While this study got a fair amount of coverage in the weather press, I don’t see that it will have much of an impact to the general public for a while. In fact, if it results in gradual improvement to long-range probabilistic forecasts, the public will probably never notice the impact, even if it turns out to be substantial over the course of several years.

April Opensource.com articles

Well, Opensource.com didn’t set any monthly traffic records this time around, but it was still another great month. I stepped up my contribution game this month, too:

mtppics: a script for copying pictures off of Android phones

Way back in the old days, Android phones could be mounted like any other FAT-32 device (think thumb drives) on a Linux computer. Life was good. Somewhere along the line, Google changed this so the phones are instead exposed at Media Transport Protocol (MTP) devices. In some ways, this is an improvement. For one, the “USB mass storage” option required exclusive access; you could access files on your phone from your computer or from your phone, but not both.

However, using KDE’s Dolphin file browser was often an exercise in futility. File transfers would almost always fail, and maybe if you disconnected and reconnected the phone, it would work better. Or maybe it wouldn’t. As it turns out, this appears to mostly be a Samsung problem and is WONTFIX’ed by KDE developers.

I initially worked around this problem by writing a quick script that mounted the phone to a known location using simple-mtpfs, a FUSE driver for MTP. This allowed the contents of the phone to appear as a normal filesystem; my wife and I could copy pictures off with Dolphin or any other tool we wanted.

This worked pretty well, until it didn’t. I’m not sure why, or when exactly, but at some point it had stopped working. It mounted okay, but using Dolphin to access the files still crashed the MTP stack. I normally use the terminal to do the file copy anyway, so it didn’t bother me, but my wife is much more GUI-oriented.

So a few nights ago, I sat down to come up with another option. The real goal was just to be able to copy pictures from the phone to our file server, not to browse around arbitrarily. This meant that I could go for an automated solution. Initially, I thought it would be best to use MTP directly, but that turned out not to be a good idea. The PyMTP library provides a good interface to MTP, but it turns out the files are exposed as a single set of objects, not a hierarchy.

So I could have continued with that route, but it would have resulted in me basically writing my own FUSE driver, so I decided that was not how I wanted to spend the rest of the evening (and many of the next evenings). In the interests of having something usable, I continued to use simple-mtpfs, but I put all of the heavy lifting into the script.

The result is mtppics, which will copy pictures from a directory on the phone to a local directory. With a little bit of trickery and the date command, you can handle a variety of date-based target directories. It’s still very much designed for how my wife and I have our pictures archived, but I’m open to making it more flexible. I’ve tried to make it fairly robust to failure (I even used a trap statement!), but there are probably opportunities for improvement there, too. Give it a try if it would be of use to you and let me know how to improve it (or submit a patch, if you’re into that sort of thing).

A culture of overwork

The technology industry has a problem. Okay, we have a lot of problems, but there’s one in particular that I’m talking about today. We have a culture of overwork and it’s bad for everyone.

As someone who is remarkably lazy, I have a keen interest in doing as little as possible. Of course, this tends to be more of the Sisyphean “automate all of the things” as opposed to just slacking off, but the point stands. Labor productivity in the United States has grown fairly steadily over the last few decades, so why don’t we see that reflected in the tech sector? (I can think of a few reasons offhand, but I don’t want to lose focus.)

My company has what I would consider a very healthy policy. Our vacation policy is effectively “take all the time you need,” and we have a minimum annual amount in case people don’t recognize that they need to take time. It’s in the best interests of company and employee alike that everyone is rested and focused. Exceptional times require late nights or weekends, but those are understood to be the exception.

But even in well-meaning organizations, particularly startups and small companies, it’s easy to let overwork culture creep in. Sometimes getting a release out on schedule means a lot of late nights for developers. Or a production outage for a customer means your support team loses their weekend. Even an offhand comment like “well look at Alice with the quick reply on a Saturday” can slowly lead to an unspoken social expectation that it’s always time to work.

For my team, I’ve always made it clear that I don’t expect anyone to be working outside of our business hours unless they get paged. In order to lead by example, I don’t have my email auto-sync to my phone, and I don’t check Slack when I’m not working. My team knows how to reach me in an emergency and I trust them to judge what an emergency is. Of course, the first week my most recent hire joined, I emphasized this to him and then ended up spending most of the weekend working. It was clearly and exception, but someone new to the company may question if that’s the unwritten reality.

Which brings me to the written reality in some places. A recent opinion piece by Alex St. John said, in effect, game developers should work 80 hour weeks and like it. Tech Twitter and many publications were immediately critical of St. John’s philosophy, but the fact that he could even get such an article published means it’s more of a problem than it should be.

I could never work in the kind of environment St. John advocates. Nor could many others for very long (and this is without considering his views on women in tech). I suspect even Mr. St. John would hate working for himself. I find the “just quit” reply to any complaints about a job to be incredibly myopic. That most people have practical considerations beyond the purity of an artist’s idealized life seems to have escaped him.

As an industry, we should be celebrating the incredible gains in productivity that we help make happen by shortening the work week, not lengthening it.

The amorality of technology

Technology enthusiasts often argue that technology is amoral. When a technology is used for unsavory purposes, that’s a failing of the user not the technology itself. That’s valid to some degree. This argument is sometimes extended to the development community around a technology. That’s never valid.

The delusion that technology, particularly open source projects, is a meritocracy because computers are incapable of moral judgements is ludicrous. Too often “merit” is used to mean “competence from people like me”. To ignore issues of social justice under the guise of “meritocracy” is to implicitly support discrimination.

As I wrote a few weeks ago, even the most well-intentioned of us have implicit biases that color our thoughts and actions. Pretending that they don’t exist or don’t matter does nothing to counteract them. I won’t go so far as to suggest that no one with unsavory views be allowed to participate in a community, but community leaders should expect pushback when their words or actions make contributors or potential contributors feel unwelcome. The contributions made to the community are just as important as those made to the code.

So what about the technology itself? Do developers owe a duty of care to the morality of a technology’s use? Yes, I believe they do. Microsoft’s recent embarrassment with a Twitter chat bot shows how quickly a supposedly amoral technology can be corrupted. I don’t expect a completely incorruptible chat bot, nor do I think adding some guardrails is an easy task. I do think that putting something like that out in public is asking for trouble (a lesson Microsoft has learned in the past and apparently forgotten). It’s a poor reflection on humanity that this is an issue at all, but here we are.

When we develop or promote technology, it is vital that we not use the amorality of ones and zeros as an excuse to ignore the human context. We owe it to our communities and to our users to understand and acknowledge the human element. In the end, what we create is a reflection of us.

Looking for my replacement

It’s been nearly three years since I joined Cycle Computing as a Senior Support Engineer. Initially, I led a team of me, but since then we’ve grown the organization. I’d like to think I did a good job of growing not only the team, but the tooling and processes to enable my company to provide excellent support to enterprise customers across a variety of fields.

But now, it is time to hire my replacement. I’m taking my talents across the (proverbial) hall to being working as a Technical Evangelist. I’ll be working on technical marketing materials, conferences, blog posts, and all kinds of neat stuff like that. I think it’s a good overlap of my skills and interests, and it will certainly be a new set of challenges.

So while this move is good for me, and good for Cycle Computing’s marketing efforts, it also means we need a new person to manage our support team. The job has been posted to our job board. If you’re interested, I encourage you to apply. It’s a great team at a great company. If you have any questions, I’d be happy to talk to you about it.

Check your project for name collisions

In my article about NPM’s Kik fiasco last week, a commenter lead me to realize I left out an important point. The developer of the original Kik NPM module said he wasn’t aware of the messaging platform of the same name. That’s a shame, because the whole kerfuffle could have been avoided if he had done some cursory searching first.

In the era of startups that seem to be named after Scrabble trays, even if you’ve made up a name, there’s a decent chance someone already made it up. That doesn’t mean you can’t use it, but the context matters.

Avoiding collisions is important for two reasons: branding and legal. The branding consideration is less context-dependent, but is all about how users find and distinguish your project. When Opscode, the company behind the Chef configuration management tool, changed their name to Chef, it made searching for errors and documentation harder. “Opscode chef knife” had much more relevant search results than “chef knife”.

The legal issue is and is not context-dependent. It is in the sense that actually violating a trademark requires some likelihood that the public would be confused. For example, Payless Shoes and the PayLess grocery chain can coexist with a minimum of confusion. However, no actual infringement is required in order to threaten someone with a lawsuit. Most open source projects don’t have the resources to fight a lawsuit, so the natural reaction is to give in, even if the claim is baseless.

So what should you check for? A recent Opensource.com article has some suggestions. In addition, I’d look for collisions on social media platforms, especially if your project is related to that platform. Also consider how the name might be made into a logo. You don’t need one right away in many cases, but when it gets huge, you may want it.

Bio-IT World recap

Last week I was in Boston for the annual Bio-IT World Conference and Expo. I spent most of the conference working the company booth. It was a lot of fun talking to people about what our software does. Even the conversations that won’t lead to a sale were interesting because I got to learn more about what other people are doing. Of course, there were some people who lit up when I gave a demo (and let’s be honest, it’s probably not just my charming personality).

My role wasn’t just limited to booth duty, though. On Thursday morning, I chaired a session in the cloud track. I was a little nervous chairing a session at a conference I’ve never attended in a domain that I know next-to-nothing about. Fortunately, it went very well. Perhaps too well, as we got so far ahead of schedule that we had to ad lib 10 minutes of Q&A before the last presentation. But it worked well enough, and the talks were really interesting.

When I was introduced ahead of the conference to the presenters, I asked all of them for guidance on how to pronounce their names in addition to the bio that the conference organizers asked them to send. The next time I chair a conference session, I’m also going to ask for a few questions in case there are none from the audience. Sometimes, the pump just has to be primed a bit, and I’d rather ask a question that the presenter thinks is relevant than whatever I come up with while listening to the talk.

 

Submit your LISA16 proposal!

I am co-chairing the Invited Talks for this year’s LISA Conference, alongside Patrick Cable. I’ve attended LISA since 2010 (with the exception of 2014) and it’s a great conference for systems administrators and other operationally-minded tech folks. I’ve enjoyed many great talks over the years, and as a co-chair, it’s up to me to help make sure that trend continues.

So here’s where you come in: it’s time for you to submit a proposal. The Call for Participation is open through 11:59 PM PDT on Monday, April 25. You may think “I have nothing worth sharing,” but you may be wrong. Patrick and I are particularly interested in finding talks that address cross-cutting topics, talks from new attendees, and generally interesting talks.

Talks don’t have to be about the cutting edge of technology to be interesting. Some of the best-received talks last year weren’t even technical in nature. So much of the job is cultural: the culture of your team and the larger organization. Alice Goldfuss’s “Scalable Meatfrastructure” talk may have broken the record for the amount of praise on social media channels.

Tell us about a problem you had and how you solved it. Tell us about how you applied technology to improve life for your organization and users. Or propose a tutorial in order to share your deep knowledge.

Go out on a limb and propose a talk. If you get accepted, it’s a great way to attend the conference and expand your professional network. if you don’t get accepted, I promise it it’s okay (I’ve had several proposals to other conferences rejected). If you want some advice on how to make your proposal awesome, both Patrick and I are happy to talk to you.

I hope you’ll submit your proposed talk soon.

To warn or not to warn?

The decision to issue a tornado warning is a difficult one for meteorologists. A timely and accurate warning can save lives, but a false alarm contributes to an already-too-high indifference among the public.

On March 31, thunderstorms moved through Indiana in the mid-afternoon. The Storm Prediction Center had a slight risk for the area, so I had been keeping an eye on them. One cell had shown rotation since it had been in east-central Illinois. After a while, it started to fall apart. Then around 4:40 PM, I happened to glance back over at the radar, and I saw this:

KIND reflectivity and velocity at 4:42 PM Eastern on March 31, 2016.

KIND reflectivity and velocity at 4:40 PM Eastern on March 31, 2016.

Oh yeah, there’s something going on there. I was talking to my friend Kevin and we were wondering why there was no warning. Even if the forecaster didn’t think a tornado warning was justified, a severe thunderstorm warning would have been a good hedge. As it turns out, the storm produced a brief EF1 tornado about a mile east of my house.

I don’t know why no warning was issued. But here’s a different take: should a warning have been issued? No one was injured and the damage that was done couldn’t have been prevented with a 10-15 minute lead time. Should this count as a false negative?

Yeah, probably. Although no one was injured, a small difference in the location could have easily changed that. But it makes me wonder if warning for every tornado is a reasonable goal.