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/

Google just released new features for Google Docs, including a new addition to the suite called Drawings! As a user of google spreadsheets I was very aware of performance issues when working with large data files and this new version of the application seems to boost performance and at least scrolling seems to work very well. These are some great enhancements to the Google Docs suite and hopefully this brings more ideas for integrating Google Docs with Force.com through the Google Data API Toolkit . Here's a video with more info:

Hello again! I just developed an Apex class for performing replace/merge operations on any kind of object, and yes any kind of relations as well! , so it doesn't matter if you have master-detail relationships that can't be modified, objects tied in a master-detail relationship will be cloned, deleted and inserted with the new values to simulate a merge operation! To use the Merge class  just create an ObjectMerge instance, passing as an argument of the constructor your current record: ObjectMerge oMerge = new ObjectMerge(SourceObject); And to peform the merge operation just use the replaceRecord method and thats it!, you can specify if you want to delete the source record after the merge operation is done. oMerge.replaceRecord(MergeToThisObjectID,DeleteSourceObject); You can limit the number of records that will be processed in the merge operation for Master-Detail relations  to avoid hitting governor limits. The ObjectMerge class will let you know if there are any...

Hello everyone! I came across a blog post at gokubi.com ( http://gokubi.com/archives/two-interesting-ways-to-architect-apex-triggers ) about some interesting ways of architecting Apex Triggers. We have developed a lot of logic in Apex Triggers and ended with some really nasty code in some scenarios; this post got me thinking about new ways to architect triggers using a more object-oriented approach. So just to follow the thoughts in this post I'll show you what I did to organize our triggers and it has been working pretty good so far. NOTE: Please refer to the code section below //Step 1 I started by creating an Apex Class to replicate some of the triggers functionality... //Step 2 The next step will be to start coding our Apex Class that will perform all of the logic in our triggers, so let's say the we are building a trigger for My_Object__c custom object. //Step 3 And finally, we just need to create the Apex Triggers that will just initialize our Trigger class and initialize...

Salesforce's Spring '10 is packed with some really nice enhancements, new interface, code scheduler, no limits in collections, and more! For more information go to: http://developer.force.com/releases/release/Spring10 Here's a small demo of how code scheduler works:

For the last 4-5 months i’ve been working with the  force.com platform, more specifically with the on-demand CRM  salesforce.com . In these few months working in this platform, i’ve seen some major improvements that i think will establish  force.com as a major platform for the development of web applications, among these: Visualforce, Web-services (which have been around for some time), integration with Google and APIs provided for other frameworks such as Adobe Flex/Air. This platform as a service concept is new for me and I think it offers great advantages in matters of development & deployment time,acquisition and maintenance costs of hardware & software. And now, with Visualforce, it gives developers the ability to follow the Model-View-Controller Design Pattern in order to have data models, business logic and user interface in different layers. I’ll post more information about how to work on each of these layers and maybe show some code of examples that i come to write i...

Hello everyone, just wanted to share with the community this custom component I made and give something back for the help I've received :) The purpose of the component is to enable autocomplete in lookup fields. I used the autocomplete js created by Jim Roos: (http://www.jimroos.com/2007/05/ajax-autocomplete.html) but made some modifications to it so that it could interact with an Apex controller among some other things... So my idea was that if you were making a VF page that had an inputfield that was related to a lookupfield you would just insert this autocomplete component to that inputfield. Something like this: <apex:inputField value="{!Contact.accountid}" id="accname" styleClass="cField"> <c:autocomplete ObjectName="Accounts" InputId="{!$Component.accname}" AutoCompleteId="accACid" ClassName="autocomplete300"/> </apex:inputField> The component has 4 parameters: The na...