August 2010 Archives

I know y'all can't live without another update so here it is.

The VerizonSupport twitter account sent me a secret URL to give them my account info and problem description. After filling it twice (separated by 2 days), I got no phone call, no email, no results.

Today I called and was told that the IVR system transfered my phone call to billing because I was entering my phone number (as asked) but since I don't have Verizion phone service it was confused. That is the phone number on my account, and it certainly is able to look up my account after I've entered it, but the person assured me that this was the problem. I should select the option where I enter my account number instead of my phone number and it should work.. promise.

When I got home (where I have the account number) I did as requested and of course the system said it is transferring my account to billing.

So what to do?

Well, I've tried billing and tech support with no luck. I decided to call sales. Stephanie and I had an ok conversation. She said that last month my account was "in treatment" and now it definitely isn't so there should be no outage on Wednesday. I pointed out that the IVR system disagrees, but she said I should "let it go". She also said that if I do have an outage on the first of the month, they can cancel the account and recreate it. I'd have a 20 minute outage. She wrote all of this up in my account notes.

Wednesday I'll be "oncall" for work from 4pm to midnight. If there is an outage in the morning, I'll be spending all day getting it fixed so that I can have connectivity for my oncall shift.

I've spent more than 10 hours on the phone with Verizon at this point.

What surprised me when I attended Ohio Linux Fest was that it is a national conference; it draws people from all over.

One of the little-known gems at OLF is their training sessions called "OLF University." It is excellent training that is at a very nice price. Considering the high-caliber trainers that they've recruited, I think (and I've told OLFU coordinators) that training like this should be priced 2x or 3x higher. The productivity boost from just one class will pay for itself in a month or two. I recommend people sign up before the organizers start listening to me.

Beth Lynn Eicher wrote a great article about OLF and the training. Check it out.

If you aren't going to OLF University, but are going to OLF, be sure to stop by the LOPSA table!

I'm going to have a completely new tutorial at LISA 2010. I'm developing the material right now and the more I see, the more I like it.

I'll announce the topic soon :-)

Quick update:

1. no manager called me back.

2. I found @verizonsupport on twitter.

3. They gave me a URL to visit that asks for my account info (and my twitter name) so that they can investigate.

Keeping my fingers crossed...

In the last few weeks I've written about ways to get peers to adopt a technology you like, and how to get your managers to adopt it too. Today I'd like to point out some "non-traditional" strategies you might employ when those fail. This list was created when talking with a reader about how to get approval for installing a trouble-ticket system.

Often the non-technical push-back is against the entire concept of ticket systems and nothing will be "good enough". In that case, don't bring a knife to a gun fight. In fact, find a way to avoid the fight entirely.

The Art of War and other strategy books would suggest alternate strategies like these:

• Privately confront the primary dissenter directly: talk privately with the person to find the reasons behind their actions and settle those issues. Enlist them as a supporter.
• Go around the dissenter entirely: set up the ticket system of your own choosing for a project they are not involved in, when it is successful it will be politically difficult not to expand its use to all projects.
• Go over the dissenter's head: get the dissenter's boss on board.
• Leverage influential people: If there is someone that the dissenter feels walks on water and can do no wrong, get an endorsement from that person.
• Act faster: install something and put it into action before they can push back.
• Act slower: are there benefits to putting off the decision? For example, will the dissenter retire or change jobs soon? (You may not be allowed to know that they are on the way out. If your boss smiles knowingly when you ask, maybe they know something you don't know.)
• Produce more data: Gather data and produce charts that show undeniably you are right (don't show a single charts that disagrees; if the dissenter doesn't have the raw data, they can't make those charts).
• Produce less data: Work in secret to build the system.
• The power of crowds: Can you get a lot of other people on board such that the dissenter is outvoted?
• The Power of the Demo: Are they rejecting a system they haven't actually used? Install your preferred solution on a VM and give demos to likely supporters. (The secret to a successful demo is doing at least 5 dress rehearsals)
• Divide an conquer: Find out where the opposition isn't in agreement with each other and play one side against the other.
• Isolate dissent: Identify the dissenters and exclude them from the process (find a politically viable justification for this).
• Overload the dissenter: Give them so much other work to do that they don't have time to dissent; or put so much of the research on their shoulders that they ask to be taken out of the decision process.
• Reduce the choices: Don't show 15 different models and hope they pick the one you want. Only show options that you will accept.
• Give too many choices: Show so many potential products that they are overwhelmed; declare your expertise and recommend the one you want.
• Selective comparison: Show 1 really awful system followed by a perfect demo of your system. (In a related note: At a singles bar always stand next to an ugly person.)
• Force a "win": Get agreement to default to your solution if a decision isn't made by a certain date ("because we can't delay ProjectX"). Make sure you've given them more work than can be accomplished by that date so-as to trigger the default.
• Make the dissenter think they are making the decision: If you ask a child "what do you want for dinner?" they'll ask for ice cream. If you ask, "Should we have hamburgers or hotdogs?" they'll think they're making the decision even though you've already made it for them. (Worst of all: don't list choices one at a time, they'll keep saying "no" until you run out of choices: "Do you want hamburgers?" "no" "Do you want hotdogs?" no "Umm... well, we have ice cream" "yes!").
• Take advantage of emergencies: In an emergency the normal decision process goes away. Can you create a situation (or wait for a situation) where you can get permission to install RT or ORTS "just for this one emergency" and then take advantage of the fact that "nothing is more permanent than a temporary solution"?)
• Bullies only respect other bullies: Declare that your solution is the ONLY solution and brow-beat anyone that disagrees.
• Discredit the enemy: If the dissenter is always going to find reasons to reject something, don't try to deal with the points they bring up; discredit the dissenter's opinions. ("He isn't a real stake-holder, why should we listen to him?" "He rejects anything new, remember the time....", "He won't even be using the system, why is he causing trouble for us?")
• Running code beats vaporware: a running system beats the theory that it won't work.
• Avoid the issue: Find another project to work on that will make you a success; leave this "can't win" situation to co-workers that are suckers.

If done right, these strategies could work or could get you fired. Proceed with caution. Work with your boss, or if you boss the problem, confer with peers.

Please post comments with your suggestions and experiences. (This website now supports OpenID and other systems.)

After my recent story about the problem Verizon FIOS is having with my account, I decided (with the prompting of Chris) to be pro-active and call them. Since I know the problem still is lurking, it is better to get it resolved rather than tempt fate on the next "first of the month."

Just to keep my dear readers (all dozen or so of you) informed, I'm going to post about my progress.

Today while at work I spent 90 minutes trying to get through to someone that could help me.

Attempt 1: The person transfered me to tech support who couldn't help me.

Attempt 2: For some reason I got transfered to billing in a state other than NJ. They couldn't help me but transfered me to the right billing center. (Why is their system not sending me to the right billing center? Could that be a symptom?) When talking with this person I created a 3-way call so he could hear the problem himself. It takes about 5 minutes to get to the point where I get transfered, and right before we got to that last, final prompt he shouted "agent" which made the system stop what it was doing and transfer me to a human. Thus, at this point no Verizon employee has seen the problem demonstrated. I was so frustrated at that point that I said something about being too upset to continue and hung up.

Attempt 3: the person at this billing center took the time to understand my problem but kept repeating that he couldn't change how the phone system works. I would calmly explain that this is triggered by something being wrong with my account, and could he help me with that. He said there is nothing wrong with my account. I agreed and said, "Since we both agree that there is nothing wrong with my account, I shouldn't be transfered, right?" At that point we would repeat our conversation. I literally got him to go in this circle 3 times. I was nearly laughing.

I feel sorry for the guy. He works at a payment center. His job is to take people's credit card info and process payment. Obviously I'm not talking to the right people.

I asked to have this escalated. He took my phone number and said that a manager will call me within 4 hours. That was at 11:30am.

Another data point: I just remembered that when I ordered the service I called from my desk phone in NYC and went to the NYC sales office. There was a problem because New Jersey is sold out of the New Jersey office. She was able to put the order in anyway. I wonder if my account is in some kind of limbo because the order was placed from the NYC sales office but the service was delivered to New Jersey.

Anyway... I've got a lot of work to do today. I'm putting this to rest until they call me back.

As part of Ohio Linux Fest's training program (called "OLF University"), LOPSA will be offering the following classes on Friday, September 10th:

• IPv6 essentials and deployment Strategies
• Black Magic: Linux Troubleshooting and System Administration
• Application Acceleration and Tiered Storage and Archiving
• Monitoring and Nagios
• Introduction to Automating System Administration with Cfengine
• Data Centers: Planning, Expanding, Managing

These classes will be taught by community luminaries such as Dale Carter, Jonathan Billings, and John Sellens.

A full class schedule can be found at http://www.ohiolinux.org/olfu.html

LOPSA instructors return for the fourth year to Ohio Linux Fest in Columbus, Ohio on Friday September 10th - teaching 6 out of 11 classes at Ohio Linux Fest University.

LOPSA serves the public through education on system administration issues; Ohio Linux Fest promotes the education of Linux and Free and Open Source software.

Classes will give OLFU students an intense and personal learning experience. The traditional Ohio LinuxFest conference and expo will take place on Saturday, September 11th. Registration for OLFU is part of the Ohio LinuxFest "Professional Package", which costs $350. It includes OLFU training classes on September 10, admission to The Ohio LinuxFest on September 11, lunch on both days and an official conference t-shirt.

Class sizes will be limited so OLFU students can receive the very best personalized professional training. Classes are by available by pre-registration only. Registration for OLFU will not be available on-site. To register, please visit https://www.ohiolinux.org/register.html

It used to be that when there was an emergency, such as a car accident, someone might go inside the house to call for an ambulance.

Now in that situation you go outside the house, to make sure you get a clear signal.

Hmmm...

Tom

P.S. Remember when people would say things like, "Could I use your phone?" and you'd walk them to the room in the house with the phone?

I wrote about upgrading to IPv6 in the past, but I have more to say.

The wrong way: I've heard a number of people say they are going to try to convert all of their desktops to IPv6. I think they are picking the wrong project. While this is a tempting project, I think it is a mistake (well-intentioned, but not a good starter project). Don't try to convert all your desktops and servers to IPv6 as your first experiment. There's rarely any immediate value to it (annoys management), it is potentially biting off more than you can chew (annoys you), and mistakes affect people that you have to see in the cafeteria every day (annoys coworkers).

Instead copy the success stories I've detailed below. Some use a "outside -> in" plan, others pick a "strategic value".

Story 1: Work from the outside -> in

The goal here is to get the path from your ISP to your load balancer to use IPv6; let the load balancer translate to IPv4 for you. The web servers themselves don't need to be upgraded; leave that for phase 2.

It is a small, bite-sized project that is achievable. It has a real tangible value that you can explain to management without being too technical: "the coming wave of IPv6-only users will have faster access to our web site. Without this, those users will have slower access to our site due to the IPv4/v6 translaters that ISPs are setting up as a bandaid.". That is an explanation that a non-technical executive will understand.

It also requires only modest changes: a few routers, some DNS records, and so on. It is also a safe place to make changes because your external web presence has a good dev -> qa -> production infrastructure that you can leverage to test things properly (it does, right?).

Technically this is what is happening:

At many companies web services are behind a load balancer or reverse proxy.

ISP -> load balancer -> web farm

If your load balancer can accept IPv6 connections but send out IPv4 connections to the web farm, you can offer IPv6 service to external users just by enabling IPv6 the first few hops into your network; the path to your load balancer. As each web server becomes IPv6-ready, the load balancer no longer needs to translate for that host. Eventually you're entire web farm is native IPv6. Doing this gives you a throttle to control the pace of change. You can make small changes; one at a time; testing along the way.

The value of doing it this way is that it gives customers IPv6 service early, and requires minimal changes on your site. We are about 280 days away from running out of IPv4 addresses. Around that time ISPs will start to offer home ISP service where IPv6 is "normal" and attempts to use IPv4 will result in packets being NATed at the carrier level. Customers in this situation will get worse performance for sites that aren't offering their services over IPv6. Speed is very important on the web. More specifically, latency is important.

[Note: Depending on where the SSL cert lives, that load balancer might need to do IPv6 all the way to the frontends. Consult your load balancer support folks.]

Sites that are offering their services over IPv6 will be faster for new customers. Most CEOs can understand simple, non-technical, value statements like, "new people coming onto the internet will have better access to our site" or "the web site will be faster for the new wave of IPv6-only users."

Of course, once you've completed that and shown that the world didn't end, developers will be more willing to test their code under IPv6. You might need to enable IPv6 to the path to the QA lab or other place. That's another bite-sized project. Another path will be requested. Then another. Then the desktop LAN that the developer use. Then it makes sense to do it everywhere. Small incremental roll-outs FTW!

During Google's IPv6 efforts we learned that this strategy works really well. Most importantly we've learned that it turned out to be pretty easy and not expensive. Is IPv6 code in routers stable? Well, we're now sending YouTube traffic over IPv6. If you know of a better load test for the IPv6 code on a router, please let me know! (Footnote: "Google: IPv6 is easy, not expensive Engineers say upgrading to next-gen Internet is inexpensive, requires small team")

Story 2: Strategic Upgrades

In this story we are more "strategic".

Some people run into their boss's office and say, "OMG we have to convert everything to IPv6". They want to convert the routers, the DNS system, the DHCP system, the applications, the clients, the desktops, the servers.

These people sound like crazy people. They sound like Chicken Little claiming that the sky is falling.

These people are thrown out of their boss's office.

Other people (we'll call these people "the successful ones") go to their boss and say, "There's one specific thing I want to do with IPv6. Here's why it will help the company."

These people sound focused and determined. They usually get funding.

Little does the boss realize that this "one specific thing" requires touching many dependencies. That includes the routers, the DNS system, the DHCP system, and so on. Yes, the same list of things that the "crazy" person was spouting off about.

The difference is that these people got permission to do it.

According to a presentation I saw them give in 2008, Comcast found their 'one thing" to be: Settop box management. Every settop box needs an IP address so they can manage it. That's more IP addresses than they could reasonably get from ARIN. So, they used IPv6. If you get internet service from Comcast, the settop box on your TV set is IPv6 even though the cable modem sitting next to it providing you internet service is IPv4. They had to get IPv6 working for anything that touches the management of their network: provisioning, testing, monitoring, billing. Wait, billing? Well, if you are touching the billing system, you are basically touching a lot of things. Ooh, shiny dependencies. (There used to be a paper about this at http://www.6journal.org/archive/00000265/01/alain-durand.pdf but the link isn't working. I found this interview with the author but not the original paper.)

Nokia found their "one thing" to be: power consumption. Power consumption, you say? Their phones waste battery power by sending out pings to "keep the NAT session alive". By switching to IPv6 they didn't need to send out pings. No NAT, no need to keep the NAT session alive. Their phones can turn off their antenna until they have data to send. That saves power. In an industry where battery life is everything, any CxO or VP can see the value. A video from Google's IPv6 summit details Nokia's success in upgrading to IPv6.

Speaking of phones, T-Mobile's next generation handset will be IPv6-only. Verizon's LTE handsets are required to do IPv6. If you have customers that access your services from their phone, you have a business case to start upgrading to IPv6 now.

In the long term we should be concerned with converting all our networks and equipment to IPv6. However the pattern we see is that successful projects have picked "one specific thing to convert", and let all the dependencies come along for the ride.

Summary:

In summary, IPv6 is real and real important. We are about a year away from running out of IPv4 addresses at which point ISPs will start offering IPv6 service with translation for access to IPv4-only web sites. Successful IPv6 deployment projects seem to be revealing two successful patterns and one unsuccessful pattern. The unsuccessful pattern is to scream that the sky is falling and ask for permission to upgrade "everything". The sucessful patterns tend to be one of:

• Find one high-value (to your CEO) reason to use IPv6: There are no simple solutions but there are simple explanations. Convert just that one thing and keep repeating the value statement that got the project approved. There will be plenty of dependencies and you will end up touching many components of your network. This will lead the way to other projects.
• Work 'from the outside -> in": A load balancer that does IPv6<->IPv4 translation will let you offer IPv6 to external customers now, gives you a "fast win" that will bolster future projects, and gives you a throttle to control the speed at which services get native support.

I'd love to hear from readers about their experiences with convincing management to approve IPv6 projects. Please post to the comments section!

-Tom

P.S. Material from the last Google IPv6 conference is here: http://sites.google.com/site/ipv6implementors/2010/agenda

I just added a new item to my list of dumb things to check. (Maybe I should call it my "things to check when you think you've tried everything").

The new item is: * Is it the first of the month? Maybe there is a billing problem and something got shut off.

A few Sunday's ago my Verizon FIOS connection went dead. Not the entire connection, just the internet. The TV still worked (I don't have the phone service)

I did the usual debugging steps but nothing worked. Realizing it was the first of the month, I thought "hmm.... could this be a billing issue?"

I called tech support and entered my account number. After 6 different prompts (!) rather than sending me to tech support the computer voice said, "Hmmm... it appears your problem can't be solved by technical support. Please hold on for a moment." (yes, the synthesized voice actually said, "hmmm"). After a few rings I got a message, "Sorry, the finance department is closed. We re-open Monday at yadda yadda yadda."

August 1st, you see, is a Sunday. With no way to reach technical support (no matter what I tried I got redirected) I was sunk until Monday. Luckily I wasn't oncall.

On Monday I called again. Since the finance department is only open hours that I'm at work, I was hoping that their procedure wouldn't require me to have physical access to my stuff at home.

Finance said that there's nothing wrong with my account and my service should be fine. As a testament to this, they pointed out that my TV service works, so obviously I wasn't shut off.

She also pointed out that I have a credit of $41.32. That number sounded familiar. Ah yes, the prior month when there really was a billing problem that number came up. However, that got resolved.

What was the chance that when the problem was resolved last time there was still a flag sitting around somewhere that meant "disconnect this customer on the first of the next billing cycle". Such a bug wouldn't appear until the first of the next month, eh? Knowing that TV and ISP subsystems are probably entirely different provisioning systems that get fed from sources, how likely is it that they got out of sync? How likely is it that when the last billing problem got resolved the flag was flipped for TV service but the request to flip it for the ISP service got lost by a buggy batch job somewhere? (My hunch: someone forgot to include unittests for the weird case of a customer having FIOS with no phone service.)

I was about to give up when I realized that the phone system had transfered me to her. Thus, some database somewhere thought I had a payment problem on my account. I pointed this out to her and she couldn't deny my logic. I could hear her typing. Suddenly she said, "Oh, that shouldn't be.. um... how could that be?" I could hear her typing a bit more.

Then she said, "Ok, things are fixed here. Now I need to transfer you to tech support so they can make sure that things are activated." I thanked her profusely.

To make a long story short, the tech support people were confused, also claimed that my account was fine, and I had to explain that things really weren't fine.

Of course, since I was at work and not at home I couldn't reboot my router (their "go to" solution for most problems, and rightly so). However, I could point out that I couldn't ping my router. They could ping their end. They could reboot their end.

Using a little verbal jujitsu, I asked them if they could reboot my router remotely. They said they could even when the system was otherwise down. But wait... he coudn't access it through that out-of-band channel! Ah, this holds promise.

Verizon FIOS installs a little box in the basement that is essentially a UPS so that during a power outage you can still make phone calls. In that box is a bit of network equipment that can only be rebooted by removing the battery from the UPS or by having Verizon reboot it remotely. He suggested I pull out the battery when I get home and call back if that didn't fix it. I asked him to reboot remotely (I didn't want to have to call back and explain the entire situation to a new tech).

After the reboot, he could see my router, but he could also see that their DHCP server wasn't giving me an address. This, good friends, was another instance of "the flag" causing problems.

He had to tweek some stuff (I hope he meant re-pushing a database) and soon it was doing DHCP right. Moments later I could ping my home router.

Success!

End note: I'm writing this blog post on Aug 22 but I'm scheduling it to not appear until August 31. Since September 1st is a Wednesday the billing department will be open if "the flag" haunts me again... though from midnight to 9am I'll be dead in the water. I just tried calling tech support and was transfered to the finance department.

Registration for OLF opened today. This conference draws people from all over the country, not just Ohio.

The Ohio LinuxFest is proud to announce that registration is now open for Ohio LinuxFest. The schedule has also been announced, and this year will feature a fantastic line-up of talks for new and experienced Linux users. The 2010 Ohio LinuxFest takes place in Columbus, Ohio at the Greater Columbus Convention Center from September 10 through September 12, 2010.

The keynote is Christopher “Monty” Montgomery of Xiph.org will be talking about next generation open source media formats.

Admission is free but space is limited. Supporters can opt for the $65 package that includes lunch and an OLF t-shirt, or the $350 package that includes admission to the “OLF University” training program (which is so good I really think they should charge twice as much. Sign up before they start listening to crazy people like me!)

Sign up today at http://ohiolinux.org/register.html

More info at http://ohiolinux.org

Usenix now has a YouTube channel!

Whether you want to watch a short, funny talk about Electronic Voting, the "Best Paper" presentation about a new security model for safe web browsing, or a technical and thought-provoking talk about how concurrency is changing everything we do by a computer science legend, this channel has everything a geek could want. (well, it's 8 videos so far, so maybe not everything.)

[If you don't have time for those videos, maybe the videos on www.TomOnTime.com will help you find more free time.]

A friend of mine who is an old-time Unix/Linux user asked me for suggestions on how to get used to Mac OS X.

The first mistake that Unix users make when they come to OS X is that they try to use X Windows (X11) because it is what they are used to. My general advice: Don't use X windows. Switching between the two modes is more work for your hands. Stick with the non-X11 programs until you get used to them. Soon you'll find that things just "fit together" and you won't miss X11.

Terminal is really good (continued lines copy and paste correctly! resize and the text reformats perfectly!). I only use X windows when I absolutely have to. Oh, and if you do use X11 and find it to be buggy, install the third-party X replacement called XQuartz (sadly you'll have to re-install it after any security or other updates)

Now that I've convinced you to stick with the native apps, here's why:

1. pbcopy <file

Stashes the contents of "file" into your paste buffer.

2. pbpaste >file

Copies the paste buffer to stdout.

3. pbpaste | sed -e 's/foo/bar/g' | pbcopy

Changes all occurances of "foo" to "bar" in the paste buffer.

4. "open" emulates double-clicking on an icon.

   open file.txt

If you had double-clicked on file.txt, it would have bought it up in TextEdit, right? That's what happens with "open file.txt". If you want to force another application, use "-a":

open -a /Applications/Microsoft\ Office\ 2008/Microsoft\ Word.app file.txt

Wonder how to start an ".app" from Terminal? Double click it:

open /Applications/Microsoft\ Office\ 2008/Microsoft\ Word.app

Want to find a directory via "cd"ing around on the Terminal, but once you get there you want to use the mouse?

cd /foo/bar/baz
open .

I use this so much I have an alias in my .bash_profile:

alias here="open ."

Now after "find"ing and searching and poking around, once I get to the right place I can type "here" and be productive with the mouse.

5. Want to use a Unix command on a file you see on the desktop? Drag the icon onto the terminal.

type: od (space) -c (space)

Then drag an icon onto that Terminal. The entire path appears on the command line. If the path has spaces or other funny things the text will be perfectly quoted.

6. Dislike the File Open dialog? Type "/" and it will prompt you to type the path you are seeking. Name completion works in that prompt. Rock on, File Dialog!

7. Word processors, spread sheets, video players and other applications that work with a file put an icon of that file in the title bar. That isn't just to be pretty. The icon is useful. CMD-click on it to see the path to the file. Select an item in that path and that directory is opened on the Desktop.

That icon in the title bar is draggable too! Want to move the file to a different directory? You don't have to poke around looking for the source directory so you can drag it to the destination directory. Just drag the icon from the title bar to the destination directory. The app is aware of the change too. Lastly, drag the icon from the title bar into a Terminal window. It pastes the entire path to the file just like in tip 5.

8. If you want to script the things that Disk Util does, use "hdiutil" and "diskutil". You can script ripping a DVD and burning it onto another one with "hdiutil create" then "diskutil eject" then "hdiutil burn".

9. rsync for Mac OS has an "-E" option that copies all the weird Mac OS file attributes including resource forks. ("rsync -avPE src host:dest")

10. "top" has stupid defaults. I always run "top -o cpu". In fact, put this in your profile:

    alias top='top -o cpu'

11. For more interesting ideas, read the man pages for:

    screencapture mdutil say dscl dot_clean /usr/bin/util pbcopy pbpaste open diskutil hdiutil

Enjoy!

P.S. others have recommended this list: http://superuser.com/questions/52483/terminal-tips-and-tricks-for-mac-os-x

I try not to use this blog to flog my employer's products but I just used the open source "Google Command Line" program and I have to spread the word... this really rocked.

I wanted to upload a bunch of photos to Picasa. I didn't want to sit there clicking on the web interface to upload each one, I didn't want to import them into iPhoto and then use the Picasa plug-in to upload them. I just wanted to get them uploaded.

Google CL to the rescue! It is a program that lets you access many google properties from the command line. It works on Mac, Linux and Windows. After a (rather simple) install process I was ready to give it a try.

Here's the command line that I typed:

$ google picasa create --title "2010-08-09-Hobart-Tasmania-SAGE-AU" ~/Desktop/PHOTOS-AU/*

I was expecting it to ask me for a username and password but I was surprised when it my web browser popped up, asked me to authorize this script to have permission to log in (just like third-party apps that authenticate against Google), and when I was back at the command line I pressed "return" to continue. The upload began and finished a few minutes later.

In addition to picasa, the command can also access blogger, youtube, docs, contacts and calendar.

Last week I wrote about how to get coworkers to adopt new technology so this week I thought I'd write about how to get your manager to do it too.

For example, someone recently told me that he'd done a small deployment on Puppet for automating certain things. While it has helped him, his management has not been convinced to adopt it for other things.

Two bits of advice:

First, "align yourself with your boss's priorities". Get some one-on-one time with your manager and find out what is most important to them and then use Puppet to do just that. They might want the ability to roll out new capacity faster or new features faster. Each of these means doing different things with Puppet. If they want to roll out new capacity faster, make sure that your use of Puppet focuses on that. If they want to roll out new features faster, make sure that adding new things to puppet has been made as easy as possible (a "how to" doc, a "getting started" guide, etc). If stability is their priority, find out what instabilities they are most concerned with and use puppet to fix those problems.

Yes, by using Puppet (or CFEngine, or other Configuration Management tool) you can usually solve all three of those problems at once. However, only talk about the one that is most important. If you talk about benefits that are not on your boss's priority list your point will be muddied. (See this recent post for more info about that.) Yes, those other advantages exist, but if they aren't important to your boss, why bring them up and confuse the issue?

Now that you have focused on what your manager considers important, you are ready for the second bit of advice: Describe things in terms of "undeniable value".

"Let's buy a new server" has no "undeniable value". In your mind you know that the new server would solve a host of problems but explaining it as "let's buy a new server" doesn't make that clear. In fact, most managers would hear this as "let's spend more money that you don't have".

So take a moment (or maybe and hour at the whiteboard with a coworker) and work out the "undeniable value" of what you are trying to do. "I want to be able to add capacity within 4 hours of the new server arriving at the loading doc." That is undeniably valuable. "When a new feature is done, I want to be able to have it on all servers within an hour". That is undeniably valuable. "It takes 4 people to handle our current change request load. I want to be able to do it with 2 people so the other two can focus on new projects." That has a nice ring to it too.

Of course, your boss makes the final decision of what's valuable. Maybe new servers arrive rarely, so the first example isn't valuable to him. Or maybe new features are deployed fast enough in his opinion, so that isn't valuable either. The third example, freeing up 2 people to work on other projects, is most valuable when there are new projects that he/she wants to prioritize.

I believe that managers, fundamentally, have two responsibilities: setting priorities and providing the resources to achieve those priorities. I believe that managers [usually] understand business priorities better than we do and when we state proposals in terms of their value we aide them in their ability to carry out their fundamental responsibilities. It creates a better division of labor and prevents micromanaging.

Comments? Suggestions?

I'm planning on writing a piece about math so I thought I'd survey my readers.

I assume that most of my readers took a lot of math in high school and college. Of all the math you learned, what parts of it do you use today as you do your system administration?

For example, of all the statistics I learned, pretty much all I actually use now is standard deviation. (and I just use it in analogies I make)

What path of your math education do you use today?

If you are teaching a group of people here's a useful technique: "I do, we do, you do".

I do the task once, then the entire class does it together (in lock-step fashion), and then everyone does one on their own.

When I do it, it gives everyone an understanding about how it is supposed to work from beginning to end.

When we all do it together, we have the benefit of knowing what is supposed to happen and fully understand the end point, but we are learning the individual steps and experiencing them in a safe environment since everyone is doing the exact same steps and waiting for everyone to finish step n before moving to step n+1. If someone is having trouble, other classmates can help them (which is educational in itself).

Lastly we do it individually. We know how it is supposed to be done, the training wheels are off, and we learn to do the task independently.

You can use this when teaching a fellow coworker one-on-one. Do the task yourself. Do the task as they do it too, mirroring your actions. Then let them do it on their own.

[I bring this up because I remember all the times that people have tried to each me something without the "I do" step and I don't even know why I'm doing what I'm doing. If they had showed me what we were trying to do in the first place, I would have learned faster.]

You've installed [Puppet, CFEngine, or any new technology] but your co-workers don't "get it". They continue to do things the old way. They resist. You can't figure out why because obviously [new technology] is better.

Three things: 1. Be a success. People want to copy success. 2. Make it extremely easy for people to get started. Document the "getting started" guide. Work through a really easy example from beginning (set up your PATH, etc) to end (testing). Keep it simple so it is clear. Write another document that covers advanced features, the ones you left out of the first doc because you were keeping it simple. 3. Expose good starter projects. You have a list of new features you'd like to add in your head where nobody can see them. Put each idea into a bug database, and mark which ones are easy "starter projects". If you do all the easy projects, there won't be any starter projects for others. Instead, create bugids instead of code. Blaze the trail by writing the major skeleton but leave behind a trail of easy projects for others to pick up.

People don't give good feedback in front of each other. Sit down one-on-one with someone and ask them what's wrong. Deal with their concerns. "Seek to understand before you seek to be understood."

We often don't want to micromanage others or think it is rude to tell them what to do. However, when someone is new at something they want to be told what to do. Imagine if on your first day at work nobody told you what your job was. You would be wondering, "hey? why isn't anyone talking with me? Why are they so unfriendly?!" The truth is that when we are just learning something we need to be told what to do. It is comforting to be told what to do. Once we get the hang of things we don't want to be told what to do, but that could be hours, days, or months into the project.

How do we tell people what to do? We write "getting started" docs, we offer to sit with the person through their first time doing something. We let them do the typing, but tell them what to type.