[TriZPUG] web application best practices

[Nathan Rice]

Unit tests are sort of a given (at least one would hope).  If you look
at most of my personal best practices, they directly address making
testing easier :)

I *HATE* most frameworks.  Flask was the first framework-ish thing I
saw that didn't make my stomach turn.  I played with doing development
using werkzeug but I found that the stuff I was doing was fairly Flask
like, and good coders only re-invent the wheel as a last resort.

Nathan

On Fri, Nov 4, 2011 at 1:41 PM, Johnson, Josh <jj at email.unc.edu> wrote:
> Where are these ideas coming from?
>
> I've been doing this for a very long time, and the thing I've learned is that the best practice is one you can adhere to. :)
>
> That said, this is what I'd advise:
>
> - document everything; inline especially.
> - unit test everything. Other tests are highly encouraged, but not strictly necessary. Remember that a web app has a moving target for a platform, and has a lot of moving parts. Test early, test often.
> - separate concerns. This doesn't necessarily mean ajax or mvc or any particular model or pattern. The best choice is what makes items 1 and 2 easier.
> - I mentioned this earlier, but I'll reiterate: the web is a moving target. Try to output browser code (html, js, etc) that works or degrades well in most browsers. Follow the best practices for browser tech, use standards whenever feasible. This can be hard, but the end result is an application that is easier to use and test.
> - don't start with a framework (contraversal, I know, but don't learn the hard way like a lot of us have, especially if you care about best practice). Start with HTTP, CGI/WSGI, and select low-level frameworks that make the protocols easier. Then build up to larger frameworks that make integration or form generation or database persistence or authentication (etc, etc) easier. Remember that a fancy REST framework might seem like its saving you time, but when it breaks, how much time will you loose figuring out how it broke and trying to fix it? Know what the framework is really buying you, not just what bells and whistles you won't have to implement yourself. I'd say the same for client-side stuff, because I like futzing with prototypes and javascript implementational nuances ;)
>
> HTH,
> JJ
>
> ----- Original Message -----
> From: Nathan Rice [mailto:nathan.alexander.rice at gmail.com]
> Sent: Friday, November 04, 2011 11:42 AM
> To: Triangle (North Carolina) Zope and Python Users Group <trizpug at python.org>
> Subject: [TriZPUG] web application best practices
>
> Hi all,
>
> Though I'm not normally a web guy, my job has me doing some web
> related stuff.  As a result, I've been trying to translate standard
> software engineering best practices over as much as possible.  Since
> this is a web-dev heavy group, I'd like to hear from other people
> about what they consider best practices.
>
> My current list of web application specific things...
>
> 1. separate client side and server side cleanly using services.
> 2. avoid generating client specific code on the server as much as possible.
> 3. separate out complex page elements into their own pages, then pull
> them in to a main page with an ajax load.
> 4. Do not put ANY logic in your request handlers.  Just use them to
> collect and validate any URL arguments or post values, manage
> security, then call a separate function and generate a response from
> the result of that.
> 5. Avoid hand coding presentation functions for every class
> separately.  Create middleware layers, and implement functions on
> divergent classes that let the middleware generate the proper results.
>
>
> Nathan
> _______________________________________________
> TriZPUG mailing list
> TriZPUG at python.org
> http://mail.python.org/mailman/listinfo/trizpug
> http://trizpug.org is the Triangle Zope and Python Users Group
> _______________________________________________
> TriZPUG mailing list
> TriZPUG at python.org
> http://mail.python.org/mailman/listinfo/trizpug
> http://trizpug.org is the Triangle Zope and Python Users Group
>