DEV Community: Rowland

Data Serialization: A Concise Guide to JSON, YAML, TOML, and More

Rowland — Thu, 26 Feb 2026 18:25:13 +0000

As a developer, you’ve most likely encountered serialization, perhaps without realizing it. It happens whenever you read config files, use APIs, or save application state.

So what is it exactly? Serialization is the process of converting data from its in-memory representation into a format that can be stored or transmitted. The reverse, reading that stored format back into usable data, is called deserialization.

A common example of this process is copying text to your clipboard from a rich text editor. The editor has all sorts of in-memory data about that text, font size, bold state, color, line height etc. When you paste it into a plain text app like Notepad, it gets stripped down to just the characters. That stripping process is a crude form of serialization, converting a rich in-memory object into a simpler transmittable format.

The format you choose matters. It affects how readable your code and config files are, how easy it is to debug issues, how well your tools and libraries support it, and sometimes even performance at scale. In this post, I review popular serialization formats such as JSON, YAML, and TOML, along with other noteworthy options, evaluating the advantages and disadvantages of each.

JSON

JSON (JavaScript Object Notation) is probably the most widely used serialization format in software today. It started as a subset of JavaScript but has since become the standard for data exchange across virtually every programming language and platform.

This is what it looks like:

{
 “name”: “John”,
 “age”: 30,
 “email”: “john@example.com”,
 “roles”: [“admin”, “editor”],
 “address”: {
 “city”: “Lagos”,
 “country”: “Nigeria”
 },
 “active”: true
}

JSON's popularity stems from its intentional simplicity, supporting six data types: strings, numbers, booleans, null, arrays, and objects.

JSON is the standard format utilized for REST APIs, browser storage such as localStorage, and configuration files within the JavaScript ecosystem, including package.json. When two services require data exchange over HTTP, JSON is typically the preferred option.

Pros

Every major programming language has a JSON parser, either built in or easily available
Easy to read and understand
Lightweight with minimal overhead
Excellent tooling support, including formatters, validators, and editor plugins

Cons

No support for comments, which is a real limitation when using it for configuration files
Strict syntax means a single trailing comma or missing quote can break parsing
Limited data types with no native support for dates or binary data
Deeply nested structures can get hard to read quickly

Worth knowing: Two unofficial extensions of JSON exist to address the lack of comments. JSONC (JSON with Comments) adds support for single-line // and multi-line /* */ comments. It's what VS Code uses for its settings.json and what TypeScript uses for tsconfig.json, so most developers encounter it without realizing it has a distinct name. JSON5 goes further, also allowing trailing commas and unquoted keys. Both require parsers that explicitly support them since standard JSON parsers will reject the extra syntax.

YAML

YAML (YAML Ain’t Markup Language) was built with human readability as the main priority. It uses indentation instead of brackets and braces, which makes it feel closer to plain text than most other formats.

What it looks like:

name: John
age: 30
email: john@example.com
roles:
  - admin
  - editor
address:
  city: Lagos
  country: Nigeria
active: true

# You can also include a comment
database:
  host: localhost
  port: 5432
  name: myapp_db

Almost the same data as the JSON example above, but noticeably less visual noise.

YAML is the standard in the DevOps world. Docker Compose files, Kubernetes manifests, GitHub Actions workflows, Ansible playbooks, and most CI/CD configuration files are written in YAML. It also shows up in frameworks like Ruby on Rails and static site generators like Hugo and Jekyll.

Pros

Very readable, especially for people who may not have extensive technical knowledge
Supports comments, which makes it much more practical for configuration files
Handles a wider range of data types natively, including dates and multi-line strings
Less syntactic clutter compared to JSON

Cons

Indentation-sensitive, so a misplaced space can cause silent bugs or confusing parse errors
The full spec has a surprising number of edge cases. One well-known example is the “Norway problem” where the string NO gets parsed as false in some parsers
Generally slower to parse than JSON
Some YAML parsers support object deserialization features that can introduce security vulnerabilities if you’re not careful

Worth knowing: YAML is actually a superset of JSON. Any valid JSON document is also valid YAML. This means YAML parsers can read JSON files, though you’d rarely want to mix the two intentionally.

TOML

TOML (Tom’s Obvious, Minimal Language) was created by Tom Preston-Werner as a configuration format that is easy to read and has predictable, unambiguous behavior. It maps cleanly to a hash table, which makes it straightforward to parse and work with programmatically.

How it looks:

# Application configuration (Also supports comments)

[app]
name = "MyApp"
version = "1.0.0"
debug = false

[database]
host = "localhost"
port = 5432
name = "myapp_db"

[server]
host = "0.0.0.0"
port = 8080
allowed_origins = ["https://example.com", "https://app.example.com"]

[[users]]
name = "Alice"
role = "admin"

[[users]]
name = "Bob"
role = "editor"

The [[double bracket]] syntax is how TOML handles arrays of tables which looks a little unusual at first but becomes intuitive quickly.

TOML has become the standard for Rust projects through Cargo.toml and Python packaging through pyproject.toml. It's also picking up adoption in Go and other ecosystems. It works best for application configuration where you want clarity and correctness without a lot of ambiguity.

Pros

Very few surprises. The spec is strict enough that parsing behavior is consistent across different implementations
Supports comments
Types are explicit. Dates, integers, floats, and strings are all clearly typed with no implicit coercion
The section-based structure feels natural for grouping related settings

Cons

Not as universally supported as JSON or YAML across all languages and frameworks
Gets awkward with deeply nested structures
Not really designed for general-purpose data exchange. It’s a configuration format and works best when treated as one

Other Formats Worth Knowing

XML

This was the dominant format used for REST APIs before JSON took over. It’s verbose and harder to read, but it’s still widely used in enterprise systems, SOAP APIs, and document formats like SVG and Microsoft Office files.

<user>
  <name>John</name>
  <age>30</age>
  <active>true</active>
</user>

CSV (Comma-Separated Values)

CSV’s simplicity and ubiquity have made it the most common format for tabular data, spreadsheets, and data pipelines, despite its limitations which includes: lack of type information, nesting, and a consistent standard for special characters. Its widespread adoption stems from universal accessibility and broad tool support.

id,name,email,role,active
1,Alice,alice@example.com,admin,true
2,John,john@example.com,editor,true
3,Carol,carol@example.com,viewer,false

Protocol Buffers (Protobuf)

Built by Google, is a binary serialization format focused on performance and efficiency. It’s not human-readable, but it produces significantly smaller payloads and parses faster than any text-based format. It’s commonly used in gRPC services and high-throughput microservice architectures. You define your data structure in a .proto schema file first, then Protobuf generates the serialization code for your language.

syntax = "proto3";

message User {
  string name = 1;
  int32 age = 2;
  string email = 3;
  repeated string roles = 4;
}

Running protoc --go_out=. user.proto against that file generates a user.pb.go file containing the User struct and all the binary encoding logic. You never write or touch that file. What you do write is your own application code that imports and uses the generated struct.

// This is inside the auto-generated user.pb.go - you don't write this
type User struct {
    Name   string   `protobuf:"bytes,1,opt,name=name"`
    Age    int32    `protobuf:"varint,2,opt,name=age"`
    Email  string   `protobuf:"bytes,3,opt,name=email"`
    Roles  []string `protobuf:"bytes,4,rep,name=roles"`
}

Those struct tags carry the field number information at runtime so proto.Marshal knows how to encode each field into binary. In your own code, you import the generated package and use it like this:

// This is your application code - you write this
user := &pb.User{
    Name:  "John",
    Age:   30,
    Email: "john@example.com",
    Roles: []string{"admin", "editor"},
}

// Serialize to binary
data, err := proto.Marshal(user)

// Deserialize back
user2 := &pb.User{}
err = proto.Unmarshal(data, user2)
fmt.Println(user2.Name) // John

It is important to understanding that the field numbers in the .proto file (the = 1, = 2 next to each field) are what Protobuf actually writes to the binary output, not the field names. Each field is encoded as a tag followed by its value. The tag is a single byte that packs two things together: the field number and a wire type.

The wire type tells the decoder how to read the bytes that follow. For example, wire type 0 means read a variable-length integer, wire type 2 means read the next byte as a length then read that many bytes (used for strings and arrays), and wire type 1 means always read 8 bytes (used for doubles). So from a single byte the decoder knows both which field it's reading and how many bytes to consume for the value.

This is why Protobuf payloads are so compact. Instead of writing "name": "John" as a string key-value pair like JSON, it writes a tag byte followed directly by the value with almost no structural overhead. For the name field, the actual bytes on the wire look like this:

0x0a 0x04 0x4a 0x6f 0x68 0x6e

0x0a is the tag byte encoding field number 1 and wire type 2 (length-delimited). 0x04 is the string length (4 bytes for "John"). The remaining four bytes are the UTF-8 characters J, o, h, n. That's the entire field, six bytes total. The equivalent in JSON, "name": "John", is 14 characters. It also means field numbers are permanent. If you change one after data has already been serialized, you'll break deserialization of existing data because the tags no longer match.

This is also why the .proto file needs to be shared between services. The binary output is not self-describing, so without the schema, the bytes are meaningless. JSON carries its field names in the payload itself, which is why any parser can read it without prior knowledge of the structure. In practice, teams using Protobuf keep their .proto files in a shared repository that all services reference so everyone stays in sync.

Pardon me for rambling so much about Protobuf. It is not the most common format you’ll encounter day to day, but I got carried away learning more about it during research and felt compelled to share.

MessagePack

It takes the same structure as JSON but serializes it as binary. The result is a much smaller payload with faster parsing. It shows up in real-time applications and anywhere that bandwidth or latency is a serious concern. The API feels familiar to anyone used to JSON.

import { encode, decode } from "@msgpack/msgpack";

const data = { name: "John", age: 30, active: true };

// Serialize
const encoded: Uint8Array = encode(data);

// Deserialize
const decoded = decode(encoded);
console.log(decoded); // { name: "John", age: 30, active: true }

For the name field with value "John", the MessagePack binary output looks like this:

0xa4 0x4a 0x6f 0x68 0x6e

Compare that to Protobuf’s encoding of the same value which was six bytes: 0x0a 0x04 0x4a 0x6f 0x68 0x6e. Protobuf needed two bytes of overhead (the tag byte and the length byte) before the value. MessagePack only needed one because it packs the type and length into a single byte for short strings.

The more important difference between the two is that MessagePack is self-describing. The encoded bytes carry enough information to deserialize the data without any external schema. Anyone with a MessagePack decoder can read the bytes and get back the original structure. Protobuf cannot do this. Without the .proto file, the binary output is meaningless. This makes MessagePack more flexible for ad hoc data exchange, while Protobuf is better suited for structured service-to-service communication where both sides share a schema and need strict type contracts.

Many Tools Accept Multiple Formats

Some developers may be surprised that popular tools like Prettier use multiple serialization formats, inferring the configuration format from the file extension. Valid configuration methods include:

.prettierrc             (JSON or YAML, no extension)
.prettierrc.json
.prettierrc.yaml
.prettierrc.yml
.prettierrc.toml
prettier.config.js

The same is true for ESLint (.eslintrc.json, .eslintrc.yaml, .eslintrc.js), Babel, Stylelint, and many other tools in the JavaScript ecosystem. The data inside is structurally the same regardless of which format you use. It's just a matter of preference.

This is worth keeping in mind when setting up a project. If your team is more comfortable with YAML than JSON, or you want to be able to leave comments in your config, you often have that option without having to change tools.

Converting Between Formats

Sometimes, you might take over a project with one format and need to switch it, or you may have to convert a configuration file to align with the requirements of a specific tool. Fortunately, there are tools available that can handle this for you, saving you from the hassle of manual rewriting.

For online converters, sites like transform.tools are very handy. You can paste JSON and get YAML, TOML, CSV, and several other formats back in seconds. It covers a wide range of conversions and is probably the quickest option for one-off tasks.

Transforming JSON to YAML in transform.tools

If you prefer working in the terminal or writing scripts, most programming languages offer libraries that simplify data format conversion. For instance, in Python, converting a YAML file to JSON takes just a few lines.

import json
import yaml

with open("config.yaml") as f:
    data = yaml.safe_load(f)

with open("config.json", "w") as f:
    json.dump(data, f, indent=2)

Using the yaml library, you can safely load the contents of a YAML file, and with the json library, you can write the data back out as a JSON file with proper formatting. This approach can also be reversed or applied to any two formats supported by parser libraries available in your chosen language.

Remember that conversions are not always lossless. YAML and TOML support comments, whereas JSON does not. Consequently, converting a well-commented YAML or TOML file to JSON will result in the loss of those comments. Additionally, TOML includes explicit date and time types that lack a direct equivalent in JSON, which means such values might be converted into plain strings depending on the tool used. Always carefully review the output before finalizing or committing to it.

How to Choose the Right Format

There’s no one-size-fits-all answer, but some practical defaults can guide your decision:

For APIs or data exchange over HTTP, JSON is the best starting point. It’s universally supported and works seamlessly with any programming language.
For tabular data or files that non-developers need to access and edit, CSV remains the most practical and accessible choice.
For CI/CD pipelines, container orchestration, or infrastructure tooling, YAML is the industry standard. Familiarize yourself with its quirks and always use a linter to avoid errors.
For application configuration, especially in languages like Rust or Python, consider TOML. It’s clean, explicit, and avoids many of YAML’s pitfalls.
For high-volume, low-latency communication between internal services, explore Protocol Buffers or MessagePack. While you lose human-readability, you gain significant performance advantages.

Conclusion

Serialization formats are something most developers pick up implicitly over time. You use JSON because the tutorial used JSON. You use YAML because Kubernetes uses YAML. That’s fine as a starting point, but understanding why each format exists and what it’s optimized for makes you more deliberate about these choices.

JSON is universal and simple, making it the default for data exchange. YAML prioritizes readability and is well-suited for configuration-heavy tools. TOML offers clarity and consistency for application config. Binary formats step in when performance becomes a real constraint.

None of them are perfect for every situation. Knowing the tradeoffs means you can pick the right tool rather than defaulting to whatever was used in the last project.

This is also by no means an exhaustive list. There are formats I didn’t cover here, like Avro, BSON, INI, HCL, and others that have their own niches and communities around them. If you work with one regularly or think it deserved a mention, feel free to drop it in the comments. I’d love to hear which formats others are using and what problems they’re solving with them.

[Boost]

Rowland — Wed, 25 Feb 2026 01:04:37 +0000

How to Land a Tech Job in the USA in 90 Days: Your 2026 Action Plan

Oluchi John for FastApply ・ Feb 16

#howtolandatechjobinusa #landatechjobin90days #90daystechjobplan #2026techjobplan

Understanding Website Cookies And Why We “Accept” Them

Rowland — Fri, 24 Oct 2025 10:41:08 +0000

Introduction

Before you read this article, “Do you accept my cookies”? Chances are, you’ve clicked “accept” on numerous cookie pop-ups over the past few weeks without fully understanding why. Cookies have become so ubiquitous now that you can hardly visit any site for the first time without getting those familiar pop ups seeking for your approval.

But why do websites ask for permission to use cookies in the first place? What would happen if they just used them without asking? And if you’re building a website yourself, what do you need to know? Let’s dive into the world of cookies, privacy laws, and what it all means for both users and website owners.

What are web cookies?

Let’s go over what cookies actually are: Web cookies are small text files that websites store on your device to remember information about you and your browsing activity. They are used to personalize your online experience, such as remembering login information or items in a shopping cart, and to make websites more user-friendly.

The image below shows how cookies actually look like when viewed with your browser’s DevTools

Source: Chrome for Developers

How cookies are stored on your device?

When you visit some websites, they sends cookies to your browser, which stores them on your device. Then on subsequent visits, your browser returns the cookie to the server, allowing it to recognize you and personalize your experience.

Source: O’Reilly Media

If that’s it and cookies are so harmless, why the constant consent requests?

The Legal Framework Behind Cookie Consent

The cookie consent requirement isn’t just a courtesy. It’s mandated by law, particularly by the EU’s General Data Protection Regulation (GDPR) and similar privacy regulations around the world. These laws require websites to obtain your explicit consent before storing certain types of cookies on your device.

Source: Futuretheory

It’s important to note that not all cookies require consent. Strictly necessary cookies, such as those that keep you logged into a website or remember items in your shopping cart, are generally exempt. The consent requirement primarily applies to tracking and advertising cookies, analytics cookies that monitor your behavior, and third-party cookies from external services.

The Consequences of Non-Compliance

So what happens if a website simply ignores these requirements and uses cookies without permission? The consequences can be severe. Under GDPR, companies can face fines of up to €20 million or 4% of their global annual revenue, whichever is higher. Beyond regulatory fines, companies also risk lawsuits from privacy regulators and class action lawsuits from users.

Tech giants like Google, Amazon, and Meta have collectively been fined hundreds of millions of euros for cookie violations. The reality is that before these privacy laws existed, websites did exactly what many of us might prefer: they simply used cookies without asking. The annoying banners we see today are the direct result of regulations attempting to give users control over their personal data.

How Tracking Cookies Actually Work

To understand why these laws exist, it helps to see concrete examples of what these cookies actually do.

Tracking and Advertising Cookies

Consider the Facebook Pixel. When you visit an online store, Facebook places a cookie on your device that tracks which products you view. Later, when you’re scrolling through Instagram, you suddenly see ads for those exact products. That cookie has followed you from the store to Facebook’s platforms, creating a connection between your browsing behavior and the ads you see.

Google Ads operates similarly through retargeting. Browse vacation rentals in Hawaii without booking, and you’ll likely see Hawaii rental ads following you across random blogs, news sites, and YouTube for the next week. One cookie tracking you across all these different websites.

Analytics Cookies

Analytics tools like Google Analytics track far more than just page views. They monitor how long you spend reading articles, which links you click, what device you’re using, and whether you’re a returning visitor. Over time, they build a detailed profile of your behavior that website owners use to optimize their content strategy.

Heatmap tools like Hotjar take this even further, recording where your mouse moves, what you click, and how far you scroll down a page. Some can even record your actual browsing session like a video replay.

Third-Party Cookies

Perhaps most surprisingly, even elements you don’t interact with can track you. That innocent “Share on X” button isn’t just a button. It allows X to know you visited that page, even if you never click it. Embedded YouTube videos let Google track every page where you watched a video, building a comprehensive profile of your interests across the entire web. Even “Sign in with Google” or “Sign in with Facebook” buttons can track which sites you visit, whether or not you use them to log in.

The fundamental issue is that these cookies allow companies to follow you across the internet and build detailed profiles about your interests, shopping habits, and online behavior, often without you having any awareness it’s happening.

The image below illustrates the difference between first party and third party cookies

Source: Kwanzoo

What Website Owners Need to Know

If you’re building a website, understanding your responsibilities around cookies is crucial. The moment you include elements like Google Sign-In buttons, embedded YouTube videos, or similar third-party services, you become responsible for the cookies they place on your visitors’ devices. Even though you didn’t create those cookies, they’re on your website, and you need to get consent.

Implementation Options

You have several approaches to handle this properly. The most common is implementing a cookie consent banner using tools like CookieBot, OneTrust, or similar services. These present users with clear options before any tracking cookies are loaded.

An increasingly popular alternative is using click-to-load placeholders. Instead of auto-loading a YouTube video (which immediately places cookies), you show a placeholder image. The video and its associated cookies only load when the user actively clicks to watch it. This approach is less intrusive and provides implicit consent through user action.

You can also explore privacy-focused alternatives, such as YouTube’s privacy-enhanced mode (using the youtube-nocookie.com domain), self-hosting videos instead of using YouTube, or implementing privacy-focused authentication methods instead of relying on Google or Facebook.

The Reality of Compliance

Here’s the uncomfortable truth: many smaller websites don’t implement cookie consent properly and technically violate GDPR. While enforcement typically focuses on larger companies with deeper pockets, the legal requirement applies to everyone operating in the EU or serving EU visitors. If you’re building a website for public use, especially if you expect international traffic, implementing a proper cookie consent solution is the safest and most ethical approach.

Other Important Cookie Considerations

Cookie Lifespan

Cookies aren’t all created equal in terms of how long they stick around. Session cookies disappear the moment you close your browser, which is why you might need to log back into a website after closing and reopening your browser. Persistent cookies, however, can remain on your device for months or even years. This is why you might see ads for something you searched for weeks ago — those tracking cookies are still there, quietly doing their job.

The Changing Landscape of Third-Party Cookies

The distinction between first-party and third-party cookies matters more than ever. First-party cookies are set by the website you’re actually visiting and are generally less controversial. Third-party cookies, set by external domains like ad networks, are the primary tracking mechanism that has raised privacy concerns.

Major browsers are responding to these concerns. Safari and Firefox already block third-party cookies by default, and Google Chrome is in the process of phasing them out entirely. This represents a seismic shift in how online tracking works.

Taking Control of Your Cookies

As a user, you’re not powerless. Every major browser allows you to view exactly what cookies are stored on your device, see what data they contain, and delete them individually or all at once. You can find these options in your browser’s privacy settings, and it’s surprisingly revealing to see just how many tracking cookies accumulate during normal browsing.

Cookie Walls and Consent

You may have encountered websites that present what’s known as a “cookie wall”: accept cookies or you can’t use the site. In the EU, this practice exists in a legal gray area. Many regulators consider it non-compliant because true consent must be freely given, not coerced by blocking access to content.

The Future of Tracking

It’s worth noting that cookies themselves aren’t inherently problematic. They enable genuinely useful features like staying logged in, remembering your preferences, and keeping items in your shopping cart. The controversy specifically surrounds tracking cookies that follow you around the internet without providing clear benefits to you.

However, as cookies face increasing restrictions, tracking isn’t simply disappearing. Companies are developing “cookieless tracking” methods, including browser fingerprinting and server-side tracking techniques. The tools may evolve, but the fundamental tension between user privacy and data-driven business models continues.

Conclusion

Cookie consent banners may be annoying, but they represent an important shift in how we think about online privacy. They’re a visible reminder that our browsing behavior is valuable data, and that we have a right to control who collects it and how it’s used.

For internet users, understanding cookies helps you make informed decisions about your privacy. You can choose which cookies to accept, regularly clear tracking cookies, or use privacy-focused browsers and extensions to limit tracking.

For website owners and developers, proper cookie consent isn’t just about legal compliance. It’s about respecting your visitors and being transparent about how their data is collected and used. Yes, implementing cookie consent adds complexity to your website, but it’s the right thing to do in an era where privacy concerns are more pressing than ever.

The conversation around cookies and privacy is far from over. As technology evolves and regulations adapt, we’ll continue to see changes in how websites track users and how users protect their privacy. But the fundamental principle remains: people have a right to know what data is being collected about them and to have meaningful control over that collection.

The next time you see a cookie banner, you’ll know exactly why it’s there and what’s at stake in that simple “Accept” or “Reject” decision.

Thank you for “accepting my cookies” and reading until the end.

How to Upgrade to The New Ubuntu 25.10 “Questing Quokka”

Rowland — Fri, 24 Oct 2025 10:29:13 +0000

Ubuntu 25.10, with the code-name Questing Quokka, is the latest stable release as of October 9, 2025, bringing many notable enhancements across the desktop experience, system security, and under-the-hood improvements. For users currently on Ubuntu 24.04 LTS or earlier versions, understanding how to enjoy these features while planning an eventual step up to Ubuntu 26.04 LTS is important.

What’s New in Ubuntu 25.10?

Ubuntu 25.10 includes GNOME 49, providing a more polished, user-friendly desktop experience with new lock screen media controls, smoother animations, and better support for fractional scaling on high-resolution displays. A major change for GNOME users is the removal of the traditional Xorg/X11 desktop session; GNOME now runs exclusively on Wayland, improving graphics performance and security while maintaining legacy support for X11 apps via XWayland.

Security is a primary focus in 25.10, which introduces a Rust-based reimplementation of the sudo command (sudo-rs) and core command-line utilities (rust-coreutils). This enhances memory safety and reduces vulnerabilities in essential system tools. The installer now supports TPM-backed full disk encryption on compatible devices, making encryption stronger and easier to recover via new built-in recovery key management options.

Ubuntu 25.10 also ships with Linux kernel 6.17 and Mesa 25.2 graphics drivers, offering improved hardware support including new Intel Lunar Lake chipsets and better support for AMD ray tracing and NVIDIA performance on graphics. Other user-facing additions include two new default apps: the GPU-accelerated Ptyxis terminal with advanced features like multiple profiles and container workflows, and Loupe, a modern, gesture-friendly image viewer.

Beyond new features, Ubuntu 25.10 refines many existing components: the Software Updater is less intrusive, desktop icons now have more keyboard shortcuts, and the Raspberry Pi variant gains a robust A/B boot system for safer updates.

Planning Upgrades to 25.10 and Beyond

If you are running Ubuntu 24.04 LTS or lower, a direct jump to 25.10 is not officially supported yet. Instead, the recommended upgrade path is incremental:

Upgrade from 24.04 LTS to 24.10
Then from 24.10 to 25.04
Then from 25.04 to 25.10

Following this approach minimizes the risk of broken dependencies and system instability.

Looking ahead, Ubuntu 26.04 LTS is scheduled for April 2026. When planning to upgrade to 26.04 LTS, upgrading sequentially through the 25.x releases now (especially 25.10) reduces the number of steps needed later and ensures your system is ready for the next LTS milestone.

Upgrading via the Terminal

If you are currently on an LTS release, you may need to adjust your system’s release upgrade settings in /etc/update-manager/release-upgrades by setting Prompt=normal to allow upgrades to non-LTS versions.

To do that, run:

sudo nano /etc/update-manager/release-upgrades

And set Prompt=normal

Then, follow these general steps for each intermediate version:

Update and upgrade your current system:

sudo apt update && sudo apt upgrade -y

Launch the release upgrade process

sudo do-release-upgrade

Reboot when prompted and confirm you have the new version before proceeding to the next upgrade by repeating the first two steps above.

Fresh Install Considerations

Sometimes, a fresh installation of Ubuntu 25.10 or future 26.04 LTS can be beneficial for a clean start. Keep in mind that a clean install erases existing apps and settings by default.

To keep some of your apps, config and settings:

Export your installed .deb package list before reinstalling:

sudo dpkg --get-selections > package.list

Back up your home directory and hidden config files to preserve personal settings.

tar -cvpzf backup-home.tar.gz /home/<your_username>

Perform the clean install, during installation, choose the option to overwrite the existing system.
Reinstall your packages:

sudo dpkg - set-selections < package.list
sudo apt-get dselect-upgrade

Reinstall your user files and configs

tar -xvpzf backup-home.tar.gz -C /home/your_username

This approach ensures you maintain your personalized environment while benefiting from the clean install’s stability.

Conclusion

Ubuntu 26.04 LTS offers significant advancements that make upgrading or reinstalling worthwhile. While the upgrade process is best done in stages through supported releases, a fresh install combined with careful backups can provide a clean and efficient transition. Whichever method you choose, Ubuntu’s vibrant community and robust tooling ensure a smooth experience moving forward.

Understanding Web and Internet Fundamentals

Rowland — Fri, 10 Oct 2025 12:42:48 +0000

Introduction

Behind every website you visit, video you stream, or message you send, there’s a sophisticated chain of communication happening that you never see. Understanding how servers, DNS, protocols, ports, and other internet concepts and technologies work together isn’t just for developers, it’s like learning the basic mechanics of a car. You don’t need to be a mechanic to drive, but knowing what’s under the hood helps you make better decisions and troubleshoot when things go wrong.

This guide breaks down the essential building blocks of the internet and web, explaining not just what they are, but how they work together to make our connected world possible.

The Foundation: Servers and Clients

At its core, the internet operates on a simple relationship: one computer asks for something, and another computer provides it. The computer doing the asking is called a client (the browser in your phone or computer), and the computer providing the resource is called a server.

Source: O’Reilly Media

A server isn’t necessarily a massive machine in a data center, it’s any computer configured to respond to requests. Your laptop could be a server if you set it up that way. What makes something a server is its role, not its hardware.

When you type “google.com” into your browser, you’re using a client to request Google’s homepage from their servers. The server processes your request and sends back the HTML, CSS, and JavaScript that your browser assembles into the page you see.

How Computers Find Each Other

IP Addresses

Every device connected to the internet needs an address, just like every house needs a street address for mail delivery. That’s where IP addresses come in. An IP address is a unique numerical identifier like 192.168.1.1 (IPv4) or the longer 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (IPv6).

Think of it this way: if the internet is a massive city, IP addresses are the exact coordinates of every building. But there’s a problem, we humans aren’t great at remembering long strings of numbers.

Domain Names and DNS

This is where domain names and the Domain Name System (DNS) save the day. A domain name like amazon.com is simply a human-friendly alias for an IP address. When you type a domain name, your computer asks a DNS server, "What's the IP address for this domain?" The DNS server responds with the actual IP address, and your computer uses that to connect.

DNS is often called the “phone book of the internet,” but it’s more like a constantly updated GPS system that helps you find the right destination every time.

Here’s a fun exercise to try out; Type 216.58.223.238 in your browser and see where that leads you.

URLs: The Complete Address

A URL (Uniform Resource Locator) is the full address you see in your browser’s address bar. It contains several parts:

Protocol: https:// tells your browser how to communicate
Domain: bbc.com identifies the server
Port: :443 (often hidden) specifies which service to use
Path: /sport/football points to a specific resource

So https://bbc.com:443/sport/football is a complete instruction set for retrieving football content from BBC’s server.

Ports: Multiple Services, One Address

Here’s where things get interesting. A single server with one IP address can run dozens of different services simultaneously; a web server, an email server, a file transfer server, and more. How does incoming traffic know which service to reach? Ports.

Think of an IP address as a large apartment building, and ports as individual apartment numbers. Port numbers range from 0 to 65,535, and certain numbers are standardized for specific services:

Port 80: HTTP (unsecured web traffic)
Port 443: HTTPS (secured web traffic)
Port 25: SMTP (email sending)
Port 22: SSH (secure remote access)
Port 3306: MySQL database

When you visit a website, your browser automatically connects to port 443 (for HTTPS) or port 80 (for HTTP) unless you specify otherwise. This combination of IP address and port number creates a socket which is a unique endpoint for communication.

Protocols: The Language of the Internet

Computers need to speak the same language to understand each other. Protocols are simply agreed-upon rules and standards for communication. These protocols define everything from how data is packaged and addressed to how errors are handled and connections are maintained.

When you send data, it doesn’t travel as one piece. Instead, it passes through multiple layers, with each adding its own header information in a process called encapsulation.

Data movement across a network follows the Open Systems Interconnection (OSI) Model, a seven-layer framework. As data travels down the layers (encapsulation), each layer adds a header with its specific control information (e.g., ports at Transport layer, IP addresses at Network layer). At the destination, the process reverses (decapsulation).

Source: NetBeez

At the Transport Layer (Layer 4) of the OSI model, data is managed by two primary protocols: TCP and UDP.

TCP: The Reliable Data Transfer Protocol

TCP (Transmission Control Protocol) is a connection-oriented protocol that prioritizes reliability over speed. Before any data is transmitted, TCP performs a three-way handshake (SYN, SYN-ACK, ACK) to establish a connection between client and server. It then breaks data into segments, numbers each one sequentially, and transmits them. The receiving end sends acknowledgments (ACKs) for received segments, and TCP retransmits any that go missing or arrive corrupted.

TCP also handles congestion control, automatically adjusting transmission rates based on network conditions. TCP is used for web pages (HTTP/HTTPS), email (SMTP, IMAP), file transfers (FTP), and any application where data integrity is critical.

UDP: The Fast Data Transfer Protocol

UDP (User Datagram Protocol) is a fast, minimalist transport protocol used on the internet. It works by sending small units of data, called datagrams, to a destination without setting up a formal connection first (it’s connectionless).

Because of its speed, UDP is perfect for time-sensitive applications where a little lost data is better than waiting to recover it. UDP is used in video streaming, DNS queries and online gaming.

Source: Storm Streaming

HTTP: Web Traffic

HTTP (Hypertext Transfer Protocol) is an application-layer (layer 7) protocol that defines the structure of requests and responses between web clients and servers. It’s a stateless protocol, meaning each request-response pair is independent i.e., the server doesn’t inherently remember previous interactions.

An HTTP request consists of a request line (method, URI, and HTTP version), headers (metadata like Content-Type, User-Agent, and Accept), and an optional body. Common HTTP methods include:

GET: Retrieve a resource
POST: Submit data to be processed
PUT: Update or create a resource
DELETE: Remove a resource
HEAD: Retrieve headers only (useful for checking if content has changed)

The server responds with a status line (HTTP version, status code, and reason phrase), response headers, and usually a body containing the requested content. Status codes are grouped by category:

200–299 for success
300–399 for redirects
400–499 for client errors, (where the infamous 404 lives)
500–599 for server errors..

HTTPS: Secure Web Traffic

HTTPS is HTTP secured with TLS (Transport Layer Security), the successor to SSL (Secure Sockets Layer). When you connect to an HTTPS site, your browser and the server perform a TLS handshake. The server presents a digital certificate proving its identity, and both sides use a complex, slow process (asymmetric encryption, like RSA) to securely agree on a secret code, called a session key. All subsequent data (the actual website content) is encrypted using the shared session key in a faster method (symmetric encryption, like AES).

This provides three critical security properties: confidentiality (data can’t be read by eavesdroppers), integrity (data can’t be modified without detection), and authentication (you’re communicating with the real server, not an impostor).

The padlock icon 🔒 in your browser verifies that the server’s certificate is valid and trusted.

Source: Nix United

In a nutshell, HTTP is an insecure connection that can be intercepted and read by anyone, but HTTPS is HTTP secured with TLS encryption, meaning the data is scrambled and protected from eavesdroppers.

IP: Routing Protocol

IP (Internet Protocol) operates at the network layer (Layer 3) and is responsible for addressing and routing packets across networks. IP gives every device a unique IP address (its label or “street address”) and uses that address to figure out the best path for data transfer.

When you send data, IP breaks it into packets and forwards each one toward its destination. Each IP packet contains a header with source and destination IP addresses, a time-to-live (TTL) value, protocol identifier (indicating whether the payload is TCP, UDP, or something else), and other control information.

Routers read the destination address on the packet’s header to decide where to send it next (next hop). The TTL value of each packet counts down with every hop. If the TTL reaches zero, the packet is thrown away. This prevents packets from endlessly circulating the network if a routing error occurs.

IP is connectionless and unreliable by design. It makes a best-effort attempt to deliver packets but provides no guarantees. Packets might arrive out of order, get duplicated, or be dropped entirely due to network congestion or routing failures. Higher-layer protocols like TCP handle reliability concerns.

There are two versions in use: IPv4 uses 32-bit addresses (about 4.3 billion possible addresses) and is running out of available addresses, while IPv6 uses 128-bit addresses (enough for trillions of trillions of addresses) and is gradually being adopted worldwide.

The Request-Response Cycle

Let’s put it all together with what happens when you visit a website:

You type https://example.com/blog into your browser
Your browser asks a DNS server for the IP address of example.com
DNS responds with the IP address (e.g., 93.184.216.34)
Your browser establishes a TCP connection to that IP address on port 443
An SSL/TLS handshake encrypts the connection
Your browser sends an HTTP GET request for /blog
The server processes the request and sends back an HTTP response with the HTML content
Your browser receives the response, renders the page, and makes additional requests for images, stylesheets, and scripts
The TCP connection eventually closes

This entire process typically happens in under a second, with multiple requests happening simultaneously.

APIs and Modern Web Architecture

As the web evolved, servers started doing more than just serving HTML pages. APIs (Application Programming Interfaces) allow different programs to communicate with servers using structured requests and responses. This communication typically involves sending and receiving JSON (JavaScript Object Notation) data, which is faster and lighter than sending a full webpage.

For instance, instead of the server sending an entire blog page (with headers, footers, and sidebars), it can use an API to send only the raw content of the blog post. This data can then be used by a mobile app, a separate web application, or a browser to display the content how it needs to.

REST API

REST API (Representational State Transfer) is a popular architectural style for building APIs. It uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources identified by URLs. For example:

GET /api/users/123 retrieves user data
POST /api/users creates a new user
PUT /api/users/123 updates user data
DELETE /api/users/123 deletes a user

Source: iDempiere

This approach powers most modern web applications, mobile apps, and connected services.

Network Management and Security

Firewalls

A firewall acts as a security guard, monitoring network traffic and blocking potentially harmful connections based on predefined rules. It can block specific ports, IP addresses, or types of traffic to protect servers from attacks.

Load Balancers

When a website becomes popular, one server isn’t enough. A load balancer sits in front of multiple servers and distributes incoming requests among them. If one server fails, the load balancer routes traffic to the healthy servers, ensuring the website stays online.

Proxy Servers

A proxy server acts as an intermediary between clients and servers. It can cache content to improve performance, filter requests for security, or mask the client’s IP address for privacy. Many organizations use proxy servers to control and monitor internet access.

Performance and Optimization

Several factors affect how fast and reliably data travels across the internet:

Bandwidth

Bandwidth is the maximum amount of data that can be transferred in a given time period, like the width of a highway. More bandwidth means more data can flow simultaneously.

Latency

Latency is the time it takes for data to travel from one point to another, like the speed limit on that highway. Lower latency means faster response times. Geographic distance, network congestion, and the number of intermediate routers all affect latency.

Packets

Packets are the small chunks that data gets broken into for transmission. Each packet contains both the actual data (payload) and information about where it’s going and where it came from. Breaking data into packets allows for more efficient use of network resources and better error handling.

Conclusion

The internet might seem like magic, but it’s really a carefully orchestrated system of protocols, addresses, and services working together. Servers and clients communicate through well-defined ports using agreed-upon protocols. Domain names make the internet human-friendly, while IP addresses and routing make it functional. Security layers like HTTPS protect our data, and architectural patterns like REST make building connected applications possible.

Understanding these fundamentals doesn’t just satisfy curiosity, it empowers you to troubleshoot problems, make informed decisions about web technologies, and appreciate the remarkable engineering that connects billions of devices worldwide. The next time you load a webpage in a fraction of a second, you’ll know the invisible symphony of technology making it happen.

These concepts form the foundation of everything that happens online. The internet is complex, but at its core, it’s just computers talking to each other and now you know their language.

Understanding Shallow Copy vs Deep Copy in JavaScript

Rowland — Tue, 07 Oct 2025 10:51:07 +0000

Introduction

If you've ever worked with objects or arrays in JavaScript, you might have run into unexpected mutations. You modify what you thought was a copy, only to find that the original data has changed too. This behavior can lead to subtle bugs that are hard to track down.

The root cause of this problem lies in how JavaScript handles references to complex data types. When you work with objects and arrays, you're often working with references rather than actual copies of the data. Understanding the difference between shallow and deep copying is crucial for writing predictable, bug-free code.

In this guide, we'll explore what shallow and deep copies are, how to create them, when to use each approach, and common pitfalls to avoid when copying data structures in JavaScript.

Methods of Copying in JavaScript?

In JavaScript, there are two main approaches to copying objects and arrays:

Shallow Copy creates a new object or array, but only copies the top-level properties. Any nested objects or arrays inside it are still referenced rather than copied. This means that if you modify a nested structure in the copied version, it also affects the original.

Deep Copy creates an entirely new object or array by recursively copying all nested structures. This results in a fully independent clone where changes in the copied structure do not affect the original at all.

Shallow Copy Techniques

A shallow copy creates a new object or array at the top level, but nested objects or arrays remain as references to the original data. Let's explore the different ways to create shallow copies.

Shallow Copying Objects

There are two primary methods for shallow copying objects:

Using the Spread Operator (...)

The spread operator is the most modern and concise way to create a shallow copy of an object:

const originalUser = {
  name: "John",
  age: 30,
  address: {
    city: "New York",
    zip: "10001"
  }
};

const shallowCopy = { ...originalUser };

// Modifying top-level property (safe)
shallowCopy.name = "Bob";
console.log(originalUser.name); // "John" - unchanged

// Modifying nested property (affects original!)
shallowCopy.address.city = "Los Angeles";
console.log(originalUser.address.city); // "Los Angeles" - changed!

Using Object.assign()

The Object.assign() method copies all enumerable properties from one or more source objects to a target object:

const originalUser = {
  name: "John",
  age: 30,
  address: {
    city: "New York",
    zip: "10001"
  }
};

const shallowCopy = Object.assign({}, originalUser);

// Same behavior as spread operator
shallowCopy.age = 35; // Safe - only affects copy
shallowCopy.address.zip = "90001"; // Affects original!

Shallow Copying Arrays

Arrays can also be shallow copied using several methods:

Using the Spread Operator (...)

const originalArray = [1, 2, [3, 4]];
const shallowCopy = [...originalArray];

// Modifying top-level element (safe)
shallowCopy[0] = 99;
console.log(originalArray[0]); // 1 - unchanged

// Modifying nested array (affects original!)
shallowCopy[2][0] = 99;
console.log(originalArray[2][0]); // 99 - changed!

Using slice() Method

const originalArray = [1, 2, [3, 4]];
const shallowCopy = originalArray.slice();

// Same shallow copy behavior

Using concat() Method

const originalArray = [1, 2, [3, 4]];
const shallowCopy = [].concat(originalArray);

// Same shallow copy behavior

Deep Copy Techniques

A deep copy recursively copies all nested structures, creating a fully independent clone. Let's explore the methods available for deep copying.

Using `structuredClone()`

The structuredClone() method is a modern, built-in way to create deep copies. It works with both objects and arrays and handles most data types correctly:

const originalUser = {
  name: "John",
  age: 30,
  address: {
    city: "New York",
    zip: "10001"
  },
  hobbies: ["reading", "gaming"]
};

const deepCopy = structuredClone(originalUser);

// Modifying nested properties (safe)
deepCopy.address.city = "Los Angeles";
deepCopy.hobbies.push("cooking");

console.log(originalUser.address.city); // "New York" - unchanged
console.log(originalUser.hobbies); // ["reading", "gaming"] - unchanged

structuredClone() also works seamlessly with arrays:

const originalArray = [1, 2, { name: "John" }, [3, 4]];
const deepCopy = structuredClone(originalArray);

deepCopy[2].name = "Bob";
deepCopy[3][0] = 99;

console.log(originalArray[2].name); // "John" - unchanged
console.log(originalArray[3][0]); // 3 - unchanged

Using Lodash `_.cloneDeep()`

If you need to support older browsers or have more complex cloning requirements, Lodash's _.cloneDeep() method is a reliable third-party solution:

// First, install lodash with npm install lodash before importing
import _ from 'lodash';

const originalData = {
  name: "John",
  settings: {
    theme: "dark",
    notifications: {
      email: true,
      push: false
    }
  }
};

const deepCopy = _.cloneDeep(originalData);

deepCopy.settings.notifications.email = false;
console.log(originalData.settings.notifications.email); // true - unchanged

When to Use Each Approach

Choosing between shallow and deep copy depends on your data structure and use case:

Use Shallow Copy when:

You only need to copy the first level of an object or array
Your data structure doesn't contain nested objects or arrays
You want better performance (shallow copies are faster)
You're working with simple data structures like configuration objects with primitive values

Use Deep Copy when:

You're working with nested objects or arrays
You need complete independence from the original data
You're implementing features like undo/redo functionality
You're managing state in applications where mutations could cause bugs
You need to clone complex data structures without side effects

Common Pitfalls to Avoid

Even experienced developers can fall into traps when copying objects and arrays. Here are some common pitfalls and how to avoid them.

(1) Using Assignment Instead of Copying

The most common mistake is thinking that assignment (=) creates a copy:

const original = { name: "John", age: 30 };
const copy = original; // This is NOT a copy!

copy.name = "Bob";
console.log(original.name); // "Bob" - both variables point to the same object!

Fix: Always use proper copying methods like spread operator or Object.assign():

const original = { name: "John", age: 30 };
const copy = { ...original }; // Now it's a real copy

copy.name = "Bob";
console.log(original.name); // "John" - unchanged

(2) Using Shallow Copy for Nested Structures

Using shallow copy methods when you actually need a deep copy leads to unexpected mutations:

const user = {
  name: "John",
  preferences: {
    theme: "dark",
    language: "en"
  }
};

const updatedUser = { ...user }; // Shallow copy
updatedUser.preferences.theme = "light"; // Oops! Affects original

console.log(user.preferences.theme); // "light" - unexpected change!

Fix: Use structuredClone() or _.cloneDeep() for nested structures:

const user = {
  name: "John",
  preferences: {
    theme: "dark",
    language: "en"
  }
};

const updatedUser = structuredClone(user); // Deep copy
updatedUser.preferences.theme = "light";

console.log(user.preferences.theme); // "dark" - original unchanged

(3) Limitations of `structuredClone()`

While structuredClone() is powerful, it has limitations. It cannot clone:

Functions
DOM nodes
Symbols
Objects with getters/setters

const obj = {
  name: "John",
  greet: function() { return "Hello"; }, // Function won't be cloned
  symbol: Symbol("id") // Symbol won't be cloned
};

const clone = structuredClone(obj);
console.log(clone.greet); // undefined - function was not cloned

Fix: For objects with functions, use _.cloneDeep() from Lodash or implement custom cloning logic.

(4) Using `JSON.parse(JSON.stringify())` for Deep Copying

Some developers use JSON.parse(JSON.stringify(obj)) as a quick deep copy solution, but this approach has significant drawbacks:

const obj = {
  name: "John",
  date: new Date(),
  greet: function() { return "Hello"; },
  undef: undefined
};

const clone = JSON.parse(JSON.stringify(obj));

console.log(clone.date); // String, not a Date object
console.log(clone.greet); // undefined - function was lost
console.log(clone.undef); // undefined - property was removed

This method fails with:

Functions (completely removed)
undefined values (removed)
Date objects (converted to strings)
Infinity and NaN (converted to null)
Circular references (throws error)

Fix: Use structuredClone() or _.cloneDeep() instead for reliable deep copying.

Conclusion

Understanding the difference between shallow and deep copying is essential for writing reliable JavaScript code. While shallow copies are sufficient for simple, flat data structures, deep copies are necessary when working with nested objects and arrays to ensure complete independence from the original data.

The key takeaways are:

Shallow copies only duplicate the top level, leaving nested structures as references to the original data
Deep copies recursively duplicate all levels, creating fully independent clones
Use structuredClone() for modern deep copying needs, or _.cloneDeep() for more complex scenarios
Always be aware of which copying method you're using and whether it matches your data structure

By mastering these copying techniques, you'll avoid common bugs related to unexpected mutations and write more predictable, maintainable code. Whether you're managing application state, implementing undo functionality, or simply working with complex data structures, knowing when and how to properly copy your data is a fundamental skill that will serve you throughout your JavaScript journey.

Understanding Promises in JavaScript

Rowland — Thu, 02 Oct 2025 19:03:03 +0000

Introduction

JavaScript is single-threaded, meaning it executes one operation at a time. But in the real world, applications constantly need to wait for API responses, file loading, or complex computations.

Historically, this reliance on waiting led to complex, nested callback functions, often referred to as “Callback Hell.” Promises were introduced to solve this exact problem, making asynchronous code cleaner, more readable, and far more efficient.

In this guide, we’ll cover the fundamentals of Promises, how to create and consume them, and some common pitfalls to avoid when using Promises

What is a Promise?

A Promise in JavaScript is an object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value. It acts as a placeholder for a value that is not yet available.

Every Promise exists in one of three mutually exclusive states:

Pending: The initial state; the operation is still ongoing and has neither completed nor failed.
Fulfilled (or Resolved): The operation completed successfully, and the Promise now holds a resulting value.
Rejected: The operation failed, and the Promise holds a reason for the failure (usually an Error object).

Think of a Promise like ordering food:

You place the order (Promise is created — Pending).
The food arrives successfully (Promise is Fulfilled — resolve).
The kitchen can run out of ingredients (Promise is Rejected — reject).

How to create a Promise

You create a Promise using the Promise constructor, which takes one argument: an executor function.

The executor function is responsible for starting the asynchronous work. It receives two arguments, both of which are callback functions and is immediately executed when the promise constructor is called.

resolve: Call this function when the asynchronous operation succeeds.
reject: Call this function when the asynchronous operation fails.

Here is a simple example of using Promises


function myExecutor(resolve, reject) {
// async operation and logic to call resolve or reject goes here

const success = Math.random() > 0.5;

  setTimeout(function() {
    if (success) {
      // Operation succeeded, pass the result
      resolve("Operation completed successfully!");
    } else {
      // Operation failed, pass the reason/error
      reject(new Error("Operation failed"));
    }
  }, 2000);
}

const myPromise = new Promise(myExecutor);
console.log(myPromise);

In the above example, setTimeout is the asynchronous operation that calls (after 2 seconds) the resolve callback function when the success variable is true otherwise it calls the reject callback function when success is false

The myExecutor named callback function is passed to the Promise constructor, but we could just as well used an inline anonymous or arrow callback function. Feel free to brush up on callback functions in my previous post on Understanding Callback Functions in JavaScript.

Side Note: Going forward, I’ll be declaring callback functions using anonymous functions. I thing it’s easier to tell that an argument is a function if it literally has the function keyword in it. You can follow along using your preferred method.

Return Value of a Promise

A Promise does not return a value like a traditional function does, instead it provides a state which represents the eventual completion (success or failure)

This is what will get logged to the console from the last line by running the code snippet above;

Promise {<pending>}

It’s a Promise object with the pending state because that’s the initial state of every Promise, clicking on it in a browser console expands the object to show other possible states and return values.

Consuming Promises

Once a Promise is created, you use methods like .then() and .catch() to "consume" its eventual value. These methods allow you to define what happens when the Promise transitions from Pending to either Fulfilled or Rejected.

The `.then()` Method

The .then() method takes up to two handler functions as arguments:

The first function (onFulfilled) accepts as an argument the result ( value returned from the *resolve* callback function ) and runs when the Promise is Fulfilled.
The second function (onRejected) runs when the Promise is Rejected but it is optional and often skipped in favor of .catch().

Using the simple example from before, we can consume the value returned by the resolve or rejected callback function by using the .then method and the handler functions ( onFulfilled / onRejected )


myPromise.then(
  function (result) {
    // This is the onFulfilled handler that runs if resolve() was called.
    console.log(result); // logs "Operation completed successfully!"
  },
  function (error) {
    // This is the onRejected handler runs if reject() was called.
    console.error(error.message); //  Logs "Operation failed"
  }
)

Notice we log error.message to the console not just error because we passed an Error object to the reject() callback function not a string.

The `.catch()` Method

The .catch() method is syntactic sugar for .then(null, onRejected). It is the standard way to handle errors in Promises and is cleaner than putting the rejection handler inside .then(). We simply just moved the onRejected handler function to a different method.

The code snippet above can be rewritten as;

myPromise
  .then(function (result) {
    // This is the onFulfilled handler that runs if resolve() was called
    console.log(result); // logs "Operation completed successfully!"
  })
  .catch(function (error) {
    // This runs if reject() was called.
    console.error(error.message); // Logs "Operation failed"
  })

How Promises Work

The image below can help visualize how Promises work

Source: Shuai Li

From the diagram above, we can see that the state changes from pending to fulfilled if the async operation resolve with a value, that value is further passed to the .then() method for further operations.

The state can also change from pending to rejected if the async operation reject with an Error, that Error is further passed to the .catch() method for further handling

Chaining Promises

The greatest power of Promises is their ability to be chained. Because the .then() method always returns a new Promise, you can link multiple asynchronous operations together sequentially.

This is the key mechanism for escaping “Callback Hell,” as you can transform complex, deeply nested code into a flat, readable sequence.

A common example of this is the chaining done when fetching data using the fetch API:

fetch('https://example.com/api/users') // fetch() returns Promise 1
  .then(function (response) {
    // Process response from Promise 1 and return Promise 2 
    return response.json(); // response.json() returns a Promise
  })
  .then(function (data) {
    // Use the result of Promise 2
    console.log(data);
  })
  .catch(function (error) {
    // Catches any error from all steps in the chain
    console.error('Something went wrong:', error);
  })

Common Pitfalls to Avoid When Using Promises

Promises are a powerful tool for handling asynchronous operations in JavaScript, but they can be tricky to use correctly. Here are some common pitfalls to watch out for when working with Promises and how to avoid them.

(1) Forgetting That Promises Are Asynchronous:

Although promises can make our code look and feel synchronous, they are still asynchronous in nature, one can easily make the mistake of trying to access the resolved value synchronously.

const getData = () => {
fetch('https://example.com/api/users')
  .then(function (response) {
    return response.json();
  })
  .then(function (data) {
    return data; // Expecting to use the data outside the getData function
  })
  .catch(function (error) {
    return error;
  })
}

const result = getData(); // getData returns a Promise
console.log(result); // Logs Promise { <pending> }, not the data

Because getData() function contains a Promise, it runs asynchronously so when the JavaScript engine reaches the line const result = getData() it simply assigns the initial pending state Promise Object to result variable before proceeding to the next line and not the data we expected.

To fix this, we can;

chain getData() with another .then() method without assigning it to a variable

const getData = () => {
fetch('https://example.com/api/users')
  .then(function (response) {
    return response.json()
  })
  .then(function (data) {
    return data 
  })
  .catch(function (error) {
    return error;
  })
}

getData().then(function (result) {
console.log(result); // Logs the data
})

or use the top level await keyword before calling getData() like this:

const getData = () => {
fetch('https://example.com/api/users')
  .then(function (response) {
    return response.json()
  })
  .then(function (data) {
    return data 
  })
  .catch(function (error) {
    return error;
  })
}

const result = await getData(); // JS awaits the data before proceeding to the next line
console.log(result); // Logs the data

(2) Not Returning Promises in `.then()` Chains:

When chaining .then() calls, forgetting to return a Promise inside a .then() handler breaks the chain and can cause unexpected behavior.

fetch('https://example.com/api/users')
  .then(function (response) {
    response.json(); // forgetting the return keyword
  })
  .then(function (data) {
    console.log(data); // data is undefined because the previous chain did not return a promise
  })
  .catch(function (error) {
    console.error('Something went wrong:', error);
  })

To fix this; always return a Promise or value from .then() handlers.

(3) Failing to handle Promise Rejections/Failures:

If a Promise rejects and you don’t handle the error, it can cause unhandled Promise rejection warnings or crashes.

fetch('https://exmpl.com/api/users') // Typo that'll trigger reject()
  .then(function (response) {
    return response.json();
  })
  .then(function (data) {
    console.log(data);
  })
// No .catch() to handle errors

Conclusion

Promises are one of the most important features in modern JavaScript because they simplify how we deal with asynchronous code. Instead of juggling nested callbacks and messy logic, Promises give us a clean, structured way to handle success and failure. They’re the foundation for even more powerful tools like async/await, which build on the same concepts but make code look synchronous.

As you work with Promises, remember the key ideas: a Promise represents a value that may be available now, later, or never. It can be pending, fulfilled, or rejected—and how you handle those outcomes determines how reliable your code will be.

By mastering Promises, you’ll not only write more maintainable and bug-free code, but you’ll also set yourself up to understand advanced JavaScript concepts with ease. The next time you fetch data, process files, or chain multiple async operations, you’ll see just how powerful Promises really are.

Understanding Callback Functions in JavaScript

Rowland — Thu, 25 Sep 2025 13:11:30 +0000

Introduction

Have you ever wondered how JavaScript knows what to do after completing a task like waiting for a timer, handling user clicks, or fetching data from a server? That’s where callback functions come in. They are foundational to writing effective, non-blocking, and clean JavaScript code.

In this post, we’ll dive into the essentials of callbacks, covering what they are, the different ways to write them, and the crucial distinction between synchronous and asynchronous callbacks.

What is a Callback Function?

In JavaScript, functions are first-class citizens, meaning they can be passed around like variables.

A callback is simply a function passed as an argument to another function, which then gets executed later, either immediately or after a specific event or operation.

Here’s a simple example:


function greet(name) {
  console.log("Hello, " + name);
}

function runCallback(callback) {
  const name = "Rowland";
  callback(name); // invoke the callback function
}

runCallback(greet); // Output: Hello, Rowland

In this code, the greet function is the callback, passed as an argument to runCallback and executed inside it.

Important Note:

When passing the function as a callback, you pass its reference by not including parentheses like this; runCallback(greet).

Adding parentheses as in runCallback(greet()) would execute greet immediately and pass its returned value (which would be undefined in this case) as the argument, which is incorrect for a callback.

Ways of Writing Callback Functions

Callbacks can be defined in a few different ways:

Named Callbacks

A named callback is a regular function definition that has an explicit name, like the greet function in the example above.

Benefits:

Reusability: You can use the same function as a callback in multiple places.
Readability: Clearer code structure when the logic is complex.
Debugging: The function’s name appears in the call stack, making debugging easier.

Anonymous Callbacks

An anonymous callback is a function without a name that is passed directly as an argument, usually defined inline.


function runCallback(callback) {
  const name = "Rowland";
  callback(name); // invoke the callback function
}

runCallback(function(name) { 
  console.log("Hello, " + name);
}); // Output: Hello, Rowland

Arrow Function Callbacks

This is similar to anonymous callbacks but uses the modern ES6 arrow function syntax for a more concise and readable style.


function runCallback(callback) {
  const name = "Rowland";
  callback(name); // Invoke the callback function
}

runCallback((name) => { 
  console.log(`Hello, ${name}`);
}); // Output: Hello, Rowland

Types of Callback Functions

Callbacks primarily fall into two categories, based on when they are executed:

Synchronous Callbacks

A synchronous callback is executed immediately within the function it’s passed to, completing before the next line of code runs.

Common Use Cases:

Array Methods: forEach, map, filter, etc.
Custom utility functions
Higher-Order Functions (HOF).

Example with map array method:


const arr = [1, 2, 3];

function doubleNumber(num) {
  return num * 2
}

const doubled = arr.map(doubleNumber); // The callback runs immediately for each item.
console.log(doubled); // [2, 4, 6]

In this case, doubleNumber is a named callback passed to the arr.map() method.

Asynchronous Callbacks

An asynchronous callback is executed after an asynchronous operation completes, not immediately. This allows the JavaScript engine to move on to the next line of code while the operation (like a timer or network request) is pending.

Common Asynchronous Operations:

setTimeout
Event Listeners (e.g., document.addEventListener(‘event’, callback))
HTTP Requests (e.g., using fetch)

Example with setTimeout :


setTimeout(function() { 
  console.log("Runs after 2 seconds");
}, 2000);

console.log("This will execute first");

Output in the console:


This will execute first
Runs after 2 seconds

The JS engine doesn’t wait for the timer, so the second console.log executes immediately, and the callback inside setTimeout runs only after the 2000ms (2s) delay.

Conclusion

Callback functions are a core concept in JavaScript, crucial for understanding how the language manages function execution, especially with asynchronous tasks.

To Recap:

Callbacks are functions passed into other functions to be invoked later.
They can be written as named, anonymous, or arrow functions.
Synchronous callbacks run immediately (e.g., in array methods like map and forEach).
Asynchronous callbacks run after an operation completes (e.g., setTimeout, event listeners, fetch).

Understanding how and when callbacks execute is essential and sets a strong foundation for learning deeper concepts like Promises and async/await. You’ll find callbacks are everywhere as you continue to write more JavaScript!

Assignment by Value vs Assignment by Reference in JavaScript

Rowland — Wed, 24 Sep 2025 13:47:47 +0000

Introduction

It’s very common in programming to assign a variable with the value of another variable as in let x = y . You assume that y now holds a copy of x’s value. And for the most part, you'd be right. But then, you run into a bug where changing y also mysteriously changes x . Why is that?

The answer lies in one of JavaScript’s most fundamental, and often misunderstood, concepts: assignment by value vs. assignment by reference. While the syntax for assignment is always the same, what happens behind the scenes depends on the type of data you’re working with. Understanding this difference is the key to preventing a whole class of frustrating bugs.

This post is a continuation from my previous post on Understanding Mutability in JavaScript

In this post we’ll cover how assignment is handled in the different data types in JavaScript.

Assigning to a primitive data types

Primitive data types in JavaScript like strings, numbers, booleans, null, and undefined are immutable. This means their value cannot be changed after creation. When you assign a primitive from one variable to another, JavaScript creates a new, independent copy of that value.

Think of it like making a photocopy. The original document remains unchanged, and any marks you make on the copy won’t transfer back to the original.

let x = 10;
let y = x;
console.log(x, y); // 10, 10

y = 20; // Re-assigned to another value
console.log(x, y) // 10, 20 ( x remains unchanged )

Drawing from my previous diagram of variables acting as pointers, let’s take a look at what happens inside the computer when we run the code above;

After the first 2 lines of code runs, the value (10) that variable x holds is copied to another location in memory and variable y points to that location and so both variables holds the same value (10) but points to different location in memory.

After y = 20, the y pointer is moved and points to another location in memory that holds the value 20. This happens because primitive types are immutable and now both x and y points to different locations holding different values.

This same process happens in all primitive data types. When you assign a variable to the value of another variable, both variables remain independent of each other and any operation to one does not affect the other.

Assigning to an object types

Objects (including arrays and functions) are mutable, their internal properties can be changed. When you assign an object from one variable to another, JavaScript does not copy the entire object. Instead, it copies the reference to the object (its memory address). This means both variables are now pointing to the same object in memory. If a property is changed by one of the variables, that change will be reflected in the other.

Imagine you have a shared Google Doc. You send the link to a friend. You and your friend are both accessing the same document. If your friend makes changes, you’ll see them, and vice versa, because you’re both looking at the same, single document. The link is the reference, and the Google Doc is the object in memory.

Consider the example below;

let user = { name: "John", role: "user" };
let admin = user; // A copy of the reference is assigned

console.log(user);  // { name: "John", role: "user" }
console.log(admin); // { name: "John", role: "user" }

// Change a property of the object via the 'admin' variable
admin.role = "admin"; 

console.log(admin); // { name: "John", role: "admin" }
console.log(user);  // { name: "John", role: "admin" } -> The original object was changed

Let's see what happens in the computer memory when we run this code in the diagram below;

After the first two lines of code, both variables points to the same location in memory unlike in primitives where the value is copied to another location in memory. Because objects are mutable, we can directly alter the properties using the dot notation.

So after the line admin.role = “admin”; the admin variable altered the object in that location in memory and because both variables points to the same address, the change is also reflected in the user variable

This works the same for other object types like array and function

Breaking the link

A good question now is; “How do we copy the contents of the object to a different address in memory and break the link?” There are a couple of ways to do that, one of which is to simply assign the admin variable to another object that is similar to the first then alter the property we want to change.

let user = { name: "John", role: "user" };
let admin = { name: "John", role: "user" }; // A new object is created at a different memory address

console.log(user);  // { name: "John", role: "user" }
console.log(admin); // { name: "John", role: "user" }

admin.role = "admin";

console.log(admin); // { name: "John", role: "user" }
console.log(user);  // { name: "John", role: "admin" } -> The original object remains unchanged

Although this works, you can tell this method is quite verbose and prone to errors. What if the initial object had over 20 properties? Instead we can use the spread operator (...) to copy the contents of the first object to another location in memory thereby breaking the link.

let user = { name: "John", role: "user" };
let admin = { ...user }; // A copies the contents to a different memory address

console.log(user);  // { name: "John", role: "user" }
console.log(admin); // { name: "John", role: "user" }

admin.role = "admin";

console.log(admin); // { name: "John", role: "user" }
console.log(user);  // { name: "John", role: "admin" } -> The original object remains unchanged

The image below illustrates what happens in the computer when we run the code above;

When we use the spread operator (...), it copies the entire properties of the first object to a different address in memory. You will notice the two variables both points to different locations in memory, now a change to either one will not affect the other.

I would like to point out some extra information about how the spread operator (...) works:

It works the same way for arrays as it does for objects.
It does shallow copying, meaning only the first level of the object is copied to a different address, for deeper nested levels, just the reference is copied.

Comparisons in different data types

JavaScript considers two objects as distinct when they don’t point to the same memory address even if the properties or contents of the objects are exactly the same

You can confirm this by running;

let user = { name: "John", role: "user" };
let admin = { ...user };
console.log(user === admin); // false ( Same properties, different location in memory )

This produces false because JavaScript compares object types by reference and not the contents of the object. So unless both objects point to the same location in memory, doing comparisons like this will always output false

This is in contrast with primitive types where comparisons is done by value;

Conclusion

In conclusion, a solid understanding of how JavaScript handles variable assignment for different data types is crucial for writing robust and bug-free code. Remember that for primitive types, assignments and comparisons are always done by value, creating a new, independent copy of the data. This means a change to one variable will never affect the original.

However, for object types, the story is different. Assignment and comparison are handled by reference. When you assign one object variable to another, they both point to the same memory location. Any property you alter on one will affect the other, as you are both modifying the same underlying object. To break this shared reference and create a new, distinct object, you can use the spread operator (...). It creates a shallow copy, which is a great starting point for making safe modifications without unintended side effects.

While the spread operator is powerful, it has its limitations, particularly with nested objects. In subsequent posts, we’ll delve deeper into more comprehensive methods for copying objects and explore how these same rules of pass-by-value and pass-by-reference apply when passing variables to functions. Knowing the difference between a copy and a shared reference is a fundamental skill that will help you avoid countless headaches in your coding journey.

Thank you for reading!

Understanding Mutability in JavaScript

Rowland — Mon, 22 Sep 2025 04:09:12 +0000

Introduction

Ever wondered what goes on inside the computer when you create and mutate variables? What exactly is the difference between let and const? Why you’re able to alter an object or array even after declaring it with const?

In this post, I’ll break down all these concepts, focusing on mutability of the different data types with simple diagrams to illustrate how variables work in JavaScript.

What is mutability?

Mutability refers to whether a data type’s value can be changed after it’s been created. This is a fundamental concept that separates the two main categories of data types in the JavaScript: primitive types and object types.

To better understand this concept, lets take a moment to understand what variables really are and how they work in JavaScript

What are variables?

In modern JavaScript, values are created and stored as a variable using the let & const keywords. both of which acts as pointers to a location in the computer’s memory where a value is stored. The only difference is how flexible they can be. let is flexible as it can be moved to point to another location in memory, different from the one it was initialized with but const can only point to the address it was initialized with.

Now let’s get back to understanding the mutability of primitive and object data types in JavaScript.

Mutability of primitive data types

Primitive types are immutable meaning their values cannot be altered after creation. When you perform an operation on a primitive, you are not changing the original value, you are simply creating a new one.

Some of the common primitive data types are:

String
Number
Boolean
Null
Undefined

Let’s take a look at a few examples to understand;

let x = 5;
x = 10;
console.log(x); // 10

From the above code snippet, you might think “didn’t we just mutate the value of x from 5 to 10?” Well, we didn’t.

The image below can better illustrate what actually happened inside the computer

What we did was move the pointer from the location in the computer memory that stored the value 5 to another location that stored the value 10. You will notice that the value 5 is still being stored at its original location but now nothing is pointing to it so it will get flushed out by JavaScript’s garbage collector to create space for another value to occupy that spot later on.

What happens when we try this with const variable?

const x = 5;
x = 10; // Uncaught TypeError: Assignment to constant variable.

console.log(x); // This will not run

When we try to move the pointer to another location, we get an error because variables initialized with const cannot be moved to another location in memory and because primitives are immutable, there is no way for us to change the value 5 to another value.

Here’s another example with strings

let msg = "hello";
msg.toUpperCase(); // This method returns a new string "HELLO"
console.log(msg); // The original string remains "hello"

From the above, you might expect the msg variable to become upper cased but it won’t because of the immutability of strings. However, the method toUpperCase() returns a new string value with all the letters in uppercase which we can re-assign back to the msg variable.

let msg = "hello";
msg = msg.toUpperCase(); // The return value is re-assigned to msg
console.log(msg); // "HELLO"

Below is a diagram to help illustrate;

You will notice the original “hello” string was not modified but a new string with all the letters in uppercase was created and the msg pointer was moved to the new location storing the upper-cased value.

Mutability of object types

Object types are mutable, meaning their properties can be changed without reassigning the variable. This includes:

Objects
Arrays
Functions

When you have a variable that holds an object, it’s not holding the object itself, but a reference to its location in computer memory. Imagine it like a label on a storage box. The variable is the label, and the object is the contents inside the box.

Because objects are mutable, you can change their contents directly, without changing or moving the label.

Consider this example below;

let bio = { name: "John", age: 30 };
console.log(bio.age); // 30

bio.age = 50; // We're directly changing a property on bio
console.log(bio.age); // This will log 50!

From the above, we can see that modifying the object’s properties directly changes the data at that memory location. We didn’t have to re-assign the bio variable to point to another location, we simply altered the value that it was pointing to.

The diagram below help illustrate that point;

The bio variable points to the same address in both figures, but the contents inside changed. It doesn’t matter if we used let or const to initialize the variable. Since we’re not moving the pointer, altering the contents of the object would still work the same.

Where we’ll run into issues is when we initialize the variable with const and then try to re-assign it to another value (point to another location)

const bio = { name: "John", age: 30 };
bio = { name: "John", age: 50 }; // Throws an error
console.log(bio.age); // This will not run

Here, we tried to re-assign bio to another object but run into an error, because bio was initialized with const. We would still run into the same error if we tried to re-assign it to a primitive type. This would work fine if we initialized the variable with let and then re-assign it to another value regardless of the data type we are re-assigning to.

Let’s consider another example with an array which is a type of object;

const colors = ['red', 'yellow', 'blue'];

/*  We can add or remove items directly from the 'colors' array
 using methods that mutate it, like .push() or .pop() */

colors.push('green');
console.log(colors); // Output: ['red', 'yellow', 'blue', 'green']

Similar to the bio variable, we did not move the colors pointer but mutated the contents of the address it was pointing to using the .push() method. This is the essence of mutability: the ability to change the contents of a data structure without creating a new one.

Conclusion

Understanding mutability is a milestone in any JavaScript developer’s journey. By now, you should have a clear understanding that primitives are immutable; operations on them create new values while objects are mutable, allowing you to change their contents directly.

Variables are pointers and declaring a variable with let means you can point it to another location in memory after creation but those declared with const are immovable and always points to the same location in memory.

In subsequent posts I will explore other concepts such as assigning by value and assigning by reference and embracing an immutable-first approach, especially with objects and arrays, to prevent unexpected side effects and simplify your code.

Thank you for reading.

How to Link git to GitHub via SSH on Windows

Rowland — Wed, 08 Jan 2025 17:40:16 +0000

As a developer, learning about github can feel great at first, I mean who doesn't need a secure cloud storehouse for their codes? The importance and use of git and GitHub cannot be overemphasized but there come a point in time where you just get tired and bored of always;

Heading to github.com,
Locating your repo
Adding new files to the repo
Clicking and dragging the files from your PC into GitHub
And finally writing a commit message.

All these just to push your code to GitHub, what if you needed to make just a minor change? You'd have to go through that mini hell again? Actually, you don't have to because all these steps can be shortened to;

git add .
git commit -m "minor fix"
git push

Yeah that's right, just these 3 commands above does all that work for you and fast.

But before you acquire such power, there's a price you'd have to pay. and that is, you'd have to setup a connection between git and GitHub first which luckily isn't that hard at all. I am going to share those steps in this post.

Step 1: Download and install git

Alright, the first step is to have git installed in your PC, if you already have it, great! If not just click here and download a version suitable for you PC

After download, start the install wizard and follow the prompts to install.

Upon installation of git, 3 other applications would also be automatically installed in your PC: Git cmd, Git GUI and Git Bash. These are just the different ways of interacting with git.

Configuring git

Open Git Bash, which should look similar to the image below

Run these commands:

git config --global user.name "Your Name"

#This name will be associated with your commits

git config --global user.email "Your email Address"

#This email will be associated with your commits

You can verify that these has been set by running

git config --list

Step 2: Generate SSH Key

Installing and configuring git was so easy right, now to an easy but not so easy step, generating an SSH key;

What is an SSH key and why do we need it?

To answer that let's first understand what SSH even mean.
SSH stands for Secure Shell, and it's a network protocol (like HTTPS but different) that allows secure communication between devices over an insecure connection.

Meanwhile an SSH key is a pair of cryptographic keys (a public key and a private key) used to authenticate a secure connection between your computer and a remote server (in this case, GitHub). Put simply, it's a file containing encrypted texts used for authetication.
We need it to authenticate to GitHub without our username or password.

To generate the key, open Git Bash and run these commands:

ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

#Replace "your-email@example.com" with the email address associated with your GitHub account.

Let's breakdown some of the command arguments above:

ssh-keygen - This generates a new SSH key pair (a public key and a private key)

-t rsa - This sets the type of SSH encryption to rsa (Rivest-Shamir-Adleman) which is the most widely used. Other types includes;
ECDSA (Elliptic Curve Digital Signature Algorithm)
ED25519 (Edwards-curve Digital Signature Algorithm 25519)

-b 4096 - This sets the number of bits of the generated key to 4096. The other possible value for rsa encryption is 2048 which is less secure.

-C your-email@example.com - This adds a comment to the key (usually your email address)

When prompted after running the above command, press Enter to accept the default file location for the file containing the generated SSH key.

Next, you can optionally set a passphrase for extra security or simply leave the field blank and press Enter twice.

Lastly, copy the public key to your clipboard with the following command.

clip < ~/.ssh/id_rsa.pub

cat ~/.ssh/id_rsa.pub

This will display the public key on your Git Bash terminal, then you can manually highlight and copy the public SSH key

Step 3: Add SSH Key to Github and link to Github repository locally

Now for the third and final step, do these:

Log in to your GitHub account.
Go to Settings > SSH and GPG keys.
Click New SSH key.
In the Title field, add a descriptive name (e.g., "git ssh")
Paste your public key into the Key field. (The one you copied earlier)
Click Add SSH key.

Confirm successfull connection

To confirm the connection between git and GitHub, open Git Bash and run the command:

ssh -T git@github.com

if connection was successful you'll a message similar to:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Else simply reply yes multiple times when prompted. Afterwards, run the first command again to reconfirm.

Linking to a GitHub repo from VS code terminal

Congratulations on Linking your git to your GitHub via SSH. Goodnews is you only need to go through all those linking steps once. Now comes the easiest part.

Goto GitHub and create a new repo or open an existing repo
Click on SSH

For a new repo without any files that looks like the above pic:
Click on SSH and copy the url

For an already existing repo with files, open the repo, click Code > click on the ssh tab and copy the url
Open your project folder in VS and click on Terminal > New Terminal
run the following command:

git clone git@github.com:rowleks/test-repo.git

Next navigate to the recently cloned repo (folder) on your PC project folder and open the newly cloned repo in VS code

Open the VS code terminal and run the following commands

git add .

git commit -m "Initial commit"

git branch -M main

git push origin main

And that's it.

Subsequently all you need to do to push to GitHub from that repository are the commands:

git add .
git commit -m "commit message"
git push

Thank you for reading! I hope this helped.

DEV Community: Rowland

Data Serialization: A Concise Guide to JSON, YAML, TOML, and More

JSON

YAML

TOML

Other Formats Worth Knowing

XML

CSV (Comma-Separated Values)

Protocol Buffers (Protobuf)

MessagePack

Many Tools Accept Multiple Formats

Converting Between Formats

How to Choose the Right Format

Conclusion

[Boost]

How to Land a Tech Job in the USA in 90 Days: Your 2026 Action Plan

Oluchi John for FastApply ・ Feb 16

Understanding Website Cookies And Why We “Accept” Them

Introduction

What are web cookies?

How cookies are stored on your device?

The Legal Framework Behind Cookie Consent

The Consequences of Non-Compliance

How Tracking Cookies Actually Work

Tracking and Advertising Cookies

Analytics Cookies

Third-Party Cookies

What Website Owners Need to Know

Implementation Options

The Reality of Compliance

Other Important Cookie Considerations

Cookie Lifespan

The Changing Landscape of Third-Party Cookies

Taking Control of Your Cookies

Cookie Walls and Consent

The Future of Tracking

Conclusion

How to Upgrade to The New Ubuntu 25.10 “Questing Quokka”

What’s New in Ubuntu 25.10?

Planning Upgrades to 25.10 and Beyond

Upgrading via the Terminal

Fresh Install Considerations

Conclusion

Understanding Web and Internet Fundamentals

Introduction

The Foundation: Servers and Clients

How Computers Find Each Other

IP Addresses

Domain Names and DNS

URLs: The Complete Address

Ports: Multiple Services, One Address

Protocols: The Language of the Internet

TCP: The Reliable Data Transfer Protocol

UDP: The Fast Data Transfer Protocol

HTTP: Web Traffic

HTTPS: Secure Web Traffic

IP: Routing Protocol

The Request-Response Cycle

APIs and Modern Web Architecture

REST API

Network Management and Security

Firewalls

Load Balancers

Proxy Servers

Performance and Optimization

Bandwidth

Latency

Packets

Conclusion

Understanding Shallow Copy vs Deep Copy in JavaScript

Introduction

Methods of Copying in JavaScript?

Shallow Copy Techniques

Shallow Copying Objects

Shallow Copying Arrays

Deep Copy Techniques

Using structuredClone()

Using Lodash _.cloneDeep()

When to Use Each Approach

Common Pitfalls to Avoid

Using `structuredClone()`

Using Lodash `_.cloneDeep()`

(3) Limitations of `structuredClone()`

(4) Using `JSON.parse(JSON.stringify())` for Deep Copying

The `.then()` Method

The `.catch()` Method

(2) Not Returning Promises in `.then()` Chains: