John’s Blog

Speaking of working remotely from home ... Glenn Fleishman has a new (free) e-book: Take Control of Working from Home Temporarily.

We're in a time of unprecedented uncertainty. In the middle of a global viral outbreak, you were told or asked to work from home—and you've never or rarely had to be productive where you live before. What to do? We're here to take some stress out of your life with a new, free book that details how to set up a home office and balance work and home life for those not accustomed to it.

Some great suggestions on working from home by Matt Stauffer:

Today, I want to talk about remote work—especially right now, as so many people are unexpectedly being told/allowed to work from home—and how so much of it happens in less-than-ideal environments, and what we can do to make the best of it. I'll assume you're working from home, but many of these tips apply in other less-than-ideal remote work environments as well.

I agree with many of his tips. I've been working from home now for over 4 years and it took some getting used to in the beginning. Now I can't imagine anything else.

While working from home takes some getting used to and people may not be as productive as before we have to remember that we're still in the middle of a global crisis, and that doesn't make working easier regardless of your work location.

MonoLisa is a new coding-focused font by Marcus Sterz:

As software developers, we always strive for better tools but rarely consider font as such. Yet we spend most of our days looking at screens reading and writing code. Using a wrong font can negatively impact our productivity and lead to bugs. MonoLisa was designed by professionals to improve developers’ productivity and reduce fatigue.

I’m still partial to Operator from Hoefler & Co, but MonoLisa looks very well done.

Speaking of Github, this week it was also announced that Github (aka Microsoft) has acquired the de-facto package manager for JavaScript, npm.

Nat Friedman, on Github's blog:

npm is a critical part of the JavaScript world. The work of the npm team over the last 10 years, and the contributions of hundreds of thousands of open source developers and maintainers, have made npm home to over 1.3 million packages with 75 billion downloads a month. Together, they've helped JavaScript become the largest developer ecosystem in the world. We at GitHub are honored to be part of the next chapter of npm's story and to help npm continue to scale to meet the needs of the fast-growing JavaScript community.

On what's next:

Looking further ahead, we'll integrate GitHub and npm to improve the security of the open source software supply chain, and enable you to trace a change from a GitHub pull request to the npm package version that fixed it.

That sounds very cool. Excited to see that piece come together.

For this Mac-loving tech kid that grew up in the 90’s, I still cringe any time I hear Microsoft doing anything. But this is not the Microsoft of then. They’ve done well with Github so far. They’re doing amazing things with the cloud. I need to get over it. Hopefully this is a new great beginning for npm.

New this week: a brand new native iOS and Android app for Github. From what I can tell these are completely native apps. Maybe there’s some web embedded stuff in there, but if there is, I can’t tell and it’s super slick and fast. As it should be.

The app seems very well designed and thoroughly considered. Handy for managing Pull Requests and Issues on the go.

Very nice looking app for debugging network requests. Reminds me of the beautiful and powerful Paw app. I love that these little development and tech tools are being so well done lately, rather than having to use some awful cross-platform Java app. via Brent Simmons

Excellent video from Kurzgesagt on YouTube:

It's the number one trending video on YouTube today for good reason. This video clearly explains what we know so far about the SARS-CoV-2 virus and how it affects the human body.

(via Kottke)

Harry Stevens, at The Washington Post, with my favorite explanation from over the weekend of why this virus is so dangerous and how it spreads:

[...] these simulations vastly oversimplify the complexity of real life. Yet just as simulitis spread through the networks of bouncing balls on your screen, covid-19 is spreading through our human networks — through our countries, our towns, our workplaces, our families. And, like a ball bouncing across the screen, a single person's behavior can cause ripple effects that touch faraway people.

The visuals in this piece are excellent.

To no one's surprise, Apple announced today that this year's WWDC will be online-only due the "current health situation."

We are delivering WWDC 2020 this June in an innovative way to millions of developers around the world, bringing the entire developer community together with a new experience," said Phil Schiller, Apple's senior vice president of Worldwide Marketing. "The current health situation has required that we create a new WWDC 2020 format that delivers a full program with an online keynote and sessions, offering a great learning experience for our entire developer community, all around the world. We will be sharing all of the details in the weeks ahead.

Ben Thompson interviews Matt Mullenweg about Automattic's distributed workforce. Ben and Matt are two of my favorite people on the web, so it's delightful to hear them discuss this topic. The interview is behind Ben's subscription paywall, so if you're not already subscribed, you should!

Mullenweg:

People are surprised when I say this, but I think in-person is really key. And so we just flip it, so instead of saying you have to be an around your colleagues 48 weeks of the year and do whatever you want for a month, we say be wherever you want for 48 weeks out of the year and for three or four weeks a year we're going to bring you together. And that might be once a year for the whole company, and then your individual team, which is probably five to 15 people, you'll see them two or three times a year and you can build that trust. There's nothing, no technology, VR or otherwise, that has the same effect of breaking bread across the table or sharing a drink with someone, for building trust, for building communication, for getting to know someone.

Working remotely in a distributed company shouldn’t replace all face-to-face communication and interaction. It’s just not the default.

And, later:

I think that when you become a truly distributed company versus just trying to recreate your meetings and everything else you do online, you start to realize how much more valuable it is to move things to be asynchronous versus synchronous because that opens up a ton of flexibility, autonomy, and agency between all of your colleagues.

Bingo. Synchronous communication (where everyone must stop and do something at the same time) is my number one productivity killer.

Great list of resources and updates on Om Malik's blog, in a 'live blog' style approach.

Like everyone else, I have become anxious about the Coronavirus Pandemic. It is hard to discern the actual impact, especially since social media is conflating facts with fiction. I have begun keeping a document that is full of links to articles, research, commentary, and videos that come from experts — scientists, immunologists, viral disease researchers, and sources that could only be said to be biased toward logic and caution. In other words, I am paying very little attention to the self-proclaimed experts who are investors, car company chiefs, or anyone else who thought Corona was just a beer till about a month ago.

Instead of keeping it on Google Docs, I have decided to share it here on the blog, and I will be continuously updating it with new links. I am no expert, but I have a pretty good sense of who to ignore and when to pay attention.

It’s been a busy week for remote working fans and first-timers with all of the safety measures being put in place for COVID-19. Here are some of the better links I’ve found recently:

• Matt Mullenweg: Coronavirus and the Remote Work Experiment No One Asked For: "This is not how I envisioned the distributed work revolution taking hold."
• Austin Kleon: A working from home manual in disguise:  "Here are 10 tips taken straight from the book, along with excerpts and quotes"
• The Staying Home Club (that’s stayinghome.club, nice): A list of all the companies working from home
• Ian Sanders: How to Work at home
• Gitlab’s remote working guide
• Protocol Source Code’s remote tips from Amir Salihefendic

More to come, I’m sure!

Update March 13, 2020:

Coronavirus and working from home – a primer to get your team started
"If your work happens in front of a computer, it can happen remotely. Yes, face-to-face interaction is the best way to transmit complex ideas, details of the tasks, hilarious jokes, and deadly viruses."

Kevin Roose: Sorry, but Working From Home Is Overrated
I think he’s missing the point here. Working from home shouldn’t (and doesn’t) mean working in isolation. Communication, breaks, and personal health should be focused on whether working in an office or remote!

I’m really enjoying Tot, a new utility from The Iconfactory. It's a simple little window with a few scratch pads for text, organized by color. Tot appears to be a very basic app on the surface but features an exceptional level of design quality and attention to detail. Interesting pricing model too: free on the Mac, $20 on iOS. During the week I have about a million little text windows open with all sorts of scratch information. On iOS I've struggled to find a similar solution for these quick notes and pieces of text. I don't need to keep them forever, sometimes just a few minutes, so it's nice to have a little scratchpad that syncs. Tot also uses a small subset of Markdown, which is really handy for basic formatting. Even better: the library for handling Markdown was open sourced on Github. Worth the $20 price alone just to fund this library's development.

Last week I open sourced a new Ruby library called Tally. Tally was created over the past few years as a part of a number of products I’ve worked on and I’ve always wanted to open it up to the public for anyone else to use as they see fit. It's a bit techy, so it doesn't feel right here in the journal, but I posted a bit about it here, in case you're curious.

Last week I open sourced a new RubyGem called Tally. Tally was created over the past few years as a part of a number of products I’ve worked on and I’ve always wanted to open it up to the public for anyone else to use as they see fit.

Tally is a quick utility for collecting counters and stats throughout a Rails application. Technically I suppose it could be used outside of Rails in a standard Ruby app, but that’s not my use-case so I haven’t spent any time optimizing it for that.

Tally sits on top of Redis for fast collection of these counters. The goal of the stat collection was to make it as fast as possible so that counters could be incremented throughout your application code in real-time.

Periodically throughout the day the counters are extracted from Redis and archived into a standard ActiveRecord model within your application. There’s a single table added to your database that keeps track of the counters each day after they are archived.

That’s it. It’s a quick and simple way to get basic stats reporting into an application. There are certainly bigger players in this space, and I’ve used several before as well. StatsD is a great example of a much more robust and scalable tool for this sort of thing. But in my recent use cases, it’s just a bit overkill. Sure, I could spin up StatsD and get it all to work. But I had bigger areas that I wanted to focus on, so Tally is a great place to start.

Side note: if you’re wanting to collect millions and millions of data points, you probably need something different here. Tally can work, but there are better tools for that job.

I’m currently using Tally for few specific needs, which I think are perfect use cases for the project. Here are a few use cases so far…

Use Case 1: Tracking Ad Impressions

First, I run a private ad server for a current project. I didn’t want to use a third-party ad server for privacy concerns and because I generally don’t trust that industry. That’s another story, for another day. However, it is important to report to our brand advertisers on how well advertising campaigns are performing. This includes impressions (views of each ad) and clicks. For video-based ads I also track the number of plays and completion percentage to see how well everything is performing. All of this is done privately with no user or personal information whatsoever shared with anyone.

Here’s a quick mockup of how it works. There is an AdUnit model in our database. It just stores basic data about the ads. Click-through links, the artwork for the ad, video streaming locations, and that sort of thing. Within that model, we use the Tally::Countable concern:

# app/models/ad_unit.rb
class AdUnit < ApplicationRecord

  include Tally::Countable

  # ...

end

Then, in the controller that renders the ad unit, we simply increment the impressions counter each time it is displayed:

# app/controllers/ad_units_controller.rb
class AdUnitsController < ApplicationController

  # GET /ad-units/:id
  def show
    @ad_unit = AdUnit.find(params[:id])
    @ad_unit.increment_tally(:impressions)
  end

end

We have a similar process to handle tracking for when an ad is clicked. To preserve the privacy of our readers we don’t directly link to the advertiser’s site. When an ad is clicked the link first goes through our server to clean any identifiable information from the user. This is also a great place for me to increment the clicks counter so I can accurately track how many people clicked on each ad.

From these two Tally counters we can derive something that looks like the screen below and see how many impressions and clicks each ad unit received:

The tracking for all of this is incredibly simple and with a few queries to get the data out of Tally, we have enough information to share with advertisers on how well their campaign is performing.

Use Case 2: Tracking Subscriber Counts over time

My second current use case is to keep track of the total number of subscribers (aka users) of my product on a daily basis. Since Tally is created specifically to track counts by day, this is a perfect way to collect data.

I could increment a counter of each time a new subscriber signs up. But that’s a bit unnecessary since each time someone signs-up there will be a new Subscriber record in my database. So I’m using Tally’s custom calculators feature to quickly count the number of subscribers and store it along with Tally’s other records.

Here’s a quick and dirty example of how I do this:

# in an initializer file,
# something like config/initializers/tally.rb

Tally.register_calculator "SubscribersCalculator"</code></pre>

Then, I have the calculator in a service class inside my app folder:

# in app/calculators/subscribers_calculator.rb
class SubscribersCalculator

  include Tally::Calculator

  def call
    start_at = day.beginning_of_day
    end_at = day.end_of_day

    count = Subscriber.where(created_at: start_at..end_at).count

    {
      key: :subscribers,
      value: count
    }
  end

end

The Tally::Calculator concern automatically sets up an initializer and the day variable is the current Date, or the date that we want collect data for. Each time the Tally archive process runs (I run it hourly) this calculator is run and the data is stored alongside the other Tally counts I’ve collected.

To make things a bit more detailed we can also store the number of signups for each referral source. This is helpful to know where subscribers are finding our site from when they sign up each day. (Are people finding us from search, social media, organic traffic, a paid traffic campaign, etc.) In my use case, I have a source enum value on the Subscriber model that stores this information when the subscriber registers:

class Subscriber < ApplicationRecord

  enum source: %w( organic search social paid )

  # ...

end

If we wanted to collect subscriber counts by source, we could modify the calculator to something like this:

class SubscribersCalculator

  include Tally::Calculator

  def call
    start_at = day.beginning_of_day
    end_at = day.end_of_day
    result = []

    scope = Subscriber.where(created_at: start_at..end_at)

    # store the total number of subscribers for this day
    result.push(
      key: :subscribers,
      value: scope.count
    )

    # store the number of subscribers for each source
    Subscriber.sources.keys.each do |source|
      count = scope.where(source: source).count

      result.push(
        key: "#{ source }_subscribers",
        value: count
      )
    end

    result
  end

end

This updated calculator will store the total number of subscribers each day, and also the total number of subscribers per referral source. After a few days of gathering data we can produce a simple report like this to show a graph of our new subscribers:

So that’s the initial release of Tally. It’s a simple but very powerful tool for collecting stats in a Rails application. It’s been very useful for me over the years, and I hope it can be useful to others.

The full documentation and README for Tally is available on Github and I’m certainly open to Pull Requests, Issues, bug reports, or other feedback.