I’m a front- and back-end web developer with a passion for coding clean, semantic, and functional websites and applications. I do a lot of PHP, I dabble in Rails, and I enjoy using HTML5, CSS3, and jQuery to build slick, modern interfaces.
Over the past few years, I’ve developed quite a fondness for WordPress, the platform on which this site is built (You can view the source of this site over on Github). You may have come across one of my WordPress plugins, WP Password Generator or WP Client Reference, both of which are available through the WordPress plugin repository.
Latest Blog Posts
This week a few people in the office got really excited about the Signals app from HubSpot, which lets you see when your emails have been opened and whether or not links have been clicked in your emails. While it’s extremely useful for marketers, project managers, and others who have a vested interest in knowing you’ve read their emails, I’d prefer to be able to read the email at my leisure without having the sender essentially standing over my shoulder to see if I’ve read it. For most people it’s not a big concern, but it is incredibly simple to thwart if you’d like a little more privacy in your inbox.
I’m working on a site right now that uses the Social Login plugin by OneAll, which is the first time I’ve dealt with users logging into a WordPress account via social networks. The plugin works really well, but I ran into one major issue: new user accounts were being created when matches weren’t found.
This particular project is a BuddyPress site for a fraternity; brothers can log in to see private events, content, and the full roster but the general public can only see the public pages. There’s also a public roster page with basic information about each member (name, graduation year, major, etc.), but those are dynamically generated by listing all BuddyPress members (excluding my team’s accounts, of course). Out of the box, OneAll would create a new user account for anyone who tried to log in, resulting in my mug appearing in the roster right along all the registered fraternity members…yikes!
At work we’ve been rolling out PHP-FPM to more and more of our clients’ servers, which has been great for performance and keeping server loads down. The only issue we’ve had (beyond some initial configuration) was related to our deployments: many of our projects, especially our web applications, are deployed through Capistrano, a Ruby-based task runner that’s extremely popular among the Ruby on Rails crowd. While Capistrano let’s us reduce deployments to running
cap production deploy, PHP-FPM typically needs to be restarted before it will start using the new code.
Having to manually SSH into a server to restart PHP-FPM after a deployment takes some of the sexy out of one-line deployments, so we sought to find a better way. The goal: be able to restart PHP-FPM (
sudo service php5-fpm restart) from within a Capistrano task without being prompted for passwords (we use Public-Key authentication) or having to manually SSH in to restart the server.
Get your geeky fill on my blog!
Follow me: @stevegrunwell
- My middle-school self wholly enjoyed this Honest Trailer for the original Pokemon games: https://t.co/7BmnM2IFra
- Okay, it's either Rush Limbaugh Springfield's own Birch Barlow: https://t.co/5NDBvwf1KX
- Working outside would be a lot easier if my super-conservative neighbor's radio wasn't saying "Obama" in an accusatory tone every 15 seconds