Articles by Phillip Smith

I’ve had my head down in a large Bricolage CMS project over the last few weeks (well, that and some packing), so it was time that I came up for some air and some technical blogging. First exciting bit of news to report is David Wheeler’s announcement about the released of Bricolage 1.11.3 last week. This is the first (and hopefully last!) beta toward the release of Bricolage 2.0. There is a lot of shiny-new fun in this release, so you should give it a try if you’re so inclined.

The next bit of fun is also Bricolage related…

Call me a curmudgeon (and many do), but I just can’t understand why intelligent folks make the choice to completely ignore Perl. I can understand if you don’t want to use it yourself — that’s all cool — but I wish folks would at least give it the nod it deserves.

Case in point: I was reading Simon Wilson’s excellent blog post about Node.js — an "evented I/O for V8 javascript” and was surprised that he only referenced Twisted (Python) and EventMachine (Ruby) when talking about non-blocking event-driven frameworks.

Why no mention of Perl?

Activist organizations are getting bitten by storing their data in "the cloud" and there is a lot that can be done about it.  Over the years, I’ve seen this happen, more than a few times, to organizations that I’ve worked with. Heck, it’s happened twice in the last year just to New Internationalist. But the question is: as Web services used by these organizations shut-down, or — worse — when they willingly hand out data to any repressive regime that asks for it, are there enough alternatives being developed to provide, well, alternatives? 

This concern was brought back to life for me recently with the news that the micro-blogging service Twitter allegedly assisted authorities in locating an activist during the G-20 Protest in Pittsburgh, resulting in his arrest.. The possible collusion of services like Twitter is a relatively new activist security concern, historically concerns focused on the all-too-frequent seizure of Internet servers and hardware used by activists and organizations like Indymedia. But now that people’s data is moving "into the cloud," there are a lot more issues to be concerned about. 

I got a great e-mail from Gabor earlier this week that proposed a simple challenge: Let’s not get distracted trying to promote Perl itself, but — instead — let’s focus on promoting projects written in Perl.

One of those projects — the one I’m most excited about on a day-to-day basis — is Bricolage, the enterprise-class content management system. Gabor’s note — which asked about the status of the project — makes me wonder why more folks in the Perl community aren’t taking a closer look at what is undoubtedly one of the most capable publishing systems on the market today?

So, in the interest of beating the drum for a Perl project that’s alive and well, I wanted to summarize what I think is exciting about the Bricolage project right now:

Over the years, I’ve been involved with a fair number of Bricolage implementations for different organizations. (For those that don’t know, Bricolage is a large, Perl-based, publishing system.) Many of these organizations don’t have a full-time Perl programmer on staff, and instead rely on external contracts to do the heavy lifting that comes up from time-to-time. However, most of these organizations have a "Web producer" or "Web manager" — a generalist who helps with content updates, and smaller scale Web site changes — and, almost without fail, that person eventually asks: How can I learn more about Perl?

Giving credit where credit is due: The folks behind Padre, the Perl IDE, are leading by example when it comes to doing community engagement well. Twice now, folks from the Padre project have dropped me a note to ask about this or that, which is a great way to catch people’s attention So, with such great outreach, I’d feel like a complete schmoe if I didn’t at least give Padre a whirl.

Unfortunately, getting Padre running is currently pretty difficult — I’d say a tad more difficult than installing Bricolage, which has historically been a non-trivial exercise. No doubt the Padre install process is going to get a whack easier soon, given the high number of commits the project sees in a given week.

One of the most enjoyable benefits of working with a not-for-profit workers’ co-operative is being able to invest some time into activities that aren’t exclusively tied to generating revenue. New Internationalist has long-relied on free and open source software and this year we will try to formalize our efforts to contribute back to projects that have helped along the way. The concept is "Free Software Fridays," which is something we hope will catch on at other organizations.

The concept is simple: those of us that work on technology-related aspects of New Internationalist’s operation invest two hours per week, or one day a month, into supporting the free software projects that we rely on, or toward releasing the tools that we’ve developed internally as free software. The idea itself is open source, in the sense that we’ve taken the broad strokes from the idea of "Open Source Fridays" started by our friends at the Web Collective in Seattle and re-purposed them to fit with the work culture at NI.

A couple weeks back, I asked the question "Where is the big ‘Explore Perl’ button?" and followed up last week with a short demo of the kind of thing I was thinking about. Some folks liked it: so today it’s one step closer to "reality." And now it’s your turn to take it to the next level.

After Adam mentioned that he was running a humourous mock-up of the "Perl Ecosystem Toolbar" on the CPAN Top 100 site, I thought "crap, I better see if I can actually make this thing work."

This isn’t really a post. But, after a bit of a funny back-and-forth with Adam Kennedy, I thought it would be fun to throw together an example of what a "persistent Perl ecosystem toolbar" might look like in reality.

So, here’s a quick demo.

How can we make Perl more "explorable?" That’s the question I’ve been wrestling with since my last post about "Getting to the root of Perl’s perception problems." (By the way, thanks for all of the feedback — very helpful).

As I continued to think through the different audiences that Perl needs to speak to and the challenge of helping them find the information they’re looking for, I kept coming back to one idea: we need a Sherpa.

The interest in improving the perception of Perl is increasing every day (much to my surprise!). From Matt S Trout’s initiative to feed patches back to the maintainers of perl.org to Jon Allen’s TPF grant application to "Improve the visual design of Perl websites," to Gábor Szabó’s "Measurable objectives for the Perl ecosystem," each step builds on the next. All of them are tangible and practical steps toward a Perl renaissance online.

Of even more interest is the approach. Like many Perl programs of the past, it appears like the first thought is "Let’s just fix this fast," which sometimes can happen even before the problem has been well defined (ahem, spaghetti code anyone?). And while the speed of the "Just Freakin’ Do It" approach works when trying to get people excited, it can sometimes miss the mark around harnessing a community’s collective wisdom. In my experience, the Perl community has a lot of collective wisdom to tap in to and should be thinking as long term as possible when it comes to re-defining what the Perl community looks like to the outside world.

So, in the interest of pushing the conversation forward another step, I wanted to explore two questions:

1. What is the Perl community "selling" to the outside world?
2. Who is the Perl community "selling" its message to?

Following on the last post about "Prettier Perl Web sites" and taking Sebastian Riedel’s "Don’t explain what you think would look better, just make a mockup and show us!" challenge to heart, I spent some time looking at Perl’s existing design patterns.

Specifically, I wanted to take a closer look at two established Perl "brands" and to expose the underlying elements of their design consistency; the typography, colours, and so on. The two I chose — because they look like they were developed by professionals, and not some 12-year-old with access to GIMP — are The Perl Foundation and O’Reilly Media’s Perl books.

In this post, I’ll focus on The Perl Foundation. Let’s start with the logo:

In doing a bit of background reading for this post, I stumbled on Sebastian Riedel’s Perl Monk post from 2008 titled "Prettier Perl websites." The discussion on that post is a fun read, as it highlights the polarization in the Perl community around Perl’s (rather lousy) public image. This comment says it all:

One thing I always liked to say about Perl-based services/sites, is that they, like Perl (and the Camel) are "Ugly, but efficient".

However, if you’re following the conversations about "Modern Perl," and "Enlightened Perl," then you know that Perl doesn’t have to be ugly to be efficient. And, in that spirit, I’m not going to debate the why, or if, improving the public face of Perl Web sites is important, as that has been covered in my previous posts.

Given the active conversation unfolding around the perceptions of Perl, I wanted to follow-up with what was originally part of my previous post on the Perl community’s multiple personality problem.

Though I feel strongly that the Perl community’s online visual identity (or lack of one) poses unnecessary friction or drag when trying to appeal to potential adopters, there are also some very positive currents in the Perl community to highlight.

Recently, I’ve been reading with great interest about the future of Perl, and — more specifically — about how the "outside" sees Perl and how Perl might need a director of marketing. Frankly, and at the risk of rocking the boat, I’ll propose that Perl needs more than just a marketing director, or someone on the "outside" to do a survey; Put simply: Perl needs a creative agitator. (Or, perhaps more appropriately, a creative benevolent dictator.)

Though I’ve been using Perl on-and-off for more than ten years, I’m relatively new to the "Perl community." I’ve been involved with promoting free and open-source software since 1999 — writing articles, organizing events, and so on — and sometime in 2005, while interviewing the fine folks at Portland’s FreeGeek project, I was pulled back into the world of Perl.

At that time, my initial reaction was: Is the Perl community schizophrenic?

Okay, here we go — because you’ve all been so anxious for it — the second part of the infamous "Ten things to love (or hate) about Bricolage."

In this week’s post I’ll focus on the things that, as a Bricolage implementer (which I’ll refer to here as a "developer," not to be confused with a Bricolage hacker), you might love (or hate) about Bricolage, the open-source enterprise-class content management system (CMS) that is used at New Internationalist.

I passionately believe in Open, but I need your help to sell my case to the rest of the New Internationalist co-operative. You see, each year the co-op determines the subject of the next ten issues of the magazine at an annual general meeting, and they do it in a very co-op-y way, with lots of discussion, and consensus-building, and then — when that all fails — by direct democracy. Its a beautiful thing to watch.

Behinds the scenes at www.newint.org and blog.newint.org is a tireless workhorse — a system that just keeps giving and giving — and that system is Bricolage. Bricolage is the open-source enterprise-class content management system (CMS) that greatly simplifies the complex tasks of creating, managing, and publishing New Internationalist’s archive of content and media assets. 

As we embark on the redesign and redevelopment of New Internationalist online, after four years on our current platform, we will be retiring some systems and adding new ones — and, for another few years at least, Bricolage will continue to serve New Internationalist’s content management and online publishing needs. 

In the spirit of Cal Henderson’s “Why I hate Django,” James Walkah’s “Why I hate Drupal,” and Vince Veselosky’s “10 Things I Love/Hate About Movable Type,” and after so many years working with Bricolage, I thought it was only fair to write up some of the reasons I keep advocating for Bricolage, and some of the reasons I sigh in frustration from time to time. 

Internet freedom has become a critical component of functional democracies. Global events like the election in Iran highlight the important role that both Internet freedom and press freedom play in maintaining the balance of power between people and politics.

Joseph E. Stiglitz wrote in his book Globalization and its discontents :

“We have come to take it for granted the important role that an informed and free press has in reining in even our democratically elected governments: any mischief, any minor indiscretion, any favoritism, is subject to scrutiny, and public pressure works powerfully.”

And, should that book be published today, no doubt Stiglitz would note that “an informed and free press” is threatened in all countries, not just Iran, when Internet freedom is undermined.

While asking for input on the New Internationalist redesign process the other day, one of my friends replied (in jest) “Is ‘crowdsourcing’ the new ‘design by committee’?”

It got me thinking about why I’m excited by open and transparent design processes, and how concepts like crowdsourcing are exactly the opposite of design by committee. (Well, sometimes.)

For me, the excitement stems from a passion for learning…

How to rescue Mother’s Day from being just another consumer occasion.

A couple of years ago I started looking at options to deliver common “front end” functionality for sites using Bricolage, the content-management system that is used at New Internationalist

Initially, what I had in mind to provide this front-end functionality was a “swarm” of micro-applications, where each little application provided one simple, specific, function, e.g., user registration, comments on content, voting and rating, sharing content, etc. There were other people thinking along these lines too, and – eventually – I came across the MicroApps project, which stated its philosophy as: 

MicroApps are small REST applications that are designed from the ground up to be integrated with other applications. Usually, they are not directly useful on their own, but must be integrated into other applications (this is what differentiates a MicroApp from a regular REST application).

Unfortunately, the project appeared to be at a standstill, and my experience with Python was pretty limited. Most of my experience is with Perl, so my investigation headed in that direction, and eventually lead to the topic of this post: Perl web frameworks. 

Over the past several years, I’ve worked with many organizations and campaigns that have seen their e-mail subscriber lists grow dramatically. As these e-mail lists grow past the thousands of subscribers mark and head into the tens of thousands, or hundreds of thousands, new strategies for list management are often required. 

A couple of weeks ago I wrote about Avoiding e-mail list data corruption and – continuing on that theme – I’ll attempt to start documenting some of the approaches that I have explored to keep large lists growing, manageable, and insightful. 

This week I’ll focus on making them more manageable. 

After a good banter back-and-forth with my colleague here on the New Internationalist Web Team about CSS frameworks, I thought it would be helpful to jot down the key themes of the debate and possible solutions. Hopefully this will benefit other teams that are managing large collections of inter-linked sites that evolve over long periods of time.

Many of the leading minds of the “semantic Web” movement, like Jeffrey Zeldman and Andy Clarke (full disclosure: Andy is leading the upcoming New Internationalist online re-design), have recently compared CSS frameworks like Blueprint CSS to Dreamweaver. For those Web producers that develop skillfully handcrafted sites, tools like Dreamweaver are akin to training wheels on a bike, or a “colouring between the lines.”

That is argument number one against CSS frameworks: they are too prescriptive in their approach, and limit creativity.

The second argument is that they are not purely “semantic,” that is that their markup contains both semantic class names, and names that are purely for presentation or layout purposes.

I think that both of these arguments are mostly (cough) malarkey, and only serve to divert the debate from where it should really be: manageability (And this is an area that really needs some creative, and innovative, thinking).

A few weeks ago, I started a major upgrade to New Internationalist's broadcast e-mail infrastructure. In the process of the upgrade, I noticed that a small number of e-mail subscriber records had been maliciously injected with arbitrary data (in this case, URLs to some other site).

Upon investigating the issue, it occurred to me that many other sites and organizations with larger e-mails list could be susceptible to this type of e-mail data corruption. So here's a quick run-down of the problem and some possible solutions.

The injection is relatively unsophisticated, and is not specific to one e-mail broadcast tool (i.e., I think it would be an issue for almost any e-mail platform on the market).