Forem: SpencerLindemuth

Ref's can change the flow of the game. Don't overReact

SpencerLindemuth — Fri, 22 Nov 2019 21:13:30 +0000

What are ref's?

Traditionally ref's are the the people in black and white striped shirts who blow whistles and get paid a lot of money to not understand what pass interference is. Ref's are also a really cool feature in React to help manage child component updates without using the traditional flow of updating state, passing props and triggering a re-render, but are also incredibly useful in creating concrete references to instances of components and DOM Nodes.

How does it work?

Finding and using data from DOM nodes is pretty straightforward in JavaScript and React. Use a document.querySelector or document.getElementById whenever you need to reference a node. But what happens when we need to reference a node all across the application? You end up writing a lot of query selectors because the reference usually only survives for the life of the function they are found in. Here is an example of a simple page that focuses the input on button click using query selectors:

import React from 'react';
import './App.css';

export default class App extends React.Component{

  constructor(props){
    super(props)
  }

  focusInput = () => {
    let input = document.getElementById("name-input")
    input.focus()
  }

  render(){
      return (
        <div className="App">
          <label htmlFor="name-input">Please input your name</label>
          <br />
          <input id="name-input"/>
          <br />
          <button onClick={this.focusInput}>Set Input Field Focus</button>
        </div>
      );
    }
}

Seems pretty simple. But what happens when we want to make it a controlled input?
We need to reference the value of the target node's event on change. But let's get add another feature too, and add a button to clear the input field...

import React from 'react';
import './App.css';

export default class App extends React.Component{

  constructor(props){
    super(props)
    this.state = {
      input: ""
    }
  }

  focusInput = () => {
    let input = document.getElementById("name-input")
    input.focus()
  }

  handleChange = (ev) => {
    this.setState({
      input: ev.target.value
    })
  }

  clearInput = () => {
    this.setState({
      input: ""
    })
  }

  render(){
      return (
        <div className="App">
          <label htmlFor="name-input">Please input your name</label>
          <br />
          <input id="name-input" value={this.state.input} onChange={this.handleChange} value={this.state.input}/>
          <br />
          <button onClick={this.focusInput}>Set Input Field Focus</button>
          <button onClick={this.clearInput} >Clear Input</button>
        </div>
      );
    }
}

Ok so we've added some state, some click listeners and we are referencing the input field value with the event target value and we clear the input by clearing the state value the input is tied to. But when we click the clear button, the input field loses focus! This isn't very intuitive. How can we refocus? We would write another query selector and use the .focus() method, but since we are such good programmers, we already have a focus method written for us, so we can just call that after setting state! Now our app is working flawlessly and it only took 42 lines! Nice!

Can we improve on that?

Ref's provide a global access to the node or instance to be referenced or interacted with anywhere in the class and this node is then able to be passed around to be referenced and interacted upon by other components. Ref's are able to do this by being declared in the constructor with the .createRef() method as seen here:

import React from 'react';
import './App.css';

export default class App extends React.Component{

  constructor(props){
    super(props)
    this.textInput = React.createRef()
    this.state = {
      input: ""
    }
  }

  handleChange = () => {
    this.setState({
      input: this.textInput.current.value
    })
  }

  clearInput = () => {
    this.setState({
      input: ""
    })
    this.textInput.current.focus()
  }

  render(){
      return (
        <div className="App">
          <label htmlFor="name-input">Please input your name</label>
          <br />
          <input ref={this.textInput} value={this.state.input} onChange={this.handleChange}/>
          <br />
          <button onClick={() => this.textInput.current.focus()}>Set Input Field Focus</button>
          <button onClick={this.clearInput}>Clear Input Field</button>
        </div>
      );
    }
}

This code does the same thing as the previous code but using Refs. It's 39 lines, which isn't a huge improvement, but a penny paid is a penny saved in my book. Let's break down what's changed. We create the ref in the constructor, so the input field is referenceable everywhere in out class. For example, in the onClick() method of the focus button, we don't need to write an external function and a query selector. We simply reference the textInput ref and use the .focus() method. Now in this code we only "find" the DOM node once, when it's built, versus 3 times in the previous code. In this code we also drop the ev.target.value we used before and directly reference the current value of the input field.

Other advantages

Those were obviously crude examples where we didn't gain a large view of the advantage of refs, but it showed syntax and ease of implementation. So what are the larger scale advantages? One of the biggest is stepping away from HTML id's for locating elements, which can change, creating lots of "find and replace"-ing by referencing the instance of the node itself. Another advantage is readability and ease of access. For example, with form validations, if a user presses submit, but forgot to enter their address, it's very easy to highlight the error field, and focus the cursor there to intuitively point the error out.

Things to note

Ref's don't work with functional components. This is because functional components do not have a this context (aka they don't have an instance). So you cannot reference the functional component like a class component. You can however use ref's inside a functional component by declaring them at the top of the function as a global variable. Another note is that when referring to a node with a ref, the node itself is stored in the .current method as seen above in this.textInput.current.focus().

Conclusion

Refs are a great tool providing easy access to DOM elements and passing nodes around, but at the end of the day, they are at risk of being overused. They take components and actions out of the traditional dataflow of React, avoiding the almighty rule that state changes should re-render components, which characterizes React as a framework. So be careful with all this newfound knowledge and use them only when necessary! Usually in the context of forms and accessibility.

Realm Data Storage in React Native and Node.js

SpencerLindemuth — Mon, 18 Nov 2019 00:11:15 +0000

I've been developing a React Native application recently that stores some highly confidential information and it really made me stop and think about storage solutions. I'm traditionally a React web developer and I hadn't really stopped to consider the differences between web and native application development.

Differences

When you create a traditional web application or site, your data persistence is kept to the back-end, and when you need more information, or need to save some, you send HTTP requests back and forth with the server who will handle that with a database connection. If you have something more short term you need to store, like a user or session id, you have a handful of options such as cookies, session storage, and HTML 5 LocalStorage. This is a fine solution that has functioned elegantly for years and something we are all overly familiar with. But when it comes to mobile app development things can be a little trickier. In mobile app development come a new set of hurdles that users on desktops aren't faced with. Spotty connections, limited data plans, and slower network speeds. These sort of hurdles can present a large barrier in terms of application performance. If you need to gather a feed of photos, there is still no way around making a network request, using data, and relying on an internet connection. But what if there is data or pages a client uses frequently and are an integral part of the app whether the client is at home on wifi or across the world and roaming? Now we need a quick, reliable and safe place to save this data with a little more longevity than cookies.

Built in storage with React Native

React native comes with a built in storage solution that works across all platforms called AsyncStorage. Just like HTML 5's implementation of LocalStorage, it stores strings of data in a key - value pair, however AsyncStorage (as the name implies) stores data Asynchronously. The problem with AsyncStorage is that data can only be of the type "String" so data must constantly be converted back and forth, it cannot be reliably encrypted, and it can only store key - value pairs, which gets very complex for large data sets and the data can have no polymorphic relationships.

Enter Realm

Realm is a storage system built for all platforms that uses an object oriented approach to databases, and can interface with Java, Swift, Objective-C, JavaScript, and .Net. Realm is also handy in the fact that it dynamically encrypts data depending on environment, using AES-256 standard encryption on an Android Device, the built in CommonCrypto library in iOS and the Crypto library included in Windows for native Windows applications. This means less code for you, and 200% more flawlessly running environments!

How to use Realm

Getting started with Realm is easy. First create a new React Native project:

react-native init <project-name>

Then install Realm:

npm install --save realm

and then link Realm to your native project:

react-native link realm

So now we have a project created, lets see how to implement a super simple React Native App that utilizes Realm (from the Realm docs)

import Realm from 'realm';


//Create a simple class component
class <project-name> extends Component {
  constructor(props) {
    super(props);
    //initialize a piece of state that we will also be persisting
    this.state = { realm: null };
  }

  componentWillMount() {
    //open the realm database connection
    Realm.open({
      //define the schema. 
      schema: [{name: 'Dog', properties: {name: 'string'}}]
    }).then(realm => {
      realm.write(() => {
        //here we create a new Realm "Dog" object as if it was a class
        realm.create('Dog', {name: 'Rex'});
      });
      //here we update state with the data from Realm
      this.setState({ realm });
    });
  }

  render() {
    const info = this.state.realm
      ? 'Number of dogs in this Realm: ' + this.state.realm.objects('Dog').length
      : 'Loading...';

    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          {info}
        </Text>
      </View>
    );
  }
}

and here is a more in depth look at interfacing with Realm storage:

const Realm = require('realm');

// Define your models and their properties
const CarSchema = {
  name: 'Car',
  properties: {
    make:  'string',
    model: 'string',
    miles: {type: 'int', default: 0},
  }
};
const PersonSchema = {
  name: 'Person',
  properties: {
    name:     'string',
    birthday: 'date',
    cars:     'Car[]',
    picture:  'data?' // optional property
  }
};

Realm.open({schema: [CarSchema, PersonSchema]})
  .then(realm => {
    // Create Realm objects and write to local storage
    realm.write(() => {
      const myCar = realm.create('Car', {
        make: 'Honda',
        model: 'Civic',
        miles: 1000,
      });
      myCar.miles += 20; // Update a property value
    });

    // Query Realm for all cars with a high mileage
    const cars = realm.objects('Car').filtered('miles > 1000');

    // Will return a Results object with our 1 car
    cars.length // => 1

    // Add another car
    realm.write(() => {
      const myCar = realm.create('Car', {
        make: 'Ford',
        model: 'Focus',
        miles: 2000,
      });
    });

    // Query results are updated in realtime
    cars.length // => 2
  })
  .catch(error => {
    console.log(error);
  });

It is important to note that Realm is also an Asynchronous storage solution, like the built in AsyncStorage in React Native.

Relationships

Just like complex database storage solutions using a back-end server, Realm supports complex relationships such as to-one and to-many's. For a to-one relationship, simply set the type of an object's property to the name of the related object, for example from the above code:

const PersonSchema = {
  name: 'Person',
  properties: {
    name:     'string',
    birthday: 'date',
    car:     'Car',
    picture:  'data?' // optional property
  }
};

The car property of the Person object (Person.car) is set to 'Car', or a Car object, declaring the relationship, instead of "string" or "integer" type. For a to-many relationship, simply append a "[]" to the Object Property, defining it as a list. From the example above:

const PersonSchema = {
  name: 'Person',
  properties: {
    name:     'string',
    birthday: 'date',
    cars:     'Car[]',
    picture:  'data?' // optional property
  }
};

Person.cars now return a list of Car objects, because one Person has many cars.

Conclusion

If you are in need of a fast and secure storage solution in a mobile application that handles large sets of data in a locally stored, easy to digest manner, look no further than Realm. The documentation here is extremely helpful, and describes all of the complex actions Realm can handle, including direct queries, advanced relationships, migrations, and encryption.

Concurrent Mode and Suspense in React

SpencerLindemuth — Fri, 08 Nov 2019 22:18:08 +0000

Concurrent mode and interruptible rendering

An experimental build of React was recently released that contained an exciting new feature, a way to fetch data and render UI elements with concurrency. This means we no longer have to fetch data in a useEffect() or componentDidMount() function and wait for the fetch to complete while the user is faced with a blank state screen before the elements all pop in together when the promises are resolved and the map function has mapped.

How does it work?

With the old method, which is considered a blocking render, as your app loads, it only loads the pieces it already has all the data ready for. Your navigation bars, backgrounds, and containers. What doesn't get loaded is the data inside the containers. The posts, pictures, avatars, and usernames. That is, until the necessary fetches complete and resolve and state is set. This is a problem because state, which updates asynchronously on the browser queue, can only set one item at a time. The order of events looks a lot like this:

We request the users avatar and username
We wait...
We finish fetching the avatar and username
We render the avatar and username components
We start fetching the users posts and pictures
We wait...
We finish fetching the posts and pictures
We render the posts and picture components

And to see it in action with a CodeSandbox from the React documentation (press the refresh button in the sandbox browser):

We can see that it first makes a request for the username, waits until it's complete while displaying "Loading profile...", waits until the username is loaded, displays it, and then begins fetching the posts. This is the blocking render. It renders things in the order in which they are received, and once it begins rendering and awaiting the data, it can't be stopped. Another example of blocking render is when typing in a dynamic search field. Say you have a search box for usernames, and after a user presses the "a" key, a state change is triggered, a fetch request for the usernames containing "a" is triggered, the results come in, the results are mapped to a collection of <SearchResult /> components, and they are displayed. Now that's a lot of steps... What happens when a user presses "b" halfway through? Well it triggers another state change... But state changes are asynchronous on the browser queue, so it has to wait for the fetch and render to finish before it can be changed, then we have to follow all of these steps again. This makes your input jumpy and laggy, especially with lots of results.

Suspense - How does it work?

Suspense takes a new approach by utilizing interruptible rendering, which is to say when new data is received, React determines the priority of the new addition to the queue and renders what it sees fit. In other words, if it is awaiting fetch requests to return data, in memory, it will build semi-constructed components and only render the pieces it has information for. So whenever a component has all the pieces it needs to be displayed, React pushes it to the top of the queue to be displayed next. The flow would look something like this:

We start fetching
We start rendering
We finish fetching

Now that is a lot fewer steps and we never have to wait! We can again, see it in action here with a CodeSandbox from the React documentation (press the refresh button in the sandbox browser):

If we look closely, it begins rendering the username and the post components, then displays them quickly as they come in. Much faster! If we revisit our case of dynamic search and are looking for usernames again, what's the flow with Suspense? A user hits "a", a state change is triggered, Suspense starts building result components, a fetch reque... oh wait the user typed 'b'! Ok we still have the components being constructed, but they don't have any data yet, so let's just throw the new data on them! Boom! Rendered.

How to use it?

So how do we use this new amazing feature to enrich our applications and improve user experience by reducing jumpy loading and wait times? Here is a code snippet from the React docs:

const resource = fetchProfileData();

function ProfilePage() {
  return (
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />
      <Suspense fallback={<h1>Loading posts...</h1>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>
  );
}

function ProfileDetails() {
  // Try to read user info, although it might not have loaded yet
  const user = resource.user.read();
  return <h1>{user.name}</h1>;
}

function ProfileTimeline() {
  // Try to read posts, although they might not have loaded yet
  const posts = resource.posts.read();
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

The first thing we do is call a function that fires our fetch requests (in this case fetchProfileData()). Next in the return of our <ProfilePage /> functional component, we wrap both <ProfileDetails /> and <ProfileTimeline /> in <Suspense /> tags, and we provide it with a prop of "fallback". The fallback is simply what is loaded when the data isn't completely fetched yet and it can be an HTML element or another React component. The <Suspense /> magic behind the scenes starts building the <ProfileDetails /> and <ProfileTimeline /> components in memory and sees the <ProfileDetails /> component isn't complete yet, because the resource.user.read() function returned only a promise, so it displays the fallback element and it moves on and checks the resource.posts.read() return in the <ProfileTimeline /> component. This component isn't complete yet either, so it renders the fallback and moves back to the top of the list. Now the <ProfileDetails /> component is complete so it renders it, and checks <ProfileTimeline /> again which is now complete too, so it renders it as well. So use is really simple. We have a resource object that contains all of our data, a <Suspense /> tag that tells React it will be rendering concurrently, with a "fallback" function if the .read() function returns a promise instead of the response data.

Conclusion

Suspense and interruptible rendering are surprisingly easy to use and have a dramatic increase on load times, application speed, and user experience. Gone are the days of elements popping onto the screen unexpectedly and keyboard input being blocked by the render of elements. Gone are the days of keeping your users...... in suspense.

resources: https://reactjs.org/docs/concurrent-mode-suspense.html

!Stacks && Queues... Stacks || Queues!

SpencerLindemuth — Fri, 01 Nov 2019 21:32:47 +0000

Stacks and Queues

Stacks and Queues are sometimes verbally used interchangeably or together with an "and" and do somewhat of a similar things. They hold a series of values or data, in which you can add or remove a value and the order of each cannot be rearranged. They are actually very different structures however and have vastly different real world applications, so let's find out what they are!

Stacks

Stacks are a non-primitive data structure (or abstract data type) that have a few methods, .push() and .pop(), being the most used, but also have a .peek() to get the top element without removing it, .isFull() to check if it's full, and .isEmpty() to check if it's empty. Stacks work from the Last In First Out principle (LIFO), meaning the element that you .push() onto the stack is also the same element returned when you .pop() an item off. This can be seen in the diagram below:

This LIFO property is important for stacks and the largest difference between it and a queue which has a First In First Out property (FIFO). Imagine a stack like a pile of unorganized DVD's on the shelf when you are trying to watch a movie. To get to "Kindergarten Cop", which you haven't watched in years, you have to sift through all the other DVD's on top of it first. Another example would be, that you just bought and watched "Spider-man: Into the Spider-Verse" so you toss it on the top of the pile. Now tomorrow night when you want to watch it again, you don't have to sort through 150 scratched copies of 80's kung fu movies to get to it, you know it's right on top where you left it. Obviously this is a primitive example, so what are the real world applications when it comes to algorithms and programming?

Stack Creation

First, to create a stack, we need a list of organized data and we always need reference to the item at the top of the stack (or the head if you will... bet you can guess where this is going). We can make a functional stack using a linked list! WOW! So meta... Using a linked list we can add elements to the head and remove them from the head at a constant time complexity (O1) because we never need to iterate through the list, just update the pointer of the head. We can also add an instance variable for length so we never have to iterate for .isFull() or .isEmpty() either.

Stack algorithm

A very simple example of an algorithm where you would use a stack for efficiency is reversing a string. After all elements are added to the stack, you simply pop them off and they come out in reverse order (LIFO).

public String reverseString(String str){
    //initialize a new stack
    Stack<Character> stack = new Stack<Character>();
    //iterate through the string adding each char to stack
    for(int i = 0; i < string.length; i++){
        stack.push(str.charAt(i));
    };
    //initialize a new reversed string
    String reversedString = new String;
    //now push each char onto a new string
    while(!stack.isEmpty()){
        reversedString = reversedString + stack.pop;
    };
    //return the reversed string
    return reversedString;
};

Here we don't have to create an Array, keep track of the end of it, or remember whether we are adding or grabbing characters from the right end of the array.

Queues

Queues are the same ordered list of elements that a stack contains but the elements get pulled off the opposite end of that they are added. To visualize, a line of cars entering a tunnel come out of the tunnel in the same order (barring we are actually in a fast and the furious film):

Queues have two main functions as well but they are known as .enqueue() and .dequeue() instead of .push() and .pop() (because developers love making you type "q u e u e" to try and make you trip up) and also contain .peek() for seeing the element on the end of the queue, .isFull() and .isEmpty(). There are also different implementations of queues, including Priority Queue, Circular Queue, and Doubly Ended Queue. A priority queue is a queue where each element also has a "priority" value, and elements with a higher priority are served first. Circular Queue is where the tail or end of the Queue holds reference to the first element. Lastly a Doubly Ended Queue is a queue where elements can be both added and removed from either end of the queue.

Queue Creation

Queues are a list of organized data where we need reference to the head to add items to the queue and the tail to remove items. Yup you guessed it, it is a doubly linked list! This means adding and removing elements is constant (O1) because to add we push at the head and add a pointer to the rest of the list and removing from the tail removes the pointer to and from the element behind it.

Queue Algorithm

There are a lot of uses for queues in computing and telecom and we use them every day in person, at say the supermarket, where the first person in line to check out, gets checked out first. But where can we use them in computer science and improving algos? They are very handy at improving the complexity of Binary Search Tree operations and traversal, but we will talk more about that next week! A more simple problem to utilize a queue is a function takes requests from users and serves information back in the correct order using a standard queue. Say you have a game and want to ensure that a user presses the buttons in the correct order, the clicks or keypresses can be logged in a queue and analyzed with maintained order!

Next week we will dive into the right time to use binary search trees!

references

https://techdifferences.com/difference-between-stack-and-queue.html

When to actually use linked lists

SpencerLindemuth — Thu, 24 Oct 2019 19:24:31 +0000

We've all learned in school or in our bootcamps about different complex data structures. Linked lists, hash maps, binary trees and search trees, stacks, queues, monotonic queues, etc... We've all also learned about how to write each one, how to traverse nodes, add nodes, and delete nodes. But what good is knowing all this stuff if we don't actually know when to use these data structures..

Linked Lists

As a brief recap, let's recall what linked lists are. Linked lists are a series of "nodes" containing a value as well as a pointer to the next node in the series. In a linked list you have access to the "head" of the list and all subsequent nodes are found by traversing through the list one by one. A doubly linked list has the same properties except a reference to the "tail" is kept as well and nodes also have a reference to the previous node, and the list can be traversed in reverse. Linked lists are usually compared to arrays as a similar data structure and although arrays are "primitive" data structures, they share similarities with linked lists.

Similarities

They both, for example, require traversal to access all elements in the structure and they both can be used to store linear data of similar types.

Differences

To really notice the differences you need to be programming in an older, compiled language such as C++, Java, or C# where arrays are of fixed length.

This is because the memory for each array is allocated on compile, while linked lists get allocated on runtime. This is advantageous to link lists because they can be resized dynamically at runtime, while changing the size of an array involves creating a new array of longer length and using more memory, or you have to know the upper limit of the needed length beforehand, wasting memory space. This is less of an issue in JavaScript, Python, and Ruby where arrays can be dynamically resized using operations like .push() and .pop()

The memory allocation however is more efficient with arrays than link lists because the data at each index is stored directly in the allocation for each index, whereas link lists have to store a value, as well as a pointer to the next (or previous and next in a doubly linked list) node.

Arrays can also reference a particular element using an index, so to get the 5th element:

    String[] array = new String[10]; //initializes new array of strings with length 10
    String fifth = array[4]; //access the fifth element in the array (constant time)

and so on, while linked lists require access to the head, and then a loop to traverse the elements:

LinkedList<String> linkList = new LinkedList<String>();
 //initializes a new linkList with type string. (no length specified)
 linkList.search(4);

//then inside the linkList class:
public <T> search(int input){ 
  head = current;
  int counter = 1;
  while(current.next != null){
    if(counter == input){
      return current.value
    }
    else{
      counter++;
      current = current.next;
    }

Here we are looking for the 4th element of linkList, so we have to iterate through the first three values to get the fourth. Since space time complexity is worst case scenario, the lookup of a value in a linked list is O(n) because it is dependent on the length of the linked list as well as the index you are searching for. An array lookup on the other hand is a constant time-complexity ( O(1) ) because it is a direct lookup to the memory location of an element at a specific index.

Linked lists (especially doubly linked lists) have a better space time complexity for adding and removing nodes at ends because inserting (or removing) the target element consists of simply changing the pointer(s) of the surrounding elements. To insert in the middle the complexity is still linear ( O(n) ) in a singly linked list because you must traverse to the index and update the pointer. The advantage here over an array comes from it's space complexity where you must traverse to an index, insert the value, and then find something to do with the remaining elements to re-position them. This is done a few different ways but requires more memory regardless.

Use Cases

So looking at the key differences between arrays and linked lists we can see the advantages and disadvantages of each and start to draw conclusions about when to use each. Linked lists utilize their key characteristic, to keep things quick and ordered, to really shine. Real-world applications most commonly include use in other complex data structures. Hash tables, graphs, stacks, queues, and dequeues all utilize linked lists internally.

A linked list can be used as a stack by repeatedly adding and removing elements from the 'head' of the list.

  // create stack linked list 
  StackUsingLinkedlist stack = new StackUsingLinkedlist(); 
  // insert Stack value at head of linked list
     stack.push(task1); 
     stack.push(task2); 
     stack.push(task3); 
     stack.push(task4);

  while(!stack.isEmpty()){
    //execute the task at the top of the stack (head of linked list)
    execute(stack.pop());
  }

A doubly linked list can be used as a queue by adding to the 'head' of a linked list and removing from the 'tail'.

Linked lists can also be the buckets on hash tables to prevent intersection. (If something is already at that hash location, add it to the end of the list).

Other real world applications can include the back button on a browser, an undo button in photoshop, or the cycle of applications running on an operating system.

Conclusion

There is a time and a place to use linked lists and most commonly it's when you want quickly add and remove elements from a container. Usually this occurs in stacks and queues with lower space time complexity over arrays or when you want to keep ordered data with more flexibility than arrays.

Stay tuned next week for part 2 of practical applications: When to actually use stacks.

References:

https://www.geeksforgeeks.org/linked-list-vs-array/

https://www.quora.com/In-which-languages-are-arrays-automatically-resizable-and-in-which-are-they-a-fixed-length

Make a better looking website the hard way

SpencerLindemuth — Tue, 20 Aug 2019 22:31:19 +0000

In part one we covered the fundamental concepts to making a better designed website and some tools to use to do it. Now that you know how to make consistent color schemes, and know that everything on the page craves uniformity, how do we make it all uniform?

Compartmentalization

This is more of a concept that a concrete idea and also applies to all of coding more than just web design, but the principle is important and I'll cover it to reiterate the importance. The easiest way to make every button on the page look the same is to use the same button on every page. It can have a different action on every page, but using the same component in React, or the same CSS class in vanilla JS on every similar button on a site inherently makes it uniform because there is no room for variation in the same code. Since this is a CSS and design based series, I'll skip the React component approach and focus on CSS classes.
The general rule of thumb in CSS is that every element on the page has a unique ID tag, but classes are helpful to spread style along many different elements on a page. To give elements a class in HTML simply say:

<input type="submit" class="generic-button" value="Submit"/>
<button class="generic-button"/>Prev</button>
<button class="generic-button"/>Next</button>

To style these button in CSS use the "." identifier followed by the class name:

.generic-button {
  color: white;
  background-color: red;
  width: fit-content;
  border-radius: 10px;
}

Which yield these generic buttons:

So now any button on our page can still be singled out with a unique ID to have special actions, but given this class will now, without any extra effort, be styled the same as every button on the page upon its first render regardless of functionality.

But what happens when we want the submit button to have some different properties than the other two, while still maintaining the existing style? We could copy and paste the code into a different class, or we can chain classes together with spaces... Let's see it in action:

<input type="submit" class="generic-button submit" value="Submit"/>
<button class="generic-button"/>Prev</button>
<button class="generic-button"/>Next</button>

All we did now is add a space in the class field, so now it's "generic-button submit". If we add another class style in the css:

.generic-button {
  color: white;
  background-color: red;
  width: fit-content;
  border-radius: 10px;
}

.submit {
  background-color: green;
}

We get the results:

How did the button turn green and maintain the border radius and font color?!?!

Well the answer is in the name of the language. It's a Cascading Style Sheet (CSS). This means that we start at the top applying a rule and then we apply more rules and overwrite existing rules (also using specificity rules) as we read further through the file. So now we can add multiple classes to a single element, to set a base style, then sprinkle extra on top to add small unique touches to match functionality and improve flow.
The takeaway here is write less lines of code, and keep things consistent by compartmentalizing classes in CSS to apply just as much style as necessary to keep it usable on as many elements as possible without ever rewriting the same code.

Dynamic spacing

This section is the bane of every web developers existence. How to keep a website looking consistent on every device in a world of thousands of screen resolutions. Before making any styling decisions establish what client you are dealing with, since it's a mobile world now. In javascript you can find client-type by using a function similar to this:

 let getDeviceType = () => {
    if(navigator.userAgent.match(/mobile/i)) {
        return 'Mobile';
    } else if (navigator.userAgent.match(/iPad|Android|Touch/i)) {
        return 'Tablet';
    } else {
        return 'Desktop';
    }
}

And using CSS you can use @media queries like screen width to determine the device being used (see more on mobile formatting here)

@media only screen and (max-width: 600px) {
  /*Mobile styles here for devices less than 600px wide*/
}

Now that we have device type established we can start making layouts that scale correctly across all the devices on the web, but how?

Using dynamic spacing! This means that setting the height of your menubar to 200px is a no go. Because 200px is a much different percentage of your MacBook pro display than it is an of a Nexus 4 phone. But this is an easy fix, because CSS has a handy Percent% unit to fix this! CSS actually has 15 different units used to size things. 6 absolute units (units that never change or scale regardless of device)

Unit	Property	Conversions
cm	centimeters
mm	millimeters
in	inches	1 in = 96px = 2.54cm
px	pixels	1px = 1/96th of an inch
pt	points	1pt = 1/72 of an inch
pc	picas	1pc = 12pt

And 9 relative units

Unit	Property
em	Relative to the font-size of the element (2em means 2 times the size of the current font)
ex	Relative to the x-height of the current font (rarely used)
ch	Relative to width of the "0" (zero)
rem	Relative to font-size of the root element
vw	Relative to 1% of the width of the viewport*
vh	Relative to 1% of the height of the viewport*
vmin	Relative to 1% of viewport's* smaller dimension
vmax	Relative to 1% of viewport's* larger dimension
%	Relative to the parent element

These units make the elements different sizes depending on the screen size (viewport) and propagates down to change the size of children who rely on parent size (percent%) so now on every device the elements will all fit perfectly and scale as you use your phone on change resolution on pc.

(Quick aside about scaling. People with vision impairment rely on the zoom feature to better see your site and read its text so don't set things like font size to things like viewport height because they will always remain the same size regardless of zoom).

Now you have to tools to build sites that display evenly on different devices, while maintaining consistent styling and keeping functionality! All that's left for you to do is come up with a great idea and implement it! Easy!

Resources: w3 schools CSS units

Make a better looking website the easy way

SpencerLindemuth — Thu, 08 Aug 2019 20:56:26 +0000

Good looking websites

A "good looking website" can mean a lot of different things. Every site or company has its own design language. For example Google apps have Material Design, Microsoft uses Fluent Design, and Apple uses their own Apple Design Guidlines. They also use their own fonts, logos, color schemes, and all look totally different and function differently as well. So which language provides the best looking website? Well that's different from person to person. While they all look substantially different they do all have one thing in common. A consistent user experience.

Consistency

If you could have one take away from reading this blog, please let it be the importance of consistent site design. If some of your buttons are rounded while some are square, your nav bar changes thickness on every page, page elements shift 2 pixels when you render a new div, or menu items are in a different order on half of the pages, you are delivering a subtly (or not so subtly) uncomfortable UX. Visitors might not be able to pick out flaws and tell you what they don't like, but they will have a feeling on your page. A feeling that they'd rather be on Instagram or Amazon. Even if you don't follow a particular design language created by an established company, a fully consistent interface will be your design language. A design language to be proud of. So what makes a consistent interface?

Color

Color is everywhere. Color is the thread making up everything we see. If we don't wear clothes that don't match, why would we make a website that doesn't? One of the first things I do before placing any elements on the page is pick a color scheme. Whether I have a color picked before-hand or I find one on the spot, having a base color makes envisioning your future product much more productive and helps get the creative juices flowing. If I have a base color in mind already I'll head to the Adobe Color Wheel website (also known as Kuler) and find the perfect color.

This involves dragging around little sliders until the shade is just right to find the hex color code to use in the css. The perfect color is subjective, but there's a few guidelines I like to adhere to. Your base color is the focal point of your site. This is the color that every element on the page compliments. Usually this is the background color or a menu bar color. For a background color you want something soft and cool that text looks good on top of. Text is always easier to read black on light, and easy to read text is important to enhance your user experience. Menu bar colors should be bold and dark but of the same hue as the background color. Some examples:

These are all nice, even pages to look at, with no eye jar when you open them. Notice where your eyes are drawn to on each page. First to the lighter sections with the easy to read dark text, then slowly scanning to the darker sections. If we take all the colors on the facebook page, and put the values in Kuler we get a wheel that looks like this:

Look at the spread of the sliders. All of the main colors of the page are in a straight line from darker to lighter meaning they are all shades of the same color, with the background being the light in the middle, the contrasting menu bar color being the dark blue on the left, and all the accents contrasting the background complimentarily. It may not be an absolutely riveting design, but it's consistent and nice on the eyes, while only using 5 colors. Your page shouldn't be a rainbow of color to make it more exciting. The content on your page should be the exciting part because that's why the user is there! A great resource I use for picking colors schemes is coolors.co

Layouts - The bigger picture

This section is about the general layout and flow of the site. There are a lot of subtleties in the bigger picture, and some that Ad companies would pay large amounts of money to understand better, but they are left up to you when designing your site. If you refer back to the pictures of Facebook, Amazon, and Github from earlier, we covered where your eyes are naturally drawn to, but skipped over why our eyes are drawn there, or more specifically why those elements were placed there, containing the information that they contain. Was it an accident? Pure happenstance? Of course not! As developers nothing happens on accident! Those elements were placed there, using those specific colors to establish the flow of the webpage. On Amazon, your eyes are immediately drawn to the deals, and Github pulls you right to the sign-up form. There is no guessing what's going on when you get to the page. No scanning looking for a sign-up button and no wondering how to find products on Amazon. These things are designed to take the guess work out for you, putting you exactly where they want you to be on the page. Amazon may have an entire design and psychology team deciding how to increase sales off the home page alone, but the concept still remains the same. Use thoughtful layouts to gently guide your users along to the information you want to show them, and they came to see.

Styling - Sweat the small stuff

Styling in this regard is using shapes, colors, and sizes to create your own design language. These are the small pieces that bring the site together and give it personality, and theme making it a product you can sell people on. Making all these 1's and 0's into something tangible people want to feel. This is the section that really brings consistency together. The styling we are talking about here is making everything on the page look the same on every page!
Every feature should be styled the same. Every item show page should have the same attributes displayed in the same manner! Every logo should bring you back the home page! Users love predictability and are frustrated by changes to convention. Underlined text is traditionally clickable. If you underline a username at the top of an Instagram profile, people click on it, and it does nothing, you're going to have a lot of frustrated Instagrammers. This is literal predicability. Predicting things by the convention for which they were created. Just as underlined text represents a link, a submit button is clearly used to send your information to a server, and the back button brings the user back to the previous page. If the back button always brings you to the home page... frustrating. But these are easy rules to adhere to because we use them all the time and the browser actually handles most of them for us. Implied predictability is where we come in. This is creating clickable images to make them larger, logos that redirect to the home page, and clicking a username to see the user profile. There is no text anywhere stating these rules exist, but they tie in directly with your layout to enhance the flow of your website. The best way to build this is simply by using your site, and noticing the shortcuts you want to take. When you build the shortcut however really stop and think if this is a conventional action that a user would be aware to try. If not, you may want to lend a little guidance, and maybe set the color of your text to a different font color to represent a link.

Clean and clear websites benefits everyone. Your users will thank you, job recruiters will be impressed, and even your grandma can check out your site out if you follow these guidelines. Now that you have a better conceptual understanding of design, tune in next week as I dive into the CSS to help make your sites more consistent.

Hacking 101

SpencerLindemuth — Wed, 24 Jul 2019 01:02:33 +0000

What does it actually mean to be a hacker?

Well here's a clip of a dark web hacker in action:

Hacking is clearly the precise combination of finding the right ski-mask, and clever use of your banana hand. The people behind the Equifax data breach in 2017 penetrated the firewall by using a technique called multi-port exploitation where they cleverly used a whole buschel of bananas to target numerous ports at once.

All jokes aside, the Equifax breach, which leaked the names, social security numbers, addresses, birth dates, and driver's license numbers of over 145 million Americans alone, was carried out by exploiting a flaw in Apache Struts, bad encryption techniques by Equifax, and insufficient breach detection mechanisms. So is this what hacking is? Finding flaws in systems, and exploiting them using advanced programming techniques? It certainly can be! While those are a lot of buzz words we hear on tv about hacking, it can also be a plethora of other things! It really boils down to the age old question... Is posting to your friends facebook feed while they use the bathroom hacking?

Hacking is defined as: "The gaining of unauthorized access to data in a system or computer".

By definition this means that posting on your friend's account is hacking! Wow! That means we are all hackers! So with this newfound knowledge about ourselves, it should be pretty easy to steal some data from one of the worlds largest credit reporting agencies! We just have to wait for the system administrator to get up to use the bathroom! While this may sound facetious and far-fetched, it brings us to most unknown hacking technique:

Social Engineering

Social engineering is: The use of deception to manipulate individuals into divulging confidential or personal information that may be used for fraudulent purposes. That sounds really vague, so let's break it down into a couple examples.

Phishing:

Phishing is the use of deceptive websites and emails to coerce personal information out of people to gain unauthorized access to their accounts.

If we dig a little deeper into this email we gain some insight on just what phishing is. First we notice that the address we received this email from is close to wellsfargo.com but snuck an extra 's' in there to try and get the recipients to glaze over it without a second glance. Next we have an embedded hyperlink with the text: "wellsfargo.com/account", but if you hover over the link, you see that it actually links to "http://www.some-sketchy-site-that-looks-like-wells-fargo.com". A good phisher will send you to a site that looks exactly like the target sites login page, then after you type in your credentials in an input field, log them in plain text and tell the user there was an error logging in, to get even more password variations out of the user, or redirect to actual target site, and high five themselves for successfully stealing information. Next we see a phone number for a customer service line. Well if we are being smart about our security we will call the customer service line just to make sure this email is legit! So we pick up our landline and dial the number here on the screen, and get a very nice voice on the other end of the line, who is almost too eager to have us verify some account information, before telling us the link is indeed legit! Now you feel safer! Now you've given enough information to the hacker to gain access to your bank... And probably all your social media accounts... And your email... And your work email... And your work computer... And now this is a full blown corporate attack.

Front-door social engineering:

Front-door social engineering is spoofing RFID tags, following people through doors, and onto elevators or pretending to be someone else to gain access to a system illegitimately. There's a famous saying,

"If you have a clipboard and a safety vest, you can walk in anywhere"

The same thing goes for I.T. people, and system administrators, and janitors, and anyone that works in a corporate office really. Someone wearing a white button up and a tie, could walk into a corporate office and say, "Did someone on this floor open an I.T. ticket?" Someone raises their hand, then the imposter comments, "This might take a few minutes if you want to go grab a coffee." Now this imposter is working unsupervised on a workstation copying user-data and emails to a flash drive. This sounds far fetched but it's a surprisingly common methods of "hacking". EY’s Global Information Security Survey 2017 found 74% of cyber attack sources are careless or unaware employees. [1] This is an exploit of a system, but not one that reads 1's and 0's and communicates over ethernet. This is the exploitation of people and their central nervous system. People are desperate to please, help, and avoid consequences, and hackers exploit this daily, because it's much easier than filtering through millions of lines of code on the internet to find a hole.

Cyber attacks

Don't fear! This isn't one of those articles where I lure you in with a topic like hacking and then tell you about how it isn't what you think it is, thus leaving you high and dry. There is still a large amount of cyber attacks carried out on a daily basis. This is hacking in a more traditional sense. This is the person in an abandoned warehouse surrounded by servers with 9 monitors in a grid suspended in the air, typing in a bash terminal that you see in the movies. Hacking in this sense, when broken down into smaller bits, is pretty simple and straightforward, although the techniques are not. To put it in layman's terms, hacking in this sense is finding an error in some code, and using it to gain unauthorized access to data or execute code on a remote machine. This is also a vague description, so let's break it down.

Remote Code Execution

Remote code execution is every hackers dream. A hacker finds a way to send code to a machine, which runs the code, returning information, or opening up doors for bigger exploitations. A good example is the 2015 Android Stagefright media server exploit, or the 2014 Shellshock hack which is described as "causing Bash to unintentionally execute commands when the commands are concatenated to the end of function definitions stored in the values of environment variables." The technical explanation is when Bash opens a new instance, it reads a list of predefined functions in a table referred to as environment variables, and executes them without verifying they were created legitimately. This was exploited in many different vectors, such as open SSH and via DHCP requests, where a hacker could append specialized privilege escalation functions onto a request to the server that would open bash to execute the initial command, not verify the appended code, and run all the commands haphazardly.

Code Injection

Code injection is the exploitation of a computer bug that is caused by processing invalid data and is part remote code execution and part system manipulation. This is the categories that script kiddies fall into and lands high on the list of most common attacks. Code injection canvases SQL injection, scripting, and packet spoofing. This is the kind of hacking that takes advantage of poorly written code, and lack of input validation. An example is the 2012 Heartbleed attack, that was eventually patched with just one line of code! The Heartbleed attack was an exploit carried out against the Open SSL protocol being used to encrypt web traffic across the world. To verify the SSL connection was still open, the web browser would send a "heartbeat" packet to the browser, which would then respond with the size and message of the original packet, but the server wouldn't verify wether the packet it was sending back was the same size as the original, instead rendering memory overflow data. A simplified explanation:

This exploit was fixed by this single line of code (or 56 characters for the curious):

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0;

That line isn't hard for even a beginner to read and understand, yet the effect radius of the exploit will forever be unknown.

This brings us to Spencer's top tips for avoiding getting hacked or fired for being "careless and unaware":

1:

Always lock your computers when you walk away from them! This seems obvious, but is more common than it should be! It's simple.

(⊞ Win + L) on PC, or (⌘ Command + ^ Control + Q) on mac.

Don't get data jacked while you're getting caffeine jacked!

2:

This may be a hard realty to take in.. But NO... That Nigerian Prince does NOT want to share his fortune with you. Things in life that sound too good to be true almost always are. Especially when they are communicated over email! No one will send you an email telling you how much money you've just won, or about an all expenses paid cruise for 2 that you got so lucky to be selected for! Look at Publishing Clearing House! They at least have the decency to show up to your front door with a giant check! Banks and other institutions DO NOT communicate private account information over email either. They may send you an information update verification to alert you if someone is tampering with your account, but they will not ask for any change to your personal information, or account verification over email to avoid this exact scenario. When in doubt, call your bank from the number on google, or in the yellow pages if you are still on AOL.

3:

Use a password manager! There are tons available for tons of different price points. (Again here, you get what you pay for. You might not think it's important, but would you buy your car from Wal-Mart or your prescription meds 7-11 brand? Don't be cheap with your security!)
Google has a password manager built into their programs now, iCloud has Keychain, and well-known third managers include Keeper, LastPass, and DashLane. They can help you generate long, unique passwords for every account, while never forgetting or typing one again thanks to autofill, and also protecting you from bruteforce attacks, or plain and simple weak password techniques like hunter12 (although all I see is ********). Even a super-computer will have a hard time guessing:

LdjgfdksjhgJDLRKJZSKLFJKL:hjt4io4wr8iro1euwrewpt8o43tuO*U$#*OU$O#I$J#_E)(R#$%*UEOIJDKLGSJDKFAJSDGFKJHFGUYT*U(RU#)$IU#(ru30tujsdklgjdkgjfskgjeoir#UR5q9oRU

(I would have guessed Passw0rd first, but that string would have been my second guess)

3:

Number three sucks. It's a tip that isn't really a tip, but maybe something to turn some gears in your mind to help deal with the inevitable reality. Sometimes you just can't avoid attacks. The identities compromised in the Equifax breach were unavoidable by the people actually effected. Equifax was collecting your information with the "consent" you gave by being born, or signing up for that low limit/high interest credit card at 18 so you could get 5% off at Macy's and buy cigarettes without your parents finding out. The tip here is BE READY when your information is leaked. Put a credit freeze on your account to prevent criminals from opening lines of credit under your name. Change your passwords. Enable 2 step verification for all of your accounts. Even accounts like your Snapchat, Instagram, and iCloud are still tied to other accounts, can provide verification for important accounts, or leak things to public you didn't want getting out.

It's a scary, hacked-together world out there... Don't get caught with your naughty pics on a Reddit thread, or the FBI going through your work computer at the Department of Labor because your computer gave hackers access to sensitive Department of energy nuclear data.

Don't be me. Be a better pair-programming partner.

SpencerLindemuth — Mon, 01 Jul 2019 22:13:35 +0000

Recently we were assigned our requirements for our first free-form pair programming project at school. Harkening back to elementary school, the mystery of who you'll be paired with burning inside you. Hoping... Or very much hoping not to be paired with the people around you. However unlike elementary school, you hardly know these people. You've only been here 2 weeks, and everyone is overwhelmed with the work, and it's still early and the skill level remains at a huge discrepancy. You start thinking, "I've been programming since freshman year in twenty ten, and have written more basic CLI apps than I can count, this is going to be a cake walk" but you don't know who around you has the same level of experience, and I didn't know it at the time but this way of thinking is the first step to becoming a bad pair programming partner. Tip number 1 for better pair programming is to tie up to a hitching post and take a break from the ride on your high horse.

Since this project seemed so nominal from the start, and "I'm such a good programmer", I spent a lot of time thinking about what I wanted to accomplish in this dedicated week. I found a great API for real time stock market info that lined up perfectly with an app idea that I had been tossing around building in my free time. With this new-found API and energy I present the idea to my partner and they were on board! Perfect! Now the ideas really start swirling around in my brain. "What should I start on first? What gem am I going to use to put this data in a table? What's the lifecycle of real-time stock market data in our program? What do I actually need out of this .JSON?"... and never thought for a second what kind of thoughts might be running through my partners head. "What the hell is a stock? An ETF? Why would someone want to see a companies 5 year stock history?". At this point I had already written 300 lines of imaginary code in my head without a second to think about what was happening in my partners. Tip number 2 for better pair programming is to realize that you have to share a vision to equally contribute to a project. No one is going to be enthusiastic to help with something they are constantly googling about along the way.

After two days of furious coding it's time to start hooking their UI to my back-end hooks, and (to no-one's) surprise! Their vision of what my pet project should look like is different than mine! (gasp).

"Don't worry, I can fix this! I'll stay late today and make some quote, unquote *subtle* changes." There's that pesky "bad partner" voice again. Tip number 3 to better pairing is acceptance. Riding right off the back of tip number 2, tip number 3 means you have to let it go. If you make the program look exactly how you want, do exactly what you want, and the whole concept is about exactly what you want, why do you even have a partner? Acceptance of your partners vision is only half the battle too. Everyone is different. Everyone's eyes are different, their fingerprints are different, their handwriting is different, and their coding style is different. To truly accept your pair partner (and life partner, but that's a different blog) is to appreciate the way they do things differently. Maybe they like if/else statements better than case statements, or they prefer .atom to VSCode like you, but maybe they've used a gem that makes that table you've been trying to format for 16 hours.

Pair programming is meant to create to a result that is the expression of both parties involved, which inherently make is better suited to tackle a task because it has 100% more brain power behind it. Every change to the code might bring your vision up 1% or 2% but the capability of the program drops 5% or 10%. Tip number 4 is, don't be afraid to express yourself. You are great! Give the world what you have to offer! But so is your partner! Don't block the shine of the person shining next to you, because you know it wouldn't feel great if they were the one holding the umbrella.

Let's review:

Be humble - Smart today doesn't mean smart tomorrow.
Share a vision - Working towards a common goal is better than building someone else's.
Acceptance - You are as different to them, as they are to you.
Collaborate - If you had every great idea, why are you sitting here reading my blog?

The most important tip is learn something! If you don't come out of a pair project feeling like you've learned something about coding and yourself, you are living all wrong.

“If you’re the smartest person in the room, you’re in the wrong room.”