Rails Best Practices, Tips and Tricks

(Source: http://glu.ttono.us/articles/2006/02/06/rails-best-practices-tips-and-tricks)
Posted by kev on Tuesday, February 07, 2006

Last month i joined company Bitla Softwares (www.bitlasoft.com). The work is exciting (all Rails) and the team is excellent. My favourite time-pass at office is digging up tricks in Rails. Found an excellent article, so thought of posting at my etechtrix just for me and U ofcourse!

Because Rails is a young framework, I thought it would be helpful to write up what I consider best practices when coding with it both for my new coworkers and the web at large. Here’s my current draft. Feel free to critique and comment. I’m very open to suggestions.

Testing

This is absolutely essential. Rails makes writing unit and functional tests incredibly easy and testing should be employed at all times. Positive and negative testing should be employed: the first to verify that the application does what it is supposed to when the proper variables are passed to the correct action and then second to verify that when incorrect variables are passed the prefered behavior occurs.

Unit Testing

As a general rule, unit testing should test any validation in models as well as any added methods in those models.

For example, if I have a User model which validates_presence_of first_name and last_name fields as well as a method fullname which combines the two, I might have test cases test_validates_names and test_fullname which would test that the model worked as it was intended to.

Functional Testing

Functional testing is used to test controllers. As a rule, there should be atleast one testcase for each action and positive and negative testing should be employed. This means that if I have an action create in my PostsController then there should be test_create and test_bad_create methods defined in my functional tests which do positive and negative testing. This does not mean there should be only two tests for each action. If there are exceptional cases beyond a simple good and bad, proper testing should cover those cases.

Helpful Reading

• A Guide To Testing The Rails

• Agile Web Development With Rails Chapter 12

Migrations

Migrations mean never having to say you’re sorry because you nuked the database. They allow for database agnostic schemas which means you can develop locally on SQLite and deploy on MySQL without a problem. They’re cleaner (and easier) than writing your own schemas custom and should be used whenever possible.

NEVER EVER EVER modify schema.rb. It is a reflection of the database. Migrations should be used to move this forward. If you don’t use migrations and instead modify schema.rb, things will break and people will be unhappy.

Note: You should always run svn update before generating a migration so you don’t have prefix collisions (two number 4s for example).

Helpful Reading

• The Joy of Migrations

• Getting Started With ActiveRecord Migrations

SQLite

SQLite is an SQL engine which runs in a single file rather than a server. It is (in general) as fast or faster than MySQL and is excellent for development and testing. In fact, it is possible to run a database completely out of memory which speeds up tests significantly. With the advent of migrations, it makes sense to use SQLite for testing as there is no extra work to deploy on MySQL.

DRY: Don’t Repeat Yourself

The main idea of DRY is that if code which is repeated is extracted to a helper or function, you only have one place to look for (and edit) your code if and when something goes wrong. If you find that similar code is used in several places, you may want to look into extracting that code to a helper function or partial.

Helpful Reading

• Rendering partials in the Rails API

• Refactoring by Martin Fowler

Naming Conventions

Don’t use abbreviations, especially in database column names. It should be immediately obvious what the column is for (or atleast what the name means) when looking at the name. These are not the days of C, we don’t need to conserve space with our variable names. Additionally, Rails error handling automatically knows how to “humanize” column names, so when you use a well described name you get to work less on outputting errors.

If names are too long, try to think of another word or phrase that means the same thing, but is immediately obvious.

Source Control (Subversion)

Some sort of source control should be used at all times. This allows for easy roll back if something goes wrong as well as the ability to refer back to old code if needed. Rails has certain files which should not be included in a source control repository, so please refer to the wiki page when preparing the initial import.

Helpful Reading

• How To Use Rails With Subversion

Authentication Systems

Several authentication modules have been written for Rails, but some are better at some things and some are better than others.

acts_as_authenticated

This should be the prefered authentication plugin. It is easily installed via script/plugin, is easily extendible and can handle all issues of the other authentication modules. Additionally, the testing code is excellent which makes it easy to modify.

login_generator

login_generator is the original login generator gem written by Tobias Luetke. The downside is that there is a bug which scrambles the password if you save an already existing user. It should not be used for this reason. It is replaced and superceded by acts_as_authenticated.

SaltedHashLoginGenerator

This was a first attempt at created a salted login generator which could reset passwords and do activation. It has since been extracted into login_engine. It is in general bloated and hard to modify. It should be avoided.

login_engine

login_engine is the extraction of SaltedHashLoginGenerator, and as such, has the disadvantages that SaltedHash has. Additionally, it uses the Rails Engines system which is designed for drop in use. In general, applications need customization. If you need more than simple modification of an authentication system, this should be avoided.

On Scaffolding

Scaffolding can be a time saver or a crutch. When using scaffolding, make sure to understand exactly what the code is doing and why. Once that happens you can generally write the code faster without using scaffolding as there are almost always changes to each section that scaffolding provides.

Suggested Reading (in General)

• The Pragmatic Programmer by Dave Thomas and Andy Hunt

• Refactoring by Martin Fowler

• Agile Web Development with Rails by Dave Thomas and David Heinemeier Hannson

• Programming Ruby by Dave Thomas, with Chad Fowler and Andy Hunt

Rails for Designers

(Source: http://glu.ttono.us/articles/2006/03/21/rails-for-designers)
Posted by kev on Wednesday, March 22, 2006

This is for designers who are going to be working with Rails and is intended to give them a good starting point to jump into work with a Rails developer. This is all introductory material. As such, I cover some basics (MVC, locations of files) and move from there to a code example and more advanced topics (partials, ActionView helpers).

Update: If there are other things people think I should cover, feel free to leave comments and I’ll do a follow up article.

Update #2: If you liked the article, digg it!

Update #Again: Marcel Molina (Jr) of the core team notes that yield is prefered to @content_for_layout when creating layouts, so I’ve updated my examples.

Views and ‘MVC’

MVC stands for “Model, View, Controller” and is a way to separate what the user sees from what happens behind the scenes.

View: The front-end

View is the section which controls what things look like when they render. What this means for you, the designer, is that you don’t have to fiddle through large blocks of programming logic which get in the way of your markup.

Controller: Programming logic

Controllers are where the actual processing code goes. This is where the variables that might be used in the view (@which @usually @look @like @this) will be set.

Model: Business logic and the database

The model deals with database and business logic and should never touch the front end.

Your friends, the views and public directories

One of the great things about Rails development is that you always know where something belongs. For designers, your code belongs either in app/views or in public/.

The views directory and dissecting URLs

The basic form of an URL in *Rails is http://yourhost/controller/action/id. The action corresponds to what view you will be rendering by default in the app/views/ directory.

So, for example, let’s say that you’re working on a social networking site and you’ve got an URL which looks like http://www.example.com/friends/show/1. This breaks down to the app/views/friends directory and the **show.rhtml file inside of it.

We’ll go over what happens in an rhtml file shortly, but first I’d like to cover the app/views/layouts/ directory.

* If this is not the case, it is because your developer is using something called Routes. Just ask them where the file you’re looking for is located in this instance.

** Again, this might be show.xml or show.rjs or something else if your developer is doing something special. Ask them about it if this is the case.

Layouts: Templates in disguise

Basically, layouts are templates. If you think about what happens in a basic site, you’ve got a header, footer and content somewhere in the center. The content comes from your view and all the surrounding stuff that might be page dependent (but can probably be reused) is part of the layout.

By default, a layout named the same as the controller is used. In our example above, the controller is friends, so a file app/views/layouts/friends.rhtml will be used for any URL like http://my.host/friends/anything. Additionally, if you create a app/views/layouts/application.rhtml file, it will be used by default if there isn’t a file named the same as the controller.

Do note that your developer can tell the view to render a template different from the default any time he wishes, so if you don’t want to be restricted to one layout per app/views/ subdirectory or controller you can create multiple layouts and the developer can explicitly define which is used.

Ok, so how do I get my view code to render in layouts?

Wherever you’d like the code from your view to go, place this bit of code <%= yield %>. You might also see <%= @content_for_layout %>, which does the same thing.

Note that <% or <%= starts Embedded Ruby (ERb) code and %> ends it. The difference between the two is that <%= outputs the result of what happens inside the ERb tags (just like or in PHP).

The public directory

The app/public directory directly links to the root directory of your application. This is where you can place images, stylesheets and javascript. In fact, Rails already creates directories for these purposes at app/public/images, app/public/stylesheets, and app/public/javascripts which are used by the helpers defined by Rails (which I will talk about later).

RHTML: Not so scary, really

So far we haven’t looked at much code. For this topic, I really think you need to see what we’ve been talking about.

app/views/layouts/application.rhtml

<title><%= @title || "My default title" %></title>

<%= stylesheet_link_tag 'global' %>

<%= javascript_include_tag 'custom', 'prototype', 'effects' %>

</head>

<body>

<div id="header">

<%= render :partial => 'shared/header' %>

</div>

<div id="content">

<%= yield %>

</div>

<div id="footer">

<%= render :partial => 'shared/footer' %>

</div>

</body>

</html>

If we scan application.rhtml, we see the basic (very basic) structure of an html document. A few elements may not be familiar.

Variables and giving your developer options

From top to bottom, the first thing that is out of place is the title tag. There are ERb tags present which outputs a result, and inside the tags it says @title || "My default title". Recognize that @title is a variable (like $title in PHP). If the ERb code only contained @title then the value of @title would be printed out. The one difference here is the || character. This means OR and effectively how the line reads in English is “print a title if there is one otherwise print ‘My Default Title’”. Doing this allows your developer to choose whether to define their own title or to use the default. If you need to get more complex than that, you should check with your developer first.

Tags to make your life easier

The next thing which isn’t normal html is two ERb tags, stylesheet_link_tag and javascript_include_tag. These are both ActionView (the name Rails gives to it’s View part of MVC) helpers. They do what their name says, and generate the html to include javascript files and stylesheets. They automatically handle file extension (.js or .css) and the directory (WEBROOT/javascripts or WEBROOT/stylesheets) for you.

link_to, the hyperlink’s smarter brother

Because designers generally won’t be working with controllers and actions (which is programming logic), you usually won’t be using the link_to helper in it’s regular form of link_to 'My link', :controller => 'something', :action => 'something_else', but you should be aware that it creates a hyperlink. You might use link_to to link to static URLs like link_to 'My link', '/my_link.html' or to named routes which look like link_to 'Login!', login_url. Named Routes are a special case, and your developer should tell you if they are being used. For more information, see the api entry.

Applying attributes to Rails tags

There are many helpers in Rails which can output html for you. Most of these take options to modify attributes for each tag. You should see the Rails API for further details, and the Learning More section at the end of this article about how to navigate the API page.

Partials

Let’s get back to the code example. Inside the header div things get a little more complicated. Here something called a partial is being rendered.

Think of partials as snippets of code that you’ll want to reuse. If you’re writing a user information div on a forum, you don’t want to have to format each individually. If you have the contents of a shopping cart print in several places, you don’t want to have to write the formatting and code in each place. Partials handle this. To do this, write code as you would in a view but place it in a file prefixed with a “_” and then use render :partial.

With our user information example, we might place the file _user_information.rhtml which contains all the code that needs to be rendered for user information in the app/views/users directory. Then, when we want to use that code in another view, you just use <= render :partial => 'users/user_information' %>.

Using partials means you only have to edit code once. Everywhere the partial is used will be automatically updated when you make a change.

Effectively yours, Scriptaculous

If you’re not aware of the Scriptaculous library, you should take a look. It is a clean effects library which integrates well with Rails. Using Scriptaculous deserves a full article so I won’t cover usage here.

Learning More

The Rails API holds all the documentation for the Ruby on Rails framework. As a designer, you will be most interested in ActionView (the name Rails gives for its View codebase). The API site is a bit ugly, but if you look at the left section in the middle frame and find links starting with ActionView you’ll find a wealth of helpers to make writing html easier. Familiarizing yourself with these and being able to find out what the helpers do will make you a better suited Rails designer, even if you choose not to use the helpers all of the time or at all.

10 Tips for Successful Development Projects

When you’re juggling four active projects, talking with clients and debugging thousand-line classes, being a developer can be stressful at times. Luckily, by planning a little here and there and working on your process, things can be much more manageable. A good developer is always perfecting his/her habits and skills. Here are a few things we’ve learned along the way.

1. Use a Version Control System (SVN, CVS, Git, et al.)

Many years ago, when I was first introduced to SVN, I didn’t understand the benefits right away. It seemed like a hassle — an extra step to go through that required me to learn something new and I didn’t think the value outweighed the inconvenience. Then I accidentally overwrote two large class files in an e-commerce project I was working on and had to redo the work. Needless to say, SVN became part of my daily workflow.

In truth, it’s fairly simple to get up to speed with the core functionality of SVN. You only need to learn a few commands before SVN becomes a very powerful part of your process. It’s especially useful if you’re working with a team of developers, as it allows everyone to work together without overwriting each other’s work, to easily share fixes and patches, and to release code to the public in a logical way. If you’re not using a version control system, you’re playing with fire.

If you’re a Rails developer, you might want to check out my SVN with Rails tutorial. It’s a little outdated now, but it should still give beginners a good idea of how to use SVN with a new Rails project.

2. Talk to Your Client

If you don’t know everything about a project, it probably won’t succeed. You need to get as much information from your client as you can. This means initial meetings and a discovery phase, but it also means that you can’t be afraid to ask follow up questions when you need to. You’ll find that most clients are more than willing to tell you anything you’d like to know about the project, and more likely than not they’ll be excited to see you’re so interested in understanding every aspect. Don’t be shy.

3. Pick the Right Technology for the Job

Just because I like Ruby on Rails doesn’t make it the right technology for every job. A good developer chooses the right technology for each project based on the requirements. But do keep in mind that it is your responsibility to suggest the best option. A lot of clients will come to the table with pre-conceived solutions based on things they’ve read or been told, and it’s up to you to state your case and give them their best options.

It’s not a bad thing to suggest a client go a different way. A lot of inexperienced developers will take a client’s requirements and run with them, even if they aren’t the best options for the project. No one wins that way. Be honest, be thorough, and make sure you’re choosing the right technology for the right reasons.

4. Keep the Client Focused on the Important Issues

This tip could alternatively be titled, “Tell the Client to Stop Worrying So Much About 99.9% Uptime and Redundancy Before They Even Have a Product to Keep Up All the Time.” It’s true: Clients believe (as they have been told for years by IT people the hosting industry) that the most important thing is that your website or web application have near-100% uptime. Notable people have written articles about how this simply isn’t true.

Here’s the reality: If you never have a product to launch because you spend all your time maximizing scale and uptime, none of that will matter. The truth is, even large web applications don’t need 99% uptime. And that’s even during success. You’ve got weekends and holidays and nights and slipping a few minutes here and there isn’t going to hurt you. In fact, if your product is good enough (i.e. you spent your time making a killer product), people won’t even mind if there’s occasional downtime that spans hours.

Don’t get me wrong: You should make an effort to maximize your product’s efficiency. But focus on getting it done first. Scale later.

5. Create Functional Specs

When working in a team (large or small), it’s important to spend time creating a functional spec —or something similar —that gives you and your team a clear development path. Many of my most successful projects have started with a functional spec. This does not mean you have to plan every part of a project out. A functional spec is to a developer what an outline is to a novelist. It’s broad strokes: Page flow, general functionality, features. It gives you a map to begin plotting your development with.

Functional specs do not need to be extremely complicated, which means that anyone on your team can do them. It doesn’t have to be the developer. Often times, the most successful functional specs I’ve used were created by other people on the project and then we met to discuss them and make changes. This lead to solid specs influenced by everyone in the project, and in the end a solid deliverable.

6. Read the Documentation & Participate in the Community

Being a developer means learning many different foreign languages. Sure, the core is English, but it might as well be Eskimo the first time you look at it. If you take one of your PHP classes and show it to a non-developer, they’d be looking at gibberish. So it’s understandable that eventually (and constantly), you’re going to need to reference documentation to get things working. And that’s not a bad thing.

Learning how to read documentation, and becoming good at seeking help is an important part of being a successful developer. Even more important is making an effort to be part of the community. Talk about the work you’re doing, read other developers’ weblogs, seek out new technologies and techniques. Join mailing lists or hang out in IRC chat rooms. You’d be surprised how much you can learn by asking questions or just reading about what other people are doing.

7. Find the Right Tools

This sounds like a no-brainer, but you’d be surprised how many people are making due with whatever they’ve been using since 1999. Times have changed. There are great text editors, powerful IDEs, and fantastic tools to help a developer get work done more efficiently and with less stress. If you’re a Mac user, you’ve probably used BBEdit at some point in your career, but have you checked out TextMate or Coda? Or vice versa? Don’t assume that the tools you’re used to are the best tools for the job. It’s possible that your work can be easier if you suffer through a week of transition.

And, of course, there are many utilities such as MySQL interfaces and solid FTP applications that will help. Don’t be afraid to spend a little time playing with your options. Once you’ve decided on a toolset, spend time learning as many shortcuts and such as you can. Getting really good with your tools speeds up your process and makes your job much easier.

8. Take Frequent Breaks

It’s simple: The more you sit in your chair at your desk staring at a computer screen, typing and mousing, the worse it is for you. Break up your work day. Take frequent short breaks and a few long ones. Your back, arms, eyes and brain will thank you. And they might even reward you with the ability to solve those problems you’ve been having the past two days with your user authentication method.

9. Do a Post Mortem

Once you’ve delivered your final project to the client, do an internal post mortem. Talk about what went well, what went wrong, and what you need to change in your process in the future. This is important to do even if the project was a complete success, since it’s a good idea to note how your process worked and how you might apply that to future work. It’s even more important, obviously, especially when things don’t go well.

It’s also a good idea to get feedback from the client. Ask them how they felt about the process, the work, et cetera. Implore them to be very honest. Their feedback will help you to deal with new clients and even improve relations in case the client comes back for more work in the future.

10. Choose the Right Project

Don’t take anything that crosses your plate, unless you’re in desperate need of money or there’s a special circumstance. Being picky is a good idea. Don’t choose projects which you have a bad feeling about — chances are that your first impression is the right one and things won’t work out. It’s much better to take fewer projects on and have them all be successful than taking many and having no successes.

There will be many times that a project starts well and goes badly. That’s the nature of the work. But if things look bad before you write the estimate, step back and think hard about whether or not you want to put in the work to try to change the situation to something you want. In most cases, this simply won’t work out and you’ll regret taking on the work at all. Be selective.

Top 10 Ruby on Rails performance tips

The performance of Ruby on Rails is influenced by many factors, particularly the configuration of your deployment server(s). However the application code can make a big difference and determine whether your site is slow or highly responsive. This short article is about some of the tips and best coding practices to improve performances in Rails only, and won’t attempt to cover the server configuration improvements for the various deployments options.

1. Optimize your Ruby code: this may seem obvious, but a Rails application is essentially ruby code that will have to be run. Make sure your code is efficient from a Ruby standpoint. Take a look at your code and ask yourself if some refactoring is in order, keeping in mind performance considerations and algorithmic efficiency. Profiling tools are, of course, very helpful in identifying slow code, but the following are some general considerations (some of them may appear admittedly obvious to you):
   • When available use the built-in classes and methods, rather than rolling your own;
   • Use Regular Expressions rather than costly loops, when you need to parse and process all but the smallest text;
   • Use Libxml rather than the slower REXML if you are processing XML documents;
   • Sometimes you may want to trade off just a bit of elegance and abstraction for speed (e.g. define_method and yield can be costly);
   • The best way to resolve slow loops, is to remove them if possible. Not always, but in a few cases you can avoid loops by restructuring your code;
   • Simplify and reduce nested if/unless as much as you can and remember that the operator ||= is your friend;
   • Hashes are expensive data structures. Consider storing the value for a given key in a local variable if you need to recall the value a few times. More in general, it’s a good idea to store in a variable (local, instance or class variable) any frequently accessed data structure.
2. Caching is good: caching can significantly speed up your application. In particular:
   • Cache your models through the plugin acts_as_cached (a pdf presentation is here) or the cached_model gem;
   • Use MemCacheStore as Sessions container;
   • Cache your pages through fragment cache (take a look at the extended_fragment_cache).
3. Use your database to the full extent of the law : don’t be afraid of using the cool features provided by your database, even if they are not directly supported by Rails and doing so means bypassing ActiveRecord. For example define stored procedures and functions, knowing that you can use them by communicating directly with the database through driver calls, rather than ActiveRecord high level methods. This can hugely improve the performance of a data bound Rails application.
4. Finders are great but be careful: finders are very pleasant to use, enable you to write readable code and they don’t require in-depth SQL knowledge. But the nice high level abstraction come with a computational cost. Follow these rules of thumb:
   • Retrieve only the information that you need. A lot of execution time can be wasted by running selects for data that is not really needed. When using the various finders make sure to provide the right options to select only the fields required (:select), and if you only need a numbered subset of records from the resultset, opportunely specify a limit (with the :limit and :offset options).
   • Don’t kill your database with too many queries, use eager loading of associations through the include option:

     # This will generates only one query,
     # rather than Post.count + 1 queries
     for post in Post.find(:all,
                          :include => [ :author, :comments ])
      # Do something with post
     end

   • Avoid dynamic finders like MyModel.find_by_*. While using something like User.find_by_username is very readable and easy, it also can cost you a lot. In fact, ActiveRecord dynamically generates these methods within method_missing and this can be quite slow. In fact, once the method is defined and invoked, the mapping with the model attribute (username in our example) is ultimately achieved through a select query which is built before being sent to the database. Using MyModel.find_by_sql directly, or even MyModel.find, is much more efficient;
   • Be sure to use MyModel.find_by_sql whenever you need to run an optimized SQL query. Needless to say, even if the final SQL statement ends up being the same, find_by_sql is more efficient than the equivalent find (no need to build the actual SQL string from the various option passed to the method). If you are building a plugin that needs to be cross-platform though, verify that the SQL queries will run on all Rails supported databases, or just use find instead. In general, using find is more readable and leads to better maintainable code, so before starting to fill your application with find_by_sql, do some profiling and individuate slow queries which may need to be customized and optimized manually.
5. Group operations in a transaction: ActiveRecord wraps the creation or update of a record in a single transaction. Multiple inserts will then generate many transactions (one for each insert). Grouping multiple inserts in one single transaction will speed things up.

   Insead of:

    my_collection.each do |q|
     Quote.create({:phrase => q})
   end

   Use:

   Quote.transaction do
   my_collection.each do |q|
     Quote.create({:phrase => q})
   end
   end

   or for rolling back the whole transaction if any insert fails, use:

   Quote.transaction do
   my_collection.each do |q|
     quote = Quote.new({:phrase => q})
     quote.save!
   end
   end

6. Control your controllers: filters are expensive, don’t abuse them. Also, don’t overuse too many instance variables that are not actually required by your views (they are not light).
7. Use HTML for your views: in your view templates don’t overuse helpers. Every time you use form helpers you are introducing an extra step. Do you really need a helper to write the HTML for a link, a textbox or a form for you? (You may even make your designer, who doesn’t know Ruby, happy!)
8. Logging: configure your applications so that they log only the information that is absolutely vital to you. Logging is an expensive operation and an inappropriate level (e.g. Logger::DEBUG) can cripple your production application.
9. Patch the GC: OK, not really a coding issue, but patching Ruby’s Garbage Collection is strongly advised and will improve the speed of your Ruby and Rails applications significantly.
10. A final note:I don’t advocate premature optimization, but if you can, work on your code with these principles in mind (but don’t overdo it either). Last minute changes and tweaks are possible but less desirable than a “performance aware” style of coding. Profile your applications, benchmark them
    and have fun experimenting.

26 MORE Guerrilla Marketing Tactics You Should Be Using

Written by: Mike Smith on Thursday, December 13th, 2007 | Guerrilla Marketing

Let’s follow up our original post: 24 Guerrilla Marketing Tactics You Should Be Using, I want to write about 26 more ideas to round the full number to 50 guerrilla marketing tactics. If you’ve got more ideas, feel free to leave a comment. If you like the article, feel free to digg it or stumble it. I’d appreciate it.

1. Client Appreciation BBQ - Invite your past clients to a BBQ and let them invite 1-2 friends to come with them. This will help your customers LOVE you even more than they already do, as well as bring some new faces into contact with you as potential clients.
2. Outdoor Signs - Ever see the huge amounts of signs in the grass for mayor elections or in the front yard of a house that just got remodeled? This is a great, and inexpensive way to get your websites name out there. Pick a great tagline or picture for the ads, and you’ll be sure to get noticed.
3. Circulars - A lot of people nowadays are looking for good deals on just about anything, so when they receive the “junk mail” it’s not considered as “junk” anymore. Get a brochure put into these and you’ll have a good chance at 10-100K people to see it depending on how big the circulation is.
4. Newspapers - You don’t have to just buy an ad. Today, a lot of newspapers are hurting for editorials, so if you have any copy writing skills, you can send in some editorials to the newspapers and include a byline for your company/website information.
5. Magazines - Similar to above. Don’t just buy an ad that will get looked over, but write an article and if it is well written, when people read it, they’ll want to check out your website for more information on you.
6. Put it on a bus - Mobile advertising is great and will get viewed by a lot of potential clients on a daily basis.
7. Postcard Mailing - This is a bit cheaper then sending out envelopes that might weigh a bit and it also is easier for the potential client to read what you’re promoting without having the OPTION of opening the envelope (a postcard is one single piece of paper).
8. Write an E-book - You can do this for to reasons. 1, you can write a free e-book on a topic in your niche and circulate it so people will start to see you as an authority in your niche, or you can also sell the book for a small profit and use that money to fund some of the other Guerrilla Marketing tactics.
9. Giving it Away - How many people will turn down a free service or product? I don’t think very many will, so your voice and company will get out there in front of a lot of people. It’s also good for press to say you’ve given away X amount of products or services.
10. Enter Business Awards - from small, local awards, to big, multi-national ones like Inc., your company could benefit from the exposure inside the awards. It’s an added bonus if you win because then you have a nice trophy in the office, or ribbon on your website that says you’re a good company.
11. Link Bait & Viral Marketing - This is a well known tip to bloggers and website owners but few actually use it to their full advantage. For example, Matt Inman from 0at.org created some surveys as link bait for his dating site. Eventually, his dating website ended up as #1 in google for “online dating”, ahead of match.com and the other big players in that niche. Lonelygirl15 is another viral marketing showcase on how creating some funny videos can boost your viewers in a huge way.
12. Offer all the extras - If you design, offer to setup hosting and buy the domain name. If you cut grass, offer to come in the winter and shovel snow. If you cook dinners for offices or nurses at hospitals, offer to create desserts. The ideas are endless, but if you give your clients EVERYTHING, they will have nothing to go elsewhere for.
13. Borrow a wall/building - get a projector and find someone to let you use the side of their business/wall, and have your company logo/website/information shown on it every night. I know I would personally stop and look at what was showing on the side of a building for sure, so I can imagine how many others would as well.
14. Own the bus stop - Not literally, but if you can get your ad on the poster area of the bus stop along with the seat inside the bus stop, you could effectively “own” the bus stop and the eyes of everyone who stands there on a daily basis waiting for the bus. Add this in with #6 and you’ve got something everyone will remember and talk about.
15. Movie Theater Ads - I’ve looked into these for myself and they are generally very inexpensive as far as ads of this style go. Think about the movie you want your ad to show for and target it accordingly. A hiphop movie would be a great place for my Kicks Junkie website to be promoted, while a teen movie will do best with games/celebrity news.
16. Doctors Office Magazines - I’d slip business cards into magazines every time you go to the doctors. That’s what they get for making you sit in a waiting room for 2 hours at a time, only to be seen by the doctor for 10 minutes
17. Sex Sells -If your business is built for it, use it. Anything that isn’t “highly upper class” could use a little sex in their ads or in various ways. Building on the 24 guerrilla marketing tactics I wrote about, you could have 5-10 bikini models picket outside your business. This will definitely grab attention of guys in cars passing by.
18. Sponsor the homeless - I believe in helping people in any way possible. If you see a homeless person somewhere on your daily commute to work, or various other places, you could pay the homeless person to hold a sign that reads “YourCompany.com paid me to hold this sign”. Regardless if it brings a TON of business your way or not, at least you’ll feel good about yourself, and you’ll touch that persons life forever. Buy them lunch and dinner or take them to a grocery store and pick out some chips and various other foods they can keep with them. Buy them a hotel room for the night to sleep in and get cleaned up. They’ll gladly stand with a sign for you after you do this for them.
19. Underground Music - Is there a genre of music that your target market listens to? I bet there are hundreds, if not, thousands of music groups that are unsigned and lack funds to survive off their music. Why not offer to rent the hall for their next performance in exchange for flyers and banners during the show, or passed out at the door? You can also sponsor their CD production, or offer to get their website created in exchange for advertising at their shows, on the site, ect.
20. Cross-Promotion on 404 Pages - Network with other bloggers or website owners and exchange banners on 404 pages. You could also promote affiliate offers or at the very least, put a google adsense block on it. The ideas for this are limitless and you can do different tests on each of your websites.
21. M&M Candy - If you go to the M&M website, you’ll notice that you can personalize your candy. You can use this to either promote your business or just put a thank you onthe candy and give it to a client.
22. Hair Salon’s and Barber Shops - How much talking happens in one of these places on a daily basis? Why WOULDN’T you want to be a business they are talking about? Drop in and offer the hair stylists some free food from your restaurant or coupons for free products. They’ll be talking about you to everyone who comes through the salon for weeks to come!
23. 800 number and PO Box - I’ve talked about these two things before but I know they deserve to be mentioned here. If you’re looking for a company in the yellowpages or online and one has a home address and a number like this: 1-333-565-3245, while the one next to it has a PO Box for the address and a 1-800 number, which do you think is more likely to ‘look’ and ‘feel’ more professional? What company do you think is going to get the first call? You guessed it, the one with the 800 number and PO Box. Read Here to find out more about these.
24. Press Releases - Regardless of what anyone tells you, a well formed and well written press release can gain you a lot of attention not only from the media, but from the target market as well. Don’t let this simple tool pass you by when trying to establish your bootstrapped business.
25. Airplane Chauffeur - Find out when a trade show pertaining to your business will be in town. Next, hire a student or someone who will work for a low amount of money and have them hand make a sign with your websites address on it and stand next to baggage claim or right outside the door of the airport. They aren’t picking anyone up, but the people walking by and seeing your website address don’t know that.
26. Let Others Talk You Up - For the final tip in this installment of the list (yes, there will be more coming soon) I want to leave you with something that sounds so simple, but you probably never thought about. A lot of people will enlist their friends and family to talk to other people about their business, but why not get people who aren’t super close to you, pay them a bit of money and send them out to bars, clubs, movies, restaurants and other busy places to talk up your business. Any word of mouth is good, even if you have to by the persons dinner in order for them to do it. Every little bit helps.

24 Guerrilla Marketing Tactics You Should Be Using

Written by: Mike Smith on Monday, December 10th, 2007 | Guerrilla Marketing

To know how to incorporate some of the older Guerrilla Marketing strategies with some newer, unconventional marketing ideas is an art form and something you should really be doing in your day-to-day business promotion. It doesn’t matter if you are promoting an information website, your new blog or some services you offer, the right marketing can make or break the fine line between success and failure.

For those who don’t know I want to give a brief overview of Guerrilla Marketing. In short you could describe guerrilla marketing as ‘link bait’ or ‘guest posting’ from the bloggers point of view, or ‘free t-shirt giveaway (t-shirts have your logo/website on it)’ for the record company. If you look on the wiki page for guerrilla marketing, it explains it like this:

… an unconventional system of promotions on a very low budget, by relying on time, energy and imagination instead of big marketing budgets

This is the basic principle of bootstrapping, so that’s why we’re covering Guerrilla Marketing here on the Bootstrapping Blog now. This is the first of many articles in the new category. If you have an idea that’s not on this list, feel free to leave a comment and let us know

1. Money Stamping - grab a stamper from your local office supply store and stamp a funny phrase along with your website address on it. Have a make money online blog? Stamp something like “Learn how to make thousands of these online: sitehere”.
2. Sticky Notes - Another way to use your stamper or even your printer. Sticky notes are noticable anywhere because people know what they’re for; notes. Put these on local business doors, offices, cars, or above mail boxes in apartment complexes and people will take notice.
3. So many stamps - Looking for a way to get noticed in the huge pile of advertising mail potential clients get? Send your promo material in a big manilla envelope and put 39 - 1 cent stamps on it. Out of 100 envelopes, who’s do you think will catch the eye first?
4. Do Not Disturb - Heading to a blog expo anytime soon? Get some door hangers printed up with your business information on it and possibly a link to something free on your site. Get the attention of everyone in your market this way, and it’s super cheap as well. Noone else I know has been doing this so you’ll stand out for sure.
5. Pay it forward - when you’re heading into the movie theater, pay the persons way behind you and tell the cashier to give them your business card. You’re not guaranteed that the person will become a client but I bet the word of mouth on that one would be pretty big.
6. Fake publicity stunt - you could have people picket your storefront with signs that read “This business is too nice” or “Company X is too good at their job”. Theres a million fake publicity stunts, use your imagination and I bet it’ll work no matter how weird or out of the box it seems.
7. Guest blogging - This is for the bloggers out there, or even the freelance writers. Guest blog on other blogs largely related, or semi-related to your websites niche. Opening other peoples eyes to your name and your website is always good promotion, especially if you’re an awesome writer. Not to mention networking with other bloggers is great for business as well.
8. Business Cards - STOP! Don’t skip this one. So many people see this and think you’re going to tell them to print cards and hand them out. I’m not! What you do with these cards is head to every library or book store in your city and find the section that relates to your business. Open each and every book and place a business card somewhere in the book. This is great targeted marketing and only costs you a few bucks for the cards and an afternoon of placing the cards.
9. Bumper Stickers - These are great because they can go anywhere, not just on your car. Bathroom stalls, street poles, ect. Get creative with where you place them, they can grab peoples attention when placed in the right spots.
10. Temporary Tattoos - I seen a post on some guerrilla marketing ideas over at Daily Bits and they talked about this as well. These tattoos will last for X amount of days and would be perfect for blog expos or other events where tons of people will be. Placing it in a weird place (forehead, neck, full back, foot, ect) is also a great way to get it noticed. Hey, if people talk about it, thats the whole point right?
11. Help Home Based Businesses - most HBB owners try to keep their records hidden from local housing authorities so they’re hard to reach. head over to your local chamber of commerce and suggest a HBB committee. They might appoint you head of it (you can even ask to be) and you have a bunch of HBB owners who will come to chat and you can promote to with business cards, flyers, booklets, ect.
12. Anything Else? - No, the list isn’t done yet. These are two words to say right before you exchange money with a client/customer. This will make them think and could open doors to a larger pay day.
13. Top 10 reasons to choose YOU - instead of leaving business cards or other promo material at a business or in someones email box, create a list of the top 10 reasons why the prospect should choose your company. Make them 100% true, humerous and memberable.
14. Demonstrations - got a service business? this is perfect for you. Find a local store that pertains to your services and put on a free demo of your services. Your service involve outdoors? Contact news stations and let them know you’ll be offering a BBQ and free service demonstration. The BBQ could get a little costly, but the amount of press and promotion could really pay off.
15. Print Calendars - These could be given to each of your clients or left in a store for people to take for free. Print your website address and a little slogan or client testimonial on each months picture for exposure every day. The people using your calendars will even help you out when they have company over who will see the calendar, especially if the images you use are high end and visually appealing.
16. Window decals - get a custom printed window decal on your car with your logo/website and possibly a slogan. looks professional, and is great for red lights.
17. Fish Bowl Business Cards - You know the fish bowls at stores offering to choose a random card for a free lunch? Well, theres two ways to benefit from this. - 1. put your card in the fish bowl (hey, a free lunch is a free lunch, and who knows, the owner of the store might need your services) - 2. ask the store to let you have the losing cards each week/month which will generate a ton of free leads for you.
18. Sponsor an event - doing this is at most times, very inexpensive and also GREAT for publicity, especially if its a big event. You normally get your logo and business mentioned in all of the events promo material which is tons of publicity you normally wouldn’t get. Be at the event to add extra stickiness to your business name and interact with the guests.
19. Holiday Greetings - send emails or snail-mail to your past clients wishing them happy holidays (Christmas, Thanksgiving, New Years). This helps them keep your name/business in their head as well as standing out from the other people they’ve done business with before.
20. Charity Donations - Donate some of the profits you generate every month to charity. Great for promotion in the media and clients to feel like they’re helping out the charity by purchasing from you.
21. Hold a Contest - This could have 1-10 winners which helps the word-of-mouth promotion everyone needs and wants. You can gain free press for starting the contest, plus publishing the winners is great for more press coverage.
22. T-Shirts - This is great for turning yourself or others into walking billboard. You can give the t-shirts away as prizes which is also another great way of gaining word of mouth promotion. Your t-shirts for the prizes don’t need your website address on it. Just give away a great, fashionable shirt and that’ll have people eager to tell friends and family where they got it from.
23. Partnerships - Do you run a web design business and want to find more potential leads? Try partnering with a web hosting company. Do you have a lawn-care business? Try partnering with a window washing company. Any partnership which benefits both companies is a great idea and a great way at grabbing the attention of new potential clients. Also a great way of giving your business targeted marketing.
24. Blood Drive - Host a blood drive, contact newspapers, tv news, radio, ect. have 1-2 banners up with your website information and also have business cards at the sign in table. Everyone loves to help their country, city, state, ect. and giving blood is the easiest way for some people to do that. Putting yourself in the forefront of your cities next blood drive would make your business very visible to a whole range of new potential clients and word-of-mouth advertisers.

See more tactics on next post "26 more Guerrilla Marketing Tactics You Should Be Using".

Introduction to OLAP

(Source: http://www.dwreview.com/OLAP/Introduction_OLAP.html)

OLAP (or Online Analytical Processing) has been growing in popularity due to the increase in data volumes and the recognition of the business value of analytics. Until the mid-nineties, performing OLAP analysis was an extremely costly process mainly restricted to larger organizations.

The major OLAP vendor are Hyperion, Cognos, Business Objects, MicroStrategy. The cost per seat were in the range of $1500 to $5000 per annum. The setting up of the environment to perform OLAP analysis would also require substantial investments in time and monetary resources.

This has changed as the major database vendor have started to incorporate OLAP modules within their database offering - Microsoft SQL Server 2000 with Analysis Services, Oracle with Express and Darwin, and IBM with DB2.

What is OLAP?

OLAP allows business users to slice and dice data at will. Normally data in an organization is distributed in multiple data sources and are incompatible with each other. A retail example: Point-of-sales data and sales made via call-center or the Web are stored in different location and formats. It would a time consuming process for an executive to obtain OLAP reports such as - What are the most popular products purchased by customers between the ages 15 to 30?

Part of the OLAP implementation process involves extracting data from the various data repositories and making them compatible. Making data compatible involves ensuring that the meaning of the data in one repository matches all other repositories. An example of incompatible data: Customer ages can be stored as birth date for purchases made over the web and stored as age categories (i.e. between 15 and 30) for in store sales.

It is not always necessary to create a data warehouse for OLAP analysis. Data stored by operational systems, such as point-of-sales, are in types of databases called OLTPs. OLTP, Online Transaction Process, databases do not have any difference from a structural perspective from any other databases. The main difference, and only, difference is the way in which data is stored.

Examples of OLTPs can include ERP, CRM, SCM, Point-of-Sale applications, Call Center.

OLTPs are designed for optimal transaction speed. When a consumer makes a purchase online, they expect the transactions to occur instantaneously. With a database design, call data modeling, optimized for transactions the record 'Consumer name, Address, Telephone, Order Number, Order Name, Price, Payment Method' is created quickly on the database and the results can be recalled by managers equally quickly if needed.

Figure 1. Data Model for OLTP

Data are not typically stored for an extended period on OLTPs for storage cost and transaction speed reasons.

OLAPs have a different mandate from OLTPs. OLAPs are designed to give an overview analysis of what happened. Hence the data storage (i.e. data modeling) has to be set up differently. The most common method is called the star design.

Figure 2. Star Data Model for OLAP

The central table in an OLAP start data model is called the fact table. The surrounding tables are called the dimensions. Using the above data model, it is possible to build reports that answer questions such as:

• The supervisor that gave the most discounts.
• The quantity shipped on a particular date, month, year or quarter.
• In which zip code did product A sell the most.

To obtain answers, such as the ones above, from a data model OLAP cubes are created. OLAP cubes are not strictly cuboids - it is the name given to the process of linking data from the different dimensions. The cubes can be developed along business units such as sales or marketing. Or a giant cube can be formed with all the dimensions.

Figure 3. OLAP Cube with Time, Customer and Product Dimensions

OLAP can be a valuable and rewarding business tool. Aside from producing reports, OLAP analysis can aid an organization evaluate balanced scorecard targets.

Figure 4. Steps in the OLAP Creation Process

Ajax: A New Approach to Web Applications

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.

Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.

That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.

It’s going to be fun.

---

Ajax Q&A

March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.

Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?

A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?

A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.

Q. Is Ajax just another name for XMLHttpRequest?

A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

Q. Why did you feel the need to give this a name?

A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.

Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?

A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.

Q. Is Ajax a technology platform or is it an architectural style?

A. It’s both. Ajax is a set of technologies being used together in a particular way.

Q. What kinds of applications is Ajax best suited for?

A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

Q. Does this mean Adaptive Path is anti-Flash?

A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).

Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?

A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.

Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.

Q. Are Ajax applications easier to develop than traditional web applications?

A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.

Q. Do Ajax applications always deliver a better experience than traditional web applications?

A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.

HTTP Request

(Ref: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html)
part of Hypertext Transfer Protocol -- HTTP/1.1
RFC 2616 Fielding, et al.

HTTP Request

A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.

        Request       = Request-Line              ; Section 5.1
                      *(( general-header        ; Section 4.5
                       | request-header         ; Section 5.3
                       | entity-header ) CRLF)  ; Section 7.1
                      CRLF
                      [ message-body ]          ; Section 4.3 

5.1 Request-Line

The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.

        Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Method

The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.

       Method         = "OPTIONS"                ; Section 9.2
                    | "GET"                    ; Section 9.3
                    | "HEAD"                   ; Section 9.4
                    | "POST"                   ; Section 9.5
                    | "PUT"                    ; Section 9.6
                    | "DELETE"                 ; Section 9.7
                    | "TRACE"                  ; Section 9.8
                    | "CONNECT"                ; Section 9.9
                    | extension-method
     extension-method = token

The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9.

5.1.2 Request-URI

The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.

       Request-URI    = "*" | absoluteURI | abs_path | authority

The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be

       OPTIONS * HTTP/1.1

The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server

specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

The authority form is only used by the CONNECT method (section 9.9).

The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:

       GET /pub/WWW/TheProject.html HTTP/1.1
     Host: www.w3.org

followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).

The Request-URI is transmitted in the format specified in section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding [42], the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.

A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".

      Note: The "no rewrite" rule prevents the proxy from changing the
    meaning of the request when the origin server is improperly using
    a non-reserved URI character for a reserved purpose.  Implementors
    should be aware that some pre-HTTP/1.1 proxies have been known to
    rewrite the Request-URI.

5.2 The Resource Identified by a Request

The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.

An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)

An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:

1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.

2. If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value.

3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message.

Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.

5.3 Request Header Fields

The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation.

       request-header = Accept                   ; Section 14.1
                    | Accept-Charset           ; Section 14.2
                    | Accept-Encoding          ; Section 14.3
                    | Accept-Language          ; Section 14.4
                    | Authorization            ; Section 14.8
                    | Expect                   ; Section 14.20
                    | From                     ; Section 14.22
                    | Host                     ; Section 14.23
                    | If-Match                 ; Section 14.24 

                      | If-Modified-Since        ; Section 14.25
                    | If-None-Match            ; Section 14.26
                    | If-Range                 ; Section 14.27
                    | If-Unmodified-Since      ; Section 14.28
                    | Max-Forwards             ; Section 14.31
                    | Proxy-Authorization      ; Section 14.34
                    | Range                    ; Section 14.35
                    | Referer                  ; Section 14.36
                    | TE                       ; Section 14.39
                    | User-Agent               ; Section 14.43 

Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of request- header fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header fields.