Today, at the Agile Testing and BDD Exchange conference, Bob Martin mentioned an article in the EE Times about how microprocessors have changed the world. I looked it up, and the article uses a truly amazing example to make the point. Suppose it’s the late 1940s, and you want to build a device with the computing power of an iPhone. The most sophisticated computer at the time was ENIAC, which was powered by 17,468 vacuum tubes, had about 5 million hand-soldered joints, weighed 27 tons, and occupied 1800 square feet. A single iPhone contains about 100 billion transistors and weighs just under 4 ounces. Building the equivalent back then would have required:
And now you can put one in your pocket.
Bob went on to point out a fascinating contrast to that exponential advance in computing power: just how little computer programming has changed. Languages have come and gone, but programmers are still writing if statements and while loops. What we think of as modern advances, like object oriented programming, were originally thought up in the 1960s.
Personally, I don’t see this as a problem. Programming languages are languages – they are forms of human expression. The world has changed in many dramatic ways since the time of Shakespeare, but we can read Shakespeare today and still relate to the motives, passions, and failings of the characters. Programming languages exist to communicate a painstaining set of instructions (and therefore aren’t as engaging to read as Shakespeare). But their domain is still that of human expression, for communicating often astonishingly subtle, complex, ever changing, and sometimes seemingly contradictory needs. So, to me, it’s perfectly logical that, while syntax and techniques may be refined over time, the fundamental aspects of programming languages today would be much more familiar to a programmer from the 1950s than the incredibly small and powerful devices in which they now run.
With 12 session tracks on Saturday, followed by unconference sessions on Sunday and encore performances of Saturday’s most popular presentations, WordCamp NYC last week was by far the biggest WordCamp I’ve attended. Then of course there’s the real reason people go – the after party on Saturday (there was also the sponsors and speakers party on Friday, which was a lot of fun too). At the parties I got to do what years of social training had previously convinced me was unacceptable: discuss code while drinking beer. I got to chat for a while with @garthkoyle (from Event Espresso), @jason_coleman (of Paid Memberships Pro fame), @vidluther (from zippykid), and @tinakesova (from Siteground).
My presentation was on object oriented programming for WordPress plugins (my slides are below). I decided to focus on OOP in general with PHP, as its simply a huge topic to try to cover in 30-40 minutes. The room was full and there were good questions at the end, so it went well. I was 1 of 3 presenters from WebDevStudios – Brad presented on WordPress security, and Eric on the rewrite API.
Brad treated us to a great dinner afterwards (ribs!) and I stayed up too late with the WebDevStudios team Saturday night (including honorary team member for a night, Captin Shmit – yes that’s how he spells it). I found out at 2AM (when I checked the conference web site after we got back to the hotel) that the unconference presentation submission I made earlier in the day had been scheduled for Sunday morning.
So on my way back to the conference Sunday morning I stopped at CVS to get post-it notes and dry erase markers, for doing an Agile project management workshop. Aside from scribbling some notes 20 minutes before the session started, I didn’t have a detailed plan, and it turned out to be a lot of fun. My session was right before lunch, which turned out to be great, as almost everyone stayed after the time was up, and we went for another half hour. I started the session by having everyone describe their client relationship and software development problems (in brief post-it note format) and collected those on one side of the white board. Then I had them describe the things they want to achieve in their business (also in post-it note form), and collected those on the other side of the board. Then we spent about an hour talking through how to get from one side of the board to the other. It was only enough time to scratch the surface of Agile practices, but what made the biggest impression on everyone is how almost all software development teams face the same challenges, and that there are ways to deal with them that are concrete, achievable, and rewarding. ContentRobot selected it as one of the best sessions.
To continue with the shameless self-promotion, here are some tweets about my talks:
And here are the slides from my OOP talk (the last half of the slideshow contains my slide notes).
If you want to see more, check out the WordCamp NYC 2012 site and ChrisDigital has a collection of links to other summaries, and slides.
I’ve traveled coast-to-coast across the US 4 times, but until this past weekend I had never been in the South (except for a brief visit to UVA many years ago). I was in Nashville for only 48 hours, and I enjoyed every minute of it. The first thing I noticed was how kind and polite everyone is. The driver of my shuttle bus from the airport pointed out all the sights as we drove into town, and he seemed genuinely interested in what everyone on the bus was planning to do that weekend. I spent the day on Friday with my friend Caryn, who I hadn’t seen since we finished grad school 16 years ago. She showed me around town, and it was great to catch up.
This was Nashville’s first WordCamp. The organizers did a great job pulling it together, and they clearly had a lot of local talent to draw upon for their speakers. Coming from Philly, I think I was the only Yankee among the speakers – I felt honored to be included (Nacin, coming from DC, is a borderline case 😉 ).
I was in the developers’ track all day. The first two sessions were design focused, and here’s an excellent summary of both presentations. They were followed by the Otto and Nacin show. They are both deeply involved in the development of WordPress, and they gave a preview of features in WordPress 3.4. Their talk was the most popular of the day in the developers’ track.
I was up next after lunch, and my talk went well. It was an advanced topic (dependency injection) so I drew a smaller crowd. But I got some good questions towards the end, and some good tweets:
Here is a non-technical summary of my talk.
Russell Fair wrapped up the day, and he did a great job of sharing his experiences using LESS with WordPress.
I didn’t get to see Joel Norris’ WordPress bootcamp presentation, but from what everyone was saying, I believe he gets the prize for having the most popular session. He stayed in character as a drill sergeant for almost the entire session. And he was in costume – here’s a photo.
The speakers dinner and the after party were both a lot of fun. I learned a lot chatting with Otto and Nacin, made some new friends, and my friend Caryn was able to come too, so it was a great evening.
If you want to read more, WP Candy has a great review, and they also have links to many of the presenters’ slides. There’s also a great photo pool on Flickr. Here are my slides:
This was my second WordCamp, and my first not as a speaker. When I presented at WordCamp Philly last Fall, I was blown away by the positive energy of everyone there (which is one of the things that led to my current position with WebDevStudios). WordCamp San Diego was just as much fun, and there was plenty to learn too. Coming from Philly means it’s a long way to go for a WordCamp, but WebDevStudios was a sponsor, so several of us from the company went. Since we are a virtual company, I also met a couple of my co-workers in person for the first time – @tweetsfromchris and @TobyBenjamin
WordCamps typically have 2 simultaneous tracks – one for developers and one for users. They also provide an opportunity for these two parts of the WordPress community to come together, so online businesses can find good developers, and for developers to find rewarding projects.
I stayed in the developer track for all but one presentation, and they were all excellent. WebDevStudio’s own @williamsba presented on how to configure and use WordPress multi-site. Even in the more introductory-level sessions, where I thought I’d already know everything, I actually learned a lot. The vibrancy of the WordPress community, and the dedication of the speakers, who appear without compensation, continues to impress me.
The “spring training” theme was really well done, from the matching baseball jerseys for the speakers, to the web site, stickers, and, of course, the cake. @norcross gave his whole talk as Ron Burgundy (yes, in his boxers), which was hilarous enough to justify him being the only speaker out of uniform.
The after party was a blast. It was my first experience where it was socially acceptable to both drink and have endless conversations about code and WordPress. I have found my people 🙂 and it was great to meet @housechick, @jaredatch, @matthewjcnpilon and @i3inary.
The 2nd day of the conference was a developers’ day, held at the very sleek Co-Merge workplace. This was similiar to the developers’ day at WordCamp Philly, with some short presentations, but the focus was more on people making connections and helping each other code.
The one challenge for me was sleep. WebDevStudios rented an apartment since several of us were there. The first night there was a party happening in an adjacent unit, and the thumping bass didn’t stop coming through the floor until about 3AM. The next night someone was shot and killed right outside our apartment, and the last night one of my co-workers had to get up and leave really early for his flight. But I’m not so old (yet) that I can’t handle it (actually, having kids has conditioned me to handle sleep deprivation better than I did years ago).
My next WordCamp is in just a few weeks. I’ll be speaking at WordCamp Nashville, on how to apply dependency injection techniques to WordPress plugin development.
I took pictures throughout the day – here’s the complete album:
Update: Shashin 3.1.4 takes care of the activation issue – you no longer need to click the “deactivate” and “activate” links in the plugin panel when upgrading.
I’ve uploaded Shashin 3.1.3 to wordpress.org. Several people have complained of error messages that start with “Invalid data property __get for…” when updating to 3.1.x. These messages relate to new settings that are added during activation, but they were not actually being added. This puzzled me because the WordPress automatic updater shows a message saying it is deactivating and reactivating the plugin when it upgrades. The problem is, it’s not actually doing it – here is the WordPress defect ticket: Auto update plugins does not activate activation hooks.
Apparently this behavior is an intentional choice. I’ve submitted a patch that corrects the wording (so at the very least, plugin authors like me don’t misunderstand what it means). In the future I will make sure to work around this, but with 3.1.3, you will need to deactivate and reactivate Shashin one more time yourself from the plugin menu after upgrading.
My apologies if you’ve had other difficulties with the recent Fancybox changes. I’ve included Highslide with Shashin since 2008, and I gradually added features and made improvements as I learned the capabilities and quirks of Highslide. Due to a licensing conflict I was alerted to, I had to rip Highslide out of Shashin immediately and switch to a different viewer with a GPL compatible license (Shashin was temporarily removed from the wordpress.org plugin repository because of this). Some of the other great viewers, like PrettyPhoto, are also not GPL compatible, so I went with Fancybox. I had only a short period of time to add it, and I’ve spent many hours recently working through some of the intricate issues involved with making it work with Shashin.
Version 3.1.3 makes the following improvements:
Also, its worth highlighting that in 3.1.2 I resolved the problem of the Fancybox slideshow navigation controls overlaying controls for videos. The video controls are accessible now.
Update 3/9: I’ve uploaded version 3.1.2 of Shashin, which makes two improvements: the code for handling the FancyBox captions is now cleaner (no HTML embedded in the title attribute) and the navigation controls in slideshows now don’t overlay controls for videos (so you can use the video controls now).
Update 3/7: I’ve uploaded new versions of Shashin and Toppa Plugin Libraries that corrects the installation bug in Shashin 3.1 that was affecting new installations. You will need to update both plugins.
Shashin 3.1 is now available for download at wordpress.org. I’ve added support for WordPress multi-site installation, and improved error reporting when there are problems with album synchronization. But the biggest change is that, due to a licensing conflict, I have removed Highslide and replaced it with Fancybox 1.3.4. Highslide uses a Creative Commons license, which is not compatible with the GPL, and all code in the wordpress.org plugin repository must be GPL compatible.
While the visual style of Fancybox is different from Highslide, the functionality is mostly the same. However, there are a few limitations with Fancybox:
So why Fancybox? Despite these issues it is still one of the more robust viewers available, and it is GPL compliant. Highslide, PrettyPhoto, and even the just released version of Fancybox (2.0) all use GPL incompatible Creative Commons licenses.
Making the transition to Fancybox was a huge effort. I’ll be willing to entertain including another GPL compatible viewer if you can recommend one that doesn’t have these technical limitations, but not right now 😉
In my new position at WebDevStudios, I’m wading deep into the world of WordPress multi-site functionality. In version 1.2 of Toppa Plugin Libraries, there’s a new method which makes it easy for plugin authors to make their plugins WordPress multi-site compatible. It is based on the excellent code Shibashake made available for doing this. I took that articles’s 3 separate (but almost identical) functions for activating, deactivating, and uninstalling a plugin, and abstracted them into a single method. Why? Because “duplicate code is the root of all evil in software design.”
As a plugin author, all you need to do is write your activation or deactivation function as you normally would, and then:
$functionsFacade = new ToppaFunctionsFacadeWp(); $functionsFacade->callFunctionForNetworkSites('yourActivationFunction');
This will call your activation (or deactivation) function for every site in the network, including the parent site.
Or in an object context, after passing the FunctionsFacade to your object:
$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourActivationMethod'));
For uninstalling, you need to pass a 2nd argument, which indicates that the “networkwide” flag should not be checked (for some reason, WordPress multisite uses this flag for activating and deactivating plugins, but not for uninstalling).
$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourUninstallMethod'), false);
I’m going to release the next version of Shashin soon, which uses this method to make it multi-site compatible, so I wanted to get this Toppa Plugin Libaries release out first. Enjoy!
In the last episode of WP Late Night, there was a brief debate about plugin size. Ryan expressed a preference for smaller plugins with tightly focused functionality. It’s natural to worry that, as the number of lines of code increases, so does the likelihood of bugs, and performance slowdowns.
This concern makes sense if you’re assuming plugin code is not very well organized and not very well tested. Unfortunately, that’s a safe assumption with many plugins. As plugin authors, we should have higher standards for our work. There are two things that come to mind:
More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.
Wulf, W. A. “A Case Against the GOTO,” Proceedings of the 25th National ACM Conference, August 1972, pp. 791-97.
The rule of thumb is to optimize for readability and maintainability first. If a performance problem comes up, it is likely stemming from a small area of the code, and you can focus your performance optimization efforts there. As one person put it: “There is far, far more money wasted on fixing and customizing and maintaining hard-to-read code than there is lost on inefficient code.”
There are many techniques involved with writing clean code. A foundational one is following the Single Responsibility Principle (SRP). Bob Martin has a very succinct definition of the SRP: “a class should have only one reason to change.” In his book Agile Software Development, he explains further:
If a class has more than one responsibility [more than one reason to change], then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the ability of the class to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
If you follow the SRP, then it doesn’t matter how big your plugin is. What matters is how you use it.
The trick, of course, is figuring out what it means to have a single responsibility. WordPress itself helps you figure this out. When you call a WordPress hook or filter, it’s likely that you will want to create a class that implements what you intend to do for that hook or filter call. For example, if you call add_shortcode
, then you should have it instantiate a class that implements your shortcode. If that class needs to change, it will be only because your needs for the shortcode have changed. The shortcode logic is not tightly coupled to other parts of the code. Removing that coupling is an important step towards also removing that sinking feeling of fear when you start monkeying with the innards of some gigantic application.
Not every hook and filter call deserves its own class. Some are merely stepping stones to others and do not need their own class. For example, if you call admin_menu
simply for the sake of calling add_options_page
, one class is enough. Others may need more than one class to support them. But for getting your feet wet, having a class per hook or filter is a good place to start.
My Post to Post Links II error: No post found with slug "shashin-wordpress-plugin" has a total of 55 classes and subclasses (you can see the code on GitHub). How can you find what you’re looking for in all those classes? It sounds horribly bloated for a WordPress plugin, right? It’s actually the opposite.
A coding habit that goes hand in hand with the SRP is the use of meaningful names. Each class in Shashin serves a specific purpose, and has a name that tells me what it does. If I need to make a change to the settings, I go to the Settings class; if I need to make a change to how album synchronizing is done with Picasa, I go to the PicasaSynchronizer class, etc. The majority of the classes are less than a couple hundred lines. With small, well-named classes and methods with clear purposes, when there is a bug, it’s usually not hard to find. And if I need to change something, I can make that change in one place with a greatly reduced fear of breaking something unrelated.
By using a class autoloader, such as Post to Post Links II error: No post found with slug "toppa-plugin-libraries-for-wordpress", you can also save yourself the trouble of figuring out where to put require_once
statements, for loading your class files. With an autoloader, a class file is loaded only when “new” is called (so if you are worrying about performance with so many objects, they are only loaded when they are actually needed). How you keep track of object dependencies, and when and how you instantiate your classes, are what I’ll write about in my next post, which will cover using an injection container.
A feature of WordPress 3.3 is the new QuickTags API, which makes it possible for developers to add buttons to WordPress’ HTML Editor button bar. My Extensible HTML Editor Buttons plugin uses this API to allow non-developers to easily add buttons. It includes a WYSIWYG settings form for creating new buttons. You can use it to specify the label for your button, the tag you want it to insert, and whether it is a self-closing tag (such as an <img> tag). If you’re comfortable with HTML (and you should be, since you’re using the HTML Editor!), you can also create a custom dialog for your button to launch. This is handy if your tag has multiple attributes (such as class, title, etc). And for plugin developers, it has an API that uses a simple method call where you can register your own button. This is useful if, for example, your plugin uses a shortcode and you’d like to create a button for it, without having to delve into the QuickTags API yourself.
Something I quickly learned working with the QuickTags API is that it’s fairly limited. It’s really designed just for adding simple buttons. Supporting custom dialogs through it required me to do some jQuery gymnastics – see my buttonController.js file if you want the gory details.
If you’re interested in the QuickTags API itself, the qt.addButton function in wp-includes/js/quicktags.dev.js has detailed explanatory comments, and there’s a good, simple working example in this gist file.
Aficiondos of toppa.com (if there are any such people) may notice this plugin sounds a lot like my old Koumpounophobia plugin. That plugin did a lot of jQuery-based scraping of the HTML Editor to make it possible to add custom buttons, since there didn’t used to be an API, and it ceased to work with the rewrite of QuickTags in WordPress 3.3. Also, the name I gave it was a poor choice (it means “fear of buttons” – totally obscure and a little too clever…). So I took the opportunity to re-write it and give it a much more descriptive name.
This past summer I started attending the Philly WordPress meetups, which led to an opportunity for me to speak at Philly WordCamp, which led to an amazing opportunity to work at WebDevStudios, with an amazing team. Today – Monday – was my first day on the job. I’m doing custom development work and soon I’ll get involved with project management. I’m starting with some enhancements to Baja.com. Friday was my last day at Penn, so my head is spinning a bit from the transition.
I’ve been part of the web team in Penn’s School of Medicine since 2004, and I’ve been Director for the past 2 years. My team had a lot of demands placed on them, with the need for projects outpacing what we could provide. One of the first things I did as Director was learn Agile practices so I could teach them to my team (and I brought in a scrum coach to help). These two graphics illustrate the two primary challenges we faced – not enough staff, and too much chaos:
For many months my work spilled over into nights and weekends as I tried to move things forward. I can’t say we entirely solved these problems, but we made a lot of progress, and got the wheels turning in higher levels of administration to address the situation (“turning the aircraft carrier,” as one of our project managers put it – change is not easy to implement in a huge institution). Deciding to leave was hard, but an opportunity to turn my WordPress plugin development hobby into a job, to work with Brad (@williamsba) and the WebDevStudios team, and having the flexibility of working at home… it was too good to pass up. I’m especially looking forward to having more time to code again. If the past 2 years have taught me anything, it’s that I have a passion for software development, and always striving to do it better.