Flint-Knapping Arrow Heads

Image shows leather hand-pad, copper-tipped pressure flaker, small stone (Jasper?) arrow head and larger glass/beer bottle arrow head (both made by me, today).

A few weeks ago I decided to have a look on Meetup.com and see if there were some meetups that looked interesting enough to attend in the area. I spotted the Wilderness Awareness and Survival Skills in Denver group, and joined it immediately. I’ve been interested in this sort of thing for a while, and even attended a week-long school with Tom Brown a few years ago. The next meetup was going to be a basic flint-knapping class, which is something I’ve wanted to try for a while. We talked about it at the Tom Brown Tracker School class, but like so many other things, didn’t have time to get any hands-on experience. I’ve also been watching a bit of Ray Mears stuff lately, and he does some basic knapping in some of his episodes, so I had some recent motivation to check it out.

The meetup was held in the court-yard/shared space between 2 apartment blocks, one of which our guide lived in. Andrew is a really personable guy who apparently works for Denver Parks & Rec at the moment. He’s also studied and been practicing primitive skills for a while, and these meetups are his way of passing those skills along to others. He was really well-prepared, and provided us with everything we needed (except a chair) to get started, and to make some simple blades/arrow-heads.

We were mostly aiming for 3-notch arrow heads, since they give a notch to got in the end of an arrow shaft, and then 2 side-notches for binding the head to the shaft. They are a little more complex than some of the others I’ve seen (or the ones that Ray Mears was making), but they aren’t that hard once you get the hang of things, and I guess could even work without any natural glue, which is an advantage. They definitely require a fine, strong point on your pressure-flaker though, so you need something like a deer antler, or if you’re using some modern tools, then a copper-tipped flaker like we used works nicely.

For practice, we used the bottom of beer bottles, which flake pretty nicely, are cheap and easy to acquire, and are pretty consistent (so you don’t have to figure out crazy impurities or anything). To get the base off, we put a giant steel nail inside the bottom, then just shook it up and down a little until it popped out the base. Then you start flaking off the edges and go from there.

You’ll need:

  • A strip of leather (which you use in your hand, to guard against sharp flakes, and the tip of your pressure flaker)
  • A round/smoothish rock (or a few different ones), for percussion flaking and also for “platforming”
  • A pressure flaker, which you can see in the picture above (that’s a thick piece of copper wire in the tip of a piece of Aspen (I think, the wood doesn’t matter that much, just make it soft enough to get the wire in there). Traditionally, you’d use a deer antler (which we also tried). They are amazingly strong, and already pointed.
  • Stone/glass to knap.

There are 3 main things we were told to keep in mind:

  1. Platform: this refers to setting up the edge that you’re working on. Basically, you use a rounded stone to abrade/grind off the edge so that you can remove all the small irregularities and provide something a bit more substantial for your pressure flaker to grip onto.
  2. Centerline: which is just referring to the rough centerline of the mass of your piece, on a horizontal plane. You always want to be flaking down from this line (into your hand, “under” the piece you’re working on).
  3. Acute: you’re looking for acute angles, below the centerline. That’s where you can get good flakes, and make progress. If the angle is obtuse, there’s nowhere for your flaker to grip, and you won’t be able to flake anything off.

I went back and found my notes from Tracker School about flint knapping, and was impressed to see that they lined up almost 1:1 with what I learned today. Getting a chance to try my hand at it really made a difference though, and I’d like to give it a bit more of a shot in the future. I’m particularly interested in super-simple, percussion-flaking, which is something that seems like it could be immediately useful in a survival situation (where you’re not going to have something like antler or copper wire handy for true pressure flaking).

A big shout out to Andrew for being a great teacher, and I really look forward to having some more classes and adventures with him and the others.

One Less Plugin, Thanks Jetpack

As a developer, I’m a huge fan of “red changesets”; when you get to delete more code than you add. Less code means less maintenance, less potential for bugs, security problems, etc. Today I got to “red changeset” the plugins powering this website because I realized I could just go ahead and delete the plugin I was using for update notifications.

I’ve been running a plugin here for a while now that emails me when I have updates available for plugins, themes or core on my WordPress installation. With the latest version of Jetpack though, I get that notification via a simple little indicator on WordPress.com (and I’m there every day already). In addition to the notification, I’ve enabled the auto-update feature for all plugins on all sites connected via Jetpack, so now I don’t even have to think about keeping my plugins up to date.

There’s a lot more cool stuff coming in this Jetpack/WordPress.com integration, and I’m really excited to see (and work on) what we can do to help make life easier for self-hosted users while leveraging the power of WordPress.com.

Simple Search Operators

I’ve long wanted to be able to do some simple, operated-powered searches within WordPress (especially relevant in a project I’m working on at Automattic). After a conversation with Allen, where he wanted to do the same thing, I figured I’d just whip up a quick plugin to see how hard it’d be. Turns out the answer is “not very”.

Simple Search Operators is a quick plugin that expands the functionality of the default search system in WordPress so that you can use a few useful operators (might look at adding some more at some point) [all links in the following list go to live searches on this site, using that operator]:

  • author:beau will limit results to posts written by the author with the username/slug ‘beau’
  • tag:burrito will only return posts which are tagged with ‘burrito’
  • category:posts (or cat:posts) to search for posts categorized as ‘posts’
  • tag:burritofriday cancun author:beau to search for posts containing ‘cancun’, written by ‘beau’, tagged as ‘burritofriday’

Some caveats:

  • Not heavily tested! May well be capable of generating server-melting queries
  • Only supports one of each operator for now
  • Operators and freeform searches may be combined (e.g.: “tag:burrito cancun”)
  • Does not support spaced strings for operators, so you can only do things where a no-space string attached to an operator will get you what you want
  • Because of the way it manipulates query variables, might mess with other plugins or themes in adverse ways. Like I said, not heavily tested.
  • Not available via the WP Plugin Repo yet; will get it up there once it’s baked a little bit

If you’d like to give it a shot, please do. If you’d like to add more operators; shoot me a pull request and we can expand this out a bit.

WordCamp Saratoga

Through some lucky scheduling, I was able to attend both LevelUp Con and WordCamp Saratoga in a single trip. I spoke at WordCamp about how to build a quick Backbone.js application which used WordPress as the backend (interfacing via the REST API). I thought my talk went OK, although I didn’t love it to be honest, and in hindsight I kind of wish I’d dived a bit harder into some better examples of how Backbone works with Views and whatnot. Here are the slides I used:

And if you’re interested in the code, it’s all available via Github. I got a few nice bits of feedback as well, so that was good:

LevelUp Con

Last week, I attended the first ever LevelUp Con (which WordPress.com sponsored) in Saratoga Springs, New York. I was really impressed with the event, which was organized by the crew at Mad Glory to help draw attention to upstate New York’s tech scene, and to expand people’s horizons and help them cross-train a bit.

Apart from the wonderful people, beautiful setting (upstate NY is ridiculously gorgeous at this time of year) and smoothly-operated event logistics, there were a few really good talks that made the 2-day event click for me.

  • Kevin Hoffman spoke about co-design, and about how to get people involved in the process of design, without falling into design-by-committee. I really liked his approach to meetings (if you’ve got to have them, at least make them work for you). His (beautifully illustrated) slides are available for download.
  • Andres Suarez (currently SoundCloud, previously Tumblr) talked about isomorphic JavaScript applications (server and client-side rendered, with the same code). It was the first time I’ve seen real, working examples of the technology, and it’s super-relevant to some things we’re doing at Automattic (which also use Node and React).
  • Justin Searls spoke passionately about open source project maintenance, dependency trees and trolls. It sounds crazy, but it came together, made sense, and was spot on. Hopefully he’ll get the slides up somewhere because it was pretty awesome.
  • My colleagues, Simon Ouderkirk and Daryl Houston spoke about Developing Hospitality and about taking the idea of Service and Hospitality and applying it both internally and externally as a lens to look at your support structures. It was a really interesting twist and their on-stage “performance” was a lot of fun.

Thanks to everyone who attended, and to all the other folks who spoke. The single-track, 2-day, planned schedule was a really interesting approach, and I think it worked nicely. Hopefully there’ll be another LUC, and I’ll get to go to the next one as well!

Automattic Grand Meetup, 2014

Once a year, all of Automattic gets together in one place for a full week of face-to-face work, learning, food and fun. We fly in from all around the world, shuttle to a hotel/resort/space of some sort, and then get together to work through a bunch of things. This year we descended upon Canyons Resort in Park City, Utah (another US state crossed off my list!). The week was roughly structured into a front-loaded, work-type-things section, and a tail end more loaded with activities. For my part, I:

  • Learned more about Node.js (and got a copy of coworker @TooTallNate‘s “Node.js in Action“), specifically in relation to some new applications we’re building out at WordPress.com
  • Worked with React.js some more (which is awesome and pretty exciting)
  • Went on a 5km run (walked the first bit, but then my knee was feeling OK so I ran most of it)
  • Took a gondola ride up the mountain, then went on a ~1.5 hour hike through beautiful aspens and conifers, past a trout-stocked lake and through some downhill MTB trails
  • Went on a guided fly fishing trip with guides from Trout Tales, where I (finally!) caught my first fish; and then my second and third as well
  • Visited High West Distillery for a tour, tasting, and picked up a bottle of their Son of Bourye (a delicious blend of Bourbon and Rye)
  • Met a bunch of new Automatticians and spent time hanging out and getting to know people new and old
  • Road tripped from Denver, CO to Park City, UT and back again with @alternatekev and @michaelarestad

Michelle did a great official write-up on the WordPress.com Blog.

Here is a collection of shots from the week (including the trip there and back):

* Title image taken by Luca Sartoni

Phantogram Blew My Mind

I just got back from seeing Phantogram play at the Ogden Theater here in Denver, CO, and they blew my mind. It was definitely one of the stand out shows that I’ve seen recently, which was extra impressive for a Monday night, at a venue I can walk to from my apartment, for $25.

Their set was super tight, and flowed really well. Instruments were switching constantly, and the four of them wove guitar, drums, keys, bass and samples together flawlessly. The two core members, Josh and Sarah, switched vocals every few tracks to provide a balance and variety that kept things interesting, while one of the best-executed light shows I’ve seen played on around them. Their stage presence was dramatic, powerful and engaging, when it wasn’t intimate and personal, depending on the track.

If you get the chance, go and see them, you won’t regret it.

I was moved enough to buy a shirt as a memento, which I almost never do at live shows.

* Header image from Wikipedia entry.

Why JavaScript Is The Next (or first) Programming Language You Should Learn

I’ve been asked a few times recently what programming language I’d learn if I was just starting out. Right now, the answer is definitely JavaScript, and here’s why:

Easiest Development Environment

I believe one of the biggest hurdles for people to get into programming is actually all of the other stuff around just writing code. Anything you can do to get to the point where you’re writing code faster (at least while you’re learning) is a win in my mind. Everyone has access to a web browser, which means everyone now has access to a simple development environment. If you’re using Chrome on a Mac, press cmd-opt-j. Welcome to the console, you’re now able to start writing JavaScript to manipulate the page you’re looking at. That’s pretty awesome. There are also a bunch of online editors and tools like CodePen, JSFiddle which allow you to dive into a more complete development/testing/prototyping environment right in your browser.


JavaScript makes it really easy to write simple code when you’re getting started, which is perfectly valid. Define a function, call it. Make a loop. Ignore the DOM (in fact, ignore the web almost entirely) and focus on simple logic and code. Start building objects and arrays. The OO-model in JS can be a little weird (especially around classes and inheritance), but that’s OK, you’re going to need to be flexible if you’re going to be a developer anyway. Once you get the basics figured out, you can start diving deeper and discover the full power of JavaScript.


The flip side of the previous argument is that JavaScript is also super flexible (arguably too much so!). Once you move on from a few functions embedded directly in script tags in your page to manipulate an image or a menu, you can quickly move towards a fully-architected web application with many files, larger object/class-style structures, complex single-page-applications and a whole lot more. JavaScript actually scales up quite nicely to handle bigger challenges, and is ideally suited to web applications, since it’s so tightly integrated with the DOM and the browser.


As much as native mobile app developers would have you believe that apps are the future, I still think that open web technologies are the key to the future. Give it a little time, and we’ll mostly be writing all of our mobile apps in HTML/JS, and deploying them in wrapper-apps to our phones. I consider this basically inevitable. Learning to develop for the web is super important. You’ll need to know it basically regardless of what main language you’re working with, because despite our best efforts, you will still end up manipulating CSS, tweaking some HTML tags, etc. That’s not going to go away any time soon I don’t think.


This is pretty far down the list, but that’s mainly because of a thought progression more than anything else. I actually see this as a really important reason for why you should learn JavaScript. Here’s the deal — if you want to develop things for the web, you will end up writing JavaScript. There’s no avoiding it. There’s only so much you can do with a server-side language (PHP, Python, Ruby). At some point, your payload is delivered to a browser, and if you want to do anything remotely interesting there, you have to do it in JavaScript. So if you’re going to have to learn it anyway, why not optimize that process (and perhaps use JS in more places, rather than less?).

Portable (browser/server/native)

Now that we have things like Node.js, JavaScript has moved beyond the browser. Not only can you write server-side JS (so you can build the front and back-end of your web application in JS), you can also use something like node-webkit to bundle it up into a distributable desktop application, or use PhoneGap to package it as a mobile app for any platform. No other language can match that portability right now.


If all of the above wasn’t enough, the exploding JavaScript community has really come a long way in the last few years as far as the developer’s toolchain goes. While we might not have the integrated, one-stop-shop approach of something like XCode for Mac developers, we have tools like Grunt and Gulp which allow us to build our own asset pipelines. Every code editor known to man has support for JavaScript syntax highlighting and linting, and we don’t need a build process like other languages, so we’re lighter on our feet anyway. There’s also a bunch of tools for testing; everything from unit tests to functional tests, to fully automated simulations of users-in-browsers.

So anyway — there’s never been a better time to get started with coding, and if you’re going to do it, I suggest starting with JavaScript. Start small, work your way up. View Source. Get on Github. Go nuts.

Why Web Development Is Complex

I keep hearing things like “programming is easy” and “everyone should code”! These are both interesting, kind of misleading statements. The actual core part of programming — actually writing code, is perhaps not that hard. Writing simple code is, relatively, simple. Many more people can, and should, probably learn to do that. Actually being a good developer is vastly different (and massively more complex).

It’s a worthy goal for people to get into development, and I love that more and more folks are, but you should also set your expectations realistically if you’ve never coded anything before. You can learn some basics pretty quickly, but you have a lot to learn before you will be fully proficient in a real development environment.

If you’re building something big-ish on the web, here’s a non-exhaustive selection of the things that are (or potentially are) relevant to that process:

  • HTTP
  • File paths
  • DNS
  • Servers and Clients
  • Databases
  • HTML
  • CSS
  • JavaScript
  • Browser Compatibility issues (affects all HTML, CSS and JavaScript!)
  • Web Server configuration and tuning
  • RTL languages and their effects on your designs/layouts
  • Internationalization, including keeping your designs flexible enough to handle variable-length text
  • Search Engine Optimization, normally based on dynamic, user-input data
  • Semantic markup
  • Accessibility
  • Design
  • Color theory
  • Visual hierarchy
  • Graphic design/image manipulation
  • Image optimization
  • Web fonts/Icon fonts
  • Image sprites
  • FTP
  • SSH
  • Scalability
  • Memory management
  • Performance bottlenecks
  • Mobile web development (infinite screen sizes)
  • Responsive Design
  • Touch vs Click interaction models and considerations
  • Offline considerations/handling (for “live” web apps)
  • Version/Source Control (Git/SVN)
  • Visual/Text Editors
  • The command line (and everything that comes with it)
  • Retina/HiDPI screens vs “normal” screens

Depending on the specific technology stack you end up using, there will be entire swaths of other technologies, libraries and tools involved as well.

Guess what I didn’t even actually mention in that list? A server side programming language (unless you’re going to use Node.js and write JavaScript on your server perhaps). So all of that other stuff up there doesn’t even actually get you writing the code on your server (PHP/Python/whatever) to do the heavy lifting that you’re here to do.

Also, just so that you’re aware; in the 15 years I’ve been doing this, the list never gets shorter, it only gets longer.

Automattic, 5 Years In

On May 11 (today) in 2009, I started full time at Automattic. I’ve written about my experiences over the years, and marked the occasion each year in some small way. Let’s continue the tradition.


This year has actually been a particularly big year. Probably the headliner happened only a week ago; Automattic raised $160 million, on a valuation of $1 billion. That’s a lot of money. That’s a large valuation, and it feels kind of weird to be employee #35 of a company of that scale. We’re now at 247 employees, and we span 30[1] different countries. Whoah.

Other than that, this year we: had a pretty large secondary fund-raising ($75m, via Tiger Capital), made some exciting acquisitions: Cloudup, Scrollkit, Longreads, had another successful WordCamp San Francisco (where I spoke, and organized the Contributor Day again), launched WordPress.com Connect, transitioned to a new CEO (Matt Mullenweg, our founder), and a bunch of other interesting things both internally and externally.

On a more direct/personal note, I feel like I’ve settled into my role as a team lead, and my team and I continue to evolve our development practices towards a modern, iterative workflow, heavy with JavaScript, Sass, and the like. Shout-outs to Allen, Gary, Jennifer and Kevin (my team) for working with me as we continue to make it all up as we go.

 In my sixth year as an Automattician, I’ll be relocating to Denver (my second relocation since I started, capitalizing on working for a completely distributed company). I look forward to new adventures there, and continued adventures with Automattic. It continues to be an inspiring and challenging company to work for, full of interesting and impressively-smart people.

Thanks everyone for continuing to make Automattic home, it’s the best job I’ve ever had, and it would be hard to ever top.

[1]: Argentina, Australia, Austria, Brazil, Bulgaria, Canada, Denmark, Finland, France, Hungary, Iceland, India, Ireland, Israel, Italy, Japan, Lithuania, Luxembourg, Malta, Portugal, Russia, Scotland, South Africa, Spain, Sri Lanka, Sweden, Switzerland, United Kingdom, United States, Uruguay.

The Future of WordPress: REST API + Javascript single-page app?

DISCLAIMER: These are my personal thoughts only, based on what I’m seeing around the web over the last few years.

Working on o2 for the last few months, and spending more and more time in amongst the Javascript community at events like jQueryConf, BackboneConf and dotJS, I’ve started thinking about the future of WordPress differently.

WordPress currently consists of a large, complex, PHP codebase, sitting on top of a MySQL backend. plugins are primarily PHP, with a light sprinkling on Javascript to mostly provide UI “candy”. Part of the reason for that is probably because:

  1. It’s pretty hard to interact with WordPress on any real depth using Javascript, and;
  2. If you’re trying to provide any custom functionality for WordPress, you pretty quickly end up doing it in PHP because that’s where all of the internal APIs and functionality resides.

That’s been a fine approach for the last 10 years, but I believe that things are changing, and we need to change with them to remain relevant. Full page reloads with heavy server-based everything is no longer really acceptable for a solid UX. With that in mind, here’s a possible future for WordPress, extrapolated out from where some things seem to be going (on the wider web, not necessarily currently within WordPress development):

WordPress core becomes 2 “separate” portions; one is a PHP-based REST-style API. Effectively, a layer that provides a structured API onto our database. That would cover all posts, users, settings, queries, meta data etc that lives within the WP DB. The other piece would be (ideally) a pure Javascript, single-page web application which fully implements the API to deliver what we currently know as wp-admin.

Plugins would create additional endpoints within the backend API, or would supplement existing ones (e.g. post/meta) with additional data and/or actions. They could also be implemented via pure JS, depending on what they were built to do. Themes could potentially be built using no PHP at all — making queries directly to the API via JS, and then using something like Mustache to template the output back to the user. This would have SEO ramifications, but we can always figure something out there, and search engines are constantly improving.

To get there would take a long time, and at many points it would no doubt break all sorts of plugins. This would be a huge shift and I think would actually be really hard to accomplish within the community, which makes me scared because I think it will be rejected as a direction (or at least slowed down a LOT) because of backwards compatibility at the very least. Perhaps we can maintain backwards compatibility for some plugins by at least making the new wp-admin a hybrid app, which leverages a JS-based approach for all truly core functionality/views, and then falls back to full page reloads for plugin-based admin functionality. Without a lot of work, that approach would still break for “integrated” plugins (where they inject settings  into or manipulate existing admin pages), if we assume that all of those pages would become powered by/created via Javascript + API interactions.

Unfortunately a crucial point where backwards compatibility would be important would be the Post Editor, which is also where some big performance/UX improvements could potentially be seen by switching to a largely JS-powered UI.

I don’t know if this is really where WordPress will go, or if it is, exactly how it will get there. There’s a project currently to build a core REST API which I’m eagerly observing and will be trying to get more involved in. It has the potential to become the kernel of the future of WordPress if it’s done right. This is going to be a long road either way, so I’m excited for where we can all go from here.

Do you think WordPress can (or should) move in this direction?

The Year Without Pants

Today is kind of exciting, although it’s been a long time coming so it’s not much of a surprise for me 🙂 Today Scott Berkun, the author of books such as The Myths of Innovation, and Confessions of a Public Speaker, releases his latest book, The Year Without Pants: WordPress.com and the Future of Work.

The book gives an inside look at what it’s like to work at Automattic, and to work on something like WordPress.com. Scott was my direct team lead (of the team that I now lead) while he was at Automattic, so the book contains a lot of personal interaction with yours truly. It also happens to be a fun read with a bunch of interesting insights into distributed teams, management, and the open-source-based culture we have at Automattic, and which may well be the future of many more companies.

I’ve read versions all the way back to some of the first drafts, and am right now reading the “final” version which I received in hard copy. You should go get it and read it as well.

A Whole New Dented Reality

Back in April, this blog celebrated 10 years of existence, and it’s been almost five years since the theme on this site changed. Yesterday I decided to just go ahead and flip the switch on something I’ve been working on here and there since late last year. It’s a complete new, very experimental theme that I call “Homeroom“.

There are some specific things driving what I was aiming for with Homeroom:

  1. First and foremost, a lot of the decisions are based around the intention that it would use Keyring and the Social Importers to pull in my content from all over the web. With that much data being collected and displayed here, I realized I couldn’t go exactly with a traditional blog layout, and had to get a bit creative with some types of data.
  2. It’s intentionally heavily integrated with Jetpack (although it works without it). Jetpack powers the comments, infinite scroll, sharing buttons and more. I’ve taken care to try to make that integration feel as native as possible (although I know there’s more to be done there).
  3. Homeroom started out as an _s-based theme, although it’s been pretty radically modified from there.
  4. I’m using a technique that I’ll call “post lookahead” when going through the loop to check the next post, and do some things like collapse sequential posts if they’re the sam type of thing.
  5. I wanted something with a bit of a timeline feel, since it’s now collecting some much data, and it’s all sequential; I wanted to show the relationship of different things along that sequence of time.

It’s not particularly beautiful because, well, I’m not a designer 🙂 In the near future I’ll be talking to some friends who are though, so hopefully I can get some advice on improving things there. I’ve been mainly focused on getting it working the way that I wanted it to. Here are some other bits that might be interesting:

  • Allows custom Header and Backgrounds via wp-admin
  • Options (currently defined in a file, because I haven’t built a UI) to control some preferences around stuff like hiding Foursquare check-ins until a set amount of time after they happened (to help avoid the creepers!).
  • Heavy use of Post Formats
  • Ability to hide Twitter replies, which you probably don’t want showing up on your site.
  • There’s the beginnings of a front-end post box (partially inspired by o2), although it doesn’t actually work yet
  • Handles Foursquare checkins differently. Rather than showing them all as individual posts, it “collects” them and shows a single, multi-point map at the end of each day.
  • Shows a map automatically on any post using the WordPress-recommended postmeta fields.
  • Using the new taxonomy introduced in Keyring Social Importers 1.4, allows you to easily filter your display based on where posts were imported from.
  • Includes a custom icon font from IcoMoon to display social icons indicating where things were imported from.
  • Search results use a Masonry-based layout so that you can quickly scan the results. Unfortunately something is broken with the search mechanism on this site right now, so that’s not working 🙁
  • Automatically lists out child-pages when you view a Page that has them, for example my Projects page.
  • Dynamic heading re-writes: format your posts for individual viewing, and the H1 etc tags are automatically “stepped down” on listing pages to maintain hierarchy
  • Has some fun mapping stuff for TripIt in particular, which draws out a “flight path” between airports. Check it it out in my TripIt section. Here’s a fun one.
  • Uses Photon to apply some effects to images in places
  • Borrows liberally from the styling of sites like Instapaper and Readability.

There’s still a lot of work to go, both on the theme itself and the importers that power a lot of the content. I wanted to get this online because I knew that’d motivate me to spend more time on it. I’m also hoping that other folks might be interested and/or have some ideas on ways to improve the theme. I haven’t got all of my content imported yet (that takes a while 🙂 ), but you’ll see more and more things fill in over the coming week hopefully.

If you’ve got any ideas for improvements, I’d love to hear them down in the comments!

Keyring v1.5 & Social Importers v1.4

Yesterday, I released version 1.5 of Keyring, and version 1.4 of the Keyring Social Importers bundle for WordPress. This update moves the Social Importers away from using a postmeta value (keyring_service) and introduces a new taxonomy that keeps track of where posts were imported from. It’s optimized towards management within wp-admin, but you can also use it for front-end queries of your posts. The update for Keyring introduces a new service file for Moves, and fixes a bug in the OAuth2 base service.

The new taxonomy for the Importers is called keyring_services on the backend, and is labeled “Imported From” in the admin UI. It will auto-create itself based on all of the importers installed. You’ll see it within wp-admin under the Posts menu, and will be listed on the “All Posts” listing as well:

Screen Shot 2013-09-15 at 9.10.59 PM

Clicking the name of a service under the “Imported From” heading will filter the posts list by that service (e.g. Twitter). The main reason that the taxonomy is exposed through the admin UI is so that you can tweak the slugs if you’d like to. I noticed that on my install, I’d already used things like ‘twitter’ and ‘foursquare’ as tags, and so they had claimed the namespace for that slug. WordPress’ shared terms are annoying like that :). So, if you’d like to use the slugs of source services in URLs, you might want to rename them:

  1. Go to Posts → Tags
  2. Search for and rename the slug for each of the services (e.g ‘twitter’, ‘foursquare’, ‘flickr’). Name the slugs something like ‘twitter-3’
  3. Go to Posts → Imported From and rename the slugs for each service to the “clean” version (without a ‘-2’).
  4. Optionally go back to Posts → Tags and rename those tags again back to the -2 versions.

As part of this change, you’ll want to update any previous posts that you imported to using the new taxonomy. I’ve included a quick and dirty script to do this. It’s called migrate-keyring-postmeta-to-taxonomy.php and can be found in the root of the plugin. To use it, you need to move it to the root of your WordPress install, and then you can just access it through your browser. It’s likely that it’ll run out of memory or time out, but it’s written in a way that you can just run it over and over again until it finishes cleanly. On my server, once it was finished and produced no output, Chrome decided to display a “friendly” error message instead of anything useful. Once that’s done, your existing posts should all be converted over to using the new taxonomy, and there should be no more postmeta entries for keyring_service.

If you’re doing a clean import, I recommend doing it without auto-import enabled, and then once you’ve fully imported everything, enable auto-import and let it run from there.

o2 at WordCamp San Francisco

I just realized that I never posted anything about speaking at WordCamp San Francisco. This was my 8th WordCamp SF (I’ve been to every one since the first, in 2006), and the second one at which I have spoken. Matt invited me to give a short introduction to the work we’re doing with o2, which is the next generation of P2. It’s not available for external (non-Automattic) use yet, so I had to settle for a relatively surface introduction, and couldn’t give people a link to download it or anything which was a bit of a pity, but it still got a good reception.

o2 is a pretty different approach to building on top of WordPress, and has meant a steep learning curve for my team and me. We’ve been digging deep into the world of front-end development, and ramping up quickly on Backbone.js, Underscore.js and a bunch of new development approaches and workflows. It’s been really fun. I’ll let the presentation do the talking though (you can also watch it on WordPress.tv):

And here are the slides I used, which you can also see on Slideshare.net.

We’re really excited to get o2 out into other people’s hands, but we’ve got a lot to build still before other people can experience it in a similar way to how we do at Automattic. The future is bright.

4 years on Automattic

On this day, 4 years ago, I started full time with Automattic. This is my 4th Automattiversary.

I had already been on trial for 5 months by that point (since January), and had a good feel for the company and the other Automatticians. I knew it was where I wanted to be. So I accepted the offer, and became a fully-fledged member of a relatively small team (I was employee number 35) that was bringing blogging to the people (amongst other things).

In the four years since then, a lot has happened and changed.


10 Year Blogoversary!

10 years ago today, I posted my first blog post on this site. That’s pretty much forever on the internet, and I think it probably also makes me old. A lot has changed in the last decade, both on this website, and for me personally (and the world at large). Let’s have a quick look shall we?


When I first created this website, I was using a little tool called blosxom to manage the blog. It was a tiny little Perl script that pulled the contents of your blog from text files on your filesystem. Pretty awesome, nerdy stuff. Dented Reality also looked something like this, pretty hot huh?



I Want to Love My Pebble

It’s true, I really want to love the Pebble that I got from being a Kickstarter backer. I want to, but right now I can’t. I can only like it. And I can like it a lot — there’s a lot to like!

  • I have a computer on my arm!
  • I can read text messages without taking my phone out
  • I can control music that’s playing on my phone
  • WordPress notifications on my wrist? Yep.
  • Calendar alerts? Got ’em.
  • The form-factor is slick: it’s slim, super lightweight and IMHO, looks pretty darned cool.
  • Nice backlight, which I can activate by shaking my wrist or tapping the watch
  • It’s waterproof! (although I’m too nervous to actively put that to the test)

So why can’t I love it? Let me count the ways (biggest reasons first): (more…)

Import DokuWiki pages into WordPress

I used to maintain a wiki full of personal ideas using DokuWiki, but at some point just gave up with wiki syntax entirely. A few months ago when I was moving all of my sites and content over to a new server and trying to consolidate things as much as possible, I decided to import all of that old content into a WordPress install (which was actually a single site within the same Multi-site install that runs Dented Reality). I ended up writing the following super-rough script to just scrape the contents of the pages and throw them into WordPress. Scraping the pages meant that I could get the actual output of all plugins etc, and also get full links between pages.