[Novalug] Suggestions for web interface?

Howard Buie hbuie112358@gmail.com
Mon Dec 12 18:23:28 EST 2016


Thanks everyone for the great insights. I am going to start with Struts. I
haven't done any serious development at home since I got out of school a
few years ago, so I'll have to get all that set up and going. Then,
properly isolate the model. Most likely, there are more questions coming!

Howard

On Mon, Dec 12, 2016 at 6:12 AM, Ed James via Novalug <
novalug@firemountain.net> wrote:

> I really wish the Perl coders where I used to work had actually followed
> all that advice, but make DOCUMENT THE CODE "first", not last.  The
> environment rewarded devs who got code into production fastest/cheapest,
> but the other group, who had to make live, emergency fixes certainly did
> not reap that "benefit".  OTOH, it helped keep me employed at various
> sites. Code documentation was sparse.  My style is to write "pseudo code"
> (simple English statements of what was being done) first, then head-check
> it out for logic, flow, efficiency, yada.  Then I'd comment it out and
> insert real code (for whichever language I'm working with).  This does slow
> down initial code writing, but "the sooner one starts coding, the longer it
> takes" was a dear lesson to learn.
>
> There was no "official style", since code was written over years by
> different groups. But yes, that would certainly have been of value.  IMHO,
> your list would have made my life "back then" a whole lot smoother, and
> prolly still would for whomever is still there.
>
> The comment about "use strict and use warnings" is well-taken.  I follow
> "paranoid mode" in C++ compiling, looking for any/every warning, and coding
> to avoid even innocuous-seeming warning.  This was something started back
> in Java-coding days, vis-a-vis getting rid of deprecation warnings in
> particular.
>
> EJ
>
> On Sun, Dec 11, 2016 at 8:48 PM, William Sutton <william@trilug.org>
> wrote:
>
> > /me rushes to Perl's defense:
> >
> > It's "Perl", not "PERL".  Not an acronym.
> >
> > I was a full time Perl programmer for over 10 years.  I've seen a lot of
> > people's ugly crappy Perl.  I've refactored most of it.  My last
> > significant Perl codebase was 15k-18k lines of Perl, SQL, PL/SQL, T-SQL,
> > and XML (the last being mostly config), all OO.
> >
> > First thing that helps is perltidy -b -gnu (or whatever other formatting
> > style you like).  The goal is to have a code tidier clean up the obvious
> > ugliness.
> >
> > Second thing that helps is syntax higlighting.  It usually makes obvious
> > quoting issues apparent, and can help break the monotony of monochromatic
> > code :-)
> >
> > Third and fourth essential things, in tandem:  use strict and use
> > warnings.  With most bad code, this immediately breaks everything.
> That's
> > good.  Start explicitly declaring variables and fix anything else that
> > fails to pass a perl -c check.  This also includes getting rid of chains
> of
> > implicit $_ statements.  Use of implicit $_ relies on nothing else
> changing
> > $_, and that's a dangerous assumption (especially in anything threaded or
> > forked).
> >
> > For that matter, the general Perl help advice on threading is "Don't."
> >
> > Once you have finished that stage, and the code still does what it's
> > supposed to, it is time to seriously refactor the code.
> >
> > Figure out appropriate logical divisions, and reimplement them properly.
> > Where you can, use Perl modules or native Perl constructs instead of
> > shelling out.  Where you *must* shell out, verify the output before using
> > it.  Use the taint option for better security.
> >
> > If you can, modularize your Perl with OO.  Perl isn't inherently OO the
> > way Java is, but doing OO Perl can force you to break things out more
> > cleanly than the typical "big ball of mud".  It also allows for better
> code
> > reusability.  Frameworks like Moose help.
> >
> > Find a clean programming style and stick with it.  People will argue
> about
> > formatting and style until the end of time, but be consistent.
> >
> > And last, but certainly not least, DOCUMENT THE CODE.  POD is
> particularly
> > helpful since you can run perldoc on your code and it will render the
> > documentation simlarly to man pages.  This is especially true if you
> follow
> > the JavaDoc style in Perl POD.
> >
> > William Sutton
> >
> >
> > On Sun, 11 Dec 2016, Ed James via Novalug wrote:
> >
> > Too many years spent debugging and fixing OPPPs (Other People's
> >> PERL Programs.  I kinda enjoyed writing PERL programs from scratch,
> >> but really hated reading messy code, especially since much of it was
> >> under "on call duty" during emergencies on live systems.
> >>
> >> I do remember with fondness the O'Reilly "PERL Cookbook" (the Ram
> book?),
> >> among others.
> >>
> >> EJ
> >>
> >> On Sun, Dec 11, 2016 at 7:14 PM, jerry w <jerrywone@gmail.com> wrote:
> >>
> >> What's wrong with Perl?
> >>>
> >>>
> >>> **********************************************************************
> >> The Novalug mailing list is hosted by firemountain.net.
> >>
> >> To unsubscribe or change delivery options:
> >> http://www.firemountain.net/mailman/listinfo/novalug
> >>
> >>
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug
>


More information about the Novalug mailing list