DEV Community: Yoram Kornatzky

Household Manager: agents that run the house on the clock

Yoram Kornatzky — Thu, 15 Oct 2026 18:15:02 +0000

Household Manager is a Laravel application I am building in public. The point is not a chat window that invents a grocery list. The point is a set of agents that already know the house, already know the pantry, and already fire at 08:00 in the user’s timezone.

The four original domains are cooking, shopping, maintenance, and cleaning. Those four are now in the app. Along the way I had to make the clock honest: a missed minute is a late run, not a skipped day.

This article is the long form of the build series I have been posting on LinkedIn and X. Same facts. Room to show how the slices lock together.

Why this project

I wanted a real application for the official Laravel AI SDK, not a demo agent in Tinker. Cursor does the agentic development. The stack stays Laravel and PHP: queues, notifications, Pest, structured output, conversation memory.

Users instruct the system through a web app. Settings are plain forms. The agents do not wait for a prompt at meal time. A scheduler ticks every minute and calls them when the local clock says so.

That constraint is the whole design. If the agent only works when you open a chat, it is a recipe generator. If it works when you are not looking, it is a household manager.

The first slice: cooking

Cooking was the first function that actually did something at 08:00.

Each user has a Cooking Agent. You set breakfast, lunch, and dinner times, how many people, city and country, and dietary notes as plain text. Location is geocoded so cuisine and ingredients fit the place. One of the early test households is two people, Ukrainian lunch, not too much sugar, one person diabetic.

A scheduler runs every minute. At each meal time in the user’s timezone, a job calls the agent. The agent returns structured dishes: ingredients, cooking instructions, serving instructions, and a generated photo of the plated meal. It remembers the conversation, so the menu varies instead of repeating the same dish three days in a row.

There is a Cooking settings screen and a Meals calendar. Open a day and you get breakfast, lunch, and dinner.

Serving a meal is a real event. Stock goes down. Meal times do not invent extra dishes.

The clock before the stove

Planning the menu is only half of cooking. You still need to know when to start.

The Cooking Agent estimates preparation time as structured output. Each meal stores prep in minutes. Dishes run in parallel when that is practical. The same every-minute scheduler that handles serving fires at served_at - prep. Laravel Notifications sends one mail: start now, this is dinner, here are the dishes. Each meal is notified once.

A dinner served at 21:00 with about 30 minutes of prep mails at 20:30. A 00:15 meal with 30 minutes of prep notifies at 23:45 the day before. That wrap has to work or the clock is a toy.

Prep-time mail. The agent owns the clock, not only the recipe.

Shopping from the pantry, not from a chat

The second piece is a Shopping Agent on the same SDK. It reads the week’s ingredients, subtracts what is already in inventory, and that is the list. Inventory is grouped the way a store is grouped: Produce, Dairy, Meat and fish, and so on. Units follow Metric or US from Cooking settings. Each item gets a generated product photo.

Mark it purchased and stock goes up.

The agent only puts on the list what you do not already have.

A checkbox is the wrong payload. Need 3 kg of tomatoes and the store only has 2.5? Mark 2.5. Remaining 0.5 kg stays on the list for the next stop, not a new list. Need 3 eggs and you grab 5? Stock becomes 5, and the line is done.

Each card already holds what is left to buy. One click, no typing, means you bought that amount. A different number is a short aisle or an extra pack. Inventory only rises by the amount you enter.

The trip writes a quantity. That is what I want the agent to see: bought 2.5 kg, 0.5 kg still open, stock +2.5.

A grocery list is a running remainder, not a checkbox.

Lead time, counted back from Monday breakfast

Shopping time plus delivery time is counted back from Monday breakfast. A scheduled job, shopping:prepare, still runs every minute. It fires when now is at or after Monday breakfast minus that lead. A three-day lead starts next week’s list on Friday at 08:00. A nine-day lead skips a Monday that is already too close and lands on the next one that still fits.

Default is one shopping day and no delivery. You set days and hours on a Shopping times screen. Under the heading, a live line shows when the next list will start preparing.

One of the screenshots is that screen with 1 shopping day and 2 delivery days. Breakfast is 08:00 from Cooking, so the next list starts Friday, 11 September at 08:00 — three days before Monday breakfast. Groceries have to be in the house before that meal.

Tests that can kill a mutant

Once cooking and shopping were live, the safety net had to be real. Pest 5 on the Laravel AI SDK build, so a dish, a shopping list, and a pantry change cannot drift without a test noticing.

What landed:

Feature tests cover agents, meals, shopping, inventory, settings, and auth.
Architecture tests keep the shape of the app honest.
One Playwright browser test hits the real home page. Trap: if Vite HMR is running, Chromium waits forever on the hot file. Tests now load the built assets instead.
Evals cover the three application agents. They run only with --evals. Live-model cases still skip — the model rejects a temperature setting Pest wants to send.
Mutation testing rewrites the code on purpose and checks the suite still fails.

Numbers from a fresh local run at the time of that post:

Line coverage of app/ — 98.8%
Type coverage — 98.2%
Mutation score — 98.9%
Suite — 313 passed, 18 skipped, 933 assertions, about 16 seconds

Local Test Impact Analysis records which tests a change actually needs. CI still runs the full suite, including Chromium for the browser test. Coverage, evals, and mutate stay local.

Coverage that never kills a mutant is decoration. Mutation score is the number I care about.

Maintenance is generated from the house

Maintenance is not cleaning. Cleaning is mopping. Maintenance is the dryer vent, the gutters, the things that break if you forget them for a year.

A House screen records the property: floors and rooms, outbuildings (storage, BBQ cabin), inside facilities (pool, SPA, jacuzzi), outside (garden, trees, flowers), and equipment (fridge, oven, laundry, dryer, dishwasher). Save the inventory and a schedule appears. You can override cadence, season, start date, skip, or notes.

The Maintenance calendar is a month grid. Click a day for that day’s tasks. The same every-minute scheduler runs. At 08:00 in the user’s timezone, Laravel Notifications emails the day’s work. No tasks, no email.

A missed minute is late, not skipped

Cooking, shopping, and maintenance all sat on that every-minute scheduler. A deploy or a crash in the due minute used to drop the task: serve the meal, mail “start cooking,” plan next week’s list, send the maintenance digest. The run was gone. Nothing tried again.

The same jobs still tick every minute. They no longer need the clock to match the due minute. If the time has passed and the work is not marked done, they run it late. A delay is fine. Skipping is not.

Same-day catch-up is bounded. Breakfast due at 08:00, scheduler back at 08:05: the meal is served. A prep mail due at 07:35 still goes. Last night’s dinner can still be served shortly after midnight. Yesterday’s breakfast is left alone.

Shopping was the extra hole. The target week used to be computed from now plus lead time, so a miss that lasted into Monday slid to the following week. Catch-up now keeps the week that was due, as long as that Monday is not more than a day in the past, and passes those dates into the job so it does not plan the wrong week.

A killed run used to hold a 24-hour overlap lock. That lock now expires in ten minutes. The queued jobs that plan meals and the shopping list retry after a worker crash, instead of failing on the first attempt.

There is no extra “did it run?” table. The meal’s serve stamp, the prep-mail stamp, the shopping-list row, and the maintenance log already record whether the work ran.

Treat a missed cron as “run it when you wake up,” not “skip this one.”

Cleaning, from the same house

Cleaning is the fourth original domain. It is generated from the same house inventory. It is kept off the maintenance list.

Save the House screen and a cleaning schedule appears under the maintenance one. Kitchen counters daily. Vacuum and dust weekly. Bathroom weekly. Bedding weekly. Windows every three months. BBQ cabin weekly in summer. Pool skim weekly in summer. Dryer lint trap weekly — the yearly vent stays on maintenance.

You can override cadence, season, start date, skip, or notes. Skip a task and that day stays empty.

The Cleaning calendar is a month grid. Click a day for that day’s chores. At 08:00 local time, Laravel Notifications emails the work. No tasks, no email.

Cook, shop, maintain, clean. That is the original four.

How the pieces lock

The interesting part is not any one screen. It is the shared facts.

Cooking settings own meal times, timezone, units, and diet.
Serving a meal decrements stock.
Shopping subtracts stock from the week’s ingredients and writes a list with remainders.
Lead time counts back from Monday breakfast, not from “Sunday night.”
The house inventory generates two schedules: maintenance and cleaning. Dryer vent is maintenance. Dryer lint trap is cleaning.
One scheduler, every minute, local time. Mail at 08:00 if there is work. Catch-up if the process was down.

The agents produce structured output. The application records whether the work ran. I did not add a separate ledger for catch-up. The existing stamps were enough.

What I am testing in the Laravel AI SDK

The public series started as a clean Laravel skeleton with the SDK already wired. The goal was to exercise the SDK in a real app:

Agents and tools
Structured outputs
Conversation memory
Queues
Notifications
Testing, including evals and mutation testing

Cursor is the development environment. The application stays in Laravel and PHP. No separate agent runtime.

Where it stands

What I care about next is the same thing I cared about at the start. Does the agent still do the work when nobody is looking at the screen? If the answer is yes after a deploy at 07:59, the design is holding.

Built in public on Laravel, the Laravel AI SDK, Pest, and Cursor. Short updates go to X and LinkedIn. This is the long form.

Phone Validation in Laravel Using Abstract

Yoram Kornatzky — Mon, 17 Jun 2024 17:18:03 +0000

Our sales events platform Auctibles, collects phone numbers for several purposes:

Contact phone of sellers to be displayed to buyers
Landline phone of sellers
Mobile phone of sellers for coordination of deliveries
Mobile phone of buyers for coordination of deliveries

Phone validation in Laravel is a crucial step for our sales events platform. It plays a significant role in ensuring smooth delivery coordination and reducing the risk of fraud.

We use validation rules, a practical feature of the PHP Laravel framework, to ensure reliable validation. This is where the Abstract comes in, enhancing the functionality of our platform.

The Validation Rule

We define a validation rule, AbstractPhoneValidation that receives two parameters:

The type of phone number expected - mobile, landline, or an empty string when any type is expected,
The country of the phone number - two letters ISO 3166-1 alpha-2 code

The rule uses our Abstract API key from the configuration file.

    namespace App\Rules;

    use Closure;
    use Illuminate\Contracts\Validation\ValidationRule;
    use Illuminate\Support\Str;

    class AbstractPhoneValidation implements ValidationRule
    {
        /**
         * Create a new rule instance.
         *
         * @return void
         */
        public function __construct(
            private string $phone_type,
            private string $country,
        ) {}    


        /**
         * Run the validation rule.
         *
         * @param  \Closure(string): \Illuminate\Translation\PotentiallyTranslatedString  $fail
         */
        public function validate(string $attribute, mixed $value, Closure $fail): void
        {
            // Initialize cURL.
            $ch = curl_init();

            // Set the URL that you want to GET by using the CURLOPT_URL option.
            curl_setopt(
              $ch,
              CURLOPT_URL,
              'https://phonevalidation.abstractapi.com/v1/?api_key=' . config('app.ABSTRACT_PHONE_VERIFICATION_KEY') . "&phone=$value"
            );

            // Set CURLOPT_RETURNTRANSFER so that the content is returned as a variable.
            curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

            // Set CURLOPT_FOLLOWLOCATION to true to follow redirects.
            curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);

            // Execute the request.
            $data = curl_exec($ch);

            // Close the cURL handle.
            curl_close($ch);

                    //The response from Abstract is a JSON
            $data = json_decode($data);

                    // here, we do the validation
            if (!$data->valid || 
                // Is the phone number valid?
                ($this->phone_type && Str::lower($data->type) != $this->phone_type) || 
                // If the phone type was given, what the phone number of the required type?
                ($data->country->code != $this->country)
                // Does the country of the phone correspond to the expected country?
            ) 
                    {
                $fail('validation.' . $attribute)->translate();
            }

        }
    }

As Abstract returns the phone type capitalized, we use Str::lower to convert it to lowercase to correspond to our labeling of phone types.

Using the Validation Rule

We use the rule in validation, where the user's country two letters ISO 3166-1 alpha-2 code is stored in $country:

$rules_array = [
    'mobile_phone' => [new AbstractPhoneValidation('mobile', $country)],
    'landline_phone' => [new AbstractPhoneValidation('landline', $country)],
    'contact_phone' => [new AbstractPhoneValidation('', $this->country)],
]);

For a contact_phone, any type of phone number is acceptable.

Emulate User Activity with Bots

Yoram Kornatzky — Sun, 09 Jun 2024 17:26:03 +0000

In our sales events platform, Auctibles, sellers have the exciting opportunity to create various events. These range from a sale event at a fixed price to live auctions, where buyers bid the price up, providing a dynamic and engaging experience.

The Technology

We use the Laravel framework in the context of the TALL stack: Tailwind, Alpine.js, Laravel, and Livewire.

Why Emulation?

For a demo environment, it's crucial that we accurately emulate buyers' activity for a seller. This includes sending buy orders and chat messages. The purpose of the emulation is to allow the seller to get a feeling of how the event with multiple buyers will be observed from the event control screens. This includes changing the quantities of items still available, dynamic price changes, and chat messages from buyers.

Ordinary Buyers

The buy screen is a Livewire component. Clicking the BUY button sends a broadcast event: LiveBuy, LiveBid,...

Similarly, buyers send chat messages via a broadcast event ChatMessage.

Bots for Emulation

We emulate buyers' activity via a bot. The bot is a ReactPHP server that periodically sends the same broadcast events that ordinary buyers send.

The server receives a set_timer GET call at the event's start and a stop_timer GET call at its end.

$loop = Factory::create();
$server = new Server(function (ServerRequestInterface $request) use($loop) {

        $path = $request->getUri()->getPath();
        $method = $request->getMethod();

        if ($path == '/set_timer' && $method === 'GET') {

          $params = $request->getQueryParams();
                $event_id = $params['event_id'] ?? null;

                // start emulation

                return Response::plaintext('timer set')->withStatus(Response::STATUS_OK);   

            } else if ($path == '/stop_timer' && $method === 'GET') {

            $params = $request->getQueryParams();
                $event_id = $params['event_id'] ?? null;   

                // stop emulation

                return Response::plaintext('timer stopped')->withStatus(Response::STATUS_OK);               
                    }

});

$socket = new SocketServer('0.0.0.0:' . config('app.BOT_SERVER_PORT'));
$server->listen($socket);

$loop->run();

Laravel to ReactPHP

These calls are received from the component where the seller controls the event, using Http:

  $url = config('app.BOT_SERVER_URL') . ':' . config('app.BOT_SERVER_PORT') . '/set_timer';
  $data = [
  'event_id' => $this->event->id,
  ];

$response = Http::withQueryParameters($data)->get($url);

Starting the Bot

To start the emulation, we set a periodic timer,

$timer = $loop->addPeriodicTimer($this->period_in_seconds, function () use ($event_id) {

   $this->send_bid($event_id);
   $this->send_message($event_id);

});

We store the timer in an array:

$this->timers[$event_id] = $timer;

Stopping the Bot

$loop->cancelTimer($this->timers[$event_id]);
unset($this->timers[$event_id]);

Using Disposable Emails for a Demo

Yoram Kornatzky — Tue, 04 Jun 2024 12:34:40 +0000

We have a demo environment in Auctibles, the dynamic prices and sales events platform.

Demo Compared to Production

The demo environment has:

Emulated shipping that takes 10 minutes in each direction.
Emulated payment - you click the Pay Now button to pay, and the payment is immediately executed.

Remove Friction in the Demo

Asking people to enter their email for signup will be a central friction point in the demo. To test the demo's functionality, our customer must create several users in our demo environment.

Users for testing:

One seller user
Multiple buyer users
Optionally team member users - as a seller can operate a team

The effort to create multiple emails might cause our customers to drop.

Disposable Emails

Several providers supply temporary disposable emails that you can use for a few days. So, we decided to allow our customers to use disposable emails in the demo environment.

So now our signup page has a button to show the customer how to get a disposable email:

This opens a modal with the list of disposable email providers:

Why Not Allow Disposable Emails in the Production

At the risk of explaining the obvious, a seller or buyer must use the platform for several days to complete the purchase. The seller has to create a sales event, which will be held days before the event.

After the event, the buyer has to pay and receive the item via delivery. Subsequently, according to consumer protection laws, the buyer is allowed to return the item within 14 days.

These disposable emails are usable only for a few days, so they cannot be practically used in production.

Cyber Risks

Disposable emails create a cyber risk. It is easy for malicious actors to create disposable emails.

This is why E-Commerce and SAAS websites often prevent users from using disposable emails.

Using ApyHub for Image Moderation

Yoram Kornatzky — Fri, 31 May 2024 09:05:25 +0000

In Auctibles, we use ApyHub to moderate images of items for auction. Auctibles is built using the Laravel PHP framework.

Uploading Image Files

Videos are effortlessly uploaded using a straightforward Livewire component and an HTML input element with type=file.

<input id="photos" name="photos" type="file" class="sr-only" wire:model.live="photos" accept="image/png,image/jpg,image/gif">

The component has a public property:

public $photos = [];

Upon clicking a submit button, we apply validation to the field,

'photos' => 'nullable|array|max:3', // array
'photos.*' => [
    'required',
    'image',
    'max:10240', // 10MB
    new ExplicitImage(),
],

ExplicitImage is a validation rule.

Temporary Files

We upload temporary files to a Minio bucket which resides on the server. The bucket is defined as an uploads bucket for Laravel. This is done in config/filesystems.php.

ApyHub Results for Image Content

We use curl to call ApyHub. The response looks like this:

{
  "data": {
    "apyhub": {
      "adult": {
        "adultScore": 0.0025164163671433926,
        "goreScore": 0.0014069777680560946,
        "isAdultContent": false,
        "isGoryContent": false,
        "isRacyContent": false,
        "racyScore": 0.0032450903672724962
      },
      "metadata": {
        "format": "Png",
        "height": 1024,
        "width": 1024
      }
    }
  }
}

The Validation Rule

<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;
use CURLFile;
use CURLStringFile;
use Illuminate\Support\Facades\Storage;

class ExplicitImage implements ValidationRule
{
    /**
     * Run the validation rule.
     *
     * @param  \Closure(string): \Illuminate\Translation\PotentiallyTranslatedString  $fail
     */
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
            // path to temporary uploaded file in uploads disk
        $path = config('livewire')['temporary_file_upload']['directory'] . DIRECTORY_SEPARATOR . $value->getFilename();

        $ch = curl_init();

        curl_setopt(
          $ch,
          CURLOPT_URL,
          "https://api.apyhub.com/ai/image/detect/explicit-content/file"
        );
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST');
        curl_setopt($ch, CURLOPT_HTTPHEADER, [
          'apy-token: ' . config('app.APYHUB_TOKEN'),
          'content-type: multipart/form-data'
        ]);
        curl_setopt($ch, CURLOPT_POSTFIELDS, [
            'file' => new CURLStringFile(Storage::disk('uploads')->get($path), $value->getFilename(), $value->getMimeType()),
            'requested_service' => 'apyhub',
        ]);

        $response = curl_exec($ch);

        curl_close($ch);

        if ($response === false) {
          $error = curl_error($ch);
          logger()->warning("ApyHub image moderation CURL Error: $error");
          return;
        } else {
          // Process the successful CURL call here.
          $statusCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);

          if ($statusCode == 200) {
            // The request was successful
            $data = json_decode($response, true); //

            $response = $data['data']['apyhub']['adult'];

            if ($response['isAdultContent'] || $response['isGoryContent'] || $response['isRacyContent']) {
                $fail('validation.' . 'explicit_image')->translate(); 
            }

          } else {
            // The server responded with an error
            logger()->warning("ApyHub image moderation HTTP Error: $statusCode");
            return;
          }
        }

    }
}

Use SharpAPI for Translating E-Commerce Product Info

Yoram Kornatzky — Tue, 28 May 2024 06:38:30 +0000

In Auctibles, we use SharpAPI to translate product info.

Auctibles is built with the Laravel PHP framework.

The Service

We defined a service that will translate a text into a given language.

The service provides a translate function that translates the text parameter into the required language:

<?php
namespace App\Services;

use GuzzleHttp\Exception\ClientException;

class SharpAPI
{
    private $service;

    public function __construct()
    {
    }

    public function translate(string $text, string $to_language)
    {       

        try {

            $statusUrl = \SharpApiService::translate($text, $to_language);

        } catch(ClientException $e) {

            $rsp = $e->getResponse();
            return ['flag' => null];

        }

        $result = \SharpApiService::fetchResults($statusUrl);
        $res = json_decode($result->getResultJson());

        return ['flag' => true, 'content' => $res->content];
    }

}

The function returns an associative array, with:

bool flag - signifying success or failure
content - translated content

The Job

Because calling SharpAPI takes time, we do this asynchronously in a job, once the user saves the product information.

The job takes an $obj parameter, which is the product, and an array of $fields to be translated. The job iterates over the fields and sends each one to the service for translation.

The object comes from an Eloquent model using Laravel-Translatable. So each field is a JSON array, mapping languages to the value for that language.

<?php

namespace App\Jobs\AI;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldBeEncrypted;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;

use SharpAPI\SharpApiService\Enums\SharpApiLanguages;

use App\Services\SharpAPI;

class SharpAPITranslator implements ShouldQueue, ShouldBeEncrypted
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    /**
     * Create a new job instance.
     */
    public function __construct(private string $from_language, private $obj, private $fields)
    {

    }

    /**
     * Execute the job.
     */
    public function handle(): void
    {
            // instantiate the service
        $sharp_api = new SharpAPI();

        foreach($this->fields as $field) 
        {
                        foreach(array_keys(config('app.content_languages')) as $to_language)
            {
                if ($to_language != $this->from_language) {

                                        // get the content for the from_language
                    $text = $obj->getTranslation($field, $fromlang, true)


                    $result = $sharp_api->translate(
                        $text, 
                        $this->sharp_api_language($to_language)
                    );


                    if ($result['flag']) {
                            // store the content for to_language
                        $this->obj->setTranslation(
                            $field, 
                            $to_language,
                            $result['content']
                        );
                    }


                }
            }

            $this->obj->save();

        }

    }

    private function sharp_api_language(string $locale): string
    {
        switch($locale)
        {
            case 'en':
                return SharpApiLanguages::ENGLISH;

            case 'pl':
                return SharpApiLanguages::POLISH;

        }
    }
}

Integrating a ReactPHP Server in Laravel

Yoram Kornatzky — Sat, 25 May 2024 10:42:33 +0000

Create a Command

Create a Laravel command,

php artisan make:command SaleServer --command=bidserver:sale

This command will be a daemon that runs a ReactPHP server.

Calling the Server

The command is called with a HTTP post from a Livewire component,

Http::asForm()->post(config('auctions.SALE_SERVER_URL') . ':' .  config('auctions.SALE_SERVER_PORT') . '/buy', [
    'auction_id' => $this->auction->id,
    'item_id' => $this->item->id,
    'user' => $this->user->id,
    'price' => $bid_received['price'],
]);

The Server

The command creates a ReactPHP server, that receives these calls.

<?php

namespace App\Console\Commands;


use Illuminate\Console\Command;
use React\Http\Server;
use React\Http\Message\Response;
use React\EventLoop\Factory;
use Psr\Http\Message\ServerRequestInterface;
use React\Socket\SocketServer;

class SaleServer extends Command
{

/**
 * The name and signature of the console command.
 *
 * @var string
 */
protected $signature = 'bidserver:sale';

/**
 * The console command description.
 *
 * @var string
 */
protected $description = 'Sale bid server';

/**
 * Execute the console command.
 */
public function handle()
{
    $loop = Factory::create();
    $server = new Server(function (ServerRequestInterface $request) {

        $path = $request->getUri()->getPath();
        $method = $request->getMethod();

                //Check if the path and method of the call are correct
        if ($path == '/buy'  && $method === 'POST') {

                    //Extract the call parameters
        $auction_id = $request->getParsedBody()['auction_id'] ?? null;
        $item_id = $request->getParsedBody()['item_id'] ?? null;
        $user = $request->getParsedBody()['user'] ?? null; 
        $bid_price = $request->getParsedBody()['price'] ?? null; 

          //Broadcast a response
          broadcast(new BuyAccepted($auction_id, $item_id, $user))->toOthers();

                    return Response::plaintext('bid processed')->withStatus(Response::STATUS_OK);   

    }             

    return Response::plaintext('Not found')->withStatus(Response::STATUS_NOT_FOUND);

        });

    $socket = new SocketServer('0.0.0.0:' . config('auctions.SALE_SERVER_PORT'));
    $server->listen($socket);

  $loop->run();

}
}

Daemon in Forge

Add a daemon running the command:

php artisan bidserver:sale

What to Monitor in a Website

Yoram Kornatzky — Thu, 15 Dec 2022 11:30:42 +0000

The Conundrum of Monitoring

So you put up your website in the cloud, and your hosting company, cloud providers, and all sorts of people offer you to monitor your website.

Launching A Platform

Now that I am approaching the launch of my platform for auction events for creators, I am putting it up in the cloud. So I need to create a server where the platform will run. Having done that, I encountered so many options to monitor it.

Despite having twenty-five years of industrial experience, I still found my head swirling from all these offers. In all the IT companies I worked for, we had a DevOps or infrastructure team to monitor whatever we needed.

So I had to make some order in my thoughts. For this purpose, I created the drawing you see at the top of this article.

The Web Application and the Scheduler

We have a web application, a website with screens, and a database. For any platform, there are some jobs that we need to do every day, every week, or every month. Such jobs include sending monthly invoices. Thus, we need a scheduler to run these jobs at the required frequency.

What Should We Monitor

Uptime

We want to know that the website is up and running. This is called uptime. The uptime monitor has to run outside the server and the platform. Because otherwise, you would not know that your server is down.

Resources

Websites and servers can get overloaded, either temporarily or permanently. Temporary spikes can be due to particular days of the year, like the holiday shopping season. Permanent overload points to the need to increase the resources available.

Resource monitors require some agent to be attached to your website to report the CPU, memory, or disk load. The resource monitor can reside inside or outside the server. In many cases, you will use both. An internal monitor is cheaper but can be clogged down in overload.

Periodic Jobs

Did the jobs run on time? Were they successfully executed?

You can record somewhere on the server whether the job is finished. But you must monitor outside the server to see if a job was successfully executed. The reason is that if the job did not run, no one inside could tell you that. Maybe the scheduler is dead.

So each regular job has to report to an outside monitor on its execution. And the monitor that has a list of jobs and frequencies can compare these reports to what happened and alert you for any malfunction.

An External Scheduler

Due to all the complications of scheduling and monitoring, numerous companies offer to schedule jobs for you by calling some endpoint (function) in your platform. Such offers are often named cron something - reminiscent of the Linux cron scheduler.

Conclusion

I hope that now you can better sort all the different options for monitoring and make a cost-effective choice.

The Timeline Method for Determined Construction of Web Applications

Yoram Kornatzky — Thu, 24 Nov 2022 13:28:47 +0000

How do you approach the development of a new web application? If you are a solopreneur or SMB, you are not aiming for a big scale. You cannot afford well-known but costly development environments.

It is a challenge that I encountered repeatedly as a freelance consultant. Build it and ship it without overbuilding.

Here is the method that I usually use.

The Matrix

Think of the complete development process as a two-dimensional plane.

On the horizontal axis, we have the different phases of the evolution of the web application. This is a timeline of phases that it goes through.

The vertical time axis is the computing environment you will use.

The Time Axis - Phases

Collection of emails
Forthcoming - add information pages
Production - add sign up/sign in and rea; functionality
Add testimonials and other forms of social proof
Scale up - multiple servers, load balancing

Of course, the production phase of development will be broken into multiple sub-phases.

In the action events platform I am building, we start with notifications via email. Later we will add notifications through SMS.

The Environments

Each phase has to go through these environments,

Local development
Staging - cloud environment
Production - production environment

The reason for going through this sequence is that we need to test things before we release them.

We start with local development but must move to the cloud to demo anything.

Design Backward from Production

We design the production web application in a most general form. Then we define a subset within the general framework for the collection and the forthcoming phase.

The Structure

As we would like the collection and forthcoming phases to have the production look and feel, we work by working backward by focusing on the navigation bar and the home page.

Navigation Bar

A navigation bar with all pages that will be in production. We expose more and more pages as we proceed through the phases.

Home Page

The collection and forthcoming pages have the general look and feel but with an email collection form only. To build a mailing list.

In the production phase, we move to a real home page.

Other Pages

If any other page appears in the collection or forthcoming phase, structure it to represent the corresponding content for that phase if different from the production phase.

Conclusion

With this approach, you construct one web application for all the phases you encounter.

Thereby you get a uniform look and feel, with a single simple timeline for development, for all phases.

Experience Continuity in Hybrid Events Platforms

Yoram Kornatzky — Fri, 04 Nov 2022 11:39:46 +0000

You are building a hybrid events platform, such as the Auction Events Platform for Creators I am making. Users will be on and off the website during the event. How do you achieve continuity of the experience for your users?

Define Meaningful Moments

Choose moments when there is some phase change, such as the start of a session or lecture. In my auction platform, this is when an item (lot) comes up for auction during a live auction.

Broadcast these meaningful events to users via email, SMS, etc., so that users that are off the website know about it.

Define Sub Moments

In many event platforms, such moments are spread in time for an hour or more, during which time meaningful things happen.

In my auction events platform, we have timed auctions that run automatically from start time to end time. In a timed auction, all items come up for auction at the start time. An auction can last for days. So a user might bid and then go off to his/her life. You need to tell the user when a competing bid comes up and is on top. So the user can come back and bid again at a higher price.

In a conference session, such sub-moments could be the switch to Q&A at the end of a presentation. In a concert platform, a sub-moment is when the band starts to play a new song. The way Apple Music on a Mac shows a notification when a new song start.

Detect In-Person Presence

In a hybrid event, you want to turn off notifications for users that present IRL (in real life), as these notifications will distract them from what is happening IRL.

In the auction events platform, users present in person will be given a sign with their user number with which to bid. We will use the opportunity to record their presence on the platform and avoid sending notifications to them.

Distinguish Pre-Event and Post-Event Phases

In many event platforms and webinars, there will be interaction before and after the event. Such as chatting with organizers or speakers. In our auction events platform, users can chat with creators before, during, and after the live auction.

In the pre-event and post-event phases, you can expect users to be off the website for extended periods. And messages may come at any time. So we need to forward any message to users with a high probability of not being online in the platform via email or SMS.

During a live auction, such forwarding is not needed and is distracting from the attention on the bidding.

Conculsion

By now, most of us have participated in some virtual or hybrid conference and received a barrage of email messages around it. The snowball effect is jarring and counter-productive.

Micro-designing notifications and messaging from the standpoint of experience continuity promises a much more pleasant user experience and will lead to higher engagement.

Generic Design for a Creator Economy Platform

Yoram Kornatzky — Wed, 05 Oct 2022 10:24:09 +0000

You want to build a creator economy platform. It could be a newsletters platform, like Revue or Substack, a podcasting platform like Anchor or Transistor, or a crowd-funding platform, like Patreon or Buy Me Coffee.

How do you design such a platform? There are many moving parts and infinite possibilities. Yet, after studying many creator economy platforms, we constructed a generic design you can use to build your platform.

The Two Faces of Creator Economy Platform

A creator economy platform wears two faces:

A consumer-facing face - the link the creator gives to its fans to see the profile, newsletter, podcast, etc.
A creator-facing face - the interface through which the creator creates content, such as uploading a new podcast, writing the profile, and tweaking the consumer-facing face

The Consumer-Facing Face

The consumer-facing face is a website, possibly with a custom domain or custom subdomain.

The website presents the creator and its activities. Its specific content will be defined by what the creator economy platform is doing.

For a newsletters platform, the website will present the newsletter information, the creator information, and a listing of newsletter issues. The front page will include a call-to-action (CTA) for a subscription to the newsletter.

Generally, this website is either a one-pager or has two levels:

Creator information and list of creations (e.g., newsletter issues, podcast episodes)
A page for each creation (e.g., podcast episode)

The Creator-Facing Face

The creator-facing face is foremost a website builder - for generating and tweaking the consumer-facing face.

This includes several generic components.

Profile Creator

The profile editor sets creator details.

The profile creator tweaks the website theme and style and provides a setup for the essential assets for the website, such as the profile photo and background.

Creation Board

The board is where you create content. It includes:

Details Form

A form with inputs for creation name and additional details, and panels for uploading assets, such as cover images

Rich Text Editor

Most creations involve some long-form text. For a newsletters platform, it is a newsletter editor. For a podcast platform, it is an episode editor.

Rich Media Interface

Most creations are media, such as audio for podcasts or video for courses. The rich media interface is where you upload the media.

Through the interface, you may further process media, such as changing formats.

Integrations Setup

For most creator economy platforms, the website generated is just the presentation layer. The content has to be distributed from the platform to the consumer. If it is a newsletter, you need to mail it. If it is a podcast, you need to distribute it to podcast platforms such as Spotify or Apple Podcasts.

Hence each creator economy platform needs a section of specific integration to enable this distribution for the creator. We cannot give a generic design here.

Conclusions

Hopefully, our generic design will kickstart the design of your platform.

Custom Domain Support in Creator Economy Platforms

Yoram Kornatzky — Fri, 23 Sep 2022 16:10:35 +0000

Most creator platforms support two forms of custom domains: \

Subdomains - such as johndoe.platformX.com
Custom domain - such as platformX.johndoe.com

Describing the creator domain as part of the URL of the site, such as www.platformX.com/johndoe, is much less common.

If you are about to construct such a platform, you may wonder how complicated it is to build custom domain support.

It turns out it is straightforward.

It boils down to two things:

The user doing setup in their domain registrar or website hosting company
Routing in your platform

Domain Setup by User

You should instruct users to add appropriate DNS records in their domain registrar or hosting company. There are many examples of instructions in existing platforms that you can borrow.

The Transistor podcasting platform instructions that I recently used are excellent.

Routing in Platform

While I do not know which backend programming framework or language you use, the following in Laravel PHP is pretty generic and can be adapted to:

Any PHP framework
Express.js or any Node.js backend framework
Ruby on Rails
Java Spring Boot

Domains

Route::group(['domain' => '{subdomain}.{domain}.{tld}'], function(){

    Route::any('/', function($sub, $domain, $tld){
        return 'custom domain: ' .  
            $sub . '. ' . 
            $domain .  '. ' . 
            $tld;
    });

});

Subdomain

Route::domain('{account}.example.com')->group(function () {
    Route::get('user/{id}', function ($account, $id) {
        //
    });
});