Wireless Continuous Wave Transmitter | Project 7/10 | Maxitronix 10in1 | In The Lab With Jay Jay

This post is part of my video blog: In The Lab With Jay Jay.

In this video I do the seventh Maxitronix 10in1 Electronic Project Lab project: Wireless Continuous Wave Transmitter.

While conducting this experiment I made some notes over here: Maxitronix/10in1/7.

I made a bunch of mistakes while building and testing this circuit, and a lot of the footage I took didn’t make it into the final video. In particular in between the construction part of the video at the beginning, and the testing part of the video at the end, I added a ceramic capacitor at the base of the transistor; I hadn’t understood the instructions to install this capacitor as it wasn’t wired in using spring terminals like all the other components.

On the value of foreign key constraints

Here is something I would like to demo regarding foreign key constraints.

This regards what type of errors foreign key constraints can (and can’t!) save you from.

Occasionally you hear developers say how important foreign key constraints are and how foreign key constraints saved them from some bug. That might all seem well and good but when you think it through if a foreign key constraint saved you from a bug it also might very well just have been luck that saved you and the thing that went wrong might have gone wrong another way and have gone undetected as database corruption and potential accidental data disclosure to an incorrect entity.

To set the scene let’s use some schema/data from what we were talking about earlier:

create table t_skinny_customer (
  customer_id bigint not null primary key,
  customer_name varchar(255) not null,
  customer_record_created_on timestamp default current_timestamp,
  customer_record_updated_on timestamp default current_timestamp on update current_timestamp
);

create table t_skinny_customer_phone (
  customer_phone_id bigint not null primary key,
  customer_id bigint not null references t_skinny_customer( customer_id ) on delete cascade,
  phone_number varchar(255) not null,
  phone_type enum( 'phone', 'tollfree', 'mobile' ) not null default 'phone',
  phone_type_order tinyint unsigned not null default 0,
  phone_record_created_on timestamp default current_timestamp,
  phone_record_updated_on timestamp default current_timestamp on update current_timestamp
);

insert into t_skinny_customer (
  customer_id,
  customer_name
)
values (
  1,
  'John Doe'
), (
  2,
  'Jane Doe'
);

insert into t_skinny_customer_phone (
  customer_phone_id,
  customer_id,
  phone_number,
  phone_type,
  phone_type_order
)
values (
  11,
  1,
  '123-456-7890',
  'phone',
  1
), (
  21,
  2,
  '123-456-7894',
  'phone',
  1
);

Then let’s run this code:

    $stmt = $pdo->prepare("
      update
        t_skinny_customer_phone
      set
        customer_id = :customer_id
      where
        customer_phone_id = :phone_id
    ");

    try {

      $stmt->execute([
        'customer_id' => 3,
        'phone_id' => 11,
      ]);

      assert( false );

    }
    catch ( PDOException $ex ) {

      // 2024-02-13 jj5 - foreign key constraint saved the day!

      assert(
        0 === strpos(
          $ex->getMessage(),
          'SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails'
        )
      );

    }

    $stmt->execute([
      'customer_id' => 2,
      'phone_id' => 11,
    ]);

    // 2024-02-13 jj5 - ... whoops! what we've done here is switch
    // one of John Doe's phone numbers to be one of Jane Doe's
    // phone numbers. The foreign key constraint is of no value in
    // detecting this type of data corruption.

Now I’m not saying that you shouldn’t have foreign key constraints. I’m just pointing out that if you do have foreign key constraints and you’re relying on them for “referential integrity” your door may be open for all manner of bugs (and exploits).

That your foreign key points to an actual record doesn’t necessarily imply that your foreign key points to a correct record.

PHP shutdown handlers and exit codes

I was in bed trying to get to sleep but my brain wanted to know the answer to this question. So I was forced out of bed to write this experiment:

function main( $argv ) {

  register_shutdown_function( 'shutdown_1' );
  register_shutdown_function( 'shutdown_2' );

  exit( 0 );

}

function shutdown_1() {

  exit( 1 );

}

function shutdown_2() {

  exit( 2 );

}

main( $argv );

With this PHP code, what do you expect is the resultant error level?

The answer is ‘1’. After main() calls exit( 0 ) the shutdown function shutdown_1() is invoked. When shutdown_1() calls exit( 1 ) the process exists and shutdown_2() is never called.

I’m glad we cleared that up. Back to bed.

Context object versus global variables

I’m reading A Philosophy of Software Design by John Ousterhout and he says:

The context object unifies the handling of all system-global information and eliminates the need for pass-through variables. If a new variable needs to be added, it can be added to the context object; no existing code is affected except for the constructor and destructor for the context. The context makes it easy to identify and manage the global state of the system, since it is all stored in one place. The context is also convenient for testing: test code can change the global configuration of the application by modifying fields in the context. It would be much more difficult to implement such changes if the system used pass-through variables.

Contexts are far from an ideal solution. The variables stored in a context have most of the disadvantages of global variables; for example, it may not be obvious why a particular variable is present, or where it is used. Without discipline, a context can turn into a huge grab-bag of data that creates nonobvious dependencies throughout the system. Contexts may also create thread-safety issues; the best way to avoid problems is for variables in a context to be immutable. Unfortunately, I haven’t found a better solution than contexts.

Okay, so I’m just gonna step way out of line over here and suggest something heretical… but shouldn’t you just use global variables? You only introduced the context object so you could tweak it in unit tests, and you could just change your tests so that each one ran in a new process. Just sayin’.

…I suppose for the sake of completeness I should add a little more from Ousterhout which he said prior to the above:

Another approach is to store the information in a global variable, as in Figure 7.2(c). This avoids the need to pass the information from method to method, but global variables almost always create other problems. For example, global variables make it impossible to create two independent instances of the same system in the same process, since accesses to the global variables will conflict. It may seem unlikely that you would need multiple instances in production, but they are often useful in testing.

…so he is bending over backward to support multiple tests in one process, but he could just run each test in its own process and his problem evaporates.

Oh cringe

Man. So. Today, this happened. I was watching a new video from Adrian Black and his EEVBlog multimeter failed:

It's disappointing that it's already failed

I have been saving my pennies and planning to buy an EEVBlog 121GW Multimeter because a lot of the makers around the interwebs have one as a nod to Dave Jones over on the EEVBlog, but that’s just so embarrassing that it’s failing. Of all the equipment you have you need to trust your test equipment the most and this is… well, just sad I guess.

Logic Analyzer with 1GHz Sampling Rate

Today I was pleased to discover this: DreamSourceLab DSLogic U3Pro32 USB-Based Logic Analyzer with 1GHz Sampling Rate, 2Gbits Memory, USB 3.0 Interface, 32 Channels.

There are some notes from the manufacturer over here: DSLogic Series USB-based Logic Analyzer.

It’s a logic analyzer which can operate at 1GHz that’s within my price range. I’m not rushing off to buy this thing, but it is certainly on my list.

The only other thing I have seen that compares to this logic analyzer is this RIGOL DS70304/DS70504– Digital Oscilloscope 3GHz/5GHz 4 Channel 20GSa/s 2Gpts 1000000 wfms/s which is roughly two orders of magnitude more expensive.