When I started developing WordPress plugins, most people asking questions in the support forums seemed like hobbyists building sites for themselves. Since then, I’ve noticed two trends that irk me.
Freelancers
Nowadays, there seem to be a lot more people that get paid to build WordPress sites for others. There’s nothing wrong with that, until you ask me to do your work for free.
I’m not talking about the “Hey, this feature doesn’t work.” type of requests; I’m talking about people dumping some code and asking how to make it do a very specific thing that their client requested.
If you are getting paid to do something, you should either already know how to do it, or spend the time needed to learn how to do it, instead of relying on the kindness of suckers strangers.
Commercial software
Commercial themes are booming and paid plugins are also becoming common. Again, there’s nothing wrong with that, but don’t expect much sympathy from me when the premium theme you’re using conflicts with my plugin. I know my code is solid, so why should I spend my free time debugging someone else’s product that they charge money to support?
Post in their support forums; if it turns out there’s an issue with my plugin, they should be competent enough to fix it and send a patch, or at least explain it to you.
Whenever money enters the picture, the gift economy goes out the window; you can’t have it both ways.
In the following post, I will attempt to chronicle how I came to believe that having your content in a portable format is more valuable than having an open source project to manipulate that content.
I accidentally jump-started my programming career by working on an open-source project (WordPress) and I use many other open-source applications and libraries every day, so I certainly see the value in that, as a developer.
As a user, I care more about my data. For example, if LibreOffice goes bust, I’m not going to start working on my own document editor, but I would definitely like to be able to open my documents with some other tool.
Two weeks ago, after a kernel upgrade, Ubuntu started crashing on my Macbook Air. After a few days of trouble, I decided that this would be a good opportunity to give OS X an honest try. I was using Tomboy before, on Ubuntu, to take notes. I had them backed up via Ubuntu One, so it was easy enough to compile Tomboy under OS X and copy over the data.
Even if Tomboy or Ubuntu One didn’t work on OS X for whatever reason, I could still access my notes, since they were stored as simple XML files.
By contrast, Mountain Lion’s Notes.app uses a weird binary format and to get your notes out of it, you have to go through Gmail and Mail.app.
In general, I think Apple is the worst offender when it comes to data portability. It’s aggressively trying to hide the filesystem from the user; in the name of simplicity and ubiquity, it shoves everything into iCloud, which I’m pretty sure won’t see major adoption from anything other than OS X or iOS apps, if that.
Google, with its Data Liberation Front, is on the opposite side of the spectrum. Immediately after the announcement that Google Reader would be discontinued, I was able to export my subscriptions and import them into a Tiny Tiny RSS instance on my own server.
After a while, attracted by the shiny interface, I switched to Feedly, an ad-supported hosted service. While writing this post, I discovered that Feedly itself doesn’t have an option to export my list of feeds. If it doesn’t add one soon, I will just have to find some other service that will, before Google Reader shuts down and my feed list becomes a hostage in Feedly’s walled garden.
Going forward, whenever I start using a new application or service, I will make sure there’s a sane exit strategy. I should be able to leave and take my data with me at any time, with no questions asked.
“I’m not a vicious capitalist, I don’t always have to get paid for what I do. I like to participate in the public debate.” I. I. I. Stop it, look around! This isn’t charity, the Times is a billion dollar corporation and Princeton is in actuality a gigantic hedge fund – why are you giving them your work for free? “That’s the system, I can’t change it.” Exactly.
The Last Psychiatrist
I have released or adopted a bunch of plugins over the years. Some of them are obsolete, while some are still quite popular. However, my enthusiasm for developing and supporting them has diminished significantly over the years.
Instead of letting them fade into oblivion, someone suggested that I ask for help from the community. So, if you are using one of my plugins and you want to ensure that they still work going forward, read on.
I’ve made a spreadsheet with the list of plugins up for adoption, which I’ll update as new maintainers are found.
For each plugin in that spreadsheet:
- if you’re willing and able to answer support questions about it on a consistent basis, let me know; I’ll add you to the team.
- if you’re a developer and would be interested in maintaining it, let me know and read on.
Each plugin has its own Github repository, which is then deployed to wordpress.org via a script. I can continue taking care of deployments, if you don’t want to or we’ll figure something out.
The more complex plugins use scbFramework, which is pretty stable.
To signal your interest, either leave a comment here or send an email to mail@scribu.net, mentioning your wordpress.org username (and github account, if you have one).
I’ve had this idea for a fun weekend project for a while: generate the WP-CLI manual concurrently, instead of one page at a time.
All I needed was the right programming language . Since I’ve heard good things about Go, I decided to give it a try. I took the Go Tour and then just started hacking.
A WP-CLI manual page is generated by:
- collecting data from inline PHP docComents
- reading a markdown file with additional documentation
- running everything through
ronn to generate the final ROFF output
At first, I tried to do all these steps in Go, but soon discovered that it would duplicate too much code. Eventually, I settled on just letting WP-CLI generate each page, using the existing logic.
So, I ended up with less than 100 lines of Go code:
I’ve tried on several occasions to use threads in various programming languages, but never felt I really mastered them. By contrast, I was able to grok goroutines and channels in a weekend; they just made sense.
In general, the Go documentation is the best I’ve seen so far. For instance, when you look up a function from the standard library, besides a helpful example, there’s also a link to its source code.
I also like go fmt, which takes care of formatting your code; no more worrying about spaces vs. tabs etc.
Even if it yielded a modest 23% speedup (from 17 seconds down to 13 seconds to compile all the pages), it was a worthwhile experiment.
As you probably know, Google Reader will be shutting down, come July, 2013. Instead of looking for a different hosted service to migrate to, I thought it would be better to use a self-hosted solution. I picked a PHP application called Tiny Tiny RSS.
After I set up a new subdomain and an nginx config file, the installation instructions were pretty easy to follow, except the part about setting up the script responsible for updating the feeds.
Starting The Daemon
Since I’m hosting this on a VPS, I have the possibility of running the updater as a daemon (a process that runs continually in the background). After a bit of googling and some trial and error, I came up with the following command to start it up:
sudo -u www-data php ./update.php -daemon > /dev/null &
disown $!
The sudo -u www-data part makes it so that the process is owned by the www-data user, instead of my user or root.
By using disown $!, the process will continue to run even after I end the SSH session.
Stopping The Daemon
If I ever want to terminate the daemon, I just need to find it’s process ID and send it the kill signal:
pgrep './update.php' | xargs kill -9
Also, it seems I need to delete the ./lock/update_daemon.lock file, to avoid getting a nag in the UI.
A while ago I read “Amusing Ourselves To Death”, by Neil Postman, who’s main premise is that television is responsible for the dumbing down of public discourse and for the decline of culture in general.
Then I read “Everything Bad Is Good For You”, by Steven Johnson, who shows that people are objectively smarter today, on average, than they were in previous decades. He makes a convincing argument that the main cause is TV shows, video games and other forms of entertainment becoming more mentally engaging over time. He then explains what economic incentives drive this phenomenon.
Another interesting insight was that the Internet has become the main medium through which people acquire factual information, allowing television to focus on what it does best, i.e. storytelling and conveying people’s characters.
If you’re at all interested in the current media landscape, I highly recommend both books.
The last major release of WordPress (3.5) got the first dose of Backbone.js in the form of the revamped media manager.
Since I’ve been itching to play around with it for a while, I decided to backboneify the javascript-heavy metabox from the Posts 2 Posts plugin, following this guide.
In the first part, I organized everything into Backbone Views. Even though there were some awkward parts, I already felt this was a big improvement.
In the second part, I started using proper Backbone Models, successfully separating AJAX logic from DOM manipulation.
After this little experience, I think Trek’s summary is spot on:
Backbone is approachable if you've spent some time writing applications with jQuery and are familiar with callback-style evented architectures. Backbone's DNA is basically jQuery custom events on steroids.
P2P 1.5 isn’t ready yet, but if you want to play around with it, you can get it straight from github:
git clone --recursive git://github.com/scribu/wp-posts-to-posts.git
Last weekend I had the pleasure of attending WordCamp Norway 2013.
On the first day, I gave a talk entitled Command Line Learnings For Make Benefit Glorious Nation Of WordPress:
After the main conference event, there was an after-party, which was more of a fireside chat actually (we were literally sitting next to the fireplace in the hotel lobby), and it was great.
On the developer day, I just threw together a few links to useful resources about automated testing of WordPress things.
I thought it was cool that there was also a charity hackathon organized for improving the WordPress site of a non-profit organization.
Oh, and did I mention the t-shirts?
PS: If you’re wondering what I used to make the slides, see github.com/scribu/wordcamp-norway-2013.
The last time I pondered on operating systems, it was all about how tablets and their touch interfaces are affecting the traditional desktop OS. Now, I’d like to consider the mobile scene specifically.
The current landscape is dominated by iOS and Android, which both work on smartphones and tablets.
Microsoft is trying to get Windows Phone 8 off the ground, with a half baked attempt to bring the same interface to other devices, in the form of Windows 8.
Canonical recently announced Ubuntu Phone OS, with support for both webapps and native apps. They actually have some credibility when they make the claim of shipping a unified interface across all devices.
Probabily the most interesting development is from Mozilla, which has a relatively new project called Firefox OS, where everything is a webapp.
So, we’ll soon have two competing open-source mobile operating systems from two reputable FOSS organizations. A lot of pundits are saying things like They don’t stand a chance against iOS and Android; they’re already entrenched
.
I, for one, don’t really need a mobile OS that everybody uses. If they work well enough and a healthy ecosystem of hackers emerges around them, it’s a win.
In the mean time, the most pressing question is this: What should I replace my aging iPhone 3GS with?
Update: For a much more thorough overview of the situation, see Early Thoughts on New Operating Systems.