Lately I've been involved in several discussions around how the Force.com platform handles object and record level security. I'm surprised that there's still a lot of confusion around this topic despite all of documentation available out there so I'll try to explain this topic in more detail. It usually helps to start the conversation referring to Jason Ouellete’s “Development with the Force.com Platform” book where he illustrates these layers of security as a funnel. Each request has to go through several layers starting with CRUD and FLS checks and then moving to verifying org-wide default sharing model and any exceptions to org-wide sharing model if applicable. If the request “survives” through all of these checks then access is granted. This funnel provides a great way to illustrate how data security works at a high level but it still doesn't explain all the nuts and bolts involved with sharing rules and how to enforce these levels of security w

Wow, every day we learn something new so It seems like I'll never run out of material for my list of commandments! Here's the continuation of my previous list, it's important to point out that some of these might not be valid for future releases but people should be careful for now when dealing with some of the current limits. So here we go... Thou shall not: Assume that standard objects in destination orgs don't have any validation rules/trigger logic that will cause your package's test units to fail, place your catch blocks and take actions accordingly Assume your custom settings will be initialized when running test units in a destination org , make sure you validate null values or set the values for custom settings Give end-users credentials to test your app and go on vacation leaving the user wondering what the heck is a verification code. Make sure you change the f$!@#%^ email address! Leave out apex:pageMessages component from your VF page to display

I've been working a lot with rails and force.com during the last months, rails is awesome however getting all of the plumbing to work is a real pain. I'm working on a template app that might be helpful for anyone that's trying to build a rails app that interacts with force.com. This app template uses: Databasedotcom gem Bootstrap framework Application template Basic chatter components (more info below) I decided to use cells for creating reusable components and it's looking very promising. I created a few chatter-related components and got it to a point were the following code: Renders the following page: I'm no expert in ruby or rails so I hope that with the help of other developers we can improve the template and expand the components library. Also, i'm planning to provide some libraries to access the metadata api from ruby but this is still a work in progress. You can checkout the github project here .

I spent a few minutes today thinking about my experiences developing on the Force.com platform. Overall it has been great, nevertheless, there have been some bumps in the road (and there will be more to come). Here's a list of some commandments that I've come to think of as imperatives for development on Force.com. NOTE: This is just a list with no particular order of some of what I consider are the most important items. Thou shall not: Say a class or trigger is ready without having any test units Place a SOQL query inside a for loop Place a DML operation (for a single record) inside a for loop Hardcode an id, object prefix or service instance names... anywhere Create a full sandbox without being damn sure you're ready to create it Say a field is hidden by just removing it from a page layout Assume your test units will magically find data in a new org Assume a 75% coverage is good Ignore asserts in your test units Rely on good percentage coverage of oth

These are some important considerations for those who plan to build apps for the Force.com platform, these considerations are organized by Data, Logic and User layers. In conclusion, the ideal Force.com profile is one that works with: Structured data, search, reports User-driven business processes Employee,customer or partners users Real-time information, mobile or collaboration needs

Here's a nice tool from Google for building apps for Android: Learn more here : http://appinventor.googlelabs.com/about/