Re: [BangPypers] Can two django projects be made to communicate to each other
Your apache config can be something like this Location /path1/ SetHandler python-program PythonHandler django_project_1_frontend PythonInterpreter django_project_1 PythonOption django.root /path1 SetEnv DJANGO_SETTINGS_MODULE apps.settings PythonDebug On PythonPath ['C:/Projects/toolsforagile_common/Scripts'] + sys.path SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \ \.(?:exe|t?gz|zip|gz2|sit|rar)$ no-gzip dont-vary /Location Location /path2/ SetHandler python-program PythonHandler django_project_2_frontend PythonInterpreter django_project_2 PythonOption django.root /path2 SetEnv DJANGO_SETTINGS_MODULE apps.settings PythonDebug On PythonPath ['C:/Projects/toolsforagile_common/Scripts'] + sys.path SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \ \.(?:exe|t?gz|zip|gz2|sit|rar)$ no-gzip dont-vary /Location This will redirect /path1 requests to django_project_1_frontend.py and /path2 to django_project_2_frontend.py The PythonInterpreter lines ensure that Apache will create two separate python instances for each project. The django_project_x_frontend.py you will need to hook up to the django project, like this import site site.addsitedir(... add a python paths here) site.addsitedir(... add a python paths here) from django.core.handlers.modpython import handler The way we have configured the layout is that each project is running in its own virtual environment (using virtualenv). So the site.addsitedir lines will add the virtualenv paths to before calling the django mod_python handler. This way both projects can have their own libraries and site-packages and won't interfere with each other. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
Refactoring just means changing the internals without adding/removing functionality. The book is good, but refactoring can be applied in many other contexts too. It has been happening long before the book came out. The big insight in the book is not the refactoring patterns themselves. The big insight is that its possible to make fairly large changes using small steps where the application does not break at any of the intermediate steps. It changes your thinking from I need to rewrite retest to go from A - B, now its like how can I go there in small steps without breaking anything in the middle. Unless you plan to keep rewriting your app everything a change comes along, I do agree that a self respecting developer needs to know refactoring (the concept, not the book) Refactoring myths - - If I write perfect code the first time, then I don't need to refactor: Wrong! Requirements change, and then your perfect code is no longer suitable, so you'll have to go in and change the design before you can implement new functionality. Thats refactoring. - Refactoring means cleaning up bad code: Wrong! See above. - Refactoring is only for OO code: Wrong! You can refactor anything, even imperative of functional programs. I have used refactoring (including some patterns from the book) on C programs. - I have not seen refactoring used on open source projects: Wrong! At least on the django project refactoring occurs _very often_ to support new functionality. When multiple database support was introduced, the ORM design (which only supported single database) was refactored without changing existing functionality. After that the multi-database feature was added. Django has a policy of having unit tests for _all_ functionality, just to support easy refactoring. I'm pretty sure it happens in all large projects. - Refactoring is only for code. Wrong! We recently released a second product which sits along with our first one, and it required completely changing the architecture of the first one - we refactored the architecture to support the new product over 3 months deploying small changes at a time. Architecture changes, server configurations, database structure - everything was changed making small changes every week on a running production system with no downtime - thats refactoring too. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On Sun, Dec 5, 2010 at 3:03 PM, Siddharta G siddharta.li...@gmail.comwrote: Refactoring just means changing the internals without adding/removing functionality. The book is good, but refactoring can be applied in many other contexts too. It has been happening long before the book came out. The big insight in the book is not the refactoring patterns themselves. The big insight is that its possible to make fairly large changes using small steps where the application does not break at any of the intermediate steps. It changes your thinking from I need to rewrite retest to go from A - B, now its like how can I go there in small steps without breaking anything in the middle. Unless you plan to keep rewriting your app everything a change comes along, I do agree that a self respecting developer needs to know refactoring (the concept, not the book) Refactoring myths - - If I write perfect code the first time, then I don't need to refactor: Wrong! Requirements change, and then your perfect code is no longer suitable, so you'll have to go in and change the design before you can implement new functionality. Thats refactoring. - Refactoring means cleaning up bad code: Wrong! See above. - Refactoring is only for OO code: Wrong! You can refactor anything, even imperative of functional programs. I have used refactoring (including some patterns from the book) on C programs. - I have not seen refactoring used on open source projects: Wrong! At least on the django project refactoring occurs _very often_ to support new functionality. When multiple database support was introduced, the ORM design (which only supported single database) was refactored without changing existing functionality. After that the multi-database feature was added. Django has a policy of having unit tests for _all_ functionality, just to support easy refactoring. I'm pretty sure it happens in all large projects. - Refactoring is only for code. Wrong! We recently released a second product which sits along with our first one, and it required completely changing the architecture of the first one - we refactored the architecture to support the new product over 3 months deploying small changes at a time. Architecture changes, server configurations, database structure - everything was changed making small changes every week on a running production system with no downtime - thats refactoring too. That is re-architecting or re-designing depending on which side of the conference table you are - not re-factoring. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers -- --Anand ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On Sun, Dec 5, 2010 at 4:07 PM, Anand Balachandran Pillai abpil...@gmail.com wrote: That is re-architecting or re-designing depending on which side of the conference table you are - not re-factoring. Err... Refactoring _is_ redesigning, that is the whole purpose of refactoring. The difference is that traditional rearchitecting/redesiging is taking down the existing design and rewriting the application with a new design. Refactoring is doing it in such a way that you can go from A - B in small steps without breaking the app at any point. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On Sun, Dec 5, 2010 at 4:53 PM, Siddharta G siddharta.li...@gmail.comwrote: On Sun, Dec 5, 2010 at 4:07 PM, Anand Balachandran Pillai abpil...@gmail.com wrote: That is re-architecting or re-designing depending on which side of the conference table you are - not re-factoring. Err... Refactoring _is_ redesigning, that is the whole purpose of refactoring. The difference is that traditional rearchitecting/redesiging is taking down the existing design and rewriting the application with a new design. Refactoring is doing it in such a way that you can go from A - B in small steps without breaking the app at any point. I understand the difference. You mentioned Architecture changes which doesn't belong to re-factoring. In a way, the whole re-writing vs re-factoring thing is a bit blown-up since the answer to the most important question Who throws away an entire piece of code and re-writes it from scratch is Not many, unless the code is highly experimental, a prototype, is a personal project (with not many users), or has hit the critical limit of usability and extensibility in its current state, so that it has to be re-written from scratch. So, most of us do re-factoring or whatever you may want to call it, almost routinely, whether it is at a code, design or architectural level. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers -- --Anand ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
I had sent this reply below earlier ...not sure why it didn't go thru' ...anyways, enough has already been said about this, however, since I already wrote this reply below, I thought I might as well make my point ... Hi Santosh, On 12/04/2010 05:36 PM, Santosh Rajan wrote: My 2 cents on this subject. I think the problem of differing viewpoints is mainly due to the fact that there are two kinds of software development. 1) Software product development 2) Bespoke software development. Let us look at software product development, and let us look at all the top open source software development projects like linux, apache, mozilla etc etc. I have not seen refactoring as described by the book used by any of the open source software products. I would like to know if any one can show me refactoring used in software product development. The very nature of Open Source Software development model is refactoring ! It isn't called that but that's what it is. Try to describe the process of FOSS development and then the way code is affected by refactoring and you would see the similarities. The only difference is in FOSS projects this is done by separate individuals in an unplanned manner -- the net effect from the /code's/ perspective though is that is being refactored. I'd go as far as saying that patches which refactor existing code in mature FOSS products are as at least the same in number as those that introduce new features. cheers, - steve -- random spiel: http://lonetwin.net/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On Sun, Dec 5, 2010 at 11:39 PM, steve st...@lonetwin.net wrote: I had sent this reply below earlier ...not sure why it didn't go thru' ...anyways, enough has already been said about this, however, since I already wrote this reply below, I thought I might as well make my point ... Hi Santosh, On 12/04/2010 05:36 PM, Santosh Rajan wrote: My 2 cents on this subject. I think the problem of differing viewpoints is mainly due to the fact that there are two kinds of software development. 1) Software product development 2) Bespoke software development. Let us look at software product development, and let us look at all the top open source software development projects like linux, apache, mozilla etc etc. I have not seen refactoring as described by the book used by any of the open source software products. I would like to know if any one can show me refactoring used in software product development. The very nature of Open Source Software development model is refactoring ! It isn't called that but that's what it is. Try to describe the process of FOSS development and then the way code is affected by refactoring and you would see the similarities. The only difference is in FOSS projects this is done by separate individuals in an unplanned manner -- the net effect from the /code's/ perspective though is that is being refactored. I'd go as far as saying that patches which refactor existing code in mature FOSS products are as at least the same in number as those that introduce new features. My thoughts (not for or against, but just to add to this thread): - the license of the code doesn't really matter. There are lots of software that we've contributed to as well as developed at Thoughtworks, and we give the same level of attention (including refactoring, testing, CI, etc) regardless of the license. This is true of other companies, and individuals as well. - refactoring need not become a bad word just because some book documents various known refactoring techniques. Martin Fowler is a very, very humble person. I spent the past three days with him hearing him talk to various Thoughtworkers in Bangalore, and he's very honest about giving credit where it's due. If you read his Refactoring book, he's very clear there that these are various techniques that he's observed everyone around him use, and he's simply explained a number of them in very layman terms so that all can understand these together. Let's the case of something like Extract Method. It's very likely that over a period of time, a developer would notice that a method could be spilt up into smaller logical private methods so that the intent is clear to the reader as well as more maintainable. This technique may be given the name Extract Method. And this technique has been applied by all programmers in so many languages. Applying a refactoring does not make us any less a programmer, and this activity need not become an insult. Reading a book that documents various such techniques could be considered a nice refresher even. Speaking about myself, I wouldn't stay away from a book just because someone declared that if one has self-respect, one would read that book. Such a statement need not be an insult. Finally, the loss (in terms of missed opportunity) would be one's own. Refactoring could be applied to any language, regardless of whether it's Object Oriented or not. cheers, - steve -- random spiel: http://lonetwin.net/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers -- == Belenix: www.belenix.org ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
[snip] [dubious aside: remember this one? Please note that there is no deeper meaning to be read into the fact that I mistakenly pasted the quote twice. -Taj. ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On 12/4/2010 5:36 PM, Santosh Rajan wrote [snip] Let us look at software product development, and let us look at all the top open source software development projects like linux, apache, mozilla etc etc. I have not seen refactoring as described by the book used by any of the open source software products. I would like to know if any one can show me refactoring used in software product development. This reminds me of the kind of discussion I used to hear when the GoF Design Patterns book was published. Lacking experience, I was in awe of the book since it codified so much practice that I could look at and go THAT MAKES SO MUCH SENSE. It took years and a lot of experience to understand that this was just a compendium of best practices that many OOP programmers had been applying for decades, taking them so much for granted that they hadn't even bothered to give them names. Unfortunately there were too many people who never saw past it being some sort of bible, so (as an example) you'd have people drop by KDE dev mailing lists 5-6 years later complaining that the KDE libraries were poorly designed because they couldn't go through the code and identify the design patterns by name. This is a pattern that I've seen repeated often over the last twenty years (the Java world is particularly guilty of it). There is unquestionable value to the classification and codification of best practices in software engineering, which has a real paucity of good references of this kind, but it must be kept in perspective of what people are doing. Unfortunately, compared to other forms of engineering it's both more difficult and more given to fads. So what I'm saying is, it is unlikely that this book contains anything that any sufficiently large and long-lived software project (FOSS or otherwise) is not already doing, because it is critical to their success. You will just have to work a little harder to identify it because they may not have bought into your taxonomy of refactoring terms. [dubious aside: remember this one? There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''] -Taj. ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
[dubious aside: remember this one? There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure. http://www.canonical.org/~kragen/tao-of-programming.html for more koans like the one above. Regards, BG -- Baishampayan Ghose b.ghose at gmail.com ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
I sure hope that we don't dismiss the reading of such books just because every experienced programmer knows about refactoring. -- Sriram On 12/6/10, Siddharta G siddharta.li...@gmail.com wrote: Nice quote. You hit the main point: Refactoring has always been done. Everyone does it. The book just gives a taxonomy to common refactorings. For what its worth, I think a taxonomy is very important. It is so much easier to communicate a design by saying this is a factory, that object is an observer to the model and so on. The same way its convenient to say first extract method, then pull up method and everyone understands what you are talking about. But whether you know the names or not, it is important to know how to go from design A to design B in small steps, without breaking the application in between. A typical refactoring step takes less than an hour (some can be as low as a few minutes). You can do a refactoring, commit, do a refactoring, commit and the application is always deployable. -- Siddharta ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers -- Sent from my mobile device == Belenix: www.belenix.org ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
Re: [BangPypers] refactoring
On Mon, Dec 6, 2010 at 10:10 AM, Sirtaj Singh Kang sir...@sirtaj.net wrote: [snip] [dubious aside: remember this one? Please note that there is no deeper meaning to be read into the fact that I mistakenly pasted the quote twice. [...] Man, and here was I thinking that you were killing two birds with one stone: To understand recursion, one must first understand recursion. Regards, Gora ___ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
