This year’s Laravel community conference — aka Laracon — was hugely informative and presented a number of interesting pieces of technology that are being put to good use by other professionals in our industry. We will be exploring this technology in the coming weeks in order to determine what we will be adopting as part of our everyday workflow here at Plank.
Here are some of the highlights:
A Practical Look At Multitenancy in Laravel
Freek Van Der Herten, Package Creator at Spatie
This talk explored how one of the most well known package developers in the Laravel community, Spatie, approaches this problem of multi-tenancy. Freek presented a package he wrote that simplifies this process. This is a rather interesting tool that allows you to juggle multiple databases in a single project, which is useful if you want to separate things like French vs English databases. This is especially relevant to Plank given that the Evenko festivals sites that we maintain are a group of multi-tenancy sites. While this may be overkill for our current projects, it will definitely be worth considering for future projects.
Building Modern Monoliths with Inertia.js
Jonathan Reinink, Creator of Inertia.js
This has a lot of merit for JS-heavy sites, and could save us a significant amount of time with minimal adjustment to our workflow.Massimo Triassi
Inertia.js allows us to send data to Vue pages a lot more easily, and simplifies the process of creating single page apps. The back end portion acts a lot like blade so we would just need to send data. The only difference is Inertia sends everything to the front end user, so we would need to be more careful in monitoring what information gets sent.
This is a great tool to reduce boilerplate API code and save precious development time. Ultimately, whether it’s going to be in the form of Inertia or Livewire, both aim to solve the same problem—one relying on blade/php, and the other on vue.js.Andrew Hanichkovsky
Exploring Laravel 8.X
Taylor Otwell, Creator of Laravel
Taylor introduced us to all the exciting new features coming to Laravel 8—including improvements to jobs, factories, rate limiting, and more—and announced their renewed commitment to open source software. Notably, Taylor announced Jetstream and Fortify, two entirely new packages in the Laravel ecosystem.
While not every new feature will prove to be relevant to the way we work, there are a few that stood out. For example, factories are moving to a class-based structure, making them a lot easier to write. There are a lot of changes to jobs that allow us to better define what happens when a job fails, or to easily create batches of jobs.
Tayor also explored some of the more popular stacks in Laravel that we will likely be adopting: Tailwind, Alpine, Livewire, Laravel (TALL) and Laravel, InertiaJS, and Tailwind (LIT) seem to have good popularity in the community, and might serve us well to start using as they have excellent integration via Jetstream.
I really like the changes, my personal favorite being the changes to the model’s default directory and being able to export the current database and clean up all the old migrations. I also appreciate the Jetstream changes to the default landing pages. Having 2-factor authentication built in is a REALLY useful feature.Evan Dimopoulos
Supercharging Laravel Apps with Machine Learning
Prosper Otemuyiwa, Cofounder of Eden
In this talk Prosper explored the integration of existing Machine Learning platforms to add utility to web applications. He detailed the package he developed, Laravel ML-Kit (not yet released at the time of this post), that works a little bit like Scout and allows for quicker integration of the larger ML platform available; like those available from Google, Amazon, and Microsoft Azure.
If reality lives up to what was shown in the presentation, this promises to be a really great tool.Evan Dimopoulos
The Importance of Practice
Colin DeCarlo, Developer at Vehikl
As one of the ‘development adjacent’ talks, this touched upon the need for setting aside time to practice and learn new skills outside of client work, so that we are better prepared for future projects. He noted the difficulty of effectively learning something while working efficiently, thus how separating them goes a long way. Colin performed a highly efficient refactoring in real time, owing to the skills he’s honed, and explained how he finds time to practice programming.
“When you want to do something well when it matters, practice when it doesn’t”Colin DeCarlo
He effectively drove home the point that scheduled learning time is essential to leveling up our team. He presented a “Good Day / Great Day” style of thinking. Under this mentality, a good day refers to spending 80% of your time doing what you would do over the course of a regular work day, meaning your typical problem solving and solution creating. Preferably, these tasks would be completed in order from a list you had drafted the day before. A great day then refers to what you do during the remaining 20% of the day, which would be spent learning something new, or fixing some internal tool that helps to alleviate the team’s daily task burden.
Don’t Cry When Your Dev Dependencies Die
Matt Stauffer, Partner at Tighten
Matt explored Docker—popular amongst agencies in their development and production environments—and proposed ways to dockerize the dev environment. He presented an OSS tool called Takeout, that aims to simplify the process of using Docker in a development environment.
This is potentially a useful pattern for us to use at Plank, and we will be discussing its use in the coming weeks. However, we will need to consider whether there is more value to writing our own docker environments; as Docker can be quite complex and difficult to use without someone on your team who understands it.
Refactoring to Simplicity
Marcel Pociot, Managing Partner at Beyond Code
Marcel is a notorious developer in the community, so he had our full attention. He used this time to remind us that while it’s quite easy to write complex code, it’s surprisingly difficult to write simple code that is easily understandable. (It should be noted that Marcel used Tinkerwell for the demo — a sandbox environment tool that supercharges the use of Tinker and allows you to execute snippets live, making it easier to refactor and simplify your code.)
Human-readable code is better for the lifespan of the code, assuming it doesn’t jeopardize the efficiency of the product. When a specific piece of code isn’t properly expressive, it makes it difficult to understand what it’s supposed to do when you return to it later. More explicit variable names are helpful, for a start, as default ones can be misleading. In order to develop more expressive code, he advocated for investing time into reading other people’s code and reviewing pull requests as ways to better understand what works and what doesn’t.
Stay tuned for more!
We’ll be following up in the coming weeks with a wish list of the skills that we want to level up, along with a plan for how we will support each other in that commitment.