Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Thursday, October 30, 2014

Argument for High-Tech Sabbaticals

This high-tech professional life is damned dynamic.  Stand in the same place too long and before you know it, high school graduates are able to out-geek you in nearly every aspect.  Staying current with technology is difficult at best.  The high-tech professional must balance life, work and education...  forever!  Yes, for those wanting to get into a high-tech career, take a little note from the CrazyOldProgrammer...  continual education is key to maintain relevancy in this insane world that melds hard technology, creativity and art.

Doctors, lawyers, scientists and college professors all have sabbaticals.  Why not high-tech professionals?  Seriously.  the world of medical science, law, sciences and education is quite dynamic.  So is the world of the high-tech professional.

So why shouldn't we have sabbaticals?  Seriously?  I spent nearly a year developing an internal data management package.  About 25% of that time was spent maintaining existing production code, about 15% was spent performing standard maintenance and performing administrative tasks.  60% was spent in heads-down development, testing and development.  No training, no mucking around with my own extracurricular code, very little surfing software development and data management forums I typically frequent.

Sure, vacations help us chill out and unwind.  But a sabbatical for a year...  six months...  3 months...  hell, a two week sabbatical where I could go nuts.  Mess around with any language or OS or platform.  Maybe take a formal & directed mini-class.  Something that I want to explore within my professional field, not something I must explore in the course of my employment.  Something to help keep that spark alive, at least until retirement.

Sabbaticals for high-tech professionals.  The time has come, oh yes it has.


Monday, October 20, 2014

No NULL exception? What the Hell???

Just a little end of the day rant about one of my least favorite software packages, Salesforce.

If I do something like this, shouldn't there be a NULL exception?

integer bar = null;
integer foo = 1;
foo = bar + foo;


Absolutely.  And Salesforce's APEX language does indeed raise a NULL Exception.  However, a little different flavor of that will not raise an exception.

Say for example you have an integer field called bar__c in the standard Salesforce object Lead.  You have a piece of code that pulls that object's record into memory; like...

Lead wrkLead = [select ID, bar__c from lead where status='Lock' limit 1];


So, shouldn't there be a NULL exception here?

integer foo = 1;
foo = wrkLead.bar__c + foo;


Well, I would think so, but nope.  APEX just keeps on chugging.  Watch out for this one.  If your data field could ever be NULL, code for it!

Friday, October 17, 2014

Salesforce DML Limit... ARGH!

ARGH
So there I am...  5AM on a Friday morning and I check a Salesforce task that should have run hours ago.   Thunk Thunk Thunk...  Is this thing ON???   Apparently not.

I run it manually and THWACK...  " Too many DML statements: 151"  After an hour of Googling and poking at the execution log the reason for this THWACK is obvious.  This Salesforce job was updating leads within a loop.  That's OK if the loop makes less than 150 iterations.  Shit...  This loop was trying to update thousands of leads.

The solution?  Pfff...  Rather than update each individual lead I need to change the code to place my updates in a List<Lead> and then, after the loop, updating the List.

What the Hell?!?!?  It worked in the dev Sandbox fine, just the way it was!  This is like taking a hot sports car out for a test drive, turning heads while driving 95 MPH down the freeway, feverishly buying the thing, then, once you are sitting in this testicular expression of your manhood, discovering it will only do 65MPH.

The specific lesson here is this...  When writing a Salesforce job (or anything for that matter) in APEX, DO NOT update table data within a loop.

Now leave me alone.  I gotta go rewrite this damned APEX job.

***Edited Oct 17, 2014 - 3PM***
Fine.  Just Effin Fine.  I found out why it worked in the sandbox.  Another programmer meant to refresh his leads in the sandbox while I was testing.  Guess what...  He refreshed my test data as well.  So, even if the 150 DML Limit works in the Sandbox, my testing wouldn't have caused a problem because there was only 50 leads in the damned Lead table!!!

New version is done and tested.  Guess I will get up before the dogs Monday and roll this out.