DEV Community: dotbehrens

npm install scrum 2

dotbehrens — Fri, 13 Mar 2020 20:07:32 +0000

This is part two of my two part blog on scrum methodology.

Scrum Artifacts

Product Backlog

The Product Backlog is a log that consists of all of the work that needs to be done in a project. This work is split up into tasks and assigned to a sprint.

Sprint Backlog

The Sprint Backlog is a backlog of the work that needs to be done in a particular sprint. This backlog contains what needs to be done, what is in progress, what is in review, and what has been completed. This log is important because it is the way team members know what is going on in the project, and what needs to be done. This helps team members know where they fit into the plan and establishes trust and accountability for the team.

Increment

An Increment is a deliverable portion to the product produced at the end of the sprint. Though the whole product is not complete the sprint should produce a functioning piece of the product that can be demoed to the customer.

Scrum Events

All scrum events are time-boxed, meaning that they are supposed to occur in an allotted amount of time, with emphasis on efficiency and productivity.

Sprint

Sprints are typically timeboxed as 2 or 4 week projects that at completion produces an iterative or a functioning piece of the overall product.

Sprint Planning

Sprint Planning is the phase where the team plans and organizes the sprint and agrees upon a definition of done. As programming product are constantly being improved having a team standard as to what is the desired outcome is extremely important for productivity.

Daily Scrum

The daily scrum, also referred to as standup is a short, typically time-boxed at 15 minutes, meeting where the team shares what they have done, what they are now working on, and what is keeping them from getting their work done. As with all other scrum events the goal is to keep the team on the same page and enable them to work efficiently. This meeting is what I think of as "the meeting that could have been an email." However since it is better for moral to physically see that others are getting things done I do appreciate that the daily scrum is included in this methodology.

Sprint Review

A sprint review is held at the end of each sprint to inspect the increment of the product. This is also a change to adapt the product backlog for more accuracy and productivity. This meeting is timeboxed at about an hour per week spent working on the sprint.

Sprint Retrospective

A sprint retrospective takes place after the sprint review, but before the next sprints planning session. This event is time boxed at 3 hours for a one month sprint. /in retrospective the team discusses what went well in the sprint, what didn't go well in the sprint, and what the team is going to commit to changing in the upcoming sprint.

Repeat

When these events are over the next step is to start the process over until the product is complete.

Scrum is a fascinating methodology for project management. Certifications in are offered by scrum.org for someone to become a scrum master, or product owner. The agile development process is extremely useful in software development projects where goals may not always be clear or may be changing constantly. Being able to keep people on the same page is an important ability of any software development team.

npm install scrum

dotbehrens — Mon, 10 Feb 2020 19:58:36 +0000

This is part one of my blog on scrum methodology.

What is Scrum?

Scrum is an agile project management framework, created by Ken Schwaber and Jeff Sutherland. The Agile Manifesto was created by these two along with unspecified others in the early 2000s. Scrum is lightweight and simple to understand but as with anything that require collaboration and organization, difficult to master. Scrum derives its name from rugby, which I would love to explain, but I know nothing of.

Agile vs. Waterfall

For the most part software development project management follows either agile or waterfall methodology. Waterfall is considered the traditional approach. It is linear, delivering a final project at the end of the waterfall. In waterfall each stage is completed before the next stage may begin.

Agile development is less traditional, and places focus on iterative development. In agile development a deliverable product is produced at the end of each sprint. This is not the final product but a functioning piece of the final product.

Scrum Roles

Product Owner

The product owner is a single person who is the only person responsible for the product backlog. Changes to the backlog may be changes by other scrum team members, but the end responsibility belongs to the product owner.

Development Team

The development team is made up of the people who do the technical development of the product. The development team is self-organizing. They are the ones who decide how long an increment will take this is not supposed to be dictated to them by the product owner nor the scrum master.

Scrum Master

The scrum master functions under the concept of servant leadership. They are there to make sure that everyone stays on the same page and that they are all practicing scrum correctly and efficiently. A big part of their role is removing obstacles for the development team and aiding in clear communication between all scrum team members. It is the scrum masters job to ensure that scrum does not become "flaccid". Flaccid Scrum is a term to describe scrum that uses scrum terminology but does not effectively produce incremented content at the end of a sprint.

Pillars of Scrum

Transparency

Scrum encourages transparency between scrum team members. Withholding information does not help productivity and so the backlogs are meant to be clearly visible and all goals are meant to be clearly understood.

Inspection

Inspection is meant to make sure the the scrum team is always checking in on themselves to discover what can be done better and what is going great. This is clear in the sprint retrospective.

Adaptation

Also a major pillar for scrum is adaptation. Scrum is meant to be agile and if something isn't working for your scrum team it can be changed,or improved upon. This is done during retrospective when the team members make commitments to changes. If your scrum team is more efficient with a every other daily scrum, the process allows for that change to be made.

Scrum Values

The scrum values are what it takes to have a successful scrum team.

Commitment

All team members must be committed to doing the work and achieving the goals of the scrum team.

Courage

Scrum team member need to have the courage to work through problems.

Focus

Everyone on the scrum team needs to be focussed on the end goal.

Openness

The scrum team agrees to be transparent about the work they are doing and where they are in the process.

Respect

Respect is the most important scrum value as the process does not work unless.
"Scrum Team members respect each other to be capable, independent people."

Come back next week for part two where we will further delve into scrum methodology.

Commit Messages

dotbehrens — Sat, 01 Feb 2020 17:30:40 +0000

This monday I decided that my new week resolution is to put more effort in to my commit messages. Previously I considered it a success if I managed to keep profanity out of my messages.

How to make a better commit message.

Everyone has a different opinion of how commit messages should be written but there are a few generally agreed upon rules.

The over all format for a commit message

type(scope):subject
body 
footer

Formatting rules include:

The subject and the body should be separated by a blank line for readability.

Unnessaccary punctuation marks should be removed from the message.

The subject line and each paragraph should be capitalized.

The imperative mood should be used for the subject line.

The body should be used to state what changes you have made and why you made them.

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

The Imperative mood

When it comes to moods in languages I have historically been uninterested in learning the differences. However, there is a wonderful little phrase that helps us format our subject lines. Before every subject line you write imagine the phrase, "if applied, this commit will..." This will force you into the imperative mood.

if applied, this commit will update getting started documentation

if applied, this commit will remove deprecated methods

if applied, this commit will merge pull request #123 from user/branch

The reason we use the imperative mood is because it continues the pattern that git itself established for commit messages. Consistency is key.

Types

Types are used so you can quickly see what kind of change has been made.

feat: is used for changes that pertain to feature updates.

fix: is used for bug fixes

style: is used to fix code styling such as indentations

refactor: is used for when code has been refactored

chore: is used for regular code maintenance.

perf: is used for an update that addresses the performance of the code

docs: is used for any change that has to do with documentation of the code

test: is used for changes made to tests.

This method of commit messages may be a bit extensive for smaller project or if you are going to rebase your commits and the smaller messages will be lost in the git void.

The short form of commit messages would be just the type, scope and subject line.

<type>([optional file name]): <short description>

A way to format the subject line when using a shorter commit message would be

Remove the X & Add the Y to allow Z

This phrase addresses everything that is needed to make your commit messages easy to understand by an outsider.

There are three things to remember about commit messages if nothing else.

Do not assume that the reader knows what the original problem was. 2 Your code is not self-explanatory.
Follow the convention set by your team.

Consistency is important for keeping commit messages understandable, especially when working in a team.

Building an MVP pt 1

dotbehrens — Mon, 27 Jan 2020 03:41:50 +0000

MVP stands for Minimal Viable Product. The goal is to create a web application that functions on a basic level. MVPs do not focus on front end design.
Here is a lovely link that will send you to a MERN stack repo. This repo is for a Mongo DB but I have faith in you to switch it to MySQL.

https://github.com/dotbehrens/fullstacktemplate.git

Before you start writing your first line of code you need to decide what you are building, and what you will use to build out your app. For this MVP I will be using a MERN stack.
M: I will use MySQL for my database
E: my server will use express
R: My front end will be rendered in React.
N: and My runtime environment will be node.js

I will be using the OwlBot Dictionary API, which requires an API Key. My app will consist of a search bar for the user to type in words and look them up from the API.

Now that I know what I plan to do. My first step will be to get an API key and check if it will work on Postman. It is important to look at the documentation for your API as it will tell you how it likes to be spoken to. Think of this as the API's love language.

Luckily Owlbot is pretty clear about what it wants from this relationship

tes

Owlbot will ask for your email address and send you an API Token to use to access its database. For security reasons, it is best not to share your API key. This includes not pushing it up to Github for public view. We will cover how to do that a little further on. For the sake of examples, I am going to pretend my API_Token is 'koalakoala'.
The best practice is to test our API key before we start coding.

Using Postman we will create a get request setting the headers as below.

Now let's open our coding environment and create a .env file. Inside of this file, we will declare an API_TOKEN environmental variable.

This is only half the battle to keep our API_TOKEN secure. Next, we need to make a .gitignore file so that when we push up our projects the computer knows not to push up the files in the .gitignore.

In my .gitignore file, I reference the bundle.js, which is a file that compiles my code, my node modules, and my .env file. Now my API_TOKEN is safe and sound.

Alright, next up we are going to render our front end. Our front end needs an input text box for our search queries and a submit button.
We should also add in a title so that our user knows what they are looking at. In a separate component, we should render a result from the query.

There isn't really a need to mess with the index.jsx file right now but let's take a look at it anyway.

Here we import the necessary react files including REact and react-dom as well as the root react component we are creating. We re also importing a CSS file to style our app. Finally, we are using React.DOM.render to render our component to the DOM.

We will leave it there for now. Part 2 next week.

Linux Terminal Commands With Cowsay

dotbehrens — Mon, 20 Jan 2020 03:40:14 +0000

This is an extension to my previous blog: Linux Terminal Commands.
Throughout this blog I will be using the extension cowsay. This extension is available on both mac and linux.

To install cowsay type in cowsay to your terminal and follow the directions. If that is unsuccessful here is a link to find the version of cowsay you are looking for.

https://pkgs.org/download/cowsay

All cowsay does is prints the text you tell the cow to say in a lovely little speech bubble. It is super cute.

first lets learn about pipes. Pipes are a single vertical line that lets the computer know that the outcome of the previous command is the input of the next command.

To demonstrate I will use another fun extension called fortune. When I type fortune into the console a fortune is returned.

Now what if I wanted to be told my fortune by a cow. Well then I could probably use a pipe.

fortune | cowsay

A pipe will let your function know that the output of what comes before the pipe is meant to be the input of what comes after the pipe. The output of our fortune ( the fortune) will be what the cowsays.

For the next part we are going to venture a little further into cowsay. I you type in the command:

cowsay -l

you will get back a list of the different cowsay options.

To use the options in cowsay, simply use the command:

cowsay -f <option> <whatcowsays>

Now lets think about using grep. "grep" will search through text to find matching characters say we want to find all of the letter k's in the list of cowsay options to do this we would use :

cowsay -l | grep k

The output of cowsay -l becomes the input for grep.

Lets say we wanted only to find the whole word koala. We would then use the command:

cowsay -l | grep -w koala

The -w searches for the whole word if we were to use the command:

cowsay -l |grep -w koal

nothing would be returned.

Personally my terminal is a little cluttered right now. Use the command




to clear the terminal and start with a clean slate.

If you would like to make your cow more vocal try the command:



```espeak <words> | cowsay <words>```



Be sure to turn up your computer volume.

Now that we have some experience with pipes and grep, lets try and figure out what the command below is telling the computer to do.



```history | awk '{print $2}' | sort | uniq -c | sort -rn | head -10```



As we know history will print out the previously used commands, but what is awk? Good question

The time has come for me to introduce you to another one of my favorite terminal commands "whatis". "whatis" is wonderful as it tells you what a command is. This may keep you from doing all sorts of horrible things to your computer. Try the command:



``` whatis whatis```



![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/8yqr100gos1hya4aljfl.png)

So what is awk? "awk" is a pattern scanning programming language. We can then deduce that we are looking for the things within history that match the pattern. The {'print $2'} is dealing with the fields we are putting into the command. For the most part lets ignore that complexity for now. 
We then take the outcome and sort it, then look for the unique values, then sort it again by a different criteria. Then we will ask for only the top ten or ten items from the head. 

We can test it to further figure out what this command is doing now that we are fairly sure it is not going to corrupt all of our files. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/lsvc787xtptup6u9sbiw.png)

As you can see the command prints out our most used commands and how many times we have used them. Handy? Maybe.. I don't know, but can a cowsay it?

Linux Terminal Commands

dotbehrens — Wed, 15 Jan 2020 01:09:47 +0000

My special skill is breaking things so I often find myself digging through the internet to find terminal commands having no idea if they will help or cause my computer to self destruct. A recent disaster led me to decide it was time to learn what these commands were actually commanding. I've put together a collection of commands I have run across and some that have helped me diagnose what is going on.

Something that has come up a lot is the file path "/etc". As someone who plays a lot of HOTS (Heroes of the Storm) I immediately think of E.T.C. (Elite Tauren Chieftain)

Though some may think of it as et cetera this file is really where the configurations for the applications on your computer are stored.

Another thing that has come up a bunch is daemons. Daemons, sometimes pronounced demons, are processed that run in the background. As a naming convention daemons typically end in the letter "d". This is why, while stumbling though mysql all of the sudden mysqld made an appearance.

pwd: This command stands for "print working directory". It prints what the absolute file from root is.

/: is the root file. if you "cd /", You will change directories to the root.

ps: "Process Status" prints a snapshot of the current running processes to the terminal.

free: This really handy command tells you how much space is free on your machine. On its own free will return the space in bits, which becomes overwhelming if you are working with larger files.

If "free" is paired with "-h", which stands for human readable, then the file sizes are returned in bytes which are more manageable.

kill: Will kill a process. Processes are usually preceded with a number if you use kill in conjunction with that number you will kill that specific process.

df: Similar to free but prints out how much space a file is using. Remember to add "-h" for friendlier units.

Two commands that I have run across that have led me to say things like "I guess I just have to trust you stack overflow" are chmod and chown.

sudo chown -R _mysql:mysql /usr/local/var/mysql

chown: Will change the ownership of the specific file. CHange OWNer.

chmod: will change the read and write permissions for a file.

While we have the example above lets talk about sudo.
Coming from Mac I was a little confused as to why my commands need to start with sudo. sudo is real nice in that it makes you the root user for that command. It is quicker than changing directories to root and changing back.

One of my current favorite commands is history. I should have known that it was an option but I just didn't. History will print a list of your command history. This is especially helpful when you have done so many things to try to fix a problem that you have forgotten what they are. Or when someone does magic on your computer and you want to know what happened.

A few fun commands to try:

cal: prints a mini calendar to the terminal
yes: just try it! Or, tell a friend to do it!

rev: will reverse the string given to it
cmatrix: will display a really nice matrix in your terminal.

Stay tuned for part two: Practicing Linux Terminal Commands with Cowsay!

Ceaser Cipher Toy Problem Walkthrough

dotbehrens — Wed, 18 Dec 2019 23:05:37 +0000

In cryptography, the Ceasar cipher is a shift cipher. It is a simple encryption technique that is named after Julius Ceaser who used the cipher to communicate with his generals. The concept behind a Ceaser cipher is that it is still a message written in plain text but every letter is shifted down the alphabet by a chosen number. While at first sight, this is an effective way to encrypt a message Ceaser ciphers are fairly easy to break. All it takes is to find the encryption method is looking for commonly used words and letter patterns. Once you crack one word of the code the rest falls into place.

Say our message is "Marsupials are the future" let's make our offset 6 meaning every character will be shifted down the alphabet 6 letters. The encoded message would then be "Sgxyavogry gxk znk lazaxk".

In order to make our cipher more secure, we are going to change up the alphabet available this will make the pattern a little less predictable to the code breakers waiting around every corner.
If we were to use the same message and encode it with the alphabet "mfutrip" the new message would be "patsfirals ate uhe mfufte".

Alright, let's get down to some code.
first let's start off with a shell of a function and some variables to work with.

const ceasarCipher = (options) => {
  let { alphabet, offset, message, command } = options;
}

Now let's decide our IOCE:
Inputs:
In this Ceasar cipher, we are using the following parameters,
alphabet: the letters we are shifting in the cipher
offset: the number of letters we are shifting
message: the message we are trying to decode/encode
command: whether we are going to encode or decode
Outputs:
We want to output a new string.
Constraints: N/A
Edge cases: N/A

To start let's make a container to hold our new string. Because I prefer to use array methods to string methods I am going to use an empty results array. You could also use a string and concat the new letters into the string.

Next, we are going to do a little cheat. We are going to add the alphabet string parameter to itself so that if the letter we are shifting is towards the end of the alphabet, it can still be shifted.

I call this cheating because this will only work if the number we are shifting by is less than the length of the alphabet. If someone wants to shift by a number larger than that, they are trying too hard anyway.

Since we know we are intending to return a string we can return result joined into a string.

The basic setup without logic is below.

const caesarCipher = (options) => {
  let { alphabet, offset, message, command } = options;
  let result = [];
   alphabet += alphabet;
      return result.join('');
};

We are out of excuses, now for logic.
Since our message input is a string and we are stubborn and prefer working with arrays we will first split the message into an array. Then we will loop over the array, and declare the variable index which will be the result of the indexOf the letter in the given alphabet. This indexOf method is great because if the letter is not found in the given alphabet indexOf returns -1. We can use this tool to make sure those characters stay the same. Spaces will now be accounted for.

Now that we have handled the letters we don't need to change we can change the letters we do need to change. If the command is "encode" we will shift the letters forward by the offset number.

Else if the command is "decode" we will shift the letters backward by the offset number.

Let's take a look at the final code for our Ceaser cipher.

const ceasarCipher = (options) => {
  let { alphabet, offset, message, command } = options;
  let result = [];
   alphabet += alphabet;
  message.split('').forEach(letter => {
    let index = alphabet.indexOf(letter);
        if(index === -1){
        result.push(letter);
        } else if(command === 'encode'){
           result.push(alphabet[index + offset]);
        } else {
          result.push(alphabet[index - offset]);
        }
  });
      return result.join('');
};

EsoSlang

dotbehrens — Wed, 18 Dec 2019 23:05:04 +0000

Esoteric Programming Languages or esoSlang is created by programmers that want to test the bounds of what can be done with programming languages. Often they are not designed for any practical reasons and are downright impractical or difficult to use. Sometimes though esoSlang influences more practical languages with their popular features. Below I am going to talk about an esoteric programming language I have been pretty excited about lately.

Perhaps my favorite is Whitespace. This language was released on April Fools day in 2003. It was developed by Edwin Brady and Chris Morris, who thought that programming languages should no longer ignore white space. White space only takes in spaces, tabs and line feed. The rest of the characters input are completely ignored. Whitespace is an imperative programming language. Imperative programming languages are languages that use statements to change the program's state.

Below is how to write "hello world" in Whitespace. You may notice it is a little bit impractical.

<tab> <tab> <space> <space> <tab> <tab> 
 <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <space> <space> <tab> <space> <tab> 
 <tab> <tab> <tab> <tab> <space> 
 <tab> <tab> <tab> <space> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <space> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> 
 <tab> <tab> <space> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> <tab> <tab> <space> 
 <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> <space> 
 <tab> <tab> <tab> <tab> <space> <tab> <space> 
 <tab> <tab> <tab> <space> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> <tab> <space> <tab> <tab> 
 <tab> <tab> <tab> <space> <space> <tab> <space> <space> 
 <tab> <tab> <tab> <tab> <tab> <space> <space> 
 <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> <space> <tab> 
 <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> <tab> <space> 
 <tab> <tab> <tab> <space> <space> <tab> <tab> <space> 
 <tab> <tab> <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> <space> 
 <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> <tab> 
 <tab> <tab> <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> <space> <space> 
 <tab> <tab> <tab> <space> <space> <tab> <space> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> <space> <tab> 
 <tab> <tab> <tab> <tab> <space> <space> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> 
 <tab> <tab> <tab> <tab> 
 <tab> <tab> <tab> <tab> <space> <tab> <tab> <tab> 
 <tab> 
 <tab> <tab> <tab> 

 <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <tab> 

 <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> 

 <tab> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <space> 
 <tab> <tab> 
 <tab> 

 <tab> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <tab> 
 <space> 
 <space> <tab> <tab> <tab> <space> 
 <space> 
 <tab> <space> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <space> 
 <tab> 
 <tab> <tab> 
 <tab> <tab> 
 <space> 
 <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <tab> 

 <tab> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <space> 
 <space> 

 <space> 

 <tab> 

 <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <space> 
 <space> 
 <space> <space> 
 <space> <tab> 
 <tab> <space> <tab> <tab> <tab> <space> 
 <tab> <tab> <space> <tab> <space> 
 <tab> <space> <space> <tab> 
 <tab> <space> <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <space> 
 <space> 

 <tab> <tab> 
 <tab> <tab> 
 <space> 
 <space> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <space> 

 <tab> <tab> <tab> <tab> <space> <space> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <space> 
 <space> 

 <tab> <tab> 
 <tab> <tab> 
 <tab> <tab> <space> 
 <tab> 

 <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <tab> <tab> <space> <tab> <space> <space> <tab> <space> <tab> <tab> <space> <tab> <tab> <tab> <space> <space> <tab> <tab> <space> <space> <tab> <space> <tab> 
 <tab> <tab> <space> <tab> <space> 
 <tab> <tab> <tab> <space> <tab> 
 <tab> 
 <space> <space> <tab> 
 <space> <space>

Whitespace does have a pretty interesting theoretical concept with it. It could be possible to write code in a more practical language and in between the characters have the white-space characters run an entirely different bit of code. No one would even have to know.

In conclusion esoteric programming languages are a fun way for programmers to test themselves and the bounds of computer programming. They can result in improvements to more main stream coding languages, but ultimately they are not meant to be used for more than their novelty.

Git

dotbehrens — Mon, 16 Dec 2019 01:10:27 +0000

This blog will be a brief overview of helpful git commands to make your coding life a little simpler and more organized. First, what is Git? Git is a distributed version control system. Git was originally developed in 2005 by Linus Torvalds, the creator of the Linux operating system kernel. Other version control systems include CVS and Subversion, or SVN. Though both CVS and SVN are not distributed.

Git saves and allows access to previous changes in your code. This means if you have broken code that wasn't broken before you can go back to the commit where things are working. Also, Git is especially helpful when coding in groups so that you can make changes to your branch of the code, while the main branch remains unchanged.

Git has been widely adopted through its criticism is that it is difficult to learn. Its commands are not the same as the commands of SVN or CVS.

If you are anything like me you have run into a problem or 500 using git. My problems often become a hot plate of git spaghetti, and me running down the hall cradling my laptop hoping to find someone, anyone who can help me figure out what Frankenstein git monster I have made and how to put it down, for the good of humanity.

I've made a shortlist of git commands I wish I had committed to memory the first 3 or 4 times they were shown to me.

$ git init

creates a new local repository for you to code in.

$ git merge

is a command I recently learned I was using all along. When you use the git pull command that enacts two commands. The first is a merge where the new data is merged into the old data. The second is the commit command. A commit is made of the new merged file right away. I believe the first time I was told this I said, "hmm, well that's super thoughtful of git.."

$ git log

Much like git hist, git log gives the history of the current branch.

$ git status

Shows the files you have changed that still need to be staged for commit.

$ git remote add

creates a remote repository that you can push and pull from.

$ git checkout

is used to switch between branches in your project.

$ git diff

will show the merge conflicts of a file

$ git diff

will show the merge conflicts before merging.

$ git branch

You can use to see what branches you can change to, the use git checkout or often the shortcut git co to move into the chosen branch.

$ git blame

is a handy little command that shows the most recent author and revision of each line in the file. It lets us know who is to blame for the infinite loop that just crashed your machine.

$ git rebase

rebasing, in general, makes for a cleaner and more linear project history
it adds the commits of a branch to the head of the branch so that the project is more linear.

$ git rebase -i Head~4

before pushing you can squash tiny commits down into one change to create a more concise commit This command will rebase the top 4 commits from the head.

There are many more useful git commands out there, and I encourage you to read into them before you start boiling that water for more git spaghetti.

Callbacks and Promises

dotbehrens — Thu, 12 Dec 2019 15:03:36 +0000

Before diving into the difference between callbacks and promises first we need to talk about what synchronous and asynchronous code is. Typically javascript runs synchronous code meaning it executes the code from top to bottom. Asynchronous code allows us to run functions simultaneously in javascript. Callbacks and Promises are both ways to write asynchronous code. Asynchronous code is useful when writing code whose response time is unknown, such as HTTP requests to an outside API. It allows for the code to go about doing other things as it waits for the response to the async code.

Callbacks are the classic way to write asynchronous code in Javascript. Callbacks are created when a function has another function as an argument. They are commonly seen in higher-order functions and further utilized in async code.

A callback is called a callback because it is a function that is only called when the outer function calls it back.

function one() {
 setTimeout(() => {
   console.log('1. First thing setting up second thing');
   setTimeout(() => {
     console.log('2. Second thing setting up third thing');
     setTimeout(() => {
       console.log('3. Third thing setting up fourth thing');
       setTimeout(() => {
         console.log('4. Fourth thing');
       }, 2000);
     }, 2000);
   }, 2000);
 }, 2000);
}

Callback Hell occurs when you have callbacks calling callbacks that callback callbacks. While in small doses callback hell isn’t too daunting or worrisome, when code gets more involved callback Hell starts to become more real.

Callback hell is a symptom of a bigger problem in your code. If you are entering the fiery pits of callback hell there is probably an opportunity to break your code up and make it more modular and less dependable upon other functions and therefore easier to debug.

Promises are a way to make callbacks easier to read. They do not change what the callbacks are doing, nor do they change the time complexity of your code. If in callback hell promises will only shove your coding problems in the closet so guests can visit.

Promises are instantiated by using the new keyword and the promise constructor. Promises, in essence, say “I promise to do this whenever that is true. If it isn’t true, then I won’t.

let promise = new Promise(function(resolve, reject) {
   // things to do to accomplish your promise

   if(/* everything turned out fine */) {
       resolve('Stuff worked')
   } else { // for some reason the promise doesn't fulfilled
       reject(new Error('it broke'))
   }
})

Promises have three states, solid, liquid and gas. Just checking if you are paying attention. Promises have three states, pending, fulfilled, and rejected. The initial state of a promise is pending this is before the promise operation begins. When an operation is completed the promise is considered fulfilled. If an operation did not complete it is referred to as Rejected. Usually when a promise is rejected an error is thrown.

The fun thing about promises is that they can be chained using the then() function.

let promise = new Promise(function(resolve, reject) {
   // things to do to accomplish your promise

   if(/* everything turned out fine */) {
       resolve('Stuff worked')
   } else { // for some reason the promise doesn't fulfilled
       reject(new Error('it broke'))
   }
})

The important thing to remember is that promises and callbacks accomplish the same thing, but promises are prettier and easier to read and keep you out of callback hell. They do not, however, fix your code and you should still make it your goal to write more modular code.

React Parents and Children

dotbehrens — Mon, 02 Dec 2019 01:57:34 +0000

I've recently been given the opportunity to work with React while practicing building the front ends of small web apps. This article will be a brief overview of how data is passed between parent and children components in React. React is an extremely popular Javascript library that was created by Facebook in 2011. Developers use React to create functionality in the front end of web applications. It works in tandem with HTML to create components that make up the pieces of an application, such as a search bar, or timeline. These different components are children of the parent App component. Components are self-contained modules that render and output. They help to make our code more composable so that the parts of our code work together.

React is definitely worth learning as there are many large companies that use react in their web development. In addition to Facebook, other companies that utilize react are Instagram, Netflix, and DropBox.

My own experience with react has been a mixed bag. On the one hand, React is very intuitive. I enjoy being able to place the function I write right in the HTML-like code, where you want it to render on the page. This is awesome and a huge improvement over what I had previously been using, jquery. On the other hand, trying to get your search function to change the information on your parent app component via the component of the search bar. That takes some getting used to when you are starting on your react journey.

Components can be either stateless or stateful. Stateful components modify the underlying data whereas stateless components respond to data. States is basically an object within the component. It holds data that the state needs and that may need to be passed to or changed by child components. State can be declared by assigning an object to this.state. State is mutable, meaning it can be changed.

Data can be passed from parent to child using props. Props are also an object however they, unlike state, are immutable. They do not change between parent and child components. They can be retrieved with the expression this.props.dataFromParent, which will retrieve the existing props and allow the developer access to them within a child component.
Props are properties passed from parent to child components that are immutable. They are passed as properties within the HTML-like react upon return.

Passing data from the child component to the parent component is a little bit more complicated. To do this data must be passed through callback functions. The parent component declares a function that is then passed down to the child component through props. The child component then passes in an argument to the callback function giving the parent function access to the data. Children components can also pass callbacks to parents by putting it on the state. In React state can be changed in the parent function by using the function setState().

In short, React is a nifty library to learn and is capable of many things, once you learn how the components need to communicate. Data is passed from parent to children components through props and passed from children to parents using callbacks.

Making a bootable file to install Linux.

dotbehrens — Mon, 25 Nov 2019 17:46:32 +0000

I recently made the giant leap into the world of Linux and had to sift through many tutorials to create a bootable file. Each tutorial would lead me to another tutorial and would bring up about 3 things I had never heard of. What follows is a summation of my experience and all of the decisions I had to make.

The first thing I had to decide what if I wanted to dual boot or not.
Dual-booting is when you partition your hard drive to load more than one operating system onto it. Your other option is to wipe your whole hard drive and start over with an all Linux system. I switched to Linux using a brand new computer so switching the whole machine to Linux wasn’t an issue.

The next step is to download a Linux ISO. There are many many options when it comes to what Linux version to download. I will give you the advice I was given. Go with the one that is most well documented. That way if you have problems you have the resources to solve them. I was advised that Ubuntu was the tried and true method for programming on Linux. From most of what I’ve seen Linux coding tutorials mostly use Ubuntu.

I decided not to use Ubuntu. Instead, I chose Linux mint. My main reason is that the people I know who use Linux on a regular basis have been using it without major problems. The difference between Linux Mint and Ubuntu is that Ubuntu is made to work more similarly to Mac and Mint works more similarly to a windows desktop. Ubuntu also takes up more memory than mint. Ubuntu unity takes almost twice the amount of space that Mint Cinnamon requires. Mint is also faster.

I’m afraid that isn’t the end of the decisions that I needed to make.
Linux Mint has three desktop options you can download. Xfce, MATE, and Cinnamon.

https://linuxmint.com/download.php

I chose Cinnamon. It has a more full-featured desktop and as someone who is new to Linux, I thought starting here would be less frustrating. MATE is more stable and faster. Xfce is lightweight and stable. I didn't worry too much over this choice because the desktop theme can be switched without having to reinstall.

Now to choose which size to download.
Older computers might need to run the 32-bit installation, but if your computer can run the 64-bit it is recommended.

Next up was picking which mirror I wanted to use. Mirrors are just sources to copy and download from. The best bet is to choose the one that is closest geographically, that way it will take less time to download. There is some fear that you may get a malicious ISO. Don’t worry too much there is a step for that. I chose the Oklahoma University option. Mostly because I knew where Oklahoma was.

Here is a link to how to verify your ISO. I personally skipped this step and nothing bad has come from this … yet.

Next, I needed to find a flash drive. This was probably the most time-consuming step as I needed an empty or empty-able flash drive with at least 2GB of space on this flash drive. As I found out, A 2GB flash drive likely does not have 2GB of available space. I had 1.83 GB of available space on my flash drive and needed 1.87 GB. It was a very sad realization. I also tried to partition an external hard drive and use it. The utility I used to make a bootable drive, Rufus did not recognize partitions as separate devices and wanted to rewrite both partitions. I elected not to do that.

Let’s talk about Rufus. Rufus helps create a bootable file that will allow you to install Linux. It’s much like unzipping a .zip file, just a different file type. Rufus is your friend. This is a link to the download. https://www.techspot.com/downloads/6062-rufus.html.

I made sure to switch my file system to FAT32 as I read it was more flexible and uses space more efficiently. The rest of the settings I left as default.

Finally, I was ready to install Linux.