PUBLIC MARKS with search sucks

Tornado comes with limited support for WSGI. However, since WSGI does not support non-blocking requests, you cannot use any of the asynchronous/non-blocking features of Tornado in your application if you choose to use WSGI instead of Tornado's HTTP server. Some of the features that are not available in WSGI applications: @tornado.web.asynchronous, the httpclient module, and the auth module.

in other words: WSGI sucks

# There are meaningful “entry points” into the app - URIs. (No, I’m not going to mention the R-word.) It’s simply entirely unacceptable for a Web app to expose only a single URI, break the “Back” button, and disallow linking. Frameworks that don’t support URIs for application concepts, such as every customer, order, contact report, document etc. should simply be banned.

# Application boundaries are a concern to developers, not users. The Web is about linking stuff together, without any concern about application boundaries. There’s absolutely no reason why you shouldn’t be able to follow a link in your CRM application that takes you to a product page in your online catalog, or from a customer record to the information about when they last logged in to the Web site, or from a page that’s part of a complex business process UI to the appropriate documentation and on to the discussion group where you can tell everybody how much it sucks.

# Documents are accessible in a standard way. The idea of accessing any kind of document, such as an insurance application form that’s been scanned in, a letter sent to a business partner last year, or a contract with a business partner, by any other means than an HTTP GET is just stupid.

The Python SMTP Server

We've all been there, mucking around in the sendmail m4 macros trying one more time to get the damn mailing list to update for the new users. Every time we say, "This sucks, I want to rewrite this stupid thing." Yet, when we're done, we simply crawl back to our caves covered in our sendmail wounds.

Lamson's goal is to put an end to the hell that is "e-mail application development". Rather than stay stuck in the 1970s, Lamson adopts modern web application framework design and uses a proven scripting language (Python).

1. Will we be able to make money? We're a business. We have mortgages and tuitions to pay. Plus, if we don't make some cash once in a while, how will we feed our habit of continually screwing around?

2. When we're done, will we be proud of the work we've done? Slaving for months on a project only to not want to show it to anyone when you're finished just plain sucks. No amount of money can make that feel better.

3. Can we learn a little something new along the way? Executing the project has to make us smarter and help satisfy our curiosity, which we think is our greatest asset.

Facebook contacted me and requested that I stop distribution of FacebookSync since it is in violation of Facebook's Terms of Use. Sorry to all out there who will miss this useful application.

FacebookSync 2.1 released, now functionality has been severely limited to comply with Facebook's Terms of Use (only uses Facebook Platform to communicate with Facebook)

facebook sucks