EHVA: Building a Seminar Management System with Go
Note: This article was written retrospectively, years after the project took place in 2014. While it captures my experiences and challenges from that time, it's enriched with insights and understanding I've gained since then.
TL;DR
- Technologies: Go, Angular, PostgresQL
- Role: Full Stack developer focused on database integration and certificate generation in backend
- Key learning: Understanding Go's philosophy coming from Java - implicit interfaces, composition over inheritance, and explicit error handling
When my university colleague and close friend Johannes Tandler approached me about building a seminar management system together, I didn't hesitate. The project, which we named EHVA, would become my introduction to Go and mark a significant shift in how I thought about backend development.
The project scope
EHVA was designed as a comprehensive seminar management platform with classic administrative functions. The system needed to handle seminar organization, participant management, and certificate generation. We chose a modern tech stack for the time - Go 1.4 for the backend and Angular for the frontend. My responsibility centered on implementing the backend functionality, particularly the database integration and the complex task of generating participant certificates.
From Java to Go: A paradigm shift
Coming from a Java background, Go felt like stepping into a different universe. Java had taught me to rely on annotations, magical implicit functionalities, and the comfort of Hibernate ORM for database operations. Go presented a radically different philosophy with its implicit interfaces, composition instead of inheritance, and that distinctly different approach to error handling that every Go developer learns to appreciate.
I'll be honest - it took me considerable time to truly grasp Go's style and idioms. Even after six months working on the project, I'm not entirely sure I had fully internalized the Go way of thinking. The shift from Java's verbose but familiar patterns to Go's minimalist approach challenged many of my assumptions about how backend services should be structured.
The certificate generation nightmare
If there's one technical challenge from this project that still haunts me, it's the pixel-based generation of participant certificates. Working at the pixel level to create professional-looking PDF certificates was genuinely horrifying. Every element had to be precisely positioned, every font metric calculated, and every layout adjustment meant diving back into coordinate calculations.
This experience had a lasting impact on my approach to document generation. Today, whenever I have the choice, I opt for template-based PDF generation using tools like Word or Google Docs to create the layout template, combined with a compatible template engine for rendering dynamic content. It's a lesson learned through painful experience - sometimes the simplest solution really is the best one.
Lasting impact
This project with Johannes didn't just introduce me to Go; it fundamentally changed how I approach teaching and mentoring. Today, when I conduct workshops for developers transitioning from Java to Go, I draw directly on this experience. I remember the confusion, the "aha" moments, and the gradual understanding of why Go makes certain design choices.
Understanding both paradigms - Java's enterprise-focused, annotation-heavy approach and Go's simplicity-first philosophy - allows me to better explain not just the differences, but the reasoning behind them. I can empathize with developers making this transition because I've walked that path myself, stumbling over the same conceptual hurdles and eventually appreciating the elegance of Go's design.
EHVA may have been a university project, but its lessons continue to influence my work today. It taught me that stepping outside your comfort zone, even when it means struggling with new paradigms, ultimately makes you a more versatile and thoughtful developer.