WordPress 3 Plugin Development Essentials

In my continuing quest to pick up some useful WordPress skills, I just finished reading WordPress 3 Plugin Development Essentials by Brian Bondari & Everett Griffiths.

This book covers all the basics you’d need to develop a plugin, from setting up a local dev environment, to pushing code to the WordPress.org plugin directory.

This is definitely an overview book, covering a bunch of stuff without trying to be exhaustive about any particular thing. There is some coverage of necessary PHP and JavaScript topics, though this wouldn’t be a good book for someone with absolutely no background in PHP or JavaScript. The coverage of the WordPress API in general is sufficient to cover the basics, and to point you in the right direction on the topics that it doesn’t cover.

The book was published in 2011, and is somewhat out of date. For example, there’s a whole chapter on using Subversion, which is still useful in some circumstances, but I think most people would be using git for their day-to-day work at this point. And the first example plugin is built around Digg’s API, from the previous version of Digg (before it was re-launched in 2012), so it doesn’t work anymore. (It’s still a useful example to read through, but you wouldn’t be able to make it work.) I’m not entirely sure, but I’m pretty sure that all the core WordPress stuff that’s covered is still recent enough to be useful.

The heart of the book walks through a number of sample plugins, devoting a chapter to each. The author builds each plugin up a little at a time, explaining what he’s doing, before going on to the next part. In general, he builds things up in such a way that the plugin is functional at each stage, so you can run and debug your code as you go. This is a good approach, especially for less experienced developers.

For my own purposes, I didn’t bother actually working through the examples, as I found the explanations clear enough, and I know enough about web development that I didn’t feel like I needed to. And I skimmed over a lot of the material that was either out of date (e.g. the Subversion stuff) or that I already know (e.g. PHP and JavaScript basics).

If there were an updated version of this book available, I’d recommend it to anyone looking to get started with WordPress plugin development. As it stands, though, I’d really only recommend it if you don’t mind skipping over the stuff that’s out of date. If you can get the ebook version when Packt is having a sale, it’s worth picking up.

Not at Comic-Con

I didn’t manage to get to San Diego this year. I tried, but just didn’t manage to win the “ticket lottery.” I’m holding out hope for next year! As usual, though, I’m following the news on Twitter, The Beat, and other sources.

I haven’t seen any really amazing news yet, but it’s only Thursday. And there have been a few interesting things, such as Comixology announcing DRM-free backups, which is quite nice (though it doesn’t cover Marvel or DC books, predictably).

Code Complete

Jon Bentley describes a case in which a thousand-line program spent 80 percent of its time in a five-line square-root routine. By tripling the speed of the square-root routine he doubled the speed of the program.
Bentley also reports the case of a team that discovered that half an operating system’s time was spent in a small loop. They rewrote the loop in microcode and made the loop 10 times faster, but it didn’t change the system’s performance — they had rewritten the system’s idle loop.

via Code Complete, First Edition.

The Ten Doctors

I just finished reading The Ten Doctors. I started reading this on the advice of a friend who is a huge, long-time, Doctor Who fan. There are many references in this comic that I don’t get, since my knowledge of the Doctor prior to the Russell T Davies reboot is spotty at best. But, even if you don’t know all the characters and continuity, this is a fun story. It’s always cool to see someone with some talent and a lot of enthusiasm do something like this, purely for fun. Fan fiction like this is usually pretty bad, but this guy is a pretty talented cartoonist and a good storyteller.

Dynamics AX error-handling

I haven’t written a useful blog post about Dynamics AX in a while, so here’s something I came across this week that might be interesting. I was trying to troubleshoot a problem with a fairly complicated process that I’ve somehow wound up being in charge of. In digging through the code, I found several instance of this pattern:

try {
  ttsBegin;
  // do some stuff involving database reads and writes
  ttsCommit;
}
catch {
  ttsAbort;
}

…and that’s it. If something goes wrong, abort everything and keep quiet about it! (I guess I should call that an anti-pattern rather than a pattern.) I think this will still display any error messages to the end-user, but of course there’s no guarantee that the end-user will tell anyone.

Well, I highly suspect that things may be going wrong somewhere in one of these try blocks, given what I’m seeing in the database, so I wanted to add some logging, at least, to the catch blocks.

In AX, error messages generally get thrown into the infolog, which is a nice little mechanism for queuing up messages for the end-user to see. So, what I’d want to do in the catch block is grab any messages from the infolog and e-mail them to myself. I looked around for other code that was doing this, and found a few instances of something like this:

s = infolog.text();

…then ‘s’ would be emailed to someone, or saved off to a log file. This looked good, but I wanted to check it first, so I wrote a little test job to try it. Well, infolog.text() really only returns the first line from the log, so that’s probably not what I want. (I’m not sure if the programmer who wrote the code I was looking at only wanted the first line, or if he just didn’t realize that infolog.text() only returns one line.) So I dug a little deeper, and found that:

c = infolog.infologData();

will get the entire contents of the infolog into container ‘c’. But it also clears the infolog, so the user doesn’t see the error messages, so that’s not good.
Digging some more, I found that:

c = infolog.copy(1, infologLine());

will copy the entire infolog to a container, without clearing it, so the user can still see it. So then I tried the usual con2str() method to convert the container to a string I could email to myself. But, it turns out that it’s a structured container that can’t be converted to string that easily. So then I found info::infoCon2Str(), which parses out the infolog container structure to string, with the parts delimited by pound signs. So to break that back up into lines I can replace # with \n and off I go.

I managed to get that all into a one-liner that looks like this:

s = strReplace(info::infoCon2Str(infolog.copy(1, infologLine())), '#', '\n');

Not bad, right? Not perfect either, and you can get a more nicely formatted string out of it by writing a little utility method to parse out the container into a friendlier format. (See this blog post for an example. Look at Martin Drab’s comment below the post for a useful code snippet.)

This weekend’s comic book reading

This weekend, I’ve been reading random stuff on Comixology. Mostly stuff I got for free some time ago, and never got around to reading.

A bunch of the stuff I read would fall into the “chaff” category, but a few things might qualify as “wheat,” or were at least interesting enough for me to look into maybe reading more.

I enjoyed Multiple Warheads: Alphabet to Infinity #1, by Brandon Graham. It was a weird story, with very imaginative art. It reminded me a bit of some of Paul Pope’s work. There’s a good review of it on CBR.

I also enjoyed Elephantmen #1. I may buy more of that series on Comixology, since it’s currently on sale. When this series (and the related “Hip Flask”) first came out, I avoided them, thinking that they were probably just a gimmick, and not really something that would have any substance. This issue, though, was actually quite engaging. It introduces the (somewhat monstrous) main character and his world and history via the trope of having him engage in a conversation with an innocent little girl. (I’m calling this a trope, since I’m pretty sure I’ve seen it used before, but I can’t remember specifically where.) It’s done effectively, with nice art and good storytelling.

I also read a number of the free Marvel #1s that they gave away as part of a promotion some time ago. Today, I read through a bunch of Ultimate Universe stuff. Some of it was pretty good, and some of it I’d read before, in TPB format. Nothing in particular stood out enough for me to want to buy any back issues or new TPBs though. The last thing I read was the first issue of Ultimatum. I was curious about it, as it was a really big event, basically doing a “reset” on the Ultimate Universe, if I understand correctly. The first issue was interesting, with some really nice art from David Finch, but when I sought out reviews of the series, I decided that I definitely didn’t want to buy the rest of it. The reviews were almost universally bad, with Comics Alliance putting it in the “Worst of the Worst” category, and a couple of bloggers (here and here) writing interesting but not exactly positive reviews. So, in a nutshell, it really doesn’t sound like the kind of thing I’d enjoy.

In general, lately, when I dip my toes into any recent Marvel or DC stuff, I’m usually not finding it to be terribly interesting. I’ve stumbled on some good independent stuff though, like the Brandon Graham and Elephantmen stuff.

[Edit: When I was trying to remember an example of the “monster and innocent little girl” trope, clearly I was thinking about Frankenstein. Or maybe Young Frankenstein. Though in this case, the girl doesn’t get thrown in a pond. Or launched through a window.]

Thomas Piketty’s Capital

I keep stumbling across references to Thomas Piketty’s book Capital in the Twenty-First Century. It’s been mentioned recently in The Economist, been the subject of a relatively long review by Cory Doctorow on Boing Boing, and it’s also been reviewed, in some depth, on Philip Greenspun’s Weblog.

The idea of actually reading the book is somewhat daunting. I don’t tend to get too far into books like this before giving up and going back to Star Trek novels or X-Men comics. And I have a stack of programming books I want to read too. I think maybe I should stick with the programming books for now. Meanwhile, for a lazy summer Sunday afternoon, I think I’m going to dive into some comics and forget all about this serious stuff!

CFL and LED bulbs

Like most people in the US, I’ve transitioned nearly all of the lighting in my apartment from incandescent to CFL over the last few years. I’ve never been really happy with the CFL bulbs though. The ceiling fixtures in my living room, dining room, and bedroom are all on dimmer switches, and of course the CFLs don’t dim. And, while I haven’t really tracked this, I’m pretty sure I’m not getting as much life out of these bulbs as they advertise. Here’s an article that seems to back up that observation. And here’s one from IEEE with some interesting data.

Last week, the fixture in my bedroom started buzzing. (There’s always a little buzzing with CFLs, but this was noticeable and distracting.) So last night, I messed around with it a bit, trying different bulbs, checking to see if everything was screwed in right, and there weren’t any loose wires or anything. No luck. I couldn’t get rid of the buzzing. I thought about calling the landlord on Monday, and having them look at the fixture and/or switch, but I haven’t really had much luck with the landlord fixing stuff that isn’t completely broken. They tend to just make things worse. (I could probably write a few funny blog posts about my landlord’s maintenance guys, but I’ll resist the temptation for now.)

So instead, I decided to go out to Home Depot today and buy a couple of LED bulbs. I picked up two Cree bulbs for $10 each. That’s pretty expensive for a light bulb, but if they really last for ten years, then I don’t mind the price. There’s a good bit of stuff on Treehugger about LED bulbs. I haven’t read it all, but in general, it sounds like the current generation of LEDs should be at least a little better than CFLs, and the next generation of LED bulbs could be a lot better.

The ones I bought did indeed solve the buzzing problem. They work fine, and don’t buzz at all when on full. And they do work with the dimmer, unlike the CFLs, though they buzz a little when dimmed.

I’m writing this post partly as a marker, so if the LED bulbs in my bedroom die, then I can refer back to this post to see when I bought them. If the marketing claims on the box hold up, then I shouldn’t have to change them until 2024. By which time, hopefully, I won’t still be in this apartment!