Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^7: Emailing Passwords? In 2020?

by marto (Cardinal)
on Nov 16, 2020 at 09:37 UTC ( [id://11123685]=note: print w/replies, xml ) Need Help??


in reply to Re^6: Emailing Passwords? In 2020?
in thread Emailing Passwords? In 2020?

The Mojo homepage does a good job of pointing out some of the highlights, and linking to others.

  • An amazing real-time web framework, allowing you to easily grow single file prototypes into well-structured MVC web applications.
    • Everything you need to build cloud-native web applications for state of the art container environments.
    • Powerful out of the box with RESTful routes, plugins, commands, Perl-ish templates, content negotiation, session management, form validation, testing framework, static file server, CGI/PSGI detection, first class Unicode support and much more for you to discover.
  • A powerful web development toolkit, that you can use for all kinds of applications, independently of the web framework.
    • Full stack HTTP and WebSocket client/server implementation with IPv6, TLS, SNI, IDNA, HTTP/SOCKS5 proxy, UNIX domain socket, Comet (long polling), Promises/A+, async/await, keep-alive, connection pooling, timeout, cookie, multipart and gzip compression support.
    • Built-in non-blocking I/O web server, supporting multiple event loops as well as optional pre-forking and hot deployment, perfect for building highly scalable web services.
    • JSON and HTML/XML parser with CSS selector support.
  • Very clean, portable and object-oriented pure-Perl API with no hidden magic and no requirements besides Perl 5.26.0 (versions as old as 5.16.0 can be used too, but may require additional CPAN modules to be installed)
  • Fresh code based upon years of experience developing Catalyst, free and open source.
  • Hundreds of 3rd party extensions and high quality spin-off projects like the Minion job queue.

Recent examples here using Mojo and its components include Apache Pulsar modules (Super Search for more), things like Minion are very powerful (see REST API with SFTP Pooling for a recent example use case). You personally may have no need for any of this, but rolling your own framework us unlikely to be as scalable or easily adoptable for others, which is important given the context of the discussion.

Replies are listed 'Best First'.
Re^8: Emailing Passwords? In 2020?
by Bod (Parson) on Nov 16, 2020 at 12:47 UTC

    As always, I am very thankful for the information and for your insights.

    You personally may have no need for any of this, but rolling your own framework us unlikely to be as scalable or easily adoptable for others, which is important given the context of the discussion

    Yes exactly. I run a small company where our websites are an integral part of what we do but are not our core business. We have half a dozen different sites which use common code for dealing with all the grunt work of what we need to do - decypher form data, check session cookies, encode passwords, send emails, upload files, etc. Each site generally has subroutines to produce the common parts of the page such as the header, footer, standard Javascript, CSS, etc and then there is a bespoke lump of code that does whatever that page is supposed to do.
    For this, I really do not see any need for a framework and certainly nothing to be gained from converting existing code to utilise a framework.

    But, I am the only person maintaining my code...nobody else needs to understand it or contribute to it. Having said that, I plan to employ a developer soon to free up some of my time and I'm aware they need to have some clues of what each bit of code is supposed to do. I think everything is adequately commented to give them a starting point!

    Whilst I sort of see the benefits of utilising a framework, it still strikes me that it also has the effect of an anchor on development. If, as you say, the reason this site looks and operates like something from several decades ago is because of the framework being used, that is hardly a good promotion.

      The barrier for entry for the old codebase this site is based on is the problem, at the time in the 1990s it made sense to do things in the way they were done, I won't go into the gory details, feel free to do some digging. Your statement "Surely here should be a showcase for all the wonderful things Perl and its programmers are capable of in the modern world." is IMHO true, but unlikely to happen should a widely used modern framework not be utilised, and we certainly wouldn't improve anything in terms of participation if we used code someone had written from scratch on their own, this I feel strongly would not gain any developers with sufficient spare time to make any improvements. Most perl developers I know don't use these old technologies on a daily basis anymore, and even removing all of the barriers for participation are unlikely to do so in their spare time I feel. They use modern frameworks, making life easier on themselves and getting more done, faster. If you look at the legacy CGI.pm documentation, and associated historical records, people rolling their own way of doing things is often fraught with errors they just didn't consider, sometimes resulting in security or other issues they may not even be aware of.

      You make a good point about being the only developer of your current system. Obviously if what you have works for you, and your business, fine, there's obviously no reason to reimplement that. However, consider the Bus_factor. Should you win the lottery or for some other reason never return to work your employer would be in a situation where they had a codebase that nobody was familiar with, rather than some standard framework they could just reach out to the employment/consulting market with. This is often highlighted as a business risk.

      For clarity the purpose of my reply is not to try and convince you to rewrite your life work in a modern framework, rather to address what I see as the main stumbling blocks for progressing this site, in line with the valid points you've raised. While I would encourage a modern framework like Mojo as it is a feature-full, performant solution to a wide variety of problems (not just web sites). This is why modern frameworks is important to the future development of this site. The fact that there are so few active developers (pmdev) of the existing method, while more modern, easier to work with, faster, saner ways of doing things exist is the base argument for changing framework.

      I have professional experience of being reimplementing legacy systems in modern frameworks, and they make development trivial, add features that would be very difficult (and costly in terms of time) to implement or simply didn't exist, while being much faster in terms of performance.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11123685]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (6)
As of 2024-03-19 09:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found