- Requirements for a project development system
I realize that my previous message was slightly inflammatory. In an effort to be constructive, here is my minimum set of requirements for any project development system: 1. The source code should be represented as plain ASCII files. 2. All required actions must be automatable. Corollaries to requirement 1: you can edit source files with your favorite editor, diff them, and store them in your favorite source code control package. By "source code" I mean all the information you create for your project: C, Python, HTML, documentation, whatever. If there is meta-data that is required to make your project work, it should be stored in a human-readable form as well. An example of this might be permissions on files, which would be stored in the form of a Makefile rule that sets the permissions.. Corollaries to requirement 2: you must be able to build and maintain your project with command-line tools. Being able to use a GUI or a web page to do things is great, but there is no substitute for the UNIX way. Windows NT is a good counter-example to this rule. Here are some examples of project tasks that are facilitated by these basic two requirements: - I want to be able to take a snapshot of my whole project that I can roll back to at a future date. - I want one team of people to work on part of the project independently without clobbering what another team is doing. - I need to look at the diffs between yesterday's version of the project and today's version to figure out what person X did. - I want to set up an automated task to check out the latest version of the project from source control and build it on a test machine. Having said all this, there are times when I break my own rules. I am using a GUI builder right now that creates a binary file describing the UI component layouts for a window. I'd rather it represented the data in an ASCII format, but it's sufficiently useful that I'll put up with it. Also, each window is stored in a separate file, so that tends to limit the possibility of two people needing to change the same file at the same time. Your mileage may vary, of course. But I have found these principles to be useful. --Curtis
On Wed, Dec 30, 1998 at 09:45:09AM -0800, Curtis Galloway wrote:
I realize that my previous message was slightly inflammatory. In an effort to be constructive, here is my minimum set of requirements for any project development system:
I'll say this up front, which is that if you have hard and fast rules about how things must behave to be "usable" and a system doesn't mean those rules, why don't you just move on, rather than trying to spin the world into your own orbit? THis isn't an attack, just an observation... many people have their own views and they're all equally valid, but that doesn't mean there's only one...
1. The source code should be represented as plain ASCII files.
I'd modify this to: "The source code must be accessible as plain ASCII".
2. All required actions must be automatable.
This is very vague... I could write a program today that used HTTP to do all the things you need to do through it... but I agree that Zope needs lots of work in this area
Corollaries to requirement 1: you can edit source files with your favorite editor, diff them, and store them in your favorite source code control package.
This will probably NEVER be doable, even Emacs stumbles over various VC models... I don't want to end up supporting RCS, CVS, SCCS, CodeSafe, SourceSafe, and about 20 others that I've used/seen...
By "source code" I mean all the information you create for your project: C, Python, HTML, documentation, whatever. If there is meta-data that is required to make your project work, it should be stored in a human-readable form as well. An example of this might be permissions on files, which would be stored in the form of a Makefile rule that sets the permissions..
Um, is it me or are you generalizing Zope out to full version control and project management for everything known to mankind? It's intended to manage objects, period, some objects are DTML, some are Python, some are all kinds of things... but I've never seen one for C.
Corollaries to requirement 2: you must be able to build and maintain your project with command-line tools. Being able to use a GUI or a web page to do things is great, but there is no substitute for the UNIX way. Windows NT is a good counter-example to this rule.
I agree that there need to be CLI interfaces to shoving thigns into the object database, and getting them out. BUT, there's nothing saything that the following options aren't 100% valid and workable, if you're willing to make slight compromises: 1. FTP access 2. Theoretically you could build a VFS interface and MOUNT the object database. I did this once with Versant, it is possible.
Here are some examples of project tasks that are facilitated by these basic two requirements:
- I want to be able to take a snapshot of my whole project that I can roll back to at a future date.
This is doable currently, though perhaps not well documented.
- I want one team of people to work on part of the project independently without clobbering what another team is doing.
How do the current draft and session management tools fail at this?
- I need to look at the diffs between yesterday's version of the project and today's version to figure out what person X did.
This needs to be available, it's just a matter of grabbing the revs and diffing them.
- I want to set up an automated task to check out the latest version of the project from source control and build it on a test machine.
Um, what does this have to do with Zope? I'm confused, all this seems more concerned with software development than website, and while there some of the former in the latter, they're not fully inclusive of their requirements. I don't expect one widget to do everything for me. I do my Product development in RCS, even though the website uses the Zope databse to storee things in. I'm just affraid you've made this a MUCH larger issue than it is. Chris -- | Christopher Petrilli | petrilli@amber.org
On Wed, 30 Dec 1998, Christopher G. Petrilli wrote:
This will probably NEVER be doable, even Emacs stumbles over various VC models... I don't want to end up supporting RCS, CVS, SCCS, CodeSafe, SourceSafe, and about 20 others that I've used/seen... That's why storing the website as a file tree is so nice :)
Most of the tools one wants to use know how to deal with file trees :)
By "source code" I mean all the information you create for your project: C, Python, HTML, documentation, whatever. If there is meta-data that is required to make your project work, it should be stored in a human-readable form as well. An example of this might be permissions on files, which would be stored in the form of a Makefile rule that sets the permissions..
Um, is it me or are you generalizing Zope out to full version control and project management for everything known to mankind? It's intended to manage objects, period, some objects are DTML, some are Python, some are all kinds of things... but I've never seen one for C. Nope. He just states ``sane'' requirements for doing projects. It's more or less the same as with SQL. I personally detest SQL, and many collegues working in the sector hate it too. After using BoboPOS for a small project, and my experiences with it, I just sounded one question to my collection of SQL haters: Where would they store legally important (for example invoices, etc.) data. Funny thing, every one of them admitted that he would store it in a good proven SQL server, and wouldn't even consider a OODB.
Having been in a philosophical mood then, I thought a bit, and discovered, that the full integration of data and code in OO programming is not right for certain data, especially when the client is required to keep the data longer (by law) than he will probably keep his hardware and software. (Doctors for example have to keep their records here around for 10 years safeguarded, ..., accounting stuff must be kept for 7 years, etc. That are time spans, that in the fast moving IT world nowadays can mean that there will be more than one software that will have to access the same data: Basically, the data scheme and data itself is much more static than even software. In some cases this leads to ``new'' mainframe sales nowadays: Nobody knows how the data is structured (and what implicit assumptions are in the code/data), nor can anybody really understand the software, so when the hardware breaks, new (exactly the same) hardware is bought as a replacement.)
Corollaries to requirement 2: you must be able to build and maintain your project with command-line tools. Being able to use a GUI or a web page to do things is great, but there is no substitute for the UNIX way. Windows NT is a good counter-example to this rule.
I agree that there need to be CLI interfaces to shoving thigns into the object database, and getting them out. BUT, there's nothing saything that the following options aren't 100% valid and workable, if you're willing to make slight compromises: See above. Certain data must be as freely as possible available. And BoboPOS implies: a) that the live production data is locked in somewhere. b) that there certain things done that are badly mappable to a filetree. (Easy one: How do you express references to the same object? symlinks? Wrong answer, because there is no master reference all references are the same. hardlinks? Wrong answer, how do you hardlink directories, ... ) And there are many other things like this.
1. FTP access 2. Theoretically you could build a VFS interface and MOUNT the object database. I did this once with Versant, it is possible.
Here are some examples of project tasks that are facilitated by these basic two requirements:
- I want to be able to take a snapshot of my whole project that I can roll back to at a future date.
This is doable currently, though perhaps not well documented.
- I want one team of people to work on part of the project independently without clobbering what another team is doing.
How do the current draft and session management tools fail at this?
- I need to look at the diffs between yesterday's version of the project and today's version to figure out what person X did.
This needs to be available, it's just a matter of grabbing the revs and diffing them.
- I want to set up an automated task to check out the latest version of the project from source control and build it on a test machine.
Um, what does this have to do with Zope?
Exactly *g*
I'm confused, all this seems more concerned with software development than website, and while there some of the former in the latter, they're not fully inclusive of their requirements. I don't expect one widget to do everything for me. I do my Product development in RCS, even though the website uses the Zope databse to storee things in.
I'm just affraid you've made this a MUCH larger issue than it is.
Not really. The problem is that some people consider website development as software development, especially if you go further than a couple of nice static webpages. Now if you just want static webpages, than you can stay with a standard webserver, right? Proven software. Now if you do develop some code, you'd better treat it as a software developement project. And SQL queries are to classified as code. (I've seen projects where the SQL ``programmer'' that supplied about 10 queries was better paid than the programmer who did all the grunt work.) Oops, Zope now does SQL, right? So Zope better meet the same ``sane'' requirements for software development. The problem here is, that for most projects the maintenance is the deciding factor. Sometime you can bring in ``exotic'' solutions like Python through arguments like productivity, price, etc., sometimes it just doesn't matter that our solution will be: 1.) quicker to deploy, 2.) cheaper, 3.) more stable, etc., just because the client never heard of python and doesn't know anybody else around here who could maintain python code. Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
One of the things that have been mentioned as a "requirement" is using your favourite text editor to edit the DTML files and then immediately being able to reload the document in a browser and see the results. If Zope supports a standard FTP protocol (I'm not considering security here...) then this could be as simple as using the ange-ftp-mode, no? It would be as simple as editing the file /admin@thezopeftpserver:some/object/with/dtml and ange-ftp-mode would take care of the get'ing and put'ing for you: To you it would seem like you just loaded it (C-xf) and saved it (C-xs). It seems like a brilliant solution to me :) (Of course, it doesn't do away with the security problem -- maybe there is some similar solution that is more secure... At least the editor/update-problem is significantly reduced IMHO) -- Magnus Lie Hetland www.pvv.org/arcadia <arcadia@pvv.org>
Hi, Just wanting to emphatically say "Hear! Hear!" to this... I don't mind there being a "binary" file as long as there is a converter to and from an character (preferably ASCII) representation of same... (uuencode, base64 and ilk do not count as I am using the term converter, I want meaningfully diffable stuff... obviously gifs etc may need exclusion unless they are small or some other criteria...). Curtis Galloway wrote:
1. The source code should be represented as plain ASCII files.
2. All required actions must be automatable.
... [snipped... and all that follows from these] ...
--Curtis
-- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
participants (5)
-
Andreas Kostyrka -
Christopher G. Petrilli -
Curtis Galloway -
LD Landis -
Magnus Lie Hetland