Category Archives: Uncategorized

Conference Calls on iPhone

I do a lot of conference calls. I love the convenience of tapping a number almost anywhere on my iPhone 6 and having it dial the number, whether it’s from a meeting in my calendar or in an email. But most conference call numbers require a pin or meeting code to connect to the meeting and for the longest time I was frustrated with having to remember the code. I finally figured out the easy way to handle the conference call and pin number.

You can provide the phone number and conference pin to the phone app if you format it like this:

1-800-123-4567;123-456-789#

That’s the call-in number, semi-colon, conference pin and pound sign. The semi-colon inserts a hard break or pause, allowing the phone to dial just the initial number. When you tap on a number that’s properly formatted, the iPhone will dial the number and the conference pin will show up in the bottom left-hand corner next to the word “Dial…”

dial_pin1

Listen for the conference call service to answer and prompt you for the pin, then tap “Dial” and the pin number will by typed in. No more remembering the pin!

Some conference scheduling software formats the number such that this works without any changes, and for any invitations you create you can now make sure to format them the right way.

If you know you need to call in using a number that’s not formatted properly, you can still set things up so you don’t need to remember the pin. Copy the phone number and pin from wherever they are, email, document, etc., and paste it into a note in the Notes app. Format it as described above, then copy the whole thing.

Open the phone app and tap and hold for a second in the white area above the number pad. When you do, the paste menu will show up allowing you to paste in the phone number plus pin.

paste_number

The phone will dial and the pin will show up in the bottom left-hand corner as before. Again, no more remembering the pin!

Is IoT All Win-win?

A recent Freakonomics podcast got me thinking about the creative destructive potential of the Internet of things. Thinking simply, there are three reasons business will embark on IoT projects: save money, make money, and help with regulatory requirements.

If you think about the potential of those, they sound great. The creative efforts there don’t seem obviously destructive for many use cases because we’re adding sensors and collecting data in places we just didn’t watch before. It sounds like a story with no losers because efficiency is an all upside conversion, right?

As I thought about it, I realized it’s not that simple. Here is an example.

If you’ve every been to a wine bar, you’ll know they sell wine by the glass and by the bottle. The wines at a wine bar are higher-end than a typical bar, so when they open a bottle to give a customer one glass, they are taking the risk that they may not be able to sell every glass in that bottle. There are tons of varieties and once opened the bottle only stays fresh and sell-able for so long. This can create a large and expensive waste of wine.

What if new IoT corks with sensors in them could track the quality of the wine and time since each bottle has been opened? The wine bar owner could then have a daily report of what is available and offer specials on opened wine they need to sell to get the most out of the bottles they have already opened.

It sounds all win-win, right? Customers get a daily special, the owner wastes less wine.

But this probably results in the wine bar owner buying less wine because they are wasting less. That’s where the savings comes from. So the wine sellers are likely to sell less wine over time because in the current system, the amount they sell includes the wasted wine.

Like the piano makers at the turn of the last century, it seems there are few acts of creative destruction that can be purely, or even mostly, win-win. In the past, these disruptions have always led to more and better opportunity. Depending on your view, this may still be the case with the internet revolution in general. In the IoT business specifically, at least in the near term, the huge amount of work to implement and get the full value from the new data should offset the losses from the creative destruction. The longer-term impact is much less clear.

 

Father’s Day Gifts Through the Generations

As I happily opened my Father’s Day gifts yesterday, I looked at my shiny new keychain and said, “Now I just need some more keys to put on this. But in a few years we won’t even have keys anymore, IoT will turn my cell phone into my keys.”

My wife and I then started discussing Father’s Day gifts through the years and we both remember exactly what we made in school for Father’s Day when we were kids: ashtrays. It’s amazing to think about it now, when smoking is relegated to a dwindling number of designated areas, but back then everyone smoked. To get a feel for how pervasive it was, just watch an episode of Mad Men. Now we need to explain to our kids what an ashtray is.

How long before we hold up something like a brass key as a mysterious artifact of the past, something you only see at your grandparents’ house?

My daughter didn’t miss a beat and said, “If that happens, then we’ll just make you a cell phone case.”

And of course she’s exactly right. I can’t wait for the 3D printers to hit our schools and art/shop classes.

Working with Software Support

I write software and over my IT career I’ve been on both sides of software support: needing support for an issue and providing support to customers for a software product. Getting support for potentially complex problems with complex software that you’ve heavily configured can be a challenge. Here are some ways to make the process easier for people on both sides of the support system.

What’s Wrong?

Most support starts off with the customer describing some issue they’re having in text and sending it off to the support organization. This might be an email alias like support@example.com or a web form in a support portal. The point is it usually starts off with text, which is a really rough way to describe a detailed problem.

Where do you start? Here’s the standard initial points you need to address first:

  1. What did you do? Give the minimum number of steps to reproduce what you’re going to mention in 3.
  2. What did you expect to happen?
  3. What happened?

This covers the basics, helps you focus the issue on exactly what’s wrong, and allows the support person to start to focus on “our software doesn’t do that” or “yeah, that’s not right”. If the software has a GUI, screenshots can provide a lot of information easily.

After the basics, you may want to add some more detail about the issue. If you’ve seen advice that you should hire developers who have excellent writing skills, writing bug reports for support is one of the reasons. Whether you’re filing a bug report for another developer on your team or sending off a support request, you need good writing skills to accurately and concisely describe a complex issue.

Fundamentals

If you want to avoid a guaranteed back-and-forth at the beginning, you should also provide as much of your environment information as possible up front. This includes the version of the software you’re running, including any updates or patches. Provide the system it’s running on, whether it’s RedHat Enterprise Linux 6 or Mac OS X 10.7.5 Lion.

Then include any other relevant diagnostic information. If the software has a configuration page, send along a copy or screenshot. If it has logs that you’re aware of, send along a relevant section gathered as you demonstrated the error. You may not see anything useful there, but even the absence of messages can be helpful for the support person.

Provide background on any history if there is one. You may have had similar issues in the past and support gave you a patch or update. Support may have provided steps to fix something similar previously, but the fix isn’t working this time. Provide support ticket numbers if you have them just in case the new support person couldn’t find them.

You don’t want to overwhelm the support person, but lastly you can include what you’ve tried so far. You may still get the standard “try this” response, but if you get a human on the first try, you might get bumped up to an engineer if you’ve already hit all of the obvious first steps (clear your cache, reboot, apply the latest system updates, etc.).

Following Directions

You’re probably working really hard to fix the issue on your own, which is why I suggest telling support everything you’ve tried. But once you send off the support request, it’s time to stop trying things randomly on your own. The support person is going to try to reproduce your issue and it can become very difficult if you become a moving target. In the best case, you’ll fix your issue but you won’t quite know why, which means it could happen again. In the worse case, you’ll cause another issue and then you’re really in a bind because you can’t easily answer 1, 2, and 3 from above because you were “just trying things.”

Assuming you have a decent support company and your boss has paid for a reasonable SLA, you should get a response in a reasonable amount of time. Unless it’s a really common issue, they are likely to send some instructions that will either give them some additional information or potentially solve the problem.

Do what they ask.

One of the more puzzling things I’ve encountered is the frequency with which support customers ask for help, then do everything but what you suggest. The support person is trying to piece together your problem from only a few clues and when they ask for something, they probably have an idea what’s wrong. They may be trying to rule out a known bug or confirm a particular setting or detail. When you do what they ask, you help them move along their train of thought. When you try a bunch of other things, they essentially need to reset and start again with how your system is set up now.

The Whole Story

You’re sitting there waiting for a response, your boss is bugging you every 15 minutes for an update, and I’m saying don’t try things. It’s understandable if you get a little antsy, especially if you get an idea after dwelling on the problem for a few hours or days. If you do make changes, keep track of exactly what you’ve done and let the support person know on the next exchange. Yeah, maybe you did something you shouldn’t have. Keeping it a secret just compounds the mistake.

Likewise, if you’ve been gathering information from other people on the issue, send along new information as you learn it. This is especially important if you track something down and find out you got incorrect information previously. Support may be holding off on sending you a fix because it doesn’t make sense given that part of the puzzle.

Closing

If you’re lucky, you’ll get a good support person and they’ll get you a fix. It might be a patch or update, a configuration change, or a reboot. Whatever the case, when the issue is resolved and you’re back up and running, reply back so the support person can close the ticket. Some support organizations are evaluated based on closing tickets. Knowing you’re all set helps them keep their ticket system cleaned up. Some systems auto-close after a period of inactivity, but the ticket history won’t reflect whether you got things fixed, especially if the last response included several things for you to try.

We all rely on software and it can be panic-inducing when it becomes uncooperative. Having good support available is one safety measure. Knowing how to work with them effectively is another.

Setting Up a Blog

Seth Godin‘s advice for people is to blog everyday. He doesn’t understand why everyone doesn’t do it. Well, I’m finally taking his advice and I think I can offer some insight into what stands in the way.

First Steps

I’ve always thought it would be a good idea to blog, but after attending a Seth Godin talk where he repeated his blogging advice, I decided to finally get going. But where to start?

I write software for a living, so of course my first thought is to set up something self-hosted because, you know, I might want to hack on the source. Being mostly a Perl guy, I started searching for something in Perl and found Movable Type is still a leading blog platform. I found the community site and the project on github. As I read more, however, I ran across the blog posts about license changes and found them all very confusing. Looking at the github project, I couldn’t find any clear software license referenced in the README. When I found the license purchase options, the minimum is a 5-user license, so it seems they are now focused on business users and not individual bloggers.

After spending a few days reading about all of this I realized I was allowing myself to get distracted from the main goal, setting up a blog. Did I really need to hack on the source? Of course not, the goal is to get up a blog post somewhere.

Hosted Blogs

The shortest path is a hosted blog service. There are a wide array of free and fee-based services. I read David Pogue occasionally, and noticed he recently started blogging on Tumblr. I thought this was interesting for someone who essentially writes for a living, then I realized this was likely because of his move to Yahoo from the New York Times (Yahoo bought Tumblr last year).

The conventional wisdom regarding free services is that if you’re not paying for the product, you are the product. As agreements go, Tumblr’s agreement appears to be one of the better ones, with subscribers retaining rights over their content. But I was still wanted to avoid being someone’s product.

Seth Godin’s blog is on Typepad and I also use their platform for our work blog. Having a service that is 100% managed, including updates and managing security is attractive. Starting at $9 per month, and $15 per month for the “Unlimited” plan, it seemed a little much just to get something going. I also find their interface a little pushy with the “related story” suggestions.

Around this time I also caught up on some podcasts and came across an episode of InBeta discussing blogs and blogging platforms. Sadly, hearing about all of the new options out there made me even more unsure what to choose to get my blog going. Kevin Purdy’s multi-step system has the advantage of being freely hosted via github’s hosted pages, but it seemed like a fair bit of work to get something posted. The last thing I need is more barriers to getting this thing going.

Then I realized this was all another distraction. The goal is to get a blog post up!

Hosting Service

I already had some domains registered with Pair Networks via PairNIC and Pair also does hosting. Maybe that was my next stop? I looked at the hosting plans, briefly circling back to installing one of the open source products myself. Worrying I was headed down another path of fiddling with an install, I was happy to find their software installation manager.

Most of the major hosting services have these sorts of service panels now to make it easy to install open source products. Since the products are open source, the licenses are usually clear. Using the installation managers also means you don’t have to worry about running into dependency problems on the hosting platform. They have sorted all of that out.

Pair supports Movable Type in their install service, meaning I could still work with a Perl-based platform and avoid getting bogged down in the install. There’s a fair bit on the web comparing Moveable Type to the other leading blogging platform, WordPress. Most say they are generally comparable feature-wise. I revisited the Movable Type licensing terms and still couldn’t figure out what the terms really are for the open source install. Fearing some strange licensing issues when my blog becomes wildly popular, I decided on WordPress. The other factor is the number of themes. WordPress seems to have a million out there, both free and paid.

Getting all of this out of the way, I was able to register a domain with PairNIC and set up a year with Pair hosting plus software installation manager for about $120 for the year, which is comparable to the TypePad rates. The installation manager worked great, allowing me to first install Movable Type, uninstall when I changed my mind, and then install Word Press. Since I had registered my domain with Pair, it was easy to launch the blog on my domain.

Success

Getting this blog actually launched was amazingly easy once I finally sorted through all the options and figured out what I actually wanted to do. It’s true that having so many options is liberating, but also paralyzing. For now I’m happy with the outcome and I’m 100% in control. Now I just need to think about the theme, the layout, and topics for blog posts, but all of the distractions around those are for another post.