Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re^8: Emailing Passwords? In 2020?

by Bod (Parson)
on Nov 16, 2020 at 12:47 UTC ( [id://11123686]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^9: Emailing Passwords? In 2020?
by marto (Cardinal) on Nov 16, 2020 at 13:09 UTC

    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://11123686]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (4)
As of 2024-03-19 07:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found