Hey Robert, Thank you for taking the time for your thoughtful responses. The overhead of Django does concern me and as I get more comfortable and have more time for reflection I will definitely re-evaluate. Just getting it up and running was a pretty rough road and I think I hit every pothole on the way. I will also try much harder to denormalize my thinking, I remember studying it a bit a few years ago, something about stars, snowflakes and cubes. In desperate development mode, I tend to stick with data structures programming design that I know. A man's got to know his limitations.
I was under the impression that denormalization was just a technique to improve read times. My applications generally serve a small audience so read performance has not surfaced in the user experience; however, I recognize this is an area I need to grow in understanding. I hate bloated overhead and using modern processor speeds and bandwidth increases as a crutch to hide inefficient code practices. I would love to pass on some of my applications to larger schools or even begin designing applications for larger audiences. Even if I stick with Django as a framework for this project I will be looking at ways to reduce the overhead and increase efficiency. I will read up on TyphoonAE and what it takes to implement a datastore abstraction. If I can still retain decent portability, then greater code efficiency and is reason enough for me to put more effort into understanding webapp2. Thank you again for your guidance! On Aug 11, 12:41 am, Robert Kluin <[email protected]> wrote: > Hi Joshua, > Responses inline. > > On Wed, Aug 10, 2011 at 16:11, Joshua Mulloy <[email protected]> wrote: > > I definitely agree with you on the python vs c markup. > > I just came back to post on my progress and read your post. After reading > > your post, I am not sure I made the right decision (actually using more of > > the Django framework). You sound very opposed to Django. If you are > > willing to share, I would be very interested in your reasons. I found > > I'm not necessarily personally opposed to it, but it carries overhead > which does not always play well on app engine. It is also very heavy > and I find it rather monolithic. I personally prefer lighter, smaller > frameworks. > > > Django-nonrel and two things made me decide to use the model framework. > > First, I really liked the Model syntax. I think it was easier for me to > > understand because they provided the related SQL code in their > > book http://www.djangobook.com/en/2.0/chapter05/. I was very frustrated by > > the lack of comparison examples in Programming Google App Engine. For > > example, instead of just mentioning (page 197) "This technique is similar to > > how you'd use 'join tables' in an SQL database." an actual mapped example > > would probably have made that entire chapter immediately mentally > > digestible. > > The problem with App Engine is that you'll get into trouble by > thinking in terms of SQL. It is not SQL, and your *really* should try > to not think in SQL-like terms. Instead think simple data structures > and denormalize the hell out of stuff, precisely the opposite of > typical RDMS thinking. > > > Second, I like that I can take the code and plop it somewhere else if > > necessary. I got burned from an unexpected limitation in GAS. If I run > > into another road block with GAE, I can take my code and run it on my server > > here with minor adjustment to the code. > > Yeah, that is a bummer. Luckily most of your code will probably be > pretty portable no matter what you choose, worst case you might need > to implement a thin datastore abstraction layer. Or you could use > TyphoonAE! > > > I have basically setup the data model for my app and the Django admin > > interface already has at least as much functionality as the old app. In > > looking at it, I could probably just put that up and give out one login and > > volunteers could start entering data (basically what they had before but > > needed a client). Then I could start "adding" features like: > > users inputting their own data instead of volunteers copying it from a paper > > form. There is still a ton I need to do and better understand. But now, I > > at least have an interface I can show to the PD committee and my boss and > > that is a big relief. I now have a bit more time to plan and consider > > alternatives, time I didn't think I would have this morning. > > Honestly, I can't argue with results. > > Nice to hear you chose Python. :) > > Robert > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To view this discussion on the web visit > >https://groups.google.com/d/msg/google-appengine/-/IyyYM6sSoHcJ. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
