Forem: Spenser Brinkman

Ternary Operations: the 1+ Line If/Else Statement

Spenser Brinkman — Wed, 31 Mar 2021 22:40:09 +0000

If/else statements represent one of the purest forms of programming. Logic gates and conditional functionality is often what makes the tech world go 'round. If/else is so ubiquitous and essential to writing effective code that it is often one of the first concepts and syntaxes learned by new programmers and really shouldn't need much explanation here. In contrast, there exists an alternate form of the if/else, often discovered later in one's learning, called a conditional/ternary operator, or simply ternary. Ternaries can be harnessed to write much more concise and elegant code, but not without the risk of over-complicating things if overused.

Take, for example, this bland and reductionist if/else:

if X
  A;
else
  B;
end

The code above can be transformed into the following ternary:

X ? A : B

Much prettier, concise, and some even say more readable! As stated before, care needs to be taken to not overdo it.
Try turning this into a single-line ternary:

if X
  A;
else if Y
  B;
else if Z
  C;
else
  D;
end

Tecnhically, it can be done. I might consider trying to use a case statement instead of turning this into a ternary, or I might even leave it alone, unchanged. But the point of this article is to show that it can be done! Check it out:

X ? A : (Y ? B : (Z ? C : D))

I'd argue that this is not easy to read, and might even be considered 'uglier' code than a traditional if/else. But what if we tried some chaining and formatting magic to make it a bit more readable?

X ? A      // if X is true, do A
: Y ? B    // else if Y is true, do B
: Z ? C    // else if Z is true, do C
: D        // if all else fails, just give up and do D

This is functionally identical to our traditional if/else defined above, but with the added bonus of cutting the number of lines used by more than half, and also finishing with (subjectively) more elegant code.

You can even have multiple actions occur for a condition by separating with commas:

X ? A, C      // if X is true, do A, then do and return C
: Y ? B, D    // else if Y is true, do B, then do and return D
: Z ? C       // else if Z is true, just do C
: D           // if all else fails, give up and just do D

The final action in a comma-separated list will be the returned value of the whole ternary operation.

There are lots of other ways to utilize the ternary operator, with plenty of documentation from MDN to help give you some ideas. The key is to be creative, but don't lose sight of the importance of readability!

React.js/Redux + Drag&Drop

Spenser Brinkman — Sat, 27 Mar 2021 04:51:28 +0000

In my most recent project, 'GreenHouse', users manage spaces that may contain any number of house plants. One of my goals with this project was to incorporate as much interactive functionality as I could to provide a fluid user experience. Drag-and-drop was a big step towards this objective. I wanted to be able to drag plants between spaces and update the containing room components appropriately, and accomplishing this was relatively straight-forward to incorporate with my Redux build.

We start off with two basic components: a PlantCard and a SpaceCard. I'm more familiar with class components, but this functionality might also be achievable using functional components.

First, our PlantCard

## PlantCard.js

import React, { Component } from 'react';

class PlantCard extends Component {

  # unrelated PlantCard functionality goes up here

  render() {
    return(
      <ul className='plant-card'>
        # plant information goes here
      </ul>
    );
  }
}

export default PlantCard

...then our SpaceCard

## SpaceCard.js

import React, { Component } from 'react';

class SpaceCard extends Component {

  # unrelated SpaceCard functionality goes up here

  render() {
    return(
      <div className='space-card'>
        <div className='space-info'>
          # space info goes here
        </div>
        <div classname='space-plants'>
          {this.props.plants.map(plant => <PlantCard plant={plant} />)}
        </div>
      </div>
    );
  }
}

export default SpaceCard

With our basic components set up, we can build in our drag & drop functionality. First, we'll tell our PlantCard about being dragged around.

dragStart = event = {
  const plant = JSON.stringify(this.props.plant);
  event.dataTransfer.setData('plant', plant);
}

When the mouse button is held and dragged away from a Plant component, the component's plant prop is stored in the DataTransfer object under the keyword plant.

As a safeguard to prevent strange graphical issues, we can also add this function to our PlantCard class component:

dragOver = event => {
  event.stopPropagation();
}

Finally, we'll attach these functions to the HTML elements being rendered by the component, and also assign 'true' to the 'draggable' attribute.

render () {
  return(
    <ul
      className='plant-card'
      onDragStart={this.dragStart}
      onDragOver={this.dragOver}
      draggable='true'
    >
      # Plant information goes here
    </ul>
  );
}

As for our SpaceCard's ability to receive dropped PlantCards, we'll follow a similar pattern as before.
First thing to note is that D&D will not work if the receiving element doesn't have an 'on drag' function, so we'll define that with a generic event.preventDefault() as a safeguard for unintended behavior.

dragOver = event => {
  event.preventDefault();
}

Next is the powerhouse of the operation, where we actually tell the application to change the plant's associated space to the one it's being dropped upon.

drop = event => {
  event.preventDefault();
  const plant = JSON.parse(event.dataTransfer.getData('plant'));
  plant.spaceId = this.props.space.id;
  this.props.editPlant(plant);
}

There's a lot going up there, so we'll break it down line-by-line. We start with a basic preventDefault() again as a catch all (I wish) for unwanted problems. Next, we access the plant data we have saved away by asking for that 'plant' keyword from the DataTransfer object, setting it to a variable. We take that variable, change the necessary attributes (spaceId in this case), and then pass it to a dispatch function provided by our redux store. For the sake of brevity, I've omitted the process of connecting components to the store.

Finally, we can tell the HTML all about it with a few more changes:

render() {
  return(
    <div
      className='space-card'
      onDrop={this.drop}
      onDragOver={this.dragOver}
    >
      <div className='space-info'>
        # space info goes here
      </div>
      <div classname='space-plants'>
        {this.props.plants.map(plant => <PlantCard plant={plant} />)}
      </div>
    </div>
  );
}

In the end, you'll end up with something that can do a little dance like this:

Making a Responsive Icon Button in JS

Spenser Brinkman — Thu, 04 Feb 2021 19:23:31 +0000

I recently wrapped up the initial iteration of my very first JS web application. While I found the crossover between my backend database and my frontend display to be powerful and intriguing, what really excited me was the styling and interactivity of the application. I wanted everything to be sleek, simple, and responsive. One such example can be found in the buttons I included in the header of the application, seen in the top-left and top-right here:

The leaf button and door button, when clicked, render a form for creating a new plant or new room, respectively. My goal was to have the icon change from its initial green color to a contrasting orange when the mouse is hovering over the icon and also when the corresponding form is open, like this:

Accomplishing this is actually quite simple. Since I already had functional buttons rendering their matching form, all I had to do was find a way to change the image displayed upon certain DOM events, specifically on mouse click and on mouse hover.

My first step was to add both green and orange versions of my button icons into my application's local file structure. An external source can also work for this.

In my .html file, I added a <div> with a class green-leaf to the leaf's <button> tag and a <div> with a class green-door to the door's <button> tag.



<button id="leaf-button"><div class="green-leaf"></div></button>

The green- classes would act a sort of default state for the divs within the buttons.

In my .css file, I add the following lines:



.green-leaf {
  content: url("../images/green-leaf.png");
}

.orange-leaf {
  content: url("../images/orange-leaf.png");
}

.green-leaf:hover {
  content: url("../images/orange-leaf.png");
}

.green-door {
  content: url("../images/green-door.png");
}

.orange-door {
  content: url("../images/orange-door.png");
}

.green-door:hover {
  content: url("../images/orange-door.png");
}

Now, when an element has a class of green-leaf, its content will be sourced from the corresponding url which directs to the local image file of a green leaf. When the class is changed to orange-leaf, the content will be changed to the url directing to the local image file of an orange leaf. This content change also takes place when the button for a unopened form (depicted by a green icon) is hovered over with the mouse.

Now all that's left would be to add JS event listeners onto the elements in question. This is also very straight-forward. A very basic example would be as such:



//grab the div containing the image

let leaf = document.querySelector("#leaf-button div")


//add an event listener to the leaf with an anonymous function

leaf.addEventListener("click", function(){
  leaf.classList.toggle("green-leaf")
  leaf.classList.toggle("orange-leaf")
}

Now every time the button is clicked, it will alternate between having a class of green-leaf or orange-leaf, applying different CSS rules in the process.

Basic Rails Website Header

Spenser Brinkman — Fri, 08 Jan 2021 23:34:24 +0000

The header is ultimately one of the most viewed elements of many websites. In most cases, it should be visually simple with a priority on convenient functionality in regard to the user experience.

I recently built a basic Ruby on Rails application called TreeLogger for keeping inventories of trees on any number of properties belonging to the user. One of the first things I set out to do was build a very basic but helpful header which would be present across the entire website.

What I came up with for this early version of my application was this:

The logo, composed of a picture of the tree and the text "TreeLogger", acts as a link to the root path of the website.

To the right are three buttons, each with their own functions.

The "Properties" button takes the user to the index page of all properties on their account.
The "Home Page" button actually does the same thing as clicking on the logo, but I chose to build it into a button for those who don't think to click on the logo to go home.
Finally, the "Log Out" button does what it says and logs a user out of their account.

The process for building this header is as follows:

In app/views/layouts/application.html.erb, start with an empty header tag. This is where the code for our website's header will live.

<header>
</header>

We'll need a link to our logo that directs to the root path of our website, for which we'll utilize an ERB expression.

/app/views/layouts/application.html.erb

<header>
  <a href=<%= root_path %>>
  </a>
</header>

The content displayed as the link will be the logo itself, which is going to be composed of the tree image and the name "TreeLogger" (don't forget to assign alternate text to the image for those using a screen reader for accessibility).

<header>
  <a href=<%= root_path %>>
    <img src="/images/logo.png" alt="TreeLogger Logo" height="35", width="auto">TreeLogger
  </a>
</header>

Next, we'll build the three links to appear on the right side of the header using some helpful ERB expressions. These URI paths have been defined in config/routes.rb

<header>
  <a href=<%= root_path %>>
    <img src="/images/logo.png" alt="TreeLogger Logo" height="35", width="auto">TreeLogger
  </a>

  <%= link_to "Properties", properties_path %>
  <%= link_to "Home Page", root_path %>
  <%= link_to "Log Out", logout_path %>
</header>

Here's what we have so far:

Not quite right... Let's keep going. First, we'll separate the logo from the other three links and send them to their respective sides of the header. We can accomplish this by placing each "group" of elements into a corresponding <span> and assigning a special style property to the span meant to live on the right

<header>
  <span>
    <a href=<%= root_path %>>
      <img src="/images/logo.png" alt="TreeLogger Logo" height="35", width="auto">TreeLogger
    </a>
  </span>

  <span style="float:right;">
    <%= link_to "Properties", properties_path %>
    <%= link_to "Home Page", root_path %>
    <%= link_to "Log Out", logout_path %>
  </span>
</header>

Which gives us:

Getting closer, now to apply a bit more styling to make it presentable. We'll add a class to the logo link and a class to each navigation link, then define the styling for both in the application's CSS stylesheet

/app/views/layouts/application.html.erb

<header>
  <span>
    <a class="logoLink" href=<%= root_path %>>
      <img src="/images/logo.png" alt="TreeLogger Logo" height="35", width="auto">TreeLogger
    </a>
  </span>

  <span style="float:right;">
    <%= link_to "Properties", properties_path, class: "navButton" %>
    <%= link_to "Home Page", root_path, class: "navButton" %>
    <%= link_to "Log Out", logout_path, class: "navButton" %>
  </span>
</header>

/app/assets/stylesheets/application.scss

a.logoLink {
    color: inherit;
    text-decoration: none;
    font-weight: bold;
    font-size: 300%;
  }

a.navButton {
    background-color: rgb(25, 78, 38);
    border: none;
    color: white;
    padding: 7px 14px;
    text-align: center;
    text-decoration: none;
    display: inline-block;
    font-size: 12px;
    margin: 4px 2px;
    transition-duration: 0.4s;
    cursor: pointer;
    border: 2px solid #4CAF50;
  }

a.navButton:hover {
    background-color: white;
    color: black
  }

Which will give us the final look of:

Lastly, let's have the appearance of the navigation buttons be conditional to whether the user is logged in or not, using a logged_in? method which is a commonly defined custom method used for authentication in many basic Rails applications. This leaves us with our final code:

<header>
  <span>
    <a class="logoLink" href=<%= root_path %>>
      <img src="/images/logo.png" alt="TreeLogger Logo" height="35", width="auto">TreeLogger
    </a>
  </span>

  <% if logged_in? %>
    <span style="float:right;">
      <%= link_to "Properties", properties_path, class: "navButton" %>
      <%= link_to "Home Page", user_path(current_user), class: "navButton" %>
      <%= link_to "Log Out", logout_path, class: "navButton" %>
    </span>
  <% end %>
</header>

Now, if there is no user logged in, the header appears only as:

Embedded RuBy (ERB)

Spenser Brinkman — Mon, 23 Nov 2020 01:30:56 +0000

`closing_statement = "Thanks for reading!"`

An effective web developer's toolkit should incorporate a diverse and practical range of technologies that can be coordinated to achieve a robust final product. One such example of a technology at the disposal of a programmer is Embedded Ruby. There are a few popular implementations of Embedded Ruby. One such implementation is included in the Ruby standard library and is called "ERB".

Through ERB, one is able to write dynamic text files (such as HTML documents to be viewed as web pages) using integrated Ruby code and logic.

Exempli Gratia

Let's say I wanted a web page to display something like this:

I could write an HTML document as such:

But with the power of ERB, I can achieve the same results by having my application require the 'erb' gem and writing the following code in a .erb file*:

In the example above, you might notice two unfamiliar tags:

Execution tags, represented with <% some ruby code %> (also known as ice cream cones) to create what are called "scriptlets"

and

Expression tags, represented with <%= some ruby code %> (otherwise aptly called squid tags) to create "expressions"

Scriptlets are the purest form of embedded Ruby, in that they covertly execute the enclosed Ruby code upon any HTML elements indicated. A user won't ever actually see the results from a scriptlet, but they will see the effects they bring upon the HTML elements being executed upon. Expressions, on the other hand, will run Ruby code and display, as a string, the returned value of said code.

In other words, going off of the above example, line 1's scriptlet initiates a loop to be run 10 times. The only code within our loop's block is an expression on line 2 which returns a literal string of "Hello, World!" followed by an HTML <br> tag to create a line-break. Line 3 wraps up the code with another scriptlet, this time indicating the end of our loop's block.

In Summary

This elementary example is just a taste of the power of ERB. Any code that can be written in a plain .rb file can also be interpreted in scriptlets and expressions. A programmer could, theoretically, write the entire codebase for their ruby-based web application all within a single .erb file.**

Documentation for ERB is as extensive as the technology itself is powerful, so if one means to take advantage of it's utility, there are many avenues to research, such as the rubyonrails.org RailsGuide

`closing_statement = "Thanks for reading!"`

`<%= closing_statement %>`

Convention often* dictates that the file should be ended with the document type followed by .erb, as in "example_file.html.erb". This helps to avoid confusion about exactly what type of document is being acted on by Ruby code without having to open the file to investigate.

**Writing an entire application in a single .erb file is not recommended.

Adding flavor to a Ruby CLI application

Spenser Brinkman — Sun, 25 Oct 2020 23:57:20 +0000

The CLI terminal is a technology infamous for its ability to repel and render useless the sharpest of minds raised in a graphical environment like Windows and iOS. The absence of color, abrupt flow of text, no-nonsense and matter-of-fact atmosphere that pervades its very essence. These are the cornerstones of what makes the terminal such an intimidating force for those unfamiliar with its hidden power and potential.

I have only recently begun my journey towards understanding the nuance and mystery of one of the most fundamentally instrumental tools developed across the history of computers. The first 'major' project I built from scratch was a Jeopardy game, meant to be played by one player in the terminal. As someone who comes from a Windows-only household, the lack of graphics and animation in an application (especially a game) is unsettling to me, and so it was only natural that I try to inject some stylistic elements into my program to make it a bit more approachable.

There are a number of tools available to one wishing to spice up a terminal application. I've put together a short list of some of the things I was able to exploit to bring my solo-Jeopardy game from "technically playable" to "nearly enjoyable".

Alignment

By default, the terminal justifies all text to the left side of the screen. This is fine in most scenarios, but for the purpose of my program, I wanted most of my output to appear centered in the screen.

I thought myself clever to just add a carefully counted number of spaces in front of every single line of text to be output in my program, until I stumbled upon the very handy .center() method, which can be called on a string to be output. This method centers the string in a provided argument of width as a number of characters.

I used the Ubuntu terminal for my Jeopardy application, so I went into Ubuntu's settings on full-screen and determined the maximum width of my terminal to be 172 characters on my 13.3" laptop screen. Then, centering the text of my program was as easy as appending .center(172) to each string in my code which I wanted to be centered when output.

If you add a second argument to .center(), the padding on each side of your string will be changed from empty spaces to the character provided as a second argument!

Colorize

A useful and well-known Ruby gem is Colorize. Colorize allows programmers to add colorful output to their CLI application with varying degrees of customization. The simplest use of the gem, once installed, is to append the method .blue or .red, or any other color supported by the gem, to change the color of output text. Follow the text color method with .on_green or .on_white etc to give the output a background color!

.sleep

To a user unfamiliar with a text-based terminal, it is sometimes shocking to be faced with an enormous wall of text after entering a single input. "Where do I even begin to start reading? Where did my input end up?" Something I like to utilize in order to make outputs more digestible is the sleep() method. This method, simply put, tells the program to sleep for a number of seconds (including floats with fractional seconds), given as an argument. The program will wait that number of seconds, and then resume. A few well placed sleep(0.5) or sleep(1) can make a long wall of text much more readable for users, instead of spitting the text out all at once.

Put it all together!

Throw in a few 30.times {puts ""} and you've got yourself a simple but refined introduction screen that would make even Trebek proud!

The Big "Why?"

Spenser Brinkman — Fri, 09 Oct 2020 19:36:02 +0000

Prompted with the question "Why did you decide to study Software Engineering?," one looks to their history of experiences had and choices made leading up to such a fundamental change in life direction. Whitewater raft guide, tree climber, park groundskeeper, national park interpreter, produce manager--these hats, and more, make up the varied background I've built up as a part of the blue-collar workforce since my 16th birthday. I am thankful for these jobs, as I was able to pay my way through college with minimal debt to show for it. However, due to the physically intense nature of such work, my body experienced measurable decline and I was faced with a dilemma: stay the course and be forced by my body into an early retirement or jump ship and forge a path to a more fruitful and sustainable career and future. The choice, at this point, was easy for me to make, and so I decided to make a change.

But this does not answer the question of "Why?" as in "Why study coding?," but instead answers "Why not continue to do what you've already been doing?"

As I considered alternate career paths that would utilize my mind over body, I read more about the skills required of a programmer and I realized that I fit the bill. As a lifelong enthusiast of logic puzzles and exercises in critical thinking, along with an affinity for math, creativity, and memorization; my hyper-focus for detail; and my ability to organize multiple evolving ideas at once, I became confident in my aptitude to become a successful software engineer.

Fast forward three months and I am two weeks into a 20 week software engineering bootcamp. So far, any doubts I started with have fallen to the recesses of my mind and I am more sure than ever that the choice to jump head-first into this program was the right one. If anything, I wistfully wish I had made the change sooner. But, at least, I made the change.

Forem: Spenser Brinkman

Ternary Operations: the 1+ Line If/Else Statement

React.js/Redux + Drag&Drop

Making a Responsive Icon Button in JS

Basic Rails Website Header

Embedded RuBy (ERB)

closing_statement = "Thanks for reading!"

Exempli Gratia

In Summary

closing_statement = "Thanks for reading!"

<%= closing_statement %>

*Convention often dictates that the file should be ended with the document type followed by .erb, as in "example_file.html.erb". This helps to avoid confusion about exactly what type of document is being acted on by Ruby code without having to open the file to investigate.

**Writing an entire application in a single .erb file is not recommended.

Adding flavor to a Ruby CLI application

Alignment

Colorize

.sleep

Put it all together!

The Big "Why?"

`closing_statement = "Thanks for reading!"`

`closing_statement = "Thanks for reading!"`

`<%= closing_statement %>`

Convention often* dictates that the file should be ended with the document type followed by .erb, as in "example_file.html.erb". This helps to avoid confusion about exactly what type of document is being acted on by Ruby code without having to open the file to investigate.