Evolution of the Magic Card Generator

Ben Craton — Thu, 01 Jun 2017 00:00:00 +0000

</div>

NOTE</strong>
If you’re wonder where the site is: see this post</a>.</p> </div> </div>
Introduction</h2>
I like Magic: The Gathering and I like programming, so in 2017 I built a web page that let people make their own Magic cards: upload some art, fill in the card attributes, get a card. That’s it. That was the whole idea. It then proceeded to eat nearly a decade of my hobby time, one rewrite at a time, and by January 2024, strangers on the internet had made over 250,000 cards</strong> with it.</p>
The honest framing: every version of this site was an excuse to learn whatever I’d just been exposed to at work.</p>
Version 1: PHP, Like an Honest Man</h2>
A basic PHP form and an image generator. Users typed in card text, the server composited it onto a card frame. It taught me web development fundamentals the traditional way: by breaking a live site repeatedly.</p>
Version 2: The Learning Platform Era</h2>
When I came back to it, I rebuilt it as an excuse to learn the “grown-up” stack of the mid-2010s:</p>

Python 3 & Django</strong> for the backend</li>
Neural networks & image recognition</strong> for automated analysis of uploaded card art</li>
Bitbucket, Jenkins, Docker, Rancher</strong> (a real CI/CD pipeline for a silly card site)</li> </ul>
The unglamorous lesson came from migrating 250k existing images and their data to a new format. Nothing teaches you respect for data integrity like the possibility of destroying a quarter-million pieces of other people’s art with one bad script.</p>
Version 3: Peak Complexity</h2>
Version 3 adopted whatever my DevOps colleagues were excited about that year:</p>

Vue.js</strong> frontend, Node.js & MongoDB</strong> backend, Redis</strong> caching</li>
An AI NSFW filter</strong> (because the site had no accounts by design, and anonymous internet users plus an image uploader is exactly the moderation problem you think it is)</li>
Docker & Kubernetes</strong> for orchestration, Azure DevOps Pipelines</strong> for deployment</li> </ul>
Yes, this is an absurd amount of infrastructure for a card generator. That was partly the point: I got to make my architecture mistakes on my own time instead of my employer’s.</p>
Where It Stands</h2>
The site is down (see the self-hosting update</a> for why), and I doubt it’s coming back. But a quarter-million cards is a quarter-million small moments of someone making a thing and grinning at it, and every skill this project taught me got used professionally within a year or two of learning it. Not bad for a hobby project that started as one PHP file.</p>

Base Emoji

Ben Craton — Fri, 03 Mar 2017 00:00:00 +0000

What is it?</h2>
A silly project to learn unicode, baseEmoji</a> is a base1024 encoding scheme that uses emoji as its lookup table. The primary purpose is to represent otherwise ugly data in more “pleasing” form in social media.</p>

Use Case</h2>

The impetus for this module was to represent digital signatures in social media in a less obtrusive way. A signature on a tweet from a user to a bot is useful in alerting the bot to run commands that can be trusted to have come from a specific source. However, these signatures look like jibberish to human readers. Instead, this signature could be represented by emoji using baseEmoji and appear to a human reader like a typical Instagram user.</p>

“Practical” Example: Signing a Tweet</h3>

Signing</h4>

</span>
import</span> sys</span></span>
import</span> tweepy</span></span>
import</span> baseEmoji</span></span>
from</span> ecdsa</span> import</span> SigningKey</span></span>
</span>
CONSUMER_KEY</span> =</span> '********'</span></span>
CONSUMER_SECRET</span> =</span> '********'</span></span>
ACCESS_KEY</span> =</span> '********'</span></span>
ACCESS_SECRET</span> =</span> '********'</span></span>
</span>
#set up tweepy and connect to Twitter</span></span>
auth</span> =</span> tweepy</span>.</span>OAuthHandler</span>(</span>CONSUMER_KEY</span>,</span> CONSUMER_SECRET</span>)</span></span>
auth</span>.</span>set_access_token</span>(</span>ACCESS_KEY</span>,</span> ACCESS_SECRET</span>)</span></span>
api</span> =</span> tweepy</span>.</span>API</span>(</span>auth</span>)</span></span>
</span>
#create a signing key. In practice this would be saved</span></span>
signKey</span> =</span> SigningKey</span>.</span>generate</span>()</span></span>
</span>
#our message</span></span>
message</span> =</span> "This tweet is signed"</span></span>
</span>
#sign the message</span></span>
signature</span> =</span> signKey</span>.</span>sign</span>(</span>message</span>)</span></span>
</span>
#convert the signature into an emoji signature</span></span>
emSig</span> =</span> baseEmoji</span>.</span>encodeStr</span>(</span>signature</span>,</span>" "</span>)</span></span>
</span>
#create the tweet with a delimiter for later parsing</span></span>
tweet</span> =</span> message</span> +</span> " #blessed "</span> +</span> emSig</span></span>
</span>
#send the tweet</span></span>
t</span> =</span> api</span>.</span>update_status</span>(</span>tweet</span>)</span></span>
</span>
#...</span></span></code></pre>Viewing</h4>
</p>
Verifying</h4>
#...</span></span>
#get the verification key</span></span>
verifyKey</span> =</span> signKey</span>.</span>get_verifying_key</span>()</span></span>
</span>
#retrieve a tweet (in this case the tweet we just sent)</span></span>
v</span> =</span> api</span>.</span>get_status</span>(</span>t</span>.</span>id</span>)</span></span>
</span>
#split the text of the tweet into the message and the signature</span></span>
(</span>rmessage</span>,</span>remSig</span>)</span> =</span> v</span>.</span>text</span>.</span>split</span>(</span>" #blessed "</span>,</span>1</span>)</span></span>
</span>
#convert the emoji signature back to its original form</span></span>
rsignature</span> =</span> baseEmoji</span>.</span>decodeStr</span>(</span>remSig</span>,</span>" "</span>)</span></span>
</span>
#verify that the signature is valid for the message</span></span>
assert</span> verifyKey</span>.</span>verify</span>(</span>rsignature</span>,</span> rmessage</span>)</span></span></code></pre>
In the wild, it may be advantageous to use a smaller digital signature algorithm and to also check that the length of the message plus the delimiter and signature don’t go beyond 140 characters. While the signature itself can be a fixed size of bytes, because some emoji require more than one code point, the emoji signature could be a few characters longer according to Twitter’s counting.</p>

FalseBlue - python

Evolution of the Magic Card Generator

Version 2: The Learning Platform Era</h2> When I came back to it, I rebuilt it as an excuse to learn the “grown-up” stack of the mid-2010s:</p>

Version 3: Peak Complexity</h2> Version 3 adopted whatever my DevOps colleagues were excited about that year:</p>

Base Emoji

What is it?</h2> A silly project to learn unicode, baseEmoji</a> is a base1024 encoding scheme that uses emoji as its lookup table. The primary purpose is to represent otherwise ugly data in more “pleasing” form in social media.</p>

“Practical” Example: Signing a Tweet</h3>

Viewing</h4> </p>

What is it?</h2>
A silly project to learn unicode, baseEmoji</a> is a base1024 encoding scheme that uses emoji as its lookup table. The primary purpose is to represent otherwise ugly data in more “pleasing” form in social media.</p>

Viewing</h4>
</p>