Archive for July, 2011

July 29, 2011

Am I your type?

Welcome back to Week Four of “Learning to Speak Like A Developer (Or at least Fake It at Dreamforce).”  If you’ve been here for the past three weeks, you are well on your way already! If not, go read those other three posts & catch up. Today’s post is a bit different, because it’s not strictly a vocabulary lesson. There’s a bit more ‘meat’ to it, so strap in!

In Apex, all variables and expressions have a data type. I’ve got a bit of a surprise for you. Unbeknownst to you, I’ve taught you two data types already! So far, you’ve learned about sObjects and objects. Hopefully, you’ve got those two down, so let’s talk about the rest.

  • Primitives – This is probably the type that you are most familiar with. If you think in terms of Salesforce, you can almost imagine these as some of the field types you can create – boolean (checkbox), integer or decimal (number), date, ID, string (text).
  • Collections – Just like they sound, groupings of elements. These elements can be sObjects, objects, primitives of other collections. They can be a set – an unordered grouping with no repetition of elements. They could also be a list, which is an ordered grouping of elements. They can also be a map, which is where a unique key will map over a value.
  • Enum – The best way to explain these are that they are a hard-coded set of values. They are used to define a set that has no particular order of the values within it.
  • Null – This one is pretty self-explanatory.

So there you have it – data types in Apex. If all (or even some) of this is making sense, you are already on the path to becoming a developer. And for now, you can fake it & impress 70% of the people at Dreamforce. And seriously, if you haven’t registered yet, what the heck are you waiting for? Just register, come see me speak about my journey from clicks to code & maybe get some free swag from yours truly!

Speaking of swag — what’s your favorite thing to get at a tradeshow? Favorite big item (think electronics), or favorite little item (think bling or something to give the kiddos)? I’ve got some things cooking, but I’d love to hear from my readers!


July 22, 2011

Method to the Madness

Hey, look at that – you are back for Week #3! Fantastic – let’s keep this Dev-speak train right on rolling.

Hopefully you have somewhat of an idea of what classes are (object factories), so  now we can start talking about the two things that make up classes: attributes and methods (hence the title of the post — sorry, best I could come up with).

These are actually pretty simple. To oversimplify, attributes are the nouns and methods are the verbs. What I mean by that is that the attributes tell you about the characteristic of the object you are creating, and the method tells you what that object can do.

Let’s use a car as an analogy (mostly because the first thing I think of when I think ‘factory’ is a car). So if we have a car class (car factory), some of the attributes we will have to each car object are the color, number of doors, size of the wheels, and so on. Some of the methods we’d have to give would be things like drive, park, reverse, comfort, transport.

So, now that you know all that, go instantiate this Bugatti Veyron object and give it to me as a thank you.

We are now at 38 days (and 5 more posts) until Dreamforce. Besides gearing up on your dev lingo, what are you doing to prepare for the greatest conference of all time?

July 15, 2011

Triggers, classes, instantiation – Oh My!

There are now only 45 days until Dreamforce & I promised to share enough so that you could sneak your way into the Hackathon (or if that’s not your thing, just impress new people that you talk to), so let’s jump right in!

trigger is a chunk of code that does things (vague, I know). They look at a specific object, and can perform actions based on criteria set around that object. You can design them to run either before or after a insert, update or delete to that object in Salesforce.
I think of classes as the object factory – it’s what makes your objects. You could also think of is as the blueprint for your object (this is the analogy that is used in the DEV 531 class) – it defines what the object is & the actions that object can do. Taking this back to the Salesforce world, think of it as the fields on your sObject & what that sObject can do.

Finally, instantiation (try saying it – it’s fun & you’ll feel really smart) is when you fire up that object factory & say “Go!” It is simply the act of creating an object from a class. I like this one the most only because I feel smart using it.

Thanks for reading! I hope my vocab series is useful & please provide feedback so that I can tune this up for the upcoming posts. See you next week, or join me over on Facebook!

July 8, 2011

Say what now?!


[lang-gwij] noun; a body of words and the systems for their use

One of the thing I struggled (and still struggle) with is all the new lingo that comes with the developer territory. It makes perfect sense that they referring to it as programming ‘language’ because that’s exactly what it is. There are new words, new rules & new syntax to learn. And poor old me, I’ve never been good with foreign languages.

I struggle with how best to share what I’ve learned, as I am still learning & am by no means an expert. I started to write up a cheat sheet for this post & realized it was more confusing than helpful. Then I came up with the idea of breaking it down even further than a cheat sheet, and making a series of posts dedicated to learning the lingo. Today I thought I start simple:

sObjects vs Objects

sObjects are what the Button-Click Admin thinks of when someone says objects in reference to Salesforce. They are all the standard & custom ‘things’ in Salesforce. To get a bit more technical, they are database constructs that store data.

Objects, on the other hand, are what people are talking about when they say ‘object-oriented programming.’ In contrast to sObjects, Objects are coding constructs. It get’s a bit hairy in that Objects can represent sObjects, but not the other way around. The best way I can describe it are the do-ers of the code work.

Stay tuned! In the following weeks, we’ll help you learn to talk the talk! You’ll be dev-speaking by Dreamforce! (Only 52 days to go…are you registered yet?)

July 1, 2011

Lace up your boots!

The journey from button-clicker to uber-coder is all about the baby steps. For me, the challenge seemed insurmountable. And when I went to seek advice, most of the answers I got were the same – “Check out the Cookbook.”  “Go to the developer site & look at the stuff in the code share.” And while I’m sure that’s great advice for coders who need to learn APEX, it’s still all looked like gibberish to me.

I resigned to the idea that I had gone as far as I could go.

Obviously, seeing where I am today, that wasn’t true. Now, I’m not going to say that I’ve got all the right answers, or that I did it the best way, but for me, the first step was an easy one (and not easy like ‘just go write a trigger & see how it goes’, it was actually easy) — I got a developer account.

I know what some of you are thinking – “As a button-click admin, I already have one of those.” Well, I didn’t, and I’m betting I’m not the only one. Sure, I had heard of them, but I wasn’t a developer, so what did I need one for? Duh! To become of a developer.

So here’s the quick 411 on a Dev org: You can do all the development work that you want without messing in your org’s sandbox. It has all the different clouds in there, including the partner and customer portals, so you can try out stuff you may not even own. The best part for me is that it comes with dummy data already in the org, so you can start playing right away. You even get a second user, so you can collaborate on projects. (Side note — Am I the only one who feels like this when I hear that word?)

This may be the tiniest of baby steps, but if you haven’t already done it, go get your free dev account.

A journey of a thousand miles begins with a single step ~ Lao-Tzu

%d bloggers like this: