Going Remote – Day 5

This post is part of a series about my experiences moving from a traditional Nine to Five office job to a remote job with a distributed team. Disclaimer: These articles are intended to provide my personal perspective on transitioning to what very well could be the future for tech workers and are not endorsed by, nor reflective of the opinions of my employer.

So I went to work every day this week without leaving my house. That was interesting…

Continue reading

Going Remote – Day 0

This post is the first in a planned series about my experiences moving from a traditional Nine to Five office job to a remote job with a distributed team. Disclaimer: These articles are intended to provide my personal perspective on transitioning to what very well could be the future for tech workers and are not endorsed by, nor reflective of the opinions of my employer.

Well, this is it. I’ve been interested in the idea of remote work and distributed teams for a long time now, and ever since I read The Year Without Pants last year I’ve been hooked. I saw what companies like Automattic and Lullabot have been doing – hiring talented programmers wherever they may be and trusting them to get things done without constant oversight – and it made so much sense to me that I had to pursue that kind of working life, if only to try it on for size. Finally, after taking my time and slowly searching out a new job over the last several months, I’m starting my first full-time, 100% remote job tomorrow.

Continue reading

Fear of Becoming Open

The University of Oregon’s developer community is interesting. I’d say unique, but from speaking to developers at other universities, I’m under the impression that our situation is fairly common at large institutions. With 25,000-ish students and hundreds of schools and departments supporting them, there comes a few thousand websites to provide information about enrollment, financial aid, majors, classes, housing, dining, activities, events, and on and on and on. Typically, developers are hired in far-fetched corners of the institution and charged with one area’s concerns. Thusly, to support a thousand sites, we wind up with a few hundred developers, ranging from $10/hr students to $100k/year professionals supporting this odd, cobbled-together infrastructure.

I’ve written about this problem elsewhere, and rather than re-hashing it I’d like to look at some interesting ideas that come up as we head down the road to recovery. Eventually, all these programmers start talking to each other and realize that they’re all working on essentially the same problem. As we begin to collaborate organically, realizing that we have common problems and coming together to find common solutions, we start to emulate open source software communities, and we run into one of the biggest problems in OSS: encouraging contribution and eliminating barriers to first commit.

Continue reading

Importing Localist Events with Feeds

I’ve been fiddling around for a while with trying to figure out a good method for getting events out of our central events calendar. Colleagues and I had toyed with implementing modules to provide a block or custom Views code to feed JSON into a table or what have you. Recently I came across Baris Wanschers’ article about importing a twitter feed and realized it was exactly what we needed.

A grid of images and descriptions of upcoming events.

While I still think having some kind of Views module specific to this task would be useful, this works well as a simple solution leveraging existing modules.

Continue reading

Understanding Institutional Scope

Working at a large, distributed institution like a public university is interesting. The University of Oregon is home to some 20,000+ undergraduate students, not to mention grad students, faculty, staff, and so on. As you might imagine, an institution this large has a similarly large web presence, with literally thousands of pages covering colleges, departments, classes, programs, organizations, etc.

For example: at Oregon, we have a few key pages: The homepage, pages for the individual colleges (Arts and Sciences, Architecture, Law, Business, etc.), athletics, and so on. However, this is only the tip of the iceberg. Departments, professors, student groups, classes, campus initiatives, and on and on and on all need sites. I’ve un-scientifically estimated the total number of sites deployed at Oregon at a (very) rough ballpark of ten thousand.

To create this mammoth web presence, we’ve taken what seems to be a typical approach for universities: hire dozens of web developers and hope everything turns out ok. Enrollment hires a developer to make enrollment sites, the business college hires someone to make their site, some student makes the computer science page, some contractor makes the site for the music school, and the physics department is still sporting that site a professor made back in the early 90’s. Universities are full of smart people and were early adopters of the internet, so back when this whole web thing was getting started and the concept of an IT department hadn’t really been invented yet, it made sense to grab the nearest nerd and put them to work. Today, this model’s still around, but it doesn’t make sense any more.

Continue reading

Product Type Pricing Rules in Drupal Commerce

Recently, I wanted to do rule-based pricing in Drupal Commerce, but only for a certain product type. Commerce ships with a rule to react on “Calculating the Sell Price of a Product” and an associated set of actions to discount by a percentage (10% off!), fixed amount ($10 off!), or set a fixed price (only $10!).

This is what you’ll typically find documented, but I got tripped up trying to add a condition to only apply a discount to certain product types instead of globally discounting products (all square widgets only $10!). By default, though, I wasn’t able to use the line item’s product type in a data comparison condition.

Turns out you can do this, but, as is so often the case, you need to figure out what magical incantation will give you the rules scope you need. In this case, adding an “Entity has field” condition to check that the entity has the ‘commerce_product’ field does the trick. From there, you’ll be able to add another condition and reference the commerce-line-item:commerce-product: selector to do your comparison.

Update: I’ve posted a sample rule for those who would like to see a complete implementation.

Developers are designers, designers are developers

I’m going to open with a question: What’s the difference between a designer and a developer?

If you’ve been working in the web for a long time, I’m going to guess at your answer: Designers are responsible for making a website look good, developers are responsible for making it work. This is how it’s been for ages, especially in the dark times before front-end engineers and UX developers or UI designers or whatever we’re calling them this week.

Historically, this is how we’ve done web development: A designer’s job has been to make something that looks nice, throw it over the wall, and let the nerds worry about how to make it a functional thing. The nerds take whatever the designer made and chop it up into something that resembles a website. Compromises have to be made – design elements are impractical or impossible, so they’re modified or left out entirely. The designers resent the nerds for ruining their design, the nerds resent the designers for being too old-fashioned to get this whole “internet” thing, the project managers don’t understand why everyone’s being so difficult, and the content managers don’t understand what all the arguing’s about and why it’s taking so long to make a website for their softball team. Nobody’s happy with this approach.

Continue reading

You Should Use Vagrant

Setting up a web development environment has always been something of a pain. Sure, we web devs don’t have to deal with compilers and libraries and whatnot to get coding, but when it comes time to run your stuff, you need a server.

Assuming you don’t have endless resources to set up development servers remotely, and considering the pain of pushing code to a remote over and over while you write it, this has usually meant building your own server to test on. If you’re a linux user, you’ve probably gone through the steps of installing Apache and MySQL locally, a php interpreter, and so on, turning your desktop into a hybrid workstation-server. Maybe you’ve moved on from that and started using XAMPP or MAMPP or some other canned, all-in-one solution.

Then, once you’ve got everything dialed in how you want it, it’s time to start a new project and now you have to juggle vhost configurations. Then you need to work on some legacy code that needs PHP 5.2 to function, so you have to juggle multiple server setups. Then you decide to dabble in something like Rails or Django, so you install more dependencies and more libraries on top of every php extension and PEAR module you already installed for those PHP projects. Then you get a new computer, and uhhhh…

I went through variations on this theme for years, then I discovered Vagrant, and I’m never going back.

Continue reading

vim: Not so scary after all?

I’ve been using Sublime Text as my primary editor for a little over a year now, and while it’s a fantastic editor, it hasn’t quite been scratching my itches lately. I’ve used a handfull of editors and IDEs for web development over the years: notepad, notepad++, bluefish, kate, gedit, netbeans, and on and on. The whole time, even since my early Linux days as a teenager trying to install Slackware on my 486 (66DX with a sweet turbo button, for the record), there’s been whispers of that editor; The way of the ancient masters, the old greybeards who have spent years meditating in the caves of their server rooms to finally become one with unix: vim.

OK, I’m exaggerating slightly, but only slightly. I (and many others) always assumed that using vim was hard. Over the years I’d flirted with it here and there, firing it up only to get frustrated that I couldn’t even edit a config file before giving up and switching to nano (after spending five minutes figuring out how to quit).

Yet as time passed, more and more of my peers used vim simply as a matter of course. I gradually became embarrased to nano in front of my colleagues. Considering my recent discontent with my current editor, and a preponderance of my fellow developers using vim, I decided I’d finally bite the bullet and learn to use the thing.
Continue reading


I was first introduced to PsySH back at OSCON last year. While I still haven’t used it much as a debugger, I’ve found that a REPL is a handy tool to have around.

A PHP what?

PsySH implements a Read-Eval-Print-Loop, or REPL, for PHP. This might sound simple, but a REPL Reads input, Evaluates that input, Prints it to the console, then Loops back to the read step. What’s that look like, you ask? Let’s see.

>>> $foo = "Hello"
=> "Hello"
>>> $bar = "World"
=> "World"
>>> $foo . $bar
=> "HelloWorld"

Notice that after every input line, we get a corresponding output. The program is reading our input ($foo = “Hello”), evaluating it (this is an assignment, so it’s straightforward), printing it out, then prompting for input again.

Wait, We Already Have one of Those

“But wait,” I hear you say, “PHP already has an interactive mode!” True, php -a exists, but have you actually used it? It skips the Print part of that whole REPL thing, it has a tendency to crash if you accidentally have a PHP fatal error, and it doesn’t really do much aside from giving you access to a PHP interpreter.

“But wait,” I hear you say, “Facebook already did that!” Yes, phpsh is a thing that facebook did, but they seem to have forgotten about it (last updated three years ago at the time of this writing) and it has this inconvenient dependency on Python. As in, it’s written in Python, and you need to have Python available in your environment to use it. Hmm.

OK, but why?

Remember the bad old days before in-browser css inspectors? Styling elements was a major pain, right? Edit your stylesheet, save, refresh the page in the browser. Hmm, that div still doesn’t look right, let me try again, edit, save, refresh, ad nauseum. Now, thanks to the miracle of property inspectors and live style editors, we can fiddle with css directly in the browser, get real-time feedback, and save it down to our stylesheets only when we’re satisfied with the result.

So why wouldn’t you want to write all your code like this? Turns out you can write functions in the interactive shell as well:

>>> function addThese($a, $b) {
... $result = $a + $b;
... return $result;
... }
=> null
>>> addThese(5, 6);
=> 11

Forgot what arguments array_push() takes? No problem, just install the PHP manual and you can look it up right from the shell:

>>> doc array_push
function array_push(&$stack, $var, $... = unknown)

Push one or more elements onto the end of array

array_push treats array as a stack, and pushes the passed variables onto the end of array.
The length of array increases by the number of variables pushed. Has the same effect as:
]]> repeated for each var.

array $array The input array.
mixed $var The pushed value.

int Returns the new number of elements in the array.

OK, fine, how do I use it?

I’m glad you asked! PsySH is written in PHP and is available as a precompiled phar. If you just want to use it as a REPL, it’s as easy as:

wget psysh.org/psysh
chmod +x psysh

PsySH is still a young product (currently version 0.1.0) but already a useful tool. If it looks interesting, check it out on GitHub and consider contributing issues and code if you wind up finding it useful.