In an effort to try to reduce the amount of code in our base repository we’ve been looking at writing managed packages that we install in our production org and then delegate the development and maintenance of these packages off to other teams. Being a Open Source company we also want to try to offer what work we’ve done to other people. However, not everything we want this package to do is useful outside of our business. To solve this, we’re releasing the base package and then creating a private child package to hold most of our business logic and custom fields.
So it’s been a week since the end of Dreamforce 2016 and I’ve had some time to soak in what was talked about. This year my task for Dreamforce was to go and get some pretty specific answers. So, instead of talking about everything that happened at Dreamforce and what I think about it, I’m going to talk about the three things I was tasked with looking into.
With the recent updates to the licensing model at Salesforce, lots of companies now get Live Agent licenses included. Because of this I’m working on a hands-on training for how to setup Live Agent and use it in Service Console. As you could guess, this isn’t an quick thing to do so I’m splitting it up into parts.
One of the hardest parts of Live Agent to test out for non-developers is the actual web front end part. If write the HTML locally and then you can test it but others can’t. To make it so others can test it, you either have to set up a web server or figure out how to deploy it to a cloud provider such as Heroku or Openshift. And that can be pretty daunting for someone that’s just trying to setup a proof of concept or is just working on the configuration side and will pass it off to someone else from their web team.
What does the quickstart provide?
The Live Agent quickstart I wrote provides a super fast way to deploy a Live Agent button to Heroku. Once you have set up Live Agent, you can copy and paste parts of the configuration into the first screen of the Heroku app setup and then click deploy. After a couple of minutes you have a website that anyone can goto and interact with your chat button!
Similar to the entitlement process hands on training, I’ll be publishing it to github for everyone to use (and fork if desired). It’s going to take some time since it’s a lot of brand new content but I’m hoping to have it done before the end of the year. So, follow here and at the github repo to keep informed of it’s progress.
By this point, you’ve no doubt read plenty of articles about what to bring to Dreamforce and how to prepare. If you’ve not had the chance yet, do yourself a favor and checkout the Dreamforce Trailhead module. But that’s not what I’m here to talk about. I want to talk about things you shouldn’t bring to Dreamforce, specifically things that I have brought in the past. So, let’s learn from my mistakes!
If this upcoming Dreamforce is your first, buckle up! it’s a wild ride. 2016 will be my 5th Dreamforce and I’ve brought a bunch of things over the years thinking I would need them and ended up not using them at all (or barely).
What Not to Bring
- Entertainment devices – This is a pretty big category so lemme break it down. Over the years I’ve brought things like card / board games, gameboy, PSP, extra movies, etc. All with the intention of using them in my “downtime,” and let me tell you, there is no downtime. Now if you have a long flight, by all means bring stuff with you to keep you entertained. But don’t bring it thinking you’ll find time to use it. There is so much to do at Dreamforce that you’ll barely have time to sleep. You’d be better off spending that time catching up on your sleep or meeting new people (or catching up with old friends).
- Work – Now hear me out. I know there are lots of solo admins, senior team members, CEO, CTO, etc coming to Dreamforce and it’s tough to leave work at work. Try. You’ll be better off if you focus on the talks being given, the hands on training or the networking than half paying attention while trying to do work. If you have to do work, try to set expectations that you’ll do it in the morning or the evening before the conference kicks off.
- Computers – Well, this one is a bit of a “clickbaity” bullet point. When you’re in attending a talk, shut the computer. Bring some paper if you want to take notes but for the most part, just pay attention. The slides will be provided after the talk so there’s no need to copy down every word that’s been said. You’ll absorb more of the talk if you’re giving it your full attention. Now there are plenty of places you’ll want to have your computer, such as the mini-hacks, so bring it. Just don’t use it all the time.
- All your camera gear – This one pains me to say more than any. I’m a photographer and love to use my camera. But unless I’m have planning to go somewhere like a tour or on a photo walk I found that I just carrying around a bunch of heavy lenses. If you want to bring your real camera, go minimal. This year I’ll just be bringing my D90 and my 50mm lens. Not only will it lighten up my bag, but it will force me to be creative with my work since I can’t just changes lenses.
- Your conference badge – Yes, you do need to bring it with you when you’re trying to enter any of the conference buildings. But you don’t need to be wearing it when you’re out to dinner with your team. And you don’t need to be wearing it when you’re walking around at Union Square. San Francisco is a pretty safe city, but it’s a big city. And like any big city your ultimate goal should be to not make yourself an obvious target. For some interesting reading look at things on the gray man theory*
- Preconceptions – Every Dreamforce is different and every person experiences it differently. So, take everything in the article (and every other article you’ve read) with a grain of salt. Do your Dreamforce your way and don’t succumb to peer pressure. Oh, and check your biases at the door too.
What to Bring
Yeah, I know, this is suppose to be what not to bring. But there are a couple of things that I have to list that I have found get left off of most lists.
- A jacket – I live in a state that is in a constant state of being so humid it should rain but not actually raining. A state where simply the act of walking from your front door to your car can end up with you being drenched in sweat. San Francisco is not in my state. It can get pretty chilly during Dreamforce at night, especially down near the water. Do like your mother told you and bring a light jacket. If you forget, there are typically lots of ways to win a hoodie at Dreamforce.
- An envelope – One of the first things I do when I check into my hotel room is to ask the front desk for a couple of envelopes. I use these throughout the conference to store receipts in and to store business cards. This keeps all of my paperwork organized so when I get home I don’t have to check through 30 different pockets to find a receipt for my expense report.
- An extra bag – Most likely, you’re going to end up with a bunch of extra swag (which is not an acronym for Stuff We All Get). In previous years, I’ve relied on the conference bag to be big enough to hold anything extra. Last year all of my bags were bursting at the seams so I decided to pick up a collapsible duffel bag. I’ll fly out with just carry-on bags, fill up the duffel bag and then check a bag on my way back. Check out David’s great article on how to get swag at Dreamforce.
* Just a quick note. Most of the stuff on gray man theory comes from “survivalist” or “tactical” sites. The concepts behind these are useful but some of it can be a little too tin-foil hat for me. I’d also recommend the first chapter of the Handbook of Practical Spying.
There are many stories like this, but this one is mine. I was born in North Carolina… wait, that’s probably too far back.
Becoming a Code Monkey
Since an early age, I’ve known that I’ve wanted to be a programmer. I use to “design” web pages on Angelfire and dabble in BASIC back in middle school. Looking back now, it wasn’t anything special but it was the catalyst that would carry me into some of my high school classes and eventually on to my degree in computer science from North Carolina State University (go Wolfpack!). Continue reading
As part of my managed package crusade I decided I should delve into the world of Visualforce from a managed package. While pure Visualforce is going to be in my package that’s not nearly as interesting as packaging and using namespaced components as part of the package. So let’s take a look at how we can use a namespaced component.
The component that I created in my packaging org is simple. The Visualforce page provides an account Id and the component lists out each of the account’s cases. This component isn’t going to win any awards for originality, but it will serve it’s purpose.
Recently I’ve been working more with managed packages and I knew that I’d be writing REST interfaces inside that package. However I had no clue how namespaced REST interfaces would be presented or how you accessed them. I was afraid that there could be conflicts. For example if the package exposed /lastcase and the customer’s org had /lastcase how would they play together. I’m very happy to announce that the folks at Salesfore are on the ball and the platform handles it wonderfully.
This weeks post is going to be another off topic one. I’ve been traveling more recently and I wanted to share the gear I use and what I like (and don’t like about) them.
Base Travel Gear
Regardless of the type of trip I’m taking, these items always come with me
I struggled for a long time to find the right suitcase. When looking for it my criteria was that I wanted a rolling suitcase that would fit in the overhead. This is a really wide category and there are hundreds that fit into this category. So I started looking at companies that I’ve use their gear before and the Osprey Merdian 22 caught my eye. It’s got some great features such as a disconnect-able backpack and straps that convert it to a backpack from a roller bag.
In Spring ’15 Salesforce released a feature called “Quick Deploy” that allows you to only run a small subset of tests when you do your deployment instead of running all the tests. When you’re in an org like ours that running all tests can take upwards of 5hrs (or longer if the moon is aligned incorrectly) this is wonderful. Let’s take a look at how quick deploy works and how you can use quick deploy with Solenopsis.
How Quick Deploy Works
Quick deploy simply runs a provided list of tests when you run your deployment. This deployment is then staged under your Deployment Status in setup. Once the all the tests have run you’ll get a button that let’s you quick deploy.
Now that I’m starting to spend time playing with packaging code for use I decided to dig into how access modifiers affect visibility of methods and classes inside of managed packages.
Visibility Access Modifiers
Before we get started, let’s review what options we have for defining visibility in Apex
private – Methods, classes and variables marked as private are only visible inside the same class. If you define something as private then it cannot be accessed from an external class
public – Things that are marked as public are available for use by anything in the same namespace.
global – Things marked as global are available for use by anything on the platform.
Typically, public and private are enough for most implementations since your code resides inside the same namespace. When writing code to be used by others from your managed package you’ll want to make it global.