Aggregate Me!

Categories

Short Version: The rumors are true. I accepted a position at Facebook with a focus on Salesforce.

(That's about it. Read the long version for more details)

Long Version:I started working at Facebook in August with a focus on designing and developing apps on Force.com within the IT group. The group is very focused on embracing cloud-based solutions to maintain agility and efficiency during a hyper-growth phase.

My wife and I moved from Portland, OR to San Carlos, CA as part of the transition and simply love it. We've actually been considering a move to Silicon Valley for 2 years for the weather, family, and, well... this is the center of cloud computing. The Facebook position gave us the perfect opportunity to make the jump.

Why Facebook? The 3 primary motivations for working at Facebook are the cloud, a progressive IT group, and company culture.

The CloudFacebook's infrastructure is one of the most under appreciated cloud architectures in existence today.

When you consider that Salesforce can support 1.5M customers on 1,000 servers (a 1,500:1 ratio) you understand why we are at an important inflection point in IT infrastructure and must consider cloud-based solution providers at every opportunity. Multi-tenancy is just much more efficient.

Then when I look internally at Facebook supporting 300M users on 30,000 servers (a 10,000:1 ratio) the efficiencies of scalable cloud-based architecture become even more obvious and impressive. (I'd love to share how we accomplish this feat, but you'll just have to apply here first . It truly is amazing and gets more efficient with each release)

Facebook as an enterprise class cloud provider will become even more apparent within 10 years as the user base grows and takes their social graph with them into every facet of their life (phones, devices, automobiles). When Mark Zuckerberg coined the term "social utility" back in 2007, the average response was "Huh?... It's just a website where I communicate with my friends".

But as the social graph gets consumed via web service APIs and millions of people communicate through the service, the role of Facebook (and the reasoning behind Mark's comment) becomes much more like an AT&T for the web rather than just a website.

The focus and dedication to cloud-computing is so serious, that we will build all our own datacenters from the ground up going forward, starting first in Prineville, OR.

Progressive Information TechnologyI work in the IT group at Facebook in a ground floor opportunity at a rapidly growing company. We have an opportunity to learn from past enterprise IT architectures and challenge the norms using cloud computing and open source. The infrastructure put in place today will very likely still exist in 10+ years.

Unlike traditional IT roles, Facebook IT is responsible for the core product; our datacenters, servers, and technical operations. Our group is aligned very closely with the product Software Engineers.

Every IT asset; from CRM, ERP, Financials, HRM, SCM, ESB,... and a dozen other TLAs, are in it's first or second generation deployment. There are "build or buy" decisions being made constantly. My role often times involves demonstrating how to leverage what we've already "bought" (using Force.com for a variety of specific solutions).

Facebook takes a progressive stance on utilizing Salesforce as a platform and I've additionally been challenged with projects and opportunities that leverage my strengths outside just Salesforce development.

CultureI'm probably the youngest 40 year old most people will ever meet still enjoy the occasional hackathon, drinking lots of coffee and embracing the most progressive idea or concept emerging at the time in software development.

There is no other company that I can think of than Facebook that is the epitome of this type of culture. There is a kindred spirit amongst all Engineers at Facebook that is hard to explain. I've participated in 2 hackathons so far and will never miss future events.

Most people don't perceive Facebook as a technology company, but the internal esprit de corps is very focused on building cool stuff, simply for the enjoyment of building stuff. Facebook is a technology company.

Side ProjectsMaybe I'm being over ambitious to think I'll have any spare time to work on side projects, but here's a status of projects I continue to support and take great interest in on the side.

Passage .NET Portal Framework: This platform is still OEM'd by a couple partners who do the heavy lifting. The XOS framework has really proven that object oriented databases can be scalable and flexible. A couple more partners/resellers are in the process of developing Passage based solutions, so I don't think the end is in sight.

i-Dialogue: Other partners and associates have taken over the day to day hosting and support of i-Dialogue portals and sites. I still respond to any dlog related questions within 48 hours. Another developer has taken over all custom development, but I still enjoy occasionally optimizing the framework and have committed to participating in quarterly reviews/updates/patches.

Cool Sites: Similar to i-Dialogue, this native AppExchange app is primarily driven by partners. Cool Sites was developed to give my creative and web development friends (who rely primarily on HTML/CSS/JS skills) access to the rapidly growing Salesforce customer base.

There is a backlog of Cool Sites plugin requests that involve porting existing i-Dialogue components to Visualforce (Event calendar, knowledge base, shopping carts, partner finder, maps, etc...). Word on the street is that Salesforce acquired a CMS company and is preparing a similar offering for Dreamforce 2010, so I'm in "wait and see" mode re: the future of this project.

Cool Trends: I started this Salesforce native app after working with the Google Maps API on the Azure proof of concept app last Winter. It's a very simple data warehouse (only 2 custom objects) with time-series analysis charts for reporting day-over-day trends.

If time allows, I'll try to submit this to the AppExchange before Dreamforce 2010.

Cool Mesh: After years of designing and developing single-tenant enterprise web applications, the entrepreneur in me began to pursue the "next big thing". Cool Mesh is a massively scalable, multi-tenant, open-source, clustered computing project loosely based on the following ingredients:

Amazon EC2

Unix

Apache

Node.js

CouchDB / Cassandra

Immutable storage

Don't ask me what I'd do with a working prototype. Probably just re-invent business models I've worked on in the past

Chatter Bot: On the heels of receiving an award for Chatter Bot, I started delving into "The Internet of Things" and envisioning what Cloud 3.0 might look like. An idea emerged, based on Cool Mesh, that continues to intrigue me. Still dabbling.

Music in Schools (non-profit): I still support or volunteer for 3-5 non-profits on Salesforce and really believe in their vision. Immersing myself in a music education non-profit is where I'd like to start devoting my time next. I'm new to the bay area, so there's some research to do. Who knows; if I don't find a perfect NPO, then I'm open to launching one myself.

I'll be wandering the halls of Dreamforce 2010. Don't be a stranger. If you read this blog, then I hope we'll meet at the Tweetup

I missed the discussions on "open cloud" and "cloud standards" at OSCON 2010, but indirectly got the gist of it. Standards themselves aren't bad, but it's rarely a good idea to create a standard for the sake of just creating a standard.

I've observed 3 fundamental perspectives and their likely motivators on the issue of cloud standards:

1) Vendor: Invested $XXX million in software stack Y. Wants it proclaimed "standard" (for obvious reasons)2) Developer: Wants "write once run everywhere" in the name of "portability" (doesn't want to learn 5 different APIs)3) Consumer: Doesn't care. Wants it to "just work"

If you look across all cloud stacks today, what do you see that is common amongst them and could even remotely be called a "standard"? I see TCP/IP running on Intel x86 CPU architecture.

If someone told you 10 years ago "In order to democratize access to computing resources and enable ubiquitous access to information we all need to standardize on Intel x86 architecture and deliver services over IP", several people would have scoffed at that. It's incredible how far cloud computing has come as a "standard".

There is an art to minimizing standards in order to maximize adoption.

Look at electricity. For years there were debates over whether DC or AC power was better. The US finally standardized on a plug with 120V AC at 60Hz as a "standard" for electricity. 3 very simple data points that led to an explosion in adoption.

But look at the rest of the world. Different combinations of plugs, voltages, and frequencies abound! Fortunately these standards are all "open" and simple enough to allow for converters and transformers to fill the gaps. Fundamentally, the world really only agreed to standardize on alternating current (AC) at a range of voltages between 110-240 Volts. But for consumers, it "just works".

That's the way cloud computing is evolving. Building on the Internet (TCP/IP), running on servers (Intel x86), and bridging the gaps using a few basic tools (JSON, XML, SOAP, REST, CSV).

Check out Nicholas Carr's book "The Big Switch" for the back story on how industrial America moved towards standardized and centralized power utilities and how that parallels what's going on in cloud computing.

The Internet is called "the web" for a reason. It's in reference to its inherently chaotic data structure. Asserting standards to make sense of it won't help. It will only inhibit adoption. The web and cloud computing must be allowed to organically sprawl uninhibited.

Final thoughts:1) Vendors: Explain to customers which specific primitive cloud services you offer (Windows/Linux, HTTP/SSL/SMTP/FTP) and preempt the discussion on integration by providing APIs to raw computing resources.2) Developers: Sorry. The days of learning one language or standard are over. "Embrace the cloud!" The next killer app exists at the convergence of several cloud services (think mashups blending location, maps, social graph, consumer reviews, and merchant offers... all in one).3) Customers: Sorry about the noise. We'll get this sorted out as soon as possible and ensure the cloud "just works". Thank you for your patience

Social Networking: Contact maintains singular identity. Always up to date. Control of privacy and disclosure (LinkedIn, Facebook)

The consumer now has more power than ever. Consumers now generate more information about themselves than can be generated by 3rd parties.

Buying a list of leads that may be interested in buying camping gear will have no where near the effectiveness of publishing an ad on Facebook targeted at consumers with a self-identified interest in camping (See The Role of Advertising at Facebook).

Consumers will increasingly defer to their friends recommendations on which restaurants to visit, which shoes to buy, and which cars to drive.

Businesses must evolve past collecting and cleansing Contacts and instead collect meta-information that refers to customer-managed online profiles, such as Facebook and LinkedIn, for these resources are now truly authoritative. When there is a conflict between CRM Contact information and an online social network profile, the social profile will be master record.

Websites must evolve to become applications. Web forms soliciting contact information will become a thing of the past. Consumers will not have the patience to do anything more than a single click to identify interest in a product or service.

The video embedded in this blog post (and available here) demonstrates a Cool Sites application integrated with Facebook Connect and Salesforce CRM.

Trigger development (apologies to Roy Rogers' horse) is not done on a daily basis by a typical Force.com Developer.

In my case, Trigger development is similar to using regular expressions (regex) in that I often rely on documentation and previously developed code examples to refresh my memory, do the coding, then put it aside for several weeks/months.

I decided to create a more fluent Trigger template to address the following challenges and prevent me from repeatedly making the same mistakes:

Bulkification best practices not provisioned by the Trigger creation wizard

There are really only 2 tech blogs that I read; TechCrunch.com and ReadWriteWeb.com (RWW). They both provide balanced coverage of the consumer and enterprise markets while remaining objective. You don't get the sense that site sponsors and advertisers are driving the stories. I admire their integrity.

I was elated to learn a few days before the hackathon that Chatter Bot had been selected as a finalist and I was strongly encouraged to attend. So I packed up Chatter Bot to take the 2 hour flight from Portland to San Jose.

It wasn't until I arrived at the airport that it suddenly dawned on me how much Chatter Bot bares a striking resemblance to a poorly assembled explosive device. Apparently the TSA agent handling the X-Ray machine thought so too and I was taken aside for the full bomb sniffing and search routine.

It crossed my mind to add a bit levity to the situation by making some kind of remark, but I quickly assessed that I was probably one misinterpreted comment away from being whisked off in handcuffs to some TSA lockup room. Ironically, I had no problem with security in San Jose coming back. They must be accustomed to these types of devices in Silicon Valley.

Upon arriving in San Jose, I setup Chatter Bot and configured the San Jose Convention Center (SJCC) as a Building Facility (Custom object) to be monitored.

Several assets were created to represent some rooms within the SJCC.

Finally, the Chatter Bot was associated with a particular room (Asset) through an intersection object called AssetSensors that relates a device ID (usually a MAC address) and an Asset.

Within minutes the motion and light sensors were communicating to the cloud via my laptop and reporting on activity in the Hackathon room.

Given the high quality and functionality of fellow competitors apps, such as the very cool Chatter for Android app by Jeff Douglas, and observations from the public voting, I thought Chatter Bot might be a little too "out of the box" to take a prize. It was a genuinely surreal and surprising moment when I learned Chatter Bot received the grand prize.

Thank you Salesforce for hosting such a great event and thank you to the coop-etition for the encouraging exchange of ideas and feedback during the challenge!

Jazz - A Software Development Methodology

WhatJazz is a software development methodology for the ongoing creation and improvisation around several small apps distributed on open Internet platforms (the "cloud").

WhyContemporary tools, languages, and distribution platforms of the 21st century make it feasible for software to be created, delivered, and performed similarly to Jazz music of the 20th century.

Software, like music, may be consumed repeatedly throughout the day by audiences.

Software has become ubiquitous and essential to people's everyday lives.

Audiences increasingly are demanding to know more about the personalities and teams behind their favorite software applications.

What (Apps)Jazz combos seek to build a repertoire of several small apps, as opposed to developing and supporting one large app. Jazz is most suitable for Developers distributing applications through online stores (such as the Apple App Store, Google Marketplace, or Salesforce AppExchange).

The repertoire should consist of at least 10 apps.

Not all apps are for commercial distribution (such as contributions to open source frameworks and proof of concept apps used for marketing purposes).

Only 1 in 10 apps within the repertoire will achieve any significant amount of notoriety or market adoption.

Who (The Combo)Apps are initially composed by a single person, which are then rehearsed and performed by combos of up to 5-7 people. Apps are occasionally composed by 2 collaborators.

Apps are consumed by audiences (customers).

Where (Spaces)Jazz is composed, rehearsed, and performed in 3 distinct "spaces".

Composition and practice are done in solitude (home, coffee shop, the beach) but always connected (anywhere with Internet access)

Rehearsals are done with a group about once per week in public meeting places

Performances are ongoing. They occur both virtually and physically. All audience interactions are performances (this includes app store listings, webinars, support, and customizations)

WhenJazz is not a 9 to 5 job. However, ongoing performances are typically supported by someone during working hours.

Jazz Developers dedicate at least 3 days per week to uninterrupted work (composition and improvisation) and at least 1 day for group rehearsals (meetings) and audience interactions (support and review of customer feedback).

Compositions may take 1 day or 1 year to write. It should take no more than 2 years to accumulate a repertoire of 10 apps.

Team members are often given "the floor" during performances to lead and improvise within a composition. Improvisations are short creative cycles within the overall structure of a composition.

HowEach member of a Jazz combo owns and maintains their own instruments (tools) that best support their function within the combo.

Academic mastery of instrument and language are assumed before confidence in composition and improvisation can be achieved.

Jazz combos are unified in language presented to audiences, but individually use languages specific to their instrument or function.

Jazz encourages the sharing, remixing, and reuse of ideas through use of creative commons licenses.

All individuals are given public recognition for their contribution to an app.

Performers may practice up to 10 hours for a 1 hour performance (10:1 ratio of effort, unit tests behind released products).

The best performances are achieved through mastery of instrument, confidence in skills, and relaxation of mind.

The result is more important than the means. Don't over think the process to achieving a good performance.

Improvisations often rely on audience feedback to determine the path of a performance.

The Jazz combo may dynamically adjust composition structure during a performance through subtle communication to support an improvisation that may lead to new discoveries or increased levels of audience feedback and participation.

A true REST interface with full support for HTTP Verbs, status codes, and URIs is currently not available on the Salesforce.com platform. However, a simple REST-like interface for getting objects can be developed using Salesforce Sites, Visualforce, and Apex.

This example uses a free Developer Edition with a Site named 'api' that uses only 2 Visualforce pages named 'rest' and 'error'. The rest page accepts a single parameter named 'soql', executes the SOQL query, and returns a JSON formatted response.

The error page is also used to generically handle all 40x and 50x errors.

The body of the error page returns a simple JSON message that the api is unavailable.

Note that the rest page is defined as the default handler for the site named 'api', so it's not required in the URL.
This simple interface supports any flavor of SOQL, including the WHERE and LIMIT keywords, so you can pass queries like

select Id, FirstName, LastName from Lead where LastName='Smith' limit 20

REST interfaces often assume the unique ID of an object is the last portion of the URL request. This can similarly be achieved with a query like (example here)

select Id, FirstName, LastName from Lead where Id='00QA00000019xkpMAA' limit 1

All of these example queries will only return the Id field by default. To fix this, update the Sites Public Access Settings and grant Read access to the Lead object.

The new URL rewriting feature in Summer 10 provides some additional options the necessary means to implementing a RESTful interface with full support for object URIs and linking.