web notes - a blog

Content Delivery Networks (CDNs) allow sites and applications to draw files from common servers. This allows far more efficient caching, reduces bandwidth and disk space requirements on both the server and client sides.

The next logical step are Application Delivery Networks (ADNs). These are hosted application services like WordPress’ blogs (http://wordpress.com/), Ning social network (http://www.ning.com/), Shopify ecommerce (http://www.shopify.com/), LivePerson live support (http://solutions.liveperson.com/index.asp), Kayako Support (http://www.kayako.com/solutions/hosted-support-desk/), News Letter or Paper Hosting (http://www.our-hometown.com/). The challenge is to develop an architecture that allows you to take advantage of the hosted services while integrating them seamlessly into a site.

Advantages

• Security is the responsibility of the hosting company and application provider. They know the server and the application, they can prevent and recover from problems quickly and in all likelihood, without disrupting service.
• Server administration is virtually eliminated. Application installation and maintenance is not necessary.
• Reduction of support requirements.
• Scalability is less of an issue. It is assumed that the application providers have the infrastructure to support busy sites if necessary

• Distributing the applications to other companies increases the fault tolerance of the systme. If one application crashes, the others can still run.

• A CDN can be used to deliver the design files, as well as a the home page or portal into the system. This also increases the fault tolerance of the system.

• Engineering tends to be the most expensive part of site development. Purchasing the logic allows more money to be spent on sophisiticated design interfaces, or - amazing application integration.

• Rapid deployment of extremely complex sites.

Disadvantages

• Customization may be difficult, expensive, or impossible. This includes design and functionality. WYSIWYG.
• A layer is added into the support path. The application provider must perform requested support, the site provider is dependent on them.
• Induces recurring hosting costs, which may be significant.

Supporting Trends

• The increased use of open source applications and toolkits is definitely making this vision more possible.
• The skills of web professionals are increasing exponentially
• Bandwidth is becoming a valuable commodity
• Security has become extremely important, even for ’simple’ blogs
• Cooperation within the open source community, across all boundaries
• The ability to use CSS to control the pagelayout and design allows the application to deliver well-formed XHTML that can be presented as defined by CSS. This is the key to a successful integration. Furthermore, the CSS must be assembled in such a way that it is hierarchical and observes site, application, and possibly page specific requirements.

Opportunities

• Architecture definitions
• Multiskin/multitoolkit applications
• Education
• Innovative connections

The link above is a link to Secunia, which tracks security issues for many products.

Interpreting the data is definitely subjective, for the following reasons:

• If an application is constantly being tested and reviewed for security issues, problems will be found more quickly.
• Applications with reports of many issues may simply be tested better than others.
• Applications which are very popular will also have a greater presence, as this implies greater testing.
• Development teams that are very concientious and report issues frequently will cause a greater quantity of reports than more reserved teams.
• Development teams that refrain from reporting security issues may consider that a valid approach, by reducing the information available for malicious users.
• Some applications have fundamental issues that make them more vulnerable than others.

After reviewing the reports for an application, there are several courses of action.

• Check if the application has been compromised on your server. Immediately apply any recommended upgrades or patches.
• Review the application documentation and the site/forum for additional tips on securing the application.
• Review any appropriate server security practices.
• Determine the value of any data or content involved, with an eye toward the cost of replacement or porting to a different application. Be sure to include the cost of training, learning curve (both for users and developers), administration issues, etc.
• Consider a web application firewall such as mod_security (http://modsecurity.org).
• If you have sensitive data or ecommerce, consider a hosted solution.
• Repeat

An application that can power multiple sites can greatly reduce maintenance.

Allowing users to run regular expression (REGEXP) searches through a web interface provides excellent search capabilities with very little engineering. One need only change WHERE `field`=’value’ to WHERE `field` REGEXP ‘regex’.

A problem arises if the regex entered is invalid. MySQL will report an error.

One solution that works well is to wrap the mysql_query string in a function or class method. Then, when testing for an error, check (use stristr) to see if the error was a regex error. Regex errors should be handled as user errors, not application errors. They should be logged to allow later analysis (if there are alot of regex errors, help should be provided).

Another approach is to use the PREPARE STATEMENT (see link above). This will throw an error if there are any invalid regexes.

I consider javascript the language of last resort. The browser compatibility and security issues associated with it can make it the most complex part of a page. For this reason, I strive to deliver pages to the browser ready for display. This isn’t always possible.

javascript is a vital part of web development, and I use it alot, but carefully. The following list describes some of the most common uses of javascript:

• Alert boxes (usually just debugging)
• Confirm boxes - great for ‘Are you sure … ‘ processing
• Detection of form inputs changed to ensure user doesn’t lose changes
• Changing state of buttons and inputs to disabled/readonly and back again
• Changing status displays, like colors or text on the page
• Opening new windows (window.open), often used for help and … Easter Eggs :)
• Timers (see post about Ladybug)
• Google (and other) Map APIs - these are cool http://code.google.com/apis/maps/documentation/
• Hiding content / menuing, using style.display="block/inline/none”
• Client-side validation and assisting the user in correcting errors, must revalidate on on server-side
• Page level validation - Ensuring that inputs are not only valid, but valid with respect to each other - for example if the status is ‘extended absence’, a return date must be specified. As mentioned about, server-side validation must also be performed.
• RIAs (Rich Internet Applications) - Sophisticated interfaces. These are usually based off javascript libraries & kits like dojo. Fundamental javascript skills are vital to work with the toolkits.
• Control of players - like Windows Media player and Flash
• Browser-specific page adjustments that can’t be done on the server-side
• Used to add things like Google analytics, support external data collection systems http://www.google.com/analytics/, also Google ads
• Choosing different .CSS files - often used to assist visually impaired site visitors with text size or color choices
• AJAX
• Input interaction - For example, if one input is chosen, another may be presented or set to a specific value

Tricks for debugging web pages under IE, if you don’t have any tools.

• Comment out all but the code that doesn’t work. Often the code that’s not working is broken because of something else.
• Have a separate CSS file, just for IE
• Use alert to halt javascript execution. This lets you see which command was executed prior to the failure.
• If you have a complex page, use View Source, then paste the text into a file under vi. Use grep “<div” | wc -l, and grep “</div” | wc -l to count the number of open and close divs.
• If you are using a template language such as Smarty, hard-code values for quick tests.
• Be sure to clear the cache, aka delete the temporary Internet files. Otherwise, CSS and javascript changes may not take effect.
• Refer to w3schools.com to check for supported attributes for various browsers.
• Be creative. If .style.display=’none’ doesn’t work, try removing the node.
• Limit the versions of IE you will support, and alert the user. IE6 is a good starting point.
• Accept some problems. For example, IE6 and Apache sometimes have trouble with .png transparency. Either make those images a different filetype, or allow them to display as the server delivers them and the browser displays them. It is not worth striving for perfection to support software that will eventually become obsolete.
• Use server-side logic to deliver the best code for the browser. Again, this should be limited to that which is absolutely necessary, but it is often easier to prepare the page well on the server, than to adjust it once it has been delivered to the browser.
• Use FireBug. It is bundled with dojo, and probably available as a stand-alone component.