Thomas F. Schaller, professor of political science at UMBC, offers his expertise on Maryland politics in a new Governing Magazine article that asks “Are the States Deepening the Nation’s Red-Blue Divide?”

The article explores how the expansion of unified party control and legislative supermajorities at the state level are impacting policymaking, examining what policies are being approved in strongly Republican and strongly Democratic states.

The article identifies Maryland as a Democratic state that has taken a turn to the left with recent legislation on assault weapons, education, same-sex marriage and the death penalty. “Maryland is getting bluer in election results,” says Schaller; conveying that Maryland’s GOP has become increasingly marginalized.

Yesterday’s allegations that state prison guards helped a gang operate a contraband smuggling scheme from behind bars at the Baltimore City Detention Center are prompting strong responses from Maryland lawmakers. While Sen. Brian E. Frosh said the O’Malley administration deserves credit for its role in a “very bold, aggressive and appropriate” prosecution, Del. Curtis S. Anderson called the indictments “just horrific” and asked for further explanation from the governor.

Donald F. Norris, professor and chair of public policy at UMBC, told the Washington Post that any political fallout from the episode for O’Malley, who is considering a 2016 presidential bid, will likely be determined by “how he handles this, whether he gets out in front of it.” Norris notes, “If the state were riddled with incompetence and corruption, that’d be one thing, but it’s not. … This kind of thing happens in all prison systems, though maybe not this flagrant.”

For All The World to Hear: Stories from the Struggle for Civil Rights, an oral history, outreach project of the CADVC, will present the session “Storytelling from Page to Stage: An Oral History Community Project” at the American Alliance of Museums’ (AAM) annual Meeting and Museum Expo.

The session, scheduled for Monday, May 20 from 1:45-3:00 p.m. in the Baltimore Convention Center, will tell the tale of the creation and production of For All the World to Hear. Harriet Lynn, director of the project, Sandra Abbott, CADVC, producer of For All the World to Hear, and Carrie Rennolds, graduate student, will present alongside participants in the project, who will share stories of their experience before and during the American civil rights movement.

Learn more about the session at the AAM article, “2013 AAM Annual Meeting Theme: The Power of Story,” or visit foralltheworldtohear.org.

The concept of “Promises” has changed the way we write asynchronous JavaScript. Over the past year, many frameworks have incorporated some form of the Promise pattern to make asynchronous code easier to write, read and maintain. For example, jQuery added $.Deferred(), and NodeJS has the Q and jspromise modules that work on both client and server. Client-side MVC frameworks, such as EmberJS and AngularJS, also implement their own versions of Promises.

But it doesn’t have to stop there: we can rethink older solutions and apply Promises to them. In this article, we’ll do just that: validate a form using the Promise pattern to expose a super simple API.

What is a Promise?

Promises notify the result of an operation.

Simply put, Promises notify the result of an operation. The result can be a success or a failure, and the operation, itself, can be anything that abides by a simple contract. I chose to use the word contract because you can design this contract in several different ways. Thankfully, the development community reached a consensus and created a specification called Promises/A+.

Only the operation truly knows when it has completed; as such, it is responsibile for notifying its result using the Promises/A+ contract. In other words, it promises to tell you the final result on completion.

The operation returns a promise object, and you can attach your callbacks to it by using the done() or fail() methods. The operation can notify its outcome by calling promise.resolve() or promise.reject(), respectively. This is depicted in the following figure:

Using Promises for Form Validation

Let me paint a plausible scenario.

We can rethink older solutions and apply Promises to them.

Client-side form validation always begins with the simplest of intentions. You may have a sign-up form with Name and Email fields, and you need to ensure that the user provides valid input for both fields. That seems fairly straightforward, and you start implementing your solution.

You are then told that email addresses must be unique, and you decide to validate the email address on the server. So, the user clicks the submit button, the server checks the email’s uniqueness and the page refreshes to display any errors. That seems like the right approach, right? Nope. Your client wants a slick user experience; visitors should see any error messages without refreshing the page.

Your form has the Name field that doesn’t require any server-side support, but then you have the Email field that requires you to make a request to the server. Server requests means $.ajax() calls, so you will have to perform email validation in your callback function. If your form has multiple fields that require server-side support, your code will be a nested mess of $.ajax() calls in callbacks. Callbacks inside callbacks: “Welcome to callback hell! We hope you have a miserable stay!”.

So, how do we handle callback hell?

The Solution I Promised

Take a step back and think about this problem. We have a set of operations that can either succeed or fail. Either of these results can be captured as a Promise, and the operations can be anything from simple client-side checks to complex server-side validations. Promises also give you the added benefit of consistency, as well as letting you avoid conditionally checking on the type of validation. Lets see how we can do this.

As I noted earlier, there are several promise implementations in the wild, but I will focus on jQuery’s $.Deferred() Promise implementation.

We will build a simple validation framework where every check immediately returns either a result or a Promise. As a user of this framework, you only have to remember one thing: “it always returns a Promise”. Lets get started.

Validator Framework using Promises

I think it’s easier to appreciate the simplicity of Promises from the consumer’s point of view. Lets say I have a form with three fields: Name, Email and Address:

<form>
      <div class="row">
        <div class="large-4 columns">
          <label>Name</label>
          <input type="text" class="name"/>
        </div>
      </div>
    
      <div class="row">
        <div class="large-4 columns">
          <label>Email</label>
          <input type="text" class="email"/>
        </div>
      </div>
    
      <div class="row">
        <div class="large-4 columns">
          <label>Address</label>
          <input type="text" class="address"/>
        </div>
      </div>
    
    </form>
    

I will first configure the validation criteria with the following object. This also serves as our framework’s API:

var validationConfig = {
      '.name': {
        checks: 'required',
        field: 'Name'
      },
      '.email': {
        checks: ['required'],
        field: 'Email'
      },
      '.address': {
        checks: ['random', 'required'],
        field: 'Address'
      }
    };
    

The keys of this config object are jQuery selectors; their values are objects with the following two properties:

• checks: a string or array of validations.
• field: the human-readable field name, which will be used for reporting errors for that field

We can call our validator, exposed as the global variable V, like this:

V.validate(validationConfig)
      .done(function () {
          // Success
      })
      .fail(function (errors) {
          // Validations failed. errors has the details
      });
    

Note the use of the done() and fail() callbacks; these are the default callbacks for handing a Promise’s result. If we happen to add more form fields, you could simply augment the validationConfig object without disturbing the rest of the setup (the Open-Closed Principle in action). In fact, we can add other validations, like the uniqueness constraint for email addresses, by extending the validator framework (which we will see later).

So that’s the consumer-facing API for the validator framework. Now, let’s dive in and see how it works under the hood.

Validator, Under the Hood

The validator is exposed as an object with two properties:

• type: contains the different kinds of validations, and it is also serves as the extension point for adding more.
• validate: the core method that performs the validations based upon the provided config object.

The overall structure can be summarized as:

var V = (function ($) {
    
    var validator = {
    
      /*
      * Extension point - just add to this hash
      * 
      * V.type['my-validator'] = {
      *   ok: function(value){ return true; },
      *   message: 'Failure message for my-validator'
      *   }
      */
      type: {
        'required': {
          ok: function (value) {
              // is valid ?
          },
          message: 'This field is required'
        },
    
        ...
      },
    
      /**
       *
       * @param config
       * {
       *   '<jquery-selector>': string | object | [ string ]
       * }
       */
      validate: function (config) {
    
        // 1. Normalize the configuration object  
    
        // 2. Convert each validation to a promise  
    
        // 3. Wrap into a master promise
    
        // 4. Return the master promise
      }
    };
    
    })(jQuery);
    

The validate method provides the underpinnings of this framework. As seen in the comments above, there are four steps that happen here:

1. Normalize the configuration object.

This is where we go through our config object and convert it into an internal representation. This is mostly to capture all the information we need to carry out the validation and report errors if necessary:

function normalizeConfig(config) {
      config = config || {};
    
      var validations = [];
    
      $.each(config, function (selector, obj) {
    
        // make an array for simplified checking
        var checks = $.isArray(obj.checks) ? obj.checks : [obj.checks];
    
        $.each(checks, function (idx, check) {
          validations.push({
            control: $(selector),
            check: getValidator(check),
            checkName: check,
            field: obj.field
          });
        });
    
      });
      return validations;
    }
    
    function getValidator(type) {
      if ($.type(type) === 'string' && validator.type[type]) return validator.type[type];
    
      return validator.noCheck;
    }
    
    

This code loops over the keys in the config object and creates an internal representation of the validation. We will use this representation in the validate method.

The getValidator() helper fetches the validator object from the type hash. If we don’t find one, we return the noCheck validator which always returns true.

2. Convert each validation to a Promise.

Here, we ensure every validation is a Promise by checking the return value of validation.ok(). If it contains the then() method, we know it’s a Promise (this is as per the Promises/A+ spec). If not, we create an ad-hoc Promise that resolves or rejects depending on the return value.

    
    validate: function (config) {
      // 1. Normalize the configuration object
      config = normalizeConfig(config);
      var promises = [],
        checks = [];
    
      // 2. Convert each validation to a promise
      $.each(config, function (idx, v) {
        var value = v.control.val();
        var retVal = v.check.ok(value);
    
        // Make a promise, check is based on Promises/A+ spec
        if (retVal.then) {
          promises.push(retVal);
        }
        else {
          var p = $.Deferred();
    
          if (retVal) p.resolve();
          else p.reject();
    
          promises.push(p.promise());
        }
        checks.push(v);
      });
      // 3. Wrap into a master promise
    
      // 4. Return the master promise
    }
    

3. Wrap into a master Promise.

We created an array of Promises in the previous step. When they all succeed, we want to either resolve once or fail with detailed error information. We can do this by wrapping all of the Promises into a single Promise and propagate the result. If everything goes well, we just resolve on the master promise.

For errors, we can read from our internal validation representation and use it for reporting. Since there can be multiple validation failures, we loop over the promises array and read the state() result. We collect all of the rejected promises into the failed array and call reject() on the master promise:

// 3. Wrap into a master promise
    var masterPromise = $.Deferred();
    $.when.apply(null, promises)
      .done(function () {
        masterPromise.resolve();
      })
      .fail(function () {
        var failed = [];
        $.each(promises, function (idx, x) {
          if (x.state() === 'rejected') {
            var failedCheck = checks[idx];
            var error = {
              check: failedCheck.checkName,
              error: failedCheck.check.message,
              field: failedCheck.field,
              control: failedCheck.control
            };
            failed.push(error);
          }
        });
        masterPromise.reject(failed);
      });
    
    // 4. Return the master promise
    return masterPromise.promise();
    

4. Return the master promise.

Finally we return the master promise from the validate() method. This is the Promise on which the client code sets up the done() and fail() callbacks.

Steps two and three are the crux of this framework. By normalizing the validations into a Promise, we can handle them consistently. We have more control with a master Promise object, and we can attach additional contextual information that may be useful to the end user.

Using the Validator

See the demo file for a full use of the validator framework. We use the done() callback to report success and fail() to show a list of errors against each of the fields. The screenshots below show the success and failure states:

The demo uses the same HTML and validation configuration mentioned earlier in this article. The only addition is the code that displays the alerts. Note the use of the done() and fail() callbacks to handle the validation results.

function showAlerts(errors) {
      var alertContainer = $('.alert');
      $('.error').remove();
    
      if (!errors) {
        alertContainer.html('<small class="label success">All Passed</small>');
      } else {
        $.each(errors, function (idx, err) {
          var msg = $('<small></small>')
              .addClass('error')
              .text(err.error);
    
          err.control.parent().append(msg);
        });
      }
    }
    
    $('.validate').click(function () {
    
      $('.indicator').show();
      $('.alert').empty();
    
      V.validate(validationConfig)
          .done(function () {
            $('.indicator').hide();
            showAlerts();
          })
          .fail(function (errors) {
            $('.indicator').hide();
            showAlerts(errors);
          });
    
    });
    

Extending the Validator

I mentioned earlier that we can add more validation operations to the framework by extending the validator’s type hash. Consider the random validator as an example. This validator randomly succeeds or fails. I know its not a useful validator, but it’s worth noting some of its concepts:

• Use setTimeout() to make the validation async. You can also think of this as simulating network latency.
• Return a Promise from the ok() method.

  
    // Extend with a random validator
    V.type['random'] = {
      ok: function (value) {
        var deferred = $.Deferred();
    
        setTimeout(function () {
          var result = Math.random() < 0.5;
          if (result) deferred.resolve();
          else deferred.reject();
    
        }, 1000);
    
        return deferred.promise();
      },
      message: 'Failed randomly. No hard feelings.'
    };
    

In the demo, I used this validation on the Address field like so:

var validationConfig = {
      /* cilpped for brevity */
    
      '.address': {
        checks: ['random', 'required'],
        field: 'Address'
      }
    };
    

Summary

I hope that this article has given you a good idea of how you can apply Promises to old problems and build your own framework around them. The Promise-based approach is a fantastic solution to abstract operations that may or may not run synchronously. You can also chain callbacks and even compose higher-order Promises from a set of other Promises.

The Promise pattern is applicable in a variety of scenarios, and you’ll hopefully encounter some of them and see an immediate match!

References

• Promises/A+ spec
• jQuery.Deferred()
• Q
• jspromise

The concept of “Promises” has changed the way we write asynchronous JavaScript. Over the past year, many frameworks have incorporated some form of the Promise pattern to make asynchronous code easier to write, read and maintain. For example, jQuery added $.Deferred(), and NodeJS has the Q and jspromise modules that work on both client and server. Client-side MVC frameworks, such as EmberJS and AngularJS, also implement their own versions of Promises.

But it doesn’t have to stop there: we can rethink older solutions and apply Promises to them. In this article, we’ll do just that: validate a form using the Promise pattern to expose a super simple API.

What is a Promise?

Promises notify the result of an operation.

Simply put, Promises notify the result of an operation. The result can be a success or a failure, and the operation, itself, can be anything that abides by a simple contract. I chose to use the word contract because you can design this contract in several different ways. Thankfully, the development community reached a consensus and created a specification called Promises/A+.

Only the operation truly knows when it has completed; as such, it is responsibile for notifying its result using the Promises/A+ contract. In other words, it promises to tell you the final result on completion.

The operation returns a promise object, and you can attach your callbacks to it by using the done() or fail() methods. The operation can notify its outcome by calling promise.resolve() or promise.reject(), respectively. This is depicted in the following figure:

Using Promises for Form Validation

Let me paint a plausible scenario.

We can rethink older solutions and apply Promises to them.

Client-side form validation always begins with the simplest of intentions. You may have a sign-up form with Name and Email fields, and you need to ensure that the user provides valid input for both fields. That seems fairly straightforward, and you start implementing your solution.

You are then told that email addresses must be unique, and you decide to validate the email address on the server. So, the user clicks the submit button, the server checks the email’s uniqueness and the page refreshes to display any errors. That seems like the right approach, right? Nope. Your client wants a slick user experience; visitors should see any error messages without refreshing the page.

Your form has the Name field that doesn’t require any server-side support, but then you have the Email field that requires you to make a request to the server. Server requests means $.ajax() calls, so you will have to perform email validation in your callback function. If your form has multiple fields that require server-side support, your code will be a nested mess of $.ajax() calls in callbacks. Callbacks inside callbacks: “Welcome to callback hell! We hope you have a miserable stay!”.

So, how do we handle callback hell?

The Solution I Promised

Take a step back and think about this problem. We have a set of operations that can either succeed or fail. Either of these results can be captured as a Promise, and the operations can be anything from simple client-side checks to complex server-side validations. Promises also give you the added benefit of consistency, as well as letting you avoid conditionally checking on the type of validation. Lets see how we can do this.

As I noted earlier, there are several promise implementations in the wild, but I will focus on jQuery’s $.Deferred() Promise implementation.

We will build a simple validation framework where every check immediately returns either a result or a Promise. As a user of this framework, you only have to remember one thing: “it always returns a Promise”. Lets get started.

Validator Framework using Promises

I think it’s easier to appreciate the simplicity of Promises from the consumer’s point of view. Lets say I have a form with three fields: Name, Email and Address:

<form>
      <div class="row">
        <div class="large-4 columns">
          <label>Name</label>
          <input type="text" class="name"/>
        </div>
      </div>
    
      <div class="row">
        <div class="large-4 columns">
          <label>Email</label>
          <input type="text" class="email"/>
        </div>
      </div>
    
      <div class="row">
        <div class="large-4 columns">
          <label>Address</label>
          <input type="text" class="address"/>
        </div>
      </div>
    
    </form>
    

I will first configure the validation criteria with the following object. This also serves as our framework’s API:

var validationConfig = {
      '.name': {
        checks: 'required',
        field: 'Name'
      },
      '.email': {
        checks: ['required'],
        field: 'Email'
      },
      '.address': {
        checks: ['random', 'required'],
        field: 'Address'
      }
    };
    

The keys of this config object are jQuery selectors; their values are objects with the following two properties:

• checks: a string or array of validations.
• field: the human-readable field name, which will be used for reporting errors for that field

We can call our validator, exposed as the global variable V, like this:

V.validate(validationConfig)
      .done(function () {
          // Success
      })
      .fail(function (errors) {
          // Validations failed. errors has the details
      });
    

Note the use of the done() and fail() callbacks; these are the default callbacks for handing a Promise’s result. If we happen to add more form fields, you could simply augment the validationConfig object without disturbing the rest of the setup (the Open-Closed Principle in action). In fact, we can add other validations, like the uniqueness constraint for email addresses, by extending the validator framework (which we will see later).

So that’s the consumer-facing API for the validator framework. Now, let’s dive in and see how it works under the hood.

Validator, Under the Hood

The validator is exposed as an object with two properties:

• type: contains the different kinds of validations, and it is also serves as the extension point for adding more.
• validate: the core method that performs the validations based upon the provided config object.

The overall structure can be summarized as:

var V = (function ($) {
    
    var validator = {
    
      /*
      * Extension point - just add to this hash
      * 
      * V.type['my-validator'] = {
      *   ok: function(value){ return true; },
      *   message: 'Failure message for my-validator'
      *   }
      */
      type: {
        'required': {
          ok: function (value) {
              // is valid ?
          },
          message: 'This field is required'
        },
    
        ...
      },
    
      /**
       *
       * @param config
       * {
       *   '<jquery-selector>': string | object | [ string ]
       * }
       */
      validate: function (config) {
    
        // 1. Normalize the configuration object  
    
        // 2. Convert each validation to a promise  
    
        // 3. Wrap into a master promise
    
        // 4. Return the master promise
      }
    };
    
    })(jQuery);
    

The validate method provides the underpinnings of this framework. As seen in the comments above, there are four steps that happen here:

1. Normalize the configuration object.

This is where we go through our config object and convert it into an internal representation. This is mostly to capture all the information we need to carry out the validation and report errors if necessary:

function normalizeConfig(config) {
      config = config || config;
    
      var validations = [];
    
      $.each(config, function (selector, obj) {
    
        // make an array for simplified checking
        var checks = $.isArray(obj.checks) ? obj.checks : [obj.checks];
    
        $.each(checks, function (idx, check) {
          validations.push({
            control: $(selector),
            check: getValidator(check),
            checkName: check,
            field: obj.field
          });
        });
    
      });
      return validations;
    }
    
    function getValidator(type) {
      if ($.type(type) === 'string' && validator.type[type]) return validator.type[type];
    
      return validator.noCheck;
    }
    
    

This code loops over the keys in the config object and creates an internal representation of the validation. We will use this representation in the validate method.

The getValidator() helper fetches the validator object from the type hash. If we don’t find one, we return the noCheck validator which always returns true.

2. Convert each validation to a Promise.

Here, we ensure every validation is a Promise by checking the return value of validation.ok(). If it contains the then() method, we know it’s a Promise (this is as per the Promises/A+ spec). If not, we create an ad-hoc Promise that resolves or rejects depending on the return value.

    
    validate: function (config) {
      // 1. Normalize the configuration object
      config = normalizeConfig(config);
      var promises = [],
        checks = [];
    
      // 2. Convert each validation to a promise
      $.each(config, function (idx, v) {
        var value = v.control.val();
        var retVal = v.check.ok(value);
    
        // Make a promise, check is based on Promises/A+ spec
        if (retVal.then) {
          promises.push(retVal);
        }
        else {
          var p = $.Deferred();
    
          if (retVal) p.resolve();
          else p.reject();
    
          promises.push(p.promise());
        }
        checks.push(v);
      });
      // 3. Wrap into a master promise
    
      // 4. Return the master promise
    }
    

3. Wrap into a master Promise.

We created an array of Promises in the previous step. When they all succeed, we want to either resolve once or fail with detailed error information. We can do this by wrapping all of the Promises into a single Promise and propagate the result. If everything goes well, we just resolve on the master promise.

For errors, we can read from our internal validation representation and use it for reporting. Since there can be multiple validation failures, we loop over the promises array and read the state() result. We collect all of the rejected promises into the failed array and call reject() on the master promise:

// 3. Wrap into a master promise
    var masterPromise = $.Deferred();
    $.when.apply(null, promises)
      .done(function () {
        masterPromise.resolve();
      })
      .fail(function () {
        var failed = [];
        $.each(promises, function (idx, x) {
          if (x.state() === 'rejected') {
            var failedCheck = checks[idx];
            var error = {
              check: failedCheck.checkName,
              error: failedCheck.check.message,
              field: failedCheck.field,
              control: failedCheck.control
            };
            failed.push(error);
          }
        });
        masterPromise.reject(failed);
      });
    
    // 4. Return the master promise
    return masterPromise.promise();
    

4. Return the master promise.

Finally we return the master promise from the validate() method. This is the Promise on which the client code sets up the done() and fail() callbacks.

Steps two and three are the crux of this framework. By normalizing the validations into a Promise, we can handle them consistently. We have more control with a master Promise object, and we can attach additional contextual information that may be useful to the end user.

Using the Validator

See the demo file for a full use of the validator framework. We use the done() callback to report success and fail() to show a list of errors against each of the fields. The screenshots below show the success and failure states:

The demo uses the same HTML and validation configuration mentioned earlier in this article. The only addition is the code that displays the alerts. Note the use of the done() and fail() callbacks to handle the validation results.

function showAlerts(errors) {
      var alertContainer = $('.alert');
      $('.error').remove();
    
      if (!errors) {
        alertContainer.html('<small class="label success">All Passed</small>');
      } else {
        $.each(errors, function (idx, err) {
          var msg = $('<small></small>')
              .addClass('error')
              .text(err.error);
    
          err.control.parent().append(msg);
        });
      }
    }
    
    $('.validate').click(function () {
    
      $('.indicator').show();
      $('.alert').empty();
    
      V.validate(validationConfig)
          .done(function () {
            $('.indicator').hide();
            showAlerts();
          })
          .fail(function (errors) {
            $('.indicator').hide();
            showAlerts(errors);
          });
    
    });
    

Extending the Validator

I mentioned earlier that we can add more validation operations to the framework by extending the validator’s type hash. Consider the random validator as an example. This validator randomly succeeds or fails. I know its not a useful validator, but it’s worth noting some of its concepts:

• Use setTimeout() to make the validation async. You can also think of this as simulating network latency.
• Return a Promise from the ok() method.

  
    // Extend with a random validator
    V.type['random'] = {
      ok: function (value) {
        var deferred = $.Deferred();
    
        setTimeout(function () {
          var result = Math.random() < 0.5;
          if (result) deferred.resolve();
          else deferred.reject();
    
        }, 1000);
    
        return deferred.promise();
      },
      message: 'Failed randomly. No hard feelings.'
    };
    

In the demo, I used this validation on the Address field like so:

var validationConfig = {
      /* cilpped for brevity */
    
      '.address': {
        checks: ['random', 'required'],
        field: 'Address'
      }
    };
    

Summary

I hope that this article has given you a good idea of how you can apply Promises to old problems and build your own framework around them. The Promise-based approach is a fantastic solution to abstract operations that may or may not run synchronously. You can also chain callbacks and even compose higher-order Promises from a set of other Promises.

The Promise pattern is applicable in a variety of scenarios, and you’ll hopefully encounter some of them and see an immediate match!

References

• Promises/A+ spec
• jQuery.Deferred()
• Q
• jspromise

Name:  Molissa Udevitz

Internship, Co-op or Research Site:  Alaska Department of Natural Resources Division of Forestry

Location of the Organization (City, State):  Palmer, Alaska

Title of Your Position:  Squad Leader Intern II

Major(s)/Minor(s):  Double Major - Environmental Studies and Dance

It’s easy to become jaded with an application, especially an application like Photoshop, where you open up a new document to be presented with a blank screen.

Professional results are easy to achieve with the right know-how, but professional results take time to produce even for experienced artworkers.

So this week our sister site, MightyDeals.com, has put together a great deal to spice up your copy of Photoshop. For a limited time you can get 54% off PsDefaults, a set of Photoshop resources to save time, and maybe even inspire you.

The collection, which is a collaboration between the teams at MediaLoot and WeGraphics, includes brushes, patterns, styles and shapes for Adobe Photoshop.

Compatible with almost every version of Photoshop including CS2, CS3, CS4, CS5, CS5.5 and CS6; there are more than 1600 items in the collection. That includes over 600 brushes, more than 100 actions, over 350 shapes, 200+ gradients, 150+ patterns and over 140 styles.

The resources are all royalty free and certain to save you hours of trial and error. They may even make you look at Photoshop in a whole new way.

The Ultimate Freelance Starter Kit – only $29

It’s easy to become jaded with an application, especially an application like Photoshop, where you open up a new document to be presented with a blank screen.

Professional results are easy to achieve with the right know-how, but professional results take time to produce even for experienced artworkers.

So this week our sister site, MightyDeals.com, has put together a great deal to spice up your copy of Photoshop. For a limited time you can get 54% off PsDefaults, a set of Photoshop resources to save time, and maybe even inspire you.

The collection, which is a collaboration between the teams at MediaLoot and WeGraphics, includes brushes, patterns, styles and shapes for Adobe Photoshop.

Compatible with almost every version of Photoshop including CS2, CS3, CS4, CS5, CS5.5 and CS6; there are more than 1600 items in the collection. That includes over 600 brushes, more than 100 actions, over 350 shapes, 200+ gradients, 150+ patterns and over 140 styles.

The resources are all royalty free and certain to save you hours of trial and error. They may even make you look at Photoshop in a whole new way.

The Ultimate Freelance Starter Kit – only $29