Laracon 2016 Recap

Shameless plug alert: Thanks to the fine folks at VIA I was able to attend Laracon2016. Being at a company that places such a strong emphasis on professional development is an exciting and empowering prospect for anyone. For developers it is a must. It is easy to get caught up in your day-to-day work, losing track of the ever-changing technologies. Conferences not only give you a crash course in the new hotness, but can re-energize your love of coding.

Second, but unrelated, plug: Laracon was spectacular and I could not recommend it more. The Kentucky Center for the Arts is a great venue. The Bristol catered all lunches. Each speaker was well prepared and shared a wealth of information. Many speakers made adjustments to their talk when another speaker had touched on a similar topic. This reduced redundancy and allowed them to cover more. Oh, and the first hour after the conference the drinks were FREE!

Now on to the actual point of this blog post. Brief recap of what I learned: Taylor Otwell is a rockstar, the PHP community loves stuffed elephants, Laravel 5.3 & Vue.js 2.0 are spectacular, and sometimes your code smells, but that’s okay, unless it’s not. Make sense? Great! If any of this is of interest to you, read on. I will be breaking down my conference experience into a brief overview of each of the three days.

Day 1

Taylor Otwell, the creator of Laravel, walked onto the stage. The place ERUPTED. I thought I was at a concert instead of a conference. People were whooping, cheering, whistling, and yelling. I had never experienced anything like it at a conference. It is safe to say the Laravel community is passionate – they kept it up the entire three days. Anytime Taylor stepped onto the stage, the crowd showed their appreciation for his efforts.

Taylor and the Laracon team tried out a new format for the first day of the conference this year. Instead of the standard hour, the day 1 talks were an hour and a half. A few people around me did not like the extra time. The majority of complaints being about having to focus for that long.

I could not disagree more. The extension gave the speakers time to deliver their talk and to do more live coding examples. Not to mention, why would you come to a conference if you were not there to pay attention and learn?

Test Driven Laravel – Adam Wathan

The first talk of the day was “Test Driven Laravel” by Adam Wathan, which covered the TDD approach to development. The majority of Adam’s talk was live code examples, so I did not take as many notes as some of the other speakers. One of the main nuggets of information I took away was to not try to implement TDD around an existing code base.

I had never heard that piece of advice but it makes perfect sense. With existing code in place, your inclination will be to write tests that make your current code pass. This will give you a false sense of security based upon those poorly written tests. Adam stressed learning TDD with a new code base. Once you are completely comfortable in the environment, you can adapt your legacy code.

Vue.js Workshop – Evan You

Evan You, the creator of Vue.js gave the next talk. If you have not yet heard of Vue.js, read this.

Why is a Javascript framework talk at a conference for a PHP framework? Javascript is becoming increasingly important in the world of the web. Starting in Laravel 5.3 (more on that later), Vue.js will come bundled with Laravel.

Evan gave a brief overview of the history of Vue, Taylor’s role in its rise in popularity*, and live coded a todo app. The todo app is the go-to example when learning a new language or framework. Vue.js 2.0 is completely stable and will be released soon. As such, Evan’s todo app was written in the 2.0 version of the framework.

One major selling point of Vue.js is the ability to drop in a link from a CDN in a project and you are ready to start using Vue. Coming from the React ecosystem, this was a pleasant surprise. You would not want to use the CDN link in a large scale production application. For a proof of concept or simple personal project it has great value.

* – Evan showed a graph of the daily downloads of Vue. It was a fairly flat line. After Taylor’s post, the downloads increased at a 45 degree angle.

Laravel 5.3 Overview – Taylor Otwell

Taylor walked out to a raucous reception for this speech. This talk covered the most information of the entire conference. I was thankful he had the extra 30 minutes discussed earlier. Everything Taylor did in this post is well outside the scope of this article, so I will touch on just a couple things.

Laravel Scout is an optional Laravel package. It is a driver-based, full-text search built on Eloquent. This means the Eloquent events (save, delete, update, etc.) can be bound to the Scout package to push updates to your search system. For example, say you have an Algolia search implementation. First configure your drivers for that system. Scout would then push updates to your search index as you alter the data you are indexing. This keeps your search index in sync with your live data without the need for a CRON job. Cool, right?

Laravel Mailable is the new implementation for sending mail in Laravel. Mailables allow you to keep the separation of the data / logic and the view template of the mail. In a large scale application, this is a great benefit.

Day 2

For the remaining days of the conference each of the talks were an hour long. In trying keeping this article (relatively) succinct I will not cover every talk.

The three presentations that most tickled my fancy from day 2 were: Zeev Suraski – PHP 7, Matthew Machuga – Tests Should Tell A Story, and Sandi Metz – Get A Whiff Of This.

PHP 7 – Zeev Suraski

Zeev Suraski is one of the creators of PHP. His involvement began when he was a computer science student. He and his group decided to use PHP/FI** for a project. Their teacher warned them that there would be problems with the language. She was both uninterested in and unwilling to help should they encounter issues. She was correct in her assumption. Zeev and the other members of his group dug into what was never intended to be a programming language. Zeev has stayed involved since then and continues to be a driving force in the development of PHP. So, who better to discuss what happened with PHP 6 and introduce what is coming in PHP 7? No one!

PHP 6 History & Problems

PHP did not have unicode support at the core of the language. Announced in 2005, PHP6 was to correct that. Issues became immediately clear. There was a lack of developers with an understanding of what needed done. This lead to performance issues with the UTF-16 support. The implementation used more memory and lowered the number of concurrent requests available. Those are both no bueno. Pronounced dead on March 11th, 2010 at 11:09:37, PHP 6 was no more.

Another issue that PHP detractors had with the language was its speed. PHP has been trending in the right direction speed-wise for quite a while now. The first major breakthroughs was in PHP 5. The language converted to a true object model without being slower than its predecessors. Enhancements to the language’s parser reduced its memory overhead and CPU consumption. Which increased real world speed. All good things.

Improvements in PHP 7

PHP 7 is more than 2x faster than PHP 5.6 and they are still achieving performance gains. When you couple in the dramatic speed increases along with the new features of PHP 7, you could say things are going well in the PHP world.

** – PHP /FI was an embryonic version of PHP. Zeev is on the far right of the picture from the link above

Tests Should Tell A Story – Matthew Machuga

Matthew’s presentation focused on thinking of your tests as a story. Humans have been telling stories since the beginning of time. What is forgetten is that we have also been interpreting stories for that long.

Take the classic game of telephone. A statement whispered to someone gets told the next person until the last person declares aloud what they heard. Generally, the statement that the last person gives to the group is a far cry from the initial statement. This same scenario can happen in a code base. Especially one developed and maintained by many people. It is easy for the original developer and any close collaborators to keep track of a feature while they are working on it. Step away a few months, or open source the project, and the clarity will not be the same.

BDD development can ensure that the story your code is telling is understandable to anyone working on the project, regardless of experience, skill level, or primary language differences.

Get a Whiff of This – Sandi Metz

Sandi’s talk centered around the well-known construct of code smells and how to categorize and refactor them. A code smell is bad code in any of the various forms it can manifest itself. No one writes perfect code. Identifying issues with your code and refactoring is the process of eliminating code smells.

She broke the code smells into the following categories: bloaters, tool abusers, change preventers, dispensables, and couplers.

Bloaters

Bloaters can be refactored into more simple and focused parts that do the same thing. An easy to understand example of this would be a large class. Tt would be easy to write a user class that contains everything an individual user may contain. Such as, contact info, authorization and access control, a user profile, etc. This should be broken into many classes. The software is easier to understand, more modular, and adhere to the single functionality principal.

Change Preventers

Change preventers make the task of refactoring difficult because of the effort required to fix them. Let’s say you wanted to make some updates to a class. But by doing so you would have to make several changes to several unrelated methods. This is a change preventer. Your updates to your class should not affect other unrelated systems in the project.

Sandi recommended Martin Fowler’s Refactoring book. The book has a refactoring recipe for every single code smell, which is great. Now all you need to know is how to recognize the bad code, Martin will lead you through how to fix it!

Day 3

The last day of a conference can sometimes feel stale and lack a little bit of energy. That was not the case with Laracon. The two talks that most captured my attention were Chuck Reeves’ Practical Software Estimation and Jason McCreary’s YAGNI talk.

Practical Software Estimation – Chuck Reeves

One of the most difficult things in software development is estimation. To build something for a client, they most often want to know two things: how long will it take and how much will it cost. The only problem with those two questions are that time and cost go hand-in-hand. You can’t always know about potential pitfalls that may exist. You need a lot of information to estimate a project accurately. The problem is you cannot always get that information until you have begun development of the project.

How do we go about mitigating this risk? Chuck’s presentation focused around the following concepts: defining actors, looking for requirement smells, using historical data, doing a dry run, defining your confidence interval, using fuzzy logic, and wideband estimates.

Defining Actors

Defining your actors is the process of determining who will be interacting with what you are estimating. Chuck’s example was that of a contact form. There were the leads (people filling out the form) and the sales team (people contacting the leads). These two groups, or actors, do not interact with the form in the same manner. Thus the requirements would be different for each group.

Requirement Smells

Looking for requirement smells is much the same process as finding code smells. His examples included language like: quick, easy, user friendly. What is the definition of user friendly? You could ask 100 people and get 100 different answers. Try to break those requirement smells into clear action items.

Confidence Interval

Think of your confidence interval like a weather forecast. The meteorologist rarely says there is a 100% chance of rain. It better to be roughly right than preciously wrong.

Wideband Estimation

Wideband estimation is the process of having several people estimate a project. You then get together as a group to discuss each estimate. There will be a variance in opinion of the amount of effort and time at stake which will lead to a discussion. The best estimate is most likely to fall between the extremes of the different estimates. The discussion will help point out any pitfalls that may be missing from one estimate to the others.

YAGNI in Laravel – Jason McCreary

YAGNI was a completely foreign concept to me before Jason’s talk. The acronym itself stands for You aren’t going to need it (ain’t if you’re from Kentucky). The presentation had three parts: WYS – what does YAGNI solve, SMTC – show me the code, and SOY – stages of YAGNI.

WYS

The three major concerns that YAGNI helps with are over-engineering, MVP, and KISS. Most software developers would admit that, when presented with a problem, they start dreaming up all the different components needed to solve it. On the whole that is a good thing, but can lead to an over-complication of the solution. One of the key tenets to YAGNI is the implement each feature as you actually need it, not just when it is a perceived need. Basically, do the simplest possible thing to make the code work. We can add to it as needed.

SMTC

Refactoring and YAGNI play into each other. By practicing YAGNI you are writing simple code. Refactoring code makes your existing code more simple. This creates a positive feedback loop. Thus your software becomes easier and easier to understand. For example, the welcome controller in Laravel contains a method which displays the view. Well, all that code is not needed. We could just return the view from the route definition. We can add the controller when we reach a point that the welcome screen needs more.

SOY

Jason broke the stages of YAGNI into laziness, challenge your assumptions, empowerment, and confidence.

His premise was that at first you feel like you are just being lazy. There is an innate part of a developer’s brain driving him or her to write code for all the requirements right now. With YAGNI you are fighting that somewhat by only doing what you need at that moment.

Challenging your assumptions will help you get over that feeling of laziness. If you ask yourself: do I need this right now? If so, do I have everything I need to start and do I understand the problem? These questions help you get past your initial reservations and begin to embrace the principles of YAGNI.

Once you reach the empowerment stage you no longer feel like you are just saying no to everything. At this stage you know when you are not ever going to call YAGNI. Some examples are: learning something new, implementing security features, testing, abstracting external code or implementing business requirements. You have embraced the fact that you are not doing things intentionally wrong using YAGNI as an excuse.

Having gained your confidence with YAGNI you will recognize those things you thought you needed right now can be addressed in the future. You are now confident in your ability to pivot quickly. You are writing less code and the code that you do write is simple and easy to understood. Which is the point of YAGNI.

Conclusion

If you made it this far you are a real trooper and I appreciate it. I hope you have learned something from my Larcon2016 recap.

My notes are available on GitHub. You can also watch all the presentations for free.