DEV Community: Derek Hopper

Build a simple Vue calendar without webpack

Derek Hopper — Wed, 26 Aug 2020 01:03:42 +0000

I needed a calendar (or a date picker) for a product I'm working on. In the past, I would have always reached for a library.

A calendar isn't usually something I want to maintain myself and the features in a library typically cover many different use cases. However, in this case, I wanted to see what I could build in a couple hours.

So, let's build a calendar with Vue. We'll use a single HTML file. We won't use webpack or babel. We won't need to compile or install anything at all.

Here's what the end product will look like.

Derek

@derekjhopper

First time using date-fns.org and I was able to cobble together a working calendar component in Vue in a couple hours. A delightful experience.

In the past, I would always reach for a library because I thought calendars were too complex to manage myself.

15:21 PM - 22 Aug 2020

0 0

We'll start with this template. It contains everything we'll be using to get the job done.

tailwind: a utility-first CSS framework
vue: a JavaScript framework for building user interfaces
date-fns: a date utility library
lodash: a utility library

<!DOCTYPE html>
<html>

<head>
  <title>Calendar.vue</title>
  <link href="https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css" rel="stylesheet">
  <script src="https://unpkg.com/vue"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/date-fns/1.30.1/date_fns.min.js"
    integrity="sha512-F+u8eWHrfY8Xw9BLzZ8rG/0wIvs0y+JyRJrXjp3VjtFPylAEEGwKbua5Ip/oiVhaTDaDs4eU2Xtsxjs/9ag2bQ=="
    crossorigin="anonymous"></script>
  <script src="https://cdn.jsdelivr.net/npm/lodash@4.17.20/lodash.min.js"></script>
</head>

<body class="py-12">
  <div class="container mx-auto flex justify-center">
    <div id="calendar" class="w-1/3 rounded border">
      &nbsp;
    </div>
  </div>

  <script>
    var app = new Vue({
      el: '#calendar'
    })
  </script>
</body>

</html>

To start, it's helpful to think about how a calendar can be represented in a data structure. This is how I thought it could look.

var august2020 = [
  [null, null, null, null, null, null, 1],
  [2, 3, 4, 5, 6, 7, 8],
  [9, 10, 11, 12, 13, 14, 15],
  [16, 17, 18, 19, 20, 21, 22],
  [23, 24, 25, 26, 27, 28, 29],
  [30, 31, null, null, null, null, null]
]

I wanted a data structure that could easily map to DOM elements. If we look at august2020, we can see how each array could be a row in the calendar and each value inside the array could map to a div. null values would be an empty div.

The challenge is that we need to build this data structure anytime the month is changed. A month can start and end on any day of the week, so we need to come up with an algorithm.

Let's get started.

We're going to need three functions. One to get the first day of the month, one to get the last day of the month, and one to get the number of days in the month. We'll use those functions to determine where to start drawing our calendar. In other words, how many empty elements do we need before we draw 1 and how many empty elements do we need after we draw 31.

var app = new Vue({
  el: '#calendar',
  data: {
    // August 1, 2020
    date: new Date(2020, 7, 1)
  },
  computed: {
    startOfMonth: function() {
      return dateFns.startOfMonth(this.date)
    },
    endOfMonth: function() {
      return dateFns.endOfMonth(this.date)
    },
    daysInMonth: function() {
      return dateFns.getDaysInMonth(this.date)
    }
  }
})

The dateFns object is provided by date-fns. The functions we're calling do what you'd expect them to do (awesome, right?).

Once we have the beginning and the end of the month, we have enough to build the august2020 data structure shown above. What we'll be building are the weeks of August 2020. We'll use the weeks to display the month of August 2020 on the page.

<body class="py-12">
  <div class="container mx-auto flex justify-center">
    <div id="calendar" class="w-1/3 rounded border">
      <section>
        <ul v-for="(week, weekIndex) in weeks" :key="weekIndex" class="border-t">
          <li>
            <ul class="flex">
              <li v-for="(day, dayIndex) in week" :key="`${weekIndex}-${dayIndex}`" class="flex-1 p-1 text-center border-r last:border-r-0">
                {{day && day.getDate()}}
              </li>
            </ul>
          </li>
        </ul>
      </section>
    </div>
  </div>

  <script>
    var app = new Vue({
      el: '#calendar',
      data: {
        // August 1, 2020
        date: new Date(2020, 7, 1)
      },
      computed: {
        startOfMonth: function() {
          return dateFns.startOfMonth(this.date)
        },
        endOfMonth: function() {
          return dateFns.endOfMonth(this.date)
        },
        daysInMonth: function() {
          return dateFns.getDaysInMonth(this.date)
        },
        weeks: function() {
          var firstDayOfWeek = dateFns.getDay(this.startOfMonth)

          var days = []

          for (var i = 0; i < firstDayOfWeek; i++) {
            days.push(null)
          }

          for (var i = 1; i <= this.daysInMonth; i++) {
            days.push(dateFns.setDate(this.date, i))
          }

          var lastDayOfWeek = dateFns.getDay(this.endOfMonth)
          for (var i = 0; i < 6 - lastDayOfWeek; i++) {
            days.push(null)
          }

          return _.chunk(days, 7)
        }
      }
    })
  </script>
</body>

The result of the above code looks like this. Let's break it down.

Once we determine the first day of the week (August 2020 starts on a Saturday), we can figure out how many blanks we need. In this case, we need six blanks. A loop that goes from 0 to 5 will give us just that. At this point, the days array looks like this: [null, null, null, null, null, null].

for (var i = 0; i < firstDayOfWeek; i++) {
  days.push(null)
}

At this point, we can add days 1-31 since we know there are 31 days in August. A loop that goes from 1 to 31 can get the job done. Instead of using integers, we push in Date objects. We use dateFns.setDate(this.date, i) to get a new date object set to the value of i. This will come in handy for other purposes.

After this look executes, days is an array with 6 null values followed by the integers 1 to 31.

for (var i = 1; i <= this.daysInMonth; i++) {
  days.push(dateFns.setDate(this.date, i))
}

Finally, once we're done with that, we can use the last day of the month to determine how many blanks we need to fill in the rest of the calendar. August 2020 ends on a Monday, so we need to fill in five blanks to finish. A loop that goes from 0 to 4 is here to help.

for (var i = 0; i < 6 - lastDayOfWeek; i++) {
  days.push(null)
}

Now, let's add some labels. To do that, we need a little HTML and a formatting function. We want to display August 2020 at the top with labels for each day of the week.

We'll add the following to our Vue template directly above the <section> for displaying the weeks and days.

<section class="flex">
  <h2 class="flex-grow text-center text-lg font-bold">{{month}}</h2>
</section>
<ul class="flex bg-gray-100 border-t text-gray-600">
  <li class="flex-1 text-center border-r last:border-r-0">S</li>
  <li class="flex-1 text-center border-r last:border-r-0">M</li>
  <li class="flex-1 text-center border-r last:border-r-0">T</li>
  <li class="flex-1 text-center border-r last:border-r-0">W</li>
  <li class="flex-1 text-center border-r last:border-r-0">R</li>
  <li class="flex-1 text-center border-r last:border-r-0">F</li>
  <li class="flex-1 text-center border-r last:border-r-0">S</li>
</ul>

And the function for month is a simple one as well. Again, dateFns is provided by date-fns and we use its format function. 'MMMM YYYY' just says give us a string representation of the date that looks like August 2020.

function() {
  return dateFns.format(this.date, 'MMMM YYYY')
}

Doing that gets us to this point. Here's what the calendar looks like n ow.

The last thing we need to do is allow ourselves to navigate to the previous and next months. This is the fun part. Everything we've done so far is setting us up to use Vue's most powerful feature: reactivity.

Whenever date changes, Vue will re-use the code we already wrote and draw a new calendar based on the new date. So if we change the date to be July 2020, we'll get a July 2020 calendar drawn for us. Let's do it.

First, we need a couple links to click on. We need a link that says "Previous" and a link that says "Next". Something like this will do just fine.

<section class="flex">
  <a class="ml-4 flex-shrink cursor-pointer text-gray-800 underline">Previous</a>
  <h2 class="flex-grow text-center text-lg font-bold">{{month}}</h2>
  <a class="ml-4 flex-shrink cursor-pointer text-gray-800 underline">Next</a>
</section>

As you might be able to tell, these links don't do anything. We don't have them hooked up to Vue at all, but that's easy enough - let's do it. We'll need a method and then tell the links to call that method when clicked. The previous link will decrement the month by 1 and the next link will increment the month by 1.

// ...
methods: {
  changeMonth: function(by) {
    this.date = dateFns.addMonths(this.date, by)
  }
}
// ...

<section class="flex">
  <a v-on:click="changeMonth(-1)" class="ml-4 flex-shrink cursor-pointer text-gray-800 underline">Previous</a>
  <h2 class="flex-grow text-center text-lg font-bold">{{month}}</h2>
  <a v-on:click="changeMonth(1)" class="ml-4 flex-shrink cursor-pointer text-gray-800 underline">Next</a>
</section>

When we click on the previous link, Vue calls our function with -1 as the argument. Then our function adds -1 months to the current date (which is August 1, 2020). This tells Vue to re-render our component with July 2020 as the current date. We're done.

If you'd like to view the full version, check it out on JSFiddle. Feel free to copy and paste this to your local machine and play around with it.

If you found this helpful, follow me on Twitter.

Using SQL with ActiveRecord for performance gains

Derek Hopper — Sat, 22 Aug 2020 00:52:01 +0000

While working on a side project, I had a need to count items by day of the month. While this can likely be achieved in Ruby, I reached for SQL instead.

I have a table called journal_entries. It has the following columns.

   Column   |              Type              | Collation | Nullable |                   Default
------------+--------------------------------+-----------+----------+---------------------------------------------
 id         | bigint                         |           | not null | nextval('journal_entries_id_seq'::regclass)
 journal_id | bigint                         |           |          |
 body       | text                           |           | not null |
 created_at | timestamp(6) without time zone |           | not null |
 updated_at | timestamp(6) without time zone |           | not null |
 metadata   | jsonb                          |           | not null | '"{}"'::jsonb

For a given journal, I wanted to count the number of journal entries per day. To do that, I ended up with a method called entries_by_day.

def entries_by_day
  journal
    .journal_entries
    .where(created_at: interval)
    .group("extract(day from created_at AT TIME ZONE '#{Time.zone.formatted_offset}')::int")
    .count
end

For the most part, this is a normal ActiveRecord query. We're querying for a journal's journal entries within a given interval. In our case, an interval would be something like July 1, 2020 to July 31, 2020.

Then, we use the group method which is pretty cool. This translates to a GROUP BY in SQL. To group the rows, we use the extract function provided by PostgreSQL (documentation).

What we're saying is this. Give me the day (1, 2, 3, ..., 31) based on the timestamp. If the timestamp is 2020-08-11 19:05:59.508883, extract would give us 11.

What we end up with is a Hash with the days as keys and the count as values.

{25=>3, 29=>2, 27=>2, 23=>2, 24=>2}

This has the advantage of offloading performance concerns to the database. PostgreSQL can typically do these types of operations faster.

If we were to attempt the same in Ruby, we would need to query for all of the records within the month of July. Then, we'd have to use Ruby's group_by method to finish the job.

Heroku is still the best way to start a hobby project

Derek Hopper — Sun, 16 Aug 2020 15:02:04 +0000

The most important step when you start a project is to get it deployed somewhere, anywhere. Running your code in your local development environment is great, but getting your deployment workflow setup is the holy grail.

When I started a hobby project about a month ago, I searched and searched for Heroku alternatives. In the past, I knew Heroku had a tendency to be costly. Heroku can also lack flexibility in certain situations.

After what seemed like an exhaustive search, I gave up. There are alternatives to Heroku, but nothing caught my eye. I had used AWS Elastic Beanstalk for a product in the past, but the initial setup took hours I didn't want to spend.

Ultimately, here's what I wanted in a service

Automated deployment when merging to master
Automated deployment when the tests pass
One click setup of the database, Redis
Process monitoring for Sidekiq
Easy, simple cron
Easy, simple scaling

To this day, Heroku still checks all those boxes. Even more so, everything has improved since I last used Heroku.

I booted up my Heroku account and started looking around. To my surprise, there was a lot I could scale up for free.

What I got out of Heroku

A small PostgreSQL database
A small Redis instance
Cron
A single web dyno
A single Sidekiq dyno
Automated deployments integrated with CircleCI
Bonus: Free Mailgun
Bonus: Free Sentry

I did all of this with minimal configuration. I didn't write any YAML. I don't deploy via the terminal. I don't worry about processes being killed.

The only annoyance is dynos going to sleep. Since the product I'm building isn't in production yet, that's not a big deal.

However, what I do have is a complete deployment workflow and somewhere to ship my code automatically. Instead of worrying about DevOps, I can focus on building. That's worth a lot to me.

Don't be a meanie when contributing to open source

Derek Hopper — Thu, 02 Jul 2020 01:23:58 +0000

In 2019, I replied to a post here on DEV about contributing to open source. After a year (and 10 years of COVID), it feels like a good time to share those tips again and expand on what I wrote.

Give thanks

Whether you're reporting an issue or opening a pull request, thank the author(s) for their work. To me, this becomes especially important if you're using their code in one of your projects.

This is a great time to thank them for making your life easier. Use this as a chance to start off on the right foot.

Read their contribution guidelines

Many projects these days have a few places to help you get started.

First, look for a file named CONTRIBUTING.md and read it. Often, this file will include information on how to report issues, open pull requests, and other ways you may be able to contribute.

Second, watch out for CODE_OF_CONDUCT.md and read it carefully. Think of this file as a primer before you communicate to anyone on the project. Be mindful and stay within the rules of the project.

Lastly, use DEV as an example. Here's the CONTRIBUTING.md and CODE_OF_CONDUCT.md.

Unsure? Open an issue and discuss it

If the CONTRIBUTING.md file doesn't explain what the project is open to accepting, use an issue to propose your change. Politely ask the project if it's something they'd be interested.

This can apply to bug fixes and is gravely important for new features. If you don't want to be disappointed, don't spend time working on a feature the project may not be interested in accepting. Some projects simply don't accept new features anymore.

Find a bug? Provide a failing test case

The best way to communicate a bug is to either provide a failing test case or the steps to reproduce it.

If you know the language the project is written in, fork the repository and write a test proving the bug you're reporting. Give a link to your fork when opening the issue.

If you don't know the language or you're unsure of how to write the test, try to give as much information as possible. Explain how to reproduce it. This is a good time to check the CONTRIBUTING.md file where they may have a template for reporting issues.

Make yourself available

Once you open an issue or pull request, don't go radio silent. Be ready to respond in a timely manner if the maintainers have questions.

Your work is much more likely to be accepted if you're willing to work with the maintainers to make it so. Maintaining an open source project is a time consuming endeavor. Anytime you can save the maintainers is a job well done.

Follow the conventions

This is a guideline you can use anywhere where software is developed. Try to stay within the conventions of the project.

If the project uses four spaces for indentation, use four spaces - not two. If the project uses tabs instead of spaces, use spaces - just kidding, use tabs.

This even goes as far as how tests are written. Try to follow the patterns laid out by the project. This increases the likelihood of your code being merged.

Explain as much as possible

Once you've worked hard to finish a pull request, try to be a good writer and explainer. Share why you did things a certain way. If you're unsure of a particular section, point that out.

Your goal should be to make it easy on the maintainers of the project. Don't be afraid to point out rough sections of the code or parts that may not make sense to the next person that reads it.

Imagine the maintainer knows nothing about what you did.

Be nice

Finally, nobody is going to get mad at you for being nice. Someone that's easy to work with is usually better than someone that's not.

It's common for open source maintainers to do their work in the moonlight. Be a pal and avoid getting frustrated if things take longer than you think they should. Ask if there's anything you can do to help the process along.

What about you?

Do you have any examples of issues you've reported or pull requests you've opened and you followed some of these guidelines?

How to choose the right HTTP status code

Derek Hopper — Wed, 24 Jun 2020 00:07:41 +0000

Take a look at the following code. It's a jQuery $.ajax request asking for a cast member of The Office.

const message = document.querySelector('#message');

$.ajax({
  url: "/status/Michael",
  dataType: "json",
  success: (data) => {
    if (data.error) {
      alert(data.error);
    } else {
      message.innerHTML = data.message;
    }
  }
});

If the response includes an error property, the request is considered an error and we alert the user. Otherwise, a message is shown about the character.

This works. However, it's a little contradictory and some might consider it a code smell. After all, we're handling errors inside the success callback. This is a clue that something should likely be changed on the server.

Since we have to handle both cases within the success callback, we have a fairly good idea the server is returning a 20x status code for both successful and bad requests. Taking a peek at the server, this is what we might see:

class StatusesController < ApplicationController
  CHARACTERS = ["Michael", "Dwight", "Angela"]

  def show
    if CHARACTERS.include?(params[:name])
      render json: { message: "#{params[:name]} is a character on The Office." }
    else
      render json: { error: "Oops. There's an error." }
    end
  end
end

This is the JavaScript we would like to write. We'd like to use both a success and an error callback. This code reads a little better now. We can clearly see what happens when a request is successful or a request has an error. We don't have to concern ourselves with a conditional.

const message = document.querySelector('#message');

$.ajax({
  url: "/status/Michael",
  dataType: "json",
  success: (data) => {
    message.innerHTML = data.message;
  },
  error: (jqXHR) => {
    alert(jqXHR.responseJSON.error);
  }
});

Once the server returns a 404 Not Found, we can start using the error callback. We might update the server to look like this. Notice how we've added a status to both cases.

class StatusesController < ApplicationController
  CHARACTERS = ["Michael"]

  def show
    if CHARACTERS.include?(params[:name])
      render json: { message: "#{params[:name]} is a character on The Office." }, status: :ok
    else
      render json: { error: "Oops. There's an error." }, status: :not_found
    end
  end
end

Previously, as we know, the server was returning a 200 OK status code for both cases. After our update, :ok refers to the status code of 200 OK while :not_found refers to 404 Not Found. This allows our $.ajax call to route the response to the corresponding callback based on the response's status code.

This short example illustrates the importance of status codes and how a status code can affect anyone developing against it. When you're thinking about the implementation for a new endpoint or route, take a moment to think about what status code makes sense. A status code can have an effect on many things.

What to watch out for

Other developers

As you saw in our example, a status code can have an influence on how a frontend developer builds against the backend. Oftentimes, we need to fetch data from the backend and the status codes can influence how this is done.

If a status code is unexpected, you might see a weird bug. If we didn't know our server was returning a 200 OK for both successful and bad requests, our customers might run into interesting scenarios.

Security

Picking the wrong status code can provide clues to an attacker. For example, returning a status code other than 404 may give an attacker a clue that a given resource exists on the server.

Take a look at this excerpt from the GitHub API documentation on authentication.

There are two ways to authenticate through GitHub API v3. Requests that require authentication will return 404 Not Found, instead of 403 Forbidden, in some places. This is to prevent the accidental leakage of private repositories to unauthorized users.

If we give out clues that a private resource exists, we begin to lose trust with our customers.

SEO

If you have public endpoints, be careful when changing the status code. Using the wrong one can yield unexpected results.

When introducing a redirect, it's considered best practice to use 301 Moved Permanently. A search engine will pass along any link juice to the new URL. If you use a 302 Found, it might not.

Take a peek at respected literature on SEO and status codes if you're in doubt or you'd just like to learn.

Reference Material

Wikipedia: List of HTTP status codes: A raw list of standard status codes.
Mozilla: HTTP response status codes: Explains the common use cases for each status code.

What's your experience with status codes? Have you been a part of any interesting debugging sessions with status codes?

How have you used static site generators to creatively simplify things?

Derek Hopper — Wed, 12 Dec 2018 17:11:46 +0000

If what you normally use to build applications is a framework like Ruby on Rails, it becomes easy to use that tool for everything. Simple is often better. Sometimes using a static site generator is the better long-term option.

Do you use static site generators like jekyll or gatsbyjs to do neat things? What use cases have you found best served by static site generators?

Thank You, 10 Open Source Projects that Helped Build a Business

Derek Hopper — Wed, 21 Nov 2018 17:19:39 +0000

Many of us likely benefit from the countless hours of effort put forth by open source contributors. We build businesses, serve customers, and learn so much standing on the shoulders of significant and valuable contributions by people who don't often get the recognition they deserve.

If you're building software on the web, it's almost a certainty you've used software written by someone else. I hope this list will remind you to reflect on the open source software you use to build your apps and your businesses.

Finally, in the spirit of giving thanks, here are 10 open source projects we've used to build a business. These projects help us solve problems for customers so they can run their business successfully. Without these projects, we wouldn't be able to do some of the things we're doing.

1. rspec

https://github.com/rspec/rspec

Without rspec, we'd be lost. It's our setup of choice to write tests. It's the major tool that helps us keep our application stable and avoid major regressions. The first rspec commit was back in 2009 and will celebrate a 10 year anniversary next year. How many projects has rspec influenced over the years?

Thank you, dchelimsky.

2. devise

https://github.com/plataformatec/devise

At the core of almost every application today is sign up and log in. There are so many concerns to think about from how authentication is implemented to properly handling security. We wanted to let the library with years of development handle this for us.

Thank you, josevalim and carlosantoniodasilva.

3. user_impersonate2

https://github.com/userimpersonate/user_impersonate2

This is one of our favorite tools to help support customers. It allows us to view the application as the customer sees it. It's highly valuable and has saved us days of time over the years. Oftentimes it's the things that appear simple that help us the most.

Thank you, drnic and rcook.

4. activeadmin

https://github.com/activeadmin/activeadmin

Speaking of customer support, we couldn't do a lot of the things we do without activeadmin. Much of our customer support is handled by performing tasks inside an activeadmin based admin panel. We do everything from pausing subscriptions to updating data for customers. An admin panel is certainly something you could build on your own, but why do that when you have a great tool like activeadmin.

Thank you, gregbell

5. wicked_pdf

https://github.com/mileszs/wicked_pdf

This is one of my favorites. Generating PDFs on your own is something most people will never want to do. We use wicked_pdf to generate signed injury waivers for the businesses we support. I'm so happy I didn't have to learn much about PDF generation to build it. This is a classic example of being thankful for the years of knowledge and experience involved with a project like wicked_pdf.

Thank you, mileszs. Indiana represent!

6. gibbon

https://github.com/amro/gibbon

We integrate with Mailchimp and we rely on a gem for that. Rolling your own gem isn't typically a great decision when such a great library exists to handle everything. Gibbon has helped us build a system that manages lists for many different businesses and send campaigns to millions of people. Hundreds of thousands of API calls have passed through this gem for us.

Thank you, amro.

7. delayed_job_web

https://github.com/ejschmitt/delayed_job_web

Having a web interface to monitor your background workers doesn't seem like much, but it seriously helps. Even though the work was inspired by resque's web interface, it still provides a lot of value to us. We use it to investigate issues with our job queue and generally keep an eye on things.

Thank you, ejschmitt

8. paperclip

https://github.com/thoughtbot/paperclip

Although paperclip is now deprecated in favor of ActiveStorage, it's served us well. We've used paperclip to handle file attachments in all sorts of places. Our customers attach documents to user accounts and we've used it to keep track of waivers I previously mentioned. We'll be moving away from it in the future, but it's saved us plenty of headache over the years.

Thank you, everyone at thoughtbot.

9. omniauth-stripe-connect

https://github.com/isaacsanders/omniauth-stripe-connect

Strategies for omniauth are always helpful. By using it, we don't have to learn much about the specifics of the way Stripe implements oauth. Our customers have connected hundreds of Stripe accounts via this gem and we couldn't be happier.

Thank you, isaacsanders.

10. ransack

https://github.com/activerecord-hackery/ransack

One feature our customers love is the ability to search for all sorts of things about their students. We haven't felt a need to implement elasticsearch just yet, so we use ransack instead.

Thank you, ernie and jonatack.

Although I only listed a few people specifically, these projects have hundreds of contributors. That's the beauty of open source; every little thing helps. To all of those contributors out there, thank you. When we work together, we can make the software world a better place.

My hope with this list is to encourage you to look at your own software and the open source projects it relies on. Take a moment to think about these people who have influenced your own projects and your own businesses and companies.

Happy Thanksgiving!

What tips do you have for homebrew users?

Derek Hopper — Wed, 31 Oct 2018 15:04:44 +0000

This morning, I recovered 110 GB of disk space thanks to one command.

I'm a heavy homebrew user. I install packages all the time. On top of that, I brew update and brew upgrade quite often. I like to stay up to date.

Over the years, I continued to install packages, update, and upgrade them. All the while I was ignoring one important command.

My Story

This morning, I was greeted with this alert. Hmmmm... I thought. What could this be?

My documents folder had a few gigabytes of data, but that wasn't filling up my entire disk. That's when I started exploring homebrew packages. I realized I had been keeping many, many old homebrew packages around for no reason.

The Command

That's when I ran the command brew cleanup. Oh boy, I was in for a surprise. My terminal started spitting out line after line of this:

That's a lot of disk space!

After that completed (which took about 15 minutes), I suddenly had 120 GB of free space to work with. And that got me thinking, what else do I not know about homebrew? Do you have any tips for us homebrew users out there?

Delaying Decisions Until the Last Possible Moment

Derek Hopper — Tue, 25 Sep 2018 16:06:16 +0000

Let's go back in time. A few years ago, I started a project and immediately reached for Bootstrap. I added it to my asset bundle and got to work.

I started writing HTML and sprinkling Bootstrap classes on every element. Before long, I had a handful of views tightly coupled to Bootstrap. I was dependent on it. Being dependent on something isn't necessarily a bad thing. After all, Bootstrap has helped push forward tens of thousands of applications on the internet.

However, there's a problem. I started using Bootstrap before I needed it. Did I need to pick a frontend framework immediately? No. Guess what? Now I'm stuck with it. Unless I want to carefully edit all of my templates or slowly reduce Bootstrap usage to zero, I'm basically stuck using Bootstrap until the end of this application's life.

Why wait to make decisions

Picking Bootstrap was one of a handful of decisions I made immediately upon the project starting. Worse yet, picking Bootstrap was a non-critical decision turned critical.

In other words, Bootstrap is not a core function of the application. It doesn't run business logic. It doesn't perform key functions of the critical work to be done. However, by making Bootstrap an early dependency, it's now key to the frontend. If I compulsively remove it, the frontend turns into a mess.

Questions like "Should I use React?" and "What CSS framework should I include?" can be left unanswered for awhile. Otherwise, you risk adopting a dependency before it's truly needed.

Benefits of delaying decisions

One way to help you skip decisions about the frontend is to write tests. Without tests, we're kind've forced to build a minimal frontend to verify our work. When you have to build a frontend, you're tempted to reach for dependencies you might not need.

Starting with tests for business logic can help us avoid the need of a frontend. Instead of using the frontend to verify work, we can run our test suite.

Let's say we're building the comment feature on dev.to. We want to notify the author when a new comment is posted. Without tests, we might create a new post, add a new comment, then check the author's notifications. That might require us to write a large amount of frontend code. It's possible we'd be making a number of decisions before we have a ton of knowledge about it.

If we jump the gun and use React for all of this, we might be stuck with it. We might realize later we didn't really need it, but who wants to go back and rebuild what's already built?

With tests, the story changes. We can ignore the frontend and save it for later. To get started, we'd write a test that creates a new comment. Then, we'd check to ensure the author has a new notification. Verifying our work is running a few tests. No frontend needed.

This isn't the only way

This is only an example. Delaying decisions about your frontend isn't something you always have to do. If your application is already based in React, it seems clear you'd continue using it. The same is true with Bootstrap. Once you're using it, the default is to continue using it.

However, the spirit of delaying decisions is something to adopt. We might be tempted to think a decision is easy and without consequence, but slowing down is a good idea. "Of course we need to use this library," you might say, only to realize later it's not as great as you thought.

The beauty of delaying decisions is that it can be applied to almost anything. Don't know what you want your backend to be? Build a minimal frontend as you work out the details. Not sure if you want to use Resque, Delayed Job, or Sidekiq? That's cool - you don't need to make that decision early in a project.

Delaying decisions saves you time

When you make a decision too early and want to change it later, the decision costs you time. If it wasn't a decision that needed to be made, it's a double whammy. Most decisions can be delayed.

If I would've waited to make a decision on Bootstrap, it would've been easy to adopt another framework. You can get away with building a frontend until you actually need a frontend. At the very least, your frontend can be basic until you need it to be fancy.

Try something. When you reach your next decision, don't come up with an answer right away. Let the answer simmer and stew in your head. Do I really need to make a decision on this right now? Can I wait until I know more?

You always have more information tomorrow. Take advantage of that fact.

Not feeling motivated? Don't beat yourself up

Derek Hopper — Wed, 19 Sep 2018 21:32:38 +0000

About a month ago, there was a #DevDiscuss about how to stay motivated. Although I've had my struggles, I've never had a huge issue with staying motivated. #DevDiscuss prompted me to think about why.

I hadn't thought about it. Why do I tend not to have motivation problems? Was I special? I don't think so, but maybe I was doing something to thwart the demotivation demon.

Motivation can be tricky. Lack of motivation can be an even tougher nut to crack. One day you're motivated, the next day you're not. There are so many factors at play it's hard to keep track. Some of these factors come barreling at you, uncontrolled. Other factors are your own doing.

When you're feeling unmotivated, don't beat yourself up for it. If you're looking for words of encouragement, turn to the Terminator. Arnold Schwarzenegger was recently asked for some advice on how to get motivated to hit the gym.

// Detect dark theme var iframe = document.getElementById('tweet-1032076043547561985-558'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1032076043547561985&theme=dark" }

Don't try to act tough and power through bouts where you're feeling unmotivated. As Arnold says, "Sometimes life is a workout." That's ok. You'll have your tough days and you won't be as productive as you were yesterday.

Even if you can't be perfect everyday, you can work to mitigate the effects of things that demotivate you. That's why it's important to search for what you can do to help. You won't be able to figure it out in a day.

Make a little progress each day and you'll slowly improve. Treat yourself like cold brewed coffee, the best type of coffee, made low and slow.

These are things that help me stay motivated. They might help you too.

1. Know when to take a break

We all have our limits. I know my productivity decreases after I work on a tough problem. My brain starts to hurt.

Even though I sit on a Herman Miller chair, sometimes my body still hurts. My neck might be positioned at a weird angle. My eyes sometimes hurt depending on the lighting that day.

So take breaks. Get up, walk around, and find a glass of water. Let the blood flow throughout your body.

2. Try to find a balance

If you're passionate about code, great! I'll often work on my own projects or open source after I'm done with my day job. I can't do it every night though.

I have other hobbies and I think that's great. If you have hobbies outside of tech, I'm happy for you too. Your hobbies might even be loosely related to tech.

For example, I love playing poker. As you learn more about the game, you realize the parallels between a game of poker and business.

3. Change it up

Have you ever been in a new car? Remember the smell and how you felt.

From time to time, your environment loses its new car smell. It's ok to work from another location. If you have a laptop, find a different desk or corner in your building - at least for a couple hours. If you work from home, try a different room or even work outside.

If you can't work in a different location, even changing little things can work.

// Detect dark theme var iframe = document.getElementById('tweet-1034254963629850624-487'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1034254963629850624&theme=dark" }

4. Be lazy for a night

You might have nights where you want to do nothing. Do nothing! Just be lazy. Get away from code and don't even think about it. Sit on the couch and turn your brain off.

5. Work on the little things

Finally, this is something I'll do on mornings when I feel a little off. I'll work on small tasks to stack some success. It gets the ball moving in the right direction.

Oftentimes, I'll surprise myself. On a day I thought my productivity would be low, I'll be the most productive.

Conclusion

It's ok to feel unmotivated. We've all been there. It's human nature.

Don't beat yourself up for it. Don't try to be tough. Instead, find ways to help you cope with lack of motivation.

Work through it slowly. Your long term productivity is more important than a few days of lackluster motivation.

How do you sell refactoring to your team?

Derek Hopper — Tue, 24 Jul 2018 16:37:28 +0000

Refactoring is often a great thing to do. If you maintain a piece of software for years, chances are you'll refactor somewhat regularly.

Even though refactoring is a good practice, your team might have plenty of valid reasons why it doesn't want to refactor something. How do you sell them on the idea?