Oops, I created a bad name in Postgres

Oops, I created a SQL user with an upper case letter.

E.g.,

createuser --interactive
$ myUser

then I tried to create a corresponding Unix user:

sudo adduser myUser
-> bad name

OK, create an all lowercase name:

sudo adduser myuser

Now create that user in SQL:

createuser --interactive
$ myuser

in psql

\du
-> myUser
-> myuser
-> postgres

Huh, so we want to delete the first user:

DROP ROLE myUser;
-> cannot drop current user

This is because SQL folds unquoted names to all lowercase, so the command that SQL is actually interpreting is DROP ROLE myuser;.

To actually remove the myUser role:

DROP ROLE "myUser";
-> DROP ROLE

Being Granted Some Latitude

I was experimenting with MapKit (for a forthcoming project) and got to wondering: how big is a degree of latitude or longitude anyway?

Because all lines of longitude go through the poles, calculating the length of a one-degree arc is trivial. But the lengths for a lines of latitude are a little more complicated.

Here is a simple Swift class to quickly calculate a fairly close approximation:

Fighting With Delegation

Here's a quick illustration of how protocols and delegation can be used in a game to move combat mechanics into a separate class from characters.

The advantage of doing this is that a Person class needs only to know about its own attributes (and how to respond to external interactions) and can be totally oblivious to how the mechanics of the world work.

Below is a grossly simplified Person class and a brief interaction between two Person entities.

Note that we can freely improve and customise the specifics of interactions in the interaction manager without touching the Person class.

If we want additional functionality, we can put the method definitions into the protocol which will tell us exactly what changes need to be made to Person to work with the new functionality.

Camera Buddy: Exposure Value Calculator

Currently in Alpha: Camera Buddy: Exposure Value Calculator

A simple EV/LV calculator that can show two side-by-side exposure values for different aperture/shutter speed and iso combinations.

Source available on Github at: https://github.com/Crossroadsman/CameraBuddy

A Rational Type in Swift Because Why Not?

Heed the dire warnings in this early version of the Type that I mostly threw together late at night.

Hex Values in Swift (With a Diversion Into Strings)

It's not uncommon to need to work with hex values. Swift is nice enough to understand hex numbers (prepended with "0x") which will then be internally treated as regular Ints.

However, because the hex value is now a regular Int, it can be inconvenient querying the hex value of that Int.

Swift has an initializer for basic data types that can take another type and a radix value to comprehend a number with an arbitrary base. For example, to create a String from an Int, but using base 16 you could initialize the String as follows:

String(0xFF0000, radix: 16)

which is equivalent to:

String(16711680, radix: 16)

If this seems unintuitive, it might be worth extending Int to give a simple function available to all Ints to generate hex Strings. An example of how we might do this is as follows:

Now, any time we have an Int and we'd like to see it as hex, we just call .asHex() on the number. By default, this function prepends "0x" to indicate it is a hex value, but that can be overridden by changing the withLeadingIndicator: parameter to false.

How about if we have a hex value expressed as a String and we want to represent get that as an Int. You might think it would be just as easy as the previous extension, but we run into two problems opportunities:

1. Swift Strings are Unicode-based, which means individual characters are not all the same size and so asking for a substring of length 'n' is potentially ambiguous (the Apple Swift book has a good discussion of why this is so in the section Strings and Characters); and

2. Swift is evolving quickly, and the syntax for String methods changes often.

Let's start with the extension on String:

This extension will take a hex String in the format "ABCDEF" or "0xABCDEF" or "#ABCDEF" and turn it into an Int.

As you can see, it is longer than the Int extension, even after taking account of the control flow. The reason for this is we need to specify an Index on the String. The Index is a value that looks a bit like an Integer, and serves the same function for advancing through a String as an integer might in other languages.

We can specify an Index from the beginning or the end of the String. Here we are working with the beginning of the string. The equivalent to .startIndex for the end of the String is .endIndex but it is important to remember that the endIndex value is the index after the last character in the String.

Example: for the String "Hi" the startIndex is 0 (like an array) but the endIndex is 2. If we wanted to get the Index for the last character in a String str we would specify str.index(self.endIndex, offsetBy: -1).

In the extension above, we take a substring from a specified point and go to the end of the String. if we wanted to start at the beginning and go to a specified point in str we would use str.substring(to: index) and here we need to be aware that to extends to just before the specified character (i.e., up to but not including).

Functional Fizzbuzz in Swift

It's fun to revisit old programming problems with new programming styles. Today I was thinking about a nice way to rewrite the classic Fizzbuzz problem in a functional style.

It takes advantage of map() and forEach() and the fact that in Swift, map can be applied to a countable range:

If you just wanted to print the output, the map() piece can be omitted and the prints moved into the function body:

This version has the advantage of being shorter to type and only applying a single function (forEach) rather than two (map and forEach). However, the disadvantage is that IO is moved into the printfb() function whereas the original fb() function has no side effects and leaves IO to the outermost part of the program.

Using zip() For Something Useful

There are a few posts describing how the zip(_:_:) function works but not a whole lot of practical illustrations. While doing some research on Bayes' Rule, I put together a simple Swift function that implements the Odds Form of Bayes' Rule.

The initial form used a for loop to go through the two input arrays and multiply the members together:

Consider the following scenario (based on this illustration):

We are trying to solve a mysterious murder, and start out thinking the odds of Prof Plum vs Miss Scarlet vs Col Mustard committing the murder are 1:2:3 (i.e., Scarlet is twice as likely as Plum, Mustard three times as likely as Plum) a priori.

Now we learn that the victim was killed with a lead pipe. We think that Plum, *if* he was the murderer, is 60% likely to use a pipe. Scarlet, *if* she did the deed is 6% likely to use a pipe. Mustard is about 50% likely to use a pipe. The relative likelihood of Plum vs Scarlet vs Mustard using the Pipe is 10:1.

The posterior odds for Plum vs Scarlet vs Mustard are (1 : 2 : 3) * (60 : 6 : 50) = (60 : 12 : 150) = (10 : 2 : 25)

It works, but it's not pretty. Let's see how much nicer zip and map can make the same function: