DEV Community

loading...
Cover image for Efficient programming

Efficient programming

Dave Hodgkinson
JAPH.
・2 min read

Coming out of a job where I was working on a 20-year old Perl codebase, I've got some burns to get off my chest. I'm reading "Accelerate" by Forsgren, Humble and Kim which claims to have scientific backing for what makes for efficient development in a team. In my recent experience:

  1. Use decent version control. To me, that means GitHub. Use a branching strategy to code each branch to a JIRA. Make the branches short-lived, preferably a day. GitHub is stateless. Diffs are resolved at merge-time when pull requests are made. Under NO circumstances use something like Perforce. That is like putting a large speed bump under a low slung car. It's stateful. Mapping a repo into your filesystem is a pain. Rewinding commits is a royal pain. Ugh.

  2. Release often, releases should be easy. A marker of a high performing team is how frequently they release software. A release should not be confined to one person on the team and take half a day.

  3. Great balls of mud are hopeless. We've been writing new software as microservices for a while now, and more recently bundling them up in Docker containers (and if you're really advanced then using Kubernetes). In the Perl world that means using a framework such as Mojolicious, Catalyst or Dancer with excellent modules like the Template Toolkit for the view and DBIx::Class for the model and not v1 of view software that's barely been touched for years and v2 exists. It also highly bound to Apache and hard to use elsewhere.

  4. Ongoing support for mod_perl in Apache 2.x is ongoing. It's already been abandoned in Apache 1.x so I would note that software is doomed at some point.

  5. Be very careful layering software upon software. Or using features that make things opaque. Oh, and having magic variables and not documenting them. For example, you have Puppet. That's great. Why not layer Heira on top and render most of the puppet documentation useless. Or use a templating system that magically calls in a hierarchy of other templates. Oh, and where does that database handle come from? Somewhere in the bowels of that page startup. Not sure which module.

In summary, I'd say be aware of the speedbumps. How can you improve them?

Discussion (1)

Collapse
mbeijen profile image
Michiel W. Beijen

Ongoing support for mod_perl in Apache 2.x is ongoing. It's already been abandoned in Apache 1.x so I would note that software is doomed at some point.

Well, Apache 1.x is abandoned as well, it had it's last release in 2013, so I don't think it's strange mod_perl on Apache 1 is no longer developed.

Apache 2 was released in 2002 - almost 20 years ago now - and mod_perl works fine on that.

That said, it makes sense that if you deploy a web service on Perl in 2021, you'll use PSGI and a PSGI-enabled web server. What's your preferred solution?

I know there are a lot of options, and a little bit outside of the Perl ecosistem there exists UWSGI - uwsgi-docs.readthedocs.io/en/lates... and also NGINX Unit - unit.nginx.org/configuration/#conf...

I have yet to see much adoption for those but I think they're valid choices.

Forem Open with the Forem app