Search Results for: speed

Dial tone moments

Posted November 11, 2014 in Personal

Googlers love to discuss and debate things within the company. As a rule of thumb, the internal discussion is civil and respectful, but can be passionate. I may take a few of my favorite internal posts that I wrote, tweak them a bit, and publish them here just so I can refer to them more easily down the road.

Here’s something I wrote in 2012:

Recently Google has been shooting for more “magical” moments, and that’s a noble goal. But I think our first priority has to be “dial tone” moments. On a basic level, that can be as simple as uptime and reliability–if Google Voice or Google Music or some other product is too flaky, people won’t use it.

But we should also strive for dial tone moments in terms of consistency or utility or latency. Here’s a simple example. Saturday night in Mountain View I wanted to check how hot it would get on Sunday. I got three different answers from Google. Google Now claimed the high would be 88 degrees. Doing a mobile search for [weather mountain view] predicted a high of 82 degrees. And the News & Weather widget predicted a high of 81. I got those results all within a minute of each other.

If we can’t tell the user whether it’s going to be closer to 80 or closer to 90 tomorrow, how can we expect users to trust us for magic moments?

I think a lot of Google’s reputation or “brand” comes from being a useful, functional tool. Magical moments are fine (great even), but overall the most important thing Google needs is to nail “dial tone” moments, where people just assume that Google will always be up, always be fast, and always get them exactly what they need. If we can do better, great, but we have to nail those dial tone moments.

At Charlie’s, the main cafe at Google’s Mountain View headquarters, there’s a door that uses an electric eye to automatically open as you walk up. When the automatic door is working, it’s a smoother experience than walking 10-15 extra feet and pulling open the regular doors yourself.

Unfortunately, the automatic door seems to be broken about 5-10% of the time. Either someone forgets to unlock it when the cafe opens up, or it’s broken, or it takes too long to open. Then you’re left standing and feeling silly waiting for a door that might or might not open. I noticed that over time, lots of people stopped using that door and went straight to the regular doors. It took 3-4 extra seconds to walk over to the regular doors, but they always consistently worked. The automatic door was optimizing for magical moments when it needed to optimize for dial tone moments. The automatic door had to walk before it could run.

What does this mean for you or your company? Look for dial tone moments or rough edges where you could improve. I had one colleague at Google who I swear could walk from his car to his office and find six different things that needed to be improved. There’s stuff all around you that could be much better if you just lower your annoyance threshold enough to notice it.

Just as an example, I’ll pick on tivo.com because I love TiVo. One annoyance: when you tell tivo.com to keep you signed in for 45 days, and then come back a week later, you have to sign in again. Another annoyance: you can only search for shows happening within the next two weeks or so.

I would consider the first annoyance to be a dial tone issue: it shouldn’t be hard to stay signed in to a website. That’s a very fixable issue. In fact, when I come to tivo.com, the message at the top knows my name even while another part of the page is telling me that I have to sign in:

Tivo sign in required

The second annoyance–only searching two weeks out–might easily be a multi-month project or even impossible, depending on how and where TiVo gets their data from. But you’d get almost as much goodwill from fixing the easy, dial tone issue as you would from fixing the really hard problem.

If you’re not using (“dogfooding”) your product every day and looking daily for annoyances, snags, or rough spots, you’re missing out. If you run a website, pay attention to the uptime and speed of your site. Monitor your vital metrics and trigger an alert if something goes seriously out of whack. Your product should probably be reliable before you shoot for flashiness.

30 day challenge for June: treadmill desk!

Posted June 1, 2014 in 30 days

Okay, it’s been a while since I’ve blogged. Let me tell you about the 30 day challenges I’ve been doing and what I learned:

– March 2014: I went back to doing no external email, and I learned this one weird, simple trick that helped. In previous “no email” challenges, I relied on sheer force of will not to reply to email. That didn’t work so well. In March, I tried something different: I used Gmail filters to take outside email, add the label “march2014”, and then made the outside emails skip my inbox.

It turns out that getting those emails out of my default view was critical. A while ago when I was losing some weight, I noticed that small nudges could make things easier. Instead of leaving chips or snacks lying in plain sight, I tucked them away where I wouldn’t see them. The principle of “out of sight, out of mind” can really work for you! Even better was to skip buying certain snacks. In theory, I could get in the car and drive somewhere if I really wanted a treat, but in practice I rarely did.

Archiving email out of your inbox has the same effect. Now if I’m done with my internal work-related email, I might click through to check out the outside email at the end of the day, but it doesn’t sit right in front of me begging for a reply like it did before. I’ve kept up this practice after March.

– April 2014: This is going to sound crazy, but I wanted to figure out how to make quirky eyebrow expressions (watch what Emilia Clarke can do with her eyebrows–it’s crazy!). Unfortunately, I only practiced in front of a mirror once or twice, so April was a total crash and burn. But so what? I still tried a couple times, and not every 30 day challenge has to be deep or meaningful. Fun is fine! Maybe I’ll circle back around to this one again down the road.

– May 2014: My challenge for May was to get eight hours of sleep a night. I only hit that goal about half the nights. But I became much more aware of when I was trading off sleep for a meaningful activity, like getting up at 4 a.m. to drive to Vallejo for a triathlon. Or more often, I realized that I was trading off sleep to answer emails or surf the web. As a bonus 30 day challenge, I biked into work almost every day in May.

Which brings me to my 30 day challenge for June! In previous months, it would take me about three hours a day to battle email to a standstill, and I’ve also noticed that I end up surfing the web for at least a couple hours a day. All told, I spend a lot of time sitting in front of a computer, which might not be the best for my health.

For June 2014, I’m going to try to convert some of that computer time to at least an hour a day with a treadmill desk. I have a treadmill at home and I slapped a couple plastic risers and a piece of plywood across it–instant treadmill desk! So the incremental cost was only like $20. I set the treadmill speed to one mile an hour, which is fast enough that my Fitbit can detect I’m walking, but slow enough that I can still think and work. I’ll let you know how it goes!

Is there any new habit or experiment you’d like to try for the next 30 days?

What would you like to see from Webmaster Tools in 2014?

Posted November 21, 2013 in Google/SEO, Uncategorized

A few years ago, I asked on my blog what people would like from Google’s free webmaster tools. It’s pretty cool to re-read that post now, because we’ve delivered on a lot of peoples’ requests.

At this point, our webmaster console will alert you to manual webspam actions that will directly affect your site. We’ve recently rolled out better visibility on website security issues, including radically improved resources for hacked site help. We’ve also improved the backlinks that we show to publishers and site owners. Along the way, we’ve also created a website that explains how search works, and Google has done dozens of “office hours” hangouts for websites. And we’re just about to hit 15 million views on ~500 different webmaster videos.

So here’s my question: what would you like to see from Webmaster Tools (or the larger team) in 2014? I’ll throw out a few ideas below, but please leave suggestions in the comments. Bear in mind that I’m not promising we’ll do any of these–this is just to get your mental juices going.

Some things that I could imagine people wanting:

  • Make it easier/faster to claim authorship or do authorship markup.
  • Improved reporting of spam, bugs, errors, or issues. Maybe people who do very good spam reports could be “deputized” so their future spam reports would be fast-tracked. Or perhaps a karma, cred, or peer-based system could bubble up the most important issues, bad search results, etc.
  • Option to download the web pages that Google has seen from your site, in case a catastrophe like a hard drive failure or a virus takes down your entire website.
  • Checklists or help for new businesses that are just starting out.
  • Periodic reports with advice on improving areas like mobile or page speed.
  • Send Google “fat pings” of content before publishing it on the web, to make it easier for Google to tell where content appeared first on the web.
  • Better tools for detecting or reporting duplicate content or scrapers.
  • Show pages that don’t validate.
  • Show the source pages that link to your 404 pages, so you can contact other sites and ask if they want to fix their broken links.
  • Or almost as nice: tell the pages on your website that lead to 404s or broken links, so that site owners can fix their own broken links.
  • Better or faster bulk url removal (maybe pages that match a specific phrase?).
  • Refreshing the existing data in Webmaster Tools faster or better.
  • Improve robots.txt checker to handle even longer files.
  • Ways for site owners to tell us more about their site: anything from country-level data to language to authorship to what content management system (CMS) you use on different parts of the site. That might help Google improve how it crawls different parts of a domain.

To be clear, this is just some personal brainstorming–I’m not saying that the Webmaster Tools team will work on any of these. What I’d really like to hear is what you would like to see in 2014, either in Webmaster Tools or from the larger team that works with webmasters and site owners.

The heart of a computer is now the network connection

Posted June 30, 2013 in Gadgets/Hack

Back in the 90s, the heart of a computer was the CPU. The faster the CPU, the better the computer was–you could do more, and the speed of the CPU directly affected your productivity. People upgraded their computers or bought new ones whenever they could to take advantage of faster CPU speeds.

I remember the point when computers got “fast enough” though. Around 1997 or 1998, computers started hitting 166 MHz or 200 MHz and you could feel the returns diminishing. At some point, the heart of a computer switched from being a CPU to the hard drive. What mattered wasn’t the speed of your Intel or AMD chip, but the data that you had stored on your computer.

The era of the hard drive lasted for a decade or so. Now I think we’re shifting away from the hard drive to the network connection. Or at least the heart of a computer has shifted for me. In 2006 I contemplated a future where “documents sat in a magic Writely [note: now Google Docs] cloud where I could get to them from anywhere.” Sure enough, I keep all my important files in Google Docs now. At this point, if I have a file that sits only on a local hard drive, I get really nervous. I’ve had local hard drives fail. By 2008, I was spending 98% of my time in a web browser.

Don’t get me wrong. Local hard drives are great for caching things. Plus sometimes you want to run apps locally. But for most people, the heart of a computer will soon be its network connection. Ask yourself: could you get by with a minimal hard drive? Sure. Plenty of people store their files on Dropbox, Box, Google Drive, iCloud, or SkyDrive. Or they back up their data with CrashPlan, SpiderOak, Carbonite, or Mozy. But would you want a computer that couldn’t browse the web, do email, or watch YouTube videos? Not likely.

Playing with a USB Missile Launcher

Posted May 12, 2013 in Fun, Gadgets/Hack

This is the last half-finished “hairball” blog post about USB devices on Linux. I actually did manage to get a working program that controlled a USB foam missile launcher. Unfortunately, I didn’t document all the steps, so this blog post just sort of stops at some point.

I got a USB Missile Launcher for Christmas. The manufacturer, Dream Cheeky, provides software–but only for Windows XP. And I thought to myself, “wouldn’t it be fun to practice some USB reverse engineering skills?” Because another Christmas present was a USB protocol analyzer from Total Phase. I should note that plenty of other people have apparently already written drivers/software for USB missile launcher toys, but I wanted to poke around myself.

Total Phase makes a high-speed USB 2.0 protocol analyzer for $1200, or a regular-speed USB protocol analyzer for $400. Here’s a trick someone mentioned: if you get the cheaper protocol analyzer and need to work with a high-speed USB device, you may be able to plug the high-speed device into a low-speed USB hub to slow the device down.

I decided to start with ladyada’s excellent guide to hacking a Kinect by reverse engineering USB packets. So here’s what I did.

Step 1. Make sure the device works. It would suck to attempt to reverse engineer a broken device. I keep a Windows XP computer lying around, so I downloaded the software for it, installed the program, and plugged in the USB rocket launcher. After the install, XP wanted to restart, so I restarted the XP computer (unplugging my USB rocket launcher after the computer was off), then started the rocket launcher software back up, then plugged in the USB device. Sure enough, everything worked fine. The controls are: pan left/right, tilt up/down, and fire. Tip: the rocket launcher uses bursts of air, so don’t jam the foam rockets down hard on the launcher.

Step 2. Probe the device. I plugged the USB rocket launcher into a Linux machine running Ubuntu 10.04 (Lucid Lynx). I ran the command sudo lsusb -vv and the relevant info from the list of USB devices on my system was this:

Bus 002 Device 045: ID 0a81:0701 Chesen Electronics Corp. USB Missile Launcher
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0a81 Chesen Electronics Corp.
  idProduct          0x0701 USB Missile Launcher
  bcdDevice            0.01
  iManufacturer           1 Dream Link
  iProduct                2 USB Missile Launcher v1.0
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              20
Device Status:     0x0000
  (Bus Powered)

Note that my Vendor ID = 0x0a81 and my Product ID = 0x0701. Also note that bNumEndpoints = 1. An endpoint is a channel for USB data communication. Then we get the Endpoint info:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              20

According to ladyada’s write-up, the “IN” means that data goes IN to the computer from the device, and the “Interrupt” transfer type is good for sending large amounts of small data quickly (e.g. a USB mouse).

Step 3. Prepare your Linux system to talk to the device. First, let’s review ladyada’s steps, which is for Windows. She installs libusb-win32 and then runs a program called inf-wizard to make a driver shell. Then plugging the device into Windows will attach the LibUSB-win32 device driver. Next, she installed Python and PyUSB.

I wanted to stick with Linux. I didn’t need libusb-win32 or inf-wizard.exe, and I already had Python installed. So my next step was to download PyUSB, extract the zip into a directory, change into that directory, then run sudo python setup.py install in that directory to install PyUSB. Since you’re installing PyUSB system-wide, you do need to run that command with “sudo” to run it as root.

Step 4. Write a short program on your Linux machine to talk to the device. I made a file missile-launcher.py and executable access with “chmod ugo+rx missile-launcher.py” next. Here’s the short program I ended up with:

#!/usr/bin/python

import usb.core
import usb.util
import sys
 
# find our device
dev = usb.core.find(idVendor=0x0a81, idProduct=0x0701)
 
# was it found?
if dev is None:
    raise ValueError('Device not found')

# Linux kernel sets up a device driver for USB device, which you have
# to detach. Otherwise trying to interact with the device gives a
# 'Resource Busy' error.
try:
  dev.detach_kernel_driver(0)
except Exception, e:
  pass # already unregistered
 
# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()
 
print "all done"

Note that my “idVendor=0x0a81, idProduct=0x0701” parameters use the values I found from lsusb -vv. If you compare against ladyada’s short program you’ll notice one major difference. My code has these lines:

# Linux kernel sets up a device driver for USB device, which you have
# to detach. Otherwise trying to interact with the device gives a
# 'Resource Busy' error.
try:
  dev.detach_kernel_driver(0)
except Exception, e:
  pass # already unregistered

Ladyada’s PyUSB program for Windows didn’t have anything like that. But when I ran the program under Linux, I got the error message “usb.core.USBError: Resource busy”. It turns out that the Linux kernel tries to use a default kernel driver, and that prevents my program from talking to the device. Detaching the kernel driver lets me talk to the device just fine. I picked up this tip Ken Shirriff’s post about a USB panic button with Linux and Python. In theory you could also unbind the USB device from a command-line, but I prefer to do it right in my PyUSB program directly.

Note that you will need to run the python program as root, e.g. “sudo ./missile-launcher.py” or else you’ll get a warning message like “usb.core.USBError: Access denied (insufficient permissions)”.

At this point, you have a small working program that opens up a connection to the USB rocket launcher. If the USB rocket launcher isn’t plugged in, you’ll get a “Device not found” error, and if the USB device is plugged in, you’ll get an “all done” message and the program exits gracefully.

Step 5: Try to read from the USB device. In ladyada’s guide, she tried sending 0b11000000 = 0xC0 (“Read Vendor data from Device”) to a Kinect. I got no response from that, but I did get a response sending 0b10000000. That corresponds to sending:
– a ‘1’ to read from the device
– a message type of ’00’ = standard. Ladyada got a response sending to ’10’ = vendor
– ‘000’ (reserved bits, so always 0)
– ’00’ to say the recipient of the message is the device.
Then sending a request of 0 got back a result of two zero bytes:

bRequest  0
array('B', [0, 0])

Interestingly, running the same program again would get a “usb.core.USBError: Unknown error” response. At that point, I would unplug the USB device and then plug it back in to reset it. I didn’t get any other responses from trying to send message types of class or vendor (as opposed to standard), nor did I get any responses from try to send messages to the interface or endpoint (as opposed to the device). See ladyada’s guide for more details about fuzzing the device and what all the various bit fields mean.

Step 6: Set up the Linux computer to use the Total Phase Beagle. The CD worked nicely with HTML documentation on it. First, you copy some udev rules so that the device is writable by anyone when the Beagle is plugged in:


cd /media/Total Phase/drivers/linux/
sudo cp 99-totalphase.rules /etc/udev/rules.d/
sudo chmod 644 /etc/udev/rules.d/99-totalphase.rules

If you’ve already plugged in the Beagle, you’ll need to unplug it and plug it back in for these rules to fire. Next, you’ll need the Data Center software. You can get it off the CD, but I’d recommend downloading the latest software and user’s manual from the website instead. My CD had software version 4.20 for example and the website was up to 5.01. Extract the software zip file (either from online or the CD). Then follow the directions in the online manual (or user manual PDF). The directions according to the manual are

  1. Install the USB drivers and Data Center software. Copying the udev rules is enough for USB drivers on Linux. Unpacking the zip is all you need for the Data Center software, because the executable is self-contained.
  2. Plug the Beagle analyzer into the analysis machine. This was my Linux machine.
  3. Plug the Beagle analyzer into the bus to be analyzed. In this case, this was my XP computer. Don’t plug the USB missile launcher in yet though.
  4. Start the Data Center software. Run the program “Data Center” in the directory you extracted from the .zip file. Follow the rest of the instruction in the Quick Start section.
« Previous Page
Next Page »
css.php