Your con-call invitation isn’t as enticing as you think

I enjoy talking shop, but not so much when I first need to call a toll-free number, punch in a four-to-six-digit code, press the pound key, speak my name after the beep and be dumped into a cybernetic void in which I must wait to hear the sound of another human voice.

Con-call invite from OutlookNo, I’m not a fan of conference calls. Part of that is a common rationale–they allow a PR minder to be on the line and make sure nobody says anything too compromising–but, really, most of it is the exasperating user experience.

That starts with the con-call invitation, which inexorably arrives on my Mac as a blank e-mail consisting only of a “Mail Attachment.ics” file. OS X’s Quick Look won’t reveal its contents, so I must open it in Calendar to see that it contains the number, con-call code and time that should have been in the e-mail itself.

Make me open another program to see what you’re talking about in your e-mail? No.

To judge from the headers of these messages, this is a Microsoft Outlook-transmitted social disease–sending a calendar invitation from inside that sprawling program must not offer the sender any hint of how it will be displayed to a recipient. In my case, it’s badly: Not only does Mail for OS X throw up its hands, the Gmail app for Android doesn’t even show this file.

(And yet Mail for iOS displays a nifty calendar widget for those invitation messages. Apple’s inability to keep its desktop mail client at feature parity with its mobile mail client is a subject for a future rant.)

After the aforementioned routine of punching in numbers and waiting for a response, I often face an extra challenge in con-calls with more than one executive, or in which the publicist and the executive are of the same gender: figuring out which of two or three white guys is speaking at any one time.

And have I mentioned that this is the tech business? There are good, Web-based conference systems that let you connect by clicking a link and then make it easy to tell who’s there and who’s talking. I’ve used UberConference and it was terrific; I hear great things about Speek but haven’t used it yet (note that a friend works at that D.C.-based startup); video chat through apps like Skype, Google+ Hangouts, Vidyo or Rabbit works too, as long as I tidy up the parts of my home office within camera view.

And yet when a company wants to talk up its technological prowess, we must jack into the AOL chat room of group voice communication. PR friends, if your client insists on that routine, can you at least do me a favor and dial my phone directly before patching me into the call?

About these ads

DIY doings: components, cables and code

I’ve been playing with gadgets ever since my dad let me and my brother take apart an old calculator for fun, but until last week I had never wielded a soldering iron to connect electronic components.

Hand-soldered LED flashlightMy chance to remedy that oversight came at the end of a tour of a redone Radio Shack store across the street from the Verizon Center Phone Booth in downtown D.C.

After getting the company pitch about its screen-repair services, inspecting some Kodak camera modules made to clip onto phones, and playing with a littleBits synthesizer kit, I was invited to assemble a tiny LED flashlight by soldering the required parts to a small circuit board.

Dripping the molten flux onto the right contacts revealed itself to be a painstakingly precise, hold-your-breath task. I needed coaching from the rep manning that station, after which he had to redo some of my work–making me think this whole project was perhaps more like when our toddler puts together some arts-and-crafts project “with help.” But a few minutes later, I did have my own tiny, battery-powered flashlight.

I had also completed my first hardware tinkering in a while.

The last time I’d cracked a computer’s case was two years ago, when I doubled the memory in my iMac (Apple has since made that at-home upgrade impossible on newer models) and then swapped out my ThinkPad’s hard drive for a solid state drive. Either chore involved less work and anxiety than the multiple transplants I performed on my old Power Computing Mac clone in the ’90s, including two processor upgrades and a cooling fan replacement.

Crimping tool

While we’re keeping score, I last seriously messed with wiring when I strung some Ethernet cable from the basement to an outlet behind our TV to prepare for our Fios install in 2010. Going to that trouble, including terminating the bulk cable and attaching plugs myself, allowed me to use my choice of routers on our Internet-only setup.

The crimping tool I used for that task hasn’t seen much use since, but I’d like to think I’m still capable of moving a phone, power, or coax cable outlet. Especially if given a spare length of cable on which to practice first.

My DIY credentials are weakest when it comes to code. I learned entry-level BASIC in grade school but now recall little of the syntax beyond IF/THEN and GOTO. I used to lean on AppleScript to ease my Mac workflow, but now Automator lets me create shortcuts without having to remember the precise phrasing required after AppleScript statements like “tell application ‘Finder’.” My HTML skills now stretch little further than writing out the “<a href=” hypertext link.

I do, however, still grasp such important basics as the importance of valid input and proper syntax, how easy errors can crop up and how much time it can take to step through functions to figure out what threw the error. For anything more complicated, the usual reporting technique comes into play: Ask as many dumb questions as needed to get a little smarter on the subject.

The importance and difficulty of clocking out on time

I had a long chat the other night with a younger tech journalist about work/life balance. I suspect this person was hoping to learn that I had found this one weird trick to regain control of when the job can cede priority to the things that the job pays for, but I had to admit that I had not.

Clocking outThat’s because experience, at least in my case, has not changed this basic conflict in journalism: As long as praise (financial or otherwise) for good work outweighs compliments for filing early, you’re motivated to keep noodling away at a story until about 30 seconds before your editor sends an “are you filing?” message. And even if you don’t, filing ahead of schedule typically guarantees that your editor’s attention will immediately get hijacked by breaking news.

As a work-from-home freelancer, I should be in a better position to log off at a normal time because I’m immune to many of the usual newsroom distractions. My editing software is faster to boot up and less likely to crash than many newsroom CMSes, I don’t get dragged into random meetings, and I don’t have to worry about the time to commute home.

Plus, if a client wants an extra story, that will usually mean an extra payment instead of another revolution of the newsroom hamster wheel.

But I’m also disconnected from the usual boss-management mechanisms. I can’t look up from my desk to see if somebody else is occupying my editor’s attention and/or office, or if I should hurry up and file the damn thing already. I can’t tell just by listening to the collective din of keyboards how busy the news day has become. Writer-editor occupational banter in chat-room apps like HipChat amounts to an inexact substitute.

What I told my younger counterpart was that you have to remember that not every story requires the same intense attention to capturing the finer points of an issue–that it also feels pretty great to crank out solid copy, clear on the outlines of a topic, in half an hour and then be done with it. That’s also a skill you need to keep current, because you won’t always have the luxury of an entire afternoon to futz with the language of a post. Give yourself a fake deadline if you must, but try to make putting down your tools at a time certain a part of the exercise.

That’s why I set a timer on my phone to ensure I’d finish up this post and get started on cooking dinner. It went off… oh, about 15 minutes ago.

Heartbleed and bleeding-heart open-source advocacy

For at least the last decade, I’ve been telling readers that open-source development matters and helps make better software. If everybody can read the code of an application or an operating system, there can’t be any hidden backdoors; if anybody can rewrite that code to fix vulnerabilities and add features, the software’s progress can’t be thwarted by any one company’s distraction, fraud or bankruptcy.

OpenSSL pitchMy glowing endorsement of Mozilla Firefox 1.0 in November 2004 set the tone:

…the beauty of an open-source product like this is that you can participate in its evolution. Firefox’s code is open for anybody to inspect and improve...

Since then, I’ve recommended open-source operating systems, office suites, anti-virus utilitiessecure-deletion tools, file-encryption software, two-factor authentication apps, PDF exporters, DVD rippers and video-playback toolkits. And I’ve had one phrase in mind each time: Given enough eyeballs, all bugs are shallow.

My experience using open-source software tells me this is true–even if that doesn’t guarantee a constant rate of improvement or an elegant interface.

And if any genre of software should benefit from this method of development, it ought to be code that Web sites use to secure their interactions with users from eavesdropping: Everybody sending or storing private information needs this feature, billions of dollars of transactions are at stake, and you don’t even have to worry about wrapping a home-user-friendly UI around it.

True, right? Except Heartbleed happened. Two years ago, an update to the widely-used OpenSSL encryption library added a “heartbeat” function that made it easier for sites to keep an encrypted session going. But it also harbored an disastrous vulnerability to buffer-overflow attacks that would cause a site to return 64 kilobytes of whatever happened to be adjacent in the server’s memory to an attacker: usernames, passwords, e-mail content, financial transactions, even the private key the site uses to encrypt the session. And the attacked site can’t check afterwards to see if it got hit. I defy the NSA to script a better hack.

And despite buffer overflows being a well-known risk with documented defenses, nobody caught this for two years. Two years! It took a Google researcher and engineers at the Finnish security firm Codenomicon to find the bug separately and report it to the OpenSSL team.

How bad is this? Ask security researcher Bruce Schneier:

“Catastrophic” is the right word. On the scale of 1 to 10, this is an 11.

It seems that everything that could go right in open source development went wrong in this case. As an excellent story from Craig Timberg in the Post outlines, the free nature of OpenSSL made it an obvious choice for hundreds of thousands of sites and something of a natural monopoly, that same enormous deployment of OpenSSL encouraged people to assume that they themselves didn’t need to inspect the code that carefully, and OpenSSL developers got so little financial support from the corporations relying on their work that they couldn’t even subject their code to a proper security audit.

The stupid thing is, we knew this could happen. See John Viega’s 2000 essay, “The myth of open source security,” in which he outlines how thousands of users failed to catch “a handful of glaring security problems” in code he’d contributed to the Mailman mailing-list manager:

Everyone using Mailman, apparently, assumed that someone else had done the proper security auditing, when, in fact, no one had.

That doesn’t mean that closed-source development suddenly looks better. (When all this is done, Microsoft’s proprietary and hideous Internet Explorer 6 may still have greased the skids for more successful attacks than OpenSSL.) But it does mean that selfishness/laziness/distraction and open source can become a toxic mix, one we should have seen coming.

Updated, 10:25 a.m., to add a link to Viega’s prescient article.

#corrected: Fixing your errors on Twitter

I screwed up on Twitter yesterday morning. In the grip of nerd rage over a story about an Apple patent application–and without sufficient caffeine in my body–I tweeted that the Cupertino, Calif., company had received a patent on a feature that had debuted in a third-party app some three years before its 2012 filing.

Delete tweetThe problem was, Apple had only applied for a patent on a text-while-you-walk system that would overlay message conversations on your phone camera’s view of your surroundings. Oops.

So I tweeted something, um, transparently wrong. Now what? I’ve attended more than one panel discussion on this, and the answers usually get stuck on one of two conflicting imperatives: Don’t let the error go unfixed, but don’t look like you’re hiding the mistake either.

(See my earlier post about documenting changes to your story, if necessary in comments you leave yourself.)

Since you can’t edit the incorrect tweet or even flag it as wrong in the way you could amend a flawed story or blog post, letting it stand risks perpetuating the mistake. But if you delete it, then the evidence of your error vanishes.

What I decided to do was to delete the tweet, follow up by saying what I’d gotten wrong, and then redo the original tweet with a reasonably obvious hashtag, #corrected, to indicate that it was a “CX” for an earlier version:

Does that routine work for you all? Or am I once again seriously overthinking something that people with real jobs don’t worry about at all?

In other news, earlier this afternoon I was glad to see that the Ask Patents clearinghouse for prior art will include this Apple filing in an upcoming call for submissions:

 

Snapshots from SXSW

It’s now been three days since I got off the plane at National Airport, officially ending this year’s SXSW itinerary, and it’s taken me that long to catch up on sleep, do laundry and edit and upload pictures. (The traditional post-conference LinkedIn binge remains undone.)  And maybe I’ve gained a smidgeon of perspective on the event too.

Attendees make their way through the convention center.Once again, my primary first-world problem was deciding which panels and talks to attend. I was more ruthless and/or lazy this time, deciding I wouldn’t even try to get to such relatively distant locations as the AT&T Conference Center at the University of Texas’s campus (where my 2012 panel drew maybe 20 people) or the Hyatt Regency at the other end of the Congress Avenue Bridge.

But then I wound up not watching any panels outside the convention center and the Hilton across the street. Of those, remote interviews with Julian AssangeEdward Snowden and Glenn Greenwald topped my list. But I was also fascinated by a debate about net neutrality in which law professor Tim Wu noted our own responsibility in putting a handful of giant companies in charge (“we don’t have a culture on the Internet of preferring alternatives”), a talk about wearable computing that pivoted to discussions of “implantables” and “injectables,” and an honest unpacking of the failure of tech journalists to break the NSA-surveillance story (TechCrunch co-editor Alexia Tsotsis: “We need to step back from our role as cheerleaders and give a more critical eye to the people we’re surrounded with”).

My geographically-restricted attendance led me to miss many other discussions that had looked interesting beforehand. Not only was this narrow-minded conduct, it stopped me from walking around more to make up for all the food I ate.

It would be hard to avoid putting on a few pounds while in Austin on a normal weekend, but when you don’t have to pay for most of your food, courtesy of pervasive corporate and PR sponsorship, the city becomes a thoroughly enabling environment. And a delicious one! For example: the brisket at La Barbecue (thanks, Pinterest), algorithm-driven cuisine at IBM’s food truck, and breakfast tacos at Pueblo Viejo (that was on my own dime, and you should be happy to spend yours there too when you’re in Austin).

Austin’s nightlife hub on the first night of SXSW Interactive.As for empty calories–um, yeah, they’re not hard to find at SXSW either. This is the single booziest event on my calendar. That can be an immense amount of fun (my Sunday night somehow involved both seeing Willie Nelson play a few songs with Asleep at the Wheel from maybe 20 feet away, followed by the RVIP Lounge’s combination of touring bus, open bar and karaoke machine), but waking up the next morning can be brutal. To anybody who had a 9:30 a.m. panel on Sunday, only hours after the time change cut an hour out of everybody’s schedule: I’m so sorry.

And then the night after I left, some drunk-driving idiot crashed through a police barricade and killed two people.

Even before that, the “do we really need this event now that it’s been overrun by marketing droids?” conversation about SXSW was louder than usual. I have to note that three of the most interesting panels–the Assange, Snowden and Greenwald interviews–featured subjects thousands of miles away; in theory we all could have watched those from home.

But this is also an event where you meet people you wouldn’t otherwise see and might not ever meet–a long-ago Post colleague from copy-aide days, Internet activists you should know for future stories, journalists who put up with the same problems as you, entrepreneurs with interesting ideas that might go somewhere, and so on. Maybe this is a colossal character defect on my part, but I enjoy those conversations–even the ones with the marketing droids. And that’s why I do this every year.

(After the jump, my Flickr set from the conference.)

(7:30 p.m.: Tweaked a few sentences because I could.)

Continue reading

So long, Sulia: lessons from an experiment in compressed journalism

My time contributing short updates to the microblogging site Sulia wrapped up unceremoniously Monday morning when an e-mail–“ending our paid arrangement”–landed in my inbox. The site’s pivoting in another direction that doesn’t involve paying for my input or that of what seems to be most other contributors it had signed up (for example, my friend Rocky Agrawal); so it goes.

Sulia compose dialogThe departure of any one freelance client isn’t that big of a deal, but in this case it was a different sort of medium, and I learned some things along the way that seem worth sharing.

The basic idea here was to get paid a little for writing the equivalent of three tweets in a row–a minimum of 700 characters, a maximum of 2,500. On clicking the “Post” button at Sulia, those updates would appear automatically under my name on Twitter and at my public Facebook page–and that’s when I was met with confusion. Readers had no idea what the heck Sulia was or what I was doing there, leading me to post an explanation here after the first three weeks.

It took longer for me to pace myself so that I wouldn’t be rushing to finish my weekly quota of 10 posts in the last hours of Sunday–and to figure out what topics fit best into this pressurized container. In retrospect, holding off on live-tweeting interesting talks so I could post a longer recap on Sulia was a mistake, while it was smarter to use that greater character count to break some local wireless news in slightly more depthdo the cost-of-ownership math for a new smartphone, or recount my experience upgrading an operating system.

Overall, this site filled a useful void in my work by allowing me to share my notes in a medium slightly longer and less evanescent than Twitter while also getting paid (and without having to send an invoice first). I‘m not sure how I’ll replace that.

Among no-payment options, Twitter puts me back in a 140-character box, Facebook and Google+ have enough of my personal business already, LinkedIn seems too business-focused, and as for Medium–well, I already have a blog here. Alas, my WordAds revenue has been so minimal to date that it’s not worth thinking about the potential income from any one extra post.

Or perhaps the Sulia experiment was a mistake all along, and I should have put the time spent crafting those 40-some morsels a month into finding three or four good stories to sell elsewhere. Either way: on to the next thing…