#indiewebcamp 2012-11-15

2012-11-15 UTC
dascher, tantek, tantek_, friedcell, barnabywalters, morrocco_mole, spinnerin and zztr joined the channel
#
aaronpk
tantek: thought you'd get a kick out of this: http://www.reinventingemail.com/ "Email was not designed to be used the way we use it now.
#
aaronpk
Email is not a messaging protocol. It's a todo list."
#
tantek
or rather the Paul Graham quote
#
tantek
email is not a to-do list, because you wouldn't let just any random person put something in your to do list would you? whereas random people can put things in your email inbox.
#
aaronpk
have you quoted that online somewhere before?
#
tantek
no - the page itself attributes it to paul graham
#
tantek
likely from one of his blog posts
#
aaronpk
no I mean your response
#
tantek
oh let me check
#
tantek
my wiki
#
tantek
here, this is close (though I didn't use the exact phrase "to-do list") tantek.com/w/EmailHandling#Emailisnotyourinbox
#
aaronpk
ah yea I like the way you just said it
#
tantek
so I'll add some explicit language accordingly then
dascher joined the channel
#
aaronpk
lol. beautiful.
singpolyma joined the channel
#
tantek
aaronpk - while you're here, I had a question of about doing release management, from an indieweb perspective in particular.
#
aaronpk
oh? interesting
#
tantek
real world problems: installing, updating, reverting open source software for an indie web site is currently *too hard* (evidence: Wordpress installs of smart people getting hacked, regularly, to the point where some even revert to Tumblr domain hosting)
#
aaronpk
ah yea, that is a huge problem
#
tantek
use-case: I want to run my own website, with some open source software behind it, and be able to maintain it *easily*, including doing updates when necessary and I want to, and having the option to easily revert in case such updates break something on my site.
#
tantek
as far as I can tell, no one has solved this problem, nor satisfied the use-case
#
tantek
neither in general, nor in the indieweb case
#
tantek
or rather, for the indieweb in particular
#
tantek
e.g., "hire a sysadmin" is not a reasonable answer for the indieweb
#
aaronpk
wordpress has done a pretty good job of the upgrade flow
#
tantek
neither is "adopt sysadminning as a hobby"
#
aaronpk
but I don't think they've done downgrades, which is also important as you pointed out
#
tantek
aaronpk - wordpress has been iteratively improving their upgrade experience, but I wouldn't call it "pretty good"
#
tantek
per the problems mentioned
#
aaronpk
heh, well
#
aaronpk
it's gotten to the point where it takes literally one click to upgrade
#
tantek
*if* everything is configured properly
barnabywalters joined the channel
#
tantek
if you have *any* configuration problems/mistakes, e.g. owners of files/directories are not quite right, then you'll get cryptic error messages, password interfaces, etc.
#
tantek
so no, I don't accept that in the general case
#
tantek
too many people have encountered those kinds of problems
#
aaronpk
and in those situations there is often no recovery path other than command line access
#
tantek
that may be true, however the UI should walk you through that
#
tantek
if that must be the case
#
tantek
also, it's not just "one click"
#
aaronpk
seems like easier deploy systems would be the first step in solving this, like pushing an app to heroku has taken all of the sysadmin burden off of people at this point
#
tantek
they still warn you to backup your database first
#
tantek
until that warning is history, it's not "one click"
#
tantek
yes, the heroku example is a good one to analyze
#
aaronpk
i think the main problem is that people still assume that FTP access is the only way to deploy sites
#
tantek
"they" above being WordPress, not Heroku
#
tantek
I think FTP is a good baseline assumption actually
#
tantek
on two counts:
#
aaronpk
and that will always lead to the problmes you mentioned, cryptic errors that are hard to resolve
#
tantek
1. every web hosting company gives you FTP access
#
tantek
2. everyone can be reasonably easily taught how to FTP (have done it on a number of occasions)
#
aaronpk
I think that between Heroku, AppFog, and now Amazon offering git-push interfaces to launch apps with no knowledge of the underlying filesystem, it's getting more reasonable to leave the FTP method behind
#
tantek
btw, biggest problem with "the heroku way" is that it seems to equate to "depend on heroku.com" - which is obviously a non-starter from a indieweb perspective.
#
tantek
"pushing an app to heroku" is too proprietary essentially
#
aaronpk
yes, but I was using that as an example, and now that there are three companies doing it that way there will undoubtedly be more coming in the future
#
barnabywalters
I have been thinking about this a little recently. One potential option I thought of was to make a native app which offers a GUI for building a project, managing depencencies, modules/plugins/whatever. Then it spits out a folder which you upload via FTP/other transfer mechanism
#
tantek
"doing it that way"? do you mean they all support the "heroku" command line command as documented here? https://devcenter.heroku.com/articles/multiple-environments
#
aaronpk
not literally, but a "git push" deploy structure is a good way to do it IMO
#
barnabywalters
if PHP was being used, the entire project could be spat out into a single .phar file, which is pretty easy to upload
friedcell joined the channel
#
tantek
aaronpk - a "git push" deploy structure depends on the web host having git installed, which is too much of an assumption
#
aaronpk
today it is supported by only a few, but I expect it will become much more common
#
tantek
e.g. my web host doesn't have git installed, and I have no desire to walk down the sysadmin rabbithole of installing git on my web host
#
tantek
same thing can be said about Node.js: today it is supported by only a few, but I expect it will become much more common
#
tantek
but that's not the way to build deployable things today
#
tantek
hence why I started and continue to develop #cassis.js
#
aaronpk
btu you *can* deploy things to Heroku, AppFog, and Amazon today without filesystem access
#
tantek
because I'm not going to wait for Node.js to be available everywhere
#
tantek
people don't pick web hosts because of git push / deployment without filesystem access
#
tantek
people pick web hosts by optimizing for cost
#
tantek
also, the more that you require "works by default" on your web host, the fewer options you have to switch to
#
tantek
in case companies go away, go down, get too expensive, share your private data, whatever
#
tantek
I think part of the indieweb way has to be maintaining low switching costs, and many switching options
#
aaronpk
that's true
#
aaronpk
case in point: eran sent me a .zip file of the oauth.net site, I dropped it onto my server and the oauth.net site was moved over in a matter of minutes
#
tantek
only by commoditizing the services we depend on can we become somewhat independent of them
#
tantek
so he had it setup as static pages then?
#
aaronpk
a super simple php template site
#
tantek
or PHP + static pages?
#
aaronpk
like <?php include('header.php')
#
tantek
right
#
aaronpk
I never even needed to know where he had it hosted
#
tantek
I think that's a good pattern for an indieweb baseline
#
tantek
right!
#
aaronpk
that's a good baseline test
#
tantek
all my currently deployed sites are like that, with maybe just a little more logic in the PHP layer
#
aaronpk
Can your site be toleld into a single file (.zip, .git, .phar, whatever) and deployed on a new host in under 5 minutes?
#
aaronpk
s/toleld/rolled up
#
Loqi
aaronpk meant to say: Can your site be rolled up into a single file (.zip, .git, .phar, whatever) and deployed on a new host in under 5 minutes?
#
tantek
if I zipped my site folder into a single file it would deploy as is
#
tantek
.htaccess included
#
tantek
PHP + Apache are the assumptions it currently makes
#
tantek
and that's true for tantek.com, for H2VX.com, for asin.cc
#
tantek
I was discussing this a bit with kevinmarks last night at the microformats meetup in SF
#
tantek
after my tweets about it last night
#
tantek
or rather about software updating/reverting in general
#
tantek
we IM'd a bit more about it earlier today
#
tantek
he mentioned the heroku stuff
#
tantek
when I pointed out the heroku-specific silo nature of their deployment tool(s) (e.g. "heroku" command line tool), he mentioned www.12factor.net
#
tantek
which I've taken a look at
#
tantek
and my evaluation was that it's a bit heavy-weight for my purposes.
#
tantek
and that I may try to simplify to a way of doing "MVRM" - minimum viable release management.
#
tantek
huh - Google says, No results found for "minimum viable release management"
#
tantek
(in quotes)
#
tantek
time to fix that
#
tantek
whatcha doing Loqi?
spinnerin and dascher joined the channel
#
tantek
aaronpk - are you using Heroku for aaronparecki.com?
#
tantek
or are you managing your site with just git based deploys (independent of any Heroku tools etc.)
#
tantek
uses scp
#
aaronpk
just doing `git pull` on the server for now
#
aaronpk
would like to get something slicker set up, but it's not enough of a problem for me yet
#
aaronpk
going to bed now, talk to you later! (12:30am in Berlin right now)
tantek_ joined the channel
#
tantek_
aaronpk - how do you revert? in case something breaks on your site after a "git pull" and it's not immediately obvious how to fix it?
#
tantek
or do you let it stay broken live while you debug it?
#
aaronpk
I run a copy of my site locally first so I see everything before I launch it
#
aaronpk
if there's an environment difference between my dev setup and production which causes an error, then I either debug live, or if it's going to take < 5 minutes I revert by checking out a previous revision from git
#
tantek
so you have a set of local tests, like checking your home page? or do you have a test suite like posting a note etc.?
#
aaronpk
nah, just spot check things by hand
#
tantek
ok cool. by "checking out a previous revision from git" does that mean you tag/name your revisions in git before you deploy?
#
aaronpk
no, I just look up the hash number
#
tantek
or how do you identify *the* previous revision in git that you had deployed before you updated?
#
tantek
since you might have made many changes in git between deploys
#
aaronpk
memory serves me well in that case
#
tantek
ah ok, you have better memory than me then ;)
#
aaronpk
if i'm doing significatn changes (like adding a new checkin type) then I"ll develop on a branch
#
tantek
makes sense
#
tantek
I'm more worried about the "need to revert" use case
#
tantek
without having to remember what was the exact version running beforehand
#
aaronpk
yea, gets more complicated to formalize that, but certainly possible
#
aaronpk
when i'm doing other ad-hoc deploys of other sites I often `cp -R` the folder to a .bak folder so I can quickly revert if neere
#
aaronpk
not the most elegant, but it works
#
tantek
ah ok - good to know
#
tantek
I figure the easier it is to revert, then the less fear there is in aggressively deploying updates, because if anything *does* go wrong, you can easily/quickly revert.
#
aaronpk
for geoloqi production stuff we spin up a new amazon server for the site and get everything running there, then switch the load balancer over when ready to deploy. reverting is then a matter of switching the load balancer back
#
tantek
so your revert is a delete of the current deploy folder then a renaming of the .bak?
#
tantek
cool.
#
tantek
this is exactly the kind of thing I think we have to document, simplify, etc. for viable indieweb software
#
tantek
there's too much alchemy in release management
#
aaronpk
yes, I should definitely document my different strategies just to get them out on the table
#
tantek
I like the switching load balancer as an atomic action to update/revert
#
tantek
that may be a bit high-end for most indieweb setup/folks, but still good to document it in case someone wants to go that route
#
aaronpk
yea definitely not super portable to different environments, but works well
#
aaronpk
ok gotta head to bed. it's almost 1am in Berlin!
#
tommorris
tantek: so, the simplest solution for tracking deploys in Git is to use `git tag`
#
tommorris
basically tag lets you add a signed pointer to a particular commit
#
tommorris
it's widely used for release management, because you can cryptographically sign the tag with GPG. which is in wide use in Linux distro land.
#
tommorris
on my work project, every day I deploy, I tag like this:
#
tommorris
git tag production
#
tommorris
git tag release-2012-11-15