Truth and Trust.

For a moment, I'm going to move away from the usual posts about programming or math.

Recently, I came across the thought of how important trust is. Most people I've encountered tend to place it at the top of their list of people requirements. That is, generally, above all else, people want their friend, co-worker, family member, or significant other to be a "trustworthy person". 

For the most part, I agree with this sentiment. Like many people, I might try to avoid those who are dishonest more often than not; however, I feel like this isn't the most important feature of the person being evaluated. Rather, I think there is a category of trust that is often overlooked - reliability. It may be essential to quickly describe what truth is before we can say someone is truthful and therefore, trustworthy.

The first step is to break truth into categories. By categorizing truth, what we are really doing is defining it. This, while sounding obvious, is where I think most people tend to make a mistake in their assessment. We must avoid mixing the subsets; simply, we cannot make the mistake of assuming that one subset of truth has an intersection with another subset.

We can start by splitting truth up into two categories:
1. Subjective truth - truth that pertains to an individual, group, or species.
2. Objective truth - truth that revolves around existence; a verified or indisputable fact.
From here, I want to split subjective truth into two categories:
1a. Established truth - truth that is based on set events particular to the subject
1b. Dependent truth - truth that is dependent on perceptions or future events particular to the subject

Let's continue with some examples. Using the labels above, I will give an example of each truth using "Person A" and "Person B":
1a - Person A asks Person B what time it is. Person B replies with the correct time. (relevant to location - timezone)
1b - Person A asks for an explanation of Plato's Theory of Forms. Person B explains the theory to Person A (dependent on Person B's understanding)
2 - Person A asks for the formula to calculate force. Person B replies with correct formula (F = ma). (the answer should always be the same)

Continuing with my opening statements - sure, we might be better off avoiding someone who will lie to you about the type 2 truths. But, in reality, you may not find too many people who lie about these truths to begin with. In most cases, you don't necessarily even need to be friends with someone to extract this type of information. When evaluating, I think people tend to look at are the type 1 truths, specifically type 1a. While, both of these truths are important, I would argue that type 1b truths are the most important. These are the truths that cause you to rely on a person, to sincerely consider them trustworthy.

When dealing with type 1b truths, you are depending on an individual to give you information that's validity is entirely in the hands of said individual. The risk here is that the information may be considered truth initially yet, fall short on its dependencies over time. In these cases, it's sometimes difficult to fault the person who failed as the falsehood may not have been intentional. In my experience, many people don't worry about this type of truth when making friends; often, one might simply label someone as unreliable or indecisive and let it go. I find it strange, this is a highly sought after quality in business yet, among friends it's negligible? I think this idea is definitely worth some heavy contemplation as you analyze your relationships.

From here, I think I could manage two more blog posts on type 1b alone; manipulation of the truth, recognizing it, labeling a person trustworthy, etc. However, this might be a good stopping point to avoid endless tangents. The other types have heavy implications as well and each could manage a post or two also. I think it's worth noting that it's often the case that if you have trouble trusting people in this way (type 1b), it might be because you yourself are not trustworthy in this way. That being said, it would be a mistake to fault yourself because you are disappointed often. Understanding this concept, a rather straightforward one at that, can make a significant difference in your decisions and success so, it might be worth a little reflection. I'll end this post on that note and, as usual, any questions, comments and/or suggestions are appreciated.

Exception Handling and Future Posts

I'm not sure how, but I managed to forget that I had started this blog. It's possible that this is because LaTeX has not been working correctly on my preview - it's quite annoying to not be able to double check your work. Anyways, I thought, for the sake of keeping this blog alive, I'd post where I plan to go from here and a bit about a mishap at work.

*NOTE* Actually, as I was typing this, I realized that none of my JavaScript is working in preview. Not sure if this is my fault or blogger is just not working correctly...

For now, those posts on calculus are being put on hold indefinitely. I did review some of the material; however, it's a lot to type up and I'm not sure if that's the direction I want to continue going with this blog. I'll try to post anywhere from one to two times a month and, for now, the topics will be random (not in series like the calculus posts attempted to be).

That being said, the I'll be sure to try to be more active from now on.

Moving on to my SQL troubles.

Now, I know better than what I did here but, I guess we all make mistakes...I guess.

At work, I primarily work in Oracle. When I'm not working in Java or some scripting language, it's stored procedures and triggers till I can no longer type. Recently, I had to make a simple update - to catch a certain value as it passed through our system and update some logs and data based on the value. For those who are not familiar, there is an Oracle function called, "NVL". Usage is as follows, "nvl([valueToCheck], [valueToReplaceWith])", this means that when this function is called, if the 'valueToCheck' is null, then return the 'valueToReplaceWith'.  For example:

set serveroutput on size unlimited;
declare
  some_string varchar2(64);
  test varchar2(64);
begin
  some_string := null; -- null value for illustrative purposes
  select nvl(some_string, 'better value') into test from dual;
  dbms_output.put_line(test);
end;
/
show err

This little PL/SQL block should output "better value" because 'some_string' is null.

Moving on, I built a new procedure and came up with the flawed reasoning that if the table doesn't have a row for a value it will return a null value on a select query. With this reasoning, I figured, "exceptions will just clutter the code, I'll just use "NVL" and check the value one time," which lead me to code like this:

-- ...other parts of the procedure
-- bad idea follows:
  select nvl(value_i_need, '?') into value_to_check 
  from some_table 
  where condition = 'condition_to_be_met';
  if value_to_check != '?' then
     -- do stuff
  else
     -- do other stuff
  end if;
-- ...more procedure logic...but logic that worked... 
end;
/
show err

Looking back, I realize that there are other flaws with this but, I'm just gonna call it a bad day. I proceded to push out this code to our working set and, only hours later, everything is broken. It was at this point I realized that my "select into" was causing a no data found exception because no rows existed for some of the conditions. Again, looking back there were plenty of better ways to handle this but, more or less, the moral of this story is, even if you don't think you need it, you always need exception handling. Just doing this alone, would have saved the errors that followed:

-- ...other parts of the procedure
-- begin end for exceptions...
  begin
    select nvl(value_i_need, '?') into value_to_check 
    from some_table 
    where condition = 'condition_to_be_met';
    if value_to_check != '?' then
       -- do stuff
    else
       -- do other stuff
    end if;
  exception when no_data_found then
    value_to_check := '?';
    -- problems solved...
  end;
-- ...more procedure logic... 
end;
/
show err

I thought this was worth writing about, if for nothing else then the fact that it will help me remember to not make that mistake again. Oddly enough, I never forget exceptions in Java, possibly because I'm more comfortable coding in it. Anyways, maybe sometime I'll look into the time complexities of SQL fetch queries depending on joins and things like that; with all the time I spend in Oracle, I've been curious lately.

Any questions, comments and/or suggestions are appreciated.