DEV Community: Chase Adams

Understanding Structured, Non-Structured, and Semi-Structured Data

Chase Adams — Sat, 15 Jul 2023 00:00:00 +0000

Data. A simple four-letter word, yet it represents an intricate and expansive world of information. It's the raw facts, figures, and details that, when properly analyzed, give us invaluable insights.

Yet, data isn't a one-size-fits-all concept.

There are different kinds of data: structured, non-structured, and semi-structured. Each holds its own significance, use cases, and ways of interpretation.

Join me on this exciting expedition into the landscape of data types.

We'll dive into what each type entails, how they differ, and why each one matters.

Though data might seem daunting at first, gaining a clear understanding of these types is your first step towards mastery. So, buckle up and let's begin our data exploration!

Learning Outcomes

By the end of this blog post, here's what you'll have added to your knowledge toolbox:

An unambiguous understanding of the three main types of data: structured, non-structured, and semi-structured.
A handle on the unique attributes that set apart each type of data.
Exposure to tangible examples of each type of data in everyday life and business contexts.
Insights into the specific value and use cases for each data type.
A comprehensive understanding of the key differences between structured, non-structured, and semi-structured data.
A sense of how recognizing and distinguishing these data types can strengthen your data handling and analytical strategies.

Acquiring this knowledge about data types isn't merely about gathering information.

It equips you with essential tools to approach data more effectively, allowing you to work with data with the precision and foresight of a craftsman.

Whether you're a data professional, an aspiring data enthusiast, or a curious reader, these insights will help you navigate the world of data more confidently.

Let's embark on thit journey together!

Who This Is For

This blog post is designed for a wide audience, catering to various levels of familiarity with data:

Data Professionals: If you're a data scientist, data analyst, database administrator, or data engineer, this post will help reinforce your understanding and perhaps offer a new perspective on the types of data you encounter daily.
Tech Enthusiasts: If you're enthusiastic about technology and have a keen interest in learning about the data that fuels it, this post will provide you with a foundational understanding of different data types.
Career Shifters: If you're considering a career shift into the world of data or tech, this knowledge will prove instrumental in developing your understanding of how dat is classified and processed.
Academic Learners: For students and researchers in the fields of computer science, information technology, or data science, this post serves as a valuable resource to strengthen your academic understanding.
General Readers: Even if you don't belong to the above categories but are curious about data and its implications in our digital age, this post can quench your thirst for knowledge.

In essence, anyone who seeks to unravel the layers of data, comprehend its forms, and appreciate its power and potential, will find value in this exploration of structured, non-structured, and semi-structured data. Here's to the joy of learning together!

Unstructured Data: The Wild West of Information

If structured data is a well-organized bookshelf, then unstructured data is akin to a treasure chest, filled with an array of diverse and untamed elements, just waiting to be explored.

What is Unstructured Data?

Unstructured data refers to data that doesn't conform to a predefined model or schema. It's not organized in a pre-defined manner and doesn't follow a consistent format.

Characteristics of Unstructured Data

Variety: Unstructured data comes in many forms. It could be text files, social media posts, emails, audio files, videos, images, and more.
Unpredictable: Unlike structured data, unstructured data doesn't follow a predictable pattern. Its inconsistency can make it more difficult to process and analyze.
Voluminous: Given its varied sources, unstructured data often comprises the bulk of data that organizations and individuals handle.

Example of Unstructured Data

Consider a collection of customer reviews on an e-commerce website. The reviews can be of varying lengths, use different language styles, contain images, videos, or emojis, and don't follow a standard format.

The Value of Unstructured Data: When and Why it's Used

Unstructured data might seem like a messy treasure chest, but it holds valuable insights. With the right tools and techniques, like machine learning and natural language processing, these insights can be unlocked and used to improve customer experiences, make business predictions, and enhance decision-making processes. It's often utilized in sentiment analysis, predictive modeling, and other advanced analytics applications.

Structured Data: The Order in the Chaos

In the realm of data, structured data is like a well-organized bookshelf, where each book has its specified place, and you know exactly where to find what you're looking for.

What is Structured Data?

Structured data is data that adheres to a predefined model or schema. It's neatly organized and easy to understand because it resides in fixed fields within a record or a file.

Characteristics of Structured Data

Consistency: Structured data is consistent in nature. The format remains the same throughout the dataset, allowing for easier analysis and interpretation.
Organized: Like books on a well-ordered shelf, structured data is organized into rows and columns, which can be easily accessed and understood.
Searchable: Thanks to its organization, structured data can be easily queried. You can search for specific information using simple queries, almost as easily as picking a book from a shelf.

Example of Structured Data

Imagine a library catalog. It has fields for the book's title, author, publication date, and ISBN number. Each of these fields represents a column, and each book entry (or row) follows the same structure.

The Value of Structured Data: When and Why it's Used

Structured data shines when it comes to efficiency and accuracy. Its clear organization allows for quick searches and precise data analysis, which is invaluable in scenarios where time and accuracy are paramount. It's widely used in relational databases and spreadsheets, where the structured format lends itself well to tasks like data mining and statistical analysis.

Unstructured data, with its unexplored potential, adds an exciting layer to the world of data. But what if there was something that straddles the line between the strict order of structured data and the wild unpredictability of unstructured data? Enter semi-structured data, our next destination in this data exploration journey. Buckle up!

Semi-Structured Data: A Fusion of Worlds

In our data universe, if structured data is a well-ordered bookshelf and unstructured data is a treasure chest of assorted items, then semi-structured data strikes a balance between the two. It's like a garden: not as rigidly organized as a bookshelf, but not as chaotic as a treasure chest either. Each plant has its place, but the layout isn't uniform.

What is Semi-Structured Data?

Semi-structured data is a type of data that doesn't conform to the strict structure of data models, yet it contains tags or other markers to separate data elements and enforce hierarchies of records and fields.

Characteristics of Semi-Structured Data

Flexible: Semi-structured data allows for a level of organization without the rigidity of structured data. It offers a flexible model that can handle variations in the type of data.
Tagged: Elements in semi-structured data are often separated by tags or markers, which help in defining the hierarchy and order of the data.
Self-Describing: Unlike structured data, semi-structured data often includes metadata that provides information about the data itself.

Example of Semi-Structured Data

An excellent example of semi-structured data is a JSON (JavaScript Object Notation) file. It doesn't follow a strict tabular format, but its elements are tagged and organized in a way that represents the hierarchy and order of the data.

The Value of Semi-Structured Data: When and Why it's Used

The strength of semi-structured data lies in its flexibility. It can store complex and hierarchical data, making it suitable for situations where the data model might not be strictly defined or may change over time. Its typical use cases include data interchange between systems and storage of complex data structures, like XML files or emails.

Exploring semi-structured data completes our journey through the different types of data. But understanding the value of each in isolation is not enough. Up next, we'll see how these data types differ from one another, deepening our understanding of when to use which. Let's continue the exploration!

Structured vs. Non-Structured vs. Semi-Structured Data: The Comparative Landscape

We've journeyed through the individual worlds of structured, non-structured, and semi-structured data. But the world of data comes alive in all its glory when we understand these forms not just in isolation, but in relation to each other. Let's delve into the comparative landscape.

How They Differ

Organization: Structured data is neatly organized in rows and columns, like books on a shelf. Unstructured data is as diverse and untamed as a treasure chest of assorted items. Semi-structured data strikes a balance, akin to a garden where each plant has its place, but the layout isn't strictly uniform.
Searchability: The organization of structured data allows for easy querying, making specific information readily accessible. Searching unstructured data is more challenging due to its lack of uniformity, often requiring sophisticated tools. Semi-structured data, with its tagging and metadata, facilitates a certain level of searchability.
Volume: Structured data usually represents the smaller portion of an organization's data. In contrast, unstructured data often makes up the bulk, given its varied sources. Semi-structured data can vary in volume depending on the specific use case and the data sources involved.
Data Analysis: Structured data lends itself well to straightforward, traditional data analysis techniques. Unstructured data, on the other hand, often requires more advanced techniques like machine learning for extraction of insights. Semi-structured data can be handled using a combination of these methods, depending on its structure and complexity.

	Structured Data	Non-Structured Data	Semi-Structured Data
Organization	Neatly organized in rows and columns	Diverse and untamed	Strikes a balance between organization and flexibility
Searchability	Easy to query due to organization	More challenging due to lack of uniformity	Facilitated by tagging and metadata
Volume	Usually smaller portion of data	Makes up the bulk of data	Varies depending on use case and data sources
Data Analysis	Straightforward, traditional data analysis techniques	Requires advanced techniques like machine learning	Can use a combination of techniques depending on structure and complexity

Understanding these differences can significantly enhance your data management strategies, helping you decide what type of data to use when, and which analytical tools are best suited for the task. Armed with this knowledge, you're well on your way to becoming a true data craftsman!

Finding Value in Different Data Types: Harnessing the Power of Diversity

Understanding the differences between structured, non-structured, and semi-structured data is key, but what truly makes a difference is realizing how to harness their unique attributes in specific scenarios. Let's explore some use cases to illustrate how each type of data can be valuable.

The Power of Structured Data

Structured data is like a reliable friend. It's predictable, easy to handle, and straightforward in its communication. With its consistency and organization, it's an excellent choice for applications where accuracy and efficiency are critical.

Business Reporting: Whether it's a sales report, a financial analysis, or an inventory update, structured data provides the tabular, easy-to-analyze format necessary for such tasks.
Customer Relationship Management (CRM): CRMs typically store data in a structured format, such as customer names, contact details, and purchase histories. This allows for efficient searching and handling of customer information.

Unearthing the Potential of Unstructured Data

While unstructured data may seem like a challenge with its diversity and lack of consistent format, it hides gems of insights waiting to be unearthed.

Sentiment Analysis: Social media posts, product reviews, or customer feedback are often unstructured but are goldmines for understanding customer sentiment towards a product, service, or brand.
Voice of Customer (VoC) Programs: Unstructured data from customer calls or support tickets can be processed and analyzed to extract valuable customer insights, aiding in decision making and strategy development.

Leveraging the Flexibility of Semi-Structured Data

With the capability to straddle the line between structure and flexibility, semi-structured data offers the best of both worlds.

Web Data Extraction: Web pages, which are typically semi-structured, can be efficiently crawled to extract relevant information, useful for applications like price comparison, sentiment analysis, or brand monitoring.
Email Analysis: Emails, with their blend of structured (header information) and unstructured (body content) data, can be considered semi-structured. Analyzing email data can provide insights for communication audits, fraud detection, or customer service improvement.

Understanding the value and specific use cases of structured, non-structured, and semi-structured data helps in selecting the right data type for the right situation. It's like choosing the perfect tool from your data toolbox to craft a masterpiece.

Now, isn't that a valuable skill to have in our data-driven world?

Stay curious!

Code Review Process

Chase Adams — Fri, 24 Mar 2023 17:44:17 +0000

A friend asked me: "how do you generally approach code reviews? what's your mindset? do you have a checklist?"

Here's my process as it is now (it's iterated over time)!

My Process for Code Reviews

I do my reviews in 3 stages and 3 passes.

3 Stages

Pause - This is to orient me towards the person requesting review and towards curiosity.
Explore - Review the code, attempting to be curious and noticing any judgment or suggestions that come up
Suggest - Review the code again, adding comments for noticings and suggestions

Stage 1: Pause

This stage is about orienting, I don't look at the Pull Request.

Here are the steps I take in this stage:

I orient myself towards the person I’m doing the code review for. What do I know about their style? What do I know about their goals? How do I get into a mindset of energetic collaboration.
I place myself. How am I feeling outside of this code review? What have I experienced today? What are my feelings? I put anything that comes up in a note in Obsidian as a container and attempt to detach extrensic experiences and feelings from the review. This is important so that I don’t bring it with me into the review)
I orient myself towards curiosity. I want this review to start from curiosity. In tech, so much of what we have been taught matters is defensive and judgmental. It's not to say there isn't a place to assess the code and make suggestions, but the goal of this step is to reduce my ego as much as possible.

Stage 2: Explore

This stage is about going on an adventure in the Pull Request!

In this stage, I take these steps:

I orient myself towards the goal. I read the description. I attempt to rephrase it so I understand it. If any questions come up, I first verify they're not "suggestions disguised as questions" and if they're curious questions, I write them down.
I read the code a first time, starting at the top of the PR. I try to understand what's happening. I don't make notes. I don't add any comments. I just try to understand what is happening. I hold the code lightly. I notice places where I hit drag in reading. Usually drag indicates something isn't clearly. If I notice I hit drag, I write questions from curiosity about the drag. I make notes of if something came up as a noticing, judgment or suggestion but I don't add them to the Pull Request. I will make a note of where I think the execution context is at the end of the read for stage 3.
I read the code a second time, starting at the top of the PR. In the second run, I look for what wasn't clear on a first read. I look to my questions I wrote down. If they're related, I make them as comments. Any comments I add as questions to a review, I start with ❓ so they're easier for me to find later. I review the execution context I guessed on the first pass.

At this point I take a 15 minute break and do something else.

Taking a break allows my subconscious to sit with my two passes through the code.

Stage 3: Suggest

This stage is where I make suggestions based on my noticings of drag.

Here are the steps to my suggestions:

I read the code a third time, starting at the most obvious entrypoint to the execution context. At this point, I've seen the code twice and am oriented towards what it's doing.
I make suggestions where the intent is clear. I make suggestions in three cases: a fairly obvious security issue, a way to make the code more readable without sacrificing performance, performance benefits that don't reduce readability. In these cases I try to be really clear about what I noticed, which of these buckets I'm making a recommendation for and why I think the recommendation could make it a little better.
Notice where someone did great work! I try to notice where I appreciate that the requester has done something that crushes for me and tell them I appreciate it and why. I think this has 3 benefits. 1. They get a dopamine hit. 2. I get a dopamine hit. 3. I reinforce what I think matters in a codebase.

Some Quick Tips

Use Loom for comments. Add text to your comments, but also if you can, use a loom here and there and in the comment for the review. Looms help set emotional context for the person you're reviewing for.
Stay curious. This code is about a thing someone put effort into. Recognize that they put their energy into it, be grateful for that and ask yourself how you help amplify their efforts instead of snuffing out their energy.
Use emoji for comment types and share your heuristic. Emoji at the beginning of a comment (for example: "❔ I noticed I slowed down when reading this bit of code and I think it's because I don't understand what it's supposed to do, can you give me a summary of what you were trying to achieve with it?"). Emoji makes your comments easily scannable for both of you and helps set context for the comment.
Set navigation points in comments. This is hard to do, but it's always been well received when I do it. If you want to create a narrative about your review, use comment hyperlinks and document them in each comment for back and next. This helps the person you're reviewing for understand the narrative instead of having to go top to bottom.

Summary

The most important thing to notice here is that I attempt to do two passes of a code review before making suggestions.

This keeps me curious about what's happening and I think when I follow this, the experience is usually really positive for me and the person I'm reviewing the code for.

Share Specific Lines in a Markdown file with GitHub

Chase Adams — Sun, 24 Mar 2019 00:00:00 +0000

In the past, when I needed to share a specific line in a Markdown file from GitHub, I'd usually share a link to the Markdown file or a link to the fragment for the header closest to what I wanted to share and say, "look for X".

In this short GitHub protip, I'll share the hack I discovered that allows you to share specific lines from a Markdown file.

I'm using Hashicorps HCL repo as an example, but the concepts work with any Markdown file on GitHub. We're going to be sharing specific lines about how to write comments in HCL.

Sharing a line with GitHub UI

First, open a GitHub project and find the README.md ¹. (If you don't have one handy, feel free to follow along in the hashicorp/HCL repo.

You can see that the README.md is rendered as Markdown instead of source. In the file viewer, find and click README.md. The view this takes us to is also rendered as Markdown:

For our example, the part of the Markdown file that we want to share is "Single line comments start with # or //" and as you can see, there's not a way to do that from this view.

To select a specific line, we're going to use the Blame view. Click the Blame button in the top right corner of the content view:

The new view that we see has the source of the Markdown file, along with the line numbers! Now we can look for "Single line comments start with # or //" and to the left, click the line number (54 as of writing).

You should notice that the URL Location has changed to include a fragment at the end of it:

https://github.com/hashicorp/hcl/blame/master/README.md#L54

When you share this link, it will take the recipient to this page, at this line number and add highlighting to the line you referenced.

Sharing multiple lines with GitHub UI

If you wanted to share all of the lines regarding comments instead of just the single line comment, you can do that too! Click the line number you want to start on (again, line 54) and shift+click the line you want to end on (in this case, line 58).

This adds a URL fragment that looks like this:

https://github.com/hashicorp/hcl/blame/master/README.md#L54-L58

Now when the recipient follows this link it will take them to the file, go to line 54 and highlight lines 54-58.

Conclusion

This is currently the best way I know of to share specific lines in a Markdown file with GitHub. Hopefully they'll be listening and push out the change I've shared below so this post can become obselete!

For GitHub, if you're listening...

You've already nailed this UI with GitHub Actions, so if you're looking for small easy wins, consider applying the switcher for rendered blob and source blob:

This works for all markdown files, but this is the one that is most prolific/consistent. ↩

Writing Drafts in GatsbyJS & Netlify

Chase Adams — Sun, 10 Feb 2019 00:00:00 +0000

There are a few solutions out there for keeping drafts in GatsbyJS, but none achieved what I wanted. The ones I've found required graphql to do the heavy lifting to filter out drafts which meant a lot of filtering out anything where drafts was false. **If you don't care about the justification, you can skip to the code for how I write drafts in GatsbyJS.

Justification

These were the specifications that led me to the solution I use:

Easy to infer which articles are in draft state.
Single author not using Netlify CMS (works for multiple authors as well, but not required for me).
The production build/runtime of my site should be totally unaware of drafts.

Finding Drafts is Clear

I'm a huge advocate for reducing the friction of finding content that has a state of "Work in Progress". Having a separate directory explicitly for drafts helps me do that.

One of the downsides of using drafts in frontmatter is that you usually have to search through the frontmatter with a tool that can tell if a file is a draft (grep, ripgrep, etc) or keep the state in your brain (which is a bad use of a brain).

Single Author Hosting Content on Dropbox

I'm the only author on my Gatsby sites and use Dropbox to host my content. I think this solution could easily work for multiple authors using git as the "backend" (the way you might use Netlify CMS), but I haven't tried that with this pattern so mileage may vary.

I also use Dropbox to host my content and builds are done as a result of changes to files. Having a separate drafts folder allows me to write content without triggering unnecessary Dropbox/Netlify hooks.

Production Safety

I don't want to have a bunch of drafts filters in my GraphQL. I can't think of a compelling reason for GraphQL to filter drafts when I know that I I don't want drafts in production). Having a separate drafts folder reduces a lot of the complexity (and potential bugs) that would come with using GraphQL to do the same filtering.

How I Write Drafts in Gatsby

Now to the fun part: configuring Gatsby!

I have two content folders in my src directory:

content - the content ready for production
drafts - the content that I'm still working on

There are 3 "stages" of the content lifecycle:

Stage	`content` present	`drafts` present
Local Development	✅ (symlink)	✅ (symlink)
Non-Production Netlify	✅ (pulled at build)	✅ (pulled at build)
Production Netlify	✅ (pulled at build)	❌

The goal is to have a gatsby-source-filesystem for drafts in any non-production stage and to not even worry about it in production.

Setup for Gatsby Config

In my gatsby-config.js I have a Gatsby config object (rather than setting the object directly on module.exports):

const cfg = {
  /* ...my default configuration */
};

module.exports = cfg;

Then do a conditional check for the environment the environment where Gatsby is building my site (based on Netlify's environment contexts):

if (process.env.CONTEXT !== "production") {
  const draftsCfg = {
    resolve: `gatsby-source-filesystem`,
    options: {
      name: `drafts`,
      path: `${__dirname}/src/drafts`
    }
  };
  cfg.plugins.push(draftsCfg);
}

If process.env.CONTEXT isn't production, provide drafts as a filesystem source.

draftsCfg is a gatsby-source-filesystem plugin configuration object, where the sourceInstanceName of the content is drafts and the path to the content is the src/drafts directory inside of the project root.

Next we push the draftsCfg into the plugins object that Gatsby will use when it builds the site.

Now whenever Gatsby is run locally or in a non-production branch (because Netlify's preview branches are AWESOME!) and the build in the production environment is totally unaware of the fact that we have a drafts folder.

Caveat

A lot of this looks like it's dependent on using Netlify, but every hosting provider worth its salt provides a way to set environment variables. Netlify does it out of the box, so it was super convenient to hook into that, but it's not a show stopper if you're using another hosting provider.

Big ❤️ to GatsbyJS and Netlify for making this process super easy!

Emacs: Highlight $FlowFixMe comments

Chase Adams — Fri, 30 Nov 2018 00:19:37 +0000

I've been working with Flow a lot since joining Webflow and one of the things that I constantly miss is the // $FlowFixMe comments. I decided to highlight // $FlowFixMe comments in red so they stood out.

Emacs makes it trivial to add configuration to highlight specific lines based on certain criteria. In init.el or any file that you load configuration through, you can add the following:

  (defface flow-fix-me-comment '((t (:foreground "#ff0000"))) "Red")

  (font-lock-add-keywords
   'js-mode '(("// $FlowFixMe" 0 'flow-fix-me-comment t)))

Breaking it down:

defface allows us to declare a customizable FACE (you can think of FACE as a style). We're naming it flow-fix-me-comment
font-lock-add-keywords allows us to highlight a mode based on a specific keyword.
'js-mode is the mode we want to highlight on.
"// $FlowFixMe" is the term we want to use as the criteria for highlighting.
If the term matches the line, apply the flow-fix-me-comment FACE.

Make sure to eval-buffer on the snippet, reload your config or restart Emacs to see the changes take place.

The end result will look like this:

If you're using Emacs to develop for JavaScript and using Flow in your projects, this is a great way to make sure you don't get burnt by any $FlowFixMe comments during development!

Most Common Programming Case Types

Chase Adams — Mon, 06 Aug 2018 00:00:00 +0000

When working with computers—specifically while programming—you'll inevitably find yourself naming things (one of the two hard things in computer science).

A major factor of being successful in naming is knowing the type of case you want to use so that you can have a consistent convention per project/workspace. If you're writing software, you'll come across at least one of these in a languages specification for how it's written. Some languages (Go, particularly) rely heavily on you knowing the difference between two of them and using them correctly!

What You'll Learn

The most common case types:
- Camel case
- Snake case
- Kebab case
- Pascal case
- Upper case (with snake case)
How to use them for the following situations:
- naming files for a computer (my recommended best practice)
- writing code with Go
- writing code with Ruby
- writing code with JavaScript
- writing code with Python

camelCase

camelCase must (1) start with a lowercase letter and (2) the first letter of every new subsequent word has its first letter capitalized and is compounded with the previous word.

An example of camel case of the variable camel case var is camelCaseVar.

snake_case

snake_case is as simple as replacing all spaces with a "_" and lowercasing all the words. It's possible to snake_case and mix camelCase and PascalCase but imo, that ultimately defeats the purpose.

An example of snake case of the variable snake case var is snake_case_var.

kebab-case

kebab-case is as simple as replacing all spaces with a "-" and lowercasing all the words. It's possible to kebab-case and mix camelCase and PascalCase but that ultimately defeats the purpose.

An example of kebab case of the variable kebab case var is kebab-case-var.

PascalCase

PascalCase has every word starts with an uppercase letter (unlike camelCase in that the first word starts with a lowercase letter).

An example of pascal case of the variable pascal case var is PascalCaseVar.

Note: It's common to see this confused for camel case, but it's a separate case type altogether.

UPPER_CASE_SNAKE_CASE

UPPER_CASE_SNAKE_CASE is replacing all the spaces with underscores and converting all the letters to capitals.

an example of upper case snake case of the variable upper case snake case var is UPPER_CASE_SNAKE_CASE_VAR.

Which case type should I use?

Now that you know the various case types, let's tackle an example of my recommended best practice for filenames and when to use each case for Go, JavaScript, Python & Ruby.

What convention should I use when naming files?

Recommendation: always snake case

When naming files, it's important to ask "what's the lowest common denominator?" If you're not opinionated, I've found I've had the most success with snake case because it's the least likely to create a problem across filesystems and keeps filenames readable for "my_awesome_file".

If you're a Mac user or work with Mac users, it's a good practice to always use lowercase. Mac's have an HFS+ filesystem and since HFS+ is not case sensitive, it can read "MyFile" or "myfile" as "myfile".

My predominant argument for this stems from a particularly insidious "bug" I saw when I was running a CI/CD (continuous integration/continuous delivery) cluster. A CI job failed with "file not found: mycomponent.js" during a build for a React project. The developer swore the file was in the project's source, and as I dug through it, I noticed they had an import for "mycomponenet.js" but the file was named "MyComponent.js" (for a React project, where PascalCase is the convention for naming component files). Due to the way HFS+ handles file casing, it happily accepted that "MyComponent.js" was "mycomponent.js" at the time the developer (using a Mac) was writing the code, but ath the time the Unix based CI server was building it, it would fail because it expected exact casing to find the file.

Go Conventions

Go is the language where it's most critical to pay attention to case type conventions. The language decides whether a variable, field or method should be available to a package caller by if the name starts with a capital or lowercase letter.

Pascal case is required for exporting fields and methods in Go
Camel case is required for internal fields and methods in Go

package casetypes

type ExportedStruct {
    unexportedField string
}

In the above example, ExportedStruct is available to package callers for casetypes and unexportedField is only available to methods on ExportedStruct.

Javascript Conventions

Camel case for variables and methods.
Pascal case for types and classes in JavaScript.
Upper case snake case for constants.

React Conventions

I write enough React and it's unique enougn that it's worth calling out conventions here as a subsection:

Pascal case is used for component names and file names in React.

Ruby Conventions

Pascal case is used for classes and modules in Ruby.
Snake case for symbols, methods and variables.
Upper case snake case for constants.

Python Conventions

Snake case for method names and instance variables (PEP8).
Upper case snake case for constants.

Other Conventions

kebab case in Lisp.
kebab case in HTTP URLs (most-common-programming-case-types/).
snake case in JSON property keys.

Quick Comparison Table

Case Type	Example
Original Variable as String	`some awesome var`
Camel Case	`someAwesomeVar`
Snake Case	`some_awesome_var`
Kebab Case	`some-awesome-var`
Pascal Case	`SomeAwesomeVar`
Upper Case Snake Case	`SOME_AWESOME_VAR`

Now that you've been introduced to the most common case types, you're prepared to hop into most of the popular languages and know what conventions to keep when you're writing your own code!

How to Inspect a Collection of Objects in Javascript with console.table

Chase Adams — Mon, 30 Jul 2018 00:00:00 +0000

Learn how to inspect an array or object of objects with console.table in the browser.

When building software in JavaScript, I often need to inspect an array of objects or object of objects.

One of my favorite methods for achieving this is to use console.table(). Rather than having to toggle open nested objects that are of the same "type" (in this example we'll use some weird fishes), console.table() presents the data in a clean, tabular format. It's available in NodeJS as of version 10.0.0 and in almost every major browser.

In this tutorial, we'll learn how to use console.table() by creating an array of objects and calling console.table to inspect the data using NodeJS and Google Chrome.

`console.table()` signature

console.table(tabularData[, properties]) is a method that takes two parameters:

tabularData: a collection of data with any type
properties: an array of strings of the fields you want to use to display the table

Setup code

First, let's create a file for this example code called weirdfishes.js and create an array of weird fishes called weirdFishes:

let weirdFishes = [{
  "common_name": "common fangtooth",
  "scientific_name": "Anoplogaster cornuta",
  "family": "Anoplogastridae",
  "wikipedia_link": "https://en.wikipedia.org/wiki/Fangtooth"
}, {
  "common_name": "vampire squid",
  "scientific_name": "Vampyroteuthis infernalis",
  "family": "Vampyroteuthidae",
  "wikipedia_link": "https://en.wikipedia.org/wiki/Vampire_squid"
}, {
  "common_name": "blobfish",
  "scientific_name": "Psychrolutes marcidus",
  "family": "Anoplogastridae",
  "wikipedia_link": "https://en.wikipedia.org/wiki/Blobfish"
}, {
  "common_name": "dumbo octopus",
  "scientific_name": "Grimpoteuthis abyssicola",
  "family": "Opisthoteuthidae",
  "wikipedia_link": "https://en.wikipedia.org/wiki/Grimpoteuthis_abyssicola"
}];

Simple call to console.table()

We're going add a call to console.table() with weirdFishes passed in as the first argument:

console.table(weirdFishes);

If we call console.table with only the first argument, it will display all of the data inside of each object.

Inspect array of objects in NodeJS

Open your favorite terminal emulator application (I used VS Code's Integrated Terminal for the screenshots) and run node weirdfishes.js within the parent directory of weirdfishes.js. Note that this requires nodejs >= v10.0.0)

When we run the command, the console will display a table like this:

Inspect array of objects in the Browser (Chrome Example)

The easiest way to see this in action in Chrome is to add the object via the JavaScript console. To open the Javascript console, type cmd + option + j and a new pane should pop up at the bottom of the browser window.

Copy the JavaScript snippet from above and paste it into the JavaScript console, press enter and you'll see a table that looks similar to the screenshot below:

Constructing the table based on keys

Let's revisit the second parameter mentioned earlier: properties—an array of strings representing the values you want to display. Continuing in the browser example in the JavaScript console, call console.table with a second argument of ["common_names"]:

console.table(weirdFishes, ["common_name"]);

Calling console.table with the second argumend constructs the new table with only the index and the values of the keys in the array:

Using console.table on an object of objects

console.table also works for an object of objects (because an array is a type of object) and the index will be the key for the child objects. You can see an example of this by running console.table(roleModelsObj).

let weirdFishes2 = {
    "common fangtooth": {
        "scientific_name": "Anoplogaster cornuta",
        "family": "Anoplogastridae",
        "wikipedia_link": "https://en.wikipedia.org/wiki/Fangtooth"
    },
    "vampire squid": {
        "scientific_name": "Vampyroteuthis infernalis",
        "family": "Vampyroteuthidae",
        "wikipedia_link": "https://en.wikipedia.org/wiki/Vampire_squid"
    },
    "blobfish": {
        "scientific_name": "Psychrolutes marcidus",
        "family": "Anoplogastridae",
        "wikipedia_link": "https://en.wikipedia.org/wiki/Blobfish"
    },
    "dumbo octopus": {
        "scientific_name": "Grimpoteuthis abyssicola",
        "family": "Opisthoteuthidae",
        "wikipedia_link": "https://en.wikipedia.org/wiki/Grimpoteuthis_abyssicola"
    }
};
console.table(weirdFishes2);

You can see that the table now has the key for each object as the index:

Now you've got a great alternative to console.log for displaying objects in JavaScript in tabular form instead of nested data—an alternative that will save you time in inspection and debugging!

Full Page Webpage Snaphots with Chrome DevTools

Chase Adams — Sun, 29 Jul 2018 00:00:00 +0000

Learn how to take full page snapshots of a webpage using Chrome DevTools

Taking full-length screenshots of a webpage is useful for client work, keeping historical references of a website or when you want to have a webpage round-up gallery to show sites that you've found around the web.

In the past, if you needed to do this, you likely did it incrementally and stitched it together or installed a separate extension in your browser (most had varying results).

Recently when I was doing some mobile web development and checking how my site looked for various devices with Chrome DevTools, I noticed that Chrome has a baked in way of taking a full length screenshot!

Open DevTools. In the application menu click "View" , then "Develop" , then Developer Tools (Alternatively you can save some clicks with cmd+option+i on a Mac). You should have a new pane that has tabs for "Elements", "Console", "Sources" and more and below that you will likely see the HTML of the page you're currently on.
Toggle Device Toolbar. In the top left corner of the new pane, click the second icon from the left for "Toggle Device Toolbar". A new toolbar should open at the top of the browser's window with options to change the page to be emulate displaying different devices.
Take The Screenshot. In the new device toolbar, click the "More Options" button (3 vertical dots) in the far right corner and click "Capture Full Size screenshot".

Now you can take full size screenshots with ease and natively in the browser!

Using Current Date and Time In VS Code Snippets

Chase Adams — Tue, 24 Jul 2018 00:00:00 +0000

Previously when generating new blog articles, adding dates to Markdown frontmatter was a manual step that required me to:

Determine the date
Convert what I read into the date format I use for frontmatter

As of VS Code release 1.20, Snippets have access to the current date and time with one of the following variables:

CURRENT_YEAR
CURRENT_YEAR_SHORT
CURRENT_MONTH
CURRENT_DATE
CURRENT_HOUR
CURRENT_MINUTE
CURRENT_SECOND

Now if I want a frontmatter "date" for Markdown for the current year, month and day (YYYY-MM-DD), I can add the following to my snippet:

date: \"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE\"

Using the published date of this post, the expanded snippet produces:

date: "2018-07-24"

Enable tab completion for Markdown Snippets in VS Code

Chase Adams — Sun, 24 Jun 2018 00:00:00 +0000

While working on a frontmatter markdown snippet in VS Code I couldn't understand why tab completion wasn't working. It turns out that some extensions (including Markdown) don't have snippet tab completion enabled by default (you can however type ctrl+Space to show available snippets with what you've typed).

Enable snippet tab completion for all extensions

To enable tab completion in VS Code, open your User Settings (⌘+, in MacOS, ctrl+, in Windows) and add the following JSON:

"editor.tabCompletion": true,

Save your User Setttings configuration and your on your way to more efficient snippet usage for Markdown (and other languages)!