Robert Scoble’s “Google, the freaky line and why Moto X is a game-changer” describes the significance of its always-on voice recognition. Under the heading, “the joy of context”:
Moto X is just one in a string of products and services that will bring radical new functionality to users. Examples? Google Now, Google Glass, and the new Moto X phone that keeps the microphone open full-time. The Xbox One, coming this winter, will have a 3D sensor on it so sensitive it can see how fast your heart is beating just by watching your skin.
These new contextual, sensor-based features are game changers and I’m hearing Google has a raft of other product announcements lined up that will turn on even more freaky features. Why? Because the more Google can get you to communicate with your phone, the more context it can slurp up.
The more sensors it can turn on, or put on you, the more it can learn about your intent and your context. Today your phone doesn’t really know that you’re walking, running, skiing, shopping, driving, or biking, but in the future, Google will know that and will be able to build wild new kinds of systems that can serve you when doing each of those things.
Naturally people have a variety of reactions for different reasons. You may find it yawningly predictable, or alarmingly freaky, or something in between. You might not mind Google slurping your data because you gave consent, but be creeped out by NSA contractors wrapping their lips around it uninvited.
But at bottom what’s the motivation behind this push for “context” and “intent”?
In my experience, the way to become a better programmer is to:
- write lots of code
- skim lots of reading material, and
- defer answers until you have questions.
To learn why you should skim this post, please read it carefully.
Travis CI is a continuous integration service for open source projects that has nice integration with GitHub.
Whenever you push a commit to GitHub, a build/test can launch. Notification of the result comes via a variety of methods. Also there’s a “badge” to show the build status, which you can link to in your
Jay McCarthy posted about a macro to do a C-style
case, where clauses fall through to the next unless you use a
break. His post is a great look at Racket macrology. Jay’s implementation is elegant. If you haven’t yet, go read it.
You’ve committed felonies.
Perhaps as many as three per day.
No one is innocent:
If someone tracked you for a year are you confident that they would find no evidence of a crime? Remember, under the common law, mens rea, criminal intent, was a standard requirement for criminal prosecution but today that is typically no longer the case especially under federal criminal law.
Faced with the evidence of an non-intentional crime, most prosecutors, of course, would use their discretion and not threaten imprisonment. Evidence and discretion, however, are precisely the point. Today, no one is innocent and thus our freedom is maintained only by the high cost of evidence and the prosecutor’s discretion.
I’m writing this blog post on a Chromebook Pixel. In Emacs. On Ubuntu, as a chroot, thanks to crouton.
Why do I have a Chromebook Pixel? Google gave one to every Google I/O 2013 attendee.1
Although I was happy to get such a cool new gadget, I honestly wasn’t sure what I’d do with the thing. I really like my MacBook Pro Retina and wasn’t looking for an alternative. Also, although I love web apps and 45% of my day is in the web browser, another 45% is in Emacs using Racket — what about that?
Although I prefer Racket, there are a few idioms from Clojure I like. I’m particularly infatuated with the threading macros,
I was surprised how little documentation I could find for these. So although I’m writing this for Racketeers, it’s possible a few Clojure folks might find it interesting, too.
Recently I wrote about my my Google Reader successor, using rss2email to push feeds to Gmail.
In the month since, I was still running it on my laptop. To make it work best, it should run on a dedicated server. That way, it would push emails even if I’m away from my laptop, and I could read them on e.g. my phone. But before committing to setting this up on Amazon EC2, I wanted to be sure I liked the approach.
Do the following apply to you?
Maybe you want to contribute something to Racket: You’d like to improve the documentation, or you’d like to add a small feature.
Maybe you’re comfortable with Git, but haven’t made a pull request before.
Maybe you’ve made a one-off pull request, but haven’t tried to contribute to the same project over time and stay in sync with the upstream project.
If so, you may find my guide helpful. I was hopelessly confused about how to handle the branches and merging. After I figured it out, I wrote this down in a Gist as a note to my future self. Today I figured I’d dust it off and make it into a blog post.
Recently I’ve shared some new libraries using the new package manager, but not uploaded them to Planet.
What about my existing Planet libraries? Yesterday Danny Yoo pointed out a bug in the Dynamo module of my Amazon AWS library on Planet.
The bug wasn’t present in my GitHub repo—I’d neglected to go through the steps of making a new version and uploading to Planet.
By contrast, with the new package manger, it would have been automatically up-to-date.