Welcome to the beta version of newint.org — we have just redesigned it — more features coming soon!
We care about your opinion. Let us know what you think, or report any problems. Feedback »

Bricolage: Localhostin' it and other news

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. One of the aspects of working with the Bricolage CMS that I find most enjoyable is that it is an entirely "back office" workflow and publishing system. That means that Bricolage usually runs on an entirely separate server from the "front-end" Web server, i.e., the server that delivers content to your site's visitors.

There are several benefits of such a "back office" system, but -- by far -- my current favorite is the ability to take the whole damn thing with me on my travels: a complete working copy that I can continue to develop on while offline and without Internet access. This happens to be particularly handy when working from the road in South America.

And when I'm finished with my changes to various Elements and Templates, I simply run bric_dev_sync and let my offline copy sync its changes to the live copy that the rest of the development team is working with.

The other unique Bricolage feature that I was pleased to finally get a chance to use is make clone. Running make clone creates an archive of your current Bricolage installation that can be easily installed on another server. With the archive in hand, I was able to simply run make install on my laptop and, with relatively few headaches, soon had a perfect clone of the existing Bricolage instance running locally: elements, templates, content and media documents -- well, er, everything.

Sure, none of this is exclusive to Bricolage, but it sure is makes the "digital nomad" life a bit easier. After all, isn't that was Perl is all about?

Perl: Love it, or hate it, but don't ignore it.

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? In reading about Node.js, it looks like one of the critical pieces of Node.js -- libev -- was co-authored by Marc Lehmann, a rather prolific CPAN contributor. Mark also appears to be the author of AnyEvent, one of Perl's own even-driven frameworks. It's not like PSGI and Plack and POE haven't been getting some good attention lately. And even the slideshow listed at the end of Simon's post mentions AnyEvent as an alternate event-driven option.

So what happened?

As most Perlers have probably experienced, this is not an isolated event. Virtually every discussion of Web frameworks -- Ruby on Rails, Django on Python, Symphony on PHP -- manage to avoid any mention of Catalyst, Jifty, or the Mojo Web Framework.

Given Catalyst's lineage -- fork of a Perl MVC framework called Maypole -- I find it a bit strange that it's so often left out of the picture. (Even more strange when one considers that Catalyst is technically older that Ruby on Rails -- or so I've read.)

So.. Why do intelligent programmers so often leave Perl out of picture when talking about new approaches? Is it a conspiracy? Just plain oversight? Or the legend of "Perl is dead" rearing it's head again?

I don't have an answer, but I wish I did. (Though, I'd probably start my investigation with the lackluster attention that O'Reilly gives to Perl.com.)

There's lots of activity around Perl. Just check out StackOverflow or commandlinefu.com. Supposedly Perl Web searches are on the rise, and the Twitterverse is all a-flutter with everything Perl, and Perl.org got a design refresh (hats off to those involved).

As the old saying goes: Love me, or hate me, just don't ingore me. If people want to hate on Perl, so be it. But I propose that it would benefit the Perl community to ensure that Perl is not ingored.

So the next question is: How do we raise the volume even higher?

Re-thinking resistance in the age of the cloud

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. 

(The "cloud" I'm talking about here just refers to putting data online somewhere, not specifically "Cloud Computing.")

From Yahoo!'s alleged collusion with the government of China, to Skype's "accidental" data leak that may have compromised the security of Chinese dissidents, we see that the Internet is no longer the land of the free. It's increasingly the land of the very rich and powerful, and can be used against those working for positive social change. 

Pondering this, my burning question is: In the age of "the cloud," is there not a new opportunity to re-think the needs of resistance culture in the face of changing times and technology?

I'm constantly inspired by the work of organizations like Resist, Riseup, Tao, InterActivist Network and the many other activist technology collectives that exist around the world, who are working tirelessly to train activists to secure their communications and providing the necessary technical infrastructure to work toward a more just world. But are their efforts, alone, enough? 

For example, would it be possible today to re-invent the idea of a radical communications infrastructure, but one that is built in the cloud -- literally -- removing the ability to pin-down a Web service down to one physical server, or location, and making it possible to quickly scale up and down as needed. (And freeing up valuable closet space in the process!)

Or, for those situations where putting data in the cloud creates more risk than opportunity, would it be possible to work toward not just free and open-source alternatives, but more radical alternatives (like Crabgrass)? Perhaps alternatives that are rooted in activist organizations -- organizations like New Internationalist -- that have been around for 30 years already, and will likely be around for 30 more (in one form or another). Why do we put our valuable communication infrastructure (coughTwittercough) into the slippery hands of the hi-tech start-up so often? 

So the question is: Given the critical role that technology plays in the work of today's activists and campaigning organizations, is there a need for a more radical communications infrastructure? From the large-scale outbound e-mail delivery required to drive online campaigns, to the micro-notification systems that help activists on the street, right on down to the provisioning of secure ways for activists to do their organizing -- all of this, currently, is all too often put into the hands of those that, all too often, do little to defend it when the time comes. 

What do you think? Are alternatives needed? What services are needed most?

The comments are open.

Promoting projects that are written in Perl

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:

  • The upcoming 2.0 release: After eight years, it's a bit of an understatement to call Bricolage "stable," it's like a clock that -- for the most part -- just keeps on ticking. That said, there are lots of improvements being added all the time, and the project is heading for a big milestone this year -- Bricolage 2.0. There's currently a developer release out, so if you've got cycles, please do take it for a spin. 

  • The user interface improvements: It's hard to summarize all of the improvements expected in Bricolage 2.0, but the one that most folks will experience in day-to-day use is the new, AJAX-powered, user interface. There's a short screencast of some of the new UI over here. (There's also work being done to re-think the UI altogether, which is something the project is always looking for support on.)

  • The new API browser: Bricolage exposes a powerful API for interacting with your data via both the templating system (which supports either Mason or Template Toolkit) and a SOAP client. The API documentation browser has recently been updated to make it easier for developers to get up-to-speed quickly. 

  • New source code repository: Along the same lines, Bricolage's source code was recently migrated to GitHub, and bug reporting to Lighthouse, to encourage more people to get involved. If you've never taken a look under the hood, now is a great time to do so

  • Active user community: Like the Perl community itself, some folks seem to think that Bricolage is a little quiet these days. Fortunately, that's not the case -- the Bricolage community is alive and well (and incredibly helpful) and can be found on the Bricolage mailing lists or on #bricolage on irc.perl.org. 

If you don't have time to dig into Bricolage today, you can always subscribe to the "Output Channel," the quarterly e-newsletter that covers most of what's happening in other places (via e-mail, or RSS). 

Just looking for an excuse to give it a try? Or wondering how it stacks up against the other options out there? Try out the VMware image, or check out these previous posts:

And if Gabor gets his way, you might just find a Bricoleur or two at FOSDEM in February. Other than that, what will it take to see some sites out there in the Perl ecosystem running an easy-to-use, stable-as-a-rock, pure-Perl, content management system? 

The comments are open. 

Perl in your city

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?

The question came up again recently and it got me thinking about the relative obscurity of Perl learning opportunities. There are the obvious challenges that have been discussed recently, i.e., the limitations of learn.perl.org, the small number of Perl books published each year, the fact that O'Reilly appears to be forgetting about Perl, and the prominence of outdated learning resources that don't help to promote the best practices described as Modern Perl, or Enlightened Perl. 

All those challenges aside, the biggest obstacle for many may simply be that it's hard to find traditional learning pathways, like teacher-led courses, certification programs, and online learning opportunities. 

These opportunities exist, but are often hidden away in the annals of community college course offerings, vocational programs, or are only known to Perl insiders who read Perl-related news (which kind of defeats the purpose, if the course if introductory in nature).

Go ahead: do a quick Google search for Perl courses in your city and see what comes up. Now ask yourself: if you were new to Perl and were in search of a learning opportunity, would you have enough information? How would you come to a decision about which learning opportunity to invest in? Who could you ask? 

This got me thinking about a couple of things: 

  • The need for Perl learning resources that go beyond books
  • The need to connect people with Perl resources in their community

Perl learning resources that go beyond books: For starters, lots of people don't learn well with a strictly self-directed approach. While the Perl books are great, they probably can't compete with an in-class experience that includes peer support and a teacher, when it comes to helping people who are new to the language and prefer learning this way. 

On this point, I'm thinking that it would be helpful to compile a list of online courses that can be accessed by people living anywhere. I haven't done an exhaustive search, but these two are ones that I have recommended to people in the past (not Perl-specific, but with Perl components): 

... but there must be others out there, no? (Know some? Please leave them in the comments.)

Connect people with Perl resources in their community: For those that live close to large urban areas, there are probably several options for learning in a traditional course environment at a community college or similar continuing education programs. The challenge is: How does someone who doesn't know what they need to learn make a decision about which to choose? 

Perhaps this is something that the local Perl Mongers groups could help with, either via their mailing list, or via some kind of a local resources page that provides a list of courses and some comments on the advertised course content. 

And, while I'm thinking about it, a local resources page could also automatically aggregate some other helpful information like:

  • Local Perl jobs (via jobs.perl.org, Craigslist, etc.)
  • Local Perl news (via planet.perl.org, etc.)
  • Local Perl bloggers and Twitterers (via Technorati, Twitter search, etc.)
  • Local groups & meet-ups that aren't Perl-specific

What do you think? Would it be valuable to explore ways to help people connect with Perl resources that are specific to their region or city, e.g.: yourcity.perl.org? The comments are open.

A Perl-based editor for Perl, on a Mac. 

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. 

Anyway, for those that want to enjoy the benefits of a pure-Perl editor -- like being able to improve it -- on OS X today (well, on OS X 10.5, as there's currently no easy way to get Padre running on Snow Leopard's 64-bit Perl), here's a quick write-up of how to do it. 

Padre, The Perl IDE on OS X (10.5)

Since I'm somewhat risk adverse, I decided to try the advice on the Padre download page to use a newer version of Perl. The system version of Perl in OS X 10.5 is 5.8.8 and Padre requires a Perl configured with threading enabled. 

Turns out this isn't too hard, just:

  • Download the current release of Perl 5.10. Unpack it. 
  • Run sudo ./Configure with -Dusethreads to compile it with threading.
  • From there, follow the instructions in the README to get Perl installed in /usr/local/bin/ so it doesn't  muck with your system's Perl. 
  • Then, to make it easy to use your new Perl, run: export PATH=/usr/local/bin:${PATH}

Now you should have a localized version of Perl 5.10 installed and can start having all kinds of fun using its new features

  • Then, and only then, use CPAN to install Padre 
  • I hit two failures during the CPAN process (wish I'd noted what they were!)
  • I forced installed these two modules  (yah, yah...)

And, voila, an ostensibly working Padre on Mac OSX. If you're experiencing problems, make sure to note what they are and pop into the ever-helpful #padre IRC channel on irc.perl.org. 

I must say, after some initial fiddling about, I was quite impressed with Padre's functionality. Unfortunately, I'd only recently invested the time in upgrading from the simple text editor that I've used for years to the Eclipse-based EPIC for development and can't say that I'm ready to make another leap quite yet. That said, I'll certainly be keeping a close eye on Padre to see how it evolves. 

Again, kudos to the Padre team for building a promising product and an engaged community. Neither are easy to do. 

Free software Fridays. Let's promote participation.

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.

Obviously, the concept of "Open Source Fridays," or "Free Software Fridays," isn't something limited to the purview of non-profits, or co-operatives, and it's clear that lots of organizations are already making huge contributions to free and open source software as part of what they do (and that's an incredible thing). The key concept here is that any organization can choose to prioritize and institutionalize those commitments and investments with just a small token gesture of time.

The idea isn't new and the amount of time we're talking about is not much. However, for those of us here at NI -- working to support the day-to-day technology needs of a publishing operation that spans the globe and runs 24/7 -- being able to prioritize some small amount of time to participate and contribute to the free software ecosystems we rely on makes a big difference. Sure, as free software activists, we'd probably be doing these things anyway in our personal time -- but having dedicated work hours helps to underscore the ongoing importance of these investments to the rest of the organization.

What are some of the ways that we currently (or are planning to) invest that time?

  • Promoting the tools that we use here at NI publicly (through writing and blogging);
  • Fixing bugs in systems that we're using, and then contributing them back to the originating project;
  • Releasing templates, code, and tools that might be useful to other organizations.

Simple stuff. No magic here. But how often do these items fall off the to-do list when time and budgets are tight? 

One of the most rewarding projects for me at the moment is writing the Bricolage "Output Channel" newsletter every few months. It requires a fair bit of work to sift through various sources and come up with the newsworthy content, but the personal notes I get back from those that read it tells me that it's a valuable contribution to the community.

Let's face it: technology is a growing part of almost every organization's operations. And, there's a good chance that free or open-source software is either part of the mix currently, or will be one day soon. So here's my pitch: let's promote some easy ways to participate and contribute to free and open-source software projects that any organization -- no matter how big, or small -- can make each and every month. If we all invest a day, that will add up pretty quickly.

The Perl ecosystem toolbar: Now it's your turn.

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."

Last night, I managed steal a couple of hours to get the initial version tested in a few different browsers (screenshots here) and checked the work into github over here. There's also a live demo of it online here.

So, what are the next steps? Well, that's where you come in. Specifically, to push this forward, I could use some help with:

  • More browser testing (Opera, Linux browsers other than FF, etc.)
  • Determining what sites to link to for each of the sub-menu items (currently unlinked)
  • Implementing improvements to the CSS or Javascript, or both.
  • And, finally, converting this into something that folks managing Perl projects can quickly and easily include on their site.

On this last one, I guess that could be any or all of the following:

  • A simple .html file with absolute paths to the necessary images
  • A merged HTML file that includes the CSS and background images embedded using the "data URI scheme"
  • A JavaScript file that could be referenced with a simple script tag, like so many "widgets" that are provided by various sites these days.
  • Other options...?

I think the main challenge of the JavaScript option is going to be how to position the bar at the top of the page without obstructing any existing content. Maybe that's easy; I honestly haven't thought it through and would be open to any advice folks have to offer.

Anyway, that's it for today. Any testing help appreciated. The code is available for you to fork and hack away at. I await and will welcome your pull requests on GitHub.

Demo: The Perl ecosystem toolbar

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.

Yah, yah: it's nothing too fancy. But, it would probably look a darn-bit better than what Adam has running over on the CPAN Top 100 site right now. ;-)

Once I have it tested and working in at least a handful of recent browsers, I'll post the code and maybe you folks can take it from there.

Sadly, I think I'll be wrapping up my "Perlceptions" posts over the next week or two. It has been fun thinking about the opportunities to Perl to re-think it's public image, and I'm excited to continue to promote the coming Perl renaissance. However, for the next few months, I'm going to get back to my previous commitments (that have been neglected for too long) to the Bricolage project.

Onward!

The big "Explore Perl" button, where is it?

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.

A Sherpa for Perl

No, not a real Sherpa, or some virtual recreation. But a wayfinding system that will help people find their way to the top of Perl's Mount Everest. So I started investigating what design patterns are out there in the wild for wayfinding across a network of sites, and recorded these specimens as inspiration (click on the photo for the full-size version):

BBC Explore navigation


My favourite by far (because I use it all the time) is the BBC's "Explore" button. It's always there, across all of their sites, and never fails me. (You can see it in action, and try it, here.)

Virb bar


I also like the Virb bar, as it provides some other useful buttons: Take the tour, Search, and Help. Interesting ideas to think about in relation to the enormous Perl online ecosystem.

Sidebar network banner


On the simpler end of things is the network banner for Sidebar creative; just links to each of their various sites. Again, always there, easy to find your way around.

Wayfinding through the Perl universe

The challenge for the Perl community -- and I would argue it's as much of a challenge for the BBC (or probably more) -- is the vast, sprawling, universe of Perl sites. And, as discussed before, they are all over the place. Each has a different navigation system, a different look and feel, and no common set of links to other Perl sites.

This is not a challenge that is going to be solved quickly, or easily -- though I'm glad to read that the TPF and EPO have taken up the cause directly -- and I suspect that the Perl community will need to live with a ad-hoc collection of sites for some time to come. So, with that in mind, I set myself to sketching out some ideas for an "'Explore Perl' persistent navigation bar" that could be implemented easily, and quickly, and across several of the key Perl online properties.

(Like the example design patterns shown above, I think there's a lot of room for creative interpretation here -- should it be dark, light, and so on -- so, to avoid the taste debate, I simply present some ideas for the information concerns of such an intervention.)

Explore Perl persistent banner mock-up


(Click for full size image)

Here we have a simple, persistent, bar with a big "Explore" button that opens into a "Mega Nav" with logical menu groups for the major audiences described in my last post. It's simple, and effective: providing a minimal-looking bar that opens into a very useful way of navigating the Perl ecosystem.

Just for those who aren't huge fans of the "Mega Nav" approach, here's another version with the groupings rolled up into simple buttons in the bar:

Perl ecosystem persistent bar mock-up


Hopefully this presents the idea clearly. Again, if you haven't experienced how this would work, go try the BBC "Explore" button over here -- then, come back, and let me know what you think.

Finally, feedback on the grouping and the contents of each grouping, would also be helpful. Clearly, I've left out some obvious things -- like CPAN -- and I've done that because I'm grappling with where they conceptually fit. Suggestions welcome.

Pages