On Apr 19, 12:40 pm, jay graves <[EMAIL PROTECTED]> wrote: > I'm a Django newbie (1 week) but a long time (since early 2000) Python > programmer. > > I have an internal project for work and I'm proposing that we use > Django. > > Here are some general questions that I would like the community's > opinion on. > > 1. I have to use Windows 2003 server due to the fact that I have to > interface with an existing application through ODBC. I'm not tied to > IIS/MSSQL but would probably try to follow the recommendations > athttp://thinkhole.org/wp/django-on-windows/and utilize Apache/ > mod_python/PostgreSQL. This division of the company just upgraded > their infrastructure before I got involved and by default we are a > windows shop. The server I would use is the domain controller and > also runs Exchange. Any red flags here? The number of users is > really small. (<30)
Having gotten my start as a sys admin, I'd raise a tentative red flag on this one. Since you're looking at a relatively small number of users, this may not be as much of an issue if the server has the iron to back this up. But... A PDC + Exchange is already a potential performance hog. Adding on another service (Apache or otherwise) could mean slow response times all around. The PDC might side of it might not suffer as much, but Exchange is a resource hog (and needs every bit it gets), and you may end up slowing down both Exchange and your Django application (whichever way you host it). Is the existing application on Windows using ODBC? If so, you're not necessarily stuck with Windows Server, as there are ODBC solutions for Linux/BSD, meaning you could put the Apache server on a separate piece of iron. All that being said, if the server hardware is fairly modern, and the user base stays level, it should handle it just fine. My only concern is you'd effectively have three different database platforms on one server, two of them backends for potentially resource-intensive services that I don't foresee the company getting rid of. :) The thinkhole.org HOWTO should get you up and running on the services side, either way. > 2. Should I stick with 0.96 or would 'trunk' be OK. I would really > like to use the newforms-admin stuff once it has merged but since I'm > new I'd like some advice. > I've readhttp://www.djangoproject.com/weblog/2007/apr/06/changes/and > since I'm writing brand new code I don't have any backwards compatible > issues to contend with and of course I would be careful when > 'updating' my Django working copy. There are some backwards incompatible issues coming down the pipe from the newforms-admin branch, and some of them aren't documented yet. If you use 0.96, you'll find yourself refactoring a bit when the next release comes out, but it's a safe bet. On the other hand, using trunk means that you have the latest and greatest, and will be able to adjust your code more incrementally, rather than all-at-once, I believe. Lastly, if you used the newforms-admin branch, you should end up with less refactoring in the end, once it's merged into trunk. I've not looked at it intensely, yet, so I could be off base a little on how much refactoring you'll have to do. > The site would need to go 'live' around Aug 1. Any gut feel on how > much 'churn' there will be in the API during now until then. From > everything I've read, Django has tried really hard to minimize API > incompatibilities and personally I'm not that worried about it but > would like some feedback. >From what I've seen over the past couple of years, there isn't a whole lot of "ZOMG, my project is DOOMED!" churn in the API. Most of your update fixes should come in the way of editing a single file when a new backwards-incompatible change comes around, though that's not always the case. The new admin stuff would require model definition changes as well as some minor edits to your url definitions, and some probably others, as some of the differences are not documented yet, as I said before. > This is a very high profile project internally and I'm excited about > using Django/Python. If this initial project goes well, there will be > alot more candidate projects for Django at my company. Getting > justification for the first one is the hardest but once it's an > 'existing' technology it's an easier sell for new projects. My concerns with performance could mean a lot here. The API churn not so much, if you keep up with things and make sure you have a good Test/ QA system in place. If the performance is horrible because of the server you're stuck with, they could blame Django, ruining any chance of it coming up again in the future. I proposed Rails for an application once that was supposed to have dedicated iron - at the last minute, they decided to host is shared. It hurt the performance of the application, and despite my pointing out that the server was already over-loaded before the application went on it, they blamed it entirely on Rails. Granted, Ruby isn't known for its performance, but PHBs rarely blame their expensive hardware when they can blame "new- fangled software". :) After all I've said, it may seem like I'm saying "Django bad!" I'm not - but you're stuck with some constraints that may mean nothing works perfectly for the application. If the server has lots of resources available to it, and they're rarely pegged, Django should perform just fine. > Thanks in advance. > > ... > Jay Graves Hopefully, I've not muddied the waters. :) -- Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
