Back in December 2009 I wrote about PlebGUI, an experimental branch of WebGUI with mod_perl replaced with Plack/PSGI. As a result, I was able to demonstrate WebGUI running on shared hosting via Plack + FastCGI. For the next few months I worked through the process of turning the proof of concept into something core-worthy. Primarily [...]

Speaking of articles, I finally got around to documenting two of the larger systems I designed for WebGUI (the Perl CMS) last year: FilePump – speeds up your front-end performance by maximising your YSlow score Passive Analytics – a system for analysing website usage data These features are both now part of the WebGUI core.

The difference between /images/myimage.jpg and /uploads/XX/XX/moregibberish/myimage.jpg is incredible

WebGUI is in the process of moving to Moose, and I've spent the last few weeks just learning Moose and writing perl.  It has been a very good time. You can see the work that I've done in the git repo in the WebGUI 8 branch: http://github.com/plainblack/webgui/tree/WebGUI8 WebGUI::Definition provides two sugar methods, property and define, that replace the old definition subroutine/data structure, and it sets up the meta class for properties.  WebGUI::Definition::Asset builds on WebGUI::Definition with just another meta class and property class. Here's where the hang up comes.  What used to be AssetAspect is now a Moose Role.  Each Role should have all the same sugar and meta class as a regular Asset, but doing this:     use Moose::Role;     use WebGUI::Definition::Asset; makes for Moose puke:     WebGUI::Role::Asset::RssFeed already has a metaclass, but it does not inherit WebGUI::Definition::Meta::Asset (Moose::Meta::Role=HASH(0x9781a78)) at /usr/local/share/perl/5.10.0/Moose.pm line 160

Navigations are often the slowest part of the WebGUI site. Here's how to make them fast.

I have always embodied the perl virtue of laziness.  Well, at least I've tried most times.  Most times, this is good, since it helps me to write small, well tested code that is easy to maintain.  Other times, it's bad, since I've never learned Moose or DBI::Class.

I just got an email from Monty (the creator of MySQL) asking me if I'd help get people involved in a petition to keep MySQL open source. So here I am asking you to get involved. You can do this quite easily by simply going over to http://www.helpmysql.org and signing the petition.

Our project, WebGUI, a perl-based CMS, has a varied group of developers.  Most developers are consultants and contractors who make a living from customizing and developing applications for WebGUI.  Some are users who dabble in writing macros and simple sub-applications.  A few are purely volunteers.

After reading Perl Testing, A Developer's Notebook, I started putting this into all the WebGUI tests:

Check out the new www.webgui.org!

Get involved, and help make WebGUI better.

Today we unveil the Google Picasa plugin for WebGUI Gallery.

Working on a perl-based CMS, I get bitten by client-side caching a lot.

GIT diff muscle

Pages, pages everywhere.

In my day job, we use an open-source content management system called WebGUI. They recently switched to git to manage their source code. "Great!" I thought, "Git's decentralized nature will make it super easy for me to maintain the local additions and modifications we've made to WebGUI over the years while still being able to update to new upstream releases as they come out."

Yeah, right.

I still haven't figured out how to do this correctly or easily (see update below). My first attempt was to branch at the v7.7.20 upstream release tag on the webgui-7.7 branch. My branch is called webgui-7.7-pin and I committed all my local additions and modifications to that branch. I then pushed it out to an EC2 instance so my WebGUI servers running in EC2 can pull their code from it when they launch. I committed a few more changes over time, and I even committed a couple of bug fixes upstream and to my local branch (because I want the bug fixes now, not in the next release). So far so good. But then 7.7.21 came out.

I tried doing (on the webgui-7.7-pin branch):

git rebase v7.7.21

That v7.7.21 tag name gets found by git on the webgui-7.7 branch and it rebases, or forward-ports, my local commits to the 7.7.21 tag. Git does this by rewinding all my commits, fast-forwarding from the v7.7.20 tag (the original branch point) and then re-applying my commits in order to that new tip. So I end up with exactly what I want, v7.7.21 but with my local changes applied on top of that. Then I tried to push it to my "cloud" remote (the EC2 instance serving my production servers). The push is rejected because it's not a fast-forward. As far as my cloud remote is concerned, my local copy of the webgui-7.7-pin branch is in chaos. It can't make heads or tails of my rebased code.

I haven't found much useful advice on the web. I'm really surprised this isn't a more common workflow pattern for folks using git. But maybe it is and I'm just going about it all wrong. Hopefully someone will smack me with a clue stick soon!

UPDATE: Many thanks to Haarg in #webgui for the clue stick beating! Turns out I was getting too big for my britches and trying to use rebase where a good ol' fashioned merge did the trick nicely. So here's the new workflow:

1. Upstream releases a new version, tags it v7.7.22 (for example)
2. I pull the latest changes into my local copy of the upstream branch:
   
git checkout webgui-7.7
git pull origin

   
3. I now checkout my local modifications branch:
   
git checkout webgui-7.7-pin

   
4. I then merge the new version tag into my local branch (git is smart enough to go find the "v7.7.22" tag on the webgui-7.7 branch):
   
git merge v7.7.22

   
5. Resolve any conflicts that created (it happens), commit them (not necessary if the merge created no conflicts), and then push to my cloud remote:
   
git push cloud

   
6. This time the push was a fast-forward merge and the cloud remote happily accepts it. Hooray!

The new roadmap is online.

WebGUI 8 is going to be the fastest version of WebGUI ever released.

When I was in graduate school, I interned at Hewlett Packard.

At the WUC I let everyone know some of the details about what's coming with WebGUI 8. Today, I posted the todo list for WebGUI 8 to the developers mailing list.

Do you use image rollovers? Do you still use Javascript to do it? There's a better way.

My experience becoming a contributor to the YUI project.

Plain Black has just published a new site called TheGameCrafter.com which is a great example of what can be done with WebGUI Shop and a little elbow grease.

Several little tidbits:

I got my start in WebGUI volunteering.