DEV Community: Enmanuel de la Nuez

Configuring Git

Enmanuel de la Nuez — Wed, 23 Sep 2020 19:04:36 +0000

Git is one of the most common tools for developers, but we often learn just enough to get the work done. Below are some optional configurations for git you might not have encountered.

Tell git your name and email

Git uses this information to say who committed what. After all, software is often a team effort. By default, git will look for this information by asking your system and choose a default, but if you want full control, here is how you set this information.

$ git config --global user.name "My Name"
$ git config --global user.email "myemail@hello.dev"

Note the --global flags, meaning these settings will be applied system-wide, as opposed to the user level.

Type less with aliases

Some git commands can feel long and tedious at times, why not make some aliases? Aliases are nicknames for shell commands. For example, we can tell git that when we run git st, we mean git status. Here are some reasonable ones from the git docs.

$ git config --global alias.st status
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit

Aliases behave the same way as the full command, meaning you can provide them flags and arguments as usual.

Git auto-correct

Are you always misspelling your git commands? Irritating, I know. Git can take help by guessing what you probably meant and doing it. Git auto-correct setting lets you choose how much time it waits before executing on its assumption.

$ git config --global help.autoCorrect 30

The argument we provided above is an integer representing tenths of seconds. 30 means git waits for 3 seconds. If git got it wrong, cancel the command with CTRL + C before the time is up and try again.

I hope you learned something new! Be careful with git auto-correct, and thanks for reading!

Photo by Pradipna Lodh from Pexels

Event-Driven Architecture

Enmanuel de la Nuez — Mon, 20 Jul 2020 20:38:08 +0000

We tend to design systems based on requests and responses that allow our components to communicate and behave appropriately to streams of information. What do we do when components in our systems are more complex, dynamic, or loosely coupled? Event-driven architecture (EDA) is an architectural style based on an entirely different principle than requests to communicate changes in state, events.

Events are the fundamental entity in EDA that communicate something that has happened. For example, an event can be announced by a button when a user presses it, a mechanism we're familiar taking advantage of in web development with event listeners. Events are pieces of data that describe something that has happened and contain no logic. We call components that emit events event producers or event publishers.

Event producers are components of our system that generate events and announce them to our event-driven framework. Event producers are solely responsible for this and unaware of how we handle the events and where. An event producer's only coupling factor with the components that will react is the event message definition. The event message definition refers to the data and shape of that data that an event includes.

In a request/response-based interaction, two communicating components have a large contract surface area, a measurement of coupling, or how much information components need to know about each other to communicate. For example, we often design components with the expectation of a side effect caused by the processing of a sent request. Additionally, components also must wait for a response. In this model service components and clients are coupled by the contract of what methods are available and logically as requests complete a given function.

Service components in EDA do not behave like a service, and we instead refer to them as consumer components or event consumers. Event consumers, only constrained by the event message definition, react to events. Events are routed to these consumers by an event-driven framework that might be making use of a service we could use a message broker on a worker queue model. Consumers are not constrained to respond to events either, for producers do not expect it. Whenever we can perform a task without any need for the results of the operation, we can consider leveraging an event-driven architecture.

EDA is hard to grasp since we are so used to thinking about software in terms of requests and responses. However, endeavoring to understand it should prove beneficial. Leveraging EDA makes it simpler for us to decouple components, which makes it easy for them to evolve and grow independent of each other. Similarly, EDA allows us to scale horizontally very well since we keep adding more consumers to react to an increasing amount of events.

Cover photo by Artem Beliaikin from Pexels.

Scaling with Object Caches

Enmanuel de la Nuez — Mon, 13 Jul 2020 20:02:42 +0000

Object caches go a long way in helping us secure the benefits caching delivers to the scalability and user experience of our web applications. Object caches are built on key-value stores, a simple type of database that matches a unique key to a value. Typically, these systems are simple to integrate into an already existing application and come with features useful to caching. Caching objects save us time and resources because we can retrieve them from our store rather than perform the computing to build them again. Object caches come in different types following the same principle. Let's explore common types of object caches.

Client-Side Caches

Client-side caching is enabled by technologies that allow our applications to store objects in the user's device, preferably for as long as possible. For the web, most modern browsers support the Web Storage API, a programming interface for storing key-value pairs locally. Client-side caching is especially beneficial in increasingly common Single Page Applications or SPAs, which tend to make many AJAX request. Each request means time spent as the data travels to and from our servers, plus the time to compute or retrieve the requested information. By leveraging local storage and storing frequently requested data, we can decrease the load on our servers as well as provide a snappier user experience.

To get started with the Web Storage API, open up your browser console and follow along with these snippets. All the following methods belong to the localStorage object, which itself belongs to the window object.

To store a new key-value pair, use setItem:

localStorage.setItem('REPLACE WITH KEY', 'REPLACE WITH VALUE');
// returns undefined

Using the method above will either set a new value to your key or replace the old value if the key is already in use. To retrieve the value, use getItem.

localStorage.getItem('REPLACE WITH KEY');
// returns 'REPLACE WITH VALUE'

Deleting specific values is also straightforward with the use of removeItem.

localStorage.removeItem('REPLACE WITH KEY');
// returns undefined

Now if we try to retrieve that same value...

localStorage.getItem('REPLACE WITH KEY');
// returns null

Clearing all the key-value pairs we've created is also possible with localStorage.clear().

Caches Co-located with Code

Caching close to our code refers to storing our key-value pairs either in places that are easy for our application logic to access. For example, our application's memory, which we can use when declaring an appropriate data structure cache data. Alternatively, we can deploy an independent cache server on the same machine for each of our web servers. Both methods have the benefit of being close to the code, so accessing them is relatively quick. Additionally, the code to access an independent service on the same machine won't be hard to adapt should you wish to connect to a remote service later on. The most popular key-value stores I've come across are Redis and Memcached. When looking to scale would architect our application so that we can have many web servers, meaning this type of cache scaled alongside them.

When we deploy a cache server locally, however, we also face limitations. For example, each web server is only aware of a singular cache and will replicate data by storing information another web server has already cached. Additionally, removing cached data is difficult since we usually communicate with one server at a time but it might be cached on multiple machines.

Distributed Object Caches

A distributed object refers to when our cache servers with software like Redis or Memcached lives on a separate host machine accessed over the internet. Distributed caches systems have the advantage of scaling very well, making it possible for our application to interact with multiple caches on a cluster as if it were one. The cache system will also be responsible for intelligently utilizing the resources available, combating the issues mentioned earlier of replication, and trouble deleting. Distributed object caches can scale vertically or horizontally to meet your application's demands without too much complexity.

Thanks for reading :)
Original cover photo by Pixabay, edited by me.

NoSQL Document Stores

Enmanuel de la Nuez — Thu, 09 Jul 2020 20:31:53 +0000

What is NoSQL?

NoSQL is a general term that encompasses databases that usually don't support the use of SQL (Structured Query Language) because they store data differently. NoSQL databases came about in the 2000s to meet the scalability demands of big companies like Google, Amazon, and Facebook. Traditional databases have been around since the 70s. Being such a general term, NoSQL can refer to many types based on how they store their data. The most popular types are document, key-value, wide-column, and graph stores. Document stores seem to be by far the most popular, widely used as a general-purpose database in many of the tutorials you might find on this platform.

Document Stores

Document stores make use of unique documents, usually a type of JSON object with fields and values. These documents support many of the primitive data types we're used to from our programming languages, making it easy to get up and running with your language of choice. As opposed to normalizing data and building relations, documents allow you to store all the information related to an entity in that document.

Relational Databases vs. Document Stores

Relational

Suppose we want to build an application that has users and those users can track their hobbies. Using a relational database we would define the structure of our two basic entities to the level or normalization (the act of breaking up tables to reduce redundancy and increase data integrity) we like. A basic structure for our users and hobbies look like this:

Users Table

id	first_name	last_name	email	hashed_password
1	Alex	Shelley	s.alex@mail.com	7Fy5vQhehSBAuJaKBJLC
2	Manuela	Avery	mavery@cool.org	GFUtPYL3vyKZAQqJeVmA

Hobbies Table

id	hobby
1	Swimming
2	Music

We can build a relationship between users and hobbies with another table, let's call it user_hobbies:

users_hobbies

id	user_id	hobby_id
1	1	1
2	1	2
3	2	1

We can interpret it to mean user 1 both swims and enjoys music while user 2 only recorded enjoying swimming. A query with a SQL operator like a JOIN allows us to reference the users and hobbies tables with the IDs listed in the user_hobbies table. This table structure allows us to assign any number of hobbies to any of the users in that table. We can also add users or hobbies individually without making new connections between them. Additionally, relational databases also allow us to alter any of the values and columns on a table.

Document-Oriented

To capture the same data in a document-oriented database, we can store our user information and their hobbies in the same document.

{
  "_id": 1,
  "name": {
    "first": "Alex",
    "last": "Shelley"
  },
  "email": "s.alex@mail.com",
  "hashed_password": "7Fy5vQhehSBAuJaKBJLC",
  "hobbies": [{ "hobby": "Swimming" }, { "hobby": "Music" }]
}

{
  "_id": 2,
  "name": {
    "first": "Manuela",
    "last": "Avery"
  },
  "email": "mavery@cool.org",
  "hashed_password": "GFUtPYL3vyKZAQqJeVmA",
  "hobbies": [{ "hobby": "Swimming" }]
}

This way of storing data allows us to be more flexible with our data. For example, We can change the structure of user 2 without changing the structure of user 1.

Scalability

Scaling a relational database is usually done by a combination of 3 principles: functional partitioning, data partitioning, and replicating data. Briefly, functional partitioning refers to delegating different data to different databases based on their purpose or function, with an emphasis placed on grouping together data that has similar write or read throughput needs. One example would mean storing data for users in one database while storing videos in another. This allows each service to be scaled independently. Within each service, data partitioning can be applied to divide a body of data among different machines so that no one server has all the information and operations can be shared. Lastly, replication refers to having more servers all replicating the other servers they’re connected to. Some of these servers will be for distributing read-only operations, while all write ops go through a primary server for the secondary ones to read from and replicate. All of these methods to scale relational databases present significant challenges such as replication lag and cross-partition queries. Luckily when the situation calls for it, we have alternatives.

NoSQL databases like document-oriented ones were invented to solve problems that arise when we want to scale a relational database. These were built with horizontal scalability in mind, the holy grail of scalability. Typically, the more servers we add the more your throughput increases without many of the complications mentioned above. No choice is without trade-offs though, truly horizontal databases can still struggle with particularly workloads. Like always, it is about choosing the right tool for the job. Next time you find yourself wondering which one to use think about the workload you expect for your database and see how different types may help you. It is okay and common to use multiple types of databases for the same product, too, so no need to try and make a particular an all-situations magical tool.

Thanks for reading! I hope to soon write about other types of NoSQL databases and familiarize myself with what's out there.

Cover photo by Pixabay on Pexels.

REST Easy: An Introduction to REST Web Services

Enmanuel de la Nuez — Mon, 06 Jul 2020 19:56:57 +0000

Since it's inception in 2000, REST has become the standard architectural style for web services or APIs. REST, or Representational State Transfer is concerned with resources or entities on a system and interacting with them with a limited set of predetermined stateless operations. Resources model (represent) what can be considered types of objects in your application. For example, if you are building an application to track books a user has read you might consider creating a ‘book’ resource. Conversely, you might consider instead to build a ‘collection’ resource that has within it different books, or you might model both. Regardless of the exact models, a REST services (also called RESTful services/APIs) expose a standard way for other computers in your application to interact with its resources.

The interactions with the resources of your application start with another standard: HTTP and its available methods or verb that describes the type of interaction. In general, a GET request will retrieve or fetch a specific resource, PUT is used to replace the resource, and POST is used to update or create a new resource, with DELETE to remove it. Every resource is identifiable by its URL or Uniform Resource Locator. With these two components, we can concisely describe different interactions with the previous example of our book tracking application. If we need to get a book, we can send a GET request to https://example.com/books/2 which will retrieve the book with an ID of 2. These interactions are stateless because all the information needed to carry them out is included in the request, meaning the server doesn’t have to store information about previous requests with the client for the intended functionality.

Stateless, uniform interactions provide many benefits to the development of an application:

The structure of your service is easy to document and predictable. When it comes to using the service, you need only know the resources and what effects different HTTP verbs have on it. One common way to convey this is with a table. Consider our book app from earlier

HTTP Verb	URL	Behavior
GET	/books	Retrieve all books
GET	/books/:id	Retrieve book by ID
POST	/books	Add new book
POST	/books/:id	Update book data
DELETE	/books/:id	Delete book by ID
PUT	/books/:id	Replace book by ID

JSON, a file format, has also become another standard in web services communication. HTTP requests and JSON files can be consumed and created in nearly every modern language, allowing services intended to work with one another to be written in different languages. This might be a great decision because of the set of libraries different languages have.

The next couple of benefits I want to list aren’t immediately available to you if your application implements REST web services, but you will be very close. A REST web server deals in stateless requests, but can be completely stateless itself as well by delegating persistent storage to other computers. Stateless web services are ideal for scalability because of these advantages:

You can use a load balancer to distribute each request from a client to any number of servers. This is possible because like we mentioned before, every request has all the information your server needs to respond, so a request doesn’t need to be in communication with the same server over a period of time. This means that one request can go to a server while the next can go to a completely different one that is more available to respond quickly and maintain good user experience.
Stateless web services can be treated like a collection or pool of resources. At any moment one server can be taken out of the pool and others can be put in. Essentially, all these servers are clones of each other and capable of providing the same functionality by spreading the work of handling requests evenly. Servers can stop working at any point service won’t be disrupted because another server can quickly take its place.

REST is a versatile and battle-tested style to design a web service. With the right application, it will bring a lot of power and convenience to the development process and will go a long way in making sure they can scale as well to serve a large audience.

Cover photo by Min An from Pexels

Demystifying Nginx for Scalable Front-Ends

Enmanuel de la Nuez — Thu, 02 Jul 2020 13:18:39 +0000

Standing at the forefront of our applications, front ends see the highest concurrency and throughput demands, so designing scalable front-ends are crucial to a performant application that intends to grow. Fortunately, tools exist to help us architect a robust front-end layer. Nginx is one of those tools.

Nginx is a popular piece of software that can play many roles in the architecture and infrastructure of your web application. It enables almost 50% of web servers for the top 1,000 websites around the world (read more here). Should you check out their website you will see claims that it can be a reverse proxy, load balancer, and many other things. To better understand why you might want to use Nginx let’s explore some different roles it can fulfill.

Nginx as a Load Balancer

Load balancers are a key player in scaling horizontally. Read more about horizontal scalability in my last blog post here. A load balancer will distribute requests among your servers. It is the service that will first receive your users' request and with the help of different algorithms, it will decide which server in your pool or farm of servers it will send the request to. Load balancers ensure we're making efficient use of all of our horizontal resources.

Load balancers help your users have a smooth experience through thin and thick. No matter how many servers we have and how beefy they are, they will eventually malfunction or need to be temporarily disabled for maintenance. Similarly, as our application grows we will probably want to add more servers to handle more requests. Load balancers are aware of new servers being available, servers no longer behaving correctly, or servers simply being too busy. With this information, they will send requests to the servers that do work, allowing you to take servers in and out without disrupting service. This ability also makes it possible to roll out new updates without any downtime.

Nginx as a Reverse Proxy

A reverse proxy server also intercepts requests from the clients to your servers. Their value comes from their ability to serve as a load balancer, cache content, and provide you with more security. Caching data is another incredible functionality that goes a long way in creating a smoother experience for your users. Data can be cached (stored for later use) in different layers and types of servers. When data is cached in a reverse proxy server, it will be because the data is frequently requested by different clients. We can store frequently requested data to more quickly send a response while at the same time decreasing the load on the server. Lastly, a reverse proxy is also able to provide an extra layer of security as they can limit requests from a particular client that may be trying to intentionally overload your servers with requests.

Additional Reading:

Thanks for reading! I am open to learning more and answering questions in the comments :)

Cover photo by Negative Space from Pexels

How to Architect Web Applications That Scale

Enmanuel de la Nuez — Mon, 29 Jun 2020 11:47:44 +0000

What is Scalability?

Scalability is the ability of your web application (or any system!) to grow and shrink to fulfill demand cost-effectively. Properly scaling can allow you to build applications that can handle more data, users, and interactions with your servers without the degradation of your app’s user experience. Don’t think about how fast your server handles any particular task or request, but rather ask yourself: does my application work for 10,000 users as well as it does for 10?

So, how would I go about making my application scalable?

First Approach: Scaling Vertically

The first approach you might consider is making your application more scalable is to give it more hardware resources. Instead of deploying your application for free on Heroku, you instead pay for a server equipped with a powerful processor and a decent amount of memory. When your app’s audience grows you simply upgrade the server by changing the CPU for one with faster clock speeds and adding more RAM. This is known as scaling vertically.

Scaling vertically is about upgrading your hardware and not changing how your application works. This works great. Your application is not that big and you’re making enough money to afford the hardware upgrades.

This approach is not without its limitations, however (I mean why else would I list more than one approach, right?). The bottleneck for scalability here is cost and application design. Firstly, getting set up with consumer-grade CPU with 18 cores from Intel for $999, but you need a quote for an enterprise-grade CPU with 28 cores (as early 2020). More cores won’t always solve the problem either, software often has to be designed to take advantage of them and software your application relies on might not be yours or even open-sourced. Eventually, you will reach a limit to the upgrades you can make.

Planning Ahead: Horizontal Scalability

Another approach you might consider is adding more servers instead of having one a couple of really powerful servers. Can you avoid hitting a ceiling with this strategy? The answer is yes! As you add servers to the system they don’t need to be all that powerful since the benefit comes from your application’s ability to leverage many of them meaning cost grows more reasonably.

Horizontal scalability is hard and will probably require your application to change. Think of the individual roles of different services in your application, like the web server, caches, and databases. True horizontal scalability means being able to add more servers to fulfill each role. Pulling this off without major rewrites means thinking a lot about your application as a system of services.

There are different ways to architect your system but generally, they all encourage you to separate your system into smaller, independent units. A system made of more independent units lets you work to develop and scale them independently as well.

Thanks for reading! If you’re feeling generous with your knowledge and experience be sure to leave a comment. Feeling curious? Questions are welcomed too!

If you’re looking to learn more about system design I would highly recommend Web Scalability for Startup Engineers by Artur Ejsmont. This is also my main source of knowledge for this post.

Cover Photo by panumas nikhomkhai from Pexels

Redux for React Devs

Enmanuel de la Nuez — Mon, 15 Jun 2020 11:00:03 +0000

What is Redux

Redux is a library built to help us manage state in all kinds of JavaScript applications. In this blog post we will explore it from the perspective of someone already familiar with using React. Redux encourages us to store state in a single source, or ‘store’ that we change with predetermined actions we set up with reducers. Sounds familiar? It should! React’s context, state, and reducer hooks give us similar functionality. Continue reading to learn more about why you might want to consider Redux nonetheless.

Origins and Principles

Redux is based on other technologies like Flux and Immutable.js that are based on the principles of immutable data structures, a single source of truth, and the use of pure functions for state updates.

Immutable data structures already exist in JS, all of our primitive data types are immutable (numbers, strings, etc.). This means we cannot intrinsically change this value, only replace it with a new one. Complex application data however is often best stored in more flexible structures like an object or array, which are both mutable (can be changed in place).
Having a single source of truth means centralizing where you communicate updates to your data as well as where you get it from. Even trivial applications with different stateful parts can get difficult, imagine the additional struggles when you throw in asynchronicity and the reality that things don’t always work into the mix.

Pure functions always return the same output for a given input. These functions don’t rely on information other than the input and transform information with other pure methods. Pure functions don’t produce side effects either, meaning they don’t change state outside their own contained scope.
All of these principles contribute to a state that is easier to debug, predictable, and more elegant. How we behave and interact with information stored in this way produces behaviors that can be more easily be reasoned about.

Connecting with React

Redux can help us manage state for React applications with the React Redux (RR) library. RR is made officially maintained by the Redux team, who created Redux for use with React. RR also implements optimizations that make it so that only the components that need to rerender do so when it actually needs to. RR is abstracting for us the optimal ways of connecting our components to our store. Here is the link to the docs. Instead of rewriting these, I would like to share with you some questions I had and what I learned based on the answers I gathered from quick chats with more senior engineers around me! Thank you, Helen and Erwins!

Should I use useState if I’m using Redux?

Yes! useState is a great way to track information that you need to make a component interactive but not necessarily persistent across rerenders or after refreshing the page. For example, using this hook to control a form is the best option, there really is no point to including it in your store since it’s only useful where the form is.

What about useContext and useReducer?

These remain great tools and frankly the ones I will be making use of in my personal projects. This is because they are often not super large and a Redux store would be a little overkill. In general, when deciding which of these different features to make use of I learned to try to keep state as close to where it's needed as possible. For me this means I would approach a growing need for more easily shareable/global state incrementally, first just using state and props. Perhaps the next step is designing my components with more intention and having state be ‘up’ so that I can pass more information down.

The React Redux docs cover a pattern of presentational and container components but show examples with using classes, is this still best practice with functional components?

The answer here is yes, maybe, depends! Quick review. Presentational components are primarily concerned with the markdown, how things look. They only receive data through props and are unaware of your larger app’s state. Container components tend to be stateful, are aware of things like Redux, and pass information to presentational components. This can still be a great pattern that helps stay organized, however, hooks make it incredibly easy to connect your store to a component. Be flexible.

Hey! Thanks a lot for reading! If you would like to help me better understand any of the things you read above feel free to message or email me! I love to be constantly improving and I would really appreciate it.

So... Linux?

Enmanuel de la Nuez — Mon, 13 Apr 2020 05:53:03 +0000

Introduction

Did you know Linux is the most popular operating system in the world? It is! For servers and supercomputers. The millions of server computers hosting the websites we visit are more than likely running a version of Linux. In this post, we'll learn what Linux is and where it comes from, vocabulary, and commands you need to start navigating this exciting platform.

What is Linux?

Linux is an operating system, just like Windows or Apple's mac OS. Operating systems are collection of software that manage the different devices and applications in your computer. These bits of software take care of processes like shutting down your computer, booting it up, and giving your programs an interface to interact with devices like your keyboard and mouse.

Learning to use a Linux system is a great opportunity to get familiar with the command line, the most explicit way to communicate with your machine. Additionally, as you experiment with different projects, you will start to learn about repositories, package management, file permissions, user management, and much more. Package management and repositories are concepts you might already be familiar with if you have any experience using npm and GitHub.

Why is Linux so Popular?

Linux distinguishes itself in the world of enterprise computing, big data, and science (think supercomputers!). Why?

Linux is free. Free in multiple ways, you don't need to pay to use Linux and you're free to view, edit, and distribute the source code. When you buy a computer with Windows or macOS, the cost of creating and maintaining these operating systems is included in the price.
Linux is flexible. Linux is used in a lot of different types of computers. Think smart toasters and refrigerators, other IoT devices, internet routers, Android smartphones, the list goes on and on. You can probably install Linux on your laptop or desktop today and be up and running with little set up! More on this at the end. This flexibility is possible because a Linux operating system is designed to be the sum of many different tools that do one job and do it well. You could piece together a version of Linux that works for your device and is optimized for your needs.

The Unix Philosophy

Linux is a 'Unix-like' operating system, meaning much of it is derived from the Unix operating system and generally follows Unix's design principles. An ideal Unix program is simple, modular, and extensible. Unix programs do a few tasks really well and are designed to work well with other programs without depending on too many others. The system is made strong by the collaboration of the programs that compose it, not because the programs themselves are super powerful.

My favorite thing about Linux is that everything is a file somewhere in the system. Those commands and programs you run in the terminal? Files. The icons in your desktop that let you quickly open your favorite apps? Files. What about the repositories your system checks for application updates? Written in a file! All of which you can mess around with. The transparency! The power! Its beautiful. Imagine one day set up your own Linux installation with everything you want, and nothing that you don't, while having full autonomy over your system... Pretty cool, right?

These principles really speak to Linux's flexibility. No wonder it's used in for so many applications!

Everything is a File, Here is Where They Live

I want to show you a typical system tree, or file system hierarchy in a Linux installation. Read more about tree-like data structures in my other post! If you're following along in your own Linux system, note that you may have additional or fewer directories. If you want to learn more these directories (folders) in detail, run man hier in your Linux terminal and read away! Personally, I keep my search engine of choice nearby to look up the many words I don't know the meaning of.

/ this is the root directory (folder), the root of the tree (yes, the data structure 😄)

/bin contains binaries, executable programs the system needs to boot

/boot contains the kernel and files needed while the machine boots

/dev contains device nodes, instructions/interfaces to use with physical devices connected to machine

/etc contains system-wide configuration files (pronounced etsy). Big software packages like gtk, python, and X11 store configuration files here as well.

/home contains directories for system users (each user's Downloads, Pictures, etc.)

/lib contains libraries shared by core programs necessary to boot the machine

/lost+found contains data misplaced during a system crash or as a result of drive errors

/media contains mount points for media devices like USBs, CDs, and DVDs.

/mnt is a mount point for a temporary file system (like the one you might use to build your installation)

/opt contains additional packages for programs. In my machine, Google Chrome and the Minecraft Launcher keep files here.

/proc contains files related to the kernel and running processes

/tmp contains temporary files that may be created while executing a program

/usr contains a secondary, read-only system tree for sharing with some programs or to be mounted on other Linux systems. Many of the directories above exist here containing additional files.

/var contains files that vary in size at different times like logs and backups

If you use Linux frequently, at one point or another you'll find that you need to edit or write files in some odd directory. I hope knowing what these names generally refer to can help you out!

Command Line Basics

Earlier I said 'the most explicit way you can communicate with your Linux machine is the command line' and I meant it. Let's learn some basic command line or terminal commands that will allow you to start familiarizing yourself with your system. If you currently develop with a graphical user interface you may find that doing things from the terminal is faster and safer (ish).

There is a program between you and the terminal called the shell. A shell is a program that interprets text commands and sends them to your operating system to execute. The most common shell program is called Bash, which comes included in most Linux installations. For macOS users, Apple recently switched the shell program to zsh. macOS is actually a Unix-like operating system as well. You too can change your shell!

The Structure of a Terminal Command

I won't share too many commands in this post, its long enough already and learning patterns is more important. Generally, terminal commands follow a very similar and predictable structure:

program_name [--optional flags] [optional arguments]

Flags can come after arguments and are often shortened to just one letter and one dash, e.g. -f. Flags are options that change the way a program behaves. -h or --help are common flags that will tell a program you want to see which flags are available to you.

Arguments are often files but can be strings and numbers too.

You can call a program from any directory in your system and you can use a file from any directory in your system as an argument. You can do this because to name a file you can use a relative or absolute path. Relative paths are relative to your current directory, which you can refer to with .. Absolute paths start at the root of the system / and name every directory to get to the desired file.

Navigation

pwd prints the directory you're currently in (print working directory)
cd changes the directory to your specified argument. If you provide no arguments it will by default take you to your user's directory, which you can refer to in paths with ~. . and .. represent your current and parent directories respectively and are also valid arguments.
ls lists the files in the directory you specify as an argument, which by default is .. The -a flag comes in handy for seeing hidden files. You can hide files by starting their name with a ., e.g. .gitignore to reduce clutter.

ls -a ~/Documents

File Manipulation

mv moves a file or directory to your specified directory.

mv fun-letter.text ~/Documents/letters/

You can also use mv to rename files and directories:

mv fun-letter.txt hilarious-letter.txt

Like moving it to itself with a new name!

cp makes a copy of a file in a specified directory. Use the -r flag to copy directories, and you can rename files and directories with cp similarly to how we did it with mv.
mkdir makes new directories where the names are your arguments. You can also make directories inside directories that don't exist yet with the -p flag.

mkdir -p code/web-stuff/html notes

touch makes new files where the names are your arguments.

You will soon find yourself wanting to do more complicated things, so read more on these commands and keep a cheat-sheet 😉.

Linux for Everyday Use

I won't say 2020 is going to be the year for Linux in the desktop, but I will share that there are many Linux distributions ready to go out of the box and with simple installation methods. If you are attracted to the power of the shell, are concerned about privacy using other operating systems, or you just like hacking around, Linux might be for you. As a developer this is also a great platform because its made with other developers in mind. Distributions, versions of Linux like Ubuntu, Linux Mint, and Fedora can get you up and running quickly. These 'distros' are accompanied by huge communities full of people willing to help. Just remember to back up any important files!

Thanks for reading! I appreciate any comments and feedback :)

Cover photo by Pixabay from Pexels

Learning Data Structures: Trees

Enmanuel de la Nuez — Sat, 11 Apr 2020 21:11:10 +0000

In this article we'll explore trees, a classic computer science data structure. Trees have many applications, used to organize information we interact with daily. Implementing the structure in our language of choice also gives us a chance to learn more about recursion.

In order to understand trees, we will learn what they are, how they are used, and how to implement them.

What are Trees?

The tree data structure is much like a tree in real life, they have roots and leafs. One key difference is that the data structure's root is at the top. Trees have other properties that make it a great way to organize the right body of information:

Trees are hierarchical. More general things are near the top and more specific things are near the bottom. This helps organize data in a way that makes it easy to access it because at any layer we can choose which path to follow. Consider this diagram representing a book:

Note that the lower cells of this tree are all classified as a book but depending on how they're connected, they might be part of the first or second chapter. If you needed to quickly access the first sentence of a paragraph in Section 2, Chapter 2 of this book, you intuitively know to follow the path to the right and to ignore anything under Chapter 1.

The children of one node are independent of the children of another node. Think about our book again, and imagine you want to delete all of Chapter 2. It sucks and you have to rewrite it 🙄. You can safely do so without affecting Chapter 1.
Each leaf node is unique. You can count on every sentence of this book having a unique path from the top of our diagram to itself.

Trees in the Life of a Developer

Trees are a truly ubiquitous data structure. Here are some examples of trees that developers interact with all the time:

The DOM: Web devs this one is for you! We write markdown for websites by nesting tags at different levels. In the end, we can visualize it like the book above:
The UNIX file system: A lot of devs use a Mac or Linux operating system. These systems belong to the same family of operating systems. The way directories (folders) and files are organized is an example of a tree as well. Big, general directories like etc/ and bin/ are at the top right under the root / directory. Check it out by opening your terminal and running cd / followed by ls. Different parts of the system are categorized at different layers and there is a unique path to every file from root. Very commonly when using tools in the command line, you have to specify the path to a file for your program to use.

All the Technical Vocabulary

Here are all the words you should get familiar with to talk about trees effectively.

Node The smallest unit of a tree where data can be stored. A node has references to its children and a property to store data, commonly called it's "payload".

Edge Edges connect two nodes and represents the relationship between them. Every node except the root has exactly one incoming edge and any number of outgoing edges. In other words, every node except the root has one parent and any number of children.

Root The root of a tree sits at the top and has no incoming edges. We manipulate trees by first referencing the root.

Path A path is the set of nodes connected by edges, in order from one node to one of it's descendants.

Children The set of nodes that have incoming edges from the same node p are children of p.

Parent A node p is a parent to all the nodes to which p is connected to by outgoing edges.

Sibling Nodes that share the same parent are siblings of one another. They share the origin of their single incoming edge.

Subtree A subtree is a set of nodes and edges consisting of a parent node and all its descendants. Internalizing this definition helps think about trees in a recursive way which is key to a lot of algorithm problems.

Leaf Node A leaf is a node with no children.

Level The level of a node is equals to the amount of edges from root to that node.

Height The height of a tree is equals to the greatest level of any node in the tree.

Defining a Tree

Lets bring all we've explored together to formulate a definition of a tree.
Nodes and Edges A tree is a set of nodes connected by a set of edges and meet these properties:

One node is designated the root node
Every node n, except the root node, is connected by an incoming edge from exactly one other node p, where p is the parent of n.
There is a unique path from the root node to each node
If each node in the tree has a maximum of two children, the tree is a binary tree.

Implementing a Tree

A quick way to implement a tree is to define a Node structure that will allow us to connect it to other instances of itself in the way we knows trees connect. For simplicity, this will be a binary tree.

class Node {
  constructor (value) {
    this.payload = value
    this.leftChild = null
    this.rightChild = null
  }
}

With the code above, we can instantiate some Nodes and connect them to form a tree.

const a = Node('A');
a.leftChild = Node('B');
b.rightChild = Node('C');

The children of a, for which we didn't assign a variable, can still be accessed and can become parents themselves.

a.leftChild.leftChild = Node('D');

We can also define this data structure recursively, meaning a we use a Node to define Node 🤔

class Node {
  constructor (value, leftChild = null, rightChild = null) {
    this.value = value
    this.leftChild = leftChild
    this.rightChild = rightChild
  }
}

I used the Stones to destroy the Stones.

Thanos

And we can use it like so!

const numbersTree = Node(1, 
  Node(2, Node(4)), 
  Node(3, Node(5)));

Try and draw this tree!

Conclusion

Trees are a versatile and prominent data structure. I hope you feel more equipped to talk about trees and that these examples have illustrated some mental models that you will need to know trees closely. The more familiar we get with our data structures, the better we are able to leverage them in real world problems.

Share thoughts, feedback, and your own implementations of nodes or trees in the comments below! Thanks for reading!

Cover photo by Skitterphoto from Pexels