Laracon EU 2017

By Maximilian Pohlmann • 11. September 2017

We went to Laracon in Amsterdam and gathered lots of take aways and this is our summary of our personal favourite talks.

Laravel is a popular PHP Framework for which each year three conferences are held. One online and two to attend as a visitor in America and Europe. These are called Laracon and we – Sebastian Stach @StachOverflow and Kim Hogeling @KimHogeling – went to Amsterdam’s conference. Laracon consists of three days, one workshop-day and two conference days – we attended the latter.

CONFERENCE DAY #1

Our favourite talks of Tuesday.

FROM ZERO TO MULTI-PLATFORM CHATBOT WITH BOTMAN

by Marcel Pociot @marcelpociot – Creator of Botman

Conference day one was started by Marcel Pociot. He pitched his BotMan PHP chatbot framework. Often we don’t enjoy pitches, but Marcel did a great job showing off how awesome BotMan is!

We were more than happy to have him talk on our Laravel Meetup in Hamburg too.

If you’re interested in developing chatbots in PHP, you should without a doubt take a look at BotMan.


DENORMALIZATION WITH ELOQUENT: HOW, WHY AND WHEN

by Max Brokman @MaxBrokman – Lead Developer – Information Systems, Vice Media

PROBLEM

We’re conditioned to think in a normalised way to persist our data in an ERDB. This is a performant way to store your data with an eye on reducing information redundancy and consistency. But because users need to see the data consolidated – not scattered as it’s stored -, we see ourself in a position where we have to collect data from multiple tables.

Sadly, collecting it all can be time consuming due to the use of JOINs for connecting the data. It gets worse when you try to filter and have to use subqueries. In Laraval you don’t see that complexity on first sight, because Eloquent encapsulates it for you.

Denormalization tries to solve this performance issue from the user sight of view. The idea is to collect the data before users try to access it.

SOLUTION APPROACH

First approach of implementing denormalised access could be introducing database views, but – as views are not real tables – these also use queries (including JOINs) to gather the view’s data on every access. Views don’t solve our problem.

The second approach is introducing materialised views, which are real tables and hold the data prepared in advance for the views. To fill these materialised view, there are different solutions and it depends on how your needed level of consistency.

  1. Fill the table once – reasonable for data which never changes
  2. Fill the table in defined intervals e.g. every day at 6am – the less time this fill process needs the more often you can run it
  3. Apply additions/changes/deletions of the source data right away
POSSIBLE IMPLEMENTATION IN LARAVEL

With Laravel’s ORM Eloquent you can achieve the third option per example by using event hooks. After the model gets saved you can add a process to a queue which updates all corresponding data in the materialised view. This mind remind you of CQRS as you separate reads and writes in different classes.

Max also gave some pro tips for running such a system:

  • Monitor the queue, because this is the process which provides you consistency
  • Write a command, because you need to be able to rebuild your materialised views from scratch
  • Design you denormalised model in a way to ensure it can’t get updated incorrectly

TRANSFORMING PHP

by Christopher Pitt @assertchris – Developer and writer

We often wish to be able to use syntax we know from other languages. The normal route to enhance the PHP core language, is to go through a long process which might fail.

  • Write an RFC e.g. RFC arrow functions
  • Write a patch in C
  • Hope it will be popular and gets implemented into PHP’s core

To speed it up for yourself, you could create/use a custom compiler.

Some impressive examples which Chris was able to add

  • template markup – inspired by ReactJS
  • pipe operator – inspired by Elixir and Elm
  • short closure – inspired by JS
  • async await and promise – inspired by JS

To achieve this Chris’s combined the YAY library with his own preprocessor library.

  • YAY’s syntax macros enables him to define custom PHP syntax and map it to actual PHP code
  • His preprocessor ensures the macros get interpreted before the actual application bootstraps

After defining the macros he was able to write code with a pipe operator for chained function composition

$result = caps('Hello world')
          |> reverse($$)
          |> wrap($$);

instead of less readable inside-out-composition

$result = wrap(reverse(caps('Hello world')));

and short closures without the need of specifying the variables from the outer scope in the signature via an use keyword

$term = '.';
$greet = ($name) => {
    return "Hello {$name}{$term}";
};
$greet('Chris');

instead of full closures with all of the boilerplate signature with function and use keywords.

$term = '.';
$greet = function ($name) use ($term) {
    return "Hello {$name}{$term}";
};
$greet('Chris');

But why would I want to use YAY and preprocessor for this?

  • it gives you the option to define new syntax in PHP, which might be easier than writing a core patch if you’re not familiar with the C language
  • it might be quicker than writing and compiling a core patch
  • it probably is faster than waiting for the long process of RFCs
  • it gives you the option to try new syntax yourself first to see if you still like it after longer usage, before writing a RFC

For further details take a look at the slides.


CODE REVIEW BEYOND CODE STYLE

by Hannes Van De Vreken (@hannesvdvreken) – Software Engineer at getstream.io

Code reviews are a must, but when reviewing code you don’t want to waste time coming across violations of code conventions/style. Prevent this by simple solutions like implementing code linters/sniffers into your workflow to detect code violations.

Why is not using linters/sniffers a problem?

  • you miss direct feedback that would help you to get used to code conventions
  • you waste your coworkers time by making them fix/communicate your violations
  • you are sloppy and get the reputation of an unprofessional developer
  • you distract your coworkers of reviewing the actual logic in your code

At shopping24 we even go some steps further:

  • we use a git pre-push hook to prevent pushing any violations
  • we introduced SonarLint which “is an extension to your favourite IDE that provides on-the-fly feedback to developers on new bugs and quality issues injected into their code.” to detect quality issues e.g. common bad practices
  • we develop in pairs which is fun, has lots of benefits and decreases review-ping-pong

It made us happy to hear Hannes’s opinion of code reviews fits well to ours.


MONADS IN PHP

by Christopher Pitt @assertchris – Developer and writer

Chris’s second talk was about monads. He approached it well by using practical examples. At shopping24 we already use monads in JavaScript for our cross seller and product widget’s frontend code, but Chris’s talk still had some great take aways for us.

In the end monads are a kind of data types with specifications of operations and rules that abstract other data types. These specifications got explained by implementing StackCollection and a Maybe monad to show how to encapsulate critical accesses without exceptions. Followed by a Many to show how to handle a list of data with the same functors and shared behaviours.

If the whole system understand Monads it’s possible to create more declarative code and remove lots of boilerplate in your code base. For example with help of the Maybe monad you can leave out the checks for the existence of optional data; just write your code as if the values inside your data types are complete.

By refactoring to magic getters, the higher order function then got encapsulated and the actual code got nice and tidy.

This topic is often hard to follow, but Chris did a great job and made his talk easy to follow and fun to listen to.

For a better explanation and more details you can take a look at the slides


STATE OF LARAVEL

by Taylor Otwell @taylorotwell – Founder & creator of Laravel

As the grand finale of conference day #1 Taylor Otwell – the founder & creator of Laravel himself – was so kind to show us the latest hot improvements and additions to be shipped with Laravel 5.5 which is the next LTS release and got shipped the day after.

If you read the section right above this section about Monads in PHP, you probably noticed our corresponding enthusiasm. So our personal favourite addition might be the Optional data type.

Instead of summing up all of the new features, we decided to just link to the corresponding Laravel News post.


CONFERENCE DAY #2

Our favourite talks of Wednesday.


DEBUGGING DESIGN – 5 SIMPLE DESIGN PRINCIPLES TO MAKE YOUR UI “NOT LOOK TERRIBLE”

by Laura Elizabeth @laurium lauraelizabeth.co – Designer & product creator

Laura introduced an easy checklist which makes it possible to create or polish a site without a design background. Following we try to recap her identified steps as precise as possible.

  1. Creating a colour palette
    • Pick any colour
    • Gather inspiration of other sites which use your chosen colour; sites like dribbble support you to find them
    • Create a colour palette and different shades of your favourite colour; with sites like paletton
  2. Choosing the right fonts
    • Choosing two typefaces is often easier than one
    • But the two should be different enough: for example serif and sans-serif
    • Sites like fontpair help you find matching siblings
  3. Making sense of hierarchy
    • Identify which parts of the site you want your users to see and how prominent you want them to be
    • Identify the problems to the current state and fix them by prioritising step by step
    • Optimise the spacing between logical different components to make them independent
  4. Coming up with decent layouts
    • Look at sites you like and identify blocks that you could adapt for you site
    • Identify a “Modular Scale” for you fonts. Sites like type-scale support you to find the best matches
    • Your textual blocks should have an optimised amount of characters per line of 45-75
    • Spacing or lack of spacing is often the problem on sites – take one base spacing and create more by dividing or multiplying that for other spacings
  5. How to make your designs look ‘polished’
    • Identify points you don’t like and make small changes to approach it
    • Add crisp icons with help of fonts like fontawesome

Laura held an inspiring talk with tons of insights which was great fun to listen to. If you want to dig deeper visit her cool site DesignAcademy<