DEV Community: Jay Delisle

My Year In Review - 2020

Jay Delisle — Wed, 20 Jan 2021 05:00:00 +0000

2020 was a year to remember. It had a lot of down points for sure. But just like anytime in life, there is always ups AND downs. So, to start the new year I wanted to look back at 2020 and go over some of the good things that happened.

1. My First Software Engineering Job

To start the year, I started work at my first software engineering job. I have a degree in mechanical engineering and was working in that field before making the switch to software engineering (I'll have a blog post on how I switched careers in the future - stay tuned!). I was miserable in my last job and just was not enjoying it whatsoever. I knew software was the route I wanted to go. After just over a year of learning software development - I had my first offer.

I love the work I do now. I'm a Test Automation Engineer and I primarily work with Python, which is great. Through this year of work, I improved upon my python skills tremendously. I gained real world development experience in python, testing, SQL and database usage, and much more. It was a year of learning. I had to learn about the tech stack in use, I had to learn the testing framework that we used, the codebase, and the standards that we followed. I look forward to the coming year as I continue to grow more and more!

2. I Launched My First Website

This year was the year I developed and launched my first live website - This blog site! This was a big accomplishment for me. My day job doesn't deal with web development. It is something I just like and continue to learn more about on the side. Through the year I continued to improve my python skills at work and my web development skills in the after hours of work. I got to the point where I was feeling confident and decided to launch my personal blog site. I intend for this blog to be a place for others to follow along and learn with me as I document my journey and new findings.

I will say, if you want to learn to code, or get better, then just build and launch something. I learned more in the two months after launching my site than I did the 6 months prior. Between figuring out how to do things from other sites and fixing errors and bugs I learned so much. I love Jamstack, so I started looking into Static Site Generators and feel they are a great tool. This was the tech that started my web development journey and you can definitely expect more posts on SSG's and Jamstack to come!

3. Started Blogging

I always wanted to have/start a blog. I love teaching others. I love teaching others through my experience even more. I like to be real with people and by starting this blog, I can help others learn to code, learn new tech, or help them solve a problem. Blogging is also a great way to document your journey, what you have learned and are continuing to learn. It makes writing a year in review recap blog post easier too! ;) I look forward to continuing to build my technical writing skills, document my journey, and helping others through blogging this coming year.

4. Skills Improved

Through this year I learned new technologies and improved upon my skills as a developer.

Python - have a deeper understanding and fluency in the language which helps me in my career
SQL - learned how to query and work with databases and continue to improve upon my SQL and database skillset at my day job
Static Site Generators - as mentioned above I love SSG's and feel they are a great tool for web development today. This year I used mainly two when developing and practicing my web development skills
- Eleventy - which this blog is built with
- Hugo - I find it easy to work with and fits my development process well
Tailwind - I used tailwind css to build this site and to be honest, feel I will use it on every project going forward. It is just a pleasure to use for me. I like keeping my HTML and styling together - less file switching and better efficiency.

Yes, 2020 was a year that will be remembered, for obvious reasons, but there was still a lot of good to come out of it!

I look forward to the new year as I continue to grow as an engineer, write more blog posts, and help others. Stay tuned for my next post on my goals and learning path for this year!

What was your biggest achievement of 2020? Follow me on Twitter and let me know!

Stayed tuned for my next blog here - on my learning goals for this year!

Originally posted @ Delisle Domain

How to Build Site Navigation with Hugo

Jay Delisle — Mon, 12 Oct 2020 04:00:00 +0000

I have been playing around with Hugo and doing research. I've come to find that there are a few different ways to build out the site navigation. This tends to be the case and differs from each static site generator. So how do we build out the site navigation with Hugo? Let's jump right into it!

There are a few different ways, but there are two main ways that I use and find the most useful. If interested in a more in-depth explanation of the different ways, check out this youtube video I found when figuring this out myself.

First, we'll go over the front matter option. Second, we will go over the completely customized navigation method. After explaining these two methods, we will see how to actually implement either option by looping over the menu option from either the front matter or custom navigation

Front Matter

Using the front matter on markdown pages is a quick and easy solution. This is especially nice for smaller websites that don't use an extensive amount of pages. If you want to make a markdown file be part of your navigation just add the following in the front matter of the file:

---
menu: "mainmenu"
---

You can name the menu anything you want. This will use the title attribute to name the actual navigation. Let's say you have a markdown file with the title of About Me, but you want the actual navigation link to say About. Then you would do the following instead of the above:

---
menu:
    mainmenu:
        name: "About"
---

This can be done anytime to allow you to determine the name of the navigation link.

Completely Custom Navigation

The above works well for a small site, but as the number of pages grows, it doesn't scale well. I tend to just use the custom navigation from the start, it flows well with how I develop and build my sites. To build the custom navigation, just go to the config.toml at the root of the Hugo project. Here we will add our custom menu. This will follow a similar pattern to the front matter when customizing the name. We will have our menu and then in that menu decide what the menu will be called - menu.nav. Again nav here can be named whatever you want to name the menu. Then for each navigation link, we will have:

identifier: used to identify this specific link
name: The name you want to appear on the site's navigation
url: The relative url to the page you want the link to go to
weight: another way of saying the order

The above would be done for each navigation link. The below code snippet is the example code for what we talked about above, having a home page, about, and contact.

[menu]
    [[menu.nav]]
    identifier = "home"
    name = "Home"
    url = "/"
    weight = 1

    [[menu.nav]]
    identifier = "about"
    name = "About"
    url = "/about/"
    weight = 2

    [[menu.nav]]
    identifier = "connect"
    name = "Connect"
    url = "/connect/"
    weight = 3

Implement the Navigation

Now, whether you used the front matter or custom navigation, we have to implement the navigation into the nav template file. To do so, I have a nav.html which holds everything in my <nav></nav> tag and I use this as a partial - love partials!. In Hugo, we can loop over these items using the range keyword and then dictate what menu to loop over. This would look like

{{ range .Site.Menus.nav }}

{{ end }}

The only thing that would be different for you possibly is again what you name your menu. I named mine nav so it is .Site.Menus.nav. If you kept the mainmenu from the template it would be .Site.Menus.mainmenu. Within this template block, you can now just write the normal HTML for the navigation. The final code should look similar to what I have below:

<ul id="nav">
    {{ range .Site.Menus.nav }}
    <li><a href=" {{ .URL }}">{{ .Name }}</a></li>
    {{ end }}
</ul>

I hope you were able to learn some of the options to implement navigation in a Hugo site. I encourage you again to check out the youtube video linked above which helped me at the start as well. Until next time - Stay Coding and check out my other posts on my blog here!

How to Get Tailwind Integrated With a Hugo Site

Jay Delisle — Sun, 04 Oct 2020 04:00:00 +0000

GoWind Boilerplate

I love static site generators. They are a great tool for backend work when it comes to whipping up sites quickly. This site (as of now) is built on eleventy and uses Tailwind for the styling of it. I wanted to expand my horizons and started to look at other static site generators. As I had said in my last post, I started to learn Go. After I started to learn about other SSG's I came across Hugo and wanted to give it a try with those incredibly fast build speeds! In case you haven't also noticed, I love Tailwind! So I needed a way to quickly get started on a site using Hugo and with Tailwind already integrated. I did some research and found a few good resources - listed at the end of the post.

With the help of the resources - I spun up a quick boilerplate repo for myself (and whoever else would like) to use as a project starting point. Welcome, GoWind! You can find the repo here. Below, I will go over the minimal steps needed to have Tailwind up and running in a great development environment workflow! You can follow these steps to know how GoWind works!

Let's Get Started

First, we must set up npm and install the needed dependencies. You can use

npm init -y

to quickly populate a package.json with all the default values in your project directory. Next, we must install the needed dependencies of Tailwind. I'm going to assume that you have Hugo installed and setup. To install the dependencies needed just run

npm install --save-dev autoprefixer postcss postcss-cli postcss-import tailwindcss

This will install tailwind and postcss with cli and import support.

Config Files

After we have the dependencies installed, we must create and code our config files. First, in the project root, create a directory/folder named assets and then another child directory named css. Within assets/css we are going to make 3 new files:

main.css - this is where our tailwind directives will go
postcss.config.js - this is where we will include tailwind as a postcss plugin
tailwind.config.js - this is our tailwind config file.

Main.css

Inside our main.css file, we are going to add our tailwind directives, which while generate the needed classes to use tailwind. This is quite simple, if you are unaware of how to do this, just check out the tailwind docs. Since we are using postcss-import we use the @import instead of @tailwind to avoid issues per tailwinds directions. The file should look like the below:

@import "tailwindcss/base";

@import "tailwindcss/components";

@import "tailwindcss/utilities";

Post CSS Config

In your postcss.config.js file we are going to dictate to postcss to include tailwind as a plugin, as well as postcss-import and autoprefixer. To do so we add the following code to the postcss.config.js file:

module.exports = {
    plugins: [
        require('postcss-import')({
            path: ["assets/css"]
        }),
        require('tailwindcss')('assets/css/tailwind.config.js'),
        require('autoprefixer')
    ]
}

Notice the path arguments for both postcss-import and tailwindcss. If you prefer to have your postcss.config.js and tailwind.config.js files in another location, just adjust your path to match that.

Tailwind Config

To automatically populate our tailwind.config.js file we can run the command:

npx tailwindcss init

This will create a tailwind config file at the root project directory with all the tailwind defaults. IMPORTANT - make sure you move this file to the location that matches the path arg in your postcss.config.js file for tailwind!

Add Tailwind to our HTML

Lastly, we must add tailwind to our HTML head area. One thing I love about Hugo and SSGs, in general, is the power of separating code into sections, and Hugo's partials do a great job at this for me. Hugo uses Go Templating language. So we first must declare a $styles variable like so:

{{ $styles := resources.Get "css/main.css" | postCSS (dict "config" "./assets/css/postcss.config.js") }}

Here we declare the styles var and use the Hugo functionality to get resources. Notice that the path to the css file is relative to the assets directory. After grabbing the css file, we then pipe it to postCSS. Also, notice that the dict argument is telling Hugo the location of the PostCSS config file.

The last part of the code we need to add to the HTML head helps us do something different depending if we are in production or not. If we are in production we want to minify the css and purge unused classes and reducing the file size. However, if we are in the development environment, we don't need nor care about this. To do this we add the following code:

  {{ if .Site.IsServer }}

  {{ else }}
  {{ $styles := $styles | minify | fingerprint | resources.PostProcess }}

  {{ end }}

The if .Site.IsServer tag determines if we are in development. It is a hugo boolean global variable that is true if using Hugo's built-in server, otherwise known as hugo server. If we are in development, we just use the css. However, if we are not using the server, we are in production and Hugo Pipes will minify and purge the unused css.

And that is it! We should be up and running and able to use tailwind's utility classes! Run your hugo server and add some HTML with Tailwind to make sure everything is working properly.

In my research to do this myself, I came across a great youtube video, seen here that helped me to understand the process. I modified it slightly and didn't use SASS like in the video. I like to keep things simple and just use pure CSS when needed.

That is all I have until next time - Staying Coding!

How to Style User-Generated Content with Tailwind CSS

Jay Delisle — Wed, 16 Sep 2020 04:00:00 +0000

Lately, I've been fiddling around with Tailwind css and Eleventy - (My site is built with them 😉 - love them 😍). I'm not going to talk about either of them in much detail, I'll have later posts for that! I did encounter a problem though and I had no idea how to solve it. So I wanted to quickly write about the problem and solution for others if they have the same issue.

The Problem

I had figured out how to style everything on my site using Tailwind - It is awesome and you should check it out if you haven't. I resonated with it as it goes along with my preference for writing HTML and not writing a lot of css. The problem was - I had no way of styling the user generated-markdown for my blog posts. At the time I had a few posts on the site and they weren't that good looking - which I knew and it was on my list of to-dos to update the UI of them. But I didn't know how to accomplish this. Static site generators convert markdown in HTML while using a template language that will inject content into the template language place holders. The code I had was as followed:

{{ content | safe }}

But how would I select just the <h1> tag in my blog posts and not all the h1 tags site wide?? or the <p> tags of the user-generated content from the post?

The Solution

Looking back, it was a simple solution, but at the moment I had no idea! After some quick google searching - I found quite the awesome solution. Just add a markdown class to the div holding the user-generated post! It is a simple solution and not something I came up with on my own - I came across this from the creator of Tailwind css himself on a forum - if you'd like to see the blog and forum where I found this info have a look here & here!

This allows for a way to specifically target the markdown generated HTML without the worry of selecting other tags site wide. So instead of my HTML looking like the above code block, it now has the added markdown class in the div as seen below:

{{ content | safe }}

PS - you can name the class whatever you like - I just stuck with the convention used in the blog post above as it seems the most intuitive. By adding this class selector I can now write some css in my main.css file to style my posts. And the best part?! I still can write it in tailwind using the @apply directive.

From here you can customize how you style your posts however you like! Again its a simple solution that I couldn't think of in the moment, but it is a great solution nonetheless!

Until next time - keep coding!

Check out my blog where this post was originally posted - Here

How To Get Started Making Your Own Python Package

Jay Delisle — Mon, 14 Sep 2020 04:00:00 +0000

Over the past few days - I've been looking into getting more involved in opensource - so I've been on Github just exploring different repositories and technologies. This got me thinking - how cool would it be to have a tool or program that could help other developers up on GitHub? Most of my stuff now is just websites - not full applications. But how do I start? How can I make my software available to others to use? After googling, I quickly realized I needed to make my own package! So here we will learn the basics of how to make your own Python package!

What is a Package

A python package is just a bunch of files that do something. Similar to a python module - which ends up just being a file.py (module) that can be imported for use.

Minimum Requirements

As I said above, this will go over everything needed at the most minimal level to create your own python package. So let's say you have this awesome idea for a package and you call it my_package - so original I know 🤣.

File Structure

The below shows the minimum files and directory structure needed.

📦 my_package
 ┣ 📂 my_package
 ┃ ┗ 📜 __init__.py
 ┣ 📂 tests
 ┣ 📜 LICENSE
 ┣ 📜 README.md
 ┗ 📜 setup.py

The root directory is the name of our package - my_package. Then inside this, we have another directory named the same thing. This is where all of the source code for the package will live - Don't forget the init.py file! At the root we also have

a tests directory for all unit tests
a LICENSE file so one can know the terms of use of your package - if you need help picking a license just visit HERE
a README written in markdown. This is where you explain all about your package like what it does, how to use it, how to download etc.
Last is the setup.py file which is used as the build script by setuptools. This file contains things like the name of the package, the version, description, author, and more.

Generating Release Requirements

After you have the needed files, we need to create the needed tools/files for a release, otherwise known as generating the distribution packages for the package. These tools can quickly and easily be installed with pip on the command line as follows:

python3 -m pip install --user --upgrade setuptools wheel

after installing these run the below command from the package root directory:

python3 setup.py sdist bdist_wheel

VOILA and just like, that you've generated what is needed for distributing the package.

Upload Your Awesome Package!

Now it is time to upload your package to the Python Package Index

You will need to register for an account (if you don't already have one) on PyPi.

We can use twine to now upload the package. First, you will need to install it if you don't already have it

python3 -m pip install --user --upgrade twine

Then run the below command to upload your package!

python3 -m twine upload dist/*

And just like that you now know what is the minimum needed requirements to upload a package to PyPi and be able to install that package with pip.

Few Notes

If you have questions on any topic here - take a look at this tutorial as it is what I followed to do so.

Also, note that the above tutorial shows how to also upload to TestPyPi and how to debug and make sure your package installs correctly etc.

Thanks for reading and can't wait to see what awesome package you come up with! Stay coding!

Originally posted on my personal blog: Check it out here!

Git Branch Workflows and What I Use

Jay Delisle — Thu, 03 Sep 2020 04:00:00 +0000

Git is an awesome developer tool! I highly recommend getting more familiar with it if you haven't done so already, especially if you're just starting in software development. A main component of Git are branches, which allow another user to take a snapshot of the upstream code, copy it, and then allow that user to add/modify/make changes without affecting the original (master) branches code. This is used in many different ways between developers and software companies, but all in all, have the same function - to allow a better workflow of software development.

Workflow Types

Basic Workflow

The basic git workflow is really simple and thus doesn't do very well with complications added to it. The master branch is remote. When developers want to work on something in the code, they work on it on the local level and when done commit and push to master. This approach is simple and will work fine for the lone developer making small websites, but for a team of devs, this is asking for trouble. This doesn't allow for the benefit of what branches provide.

Feature Branch Workflow

For a feature branch workflow, there is the master branch as in all workflows. Now let's say a developer has been assigned a task to add a new feature to the tool. He can create a new branch from the master and work on adding that feature independent of the stable production of master. While they are doing this, another dev can make another feature branch for a different feature. When the developer is done adding the feature, that feature branch can then be merged into master. This workflow keeps the feature branch and master separate, unlike the basic workflow.

Gitflow Workflow

The Gitflow workflow is a newer method that was developed by Vincent Driessen in 2010. It is very similar to the feature branch workflow but has a major difference. let's say that you are working with a feature branch workflow. The developer implements a new feature in a branch and then merges their feature branch into the production master... and it breaks the site! The major plus of a gitflow workflow is added support for development. There is a master branch that is always clean and live - it is the live production code. Then downstream is the development branch which can be run daily with testing. Then when a developer adds a new feature, they merge their feature branch into the development branch. In this instance, the development branch is run through a nightly run every night of tests to test code. The development branch is merged into the master production at set intervals twice a week. This workflow allows for the pros of the feature branch workflow but adds better functionality in terms of testing and verifying new features that have been merged into the development branch.

Branches allow developers to do a lot! There are more workflows but these are the ones that I have seen to be the most useful to me in my software journey. Do a google search of git workflows to learn of others, there is a plethora of info out there by people way more versed in this subject than I am!

Branch Workflow I Use

For this website, I use the Gitflow workflow. I have my master branch which I use as my production/live branch. Thanks to the awesome Netlify - whenever I push anything to the master branch - my site will automatically rebuild and deploy. Under master, I have my development branch. This is where I will do quick fixes and changes that won't take a while and where I verify any new code before again merging into production. Lastly, I make new branches for any new features or modifications. For example, when I rebuilt my site using TailwindCSS, I made a new feature branch tailwind_convert. Once completed this change in the new branch, I merged the code into master and deleted the branch.

How To...

Now for one of the reasons I wanted to write this post - so I can remember commands! It helps to have a place of reference for this.

Create a New Branch

git checkout -b new_branch_name

The above command will create a new branch and check it out at the same time. REMEMBER you want to be in the branch that you wanted the new branch to be downstream from.

Change Branches

git checkout branch_name_to_switch_to

Delete Branches

git branch -d branch_to_delete

Merge

git checkout branch_to_merge_new_code_into
git merge branch_to_merge_into_current_branch

I hope you learned something new here and if not, at least now have a place to pull up a quick reference of git branch commands when you can't remember!

As always - stay Coding!

Originally posted on my personal blog: Check it out here!