Chris Peterson

Hey uhh so strcmp() huh pretty simple I mean what could be simpler: 

Returns < 0 if str1 is less than str2; > 0 if str1 is greater than str2, and 0 if they are equal.

Pretty straightforward right how could this possibly be messed up it’s freaking strcmp either the strings are equal or they ain’t right

http://danuxx.blogspot.co.uk/2013/03/unauthorized-access-bypassing-php-strcmp.html

GODS FREAKING DARN IT ALL TO HECK.

This is why I hate you, PHP! This is why I consider you an unmitigated failure, a pox on the good name of programming! 

Dear language designer, pick one:

• A language with a very casual typing system;
• A language with standard API functions that cannot return an error indicating incompatible types were passed at runtime.

NOT BOTH. YOU CAN’T HAVE BOTH.

When I shared this on Twitter, legions of people showed up to say it was the programmer’s fault for using strcmp(). Riddle me this: is strcmp() part of the standard PHP API? Yes. Is it deprecated? No. Are there any caution notes in the official documentation? No. I don’t care how hard you try to blame the programmer, this is fundamentally bad language design. It’s a trap.

You can easily cut yourself on the standard API of many languages. The difference is that languages like C are labeled “sharp knife” and PHP is labeled “child-safe scissors.” Cutting yourself should not be this easy.

Dear sweet merciful angels I want to stab this language, twist the knife, yank out its still-beating heart and smash it against a rock.

 (╯°□°）╯︵ ┻━┻  0xabad1dea OUT.

Large Ext-JS applications can be structured using a range of libraries. I propose a method for installing these libraries in Salesforce. I cover development time, before the code is minified. I hope that moving to production minified code would be very easy. My working application has been a Google Map showing the UK Amateur Radio […]

Profiles remain an important and necessary tool for the administrator.  Beyond the requirement that every user is assigned to a single profile, certain user settings are available on profiles that are not available on permission sets.

Previous blogs discussed the ability of permission sets to simplify the administrator’s job as it pertains to assigning the appropriate permissions to the appropriate set of users.  There are some additional simplifications available to the administrator who fully leverages that capability in order to reduce the number of profiles within an organization.

It does not take too many job functions within an organization before the possible number of profiles grows quite large.  Beyond the challenge of administering each of these profiles, many screens related to object creation, field creation, page layouts, etc. become more difficult to manage as the number of profiles grows.  By reducing the number of profiles, the manageability of these screens improves.

Because profiles control more user settings than permission sets, it can be a challenge to eliminate some profiles simply because those user settings are important variations within the organization.  However, one user setting that is not available on permission sets, but can -- to a certain extent -- be controlled by permission sets is “Tab Settings.”  In order for a tab to be visible to a user, the tab must be available to the user (either “Visible” or “Available”) and the user must have at least read access on the object in question.  Profiles control the tab setting, but permission sets can control the object level access.  So, if you want your users to have the tab when they have access to the underlying object, you can set the profile to “Visible” (or off, as appropriate) without also defining on the profile any object level permissions for the object.  Then, any individual user’s ability to see the tab will be controlled by the permission sets assigned to them and whether those permission sets grant read access to the object in question.

A little while ago a developer I was working with found something undocumented in Apex. While it was a great find and very much what we needed at the time to achieve our goal to generically log errors from a Database.insert. Undocumented features can come back to bite you! For starters they are not supported and worse still can change without notice. I decided to raise a support case anyway, as it may have been a documentation oversight. The result is a few months later after a bit of testing, Salesforce have documented it and all is well! And whats more its available now!

This feature relates to an Apex class called Database.Error, used by the methods on the Database class. When performing DML operations (such as insert, update or delete for example) with a set of records the default behaviour is to fail the entire operation if any one of the records is in error .

In our case we wanted to allow valid records through and log errors for those that failed. Thus we passed false to the second parameter of the Database.insert method. The information we got back was useful but critically lacked the fields in error, leaving the user to decipher the field causing the error from the messages. The much needed getFields method returns a list of the field/s associated with the error message.

This method has now been documented, many thanks to Apex Product Manager Josh Kaplan and his team, enjoy!

List<Database.SaveResult> saveResults = Database.insert(recordsToInsert, false);
for(Database.SaveResult saveResult : saveResults)
{
    if(saveResult.isSuccess())
        continue;
    for(Database.Error err : saveResult.getErrors())
    {
        System.debug('The following error has occurred.');
        System.debug(err.getStatusCode() + ': ' + err.getMessage());
        System.debug('Fields in this error: ' + err.getFields());
    }
}

archive - contact - sexy exciting merchandise - cute - search - about
← previous	May 21st, 2013	next
May 21st, 2013: If you want the amazing T-Rex's Summer Vacation design on a tote bag or a hoodie, now is your last chance! TIME IS RUNNING OUT, Y'ALL: One year ago today: well i for one am giving up boo-berry muffins – Ryan

by komar

BLUF: you can use =, ==, or === for equality comparison operators in apex code.  It just depends on what you’re actually trying to compare.

I bet you knew that you can compare objects in apex by using the == operator.  What you may not have know is that you can also use the === operator. You can even use the = operator if you’re comparing equality in a SOQL statement.  You can read the docs here to get a full rundown of how these (and all other) operators work in apex.

Using the == operator (most common case)

I recently read Adam Purkiss’ blog post about Soft Asserts and I saw some code that I wasn’t sure how would perform.  He abstracted an assert method to just use objects and test for equality.  I worried that there might be some edge cases where it doesn’t have his expected behavior.  The answer is that, under most circumstances, he’s just fine.  I’ll demonstrate using the Contact object but this can be shown with any object, even custom objects.

Contact a = new Contact(FirstName='Test', LastName='Contact');
Contact b = new Contact(FirstName='Test', LastName='Contact');
System.assert(a==b);

According to the documentation, (here again) the == operator will evaluate all fields on an object to evaluate equality. Because of that, this code runs successfully.

The caution here is that if you were to insert those objects, Id is now a field on the object to be evaluated for equality and the assertion will fail:

Contact a = new Contact(FirstName='Test', LastName='Contact');
Contact b = new Contact(FirstName='Test', LastName='Contact');
insert a;
insert b;
System.assert(a==b);  // this fails (sad trombone sound)

Now, let’s look at comparing Strings.  In the following example, we can see that the == operator is case insensitive when comparing Strings.  This kind of blew my mind.  I had assumed string equality was case sensitive but just recently learned it isn’t.  Be careful when you compare strings and you want exact equality!

String a = 'Test';
String b = 'test';
System.assert(a==b);

Using the === operator

If you’ve ever written code in Java, you would expect the first Contact example shown to fail assertion because the == operator in Java is a reference evaluation (does the memory address of Contact a equal the memory address of Contact b?).  If you want to evaluate the equality of an object’s location in memory, use the === operator.

Let’s look at an example with the Contact object again. The assert will pass and you now have two objects pointing to the same location in memory. You could also do a System.Assert(a==b) and it would pass but that’s not the point of this section:

Contact a = new Contact(FirstName='Test', LastName='Contact');
insert a;
Contact b = a;
System.assert(a===b);

If you have any questions about what is happening when assigning Contact b to Contact a, check out this blog post for clarification.  For bonus points, you can also use !== to determine whether the memory address of an object does not equal the memory address of  another object.

Unfortunately, the === operator isn’t valid for primitive data types so we can’t look at an example with Strings.

Using the = operator (SOQL)

Last but not least, you can use the = operator when writing a SOQL (or SOSL) statement to compare equality.   Don’t use it anywhere else when comparing equality or it will be executed as an assignment operator.

Contact a = new Contact(FirstName='Test', LastName='Contact');
insert a;
Contact b = [SELECT Id, FirstName, LastName FROM Contact WHERE Id = :a.Id]; // = as an equality operator
System.assert(a==b);  // == as an equality operator
System.assert(a!==b);  // === (or its variant) as an equality operator

Your homework: Why does a!==b?

Your homework part 2: Is there ever a case where a===b but a!=b?

BlobConfig.config not found, said the error console of The Blob-- the "insane in every way" system Sep's company produced.

Because a millisecond earlier, The Blob erroneously determined Sep's computer already had a copy of the config file, and didn't automagically create it.

Because one second earlier, The Blob couldn't find the substring "No such file or directory" in the output of "ls -l %BlobDirectory%/BlobConfig.config"

Because five seconds earlier, Sep's local instance of The Blob issued that command to Sep's OS.

Because ten seconds earlier, The Blob (installed on localhost) connected via SSH to localhost

Because fifteen seconds earlier, The Blob ran an "cleverly" optimized routine to try to check for the existence of the system-critical config file.

Because five minutes earlier, Sep ran his local instance of The Blob for the first time.

Because thirty minutes earlier, Sep had configured everything on his brand new computer to his liking, except for the local instance of The Blob.

Because an hour earlier, Sep was assured by his coworker that The Blob would automagically configure itself on the new machine without intervention.

Because some years earlier, someone thought themselves clever enough to write the following optimization into The Blob's startup routine:

public void ConfigFileExistsOrCreate()
{

String result = null;
remoteCon = SSHConnection("localhost");
result = remoteCon.sendCmd("ls -l %BlobProfileDirectory%/BlobConfig.Config");

if (result.contains("No such file or directory"))
{

String fileContents = "smb://GlobalShared/UniversalBlobConfig.config";
remoteCon.putFile("BlobConfig.Config", fileContents, FileType.Link)

}
else
{

// no-op! File exists!

}

}

Because as clever as that person was for optimizing the creation of a static, 400 byte configuration file that itself was just a linkfile with a hard-coded path-- they weren't so clever as to remember the company was based in Switzerland.

Because hundreds of years earlier, French became one of the national languages of Switzerland: written, spoken, and more pertinently (and much later) available to select as a localizational language in Linux.

Which Sep had done.

ls: Impossible d'accéder à BlobConfig.Config: Aucun fichier ou dossier de ce type

Impossible, indeed.

Recently I was working on a prototype Force.com application for which I anticipated heavy use of Salesforce Approvals Processes. When testing my prototype, I found the record locking system with Approvals fell short of what I wanted – I needed to be able to lock specific fields rather than the record as a whole.

My Approvals Process made use of a “stage” pickist provided in the prototype App, and I realised that I could achieve what I wanted by using validation rules in conjunction with this stage field. However, the validation rules would be fairly complex, and not particularly easy to modify if the business requirements changed.

What I wanted was an easy way for users to configure field locking based on a stage / status field on a record, for any object type… LockingRules.

Prototype

So I set about building a LockingRules prototype which allows a user to first pick a field to be used to define the record’s stage (at the moment this must be either a picklist or checkbox), and then go on to specify how fields should be locked at each stage, using a simple checkbox grid.

The rules are enforced using triggers. All that’s needed is a one line trigger which invokes a general handler class, so its very easy to extend for unmanaged or managed-package custom objects.

The solution does not need to be used with Approvals of course – it can be used wherever you need selective locking based on records state.

You can find the full source code for LockingRules shared in a Github Repository, so you can embed it into your own projects if you so wish.

LockingRules Evaluation Packages

I have also produced a pair of beta managed packages for evaluation purposes – one package contains the LockingRules utility and an extension package contains an Opportunity trigger.

If Locking Rules were to be packaged as a standalone utility I would expect to package the triggers in extension packages, for example: “Locking Rules for CRM”, “Locking Rules for FinancialForce PSA“, “Locking Rules for FinancialForce Accounting” etc. I have followed this pattern for the evaluation packages. Here are the installation URLs:

LockingRules 1.1 (Beta 1)
LockingRules for CRM 1.0 (Beta 1)

Being beta packages, they can be installed only in developer or sandbox orgs. Naturally you need to install the main LockingRules package before the CRM extension package.

Configuration

A “Locking Rule Objects” custom setting (Setup | Develop | Custom Settings) is used to govern which objects can have rules. Use the “manage” option to add a custom setting record for each object you want to use with Locking Rules, entering the API name of the object as the custom setting name:

LockingRules can be used with standard objects (Product, Account, Opportunity), custom objects, or objects contained in managed packages.

If you specify an object belonging to a managed package then the namespace prefix must be entered all lower-case.

In addition to the custom setting, a simple trigger is also required to enforce the rule. The LockingRules for CRM evaluation package contains a sample Opportunity trigger. If you want to create LockingRules for other objects, you will need to create your own simple triggers to enforce the rules. For example, to enforce Locking Rules on Accounts you will need an Account trigger:

trigger AccountLockingRule on Account (after update)
{
   LockingRules.LockingRuleHandler.handleTrigger();
}

If it is more appropriate, you could of course invoke the handleTrigger method from an existing trigger.

The custom setting governs the UI for building the rules – whereas the triggers apply the rules to record updates.

Creating a Rule

Once the triggers are in place and custom settings are set up for each object that you want to work with LockingRules, a standard user can define and update the rules from the Locking Rules tab. Each rule is defined as a single record of the Locking Rule object. 

There can currently be only one rule for each object type.

Go to the Locking Rules tab, and click “New”. Pick the object type from the drop-down list. The drop-down list shows the label and API name of the available objects (as defined in the custom setting above).

Click “Continue” and then pick a state field from the drop-down list.

Field locking is dependent on the state of a record, and this is defined by the selection of a state field. You can pick any checkbox or picklist for your state field, from standard fields, custom fields, or managed fields:

For example, on Opportunity you could pick “Stage” for your state field – so that you could then lock different selections of fields at each Opportunity Stage.

For simpler scenarios, you might pick the “Closed” checkbox for your state field – if you simply want to lock down some of the fields when an Opportunity is closed.

Having chosen a state field, you are presented with a checkbox grid. States run across the page horizontally, and fields run down the page vertically. Only editable fields are listed.

A check in a box indicates that the field in that row will be locked when the record is in the state indicated in the column.

So, in this example, Opportunity Amount and Account will be locked when the Opportunity is closed:

If your state field is a picklist, then if a new value is subsequently added to the picklist – for example adding a new Opportunity Stage – then when returning to edit the Locking Rule, the new stage value will be added to the grid (all checkboxes for the new stage will be unchecked by default).

If you need to pick a different state field, click the “Reset” button. This will wipe out all your checkbox selections and allow you to choose a different state field.

When your checkbox selections are complete, click “Save”.

Rules in Operation

The rule will now apply to all changes to Opportunities. So, attempting to change the amount on a closed Opportunity will not now be allowed!

Under the hood…

Locking Rules are stored in a LockingRule object. This object has fields for the object API name, the state field API name, and a long text area field.

This long text area field is used to store the actual rule (the field locks) encoded in JSON. For example the sample Opportunity rule above would be stored as:

{"LockedFieldsByState":{"true":["Amount","AccountId"]}}

Actually in the original implementation the JSON looked very different from this. I derived the JSON structure to fit my UI, whereas ultimately what was needed was a structure which was designed to be efficient for the trigger – seeing as this would be executed much more frequently!

The UI for defining rules is Visualforce with a controller extension. This uses Apex Describes to find suitable state fields, and then editable fields which the user may want to lock. So, we can dynamically handle any object and lock any editable fields.

I translate the JSON to a list of a custom type in the controller (an inner class) on loading a rule, and translate back to JSON on save. It is then really easily to bind Visualforce controls to my list of this inner type.

As the JSON is designed to be efficient in the trigger, the trigger handler class is quite simple, whereas the controller has to do more work to map the UI to the JSON data.

Finally, the trigger handler class needs to be global because I intended not to implement the triggers in the same package, but in an extension package (or use unmanaged triggers).

Links

Evaluation beta package installation links:
LockingRules 1.1 (Beta 1)
LockingRules for CRM 1.0 (Beta 1)

LockingRules source code on Github

Apex Code Developer’s Guide – JSON Methods