Shashin 3 Beta is Here
I just uploaded the beta release of Shashin 3 to GitHub. All the features are done, so this is the version I will upload to wordpress.org after all you nice people help me test it (what would be especially helpful is if someone tried it on a Windows server, which I do not have). If you find bugs, please submit issue tickets on GitHub, or leave a comment here.
I am working on a major re-write of my Post to Post Links II error: No post found with slug "shashin-wordpress-plugin", so that it documents how to use Shashin 3, as there are several major differences from Shashin 2. I intend to finish this weekend.
A key thing to note for those who’ve been using the alpha version is that it will now upgrade and replace an existing Shashin 2 installation (you can no longer run Shashin 2 and Shashin 3 side-by-side). It will update your Shashin 2 database and there’s an option now on the Shashin Settings menu to turn on support for the old shortcode format.
If you are upgrading from Shashin 2, please follow these upgrade instructions:
- Deactivate and delete your Shashin 3 Alpha installation if you have one
- Deactivate your Shashin 2 installation
- Backup and remove the “shashin” folder from your plugin directory
- Download Shashin 3 from GitHub, and rename its folder to “shashin”
- Upload it to your plugin folder
- Click “Plugins” in the WordPress admin sidebar, to reload the main plugin panel (this is important, so that WordPress will be aware of the underlying code change before activating)
- Activate Shashin. This will trigger the creation of backup copies of your existing Shashin 2 database tables, and then a series of transformations on the live tables to make them Shashin 3 compatible.
- You’ll see an upgrade nag message telling you to go to the Shashin Tools menu to complete the upgrade – follow the instructions you see there
WordPress Plugin Updates
I’ve committed updates to the following WordPress plugins:
- Shashin 3 (dev): added support for image viewers other than Highslide. See the Post to Post Links II error: No post found with slug "shashin-3-development-progress" for more details. Currently available at GitHub (I’m not going to replace Shashin 2 at the wordpress.org plugin repository until Shashin 3 is done).
- Post to Post Links II error: No post found with slug "deko-boko-wordpress-plugin": fixed the language translation configuration and updated the .pot file
- Post to Post Links II error: No post found with slug "toppa-plugin-libraries-for-wordpress": added language translation support, improved the form building widgets (especially for checkboxes), and added a bunch of functions to the WordPress facade (see the readme file).
- Post to Post Links II error: No post found with slug "simpletest-for-wordpress": also added language translation support.
- All of the above: handling of any plugin activation errors is now much more user friendly.
My other two plugins – Post to Post Links II error: No post found with slug "post-to-post-links-wordpress-plugin" and Post to Post Links II error: No post found with slug "koumpounophobia-wordpress-plugin" – are on the back-burner for now. For now I’m focused on getting Shashin 3 done. I have plans for these 2 plugins as well. It’s all just a matter of finding enough time…
Shashin 3 Progress Update
Last week I finished the last complex task remaining for Shashin 3, which is using jQuery so you can page through large album photos sets without the whole page having to refresh. Click the thumbnail on your right for my Seattle trip photos to give it a try.
Tonight I pushed an update to GitHub which makes the settings page fully functional. Note you need to update Toppa-Libs as well. Keep in mind not all the features related to the settings are implemented yet (specifically, automated album syncing and support for viewers other than Highslide).
At this point, you can put Shashin 3 into use on your site, as long as you don’t need backwards compatibility with Shashin 2, and you don’t need the features still on the to-do list. Shashin 2 backwards compatibility and the other features are coming!
I am speaking at WordCampPhilly on Nov 5th, to talk about the Agile coding practices I’ve applied to Shashin 3, so my goal is to be done before then.
The New Chatham Chat Web Site
I’ve been working with the new managers of the Chatham Park Home and School Association to re-launch their website (Kai goes to school at Chatham). We just finished – check out the Chatham Chat:
I did the back-end work on the site (for managing the email newsletter subscriptions, converting from the old site, etc), but not the design. It’s using WordPress (of course!), my Post to Post Links II error: No post found with slug "deko-boko-wordpress-plugin" for the contact form, a modified version of the Classroom Blog theme, and I did some customizations to the Subscribe2 plugin for emailing the Association’s newsletters.
Dependency Injection in PHP
Last week I gave a presentation to my team on dependency inversion and dependency injection in PHP. Dependency inversion is the “D” in the the SOLID object oriented design principles, and dependency injection is a design pattern for implementing it.
We previously learned the single responsibility principle (PDF) (the “S” in SOLID). To me, dependency inversion is the next logical topic. Single responsibility is about how to write objects that do one thing; dependency inversion is about how you wire those objects together into robust, working software.
This was a fun presentation, and I think the slides work well even without my narration. Several of the code examples are from Post to Post Links II error: No post found with slug "shashin-3-development-progress", where I’m applying the principles. I’m still learning how to best apply them, so feedback in the comments section is welcome.
Why Do Planes Crash?
A couple weeks ago I gave a presentation to my team, based on Malcolm Gladwell’s Outliers: The Story of Success
Gladwell’s examples from black box recordings are astonishing. In many cases everyone in the cockpit except the captain knew the plane was in serious trouble, but even then wouldn’t speak up forcefully (typically the captains were good pilots, but were exhausted and weren’t picking up the hints from their crews). They’re powerful examples of the importance of being assertive, and just how hesitant most of us are even when it’s obviously vital to speak up. And my presentation was, I hope, more entertaining then some stereotypical HR assertiveness training class.
The last couple slides show similar examples from The Clean Coder: A Code of Conduct for Professional Programmers
Here are my slides (posted on SlideShare.net)
Shashin 3 Progress and Examples
I’ve created Post to Post Links II error: No post found with slug "shashin-3-development-progress". It lists features which are completed, and those that are on the to-do list. It also documents the new shortcode syntax and has working examples.
I just uploaded revisions to GitHub. If you are working with a version that’s more than a few days old, you will need to delete your previous installation and reinstall, in order to get the database changes (hey, it’s still an alpha version!).
Please make sure to follow the instructions in the README file when installing, and report any problems with Shashin 3 using the GitHub issue tracker.
Agile Programming for WordPress Plugins: The Joy of Output Buffering
A standard practice of Agile programming, and good programming in general, is to separate your display code from your application logic. Bob Martin:
Today’s modern programming environments make it possible to put many different languages into a single source file. For example, a Java source file might contain snippets of XML, HTML, YAML, JavaDoc, English, JavaScript, and so on… This is confusing at best and carelessly sloppy at worst.
The ideal is for a source file to contain one, and only one, language. Realistically, we will probably have to use more than one. But we should take pains to minimize both the number and extent of extra languages in our source files.
Separating display code is central to the MVC pattern, which underlies almost all PHP frameworks (and frameworks in many other languages as well). WordPress is a blogging platform and arguably a CMS, but for plugin authors, it does not provide the typical tools of a development framework. If you want to separate out your display layer, you’re on your own.
As a result, very few plugin developers do. A common style for WordPress plugins is a single file, sometime running thousands of lines, that consists of cryptically named functions (often in no discernible order), which have the display code scattered around within the core application logic. This style might be acceptable for something small and simple. But once the functionality becomes complex, this style makes the code very difficult to understand for anyone other than the author (and the author is likely to find it hard to understand six months after finishing work on it). It also makes extending the functionality difficult. For example, adding support for a mobile UI would entail a major rewrite.
For a WordPress plugin, you can use output buffering to solve this problem. You can see an example in my ShashinMenuDisplayerAlbum class. The run() method triggers the display of the menu, and its HTML is in a separate file:
ob_start(); // start the output buffer require_once($this->relativePathToTemplate); // get the HTML template $toolsMenu = ob_get_contents(); // store it in a variable ob_end_clean(); // empty the buffer and turn it off
Normally a require_once call would include the file, evaluate any PHP code, and immediately output the HTML. Including the file with output buffering turned on allows you to instead store all the output in a variable. You can then control when it is displayed. With this approach you do not have to write all your HTML inline with your application logic.
The template file being included in my example does have PHP as well as HTML in it, so I am not meeting the ideal of complete separation. But as Bob Martin points out, such total separation isn’t always possible. In this case, the PHP code used in the template is the minimum necessary for the purpose of rendering the page (for example, it contains a foreach loop to display rows of data in a table).
Thoughts on @RonJeffries “But We Need a Database… Don’t We?”
Ron Jeffries wrote a post a couple days ago with a title indicating its about databases, but then he proceeds into a test-driven development (TDD) coding exercise. Halfway through, an ostensible reader interrupts:
Hey! I thought this was supposed to be about databases???
Hey, yourself. Try to pay closer attention. This is totally about databases.
Why is this even remotely about databases???
Well, here’s why:
We have just defined a core element of our member database record, namely the purchase count, and made sure that it works. Now when we read a member record in from our database, we can instantiate it into our class MemberRecord and send it messages to decide what to do. This is OO here, my young padawan, and that’s how we do it.
Yeah, sure, old man, but what about the membership number? That’s the key, according to the story, and you don’t even have it. And isn’t there just a small matter of actually storing and retrieving these babies?
Patience, youngling. Each thing comes in its time. Let’s see what the next tests bring us.
His post is a good illustration of the revelation I had when first learning Agile coding practices: they let you start in the middle, with the business logic. A common traditional approach is to instead define a database schema first, and then deal with the UI and business logic. There are 2 problems with this traditional approach 1. the database is the hardest layer to change, and your design is likely most volatile in its early stages, and 2. it makes it that much easier to end up tightly coupling the components of your application together.
By starting with the business logic and no supporting infrastructure other than your tests, you have no choice but to fully decouple the application logic from the UI and the database. Then when your boss says, “we need to make a mobile version of this app by Friday!” you can work on the new mobile UI design without having to cut through a tangled thicket of blended UI and business logic.
Having said that, there are challenges with mimicking complex interactions with the database and UI layers through unit tests. I consider myself a novice with Agile techniques, but I’ll share what I’ve learned so far:
- For my Shashin project, which pulls data from Picasa json feeds, I simply saved copies of some feeds to local files, and my tests can talk to those files. This allowed me to keep developing while offline (on a flight to Hawaii!) which is very cool.
- There are the object mother and test data builder patterns but both can entail a fairly heavy degree of typing when dealing with large or complex data sets.
- My team at Penn is currently trying out FitNesse, which lets you specify your inputs and expected outputs through simple wiki tables (which you can paste from a spreadsheet). This seems about as lightweight as you can get. Although it’s an acceptance testing tool (not a unit testing tool), it can still help drive your design. If you follow specification by example practices, and write your code so that it can take inputs and send outputs to a FitNesse test fixture OR a database and a form, then congratulations, you’ve decoupled your code from the database and UI!
Deko Boko 1.3 Now Available
Update 6/26: Please download version 1.3.1, as it contains an important bug fix. Also, for GitHub fans, I now also have Deko Boko on GitHub.
It’s been almost two years since I last updated my Deko Boko contact form plugin. The new version is now available at wordpress.org. It started as a fix to a minor bug that was recently reported, and grew into a significant overhaul. This version updates the reCAPTCHA library code, as the reCAPTCHA project is now managed through Google. It includes several other minor enhancements and bug fixes (see the change log if you’re really curious). Note you will need to install Toppa Plugin Libraries for WordPress to use it.
This is the first round of refactoring Deko Boko. It has exactly one unit test now! Hey, it’s a start. I’ll turn my attention back to finishing work on Shashin before I do more with it (Deko Boko is much less complex than Shashin, so updating it was not nearly as involved).