Aside from the legal advantages of not talking to the cops, it can also save you from a very aggravating conversation.

I had the cops come by my apartment once. Apparently some kids were shooting airsoft guns into the neighbor's yard and endangering their kids, and they thought I knew something about it. I didn't, but the cops spent the whole time acting like they had a witness who saw me talking to the kids--and singled me out by my t-shirt and car--and were convinced I knew who they were.

They even played good cop bad cop--one of them acted friendly and sympathetic, "I know you don't want to rat out your friends", complimenting me on my music (I had Iron Maiden playing on my Pandora at the time) while the other one was a total dick and kept saying "We know you're lying". They were expert at turning around everything I tried to say--I'd say "I'm sorry, I can't help you", and they'd say, "Why can't you help us? Why can't you just tell us what you know?"

Then, of course, since they were rather intimidating they kept commenting that I was acting "avoidant" and implying that meant I knew something, when actually I was just intimidated by them. It didn't help that at the beginning they told me to keep my hands out of my pockets, which is an obvious security measure but also a power game.

To this day, I still don't know if they got a tip on me from someone who saw me and misinterpreted the situation, or if they were sweeping the whole complex and bluffing their way into making everyone think they had a specific tip on them. Or maybe they were just practicing their interrogation skills. Nothing ever came of it, but I should have known from the outset to say nothing.

My copy of baby Rudin (Principles of Mathematical Analysis) was the first "real" math textbook I used. It was notorious at the bookstore. At $135, it was more than a dollar per piece of paper, and smaller than a volume of poetry, with decently sized text and a good layout. But make no mistake--it could kill a man, and it was well worth every penny.

It's not an exaggeration to say that you could spend a whole hour working through a single page, and in fact that's what the first day in my Real Analysis class was: learning how hardcore math is really done. It has an astonishing economy of expression, where everything you need to understand a proof is written, but if you blink you'll have to start over. It doesn't just feed you facts and theorems to memorize. Skill is developed in the process of reading, because reading this book requires unpacking explanations, filling in details, and making connections for yourself.

The closest analogy I can make is that it's like watching a grandmaster play a real game of chess, when all your previous chess lessons had been finding the correct four moves from a handful of common positions. It's not necessarily the best or easiest way to learn real analysis itself, but having learned real analysis from that book, you are prepared to not only learn, but master, any other type of math you happen to come across.

Requiescat in pace.

I was in a very similar situation a few months ago. I ran a URL shortener and got tired of the upkeep, but more importantly, I realized that it's a not product but a feature. I sold it, eventually. Here is how.

I blogged saying the site is going to shut down, and I started making plans about what would happen in terms of data export and keeping the URLs working. The community responded VERY loudly: we like it, don't shut it down, at least give it back to us or sell it. This told me something very important that I didn't realize: no matter how fed up you are, no matter if you hate it or like it, there are people out there that value your work. You just don't it yet.

So I wrote up a brief post about the vital stats with vague ballpark figures, and gave an email address for serious bidders to get in touch. A lot did. Some were not serious at all (easy to tell) and some were very professional and clearly serious about wanting the site. In the end more than one bid was on the table from people that not only wanted the site, but really cared about the users.

How it was valued: an auction. Best bid wins. I kept it anonymous (under the trust that I don't inflate the price, and I never did). If I were to do this again, I would put it up on flippa or sitepoint or ebay or elsewhere.

The biggest problem you'll have is people knowing about the sale. Like anything, market it. Your users are the most likely group to produce the buyer.

The second biggest problem is spurious bids.

And sell everything related to the site. You need to sit down and make a very thorough inventory, and be very careful not to include things you cannot sell (check the licenses) and be sure to include everything you can sell. Included in my sale was a handful of domains, full source code and the whole database.

People will want proof of whatever numbers you give them. Screenshots are OK to a certain extent. Eventually they'll need full access to verify things, like to Google Analytics or your site's admin area. A good way to do this is show them screenshots and agree the sale. Get paid 1/2 or 1/3 upfront, give them access, they verify everything and then you get the rest of the money. Even better, use an escrow service.

Drop me a line if you want more help. Details in my profile.

Once upon a time, there used to be these books that contained everyone's phone number. They called them the "White Pages". Oh the humanity!

This looks great. If you are a non-Haskeller or only a semi-Haskeller and are wondering what technical features set this apart from other existing frameworks:

The Snap framework uses a style of I/O called “iteratee I/O”. We have opted for iteratees over handle-based and lazy I/O because iteratee I/O offers better resource management, error reporting, and composability.

If you're interested, you can read some in-depth stuff here: http://okmij.org/ftp/Streams.html (these papers are somewhat famous)

The Snap tutorial has a decent summary of how they work, but it doesn't provide a lot of context for why.

If you are already familiar with functional programming, then you know about foldl, foldr, and left/right recursion. When processing a collection of some kind (like a list), usually you take an enumerator (the fold function or a map function, for example) and pass it an iteratee (the function that will be applied to each element) and then your work gets done and you get a result. Left fold is non-lazy, right fold and map are lazy.

Because Haskell is a lazy language, there is another way to process lists lazily: with explicit recursion to the right. If you are familiar with Scheme or Lisp, it would look kind of like

    (define (myfunc xs)
      (cond ((null? xs) '())
             (else (cons (+ (car xs) 1)
                         (myfunc (cdr xs))))))

which would add 1 to each element of a list, returning a new list.

In Lisp or a non-lazy Scheme, this would blow up in your face for a large list. In Haskell it's no sweat, because the list will only be processed as it is needed, and generally for control structures you have to go out of your way to make it 'space leak' (build up a bunch of unevaluated expressions and then explode when you finally evaluate it.)

If you use foldr or map in Haskell, it works like this. One interesting thing about using non-explicit recursion in Haskell is that if you put a bunch of maps or folds (or with the Stream Fusion library, many different types of list operations) next to each other, the compiler will inline them together and eliminate intermediate list allocations. So you can end up writing your process as a series of discrete logical steps (from list type a, to b, to c, to d) but still get the performance of doing only one traversal. Very nice.

One of the downsides is that you end up with a lazy control structure, which can be problematic when dealing with the real world. For example, when reading from a file handle, someone could move the file or delete it or something. With lazy IO, the programmer is not really controlling when the file will be read by the program. Often, this is not a problem. However, with networking and time-critical applications, it can be a big problem.

Another problem is that if you need to perform allocations (like going from a list of one length to a list of another length) in the middle of your transformations, it gets really tricky if you want to maintain fusion. Normally with explicit right recursion you can just cons together a larger list on the fly, but we can't do fusion on explicit recursion, and compilers are generally bad about figuring out what kinds of allocation our explicitly recursing function does.

We don't want to give up our elegant way of expressing operations of sequences, but we want to know when we are writing and reading from the real world, and we want to do it with determinate constant space. Iteratees let us do that almost as elegantly as the normal list stuff by driving the consuming of the list via the functions that do the actual processing. Sort of like a list unfold, but not quite.

Check out attoparsec-iteratee http://hackage.haskell.org/package/attoparsec-iteratee for an example of iteratee usage: it turns a fast bytestring parser into one that's based on iteratees, which will probably end up being even faster. (correction: which will allow you to process streams in constant space without needing to explicitly manage things.)

(If Dons or Gregory Collins is around to correct the numerous mistakes I'm sure I made in this post, please do so!)