DEV Community: Luka Peharda

How to write better

Luka Peharda — Wed, 17 Jun 2026 10:00:29 +0000

I don't consider myself a great writer. But I do consider myself a writer who cares. And that might be even more important.

I've been writing articles for a while now. Some are good. Some could be better. Some I'm proud of, most I'm ashamed of. But the articles that resonate most with readers aren't the ones with the fanciest words or the most perfect grammar. They're the ones that provide the most value.

And that's really the whole point, isn't it?

Value over everything

In order for your writing to improve, it needs to be valuable. And in order to be valuable to your readers, you need to know your readers.

Sure, it needs to be clearly written. Organized. And you need to appear knowledgeable and persuasive. But if it does not have any value for your readers, they won't be willing to read it.

What does that mean, to know your readers? You need to imagine who they are. Are they experts? Novices? Your friends? Your colleagues? Are they senior developers with 15 years of experience, or junior devs just starting their first job?

I write primarily for developers like me. People who care about building good software, who want to learn, who appreciate a practical example over a theoretical lecture. And that shapes everything I write.

Your work does not have to be original

You don't have to be the first person to ever write about a topic. You don't have to invent a new programming paradigm or discover a revolutionary concept. Most of the best articles I've read aren't groundbreaking, they're just really good explanations of existing ideas. Or just written in a way that resonates with me better.

What you do need to do is provide value. Your writing needs to change the way your readers think about a problem. It needs to help them see something differently, understand something more deeply, or apply something more effectively.

Think of it this way: you're not a researcher discovering new truths. You're a guide helping others navigate truths that already exist.

Write to change minds, not to explain

In school, we're taught to write to explain. We're taught to write so that our teachers can see if we understood the matter. We're not taught to provide value to our teachers. Or to our classmates. Or to anyone else, really.

But that's not how good writing works. Good writing isn't about proving you understand something. It's about helping someone else understand something.

So don't write to explain. Write to change or shift perspectives. Write to make your reader think "Oh, I never thought of it that way before."

The structure that works

A simple structure that works for me is this:

Open with a problem

Start with something your reader is struggling with. A pain point. A frustration. Something that keeps them up at night (or at least makes their workday more annoying).

Then move to the solution

Not just any solution. Your solution. Your approach. Your hard-won wisdom. The thing you wish someone had told you when you were facing that same problem.

That's it. Problem, solution. It's simple, but it's effective.

You don't need a fancy introduction. You don't need to define every term. You don't need to provide a complete history of the topic. You just need to help someone solve a problem they actually have.

Write for yourself first

There's another aspect of writing that's often overlooked: writing for yourself.

As Addy Osmani writes in his excellent article Write Learn, writing is one of the best ways to learn. When you try to explain something to others, you force yourself to understand it more deeply. You spot gaps in your own knowledge. You clarify your own thinking.

So don't just write for others. Write for yourself. Write to learn. Write to clarify your own thoughts. The fact that others might benefit from it is just a happy side effect.

I've learned more from writing articles than I have from reading them. There's something about the act of putting your thoughts into words that forces clarity in a way that nothing else does.

The courage to explain who you are

"We write for the same reason that we walk, talk, climb mountains or swim the oceans - because we can. We have some impulse within us that makes us want to explain ourselves to other human beings. That's why we paint, that's why we dare to love someone - because we have the impulse to explain who we are. Not just how tall we are, or thin... but who we are internally... perhaps even spiritually. There's something, which impels us to show our inner-souls. The more courageous we are, the more we succeed in explaining what we know." -- Maya Angelou

That's the thing about writing. It's not just about the information. It's about the person behind the information. It's about your unique perspective, your experiences, your voice.

And that's what makes it valuable. Not the perfection of the prose. Not the length of the article. Not the number of fancy words you use. But the authenticity of the person writing it.

Practical tips that actually work

Okay, enough philosophy. Let me give you some practical advice you can actually use.

Before you write

Pick one idea. As I wrote in my article One idea, one article, trying to cram too many ideas into one article is like stuffing 10 clowns into a tiny car - chaos!

One clear idea. One focused article. That's the way to go.

Know your audience. Who are you writing for? What do they already know? What do they need to know? What problems are they facing?

The more specific you can be about your audience, the better your writing will be.

While you're writing

Write like you talk. Your writing should sound like you. Not like a corporate press release. Not like a academic paper. Like you, talking to a friend.

Use simple words. Use short sentences. Don't try to sound smart. Try to sound clear.

Use examples. Nothing makes a concept clearer than a good example. Especially in technical writing. Show code. Show your real-world scenarios. Show what happens when things go wrong.

People remember stories and examples long after they've forgotten the theory.

Be honest. Don't pretend to know things you don't. Don't be afraid to say "I don't know" or "I'm not sure about this part."

Readers appreciate honesty. They can spot BS from a mile away. And they respect authenticity.

After you write

Edit ruthlessly. Your first draft is for you. Your second draft is for your readers.

Cut anything that doesn't add value. Remove filler words. Shorten long sentences. Break up long paragraphs.

Ask yourself: does this sentence add value? If not, cut it.

Read it out loud. This is one of the best editing tricks I know. If it sounds awkward when you say it, it'll read awkward when someone else reads it.

Get feedback. Show your writing to someone else. Ask them: does this make sense? Is it valuable? What's confusing? What's missing?

You don't need a professional editor. You just need someone who's willing to give you honest feedback.

What about SEO and all that?

I'm not writing for Google. I'm not writing for robots. I'm not writing for SEO.

I'm writing for you, and me.

Does that mean I ignore SEO completely? No. I still use descriptive titles. I still use clear headings. I still try to make my articles discoverable.

But I don't let SEO dictate what I write or how I write it. I don't stuff my articles with keywords just to rank higher. I don't write 3,000-word epics just because Google supposedly prefers long content.

I write articles that provide value. And if Google rewards that, great. If not, I still have the satisfaction of knowing I helped someone.

The most important rule

Here's the most important rule of writing: write.

Not "write perfectly." Not "write when you have time." Not "write when you feel inspired."

Just write.

The best way to become a better writer is to write. A lot. Consistently. Even when it's hard. Even when you don't feel like it. Especially when you don't feel like it.

You don't need to publish everything you write. You don't need to show it to anyone. But you do need to write.

Because here's the thing, you can read all the articles about writing. You can watch all the videos. You can take all the courses. But none of that will make you a better writer. Only writing will.

Why write at all?

Good question. Why should developers write?

This article from Evil Martians covers it well, but here are my reasons:

It helps you learn. As I mentioned earlier, writing forces you to clarify your thoughts and identify gaps in your understanding.
It helps your career. Developers who can communicate well are more valuable. They get promoted faster. They get better jobs. They have more influence.
It helps others. Every article you write has the potential to help someone else. To save them time. To save them frustration. To help them avoid a mistake you made.
It helps the community. The developer community thrives on shared knowledge. Every article, every tutorial, every Stack Overflow answer makes us all better.

Do We Still Need NoSQL in 2026?

Luka Peharda — Mon, 23 Feb 2026 07:06:17 +0000

I graduated university in 2007. Back then, databases meant one thing: tables, rows, and relationships. A user has orders. Orders have products. Everything is connected, and you draw those connections carefully on a whiteboard (or a notebook) before you write a single line of code.

That's just how data works, right? Things in the real world are related to each other. It makes sense to model that. Similar how classes in OOP are a natural way to model real-world entities, relational databases felt like the natural way to model real-world data.

Then NoSQL came along. Suddenly, you could just throw data into a big flexible blob without worrying too much about structure or relationships. It was like someone had looked at a filing cabinet and said "what if we just used a pile on the floor instead?"

Maybe that's my bias showing, or my old age. But I've been sitting with this question for a while now: do we actually need NoSQL databases in 2026, or have I just not updated my thinking since 2007?

Let me try to work through it "on-paper" here.

What even is NoSQL?

If you're not a developer, here's the short version. A traditional relational database (like PostgreSQL or MySQL) stores data in structured tables, kind of like spreadsheets, and lets you link those tables together. NoSQL is a term for databases that don't do that. They store data differently, often as flexible documents (imagine JSON files), key-value pairs (like a dictionary), or other formats.

The pitch for NoSQL is roughly: more flexibility, easier to scale to massive amounts of data, no need to define your structure upfront. This "no need to define structure" was a big part of the appeal. Just throw data in and figure out how to use it later.

Where NoSQL makes sense

When speed is everything and the data is simple. Think of things like a leaderboard in a game, user session data, or a cache. You're not doing complex queries, you just need to store something and retrieve it incredibly fast. Key-value stores like Redis are brilliant at this. A relational database would be overkill.

When your data doesn't have a fixed shape. Imagine a product catalog where a t-shirt has "size" and "color" attributes, but a laptop has "RAM", "CPU", and "screen size". These are very different. Forcing them into the same table structure is awkward. A document store like MongoDB lets each product just be what it is.

When you're dealing with enormous scale across multiple regions. Big tech companies (think Amazon, Netflix, or Facebook) have data spread across data centers all over the world. Some NoSQL databases are specifically built to handle that kind of scale, accepting some trade-offs (like the data not being perfectly up-to-date everywhere at all times) to stay fast.

For highly connected data, like social networks. Ironically, one area where NoSQL really shines is relationships, but a specific kind. Graph databases (like Neo4j) are built to answer questions like "who are the friends of my friends who also like jazz?" across millions of people. A relational database can do this, but it gets slow fast.

So yes, there are real use cases. But those use cases are pretty specific. They're not the kind of thing most apps need.

But here's where my head still hurts

The thing is, most apps aren't Netflix. Most apps I've worked on, and most apps most developers build, have data that is relational. Users have profiles. Profiles belong to organizations. Organizations have subscriptions. Subscriptions have invoices.

That stuff has relationships. And relational databases were literally invented to model exactly that.

When I look at a NoSQL document store handling that kind of data, I often see one of two things. Either the data ends up duplicated everywhere (the user's name stored in fifty different places), or the app code ends up doing the work that the database used to do - manually stitching data together, checking consistency, making sure nothing gets out of sync.

That's not a win. That's moving complexity from a place designed to handle it (the database) to a place that's much worse at handling it (your application code, written by humans, at 11pm, day before Black Friday).

Meanwhile, relational databases haven't been standing still

This is something I think gets missed in the NoSQL conversation. Tools like PostgreSQL have been quietly adding features that close the gap significantly.

For example - PostgreSQL has a column type called jsonb that lets you store flexible, document-like data inside a relational database. So you can have the best of both worlds - structured, relational data where you need it, and flexible blobs where you don't. And all of that in one place, with proper transactions and data integrity guarantees.

Modern relational databases can also handle a lot more scale than people give them credit for. The "NoSQL scales better" argument made a lot of sense in 2010. In 2026, it's a much more nuanced picture.

The honest downsides of NoSQL

I want to be clear I'm not just being a grumpy old dev here. There are real trade-offs with NoSQL that don't always get talked about enough.

You lose consistency guarantees. Many NoSQL databases are "eventually consistent," which means for a short time, different users might see different versions of the data. For some apps that's fine. For anything involving money or critical records, it can be a serious problem.

You become responsible for your data's integrity. Relational databases enforce rules. For example, you can't link an order to a user that doesn't exist. With many NoSQL databases, that's your problem now. One bug in your code and you've got orphaned, inconsistent data with no safety net.

Flexible schemas are a double-edged sword. Yes, it's nice to not have to define everything upfront. But six months into a project, when your documents all look slightly different because three developers made different assumptions, you'll wish someone had drawn a schema on a whiteboard.

Querying can get awkward. SQL (despite its age) is a remarkably powerful and expressive way to ask questions of your data. Equivalent operations in some NoSQL databases require more code, more effort, and sometimes just aren't possible at all.

So where does that leave me?

Honestly? Still pretty relational in my thinking. And I think I'm okay with that. At least for now, until I get a project that genuinely needs NoSQL's strengths.

I don't think my instinct to model data as interconnected things is a limitation from my education. I think it reflects something true about how a lot of real-world data actually works. And relational databases are really good at modeling that.

Does that mean I'd never use NoSQL? No. But I'd want to be very sure I needed it before I went down that path.

My overall take: if you're building most apps, a well-used PostgreSQL database will take you further than you think, for longer than you think, with fewer surprises than you think. And if you ever genuinely outgrow it, you'll know. And the NoSQL option will still be there and you'll be able to migrate your data if needed.

I just wouldn't start there.

Why I Hate Black Fridays: A Developer's Thurs-dread Manifesto

Luka Peharda — Thu, 28 Nov 2024 10:00:13 +0000

Let's get one thing straight: I'm not a discount-hating Grinch.

As a consumer, I love a good bargain. As a developer, I'm all for spreading some financial joy through product discounts. But there's a special circle of software hell reserved for the Thursday before Black Friday – what I've christened "Thurs-dread" (get it? Thursday + dread? I'll wait while you appreciate my linguistic genius).

Picture this: It's the day before retail's version of the Hunger Games, and I'm sitting at my keyboard, happily clacking on my keyboard introducing bugs into the codebase, bracing for the annual software circus of discount madness.

Survival Strategy #1: The Mythical Universal Checkout System

Some naive souls might suggest building a checkout system so robust it could handle every possible discount scenario. Ha! If only.

The moment you think you've created the software equivalent of a puzzle with no solution, the marketing team swoops in with ideas so wild they'd confuse a GPS.

Survival Strategy #2: The Pre-Emptive Interrogation

Asking the product team about their Black Friday plans a month in advance? That's cute. They'll look you dead in the eye and swear nothing special is happening. Cut to three weeks later – their inboxes are overflowing with promotional emails, and suddenly they've transformed into discount innovation machines.

It's like watching a mild-mannered IT guy turn into a used car salesman overnight.

My Coping Mechanisms: A Tragicomedy in Multiple Acts

The Therapeutic Article

Writing about my frustrations publicly. Sometimes, shouting into the void feels good. This very article serves as Exhibit A.

The "Yes, But" Diplomatic Dance

The art of agreeing while meticulously documenting why their last-minute request is about as feasible as teaching a cat to juggle. Success rate? A solid 50%. Not great, not terrible.

The Passive-Aggressive Emoji Ballet

Responding with a barrage of cheerful emojis while internally crying. 🌈😄🎉

Jokes aside, I work with an incredible team who actually listens and tries to meet me halfway.

So, fellow developers and discount warriors: How do YOU survive the Thurs-dread?

When does the TDD approach make sense?

Luka Peharda — Thu, 17 Oct 2024 07:29:01 +0000

I don't like writing tests. But I like having tests. They give me a sense of security and confidence that my code works as expected.

I never bought into TDD practices.

I know the approach can be very useful and in the long run it can save you time and money. But there is always a time pressure when developing features and not enough time to write tests.

But I always start with TDD when I need to develop a feature that will require me to test a lot of different variants and edge cases, and especially when there are a lot of clicking and moving parts and especially when external platforms and APIs are involved.

Adding Order::nextPaymentAmount method

Let me give you an example from the project that I'm working on.

I had to add a method nextPaymentAmount to the Order class which would return the amount of the next recurring payment.

Payment can be a one-time, a subscription, or installment plan. It can have setup fees and trials. It can have discounts and coupons. Coupons can be applied only to the first payment or to all recurring payments as well. It can have taxes. It can have a lot of different scenarios.

A lot of unnecessary clicking to test all of these combinations manually.

TDD to the rescue

In scenarios like above, I always use TDD and it saves me incredible amounts of time.

I'm not strictly adhering to TDD practices. I skip steps.

First, I write down all test cases that I can think of.

class NextPaymentAmountTest extends TestCase
{
    ...

    public function testOneTimePaymentHasNoNextPayment(): void
    {}

    public function testSubscriptionHasNextPayment(): void
    {}

    public function testSubscriptionWithSetupFeeHasNextPaymentWithDifferentAmount(): void
    {}

    public function testSubcriptionWithBasicCouponHasNextPaymentWithoutDiscount(): void
    {}

    public function testSubscriptionWithRecurringCouponHasNextPaymentWithDiscount(): void
    {}

    ...
}

Then I focus on a single case.

...

public function testOneTimePaymentHasNoNextPayment(): void
{
    // Arrange
    $pricingPlan = factory(PricingPlan::class)->create([
        'type' => 'one-time',
        'amount' => 100
    ]);

    $order = factory(Order::class)->create([
        'pricing_plan_id' => $pricingPlan->id,
        'member_id' => $this->member->id,
        'membership_id' => $this->membership->id
    ]);

    // Act
    $nextPaymentAmount = $order->nextPaymentAmount();

    // Assert
    $this->assertEquals(0, $nextPaymentAmount);
}

...

At first, test fails because the function that I'm testing (Order::nextPaymentAmount) is not yet implemented. Then I implement it just so the test passes.

Each test case is a small step towards the final implementation and adds a bit of code or conditional.

Usually, as I go along these cases and write code to pass them, I find a lot more edge cases that need to be covered.

Using this iterative approach I'm positive that I've covered most of the possible scenarios. And more importantly, I wasn't overwhelmed with "loading" all edge cases in my head before implementing the feature.

TDD not only saved me a lot of time, but gave me confidence that the feature works as expected. And that it will work as we extend it in the future.

Code refactoring: what is it and why should you do it

Luka Peharda — Thu, 28 Mar 2024 10:28:47 +0000

There is a lot of talk and mention of refactoring in developer communities. But what is it exactly?

Some use refactoring as an insult - meaning your code is bad and it needs refactoring. Others use it as an excuse - meaning my estimations were wrong because I needed to refactor legacy code or when regression bugs happen because they were “refactoring” code.

What is refactoring

Refactoring is the art of restructuring existing code without changing its external behavior. And this distinction without changing is really important.

Refactoring shouldn't be done while you are adding new features to the code. First, refactor old code and then proceed with adding a new feature.

Martin Fowler says that refactoring is a "series of small behavior-preserving transformations". And if he says so then who are you (or me) to question that 🫣

He continues that "each transformation does little, but a sequence of these transformations can produce a significant restructuring."" By making small changes it is less likely you'll break things.

Refactoring should not be a separate task that we'd add once in a while to our TO DO list. It should be a part of day-to-day programming.

Why should you refactor your code?

You should consider refactoring as a part of your code hygiene - similar to washing your teeth or washing your hands. You don't question why - you just do it.

Enhance readability and maintainability

Easier to read code is easier to fix. Both by you and your colleagues. You know, code is read more than it's written so it is important to be easy on the eyes.
The best way to learn the value of simple code is to be the person who has to pick it up again several months (or years) after it was written. Preferably in an emergency where you have to make and deploy a change very quickly, and also be confident that you're not going to take the system down.

Improve extensibility and maintainability

Well-factored code is like Lego blocks. Easy to add a new feature to it, or to remove it if you don't need it anymore.

Increase performance

Sometimes, by simplifying code, you inadvertently or intentionally fix an issue which improves performance.

Reduce technical debt

Technical debt refers to accumulated code issues that make future development harder.

Refactoring helps you pay down this debt by fixing issues like duplicate code, unused variables, and poor naming conventions.

However, refactoring shouldn't be done for its own sake.
Always have a clear goal in mind, such as improving readability, fixing a bug, or adding a new feature.

I'm giving a talk at the Weblica conference about code refactoring so if you are interested in learning more, do come by. This will be my first talk at a conference (I'm not counting meetup talks) and I hope it will be both informative and amusing.

Use EXISTS instead of COUNT > 0 when checking if records exist

Luka Peharda — Wed, 14 Feb 2024 10:07:00 +0000

TL;DR Use exists when querying if SQL records exists instead of using count. exists is much more efficient and breaks out of the loop when first record is found.

Using `count`

Until recently, when I had to check if a DB record that satisfies some conditions exists, I’ve used a count and then check if returned result is greater than 0.

Plain SQL query:

SELECT COUNT(*) 
FROM `post_likes`
WHERE `member_id` = 1
AND `post_id` = 1

Extra tip: MySQL has `COUNT() optimised and it is faster and more efficient than using COUNT(id)` for example.*

Laravel Eloquent query (using postLikes relationship):

// Did member like a post
$member->postLikes()->count() > 0;

Extra tip: notice the brackets after postLikes() relationship name. This means we are using the relationship to generate query on the related table and setting up foreign key for us. If we used $member->postLikes->count() , without the brackets, we would fetch all related records and then do a count afterwards. This would result in a much costlier DB query, and more memory used as all those records needs to saved to memory.

This would “force” a DB to count through all of the records that satisfies these conditions. And if your table is large enough it could take some time. Granted, probably in milliseconds but still it would do unnecessary work as it does not know that you are just interested in “existence” of the record and not the exact count.

Of course, if you indexed the table “properly” and use a composite index on member_id and post_id columns result would be pretty fast in this scenario but in some others it still may be optimised.

Using `exists` subquery

Better way would be to use an exists subquery. This is available in MySQL from version 5.7 so there is no reason not to use it.

You can check MySQL docs on EXISTS here. There is also NOT EXISTS subquery if you want to query for inversion.

EXISTS works by encapsulating a query in SELECT subquery:

SELECT EXISTS(
    SELECT *
    FROM `post_likes`
    WHERE `member_id` = 1
    AND `post_id` = 1
)

Doesn’t matter if your SELECT fetches all columns (`) or plain 1` , SELECT will be discarded in EXISTS query.*

This query will return true if subquery has at least one record or false if there are no records that satisfies your conditions. MySQL will break out of the “loop” when it finds the first record and this is what makes it more performant than the COUNT.

In Laravel you can use exists method on the query builder:

// Did member like a post
$member->postLikes()->exists();

Eloquent will encapsulate the query in the EXISTS subquery.

Eloquent also provides whereExists , whereNotExists , doesntExist, withExists and several more to allow you to build a query that you need.

Proper example of using `exists`

I’ve been using this to check existence of all kinds of records and relationships. Like permissions, likes and even as a nested subquery.

For example, when fetching a list of posts to display on the page, I want to know if member did like a post in order to show a proper UI icon. This could lead to a N+1 situation where for each post we’d have to do a separate SQL query to check if record exits.

Or we can use EXISTS subquery:

SELECT `id`, `title`, `content`, exists(
    SELECT *
    FROM `post_likes`
    WHERE `posts`.`id` = `post_likes`.`post_id` 
    AND `member_id` = 1
) AND `is_liked`
FROM `posts`

This will be done in a single optimised SQL query and provide information if member liked a post in a generated is_liked column. To be precise, MySQL will do N+1 subqueries to check for existence but this will be optimised and done internally.

In Laravel you’d use withExists to do the same thing:

$posts = Post::query()
    ->select(['id', 'title', 'content'])
    ->withExists(['postLikes as is_liked' => function ($query) use ($member) {
        $query->where('member_id', $member->id);
    });

is_liked will be added as an attribute on each $post model.

This optimisation may not seem as important and it may look like a “micro” improvement. But if your tables have millions of records then you already know that every millisecond counts.

Using Tailwind CSS classes in markdown

Luka Peharda — Wed, 01 Nov 2023 07:10:34 +0000

One of the biggest reasons why I moved my blog from Gatsby to Astro was its markdown integration and ease of creating new articles using markdown syntax.

Not only markdown but MDX - using JSX and component imports in markdown content.

Using Tailwind CSS typography plugin
As my blog is built using Tailwind CSS, content for the blog articles were also using Tailwind’s classes to style it. This means that instead of using regular

<p>

tags I’m using

<p class="pb-3 text-slate-400 text-xl">

to create a “simple” paragraph. As you can see this isn’t really simple nor does it enable me to write articles fast.

Not that the speed of converting my thoughts and ideas into HTML markup was my biggest problem.

Sensible person would use Tailwind’s typography plugin to style all content markup using CSS classes on the markdown content parent element. Their page even says that the plugin’S intended use is to to add beautiful typographic defaults to any vanilla HTML you don’t control, like HTML rendered from Markdown.

How would the paragraph look like using Tailwind’s prose classes?

<article class="prose prose-p:pb-3 prose-p:text-slate-400 prose-p:text-xl">

You’d have to add modifiers to the parent element class attribute. And repeat those modifiers for all other “target” like a, h1, h2, ul and all others.

And you’d have to reset some of the defaults that typography plugin brings to the table. It looks less and less as a sensible solution. Right?

Assigning Custom Components to HTML elements
Fortunately smart folks from MDX were already thinking of scenarios like that.

That is why you can import your custom component and then export a components object that maps the standard HTML to your custom component:

import Paragraph from '../components/Paragraph.astro';
export const components = {p: Paragraph}

This will be styled custom paragraph.
Paragraph.astro component is pretty simple:

<p class="pb-3 text-slate-400 text-xl">
    <slot />
</p>

is where the “child” content (paragraph’s text) will go.

This whole article was written using standard markdown syntax with styling applied by overwriting the HTML with custom components. I must say that the speed of writing this article surprised even me. Whole article was written in VS Code without any need for custom HTML markup nor CSS nor messy copy/pasting from older articles.

Now I’m off to find a good VS Code extension for Grammarly so I literally don’t have to use any other tool to publish an article.

To learn more, visit Astro’s Markdown Content guide or MDX Website for a full list of HTML elements that can be overwritten as custom components.

100 lines of code per file

Luka Peharda — Wed, 01 Nov 2023 07:05:31 +0000

It has gotten to my attention that one of the biggest dev agencies in the region has a pull-request requirement that checks whether each file committed is under 100 lines long.

It seems like a pretty stupid requirement, right?

Then I tried it.

I had a class that was 133 lines long and I want to see whether I can get it under 100. As the class was already “doing one thing” it didn’t make sense to refactor it and split it into two files.

First to go were the comments 😀 Method docblocks were replaced with proper type declarations and return types. To preserve the readability, variable and method names had to be changed to be self-explanatory although a bit longer. Conditionals were extracted into separate methods.

Multiple simple IFs were combined into one, which did hurt readability a bit but it saved 5 lines 😀

Somewhat duplicated code was extracted and parametrized which allowed me to reuse methods in several locations.

And I got to 99 lines 🚀

I was skeptical about this requirement when I started but now I see its benefits. It makes you think about your code a bit more and forces you to make it more readable while also removing clutter from your files. And as strange as this may sound, it was fun doing it 😆

100 lines of code per file

Luka Peharda — Tue, 25 Oct 2022 07:39:26 +0000

It has gotten to my attention that one of the biggest dev agencies in the region has a pull-request requirement that checks whether each file committed is under 100 lines long.

It seems like a pretty stupid requirement, right?

Then I tried it.

Multiple simple IFs were combined into one, which did hurt readability a bit but it saved 5 lines 😀

Somewhat duplicated code was extracted and parametrized which allowed me to reuse methods in several locations.

And I got to 99 lines 🚀

Unexpected benefits of estimations

Luka Peharda — Tue, 31 May 2022 08:42:03 +0000

I yet have to meet a developer that likes doing estimations. And don't get me started on sticking with them.

I get that they are necessary for management to make plans but that does not mean I have to like them or enjoy doing them. No matter how hard I try my estimations are never correct.

I've been using the three-point estimation technique lately.

Did you know you can use the estimation to jump-start and beat procrastination? No? Read on. You did? Well, why didn't you share it with me?

What is procrastination?

"Procrastination is the act of delaying or putting off tasks until the last minute, or past their deadline."

Why? I'll leave that up to you as each of us have a large number of different reasons for it.

In some cases, reasons for the procrastination can be because we don't know how to do something or even what needs to be done. Or we are intimidated by the size of the task in front of us. And this is where estimation kicks in!

How estimation can help?

Well, when doing an estimation you'll have to get all information on what it is that you are building. You'll have to fill all missing gaps and deal with all ambiguous requirements.

You'll split a large task into smaller manageable pieces. And you'll be able to procrastinate over a large number of smaller tasks.

By doing that, the task will be manageable and our motivation will slightly improve.

Additional benefits

Usually, the best cure for procrastination is to just start working. Doing as small a chunk of work as possible. Guess what? By doing the estimation you've done exactly that! You've started working on your task. And now nobody can stop you.

Not only that, but by providing the estimation number you'll be "going public" with it and now a much larger audience could "hold you accountable".

This article is a part of my personal pledge to write at least one article per month for a whole year. As you can see, I've written this article on the last day of May which means that I'm struggling with procrastination as well so if you know any good tips please let me know!

How to generate a full Tailwind CSS palette from a single color

Luka Peharda — Wed, 27 Apr 2022 06:07:55 +0000

You have an app where you allow users to select their brand color in order to style their website. Naturally, you use different shades of the color in your design - in some places you use ligher ones, and in other darker ones.

There are a lot of color generators and app that generate Tailwind CSS color palette for you. Here are some of my favorites:

Problem is, you want to have a simple UI and the thought of forcing users to select all possible shades gives you a headache.

Solution 1. "Opacity"

Official theming video from Tailwind CSS suggests adding a single (brand) color and then modify opacity (either text opacity or background opacity) to have lighter shades of your color.

<h1 class="text-brand text-opacity-75">Howdy</h1>

Under the hood Tailwind CSS uses CSS variables to modify alpha channel of the color (A in RGBA color model) which is pretty smart. Please watch the above YouTube video to see more detailed explanation but the gist of it is this:

.text-brand {
    --tw-text-opacity: 1;
    color: rgba(255, 255, 0, --tw-text-opacity);
}

This is fine and dandy but what to do when you want to have darker colors as well? You could start with a darker color and have a greater range. Can you tell your users to select "darker" color? No. You can't. You shouldn't.

Solution 2. "HSL"

For this reason I've been playing with HSL color model (where H stands for hue, S for saturation and L for lightness). By changing the L values (lightness) of a base color I was able to get OK looking palette for the whole range - both lighter and darker.

I've written a PHP package called Tailwind CSS Color Palette Generator to use exactly this to generate a full palette.

It is easy to generate a palette by specifying your base color:

use LukaPeharda\TailwindCssColorPaletteGenerator\Color;
use LukaPeharda\TailwindCssColorPaletteGenerator\PaletteGenerator;

// Create base color from hex
$baseColor = Color::fromHex('#ffff00');

// or from RGB
$baseColor = Color::fromRgb(255, 255, 0);

// or from HSL
$baseColor = Color::fromHsl(60, 100, 50);

// Generate a palette
$paletteGenerator = new PaletteGenerator;
$paletteGenerator->setBaseColor($baseColor);
$palette = $paletteGenerator->getPalette();

Generated $palette will be an array where keys are Tailwind CSS color steps and values Color objects:

$palette = [
    50 => Color,
    100 => Color,
    200 => Color,
    300 => Color,
    ...
];

You can then loop over it to generate CSS variables or use it anyway you see fit:

foreach ($palette as $key => $color) {
    echo '--color-brand-' . $key . ': #' . $color->getHex() . ';';
}

Extend color settings in your tailwind.config.js file and add brand color palette:

module.exports = {
    theme: {
        extend: {
            colors: {
                brand: {
                    50: 'var(--color-brand-50, #F5F3FF)',
                    100: 'var(--color-brand-100, #EDE9FE)',
                    200: 'var(--color-brand-200, #DDD6FE)',
                    300: 'var(--color-brand-300, #C4B5FD)',
                    400: 'var(--color-brand-400, #A78BFA)',
                    500: 'var(--color-brand-500, #8B5CF6)',
                    600: 'var(--color-brand-600, #7C3AED)',
                    700: 'var(--color-brand-700, #6D28D9)',
                    800: 'var(--color-brand-800, #5B21B6)',
                    900: 'var(--color-brand-900, #4C1D95)',
                }
            }
        }
    }
}

Afterwards you can use your color as regular CSS Tailwind class, for example as text-brand-100 or bg-brand-300.

Documentation and settings for fine tunning can be found here.

Generated palettes are not as great as the ones from the official Tailwind CSS color palettes but hey, those were carefully hand picked.

Why wrapping 3rd-party calls to external services is always a good idea

Luka Peharda — Thu, 31 Mar 2022 13:24:38 +0000

When using a 3rd-party package that makes calls (or API requests) to an external service it is always a good idea to wrap 3rd-party service with a thin wrapper (Facade). Why?

Wrapping it avoids vendor lock-in and tight coupling. Imagine that the API the 3rd-party is using stops working. Now you need to change service calls across your whole project. If wrapped, you only need to modify your code once.

Another reason is that you can then build and setup the 3rd-party service (or the client) according to your requirements.

Let me give you an example:

...

use Kourses\Website;
use Mpociot\VatCalculator\VatCalculator;

...

class VatHelper
{
    protected $calculator;

    public function __construct(Website $website)
    {
        $calculator = new VatCalculator();
        $calculator->setBusinessCountryCode($website->user->country);

        $this->calculator = $calculator;
    }

    ...
}

In my project, I'm using driesvints/vat-calculator package to calculate VAT (value-added tax) rate and to validate the EU VAT number. EU VAT number validation is being done by calling an external API.

As VAT rate calculation needs to take into account your business location, I need to provide the business country code when setting up the calculator. As a product I'm working on is a SaaS, I need to specify this param on each request and can't do it through configuration files (which this package supports). So I'm "building" up the VatCalculator according to my requirements.

If I did not wrap this service, I would have to configure it each time I call it. Not a big deal I know, but this is a simple example.

Besides doing a simple "wrapping" I've added a couple of methods that slightly modify 3rd-party service behavior.

...

use KoursesMember;
use KoursesErrorsVatValidationException;

use Exception;

class VatHelper
{
    ...

    public function isValidVatId(string $vatNumber): bool
    {
        try {
            return $this->calculator->isValidVATNumber($vatNumber);
        } catch (Exception $exception) {
            throw new VatValidationException("VAT validation failed.", 500);
        }
    }

    public function getTaxRate(string $countryCode, string $postalCode = null, string $vatNumber = null): float
    {
        $isCompany = $this->isValidVatId($vatNumber);

        return $this->calculator->getTaxRateForLocation($countryCode, $postalCode, $isCompany);
    }

    public function getTaxRateForMember(Member $member): float
    {
        return $this->getTaxRate($member->country, $member->zip, $member->vat_id);
    }
}

In method isValidVatId I'm catching a 3rd-party service exception and re-throwing it using a message (and code) that is in sync with my app. Now I don't need to catch 3rd-party package exceptions in my controllers.

If I decide to change this 3rd-party package I wouldn't have to go through my code and change all mentions of this package.

In getTaxRate method, I've also slightly altered behavior which suits my flow better. I'm validating the VAT number before getting the tax rate for the user's location (as it is dependent on your business location as well as your customers' location).

Method getTaxRateForMember is a simple helper which allows me to easily pass my $member object and get its current VAT rate without needing to "spread" required params.

Using this technique you could easily implement caching in front of external service calls if need be. Here, as the VAT number checked should be different each time I'm not doing that.

This wrapper borrows from a Facade design pattern, a Proxy, and even a Decorator. If you wish to learn more about design patterns be sure to check out https://refactoring.guru/design-patterns as they have a nice overview of basic patterns as well as real-world examples.

DEV Community: Luka Peharda

How to write better

Value over everything

Your work does not have to be original

Write to change minds, not to explain

The structure that works

Open with a problem

Then move to the solution

Write for yourself first

The courage to explain who you are

Practical tips that actually work

Before you write

While you're writing

After you write

What about SEO and all that?

The most important rule

Why write at all?

Do We Still Need NoSQL in 2026?

What even is NoSQL?

Where NoSQL makes sense

But here's where my head still hurts

Meanwhile, relational databases haven't been standing still

The honest downsides of NoSQL

So where does that leave me?

Why I Hate Black Fridays: A Developer's Thurs-dread Manifesto

Survival Strategy #1: The Mythical Universal Checkout System

Survival Strategy #2: The Pre-Emptive Interrogation

My Coping Mechanisms: A Tragicomedy in Multiple Acts

The Therapeutic Article

The "Yes, But" Diplomatic Dance

The Passive-Aggressive Emoji Ballet

When does the TDD approach make sense?

Adding Order::nextPaymentAmount method

TDD to the rescue

Code refactoring: what is it and why should you do it

What is refactoring

Why should you refactor your code?

Enhance readability and maintainability

Improve extensibility and maintainability

Increase performance

Reduce technical debt

Use EXISTS instead of COUNT > 0 when checking if records exist

Using count

Using exists subquery

Proper example of using exists

Using Tailwind CSS classes in markdown

100 lines of code per file

100 lines of code per file

Unexpected benefits of estimations

What is procrastination?

How estimation can help?

Additional benefits

How to generate a full Tailwind CSS palette from a single color

Solution 1. "Opacity"

Solution 2. "HSL"

Why wrapping 3rd-party calls to external services is always a good idea

Using `count`

Using `exists` subquery

Proper example of using `exists`