This has many possible applications for file transfer, but for instance, if you're writing an HTML5 / PhoneGap app for iOS 5, and you want to download an attached file from the current version (v23.0) of the Chatter REST API, you need to send a GET request to:

https://test.salesforce.com/services/data/v23.0/chatter/files/[PUT THE FILE ID HERE]/content?versionNumber=1

But, you have to include a few headers for authentication…

setRequestHeader("Authorization", "OAuth " + oauthToken);

setRequestHeader('X-User-Agent', 'salesforce-toolkit-rest-javascript/v23.0');

…so it's not like you can just dump the GET request into the src of an <img> tag. So, what you can do now in iOS 5 is send off an XMLHttpRequest with a responseType of "arraybuffer", and use this data to write to a HTML5 Canvas object.

Here's the XMLHttpRequest:

And here's the body of the callback that handles Base64 encoding the arraybuffer and writing that data to a Canvas using the Data URI Scheme:

The code for this app will be released on Github.

To play, you must first register at http://bit.ly/dreamforcenger.

You can then download and log into the Dreamforcenger Hunt app, which is available in the Android Marketplace:

Rules of the Game

1. Dreamforcenger Hunt is played by registering and installing the Dreamforcenger Hunt app on your Android phone. This app is available in the Android Market. In the app, you will find a list of clues for scavenger hunt locations around San Francisco. To find a location, you will have to go to that location, and click the "Geotag It!" button. If you have found the item, the app will tell you so, and it will be marked as found in Database.com for your user.

2. The person that finds the most scavenger hunt items will win the prize, a Samsung Galaxy Tab 10.1

3. To be eligible to win, you don't need to attend the Application Development with Android session, but you do need to be a Dreamforce 2011 attendee.

4. Employees of Model Metrics and Salesforce.com may participate in the scavenger hunt, but are ineligible to win the prize.

5. In the event of a tie, the winner will be chosen at random from among the tied users.

6. Additional hunt locations may be added after the game begins, so if you find all of them, don't assume more won't be added.

7. The game ends at Noon, PST, on Friday, September 2. A winner will be chosen at that time. The winner may pick the prize up in person, or if that is impossible, the prize will be mailed to the winner at a later date.

8. You must register with your real name and email address. Accounts that use obviously fake names or email addresses will be deactivated.

9. Any attempts to hack the system will result in an ineligibility to win the prize. Please play fair.

10. Have fun!

oAuth 2.0 is a popular universal specification for authentication to various web services. If you've used a mobile app that logs into Facebook, Twitter, LinkedIn, or Chatter, you've probably used it. for Salesforce.com provides four different authentication flows:

• Web Server
• User-Agent
• Refresh Token
• Username/Password

A combination of the User-Agent flow and Refresh Token flow are recommended for mobile applications, so that's what I'll demonstrate here.

First off, you should understand both flows from a high level:

Salesforce Configuration

Both the User-Agent flow and the Refresh Token flow require a Remote Access Application be set up in the target SFDC org. This is configured under Setup=>Develop=>Remote Access. Required fields are Application, Contact Email, and Callback URL. There are a variety of rules about what the Callback URL can be, but the simplest way to do this is to have it be: https://login.salesforce.com/services/oauth2/success

Once saved, SFDC will generate and display a Consumer Key and a Consumer Secret. Both of these will be needed by the application for login.

User-Agent Flow

The User-Agent flow involves the use of a webview within the application. The app passes a special Salesforce.com URL to that webview, which renders a login view. 

First, the user will be asked to log in, and then they will be asked to confirm that they would like to provide access to Salesforce.com using this application:

The URL passed to SFDC in order to render this login view is in this format:

https://login.salesforce.com/services/oauth2/authorize?

response_type=token&

display=touch&

client_id=[CONSUMER KEY FROM REMOTE ACCESS]&

redirect_uri=https%3A%2F%2Flogin.salesforce.com%2Fservices%2Foauth2%2Fsuccess

Upon successful login, SFDC will redirect the webview to the URL specified as the redirect_uri (which must be the same as the Callback URL specified in the Remote Access Application setup). After the Callback URL will be a hash tag and then a series of parameters returned by Salesforce:

access_token=[ACCESS TOKEN (Session Id)]

&refresh_token=[REFRESH TOKEN]

&instance_url=https%3A%2F%2Fna1.salesforce.com

&id=https%3A%2F%2Flogin.salesforce.com%2Fid%[ORG ID]%[USER ID]

&issued_at=1312403866216

&signature=[SIGNATURE]

The Access Token specified here is the Session ID that will be used for all subsequent calls to the API. The Refresh Token must be saved securely to disk, as it will be used in conjunction with the Consumer Key and Consumer Secret to get a new Access Token from SFDC when the current on expires. The Org Id, User Id, Issued At Time (number of milliseconds since the Unix Epoch), and Signature should be saved as well.

Refresh Token Flow

At some point in time, your Access Token will expire. This may come as a shock, so be sure to prepare your friends and family. The app will learn that the session ID has expired when it attempts to access the API and the response is either:

• SOAP API: HTTP 500 Internal Server Error, with a faultCode: <faultcode>sf:INVALID_SESSION_ID</faultcode>
• REST API: HTTP 401 Unauthorized

The amount of time a session ID remains valid is configured under Security Controls => Session Settings  in SFDC Setup. When it expires, the app will have to use the Refresh Token flow to request another Access Token from SFDC. To do this, the application will send a POST request to SFDC including the Refresh Token, the Consumer Key, and the Consumer Secret. SFDC will respond with a new Access Token.

NOTE: At no time does the application store the Username or Password of the individual logging into the app.

So, that's it. I hope you've enjoyed this foray into the world of oAuth 2.0 and Salesforce.com.

Enter DiffDog…

DiffDog is a great tool for validating that the metadata between two orgs is identical, and, when used in conjunction with Eclipse, it can be used to push changes from one org to another. It can be used to compare any of the metadata types that are able to be checked out using Eclipse: Objects, Page Layouts, Profiles, Workflow, Reports, etc. The main benefit with this tool over other diff tools is that it allows for the comparison of XML files with ignoring the order of XML nodes. This is important because the metadata between two orgs is XML based, and can be functionally identical, but rendered in different orders. Because of this, with a regular flat-file diff tool, you will get lots of false positives. DiffDog can be configured to properly compare XML files, thus eliminating these false positives. This post describes some optimal settings for use with SFDC, and the process for comparing orgs and deploying changes.

To start with, download the tool from Altova: 

http://www.altova.com/download/diffdog/diff_merge_tool_professional.html

Setup

Once you've downloaded the app and registered it, go to the Tools menu, choose "Comparison Options", and select the XML tab. This part is important: you want to make sure the comparison ignores the order of child nodes. This basically means that XML nodes can be rendered in any order and still be considered identical. Click the "Ignore order of child nodes" box in the Order section. All of the other options should be default, but double-check to make sure they match this screenshot.

Additionally, if "quick" diff is turned on for folder comparison (it will be by default), make sure to turn it off:

You want to do extension-based comparison (EXT):

Check Out the Orgs

You will now have to check out the metadata objects that you want to compare from both SFDC orgs using Eclipse. Let's assume one org is a sandbox and one is production. Note that if you want to compare profiles, you will need to select all of the metadata types for everything that you want to compare profile permissions for. For instance, if you want to compare Field-Level Security on Custom Objects, you will need to check out Profile metadata AND Custom Object metadata. SFDC only sends the profile metadata for the metadata types that you have checked out. If you try to do only profiles, the files will be practically empty.

The metadata from the two orgs that you checked out will be located in your Workspace directory. You can generally figure out where this is by right-clicking on one of the files in Eclipse, and selecting "Properties".

Using DiffDog

You'll then want to pick a metadata type and open the two org's folders for that type in DiffDog. For instance, to compare Objects, select "Compare Directories" from the File Menu…

…and then select a metadata folder for each org. I'd suggest putting your sandbox org on the left and your production org on the right so that you're moving changes from left to right, but you can do it either way.

Once you've done this, DiffDog will initiate a high-level diff of all files in the directories, and will display something like this. Lines displayed in black are identical, lines displayed in Red have differences, and lines in blue are missing in one org or the other.

If you need to move an entire object over, you can do that here by clicking on the blue name and pressing the "Copy from left to right" or "Copy from right to left" button, depending on which direction you want to go.

If you want to inspect the differences between two files, double-click on one, and it will launch a flat file-based diff that looks something like this:

This is not what you want. You want to select the "Grid View" tab at the bottom left of the window. This launches the grid-based diff tool that will show you differences between the two metadata objects:

Differences are highlighted in light green, and the "current difference" is highlighted in a darker green. To move a change from one org to another, you'll have to click on the box in the grid in the org you want to move FROM, and then click the "Make current difference" button in the top toolbar (or hit Alt-Enter) to highlight it in dark green.

Once you've done this you can copy the change over with the "Copy from Left to Right" button:

Deploying Your Changes

You'll then want to save (Ctrl-S or File=>Save). This will save your changes locally. Note that they have not yet been deployed to SFDC. To do this, you'll have to go back to Eclipse. Find the file (or group of files) that you saved in your Eclipse project, right click on it, and select "Refresh". This will cause Eclipse to attempt to deploy your changes to SFDC. This could result in one or more errors, so be sure to watch the Problems tab for any errors. If you're deploying to Production, this step can take some time if the org has a lot of Apex code, because all tests will be re-run when you deploy. A minute or so is common. 10-15 minutes isn't unheard of.

This is just a round-up of some of these posts, and the advice given. They've been edited down, of course, so be sure to read each of these articles for the whole story:

The Cloud is Not a Silver Bullet – Joe Stump, CTO of SimpleGeo

• Everything needs to be automated. Spinning up new instances, expanding your clusters, backups, restoring from backups, metrics, monitoring, configurations, deployments, etc. should all be automated.
• You must build share-nothing services that span AZs at a minimum. Preferably your services should span regions as well, which is technically more difficult to implement, but will increase your availability by an order of magnitude.
• An avoidance of relying on ACID services. It’s not that you can’t run MySQL, PostgreSQL, etc. on the cloud, but the ephemeral and distributed nature of the cloud make this a much more difficult feature to sustain.
• Data must be replicated across multiple types of storage. If you run MySQL on top of RDS, you should be replicating to slaves on EBS, RDS multi-AZ slaves, ephemeral drives, etc. Additionally, snapshots and backups should span regions. This allows entire components to disappear and you to either continue to operate or restore quickly even if a major AWS service is down.
• Application-level replication strategies. To truly go multi-region, or to span across cloud services, you’ll very likely have to build replication strategies into your application rather than relying those inherent in your storage systems.

How SmugMug survived the Amazonpocalypse – Don MacAskill, CEO of SmugMug

• Spread across as many AZs as you can. Use all four.
• If your stuff is truly mission critical (banking, government, health, serious money maker, etc), spread across as many Regions as you can.
• Beyond mission critical? Spread across many providers.
• Since spreading across multiple Regions and providers adds crazy amounts of extra complexity, and complex systems tend to be less stable, you could be shooting yourself in the foot unless you really know what you’re doing.
• Build for failure. Each component (EC2 instance, etc) should be able to die without affecting the whole system as much as possible.
• Understand your components and how they fail. Use any component, such as EBS, only if you fully understand it. For mission-critical data using EBS, that means RAID1/5/6/10/etc locally, and some sort of replication or mirroring across AZs, with some sort of mechanism to get eventually consistent and/or re-instantiate after failure events.
• Try to componentize your system. Why take the entire thing offline if only a small portion is affected?
• Test your components. I regularly kill off stuff on EC2 just to see what’ll happen.

AWS outage timeline & downtimes by recovery strategy – Eric Kidd, Randomhacks.net

Eric took an interesting look at various potential strategies, and how long a company would have been offline during the EBS outage:

• Rely on a single EBS volume with no snapshots: 3.5 days
• Deploy into a single availability zone, with EBS snapshots: over 12 hours
• Rely on multi-AZ RDS databases to fail over to another availability zone: longer than 14 hours for some users.
• Run in 3 AZs, at no more than 60% capacity in each: This is the approach taken by Netflix, which sailed through this outage without no known downtime
• Replicate data to another AWS region or cloud provider: This is still the gold standard for sites which require high uptime guarantees.

The AWS Outage: The Cloud's Shining Moment – George Reese, Founder of Valtira and enStratus

The Amazon model is the "design for failure" model. Under the "design for failure" model, combinations of your software and management tools take responsibility for application availability. The actual infrastructure availability is entirely irrelevant to your application availability. 100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage…

There are several requirements for "design for failure":

• Each application component must be deployed across redundant cloud components, ideally with minimal or no common points of failure
• Each application component must make no assumptions about the underlying infrastructure—it must be able to adapt to changes in the infrastructure without downtime
• Each application component should be partition tolerant—in other words, it should be able to survive network latency (or loss of communication) among the nodes that support that component
• Automation tools must be in place to orchestrate application responses to failures or other changes in the infrastructure (full disclosure, I am CTO of a company that sells such automation tools, enStratus)

Today’s EC2 / EBS Outage: Lessons learned – Stephen Nelson-Smith, Technical Director of Atalanta Systems

• Expect downtime…What matters is how you respond to downtime
• Use amazon’s built-in availability mechanisms
• Think about your use of EBS:
  • EBS is not a SAN
  • EBS is multi-tenant…Consider using lots of volumes and building up your own RAID 10 or RAID 6 from EBS volumes.
  • Don’t use EBS snapshots as a backup…Although they are available to different availabilty zones in a given region, you can’t move them between regions.
  • Consider not using EBS at all
• Consider building towards a vendor-neutral architecture…Cloud abstraction tools like Fog, and configuration management frameworks such as Chef make the task easier.
• Have a DR plan, and practice it
• Infrastructure as code is hugely relevant…one of the great enablers of the infrastructure as code paradigm is the ability to rebuild the business from nothing more than a source code repository, some new compute resource (virtual or physical) and an application data backup.

I was intrigued by the rather excellent post over at the blog Il y a du thé renversé au bord de la table, [Rant] Web development is just broken. Yoric makes the argument that web developers are forced to deal with too many "nightmares" that have very little to do with programming. First you have to decide on a programming language. Should you use PHP, C#, Java, Ruby, Perl, or Python? Then you have to choose a web server and OS. Windows/IIS or *nix and Apache? OSX? BSD? Solaris? If you go with Linux, which distro do you choose? Is it worth it to pay for Red Hat, or will Fedora do? What about Ubuntu? Then you have to choose a DBMS, of course. Do you want Oracle? Well, can you afford Oracle? Then there's MySQL, SQLServer, or PostgreSQL. Or maybe one of the NoSQL databases like MongoDB, CouchDB, or Cassandra. And then you probably want to choose a server-side framework. Rails? Spring? Zend? And a client-side framework, of course, so you don't have to worry too much about all the differences between the JS engines in each different browser. JQuery? Prototype? Scriptaculous?

And then, once everything is selected, it all has to be configured to work together without (too many) security holes. But, of course, how much does the average developer really know about configuring a secure Linux environment with Apache? Or setting up a secure IIS? And even if the developer does know a lot about configuring all of this, wouldn't it be more productive to have him or her focused on developing actual application features rather mucking around in Apache2.conf or php.ini, or trying to figure out why their package manager can't find the right package for some random server component? How do I configure CPAN, again? Do I really need the Multiverse, or will the Universe do? Then, of course, you'll probably want an ORM, and you'll need to decide on how you want to glue all the bits and pieces together.

Not to mention keeping all of that up to date and working as new releases get rolled out… oh, and what about scaling up to meet the increased demand if you start to get really popular and get bought by Conde Nast?

Great points. Couldn't agree more. Anybody guess where I'm going with this? 

Tired of worrying about infrastructure? You want to start coding now? Great, take a look at Elastic Beanstalk, Heroku, or Force.com VMForce (yeah, I know, "coming soon"). No infrastructure setup required. You still have to choose a language and a platform, I guess, but that seems unavoidable. You have to make some choices in life. However, you don't have to care about which OS or web server to use, and you don't have to manage updates of server software. AWS might all be running in VMWare within a virtualized Windows 98 stack based on a billion hand-built Commodore 64s for all I care. As long as it works. And the DBMS is a service too… you don't have to set it up, you just pick whichever one you want. When VMForce is launched, you'll have database.com as a DBMS. With Elastic Beanstalk, you have RDS or SimpleDB. With Heroku, you have PostgreSQL out of the box, with a ton of other choices available, but you don't set them up yourself, you just add them to your account, and they get set up for you.

What about security? Does your data center have 24-hour manned security, including foot patrols and perimeter inspections? Well, Salesforce does. Is your server certified by PCI, ISO, SAS70, and HIPAA? Well, AWS is, and Heroku is hosted on AWS, and they have their own operations team that monitors the system 24/7. Even Multi-Factor Authentication is just another service at AWS. And if somebody finds a security flaw in any of these platforms, it's not your problem. Somebody else can figure it out and fix it, hopefully before you even know about it. Of course, it's still important to write secure code, sanitize user inputs, parameterize SQL queries, etc., but at least that's all in _your_ code. You can focus on writing good code, and not on whether or not you accidentally configured an Apache mod incorrectly, or accidentally allowed anonymous FTP access to your web server, or if your version of PHP has a buffer overrun bug that will allow some random hacker to drop your User table.

You'll probably still need to glue some things together, and if you're doing web development, you'll still want a client-side framework so you don't have to worry too much about all the various inconsistencies between browsers, but with the infrastructure headaches out of the picture, it's easier to just start coding.

Password

• Required
• No Repeating/Ascending/Descending Characters
• Require Alphanumeric
• Minimum Password length
• Minimum number of non-alphanumeric characters required
• Maximum password age (1-730 days)
• Auto-lock (1-5 minutes)
• Password History (1-50 Passwords)
• Grace Period for Device Lock (amount of time the device can be locked without prompting for a password on unlock)
• Maximum number of failed attempts (before all data on device will be erased)

Restrictions

• Allow installing apps
• Allow use of camera
  • Allow FaceTime
• Allow Screen Capture
• Allow Automatic Sync while Roaming
• Allow voice dialing
• Allow In App Purchase
• Allow Multiplayer Gaming
• Allow Adding Game Center Friends
• Force Encrypted Backups
• Applications
  • Allow use of YouTube
  • Allow use of iTunes Music Store
  • Allow use of Safari
    • Enable autofill
    • Force fraud warning
    • Enable JavaScript
    • Block Pop-ups
    • Accept Cookes: Always, Never, From Visited Sites
    • Allow Explicit Music & Podcasts
  • Allowed Content Ratings
    • Movies: Don't Allow Movies, G, PG-13, R, NC-17, Allow All Movies
    • TV: Don't Allow TV Shows, TV-Y, TV-Y7, TV-G, TV-PG, TV-14, TV-MA, Allow All TV Shows
    • Apps: Don't Allow Apps, 4+, 9+, 12+, 17+, Allow All Apps

Wi-Fi

• Service Set Identifier (SSID)
• Hidden Network (if target network is set to not broadcast)
• Security Type: Any (Personal), None, WEP, WPA/WPA2, WEP Enterprise, WPA/WPA2 Enterprise, Any (Enterprise)
• Password

VPN

• Connection Name
• Connection Type: L2TP, PPTP, IPSec (Cisco), Cisco AnyConnect, Juniper SSL, F5 SSL, Custom SSL
• Server Hostname or IP Address
• Account
• User Authentication: Password, RSA SecurID
• Shared Secret
• Send All Traffic (Route all network traffic through VPN)
• Proxy Setup

Email

• Account Description
• Account Type: IMAP, POP
• User Display Name
• Email Address
• Mail Server and Port
• Authentication Type: None, Password, MD5 Challenge-Response, NTLM, HTTP MD5 Digest
• Password
• Use SSL

Exchange ActiveSync

• Account Name
• Exchange ActiveSync Host (Exchange Server)
• Use SSL
• Domain
• User
• Email Address
• Password
• Past Days of Mail to Sync: No Limit, 1 Day, 3 Days, 1 Week, 2 Weeks, 1 Month
• Authentication Credential Name
• Authentication Credential
• Include Authentication Credential Passphrase

LDAP

• Display Name
• Account Username
• Account Password
• Account Hostname
• Use SSL
• Search Settings

CalDAV

• Account Description
• Account Hostname and Port
• Principal URL
• Account Username
• Account Password
• Use SSL

CardDAV

• Account Description
• Account Hostname and Port
• Principal URL
• Account Username
• Account Password
• Use SSL

Subscribed Calendar

• Description
• URL
• Username
• Password
• Use SSL

Web Clips (web pages saved to the home screen as bookmarks)

• Label
• URL
• Removable (yes/no)
• Icon
• Precomposed Icon
• Full Screen

Credentials

• Specify PKCS1 and PKCS12 certificates needed to authenticate access to your network

SCEP

• URL for SCEP server
• Name
• Subject (representation of X.500 name)
• Subject Alternative Name Type (None, RFC 822 Name, DNS Name, Uniform Resource Identifier)
• Subject Alternative Name Value
• NT Principal Name
• Challenge
• Key Size: 1024, 2048
• Use as digital signature
• Use for key encipherment
• Fingerprint (hex string)

MDM

• MDM Server URL
• Check in URL
• Topic (Push notification topic for management messages)
• Identity: Add credentials in Credentials payload, SCEP
• Sign Messages: yes/no
• Access Rights granted to remote administrators:
  • Query Device for:
    • Device Information
      •  
      • unique device identifier (UDID)
      • device name
      • iOS version
      • device model name and hardware version
      • serial number
      • overall and available storage capacity
      • IMEI number
      • the modem firmware version
      • SIM card ICCID
      • and MAC addresses for integrated Wi-Fi and Bluetooth
      • carrier currently being used
      • the carrier specified by the current installed SIM card
      • the version of the carrier settings (APN) data
      • assigned phone number
      • whether or not data roaming is currently allowed
      • list of configuration profiles installed
      • list installed security certificates and expiry dates
      • list of enforced restrictions
      • hardware encryption capability
      • whether an unlock passcode is set
      • installed applications (with App identifier, name, version, and size)
      • a list of any application provisioning profiles with expiration dates.
  • General Settings
  • Security Settings
  • Network Settings
  • Restrictions
  • Configuration Profiles
  • Applications
  • Provisioning Profiles
• Add / Remove:
  • Configuration Profiles
  • Provisioning Profiles
• Security
  • Change device password
  • Remote Wipe
• Apple Push Notification Service
  • Use Development APNS Server

Advanced

• Access Point Name (APN): The name of the GPRS access point
• Access Point User Name
• Access Point Password
• Proxy Server and Port

Mechanics, Dynamics, and Aesthetics (MDA)

So what makes a game? Bunchball discuss the terms "game mechanics" and "game dynamics" in their white paper, and those terms come from a game design approach called MDA (Mechanics, Dynamics, Aesthetics), described by Hunicke, LeBlanc, and Zubek in their article MDA: A Formal Approach to Game Design and Game Research. The idea is basically that a game designer creates various rules for a game (Mechanics). These rules then work together (in sometimes unexpected ways) to create a system (Dynamics). And a player experiences these Dynamics through the Aesthetics of the game, which they categorize into things like "Challenge", "Discovery", or "Narrative". So, the game designer sets up the game by manipulating the Mechanics, and the player experiences the game through the Aesthetics. Put simply, if the designer can directly manipulate something by changing the rules of the game, it is part of the game mechanics. Dynamics are manipulated indirectly by the designer, and aesthetics are experienced by the player. Game design is complicated, then, because the experience of the player is two steps removed from the rules set forth by the designer.

A simple example can be illustrated with the game of Poker. The mechanics of the game involve dealing cards, anteing, and betting. The dynamics of the game have emerged over time to include things like bluffing. And the aesthetics of the game include things like fellowship (it's a good game to play with friends) and challenge (your opponents present many obstacles to winning).

Success!

So what makes a game fun? Every game uses game mechanics, but many have been utter failures. What makes a gamification strategy successful? It's easy to throw together leader boards, loyalty programs, and point systems, but how do you actually drive behavior with gamification? And what exactly is a game anyway? It's one of those things that you know when you see it, but how do you actually define it? Chris Crawford offers an interesting definition of "game" in his book, Chris Crawford on Game Design, Basically, if there is no competition (either amongst players or against some form of AI), then what you have is a puzzle, not a game. Additionally, if you have no influence over how your opponent is performing, then that competition isn't a game either. By this definition, solitaire is a puzzle, because there is no competition. A drag race is a competition, but not a game, because you can't slow the other car down in any way. However, a race where you are allowed to run your opponent off the road is a game.

So, does a successful gamification strategy need to follow this definition? Does there need to be competition, and should employees or customers be able to alter other's ability to perform? Perhaps not, but competition is likely to be important in any successful gamification strategy.

Pitfalls

So, what are some pitfalls of game design? If some players are able to get too far ahead of the pack, does it create a disincentive for the rest of the players? How can you reward top players without discouraging everyone else? Consider Monopoly: The game starts out fun for everyone, but as one or more players start buying up all the property, the "poorer" players get less and less interested in completing a game that they have very little chance of winning. How could the mechanics of Monopoly be adjusted to keep everyone engaged? It's important to consider positive and negative feedback loops in the game. Monopoly has a strong positive feedback loop. The more property a player has, the more money they make from other players, which they use to purchase more and more property. To cancel this out, one could adjust the game mechanics to include, say, theft. This could introduce a negative feedback loop by making players who are doing well more likely to have property stolen by players on the poverty side of the equation.

Frequent flyer programs have a similar problem. People who fly frequently form loyalties to airlines because they have so many points built up that they are able to reap the benefits of the program. People with few points have little incentive to be loyal to any specific airline because they are a long way from "leveling up" and seeing any tangible benefit from the program. The airlines probably don't care as much about these infrequent flyers, but they may be missing out on nurturing loyalties in people who may become more frequent flyers in the future. These "players" could be incentivized to by being entered in a drawing each time they fly, or randomly getting free drinks or being upgraded to first class when seats are available.

Overall

Overall, I think it's really exciting that business leaders are starting to consider employee and customer motivation from the perspective of the game designer, and it's nice to see some formalized thought being put forward that takes some lessons from "regular" game designers and researchers. It will be interesting to see what innovative groups like Bunchball come up with over time.

Reasons why you may want to consider using SES

1. Ever receive an email from Amazon.com? Yeah, so has everybody else. They know a thing or two about sending out mass emails.
2. Their pricing is ridiculously competitive. Other mass email services start out around $15 per thousand emails. Amazon charges $0.10 per thousand. Of course, other services offer more in the way of campaign management, point-and-click setup, and analytics, but if you're just sending emails, it's hard to beat the price.
3. It's relatively easy to use. Emails are sent through simple RESTful API calls.

Getting set up

So assuming you're already an AWS member, first off you have to sign up for SES. That will get you set up with a developer account relatively quickly, and you can test sending emails to a few email addresses with the ses-send-email.pl script that comes with the AWS SES Developer Tools. If you want to actually start sending out mass emails, you have to then request production access from Amazon.

Sending emails from Force.com

First off, download the Apex code here.

Then, take a look through the files:

AWS.cls

This is a top-level abstract class that has a few methods in it that you'll need for any AWS functions. This includes the code to generate a signature from the current Date/Time and your AWS Secret Key:

public string signature(String awsNow, String secret) {

     system.assert( secret != null ,' missing S3.secret key');

     Blob bsig = Crypto.generateMac('HmacSHA256', Blob.valueOf(awsNow), Blob.valueOf(secret));          

     return EncodingUtil.base64Encode(bsig); 

} 

And the code to generate the authorization header using that signature:

public string headerForAmazonAuthorization(String accessKey, String signature)

{

return 'AWS3-HTTPS AWSAccessKeyId='+accessKey+', Algorithm=HmacSHA256, Signature='+signature;

}

SES.cls

Being an abstract class, AWS.cls is then subclassed by SES.cls. This includes the method to actually send an email by setting the HTTP headers and body, and sending the request to the SES endpoint. To use this, you just need to send in a List of recipient addresses, your from: address, a subject, and a body for the email. The response from AWS is then written to the debug log, so you can see any error messages sent back by Amazon. 

SESEmail.cls

The SESEmail class defines a single SES Email message with multiple recipients, a sender, a subject, and a body, and it takes care of URL Encoding all of that and setting up the Body of the request to Amazon.

AWSKeys.cls 

So this one I didn't actually write. I got it from the Force.com AWS Toolkit. Mostly it just reads your AWS Access Key and Secret Key from a custom object. The authentication code in that toolkit is a bit out of date for the current version of the AWS API, and I did modify this class to be a singleton so a DML statement doesn't get kicked off every time you query for your AWS Keys. If you're using this, you'll probably also want to make the AWSKey__c SObject private so your entire org doesn't have access to your AWS keys, but I'll leave that as an exercise for the reader.

SESController.cls

Last, and I'll be honest, least, is a dummy VF Page and controller that connects the dots and sends off emails using SES. The page is a pretty simple page that calls the controller:

<apex:page controller="SESController" action="{!constructor}" >

And sends an email to a List of recipients:

AWSKeys awsKey = AWSKeys.getInstance(AWSCredentialName);

SES sesEmail = new SES(awsKey.key,awsKey.secret);

List<String> recipients = new List<String>();

recipients.add('nobody@modelmetrics.com'); 

String sender = 'nobody@modelmetrics.com';

String subject = 'Test message';

String body = 'This is the body of the message';

sesEmail.sendEmail(recipients,sender,subject,body);

That's it. Relatively easy. Adding test classes is left as an exercise for the reader .

Anyway, the way I finally got it working was to create a new AIR Desktop project in Flash Builder 4 and copy the entire src folder over from the Flex Builder 3 project. The only thing that you can’t copy is the app.xml file, as it seems to be in a slightly different format in FB4, and the project won’t build.

SVN

This causes some problems if you want to continue a development effort using SVN, and other members of your team are using Flex Builder 3, because the actual project can’t be shared between the two versions of the IDE. However, the src folder can be shared without issue, so if you check just that folder out into your new Flash Builder 4 Project shell, and over-write the app.xml file you’ll be good to go, just don’t accidentally commit the app.xml file to the repository, or you’ll break the build for everybody else.