Justin A. Parr - Technologist

Please note:  This has NOTHING to do with pizza coupons nor discount codes.  If you want pizza coupons, click here.

Every now and then, I run across the Geek Code, a compact notation for sharing basic profile and personality information.

I recently ran across this again, while looking for something else, and it inspired me to answer these questions:

• Could you define a compact yet robust notation for ordering a pizza?
• Could you order any pizza within an 80-character text message?
• Could you manage a single order with multiple pizzas within an 80-character text message?

Let’s find out…

 

 

Background

Please note:  This has NOTHING to do with pizza coupons nor discount codes.  If you want pizza coupons, click here.

The Geek Code has been around since 1993, as sort of an underground (“geek”) phenomenon.

It uses a specific syntax consisting of core attribute abbreviations to express various aspects of your profile and personality.  Each attribute has a specific set of modifiers to express degree, explicit inclusion, explicit exclusion, or the like.

What’s interesting about the Geek Code is that, as long as we all agree to a specific version, it can convey a tremendous amount of information using very few bytes, because each symbol or group of symbols has a specific predetermined meaning.

Moreover, because the Geek Code is text, you could:

• Add it to your e-mail signature
• Post it on your website
• Text it to someone
• Embed it in a QR code, and print the QR code on your business card
• Add it as an attribute to an X.500 / LDAP server

Anything you can do with text, you can do with the Geek Code.

Here is a very basic, sample Geek Code:

—–BEGIN GEEK CODE BLOCK—–
Version: 3.12
GAT d+ s+:+ a+
——END GEEK CODE BLOCK——

This tells another geek:

• GAT:   Geek of All Trades
• d+  I dress OK
• s+:+  I’m a little tall and a little round
• a+  I’m a little bit older than average

There are many other elements that can be added to your Geek Code, but the problem is that it’s no longer being actively maintained, and many of the categories are somewhat dated (e.g. “I watch X-Files whenever possible”)

So, in all, it’s a great piece of internet history, but maybe not completely relevant today.

 

 

The Pizza Code

Disclaimer:  I did some Googling, and wasn’t able to find anything that resembles what I’m presenting below, but if there is already a “pizza code” out there, I apologize – please contact me and we can collaborate. 

Once again, I recently ran across the Geek Code, which happens from time to time.

I thought, “what COULD you do with this kind of notation?”  In other words, what could you easily describe with “Geek Notation”, that would be fairly standard and easy to maintain?

My first thought:  Pizza!

Excluding vendor-specific specialty pizzas, there are a few simple options.

What could you use this for?

My next thought:  If you were REALLY adept at “the pizza code”, could you in theory order one via hand-typed text message?

Text messages are 80 or 160 characters in length (think: 1 or 2 lines of text), and are designed to convey lightweight information.  People have already developed many dialects of “text speek”, in order to shorten normal English in to a text-message-friendly format – sometimes, so much so, that text speek is almost unreadable.

English:  How are you today?

Text:  how r u 2da

So the goal of this project is to develop a standardized, compact, pizza notation that one could theoretically use to order a pizza via text message.

 

 

Designing The Pizza Code

Project Goals

Project Goals:

• Largely vendor-independent
• Allows robust options, like ordering different toppings on each half
• Allows the expression of ALL options, including crust, sauce, cheese, and toppings
• Include some basic error checking
• Exclude collisions – situations where symbols are ambiguous
• Avoid similar or confusing symbols – e.g. ‘l’ and ‘1’ look similar, as do ‘O’ and ‘0’.
• Allow self-healing for unsupported options

 

Design Approach

Obviously, the Pizza Code has to be symbolic, and we want to use pure text symbols, just as the Geek Code did.

Rather than specify each option, we can assume that we will always start with a basic prototype.  This allows us to represent an entire “default” set of options with one symbol.  We can use “P” for pizza:

P = generic pizza

We can start with something simple and generic, like a medium cheese pizza, which has all of the basic elements of a pizza, represented in a “default” mode:

• Medium size
• Regular crust
• Marinara sauce
• Regular amount of sauce
• Mozzarella cheese
• Regular amount of cheese
• No toppings

This means that we can encode 7 values in one symbol!  Not a bad starting point:

Rule 1:  P = 1 Pizza, medium, regular crust, marinara (regular amount), mozzarella cheese (regular amount) and no toppings.

As we progress, we can use other symbols and modifiers to describe these variables and other aspects of our pizza.

Further, we can assume that syntactically, if we start each pizza with “P”, then the next time we see “P” within the same string, we are describing a net-new pizza – for example, allowing us to concatenate Pizza Codes, and thereby order multiple pizzas with one string.

This gives us Rule 2:

Rule 2:  Each “P” represents a new pizza, and any subsequent characters are attributes or modifiers of the most recent “P”, starting new with the next “P”.

As a byproduct of Rule 2, we can safely ignore spaces and line breaks – they can be included for readability, but the system will work the same regardless.

 

Encoding Basic Attributes

We’ve already identified that “P” is a basic set of options for a medium cheese pizza.

Remembering my most recent online ordering experience, here is a quick run down of pizza attributes, minus toppings:

• Size:  Small, Med, Large, etc…
• Type of Crust:  Regular (sometimes called “hand-tossed”), Thin, Pan, Deep Dish
• Type of Sauce:  Usually Marinara, but some places also offer Alfredo
• Amount of Sauce:  Light, Regular, Extra
• Type of Cheese:  Usually Mozzarella, but some places offer a cheese blend, or Feta
• Amount of Cheese:  Easy, Regular, Extra
• Bake Time:  Some places allow you to specify slightly over or under the normal bake time

Let’s draw a line in the sand, and assume that all of these, for a given pizza, is a “global” option – you can’t order two different crusts or sauces on the same pizza.  Although some places may offer this, let’s assume you CAN NOT order more than one kind of cheese, either.  We can go back later and allow vendor-specific specialization through a set of vendor-specific options.

For now, we can focus on our core pizza attributes.

Since size is a function of the pizza itself, we can simply make it a modifier.  If we start with “P” = “Medium”, then:

• P++    Extra Large
• P+       Large
• P          Medium
• P-        Small
• P- –      Personal

Since not every pizza place offers all of these options, we can assume Medium is always Medium.  However, if they don’t offer a personal pizza, maybe this reverts to 1 slice, or to a small.  If they don’t offer a small, small reverts to medium.  Likewise, if there is no extra large, it reverts to large.

With this scheme, worst case scenario, I could order a P- – and end up with a medium, if that’s the smallest pizza they offer, but that might be much more food than I want.  We can check for this and correct it later.  Conversely, if I order a P++ and they don’t offer one, I’ll end up with the largest pizza they DO offer, which would still be OK.  I can always go back and order another pizza if needed.  Again, we can cover this later under logistics.

We need a symbol table for the other attributes.

Unfortunately, we have some possible collisions:

• “C” could stand for “Cheese” or “Crust”
• “T” could stand for “Type” (of something), Bake “Time” or “Topping”
• “S” could be “Sauce”, but maybe we want to be able to order a “Specialty” pizza

At first, the best approach would seem to be to use predefined fields:

P : crust : sauce : cheese : bake_time

Using this notation, your order might look like this:

P+ : r : m- : m+ : +

• Large pizza
• Regular crust (or hand-tossed)
• Easy on the marinara sauce
• Extra mozzarella cheese
• Extra bake time

Although this seems like a good approach, it has a few problems:

• What if you confuse the field for sauce and cheese?  You’d end up with EXTRA sauce, and LESS cheese – the opposite of what you want.
• What if you want to omit a field?  You could always leave it blank “::”, but then you run the risk of putting something in the wrong field.
• If you put an option in the wrong field, you might end up with something that doesn’t even make sense, such as “m-” in the “crust” field.  Rather than discard the option, this leaves you with an unusable pizza – obviously the “m-” meant something, but it can no longer be interpreted correctly.

Even though we are trying to use as few characters as possible, clearly we need to be more specific, and we need codes that make sense as a mnemonic.

For now, we probably need to keep the field separator, so let’s make that Rule 3:

Rule 3:  Each Attribute is separated by “:”

Why not use “.” or something else?  Although my Android has a “.” on the main alpha keyboard (without shifting), my iPhone doesn’t.  Besides, this is a code for geeks, and geeks should know how to get to the “:” symbol.

Using a separator also has the side effect of making the code largely case-insensitive, because we can use branching logic.

Rule 4:  all codes are CASE INSENSITIVE

 

 

Attribute Codes

We want all of the codes to be largely mnemonic, and also as forgiving as possible, in the event of a typo or collision.

Crust and Bake Time

Since we are already using “P” with modifiers to specify the size of the pizza, and a +/- modifier for crust doesn’t really make sense, we could combine the bake time with a +/- modifier.

:Cr = Crust

Options:

• :CrT      Thin Crust
• :CrR      Regular Crust (Default, Sometimes called Hand Tossed)
• :Cr          Also, Regular Crust
• :CrP       Pan Crust
• :CrD      Deep Dish
• :CrDD    Also, Deep Dish
• :CrXa      Vendor specific.

If Omitted, CrR is assumed.

Non-standard crust specification will be ignored, and will default to CrR.

Bake Time Options:

• :Cr+    Extra bake time
• :Cr       Regular bake time
• :Cr-      Less bake time

Default Bake time is assumed to be :Cr (regular)

Bake time and crust option can be combined:

• :CrP+    Pan crust, extra bake time
• :CrT-     Thin crust, less bake time
• :Cr         Regular crust, regular bake time (same as omitting)

The “X” code allows each vendor to optionally specify their own crust type or option, for example:

• :CrXc might mean “Cheesy Crust”
• :CrXp might mean “Pretzel Crust”

Not every vendor offers these options, but the “X” code gives each vendor some flexibility to offer their own signature options.  Later, if everyone generally agrees with a particular standard, it can be moved in to the main option list – for example, if CrXc becomes commonly used, it might become CrC in later versions of the standard.

Backward-compatibility is important – if multiple vendors are using CrXc, we don’t want them to simply drop this code and start using the new one.  Both codes have to be supported for a while:

Rule 5:  All future versions of the Pizza Code must be backward-compatible

Finally, we want to avoid collisions with some other code that starts with “C”.  For example, if we simply specify “C” = “Cheese”, we have a potential problem, if “Cr” = “Ricotta”.  We can’t distinguish between a regular crust and Ricotta cheese.

Rule 6:  All attribute codes other than “P” have to be the same length (2 characters)

 

Sauce

We want to be able to specify what kind of sauce, but also the amount.

:Sa = Sauce

Options:

• :SaM    Marinara (Default)
• :Sa        Also, Marinara
• :SaA     Alfredo
• :SaB      BBQ
• :SaXa   Vendor-specific

Modifiers:

• :Sa+     Extra Sauce
• :Sa        Regular Sauce (Default)
• :Sa-       Light Sauce
• :Sa- –     No Sauce

If not specified, the default is :Sa, which equates to Marinara, regular amount.

Options and modifiers can be combined:

• :Sa-      Easy on the Marinara  (Same as :SaM-)
• :SaA+   Extra Alfredo sauce

Again, the “X” code allows each vendor to offer their premium / signature sauces.

 

Cheese

We want to be able to specify what kind of cheese, and the amount

:Ch = Cheese

Options:

• :ChM    Mozzarella, Shredded (default)
• :Ch       Also, Shredded Mozzarella
• :ChMM    Mozzarella chunks, like a Margherita pizza
• :ChF     Feta
• :ChB     Cheddar Blend
• :ChXa   Vendor-specific

Modifiers:

• :Ch+    Extra cheese
• :Ch       Regular amount of cheese (default)
• :Ch-     Easy on the cheese
• :Ch- –   No Cheese

If omitted, the default is :Ch, which equates to a regular amount of shredded mozzarella

Options and Modifiers can be combined:

• :ChB+    Extra cheese, cheddar blend
• :ChF-      Light cheese, Feta

As with the other options, the “X” code allows the vendor to offer specialty options.

Because all of our option codes are the same length, the position where each occurs within the Pizza Code is irrelevant – except, of course, that it must appear after “P”.

Rule 7:  Other than “P”, option codes can be specified in any order.

This means that the following pizzas are all the same:

• P+:Ch+:Sa-:CrP
• P+:Sa-:ChM+:CrP     (Note that Ch and ChM are the same)
• P+:CrP:Ch+:Sa-

Etc…

 

Toppings

This is where things get tricky.

We’re on a roll with the attribute codes, so maybe “To” is a good way to specify “toppings”.

Setting aside (for now) that we want to be able to specify two pizza halves with different toppings, how would we specify multiple toppings?

One poor approach would be to use the topping attribute code each time:

• ToO      Onions
• ToO      Olives (collision)
• ToOl     Olives  (green or black?)
• ToGo    Green olives….. or green onions??
• ToTo+   Extra diced tomatos

Because of the specificity required for each topping, this is going to get cumbersome.

The first problem is to find a canonical way to identify each unique topping – a “taxonomy of toppings”, so to speak.

The first obvious segregation we can perform, is that “specialty” items would be vendor-specific.  So, for example, if you wanted a “sushi pizza”, this would be outside of the traditional taxonomy – we can account for this using our established “X” code standard:    For example, Xsu might mean “slice up a california roll, and drop that right on my pizza”, to the ONE vendor who does this.

For the so-called “standard” toppings, the first bifurcating characteristic in our taxonomy is “meat’ or “not meat”.  Although from a logical perspective, this statement seems almost contradictory, as if combining “meat” and “not meat” might inadvertently result in annihilation followed by a burst of gamma rays, the reality is that we have to account for the comical and ironic fact that the government classifies the tomato (a fruit) as a vegetable for tax purposes.

Likewise, plant leaves, fleshy roots, fruits, nuts, bark, and seeds all fall in to the “not meat” category, and we can save ourselves an existential headache by simply calling all of this stuff, “veggies”.

We already have a category for cheese, eggs (although they SHOULD be) are not currently a “standard” topping on pizza.  This eliminates “dairy” as a standard category…

So if we discriminate between “meat” and “veggies”, we have the basis for a taxonomy, and thus a topping lexicon.

What if we want a predefined specialty pizza?  For example, although the specific definition varies from vendor to vendor, EVERY vendor has a “Meat” pizza, a “Supreme”, and a “Veggie” pizza.

We need the flexibility to select a predefined configuration such as the above, but also, we need to be able to add or remove toppings.

Setting aside the whole attribute code issue:

• X – Vendor-specific topping  (e.g. Xq = Quail’s egg; Xsu = Sushi)
• S – Grouping of specialty toppings (e.g. meats, veggies, supreme, etc….)
• M – Meat topping
• V – Veggie (not meat) topping

This gives us a basic starting point for developing a “codified topping lexicon”.  Keep in mind that we want to maintain a mnemonic scheme.

Specialty Pizzas:

• Sm      Meats
• Ss        Supreme
• Sv        Veggie
• Ssa       Spinach Alfredo
• Sca      Chicken Alfredo

(No modifier)

Meat Toppings:

• Mba     Bacon
• MIt      Italian Sausage
• MHa    Ham (Canadian Bacon)
• MCb     Canadian Bacon (Ham)
• MBu     Hamburger
• MHb    Also, Hamburger
• MPe     Pepperoni
• MSt      Sliced Steak
• MCh    Chicken
• MAn     Anchovies (I LOVE ANCHOVIES….. GO WRITE YOUR OWN PIZZA CODE)

Veggie (non-meat) Toppings:

• VPe     Peppers  (Default – Green)
  • VPeB     Banana Peppers
  • VPeG     Green Peppers
  • VPeJ      Jalapeno Peppers
  • VPeR     Red Peppers
• VOn    Onions   (Default white / yellow)
  • VOnG    Green onions
  • VOnR    Red onions
• VOL    Olives   (Default black)
  • VOLG    Green Olives
  • VOLB     Black olives (Same as VOL)
• VPi     Pineapple
• VTo    Diced Tomato
• VMu   Mushrooms
• VSp    Spinach

So the next question is:  How do we string this together?

There are two basic scenarios:

• You pick a specialty pizza, and you add / remove toppings
• You build a pizza from scratch, and you add toppings

So our lexicon has to include the ability to add, remove, or specify extra toppings:

-Topping       Remove this topping

+Topping      Add this topping

++Topping   Add extra of this topping

Because we will always specify +, ++, or – in front of a topping, this gives us a syntactical approach to stringing toppings together.

To be consistent with our 2-character attribute code, let’s put “To” in front of the whole thing…

:To = Toppings

Syntax:

:To{++|+|-}Topping1[{++|+|-}Topping2…]

 

So…. let’s say we start with a Meat loving pizza, drop the hamburger, and add pineapple:

:To+Sm-MBu+VPi

Large Cheese and Pepperoni:

P+:To+MPe

NOW, we have a pizza!

 

Two Halves

Let’s say that you want two different toppings on each half of a pizza…

What’s the easiest way to do this?

Simply, specify two topping codes.

IF 1 topping code

Cover entire Pizza with Topping_Set_1

ELSE

Cover Half1 with Topping_Set_1

Cover Half2 with Topping_set_2

So, let’s say we want a large veggie on one side, and meat-lovers + onion on the other:

P+:To+Sv:To+Sm+VOn

Two To codes result in Half1 with topping set 1 and Half2 with topping set 2.

 

 

Miscellaneous

We still have  a few things to cover…

Error Checking – Optional

At the end of the pizza code, there should be an indication of what was requested:

Checksum

In parentheses, indicate the total number of pizzas of each size within the order.  Use “=” for medium.

“(” [n++] [n+] [n=] [n-] [n- -] “)”

For example, if we are ordering 2 large and 1 medium pizza:

(2+1=)

Error checking helps us determine what we are buying, to ensure that what we requested is what we should expect.

For maximum ease of use, the checksum should be optional.

 

Address

Let’s say you’re at your friend’s house….

We need to be able to specify an alternate address.

Note:  No address means that your default address will be the delivery address.

:Ad!Streetaddress!Apt!zipcode

Examples:

:Ad!123 Any Street!!12345

:Ad!401 Nowhere Blvd!104!84842

In the event of a severe disconnect, the pizza vendor can simply call the customer on his/her phone, or text, requesting clarification.

 

Logistics

1. You text Pizza Code(s) –> Pizza Vendor
2. You <– Pizza Vendor texts summary, any discrepancies, address, and price
3. You text “yes ” PIN –> Pizza Vendor
4. You <– Confirmation

At any time, text “Cancel” to cancel the transaction.

Any transaction > 10 minutes is automatically cancelled without a valid response.  You <– Pizza vendor “Cancelled”

In step 2, the pizza vendor confirms what you are requesting.

So if you text:

P+:P:To+Ss+VOlG(1+1=)

• 1 Large cheese pizza
• 1 Medium supreme, add green olives

Suppose the vendor doesn’t have green olives for some reason, they might respond:

1+
1= -VOlG
$18.95
123 Yourstreet
Type yes PIN to order

This provides you with a chance to review your order.  You see that black olives are not available, but you decide to order anyway.

In another situation, maybe you want a personal pizza:

P–:To+MPe(1–)

Perhaps the vendor doesn’t offer personal pizza, nor pizza by the slice.  Maybe all they have is a medium:

1=
$9.99
123 Anystreet
Type yes PIN to order

You quickly see that they don’t offer a personal or small – the smallest they offer is a medium, so you cancel the order:

Cancel

 

 

Tip

:Ti

• :Tin     $n dollars tip
• :Tin%   n%  tip

 

Vendor-Specific Items

:Xx = Vendor-specific item or attribute

For example, maybe SuperduperPizza decides to offer wings and breadsticks via the pizza code.  You might order them like this:

P:To+MPe:XxWiB10:XxBrCh

Although each vendor might have their own codes, maybe at SuperduperPizza, this means:

• Medium pepperoni pizza
• 10 boneless wings
• Cheesy breadsticks

As you can see, extending the pizza code is quite simple.  Later, it might make sense to have a completely separate “Wing Code”, or an official set of wing standards within the Pizza Code itself.

 

Multiple Pizzas, Same Specification

An integer after “P” indicates the quantity:

• “P2”     = 2 medium
• “P3+”  = 3 large
• “P4- -” = 4 personal

Example:

P4+:To+MPe(4+)         4 large pepperoni pizzas

 

Multiple Pizzas, Different Specification

Concatenating Pizza codes:

P+:To+VOnR++VOlG+MPe:P2:CrP:SaA:To+MCh+VPi(1+1=)

1 large red onion, green olive, pepperoni

2 medium pan, alfredo, chicken, pineapple

 

Conclusion

Here are some of my favorite pizzas:

• P+:To+Sca+VPi    (Chicken Pineapple Alfredo)
• P+:To+Ssa             (Spinach Alfredo)
• P+:CrT:To+MPe+MHa++MBa+VOnR       (Thin crust, Pepperoni, Ham, Extra bacon, Red Onion)
• P+:To+MHa+VPi+VMu+VOn                       (Regular crust, canadian bacon, pineapple, mushroom, onion)

Generate your own pizza code!

 

Pizza Code Cheat Sheet

pizza-code-cheat-sheet