Every time I performed a git fetch or a git pull on my MacBook for a particular repository I would see a log from the command that said something like the following.

From github.com:
 * [new branch]      User/feature -> origin/User/feature

What I noticed though, that branch was an old and outdated one that nobody was working on. I came to find out it hadn't been updated for 11 months! I had been seeing this message from github.com for long enough... I had to track it down to remove it.

The Fix

Git provides a way to migrate the refs on your local machine to a flat file with case sensitivity, instead of the default directory structure which may be case-insensitive.

Run this command from your repository root:

git pack-refs --all

https://git-scm.com/docs/git-pack-refs

Then do a git pull or git fetch, and you'll stop seeing the "new branch" because the ref will use the flat file with the correct case.

The Root Problem & Explanation

Git refs may be stored case-sensitive in one filesystem, but case-insensitive in another.

This can cause some references in git to be incorrect according to your local filesystem.

In my scenario that I observed (every day) the branch was named on the remote using capital letters, User/feature. To add to the mix there were other branches named lowercase, user/feature2. So when refs were being stored in my filesystem it would put the branch under whatever one existed first, which happened to be the lowercase one.

user
  - feature
  - feature2

Ideally it would store them like this so git can correctly find the ref.

User
  - feature
user
  - feature2

When the refs are stored in a flat file the case sensitivity can be preserved, so you won't see the new branch warning anymore.

Disclaimer

Over time when branches are updated, there's a chance you will have to run the command again, this only affects your local machine's refs.

An alternative approach could be to rename the offending branch on the remote itself.

Summary

The software development industry has a lot of steps to take in its interview process. Frequently, you have multiple interview rounds, and a coding challenge of some sort, some of which are live in front of your interviewer(s).

Recently, I was interviewed and had to do a live coding challenge over the web. I was comfortable, in my own home, yet, I still had some pretty major failures that made it so I wasn't able to show my true colors as a software developer.

I want to go over what happened over the course of the interview, as well as what my takeaways were after some reflection about how it went.

Coding Interview Sections

• First 5 minutes - Background
• Last 45 minutes - Coding Challenge
• Takeaways

Background

The first part of the interview was extremely short, and was the easy part. The interviewer, who was really kind and friendly, asked me to introduce myself and my developer background. So, I dove right in and explained where I'd come from, what technologies I'd used up to now, and what I was currently working on. Awesome, things were going alright so far, and I had nothing that was bothering me yet.

Good good...

Then the next question is where I probably could have selected something better. I was asked to describe a recent project that I'd been working on and I chose a Node.js project that I'd worked on solo a while back to help someone move data from a database to a 3rd party service.

I explained everything that was involved with that project, like how I was able to validate the data moved successfully. It was a good conversation, yet, I didn't feel good about my choice of project discussion. The role I was applying for wouldn't really take advantage of the skills I was talking about...

Lesson Learned - When I get asked this question next time, I'll select a project relevant to the role I want.

Coding Challenge

...The Coding Challenge...

The general format of the coding challenge section of the interview felt pretty good and fair. It started out with the interviewer explaining the puzzle that was to be solved during the interview. After the puzzle was explained, I could ask any clarifying questions, and begin to solve the puzzle in whatever way I chose. I was also able to choose one of many different programming language options, which was great.

I began by creating some pseudocode-comments and spoke out loud what my thought process was. During this portion of the coding challenge, I feel like I actually did "ok" on a first draft attempt at the solution. I had some data structure usage in mind to help solve it, which I talked through with the interviewer. We went back and forth a little bit in discussion but agreed it sounded like an OK plan overall.

After feeling like I found something that might work, I began to actually write some code. Of course, this felt ok right at the start but as I started to dive in I realized I definitely had some weaknesses I didn't realize I had. Only through this type of interview would I have learned I need to strengthen certain areas.

...The Environment...

The coding environment was in the browser, and of course, this means it was pretty much a text editor that I was writing code in. I felt like I was writing code BLIND... IDEs provide a really good environment to work in, but I've relied on their help to use the various APIs so much that I had to look up the docs frequently in the interview, which thankfully was allowed.

In the real world day to day, I've not had to memorize all the order of parameters of various APIs, but oh man it would have helped me to perform better in the interview. I'm strongly considering taking some time to specifically code "blind" without the IDEs help so I can find out what APIs I actually know.

...Finishing? the Challenge...

As the challenge continued, I got down into the depths of the puzzle, started to struggle a little bit, and the interviewer chimed in with helpful hints here and there. While somewhat helpful, some of the hints actually swayed me away from my initial design that we talked through in the beginning. Because there were now a few very different designs going into the algorithm I started to really struggle in my solution. The pieces weren't fitting together how I was hoping, and the answers just weren't coming together. I really should have kept going with my initial design and thought. If you are pretty confident in a solution, don't let the interviewer sway your design.

The key here being, the interviewer doesn't know your whole solution. They might not know you've already got a solution to a piece they haven't thought of, so when the give you a hint, make sure it fits your design and you don't have to implement their idea.

...Times Up...

Unfortunately, the challenge ended, and I didn't have a working solution in the allotted time. Of course, this comes with feelings of shame, regret, failure, imposter syndrome, etc. It's wild how emotion plays into the interviewing experience as a developer, and it really can do a number on your confidence when you fail to show what you can do.

Now, I know I am totally capable of solving many problems, moving data around, integrating 3rd parties, creating reusable components, building web pages and styling for mobile devices etc. But after the coding puzzle and performance, I don't know if I'd hire me either if I was the interviewer that ran the coding challenge.

As hard as it is to not just feel bad about the whole thing, I knew I needed to take a step back and not let a bad interviews kill my drive.

...After Math...

After finishing up with the interview, I didn't stop solving the challenge and walk away with it unsolved. I wasn't about to let some silly puzzle in a timed challenge beat me. I took some more time and FINISHED the puzzle and wrapped it into a nice little bow to prove to myself that I am absolutely capable of delivering the desired solution. I specifically allowed my failures to strengthen my weaknesses directly after the interview.

The best part is, for this particular problem, I now know what kind of data structure will support what I needed to solve. If I run into something similar later I'll be able to remember this as a strengthening moment, not a complete failure.

Takeaways

Here's a quick rundown of the key takeaways and tips

• When asked to give a background, highlight the role's requirements you're interviewing for
• Have a project example ready which is directly relevant for the job you're interviewing for
• Know your crutches, since live coding typically isn't inside of your own IDE
• Be sure to know your APIs, like how to use various string and array APIs without looking things up
• Code "blind" to find out what you really know in a language
• Freshen up or strengthen your algorithm skills, even if it is only for interviews. I typically don't have to iterate through strings the same way and unscramble words in my job, but many code challenges will have you doing it.

Conclusion

These timed coding experiences often feel very different from the real world work that needs to be done. For example... In my career I've been building parts of CRM products, back-end office websites, or handling MySQL and Mongo data structures, but all of that hasn't felt anything like the live-coding challenges you get into the interviews.

I learned a lot over the course of this single coding interview. Some about me, and some more about the interview process in general. I now know what I need to practice and study in order to perform well in the time-crunched coding experience.

Coding Interviews are the standard it seems for most organizations, so I'll be practicing these types of problems until I feel very comfortable with the process. In doing so, I hope to open more doors of opportunity for my career and social network as I speak with more brilliant engineers.

Summary

Over the last few days I've started to read the book, The Pragmatic Programmer, and I don't know why I let it sit closed for so long... (Got it back in December)

It's a great resource for learning about best practices for software developers, and it's just an overall refreshing read created by those who really care about software.

I'm almost 2 chapters in, and I'm already singing it's praises, I'll give you a taste of what they've mentioned so far, in my own words of course. Pick up the book if you haven't already, you won't regret it.

Care About Your Software

There are many levels to what this means, but to have a good piece of software that lasts over the tests of time, you'll need to take care of it.

First, start where you are at, and don't cause more harm to your code. Just because it's faster to copy something "for now", and you've already seen this duplication before, it doesn't mean you should follow suit and add to the problem.

Instead fix the duplication or other problem you're seeing as you run into it. Or, bare minimum when in a crunch for time, call it out for future developers in a comment so it's flagged as a problem.

The main idea being, be sure to think about your software, critically think about your code, and face those harder choices when you need to. It will make your project mature in good ways.

Don't neglect your code. Like bad milk, it will spoil, and be a smelly experience dealing with the mess it causes. It's better to clean it as you find problems.

Easy To Change

Something significant that was mentioned is the idea that a good design typically makes it easier to make changes to the code. There's a ton that can go into "design", but as an overall concept, this is really great!

The reason I like this so much, is it kind of helps a developer identify when a system might not be designed well, and when to point something out to the team. If an area of code is hard to change, or unexpected side effects happen because of a change... It might be time to reconsider the design of that system.

It may even be appropriate to call a meeting together to make sure everyone is aware of the side effects and what problems you're facing. The result of the meeting may create a better developer experience, and who knows, you might be a hero by saying something.

DRY Duplication

Most software developers have heard of this acronym before. Don't Repeat Yourself! The idea being, well... don't repeat yourself, right? Most times this is resolved by creating abstractions in your code so you don't have repeated logic in your codebase.

However, this is not all it is meant to mean.

What the authors brought to light in the first few chapters of this book, is that it's way more than just abstractions into functions and classes. It is a much broader concept and way of thinking. Rather, it includes all aspects of duplication. Code, documentation, data, API interfacing, third party library's providing the same services, etc. All of these have levels of duplication you need to be aware of it all so you can minimize it.

It isn't just about creating functions and classes. It's about reducing any level or system of duplication that surrounds your software.

Orthogonality

This concept really hooked me as I read through it. It's one of those ideas and systematic thinking I've tried to implement as I code, but it was amazing to read it well defined in a book.

The idea of Orthogonality is that a change to one thing, does not affect or change another.

If you are able to change an area of code and nowhere else in the system "cares" about that change, it probably means your system is well designed. On top of that, it's easier to write tests for that code because it is so isolated from the other systems.

So, the tip being, write your code in a way that changes to one feature/system don't cause side effects to other areas of the software. It remains isolated.

I've been in code bases where this is very much NOT the case, and I've been in others where it is. Orthogonal systems are so much more rewarding to work in, and the stress you get when making changes is much much lower. (also, tests are typically written in well designed systems so that's a HUGE bonus)

Push your system designs forward in a way where changes to one area, don't affect another.

Reversibility

If a system or library you've relied on suddenly goes away, what will happen to your software?

The idea of reversibility is to allow yourself the flexibility to change the underlying implementations to those types of problems. To do so, you can abstract your usage of those libraries into your own interfaces and APIs.

An example, would be to abstract what kind of database you use. Right now you might be implementing your code directly with only MySQL, but what if you were required to move to Microsoft SQL next week? Will your software crumble, or are you flexibly designed to minimize the required change?

These types of considerations need to be taken into account, and in the long run a design with reversibility makes your software more robust.

Conclusion

There are so many other things they've been sharing in the book, I'm excited to uncover what next.

Summary

In the last two weeks (during weekend hours) I've created of very simple Chrome Extension that downloads a CSV file of data on a very specific website page. It's been fun to have an extension that I built in my browser, but I definitely spent a lot of time in the Chrome Extension docs in order to get things rolling forward.

I wanted to go over a few tips that people should probably be aware of when they dive into creating Chrome Extension. It's been some trial and error for me to get to where I'm at, and hopefully this will give you a good heads up.

This is a pretty short read, but here's the outline

• Manifest Version
• Online Examples
• Understand The Components

Manifest Version

To create the most updated version of a Chrome Extension you should be using Manifest Version 3. It is the latest version of the manifest, therefore, it wil be the most supported version going forward. If you can, use this version of the manifest! It will keep you updated (as of May 2021) and help you avoid the need to migrate too soon after creating your extension.

Start with v3 first.

According to the docs, there are some things that are not in V3, like browser actions, and page actions (sad faces). Some of these features have been moved to the actions api, but there are also some parts that just don't exist in v3 yet if I understand the docs correctly.

So, if you start in V3, and find you actually need V2, only then, should you actually start in V2 instead. The only downside here is you'll have to be in an understanding that you'll be migrating up to V3 at some point.

Start in V2 if you can't use V3 for something specific.

Online Examples

In my short experience, most examples I've run into online have been for the previous manifest version (2). Keep this in mind when you are looking to do something specific, and you've been reading up in a tutorial or video made by somebody else.

Keep in mind if you are using V3, you may run into things that won't work for you the way tutorials say they should.

In particular for me, I've been having trouble figuring out how to disable and grey out my extension on specific page. My understanding is that I can use the chrome.action.disable() (chrome action API), but it doesn't actually grey out the icon... It does disable my extensions UI from popping up on click, but it doesn't grey out the icon like I expect it to. It feels like it only does half of what is supposed to happen.

(Maybe I've just totally missed it in the docs, and I understand the docs wrong, but it seems that's when you call disable() it is supposed grey out the icon and prevent the popup from appearing. If anyone has done this with V3, please share!)

Understand Environment Isolation

I jumped straight in, no mentor, no previous knowledge, ready to make a mess of things :D. It went something like this:

1. Looked up Chrome Developer Extensions in Google
2. I wrote some JavaScript that does what I needed, loosely following some examples.
3. I successfully made the extension do what I wanted and got it to show in the browser (bare minimum viable product)
4. Used my extension, showed it off to a few people who might also use it, that's always fun to do :) .
5. I reviewed my code knowing it's in a messy state, since I didn't deep dive into the concepts while making it. (Like I mentioned, I just dove straight in)
6. I'm now learning the concepts of the extension ecosystem so I can provide a clean modern extension for myself and my small target user-base.

A great place to start is the Getting Started directly from Google.

If you breeze through that Getting Started extension example above, it indeed builds you an extension, but it doesn't really solidify the concepts of what is going on. To understand the concepts you actually need to follow the links, read up more on what is going on, and overall be interested in learning more about how the architecture actually works. If you follow the additional links you'll have a better chance at building something solid and less thrown together.

In particular, the distinction that execution environments are isolated makes simple enough sense in theory. But depending on your extension's purpose, you might need to understand it more in depth to accomplish your goals. The extension's execution environment is separate from the page's execution environment, so you have to plan for that in your design.

For example, my extension really does a very minimal amount of work, but it does need to know about both environments. Here's what it does.

1. Extension has a download button in its UI that can be clicked
2. Queries the page's DOM for data in a specific table
3. Uses the data to create a downloadable CSV for the user's device

For each of those steps above, I had to understand where that work was being done before I was able to get it to work correctly. I changed my code around a few times before I understood it correctly.

1. Extension Environment (download button)
2. Page Environment (table of data on the page)
3. Page Environment (use data to create download)

In order for my extension to start acting on the page, I had to use script injection. In particular, when the extension button is clicked, I inject a script into the page that does the rest of the work, on the page.

Extension Environment --> script --> Page Environment

TIP - When injecting a script into a page, you can't use functions that are declared in your extension's js file. They won't be defined when the page environment tries to use them, since the environments are isolated. You have to inject the functions into the page, as well as the code that uses them.

Conclusion

I've been having fun building an extension, even if it's the only one I ever build. I use chrome a lot, so it's fun to see my extension icon floating up there next to my staples that I always have!

Anyway, extensions so far feel very different to develop, and I'm still learning about them, but so far, I know to

• Watch out for the correct manifest version in the docs
• Carefully choose examples to follow, keeping manifest version in mind
• Pay attention to which environment a piece of code should run

Summary

This will be a very quick post, getting straight to the point. There's not too much fluff to get lost in, so let's just dive right into the code example!

I will show how to

• Create a Blob from a string (Blobs work well with the download attribute of the a tag)
• Create an Object URL for your downloadable blob.
• Create an a tag which powers the download
• Trigger the download programmatically, (or attach the link to the DOM if you want)
• Side note - It's best to release the URL afterward

// Create the blob (file data) and trigger download:
const blob = new Blob([csv], { type: "text/csv;charset=utf-8;" });
const url = URL.createObjectURL(blob);

// This simple recipe uses the <a> tag, ends up something like:
// <a href="bloburl" download="filename.csv"></a>
const a = document.createElement("a");
a.href = url;
a.download = "filename.csv";

// Trigger the download
a.click();

Create a Blob for download

const blob = new Blob([csv], { type: "text/csv;charset=utf-8;" });

There are a few assumptions about the above snippet

1. You want to generate a CSV file for download
2. You already have a javascript string formatted into a CSV string. (There are libraries and many other ways to accomplish this, so I will leave this out)

You could really create a file of many types, you'll just have to read up a little on your specific case.

If you want to know more about Blobs, the mozilla docs about Blobs are the way to read up!

Create an Object URL

This one is in preparation for setting up the download attribute of the a tag

const url = URL.createObjectURL(blob);

If you want to know more, the mozilla docs about createObjectURL are what I used.

Create the a tag

// This simple recipe uses the <a> tag, ends up something like:
// <a href="bloburl" download="filename.csv"></a>
const a = document.createElement("a");
a.href = url; // It's pointing to our Blob!
a.download = "filename.csv";

Go here to learn more about the download attribute

Then, as a final step you can actually download the file (without even attaching the element to the DOM!) using:

// Trigger the download
a.click();

You can optionally attach the tag to the DOM, or manipulate an existing tag that is already on the DOM, etc. This is just one of your options.

Conclusion

I had to create a simple downloadable CSV template for a work assignment, so I figured I'd share this simple recipe of how to accomplish it.

I will also note, that the Mozilla Docs recommend releasing the Object URL once you are done with it for proper memory management. I'll leave that to you for further reading.

Anyway, I hope this helps somebody, including myself, in the future when dealing with downloads!

Summary

I have an upcoming personal project that deals with ordering Pokemon in various ways. Since there are so many Pokemon, I wanted to take some shortcuts to get all the data I needed. Luckily for me there are many sites out there that already have most of the info I need. Pokemon has many fans, so a big thanks to all of you data contributors out there!

Side Note - There's probably already a spreadsheet, or json file somewhere that has what I need, but I wanted to data-scrape just for fun

Now, let's get to what in the world I was doing :D.

Decide On Data

Ok data, let's talk data... what do I need in order to complete my project? 🤔

• A list of Pokemon by national pokedex number
• A list of Pokemon by Johto pokedex number
• Multiple lists of Pokemon trading card sets

So, almost a direct correlation, here are the sites I got info from in my adventure this weekend.

• pokemondb.net (A list of all Pokemon by national pokedex number)
• pokemon.fandom.com (A list of all Pokemon by Johto-dex number)
• pokellector.com (Lists of Pokemon card sets, which is a major piece of my project)

So, why is this information going to be useful? For those that aren't familiar, Pokemon are all assigned a unique number for identification, and these number-to-pokemon correlations make up what is called a pokedex. Basically a dictionary listing them all out. My project's purpose is to help in ordering pokemon card sets in their pokedex order, so this information will be vital for success.

Alright, so now that we know what data we are after and where we can get some of it, let's go get it!

Inspect the page

I went to pokemondb.net to get the list of all pokemon... Open that page if you're curious enough to see what the table looks like. In order to scrape the data with JavaScript I need to know the structure of the page so I can select the appropriate pieces from it, so let's take a look.

Inspect the DOM of page

Right-click on the table and inspect it. Here's a snippet of what it looked like.

<table id="pokedex">
<tbody>
<tr>
    <td class="cell-num cell-fixed" data-sort-value="1">
        <span class="infocard-cell-img">
            <img 
                class="img-fixed icon-pkmn" 
                src="https://img.pokemondb.net/sprites/sword-shield/icon/bulbasaur.png"
                alt="Bulbasaur icon"
            >
        </span>
        <span class="infocard-cell-data">001</span>
    </td>
    <td class="cell-name">
        <a 
            class="ent-name" 
            href="/pokedex/bulbasaur"
            title="View Pokedex for #001 Bulbasaur"
        >
            Bulbasaur
        </a>
    </td>
    ...
</tr>

I want 2 pieces of information from this table, the name, and the national number. Using the above inspect information, I can construct various selectors to get it!

Run console commands

All of the following code was placed directly into the Chrome Dev Tools, no servers, no Node, or anything else is required. The only other tool I used was VSCode for writing code before placing it into the console. (syntax highlighting and proper editing!)

First, let's figure out how to select all the rows of our pokemon. I ended up constructing something like this:

// An array of nodes, each holding a <tr> with a Pokemon's data
const rowNodes = document.querySelectorAll('table#pokedex tbody tr')

Awesome, that's how we get the tr elements that each hold a Pokemon. The next few pieces of information assume we have a rowNode variable available to us in JavaScript to act on. Specifically, I looped through the above nodes array in a forEach and used a rowNode variable for the element argument.

Alright we're moving forward, let's get the actual info now. In order to get the number:

// This will select the number text
rowNode.querySelector('td:first-child span.infocard-cell-data')?.innerText

In order to get the name:

// This will select the name text
rowNode.querySelector('td:nth-child(2) a').innerText

Now you can gather up the Pokemon data into a list using those pieces of data!

pokedex.push({
    name,
    nationalNumber,
});

Alright, with those pieces explained so you can better understand what's going on, here's my code that grabs the full table, and turns in into console printable json, which I can then copy-paste into a new file and save for my own purposes.

// Pokemondb.net/pokedex/all Screen Scrape
// returns object of pokemon
// optionally print the JSON to console
function grabPokedex(printJson = false) {   
    let pokedex = [];
    document.querySelectorAll('table#pokedex tbody tr').forEach((rowNode) => {
        const nationalNumber = rowNode.querySelector('td:first-child span.infocard-cell-data')?.innerText || 0;
        const name = rowNode.querySelector('td:nth-child(2) a').innerText || "";
        pokedex.push({
            name,
            nationalNumber,
        });
    });

    if ( printJson ) {
        prettyPrint(pokedex)
    }

    return pokedex;
}

// Just a bonus for fun
// This helps print the whole object to the console
// This make it copy friendly
function prettyPrint(anyValue) {
    console.log(JSON.stringify(anyValue, null, 2));
}

Conclusion

It was a fun little adventure. In general for screen scraping, all you need to do is

1. Identify what you need (find the site and page with your info)
2. Find the structure of the data (inspect the page)
3. Build JavaScript to select the right pieces of data (then copy paste)

I followed a similar process for each site I scraped data from. Now I have enough information to start compiling it together in the format I actually want it for my project. If I wanted, I could even drop it straight into a database like Mongo!

For fun, I also made a CSV output of the same data using the same concept. I just didn't want to bore you with more detail than was needed.

Anyway, hopefully you've got at least an idea of what it might take to do a small amount of screen-scraping if you ever find the need to. Have fun out there, until next time!

Bonus: It would be more automated to just have it download a file directly, but browser limitations block this behavior without a server doing that work.

Summary

In order to Unit test a React component you need to be able to control the props and the state that it deals with. Otherwise, it's really hard to be able to know what to expect in the tests you write. So how do we deal with components that are too coupled with business logic?

So far in my experience, separating the business logic out into custom hooks allows for better and easier testing, and reusable logic. In this post I will go over refactoring a React Component by separating out some logic into a custom hook. This enables you to later user that logic elsewhere (avoiding copy pasta), and to mock that hook for testing the specific parts of the component. (This post won't go into the actual testing, just getting ready for it)

A Complex Component

Take a look at this pseudocode component, it has few things going on

• Its purpose is to display a list of users
• Admins are the only ones who should see other admins
• It knows how to grab the users
• It gets a permission, applies some logic, and filters the list

function UserList() {
    // State, holds the user data
    // Determine if admins can be shown
    const [users, setUsers] = useState([])
    const [hasAdmin, setHasAdmin] = useState(false)
    const [filteredUsers, setFilteredUsers] = useState([])

    // Get the users in a useEffect since it is an async task
    useEffect( () => {
        // Some async code that grabs the users
        // ...code...
        setUsers(newUsersResult)
    }, [])

    useEffect( () => {
        // Async call to get the permission
        // ...code...
        setHasAdmin(newPermissionValueResult)
    }, [])

    useEffect( () => {
        // Admin users can view them all
        if ( hasAdmin ) {
            setFilteredUsers(users)
        }

        // Non-admin users get a filtered list
        const nonAdminList = users.filter((user) => {
            return user.isAdmin ? false : true
        })
        setFilteredUsers(nonAdminList)
    }, [users, hasAdmin])

    return (
        <>
            {
                // Map over all the remaining users so
                // they can be displayed
                filteredUsers.map( (user) => {
                    return (
                        <div>{user.name}</div>
                    )
                })
            }
        </>
    )
}

It knows... too much... Let's make it a little more dumb, and a little less smart. 🙃

Up above you can see that React Component currently has some http fetch type logic directly inside of it, and it handles some business logic for admins. What I'd like to do is make these pieces of logic exist in a separate hook to keep the component clean and focused on what it should actually be doing, just displaying users.

Again, doing this will allow me to do a few things (I think I've mentioned these before...):

• Reuse the same hook in other components that need an admin-permissioned list
• Test the component by mocking the hook with returned list of Users

A Custom Hook

Give a gander at this new organization of the code. See if you can spot the difference, it's really not too different at all. I just moved some chunks around.

function useAdminRestrictedList() {
    // State, holds the user data
    // Determine if admins can be shown
    const [users, setUsers] = useState([])
    const [hasAdmin, setHasAdmin] = useState(false)
    const [filteredUsers, setFilteredUsers] = useState([])

    // Get the users in a useEffect since it is an async task
    useEffect( () => {
        // Some async code that grabs the users
        // ...code...
        setUsers(newUsersResult)
    }, [])

    useEffect( () => {
        // Async call to get the permission
        // ...code...
        setHasAdmin(newPermissionValueResult)
    }, [])

    useEffect( () => {
        // Admin users can view them all
        if ( hasAdmin ) {
            setFilteredUsers(users)
        }

        // Non-admin users get a filtered list
        const nonAdminList = users.filter((user) => {
            return user.isAdmin ? false : true
        })
        setFilteredUsers(nonAdminList)
    }, [users, hasAdmin])

    return filteredUsers
}

// The UserList now only needs to know one thing...
// What hook to call to get the correct list :D
// The users will just be displayed
// (You could also pass them in as a prop to really
// separate that logic out)
function UserList() {
    const users = useAdminRestrictedList()

    return (
        <>
            {
                // Map over all the remaining users so
                // they can be displayed
                users.map( (user) => {
                    return (
                        <div>{user.name}</div>
                    )
                })
            }
        </>
    )
}

See how much dumber the UserList component is now? It doesn't need to know

• how to filter the list
• it isn't holding onto the full user list

It only needs to know the users to show, and now we have that.

This is an extremely simple example, but hopefully you can see how I've separated out the business logic into a hook instead of keeping it within the component. Now to get a list of users that should be viewable into any React component you only have to call that hook. (Goodbye copy pasta, we won't miss you)

For example an EditableUserList might render editable fields for the users, not just display their name. Now you have two components that can share the same hook, and the admins won't show up for users who shouldn't see them.

Mock the Hook and Test

I'm not going to go over the testing of the component here, but I did want to make it a point of this article that now you can easily test the component.

Having the component separated from the business logic will allow me to test the component's functionality without worrying about the implementation of the hook, by mocking the hook's return value in a test.

To write a test for the component, all I have to do is generate any list of Users and have a mock of the hook return them. Now I can focus on specifically what my component should be doing with that list. (and depending on your use case, you could even just have the users passed in via a prop instead. There are always options to consider)

To write a test for the hook... like most, I'll be looking up what the standard is currently, but there's a library for that no doubt.

Conclusion

I like keeping my components as clean as I can. Separating logic out in this way is my preference because I can easily look at the component code and decipher what it's actually supposed to do.

My rule of thumb is if I can't glance at the code for under a few minutes and then understand what's being rendered... There's probably too much logic going on inside of the component. That's me though, let me know if you feel the same.

Thanks for reading!

Summary

When I say testing I actually mean automated testing through code in this post. I don't mean having someone manually clicking around in the application trying to notice any problems. What I'm talking about is explicit pieces of code that test the software for exact output.

Here are three questions I'd like to explore

• Who benefits from automated testing?
• What benefits do you get from automated testing?
• What cost makes automated testing possible?

Who Benefits

The benefits of automated testing are "many", and it can benefit many different people. So, with automated testing in place what individuals actually end up benefiting from it?

The person, organization, or company who owns the software ultimately benefits the most from implementing automated testing since they sit at the highest level. The goal of this party is to deliver a working product to a paying customer. Hopefully, a customer who will pay again for the services to keep that revenue stream flowing. In order to deliver a product that works as expected there are many teams and man-hours involved.

At a very high level (leaving out a lot), these are some of the teams and resources that may be managed by an organization, and all can benefit uniquely from automated testing.

• Software/Product Design & UX
• Developers
• Quality Assurance
• Data Management
• Software Training
• General Personnel training
• Customer Satisfaction

Each of those teams takes ownership of the software at a different lifecycle. They each have to apply their time and effort every single day to meet the demands of the customers. If each of these groups has to manually validate everything they do, every single day, with every process, scaling into a larger company will become a gigantic hurdle.

Some questions to consider

• Is it better to hire more people so the company can scale, since there is so much to do?
• Should a company require overtime hours on the weekend to make sure things are working?
• With each delivery of the product does the whole team have to be on call just in case something goes wrong?

The old saying "work smarter, not harder.." really applies to this scenario. If a company requires more hours, and more effort than a normal workday from its employees, burnout may become a real problem, I've seen it.

Testing Benefits

These are the primary benefits I see with automated testing

• Confidence
• Consistency
• Bug Prevention
• Clean Code Design
• Features can be clearly explained

Confidence

When software is properly tested you can be confident that the time, money, and other resources spent on it will have been worth it. The goal after all, is to provide value to the people that use it.

Proper testing provides the confidence that what is said about the application's features is actually what they get. If they get what was promised from it, they'll be confident in their choice to trust it.

Consistency

What does the software do today? Can it promise that all working features will still work tomorrow when new features are released?

Sometimes features in software are intertwined in the data in the back end, or the UI components of the front, so how can software stay consistent for its users while evolving forward?

With proper tests that cover the functionality that shouldn't be changing, it can deliver a consistent product with confidence, even while features are added.

Bug Prevention

Software bugs... Some are harmless (and even hilarious), but some are devastating.

• Consider a scenario where a system accidentally charges a customer $10,000 when it was meant to charge $1,000 or $100... Ouch.
• Or another scenario where a bug fix was delivered to production, but another area gets broken unknowingly... (I just thought of this term now, so bear with me, but this could be described as a wormhole bug. The software went from having a bug in one place, to having one pop up somewhere else.) In my experience, these are not fun to deal with, as it means code was coupled in a way that wasn't obvious to the developer, and it may need a considerable refactor to fix.

If the software is tested thoroughly, the chances of these scenarios happening are considerably less.

Clean Code Design

This is an interesting benefit, but is one that I'm most familiar with since I'm in the code daily. For a software product to be properly tested, it also needs to be designed and written to be test friendly. I don't want to dive deeply into this topic in this post, but I'll go over some of the main points.

Software can be tested at various levels, and these are some mentioned by Kent C Dodds who has a course about testing javascript code. I'm using my own words to describe them.

• Static: Using editor tools to help the code be clean from the start. This helps catch the simplest bugs.
• Unit: Testing the smallest pieces of code in isolation. Like testing a single function or class for its expected behavior at the simplest level.
• Integration: Testing multiple pieces (Units) of code together as one.
• End to End: Testing the app like users would (Just like manually clicking through the application to make sure it is acting correctly)

In order to test code at the Unit level, the code must written in a way that it can be tested in isolation from the rest of the code. For example, if you want to test a function that displays a name a certain way, you don't want to also get the name from the database, render a page, and update records. You want to have the code's concerns separated enough to do just one thing so you can test just that one thing.

Integration tests would be similar, just at a higher level. The concerns should be separated enough so the system can test ONLY the feature being worked on. Maybe it is best to leave out the 3rd party APIs for this kind of test, so the code should be written so it can be tested that way without calling those particular APIs.

A great benefit of having clean code with separated concerns, is a developer will have a better idea of what is happening when reading through it. Separation of concerns allows the developer to not have to understand the entire system as a whole before they can start making changes and fix that bug.

Features can be explained

Everyone involved with building or supporting the software should be aware of the feature and what it will do.

The great part about having to write tests, is that a developer has to understand the feature in order to test it. This means all teams involved from design, to programming, to QA, to customer support, all need to know what's going on so the expectation is clear.

Before developers start on the feature, there should be an explicit expectation about what it should do. That way a test of the feature can cover exactly that, it runs the software and expects the result of the feature to be what the developer tells it to be. The clear expectation should have been agreed upon by those requesting the feature. If it isn't clear more discussions are needed. If unclear expectations of a feature are given to a developer it will be impossible for them to write a proper test for it (and to build the feature correctly anyway).

The process of writing tests can also help discover unknown scenarios surrounding the feature. It's likely that Customer Support employees may be questioned about these scenarios. I've run into plenty of "what if..." questions during development that nobody considered before production started. After these were found, they could be distributed and discussed to all teams to keep things clear for everyone.

In summary of this section... By discussing feature expectations and writing proper tests, all the teams involved will gain a better understanding of the scenarios that exist inside of the software.

Costs

Hopefully you've been able to see some of the benefits of testing software, but what are the costs to getting this all going? Mostly time, education, and money

Time

This one is hard to swallow if you're just getting started with testing and already have an application in use. Sometimes the amount of time it would take to "just fix" a problem would be minutes, but if a test needs to be written in software that's not designed with testing in mind, it could take hours or longer... So it's obvious that a manager would hesitate to allow the time for testing. They have other things they need to deliver and get done.

There is not one-size-fits-all answer of how to convince management to allow the time, but I would say the up front time IS costly, but the time NOT SPENT rehashing future issues will make up for it in the long run

Education

There are many courses and tons of technologies to learn in order to test your whole application. You will need to invest in learning, on or off the job, to be able to do it effectively.

Each programming language will have its own tools and libraries for writing tests, so you will have to research what fits best for your software and team.

Money

Some testing may require a whole new infrastructure to support it. This should definitely be part of the considerations and discussions.

For example, entire testing environments can be set up with databases, APIs, etc, so the entire application can be tested from End to End. Basically, everything is set up like your production app, but just for testing and keeping data isolated. (Though, depending on set up, it may only need to run during the tests running time so cost can be minimized)

Conclusion

Automated Testing... I feel like the benefits far outweigh the costs!

• Static Tools: Help me avoid simple mistakes and typos
• Unit Tests: give me confidence that I wrote good code
• Integration Tests: give confidence that other areas don't break because of my changes
• End to End Tests: MORE CONFIDENCE

Not all developers write all levels of tests, as I've written mostly Unit Tests. Sometimes entire teams write Integration and End to End tests, like qualified Quality Assurance Engineers who specialize in it.

I love that when features are properly tested, I (as a developer) don't have to worry about unknowingly breaking something that I didn't intentionally touch.

My suggestions for you...

If you aren't testing your software or application currently, I would urge you to look into how you can get started at any level. You'll love the confidence it gives you.

If you want to learn more about testing and what it can do, I'd check out testingjavascript.com, and expand your research from there. Though it is a JavaScript focused page and course he does explain the benefits very well on that site, so read over his reasoning of why testing is great if nothing else.

So Many Ideas

What should we spend our free programming time on? We only get a finite amount of it, so we shouldn't make the decision too lightly. But, in my opinion, we should definitely have fun.

I have had many software ideas over the last weeks, but I haven't yet started down the path for any of them... I am having a hard time deciding what I actually want to focus on, for learning and content to share. If I start down one path will it be the right one, will I get bored, or will it work out really well and everything will be amazing? The only way for me to decide what to do is to actually think through what options I have, so, here they are.

One thing I have to keep in mind is that I'll soon be changing jobs, so that weighs heavily into my decision.

Idea 1 - Card Collecting Software

Lately, I have been getting back into the hobby of collecting trading cards. Because I've been so excited about it, that's where my mind space has been. I've taken a trip down memory lane with Pokemon Cards, and I've been introduced into the current state of the hobby. While collecting cards there are many things you need to track, manage, and organize if you want to have a well kept collection.

Unfortunately, when figuring out the state of my old cards I spent quite a bit of time putting cards into a binder, taking them back out, and placing them back into the binder again... I've gone through a few different organizations of my binder because I didn't realize fully what cards were in each set. I'd love to have a good piece of software that would help me organize it right the first time.

The great thing is, these needs fit naturally with what software can do. Here are some of the ideas I've juggled in my head, but haven't seen done very well in any tracking system I've tried so far.

• Advanced Sorting
  • Rarity (Rare, Uncommon, Common, etc)
  • Printing (holographic, reverse holo, normal)
  • Type (Fire, Water, Grass, etc)
  • Set (Base, Jungle, Fossil, etc)
• Collection Tracking (mark as have when you physically have it)
• Estimated Collection Value
• Marking cards as "wanted" with a reason
• Images
• Marking your cards to be a certain condition (and condition explanations)

Idea 2 - 2D Game Development

The reason I actually got into programming was potentially getting into game development some day. Way back in the day playing StarCraft I built custom maps, and used their trigger system to create special events in the game. These gave me a taste of what if statements were and how programming worked in simple terms without realizing it was programming at the time.

I thought it was soo cool to imagine an effect of something happening based on a condition, and then to actually see it play out in the game. Now I have that same desire, but to create my own game entirely rather than a piece of one.

I have already purchased Game Maker Studio 2, followed a few tutorials, and gotten a taste of what it's like to make some 2D games in the software. And, it feels good! Who doesn't want to create their own game, that just sounds awesome, right?

The problem? There's a lot of work involved, but that also means I'll be able gain some very unique skills to games. Anyway, here's what I'd have to do for games.

• Design Work
• Art
• Sounds
• Music
• Specific Programming Language (Game Maker Language)
• Game organization and performance considerations
• Other unknowns

I'd love to create a game, but there are a LOT of unknowns so I don't know if this should be my primary path or not. At least, maybe not when I'm hopping into a new job position soon.

Idea 3 - Job Skills

Of course, learning is always important for your current job position. If you're not actively learning new things in your position you may start to feel stale, and it can affect your performance in your assignments.

I will soon be changing jobs, which is exciting! It also means I'll be changing what I'm using from day to day. Currently I've been using front end React, css, and HTML pretty much exclusively. In my new role this will change, and I will be touching all sorts of different technology on the front and back end.

So... Maybe it's wise for me to wait a few weeks before diving in too deep with either of my hobby paths, and go down the professional path to improve my job performance right from the start. I love jumping in to new projects and new tech, and sometimes it takes some extra learning before you can really be effective.

I have a track record of being able to jump in and get going quickly, and this would be a great path to accelerate that even more, and would provide these benefits overall.

• Fast Start to a new job
• Practice with new tech
• Validate my on the job skills
• Greater Confidence
  • Confidence in myself
  • Confidence of my Employer in the decision to hire me
• Provide value to the company

So Little Time

We all have lives, and every waking hour shouldn't be spent at the computer. I want to enjoy hobbies, family, friends, and solo time. The greatest challenge is balancing the time to get what you want out of it, and where to include skill improvement and hobbies like programming. Here are some pros and cons of where I should spend some of my free time.

Prioritize Hobby Software?

Pros

• I may be able to enjoy my card collecting even more! As it's on my mind, this would be an immediate reward for me, the passion for it is already there.
• I have multiple friends who might also benefit from it (real testers!)
• If I create a game, I can share in the fun with family and friends
• I may find strategies in these projects that are useful for my job, while having fun.
• My brother is also interested in building games, this could be a way to bond with him AND to gain some new skills.
• So much fun to be had!
• There is a chance I could learn some hard skills to transfer to my job as well.

Cons

• I might regret not spending more time learning targeted career and job specific skills to perform better in the new position. When jumping into a project for the first time I've found there are always strategies or new tech to learn and become familiar with.
• While working I might find my mind wandering to my hobby projects instead if I dive in too deep.

Prioritize Professional Skills?

Pros

• Better job performance
• Less stress when learning the projects
• Less post-job-day stress, leisure time will be more rewarding
• A hard days work earns a good days leisure

Cons

• Card collection management might be slower
• I probably won't get a game created too soon.

Pro and Con Summary

I've included a sample of my thoughts above, so hopefully you get the idea. There's a lot to consider when plotting out your time. There are only a few moments in each day, if any, that can be spent toward personal projects. I've got to juggle a few younglings, a house, time to spend with my amazing wife, etc, so what should I spend my time on?

Which Idea - My Conclusion

There are books to read, tutorials to follow, and unlimited amounts of things that can be learned, but what brings the biggest win right now?

Luckily, I've got a few weeks before my new job starts, so in that time I will enjoy my hobbies. If I can manage it, I'll spend some time making some games, or creating a collection management program. Most of it depends on how involved I can get my brother in the process of making games.

Either way, I'll focus on the biggest win and reward for me at this time. Once my new position starts, I'll re-evaluate so that I'll be able to perform at my new job the best that I can, I'm really looking forward to it!

Summary

This post will have a few short sections.

• Example Code - showing a few similar pieces of code that could be refactored.
• Using VS Code's Compare Feature - This helps you visualize what is actually the same in two different snippets of code.
• Move Similar Code to a Function - This shows the refactored version of the code.

Example Code

Here is a snippet of code, note, it hasn't actually been tested or used, but is for an example. Two main sections, both loading data into elements on the page. You may notice that the code is essentially doing the same thing in both sections.

// loading super nintendo console
const snesData = {
    description: "Super Nintendo Entertainment",
    games: [
        {title: "Super Mario World"},
        {title: "Donkey Kong Country"},
    ]
}

const snesDescription = document.getElementById('snes')
snesDescription.innerText = snesData.description

let snesGamesList = document.createElement('ul')
snesData.games.forEach((game) => {
    const gameElement = document.createElement('li')
    gameElement.innerText = game.title
    snesGamesList.appendChild(gameElement)
})
const snesGames = document.getElementById('snesGames')
snesGames.innerHTML = snesGamesList.toString()


// loading nintendo 64
const n64Data = {
    description: "Nintendo 64",
    games: [
        {title: "Super Mario 64"},
        {title: "Donkey Kong 64"},
    ]
}

const n64Description = document.getElementById('n64')
n64Description.innerText = n64Data.description

let n64GamesList = document.createElement('ul')
n64Data.games.forEach((game) => {
    const gameElement = document.createElement('li')
    gameElement.innerText = game.title
    n64GamesList.appendChild(gameElement)
})
const n64Games = document.getElementById('n64Games')
n64Games.innerHTML = n64GamesList.toString()

Using VS Code's Compare Feature

It would be nice to visually see what exactly is different between the two sections, and VS Code provides such a feature.

In order to use the feature, do the following

1. Copy the text of the first section into a new file (you don't have to save it)
2. Copy the text of the second sections into a new file as well
3. In the top left of VS Code, you can see your Open Editors (files). You will see your two unsaved documents listed there.
4. Right click one of them, and select Select for Compare
5. Right click the other one, and select Compare with Selected
6. A new two-paned editor will open showing you the changes between the two files.

You can see in the image above, that it highlights the words and lines that are different between the two. Using that information as a hint for yourself, you can then refactor both sections of code in a way that you see fit.

This is a very simple example, where a lot of the lines are similar. In other real world scenarios it might not be quite as obvious, and there may be extra lines in the left file that don't exist in the right and vice versa. The idea behind the feature and this strategy is to be able to quickly observe the differences without painstakingly reading each line of both sections.

Move Similar Code to a Function

For my code above, I'm able to refactor it to this based on the hints in the two panes.

const snesData = {
    description: "Super Nintendo Entertainment",
    games: [
        {title: "Super Mario World"},
        {title: "Donkey Kong Country"},
    ]
}

const n64Data = {
    description: "Nintendo 64",
    games: [
        {title: "Super Mario 64"},
        {title: "Donkey Kong 64"},
    ]
}

updateConsoleInformation('snes', 'snesGames', snesData)
updateConsoleInformation('n64', 'n64Games', n64Data)

function updateConsoleInformation(consoleId, gamesId, consoleData) {
    const descriptionElement = document.getElementById(consoleId)
    descriptionElement.innerText = consoleData.description

    let gamesList = document.createElement('ul')
    consoleData.games.forEach((game) => {
        const gameElement = document.createElement('li')
        gameElement.innerText = game.title
        gamesList.appendChild(gameElement)
    })
    const gamesElement = document.getElementById(gamesId)
    gamesElement.innerHTML = gamesList.toString()
}

You can see in the above snippet, that I was able to entirely eliminate a section of DOM related code. The hints provided in the two-paned comparison show that most of the code was actually duplicate, but just different variable names, ids, and data. So, I threw those differences into a function via the parameters.

Conclusion

When you see a few pieces of code that look fairly similar, and you want to know at a glance what actually is duplicate, give VS Codes compare feature a try.

Summary

Duplicate Lines

Duplicate Functions

Duplicate Modules

Duplicate Lines

The most frequent kind of duplication that I've seen is lines of code within the same file. More often than not, they aren't quite "duplicated", but they are changed just ever so slightly from each other.

Take this as an example, where we want to disable a few buttons, and the only difference is the ID being used in the selector. Everything else is the same, repeating the document.getElementById multiple times along with other logic that looks repeated.

document.getElementById('bigButton')
    .disabled = true
// other duplicated logic

document.getElementById('medButton')
    .disabled = true
// other duplicated logic

document.getElementById('smallButton')
    .disabled = true
// other duplicated logic

When I see code that looks similar like this my first approach is to create a reusable function to simplify the file. It makes it look more like this:

function disableButton(id) {
    document.getElementById(id)
        .disabled = true
    // other duplicated logic
}

disableButton('bigButton')
disableButton('medButton')
disableButton('smallButton')

Now there's no need to re-read through all that logic multiple times each time you have to edit the page. You can read the function, and then just read where it's used.

Now, there are multiple ways you could handle this code, it all comes to preference and need.

• As a first step, you can always find and keep the similar logic, put it in the function, and add parameters for the parts that change.

• Since the logic that's going on is exactly the same, you could even have the parameter be an array of ids to operate on and create a loop in the function instead of calling the function multiple times.

  function disableButtons(ids) {
    ids.forEach((id) => {
        document.querySelector(id).disabled = true
        // Other duplicate logic
    })
  }
  disableButtons([
    'bigButton',
    'medButton',
    'smallButton'
  ])
  

• You could use querySelectorAll to get a list of Nodes you can iterate through to disable.

• etc.

A lof of the decision just depends on your specific application, but personally, I feel that de-duplicating lines in at least one way is always worth it for readability, and maintenance reasons.

Duplicate Functions

Sometimes when you are reading through code, and writing some of your own, you'll find that there are multiple functions doing the exact same thing, but they are declared in different places and named slightly different. The problem comes in when both are actually used in various places.

Following our example above, lets say we have two functions that are disabling buttons and running some other code, that take the string id as a parameter.

function disableButtonById(id) {
    ...
}
function disableButton(id) {
    ...
}

Having two functions like this will just be confusing for a developer to maintain. If I encounter this situation I have multiple questions going through my mind

• Which one is most current?
• Which one should I use?
• Are both of these used?
• Why is one better than the other?
• etc.

To reduce duplication you'll have to deprecate one, and choose to use the other one. One strategy I've used to resolve this is to function wrap one within the other and then mark the deprecated one as deprecated.

// This is more descriptive, let's keep this
function disableButtonById(id) {
    ...
}

/**
* @deprecated - use disableButtonById
*/
function disableButton(id) {
    // Remove all previous code and call
    // the function you want to keep.
    // Once you've tested that this doesn't
    // break anything of course
    disableButtonById(id)
}

With this strategy, you can take an incremental approach to removing the usage of the old function. If it's simple enough you could just remove the one and keep the other without the deprecation and function wrapping, but sometimes the scope of your task just doesn't allow you to do it all at once. Or, the usage of the function is a public API so just removing it would be dangerous for your users.

You'll need to take care to test all areas as you deprecate it's usage, and then plan to chop the function out of your code in a future version when all code has been moved to the direct usage of the chosen one.

Duplicate Modules

With this one, I don't mean two of the same module, but rather two modules that solve the same problem. It's very possible that you could remove one and not the other.

This one is a little more tricky to handle, and it will come down to coordination with your team. Sometimes people prefer certain packages, but to reduce your code's bloat, you'll need to come to a decision of what to keep, and why.

• Is it worth cutting one of the modules that solve the same problem, or do they have unique situations that it's worth keeping both?
• Is the module size worth fighting over?
• Is it just a dev dependency, or is it bloating up your production application?

The main point here is, communicate what duplication you see and question the choices that have been made if you're not sure. You might end up reducing your code when you do. Chances are, no one knows why it is included if you are in an older code base, so questioning it will lift the whole team up.

Conclusion

I went over Line Duplication, Function Duplication, and Module Duplication, and some strategies I've been involved with for resolving them.

I love when I can clean up some code, and most often, it's all about reducing duplication, get out there and have fun reducing your code!

Before code has been written

If you already know you will want to put a new project in GitHub, creating the repository from GitHub itself is very easy. All you'll have to do afterward is clone the project from GitHub onto your device, and then you can code locally and push your changes to GitHub in the cloud.

1. Navigate to GitHub and sign in.
2. Create a new repository. At the time of writing there is a + symbol you can click on the top right, and choose New Repository
3. Provide a new repository name that will identify your project
4. Choose public or private depending on your preference
5. I'd recommend adding a README file, unless you know for some reason it will cause you issues. Check the box to create the repository with a file. Eventually this file should describe your project, how to get set up, and any meaningful notes about your project.
6. Finally, click Create Repository

Now GitHub has a git repository ready for you to start working in, you just have to get it locally on your machine. You do this using the git clone command. You should have been taken to a page that shows your new git repository's information. What you need to find is your git repository address. You can find it in a few ways

• Address Bar of Browser: use the URL of the page, and add .git to the end
• Look for a Green Code Button (at the time of writing): clicking on it should reveal your repository address, with .git already added to the end of the URL, copy that to your clipboard.

The address you find will look something like https://github.com/codingLogan/temp-test.git Using that address, you can now git clone your repository to your local machine.

1. Open a terminal and navigate to a folder that you'd like your project to exist in.
2. Run the following git clone command

   git clone <address-of-git-repository>
   

For me it would look like this

git clone https://github.com/codingLogan/temp-test.git

1. You should now have a folder named the same as your repository.

You can open up that folder and begin coding as you would normally, making commits, branches etc, using git. The only difference now, is you can use git push to get your local changes of your current branch up to GitHub.

After code has been written

In this situation you've already been coding locally and you have a set of files you want to get into GitHub. To get this project into GitHub, you just have to be sure it's being tracked locally by git, and also create a repository on GitHub to push to.

(Pre-requisite) If it hasn't been done already, you need to be tracking your files in a git repository locally before you can push them to GitHub. Navigate in the terminal to the root of your project and run these commands.

git init
git add .
git commit -m "First commit"

Now your files are ready to be pushed to GitHub, so let's set up a repository for GitHub to track it.

1. Navigate to GitHub and sign in.
2. Create a new repository. At the time of writing there is a + symbol you can click on the top right, and choose New Repository
3. Provide a new repository name that will identify your project
4. Choose public or private depending on your preference
5. (important) Be sure to NOT ADD ANY FILES when creating the repository on GitHub. You'll run into conflicts with your local files if you do
6. Finally, click Create Repository

Situation Review

• You have a blank repository on GitHub
• You have a local git project you want to push to GitHub

To push your project up into GitHub, use these commands, which are actually provided to you on the GitHub website as well. This will connect your local project with your remote repository in the cloud. (It also renames your current branch to main and then pushes up the branch named main to GitHub)

git remote add origin <address-of-git-repository>
git branch -M main
git push -u origin main

Now, you can continue editing your files, making commits, new branches, and then use git push to put your changes into the cloud.

Summary

I showed two scenarios which you may be in, and how to set up GitHub for them.

Before project code has been written

• Set up GitHub first (create at least a README.md)
• Clone that repository locally and start working

After project code has been written

• Start tracking your project locally with git
• Set up GitHub with a blank repository
• Push your project up to the blank repository

Overview

Here are the sections of this article

End Goal

The Component Tree

Lift State Up

End Goal

The goal of this post is to show how you can communicate between two different depth child components. I want an event fired by one child component to trigger a specific action on the other child. One way to do this is to create some form of state in the parent component that both children can access via their props.

I'm using this pattern to create a set of controls that are always visible to the user (up, down, left, right, accept, and decline buttons), but depending on the current Screen and the currently active item on that screen, those actions can behave differently.

For clarity, in a recent project I'm emulating a old school GameBoy interface, which is pretty unique, but I'll try to expose the fundamentals of the pattern in this post so it is useful for all cases.

The component tree

Let's assume we have a component tree that looks like this

[Parent component]
  |           |
[Controls]  [other children]
              |
             [Screen]

Components

• Parent: Holds the state of what items are available for navigation, and creates a handler function to pass down to children so items can be interacted with.
• Controls: Child of Parent who's specific purpose is to fire an action. The example I'd like to use in this post is firing a "move down" event when a button is clicked.
• Screen: Creates the items you can interact with, and renders them.

Example event desires

Ok, so lets think through what we want to happen. On my Screen, I want to have a "currently selected item", and when the down button is pressed on the Controls, the active menu item should move to the next available item if it can.

Visually...

first menu item <-- active
second menu item

Pressing down

first menu item
second menu item <-- active

Ok, looking at the two components we want to interact, we have these two specific things we want to happen, but they aren't hook up to work together yet.

1. Controls component fires "down" event
2. Screen should create a list of items to interact with and render them, and re-render them when the active item changes

Lift state up

Let's play matchmaker and get these two components "hooked up". To do that we will use the lift state up strategy. These components need to interact with a common piece of state that we'll place into the parent component.

Parent

On the parent we are going to do two things.

1. Set a piece of state in Parent called "navItems", and we'll pass this state as a props to Screen
2. Create a downHandler function that we'll pass to Controls as a prop so it can fire the event

navItems: Object containing the list of items you can navigate through, and the currently active item's index.

downHandler function: This function will be called by Controls to signify the "down action" has taken place. The items state will be used in the function to determine what the effect of that action should be.

Code snippet for Parent

const [items, setItems] = useState({ activeIndex: null, items: [] });

const downHandler = function () {
    if (navItems.activeIndex < navItems.items.length - 1) {
        setNavItems({
            items: navItems.items,
            activeIndex: navItems.activeIndex + 1,
        });
    }
};

Parent markup snippet

<Controls
    downHandler={downHandler}
/>

Notice, we are not actually setting the items to anything but an empty array. It will be up to the Screen to do that. All we are doing in the function is changing the active index to be the next one in the list if we can.

Controls

Use the handler function (which should be passed as a prop) from Parent in your markup. This will make Controls call the function that is defined Parent.

function Controls({downHandler}) {
    return (
        <button onClick={downHandler}>Down</button>
    )
}

Screen

Ok then, Screen needs to set the items that are available, while also accepting the items from the parent so it knows which one is active.

(side note - As I am writing this I'm realizing that the Screen component probably only needs the index information passed to it from the parent, not all the items, I'll play with that later)

Here's a snippet of the setup for Screen

function ScreenContent({ navItems, setNavItems }) {

    // Define the items that should appear on the screen
    const initialItems = [
        {
            text: "View Games",
        },
        {
            text: "Borrowers",
        },
    ];

    // Only on FIRST RENDER, set the initialItems on the Parent
    useEffect(() => {
        setNavItems({
            activeIndex: 0,
            items: initialItems,
        });
    }, []); // This empty array signifies the "first render only"

    // Render the list of items
    return (
        <>
            {navItems.items.map((item, index) => (
                <p className={navItems.activeIndex === index ? "active_item" : ""}>
                    {item.text}
                </p>
            ))}
        </>
    );
}

Conclusion

And there you have it. You have two separate children of Parent talking to the same data through their parent.

We set up a Parent component with

• a handler function to pass down to children
• a piece of application state, that the handler uses, and the other child component consumes.

I hope you found this useful in your React adventures. This is just one way to set of sharing state, as there are other ways like using the Context providers as well. But, this is how I achieved what I needed for my little side project that I'm having a blast with.

Go out there and have fun with React!

Summary

There are three main points I bring up in this article

• Be practical
• Don't get too comfortable
• Keep learning

Be Practical

There are so many ways to create things as a developer, and there is not one right way to accomplish anything. Rather, there are infinite ways to create a feature and it is up to you to balance the effort of your chosen path with the requirements of your project that you've been assigned. You need to ask the right questions to multiple parties as you continue moving forward working on your assignment. Be sure to gather your requirements, execute on a minimum viable product, and then polish and improve on what works.

Gathering requirements is absolutely critical to the work you will doing for the next chunk of time. Many points of the success of the project depend directly on having accurate requirements when you start. One way to gather good requirements is to get enough details so that you understand exactly what problem is going to be solved by your work. If you can't describe the problem, how will you come up with a good solution? Frequently, you will also be asked "how long will this take?", and you can't answer that question at all without understanding the problem. So please, gather good requirements, and don't start work or promise a deliverable until you understand the problem. (yes, this has happened for real in the past, and it's not fun to deal with)

Once you have valid requirements create an MVP (Minimum Viable Product) as soon as you can. Also, know that estimation is ALWAYS hard to get right because there are so many paths you can take. You will always be wrong, and that is ok. Your first goal after giving an estimate to a stakeholder should be to create a MVP. What this means is that it solves the problem, even if some of the bells and whistles are missing. Maybe the styling is off a little bit, or maybe that one extra feature hasn't been implemented yet that they asked for. That's ok at this point. At first, you just want to solve the core problem and then add to it.

A frequent problem I have had here, is that I get stuck in doing a project the right way, the industry standard way, or the popular way, etc. My best advice is to do what feels like it will work for the MVP. If needed you can always refactor your code later because no software is ever "done". It will get changed and reviewed by you and others later anyway. Your job is to deliver a solution to a problem, so focus on that one thing first and try to not get hung up in the "right way". The stakeholder cares more if the problem they have is being solved.

Polishing your code can take some time. You can refactor your code, write tests, and restyle your components all day long, for weeks, or months. Pump some extra estimation time into the project for all the back and forth that you'll do here. Hopefully by this point, your project has solved the core problem, and it is mostly deliverable already. Use your time to make it feel good to you in the code, rename variables so you can code search more easily later when you find a bug (trust me, it will happen). Make it as easy for your later self as you can. If it feels dirty, clean it up, you probably won't know how to read through it later if you can't even read through it now.

In a few bullets, let's summarize

• Remember to gather your requirements for more accurate estimation
• Build an MVP and don't overthink the design too much. Find something that will work and commit to it.
• Polish with the remaining time that you have, clean it up for your future self and other developers.

Don't Get Too Comfortable

This sounds like a downer section, but it does have some good pointers at the end at least. These opinions may reflect only my specific experience, and might not be the same for other companies, so take this section with a few "grains of salt".

This was one of the hardest lessons I've learned in my career. DO NOT get too comfortable with your great position at any company. Once you've landed a job, don't sink in and forget about yourself outside of that position. If a company has a need to let people go, for better or worse, they won't hesitate to keep their business flowing without you in that position. Finances win in a business, and if you're making too much of a dent on their payroll, cuts will be made, and you have to be ready when that happens.

Something to consider...

Companies hire you with many promises and benefits coming your way.

• They might say over and over how great they treat their employees.
• They promise that you'll "be taken care of", and that they treat employees like family, etc.
• You might receive many great benefits that you feel like you couldn't live without.
• On site gym, insurance, etc...
• Competitive Salary
• The list goes on

All benefits grouped together are just Golden Handcuffs, and you have the power to wear them, or not, you have the key. A company keeps you employed by enticing you with these things that are very desireable to have, so you may willingly keep the handcuffs on, and I kept mine on for too long.

There were multiple times where I considered moving positions, mostly just to try something new because I was starting to feel stale in my position (I wasn't learning much of anything new). But, every time I was really thinking of leaving I'd somehow get a raise or a promotion, or I'd consider the value of the Golden Handcuffs and decide I was fine where I was. I felt like the company really valued my work, and in turn I felt very loyal to the company. They were taking care of me, and I was doing my best to push the company forward.

But, hard times came, and I was ultimately let go, even though I thought I was actively making a difference and that they said they were very appreciative of my work. This can happen to the best and worst of employees, and it was a complete shock to me and my family when I came home jobless. I was not ready for starting a job search... So I want to share some tips to avoid the pain that I went through.

My tips for avoiding some of the harsh reality of being let go when you thought you were safe and comfortable

• Always be ready to enter the job market, comfortable job, or not
• Practice software development OUTSIDE of work (all my portfolio work was in private repositories so I had nothing to show to potential employers...)
• Create and update a public portfolio to showcase your best work
• Journal or blog about what you've been learning

Your goal in a job application, or interview, is to reduce the risk a company takes in hiring you, so show your work and progress in any way that you can!

Keep Learning

The biggest game changer of my entire career, which has completely changed how I feel about myself as a developer, has been creating a habit of daily developer practice outside of work and blogging about it. The goal here is that you are able to share all of that development experience with potential employers once you hit the job market again. Don't stop learning, once you do, you'll get comfortable, and as I explained up above, getting too comfortable can be a scary situation if the stars align wrong.

I try to work on side projects before work, for 1 hour a day. Do what works best for you, but find a good consistent time so you are always improving yourself and improving your marketability.

Ok, so, you want to keep learning, but what should you build?

• Build something that provides you with experience in the tech you're interested in.
• Solve a problem you currently have, with code
• Do extra practice similar to a difficult work project so you can excel during work hours (might get you noticed at work).
• Combine a non-technical hobby with tech. (Example, I created a parallax learning project with images of Pokemon Cards to figure out how perspective works in CSS).

If you can keep learning, you are employable, and companies will be lucky to have you.

Conclusion

I hope you were able to grab a few good tips from my thoughts. Just a a reminder and recap...

• Be Practical with your work
• Don't Get Too Comfortable at one position and company
• Keep Learning new things

As I do these three things, I'm finding myself happier and consistently becoming a more capable developer.

Cheers!

Summary

Recently I've been working on a project at work where I've been applying this 3d effect to a set of mountain ranges and some clouds, with a sunset gradient background. During it I ran into a few things that I'd like to share if it helps anyone else, including myself in the future.

Key Points of the article

Css Backgrounds should be applied to the parent that sets the perspective, otherwise you'll be painting the background in front of your other elements.

.parallax-parent {
    perspective: 1px;
    background: <your-gradient or color, or image>;
}

You can actually view the parallax examples in this post on GitHub at my pokemon-parallax repository. Look at the README and you can follow links to see those examples.

Firefox tip - If you are nesting parallax effects deeply for whatever reason, you MUST apply a transform-style: preserve-3d; to every div that contains parallax elements or you'll lose your 3d perspective. Chrome and Safari did not have this issue...

Intro To Parallax

Parallax is really just another way of saying that you've applied a 3d-like view to your page. As the page adjusts its scrolled position, the view and arrangement of the elements changes as well, as if you were in a real 3d environment. It's all about the perspective.

For example, if you're looking at a mountain and you are standing at its base, you can only see the mountain, and maybe taller mountains behind it.

But, if you have a drone up high, the perspective is up high, where you can see the front mountain, and down into some canyons, and you can see more of the back mountains.

In addition, if you are moving and looking at the mountain, things close to you appear to move faster than things that are further away.

These are the kinds of things you can achieve with CSS perspective or parallax.

Quick CSS To Start Using Parallax

This is a very minimal intro to get you started. If you want a really good article to learn how it works, check out Keith's Blog Post about Parallax. It's an incredible resource, and I don't want to copy his amazing content, credit is due where it is due and he's earned it.

To start using parallax there are a few things you'll need to set in CSS to get things rolling. On a parent element containing your 3d-viewable elements, you should set these properties.

.parallax-parent {
    perspective: 1px;
    height: 100vh;
    overflow-y: auto;
    overflow-x: hidden;
    perspective-origin: center center;
}

• perspective sets what depth the users view is at.
• height and overflow helps you set up a scrolling area so that you can see the perspective work. If the content of the parallax-parent isn't tall enough to need scrolling you won't see any of the 3d effects. Set these how you need them.
• perspective-origin is used to set where the user's "eye" would be viewing the images from. You'd adjust this depending on the desired effect, but center center is a good start.

Then on any child element that you want to be part of the 3d effect, you have to apply a transform that pushes it to a different depth away from the user.

/* Set layer to be same distance as user
   Example - close mountains
*/
.layer1 {
    transform: translateZ(0px);
}

/* Push this element further away from the user
   Example - further mountains
*/
.layer2 {
    transform: translateZ(-1px);
}

Have fun and play around with these, and checkout out Keith's article, it's really informative.

Now, to the problems I ran into...

The Background Problem

You have to be careful how you apply a CSS background. You may end up covering elements that have been pushed back further when you don't mean to. Especially when you apply a background to a group of 3d positioned elements.

Potential Solutions

• Move the background CSS to the parallax parent, or higher to get the background you want behind all elements.
• If you like the effect, you can create semi-transparent background colors to separate the sections.
• Have fun! Play with it until you like it.

The Firefox Problem

Firefox needs some hand holding to let parallax effects drill down into groups. If you have html markup like this, Firefox will not have 3d effects. But, Chrome will still work just fine.

<div class="parallax-parent">
    <div>
        <img src="bulbasaur.png" class="layer3" />
        <img src="ivysaur.png" class="layer2" />
        <img src="venusaur.png" class="layer1" />
    </div>
    <div>
        <img src="charmander.png" class="layer3" />
        <img src="charmeleon.png" class="layer2" />
        <img src="charizard.png" class="layer1" />
    </div>
    <div>
        <img src="squirtle.png" class="layer3" />
        <img src="wartortle.png" class="layer2" />
        <img src="blastoise.png" class="layer1" />
    </div>
</div>

So, what gives? After some digging, I found this gem in the docs on MDN that says

As this property is not inherited, it must be set for all non-leaf descendants of the element.

So, if we modify our above markup with a new CSS class for each grouping, it will fix Firefox, and preserve the 3d effect as expected.

.parallax-group {
    transform-style: preserve-3d;
}

<div class="parallax-parent">
    <div class="parallax-group">
        <img src="bulbasaur.png" class="layer3" />
        <img src="ivysaur.png" class="layer2" />
        <img src="venusaur.png" class="layer1" />
    </div>
    <div class="parallax-group">
        <img src="charmander.png" class="layer3" />
        <img src="charmeleon.png" class="layer2" />
        <img src="charizard.png" class="layer1" />
    </div>
    <div class="parallax-group">
        <img src="squirtle.png" class="layer3" />
        <img src="wartortle.png" class="layer2" />
        <img src="blastoise.png" class="layer1" />
    </div>
</div>

Conclusion

Parallax is a really cool effect to work with, and I'm still learning the tricks with it. If you have anything you'd add to a gotcha list for parallax building, I'd love to discuss them, I look forward to hearing from you.

Summary (you're welcome)

1. Create a folder for your project and run git init inside it
2. Run npx express-generator to create a basic Express app
3. Run npm install
4. ignore _nodemodules
5. Run npx create-react-app client to create a React client
6. Modify Express to serve React's static files
7. Create a root level package.json script to build client files, and run npm run build
8. Run your entire app with npm start.

In the end you will have a repository that is holding both your front end application AND your back-end server code. It makes for really easy deploys of your code because it's all in one place. This is how it will look at the top level when we're done.

bin/
client/
 |-node_modules/ (ignored)
 |-public/
 |-src/
 |-.gitignore
 |-package-lock.json
 |-package.json
 |-README.md
node_modules/ (ignored)
public/
routes/
views/
.gitignore
app.js
package-lock.json
package.json

There are improvements that could be made with this FOR SURE, but this should get you going like it did for me.

Read on if you want more details for each step.

Create your project folder

Lets start by creating a folder for our project and initializing it with git.

mkdir your-app-name
cd your-app-name
git init

Create the Express app

Now we need our express application, I found recently that you can generate one really quickly by running this command.

(note - the npx package runner lets you run commands even if you don't have the packages installed with npm. See this great article for more info)

npx express-generator

This will create a folder structure that looks something like this. Feel free to modify these files to your needs, but out of the box it's a fully functional Express server.

bin/
public/
routes/
views/
app.js
package.json

Now... this automated generation added the proper dependencies for your express app to package.json, but did not install them via npm. Install them now by running npm install

Sanity check, make sure it runs

Run npm start to start up your new express server

Go to http://localhost:3000/ and check to see if you get a friendly "Welcome to Express" message. If you do, you're good to go!

Git management

You'll want to create a .gitignore file at the root of your project to ignore various files... Specifically, for any npm project it's _recommended to ignore nodemodules, so let's add this to a .gitignore file so we're not saving tracking info for installed packages.

node_modules

At this point, you have a bunch of files generated for Express, and you should be ignoring node_modules, I'd recommend doing a git commit at this point but you do you.

Create a React client for your app

Creating a React app structure has been made easy (makes me feel spoiled), by running this command from the root of the project.

npx create-react-app client

If successful you will have a new folder in your project called client and it will have these contents

client/
 |-node_modules/ (ignored)
 |-public/
 |-src/
 |-.gitignore
 |-package-lock.json
 |-package.json
 |-README.md

Now, we're going to need to build the React app. For convenience, lets create a build script at the root level, that will go into the client folder and run the build.

Open up your root level package.json and make the scripts look like this

"scripts": {
    "start": "node ./bin/www",
    "start-client": "npm start --prefix client"
    "build": "npm run --prefix client build"
},

• start will run your Express server
• start-client will run your client only
• build will build your client files

I created the build and start-client commands on my own, and I'm not the most familiar with the syntax, but here's my shot at the explanation. The command work for the client because when you run an npm command with the --prefix flag it runs the command (in our case npm run) as if you were in the client folder.

Anyway, try it out, running npm run build from the root of your project should generate a new build folder inside of client.

Then run npm run start-client to see your React app running.

You can still run npm start and see your Express app running.

Make Express serve the react app

All you need to do to serve React's files is tell Express to look for them in the right place. This is all I've had to do so far in a simple React app.

Open up app.js and find the express.static( line. Make it look something like this, pointing to your React-built files

// Serve React's files instead of default public folder 
// app.use(express.static(path.join(__dirname, 'public')));
app.use(express.static(path.join(__dirname, 'client/build')));

Now when you start Express, it will first look for your /client/build/index.html file. If it finds it, it will serve React for you.

To validate everything is working run npm start and you will see React instead of Express

Notes on Heroku deployment

The additional scripts we added earlier will allow Heroku to build and start your server thats holding your React files. It looks for those two scripts when you deploy a Node project.

A few more configs

• To deploy to Heroku, they also want you to specify the Node version in your package.json, so lets add that.
• And, unless you add your client app as a dependency you'll get errors when trying to run the above build command. The root level package.json should have a dependency of your client.

  "dependencies": {
    ...other entries...
    "client": "file:client"
  },
  "engines": {
    "node": "14.x"
  }
  

When you update package.json with new dependencies be sure to run a fresh npm install to update your lock file accordingly. Push your changes to GitHub and you're ready to deploy.

1. Go to Heroku.com
2. Create a new app
3. Connect it to GitHub by choosing Connect to GitHub in the deployment method section
4. Then you can deploy it automatically or manually. Once you do, your app should be visible.

Troubleshooting

As I was learning how to do this Heroku was actually pretty helpful in showing me the errors. If you run into issues, watch the logging.

Conclusion

Getting a basic site up and running isn't that bad when you have good tooling available to you, and free hosting like Heroku.

We just created a (M)ERN app without the M in a few minutes.

If you want to use git, you must first install it by following the instructions at https://git-scm.com/

What Git is and is not

I want to start by clarifying a piece of confusion that I had when I first heard of Git years ago. Git is not the same thing as GitHub.

Git is a version control system. It keeps track of the changes to your files. As part of its tracking, it also provides you with an evolving history of each of file. What this means is you can look into the past and see previous saved "states" of your file, which is called a commit.

GitHub is just one place you can store your code in the cloud, there are many other options as well. To use Git, you do not even have to use GitHub, or any cloud service. What these services allow you to do is share your code and collaborate with other people.

In this post I am going to just cover what Git is, and in a future post I'll cover the basics of using cloud services to collaborate with others.

Why you should use Git

I stated this already, but the benefits of using Git are these

Changes are tracked

Once you've initialized a folder as a Git repository, Git tracks all of the changes to your files within that folder. "Changes" can be additional files, deleted files, more lines added to a file, lines removed from a file, etc. Any changes to the files in the folder will now be tracked for you. You choose when you want to save those changes to git by creating a commit. Git will now use that commit as it's "clean" slate to track what has changed.

I will go over creating commits later in the post.

Ability to see history

Every commit you make is accessible in the future. You can go back and view the differences between commits, or, if you want, you can actually get an old version of the file back on your system by using the checkout command.

This is the basis of how libraries and frameworks have multiple versions you can choose from, different commits are flagged as those versions.

Freedom to Experiment

By default Git creates a default branch called "master" or "main". With Git you can create as many branches of your code as you wish. Essentially, when you create a branch you are creating a new version of your code where you can make whatever changes you'd like, without affecting your previous work. This is useful if you want to add a new feature, or try something completely different. Often in practice a branch is created by a developer when they begin work on a particular task.

When work has been completed in a branch you can "merge" the branch back into the "main/master" branch so your work is all back in one place again.

Create a Git repository

To initialize a folder of yours as a Git repository, you can use this simple command while currently in the folder

git init

It will create a folder named .git, and that's where all the magic tracking information is stored. I have never had to dive into the folder, but that's how you know if a folder is being tracked by Git or not.

Track some files

When you're tracking files in Git you can have the files in a few different states

Untracked Files: Git will show you when files are completely Untracked.

Working or Un-staged Changes: These are files that have differences compared to the most recent commit or staged changes. You will typically only "stage" your changes when you are confident that the changes are what you'll want to save in a commit.

Staged Changes: These are changes that are being batched up in preparation to make a real commit. When you make a commit, you are telling Git to put all of your staged changes into a commit and save it to the history of your project.

It's worth noting, most developer tools will help you readily see your changes. When I work in VS Code frequently, there's a sidebar that shows me all of this information.

Tracking the state of your files

In order to accurately track files with Git, it's good to know how to check on the status of your new files, working changes and staged changes.

Use this command to see what files are new, deleted, or modified, or currently staged for a commit.

git status

If I use git status right now for this post I have in progress, I get this output showing that I have a modified file, and it gives instructions for how to stage or commit them.

codingLogan.github.io$ git status
On branch git-basics
Your branch is up to date with 'origin/git-basics'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   _posts/2020-12-07-git-essentials.md

no changes added to commit (use "git add" and/or "git commit -a")

If you want to review the actual changes made to that file, you use the git diff command. Honestly, it's kind of hard to read, but it shows additions and deletions made to the file. There are many tools that make viewing the diff much easier.

git diff <filename>

To stage a file to git for the first time or to stage a file's modifications use:

git add <file>

To unstage a file, Git shows that you can use

git restore --staged <file>

Once you have staged all the changes you want to save to Git history, you can commit them.

git commit

When you use the command like this it will open an editor to add a message to your commit. The editor may be different for you, but typically it's a vim editor

In order to write a message in a vim editor you'll have to do the following

1. Hit the "i" key to enter Insert Mode
2. Type your message
3. Hit "Esc" to exit Insert Mode
4. Type a ":wq" and hit Enter (saying you want to write and quit)

You can optionally give the commit a message from the command line

git commit -m "Finish commit example message"

Hide some secrets

What do I mean by secrets? Well, there are projects that contain secrets, or API keys, or passwords, etc, that are needed in order to communicate with other services. Sometimes these are stored in files in the project, which is ok, but...

DO NOT COMMIT ANY SECRETS TO GIT!

I'll say it one more time, I want to be sure it's clear... Saving secrets to Git will permanently save those secrets to Git's history. If you don't want the world to know your secrets, don't ever commit any.

PLEASE, DO NOT COMMIT ANY SECRETS TO GIT!

When a project needs to hold any secrets you should ignore those files and set them up manually wherever you need them. Luckily Git provides you with a mechanism to prevent you from saving them in Git.

Introducing the .gitignore file. The "." is part of the filename, as it's a hidden file.

A very fast example for you. Let's say we have a file named secrets.json, and we want to prevent Git from tracking it.

1. create a .gitignore file at the root of your project
2. Edit .gitignore and add secrets.json to it

    secrets.json
   

Now, Git will not tell you about changes that happen to that file 👍. (Phew... crisis averted)

Add a feature branch

Branches are basically different volumes of code. I like to think of branches like library books because you

• Can only have one branch checked out at a time, similar to library cards limiting you to a certain number of books.
• Check them out to start working on them
• Commit to them when you're done
• Checkout another branch.

Here are some useful commands with branches

To view all branches you have on your machine

git branch

To create a branch, but don't check it out yet, then checkout the branch with the second command

git branch <branchname>
git checkout <branchname>

To create a branch and check it out immediately, it's the same thing as running both commands above (I use this one all the time)

git checkout -b <branchname>

Here's a concrete example to create a branch called "fantastic-feature" and start working on that branch

git branch fantastic-feature
git checkout fantastic-feature

Remember, you can always verify what branch you are on by using either of these commands (I prefer git branch, but both work)

git branch
git status

Once you have created a branch, made some commits, and you feel the work is done, you are probably going to want to merge your code back into the "main/master" branch. Unless you want to indefinitely have separate versions of your code (like Linux).

Merge a feature branch

To get your changes into a branch we need to do a few things

1. Checkout the destination branch you want all code to end up in
2. Attempt a merge of your feature branch into your destination branch
   • (Maybe a future post) If the two branches have conflicting changes git won't be able to merge them automatically. When this happens you'll need to resolve the conflicts manually. This usually happens if both branches have changes to the same area of a file, so it doesn't know how to choose which change to keep.

Use this set of commands to merge your branch

git checkout <destination>
git merge <feature>

or concretely...

git checkout master
git merge fantastic-feature

Master will now have ALL of your work, congrats!!! 👏👏👏

Store it in the cloud

I mostly wanted to bring to attention what options you have for storing your code for collaboration with other people.

Popular choices are

• GitHub
• BitBucket
• GitLab I'm not too familiar with this one, but I've seen it around

Conclusions

I hope this post helped in explaining a few of the basics of Git for you.

• What Git is
• How to track changes
• How to create branches
• How to merge branches back together

What is 100DaysOfCode?

At it's core, it's a commitment to code for 1 hour for 100 days.

First, I'll say the official rules are at 100daysofcode.com if you want to check them out, but I'll summarize them here for you.

• Tweet the hashtag #100DaysOfCode to commit to the challenge
• It is recommended that you read this article to familiarize yourself with the purpose of the challenge.
• Make a rough plan for what you want to build during your challenge time
• Code for 1 hour a day for the next 100 days, and tweet your progress using #100DaysOfCode to encourage yourself and the community

If you actually read the article above they mention that they were NOT counting time following tutorials as part of their completion of the challenge. I have not applied that to my challenge, as I learn well from structured formats, especially in unfamiliar territory I've never touched in depth, like android.

Use the rules above as guidelines to tailor the best experience for you and your learning style, and have some fun with it! This primarily for you anyway. For example, I take a day off here and there to refresh my mind, but I get right back to it the next day. (I've got kids, an amazing wife, and real life to take care of too, can't always be coding, right?)

Challenge Benefits

I highly recommend all developers to accept the challenge, or a shorter version if 100 days is just too much, I'll leave that up to you. But commit, push forward, and learn! I've also connected with many developers that have also accepted the challenge on Twitter. The community on there is amazing, and very supportive!

The reason I wish I would have done this years ago, is because I was really feeling stale in my webdev position. I wasn't learning much anymore because all the tickets coming through felt the same day after day. But I was comfortable, so I didn't mind too much, but I should have. I knew I wanted more, I was hungry to learn, but I just didn't do anything about it. Accepting this challenge is keeping my inner developer entertained and curious about new technology, I love it!

Benefits

• Learn New Skills
• Develop Habit of Learning
• Time management
• Opportunity to experiment in code (outside of work)
• Networking with other challengers

My First 30 Days

In my career, I've been a web developer the whole time. I worked in the traditional LAMP stack for multiple years. Just recently, I've moved to a position using primarily javascript using React and a node back-end. Because I won't get asked to create an android app at work, I chose to learn android on my own during the challenge, and to learn kotlin along with it. Kotlin is apparently the choice for android development now.

I have been enjoying this challenge WAY more than I thought I would. It has taken my free time, and transformed a piece of it into productive developer time where I sharpen theoretical blade of skills every single day. Thirty days ago, I had never touched the kotlin programming language, and for the most part had not really touched android either. It's been multiple years since I've really done anything with Android. So I could just say that prior to the challenge I've "never" developed for the android platform... It was only during a school course, and used Java instead...

Anyway, now I'm using both of those technologies daily, and I'm creating small little apps just for fun! In particular, outside of tutorials I'm following, I created a small little app in an attempt to help me generate a new username. It was done in android using kotlin, applying everything I'd learned up to that point. It feels so cool to hold a phone that is running code that I wrote in my hands. I'm kind of getting addicted to the fact that my phone can be utilized for my designs! (...excellent...)

Is it a good addiction though?... I think so!

Looking Forward to Days 31 - 100

Most of my time so far has been spent in tutorials, but I learn really well that way. I have a very well structured tutorial created by Google that I'm following on Udacity to learn best practices for the android platform. I don't think I'll just happen to find the best practices that they're sharing on my own, so I'm going to continue all the way through it. Good exposure to best practices is priceless, and will help me in the long run.

One thing I will change as I go further into the challenge is to go tutorial free, like the original challenger did. I have a few ideas brewing and I'm looking forward to building more things of my own design, and encountering my own unique issues that I have to work through.

This has been a GREAT experience, I highly recommend, 10/10 I will do it again.

Getting Started

Starting to dive into unfamiliar tech can be overwhelming, luckily, there's really not that much prerequisite to getting started with Android.

What you need

Personal opinion, you'll want to have a computer that is fairly powerful and has plenty of RAM to spare. I've heard Android Studio can potentially be a resource hog, but it's not a requirement to have a beast of a machine.

Actual Needs

• Download the latest version of Android Studio
• Android Device - Android Studio does provide you an emulator if you don't have a physical device.

Create a Project

Once you've got Android Studio installed you can create a project, which, actually sets up an entire "Hello World!" for you with a layout file, a kotlin file, and more.

• Start up Android Studio
• Follow the prompts to create a new Project
  • For simplicity, start with a Blank Activity (it's as basic as it gets)
  • In one section of the options you can choose either java or kotlin, I'm choosing kotlin.
  • With your first app, most of the options can, and should, be left at defaults.

After you've created your first project it might take a few minutes to build as it sets up all the files. Once your files are all generated see Run Your App in Google's docs to get a device set up.

At this point you can hit the play button in the IDE and it will build, install, and launch your app on the emulator or physical device, whichever you have set up. And it will give you the all too common "Hello World!" on your screen, but it's really fun to see it pop up on your phone! (I use a real device)

File Structure

Once your project has built, you can finally take a peek at the file structure. For me, it helps to at least be aware of what the folders are, even if I don't need to touch them yet.

It's good to understand the magic going on so you can really own your project

In the left side of the IDE you'll see the files of your new project. You'll also notice at the top area above the files, it has a dropdown to select different views of the project's files.

• Project: Shows the files as they are in the filesystem. (This view is good to know about, but less useful in my short time with it)
• Android: Shows a friendly view of the various folders which house different content. Note - it's NOT the actual folder structure of the files on disk, it's just organized in this way to be useful for developers.
• (others I've not explored yet)

Moving forward in my Android experience I will be using the Android view as it seems to be the easiest to work with, until I find some reason not to.

Here are the essential folders to be aware of in your project (there are lots more).

• manifests: Essential app details the OS needs to launch your app.
• java: All kotlin/java code to control your app goes here
• java(generated): Files generated by the IDE, there's no need to modify these files
• res: Folders with resources you can use in your app
  • drawable: contains images/vectors
  • layout: contains xml files that describe screens of your app
  • values: contains strings, and other static values

Key Parts of Android

In the most basic app, I learned that there are really 3 basic building blocks to get something working in an Android App. There's the xml layout, the controlling java/kotlin Activity code, and optionally some resources to reference, like strings.

If you are in the Android View of your project they are in these folders

• xml layouts -> app/res/layout
• activities -> app/java
• resources -> app/res

Layout (XML)

This is where you actually build the components that the user will see. It's defined in XML, and there are many different components you can place into the layout. I will introduce you to a few by sharing my _activitymain.xml layout file so you can see what one looks like, but rather than seeing all the details, let's start without all the Android specifics.

Let's start by how you can think about the design of a layout. In a simple app, lets say we want just a few elements that appear 1 by 1 vertically

Paragraph of text
Image
Button to press and respond to

Now that we know what we want, we just need to search in the docs for what can give us the functionality we want. After finding the XML elements that match your needs lay them out in XML.

• LinearLayout gives me the vertical 1 by 1 I want if I place elements inside of it
• TextView shows text
• ImageView shows an image
• Button is an Android button for interactions

{% raw %}
<LinearLayout>
    <TextView/>
    <ImageView/>
    <Button/>
</LinearLayout>
{% endraw %}

Now that we know the elements we need, we'll need to research and fill in all the Android details, (or just follow a tutorial that teaches them to you 👍)

Here's what it looks like all filled out, some was boilerplate, some was manual injection by me, but it's important to see the structure is what I thought up before even thinking in Android's terms.

{% raw %}
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical"
    android:layout_gravity="center_vertical"
    tools:context=".MainActivity">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal"
        android:text="@string/roll_description"
        android:textAlignment="center"
        />

    <ImageView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal"
        app:src="@drawable/your_image"
        tools:src="@drawable/your_design_image"
        android:id="@+id/action_image"/>

    <Button
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal"
        android:text="@string/roll"
        android:id="@+id/roll_button"/>

</LinearLayout>
{% endraw %}

Very concise recap... We have a ViewGroup LinearLayout element, holding the other elements that give us the layout we thought up, now with Android details.

I feel it might be worth going over some of the android attributes, because when I see them, it feels overwhelming.

First, the root element of a layout can specify what namespaces are used with the xmlns attributes. I'm not going to claim I know a lot about these, but here's what I'm using in the LinearLayout (root) element so I can use the attributes from those namespaces.

• xmlns:android="http://schemas.android.com/apk/res/android" provides android attributes
• xmlns:tools="http://schemas.android.com/tools" provides build time tools, and the usages of it are removed from elements during build time of your app.
• xmlns:app="http://schemas.android.com/apk/res-auto" in my usage provides backwards compatibility for the ImageView to draw vector graphics. I followed the tutorial on this one, and definitely need to research to understand this more.

android attributes

• layout_width: the width of your element
• layout_height: the height of your element
• orientation: vertical | horizontal for LinearLayout
• layout_gravity: where to position the view/element
• text: display text
• gravity: helps align the contents of the view/element
• id: This is used to allow your kotlin/java code to reference the element to do something with it. If you want that button to do something, the id attribute is essential.
  • When declaring an id, do it like this _android:id="@+id/your_idname". Under the hood Android Studio will create an integer id for you to reference using the R class in your Activity code (I'll show you this later).

Activity (Kotlin)

An activity file is where you actually define the behavior of the app. For example...

• You can define what happens when a button is clicked by the user.
• Should text appear at the bottom of the screen confirming to the user that something happened?
• Randomly generate a number, like a dice roll
• etc

Ok, so at it's core, we want our user to click the button, and have something happen. You'd add something like this to your Activity in it's onCreate() method (probably app/java/[your package name]/MainActivity.kt if you just created your project)

// Using findById, get reference to a button
val actionButton: Button = findViewById(R.id.your_button_id)

// tell it what to do when clicked
actionButton.setOnClickListener {
    // Your actions go here, be creative!
    // Create a message
    // Change some text of an existing element
    // Generate a number
    // Have fun with it...
}

There are a lot of things you can do, I'll leave it to you to look up what's possible. If you want something simple, you could look at using a Toast() popup 👍

Resources (images/text)

I want to go over the two resources I used, images, and strings. The larger your projects gets, the more you'll gather up, so it's good to know how they're used.

Images

Images that you want to use in your app go in the drawable folder. Simply copy your images into the res/drawable folder and then you can reference the image in your layout xml files.

<ImageView android:src="@drawable/your_image" />

String Resource (located at app/res/values/strings.xml)

The strings resource files has contents like this, which you can either enter manually, or, you can use the IDE helper lightbulb to place it in for you (very handy).

<resources>
    <string name="app_name">Your App Name Goes Here</string>
    <string name="roll">Seek Your Fate!</string>
    <string name="roll_description">Each day of life is a roll of the dice... Make the best of it no matter what you get!</string>
</resources>

Use strings in your layouts like this. It will grab the string from the strings.xml file and place them into the view for you. This is nice because it keeps your xml layout file more concise, especially if you have paragraphs of text.

<TextView android:text="@string/roll_description" />

Gradle Build System

I mostly wanted to mention this because it really does feel like a magic box that puts everything together. Gradle provides these features for your app, I'll leave a link to their site at the end if you want to learn more.

• Target particular Android devices
• Compiles your app to executable code
• Dependency management
• App Signing for Google Play
• Automated Tests

There is a .gradle file for

• Each module of your app
• Your entire project

Industry Tips

There were a couple things mentioned in the Udacity course that I'd love to pass along.

1. Reduce Calls to findViewById. If at all possible reduce the calls to findViewById, it can be an expensive operation and cause lag if misused.
2. Always move strings to the resource file. The makes it easier to deal with all of your strings because they are all in one place, especially if you want to translate your app to other languages
3. View Binding - The instructor had notes recommending using this instead of using findViewById. They mentioned these advantages.
   • You get a reference to the full xml layout, and can still reference the id you need
   • Type Safety, you don't have to guess what type a view element is
   • Null Safety, you don't pass a resource number, so you can't guess wrong

Conclusion

That was a LOT of information, even as I read back over my post I realize how much of a wall of information it was. Hopefully you might have picked up a few things you didn't know before, let me know if you did find it helpful!

Learning Resources

• Udacity Course - Developing Android Apps With Kotlin
• Android Studio
• Gradle
• View Binding

Visual Summary of Moving your branch's base to another

Go from this

-(0)--(1)--(2) master
    \ 
    (R1)--(R2) rebase1

To This

You'll get something like this:
-(0)--(1)--(2) master
                \ 
                (R1)--(R2) rebase1

Bonus: after a clean rebase, you can merge rebase1 to master cleanly

You'll get something like this:
-(0)--(1)--(2)--(R1)--(R2) master

Steps Summary

• Make a feature branch
• Make commits on feature branch
• Make commits on master
• Rebase feature branch (move the branch start to the tip of master)
• Move the feature branch into master (merge, with no extra commit)

Exercise

Make a feature branch

Create a new rebase1 branch off of master

git checkout master
git branch rebase1
git checkout rebase1

Make commits on feature branch

Make a few commits while on the rebase1 branch. For convenience, make commit messages something like the following so you can easily follow your own messages from each branch

rebase1 R1
rebase1 R2
etc...

Make commits on master

Make a few commits on the master branch. This will allow us to see how our history moves when we rebase. Follow a similar commit message format

master 1
master 2

Stop and observe what your commits currently look like. You can use git log while on each branch to see the recent commits. I'm a very visual person so here's a diagram of what it should be

-(0)--(1)--(2) master
    \ 
    (R1)--(R2) rebase1

Rebase feature branch (move rebase1's base to the tip of master)

Rebase rebase1 to the master branch. What you're really asking git to do is "attempt to move the start of my branch to the current HEAD of master"

git checkout rebase1
git rebase master

You'll get something like this:
-(0)--(1)--(2) master
                \ 
                (R1)--(R2) rebase1

• Using git log while on rebase1 you'll see all 5 commits in that order

Move the feature branch into master (merge, with no extra commit)

Once you've done a rebase successfully with no conflicts, you can now do a merge and it won't leave any extra commits in your history since no additional change was made

git checkout master
git merge rebase1

You'll get something like this:
-(0)--(1)--(2)--(R1)--(R2) master

• use git log to checkout your commit messages if you want to verify this really happened

Conclusion

Using rebase properly can result in a very clean looking branch history.