Browsing through the Force.com Discussion Boards while playing with the new version of the Force.com IDE (released June 19), the ever helpful JonP explained exactly how to generate a .object file on standard objects.

Fire up Eclipse, and in your Force.com project open up src/unpackaged/package.xml. Find the XML element with the name of “CustomObject” and add in some new subelements with the value of the standard object. It should look like this:

<types>
    <members>*</members>
    <name>CustomObject</name>
    <members>Contact</members>
    <members>Account</members>
</types>

Then, run the “Refresh from Server” functionality by right-clicking on src/objects and accessing the Force.com menu. Your standard objects should then appear.

Alternatively, if you’re paranoid about too many custom fields being editable (and quickly erasable) in the IDE, you can stick in an entirely new types element named CustomField that looks like this:

<types>
    <members>Opportunity.SomeCustomField__c</members>
    <name>CustomField</name>
</types>

Now, you’re able to use the power and speed of the IDE to create, edit, and deploy custom fields on your standard objects. It’s a great productivity win. A big thanks to JonP for explaining all this.

Pardon the ridiculous headline, but I figured this was my one chance to use it.

At Dreamforce Europe today, the big announcement is that Visualforce is finally going to be generally available in Salesforce.com with the Summer ‘08 release.

If you haven’t yet done so, register for the Developer Preview here.

Because the Force.com developer community is still very small, it’s important to make the most out of what Salesforce.com (the company) provides for us on the Web. The best site for all things Force.com is of course developer.force.com, with its invaluable Wiki and Discussion Boards. But sometimes dead-tree versions of knowledge can be helpful too.

Ebooks

SFDC has made available two free books, one is an introduction to the platfom and the other is a recipe-style book. If you’ve been to a Force.com event recently, chances are you received these as actual, bound books. Here are the PDF ebooks:

• Introduction to the Force.com Platform – Really a beginner’s guide, this book takes you on a feature tour of the Force.com platform, and goes over both administrative/declarative features as well as the more programmatic Apex and Visualforce capabilities.
• Force.com Cookbook – I find myself flipping through this problem/solution recipe book often. It’s very helpful at producing those “Ah! So that’s how I’m supposed to do it!” moments.

The APIs

The Force.com Application Programmer Interfaces (APIs) allow us developers to integrate our Salesforce instances with external web services, as well build in some powerful customization into those instances. I don’t print these out, but rather just keep the PDFs quickly accessible for fast keyword searching:

• Apex Web Services API – Covers the SOAP API in all its glory. I personally wish this was REST, but SOAP is better than everything but REST.
• Apex Metadata API – A newer API, the Metadata API allows us to define the structure (fields and relationships) of our custom objects via XML rather than via the declarative point-and-click interface. Unfortunately there’s no Metadata API available for standard objects (Contacts, Accounts, Opportunities) yet, but I expect that to change this year.
• Apex AJAX Toolkit API – The AJAX Toolkit is primarily used with S-Controls, which are being phased out in favor of Visualforce. To be honest, the AJAX Toolkit has always seemed like a workaround hack to me, and hopefully the combination of Visualforce and Apex Code will render it obsolete.

The Developer Guides

These are must-prints. As more thorough extensions to the ebooks above, these guides are the definitive resources for developing with Apex and Visualforce.

• Apex Developer’s Guide
• Visualforce Developer’s Guide

Frequent Updates

Both the APIs and Developer Guides are updated with every release (Spring, Summer, Winter), so make sure to grab the newest versions when you see your org being updated, and please do recycle the old versions if you print them out.

I suggest bookmarking this post, so you can quickly access these PDFs instead of browsing through the developer.force.com Wiki. Enjoy!

Two weeks ago, Salesforce.com’s Tour de Force rolled into Atlanta, the first stop in a multi-city tour. While I’m terribly late in producing the following recap, I’m sure you’ll find it in your heart to forgive me:

The Opening Keynote

The event was held at a hotel in downtown Atlanta, and the Expo area was packed when I got there about thirty minutes before the keynote was to begin. I’m continually amazed at how well-attended Salesforce events tend to be. Maybe it comes from never working in the enterprise, but I couldn’t believe how many people flew in from around the country to attend Dreamforce last September, and I was equally surprised at the turnout in Atlanta.

The keynote started at 10:00 AM sharp, and Polly Sumner, President of the Platform, was the first speaker. She spoke for what seemed to be over an hour, in what was a general overview of Salesforce.com and Force.com. As a developer, I got a bit antsy during her talk because it was completely review to me and I find Salesforce.com’s marketing slickness to be offputting, but I know that they had many potential customers in the audience.

After Sumner’s opening presentation, she invited up to the stage several partners to display impressive applications they’ve been working on. I won’t bore you with the details, but overall the demos were very impressive, many showing off the power of VisualForce. Then, an SFDC employee did a “Build an App in 15 Minutes” run through, which once again was review to me. It was at this time, sitting there for about 90 minutes, that I wished we had time for a break, and I assume others in the audience were suffering through it like I was.

Lastly, Nick Carr, the author of “The Big Switch”, came on and did a great talk on cloud computing. Carr even mentioned that he knew many in the audience were uncomfortable sitting there for so long, so he promised to go through the talk quickly. That was unfortunate, as he had some great things to say, and I really wished he could have gone on longer. His central thesis is that bandwidth and computing power is becoming a utility that we tap into on demand much like electricity or water has been. He made a compelling case, and I look forward to reading his book. By the time he was finished, the audience was sitting for over two hours, and we were, how to say, quite relieved to have a break.

Developers’ Track: Apex Code Deep Dive and VisualForce Preview

There were three tracks available for the afternoon session:

• Admins, Managers, and Analysts
• Developers
• Entrepeneurs and Vendors

Upon entering the room for the Developers track, I was surprised at how few people were there. While I would estimate that 300 people were in the room for the morning keynote, only 25 or so were attending these Developers sessions. I’m not sure how many people were in the other two tracks, but the lower number more closely aligned with my expectations of how many Force.com developers are actually in the Atlanta area.

The first 75 minute session focused on Apex. It was largely a language overview with a little bit of demo, and it had some stuff for both newbies and more experienced Force.com developers. My ears perked up at the end, when upcoming features were discussed:

• Dynamic Apex – Apex that acts more like the Partner WSDL for the SOAP API. It’s more loosely typed, and includes metadata methods.
• Asynchronous Apex – Asynchronous is actually a misnomer, as the more appropriate term for it is Queue-based. This means that Apex transactions can be put in a queue to be processed in the background as the rest of the application moves forward. I surmise that this will allow for looser Governor limits, but I’m not certain of that.

The second 75 minute session featured VisualForce. I have yet to play with VisualForce (shame on me!), and so this talk was very, very interesting. Overall, I get the “Ah, this is the Right Way to do it” feeling that I first got with Ruby on Rails. However, I’ll have to try it out to see the limitations, as I’m sure there are quite a few. We closed with a demo of Salesforce wrapped in the the iUI interface, which was really, really slick.

Conclusion

Overall, it was a day well spent. I loved the demos and the breakout sessions. My big gripe was with the length of the morning keynote. Yes, Salesforce.com is great at selling their product, but this day was supposed to be about developing with Force.com. More demos, more sessions, and less marketing!

Salesforce.com is billed as Software-as-a-Service: a complete software experience contained in the web browser. While regular users will never have to leave the warm comfort of their browsers, the reality for administrators and developers is much different. We depend on several essential tools to wrangle our data. Luckily, all the following tools are downloadable for free, and versions are available for both Windows and Mac OS X.

Apex Data Loader

Windows Installer | Mac Installer

Originally called LexiLoader (the Mac application is still called this), the Data Loader is the most essential tool for getting data in and out of Salesforce. The Data Loader connects via the Force.com SOAP API and understands the ubiquitous format of CSV (comma-separated values). When exporting data out of Salesforce, you’ll need to use SOQL, Salesforce.com’s SQL-like language for querying your data. SOQL doesn’t work exactly like SQL, and at times can be maddeningly confusing. But have no fear, as we have help.

Force.com Explorer

Windows Installer | Mac Installer

The Explorer explores your data. With it, you can build and execute SOQL queries, view the results, and edit the data (one record at a time).

The Windows version includes a SOSL Tester, which let’s you play with results from SOSL, Salesforce.com’s search language.

The Mac OS X version, SOQLXplorer, doesn’t include SOSL support, but does include a nifty graphical view of your data schema:

Let’s say that a city changes it’s name from Raritan to Edison (it’s happened before). So your workflow for updating contact data using the Data Loader and Explorer looks something like this:

1. Use the Explorer to figure out the correct SOQL query for all contacts in Raritan
2. Using the Data Loader and your cool query, export the data to a CSV file
3. Open the CSV file in Excel, and replace the City column with “Edison”
4. Fire up the Data Loader again and update the fields using with the new values in the CSV

Three different applications, four steps. Whew! If only there was a tool that did all of that in one neat little package…

Mass Update Anything

Windows/Mac Installation Instructions

Mass Update Anything, as the name implies, updates fields in bulk, based on a SOQL query. In addition, you can choose to delete fields in bulk as well. It’s a great little tool that does one job very well, and will save you from CSV hell.

Force.com IDE

Windows/Mac Installation Instructions

Last but not least, the Force.com IDE, based on Eclipse, is essential if you’re going to write any custom code for Salesforce. It has more features than I could ever describe in one post, so your best bet is to just visit the page. The IDE also includes an integrated Schema Browser (like the Force.com Explorer), and I’ve found myself using that rather than the stand-alone app.

Summary

So there you have it. The Data Loader loads data. The Explorer explores data. Mass Update Anything does what it says. And the IDE provides you with an integrated development environment for Apex Triggers and Classes, S-Controls, Visualforce, and Metadata. These are the tools you need to kick ass, so get ‘em and get started!

In Salesforce, every Contact record must be matched to an Account in order to be viewed by your entire organization. Unfortunately, users uploading in new Contacts via data import, or entering a new Contact manually, usually forget to enter in an Account field. Later, when other users search for that Contact, they won’t be able to find it, as Salesforce considers a Contact to be private (and thus not searchable), if it’s not linked to an Account.

Since the Account field on Contacts is standard, we can’t just modify it to make it a Required Field. Oddly, creating a Workflow to specify an Account when one doesn’t exist doesn’t work, for reasons that are a bit of a mystery to me. Enter Triggers: a programmatic way to take some action before or after a record is created, updated, or deleted.

First, create a generic Account that can function as a catch-all. I suggest “Individuals”. Then, use either the Apex Deployment Tool or the Force.com Toolkit for Eclipse to create a new trigger (using those tools will be the subject of future posts).

trigger SetDefaultAccount on Contact (before insert) {
    For (Contact nc:Trigger.new) {
        If (nc.AccountId == NULL)
            nc.AccountId = [select Id from Account where Name = 'Individuals'].Id;
    }
}

The code basically says: “Before a new Contact is inserted and if it doesn’t have an Account Id, set the Id to the Account named ‘Individuals’.

In Eclipse, you’ll be prompted to provide some test coverage for the trigger before deploying:

public class testcontact {
    static testmethod void mytest1() {
        Contact c = new Contact(LastName='test lname');
        insert c;
    }
}

Awesome! Now you’ll never have to worry about anyone in your organization forgetting to link a new Contact to an Account.

Hat-tip to Mike Rosa @ Salesforce.com for helping me out with this.

Well, lucky you! You’ve stumbled upon this weird, strange corner of the Tubes. A place where the idealism of an elegant open source project meets the stone-cold reality of delivering quality software within tight deadlines to those who line your pockets. No, this is not just another Rails blog. This is a blog about building web software really fast, under ridiculous constraints, with a multitude of crap hurled your way, and finding joy in it. I don’t profess to have found that joy yet, but hopefully, in what should be a long, fulfilling journey, you and I, my dear reader, will. And I won’t ever use that many commas in a single sentence again. Promise.

Luckily, we have some excellent tools at our disposal. You’ve heard of Ruby on Rails, the high-flying web framework that everyone’s been writing about since 2005. It’s got that guy DHH who drops the F-bomb a lot and has a funny Danish accent.

The hippest nerds flock to it, because it’s a damn good way to built web applications. Ruby is, hands down, the nicest language to code in. Rails (and now Merb), were designed from the ground up to make the lives of web developers better. To make us happier. That’s an amazingly progressive goal, hippy-ish really, and it would have been laughed at by those IBM engineers of yore who wore thick-rimmed glasses out of utility and not out of fashion. But I’ll be damned if I ever code in PHP or Java again.

You may have heard of Salesforce.com, the enterprise CRM system used by Fortune 500s to Mom and Pop shops to everyone in between. In the past few years (as Rails has been gaining in popularity), Salesforce has become more than just a CRM (customer relationship management). Dubbed Force.com, it’s become a nearly full-blown web application framework, but not in the same sense as Rails. Using Rails, we build web applications by firing up a text editor and coding in Ruby, HTML, CSS, and some Javascript. Using Force.com, we don’t build applications as much as customize the hell out of an existing one. Much is already built for us, but we then need to use a gaggle of technologies to tweak it just right to fit with our users’ needs.

Ruby on Rails and Force.com have a lot of differences. Rails is open-source, licensed under the MIT License. It’s free as in beer and free as in speech. Force.com is completely proprietary. Your users will have to subscribe in a per seat/per month arrangement. You host (or pay to someone to host) your own Rails apps, while Force.com apps are completely managed by Salesforce.com (the company). Philosophically, Force.com is a true enterprise framework, while the Rails Core team could care less about making it enterprise (and with good reason).

But the two have one striking similarity: they both help web developers build solid applications in ridiculous time. And let me make a bold claim: Force.com completely destroys Rails in development time. It’s not even close. A tool that takes me a day to build using Force.com would take at least a week (and probably two) if I were to use Rails.

I’ll let that sit with you, as I’ve said enough for now. In the coming days and weeks, I’ll be evaluating the pros and cons of each web framework, and sharing what I learn along the way. Neither is perfect, but both are pretty great. While there are many great Rails blogs out there, there is (to my knowledge), only one regularly updated Salesforce development blog, with another newer one. So, I hope to help fill that void. If this all tickles your pickle, consider subscribing to the feed.