3/04/2009 What should a developer know _bef…

What should a developer know _before_ building a public web site?

Transfert de données SQL Studio - 18 tools Web 2.0 Apps in Minutes

Solution d'intégration de données Open Compare, Script, Recover, SSIS, IDE/Editor, Generate database & reporting apps straight
Source : 100% gratuit ! Doc, Diff & Audit from your database! Try it
www.talend.com/download www.ApexSQL.com www.ironspeed.com

What things should a programmer implementing the technical details of a web site address before
making the site public? If Jeff Atwood can forget about HttpOnly cookies, sitemaps, and cross-site
request forgeries all in the same site, what important thing could I be forgetting as well?

I'm thinking about this from a web developer's perspective, such that someone else is creating the
actual design and content for the site. So while usability and content may be more important than the
platform, you the programmer have little say in that. What you do need to worry about is that your
implementation of the platform is stable, performs well, is secure, and meets any other business goals
(like not cost too much, take too long to build, and rank as well with Google as the content supports).

So what simple things could you forget to do that would cause the site to miss any of that? Think of
this from the perspective of a developer who's done some work for intranet-type applications in a fairly
trusted environment, and is about to have his first shot and putting out a potentially popular site for
the entire big bad world wide web.

Also: I'm looking for something more specific than just a vague "web standards" response. I mean,
HTML, javascript, and CSS over HTTP are pretty much a given, especially when I've already specified
that you're a professional web developer. So going beyond that, Which standards? In what
circumstances, and why? Provide a link to the standard's spec.

Thank you to naeblis for providing the initial compiled answer.

This question is community wiki, so please feel free to edit that answer to add links to good
articles that will help explain or teach each particular point.

best-practices web-development security cross-platform

edited Dec 31 at 17:21 community wiki

Joel Coehoorn 22 revisions, 3 users
Joel Coehoorn 100%

52 Answers:
1 2 next

The idea here is that most of us should already know most of what is on this list. But there just might
be one or two items you haven't really looked into before, don't fully understand, or maybe never
even heard of.

Interface and User Experience

Be aware that browsers implement standards inconsistently and make sure your site works
reasonably well across all major browsers. At a minimum test against a recent gecko engine
(Firefox), a Webkit engine (Safari, Chrome, and some mobile browsers), your supported IE
browsers, and Opera.
Consider how people might use the site other than from the major browsers: cell phones, screen
readers and search engines, for example. — Some accessibility info: WAI and Section508,
Mobile development: MobiForge
Staging: How to deploy updates without affecting your users. Ed Lucas's answer has some
comments on this.
Don't display errors directly to the user
Don't put user's email address in plain text as they will get spammed to death
Build well-considered limits into your site - This also belongs under Security.

Security

It's a lot to digest but the OWASP development guide covers Web Site security from top to
bottom
Know about SQL injection and how to prevent it

stackoverflow.com/…/what-should-a… 1/9
3/04/2009 What should a developer know _bef…
Never trust user input
Encrypt Hash and salt passwords rather than storing them plain-text.
Don't try to come up with your own fancy authentication system: it's such an easy thing to get
wrong in subtle and untestable ways and you wouldn't even know it until after you're hacked.
Know the rules for processing credit cards. See this question as well:
http://stackoverflow.com/questions/51094/payment-processors-what-do-i-need-to-know-if-i-want-
to-accept-credit-cards-on-m
Use SSL/HTTPS for login and any pages where sensitive data is entered (like credit card info)
How to resist session hijacking
Avoid cross site scripting (XSS)
Avoid cross site request forgeries (XSRF)
Keep your system(s) up to date with the latest patches
Make sure your database connection information is secured.
Keep yourself informed about the latest attack techniques and vulnerabilities affecting your
platform.
The Google Browser Security Handbook

Performance

Implement caching if necessary

Optimise images - don't use a 20KB image for a repeating background
Learn how to gzip content
Take a look at the Yahoo Exceptional Performance site, lots of great guidelines including
improving front-end performance and their YSlow tool.
Use CSS Image Sprites for small related images like toolbars (see the the "minimize http
requests" point)
Busy web sites should consider splitting components across domains.
Minimize the total number of http requests required for a browser to render the page.

SEO

Use "search engine friendly" URLS, i.e. use "example.com/pages/45-article-title" instead of

"example.com/index.php?page=45"
Don't use links that say "click here". You're wasting an SEO opportunity and it makes things
harder for people with screen readers.
Have an XML sitemap
http://www.google.com/webmasters/
Install Google Anyalytics right at the start
Know how robots.txt and search engine spiders work
Avoid table-based layout: Google will generally score good semantic/CSS-based html better than
an equivalent page with table-based layout.
If you have non-text content look into Google's sitemap extensions for video etc. There is some
good information about this in Tim Farley's answer.

Technology

Understand HTTP and things like GET, POST, sessions, cookies, and what it means to be
"stateless".
Write your XHTML/HTML and CSS according to the W3C specifications and make sure they
validate. The goal here is to avoid browser quirks modes and as a bonus make it much easier to
work with non-standard browsers like screen readers and mobile devices.
Understand how JavaScript is processed in the browser. Move scripts to the bottom of your
pages.
Understand how the JavaScript sandbox works, especially if you intend to use iframes.
Be aware that JavaScript can and will be disabled, and that AJAX is therefore an extension not a
baseline. Even if most normal users leave it on now, remember that NoScript is becoming more
popular and mobile devices may not work as expected.
Learn the difference between 301 and 302 redirects (this is also an SEO issue).
Learn as much as you possibly can about your deployment platform
Consider using a Reset Style Sheet

Bug fixing

Understand you'll spend 20% of the time coding and 80% of it maintaining so code accordingly
Set up a good error reporting solution
Have some system for people to contact you with suggestions and criticsm.
Document how the application works for future support staff and people performing maintenance
Get it working in Firefox first, and then Internet Explorer
Make frequent backups! Ed Lucas's answer has some advice.

Lots of stuff omitted not necessarily because they're not useful answers, but because they're either
too detailed, out of scope, or go a bit too far for someone looking to get an overview of the things they
should know. If you're one of those people you can read the rest of the answers to get more detailed
information about the things mentioned in this list. If I get the time I'll add links to the various answers
that contain the things mentioned in this list if the answers go into detail about these things. Please
feel free to edit this as well, I probably missed some stuff or made some mistakes.

stackoverflow.com/…/what-should-a… 2/9
3/04/2009 What should a developer know _bef…
edited Mar 31 at 16:46 community wiki
Joel Coehoorn 33 revisions, 7 users
Joel Coehoorn 58%

Never put email addresses in plain text because they will get spammed to death
Be ultra paranoid about security.
Get it looking correct in Firefox first, then Internet Explorer.
Avoid links that say "click here". It ruins a perfectly good SEO opportunity.
Understand that you'll spend 20% of the time developing, 80% maintaining, so code it
accordingly.

edited Sep 16 at 14:15 community wiki

Aston

Web standards: it's cheaper to aim for standards than testing for every browser available (and in
a public website you will see a lot of different browsers/version/OS combinations (30+))
SEO-friendly URLs: changing URLs later in the game is quite painful for the developers and the
site will most probably take a PageRank hit.
Understand HTTP. If you have only worked with ASP.NET webforms, then you probably don't
really understand HTTP. I know people that have worked with webforms for years and they don't
know the difference between a GET and a POST, let alone cookies or how session works.
HTTP Caching: Understand what to cache what NOT to cache.
Optimize image weights. It's not cool to have a 20k image for a repeating background...
Read and understand yahoo's best practices
(http://developer.yahoo.com/performance/rules.html). Not every rule applies to every website.
Use YSlow for guidance, but understand its limitations.
Understand how javascript is processed on the browser. If you put tons of external scripts at the
beginning of your page, it's gonna take forever to load.
Consider cell phone usability: some users will access your site using their native cell phone
browser (I'm not talking about iPhones or Opera Mini). If your site is pure ajax, they will probably
be out of luck.
Learn the difference between 301 and 302 redirects: it's not the same for search engines.
Set up google analytics (or any other analytics package) right from the start.

Not specific to public websites, but useful nevertheless:

Server caching: identify and exploit any caching opportunities, it makes a big performance
difference. It's often overlooked on non-public websites.
Set up a good error reporting solution, with as many details as possible. You will get a lot of
errors when you launch, no matter how much you tested, so you better get all the details you
can.
Set up an Operation Database (see for example
http://ayende.com/Blog/archive/2008/05/13/DevTeach-Home-Grown-Production-System-
Monitoring-and-Reports.aspx) so you can quickly identify bottlenecks.
Set up a good deployment strategy. You will probably deploy more often than non-public sites
(we deploy daily).
Realize that web applications are inherently multi-threaded, you will have lots of visitors (typically
much more than in non-public websites), and threads are not unlimited.

edited Sep 26 at 1:33 community wiki

mausch

1. Web standards
2. Awareness of browsers
3. Awareness of accessibility
4. Awareness of usability

edited Sep 16 at 13:52 community wiki

qui

I'll add one:

how to do caching

edited Sep 16 at 13:53 community wiki

Joel Coehoorn

stackoverflow.com/…/what-should-a… 3/9
3/04/2009 What should a developer know _bef…

Rule number one of security:

Never trust user input.

edited Sep 16 at 16:03 community wiki

Jonny Barnes

It might be a bit outside of the scope, but I'd say that knowing how robots.txt and search engine
spiders work is a plus.

edited Sep 16 at 15:25 community wiki

Twan 2 revisions

Security

Validate and escape all user input. Never trust any data given by the user.
And the above will help with protecting against SQL injection.
Understand SSL
Keep your systems up to date with the latest patches.
Protect yourself from cross site scripting
How to resist session hijacking
Find out about HTTPOnly cookies
How to handle authentication/permissions
Understand PKI (public keys)
Keep up to date! This is the most important thing, make sure to follow all the latest information
about possible security issues and vulnerabilities that affect your platform.

SEO

Create SEO friendly URLs - example.com/articles/rampaging-bull-tramples-unicorn NOT

example.com?article=45
Use an XML sitemap so that site engines can crawl your site more intelligently
Set up Google Analytics (or another analytics package) from the start
Learn the difference between 301 and 302 redirects: it's not the same for search engines.
Set up a robots.txt file

Performance

How to cache
What not to cache
How to gzip
Make regular backups. Don't just rely on your hosting provider - have another backup source in
case something critical is destroyed (like a database table)
Read Yahoo's best practices (http://developer.yahoo.com/performance/rules.html) for information
on improving performance
Set up an Operation Database (http://ayende.com/Blog/archive/2008/05/13/DevTeach-Home-
Grown-Production-System-Monitoring-and-Reports.aspx) to quickly identify bottlenecks.
Look into performance monitoring

Productivity

Documentation!
Code from the beginning with maintainability in mind
Have a good deployment strategy - don't save it to the very end to figure this out.
URLs designed with REST in mind could save you a headache in the future.
Use patterns like MVC to seperate your application flow from your database logic.
Be aware of the many frameworks out there that will speed up your development
Use staging and a version control system to deploy updates so that your users won't be affected
Set up an error logging system. No matter how well coded your website will have errors when it is
released. Don't wait for the user to let you know; be proactive in identifying errors and bugs
Have a bug tracker
Know your environment. Your OS, language, database. When you need to debug it will be
important to understand how these things work at a basic level in the least.

User experience

Be aware of accessibility. This is a legal requirement for some programmers in some jurisdictions.
Even if it's not, you should bear it in mind.
Never put email addresses in plain text, or they will be spammed to death.
Have some method for users to submit their comments and suggestions

stackoverflow.com/…/what-should-a… 4/9
3/04/2009 What should a developer know _bef…
Catch errors and don't display them to the user; display something they can understand instead
Remember that cell phones and other mobile devices with browsers are becoming more common.
Sometimes they have very poor javascript support. Will your site look okay on one of these?

Core Web technologies

Understand HTTP, and things like GET, POST, cookies and sessions.
How to work with absolute and relative paths
Realize that web applications are inherently multi-threaded, you will have lots of visitors (typically
much more than in non-public websites), and threads are not unlimited.

edited Oct 14 at 14:15 community wiki

Joel Coehoorn

In addition to caching

know how to set up and gzip content.

edited Sep 16 at 14:27 community wiki

yoavf

Here are a couple thoughts.

First, staging. For most simple sites developers overlook the idea of having one or more test or
staging environments available to smoothly implement changes to architecture, code or sweeping
content. Once the site is live, you must have a way to make changes in a controlled way so the
production users aren't negatively affected. This is most effectively implemented in conjunction with
the use of a version control system (cvs, subversion, etc.) and an automated build mechansim (ant,
nant, etc.).

Second, backups! This is especially relevant if you have a database back-end serving content or
transaction information. Never rely on the hosting provider's nightly tape backups to save you from
catastrophe. Make triple-sure you have an appropriate backup and restore strategy mapped out just
in case a critical production element gets destroyed (database table, config file, whatever).

edited Sep 16 at 16:03 community wiki

Ed Lucas

You also have to:

Keep your system up to date with the latest patches.

Keep yourself up to date with knowledge of new vulnerabilities affecting your platform, and attack
techniques in general.

I follow several security related blogs and podcasts.

Bruce Schneier
Security Now!
The Register
Dark Reading

In addition, I get email alerts from SANS https://portal.sans.org/. (you need to register, but it's a great
source).

(I'm always interested in learing about other good sources, too).

edited Sep 26 at 11:14 community wiki

AJ

Valid (X)HTML - with the appropriate tags.

No broken links (See above about relative links)

edited Sep 16 at 13:50 community wiki

Raithlin

When to say "no" to the designer or client, and how to do so gracefully and diplomatically.
stackoverflow.com/…/what-should-a… 5/9
3/04/2009 y g What should a developer
g y know
p _bef…y

edited Sep 17 at 22:22 community wiki

Josh

If you have any influence on design, please read, "Don't Make Me Think" by Steve Krug. It is an easy
read, and will almost certainly make you think...

edited Sep 26 at 11:25 community wiki

Kramii

How to work with absolute and relative paths.

edited Sep 16 at 13:50 community wiki

Andrew Taylor

I would think that knowing all you can about your deployment environment will be would rank up there.

IIS, MSSQL or Apache, MySQL, etc? ASP.NET, PHP, etc?

Perhaps this is a no-brainer, but surely someone out there has written code that relies on [insert
dependency] only to find out their client's server was missing [aforementioned dependency].

edited Sep 16 at 13:55 community wiki

Jordan

Consider URLs, a URL design with REST in mind could make exposing APIs easier in the future.
Definitely much easier to get your URLs right the first time then to change them in the future and
deal with the SEO consequences.
Read Josh Porter's book Designing for the Social Web.
Have some way to accept criticism and suggestions.
Know what progressive enhancement an graceful degradation are, JavaScript is NOT a
requirement to operate the web and should be treated as such.

edited Sep 16 at 13:57 community wiki

Eric DeLabar 2 revisions

On a public site, make sure you are using an XML sitemap to help search engine crawlers crawl your
content more intelligently.

If you have non-HTML content on your site, you should also look into Google's extensions of the
sitemap protocol to make sure you are using whatever is appropriate. They have specific extensions
for News, Video, Code, Mobile-specific content and Geospatial content.

One thing I learned that was not obvious in the Google help, is that each of these content-specific
sitemaps should be a separate file and joined together at the root with a sitemap index file. For some
reason Google doesn't like you to mix content in one sitemap. Also, when you use Google Webmaster
tools to tell Google about your sitemaps, tell it about each of the special sitemaps you have
separately and use the drop-down to specify the type. You would think the crawler could use the XML
to auto-detect this stuff, but apparently not.

edited Oct 3 at 16:04 community wiki

Tim Farley

Aside from basic competence in the base language and the key technologies which might be
assumed (although shouldn't be taken for granted):

Platform - no good attempting to develop an ASP.NET application for a server that doesn't
support .NET, no good attempting to provide a SQL Server database to be hosted on a MySQL
Server... etc.
Deadline/Budget - Does it need to be done by next week and therefore potentially has lots of
quick hacks and workarounds vs. coding to strict standards and doing everything the right way.
Content - who is providing it? has it been vetted for quality and approved for publication? Have
stackoverflow.com/…/what-should-a… 6/9
3/04/2009 What should a developer know _bef…
all applicable copyrights been checked? etc
Team/Stakeholders - Who needs to be kept in the loop for development, who will the developer
be working with, who do they need to keep happy? etc. Will there be a designer or is the
developer the designer too? Don't hire a top notch developer and assume their design skills are
all that - most of them are not. I get by and can make something that looks reasonably
professional, but I wouldn't consider myself a designer even by a long stretch of the imagination.
Target Audience - savvy, not-savvy, intranet, internet. Make no assumptions here, there's a
great quote that goes "Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce bigger and better
idiots. So far, the Universe is winning."
Hardware Base - how much performance has/have the host machine(s) got? Do we have to be
concerned about limited memory/diskspace/resources? Obviously if it's only got a small amount
of memory, then we need to make sure that minimal memory resources are used in the design of
our application. Likewise for diskspace etc.
Platform - overall architectural/network topology
Maintenance - who will be maintaining this product? If the maintenance crew all have a VB
background and haven't the first clue about PHP or C#, don't write it in those languages!! If the
maintenance crew is you, then code in whatever you're most comfortable in.

This is all before you even get to a web environment really. Once you get into a web environment you
would really expect them to understand (in no particular order):

Stateless interfaces
Web protocols (HTTP/HTTPS/FTP) etc
JavaScript and/or other relevant client-side coding techniques
Various Persistence techniques - Cookies, Sessions, ViewState, ObjectState (and/or any others
that relate to the APIs being used)
At least a basic understanding of HTTP handlers and how they do their job
Page Lifecycle
Security in web environments - XSS, SQL Injection, Session hijacking etc etc.

After that:

Competence in the language used to develop the site

Knowledge of standards and best practices and an ability to apply them effectively
A good understanding of Cross browser techniques and hacks
CSS techniques and standards (if the developer is expected to design too)
Understanding of various browsers and their idiosynchrosies and workarounds

And then - if your site is data driven

An understanding of the database technologies to be used

RDBMS design and performance tuning if you're asking them to design the underlying database.
If you've got a DBA for that, then this is not such a major concern.

edited Dec 15 at 20:22 community wiki

balabaster 2 revisions

Cross-browser support, particularly with respect to CSS.

edited Sep 16 at 13:55 community wiki

Graeme Perrow

Ensure that whatever framework/server-side scripting/web server/other you're using doesn't expose
error messages directly to the user.

Checking that whatever has been put in place to facilitate the above during development is switched
off or reversed. Obviously the preference is to have this stuff properly configured in first place - but it
will still occur time and time again.

That's mainly written from a security standpoint, but very much related is the usability issue of
ensuring that should errors occur, the user get something that makes sense to them and tries as best
possible to get them back to what they were doing.

edited Sep 16 at 13:56 community wiki

Gareth Jenkins

Good knowledge of HTTP, including caching and expiry headers

edited Sep 16 at 14:30 community wiki

stackoverflow.com/…/what-should-a… 7/9
3/04/2009 What should a developer know _bef…
broady

How to build a scalable design in the off chance that the site becomes really popular.

edited Sep 16 at 14:50 community wiki

Wayne

You should consult the OWASP web site and understand the vulnerabilities listed there. Keep in mind
OWASP does not talk about issues like scalability, session state management issues, and browser
compatibility. Those areas will need to be understood as well. But I would argue that they certainly are
less important than security.

edited Sep 16 at 15:13 community wiki

Johnny Bravado

Found a new one today:

Reset Style sheets

They style sheets you included as a base-line when starting a project to give you more consistent
behavior across different browsers. See this question:
http://stackoverflow.com/questions/167531/is-it-ok-to-use-a-css-reset-stylesheet

edited Oct 3 at 15:56 community wiki

Joel Coehoorn

Well, everyone else has already mentioned most things I thought of - but one thing I always forget is a
favicon. Sounds stupid, I know, but I think it's one of those little things that helps to emphasise your
brand, and I never seem to remember it.

I agree with some of the rest too - I think it's important to know as much as possible about your
chosen language, so that you can code it with best practices and maintainability in mind. I've come
across functions and patterns that I wish I'd known about when I did my first few crappy, amateur
projects, as it would have saved me writing some retarded WTF-ey workarounds!

edited Sep 16 at 15:44 community wiki

thesmallprint

WEB STANDARDS:

HTML
CSS
XML
JAVASCRIPT

HTTP PROTOCOLS.
UI Design
Web Security
Web Caching
Some web server knowledgement ( apache HTTPD, ISS, Light HTTPD)
LAMP

edited Dec 30 at 2:40 community wiki

HBoss 2 revisions, 2 users

The most important thing for a web site developer to know is that there really is no such thing as a
standard. The standards exist, but are often ignored or are incorrectly implemented.

The only way to know if your pages are going to operate correctly on all web browsers is to try it on
every browser you can find: IE, Firefox, Opera, Safari, and Chorme for a start.

So, yes, of course, use standard practices. But then test and remove those features which do not
work across all browsers
stackoverflow.com/…/what-should-a… 8/9
3/04/2009 What should a developer know _bef…
work across all browsers.

edited Sep 16 at 14:00 community wiki

Mark T

How to avoid Cross site request forgeries (xsrf) (this is not cross site scripting (xxs))

Now i'll probably be modded down for overuse of parenthesis

edited Sep 16 at 14:32 community wiki

Marc Gear

One of the key things is to understand how you are going to debug your system. This means
understanding the 'big picture'. So know your environment (O/S, database, framework,
networking et al) and at least know where to 'look' if you have ten users each calling with their on
issue even if you did not write all that server side code.

Often times, good user interface design (error logging with the right amount of detail, log levels,
hooks to display some details on demand) will go a long way.

edited Sep 16 at 15:03 community wiki

Jay

1 2 next

Not the answer you're looking for? Browse other questions tagged best-practices
web-development security cross-platform or ask your own question.

stackoverflow.com/…/what-should-a… 9/9