On the Medium.com site today Laravel project lead and creator Taylor Otwell has posted about a feature coming in the 5.6 release of the Laravel framework: single server scheduling.

Today Laurence Ioannou, founder of the Laravel monitoring application Eyewitness.io, contributed a great new feature to Laravel 5.6 (February 2018 release): single server scheduling.

He illustrates the new feature by first defining a new "inspire" job, making it run hourly with the artisan command and not overlap with a previous execution. While this works with a simple server, it doesn't scale to multiple - that's where the "single server scheduling" comes in. The addition of this support provides a new onOneServer option that prevents the job from running elsewhere. It makes use of Redis or Memcache to store the information about which server it is running on so that will need to be enabled to use this feature.

The SitePoint PHP blog has recently posted a tutorial from author Lukas White showing how to create an online reservation system for cooking classes using Lumen and the Acuity Scheduling service.

I recently wrote an article about building an online system to book lessons with a driving instructor. [...] Cookery classes usually have a very well-defined limit on the number of students — you can only really teach as many people as you have cooking stations or cookers. That’s going to be the theme of this article — managing those “slots” in a cookery class. The principles remain the same for all sorts of other forms of tuition.

As before, we’re going to take advantage of Acuity Scheduling in order to manage bookings for our classes, and everything that entails.

First he walks you through exactly what he'll guide you through building and a real world scenario where it might be used. Next he shows how to set up an account on Acuity, create appointment types and get the credentials for the API integration. From there he gets into the implementation:

• Creating a new Lumen project
• installing the PHP SDK from Acuity
• Getting a list of available class times and showing the list in a view
• Setting up the booking form and handling the submit

This last step includes reaching out to the Acuity API and submitting the information for the appointment. It's not tracked on the application's side opting to use the Acuity service as a source of record.

The TutsPlus.com site has continued their "Building Your Startup" series with this new article enhancing the application they've already created to send requests for scheduling changes.

As the Meeting Planner alpha testing phase began, the clearest feature gap was the inability to change a meeting after it had been scheduled. It's not an easy problem. Is it okay to just change a meeting without a participant's permission? Or should you ask? Or do either, depending on your role in organizing the meeting? What if you just want to ask if it's okay to meet 15 minutes later—that should be easy, right?

Solving all this required some reflecting on the social aspects of adjusting a meeting. Over time, I realized that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand.

He then starts out by describing the "tall mountain to climb" in the number of changes to backend, frontend and UX/UI functionality required to add the feature. He includes all of the code changes and additions that need to be made including:

• migrations to add new tables
• UI updates to add options for rescheduling requests
• form changes
• handling request submissions

Each point on the list includes code, screenshots and anything else that was required to make the update.

The TutsPlus.com site has updated their "Building Your Startup" series with their latest tutorial showing you how to build advanced scheduling commands allowing for things like repeating meetings, updating the meeting details and rescheduling.

I also began to realize that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand. [...] In today's tutorial, I'll cover expanding the navigation bar using Bootstrap and the basics of building some of the advanced scheduling features within Meeting Planner. Next week, I'll review building the more complex feature for participants to request change(s) and for others to accept or decline them.

He starts with the frontend, updating the navigation bar to include links to other functionality for meeting changes, repeating and showing planning activities for the meeting. He uses Bootstrap's single-button dropdowns for this and includes the code to add them to the UI with a bit of code in the view. He then gets into the main functionality of these changes showing the code to:

• make changes to a current meeting
• reschedule a meeting
• repeat a meeting
• resend invitations

The next part in the series will take a look into social engineering and UX needs for the application along with some other smaller changes.