Thank you.
This is a QR code for the slides and also all of the talks I reference in this talk.
And yeah, thank you Theo for organizing the poll in Raku Devroom.
I'm going to talk about, you can all hear me okay?
Yeah, perfect.
I'm going to talk about Pearl at PayProp, which is a company I work for, an established company,
been around for almost 25 years now.
And briefly about me, I don't normally do this, but I see a few faces I don't recognize
and I'm sure people don't recognize me as well, so I thought I would do this.
I'm a senior dev and head of processing at PayProp.
I've been there for 10 years.
I've been a developer for just over 20 years.
I've worked with various languages, but mostly Pearl.
But I've only worked for three companies in the time I've been in that 20 years, so I've
kind of seen tech stacks grow and shrink and change.
I'm a C-Pone contributor, so Lijo, I'm a C-Pone, Meta-C-Pone.
And I'm a London and Swiss Pearl and Raku workshop organizer, so come and talk to me
if you're interested in any of those.
We're searching for a venue for this year's London Pearl workshop, so if you have any
ideas, come and talk to me.
And I'm a regular speaker at other Pearl workshops and conferences, and often I'm helping out
with the video.
And I occasionally blog on Pearl.
I prefer to do long form articles rather than technical kind of, this is how you use this
module kind of posts.
And I run the Pearl events Instagram account, but that's about the limit of my social media
interaction.
And I'm a Fosdum Newsbie, so my first time here.
We usually have a work event that runs at this time of year, so it always clashes with
Fosdum, so I've never managed to make it, so this is the first time it hasn't clashed
with Fosdum.
So about paper op.
That's what kind of what we look like, the public facing part of the site at least.
We're a payment and reconciliation platform for the residential letting industry.
And we kind of, our core business value is we turn things like this, and this is one
of the nicer ones to deal with.
This is a Swift format into things like this.
So we put interfaces and automation on tank consuming payment reconciliation flows.
And this literally saves our customers hours, days, weeks of time, so we're really, really
useful to them.
The key night of you might see CGI bin script.cgi in that URL.
So yeah, we've been around for over 20 years, so we have some old code, bit of an understatement
in places.
But the pearl we are using is relatively modern, 532.
And we build our own pearl, and we don't use the vendor supplied pearl or the system pearl.
We don't do anything special with it.
We could in theory compile it with different flags, but we don't do that.
So we get the defaults, which means we don't get things like iThreads, because if you use
vendor supplied pearl, you get things you probably don't need.
Yeah, the key is that it's not the system pearl.
So we're not kind of tied to any particular version of an OS or package or whatever.
And we can apply updates and patches as necessary.
We should be on 538 by now.
We tend to trail a major version.
I've been spread a bit thin, so we haven't managed to get to latest, but that's on the
roadmap for this year.
Yeah, and it gives us dependency control, which is critical.
If you've been paying attention the last couple of weeks, there's been a couple of
critical CVEs against a couple of spreadsheet passing modules, so we could get those updates
out quite quickly.
Loose coupling, so yeah, like I said, not tied to the OS or anything like that.
And the key is it's everywhere.
So we have the same version of pearl, the same version of modules from dev through CI
staging demo all the way to production.
So otherwise you get interesting debugging problems.
And while the issues and challenges around that, well, probably the ones you've all heard,
you know, still use pearl or even what is pearl, and the bus factor, which is, you know,
becoming a problem with some of the pearl dependencies.
So yeah, it's a 20-year-old, 22-year-old app, so we are in the process of migrating
from CGI.pm to Modulicious.
A 20-year-old app has some legacy, a bit of an understatement really.
This is an ongoing task, and we're about two-thirds complete in terms of number of requests to
the site.
We have a lot more pages than we really use after 20 years.
Kind of inevitably happens that people write features and functionality that end up not
being used, and we've got hundreds of pages, and really only 20% of them are actively used.
So a lot of them will never actually end up getting converted.
And one of the ways we did this in one of our other apps is using this plugin from Modulicious.
And we decided not to do this with PayProp because we're using Apache on the front end
anyway, so we can kind of proxy to a Modulicious server or just run exec CGI if it's CGI script.
So we're not doing a kind of serving the CGI scripts from Modulicious using a plugin.
There's no real value there, to be honest.
So that's kind of what the setup is.
I actually gave a talk about this almost a decade ago, so there's a link there to that talk,
which has some suggestions for how you can do this if you're using CGI.
You want to use Modulicious, what the options are.
But it was 10 years ago, so it's a little bit out of date now, because Modulicious moves
fast, and it is one of the challenges in using it because they say that you can always count
on backwards compatibility, but they will deprecate and remove features within a three-month
window, which is not really backwards compatibility.
So you just have to be aware that if you haven't done an update in a while, things might break.
And we're adding an ORM.
And I know this can be a contentious issue, which I kind of find surprising.
I'm just title writing this kind of stuff.
And this is a simplified, about as simple as the query you can do.
So you select some columns from the table, prepare the query, make sure you have the error handling,
execute it, grab a hash ref.
I just want to write that more descriptive.
All the stuff we can get for free is there.
And we can still drop down to vanilla SQL if we want.
And we do do that.
We have some pretty hairy reporting queries, and we're not writing them in ORM speak, because
they're big enough already.
If you start using the DSL of your ORM, they become an obfuscation.
And the reason we're doing that is it allows us to kind of isolate some of the legacy issues
in the schema.
Again, 20-year-old app, organically growing schema, you can have some issues like this.
And we can kind of nicely abstract them away in the ORM that we're using.
Put this down as stuff hack and use says, you know, just fix your schema and things will
break and you might see it.
And it's like, no, we're not going to risk the business by breaking stuff.
We don't move fast and break things.
You know, we want to keep our customers happy.
And then another suggestion is, well, why don't you write your own?
But why would you do that?
You know, we could abstract all our logic into an ORM, but it'd be half done one full of
the bugs that all of the available ones have kind of already ironed out anyway.
And yeah, we're using DRX class.
Very feature-rich, but not dogmatic about its use.
It's like, say, you can use it in ways you want to use it.
Some of the issues and challenges around that, well, there's a learning curve, a big learning
curve, especially if you haven't used an ORM before.
But the manual is very good.
Lots of stuff on the web you can find about how to do, you know, quite bespoke things
with it.
Currently, I say unmaintained, I would say stable rather than maintained.
There are talks happening to kind of address this because it's a backlog of patches that
could be applied and that kind of thing.
And I did talk about this, I want to say, six years ago, using a legacy schema with the
big class and how you can address some of those issues that you might have in your schema.
Business objects, the model.
So the older code is kind of a procedural mashup of business logic, database access,
new logic, and so on.
So it's all kind of smushed into the same layer.
The newer code we're factoring into business objects.
And the key is that the business objects are our model.
Our ORM is not our model.
People often kind of conflate the two.
And the reason we're doing it is to get all of this stuff.
If you're doing object-oriented coding properly, you get all of this really nice stuff.
It's not just calling a method on an instance of a class.
You get really powerful, useful things.
And we're using Moose.
And we were previously using mouse, but we're kind of moving to Moose reasons that I won't
go into here.
Karina is one to eventually look at.
That's been added to the core in 538, the early version.
Ovid's going to talk about that a bit later, so I won't go into that too much.
But just a quick example, this is kind of the thing we're doing.
We're dealing with payments, so we have this incoming payment class, and it has an attribute
that references a bank statement, so we're having type constraints.
So we can properly constrain that it has to be an object of this type with an ID, and
we can throw a useful exception if we try and put something in there that shouldn't be
in there.
And then we can use the tell-on-ask principle.
We can say fail that payment, and then the logic is in one place.
And we're throwing exceptions if things aren't in the right state, and then we're delegating
to the bank statement object to then fail its payment.
So it's all nicely isolated, easy to test.
So yeah, Moose, again, what are the issues and the challenges?
Well again, the learning curve, if you've not used much object-oriented programming,
this is a big paradigm shift.
But I think it's worth it, because I think Moose is one of the best object systems available
across any language.
And then you add the mop, meta-object programming, and you can use introspection and everything.
Pearl's very powerful about introspection.
And there's been multi-day courses at Pearl Conference that's talking about Moose, so
it's impossible for me to even scratch the surface in a small section of a 20-minute
talk.
People often talk about the slow startup if you're using some of these frameworks and
systems, but if it's in a persistent process, a modulator server, that's not an issue.
You load it once, it's loaded.
If it's on the command line, well yeah, it used to be slow, but now it's things have
caught up, and you're probably running those command line scripts once in a blue moon anyway.
CGI scripts, we do use some of this, but we lazy load.
So these are pages that are taking a couple of seconds to run their commands anyway, so
the compile time of loading some of those subjects is a tiny percentage of that anyway.
Yeah, mutable state, that's my technical debt.
It's one of the things you learn, you know, mutable state is bad, so all our new code
and your objects are immutable objects.
Refactoring and regression testing, and I'm talking about beyond unit and integration
testing because that's kind of the easy stuff.
We're adding this for all new code, and mind we do refactoring, we're making sure there's
test coverage there and addressing any gaps.
But what about those critical business scripts that have existed forever and have no test
coverage and basically run the business?
I mean, how do you adjust bootstrapping problem of refactoring so you can work easy with them
but there's no tests, but you don't want to refactor them because there's no tests, it's
kind of a catch-22 situation.
Well, this is Pearl, so we've got some useful features we can use to work around that.
One of the frameworks we've come up with is we are creating override libraries that we
pass into scripts that allows us to override various functions at various times in the
lifecycle of that script that runs.
So here we are overriding the call to file slippers read text method by saying run this
script with this override library path and then we have these various blocks that will
override calls so we can kind of monkey patch things.
So we can add as much test coverage as we need and then start changing the script.
So that's kind of an example of how we do it, a bit down in the weeds, but I would encourage
you to watch this talk by Nick.
He talked about this at the Pearl and Racket conference last year.
It goes into all the details of how you can do this, which blocks you can use to run when,
how it works and some of the issues around doing that because you're actually adding
technical debt when you do this, but we need that test coverage there.
So the aim is get the test coverage in place, the fact of the scripts, the fact of the test
coverage, we're in a better place.
This has been critical for some of the scripts we have because I mean they literally run
the business and they literally have no test coverage while they have test coverage now.
Like I said, we don't move fast and break things.
Contributing to C pan.
So yeah, we actively encourage contributions to C pan.
These are all the distributions that we've either written or taken over maintenance of
in the last decade, which is the time I've been a pay prop.
Stuff like some modulus plugins.
So there's this plugin for NMIT, modulus that allows you to profile your routes using NMIT
prof.
It's really useful.
I wrote some of this OAuth 2 server stuff.
If you've ever used OAuth 2 and tried to implement server side stuff, it's a fun game.
That hopefully makes it a bit easier.
Third party payment libraries.
We interact with third party payment providers so we've written some stuff.
Go Caldlis do direct debit in the UK.
TrueLayer is a new opencomer.
They're using the open banking spec so I think they're going to get quite big in the coming
years.
And other stuff, so we maintain CGI.pm because we still have CGI scripts.
We can maintain un-maintained libraries, Google Maps stuff and all that kind of stuff.
The issues and challenges around that, well, the pool of contributors to C pan is shrinking.
Libraries for newer services and APIs don't exist.
Often you'll find third party libraries for languages except Pearl, which is a shame.
Modern APIs are restful and easy to create a third party library for.
We're happy to throw somebody at it for a week or two, which is what we did with the
TrueLayer one.
They threw me at it for a week and there's one on C pan.
Navigating around IP issues, well, that encourages to decouple our code.
So that's actually quite a good thing.
And finally, hiring devs new to Pearl.
I say Pearl has been on the plateau of productivity for quite a while.
Those that left it a long time ago don't know the current ecosystem.
But more than a generation removed from even Pearl 5.
Pearl 1 was released in 1987 and actually probably Larry was prototyping it a long time before that.
510, which can be considered modern Pearl, there are people starting a university now
that were born after 510 came out.
But it's still in a lot of places and I know that because we've interviewed people.
Some of these users can't talk about it.
Banks, the fangs, I won't emphasize which letter in the fangs, but we know there's people
using Pearl in these places.
So I think the rumors of Pearl's demise are greatly exaggerated, but it's kind of a known
unknown at this point.
And it's still be using Greenfield projects, so the system that Fosdham used to review,
annotate, cut, process, transcode and publish all of their videos runs on modern Pearl.
So over a thousand videos this weekend are going through a modern Pearl system.
And its popularity is kind of normalized over the last two decades, I think.
So it's had to find Pearl developers.
But newcomers don't have preconceptions.
That's my experience of interviewing anyway.
I think those under 30 either haven't heard of the language or haven't used it.
And those who don't want to use it self-select out of the process anyway.
Because we are explicit that we use Pearl in our job specs.
We just don't require it unless we're hiring a senior Pearl developer.
And I find modern Pearl is an interesting and enjoyable language to work with.
Working with legacy code is not specifically a Pearl thing.
And we make sure to do all of this stuff, because you should be doing all of this stuff.
And we're finding in a distributed work environment you need to do all of this stuff.
I've not really talked about this much in the past, but I have written blog posts.
So check out the blog posts if you're interested.
And the key is that you can still be very experienced, but still a newcomer.
And that's absolutely fine. And I think it's actually beneficial to the ecosystem and the community.
So if you are, please speak up. You want to hear from you.
And that's it. I don't think I have time for questions.
So thank you very much.
Thank you.