Weekend Learnings 28072019

MindValley, Inpired speeches from Great people
https://www.mindvalley.com/quests/extraordinary-by-design

VSCode setup:
Basic Trial:

Today I completed module called

Apex Testing

Define Sets and Maps

Learning Objectives

Choosing a List or a Set

You may be thinking, “I know how to use both lists and sets now. How do I decide which to use?” Think about the collection you want to create and ask yourself these two questions.

Do I want to allow duplicates?

Is the order of items important?

If you answer yes to at least one of these questions, then use a list. If you answer no to both questions, use a set. 

You’ve learned about lists and sets, but there’s one more collection type. Let’s talk about maps next.

Apex Debug Skills

These panels are available in the Log Inspector.

• Stack Tree—Displays log entries within the hierarchy of their objects and their execution using a top-down tree view. For instance, if one class calls a second class, the second class is shown as the child of the first.
• Execution Stack—Displays a bottom-up view of the selected item. It displays the log entry, followed by the operation that called it.
• Execution Log—Displays every action that occurred during the execution of your code.
• Source—Displays the contents of the source file, indicating the line of code being run when the selected log entry was generated.
• Source List—Displays the context of the code being executed when the event was logged. For example, if you select the log entry generated when the faulty email address value was entered, the Source List shows execute_anonymous_apex.
• Variables—Displays the variables and their assigned values that were in scope when the code that generated the selected log entry was run.
• Execution Overview—Displays statistics for the code being executed, including the execution time and heap size.

Log levels control how much detail is logged for each log category. The following levels are available in the Developer Console, from the least amount of data logged (level = NONE) to the most (level = FINEST).
NONE
ERROR
WARN
INFO
DEBUG
FINE
FINER
FINEST

Checkpoint Inspector
The Checkpoint Inspector has two tabs: Heap and Symbols.
Heap—Displays all objects present in memory at the line of code where your checkpoint was executed.
Symbols—Displays all symbols in memory in tree view.
Heap Tab
The Heap tab includes some great panels for debugging, like the Types panel. This panel shows how many objects were instantiated and the memory they consumed in bytes. Let’s look at the details captured by the checkpoint you set.

1. Under Types, click Messaging.SingleEmailMessage.
2. Under Instances, click any instance of this object type.
3. Under State, view the object’s fields and their values.

ERROR: Executing against the trigger does not work as expected
trigger ClosedOpportunityTrigger on Opportunity (after insert, after update) {
        List<Task> taskListToInsert = new List<Task>();

        for(Opportunity opp : [Select Id,StageName from Opportunity
                                  where Id in :Trigger.New AND StageName = 'Closed Won'])
        {
                taskListtoInsert.add(new Task(Subject ='Follow Up Test Task',WhatId = opp.Id));

        }

    if(taskListtoInsert.size()>0)
    {
        insert taskListtoInsert;
    }
}

Application Life Cycle Management:

Step 1: Plan Release
Start your customization or development project with a plan. Gather requirements and analyze them. Have your product manager (or equivalent) create design specifications and share them with the development team for implementation. Determine the various development and testing environments the team needs as the project progresses through the ALM cycle.
Step 2: Develop
Complete the work, following the design specifications. Perform the work in an environment containing a copy of the production org’s metadata, but with no production data. Develop on Lightning Platform using an appropriate combination of declarative tools (Process Builder, the Custom Object wizard, and others in the UI) and programmatic tools (Developer Console, Source Code Editor, the Force.com IDE, or Visual Studio Code).
Step 3: Test
Exercise the changes you’re making to check that they work as intended before you integrate them with other people’s work. Do your testing in the same type of environment as you used in the develop step, but keep your development and integrated testing environments separate. At this point, focus on testing your changes themselves, not on understanding how your changes affect other parts of the release or the app as a whole.
Step 4: Build Release
Aggregate all the assets you created or modified during the develop stage into a single release artifact: a logical bundle of customizations that you deploy to production. From this point on, focus on what you’re going to release, not on the contributions of individuals.
Step 5: Test Release
Test what you’re actually going to deploy, but test safely in a staging environment that mimics production as much as possible. Use a realistic amount of representative production data. Connect your test environments with all the external systems they need to mimic your production system’s integration points. Run full regression and final performance tests in this step. Test the release with a small set of experienced people who provide feedback (a technique called user-acceptance testing).
Step 6: Release
When you’ve completed your testing and met your quality benchmarks, you can deploy the customization to production. Train your employees and partners so they understand the changes. If a release has significant user impact, create a separate environment with realistic data for training users.