You are currently browsing the category archive for the ‘Ruby’ category.
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.
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 < 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.
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.
