What to do before launching v1.0?

I’m launching a rails website, the app is written and works, undoubtedly
it’ll be an unmitigated disaster when I launch but none the less I
thought I’d least attempt to give myself the best chance of success by
asking all the gurus here for some advice – pre launch advice if you
like.
In an ideal world I’d spend days and hours on all of these things and
get it absolutely spot on, but as we all know the world is not ideal and
time is a precious commodity so I’m calling for comment as to which of
these are most important. i.e. what should I do first and spend most
time on!
For context, my initial deployment will be on a shared webhost (a joyent
shared accelerator). If I get a modicum of success I guess in time I’ll
need to move it to a more appropriate product (read, more bandwidth, RAM
capacity etc).
So this is a brain dump of all the tings that I could possibly spend
some time on in the coming days, to basically finish and polish the app
to v1.0. I’d be really grateful for comment.
Sorry for the long post, but I wanted to get few things off my chest in
one go.

- clear down log files
- build a rake task for backups (thinking backing up the database and
any paperclipped images that users have uploaded (cron?) to a tarball
nightly and FTP’ing that tarball off the webhost nightly)
- build in some sort of dynamic error alerting system to email when
errors occur (a la hoptoad / exception_logger / make one)
- clear down as much space as possible on your webhost (breathing space
/ housekeeping)
- clear out as much unused code as possible from the app (make it easier
to maintain)
- comment the app code (yes, I know, should do this while going along)
- write some tests and err test (I can imagine a great number of people
up in arms at this one, ok, I admit it, my app has no tests – reason is
I never learned how, so I haven’t done it – would love to test and
realise the importance but at the moment my testing amounts to me seeing
something break in the browser and fixing it)
- make sure google analystics is working (so real hits can be tracked)
- include at least some metadata making a stab at initial SEO
- backups
- register the site with as many search engines manually as possible
(e.g bing)
- Performance tweaks : tweak all the active record finder methods and
make sure they’re optimised, basically things like don’t find all
records when you don’t need to.
- Performance tweaks: optimise images in photoshop, i.e. reduce file
sizes
- Dump those generic error pages in /public (e.g. the 404, make
something nicer, less generic rails)
- git, my git workflow is simple so far, I do this on my mac “git add .”
“git commit –a –m “some changes” “git push origin master”, then I ssh to
my apps web directory on my host and do “git pull”, life is good. Should
I just keep doing this when the app goes live, I’d like to as it works
but I wonder if I should create some sort of v1.0 (is it called a branch
or a tag or something), maybe I should just continue with my current
workflow with a commit message like “THIS IS IT, V1.0” hehe.
- *** Anything else I haven’t thought of that are real musts before
going live!

[...]

- write some tests and err test (I can imagine a great number of people
up in arms at this one, ok, I admit it, my app has no tests – reason is
I never learned how, so I haven’t done it – would love to test and
realise the importance but at the moment my testing amounts to me seeing
something break in the browser and fixing it)

Start with this one. If you have no tests, you really don't know if
your app works. Write tests *now*, before releasing. Delay your
release date if you have to in order to do this. Then do all new
development test-first.

Ignorance is not an excuse here. There are plenty of people here and
elsewhere who can help you learn. This is vital.

Best,

You've got to start with backup. If you're launching something then
you, your customer or your users are going to rely on their
interactions to be permanent.
Make sure you don't lose client data and then improve your product.

PS. You put it in your list twice so you know it's important :slight_smile:

Andrew Timberlake
http://ramblingsonrails.com

http://MyMvelope.com - The SIMPLE way to manage your savings

slicehost.com for hosting and backup

-- They have bare bones servers and great documentation so you can build
up your server the way you want. You can perform backups on most of the
slices (giant slices you cannot). You can upgrade or downgrade at will
and the process takes only a short while.

Testing

You have a lot of different ways to test your app. You can use the
default testunits, or go with Rspec, Autotest, Shoulda to name a few.
Just keyword any of those in google and you'll be on your way.

Diagraming

I purchased a dry eraser board - did wonders for me. It doesn't matter
what you use so long as you can create a larger than life diagram of
your app that you can add/adjust as you progress through different areas
of your app.

Part of diagraming should include what features/components you need to
use and making sure you can either find gem support or plugin support
for those features with whatever ruby platform you are using.

Don't give up.

People will tell you that you have bitten off more than you can chew
that you should put aside everything and slow down. I personally don't
believe in that line of thinking. I believe you task yourself first and
ask yourself how far can you go and what are your own boundaries. With
me, there are none. If someone asked me if I could do a better job than
the current President of the United States, my answer would be yes, but
it would take some time to get there.

There is no such thing as Peter Principle in my life. Is there in
yours?

Have you seen the rails guide on testing,
http://guides.rubyonrails.org/testing.html

Also the testing section in AWDR3 is useful.

Start with unit testing and include tests for every method of your
models, checking operation under normal conditions and with out of
range parameters and so on. Try to think of all the possible ways the
method may be called and test them. Any time there is a condition
test in the code check that each branch of the test is exercised in
tests. Then move on to functional testing the controllers, checking
each controller action with normal and unusual parameters.

Any time you find a problem in the code (I guarantee you will find
some while thinking of the tests to run) add a test that demonstrates
the problem before fixing it in the code.

It may seem a lot of work, and it is, but you will be amazed
afterwards how much peace of mind it provides as you tidy up or extend
the code knowing that you have minimised the likelihood of your
changes messing something up without you noticing.

Colin

Get "The RSpec Book" from Pragmatic Programmers. It really drives home
the BDD/TDD cycle.

Before I really drank the BDD/TDD kool-aid, I was always wary of
modifying a working application. With my test code in place, I am a
lot more comfortable creating a new branch and adding new code/re-
factoring. I can't imagine going back to the old way.

Eric

Make sure your database is indexed properly (benchmark and test, don't
randomly add indexes though). That can be one of the biggest initial
performance boosts.

rsync is a good place to start.

astrails-safe is a great backup gem, it takes care of both db (mysql
and postgresql) and file backups, storing them on S3. not sure if
it'll do email notifications though

http://github.com/astrails/safe/tree/master