Malcolm events

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much of the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by Malcolm events [, seemingly insignificant events that are intent on screwing you in an unlikely way.]

Michael Lopp — Managing Humans

A stranger in a strange land

When the iPhone first was announced, I remember debating with Jerome, my coworker at Grist, whether it would support third party apps or not. “If it doesn’t support Skype,” I told Jerome, “there’s no way I’m spending $600 on one.”

The day the iPhone was available, I went to the Apple Store in University Village just to hold one. No commitment. And I went out the door with an iPhone anyway.

I’m writing this post from the WordPress for Android app (which really should be named the / Jetpack upsell app). Two years ago, I tried to make the switch but I just wasn’t ready. Now, I’m mulling making a more gradual switch, having purchased one of the last latest Nexus(i?) for this testing purposes.

As a stranger in a strange land, here’s what I’m running into, in no particular order:

+ Other than the fact I have no idea how to create an unordered list, the WordPress for Android editor is quite nice.
+ I feel like I’m relearning how to computer with the Android keyboard. Selecting text also feels like it takes three attempts per.
+ With Ad Block Pro on desktop and Tweetbot on iOS, I almost forgot Twitter had ads. Twitter Android client: ew.
+ TouchID is conspicuously absent. As is iMessage support and Things. I guess you basically need iOS and Android apps if you want to exist.
+ It’s mindboggling how Slack has managed to produce a consistent, solid user experience across multiple platforms. Lesson for the rest of us.

Ok, battery just about dead. Back to iOS.

I always love a good curse word

The simple fact is that well-defined roles in software development are fading. User-interface guys are doing what can only be called development in JavaScript and CSS. Developers are learning more about interaction design. Everybody is talking to everybody else and they’re learning from each other’s mistakes, stealing each other’s code, and there is no reason that a manager shouldn’t be participating in this massive global cross-pollination information cluster-fuck.

Michael Lopp — Managing Humans

Move fast and don’t break things

Move fast and don’t break things. Toy wrote about our TDD practices at Fusion. Notably, I’m looking forward to us taking frontend testing even further. Using QueryPath to validate frontend markup has the great side effect of firing many of the hooks in a typical request — and triggering errors before they happen in production.

Thoughts on using WP-API for WordPress-based apps

This past week, I got to do my first client project using WP-API. The scope of the project is to create custom endpoints for a WordPress-based web application. The endpoints will eventually be used to power iOS and Android apps.

I thought I’d use the opportunity to gauge usability of using it in a project. My feedback is from the perspective of a developer needing to create custom endpoints for WordPress — I haven’t written any client-facing code yet.

These notes are roughly edited. Mostly I just want to get them up before WCSF.

What I like

WP-API has a comfortable implementation of using WP_Error for returning error responses in my endpoint callbacks. Being able to specify the HTTP status code is a great touch.

Extending WP-API’s core classes is really nice for DRY. They should be designed to be extended — I’d suggest they’ll be more commonly extended than used standalone.

For instance, I was able to get a lot of mileage out of extending WP_JSON_CustomPostType and customizing the response values for prepare_post(). However, I basically reset the original array (because the project has different data models), so it would be cool if there was some reusability there.

Also, I was able to easily add an authentication check for get_posts(). But, I wasn’t able bypass delete_post()’s capability check, so I needed to create my own.

Context argument is proving to be easily reusable. I invented my own context that seemed to fit in the paradigm.

Route registry is pretty much copy and paste == it works. I love the style of route definition too: /(?P<id>d+)

What can be improved

Using bitmask operators to map HTTP methods to callback isn’t terribly intuitive, although it’s easy enough to get going by copy and paste. I’ve never liked that part of the Rewrite API, and don’t think we should repeat it.

It would be nice to be able to modify the “data” field associated with a WP_Error entry. I’ve set up my models to return WP_Errors, but then I need to recreate that error in my controller to include the status code.

Because we have a variety of content models that are often mixed and mashed (e.g. a Post displayed with Author, Terms, and “Featured Image” Attachment), we should do embedded media really well. I think this is lacking in WP-API right now — you basically need to reinvent the wheel on each endpoint.

I’ve spent way too much time writing code to define and validate supplied arguments. I know this is something I like and Ryan hates, but it would be cool if we could nail field definition and validation for endpoints. This is something we did with H-API. It seems like we’re part of the way there by using Reflection for argument definition in our endpoint callbacks. Easy type validation is just the next step — maybe it could be introduced as an optional library.

On that note too, using Reflection against the defined method arguments to decide which request arguments are passed is too magical. It’s new to PHP and will be completely baffling to Joe Shmo WordPress developer.