Posted by JP
Thu, 24 May 2007 09:43:00 GMT
So yesterday, after upgrading Typo, I had this problem:
http://www.jponrails/blog/
would work but
http://www.jponrails/blog
wouldn't (400 Bad Request).
The problem is my blog runs with Mongrel FastCGI so in my public_html folder, I have a symbolic link that points to my application's public folder. Somehow, if you don't put the trailing slash, you get a 400 Bad Request error. I need to investigate this further, and I will as soon as I have some time.
I searched on the web for a mod_rewrite-based fix. All the fixes I found would work without the trailing slash, but they would break when you put the trailing slash! Not very useful...
That's until I found this blog entry on LavaFactory. That link I put is broken for some reason, so try clicking here and scrolling down a bit.
Here's the code I pasted in my public/.htaccess file:
# Trailing slash fix
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/]+)$ $1/ [R]
RewriteRule .*/blog/(.*) http://www.jponrails.com/blog/$1 [L,R]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
Posted in Tips | Tags apache, bestpractices, deploying, fastcgi, mod_rewrite, production, rails, site5 | no comments
Posted by JP
Tue, 22 May 2007 02:03:00 GMT
Or, how to decrease the probability that you shoot yourself in the foot.
Here's a checklist of things you might want to do early on during a web application. Doing these simple things will save you trouble, save time and help you put out a better quality product. The earlier you do them, the more time you'll save.
1 - Commit Source Code to Subversion
If you prefer another source-control system, use another one. The point is, use source control software. If you don't, bad things can and will happen.
Source control will help you:
- Track regression bugs.
- Remember what your code looked like before after you change your mind.
- Bring other people on board. Having more than one person modify a code base without source-control is a surefire way to attract problems.
- Document what you did and when you did it.
- Undo errors. Yours or others'.
2 - Write Automated Tests
Automated tests are a key component of Quality Assurance. If you can't hire QA people because you're running a small operation, fine - but do the minimum.
Automated tests let you:
- Find bugs as soon as they are created.
- Know when you break an interface.
- Find bugs before you deploy.
- Find bugs before your client/co-workers/boss finds them for you.
- Test your code in a relatively thorough fashion in a fraction of the time you would do it by hand.
- Increase the quality of your projects constantly.
3 - Set up a staging environment
Sooner or later, you'll need to deploy things that can't be tested in a development environment: server configuration changes, database server upgrades, whatever. The only way to test this reliably is to do it using a staging environment.
While testing your deployment on the staging environment, take note of everything you do so the real deployment will be smooth. To be safe, you can even stage the deployment twice. The second time around, you'll be sure that you didn't forget anything.
A staging environment will help you
- Deploy your software easily.
- Test the deployment procedure itself somewhere else than your production environment.
- Document changes done to the production environment.
- Get up and running quicker should you need to restore your entire production environment.
4 - Automate your deployment procedure
Scripts are faster than you are and if they're set up properly, they don't make mistakes. If your scripts are intelligent enough, they let you undo the deployment. Write them to be what you want them to be. My advice on the subject is to do it good enough so you save time without going overboard.
Automating your deployment procedure will let you:
- Minimize your application's downtime.
- Deploy urgent fixes quickly. It happens.
- Deploy more often by removing overhead. The easier it is, the more you'll do it. Your product will be incrementally better, faster.
5 - Fix problems as soon as they show up
Procrastinating is bad. Procrastinating bug fixes is especially bad. Fix problems while they are fresh in you mind. Don't wait two months to fix something that you could fix now. That way, you won't forget it, and it will take less time ot fix.
Out of lazyness, no bullet list for this item!
6 - Backup everything
On-site, and off-site. Your local machine and the servers. On site backups aren't enough: they won't protect-you against theft, fire, or whatever mother nature can cook up these days.
My friend's father who's a graphic designer used to backup his work on a Zip Drive. Too bad his backup disk was in his computer when it was stolen. Not only did he have to deal with the theft itself, but he had to redo a few weeks worth of work, with the ensuing consequences. Let's all learn something from this anecdote. I know I have.
Now, Business consultants charge four figures to walk into a conference room and tell you the same things I just told you with PowerPoint slides. One could say that they are crooks for doing so. One could also say that the return on investment will make up for that cost.
Maybe your project isn't there yet, fine, but as soon as a project becomes a source of revenue - or expenses, you want do be following these tips to make sure you're not burning your profits, potential revenue, or even worst, money out of your pocket.
The bottom line is that if you're not doing these things, you're lazy, but in a bad way. Lazing is an art. Do it well.
Please share any other ideas/suggestions you might have.
Posted in Tips | Tags bestpractices, bugfixing, deploying, process, productivity, svn, testing, tips | no comments
Posted by JP
Wed, 09 May 2007 17:31:00 GMT
Creating a web application is one thing. Deploying it is another.
On a shared server, resources such as memory and processing time are monitored closely so that a single application doesn't gobble up all available resources. Failure to do so can result in your hosting account being suspended, depending on your hosting provider.
Although Rails is relatively efficient, it's still not comparable to having the web server throw back a cached static page. Doing so bypasses the Ruby interpreter and relieves the database server altogether.
And it proved quite useful, as my World of Warcraft Gemfinder got picked up by World of Warcraft Insider, a well-read site in the gaming community. The mention of my site on that blog led to a peak of almost 40000 page views in a single day. Good thing I had turned on the application's caching the week before that.
Rails caching can work on three different levels. You can cache entire pages, which you can easily do by adding this to a controller:
class CutGemController < ApplicationController
...
caches_page :list
...
end
In this example, the 'list' page will be cached along with the template. Expire your cache with the expire_page command. Make sure you do so in every action which modifies the generated page. If you don't do it, your site will serve an outdated page.
If you still need the template to be dynamic, you can cache just the action. The template will still be rendered dynamically, which is useful if you need dynamic content in the sidebar or elsewhere in your template.
Finally, you can cache page fragments, which is useful for when your application is more dynamic, but you still have parts of the page which are expensive to compute, yet seldom change.
This post isn't a howto and doesn't contain detailed instructions on how to cache using RoR: plenty of sites already explain this in greater details.
I merely wanted to get this point across: Use caching, it's easy, and you never know when you site will get hit by a tsunami of requests. It's a matter of being a good neighbor to the other sites hosted on your server and to keep your site snappy, smooth and responsive.
Tags bestpractices, caching, deploying, optimizing, performance, rails | 3 comments
