Forem: Ackshaey Singh

The 30-Second Hack That Will Speed Up Your Coding More Than Any Framework

Ackshaey Singh — Wed, 17 Dec 2025 20:43:09 +0000

As software engineers we're always chasing the next productivity tool. A faster build system. A smarter IDE. A new framework that promises to 10x our output.

More than anything else, this setting makes more of a tangible difference to my daily coding speed than any tool I've adopted over the past decade.

Sound familiar?

Think about how much time you spend holding down keys:

Scrolling through terminal output with arrow keys
Deleting a line with backspace
Moving through code with hjkl in vim
Navigating long file paths in the shell
Holding down arrow keys to select text

By default, MacOS has conservative key repeat settings - which makes sense because Apple doesn't tailor MacOS out of the box for keyboard first use. When you hold a key, there's a 225ms delay before it starts repeating, then it repeats every 30ms. That might not sound slow, but over thousands of operations per day, it adds up.

I estimate this costs the average terminal-heavy developer 15-20 minutes per day. That's scrolling lag. Waiting for the cursor to catch up. The micro-frustration of mashing delete harder because it feels too slow. Over a year? That's roughly 80 hours of your life spent waiting for keys to repeat.

Do this

MacOS allows you to set key repeat values below the System Preferences minimums via the command line:

defaults write -g InitialKeyRepeat -int 10  # 150ms delay (default: 225ms)
defaults write -g KeyRepeat -int 2          # 30ms repeat (already at GUI minimum)

Or if you want ludicrous speed:

defaults write -g InitialKeyRepeat -int 10
defaults write -g KeyRepeat -int 1          # 15ms repeat (2x faster than GUI minimum)

Log out and log back in for changes to take effect.

Why This Matters for Developers

Terminal scrolling alone is transformative. When you run a test suite or check git logs, you're not just scrolling—you're scanning for errors, searching for context, navigating to specific lines. With default settings, you're fighting the UI. With these settings, the terminal keeps pace with your eyes.

The same applies to:

Code navigation: Moving through files in vim/emacs at the speed of thought
Editing: Deleting/rewriting code without the frustrating "hurry up" feeling
Command line: Fixing typos and navigating bash history instantly

Start Conservative

I recommend starting with KeyRepeat=2 rather than 1. The difference between 30ms and 15ms is enormous—1 can feel almost too fast if you're not used to it. Give yourself a day to adjust.

If you want to go back:

defaults delete -g InitialKeyRepeat
defaults delete -g KeyRepeat

A Decade Later, Still the Best Hack

I've switched between dozens of editors, languages, and frameworks. I've adopted and abandoned countless productivity tools. But this setting? I notice within 5 seconds when it's missing.

That's why, after setting up my new MacBook and feeling that familiar sluggishness, I had to write this down.

YMMV. But if you spend hours in the terminal every day, this is the fastest way to speed up your development workflow. Not a new language. Not a better framework. Just two commands and a logout.

Try it for a day. I bet you'll never go back.

Harnessing Client-Side Caching in Rails: The Power of `expires_in`

Ackshaey Singh — Thu, 05 Oct 2023 12:17:26 +0000

In your journey as a software developer, you'll encounter myriad tools and techniques designed to optimize and streamline web applications. One such tool, often overlooked, is client-side caching. As backend and full-stack engineers, we spend hours crafting complex caching layers on the backend. However, we often overlook the most effective caching technique: having the request never reach the backend! Let's delve into how requests get cached on the client using the Cache-Control header.

Cache Control Header

At the core of client-side caching is the HTTP Cache-Control header. This header offers directives to browsers (and other caching agents) about how they should cache the content and when to consider it stale.

The most common directives include:

max-age: Specifies the number of seconds the response remains fresh.
no-cache: Directs caching agents to revalidate with the server before using the cached version.
public/private: public means that any cache, including CDNs, can store the response. private ensures the response is user-specific and only cached at the end-user level.

By setting the appropriate cache control headers, developers can steer the caching behavior of browsers and intermediaries, thereby optimizing both server load and user experience.

Rails `expires_in` in Controller Actions

In the Rails ecosystem, the expires_in method is our key to effortlessly managing the cache control header. Within the context of Rails actions, using expires_in sets the Cache-Control header on the HTTP response.

Take, for instance, an application like Designer Discount Club I'm currently building. The product data updates roughly once a day, and constructing the response requires complex queries and interactions with multiple services. Below, the display_cards action powers an infinite scroll list on the client. By implementing expires_in 1.hour, public: true, we essentially direct clients to retain and reuse their cached response for an hour. When users navigate back and forth, adding this cache control header reduces ~100ms round trip time from the client's perspective and diminishes request volume to our backend Redis cache by over 60%.

class ProductsController < ApplicationController
  ...
  CLIENT_CACHE_EXPIRY_DURATION = 1.hour
  ...

  def display_cards
    # ... expensive queries and requests to backend caches to build `response`

    expires_in CLIENT_CACHE_EXPIRY_DURATION, public: true # Set the Cache-Control header

    respond_to do |format|
      format.json do
        render json: response, status: :ok, mimetype: Mime[:json]
      end

      format.protobuf do
        render plain: response.to_proto, status: :ok, mimetype: Mime[:protobuf]
      end
    end
  end
end

The Subtleties of `expires_in`

When utilizing expires_in in your controller actions, it's pivotal to understand its various options:

Time Duration: This determines the freshness duration. Be it 30.minutes or 1.day, ensure it matches your application's data refresh cycle.
Public/Private Directive: public: true indicates any cache, including CDNs, can store the response. In contrast, private: true refers to user-specific data that should only be cached at the user level.
Other Directives: Directives like must_revalidate can be used for nuanced cache control. With must_revalidate, once data becomes stale, it must be re-validated with the server before being reused.

And there you have it! I've deliberately left out the many other splendid backend caching techniques integrated into Rails and those used by the display_cards endpoint above; those will be the subject of another post. Before signing off, here are some plugs for my projects:

Preparing for a software engineering interview but loathe grinding LeetCode? I crafted Firecode.io precisely for that reason. Give it a whirl!

Fancy buying furniture at 20-30% designer and trade discounts without the need to hire an interior designer? Swing by Designer Discount Club!

Feature flags in Rails: How to roll out and manage your features like a pro

Ackshaey Singh — Thu, 06 Apr 2023 14:10:35 +0000

Feature flagging is a widely adopted technique used in software development that enables developers to turn features or sections of their code on or off for different groups of users. It allows for the gradual release of new features to subsets of users, which makes it easier to test and monitor performance before enabling it for everyone. It provides developers with more flexibility and control over their releases, which can help avoid potential issues or rollbacks.

For example, imagine a team is working on a new feature that involves a significant change to the login process for a web app. Without feature flagging, the team would have to deploy the new code to everyone at once, potentially causing breaking the web app for all users. With feature flagging, the team can gradually enable the new login process for specific groups of users, testing and monitoring performance along the way. If any issues arise, the team can quickly turn off the feature flag to avoid widespread issues.

Even if you’re working on your own solo developer low throughput Rails app, feature flagging can be useful in isolating and eliminating problematic releases. I recently had to implement a feature flag system for Firecode.io, which is written primarily in Rails. In this blog post, we will look at how to use the Flipper gem to implement a basic feature flagging system in a Rails application. I have taken semi real examples and code from Firecode.io to illustrate the implementation with an example.

Step 1: Add the Flipper Gem to Your Gemfile

To get started with Flipper, add the following lines to your Gemfile:

### Feature flagging with Flipper
gem 'flipper'
gem 'flipper-active_record'
gem 'flipper-ui'

These gems provide the core functionality for feature flagging with Flipper, as well as a user interface for managing your feature flags.

Step 2: Configure Flipper in Your Application

Next, create a file flipper.rb in your config/initializers directory, and add code for configuring user groups. In this example we have created two user groups which can be accessed in the Flipper UI, and features can be enabled or disabled for these groups individually.

This code registers two feature blocks with Flipper: :admin_user and :patron. These blocks define the policy for enabling or disabling the features based on the properties of the current user. As an example, Firecode.io offers many perks that are reserved for Patrons, and the :patron policy block we can apply features that are active only for Patrons.

# Initializer for the Flipper gem. Setups up the Flipper UI and registers
# feature groups.

# admin_user policy block
Flipper.register(:admin_user) do |actor, _context|
  actor.respond_to?(:admin?) && actor.admin?
end

# patron policy block
Flipper.register(:patron) do |actor, _context|
  actor.respond_to?(:patron?) && actor.patron?
end

Step 3: Mount the Flipper UI in Your Application

To make it easy to manage your feature flags, you can mount the Flipper UI in your application. To do this, add the following code to your config/routes.rb file:

Rails.application.routes.draw do
  # Flipper for feature flags
  mount Flipper::UI.app(Flipper) => '/flipper', constraints: RoleConstraint.new(:manage, :all)
end

This code mounts the Flipper UI at the /flipper endpoint in your application. The RoleConstraint class is used to restrict access to the UI to users who have the manage role. You can customize this constraint to suit your specific needs. In this case, we're using the CanCanCan gem to gate specific routes to admin users. If you haven't worked with CanCanCan before, ignore the RoleConstraint portion.

Step 4: (Optional) Create a Features Repository and test it

To make it easy to manage the feature symbols and check the state of your feature flags in your application code, you can create a FeaturesRepo module that provides a simple API for checking the state of your feature flags. Create a file called features_repo.rb in an app/repositories directory, and add the following code:

# frozen_string_literal: true

# Repository of feature flags. Uses the Flipper gem to manage feature flags.
module FeaturesRepo
  # All feature flags should be defined here. Do not use strings.
  FORWARD_INCOMING_WEBHOOKS = :forward_incoming_webhooks

  # Returns the feature flag value for a given feature
  # @param feature [Symbol] the feature to check
  # @return [Boolean] the feature flag value
  def self.enabled?(feature)
    Flipper.enabled?(feature)
  end

  # Enables a feature flag
  # @param feature [Symbol] the feature to enable
  # @return [Boolean] the feature flag value
  def self.enable(feature)
    Flipper.enable(feature)
  end

  # Disables a feature flag
  # @param feature [Symbol] the feature to disable
  # @return [Boolean] the feature flag value
  def self.disable(feature)
    Flipper.disable(feature)
  end
end

This code defines a module called FeaturesRepo that provides methods for checking the state of your feature flags. The FORWARD_INCOMING_WEBHOOKS constant is defined as an example of a feature flag that can be used in your application code - we’ll take a look at how it is used below.

You should also create a test for this repo, just in case the Flipper API changes in the future or if our AI overlords generate garbage code and break our app. Create a file test/repositories/features_repo_test.rb with the following tests:

# frozen_string_literal: true

require 'test_helper'
require 'minitest/autorun'

# Tests for the FeaturesRepo module
class FeaturesRepoTest < ActiveSupport::TestCase
  setup do
    print_test_case_running
  end

  teardown do
    print_test_case_pass
  end

  test 'enabled? should return false if a feature is disabled' do
    Flipper.disable :test_feature
    assert_equal(false, FeaturesRepo.enabled?(:test_feature))
  end

  test 'enabled? should return true if a feature is enabled' do
    Flipper.enable :test_feature
    assert_equal(true, FeaturesRepo.enabled?(:test_feature))
  end

  test 'enable should enable a feature' do
    Flipper.disable :test_feature
    assert_equal(false, FeaturesRepo.enabled?(:test_feature))
    FeaturesRepo.enable :test_feature
    assert_equal(true, FeaturesRepo.enabled?(:test_feature))
  end

  test 'disable should disable a feature' do
    Flipper.enable :test_feature
    assert_equal(true, FeaturesRepo.enabled?(:test_feature))
    FeaturesRepo.disable :test_feature
    assert_equal(false, FeaturesRepo.enabled?(:test_feature))
  end
end

Step 5: Use Feature Flags in Your Application Code

Now that you have set up Flipper and created a repository for your feature flags, you can start using feature flags in your application code. For example, here is some semi real code from Firecode.io for a WebhooksController that checks the state of a feature flag before forwarding incoming webhooks to Slack - it has been (over) simplified for conciseness, always remember to sanitize any external data before forwarding it to other destinations.

class WebhooksController < ApplicationController
  # Bypass authenticity token check since we are receiving webhooks from external services
  skip_before_action :verify_authenticity_token

  def send
    if FeaturesRepo.enabled? FeaturesRepo::FORWARD_INCOMING_WEBHOOKS
      ForwardService.forward(message: build_forward_request_output(request))
    end
    render json: ApiConstants::EMPTY_JSON_RECEIVED, status: :ok
  end
end

This code checks the state of the FORWARD_INCOMING_WEBHOOKS feature flag before forwarding incoming webhooks. If the feature flag is disabled, the message is not forwarded.

Step 6: Test Your Feature Flags

To ensure that your feature flags are working as expected, it is important to write tests that cover all of the possible scenarios. Here is an example test for the hypothetical WebhooksController :

# frozen_string_literal: true

require 'test_helper'
require 'sidekiq/testing'

module Api
  module V1
    class WebhooksControllerTest < ActionDispatch::IntegrationTest
      include Devise::Test::IntegrationHelpers
      ...
      test 'send should not use ForwardService to enqueue a SlackWorker job if the feature flag is disabled' do
        Flipper.disable FeaturesRepo::FORWARD_INCOMING_WEBHOOKS
        assert_equal(0, Sidekiq::Worker.jobs.size)
        post @send_path
        assert_equal(0, Sidekiq::Worker.jobs.size)
      end

      test 'send should use ForwardService to enqueue a SlackWorker job if the feature flag is enabled' do
        Flipper.enable FeaturesRepo::FORWARD_INCOMING_WEBHOOKS
        assert_equal(0, Sidekiq::Worker.jobs.size)
        post @send_path
        assert_equal(1, Sidekiq::Worker.jobs.size)
        assert_equal('SlackWorker', Sidekiq::Worker.jobs[0]['class'])
      end
    end
  end
end

When you deploy this code to production or test it locally, you'll have to first create a feature flag called forward_incoming_webhooks in the Flipper UI (mounted at /flipper and accessible to admin users) and enable it. Fortunately, the Flipper UI is awesome and makes managing features really easy.

That’s it! You now have a fully configured feature flagging system in your Rails app. Notice we didn’t cover some more advanced features that Flipper offers, including enabling features for a user group or individual users. For that, check out Flipper on Github. We also didn’t cover feature flagging frontend features in this post - if that becomes a requirement we could easily create an endpoint that uses the FeaturesRepo and sends enabled features to the frontend to toggle. If you learned something new consider following me here - I’ll be putting out more content on Ruby on Rails and software development as I work on Firecode.io. Preparing for a coding interview? Check out Firecode.io.

Switching it up: how Tailwind CSS helped me create a dark mode logo in Rails

Ackshaey Singh — Wed, 22 Mar 2023 12:12:25 +0000

As someone that still swears by Bootstrap, I recently had the opportunity to try Tailwind CSS. I'm currently working on a new Rails 7 app for my wife, and I wanted to design a new logo for it. I used Illustrator to create the logo, and exported it as a PNG with a transparent background and white foreground. But I wanted to take it to the next level by adding a toggle between light and dark mode depending on the user's preference or the system settings.

I wasn't sure how to achieve this effect without writing custom CSS or exporting another version of the logo for light mode screens, but I knew that there had to be a better way to achieve the effect I wanted. Sure, I could write a custom style class in CSS for this, but then how do I check if dark mode is enabled as a system wide setting? Tailwind CSS to the rescue. After setting up Tailwind for my rails app, it was as simple as adding two utility classes to the logo in my header.erb file:

<%= image_tag 'brand/1x/logo.lightmode.png', class: "h-full dark:filter dark:invert" %>

These classes apply the invert(1) function to the CSS property filter , but only when system wide dark mode is enabled.

This was such a timesaver and cut down quite a few hoops in getting the logo right. I’m still discovering other utility classes in Tailwind CSS, one thing I know for sure is I might finally ditch Bootstrap for Tailwind for new Rails apps.

Are you preparing for a coding interview? Check out Firecode.io.

How to Setup Devise for User Authentication on Rails 7

Ackshaey Singh — Mon, 20 Mar 2023 22:36:08 +0000

If you are a frequent user of Ruby on Rails, you know that building authentication and user management systems can be a time-consuming and complex process. That’s where Devise comes in — a powerful authentication solution that simplifies the process of implementing user management systems in your Rails applications. As a Rails developer who churns out apps regularly, I’ve found myself reaching for Devise every single time. However, with the release of Rails 7, I’ve had to adjust my workflow and make sure that Devise works seamlessly with the new version. In this blog post, I’ll share my workflow for setting up Devise on Rails 7 and walk you through the steps to get started with this essential tool. So, whether you’re a seasoned Rails developer or just getting started, read on for a comprehensive guide to setting up Devise on Rails 7.

Hang on, why should I use Devise?

Authenticating users in a web application is a critical task that requires careful consideration of security best
practices. Building authentication functionality from scratch can be a daunting and time-consuming process, particularly
for developers who are not well-versed in security principles. This is where Devise comes in handy. Devise provides a comprehensive and customizable solution that handles common authentication tasks such as user registration, login, and password resets, while also supporting various authentication mechanisms and providing robust security features. By using Devise, developers can save valuable time and ensure their application's authentication system is strong and reliable, allowing them to focus on building other aspects of their application. Let's see it in action on Rails 7.

Prerequisites

Before proceeding with the guide, ensure that you have a new or barebones Rails app created using rails new.
Additionally, you should not have a User model set up yet.

Step-by-Step Guide

Add Devise, Letter Opener, and Omniauth (optional) to your Gemfile:

...
gem "devise", github : "heartcombo/devise", ref : "f8d1ea90bc3"
gem "omniauth"
...
group :development do
    ...
    gem "letter_opener"
    ...
end

Note: cloning Devise from GitHub is necessary because it contains fixes for some Rails 7 incompatibilities.

Install the gems:
```
bundle install
```
Run the Devise install generator:
```
rails g devise:install
```

This generates the devise.rb initializer and adds the en locale at config/locales/devise.en.yml.

Add the following Devise-specific configurations to config/development.rb:

# For Devise
config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }
# For Letter Opener
config.action_mailer.delivery_method = :letter_opener
config.action_mailer.perform_deliveries = true
config.action_mailer.raise_delivery_errors = true

Generate the User model with Devise:
```
rails g devise user
```

This creates the user model files as well as a preliminary migration.

Edit the migration to add the fields you need:

## Identifying fields
t.string :first_name, null : false, default : ""
t.string :last_name, null: false, default: ""

Also, uncomment the trackable, confirmable, and lockable fields (and accompanying indexes).

Edit user.rb and add confirmable, trackable, lockable, and omniauthable to Devise.
Tweak options in config/devise.rb to suit your needs. For example, you may want to increase the remember_for
option to a couple of months:
```
config.remember_for = 2.months
```

In the same file, change the default email to one from your application:

```ruby
config.mailer_sender = 'no-reply@designerdiscount.club'
```

Generate the Devise views so you can modify them later:
```
rails g devise:views
```
Migrate the database:

   rake db:migrate

Add the following code to application.html.erb right above the yield block:

   <% if notice %>
     <p class="alert alert-success"><%= notice %></p>
   <% end %>
   <% if alert %>
     <p class="alert alert-danger"><%= alert %></p>
   <% end %>

Try it out! Start your rails server and head to http://localhost:3000/users/sign_up and create a new user. You should receive an email which opens in the browser (via letter_opener). Great, it’s working!
Deny logged-out access to a controller action and test it out. Create a home action in an existing controller,
which is PagesController in this example:


   class PagesController < ApplicationController
     def landing; end

     def home; end
   end

Let’s redirect the user to the landing page if they try to access home but are logged out.


   def landing
     redirect_to(action: :home,
                 params: request.query_parameters) if user_signed_in?
   end

   def home
     redirect_to(action: :landing,
                 params: request.query_parameters) unless user_signed_in?
   end

Edit the global header to hide the sign-in link if the user is signed in:

<% if user_signed_in? %>
  <li class="flex">
    <%= link_to 'Logout', destroy_user_session_path,
                method: :delete,
                data: { turbo_method: :delete } %>
  </li>
<% else %>
  <li class="flex">
    <%= link_to "Sign up", new_user_registration_path, rel: 'noopener noreferrer' %>
    <%= link_to "Login", new_user_session_path, rel: 'noopener noreferrer' %>
  </li>
<% end %>

That’s it! You now have a basic setup for user authentication using Devise on Rails 7. You can customize the generated Devise views with Tailwind or Bootstrap to match your app’s design. Want to learn more? Check out the Devise wiki. Preparing for a coding interview? Check out Firecode.io.

So what exactly are those pesky versions in your package.json and Gemfiles anyway? An introduction to Semantic Versioning

Ackshaey Singh — Tue, 14 Mar 2023 21:36:32 +0000

You may not give it a second thought, but as a software engineer, you come across Semantic Versioning every day. Simply put, it's a way of standardizing how version numbers are assigned and interpreted. It follows a three-part numbering system: Major.Minor.Patch. And trust me, understanding what each number means can save you a lot of time and headaches down the line.

Let's start with the PATCH version. This level is for implementation level detail changes, like small bug fixes. It's denoted by a number in the form of 0.0.x. So, if you see a new version of software that has changed the PATCH number, you can safely update your code without worrying about backwards compatibility issues.

Moving on to the MINOR version, which is denoted by a number in the form of 0.x.0. This level is for any backwards compatible API changes, like new functionality/features. So, if you see that a new MINOR version has been released, you can safely update your code and expect it to work as expected.

Finally, the MAJOR version, which is denoted by a number in the form of x.0.0. This level is for backwards incompatible API changes, such as changes that will break existing users' code if they update. So, if you see that a new MAJOR version has been released, proceed with caution and make sure you thoroughly test your code before updating.

Let's take an example. Suppose you want to build a toy 'magic-8-ball' application that can predict the future. Using semantic versioning, you might keep track of changes in your CHANGELOG like this:

v0.1.0: Initial release, with the core 'magic-8-ball' prediction functionality.
v0.2.0: Added color to the 8-ball because black and white is so last century.
v0.3.0: Added a 'shake' method that shakes the ball so you don't have to.
v1.0.0: Added a 'reveal' method to see the prediction without shaking the ball. Breaking change: prediction string now includes question asked.
v1.1.0: Added a 'history' method to view previous predictions. Backwards-compatible: still returns only the latest prediction by default.
v1.1.1: Fixed a bug in the 'history' method that prevented it from returning more than one prediction.
v1.1.2: Fixed a bug in the 'reveal' method that was caused by the previous bug fix.

Semantic Versioning is a simple and powerful tool that can save you time and prevent headaches. Understanding what each number means can help you stay ahead of the game and make informed decisions when updating your code. So, next time you come across a new version of software, take a moment to check the version number and make sure you understand what each number means before updating!

Want to learn more? Check out SemVer. Preparing for a software engineering interview? Checkout Firecode.io.

Level up your JavaScript browser logs with these console.log() tips

Ackshaey Singh — Mon, 02 Nov 2020 18:49:04 +0000

I consider myself a backend software engineer - and as any backend engineer would attest, a large part of our life is spent monitoring, troubleshooting, and debugging our applications. The fundamental rule of software development is that software will fail - what separates new developers from experienced ones is how they plan for those failures. Robust and effective logging is an important part of planning for failure, and eventual mitigation. As it is for backend development, logging can be useful for frontend software development, but it goes much further than just troubleshooting and debugging. Effective frontend logging can also make the development experience productive, fast, and fun.

While I’m a big proponent and diligent practitioner of Test-driven development, I love the flexibility, the richness of information, and code confidence browsers provide to frontend developers who make effective use of console.log(). I thought I’d share some frontend logging tips and tricks I’ve learned and incorporated in my workflow over time while building Firecode.io - in the hope that some of these will help you make your development workflow a bit more productive and fun!

I like to divide these tips into two broad categories - quick n’ dirty logging for when you’re actively building and debugging your application, and durable production logging - to know when your app’s working as expected and when it’s not.

Tips for quick n’ dirty development logging with `console.log()`

Don’t use console.log().

Yes, that’s right. I don’t use console.log(). Well, ok I write wrappers that use console.log() (more on that in the production logging section), but if you want to log something in your app to see what’s going on, use console.trace() instead. In addition to giving you everything console.log() does, it also outputs the entire stack trace so you know where exactly the message is emitted from.

Use ES6’s computed property names to identify your objects and avoid variable name confusion

This one is straightforward - use ES6’s computed property syntax and wrap the objects you wish to log in curly braces inside console.log() - i.e. use console.log({user}) vs console.log(user). You’ll find them neatly logged with the variable name set as the key, and the value as the object itself. This is especially useful when you’re in a hurry and want to log multiple objects in the same console.log() command.

Embrace tiered log levels - error, warn, info

console.log(param) by default logs at the INFO level - however, you also have 3 other logging levels at your disposal which you should make use of - console.debug(), console.warn() and console.error(). Besides formatting differences (notice the different colors?), the browser’s developer console also lets you easily filter out logs at different levels with a convenient dropdown to declutter your logs.

When logging lists of items, use console.table()

This one is self-explanatory and one of my favorite console functions - if you ever need to log a list of objects, give console.table() a try.

Quickly debug with `debugger`

Want to save a precious few seconds? Instead of finding your file in the developer console to add a breakpoint, drop a debugger in your code to halt execution when the line is executed. From this point on, you can debug and step over / into functions as you normally would.

Granular performance profiling with `console.profile()` and `console.time()`

Want to profile an exact user flow in your application to find hot spots? Trigger console.profile(profileName) at the start of the action, and console.profileEnd(profileName) at the end to inspect the CPU profile for the flow.

Related, you can measure exactly how long a flow takes with triggering console.time(id) at the start of the flow, and console.timeEnd(id) at the end.

Count labelled executions with `console.count()`

This one’s one of those console functions I haven’t found much use for personally, but it’s there if you need it. console.count(label) can help you know exactly how many times a piece of code gets executed - which could be useful for finding and eliminating race conditions and other scenarios.

Prettify your logging with CSS

This is by far my favorite console feature and one I make extensive use of in production logging (more on this in the production logging section). You can make use of format strings to format your log messages. The %c is the placeholder for CSS styles, and anything after is your message.

You can also style multiple elements by extending your format string to include %s for string parameters.

Since I’m a highly visual person, I like to spend some time making my info and debug logs look pretty and be useful at the same time. I make extensive use of this feature for production logging in Firecode.io - which is an excellent segue for the next section.

Production logging with `console.log()`

Getting frontend code production ready involves a number of steps - some being uglifying and compressing your code, generating cacheable asset digests, and removing console.log() s from your app. Why? Because you don’t want your users to have to open the developer console to interact with your app, which nullifies the usefulness of your logs and leaves them as pure security holes for the more inquisitive to take advantage of. At the same time, when you use your own app, you most likely want the most granular level of logging to understand how your app is functioning and find and squash bugs. If your app is being used by others, you’d also want to be notified when your application’s users encounter errors so you can track down and fix your code. Here’s a couple of things I do to satisfy these requirements as best one could on the frontend:

Don’t use console.log()

Instead, write a wrapper class that includes logic for conditionally logging based on the log level based set on a global variable by the backend. Warning - you’ll see TypeScript code snippets ahead - if you’re not familiar with TypeScript, think of it as a superset of JavaScript with types tacked on (gross over-simplification) - i.e. const str = “some string”; becomes const str: string = “some string” - types are added after a variable followed by a semicolon.

In the case of Firecode.io, I wrote my own frontend framework that utilizes RxJS, but includes familiar concepts such as components from other popular frameworks such as React and Vue - while adding additional concepts such as engines for processor-heavy code blocks, channels for WebSocket messages, and clients for HTTP requests. Visualizing all these pieces working together was critical, so I implemented custom formatting in a Logger wrapper class that formats and visually differentiates logs from each part of the application.

Instead of calling console.log("Cache SET to", {value}), I call Logger.debug(“Cache set to”, {value}, Framework.Cache) . The Logger class has a TypeScript enum that maps each framework component to the color to be used:

This allows me to visually focus on components of the app during development - for example, if I want to see what the WsRequestCache is doing I can tune out everything else besides the turquoise badged logs.

Protect your logs by having the backend set your log level

I have Firecode.io configured to turn on debug level logging by default for admin users with a JavaScript variable that is set by the backend. While adventurous users can still find and set these flags in the developer console to turn on granular logging, it is better than having all logs exposed to every user of your application by default, or having a post-processor remove all logging completely from your application in production.

Set in a Ruby on Rails view:
const logLevel: number = <%= @app.get_log_level_for_user %>

And in the Logger class:



class Logger {
   ...
   ...
   static info(...) {
     shouldLog(Level.INFO) && console.log(...);
        ...
   }
}

Log and notify on actionable errors

Last but not least, you want to be notified when exceptional conditions are encountered by users without necessarily outputting logs to the developer console. You can do this by including a call to pipe your errors to a third party APM service such as AppSignal in your Logger‘s error function like so:



class Logger {
   ...
   ...
   static error(e) {
     if (shouldLog(Level.ERROR)) {
       console.error(e);
     }
     appsignal.sendError(e);
   }
}

AppSignal includes integrations to pipe your errors to outbound notifications services such as Slack, PagerDuty, and OpsGenie - you can even hook up a project management tool such as JIRA or Trello to automatically create issues and bugs for your team.

Summary

I really hope these tips and anecdotes make your frontend development experience a little more productive and fun! I’ve obviously only touched the surface of logging ninjitsu in this post, so if you have any more tips to share I’d love to read them over on my Twitter.

Two parting plugs - I’m rebuilding Firecode.io from the ground up with a brand new set of coding interview questions for JavaScript, Java, Python, and Scala. If you’re interested in coding interview prep that adapts to your learning style and is fun - sign up with your email here I’ll also be putting out more content about building a production scale web app like Firecode.io from scratch as a side project - follow me at @ackshaey or @firecodeio to learn more. Lastly, if you’re new to JavaScript and want to understand how object-oriented JavaScript and prototypal inheritance work under the hood, check out my favorite book on the subject - The Principles of Object-Oriented JavaScript, and if you’re interested in learning more about why you should use TypeScript instead, check out Effective TypeScript.

MacOS vs Linux — the cp command will trip you up!

Ackshaey Singh — Tue, 27 Oct 2020 17:56:08 +0000

While building www.firecode.io, I was recently confronted with more than a hundred failing unit tests when running the test suite locally on my MacOS machine, rather than in a Linux Docker container the platform is configured to run tests in.

I use a MacBook Pro for software development, primarily because the BSD based MacOS provides a development experience that’s very similar to other Linux distros. All of my most frequently used navigation commands — cd, cp, mv, mkdir, touch, etc...work with 1:1 parity across both flavors of operating systems, or at least that’s what I thought. As I discovered after spending a good hour debugging these failures, there’s a subtle difference between the BSD and GNU implementations of the cp -R command, which I got hit with when running my tests on different environments.

Here’s the difference, illustrated with an example run in both MacOS and Linux:



# Creates "source_directory" in the current working directory
$ mkdir source_directory

# Creates 2 new empty files within "source_directory"
$ touch source_directory/{file1,file2}

# Creates "destination_directory" in the current working directory
$ mkdir destination_directory

# Intended to copy the contents of "source_directory" to "destination_directory", hence the trailing slashes
$ cp -R source_directory/ destination_directory/

# Lists the contents of "destination_directory"
$ ls destination_directory

So what would you expect to be printed with ls? Turns out the Linux GNU implementation of cp copies the source_directory directory to destination_directory, whereas on BSD MacOS the contents are unpacked and copied, as I’d expected it to behave on both environments:

GNU (Linux):



$ ls destination_directory
source_directory

BSD (MacOS):



$ ls destination_directory
file1 file2

The trailing slash is significant in BSD, whereas the GNU implementation treats both source_directory/ and source_directory the same. The workaround, thankfully, is really simple — append a period when you intend for the contents to be copied and you’ll see the same behavior on both BSD and GNU : cp -R source_directory/. destination_directory/.

I hope this tidbit helps you write better cross environment code on MacOS and helps you save some time debugging unexpected results.