Doc tweaks

DESIGN.md

@@ -80,7 +80,7 @@ Supporting multiple Python versions can be done by deploying `piku` again under
 
 ## Internals
 
-`piku` uses two `git` repositories for each app: a bare repository for client push, and a clone for deployent (which is efficient in terms of storage since `git` tries to use hardlinks on local clones whenever possible).
+`piku` uses two `git` repositories for each app: a bare repository for client push, and a clone for deployment (which is efficient in terms of storage since `git` tries to use hardlinks on local clones whenever possible).
 
 This separation makes it easier to cope with long/large deployments and restore apps to a pristine condition, since the app will only go live after the deployment clone is reset (via `git checkout -f`).
 

INSTALL.md

@@ -37,7 +37,7 @@ Before running `piku` for the first time, you need to install the following Pyth
 sudo pip install -U click virtualenv
 ```
 
-These may or may not be installed already (`click` usually isn't).
+These may or may not be installed already (`click` usually isn't). For Raspbian this is the preferred approach, since current `apt` packages are fairly outdated.
 
 ## Setting up SSH access
 
@@ -123,7 +123,7 @@ And that's it, you're set. Now to configure [uWSGI][uwsgi], which is what `piku`
 
 ### Raspbian
 
-Since Raspbian's a fairly old distribution by now, its `uwsgi-*` packages are outdated (and depend on Python 2.6), so we have to compile and install our own version, as well as using an old-style `init` script to have it start automatically upon boot.
+Since Raspbian's a fairly old distribution by now, its `uwsgi-*` packages are completely outdated (and depend on Python 2.6), so we have to compile and install our own version, as well as using an old-style `init` script to have it start automatically upon boot.
 
 ```bash
 sudo apt-get install build-essential python-dev libpcre3-dev

README.md

@@ -10,14 +10,15 @@ I kept finding myself wanting an Heroku/CloudFoundry-like way to deploy stuff on
 
 From the bottom up:
 
-- [ ] Support Node deployments (if at all possible in a sane fashion)
-- [ ] `chroot`/namespace isolation
+- [ ] Prebuilt Raspbian image with everything baked in
+- [ ] `chroot`/namespace isolation (tentative)
 - [ ] Proxy deployments to other nodes (build on one box, deploy to many) 
+- [ ] Support Node deployments
 - [ ] Support Clojure/Java deployments
-- [ ] CLI command documentation
-- [ ] Support barebones binary deployments
 - [ ] Sample Go app
 - [ ] Support Go deployments
+- [ ] CLI command documentation
+- [x] Support barebones binary deployments
 - [x] Complete installation instructions (see `INSTALL.md`, which also has a draft of Go installation steps)
 - [x] Installation helper/SSH key setup
 - [x] Worker scaling 
@@ -32,11 +33,11 @@ From the bottom up:
 - [x] Repo creation upon first push
 - [x] Basic understanding of [how `dokku` works](http://off-the-stack.moorman.nu/2013-11-23-how-dokku-works.html)
 
-## Typical Workflow
+## Using `piku``
 
-`piku` aims to support a Heroku-like workflow, like so:
+`piku` supports a Heroku-like workflow, like so:
 
-* Set up an SSH `git` remote pointing to `piku` with the app name as repo name (`git remote add paas piku@server:app1`) 
+* Create a `git` SSH remote pointing to `piku` with the app name as repo name (`git remote add paas piku@server:app1`) 
 * `git push paas master` your code
 * `piku` determines the runtime and installs the dependencies for your app (building whatever's required)
     * For Python, it segregates each app's dependencies into a `virtualenv`
@@ -51,7 +52,7 @@ Later on, I intend to do fancier `dokku`-like stuff like reconfiguring `nginx`,
 `piku` is intended to work in any POSIX-like environment where you have Python, [uWSGI][uwsgi] and SSH, i.e.: 
 Linux, FreeBSD, [Cygwin][cygwin] and the [Windows Subsystem for Linux][wsl].
 
-As a baseline, I intend to make sure this runs on an original, 256MB Rasbperry Pi Model B (which is where I'm testing it).
+As a baseline, this is currently being developed an original, 256MB Rasbperry Pi Model B.
 
 Since I have an ODROID-U2, [a bunch of Pi 2s][raspi-cluster] and a few more ARM boards on the way, it will be tested on a number of places where running `x64` binaries is unfeasible.