Category: Salesforce

Salesforce

The Rollercoaster of Change

| sudovi

I’m a creature of habit and change for me doesn’t come easy. When making career decisions, I do tend to extrapolate things out and try to weigh out all the advantages and disadvantages of the various scenarios.

For instance, I’ve not been part of “Corporate America” for 18 years. (Well there was a 9-month gig at an IT Union shop where I was LIFO’d — last in first out — during a layoff, but I don’t count that). I’d spent the first 5 years of my career at a fortune 500 company and during that time, we were re-org’d 4 times. Seeing people rush around, re-interviewing for their jobs was very alarming. (This is about right).

When I picked up and moved to Madison, I joined a local consulting firm that while national, still ran rather independently, and from there I wound up at a small Java shop of about 26 or so people. (We grew and shrunk, but I was there for 10 years). I was largely on an island, were it not for the fact that I was in an office with peers, I might have felt that I was just self employed. I got very comfortable on this island.

After my last company closed its doors I went back to that shop in an attempt to build them a Salesforce practice. This time I was the ONLY Salesforce person so it felt even more like I was my own boss (and for all intents and purposes I was) which was why when I had the opportunity to apply for a position as Salesforce.org, my emotions were all over the board.

I strapped myself firmly into the seat of this emotional rollercoaster as soon as I clicked submit on the application and a whirlwind of emotions ensued.

That first hill gets ya! You have all sorts of unknowns flying in and out. You don’t know if you’re going to enjoy what’s ahead, you’re very excited to find out, but also very intimidated, “should I even be on this ride?”, “are you qualified to meet the minimum requirements?”, “am I gonna throw up?”

My first interview was only 15 minutes…“was that too short?”, “If we were off the phone that quick am I dismissed already?”, “Was that too long?”, “Did I say too much?”, “What if I move on and people think I don’t know what I’m doing?”, “If I don’t move on, do I know what I am doing?”, “I think that went well…oh crap it went well and now I have to do it again!”

The second interview has the same feelings. “Even if I make it out of here alive, can I go through it again?”, “What if I do really well, whats next?” The third interview, more of the same.

Having not been part of a “real interview” in 18 years, I’d never been fully “teched” before. This caused all sorts of distress. “How am I actually being graded here?”, “Can I ask too many questions?” Never have I ever second guessed my code so much. Double checking everything, sucking out every last bit of code coverage I can get, (which I normally do anyway, but this time, it felt different, like I was unit testing for my life!), fully documenting everything that I’ve done complete with tables and nice looking fonts (everyone likes comic-sans right?? #Kidding). Getting through that was like the first time you rode a rollercoaster that went upside, or that dropped you straight down from 20 stories up…stomach up in your throat, but getting through it is like that rush of adrenalin…“Look what I just did!! I DID that!! ME!”

Then reality hits ya hard. I was not prepared at all for what came next. After passing the previous level (this really was almost game-like, leveling up each time), the more relaxed but deep conversations followed. My imposter syndrome never let me think that I was going to get to this level. I was always the kid that had to use cheat-codes and the “Game Genie” to advance to higher levels (…man I’m old). However, its also at this point that you realize, perhaps you may be too hard on yourself. Someone sees something in you and even if you don’t see it yet, something is there, you only hope you can find it yourself (this is a daily struggle for me actually).

After meeting with more of the teams you realize that soon, if things go your way, you may have to make a decision. In some cases this decision may be easy, in other cases, it may be very hard. For me, making this decision meant a number of things:

Giving up my MVP status — maybe I’m not supposed to talk about it in this way, but I LOVE being an MVP. I feel such a closeness with many of my fellow MVPs. They truly are like my extended family. I also like being out in the community and meeting new people, doing the whole selfie thing…while I’ve said it over and over again, “I’m not a people person” the community sure brings it out in me, and I love it.

Apex & the Limits — “Would I have to step down from Apex & the Limits?”, “Could I bring myself to step down if that was a requirement?” I love music, and I love this community, the band helps me tie those two things together. (Thankfully, I’m very happy to say, I’m still “with the band”).

System dot Debug — for those that don’t know, I’m also co-host of the Salesforce developer’s podcast known as “System Dot Debug” and I really enjoy that as well as I feel we do something nobody else is doing in the dev podcast space as our shows are recorded live on System dot Debug Youtube Channel. I enjoy my time with Bryan and Raymond and I want to be a part of this as we grow. Great news! I don’t have to give this up either…

Can I go back to having a “traditional boss?” at a large company — For all intents and purposes, I’ve largely been flying solo for quite some time. “Will I be able to adjust?” (I know I will adjust and the team is friggin’ awesome so this is no longer a worry, but it was during the decision making process).

In the end, you do whats best for you, your family and your career. At the end of this rollercoaster, you unbuckle and you step off onto the platform and its a different world. Your sad the ride is over, but you’re so looking forward to going to the next ride, the bigger, faster, longer ride. You’re nervous all over again about that first hill but once you are strapped in, you’re very excited for what comes next.

I didn’t think I could be more nervous, and excited, and scared, and happy, and sick all at the same time, but I certainly am. So I hope that you will virtually join me on this ride because I’m not going anywhere. I’m still the @lifewithryan you know, I’m still going to be community present, I’m just going to be part of team doing good things again, and that feels very good.

Please fasten your safety harnesses and keep your hands and feet in the car at all times. Raising your hands and screaming however is vastly encouraged, (I will be), enjoy the ride.

:wq!

Salesforce, Support

Yes the Community is THAT Important!

| sudovi

Since I started back with my old company as the Salesforce Practice lead, several firms have contacted me trying to place resources, or I’ve been asked to help “tech” someone applying for jobs at various clients around town.

I recently got passed a resume of someone claiming they’ve had 5 years of experience and carry 5 separate certifications. This person is apparently somewhat local to the area and yet I find no record of this person in any — zero in fact — of the various Salesforce related communities online. Not success, not the stack exchange, not even on twitter or even a blog. In addition, if they’re as local as I’m led to believe, I’ve not seen them at a single user group and not at my dev group either.

While I have no doubt that the person is probably quite capable, I find this extremely alarming. To me it shows zero passion for the platform, zero advocacy. Maybe I’m not being fair, maybe there are extenuating circumstances that I don’t know about, maybe they don’t know these things exist (after five years experience, I find that really hard to swallow).

If I’m given the choice between this person with 5 years experience, and 5 certs but completely unplugged from the community, or someone who maybe has only some of the experience and certs but is regularly attending User Groups, has a success community profile, or stack exchange, and is engaged at all with the community — I’m going to pick the latter.

To me, yes the community is THAT important! Its where the support is at, it’s where you learn the new tidbits and connect with others like yourself and more advanced than yourself, its how you grow. Surrounding yourself with the members of the community I feel is one of the most important things you can do in your Salesforce career and activity within the community is NOT to be overlooked.

If you’re reading this, and wanting to build a career on the platform but you haven’t participated in these channels, it would behoove you to start right away:

Login to the Trailblazer community and create a profile
Visit/browse the Salesforce Stack Exchange Community
Attend a local user (or dev) group, and if you don’t have one, start one! (You can find them listed in the Trailblazer community I linked to above).
Do this, do this now — don’t even finish reading this rant of sorts…

Yes, its THAT important!

:wq!

General, Lightning Components, Salesforce

Transitioning to #Lightning from Visualforce

| sudovi

You’ve heard me say it before: I was jaded. I was looking back at 20+ years in I.T most of that as a developer in various languages and “frameworks of the day.” I was tired of the same thing, and even my transition to the Salesforce platform brought very little actual excitement for me. The community helped me see past all of that, which is why the community is still my favorite thing about the ecosystem, but as a developer, I was still…well I was cranky!

Then Salesforce introduces #Lightning. Suddenly I was invigorated again, something new, something that was in line with what all the “cool kids” were doing. Something forward-looking, and I got excited again. I dove in and started working, which brings me to my first tip for making the leap from Apex/VF to Lightning.

#1. Jump Right In — One of my favorite bands today “The Zac Brown Band” has a song called “Jump Right In” and you could say I took that to heart. I closed my eyes, picked a random deity, said a prayer and leapt from the lion’s head smack-dab into writing some lightning components. I suppose I’ve always been a learn by necessity/trial by fire kinda person and that seems to work for me. So if it works for me, it might work for you as well. Spin up a developer org, turn on lighting, and start writing something, anything! My first foray was a streaming application that ran via the web and in Salesforce1 that allowed users to vote on what they wanted for lunch. As they voted, the counts went up in real time. Meaning person A voted for sushi from their phone, and persons B,C, and D all saw those updates happen in real time on their screens. I was jazzed, and I was hooked! Was it useful? Not really, but that’s not what matters. What matters was that I learned something. So just “Jump Right In” and do something.

#2. Ask “What If” — since your jumping right in with both feet anyway, start asking yourself “what if?” What if I try to add something like a streaming (see above) result to a lightning component? What if I change this line to that? What if instead of creating a component on the record detail page to modify a field on that same object, (because you could do that), I created a reusable form to create child components directly from the parent’s detail page without having to leave that page? Ya know, like this:

#3. Check out Lightning Design System — When thinking about moving some functionality from Visualforce to Lightning, think about your options. Maybe your first option isn’t a component at all, maybe its simply re-styling your Visualforce page using the Lightning Design System. (This thing is awesome…just awesome). If you’re at all like me at hate front end work, the perhaps the Lightning Design System can ease your pain somewhat. They’ve taken all the things I hate about CSS and put them together in a not so blackbox “blackbox” that just works. All you have to do is apply the appropriate styles to your HTML elements and the system takes care of making it look like the page is inside LEX. Yea, I’m gonna say it…it’s sexy.

#4. Lightning Out — Maybe you’re not quite ready to go full on lightning components. Maybe you could instead replace pieces of functionality with a simple component and Lightning Out and throw that into a Visualforce Page. Lightning Out allows you to run lightning components right inside of a Visualforce page or even off platform if you so desire. (Something I’m really wanting to try but just haven’t been able to find that time yet, but mind you, I will indeed find the time). This would allow you to start small and work your way up.

#5. Get Involved — No surprise here. Me, the guy always raving about the community, is asking you to get involved with the community. Join your local developer group, go to user groups, participate in the Success Community, or the Salesforce Stack Exchange. Start helping other’s solve their problems. I promise, you will learn more than you ever thought you could, and there’s so much to learn. I’m barely scratching the surface and if it weren’t for those in the community already doing the things I’ve mentioned above, I’d be nowhere. Ya hear me? No. Where. The community is the secret and we are all here to help. The blogs, the forums, the user groups, the conferences, all of it. Just do it.

:wq!

Salesforce

Lightning, Are You Ready?

| sudovi

Salesforce.com’s new UI (and design paradigm) Lightning Experience (LEX for short), has been making impressions since it was announced. Admins & user’s alike have had over a year now to poke and prod at it with a stick. I even know of a few folks that claim to have LEX turned on in their production orgs for all users.

I get asked all the time, what’s it going to take for us to switch over to LEX in “our org?” And more often my response has been: “It’s not really a question of if you are ready for LEX but is LEX ready for you?”

I don’t say that to bash LEX in anyway — however I feel at times there are many that feel jaded by it. It’s not the most performant thing yet, and yes there are many items that now take more clicks than we as admins and users are used to. To those folks I say, consider this:

Regarding performance: We are asking a “page” to do so, so, so much more than a page has done in the past. I’ve been in IT for over 20 years. Its a vicious circle. There was the mainframe and dumb terminals, then it all moved to desktop apps, then over to client server (a rehash of dumb terminals, if you will), then onto more of a hybrid, then onto web applications, and now we are in the app world, and demanding more of our web experience to behave more like our apps. I daresay it will come around yet again in some evolution and we’ll be off the client and back to the dumb-terminal to server architecture at some point. For now however, we are in some sort of thick client like architecture where much of our heavy lifting happening behind our web pages is now happening in javascript, on our devices when it used to happen at the server and simply show us the results of said backend work. As consumers of technology we begin to demand more and more from what is available and while technology moves at the speed of light, our expectations seem to move even faster — and that is okay! THAT my friends is how things progress. The caveat here is, we need to be patient. It. Will. Get. Better.

Regarding more clicks: As a developer there are times when I think to myself: “How can users be any lazier? Complaining about an extra click or two? After all, data is king and having it organized and clean is worth the extra clicks.” It takes me awhile to snap out of that line of thinking and look at things from the perspective of a user. Our jobs get more and more demanding everyday. “Do more, with less, and do it faster!” so efficiency is king to a user. I get that. Here we are squaring off and being the service oriented people we are, we ease the end-user’s life even when it makes our life a bit more difficult. Eventually we come around and meet somewhere in the middle. This whole thing is a process, it will take time to get things to the point where performing tasks in LEX will be just as efficient in LEX as they are in classic. There are millions of us users, and we all have feedback and opinions, etc. It takes time to process all that collective feedback and jump the technical hurdles currently blocking the way to some of this efficiency, but it will come.

Overall, LEX is indeed not ready for most existing clients. Change is never easy and perhaps the hardest element to overcome is the human element. However, LEX WILL BE ready, perhaps not as fast as many would like, certainly not as fast as Salesforce.com would probably like — but its a paradigm shift.

It reminds me of my last “Corporate America” job 14 years ago. I had been a linux user since 1995. I loved it, was way more productive using that than using Windows. As a server architecture, particularly for web apps it just made much more sense to me. I made the mistake of preaching its virtue’s to my Microsoft embedded colleagues who never let me hear the end of it (ultimately why I was happy to leave that job — being a pilgrim in an unholy land took its toll on me). “Your toy operating system will never go anywhere, why waste time on such things” — a few short years later, linux in that environment was a constant. It took time for that to make its way, but it certainly made its way.

Rome wasn’t built in a day — LEX will be ready.

:wq!

Salesforce

Catching Up With the Community

| sudovi

First off, please accept my apologies for letting things slack around here a bit. Since May things have been absolutely crazy. As previously mentioned two big things happened in June and then there was a brief period of professional catch up being played, followed by another three big things, (there was a fourth-ish, but lets just downplay that one).

Thing One
Midwest Dreamin’:
I had a moment of bravery and submitted a talk for Midwest Dreamin’ and it subsequently got accepted. This meant that I really had to get my shit together and practice and organize my thoughts, etc. I was super worried that all the work I’d done to day was all for naught, or at least would be usurped by features in the pending Summer 16 release. Alas, it would appear that neither of those things happened, and overall my presentation went of rather well considering public speaking is just not something I feel very comfortable with yet. (Nor do I think of myself as an authority on any topic, so I was suffering some major Imposter Syndrome). My session was packed, my clicky thingy wasn’t working to advance my slides, I felt unorganized, and my laptop took a dive off the podium at the end, but people clapped and I had some good follow up questions afterwards. Oh and someone want’s me to present on how to write Salesforce parody songs…interesting, but that’s a great segue…

Thing Two
Apex & the Limits at Midwest Dreamin:
Whilst prepping for the above presentation at Midwest Dreamin’ I also had to help my band mates prepare for a number of mini-performances for the conference. This part is always stressful because there are certain needs, (not green M & M’s kind of needs, thing more logistical needs) that the band requires. There’s sound, microphones, prepping the karaoke tracks, the lyrics, figuring out who is singing what part, etc. Its all very nerve wracking and usually all comes together at the very last minute, but once we are up there — THOSE moment make it all worth it. People may think we are looney, but I’ll be damned if we don’t have a great time!

Thing Three
LEX MVP Summit:
The first part of the week at Midwest Dreamin’ was a closed MVP event regarding all things LEX. And while there isn’t really anything I can share with you from a platform point of view (NDA and all), I can say there are some great things coming. My brain was absolutely full after the first day but somehow they managed to cram even more information on day two. Add to that, getting to catch up with my MVP family from all over the world always gives me a recharge.

Between catching up with my fellow MVPs and meeting all the new faces (and some old friends) at Midwest Dreamin, my community cup had runneth over. These are the moments I love. These are the moments however that also make me question: Why am I coding anymore? My love is really interacting with the community. How can I get to interact more (and still make a living). I still haven’t figure that part out yet, but its definitely on my radar. I’ve never considered myself a people person, but for some crazy reason — this community makes me want to be out amongst people.

Okay a fourth-sh thing (plus a half):
They made me walk around in Lion PJs. The things I get myself into (contrary to popular opinion, there was no bet):

4.5:
I got stopped in the expo for my autograph — I still haven’t figured out if that was a serious request, but out there somewhere is a polaroid selfie with my signature on it, because how often does THAT happen?? Never if you’re me, so hell yea I signed it and now I have a story :)

Okay, back to it…see you all at Dreamforce!

:wq!

Music, Salesforce

Everyone’s an Admin

| sudovi

Okay, so I had part two of my lightning components exploration all planned out but — I haven’t executed it yet, life just sorta got in the way. To that end, awhile back I recorded a new song: “Everyone’s An Admin” and had sent the rough draft to a few people and even performed it at #SoutheastDreamin. My plan was to do something more “official” but given that life sorta gets in the way sometimes, I don’t see a chance to do this one “right” for a little while yet, so here it is in its rough draft form, “Everyone’s An Admin”:

Hopefully I’ll have some time to get the next part of my lightning topic ready to fly by next week. Until then, I hope you enjoy the video.

:wq!

General, Lightning Components, Salesforce

Thinking About Lightning Application Architecture: Part 1

| sudovi

One of the things that really surprised me when I started poking at custom Lightning Components/Apps was the fact that I truly had to handle navigation from scratch. As a developer, we’re taught to never re-invent the wheel and to write code that is re-usable up front. Over the next few posts, I hope to discuss what I’ve found, what I’ve tried and what I’ve ultimately come up with when facing these challenges.

When I started out, I knew that navigation was something that I didn’t want to have to solve every time I set out to write an application. I knew I’d need a core group of components and events that would work in concert with one another and I knew that I’d have to keep these components generic enough that they could be included in any apps that I wrote. What I’ve come up with thus far appears to be working and I’ve done a demo for a couple different people and haven’t had any major “gotchas” pointed out to me yet. I’m still trying to get the ear of some other folks that I know are much more into Lightning than I am just to level set my expectations and find out if I’m really off in the weeds or not.

Before I get into the nitty-gritty, the back story here is that I had a customer approach me about creating a Visualforce page for a very complex custom object in their org. They wanted to be able to use the page in both the browser and on Salesforce1. If this were a simple object, this could have been simpler I imagine, however there are numerous dependent picklists that forced the original VF page to be spread out amongst several other clicks/refreshes, etc. This was not going to translate well to Salesforce1. Also, we wanted to avoid two different processes, one for mobile and one for the web. I made a couple of suggestions and one of them was to create a custom app that could be “created” via App Builder for use with Salesforce1 and an app that could be accessed via the web interface. (I’ve since done some playing with lightning out and prefer going that route for the web interface as it feels more native to the Salesforce experience).

However, budgeting for such an endeavor was a challenge because I’d never done anything like this before. I’ve been through the trailhead modules, taken a HOT at Dreamforce and toyed with it a bit on my own but only using rather simple examples. This was a chance to step back and tackle a “real world” scenario. I dove in far enough to realize, as some of my past blog posts have eluded to, that Lightning really is a “framework” in the most true sense of the word. There are just enough features there for you to work with, but you are left to your own devices to get things off the ground. Therefore, I started an example project in a dev org and this is what I’ll be going over in the coming posts.

Since #TahoeDreamin had just ended, and Apex & The Limits had been asked to travel to #SEDreamin — conferences were stuck on my mind. So my sample application was a very basic conference management application, its not fully baked and I plan to write more, but currently its just venue’s and conferences because…well consulting and billable hours take precedence. (Hey kids gotta eat man!)

The actual components are simple enough that I could use pre-built items for display, etc but I wanted to see how the system would behave with completely custom pages/forms, etc. since my clients’ application was not going to be able to take advantage of things like default page layout, record pages and what have you.

Rather than discuss the ins and outs of creating my custom objects, I’ll just tell you what I have and leave you to your devices to create them (or something similar) if you’d like to follow along. We have a Conference object and a Venue object. Each object has its own information, like addresses, start dates, end dates etc. Again since that’s not at all what this post is about, I don’t want to spend too much time here. Let’s get to thinking about the structure of the application since we are trying to be generic anyway.

Navigation:
I wanted to be able to navigate to a list of conferences or a list of venues so I knew I would need a basic component to display these links to me. I knew I would need custom components to display these lists and informational pages. What I didn’t know was how to navigate between the two. My intuition told me that selecting a record would need to fire some sort of event that I could handle and initialize/load the appropriate component. I had been googling and not found a standard, built-in navigation method. I did find e.force:navigateToSObject and other similar events, but those only work in Salesforce1 (according to the docs) & I needed this to work in the web interface as well. On top of that, I needed a component to fire that event anyway. I knew I needed to fire a custom event and it was looking like I would also need a component to fire it.

However, that’s only part of the problem. Even if I managed to fire this custom event, how were people swapping components in and out. And then I came across this. Basically, I needed to create a container component that would house my custom components and swap them in and out of there.

The last piece I needed was some generic code to be able to handle my custom event, get the name of the component I intend to load and have my container component’s controller load that component. I created a “Base Component” that will be my container and a matching controller that will initialize my entire app (based on a parameter, but more on that later) and also handle my “navigation” by swapping out custom components as signified by my custom event. That looks something like this (I’m using the Lightning Design System to style things):

<aura:component implements="force:appHostable,flexipage:availableForAllPageTypes" controller="BaseComponentController">
	
	<aura:attribute name="appName" type="String" />
	<aura:attribute name="activeComponent" type="String" />

	<aura:handler name="init" value="{!this}" action="{!c.doInit}"/>
	<aura:handler event="c:NavigateToComponent" action="{!c.loadComponent}" />

	<div class="slds" style="padding: 10px;">
		{!v.body}
	</div>

</aura:component>

And my Base Component’s controller (NOTE: much of this code should be moved to the helper class, I just haven’t gotten there yet):

({
    doInit : function(component, event, helper) {
            //ignore this bit for now, more on that later
            var action = component.get("c.getDefaultComponent");
            action.setParams({
            	"appName" : component.get("v.appName")
            });

            action.setCallback(this, function(response) {
            	var state = response.getState();
            	if(state === "SUCCESS") {
            		//load new component
            		var defaultCmp = response.getReturnValue();
            		$A.createComponent(
            			defaultCmp,
            			{},
            			function(newComponent) {
            				component.set("v.body", newComponent);
            			}
            		)
            	}
            });

            $A.enqueueAction(action);
    },

    //this is the custom swapping of components piece...
    loadComponent : function(component, event, helper) {
        var newCmp = event.getParam("targetCmp");
        var attrs = event.getParam("attributeList");

        $A.createComponent(
			newCmp,
			attrs,
			function(newComponent) {
				component.set("v.body", newComponent);
			}
		)
    }
})

The “magic” here lies in my controller’s loadComponent function. You will notice that my Base Component is handling a custom event called “navigateToComponent” — this event gets fired by another custom component (we’ll discuss that in my follow up post), my base component will handle that event and inspect it for the name of the component I’d like to load as well as any custom attributes my new component will need, such as the ID of an object I’m trying to load into that component. This function calls $A.createComponent which loads an instance of my component, and swap it into place where my Base Component has {!v.body} specified.

So now “theoretically” (this is all just my observations, but it is indeed working) I can fire my custom event, pass in the name of any component and its attributes and load it without my Base Component having to know anything about the component it is loading nor its data. If I use this base component in all my future apps (along with my custom event), navigation is solved for me.

That’s plenty of writing for me, and reading for you at the moment I think. Hopefully next week, I’ll have the custom event queued up for you :)

:wq!

Salesforce, Trailhead

New Trailhead Trail to Help Answer That Question: “What is it that you do exactly?”

| sudovi

If you work in I.T. or anything remotely to do with “technology to solve business needs” then you’ve no doubt been asked by your mother, grandmother, grandfather, uncles, aunts, cousins, friends, and random people at various social events “What is it that you do.” Explaining what you do to a non-technical person can get very complicated, very quickly. You can literally watch the glaze begin to form over people’s eyes as they realize that they don’t understand a word you are saying. Now, to quote Chris Duarte, “There’s a badge for that!”

Recently Trailhead release a new trail called “Navigating the Salesforce Advantage.” It seems to do what nobody has really been able to do very well and that is explain what the cloud is and how businesses benefit from it. What Salesforce is and how it leverages cloud technology, and it does so with the same fun attitude that Trailhead has become known for. (I mean one of the answers in the quiz sections reads: “Its complicated and makes you look smart” — ya gotta love this stuff.

Its been suggested that when asked the question, many people default to “I work with computers” — that’s enough for those that would just glaze over anyway. But for those that lean in just a little more, it might not be a bad idea to send them over to Trailhead for a much better answer than “I do computers.” :)

It starts out talking very basically about Salesforce the company and its four core differences: Customer Success, Innovation, Leadership, Giving Back (my favorite).

Now, for those that didn’t “checkout” after your “I do computers” answer, a group of them will have checked out after above two modules feeling satisfied that they have a better understanding of what you do with your 8 to 5 time. However that won’t satisfy the more tech savvy and from there they will move on to the module that discusses the technology basics behind Salesforce. Brief overviews of security and multi-tenancy are given. Things start getting a little heavier here and you may lose some more folks, particular when talking about metadata, there’s something about saying things like “data about data” that scares people off. (It used to drive me nuts back in the 90s — yes, I’m old). However this module clears things up a bit and then goes on to talk about why the metadata architecture is a huge advantages for customers using the platform.

Finally, if they’re still here — they’re interested in finding out more and the trail closes with my favorite topic of all time: The Community. It’s no secret that I’ve raved and raved about this community. The plethora of talented and engaged individuals means that you’re not alone, ever and help is always right around the corner.

So there you have it — there may not be any hope for those that completely glaze over the minute that anything that sounds remotely like 1’s and 0’s starts to come out of your mouth, but for those with some interest, and perhaps some drive to learn more, and do more — there’s a self-serve answer for them out there. So next time someone asks you what you do, give them a sly smile and say: “There’s a badge for that!” and point them to Trailhead.

:wq!

Lightning Components, Salesforce

Top Five Things I’ve Learned So Far About Lightning Components

| sudovi

If you are reading this, Force.com Lightning Components are something you’ve probably heard about by now. However, if your situation is at all like mine, you’re probably finding very few people doing much of anything with them yet, especially when it comes to doing so for commercial customers. Sure, you may know some folks who are messing with them in a dev org or perhaps have even written something for the App Exchange, but you’ve not really seen anyone working on Lightning Apps for their customers “in the wild.”

I think this is largely because there is quite a bit to learn, and they’re still relatively new, so for those forging ahead, you’re quite possibly in some uncharted waters. This is the boat that I happened to find myself in the past couple of weeks.

I was asked about the feasibility of doing a Lightning App for a client and while I was extremely excited, I was also extremely intimidated. I don’t yet know all the things that I don’t know, and I know that I don’t know quite a bit. (That was probably more fun for me to type that it was for you to read).

I had to do some research so I took some personal time and borrowed this client’s use case as my test bed. Don’t get me wrong, Trailhead is a great way to get started but there’s nothing quite like learning from a real-world example.

I had grandiose plans to have some workable code examples to blog about, but billable hours call and I’ve not put anything together yet that I believe one would find useful, but I did manage to learn a few lessons in the few short hours that I put in. Here are my top 5 takeaways so far:

#1) You have to create more components than you think. There’s been quite a bit of talk around reusable components, built in “stuff” etc. All of that is indeed coming I’m sure but as it stands right now there aren’t too many ready-to-fly components. For instance: I expected to find a prebuilt ui component that I could load in a list view that would be “tappable/clickable” etc. There may be one, but I couldn’t find it and after talking with a few people who are currently toying with these things, the general consensus was that I’d have to write my own. The goal of this component was to, at the very least, fire an event that I could listen to and then use that even to load a custom view component. (A force:recordView action exists, but that wasn’t going to work for this case, and even so the component that one would wire up to fire that event doesn’t seem to exist). Which brings me to the next item.

#2) Its all about Events. Components need to fire events to tell other components and bits of code you write to load/execute. I already knew this was the case but didn’t realize the extent to which you would employ events. I attempted to use an existing lightning event when my custom item list component was tapped. For some reason that event never loaded, so I decided it’d be a good time to attempt to write my own event as an experiment. That one indeed fired without issue. Then I realized that its all well and good that I fired the event (and handled it in the parent component), but then realized I’d need to fire yet another event to tell my components to swap in and out. Essentially a navigation event. (I’m still working on this but I haven’t finished…because consulting).

#3) “Physical” structure is very important to consider right out of the gate.Often times I trudge forward and just figure things out along the way, and that’s what I was doing here. However when it came time start figuring out how to swap components in an out, etc I realized that I actually need a top-level component that would own all other components. I had thought I originally created a top level component but then realized what I actually created was just the first component that the user will see. I wound up building another top level component that would house this original component as well as be responsible for swapping in/out other components as fired events dictate. I’m envisioning now that this top level component will essentially be responsible for handling APPLICATION level events (such as navigation events perhaps) and knowing which component is currently being viewed, etc. Had I thought of that fact up front, I would have saved myself some refactoring. (NOTE: this is all still theory as I haven’t completed my navigation components yet, maybe this won’t work…I dunno yet).

#4) Be as generic as possible. The overall goal — since we’re doing all this low-level component work — is to wind up with reusable components that you could possibly use in other apps. For instance, my ClickableListItem component and ItemSelectedEvent take an object Id, type and name. I can use that component and that event to display any object as well as tell whichever component that holds it that it was clicked and give that component access to the object ID through the event. I can use this in any app I write. I’m trying to remember this moving forward especially with regards to navigation. Ideally I’d love to be able to load components dynamically and have to solve that problem only once rather than re-invent the wheel for every app.

#5) It creates a ton of files. I currently have one screen and a few events but there are nearly 50 separate files. (Granted I haven’t used all of them, but they’re there). It can get hard to keep track of everything involved with a given app since components can be reused under multiple apps, etc.

BONUS: I also didn’t realize the extent to which I’d be using the Lightning Design System. I guess I’d just assumed (rather falsely) that using the ui/aura tags also would apply some sort of default style. This is not the case as near as I can tell, so I had to include LDS in my top level component. Again, I’m not sure why I was assuming I wouldn’t have to…but I assumed nonetheless.

Anyway, some of this might be way off but its what I discovered in my few short hours of exploration. Your mileage may vary.

:wq!

Dreamforce, Salesforce

Are You Going to Tahoe?

| sudovi

I’m not — and I’m never going to be able to forgive myself for it, but due to some personal things going on, my family just couldn’t swing having me away that weekend. That being said, I’m asking you all to consider going. Maybe you missed Dreamforce, or maybe you are “missing” Dreamforce, maybe this event will be the one where you take home something so invaluable it changes your career for good.

Here are 5 good reasons you should attend Tahoe Dreamin:

  1. It will be a more intimate setting than Dreamforce. Not that Dreamforce isn’t a good thing, but the huge number of attendees compounded with the vast array of session options, it can be a little overwhelming. These smaller events tend to be more “digestable” and due to the size of the group in these sessions, it feels less like fluff and more like stuff
  2. Great speakers & Sessions. I mean just look at this list of Tahoe Dreamin’ Sessions so far!
  3. It’s been organized by Salesforce MVP Bill Greenhaw. With Bill behind this thing — its sure to be an incredible event. For those of you that don’t know Bill, he’s very passionate about the platform and even more so about the community and his role in that community. Definitely a man worthy of praise!
  4. Dreamforce ’16 is quite a ways off and if you are anything like me, your Salesforce year revolves around Dreamforce…its how we measure time. These in-between events can help you get over that hump!
  5. Last but not least, it’s Tahoe for cryin’ out loud. TAHOE! So what the heck are you waiting for. Go, go, for all that is good and holy…GO!

P.S. Ima be extremely jealous…

:wq!