Wednesday, September 30, 2009

YUI to the rescue

Are you still rolling your own HTML user interface components? If you are, take a look at what YUI has to offer. The advantages of leveraging YUI's standard components are abundant.

YUI Advantages:

  • Saves cost on development effort. The suite of controls are already developed and tested. This allows your team to work on more valuable tasks.
  • Excellent performance. YUI has adopted many of the great performance improvement practices that were identified in Best Practices for Speeding Up Your Web Site. Several of the performance improvements include:
    • Minified JavaScript and CSS files. This will improve page load performance with smaller files to download.
    • Aggregated or rolled-up JavaScript and CSS files. This will improve page load performance with fewer HTTP requests.
    • Yahoo will host the files on their own Content Delivery Network. In addition, Yahoo will compress and cache all of their controls for even greater performance. They also manage versioning.
  • Components are supported across all A-Grade browsers
  • Helps non-UI experts design beautiful user interfaces. Yahoo provides the design and CSS layout for all of their components.
  • 508 compliant. All components are screen reader accessible.
  • All components already have extensive documentation with many examples.
  • Reusable. You can apply the YUI controls everywhere because they are not proprietary.
  • Technology agnostic. These controls can be applied across all Web environments regardless of technology (Java, .NET, Rails, etc.).
  • Support many features that allow you to change behavior without customizing the code.
  • Thier code is clean. I validated their JavaScript with JSLint and few errors were reported. I also validated their CSS files and no major issues existed either.


YUI Disadvantages:

  • Some controls are not bullet proof. For example, there is a sorting issue with their datatable control if you embed the component within a table. However, this is not an issue if you are working in a CSS based design.
  • They do not have everything but the list is extensive.


Recommendations:

  • Try to avoid customizations. Customizing the code will make it difficult to migrate to newer versions in the future.

Monday, August 31, 2009

Preventing Buffer Overflow Attacks

Is your website resilient enough to withstand a buffer overflow attack? A buffer overflow attack is actually one of the simpler attacks a malicious user may attempt. Imagine the following scenario. You have a public facing web page that allows unauthorized users to submit data. A malicious user probes your site to see if you have exposed this vulnerability. If your site is at risk, it may only take minutes for the user to bring your site down if they employ a botnet attack.

The Attack

  • The simplest attack method is for malicious users to throw overloading (2GB - 8GB) amounts of data in a text field in hopes of crashing the server due to out of memory errors.


The Prevention

  • Bounds checking on the server-side is the most effective solution for preventing buffer overflows. For example, if you are using Spring's annotation-based validation this is all you would need:

    /**
    *
    * Spring's annotation reference documentation
    * Configuration setup example
    */
    public class Student {

    @NotBlank
    @Length(max = 50)
    private String firstName;

    @Length(min = 1, max = 50)
    private String lastName;

    }


    HTML's maxlength attribute is NOT sufficient:
    <input type="text" name="firstName" maxlength="50" />
    This is not secure because there are tools that will enable users to bypass this HTML tier of validation. You must perform max length validation on the server-side as in the example above.
  • Leverage the bulkhead stability pattern to decouple your authenticated business critical applications from your publicly exposed (more vulnerable) applications. The goal of this pattern is to preserve the stability for a particular group of customers. Most software attacks are targeted at publicly available web sites. You should leverage this pattern if you want to help preserve the stability of your authenticated users during an attack on your publicly available sites.
  • Prefer to keep public data out of session. This simple solution will help preserve memory if a user attempts a buffer overflow attack.

Friday, July 31, 2009

JavaScript Singletons

JavaScript singletons are relatively simple to create. With two additional characters you can define your object as a singleton. I'll show how this is accomplished in a moment. In my prior JavaScript post I talked about why the module pattern was preferred for creating objects. Those objects were prototype-based and multiple instances were allowed. The following examples illustrate the preferred way to create singletons with the Module pattern. This should be your preferred creational pattern for creating JavaScript singletons.

Singleton Pattern Example #1:

/*
* Singleton counter example.
*/

var mySingletonCounter = function() {

/* private, static variables */
var count = 0;

return {
/* public methods */
increment: function (inc) {
alert('Adding ' + inc + ' to count.');
count += inc;
},

getCount: function() {
alert('The current count is ' + count);
return count;
}
};
}(); // <- These two parentheses define the object as a singleton. It assigns the result of invoking this function to mySingletonCounter.


To exercise the singleton, the button below will execute the following code:

mySingletonCounter.increment(2); mySingletonCounter.getCount();
Run Singleton Counter



Singleton Pattern Example #2:

/*
* Singleton data access example.
*/

var mySingletonData = function() {

/* private, static variables */
var data = {
1: "Harry Potter and the Philosopher's Stone",
2: "Harry Potter and the Chamber of Secrets",
3: "Harry Potter and the Prisoner of Azkaban"
};

return {
/* public methods */
getData: function() {
return data;
}
};
}();


Reference the singleton object in the following manner:

mySingletonData.getData()[2];
Run Singleton Data



Advantages:

  • It is extremely simple to declare a JavaScript object as a singleton. More dynamic languages are focusing on simplicity. For example, Groovy has recently provided the @Singleton transformation to simplify Singleton creation.
  • Improved run-time performance vs the prototype-based creational pattern.
  • You still leverage all the advantages that the module pattern provides.

Saturday, June 27, 2009

Agile: A requirements change is a competitive advantage

At what point in the lifecycle should requirements be locked down?
  1. Before development begins
  2. Never
  3. Somewhere in between

Most developers will immediately choose "Before development begins" for simplicity. However, if you work in an agile environment that responds well to change then there are many advantages to "Never".

Advantages of Changing Requirements

  • Changing requirements will improve the product and should give you a competitive advantage.
  • Changing requirements will evaluate the efficiencies of your development, QA, and deployment processes. Highly effective or agile teams will deliver the new requirement relatively pain-free.
  • Changing requirements encourage automation throughout the lifecycle. The important factor here is that it encourages automation across all departments (development, QA, deployment). The following attributes must exist within each department for this strategy to be successful:

    • Development:
      • Automated JUnit tests - frequent changes must be tested efficiently.
      • Continuous Integration - frequent changes require stable environments.
      • Code reviews - This knowledge transfer session will give your team the flexibility of having anyone work any task more efficiently.

    • QA:
      • Automated regression tests - frequent changes must be tested efficiently.

    • Deployment:
      • Automated deployment scripts - simplify and more accurately deploy the changed release modules.

  • Software must be delivered faster so the customer's can identify the change points sooner in the lifecycle. The goal is to deliver testable software quicker. How many of you deliver testable code after iteration one? How many of you have customer demos of working software after iteration one? The goal is to identify changes sooner in the lifecycle and this will help minimize the risk of failing to meet your production delivery date.

Disadvantages of Changing Requirements

  • Changing requirements may delay the project. This is where the debate typically begins. However, if you initially plan for some percentage of change you should be fine. Identifying change early in the lifecycle will also help remedy the impact.

The Hybrid Example

Which auto makers were most successful with their hybrid initiatives? It was the automakers that adopted lean/agile practices many years ago. The automakers that did not change soon enough are now scrambling to recover. Changing requirements can have a huge competitive advantage if your environment responds well to change. A key attribute of being agile is adapting to change.