On March 8th 2017, I attended the very first Laracon Online event. This official Laravel conference was entirely streamed live, the speakers were doing their talk from their home/office. The atmosphere was pretty different compared to a traditional conference, but the formula worked very well for a single-day event. Luckily for me, the schedule was based on the same time zone as mine, so I could enjoy the presentations live, without sacrificing sleep. However, for those in different parts of the world, recordings were available the very next day. The conference was packed full of great content, even for someone slowly learning Laravel on the side. Here is a write-up of my notes and what I learned, from the standpoint of someone learning the framework.
1- Jeffrey Way: Laravel Mix
Jeffrey Way is an active member of the PHP/Laravel community and founder of Laracasts.com. Laracasts is an amazing collection of video tutorials to learn Laravel and other web-related technologies/tools, it’s definitely a great place to start when learning web development.
In his talk, he presented Laravel Mix, a wrapper around webpack. I knew a bit about WebPack, but Jeffrey clearly defined its role and differences with Gulp. Basically, Gulp is a task runner, configured to execute some process upon some events. On the other hand, webpack is a module bundler which can do specific tasks such as dependency bundling, tree-shaking, minification, obfuscation, etc.
webpack stands on 4 concepts to accomplish its work:
- Entry: Defines what must be processed
- Output: States where to store the results
- Loaders: Allow to handle different file types such SASS, TypeScript, etc.
- Plugins: Can add build steps, like uglify, to the webpack’s pipeline
To facilitate the integration of webpack into Laravel projects, Jeffrey developed Laravel Mix which streamlines the configuration of webpack for the 80% use case. In his talk, he compared raw webpack configuration with the one provided through Mix. It helped me better understand why it’s useful and sparked curiosity to learn more about it and Vue.js.
2- Evan You: Inside Vue Templates
3- Rachel Andrew: CSS Layout with Grid and Flexbox
Rachel Andrew is a Google Dev Expert for Web and a collaborator to the CSS Working Group. She talked about the tools we have to build a modern web layout such as floats, inline-block, display-table and relative or absolute positioning. She explained how these tools are evolving to support the growing need for responsive layout. There are many CSS frameworks which try to provide easier way to build such layout, but the W3C is also working to expand the CSS specification with new mechanism.
Flexbox and Grid Layout are both under the status Candidate Recommendation which should bring widespread browser support when officially adopted. These tools allow to build responsive and relative layout by giving relationships to elements. Each element then understands its place along within the layout. The difference between these is that Flexbox is intended to layout items in a single dimension, either rows or columns, not both. On the other hand, a Grid is used when both dimensions are needed for the layout, rows and columns. Rachel offers a great comparison of both systems on her blog.
As stated earlier, not all browsers support Flexbox or Grid, but you can use CSS’ feature queries to enhance layout when available. It’s an interesting trick because it allows you to gradually include new CSS feature without breaking backward compatibility.
Here are a few links to learn more about these modern layout tools
4- Adam Wathan: Alternate facts about testing
When starting out with TDD, we learn to
- Use mostly Unit tests
- Not touch the database
- Run tests in isolation
But… aren’t tests kinda coupled to implementation details? We learn that good code is testable code, but tests can also be adapted to what were are really trying to validate. Refactoring is a wonder of software development and strongly encouraged by TDD. Sometimes though, isolated unit testing gets in the way. That’s when you should consider using feature-tests, which validate behaviour but allows greater flexibility in implementation details. There are also valid cases for combining unit and feature tests like when you encounter redundancy in your test, for example testing a database save in multiple routes. In the end, nothing stops you from adapting the tests to your needs and there is no one true way to test an app.
Jason McCreary, another speaker of the conference, wrote an interesting response to Adam’s talk.
5- Taylor Otwell: Laravel’s internal
Taylor Otwell is the mind behind Laravel. He created the framework in 2011 to make it easier to develop for the web platform. His talk was about Laravel’s architecture and inner working. He detailed the flow of an HTTP request through the framework, from the initial request to the response. It was a really nice technical overview of a framework that I grow to love more and more every time I play around with it.
Since Laravel is open-source, Taylor explained how to contribute to the framework and his configuration to modify the framework’s source code. I liked that he touched that subject since that’s the community around Laravel that made me choose it when looking at web tools some time ago.
6- Nick Canzoneri: What developers should know about emails
Nick Canzoneri from Postmark talked about the inner working of email. He presented the format of an email, which looks a lot like an HTTP request with a header containing metadata and allowing us to add custom entry. Emails always have a content-type attribute for the body content that can be plain text or HTML. Apple even has a special content-type to display email on the Watch.
He also explained some security mechanism to make sure our emails don’t get spoofed, tempered and get delivered. The security methods presented are all somewhat DNS-based:
- SPF: TXT Record to validate identity
- DKIM: Private Key identication through SMTP header.
- DMARC: Domain-based authentication built on top of SPF and DKIM which allows to manage what to do when validation fails
It was pretty interesting to learn more about emails, a tool that we all use pretty much every day.
7- Jason McCreary: You don’t know Git
Jason McCreary(https://twitter.com/gonedark), creator of Laravel Shift and Getting Git, made a summary of some known and other more obscure git commands. I really liked his style and his talk made me want to learn more about git so I bought his course, Getting Git. I loved his philosophy to use git through the command line so you have to learn it once and can use it forever in any environment.
Here are some commands I learned:
* git add -p : goes through all the changes and allows you to stage them or not
* git add -i: interactively add untracked files
Slow down the commit process to get it right the first time.
* git commit –amend
* git commit –amend –no-edit
You should not amend a pushed commit, because the commit’s hash is updated so it invalidates other contributors history.
* git stash
* git stash save “doing crazy things”
* git stash pop
* git stash apply: stays in the stack
* git stash –include-untracked
* git stash list
git rebase -i
* git rebase -i: interactive
Reworks past commits, it updates SHAs, so be careful.
* git cherry-pick [commit hash]
Pull a specific commit in.
* git bisect [good commit hash] [bad commit hash]
Go through all commits to find when code has changed
He also presented 2 branching strategies:
- git:3 long-lived branches: dev, staging, master
- GitHub one, with a single long-lived branch, master, but many short-lived feature branches.
I personally prefer the feature-branching approach, I usually work on smaller projects so it reduces the merging overhead and gives me a more straightforward workflow.
8- Matt Stauffer: Mastering the Illuminate Container
Matt Stauffer from Tighten and author of Laravel: Up and Running made a great explanation of the Illuminate container. This basically wires everything up together in a Laravel app like routing, middlewares, requests, constructor injections and Facades.
As a beginner Laravel user, I effectively wondered how my app was put together and why I could access injected dependencies. Well, what you will sometimes see called the IOC container(inversion of control) or DI container(dependency injection) makes it all possible. It’s the glue that allows different components of the app to work together. It can resolve instances through the container and abstracts away the dependencies using auto-wiring and reflection to instantiate them. You can extend the behaviour of the container by manually binding a dependency to the container with a closure. You can also create aliases to request instances easily just like the one provided for Laravel’s Facades like logger, config, etc.
One common use of the IOC container is to allow the use of Service Providers. They bind services, grouped by functionality, to leverage Laravel’s bootstrapping mechanism. This means that we can register event listeners, middlewares, etc. It’s the responsibility of the service provider to register itself with the container. Then, its boot() method will be called once all registrations are complete to allow further configuration.
It’s really nice to learn more about the inner working of your tools. You are then much more confident to employ them. That’s why I bought Matt’s book, I want to learn more about Laravel and the right way to use the framework.
This first online and distributed conference was a success on every aspect. There were absolutely no technical problems, the streaming quality was great. The talks were very good and covered different subjects related to web development, applied to Laravel. Also, I especially liked those explaining the core concept and inner working of the framework. I definitely look forward for next year and can’t wait to build something with Laravel and Vue!
I stumbled upon a pretty nice GitHub repo containing lots of links and resources about the talks.