DEV Community: Huzaifa Rasheed

The Things We Own

Huzaifa Rasheed — Tue, 11 Aug 2026 15:34:17 +0000

Repost of https://rhuzaifa.com/blog/the-things-we-own/

On renting, ownership, leverage, and why I increasingly want to own more of the things that matter.

Renting Isn't Bad
A House Is the Obvious Example
The Software You Rent
Own the File, Not the Feed
Careers Are Rented Time
The Next Thing Is Cheaper
Ownership Has a Maintenance Tax
Build an Exit Door
What Should You Actually Own?
- Identity
- Data
- Skills
- Content
- A Place the Writing Stays
- Some Infrastructure
- Things That Make the Next Thing Easier
Rent Convenience. Own Leverage.

There is something satisfying about owning something.

Not because of the object itself. A house is still walls and maintenance. A server is still a computer burning electricity. Software is still code.

Ownership changes what you can do with it. Change it. Break it. Keep it ten years without asking. Make decisions that make no sense to anyone else.

That last part is what I like most.

I've always built things myself when an existing solution didn't quite fit. Sometimes smart. Sometimes a wasted weekend.

Last year I spent two nights on a tiny download script because I didn't want another account and another "workspace." Ugly script. Still runs. I still know where the files are.

So this isn't really a technology preference.

I want control over the things I depend on.

The rent-versus-own frame isn't original. A lot of people have said a version of this. The calls I made, and the ones I still haven't, are mine.

Renting Isn't Bad

Renting is usually the right move. You don't need to own a car to drive, or a server to ship a site, and you don't need to build everything because you can.

Need a GPU for three hours? Rent it. Buying for a temporary spike is how you get idle hardware and a story about "investment."

I learned that the long way with email. I wanted an address on my own domain. I tried doing it "properly" (self-hosted mail). Reputation, queues, TLS, spam. Owning the pipes bought me a second job, not more freedom.

So I rented the infra on purpose. Cloudflare for inbound. Gmail for the inbox I already lived in. No mail-vendor bill. Custom address. Someone else's spam war. The part I actually needed to own was the domain, not Postfix, Mailcow, or whatever else I would have been babysitting.

Renting the boring layer gave me more options than running a mail server ever did.

Rent until the thing is load-bearing.

The danger is renting something that becomes strategically important to you.

A House Is the Obvious Example

This is the example everyone uses. I'll keep it short.

Rent for ten years and you bought access. Buy and some of the money becomes equity, plus a roof, tax, and money you can't point elsewhere.

v/s

Own it and you pick which costs are worth it. Flexibility vs control. Moving a lot > rent. Staying put > own starts looking better.

Same fork in software and work.

The Software You Rent

Most software we use isn't ours. Email, storage, design tools, managed databases. Often correct.

Why babysit Postgres when managed Postgres exists? Sometimes you shouldn't.

The sharper question: what happens if it disappears?

Wire a few years of notes, files, and automations into one service. Pricing changes. Feature dies. Account locked. You didn't lose an app. You lost infrastructure.

I dodge a small version of that with writing. Draft wherever. The durable copy of my site is Markdown in a repo I control, not posts trapped in whoever's editor was convenient. Worse than a polished CMS some days. Harder to revoke.

Use services. Don't depend on them for the irreplaceable copy.

Own the File, Not the Feed

I don't have a platform audience to "own." That's fine. This section is about where the words live, not who claps.

Views and followers on someone else's app are rented reach. I don't play that game much. LinkedIn is a profile, no posts. The X posts live on X.

The writing I care about keeping is supposed to live on the domain. A URL I control. I can open the file, change it, move hosts, keep the address. A post that only lives inside an app is gone if the account is, or buried if the feed moves on.

That's the how: not more attention. More chance the writing still exists. An email list would be a tighter loop later. Not a relationship I pretend to have.

Careers Are Rented Time

A job rents your time. Good deal: pay, sales handled, less risk on you.

Do it for ten years with nothing outside the job and the ledger gets thin. Bills paid. Weekends gone. Experience up. Durable assets? Maybe not.

Pay isn't enough. Leave more valuable than you arrived.

If I spend six months on a stack for someone else, I try to disclose some of that work in public. A post about the problem. A small repo. Notes I can point at later. Not the confidential bits. The craft. Same time spent. Now the work isn't only trapped in a company's Slack.

Projects can fail and still leave code or a map of what doesn't work. Jobs don't always leave that.

The Next Thing Is Cheaper

Once you own a place to put things, the next thing is cheaper.

I already have a domain, a repo, a way to ship a page. A new post, a small tool, a note I want public: it goes in the same pile. I don't open another account to start. That's the trick. Not that I have a lot of posts. I don't. The old setup holds the new work.

Same with the home server. Once the box is already on, the next git repo, script, an automation, or small service doesn't need a new machine. I already paid for the electricity and the fuss.

Same with a skill I already paid for at a job. Next time I need it, I'm not at zero. Modest stack. Still compounding.

Ownership Has a Maintenance Tax

Own too much and you become the unpaid ops team.

Patch the server at midnight. Full-time job, self-assigned. Not freedom. Another dependency.

There's a Fight Club line that shows up whenever I get too romantic about this:

"The things you own end up owning you. It's only after you lose everything that you're free to do anything."

First half: yes. Everything collects rent in attention.

Second half: no. Burning it all down is drama, not strategy. Bankruptcy with better lighting.

Don't accumulate things that own your attention without returning leverage.

I was trying to automate some sending. Forms, lists, little workers that should have just run. A cheap tool already did it. I still spent evenings building my own. Then I had to keep the thing alive. That's the tax.

Ask: does this own me back more than it frees me?

I'll rent CDNs and mail plumbing. Spend ownership budget on what compounds. Price alone is a bad scorecard. Time and dependency count.

Build an Exit Door

You don't need to own the machine to keep control. You need a way out.

Export. Domain. Portable copy. If you can leave without losing the work, you have leverage.

For anything important: what if I leave tomorrow? Can I get the files out? Do I even care about the files?

I could have kept everything on GitHub. Instead: bare repos on a machine I already had, SSH push, cron'd backups of the important history. Not fancy. An exit that already works.

I don't mind rented tools or platform distribution. I mind no door.

Dependence is normal. Unexamined dependence is the problem.

What Should You Actually Own?

Own these. Rent the rest.

Identity

Name, domain, reputation. Existence that isn't one app's account row.

Data

Copies in boring formats. If leaving erases history, you never had it. Markdown on disk is ugly and hard to revoke.

Skills

Companies and frameworks leave. Learning and building travel with you.

Content

Publish anywhere. Keep originals somewhere you control.

A Place the Writing Stays

Not owning humans. A URL and a file that still exist if the feed dies. Domain first. Inbox optional.

Some Infrastructure

Enough that one vendor mood swing can't kill what matters. Not a second full-time job.

Things That Make the Next Thing Easier

A domain, a repo, a skill you already paid for. The next thing isn't a new account.

Rent Convenience. Own Leverage.

Rent what changes fast, costs too much to maintain, or where someone else has absurd scale.

Own what accumulates and survives a pricing or algorithm change.

Rent convenience. Own leverage. Keep an exit door.

That's less "This is mine" and more "I decide what happens next."

Ownership vs renting isn't the fight.

Knowing which is which is.

Valid Sudoku Algo - Leetcode

Huzaifa Rasheed — Tue, 21 Mar 2023 18:50:34 +0000

So the other day I was doing some leetcode and found the Valid Sudoku problem interesting. Also since I had not posted for a long time (missed it 😁), thought why not just write how I solved, so here it goes.

Algorithm (I followed)

1- Map over each row of the board, check if row has duplicate numbers
2- Map over each column of the board, check if column has duplicate numbers
3- Map over each row of the board, if that row is the start of a unique 3x3 matrix, then create three 3x3 matrices and check for duplicates

We can check for each test case in a single map

Implementation (JavaScript)

/**
 * @param {character[][]} board
 * @return {boolean}
 */
var isValidSudoku = function (board) {
    // map over each row
    for (let row = 0; row < board.length; row++) {
        // we will store and check for dup digits
        const foundRowDigits = [];
        const foundColDigits = [];

        // map over each column
        for (let col = 0; col < board.length; col++) {
            const rowDigit = board[row][col]
            if (rowDigit !== '.') { // we are ignoring periods '.'
                // check duplicates in row
                if (foundRowDigits.includes(rowDigit)) {
                    // oh uh, dup found -> invalid sudoku
                    return false
                }

                foundRowDigits.push(rowDigit) // store row digit for further comparison
            }

            const colDigit = board[col][row]
            if (colDigit !== '.') { // we are ignoring periods '.'
                // check duplicates in row
                if (foundColDigits.includes(colDigit)) {
                    // oh uh, dup found -> invalid sudoku
                    return false
                }

                foundColDigits.push(colDigit) // store row digit for further comparison
            }
        }


        if (row % 3 === 0) { // row is the start of 3 3x3 matrices
            let threeByThreeGrid = [] // we will store grid values to check dups
            let rowIndex = row

            for (let colIndex = 0; colIndex < 9; colIndex += 3) {
                // make 3x3 grid by taking a rowIndex and colIndex
                for (let gridRowIndex = rowIndex; gridRowIndex < rowIndex + 3; gridRowIndex++) {
                    for (let gridColIndex = colIndex; gridColIndex < colIndex + 3; gridColIndex++) {
                        const digit = board[gridRowIndex][gridColIndex]
                        if (digit !== '.') { // we are ignoring periods '.'

                            // check if there are duplicates in a 3x3 matrix
                            if (threeByThreeGrid.includes(digit)) {
                                // oh uh, dup found -> invalid sudoku
                                return false
                            }

                            threeByThreeGrid.push(digit) // store row digit for further comparison
                        }
                    }
                }

                threeByThreeGrid = [] // reset the grid
            }
        }
    }

    return true // if above test cases passed then sudoku is valid
};

Time complexity

O(n^2) - We have 2 nested for loops. The 3x3 subgrids only work in certain cases so going for the worst case we have O(n^2)

Space complexity

O(1)

Test Cases

A valid sudoku

const validSudoku = [
    ["5", "3", ".", ".", "7", ".", ".", ".", "."],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(validSudoku)) // true

A sudoku with dups in row

const sudokuWithRowDups = [
    ["5", "3", ".", ".", "7", ".", ".", ".", "5"],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(sudokuWithRowDups)) // false

A sudoku with dups in col

const sudokuWithColDups = [
    ["8", "3", ".", ".", "7", ".", ".", ".", "."],
    ["6", ".", ".", "1", "9", "5", ".", ".", "."],
    [".", "9", "8", ".", ".", ".", ".", "6", "."],
    ["8", ".", ".", ".", "6", ".", ".", ".", "3"],
    ["4", ".", ".", "8", ".", "3", ".", ".", "1"],
    ["7", ".", ".", ".", "2", ".", ".", ".", "6"],
    [".", "6", ".", ".", ".", ".", "2", "8", "."],
    [".", ".", ".", "4", "1", "9", ".", ".", "5"],
    [".", ".", ".", ".", "8", ".", ".", "7", "9"]
]

console.log(isValidSudoku(sudokuWithColDups)) // false

A sudoku with dups in 3x3 matrices

const sudokuWith3x3GridDups = [
    [".", ".", ".", ".", "5", ".", ".", "1", "."],
    [".", "4", ".", "3", ".", ".", ".", ".", "."],
    [".", ".", ".", ".", ".", "3", ".", ".", "1"],
    ["8", ".", ".", ".", ".", ".", ".", "2", "."],
    [".", ".", "2", ".", "7", ".", ".", ".", "."],
    [".", "1", "5", ".", ".", ".", ".", ".", "."],
    [".", ".", ".", ".", ".", "2", ".", ".", "."],
    [".", "2", ".", "9", ".", ".", ".", ".", "."],
    [".", ".", "4", ".", ".", ".", ".", ".", "."]
]

console.log(isValidSudoku(sudokuWith3x3GridDups)) // false

It may not be perfect, and can always be improved. Let me know your thoughts and thanks for reading.

How to Avoid Default Props Render Trap in React

Huzaifa Rasheed — Sun, 20 Feb 2022 18:44:27 +0000

What is it?

Let's say we have a component with a default prop like this

import React, { useEffect, useState } from "react";

const RerenderChild = ({ value = [] }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
     {/* ...component */}
    </div>
  );
};

export default RerenderChild;

Whenever the value prop is nullish (not set by the calling component), the useEffect causes the component to render infinitely. This is the Default Props Render Trap. We get something like this in the browser console.

Why It Happens

When we don't provide the value for the value prop it takes the default value provided as argument, which in our case is []. This triggers the useEffect hook which updates the valueFromProp state. The state change causes the component to re-render.

Now when the component re-renders, it takes the new prop values which again are the default one's. This again triggers the useEffect and the whole cycle repeats. That's why we end up with an infinite loop.

The Solution

We have to make the default prop values a part of our component definition. We can do that in these ways.

1. Use defaultProps property.

We can set the default props value by using the component's defaultProps property. Our component now becomes

import React, { useEffect, useState } from "react";

const RerenderChild = ({ value }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
      {/* ...component */}
    </div>
  );
};

RerenderChild.defaultProps = {
  value: [],
};

export default RerenderChild;

2. Declare default props as constants.

We can declare constants outside of our component and set them as our default prop value.

import React, { useEffect, useState } from "react";

const DEFAULT_VALUE = [];

const RerenderChild = ({ value = DEFAULT_VALUE }) => {
  const [valueFromProp, setValueFromProp] = useState([]);

  useEffect(() => {
    setValueFromProp(value);
  }, [value]);

  return (
    <div>
      {/* ...component */}
    </div>
  );
};

export default RerenderChild;

Hope this helps you to avoid the infinite loop. Thanks 😊.

Running Batch Requests In Postman

Huzaifa Rasheed — Sun, 13 Feb 2022 12:59:30 +0000

I recently faced a situation where I had to run bulk/batch requests in postman. There are other ways to seed data like a custom script, but let's just focus on how to do it with postman.

Making Batch Requests in Postman

We will need some setup to demonstrate so let's create one.

1. Setup
I created a simple express server with 2 endpoints for creating and returning data. We will store the data in a variable and run the server at port 3000.

const express = require("express");
const bodyParser = require("body-parser");
const app = express();
const port = 3000;

// parse request data
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

let data = [];

app.get("/", (req, res) => res.json(data).status(200));

app.post("/", (req, res) => {
  data = [...data, req.body];
  res.json(req.body).status(201);
});

app.listen(port, () => console.log(`App listening on port ${port}`));

Now, let's move to postman and create a collection (I am calling it Data Endpoints)

Now let's create 2 requests in the collection (for the 2 endpoints from express server).

Get Data
Insert Data

We will be inserting this data. Let's save it in a file (seedData.json).

[
  {
    "id": 1,
    "first_name": "Gary",
    "last_name": "Ortiz"
  },
  {
    "id": 2,
    "first_name": "Albert",
    "last_name": "Williamson"
  },
  {
    "id": 3,
    "first_name": "Mildred",
    "last_name": "Fuller"
  },
  {
    "id": 4,
    "first_name": "Russell",
    "last_name": "Robinson"
  },
  {
    "id": 5,
    "first_name": "Laura",
    "last_name": "Harper"
  },
  {
    "id": 6,
    "first_name": "Larry",
    "last_name": "Sanders"
  },
  {
    "id": 7,
    "first_name": "Michael",
    "last_name": "Rice"
  },
  {
    "id": 8,
    "first_name": "Sara",
    "last_name": "Harris"
  },
  {
    "id": 9,
    "first_name": "Phyllis",
    "last_name": "Webb"
  },
  {
    "id": 10,
    "first_name": "Roger",
    "last_name": "Alvarez"
  }
]

Now, our setup is complete. Next we will run the actual batch requests.

2. Running Batch Requests
We will be inserting data, so we will need to modify our 'Insert Data' request to allow dynamic data. Something like this

Then, we will need to run the collection.

And select our seedData.json file along with the 'Insert Data' request (then click the 'Run Data Endpoints' button).

It will run the batch requests and give us the results, something like this.

We can use the Get Data request to re-validate data insertion.
.

And that's it. Hope this helps you in your Projects. Thanks 😉

Add Google reCAPTCHA v2 to plain HTML

Huzaifa Rasheed — Sat, 12 Feb 2022 19:10:08 +0000

What is it?

A CAPTCHA is a test that helps to tell the difference between a bot and a human.

The reCAPTCHA is Google's implemenation of a CAPTCHA. Its very easy to integrate, without any third party libraries.

What's The Purpose?

A reCAPTCHA can keep malicious software/bots from engaging in abusive activities on your website while allowing legitimate users access to your site.

How to Integrate?

We will be using the v2 version.

1. Create a site key
You can create a site key from Google reCAPTCHA Admin Page.

You also will need to add a site domain, where you would deploy the site. For testing you can add localhost and use the loopback address (127.0.0.1) or use a key from reCAPTCHA automated tests guide. One of those keys is

6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI

which we will use in our example.

2. Add Widget to Markup
The only thing we will need to add to our HTML is

<div
  class="g-recaptcha"
  data-sitekey="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"
>
</div>

this can be added to a form or used without one, depending on the use case. Source

We will also need to add a cdn link to the head tag.

<script src="https://www.google.com/recaptcha/api.js" async defer>
</script>

We can listen to callbacks from the widget and register our own handlers.

<div
  class="g-recaptcha"
  data-sitekey="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"
  data-callback="onRecaptchaSuccess"
  data-expired-callback="onRecaptchaResponseExpiry"
  data-error-callback="onRecaptchaError"
>
</div>

these callbacks can be used to validate or invalidate our form or whatever we want to do.

I made a simple form that submits successfully when the reCAPTCHA validates successfully, its here. I also added some basic styling to have a decent look and feel.

Hope this helps you in your Projects. Thanks for reading 😉.

How do abstract Socket.IO connections in your SPA.

Huzaifa Rasheed — Thu, 10 Feb 2022 18:49:58 +0000

When working with socketIO client in your SPA, it may become very hard to manage the socket instance, events emitters, and work with the callbacks in different places of the app. Especially when there are multiple different servers to connect with. What can be done?

Solution

We can create a closure that takes event callbacks as functions and return event emitters, to abstract socketIO implementation in a single file (let's call it SocketManager.js).

Example

import io from "socket.io-client";

const SocketManager = ({
  onCallback = () => {},
}) => {
  const socket = io(/* server url to connect */);

  // Callbacks
  socket.on('callback-event-name', (payload) => {
    onCallback && onCallback(payload);
  });

  // Emitters
  const emitEvent = (eventPayload) => {
    socket.emit('emit-event-name', eventPayload);
  };

  return {
    socket,
    emitEvent
  };
};

export default SocketManager;

then we can use this in our React code like this

import React from "react";
import SocketManager from "./SocketManager.js";

const SocketConsumer = () => {
  const { emitEvent } = SocketManager({
    onCallback: handleCallback,
  });

  const handleCallback = (payload) => {
    /** Do something with the payload */
  };

  return <button onClick={emitEvent}>Fire Event</button>;
};

export default SocketConsumer;

Hope this helps you in your projects. Thanks 🙂

Regex? The Minimum You Need To Know.

Huzaifa Rasheed — Tue, 06 Apr 2021 21:59:35 +0000

You might have noticed when filling out an online form for email or password, you sometimes get validation errors like email must be valid or password must be 8 digits long. Something like this 👇

These are places where REGEX is used.

What Is Regex?

Regex is short for Regular Expressions.

A sequence of characters that specifies a search pattern. These patterns are mostly used by string-searching algorithms to find or find and replace character/s. Thus they can be used for validations and mostly you will be using Regex for them.

How To Use Regex?

You can use different functions for matching regex with your data. In PHP there are functions starting with preg_ that mostly match regex (see Regex for Php) while In JavaScript, regex are also objects. You can see some of the regex functions for JavaScript on Javascript Regex Guide.

Basic Validations

There are a number of online regex engines that you can use to quickly test out your regex expression. I mostly use Regex101 because I like it. The following examples are tested on Regex101.

Email

/^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

Password

Minimum eight characters, at least one uppercase letter, one lowercase letter, and one number

/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)[a-zA-Z\d]{8,}$/

For more password validations, Check out the answer on stackoverflow

Numbers Only

To match 0 or many numbers
/^[0-9]*$/

To match 1 or many numbers
/^[0-9]+$/

To match exactly 1 number
/^[0-9]$/

If you add one more number in the test string, the validation will fail.

Phone Numbers Only

This is a little difficult to explain as different countries have different phone numbers, codes, etc., you know what I am talking about.

For my number, and I have an 11 digit number(Pakistani Phone Number), I use the following regex
/^((\+92)|(0092))-{0,1}\d{3}-{0,1}\d{7}$|^\d{11}$|^\d{4}-\d{7}$/

It validates the phone number with and without the country code like the following do pass

00923000000000
+923000000000
03000000000

I would suggest that for a good reference, check out Google's Library for validating international phone numbers. This is not regex but it gets the job done if are on the run.

Characters Only

To match for 1 or many characters
/^[A-Za-z]+$/

To match 0 or many characters you can use /^[A-Za-z]*$/
To match exactly 1 character you can use /^[A-Za-z]$/

Of course, there are other combinations you can explore.

URL Matching

The following will mostly match the URLs you want to
^(?:(?:https?|ftp):\/\/)(?:\S+(?::\S*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)(?:\.(?:[a-z\u00a1-\uffff0-9]-*)*[a-z\u00a1-\uffff0-9]+)*(?:\.(?:[a-z\u00a1-\uffff]{2,}))\.?)(?::\d{2,5})?(?:[/?#]\S*)?$

This however does not match port numbers, Like it would not match https://regex101:9000.com/?page=1. So you should have a general idea of what type of URL you want to match.

I suggest seeing Regex For URL that has different implementations of Php and Js that you can play with.

Which Language Supports Regex?

Almost every major language has support for regex.

To be more clear, implementations of regex functionality are called a regex engine, and a number of libraries are available for reuse which different languages do use.

Regex syntax may vary slightly between languages but for the most part, it is the same.

Now Some Theory.

Fun is over guys, now we are moving towards the theory. Jokes aside, Most of you don't need to know everything about regex in detail, the same with a programming language, we can't learn everything about them.

But you should know that 👇

A Regex can have

Tokens
Anchors
Meta Sequences
Quantifiers
Group Constructs
Character Classes
Flag/Modifiers
Substitution

If you want to learn and practice them at the same time then I would again suggest, goto Regex101. It has a good reference for the regex operators. 👇
and I think I don't need to explain more 😉

Fun Part While Writing The Article

I found a regex from StackOverflow that was matching non-ASCII characters and it matched every word I tried of any language. Even in my native language Urdu it matched اِسلامی جمہوریہ پاكِستان

I don't know if it's useful or not, but I will add it in the comments.

Tip

More like a best practice. You should do regex validations on both the frontend and backend of your code. Just in case someone tries to manipulate the frontend, your backend will not validate the invalid data.

Note: You can also use HTML5 Input Types for validating some form fields on the frontend, but for the backend you need regex.

Conclusion

So did you use regex for a complex match sometime or you just got to know about it? Also, give a 💖 or a 🦄 if you like the article.

Solid. Is It Still Useful In 2021?

Huzaifa Rasheed — Sat, 03 Apr 2021 22:52:30 +0000

Why Even Bother?

In the software development world, there are 2 extremes.

People who don't follow best practices.
People who follow them to the extreme.

If you are lazy like me you mostly don't follow best-practices because YAGNI(You aren't gonna need it) but if you are like me you mostly do follow best-practices like SOLID Design Principles.

Wait. Why am I on both sides? Because I follow both depending on what I am doing. If it's simple, limited/scoped, and predictable then who needs to overthink about best practices but if it's complex, may-become-complex, should be scalable and maintainable then yeah, we need best practices.

If you are building a system that would need changes in the future then you are going to be happy about how SOLID can make your life easy.

What is SOLID?

SOLID is an acronym for 5 principles

S. 👉 Single Responsibility
O. 👉 Open/Close
L. 👉 Liskov Substitution
I. 👉 Interface Segregation
D. 👉 Dependency Inversion

They aim to make your code manageable, maintainable, and scalable along with other benefits.

Note

They are not Rules, but best practices.

The Person Behind SOLID

This was in the year 2000. Robert C. Martin first introduced SOLID as a subset of different design principles in his paper Design Principles and Design Patterns.

Design principles and patterns are different, SOLID are principles.

So What Do The Principles Mean?

Each SOLID principle aims to achieve a certain goal by following a certain rule.

1. Single Responsibility Principle

It aims to separate behaviors or concerns. Meaning that every piece of code should have a specific purpose of existence and it should be used for that purpose only.

Example

The following function should only validate a user given their id.

function validateUser(userId){
    // will validate user with their userId
}

For a complete reference, check out the Single Responsibility Principle in detail.

2. Open/Close Principle

The goal is to prevent those situations in which changing a piece of code from a module also requires us to update all depending modules. Basically, we don't allow new code to make changes to our old code.

We can extend code but not modify it. One real-life use case is of those softwares that have backward compatibility.

Example

A typescript example

interface PaymentMethod {
  pay() : boolean
}

class Cash implements PaymentMethod {
  public pay(){
    // handle cash pay logic here
  }
}

function makePayment(payMethod: PaymentMethod) {
  if(payMethod.pay()){
    return true;
  }
  return false;
}

In the above code if we want to add credit card payment all we have to do is add the following code (along with the actual implementation) and it will work just fine

class CreditCard implements PaymentMethod {
  public pay(){
    // handle credit pay logic here
  }
}

For a complete reference, check out my other article on Open/Close Principle.

3. Liskov Substitution Principle

What this principle tells us is that if we replace an instance of a child class with a parent class, our code should still work fine without breaking or having side effects.

Example

class Printer{
    function changeSettings(){
        // common functionality
    }

    function print(){
        // common functionality
    }
}

class LaserPrinter extends Printer{
    function changeSettings(){
        // ... Laser Printer specific code
    }

    function print(){
        // ... Laser Printer specific code
    }
}

class _3DPrinter extends Printer{
    function changeSettings(){
        // ... 3D printer specific code
    }

    function print(){
        // ... 3D printer specific code
    }
}

This principle however has its limitations some of which I discussed in its own separate article. See Liskov Substitution Principle for an example of its limitations.

4. Interface Segregation Principle

This principle aim's to use role interfaces (or role modules in general) which are designed for a specific purpose and should only be used for those. It says

Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

This principle solves some of the issues with the Interface Segregation Principle like the Bird example I mentioned in my article on Liskov Substitution Principle

Example

This is a typescript example but still not too difficult to understand.

interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck implement BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich implement BirdWalk{
    walk(){
        // Ostrich can walk
    }
}

For a complete reference, check out the Interface Segregation Principle in detail.

5. Dependency Inversion Principle

It focuses on using abstraction or facade/wrapper patterns to hide details of low-level modules from their high-level implementation.

We basically create wrapper classes that sit in between high-level and low-level modules. This helps a lot if the low-level implementations are different from each other.

Example

Again a typescript example

interface Payment {
    pay(): boolean
}

// (Wrapper/Abstraction around cash payment)
class CashHandler implements Payment {
    constructor(user){
        this.user = user
        this.CashPayment = new CashPayment();
    }

    pay(amount){
        this.CashPayment.pay(amount)
    }
}

// (low-level module)
class CashPayment {
    public pay(amount){
        // handle cash payment logic
    }
}

// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

For a complete reference, check out the Dependency Inversion Principle in detail.

When To Use What And Avoid What

Now that we know a brief about each principle, we will look at when to use and avoid them.

	Use	Avoid
Single Responsibility	For Scalable and Maintainable Code.	When too much Fragmentation occurs without predictable future changes.
Open Close	To prevent old code from breaking due to a new one.	When over-engineering.
Liskov Substitution	Parent/Child used interchangeably without breaking.	When substitutions do not make sense. (Bird example)
Interface Segregation	For Role-specific interfaces.	When difficult to aggregate (due to a lot of modules) from segregation.
Dependency Inversion	For different low-level implementations.	When different implementations of a low-level module are not needed, like the String class in most languages are not changed because it's not needed to mostly.

These are mostly the reasons and you can disagree but it all comes down to what you are dealing with.

Is SOLID Still Useful in 2021?

Ask yourself. Is there a language that does everything with one line of code?

do_everything();

I guess not, unless you or someone makes a language that uses less code than python and does everything with one line of code, you do need SOLID design principles.

Of course, there are extremes and cases where it's just not possible to implement SOLID, but if you are comfortable and can use SOLID then you probably should.

Conclusion

So, what's your take on this? Do you follow an approach similar to mine? Be sure to give this article a 💖 if you like it.

Why The Dependency Inversion Principle Is Worth Using

Huzaifa Rasheed — Thu, 01 Apr 2021 22:13:51 +0000

Dependency Inversion is the D of SOLID, and you may wonder, what is SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

Rules and Conventions have their place. In code, the SOLID design is considered a convention/best-practice.

Now what is Dependency Inversion?

Basically

High-Level Modules Should Not Depend Upon Low-Level Modules. Both Should Depend Upon Abstractions.

Not too difficult. Right? Here is more

Abstractions Should Not Depend Upon Details. Details
Should Depend Upon Abstractions.

Too confusing? This might help

What This Means

✔️ Both High-level and Low-level modules should depend on the same Abstraction.
✔️ High-level modules should implement abstractions that implement Low-Level modules and vice-versa.
✔️ Abstractions can implement different details of the operation.
❌ High-level modules can implement details surpassing abstractions.

Goal

Follow an abstract/facade/wrapper pattern.
Hide Low-Level implementation from High-Level Implementation.

A Simple Use Case

We will continue with the payment example from Open/Close Principle. But for this example at the moment we only accept cash payment.

interface Payment {
    pay(): boolean
}

class CashPayment implements Payment {
    public pay(amount){
        // handle cash payment logic
    }
}

function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

In this particular example, makePayment() is a high-level module and CashPayment is a low-level module. It clearly has no wrapper/abstraction layer.

Now, what if we want to add credit card payment? We might modify our code like this

interface Payment {
    pay(): boolean
}

// (low-level module)
class CashPayment implements Payment {
    constructor(user){
        this.user = user
    }

    public pay(amount){
        // handle cash payment logic
    }
}

// (low-level module)
class CreditCardPayment implements Payment {
    constructor(user){
        this.user = user
    }

    public pay(amount, creditCardId){
        // handle creditCard payment logic
    }
}


// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){

    if(paymentMethod instanceof CashPayment){
        if(paymentMethod.pay(amount)){
            return true;
        }
    }

    if(paymentMethod instanceof CreditCardPayment){
        if(paymentMethod.pay(amount,paymentMethod.user.creditCardId)){
            return true;
        }
    }

    return false;
}

This clearly violates the Dependency Inversion principle since the high-level module is implementing details for low-level modules. It also violates the Single Responsibility Principle.

Using Dependency Inversion, we will make wrapper classes or abstractions around cash and credit payment implementations.

interface Payment {
    pay(): boolean
}

// (Wrapper/Abstraction around cash payment)
class CashHandler implements Payment {
    constructor(user){
        this.user = user
        this.CashPayment = new CashPayment();
    }

    pay(amount){
        this.CashPayment.pay(amount)
    }
}

// (low-level module)
class CashPayment {
    public pay(amount){
        // handle cash payment logic
    }
}


// (Wrapper/Abstraction around credit card payment)
class CreditCardHandler implements Payment {
    constructor(user){
        this.user = user
        this.CreditCardPayment = new CreditCardPayment();
    }

    pay(amount){
        this.CreditCardPayment.pay(amount, this.user.creditCardId)
    }
}

// (low-level module)
class CreditCardPayment {
    public pay(amount, creditCardId){
        // handle creditCard payment logic
    }
}


// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}

As we can see now our high-level modules are separated by an abstract layer hiding the details of low-level implementation. We inverted the dependencies.

Why Dependency Inversion is Worth Using?

Consider This

We want to add PayPal and WireTransfer Payment Options to our existing code (the example we just did). It can be done easily without touching our existing code. We only have to add low-level and wrapper implementations for PayPal and WireTransfer Payments. Thus, our High-level implementations never break since we are not touching it.

Also

We create resilient and reusable code.
Code that is easier to maintain.
Easier to test individual code components.
We prevent code breakages by not touching high-level implementation

The pattern for other SOLID principles like Interface Segregation and Liskov Substitution is much similar in terms of code breakages i.e : Avoid Them in the long run.

Here it is guys. Do you use Dependency Inversion? Be sure to tell me your opinion in the comments and give this article a Heart 💖 if you liked it.

Is It Practical To Use Interface Segregation Principle?

Huzaifa Rasheed — Wed, 31 Mar 2021 18:05:02 +0000

SOLID is a very popular design concept in programming. Interface Segregation is part of SOLID Design. You may ask, what is SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

In code, you have best-practices and rules. SOLID designs are like best-practices.

Interface Segregation

It says

Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

Pretty straightforward.

What This Means

✔️ Create smaller and specific interfaces (role interfaces).
❌ Classes can implement interfaces they don't use.

Why do this?

Consider

A client depends upon a class that contains interfaces the client does not use, but other clients do use, then the first client will be affected by the changes other clients force upon the class used by the first client.

The Goal of this principle is to avoid these situations.

The pattern for other SOLID principles like Single Responsibility and Open Close is much similar : To avoid code breakages in the long run.

A Simple Use Case

Using the Bird example much similar to that discussed in Liskov Substitution.

interface Bird {
  fly(): void;
  walk(): void;
}

class Duck extends Bird{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends Bird{
    fly(){
        // Ostrich cant fly... throw some error
    }   
    walk(){
        // Ostrich can walk
    }
}

Here fly() is enforced to an Ostrich class by the Duck class, since both implement the same interface and Duck does use fly(). It is a clear violation of the Interface Segregation Principle.

Using the Interface Segregation Principle we refactor our code to be

interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck extends BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich extends BirdWalk{
    walk(){
        // Ostrich can walk
    }
}

We have now made role-specific interfaces and there is no inadvertent coupling.

Is It Practical?

Definitely, It is best to follow this principle whenever possible. However, if your requirements are satisfied and you can work around the inadvertent coupling, then sure you can avoid this principle.

Do you use Interface Segregation? Be sure to tell me your opinion in the comments.

What's Next

Why The Dependency Inversion Principle Is Worth Using.

2 Simple Tips To Clean Nested IF/ELSE Conditions.

Huzaifa Rasheed — Tue, 30 Mar 2021 18:43:40 +0000

There might be a time when you have your if/else conditions like this

if(age>0){
    if(age < 18){
        return "Not an Adult"
    }
    else if (age >= 18 && age<60){
        return "An Adult"
    }
    else{
        return "Senior Citizen"
    }
}
else{
    return "Age must be a valid number"
}

This is however a simple example, this can get messy as your code logic gets complex.

To add more, Multiple nested if/else increases Cyclomatic complexity and it is better to avoid it whenever possible.

Cyclomatic complexity is a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. Thomas J. McCabe, Sr.

So what can you do to avoid it? Simple, Try to have fewer branches of if/else conditions achievable with the following tips.

The Tips

Guard Clauses
Ternary Operators

There are others like Switch Statement, Dictionaries, Jump Tables, etc. but those are beyond this article's scope.

1. Guard Clauses

In simple terms, return early if a condition is not met. Again taking our previous code, we can modify it like this

// Guard clause
if(age <= 0){
    return "Age must be a valid number" 
}

if(age < 18){
    return "Not an Adult"
}
else if (age < 60){
    return "An Adult"
}

return "Senior Citizen"

Or you could even do this

// Guard clause
if(age <= 0) return "Age must be a valid number"

if (age < 18) return "Not an Adult"
else if (age < 60)  return "An Adult"
else return "Senior Citizen"

Use brackets or not, scoped only to clean code.

2. Ternary Operators

Most of you already use them, but anyways. Modifying our last code

if(age <= 0) return "Age must be a valid number"

var res = (age < 18 ? "Not an Adult" 
        : (age < 60) ? "An Adult" 
        : "Senior Citizen")

return res

if(age <= 0) return "Age must be a valid number"

return (age < 18 ? "Not an Adult" : (age < 60) ? "An Adult" : "Senior Citizen")

Disclaimer: Clean code doesn't always mean Performant code or Simple Code. Sometimes you have to decide between one or the other. There is however a limit to how clean you can make your code.

So here it is guys, do you use any other method to clean nesting? Be sure to tell me in the comments.

Is The Liskov Substitution Principle Really Useful?

Huzaifa Rasheed — Mon, 29 Mar 2021 18:15:10 +0000

Liskov Substitution is part of SOLID Design. SOLID?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.

Think of them as best practices.

Now What is Liskov Substitution

You see the L in SOLID stands for this principle.

It says

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. Barbara Liskov

Honestly, Too scientific.

In simple terms

Replacing an instance of a class with its child class should not produce any negative side effects or broken codebase.

Meaning

✔️ Can use the subclass of a parent class just the same as using the parent class without breaking anything.
✔️ Subclasses can modify/override parent class methods.
❌ Subclasses can modify the parent's method signature like arguments, return type, and exceptions.
❌ Subclasses can define a new function not present in the parent class.
❌ Parent class can be modified.

Why do this?

The Goal of this principle is to basically prevent our old codebase from breaking due to new code. This is also in line with the Single Responsibility and the Open Close Principle.

We will use a simple example for explanation.

A Simple Use Case

The following example violates the rule.

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code

        //  voilating LSP: parnet sleep() does not return boolean
        return true 
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was tasty."    // return type string
    }

    function sleep(){
        // ... dog specific code

        //  voilating LSP: parent sleep() doesn't use Error Exception
        throw Error('I just slept') 
    }
}

With the Liskov Substitution Principle, we would modify our code as follow

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code
        return "I am already sleeping"  // return type string
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was actually tasty."   // return type string
    }

    function sleep(){
        // ... dog specific code
        return "Zzzzzzzz"   // return type string
    }
}

With this approach, we can swap parent and child classes without breaking the code.

So Is it Helpful?

It is in most cases, but there are those cases where you might want to add some more that does not quite fit in like the Birds example below

class Bird{
    function fly(){}
}

class Duck extends Bird{}

class Ostrich extends Bird{} // Duck can fly but ostrich cant:

So yeah, it really depends. If it's getting over-complicated/over-engineered or is not making sense(like bird example) then it's best to do your own thing.

Tip

It's easy to extend old code with new code. You just have to make a new class and extend it with parent/base class without the fear of breaking the already working code. We also get this benefit from Dependency Inversion principle.

So how do you see this? Do you think it's really useful? Be sure to tell me your opinion in the comments.

DEV Community: Huzaifa Rasheed

The Things We Own

Contents

Renting Isn't Bad

A House Is the Obvious Example

The Software You Rent

Own the File, Not the Feed

Careers Are Rented Time

The Next Thing Is Cheaper

Ownership Has a Maintenance Tax

Build an Exit Door

What Should You Actually Own?

Identity

Data

Skills

Content

A Place the Writing Stays

Some Infrastructure

Things That Make the Next Thing Easier

Rent Convenience. Own Leverage.

Valid Sudoku Algo - Leetcode

Algorithm (I followed)

Implementation (JavaScript)

Time complexity

Space complexity

Test Cases

How to Avoid Default Props Render Trap in React

What is it?

Why It Happens

The Solution

Running Batch Requests In Postman

Making Batch Requests in Postman

Add Google reCAPTCHA v2 to plain HTML

What is it?

What's The Purpose?

How to Integrate?

How do abstract Socket.IO connections in your SPA.

Solution

Example

Regex? The Minimum You Need To Know.

What Is Regex?

How To Use Regex?

Basic Validations

Email

Password

Numbers Only

Phone Numbers Only

Characters Only

URL Matching

Which Language Supports Regex?

Now Some Theory.

Fun Part While Writing The Article

Tip

Conclusion

Solid. Is It Still Useful In 2021?

Why Even Bother?

What is SOLID?

Note

The Person Behind SOLID

So What Do The Principles Mean?

1. Single Responsibility Principle

Example

2. Open/Close Principle

Example

3. Liskov Substitution Principle

Example

4. Interface Segregation Principle

Example

5. Dependency Inversion Principle

Example

When To Use What And Avoid What

Is SOLID Still Useful in 2021?

Conclusion

Why The Dependency Inversion Principle Is Worth Using

Now what is Dependency Inversion?

What This Means

Goal

A Simple Use Case

Why Dependency Inversion is Worth Using?

Is It Practical To Use Interface Segregation Principle?