Kyle Manchee

Simple Cedar Key Rack

2021-02-06T13:54:32+00:00

This was a quick and simple project to add a key rack by our main entrance.

Finished key rack

There’s not a lot of space at our side door (our most heavily used door) and no place to put even a small key rack. There is however a 6” beam directly beside the entrance. I thought a small vertical key rack could fit here nicely.

The rack is made from some scrap cedar I had lying around. I finished it with some water based varathane. The hooks are simple cup hooks. The hole process could be summarzied by: 1. find piece of wood, 2. screw hooks said wood. But why not, let go into excessive detail.

I started by measuring our keys…. since they will hang vertically there is the potential to block lower hooks if they are spaced too closely. I found that a 4” separation would probably work. For a 4-hook rack that’s 3x4” plus an inch on each end for a total of about 14” in length. I cut this from stock 1”x3” cedar.

To add a little pizazz I used a router to edge the piece. Also, this is the only thing that differentiates the piece from simply a strategically cut chunk of wood. I used an ogee bit (those s-shaped ones) with ~1/4” diameter to give this nice rounded finish. Very regal. Very fancy.

While I personally like the look and feel of the unfinished cedar, I decided to protect it with two coats of water based varathane. This will help avoid scratch and just protect it a little (protect from what I do not know). I prepped by sanding the face to 220 grit with a detail sander. I carefully sanded the edges by hand. Two coats of varathane sealer and we’re done.

At this point I had not bought the hooks yet, so I just marked out their locations and mounted the rack. I predrilled and countersunk the screw holes and mounted the rack directly into a stud - not that it is needed for this, anchors would be fine, it was just coincidence with the mounting location.

The hooks were the only thing I purchased directly for this project. They were $2.50 from HD. I went for the darker antique finish, just ‘cause. As I said I had pre-marked the locations, so finishing this was as simple as screwing in the hooks.

Protip: predrill hole for this type of delicate hook - even in a soft wood such as cedar. One of the hooks hit a knot and I broke it off trying to screw it in. Luckily I was able to drill and mount a replacement directly beside the broken stub and it is concealed pretty well. But just avoid this possibility and pre drill.

So far the rack has performing honourably, and we no longer have to rifle through a drawer to find our keys!

Building a shed

2020-09-01T23:13:32+00:00

This spring I built an open-faced shed in our yard, primarily as a convenient shelter to store out bikes.

Motivation

We moved into a new house in early spring. Our backyard was an absolute disaster, including a massive garbage/brush pile in one corner. This is the corner that joins the end of our driveway and the streetside property line (we are on a corner lot). It is a perfect nook to fit a small shed. Plus, building the shed here offers a little more privacy from the street.

The finished shed is 4ftx10ft, and is about 7ft tall. It features a green, or living, roof, which come spring will be complete with an array of local greenery.

All in the project cost a few hundred dollars, though unfortunately I don’t have a detailed breakdown. Most of the build was completed late spring/early summer 2020. Lumber prices had begun to rise and availability was an issue at times, but not as crazy as late 2020 - thankfully.

Laying the foundation

The soil here is hard clay, and the location slopes gently parallel to the fenceline. For simplicity, and because this is just a shed, I decided to use a skid foundation. This consists of three treated 10ft 4x4’s (skids) laying directly on the ground. A layer of stone/rock under each skid helps to remove moisture from the wood foundation (despite the skids being treated, prolonged direct contant with the wet soil will eventually rot the wood).

A skid foundation is simple and easy to build, but it is also susceptibile to heaving from frost. Re-level the skids after a particularly eventful spring is not too big of a job, though.

First I had to dig out the site to get it close to level. It is crucial that the skids are as close to level as possible, and the easiest way to acheive this is to make the ground level. I then layed three trenchs filled with small gravel and stone, all of which I removed from my flower beds (a story for another time).

The base frame sits directly on the three skids. It’s built from PT 2x6’s. The decking is simply 3/4” PT ply.

4 3 walls…

I wanted to keep the front of the shed completely open, so I needed two 4ft side walls and a single 10ft rear wall. There were a couple factors that went into determining the the shed height. First, I wanted the enterance to the shed to be high enough such that I didn’t need to worry about smashing my head (I’m no shorty, peaking out around 6’2”). Second, the slope of the roof needed to be relatively small, for future green-thumb reasons. I settles on a wall height of 6ft. This would be the same for both side walls and the rear wall. The front entereance woud be lifted by 6 inches, for a clearance of 6’6” - enough buffer for my head. This is a roof slope of 6” over 4’, or 1.5:12, or 12.5%… or about 7 degrees.

Excellent.

I used untreated framing lumber for the frame. It is mostly protected from the elements, and is elevated off the ground, which should offer enough protection against moisture and decay.

The framing will be visible so I spaced the studs symmetrically along the back wall. This required more cuts for the siding since I couln’t use stock lumber lengths. All-in-all I only had to buy a couple extra pieces and I think it was worth it for the symmetry!

I secured the frame to the based with screws along the base plate. I leveled and squared each side and held them temporarily in place with some cross-bracing. Eventually these would be removed when the siding went up.

The front of the shed is framed by two treated 4x4’s. These are 6’6” tall and the header sits directly atop them. I made the header by laminating two treated 2x6’s. The span is 10ft, which may be a little large given the future roof load. In the winter, when there is significant snow loads, I slip in a third 4x4 support in the middle. This is mostly just precautionary. In the future I may try to beaf up the header, or make the center post permanent.

…and a roof

While the footprint of the shed is 4ftx10ft, the roof is 6ftx12ft, to give about a foot of overhang on each side. First I cut all the rafters to length and angle. Then I knotched out a pair of birdmouth cuts on each so they could sit flush on the rearwall top plate and header. I used 2x4’s for the rafters since the span isn’t very long. I made a bare-bones frame on the ground, hoisted it into place (working on my lonesome, so this had to be light), and assembled the remaining rafters in place.

Rafters were spaced symmetrically, ensuring proper alignment with the roof sheathing. I used three sections of 4’x6’ 1/2” treated ply for the roof, so rafters had to fall at 48” and 96” centers.

I added an 8” facer around the perimeter of the roof. This both serves as a sidewall for the future roof-top fun, and cleans up the exterior look of the roof line. You can see in the picture below that I shaved off the end of the facer side boards so that they met flush with the top of the front boards.

The future fun I have planned for this shed is a green living roof. The top will be filled with top soil and various local grassed, shrubs, flowers, etc. The completion of the green roof will be covered in another post, but for now you can see how the facer board enclosed the roof-top. From here a waterproof membrane will be layed, followed by garden fabric and topsoil. Most green roofs recommend a few inches depth to provided adequate root binding. The 8” facer gives a 3-4” depth, which should be perfect.

Siding

The siding for the shed is super simple. I didn’t want sheath the entirety in OSB, then side the exterior with a facade. I don’t like the look, and since the shed is not weatherproof by design, there is no need. I wanted a simple siding that adds some character. I opted to use 1x6 treated fence boards that I mounted horizontally.

My local lumber store stocked 5ft boards, which was perfect for the rear wall (10ft in length). I trimmed the seams with vertical boards. I really like this finished look.

For the sides I just had to cut to length as there were no 4ft or 8ft boards available. This left a little waste, but it was pretty minimal, plus I made use of some of it by making some planter rack for the sides. I used two 1ft offcuts for the face, and trimmed a few small pieces as spacers from the shed sides. These little guys work perfect for hanging planters - the type you would hang from a railing. Hopefully next summer we will get some herbs in here.

As the siding boards dried and shrank, small gaps formed between the boards. Not big enough for rain or snow to get through, but large enough that you can see slits of light. I think it works with the overall style of the shed. And again, it is open faced, so it’s not like the thing was weather proof to start.

Done for now

That concludes the main build of the shed. So far it has treated us well and has been used quite a lot. It has also stood it’s ground against some pretty fierce storms.

Next spring I’ll be finishing off the roof by planting some greenery. It should be an interesting addition to the project. There will be more details and pictures when that happens.

The one true triathlon distance

2019-08-15T00:55:32+00:00

I have created a web-scraping tool to pull athlete result data from Ironman triathlon events. Using some of this data I’d like to do some simple analysis on the relative distances and finishing times of the three disciplines in triathlon: swim, bike run. In the end, I would like to come up with a ‘natural’ distance for each disciplines, where each is equally weighted in the event.

A brief look at finishing times

Using the associated Ironman data-scrapper, the event data for Ironman Canada 2019 (held in Mt. Tremblant) will be used for demonstration. We can see the general structure of the data below. The data pulled from the Ironman site is athlete-specific and quite granular, including all split times and ranks for each individual.

import pandas as pd
import time

event_folder = 'data/canada140/'
ad = pd.read_csv(event_folder+'data.csv')
ad.head()

	link	name	bib	division	age	state	country	profession	points	overall_rank	...	gender_rank	swim_time	bike_time	run_time	total_time	swim_racetime	bike_racetime	run_racetime	t1_time	t2_time
0	https://www.ironman.com/triathlon/events/ameri...	Raynard Picard	139	35-39	39	CA	MEX	---	5000	1.0	...	1.0	3577.0	17389.0	11612.0	32966.0	3577.0	21193.0	32966.0	227.0	161.0
1	https://www.ironman.com/triathlon/events/ameri...	James Curran	211	35-39	34	Munster	IRL	---	4948	2.0	...	2.0	3820.0	17904.0	11172.0	33224.0	3820.0	21907.0	33224.0	183.0	145.0
2	https://www.ironman.com/triathlon/events/ameri...	Reid Foster	130	30-34	33	OK	USA	---	5000	3.0	...	3.0	3437.0	17605.0	11834.0	33242.0	3437.0	21238.0	33242.0	196.0	170.0
3	https://www.ironman.com/triathlon/events/ameri...	Heather Wurtele	3	PRO	40	BC	CAN	---	5000	4.0	...	1.0	3198.0	18107.0	12084.0	33641.0	3198.0	21429.0	33641.0	124.0	128.0
4	https://www.ironman.com/triathlon/events/ameri...	Karel Sumbal	145	40-44	42	SC	CZE	---	5000	5.0	...	4.0	3510.0	19025.0	11043.0	33913.0	3510.0	22730.0	33913.0	195.0	140.0

5 rows × 21 columns

print('There are {:d} athlete entries.'.format(len(ad.index)))

There are 1489 athlete entries.

Each athlete entry (row) includes a direct link to it’s results page, along with detailed race data. All time-based columns are in units of seconds. First, let’s look at the finishing times of all the athletes.

import matplotlib.pyplot as plt
import seaborn as sns
import numpy as np

sns.distplot(ad.total_time.dropna())

<matplotlib.axes._subplots.AxesSubplot at 0x18208617d0>

Notice the irregular distribution shape and the truncation for long time. This is atleast partially due to the hard time limit of the event (17hrs or 61200s). Additionally, each dicipline has it own cut-off time.

print('The average and median total times are ' + time.strftime('%Hhrs %Mmin %Ss', time.gmtime(np.mean(ad.total_time))) +
     ' and '+ time.strftime('%Hhrs %Mmin %Ss', time.gmtime(np.median(ad.total_time.dropna()))) +
     '. The standard deviation of the distribution is ' +time.strftime('%Hhrs %Mmin %Ss', time.gmtime(np.std(ad.total_time))) + '.') 

The average and median total times are 13hrs 21min 41s and 13hrs 23min 51s. The standard deviation of the distribution is 01hrs 46min 57s.

f, ax = plt.subplots(1,3,figsize=(12, 3))
plt.setp(ax, yticks=[])
sns.set(style="white", palette="muted", color_codes=True)
sns.despine(left=True)
sns.distplot(ad.swim_time.dropna(), color='b',ax=ax[0])
sns.distplot(ad.bike_time.dropna(), color='g',ax=ax[1])
sns.distplot(ad.run_time.dropna(), color='r',ax=ax[2])

<matplotlib.axes._subplots.AxesSubplot at 0x1a214a4210>

The event cut-off times for the swim, bike, and run are 2hrs 20min (8400s), 8hrs 10min (29400s), and 6hrs 30min (23400s) respectively. Some individual times may exceed this limit, but the athlete would not be permitted to continue to the next dicipline.

print([(np.mean(time), np.median(time.dropna()), np.std(time), np.std(time)/np.mean(time)) for time in [ad.swim_time,ad.bike_time,ad.run_time]])

[(4839.948738812042, 4765.0, 823.7251282290428, 0.17019294473586197), (24268.259509721047, 24194.0, 3001.649341671252, 0.12368622234606039), (18234.61800699301, 18085.5, 3351.7988083726937, 0.18381513706990038)]

An interesting feature of the plots above is that while the swim times produce the narrowest distribution, they are not the least variable with respect to the mean. The swim time standard deviation is 17.0% of the average swim time, compared to 12.4% for the bike, and 18.4% for the run. The run result at least is expected, since it is the last dicipline of a gruelling event. With the body exhausted it is natural to expect significant variability in finishing times.

f, ax = plt.subplots(1,2,figsize=(14, 8))
sns.swarmplot(data=ad.iloc[:,12:15],size=2, color=".3", linewidth=0, ax=ax[0])
sns.boxplot(data=ad.iloc[:,12:15], whis="range", ax=ax[0])
sns.boxplot(x='total_time', y='country', data=ad, ax=ax[1])

A natural triathlon distance

The Ironman triathlon, sometimes referred to as a 140.6, consists of a 3.86km swim, 180.25km bike, and 42.20km run. Added together the event is 226.3km, or 140.6 miles (hence the name). As shown above, the bike portion of the race is heavily weighted, averaging for more than half the total race time. While one could contemplate and debate the merits of this with respect to the sport of triathlon, I am curious what a more evenly weighted race looks like. Presumably there would be less emphasis on the bike, likely being shifted to the swim - but to what extent?

The total event distance $d_{event}$ is simply the sum of the dicipline distances: $d_{event} = d_{swim} + d_{bike} + d_{run}$

d_ims = 3.86; d_imb = 180.25; d_imr = 42.2; d_im = d_ims + d_imb + d_imr

Weighting schemes for dicipline distances

For the purposes of this analysis we will hold the total event distance constant ($d_{event} = D_T = 226.3 km$). This leaves us to choose conditions for the weighting of each dicipline. We will investigate a few weighting schemes now. In each case, the dicipline distance is characterized by it weight, $W_i$: $d_i = W_iD_{T}$ The weights must be normalized, therefore: $\sum W_i = 1$

The Ironman 140.3 uses relative distances of 1:46.7:10.9 for $d_{swim}:d_{bike}:d_{run}$, resulting in weights of: 0.017, 0.796, and 0.186.

Equal weighting

A simple scheme is to simply weight all diciplines equally: $W_i = \frac{1}{N} = \frac{1}{3}.$ The resulting dicipline distance is $226.3/3 = 75.4 km$.

w_s = w_b = w_r = 1/3
print('The dicipline distances are swim = {:.1f}km, bike = {:.1f}km, run = {:.1f}km.'.format(*[w*d_im for w in [w_s,w_b,w_r]]))

The dicipline distances are swim = 75.4km, bike = 75.4km, run = 75.4km.

This is a trivially absurd example considering a ‘marathon’ swim is typically expressed as $10 km$, i.e. the event would consist of 8 consecutive marathon swim, capped by two marathon runs. Meanwhile, the bike distance is nothing a a casual Sunday rider couldn’t handle. While this example is silly, it does suggest the next weighting scheme: time-weighted distances.

Time weighting

Time (or speed) weighting may be the first ‘natural’ choice for determining dicipline distances. The premise is that each dicipline should take roughly the same amount of time to complete. On an individual basis this almost certainly will not hold true, but if instead we consider the entire field we can determine a weighting scheme that will satisfy the equal-time criterion.

Once again, we are using the Ironman Canada 2019 data as a test-case. The mean split swim/bike/run times in this event were:

print('{:.2f}, {:.2f}, {:.2f} hours, respectively.'.format(*[np.mean(time)/(60*60) for time in [ad.swim_time,ad.bike_time,ad.run_time]]))

1.34, 6.74, 5.07 hours, respectively.

The average split time for each dicipline is given simply by $t_i = \frac{d_i}{v_i}$, where $v_i$ is the average speed for the split. Since $d_i = W_i D_{T}$, the split time can be written as: $t_i = \frac{W_i}{v_i}D_T$ and the dicipline weights written as: $W_i = \frac{v_i t_i}{D_T}.$

If we enforce the condition that split times must be equal, $t_i = t_{swim} = t_{bike} = t_{run} = T$, then we see that, since $T$ and $D_T$ are constant, the weights are proportional to the average speed.

We can express the normalized weights, $W_i$, in a slightly different manner: $W_i = \frac{w_i}{\sum w_i},$ where $w_i$ are unnormalized and the sum in the denominator serves as the normalization constant. Using this notation it is simple to see that in the case of equal-time weighting, $w_i=v_i$, and so: $W_i = \frac{1}{\sum v_i}v_i.$ Evidently, the normalization constant is $\frac{1}{\sum v_i}=\frac{T}{D_T} = A$.

The average swim, bike, and run speeds (from IronmanCanada 2019) are:

v = np.array([(x*1000)/(np.mean(time)) for (x,time) in zip([d_ims,d_imb,d_imr],[ad.swim_time,ad.bike_time,ad.run_time])])
print('{:.2f}, {:.2f}, {:.2f} m/s, respectively.'.format(*v))

0.80, 7.43, 2.31 m/s, respectively.

A = 1/np.sum(v)
W = A*v
d = d_im*W
t_e = 3*(A*1000)*d_im
print('Normalization A: {:.3f} s/m'.format(A))
print('Weights:\n\tSwim: {:.3f}\n\tBike: {:.3f}\n\tRun: {:.3f}'.format(*W))
print('Distances: {} km total\n\tSwim: {:.2f} km\n\tBike: {:.2f} km\n\tRun: {:.2f} km'.format(d_im,*d))
print('Total average time: {:.1f} hrs'.format(t_e/(60*60)))

Normalization A: 0.095 s/m
Weights:
	Swim: 0.076
	Bike: 0.705
	Run: 0.220
Distances: 226.31 km total
	Swim: 17.13 km
	Bike: 159.49 km
	Run: 49.69 km
Total average time: 17.9 hrs

The resulting dicipline distances for this time-weighted scheme are 17.1 km, 159.5 km, and 49.7 km, for the swim, bike, and run, respectively. Expressed as ratios this is 1:9.3:2.9. This leads to an average event time of 17.9 hrs. If we scale the event down to the current average finishing time (13hrs 21min 41s), the distances become:

t_im = np.mean(ad.total_time-(ad.t1_time+ad.t2_time))
C = t_im/t_e
d_scaled = C*d
d_e = d_im*C
print('Distances: {:.2f} km total\n\tSwim: {:.2f} km\n\tBike: {:.2f} km\n\tRun: {:.2f} km'.format(d_e,*d_scaled))

Distances: 165.85 km total
	Swim: 12.55 km
	Bike: 116.88 km
	Run: 36.42 km

These results are starting to look realistic. The swim, though more than four times the current Ironman distance, is only slightly longer than an Olympic marathon swim. While this on it’s own isn’t an issue, organizers may view (and rightly so) an average of 4+hrs in the water as a significant safety risk.

Equal-opportunity weighting

The time-weighted approached discussed previously foccuses on equalizing the time of each segment. On the surface, this may seems like the most fair option to specialists of each dicipline, i.e. a strong swimmer would have the same advantage as a strong runner. However, since the distribution of paces in each dicipline is not uniform, this is not true. This is highlighted by the normalized dicipline finishing times shown below:

sns.distplot(ad.swim_time.dropna()/np.mean(ad.swim_time.dropna()), color='b')
sns.distplot(ad.bike_time.dropna()/np.mean(ad.bike_time.dropna()), color='g')
sns.distplot(ad.run_time.dropna()/np.mean(ad.run_time.dropna()), color='r')

<matplotlib.axes._subplots.AxesSubplot at 0x1a21c72110>

Evidently, the bike is the most narrowly distributed segment, followed by the swim, then run. This means a relatively strong biker will gain less time, relatively (i.e. time_gained/time_total) than a relatively strong swimmer or runner. The equal-opportunity weighting scheme will assign distances such that the time gained/lost to the field by a given athelete is consistent accross all diciplines for atheletes of the same relative skill level.

Clearly, the distributions above are not perfectly Gaussian, but they are relatively normally distributed. They are (essentially) single-mode and not significantly asymmetric. The mean and median do not differ by more than 1.5% (swim). A reasonable proxy for the discipline variability is the standard deviation of the distribution.

\[w_i = \frac{t_i}{\sigma_i}v_i = \frac{d_i}{\sigma_i}.\]

The term $\frac{\sigma_i}{t_i}$ is the standard deviation of the distribution relative to the mean:

print('Relative standard deviation\nSwim: {:.3f}\nBike: {:.3f}\nRun: {:.3f}'.format(*[np.std(time.dropna())/np.mean(time) for time in [ad.swim_time,ad.bike_time,ad.run_time]]))

Relative standard deviation
Swim: 0.170
Bike: 0.124
Run: 0.184

w = np.array([dist/np.std(time.dropna()) for dist,time in zip([d_ims,d_imb,d_imr],[ad.swim_time,ad.bike_time,ad.run_time])])
A = 1/(sum(w))
W = A*w
d = d_im*W
t_e = np.sum((d*1000)/v)
print('Weights:\n\tSwim: {:.3f}\n\tBike: {:.3f}\n\tRun: {:.3f}'.format(*W))
print('Distances: {} km total\n\tSwim: {:.2f} km\n\tBike: {:.2f} km\n\tRun: {:.2f} km'.format(d_im,*d))
print('Total average time: {:.1f} hrs'.format(t_e/(60*60)))

Weights:
	Swim: 0.061
	Bike: 0.777
	Run: 0.163
Distances: 226.31 km total
	Swim: 13.71 km
	Bike: 175.75 km
	Run: 36.85 km
Total average time: 15.8 hrs

Surprisingly, this treatment results in an increase of the swim distance at the expense of the run distance.

Time-gained weight

The strategy above can be treated more analytically. The time-gained in a dicipline is: $t_g = t - t_0 = \frac{d_0}{v_0}-\frac{d_0}{v}$

w = np.array([v0*(1-(np.mean(time)/np.std(time.dropna()))) for v0,time in zip(v,[ad.swim_time,ad.bike_time,ad.run_time])])
A = 1/(sum(w))
W = A*w
d = d_im*W
t_e = np.sum((d*1000)/v)
print('Weights:\n\tSwim: {:.3f}\n\tBike: {:.3f}\n\tRun: {:.3f}'.format(*W))
print('Distances: {} km total\n\tSwim: {:.2f} km\n\tBike: {:.2f} km\n\tRun: {:.2f} km'.format(d_im,*d))
print('Total average time: {:.1f} hrs'.format(t_e/(60*60)))

Weights:
	Swim: 0.058
	Bike: 0.788
	Run: 0.154
Distances: 226.31 km total
	Swim: 13.18 km
	Bike: 178.31 km
	Run: 34.82 km
Total average time: 15.4 hrs

data = ad.swim_time.dropna()
kde = sns.kdeplot(data)
x,y = kde.get_lines()[0].get_data()
imax = np.argmax(y)
plt.vlines([x[imax],np.mean(data),np.median(data)],0,np.max(y), color=['r','k','g'])

<matplotlib.collections.LineCollection at 0x1a21c23c50>

sns.distplot((ad.t1_time+ad.t2_time).dropna())

<matplotlib.axes._subplots.AxesSubplot at 0x1a21d8ac50>

Flask deployment on Heroku

2019-05-31T17:27:01+00:00

You’ve developed a Flask app locally. It runs, and you are at the point that you’d like to publish to the web. Or get the ball rolling, at least. It is time for deployment. Unlike static a webpage, a Flask app requires significant computing power in order to run: Python, and all the app’s package bependencies, must be available on the host server, and, rather importantly, dedicating processing resources (CPU) and hard disk storage may be required. If your app utilizes a database, this must be stored on the host server and be readily accessible at all times.

If you have the required experience, you may opt to run your own Linux server to host your app. While not particulary difficult, this option does require a decent amount of background knowledge and manual maintenance. Fortunately, there is a better way. Several third-party cloud hosting companies now offer app hosting services, typically branded as Platform as a Service (PaaS). These services offer dedicated storage and computing resources specifically for app deployment. Many also offer manageed database solutions and a variety of other cloud-based services. Popular PaaS clients include Amazon Web Services (AWS), Google Cloud Services (GCS), and Heroku. The offerings and pricing scheme from each provider varies slight, but most offer a free (or nearly-free) option for low-use or hobby-level web applications.

Here I will run through the process required to deploy your app to a Heroku server. This will include configuring the Heroku app, migrating your database to the Heroku platform, and deploying your app to the web.

Heroku

Heroku is a very popular PaaS. It is a flexible platform with capabilities for the deployment of a variety of app languages including: Ruby, Java, Node.js, and importantly Python. Heroku is a tiered service, allowing you to customize the computing power and storage dedicated to your app. For low-demand apps there is a hobby-level tier, which is free and sufficient for most individual needs.

Heroku allows for deployment through Git. This is extremely convienient as updating your deployed app can be as simple as pushing your git commit to the Heroku server. Heroku also offers continuous deployment via GitHub. If your app is stored in a GitHub repository then the Heroku app is updated whenever a commit is pushed to the monitored branch. Easy. I’ll assume your app is stored in a git repository.

Heroku account and CLI

I you don’t have on already, begin by signing up for a Heroku account. For now you can select all of the free options. You may need to enter a credit card for some services or verification, but unless you are scaling up your app you should be able to use the free tier for everything shown here.

Most (if not all) of the setup can be performed on the Heroku web interface, however Heroku also offers a command-line-interface (CLI) which can be utilized, for example, in the Mac OS terminal. Installation commands can be found here. To install the Heroku CLI on a Mac OS system run the terminal command (requires Homebrew)

brew tap heroku/brew && brew install heroku

Once you’ve created a Heroku account and the CLI is installed you can login using

heroku login

This will open a browser window for you to enter you Heroku account details. You should only need to do this once, after which your authenticated status is rememebred.

Create a Heroku app

Again, this can be performed (rather intuitively) using the web interface. Alternatively, using the CLI you can create a Heroku app using

heroku apps:create <your_app_name>

The name of your app must be unique globally as it serves as a unique identifier of your app in the Heroku system (it is also the default domain of you app once deployed: https://.herokuapp.com)

You may also wish to create a Heroku Pipeline and add you app to it. A Pipeline is a sort of workflow, useful for dealing with larger projects with multiple apps. You may find it useful, but it isn’t necessary.

Web server

Use gunicorn

pip install gunicorn

Install Postgres

Also need psycopg2

pip install psycopg2

Will need to install Postgres before installing psycopg2, otherwise the install will fail due to missing dependencies.

Requirements and Procfile

Heroku needs a requirements.txt file in order to install the needed Python packages for your app. While in your app main directory

pip freeze > requirements.txt

Heroku also needs a custom Procfile, which give a list of commands to execute when the app is deployed.

web: flask db upgrade; gunicorn <your-app>:app

This upgrades the database and starts the gunicorn server for your app. <your-app> is the name of your main .py file and app is the assignmnt of create_app() in this file.

Transfer database data

Heroku utillizes the PostgreSQL database structure. If you have been using this in development then transfering your data to the Heroku database is simple (proceed directly to pg:push). However, you may have been using MySQL, or SQLite during development, in which case migrating your database is slightly more complicated.

There are a few migration tools which can accomplish this task, such as pgloader, or the Ruby gem sequel. I’ve had issues using pgloader to migrate from SQLite where primary key squences are not initialized properly (the result is an attempted null insertion as a primary key when making a new database entry, which is not allowed in Postgres), so I’d recommend using sequel instead for this task.

Provided you have ruby, rubygems, and postgres installed, as well as the relavent postgres-dev and sqlite3-dev libraries, you can install sequel by running

gem install sequel pg sqlite3

Next, I’ll create a new, empty postgres database and fill it with data from my SQLite database used in development.

createdb newdb
sequel -C sqlite://app.db postgres://localhost/newdb

Here I’ve assumed we are in the local directory containing the development SQLite dabase named app.db. In general this portion of the command can be written using the relative path to your .db file: sqlite://<path-to-sqlite-db>.

Once this transfer is complete you can use Heroku’s pg:push command to push your newly-populated local posgres database to your Heroku postgrea database. In order to push data to a Heroku database, the database must be empty. If your Heroku database is not empty you must reset it

heroku pg:reset -a <your-app-name>

This is a destructive process that deletes all of the data in your Heroku database. Take necessary precautions! Now you can perform the push

heroku pg:push newdb DATABASE_URL <your-app-name>

That’s it - you’re set. Note that DATABASE_URL is the environment variable pointing to your Heroku postgres database. Heroku will interpret this variable properly, so you don’t need to copy/paste an actual url.