Our event kicked off as we do each month, with some pizza, drinks, and great conversation. It was amazing to see the turnout for the global event. We had several new attendees and we hope they were intrigued enough to come back!

After some great conversations, Peter Knolle (@PeterKnolle) started the official meeting. He went over some key information, including watching a fantastic TrailheaDX ’17 hype video! After that, everyone was excited to learn more.

The main focus of the meeting was around Salesforce DX. Wade Wegner (@WadeWegner) did an enlightening session at TrailheaDX 2017 for an introduction to Salesforce DX. We watched that session together to learn more.

After watching the presentation, we discussed Salesforce DX and how it could be utilized. We also had some general conversation around how we use Salesforce and how to convince IT departments to invest on the platform. All in all, it was a fun evening. We closed the meeting up with a group photo before heading out for a few beers, some appetizers, and more discussion.

This might seem like such a silly thing, but before you click away, hear me out. The most important part of software development tends to happen after the initial piece of functionality is written. The reality is a large part of an application’s cost is spent during maintenance. Part of this reality is that you will have to come back to the work you are doing now and relearn the code that you had written. This means it is incredibly important to make your code consistent, which has the benefit of making it easier to read and easier to modify. Let me give you an example.

Imagine the company you work for sells flowers. You create a very simple page which allows you to create a flower order and add flowers to it. On your first attempt, this is how the controller code turns out:

public with sharing class FlowerOrderController 
{
    private Flower_Order__c flowerOrder;
    public List<Flower> availableFlowers{
        get;
        set;
    }
    
	public FlowerOrderController(ApexPages.StandardController stdController)
    {
flowerOrder = (Flower_Order__c)stdController.getRecord();
    }
    
    private void setAvailableFlowers(){
        	availableFlowers = new List<Flower>();
        List<Flower__c> flowersFromDb = [SELECT Id, Name FROM  Flower__c WHERE Is_Active__c = true];
        for(Flower__c singleFlower:flowersFromDb){
        availableFlowers.add(new Flower(singleFlower));
        }
    }
    
    public PageReference saveFlowerOrder(){
        Savepoint sp = Database.setSavepoint();
        try
        {
        insert flowerOrder;
        List<Flower_Order_Item__c> selectedFlowers = new List<Flower_Order_Item__c>();
        for(Flower flowerWrapper:availableFlowers){
        if(flowerWrapper.isSelected){
        selectedFlowers.add(new Flower_Order_Item__c(
        Flower__c = flowerWrapper.singleFlower.Id, 
Flower_Order__c = flowerOrder.Id
        ));}}
        
        insert selectedFlowers;
return new ApexPages.StandardController(flowerOrder).view();
        }
        catch(Exception ex)
{
        Database.rollback(sp);ApexPages.addMessages(ex);
        }
return null;
    }
    
    public class Flower
    {
        public Flower__c   singleFlower {get;
set;}
public Boolean isSelected {get;set;}
        
        public Flower(Flower__c singleFlower)
        {
        this.singleFlower = singleFlower;
        }}


}

How many times have you seen something like this? This code will run just fine and it should do exactly what we expect. The problem is that it is difficult to read. This will make it very hard to modify in the future, as you have to relearn what the code does when you go to make a change. The most frustrating part of all of this? There is simply no reason for it. It is very easy to clean something like this up, and it provides a ton of value. New developers focus so much on just getting something to work, that once they do, they sometimes just stop to make sure it continues to work. They got the job done, right? Well, why not spend 5 minutes, clean up the file, and you can get something like this:

public with sharing class FlowerOrderController {
    private Flower_Order__c flowerOrder;
    public List<Flower> availableFlowers {get;set;}
    
    public FlowerOrderController(ApexPages.StandardController stdController){
        flowerOrder = (Flower_Order__c)stdController.getRecord();
    }
    
    private void setAvailableFlowers(){
        availableFlowers = new List<Flower>();
        List<Flower__c> flowersFromDb = [
            SELECT
            	Id, Name
            FROM
            	Flower__c
            WHERE
            	Is_Active__c = true
        ];
        for(Flower__c singleFlower:flowersFromDb){
            availableFlowers.add(new Flower(singleFlower));
        }
    }
    
    public PageReference saveFlowerOrder(){
        Savepoint sp = Database.setSavepoint();
        try{
            insert flowerOrder;
            List<Flower_Order_Item__c> selectedFlowers = new List<Flower_Order_Item__c>();
            for(Flower flowerWrapper:availableFlowers){
                if(flowerWrapper.isSelected){
                    selectedFlowers.add(
                        new Flower_Order_Item__c(
                            Flower__c = flowerWrapper.singleFlower.Id, 
                            Flower_Order__c = flowerOrder.Id
                        )
                    );
                }
            }
            insert selectedFlowers;
            
            return new ApexPages.StandardController(flowerOrder).view();
        }catch(Exception ex){
            Database.rollback(sp);
            ApexPages.addMessages(ex);
        }
        
        return null;
    }
    
    public class Flower{
        public Flower__c singleFlower {get;set;}
        public Boolean isSelected {get;set;}
        
        public Flower(Flower__c singleFlower){
        	this.singleFlower = singleFlower;
        }
    }
}

I didn’t change a single thing between those two examples, except for consistently formatting my code. That simple change, which only took about a minute or two, immediately improves the quality of the work I have done and makes it much easier to maintain in the future. Moral of the story is that it is important to make sure things are clean before you finish your work. Spending a few minutes to simply format your code, can help tremendously in the future. Once you get into the habit of constantly keeping it formatted, it will become second nature and you will immediately be viewed in a better light by your fellow devs. Enjoy!

Apex provides a stub API for implementing a mocking framework. A mocking framework has many benefits. It can streamline and improve testing and help you create faster, more reliable tests. You can use it to test classes in isolation, which is important for unit testing. Building your mocking framework with the stub API can also be beneficial because stub objects are generated at runtime. Because these objects are generated dynamically, you don’t have to package and deploy test classes. You can build your own mocking framework, or you can use one built by someone else.

I was honored to be able to speak at my first Dreamforce and my two co-presenters were fantastic to work with. If you aren’t familiar with this topic, please check out either the Dreamforce ’16 video or watch the same presentation I gave a the Lehigh Valley Salesforce Developer Group

Getting Started with Apex Unit Tests

This is a fantastic start to explaining unit tests. I think the fifteen minute estimate is valid, although the test scenario using Date classes can be tricky for someone first learning unit tests. That may push it out past fifteen minutes. I’d suggest reading up on the Date class more and experimenting with it. While that wasn’t the focus on this specific piece, it can be trickier than other primitive data types, so it is good to get some practice.

Outside of that, there were a few oddities that I noticed. One, the challenge asks for you to create TestVerifyDate yet the example always ended their classes with Test rather than prepending it. Either way is fine, but it is important to be consistent when writing your test classes. Find a good paradigm that works for you and stick with it. I’d also suggest consistently using camelCase. Some of the code here did not always use it. You can choose your own formatting, but Apex typically uses camelCase so it wouldn’t be a bad idea to keep that in mind. Consistency is key to great development.

Testing Apex Triggers

Triggers are an interesting aspect of Salesforce that can cause headaches if done improperly. This example is pretty straight forward, but I would highly consider following Salesforce’s own posted Trigger Best Practices. Specifically, the use of logic-less triggers, one trigger per object, etc. By using a framework like this, it will be much easier to breakdown where your logic exists in real world situations as well as properly test the implementations outside of a specific trigger.

Creating Test Data for Apex Tests

It was a fantastic idea to call out the usage of a Test Utilities class for creating your data. That is a common mistake I see most new developers make (by not having one). I also thought the mention of branch coverage was a good idea. I felt this module was really good (despite some of the naming issues I mentioned above). I’d consider taking this to the next level by utilizing the new @testSetup annotation to encapsulate your data creation in a single location. I’d also consider more complex Test Utilities classes.

Overall, I’d say this is a fantastic module. Some minor chances to expand, but for the most part they include some great concepts for developers new to unit testing.

I highly recommend Trailhead for everyone. Even if I called out some different things that could be expanded on, it doesn’t change my opinion that Trailhead is a fantastic tool for learning the development practices on the Force.com platform.

For more information related to Trailhead, please read the Trailhead FAQ.

Once again, a Salesforce global user group meetup significantly helped attendance at this month’s Lehigh Valley Salesforce Developer User Group (@LVSFDCDUG/Youtube) meeting. We had one of our best turn outs in months from all of Salesforce’s marketing, but also from some promotion from the local Girl Develop It chapter, a great group looking for more members! Peter Knolle (@peterknolle) kicked off the event with the best Lightning presentation I have seen so far, explaining and demonstrating Lightning Connect, Lightning Process Builder, Lightning App Builder, and Lightning Components. We were incredibly fortunate to have Peter, a Force.com MVP and 6x certified Salesforce architect, presenting. He is one of the world experts on Lightning, sharing his expertise through several fantastic blog posts on his own site as well as on the Salesforce Developer Blogs (with more to come over the next few weeks).

After food, drinks, and Peter’s presentation, we jumped directly into hands on workshops, one of my personal favorite things to do with a user group. It is always interesting when you start working with fellow Salesforce enthusiasts and start hearing their use cases for the different products, specifically Lightning this meetup. Several of our members had begun writing Lightning Components, using the Lightning Process Builder, and experimenting with Lightning Connect. On top of that, it is fun to work as a group towards learning and discovering new technology.

After all of this Lightning talk, we finished the evening up with some drinks and more food at a local bar. The Lightning conversation was very active, and at the end of it, that really is the goal of these developer weeks. Let’s get more people involved and let’s keep them involved. So, what’s the next step for you?

If you don’t have one, get a Lightning Dev Org. This is step 1, and should be followed even if you have a dev org already. These orgs come ready for Lightning development. The next step would be deciding what you want to learn first. You have:

• Lightning Connect Tutorial
• Lightning Process Builder Tutorial
• Lightning Components Tutorial
• Lightning on Trailhead

After you have gone through the material, start to share your work! Share your experience on Twitter, Facebook, LinkedIn, etc! Write some blog posts (if you do not have a blog, I can work with you to guest blog here or on other blogs – just contact me)! Finally, make sure to continue to attend your user group. I know there is a large influx of attendees during this week, but you can get value year round from your local user group. Not only are you interacting with a larger set of people in your industry (perfect for recruiting/sales/job search), but in general you will find a ton of really smart people who will be able to teach you knew things.

It is a fun, exciting time to be involved with Salesforce. How was your Salesforce Lightning Week? What meetup did you attend? What are you most excited about with Lightning? Share in the comments below!

What’s Happening?

100+ Salesforce Developer, User, and Non-Profit groups across the globe will be meeting during Lightning Week to experience first hand the power of Salesforce1 Lightning. Join a group near you for demos, training, and to meet Salesforce experts. No matter your experience level you’ll learn new tools that you can start using right away.

Should I Attend?

Yes! It is just that simple. Everyone should attend. There are so many meetings being held around the world, hopefully there is one close enough to you to make it possible. If you are a developer, learning about Lightning is important because it is going to change the way you work with Salesforce. If you are an admin, learning about Lightning is important because it is going to change the way you work with Salesforce. If you are a consultant, learning about Lightning is important because it is going to change the way you work with Salesforce. See where I am going with this? Lightning is a huge set of functionality and topics and it doesn’t pertain to any specific “role”. Lightning is bringing developers, admins, and consultants closer than ever before.

RSVP Now!

There is still time! Choose from one of the many DUGs participating around the world, RSVP to the event, and join the rest of us! You will enjoy it! Share your experience with the world using the #lightningdevweek hashtag! If you live in the Lehigh Valley, PA area, please consider attending the LVSFDCDUG Meetup on March 12th at 6pm with me! Have fun!

Get a Head Start

Once you have RSVPed to an event, get a head start learning about Lightning using Trailhead. There is a fantastic Lightning hands-on tutorial now available on Trailhead. When you are done, try some other modules on areas you may not be 100% familiar with. Also, feel free to check out some of the great Lightning content being pushed to the Salesforce Developer blogs on a regular basis.

Have a fantastic Salesforce Lightning Week and be sure to share your experience online with others!

Note: Apologies for recording the “presenter” view, that will be fixed for the next recording!

Standard Address Fields Show Google Maps

Records with standard address fields now display a Google Maps image of the address. This saves users time by letting them see where their contacts or accounts are located, instead of having to locate addresses in a separate browser tab.

On a record, go to the detail page to see the Google Maps image on the address field. To generate a map image, an address must include the street and city fields and either the state, postal code, or the country. If an address field is missing any of the required information, a map won’t display.

Address fields will now look like:

This feature also works in Salesforce1.

This functionality will be on by default. To disable it, go to Customize | Maps and Locations | Settings and uncheck Enable Maps and Location Services.

Limitations Changed for Geolocation Fields (Generally Available)

Geolocation fields, formerly available only as a beta release, are now generally available. Now you can get the most out of geolocation thanks to fewer limitations and increased functionality, including improvements in Visual Workflow, workflow updates and approvals, Apex, search tools, and more.

Spring ’15 includes the following changes to geolocation field limitations.

• Geolocation fields are available in Visual Workflow and in formula-based criteria in workflow rules and approval processes, but cannot be used in filter-based criteria in workflow rules and approval processes.
• Geolocation fields can be searched in SOQL and SOSL.
• DISTANCE formulas are supported in:
  • Entry criteria for workflow rules and approval processes
  • Field update actions in workflow rules and approval processes
  • Custom validation rules
• The only formula functions that you can use with compound fields are ISBLANK, ISCHANGED, and ISNULL. You can’t use BLANKVALUE, CASE, NULLVALUE, PRIORVALUE, or the equality and comparison operators with compound fields. The equality and comparison operators include = and == (equal), <> and != (not equal), < (less than), > (greater than), <= (less than or equal), >= (greater than or equal), && (AND), and || (OR).
• Geolocation fields are now queryable in Apex. However, their locations are editable in Apex only as components of the compound field. Read and set geolocation field components by appending “__latitude__s” or “__longitude__s” to the field name, instead of the usual “__c.” For example:
  [java]
  Double theLatitude = myObject__c.aLocation__latitude__s;
  myObject__c.aLocation__longitude__s = theLongitude;
  [/java]

Use Visualforce Map Components to Show Location Data More Clearly

There are two new fantastic Visualforce tags, apex:map and apex:mapMarker, that are included as part of Spring ’15.

Visualforce mapping components make it simple to create maps that use third-party mapping services. Visualforce maps are interactive, JavaScript-based maps complete with zooming, scrolling, and markers based on your Salesforce or other data. Create stand-alone map pages, maps that you can insert into page layouts, and even mobile maps for Salesforce1.

Create Visualforce maps with a set of related mapping components. defines a map canvas, including map size, type, center point, and initial zoom level. child components define markers to place on the map, by address or geolocation (latitude and longitude).

Maps that you define generate JavaScript code to render onto the page. This JavaScript connects to a mapping service and builds the map by fetching map tiles, placing markers, and even geocoding addresses if you don’t have a latitude and longitude. After the map renders, your users can interact with the map by panning and zooming, just like they’re used to with other popular map sites. The effect is if you wrote your own custom JavaScript to interact with a third-party mapping service, but without needing to actually write that JavaScript. You define the map in Visualforce and get the mapping JavaScript for free.

An example of both tags in action:

Result:

My Observations

Salesforce has done a fantastic job with this release of visualizing location data and making it more end user friendly. As the world becomes more and more mobile, this type of information will be very useful to have at your fingertips.

Enjoy and feel free to test it out on your own Spring ’15 Pre-Release Org!

Apex Flex Queue

One of the nicest features of Spring ’15 in my mind is Apex Flex Queue. From the release notes:

Submit up to 100 batch jobs simultaneously and actively manage the order of the queued jobs to control which batch jobs are processed first. This enhancement provides you more flexibility in managing your batch jobs.

Previously, you could submit only up to five batch jobs simultaneously. The Apex flex queue enables you to submit up to 100 additional batch jobs for execution. Any jobs that are submitted for execution are in holding status and are placed in the Apex flex queue. Up to 100 batch jobs can be in the holding status. When system resources become available, the system picks up jobs from the top of the Apex flex queue and moves them to the batch job queue. The system can process up to five queued or active jobs simultaneously. The status of these moved jobs changes from Holding to Queued. Queued jobs get executed when the system is ready to process new jobs.

Administrators can modify the order of jobs that are held in the Apex flex queue to control when they get processed by the system. For example, administrators can move a batch job up to the first position in the holding queue so that it’s the first job that gets processed when the system fetches the next held job from the flex queue. Without administrator intervention, jobs are processed first-in first-out—in the order in which they’re submitted. To monitor and reorder held batch jobs in the Salesforce user interface, from Setup click Jobs | Apex Flex Queue.

My Observations

This is awesome! Being able to queue up 100 jobs rather than 5 is a huge difference (that is a 2000% increase)! The important thing to note about this change is the addition of the Holding status. From the release notes:

The AsyncApexJob object, which represents a batch job, has a new Status field value of Holding. This new status indicates that the job is placed in the flex queue and is waiting to be processed when system resources become available.

This aspect of the change is crucial. It doesn’t matter what version of Apex your code runs against, it needs to be able to support this new status. Specifically, this affects all queries against the AsyncApexJob. Take for instance (prior to Spring ’15):

This query would have found all existing batch jobs for the TestBatchClass prior to Spring ’15. However, due to the addition of the new Holding status, this no longer finds all of the existing jobs. This query needs to be modified slightly to:

As mentioned before, different than most changes to Apex, this is a data change. It requires code running on previous versions to take into account the proper Status values.

Enjoy and feel free to test it out on your own Spring ’15 Pre-Release Org!

@testSetup

One of the nicest features of Spring ’15 in my mind is @testSetup. From the release notes:

Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in every test method in the test class. Test setup methods can be time-saving when you need to create reference or prerequisite data for all test methods, or a common set of records that all test methods operate on.

Test setup methods can reduce test execution times especially when you’re working with many records. Test setup methods enable you to create common test data easily and efficiently. By setting up records once for the class, you don’t need to re-create records for each test method. Also, because the rollback of records that are created during test setup happens at the end of the execution of the entire class, the number of records that are rolled back is reduced. As a result, system resources are used more efficiently compared to creating those records and having them rolled back for each test method.

If a test class contains a test setup method, the testing framework executes the test setup method first, before any test method in the class. Records that are created in a test setup method are available to all test methods in the test class and are rolled back at the end of test class execution. If a test method changes those records, such as record field updates or record deletions, those changes are rolled back after each test method finishes execution. The next executing test method gets access to the original unmodified state of those records.

In Action

Let’s consider the following class:

Typically, this would require a unit test class that looks like:

So, what’s wrong with the current approach above? Well, you need to generate the same data several times, but it is also done in slightly different pieces of code. This can cause maintainability problems as well as well as a slow process generating the same data. How would this look using the new @testSetup method?

Note how there is only a single method that inserts data and also note that I can directly query records immediately in a test yet @SeeAllData is not set. We are accessing the data that was set up when the class was first instantiated. Now let’s tweak the code just slightly to verify the rollback works properly.

The last test was added to verify that the data rolls back to it’s original state, which it does (otherwise we would find an account with the updated name).

Other Considerations

From the release notes:

• Test setup methods are supported only with the default data isolation mode for a test class. If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class. Because data isolation for tests is available for API versions 24.0 and later, test setup methods are also available for those versions only.
• Multiple test setup methods are allowed in a test class, but the order in which they’re executed by the testing framework isn’t guaranteed.
• If a fatal error occurs during the execution of a test setup method, such as an exception that’s caused by a DML operation or an assertion failure, the entire test class fails, and no further tests in the class are executed.
• If a test setup method calls a non-test method of another class, no code coverage is calculated for the non-test method.

My Observations

This is a big step forward to achieving faster test runs. Faster unit test execution time is pivotal to Test Driven Development (TDD). This is a feature that will immediately impact the way everyone develops as every single Salesforce developer will want to utilize this functionality.

The main downside to all of this is the fact that the only way to access this data is to query it back from the database. While this may not be a problem in the simple example above, it may become more of an issue as the complexity grows.

With that said, it is still worth it to use this new functionality. You will still want to incorporate good unit test practices (such as using a TestUtils class), this will just be a new aspect of proper unit test structure. Enjoy and feel free to test it out on your own Spring ’15 Pre-Release Org!