You are currently browsing the category archive for the ‘Salesforce’ category.

If you are working in another context and have been considering out of personal interest or necessity joining “the Enterprise,” here are a few things you should know:

(1) The enterprise is about meeting people’s needs as they already exist

Generally speaking, you don’t do any true B2C stuff in the enterprise, it is all B2B and built on top of existing products and stacks, so your chance to start something “from scratch” is virtually nil. Don’t try. No one cares. This generally also means heaps of integration with existing business processes, software products, etc.

(2) Your users are not you

I’ve seen this problem come up a number of times, but most of the time the people using the product you will be building are very different from you and have a very different set of problems. You either need to understand these problems yourself or get used to working with someone who does.

(3) The enterprise is about money

Money is needed to live and is, generally speaking, the standard by which everything is measured in the enterprise. And by everything, I mean everything. Your cool widget isn’t worth anything to anybody unless it makes someone money. There is a certain reasonably large amount of bullshit eliminated this way.

(3) The enterprise has money

You don’t have to worry (or at least you have to worry less) about people with their latest greatest idea wanting you to implement their idea for time with their cat. I like cats, but I also like to get paid. This is one of the main reasons why people end up in the enterprise.

(4) Your tools are what you are given

Since you are working on top of someone else’s stack, generally you are stuck with whatever they provide. This can really suck. Unfortunately, due to No. 3, probably no one cares much about creating new tools for you to work with, since this costs them time and they can’t figure out why they should give you anything more than you need.

(5) You will be forced to drink kool-aid

Marketing, frequently involving technologies which are poorly-defined and do not exist, is the lifeblood of “innovation” in the enterprise. Generally speaking, this involves putting a vague concept out there and contrasting your awesome vague concept with the “conservative” parties that are just selling the same old sauce instead of your new sauce. The implication of this, is that if you are in the periphery, you are more or less forced to become a cheerleader. Although waving pom-poms can be nice (well, depends on who is doing this, do not click on this link), it can go to your head. Generally speaking, this sluicy juice does make people a bit crazy, so you have to watch out.

Generally speaking, you should be aware of all of these things before starting. The enterprise can introduce you to a lot of people with interesting needs in a variety of industry sectors (I’ve been fortunate to work with a number of very large and interesting corporations) without a lot of bullshit you might deal with if you are limited to small and mid-size companies and deals. The unfortunate consequence is that you will probably move far away from B2C solutions, which can be a better way to improve your skills as in many circumstances you are forced to be much more competitive when working on a product which, generally speaking, must iterate much more rapidly.

In the end, if you stay in the enterprise with the attempt to be as “good” as you can, you will probably become awesome at doing a lot of things quickly, but will probably stop doing them all that well (the incentive structure generally emphasizes quantity of features but less frequently quality of experience, something which generally means that you need to care about your customers).

I try to work on things I am excited about as much as possible because I work “harder, better, faster, stronger.”

Here are a few things I’m excited about at the moment:

(1) Meteor. Recent explosive entry into the Javascript libraries/frameworks, which provides a “railsesque” framework for developing with a Node.js backend and presumably MongoDB datastore. Fills a huge need and appears to do just about everything just right, both in terms of design decisions and community engagement. I predict total domination.

(2) 12 Factor App. Not commented on heavily with the Salesforce community though a product not only of top-notch Heroku smarts but also with commentary from top Salesforce eggheads (e.g. Mountjoy), I think this is the sort of document we will be reviewing in five years as “prophetic.” In many ways, the future is already here, but it will take most of us a long time to realize it.

(3) jQuery. I know that there is nothing new here, but as a diehard jQuery enthusiast, I still think its time of triumph “in the enterprise” is coming soon as people finally get the message (and also realize that UI of their product is important).

(4) Berlin. Not quite Silicon Valley but people are picking up the torch and I expect to see more significant European-based challengers instead of just imitators over the next few years. Don’t doubt the Curry Wurst.

(5) Polyglot solutions. Even though it has often failed to invest substantially in its own open source ecosystem, Salesforce has taken something of a lead in acquiring in the fascinating although occasionally murky world of “polyglot” solutions, where various languages are used to provide what presumably is the “right tool for the job.” Despite the occasionally murkiness and gangs of cheerleaders without any real understanding of the strengths and weaknesses of various technology sets, I’m excited to see more definition about what constitutes the “right tool for the job” and robust composite solutions — of course, expect to see this more on the “bottom up” Heroku side than the typically top-down Salesforce side.

(6) Fractals. Okay, probably you know this already, but I think other people are finally starting to get the message about just how “fractal-eque” many parts of the world are.

jQuery UI for Salesforce provides a complete set of jQuery powered elements that can be used instead of the standard elements. This includes automatic client-side validation.

A page showing the jQuery elements compared with standard elements can be found here.

Usage

Complete specifications follow for each enhanced component:

Text:

<c:enhancedText pageController="{!this}" fieldName="Text__c"   />

You can also force there to be both a uppercase and lowercase letters by telling to to validate as a name:

<c:enhancedText pageController="{!this}" fieldName="Text__c"  validateAs="name" />

Email:

<c:enhancedText pageController="{!this}" fieldName="Email__c"  validateAs="email" />

Number (Double):

 <c:enhancedText pageController="{!this}" fieldName="Number__c" validateAs="number" />

Percent:

<c:enhancedText pageController="{!this}" fieldName="Percent__c" validateAs="percent" />

Checkbox (Boolean):

<c:enhancedCheckbox pageController="{!this}" fieldName="Checkbox__c"   />

Phone:

<c:enhancedText pageController="{!this}" fieldName="Phone__c"  validateAs="phone" />

Defaults to international phone, for US domestic phone use:

<c:enhancedText pageController="{!this}" fieldName="Phone__c"  validateAs="phoneus" />

Picklist:

<c:enhancedSelect fieldName="Picklist__c" pageController="{!this}" object="{!TestObject__c}" /

Multi-Picklist (Multiselect)

<c:enhancedMultiselect pageController="{!this}" fieldName="Picklist_Multi_Select__c" object="{!TestObject__c}"  /

Lookup (Reference) :

<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" />

Lookup (Reference) :

<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" />

Textarea :

<c:enhancedTextarea pageController="{!this}" fieldName="Text_Area__c" expandable="true" width="145" height="50" />

Controller:

(1) Install enhanced components via unmanaged package install link.

(2) Have your main controller (which can be a standard controller) extend PageControllerBase:

public with sharing class DemoPageController extends PageControllerBase

If you want to use a standard controller include this:

	  public DemoPageController(ApexPages.StandardController controller) {
	    	standardCon = controller;
	        this.myObject = controller.getRecord();
	  }

Then include this function:

	  // First we save the values from the Enhanced Component controllers, then whatever standard fields there are.
	  // If you are using standard fields in addition to enhanced components, whichever method is utilizing fields required by the API should always be in the first position

	 public PageReference save()
	 {
	  	ecSave();
	  	standardCon.save();

	  	return null;
	 }

Page:

Include your favorite jQuery UI theme easily:

    <apex:stylesheet value="{!URLFOR($Resource.JQueryUICup,'development-bundle/themes/cupertino/jquery.ui.all.css')}"/>

See how standard themes will look by choosing the switch theme option on this page. You can also easily create your own theme with Themeroller.

On your page you will also need to enable validation.

The easiest way is to assign a form styleClass element to your form declaration:

<apex:form styleClass="form" >

Then just before you close your form tag add an action function:

       <apex:actionFunction action="{!pageController.save}" name="saveMe"></apex:actionFunction>
  </apex:form>

Then add the automatically generated javascript:

    <apex:outputText escape="false" value="{!pageController.completeJavascript}"/>

This line will not only add hotlinks to the Google and Microsoft CDNs (for JQuery, JQueryUI and JQuery validation plugin), it will enable validation any form with a form class and add all of the necessary methods for validation.

If you don’t want to use the automagic client-side validation, hotlink the necessary CDNs manually:

    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"/>
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.1/jquery-ui.min.js"/>

Here is a list of all of the Plugins currently included:

JQuery UI 1.8
JQuery Validation (Joern Zaefferer)
Autocomplete 1.1.1 (Joern Zaefferer)
Expandable 1.0 (Brandon Aaron)
Select Menu (Filament Group)
Multiselect 0.6 (Eric Hynds)

Github repo here.

Dreamforce is crazy. So many sessions, so many people to see, so little time. Moreover, there were a bunch of sessions related to Ruby, and it wasn’t always easy to know what sort of content would be covered ahead of time (esp. since some of them were added at the last minute).

I will summarize here all of the sessions covering Heroku and Ruby along with what you should know about the status of Ruby right now in the enterprise world, then present a summary and evaluation of Dreamforce presentations as a whole. It’s worth mentioning that all of these are among the most popular sessions, both from impressions at Dreamforce and Youtube views afterwards.

From high-level to very technical:


Platform State of the Union
The Platform State of the Union is the one *must* attend event for all developers. Highlights were the vision for the future of the platform by Byron Sebastian (former CEO Heroku, now Senior Vice President of Platform Technology), from 2:01-6:30, an appearance by the creator of Ruby and now, employee at Heroku, Matz, 6:40 – 8:40, as well as an extensive example from Barry Newman of Saveology of utilization of Heroku and Force.com platforms 35:48 – 45:00, followed and preceded by comments by Dave Carroll, Director of Dev Evangelism for Salesforce.


Heroku in the Enterprise
Oren Teich, COO @ Heroku
Very visually compelling and enthusiastic presentation by Oren Teich that gives a good introduction to the Heroku platform. Appropriately emphasized the core strengths of Heroku,”You as a developer have complete control over what is going on in your app.” Didn’t quite connect the dots as far as what would be compelling use cases for existing Salesforce customers. Nonetheless, my favorite presentation at Dreamforce.


Connecting Ruby Apps with Force.com
Alex Sutherland (Mavens) and Joel Dietz (me!)
Originally slated to be a more technical presentation, ended up being a high-level presentation of the use cases for hybrid apps that leverage the strengths of using the right tool for the right job. Also gives the history of Ruby integrations from the folks with the most experience (mainly Alex). Presented some compelling use cases for Ruby/Heroku utilization (although Joel Dietz said “umm” too many times, esp. at the beginning).


Building and Deploying Great Applications with Salesforce, Ruby, and Heroku
Danny Burkes, Pivotal Labs
Presentation by lead developer on how to use the new Database.com gem released by Salesforce at Dreamforce (see my earlier post for some background on this).


Using Ruby on Heroku
Alex Wong, Salesforce.com
Starter presentation on how to get a Ruby on Rails app running on Heroku. Another presentation with similar content was given by Morten Bagai (but doesn’t seem to have made its way to youtube).


Connect your Clouds with Force.com
Jeff Douglas, Appirio
Attempting to do a bit of everything and generally succeeding is Jeff Douglas. See his high-level description at 3:55 and demo of a mobile device focusing on Heroku at 36:14.

In general, all of the bases were covered somewhere at Dreamforce. There were introductory sessions for Ruby the language, introductory sessions for how to employ Heroku, high-level introductory sessions to the platform, and a couple sessions that showed compelling use cases and showed the when and what is the right tool for the job. In general, the Heroku sessions set a new standard for compelling presentations, and I’m confident that things will continue to progress in this direction — despite the fact that some of us (::cough cough::), continue to be forced to use the standard Salesforce powerpoint template.


Another thing, and I am confident that this will be resolved in the next six months or so, is the lack of an unified and compelling vision for what is the right tool when. The increased investment in all parts of the platform is fantastic, but there is still a bit more to be done as far as connecting the dots with existing enterprise clients of Salesforce and Heroku.

What follows are instructions on how to get started with the databasedotcom gem, released yesterday afternoon at Dreamforce.

The examples here will be assuming you use Heroku for hosting and deployment although you can use all of the features mentioned without Heroku if you so chose.

This is also for the most part a tutorial and not a replacement for the existing documentation includes as part of the databasedotcom gem on Github and shared via Ruby docs, which hopefully will be expanded as the gem gets some love.

There are two main components of the current release:

(1) A wrapper for the Force.com REST API which currently works with both Force.com and Database.com
(2) A wrapper for the Chatter API which will not be useful until Winter ’12 (or in orgs w/ api v. 23 already enabled)

There is also an additional controller released separately on Github which provides a class that your controllers (assuming you are using a Rails app) can extend. By doing so they will instantly get access to the Force.com or Database.com backend you are hooking into.

As of right now, the gem only supports Ruby 1.9.x, although support for earlier versions of Ruby is promised within the very near future. Although the development of the gem was commissioned by Salesforce/Heroku, maintenance is less certain and depends largely on your contributions.

The first thing you need to do is include the gem in your app. Add the databasedotcom gem to your Gemfile.

gem 'databasedotcom'

If desired, use the edge version instead of the released gem version. This will allow you to get the latest version (you will probably want this if testing in the next couple of days, not necessarily later once the few warts have been ironed out).

gem 'databasedotcom', :git => "https://github.com/heroku/databasedotcom.git"

I’m assuming you’ve already initialized your app on Heroku. If not, go through the Heroku starter tutorial and create your heroku app.

I also recommend adding ssl to your Heroku app:

heroku addons:add ssl:piggyback

The first thing you need to do is add your credentials. You will need to add remote access for your heroku app in Salesforce (Setup -> Develop -> Remote Access).

Note your consumer key and secret. For the purposes of this gem, the client id is always your consumer key, and client secret is the same as consumer secret.

You can add this information to your app in one of three ways: (1) explicitly passing a hash. (2) Setting environment variables via Heroku (3) setting up a yml file in your config folder with the credentials. I recommend doing (3) unless you have a reason to use one of the other options.

The second thing you need to do to authenticate is do the OAuth handshake.
I recommend using the username and password combination for the user with the appropriate permissions for your org.

These can also be set in your yml file. I recommend also turning on debugging.

This will lead to a file called “databasedotcom.yml” in the config folder with the following info:

client_id: CONSUMER_KEY_FROM_REMOTE_ACCESS
client_secret: SECRET_FROM_REMOTE_ACCESS
username: SALESFORCE_USERNAME
password: PASSWORD_PLUS_SEC_TOKEN
debugging: true

Now make sure that is included and deploy the yml to Heroku.

To actually use the gem I recommend starting by extending the databasedotcom controller. Your code will look like this:

class SObjectNameController &lt; DatabasedotcomController

You can then easily refer to the objects you need in that controller.

For instance in the index method you can do

@users = User.all

Where “User” is now your automagically instantiated SObject class queried via the REST API. The way this works is that if you use a variable (e.g. “User”) that is unknown to the class it will find all of the available SObjects and attempt to instantiate a new instance.

That should be enough to get you started. A bunch of other useful examples are in dburkes’ example code.

One note of caution, there is as of yet no session management for this app, so if your auth token times out you will need to re-authenticate yourself.

Krishnan Subramanian and Ben Kepes have just delivered a needed update on the state of cloud warfare, focusing especially on recent moves by Heroku (where I was earlier today). Krish of CloudAve breaks down the contenders into three main groups:

Traditional (Heroku) Server like a repository. You push. Everything just works.
Packaged (Amazon). Push, but exposed IaaS layer.
Federated (VMWare). Network of clouds, customization in side.

Krish expects federated servers to win out. Although he doesn’t pick any winners, he says Cloud Foundry/VMWare is the front runner at the moment. Folks like Heroku aren’t apparently not competitive for big enterprise apps.

Ben Kepes suggest the division is more like this:

Infrastructure PaaS (Heroku, Amazon). Caters to developers used to working with infrastructure. Customization where you need it.
Application PaaS (Force.com). Just get to the app! Fully managed infrastructure.

He also suggests that these are fairly separate arenas and are diverging.

First of all, I’m more on the Ben Kepes side of things. Basically, how you manage your PaaS offering (hopefully well!) is a distinct issue to how it appears to the world. Architectural decisions are not features. Choosing to expose certain aspects to your users or provide for certain technologies and not others is. However, diversification is frequently not a winning strategy if it ends up with feature bloat — too many features requiring maintenance without necessarily meeting the needs of paying users. What do the users want? I’d guess the main aspects are the following: ease of use, scalability, features, price. The fact that different market segments will weight different aspects differently is a good reason why despite a crowded market there will probably be a lot of contenders for quite some time.

Second, it is worth noting who is not mentioned. Microsoft is still here (albeit not a front runner), but Google and other Ruby cloud folks (Engine Yard) are not highlighted at all. Yikes!

Third, it is worth noting the challenge of the “enterprise,” which most likely still hasn’t moved much if any of its core services into the cloud. Yes, Salesforce is “enterprisy,” but apps are usually extensions of its core CRM functionality, not fully featured “standalone” apps. Who will service them? I think that is still to be determined, and I wouldn’t write off any of the main contenders just yet.

Heroku co-founder Adam Wiggins stated in a recent interview that Salesforce is “Really good with business and enterprise, but … not necessarily as knowledgeable about how to engage developers.” That started this fascinating exchange with Salesforce’s ISV Architect Evangelist Shoby Abdi:






 


So is there an “engagement equation” ? Why are developers interested, engaged, and passionate in certain things and not others?

Regardless of what Salesforce is doing or not doing, here are my suggestions for how to engage developers better:

Tools that are awesome
– If you want developers to be productive and happy, give them good tools

Tools that can be modified
– Good developers, like folks in other fields, like to tweak their tools. Also try not to lock people into tools that you’ve made.

Cutting-edge technology
– Awesomeness in technology usually means things that are pushing some technological edge. Integrations between existing technologies frequently do not meet this standard (hint: XML and SOAP are not cutting-edge any more).

Push your edge
– Not just with respect to technologies, but also more broadly with respect to how you work and who you work with — competitions and late night coding sessions are awesome! As Yehuda Katz says, “Find something impossible and do it.”

Props
– Don’t leave your developers in the basement contemplating how to siphon fractions of cents from your corporate bank account. Give them props for what they do. Open source is a lot about props. People can see what you did and what you can do (follow me on Github!).

Independence

– Brilliant people frequently want to work on a variety of stimulating things since they get smarter that way. Remember, more challenge (usually) equals better. There needs to be room for people hack here, hack there, hack around, whatever. Don’t put chains on your developer!

Insulate

– Specialization is awesome. Some folks work really well on some things but don’t want to deal with others. Don’t make your developers do things other than development or sit through the presentations of people who do. CIOs should get paid more to drink corporate kool-aid. Don’t make your developers!

$$$

Not the number one concern for awesome developers, admittedly, but a concern. Don’t throw pennies at people contributing in awesome ways. Find some way to make them part of a thriving ecosystem. They don’t want to starve (me neither, hire me!)

I’m not going to issue a Salesforce grade in each of these areas, but I think it is clear that Wiggins is correct in general. Salesforce has a way to go in engaging developers. Hopefully Heroku can be a turning point.

This week I :

(1) Wrote and deployed a Sinatra App to Heroku to test Jeff Douglas’s code. It works! Link.

(2) Leveraged the Cinch framework to write an IRC Bot for the #salesforce IRC channel on Freenode. Please say hello to “Saasy” in the #salesforce channel and see what it can do.

(3) Wrote and deployed a simple Rails app (v. 3) to Heroku which displays the log from the IRC Bot (link edited 2/28/11).

Here are some takeaways:

(1) Getting started with Ruby can be a bit tough. There are often versioning issues and incompatibilities which can take a long time to solve. I was switching back between different versions of Ruby, Rails, and various gems — often finding that documentation was out of date. You also need to spend a fair amount of time on the command line, which can be difficult for folks used to a super IDE.

(2) Writing with Ruby is fun. Of course, there is a learning curve with anything, but there is a lot of syntactical sugar that makes writing Ruby one of my favorite things to do (once I get the hang of it).

(3) Heroku is awesome. I’ve written a couple Rails apps before but deployment was kind of pain. No longer! Heroku is super fun and super easy.

(4) The Ruby community is great. Even if sorting through blogs to find up-to-date instructions is not the most fun activity, there is tons of information out there and also lots of helpful people on various IRC channels (#heroku #ruby #cinch #rubyonrails).

So why not get started? For resources I highly highly recommend Peepcode, as well as the “Pickaxe”. For a (if you are doing Rails stuff, also the Agile Guide). For a quirkier, quicker, and in many ways more delightful (if not as comprehensive) approach, check out Why’s Guide to Ruby and learn the meaning of chunky bacon.

Special thanks to Domink Honnef, who provided helpful advice and put up with my safe harbor statement testing on the #cinch-bots channel, as well as aliasweird, apothecary, and others who made helpful suggestions re: the irc bot in #salesforce.

Problem:

You use the 10000 record limit on your queries but they still could fail since you might return 5000 in one and 6000 in the next leading to greater than 10000 records returned. Or potentially more annoying… running into the different limits at play when you are in a test method.

Solution:

Use my rapidly growing Limit Utilities class:

public class LimitsUtility 
{
        static final Integer PERCENT_PER_QUERY = 65;

	public Integer rowsAvailable()
	{
		Integer rowLimit = Math.round( ( Limits.getLimitQueryRows() - Limits.getQueryRows() ) *  ( PERCENT_PER_QUERY / 100.00 ) );
		if (rowLimit < 15) 
			rowLimit = 1;      
		return rowLimit;
	}  

}

This function simply takes the total limit and subtracts the available rows, then only queries a certain percentage of the available rows (in this case, 65%).

Use as follows:

List<SObject> sos = [select id from MySObject__c limit = :LimitsUtility.rowsAvailable() ];

I’ve also created a little spreadsheet to show how fast you will burn down the queries at various percentages (assuming you are hitting a full record set).

Note that things won’t be quite this bad if you use my method, since it will drop the limit to 1 if you go below 15 available rows, giving you a little bit of an extra lifeline before you hit the limit. This code is now also available on Snipplr.

With the sponsorship of the phenomenal company Hoopla Software, I’ve put together a number of enhancements to the SOQLBuilder as included in Apex-lang, a community project headed by developer hero Richard Vanhook. For those who don’t know, SOQL Builder allows you to simply and reliably create queries like this:

new al.SoqlBuilder()
 .selectx('name')
 .fromx('Opportunity')
 .wherex(new al.FieldCondition('employees').lessThan(10))
 .toSoql();

I’ve added support for aggregate queries:

Count:

new al.SoqlBuilder()
 .selectCount('Id')
 .fromx('Opportunity')
 .toSoql();

Sum:

new al.SoqlBuilder()
 .selectSumx('Amount')
 .fromx('Opportunity')
 .toSoql();

Average:

new al.SoqlBuilder()
 .selectAveragex('Amount')
 .fromx('Opportunity')
 .toSoql();

Max:

new al.SoqlBuilder()
 .selectMaxx('Amount')
 .fromx('Opportunity')
 .toSoql();

Min:

new al.SoqlBuilder()
 .selectMinx('Amount')
 .fromx('Opportunity')
 .toSoql();

I’ve also added support for Group by:

new al.SoqlBuilder()
 .selectx('OwnerId')
 .fromx('Opportunity')
 .groupBy('OwnerId')
 .toSoql();

Get Apex-lang here.

Here’s a video showing the sort of things that are possible with this library:

@fractastical updates

May 2013
M T W T F S S
« Dec    
 12345
6789101112
13141516171819
20212223242526
2728293031  
Follow

Get every new post delivered to your Inbox.

Join 951 other followers