Every once and awhile I try to go through my records and see what sort of assets I have out there floating around on the web. I’ll put this in the form of a list and then put a few lessons learned.

Blogs: WordPress.com (1 owner, 2 contributor), WordPress.org (2 owner), Tumblr (1), Posterous (1), Blogger (3, all defunct). Also had several Ruby-powered blogs all gone.
Social Media: Twitter (1 business, 1 personal, 1 product, contribute to 2 others), Facebook (1 + 1 page), Google+ (1 + 1 page)
Hosts: Dreamhost (1), Yahoo (1), Linode VPS (1)
CMS: WordPress (2), Refinery CMS (1), Hardcoded HTML (1)
Discussion Boards: PhPBB (1), Invasion Power (1). Contribute to a few others.
Domains: Yahoo (9), Network Solutions (1), Dreamhost (1), Godaddy (1).

News Aggregators: Hacker News (2)

From top to bottom:

Blogs: No clear lesson from the blog world, only that at the moment it makes sense to have multiple blogs divided by topic. I have a company blog, a developer blog (this one), a “work” essay blog, a personal essay blog, and an art/inspiration-of-the-moment tumblog. Over time moved to feature-rich easily-maintainable hosted options from more custom options, don’t plan to go back. That said, I miss the nice syntax highlighting available not on WordPress.com, which is probably the major reason why I am planning to move this blog over to wordpress.org in the near future.

Social Media: Twitter, and particularly my “work” twitter account gets the most attention (I put it in quotes because my I don’t believe that work should ever be work, but rather fun and I try to keep things that way). My personal twitter gets barely any love. Facebook for me is now 60% liking things from the “work” world and 40% personal updates, which seems a bit odd. Google+ is an outlet for nerdy things that I don’t think will be appreciable to a more general audience.

Hosts: I’m a legacy customer of Yahoo from when they were great. I am very happy with Dreamhost but it is too much hassle to move all of my websites over there.

CMS: I’ve run virtually every CMS known to man at some point and at this point I actually don’t see any need for most sites for anything more complicated than WordPress. I just spent some time with two Ruby CMSes (Locomotive and Refinery) but would never recommend them to anyone who doesn’t want to spend a rather substantial amount of time tinkering in order to get it up and running for what is, in general, a less capable system (that said, you can extend it yourself, which is cool).

Discussion Boards: Was happy with PhpBB for a long time but at some point lost the time/interest to make all the modifications to optimize it. Been experimenting with other options (vBulletin/IPB) but haven’t had the time to pick one. Paying for IPB but not using it.

Domains: I’ve greatly reduced my number of parked domains, largely because I was all on Yahoo and they more than tripled their prices. Not too sure that this was the right decision, but absolutely hated Godaddy and it was too much of a pain to transfer domains. Still looking for a good, cheap host to park domains for future ideas if anyone has a suggestion. I like Network Solutions okay but they just spammed me with “.XXX” domain advertisements which I didn’t appreciate.


News Aggregator: 2011 was the year when I basically stopped reading all news not immediately relevant to what I was doing, perhaps because I find it a generally depressing waste of time (I used to read the Economist cover to cover and follow a bunch of other publications). The major winner here is Hacker News. I use two accounts, one for general posting and one for commenting on things which I expect will be controversial (Hacker News has a bunch of “karma police” that, in what I believe to be a generally laudable attempt to maintain high comment quality, frequently go overboard in downmodding non-mainstream viewpoints).

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.

In this tutorial we will go from zero to ninja speed in approximately ten minutes. If you have problems approaching ninja speed, it is probably because you are in ruby version management hell, gem dependency hell, or any other number of hells that brave would-be ninjas are occasionally trapped in. Should you end up here, prayer and Google may help you.

Step one: Create your rails app.

 rails new ninjaspeed 

Step two: Add the database.com and helper gem to your GEMFILE (this will be in the ninjaspeed directory)

 gem 'databasedotcom'
 gem 'databasedotcom-rails' 

Also add the postgres gem (you aren’t using the db on Heroku but need it anyways) and a gem to handle precompiled javascript (for the JQuery Mobile):

 gem 'pg'
gem 'therubyracer'
 

Step three: Install the new gems

sudo bundle install

Step four: Add scaffolding for a new resource that corresponds to a resource in Salesforce

 rails generate scaffold_controller Lead FirstName:String LastName:String Company:String 

Add an entry in your routes.rb file

 resources :leads

Rails is straight up MVC, and you just created a controller and a view. Check out your app/controllers and app/views folders to see them. Salesforce/Database.com will be your Model.

Step five: Deploy this baby to Heroku

 
git init 
git add .
git commit -m "i love databasedotcom"
heroku create
git push heroku master
heroku addons add:piggyback_ssl

Step six: Take the new funky fantastic name you got and enable remote access in Salesforce

Login to salesforce. Go to Setup -> Develop -> Remote Access -> New 

Enter the address of your app (e.g. https://stormin'-samurai-558.herokuapp.com)

You will get a client key (this is also the client_id) and your client secret 

Step seven: Add your salesforce credentials to a file in the config folder called databasedotcom.yml

 
databasedotcom.yml
####
client_id: 3MVG.....
client_secret: 1323224123...
username: mysalesforceusername@login.com
password: passwordPlusSecToken
host: login.salesforce.com <-- use test.salesforcecom if using a sandbox
debugging: true

Step eight: Connect your app to Salesforce

Add this to your app/controllers/leads_controller

 
LeadsController < ApplicationController
  include Databasedotcom::Rails::Controller

In the same file you need to add a few more required fields. Navigate to the create method and add three lines:

 
  def create
    @lead = Lead.new(params[:lead])

    # ADD ME
    @lead['OwnerId'] = '005U0000000IekIIAS'    <-- ownerId here is the Id of the User you want the Lead associated with
    @lead['IsConverted'] = false
    @lead['IsUnreadByOwner'] = true
    # END

Thanks to some backend magic, the databasedotcom-rails gem automatically initializes the client you need to connect to salesforce so you don’t have to worry about it.

Step eight: Add in a jQuery mobile stylesheet so this doesn’t look super ghetto (optional)
Navigate to app/views/layouts/application.html.erb and edit these lines to the header:

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.css" />
<script src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.js"></script>

Put the yield tag in the body in a div like so:

<div data-role="page">
   <%= yield %>  
</div>

For your apps/views/leads/new.html.erb, divide into a couple of sections

<div data-role="header">
   Lead form
</div>
<div data-role="content">
   <%= render 'form' %>
</div>
<div data-role="footer">
   If you want it
</div>

Navigate to config/environments/production.rb, find the config.assets.compile, and set it to true (turn on the live compiliation of assets)

  config.assets.compile = true

Step nine: Remove extra stuff from your _form.html.erb/strong

This is all you need:

<%= form_for(@lead) do |f| %>

  <div class="field">
    <%= f.label :FirstName %><br />
    <%= f.text_field :FirstName %>
  </div>
  <div class="field">
    <%= f.label :LastName %><br />
    <%= f.text_field :LastName %>
  </div>
  <div class="field">
    <%= f.label :Company %><br />
    <%= f.text_field :Company %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

Step ten: Deploy to Heroku

git add .
git commit -m "I love databasedotcom even more now"
git push heroku master

Navigate to yourapp.heroku.com/lead/new, and presto-chango, a mobile-enabled submission form that hooks up to Salesforce.

You can also view leads in the system by navigating to yourapp.heroku.com/leads

Also, if you want to add in validation (and I suggest it) you can do this client-side rather than serverside.

Oh, and in case you were wondering the source code for all this is available on Github.

Please contact your congressperson today.

You have a git submodule. You want to update it (e.g. get the newest freshest code). Here’s what
you do:

I’ve already initialized my submodule of course:

git submodule add git@github.com:mysubmodule mySubmoduleDir

At some point later I try this.

git submodule update 

Ha ha you fool! This only gets you the copy that your submodule is already frozen at.

Try this instead:

cd mySubmoduleDirectory
git checkout master
git pull

Yes, I was the fool. You can go away now.

I stayed up until around three in the morning one night last week finishing this super addictive and awesome tutorial by jQuery creator John Resig. I’ve been through some little ditty tutorials on closures and had people attempt to explain what it is before, but Resig’s tutorial is to your average online tutorial what a tanto is to a wiener.

Even though in a certain sense I’ve never met a wiener I didn’t like, I’d prefer that if you were fighting on my side you had a proper weapon –
and no matter how many skillz you got, it always helps to sharpen them.

Part of the reason I like this approach so much is that there is very little unnecessary baggage. You figure out what you need to by reading the code, with a few quizzes where you write some code so that the lessons sink in. As things stand I think the quizzes are a little bit under-developed, and as a whole it could probably be a bit more content as far as examples and gradually developing a theme, but hey JResig has a whole book coming out soon. Another fantastic feature is that you can edit each example as you go along, so if something is not immediately obvious you can tweak it or can add in the necessary log statements.

As far as this goes, I believe this is the future of programming education (and education in general). Less paper, less explanation, more interaction, more cementing of the material. In other words, less talking, more doing.

Keep in mind this is a Ninja-level tutorial, so it assumes a fair bit of knowledge of Javascript that you probably won’t have if you’ve just been waving around a wiener. That said and despite some rough edges, I will repeat and say it is the best online tutorial I have ever seen.

Here are some highlights:

Context – One of the funkier bits of JS.
Closures – Show don’t tell. Love it!
Function Prototypes – A lot you can do here but tricky to get right
Inheritance – You have to understand this well if you are doing any Advanced Javascript

Truly awesome is when you get to see how all the building blocks fit together towards the end of the book as Resig appropriate builds up to (rather than dissects) the Prototype bind function.

I end with this beautiful example:

var ninja = { 
  yell: function(n){ 
    return n > 0 ? ninja.yell(n-1) + "a" : "hiy"; 
  } 
}; 

In case you were wondering, we are hiring ninjas over at Tquila.

Today I was performing some maintanence in Facebook and got caught in a wonderful infinite recaptcha loop, where Facebook asked me for my password, got it, asked me to fill out a recaptcha, I filled it out, and then kept asking me to fill out more and more recaptchas. I gave up after about ten. I tried again later and same problem.

If you are experiencing this problem, the solution is probably to switch accounts. In my case I was in as one of my Page accounts instead of my normal accounts. Once I switched back recaptcha worked as usual.

Hope this helps someone!

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.

Byron Sebastian, formerly CEO of Heroku and now GM of both Heroku and SVP Platforms for Salesforce pointed out in a recent interview of the different nature of developers currently working on the Force.com platform and those which Heroku reaches out to. Although this is highly recommended, there is little in the way of publicly available information on the difference between these two developer communities. So here’s the difference, exaggerated somewhat:

Dress code

Force: Probably forced to wear a suit from time to time and doesn’t mind it all that much, so long as it doesn’t always include a tie.
Heroku: Will look at you in a strange way if you suggest they wear a suit. And probably never talk to you again…

Emerging Tech

Force: Laughs at Salesforce announcements while reading the safe harbor statement and knows that he won’t get promised tech for a few more release cycles.
Heroku: Itching to get hands on new tech (Clojure, Node, etc.), spends his evenings working on side projects for fun.

Tools
Force: Likely using a snazzy IDE like the Force.com IDE (harhar). Occasionally upvotes ideas for new and better tools in the IdeaExchange but knows that his voice is not likely to be heard. Like here. ::cries::
Heroku: Very comfortable on the command line and using a text editor w/ nifty shortcuts like Textmate or a pro editor like Vim/Emacs. Generally sets up his own environment and doesn’t think or care much for the IDE world.

$$$
Force: Paid because every company of a certain size uses Salesforce because it is baddest most kick-ass CRM solution ever.
Heroku: Probably leveraging Rails or another Ruby framework to deliver small to mid-size web apps. When finds that some client uses Salesforce is a bit confused as to why. Looks at the UI and says, “Aaaaah! So 1990!” May attempt to convince VCs that they can build the next Salesforce on Rails.

Meetups
Force: Goes to conferences, listens to lots of lame jokes, drinks many liters of koolaid, and shouts or tweets “hurrah! hurrah!” as much as he possibly can. Possibly stops going out.
Heroku: Goes to conferences that are for developers only and heatedly discusses the pain points of the new edge rails version over a pint afterwards.

Configuration/Division of Labor
Force: Probably ends up doing some configuration because, oh my goodness, Salesforce is hella complex. Err, shouldn’t there be an admin here somewhere? Thankfully most of the time there is (I love you admins!). Designers are usually not employed, because Salesforce provides all the design for you (but should it? Stay tuned for my top secret jQuery Theme Engine for Salesforce…).
Heroku: Everything is code. There are only developers, no admins. Designers usually deliver css, etc. developers, who implement, although sometimes you have designers that can touch up Rails views themselves.

Integration
Force: Knows that the watchword of every mid-to-large size company is “integration” and probably spends lots of time with different APIs moving information from one data silo to another.
Heroku: If asked about integration, will say “Here is the sexy JSON REST API for my app, integrate to it however you want!”

Enterprise
Heroku: Enterprise epitomizes needless cruft and annoyances that developers who care about pushing forward technological possibilities shouldn’t have to worry about.
Force: What’s to think about? What is, is. Back to waiting for an awesome new version of the Force.com IDE. Oh, can I please get my stapler back?

It sounds like Byron Sebastian & co at Salesforce are not particularly keen to attempt to integrate these two communities, which makes a good deal of sense. It isn’t clear to me that they can co-exist. However, the road forward is far from clear. Much, although certainly not all of the Salesforce developer community are not developers in the traditional sense, having started with Salesforce’s “Clicks not Code” mantra and gone on to occasionally build triggers and other things necessary in the Salesforce environment that will be unusual if not incomprehensible to those used to working on smaller apps. This is entirely different from enthusiast programmers, who, despite a lot of experience with certain aspects of the cutting edge, usually don’t worry about problems of a certain annoyance level and/or complexity (e.g. scaling, integration) that every large company has to worry about. In other words, there is often a “bite the bullet and get the job done” attitude among experienced Force developers that makes them optimally suited for solving the sorts of problems that large companies have.

Great developers in both worlds will see the benefits that are there on each platform and the accompanying community. Salesforce should take every opportunity to merge these where this is appropriate, providing a seamless experience to those who want to bridge the gap. With this, there is an increasing need for elite teams that can acknowledge and utilize the strengths of both areas. In fact, this will be a major focus in my Dreamforce session on connecting Ruby on Rails apps with Force.com. Stay tuned.

@fractastical updates

 

February 2012
M T W T F S S
« Dec    
 12345
6789101112
13141516171819
20212223242526
272829  
Follow

Get every new post delivered to your Inbox.

Join 532 other followers