DEV Community: Muhamad Sulaiman

How I Smashed Image Compression in Laravel Using Node.js

Muhamad Sulaiman — Sun, 24 May 2026 12:32:07 +0000

Hey everyone! I’ve been learning more deeply about Node.js recently, and instead of studying it in isolation, I wanted to use it to solve a real problem inside the project that I've been working on.

One of the functions that I need to build is an image compression. But these functions are not developed 100% in Node.js; instead, they are inside my Laravel app.

One issue kept showing up: image uploads are huge, and processing them directly during a normal Laravel request quickly becomes expensive. So I tried a hybrid approach. Laravel for the application flow, and Node.js with Sharp for the heavy image work.

This setup ended up being one of the most practical architecture experiments I’ve done in a while.

The real problem

In many Laravel apps, users upload images straight from their phones or from Designers. Those files can easily be several megabytes each, and once you start resizing, converting, and compressing them, the request can become much heavier than it looks.

The first version of this problem is simple: the upload works, but the response gets slower. The second version is worse: if several users upload at the same time, the application starts spending too much time on image processing instead of serving the rest of the app.

That was the point where I stopped asking, “How do I make PHP do this?” and started asking, “What should Laravel do, and what should it delegate?”

While I'm studying Node.js, out of the blue, I'm thinking... "Why don't I pass the heavy work to compress the image by using Node.js?"

And I've made it. I create the logic and execute it.

Why I moved it to a queue

The biggest improvement was not Node.js alone. It was moving the image optimization work into a queued job.

Laravel queues are designed for time-intensive tasks, so the application can return a faster response while the heavy work continues in the background. In other words, the controller no longer needs to wait around doing expensive image work before responding to the user.

That changed the architecture completely:

Laravel handles validation, persistence, and job dispatching.
The queue handles background execution.
Node.js with Sharp handles image transformation.

That separation feels much more natural than trying to do everything inside one request.

Why Sharp

I chose Sharp because it is a high-speed Node.js image processing library that uses libvips under the hood, and it supports common web image formats like JPEG, PNG, WebP, GIF, and AVIF. Its installation guide also provides prebuilt binaries for many common platforms, which makes it practical to use in real deployments instead of feeling like a purely experimental tool.

For this use case, Sharp gave me exactly what I needed:

Resize oversized uploads.
Convert to WebP.
Lower storage usage.
Keep the worker focused on one job only.

The architecture

I now think about this flow in three layers:

Laravel controller receives the upload and stores the original file temporarily.
Laravel queue job gets dispatched for background processing.
Node.js script runs Sharp to resize and convert the image.

So Laravel still owns the application flow, but it no longer performs the expensive image manipulation inside the request itself. That is the part that made the solution feel production-friendly.

Why I kept Node.js isolated

I also kept the Node.js worker code inside its own scripts/ directory with its own package.json.

Could Sharp be installed at the Laravel root? Sometimes yes. But I preferred isolation because the root package.json usually belongs to frontend tooling such as Vite, Tailwind, Vue, or React, while this worker is backend-oriented and has a different responsibility.

Keeping the worker separate gave me three benefits:

Clearer ownership of dependencies.
Cleaner deployment steps.
Less mental overhead when maintaining the project later.

Instead of mixing everything together, the project now has a small, focused Node environment whose only job is image optimization.

Project structure

laravel-project/
├── app/Http/Controllers/ImageController.php
├── app/Jobs/OptimizeImageJob.php
├── scripts/
│   ├── optimize.js
│   ├── package.json
│   └── .gitignore
└── storage/app/public/optimized/

Controller flow

The controller became much simpler. Its job is no longer to optimize the file immediately. It only stores what is needed and dispatches the background job.

public function store(StoreImageRequest $request)
{
    $request->validated();

    $path = $request->file('image')->store('private/uploads');

    // You can extract this to services later.
    $image = Image::create([
        'folder' => 'senior-leadership',
        'original_path' => $path,
        'status' => 'queued',
    ]);

    OptimizeImageJob::dispatch($image, 'senior-leadership');

    return response()->json([
        'message' => 'Image uploaded successfully and queued for optimization.',
        'status' => 'queued',
    ], 202);
}

That felt much better architecturally. The request stays focused on application flow, and the expensive work happens later.

The queued job

This is where Laravel and Node.js meet.

Laravel jobs can run asynchronously through the queue system, and Laravel also supports passing serialized model data into jobs cleanly. That makes the job layer a natural place to hand the file over to an external worker process.

<?php

namespace App\Jobs;

use App\Models\Image;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Symfony\Component\Process\Process;

class OptimizeImageJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function __construct(
        public Image $image,
        public string $folder
    ) {}

    public function handle(): void
    {
        $inputPath = storage_path('app/' . $this->image->original_path);
        $outputFolder = storage_path('app/public/optimized/' . $this->folder);

        if (! is_dir($outputFolder)) {
            mkdir($outputFolder, 0755, true);
        }

        $process = new Process([
            'node',
            base_path('scripts/optimize.js'),
            $inputPath,
            $outputFolder,
        ]);

        $process->run();

        if (! $process->isSuccessful()) {
            $this->image->update([
                'status' => 'failed',
                'error_message' => $process->getErrorOutput() ?: $process->getOutput(),
            ]);

            throw new \RuntimeException('Image optimization failed.');
        }

        $result = json_decode($process->getOutput(), true);

        $this->image->update([
            'status' => 'optimized',
            'optimized_path' => 'optimized/' . $this->folder . '/' . $result['filename'],
        ]);
    }
}

I prefer this over doing the work directly in the controller because it is easier to retry, easier to monitor, and easier to scale later.

The Node.js worker

The Node.js side stays intentionally small.

const sharp = require('sharp');
const path = require('path');
const fs = require('fs');

const [,, inputPath, outputFolder] = process.argv;

async function compressImage() {
    try {
        const filename = path.basename(inputPath, path.extname(inputPath));
        const outputPath = path.join(outputFolder, `${filename}.webp`);

        await sharp(inputPath)
            .resize({ width: 1200, withoutEnlargement: true })
            .webp({ quality: 80 })
            .toFile(outputPath);

        if (fs.existsSync(outputPath)) {
            fs.unlinkSync(inputPath);
        }

        console.log(JSON.stringify({
            success: true,
            filename: `${filename}.webp`
        }));
    } catch (error) {
        console.error(JSON.stringify({
            success: false,
            error: error.message
        }));
        process.exit(1);
    }
}

compressImage();

I like this part because it does one thing only: optimize the image and return a machine-readable result.

What improved

After switching to this design, I got improvements in the areas that actually mattered:

Better request responsiveness because the optimization no longer runs during the normal HTTP request path.
Cleaner separation of concerns because Laravel owns app logic and the worker owns image processing.
Lower storage usage because the output is resized and converted to WebP.
Safer failure handling because a failed optimization becomes a job failure, not a broken user request.

Trade-offs

This approach is not free of trade-offs.

You are now maintaining two runtimes in one project: PHP and Node.js. You also need queue workers running properly in each environment, and Laravel supports multiple queue backends like database, Redis, and SQS, depending on how you want to operate the system.

So I would not use this pattern for every app. But for applications that deal with large uploads or frequent image processing, it feels like a very practical split.

Final thought

As someone still learning Node.js, this was a great reminder that learning sticks better when it solves a real problem.

Laravel remained the application brain. The queue became the handoff layer. Node.js with Sharp became the specialist worker.

And honestly, that combination felt much more scalable than forcing the whole workflow into a single request.

SDD is now my go-to when developing a Website / Software

Muhamad Sulaiman — Tue, 19 May 2026 14:33:19 +0000

Recently, I ran an experiment across several of the projects I’ve been building. The focus of that experiment was simple: how could I consistently get better results and higher-quality responses from the AI models I use, while also reducing the time it takes to arrive at a solid outcome?

Previously, my workflow leaned more toward Vibe Coding Prompting, or VCP. My usual approach was to build things first, then ask the AI to review what I might have overlooked, especially around caching strategy and SQL performance.

The problem, however, was that VCP often gave me responses that did not meet the standard I was aiming for. Hallucinations were quite common, and the issue became even more obvious when the context grew longer and more complex.
Because of that, I changed the way I use AI in my daily workflow. I moved from VCP toward SDD, or Spec-Driven Development. From my experience so far, SDD gives me significantly better responses than VCP.

That said, I have not abandoned VCP entirely. It is still useful when I want the AI agent to handle repetitive tasks for me, so I can stay focused on work that requires more attention and deeper thinking.

The first time I used SDD, I stuck with it almost immediately because it felt like working with a highly capable Project Manager. That said, SDD does take more time at the beginning. You need clear stakeholder requirements first. Then you need the AI to align properly with the spec before execution begins. This is different from VCP, where you can often jump straight into getting an output. The trade-off is that the output may not be as strong or as reliable as what SDD produces.

The slower start is normal. That has always been true in software development. Even before AI became part of our workflow, we still needed time to analyze requirements and think things through properly. The difference is that, over the long run, SDD has accelerated my workflow by more than 30%. The quality of the output is better, and the number of bugs is lower. As a result, I spend far less time debugging.

At the moment, this is how I work with AI. You may want to adopt parts of this workflow, or perhaps share your own with me. I am always open to learning from how others approach their process. For now, this is the workflow that works best for me:

I manually initialize all Laravel, Symfony, Nuxt, Next, or Express projects.
I set up the initial routes that I know the project will need.
I create the necessary SKILLS to ensure my AI agent can follow SDD, read related specs correctly, and understand my preferred code patterns.
Once those first three steps are in place, I create a specs/ folder, along with the relevant subfolders for the specs I want the AI to work on. For example, I recently needed a shell script for a data pipeline process, so I created specs/shell/.
Before asking the AI to generate the basic files for SDD, I write the readme.md for that spec myself. This document contains the full stakeholder requirements, including the WHY behind the spec.
I then run a prompt that instructs the AI to read and analyze that readme.md.
Based on its analysis, I ask the AI to raise any questions it may have before completing the development plan for that spec.
Once I answer those questions and it generates the development plan, I review that plan carefully, step by step. If anything feels off, I correct it manually until I am fully satisfied, and only then do I ask the AI to execute the plan.

I am not claiming that this is the best workflow. It is simply the workflow that fits the way I work today. I still think critically, and I still write code manually. What SDD gives me is a more structured path, fewer bugs, and a faster development cycle overall. That also allows me to spend more time on the things that matter most, such as design patterns, architecture, and other higher-level engineering decisions.

Beyond CRUD: The Developer’s Ascent – A Story of Growth

Muhamad Sulaiman — Sun, 23 Nov 2025 04:17:00 +0000

Based on my personal experience. But blend with a Journalist-like story to make it more interesting.

Kuala Lumpur — It’s a scene familiar to many in the tech world: a young developer, lit by the glow of a laptop screen, celebrates the launch of their first simple web application. But for seasoned software engineer Ahmad (not his real name), that moment was just the first step of a decade-long journey climbing from novice coder to technical architect—a journey marked less by the mastery of CRUD (Create, Read, Update, Delete) and more by a relentless pursuit of growth and complexity.

“I still remember the first time my own app let someone add and delete a note,” Ahmad recalls. “It felt like magic. CRUD opened the gate to programming for me. But I eventually realized it’s really just basic survival.”

For years, CRUD skills sufficed. Ahmad bounced between languages—PHP, JavaScript, Go—building countless forms and tables, spinning up databases, and deploying apps that managed users and lists. The early victories, however, gave way to a sense of monotony. “It’s easy to fall into the loop,” he says. “Every project starts to look the same. You wonder, is this all I’m going to do?”

Industry veterans say that realization marks an important inflection point—the plateau that separates junior developers from their more senior peers. “Moving past CRUD is not about abandoning the basics,” says Maya, Ahmad’s former mentor and team lead. “It’s about asking bigger questions: How does this system work for the business? What happens if traffic doubles? If a bug wipes out the database, are we ready?”

For Ahmad, the turning point came when his team was tasked with integrating real-time payments and automated reporting into their platform. CRUD apps, he discovered, could not answer questions about reliability, scalability, error recovery, or business impact. “Suddenly, I had to think like an architect, not a form designer,” he tells us. “From database indexing to API reliability, every decision mattered.”

The role of a Senior Developer, Ahmad explains, is less about coding individual features and more about designing systems and processes. He describes late nights debugging production issues, painstaking data modeling, and the challenge of translating technical risks to cross-department stakeholders. “You don’t just write the code. You explain why, negotiate trade-offs, and make sure the solution actually solves a real-world problem.”

Beyond the technical, communication skills emerge as critical. “The bigger the system, the more people involved,” Ahmad notes. “You need to speak business, not just code. Convincing marketing or ops to invest in better logging or infrastructure—that's what really moves projects forward.”

This ethos of perpetual learning runs deep. Technologies like Laravel Collections, he says, seem straightforward—until new custom methods reinvent familiar workflows. Ahmad regularly returns to old documentation, finding surprises in the details. “Even when it’s a repeat topic, there’s always something new,” he reflects. “The best engineers constantly re-learn and re-invest in their fundamentals.”

Experts echo this view. “In the real world, seniors spend as much time mentoring, designing, and testing as they do coding,” Maya explains. “The real ascent is about growing as a leader and problem-solver, not just a programmer.”

Today, Ahmad mentors teams across departments, reviews code, drafts architectural diagrams, and steers projects from conception to completion. “I see junior devs excited about CRUD. I tell them it’s a great start. But don’t stop there—your road is far longer and richer.”

As the tech world races forward, Ahmad’s story serves as both blueprint and inspiration—a testament to the climb from CRUD to creativity, from novice to senior, and from solitary coder to collaborative leader.

“CRUD is the start of the story,” Ahmad concludes, “but the most exciting chapters come after.”

Understanding Polymorphism vs. Polymorphic in Programming

Muhamad Sulaiman — Fri, 07 Feb 2025 07:04:12 +0000

Introduction

If you've ever dived into Object-Oriented Programming (OOP) or worked with an ORM like Laravel's Eloquent, you've likely come across the terms Polymorphism and Polymorphic Relationship (will use Polymorphic after this). While they sound similar, they refer to two distinct concepts.

Many developers, especially those new to these concepts, often confuse them. In this post, I'll break down what each term means, how they are used, and why understanding the difference is crucial for writing clean and efficient code.

What is Polymorphism?

Polymorphism is a fundamental concept in Object-Oriented Programming (OOP) that allows objects of different classes to be treated as objects of a common superclass. It enables a single interface to be used with different underlying data types, improving code reusability and flexibility.

There are two primary types of polymorphism. Method Overriding and Method Overloading. For the sake of the PHP and this sharing, we focus on the first type only.

Example of Polymorphism in PHP (Method Overriding)

Let's take a real-world example. Assume we have a User system where different types of users (Admin, Customer) have different access levels.

/**
* Main (or Parents) Class
*/
class User {
    public function getRole() {
        return "General User";
    }
}

/**
* Child Class
*/
class Admin extends User {
    public function getRole() {
        return "Administrator - Full Access";
    }
}

/**
* Child Class
*/
class Customer extends User {
    public function getRole() {
        return "Customer - Limited Access";
    }
}

/**
* Instantiate the Class - Object
*/
$users = [new Admin(), new Customer(), new User()];

foreach ($users as $user) {
    echo $user->getRole() . PHP_EOL;
}

Output

Administrator - Full Access
Customer - Limited Access
General User

Here, even though we are calling getRole() on different objects, they return different results based on their respective class implementations. This is the power of polymorphism.

Ok now, I hope you understand about polymorphism. Let's go to other terms, polymorphic.

What is a Polymorphic?

A Polymorphic is a database design pattern used in Object-Relational Mapping (ORM) systems like Laravel's Eloquent. It allows a single model to be associated with multiple other models without needing multiple foreign keys.

For example, let's say we have an Image model that can be associated with both a Post and a User.

Instead of creating separate post_id and user_id columns in the images table, we use a polymorphic relationship with imageable_id and imageable_type columns.

Example of Polymorphic Relationship in Laravel

In your migration file :

Schema::create('images', function (Blueprint $table) {
    $table->id();
    $table->string('url');
    $table->morphs('imageable');
    $table->timestamps();
});

In your Model :

/**
* Image Class
*/
class Image extends Model {
    public function imageable() {
        return $this->morphTo();
    }
}

/**
* Post Class
*/
class Post extends Model {
    public function images() {
        return $this->morphMany(Image::class, 'imageable');
    }
}

/**
* User Class
*/
class User extends Model {
    public function images() {
        return $this->morphMany(Image::class, 'imageable');
    }
}

With this codes, you can do like this when Data Creation :

$post = Post::find(1);
$post->images()->create(['url' => 'post_image.jpg']);

$user = User::find(1);
$user->images()->create(['url' => 'profile_picture.jpg']);

Now, both Post and User models can have associated images without needing separate foreign keys.

Polymorphic Relationships Exist Beyond Laravel

Although Laravel has made Polymorphic relationships popular in the PHP ecosystem, this concept exists in other frameworks and ORMs such as:

Django (Python) – Uses Generic Foreign Key
Hibernate (Java) – Uses Single Table Inheritance or Join Table Inheritance

Conclusion

Both Polymorphism and Polymorphic are crucial concepts, but they serve different purposes:

Polymorphism is an OOP concept that allows multiple classes to share the same interface and behave differently based on their implementation.
Polymorphic usually referred as Polymorphic Relationship are a database ORM feature that allows a single model to relate to multiple other models dynamically.

To visualize the difference

Polymorphism is like having different types of users (Admin, Customer, Guest) who inherit from a common User class but override methods to behave differently.
Polymorphic are like an Image table where a single image can belong to either a Post, a User, or even a Product, without needing multiple foreign keys.

Understanding the difference between these two concepts helps you write cleaner, more maintainable, and scalable code. Whether you’re designing an object-oriented system or a database schema, knowing when and how to use polymorphism can make a huge difference in your project's architecture.

Even there's some Cons. But I don't want to explain it here. Now, it's your job to find the Cons ;)

I'm sure you have implemented the polymorphism in your Laravel project. But Have you used polymorphic relationships in your projects? Let me know in the comments below! 🚀

Understanding Laravel Queues: queue:work vs queue:listen and Why queue:restart Matters

Muhamad Sulaiman — Sat, 01 Feb 2025 13:51:09 +0000

Recently, I released a Laravel package called EasyDeploy, and someone asked me why I included php artisan queue:restart instead of just using php artisan queue:work or php artisan queue:listen.

This question made me realize that many developers aren't fully aware of how Laravel's queue system works, especially when using Supervisor. So in this post, let's break it down step by step.

By the way, I will shorten the command to like queue:work. I hope you can understand that it's mean php artisan queue:work

🚀 `queue:work` vs `queue:listen`

Before we talk about queue:restart, let's first understand the difference between queue:work and queue:listen.

🛠 php artisan queue:work

Runs a queue worker once and then exits.
Since Laravel now runs queue:work in daemon mode by default, you can simply use:

php artisan queue:work

Because of queue:work runs in daemon mode by default, the worker stays running without restarting Laravel for every job, making it faster and more efficient for production.

🎧 php artisan queue:listen

Listens for new jobs continuously.
Restarts Laravel for every job, which ensures fresh code but makes it slower than queue:work.
Good for development, but not recommended for production due to performance overhead.

✅ Which One to Use?

Use queue:work in production for better performance since it already runs in daemon mode by default.

Use queue:listen in development when you want changes to be reflected immediately without restarting the worker.

🔄 Why queue:restart Is Necessary

Now that we understand the difference, let's talk about queue:restart.

Even if you're using queue:work, the worker keeps running indefinitely. This means:

If you deploy new code, the worker still runs old code because it never restarted.
If you update a model, job, or database structure, the queue worker won’t pick up the changes. Because the worker does not automatically reload the application state.

To solve this, Laravel provides:

php artisan queue:restart

This command signals all workers to gracefully exit after finishing their current job, allowing them to be restarted and reload the updated code.

🤖 How Supervisor Fits In

Many Laravel developers use Supervisor to keep queue workers running.

Supervisor auto-restarts workers if they crash, ensuring that queue jobs are always processed.
However, Supervisor does not restart workers when you deploy new code.
This is why queue:restart is important: it tells existing workers to stop so that Supervisor can restart them with the latest code.

📌 Without queue:restart, your queue workers might continue using old code after deployment.

🔥 Best Practices for Laravel Queues in Production

When deploying updates, always do:

php artisan migrate --force
php artisan queue:restart

This ensures that:

✅ Database migrations apply correctly.

✅ Queue workers reload the latest code.

✅ No jobs get stuck due to outdated logic.

This command is included in my package. I'm using this for years

🎯 Final Thoughts

Understanding how Laravel queues work is crucial for building reliable and scalable applications. If you're using Supervisor, make sure to include queue:restart in your deployment workflow to prevent workers from running outdated code.

I hope this post clarifies the difference between queue:work, queue:listen, and why queue:restart is necessary.

If you're interested in automating your Laravel deployments, check out EasyDeploy!

Have any questions? Let's discuss in the comments! 🚀

My Journey from BootstrapCSS to TailwindCSS: A Backend Developer’s Perspective

Muhamad Sulaiman — Thu, 03 Oct 2024 01:44:59 +0000

As a backend developer, my journey in the world of web development has been filled with learning and adapting to new technologies. Recently, I made the switch from BootstrapCSS (Bootstrap) to TailwindCSS (Tailwind), and I’d like to share my experience along with a comparison of both frameworks.
⁣
⁣

Discovering Tailwind: From Skepticism to Adoption

I first came across Tailwind through the front-end community. I’ve been following Adam Wathan, the founder of Tailwind, since he published his course about Laravel. However, at the time, I was more into Bootstrap because, as a backend developer, front-end styling wasn’t my priority.
⁣
⁣
But as time went on, I had to evolve into a Full Stack Developer. When working with frameworks like Laravel and WordPress, companies expect you to handle both backend and frontend. This shift pushed me to rethink my approach to front-end development, and eventually, my frustrations with Bootstrap led me to explore Tailwind.
⁣
⁣
Before Tailwind, I even tried Bulma, but the community wasn't as active or supportive compared to Tailwind and Bootstrap.
⁣
⁣
What made Tailwind even more appealing was how I could avoid writing separate CSS files. With Tailwind’s utility-first approach, I could apply styles directly within the Blade or PHP files, similar to inline styling but with more power and time efficiency. It saved me the hassle of going back and forth between CSS and HTML, making development much smoother.
⁣
⁣

Performance and Flexibility: Why Tailwind Wins for Me

When it comes to performance, Tailwind edges out Bootstrap, especially with its JIT (Just-in-Time) compilation and tree-shaking mechanism. With Bootstrap, you often end up loading a ton of unused CSS classes, which can bloat the file size. Tailwind, on the other hand, compiles only the classes I use. This results in a leaner, more efficient CSS file, directly improving page load times and overall performance.
⁣
⁣
As for flexibility, Tailwind offers way more freedom than Bootstrap. In Bootstrap, while there’s customization available through SCSS or LESS, it often feels like an extra step. Tailwind, however, gives you customization directly through utility classes. Need a specific width? No problem—use w-[200px] or w-[50em]. Want a custom background with transparency? bg-pink-500/20 gets the job done.
⁣
⁣
This design freedom makes Tailwind powerful, allowing me to create exactly what I envision without writing custom CSS files or relying on pre-designed components.
⁣
⁣

Adjusting to Tailwind: A Learning Curve

One of the key reasons my development slowed down when switching to Tailwind was the shift in approach. With Bootstrap, a lot of the heavy lifting is done for you. Bootstrap comes packed with pre-built components like btn, nav, container, and more. It’s quick and easy to implement, often requiring just a few classes to achieve a fully functional and styled element.
⁣
⁣
On the other hand, Tailwind takes a more utility-first approach. Instead of pre-built components, you’re in control of each aspect of the design. For example, creating a simple button in Bootstrap is as quick as writing btn btn-primary. In Tailwind, you need to manually define each property like rounded-md p-4 text-white bg-blue-500 hover:bg-blue-300. This gives you more design flexibility but also increases the amount of code you write.
⁣
⁣
This learning curve and extra level of detail in styling make Tailwind slower at first. You’re responsible for crafting each component from scratch, which takes more time compared to using Bootstrap’s ready-to-use components. However, once you get the hang of Tailwind, the payoff in terms of performance, customization, and design freedom becomes clear.
⁣

Challenges and Lessons Learned: Transitioning to Tailwind

Switching to Tailwind wasn’t without its challenges. As someone who initially focused on backend development, adjusting to a utility-first CSS framework like Tailwind required a shift in mindset. Unlike Bootstrap, which offers pre-built components and a structured approach to UI design, Tailwind forces you to build everything from the ground up.
⁣
⁣
The challenge was in balancing flexibility with the learning curve. Initially, it felt like I was spending more time manually writing classes for every design element, which slowed down my development process. There was also a period where I struggled to remember Tailwind’s utility classes, making it harder to develop quickly compared to Bootstrap’s familiar component classes.
⁣

However, the key lesson I learned was patience. Once I got over the initial learning curve, Tailwind became second nature. I realized that while the upfront effort is higher, the long-term gains in flexibility and performance were worth it. The framework’s approach to responsive design, customization, and optimization pays off in larger projects, especially when performance is critical.
⁣
⁣
Advice for Developers Transitioning to Tailwind
For front-end developers, Tailwind will feel like home. The utility-first approach gives you granular control over every aspect of the design, allowing you to build responsive and high-performance websites with ease. If you enjoy customizing layouts and fine-tuning the look of your site, Tailwind is perfect for you.
⁣
⁣
For back-end developers, my advice is to start with Bootstrap. Learn and get comfortable with CSS concepts first. Bootstrap’s structured component system will help you ease into front-end development. Once you’re comfortable with the basics of CSS, consider moving to Tailwind to unlock its full potential for performance and design flexibility.
⁣
⁣
If you want to go faster, consider asking your designer to create the mockups first. This way, you’ll have a clear visual guide on how to bring your designs to life using Tailwind.
⁣
⁣
In modern website design, performance is just as important as UI. Don’t overlook this aspect. Tailwind’s JIT compilation and efficient CSS bundle make it a great option for developers who prioritize speed and user experience. It’s important to balance aesthetics with functionality, ensuring that your websites not only look good but perform well too.
⁣

Embracing Agile, Scrum, and Kanban in Project Management: A Personal Journey

Muhamad Sulaiman — Mon, 30 Sep 2024 12:51:32 +0000

Managing projects in a software house can be both rewarding and challenging. One of the biggest challenges I faced was shifting from the traditional Waterfall model to a more flexible approach using Agile, Scrum, and Kanban. My team and I were tasked with building a social media platform for book lovers—a project that required close collaboration, timely iterations, and a clear workflow. This is a reflection of how we managed the process, the obstacles we faced, and the lessons learned.

The Waterfall Challenge

Before this project, we had always used the Waterfall methodology. In a software house, this felt like the natural choice. Waterfall gives you that sense of control, where every stage of the project is neatly planned and executed in sequence: requirements, design, development, and testing. But this approach often led to rigid timelines and miscommunication. If a change was needed during development, going back to earlier stages was cumbersome, resulting in delays and frustrations.

For this project, we realized that the Waterfall approach wouldn't allow us to be flexible enough to meet evolving requirements, especially for a dynamic platform like a social media network. This realization led us to embrace Agile, combining Scrum and Kanban to create a hybrid approach tailored to our needs.

The Shift to Agile-Scrum-Kanban: A New Way of Thinking

Transitioning to Agile wasn't as smooth as we initially hoped. Although we had the right tools—Scrum for organizing sprints and Kanban for managing tasks—the team struggled with one significant challenge: shaking off the habits formed from years of Waterfall projects. Developers found themselves waiting for the design to be finalized before starting, and the workflow often felt like we were reverting to the Waterfall model.

Adapting to Challenges

While we haven’t fully found the perfect solution, one of the approaches we are considering is to embrace cross-functional teams. Having designers, developers, and even stakeholders work together from the very start of the sprint could help reduce delays caused by waiting on one another. In our current approach, we had scenarios where the back-end developer would start working on the business logic, the designer would begin creating high-fidelity designs in Figma based on wireframes, and the front-end developer would start creating the front-end skeleton.

Although it felt like we were following an Agile approach, this setup often mirrored the Waterfall process, where one team member had to wait for another to complete their work. For example, the front-end developer would wait for the final design to be implemented, resulting in unnecessary delays. This sequential dependency made it challenging to move at the speed of Agile promises.

To counter this, we’re working towards more parallel processing within sprints. Breaking tasks into smaller, independent chunks that don’t rely on sequential completion would allow developers and designers to work simultaneously. This shift would significantly reduce bottlenecks and make our sprints smoother.

Additionally, we’ve started focusing on more robust sprint reviews and retrospectives to highlight these bottlenecks in real-time, enabling us to quickly adapt and evolve our workflow. In the future, shorter iterations and more real-time feedback are essential to prevent falling back into Waterfall-like habits.

The Outcome: A Successful Sprint

Despite the challenges, the outcome of the project was extremely positive. By using the Agile-Scrum-Kanban mix, we were able to build the necessary features without any major conflicts during the sprints. The key to this success was the clear communication and alignment we had during the backlog discussions. Everyone knew exactly what needed to be done and what the priorities were, allowing us to complete each sprint without confusion or scope creep.

The platform for book lovers came together smoothly, with each function being developed and tested in clear iterations. We were able to deliver value consistently, meeting the expectations of both the stakeholders and the end-users.

Final Thoughts

Switching from Waterfall to a hybrid Agile approach wasn’t easy, but it was a necessary step for us to evolve as a team. While we’re still fine-tuning our process, the Agile-Scrum-Kanban framework has proven to be more flexible and efficient for our projects. If you’re considering making the switch, my advice is to involve your whole team from the start, allow for flexibility, and don’t be afraid to iterate on your process just like you do on your product.

A Story From WordPress to Leadership: A Software Engineer's Journey

Muhamad Sulaiman — Sat, 20 Jul 2024 14:24:03 +0000

In the dynamic world of software development, career paths often take unexpected turns. This is the story of a passionate programmer whose journey led him from specialized web development to a leadership role, and ultimately back to his coding roots—albeit in a different company and with newfound wisdom.

The Early Days: Mastering WordPress

Our story begins with a dedicated WordPress developer, crafting digital experiences with a blend of creativity and technical skill. Each day brought new challenges in theme development, plugin customization, and creating responsive designs. The world of content management systems was his playground, and he excelled in it.

Broadening Horizons: The Software Engineer.

Recognizing his potential, the company soon promoted him to the role of Software Engineer. This transition marked a significant step in his career, broadening his horizons beyond WordPress to tackle a diverse array of general software development tasks.

The excitement of exploring different technologies and solving varied challenges fueled his passion for coding. From backend systems to front-end frameworks, our protagonist immersed himself in the vast ocean of software development, continuously learning and growing.

The Unexpected Promotion: Lead Developer

Just as he was hitting his stride in this new role, another opportunity presented itself. The company offered him a promotion to Lead Developer—a position that promised not only a substantial salary increase but also the chance to shape the direction of projects and mentor junior team members.

Initially hesitant, our developer was swayed by the company's predicament. There was no one else to fill the crucial role of overseeing developer workflows and managing projects. With a mix of trepidation and a sense of duty, he accepted the position, believing he could balance his passion for programming with his new responsibilities.

The Reality of Leadership

What followed was a stark awakening to the realities of leadership in the tech industry. The once-comfortable world of coding gave way to a landscape dominated by meetings, stakeholder management, and business strategy. Our lead developer found himself spending a mere 20% of his time on actual coding—and even that was primarily for research purposes rather than project work.

The daily routine became a source of emotional turmoil. Sitting with his team, listening to discussions about cutting-edge technologies and the rhythmic clicking of keyboards, stirred a profound sense of longing. Each line of code typed by his team members felt like a reminder of the path he had reluctantly left behind.

The Struggle for Balance

Concerned about his growing dissatisfaction, our protagonist approached senior management, hoping for a solution. However, the response was disheartening. The company lacked qualified internal candidates to take over the lead developer role, leaving him firmly entrenched in his new position.

As the months turned into years, our lead developer gained valuable insights into the business side of software development. He broadened his perspective and acquired new skills. Yet, these professional gains came at a significant personal cost. The joy he once found in programming had dimmed, replaced by the constant pressure of managerial responsibilities.

The Decision to Move On

After two years in the lead developer role, our protagonist realized that his true passion lay in hands-on coding. The experience had been invaluable, providing insights into project management, team dynamics, and business operations. However, it had also made clear that his career goals were firmly rooted in technical excellence rather than people management.

With a heavy heart but a clear vision for his future, he decided it was time to move on. He was grateful for the trust the company had placed in him and the opportunities they had provided. Their support played a crucial role in his professional growth, offering lessons and experiences that would continue to influence his career.

A New Chapter: Return to Coding

Armed with a wealth of experience and a renewed sense of purpose, our protagonist embarked on a job search. He faced challenges along the way, discovering that his extended time away from hands-on coding had dulled some of his technical skills. Several companies were hesitant to hire an external lead developer, preferring to promote from within.

However, persistence paid off. He found a new role as a Senior Full-Stack Engineer at a different company. In this position, he made it clear from the outset that he wanted to focus on technical work, avoiding management responsibilities except for mentoring junior developers through code reviews.

Lessons Learned

This journey, though challenging, yielded valuable insights:

Leadership roles, while prestigious, demand a genuine interest in management and business strategy. It's crucial to align career moves with personal passions and long-term goals.
The title and compensation of a lead developer may be alluring, but they come with significant responsibilities that can fundamentally alter one's day-to-day work and career trajectory.
Maintaining technical skills is crucial, even in management roles, to keep career options open.
It's essential to regularly reassess career goals and have the courage to make changes when necessary.

Conclusion

Today, our protagonist has found his way back to his true calling. As a Senior Full-Stack Engineer in his new company, he's rediscovered the joy of solving complex technical problems and staying at the forefront of software development.

His experience serves as a poignant reminder of the importance of self-awareness in career planning. It underscores the value of aligning professional roles with personal passions and the courage to course-correct when necessary.

For those standing at similar career crossroads, remember: the most fulfilling path is often the one that resonates with your core interests and allows you to leverage your strongest skills. In the dynamic world of software development, there's always room for growth—but it should be growth on your own terms.

Create a re-useable Mailing Code in Laravel

Muhamad Sulaiman — Sat, 06 Apr 2024 17:54:28 +0000

Hi there! In today's posting, I would like to share with you guys how to create a Laravel Mailing reusable code.

What I mean here is not the php artisan make:mail. But the Mail::to Syntax.

I'm building one mechanism in my application to send the reminder email to all of our targeted users. There are two ways to send to them. One is done manually (by clicking a button and then sending the email), second is done automatically (by using Laravel Scheduler)

The problem I faced was a lot of Mail::to syntax logic that I needed to code. The full code is like this,

Mail::to($user->email)
->send(new SendFirstReminder($user->name, $user->email));

It took me nearly 20 seconds to code it (I'm a slow typer)!

And there are a few places where I need to put the code. Such as Controller, and Console.

That's when I started to think. what if I need to use that mail code again?

So I need to spend another 20 seconds again? Of course, I don't want to do that again.

So what happened is, that I created a custom Services Class. I named it as EmailReminder. In this class where I gather all the reminder emails. Everything is in one place.

Then I use the static method to make it more readable.

As you can see in this image, after I created the EmailReminder services, I can call it wherever I want without spending 20 seconds to code it. It can be reused in all places.

I just need to call it statically and then it will work like usual. But it is shortened and more readable (at least from my point of view)

Later I will create another post on how I created a reusable Local Scope logic for my application.

If you have other suggestions, comment below. I'd love to hear about your code strategy.

Inverse of hasManyThrough Laravel

Muhamad Sulaiman — Wed, 01 Feb 2023 07:26:38 +0000

Currently, I'm developing a Learning Management System called Kelas Design. And today my task is to count how many Episodes do the Series have and vice-versa.

So I do the logic using Laravel Built-in Eloquent : Has Many Though. What's my logic look like is :

So I will get the Episodes data through Section. That's fine. But how about getting the Episode and which Series it's belongs to?

I realized that, in Laravel documentation, there's no instruction about Inverse of Has Many Through or Has One Through.

And since they don't provide that instruction, so I do need to create it manually. Usually if I faced a situation like this, I always reverse engineer the logic.

For example, Laravel has the built-in function such as Has Many Through & Has One Through.

So what I do is in Episode Model, I create method and returning Has One Through. If you're thinking about using belongsTo, you are wrong.

And this is my logic :

By default, you can just passed two (2) arguements if you are following Laravel convention. But in my case, If you just passed the two arguements, it will print an Error. Which the system cannot find the column you wanted.

With the extra arguements, you can search more depth. The third arguement is called $first_key and the fourth is $second_key.

Adding this, will allow the system to search more deep in your Database. And Eventually, will return you a data that you need. The third and fourth arguements is not nessasary an 'id'. It can be something else.

That's all, I hope my solution also can solve your situation like me also. If you have a better approach to do the inverse, please do comment below :)

PS : I've stumble upon one package name staudenmeir/belongs-to-through. Tested it and based on what I read at the files, this package also will solve my problem. However, I do not seek something overkill like this. Look at my solution, compared to this package. Even though the syntax is much cleaner, but I still need to download the package that have many files. And that I do not want to.

By the time I wrote this blog, this package has issue. Please refer to Github Issue

[BM] Bagaimana untuk menikmati kenaikkan gaji bagi seorang Web Developer

Muhamad Sulaiman — Sun, 22 Jan 2023 06:03:57 +0000

Assalamualaikum dan Hai semua. Seperti yang saya janjikan pada posting di Facebook, saya akan kongsikan kepada kalian bagaimana saya 'Hack' diri sendiri untuk mendapatkan kenaikan gaji setiap tahun bersama 3 syarikat yang saya bekerja.

Anda boleh rujuk posting saya disini : Facebook Sulaiman

Penafian : Hasil (Result) mungkin berbeza. Kena faham sangat konsep REZEKI. Ini adalah ikhtiar sahaja. Yang menentukan segala-galanya adalah yang maha Esa.

Berbalik pada tajuk yang dikarang, bagaimana anda boleh menerima kenaikkan gaji setiap tahun sebagai seorang Web Developer.

Web Developer yang dimaksudkan dalam posting ini termasuklah App Developer, Software Engineer, Data Scientist, dan yang melibatkan Coding.

Apa yang saya kongsikan ini adalah semata-mata berdasarkan pengalaman saya. Dengan tips ini, saya menerima kenaikkan gaji dari 2 syarikat dan 1 syarikat lagi saya tak naik gaji tetapi mendapat skop kerja yang lebih terperinci.

2 syarikat yang saya menerima kenaikkan gaji ini pula, syarikat pertama saya menerima kenaikkan 12%. Manakala syarikat kedua saya menerima dua kali kenaikkan gaji dengan kadar 28% dan 43%.

Kenapa anda perlu buat perkara ini?

Pertama adalah kerana Manager, Higher management syarikat anda tidak tahu apa yang anda inginkan dalam kerjaya. Terkadang apa yang anda buat pun mereka tak ingat.

Yang mereka ingat adalah anda boleh buat atau tidak. Itu saja.

Dan kita sebagai pekerja, tidak boleh salahkan mereka kerana mereka sudah ada banyak tugasan mereka sendiri.

Kedua, anda bertanggungjawab sepenuhnya tentang kerjaya anda. Bukan orang lain.

Ketiga, syarikat perlukan sebab-musabab kenapa perlu menaikkan gaji anda. Jadi anda perlu tunjukkan Value (nilai) yang ada pada diri anda.

Apa yang anda perlu laksanakan untuk membolehkan anda menerima kenaikkan gaji?

Pertama. Matlamat

Anda perlu tetapkan matlamat yang jelas dalam hala tuju kerjaya anda. Anda kena jelas apa yang anda nak capai. Jika anda nak jadi CTO atau gaji RM100K / bulan, bila anda nak perkara tu terjadi?

Kemudian, anda pecahkan kepada perkara yang kecil apa yang anda perlu buat demi mencapai matlamat yang utama itu tadi.

Sebagai contoh, saya mahu menjadi seorang CTO (Chief Technology Officer) dengan gaji sebanyak RM30K sebulan pada tahun 2030. Untuk menjadi seorang CTO, saya mesti kena faham perkara yang berkait dengan Teknologi. Jadi setiap tahun, saya kena fokus apa yang saya nak belajar, faham dan amalkan.

Sekarang saya berada di tahun 2023, jadi pada tahun ini apa yang saya perlu lakukan. Tahun hadapan apa? 2 tahun hadapan? Dan seterusnya.

Untuk memudahkan anda menentukan matlamat ni, anda boleh Google apa itu Vision Board.

Kedua. Bertindak.

Perbezaan antara orang yang gagal dan orang yang berjaya adalah, orang berjaya dia bertindak selepas dia buat perancangan.

Jadi anda perlu bertindak selepas anda melaksanakan Langkah pertama. Anda tahu untuk menjadi seorang Senior Front-end Developer, anda wajib untuk tahu salah satu Libraries/Frameworks JS diluar sana. Maka anda terus bertindak dengan belajar atau buat projek yang akan mendekatkan diri anda dekat matlamat yang hendak dicapai.

** Projek disini boleh jadi projek bersama syarikat atau projek tepi. Jika saya, saya akan buat projeck tepi yang ada kaitan dengan syarikat. Pada langkah ke-empat saya akan perincikan.

Langkah ini wajib selaras dengan langkah pertama. Kena align.

Ketiga. Track & Record

Selepas anda bersungguh-sungguh untuk laksanakan langkah kedua, anda wajib Track & Record supaya anda tahu anda tidak lari dari landasan yang anda telah bina.

Gunakan platform yang boleh anda track & record. Contohnya saya ingin menjadi seorang WordPress Specialist. Jadi saya perlu mahir dalam JavaScript, PHP & SQL (Kerana dengan tiga ini, saya boleh buat pelbagai perkara dengan WordPress).

Jadi saya track & record segala Customization, Plugins, Themes yang telah saya buat.

Keempat. Show. Don't tell.

Ini adalah masanya untuk anda buktikan bahawasanya, anda adalah asset kepada syarikat. Anda ada value yang boleh membantu syarikat menjana kekayaan.

Dalam ketiga-tiga syarikat yang saya sertai. Saya adalah orang pertama yang melaksanakan perkara ini. Saya ada manager, saya ada director. Saya tempah masa mereka 1 - 2 bulan awal untuk mereka luangkan masa untuk saya bentangkan Track & Record saya.

Setiap tahun saya akan book pada hujung Disember kerana pada waktu ini kerana pada saya, ini masa yang sesuai sebelum masuk ke tahun baru. Dan sinonim dengan Masuk tahun baru dengan Azam yang baru.

Pada sesi ini, anda wajib untuk bentangkan segala data yang anda buat semasa langkah ketiga yakni Track & Record.

Anda kena kongsikan data yang berjaya dan yang tidak berjaya. Anda kena buat satu Presentation dan bincangan secara terperinci apa yang telah anda laksanakan sepanjang 12 bulan anda bekerja.

Kelima. Kongsikan matlamat

Pada langkah ke-empat, anda jangan hanya sekadar beritahu tentang Track & Record anda. Tetapi yang paling penting, anda kena kongsi matlamat kerjaya anda.

Dari sini anda boleh tahu adakah Syarikat boleh berikan peluang untuk anda mencapai matlamat yang anda inginkan. Jika syarikat tidak boleh untuk menawarkan peluang untuk anda capai matlamat kerjaya. Tidak mengapa. Mungkin syarikat lain boleh.

Anda tak perlu kongsi Matlamat utama anda Seperti nak jadi CTO. tapi kongsi yang kecil sahaja. Sebagai contoh, Saya nak mahir dalam beberapa perkara pada tahun hadapan seperti API, Server, Cloud Storage dan lain-lain.

Nah.. Inilah perkara yang saya laksanakan dari dahulu sehingga sekarang. Setiap tahun. Apa yang saya belajar daripada semua ini adalah, syarikat nak lihat Nilai yang ada pada diri anda. Adakah Nilai itu berbaloi untuk mereka naikkan gaji anda? Atau naikkan pangkat anda?

Saya lihat ramai rakan-rakan Developer saya sekadar kerja. Sekadar harapkan gaji hujung bulan. Kalau tak cukup, mengeluh. Tapi apa tindakan pun tak diambil untuk memperbaiki hidup.

Saya pun dulu begitu. Selesa dengan tugasan. Tidak mahu keluar dari ruang selesa. Tidak mahu buat perkara baru seperti Coding untuk Front-end (sebab saya fokus ke Back-end). Tapi kalau bercerita tentang gaji, sibuk kata tak cukup.

Saya harap langkah ini anda dapat laksanakan demi mencapai apa yang anda inginkan dalam kerjaya. Nak jadi seorang Senior Developer pun, ada perjalannya (path). Apatah lagi nak capai Gaji RM30K sebulan. Tak gitu.

Saya kongsikan Google Slide yang saya buat semasa perbentangan saya dengan Syarikat saya bekerja sekarang.

** Saya buang nama syarikat, gambar syarikat dan nama klien.

Slide 1. Result - Kenaikkan gaji 28% :
Google Slide

Slide 2. Result - Kenaikkan gaji 43% :
Google Slide

Saya harap guideline ini bermanfaaat kepada rakan-rakan developer.

Sekiranya anda ada persoalan, bolehlah bertanya dibawah. Saya akan sedaya updaya untuk menjawab soalan anda.

Terima kasih kerana sudi membaca.

How to enable user to upload profile photo in Laravel 8

Muhamad Sulaiman — Tue, 11 Jan 2022 16:01:55 +0000

Today I was assigned to develop a user profile function in our client web apps.

Ok, easy enough. I just need a form that has enctype and file upload.

So I thought it only needs to upload the image, then store it in DB and then show it to the front-end.

However, the flow that I thought is wrong. The flow should be very seamless. Which is when the user success registers, they can see the default profile image (set by the system, like example image). Then when users click on the image, their windows appear, choose the image and then save.

The save button should not like the default file upload (refer to Bootstrap File Input).

Also, after the user click Save Photo, the system will behave like SPA. Without refreshing the browser.

That time I know I was in trouble. Because I don't like much play around with JavaScript. I know I can achieve that using vanilla or JS Framework such as Inertia or Vue. I'm using Laravel by the way.

So after searching, I decide to use Laravel Livewire. Why?

This is mainly because I think I can make it using Livewire and not others. And the best part of Livewire is that even though I code dynamic function for Front-end, but I'm coding it using PHP Laravel. I don't know if this makes any sense to you.

So how do I develop it using Livewire?

First, after I create the component, I create a method named avatar() on User Class.

Second, in the livewire component, I use the file upload trait (because Livewire does not support file upload by default).

Then I create a method to save the avatar when the user uploaded it. Don't forget to set the avatar null to remove the button right after user successfully upload the image.

Third, in my rendering component file, I show the default image first. Then after the user saves, the image will change into a new image.

That's it. With all of these steps, you now will have a User profile functionality.

I've complete the task. Now your turn to do it better than me. Share your experience in the comment section ;)

DEV Community: Muhamad Sulaiman

How I Smashed Image Compression in Laravel Using Node.js

The real problem

Why I moved it to a queue

Why Sharp

The architecture

Why I kept Node.js isolated

Project structure

Controller flow

The queued job

The Node.js worker

What improved

Trade-offs

Final thought

SDD is now my go-to when developing a Website / Software

Beyond CRUD: The Developer’s Ascent – A Story of Growth

Understanding Polymorphism vs. Polymorphic in Programming

Introduction

What is Polymorphism?

Example of Polymorphism in PHP (Method Overriding)

Output

What is a Polymorphic?

Example of Polymorphic Relationship in Laravel

Polymorphic Relationships Exist Beyond Laravel

Conclusion

To visualize the difference

Understanding Laravel Queues: queue:work vs queue:listen and Why queue:restart Matters

🚀 queue:work vs queue:listen

🛠 php artisan queue:work

🎧 php artisan queue:listen

✅ Which One to Use?

🔄 Why queue:restart Is Necessary

🤖 How Supervisor Fits In

🔥 Best Practices for Laravel Queues in Production

🎯 Final Thoughts

My Journey from BootstrapCSS to TailwindCSS: A Backend Developer’s Perspective

Discovering Tailwind: From Skepticism to Adoption

Performance and Flexibility: Why Tailwind Wins for Me

Adjusting to Tailwind: A Learning Curve

Challenges and Lessons Learned: Transitioning to Tailwind

Embracing Agile, Scrum, and Kanban in Project Management: A Personal Journey

The Waterfall Challenge

The Shift to Agile-Scrum-Kanban: A New Way of Thinking

Adapting to Challenges

The Outcome: A Successful Sprint

Final Thoughts

A Story From WordPress to Leadership: A Software Engineer's Journey

The Early Days: Mastering WordPress

Broadening Horizons: The Software Engineer.

The Unexpected Promotion: Lead Developer

The Reality of Leadership

The Struggle for Balance

The Decision to Move On

A New Chapter: Return to Coding

Lessons Learned

Conclusion

Create a re-useable Mailing Code in Laravel

Inverse of hasManyThrough Laravel

[BM] Bagaimana untuk menikmati kenaikkan gaji bagi seorang Web Developer

Kenapa anda perlu buat perkara ini?

Pertama. Matlamat

Kedua. Bertindak.

Ketiga. Track & Record

Keempat. Show. Don't tell.

Kelima. Kongsikan matlamat

How to enable user to upload profile photo in Laravel 8

🚀 `queue:work` vs `queue:listen`