Month: May 2013

Slides and reflections from my presentation on WordPress Developer Tools

On Tuesday I gave a remote virtual presentation titled “WordPress Developer Tools” to the Room to Think coworking community in Richland, Washington. My slides are posted here.

The slides are built with the web-native Reveal.js, and the source is here on Github. I am so in love with Reveal.js. So long, Keynote! Thanks to Flynn O’Connor for turning me on to this at BeachPress.

This was my first experience giving a tech talk, my first WordPress talk, and my first remote talk (meaning it was delivered over a video conference with screen sharing). I gave the talk from my bedroom at the BeachPress house in Rockaway Beach, Oregon. I learned several good lessons, thanks in part to the great feedback I was given:

Giving talks virtually

  • Not compromising on internet bandwidth is important. (Duh.) It wasn’t fair to the audience that I didn’t make absolutely sure ahead of time that my up and down times were good.
  • At the beginning, establish good and bad ways to give feedback during the presentation. I wasn’t able to hear audience members far away from the microphone and also missed some messages in the Google Hangout’s group chat window because I wasn’t paying attention to it.
  • I didn’t know at one point that our connection dropped for several moments because I was looking at my slides instead of the Hangout window. I’ve seen similar issues in presentations where I’ve been in the audience before, and I’m not sure how to fix this.
  • I’m interested in giving virtual talks more often because they’re more nimble — I can give them from anywhere with (good) internet, etc. — and also better for Earth than flying all over to speak in person. I’m not saying conferences and events are bad, just that I’d like to explore and promote how virtual talks can work well to be really great experiences, to lower the tech industry’s carbon footprint a bit. On the whole, this experience seemed to support that it is possible to pull this off and do it well, if I pay more attention to the details listed above.

Giving talks on WordPress

  • My slide deck skews a bit heavy in the beginning toward explaining why it’s even a good idea to think of WordPress as a serious platform. I think I may feel a bit defensive about this, which I’ll work to get over.
  • Similarly, this should have been two separate talks. I plan to split them — one about WordPress as a framework, another about technical dev tools.

Giving tech talks

  • I thought I was exempt from the Law that Live Coding Demos Don’t Work because why?

My Talk Submission for WordCamp Portland 2013

This year’s WordCamp Portland organizers are trying some experiments this year with selecting speakers. First, they’ve asked for submissions in the form of video pitches. And, for the first time, the conference has a theme: Permanence.

I was planning to put a lot more time into this, but was strongly encouraged not to, so I knocked it out in about 20 minutes this evening after a full day of coworking at BeachPress. The video is fairly lo-fi, and straight to the point: Introducing the topic, describing its relevance to the conference’s theme of permanence, and introducing myself as the right person to give the talk.

Here’s my submission. It’s all about checklists.

Aren’t I cute? Vote for me!

Just kidding. There’s not actually a way to vote. But I’d love your feedback.

Git Submodule Cheatsheet

I’m aware git submodules aren’t awesome, but a lot of what makes them a pain is having to remember the arcane sequence of commands to invoke when using them in a collaborative team project. I’m creating this cheat sheet for my own reference. If you find it useful too, or have suggestions for improving it (or if you spot errors to correct), let me know.

Adding a submodule to a project

$ cd <repo root>
$ git submodule add <readable remote submodule repo> <relative local path to install target>

Making changes to a submodule

Here we want to first push our changes to the submodule’s upstream repo, and then record the change in the parent project repo. It’s very important to not skip the first part, as that would break the submodule for other developers when they pull changes to the parent project with an updated reference to a nonexistent state of the submodule repo.

$ cd <submodule path>
// do stuff
$ git commit ... // Changes committed to submodule; parent repo only recognizes that submodule's commit has changed
$ git push ... // Push submodule changes; parent repo unaffected
$ cd <anywhere within parent repo>
$ git commit ... // Commit updated reference to new submodule state (reference by commit)
$ git push ...
// Tell your fellow coders to be sure and update submodules when they next pull.

Cloning a repo with submodules for the first time

After cloning the repo, initialize and update your submodules. git submodule init sets up the repo structure. git submodule update populates submodule files by pulling their commits.

$ git clone ...
$ git submodule init
$ git submodule update

Pulling commits including updates to submodules

$ git pull ...
$ git submodule update

Thoughts on “Analogy is the Core of Cognition”

This is a great talk at Stanford from cognitive scientist Douglas Hofstadter. It taught me to recognize the essential analogy-nature of just about every new understanding, and the essential category-nature of (nearly?) all words and phrase structures in language.

I also found this illuminates why building satisfactory taxonomy systems in databases (like those that power CMSs like WordPress) might be so difficult: Categories in our minds are essentially analogies, with varying degrees of complexity, but which grow and morph in meaning as we gain experience and learn. The edges are inherently fuzzy, and our mental hardware is optimized to make connections between them easily. In computer systems with fixed data structures, categories must have to be fixed, with clear hard yes/no lines, and (unless you have the benefit of complicated machine learning algorithms) connections between them must be intentionally and explicitly crafted by programmers.

At first this appeared to me as a fundamental alienating difference between biological and machine minds: Fixed, binary thought, versus flexible, analog (with its delicious shares root with analogy) thought. But, I suppose our own minds are built up of their own (however elegant and complicated) logic gate hardware — is the axon firing, or not? — and perhaps machine minds will come to work much like our own when sufficiently advanced, with layers upon layers of software on top of our contemporary primitive ones.