gokubi.com

Don’t forget your shirt…

I’ve doing Salesforce.com development with Eclipse as my IDE for over two years now and it’s truly indispensable. It hasn’t been the easiest thing to learn and use, however. Eclipse is a complex beast–it’s really trying to meet the development needs of an amazing disparate group of users. And it’s a framework on which plugins sit, which is a powerful but scary proposition.

As I said, though, it’s indispensable for Salesforce coding. And even though it’s big and gnarly, I genuinely like using it most of the time. Here are some tips that might help you like using Eclipse for Salesforce as well:

Get latest “supported” versions of Eclipse and plugin

The Eclipse framework is an open source tool that periodically comes out with a new release. The Force.com IDE is a plugin that sits on top of that framework, and it has it’s own release cycle, controlled by the folks at Salesforce.com.

You should get on the latest version of Eclipse and the Force.com IDE that Salesforce.com recommends. At the time of this writing, that’s Eclipse 3.3 and Force.com IDE 13.0.

The latest Eclipse version is 3.4, but Salesforce.com hasn’t tested IDE 13.0 with it, so they don’t recommend it. I’m using 3.4 and haven’t had any problems except the small one that if you delete an Open Force.com project your code will be deleted from your Salesforce.com instance! Trust me, you want to stay on the Eclipse version Salesforce.com recommends–you’ll be happiest that way.

Whitelist your network

Eclipse is a “client app” which means it’s accessing Salesforce.com from your desktop. Because of that, it’s not trusted, and needs to be given the OK to talk to Salesforce.com. You can do this one of two ways–get your security token and use that or whitelist your network.

I highly recommend never using security tokens if you don’t have to! You can white list your network at Setup | Security Controls | Network Access

Once you do that, Eclipse will be able to connect to your Salesforce.com instance from that location.

Change your fonts

Maybe I’m just getting old, but the fonts in Eclipse are hard to read. I can’t easily tell a { from a (, which in coding is a pretty important distinction to make! Set your text font in Eclipse under Window | Preferences.

After trying some different fonts, I landed on Consolas with cleartype turned on in Windows.

Maximize screen real estate when coding

The Eclipse is set up with panels that you can drag around to create the look you want. It’s very flexible. It’s nice to see your code and the list of all code files and the test runner, all in one view. But, when you’re coding, use CTRL+M to quickly hide all the other panes, then hit it again to bring them back.

Refresh your projects often when multiple people are involved

In Eclipse you are working with local text files. Because of this, what you’re looking at might not reflect what is really in Salesforce.com at that instant, especially if you have multiple people working in the same instance. You can refresh what you have on your computer with what is in Salesforce.com, and I recommend doing it pretty regularly so you don’t get in the situation where you’re working on old code. The new IDE is much better at warning you when that happens, but it’s much better to not get into that situation.

Be Patient

Working on local text files is quick, but saving those up to Salesforce.com isn’t. You’re pushing files to San Francisco, and that takes time. But, there are other things going on. The two things that take the most time are compiling and running of tests. It’s great that these things happen automatically for you, but you have to be patient as they take the time to make sure you’re not breaking your instance. It’s worth the wait.

When you save a file, the Problems tab turns to italics. When the save is done, it goes back to regular text.

Close Projects to Keep Workspace Smaller

Having many projects handy is great, because you can go and steal code from on to put in another, but slows down the workspace. Searches and synchronization take longer. You can create Force.com projects for all your instances and close the ones you don’t care about right now. It’s two clicks to open them back up.

Compare and Merge Files Across Instances

This is a basic one, but very handy–Eclipse has a text compare feature where you can take two files and show how they differ. This is great for adding functionality from one instance to another where similar code already exists.

Deploy when possible, but Drag and Drop is Quicker

The Force.com IDE has a deployment wizard which is great for moving code between two instances. It’s really nice. The latest release of the IDE has gone one step further, adding robust drag and drop functionality. It’s kind of like deploying without the deploy wizard. Sometimes it’s faster to just drag and drop, but sometimes only the deploy wizard will work for what you’re trying to do.

Connect to other systems

I said earlier that Eclipse was trying to meet the needs of a very diverse developer audience. The good part of that is there are some killer plugins for connecting Eclipse to other systems out there.

You can connect your Force.com project to a Subversion code repository so that all your Salesforce.com code can be version controlled in the industry standard system.

Mylyn is a cool add-on (included in Eclipse 3.4) that allows you to connect to ticket or task management systems out there like Trac, or Google Code Projects. It makes managing code issues and bugs very nice and collaborative.

Conclusion

It’s becoming increasingly mandatory to use Eclipse for developing with Force.com. That’s a good thing, once you climb the learning curve. Eclipse is a good IDE that is amazingly extensible. Just think about what Salesforce.com is doing with their plugin–they’ve taken a tool that is used to dealing with text files and have it working with their database-stored code and config. Pretty amazing, really.

If you are using Eclipse with Force.com, please comment with any cool things I’m missing–it’s a sprawling tool. If you haven’t been using Eclipse, you really should!

Here is a modest proposal for making it easier for sending Vertical Response emails from a Campaign.

Am I missing something? Seems like this would be really easy for Vertical Response to implement.

Scott, a master of the URL hack, has found the URL for Coming in Winter ‘09 Ideas.

Here are my favorites:

• Packageable VisualForce
• Better Campaign Member management
• Visualforce for list buttons
• Tons of Ideas features
• Marketing influence reports
• Documents in Metadata API
• Reports in Metadata API
• SOQL Outer Joins
• Visualforce as Email Templates

VisualForce and Apex use semicolons, and the Salesforce.com user forums software interprets semicolos as the eyes in a smiley face. Oops.

When you are struggling with syntax and you run across sample code that look like this, it kinda feels like getting kicked in the gut by a clown.

Earlier I faked a drip email campaign, but here’s the real deal. Matthew came up with this idea and I think it’s brilliant.

Basically, you mark that a Contact should start a drip email series, and from then on they will receive your templated emails automatically, at the time intervals you configure.

The sending of these emails requires no User intervention, and no code is necessary to make this work–it’s unattended drip emailing from plain vanilla Salesforce.com.

I love working on a team, because someone often comes along with a different approach to a problem that I was blind to. This is so much better than what I was coming up with. We still have a limit of 200 emails a day, but because these are going out daily rather than in large batches, we have more ability to level our sends, staying under 2000.

I’m not sure why workflow sends to Contacts was a blind spot for me. I guess I have been thinking about email as large-batch sends, rather than thinking about them as one-offs. Or maybe I still haven’t recovered from summer vacation…

Thanks again to Matthew for this great idea. If anyone can think of limitations we’re not considering, or ways of doing this better, please post a comment!

We’ve done about 20 Salesforce implementations, and have 5 more going right now. We’ve developed a base template–a set of objects, fields, reports, dashboards, workflow, scontrols, visualforce, and apex that we start with for each client. We then customize that to their needs.

When I first started this work, it would take about a week to get a base install set up. All the objects had to be created in the web interface. Fields and values had to be done by hand. Code had to be copied by hand. It was a drag.

Then came the Appexchange, and we got to package up some things and install them with a few clicks. Then the Appexchange got better, allowing for more things to be packaged.

The last time I did a base install of our template, it took about 8 hours.

Much of this time was getting the page layouts to look right. If you’ve ever worked on a page layout, you know how complex they are. First you have to get all the fields in the right place by dragging and dropping them. But you then have to click into each field if you want to make it read only. You have to pick the buttons you want to show up on the page. You have to pick the related lists, and then each related list has a list of fields in a specific order, as well as sort order.

Page layouts were a significant piece of work, and I’d often find out in training with the client that one related list didn’t have the right fields, or wasn’t sorted the correct way.

The Metadata API and the Force.com IDE have changed how we deal with page layouts. We can now set them up in our template instance and copy and paste them into our customer org.

I have a new customer and I set them up with our base template yesterday. It took me 2 hours.

For each customer I deal with, the Metadata API will save me 6 hours of point and clicking in page layouts. I can’t tell you how happy that makes me–hand-tweaking page layouts isn’t the greatest value-add to the environmental cause.

You can also copy and paste Profiles, so we now have some template profiles set up, and the next install will go even faster.

If you’re a consultant, you need to use the Force.com IDE and the Metadata API. It’s a massive time-saver and will only get better as more things are added–roles, sharing rules, record types, buttons and links–who knows what’s next?

Dreamforce is on election day. I hear tell San Francisco is Obama country. Anyone know of a good place to party after the results come in?

We don’t have an email blasting tool that effectively supports drip campaigns, so we’re faking it a bit. A picklist represents all the steps in a drip campaign. After we send all the communications for this month, we shift everyone to the next step. To make this easier, I built a VisualForce page that updates all Contacts to the next value in a specified picklist.

You could do this kind of thing with workflow field updates (there is an option for moving fields to the next option in the picklist) but there isn’t a great way to query the objects. A List Button won’t work because you have to page through and select all your Contacts before clicking the button. So, this is what I came up with.

Scott Hemmeter has a cool new feature for his Salesforce.com mapping product Arrowpointe Maps: proximity searches. Find nearby Accounts and Contacts on a map. Very cool Scott!