stevej

import java.net._
import java.util.UUID

import com.twitter.conversions.time._
import com.twitter.finagle.builder.ClientBuilder
import com.twitter.util._
import java.nio.charset.Charset
import org.jboss.netty.buffer.{ChannelBuffers, ChannelBuffer}
import org.jboss.netty.handler.codec.http._
import com.twitter.finagle.stream.Stream

stevej

;; emacsd-tile.el -- tiling windows for emacs

(defun swap-with (dir)
  (interactive)
  (let ((other-window (windmove-find-other-window dir)))
    (when other-window
      (let* ((this-window  (selected-window))
             (this-buffer  (window-buffer this-window))
             (other-buffer (window-buffer other-window))
             (this-start   (window-start this-window))

stevej

I can make a case that queues only do what people want if you don’t consider failure cases. 

Qs are empty (normal) or full (fail). Normally things are processed quickly. Failure case processing time is unbounded (or “too long”). 

Solution is always “dump the Q”.  Which means you do care about how long it takes to process items. So you want the queue to always be empty

Which means you only want a non-failing Q. 

So why not admit it, use in-proc buffers, run enough servers to handle load? Reject work up front instead of dropping oldest items w/…

stevej

// In Rust, much like Go, you organize functions around structs.
#[derive(Debug)]
struct Person {
    id: u64,
    name: String,
    twitter_handle: String
}

// Here we hang a function off of a struct.
impl Person {