Update 2020-06-10: The linked article is possibly still of some value for the example of a lambda function in Swift (not to mention the world’s best bakery name). However, the convoluted steps necessary to compile Swift for the AWS environment are no longer necessary with the introduction of the Swift AWS Runtime.

I wrote a short article on using Swift and AWS Lambda to write serveless functions. Directing you to another site is, I suppose, not a swift move from a social media perspective. Nevertheless, go have a look.

import Foundationn

if "this is a test" {
   println("This can't work.")
}

Perhaps you are expecting a compiler error. Nope. The output is, of course,

This can't work.

Then I tried the following:

if "this is not a test" {
   println("No, really, this can't work.")
}

Xcode displayed the output:

No, really, this can't work.

One last code snippet:

if "you know what's going on" {
   println("You're a genius!")
} else {
   println("So sad!")
}

I’ll let you determine for yourself the appropriate output.

The point of the exercise

To be honest, there’s not much of an actual point here. I just found the Swift code amusing.

Sure, I could argue against using overly-clever code in production. And I would never use a trick like this in production code. But I don’t need to argue against this practice, because nobody’s arguing for it.

Now, before you repsond “because DSL”, let me point out, I’m all for domain specific languages (DSLs). I’ve given talks on DSLs in Forth and TCL (such as this one. I’m jealous that Mattt (not a typo) Thompson beat me to the punch with Euler. So, I’m all in favor of DSLs, not to mention operator overloading, code generators, and metaprogramming. They’re all good!

But the primary purpose of code is to clearly communicate with other programmers. (What? You thought it was to tell the computer what to do? That’s soooo quaint!) One of my favorite CS-related quotations is from Brian Kernighan:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Metaprogramming, operator overloading, etc. often times make our code harder to read (hence, harder to understand/debug) because they increase the amount of context we have to maintain. There are many situations where using macros (real macros, Lisp-like macros, not puny C preprocessor macros), or operator overloading, or creating a DSL is warranted because it clarifies our communication, but every time we are tempted to use such a technique, we have to ask ourselves are we using this technique because we need to, or are we using it because we can?

The code behind the curtain

First, I should fess up. In case you didn’t notice it, at the beginning of the code listing, it’s not Foundation that I’m importing, it’s Foundationn. The former is Apple’s module containing definitions for all the, uhm, well, foundational classes. The later is a module I cooked up to be deceptive^Wclever. I’ll list the code below.

The main decision to make is how to map strings to boolean values. Once you’ve decided on a mapping approach it’s a simple matter of using an extension so that String implements the BooleanType protocol. I did it as follows:

extension String: BooleanType {
   var boolValue: Bool {
      get {
         if self.contains("test") {
            return true
         } else {
           return false
         }
      }
   }
}

String (at least as of Beta 5 and, yes, I’ve been a little slow posting this) doesn’t implement contains. I use code which I grabbed from StackOverflow.

extension String {
    func contains(other: String) -> Bool {
      var start = startIndex

      do {
        var subString = self[Range(start: start++, end: endIndex)]
        if subString.hasPrefix(other) {
            return true
        }

    } while start != endIndex

    return false
  }
}

I wound up with the above code to check string containment after trying a half-dozen different approaches that various people claimed worked. I suspect they all did for one beta or another. Presumably with the 1.0 release of Swift (and 1.1 around the corner), the pace of change in Swift will slow down (but not stop, since much as I like Swift, it still has a lot of growing up to do).

If you would like to play around with branching on strings, you can download the workspace I created from https://github.com/profburke/ObscureSwift. I would like to collect more Swift oddities, so feel free to add an issue or send push requests if you have anything to contribute. Given the previous paragraph, YMMV.

Spanning Xcode betas

One final note. I was working on this during some less-than-ample-spare time and new Xcode/Swift betas kept popping up before I was finished.

This was not fun.

In case this remains an issue with new releases, here’s the little dance I had to perform for each new version in order to get Swift to recognize the Foundationn module:

• delete the derived directory for the project
• remove the pcm file from the module cache (under the DerivedData directory)
• delete the playground file
• build the module
• recreate the playground file

Once the Xcode release for Yosemite comes out, I’ll test this again, and submit a radar as necessary.

CREATE TABLE members (
   member_id INTEGER PRIMARY KEY AUTO_INCREMENT,
   member_name VARCHAR(128) NOT NULL,
   member_state CHAR(2) NOT NULL,
   INDEX state_idx (member_state),
   FOREIGN KEY (member_state) REFERENCES postal_abbreviations (abbreviation)
) ENGINE=INNODB;

CREATE TABLE members_journal (
  journal_id    INTEGER PRIMARY KEY AUTO_INCREMENT,
  operation     VARCHAR(16) NOT NULL,
  member_id     INTEGER NOT NULL,
  member_name   VARCHAR(128) NULL,
  member_state  CHAR(2) NULL
) ENGINE=INNODB;

DROP TRIGGER IF EXISTS members_insert_trigger;

DELIMITER |
CREATE TRIGGER members_insert_trigger AFTER INSERT ON members
FOR EACH ROW
BEGIN
  INSERT INTO members_journal (operation, member_id, member_name)
     VALUES (<span class="s1">'insert', NEW.member_id, NEW.member_name, NEW.member_state);
END;
|
DELIMITER ;

-- more trigger definitions here. . .

Briefly: for each primary table, such as members, you create a table to record the changes, members_journal. The journal table should include all the columns from the primary table, without constraints, as well as its own primary key and a column to include the operation type (insert, update, delete). Typically, you would want to include a timestamp in the journal table, but I have not shown it, as the example source code is already fairly lengthy. Then you create triggers to insert information into the journal table each time the primary table is modified.

There are some things which you need to be concerned with if you use this technique. The first that comes to mind is performance. But in this particular case, it’s not too much of a concern because once we went into production, the content would change infrequently and only a handful of users would have permission to change the content.

More pressing for us was the fact that a) we were making fairly frequent and extensive schema changes during development and b) unlike the example above, our tables had lots of columns.

You can probably see the implication of the above. We would update our code and recreate the database only to find that the column lists in the table definitions and the column lists in the trigger definitions were out of sync. Keep in mind that for each table being audited we had four column lists to keep consistent: one table and three triggers.

Now let’s change gears for a moment and consider software development principles. DRY is an acronym formed from the coding aphorism Don’t Repeat Yourself (also known as Single Source of Truth). The essence of the principle is that, according to Hunt and Thomas in The Pragmatic Programmer, “[e]very piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Why keep your code DRY? Because if you do not, dire things happen! You find yourself having to fix the same bug in multiple places (and always, always, always forgetting to correct one of the instances), or introducing inconsistencies in your software, or not seeing opportunities to simplify your implementation because you’re blinded by lots of excess code.

Now back to my database problem. Clearly, if you’re not DRY, then you must be WET (write everything twice). Except in my case, I’m beyond WET because I’m writing everything four times!

I needed a mechanism that allowed me to avoid this duplication. There are several approaches I could have taken including the following:

• Write the SQL statements to create the tables then parse these SQL statements to auto-generate the trigger definitions.
• Define the tables and then pull the necessary information to generate the triggers from the database’s information schema.
• Describe the table columns using something more abstract than SQL code and auto-generate both the table definitions and the trigger definitions from this same source.

I chose the third option. There remained the decision of how to represent the column definitions and how to do the auto-generation. An obvious choice would be to use XML as the data representation and use XSLT to do the transformation. I leave it as an exercise for the reader to research this option.

Instead, I chose to use the language Lua. Lua is an elegant, powerful scripting language that began as a data description language in the early 1990s. Although it has evolved significantly since then, it has never lost its powerful data description capabilities. I’ll discuss Lua in more detail in a future blog post.

Using Lua, I created a data structure to describe each of the primary tables. Using the example schema from above, the data structure looks as follows:

schema = {
  members = {
     fields = {
        { 'member_id', 'integer', 'auto_increment', },
        { 'member_name', 'varchar(128)', 'not null', },
        { 'member_state', 'char(2)', 'not null', },
     },

     primary_key = {
        'member_id',
     },

     foreign_keys = {
        { 'state', 'postal_abbreviations', 'abbrev', },
     },

     indices = {
        'state',
     },
   }

   some_other_table = {
                    . . .
                    . . .
   }

A few points about the above code: in Lua, the primary data structure is the table, which can be treated as an array, an associative array (hash), or both at the same time. The schema table includes entries for each primary table in my database. Each table entry describes the fields and auxiliary information such as table constraints, keys, and indices to be created. As with many scripting languages, if you attempt to access a key in a table that doesn’t exist, you get the special value, nil, returned. This means that your data definitions can be sparse.

With the above data structure in hand, we can now easily write different scripts to process the schema in different ways. For example, below is the start of a script to generate the table definition code.

for tableName, tableDefinition in pairs(schema) do
  print(string.format("CREATE TABLE %s(", tableName)
  for _, fieldDefinition in pairs(tableDefinition['fields']) do
    . . .
    . . .
end

Using the above, I have moved from being all WET to DRY. I use the same information to generate the tables, the journal tables, and the triggers and so I can be assured that everything is properly in sync. There is one small, remaining item. After I make a change to the field definitions, I need to remember to run all the generators. But that can be handled with proper use of build automation and will have to be left to another blog post!