DEV Community: Zachary Izdepski

Generators in JS

Zachary Izdepski — Wed, 16 Mar 2022 23:18:58 +0000

It's been some time since ES6 first came out in 2015, and it feels like even longer when we consider the speed at which tech evolves. At this point, using key ES6 features such as arrow functions, let/const variable declaration, the spread operator as well as many more useful additions have become the norm for most javascript developers. But nestled amongst the more commonly known ES6 syntax is a less well-known and less understood feature: the generator function. So, in this blog post, I will walk through exactly what a generator is and provide some examples of how it can be used.

At its core, a generator is a function that returns a generator object. This generator object has a few built in methods that allow it to behave in ways that are unique in javascript. These include next, return and throw. Here is the syntax for creating a basic generator object:

function* basicGenerator() {
  yield 'first value';
  yield 'second value';
  yield 'third value';
}
const genObj = basicGenerator();

The above genObj is a generator object that is one instance of a generator. Instead of using the return keyword, generators use yield to return objects that contain a value and a done property which evaluates to a boolean. To initiate a generator, we can call the next function. Every time next is called, the next operation is run and another value is yielded. When all next functions have been called, the done property flips from false to true.

console.log(genObj.next()); // -> {value: 'first value', done: false}
console.log(genObj.next()); // -> {value: 'second value', done: false}
console.log(genObj.next()); // -> {value: 'third value', done: true}

The utility of a generator may not be immediately apparent, but if we consider that the context is saved between each next function call, we can start to imagine writing asynchronous code this way, as well as use them as iterators. Generators all but completely eliminate the need for callbacks and in doing so are a way to avoid callback hell. They can also be used to create controlled infinite loops, or open-ended processes that won't cause your computer to crash since the generator "pauses" after every next call. Consider the following example:

function* infiniteIDs() {
  let id = 0;

  while (true) {
    const increment = yield id;
    if (increment !== null) {
      id += increment;
    } else {
      id++;
    }
  }
}

const IDGenerator = infiniteID();

console.log(IDGenerator.next());// -> {value: 0, done: false}
console.log(IDGenerator.next(4));// {value: 4, done: false}
console.log(IDGenerator.next());// {value: NaN, done: false}

In the above code snippet we create a generator that generates a new id every time next is run, which could be run ad infinitum since we have set a condition in our while loop to always be true. On the first next call, the generator yields 0. On the second call, we pass in a value to next that gets returned in the yield, so 4 is yielded. On the third call nothing is passed in to next so NaN is yielded since we didn't provide an increment. To reset the generator we could simply create a new instance of one by setting another variable equal to our generator function and give it whatever starting values we want. One important thing to note is that nothing would happen to the value of id if we passed a value to next on the first call since there is no yield yet to pass a value to. Now let's take a look at the return and throw methods.

Let's say we don't know how many ids we want to create so we're ok with the open-ended nature of our IDGenerator but we do want to break out of it under certain conditions or if an error is thrown. To break out of a generator we can call return and optionally pass it a value to be immediately returned and set the done property to true.

console.log(IDGenerator.return(6)); -> {value: 6, done: true}
console.log(IDGenerator.throw(new Error("invalid input"))) -> Error: invalid input

And that's about it! Happy coding!

Move over, Postman!

Zachary Izdepski — Mon, 14 Mar 2022 02:27:38 +0000

I was pair programming with a friend a few weeks ago when the disparity between our experience levels (he's been an engineer for several years, I'm graduating a bootcamp) inevitably reared its head in the form of some light ribbing between old friends; "Why don't you break out your terminal in another window? I can't stand this little window thing you got going.", he said. I replied "I like to keep my tools on hand, and sometimes you need to see the terminal in VS Code while other windows are occupied." This dialogue is hardly unique to the software development field. No matter the vocation, it is in our human nature to develop preferences and a need to shape the environments we work in. Some prefer to have their apps sequestered from their primary workspaces. Some prefer them integrated. I decidedly fall in the latter category, and as such I have taken a liking to a neat VS Code extension (available starting with versions 1.57 and later) that came our last summer - Thunder Client.

I'll get one thing out of the way - Thunder Client isn't necessary. It doesn't really do anything that Postman can't, and in fact can't do certain things that Postman can, like proxy configuration or creating variable scripts. But while it has some limitations, the most frequent use cases are fully intact, and the lightweight design makes testing apis less of a chore. Additionally, the minimal design is intuitive and favors the most common use cases. As a relative newcomer to the tech industry, I appreciate approaching apps in a simple and straightforward way. I'm far more likely to test an api endpoint than I am a mock server, after all. So, without further ado, let's take a closer look at the design and features.

If you want to install it, begin by clicking the extensions icon in VS Code and search for "Thunder Client".

You'll need to restart VS Code to complete the install, and then you'll be greeted with a welcome page detailing the extension.

Right off the bat, you'll notice that Thunder Client adopts your VS Code theme choices to seamlessly integrate into the app. Featured prominently on the left is the New Request button that opens up a tab to display the request field, which is initially populated with a test endpoint. Pass in a parameter and a value and you'll get a welcome response on the right.

As for the primary features, all major HTTP requests can be sent (GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD). Query parameters can also be added. If you add keys and values in the URL, they automatically populate the query parameters fields. There is an auth section where you can add add Basic Auth, OAuth2.0, Ntlm, Aws, and Bearer Token. A section for adding HTTP headers as keys and values is also available. Data can be sent using JSON, XML, text, form, form-encoded, graphql and binary in the body section. The last section beneath the request bar is where we can add conditions for testing. For example, we can check for a particular response code or a particular value in the response body. In the response section we have four tabs where we can look at the Response (nicely marked up in green for "OK" status), Headers, Cookies, and Test Results. On the far right there is an object literal ( {} ) that you can use to view and copy code snippets. On the far left, you can see the Activity, Collections and Env tabs, all of which can be filtered. You can save requests to collections, duplicate them, rename them or delete. Postman collections and environments can also be imported.

In sum, if you're like me and enjoy a workspace that is focused, consistent and straight to the point, Thunder Client is a great extension for you. Happy coding!

An introduction to Scala

Zachary Izdepski — Sun, 27 Feb 2022 00:53:47 +0000

Software development is an industry that is defined by rapid change, be it new tech, revived trends or an old idea that finally catches on to the mainstream. Scala may soon be an example of the latter of these. From the growing demand for typescript proficiency to smarter API handling with GraphQL, stronger typed technologies appear to be finding their way into historically less opinionated spaces. As a javascript developer who is currently learning typescript, I am interested in delving into other typed tech and landed on Scala, a language that was conceived of the criticisms of its predecessor, Java. So, in this blog I will briefly walk the reader through the basics of Scala and maybe provide some insight into what mainstream development could look like in the near future.

To begin we start by taking a look at how Scala deals with variables. Scala is an object-oriented language in that every value is an object, which means that every value can have a type. These types belong to a hierarchy, with the supertype "Any" at the top level. Any is used to define some universal methods that can apply to any value, such as toString or equals. The diagram below describes the shape of the hierarchy:

We see above that the Any superclass has two immediate subclasses, AnyVal and AnyRef. In terms of javascript, we can think of the AnyVal class as simple data types and AnyRef as complex data types. AnyVal types are non-nullable and the Unit type is essentially a placeholder that can be returned from a function since all functions in Scala require some kind of return value. All non-value types are AnyRef types as well as any user-defined type. At the bottom of the hierarchy we have the "Nothing" type and Null. Nothing is a subtype of all types and has no value. It is typically used to signal that an expression will not yield a value or a method will not return normally. Null is a subtype of all reference types and has the literal value of the keyword "null". Null is available in Scala as a way to work with Java code since Java does not have a Nothing subtype, and as such should not be used.

Creating objects in Scala is done by defining classes that serve as a blueprint for object creation. Class names are capitalized and are instantiated with the keyword "new". Classes can contain values, objects, traits, variables, methods and other classes. Each of these properties defined on a class are called "members" of the class. Consider the below code:

class Person(var name: String, var age: Int) {

  def talk(words : String){ //Return type is a string
    println(words)
}
# use the class
val zack = new Person("Zack", 35)
zack.name                        // "Zack"
zack.age                         // 35
zack.talk("Hello there!")        // "Hello there!"

Here we have defined a class called Person that has three members: name, age and a method called talk. The variables are declared with the "var" keyword and are mutable. Had they been declared with the "val" keyword their value would not be able to be changed, similar to the const keyword in javascript. The talk method is a function that we declare with the "def" keyword and simply prints a line of text with the built in "println" method. Each member in the class has its values defined when they are declared and the method has its return value similarly defined beforehand.

In sum, Java is a language that is strongly typed, and while Scala is also typed, its more flexible and hints toward an industry-wide shift toward the middle of the opinionated-unopinionated programming language spectrum. This shift is powered by a desire for code that is both expressive and less prone to bugs. One needs not be sacrifice for the other, and a future looms where the conversations surrounding what language works best in certain environments is going to get more nuanced. Why would we want it any other way?

Intro to GraphQL

Zachary Izdepski — Wed, 16 Feb 2022 08:05:57 +0000

In order to get data to use in our applications, we typically need to request it from an API via an endpoint that returns a dataset in a particular format, such as json or xml. We've grown so accustomed to the restful api format that it has become second nature, or simply the way that apis are supposed to work. But because we're developers and because paradigms in this industry are always changing, we will see in this blog post how GraphQL makes fetching data a more efficient and data-rich process.

So what is GraphQL? In brief, GraphQL is a query language for APIs that was designed by Facebook. The purpose of GraphQL is to prioritize getting the data that the client wants and expects. It helps solve the issue of overfetching and underfetching data. Overfetching is having to handle lots of unwanted and unnecessary data that comes from an API when we make a query while underfetching is having to fetch data from multiple endpoints in order to accrue the data we need to satisfy the client's needs. Consider the example scenario where we want an NBA player's average points scored against a certain opponent on their court. We have some relational data that we need and likely will have to hit multiple endpoints in order to get the specific data that we want, and we'll definitely get a lot of data we don't. GraphQL allows us to make smart queries we define from just one endpoint so we can reduce our calls to APIs, making our functionality both faster and cheaper, particularly at scale. Now that we know the purpose of GraphQL and the general problems it was built to solve, let's dive in to how we should approach using it.

The best place to start learning GraphQL is taking a good look at the language specification, or spec for short. A spec is a technical document that describes what a programming language is capable of and used for. It defines guidelines for designing schemas, drafting queries and other rules for using the language. As a spec we don't need to worry about what programming language is used in conjunction with GraphQL. It supports pretty much all of them. The queries themselves are an object syntax and the shape of the data returned is reflected in that. Queries can take arguments, use aliases, accept type definitions, pass variables to make queries dynamic and more. A notable quality of GraphQL is that it is a typed language. This adds specificity to queries and helps ensure data quality and predictability, leading to fewer bugs in our code. A type can be defined as anything we want from the API. Going back to our NBA player example, we could define a type as follows:

const typeDef = gql
  type Player {
   name: String!
   avgPoints: Int!
   awayGame: Boolean!
}

This type definition is a model of exactly the data we want to extract from an API call and can also be used to create queries. The gql and type keywords are GraphQL syntax, as is the capitalization of the datatypes. The exclamation mark denotes required values. Each of these type definitions would need to be exported and used in some kind of server middleware, the most popular being Apollo.

const { ApolloServer } = require('apollo-server-express');
const express = require('express');
const app = express();

const app = express();
const server = new ApolloServer({ typeDef });

server.applyMiddleware({ app });

app.listen({ port: 8001 }, () => {
 console.log(listening on port 8001});

The above example is a basic setup for using an apollo server with express. We pass in the typeDef to a new instance of an apollo server that gets applied to the express server. This means that our server now has a definition for an object that we will return from an API call. This is just the small part of how to implement GraphQL, but the point stands that with it we can easily determine the shape and content of data from API requests. A point of note is that not all projects would experience the benefit of using GraphQL, but for applications that need a lot of data assembly and make a lot of API requests it can be a really powerful option.

Microservices, Kubernetes and Docker

Zachary Izdepski — Tue, 08 Feb 2022 23:18:41 +0000

Just a few days ago I had some issues with an EC2 instance. I'm pretty new to the development field, and as such I fumbled through inbound rules and playing with the VIM editor to cobble together an environment file and ran up against permission and dependency disparities between my little macbook air and the instance I was just getting acquainted with. I eventually weeded out the bugs, got things running, and vowed to explore other solutions to my deployment woes for the next go around. It just seemed like there was so much that could go wrong with configuring an instance up close that there must have been advancements in that area. I'd heard of other services like Heroku, Elastic Beanstalk and Digital Ocean, but what really grabbed my attention was the rapid rise in the demand for and utilization of microservices, particularly Docker with Kubernetes. So, in this blog I'd like to explore what those are and how they have launched us deeper into the world of the virtual cloud.

To begin, we need to understand the basic purpose of Docker, the problems it solves as well as some vocabulary. Imagine this common scenario; you've built your app, it runs great, and you send it off to be tested. You get an email a day later saying there are several bugs in the app and it is not ready to be deployed on the market. Perplexed, and maybe a little frustrated, you respond with "Well, I have no issues at my end. It must be an issue with your machine!". There are so many variables involved in running a large application in a foreign environment that issues are commonplace. Docker solves this problem by creating an "image" of your environment, which is essentially an instance of your os and app bundled with all of its dependencies. This bundling creates something called a container can be run on any computer anywhere as long as it is run with Docker. What goes into the container is defined in a Dockerfile that can be written in json or yml format, the latter being recommended for readability. The container instance will have everything it needs to run like it is on your own machine, controlling for all those pesky variables and delivering a product that is air tight right out of development. But that is just the beginning of what Docker can accomplish. These containers are replicable, and as such ready to handle variable workloads. This can be accomplished with the Docker Daemon, but it has also become popular to use Kubernetes.

A common misconception about Docker containers is that they are virtual machines (VMs), which is untrue because virtual machines run on their own os while a container uses a shared os. This has the advantage of sharing bins and libraries between containers, which prevents redundancies and saves space. in the same vein, Kubernetes offers an architecture that prioritizes efficiency. It is an open source container orchestration tool, meaning it does what it sounds like - orchestrating the number and location of containers. A Kubernete cluster utilizes a single control plane to manage nodes, which are worker machines that can be either virtual or physical. Each node has pods that can contain a number of containers. The Kubernete control plane controls the scheduling of pod deployment through a Replication controller that contains a history of deployments and can scale them up or down. If a container fails, another one can take its place until the failed container comes back online. The same is true for a pod.

Cloud based computing has come a long way in the last several years, and while there are some disadvantages to decentralized deployment services, such as higher complexity and tougher troubleshooting, it is clear that the pros far outweigh the cons. When used at scale, it's easy to see why more and more companies are interested in investing in cloud tech, with the understanding that sometimes harder is better.

Getting started with ElectronJS

Zachary Izdepski — Thu, 06 Jan 2022 10:30:51 +0000

In today's web development landscape, there has never been so many frameworks and libraries to choose from. And while many of them have been engineered to be best suited for particular fields of web development, they all generally share the quality of being easier to work with and more intuitive than their predecessors. No framework exemplifies this more than ElectronJS. ElectronJS is a cross platform framework that is used to develop desktop applications with only javascript, css and html. In this article, we'll walk through how to build a barebones Electron desktop app step by step, and learn about some of the key features along the way.

To begin, we'll start by doing some set up in the terminal command line by making a directory mkdir <your_directory_name> and cd-ing into it with
cd <your_directory_name>. Next, we'll add a package.json by running npm init. At this point you will be prompted to fill in some options. Many of these are optional, but it is good practice to be as detailed about your projects as possible and there are some common conventions to consider. So, go ahead and give your app a name, description, set the entry point to main.js (an Electron convention), author it with your name, and when prompted is this OK? say yes, or simply type "y". Then, add the folder to your workspace so we can add some more contents. Next, we'll install Electron both globally and locally. To install globally, type npm install -g electron into the command line. To install locally, type npm install electron --save. Installing locally will place a node modules folder into your directory along with a package-lock.json file. Lastly, we'll create three files: index.html, main.js, and renderer.js.

Now that the initial workspace is complete, we'll move on to the code that we need in main.js. Take a look below, then read for an explanation of what it is doing.

main.js

const { app, BrowserWindow } = require('electron');
const path = require('path');
const url = require('url');

let win;

function createWindow() {
  win = new BrowserWindow({ width: 800, height: 600 });

  win.loadURL(
    url.format({
      pathname: path.join(__dirname, 'index.html'),
      protocol: 'file',
      slashes: true,
    })
  );

  win.webContents.openDevTools();

  win.on('closed', () => {
    win = null;
  });

  app.on('ready', createWindow);

  app.on('window-all-closed', () => {
    if (process.platform !== 'darwin') {
      app.quit();
    }
  });
}

The main.js file begins with us requiring a few modules that come with the Electron package. app contains functionality pertaining to our app and BrowserWindow is a class that creates an instance of a browser window that houses our application. path has some nice methods for handling filepaths and url will allow us to load our index.html file. We then declare win, a shorthand for window, that is assigned to a new browser window in the createWindow function which itself takes in an object of options for the window being created. We're only specifying width and height, but other options, such as images, can also be added here. Next, we load our url with win.loadURL which creates a path to our index.html file. win.webContents.openDevTools gives our applications its dev tools so we can inspect or debug the application just the same as if it were in a web browser. Our last window function sets win to null when the window is closed. Lastly, we have two app functions, one for calling createWindow when the app is opened and one that runs app.quit when all the windows are closed. That concludes the main.js file. Now we take a look at our index.html:

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <link rel="stylesheet" href="<some_styling_template_url" />
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Your App Name</title>
  </head>
  <body>
    <h1>My Desktop App</h1>
  </body>
  <script>
    require('renderer.js');
  </script>
</html>

The index.html file is mostly boiler plate, but Electron requires that we have a renderer.js file that runs when the window renders and also makes Node.js apis available in the process.

The final piece of the puzzle is a small change we need to make to our package.json file. By default, we'll have a test script that we won't need that we will replace with "start": "electron .". Now all you need to do to start your little desktop app is type npm start into the command line and explore the application!

Content Delivery Networks and Caching

Zachary Izdepski — Tue, 21 Dec 2021 14:47:40 +0000

So you've just launched your shiny new app and are ready for hoards of curious potential customers to start bombarding you with requests for your new services. You keep a close eye on the traffic and are pleased that things seem to be working fine with no crashes or bugs reported. But within a few hours of going live you begin to notice a disturbing trend - people are leaving your site shortly after arrival. What's worse, they're leaving without delving into all the features you painstakingly came up with! So, you hop on your own app and try to see what your quickly dwindling users are seeing and are mortified when you have to wait 3 seconds (an eternity in the web development world) for a server request to complete. You have latency issues and your users are moving on as a result.

Those of us who grew up in the early days of the web know how much faster web applications have become over the years. We've never had it so good, and you can't help but notice, or even be a little frustrated by, websites and apps that don't respond in the blink of an eye. We can actually measure this impatience we have become accustomed to with something called Bounce Rate, or simply the percentage of users who exit, or "bounce" from a site or app before moving on to the next page or using features. The average bounce rate for fast applications (loading times of less than 400milliseconds) sits at around 7%. For loading times of 3 seconds or more the bounce rate jumps up to around 22%, which is quite significant. So what can you do to speed things up? These days we have fiber optic cables that have boosted the speeds and bandwidth that many ISPs offer, but even fiber optics have limitations. Even though fiber optics utilize speedy light signals, latency issues can still arise over long distances due to the fact that the light in the cables does not follow the fastest path from end to end. This is because the light bounces along the glass wire in a zigzag fashion. Add to that the frequent need for several call/response cycles to your server or database and all of a sudden the milliseconds it takes for your users in Sacramento to reach a server in Amsterdam are really adding up. This is one of the many issues that using a Content Delivery Network (CDN) can solve.

CDNs use a geographically distributed network of servers and databases to hold copies of data in order to keep it available to the user closer to where they are. They achieve this through the use of Reverse Proxy servers and data Caching. As the name suggests, a Reverse Proxy server is essentially the opposite of a proxy server in that the user, or client, is agnostic of what server is in use rather than the server being agnostic of the user. This allows for the Load Balancing of server traffic since the network decides what servers should fulfill a given request based on data traffic and availability. This "deciding" of where to grab the requested data is called Received Package Steering (RPS), where requests for particular bits of data are tracked and "steered" to the appropriate server to optimize efficiency and reduce latency.

Another integral aspect of a CDN is how data is cached in the servers. CDNs all have some kind of Cache Policy to determine what data gets cached and for how long. The most common policy is the Least Recently Used (LRU) policy where data is evicted from the server after a predetermined amount of time since it was last requested. This policy saves the application owner on the cost of the server because it does not need to be as large as a database. This is an important consideration because CDN servers typically use Solid State Drives (SSDs), which are more expensive than the hard drives used in a typical database. With this in mind, it is important to get a server that is not so large as to be too expensive, but also not so small that evicted data is frequently re-cached. This means unnecessary calls to the database that defeats the purpose of a CDN in the first place. Another advantage of using a CDN is a sort of build-in side effect of the network structure itself; if traffic is load balanced, DDOS attacks are likely to be rendered ineffective.

In sum, CDNs offer speed, data availability, security and scalability, all of which are essential for developers who are bringing their innovations to a competitive market. However, not all data are equal, and not all data are cacheable. CDNs are mostly meant to cache non-essential, transient types of data such as user profiles, videos, images and other static data types. More critical data, such as medical records, banking information and passwords, cannot be cached in a CDN and must be stored in a more permanent database.

A beginners guide to the terminal and z-shell

Zachary Izdepski — Mon, 13 Dec 2021 14:56:39 +0000

The relationships between the levels of a computer can be thought of in terms of layers, the computer itself being the hardware, the Kernel being a largely inaccessible program without a user interface that handles the very basic functions necessary for the operating system to, well, operate, and a terminal that allows the user to actually communicate with the computer. Subsequent "layers" are where we start to interact with our computers in more nuanced and specific ways, and this is really where the term "shell" gains more meaning.

So what exactly is a shell? At the most basic level, a shell is a user interface that allows the user to interact with the computer in a more human friendly way. You can think of a shell as just another layer of interpretation, an interface that ‘wraps’ the commands you give to your operating system so you don’t need to be quite as verbose with your machine. There are two primary types of shells: Graphic User Interface (GUI) and Command Line Interface (CLI). GUI is the way in which most everyday people interact with their computers. It is an interface that is built to be specific to tasks and supports a more visually interactive user experience. An example would be a file directory. By contrast, a CLI is how developers interact with their machines. The CLI is a more wholistic way to communicate with your operating system in that it essentially consolidates interaction with your operating system into one place; the terminal.

Let's take a step back. What is a terminal? And is a CLI a terminal or is a terminal a CLI? This gets at a somewhat confusing characteristic of modern software development; the repetition of industry terminology and reliance upon understanding the context in which the terms are used as the industry evolves. With this in mind, I will say that the "terminal" is typically referred to as a CLI, or even THE CLI, and is a place where we can interact with the hardware of our computer in an environment largely stripped of software. In the early days of computers, a terminal was an actual keyboard and monitor connected to a large computer in a server room. It was THE way in which early software developers had to communicate with a computer. Nowadays we utilize an electronic terminal, one that is much more integrated into our machines and far more powerful. In the terminal you can run code, execute files, start servers and download and install tools all in one place.

So what then is the z shell? In 2019, Apple replaced the born again shell (bash) with the z shell (zsh). Many of the features of bash, tcsh, and ksh were incorporated into zsh since it is really just an updated version of previous unix-like system shells. Zsh can be used for in line completion features, natively supports unicode, can get paths to binaries, and offers customized CLIs, built-ins and plugins. All of this is supported by a community of developers whose main goal is to make life easier for other developers. For instance, zsh offers a reverse-search that allows you to search your command history across sessions. Now you can go back in time and see exactly what commands you ran in your app to make it break the last time you used the terminal in a previous session! There are also built-ins, which are basically subsets of shorthand commands that you can choose from depending on what kind of software development you are in. There are many more features in zsh that can be used to customize your terminal experience and make you a more efficient developer, but probably the best one is the open-sourced nature of the shell. Crowd source is the best source!

What's all the "Fuzz" about?

Zachary Izdepski — Thu, 28 Oct 2021 07:16:19 +0000

It's been 33 years since then University of Wisconsin Professor Barton Miller began fuzz testing software with his graduate students, and it would be an understatement to say both computer programs and the tools used to test them have advanced quite a bit. Long gone are the days when inputing purely random bits of code meant to induce crashes was the norm. These days nearly all software development companies are taking a more target-oriented and thorough approach to testing their products and services, and those who aren't are at a big disadvantage. In this post, I'll walk through the different fuzz testing methods and discuss how best to use them.

The first method I'll discuss is the earliest and most primitive and is known as Black Box testing. Black Box testing is a test where a program is subjected to random inputs to induce unpredictable behavior. It is an overall negative test (we wouldn't expect a chat app to regularly handle an input of 37 different special character username inputs, right?) and does not take valid or semi-valid inputs into account. This lack of focus in Black Box testing makes it fairly limited in its use, since nearly all test cases are immediately and easily discarded by the program. Additionally, reading the test results from randomized testing can be problematic and cumbersome. That said, at the outermost trust boundaries it can be viable for finding bugs in simple password barriers. It also does not require source code since it is a method that is utilized from outside of the program structure.

The next method is much more focused than Black Box and is called the Mutation Fuzz test. Mutation tests make an attempt at "tricking" the tested program by tweaking valid and semi-valid inputs. The test is "aware" of at least some of the program structure and uses existing inputs, called seeds, to creating thousands of minor variations of inputs that are deemed valid enough to not be immediately rejected by the program. This testing is not only effective at stressing edge cases and inducing strange behavior, but it also finds deeper bugs than more ham handed methods and is easy to set up and implement. It does have longer runtimes, however, which can be a big factor if testing is to be done at multiple stages of development.

The third fuzzing method I will discuss is the Generation
Fuzz method. As the name implies, Generation testing generates test with a template that is designed specifically for each trust boundary within the program. The advantages here are many; with specific tests we not only have shorter runtimes, we also have clearer results and there is an added level of context to the data we get back from the test results. Sometimes it is not only important to know what input caused a bug or crash, but under what conditions and at what point in within the program the event occurred. Generation testing also provides deeper code coverage and is generally reusable for regression testing as the program is updated. There is, of course, a simple downside to this method - expense.

The last method I will discuss is the Feedback Fuzzing method. Feedback tests are the latest in fuzzing software and involves combining the principles of Mutation testing with smart algorithms that measure code coverage as the test is run. The test then uses existing inputs and coverage data to "learn" about the structure of the program and how to effectively and efficiently stress possible vulnerabilities by slightly changing inputs. Feedback tests provide the highest degree of code coverage and exposes the deepest bugs, but runtimes can be pretty slow. It is also a tool that shouldn't be used at early stages of development since it would need to be updated frequently in tandem with program updates.

So there you have it, the four main Fuzzing methods. To date there is no one-size-fits-all fuzz test, and it is up to the developer to decide which one fits best at different stages of development. But one thing is clear; integrating fuzz testing into development is a must, especially for equipment and programs that have the highest standards of security, such as medical equipment or aircraft instrumentation. Furthermore, fuzz testing can be done my more than just software developers. Hackers and other bad actors are also using these techniques to exploit zero-day vulnerabilities so taking the same approach in an effort to the contrary is a worthwhile endeavor. And lastly, who really enjoys writing hundreds of test cases anyway?

What is Material UI?

Zachary Izdepski — Wed, 20 Oct 2021 08:12:04 +0000

I chose to write this post on Material UI for a very simple reason - I am new to software development and knew absolutely nothing about it. But while I didn't know what the Material UI library was or was used for, I had heard that it has grown in popularity over the years in tandem with React, and as a newcomer to the field I think it is best to get my feet wet by studying the languages and frameworks that are mainstays (for now, anyway) in the industry. So, without further ado, I will jump right in to where Material UI came from, what it is and why it is such a useful tool in front end development.

Google Headquarters

Material UI (MUI) is an open source user interface library that you can use in front end development with React. It was designed with Google's Material Design in 2014 and as such inherits the design concepts developed by Google software engineers to make front end development both easier and faster since developers do not need to build each part of their UIs from the ground up. The Material UI library gives you access to React components that are made with web design best practices in mind, such as common spacing and typography conventions, but are also highly customizable. Source code for components is readily available to make design changes as you see fit. Let's take a look at several primary MUI features and component types.

The features offered by MUI are centered around the core Material Design concept of Material Theming. Material Theming is the idea that we can customize things like typography, color palette, iconography and other elements specific to design needs. The MUI library gives access to Material Design color palettes that include shading of elements in primary and secondary color schemes. MUI also provides a React component object for typography that can be used anywhere in the user interface. Additionally, iconography is provided to add specification to typical user actions. The icons are available in SVG (Scalable Vector Graphic) format that is much cleaner than its raster counterpart. Components include things like navbars, sidebars, buttons, and checkboxes. All of these are animated to reflect different states to provide more nuanced user interactions.

There are also many other components that are available to fill any web application need, but the best feature is the idea that being able to easily import these objects directly into code makes life easier for developers. As languages and frameworks evolve, the common thread is an increase in elegance and modular application, which saves time, effort and provides the flexibility to focus more on the end user experience and less on the nitty gritty of how our application is running. In this regard MUI excels, and to many developers it just makes sense to keep building off of the efforts of those who walked so we could run.