As all Salesforce developers that have ever written any APEX code know: The code requires test coverage to become eligible for deployment to a production org. To deploy to a production system, 75% test coverage is required. There's a funny thing with the calculation of this coverage though.

Learning Salesforce.com and keeping your knowledge up-to-date has always been challenging. With Salesforce's 3 releases / year, anyone that wants to stay current has a nice challenge cut out for him or her. Even though there are the mandatory release exams which any certified Salesforce professional has to tackle, in practice a lot more effort is needed to cover all of the release's changes and additions, not to mention staying current with the growing Salesforce.com ecosystem.

Today I came across something an APEX developer does not see very often, a very rare species of error. Although there certainly have been sightings before, this one was caught on tape! Behold, the infamous ORA-NNNNN, straight from the belly of Salesforce!

This will be the third and last part in my series about (Skype) bots. This time, I will explain how I used the knowledge gained from building the game bot, to create a more productive bot. One that integrates with the Salesforce.com Sales Cloud and Service Cloud and moreover, one that does not require precize commands, but instead uses Luis.ai in an attempt to interpret natural language.

This is part 2 in a series of blogs about Force.comSkype Bots and the Microsoft Bot Framework. In the previous blog in this series, I explained how my first successful integration between Skype and Force.com had several downsides. The most annoying one: A local server sad In this blog I will tell you about the evolution of my Skype bot to version 2; the cloud edition.

This will be the first part in a series of blogs about an escalated hobby project and the discovery of an amazing new technological development: Bots.