Happy 34th Birthday, Linux

Happy 34th Birthday, OS Linux! 🎂🐧

On August 25, 1991, a young Finnish student named Linus Torvalds made a modest announcement on the Usenet group comp.os.minix. He wrote that he was working on “just a hobby, nothing big and professional” — a free operating system kernel for 386/486 AT clones. That “hobby” would soon grow into Linux, the foundation of one of the most influential open-source movements in history.

Today, in 2025, we celebrate 34 years of Linux — a system that powers everything from supercomputers, smartphones, and cloud servers to IoT devices, cars, and even space missions.


From Hobby Project to Global Phenomenon

What started as a personal learning project quickly gained traction. Developers from all over the world joined Linus, contributing code, testing features, and improving performance. Within months, Linux had transformed from a rough kernel into the cornerstone of a community-driven ecosystem.

By 1992, Linux was officially released under the GNU General Public License (GPL), ensuring its growth as free and open software. This decision shaped its future, making collaboration and transparency its DNA.


The Impact of Linux

  • Servers & Cloud: More than 90% of the world’s top 1 million servers run Linux.
  • Supercomputers: Every single system in the Top500 supercomputer list runs Linux.
  • Smartphones: Android, the most popular mobile OS, is built on the Linux kernel.
  • Innovation: From AI research to Kubernetes orchestration, Linux is everywhere.

Simply put: without Linux, modern computing as we know it wouldn’t exist.


Why Developers Love Linux

  1. Freedom & Flexibility — open code means endless possibilities.
  2. Community Support — thousands of contributors worldwide.
  3. Stability & Security — a proven track record in mission-critical environments.
  4. Learning & Growth — Linux remains the go-to platform for students, sysadmins, and developers alike.

Looking Ahead

As we mark Linux’s 34th anniversary, the journey is far from over. With advances in AI, edge computing, and open hardware, Linux continues to push boundaries and empower innovation. Its story is a reminder of what’s possible when curiosity, collaboration, and community come together.


Final Thought

From a Usenet post in 1991 to the backbone of the internet in 2025 — Linux has come a long way. Today, we don’t just celebrate software; we celebrate an idea that changed the world.

Happy Birthday, OS Linux! 🐧🎉 Thank you, Linux Torvalds.

Laravel Best Practices: Repository Pattern for Clean and Scalable Code

Imagine situation: when you start building applications with Laravel, it’s very tempting to place all logic directly in controllers. After all, Eloquent models make querying the database straightforward, so why not just use them everywhere?

But as your application grows, you’ll notice that this approach quickly leads to fat controllers, tangled logic, and difficulties with testing or making future changes. That’s where the Repository Pattern comes into play.

What is the Repository Pattern?

The Repository Pattern is a design pattern that acts as a mediator between your application logic and data access layer. Instead of querying Eloquent models directly inside controllers or services, you put that logic into dedicated repository classes.

This separation of concerns gives you:
• Cleaner controllers – focused only on handling HTTP requests and responses.
• Testability – you can mock repositories in your unit tests without touching the database.
• Maintainability – changes in data access (e.g., switching from MySQL to PostgreSQL, or even to an API) require minimal changes in your business logic.
• Reusability – one repository can be used by multiple services or controllers.

Example: Implementing a User Repository

Let’s look at a simple example.

Instead of this (in a controller):

public function login(Request $request)
{
    $user = User::where('email', $request->input('email'))->first();
    // authentication logic...
}

We’ll create a separate repository class:

// app/Repositories/UserRepository.php
namespace App\Repositories;

use App\Models\User;

class UserRepository 
{
    public function findByEmail(string $email): ?User
    {
        return User::where('email', $email)->first();
    }
}

Now, inject this repository into your controller:

// app/Http/Controllers/AuthController.php
namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Repositories\UserRepository;

class AuthController extends Controller
{
    public function login(Request $request, UserRepository $users)
    {
        $user = $users->findByEmail($request->input('email'));
        
        // handle authentication...
    }
}

Adding Interfaces for More Flexibility

To make it even more flexible, you can define an interface for your repository. This allows you to swap implementations easily (e.g., switch to an external API instead of a database).

// app/Repositories/UserRepositoryInterface.php
namespace App\Repositories;

use App\Models\User;

interface UserRepositoryInterface 
{
    public function findByEmail(string $email): ?User;
}

Then, implement it in your repository:

// app/Repositories/UserRepository.php
namespace App\Repositories;

use App\Models\User;

class UserRepository implements UserRepositoryInterface
{
    public function findByEmail(string $email): ?User
    {
        return User::where('email', $email)->first();
    }
}

And finally, bind the interface to the implementation in a service provider:

// app/Providers/AppServiceProvider.php
public function register(): void
{
    $this->app->bind(
        \App\Repositories\UserRepositoryInterface::class,
        \App\Repositories\UserRepository::class
    );
}

Now your controller can depend on the interface, not the concrete class:

public function login(Request $request, UserRepositoryInterface $users)
{
    $user = $users->findByEmail($request->input('email'));
    // handle authentication...
}

When Should You Use It?
• Medium to large projects with complex business logic.
• Projects where testing is important (mocking repositories instead of hitting the database).
• Systems that might change data sources in the future.

For small projects, the Repository Pattern may feel like overkill. But in most real-world Laravel applications, it helps you keep code clean, testable, and future-proof.

Conclusion

The Repository Pattern is one of the most practical best practices you can apply in Laravel. It enforces separation of concerns, keeps controllers slim, improves testability, and makes your project more maintainable in the long run.

If you’re building anything beyond a toy app, consider introducing repositories early—it’s a small investment that pays off big as your project grows.

How to Find Large Files on Ubuntu Linux (and Clean Up Disk Space)

🧹 How to Find Large Files on Ubuntu 18.04 (and Clean Up Disk Space)

If you’ve ever run into the dreaded “No space left on device” error on your Linux system, you’re not alone. Over time, log files, package caches, and forgotten downloads can fill up your disk. In this guide, we’ll walk through several ways to identify large files and directories on your Ubuntu 18.04 system — using both command-line tools and interactive utilities.


📁 Why You Might Need This

  • Your system is running low on disk space.
  • You’re managing a server and want to optimize storage.
  • You want to clean up unused data before creating a backup.
  • You’re just curious what’s eating up all your GBs.

🔍 Method 1: Find Large Files Using

find

Let’s say you want to find files larger than 100 MB:

sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k 5 -hr | head -n 20

What this does:

  • find /

    — search the whole system

  • -type f

    — look for files only

  • -size +100M

    — files larger than 100 megabytes

  • ls -lh

    — show file size in human-readable format

  • sort -k 5 -hr

    — sort files by size, descending

  • head -n 20

    — show only the top 20 results

🔐 Note: You may need

sudo

to access some directories.


📦 Method 2: Show Largest Directories with

du

To find out which folders are taking up the most space, use:

du -h --max-depth=1 | sort -hr

This lists the size of each subdirectory in the current folder. Example output from

/var

:

3.4G    ./log
1.2G    ./cache
5.0G    .

You can also search the whole system:

sudo du -ah / | sort -rh | head -n 30

This command lists the 30 biggest files and folders system-wide.


🖥️ Method 3: Use

ncdu

– The Friendly Disk Usage Viewer

Prefer something more visual and interactive? Try

ncdu

:

Install it:

sudo apt update
sudo apt install ncdu

Run it:

sudo ncdu /

Navigate the disk usage tree using arrow keys. Press

d

to delete files directly from within the tool (be careful!).


🧼 Bonus Tips: Clean Up with Built-in Tools

Clear APT cache:

sudo apt clean

Remove old kernels (Ubuntu auto handles this, but still):

sudo apt autoremove --purge

Check disk space usage at a glance:

df -h

🔚 Wrapping Up

Identifying and removing large files can dramatically improve system performance and free up valuable space. Whether you’re a sysadmin managing a fleet of servers or just cleaning up your dev laptop, these tools will help you stay in control.


💬 What’s your favorite way to clean up disk space on Linux?

Feel free to share your tips in the comments box below this blog post or contribute to the conversation on Reddit, X (Twitter), or your favorite dev community.

🔍 How to Verify Inserted Rows Using a CTE in SQL (WITH expected AS Pattern)

🔍 How to Verify Inserted Rows Using a CTE in SQL (

WITH expected AS

Pattern)

Whether you’re writing seeders, migration scripts, or integration tests — verifying that specific records were inserted into a table is a common and critical task.

Let me show you a clean and portable SQL technique using a Common Table Expression (CTE) to check that a set of expected rows exists in your database — without writing 6 separate

SELECT

queries or messing with application-level checks.


✅ Use Case

Imagine you just ran this

INSERT

into a table called

template

:

INSERT INTO template (service__id, id, os__id, ...)
VALUES
  ('wpsquared', 'cloudlinux8-wp2-v1', 'cloudlinux-8', ...),
  ('wpsquared', 'cloudlinux9-wp2-v1', 'cloudlinux-9', ...),
  ('wpsquared', 'cloudlinux9-wp2-v2', 'cloudlinux-9', ...),
  ('wpsquared', 'cloudlinux9-wp2-v3', 'cloudlinux-9', ...),
  ('plesk',     'ubuntu2204-plesk-v1', 'ubuntu-22.04', ...),
  ('cpanel',    'ubuntu2404-cpanel-v1', 'ubuntu-24.04', ...);

Now you want to confirm that all 6 rows exist.


🧠 The Pattern:

WITH expected AS (...)

Here’s the SQL snippet:

-- Step 1: Define the rows we expect
WITH expected AS (
    SELECT 'wpsquared' AS service__id, 'cloudlinux8-wp2-v1'  AS id UNION ALL
    SELECT 'wpsquared', 'cloudlinux9-wp2-v1'  UNION ALL
    SELECT 'wpsquared', 'cloudlinux9-wp2-v2'  UNION ALL
    SELECT 'wpsquared', 'cloudlinux9-wp2-v3'  UNION ALL
    SELECT 'plesk',     'ubuntu2204-plesk-v1' UNION ALL
    SELECT 'cpanel',    'ubuntu2404-cpanel-v1'
)

-- Step 2: Check which of them are missing
SELECT  e.service__id,
        e.id
FROM    expected e
LEFT JOIN template t
       ON  t.id = e.id
       AND t.service__id = e.service__id
WHERE   t.id IS NULL;

📋 Result

  • If the query returns 0 rows → ✅ You’re good! All expected rows are present.
  • If any rows are returned → ⚠️ These are missing or mismatched by primary key or foreign key.

🔄 Bonus: Quick Boolean Check

Want a compact version that tells you how many rows are missing?

WITH expected AS (
    -- same as above
)
SELECT COUNT(*) AS missing_count
FROM   expected e
LEFT   JOIN template t
       ON t.id = e.id AND t.service__id = e.service__id
WHERE  t.id IS NULL;

🧬 Cross-Database Compatibility

This pattern works on:

  • PostgreSQL
  • MySQL / MariaDB
  • SQLite
  • SQL Server 2005+ (with some minor syntax adaptation)

The key is that all of these databases support CTEs (Common Table Expressions) and

LEFT JOIN

logic.


🧑‍💻 When Should You Use This?

  • To test database seeders
  • To verify data migration scripts
  • During CI pipelines or test automation
  • For quick manual checks in staging or dev

📎 Final Tip

You can also extend this pattern to check not just existence, but field-level equality, version numbers, or even timestamps — just join on more columns and compare.


If you liked this trick, follow me or join my community [insert your Reddit, blog, or channel link here] where I share more real-world PHP + SQL tips like this one!

How to create a simple IP address tracker with geolocation in Symfony 6+

Do you want to know who visits your website, where they’re from, and when?
In this post, I’ll show you how to build a small Symfony project that:

  • Detects the visitor’s IP address
  • Retrieves geolocation data based on the IP
  • Stores this data in a database
  • Displays the IP, country, and city on the homepage

⚙️ Project Setup

Creating a new Symfony project:

composer create-project symfony/skeleton:"6.4.*" ip-tracker  
cd ip-tracker

Installing required dependencies:

composer require symfony/twig-bundle  
composer require symfony/http-client  
composer require symfony/orm-pack doctrine/doctrine-bundle  
composer require nesbot/carbon  
composer require symfony/maker-bundle --dev

🧱 Creating the Controller

File:

src/Controller/ClientIpController.php

<?php

namespace App\Controller;

use App\Entity\VisitorLog;
use App\Service\IpGeolocationService;
use Carbon\Carbon;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ClientIpController extends AbstractController
{
    #[Route('/', name: 'app_home')]
    public function index(Request $request, IpGeolocationService $ipService, EntityManagerInterface $em): Response
    {
        $ip = $request->getClientIp();
        $geo = $ipService->getGeolocation($ip);

        $log = new VisitorLog();
        $log->setIp($ip);
        $log->setCountry($geo['country'] ?? null);
        $log->setCity($geo['city'] ?? null);
        $log->setCreatedAt(Carbon::now());

        $em->persist($log);
        $em->flush();

        return $this->render('client_ip/index.html.twig', [
            'ip' => $ip,
            'geo' => $geo,
        ]);
    }
}

🌐 Geolocation Service

File:

src/Service/IpGeolocationService.php

<?php

namespace App\Service;

use Symfony\Contracts\HttpClient\HttpClientInterface;

class IpGeolocationService
{
    public function __construct(private HttpClientInterface $client) {}

    public function getGeolocation(string $ip): array
    {
        $response = $this->client->request('GET', "https://ipapi.co/{$ip}/json/");
        return $response->toArray();
    }
}

🗃 Creating an Entity for Logging

Command:

php bin/console make:entity VisitorLog

Fields:

  • ip

    : string

  • country

    : string (nullable)

  • city

    : string (nullable)

  • createdAt

    : datetime_immutable

Migrations:

php bin/console make:migration  
php bin/console doctrine:migrations:migrate

🖥 Template for Displaying Information to Users

File:

templates/client_ip/index.html.twig

{% extends ‘base.html.twig’ %}

{% block title %}Your IP Address is: {{ ip_address }}{% endblock %}

{% block body %}
<div class="ip-address-wrapper"><h1>Your IP Address is: {{ ip_address }}</h1></div>
{% if geo %}
<ul class="ip-info">
<li>Country: {{ geo.country }}</li>
<li>City: {{ geo.city }}</li>
</ul>
{% endif %}
{% endblock %}


📦 Project Dependencies

According to the list in

composer.json

, this project uses:

  • Symfony 6.4
  • Doctrine ORM
  • Twig
  • Carbon
  • HttpClient
  • MakerBundle (dev)

📝 Conclusion

Together we’ve built a full-featured IP logger on Symfony:

✅ Detects IP
✅ Retrieves geolocation
✅ Stores data in the database
✅ Displays it on the page

This functionality can serve as the foundation for a more complete analytics system, access control, or content personalization for your users.

How to Open Unverified Apps on macOS: MarkText Example

🚀 How to Open Unverified Apps on macOS: MarkText Example

If you’ve ever tried launching an app like MarkText on macOS and saw the warning:

“The application can’t be opened because the developer cannot be verified”

— don’t worry. You’re not alone, and yes, there’s a safe way around it.

In this article, I’ll show you how to launch unverified but trusted applications like MarkText, step-by-step.


🔒 Why Does macOS Block Some Apps?

macOS has a security feature called Gatekeeper that only allows apps from:

  • The Mac App Store
  • Verified developers registered with Apple

This is great for security but can block open-source tools and smaller projects — even if they’re totally safe.


✅ Option 1: Allow Once via System Settings

Here’s how to bypass the block and launch an app manually:

  1. Try to launch the app — you’ll get a warning popup.

  2. Open System SettingsPrivacy & Security

  3. Scroll down and find the section saying:

    “MarkText was blocked from use because it is not from an identified developer.”

  4. Click Allow Anyway

  5. Go back and right-click the app icon, then select Open

  6. This time, you’ll get a new popup with an Open button. Click it.

That’s it — your app will now launch!


🧑‍💻 Option 2: Use Terminal to Bypass Gatekeeper (Power Users)

If you’re comfortable with Terminal, here’s a quick command to remove the "quarantine" flag that macOS adds when downloading apps from the internet:

sudo xattr -rd com.apple.quarantine /Applications/MarkText.app

🧠 Tip: If your app is located somewhere else (like Downloads), adjust the path accordingly.

This command tells macOS: “Hey, I trust this app — stop treating it like malware.”


⚠️ A Word of Caution

Only bypass Gatekeeper for software from trusted sources like GitHub or official project websites. If you’re not 100% sure an app is safe, don’t ignore the warning — it’s there for your protection.


💡 Conclusion

You now know how to safely launch unverified apps like MarkText on your Mac. Whether you prefer the GUI route or the terminal method, you’re back in control.

Let your creativity flow — Markdown away! 😉

What is Docker and Why Developers Should Care

Docker is a tool that allows you to run your projects inside special isolated environments called containers.
Imagine packing your app together with all its dependencies — PHP version, MySQL, Redis, configs — and giving it to another developer or running it on a server without the classic “but it worked on my machine!”.

A container is like a mini-computer inside your system: it starts in seconds, can be copied or destroyed easily, and doesn’t eat up gigabytes of RAM like traditional virtual machines.


Why web developers love Docker:

  • Consistent environments. The same code runs identically on your local, staging, and production servers.
  • Fast onboarding. A new team member? One command and they’re ready to code.
  • Service isolation. PHP, MySQL, Redis, Nginx — each in its own container. Easily swappable and scalable.
  • Effortless deployment. A container is a portable unit ready to be deployed anywhere.
  • CI/CD integration. Works smoothly with GitLab CI, GitHub Actions, Jenkins, and more.

A few key terms to know:

  • Docker Engine – the core software that manages containers.
  • Image – a template used to create containers (e.g., php:8.2-fpm).
  • Container – a running instance of an image.
  • Dockerfile – a file that defines how to build your own image.
  • – Docker Compose – a file that defines and runs multi-container applications (like php, mysql, nginx, etc.).

In the next post, I’ll show how to install Docker on Ubuntu and other operating systems.
But for now, ask yourself: “How much time do I waste configuring dev environments?”
Docker might save you days.


If you found this post helpful — save it, share it, or follow the series. More practical stuff coming soon!

Service Classes in Laravel: Clean Architecture and Scalability

✍️ Introduction

In Laravel, it’s convenient to put business logic into controllers or models. But what should you do when the logic starts to grow? The right solution is to move it into dedicated service classes. This approach follows the Single Responsibility Principle (SRP) and helps make your code scalable and easy to test.


🧱 Structure of a Service Class

Let’s take a look at a basic example of a service class responsible for creating an order:

app/
├── Services/
│   └── OrderService.php
namespace App\Services;

use App\Models\Order;
use App\Models\User;
use Illuminate\Support\Facades\DB;

class OrderService
{
    public function create(array $data, User $user): Order
    {
        return DB::transaction(function () use ($data, $user) {
            $order = new Order();
            $order-&gt;user_id = $user-&gt;id;
            $order-&gt;total = $data['total'];
            $order-&gt;status = 'new';
            $order-&gt;save();

            // Here you could dispatch events, send emails, etc.

            return $order;
        });
    }
}

🚀 Using It in a Controller

namespace App\Http\Controllers;

use App\Http\Requests\OrderRequest;
use App\Services\OrderService;
use Illuminate\Http\JsonResponse;
use Illuminate\Support\Facades\Auth;

class OrderController extends Controller
{
    public function __construct(
        protected OrderService $orderService
    ) {}

    public function store(OrderRequest $request): JsonResponse
    {
        $order = $this-&gt;orderService-&gt;create($request-&gt;validated(), Auth::user());

        return response()-&gt;json([
            'message' =&gt; 'Order created successfully.',
            'order' =&gt; $order,
        ]);
    }
}

Why This Approach Rocks

  • Cleaner architecture: Controllers become slim and act as entry points, not logic holders.
  • Easy testing: Services can be tested in isolation with mocked dependencies.
  • Flexibility: Services are easier to extend or modify without touching the controller.
  • Reusability: You can call the same service from REST APIs, Artisan commands, or queued jobs.

🧪 How to Unit Test the Service

use App\Models\User;
use App\Services\OrderService;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class OrderServiceTest extends TestCase
{
    use RefreshDatabase;

    public function test_it_creates_an_order()
    {
        $user = User::factory()-&gt;create();
        $data = ['total' =&gt; 1000];

        $service = new OrderService();
        $order = $service-&gt;create($data, $user);

        $this-&gt;assertDatabaseHas('orders', [
            'user_id' =&gt; $user-&gt;id,
            'total' =&gt; 1000,
        ]);
    }
}

🔚 Conclusion

Service classes in Laravel aren’t overengineering — they’re a smart and maintainable way to structure your business logic. By adopting this pattern, your Laravel applications become cleaner, more modular, and ready for future growth.

🧭 What is Symfony? And How Is It Different from Laravel?

🧭 Symfony is a powerful open-source PHP framework focused on stability, flexibility, and reusable components. It’s widely used to build complex, scalable web applications, enterprise systems, or RESTful APIs. At its core, Symfony is a component-based architecture — and many of its components are actually used by other frameworks, including… Laravel.

Yes, you read that right: Laravel is built on top of Symfony components like HttpFoundation, Routing, Console, EventDispatcher, and more. But despite that, there are several major differences between the two.


🔍 Key Differences Between Symfony and Laravel

1. Architecture Philosophy

  • Symfony follows a flexible and modular approach — you choose exactly which components you want to use.
  • Laravel comes with most features "batteries-included" — everything is ready to go out of the box.

2. Configuration Style

  • Symfony encourages configuration using YAML, XML, or PHP files.
  • Laravel primarily uses PHP config files located in the config/ directory and a simple .env file for environment variables.

3. Project Structure

  • Symfony enforces a stricter project structure, with a strong focus on PSR standards and SOLID principles.
  • Laravel has a simpler, more beginner-friendly structure, though it sacrifices some architectural flexibility.

4. Templating

  • Symfony uses Twig — a secure, fast, and lightweight templating engine.
  • Laravel uses Blade, which is tightly integrated with Laravel’s core and favored by many PHP developers.

5. Strengths and Use Cases

  • Symfony is ideal for large-scale, enterprise-grade applications that demand long-term support (with LTS releases).
  • Laravel is great for rapid development of MVPs, startups, or projects with a quick release cycle.

🎯 Conclusion

Symfony is not a direct replacement for Laravel — it’s simply a different tool for different needs. If you want full control over architecture, advanced service container management, and long-term support — Symfony is your friend. Laravel is all about developer happiness and speed. Symfony is about stability and scale.

In the next post, we’ll dive into installing Symfony and creating your first project. Stay tuned! 😉

Laravel Facades Uncovered: Convenient, but Always Safe?

Facades are a common and convenient practice in Laravel development.
No need to import services manually — just call Cache::get() and go.
But do you really know what’s happening behind the scenes?

In this post, we’ll break it down:

1. How Facades Work Under the Hood

A facade is just a static wrapper around a service in the Laravel Service Container.

Cache::get('key');

is essentially the same as:

app('cache')->get('key');
// or via dependency injection:
$cache->get('key');

So, facades aren’t really static — they resolve real objects from the container dynamically.


2. What’s the Catch?

Facades are convenient, but:

  • Harder to test — mocking with Cache::shouldReceive() or Mail::fake() can be unintuitive;
  • Hidden dependencies — classes don’t explicitly declare what they rely on;
  • Weak IoC principles — swapping implementations becomes more difficult.

3. When Should You Use Dependency Injection Instead?

Prefer DI when you:

  • Want testable, flexible code;
  • Work with multiple implementations of a contract;
  • Need to clearly express a class’s dependencies.
use Illuminate\Contracts\Cache\Repository as Cache;

class UserService 
{
    public function __construct(private Cache $cache) {}

    public function getUser(int $id)
    {
        return $this->cache->remember("user:$id", 60, fn() => User::find($id));
    }
}

4. Refactoring from Facade to Dependency Injection

Before:

class UserService 
{
    public function getUser(int $id)
    {
        return Cache::get("user:$id");
    }
}

After:

use Illuminate\Contracts\Cache\Repository as Cache;

class UserService 
{
    public function __construct(private Cache $cache) {}

    public function getUser(int $id)
    {
        return $this->cache->get("user:$id");
    }
}

TL;DR

Facades are fast and easy to use.
But for scalable, testable, and maintainable architecture — consider dependency injection instead.

Do you use facades in your Laravel projects? Share your thoughts in the comments!