One of our Cubes tackled digitising our lego schedule board during his innovation time, read further to see if he was successful!
Time for the latest and greatest to come out of Freeish Time! Just to refresh your memory, “Freeish Time” is the opportunity for our Cubes to focus on their passion projects outside of their work commitments. They have an entire week to identify a problem, build and create a solution, then present it to the rest of the team during our Friday Happy Half Hour meeting.
This has become an integral part of 3 Sided Cube. The encouragement and time to work purely on whatever their heart desires, all while getting a little reprieve from the normal hustle and bustle from the normal workload is a welcomed treat. Whether they opt to go the “innovation” or “education” route, that invaluable time to focus purely on whatever it is that intrigues them is pretty rad.
The sky’s the limit when it comes to Freeish Time. We got to sit down with Tom, our RIDICULOUSLY talented Server Team Lead, to chat about his latest innovation…
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:
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…
Published on March 30, 2021, last updated on March 31, 2021