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

Campaigns are about seizing opportunity and running with it. Obama is seizing this opportunity to brand John McCain:

Obama just announced surrogates will be talking about John McCain’s houses and his forgetting about them in 16 states tomorrow. Ouch. Looks like the general is really underway.

Matthew just notified me that my last month and a half of articles didn’t make it to my feed. Whoops. I seem to have fixed the problem. Feel free to check out what I wrote in July and August!

And I’m not talking about Green building…

I’ve had a great time working with Green for All–they’re accomplishing amazing things very rapidly. And what Van is doing to set the messaging frame for the new environmental movement is invaluable. We all need to keep him out there, spreading the message.

• We can’t make a green economy by reclaiming thrown away stuff, we need to reclaim thrown away people.
• I can’t tell a drug dealer he’s hurting the community, and that he should go work for Walmart. They hurt the community, too.
• Green jobs not jails.
• Affluent people can spend money on “green premium” Priuses, but poor people can earn money and save money in a green economy.
• It’s not about crisis, it’s about opportunity

This is great stuff. He also calls out the biggest risk to this movement–a backlash alliance between polluters and poor people. I think he’s right on there.

Another reason I love where I live–Discovery Park and it’s miles of running trails right in the middle of Seattle.

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!