Life so far with a 2020 13″ MacBook Pro

I recently switched from using a Mid-2015 15″ MacBook Pro to a 2020 13″ MacBook Pro with Apple’s Silicon M1 chip. It was a Big Deal in the sense that my computer is a primary daily tool in my personal and professional life. So much of my work, my creativity and the management of my life is handled through this one device, so it’s always a little scary to make a change. (I actually could have been happy continuing with my previous laptop if its battery hadn’t been expanding, causing the entire computer to bulge in weird and alarming ways.)

Here are a couple of things I observed in making this transition and in using the MacBook every day since:

Apples to Apples

My previous MacBook Pro was pretty high end (2.8 GHz Intel Core i7 Processor, 16 GB 1600 MHz DDR3 RAM, Intel Iris Pro 1536 MB Graphics, 1TB HD) and very fast for the things I used it for. These included software development, hosting multiple software development environments, audio and video editing and rendering, graphic design and photo editing, and LOTS of browse tabs. It took everything I could throw at it and I never felt slowed down by the computer itself.

So the idea of “downgrading” to a smaller screen (13″ instead of 15″), fewer ports, and the same amount of RAM but 5 years later was a bit nerve-wracking.  Conventional wisdom for a long time was that 13″ MacBook Pros were fine for some kinds of advanced computing but that the 15″ model was always the best option for the kinds of things I use it for. Maybe this was just me naively buying into Apple’s marketing, but it seemed to be supported by testimonials from colleagues over the years, and was a strong narrative in my head nonetheless.

But I’d heard and read that the Apple Silicon M1 chip was a game-changer, and that any comparison between Intel and the newer processors was not really valid. And after seeing enough stories from real users where they said the new chip plus 16GB of RAM was even faster running some of the same software I do, even with Rosetta 2 translation turned on, I was sold.

Continue reading Life so far with a 2020 13″ MacBook Pro

Intercepting mail with MailHog in Laravel Valet

I’m trying out using Laravel Valet to manage the development environments for both my WordPress and Laravel related work. (This is not the result of any dissatisfaction with VVV, which I’ve happily been using for the WP work, and Laravel Homestead, which I’ve happily been using for Laravel work, but comes as a necessity now that I am using a Mac with Apple’s M1 ARM chip, which doesn’t support Intel Vagrant virtual machines.)

The Valet installation and setup was easy and fast using their instructions, and I’ve been able to successfully move projects over to it without a lot of hassle. The one place where I was really bit was taking for granted how those previous virtual environments where handling the intercepting of email generated by my applications, so that they didn’t actually go out onto the Internet for actual delivery. I got used to spinning up environments with copies of production data and not worrying about real users getting email messages.

Well, you can guess what happened when I did that in Valet, which by default delivers email just like any other email generated from a process running on my Mac. Spinning up a WordPress dev site with a slightly outdated database dump and with functionality that is all about notifying users via email of things that are about to happen or have happened meant…lots of emails going out.

Ugh. Apologies, installing Stop Emails and other cleanup ensued.

Fortunately, the long term fix is pretty easy. Yes, there are various plugins one can install on individual WordPress sites to stop email from going out, or to change default SMTP behavior. But I didn’t want to have to worry about that each time I clone a site. So instead I changed the default SMTP behavior for the php-fpm processes that Valet runs to deliver all mail to MailHog.

First, I installed MailHog:

brew install mailhog
brew services start mailhog

Then, I added a smtp-mailhog.ini file in the PHP conf.d directory for my setup. In my case that was each version in /opt/homebrew/etc/php/X.X/conf.d. The contents of that file are:

; Use Mailhog for mail delivery
sendmail_path=mailhog sendmail

Then I ran valet restart and tested by triggering a password reset email from a WordPress site, and confirmed that it had been intercepted by visiting the MailHog interface at http://127.0.0.1:8025.

Of course this setup may not fit every use case, so adjust your config accordingly. (I submitted a PR to the Laravel docs with this info, but understandably it was probably too specific to my setup.) Even if you don’t change the PHP-level settings, with MailHog installed you could set up individual sites/applications to send to it as needed.

Create and send custom Mailchimp email campaigns from WordPress

There are lots of Mailchimp + WordPress integrations out there already. But when I wanted to create a customized, automated daily email campaign that would be generated from WordPress content (beyond just a listing of recent posts) and sent to a Mailchimp list, I couldn’t find anything to do just that.

For a little while I used MailChimp’s ability to read RSS feeds and generate campaigns from them, and I built a custom RSS feed on my WordPress site where the latest entry in the feed was the customized content I wanted to be populated into the *|RSSITEM:CONTENT_FULL|* variable to then go out to my subscribers.

But this was unreliable — sometimes the message wouldn’t go out because of caching issues on my end, mysterious days where MailChimp didn’t seem to check the feed, and there were other quirks — and even working with MailChimp support I couldn’t get things to a stable state. I also didn’t like that MailChimp’s system forced me to pick a top-of-the-hour time during the day when the feed would be checked, and if for some reason it was missed, I had to reconfigure the whole campaign to get the message out.

I needed a better way.

The resulting method that’s been working for almost a year now is to initiate and send the Mailchimp campaign directly from within WordPress. I get full control of scheduling, message generation and formatting. I can re-run the campaign send if I need to. And it has worked reliably every day. Here’s how I set it up (with inspiration from this blog post by Isabel Castillo).

Continue reading Create and send custom Mailchimp email campaigns from WordPress

Testing my WordPress plugins in preparation for WordPress core releases

A couple times per year, WordPress plugin authors and owners get an email like this one:

WordPress 5.6 is imminent! Are your plugins ready?

You’re receiving this email because you have commit access or ownership of existing, open plugins hosted on WordPress.org. The next release of WordPress, 5.6, is scheduled for 08 December 2020.

We would like you to take this time to review your existing plugins and ensure their ongoing compatibility with WordPress. Once you’ve done so, you can update the readme “Tested up to:” value to 5.6. This information provides peace of mind to users and helps encourage them to update WordPress.

Here are the current “Tested up to:” values for each of your plugins:

The message goes on from there to list the plugins I’m responsible for and some notes and details about what’s new in the upcoming WordPress release.

In case it’s not clear, this is an important moment because the authors of tens of thousands of WordPress plugins are being asked to help ensure that when the many millions of WordPress sites out there upgrade to the upcoming release, that those sites continue to look and function as expected by their users. It’s an impressive example of how the WordPress developer community works together in the background to help sustain and grow the larger WordPress ecosystem.

For authors of widely used plugins, by the time this email goes out their plugin may already be fully ready, especially if they’ve been following or maybe even contributing to the development of the new WordPress core release. Some plugin authors rightly have an extensive automated test suite in place to confirm that every part of their plugin’s functionality works against the latest beta or release candidate version of the new version before it comes out.

Authors and maintainers of smaller plugins (like me) may not have the same infrastructure set up, and instead need to perform some manual testing of our plugins to ensure they’re ready.

So, here are the steps I follow every major release cycle to make sure my plugins have been tested and are ready for the new version.

Continue reading Testing my WordPress plugins in preparation for WordPress core releases

SMTP relay through Fastmail from Postfix on macOS Mojave

When my Mac laptop tries to send me email — the output of a cron job, for example — by default it ends up in a local mailbox file that I never check. I want the mail to get to my regular email account, but I don’t want it to relay that message through whatever random ISP I might be connected to at any given time, or over the open internet. It’ll likely fail, it’s not secure, and there are better ways.

Instead, I relay all outgoing mail sent from macOS through my email provider, Fastmail (affiliate link). This especially makes sense since most of the email from my OS is going straight to my inbox hosted at Fastmail.

The notion of relaying email through a specific provider is built in to the Postfix mail transport agent that comes with macOS, so in theory it’s not a big deal to set up. In reality, I’ve found it to be a somewhat fragile configuration, and rarely does it survive a macOS upgrade or switch to a new computer. So I’ve come to document it pretty heavily for my own reference. I recently went through the process again, so thought I’d write it up here in case it’s helpful to others.

Most of these steps are derived from this nice compilation of steps that applies to macOS Sierra through Mojave.

  1. Edit /etc/postfix/main.cf and add these lines to the end:

Continue reading SMTP relay through Fastmail from Postfix on macOS Mojave

What are AWS hosting costs using Laravel Vapor?

When I was researching tools and services for launching a SaaS app, I was pretty clear that I wanted to use Laravel Vapor to manage the Amazon Web Services deployment. The main mystery about that decision was what it would actually cost to have a Vapor-managed deployment on AWS for the size of my application and my expected usage levels.

I found a few articles and blog posts about that topic (the most helpful was Cost & Performance optimization in Laravel Vapor) but, as is the case with AWS hosting in general, there was no clear formula that would lead me to a precise monthly hosting cost for a brand new web application.

In hopes that it helps someone else in a similar situation, I’d like to add one more data point to the mix. Here are some details about what it’s costing me (so far) to host my Laravel-powered application on AWS as managed by Vapor.

Vapor itself is $39/month. This cost does not change if you use Vapor across multiple projects, so your per-project cost can go down over time if you plan to launch more than one project. Some people have raised eyebrows at this baseline cost but as anyone who has ever had to manage their own hosting server infrastructure and worry about upgrades, security issues, configuration management, etc. knows, it feels like a great deal. I wrote about that more in my other post on launching a SaaS business, but this sentiment remains true:

It felt like the magical world of cloud hosting that was always promised but never quite delivered had finally become reality. Even a month later I’m still constantly amazed by it. Huge kudos to the Vapor team.

Now, on to AWS itself. I’m currently paying approximately $1.00 per day for AWS services, and the monthly bill ends up being about $33.00.

Continue reading What are AWS hosting costs using Laravel Vapor?

Getting alerts about outdated Time Machine backups

Our household uses Apple’s Time Machine backup system as one of our backup methods. Various Macs are set to run their backups at night (we use TimeMachineEditor to schedule backups so they don’t take up local bandwidth or computing resources during the day) and everything goes to a Synology NAS (basically following the steps in this great guide from 9to5Mac).

But, Time Machine doesn’t necessarily complete a successful backup for every machine every night. Maybe the Mac is turned off or traveling away from home. Maybe the backup was interrupted for some reason. Maybe the backup destination isn’t on or working correctly. Most of these conditions can self-correct within a day or two.

But, I wanted to have a way to be notified if any given Mac had not successfully completed a backup after a few days so that I could take a look. If, say, three days go by without a successful backup, I start to get nervous. I also didn’t want to rely on any given Mac’s human owner/user having to notice this issue and remember to tell me about it.

I decided to handle this by having a local script on each machine send a daily backup status to a centralized database, accomplished through a new endpoint on my custom webhook server. The webhook call stores the status update locally in a database table. Another script runs daily to make sure every machine is current, and sends a warning if anyone is running behind.

Here are the details in case it helps anyone else.

Continue reading Getting alerts about outdated Time Machine backups

Personal banking needs an API

My washer and dryer can tell my smart watch when they are done washing and drying. A voice assistant in my kitchen can update my grocery list. Documents in selected folders on my laptop can be synced to data centers around the world in an instant.

These things are possible through the use of APIs, which most every user-facing service, tool, device and ecosystem out there these days seems to understand are an essential part of their offering. APIs give users, developers and partners a way to build new things on top of the thing you already offer. They give people flexibility to integrate a service, tool or device into their lives in a way that makes sense for them. APIs help encourage wide adoption and extensibility.

The industry that seems to be far behind in offering powerful APIs to end users? Personal banking, and related billing systems for utilities and credit card companies.

When I want to check the current balance on my personal checking account, I have to follow a multi-step process in a web browser or mobile app.

When I want to get the latest PDF copy of a bill from my mobile phone carrier, it’s something like 10 clicks across three different websites.

When I want to initiate a bill payment on a credit card provider that doesn’t support automatic drafting from my bank, it’s a similarly long process.

The other day a rep from a utility told me I had to call them to request a form be mailed to me so I could fill it out and mail it back to them, just in order to set up automatic payments from a bank account.

And when I want to be notified about certain kinds of activity from these institutions, I have to log in to each one to go through their proprietary grid of checkboxes and verification methods to set up push alerts or text messages…if they offer notifications at all.

Indeed, accessing and working with my personal financial information is one of the most cumbersome, high-friction, analog things I do any more. Personal banking and bill payment feels like swimming in mud compared to the light speed of most of the rest of the information economy.

Why is there so much friction in personal banking and financial transactions?

Continue reading Personal banking needs an API

How long does it take between when a plugin update is released and when auto-updates install it on your WordPress site?

Auto-updates for WordPress themes and plugins were released this year in WordPress version 5.5. They allow WordPress site owners to opt-in to automatically have new versions of plugins and themes installed when they are released, without any intervention from the site owner.

If you use auto-updates, one question might be on your mind:

How long will it take between when the author of a plugin releases a new version and when that new version is installed on your WordPress site?

This question is vital for site owners and managers. Especially in scenarios when new plugin or theme versions contain critical security fixes, time is of the essence to avoid possible unauthorized access to your WordPress site.

To get to the answer, let’s first review how plugin and theme releases happen.

The Plugin and Theme Release Process

When a plugin or theme author is ready to make an update to their software, they upload those changes to the directory on WordPress.org. This is where the code for their theme or plugin is hosted publicly.

Most theme and plugin authors also indicate the release of non-trivial changes by increasing the version number associated with their plugin. Maybe it’s a small “point release” like going from version 1.1 to version 1.2, or maybe it’s a major release like going from version 3.0 to version 4.0. The change in version number lets everyone know that there’s new functionality and fixes available. It’s a convenient way to refer to how software has changed over time.

Once the updated software and version number change is live on WordPress.org, it’s immediately in effect for new installations of that plugin or theme. Anyone downloading and installing a plugin or theme from that directory will now be using the latest code made available by the author.

But what about existing sites that already have that theme or plugin installed? How do they learn about the new changes and new version?

How WordPress Sites Discover Updates

You might think it happens through a “push notification” sent to your site from WordPress.org. But the WordPress.org systems would have to contact thousands or maybe millions of sites to tell them about an update to a single plugin. That’s just not practical.

Continue reading How long does it take between when a plugin update is released and when auto-updates install it on your WordPress site?

How I built and launched a SaaS app in one month

In June of this year, I had an idea for a software-as-a-service (Saas) application that I wanted to build and launch. On July 1st, I committed the first lines of code to a git repo for the app. After about 200 hours of development time, on August 10th I launched the first version of the application into the world, ready for users and subscribers.

The service is called WP Lookout and you can read more about the service itself and why I built it on wplookout.com. This post is about the process, tools and services I used to build and launch a SaaS application in what felt like a relatively short period of time.

Here’s the short list of resources I used along the way if you just want to explore them without further commentary:

  • Laravel for the application framework
  • Laravel Homestead for my local development environment
  • PhpStorm for software development
  • Laravel Spark for scaffolding the SaaS subscription and account management
  • Stripe for subscription payment processing
  • Laravel Nova for an administrative dashboard
  • Git and GitHub for tracking code development, to-do items and feature branches
  • Upwork for hiring and paying a software code reviewer and consultant
  • Slack for coordinating with my contractor
  • TermsFeed for generating privacy policy and terms of service documents
  • Amazon Web Services for application hosting
  • Laravel Vapor for managing AWS setup and deployment
  • WordPress for building the WP Lookout marketing website
  • Matomo for privacy-focused analytics
  • HelpScout for managing user support interactions
  • MailerLite for handling new user onboarding and marketing automation

I’m not going to go in-depth on all of these tools, as some of them are pretty simple and self-evident in their value. Others are just magical and deserving of some additional observations. Here are some things that stood out and what I learned along the way:

Continue reading How I built and launched a SaaS app in one month