joeybaker

couchdb setup

• create an admin user
• then

couch_httpd_auth
    require_valid_user = true
couchdb
    delayed_commits = false
couch_httpd_auth

joeybaker

new ubuntu server

# add a non-root user
sudo adduser <username> sudo
su <username>
# paste in your ssh key
# ssh-copy-id -i <username>@<host> 
sudo vi /etc/ssh/sshd_config
# set PasswordAuthentication no

joeybaker

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
        Created by Manifold
--><service_bundle type="manifest" name="bud">

    <service name="bud" type="service" version="1">

        <create_default_instance enabled="true"/>

joeybaker

I'm a big fan of github flow. Which basically states that you should create a branch for each feature, then merge it into master only when it's ready to push to production. However, github flow is a bit ambiguous about how to resolve conflicts between your feature branch and master. What follows is a method of dealing with that problem.

• Anything in the master branch is deployable
• To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into master

• a really good addition: how to merge into master. Here's why

joeybaker

# print all the titles in the db
strings -a -t x id_stor  | pcregrep -M '[a-z0-9]{1,9}\stitles\[\n[a-z0-9]{1,9}\s(.*?)u$' | grep -v 'titles' | cut -d " " -f 2- | sort | uniq | sed 's/u$//' | sed 's/://' | sed 's/\///' > couchpotato_export.txt

# get all current movies
# note: with GNU sed, the `sed -E` should be `sed -r`
ls /Volumes/raid6/Movies | sed 's/ ([0-9][0-9][0-9][0-9])//' | sed -E 's/(.*), The/The \1/' | sort > movie_files.txt

# get the wanted movies
grep -v -f couchpotato_export.txt movie_files.txt

joeybaker

SSL terminators

• good general SSL tips
  • don't use a wildcard cert. We'll need to buy certs for staging + prod + futon
  • can probably safely limit to tls 1.2
• what is SNI?
• istlsfastyet ← good comparisons of terminators

Nginx

• compile it from source and other tips

joeybaker

# no sudo for global installs!
sudo chown -R `whoami` ~/.npm; sudo chown -R `whoami` /usr/local/lib/node_modules 

joeybaker

// if the user attempts to navigate away from the page before ajax is complete, warn.
$.ajaxPrefilter(function(/*options, originalOptions, jqXHR*/) {
  window.onbeforeunload = function(){
    return 'Please allow ajax to complete'
  }
})

// remove the warning when AJAX is done
$(document).ajaxComplete(function(){
  window.onbeforeunload = void 0

joeybaker

We're going to refactor a library to make it more usable. The intention is to get the code to a point where it's a reusable component.

The library to refactor is: https://github.com/01miru/fileuploaderjs

ToDo List

This is a non-comprehensive list of things to do:

• Convert to use jQuery instead of native browser code where possible
• Add tests
• Convert it UMD. Don't pollute the global scope.

joeybaker

Build a re-usable HTML component that allows a user to submit a bug report about the page they're viewing.

• The client-side component should be standalone, and easily re-usable in wider app. It's okay to require a framework(s), but dependencies must be easy to manage.
• Also build out a server that can receive these bugs, parse them, and send them to the Github API as new issues. You can use whatever server environment you'd like.
• To enable the github API, you should probably create a new repo. Alternatively you can mock out the Github API responses.

You should build this as if you were going to put it into production: optimize for code quality over quantity, write tests as appropriate, and so on.

It's fine if you don't actually finish.