You are currently browsing the category archive for the ‘Salesforce’ category.
Since I’m one of few people with experience working in both Ruby and Salesforce/Force.com/APEX and with a working knowledge of various PaaS (platform-as-service) offerings and long time YCombinator junky, here are my brief thoughts on who wins here and why:
Winners:
Heroku — biggest exit from the YCombinator group to date by a significant margin and chance to take Ruby to the next level.
Salesforce — this is a bit complicated since the problem here is integration and actually developing an attractive development platform which can deliver on the promise of PaaS and SaaS. Salesforce’s developer outreach is intense but often runs up conflicts with their underlying architecture, which has warts (see my post here on the advantages and disadvantages of the platform as it currently exists). This could make it fun to code on the Force.com platform which would be a huge win for developers and Salesforce alike.
YCombinator & co. — YCombinator hits the big leagues here but it is hard to see how this acquisition will be perceived a few years out, which largely depends on Heroku employees staying on and effectively building an enterprise platform for Ruby — and Rubyists everywhere seeing this as a good thing and leaving the 37 Signals anti- large company bandwagon. YCombinator and especially Paul Graham also have a significant anti- large company bent, leaving Yahoo after they converted what become Yahoo Stores into “blub” instead of a super language and has written on how large companies stifle innovation. One suspects Conde Nast is not entirely happy with their pricey Reddit acquisition from a couple years ago and this will be a challenge to show that one can strike a balance between small team innovation and big company needs (e.g. integration is king).
Ruby — By far the biggest winner here is Ruby the language which has struggled for a long time with the association anti-enterprise atmosphere of the Rails community. As frequently noted on Hacker News threads there are still lots of problems with Ruby libraries that don’t exist in their Java peers necessitating but this will be eased with larger scale adoption and (hopefully) less coverage of DHH’s loud talking.
Neutral:
Apex — Apex, the Java-derived platform language of Salesforce will be around in perpetuity, or so I have been assured by my Jedi master, also lead Developer Evangelist for Salesforce (tweet here).
The Cloud — Probably will turn out for the best, but there will be a lot of technical challenges in the implementation and I’m sticking with “wait and see” for now.
Engine Yard — Should raise their valuation but could also leave them in the dust.
Losers:
Java — Oracle has done what it can to drive people away from the Java world which is kind of sad but great for the Ruby world, which looks like it could absorb a lot of the enterprise Java talent, esp. if there was a Cloud platform that provided performance at a decent price without the typical hassle of Java deployment.
Oracle — All the Oracle customers and contractors I know don’t like working with them and think that their products are overpriced, etc. Moreover, they’ve driven a huge wedge between themselves and the world wide developer community with their latest pattern of litigation which is, frankly, ridiculous. I’d plan to abandon ship now.
Google App Engine — Latest buzz from folk attempting to use it for significant business purposes is that it just doesn’t work the way they need it to, with all sorts of limitations on par with the Salesforce ones and yet without many of the benefits. Will need a major boost from Google to keep up with Benioff and Salesforce’s movin’ and groovin’
Microsoft — Not sure what they are doing any more. I think it is safe to ignore them.
Joel Dietz, Titania, Inc.
Although my last post on the Force.com platform described that Force.com is not be the best solution for every problem, I thought I’d take a moment to highlight some of my favorite things about Salesforce:
(10) The Best CRM 
Almost goes without saying. Are there even any serious competitors left?
(9) In the Cloud
Also hard to find any real cloud skeptics anymore… unless they are selling mainframes.
(8) Trust
Security, up time, managed scalability.
(7) Cool Kool-Aid
Salesforce marketing is fantastic. Every web page, every screen I’ve every seen is well crafted and visually appealing.
(6) Non-profit engagement
1-1-1 model, Salesforce Foundation, Non-Profit Starter Pack (Side note: I would really like this job if I wasn’t otherwise engaged…)
(5) Marc Benioff’s Aura
To feel my hair blow back once more as he walks by! Not only does Benioff have excellent taste and stage presence, he never misses a chance for a good joke.
(4) Constant Innovation
Chatter, VMForce, amazing bunch of planned of improvements for Winter ’11 — the sky is the limit and Salesforce is going there.
(3) The people
I’m constantly amazed by the enthusiasm and responsiveness of Salesforce staff, both on the community boards and everywhere else, not to mention the diverse pool of admins, developers and users.
(2) No software
Iaas, PaaS, SaaS. On demand, awesome, without a doubt the best in class.
(1) Real people, real needs.
One of the most amazing aspects of being a Force.com developer is how connected I feel to the real needs of real people. The ability to see newly smiling faces as they experience previously unattainable functionality simply can’t be beat!
I’ve been bothered for awhile that when you search for advantages for developing on the Force.com Platform one of the first Google results is a thread on a forum listing many perceived disadvantages from a development perspective. Even worse, because of the rapid development of the platform many of the disadvantages listed are no longer correct. In this post I will discuss both advantages and disadvantages relating to development on the Force.com platform.
Advantages
(1) Quick access to Salesforce’s existing 82,400 company user base ( which has money to spend ) through the AppExchange (only a $300 listing fee).
(2) Piggy back off Salesforce’s powerful existing functionality, including:
- User management and authentication
- Administrative interface
- Reporting and analytics
- Dynamic API
- Toolkits and integrations for other languages and platforms(3) PaaS offering allows you not to worry about server maintenance or architecture
(4) Governor limits and test code coverage enforce some degree of best practice
(5) Security, both because of code review and because of high degree of control on the platform (see #2)
(6) Java-like syntax speeds learning curve for new developers
(7) Native “Visualforce” elements allow quick and easy information output
(8) Active community. Lots of information out there and active participation from Salesforce staff
(9) Object metadata can be leveraged for powerful functionality
(10) Actively under development (Big things underway with VMForce).
Disadvantages
(1) APEX is not a fully featured language
-Lots of things you might wish were there aren’t
- You will have to port them yourself or make outbound webservice calls(2) Hard to know if you will really make money
- Hard to impossible to find revenue numbers for the AppExchange
- Per-user licensing creates a pretty linear margin on license fees (as opposed to potentially exponential on a metered system like GAE or EC2).
- Data based pricing makes it pricy for folks with lots of data(3) Debugging can be extraordinarily slow:
- No real debugger
- Places where you don’t even have a debug log (not enabled, in a managed package, reached the limit, or weird errors that don’t leave an entry).
- Unfixed bugs or quirks on the platform that you wouldn’t expect (i.e. undocumented differences between commandLink and commandButton).(4) Ideaexchange and other reporting tools tend to be admin focused
and geared towards new features, not fixes or better developer tools(5) Governor limits sometimes make sense, but at other times they can be very difficult and prevent what would be best practice. Very easy to get in a place where you are trapped by a governor limit and very hard to know ahead of time whether or not any given practice you will take there (unless you already have a lot of time playing “dodge the governor limit” ). These are doubly a problem when it comes to test coverage.
(6) Developer tools continue to be somewhat lacking (even though the Force.com IDE runs in Eclipse you can’t use many of the Java focused extensions and build time is slow).
Incorrect Criticisms
(1) WRONG: There is no namespacing or packaging.
RIGHT: Namespace and packaging exist but are controlled via metadata (and unfortunately do not allow different folders in the Force.com IDE default view).
(2) WRONG: Security model is restrictive
RIGHT: A restrictive security model can be a robust security model. There are layers of complexity and in this case complexity equals customizability and power.
(3) WRONG: Difficult to convert SObjects to JSONObjects
RIGHT: JSONObject implementation makes this fairly simple.
(4) WRONG: Governor limits are terrible
RIGHT: Governor limits makes sense given the Force.com architecture (although they can be limiting and frustrating at times)
(5) WRONG: Support is poor
RIGHT: It is not realistic to expect excellent free developer support and if you want developer-focused support you should be willing to pay for the Premier offering.
My Recommendations
Do:
There may be some pain, but you should be okay developing small to mid-size apps on the Force.com platform, and you will do even better if you learn some Tips and Tricks and/or minimize coding in APEX (i.e. convert everything to JSON and do your processing in Javascript). I’d also recommend against trying to do anything too creative or with going in with expectations that are too high.
Don’t:
Don’t try to develop an enterprise app of significant size or scope on the platform. Even if the OEM pricing looks attractive, there is a good chance you will end up sinking ever deeper in a quagmire of multiplying unexplained buggy behavior and insurmountable governor limits (note: this recommendation may change with VMForce).
Takeaway
Part of the necessity here is understanding where PaaS is today, and the reality is that while PaaS as a service beyond IaaS, while developing rapidly, is not yet a platform ready for development of large enterprise ready apps. It is fine for extensions of existing technology, but be wary if you try for much more than this. This does not reflect poorly on Salesforce.com as they have been pushing the envelope on what is possible with all the force available to them. There are at the moment very many useful and potentially profitable things that can be done with the platform and if you have the time and resources, I strongly suggest doing them (or at least getting your feet wet while waiting for things to develop further).
Special thanks to Wes Nolte and Alex Sutherland for suggestions and corrections, as well as attendees at the Philadephia Dev Meetup (@botoscloud, @cashion, @matschaffer).
Come to the first ever Salesforce Developer focused Meetup in Philadelphia next Tuesday.
Start time: 6:30 pm
Location: Nodding Head
Some things that will definitely happen:
(1) Development team at Hoopla will be sharing about their awesome Ruby gem for rapid Salesforce deployment
(2) I will discuss exciting new partnerships
(3) Beer will be consumed
First round of drinks is on me! ( and while you are at it please join our mailing list ).
Since loading large numbers of records proved impossible, I’ve updated my jQuery autocomplete integration to perform an Ajax call and retrieve associated records on key press.
Benefits:
(1) Live Ajax autocomplete on any object
(2) Easy to use
(3) Easily themable with jQuery Themeroller
(4) Easily customizable (implementation is open source)
(5) Can provide a filter
Usage:
<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" bigset="true" />
Defaults are:
(1) 2 characters must be typed in before the call
(2) Call with ‘LIKE’ as specified in Abhinav Gupta’s helpful post on the subject
(3) Lookup on 8 elements while the string is under 3 characters and 100 after this
To provide a filter pass a filter string in SOQL format such as the following:
<c:enhancedLookup pageController="{!this}" fieldName="Test_Lookup_Object__c" objectToLookup="TestLookupObject__c" bigset="true" filterString="WHERE type__c != 'Bear'" />
I’ve added this and numerous other enhancements to the jQuery for Salesforce library at Google Code.
I’ve also added the controller to my library on Snipplr for reference.
Setting up jqGrid is not terribly difficult, but customizing it can be somewhat more difficult. Take this paragraph from the wiki article on search:
There are four approaches:
* a toolbar searching
* a custom searching
* a single field searching
* a more complex approach involving many fields and conditions – advanced searchingThese approaches use common options from jqGrid and so can be called only on an already-constructed grid. Every search method requires that some additional module should be included into the package. Also refer to Download or in every specific module on what should be included
But there are no links to article on the different search modules and the download page does not include any more details.
What to do? Here’s a working search function partially provided by Trirand support:
<script type="text/javascript">
$.jgrid.no_legacy_api = true;
$.jgrid.useJSON = true;
</script>
<script type="text/javascript">
function searchContact(letter, field, oper)
{
if(!oper) oper = 'bw';
// build the filter
var filter = {"groupOp":"OR","rules":[{"field":"FirstName","op":oper,"data":letter},{"field":"Lastname","op":oper,"data":letter},{"field":"Phone","op":oper,"data":letter}] };
$("#Contactdatatable").jqGrid('setGridParam',{search:true, postData:{filters:filter} } );
$("#Contactdatatable").trigger("reloadGrid");
return false;
}
</script>
Here is what a modified version looks like in my Salesforce component:
function search{!uid}(arg, field, oper)
{
if(!oper) oper = 'bw';
if(field)
$enhanced{!uid}.jqGrid('setGridParam',{search:true, postData:{searchOper:oper,searchField:field, searchString:arg}});
else {
var filter = {"groupOp":"OR","rules":{!colRulesJson} };
$enhanced{!uid}.jqGrid('setGridParam',{search:true, postData:{filters:filter} });
}
$enhanced{!uid}.trigger("reloadGrid");
return false;
}
An editable, searchable implementation for Salesforce has just been finished as part of something I am working on for the Salesforce Foundation:
Soon to be generally available.
