One of the fun projects I've been involved with in my work at Automattic is bringing Joel Spolsky's esteemed writings at JoelOnSoftware.com to a WordPress-powered site. That site went live earlier this week just in time for a big announcement from Joel's company Fog Creek Software.
A few years ago I noticed that a couple of different tools and services I was using at the time were offering the option to tweet when I engaged with them somehow. I was interested to try it out but I didn't want to clutter up my human-authored Twitter feed with a bunch of software-authored stuff that I couldn't necessarily control the timing or content of.
So, I created the @JCHThings Twitter account, and it's been a steady stream of activity from the Internet-connected devices and tools in my life ever since.
Sometimes it shares some bad news:
SSL is one of the most important technologies in use on the modern web. It enables all kinds of business, collaboration, commerce, activism and communication to happen securely, and the Internet couldn't thrive without it. Yet for the average person, alongside domain name registration and management, obtaining and renewing SSL certificates has always been one of the least accessible and convenient parts of having a website.
So I was particularly proud when a year ago my employer Automattic became a sponsor of the Let's Encrypt initiative and even more proud earlier this month when we rolled out free SSL for all domains hosted on WordPress.com, using Let's Encrypt certificates. All of the sudden a huge portion of the world's websites were using SSL to make sure communications between site owners and users are encrypted and secure - amazing!
Let's Encrypt is itself pretty amazing. A bunch of industry experts got together and decided it was time to make the process of obtaining SSL certificates free, automatic, secure, transparent, open and cooperative. This is a long way from what it looked like in the late 1990s, when just a few "certificate authority" options existed, you could expect to pay $100 or more for a certificate, and the application process was painfully slow and analog (think faxing your corporate articles of organization and a photocopy of your driver's license to a call center somewhere), and that's all before you had to mess around with recompiling or reconfiguring Apache to use SSL on your site(s). Even with Let's Encrypt and other modern options some of the concepts and steps remain too technical for many site owners to tackle, but it's getting better all the time.
I'm used to paying around $10/year for SSL certificates on a few of my personal sites, and I actually haven't minded that price point given that the rest of the process has been pretty easy for me to manage. But I recently decided to try using a Let's Encrypt SSL certificate on a site that didn't have one yet, and I'm sharing the steps involved here.
I recently played around with building a new WordPress theme from the ground up, and I'm sharing some notes here about what I learned along the way.
It had been a while since I'd created a WordPress theme from nothing, and I knew that best practices had shifted quite a bit since then. I also wanted to use a more modern development workflow than I'd previously been used to. In my daily work I get to help our clients test, refactor, optimize and launch their WordPress themes (and I enjoy that quite a bit), but sometimes I just want to tinker for a personal project.
I also had an itch to scratch with 47374.info, a site I'd created in 2011 to aggregate local news headlines into a single, simple list display. It uses the great FeedWordPress plugin (along with some custom Perl scripts I wrote to scrape news off of local sites that embarrassingly don't offer their own RSS feeds) and does its job just fine, but it wasn't responsive, the mobile theme wasn't working so well for this use case, and there were more and more parts of the original theme I'd used that needed cleaning up. I also wanted to create something that looked and worked a little bit more like the Hacker News front page (without voting or comments). I am my own primary target user here; the site in question tends to get 40-60 visitors per day (I hope you're enjoying it, whoever you are), but I know I use it every single day.
I didn't quite have the time to start with a totally blank slate, so I started looking at some of the starter themes out there: Underscores, Components, Minimum Viable VIP, and Bones were the main ones I considered. These starter themes include all of the basic requirements of a WordPress theme so you don't have to literally create each new file (like
style.css from scratch). Each option then offers its own unique flavor to what a starter theme should have. For example, the Minimum Viable VIP theme is designed to have everything a developer on the WordPress.com VIP platform would need to implement basic functionality while also meeting code security and performance standards on our platform.
In my case, mobile-first and responsive was a top goal, and while Components has some great options there, Bones seemed to take care of what I wanted with a little less extra stuff thrown in. (Some day I will learn to write media queries from scratch, not this time around.)
So I downloaded Bones, opened it up, and started poking around. And that's when I encountered this:
A few weeks ago I created a new, simple WordPress plugin, Debug Bar Widgets.
It adds a panel to Debug Bar that displays all of the widgets registered on a site, even if the widgets aren't active. There are probably simpler ways to get at the same info but I've found it useful in developing some of my other widget-centric plugins.
Pull requests welcome.
There are many online resources about using SSH keys to achieve passwordless, cron-initiated tasks like rsyncing some files around. Most of these assume your SSH key is either not encrypted with a password, or that you're running the related command in an interactive session.
What I couldn't easily find recently was a way to make sure that a script initiated via cron on OS X 10.10 (Yosemite) and that uses an SSH key that is encrypted with a password would have access to that key as managed by the current login session's
This problem manifested itself with the following kind of output from my rsync command - being used to back up some files from a remote server - when it was executed via cron:
Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [receiver=2.6.9]
If I ran the same command from the shell prompt it worked fine.
I like Google and a lot of the things it does in the world. When people ask me what free mail, calendaring and contact syncing tools they should use, I usually include Google's services in my answer. But I always explain that they're trading some privacy and ownership of their information for the "free" part of that deal. "You're the product, not the customer" and all that.
For me, I've always tried to avoid having my own data and online activities become the product in someone else's business model. There are plenty of places where I can't or don't do that, and I mostly make those tradeoffs willingly. But so far, I've been able to avoid using Google (and Apple and Microsoft) for managing my personal email, calendaring and contact syncing.