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

Very few companies are able to successfully manage multiple languages in house, although frequently many are forced at least negotiate between using one back-end language (PHP/Ruby/JAVA) and one front-end one (Javascript of some flavor), this is rarely perceived as ideal from a management perspective — diversity may be great when you are a pumped up programmer wanting to work (or dabble) in a panoply of different languages, but unless you are able to fully manage the extent of all your projects, including needed future updates for eternity, the use of “proprietary” or specialized languages provides a substantial added cost to your company. This is simply to say that a principle which applies in other industries applies also within software: fungibility.

If, as I have suggested, to the maxim “real artists ship” should be added “real apps scale,” scalability is not merely a function of more users, but necessarily of a codebase larger than a single or pair of geniuses can create. This is why many of the great geniuses of history, among them Plato and Aristotle, worked within the context of schools, distributing the knowledge that they had achieved over a larger extent of time and space via human intermediaries (i.e. students), and these schools, of course, had teachers beyond the genius-founder.

Business is, if frequently following a different set of impulses than potentially “love of wisdom” and educational institutions which follow in their potentially altruistic path, is nonetheless subject to a similar set of limitations. One simply cannot know everything and, even if, in a fractal-mode, one can understand the basic principles of a subject at a high level of abstraction, this “higher-knowing” does not necessarily give one the skills to solve all problems that arise at the microscopic level of the day to day.

Programmer-mathmagicians have frequently attempted to solve this problem by simply residing in the highest possible level of abstraction, not withstanding that anything written, at least as attested in many philosophical schools, cannot represent reality at the most abstract way. In this sense, we soon reach the limitations even of an incredibly abstract language (i.e. Lisp), insofar as the implementation must contain a machine and it is no longer a truely and “purely” a lisp machine as soon as it contains assembler.

The fractal is a symbol, in a certain fashion, of the juncture not only of the sometimes invisible mathematical patterns which hide between and beyond virtually all of nature, but of the fascinating interjection of beauty which appears once we dive beyond that which is easily put into words.

In a sense, to recognize this trend in the 21st century we must have some historical awareness, at least in the sense in which historical awareness allows us to understand the categories in which we think as a product of our education at a particular moment in history. This allows us to realize that the modern emphasis on the defined self distances us from the “genius” of the supreme flow state which was exalted as “divine madness” in the early Greek philosophical tradition and similarly exclaimed in Indian and Chinese philosophical traditions.

However, supposing we have let the defined “self” go, even for a moment, how do we descend into the world of diverse and variegated languages? The challenge of Plato’s academy and every educational institution since was just that — we simply have to descend beyond our contemplation of beauty and into the dirt of the every day.

In an ancient Chinese conception, this was known as the fusion of heaven and earth, and heaven here was not simply a place but an active force which, once opened up to, could serve to illuminate divide the great expanses.

The polyglot challenge and accompanying fractal imagery, is then, potentially an opportunity to recognize the grand patterns that exist on a higher level of abstraction and, by recognizing the grand patterns (and beauty that accompanies them) to dive into the details with the “right tool for the right job,” a task that is otherwise quite difficult to realize.

The sad problem is that frequently the world remains divided between those who, in a particular place of abstraction, refuse to deal with the nitty-gritty details of the “blub” things of ordinary life, and those who, because of immersion in “the way things are done,” fail to see any better way.

This is particularly sad at a moment in time, like the present, where “the way things are done” simply is shown to be insufficient. If, to use a military metaphor, there is an enemy at the gates and yet the soldiers refuse to fight because because the plans are not well-defined, the stocks of food or weapons are insufficient, or because their commanders are idiots, we might understand this. We can even picture them retiring into the countryside because the countryside is a safe and comfortable place to be. However, no problems are solved this way.

However, this suggests that even if a military metaphor might be appropriate, the appropriate response is rarely “forward,” in the charge sounded by the exuberant officer, but rather up, in the sense that a contemplation of things in context of a higher level of abstraction (or in accordance with the Way or Dao of the great philosopher of war Sunzi), will produce more beneficial results than those who respond to instigation by either charges or retreat.

As for the polyglot future I have claimed in other posts to be excited by, I think it is gradually reaching increased definition. It demands, among other things, people who are willing to know things well at a level of an abstraction and be capable of knowing the details while admitting they do not know everything. This is to suggest that the developer-architect will be an increasingly important role as multiple platforms are engaged in increasing levels of abstraction.

However, it also demands that these same people are capable of engaging at the most detailed level and, with regards to this, I can only be excited for a a most “fractastical” future.

New project of mine on Github.

Explanation:

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.

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.

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.

@fractastical updates

July 2014
M T W T F S S
« Mar    
 123456
78910111213
14151617181920
21222324252627
28293031  
Follow

Get every new post delivered to your Inbox.

Join 1,269 other followers