So I put in a little effort and in just one day I went from this:

To this:

Most of the time was spent on editing the text and skills. Click here to check out my GitHub profile or keep reading and edit yours.

Left Column

With the left column, everything is simple. Click on the "Edit profile" button and fill in all the fields. Keep in mind that GitHub often adds new features, so it's worth checking back from time to time to see if they've added anything to this column.

If you want to customize the left column even more, you should check out GitHub Achievements. Most of them aren't easy to unlock, but getting them is a good way to prove your skill level.

Main Area

This is where things get more interesting. In addition to the pinned repositories and gists, you can create an entire page with information about yourself. To do so, just create a repository and name it the same as your GitHub username.

For example, my GitHub username is AndrewSavetchuk, so my GitHub repository for my profile page is also named AndrewSavetchuk. You are welcome to take a look or use some of my code to make changes to your profile.

In the newly created repository, you will need to edit the README.md file to make changes to your page. There you can use markdown as well as HTML.

I decided to add some text about me, a list of languages and technologies, the latest blog posts, social links and one widget that shows my GitHub contributions.

If you need more inspiration, I recommend you visit this website - https://zzetao.github.io/awesome-github-profile/. It's a collection of well-designed GitHub pages that I often use to see what widgets are used by others.

You may also like the images I used for skills and social links, you can find them here: https://github.com/alexandresanlim/Badges4-README.md-Profile

As you can see, redesigning GitHub's page is not a challenging task and now that you have learned how to do it, why not put your newfound knowledge into action? Try out the ideas discussed in this article and see how they work for you.

I hope you found this information helpful, stay tuned for more content! I also post on Twitter and Mastodon if you want more content on web development and other technologies in your feed :)

The Model-View-Controller pattern was originally created in the late 1970s by Trygve Reenskaug, a Norwegian computer scientist, while he was working at Xerox PARC (Palo Alto Research Center). The MVC pattern was intended to help separate the concerns of the user interface design from the underlying application logic, making it easier to develop, test and maintain software.

Since then, the MVC pattern has become a widely used design pattern in software development and has been applied to many different types of applications and platforms, including web development, desktop applications, mobile apps, and more. Although there are several implementations of MVC, the most important point of the pattern remains the same - the division of responsibility.

There are other patterns similar to MVC, such as MVP (Model–View–Presenter) or MVVM (Model-View-ViewModel), but these are beyond the scope of this article. In this article, we will focus on a traditional MVC architecture for web applications.

If you have worked with frameworks like Laravel, Ruby on Rails, or Flask, you may already be familiar with the MVC architecture. It divides the program into three interrelated components:

• Model

• View

• Controller

Model

The Model often represents a table in an application's database and is responsible for reading and writing data, as well as persisting the application state.

In MVC, the Model is designed to be independent of the View and the Controller. It can be tested and developed separately from the other parts of the application.

View

The View is responsible for displaying data to users and handling user interaction. In the traditional interpretation of the MVC pattern, the View should not communicate directly with the Model. The Controller should update the View after receiving information from the Model about any changes to the data.

However, in practice, direct access to the Model is not uncommon, for example in small or simple applications. While this approach can simplify development in some cases, it can also make code more difficult to maintain and test over time, as changes to the Model can break views that rely on it. It also violates the principle of separation of concerns, which can make the code less modular.

Controller

The Model and the View are connected together through controllers. The Controller is responsible for receiving and processing user input, manipulating the Model (fetching/creating/updating/deleting data), and updating the View (returning the appropriate response to be rendered).

Visual Representation of MVC for a Web App

Below is a diagram of one possible take on the MVC pattern for a web application.

Let's take a closer look at what is happening here:

1. A user enters a URL in a browser and sends a request to a web application to open a specific page, in our case https://website.com/pages. Similarly, a user can send other types of requests, for example, a POST request from a web page to create a new record in the database.

2. In order to know which page/response to show the user based on their request, the web application has a list of routes. Those are, essentially, URL patterns associated with different pages which the application tries to match with the requested URL. Routes are associated with controllers, or rather with a specific function inside the controller known as a controller action. If the application finds a matching route (/pages in our case), it invokes the route-related controller action. If the route is not found, the application returns a 404 error.

3. With help of the routes, the PagesController action is called and that controller receives the user's request. PagesController then goes to PageModel to retrieve the necessary data, in our case, a list of pages. In other cases, the Controller may ask the Model to create a new record or modify an existing one based on the user's request.

4. As discussed previously, the Model often represents a table in an application's database, in our case, PageModel is connected with the pages database table.

5. The Model makes a request to read or write data from the database. The database executes the specified command, in our case, it is fetching all pages from the pages table and returns the result (data) to PageModel.

6. PageModel returns the pages data to PagesController.

7. The Controller passes the data received from the Model to the View. Finally, the View renders the requested page using data received from the Controller. The View is the last page a user sees in their browser.

The end. I hope you found this information helpful, stay tuned for more content! :)

Source

1. Model–view–controller - Wikipedia

2. Trygve Reenskaug - Wikipedia

Top 10 programming languages according to PYPL Index as of February 2023.

Some of you who decide to try TypeScript might get confused with type aliases and interfaces because they are both similar and used to define the shape and structure of values in a statically typed way. This means that it is possible to describe the same object using a type alias or an interface:

// Option #1: using a type alias
type Person = {
  firstName: string;
  lastName: string;
  age: number;
};

// Option #2: using an interface
interface Person {
  firstName: string;
  lastName: string,
  age: number;
};

You might be asking yourself why we have two options for describing the Person object instead of one. And are there any differences or specific use cases between type aliases and interfaces? Yes, and you will find out about them in a moment.

Before we begin, I should mention that the correct term for a type is type alias, but for simplicity, I will use those two terms interchangeably.

Difference #1: Objects and Functions

Both types and interfaces can be used to describe the shape of an object or a function signature. However, the syntax is different. A type is defined using the type keyword, followed by the name, an equals sign and the type definition:

type SampleObject = {
  a: string;
  b: string;
};

An interface is defined using the interface keyword, followed by the name and the interface definition in curly braces:

interface SampleObject {
  a: string;
  b: string;
};

As you can see, there is not much difference in syntax between the two examples. However, when we want to define a function signature, the difference becomes more noticeable:

// Using the "type" keyword
type SampleFunction = (param1: string, param2: number) => boolean;

// Using the "interface" keyword
interface SampleFunction {
  (param1: string, param2: number): boolean;
}

In practice, either approach can be used to define a function in TypeScript, and the choice between them often comes down to personal preference or project standards.

Difference #2: Other Types

Unlike an interface, the type alias can be used to create named types for all other types including:

• primitives

• unions (union types)

• tuples

• mapped types

Primitives

Just in case, I will remind you that there are six primitive types in JavaScript and TypeScript: boolean, number, string, null, undefined, and symbol. Here is an example of how to represent primitives in TypeScript using the type keyword:

type Name = string;
type Age = number;
type IsStudent = boolean;

With interfaces, you cannot directly define a named type for a primitive type.

Unions

A variable with a union type can hold a value of any of the constituent types. Union types can be formed by combining two or more other types, separated by a vertical bar (|).

// Example #1: union type that allows a variable to hold 
// one of the three specified string literal values.
type SampleType1 = 'Coffee' | 'Tea' | 'Water';

// Example #2: union type that allows a variable to hold 
// a value that is either a string or a number.
type SampleType2 = string | number;

// Example #3: union type that allows a variable to hold
// any of the values that are allowed by SampleType1 or SampleType2
type SampleType = SampleType1 | SampleType2;

Same as with primitives, you cannot directly define a union type using the interface keyword, however, it is possible to have a union type as an object property:

interface SampleObject {
  myProperty: string | number;
}

There are some limitations when using union types that you should be aware of:

• An interface cannot extend a union type:

type SampleUnionType = string | number;

// The code below will not work
interface extends SampleUnionType { ... }

• A class cannot implement a union type:

type SampleUnionType = string | number;

// The code below will not work
class SampleClass implements SampleUnionType { ... }

A class can implement an interface or type alias, both in the same way. However, it can not implement a type alias that names a union type.

Tuples

A tuple is a type that allows you to specify a fixed-length array of values where each element has a specific data type. Here is an example of how to create a type for an array with only two elements:

type PersonTuple = [string, number];

const person: PersonTuple = ["John Doe", 25];

Even though this can be achieved using interfaces as shown below, you will lose access to all of the array methods. If you try to call person.length on the variable created from the interface, you will get the following error: Property 'length' does not exist on type 'PersonTuple'.

You will have to manually add those methods (length, push, concat, etc.) to the interface as shown below. However, this is not something you want to do. If you need a tuple, consider using a type alias.

// How to mimic array methods
interface PersonTuple
{
    0: string;
    1: number;
    length: 2;
}

const person: PersonTuple = ["John Doe", 25];

console.log(person.length); // This will now work

Mapped Types

Mapped types allow you to transform an existing type into a new type by applying a mapping operation to each property of the original type.

type NewType = {
  [Property in OldType]: MappingOperation;
}

Here, OldType is the original type that you want to transform, and Property represents each property in OldType. MappingOperation is a TypeScript type operator that defines how each property in OldType will be transformed.

In the example below we create a new type B, which has all the properties of A, but with each property made optional.

type B = {
  [Property in keyof A]?: A[Property];
}

TypeScript does not currently support typing mapped types with interfaces.

Difference #3: Declaration Merging

If you have two interfaces that you define with the same name in the same scope, they will be merged. Consider this example:

// Declaring SampleType interface for the 1st time
interface SampleType {
  a: number;
  b: number;
};

// Declaring SampleType interface for the 2nd time
interface SampleType {
  c: number;
  d: number;
};

// The second interface declaration extends the first one by adding
// two new properties. Now SampleType has four properties: a, b, c, d
const sampleType: SampleType = {
  a: 1,
  b: 2,
  c: 3,
  d: 4,
};

We cannot do the same with types. This is important to consider if you are the author of a library and want your users to be able to extend its functionality by merging interfaces. It will allow them to combine their own type declarations with those provided by the library, effectively "extending" or "augmenting" the library's API.

Difference #4: Extention

Interfaces can extend other interfaces using the extends keyword which allows for greater flexibility and modularity:

interface Named {
  name: string;
}

interface Ageable {
  age: number;
}

interface Person extends Named, Ageable {
  sayHello(): void;
}

Types can also be extended using an intersection type. An intersection type combines multiple types into one. Consider this example:

// Example #1
type A = { a: number };
type B = { b: number };
type C = A & B;

const c: C = { a: 10, b: 20 };

// Example #2
type A = { a: number };
type B = A & { b: number };

const b: B = { a: 10, b: 20 };

As you can see, the & operator is used to create a new type by combining multiple existing types. The new type has all properties of the existing types.

We can also mix them together as shown below. Interfaces and type aliases are not mutually exclusive. An interface can extend a type alias and vice versa.

• Interface extends another interface:

interface A { sampleProperty: number; }
interface B extends A { sampleProperty: number; }

• Interface extends a type alias:

type A = { sampleProperty: number; }
interface B extends A { sampleProperty: number; }

• Type alias extends another type alias:

type A = { sampleProperty: number; };
type B = A & { sampleProperty: number; };

• Type alias extends interface:

interface A { sampleProperty: number; }
type B = A & { sampleProperty: number; };

There are some limitations to what can be extended with interfaces. For example, primitive types, union types, classes, and enums, cannot be extended with interfaces.

What Should I Use?

In general, it is recommended to use interfaces for defining object shapes, and types for defining other types of values. However, it is up to you and your team to decide which option to use as long as you are consistent.

For example, every object should be typed as an interface and everything else as a type. Or you can use interfaces or types for everything, but not both for values of the same type (e.g. types and interfaces for objects). Communication with your team and consistency are crucial for quality code.

Here is a good cheat sheet that I often refer to, however, it may differ for everyone:

When to use type:

• Use type when defining primitives

• Use type when defining unions

• Use type when defining tuples

• Use type when defining functions

• Use type when defining mapped types

When to use interface:

• Use interface for all object types where using type is not required

• Use interface when you want to take advantage of declaration merging

Keep an Eye on the Changelog

The limitations and differences described in this article are current as of February 2023. However, with new versions of TypeScript, they can change. It is important to keep an eye on the release notes to stay informed about new changes and features.

The end. I hope you found this information helpful, stay tuned for more content! :)

Source

1. PYPL PopularitY of Programming Language

2. Interfaces vs Types in TypeScript - Stack Overflow

3. TypeScript: Documentation - Everyday Types

4. TypeScript: Documentation - Mapped Types

This method worked well and was sufficient to complete the tasks I had at the time. However, as I progressed and started collaborating with other developers, I discovered additional ways to convert a value to a string. Here’s the full list:

• value.toString()

• value + '' or `${value}`

• String(value)

• JSON.stringify()

I was surprised to learn that each of these approaches works slightly differently, and I think experienced developers should be aware of these differences. In this article, we’ll dive into how each method behaves so you can choose the one that best suits your needs.

Option #1: value.toString()

value.toString() is an explicit conversion to a string because you are directly calling a method to perform the conversion. This option works only if the value is an object that has a toString() method; otherwise, it will throw a TypeError. Here are some examples to illustrate the difference:

// The variables below are objects that have toString() method
// Primitive data types such as number and boolean are also objects

const a = 50;
const b = true;
const c = [1, 2, 3];
const d = { name: "Andrew" };

console.log(a.toString()); // => "50"
console.log(b.toString()); // => "true"
console.log(c.toString()); // => "1, 2, 3"
console.log(d.toString()); // => "[object Object]"

// The variables below are not objects and do not have toString()
// method. Calling .toString() on them will result in TypeError

const e = null;
const f = undefined;

console.log(e.toString()); 
// TypeError: Cannot read properties of null (reading 'toString')

console.log(f.toString()); 
// TypeError: Cannot read properties of undefined (reading 'toString')

Good news: all standard objects in JavaScript - such as Number, Array, and Function have the toString() method implemented. It is used whenever an object needs to be represented as text (for example, in HTML) or whenever an object is implicitly converted to a string.

The important thing to remember is that calling value.toString() on null or undefined will throw a TypeError. This happens because these values are not objects and therefore do not have a toString() method.

You can also override the toString() method for your own objects or even for existing built-in objects. However, modifying built-in prototypes is generally discouraged, as it can cause unexpected behavior in other parts of your code or in third-party libraries.

Option #2: String(value)

String(value) is another explicit way to convert a value to a string using the String constructor. However, it works a bit differently than value.toString(). When you call String(value) on null or undefined, it will return a string with "null" or "undefined" respectively. And this is the most important difference to remember.

const a = 50;
const b = true;
const c = [1, 2, 3];
const d = { name: "Andrew" };

console.log(String(a)); // => "50"
console.log(String(b)); // => "true"
console.log(String(c)); // => "1, 2, 3"
console.log(String(d)); // => "[object Object]"

// Note that we do not get a TypeError 
// when calling String() on null or undefined

console.log(String(null));      // => "null"
console.log(String(undefined)); // => "undefined'

One important thing to note: since String is a constructor, it is possible to call it with the new keyword - new String(value). You should rarely use it this way.

When String is called as a function, it coerces the parameter to a string primitive. However, when String is called as a constructor (with new), it creates a String object, which is not a primitive. This produces different results:

const a = new String("Hello from 2023!");
const b = String("Hello from 2023!");

console.log(a); // => String {"Hello, 2023!"}
console.log(b); // => "Hello, 2023!"

console.log(a === 'Hello from 2023!'); // => false
console.log(b === 'Hello from 2023!'); // => true

console.log(a instanceof String); // => true
console.log(b instanceof String); // => false

console.log(typeof a); // => "object"
console.log(typeof b); // => "string"

Option #3: value + "" or `${value}`

When you concatenate a string with any other value, JavaScript will automatically convert the other value to a string. This is an implicit way to convert a value to a string because the + operator is not specifically designed for string conversion. Instead, it is a general-purpose operator that can be used for addition or string concatenation, depending on the types of the operands.

When you try to convert null or undefined to string, it will not result in TypeError:

const a = null;
const b = undefined;

console.log(a + ""); // => "null"
console.log(`${a}`); // => "null"

console.log(b + ""); // => "undefined"
console.log(`${b}`); // => "undefined"

However, I am not a big fan of using this method because it involves implicit string conversion and it can be difficult for other developers unfamiliar with JavaScript to understand how the code works at the first glance.

Whenever possible, I prefer to use String(value) or JSON.stringify(value) (comes next in the article), which are explicit conversions that do not throw a TypeError when calling on null or undefined.

Option #4: JSON.stringify(value)

This method is particularly useful for converting objects and arrays to JSON strings because it can handle nested objects and arrays. Remember what we got when we called value.toString() or String(value) on array or objects?

const a = [1, 2, 3];
const b = { name: "Andrew" };

console.log(a.toString()); // => "1,2,3"
console.log(String(a)); // => "1,2,3"

console.log(b.toString()); // => "[object Object]"
console.log(String(b)); // => "[object Object]"

This is not the case with JSON.stringify(), consider this example:

const a = [1, 2, 3];
const b = { name: "Andrew" };

console.log(JSON.stringify(a)); // => "[1,2,3]"
console.log(JSON.stringify(b)); // => '{"name":"Andrew"}'

As you can see, when we call JSON.stringify() on arrays, we get a valid JSON array as a string, and when we call JSON.stringify() on objects, we get a valid JSON object as a string. This also works when we have nested arrays or objects:

const a = [ ['a', 'b'], 5 ];
const b = { name: "Andrew", skills: [ "JavaScript", "TypeScript" ] };

console.log(JSON.stringify(a)); // => '[["a","b"],5]'
console.log(JSON.stringify(b)); // => '{"name":"Andrew","skills":["JavaScript","TypeScript"]}'

Calling JSON.stringify() on null or undefined works the same as with String():

console.log(JSON.stringify(null)); // => "null"
console.log(JSON.stringify(undefined)); // => "undefined"

JSON.stringify() is a more complex method than the previous ones, and in addition to the value to be converted to a string, it also takes two optional parameters: placeholder and space. Refer to the MDN Docs if you want to learn more.

Converting Dates to String

When we try to convert JavaScript dates to a string, the first three options work the same, while JSON.stringify() gives a different result. Consider this example:

const date = new Date(2023, 0, 1, 10, 0, 0);

console.log(String(date)); 
// => "Sun Jan 01 2023 10:00:00 GMT-0500 (Eastern Standard Time)"

console.log(date.toString()); 
// => "Sun Jan 01 2023 10:00:00 GMT-0500 (Eastern Standard Time)"

console.log(date + ""); 
// => "Sun Jan 01 2023 10:00:00 GMT-0500 (Eastern Standard Time)"

console.log(JSON.stringify(date)); 
// => '"2023-01-01T15:00:00.000Z"'

In this case, JSON.stringify() returns the date in ISO simplified extended format (ISO 8601). This is because the date object we pass to JSON.stringify() method implements the toJSON() method which returns a string (the same as date.toISOString()).

Always Consider Performance

Now, you may be tempted to use JSON.stringify() all the time as it offers the most complete conversion. However, you should know that String() is likely to be faster than JSON.stringify() because it is a simpler operation that does not involve parsing or formatting the input value as a JSON string.

String() simply converts the input value to a string using a simple set of rules, as we discussed earlier. This operation is generally fast and efficient, especially for primitive values.

On the other hand, JSON.stringify() is a more complex operation that involves parsing the input value and generating a JSON string that represents the object in a standardized format. Depending on the size and complexity of the input value, this operation can be relatively slow and resource intensive.

Even though the performance difference may not be significant, I strongly recommend choosing the right method wisely: if you do not need a JSON string in a standardized format, use String(value) or value.toString(), otherwise, use JSON. stringify(value).

The end. I hope you found this information helpful, stay tuned for more content! :)

Source

1. JavaScript Object toString() Method - W3Schools

2. String() Constructor - MDN Docs

3. JSON.stringify() - MDN Docs

Both Images and Containers are two distinct concepts in the Docker ecosystem and we need them both in order to work with Docker.

Docker Containers

Docker containers are small packages that contain our application and the environment required to run it (system tools, libraries, settings, etc). We can think of containers as running/executable units of software, the units we run locally, on servers and cloud providers in order to start our application.

Docker Images

Docker images are read-only templates of Docker containers. In order to create a Docker Container, we need a template or blueprint which is a Docker Image. Therefore, containers are dependent on images and use them to construct a run-time environment and run an application.

Docker images are typically built using a Dockerfile, which is a script that specifies the instructions for building the image. Docker images are stored in a registry and can be shared and reused by other users.

We can run multiple containers from the same image as shown below.

It is also worth mentioning that we can create Docker images based on other Docker images and this is often referred to as "layering" Docker images. The newly created Docker image inherits all the files and settings from the parent image, and we can add new files, dependencies, and configurations as needed.

Summary

• A Docker image is a read-only template or snapshot of a Docker container.

• A Docker container is a runnable instance of a Docker image.

• Images contain applications code, meanwhile, containers run it.

• We can use one image to create multiple containers on different servers.

  ---

  I hope you found this information helpful, stay tuned for more content! :)

Note: It is possible to add TypeScript during the initialization phase of the project, but this article is intended for those who already have Next.js projects and want to add TypeScript to them.

To Add Typescript to an Existing Next.js Project, You Can Follow These Steps:

Step 1 of 7

Install the necessary dependencies by running the following command in your project's root directory:

npm install -D typescript @types/react @types/react-dom @types/node

This will install the TypeScript compiler and the necessary type definitions for React and Node.js.

Step 2 of 7

Rename the existing jsconfig.json to tsconfig.json, or create a new tsconfig.json if the former file does not exist. Now we need to update the contents of the file to include TypeScript-specific configuration options. Merge your configuration with the code below if required:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "baseUrl": ".",
    "paths": {
      "@/components/*": ["components/*"],
      "@/pages/*": ["pages/*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

Step 3 of 7

Update next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  i18n: {
    defaultLocale: 'en',
    locales: ['en'],
  },
  reactStrictMode: true,
};

module.exports = nextConfig;

Step 4 of 7

Rename any existing .js files to .ts or .tsx, depending on whether the file contains JSX or not. For example, if you have a file called pages/index.js, rename it to pages/index.tsx.

You can also rename your existing directories such as pages or components to pages-old and components-old and create new empty directories with TypeScript files in case you need to reference the original files later.

Step 5 of 7

Update any files that import other files to use the .ts or .tsx extension. For example, if you have a file called index.ts that imports a file called header.js, update the import statement in index.ts to use the .ts or .tsx extension like so: import Header from './header.tsx';

Step 6 of 7

Covert your JavaScript code into TypeScript code. Here is an example of how to convert pages/_app.js to pages/_app.tsx:

import 'normalize.css';
import '@/styles/index.scss';

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

export default MyApp;

import 'normalize.css';
import '@/styles/index.scss';

import type { AppProps } from 'next/app';

export default function App({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />;
}

Step 7 of 7

Restart your development server by running npm run dev, and your TypeScript code should now be compiled and running alongside your React code.

Note: you may need to adjust some of these steps depending on the specific structure of your project. However, these steps should be a good starting point for most projects.

The end. I hope you found this information helpful, stay tuned for more content! :)

Whenever I hear that ChatGPT is going to take someone's place, I encourage people to try actively using ChatGPT for at least a week. I do use it more often than Google, and while it helps to find the right information without annoying ads, it still often gives me incorrect answers to simple questions.

For example, here is me asking ChatGPT how to add a multi-select option to Choices.js (a JavaScript library I use in a Laravel project to make custom selectors).

As you can see, ChatGPT suggested that I should add multiple: true to the configuration object. I tried and it did not work. Instead, I decided to add the multiple property to the HTML tag itself and it did the trick (<select multiple...>).

Next, I wanted to be able to unselect some previously selected options, but the "X" button I expected to see did not appear. So I asked ChatGPT again.

As with the previous question, this time I got the wrong answer again. Even though the given piece of code is complete and works, it is not the piece I asked for.

Let's see one more example when ChatGPT gave me the correct answer, but in my opinion, the answer could be a bit better.

I asked ChatGPT to instantiate the date in Laravel, add 30 days to it, and display it in the following format: 13/2/2023. The code ChatGPT gave me this time was correct, however, Laravel has a now() helper that you can use instead of Carbon\Carbon::now() which I think makes your code cleaner. If I did not know about the shorthand, I would have had to write more code. It would be great if AI tools like ChatGPT offered you multiple solutions and explained the benefits and differences of each.

As of 2023, ChatGPT is pretty much the same tool as Google or StackOverflow, but without the ads (I wonder how long it will stay this way though). I do realize that the model will learn and grow over time, but I wonder if it could keep up with the latest technology trends in the future. For now, it works just well, periodically giving wrong responses, but still not good enough to give up other tools such as old but good StackOverflow.

The end. I hope you found this information helpful, stay tuned for more content! :)

Finding Files using AWS CloudShell

For this example, I have chosen Amazon CloudShell as the easiest tool to use with the AWS CLI that does not require any software to be installed on your computer. You can use any other tool you like.

To find the N most recent largest files in an AWS S3 bucket, you need to open console.aws.amazon.com and find CloudShell (I recommend adding it to your favourites in case you need to use it again).

Before running the command you need to know your S3 bucket name. When you have it ready, you can use the command below to find files:

aws s3api list-objects-v2 --bucket BUCKETNAME --query 'sort_by(Contents[?LastModified>=`2023-01-01`], &Size)[-5:]'

Replace BUCKETNAME with your S3 bucket name and change the date (2023-01-01) as needed. After running the command, your output should look like this:

Ignore LastModified Property

If you want to find the last N files regardless of the LastModified property, you can configure your command like this:

aws s3api list-objects-v2 --bucket BUCKETNAME --query 'sort_by(Contents, &Size)[-5:]'

Adjusting the Number of Files

You can adjust the number of files to be returned by changing the number in the square brackets ([-5:]), or you can remove the square brackets with the contents inside to display all files sorted by size. Be careful to run such a command on a large bucket though, as it can take minutes to perform the operation (I did it once...).

Bonus Command

There is another command that I rarely use but thought it would be useful to share.

aws s3 ls --summarize --human-readable --recursive s3://BUCKETNAME

This command will display all files in the bucket in a compact form with LastModified, Size and Name properties. If you have ever run the ls command on a Linux/Unix operating system before, you know what to expect.

The end. I hope you found this information helpful, stay tuned for more content! :)

PHP CS Fixer stands for PHP Coding Standards Fixer. This is a tool that fixes your code to follow standards. There are various PHP coding standards that you can follow, such as the popular PSR-1, and PSR-12 published by the PHP Framework Interoperability Group (the full list of PSR standards can be found here).

There are also other community-driven standards like the Symphony.

With PHP CS Fixer, you can follow multiple coding standards at once, or you can also define your own or your team's own coding standard through configuration. If you have ever worked with JavaScript and Eslint in particular, think of PHP CS Fixer as an alternative to Eslint for PHP.

Manually fixing coding standards in your code is a very tedious process, so PHP CS Fixer is a great solution. It helps you and your team ensure that you all follow the same rules when writing code, thus keeping it cleaner.

Installation​

The recommended way to install PHP CS Fixer is to use Composer in a dedicated directory in your project, for example in the tools/php-cs-fixer.

mkdir --parents tools/php-cs-fixer
composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer

For more details and other installation methods, see installation instructions.

Usage

Usage: Option 1​

Assuming you installed PHP CS Fixer as instructed above, you can run the following command to fix the files PHP files in the src directory:

tools/php-cs-fixer/vendor/bin/php-cs-fixer fix src

See usage, list of built-in rules, list of rule sets, and configuration file documentation for more details. If you need to apply code styles that are not supported by the tool, you can create custom rules.

Usage: Option 2 (Editor Integration)​

However, executing a command manually does not seem to be a convenient approach. I personally prefer to run PHP CS Fixer by pressing a pre-configured keyboard shortcut in PHP Storm.

You can configure PHP CS Fixer for various code editors as described below:

• Atom

• NetBeans

• PhpStorm

• Sublime Text

• Vim

• VS Code

Usage: Option 3 (Run PHP CS Fixer on every commit)​

As an alternative option, you can fix your code on every commit using Husky and lint-staged. Using these tools PHP CS Fixer will run on your staged files, in other words, on the files you want to commit. Here is a great article explaining how to set up these tools to work with PHP CS Fixer.

Easy way of configuring PHP CS Fixer​

If you are new to PHP Coding Standards and want to quickly configure PHP CS Fixer, I highly recommend using PHP CS Fixer Configurator by Michele Locati. It has a pre-defined set of rules that you can select and create your own configuration.

Most rules, when clicked, will display general information about the rule, available configuration options, and usage examples. The PHP CS Fixer configuration file generated by this tool can be exported to use in your project and then imported again in case you want to do some modifications.

The end. I hope you found this information helpful, stay tuned for more content! :)

Source

1. FriendsOfPHP/PHP-CS-Fixer: A tool to automatically fix PHP Coding Standards issues

2. PHP-CS-Fixer Configurator

An idempotent HTTP method is a method that can be called multiple times with the same input and produce the same result, without changing the state of the server.

Idempotency essentially means that the result of a successfully performed request does not depend on the amount of its execution. For example, in arithmetic, adding zero to a number is an idempotent operation.

Why do we need Idempotency?​

API consumers can make mistakes and write the client code in such a way that there can be duplicate requests coming to the API. Idempotency is needed to make APIs fault-tolerant so that duplicated requests do not leave the system unstable.

The end. I hope you found this information helpful, stay tuned for more content! :)

Design Patterns

Design Patterns are techniques for how to design and architect your code. They are reusable low-level solutions to commonly occurring software design problems, so instead of inventing the wheel, we follow design patterns that are well-proven, tested by others, and safe to follow.

Each design pattern has a different use case and applies to a different scenario, they are also typically specific to a programming language or technology and often provide implementation details.

Examples of Design Patterns:

• Adapter Pattern (converts the interface of a class into another interface that clients expect, allowing classes to work together)

• Active Record Pattern (a database table or view is wrapped into a class)

• MVC Pattern (separates application's logic into three interconnected components: the Model, the View, and the Controller)

• Singleton Pattern (one class can only have one instance at a time)

Design Principles

Design principles, on the other hand, are general (high-level) guidelines that help inform good software design to ensure scalable software architecture and mastery. In most cases, you need to follow them to have quality code. They are more abstract and less prescriptive than design patterns and are typically not dependent on any specific programming language or technology.

For example, the Single Responsibility Principle (SRP) suggests that a class should have only one reason to change. This is a high-level statement that we should keep in mind while designing or creating classes for our application. SRP does not provide specific implementation steps and it is up to developers how they implement it in their applications.

Sometimes, design principles imply some design patterns. For example, the Open/Closed principle closely implies the Strategy pattern. Meanwhile, the Dependency Injection principle has strong ties to the MVC pattern.

Examples of Design Principles:

• DRY Principle (Don't Repeat Yourself)

• KISS Principle (Keep It Simple, Stupid)

• Single Responsibility Principle (a class should have only one reason to change)

• SOLID Principles (an acronym for five design principles)

TL;DR

• Design Patterns are specific (low-level) solutions to specific problems. You should have a very good reason every time you decide to implement a pattern.

• Design Principles are general (high-level) guidelines that help inform good software design. You should have a very good reason every time you decide not to follow principles.

• Both concepts are important for building high-quality software, and they can be used in conjunction to create robust and maintainable systems.

I hope you found this information helpful, stay tuned for more content! :)

Source

1. ruby on rails - What's the difference between design patterns and design principles? - Stack Overflow

Unix​

Before Linux and Windows, the computer world was dominated by Unix. Unix is a family of computer operating systems that derive from the original AT&T Unix (the mother OS as some people call it) that was invented in the '60s and over time has become a standard or certification. Only systems fully compliant with and certified to the Single UNIX Specification qualify as "Unix", others are called "Unix-like". For example, nowadays Mac OS is certified as UNIX certified while Linux is Unix-Like.

However, over time, Unix became less popular. The main problem with Unix was that it was very expensive. You needed expensive machinery, an expensive license, and an expensive administrator. We are talking about tens of thousands of dollars or euros a year, not the computer you buy as a student. This still applies to IBM AIX, HP-UX, and Sun Solaris, which are mostly used by large companies and organizations, although it would be cheaper for them to run everything on Linux.

Linux​

Linux is a Unix-like operating system that behaves in a manner similar to a Unix system, although not necessarily conforming to or being certified to any version of the Single UNIX Specification. Technically, it is created from scratch, except for some parts where software providers gave away their code. The term Linux is applied to a number of open-source Unix-like operating systems based on the Linux kernel (the main component of a Linux operating system) known as distributions: Ubuntu, Debian, CentOS, Fedora, and so on.

Many operating systems were developed to be like Unix, but none have become as popular as Linux. Linux arose from the desire to have an affordable OS that would be cheap and could run on common hardware, like the average PC. One of the features was to make it "free" with the appropriate license: GNU. It is freely available, costs nothing to download and install, and can run on a cheap computer, take Raspberry Pi, for example. Using Linux as a user or admin is mostly the same as using Unix as the commands are very similar. If you have ever worked with a Linux and Mac OS terminal, you have probably noticed it.

We can say that asking about the differences between Unix and Linux is like asking about the differences between Mammals and Dogs. All dogs are mammals, but we can say that they are usually more suitable for pets than other mammals. This is not to say that other mammals, such as cats, cannot be excellent pets. Similarly, it would be fair to say that Linux is generally less expensive than Unix, but this does not preclude the existence of expensive Linux or free Unix distributions.

Key Features

TL;DR

Unix and Linux are both operating systems, with Unix being an older and proprietary system, while Linux is an open-source system based on Unix.

I hope you found this information helpful, stay tuned for more content! :)

Source

1. Unix - Wikipedia

2. Linux - Wikipedia

3. Difference between Unix and Linux - Unix & Linux Stack Exchange

Both service classes and traits can be reused throughout an application and service classes can utilize traits.

Service Classes​

We can think of a service class like a PHP object that performs some sort of a "global" task. Service classes are often used to encapsulate complex business logic or to provide a unified interface to interact with external services, such as databases or web services.

For example, there may be a mailing service or a user creation service. These are tasks that need to be repeated over and over again in different places. This makes them good candidates for a service class.

Some ideas for service classes:

• Service class responsible for sending SMS via Twilio.

• Service class responsible for sending Emails via Mailgun (Newsletter Service).

• Service class responsible for working with UptimeRobot APIs.

• Service class responsible for storing and deleting images on the cloud.

Example of a Service Class in Laravel​

Here is an example of the App\Services\UptimeRobotAPI.php service class that is responsible for connecting to the UptimeRobot API and retrieving data:

<?php

namespace App\Services;

use GuzzleHttp\Client;

class UptimeRobotAPI
{
  protected string $url;
  protected string $http;
  protected array $headers;

  public function __construct(Client $client)
  {
    $this->url = 'https://api.uptimerobot.com/v2/';
    $this->http = $client;
    $this->headers = [
      'cache-control' => 'no-cache',
      'content-type'  => 'application/x-www-form-urlencoded',
    ];
  }

  private function getResponse(string $path)
  {
    // Making a GET request to UptimeRobot API using GuzzleHttp...
  }

  private function postResponse(string $path, array $params = [])
  {
    // Making a POST request to UptimeRobot API using GuzzleHttp...
  }

  public function getMonitors()
  {
    return $this->getResponse('getMonitors');
  }
}

The UptimeRobotAPI service is now can be used like so:

<?php

namespace App\Http\Controllers;

use App\Services\UptimeRobotAPI;

class MonitorsController extends Controller
{
  public function index(UptimeRobotAPI $uptimeRobotAPI)
  {
    $monitors = $uptimeRobotAPI->getMonitors();

    return view('monitors.index', compact('monitors'));
  }
}

More Service Class Examples

Another example of a service class would be a PaymentService or StripeService - a service class that encapsulates payment-related functionality, such as processing payments, managing payment methods, and handling refunds.

Traits

In PHP, a class can only inherit from a single parent class, which can limit the ability to reuse code. Traits were introduced to solve this problem by providing a way to reuse code across multiple classes without using inheritance. They allow developers to define a set of methods that can be shared among multiple classes, allowing for more flexible and modular code. Traits are particularly useful when building complex applications that require a lot of code reuse.

Example of a Trait in Laravel

Here is an example of the app/Traits/ApiResponder.php trait I often use when developing Laravel applications:

<?php

namespace App\Traits;

use Illuminate\Http\JsonResponse;
use Symfony\Component\HttpFoundation\Response;

trait ApiResponder
{
  public function successResponse($data, int $code = Response::HTTP_OK): JsonResponse {
    return response()->json([
      'data' => $data,
      'code' => $code,
    ], $code)->header('Content-Type', 'application/json');
  }

  public function errorResponse($error, int $code): JsonResponse
  {
    return response()->json([
      'error' => $error,
      'code'  => $code,
    ], $code)->header('Content-Type', 'application/json');
  }
}

Once the trait is created, you can import it as follows:

<?php

namespace App\Http\Controllers;

use App\Traits\ApiResponder;
use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Routing\Controller as BaseController;

class Controller extends BaseController
{
  use AuthorizesRequests, DispatchesJobs, ValidatesRequests, ApiResponder;

  // ...
}

Once the trait is imported it is ready to use:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\JsonResponse;

class TwilioSettingsController extends Controller
{
  public function fetchSettings(): JsonResponse
  {
    $response = TwilioSettings::getSettings();

    return $this->successResponse($response);
  }
}

More Trait Examples

Another example of a trait would be a LoggableTrait - a trait that adds logging functionality to a class, allowing it to log messages to a log file or other logging system. This trait can be used by multiple PHP classes, including Service Classes.

The end. I hope you found this information helpful, stay tuned for more content! :)

The active record design pattern (considered an architectural pattern) is an approach that connects the application's business logic to a database table, allowing developers to work with the database using an object-oriented paradigm.

The active record is an object that wraps a row in the database table, encapsulates the database access and provides an interface to query, insert, update and delete data from the database, making it easier to work with databases in an application.

In addition to query, insert, update and delete functions, the interface on an object conforming to this pattern would also include properties that correspond more or less directly to the columns in the underlying database table.

After the creation of an object, a new row is added to the table upon saving. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.

The active record pattern is commonly used by many programming frameworks that store in-memory object data in relational databases, such as Django and Laravel.

Name origin

The pattern was named by Martin Fowler in his book Patterns of Enterprise Application Architecture (2003).

Implementation

This pattern is intended to make simple CRUD (Create, Read, Update, Delete) tasks quicker to achieve. For example, instead of writing a lot of SQL queries to insert or update many common and simple data objects, it allows us to simply assign values to the data object and run a command to save it, e.g. $object->save(). The SQL for inserting/updating data will be compiled and executed for us.

For example, if there is a table users in a database with columns name (string type) and age (number type), and the Active Record pattern is implemented in the class User, the pseudo-code will create a new row in the users table with the given values:

$user = new User();
$user->name = 'John Doe';
$user->age = 25;
$user->save();

The pseudo-code above is roughly equivalent to the SQL command:

INSERT INTO users (name, age) VALUES ('John Doe', 25);

Conversely, the class can be used to query the database:

$user = User::where('name', 'John Doe')->first();

This will find a new User object based on the first matching row from the users table whose name column has the value "John Doe". The SQL command used might be similar to the following, depending on the SQL implementation details of the database:

SELECT * FROM users WHERE name = 'John Doe' LIMIT 1;

Most frameworks also implement data relationships within their respective Active Record models which can greatly simplify accessing data related to our object. For example, in Laravel, if we specified that a Category "has many" Product`s then after loading the Category object from the database, we can list its child Product`s with a simple line of code:

foreach ($category->products as $product) {
  echo $product->name;
}

When to use it

Active Record is a good choice for domain logic that is not too complex, such as creates, reads, updates, and deletes. Derivations and validations based on a single record work well in this structure.

Criticism

Mapping issues

Active Record has the primary advantage of simplicity. It is easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record objects correspond directly to the database tables: an isomorphic schema.

If your business logic is complex, you will soon want to use your object's direct relationships, collections, inheritance, and so forth. These do not map easily onto Active Record, and adding them piecemeal gets very messy. That is what will lead you to use Data Mapper instead.

Testability

Due to the coupling of database interaction and application logic when using the active record pattern, unit testing an active record object without a database becomes difficult. These negative effects on the testability of the active record pattern can be reduced by using mocking or dependency injection frameworks to substitute the real data tier with a simulated one.

Distributed systems

Record-based patterns work poorly in distributed systems, especially where concurrency is impossible (e.g. offline). i.e. two updates both may have one field that is correct but only one of the two records can win.

Single responsibility principle and separation of concerns

Due to the strong coupling of database interaction and application logic, an active record object does not follow the single responsibility principle and separation of concerns as opposed to multitier architecture which properly addresses these practices.

Conclusion

Active Record is good for quick CRUD-based applications where the Model is relatively flat (as in, not a lot of class hierarchies). However, for applications with complex OO hierarchies, a DataMapper is probably a better solution.

I hope you found this information helpful, stay tuned for more content! :)

Source

1. Active record pattern - Wikipedia

2. What is the purpose of Active Records? - StackOverflow

3. Patterns of Enterprise Application Architecture (2003)

• Adding SASS / SCSS support

• Setting up Eslint and Prettier

• Setting up Eslint to run automatically before every commit (via a Git hook)

• Setting up Semantic Commits (via a Git hook)

Any of the above items are optional and can be skipped during the process.
For example, if you are not familiar with Semantic Commits or do not plan to use it, you can skip that part and move on to another.

You may want to bookmark this article and use it as a reference when creating your projects. I will try to keep it up to date, and when I discover a new useful feature, I will include it here.

Let's get started.

1. Install Node.js and NPM

We need Node.js 12.22.0 or later in order to install and use Next.js.

To see if you already have Node.js and NPM installed on your machine, run the following commands:

node -v
npm -v

You should see the installed version printed for each command.

If you do not have this output and instead see command not found or a similar error, download and install Node.js from the official website: https://nodejs.org/en/download/

2. Install Next.js

Open your terminal, navigate to the folder where you want to create a new project, and run the following command:

npx create-next-app@latest

During installation, you will be prompted to name the project, enter the most appropriate name, and press Enter.

Congratulations! You have installed Next.js.

You can stop here and work with your application already by running the following command in the directory we just created (you named it during the installation).

npm run dev

However, if you want to add some configuration, open the project in your favorite code editor and follow the next steps. Each of the steps is optional, you can choose ones that suit you best.

3. Configure .gitignore for JetBrains products

Note: This step is optional.

If you are using any of the JetBrains code editors (such as WebStorm or PHPStorm), it is recommended that you exclude certain folders and files from version control.

You may use the following preset: https://github.com/github/gitignore/blob/master/Global/JetBrains.gitignore

Just copy and paste the content into your .gitignore file.

4. Adding SASS / SCSS support

Note: This step is optional.

If you plan on using SASS / SCSS, run the following command:

npm install sass

Now go to the styles folder, you should see two .css files there:

• styles/globals.css

• styles/Home.module.css

Rename them to .sass or .scss as you prefer.

After you renamed the files, you need to change the paths to them in:

• pages/_app.js

• pages/index.js

That is all! The rest will be handled by Next.js. You can now use SASS in your project.

5. Setting up Eslint and Prettier

Note: This step is optional.

Eslint is already installed in your Next.js project by default. The configuration file (.eslintrc.json) can be found in the root directory of your project.

However, it is not automatically called when you run the application in development mode (npm run dev). This is why we are going to set up a Git hook in the next step, but first, let's install and configure Prettier.

Run the following commands to install Prettier:

npm install --save-dev prettier

Since Eslint also contains code formatting rules, which can conflict with your existing Prettier setup, installation of eslint-config-prettier is recommended.

To install the config, run:

npm install --save-dev eslint-config-prettier

After the installation, create a config file for Prettier (.prettierrc.json) in the root directory of your project. Here is a sample configuration.

{
  "singleQuote": true,
  "semi": true,
  "tabWidth": 2
}

Now, add prettier to your existing Eslint config (.eslintrc.json): json { "extends": ["next/core-web-vitals", "prettier"] }

Done, now you can use Prettier and lint your code by running npm run lint.

6. Setting up Eslint to run automatically before every commit

Note: This step is optional.

To prevent code with Eslint errors or warnings from being pushed to your working repository, you can set up a Git hook that will run the next lint command every time you try to send a commit.

In case of Eslint errors, your commit will not be sent and you will see an info message with error/warning details. See the example below.

In order to set up Git hooks, we need to install Husky (npm package):

npm install husky --save-dev

After the installation, add the prepare script to your package.json file:

...
"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "prepare": "husky install"
},
...

Then run it once, it will create a .husky folder with the required configurations.

npm run prepare

Husky is installed and it is time to create our first Git hook.

Run the following command:

npx husky add .husky/pre-commit "next lint --max-warnings=0"

This command creates a pre-commit hook that executes next lint command every time you try to send a commit.

The --max-warnings=0 flag is optional and can be removed in order to allow pushing the code with Eslint warnings. The info message will only appear in case of errors.

7. Setting up Semantic Commits

Note: This step is optional.

If you are familiar with Semantic Commits, you may want to add validation to ensure all commis is in the correct format.

To do so you need to have Husky installed (see step 6 in this tutorial).

After Husky installation, we need to install the @commitlint npm package:

# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}

# For Windows:
npm install --save-dev @commitlint/config-conventional @commitlint/cli

Then we need to configure commitlint to use conventional config:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

And finally, add a hook that will check the validity of commit messages:

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

Now, if you try to send a commit that does not follow the Conventional Commits rules, you will see the following error:

If you would like to see the final results of the project described in this article please take a look at the Github repository: https://github.com/AndrewSavetchuk/next-js-project-starter

The end. I hope you found this information helpful, stay tuned for more content! :)