As you’ve probably noticed my name is Simon Goodyear and I have a passion for technology; not just computers and programming but for most things electronic.

  • The Force.com Platform...

    Join in me in pushing it a bit further

Missing Name Field on Person Accounts
Jan 8, 2014  |   SalesForce  |   No Comments

Missing Name Field on Person Accounts

Person Accounts are loved the world over and their foibles are well documented. However I struggled to find any particular reference to this little gem and as a form of therapy and to serve as a remind for future generations I find myself duty bound to make a note of it.

For some reason the Name field for a Person Account object is not provided in the Trigger.new and Trigger.old collections. I appreciate that this field is an almalgmation of the FirstName and LastName of the related contact but it seems inconsistent to drop the field completely from the object in this one circumstance.

Deprecation
Jan 6, 2014  |   SalesForce  |   No Comments

Deprecation

A New year is upon us and last year’s Dreamforce is all but a distant memory to most of us. I learnt a lot and had a great time but I don’t want to dwell on that too much. Instead I want to answer a question that I was asked in my Designing APIs session that I couldn’t provide a good enough answer to at the time.

The question was around how to deal with versioning an Apex API in a managed package. My advice at the time was to try to not have to version things. And whilst I stand by this it wasn’t particularly helpful; there are obviously going to be times when you have to make changes, breaking changes that mean you need to completely remove methods from your code. So how does this work in Apex?

Develop For Your Admins
Nov 12, 2013  |   SalesForce  |   No Comments

Develop For Your Admins

I was having a conversation over lunch a few days ago when I was asked “what originally drove you to Salesforce?”. I surprised myself a little with the answer: It was how quickly I could make changes to the system – how quickly I could take a business process and free it from the shackles of spreadsheets and post-its and turn it into a fantastic, computerised, cloud based system. This impressed people around me too, in particular business owners, I got sucked deeper into the rabbit hole and the rest is, as they say, history.

It was the “Clicks Not Code” that actually won me over. Obviously I went on to get a deeper understanding of the platform and how to develop on it, but in the first place it was the declarative nature of things that drew me in. And I know that I am not alone in this fact, in fact this is one of the real powers of Salesforce and something that developers forget all too easily.

Currency Is Case Sensitive
Nov 1, 2013  |   SalesForce  |   No Comments

Currency Is Case Sensitive

Every day is a school day, or so the saying goes. And today has once again lived up to that adage.

I have been creating a webhook to allow me to load invoice data into a mutli-currency enabled org. I have dealt many times with multi-currency orgs and have never had any problems with them. However today that was not the case. I knew that to set the currency of a record to something other than the org default you need to set the CurrencyISOCode to the ISO Currency Code for the currency that you wish to use. Until this afternoon this was the limit of my knowledge on the subject, however that quickly changed when I found myself receiving the DMLException: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST

The values in a normal picklist are case insensitive; that is, if the values available in the picklist are: A, B and C and I insert a the when I query the data I will find that the record has been inserted as A – brilliant, it’s a consistent behaviour and better than that a lenient behaviour which helps to drive data consistency.

From Catching Unhandled Exceptions to Expanding Your Knowledge
Oct 8, 2013  |   SalesForce  |   No Comments

From Catching Unhandled Exceptions to Expanding Your Knowledge

Unhandled exceptions from managed packages cause emails to be sent back to a specific user that was defined when the package was initially uploaded. These exceptions are important if you want to understand how your application is really being used and more importantly how it’s going wrong. Because whilst it is possible to instrument the internals of a managed package you just can’t catch all of those exceptions all of the time.

The trouble is that emails aren’t the best media in the world for receiving this information – it’s likely to sit wastefully in an inbox or even spam box and never really be seen, inspected or even cared about. The most logical thing to do with these exception reports in my eyes was to send them towards a Salesforce email service and have them appear in the LMA against the licence that caused the exception to be thrown in the first place. At least this way they may still go unnoticed but at least they’re stored in a sensible place and with some context against them.

All decimals are equal, but some decimals are more equal than others
Jun 18, 2013  |   SalesForce  |   1 Comment

All decimals are equal, but some decimals are more equal than others

I learnt something rather intriguing today on the old Force.com platform: decimals just don’t behave how I expected them to when converting them to strings. I have obviously set myself up with that line but nevertheless let me go through the motions.

Before today I would have expected the following code to display the same three strings on each of the lines.


Generating Hashcodes
Dec 17, 2012  |   SalesForce  |   1 Comment

Generating Hashcodes

I was quite excited by the introduction of the hashCode and equals methods to custom classes in Winter ’13, as I was finally going to be able to get a map to behave the way that I wanted it to. I started to write such a map and a post to go with it when I started to discover a few, shall we say, nuances about what was necessary to implement these methods – in particular the hashCode one. I will follow up with my magic map post but for the meantime I want to discuss the implementation of hashCode method.

I never studied computer science, or indeed maths in enough depth to know the intricacies of hash codes but I know enough to know that good hashing methods are hard to come by and potentially are computationally expensive. Given both of these facts I came up with a cunning plan when I was designing my hashCode method, in fact it was more cunning than a… never mind. My plan was thus:

First of all I would create a string representation of my object by making use of the JSON serializer and once I had this string I would simply call it’s hashCode() method.

Handling Optional Platform Features From APEX
Nov 15, 2012  |   SalesForce  |   No Comments

Handling Optional Platform Features From APEX

Over the past few weeks I have been getting a few requests from some of our customers to add a feature to one of our products; some minor integration with Chatter. Being a company that prides ourselves on being responsive to our customers wants (once a little common sense has been applied of course) we decided to add said feature.

The feature itself was trivial to implement but what struck me as I was thinking about it was: “what about our customers without Chatter enabled?” I know it’s becoming less and less common these days but back when we were consulting full time we heard numerous clients ask us to make sure Chatter was turned off – and no amount marketing material was going to convince them to turn it on. With this in mind I was suddenly a lot less bullish about this new feature – I didn’t want to alienate a whole section of our potential market just for this feature.

Accessing Record Types Consistently
Sep 14, 2012  |   SalesForce  |   No Comments

Accessing Record Types Consistently

Reading other people’s code is great, be it good or bad, functioning or broken there is always something to discover – and generally it is something that makes you think: “d’oh, why didn’t I see that before?”

I liked my latest discovery so much that I thought I’d share it myself for those, like me, that just hadn’t thought of it or indeed seen it elsewhere.

Record Types are the subject. We are all aware of the complications that record types bring to Apex; often you will want to perform a different action in your code depending on the type of record that you have. Or you’ll want to get a value from one field for one record type but from another for the rest. That’s cool and it makes sense but how do you write the code to do that? Hard coding the record type id is a common practice and it just about works, so long as you have declared the record types in your production org as the ids stay the same when you create sandboxes. However things don’t normally happen this way. Often a developer will create a new record type in her sandbox and make use of it there but when you move between environments this code breaks as the record type doesn’t exist and if you create it the id will be different; try running CI in an environment like this! Another problem I see with this method is that, even if the ids are consistent between environments the code is fairly meaningless: what exactly is id 00D123…..? So much for self documenting code, eh?

Aug 8, 2012  |   Rypple  |   No Comments

An unusual use case for Rypple?

A slight departure from my normally technical posts to give me a chance to get a random thought off my chest.

Rypple is doing it’s best to revolutionize the way in which staff and teams are managed and it seems to be a great tool to do it wit. However lately I’ve been wondering about how it might be applicable is less obvious situations.

I’m going to preface the rest of this post with the admission that I’m basing everything that I write here on a vague understanding (a demo and a brief play) of Rypple. And that I only really have indirect experience of the education sector (I went to school, I worked in a school for a year and my wife is a teacher). Therefore all of this might already exist or be complete rubbish.