Trapdoor In The Sun

Alan Shanahan, Technician & Consultant


2 Comments

Force.com: Apex Styleguide, Part 3

Click here for Part 1 of this series.
Click here for Part 2 of this series.

Here, I’m going to take a look at the condition part of the if statement. In particular, how best to write a complex condition to allow for readability and easy code maintenance. Sometimes even just a small number of ANDs and ORs can be easy to write but difficult to untangle later. Add in some brackets for changes in operator priority and the picture becomes even worse. I will refrain from filling up this post with words because I think the example below will provide most of the colour and information I’m trying to impart on the topic.

if (conditionA || (conditionB && conditionC) || (conditionD || conditionE)) {
  doSomething();
}

Figure 1, above, equates to the following:

if A OR (B AND C) OR (D OR E) then do something

When you substitute the conditions for real-world variables, function/method calls or complex structure sub-fields, the results can be less than legible. But, apply a little indentation and split your conditions up and you suddenly have some clarity.

if (
       conditionA
       ||
       (
           conditionB
           &&
           conditionC
       )
       ||
       (
           conditionD
           ||
           conditionE
       )
   ) {
  doSomething();
}

Figure 2, above, is functionally identical to Figure 1. Do you think it’s more readable? Easier to maintain?

A little tip for those engaged in writing complex Force.com custom formula fields with if statements: try using the same method .

Advertisements


Leave a comment

The Transition To Force.com Developer

This is aimed at Java and C# developers who want to move into cloud computing and create demand for their skills.

One thing I regard as vital is to constantly keep an eye on your career progression. My aim is to make myself just that little bit more employable every year. It’s tough to combine this with a busy work schedule, but just because it’s tough doesn’t mean it’s not worthwhile.

The last year has seen huge growth and even bigger projections for the future of Cloud Computing. The trends are all upward, there’s no doubt. Gartner’s recent report states that the areas of “social, mobile, big data and cloud” will experience growth as they are championed by new IT leaders. Forrester predicts patterns of growth that are also encouraging. Most pundits and industry commentators agree and many of the big players are positioning themselves along these lines.

Along with explosive sales in mobile and tablet devices, it’s clear that mobile applications (particularly those that are cloud-based) will feature strongly in a global IT context for some time to come.

Add social media to the mix and it’s clear that Salesforce.com (with its Force.com platform) has its bases well and truly covered. They’ve got Chatter; Facebook and Twitter integration is covered; Touch is their technology stack for mobile; mobile apps proliferate.

And at their heart SFDC are “Cloud”. They are pioneers in the arena, that’s an undisputed fact.

Getting down to nuts and bolts, if you’re a developer with Java or C# skills, there’s a definite path you can take to sharpen your skills to become a certified Force.com developer. If you have designs on such a career path, my advice would be to follow these lists:

Application & Configuration Skills:

  • Get yourself trained up on the (Sales Force Automation) SFA application and, optionally, get yourself a certification
  • Understand what Account, Contact, Opportunity, Pricebook, Product, Case, Lead are, and what they do
  • Understand how to use Reports & Dashboards
  • Preferably, attend at least one of the Salesforce Administrator courses
  • Learn how to configure custom objects, custom fields, page layouts, field sets, formula fields, validation rules, custom buttons & links
  • Learn about Security, Roles & Profiles, field-level security
  • Get acquainted with Workflow and Approvals, what they are, what they can do
  • Learn how to import data with the Data Import Wizard

Technical & Coding Skills:

  • Sign up for a free SFDC Developer org
  • Learn about coding on the Force.com platform: Apex Triggers & Classes, VisualForce, Components, Custom Settings, Custom Labels, Resources
  • Understand what Force.com Governor Limits are, how to apply them
  • Learn what SFDC API usage limits are and understand how they may affect any application you design
  • Learn the new coding paradigms for bulk processing (a large topic but here’s a useful starter blog post)
  • Understand Lists, Maps, Sets and when to use them to handle batches of data
  • Understand Test Classes & methods
  • Learn about Apex Batch and Scheduled jobs
  • Learn how to use the SFDC SOAP and REST APIs and Workflow Outbound Messaging options
  • Learn how to extend the API with your own custom web services
  • Understand how to process inbound emails in Apex
  • Use Eclipse and the Force.com plugin to maintain Apex & Visualforce code and to examine the database schema
  • Learn how to debug code and troubleshoot using the various tools on the Force.com platform
  • Understand all the places (or “hooks”) where you can plug into the SFDC application to customise it
  • Gain at least a cursory understanding of SControls (deprecated functionality) in case you need to modernise or maintain old applications
  • Understand how to use the Apex Data Loader
  • To help you on your way with the above, here is a link to all SFDC documentation (pay special attention to the Apex and Visualforce reference docs)

You can also take your existing skills with you, and these will be invaluable:

  • Database and application design skills
  • Data Migration skills
  • Data Integration knowledge
  • Service-Oriented Architecture (SOA) and web service knowledge
  • Industry vertical expertise
  • Test-Driven Development (TDD) strategies
  • Source code version control tools and techniques
  • Multi-developer, multi work-stream development
  • Application testing strategies & methods

You can acquire all the training resources you need with little or no cost, but you can also accelerate your ramp-up time by attending SFDC formal training courses.

Anecdotal evidence would suggest that there are at least some Java developers out there who have a reluctance to extend their knowledge into the Force.com arena, primarily because of the more restricted nature of the environment. However, if you take the plunge, the rewards are there for the taking and you’ll join a growing army of technicians with niche skills.

Don’t be too quick to assume, however, that because you can instantly read Apex code (which a Java or C/Whatever coder can), your transition will be instant – there’s a little more to it than that. Most who took that path with that outlook fell foul of platform differences, a.k.a. the famed Governor Limits. But, learning the How, When and Why of these limits will help get you to the next stage in the transition process.

Acronyms used above:

  • SFDC = SalesForceDotCom
  • API = Application Programming Interface
  • SOA = Service-Oriented Architecture
  • SOAP = Simple Object Access Protocol
  • REST = Representational State Transfer
  • TDD = Test-Driven Development


1 Comment

Auditable Programming

Developers use debugging tools to look at the internal workings of their creations every day. One of the most useful debugging function is the ability to peer inside the contents of variables at strategic points in a program’s execution to see whether it’s behaving as expected. This is the use of a technical tool for a technical purpose. But why couldn’t we use that same concept to build better software; to give end users a peek inside the internals of the programs we write?

In the case of a complex set of calculations or decisions, this can really reap benefits. Let’s take the example of a custom discount calculation, and assume the following:

  • There are 5 different discounts that can apply to a customer order
  • Some discounts are mutually-exclusive
  • All discounts have limits that will be applied if appropriate
  • All conditions have a specific set of conditions that determine whether they are applicable
  • Some discounts require approval from a senior manager
  • Discounts above predefined threshold amounts and order percentages require approval
  • Some products do not qualify for discounts
  • Discounts can arise from a customer account, at order level or at product level

Looking at this list of preconditions, or business rules, it’s not hard to see that the internal workings of a discount calculation program can be quite complex. Consider also that you, as a developer, will need to write the code to implement these rules. You will have to debug the code and test it thoroughly. You will also have to gain customer acceptance that he is satisfied that everything works.

How can you make that last thing easier to achieve? By letting the end user peer inside the process through all stages. Let’s break this down further.

All programmed components have three simple components: input, process and output. The input to a process might be the customer record, with its associated 12.5% discount field. Another input would be a product line on an order, and its associated total amount field. The processing would be a multiplication of the line total by the discount percentage, but there might also be a decision point whereby the program checks that the product allows discount; the “Allow Discount” flag on the product would, therefore, be another input. And the output would simply be the amount of discount.

Now, let’s say we created a large text field on the order that we would use to accumulate text output to give the end user the visibility I mentioned earlier, for example:


Customer Information:
---------------------
Account "Smith And Sons" qualifies for a 12.5% on all applicable products.
Sales Discount of EUR 100.00 has been applied to this order by User: John Smith

------------
Order Lines:
------------
Processing line 1 of the order:
Product Code "ABC123", Description "Widget 123", discount IS applicable.
Order Line Total is EUR 2,500.00, Discount is EUR 312.50, Discounted Line Total is EUR 2,187.50

Processing line 2 of the order:
Product Code "XYZ001", Description "Widget 001", discount IS NOT applicable.
Order Line Total is EUR 5,000.00

--------------
Order Summary:
--------------
Order List Price Total is EUR 7,500.00
Total Order Discount Amount is EUR 412.50

----------
Approvals:
----------
Sales Discount is below the threshold level of 10% of the Order List Price Total. No approval is required.
Total Order Discount is 18.18% of Order List Price Total. Approval required because this exceeds the threshold value of 16%.

The key point to take from this is the enormous value that this text brings to the application, especially to the end user. It is valuable to anyone testing the application too, because it really is a debugging log; but it is presented in a plain-English manner.

This strategy will not hurt you when it comes to quality. Bottom line, it’s about programming for the user, not for the programmer.


Leave a comment

Techie Poll: Code Comments Misspellings & Bad Grammar

As a picky, petty pedant, this is a topic near and dear to me. The question also applies to field names, method and class names and any other symbolic placeholder names in program code.

Question: “What do you think of misspellings and bad grammar in code comments, field names, method and class names?

Your comments are welcome, as always. It doesn’t have to stop at a poll, it’s worthy of discussion.


Leave a comment

Developer Maturity

Thirty-odd years ago, I wrote my first lines of BASIC code on an Apple II computer donated to my secondary school by some local businesses. We were the first of our school and, to some degree, our generation to have access to such a device. I was hooked from the word go. All these years and a few dozen jobs later, I can tell you I’ve seen the full spectrum of good and bad in the world of programming; I may even have contributed to the bad side, but I live in hope that most of what I produced was leaning towards the better side of things.

But I can see definite steps in my progression in those intervening years; let me focus on programming itself, or “development” as the industry likes to call it. Today, I have a very different mindset to that of my teen years. My young naive self revelled in the idea that you could type an arbitrary set of instructions into a machine and it could do the most marvellous things. Coding was an end in itself! It existed just so that beautiful programs could be written and run. I had a lot to learn.

Then I started working in the real world. My programs were now being used by real people, in a real business, every day. There was a huge amount of job satisfaction in that idea. Everything changed. My “hobby” was now something to take seriously and it had to perform to a new standard. But I didn’t fully realise that and I still saw programming as an isolated pursuit with its own intrinsic value; in my mind it was a primary activity with its own purpose rather than an enabler. This illustrated an immaturity in terms of my business viewpoint.

Many years later, I’ve managed programmers and development teams. Still doing that. I’ve designing solutions for customers that are implemented by these teams. I’ve seen and reviewed a lot of code. In that sea of code, the full spectrum of quality exists. Some bad practices can have a subjective slant to them, but other bad practices are just plain bad. I’ll tackle the subject of quality later, it’s just too big to even contemplate here. But one point on quality is worth reiterating here and now: quality is everyone’s responsibility. I won’t explain that further, I believe the words do that for themselves. You own quality. You own problems created by your programs, no matter how trivial. At least to some extent. You owe it to your team to properly ring fence and test scenarios your programs are supposed to handle. You owe it to the customers who are paying for your development efforts.

And what I have seen is a set of behaviour patterns that seem to be repeating.

Firstly, there is an obvious disconnect between some programmers and the end user they are programming for. Think about users. Someone will sit in front of a screen and use your programs. They are real people, no matter how distant they are, or how imaginary they seem.

Another misalignment I’ve seen is that some programmers don’t conceive that data represents real world things. Financial data represents money, real money, not imaginary money. This is important to customers. It’s their money, the life blood of their business, which would simply curl up and die without it.

Polish! Polish your code. Polish the user interface. Try to break your programs. Keep trying until they no longer break.

Open your mind. Let go. Don’t be afraid to rework what you’ve written. The best writers and authors do this regularly; that’s why they’re the best. Coding is not an end in itself, it’s a means to an end: the business aim is the end. Code is just an enabler.

Do these things…

…and you’ll be all grown up.

[Note: I’ve emphasised “some programmers” in this piece. I’ve worked and continue to work with many superb developers. It’s worth mentioning.]