DEV Community: Frank Riccobono

But What About the Trophies?

Frank Riccobono — Sat, 25 Apr 2026 00:00:00 +0000

Backstory

It was the fall of 2020. A new school year had just started, but amidst the continuing pandemic safety measures, we in the speech and debate community were wondering whether we would be able to continue the activity in some form or another. Thanks to a video platform developed that summer by the National Speech and Debate Association, we were fairly confident we could hold virtual tournaments, but we had another practical issue: how would we recognize the winners?

Speech and debate is primarily an educational activity. We don’t encourage students to participate for the trophies, but at the same time, doing well at a tournament is difficult. We still wanted to reward these students for their success. Trophies were the league’s largest expense when running in-person tournaments, and mailing them out after virtual tournaments would have been prohibitive.

Our league director came to me with an idea: certificates. More specifically, we needed a way to generate hundreds of printable certificates automatically, personalize them, and distribute them digitally. Here’s how I did it.

Layout

Maybe I was just biased from years of working in web development, but when I looked at the sample certificates we had printed, I saw a familiar box model.

The layout was primarily centered text with some borders and spacing. I decided to use HTML and CSS. A certificate can be represented as just a few lines of text and markup. The structure was straightforward.

<div class="certificate_border gold finalist">
    <div class="certificate_body placement_certificate">
        <img alt="The tournament logo" src="/nycfl-logo.svg" height="100px"/>
        <p class="nycfl">New York Catholic Forensic League</p>
        <p class="award_certificate">Award Certificate</p>
        <div class="tournament_details">
            <p class="host">Regis High School</p>
            <p class="tournament_name">NYCFL First Regis</p>
            <p class="tournament_date">September 26, 2020</p>
        </div>        
        <p class="place">First Place</p>
        <p class="before_text">This certificate is given to</p>
        <p class="name">Jane Doe</p>
        <p></p>
        <p class="before_text">to recognize outstanding performance in the category of</p>
        <p class="event_name">Dramatic Performance</p>
        <p class="signature_block">
            <span class="signature">Thomas Beck</span>
            <span class="position">NYCFL President </span>
        </p>
        <p class="date_block">
            <span class="signature-date">09/26/2020</span>
            <span class="date-label">Date</span>
        </p>
    </div>
</div>

I found a royalty-free guilloché border vector image and found a few suitable web fonts with the right look. My reference certificate was a Word Document based on a print template from an office supply store. When translating a design into HTML/CSS, we usually use units like pixels or REMs, but in this case, it was easier to use inches, a less commonly used unit in web design. That allowed me to make the full size of a certificate to be based on US Letter paper size (8.5 x 11 inches).

div {
    overflow: hidden; 
    height: 8.5in; 
    width: 11in; 
    padding: 0.5in;
}

Because certificates are fixed-size documents, HTML print styles made it easy to produce consistent, printable layouts.

Templates

The core idea was to extract data from Tabroom, the software we used to run tournaments and use it to generate the certificates. Tabroom was built with a programmer’s mindset and makes much of its data available as comma-separated-value (CSV) exports. There were several types of reports we wanted to generate from this data so I decided the best starting point was to parse the files once and import the data into a database.

The basic workflow would be:

Import CSV results
Store in database for reuse
Render certificates using a template
Export as printable HTML/PDF

I decided to use Quarkus to scaffold the application along with its Qute templating language. Its quick startup time, developer tooling, and simple Jakarta EE API implementations made it a great choice for building a prototype that could evolve into the final product.

Students compete in one of several categories. For each category, I would get a final results CSV file that looked something like this. I used the Apache Commons CSV library to parse the files.

Ranking	Code	Name 1	School
1	508	Jane Doe	Some Academy
2	512	John Smith	P.S. 1337

Since I would be the one generating the certificates, I used an H2 file-based database. We were all working remotely so both the application and the database file lived on my desktop. When I needed to generate something, I could start up the application using Quarkus development mode.

To interact with the application, I created a REST API that could power a small React front end. Below is a simplified version of the JAX-RS resource. Most of the endpoints are general CRUD operations. These endpoints provided for the following workflow:

create a tournament with basic information like the name, date, and virtual host school
create a list of events in the tournament
upload the CSV results for each event
render the certificates into the template

@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class CertificatesResource {
    @Inject
    Template certificate;

    @POST
    @Path("/tournaments")
    public Tournament createTournament(Tournament tournament);

    @POST
    @Path("/events")
    public Tournament createEvents(EventList eventList);

    @POST
    @Consumes(MediaType.MULTIPART_FORM_DATA)
    @Path("/tournaments/{tournamentId}/events/{eventId}/results")
    public Tournament addResults(
        @MultipartForm MultipartBody body,
        @PathParam("eventId") int eventId,
        @PathParam("tournamentId") long tournamentId
    );

    @GET
    @Produces(MediaType.TEXT_HTML)
    @Path("/tournaments/{id}/certificates")
    public String generateCertificates(@PathParam("id") long tournamentId);
}

The generateCertificates endpoint would render the Qute template.

<link rel='stylesheet' href='/certs.css' />
{#for event in tournament.events}
{#for result in event.results}
<div style="overflow: hidden; height: 8.5in; width: 11in; padding: 0.5in">
    <div class="certificate_border {result.certColor}">
        <div class="certificate_body">
            <img src="/nycfl-logo.svg" height="100px"/>
            <p class="nycfl">New York Catholic Forensic League</p>
            <p class="award_certificate">Award Certificate</p>
            <div class="tournament_details">
                <p class="host">{tournament.host}</p>
                <p class="tournament_name">{tournament.name}</p>
                <p class="tournament_date">{tournament.longDate}</p>
            </div>
            <p class="place">{result.placeString}</p>
            <p class="before_text">This certificate is given to</p>
            <p class="name">{result.name}</p>
            <p class="before_text">to recognize outstanding performance in the category of</p>
            <p class="event_name">{event.name}</p>
            <p class="signature_block">
                <span class="signature">Thomas Beck</span>
                <span class="position">NYCFL President</span>
            </p>
            <p class="date_block">
                <span class="signature-date">{tournament.shortDate}</span>
                <span class="date-label">Date</span>
            </p>
        </div>
    </div>
</div>
<div style="page-break-after: always; visibility: hidden"></div>
{/for}
{/for}

In the first version of this, I had several border images to produce different placements. Gold for first place, silver for second, bronze for third, red for fourth through sixth place, and light blue for any other finalists. I quickly realized that it would be beneficial to have more flexibility to support more placements and custom designs without maintaining multiple static images. Thankfully, since the border was an SVG file, I could also turn it into a Qute template as well and add one more endpoint that would adjust colors in the SVG.

@GET  
@Path("/background.svg")  
@Produces("image/svg+xml")  
@PermitAll  
public String getBackgroundImage(  
    @QueryParam("color") @DefaultValue("ffffff") String color,  
    @QueryParam("color2") @DefaultValue("323131") String color2,  
    @QueryParam("color3") @DefaultValue("323131") String color3  
)

And we could reference this endpoint in CSS like this:

.certificate_border.gold {
    background-image: url('/certs/background.svg?color=D4AF37');
}
.certificate_border.black {
    background-image: url('/certs/background.svg?color=D8D8FF');
}
.certificate_border.silver {
    background-image: url('/certs/background.svg?color=C0C0C0');
}
.certificate_border.bronze {
    background-image: url('/certs/background.svg?color=CD7F32');
}
.certificate_border.red {
    background-image: url('/certs/background.svg?color=C76C67');
}

Finally, since the certificates were rendered as HTML, generating PDFs was straightforward. I used Chrome’s built-in “Print to PDF” feature, which handled layout and pagination reliably without needing additional libraries or tooling. While this wasn’t fully automated, it was simple and dependable—and more than sufficient for our needs. For ease of downloading, I uploaded the resulting PDF to an Amazon S3 bucket because the file was too large to email.

On September 30th, I sent out the first set of certificates for our first online speech tournament, 45 pages altogether, and it was just the beginning. Soon, I needed to accommodate events with other formats, larger tournaments with quarterfinals and semifinals, tournaments for other leagues, and customization for other purposes. The strength of the original implementation was how easy it was to evolve. I’ve since generated certificates and slides (more on that later) for over 150 tournaments, and the software has continued to evolve.

Lessons Learned

HTML and CSS work well for print layouts. Browsers provided a reliable and flexible way to generate certificates without specialized tooling.
Templates make scaling easy. Once the certificate layout was templated, generating hundreds of certificates became trivial.
SVGs can be treated as templates too. Converting the border into a template made it easy to customize designs without maintaining multiple assets.
Manual steps can be the right starting point. Using Chrome’s Print to PDF feature was simple, dependable, and fast to implement.
Simple systems can go a long way. A lightweight architecture was enough to support over 150 tournaments and six years of iterative feature development.

A Programmer's Journey

Frank Riccobono — Sat, 20 Jul 2019 00:00:00 +0000

I was fortunate to be introduced to computers at an early age. According to an old school report I found in my hoard, we got our first family computer when I was four. You probably wouldn't take my dad for your typical computer geek, but he latched onto the technology when it started transforming the workplace. He, in turn, taught me the basics. By the time I was five years old, I already knew a handful of basic DOS commands. (At that point it was limited to switching directories and launching games – Reader Rabbit was an early favorite). By eight, I was using Microsoft Office to write silly short stories and PowerPoint to make “art."

I started programming almost by accident. Although I liked school and my teachers, I wasn't quite a star student in my earliest primary education. I hated coloring inside the lines, my penmanship was atrocious, and I've always tended towards absent-mindedness. I would forget to do homework or frequently leave books at home. That changed once I got to third grade and even more so by fourth and fifth. That's the point where school became less about learning behaviors and more about acquiring knowledge. I was (and still am) insatiably curious, and this new chapter of education was what I had been waiting for. I was also very impatient. I would look ahead in my textbooks, anxious for the next lesson even before the current one had fully sunken in. What was worse was that many of our books were longer than we'd be able to cover in a school year. I found myself particularly drawn to the final chapters that we would otherwise never see.

One day in fifth grade, something in the appendix of my math textbook caught my eye. It was an extra credit assignment of sorts written in a mono-spaced font. The instructions said to type the instructions into a program called QBasic, which at that time was still bundled with Windows. I don't quite remember what the program was, but it was something simple like a coin flip simulator. Whatever it was, when I entered the instructions, it worked! I was experiencing some new kind of magic that I didn't fully appreciate at the time. I flipped through the book and found a few more extended code listings and tried them out. I was exclusively following the textbook instructions, though. I had no idea what any of the keywords meant, and it never occurred to me to change anything or to try to write my own program.

BASIC...the entrypoint for many a programmer

Another joy at that time was the annual Scholastic Book Fair (I’m a nerd if you haven’t figured that out by now). A year or so after my first foray into QBasic, I found a book and accompanying CD at the book fair called“Learn to Program BASIC” by Interplay. In it, a bizarre-looking cartoon character named Media Man( reminiscent of Clippy) taught you through wacky video clips how to write a dialect of BASIC developed by the game company. I learned about strings, subroutines, sprites, arrays, and much more. I still didn't stray far from the tutorials, but I was able to internalize much of the material. In particular, programming in an XY-coordinate system gave me a leg up in math class when we started learning how to plot various graphs. It also helped in Computers Class where Sr. Blanche was introducing us to Logo.

LTPB felt more like a video game than a useful tool, though, and I lost interest when I’d finished all the lessons. I still never thought to try creating something original, and I did not do much more than that until another coincidence occurred in high school. I was chatting with a friend at the end of freshman year, and we somehow got into the topic of programming. His father was a programmer, and he was learning Visual Basic 6. I'd never heard of it, but it had Basic in the name, so I assumed it was similar to what I'd seen before. He agreed to teach two other friends and me. The four of us had bold plans to create a video game company that summer, powered by VB6. Those plans never materialized, but I did learn the language and my friend, the ringleader, did write an Apple Catcher game that "went viral" in the sophomore class (before "going viral" was a thing).

Part of the problem with our ill-fated video game company endeavor was that we couldn’t agree on what type of game to make. I had suggested an RPG, not imagining at the time, how much work was involved. I spent the summer learning a bunch of things including how to do Bit Block Transfers (BitBlt) to remove the backgrounds from sprites (something I missed about LTPB), how to generate tile-based maps, and, most-ambitiously, how to implement the A* path-finding algorithm. When that last one (mostly) worked, I was ecstatic. Mind you, at that time, I still had no sort of formal training.

Throughout the rest of high school, I dabbled in various other technical things. I learned HTML/CSS in the age of CssZenGarden. I set up a personal website on Tripod and even wrote a few Perl-CGI scripts to automate some of the maintenance of it. My dad found this browser-based 3D game engine from Wild Tangent that allowed you to write in Javascript. I built a few simple websites for a theater company I was working with at the time. One of my favorite TV shows at the time, The Screensavers, introduced me to Linux and I started playing around with that in my spare time. It was all a hobby for me. I had no idea that I could make a career out of it.

My first website...what was I thinking?

When the college admissions process started in my junior year, I received an advertisement for a summer program at one of the schools I was considering (Stevens Institute of Technology). The program allowed high school students to take an online college-level class over the summer. I signed up for CS115, Introduction to Computer Science. I didn't know what "computer science" was at the time, but the syllabus mentioned programming, and that was enough for me. The class involved learning Java, which had enough in common with VB6 that I was able to pick it up pretty quickly. That class convinced me to choose the heretofore unknown Computer Science as my major when the time came.

I ended up attending Stevens for college. It was a blur of languages including C, PHP, Assembly, Scheme, Matlab, MySQL, and even a smidge of COBOL. Like most graduates, I thought all that was everything I needed to know about programming. One concept I later learned was conspicuously missing from the CS course load was the idea of "Legacy Code" and how to work with it.

My first job out of college had me working with a several-years-old Java project that had been cobbled together by outsourced contractors. I can't say too much about the experience due to confidentiality agreements. It suffices to say that academic knowledge of Java did not prepare me for J2EE, or for making sense of tens of thousands of lines of code and a bunch of terrible variable names. I was not given a lot of guidance since our lead developer worked remotely and only at night. And my conservative inclination left me afraid to change much. I did eventually get to the point where I could contribute to the project. I was writing software for a business, but I had no real sense of what business software engineering entailed.

Programming in the "Real World"

The next milestone didn’t come until three years later. There were two sources. First, I was taking some graduate-level classes in Natural Language Processing, a topic that had long interested me. As bad as corporate code can get, academic code is generally worse. PhDs and grad students typically write software for an upcoming paper and, unless their discipline is software engineering, they usually don't write with maintenance in mind. "Battle-scarred" as I was by the corporate world, I rejected this writing style and strove to try to make any code I wrote for those courses as clean as possible. This goal required reading lots of tutorials outside of class, but I think it paid off. Most of those courses required us to code in Python, and I made an effort to learn the Pythonic way. For the first time, I wasn’t just thinking about whether or not my code worked but also how it was structured.

The other influence was a part-time gig I took on in between grad school semesters. One of my college professors contacted me regarding an opportunity with a startup looking for an intern. They were developing a Ruby on Rails e-commerce site. Ruby and Python had enough similarities that I was able to pick up the former pretty quickly, but Rails was eye-opening. I had never used a framework. I was fascinated by tools that not only reduced boilerplate code, but that also imposed structure on the application.

On top of that, the team was also using Capistrano to automate building and deploying the app, and they had AUTOMATED UNIT TESTS through rake! I had used simple makefiles in my college C-programming days, but, for a technology aimed at creating efficiencies, programming and testing of programs always seemed very manual to me. My college professors had even convinced us not to use IDEs when learning because they introduced too much magic. The idea that you could introduce automation and tooling seemed revolutionary.

In the end, the startup didn't work out (long story for another time, but no hard feelings toward anyone involved). In the meantime, I found myself in the lead developer role for that software product I had started working on after college. The time had come to put some of what I'd recently learned to use. Over the next few years, a junior developer and I worked to wrangle the legacy code. We imposed structure where there was disorder and wrote automated tests where there had been none. It was exciting.

All Hail Test-Driven Development!

Today we’re working on a new system. We’re using technologies like Hibernate in the back-end and React in the front-end. It's been a bit of a paradigm shift from never using any frameworks. There are various challenges and successes every day, but the best part is there is always plenty to learn. I can still be that curious kid, stealing furtive glances at advanced topics, that I was when I started.