Quality - Time - Cost for Software (including websites)

These three factors - quality, time, and cost are the same for software as any other product or service. In most cases, two out of three will be favorable (meaning high quality, done quickly, for a low cost). On many projects, quality and fast are not achievable, for any price, unless the team can quickly find and integrate good components.

To address this, a prototype may be developed quickly to demonstrate a concept, but the risk there is that the prototype will become the end product. That’s fine if the prototype is robust enough to work.

I think the best strategy for building a system where you need all three is to focus on the foundation or architecture, limit the functionality, and use that to build on. It takes money to make money, someone will have to be paid to develop the system. If you abandon quality in favor of time and reduced cost, you may attract enough interest to fund a new system, but you risk being labeled as a low quality provider, or being saddled with code that is difficult to work with.

Research and development prior to production engineering is almost always worth it. It can be skipped if you have alot of experience.

Often, regardless of the plan, version 1.0 of a system is almost entirely discarded and replaced eventually. This is an argument in favor of a rapidly developed prototype that looks okay and functions reasonably well, but is deliberately intended only for short term use. Another approach is to focus on the system architecture more heavily so that version 1.0 may be discarded, but the underlying architecture remains. This may be a better long term plan.

Web software seems to have about a 3 year lifespan. The technology is changing so fast, and the way people use the web is changing so fast, that even an excellent site needs to be built with an eye toward adapting to future requirements.

Tags

Tags are an interesting idea - a way to highlight the content of an item to categorize it for quick access.

But assigning tags to each post in a blog can be cumbersome. It is almost redundant if there are categories.

A different approach is to create a managed tag cloud. A managed tag cloud allows you to enter a list of tags you’d like displayed, then it creates the access link to those elements in the system.

The code reads a list of tags, searches the system to count the number of occurrences, then generates the HTML to display the cloud. This eliminates the need to assign tags to content, while still providing a cloud, and representing the content in the system.

Fast CSS skin map idea

*** This post and link superseded by the ‘color map’ blog (see above) ***

The link provides a set of instructions and code which allow you to read the CSS files from a target application, then read CSS files from an existing site, and map the colors from the existing site into the target application, using sed.

This is brute force design, it would be very valuable for rapidly skinning an application to help a potential client visualize your application delivering their site.

The success of the approach is affected by the colors of both designs, this is a very simple method, the number of colors will impact how well they map.

The basic idea is to convert the colors from RGB into HSV, then reorder the HSV code into VSH - so the brightness takes precedence. In this case, it is assumed that the lightest colors will map to each other. Hue is virtually disregarded by its position.

The mechanics of the process are functioning as I wanted them to, although I haven’t tested it with live sites.

It also creates a shell script to generate image files of the colors, using ImageMagick, which is interesting but not actually used.

Requisite knowledge: Linux, PHP, bash, sed, regular expressions helpful.

I tried to put the text from the above link in the blog, but it didn’t work. Too many bizarre character strings.

Version Hiding for Server and Application Security

One of the easiest ways to make a server or application more secure it to reduce the publicly accessible information.

The above link describes how the versions can be suppressed in the HTTP headers to make it more difficult for people to identify the version of server software you are running, and the version of PHP.

This same principle should be used with applications. Any tag in the HTML that exposes the version should be suppressed.

md5('just_a_test')

With sincere thanks to the associated URL, this is .htaccess code that can be used with b2evolution to deny access to requestors who include http: or ftp: on the query string. This is slightly different than the other post - it seems to be working. [L,F] didn’t work as I would have liked.

.htaccess


RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
RewriteRule ^.*$  403.php [L]


# CATCH EVERYTHING INTO B2EVO:
# The following will allow you to have URL right off the site root,
# using index.php as a stub but not showing it.
# This will add support for URLs like:  http://example.com/2006/08/29/post-title
# Redirect anything that's not an existing directory or file to index.php
#
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ index.php [L]

403.php


header('HTTP/1.1 403 Forbidden');

I hope this is helpful.