hi Dana
On Thu, Dec 23, 2010 at 12:51 AM, Dana <[email protected]> wrote: > Subramanyam, thanks for the response. > > In regard to 3, I am not clear why it would be a good idea to add in > model fields for things you *think* you might want some day. > > I would think that using Django South or something similar to create > SQL migrations for your model after a change would be a cleaner > solution... I don't like the idea of adding fields to a model that I > will not use right away as it adds cruft and complexity to my models > and makes it so determining what is being used and what is not more > difficult. Also, since you would be planning for the future, there is > a good chance things will change so much that it would render those > fields obsolete or inaccurate. > My point exactly is to lessen the changes that one may want to say I can do them later and that ends up being a daunting task later ( personally we have re factored much of the code that way) The fields I mentioned are mostly relation for tables that would be part of your project but which are required to be implemented later South is a good tool, but my point is its better not to get to the point that we have to use South ( Invariably we end up with that its a different case ) Regarding changes of DB, we dont want to predict that there may be many changes, that I dont know now, instead I feel it should be "I have estimated all of the project`s DB schema now as per the features and dont need anymore unless the features are completely changed - Subramanyam > > Do you use PIP, virtualenv or any of the other tools I mentioned in my > first post? > > Cheers > > On Dec 22, 11:12 am, Subramanyam <[email protected]> wrote: > > Hi > > > > After working on couple of big projects I felt the best way to start on > > django once you have the basic setup ready is > > > > 1.) Have a complete list of the features into your requirement documents > > if its not possible and you want a agile development methodology > split > > into features that makes sense w.r.t sub-releases > > > > 2.) understand what all external django apps you may need and go through > > their documentation as well > > > > 3.) Create the db model as completely as possible i.e include any future > > fields that you need, or you feel could be important for you project, > > addressing in the first go would be great > > ( I messed up DB modelling and I had to redo quite some ) > > > > 4.) Start working on the views page by page w.r.t the requirement > > > > 5.) Have the unit test case after you are done ( or even before you > develop > > if you are using TDD model ) > > > > 6.) once you feel complete then go for selenium , deployment automation, > ... > > and the rest > > > > Subramanyam > > > > On Thu, Dec 23, 2010 at 12:10 AM, Dana <[email protected]> wrote: > > > I've been bashing my head against a wall lately trying to determine > > > the best (highly subjective, I know) workflow for developing Django > > > projects. > > > > > What I have gathered so far is: > > > > > * Buildout -- For building and packaging your projects. > > > * Fabric -- For easy deployment/testing of code on devel/staging/ > > > production servers > > > * PIP -- For installing Python packages into your project. > > > * virtualenv -- For creating an isolated Python environment. > > > > > ... but what I am having trouble figuring out is how the workflow > > > should be between these tools. > > > > > * What's the relationship between PIP and buildout in development vs. > > > deployment? > > > * Is buildout used solely for installing/packaging stuff for > > > deployment? > > > * Do you use fabric to run buildout on a server? > > > * What role does PIP requirements file play in all this? Is it used? > > > * Are you using setuptools or distribute? > > > > > I know this is a very broad and subjective topic but I'd love to hear > > > what you guys and gals are doing out there to develop rapidly and to > > > deploy efficiently and predictably. > > > > > Cheers > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Django users" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<django-users%[email protected]> > <django-users%[email protected]<django-users%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/django-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<django-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en.
