Common Table Expressions are queries that return a dataset that can then be used in another query. I think of them as the building blocks of a bigger query that are also helpful for organization and composition. Here is the basic syntax, taken from postgresqltutorial.com:

WITH cte_name (column_list) AS (
    CTE_query_definition 
)
statement;

Let's unpack this a bit. First, to create a CTE, you must always start by using the WITH keyboard. Then, you can give it any kind of name you'd like followed by an optional column list. The column list will name the return columns if you want, but I usually just name everything in the final statement. After tying the name to the query with the AS keyword, you can make any kind of SELECT, INSERT, UPDATE, or DELETE statement inside the parentheses. Lastly, you must create a SELECT statement at the end which pulls from the query definition.

Imagine a database with 2 tables, students and classes. We have recently created a third table, students_classes which will hold the links between the first two tables. We need to fill the new table programmatically so that every student in the students table will be linked to entry level English and Science classes.

WITH student_ids AS (
    SELECT id FROM students s
    WHERE s.id NOT IN (
        SELECT student_id 
        FROM students_classes
       )
   )
  , class_ids AS (
      SELECT id FROM classes c
      WHERE
      c.subject = 'English'
      OR
      c.subject = 'Science'
      AND c.level = 101
   )
   INSERT INTO students_classes
   (student_id, class_id)
   SELECT
   s.id AS student_id
   , c.id AS class_id
   FROM student_ids s,
   class_ids c;

First, I'm grabbing all of the Id numbers from the students table, taking care to only grab the ones that aren't already in the junction. Then, I get all the class Ids that I plan on inserting, in the second block. You can chain CTEs together endlessly by separating them with a comma and naming the next one. Finally, I use an INSERT statement that pulls from both of the temporary datasets, student_ids and class_ids. The CTE structure made it easy to grab just the data I needed from the first two tables and then insert data into students_classes based off of the information I collected previously. I'd encourage anyone interested in using CTEs to read through the postgreSQL tutorial website, (link posted above) and try them out as a means of breaking down a bigger problem into manageable parts.

Naming Variables

Bad variable names are something that will continue to haunt you for the duration of a project so care should be taken to make sure they're both descriptive and concise. When I first started programming, I was often confused by code snippets that used short meaningless variables like 'a' or 'b' so my initial reaction was to write longer, descriptive names to make it easier to understand what was going on. That's well and good, but longer names are a huge pain to have to continually type out and can actually detract from code clarity rather than add to it. The key is to strike a balance between keeping the name short and sweet, but also letting a future reader know exactly what value the variable should hold.

const a = 3600; //not descriptive enough
const numberOfSecondsInAnHour = 3600; //overly descriptive
const hrInSeconds = 3600; // just right

Along those same lines, I like to describe boolean values in a human readable format that makes it easy to ascertain the variable type.

//don't do this
let user = false; 

//these are better
let isUser = false;
let isActive = true;
let hasMoney = false;

Naming a boolean as 'user' is confusing because it implies that the var should hold some actual user info, not a binary description of whether someone is a user or not. By prefixing it with the appropriate verb, a reader can easily infer the type.

Use 'const' over 'let'

Make the effort to avoid using 'let' whenever possible in favor of 'const'. In JavaScript, 'let' is a mutable variable declaration, while 'const' is immutable. If variables are mutable, they can be changed after they have been declared. This is a necessary part of programming, but it is always best to declare things that should not change as a constant. That way, other programmers can trust that you won't try to mutate the value somewhere else in the code. A 'const' will hold the same value it was declared with. For example, functions should always use a 'const' declaration because the code would be a mess if something declared as a function on line 10, suddenly held a number on line 20 and could no longer be invoked as a function. That would be hard to understand and harder to debug. So, always choose to use 'const' as a first resort, and only switch to 'let' when it's a variable that you know will need to be altered.

Writing (Useful) Comments

This is one that people seem to be divided on. On one hand I've heard that good code should be self documenting and that comments are a crutch for people that need to explain their bad code. I think the idea of self documenting code is nice but I often come across code that could benefit from a comment.

I think striving for simplicity is always the primary goal, but clear comments make decent code into great code. The best piece of advice I've gotten is that comments should explain the why,  not the what. It should generally be clear what you're doing, but if you can comment to explain why you're doing something a certain way that would be helpful for someone else reading your code later, then you should do so. And as with many things, less is more.

Avoid Nesting Your Logic

if(num > 10){
  if(num < 50){
    if(isSecretNum === true){
        return "You've guessed correctly!";
       }
  }
}

The example above is tiny but the bigger and deeper the nesting becomes, the harder it will be to read and eventually debug. If you ever see yourself writing something like this, there's probably a better way to do it. (See below).

if(num > 10 && num < 50 && isSecretNum){
  return "You've guessed correctly!";
};

Review Your Pull Requests Before Submitting

This isn't necessarily a way to write better code but it is a way to save yourself some embarrassment and avoid wasting your co-workers' time. When you're ready to push your code to Github, go through everything line by line and see if there is anything you can clean up before showing it to someone else to review. Do you have console logs that should be removed? How about pseudo code comments that you made when doing a first pass? Do your best to ensure that when you ask someone to review your PR, it's free of any mistakes as far as you can tell.

Incorporating these things into my workflow has definitely improved my skill as a developer. As I learn new things, I'll try to keep updating this post.

Today I'll discuss the concept of ownership in Rust as a way to help myself retain the information and hopefully understand it a bit better. Essentially, there are two main ways that memory is handled in programming languages today.

The first way exists in languages like C or C++ that require the person writing the code to manually allocate memory to their variables and then be responsible for freeing the memory from use after it is no longer needed. This allows that memory to be used elsewhere down the line. If you didn't do this, eventually the computer would run out of available memory and crash. On modern operating systems, this isn't too big of a deal because the OS will recognize what is going on and terminate your program and free the memory resulting in no harm to your computer. But, if you were compiling and running your badly written code on the kernel level for example, the OS wouldn't be there to save you and you could risk causing real damage to your system.

The second way is more familiar to me and it revolves around 'Garbage Collection' (GC). First introduced in 1959 with the Lisp programming language, it is widely used today. In languages like JavaScript, Python, or Ruby, memory is automatically freed up and recycled when it is no longer in use. The programmer doesn't have to worry about a lot of the pitfalls present in lower level languages. Kind of like driving an automatic car vs. a stick-shift. While GC is really convenient, it isn't going to be as efficient with handling memory as a knowledgeable programmer who is able to do it by hand. JavaScript is used all over the web today, but it isn't a good choice for writing a video game for example, because it just isn't fast enough among other reasons. Even with modern frameworks like Electron that have allowed us to use JS outside of the browser and create desktop programs, (see the popular chat app Slack), it generally isn't as fast as a natively written desktop program. I run Slack in my web browser because it hogs way too much of my computer's memory as an Electron app.

Rust introduces a third method of handling memory, that the creators have called 'Ownership'. Essentially, there are rules in place regarding safe memory usage that are checked by the compiler during compilation. This prevents your application from being slowed down while it is running which is what happens with garbage collected languages. It's kind of a best of both worlds scenario. Rust protects the programmer from writing inefficient code like in garbage collected languages but it doesn't do it while the program is running so there isn't a loss in speed. Kind of like how many super cars today are able to use automatic transmissions because the technology has caught up to the point that the car can shift more quickly and make smarter decisions than a person driving a manual transmission.

First, let's go through a brief explanation of how memory is stored and allocated. In a computer program, the memory is stored in RAM (Random Access Memory) in two places, the stack or the heap.

The stack is like a deck of cards. Think of things like variables and functions as individual cards in the deck. When a new variable is created, it is added to the top of the deck. When it is done being used it is removed from the top of the deck as well. This operation is called LIFO or Last-In-First-Out. The stack always operates like this and the order is always preserved. This makes it easy for the computer to tell what is going on and doesn't require too much thinking. Therefore, it's fast and efficient to allocate and free memory from the stack. The caveat is that in order for something exist in the stack, the computer has to know about its memory requirements at compile time. The stack can only handle data that have a fixed or static size.

Data that might change in size cannot go on the stack. That's where the heap comes in. As the name might suggest, it is not ordered like a stack. When something is added to the heap, you specify a memory size that the data will need and the computer finds space in the heap to satisfy your requirement. This provides more flexibility than the stack, but it is more costly because the computer needs to make more calculations to decide what to do with the data and where to store it in memory. In addition, when you want to read from the heap or manipulate the data stored there, the computer is going to be slower about completing these operations than it would on the stack.

Keeping track of what is being stored where is something that must be done in C or C++ and doing it poorly will cause problems, Rust takes care of that for us with the rules around ownership.

Here is Rust's ownership concept in action:

{
let message = "Hi!";
//message can be accessed here
}
//message is no longer available down here.

The variable message is storing the word "Hi!" as a string literal. Doing this will allocate storage on the stack. As far as I understand, variables are block scoped in Rust so, message is valid within its block and then it is freed from memory once the program is done with that block. However, since it is stored as a string literal, it cannot be mutated or reassigned. This contrasts against JavaScript where we could reassign the value inside the scope above like so:

{
let message = "Hi!";
let mesage2 = message;
console.log(message2); //"Hi!"
}

If we want to do that in Rust we need to use a more complex string type ```String```.  ```String``` allows for strings of different sizes to be stored. As discussed earlier, since the size is not static, String types are held in the heap.

{
let message = String::from("Hi!");
let message2 = message;
println!(message2); //"Hi!"
}

Okay, so same result, but what is happening behind the scenes? In a language like C++, there would be a problem here because when freeing the memory from these two variables, they are both pointing at the same memory address in the heap. The computer would be confused about what to do.

Rust solves this problem like this: Once message2 (s2 in the picture) is pointing at the same address in the heap as message (s1), message is no longer in scope. Ownership dictates that the heap address now belongs to message2 as long as the variable is in scope. That way when the memory is freed, there is no confusion, message just goes away and message2 can be responsible for freeing the data stored in the heap.

All of this to show one small example of how ownership works in Rust. As I continue learning more, I'm going to try to keep adding new posts. Until next time.

In technical terms, the HTML and CSS are really easy to recreate using flexbox and the functionality can be achieved with a bit of javaScript. I've added a codepen here if you want to see what that looks like:

And below is the JavaScript code with comments. It's been a while since I've been able to write a bit of vanilla JS. Most of my day to day work makes use of React, Angular, or Node which make it a bit quicker to do some things. Honestly, there's nothing wrong with doing things without a framework for most smaller websites. In my opinion, being able to manipulate the DOM using just the language itself give you a good foundation for understanding some of the abstractions that make your life easier when using modern front end frameworks.

//getting arrays of the checkBoxes and selects
const checkBoxes = document.querySelectorAll( '.check' );
const selects = document.querySelectorAll( '.dropdown' );

//setting the selects to be disabled by default
for ( let i = 0; i < selects.length; i++ ) {
    selects[ i ].disabled = true;
}

//loop over the checkboxes and add an event listener on each one
//if one is checked, I check all previous boxes
//if one is unchecked, all rooms that come after it should be unchecked.
checkBoxes.forEach( ( checkInput, idx, checks ) => {
    checkInput.addEventListener( 'click', function () {
        if ( checkInput.checked ) {
            for ( let i = idx; i >= 0; i-- ) {
                checks[ i ].checked = true;

                if ( i === 0 ) {
                    selects[ 0 ].disabled = false;
                    selects[ 1 ].disabled = false;
                } else if ( i === 1 ) {
                    selects[ 2 ].disabled = false;
                    selects[ 3 ].disabled = false;
                } else {
                    selects[ 4 ].disabled = false;
                    selects[ 5 ].disabled = false;
                }
            }

        } else if ( !checkInput.checked ) {
            for ( let i = idx; i < checks.length; i++ ) {
                checks[ i ].checked = false;
                if ( i === 0 ) {
                    selects[ 0 ].disabled = true;
                    selects[ 1 ].disabled = true;
                } else if ( i === 1 ) {
                    selects[ 2 ].disabled = true;
                    selects[ 3 ].disabled = true;
                } else {
                    selects[ 4 ].disabled = true;
                    selects[ 5 ].disabled = true;
                }
            }
        }
    } );
} );

Above is an example of a singly linked list, meaning that each node only links the next node in the sequence. There are two other variations as well, the doubly linked list and the circularly linked list.

The doubly linked list, as the name implies, allows for each node to have two links. One pointing to the next node in the sequence, and the other pointing to the previous node in the sequence.

As anyone who has a little bit of programming experience would note, these look a lot like arrays. They are similar in that they're both linear data structures but there are significant differences as well.

Arrays are contiguous - each element is stored next to its sibling element in memory. Therefore, the array must be traversed every time something is inserted or deleted. Linked lists are held together by pointer which point to the memory location of the next node in the list. This makes it much more efficient to manipulate through insertion or deletion because you don't have to loop through to find the correct node/element.

Arrays are fixed in size - We have to know the maximum number of elements that might go into the array ahead of time. If the array doesn't end up holding all of those elements, the memory allocation will still be for the maximum size. So linked lists also have the advantage in only needing to take up memory for nodes used.

There are some downsides though. Linked lists might be more dynamic than arrays in terms of size and memory allocation, but each node must not only hold data but also save room in memory for the pointer. Also, we cannot use Random Access Memory to access pieces of a linked list, we must go sequentially through the list to find the item we need.

Alright, enough theory. Let's try to implement a singly linked list in JavaScript. Knowing what we know now, let's try to break this down into manageable pieces. Again, a linked list is a bunch of nodes that consist of data and a pointer. So, I'll start by creating something that can generate nodes for me.

class Node {

    constructor(data, pointer = null){
    
        this.data = data;
        
        this.pointer = pointer;
        
    };

};

In the code above, I created a class called Node. Using a class is important because it makes it easy to generate new nodes for the list. The constructor takes in whatever data it is passed as well as a pointer. If a pointer isn't designated, then a default value of null is used. From here, we can build another class that generates our actual list.

class LinkedList {

	constructor(){
    
		this.head = null;
	};
};

For the LinkedList class, the constructor won't take in any values. Instead, I'll set a default value for the head of null. When a list is created from this class, there won't be any nodes inside at first. Once we add one, it will be the value for this.head.

This is how you instantiate the LinkedList class and what it looks like once we log it to the console:

const myList = new LinkedList();

console.log(myList); //LinkedList { head: null }

Now that we have the list, we can start adding and removing nodes from it.

The best way to do this is by creating prototype methods on the class which we can then call in any subsequently created child objects.

Linkedlist.prototype.addFrontNode = ( value ) => {

    //create a node and assign it some value or data
    
    let node = new Node(value); 
    
    //create a pointer and point it at the head 
    node.pointer = this.head;
   
   //assign the head value to the node since we are inserting
   //it in the front of the list
   
   this.head = node;
   
   return this.head;
};

So that takes care of adding a node to the front of the list. We can now easily do so by calling the addFrontNode method on an instance of the LinkedList class. Here's how you would remove a node from the front as well:

LinkedList.prototype.removeFrontNode = ( value ) => {

    //check to make sure the node you are trying to remove is the first
    //in the list
    if(this.head === false) {
        return;
    };
    
    //reassigning head to the next item in the list
    //if there is one
  
    this.head = this.head.pointer;
   
    
    return this.head;

};

When removing a node from the front of the list, our method above checks to make sure that this.head has a value. This indicates that we are looking at the actual front of the Linked List. Then, we simply reassign the value of this.head to the next node in the list by using the pointer property on the head object. The pointer should already be pointing at the next item. If our pointer has a value of null, then we know that there are no more items in the list after the one we are deleting.