The Big Picture

First, setup a webserver to listen for connections to demo.example.com. When a user connects to the webserver, it will attempt to proxy their request to port 1337 (demo.example.com port 1337).

Second, a reverse proxy initiated with SSH on your localhost creates a connection to demo.example.com, and then has all traffic on demo.example.com port 1337 forwarded to localhost port 80.

User => demo.example.com:80 <=> demo.example.com:1337 <=> localhost:80

Requirements

Server

• Apache Web Server
• Apache mod_proxy module
• OpenSSH

Client

• Local web application
• SSH client
• SSH public/private keys to login to the remote server

Server Setup (Ubuntu)

You should be able to login to your server over SSH using public/private key authentication. How to do that is out of scope for this post, however there are plenty of guides available online that explain in detail how to do this.

Apache: Enable mod_proxy

$ sudo a2enmod proxy_http

Apache: Configure VirtualHost

Setup Apache to use a VirtualHost for URL you want to use for sharing your work:

<VirtualHost *:80>
ServerName "demo.example.com"
ProxyPass / http://127.0.0.1:1337/
ProxyPassReverse / http://127.0.0.1:1337/
</VirtualHost>

The ServerName Directive tells Apache to listen for client requests for demo.example.com. ProxyPass and ProxyPassReverse configure Apache to forward all requests to the local port 1337.

Apache: Restart to load VHost

$ sudo apachectl restart

Localhost Setup

Make sure you're running a local web application

This should be pretty obvious It doesn't matter what port it's running, you can configure that when you start the SSH reverse proxy.

Create an SSH Reverse Proxy

To actually enable the connection form your public web server to your localhost, you have to create a reverse proxy using SSH. The reverse proxy will create a connection from your localhost to the remote server (demo.example.com), then have all traffic from a designated remote port forwarded to a local port.

$ ssh -fNR 1337:localhost:80 demo.example.com

• -f puts ssh into the background. If you want to be able to easily kill the Proxy later, omit the -f and use ctrl + c.
• -N disables all output keeping things clean. If you omit this, you'll see SSH connect to your remote server.
• -R 1337:localhost:80 Tells SSH to create a reverse proxy and that all traffic on the remote port 1337 should be forwarded to localhost's port 80.
• demo.example.com is the remote server you want SSH to connect to.

You may need to change your localhost port depending on what port your local environment is running on. For example: if you're developing a rails application using the builtin webserver, you might need to use port 3000 instead of port 80.

You should now be able to hit demo.example.com in your browser, and see your application load.

$ npm install jshint -g

And was then greeted with a command not found error:

$ jshint
zsh: correct jslint to slit [nyae]? n
zsh: command not found: jslint

Turns out I needed to add the npm bin directory to my PATH, as it didn't get added there automatically since I installed zsh after node/npm.

export PATH="/usr/local/share/npm/bin:${PATH}"

You need to have some form of jshint installed on your server. Instructions of how to do that are out of scope for this post, and should be able to be easily found on the internet. I used the version that installed with npm.

Jenkins Build Tasks

This is a very simple setup that uses 2 Build > Execute Shell tasks. In the first shell task I created the checkstyle output:

jshint --checkstyle-reporter app/webroot/javascripts/mdc/ > build/logs/checkstyle-jshint.xml || exit 0

In the second, I created the jslint output:

jshint --jslint-reporter app/webroot/javascripts/mdc/ > build/logs/jslint.xml || exit 0

Checkstyle Plugin

Configure the checkstyles plugin to reference the created checkstyle-jshint.xml file:

Violations Plugin

Configure the violations plugin to reference the created checkstyle-jshint.xml and the jslint.xml file:

After some googling, the resolution was the following command on the server:

svn resolve --accept working -R .

Thanks to http://www.learnaholic.me/2009/10/04/subversion-resolve-for-tree-conflict/ for the answer.

CakePHP let's you use timestamp based cache busting on your assets by enabling Asset.timestamp in your core.php file. By enabling this and using the builtin HtmlHelper::css and HtmlHelper::script methods, your assets will have a timestamp appended to them as a query string. For example:

/app.js?123456789

However, older squid proxies will not cache anything that has a query string, thus preventing your files from being cached. An alternative solution is to move the timestamp into the filename, and then use htaccess or similiar rewrite rule system to map those files back to the actual files on disk. The end output would be something like the following:

/app.123456789.js

To implement this in CakePHP, you need to override the assetTimestamp in AppHelper.php

Use the following in your .htaccess file. If you're not using Apache, see the html5 boilerplate for nginx or web.config files.

Read more about filename cache busting at the Html5 Boilerplate Wiki entry on cache busting.

Content-switching is an OSI layer 7 application switching technique, which in lamans terms means that it has access to the HTTP requests and responses of your application. By inspecting each request and response, it make decision on where to send those requests and how to handle responses.

HAProxy is an open source load balancing tool that also has the ability to implement content switching.

Proxies & Reverse Proxies

You might be familiar with a Proxy, which is basically something that sits between the client and the server. When the client makes a request it first goes through the proxy then to the server. The response from the server then goes back through the proxy  to the client. These are usually implemented by the client and completely transparent to the server. A great example of this is when someone configures their browser to use a proxy to access the internet, with a tool such as Tor.

A Reverse Proxy is the same thing except it acts on behalf of the server. One example of a Reverse Proxy is a load balancer, which receives requests from a users and usually proxies them to one of several backend servers. This process is completely transparent to the client. Content switching is also a form of Reverse Proxy.

Content-Switching Scenario

Let's say you're in charge of a large social bookmarking application, http://delicioso.com. The shelf life for that system has come to and end and you're team has decided to rewrite everything in Rails. It's going to take a long time to migrate everything over to the new application, and you want to reduce the risk involved with a huge release cycle. Instead you want to take an agile approach and roll out bits and pieces over time in the following order:

1. Configure HAProxy as a Reverse Proxy
2. Phase in user profiles - http://delicioso.com/profile/...
3. ...

For the purpose if this example, let's call the current application Legacy. Image your current infrastructure is setup like the following:

                        +-------------------+
                        |    example.com    |
  User  +---------->    |-------------------|
                        |     legacy:80     |
                        +-------------------+

Step 1: Configure HAProxy as a Reverse Proxy

The first step is to setup HAProxy to be reverse proxy for Legacy, so later we can implement content-switching. You'll need to have HAProxy installed.

                      +-------------------+
                      |    example.com    |
User  +---------->    |-------------------|
                      |    HAProxy:80     |
                      |     legacy:8001   |
                      +-------------------+

Here's the config file to configure HAProxy in this way:

global
  #debug                                   # uncomment to enable debug mode for HAProxy
 
defaults
  mode http                                # enable http mode which gives of layer 7 filtering
  timeout connect 5000ms                   # max time to wait for a connection attempt
                                           #  to a server to succeed
  timeout client 50000ms                   # max inactivity time on the client side
  timeout server 50000ms                   # max inactivity time on the server side
 
backend legacy                             # define a group of backend servers
  server legacy_server 127.0.0.1:8001      # add a server to this backend
 
frontend app *:80                          # define what port to listed to for HAProxy
  default_backend legacy                   # set the default server for all request

Step 2: Phase in User Profiles

All of your user's profile pages have a URL format as follows: /profile/username. Your team finished implementing this in the new Rails framework and it's time to roll it out. The rails app is running on port 8002.

                      +-------------------+
                      |    example.com    |
User  +---------->    |-------------------|
                      |    HAProxy:80     |
                      |     legacy:8001   |
                      |      rails:8002   |
                      +-------------------+

Here's the new config file for content-switching all requests starting with /profile to the new rails application

global
  #debug
 
defaults
  mode http
  option httpclose                         # close the tcp connection after every request
  timeout connect 5000ms
  timeout client 50000ms
  timeout server 50000ms
 
backend legacy
  server legacy_server 127.0.0.1:8001
 
backend rails                              # define a group of backend servers
  server rails_server 127.0.0.1:8002       # add a server to this backend
 
frontend app *:80
  default_backend legacy
  acl rails_path path_beg /profile         # acl rule for rails supported paths
  use_backend rails if rails_path          # use rails if the rules match.

Check out the HAProxy documentation for more keywords your can use to route requests. This was a pretty simple example, this get's more challenging when you need to handle session state across the legacy and new systems.

Just add the file attribute to the <appSettings> node in your web.config, and add a local.config file to the project root.

<!-- WEB.CONFIG -->
<configuration>
  ...
  <appSettings file="local.config">
    ...
  </appSettings>
  ...
</configuration>

<!-- LOCAL.CONFIG -->
<?xml version="1.0" encoding="utf-8"?>
<appSettings>
	<add key="MySQLConnectionString" value="..." />
</appSettings>

Now when your app loads, it will check to see if there's a local.config file relative to the web.config file. If there is a file, then it overrides any web.config settings it finds duplicates for in the local.config. If the local.config file does not exist, then it is ignored.

Pro tip: Keep local.config out of your code repo and boom! Easily manageable local dev environment settings.

See Also:

• MSDN: appSettings Element (General Settings Schema)

CMD + OPT + CTL + [F1 - F7]

Here's the error I was getting:

The fix was simple, wrap the object in an array.

Found the fix thanks to the following StackOverflow post: http://stackoverflow.com/a/4939147

A Man's Secret - An Analogy

A man possess a secret book, which he cannot let anyone else know about. He decides the only way to keep the book truly secret is to memorize the entire thing and then bury the book so no one can find it. Later in his years he bears a son. Once his son grows old enough, the father digs up the book and begins having his son commit the entire book to memory. Years later, he has his son rewrite the entire book cover to cover from memory on paper. When the son successfully completes the task, and the father is satisfied that his son truly has the book memorized in it's entirety, the book and the copy of the book the son just wrote are thrown into a fire, completely eliminating any evidence that the book actually existed. A few years later the father dies, leaving the son on his own, with the book committed to memory.

This is similiar to how a javascript closure works. See the following code.

Code Example

var father = new function(){
 
    // this is declared as a private variable
    var secretBook = 'Book of Secrets';
 
    this.bearSon = function(){
        return {
            whatWasTheBookYourFatherTaughtYou: function(){
                alert(secretBook);
            }
        };
    };
};
 
// the father won't tell anyone about the book he has
alert(father.secretBook); // undefined
 
// the father bears a son
son = father.bearSon();
 
// the father dies
father = undefined;
 
// the son still knows the book his father taught him
son.whatWasTheBookYourFatherTaughtYou(); // Book of Secrets

secretBook was declared inside the father function and is a private variable, inaccessible to anything outside the father function. The father function closes around the variables declared inside of it. Anything defined inside the father function has access to it, even once the father function has executed and been undefined. The bearSon method returns a new object that contains a function called whatWasTheBookYourFatherTaughtYou.