WordCamp NYC

I’m Attending WordCamp NYC – August 2-3, 2014
I’m planning on going to WordCamp NYC this weekend, barring any unforeseen circumstances. I’m looking forward to it, since I haven’t been to anything like this since Drupal Camp in 2012. The schedule looks pretty interesting; I should be able to learn some stuff.

WordCamp won’t really make up for missing San Diego this year, but hey, it should be fun!

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.)