Nothing But Words

• Arrived in DC yesterday – looking forward to meeting up with @hakjoon and @jjmedusa today #
• A picture of the boys outside the Smithsonian today. They enjoyed the Natural History and Air & Space Museums http://t.co/j6gHKVAX #
• Argh! Shashin was just removed from the http://t.co/Gi0D4ZfY repository, because of a license conflict with the included Highslide viewer. #
• Until I can resolve the problem with http://t.co/Gi0D4ZfY, you can still download Shashin from GitHub https://t.co/IqJJZAHR #
• @zamoose It uses a creative commons license. I've had it in the repo with Shashin for 5 years. I forgot all about the license difference. in reply to zamoose #
• Fish Story: a movie about how punk rock saves the world, literally. A true joy to watch. On Netflix streaming. Review: http://t.co/QFPZGlxz #
• I thought @ericandrewlewis was cryptically teasing me, but we both just happened to tweet about fish related movies at almost the same time #
• @jason_coleman good article, but it's ironic that the author's site has 2 ad overlays and a really annoying vibrating ad at the top in reply to jason_coleman #

It’s time for a new plugin support post – please use the comments section for any questions about my plugins.

Also, to my surprise, Shashin was removed from the wordpress.org plugin repository yesterday. The reason is a perfectly good one – Shashin comes with Highslide, which has a license that is not compatible with the GPL, and all code in the wordpress.org plugin repository must be GPL compatible. I’ve packaged Highslide with Shashin for 4 years, and this issue had simply not crossed my mind.

I will replace Highslide with Fancybox, which is GPL compatible, and then I can make Shashin available again at wordpress.org. I would like to continue supporting Highslide, as neither Fancybox nor most other viewers have the same range of features. But since I can no longer include Highslide with Shashin at wordpress.org, I need to determine if there is an alternate solution that will not cause concern for the wordpress.org folks, and will not make life complicated for Shashin users.

My next week or so is very busy but I will work on transitioning to Fancybox as quickly as I can. In the meantime, Shashin is still available at GitHub. Make sure to read the appropriately named README_GITHUB_IMPORTANT file that contains specific installation instructions when downloading from GitHub.

Update: by request I now have Shashin available for download here as a zip file, with no special steps needed for installation (except that you still need to have Toppa Plugin Libraries installed first). Download Shashin 3.0.9.

Update II: The GitHub version no longer works with Highslide – I’m phasing in Fancybox. Use the link above for Shashin 3.0.9, which is the current stable release (with Highslide).

Update III: I’ve submitted a revised version of Shashin for review to wordpress.org. I have therefore removed the old version of Shashin from my site, as it does not meet wordpress.org’s license requirements.

• My bio page is now on the WebDevStudios site. I'm lucky to be of such a great team! http://t.co/wNYTTpR4 #fb #
• @jason_coleman I actually painted my first web page on a cave wall, with bison blood in reply to jason_coleman #
• Wow, WordCamp San Diego sold out 11 hrs and 55 min after tickets went on sale http://t.co/xytdIGbs #wcsd #
• Maria is quoted in the CSM's article today about Chinese president-in-waiting Xi Jinping's visit to California http://t.co/oPZ3ZzSo #fb #
• I very nice tribute to Carl Sagan RT @zenpencils: New Zen Pencils comic by Carl Sagan http://t.co/E5Q9zL6u #

In my new position at WebDevStudios, I’m wading deep into the world of WordPress multi-site functionality. In version 1.2 of Toppa Plugin Libraries, there’s a new method which makes it easy for plugin authors to make their plugins WordPress multi-site compatible. It is based on the excellent code Shibashake made available for doing this. I took that articles’s 3 separate (but almost identical) functions for activating, deactivating, and uninstalling a plugin, and abstracted them into a single method. Why? Because “duplicate code is the root of all evil in software design.”

As a plugin author, all you need to do is write your activation or deactivation function as you normally would, and then:

$functionsFacade = new ToppaFunctionsFacadeWp();
$functionsFacade->callFunctionForNetworkSites('yourActivationFunction');

This will call your activation (or deactivation) function for every site in the network, including the parent site.

Or in an object context, after passing the FunctionsFacade to your object:

$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourActivationMethod'));

For uninstalling, you need to pass a 2nd argument, which indicates that the “networkwide” flag should not be checked (for some reason, WordPress multisite uses this flag for activating and deactivating plugins, but not for uninstalling).

$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourUninstallMethod'), false);

I’m going to release the next version of Shashin soon, which uses this method to make it multi-site compatible, so I wanted to get this Toppa Plugin Libaries release out first. Enjoy!

• Looks like there is a "Mr. Toppa Toppa" who is a reggae producer – Toppas are everywhere http://t.co/H4yzmK9r #fb #

In the last episode of WP Late Night, there was a brief debate about plugin size. Ryan expressed a preference for smaller plugins with tightly focused functionality. It’s natural to worry that, as the number of lines of code increases, so does the likelihood of bugs, and performance slowdowns.

This concern makes sense if you’re assuming plugin code is not very well organized and not very well tested. Unfortunately, that’s a safe assumption with many plugins. As plugin authors, we should have higher standards for our work. There are two things that come to mind:

1. Optimizing the readability and maintainability of our code. This means writing “clean code” (the subject of my Philly WordCamp presentation). It reduces the likelihood of bugs, and makes our plugins easier to enhance and adapt to changing needs. It also makes it more likely that others will contribute to the project, or learn from it, and start writing better plugins themselves. These are some one of the main attractions for participating in the WordPress open source community, right?
2. Optimizing for performance: one aspect of the “clean code” philosophy is to not prematurely optimize code for performance, especially when our guesses about how to do that are often wrong.
   

   More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

   Wulf, W. A. “A Case Against the GOTO,” Proceedings of the 25th National ACM Conference, August 1972, pp. 791-97.

The rule of thumb is to optimize for readability and maintainability first. If a performance problem comes up, it is likely stemming from a small area of the code, and you can focus your performance optimization efforts there. As one person put it: “There is far, far more money wasted on fixing and customizing and maintaining hard-to-read code than there is lost on inefficient code.”

There are many techniques involved with writing clean code. A foundational one is following the Single Responsibility Principle (SRP). Bob Martin has a very succinct definition of the SRP: “a class should have only one reason to change.” In his book Agile Software Development, he explains further:

If a class has more than one responsibility [more than one reason to change], then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the ability of the class to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

If you follow the SRP, then it doesn’t matter how big your plugin is. What matters is how you use it.

The trick, of course, is figuring out what it means to have a single responsibility. WordPress itself helps you figure this out. When you call a WordPress hook or filter, it’s likely that you will want to create a class that implements what you intend to do for that hook or filter call. For example, if you call add_shortcode, then you should have it instantiate a class that implements your shortcode. If that class needs to change, it will be only because your needs for the shortcode have changed. The shortcode logic is not tightly coupled to other parts of the code. Removing that coupling is an important step towards also removing that sinking feeling of fear when you start monkeying with the innards of some gigantic application.

Not every hook and filter call deserves its own class. Some are merely stepping stones to others and do not need their own class. For example, if you call admin_menu simply for the sake of calling add_options_page, one class is enough. Others may need more than one class to support them. But for getting your feet wet, having a class per hook or filter is a good place to start.

My Shashin plugin has a total of 55 classes and subclasses (you can see the code on GitHub). How can you find what you’re looking for in all those classes? It sounds horribly bloated for a WordPress plugin, right? It’s actually the opposite.

A coding habit that goes hand in hand with the SRP is the use of meaningful names. Each class in Shashin serves a specific purpose, and has a name that tells me what it does. If I need to make a change to the settings, I go to the Settings class; if I need to make a change to how album synchronizing is done with Picasa, I go to the PicasaSynchronizer class, etc. The majority of the classes are less than a couple hundred lines. With small, well-named classes and methods with clear purposes, when there is a bug, it’s usually not hard to find. And if I need to change something, I can make that change in one place with a greatly reduced fear of breaking something unrelated.

By using a class autoloader, such as mine, you can also save yourself the trouble of figuring out where to put require_once statements, for loading your class files. With an autoloader, a class file is loaded only when “new” is called (so if you are worrying about performance with so many objects, they are only loaded when they are actually needed). How you keep track of object dependencies, and when and how you instantiate your classes, are what I’ll write about in my next post, which will cover using an injection container.

• Finally got the NoMeansNo Tour EP 2. This song is a little masterpiece – song: http://t.co/rSWsnVNZ – lyrics: http://t.co/GtwwLueW #fb #
• Great interview – Luke covers a lot of usability topics – RT @lukew: Thinking about mobile? I think this will help: http://t.co/gTfLCkO8 #
• Writing code fast and messy will ultimately slow your project to a crawl. This cartoon explains it perfectly http://t.co/h3TuSbqV #
• RT @Jtsternberg: http://t.co/9Fzk2aKu – amazing letter from a former slave, replying to his former master's request to come back #fb #
• Wow, I didn't know the Muppets did press conferences – Fox News should know better than to mess with Miss Piggy http://t.co/bai8QTBb #
• I need to figure out how to work back near Penn occasionally, so I can satisfy my craving for a Hemo's chicken sandwich http://t.co/ZjtDQ6ii #
• RT @jtsternberg This video made my day! http://t.co/p3hM8Ny7 #fb – mine too #
• Just responded to another batch of Shashin support requests. I deserve a prize, or some donations (cough, cough) http://t.co/1Orx8brr #
• The boys & I have been re-watching Avatar: The Last Airbender. I mean the amazing anime series, not the awful movie http://t.co/ZQkYkpmQ #fb #
• @speno for the kids we kept it simple – some onigiri had shiso salt and others had green tea salt. For the teachers, we used saury fish in reply to speno #

Onigiri for the kids in Eidan's class View at Picasa Onigiri for the kids in Eidan's class02-Feb-2012 23:25, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.067 sec, ISO 640

For Eidan’s kindergarten class this week, our parental duty was to bring in a snack for all the kids that starts with the letter “O”. So last night Maria and I made about 30 onigiri:

Onigiri (お握り), also known as omusubi (お結び) or rice ball, is a Japanese food made from white rice formed into triangular or oval shapes and often wrapped in nori (seaweed). Traditionally, an onigiri is filled with pickled ume (umeboshi), salted salmon, katsuobushi, kombu, tarako, or any other salty or sour ingredient as a natural preservative. Because of the popularity of onigiri in Japan, most convenience stores stock their onigiri with various fillings and flavors. There are even specialized shops whose only products are onigiri for take out.

justbento.com has some wonderful pictures of the many forms onigiri can take.

We made the traditional triangle shape, and thanks to the 69th St. H-Mart’s dazzling array of nori selections (half an aisle for nori!), we were able to use the nori that comes in individial plastic sleeves. The sleeve keeps the nori dry, so we could get them to school with Eidan and not worry about them getting soggy. You then remove the plastic sleeve right before eating. Of course someone has posted a video on YouTube to illustrate. Ingenious product packaging from the Japanese – what a shocker

Final snack - onigiri and lemon water before getting on the plane back to the US View at Picasa Final snack - onigiri and lemon water before getting on the plane back to the US08-Jul-2010 20:43, SONY DSC-W55, 2.8, 6.3mm, 0.02 sec, ISO 100

When we lived in Japan in 2007, the boys and I would stop at a convenience store for onigiri almost every day. It’s a cheap, healthy, and filling snack, and the boys never got tired of it. There’s a huge variety of fillings to choose from, some of which the boys liked (such as salmon) and some which they didn’t (like umeboshi – pickled fruit). So to make sure I didn’t buy the wrong thing, I learned to go to the stores that labelled the onigiri in Hiragana, which I could read, and to avoid the stores that used Kanji, which I couldn’t read.