Using Magic Mouse on Windows 7 with Boot Camp

I’m running Windows 7 on some Mac hardware with Boot Camp. The Magic Mouse didn’t work right out of the box, even though Windows seems to understand the Bluetooth device just fine. I used the following combination of processes to get the Magic Mouse to work:

  1. First, install the mouse with the following steps: Magic Mouse Guide for Windows
  2. Second, get two-finger scrolling to work, with the updated Apple Bluetooth driver. I had a hard time finding this, but here’s a link that’s still active.
  3. Third, enable natural scrolling (because using Lion on a Mac for a year ruined me to normal old-school scrolling). I used an AutoHotkey script.

That’s it. Took a lot more research than it should have. But hey, it works now.

Car health records in a personal event network

Carvoyant is launching a car health record service: They send you an OBD-II device, which you pair via Bluetooth with your Android phone. The app periodically polls the device for diagnostics from your car and uploads them to Carvoyant’s servers. Their website tracks your maintenance history and other statistics, ostensibly so you can take better care of your car and save money.

They take it one step further by sharing your data with service providers. When your car is in need of a repair, Carvoyant automatically sends the data it collected (anonymized) to service providers in your area, who have half an hour to provide a bid for the repairs. You can evaluate those bids and choose where to go for service. (This is not unlike Facebook’s model of collecting your personal information free of charge and then selling it to advertisers.)

I like the idea, but I want more control. It’s good the data gets anonymized before it’s shared, but I also want to decide who gets to see it in the first place. Phil Windley designed a 4th-party anonymous ecommerce system to do just that. Using a personal event network like Phil suggests means I retain control of the data, including the ability to modify or delete it, and I control who has access to it (whether anonymously or not).

The OBD-II hardware itself is inexpensive. It wouldn’t be too hard to copy this system but build it on a “personal cloud” so the user is in control.

Carvoyant calls their product a “two sided platform”, but it’s still just an information silo. No one gets any value out of the data unless they consult the cow.

Designer founders

Don Dodge tweeted today:

Most important hire in a startup? Designer. Better if one founder is a designer.

The Design Fund has an excellent infographic about successful startups whose founders have been designers. This is the reason having a designer as a cofounder is so important:

Now, more than ever, we face complex problems that designer founders with professional craft have the opportunity to solve by facilitating design behaviors with the rest of their team, thus inspiring everyone to have creative confidence and apply design thinking collaboratively. The whole company should practice empathy, not just designers. No longer can design just be an outsourced add on, limited to occasionally putting “lipstick on a pig.” Tech moves so fast that it’s a continuous process of iteration for designers to prioritize solving the right strategic problems, contexts and use cases for their company to prosper.

It’s about culture.

I’m an engineer; design is not my forte. But I understand the critical importance of the user experience to the success of a product. I’m in the middle of reading two design books right now, and I hope to make the study of good design a long-term pursuit, even if I never become an outright designer.

The trouble is, software engineers are still the ones who build systems. We need more technical people with design sense, just as we need design people with technical breadth.

The BYU Computer Science department has a user interface course, but it’s a dismal excuse for teaching design. I’m pleased that the Information Technology major has a User Experience & Human Computer Interaction emphasis. They are on the right track.

The CS department trains people to be great coders, but it’s not giving them the skills they need to be successful as entrepreneurs (where design sense is critical) or in companies where the culture of design is central. Self-study is always an option (one of which I’ll avail myself), but I want to see software engineering curricula teach design as an integral part of the engineering discipline.

Teaching kids to program

Benjamin Pollack wrote yesterday about “Learning coding from boredom.” I love his ideas about teaching programming:

Programmers like to program because they can do cool things, or because they can solve problems, or both. It’s both creative and it’s practical. If the goal of a high school course is to get people interested in programming, then the course must build around these two pillars.

I first learned to program in BASIC on the VTech PreComputer Prestige. The things I wrote were simple Fahrenheit-to-Celsius conversions, guess-the-number-I’m-thinking programs, but they were really cool in the mind of an elementary school kid. Once my dad got me a copy of Visual Basic 2 that would run on our real Packard Bell Navigator Windows 3.11 computer, I was in heaven.

My junior high had two great programming classes. We didn’t do much theory, but Mr. Ferrin taught us a good balance of programming practice and Visual Basic GUIs. The high school had one class in the business department that tacked on VB6 for a measly two or three weeks, but like Benjamin, I knew nobody who actually liked programming after taking that class.

A few of my friends had great computer science teachers in high school, but most of them gained their love of programming by solving their own problems outside a formal programming course. Secondary education is ripe for reform in computer science curricula.

I’m lucky right now to be working with Bayside High School in Queens, who’s developing a program for CS students that looks a lot like the above, with introductory classes focusing on tangible results students can play with immediately (web applications, little GUIs, and dumpster-diving through massive datasets) rather than wading knee-deep into theory right from the get-go. But there are many, many high schools out there who have nothing remotely like this, who teach programming the same way they teach math. If the high school in your area’s like that, volunteer to teach something more inspiring. The students will love it, and we’ll get more impassioned developers as a result.

I might just do that.

Implementing the driver’s personal event network with Kynetx

Lab 3 in CS 462 involves creating a personal event network for drivers in the classic flower delivery system. I have recommended that KRL is a good language to use to implement this personal event network, rather than writing everything in a traditional language. However, there are some pieces of the system that don’t quite make sense since KRL doesn’t exactly have a front-end.

Here’s a diagram of the driver registration process:

The orange arrows indicate that some important data is being exchanged; the data itself is shown in bold type.

In short, the driver’s personal event network needs at least the following information in it’s data store from this interaction:

  • Driver’s name
  • Driver’s phone number
  • Information about each flower shop:
    • Flower shop ESL
    • Flower shop latitude and longitude

If you write this all as a traditional website, the UI for this is obvious. But KRL doesn’t provide as obvious a way to create front-ends. Here’s how I would do it.

We first presume that the driver has created his personal event network with Kynetx and has installed the driver app. It’s then a simple matter to create another KRL app that the driver can install to interact with the data store. This app will have display its UI when the user has installed the app and navigates to exampley.com. Here are the various pieces of that app:

Driver registration

We implement an interface that lets the driver submit his name and phone number. It could look like this:

When the driver clicks Submit, the data is sent back to the Kynetx servers and stored in entity variables. (The code for this and all other examples will be given later.)

Flower shop information

The driver needs to maintain information about the flower shops for whom he delivers. We provide an interface like this for submitting that information:

Again, when the driver clicks Submit, the information is sent back to the Kynetx servers, where it can be stored in an array of flower shops. We’ll use entity variables and JSON-encode the information.

The driver may also want to list all the flower shops. To do that, we simply loop over the array containing the flower shops and display the details:

The code

The code for this is relatively straightforward. I display a series of notify() boxes and use watch actions to raise events when the user clicks buttons. Here’s what it looks like:

Installing the app

The “driver” can install the app into his personal event network at this link: Driver Registration Helper. To use the app, go to exampley.com once the app is installed.

Using the data from this app
You will need to import my ruleset as a module in order to get the data out. Put this line in your meta block:

use module a163x154 alias driver_data

You may choose the alias, but make sure you prefix all function calls with that alias.

The modules provides a few functions to give you access to the data collected from the driver:

get_driver_name();
get_driver_phone();
get_flower_shops();

The first two of those functions return strings. The second returns an array of string-encoded JSON objects (called “hashes” in KRL parlance) that look like this:

{
  "name": "The Flower Shoppe",
  "esl": "http://consumer.eventedapi.org/receive/fizzbuzz",
  "lat": "-41.1",
  "lng": "111.1"
}

Use decode() and pick() to get the information out of those hashes.

A function call could look like this:

pre {
  driver_name = driver_data:get_driver_name();
}

Rethinking the Office Hours app

It’s Winter Semester at BYU, and I’m again the TA for Phil Windley’s Distributed System Design class (CS 462). This time, we roped Reed into being a TA as well. We really liked the idea of the Office Hours app from last year, but we have a few different requirements this year:

  • There are two of us now, instead of just one, so the Google Calendar holding the hours got more complicated.
  • Since Reed and I both work in a research lab, we want to be available to the students without having to sit down in the TA cubicles all day. We created “on-call” office hours, during which we are available to help students but we won’t be physically present until someone actually shows up.

Those two things increased the complexity of the problem fourfold. We used the same basic model as before (texting via Twilio) but chose a more distributed design:

Here is how this works in terms of events:

  1. The SMS is received by Twilio, raising a twilio:sms event to the dispatch ruleset.
  2. The dispatch ruleset checks the Google Calendar to see if anyone is on the schedule. If so, it raises a schedule_inquiry event to the rulesets handling hours for each TA. If not, it raises an absent event.
  3. The dispatch ruleset responds to the absent event by sending a text to the student that no TAs are on the schedule now. It also includes the date and time of the next office hours.
  4. The individual TA rulesets respond to the schedule_inquiry event by checking the calendar to see whether that TA is on the schedule right now. There are two possibilities: in office and on call. The former raises a present event; the latter raises an on_call_request event. The default behavior is to respond this way:
    • present: Text the student that {Steve|Reed} should be in the cubicle already.
    • on_call_request: Text {Steve|Reed} to get downstairs and reply to the student that he’s on his way.

Separating the TA rulesets allows me and Reed to have the application behave differently for each of us. I prefer texting (or XMPP if I ever figure out a good way to do it), but Reed would prefer email, since his AT&T iPhone gets bad reception in our lab. All I have to do is add another rule to respond to the on_call_request event and make it do whatever I want.

Here is what my version of the TA ruleset looks like:

To read your speech or to speak

Seth Godin wrote a great post today: “Your voice will give you away“. If you give a presentation by reading a speech you wrote beforehand, your voice betrays it. If you’re speaking naturally, your listeners will notice.

The BYU devotional this week was an excellent example of this. President and Sister Samuelson gave a joint speech. They scripted everything and decided who would talk when. But the occasional awkward transition and canned, corny joke betrayed a lack of rehearsal.

At the very end of the speech, Sister Samuelson read her testimony from the script and concluded. Then President Samuelson spoke again and bore his testimony. This time, he had a different tone. He stammered a bit. His words were softer. It was obvious to me that he was speaking from his heart this time, not reading the script. His testimony at the very end of that speech was the most powerful part of the entire hour, because I knew it was real.

The stilted tone made me tune out much of the speech. But when President Samuelson spoke from his heart, I was compelled to listen, and I relished it.


When I give presentations or speeches, I usually write them out beforehand and rehearse them. But I write with the same tone I use when I speak. I use the same expressions; I try to use big words only if I might actually say them. I make it as conversational as the setting permits. Once I have it written out, I practice it again and again until I can speak it without having to read my script.

That method gives a very genuine feel to my talks. The audience thinks I’m just talking, not reading. I work hard to get that tone. Seth is absolutely right.

What the Daily Universe forgot to explain

UPDATE (January 2012): According to the Daily Universe, Brandon Beebe has decided to discontinue Schedule Snatcher at BYU, although he’ll keep rolling it out to other universities.

BYU announced this week a few changes to the registration system that effectively crush an independent service called Schedule Snatcher. The article attacks this service rather pointedly, even if it doesn’t mention it by name.

What’s new
The new system makes two major changes:

  1. When a class is full, you enter a wait list and the system will automatically add you to the class when a spot opens up (first come, first served).
  2. Adding a class now requires you to fill in a reCAPTCHA.

This strikes down both of Schedule Snatcher’s salient features:

  1. Registering automatically for a class once a spot opens was the whole point of Schedule Snatcher, so this renders the service obsolete.
  2. Schedule Snatcher (or any other service) can’t even make requests on your behalf unless a human is there to handle the reCAPTCHA.

    UPDATE: Schedule Snatcher has already implemented a system to handle this. Apparently the registration system only prompts you for a reCAPTCHA once (consistent with my own experience yesterday).

Developer games
When you write to an application that doesn’t provide an API, you always run this risk. (And even when it does provide an API, you still run the risk. Twitter is a shining example of ruthlessly quashing developers. They’ve made developing Twitter clients a game of acquisition-or-obsolescence.)

This same thing happened to me with the BYU Bookstore’s “My Book List” application. I wrote a browser app that extracted the ISBN numbers from the page and looked up textbook prices on Amazon. It then displayed them so you could easily compare the cost to buy the book on campus or online. The Bookstore implemented this feature themselves directly into “My Book List”, rendering my app unnecessary.

I’m glad BYU is implementing these features, both the inline price comparisons and the built-in wait list. But it makes students more wary of developing tools on top of BYU’s systems that would make their lives easier.

Ambiguous claims

Jeff Bunker claims in the Daily Universe article that the new wait list feature “will make sure the long-existing practice of students holding and registering spots for other students will no longer be effective” (as if it were a rebel uprising). The reporter’s unfortunately ambiguous writing fails to explain how that would happen, making Bunker’s claim seem unrelated. Here’s how it works:

  1. You go to sign up for a class. It’s full, so you add yourself to the wait list.
  2. Someone else drops the class.
  3. The first person in “line” on the wait list automatically gets added to the class.
  4. Hopefully, you eventually get added to the class if enough people drop and move you up the wait list.

The reason this system can prevent upperclassmen from saving spots for their friends is that the person dropping the class has no control over who gets the spot he just vacated. It goes to the highest bidder.

Playing catch-up

All the same, it’s nice to see this “significant service,” as Bunker puts it, being provided in the platform itself, even if it’s merely a response to someone else’s innovation.

Very short stories

I wrote a couple 140-character stories for one of the final assignments in CS 404 and found it quite a satisfying experience.

The first details one of the strange aspects of meeting in person for the first time someone you only “know” via Twitter:

He sat across the room, his face familiar, his voice strange. Despite resembling his avatar, this man could speak more than 140 characters.

The second deals with a theme I’ve pondered for quite a while—living life through a screen.

She danced gracefully while I watched through a 3.5″ piece of glass. It’s all in 1080p video, but I missed the higher-def live performance.

Real life

I spend a lot of time online every day, partly by choice and partly by profession. But being online never replaces “real life.” Last week, I disconnected for a few days to spend time with my family and friends. We relaxed and enjoyed each other’s company. We strengthened friendships, laughed, and played. Those “real life” relationships will last. Love, friendship, a hug, and a pat on the back are things I don’t find online. The concept of “life” doesn’t change by sticking “real” in front of it. Life is lived in the world where I can see and hear and interact with the people I love. No game or chatroom or network will ever replace that.