Category Archives: Uncategorized

What. The. Fuck.

Google Reader is shutting down?

I consider myself somewhat of a Google Reader power user. I have over 1000 feeds in my Reader. Over the years, Google Reader has become the primary way that I access the Web. I spend several hours on Reader every week. I use Reader on my smartphone via Newsrob and Goodnews. I know I’m not the only one. How could they shut this product down?

Running OpenVPN on TomatoUSB

Some quick technical notes on setting up OpenVPN in TomatoUSB and using an Ubuntu (12.10) client:
– Use the more laborious TLS auth (requiring certificates and such) instead of static key. Static key sounds like it should be easier. But at least with my Ubuntu client, TLS has the significant ease-of-use advantage in pushing the proper network config to the client; whereas static key left me disconnected.
– I used the OpenVPN for network manager package on the client.
– I had to use TCP (configured in both the server and client).
– I had to set the client’s HMAC authentication to SHA-1. Note that the server has “Extra HMAC auth” set to Disabled.

OpenVPN on TomatoUSB makes for a great personal VPN solution when you’re at a coffee shop, etc.

Emotional Politics

A theory on why politics today is so polarized:  Polarization is how the political parties have learned to motivate people.  This is crucial to countering apathy.  And because campaigns can be won simply by increasing turnout, they’ve learned to emphasize the differences.  As a result, a lot more people care, and care more deeply, and are therefore motivated to vote.

I haven’t heard this theory elsewhere, it would be interesting to look at data and test it.

pronto – little scripts with Web interfaces

I’ve long wanted to be able to write little scripts that are as easy to write as shell scripts but have Web interfaces. Part of the inspiration comes from GitHub’s Hubot, which has an IRC bot interface. I finally got around to hacking together the beginnings of a tool that accomplishes this. It uses Scala, Play Framework 2.0, WebSockets, and especially Akka dataflow concurrency. With it, you can write interactive scripts like this in your controller and run them in a page:

  def ws2 = ProntoWebSocket { implicit context =>
    // Set up two "windows", "right" and "left"
    print(div('class -> "container") { row {
      span('id -> "left", 'class -> "span4 box", 'style -> "height: 200px")() +
      span('id -> "right", 'class -> "span6 box", 'style -> "height: 200px; overflow: auto")()
    } })

    val form = Form(tuple("name" -> text, "age" -> number))
    
    println("right", "here are some instructions")
    val (name, age) = promptTo("left", form) { form =>
        prontoform() {
          inputText(form("name")) + inputText(form("age"), '_showConstraints -> false) +
          inputSubmit('value -> "Submit Yo", 'class -> "btn")
        }
    }(context)()
    
    println("right", Html("<b>we</b> got name = ") + htmlescape(name) + Html(" and age = " + age))
    println("right", "to continue click the button:")
    println("right", prontobutton() { Html("Hit Me!") })
   
    // Wait for the button to be clicked
    readClick()(context)()
    
    println("right", "Thanks for hitting the button")
  }

Notice you can prompt for input and react to that input in an imperative style, yet the script runs in a non-blocking fashion (by virtue of using Akka dataflow, which in turn uses Scala delimited continuations). You can see more documentation and examples on the github. What’s committed now is an early release to demonstrate the idea. Potential use cases include: internal tools, devops tasks, bots, etc. A lot more could be done to flesh out the idea and make scripts even easier to write.

I like the idea of having a single Web framework (i.e. Play) that can flexibly span multiple paradigms. You can employ different styles suited to the task at hand, without having to switch frameworks (or languages) to do it. Play already supports both full MVC (comparable to RoR or Spring MVC), purely REST-style controllers (like Sinatra or JAX-RS), as well as a reactive style of programming (a la node.js) using iteratees. This module shows the seeds of a fourth style, similar to a continuations-based framework like Seaside. This flexibility of styles I think really demonstrates the completeness and elegance of the Play framework. Like the Scala language itself, Play can be a “scalable” framework for developing Web applications in both the small and the large.

WebSockets Echo Using Play, Scala, And Actors, Part II

The first part of this tutorial went into detail on Play’s support for WebSockets based on iteratees. You don’t need to use actors to handle WebSockets, but in a lot of real-world situations you’ll want to use actors because you’ll want to keep some longer-lived state associated with the connection.

Let’s start with a “naive” implementation of the code. This is a direct translation of our initial simpleIterateeWebSocket to use an actor:

  def naiveActorWebSocket = WebSocket.using[String] {
    val actor = Akka.system.actorOf(Props[NaiveEchoActor])
    val out = Enumerator.imperative[String]()
    actor ! NaiveStart(out)
    val in = Iteratee.foreach[String] {
      msg =>
        actor ! Message(msg)
    }
    (in, out)
  }
...
// Actor messages
case class NaiveStart(out: PushEnumerator[String])
case class Message(msg: String)

class NaiveEchoActor extends Actor {
  var out: PushEnumerator[String] = _
  
  override def receive = {
    case NaiveStart(out) => this.out = out
    case Message(msg) => this.out.push(msg)
  }
}

(You can test the examples in this tutorial by cloning the github repo. Use the echo test at websocket.org and point it to ws://localhost:9000/wsNaiveActor. Each example in this tutorial has its own URL that you can see in the routes file.)

In this implementation, we pass the out enumerator to the actor using the NaiveStart message. The NaiveStart message acts like an initializer for the actor. It takes the out enumerator and stores it in a member variable. The in iteratee now simply passes each message to the actor. The actor then handles that message by doing what the old iteratee did, pushing the message back to the client via the enumerator. Notice we haven’t used WebSocket.async yet: While the actor tell (!) invocation is asynchronous, the overall method is synchronous.

This code more or less works but it has one important bug: There’s no guarantee that the out member on NaiveEchoActor will actually be set before the first invocation of actor ! Message(msg). If it’s not set, this would result in an NPE. If you look at the WebSocket chat example that comes with Play, you’ll notice they take a slightly more sophisticated approach using the ask method on actor (an implicit requiring import akka.pattern.ask). We can fix our code by doing the same thing:

  import akka.pattern.ask
  import akka.util.duration._
  
  implicit val timeout = akka.util.Timeout(1 second)
  
  def actorWebSocket = WebSocket.async[String] {
    val actor = Akka.system.actorOf(Props[EchoActor])
    (actor ? Start()).asPromise map {
      case Connected(out) =>
        val in = Iteratee.foreach[String] {
          event => actor ! Message(event)
        }
        (in, out)
    }
  }
...
case class Start()
case class Connected(out: PushEnumerator[String])
class EchoActor extends Actor {
  var out: PushEnumerator[String] = _
  override def receive = {
    case Start() =>
      this.out = Enumerator.imperative[String]()
      sender ! Connected(out)
    case Message(msg) => this.out.push(msg)
  }
}

The ? operator is a synonym for ask. ask sends a reply back to the caller as a Future, which we immediately convert to a Promise. (This conversion will become unnecessary with Scala 2.10 and Play 2.1). Now we can wait for the Connected reply message before creating our iteratee. We also make the Start message behave more like a real constructor and let it create the enumerator for itself. The out enumerator then gets passed back in the Connected reply. The Promise.map method invoked on (echoActor ? Start()) is like an “onReply” event handler. This approach guarantees that the enumerator is set on the actor before the iteratee is created. Since ask is asynchronous it is wrapped in a Future/Promise, as is the result of map. Hence, we can use the WebSocket.async call and everything works as before except now we have actors in play!