Development Guide: UCSB static content website

(This entry has to do with my personal opinion about the way a static website should be built at UCSB and does not reflect the opinions of UCSB)

A static content website at UCSB would help with performance for a couple of the “high visibility” websites. But, it is not required. A couple of reasons why to use a static content website are described by YSlow (a plugin for Firefox): http://developer.yahoo.com/performance/rules.htm

At UCSB we should/will be creating a static content website for a couple more reasons:

1. We copy a lot of static content into multiple of our websites (mostly for MasterPages). This causes:
   1. Duplicate content in the source control system.
   2. Maintenance issues when updating websites.
   3. Excessive copy times when deploying websites (well, this may not be a very big issue).
2. A common infrastructure to look for images that are copyrighted/available for use on SA websites.

It seems that there is a need for all the developers to be on the same page when using a communal share for website static content. And in that vein here are a few Development Guidelines.

Development Guidelines:

1. The static content website urls are at:
   1. Dev: http://static.dev.sa.ucsb.edu/ (only available within the SA network)
   2. QA/Test: http://static.test.sa.ucsb.edu/ (only available to UCSB IPs)
   3. Prod: http://static.sa.ucsb.edu/ (public)
2. The base folder (/) should have sub-directories for common groupings. A few upfront common groupings are:
   1. js
   2. css
   3. images
3. Any commonly used js/css/images should be kept under the appropriate subfolder.
4. Any project specific js/css/images should be kept under a subfolder for the application.
   1. Examples: js/InsideSa, css/AAA
   2. If the website name is already taken, please use a new and appropriate name which describes the website the content is for. No restrictions, just don’t duplicate.
5. For third party components (eg: jquery) place a parent directory under the appropriate top directory (eg: js/jquery), but then place version directories underneath it.
   1. js/jquery/1_2_6
   2. js/jquery/1_3_2
6. For third party components to third party compents (eg: jqGrid) place a parent directory under appropriate third party diretory (eg: js/jquery/jqGrid), but then place version directories underneath it.
   1. js/jquery/jqGrid/1_4_3
7. Never allow dots (.) in a directory name before the static content. I haven’t found any official documentation on it, but it seems like IIS will stop looking for sub-directories once the first dot is found.
   1. For Example: If you have /js/jquery/1.2.6/jquery-1.2.6-min.js, then IIS will return a “404 File Not Found” error message for file “1.2.6”; because it considers the first dot name (1.2.6: a directory) to be the name of the file.
   2. Please use underscores (_) in place of dots in directory names.
8. When putting content into the static website always add a Version Stamp to the filename.
   1. CSS:
      1. Use a version number.
         1. Please use the same version number of your website update as the filename addition. For example: css/insideSa/InsideSaLayout-0.0.0.1.css
         2. ** alternative suggestion
   2. Javascript:
      1. Use a version number.
         1. Please use the same version number of your website update as the filename addition. For example: js/InsideSa/insideSa.menu-0.0.0.1.js
         2. ** alternative suggestion
   3. Images:
      1. Use a date/time stamp.
         1. Use the format <image name>_yyyyMMddHHmm.<ext>. For example: images/InsideSa/background_200903260203.jpg
         2. A date/time is used because multiple images with the same name can be created during development.
9. Because versioning is done in the filename, you don’t have to delete any files. Please don’t delete any files in the “common area” of the folders. The project specific folders can have files deleted if the developer(s) feel it’s okay; but we strongly suggest you don’t. Just incase some unknown project is referencing the static content.
   1. Don’t worry about the disk space, it really shouldn’t eat up too much room. And if it becomes a problem we’ll work with the systems team to come up with a good solution.
10. Javascript files should have a development version and a minified version (for production).
    1. The development (human readable) version should be formatted like the example in section 8.2.
    2. The minified version should have the same format as section 8.2 but with the extension .min.js.
       1. This means that sometimes you will have to change the names of javscript files you download. For example, Microsoft uses .js for the minified version and .debug.js for the development version.
       2. You can use jsmin.exe to minify your javascript files after development has finished.
       3. Before and after you use jsmin.exe you should run your file through jslint. jslint has a yahoo widget for it. If anyone knows of a google gadget for it, let me know. Or even a command line version, so we can add it to an automated build script.
    3. Mozilla has a great list of links for standard javascript tools.
11. New Common sub-groupings do not need to be vetted (aka, submitted for approval), just make sure that there is no appropriate sub-directory already in existence.
    1. For example: RadControls. They require that the base sub-directory be the root for all js/css/images used within their Q3 2006 dll. (This has not been done yet, because RadControls integration with MVC is not “great” yet.)
       1. Sidenote to Telerik: We really liked your Blue theme from your 2006 components. But, those Blue themes were not added to your dll’s when you started compiling your resources into them. Which makes it difficult to easily upgrade from your website based components to your web application based dlls. =(
12. The dev area will be hooked up to the source control system.
1. The dev area will be automatically updated into the source control system on Friday.
2. Please update your changes into the source control system before Friday when you see fit.
13. (UPDATE) Websites which are SSL encrypted must retrieve content through an SSL request.
1. This is due an error message which only occurs on IE. The problem has been reported multiple times (387991,388636), but the people who report it don’t suggest removing the warning. (Firefox, Safari, Opera, and Chrome do not have an error/warning message).
2. When the IE feedback stops giving me an error message after I sign in, I will add a “feedback” post which requests that the feature be dropped. The link to that “feedback” post will be attached here, so others may second the feature drop. (IE Team: please stop producing this error/warning message; its so unnecessary).

** alternative suggestion: Add version subdirectories for our applications. It can simplify things for the program. But it does complicate maintenance for the developer. Not much though. Please, ask for this if you think it will be less maintenance.

Remember: This can always be updated. And as things change this should be updated.

Technorati Tags: UCSB,staticcontent,javascript