Freeish Time: Taking Our Lego Board Virtual

When Cube had to go completely virtual overnight last March, we didn’t really skip a beat. The team quickly settled into working remotely and we just made it work. One thing we all instantaneously missed was our lauded 3 Sided Cube lego board schedule. For those that don’t know, many moons ago, we made the transition from scheduling projects on boring ol’ spreadsheets to our real-life lego board. That way every single Cubie knew what project they were on with a quick glance at the wall.

It was the epicentre of the agency. PM’s and Devs could usually be found hashing it out and meticulously planning the perfect schedule for all. And all done with lego pieces in every colour under the sun representing a project. It was a core part of Cube.

Until we all had to WFH and no one had access, so we had to make do with our old failsafe.

I was talking to our PHP Developer, Javi about the schedule and how he’s had a much better experience with scheduling since we started using a Google doc. He’s lived in Spain for a few years now and always found it difficult that we relied so heavily on something he couldn’t interact with, so would miss the functionality of accessing the board remotely.  With the return to work coming soon (FINGERS CROSSED!) I wondered if this problem would haunt him (and our other remote Cubes) again shortly. Our Lego board is great but it’s not terribly scalable or accessible!

Although the existing Google doc works it sometimes feels a bit clunky and it’s hard to generate reports from. So I thought I’d try to make an internal web application for Cube to use for scheduling. Given that I only had a week to make a usable web application I thought this would be a great time to try some RAD (rapid application development) tools to speed up development!

I started off by framing the problem in the form of user stories. From here I made an entity-relationship diagram using the nouns from the user stories. I then wrote down the views I’d need to create and designed the API that would support them. I hastily put together a rough UI design.

I started with the Laravel framework and used Laravel Sail as my development environment. Then I added Laravel UI to help scaffold the authentication and authorisation. From there I scaffolded the models and set about writing the controllers and views. This wasn’t too tricky as I’d already defined what I would need during my planning phase!

By utilising the power of the Laravel framework I made good progress… thank goodness I was using a framework. When I cast my mind back to framework-less development in the early noughties I wonder how I ever got anything done on time!

On the front end, I opted to use a sprinkling of Alpine.js to compliment Blade’s templating. This is the first time I’ve used Alpine.js and I must admit I’m a huge fan of it! My experience with SPA frameworks is limited to AngularJS and Vue.js. Both seem over-complicated when I think about how easy it was to use Alpine.js!

Sail is such a time saver! Having to write Docker Compose files by hand is a chore and knowing that the Docker images are maintained by Laravel is a breath of fresh air.

Although SPAs are popular and commonplace in modern web application development, I think SSR still has value to offer. Its simplicity is what makes it useful when prototyping or developing MVPs. Continuing along that train of thought, I really love the ease of use of session-based authentication. Again, it doesn’t scale very well or allows other platforms to integrate easily… but this is an MVP! Who cares, right?

Alpine.js is awesome. It’s perfect for adding some SPA-ish interactivity to an SSR project. I will definitely be using it again!

I guess what I’m saying is:

• Web application development doesn’t have to be difficult when building something small.
• You don’t need to model your small application on FAANG technologies and practices… in fact, if you do this you will over complicate things and slow down development!
• Using a well-supported framework with a great community will save you lots of time and hassle. Laravel is the undisputed king if you want to do that in PHP land!

Originally I added Laravel Breeze to help speed up the scaffolding of the UI. After pulling my hair out for an hour trying to figure out how things worked I reverted back to Laravel UI. Breeze is a lot more complicated than its predecessor, I think when prototyping it’s important to use what you know (if you want to ship something on time).

It really was just about getting on with it. I kept it simple and mini-project managed (Sophie would be so proud!) and the process was really straightforward.

If it’s a success I (and the rest of the production team) will use it every day! There was even talk of it being displayed on a TV where the existing schedule board is so watch this space to see how it turns out…