This week I am doing #DEV450. I neeeed to learn more about coding. 

Like the other Salesforce courses I have attended, I don't expect to get much out of it, but as it's a topic I don't know a lot of, I do expect to get a lot out of it. It's a conundrum. 

It is a huge investment to take a week out of productive paying work to do learning, so I will have to do real work after hours for the week. 

At the same time as doing this course, I am doing David Liu's Pluralsight course, which has been great so far. 

Intro

What I expect to learn

• Enterprise Coding patterns - eg don't write code directly in triggers. 
• Callouts 
• @Future methods
• @Invokable
• Writing really good test classes. 
• A really good understanding of bulkification. 
• Custom REST Apex
• Getting data in and out of Salesforce via APIs
• Merging and sending emails by code
• How to string multiple transactional processes together
  • eg I have a business requirement to do 10 things in a specific order, with some of them optional or based on other criteria. 
• How to use the debugger well
• How to use Developer Console well
• Tricks for coding in MavensMate
• Proper reuse of code. 
• Maps vs Lists and when and why to use them. 

What I will probably be expected to learn

• How to write simple triggers that can now be done in process builder or flow. 
• How to write simple flows - which I know how to do. 
• What is a variable - which I know. 
• Using Eclipse - I don't want to install Eclipse on my new PC. 
• How to "get around" writing test classes.
• How to pass the exam - I don't particularly want to take the exam. 
• Simple visualforce pages - I don't expect to learn to write a full Lightning component, but I do hope it is way more than a simple VF page. 
• Fundamentals of OO programming - which I know. Plus you just have to read Kieren's article to understand the basics. 

What I am sure I won't learn

• Lightning components
• Lightning Design System
• Javascript remoting

Diary

What the course covers

• Day 1
  • Half day on declarative programming - probably not enough. And boring. But you have to do it. 
    • Started building objects from the Schema Builder. 
      • I did not know that Schema Builder skips the permissions and page layouts sections. 
      • So this is actually good! It defaults to all users and not on the page layouts. 
      • See, you learn something every day. 
  • SOQL
  • DML
  • OOE
  • Visualforce Pages
• Day 2
  • SOQL
  • Beginning Code
  • DML
  • Some Best Practices

Who should take this course

I really really think this course is only suitable for those that have a really good understanding of Salesforce from an Admin or Consulting background first. I think you need a thorough understanding of the things work in Salesforce. Especially permissions and when to use Code and not. 

You MAY be able to get by if you are a shit-hot programmer with experience in many different languages, but "check your knowledge at the door" and don't think that SQOL is exactly like SQL and don't complain that things don't work the same way as they do in X language. Understand how the multitenanted database works and why the limitations are in place, and argue from a good basis. 

Yes, there are really shitty things in Salesforce, but know enough to be able to defend them to start criticising them. (in most cases). 

Day 1 Thoughts

It's so slow to get going. To have to go through permissions, OWDs, Record Types etc. It's like they are just covering those things because the code they are writing later on touches those areas, but it is presented without enough business context.

When we finally get to code, we are copying and pasting code. I hate hate copy and pasting code. Again, it is like learning by rote rather than really understanding the way things really work. But there is only 5 days to get through stuff and we are starting from less than zero, so you have to catch up somewhere.  

This is definitely NOT a course for the uninitiated developer, you do need to be fluent in your dev language - eg know what compile, initialize, method, type, etc words mean. 

Then at 4.20pm it starts going into real code where you are just copying and pasting and not understanding where you are going or what you are doing. Mind. Blown. Not in a good way. From being completely slow and boring to completely not understood in the space of 20mins. This is not good. 

Yep! Of course. Exactly what I said. The first coding structure we write can be dealt with in standard setup now. Checking Duplicates. But thankfully the instructor told me of a scenario where you will need to code deduping - deduping on two lookups. (But I still worked out a way you can do that within setup using a SteveMo trick of concatenating two values together and setting uniqueness on that. 

Day 2 Thoughts

Today was much easier to cope with because I understand SOQL quite well. Still learnt a few things though - like a 5 level limit up the parent chain for Apex whereas it's 10 in formulas.

The coding bit started quite slowly which is good, and the TODO items in the examples were writen in such a way that I could work out what was needed with a bit of checking on the previous examples. I'm not convinced I have taken it all in. But I am at least a bit more comfortable with using Lists. 

One cool thing I learnt today is AllOrNone as I had come across that last week in a Flow Error message, and wondered what exactly it was. Now I know. 

What we didn't Learn

I still need to know these things right now, and I still think even a beginning developer needs to know these things. 

• Callouts and their limitations
• Really in-depth on how to use the debug log
• How to use the other tools - is Developer console the best tool to do debugging and looking at test coverage? 
• Interfaces (it was touched on, but not enough for me to understand them).
• Implements eg Class A implements Class B
• Calling a Flow from Apex (this post is great though Calling Flow from Apex). 
• Email handling
• Just how to integrate a simple controller into a Visualforce Email

Things I know but needed to be covered in DEV450

• All of the APIs and what they do and when to use them

Outcomes

So regardless of the issues I have with this course, and that I don't feel I can code (YET), I have had some good outcomes. 

• More understanding of the Developer Console
• How to look at test coverage for some custom code
• How to filter logs to look at only debug statements or specific text
• I took a piece of code written for one Apex REST API and cloned it to work for another API call, including the Test Class. 
  • Only had to ask two questions. 
• Successfully debugged an issue in production by reading the code, adding some extra debug statements, then looking up StackExchange for the answer. 
• I now know what Lists and Maps are doing when I read code. This is huge! 
• I was able to understand how and why the developer had built a mocking class to simulate a HTTP Response. 
• I had asked the developer to do some modifications to some code, then thought about it overnight and found a simpler way to do it that did not require a new custom setting - thinking like a developer! 

Concepts

List Set Map

• Collections
• List is Ordered index, Set is Unordered
• List can contain duplicates, Set can not
• Map is like a Key Value pair. Key has to be unique. 

Looping

• Traditional for (looping though then ++)
• List or set interation - (for set...)
• Iterate over SOQL result. 

Data Types

Blob, Boolean, String, Integer etc

All variables are initialised to null. So you always need to check for null values

== vs ===

== is Equality 'A' = 'B' (false). Used for comparing strings (eg recordIDs) 

=== is Memory reference the same - It is a true coding memory thing - eg a=1; b=a; b===a is true. 

Contains is == 

Triggers

• Insert
• Update
• Delete 
• Undelete

Governor Limits vs Platform Limits

Platform limits are things like 500 fields in an object, workflow limits. 

Governor limits are limits to make sure your apex code doesn't run away with server resources. 

SObject

Data in memory is also known as an SObject. (doesn't quite make sense yet). 

An SObject is the Metadata of an Object. 

Syntax

public void UpdateLocation(List<Course_Delivery__c> deliveriesToCheck) {

• Void means it returns nothing
• UpdateLocation is the name of the method
• List<Course_Delivery__c> is the Type - similar to defining a parameter of type "String" but this is a list. 
• deliveriesToCheck is the variable name of the list. 

<> encloses an parameter for a Collection. 

[  ] encloses SOQL

SOQL vs SQL

• No Select * from
• No DML statements - query only. 

Parent to Child Relationships - lookup the Child object, then the field to the Parent object then find the Child Relationship Name, and add __r onto the end. The instructor told the students it was "always plural of the object name", but that is not correct. I often rename my relationship names - especially to get rid of the underscores. So know where to find it in the database. 

SOQL in Apex

• Use bracket notation eg [Select ID from Contact]; or System.Database('String of query'); 
• System.database is used if dynamically building a SOQL statement. 
• System.database is not checked at compile time. 
• Always return to a List.