A couple of weeks ago I posted my thoughts on creating a new packaging format for Melody plugins and its advantages:

The biggest advantage to [this new packaging format] is to allow us to use github to automate plugin and theme installation and upgrades because now one could easily do this: (snip)

What I am snipping out of the above quote are some geeky command lines which illustrate how to checkout a project from git. Such command line snippets now seem anachronistic given that the community has taken a major step in implementing this vision through a new plugin which, after a little TLC, will find its way right into Melody.

What is most exciting I think is the path and roadmap this plugin squarely puts us on. From the plugin’s README:

This plugin is part of a larger effort to completely overhaul how plugins are discovered, installed and managed in Movable Type and Melody. The roadmap for this plugin is for it to interface directly with a centralized plugin directory managed by the community. In this capacity, the need to enter a git url at all will be completely obviated. Instead, users will search for the plugin they want from within Melody, and then click “install.” The directory will know the git URL so users don’t have to.

Today begins our journey on a road leading to one of the most important milestones this community will ever reach: the first ever launch of a production ready version of Melody.

We have updated our download page with links to downloading the most recent version of Melody, and included what we think are simple instructions on how to get started. These instructions include where to download Melody, how to install it (for now we will still rely on Movable Type’s install instructions), and where to report bugs.

Since the very beginning of this project people, especially non-developers, have asked, “how do I help?” Well, good news, there is finally a way everyone can help: become a tester and join the elite group of people who will be heralded as the ones who helped make Melody possible!

I originally posted this tome of an email to the openmelody mailing list, but figured there might be more people than just developers interested in what we have been working on and thinking about. Here we go…

~~~~

Things have appeared a little sleepy recently. I apologize for that. I have been working on some big stuff for Melody that I wanted to share.

1) Theme Manager - Endevver (disclaimer: I am a principal at Endevver) commissioned Dan Wolfgang to build for Melody a new Theme Management interface. We are working on the finishing details now and so far we really like what we see. At a high level this is an implementation of how TypePad manages templates in that it allows for two modes of operation:

a. Linked to Theme - in this mode, users are not allowed to edit templates. The look and feel of a site is derived exclusively from the theme source code. As changes are made to the theme, the site's templates are updated simultaneously.

b. Unlinked to Theme - the classic MT mode where the user is allowed and invited to edit their templates. In this mode as updates are made to the theme, they are not applied automatically to the theme. You must reapply the theme to see the updates, but at the risk of losing any changes you have made.

Theme Manager also comes with a theme dashboard showing a preview of your site, and other options to customize the look and feel of your site. Again, a lot of inspiration was drawn from TypePad which we think offers a great model for this.

We also allow designers to embed their PayPal email address to more easily prompt users of their themes to donate to the cause.

1. Static File Deployment - This is a biggee for end users. When implementing Theme Manager we wanted to look at the entire life cycle of theme management from installation to management. There Dan also implemented a framework by which themes can package their static files for MT to install for the end user automatically. We can’t underscore how big this will be. So big that I think we should revisit the plugin packaging standard for Melody.

NEW PROPOSED PLUGIN PACKAGING STANDARD

Right now plugins are encouraged to package themselves like so:

PluginName-1.0/plugins/PluginName/...
PluginName-1.0/mt-static/plugins/PluginName/...

This is straight forward, but one of the things that this structure makes difficult is to have a plugin be pulled directly from source control because the plugin is fragmented into two distinct groups of files. With the enhancements Dan made to Config Assistant (already core to Melody) static files would be packaged as follows:

$MT_HOME/plugins/PluginName/config.yaml
$MT_HOME/plugins/PluginName/static/*

Upon installation of the theme, MT would automatically copy files found in static/ to:

$MT_HOME/mt-static/support/plugins/PluginName/

And it would give you a template tag <$mt:PluginStaticWebPath plugin="PluginName"$> for you to access the web accessible endpoint where your files were installed - wherever that might be.

This would allow plugins packages like so:

PluginName-1.0/plugins/PluginName/config.yaml
PluginName-1.0/plugins/PluginName/lib/...
PluginName-1.0/mt-static/plugins/PluginName/...
PluginName-1.0/mt-static/plugins/PluginName/images/logo.png

To be packaged like so:

PluginName/config.yaml
PluginName/lib/...
PluginName/static/images/logo.png
PluginName/static/...

Again - the biggest advantage to this is to allow us to use github to automate plugin and theme installation and upgrades because now one could easily do this:

prompt> cd $MT_HOME/plugins/
prompt> git clone http://github.com/byrnereese/mt-plugin-assetgallery

Something that is impossible today due to limitation in git. For example, git does not allow me to clone or fetch a sub-directory within a repos. I can only pull down the repos in its entirety.

Anyway - enough typing. What do people think?

~~~~~

As a post-script to this would-be email, I will also add the following. One of the things I think would be wise is to begin requiring config.yaml files (of course I am not the first person to state definitively that this would be a good, no great idea). Once this file is required then we can defer to the config.yaml to define all the meta data one would need to not only run the plugin, but to also have it hosted in a self-maintaining plugin directory.

To this end, we turn to our brother blogging system WordPress for inspiration for something it has done an amazing job with: building out a rich ecosystem for supporting plugin developers. At the heart of this ecosystem is a plugin directory, and what it does uniquely well is maintaining itself. Movable Type’s plugin directory requires plugin authors to go back to the directory to update if they make any changes. WordPress’ on the other hand, is integrated seamlessly with a source code control system. To register a plugin, you just checkin your plugin’s files to a svn repos they provision for you. Then whenever you update your plugin, the directory is updated automatically for you. By integrating the directory with the developer’s workflow, they ensure that their directory is always up-to-date and minimize the overhead anyone has to spend maintaining it.

I would like to do the exact same thing for Melody.

Ok, now really I have done enough blabbering. Time to sign off the email-turn-blog-post.

As you may or may not know, Melody uses git and we love it. We use it so much, we thought we should share a bash recipe with you that helps us work more efficiently on the command line. The following recipe, when added to your .bashrc file, will allow you to use the TAB key to auto-complete any git commands, local branches and local remotes. Hit TAB twice and it will show you a list of possible matches. Very helpful.

# This command line completion script will handily autocomplete
# any git commands as well as any remotes and branches you have
# defined.
#
# Add this to your .bashrc file
complete -f -W "$(echo `git branch | sed -e s/[\ \*]//g | cut -f 1 -d ' ' | uniq`; \                                                                       
    echo `git remote | sed -e s/[\ \*]//g | cut -f 1 -d ' ' | uniq`; \                                                                                   
    echo `git | tail -23 | head -21 | cut -d ' ' -f 4`);" git

Jay Allen and Byrne Reese explain unit testing in Melody and demonstrate how to use Git to make, commit and push changes to the code from your own local repository in this live screencast recorded Wednesday, January 13th.

Part 1:

Part 2:

Not too long ago the core development team upgraded and folded into the core distribution of Melody Tatsuhiko’s PubSubHubbub plugin to make it immediately available upon download and installation. If you are like most people, you are probably asking yourself, “umm, what in the world is ‘pubsubhubbub’ and who keeps letting geeks name important internet protocols?”

Luckily I don’t have to answer these questions directly. Instead, let me refer you to the technology’s creators, Brad Fitzpatrick and Brett Slatkin, who explain very succinctly why this is cool, and admit to the obvious, “PubsubHubbub is a geeky name” (and we love you for it guys).

So why did we make this core? Easy:

• Better SEO - Pubsubhubbub is not replacing feeds, they are augmenting them and helping you to plug your site into the services that want to consume your data - like search engines, feed readers and more.

• We think this is the way servers will be handling blog subscriptions in the future, and putting this into Melody will give our users a head start on getting embedded with the technologies and services that matter.

• Pubsubhubbub is more performant and scales better. Melody is all about operational integrity and we will aggressively adopt any technology that can dramatically improve the uptime of your web site.

In our most recent community conference call, we began putting our ducks in a row for a launch of a Melody 1.0 beta. Our first line of business? Bring the product to a level of quality we feel necessary to support a community of beta testers. The best way for us to do that is to build out a robust set of unit tests that we can rely on to assure a baseline level of quality going forward.

We had a wonderful turnout at today’s free training seminar for designers; and by “wonderful” I mean we were at capacity and actually had to turn away visitors because our Adobe Connect account couldn’t accomodate everyone. I must say that it is so rewarding for me and everyone working on this project to see a turn out like this and it reaffirms that the Melody project really is poised to be a huge contender in the content management and blog publishing space.

We are currently in the process of assembling a video and screencast of today’s seminar, so if you missed it, you can always wait to see it again later on in the week when that process is complete. In the meantime, here are the slides from today’s presentation:

Update: the audio component (provided separately) is now available.

We encourage you to share the presentation with your friends and the designers you may know.

To help prepare users for the upcoming release of Melody, we will be taking time to educate as many of you as we can about how to make the most of Melody. Our initial training sessions will focus on designers and developers, and as we get closer to release will expand to include sessions for authors and content managers.

So if you are interested in learning more about Melody, about the many new features we are adding specifically for designers, and about just how easy is it to build web sites for your clients using Melody, then our first online seminar (I just can’t bring myself to use the word “webinar”) is for you. RSVP now!

Jay recently posted this video to the openmelody mailing list. Jay is Melody’s Code Ranger and is responsible for wrangling all of the changes and contributions being made by the community. In addition to being a git expert, he is also our resident git evangelist and has donated a tremendous amount of his time to teaching us all how to use git in order to make our lives as developers easier. Everyone he has introduced git to has loved it, especially theme designers who have, until git, had no easy way to manage and collaborate upon building a web site with other designers and developers.

The video below caught my attention, not just because it provides a great technical background on git, but because it was given by Randall Schwartz — one of the most recognizable names in the Perl community because most of us learned Perl by reading his books.