We are happy to announce that Mike Gerholdt is joining Red Argyle as Director of Client Engagement!

Mike Gerholdt is the founder of ButtonClickAdmin.com, which is one of the top Salesforce blogs (and now, podcast!).  As one of the inaugural members to the Salesforce MVP Program, his dedication to the community has been recognized since 2010.  His former tenure included managing a 350 seat implementation over 6 years, growing adoption by 1200%.  

As Red Argyle has grown, we have the desire to build a new practice. We were in need of someone who can be focused on ensuring the continued success and adoption of projects.  This success management is what Mike is going to bring to the table.  Between crafting world class training, adoption plans, and coaching stakeholder groups to maximize their Salesforce experience, Mike will be ensuring that the long term success of a project is attained and measured.  A project is much more than a build and a go-live.  The magic happens months after go-live, and we’re going to make sure our customers get the benefit of this.

In addition to project and client involvement, we’re excited to begin our quest to make Red Argyle’s blog truly world class.  Between Mike’s astuteness, consistency, and creativity, we can’t wait to have his insights contributing to our blog.  You can be sure that we’ll be bringing some great content to the table both from Mike and also the rest of our talented team.

This truly is an exciting announcement for us to make and a very exciting time for Red Argyle, our customers, and the Salesforce community.  We are committed to being the best, and one step to getting us there is to have the best people on our team.  Please join me in welcoming Mike, and let’s go get AWESOME!

Having worked with Salesforce since 2008,  there's always been the gap that Salesforce didn't do email marketing.  The good side was that there were a host of options to manage it, the bad side was that reviewing the host, making a selection, and implementing was tougher than a first party email marketing approach.

Another big missing piece was lead automation & drip campaigns.  We've done some amazing things with workflow rules & creative criteria & time triggers but you can only take that so far before needing a more robust system.

In mid 2012, Red Argyle became an ExactTarget partner.  We always liked ExactTarget's data model and deep integration with Salesforce.  It actually used Salesforce data instead of hosting its own external database.  In late 2012 ExactTarget acquired Pardot, a lead automation & email marketing company.  Pardot brought some nice perks and helped round out ExactTarget's suite of offerings.

And then today (a whopping 6 months later...), Salesforce is buying the whole shebang.  So looking forward, this opens up a a few exciting avenues (Safe Harbor, Safe Harbor, etc. etc.)

• The acquisition will help position Salesforce to compete with their rivals who also recently made email marketing acquisitions.
• The Pardot/ExactTarget offering brings a LOT of features to the table which are a great fit into the Salesforce CRM offering.  There's not to much overlap here, Salesforce has a space carved out within their functionality.
• Coupling the power of ExactTarget with the magic of the Marketing Cloud, I can foresee some amazing analytics that go far beyond anything available today.  More than just email analytics, but true, 360 degree campaign management across all Social Media properties.
• Implementing ExactTarget is about to get a whole lot easier.  With the application being first party implementing ExactTarget in the future may be as easy as checking a few boxes and you're off to the races.
• I don't expect any immediate changes, enhancements will begin rolling out over the course of the next several releases.

So what do you think?  Any predictions?  Excited about this play?

After doing some research we decided to use a continuous integration setup. We are using Jenkins hosted on an Amazon EC2 instance and we’re using Git as a central repository that each developer pushes their code to. The goal is to have each developer working in their own isolated environment and pushing their changes, when they are completed and tested, into the repository which then sends the changes into a client facing sandbox. Once a developer pushes their changes to the repo, the other developers can then pull down the new changes and apply them to their org. Adding a Git repo helps us to merge changes that have happened to the same file and adds some much needed versioning to the code behind our applications.

Server Setup
While looking for information on how to setup Jenkins on EC2 I came across an AMI (Amazon managed image) that Bracket Labs had put together that includes Jenkins and the Force.com Migration tool. The AMI is can be downloaded from here. Click the Amazon Web Services logo which will launch your EC2 instance wizard. Now you’ll need to walk through the steps to setup your server. I left everything at its default except when it came to the Key Pairing step. Key Pairing is basically a password file that you will need to connect to your instance. If you need help setting up a Key Pair check out the User Guide. Select or create a Key Pair for this instance. On the next page, select an existing security group or create a new one. I recommend creating rules for SSH(port 22), HTTP(port 80), HTTPS(port 443) and FTP(port 21). Finish up by clicking continue, reviewing your settings and clicking launch.

The Bracket Labs AMI is hosted on the US West (N. California) Region, which is great if you are from that area. Red Argyle is an east coast company so hosting the server on the west coast might add a bit of lag to our requests. No worries, EC2 instances can be moved using CloudyScripts free tool. Make sure you create temporary AWS Access Keys and Key Pairs for this activity and delete them when you are done.

Your instance now lives at an assigned url, Public DNS. But in order to get your server connected to your sandbox org down the line you should assign it an IP address so you can add it to you org’s network access settings. Towards the bottom of the left side bar is the link to manage Elastic IPs. Allocate a new address and associate it to your instance. 

You can now connect to Jenkins by going to the IP address of your instance on port :8080. It should look something like

http://192.168.0.0:8080

The AMI you have installed will already have a few jobs setup. Take a look at how they're configured, and also check out Bracket Labs’ git repo for their DreamForce Team Development presentation. So far you have enough to get you started. I’ll post again soon with more details on how we expanded on this setup to meet our development needs.

References
Brack Labs Team Delevlopment Demo
Bracket Labs Jenkins AMI
CloudyScripts Instance Migration Tool 
Helpful blog post
Team Development on Force.com with Github and Ant - A Red Argyle DF12 Presentation

Update: It looks like other folks have identified and are discussing some similar issues in this Force.com community thread.

There’s some moving parts here, so let’s set up a scenario. First, we have a Visualforce page which uses a standard controller (in this case, the Account object). This VF page references a Visualforce Component that exposes a “recordId” attribute. Basically, we’re passing the SFID of the record this VF page references down to the VF component:

The guts of the VF component looks like this:

The MyComponentController controller for the VF component looks like this:

Prior to Summer ‘13, this worked without any issues. However, after the release, we started getting low-level Salesforce “unexpected errors” when the recordId.getSObjectType() method was called.

It seems that, in Summer ‘13, Visualforce components are not correctly passing a Salesforce Id as a true Id data type. My best guess is it’s actually passing it as a String. Since getSObjectType() is not a method on the String data type, I think that’s where the unexpected Salesforce error kicks in.

To workaround this, we changed the recordId property in MyComponentController from an Id to a String data type. Next, we added a new property called recordSFID with a data type of Id, which we populate by casting recordId to an Id data type. Finally, we swapped our reference in the sot getting from recordId to recordSFID.

Final code is below:

Visualforce Page (no change here):

Visualforce Component (changes commented):

MyComponentController Apex Controller (changes commented):

Late in 2012, I was asked to post to the Salesforce community blog.  I wrote this article:

http://blogs.salesforce.com/company/2012/12/5-fields-every-salesforce-instance-should-have.html

As it turns out, I got some feedback, folks thought I was on to something.  They asked me "Hey, can I get the 5 fields?".  So, I did the thing any Salesforce ISV partner would do, I turned it onto an application!

So here it is, hereby dubbed "High Five!", THE 5 fields every Salesforce instance should have, along with a few bonus reports, FREE and ready for installation:

https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3GloEAF

I love how we were able to take an idea, "Appify it", and get it posted to share with the world in a very short period of time.  Sure, it's a simple application, but simple or complex, the process is the same.  Idea to market quick and not having to build the infrastructure!

If you install the application, I'd love to hear your feedback or if I can make any enhancements.  Have at it!

The post sucked.  Maybe my nicely crafted bullet points with a situation and takeaway seemed like a good idea at the time, but reading back into it, I sadly realized… “this is crap”.

It was a good movie, just probably not good blog/mashup material.  So maybe the lesson from this whole exercise isn’t about how winning sword fights can also help you win at business, but how we shouldn’t be afriad to abandon something that’s no good.

I spent two hours writing that blog post.  I knew it was no good and considered publishing it.   And didn’t.  Have you ever been tempted to launch something that was not good simply because you spent time on it?  Is your company carrying around business processes because someone spent time on them?

Time to get ruthless!  Not “I’m going to be rude and hurt people’s feelings” ruthless, but being “honest with yourself” ruthless.  If you know something is crap, admit it and determine how to decrapify it or get rid of it.  That’s what Rob Roy MacGregor would have done.

So 10 years ago today, I graduated from college.  Maybe I’m feeling a little bit wistful, 10 years is kind of a big deal, or maybe it’s because I’m going to be a Dad in a few short weeks.  I was thinking the other day, what if I could teleport back to my 10-years-ago-self and give my former self a pep talk.  What would I say?

On that fateful day 10 years ago

First I’d give myself a disclaimer and say “Hey self, you think you’re way smarter than you are and you’re probably not going to listen to me.  But that’s okay because truthfully, the only way you’ll learn this stuff is to mess it up anyways.”

Then I’d go on to give my former self some pointers of what I did learn over the years...

• Don’t dress for the job you have, don’t dress for the job you want, but dress to be yourself.  However, looking dapper does not hurt.
• Don’t be worried that you got a degree that’s not business oriented.  Revel in it.  You’ve just learned a set of skills that are applicable in any business.  Problem solving?  Check.  Public speaking? Check.  It’s not what your degree is in, but what you choose to do with it that matters.
• Tattoos hurt a lot less than you think.
• Keep on taking the long view.  It makes failures seem that much smaller and successes feel more like a stepping stone than the destination.
• Speaking of failure, buckle up, because you’re going to have a lot of those!
• Don’t ever stop loving Volkswagens.  And (hint, hint), you’re going to build one of the best of them.  You’ll succeed because you stuck to it and didn’t give up.
• Spend as much time as you can with your family, it’ll be the best times that you remember.
• Don’t ever quit playing music.
• Growing up sucks so resist with all your power!  Keep that child-like interest, it will serve you well.
• Stay tuned, because in a year P90X will be invented.  Buy it and never stop doing it.  Sometimes you’ll fall off the wagon but keep on getting back on, you won’t regret it, not ever.
• You’ll catch the biggest fish by spending more time with your pole in the water.  Every cast you create an opportunity.  This works for fishing and life in general.  Keep trying to create opportunities.
• It’s okay if you say “Awesome” a lot.  Just make sure that you are doing something awesome.
• Speed is motion.  Velocity is motion with a direction.  Think velocity, not speed.  Pick a direction and keep moving foreward.
• Keep on having a good time, no matter what.  You have one life, live it dude!

Still smiling today!

I’m sure I’d be tempted to tell my former self to invest in Salesforce.com, get a job in the cloud technology and make sure I go to the first Dreamforce, but I’d be a little worried about creating a fold in the space-time continuum which would probably destroy the universe. 

Question for you - what advice would you give 10-years-younger self if you could talk to them right now?  Feel free to leave a comment with your pointers!  Thanks for reading.  -Garry

During Pat’s presentation, he described mobile development approaches using the Salesforce Mobile SDK in three flavors:

1. HTML5 - web apps built with a mobile-friendly (aka responsive) design in mind.
2. Hybrid - HTML5 apps (see previous bullet) enhanced with a simple Native wrapper (see next bullet), allowing developers to access some hardware on the device (camera, voice, etc)
3. Native - apps built using the iOS or Android mobile platforms, allowing developers to access all hardware on the device beyond the “wrapper” mentioned above.

Clearly, the level of sophistication of an app increases as you read down the bullets. The tradeoff? So does the level of complexity to develop them.

I would recommend that any Force.com developer building a mobile app to “go hybrid”. Force.com devs already have the skills to build an HTML5 app quickly, and the wrapper needed to go from HTML5 to a Hybrid app is a weekend project away for any nerd that can’t seem to get their fix of code during the workweek (read: all of us).

Also, Force.com developers typically build business apps. A mobile app will likely plug a specific hole for your company. It would benefit from a device-specific user interface and some streamlined functions, but it probably won’t benefit from a graphics accelerator or a multicore processor that native development may afford. While an “Angry Birds : Salesforce Edition” sounds intriguing (and I’ll let you all decide which Salesforce executive aligns with which bird), “Lead Closer 9000 Extreme Edition” is probably closer to our development reality.

Finally (and at risk of showing of my development ineptitude), native development is hard! I’ve picked up XCode three or four times, only to put it back down in a huff, grumbling to myself “Objective-C makes me feel stupid”! No doubt, there are developers who would laugh at this, but to hark back to my previous point, if you don’t need the sophistication of a native app, you don’t need the complexity of developing it.

Save time. Save money. Go faster. Go hybrid.

Now, throw tomatoes (or angry birds) at me in the comments.

However, one challenge we had in the past was aligning Google Docs, project websites (like Basecamp) and other apps with related assets that are stored in Dropbox. The old-school-yet-effective solution: bookmarks in a folder.

Here's how we do it:

1. Open the Dropbox folder on your machine (we organize our Dropbox folders to align with projects):

2. Navigate in your browser to the page / app / Google Doc you want to track alongside your Dropbox assets:

3. Click and drag the web page icon into your Dropbox folder:

4. Bask in the lo-fidelity organizational glory!

When you do this on a Mac, you will get a ".webloc" file in Dropbox. Double-clicking the file will open a browser and take you to the corresponding page (again, you can do this for anything that has a URL - Google Doc, web app, etc). The file will also sync to everyone else you've shared the Dropbox folder with, keeping your project team in sync and (hopefully) helping to end the "hey where did that thing go?" conversation.

We're all Mac-folk here at Red Argyle, but I'm not sure if that same file format will work on a PC. If not, I suspect a similar format would result if you followed this same process.

Simply put, Heroku is a platform for building, deploying and managing applications. It is probably best described by comparing it to how we used to develop, deploy and support apps in the days before Heroku.

Before Heroku

1. Build an app.
2. Find a server. Hope that the server is reliable. Hope that the server is configured in such a way that our app will actually run on it.
3. Figure out how to get the code for the app on the server. Forget FTP credentials. Call tech support.
4. Figure out where to put the database that the app needs to store all the data. This often means repeating step 1.
5. Deploy the app. Use the hope-and-pray method of performance monitoring.
6. Determine that, based on said hope-and-pray method, that there is a performance issue. Somewhere. Maybe with the web server. Maybe with the database server. Maybe the connection between them. Maybe with something else that we don't understand.
7. Endure occasional panic-stricken cold sweats and sleepless nights.

With Heroku

1. Build an app.
2. Check a box to enable a database.
3. Check a box to enable performance monitoring.
4. Deploy the app.
5. Watch the logs from the monitoring app.
6. Push buttons to increase performance throughput.
7. No sweating. Nights are for sleeping.

As you might expect, we prefer the latter. Heroku eliminates all the tasks that have nothing to do with building an app, allowing us to focus on what's important: the app itself.

It's this freedom that's allowing us to dive into much more challenging and exciting projects than we would have in the past. No matter the language, integration points, scale or complexity, Heroku has our back.

That's why we became a Heroku Partner - we firmly believe in Heroku's capabilities and direction, and have committed to running all of our applications on the platform.