I ran into an issue the other day while trying to deploy to an org with a lot of ongoing activity. I ran into the annoying error message:

Error: Apex class has Batchable or Future jobs pending or in progress
 (line 1, column 21)

I checked the Apex Jobs queue and found that there was over 5500 queued jobs. Some which had been waiting for hours. I decided to clear the queue so that I could continue with the deployment. I wrote a quick APEX script to mass abort all the queued jobs which I then executed using anonymous APEX.

The 27th of June is almost like Christmas—it’s the day when you learn if your Dreamforce session was accepted or not. It’s not a lot of words that go into a proposal but a lot of thinking. For me it’s a great honor and a learning experience to be able to host a session at one of the largest computer conferences in the world. Last year was my first year as a submitter and a speaker. I was very surprised when the acceptance notification came. I had almost forgotten about it.

Go, or golang, is a language I thought looked strange and sloppy, but with my long C-development background, it didn’t take me many hours to start loving the language and the large community growing around it. As a Salesforce developer and user, I was, of course, curious to find an easy way to start working with the different platform APIs.

A great starting point for this journey was to look closer at the force CLI tool developed by the guys at Heroku and Salesforce. The next step was to start building my own application. Pretty soon, I realized that I had implemented the full webserver OAuth flow in my application—and all for a token so that I could call the APIs.

On April 9:th I made a presentation at the Stockholm Salesforce Developer User Group Meetup about migration strategies and git. Below are the slides from the presentation.

• force.com Migration strategies and GIT

When you build solutions on the force.com platform you should always try to make them robust but yet flexible. Customisations you build should be created in a way that they are org independent so that you can handle sandboxes and maintenance in a good way. It is not uncommon that you need to build triggers or classes that to a degree will be org dependent - this is the effect of the business requirements but there are ways to drastically limit the impact on the org.