Building a Family Tree with GraphQL – Part 2: Adding New Resolvers

In my last post, I described how you can build flexible APIs with GraphQL, using a family tree API as my demonstration. The implementation of the API was fairly simple, and I was able to traverse the graph of relationships between different people in the data set.

In this post, I’ll demonstrate how we can extend the same API to solve a problem with the first version. We can create new resolvers to fix a particular problem, but due to the nature of GraphQL, the same resolver can be used across many different queries. This unlocks more potential for the API without any extra development effort. Read more on Building a Family Tree with GraphQL – Part 2: Adding New Resolvers…

Mocking in JavaScript Unit Tests Using Sinon.JS

Lately, I’ve been using Sinon.JS for mocking in my unit tests. By using mocks for dependencies inside functions, I can write unit tests that are resilient to a changing codebase. Functions with mocks can also be developed without worrying about the chain of dependencies that could affect the logic inside the functions. Read more on Mocking in JavaScript Unit Tests Using Sinon.JS…

Using State Tables for Testing

Tests can benefit a project in many different ways. For example, they help ensure that the software behaves as expected. They also help document that functionality for pieces of code that other developers may have to maintain.

Lately, I’ve been using state tables in my tests to improve both of these benefits. State tables allow for clear and comprehensive tests that are scalable during the development. Read more on Using State Tables for Testing…

Naming Things Is Hard

When making software, you have to name a lot of things. There are functions, classes, numbers, data models, etc., and they all need meaningful names to ensure better communication within a team.

Over the past few months, I’ve noticed a few things that make naming things hard in a software project. These difficulties may be stressful, but they also highlight the benefits of good naming conventions.
Read more on Naming Things Is Hard…

Using Higher-Order Functions to Build Queries in Knex.js

My team has been using Knex.js to build database queries for our latest project. To create increasingly complex queries, we developed a pattern to generate SQL queries using higher-order functions. I’d like to share how we leverage these higher-order functions to make our query builders modular, concise, and very easy to understand.
Read more on Using Higher-Order Functions to Build Queries in Knex.js…

Three Tips for a Positive, Effective Team from Casey Watts

I recently heard the excellent talk “A Neurobiologist’s Guide to Mind Manipulation” by Casey Watts at EmberConf. Part of the talk focused on techniques for keeping a positive attitude, so no one shuts down or shies away from discussion during the project.

Basically, having positive, active teammates leads to a more effective team. Here are a few of the tips I took away from this talk.
Read more on Three Tips for a Positive, Effective Team from Casey Watts…

Timing Your Queries in Knex.js for Node.js

While developing web applications, I keep a close eye on performance issues, particularly in database queries. In my latest project, I’ve been using Knex.js, a SQL query builder for Node.js.

I developed a method of logging the queries executed by Knex.js as well as the execution times for each query. This method can be applied to nearly any application that uses Knex.js, and it uses a few features of Knex.js that I didn’t notice immediately, so I thought I’d share this small but useful bit of code.
Read more on Timing Your Queries in Knex.js for Node.js…

You Should Use Static Dates For Your Unit Tests

When writing unit tests for time-sensitive features, there are two ways you can define dates: dynamically or statically. When I say “dynamically defining dates,” I mean basing dates off of the current system time, as opposed to statically defined dates, which are hard-coded strings in the unit test.

Over the past few months, I’ve found that dates become much less of a pain to test when you use statically defined sample dates. They also lead to generally stronger test suites as a whole. Here are a few reasons why I think you should use static dates for your unit tests.
Read more on You Should Use Static Dates For Your Unit Tests…

Four Tips for Documenting a Legacy Codebase

Over the past few weeks, I’ve had the privilege of working with Microsoft’s Visual FoxPro. My task was to take a fairly large codebase and document its behavior so my team could rewrite the software in a modern language.

FoxPro is one of the most archaic languages I have ever worked with, and it poses quite the challenge when trying to decode the complexities found in this particular codebase. Read more on Four Tips for Documenting a Legacy Codebase…