jonathanrico.

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:

<table class="profile">

	<tr>
		<td style="vertical-align:top;">
			
			<div style="width:100%;">
				<div style="width:220px;float:left;">
					<%= render_cell :ProfilePhoto, :display , :uid => current_user.id, :size => 'large' %>
				</div>
				<div style="width:300px;float:left;">
					<%= render_cell :UserStatus, :display , :uid => current_user.id %>
				</div>
			</div>

		</td>

		<td>
			<%= render_cell :AboutMe, :display , :uid => current_user.id %>
		</td>

	</tr>

</table>

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 other classes to upload your “I must get this to production right now” code
• Prefer a trigger over a validation rule (if it can be done through a validation rule)
• Create a new trigger for an object each time you want to add something new unless you’re pretty sure of what you’re doing
• Ignore the undelete event in a trigger
• Assume a trigger will process a single record
• Create all of your classes with “without sharing” keyword unless you know what you are doing
• Leave open queries (without a where clause or limit) unless you know very well your data
• Ignore the escapeSingleQuoutes function to “clean” user-supplied input in dynamic SOQL
• Keep list of objects as part of your viewstate … again … unless you know what your are doing
• Create a custom object for saving custom settings
• Look for a RecordType based on the Name instead of the DeveloperName
• Ignore the certification maintenance emails
• Reset a security token without taking in account existing integrations or other people that may be using the token
• Have a mac and not use SoqlXplorer
• Use chrome and not use the “Force.com utility belt” and “Force.com Logins” extensions
• Ask questions like crazy unless you already searched in the discussions boards and found no answer
• Use accents in profiles or page layouts names (for those that use Spanish)
• Change the type of a lookup relationship without taking in account any impact on the standard report types and reports that are currently using those report types
• Suspend a user without thinking about re-assigning ownership of his/her records
• Ignore declarative changes in production, always keep track of these changes
• Avoid the use of Security Code Scanner to resolve thy issues — Cory Cowgill

Amen.

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