Forem: Jon Deavers

Side Project Journey Part 4 – Back End Coding

Jon Deavers — Mon, 11 Oct 2021 18:06:47 +0000

In the previous post I laid out the scaffolding for my back end code. It took a little time to think through the code I would need. I referred to some past projects and a tutorial I had taken when I was first learning React. During the process of pseudo-coding there were a couple times where I felt like the effort was outweighing the eventual benefits. What’s the point of writing one comment line to describe another single line importing a model after all?

Pseudo coding

After completing the process, I felt different about that “extra work”. The result was akin to painting by numbers. Once I finished pseudo-coding, it only took a fraction of the time I would normally spend writing up a node API to get all of the pieces in place and functioning properly. I was able to cut and paste some code from older projects quickly and easily given that every piece of functionality already had a home in the document. The structure of the pseudo-code comments also made writing the completely new code blocks a breeze. The concept of what needed to happen was already in place, so I saved a ton of time in trying to think through the logic on the fly. Additionally, my code is much easier to follow because I left many of my pseudo-code comments in place or modified them slightly to explain what each piece of logic was doing.

In a real-world production environment, this may be overkill. I’m aware of the debate that surrounds comments and the addage “Write fewer comments by writing cleaner code”. The idea behind this phrase is that if your code is written well enough, comments become unnecessary because your code can speak for itself. I’m not sure I’ll ever fully adopt this mindset, as I find it much easier to not only understand what I’ve written but also to navigate the document seeing the comments acting as headers for each block. At least for my personal projects, I intend to continue writing comments that explain what is happening in each significant section and just let the compiler make up for my inflated file sizes. Here’s an example of my commenting practices in the server.js file:

Similarly, in my routes files, having this “roadmap” in place allowed me to think about some future development ideas and leave breadcrumbs for adding new features in the future. For example, since this app is designed to track progress in weight loss and blood pressure, it’s not practical for a user to easily be able to go back and edit or delete old entries. Ideally you would want your user to have that ability but place it behind a roadblock that requires the user to confirm they want to edit their history and be aware of those implications. Since that was outside the scope of my initial minimum viable product definition, I left room for it in the API and color-coded the future development notes using Better Comments VSCode extension.

Notice the route definitions on lines 16-18. This is a labeling convention I picked up by following the React Front to Back Tutorial by Brad Traversy. I mentioned his tutorial in the previous post and loved this idea of having detailed descriptions of each route so I’ve implemented it in my own API’s. Thanks Brad!

Postman

I’d love to tell you that server.js fired right up on the first try after finishing the coding process. I’d love to, but I can’t. A few oversights still popped up and I had to troubleshoot a couple of minor bugs in my routes before I got to this beautiful console message:

Now it was time to test out my API using one of my favorite tools in all of web development; Postman. Postman is a free (for solo developers) tool for testing REST API’s during development without having a front end client. You can download it here. I’ll write a post dedicated to using Postman in the future, but for this post, I’ll share some screenshots and give an overview of how it is used.

Postman allows you to create HTTP requests using a URL field similar to what you would find in a web browser like Chrome, Firefox, or Safari:

Sometimes these requests can get pretty complex and so as you develop your API you can save collections of requests and easily access them later as you update or modify your API.

Postman returns the body of your request in easy to read JSON format as well:

Side-note, Batman is a gracious alpha-tester for most of my API work.

Summary

Just like in the console previously, not all of my requests worked perfectly the first time. On the whole, however, this pseudo-coding process turned what used to be a day-or-three-long project into a functioning node server and REST API in just a couple hours. Next up, we bootstrap the front end client and pseudo-code the front end UI in React!

Publishing my first NPM package

Jon Deavers — Fri, 08 Oct 2021 16:33:21 +0000

For the past few weeks I’ve been working on a side project and documenting it in a series of blog posts. It’s been a pretty lengthy project so I wanted to take a quick break and write about my first experience publishing a package to NPM. The more I work in the code editor, I begin to see the need for helper functions that have common usage regardless of the project. My previous solutions for this were to re-write the helper function from scratch or, moderately more efficiently, copy and paste one I had written in a different project.

Today I decided it was time to at least start collecting these helpers in their own repo so I didn’t have to go hunting down that one project from months ago where I think I last used the function. I created a GitHub repo https://github.com/lucsedirae/helper-library and loaded the couple of helpers into an index.js file that I am constantly searching for to get it started.

Then the thought occurred to me that it would be nice to just install this index.js file via NPM and be able to import the functions like I would any other NPM published dependency. I wasn’t sure where to start so I did some Googling and discovered the process was actually really easy and NPM gives you unlimited public access packages with their basic free tier membership.

Initializing package.json

The first step after cloning down my repo that I initialized from the GitHub website GUI was to run npm init from the root directory of my new repo on my local machine. This executes a command line script that asks for basic information about your package and creates a package.json file in the project directory. It’s important to have a readme file, a license file, and make sure the NPM “entry point” is the name of the file you want to store your functions in. The default entry point suggested by the npm init script is index.js so that’s what I went with.

Inside index.js I wrote out the couple of helpers I am always searching for. The one I needed this morning was formatDate(). It’s a simple function that takes in an incoming UTI time stamp value, creates a new JavaScript date value using the Date constructor and then returns that new value using the toLocaleDateString method. I have some plans to expand the functionality of this over time so I use it regularly as a helper instead of doing both of those other processes inline for each use case. This is a much lighter-weight solution than importing a time-handling library like moment.js and keeps my codebase clean.

I pushed these initial functions up to my GitHub repo and was ready to publish the package to NPM.

Publish to NPM

Before you can actually publish your package you need to create an NPM account. You can do this from their website at https://www.npmjs.com/ or from the command line by running npm adduser. Make sure to select a password longer than 10 characters. NPM will send you an email to confirm your address and once you have clicked on their confirmation link you are ready to publish.

Publishing was as easy as running npm publish --access public from the command line inside the root directory of the package you wish to publish. Once that script completed, I was able to test my publication inside a project. My package is published as my GitHub user name so I navigated to the project I wanted to use the function in and ran npm i lucsedirae. Then I imported the function in the file where I needed it to run:

import { formatDate } from 'lucsedirae';

Then called the function:

const todaysDate = formatDate(Date.now());

And voila! It worked like a charm!

Caution!

I noticed after running npm i lucsedirae that there were a lot of vulnerability notices in the terminal. I haven’t had a chance to dig into how to fix these issues but I do plan on doing so to expand my understanding of NPM and its package publishing environment. So, with that said, I would not recommend using a package like this in a production environment. When I publish my project I will replace that import with the helper functions hosted in a utils file inside the project until I better understand the security implication with using my own NPM package. But as a learning experience and a way to store common helper functions for practice projects, I was really satisfied with the results.

Side Project Journey Part 3 - Back End Planning

Jon Deavers — Tue, 05 Oct 2021 17:03:21 +0000

The first two parts of this series were focused on desiging the user interface of my new side project called Bioledger. The first step was hand-sketching the UI elements on a sketchpad. The sketches don’t look great but they did give me a clear plan for what I needed to create on the screen. The second step was to translate those hand sketches into a digital version that gave me a representation of what the final project would look like on a mobile device. Figma and its community-built tools made that process relatively easy. Now I have some solid reference points for beginning the actual development process. I feel good about where I am in the process so far but a couple of things have changed from my original plan. Let’s take a look at the original outline from part 1:

Design product
1. (complete) Sketch out the UI on paper including any necessary elements and a basic navigation flow
2. (complete) Use the sketches as a basis for a more detailed design on a digital design tool (i.e. Figma)
Develop back end
1. Using the designs developed in step 1, map out the data structure for the necessary mongoose Schema(s)
2. Build a node.js express server that handles an API for the MongoDB database using Schemas and controllers informed by the previous step
Develop front end client
1. Utilizing Next JS, bootstrap a client and add necessary pages, fields and layout components
2. Style front-end using CSS modules

Process Modifications

This was a great outline to get the ball rolling, but as I’ve spent more time thinking about the code I’ll need to write I’ve decided there’s a couple changes I’d like to make. Firstly, step 1 should be more accurately labeled “Design User Interface” since that step was focused just on UI and not on the architecture of the codebase. That’s an easy change.

Next up is in step 2 where I’m missing a couple key steps that I think will be helpful in the development process. The second sub-step in my outline is a little too broad. I’d like to get a little more granular with the back end design process. Also, I’d like to pseudo-code each of those sub-steps in the code editor so that I’m being more deliberate with my planning both inside and outside the editor.

Lastly, in the third step, I’ve decided to not use Next JS as a React framework. Next is a powerful tool and comes with a large amount of powerful features but its primary use is to build and serve statically rendered content from the server. This project will not be hosting any static content and so it will be unnecessary to utilize its most important feature. Also, Next makes handling navigation really easy but I want to really code my routing in a more visible way that gives me easier access to the handling of public and private routes. In order to achieve this I’m replacing the Next bootstrapping with create-react-app and will handle routing with the NPM package react-router-dom instead.

Here’s an updated version of my design/development outline:

Design User Interface
1. (complete) Sketch out the UI on paper including any necessary elements and a basic navigation flow
2. (complete) Use the sketches as a basis for a more detailed design on a digital design tool (i.e. Figma)
Develop back end
1. Using the designs developed in step 1, map out the data structure for the necessary mongoose Schema(s)
2. Code config files
  1. db.js – export method for connecting to database
  2. production.json – json file holding config keys for deployment
3. Pseudo code the server entry point file (server.js)
  1. Dependencies
  2. Database connection
  3. Middleware initializations
  4. Define routes
  5. Port & server initialization
4. Pseudo code the routes files
  1. Dependencies
  2. Init router
  3. Define each CRUD route in comments
  4. Write comments as placeholder for the logic each CRUD operation will handle inside the route
  5. Repeat this process for each route file
    - auth
    - metrics
    - users
5. Code schemas using data map written in step 1
  1. User schema
  2. Metrics schema
6. Code server & routes according to pseudo comments
Develop front end client
1. Utilizing create-react-app, bootstrap a client and add necessary pages, fields and layout components
2. Style front-end using CSS modules

This is looking a lot more detailed now. The outline will eventually serve as a template for designing future projects once I’ve completed the development process.

Initializing Project Directory

It’s finally time to start working with some files and the code editor! I created a directory for my project and initialized the project with npm init to create a package.json file. From there I installed my list of dependencies (for the back end) in the command line.

My preferred text editor is VSCode so I opened up the project directory and created the files I would need for my server. Here’s a look at my file structure:

According to my development outline, some of my files would be redundant to pseudo-code so I went ahead and coded out the config files (sorry, won’t be sharing those) and my models files.

One of the best features of VSCode is its absolutely massive collection of community-created extensions. These extensions help streamline the development process and add functionality to the core of VSCode’s functionality. I utilize and extension called “Better Comments” to color code comments in my code which is helpful when organizing your codeblocks. You can find it on the VSCode marketplace in the app or on their website.

I pseudo-coded the server.js and routes files using this extension.

Summary

At this point I am ready to code out my routes and server.js file. From there we’ll be able to test the routes in a development environment using the Postman tool. As a side-note, I’d like to say that I had all of this necessary functionality in my head, ready to be committed to comments but that wouldn’t be truthful. I referred back to a project I developed with my team in boot camp that had a lot of this functionality already coded up. Some of it mirrors that project exactly but some I had to modify as I thought about the differences in how this project will handle data. Special thanks to Brad Traversy of Traversy Media for his React Front to Back course available on Udemy. That course provided a blue-print for both of these projects. If you are learning React and need a tutorial, I encourage you to visit his website and check out his offerings.

Next up we’ll be reviewing our development outline again, taking a look at the back end code itself, and testing our routes using Postman.

Side Project Journey Part 2 – Wireframe

Jon Deavers — Mon, 04 Oct 2021 17:34:01 +0000

In part one of this series I laid out my plans to document the development process of a side project called Bioledger and showed my (poorly) hand-drawn sketches for a user interface. In this post I plan to share my digital mockup of the UI that I built using Figma. One of the main motivations for starting this series is to build a project using a plan. So before diving into the design, here’s how that is going so far…

Planning is hard. I’m the type of person who wants instant gratification and I love being in the code editor writing, editing, and thinking about the code. While I appreciate great visual design, I’m not a designer. Similarly, pseudo-coding and white-boarding code seems like a great idea but my instincts are still to dive into the code editor and start hacking away. Thankfully, pushing myself to stop and make a plan for this project is already paying off.

Moving the UI design from paper to Figma

Figma is a design tool that you can try out and use as a solo developer for free. It has a robust community with tons of free assets, plugins, and tutorials to utilize directly in the app. It’s also utterly confounding to use if you have no experience with design tools of this type. I highly recommend working through some tutorials when starting out in Figma to avoid the frustration of trying to use it as a painting program. It’s a tool built by designers for designers and so you have to understand how a designer thinks before getting the most out of the tool.

Figma allows you to not just mock up a UI but to simulate programmatic features including animations, clickable navigation, and much more. My app is pretty simple and with my limited experience with the tool I decided to focus on building a more polished digital version of the sketches I made in my sketchbook until I have more experience using Figma’s more complex features. After watching some tutorials and reading some articles on the fundamentals of web design, I was able to create a basic UI that I felt comfortable would look good and function well as a finished product for this project.

The picture above displays the 5 main views my minimum viable product should include:

A landing/user login view
User registration view
A form for entering daily metrics
A screen that displays once that day’s metrics have been logged
A data visualization view with some mock charts

A closer look

Notice at the very top of the image, the screen view is labled with the name of the component to eventually be rendered using React, a short description of the view, and a URL endpoint. Labeling the views allows me to easily refer to each one during the development process and know exactly where it fits in the UI flow. I used a community plugin that easily lets you incorporate forms in your design. Congratulations to user @OneBlinq for the intuitive and easy to use plugin. It worked great and only took a few minutes to design all of my project’s forms. I also labeled dynamic data in the view using arrow brackets. I don’t know if this is a common practice or not but it made it easy for me to identify what needs to be dynamic when coding the project.

Summary

All in all, Figma comes with a steep learning curve, especially if you don’t have a background in design. However, I’m really happy with the design and feel confident that the effort it took to put this design together will help make my development process move more smoothly with better final results.

Next up is laying out a plan for my back end and database. Instead of adding data properties to a schema as I run across the need during the coding process, I want to have a reference and think through how the data will be stored, retrieved, modified and deleted. If you have feedback or suggestions on this process feel free to connect with me on Twitter @jondeavers. I’d be gratful for the feedback and happy to help!

Originally published on my blog at https://jondeavers.net

Side Project Journey Part 1 – Initial Design

Jon Deavers — Sun, 03 Oct 2021 20:26:18 +0000

As a web developer, I am constantly looking to improve my skills. I’ve completed a full stack boot camp, followed dozens of tutorials, and built my own projects from scratch. As my skills have developed certain things have come into focus. Firstly, I know where my strengths lie; organizing code in a readable and maintainable codebase is a borderline obsession for me. I like small, modular components that keep individual files to a manageable size. React is a framework I have genuinely come to love. It has provided me with a much greater competency in “vanilla” JavaScript and a practical, consistent path to rendering my vision in the browser. Node.js was a struggle to get comfortable with at first, but building simple API’s has given me a much deeper understanding of how the web works as a synergistic system of front-end views and back-end models and controllers.

I am also more aware of my weaknesses. At the top of that list is as a designer. Like many developers, I like to explore new ideas and tools but sometimes that case of “shiny object syndrome” will keep me from completing or even making progress on a project. Often I will start a project in the code editor. This isn’t always a bad idea, but it does lead to more frustration than would be necessary had I started with a design and “roadmap” through the development process. My dev directory is full of abandoned, half-baked projects.

After taking some time to analyze these strengths and weaknesses, I decided to try and shore up the weaker parts of my skill set and start a new project where I follow a specific development process. I also wanted to document this process in hopes that it will keep me accountable to finishing the project and hopefully be of value to others.

Here’s my plan:

Project Name

Bioledger – A biometric tracking application

Tech Stack / Tools

Figma – For designing the UI based on hand sketches
Node JS – JavaScript runtime for web server
Express – Node framework for building a web server
MongoDB – Relational database for data storage
Mongoose – MongoDB framework for building REST API
React – UI framework for front-end client
Next JS – React toolkit for handling routing, image optimization, and server-side rendering of static data

User Story

As a user working to become healthier, I want an application where I can log in daily and easily track my weight and blood pressure readings. I also want to see my progress displayed in easy-to-read charts.

Development Process

Design product
1. Sketch out the UI on paper including any necessary elements and a basic navigation flow
2. Use the sketches as a basis for a more detailed design on a digital design tool (i.e. Figma)
Develop back end
1. Using the designs developed in step 1, map out the data structure for the necessary mongoose Schema(s)
2. Build a node.js express server that handles an API for the MongoDB database using Schemas and controllers informed by the previous step
Develop front-end client
1. Utilizing Next JS, bootstrap a client and add necessary pages, fields and layout components
2. Style front-end using CSS modules

Initial Sketches

There’s a reason I like to be creative using digital tools. I am certainly not a visual artist. However, I’ve been following a design course on Udemy that recommends beginning the design process with sketches and so I’m following their advice. Below are my (very) rough drafts of the UI for this project.

This process is subject to change. I’ll do my best to explain my thoughts as I work through the steps and if you have any suggestions, feedback, or questions please connect with me on Twitter and I’d be grateful for the advice and be happy to help.

Originally published on my blog at jondeavers.net

What is an API?

Jon Deavers — Thu, 05 Nov 2020 20:26:09 +0000

What is an API?

API stands for "application programming interface". APIs allow one application to "talk-to" another, allowing for the transfer of stored data or instructions. API's are everywhere in your daily life; from the embedded YouTube videos on social media applications to the smart speaker on your kitchen counter. They make it possible for software developed at different times by different people to interact and thereby increase functionality and productivity.

How does an API work?

For the following example, we will be working in JavaScript (jQuery enabled) with The One API (a fun Lord of the Rings Themed API). Consult the API documentation for specific instructions on usage. Many APIs require an authenticating id token to access. The instructions for acquiring that token are also found within the API's documentation.

Consider the following code:

The URL string below is the path of your API and can be found in API documentation

const lotrQuote = "https://the-one-api.dev/v2/quote/";
$.ajax({
    url: lotrQuote,
    method: "GET"
    }).then(function(response){
        console.log(response);
    })

In this example, the variable lotrQuote is defined as a string that contains an API route. When called by the jQuery .ajax method in line 2, the API is queried and returns either JSON or XML data. That data is passed into our .then callback function and rendered to the console in its raw form.

Examples of APIs

There are tons of APIs available to the public that are free to use so check out a site like public-apis.xyz to explore and get creative with a wide variety of options. Here are a few examples of common public APIs that you may already be familiar with in your day-to-day life:

-Google's public API suite - Google has an overwhelming collection of public APIs that developers can try for free. They do have pretty strict security on their id keys and free usage is capped by a daily limit so test sparingly. This suite facilitates all the embedded "Google Maps" you see on other developers' apps and websites. And that's just the tip of the iceberg, so dive in.

-Mailchimp's Marketing API - Mailchimp is an email marketing platform that powers the email marketing needs of many of the websites you read every day. Those sites and apps are able to make use of Mailchimp's platform by utilizing the power of their marketing API.

-OpenWeather API - OpenWeather is a free and open weather data API that can be used to power anything from small widgets to whole applications. According to the reporting site Built With, many news organizations use OpenWeather on their sites.

Experiment

Simply messing around with free API's can teach you a lot about your language's syntax and programming concepts in general. Create something fun and useful today!

If you have questions or enjoyed the article let me know in the comments below or stop by my developer profile page and say hello.
https://lucsedirae.github.io/

Experimenting with Bootstrap Alternatives

Jon Deavers — Tue, 03 Nov 2020 06:46:22 +0000

Currently I am half-way through a 6-month full-stack web development boot camp. Since day one we've been using Bootstrap as an HTML framework. I am not ashamed to admit, I've been in love with it ever since. It makes my "this had to have been made circa 2002" web designs look modern and relevant in today's environment both on desktop and mobile with little fuss.

Recently, though, I've been experimenting with new frameworks so that I don't cement one method of design in my head with Bootstrap's syntax. I wanted to share my thoughts on each. Firstly, here is a list of the pros and cons of continuing to use Bootstrap for every project:

Bootstrap 4

https://getbootstrap.com

Pros

Incredible documentation - Bootstrap's Documentation page is world class in terms of organization and ease of use. For a new dev, it set a high standard that has rarely been met in my experience.
Full featured - There's a reason that one of the chief cons of BS4 (spoiler alert) is its size. This framework has just about everything covered for complex and richly featured web designs.
Intuitive grid system - I cannot over-emphasize how helpful Bootstrap was in helping me understand the concept of CSS grids. Rows divisible by 12 columns each is about as visually elegant as it gets.

Cons

It's huge - One of the biggest complaints that I've read about when exploring alternatives to BS is the size of the codebase. I haven't personally run into issues here, but my applications are still relatively rudimentary. I can see this becoming an issue at scale and for accessibility reasons given the amount of data needed to render on a browser with a slow connection or dated hardware.
It does a little too much - Sometimes I want more control over the finer details of my design. Bootstrap handles so many elements of design and offers a ton of built-in components but these can cause styling conflicts when building out my own stylesheet. For some projects it would be nice to rely more on my own styling and lean on a framework for the basics, like an intuitive grid system.

Let's meet the alternatives:

Materialize

https://materializecss.com/

Familar, maybe a little too familar - For the sake of clarification: I haven't permanently shelved any of these options. I've only dabbled in each and so will come back as my skills develop and explore the finer details of each of these tools. With that said, Materialize felt a little too similar to Bootstrap to require learning the differences in syntax. It was missing some of the built-in components I had come to rely on as well.

Everything I read about Materialize pointed to it being a full featured framework but with less bulk than Bootstrap. As mentioned above, I haven't seen cases of performance strain in any of my projects yet so that benefit wasn't readily apparent. Since I am currently only using maybe 20-30% of the power BS offers, it felt like a lot of duplication using Materialize and therefor not worth the time investment to keep digging.

The incredibly clean look of Materialize was one of its standout features. Squared corners and clean lines gave the HTML a very sleak, modern feel out of the box. That and the potential performance gains definitely make this framework one to revisit in a future project.

Foundation

https://get.foundation/

A roller coaster of emotions - Foundation is the tool I wanted to love the most but ultimately generated the most heartburn. This framework strips away a lot of the complexity of Bootstrap's syntax while remaining modular enough to offer a robust catalog of snippets and components, many made by outside contributors.

I just felt a little out of my depth on it. There were the expected growing pains of working with a new framework or library where one spends hours pouring over documentation and YouTube tutorials to get a handle on the basics. The point where it became too much of an obstacle for my project was when trying to assign a font-family attribute.

I was test-driving Foundation on the third verison of my developer profile between bootcamp homework projects. I wanted to import a Google Font into my landing page for the header and I could not find a way to assign it a attribute in the stylesheet. Some Googling of the issue found a solve for it, but it required making configuration changes in the package's CSS files. For that project I am relying on CDN's for outside libraries and frameworks and so Foundation is making its way back on the shelf to wait for another day.

The ability to quickly build in mobile responsiveness and easily maintain design consistency was very attractive. I also really like how the grid system is handled in Foundation. I feel it would have been tough to learn grid with but, with a "foundational" (sorry, couldn't help it) understanding of grid, the control Foundation provides over both the x and y axes was a welcome change. Once I have more experience in server side deployment and am no longer relying solely on CDN's, I will be revisiting Foundation.

Simple Grid

https://simplegrid.io/

Joyfully bare bones - Simple Grid is the least robust, most feature limited, and my personal favorite of all the frameworks I've tried, excluding my beloved Boostrap of course. This framework focuses solely on making pages responsive via CSS Grid. SG's grid system is a very similar syntax to Bootstrap but less cumbersome. Instead of a class <col-md-6>, a simple <col-6> is needed and SG handles the rest. There are no pre-built components and very little other than the grid itself is provided.

So why is it my favorite? Because it provides a wide-open canvas to design and build my own CSS library and have full control over customization of the project's HTML. Because of this skeletal approach, Simple Grid won't make sense on every project. Sometimes time-constraints will require a more full-featured framework. Consistency of design is also a great reason to work with a more robust framework. But for side projects and certain other tasks, the race-car performance and granularity of styling that SG allows makes it a permanent addition to my toolbox.

The bottom line

Ultimately, Bootstrap is still my go-to choice. I see potential in all of the frameworks and the experience of thinking about the grid and design differently were well worth the experimentation. But BS4 just does everything well. I look forward to the day when performance is a big enough concern to look for a more performant solution. I have some great ideas for functional applications that would be a perfect fit for the bare bones efficiency of Simple Grid once our class dives into React. But for now, I'll be continuing to lift my skills up by their, you guessed it, Bootstraps.

What are you using?

What frameworks are you currently using? I'd love to see some suggestions for other frameworks to explore.

Come say hello at https://lucsedirae.github.io/
I'm always up for collaboration and constructive criticism.

Intro to Chrome Dev Tools - Part 1

Jon Deavers — Mon, 19 Oct 2020 07:42:43 +0000

Merriam-Webster defines the term "whip-lash" as "injury resulting from a sudden sharp whipping movement of the neck and head." That's how I feel on a regular basis while working my way through a full-stack web development bootcamp. As the knowledge comes in, I race to implement everything I'm learning into a homework assignment or pratice project. Inevitably, during every work session, I hit a wall bringing my workflow to a screaching halt while I power through a couple tutorials on YouTube or comb through documentation.

This rhythm of the learning process is likely (and hopefully) never going to stop. The intervals between full-stops may grow larger but one of the aspects of web and software development that drew me in was the ability to never run out of things to learn. The allure of having a constant stream of new tools and techniques to explore makes me excited for the future.

This process can feel like a roller-coaster, full of ups and downs. The downs can be challenging but the ups make it all worth it. The best kind of "up" is coming across a watershed event, something that completely redefines your level of competency. One such moment, for me, was discovering the power of Chrome dev tools.

Under the browser's hood

Until I started the journey of web development, I never put much thought into my browser. I liked the look and feel of Chrome over Microsoft's browser offerings and so I made it my default a decade or more ago. That is pretty much all the thought I had put into my browser until now.

When we first learned that right clicking and selecting "inspect" on a page in Chrome gave access to a whole new world of data and information, I was intrigued, but didn't quite understand the scope of what this tool allowed me to do. What was apparent to me, though, was that I was looking at the inner workings of an incredibly complex tool that I had always taken for granted. As time has passed and my skills have improved, the dev tools are making their real power known to me and they allow me insight and access into the development process that improves the speed at which I work AND the speed at which I learn.

In this series I will share what I've learned so far about Chrome's dev tools. So right click on your page, select "inspect" and follow along.

FYI - I am aware that other browsers also offer developer tools and that some have features that Chrome doesn't offer. My experience is limited to Chrome's suite of tools and so I will focus on that browser for this series.

Elements tab

The elements tab is the default view upon opening up Chrome dev tools. It displays the most basic of web-page information, the HTML markup of the currently displayed page. Being able to see how the HTML is formatted while looking at the rendered page made grasping the underlying structure of my pages much easier to understand and plan out. This was especially helpful as I learned how to start using grid frameworks like Bootstrap that significantly increase the amount of elements on my page.

Here are some useful notes on how to use the elements tab:

Hovering

Hovering over an element in the Elements tab will highlight it on the rendered page. This makes tracking down exactly where your elements wind up on the page much easier. In the image above, you can see an icon at the top left corner of the dev tools window that looks like a square with an arrow pointer in it. Clicking on this will let you hover over elements on the rendered page to see information. Clicking on an element in this view will automatically navigate to the Elements window to the corresponding HTML line.

Style Visualization

On the right hand side of the Elements tab you will find a second window with even more tabbed options available (see image above). The "Styles" tab will show you any associated CSS that is being applied to the selected element. This is invaluable when trying to figure out if a framework or CSS library is applying a style to your element or if you're trouble-shooting styling on a specific element.

Right beside the "Styles" tab you will find the "Computed" tab. This tab displays a box that visually represents the selected element and notes the amount of margin, border, and padding that is being applied via CSS or natively to that element (see image below).

What's really impressive here is that you can test out changes in your CSS styling right there in Chrome's dev tool. Just click inside the "Styles" tab and add, remove, or modify CSS properties and see their effects applied in real time to the page you have loaded. These changes don't get saved to your files permanently, so it's a great way to test out changes or trouble-shoot styling that isn't quite lining up as expected without breaking your stylesheet. Just remember that you will need to copy these changes to your code editor and save them in your stylesheet in order for them to be permanent. Once you navigate away from the page you loaded, the changes are lost.

Event Listeners

The next tab on our Elements sub-window is the Event Listeners tab. This tab will show any event listeners that are active on the page or a selected element. Event listeners are pieces of code that are "listening" for something to happen in order to trigger something else. A basic example would be button. Buttons have a piece of code attached called a "click listener" that is waiting for the user to click the button and then that listener instructs the broswer to do something else specific after the click is "heard". Sometimes there are different types of listeners on a single element or there are many "listening" elements across the page. Navigating to this tab makes tracking down those listeners and seeing what purpose they serve much easier than scanning through your codebase.

Accessibility

Our very first bootcamp homework assignment was to refactor an HTML page to make it more accessible, paying close attention to "semantic HTML" to improve the ability for tools like screen readers to make sense of the elements on the page. The "Accessibility" tab in the dev tools is a massive time saver for this task.

Elements that are not semantically labeled will return a "generic" descriptor in this section. This provides a road map on how you can take a second look at the elements your page is comprised of and allow you to change their element tags to more accurately reflect their purpose and allow a larger number of people to easily access your content.

"HTMLify" Dynamically Generated Markup

My last tip for the "Elements" tab is probably my favorite. I much prefer to generate my page content dynamically using jQuery and JavaScript over hard-coding HTML. This allows me to have minimal content in my index.html and never navigate away from the main page while still being able to deliver well organized content dynamically. While in the dev tools, the "Elements" tab will display the active HTML that is being rendered on the page even if it was created dynamically outside the HTML file.

In the example above, everything that is shown inside of the "main" element tag was written using jQuery and JavaScript. As the user navigates the menus of my developer profile page, the content of "main" is replaced with different markup. This makes it easy for me to see what my HTML file would look like if it were hard-coded HTML and not dynamic JavaScript.

Summary

Thanks for taking the time to read my post. In the next installment I will take a closer look at the "Console" tab of Chrome's dev tools and really start to dig into the browser's hidden power.

If you would like to see what I've been up to or get in touch, check out my developer profile page on GitHub.

Important Things I Learned Working In A Group

Jon Deavers — Fri, 02 Oct 2020 07:08:33 +0000

I'm currently a student in a full-stack web development boot camp. We are just about to turn in our first group project and I learned a lot during this process. I learned some handy tricks in JavaScript and CSS, but more importantly, the lessons learned from this assignment were lessons about working with people in a creative and collaborative environment. I'm making a career pivot after almost 20 years in sales and collaborating is rarely an option in that field. Even when you're part of a team, there's an underlying layer of competition involved.

Spoiler alert: I thoroughly enjoyed the group dynamic and felt lucky to have landed with the team I did. We learned about each other's skillsets and strengths and weaknesses as well as our own. Here are some of the highlights:

Decisiveness
I have to be honest, our first night felt a little messy. We spent the majority of our 3 hour session trying to get a consensus on a project. Not because there were passionate disagreements but because it felt difficult choosing something that was important, but also within reach of our current skillsets. We still hadn't learned anything about server-side programming or any sort of third party storage. That ultimately became the deciding factor in making our choice between our two top candidates.

I felt a little conflicted here. I was fully on board with our ultimate choice in project. It was partly my idea. But I also felt a responsibility to really give it 100% effort so that the decision to commit to that idea really resulted in exceeding the potential of our backup idea. That sounds a little strange to say even as I type it, but essentially I wanted to feel confident that the route we were taking was going to truly produce a better application and wasn't just a matter of taking the easy route.

At the end of that first night we all agreed readily on one major philosophy for the project; once we made that choice, we weren't looking back. It was full steam ahead with our decision. Two weeks sounded like an eternity at the beginning of the project. But currently with only one class left before our presentation, we wish we had another week. I was glad we decided to commit to an idea in those early hours and move forward to delivering our minimum viable product.

Project management
Collaboration is hard. It's a completely separate layer of skill. Through the first couple months of work prior to our group assignment, I had developed a pretty fluid workflow and pace to my development work. Having to learn to operate in concert with several teammembers taught me the value of focus.

Perhaps in the real world I will occasionally not be bound by constraints on time and other resources. My guess is that, more often than not, the opposite will be true. With a due date looming and several other moving pieces revolving around my efforts I learned quickly that I need to focus on a task, knock it out, test it and push my commits to version control. There were several times when someone was waiting on me to complete a task or vice versa. In my previous method of "solo" development, I frequently would get inspired and leave a function unfinished to pursue the shiny object. Now, I've learned to drop a comment where that new feature should go and make an issue to revisit it when the workflow allows.

Delegation
4 years of my aforementioned 2 decades of sales experience was spent managing people in a large sales organization. That was a roller-coaster of an experience but it taught me some valuable inter-personal skills.

As a natural introvert, it took a lot of practice to learn to take charge of a situation. I was always afraid of stepping on toes or insulting someone. What I realized over time was that there is a big difference between holding someone accountable to their responsibilities and being an over-bearing jerk.

That is not to say we experienced any inter-personal drama. But we were in need of someone to organize our collective thoughts and democratically map out the chart of progress. I volunteered for that role and dove into the projects and issues tools on GitHub.

It's difficult to manage my own scattered brain, but having to juggle my own thought process while being aware of what was happening in the several other branches of our repo made the value of those tracking tools apparent. In future projects, I would want to increase my granularity with those tools. I typically found myself spending 15 minutes before class started cleaning up issues that had been solved in the past two days. It still provided a record and a roadmap of our progess.

Version control
This is a dangerous topic. In the first few days of our collaboration, I completely scrambled our codebase multiple times due to mishandling of pull requests and a failure to better plan out protocols for our version control. Yet, by the end of week 1, we were merging the majority of our pull requests without any conflicts and the application was progressing nicely.

Since the early days of this boot camp I have committed and pushed early and often. It's been a life-preserver one more than one occasion. I was intimidated by having to process gobs of pull requests if everyone took the same approach. Surprisingly, it was less of a time investment to process large quantities of pull requests which could auto-merge than it was to have to resolve conflicts throughout 100 lines of new code.

Hurdle-jumping
One of the most surprising and beneficial lessons was learning to pass the football. The biggest pain points in this boot camp have always revolved around roadblocks I'd encounter tackling a homework assignment on my own. Fortunately, we had developed a tight-knit study group consisting of most of the cohort and help was always a Discord or Slack ping away. But you still felt like you were on an island of sorts.

With this team, communication was frequent and constant. The hours between class sessions were almost all dotted with short collaborative conversations in our Slack message group. Most of the real progress made on the codebase was written in those gaps.

The all-hands on deck approach of our team allowed us to hand off an issue and quickly get a second or third set of eyes on the code to help troubleshoot. This rapid response was really what saved the project and made it possible to produce an application we were proud of. It gave us sufficient time to spend on deciphering endless console errors and returned data format trifles in our chosen API calls.

Trusting your teammate to innovate and create
My current career is in real estate. As a Realtor, I do not work on a team. I do work for a supportive broker and have access to an array of talent via the experience of my office-mates. Ultimately, though, I am self-employed and it's easy to develop a control complex in that environment.

I really had to fight the urge to try and override someone else's decision throughout this project. I had my own vision for how the project would look and in my current position I would have no one presenting alternative options. I knew going into this boot camp that this was a weakness in my professional life that I needed to work on.

While I am not surprised, I am relieved to confirm that every time I had a difference of opinion about a certain feature and deferred to someone else's judgment the finished product was that much better for it. The lesson for myself here is that if I am passionate about a certain feature, then I need to make sure I've considered all the pros and cons before going to the mat for it. I believe that if an idea is truly the best way to go then its best shot at adoption is to develop the idea to a point where it can convince everyone else of its own merits.

This is almost certainly an optimistic way to think about every decision and situation. There will be times where I feel I support a superior option and another option wins out. I hope in those moments I am able to remember that the winning idea has someone behind it who is just as passionate about it as I am about my own. In that case, it deserves an honest effort and will potentially benefit from complimentary ideas from my own option.

The importance of comments
Comments had long been a mystery to me. I was of the mind that my code should be so clean, well thought out, and organized that it would speak for itself. That's a tall order in a time crunch with three other coders all bouncing ideas off each other. Also, there were times I ran across something someone had added and asked myself, "What the heck is this?". Turns out there's a saying about people who live in glass houses.

I soon realized how beneficial it was to have a brief summary of a function commented out right above that function's code block. A little date stamp with some initials would save a lot of alt-tabbing between my IDE and my GitHub repo while researching commit history. I even discovered how valuable comments can be as storage containers. It was very helpful to provide a link to an API's documentation right above an ajax call for easy reference.

In Summary
And so here we are. 90% of the way to our minimum viable product. And with time left to be able to put some vanity touches on our app with CSS, add in last minute functionality that enhances the experience, or even dry out that script.js file that was always on the brink of becoming unwieldy.

I've learned a lot about coding and about myself. Not least of all, I've learned a lot about the people I worked with and for that I am grateful.

Thanks for taking the time to read. I would love to hear what you think and how your early group-efforts went. Comment below or find my contact info on my profile page.

-Jon Deavers
https://lucsedirae.github.io/

Keeping A Portfolio Page Current While Learning

Jon Deavers — Wed, 23 Sep 2020 04:34:25 +0000

As a new developer, still deeply in the learning process, there are so many interesting tools introduced each day. I am currently enrolled in a bootcamp and loving it. Sometimes the curriculum is like trying to drink water from a fire hose. There's a ton of information coming at us during class and it's a lot of work to produce solid results for the homework assignments.

Once in a while you have an assignment where you really click with the material and the work only takes a few days instead of the whole week. The first time I was lucky enough for that to happen, I spent the rest of the week packing my current homework assignment with additional features and refactoring code down to the most efficient blocks I could produce. That "extra-curricular" work taught me quite a bit and the practice time spent going a little overboard was invaluable.

This week, I really felt comfortable with our assignment and came to that same fork in the crossroads; do I continue to improve this project or do I work on something new? The practice would come in handy and it would be fun to share the extra features with the like-minded students of our study group. But I am approaching web development with the goal of freelancing and building my own business.

So I started to think; what holes are in my portfolio right now? I brainstormed for a solid hour and most of the projects I dreamed up would require more knowledge than I currently had. I'd also rather improve my grasp on past material than study forward. Eventually it dawned on me. Let's take a look at the portfolio to date and start to apply to those old assignments what I've learned in the weeks since those prior assignments had been completed.

The natural first project I thought of was my profile page. Created in the first week of class, this page was woefully outdated. Sure, at the time, it received a grade I was proud of. But looking back and knowing now what I didn't know then, all sorts of ideas on how to redesign and improve the page started popping into my head.

So I spent the better part of a weekend building out version 2.0 of my developer profile page. I incorporated a ton of features from bootstrap that I had become more comfortable with. I used jQuery and JavaScript to consolidate the page from multiple html files down to a single dynamically programmed index.html. I finally learned some palette restraint and made conservative but unique styling choices with CSS. And I published the page to GitHub pages with a feeling of satisfaction that was more than just the type you feel when you finish a homework assignment. This time I knew the project had been real-world productive. I didn't have time constraints or instructions to restrict me, and so I felt free to be as creative as I wanted. All while showcasing the skillset that continues to evolve with each week.

The conclusion for me is to make this a regular part of my learning process. Revisit old projects, look for improvements, and continue to seek out new tools, techniques, and tricks. If you'd like to see my newly redesigned profile page, feel free to visit https://lucsedirae.github.io/

Overthinking Web Development as a Beginner

Jon Deavers — Tue, 08 Sep 2020 16:01:37 +0000

I recently started a full-stack web development boot camp at a local university. After months of poking around YouTube and Google with little-to-no direction and a total lack of foundational understanding, I decided it was time for some structure. I needed someone to tell me what I needed to know in order to learn what I wanted to know.

It turns out this decision is one of the best I've ever made. Not only am I learning at a break-neck speed, I've also found a group of fellow students who are equally as passionate and excited about the journey as I am. Together we've taken concepts that seemed foreign and confusing at first and work-shopped them into tools that we can use to build professional and creative projects.

It hasn't been an easy road, however, and the learning curve is definitely steep. Over the course of several homework assignments I've discovered that often the biggest obstacle standing between me and a fully functional script is my own brain.

Learning so much so fast makes me want to cram the fruits of every lesson into a JavaScript file and make sure I'm demonstrating my understanding of how everything works. The problem is that this approach often results in overly complicated functions that break easily because I'm overlooking a core principle in functional coding: keep it simple, stupid.

Before classes started I had the rare (for me) foresight to pick up a book called The Pragmatic Programmer by Andy Hunt and Dave Thompson. The book has been updated since its initial publication in 1999 but it is still a static piece of tech in a world that evolves by the hour.

Fortunately, this is not a book about syntax or any specific languages. The book speaks to the mindset required to be a great programmer. I didn't have the opportunity to finish reading it before classes started so I'm in a holding pattern until graduation. After all, there is such a thing as mental bandwidth limits.

The best lesson I've learned from reading through the first handful of chapters is this: stay grounded. Staying grounded to me means being mindful of the logic, following it through each step. It means staying open-minded; allowing your ego to stand aside while you learn from your fellow students and instructors. It means creating code from the perspective of your end user and not necessarily your own; letting overly elaborate functions and methods take the backseat to accessibility, readability, and usability.

We're only a little over a month in to the boot camp and there's a long road ahead between now and graduation. Over the course of the next five months, I plan to ground myself when necessary by thinking back to the lessons learned from Andy and Dave's book.