Archive for September, 2009
Tags: flex, image resolution
Posted in Blogroll | 1 Comment »
-
Monday, September 28th, 2009
One of our projects, PianoMarvel, is a finalist for an Adobe MAX award under the category of education. Help us out by voting for us here.
-
Sunday, September 20th, 2009
Custom book builders are great Rich Internet Applications that we’ve made at Rain. One core component of custom book builders is allowing users to upload their own photos. The most common user error is uploading and using a photo that cannot be printed at a high quality print resolution. It is our job to let the user know if the image he or she has selected for a particular ImageWell (a rectangle where a photo can be placed) can be printed.
Printers print according to dpi (dots per inch). Say a 1200 px x 1800 px image is printed onto a 4″ x 6″ sheet of paper. The dpi would then be:
Print resolutions can vary anywhere from 150 dpi (low/medium quality) to 300 dpi (high quality) and up.
Our Example
First we need to define two variables:
For this example we will use a final print resolution of 300 dpi and we will show a warning if the image resolution is lower than 200 dpi. The user has uploaded a low resolution 400 x 500 photo to our photo book application. The user has placed the photo into an ImageWell that is 1200 x 1200 (square). Then the user scales the image to 200% which crops the photo and lowers the dpi.
Archive for September, 2009
Tags: flex, image resolution
Posted in Blogroll | 1 Comment »
-
Tuesday, September 15th, 2009
Unit testing is a topic that creates a variety of opinions. For a lot of people it is like a first date – the first time they try to take out unit testing for a spin it seems like it is fat, slow, and impedes what you want to get done. For others, it is love at first sight.
To be honest, I still struggle to decide if I want to include unit testing in my relationship with each new project I take on. I know that it is needed, and that it really is best practice, but then I get thoughts such as:
Even though I murmur about the different times to use unit testing, as Flex and Flash keep moving to become bigger players in developing true business applications, the greater the need to verify an applications functionality.
What’s cool about Flash Builder 4 and unit testing is that we finally have a solution that is actually built into the IDE. It seems that the wars between FlexUnit, FlexMonkey, Structured Log Testing, and AsUnit were won by Flex Unit when they were crowned by Adobe to be integrated in the IDE.
If you need a refresher in what unit tests are and why they are important, check this out.
So let’s take a first date with unit tests in Flash Builder 4.
1) Create a project and create a simple class that will do some business logic we want to test. In this example, we use the standard bank account example that makes deposits and withdrawals.
package
{
public class Bank
{
public function Bank() { }
private var _balance:Number;
public function get balance():Number {
return _balance;
}
public function set balance(v:Number):void {
_balance = v;
}
/**
* Deposit some money into our bank
* @param ammount
* @return
*
*/
public function deposit(ammount:Number):Number {
_balance += ammount;
return balance;
}
/**
* Withdraw some money from our bank
* @param ammount
* @return
*
*/
public function withdraw(ammount:Number):Number {
_balance -= ammount;
return balance;
}
}
}
2) Now it’s really easy to create a test case. Just right click the class you want to test and create a new test case off it:

This will name the class what it should be called (in our case BankTest.as) and insert all of your stub functions to setup/tear down the test case. You will also notice one extra file created in your directory called FlexUnitCompilerApplication. This exists simply to be the application that runs when you execute the test cases. It will also show you a nice pretty dialogue when all your tests run successfully.
3) Configure your test case. Below is a sample:
package flexUnitTests
{
import flexunit.framework.TestCase;
public class BankTest extends TestCase
{
// please note that all test methods should start with 'test' and should be public
// Reference declaration for class to test
private var classToTestRef : Bank;
public function BankTest(methodName:String=null)
{
super(methodName);
}
//This method will be called before every test function
override public function setUp():void
{
super.setUp();
classToTestRef = new Bank();
}
//This method will be called after every test function
override public function tearDown():void
{
super.tearDown();
}
/* sample test method
public function testSampleMethod():void
{
// Add your test logic here
fail("Test method Not yet implemented");
}
*/
/**
* Do a test deposit
*
*/
public function testDesposit():void {
//Reset our balance to zero
classToTestRef.balance = 0;
//An ammount to deposit
var ammount:Number = 1000;
//Deposit the ammount
classToTestRef.deposit(ammount)
//Check to make sure that this deposit posts to the balance successfully
assertEquals(ammount, ammount);
}
/**
* Do a test on a withdrawal
*
*/
public function testWithdrawal():void {
//Reset our balance to zero
classToTestRef.balance = 1000;
//An ammount to withdraw
var ammount:Number = 400;
//What the end ammount of our withdrawal should be
var endAmmount:Number = 600;
//Withdraw the ammount
classToTestRef.withdraw(ammount);
//Check to make sure that this withdrawal posts to the balance successfully
assertEquals(endAmmount, endAmmount);
}
}
}
Now just run your test! See, it’s that easy!

If you are successful, you will see two screens with the results of your tests. The first will be in the browser, but the most useful one will be right inside your IDE where you can see which tests executed successfully and which ones did not.

So there you go. That was a nice, easy first date with unit tests in Flash Builder 4!
Archive for September, 2009
Posted in Blogroll, debugging, flash, flex | No Comments »
-
Friday, September 4th, 2009
Automagic is authoritatively defined by wiktionary as “Automatic, but with an apparent element of stage magic. Commonly used in computer and other technology fields, referring to complex technical processes hidden from the view of users or operators.”
While, Cake’s automagic features are what make the framework useful, they can often turn around and bite you. Though it is not necessary to understand the full implementation details of every automagic feature, it is important to be aware of some common issues.
You can link models together using associations. When using the find function, Cake automagically fetches associated data. This may cause the database to execute queries for data that is never used. The Containable Behavior is one of the best solutions to reduce the amount of data fetched.
The Containable Behavior is covered pretty well in the CakePHP book. Basically, it allows you to specify which associations you want to be included in a find query. It’s fairly new to CakePHP; before it was introduced in CakePHP 1.2, the recursive property and/or the undbindModel method were primarily used to pare down find results (if they were even pared down at all). The Containable behavior allows you to accomplish the same task in a much simpler and cleaner way.
An example of an association type is hasAndBelongsToMany (many to many). Again, the CakePHP book is a good source for learning how to save hasAndBelongsToMany data.
A key line in the docs is the following: “Cake will delete all rows on the join table before saving new ones.” It is important to be cautious when saving data with hasAndBelongToMany associations. The following example illustrates a reason for such a caution:
$options = array(
‘conditions’ => ‘Recipe.id’ => $recipeId
);
$data = $this->Recipe->find(‘first’, $options);
//Changes to $data
$this->Recipe->save($data);
If you had any hasAndBelongsToMany associated data, such as RecipeTags, these records would all be deleted. This was an unfortunate lesson I learned on a recent project.
In /app/config/core.php, you can set the debug level. There are four levels, 0-3. In the comments of this configuration file, it explains what to expect at the various levels. For levels greater than 0, model caches are refreshed.
If you are new to CakePHP, you may not understand what is meant by “model caches refreshed”. In app/tmp/cache/models you’ll find a file for every model containing a cached version of the database schema.
If you make a change to your database schema when the debug level is 0, these model caches won’t be refreshed; if you get errors or unexpected behavior after making a database change, a likely fix is rm -f app/tmp/cache/models/*.
If you ever decide to clear the cache by removing the tmp directory, remember to rebuild the directory structure and recursively set the permissions to be writable by the web server.
Be careful not to set debug to greater than 0 on a production system. Besides displaying errors and warnings, leaving your system in development mode will make requests take longer. CakePHP runs a describe query and rebuilds the cache file for each model in use.
Cake’s AuthComponent can add authentication to a site quickly and easily. However, if you don’t understand all the trickery that goes on, you can encounter some issues when your implementation varies from the example in the CakePHP book. I recently ran into some trouble when building a registration form. As is typical of registration forms, there is a password field. I wanted to include all my validation rules in the model.
When I submitted the registration form, I would consistently get a password matching error, even though the password and confirm password were the same. I discovered the AuthComponent hashes the password field when you post data via a form. Though there are numerous ways to get around this, here is my preferred approach (this snippet belongs in the User model):
var $validate = array(
'confirm_password' => array(
'minLength' => array(
'rule' => array('minLength', 6),
'message' => 'Passwords should be at least six characters long.',
),
'matching' => array(
'rule' => 'comparePasswords',
'message' => 'Passwords do not match.'
)
...
);
function comparePasswords()
{
if(
$this->data[$this->name]['password'] ==
Security::hash($this->data[$this->name]['confirm_password'], null, true)
)
{
return true;
}
return false;
}
Notice how validation is performed on the confirm_password field. This allows you to specify length and other requirements on an unhashed version of the password. I typically display errors in list form. If you wanted to display an error message next to the password field, you would need to adjust the code to also invalidate the password field.
Archive for September, 2009
Tags: Auth Component, CakePHP, Containable Behavior, hasAndBelongsToMany Association
Posted in Blogroll, php | 4 Comments »
-
Wednesday, September 2nd, 2009
Things that make us happy:
Archive for September, 2009
Posted in Blogroll, clients, iPhone | 2 Comments »
Archive for September, 2009
Tags: adobe max, education, piano marvel
Posted in Blogroll | No Comments »