Dylan Smith

Dropbox Based Static Site

2017-09-06T16:23:41+00:00

This site is built using Hugo, a blazing-fast static site generator based on the Go programming language. I’ve put together a writing and publishing workflow that can be used across devices, including mobile, that I’m really happy with. It’s not for everyone, but if you favor Markdown as I do, and want to have all your content in a single managed place, it could be a good solution for you. This post outlines how I went about setting it all up.

Docker all of it

I’m using docker-hugo to run all Hugo commands, both locally and on the server. This way I don’t have to manage Go or any dependencies. It just works.

Local development

To start a new Hugo project using the Docker image, run:

docker run --rm --name hugo-init -v $(pwd):/src jojomi/hugo hugo new site src

Be sure to do this in a Dropbox sub-directory so that your content syncs across devices and, most importantly, on the server (we’ll get to that part).

Now you can start watching the site in development mode using:

docker run --rm -it --name hugo-watch -e HUGO_WATCH=1 -p "1313:1313" -v "$(PWD)/src":/src -v "$(PWD)/output":/output jojomi/hugo

This will start the Hugo server on port 1313, which is why we map that port to the host.

(If you are following along and just created a new Hugo site, at this point you will only see a blank page. You will have to create or download a Hugo theme to get started. This overview will not go into the details of customizing and configuring Hugo itself. I’ll save that for another essay.)

At this point, the root of your project will have two directories:

ProjectDirectory/
+ output/
+ src/

The Docker Hugo container should always be run from the base of the project since it will be linking volumes in the container to the src and output directories.

On the server

Make sure Docker and docker-compose are available on the server. I won’t go into Docker installation in this post. DigitalOcean has a great post outlining the process.

Also required for the next few steps is Python 2.7 and inotify-tools. The latter can be installed with:

sudo apt-get install inotify-tools

I run Dropbox with a customized Dropbox Docker image. To set up Dropbox on Ubuntu, run the following command, which will automatically pull the latest image:

docker run -d --restart=always --name=dropbox -v ~/dropbox:/home/user/Dropbox -v ~/.dropbox:/home/user/.dropbox dylansm/dropbox

This will link the running container to two directories, dropbox, which will hold your Dropbox-synced files, and .dropbox, which will hold the Dropbox configuration files.

In order to link to your Dropbox account you will need to view the Docker Dropbox container logs. An authorization URL should be visible by issuing:

docker logs dropbox

Copy and paste the URL in a browser and log in to your Dropbox account to associate the container with your Dropbox account.

Exclusions

If you are an active Dropbox user, you may wish to use the selective sync feature to exclude all files and folders that are not related to your website.

Do this by issuing the exclude command:

docker exec -it dropbox dropbox-cli exclude add <dir or file name(s)>

You can list as many directories and files as you like in a single command. After a few moments, excluded files should disappear from your Dropbox directory.

Build your site by saving a file

The following steps will set up a watcher that rebuilds the site when a text file has been modified.

In the root of the src directory of your project, either on your local development box or on the server, create a file called rebuild.txt (you can call it whatever you want as long as you reference it correctly in the following steps). This will be the file that, on save, will sync to the server and trigger a site build.
On the server, create an empty file in the home directory called .websitename_last_build (replace websitename with the name your website). This file will store the last modified date of the dropbox-synced rebuild.txt file.
Now visit the Dropbox for Developers Apps page and create a new application. Grant it full Dropbox permissions and generate an access token by clicking Generate button under the OAuth 2 section. Copy the access code.
Create a directory called bin in your server home directory. The first file we will add is a Python script to check the status of the rebuild.txt file and, if it changes, store the last modification date to the file created in step two .websitename_last_build . Save the following as ~/bin/dropbox.py and be sure to paste your access code into the headers dict at the top:

import json
import os
import requests
import subprocess

url = "https://api.dropboxapi.com/2/files/list_revisions"

headers = {
 "Authorization": "Bearer YOUR-ACCESS-CODE-HERE",
 "Content-Type": "application/json"
}

data = {
 "path": "/Sites/servername.com/src/rebuild.txt",
}

request = requests.post(url, headers=headers, data=json.dumps(data))

created = json.loads(request.text)

last_modified = created['entries'][0]['server_modified']

with open("/home/serveruser/.servername.com_last_build", 'r') as f:
 last_build = f.readline()
with open("/home/serveruser/.servername.com_last_build", 'w') as f:
 if last_build != last_modified:
 f.write(last_modified)
 subprocess.call("/home/serveruser/bin/hugo_build.sh sitename.com www", shell=True)
 else:
 f.write(last_build)

Don’t forget to replace the access key in the headers dictionary near the top. Also, change the server user from ‘serveruser’ to the correct user name.

Next, create the file ~/bin/hugo_build:

#!/bin/bash

echo ""
echo "Building $2.$1..."

START_DATE_WITH_TIME=`date +"%Y-%m-%d %H-%M-%S"`
echo "Start: $START_DATE_WITH_TIME"

production_path="/home/serveruser/dropbox/Sites/$1/src"
production_build="/var/www/www.$1/public"
docker run --rm --name hugo-production -e HUGO_BASEURL=https://www.$1/ -v "$production_path":/src -v "$production_build":/output jojomi/hugo
chown -R serveruser:serveruser "$production_build"

END_DATE_WITH_TIME=`date +"%Y-%m-%d %H-%M-%S"`
echo "End: $END_DATE_WITH_TIME"

Create a third file ~/bin/watch_build that has the following:

#!/bin/bash

function watch {
 FILE=/home/serveruser/dropbox/Sites/websitename.com/src/rebuild.txt

 if [[ -e "$FILE" ]]; then

 while inotifywait -qe MOVE_SELF $FILE; do
 /usr/bin/python /home/serveruser/bin/dropbox.py >> /home/serveruser/logs/build.log 2>&1
 break
 done
 fi

 watch
}

After creating these files make sure they are executable:

chmod +x ~/bin/dropbox.py
chmod +x ~/bin/hugo_build
chmod +x ~/bin/watch_build

Now we will set up the server directory so that when Hugo builds the site it will be generated at /var/www/www.websitename/public

sudo mkdir -p /var/www/www.websitename
sudo chown -R serveruser:serveruser /var/www

Be sure to use the correct server user name.

Create a docker-compose.yml file with the following content:

nginx-proxy:
 image: jwilder/nginx-proxy:alpine
 volumes:
 - /var/run/docker.sock:/tmp/docker.sock:ro
 - /etc/letsencrypt/live/websitename.com:/etc/nginx/certs:ro
 - /etc/nginx/vhost.d
 - /usr/share/nginx/html
 ports:
 - 443:443
 - 80:80
 restart: always

letsencrypt:
 image: jrcs/letsencrypt-nginx-proxy-companion:latest
 environment:
 - DEBUG=true
 restart: always
 volumes_from:
 - nginx-proxy
 volumes:
 - /etc/letsencrypt/live/websitename.com:/etc/nginx/certs:rw
 - /var/run/docker.sock:/var/run/docker.sock:ro
web:
 image: nginx:alpine
 environment:
 - VIRTUAL_HOST=websitename.com, www.websitename.com
 - LETSENCRYPT_HOST=websitename.com, www.websitename.com
 - LETSENCRYPT_EMAIL=your@email.com
 restart: always
 volumes:
 - /var/www/www.websitename.com/public:/usr/share/nginx/html
 - /var/www/www.websitename.com/etc/nginx/conf.d/:/etc/nginx/conf.d

This will start up an nginx-proxy and another instance of nginx to host the static site. It will also set up a letsencrypt SSL certificate, which is super cool, too.

Important note: if you do not have a domain resolving at the address your server is using do not include the letsencrypt block or the volume link to the letsencrypt certificates, or any of the environment variables that reference letsencrypt. If you do, the site will error-out until the service can verify that the domain is yours and correctly set up.

Make sure you build the server manually at least once before automating the process with the scripts above. This will deploy Hugo to the public directory under our website directory:

docker run --rm --name hugo-production -e HUGO_BASEURL=https://www.websitename.com/ -v /home/serveruser/dropbox/Sites/mysite/src:/src -v /var/www/www.websitename.com/public:/output jojomi/hugo

Start up the web server by issuing the following in the same directory where you created the above docker-compose.yml file:

docker-compose up -d

At this point, you should be able to bring up your website but modifying rebuild.txt will not yet trigger a build because our watcher isn’t running. We’ll use Ubuntu’s systemd to load ~/bin/watch_build at system start time and continue watching for changes.

Create the following under /etc/systemd/system/watch-build.service:

[Unit]
After=docker.service

[Service]
ExecStart=/home/serveruser/bin/watch_build

[Install]
WantedBy=default.target

Modify permissions and enable service:

chmod 744 /home/serveruser/bin/watch_build
chmod 664 /etc/systemd/system/watch-build.service
sudo systemctl daemon-reload
sudo systemctl enable watch-build.service

Start the service with:

sudo systemctl start watch-build.service

If all went according to plan, you can view the status of the loaded service with:

sudo systemctl list-units | grep watch-build

You should see “loaded active running” next to the service name.

That was a lot. With any luck, you can now build your Hugo site by editing src/rebuild.txt in any text editor and you should see the changes live on production within moments. Since your content is stored in Dropbox things will stay in sync, as well, across all your devices.

The Rhizome Telecaster

2015-10-17T00:00:00+00:00

This guitar project was simple but the result is one of the best guitars I’ve ever assembled. I ordered a Warmoth pre-made swamp ash body that features contour cutouts that make it really comfortable. The neck is a custom-ordered slim profile AAA flame maple with ebony top (without dots). The fretboard radius is an unorthodox 12″ that I really like (the classic Telecaster fretboard radius is usually a much rounder 7.5″ to 9.5″).

The bridge is a Callaham Vintage T that gives it a fantastic vintage twang or percussiveness while still being relatively easy to dial in a near-perfect intonation setup.

The pickups are Jason Loller ‘52 T Series, which are hand-wound to 1952 Telecaster specs.

This project strikes a great balance, for me, between modern refinement and classic tone (and aesthetics).

The Sparklemaster Guitar Project

2015-04-13T00:00:00+00:00

This was the first time I’ve tried to paint a guitar that I assembled. Sparkle paint is very difficult to handle. I went through a couple of spray guns and more than one can of Big Daddy Roth Rattlebomb paint, which is usually used for hot-rod and motorcycle builds.

The bridge is a Mastery Offset Bridge with Vibrato. The pickups are Lindy Fralin Hum-cancelling P-90’s. Maple body and neck with rosewood fretboard.

This guitar was sold to a collector in Hong Kong.

Powderbird Helicopter Ski Tours

2015-03-20T00:00:00+00:00

As Technical Director, Lead Programmer and Project Manager on the Powderbird website redesign with Owen Jones & Partners, I had an opportunity to harness a powerful group of technologies to tell this adventure ski tour company’s story with immersive photography, design and copy. I built a flexible CMS to allow for easy management of front-end design, assets and copy, as well as a back-end that handles ski tour reservations and user management.

Guitar Amp Project

2015-03-01T00:00:00+00:00

This project used the “Champ Ultra” chassis from Ceriatone without tubes or transformers, which I sourced and soldered separately.

The head and speaker cabinets are made with hand-cut dovetail-joined maple. The speaker cabinet holds a Celestion Gold 10" speaker.

Case Study: International Institute for Analytics

2015-02-19T00:00:00+00:00

When Jack Phillips and Andrew Lightman met with me at Owen Jones to kick off development of the new IIA website, I knew immediately that their level of engagement was going to have a hugely positive influence on the project. When stakeholders participate in discovery and stay engaged throughout a project, from requirements-gathering through development and testing, it has a much greater chance of being successful than those lacking that kind of engagement.

Overcoming Technical Biases

At first, the rewards I was seeking weren’t centered in the client’s needs. From a technical perspective, I was hoping there was going to be a richer feature-set than that typically met by an off-the-shelf CMS solution. My interest was in building a custom website that would address complex features and provide rich technical challenges and engineering experience.

This is why initial requirements-gathering sessions are so important. By listening to the customer – by listening to each other – we agreed that the best solution was to go with a PHP-based CMS with a rich feature set. I was able to overcome biases I was barely capable of acknowledging and feel solid about the best direction for the project. Only after weighing the benefits and drawbacks of each approach with the customer could I really see this. Best of all, the client felt informed and positive about the technical direction, as well.

Meeting Creative Challenges

Would an agency with a deeply creative spirit like Owen Jones be a good fit for a data-driven business analytics company? What imagery and visual elements could we employ to elevate the experience? How could we organize the content in such a way that the visual hierarchy of each page represented the hierarchy of business objectives?

These, of course, are the kind of questions people often ask themselves at creative agencies, especially when confronted with the challenge of creating brand experiences for clients in market segments that don’t easily translate to visual solutions.

The branding and creative direction developed by Brandy Shearer set a great tone for the site, with well-balanced typographic choices and emblematic image treatment. But beyond the visual solutions put in place, the underlying creative collaboration and discovery between our two teams amounted to a truly creative outcome and a great, highly usable final product.

Results

The new site saw a definitive increase in traffic in the first year after deployment. The publishing and editorial workflows that contributors and editors relied on were greatly improved, as well. Out-of-date and buggy plug-ins no longer plagued site administrators, and security was also greatly improved.

Equally important was the fact that both teams found success working with, and learning from, each other throughout the highly collaborative project.

Hand-built Modular Synthesizer Case

2015-01-13T00:00:00+00:00

This hand-built case is dovetailed walnut. The juxtaposition between the organic and space-race aesthetic is what made this project appealing. It houses a combination of Verbos Electronics and Make Noise modules. The sounds it makes seem to be limitless.

Case Study: Adobe Community Building Tool

2014-10-02T00:00:00+00:00

This internal project with Owen Jones & Partners was one of the more fun projects I had the opportunity to work on with Adobe. I was able to apply a test-driven development approach to building an experience that was easy, fast and intuitive to use. The goal was to build a community platform where students could post videos, photos and written content, and be rated by program managers, who could communicate back through a custom messaging system. mini-Facebook with a scoring algorithm.

Unstuck iPad App

2012-09-10T00:00:00+00:00

This native iOS app was written in Objective-C. A significant portion of the work focused on fine tuning the movement of various text and graphical elements across multiple pages. The project was particularly well suited for the screen-by-screen approach to becoming “unstuck.”

Struck Redesign

2012-04-10T22:08:22+00:00

Looking back at the Struck website redesign I worked on in 2012, it’s interesting to compare favorably the refinements of today’s site over the original. Much of the design has been cleaned up and, I think, improved. However, the core layout and lazy-loading functionality remains very much intact today, which feels like a testament to the underlying technology stack and implementation I chose as Technical Director. In addition to managing the project, I was responsible for the front-end development work on the site, and helping guide the Rails development.