All posts by Jeremy Felt

Proceed with Caution toward the Self-Driving Car

A good perspective on the caution required as we enter an era of self driving cars. While I normally find myself in full support of the switch, there were a few sections that made me think and we definitely have a long way to go.

There was one statement that gave me pause:

No system can yet match a human driver’s ability to respond to the unexpected, and sudden failure could be catastrophic at high speed.

I would argue that a primary reason for looking forward to autonomous vehicles is that no system can match a human driver’s ability to cause the unexpected.

webcame-pulse-example

Tracking Your Heart Rate Via Webcam

Technology, ,

I remember being fascinated by the Eulerian Video Magnification work when some of the videos were being spread around, so I was excited to see the Webcam Pulse Detector project pop up on Quantified Self as I was scrolling through some missed feeds this morning.

It didn’t seem too difficult to setup for somebody with some linux familiarity and I set off to make it happen on my laptop.

The entire process took a couple hours. Some of that was due to missteps in installing OpenCV or not using sudo in the right place. The rest was due to the unavoidable—some packages just take a long time to install.

Seeing it finally work is really, really cool. Using my forehead, the app seemed to consistently track my heart rate at around 54-57bpm. At the same time I measured my pulse at my wrist as 60bm. I’ll need to track the consistency over time and with non-resting heart rates as well, but that seems like an acceptable variance so far. Pretty cool stuff.

If you want to give it a go and you’re running OS X 10.8.3 on your machine, I’m embedding a gist with the commands I had to use to make this work along with some comments inline.

There were also plenty of resources that proved invaluable in actually finding the right answers for installing some of these software packages:

On Citizenship in Open-source software development

I’ll steal the TL;DR from the author:

TL;DR: By giving an actual social status to the people contributing to a repository, GitHub would solve the problem of zombie-projects with a scattered community. By allowing these citizens to actually collaborate with each other, instead of just with the owner, repositories will live as long as the community exists, completely on auto-pilot.

Ignore “GitHub” for a second and replace with WordPress.org. Upvoted contributions to by_the_people_ branches on plugins could be an interesting way of addressing the stale plugin or unresponsive plugin author issue.

v0.6 of Varying Vagrant Vagrants has been pushed

Plenty of changes and plenty of contributions this round. Great stuff!

  • Add WordPress Unit Tests
  • Option for custom shell provisioning file
  • Pre/Post provisioning hooks via additional shell scripts
  • Flags system to disable portions of default provisioning
  • Grab stable WordPress from latest.tar.gz vs SVN
  • Append custom apt sources list to default
  • Update to SVN 1.7.9, addresses specific Windows permissions issue
  • Move wp-cli to /srv/www/ for easier contributions

Can’t move ‘.svn/tmp/entries’ in Vagrant / Virtualbox

Code, ,

Some Windows machines were having trouble with the SVN portions of Varying Vagrant Vagrants, getting this error during an svn checkout:

svn: Can’t move ‘.svn/tmp/entries’ to ‘.svn/entries’: Operation not permitted

Such an ugly thing to have to troubleshoot, but we had several minds at work.

Many sites indicated there was some kind of file permissions problem between Virtualbox and Windows. One of these sites happened to mention the issue being related to the version of SVN.

Long story short. If you end up here because of SVN issues in Vagrant or Virtualbox, upgrade to SVN 1.7 or higher inside the virtual machine and see what happens.

A Git Submodule Management Question

Code,

I have a jeremyfelt.com repository, similar to this on GitHub, that includes WordPress trunk as a submodule. I manage plugin and theme files outside of core WordPress files and from time to time do a git submodule foreach git pull, which grabs the latest changes from the WordPress repo. This all works beautifully (I think), but whenever I run git status inside the master jeremyfelt.com repository, I get this:

wordpress-submodule-shot

I’ve gone several months just ignoring this and not ever staging anything. Today I decided to figure it out. From what I can tell there are at least two possibilities.

First – I stage and commit in the parent repository as a way of keeping track of what revision the submodule is on when changes are made to the parent. See - Stack Overflow discussion.

Or – I ignore the changes in the submodule (similar to what I’ve been doing) by adding ignore=dirty to my submodule definition in .gitmodules. See - How to ignore changes in submodules.

I’m leaning towards the second as my goals in the parent repository are not necessarily to track a specific version of the WordPress submodule, just to use it as a way to have trunk easily updated.

What do you think?

Varying Vagrant Vagrants has moved (a bit)

Code, ,

Varying Vagrant Vagrants started off 4 months ago as a shot in the dark to solve a problem I was having. As development progressed, it became immediately clear that this was something we wanted to have in the 10up bag of tricks while we’re working with varying production environments. The contributions from other 10uppers have been fantastic and it quickly became obvious that this should grow in 10up’s area of GitHub rather than in my little personal corner.

Things have come a long way and we now have a great base to start branching from. The next hope is to see custom Vagrantfiles from groups like WordPress.com, ZippyKid, WPEngine, DreamHost, GoDaddy, Bluehost, or anybody else doing WordPress hosting.

We’ll keep the pressure going on that front and over the next few days do a better job of explaining the overall goal for Varying Vagrant Vagrants, how we’ll use it internally, and how you may be able to use it or a variant for your own development process.

In the meantime, if you’ve already cloned the repository, please make sure that your git remotes are up to date if you’d like to pull in changes.

Hi WordPress, Meet Vagrant

Code,

Over the last few months I’ve been planting seeds with every WordPress developer I run into with the hope of convincing them to use Vagrant to manage their development environment. The basic pitch has evolved with time and now that I’ve had the chance to fine tune it for 10up’s recent developer summit, I’m going to lay it out here as well.

LAMP via MAMP / XAMPP / WAMP

It helps to start with what we’ve been working with so far. The first step to developing for WordPress is to make sure your environment meets the minimum requirements. As of today, these are PHP 5.2.4 and MySQL version 5.0 or greater.

The beginning of WordPress development was often like the wild west. Cowboys abound, PHP files were edited in some form of a text editor and uploaded directly to the server for testing. White screens were a good indicator when things went wrong.

As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a basic development environment could be setup with relative ease. White screens now happened locally first and more rarely in production.

MAMP, XAMPP and WAMP came along and provided a few click method of creating a stable LAMP sandbox for us to play in. With the minimum requirements for WordPress development met, things got stable and stale.

Meeting Environment Requirements

Rather than meeting minimum requirements, Vagrant provides a flexible way for a developer to meet environment requirements.

How about a server running Ubuntu 12.0.4, nginx, PHP-FPM, MySQL, memcached and the PECL memcache extension? Vagrant does that.

And CentOS 6.4 with nginx, PHP-FPM, MySQL, memcached and the PECL memcached extension? This too.

Or Debian 6 with page caching provided by Varnish or Redis… Can also do.

But wait.. still working with that project hosted on Apache, MySQL and PHP?

Vagrant does that.

This Matters?

This matters. The closer you can be to your production environment during development, the more confident you can be that the code you are pushing has been tested properly.

When that tricky cache expiration issue appears, the tools will be immediately available to confirm and troubleshoot it. When somebody on your team needs to jump in to help on a project, only a couple commands stand between them and a full matching system.

And at the end of the day, when you are done with development, one command powers off this amazing virtual environment and leaves you with a personal computer.

Go Try It and Chime In

10up has a pretty decent setup going over at Varying Vagrant Vagrants. A walkthrough from a few weeks ago is up at Evolving WordPress Development With Vagrant. We’re continuing to cruise ahead with a common nginx, MySQL, PHP-FPM and memcached setup, but we’ll be branching off to our other environments shortly as well. If you have an environment you’d like to see matched, fork the repository and give it a go.

And If Your Name Is Mo Or Barry…

Hi!

What we have in our default provisioning so far is pretty close to a basic version of the WordPress.com server environment. We would love to help create a Vagrant setup that matches production as closely as possible and can be used by anybody developing a project with that in mind. Ping me when you’re game. :)

Cache issues be gone!

v0.4 of Varying Vagrant Vagrants has been pushed

Among the changes:

  • Add default .vimrc file with some helpful tricks
  • Clarify sample SQL commands
  • Add WordPress trunk installation to default setup
  • Use Composer for PHPUnit, Mockery and XDebug – faster than PEAR
  • Filename modifications for config files
  • General documentation improvements