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

Thursday, December 18, 2014

KIFS - A New Software Development Paradigm

KIFS Logo
KIFS is a new software development paradigm or philosophy that emphasizes simplicity above all other factors.
KIFS is an acronym for Keep It Freakishly Simple.

Introduction
KIFS is not enumerable or objective.  It is sensitive to the context with which it is to be applied.  It is similar to the KISS philosophy but more specific. The goal of any software project developed using KIFS is simplicity in all aspects without affecting intended functionality.

KIFS is not exclusionary.  It may be used within the user interface where something large, overbearing and wasteful like an MVC design pattern can be used for other aspects of a particular project.  KIFS is there to help when needed.

Some advantages of KIFS are...

Saturday, November 22, 2014

Brain What???

Many years ago as a hobby I collected computer languages.  I would be up all hours of the night downloading source code, reviewing documentation or trying to contact programmers involved with defunct languages.

Well, I saw the name of this language and had to laugh...  BrainFuck

Apparently this is an older language and, well, a very simple one.  The word terse simply does not do it justice.  Take a look at the above link to it's Wikipedia page.  Just WOW :-)

Wednesday, November 12, 2014

Z80 Blast From The Past

A few weeks ago while putting things away for winter; an 'autumn cleaning' if you will, I found my old project computer notebook from the late 1980's.  In it were notes and plans and photo-copies of more than enough information to build my own Z8000 computer.  Back then, my personal projects were based more on 'coolness' than having a purpose.  Ahhhh the good old days.

This morning I was poking around on the internet and what do I find???  A military paper on 256 Z80 autonomous computers clustered into a single highly parallel computer called ZMOB.

ZMOB had more of a conceptual point of origin rather than a purpose: "The ZMOB idea sprang originally from needs of the Computer Vision Lab at Maryland."  Ahhh...  To build something for the simple sake of building it.

Monday, November 10, 2014

C# Programming Tip - ViewState

A C# page's ViewState is a real cool place to put state information and variables you want to stick around for the lifetime of a web page.  Actually, most ASP page components save their state information in the ViewState.

Saving stuff in the ViewState is easy.  Here is an example:

ViewState["mode"] = "A"

Accessing it is easy as well:

if (ViewState["mode"].ToString() == "A") {...}

You can also do cool things like put more complex items in the ViewState like:

SomeComplexClass ComplexObject = new SomeComplexClass();
...
ViewState["ComplexObjectVS"] = ComplexObject;
...
SomeComplexClass ComplexObjectCopy = (SomeComplexClass)ViewState["ComplexObjectVS"];


So long as the object is seralizable (more on that later), you can save it in the ViewState.  There is a big drawback... space and bandwidth.  A page's ViewState is stored in the page!  So, each time the page loads, is posted or there is a postback, the entire ViewState is sent over the network.  If you want to maximize the efficiency of your page, minimize your ViewState usage.  The size of a ViewState can grow quickly if you have a large and/or complex page.

Also...  ViewStates are NOT secure.  With enough smarts a person can decode them, so don't put anything in the ViewState that you want to keep secure.

For those curious, here is what a simple ViewState looks like in a simple page:
<input id="__VIEWSTATE" name="__VIEWSTATE" type="hidden" value="/wEPDwUJNzkzMjk1ODg4D2QWAmYPZBYCAgEPZBYCAgsPDxYCHgRUZXh0BQgxLjAoZGV2KWRkGAEFHl9fQ29udHJvbHNSZXF1aXJlUG9zdEJhY2tLZXlfXxYBBSZjdGwwMCRNYWluQ29udGVudCRMb2dpblVzZXIkUmVtZW1iZXJNZbVBilGyAMpTuiSmFozdPPwfgNyhxhHXWwhU4O2NRdBd" />

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.