Techosaurus

I’ve written about this before. It comes up about every time I look for a new place to live. I moved back in with my parents a while back, but unfortunately it just doesn’t jive well with my social life. No disrespect to my parents (i love them), I just need a place to call my own. This brings us to the search.

Looking for a place to live in Utah county sucks because no good search tools exist. The closest thing I had to a good search tool was KSL Classifieds. Unfortunately, they’ve replaced their homes section of the site with some service called Rentler. It’s pretty clear that Rentler has put quite a bit of money into their site design, but unfortunately it’s clear that Rentler lacks a good UX developer. There are a number of glaring issues that make searching a bane:

1. There are no text summaries on the main search results page.
   This by far is the biggest problem I have with Rentler. Really, the first two sentences of the description are all I need to make a quick yes/no decision on a property. Normally because these first two sentences include important key phrases like, “women only” (obviously that’s a no, because I have a penis), “BYU Approved” (no), and “shared room” (no). Instead of being able to blaze through hundreds of ads in a few minutes, I have to click on each one, load a whole new page and then click another link to get a full summary. That’s just shit UX design.
2. No result sorting in any way.
   Seriously? What in the hell were they thinking? The default (and only available) search sorting is price high-to-low. I like to view my ads from the newest to oldest posting. The new ones are more likely to be open (and actually relevant). Furthermore, I don’t know a single person who thinks to themselves, “Ah yes, I’d like to search in the very tip top of my price range.” When I set price ranges, the high is the absolute most I would want to spend… aka the last resort. Absolutely not the first thing I want to see.
3. Hope you didn’t want to select a price range smaller than $400:

Really, I could write a better site than this in under a week. Node.js would be the server side, couchdb for the database, UI would be all AJAXy (and actually usable), and it would have a RESTy JSON API.

I’m an IT major. Well… I’m an arrogant IT major. I feel like I already know everything for this degree. Because of that, I’ve been avoiding the entry level classes for as long as possible. Well, I’m a senior now, so it’s time to get those entry level classes finished up. The more I take the low level 101-esque clases, the more I see a disturbing trend. These classes don’t teach you any IT fundamentals. In fact, they would probably be more appropriately titled: How to give your boss a reach around.

The reasoning here is that you don’t actually learn anything about computers. You learn marketing/business terms that vaguely relate to computers only in that computers are so pervasive, anything can be related to computers.

If I wanted to be in marketing / business, I would take a class in marketing or business. Me? I want to learn about computers. I would so much rather see IT 101 all about setting up Linux VMs, familiarizing with various unix flavors, gaining some windows sysadmin skills (policies, etc) or learning about low level computing concepts. Instead, what you’re getting is the definition of B2B, and tips on how to suck up to management.

Note: I’m not opposed to having a business class or two required for my degree. That’s a-okay… but make me take a business class.

Apache is fat. Fat with memory usage. Right now It’s eating up 40% of the available memory on my server and it’s nearly idle. I would hate to see what it looks like under load (but this box almost never gets under load, because this blog is really low-traffic). 2nd in memory usage is MySQL. MySQL almost idle too. So the new plan is:

• nginx
• jekyll
• couchdb (if necessary).

There will be a time in your life where you want to set nginx up to serve all of your static content. Then you’ll get fancy with your programming and want to serve dynamic content. Heres the thing, you don’t want all of your requests to be served dynamically. You want the front facing web server to serve up your static content, while still letting connections through to your dynamic content engine. I’m going to show you how to do it. In our case, we’re using connect-vhoster in combination with node.js, connect and spark to serve dynamic content. Let’s get into the nitty gritty:

I want mine to work with wild card subdomains so i can set up anything on the fly. The nginx.conf I’m about to explain already has support for that, but you’ll need to make sure that you set up wild card DNS with your DNS host first.

In your nginx.conf we need a server block (this goes at the end of the http block) Here is mine:

server {
  listen 80;
  server_name ~^(?<domain>.*techosaur.us);
  root /var/webapps/vhosts/$host/public/;
  try_files $uri $uri/ @nodevhost;

  location @nodevhost {

    access_log      /var/log/nginx/vps-access-log;
    proxy_pass      http://localhost:3001;
    proxy_redirect  off;

    proxy_set_header  Host              $host;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_max_temp_file_size 0;

  }
}

So there it is. It’s neat, it’s clean, and it’s not very descriptive.  I’ll explain it line by line:

  server 80;

This just tells nginx to listen on the standard http port of 80.

  server_name ~^(?<domain>.*techosaur.us);

This sets server_name to whatever the wild card subdomain of the moment is. It’s totally dynamic and very smooth.

  root /var/webapps/vhosts/$host/public/;

Here we set the root of the site of the moment to the correct directory based on the subdomain ($host). For example, if we’re being accessed on lollerskates.techosaur.us then $host is set to lollerskates.techosaur.us. If you’re using the connect middleware vhost module that I do (and I think you should), then your directory names in /var/webapps/vhosts match the subdomains that you want to use. This is a key part of letting nginx serve static files for your wild card subdomains. Without this, nginx won’t be able to find the files.

  try_files $uri $uri/ @nodevhost;

This is the most important part of nginx static file serving. This line tries to serve $uri (/something/whatever.html) from the root that we defined above, if that doesn’t work it’ll try it with a / on the end, and if that doesn’t work then it’s probably a dynamic page and will and it off to location @nodevhost, which is our reverse proxy.

I’m going to skim over the location @nodevhost block because this is covered elsewhere, but essentially it’s just a reverse proxy to localhost on port 3001 which is the port that my vhost module listens on. We forward some headers in the 2nd part which allow the vhosts to see the real remote IP instead of nginx’s IP.

And that’s about it