Musings by GC

Anatomy of an AI agent

Gabriel Nwogu — Sun, 08 Feb 2026 07:27:11 GMT

The concept

Calmoth agent in action

The concept of AI agents has fascinated me ever since I first interacted with coding agents, and I’ve been thinking about how I could deploy them to be useful in my daily life.

As a multitasker, I switch context a lot across different domains. From things I need to do at work, to the shopping list I need to remember for tomorrow’s breakfast, to planning bill payments for my family summer trip, and even the drugs I need to buy for my father’s health.

To keep track of everything, I use Google Keep. Each morning, I run through the day in my head and I ask myself: "What I need to work on? What I need to do?"

I write it all down in a note. During the day, if more thoughts come up, I add them to the list, reorder things, or deprioritize.

The general idea sounds like this: I check that list to bring myself up to date on what I haven’t done yet, and to make sure I’m not falling behind on more important tasks.

This is what made it feel like a perfect use case for a personal AI agent. An agent that could send me daily briefs and do quick check-ins throughout the day about my tasks.

The caveats

I’m still a bit too paranoid/cautious to delegate truly autonomous work to an agent without a human in the loop. I’ve seen this with coding agents. When there’s no one verifying what’s being done, guiding it, and shaping how it’s used, letting an agent run free feels like a recipe for disaster. I’d be a lot more comfortable if it had clear constraints and boundaries it could operate within.

The idea of letting an agent buy drugs on my behalf, book flights, or send emails for me also raises the risk of costly mistakes. Booking a flight with extra luggage space when not needed, buying more drugs than needed, or sending the right person the right message in the wrong tone. I don’t have the luxury of tolerating those kinds of errors.

With code, these mistakes are easier to catch and manage. You can write automated specs to cover test cases, or even use another agent for reviews. But how do you run test cases for real-world actions? Things that don’t live inside your system like a program does?

That’s probably also one of the reasons I opted against running/installing OpenClaw, beyond the potential security liability the tool itself might introduce.

So I figured this might be a good opportunity to build an AI agent myself, just to understand the nitty gritty of how it all comes together under the hood.

The definitions

AI agents are jagged intelligent (borrowing from Karpathy) packaged into programs that can self-execute on your behalf, powered, of course, by LLMs.

Before agents became a thing, you still had programs (software or hardware), but humans were the ones operating them.

Take a CRM, for example. If you wanted to manage a customer pipeline:

Before AI agents: you’d call the customer yourself, categorize them, place them into buckets, and manually save that data in your CRM.

With an AI agent: the agent can do that for you. It can speak with the customer and operate the CRM on your behalf.

The hows

So, how do we actually build an AI agent? The good news, at least from where I stand, is you don’t need to be a machine learning expert to build one. Like any other software program, an AI agent is still just software. If you’re comfortable working with APIs, you already have enough to get started.

In this case, we’d be building an AI task assistant. Its main job would be to brief me daily on my tasks and todos, and check in throughout the day when necessary. To make that happen, we need a few things:

The medium: LLMs are mostly non-deterministic systems, which is why rigid, structured input forms don’t work that well. They limit what the system can interpret and do. That’s why chat has become the de facto interface for interacting with these models and collecting input. We could build our own chat UI as a web app or native app, but to keep things simple, we’ll use Telegram. Other channels work too (WhatsApp, Slack, Discord, even email), as long as they support free-form, multimedia-friendly interaction and let us programmatically send and receive messages.
The model: Of course, there’s no agent without a model. There are plenty of foundational models we could use, including self-hosted open-source options. But for this, we’ll use OpenAI’s GPT-5 Nano, mainly because I’m already a ChatGPT Plus subscriber.
The program: Finally, the agent needs a program it can actually operate on, something that exposes tools the model can call to take (in)appropriate actions. That program can be an existing tool or something you build from scratch. For this scenario, we’ll build a simple todo list app with reminder scheduling. I originally considered Google Calendar, but I realized not all my tasks have a clear due date. Sometimes I just want something on a list, and I want occasional check-ins about it.

The Medium

I'm going to skip the process of setting up a telegram bot. It's pretty easy and Telegram has a good guide on how to set it up. To summarize the steps:

We need a way to receive messages from our Telegram bot and a way to respond to those messages. We can do this with webhooks. A typical webhook handler would look like this:

class TelegramWebhookController
{
    public function __construct(
        protected TelegramAdapter $adapter,
    ) {}

    public function __invoke(Request $request, string $secret): Response
    {
        $expectedSecret = (string) config('services.telegram.webhook_secret');

        if ($secret !== $expectedSecret) {
            return response('Forbidden', 403);
        }

        $message = $this->adapter->toNormalizedMessage($request->all());

        if ($message->externalUserId === '' || $message->text === '') {
            return response('OK', 200);
        }

        ProcessInboundMessage::dispatch($message->toArray());

        return response('OK', 200);
    }
}

Telegram Webhook Handler

When we receive a request from our Telegram bot, we quickly respond back with a 200, and then process the message in the background as a queued job.
After our job processes the message and we are ready to reply to the user, we send back our message by hitting Telegram’s API:

class TelegramMessenger implements ChannelMessengerInterface
{
    /**
     * @param  array  $options
     */
    public function sendMessage(User $user, string $text, array $options = []): void
    {
        $token = config('services.telegram.bot_token');

        if (! $token) {
            Log::warning('Telegram bot token missing.');

            return;
        }

        $identity = $user->identities()
            ->where('provider', 'telegram')
            ->latest('id')
            ->first();

        if (! $identity?->chat_id) {
            Log::warning('Telegram chat id missing for user.', ['user_id' => $user->id]);

            return;
        }

        $payload = array_merge([
            'chat_id' => $identity->chat_id,
            'text' => $text,
        ], $options);

        Http::post("https://api.telegram.org/bot{$token}/sendMessage", $payload);
    }

Responding to message

As we can see, we obviously need a datastore for users interacting with our agent. We can store this anywhere: Postgres, MongoDB, MySQL, even Redis. We just need to be able to reference user data somehow. In my case, I used a MySQL datastore (yes, I know. I didn't use Postgres, Supabase, Convex, PlanetScale. I'm an old-school guy, running self-hosted MySQL. Ok I'm kidding. I already pay for managed MySQL for my blog, so I used it here).

I have a User model that stores basic user info like name and timezone. I also have a UserIdentities model that stores metadata about the channel in use (Telegram in this case, but it can also be used for WhatsApp or other channels).

Awesome, we now have a functioning medium (Telegram). We can receive messages and respond to messages. Let's move on to the program.

The program

AI agents need a program to run against. Something they can actually execute on. In our case, that program is a todo list system.

At the task level, I need to be able to create, list, edit, update, and delete tasks. Tasks should support optional due dates, and I should be able to assign priorities when needed.

On top of that, I need reminders. I should be able to set, pause, snooze, delete, or dismiss a reminder for a task. Reminders can be one-off or recurring (up to a defined period). And for check-ins, I can treat those as recurring reminders, but with random intervals.

Also, the program doesn’t have to live inside the agent. It can be external, or even multiple programs, like an agent that operates your WhatsApp or email on your behalf.

For our todo list program, to keep it simple, we’ll stick to two tables/models: tasks and reminders, plus a service class that performs the actions.

tasks()->create([
            'title' => $title,
            'notes' => $notes,
            'due_at' => $dueAt,
            'status' => 'open',
            'created_via' => $createdVia,
        ]);
    }

    /**
     * @param  array  $attributes
     */
    public function update(User $user, int $taskId, array $attributes): ?Task
    {
        $task = $user->tasks()->whereKey($taskId)->first();

        if (! $task) {
            return null;
        }

        $task->fill($attributes);
        $task->save();

        return $task;
    }

    /**
     * @return Collection
     */
    public function listOpen(User $user, int $limit = 5): Collection
    {
        return $user->tasks()
            ->where('status', 'open')
            ->latest('id')
            ->limit($limit)
            ->get();
    }

    public function complete(User $user, int $taskId): ?Task
    {
        $task = $user->tasks()->whereKey($taskId)->first();

        if (! $task) {
            return null;
        }

        $task->update([
            'status' => 'done',
            'completed_at' => now(),
        ]);

        return $task;
    }
}

Our Todo list Program for Tasks

Now we finally have our todo list program. Let's go to the hard part

The Model

The model is what actually brings life to the whole agentic journey. Think of it like a conductor sitting between two moving parts, the medium and the program, and orchestrating how they work together. The model lives in the middle, working “effortlessly” (hard?) to carry out its goal. Its life’s work.

A simple agentic LLM integration usually looks something like this:

Simple LLM Integration journey

But there are three things we need to think through:

How do we get the LLM to reliably interact with our program?
How do we manage context, memory, and tokens especially given model constraints and the degradation that happens as you get close to token limits?
And how do we make it actually feel like an agent one that follows up and breaks out of the boring request/response loop?

Tool Calling

With tool calling, we give the LLM a direct way to interact with our program. In simple terms, we’re telling the model: these are the tools my program exposes, this is what each one does, and this is how you call them.

 'function',
            'function' => [
                'name' => $this->name(),
                'description' => 'List open tasks for the user.',
                'parameters' => [
                    'type' => 'object',
                    'properties' => [
                        'limit' => ['type' => 'integer'],
                    ],
                ],
            ],
        ];
    }

    public function handle(User $user, NormalizedMessage $message, array $args, string $timezone): ToolHandlerResult
    {
        $limit = (int) ($args['limit'] ?? 10);
        $tasks = $this->taskService->listOpen($user, max(1, min($limit, 25)));

        $items = $tasks->map(function ($task) use ($timezone) {
            return [
                'id' => $task->id,
                'title' => $task->title,
                'due_at' => $task->due_at?->timezone($timezone)->toIso8601String(),
            ];
        })->values()->all();

        return new ToolHandlerResult(true, [
            'tasks' => $items,
        ], $items === [] ? 'You have no open tasks.' : 'Here are your open tasks.');
    }
}

List Tasks Tool

The anatomy of a tool:

Every tool needs three things:

A name: so the model has something to reference
A definition/schema: so the model understands what the tool does and what inputs it expects
A handler: the actual code that runs when the model calls the tool, passing the arguments into our program

For example, our “list tasks” tool (seen above) has its own schema that explains exactly how the model can invoke it. You can think of it like an OpenAPI spec, but for models.

class OpenAiClient implements ModelClientInterface
{
    public function generateToolCalls(array $messages, array $tools, array $settings = []): array
    {
        $apiKey = config('services.openai.api_key');
        $model = $settings['model'] ?? config('services.openai.model', 'gpt-4o-mini');
        $baseUri = rtrim((string) config('services.openai.base_uri', 'https://api.openai.com/v1'), '/');

        if (! $apiKey) {
            return [
                'error' => 'missing_api_key',
            ];
        }

        $payload = array_merge([
            'model' => $model,
            'messages' => $messages,
            'tools' => $tools,
            'tool_choice' => 'auto',
        ], $settings['payload'] ?? []);

        /** @var \Illuminate\Http\Client\Response $response */
        $response = Http::withToken($apiKey)
            ->post("{$baseUri}/chat/completions", $payload);

        return $response->json();
    }
}

We can make our model aware of our tools, sending it together with our message

Conversation and Memory Management

I also needed a way to preserve context, so I stored the full conversation between the user and the agent. When sending a message to the LLM, I include the relevant chat history along with it. That way, the model has the context it needs at the right time.

Conversation roles:

To keep things structured, I grouped messages into three roles:

User: messages sent by the user

Assistant: messages sent by the model/agent

Tool: messages generated as a result of tool calls (i.e., tool responses)

This makes it easier for the LLM to follow the thread: it can see what the user asked, what it responded with, what tool it triggered (and what came back), and where the conversation left off.

|null
     */
    protected function toModelMessage(ConversationMessage $message): ?array
    {
        if ($message->role === 'user') {
            return [
                'role' => 'user',
                'content' => $message->content ?? '',
            ];
        }

        if ($message->role === 'assistant') {
            $payload = [
                'role' => 'assistant',
                'content' => $message->content,
            ];

            if ($message->tool_calls) {
                $payload['tool_calls'] = $message->tool_calls;
            }

            return $payload;
        }

        if ($message->role === 'tool') {
            return [
                'role' => 'tool',
                'tool_call_id' => $message->tool_call_id,
                'content' => $this->encodeToolResult($message->tool_result ?? []),
            ];
        }

        return null;
    }
}

Building conversation history for the LLM

Conversation rotations:

Rotating Conversations

To manage token limits and avoid sending an extra-large context window to the LLM, I implemented conversation rotation. The idea is that only the active conversation contributes to the history we send to the model, and only one conversation can be active at a time.

conversation (active/inactive) -> conversation messages

where('user_id', $user->id)
            ->where('channel', $message->channel)
            ->where('external_user_id', $message->externalUserId)
            ->where('status', 'active')
            ->latest('last_message_at')
            ->first();

        if ($conversation && $this->shouldRotateConversation($conversation)) {
            $conversation->update(['status' => 'inactive']);
            $conversation = null;
        }

        if ($conversation) {
            return $conversation;
        }

        return Conversation::query()->create([
            'user_id' => $user->id,
            'channel' => $message->channel,
            'external_user_id' => $message->externalUserId,
            'status' => 'active',
            'last_message_at' => now(),
            'metadata' => null,
        ]);
    }
 }

Auto generate new active conversation to prevent large context and token limits

Now, how do we decide when to rotate a conversation? There are a few approaches I think we could take:

Idle time: rotate if the last interaction is older than x minutes/hours/days

Message count: rotate if the conversation has more than x messages

Token-based: if we assume 1 token ~= 4 characters, we can estimate token usage and rotate once we hit a cutoff

To keep things simple, I went with a blend of the first two. There are definitely better ways to do this. In fact, I can already see a potential issue, especially once we introduce an agentic loop:

last_message_at) {
            return true;
        }

        $idleMinutes = $conversation->last_message_at->diffInMinutes(now());
        if ($idleMinutes >= $this->maxIdleMinutes) {
            return true;
        }

        $messageCount = $conversation->messages()->count();

        return $messageCount >= $this->maxMessages;
    }
}

Conversation rotation based on last message and message count

The upside is that we cap how much context we send at once. And if we want to go a step further, we can give the LLM a tool to search older conversations when it needs missing context, assuming it has enough of a clue about what to search for.

For example, a user might say: “I've completed the task we talked about last week Friday.” At that point, the agent probably won’t have last week’s messages in its current context, but it can still place a tool call to fetch conversation history from last week Friday and follow up from there.

The agentic loop

What really makes an agent an agent is its loop. If we want to break out of the request/response cycle, we need the system to be able to act, observe, and act again without requiring the user to keep nudging it.

To see why this matters, let’s reuse the earlier scenario. The user says: “I've completed all the tasks I listed last week Friday. We can mark them as done.”

If we decompose this message, we can see that involves multiple tool calls:

call list_task, filtered by date, to find the tasks from last week Friday

call update_task to mark each task as completed

And if we assume we don’t have bulk updates, and there are 3 tasks, that’s already three update calls.

The agentic loop

We can already start seeing the issue with request/response flow. It would be terrible UX to expect the user to always come back with the next instruction. Ideally, the agent’s 4 tool calls should happen in one go, without the user having to babysit the process. While those tool calls are running, it would be nice if the user stays informed (and relaxed) instead of wondering what’s happening behind the scenes. That’s where the agentic loop comes in. It basically translates to:

While this action is not yet complete, continue doing x

I'm sure you might be wondering, how can we tell if the agent's outcome is not yet complete. That's where the system prompt comes in. The brain child/soul of the agent.

You are a task and reminders assistant. Use the provided tools to take actions. Stay within tasks, reminders, and summaries. When you create a task, the system will automatically attach a reminder (check-in by default, or scheduled if due_at is provided). When the user wants to change a task, use update_task (find tasks first if needed to resolve references). Check-ins are random by default; use fixed intervals only when explicitly requested. All reminders require acknowledgement. If the user confirms or says done, dismiss the reminder. If they ask to delay, snooze it. When you need to send multiple user messages, respond with JSON: {"messages":["first","second"]}. When you want a follow-up turn without waiting for the user, respond with JSON: {"messages":[...],"next":{"type":"follow_up","reason":"..."}}. If you need to call tools, call them first and leave the message content empty; you will get another turn to respond after tool results are returned.

In that prompt, we’re explicitly telling the agent to follow up when it needs a follow-up. But because I have agent trust issues, I also added a breaker to cut the loop just in case the agent overlord decides it wants to loop forever.

The Ending

Putting it all together, we’ve walked through a rough anatomy of what makes an agent an agent: tool calling, memory and context management, the underlying program, the LLM, and the agentic loop. It's not an anatomy grounded in expertise and given the way the AI space evolves, this might become obsolete in a few months. Heck, there are already AI agents building AI agents. It is just what it is. It’s no longer a matter of what an agent is, but what it’s about to do next.

Check out the project: here

Implementing OTPs via USSD in your application

Gabriel Nwogu — Thu, 24 Sep 2020 13:31:23 GMT

Whether you are requiring 2FA, or validating a phone number, or completing user registration, or seeking authorization to perform a certain action on your app, One Time Passwords have become a regular feature of the systems we use.

They serve as an extra layer of security in your application or sometimes as the default layer and I can fairly postulate that an app lacking an OTP feature eventually implements/enables it in the long run. Case in point: Piggyvest after the cowrywise saga 💀

Although OTPs can be delivered via different channels (At uLesson, we make use of voice,SMS,WhatsApp and most recently USSD as delivery channels for OTP), the default option has traditionally been SMS, and for most apps, SMS remains the only option.

But the two main problems with SMS as a channel is the unreliability of delivery and the speed at which it is delivered, and this can worsen your user experience, especially when it is tied to user registration/ on-boarding. Case in point: abeg.app having problems with OTPs on launch day. 💀

USSD as a channel solves both problems to a fair extent. It is instant, OTPs can be generated in seconds and you can be sure of its reliability to a large extent, compared to SMS were the DND directive may mess you up. The downside to this however, is that it costs twice as much to dial into a USSD session, as opposed to sending an SMS. The setup costs for the USSD code itself might be on a high side for startups and businesses alike. Regardless, it makes for a solid option as an alternative to SMS delivery in these climes.

Here's a high level overview of how we implemented OTP via USSD on the uLesson app for our users in Ghana and Nigeria.

Flow diagram showing the process flow for OTP generation via USSD

The OTP request:

The process starts from a request by the client on the app to the USSD short code which is provided by the USSD service. (Using third party providers like Africastalking is much more a preferable option for your USSD service than integrating directly with the telcos for obvious reasons like bureaucracy and discrepancies in API contracts from the different network providers.) As soon as the client request comes in, the USSD service picks up the request and forwards the details to the application backend server.

The OTP generation:

The backend server receives the request from the USSD service, in our case, through a callback url. Here we are able to retrieve the user's phone number via the request.

We need a data store to hold the value of the OTP and its generation time. We also need to make sure that phone numbers are acting as a user identifier of some sort within the application. This is important to be able to validate the inputed OTP against the generated one. In this case, phone numbers are the primary account identifier.

OTPs are normally within the range of 4 to 8 digits and usually have a validity period. To solve for the case of a user making multiple requests within the same validity period, when generating the OTP, we make a check first by searching the datastore to determine if the user identified by the phone number has an existing OTP that is valid for the period. If our search returns a result, we send back that value to the USSD service, if not, we proceed with generating an OTP with the preferred length and saving it against the user's phone number on the datastore.

OTP validation:

We can retrieve the inputed OTP from the client via a form or any interface designed for this purpose. Ideally the user's phone number should already be in your system, if not, you will need to collect this as well. The client sends the request directly to the backend, rather than the USSD service, where the OTP is then validated against the user's phone number and the stipulated expiry time.

Sample code showing OTP validation

We've explored at a high level how OTPs can be delivered via USSD. There are multiple use cases depending on what your OTP is being used for. There is also higher reliability for the delivery.

Hopefully we get to see more applications exploring this channel.

**thanks to etinosa obaseki for the edits.

Event-Driven Development in Laravel

Gabriel Nwogu — Thu, 05 Mar 2020 14:42:41 GMT

I recently started a fresh project with my people at WTS. A SaaS themed solution for content creators to engage with their fans. (Oh by the way, we've put out new music: Lofn 3, a collection of love stories. Go check it out).

Landing Page Mockup For TrivYeah

As with all things new, A SaaS application usually starts out with simple functionality, without intertwined logic and complex calculations. User Logs in, User creates A, C happens. User updates B, D is calculated. User logs out. etc. But as the user base grows, or even as active development continues, new business requirements come up that entirely threatens the structure of existing logic. If the codebase is not rightly structured, it is likely to drift into a plethora of issues. Longer functions, longer constructor parameters, nested ifs within nested ifs within nested loops.

That's how legacy code bases are born. New developers are afraid to touch the code, it takes days to understand what is going on, a lot of logic all happening in one place.

Having complex domain logic cannot be avoided when building SaaS applications, however the right approach must be taken to keep the codebase understandable, maintainable and structured. A good way to begin would be to adopt the OOP principles, having classes, interfaces and objects which are SOLID will provide a basic structure for the application of business requirement.

What about events? How does it come into play here?

The cost of increasing changes

Let's take the TrivYeah app as an instance. The application is a multi tenant system, that is, each registered organization on the app will have its own database, pointing to its own hostname.

createOrganization($tenantInformation)
    
            $hostName = $this->createHostName($tenant);
            
            if ($tenant->isPremiumUser()) {
            
            	$this->setUpTenantDatabase($tenant, $hostName);
            }

            return $tenant;
        });
    }
}

A System Service Object

Here we see that a couple of things are going on in the createTenant method, we are creating:

An Organization
A hostname for the organization
A database for the organization

At the surface, everything seems good. Not much is going on, just basic stuff. Now after a couple of days, we decide that we want to add some default configuration settings for newly created organizations. We can easily go back to our method and add a few lines of code.

createOrganization($tenantInformation)
    
            $hostName = $this->createHostName($tenant);
            
            if ($tenant->isPremiumUser()) {
            
            	$this->setUpTenantDatabase($tenant, $hostName);
                
                //create default settings here
                $this->createDefaultSettings($tenant);
            }

            return $tenant;
        });
    }
}

Add default settings to the tenant creation process

There. Done. Nobody died. Nothing difficult. Right?

Well, two more days later, business requirement changes and now we need to create an admin user in the tenant database as soon as the database is created. That's right we'll just go back to that method and add a few more lines.

createOrganization($tenantInformation)
    
            $hostName = $this->createHostName($tenant);
            
            if ($tenant->isPremiumUser()) {
            
            	$this->setUpTenantDatabase($tenant, $hostName);
                
                //create default settings here
                $this->createDefaultSettings($tenant);
                
                //create admin user
                $this->createAdminUser($tenant);
            }

            return $tenant;
        });
    }
}

Add Create Admin Logic to the createTenant method

We can both see where this is going, what happens when business requirements keep changing/growing? What if we need to send out an immediate welcome email, or create a default account ledger for the organization?

It most often would lead to an inflated code base, filled with different logic, that can become more complex and hard for new developers who would be working on the project to quickly understand.

Decoupling logic using events

Events depict that an activity is taking place. We can make use of events to build modularized applications. The more modular our application is, the more maintainable it will be.

Think of events as a kind of interface that allows interested parties to plug into an activity. Let's go back to our example method above.

We can rewrite our createTenant function to make use of events to achieve its goal.

createOrganization($tenantInformation)
    
            event(new TenantCreated($tenant, $tenantInformation));

            return $tenant;
        });
    }
}

Our createTenant method triggering an event

Here, the only thing we do in our method is to actually create the tenant (which is the organization). By triggering the TenantCreated event, we are telling other interested parties that the Tenant has been created, then we return the newly created tenant.

class TenantCreated
{
    
    public $tenantInformation;
    
    public $hostName = null;
    
    public $tenant;
    
    public function __construct(
    	Tenant $tenant, array $tenantInformation
    )
    {
    	$this->tenant = $tenant;
        $this->tenantInformation = $tenantInformation;
    }
    
    public function setHostName(HostName $hostName)
    {
    	$this->hostName = $hostName;
    }
}

The TenantCreated Event Class

Now that we have triggered our event, we can now create several handlers/listeners that will act on this event.

class CreateHostName
{
	/**
    * @var System\Services\SystemService
    */
	protected $service;
    
    public function __construct(SystemService $service)
    {
    	$this->service = $service;
    }
    
    public function __handle(TenantCreated $event)
    {
    	$hostName = $this->service->createHostName($event->tenant);
        
        $event->setHostName($hostName);
    }
}

Create Host Name Listener

class SetupDatabase
{
	/**
    * @var System\Services\SystemService
    */
	protected $service;
    
    public function __construct(SystemService $service)
    {
    	$this->service = $service;
    }
    
    public function __handle(TenantCreated $event)
    {
    	$this->service->setUpDatabase(
        	$event->tenant, $event->hostName
        );
        
        $this->service->createDefaultSettings($event->tenant);
    }
}

Setup Tenant Database Listener

class CreateAdminUser
{
	/**
    * @var System\Services\SystemService
    */
	protected $service;
    
    public function __construct(SystemService $service)
    {
    	$this->service = $service;
    }
    
    public function __handle(TenantCreated $event)
    {
        $this->service->createAdminUser(
        	$event->tenant, $event->tenantInformation
        );
    }
}

Create Admin User Listener

We can see how we have made use of events to decouple our code. When the TenantCreated event is triggered, Laravel passes the event object to all the registered listeners of that event. First the CreateHostName listener is called, followed by the SetupDatabase listener, followed by the CreateAdmin listener. Each listener gets called in the order you define them.

If we have a new requirement which needs to be done when creating our tenant, we do not need to touch the createTenantMethod. All we need to do is write a listener to handle the event.

class SendWelcomeEmail
{
    public function __handle(TenantCreated $event)
    {
        $event->tenant->notify(
        	new System\Notifications\WelcomeToTrivYeah
        );
    }
}

SendWelcomeEmail Listener

Events beyond modularization

Apart from helping with decoupling code, we can make use of events to trigger application level changes like, dynamically registering route files, appending middlewares, or even setting a new route action.

class IdentifyTenantServiceProvider extends ServiceProvider
{
	public function register()
    {
    	$this->app->bind("tenancy", function ($app) {
        	return new System\Tenant\Tenancy($app);
        });
    }
    
	public function boot()
    {
    	$this->app->resolve("tenancy")->identifyTenant()
    }
}

IdentifyTenantServiceProvider

Here we have a service provider, that identifies a tenant by the environment. We can let other aspects of our application know when a tenant has been identified by triggering an event.

class Tenancy
{
	//... other random magic
    
	public function identifyTenant()
    {
    	$tenant = $this->app->runningInConsole() ? 
                $this->identifyByConsole() : 
                $this->identifyByHttp();
                
         return $this->dispatchTenantIdentifiedEvent($tenant);
    }
    
    public function dispatchTenantIdentifiedEvent($tenant = null)
    {
    	$event = $tenant == null ? new NothingIdentified :
        		new TenantIdentified($tenant);
        
        event($event);
    }
}

System\Tenant\Tenancy class

We are dispatching two types of event, depending on the outcome of resolving the tenant. If a tenant is resolved, we trigger the TenantIdentified event, if not, we trigger the NothingIdentified event.

class TenantIdentified
{
	public $tenant;
    
    public function __construct(Tenant $tenant)
    {
    	$this->tenant = $tenant;
    }
}

The TenantIdentified Event

This gives us the ability to plug into any of the scenarios. In our case, we want to load a route file based on the tenant.

class LoadTenantRouteFile
{
	protected $service;
    
    protected $router;
    
    protected $defaultTenantRouteFile = "tenant/routes/api.php";
    
    public function __construct(TenantService $service, Router $router)
    {
    	$this->service = $service;
        $this->router = $router;
    }
    
    public function __handle(TenantIdentified $event)
    {
    	$routeFile = $this->service->getRouteFileForTenant(
        	$event->tenant
        ) ?? $this->defaultTenantRouteFile;
        
        $this->flush()->setRouteFile($routeFile);
        
    }
    
    protected function flush($router)
    {
    	$this->router->setRoutes(new RouteCollection());
        
        return $this;
    }
    
    protected function setRouteFile($router, $routeFile)
    {
    	$this->router->group(
        	['middleware' => 'api'], base_path($routeFile)
        );
    }
}

LoadTenantRouteFile Listener

A few things are going on here. First, we get the tenant route path based on the organization, if the tenant has a route configured, we save it in memory, else we use the default tenant route path. We then get the router instance from Laravel's container, flush the existing route collection, and set the new path for the tenant on the router. Done. Dazzzall.

One more reference

In Italo Baeza's recently released package, Laraguard, we see another example of how events are used to manipulate functionality.

This package silently enables two factor authentication using 6 digits codes, without Internet or external providers.

    /**
     * Register a listeners to tackle authentication.
     *
     * @param  \Illuminate\Contracts\Config\Repository  $config
     * @param  \Illuminate\Contracts\Events\Dispatcher  $dispatcher
     */
    protected function registerListener(
    	Repository $config, Dispatcher $dispatcher
    )
    {
        //Some magic happened here!
        
        $dispatcher->listen(Validated::class,
            'DarkGhostHunter\Laraguard\Listeners\EnforceTwoFactorAuth@checkTwoFactor'
        );
    }

LaraguardServiceProvider.php

A listener is hooked into the Illuminate\Auth\Events\Validated event, which gets fired after a login attempt is validated. When this happens, the package plays out its own validation logic.

shouldUseTwoFactorAuth($event->user)) {

            if ($this->isSafeDevice($event->user) 
            || ($this->hasCode() && $invalid = 
            $this->hasValidCode($event->user))) {
                return $this->addSafeDevice($event->user);
            }

            $this->throwResponse($event->user, isset($invalid));
        }
    }
}

EnforceTwoFactorAuth.php

Conclusion

We've been able to explore ways how events can help us build more structured apps. It may sound like it's more work. The tempting feeling of :

"why write more classes? when you can just do everything in one place?"

It shouldn't be about what you can do for the code, or the necessity of agile sprints. If your code could speak, what would it say about you?

For more references about events in Laravel, The official documentation is splendid:

https://laravel.com/docs/master/events

If you liked this piece, send a holla on twitter @gabrielnwogu

**thanks to etinosa obaseki for the edits.

Build a Whatsapp Game Bot with Laravel and Twilio

Gabriel Nwogu — Sun, 05 Jan 2020 15:41:32 GMT

There's a word game I find very addictive. I play it often, usually in transit and stuck in one terrible traffic from Opebi to Ogba.

Word Cross Game On Mobile

The game is pretty straight forward. You're given a couple of letters and some empty word blocks. You are expected to construct some words with the given letters. A correctly formed word fills the empty block. If you fill all the blocks correctly, you get points and move to a new level.

We could replicate this game and its functionality with a WhatsApp bot.

Prerequisites:

Twilio Account
Composer
Laravel Installation
Good Knowledge of PHP
Good Knowledge of Laravel Framework
Ngrok

Twilio Account:

Twilio is a service that allows us to programmatically add communication services through its suite of APIs. We are going to use Twilio to make API calls between WhatsApp and our application, because getting direct access to WhatsApp's API involves a rigid approval process.

Visit Twilio on your browser by going to https://twilio.com (PS: Referral Link, I get sms credits if you sign up with my link)

Twilio's Landing Page

Check your inbox for the verification mail

After verifying your email, you need to also verify your phone number before you'll be granted access to the sandbox.

Verify your phone number as well

You'll be taken to a setup page were certain questions will be asked to customize your experience. You can answer as you please.

Our goal today is to use Twilio in a project

We want to Send Whatsapp Messages first

If you selected the "Send WhatsApp Messages" option on the last setup page. You'll be taken to the messaging dashboard.

Twilio's messaging dashboard

Click on the "Sandbox" menu option on the sidebar to go to our sandbox

Twilio WhatsApp Sandbox

Congratulations, you've just set up your Twilio WhatsApp sandbox. We shall come back here to configure our call back url.

Laravel Installation:

Next, we create our Laravel project. I'm assuming you already have composer installed.

From your terminal, type:

composer create-project --prefer-dist laravel/laravel word-game

This will scaffold a new Laravel application for us into a folder called word-game.

We need to also install Twilio's sdk which we will use to return our responses. (We''ll see this in use later)

composer require twilio/sdk

Okay great. Now we're set up. Its time to jump into some coding action.

Let's define our callback url. Twilio will send our WhatsApp messages to this endpoint as a post request, then we can look at the message and determine what to send back to the user.

In our routes/api.php file, add this line:

Route::post('/word-game', 'WordGameController');

Here we are telling Laravel to invoke WordGameController any time the endpoint is matched. We need to create that controller, since it doesn't exist yet.
You can spin up a controller by typing in the terminal:

php artisan make:controller WordGameController --invokable

Invokable Controller

Our Controller has only a single action, which is why we are using an invokable controller. Laravel will automatically call the invoke method. You can read more on invokable controllers in the Laravel documentation

Twilio provides us with a MessagingResponse class to help us handle our messages. It converts our message to Twilio's TwiML response format. We shall come back to this controller later.

`Schemas:`

On your terminal, type:

php artisan make:migration create_gamers_table && php artisan make:migration create_games_table


This will scaffold two migrations for us in database/migrations folder
Schema::create('gamers', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name')->nullable();
            $table->string('phone_number')->unique();
            $table->string('points')->default(0);
            $table->string('level')->default(0);
            $table->timestamps();
        });
Gamer Schema Up Method
Schema::create('games', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('gamer_id');
            $table->longText('question');
            $table->longText('answer');
            $table->integer('points')->default(0);
            $table->integer('attempts')->default(0);

            $table->foreign('gamer_id')
                    ->references('id')
                    ->on('gamers')
                    ->onDelete('cascade');
            $table->timestamps();
        });
Game Schema Up Method
Our Gamer will contain a name, a phone number, points (To track total game points) and game level.

Our Game will hold the question, its answer, points, and gamer_id because each game will belong to a gamer.

Models:

We will scaffold the models for our migrations by running the command:
 php artisan make:model "Models/Gamer" && php artisan make:model "Models/Game"
This will create our models in an App\Models directory. PS: I prefer having my models in that directory structure but it's entirely optional and a personal preference.
belongsTo(Gamer::class);
    }
}
Game Model
hasOne(Game::class);
    }
}
Gamer Model
Actors and Workflow:
Our game bot has a guided workflow. There's no fancy AI going on. No NLP to detect intents and actions. We are basically giving instructions to our gamers through keywords and expecting specified answers. 
Actors:
We will make use of a handler class, which we'll call an Actor, to interact with any incoming message from a gamer. The Actor class will simply do two things. Take the incoming message, check if it should respond, and return a response to the gamer.
Actor Contract:
From our workflow, we know what an actor is suppose to do. We will create an interface to enforce this contract.
App/Contracts/ActorContract.php
The static shouldTalk method will take in the gamer and the message sent as parameters, then return a boolean if the actor should talk or not.
The talk method will take an optional data parameter, perform some logic and return a response to the gamer.
Let's define a base class that will implement this contract, because why not? The father bears the burden of the children.
gamer = $gamer;
        $this->message = $message;
    }

    /**
     * Call an Actor from within an Actor
     * @param string $actor
     * @param mixed $data
     * @return string $convo
     */
    protected function call($actor, $data = null)
    {
        $actor = new $actor($this->gamer, $this->message);
        return $actor->talk($data);
    }
}
App\Actors\Actor.php
Our call method will allow us to pass an actor from within an actor, as we will see later. 
Keywords:

Lets create the keywords our game will interact with. I shall put this in a constants class.
App\Constants\KeyWords.php

I'm keeping the keywords restricted to four letters. Just to make it concise.
The play keyword will begin the game. We will define actors that will respond to this keyword.
Conversations:

I'll add another constants class to hold conversation values.
App\Constants\Conversations.php
Notice our SALUTE constant has a place holder (extra_greet _key). This placeholder will be replaced within our actor when responding to a gamer
Actor Factory:
The Actor Factory is responsible for generating the actor suitable for an incoming message.
resolveGamer($phoneNumber);
        $this->actor = $this->resolveActor($message);
    }

    /**
     * Make Actor
     */
    public static function make()
    {
        $self = new static(
            Request::get("From"), 
            Request::get("Body"));

        return $self->actor;
    }

    /**
     * Resolve Gamer
     * @param $gamer
     * @return void
     */
    protected function resolveGamer($phoneNumber)
    {
        $this->gamer = Gamer::firstOrCreate([
            'phone_number' => $phoneNumber
        ]);
    }

    /**
     * Resolve Actor
     * @param $message
     * 
     * @return App\Contracts\Actor
     */
    protected function resolveActor($message)
    {
        $message = $this->normalizeMessage($message);

        $actors = $this->getActors();

        foreach ($actors as $actor) {

            if ($actor::shouldTalk($this->gamer, $message)) 
                return new $actor($this->gamer, $message);
        }
        return new \App\Actors\SaluteActor($this->gamer, $message);
    }

    /**
     * Trim and lower case the message
     */
    protected function normalizeMessage($message)
    {
        return trim(strtolower($message));
    }

    /**
     * Get available actors
     * @return array
     */
    protected function getActors()
    {
        return [
            App\Actors\PlayKeywordActor::class,
            App\Actors\GameActor::class,
            App\Actors\SaluteActor::class,
        ];
    }
}
App\Factories\ActorFactory.php
This code is pretty explanatory, first we get the phone number and message from the request body in the static make method. Next we pass these values to the resolveGamer method, which just retrieves or persist the gamer from our data store. We then go ahead to pass the message to the resolveActor Method. This method gets all the actors (We'll create them soon), loops through them and calls the shouldTalk method already defined in the Actor contract. If the return value is true, the Actor Class is instantiated with the phone number and message as parameters.
SaluteActor:
Lets start with our first Actor. This Actor will greet the gamer on first interaction. Our Salute Actor Class will look like this:
game == null;
    }

     /**
     * Converse
     * @return string
     */
    public function talk()
    {
        $conversation = Conversations::SALUTE;

        foreach ($this->buildConvo() as $key => $value) {
            $conversation = str_replace($key, $value, $conversation);
        }
        return $conversation;
    }

    /**
     * Build Conversation
     */
    protected function buildConvo()
    {
        $extra_greet_key = $this->addExtraGreeting();

        return compact('extra_greet_key');
    }

    /**
     * Add Extra Greeting
     */
    protected function addExtraGreeting()
    {
        $extraGreeting = "";
        if ($this->gamer->level < 1) {
            $extraGreeting .= Conversations::EXTRA_GEETING;
        } elseif ($this->gamer->level > 1 && $this->gamer->points < 7) {
            $extraGreeting .= "Nice to see you again. 
            You didn't do well the last time. You are in the bottom ".rand(10, 100)." players 
            with just {$this->gamer->points} points. Try beating your last score";
        } else {
            $extraGreeting .= "Nice to see you again. 
            You are smashing it. You're in the top ".rand(10, 100)." players with {$this->gamer->points} points.
            Try beating your last score";
        }
        return $extraGreeting;
    }
}
App\Actors\SaluteActor.php
In our shouldTalk method, we only want to greet the gamer, if there's no active game, while in our talk method, we are getting the placeholder values from our constants and replacing them with dynamic values.
PlayKeyword Actor:
This actor will act on the play keyword, if there is no current game.
game == null && 
        Keywords::START == $message;
    }

     /**
     * Converse
     * @return string
     */
    public function talk()
    {
        $question = QuestionFactory::make()->generate();
        
        $puzzle = join("\n", $question["puzzle"]);

        $this->gamer->game()->updateOrCreate(['gamer_id' => 
            $this->gamer->id],[
            "question" => $question]);

        return $this->printPuzzle($puzzle, $question["shuffled"]);
    }
}
App\Actors\PlayKeywordActor.php
In our talk method, we generate our questions from a question factory, store the question in the db and return the question to the gamer.
Game Actor:
The Game actor is responsible for handling the gamers responses to question.
game;
    }

     /**
     * Converse
     * @return string
     */
    public function talk()
    {
        $answerScenario = $this->checkAnswer();

        switch ($answerScenario) {
            case self::ANSWERED_PREVIOUSLY:
                return $this->answeredPreviouslyActivity();
            case self::ANSWERED_WRONGLY:
                return $this->wrongAnswerActivity();
            case self::ANSWERED_CORRECTLY:
                return $this->correctAnswerActivity();
            default:
                return "I don't know what to do";
        }
    }

    /**
     * Check Answer
     */
    protected function checkAnswer()
    {
        if (in_array($this->message, $this->gamer->game->answer ?? [])) {
            return self::ANSWERED_PREVIOUSLY;
        }
        if (in_array($this->message, 
        $this->gamer->game->question["missings"])) {
            return self::ANSWERED_CORRECTLY;
        }
        return self::ANSWERED_WRONGLY;
    }

    /**
     * Perfom if gamer answers correctly
     */
    protected function correctAnswerActivity()
    {
        $this->givePoints();
        
        return $this->successMessages
        [rand(0, count($this->successMessages) - 1)]
                . " You're on {$this->gamer->game->points} points" 
                . $this->dropQuestion();
    }

    /**
     * Perform if gamer has answers previously
     */
    protected function answeredPreviouslyActivity()
    {
        return $this->repeatQuestion();
    }

    /**
     * Generate next question
     */
    protected function dropQuestion()
    {
        if ($this->shouldMoveLevel()) {
            $this->saveGame();

            $level = $this->gamer->level + 1;
            return "*** Level {$level} ***" . "\n\n" .
            $this->call(PlayKeywordActor::class);
        }

        return $this->repeatQuestion();
    }

    /**
     * Checks if Questions Should move to another level
     * @return bool
     */
    protected function shouldMoveLevel()
    {
        return count($this->gamer->game->answer ?? []) 
        >= count($this->gamer->game->question["missings"]);
    }

    /**
     * Give points to gamer
     */
    protected function givePoints()
    {
        $game = $this->gamer->game;
        $answer = $game->answer ?? [];

        $game->points += self::POINTS;
        $answer[] = $this->message;
        $game->attempts = count($answer);
        $game->answer = $answer;
        $this->gamer->push();
    }

    /**
     * Perfom if gamer answers wrongly
     */
    protected function wrongAnswerActivity()
    {
        return $this->repeatQuestion();
    }

    /**
     * Repeat Question with already submitted answers
     */
    protected function repeatQuestion()
    {
        $question = $this->gamer->game->question;
        $words = $this->gamer->game->answer ?? [];
        $words = array_map("strtoupper", $words);

        $puzzle = $question["puzzle"];

        if (empty($words)) {
            $resolvedPuzzle = $puzzle;
        } else {
            $puzzleResolver = new PuzzleResolver;
            $resolvedPuzzle = $puzzleResolver->solve(
            0, count($words), $words, $puzzle);
        }
        
        $resolvedPuzzle = join("\n", $resolvedPuzzle);

        return "\n\n" . $this->printPuzzle(
            $resolvedPuzzle, $question["shuffled"]
        );
    }
}
App\Actors\GameActor.php
It looks like a lot of things are going on here, but its quite straightforward. 
In the shouldTalk method, we check if the gamer has a current game,
In the talk method, we check the correctness or wrongness of the response. If the gamer answered correctly, we will give points to the gamer, and return the remaining questions. If the gamer answered wrongly, we repeat the question to the gamer.
In the dropQuestion method, we can see that we made use of the call method, previously defined in our abstract Actor class to pass the action to the PlayKeyword actor.
WordGameController:
Lets put everything together by revisiting our WordGameController
public function __invoke(MessagingResponse $messageResponse)
{
    $actor = ActorFactory::make();
    $messageResponse->message($actor->talk());

    return response($messageResponse, 200)->header(
        'Content-Type', 'text/xml'
    );
}
App\Http\Controllers\WordGameCOntroller.php
Now we're ready to start playing our game. We'll use ngrok to quickly expose our application. Ngrok is a really cool open source tool that will allow us expose our local environment to the internet. It works by creating a secure tunnel on our local machine along with a public url. This is pretty useful in situations where you need to test a webhook, just like in our case.  If you don't have ngrok installed, you can visit the ngrok download page for instructions on how to set up.
Ngrok on terminal
Run the following command to tunnel our app using ngrok.
ngrok http 8000

Copy the forwarding url and go back to the Twilio WhatsApp sandbox. we shall paste the url in the callback field.
Using the Game Bot:
Add the Twilio sandbox number +1 415 523 8886 to your phone contact list. Open whatsapp and join the sandbox by sending join empty-toward (My sandbox code would be different from yours)
Congratulations! We now have a functional WhatsApp bot. 
Feel free to let me know what you think. I'm on twitter @gabrielnwogu
Link to repo: https://github.com/nwogu/word-game
Link to Demo: https://api.whatsapp.com/send?phone=14155238886&text=join empty-toward
*Thanks to Etinosa Obaseki for the edits



This agritech bullshit, or are we insane?
Gabriel Nwogu — Fri, 27 Dec 2019 07:06:59 GMT
*Writer Note:  A couple of years back, my good friend Samuel and I decided to run a startup in the Agritech space. It was brutal. We got into debt, chanced meetings with VCs, fights with customers and clients alike. At the height of that ridiculousness, I ranted about all of it as a way to comfort myself. This was that rant:
I sat down (Not entirely. I stood for the most part) across a panel of 4 investors, a couple of weeks back. My first attempt at pitching something endearing to some people's misunderstanding.

The conference room was 2 men short by the time I was done, a rather perturbing affirmation that I had once again failed to explain the concept of my startup's thesis to an enlightened few. 

I need to flesh this thing out, this startup thing, to explain my company's existence so often misinterpreted. 

Still, somewhere in my mind's eye, I'm perhaps doing this to affirm my own sanity, silence my continued rhetoric "are we just chasing the wind?" 

The idea for Farmoly did not entirely happen by chance. It was an evolution of accompanying ideas in the agricultural space. From the onset, Sam and I had always been enthusiasts of the industry. Having re'd agriculture at the university, Samuel was even more endeared to it. 

We noticed problems. Quite a lot of people in the space had noticed too, but only a handful were actually trying to solve. The market was an admirable mess across most crops.

Farmers never really earned their work's worth.

A crazy amount of wastage occurred on a daily, especially around perishables. 

An impressionable deficit in the availability of agro focused logistic providers across states.

Lack of real time data on pricing, farmers cultivating capacity, quantity of inputs etc.

A highly fragmented market causing a mismatch of demand and supplies.

Underutilized farmlands, making the expending of resources yeild low outputs.

Farmers disregard for quality standards ( Not on purpose, since most aren't even aware of modern and best practices), making most produce non-exportable.

A myriad of other unaccounted problems.

Was the billions of naira generated in transacted sales across the country, making stakeholders turn a blind eye towards developing effective solutions? 

Was this an effect of a lack of considerable processing companies?

Samuel had built a real connection with a cross section of farmers in Nassarawa where he served. He felt the pain points more closely and turning a blind eye to the various complexities was completely out of the table.

The initial concept of Farmoly revolved around disseminating information about best practices to rural farmers. We were able to run a pilot with 50 yam farmers in Nassarawa. We had convened a seminar-styled gathering, recruited a local who spoke the native tongue and ran a one week series on yam farming using the aeroponics system. We measured progess by testing the recollection of procedures by farmers. 

There's however a fine, thin line between social enterprise and charity. 

We build thesis around monetization models and how to scale leveraging technology, none of which seemed to make sense, at least at the time. Soon enough, the first version of Farmoly went with the wind, or more frankly, after Sam's clarion call, came to an end.

Various iterations of what we wanted to solve with Farmoly came and (some, at least) went: Notably amongst them was a plan to train/build/deploy 10,000 greenhouse farms and farmers for Tomatoes in 10 years (Sam had even drawn out a full blown business plan around this), another was a crowdfunding investment arm for farmers (There are so much of this springing up these days)

Farmoly right now, and for the foreseeable future, is trying really hard to solve the distribution problem. 

Consider these scenarios; 
Mr Alabi sells pineapples in Lekki. Whenever he runs out of stock, he has to leave his house as early as 5am to catch a ride to Ketu, the popular food market in Lagos. He buys the pineapples for three times the price it was sold when it left the farm. He has to wait for a vehicle who charges him almost 10% the cost of the produce, to drive him and his purchased goods back to lekki where he eventually has to sell at a much more higher price to offset his expenses.

Mrs Njoku runs a smothie bar, and gets supplied pineapples by a local dealer who buys off from Ketu, resells at almost twice the price. The quality of her smoothies differs each week, because different varieties of pineapples were supplied at different times. Her smoothies cost more, because she needs to  offset supply costs, and sometimes she doesn't make smoothies because her supplier who is dependent on Ketu, failed to supply produce, hence inconsistency.

At it's core, Farmoly is primarily being an aggregator. (Without diving into some Ben-Thomson-like analysis).  We Gather information from the supply end (farmers), onboard as much vendors and independent logistics personnel as possible and route demand as at when due to the appropriate channels. A cycle of match making across the value chain and perhaps at some point, with enough network effects, be able to control pricing in the entire market.

We don't think it is too much of a daunting task, trying to change (Notice my avoidance of the word: disrupt) the way food is distributed and sold. The problem however has been the users at both sides of the table. Agriculture has, for the most part, been a bottom of the pyramid play, an informal market driven by the not so educated. 

How do you change a procedure with technology when the focus of the process is not savvy in itself. Enlightenment? Doesn't it defeat the mantra of: "Startups move fast?" is software in Agriculture only a facade? Do existing solutions that claim to use tech (read eCommerce) to enable farm to market trade see adoption by rural farmers and consumers alike? 

The problems we face do not stop at uneducated end users. It goes down to infrastructure; logistics, payments and storage. It meant, building out our own logistics, payments for the unbanked/informal market and owning our storage. These things are necessary for Farmoly to work at scale and software alone is far from solving them.

Sam's father thinks his son has gone mad for not finding some cool conglomerate to work in. My father? Story for another day. This entrepreneurship thing should work? 

Perhaps we are mad afterall, descendants of the Mad King (My apologies, I couldn't avoid a Game of Thrones reference) We could have picked some other sexy AI, machine learning and virtual reality space to disrupt, but no, the real crime was passion.

Sam is going out tomorrow, from our boy's quarter which surprisingly doubles quite well as our office. Five more vendors want to buy from us and we have to supply, for margins' sake, with or without software.


A Robot Bartender's Guide To Laravel Form Requests
Gabriel Nwogu — Thu, 26 Dec 2019 21:54:41 GMT
Laravel is beautiful. Elegant, succinct and beautiful, but luckily this article is not about poetry, else I would have gone on about a man who fell in love with a framework.
A gentle introduction to life, without Form Requests, infact, life without Validators.
Let’s say we have a ProductController that handles specific actions related to a product and returns json.
get("price") < 0) {
            return response()->json([
            "status" => "error", "message" => 
            "Price cannot be greater than zero"], 406);
        }
        if (is_null($request->get("shop_id"))) {
            return response()->json([
            "status" => "error", "message" => 
            "shop_id is required"], 406);
        }
        if (is_null($request->get("name"))) {
            return response()->json([
            "status" => "error", "message" => "name is required"], 406);
        }
        $shop = Shop::find($request->get("shop_id"));
        if (null == $shop) {
            return response()->json([
            "status" => "error", "message" => 
            "shop_id does not exist"], 406);
        }
        
        /**
         * Actual action being performed here
         */
        $product = Product::create($request->all());
            return response()->json([
            "status" => "success", "data" => $product->toArray()], 200);
    }
}

From the above, we can see that validation takes up the bulk of logic for performing an action. Thankfully we can call the validator on the request object, so the multiple ifs could be refactored as below.
validate([
            "shop_id" => "required|exists:shops,id",
            "name" => "required|string",
            "price" => "required|numeric|gt:0"
        ]);
        
        $product = Product::create($request->validated());

        return response()->json([
            "status" => "success", "data" => $product->toArray()], 200);
    }

}

Validations often take up a bulk of the lines when writing business logic.
Imagine a bar, run by a robot. Each time you order a drink, the robot spends some minutes asking you for an ID to prove you’re of legal drinking age.
Form Requests provide a nice way of encapsulating requirements for processing a given resource, allowing your services do their actual jobs.

Form Requests are the bouncers you put at the entrance to the bar, with one simple instruction: “Don’t let anyone below 18 get in here”. Hence, the robot doesn’t need to know your age. It just serves the drink while the bouncers now have the actual task of checking IDs.
They extend the Illuminate\Foundation\Http\FormRequest class. 
To create a Form Request, run the artisan make request command, supplying the request name as an argument. In our instance: 
php artisan make:request ProductRequest
This will create a Requests Folder, if you don’t already have one, within your App\Http Folder.
Form Request Structure.

Form Request come with two methods already included:
authorize: You can use this to handle access permissions for the resource. This method should return a Boolean, indicating to grant access or not. By default, this returns false. Change this to true to grant access to the given resource, or you can also add custom permission checks within this method.
rules: This is where you define validation rules for the request. Your rules should return an array with the request field as a key and the validation rule as value. So in our case:
 "required|exists:shops,id",
            "name" => "required|string",
            "price" => "required|numeric|gt:0"
        ];
    }
}

Using Your Form Requests.

To use our newly created FormRequest, we just need to type hint our controller method and Laravel will automatically resolve it for us from the service container, by doing so, validating the request.
validated());

        return response()->json([
            "status" => "success", "data" => $product->toArray()], 200);
    }

}

Switching Validation Rules based on Request methods.
You can return different rules depending on the request method specified, by switching through each request, this allows you to be able to use the same request for multiple actions. Say we want to update a product, we don’t want to require that the client sends us the name or the price fields.
To achieve this we can switch through the request method:
method()) {
        case "POST":
            return [
                "shop_id" => "required|exists:shops",
                "name" => "required|string",
                "price" => "required|numeric|gt:0"
            ];
        case "PUT":
            return [
                "shop_id" => "exists:shops",
                "name" => "string|nullable",
                "price" => "numeric|gt:0"
            ];
    }
}

We can now use the ProductRequest when updating the product:
update($request->validated());

    return response()->json([
        "status" => "success", 
         "data" => $product->toArray()], 200);
}

Form Requests provide us with structure to organize requirements for our controller processes. As we can see, so far so good, I can’t think of any reason why you aren’t using Form Requests yet.


Lekki's Rental Conundrum
Gabriel Nwogu — Thu, 26 Dec 2019 21:24:57 GMT
The road to Aro is rough and much sandier than the last time I came only two days ago. If I were to properly explain the significant change in the level of sand, I would have said: The sands got fed up and decided to procreate.
“Cars can only pass here during the raining season,” Mr. Ajibade says matter-of-factly; he is here to guide me through Aro.
Aro's sand
“If any car goes through this road like this, the tyres will sink and these aboki boys—"He points to a group of youths wearing nothing but faded underwear and jeans soiled in grease, sitting across each side of the road. They are smoking what looks like wrapped cannabis—"they will come and help you carry your car, and you will pay them like ₦5,000.”
Ajibade’s description of the process sounded like something from a pitch deck: Car aid, on demand. Just another quick hustle on the streets of Lagos.
As we approach the town’s main entrance, I spot a market for second-hand goods. Ajibade responds to my silent enquiry. “We call it Kasuwa.”
“The things they sell here are now expensive. They were really cheap before,” he complains. “I bought almost everything in my house from this market. My rug, my fan, my wardrobe and even my bed.”
I watch as two men push locally fabricated wheelbarrows filled with wood, metal, and some other things. The town seems to be full of stories.
Three years ago, Aro was a fenced piece of land by the beach. It served as an alternative entrance to the now demised Lekki beach. Its exact capacity, wild speculation (My request to speak with the Baale—High Chief—of the town proved abortive).
“Aro is big! It’s a mighty population. I can say that more than 1500 people are staying here,” Ajibade exclaims.
How did an empty settlement grow to accommodate so many people in three years?
There may be jobs in Lagos, but are there houses?
My father arrived in Lagos in the early 70’s, looking—like others were—for a better life. The guiding ideology being: There is work in Lagos.
This ideology has spread over the years, drawing people from all over to Nigeria’s smallest state, and creating a housing crisis.
But not all of Lagos is created equal; opportunities are found in some places more than others.
In my father’s time, Ikeja the place to be. Hearing that someone stayed in Ikeja signalled a comfortable life. If you were coming to Lagos, you were heading to Ikeja. It was all that mattered.
Today, Lekki is the new Ikeja; a new enclave for the wealthy, spurred by high prices in real estate. A three bedroom in the area could go for ₦4,000,000 in annual rent. The same type of apartment could be found for less than ₦300,000 in Ogba or Ikorodu.
“I was paying ₦60,000 per year for a self-contained apartment in Agege, but in Lekki, if you don’t have up to ₦200,000 you can’t even rent a good room,” Ajibade chips in. He relocated to the island after he’d lost his job in Agege and got a similar role in Lekki with twice the pay.
“I was asked to pay ₦50,000 for agent and agreement plus two years upfront at ₦180k per year. Where do I want to see that kind of money? How much is my salary?” He laughs.
Ajibade isn’t the only one relocating. Many people flock to the island for promises of a good job, yet house rental prices continue to dissuade them. Is the disparity in rent on the island driven by demand or the sheer indulgence of the affluent?
Ajibade does not doubt that it is the latter. “If you look at most of the houses in gated estates, they are empty. Nobody is renting them, and they don’t want to bring the prices down.”
Although companies like Fibre and Muster are trying to solve housing problems through innovations like shared apartments and monthly rental payments, how far can these go in a state with over 15 million people?
Demolition day
Aro’s main entrance once had wooden gates, until the Lagos State Government attempted to demolish the settlement last year.
“Everybody in Aro was scared. A lot of people had no other place to go. Plenty people actually moved out,” Ajibade remembers.
Main entrance to the settlement
It was during the State Government’s rampage that the gates were put down. The community had thought the gates would dissuade the officials who came with bulldozers and uniformed men.
The bike men who rode through Aro’s route were scared. Aro wasn’t just a community to them, it is a means of livelihood. “People were crying that day. I heard someone call on Elijah; some people fainted,” Ajibade adds solemnly.
The bulldozers had arrived in Aro’s vicinity on a Saturday night. The officials had started their demolition in similar settlements on the island; Ikate was hit first, then Marwa. Properties were brought down with little time for their owners to recover valuables. Aro was to be the third.
Residents were forced out of Aro during the demolition
Ajibade looks at me intently as he recalls that frantic period. “I moved all my important belongings out of Aro about one week before they came. I kept them at a friend’s place, but a lot of my clothes were still in Aro.”
The demolition started on Sunday morning, from the market leading to the community. Everything was brought down and set ablaze. The officials claimed they gave a 6-month notice to the occupants of the town. The bulldozers moved with the uniformed officers as reinforcement, but something surprising happened. Something the hopeless inhabitants of Aro didn’t expect.
The salvation of the Baale
Aro is made up of wooden shanties, built in clusters around each other. The entire community is fenced and controlled by a council set up by the Baale.
A lot of Aro houses are made of wood
The wood making up the houses is wrapped in nylon thicker than polythene. The houses lack any form of waste disposal, and some houses are without a bathroom. The average occupant of the town works a blue-collar job, as a driver, laundry personal or a cleaner. There are also bankers, architects and other professionals who reside comfortably in the wooden ghetto
“We don’t pay rent here. When I first came to Aro, I bought my pako for ₦45,000. We don’t pay for any other thing, apart from ₦500 security levy and ₦1,000 NEPA money,” Ajibade asserts.
Ajibade uses the term pako to reference the wooden houses. The value of each house put up for sale is determined by two factors: its size and its proximity to the main entrance. There is never talk about rent; each occupant becomes a landlord to his pako.
“Every last Saturday we usually have environmental sanitation, and everybody is expected to participate, if not, they will be fined ₦500,” Ajibade says.
I run the numbers in my head. Given Aro’s estimated population, these little charges everyone coughs up each month would make for decent internally generated revenues. So, does the council have any long-term development plans for the community, I wonder.
“We have three schools inside Aro that the Baale built. We also have a lot of churches,” Ajibade responds. He thinks the Baale is trying.
Aro's dumpsite
When the Lagos State Government officials had their bulldozers bring down the wooden gate, they stopped and went back. “Someone said it was the Baale that came out to intervene. I don’t know, but what I know is that they left. All of them left with their bulldozers, without entering Aro.” Ajibade acclaims.
People jubilated. Mothers held their babies in one hand and danced with the other. Shops that were previously closed reopened that evening. The community was relaxed.
“Some people said they would come back, but it’s been over a year now and nothing,” he finishes.
“Are you comfortable in this place?” I ask Ajibade.
“For now, I’m not thinking of moving out. At least till I can afford Lekki’s rent. Let me be managing this place like that,” he replies, and for others like him, Aro is a saving grace; a chance to be closer to what feeds them.
Ajibade is a hopeful man. I follow him as he shows me more places within the town. A part of me wonders if he is indeed comfortable, if his heart isn’t in his mouth, waiting for the dreadful news of when the bulldozers come back.


Sorry
Gabriel Nwogu — Thu, 26 Dec 2019 21:19:11 GMT
he said sorry for him hurting

teeth shining,  

he said sorry and you gave in.

hugs fell after hug

but he had hurt first

made you cry first, 

cursed first.

he said sorry for him jesting

smirk faced in, 

i won't make fun of your dressing

kisses deepen after kissing, 

but he didn't jes' less, 

never felt awkward less, 

cared less.

he didn't say sorry for lying

you ask him why, crying

looked him in the face, 

waiting, 

he,  stalling, you pace.

great!

he never said sorry in the first place.