andrewalker

About a year ago, I submitted a grant proposal to TPF to revitalize this platform, blogs.perl.org. It was supposed to have taken only a few months, but it's still not ready. In the meantime, I have been completely silent, at least publicly. What's going on? Is it ever going to be delivered?

Indeed, I should have started writing here months ago, with traditional timely updates on the developments on the grant. What discouraged me to do so was that these developments have been somewhat irregular. Some moments of uncertainty on the best course of action, and others of simply not being able to dedicate enough time to it. Still, I assure you, dear BPO reader, the project is alive and well!

In the interest of being more open, then, I'll make a series of posts this week saying all that I've been working on and what's my overall plan for blogs.perl.org and PearlBee.

Let’s start with the beginning.

The first thing I attempted to do, once it was accepted, was exactly what I described in the proposal. I tried to find ways to reuse as much as possible from the work that others had put into this. If you’re not familiar with the story, there was already a grant proposal for revitalizing blogs.perl.org years ago, which was never completed. It was based on PearlBee, which has multiple forks lying around. My goal at first was to pick one of these forks (in particular, the one I had been working on with Sawyer X), and backport features from the others (especially the one from the previous grant), if they were general enough. After that, I would see what was missing, and work on that.

I soon realized this wouldn’t work out. The fork of the previous grant had a huge feature set, and it was hard for me to determine what was finished and what was not. It had some hardcoded paths and dependencies, so that even starting it up was a challenge at first. I’m sure it would have turned out great once it was finished, but for me to map everything out was tough at this point.

I decided to just go with the basics, the common sense, really: what are the features we need? A sign-up page, login, logout, reset password, a dashboard to manage posts, a few ways to filter posts. A few more features, but you get the idea. Sure, one day we might want to have login via social media, but not essential. Even comments, we can delegate to a third party at first.

Ok, so now we have a very limited set of core features, what’s next? I want to make sure I get them right. In a sense, that’s why I reduced scope as much as possible. For me that meant rethinking the data model, and writing tests. I reworked PearlBee’s entire database schema, taking into account those core features. And for every feature, I would start writing tests to see if PearlBee already had it, and if not, I would implement it.

To be sure I would have reproducible builds, I also set Travis CI, and set up Heroku to auto deploy master when the tests pass. That gives me peace of mind that it doesn’t just “work on my machine”. It should be easy for new developers to work on PearlBee, and it should be easy to deploy to new servers.

Looking back, this was a good strategy. The tests aren’t perfect, nor is the data model, but it makes everything a lot clearer to me. It gives me visibility of what I have and what’s missing.

I started writing tests for every feature, as I described, until I got to the point of writing posts. And then, a pile of unknowns unraveled, and that’s a a whole other story. Come tomorrow and find out.