Blog | Mark Hernandez (lion-byte)

Fetch and Query Parameters

2020-04-05T00:00:00Z

Lately at work, I've been updating some front-end code to be more modern. Among the changes, I was swapping a lot of API calls to use Fetch instead of Dojo's xhr or jQuery's ajax. Fetch calls return a promise, so that meant that we could use it with async/await syntax. Although it's been easy to make this change, the Fetch API doesn't technically support adding query parameters to the URL for HTTP GET, unlike most other library implementations of this.

// Desired: GET `/api/item?q=test`
// Below will not work
fetch('/api/item', {
  method: 'get',
  body: JSON.stringify({ q: 'test' })
})
  .then(res => res.json())
  .then(data => {
    // ...
  })

While using encodeURIComponent could solve this, I felt weird seeing it written out. This would also pose an issue if there were multiple parameters needed or if some of the parameters were optional.

// Desired: GET `/api/item?q=test`
fetch(`/api/item?q=${encodeURIComponent('test')}`, {
  method: 'get'
})
  .then(res => res.json())
  .then(data => {
    // ...
  })

Thankfully, URL API and URLSearchParams helped clean up this code.

// Desired: GET `/api/item?q=test`
const url = new URL('/api/item', location.href)
url.searchParams.append('q', 'test')

fetch(url.toString(), {
  method: 'get'
})
  .then(res => res.json())
  .then(data => {
    // ...
  })

I really love how readable and flexible it is! We're also using Babel and core-js@3 in our builds, so the URL API is polyfilled automatically when needed! This code snippet might not be as succinct as just using a library's version of fetch, but I'd like to keep our build sizes lower if I can help it.

Year in Review - 2019

2020-01-18T00:00:00Z

Last year was wild all around.

Since I graduated from UNL December 2018, I was relieved of one source of constant anxiety. Although, I didn't have a job lined up beforehand, so I was pretty much scrambling to find interviews here in Omaha.

After about 2 months of searching and sending resumes, I was hired at National Indemnity Company. It was exciting to start my first full-time job, but I knew that I wasn't working with the latest technologies. Regardless, I did gain skills and techniques for working with legacy codebases.

Months passed, and I still felt like my already developed skills weren't being put to good use. I knew git and git workflows. I knew about writing pure/semi-pure functions and unit testing them. I knew so much modern JavaScript features and knew that they would never be used here. Obviously I was nit-picking what I didn't like, but I was really concerned about falling behind the rest of the industry.

Additional factors at work eventually led to my decision to find work elsewhere. Luckily, Derek Waskel, an old classmate of mine, reached out to me for a position at gWorks. It felt strange to leave a place only after 8 months, but I felt this was the best choice to make. I've been really satisfied being a part of the team here.

Last year, I wrote goals did not really meet them. To be fair, they were extremely vague and I had less free-time to focus on them. I've actually stopped having new year resolutions and opted towards a lookback approach; hence, this post. No one can tell the future, and I don't feel like disappointing myself with arbitrary goals.

Building RPJournal

2019-02-19T00:00:00Z

Past Situations

So I've been regularly playing tabletop role-playing games for a couple of years - with the occasional breaks. Some breaks have gone for up to to 6 weeks. Since we didn't really keep much notes outside of our character sheets, we had try to remember by scrolling up through our previous chat logs to make sense of the current plot.

That worked during the year and a half that the campaign lasted. I only wished we recorded more of the funny moments we said only over voice chat.

About 6 months passed, and I really wanted to get into another campaign. My other friend was excited to be our dungeon master for our local friend group!

Little Wishes for Improvement

This time around, he asked that someone be the note-taker for our sessions. Given that I had a lot of spare paper lying around, I took... initiative and offered to do it. While I wouldn't say these notes were exhaustive, they did help a lot months into our campaign.

As the notes spanned over about a dozen pages, I wanted to move towards a more compact format. I spent a couple days transferring my notes to a single Google Docs file with the same structure as my college class lectures. It's still my current solution, since I became very efficient with the learned shortcuts.

Although I am largely satisfied with typing it all out, I still find myself needing to keep a couple sheets and sticky notes at my side. I'm perfectly fine keeping my character's inventory on paper; that's always shifting. It's the other details like quests, NPCs, sketches/pictures, etc. I didn't want to maintain additional small files. I also wanted all this information to flow together well, like in many story-driven RPGs.

Prototype

After going through Wes Bos's Advanced React course, I decided to plan out my own solution for this need. Although my dependencies differ slightly from the course, the concepts really let me accelerate the process.

The application centers around three types of models: Adventures, Sessions, and Quests. Adventures are the main model that reference an RPG campaign or story, as well as the sessions and quests for it. The screenshot above shows the initial presentation of an Adventure page.

At this point, there's the usual create, read, and update functions for each data model. I put off deleting until after user authentication is added. I'm happy with the potential for this after setting up the basic version.

Later Plans

I planned a break between the prototype and the "phase II" start date so that I can use it and think about improvements. I'm definitely going to modify some actions to flow a little nicer, like creating and updating sessions. I'm not going to list all of my tasks here, but I am putting them in a GitHub project page. I'll write about it more once that phase is done and deployable somewhere.

Year in Review - 2018

2018-12-29T00:00:00Z

2018

Gatsby JS

I moved my personal site to Gatsby around February. There’s been plenty of design changes since then, but the framework still worked all the same to me. It’s been incredibly insightful in how I should organize my other projects. It’s also been a great introduction to tools like GraphQL. I’ve made a couple of mini projects with this framework with very little trouble!

GraphQL

Since Gatsby had a pleasant development experience, I decided to implement a GraphQL server and front-end portion using Apollo-Server and Apollo-Client, respectively. This was for a synthetic biology group to create safety diagrams. I built the whole application in less than 6 weeks!

VS Code

I moved from Atom to VS Code almost exactly a year ago. Throughout this year, I’ve enjoyed VS Code more and more. I used a lot less extensions compared to what I used in Atom, but I got way more productive afterwards with this. The Intellisense and TypeScript checking built-in made me enjoy documenting functions and methods since they provide helpful tooltips. It’d also helped with git commits and syncing with a slim git diff interface.

Styled-Components

This is more of a recent find, for me. This has quite easily replaced LESS for my use cases. I tried to do a similar file organization with LESS, but it was tedious to go back-and-forth between that and the related React component. Styled-Components has the nesting styles feature that’s also found in LESS and SASS. With that, I don’t think I’ll be using anything else since I usually stick with React. Cascading styles have never been an issue for me, since I make sure class names are unique, but this does make it less time-consuming for solo-/mini-projects.

First Conference Attendance: NebraskaJS

I’ve watched plenty of conference talks posted on YouTube, but there’s something special about seeing the talks live. However, feelings of imposter syndrome crept up on me as the day went on. I’m pretty sure I was one of the youngest in the audience. Despite that, I did get a glimpse of where I should move my focus for future projects.

Move to Omaha

For years, I lived in Lincoln on the UNL campus. My graduation was coming up later in mid-December, so I moved in with some friends in Omaha. I was always expecting to go to Omaha, since it’s more lively and active.

Future Goals in 2019

Working Out

This isn’t a surprising goal, but it’s always good to be active. I’ve been meaning to go back to the gym, but I keep feeling so self-conscious when I arrive. I need to stop that. Who cares about whatever I’m doing there (so long as I’m not putting myself in danger)? I'm definitely going to ease that anxiety with some Discover Weekly playlists on Spotify.

Art

I have plenty of sketchbooks, ink pens, and markers on my shelves. It’s been a long time since I used them, but I really love coming back to them every now and again. I’d like to revisit this hobby more often. At least create something beyond a sketch once a month.

Side Projects

I've made a JavaScript project generator, two gift websites for some friends, and this blog all on my free time throughout this year. That's not including development and contributions to the year-long senior design project or the safety diagram project. These side projects and other open-ended projects allow me to freely experiment with tools and formats! I'd like to continue doing so more often. There are new libraries and releases being developed, and I would like to at least play around with them.

Commuting and Podcasts

2018-12-15T00:00:00Z

Ha, well it's been a while since I last wrote a post here. Working on summer projects, finishing my last classes, and moving to Omaha filled up my past 6 months. During that time, I’ve been commuting to Lincoln, which was lengthy compared to having everything within 15 minutes.

For the first couple of months, I just had the radio playing. However, the signal to my favorite station gets hazy the closer I get to Lincoln. Other stations played either five songs on repeat or country songs. I grabbed my Spotify Discover Weekly for at least two months, but sometimes the algorithm missed my tastes pretty badly.

I mixed in podcasts between weekly playlists. It turns out that this was the perfect situation to listen and catch up on lengthy podcast episodes. They’ve made my 2 hours of driving per day something to enjoy rather than suffer!

My main collection of podcasts includes:

Syntax - This is all about web development, but they’re a lot more lively than most others on the topic.
Developer Tea - This podcast focuses on the human-side of software development: stress, goal management, the reasons behind fundamental rules in development, etc.
Wonderful! - An enthusiast podcast celebrating the small or large items or activities!
Shmanners - An etiquette podcast for often unspoken rules in special occasions.
My Brother, My Brother, and Me - A comedy podcast by three brothers giving advice comedically.

I’ve been listening to most of these for over a year; I came across Developer Tea only three months ago. I would wholeheartedly recommend checking out these shows if you’re curious.

JavaScript Crash Course

2018-07-10T00:00:00Z

I wrote most of this post roughly a year ago for my Design Studio team, since some of our team members have not used JavaScript before. This is only meant to be a starting point in learning JavaScript.

JavaScript Syntax

JavaScript is a loosely-typed language. Instead of using int, boolean, etc., to initialize a variable, var, let, and const are used instead.

Variable Initialization

Note: We will use only let and const.

// Cannot assign another value to this variable
const isEclipseFunky = true

let age = 12
let name = 'Tony'

// This is a plain object.
let allStar = {
  some: 'body',
  once: 'told me'
}

// List of numbers
let numberList = [1, 24, 25.01, 6, 0]

// Can hold mixed different types of data
let mixedList = [
  "I'm a string using double-quotes",
  'I am a string using single-quotes',
  `I'm a string using backticks`,
  12,
  false
]

Functions

Functions in JavaScript are a bit more flexible here. They can be assigned to variables and arguments to other functions.

const addNums = (a, b) => {
  return a + b
}

let addResult = addNums(1, 2) // 3

// Using a function as an input
// It will use the callbackFunction input within the function.
// Many APIs and libraries do this
function multiplyNums(a, b, callbackFunction) {
  const result = a * b
  callbackFunction(result)
}

// Note: The function is unnamed. It's fine if we only use it once.
multiplyNums(2, 12, function (answer) {
  console.log(answer) // 24
})

// Alternatively, we can write it like this:
multiplyNums(15, 3, answer => {
  console.log(answer) // 45
})

Classes

class Person {
  constructor(name, age) {
    this.name = name
    this.age = age
  }

  // This is a method
  introduce() {
    console.log(`My name is ${this.name}. I am ${this.age} years old.`)
  }
}

// New instance of Person class
let p1 = new Person('Marty', 15)
p1.introduce() // console reads: 'My name is Marty. I am 15 years old.'

// You can extend classes as well
class Student extends Person {
  constructor(name, age, id) {
    super(name, age)
    this.id = id
  }

  showId() {
    console.log(this.id)
  }

  // `introduce ()` still exists
}

Modules

You can have functions, classes, and constants exported from one file and required / imported in another.

Let's have a simple example. Assume that both files are in the same directory.

Exporting

// `math.js`

const addNums = (a, b) => {
  return a + b
}

function multiplyNums(a, b) {
  return a * b
}

// (1) Here's where we export the functions
module.exports = {
  addNums: addNums,
  multiplyNums: multiplyNums
}

// (2) Note: if the property name and variable names are the same
// like in the lines above, then it can be written as such:
module.exports = {
  addNums,
  multiplyNums
}

For JavaScript that is transpiled with webpack, parcel, or any other bundler, you can use the ES6 syntax for exporting.

// (3) Exporting as it is defined

export const addNums = (a, b) => {...}
export function multiplyNums(a, b) {...}

Requiring / Importing

// `index.js`

// This will import from `math.js` in the same directory
// (1) You can specify which functions, classes, or constants you want using this syntax. More on this in the links below
const { addNums, multiplyNums } = require('./math')

// (2) The other way is like this:
/*
  const math = require('./math')
  const addNums = math.addNums
  const multiplyNums = math.multiplyNums
*/

// (3) ES6 `import` syntax
/*
  import { addNums, multiplyNums } from './math'
*/

let addResult = addNums(2, 4) // 6
let multResult = multiplyNums(3, 7) // 21

Note: import / export is not available in Node.js natively at this time. Only module.exports and require().

There are other neat features to ES6 that you can learn in the resources linked below.

Node.JS

Node.js is a runtime environment that interprets JavaScript - similar to JVM for Java. Node.js lets a JavaScript program be organized into separate files/modules.

NPM

NPM is unofficially called the Node Package Manager. (Technically it's not an acronym according to the NPM team, but whatever.) This is used to manage JavaScript packages and projects.

package.json and package-lock.json

Node.js projects, like any other project, will have to manage dependencies. They also need to be tested, built, etc. Luckily, the package.json file holds all the information listed above!

The important sections in that file are as follows:

name - Project name
version - Project version
description - Project description
scripts - Command-line scripts that are run. It's way better save the commands here than trying to memorize them. (Or have them forgotten, and no one can run anything.)
main - Specifies the primary file where everything runs.
dependencies - Holds list of required dependencies for the project
devDependencies - Holds list of dependencies used only for development

All packages added to the project update the package-lock.json file. This file saves the specific versions and the dependencies' dependencies. This was added in version 5 of npm.

CLI Commands

NPM uses the package.json file to run the commands below

npm install <package-name> - adds package to dependencies
npm install -D <package-name> - adds package to devDependencies
npm run <command> - runs the appropriate script in the scripts section
npm start - equivalent to npm run start
npm test - equivalent to npm run test

Hopefully this gives you a clear idea about JavaScript and Node.js. I'll update this post as needed in the future. Linked below are some other tutorials or resources that may be helpful to you.

More Info/Resources

DevDocs - JavaScript
Learn ES2015 (Note: ES6 and ES2015 are different names for the same thing.)
The Modern JavaScript Tutorial
Node for Java Developers
What is Node.JS for Java Developers
Using a package.json

Design Studio, XKit, and TypeScript

2018-06-17T00:00:00Z

It's been over six weeks since my spring semester ended and a quite a bit has happened since my last post.

Design Studio

In my capstone course for my computer science major, I received a Rockstar Developer award for "outstanding work leading and contributing to the overall final product and growth of their team members." I am grateful for the peer nomination for the award. I loved being the team's Development Manager for in this year.

After the Design Studio showcase, I chose to keep working on the project as an Undergraduate Research Assistant for Myra Cohen. She was amazed at the outcome and welcomed my continued contribution to this and other undergraduate research projects. I'm looking forward to that!

XKit

Since I have had a bit of spare time outside of that project, I've been itching to contributing to an open source project, XKit.

Tumblr is a blogging platform that I use fairly frequently, and XKit feels like a must-have since there's so many enhancements. XKit is a browser extension that customizes and improves Tumblr's interface. There's a whole collection of enhancements available within the project. My favorite enhancement is "One-Click Postage" since it makes reblogging posts easier with less clicks.

XKit has been actively maintained since 2014 and has some legacy code to show. I love using the extension and wanted to lend any assistance I could provide. I started by improving their CI test speed by updating their configurations. It was minor but needed since they were using an unmaintained version of Node.

I then saw that only eslint was used in their test script. No unit or integration tests. Due to the project’s structure, their testing options were limited without doing a whole rework.

Initially, I wanted to modularize the project to allow more tests to be added. They've discussed doing so before in a GitHub issue labeled The Great Modularization Project#478. It became very apparent extremely quickly that this wasn't going to be an simple task.

The structure of the API revolves around a single god-object variable with parts of it being defined dynamically. Those were not great practices but that's due to the design choices made early on in the project.

Instead of tackling a large task, I thought it would be better to try and improve their test suite. That way, big changes can be made faster without the fear of breaking any features.

Given that unit tests weren't currently available, I looked into using TypeScript since it provides a type system on top of JavaScript.

TypeScript

When I first learned about TypeScript two years ago, I will admit that I was hesitant about using it. I felt fairly confident that I could do without it, so I just wrote it off as "JavaScript for those who know just Java."

However, after I swapped over to VS Code back in December, I noticed nice autocomplete suggestions that were very relevant. This was because of the Intellisense packed into the editor. It even gave type specific methods since it was using TypeScript as well! This, in my opinion, was a good way of introducing TypeScript.

I added TypeScript to my side projects in later months and found a couple uncaught faults. It was mostly just placing the wrong input in a library's function. The configuration was very simple, and the documentation was stellar!

So after trying it out, I decided to add TypeScript to the XKit project.

It's been a challenge to write the declaration file since the API docs are both incomplete and outdated in some places. I took time to look into the source code and took notes. I wrote a decent chunk of definitions before running tsc and there were around 700 marked errors.

Many errors came from type mismatches in some extensions. The rest of those were because some API methods were defined in another file. This was just recently refactored so that they're all in one file, which makes my task a lot easier.

This is still a work in progress, and I will be happy to make more contributions to this and other projects in the future.

Updating generator-lionbyte

2018-03-11T00:00:00Z

On March 9, 2018, I updated my package generator-lionbyte to v1.0.1!

Today, I want to share all the changes I made and my thoughts as I was working on it.

If you want to follow along or review the changes at your leisure, here are links to the version tags:

You can check the diffs on this page:

Compare changes from v0.4.0 to v1.0.1

Why I Decided to Update

I was using VS Code's debugger for Java for homework in my network communications class, and I thought it was a pretty great tool. I wanted to do a better job of debugging my JavaScript projects and rely less on console.log().

I did a quick search for any how-to articles and found one by Matt Rozema. Essentially, there were 3 options: debug the transpiled version, installing another package for debugging, or setting the IDE's configuration to use babel-node. All of these options seemed tedious to me, and I wanted to avoid it if I could.

Then I thought, "Maybe I don't need to use babel-node?" The feature I absolutely wanted to keep was async/await; they make it easier to work with Promises. According to node.green, that particular ES2017 feature is available all the way back to Node v7.10.1! I use the latest available Node version on my personal machines, so I'm content.

As I was looking through the page, I saw that ES6 import/export was not natively supported. I read Vance Lucas's article Don’t Transpile JavaScript for Node.js afterward. He basically reaffirmed that I came to the right conclusions. He mentioned that babel converts import/export down to require() and module.exports. It's still useful for client-side code, since webpack can parse and transpile it.

Thus, I decided to start updating my package.

Prettier

Although prettier doesn't necessarily affect the functionality, this basically helped save me from my past self. The last time I really worked on this project was around mid-December, so I should make everything easier to read and resume. I saw that prettier paired well with standard.

Removing babel-node Usage

This was tedious, but not difficult. I re-wrote the modules to use require and module.exports as needed.

Then I saw that the build scripts I wrote using gulp would be useless for Node.js specific projects. It was using gulp-babel to transpile the code, but I don't intend to write any code to be used for Node versions < 8.

Therefore, I decided that I don't need gulp anymore.

Removing gulp Usage

There were a lot of tasks, and I was using gulp-hub to let the tasks be split into separate files. The problem was, that took a long time to load all the separate files before running a single task.

The task files were distributed among the subgenerators. The server and default project types no longer needed them, so that was easy. In a way, it was pretty satisfying to delete all those files.

When I went to the static-site project type, I saw that it was heavily relying on gulp. It was... not the best, to say the least. I'm starting to realize that I was using way too much RAM during development with that configuration.

Using webpack@4 (Legato)

Since I was removing all gulp tasks, I thought it would be better to fully utilize webpack. Although it recently updated to v4, codenamed "Legato," it's a good chance for me upgrade my other projects using v3.

I previously only used webpack to package the JavaScript portion of a project. Now I'm letting it build and bundle everything. Most plugins have already updated to support this version, but some have to be installed with either @latest or @next. As of March 11, 2018, it is the following:

extract-text-webpack-plugin@next
html-webpack-plugin@latest

You can look at the webpack configuration files that I defined here.

Lessons Learned

Node.js versions > 8 already support all JavaScript features I want and more
prettier and standard code formatters are a nice pair
gulp is still pretty good, but has better use cases for it
webpack does so much for web development

Hello

2018-02-16T00:00:00Z

Hello! My name is Mark Hernandez, and I am a web developer.

Previous Site Attempts

Now this isn't the first time I've tried to build my personal site. I think I tried about two or three times? I deleted those versions, so I can't provide any visual comparisons.

Beginning

At first, I tried Jekyll. (This was all before I used NodeJS. Probably in my second year of college.) It was great, but running Ruby on Windows wasn't. I believe I was trying to use LESS instead of SASS. I couldn't modify it very much because I was missing some gems. I left it untouched for a long time and eventually scrapped it.

By all means, Jekyll is still a great static site generator and is very robust! The documentation is well-organized and thorough.

One and a Half Years Later

I had a pretty good understanding of NodeJS, React, Gulp, and Webpack. I made my custom Yeoman generator (generator-lionbyte) for myself to demonstrate my understanding of the tools.

I used this to try making my personal site again. Since I was using this custom configuration, everything had to be changed manually. I took a step back and searched for a better solution for myself.

Hello Gatsby

Now this... this is beautiful.

With Gatsby, I created this site within 2-3 weeks, and it's way better than anything I attempted to do before. All pages are built on React components. The development and build processes for Webpack were already configured! Most importantly, there's a huge ecosystem of plugins to extend Gatsby's abilities!

Where was I when this lovely static-site generator came out? This is probably going to be my go-to tool for any front-end portion of future projects!

Netlify Deployment

Originally, I was just deploying to GitHub pages. It's fine, but I wanted to use a custom domain name. Unfortunately, I wouldn't have had https if I stayed there.

After scrolling around on Twitter, I saw a couple tweets mentioning Netlify. It's incredible how simple it is to deploy there -- with https support too! It builds and deploys from my main branch on the repository.

Lessons Learned

Gatsby and Netlify are so great individually and together
Webpack does a lot more than what I realized
My appreciation for open source projects continuously increases

Blog | Mark Hernandez (lion-byte)

Fetch and Query Parameters

Year in Review - 2019

Building RPJournal

Past Situations

Little Wishes for Improvement

Prototype

Later Plans

Year in Review - 2018

2018

Gatsby JS

GraphQL

VS Code

Styled-Components

First Conference Attendance: NebraskaJS

Move to Omaha

Future Goals in 2019

Working Out

More Blog Posts

Art

Side Projects

Commuting and Podcasts

JavaScript Crash Course

JavaScript Syntax

Variable Initialization

Functions

Classes

Modules

Exporting

Requiring / Importing

Node.JS

NPM

package.json and package-lock.json

CLI Commands

More Info/Resources

Design Studio, XKit, and TypeScript

Design Studio

XKit

TypeScript

Updating generator-lionbyte

Why I Decided to Update

Prettier

Removing babel-node Usage

Removing gulp Usage

Using webpack@4 (Legato)

Lessons Learned

Hello

Previous Site Attempts

Beginning

One and a Half Years Later

Hello Gatsby

Netlify Deployment

Lessons Learned