DEV Community: Jenn Herrarte

How to Read Technical Books 📚

Jenn Herrarte — Mon, 08 Jan 2024 05:55:47 +0000

Hello! Happy 2024! THIS is the year where we're picking up the stack of software engineering books that are collecting dust and cracking them open.

Last year, I started reading Designing Data-Intensive Applications by Martin Kleppmann. One page in, and I realized reading it was going to be a doozy. Getting through the material taught me that reading technical books requires a level of effort that goes beyond reading your average book. Here are my top tips for reading technical material.

TIP #1 - Draw it out ✍🏽

For example, if the text lists out the pros and cons of using a specific technology, draw it out in an actual chart. So many of these books don't have pictures (can we please change this)so drawing goes a long way. If there’s an analogy that comes to mind when reading about a concept, draw it out! I enjoy using Figma to create slides containing all my visuals.

TIP #2 - Use ChatGPT 💻

Use ChatGPT to look up any keywords or phrases you don’t understand, especially if the text doesn’t explain what it is. For example, if there’s a paragraph talking about how nodes communicate through routing packets and you’re like what is a route packet???, just look it up.

pro tip: use the voice feature in the chaptgpt mobile app for quick answers on the go.

TIP #3 - Read Blogs 💡

Read engineering blogs that show real-life examples or case studies that help solidify the concepts you are reading about. For example, this blog post from Educative covers the Ticketmaster meltdown from a system design perspective and this might have affected you personally if you’re a swiftie!

Tip #4 - Teach the material 🍎

My last tip is to teach the material! You can do this via blog posts, YouTube, LinkedIn, etc. I started a book club recently that covers one chapter of Designing Data-Intensive Applications a month, which adds a level of positive pressure to study and understand the material. Teaching the material solidifies it in your brain.

I hope this helps! Let me know in the comments what you're all reading.

Docker: An Introduction

Jenn Herrarte — Wed, 18 Oct 2023 01:56:00 +0000

Earlier this month, I had the chance to attend DockerCon in Los Angeles. You can read more about that here...However, attending DockerCon inspired me to share an introduction to Docker!

First, let's try to come up with a mental model for what exactly Docker is. Imagine Docker as a standardized shipping container in the world of transport.

Back in the day...

In the real world of logistics and transportation, goods need to be transported from one place to another efficiently and securely. Traditionally, cargo was loaded and unloaded individually onto various types of vehicles, each with its own specific requirements and limitations. This process was time-consuming, error-prone, and costly.

Now, consider Docker as the equivalent of a standardized shipping container. Just like a shipping container, Docker containers are designed to be a consistent, self-contained unit that holds everything needed for a particular "cargo" or application. Docker containers provide consistency, isolation, portability, efficiency, and scalability.

This is especially helpful as applications become more complex, with some having separate frontends, backends, and numerous dependencies.

Here are a few problems Docker can help solve:

Inconsistent Environments
In the world of software development, an application typically goes through multiple stages, from development to testing and then deployment. The challenge here is that each of these environments can be slightly different in terms of configurations, libraries, and dependencies.

This inconsistency often leads to the notorious "it works on my machine" problem, where an application behaves differently in different environments. Docker ensures consistency by packaging the application and all its dependencies into a single container. This container behaves the same way across different environments, eradicating the issue of inconsistent environments.
Dependency Hell
Application development often requires specific versions of libraries, packages, and software dependencies. Managing these dependencies manually can be a nightmare, especially when multiple projects with conflicting requirements are in progress.

Docker simplifies this by encapsulating an application and all its dependencies in a container. You define the required dependencies in a Dockerfile, and Docker takes care of the rest. No more worrying about dependency conflicts or complex installation procedures.
Isolation and Security
Running multiple applications on a single server can be risky. If one application encounters a security vulnerability or a runtime issue, it can potentially affect other applications running on the same server.

Docker offers containerization, which means each application runs in an isolated environment. A security breach or an application crash within one container won't jeopardize others, enhancing overall system security and stability.
Portability
In a world where applications can be deployed on various platforms, from local development machines to cloud servers and everything in between, ensuring your application works consistently across these platforms can be challenging.

Docker solves this problem by making containers portable. You can develop an application on your local machine, package it as a Docker container, and be confident that it will work the same way when deployed in the cloud or on-premises.
Resource Efficiency
In traditional virtualization, each virtual machine requires its own operating system, which consumes a significant amount of resources.

Docker containers share the host operating system's kernel, making them incredibly lightweight and efficient. This results in reduced overhead, better resource utilization, and the ability to run more containers on the same hardware.

Docker's Architecture

Docker's architecture is designed around a client-server model, which includes:

Docker Client
The Docker client, also known as the Docker CLI, is the primary interface for users to interact with Docker. Users issue commands to the Docker client, which in turn communicates with the Docker daemon to carry out requested operations. These commands can be used to build, run, and manage containers, as well as interact with images and registries.
Docker Daemon
The Docker daemon, or simply Docker, is a background service that manages container lifecycles. It listens for Docker API requests, processes these requests, and interacts with the host operating system to create and run containers.

The daemon is responsible for building and managing containers based on Docker images. It ensures that containers run in isolated environments and communicates with the kernel of the host operating system to control resource allocation.
Docker Images
Images are at the core of Docker's architecture. An image is a read-only template that includes a set of instructions for creating a container. Images are composed of multiple layers, which are stacked to form the final image. The layered approach enables images to be lightweight and efficient. Images can be created manually using Dockerfiles or pulled from registries.
Containers
Containers are the runtime instances of Docker images. When you run a container, it's created from an image, and a writable container layer is added on top. This container layer allows the application to make changes without affecting the underlying image. Containers are isolated, lightweight, and ephemeral, making them perfect for running applications and services.
Docker Registry
A Docker registry is a repository that stores and distributes Docker images. Docker Hub is the most well-known public registry, but organizations can set up private registries to store their images securely. Images can be pushed to and pulled from registries, making it easy to share and collaborate on software projects.

How Docker's Architecture Works

With this architectural foundation in mind, let's dive into how Docker operates:

Building an Image: You create an image by defining its configuration in a Dockerfile. This configuration includes specifying a base image, adding files, setting up environment variables, and executing commands. The Dockerfile is used to build the image.
Layered Filesystem: Images are composed of multiple layers. Each instruction in the Dockerfile creates a new layer, and these layers are cached and can be reused to speed up image creation.
Running a Container: You run a container from an image using the docker run command. The Docker Engine leverages the image's filesystem and adds a writable container layer on top. This container layer allows your application to make changes without affecting the underlying image.

Isolation: Containers provide process and filesystem isolation. Each container runs in its isolated environment, separate from the host and other containers. This isolation enhances security and prevents conflicts between applications.
Resource Control: Docker allows you to control the resources allocated to containers, such as CPU and memory. You can also limit network access, making it possible to run multiple containers on the same host without interference.
Interacting with Containers: The Docker CLI and Docker API provide interfaces to interact with containers. You can start, stop, and manage containers, and even execute commands inside running containers.
Cleanup and Portability: Containers can be stopped and removed when no longer needed. Images can be shared with others, pushed to registries, and pulled to different environments. This makes applications highly portable and easy to manage.

Docker's architecture, with its client-server model, layered filesystem, and containerization principles, plays a pivotal role in its success. Understanding this architecture is crucial for harnessing Docker's power and streamlining your software development workflow.

With Docker, you're equipped to create, package, and deploy applications more efficiently and reliably than ever before. Docker, with its architecture and containerization, offers a seamless and reliable way to streamline the development and deployment of applications.

Catch me at the 2023 Discord App Pitches!

Jenn Herrarte — Mon, 25 Sep 2023 19:24:12 +0000

Hello Dev Community!

I'm thrilled to share that I'll be one of the judges for Discord's 2023 App Pitches, and I'll be in awesome company with some super cool people. Discord has been my go-to for connecting with folks, whether it's about my love for hip-hop 🎧 or diving into web development 💻 discussions. And because I work at a creative agency and have been in quite a few pitch sessions, I can't wait to see what creative ideas people come up with! 💫

Need inspiration or want to upgrade your server? Check out the app directory here!
https://discord.com/application-directory

You can find more info about how to create your pitch, details about the requirements, and judges here: https://discord.com/build/app-pitches-2023

Exploring Two-Way Data Binding in Vue.js: Building Interactive Web Apps

Jenn Herrarte — Sun, 03 Sep 2023 20:22:51 +0000

In today's dynamic web development landscape, creating interactive and responsive web applications is key to providing engaging user experiences. Vue.js, a popular JavaScript framework, simplifies this process by offering a powerful feature known as two-way data binding. In this post, we'll explore what two-way data binding is and how you can use it effectively in Vue.js to create highly interactive web applications.

Real quick...Let's Talk About One-Way vs. Two-Way Data Binding

One-way data binding is a technique where data flows in a single direction, typically from the data source (model) to the user interface (UI). Changes in the model update the UI, ensuring that users see up-to-date information. While one-way data binding simplifies data display, it doesn't facilitate user interactions that update the data model. This is where two-way data binding shines.

Two-way data binding extends the concept by allowing changes in the UI to automatically update the data model as well. It enables real-time synchronization between the UI and the data, creating a more interactive and responsive user experience. Developers choose two-way data binding when they need to build applications where user input directly influences the data, resulting in a seamless and efficient flow of information between users and the application's underlying logic.

Understanding Two-Way Data Binding

Two-way data binding is a mechanism that establishes a seamless connection between the data model and the user interface. As discussed, with traditional one-way data binding, changes in the model (data) update the UI, but not the other way around. Two-way data binding, on the other hand, ensures that changes in the UI also update the data model. This bidirectional synchronization simplifies development and enhances user interactions.

Let's illustrate this concept with a basic example using Vue.js:

<div id="app">
  <input v-model="message" placeholder="Type something">
  <p>You typed: {{ message }}</p>
</div>

In this Vue.js code snippet, the v-model directive binds the input field to the message data property. As the user types, the message property updates in real-time, and any changes to the message property are instantly reflected in the paragraph element.

Benefits of Two-Way Data Binding in Vue.js

Vue.js's implementation of two-way data binding offers several advantages:

Productivity: Vue.js provides a clean and concise syntax for two-way data binding, reducing the complexity of manual data synchronization.
User Experience: Changes made by users are immediately visible in the UI, enhancing the responsiveness and interactivity of your application.
Code Clarity: Vue.js abstracts much of the data binding logic, resulting in cleaner and more readable code.

Implementing Two-Way Data Binding in Vue.js

Getting started with two-way data binding in Vue.js is straightforward. First, include the Vue.js library:

<script src="https://cdn.jsdelivr.net/npm/vue@2.6.14/dist/vue.js"></script>

Next, create an instance of Vue and define your data properties:

<div id="app">
  <input v-model="message" placeholder="Type something">
  <p>You typed: {{ message }}</p>
</div>

<script>
  new Vue({
    el: '#app',
    data: {
      message: ''
    }
  });
</script>

By binding the message property using v-model, Vue.js automatically sets up the two-way data binding for you.

Best Practices and Considerations

While two-way data binding is a powerful tool, it's essential to keep a few best practices in mind:

Performance: In complex applications, excessive use of two-way data binding can impact performance. Be mindful of the number of data-bound elements and the frequency of updates.
Debugging: Debugging can be challenging when unexpected changes occur. Vue.js provides debugging tools to help trace data flow and troubleshoot issues.
Learning Curve: Familiarize yourself with Vue's directives and concepts to maximize the benefits of two-way data binding effectively.

Two-way data binding is a valuable feature that Vue.js brings to the table, enabling developers to create highly interactive and responsive web applications. By effortlessly synchronizing data between the model and the UI, Vue.js streamlines development and improves user experiences.

What is State Management and Why Is It Important?

Jenn Herrarte — Mon, 07 Aug 2023 15:00:00 +0000

What is State Management?

"State" is any data that describes the current behavior of an application. This could include values like "a list of objects fetched from the server", "which item is currently selected", "name of the currently logged-in user", and "is this modal open?".It's like a snapshot of what's happening inside the app at any given moment.

"State Management" is the process of dealing with changes and updates to state over time. This means having ways to:

store an initial value
read the current value
update a value

There's also typically a way to be notified when the current value has changed.

Types of State

When it comes to an app, there are different types of state we can talk about. Here are some of them:

Data: This is about values that handle specific features or how the app works, like a list of todos.
Control/UI state: Here, we're talking about values that deal with how the user interacts with the app, such as which todo item they've picked.
Session state: This is all about values related to the current user, like their username or profile info.
Communication state: These values describe stuff that's going on when the app talks to other servers, like a "loading" indicator.
Location state: This type of state keeps track of where we are in the browser, like the website's domain, the path, query parameters, and the navigation history. It's like knowing where you are on a map.

Another set of categories might be:

Local client state: values that are scoped directly to a single component or its descendants
Global client state: values that are broadly needed in many places throughout an application

What are the benefits of introducing State Management into your application?

Centralized Data Management: State management provides a single, centralized store for all the data and application state, making it easier to access and modify the data from different components.
Predictable and Consistent State Updates: State management libraries, like Redux or MobX, enforce strict rules for updating state, ensuring predictability and consistency in state changes throughout the application.
Improved Debugging: With centralized state, debugging becomes more manageable as you can easily trace the flow of data and monitor state changes in a controlled environment.
Easier Collaboration: State management fosters better collaboration among developers since it establishes clear patterns for data handling and reduces code entanglement.
Efficient Performance: By organizing state updates, state management can optimize re-renders and prevent unnecessary rendering of components, leading to better application performance.
Simplified UI Logic: State management reduces the need for passing props through multiple components, as components can access the necessary state directly from the store.
Support for Time Travel Debugging: Some state management libraries offer time travel debugging, allowing developers to rewind and replay state changes for easier bug identification and resolution.
Scalability: As your application grows in complexity, state management ensures maintainability and scalability by handling state in a structured manner.
Separation of Concerns: State management helps to separate the business logic and presentation concerns, promoting a more organized and manageable codebase.
Consistent State Across Components: State management ensures that all components access the same up-to-date state, avoiding discrepancies and inconsistencies.
Cross-platform Compatibility: State management can work with different frameworks and platforms, making it easier to share code and state management logic across multiple projects.

How do popular libraries and frameworks such as React and Vue handle state management?

Because state management is such a vital part of writing applications, most frameworks and libraries have developed many different tools and patterns for working with state.

State-Management in React

Redux is a popular state management library, often used with React, which is known for its simplicity and flexibility. It is based on the Flux architecture, which makes it easy to reason about and debug your state.

Pros:

Simplicity and flexibility
Well-documented and supported
Large community of users and developers
Extensive ecosystem of third-party libraries

Cons:

Can be complex to learn and use
Not as performant as some other libraries
Can be difficult to debug

If you’re interested in learning more about Redux, I highly recommend watching the video below:

State-Management in Vue

The official state management library for Vue has changed from Vuex to Pinia. Pinia is gaining popularity within the Vue community, and quickly becoming known for its simplicity.

Pros:

Cute pineapple logo
Has a Simpler API than Vuex
Did I mention it has a smiling pineapple logo???
Comes with Devtools
Has built-in Typescript support

Cons:

It doesn't have large community support and solutions compared to Vuex
Pinia doesn't support debugging functions, like time travel and editing

In a nutshell, state management is super important for making scalable apps. It helps keep all the data in check, making sure it's organized and consistent. Plus, it makes it a breeze to handle lots of users and different parts of the app without everything going haywire.

Tech Terms You Need to Know 💭

Jenn Herrarte — Mon, 09 Jan 2023 18:01:23 +0000

Today's post will be dedicated to a few terms and phrases that are software, development, and tech specific. I was inspired by this tweet where Gergely Orosz, author of The Pragmatic Engineer newsletter (if you haven't checked it out, I highly recommend it), asks what terms many software engineers understand, but can confuse people outside of tech.

I related to many of the replies, as I was so confused by terms like production and staging on my first day as a junior developer.

Live footage of me on my first day:

Of all the terms mentioned, here are my favorites:

Rubber Ducking 🦆
Rubber Ducking is a term often used when talking about debugging. The term “rubber duck debugging” comes from a book by Andrew Hunt and David Thomas called “The Pragmatic Programmer.” In the book, the authors describe a programmer who carries a rubber duck around and debugs their code by explaining it, line-by-line, to the duck.

While the practice of talking to a rubber duck may sound silly, it’s actually proven to be a helpful strategy for finding and solving problems with code.
Daily Standup 🤝🏽
Daily Stand Ups are part of the Agile Software development process (and SCRUM). They are usually at the same time every day and can cover topics such as what you accomplished the day before, what you plan on accomplishing that day, and blockers.
Blockers 🛑
Something preventing (blocking) you from moving forward with a task, often code-related.
Do a Git Blame 🙃
A git-blame is used to show what revision and author last modified each line of a file. It's like checking the history of the development of a file. More formal definition from GitHub:

The blame command is a Git feature, designed to help you determine who made changes to a file. Despite its negative-sounding name, git blame is actually pretty innocuous; its primary function is to point out who changed which lines in a file, and why. It can be a useful tool to identify changes in your code.
Lead the Postmortem 💀
A post-mortem is when a team reflects on a project, how it was executed, what went right, what went wrong, how to prevent mistakes, and how to do better next time. I've heard this phrase used outside of tech many times.

In my opinion, postmortems are really a helpful exercise regardless of industry. Oftentimes, someone is chosen to lead this, therefore leading the postmortem. I love this article from Free Code Camp on what postmortems can look like for software.
Technical Debt 💵
Technical debt is the term used to describe the result of making decisions based on speed above all else. These quick, real-time decisions can make or break software updates. But there should be a balance between good decisions and fast ones. Technical debt can result in negative outcomes or be well worth it—depending on what you and your team decide.
Spaghetti Code 🍝
Spaghetti Code is a term used when describing unstructured and difficult-to-read code. Spaghetti Code can lead to problems over time, as it's often tricky to build on top of. If not resolved, it can lead to folks spending time and energy fixing and finding bugs due to the lack of structure in the code.
Kill All ☠️
killall is a tool for terminating running processes on your system based on name. You can run it like this:

killall [process name]
Development (aka Dev) 💡
Commonly referred to as dev, this is where developers build the code. For example, your company may have a 'dev' version of the site where you push up code for review.
Staging (aka Stage) 🧪
This environment is used to test the software using real data to validate it is ready for use. For example, your company may have a 'staging' version of the site where you push up code. In my experience, this step comes after testing code on dev.
Production (aka Prod) ✅
Commonly referred to as prod, this is where the software is made available to users (aka friends, family, the general public, etc.)
Ship to Production
Shipping to production essentially means pushing code live to where it is available to all users. However, this can happen differently depending on your company. I love this article from Gergely Orosz on the different approaches to pushing code live.
Cut a Release 📋
Cutting a release means taking the state of a code base, project, or repo, and locking it down so no further changes are made. This state is then given a release name and/or release version.

An example would be how different versions of operating systems are released for your laptop or phone. Releases are helpful because when consistent versions of the software are given to users, it is easier for them to ask for help based on what version they are using.
Change List ✔️
New features and/or fixed bugs that are new from one version of software to the next.
Grok 🧘
Grok can be used to describe understanding a subject matter (for example, a programming language) so well that you become one with it.

Two definitions from The New Hackers Dictionary by Eric S. Raymond state:

To understand. Connotes intimate and exhaustive knowledge. When you claim to ‘grok’ some knowledge or technique, you are asserting that you have not merely learned it in a detached instrumental way but that it has become part of you, part of your identity. For example, to say that you “know” LISP is simply to assert that you can code in it if necessary — but to say you “grok” LISP is to claim that you have deeply entered the world-view and spirit of the language, with the implication that it has transformed your view of programming. Contrast zen, which is similar supernal understanding experienced as a single brief flash. See also glark.

Used of programs, may connote merely sufficient understanding. “Almost all C compilers grok the void type these days.”

You can read more about its origins here.

Comment down below with any of your favorites!

An Introduction to Rest APIs

Jenn Herrarte — Wed, 28 Dec 2022 19:59:05 +0000

I know in my last post I said the internet doesn't need another explanation of REST APIs, but that's exactly what I'm writing about today because, well, they're important. 🙃

Below we'll be discussing concepts such as REST, APIs, and how they come together to create RESTful APIs.

What is an API?

API stands for Application Programming Interface, which is a set of rules two software programs use to communicate with each other and exchange data.

Let's use an everyday example:

Imagine you went to the hottest 🍕pizza🍕 place in town for dinner. Upon getting there, the waiter takes your order and delivers it to the kitchen. The kitchen makes your pizza and gives it to the waiter, who delivers it back to you. All of this happens without you ever having to step foot in the kitchen or talk to the chef. An API does the same by taking your request, telling the server what you want, and giving a response back to you.

Similar to how waiters act as an in-between for guests and the kitchen, APIs process data transfer between servers and an application.

How APIs actually work:

Step 1 💡

A client application makes an API call (aka a request) to an endpoint to retrieve information.

An endpoint contains a Uniform Resource Identifier (URI) indicating where and how to find the resource on the Internet. The most common type of URI is a Unique Resource Location (URL), serving as a complete web address.
URI's include a request verb, headers, and a body.

Headers store information relevant to both the client and server. Headers provide important authentication data — such as an API key, the name or IP address of the computer where the server is installed, and information about the response format.

A body gives additional information to the server. For instance, it may be a piece of data you want to add or replace.

When making a request, most APIs use HTTP verbs.

What is HTTP?

HTTP (Hypertext Transfer Protocol) is a standard way of transmitting data over the web that defines how messages are formatted and transmitted, and what actions web servers and clients should take in response to various commands. It is a request-response protocol, meaning that a client sends a request to a server and the server returns a response.

What are HTTP Verbs and Why do APIs use them?

HTTP uses a set of standard verbs to specify the intended action to be performed on a resource. These include GET, POST, PUT, and DELETE. The acronym CRUD also describes what kind of requests we can send in relation to HTTP verbs:

HTTP Status Codes

HTTP also defines a set of status codes that are used to indicate the result of a request. For example, a status code of 200 OK indicates that the request was successful, while a code of 404 Not Found indicates that the requested resource could not be found.

Although developers often make use of HTTP verbs to provide a standard way of interacting with resources over the web, it is important to note that APIs and HTTP verbs are not the same things. APIs can use different methods of communication besides HTTP.

Step 2 💡

After receiving the request, the API makes a call to the web server.

Step 3 💡

The server sends a response to the API with the requested information. The response also includes an HTTP status code.

Step 4💡

The API transfers the data to the initial requesting application.

What is REST?

As the use of APIs became more common, protocols and sets of rules were created to provide users with defined rules that specify accepted data types and commands. These include SOAP (Simple Object Access Protocol), XML-RPC, but the one we care about in this post is REST.

REST stands for Representational State Transfer, and is a set of Web API architecture principles. To be a REST API (also known as a RESTful API), the API must adhere to certain architectural constraints.

TLDR - REST is a standard that APIs follow, but there are other ways APIs can work.

⭐ RESTful APIs: How it all comes together⭐

To recap, we know REST isn’t linked to any particular technology or platform. Instead, it introduces constraints that describe how the server processes requests and responds to them.

To be considered RESTful, an API must adhere to the following constraints:

Client-server autonomy

With REST APIs, the client and server work independently and use different tech stacks. The server has no idea what you're seeing as a user, and the client doesn't know anything about the server. Having this separation means the API providers and consumers can be modified without interrupting communication.

Why is this good?

Easy modifiability, better system reliability.

Uniform interface

A uniform interface dictates a standardized way to communicate with a given server, no matter the client app or device that runs it. This includes having a unique identifier (URI) assigned to each resource, self-descriptive messages explaining how to interpret them and what to do next, and the ability to manipulate a resource through its representation in JSON or XML.

Why is this good?

Easier to use and understand.

Layered architecture

The client does not need to know the details of the server implementation, as the communication between the client and server takes place over a uniform interface. When calling a server, a client doesn’t know whether there are any intermediaries along the way. This allows us to place a proxy or load balancer between the client and server, which improves scalability. Adding security as a separate layer also enhances system safety. Although these services are involved in producing the response, the client doesn’t have to worry about what’s behind the interface.

Why is this good?

Better for overall scaling and security.

Caching

With REST APIs, we can allow clients to store frequently accessed data on their side instead of requesting them again and again. As a result, the app makes fewer calls, which reduces the load on the server and its latency. This allows the application becomes more responsive and reliable.

Why is this good?

Low server latency, increase in app speed and responsiveness.

Code on demand (CoD)

The server can send code to the client to be executed, allowing the server to adapt to the needs of the client on the fly.

Why is this good?

Feature customization, extended functionality.

Stateless interactions

The server does not store any state about the client sessions, so each request from a client must contain all the information necessary to understand the request.

Why is this good?

Enhanced performance, and app reliability.

Summary

API stands for Application Programming Interface, which is a set of rules two software programs use to communicate with each other and exchange data.
APIs use HTTP Protocol when making requests.
HTTP (Hypertext Transfer Protocol) is a standard way of transmitting data over the web that defines how messages are formatted and transmitted, and what actions web servers and clients should take in response to various commands.
REST stands for Representational State Transfer, and is a set of Web API architecture principles.
To be considered RESTFUL, APIs must adhere to these constraints:
- Client-server architecture
- Statelessness
- Cacheability
- Layered system
- Code on demand

I'm hoping to write a follow-up post with an API tutorial but until then, here are some APIs with great documentation:

First and (Maybe) Last Post of 2022...

Jenn Herrarte — Sat, 17 Dec 2022 03:45:01 +0000

Definitely more posts to come in 2023, but first, a little about me...

About Me

Hello! My name is Jenn and I'm a software developer at a creative agency in Los Angeles. Before becoming a developer, I worked in the entertainment industry (showbiz, baby 🎥). Although it was a fun career choice for a while (Ok, I did meet Tom Cruise, twice), I knew it wasn't what I wanted to do long term. I always had an interest in tech and software development (especially when I read this) so I took a leap of faith and enrolled in a coding bootcamp, which brings me to where I am today! A dev with a little bit of imposter syndrome.

Why I'm starting this blog

I think many career switchers and bootcamp grads feel overwhelmed by the amount you have to learn, like REALLY FAST.

...What's that thing people say about learning development? It's like drinking out of a firehouse? Yeah, that's it...

There are concepts and technologies that I still don't fully have a grasp on (kubernetes anyone??). Although I don't think the internet needs another explanation on how REST APIs work, I've decided to start this blog anyway as a way to teach myself, and hopefully you, concepts by writing about them. I would appreciate any feedback from anyone who reads my posts, especially if there's an error or gap in my explanations.

That's all for now folks. 👋