21–30 of 57 posts
Earlier quoted context omitted.
> what ORM to use (or not to use an ORM) do you have something to recommend ? used Rose::DB in the past, then I discovered SQLAlchemy and it's difficult to look back...
I'd need someone suggesting anything other than DBIx::Class to present some ironcast arguments for that choice
I've just started tinkering with Mojolicious, after spending some time playing with a variety of other frameworks in other languages (I'm starting a new web project, and wanted to make an informed decision about how to build it). Mojolicious gets so many things right in such a tiny package, I'm surprised more folks aren't using it or talking about it. The real-time support is awesome; setting up Websockets is stupidl…
> what ORM to use (or not to use an ORM) do you have something to recommend ? used Rose::DB in the past, then I discovered SQLAlchemy and it's difficult to look back...
Love DBIx::Class.. but it's not a good/perfect fit for Mojolicious by a long way.. it's blocking by nature and thus doesn't play too nicely if your aiming to write a non-blocking mojo app. reply
We investigated a lot of other options (go & python specifically) when building new projects, but found that perl was the best solution. It's flexibility allowed us to develop a custom and durable solution that surpassed our expectations.
We ran into some environment/portability issues and resorted to using docker, carton, and gitlab CI to solve these problems. It is incredible how reliable and easy it became to modify and deploy code to a variety of systems (new or old).
Earlier quoted context omitted.
Why would this surprise you? Perl continues to improve and is battle tested. More Perl is written today than ever before (that said, much more software in general is written than ever before, and there is no doubt Perl's share has declined). Particularly if you're doing lots of text processing Perl remains a great choice.
> Particularly if you're doing lots of text processing Perl remains a great choice. And, when you get right down to it, a huge chunk of web dev falls into that category.
I've taken some steps to do a re-implementation in node, but the perl version "just works" with very little fuss, under fairly heavy load, and is pretty easy to debug when I need to.
This is very much a microservice: tailored PXE environments as a service based upon a database, and the booting mac address as a key. A programmatic/database-based backend to a PXE server. It allows us to boot effectively anything that is bootable by modern hardware, from Linux, Windows, SmartOS/OpenSolaris, through FreeDOS, and other more esoteric systems. A number of our customers use this as a configuration tech underneath their own orchestration layers.
All Perl based, and using as modern techniques as possible.
We stopped using system Perl many years ago. Red Hat seems to like to ship not merely obsolete versions, but versions actually past their end-of-life, so that they are not really supported upstream anymore. They have a similar issue with Python and other languages. So, reluctantly, about a decade ago, we started building our own toolchain. First with Perl, then adding in Python, Julia, R, Octave, and other analytics codes. Our analytics tools use all of these as part of our SIOS rambooted appliances (http://scalableinformatics.com/fastpath), so we needed the updated toolchain. We are looking at Rust as well for future work, and have looked at incorporating Go, but we don't have any Go code developed/planned as of yet.
What's microservice-specific about that post? It's mostly about pretty standard perl packaging and deploying, most of which would apply to monolithic equally well (even more so, if your dividing line is DarkPAN-backed modules and not HTTP-isolated (micro-)servers).
You are absolutely right! The post's equally relevant to a monolithic setup as well. In such a setup, a code artifact (as mentioned in the post) will probably just be a script or a library (now I include a service too). A toolset like this is a good-to-have for a monolith but a pre-requisite for micro-services (if you want to reuse code as much as possible i.e.), I feel. The post has been written from a micro-service…
So I'm always interested in the more specific approaches to communication and storing data when it comes to microservice architecture, which might be an idea for a sequel article ;)
It surprises me Perl isn't dead yet - in fact, German Bundeskriminalamt built a website for people having information about the German nazi hool riots during the France EM 2016 in Perl: https://www.bka-hinweisportal.de/
Why would this surprise you? Perl continues to improve and is battle tested. More Perl is written today than ever before (that said, much more software in general is written than ever before, and there is no doubt Perl's share has declined). Particularly if you're doing lots of text processing Perl remains a great choice.
https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292...
It surprises me Perl isn't dead yet - in fact, German Bundeskriminalamt built a website for people having information about the German nazi hool riots during the France EM 2016 in Perl: https://www.bka-hinweisportal.de/
Perl is bundled with many linux distributions and is a hard dependency for many popular programs. It isn't going away.
And upgrading that might risk incompatible system services, which is why sysadmins usually have way fewer problems adding something like Perl or Python. Isolated language environments (cf. perlbrew) are a nice solution to this, at least until you happen upon a particular paranoid admin.
This is one of the first articles that clearly and consistently lays out the actual concrete benefits of microservices instead of the cargo cult Medium drivel that usually plagues the ecosystem. (Of course, these are still only arguments for SOA and there's no clear differentiation between SOA and microservices, because there is none.)