PS: I also made a youtube video on this here.

Using the right icons can make our applications not only better looking but also more intuitive. Inline SVG icons are safe, sharp, and easy to customize, but they tend to ruin our markup and make it less pleasant to navigate.

Another problem is that they are hard to re-use. Because, one, you cannot really know which icon is which unless you figure out from the surrounding markup or by refreshing the browser, and two, when you want to change an SVG icon you have to find and replace all the occurrences in your app, which isn’t that nice.

Two solutions solve this…


Duh! What else could it be?

Everyone knows you should put all your energy into your application’s core features and ignore everything else that gets in your way. And yet we continue to build unnecessary crap and fail to ship our best work.

From time to time, I run into some issues one of my old projects would have solved and use it as an excuse to try and revive the once-abandoned idea.

So I take the dust off, open the project, and start by… removing half or more of the features I was building. Whatever the project aimed to do, I cut it half. …


When you write a piece of code for the first time, names don’t matter that much. You obviously know what everything is and what it does. However, while it’s cheap and easy to understand now, code written using poor names will grow to be incomprehensible as time passes and your application gets bigger.

The price we pay for poor names comes under many different forms: slow development speed, faulty design, bugs, and ultimately, clients and customers lost. Because of this, we should write code that is easy to understand and use now, and in the future.

Image for post
Image for post
Photo by Brett Jordan on Unsplash

A method must a query or a command. Not both.

Query methods are methods that return something without causing any side-effects. A side-effect could be anything — from updating a row in the database, to sending an e-mail, writing to a file, or posting data to an external API. Anything that changes something somewhere is a side-effect. …


There are many good reasons to rewrite a legacy application, but most of the time, the cost outweighs the benefits. In this article, I balance the pros and cons of rewriting applications from scratch and try to articulate why it is almost always a bad idea.

Many developers, including myself, can live with a legacy application for only so long before they want to kill it, burn it with fire, and rebuild it from the ground up. …


Image for post
Image for post
Photo by Jelmer Assink on Unsplash

I believe 2020 is my fifth(?) year of consistently going to the gym. Since the beginning, I found myself almost quitting every few months, but there were a few things I believe that helped me keep going. In this article, I want to share those things in the hope of helping others wishing to make working out an important part of their lives.

Everything has a price

First things first. You must acknowledge and accept the pros and cons that come with consistently going to the gym. …


Image for post
Image for post

I think everyone loves to work on completely greenfield applications. You get to plan your own course, chose your current favourite technologies, structures, and patterns to follow. There is no legacy code, no technical debt, nothing that stands in your way. You can do whatever you want and building features is a breeze.

But you know the story. You know what happens next.

Your application grows. New requirements come in, and old features need to be changed.

You do your best to keep customers happy, but after a while complexity creeps in and you find yourself in a position where you start doing every possible hack and take every crappy decision to fight your own code into submission. …


The easiest way to get yourself accustomed with how inertia works is to stop thinking about inertia visits as being XHR requests where you *do something* when the request it’s completed, and think of your project more as traditional server-side application where everything that happens next is dictated by the server.

The same is true for handling server-side validation errors.

You shouldn’t try to catch() the validation errors and update the form state. Instead, you should validate the form and return the errors as view props, just like you would do with a default Laravel & Blade application.

  1. Submit your form with Inertia. …


If you’re a Laravel developer working with InertiaJS, there’s a good chance you played around with PingCRM, the application Jonathan build to illustrate how InertiaJS works. If not, I encourage you to have a look over it as it helps a lot in figuring out how Inertia should be used.

Because the default Laravel pagination does not work well with Inertia, in PingCRM the LengthAwarePaginator was swapped with a custom one which does work when paginating Eloquent models, but fails to do so when using API resources. Don’t get bummed out, there are a few solutions:

Use the transform(callback) method.

This will loop through the collection and return an API resource. …


Image for post
Image for post

Mass-assignment is when you use an array to create/update eloquent models.

$user->update(['name' => 'Dan Gosling', 'email' => 'dan@gosling.com', ...etc]) 

User::create(['name' => 'Jack Ba', 'email' => 'jack@ba.com', ...etc])

The $fillable and $guarded model properties are part of Laravel’s solution to avoid mass-assigning unwanted attributes when someone passes an unexpected HTTP parameter through a request and ends up changing a column in your database you did not expect.

While you can, and should protect yourself by filtering out the request parameters and only accept a known list using $request->only('param1', 'param2'), having protection at the model level is encouraged – you never know when some request somewhere slips through the cracks. …


Tell, Don’t Ask is an object oriented programming principle saying we should just tell objects what to do, without asking them unnecessary questions.

Asking is when we’re writing conditionals solely based on one object’s internals. Either we’re checking a property or a method returning a result, if we’re doing it to tell the object to do something else, we’re breaking the Tell, Don’t Ask principle.

Here are two examples:

// bad 
if ($order->subtotal() > 10000) {
$order->shipping_price = 0;
}

// better
$order->calculateShippingPrice();
// bad: asking the user object if it's enrolled, then telling it to enroll to $course
if (!$user->isEnrolled($course)) …

About

Druc Constantin

Web developer. Strong opinions, weakly held. https://cdruc.com/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store