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.
Posted in Off Topic
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.
If you’ve been working with Salesforce for a while or you’re a larger company you’ll eventually want to get data out of Salesforce and into another system. So let’s take some time to break down the options that are available for getting data out of Salesforce in varying degrees of realtime.
One of the cool new features in Summer ’16 is the ability to take a built in (or custom) address and automatically get that addresses latitude and longitude with SOQL (Read More). So took this as an opportunity to learn some more about it as well as some other mapping technologies. So for this my goal was to be able to create a heatmap of all the contact’s location under an account and place this on the account page.
This week is going to be just a social update on a couple of projects that I’m working on. I’ve got plans for a big neat post next week.
Me Code Pretty One Day…
I was hoping to present this at Dreamforce this year but it doesn’t look like that’s going to happen. So instead I’ll just talk briefly about it here
Apex Styleguide – Link – I’ve been asked several times what our team does for it’s code style and I’ve been working on an online style guide. It’s really a work in progress and will probably pivot a bit once Apex Checkstyle is complete. Right now all the rules are enforced by regexes and it doesn’t scale well and has a lot of false positives. If you want to create your own styleguide, feel free to fork the project. I’ll add build instructions for the site soon to make this easier.
Apex Checkstyle – Link – This has been something that’s been in the works for a while. Initially I tried to just make an extension to Checkstyle but there was just too many problems with that. So instead I completely forked Checkstyle and modified the grammar to help support Apex. While the project builds and it works on some very simple Apex code, it’s nowhere near ready for the big time. I’m going to keep working on it and hopefully someday soon it’ll be ready.
Escalations – Link – Another project still very much in it’s infancy. The idea behind this is to make an easy way for support centers to track escalations to cases. The plan is to have this both as a managed package as well as having the source available if you want to install it as unmanaged code.
SalesforceApps – Link – This is just a repo for random code that I’ve worked on that others may find useful. Right now I think the most useful bits are under the node_scripts directory.
Hands On Training – Link – Training is in my blood and it’s something I’ve always loved doing. You should checkout my hands on training. I have plans to migrate some others over to it as well as writing a couple more. You can follow the project if you want to be notified of updates.