DEV Community: Jump24

Laravel Blade Components

Daniel Newns — Sun, 28 May 2023 09:46:28 +0000

Laravel Blade is a powerful templating engine that allows developers to create dynamic and reusable views in a Laravel application. One of the key features of Blade is the ability to create reusable and composable components, which can help speed up front-end development. By enabling the creation of reusable components that provide consistent styles and behaviour, developers can avoid the need to construct elements from scratch. Instead, they can simply make use of the components that already exist.

In this article we will create a basic form that shows you some benefits and techniques of blade components.

Creating your first component

There are two types of components: class-based and anonymous. Class-based components have a class and a view template, while anonymous components only have a view template. In most cases, anonymous components are sufficient, and I tend to use class-based components only when I need to use dependency injection.

php artisan make:component layouts.app --view

Running the above command will create our first component, a layout file named resources/views/components/layouts/app.blade.php. This file will be the layout of the app.

<!-- /resources/views/components/layouts/app.blade.php -->

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">

    <title>Laravel Blade Components</title>

    <script src="https://cdn.tailwindcss.com"></script>
</head>
<body>
    {{ $slot }}
</body>
</html>

<!-- /resources/views/example.blade.php -->

<x-layouts.app>
    Hello World!
</x-layouts.app>

{{ $slot }} will render whatever we pass to it. For example, passing Hello World! will render it on the page. Slots are what make blade components composable. We can pass components to other components and even use named slots!

Create a form

Run the following to create our anonymous index component

php artisan make:component form.index --view

Normally to group components together you would have to have a form component then have the rest of the forms components inside a folder.

/resources/views/components/form.blade.php
/resources/views/components/form/group.blade.php

Anonymous index components allow you to group your components together.

/resources/views/components/form/index.blade.php
/resources/views/components/form/group.blade.php

Usage would look like

<x-layouts.app>
    <x-form>
        <x-form.group>
            Hello!
        </xform.group>
    </x-form>
</x-layouts.app>

<!-- /resources/views/components/form/index.blade.php -->

@props([
    'method' => 'POST',
    'action',
    'hasFiles' => false,
])

<form
    method="{{ $method !== 'GET' ? 'POST' : 'GET' }}"
    action="{{ $action }}"
    {!! $hasFiles ? 'enctype="multipart/form-data"' : '' !!}
    {{ $attributes->except(['method', 'action']) }}
>
    @csrf
    @method($method)

    {{ $slot }}
</form>

We define the props we want the component to accept. We are able to set some sensible defaults. Most forms have the method as POST so we set that as default. When forms are sending files we need to have the enctype attribute. Instead of typing it out every time we make the component add this attribute on when we need it.

We want to make sure the developer passes an action when using this component so we set action as a prop but set no default value. When no action is passed Laravel will throw an error if we do not do an isset() check.

Echoing out $attributes allows us to pass any additional attributes we need without having to define them in the props.

<x-form action="/users"></x-form>
<x-form :action="route('users.store')"></x-form>

<x-form method="GET"></x-form>

<x-form has-files></x-form>

<x-form class="border border-red-200"></x-form>

<x-form 
    :action="route('photos.store')"
    has-files
    class="p-5"
>
    //
</x-form>

In the above example we use the :action attribute. We use the : prefix to denote that it is a PHP expression or variable. We could also do :action="$someRoute". If it is a hardcoded or primitive value we do action="/" like normal.

Create text input

When working with inputs I like to create a group component that can take the input component. This group will display the label, help text and any errors.

php artisan make:component input.group --view

Here we are setting a default class using $attributes->class(['block']). If we were to pass the class attribute any classes would be merged with block.

We use @class() to conditionally set classes. text-gray-700 inline-block mb-1 is always displayed, text-red-500 is only merged into the default when $error is present.

If we don’t pass a prop in then it is not defined, that is why we use @isset($help) and @isset($error) to check if they are set. We could also set the props to have null as their default value and check for that.

<!-- /resources/views/components/input/group.blade.php -->

@props([
    'label',
    'for',
    'help',
    'error',
])

<label
    {{ $attributes }}
    {{ $attributes->class(['block']) }}
    for="{{ $for }}"
>
    <span
        @class([
            'text-gray-700 inline-block mb-1',
            'text-red-500' => isset($error)
        ])
    >{{ $label ?? '' }}</span>
    <div class="mt-1">
        {{ $slot }}
    </div>
    @isset($help)
        <p class="mt-2 text-sm text-gray-500" id="{{ $for }}">{{ $help }}</p>
    @endif
    @isset($error)
        <div class="mt-1 text-red-500 text-sm">{{ $error }}</div>
    @endif
</label>

Next we will create a text input

php artisan make:component input.text --view

This component uses @aware(). This allows the child component to access data in the parent component.

<!-- /resources/views/components/input/text.blade.php -->

@aware([
    'error',
])

@props([
    'value',
    'name',
    'for',
])

<input
    {{ $attributes->class([
        'shadow-sm focus:ring-indigo-500 focus:border-indigo-500 block w-full sm:text-sm border-gray-300 rounded-md',
        'border-red-500' => $error
    ]) }}
    @isset($name) name="{{ $name }}" @endif
    type="text"
    @isset($value) value="{{ $value }}" @endif
    {{ $attributes }}
/>

Create button

Finally we can create a button to submit our form. We will use an anonymous index component again. This is because I don’t want to access the button directly, instead I want to use this component inside primary, secondary buttons.

php artisan make:component button.index --view

<!-- /resources/views/components/button/index.blade.php -->

@aware([
    'type',
])

<button
    type="{{ $type }}"
    {{ $attributes->class([
        'inline-flex items-center border font-medium rounded-md focus:outline-none focus:ring-2 focus:ring-offset-2',
    ]) }}
>
    {{ $slot }}
</button>

Next we create our primary button. You can see that we are using the x-button inside our primary component.

php artisan make:component button.primary --view

<!-- /resources/views/components/button/primary.blade.php -->

@props([
    'type' => 'button',
])

<x-button
    {{ $attributes->merge(['class' => 'border-transparent shadow-sm text-white bg-indigo-600 hover:bg-indigo-700']) }}>
    {{ $slot }}
</x-button>

Separating the x-button component means that we can re-use it in multiple places, even using it on its own.

Putting it all together

Now we have created our components we can start to use them together. We first use our form component to wrap all our inputs, in this instance we only need to pass the route as the action. Next we have a couple of input groups, these take a label, for and an error. The error comes from the validation error bag that is available to all views. Passed to the input groups slot is the input. In this example we are using automatic attributes to pass along the old value to the value attribute. Lastly we use our button to submit the form.

<x-form :action="route('users.store')">
    <x-input.group label="Email" for="email" :error="$errors->first('email')">
        <x-input.email name="email" :value="old('email')" />
    </x-input.group>
    <x-input.group label="Password" for="password" :error="$errors->first('password')">
        <x-input.password name="password" :value="old('password')" />
    </x-input.group>
    <x-button.primary>
      Submit
    </x-button.primary>
</x-form>

We can mix blade components with plain HTML as well.

<x-form action="/photo" has-files>
    <div class="p-3 border border-slate-200">
      <x-input.group label="Password" for="photo" :error="$errors->first('photo')">
          <input type="file" name="photo" />
      </x-input.group>
      <button>Submit</button>
    </div>
</x-form>

Bonus Tips

Short Attribute Syntax

{{-- Short attribute syntax... --}}
<x-input.text $name />

{{-- Is equivalent to... --}}
<x-input.text name="{{ $name }}" />

Named Slots - You can have multiple slots in a component by giving them names.

<x-modal>
    <x-slot:header>
      Hello World!
    </x-slot>

    Some lovely content

    <x-slot:footer>
      Goodbye World!
    </x-slot>
</x-modal>

You’d achieve this by doing the following

<!-- /resources/views/components/modal/index.blade.php -->

<div>
  <header>
    {{ $header }}
  </header>
  <main>
    {{ $slot }}
  </main>
  <footer>
    {{ $footer }}
  </footer>
</div>

Brum Tech Tapas: A Retrospective

James Seconde — Thu, 27 May 2021 07:54:29 +0000

Launching a new event for the city, towards what will be hopefully the end of the COVID crisis was always going to be a daunting task. Wary of the dreaded ‘Zoom fatigue’, numbers for online events have slowly been dropping over the past year or so. But, with a huge push from the team at Jump24, we did it - and our building excitement before launching was satisfied with something we really enjoyed and are proud of.

We previously wrote a blog post on launching online events, and what we’d learned in the process. Building on that, it makes sense to write up what we learned during the launch of Brum Tech Tapas (and we learned a lot!). There is, however, a lot to take in. So, in the spirit of “tapas” being “bitesize chunks”, we thought we split our thoughts into three natural categories. First up, it’s:

BRUM

This is a local event, created for the community here, with a line up of speakers doing work in the region.

Selecting Speakers

The speakers really provide the core content of the whole event, and drive the direction of the event – so our speaker selection was very carefully planned. As a team, we created a shortlist (which became a very long list in a matter of hours!) of who we wanted to invite. Our lists contained people expert in the areas outlined in the introduction – so for a quick reminder:

We approached people in a number of ways – Twitter Direct Messages, LinkedIn Direct Messages, email addresses we found on websites. Communication is hard when so many channels are available, but really Twitter was probably the most effective. There is reasoning behind this – one of the targets for Brum Tech Tapas content from speakers was to get the “inside story” or honest account of what they work on rather than the sales pitch. For some speakers, this doesn’t apply, but for those operating in corporate spaces it certainly rings true.

Diversity / Inclusion

In our world of tech, the demographics of those speaking at meetups and conferences are still massively skewed towards middle-aged white men – commonly known as ‘manels’. Well, you won’t see one of those at Brum Tech Tapas. This is an event for the West Midlands, so it is essential to the mission that speaker selection represents the region correctly.

Code of Conduct

We believe that a Code of Conduct (CoC) is absolutely vital. We adapted the one used by PyCon US (https://us.pycon.org/2020/about/code-of-conduct/) for Brum Tech Tapas that you can find here (https://brumtechtapas.co.uk/code-of-conduct/). Launching the event online means applying the CoC somewhat differently, so Chris, Dan and Ollie moderated the YouTube chat room. Thankfully CoC violations are rare (especially for a new event) but given our ambition to grow, we made sure we were doing things the right way. It didn’t go unnoticed, given that several of our attendees gave positive feedback that we had a CoC.

Promotion

The principal driver behind how we conceived and executed Brum Tech Tapas comes from the world of Developer Relations. You can read a decent outline on what this looks like from Matthew Revell’s Hoopy consultancy here. Like with any good event, it’s about putting the community first.

Interesting things happened as a result, some of which we couldn’t have predicted but were delighted to see.

Asset Reuse

We contacted several tech organisations in the city to see if they were interested in promoting the event. It may sound like I’m easy to please, but given how hard it is to collaborate and promote ourselves within the region, it was a genuine delight to see our assets being reused without any ask in return.

The top image comes courtesy of Birmingham Tech, who promoted our event through their platform and created this promo image themselves – and it looks great! The second image appeared to our surprise from Innovation Alliance – while we didn’t have any direct contact with them, I suspect this was the work of Naomi Nash at Tech Nation who helped us promote through their network. Both Naomi and Yiannis had generated interest through their spheres of influence, which put my mind at ease that people were indeed interested in what we were putting together.

A Wider Audience

Now, this was harder. We could do promotion through our tech network but our speaker pool lay outside of our comfort zone. Our starting point was to get word-of-mouth out there from people who we have approached about speaking or promoting. You can’t suddenly declare yourself as a connected expert in the art world of Birmingham, for instance, so instead we had a lot of conversations with people who ARE expert in those spaces. We pitched Brum Tech Tapas as a concept to them, and if they liked what they see – they could speak or recommend speakers to us. Because, after all, the event is for the community.

Rather than plan, plan and plan with massive ambitions for Brum Tech Tapas, we just wanted to launch the event and get the momentum going for more events. As such, we didn’t set massive targets, because really just launching the event and getting attendees could be seen as a success. We also made it free, to encourage participation and send a message that this is a not-for-profit event. So, we set relatively low targets – 50 tickets ‘sold’ through EventBrite, with perhaps a 45-50% turnout from that. We were absolutely delighted when around 60 people watched the live event during most of its 2 ½ hour duration . We most definitely counted that as a win.

On the subject of tickets – when sales started coming in, we saw many familiar faces of colleagues, friends and peers within tech. However, shortly after launch we were selling tickets to people totally unfamiliar to us, mostly in waves after using social media to promote other organisations and interesting people, which brings us neatly onto:

Promoting the Region

One of the approaches we wanted to take was to give shout outs to all the amazing people and organisations that we want to connect with, potentially as speakers or who would know people in their own industries that could speak (or attend!). In doing so, we discovered so much more about these areas of the city’s creative ecosystem. Here are a couple of examples:

The conclusion here is that we achieved what we set out to do, and that promoting the people and organisations that we see doing great stuff establishes the connections we want to make for future events. Put your trust in the community before your own requirements, and people will take you seriously.

Next up, we’ll cover the “tech” part of Tech Tapas. After all, we’re a tech company streaming an event online-only for now, so there was bound to be some interesting snags along the way, right?

Remote Code Pairing with PHPStorm

James Seconde — Fri, 07 May 2021 09:25:27 +0000

Among the many challenges developers face when working 100% remote are those times when you face a problem that results in you staring at your IDE blankly for minutes on end.

The ability to swivel your chair around and quickly throw out “have you got 2 minutes to rubber duck this bit of code please?” has become a distant memory.

Pair programming is a practice that I have encountered far less than I feel is acceptable within agency software development. As always, everything evolves around time; from what I have experienced across this sector, if it’s not coding that feature and getting it out the door as quickly as possible, it’s not worth the company’s time.

Of course, at Jump24 we don’t operate like that, because investing time in our tooling is part of what we do. We can’t all be 10x Engineers and so, with the company completely remote, how do we solve the rubber duck problem?

Remote pair programming tools have been around for some time – Saros, which is available for IntelliJ and Eclipse, has been in development since 2006 for example. One of the other IDEs we use at Jump24 is VSCode (or VSCodium, which is VSCode with Microsoft’s telemetrics reporting taken out) has several extensions available that also do remote sessions – CodeTogether is a solid choice in my experience.

Like many organisations, 2020’s COVID crisis has propelled some of these tools to the forefront of developers’ consciousness – and it seems Jetbrains responded by accelerating development on it’s remote pairing plugin. While it’s already been mentioned that VSCode has remote pairing extensions available, the same features were astonishingly requested in Jetbrains’ Issue Tracker as long ago as 2004. Spearheaded presumably by COVID demands from remote workers, finally on 2020-09-18 Code With Me was released.

So, when trying to debug a particularly tricky set of feature tests with Ben Paddock, it seemed like the perfect time for us to experiment with it.

Setup Before

What would the next steps have previously been before Code With Me, then? Well, choose your video conferencing suite of choice, share screen and one of you drives the session. It’s not the most intuitive of solutions, but it does at least mean your partner can see and dictate potential changes with you over video.

Problems

The biggest blocker for this type of pairing is that the ‘client’ human has no control over the IDE. Indeed, this is true of real life: when trying to think of potential solutions in code, one of you can only dictate to the other who is driving. I’m sure many readers would agree that, sometimes, dictating code and code changes is hard.

Features

Code With Me has a couple of advantages over similar plugins such as CodeTogether. Here’s the two key features at Jump24 we found that were essential:

Because it uses a remote Java client developed by Jetbrains, it sandboxes the whole IDE on the host to the client. This means that the client doesn’t need to have the codebase. In our development where individual developers work on large, split codebases with entire Docker stacks, this gives a massive boost by not necessarily needing the entire project downloaded, dependencies from Javascript and PHP run and docker-compose spun up.
Because this client replaces the functionality of what ssh would be doing if you were to remote pair in something like, for example, vim and tmux, it means you both have 100% keypress access to the same remote terminal. If you were both debugging on a remote server, sure this doesn’t seem special. But, couple this with our large Docker stacks and both of you can run a command line ssh’d within the Docker stack on the host machine.

Aha! But Security!

So, in terms of security and given that you can share an entire codebase with another “dumb IDE”, what’s going with those comms under the hood?

The answer is: they’re going through Jetbrains’ servers. The infosec managers cry “ISO27001!” and if you’re in a large MegaCorp your pairing dreams are over. But, one of the really lovely features rolled out with this plugin is you can run your own Code With Me server. Take that, MegaCorp!

Similar approaches: VSCode

It’s worth noting that, because I have some streak of masochism about me, I actually use two IDEs: PhpStorm for backend development in PHP and React/Vue and VSCodium for node.js and vanilla JS.

CodeTogether has been available for VSCode for quite some time now, and while you might be tempted to scoff that users of that IDE have been ahead of the game, the two key features noted (remote shared terminal, run your own server) make Code With Me just take the edge. I expect these features to likely be on the way, mind.

Conclusion: more joyful pairing

Zoom calls and Skype screen sharing in the time of COVID have become tiresome, but switching to this toolset makes remote pairing a world of difference for the better. There’s just too many upsides to ignore here – as well as key features mentioned, it’s just the little things when trying to untangle your spaghetti. When you’ve both got the IDE running rather than one transmitted across via screen share, your linter works, both of you can use code completion and can navigate through classes – the list goes on.

And, more to the point: surely anything is better than trying to dictate to the user what code to write.

Running and speaking at Online Events: what we’ve learned

James Seconde — Mon, 07 Dec 2020 14:09:23 +0000

My start at Jump24 was never going to be straightforward – the United Kingdom was in full COVID-19 lockdown, bringing down tech meetups and conferences worldwide at the point when I was fully launching into a Developer Relations role, which would immediately have to be redefined to make our developer outreach work. But: we currently have a talk and live code demo session currently on tour – so how did we do it, and what experience have we gained? But first: some observations about the impact of COVID-19 on our communities.

Slow to adapt: how tech got caught napping

It’s hardly a surprising outcome with what happened after the Prime Minister announced full lockdown on 24th March. 34 tech events happened in the first two months in the West Midlands region in the UK, including regulars from DevOps, AWS, Ruby, Javascript, Xamarin/.NET, Docker and ProductTank. After lockdown in April and May, just 6 of the regular meetups happened after switching online, almost all of them Zoom calls.

This was only for our region of course: the unexpected overhead of suddenly needing to organise and promote on entirely digital platforms meant that grassroots meetups dropped off all over the world and conferences got cancelled with no time to arrange alternative online setups.

Speaking: Turbocharged development with Xdebug, Docker & PhpStorm

So, the first question we had to ask was that if some usergroups were being continued online, should we go ahead with the idea of delivering a talk we’d prototyped internally? First, we’d have to solve the elephant in the room: this was due to be a live code demo. So, to deliver this talk we’d need:

A speaker, me
Google Slides, using Chrome
A bash terminal
PhpStorm
Firefox

How do you juggle all this in virtual form, and how do you make it presentable? Step forward Jump24’s Ollie Matthews: Operations Manager and avid gaming streamer.

Lessons from the gaming world

Multiple input sources to create a slick streaming platform, you say? Well, it came as no surprise that professional gamers have had this mastered for quite some time. Ollie outlined the equipment needed, so here’s how we built the home studio for streaming:

The office streaming setup

Macbook Pro 2016 (Touchbar)

https://everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-i9-2.3-eight-core-15-mid-2019-touch-bar-specs.html

In the field of web application development, particularly in the realms of PHP, Javascript/Node and Ruby, the dominant Operating System on a user level tends to be skewed towards macOS. We use Macs for developing in Laravel, so it’s worth noting that our experience in putting together a streaming setup is already going to differ from the gaming world, where Windows is by far the dominant platform.

Elgato Stream Deck

https://www.elgato.com/en/gaming/stream-deck

Elgato’s Steam deck is really the keystone feature of the setup – the ability to create a custom setup that can control lighting, desktop applications (so this tackled the quick switch between terminal, IDE, Firefox and Google Slides on Chromium), Twitch, and OBS (in particular scenes & transitions) is a gamechanger. This bit of kit is no stranger to the gaming world: streamers use it regularly for Twitch (and other socials integration such as Twitter), recording and scene control. Elgato has recently opened up the button marketplace, adding new control sets such as integration for VSCode.

Elgato Key Light

https://www.elgato.com/en/gaming/key-light

Despite many people’s beliefs, lighting is one of, if not the most important part of any streaming setup. So, the next thing we went for in the Elgato family is the Key light. Yes, this may seem a little expensive compared to other LED panels or ring lights but this particular light seamlessly integrates into the rest of our setup – including the Stream Deck.

With its sleek design it can fit into any space or desk setup, and hooking it up to your PC via wifi allows you to tweak the brightness and temperature to best suit your needs.

Despite the premium nature of this product, the setup wasn’t all plain sailing. The Key Light requires a 2.4ghz banded Wifi and doesn’t work with 5ghz. I have a dual band router, so when I switched on 2.4ghz it firstly had a weak signal despite not being far away (common with poor routers dished out by providers). Secondly, my new TV fights with the Key Light over who gets to be connected to the network.

For more advanced colour options, you might want to consider the Elgato Ring Light, but still has the same potential burden regarding control.

Rode NT-USB with boom or Elgato Wave:3

https://www.rode.com/microphones/nt-usb

https://www.elgato.com/en/wave-3

Originally I’d purchased the Blue Yeti on the back of many recommendations, but it shipped broken. Rode’s USB mic might not have the multi pattern recording modes that the Yeti does, but it does come with a decent pop filter and reasonable price tag. In the office setup we use the Elgato Wave:3 with a boom and filter.

Logitech Streamcam

https://www.logitech.com/en-gb/products/webcams/streamcam.960-001281.html

Choices for HD streaming are vast, and so sifting through the pages of 1080p cameras can be daunting. The important bit here is to answer the glaring question: “do I need a 1080 webcam?”. Well, what we wanted at Jump24 was as professional a setup as we could get, which included a 1080 cam. However, it’s worth pointing out that if your scenes are mostly a small corner box with a slide deck taking centre stage (or on a live demo like ours – a terminal, browser etc.) then realistically any cam will likely be sufficient.

Elgato Green Screen

https://www.elgato.com/en/gaming/green-screen

This is something new we have added to our setup but yet to implement. Using a green screen will allow us to expand our Overlay options when doing events, from branded backdrops, animations to simply removing a messy background.

A green screen can be something that eliminates issues; add a chrome key filter in your broadcasting app of choice and, just like magic: the background has disappeared.

OBS Studio

https://obsproject.com/

Open Broadcaster Studio has been at the forefront of game streaming for at least five years. It’s ability to take almost any media input and generate an output for streaming, and for free as Open Source Software makes it an industry standard of sorts. There are disadvantages, however – the majority of its users tend to be on Windows platforms, so if you’re using the MacOS or Linux ports it can be a little more buggy. In order to hook up OBS to various hosting platforms where no integration with OBS is possible, it needs the ‘Virtual Camera’ feature, that will take the OBS output and pipe it into a virtual device. The likelihood is that if you are in control of your stream, you can hook up OBS to YouTube or Twitch with API keys directly and thus won’t need to use the Virtual Camera, but when you are being hosted and control is out of your hands it will be needed.

Being Hosted: your meetup’s tech stack

Zoom / Skype

Zoom capitalised on their new found advantage by offering unlimited free tier calls. It’s probably not that much of a surprise then that Zoom seems to have become the default. I’ve done the talk a couple of times now on Zoom with OBS’s Virtual Camera output and not found any issues with it.

Jitsi

Jitsi would absolutely not play ball with the OBS Virtual camera output – problems included output resolution and “flipping” the output image. What made Jitsi unusable for us, however, is that there is a tendency for meetups using it to have the free tier (for understandable reasons). Unlike the resource Zoom has to throw at free tier usage, it was clear that the servers were heavily throttling the connection. That’s not a problem if you’re doing a brief meeting, but presenting and pulling down docker containers? Nope.

Streamyard

Streamyard is a popular option, and from a speakers’ perspective has decent features: a backstage broadcasting area and a screenshare perspective that takes care of the scene layout for you. There is, however, a disadvantage to this (as we discovered) in that you can’t use OBS’s virtual camera output. The image resolution is cropped awkwardly, but more importantly with OBS you’re trying to replicate a feature that Streamyard is designed for. This is where there’s a big difference in Streamyard between speaking and hosting: as a speaker, you don’t have control whereas when hosting you can include backdrops with branding.

Hosting: Tech stack options with Kevin Lewis

So, we’ve covered being the speaker in virtual meetups, but what about hosting your own? Before COVID hit, we were planning to launch a new tech, art & culture event in the city, BrumTech Tapas.

With the switch to virtual, we needed to think about our options from an organisers’ view. Rather than go into this foray blindly, I spoke to Vonage’s Kevin Lewis, whom I knew had a mountain of experience in this area due to his events work with the You Got This Conference Series, Women of React and Vonage’s Developer Day.

Online events provide some really exciting opportunities to build experiences that just wouldn’t be possible in a physical space, for the affordances that tech brings. When organizing events, you can try and emulate offline events complete with networking setups, work towards an Apple WWDC-style highly-produced live TV show, or create more novel experiences such as Roguelike Celebration.

When choosing your setup, there are five core considerations:

Complexity of Operation – how confident is your team to use more complex tooling?
Creative Flexibility – how customized do you need the output to be?
Moderation Bandwidth – how much people-power do you have for moderation, and how does the choice of platforms impact this?
Attendee Experience – what is an ideal experience for attendees? Do you want to facilitate networking? Should it all be in one platform?
Speaker Experience – how involved or complex can your speaker experience be while still being appropriate for who you have invited?

Some of these items are inextricably linked – having more creative flexibility is likely to increase complexity, for example.

My first full-scale online conference was Women of React back in April. We used Skype (with NDI) and OBS for managing the stream, YouTube for hosting the stream and Discord for community interactions. We got a really lovely set of custom scenes and full control over what was seen or heard, but it was a pain to keep on top of. The speakers and MC had to really work through all of the technical quirks (which they did fantastically), but it was difficult.

Using a video call, piping data into OBS via the NDI protocol and pushing out a completed stream to your host means your one device will be doing lots of computationally-expensive operations, and if it fails to deliver the whole event will suffer. There are contingencies to this – such as renting a more powerful cloud-hosted machine and completing the work on it, but this comes at an additional cost and setup time.

My team at Vonage chose to use a platform called Remo for Vonage Developer Day – which has a networking component aiming to emulate offline events. Attendees can gather and move around tables – each a small video call between groups.

Through all the events I’ve run, I still believe Streamyard provides the best overall setup for publishing livestreams. While you are creatively limited to just the 7 pre-set layouts provided, they are designed with care and almost every use case in mind.

Also consider the need for networking in the long, long year that is 2020. I am a fan of giving people spaces to meet, but nothing will replace being in the same room. Many folks have screen fatigue, and many will be motivated only by consuming the organized content. Consider if this is true in your community and whether you can place somewhat-forced networking efforts aside for a happier time.

If you want to find out more about the considerations and outcomes around Women of React, Vonage Developer Day and You Got This From Your Couch – you can watch my talk from DevRelCon Earth earlier this year.

Event Branding – design considerations

The new branding for Brum Tech Tapas along with the website had just been completed before we went into the first lockdown. The idea was to keep it simple and not focus solely on the tech community. A lot of this was achieved by building the website and the photography we used to represent the diverse cultural scene in Birmingham.

The next design aspect we had to tackle was moving the talks over to Twitch. Something as designers we had no experience in. We started taking a look at other Twitch coder accounts and noticed that the aesthetics weren’t always a priority, something we wanted to avoid. As this was something relatively new for tech talks in Birmingham we wanted to make sure we put our best foot forward, using our branding to create something aesthetically pleasing whilst allowing for multiple speakers to be shown and live coding to be clear and visible.

Virtual means more accessible options

The equipment we put together and time invested in designs etc. comes at a cost. The decisions that we made are based on the notion that you don’t have to invest much to get a polished, professional setup that looks no different from international tech firms’ branding and content delivery.

While that’s certainly the conclusion for what we were looking for, it’s important to bear in mind that to speak at a meetup or to host one, you technically don’t need any of this. This is vital to know if you’re starting out speaking and need some exposure, or you’re booting up a new usergroup (or transitioning online for the first time). All you actually need is an internet connection, a webcam and people to join. As with most things, the end goals of what you want to achieve dictate the requirements.

Virtual meetups and conferences: advantages and disadvantages

So, given that we’ve gone through planning, let’s have a bit of a postmortem on the key things to think about when it comes to running virtual tech events. As we approach tech events from a Developer Relations perspective – raising awareness of our work and doing developer outreach for education, it’s now very apparent what can run smoothly and what snagging points you can encounter.

Advantages

Speaker Pools

The rules have now been redefined – you can officially contact someone elsewhere on the planet and ask if they want to speak at your meetup. It’s worth noting that, while there is an element of truth to that sentence, many of the meetups I have spoken at have very much stuck to a pool of speakers already within their network. While it might have potentially opened more doors to speakers, it’s also worth considering that it doesn’t give you an immediate ‘yes’ from everyone.

Cost

The cost of what you’re looking at has pretty much been outlined in the article. In-person meetups require spaces, the oh-so-stereotypical “Pizza for 30 developers” and drinks sponsorships. If you’ve got a fancier meetup, you might have catering. The cost of running a meetup can be £0 if you want it to be; even the price of a conference is suddenly astonishingly low considering the speakers you might have been able to virtually pull in.

Potential Reach

The point of a local usergroup is that you form smaller communities around common themes – the convenience of opening it up without a physical form means that your attendance might well spike. In the usergroups we’ve spoken at on our current talk, it’s noticeable how the attendance is actually higher. In the PHP world this does however have a drawback – one of the reasons you’ll see more one some of the events is because PHP developers are aware of other local usergroups. There is a scenario playing out right now that we’ve seen. A point Raised by one of the usergroups we spoke at stated that the same talks are going round the circuit and thus someone from Bristol might not want to watch a talk on at PHPSW: because they already saw it at PHPMiNDS in Nottingham.

Disadvantages

Loss of 1-2-1 interaction

Developer Relations still thrives on in-person 1-2-1 interactions – from my experience personally this is still the best way to network and create a hub of people with similar interests to get feedback and opinions off. Without that, the hardest part of expanding your network has pretty much gone. Yes, in speaking to event organisers, recreating this part of outreach has been attempted, but as of yet not many that I’ve spoken to have reported a successful method for doing it.

Internet speeds

This one stands out by a country mile. If COVID has shown us anything, it’s how reliant in the tech world we are for the Internet for software development beyond the obvious limitations of CI pipelines and Docker pulls.

Your speaker’s connection goes down 5 hours before the event because someone drilled through a pipe. Your speaker’s connection goes down during the event while speaking because geese have attacked the exchange. What do you do?

That’s only from the speakers’ perspective. During the tour of our current talk, my internet speed was fairly poor, and an unexpected need to pull an nginx container resulted in my best Minecraft look. But what if you encounter this when you’re on StreamYard and hosting the whole event? Well, then you’ve not really got any options. But you can prepare by making sure you host from a high speed connection, especially if you have speakers from across the globe, and especially if they’re not in the standard Western world tech bubble.

The curse of remote working

This is one of the biggest issues with moving virtual. You’ve just spent eight hours of your day on Zoom calls, JIRA and your IDE open in front of you, barely moving apart from the get the occasional coffee which is also now done in silence.

Come 6:30pm, is opening up a Zoom call with 30 people in to have a virtual tech talk (that, in some cases, is being recorded and will be available at any point in the future you choose anyway) really how you want to spend your evening?

Losing outreach: Slack/Discord

This is Developer Relations. Marketing people might well not see the problem with throwing out “for discussions, sign up to our Slack/Discord!”, but we know the pain of being told for the 10th time in a month to sign into a new social media platform for one event that will be used once.

This particular subject has been covered recently by Joe Nash, offering to open up discussions as to why Let’s Just Create a New Slack really isn’t the one-size-fits-all solution.

Source: https://twitter.com/jna_sh/status/1326514552251568130

For more fitting options, specifically around the biggest sticking point of live feedback/community comms – moderation – check out Joe’s tweets and subsequent discussions on why certain platforms have advantages over Slack. What’s interesting is that Discord comes up time and time again in conversations – another crossover from the gaming world.

Conclusion: A more versatile outreach

So, what are the results of what we did? Well, like most people I expect, we’re ready for physical events again for sure. But for now, I’ll put it this way: we’re now equipped and experienced in hosting and delivering virtual content. This is something we certainly couldn’t do before, and besides: without the COVID crisis many large tech companies did have the ability to create content in this way. So, by preparing for virtual content and calling in advice across disciplines both internally and externally – Jump24 has a far more versatile outreach capability. Which, after all, is the point of Developer Relations, isn’t it?

With thanks to Ollie Matthews, Anneka Mistry, Kevin Lewis and Joe Nash.

Turbocharged PHP Development with Xdebug, Docker & PHPStorm.

James Seconde — Thu, 13 Aug 2020 07:48:59 +0000

It all started out with that oh-so-modern cause of a community backlash: the humble tweet.

Source: https://twitter.com/derickr/status/1274134192155131905

Quite the controversial “hot-take” from Derick, and while it certainly caused quite the stir (that it was probably designed to), it made me think. I thought, ‘Do I need to revisit Xdebug?’, and I realised that I’d fallen into Derick’s trap. But think I did.

Let’s clear up some existing thoughts I had on Xdebug – some readers might nod in agreement or have/had similar experiences:

Like many PHP developers with significant experience: I know of Xdebug. It’s been around years – I started writing PHP professionally in 2016, by which time Xdebug had existed for 14 years. It’s not like it was some obscure or new tool being talked about.
I’d tried Xdebug before at some point – I can’t recall when, and had an experience that left me thinking that understanding what you could do with it would take far too much time up for me to learn. Plus, things like custom “bookmark” browser extensions made it feel like you had to jump through a lot of hoops to use it effectively. A lot has changed since I started – I use Jetbrains PHPStorm as my IDE, and develop with Docker. It was a pain trying to set it up manually before, but what about now, where Xdebug runs a server on an IP, but it will be running in Docker?
I’ve previously written an article on how superb PsySh is as an application’s command line. Given that when used as part of Laravel’s tinker it boots up the whole app into a REPL environment, does that render something like Xdebug somewhat redundant?
Lastly, but most importantly for developers: why bother when you can use var_dump() or Symfony’s dump() or Laravel’s dd()?

These thoughts of mine were also circulated in others’ replies to the tweet, but it was when Tighten’s Matt Stauffer and Twilio’s Gary Hockin stepped in to offer livestreams with Derick to set it up that I took notice – the resulting content is now excellently documented at https://learnxdebug.com with others’ contributions.

So, I thought: why not give it a go again? And so I did, going step by step though Gary and Derick’s video, with the goal to implement it into our development process for our Open Source project Awe-der.

How hard can it be?

One of the things that most articles I’d read or tried to follow miss out one core thing that frustrated me: most have the “how”, but not the “why”. That is to say: what is this thing I’m doing and why does it work?

Bearing that in mind, here is how I implemented the stack, step by step with a little bit more info than just your average set of instructions.

The Stack

MacOS 10.15 (Catalina)
PHPStorm 2020.1
PHP 7.4.4 (from official PHP Dockerfile)
Docker 19.03.8 (engine) 1.25.5 (compose)

Step One: Installing Xdebug

Part of what made the installation significantly easier for me was that the project it was being installed on was already using a Dockerfile as part of the stack. So, to install Xdebug, you need to include it with pecl (you can still -only- use pecl for operating system-level dependencies at the time of writing). Our project had this in our Dockerfile to install redis and imagick:



RUN docker-php-source extract && \
   pecl install redis && \
   pecl install imagick && \
   docker-php-ext-enable imagick && \
   docker-php-ext-enable redis && \
   docker-php-source delete

It’s at this point you want to install it with pecl, so add pecl install Xdebug into the run commands for the container:



RUN docker-php-source extract && \
   pecl install redis && \
   pecl install xdebug && \
   pecl install imagick && \
   docker-php-ext-enable imagick && \
   docker-php-ext-enable redis && \
   docker-php-source delete

You can see the actual live Dockerfile (with the correct install command) at: https://github.com/awe-der/aweder-core/blob/release/table-ordering/docker/php/Dockerfile

Step Two: Configuring Xdebug

Before Docker, Xdebug was relatively straightforward to configure on a platform, in that it was a new set of the php.ini parameters – you’d either just edit the existing php.ini, or load in a custom ini or override. Now we’re running PHP and fpm in a container, so we need to inject the configuration in with docker-compose.

First, create the file to inject and save it in the project root – let’s call it xdebug-local.ini.

Here’s what to put in it:



zend_extension=xdebug
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9001
xdebug.remote_host=host.docker.internal

I said this wouldn’t just be a copy and paste article, so: what are these parameters?

Zend_extension has always been the PHP ini file parameter name for adding in extensions – it hooks the pecl extension (or extensions installed with other tools like PEAR) installed to the runtime, so things like zip, redis, curl and the like use the same parameter to enable them.

xdebug.remote_enable and xdebug.autostart are more interesting. Remember me mentioning “bookmarklets” in the browser earlier? You have to use an extension to keep a server connection alive with your Xdebug session – for example, for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/xdebug-helper-for-firefox/

Sound clunky? You bet. Is it required? Absolutely not. Enable remote triggering of the Xdebug server and set autostart to true when either a breakpoint is hit in the code or you’ve set the break to be at the entry point to your application’s code and: bingo. It triggers your debugging session. Do I wish I’d have known about this years ago? For sure.

Xdebug.remote_port has an interesting quirk in that if you don’t set the parameter, it defaults to port 9000. I guess it’s an interesting aspect that shows Xdebug’s history in that it was probably chosen as a default port before the CGI adopted replacement php-fpm used port 9000. So, it’s important to set the remote port to 9001 (or whichever free port you wish) to stop clashes.

Xdebug.remote_host is the point at which our Docker configuration starts making the process perhaps a little convoluted. In our case, we develop as a company with Macs, so it’s handy that Docker has a reserved handle (host.docker.internal) to route into the correct IP. Windows does the same at the time of writing, but Linux distributions might need a bit of research to get the correct address in here to connect into Docker.

Step Three: Inject Config to Docker

So, using docker-compose, we now inject the local ini file into the php container’s conf.d directory. The docker-compose file should look something like this:



php:
   container_name: my_container
   build: ./path/to/my/php/dockerfile
   environment:
       PHP_MEMORY_LIMIT: '128M'
       DB_HOST: 'mysql'
       DB_USER: 'root'
       DB_PASSWORD: 'root'
       DB_NAME: 'if_your_app_has_a_db'
       PHP_IDE_CONFIG: 'serverName=myapp.url'
   volumes:
       - ./:/var/www/vhost/:cached
       - ./xdebug-local.ini:/usr/local/etc/php/conf.d/xdebug-local.ini

There are two things here to point out. Firstly, the docker volumes – it’s this line that’s going to enable Xdebug:



./xdebug-local.ini:/usr/local/etc/php/conf.d/xdebug-local.ini

The second one was a big gotcha: PHPStorm will need to match the incoming Xdebug server request to the webserver that’s set up in the IDE.



PHP_IDE_CONFIG: 'serverName=myapp.url'

I hadn’t actually set up the webserver on PHPStorm because I personally find a lot of the CLI and server setups for it extremely complex and hard to understand. But, because this environment variable is used to match to PHPStorm’s webserver setup, it cannot match the file structure without it – but more on that in a bit.

It’s time to check that Xdebug is working: rebuild your Docker stack


 build build && docker-compose up -d

And to check, debug by throwing phpinfo(); into an entrypoint to your app. Navigate to Xdebug on the page and you should see the following:

Step Four: Set up PHPStorm

I briefly mentioned that you need to set up your web server on PHPStorm first – so do that first. You can find pretty comprehensive and complete docs from Jetbrains on this here: https://www.jetbrains.com/help/phpstorm/creating-local-server-configuration.html#example1

Now we get PHPStorm to listen to port 9001 which we set in the config. You can change that like so:

Path mapping is important – PHPStorm has no way from the incoming request of knowing how the application is structured. Here’s an example of the configuration for Awe-der:

The absolute path on the server is what you need to change – make sure you change it to the root path served by your Docker stack (in our case, where nginx is serving the root of the application). This is an important step because PHPStorm assumes that the root directory from the incoming request is the public folder (if using either Symfony or Laravel). Make sure you also choose Xdebug as the debugger and use the appropriate HTTP port. Now, set PHPStorm to listen.

It’s time for the moment of truth: you’re listening for connections, you’re mapped, you’ve setup the Xdebug server: showtime. Add a breakpoint in PHPStorm (preferablly at the entry point of your app, so you know it’ll get hit), fire a request in the browser and IF everything is OK you’ll get an incoming connection from Xdebug in the IDE. Happy days if you did, don’t despair if you don’t: there are a lot of gotchas here. If nothing happens, the other tutorials at https://learnxdebug.com/ will probably have the answer.

As promised: Turbocharged Development

So, here’s what you actually came here for, right? As with debugging in other interpreted languages, your start point will be a breakpoint (you can actually set PHPStorm to hit a breakpoint whenever a new file entry point is detected as well).

Here’s a breakpoint set in our Awe-der project. We’re listening for connections – so, all being well we hit the Controller when loading the page, and hey presto! PHPStorm’s debugging pane appears.

Now that we’re at a paused moment in the runtime, let’s check out what we can do.

Console / Evaluate expression

You get a console that can run executable PHP within the runtime you’re in. That is… absolutely magic. Here’s an example of using the console live within Xdebug that will save you a mountain of var_dump() calls:

Putting a variable straight into the console will print it, in exactly the same way that Javascript does it with console.log in a browser console.

We can change something on any variable at runtime in the console. Take for instance this line:

$orderItem->fill($apiPayload);

That’s Laravel’s Eloquent ORM. Why not see what happens at runtime when you do something else with it in the console?



$orderItem->toArray()
‌array (
  'order_id' => 1,
  'inventory_id' => 2,
  'variant_id' => 1,
)

$orderItem->fill(['order_id' => 234523523]);

$orderItem->toArray()
‌array (
  'order_id' => 3333,
  'inventory_id' => 2,
  'variant_id' => 1,
)

Done. We’ve just messed around with an entity on the fly.

The console has everything set & booted (assuming you’re using Composer’s autoload) to the point it’s activated – so crucially local scope variables are available. You can also navigate the stack as well via. the frames in the debugger. Laravel has pretty detailed stack traces when you use Blade, but they’re not interactive ones like we can get in the IDE:

This is next level debugging. You can navigate the frame pane to the left to view the executed stack. When you select a frame from it, the editor pane will navigate to the function call in the code and the variable pane will update to everything that has been set at that point. For big monolith stacks full of services and function calls all over the place, you’ve now got far more visibility. Pretty neat, huh?

Conditional Breakpoints

An underrated feature is the ability to set breakpoints conditionally. For an example, let’s say that we only want to trigger the breakpoint to debug if an incoming request to a controller has a “search” term set.

Done. Another joy of this in PHPStorm is that the Condition window behaves like any other console window, so you get application-wide autocompletion and local variable autocompletion.

So, if we hit the URL:

Loads as expected, but add the search term in to the URL:

https://awe-der.net/admin/dashboard?search=test

Watchers

Common debugging nightmares include mutable objects being hit -somewhere- in the stack. We have visibility of the stack, but that’s not much help when tracking a specific object. To set a watcher, add an expression in the watcher pane to the left. It will be evaluated with each step you trigger. A good example to see it in action would be the classic C loop:



public function testWatcher(): void
{
   $variableToWatch = 45;

   for ($i = 1; $i < 5; $i++) {
       $variableToWatch = $variableToWatch + rand(0, 200);
   }
}

Set a watcher on $variableToWatch, and check out the watcher doing it’s magic just like any Javascript browser watcher as you step over the code:

Step & Cursor controls:

The five controls are as follows:

Step over: run to the next line of code

Step into: run into the next line, moving the cursor if entering a method call

Force step into: same as Step into, but runs with calls into vendor/3rd party code for deeper debugging

Step out: complete the current method and stop at the next line after the method that called it

Run to cursor: For me, this is the most important one, and I’ll tell you why:

If you’re debugging something quite straightforward in that it’s your own code entirely, or something like the Slim framework with as little code as possible, stepping through the code is pretty logical. However, for those using a big framework – Laravel, Symfony, Cake, WordPress etc. there are calls, pipelines and event handlers all over the app. That magic has got to happen somehow, and if you try and step into it, you can see it in action.

Don’t want to see all the handlers resolve? Cool. Move the cursor to the next line you want, so you can see the result piped into the variable frame. Hit run to cursor, job done.
Probably the most important: modifying the output

Modifying the output is, in my opinion, what makes Xdebug so powerful. We’ve looked at the fact that you can change variables and interact with the code at runtime, but what hasn’t been mentioned is that if you instruct the debugger to complete, the output is the changed output. To see it in action, here are two use cases:

Blade templates

We have a variable named $dashboardMetrics that’s passed into our template for rendering. Here it is rendered:

And, with a breakpoint set in the debugger, here is the payload printed out at the point it’s about to be loaded into the template:

So, I’m going to change “Processing” to 999. Hitting the breakpoint again, I’ll use the console to set it:

On the left hand side of the debugger pane you have the a “Resume Program” button. It allows you to complete the incoming request, so hit that and:

Request completed, you’ve modified runtime to change it.

API calls

Exactly the same logic applies to changing the output of an API request. Here I’m using Postman to get an entity via. A UUID:

Using the same method as the browser request, we’ll put a breakpoint into the API method and modify the output. Here’s the method response:

(Protip for Laravel – don’t do this, always use Laravel Resources!)

So, at the breakpoint let’s change the entity making the available_time now instead of the dummy date using the Carbon library:

Resume runtime, and check out the result from Postman:

Magic.

I came into this with some thoughts and assumptions, so I’ll tie up my new experience with Xdebug in some key points that answer those questions.
Conclusions

Q: Why use Xdebug when you can var_dump()?

A: Because it allows you to manipulate the runtime. If you use something like var_dump() you need to fire the CLI constantly or hit refresh on a browser over and over to get to the same point. Instead, you now have the chance to dynamically change and modify the stack – which is a big timesaver.

Q: You mentioned PsySh, why not use that?

A: Xdebug and PsySh are very different beasts. Whilst PsySh is labelled somewhat of a debugger, I don’t really treat it as such. It’s vital as a booted command line for your app, similar to manage.py for Django, but it’s not a pure debugger like Xdebug is.

Q: This is still hard to set up still, isn’t it?

A: I’d say it’s probably less of a mystery now that I’ve looked at it, and not as hard as most developers think. Plus the toolset for everyday use is so powerful, it’ll save you or your team a big chunk of valuable time and cognitive load.

Q: Are there downsides to using Xdebug?

A: The biggest downside I found was execution time. With the configuration in this article, the Xdebug server is always on – for a full PHPUnit test suite to run (if it’s pretty comprehensive) it will take a -big- performance hit. Luckily, there are workarounds for this in Docker, such as running commands with a custom ini to switch the Xdebug server off. If you’re in Production this is a real no-no.

Overall, I’d say the tradeoff for time was well worth the effort. Something like this should be part of a developers’ tool chain – sure, it’s not always needed. If you’re doing an MVP in Laravel that’s mainly just CRUD operations, there’s probably not much justification for it.

However, I’ve found that for many modern practises – comprehensive unit tests with large coverage from TDD, interface-based development and well-separated call stacks from considered single-responsibility principle controllers really do mean Xdebug gives you a decent edge.

If you’re working on a legacy application in Zend Framework 2 or 10,000 line controllers in someone’s 2006 bespoke framework and you’re not using Xdebug, I’d come to the conclusion that you love the punishment, and like it that way, you massochist.

Q: What’s the outcome of trying it out?

A: Development with TDD and Xdebug felt incredibly empowering, so we’re going to look to make it part of the default development environment & process.

Q: How much does Xdebug cost?

A: It’s free. Although, it depends on what the definition of “free” is – as it’s Derick’s Open Source project, it costs vast amounts of personal development time. If you want to try it out from reading this article (or you want to try it out with a different platform – check https://learnxdebug.com for other tutorials) then considering supporting his work:
https://xdebug.org/support

Happy debugging!