briancarper.net (λ) (Tag: Compojure)

New blog engine up and running

Wed, 23 Jun 2010 15:48:24 -0700

Well, my new blog is up and running. Sorry for the temporary lack of cows in my layout. I'm dogfood-testing the blog engine in a fairly vanilla state until I work out some of the bugs. This layout is based upon barecity, a minimalist Wordpress theme that I adapted easily enough to my blog.

As a bonus, I applied a dirty hack to my RSS feed that I think should help avoid screwing up people's RSS readers with duplicate entries.

I'll write again soon with some info about the blog engine and some things I learned writing it.

(As mentioned previously, here's the code.)

Breaking links is easy to do

Tue, 22 Jun 2010 23:23:27 -0700

I apologize in advance to everyone who subscribes to my blog's RSS feed, but this week your RSS reader is probably going to suddenly find 25 "new" posts from me.

My blog currently uses /blog/title as the URL scheme, with similar URLs for categories and tags etc. Soon, I'm probably going to change it to /blog/123/title, as part of the impending release of version 0.2 of my blog engine. (The code-in-progress is in a branch on github, for the daring and foolish among you.)

This way, I can change the title of a post without breaking everything. I have heretofore lacked this ability. It's easy to code, you just tell Compojure to ignore everything after the number in a route. Something like this:

(defroutes foo
  (GET ["/blog/:id:etc" :id #"\d+" :etc #"(/[^/]*)?"] [id]
    (pages/post-page id)))

It's only a few lines of code to change, but the ramifications are widespread. It'll instantly break every link to my blog, for example. At least it's pretty easy to set up a bunch of redirects in Compojure to avoid that. I think this'll work:

(require (blog [db :as db]
               [link :as link])
         (oyako [core :as oyako])
         (ring.util [response :as response]))

(defn redirect-post [name]
  (when-let [post (oyako/fetch-one db/posts :url name)]
    (response/redirect (link/url post))))

(defroutes redirect-routes
  (GET ["/blog/:name" :name #"[^/]+$"] [name]
    (redirect-post name)))

(Oyako here is the experimental ORM-like library I'm using to interface with PostgreSQL nowadays, having ditched Tokyo Cabinet.)

Changing my URL scheme is also going to mess up RSS though, because I (foolishly) used post URLs as the GUIDs in my RSS feed up to this point. This problem I don't know how to avoid. I might reduce the number of posts included in my feed temporarily, to limit the damage.

Deploying Clojure websites

Mon, 04 Jan 2010 20:42:17 -0800

On my server I'm running one Java process, which handles four of my websites on four different domains. These are all running on Clojure + Compojure. Some people asked for details of how to do this, so here's a rough outline. For the sake of brevity I'm only going to talk about two domains here, though it scales up to however many you want pretty easily.

This is surely not the only way to do this, and probably not the best way, but it's what I've arrived at after a year of goofing off.

Summary: Emacs + SLIME + Clojure running in GNU Screen; all requests are handled by Apache and mod_proxy sends them to the appropriate Jetty instance / servlet.

Directory structure

First you have to decide on a directory structure. There's a sort of Clojure convention to have a src and deps directory, though Clojure is so young that this convention may or may not stick. Behold my ASCII line-art directory tree:

~/public_html/base/
|
|----src/
|    |
|    |----common/
|    |
|    |----net/
|         |
|         |----briancarper/
|         |    |
|         |    |----<lots of .clj files>
|         |
|         |----ffclassic/
|              |
|              |----<lots of .clj files>
|
|----deps/
|    |
|    |----<lots of .jar files>
|
|----briancarper.net/
|    |
|    |----public/
|    |
|    |----db/
|    |
|    |----apache/
|
|----ffclassic.net/
|    |
|    |----public/
|    |
|    |----apache/
|

src holds the Clojure source code for all of my sites. Java (therefore Clojure) forces your directory structure to match your namespaces, and traditionally people use domain names in reverse order for both. Whether you like or dislike this convention, you must admit that if you're writing code that's actually going to be used to host websites on domains, the convention probably makes sense. There are some utility libraries I wrote that I like to share between sites, so I put those in some common namespace in their own directory.

deps holds a bunch of .jar files. This includes clojure.jar, clojure-contrib.jar, compojure.jar, swank-clojure.jar (for SLIME), and all the Java libraries I use, like Jetty, a bunch of Apache Commons libraries, Tokyo Cabinet, Rhino and so on. This means that all of my sites are sharing libraries, and therefore must be running the same version of Clojure and all other libraries. So when I upgrade a library that one site is using, I must upgrade all the other sites. This is sometimes a hassle, but it forces me not to be lazy.

Then I have one more directory for each of my domains, for static files and such. These directories have different subdirectories depending on how I'm running them. For the sites that use Tokyo Cabinet, I have a db directory to hold the database files. On some sites I want to run a PHP or CGI script, so I have a directory for Apache to use. All of them have a public folder, from which Clojure serves images, JS and CSS files etc.

Phil Hagelberg's recent Leiningen project can possibly help with some of this. I don't use Lein but I may switch someday.

Emacs + SLIME + CLASSPATH setup

Building or installing Clojure and Emacs and SLIME and friends is beyond the scope of this blog post. swank-clojure has come a long way in being auto-installable via ELPA nowadays, if you like.

The most important thing is to set up CLASSPATH correctly. src should be on the CLASSPATH, as well as every .jar file in deps. My .emacs contains this, among other things:

(setq swank-clojure-classpath (list "." "./src" "./deps/*"))
(setq swank-clojure-library-paths (list "/usr/local/lib"))

Java will take a glob and expand it to include every jar file in a directory, thankfully. But this seems to happen right when you start Java, so to add a new .jar to your CLASSPATH you generally need to restart the JVM. This is annoying, but oh well.

If you AOT-compile your Clojure code you might also have a classes folder on your classpath, but I don't bother. You could also compile your whole site into its own .jar file and use that. I don't do this because I want to be able to edit my Clojure source files on the server if I need to.

swank-clojure-library-paths is necessary for me because Tokyo Cabinet uses some C libraries. You might not need it.

Then when I start Emacs, I M-x cd to the base folder and start SLIME there. It'll find Clojure in deps and give me a REPL. If you can get this working, you're well on your way.

Clojure code

I have a file server.clj for each domain, which are in charge of setting up and starting / stopping the servlets. So in src/net/briancarper/server.clj I have something like:

(ns net.briancarper.server
  (:use (compojure.http request servlet session routes)
        (compojure.server jetty)
        (compojure control)
        (net.briancarper ...)))  ;; lots of files containing the guts of the site

(defroutes some-routes ...)
(defroutes other-routes ...)

(defroutes all-routes
  some-routes
  other-routes)

(defserver blog-server
  {:port 8080 :host "localhost"}
  "/*" (servlet all-routes))

src/net/ffclassic/server.clj is similar, except with different routes (obviously) and a different port for the servlet. Note that we bind to localhost here, so that people can't connect directly to port 8080 and bypass Apache.

One of the routes should be set up to point to the proper public folder. Generally some catch-all route near the end of your list of routes, like:

(GET "/*" (static-file (params :*)))

where this static-file knows to serve files from briancarper.net/public, and the other server.clj for the other domains point to different directories.

Compojure has the compojure.http.helpers/serve-file function you can use to serve static files too. I use my own function for various reasons. Note that Compojure generally doesn't set any HTTP headers on your responses. You should probably set some kind of cache control headers unless you want your users to re-download all of your image files and stylesheets every time they hit a new page. You might also have to fiddle with Content-Type sometimes, though Compojure is usually pretty good about guessing them.

Note that Compojure's hands-off approach has its upsides too. For example, I have a bunch of CSS files for my blog. In Clojure, I read and concatenate all of those CSS files into one blob of text and have Clojure serve that as http://briancarper.net/combined.css. combined.css doesn't actually exist. I do the same for JS. This speeds up user requests quite a bit, without having to merge all the files on the filesystem. I could further compactify them if I cared.

If your Clojure app is handling arbitrary request URIs, you should be careful you aren't serving up ../../../../etc/passwd or something. Pretty sure Apache protects you against this by default, but Compojure uses compojure.http.helpers/safe-path? to test for it too if you use the built-in serve-file.

Finally, for convenience, in the base directory I have a file called server.clj which contains this:

(ns server
  (:require [net.briancarper server]
            [net.ffclassic server]))

(defn go []
  (.start net.briancarper.server/blog-server)
  (.start net.ffclassic.server/ffclassic-server))

Then, to start everything, from a REPL:

user> (require 'server)
2010-01-04 18:10:50.046::INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
net.briancarper.server.proxy$javax.servlet.http.HttpServlet$0
net.ffclassic.server.proxy$javax.servlet.http.HttpServlet$0
nil
user> (server/go)
2010-01-04 18:11:02.260::INFO:  jetty-6.1.15
2010-01-04 18:11:02.358::INFO:  Started SocketConnector@localhost:8080
2010-01-04 18:11:02.707::INFO:  jetty-6.1.15
2010-01-04 18:11:02.789::INFO:  Started SocketConnector@localhost:8087
nil
user>

On the server (Apache)

To deploy this to my server I just rsync it all over SSH. On the server, I have Emacs and Java installed, as well as Apache and GNU Screen.

Why Apache? In case I want to run something that isn't Clojure, like webmail or some CGI script. Plus it's easy to run Clojure as a non-priviledged user on a non-priviledged port, and have Apache forward requests to the proper servlet based on the domain in the request. Apache is also nice for doing HTTPS.

My Apache setup is a pretty standard Debian-ish setup. You need mod_proxy installed. My Apache config for one domain looks a bit like this:

<VirtualHost *:80>
        ServerName ffclassic.net
        ServerAlias www.ffclassic.net

        <Directory /home/user/clj/ffclassic.net/apache/>
           AllowOverride All
           Order Allow,Deny
           Allow from all
        </Directory>

        DocumentRoot /home/user/clj/ffclassic.net/apache/

        ProxyPass /foo !
        ProxyPass / http://localhost:8087/
        ProxyPassReverse / http://localhost:8087/
</VirtualHost>

Yeah, that's about it. By default, every request will be passed to Clojure. The ports specified here should obviously match the ports you specify in your Clojure code for your servlets.

ProxyPass /foo ! tells Apache to handle requests to http://ffclassic.net/foo itself rather than pass them to Clojure. I override URIs on a case-by-case basis like this, to tell Apache to run whatever CGI or PHP scripts I need.

One oddity of running a setup like this is that thanks to mod_proxy, the "remote address" for every request is always going to be 127.0.0.1 by the time they get to Clojure. So if you want to see the IP address of your users, you have to do something like:

(defn- ip [request]
  (or ((:headers request) "x-forwarded-for")
      (:remote-addr request)))

Another oddity is that sometimes if Apache is running, and then I start Clojure, I have to restart Apache before it "finds" Clojure and starts forwarding traffic. No big deal though.

This is otherwise transparent from the Clojure end.

Starting it up

You probably want to SSH to your server, start a REPL, start your code running, and then log off the server. There are various ways you can run keep Emacs running in the background. You could run Emacs in server mode and attach to it with emacsclient. I use GNU Screen because it's easy and I have other things running in Screen instances that I like to switch between. So I start Screen, start Emacs, start SLIME, and start my site from there. Then detach from Screen when I'm done. It's easier than it sounds.

Why SLIME and not a normal commandline REPL? Because in Emacs I can patch the code easily on a function-by-function basis, among other things. You can do this from a commandline REPL but not nearly as easily. Emacs is a much nicer place to type than any command line. When I need to make an update to the site or fix a bug, my workflow is typically:

Fix it locally on my test machine, make sure it works
rsync the changed files to the server
SSH to the server
screen -r to bring up Emacs
Open the .clj file(s) I changed
C-c C-c to recompile and reload the individual function(s) I changed, or C-c C-k to recompile and load a whole .clj file, or whatever.
C-a d to detach from Screen

I can do any database inspecting or fiddling I need to do from the REPL. I can also do some live testing of the site or whatever else I want. It's good for debugging.

I've had Emacs running for months this way without having to restart it, it seems to work OK.

That's it

It's not that hard. It's clearly more steps than dumping some PHP files into a directory and having them work. But with Clojure, you get the benefit of a persistently running environment with a nice REPL interface, all in a nice fast multi-threaded JVM. Plus you get to write all your code in Clojure instead of PHP. In terms of fun and long-term maintenance costs, Clojure comes out way ahead in the end, for me anyways.

Clojure and Compojure to the rescue, again

Sun, 03 Jan 2010 15:57:52 -0800

I haven't posted here much recently because I've been hacking on another recently-sort-of-completed website. One of my favorite hobbies is old 8-bit video games. The first thing I ever programmed was a website about Final Fantasy for the old NES, and I've fiddled with it for the past 10 years or so.

A while back I decided to rewrite the whole thing using Clojure + Compojure with data in mysql. This went really well. I know lines of code isn't that great a metric, but it can give a rough estimate: this whole website is done in 3,400 lines of Clojure, which includes all of the HTML "templates" and the DB layer I had to write. And it's ~~turtles~~ Clojure all the way down. The only thing not written in Clojure are a couple bits of Javascript here and there and the stylesheet.

I suspect the target audience of this blog and the target audience of that website don't overlap that much, but I figured someone might be interested in some of the detail of how it's implemented. A few things I learned...

I didn't write a single line of HTML by hand. I can't overemphasize how wonderful this is. Compojure's HTML library lets you write HTML as Clojure data structures, with vectors being tags, keywords being tag names, hash-maps being attribute-value pairs etc.

Not only is this easier to write, it's easy to generate and manipulate. I have a ton of functions where given a list of hash-maps of data, it spits out a nicely formatted chart of that data. Here's an example:
```
(chart "Armor" (armor game)
       ["" #(name-with-image %)
        "Locations" (comp ulist location-links :locations)
        "Buy" (comp g :buy)
        "Sell" (comp g :sell)
        "Absorb" :abs
        "Evade%" (comp percent :ev)
        "Element" (comp ulist #(map :name %) :elements)
        "Casts" #(-> % :magic :name)
        "Usable by" (comp (partial equipable-by game ps) :pcs)])
```
chart is a function taking a chart title, some data, and then a vector of column-header names and functions for the data in each column. Anonymous functions are a great way to format each column differently depending on the kind of data it contains. chart also does some other stuff like standardizing the text of the chart title, alternating the background color of rows of data, re-inserting the header every so often, and formatting the first column specially (expecting it to be a title) and so on.

Sample output of this function is here. A screenshot for the lazy (click for bigger version):
Who needs an ORM? I wrote about this previously, but for my needs, an ORM is overkill. The vast majority of my interaction with a DB is reading data. All you need for that is an easy way to write SQL queries and get the results into a hash-map. I wrote a bunch of macros for this, and there's ClojureQL and clojure.contrib.sql and friends to help. For example I run some polls that users can vote on, and here's the entirety of the code that fetches it out of the DB.
```
(defn polls []
  (with-tables [polls poll_options poll_votes]
    (map (fn [p] (assoc p
                   :total (count (:votes p))))
         (-> polls
             (one-to-many :options poll_options (key= :id :poll_id))
             (one-to-many :votes poll_votes (key= :id :poll_id))))))
```
with-tables is a simple macro I wrote that fetches data from the DB for some table (possibly putting a WHERE clause on the query if specified, unspecified here). It takes care to run the minimal number of queries necessary, generally one query per table of data. Then I use other functions like one-to-many to join the data together. The result is a list of hash-maps, with the value of some keys (here :options, :votes) being sub-lists of hash-maps, for data that "belongs" to the toplevel hash-map.

Doing it this way helps me avoid the infamous "N+1 queries" which plagues naive use of Rails (where each of N objects would query the DB again to get its sub-lists of objects). I think Rails uses an :include option in its find functions to do that same kind of thing.

This is dirt-simple, but it gives me a lot of control. I can easily map or filter over any of these intermediary table lists before or after putting the results together. I can add keys with values that are calculated from other values, so it looks like the records have fields that don't really exist in the DB. I can do a sort-by on some key. I can take a user parameter and return different results based on whether that user is an admin or not. I can put metadata on the hash-maps, e.g. to indicate which table the data was fetched from. And so on.

Thanks to memoize (see below) this is really fast too. The most complicated query I have is for my walkthrough. After priming the cache:
```
net.ffclassic.db.charts> (time (dorun (walkthrough-chapters :nes)))
"Elapsed time: 0.074587 msecs"
```
Speaking of metadata: I like metadata.

For example I have a multimethod called link, which dispatches on the :table metadata key set from my SQL macros above, and outputs an appropriate link for something based on what it is. So (link some-user) links to a user's profile on the site, using the user's username as the anchor text, and styles it differently if it's an admin user or normal user. (link some-forum-post) links to the forum thread which contains the post. (link some-poll) links to a poll using the poll's title as the anchor.

Each of these spits out a vector that looks like [:a {:href "/user/view-profile/1"} "Brian"]. And that's changed into HTML eventually via Compojure's delicious HTML library.

This makes it really easy to link to things in a standard way with standard-looking anchor text. It also makes it easy to standardize on a URL scheme. If I want to change the URLs used to access my polls, I only need to change it in one place.

This is kind of like OOP, but not really, since I can have different metadata tags and use different ones depending on what I'm doing. And I can completely ignore the metadata whenever I don't need to use it.
Speaking of multimethods: multimethods are handy.

I have five "categories" of pages of data on my site, with pages in each category that are usually identical across categories. But sometimes a page in one category should look slightly different from the same page in other categories. Sometimes a page only belongs in one category and should 404 for the other categories. What I needed was some way to say "Display this page identically for each category by default, but page Y on category X is an exception".

Multimethods are great for this. Compojure's "routes" take a request URI and dispatch based on a regex pattern matched against it. I dispatch most requests to a series of multimethods. Given a request URI, I split the URI into category + everything else. Then, I first try a multimethod for category-specific pages, dispatching on a vector of [category rest-of-uri]. If there is no method for this, it falls through (returning :next) and Compojure tries the next route. The next route tries a multimethod for pages that look the same category-wide, dispatching only on rest-of-uri this time. If there's no method for that, it falls through again with :next and a list of "static" routes are tried (oddball pages that don't belong to any category). If those all fail, you get a 404.

This is an easy way to split your site into namespaces based on the uri. You can also add new pages without editing your Compojure routes. Just add a new method to the multimethod.

The code looks something like this:

*code edited 2010-01-04 to fix a crapload of typos, thanks Shawn
```
(defmulti category-specific-page (fn [cat page] [(keyword cat) (keyword page)]))
(defmethod category-specific-page :default [& _] :next)
(defmethod category-specific-page [:cat1 :some-page] [cat page]
  (...))


(defmulti cross-category-page (fn [cat page] (keyword page)))
(defmethod cross-category-page :default [& _] :next)
(defmethod cross-category-page :some-page [cat page]
  (...))


(defroutes some-routes
  (GET #"/(cat1|cat2|cat3)/([^/+])/*$" (apply category-specific-page (:route-params request)))
  (GET #"/(cat1|cat2|cat3)/([^/+])/*$" (apply cross-category-page (:route-params request)))
  (GET "/" (default-index-page))
  (ANY "/*" (error-404))) 
```
This was a nightmare to do properly in Rails. Rails wants to dispatch to controllers, which are classes. To make this work in Rails I had to mangle this concept to fit into the idea of a hierarchy of classes and subclasses. There might have been an elegant way to do it, but I couldn't think of one. I suspect someone will leave me a ~~flame~~ comment telling me how to do it.
memoize is great as a poor-man's web cache. I have a bunch of pages of data that never change. So the first request fetches it from the DB, and subsequent requests are cached in RAM and are therefore nearly instantaneous. The data is cached in the form of huge lists of hash-maps (many of which have sublists of more hash-maps, sometimes many levels deep). I was concerned at first that this might take a lot of RAM, but I went with it, and it turned out not to. top tells me:
```
PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17   0  257m 127m  12m S    0 23.6  48:18.91 java 
```
I'm actually running four websites in the same instance of the JVM there, so it's not that much RAM usage at all.

memoize doesn't work for everything, obviously. There's no easy way to invalidate or refresh the cache with the built-in memoize, so it's not good for data that is updated frequently. If you do need to invalidate some data, you have to re-compile the function. But it works well for static data. The great thing is that it's very fine-grained. Change a single defn to defn-memo (in clojure.contrib.def) and you're done.
Compojure's "decorators" are really quite nice. For example I use them to implement a kind of templating / layout system. I have a with-layout function which, given a response, wraps the HTML for that response in a standard layout (header, sidebar, footer). I group a bunch of routes together and decorate all of those routes with with-layout, and then it's done. This "layout" code is completely separate from the code the generates the HTML for the pages, and lets me change it easily (add a new layout for some specific pages, or whatever). A bunch of other routes, like those that handle POST requests and such, don't get a layout; I just group those routes separately and don't decorate them.

All of this is done with plain old Clojure functions. There's no separate "template library". There's no ERB or Smarty to wrestle with, though you could use something like StringTemplate if you wanted to.

Another example: certain pages are admin-only. So I group all of those pages together into one group of routes, and do the admin check first-thing, immediately failing if someone isn't logged in or if the current user isn't an admin. This thankfully lets me not have to worry about doing permissions checks all over the place. The code looks like this:
```
(defn admin-only [handler]
  (fn [request]
    (when (:admin (:session request))
      (handler request))))


(defroutes admin-routes
  (GET "/some-admin-only-page" (admin-page))
  (GET "/another-admin-only-page" (other-admin-page)))


(defroutes admin-form-routes
  (POST "/some-admin-only-page" (mangle-database)))


(decorate admin-routes with-layout admin-only with-session)
(decorate admin-form-routes admin-only with-session)


(defroutes all-routes
  admin-routes
  admin-form-routes
  other-routes
  etc.)
```

I'm overall pretty pleased with the site. There are still some rough edges and much more work to be done, but it's a joy to code compared to the Rails version.

Blog and CRUD

Sun, 12 Apr 2009 20:01:35 -0700

I updated my blog source code on github. I also split my CRUD library out into its own clj-crud repo. It is cruddy, so the name is apt.

This code still isn't polished enough for someone to drop it on a server and fire it up, but maybe it'll give someone some ideas. I think the new code is cleaner and it'll be easier for me to add features now.

Beware bugs, I'm positive I introduced some.

EDIT: A word about the CRUD library... persisting data to disk is hard when the data may be mutated by many threads at once and the destination for your data is an SQL database that may or may not even be running. I have more respect for people who've written libraries that actually do this kind of thing and work right. Granted I only spent 3 days on mine but still, it's tricky.

I gave up for a while and tried clj-record, but it was prohibitively slow. It has the old N+1 queries problem when trying to select an object which has N sub-objects. In real life you'd write SQL joins to avoid such things. Ruby on Rails on the other hand gets around this via some nasty find syntax.

I get around it by having all my data in a Clojure ref in RAM already so it doesn't matter. And by using hooks so each object keeps a list of its sub-objects and the list is always up-to-date (updates of sub-objects propagate to their parents). But the crap I have to do to get this to just barely work is pretty painful.

Blog source code released

Fri, 27 Mar 2009 02:14:53 -0700

By popular demand, I've released the source code for my blog. Hope someone finds it useful.

http://github.com/briancarper/cow-blog/tree/master

Feedback and bug reports welcome, email me or post them somewhere on my blog and I'll find them.

Anti-spam field still holding

Mon, 23 Mar 2009 19:38:27 -0700

So far my silly anti-spam measures are working. Since last week I've had 1861 spam comment attempts, of which 0 were successful. 1857 of them didn't even alter the text my the captcha text field at all. Four of them inexplicably HTML-escaped the < into a <.

One feature I didn't implement from Wordpress is subscribing to comments via email. Sending an email from Java is possible but a little bit painful to implement. The Javamail API is a monster.

I do think it's useful to be able to know when someone responds to comment you left, but is spamming your inbox really the best way? I have to think there's a better way.

I did implement an RSS feed for each individual post's comments. And separate RSS feeds for all the tags on my blog, and all the categories. When RSS feeds are generated dynamically, why not? This is all of the code for the tag feeds:

(defn tag-rss [tagname]
  (if-let [tag (get-tag tagname)]
    (rss
        (str "briancarper.net Tag: " (:name tag))
        (str "http://briancarper.net/" (:url tag))
        "briancarper.net"
        (map rss-item (take 25 (all-posts-with-tag tag))))
    (error-404 )))

Plus the routing code:

(GET "/feed/tag/:name" (tag-rss (route :name)))

But I haven't uploaded the comment-feed feature because I don't know if it's overkill. Personally I am liberal with my RSS feeds, I just pop them into my Akregator and off I go. But I don't know if other people take their feeds more seriously, or what. RSS feeds can be a bit heavyweight. Maybe I should make a feed for all of my comments across all posts.

Blog is still going strong

Wed, 18 Mar 2009 22:01:11 -0700

After I implemented that silly CAPTCHA yesterday, the spam was stopped. There's also a honeypot form field (it's hidden via CSS so humans don't know it's there, and if any bot POSTs text for that field, the data is rejected automatically). It's silly and easily defeated, yet it stopped all 262 spam attempts since yesterday. It looks like all the spam is for one site, but it's coming from a huge range of IPs. So it's probably a botnet. Thanks, MS Windows!

I rewrote my whole CRUD layer so that I could use it for more than one database at once, and then rewrote my gallery code to take advantage, and now two hours later I have my origami gallery back up and running. Both sites are running from the same JVM. I wonder how many sites I can have going at once before the server melts into a puddle of Java-inflicted goo.

  PID PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11338 16   0  512m 128m  12m S    0  0.3   0:28.33 java

Good thing I have plenty of RAM on the server. From looking at before and after shots of the memory usage, 66 MB is the JVM itself, and 40MB more is Jetty and Compojure and my code and all the dependencies. Then the last ~20 MB or so is my database slurped into RAM. So I can probably fit another few tens of thousands of posts and comments in here before I have to worry much. The real test will be letting this thing run for a couple weeks and see how hard it leaks.

Fun with HTTP headers

Tue, 17 Mar 2009 22:14:10 -0700

One fun thing about playing with Compojure is that it doesn't do much with HTTP headers for you, which is a good learning opportunity. RFC 2616 is rather helpful here.

For example I learned that if you don't set a Cache-Control or Expires header, your browser will happily re-fetch files over and over, which is a bit of performance hit. Static files that don't change often like images etc. can be set with a higher Expires value so they're cached.

Another thing to keep in mind (note to self) is that using mod_proxy to forward traffic to a local Jetty server means that the "remote IP" you get from (.getRemoteAddr request) will always be 127.0.0.1. If you want the user's real remote IP, you have to look in the X-Forwarded-For header (easily accessed as (:x-forwarded-for headers) in Compojure. Given that Identicons are generated from a hash of an IP address, this has resulted in some screwed up (wrongly identical) avatars for a bunch of people in posts for the past couple days. Oops. Not much I can do to fix that now.

In other non-news, I just the spam logging for the blog so I can see the kinds of things bots are doing to get around my feeble anti-spam measures. Sadly the spam seems to have stopped entirely, right after I set this up. How annoying.