Thoughts worth sharing

The gang at Atlassian did really well with their Summit. I anticipate that their Summit audience numbers will only grow over time. It was great to meet their customers, and those in their commercial ecosystem.

The combination of using Google Apps for email and Salesforce.com for CRM is all too common. We’ve been using both products for years but the integration of the two products over that time has been sadly lacking.

As a Force.com developer I have always wanted a chance to become proficient at using these tools myself (VIM in particular), and before long I found myself looking into ways this might be possible.

Salesforce.com today released Do.com, a simple project management tool, into public beta. Do.com is the result of an acquisition that Salesforce.com made a few months back when they acquired Manymoon.com.

In my previous post I explained how Javascript remoting can be used in Force.com to provide fast, asynchronous communication between client & server. This time I will explain how it works at more of a technical level.

The term ‘private cloud’ has been used a lot in the last year or so. Some say the private cloud doesn’t exist but in most cases the term is being used to simply relabel the status quo. So does private cloud really exist? YES!

Continuing on this summary for Day 2. We started with Real Time Rack by Konstantin Haase, followed by Implementing Rails 3.1, Backbone.js, CoffeeScript, jQuery, Sass, and CouchDB on EC2 by Rod Cope.

This summary of Rocky Mountain Ruby is not exhaustive, not complete, but includes a few notes about what stuck in my mind. We started with Focus by Mike Gerhard. Find focus. Right/rich brain, left/linear brain.

I am really passionate about creating user interfaces that are clean, simple, and intuitive to use. With the addition of a new exciting tool I have been able to deliver Force.com web applications with a much better user experience.

When deploying a Rails web application that connects to the Salesforce.com API on the Heroku platform, one ideally wants to achieve a few things. First: not deviating from the standard Heroku deployment process.

Continuing from my previous post about agile development in the corporate context, I will point out the ways in which the team was structured and backed financially – in the context of the goals that were set for us.

Continuing from my previous post about agile development in the corporate context, I will describe the technology we used to be able to rapidly deliver web applications. We needed some basic structures in place.