As pretty much anybody who has a pulse already knows, BlackBerry has released their latest technological marvel, the PlayBook tablet. Initially, it appears to be a direct competitor to the iPad, which as far as we're concerned is a good thing. Competition breeding innovation and all.

But what really excites us is that this new tablet device runs Adobe AIR, which our 2GO platform and applications are built to run on. Sweet! Now our customers have a true choice in the marketplace when they want mobile access to salesforce data, content, and so much more.

Now to the fun stuff, a video demo of the PlayBook in action:

Whats wrong with this picture?

There are a few things, but one thing that is obvious which is the basic part of this story:

1. This code and any and all Trigger code must be in classes. Triggers run with System Admin privileges and don’t take advantage of any sharing rules or any security restrictions. That is why Apex classes have “with sharing” in their declaration
2. The error message should be on the Stage field because its an error driven by the stage field.
3. The error message itself should be a System label so if it needs to be translated or changed it can be done without developer intervention.

Other than that its perfectly compilable and runnable code. It addresses whichever use case needs to be addressed and can be unit tested with relative ease.

The BIGGEST issue with this code is that it shouldn’t exist in the first place.

This is what it should be:

The story always is that Surgeons cut, Doctors diagnose, and Coders code. There is always the temptation to cure every and all issues with code. Its what we know how to do well and its what makes us different from others. But none of this means that, as a Force.com Developer, it should be the only weapon in your arsenal.

At Model Metrics we enforce the necessity of Salesforce certifications. For anyone who does Apex code or works with the API we require that they at least have the Force.com Developer certification. If you have either taken this certification or the Dev 401 training you know all they talk about is the declarative portion of Salesforce, not custom.

Something we take for granted is that it needs code. Force.com just as a declarative platform is very powerful and even the most complicated use case can be fulfilled with just clicks.

If you were to come to me and say “I want to lock this parent record with a Checkbox and I want all of the subsequent child records, hundreds of records across eight different sObjects, to be locked as well. A coder will tell you “Sure, we just have a trigger on each of those sObjects, all eight of them, and query against that parent record to see if it is locked. If it is, don’t let them edit the record.” A Force.com Developer SHOULD tell you “Sure, we just have to put validation rules on each child sObject that looks up to that checkbox through the parents lookup field.” The difference in development and support time between the two is staggering. The coder will take a good long time to create eight triggers and subsequent unit tests and make sure they work with any current code existing in the org. The Force.com Developer will do eight validation rules and it will take them an hour. Maybe less.

Now if you were to tell me “I need to do a check across all child records” or “I need to do a callout to an external web service” then OK code it is. Of course keep in mind you can’t do a web service callout from a trigger(yay @future tag!).

There is always the temptation to code first, ask questions later. Force.com Declarative is easily maintainable and doesn’t require any engineering knowledge to work with(but we are more awesome with them!). Apex and the Force.com API allows a Force.com developer to fulfil those use cases that the declarative portion can’t address. Its easy to differentiate between Declarative vs. Custom. Setup a devorg, read the Salesforce books, and take the Developer certification. If you can do that, and you know how to code that’s not IF THEN ELSE, you're a Force.com Developer. 

Theres a few rules that I've learned while working with Salesforce/Azure/Amazon Web Service/Google App Engine that everyone should follow:

1. Manage your DB read/writes - It may seem beneficial to do a write then a read for the latest data, but manage the data in cache so you don't waste precious resources. Many Cloud providers lock down your DB read/writes, keep those limits in mind.
2. Be mindful of memory - All of the cloud providers, especially Google App Engine and Salesforce have limits on Heap size. Refresh your lists, make sure your heap time is properly managed. Everyone provides some form of garbage collection, but they won't watch your resource limit for you. 
3. Always cache your public pages - All of the provides have a hard limit on bandwidth. If you don't have proper caching, you'll hit your limits and lose money when you don't need to. 
4. Make "More Hardware" your last resort - As software engineers we usually prefer to say "Toss a few boxes on, cluster it, and boom were golden". When it comes to the Cloud resources = money. Unroll loops, deallocate memory how you can (clear list and maps OUT after they aren't needed), and be mindful of memory leaks. 
5. Triage scheduled jobs - Scheduled jobs are those special processes that happen when you need them to happen but be very careful. If the cloud goes down and your needed job doesn't happen, you could be in a heap of trouble. If its REALLY necessary then have a manual process or a servlet setup that can be run later on to make up for that missed job. 
6. PAY ATTENTION TO ENVIRONMENT UPDATES! - When your Cloud provider releases a new SDK, updates your environmental variables, or makes a change in any way, KNOW ABOUT IT. Cloud providers are constantly upgrading their product, and since its in the Cloud they will update it and you will need to deal with it. There is no "OK this app works with Tomcat 5.5, so we don't really need 6.0." No, they will give you 6.0, and your application could crash and burn. You may need to make some changes but so what, get with the program or get off the Cloud. 
7. Someone else built your security - Every cloud provider has their own security setup. Now you don't have to build one, great! But it keeps changing, not so great! How your provider chooses to manage your apps security, authenticated or unauthenticated, can and will change. Like before, pay attention to security updates. Make sure your app is XSS and XSRF safe even if your provider makes that guarantee. 
8. Is your application Cloud Ready? - Your Java application uses Struts. You wan't to use either Google App Engine or VMware's vSphere. Uh-oh, GAE Java uses Spring(sort of) and vSphere uses SpringSource. OK, should you rebuild your app or go over to another provider such as Amazon Web Services? Know this before you start refactoring.
9. Know your costs - If your app needs to grow, the Cloud can accommodate………….at a cost. Its hard for a developer to see dollar signs when they need something done but you need to learn that with great power comes great responsibility. If you want to start your own Cloud ISV, make sure your income statement keeps those growing Cloud costs in check. 
10. Remember: You're Sharing - You could have three boxes, you could be with three other people on a single box, you do not know. Keep in mind that if you screw up big, it can affect alot of people. Safe virtualization techniques by your Cloud providers can prevent this from happening from the most part, but take some of your own precautions. Most cloud providers don't allow for any real multi-threading, but if they do remember the following: avoid deadlocks and race conditions. These aren't just kernel issues, they're hardware issues and can do some real damage to other peoples applications. 

Nearly all of my recommendations are the the same as if you were designing a C application for a router. Be safe, be secure, and watch the expenditure of money and resources. Keep these things in mind and you will have a great experience in the Cloud. 

You may recall back in March we wrote a post on the rapidly dwindling need for desktop machines. That trend has continued, except now it's changing directions yet again. Not only are laptops and netbooks increasing sales, but now tablets are all the rage just 6 months later. 

Apple has once again defined a new segment with their iPad, in an arena where tablet PC's had historically failed miserably. With a large, beautiful touch screen, fast processor, and light weight, it was a huge home run. 

Recognizing a big market opportunity, competitors are lining up and salivating over what could be huge sales. A quick search on Engadget's website shows a fairly large list of upcoming tablet devices. Companies like Samsung, Toshiba, Archos, Texas Instruments, Dell, Acer and HP are building their own tablets to compete and hopefully take some market share from Apple. 

Will they succeed? Tough question – but given the publics' acceptance of Android based devices I suspect we will see several tablets from Apple competitors doing well. 

So why do we care about this at Model Metrics? Because we develop applications that grant mobile access to cloud-based data. And our 2GO platform runs on all of these devices whether they're IOS-based or Android. Stay tuned, this is an exciting place to be. 

As we first saw reported by Engadget yesterday (and soon by many, many others) Apple has lifted its development ban on third-party platforms. This of course, is big news because Apple had once infamously blocked the use of those platforms to create apps for the iPhone and iPad. 

Why would we care so much at Model Metrics? Simple; we're experts at developing on the Adobe platform. Sure, we are perfectly capable of developing native applications for the iPhone, but Adobe makes the development process a more streamlined one. If you're curious about enterprise applications running on your mobile device, give us a shout. 

Adobe is also clearly ecstatic about Apple's change of policy, and notes that applications built using Adobe technology are already making their way into the App Store. The more, the merrier, we say! 

In the world of CRM implementation and management, we tend to focus a lot of effort (and rightfully so) on process compliance, collaboration, and user adoption metrics. We do this because we know intuitively that impacting these behaviors of CRM users will ultimately lead to desired outcomes like increased customer loyalty, better customer service, lower costs, and increased revenues. These are the real metrics that success or failure will be measured against; the others are simply a means to an end.

What is often lost in the focus on change management is the end users’ ability to optimize their behavior with the real end goals in mind. Remember, a sense of ownership among end users is a key tenant to behavioral change.

Here are a couple of examples taken from the real world that help illustrate the point. First, I was teaching my 7 year-old daughter how to hit a softball last summer. I spent a great deal of time coaching her on her stance, her grip, the position of the bat, contact point, bat speed, rotation of hips, and on and on and on. She was a natural at hitting the ball, but she kept hitting the ball between first and second bases making her an easy out for the other team. So, I worked with her some more to speed up her swing, swing earlier, focus on the release point of the pitcher and follow-through. No change. Finally, in frustration, I said, “I want you to hit the ball to left field, not right field.” Would you believe that this is all it took? She never hit another ball to right field. It occurred to me that I had not effectively communicated the outcome that I wanted up until that point; I was so focused on the “process” that I forgot all about the goal!  By communicating the goal, it allowed her to apply the processes that she had learned to achieve the desired outcome.

The second example is more relevant to the CRM space. I worked with a company that sold food ingredients, and one of the major scope items in their CRM implementation was to increase collaboration among their sales people. They listed all of the various interactions that were mandatory to log in the system: call reports, quote requests, sample requests, meetings, phone calls, etc. It worked by most measures. There was rather high compliance to the process, user adoption was strong, and revenues were on the rise. One day I was having a side conversation with one of the real rainmakers in the organization and I asked him how he was so successful. He described an involved process that he followed to understand his clients’ products, the pricing of competitive ingredients, and the calculations that he did before we walked into a sales call that made him confident that he could win the business. I said, “Does anyone else do this?” He responded, “I don’t think so.” So when I asked him why he hadn’t used the capabilities of this new system to share his well-thought out approach, he said “that isn’t the type of thing that anybody said I should be sharing.” Now, you can make the case that this is implied behavior, but the point is that the process was, once again, over prescribed and the end goal of increasing top line revenue was not effectively communicated.

The great thing about implementing Salesforce.com as a CRM solution is that it provides the flexibility needed to allow your end users to participate and own the processes. Change in the business is easy for the technology to adapt to so the business doesn’t have to constantly adapt to the capabilities of the technology.

Steven Covey says “Begin with the end in mind,” but don’t forget to communicate the end to those that are intended to get you there.