OK, Squeakers,
I'm in a situation where I can see myself being poised to suggest a language tool for an upcoming iteration of a retail product. It's a ways off, but it is, I think, inevitable. We are currently using an Access-like tool to develop the application, which has around 200 different tables and screens. It also has many variants. From a design standpoint, it cries out for object-orientation, but of course, we have bupkus as far as genuine OO tools at hand.
I'm considering suggesting Squeak (or any Smalltalk) as the platform but there are a few issues, some more easily resolvable than others. I'd like to hear some ideas on this:
-> The lure of the Access-like tools is the fact that any moron can design a table or set and then create a form or grid based on said table. Forms generally need a lot of massaging and re-formatting so they're not a huge deal, but I've seen no grids. Having built a few grids in my day I'm not keen on building more.
-> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.)
-> Right now the bosses are concerned with the fact that the app doesn't look like a "normal Windows app" that people are used to. I'm aware of the problems and solutions to this in Squeak, but I also suspect this will be a non-issue shortly. MS seems to have abandoned Win32.
-> The web-based squeak stuff--not Seaside, but the plug-in--makes it appear as though any squeak application can be put on the web with a flick of a switch (I suppose especially if the data storage is handled correctly). I am somewhat concerned about interoperability between Squeak and .NET/J2EE Thoughts?
Thank you, kind folk, in advance.
===Blake===
Am 27.11.2004 um 09:48 schrieb Blake:
-> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.)
Monticello should be very good for managing the code of 4-5 developers. Much better then changesets.
I am somewhat concerned about interoperability between Squeak and .NET/J2EE Thoughts?
for .net there is a .net bridge http://www.saltypickle.com/SqueakDotNet
Marcus
Am 27.11.2004 um 18:32 schrieb Marcus Denker:
Am 27.11.2004 um 09:48 schrieb Blake:
-> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.)
Monticello should be very good for managing the code of 4-5 developers. Much better then changesets.
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
- Bert -
On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg bert@impara.de wrote:
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
Yes, that's how I work as well. It's somewhat telling that the only packages I know of that use the dependency system extensively, OmniBrowser and Chuck, are essentially single-developer projects; for team use, I think my dependency implementation has failed. It's an open question as to how to improve it, and patches are certainly welcome. Speaking of which:
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
Yeah, I'm sorry that I haven't gotten around to integrating these enhancements yet. Real Soon Now ;).
Avi
It's probably worth noting that this is also how people tend to use Store with VW. Nested bundles become un-wieldy so people tend to use a single bundle that acts as a sort of versioned configuration (they have a defined load order). People then tend to use scripts to grab the latest versions of packages in a bundle and that represents the tip development version. To compare with Envy, this is like an open config map with an implicit release (i.e. when you publish a new version of a package, it is implicitly part of the tip version to the bundle). It's still difficult to manage if you have multiple versions of a bundle that are under active and parallel development, but it's not terrible (you have to explicitly update and publish the branch configurations, which generates a lot of useless intermediate versions of the bundle).
Perhaps Monticello could use a couple different types of configurations:
- one where the config specifies exact package versions - one where the config specifies only the package name and the latest version of a given package is always grabbed - one that looks at other meta data associated with the package to determine which to load (such as the latest version with a given tag)...this could be used to better manage concurrent developement streams - one that is completely pluggable with respect to the algorithm used to determine what version of a package is to be loaded (or these could just be new subclasses on an abstract config that people come up with)
Only the first type would be a concrete and unchangeable specification of exact packages and versions. From the other types, you could generate a concreate config (a kind of snapshot of the state of a given config at a point in time). Envy deals with this by having open editions (but you still must explicitly release things in an open edition). I think you could get more mileage by separating these envy concepts (a version vs open edition) such that you can now have configs that are based on some version selection algorithm, and other configs that are an exact specification of package versions.
I agree that pre-requisites are not very useful beyond their documentation value (although, I think in the context of a modular system, pre-requisite specs would be useful...they would serve as a kind of declaration of required bindings that would need to be satisfied before a package could become operational).
- Stephen
Avi Bryant wrote:
On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg bert@impara.de wrote:
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
Yes, that's how I work as well. It's somewhat telling that the only packages I know of that use the dependency system extensively, OmniBrowser and Chuck, are essentially single-developer projects; for team use, I think my dependency implementation has failed. It's an open question as to how to improve it, and patches are certainly welcome. Speaking of which:
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
Yeah, I'm sorry that I haven't gotten around to integrating these enhancements yet. Real Soon Now ;).
Avi
hi steven
this is really interesting. Thanks for sharing that with us.
It's probably worth noting that this is also how people tend to use Store with VW. Nested bundles become un-wieldy so people tend to use a single bundle that acts as a sort of versioned configuration (they have a defined load order). People then tend to use scripts to grab the latest versions of packages in a bundle and that represents the tip development version.
Do you know one bundle on store that contains such a kind of scripts ;))
To compare with Envy, this is like an open config map with an implicit release (i.e. when you publish a new version of a package, it is implicitly part of the tip version to the bundle). It's still difficult to manage if you have multiple versions of a bundle that are under active and parallel development, but it's not terrible (you have to explicitly update and publish the branch configurations, which generates a lot of useless intermediate versions of the bundle).
Perhaps Monticello could use a couple different types of configurations:
- one where the config specifies exact package versions
- one where the config specifies only the package name and the latest
version of a given package is always grabbed
- one that looks at other meta data associated with the package to
determine which to load (such as the latest version with a given tag)...this could be used to better manage concurrent developement streams
- one that is completely pluggable with respect to the algorithm used
to determine what version of a package is to be loaded (or these could just be new subclasses on an abstract config that people come up with)
Only the first type would be a concrete and unchangeable specification of exact packages and versions. From the other types, you could generate a concreate config (a kind of snapshot of the state of a given config at a point in time). Envy deals with this by having open editions (but you still must explicitly release things in an open edition). I think you could get more mileage by separating these envy concepts (a version vs open edition) such that you can now have configs that are based on some version selection algorithm, and other configs that are an exact specification of package versions.
I agree that pre-requisites are not very useful beyond their documentation value (although, I think in the context of a modular system, pre-requisite specs would be useful...they would serve as a kind of declaration of required bindings that would need to be satisfied before a package could become operational).
I agree with you. It seems that pre-requisite specs are really important to understand how several packages work together and for example should be managed all together (removed for example from a config map) but on the other hand you do not want to have a propagation of changing versions. So what is your practices/advices with that?
Stef
- Stephen
Avi Bryant wrote:
On Sun, 28 Nov 2004 14:15:15 +0100, Bert Freudenberg bert@impara.de wrote:
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
Yes, that's how I work as well. It's somewhat telling that the only packages I know of that use the dependency system extensively, OmniBrowser and Chuck, are essentially single-developer projects; for team use, I think my dependency implementation has failed. It's an open question as to how to improve it, and patches are certainly welcome. Speaking of which:
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository.
http://mail.wiresong.ca/pipermail/monticello/2004-November/ 000112.html
Yeah, I'm sorry that I haven't gotten around to integrating these enhancements yet. Real Soon Now ;).
Avi
stéphane ducasse wrote:
Do you know one bundle on store that contains such a kind of scripts ;))
Actually, no, but I'm guessing that you've published one...what is it called?
I agree with you. It seems that pre-requisite specs are really important to understand how several packages work together and for example should be managed all together (removed for example from a config map) but on the other hand you do not want to have a propagation of changing versions. So what is your practices/advices with that?
Stef
Woefully in-adequate I guess. ;) Given the lack of modularity in the Smalltalk system and how difficult that issue is to tackle, I've temporarily resolved myself to dealing with Smalltalk as it is rather than as I wish it were. In that context, I'm happy if I have configs that load cleanly from some base image (I don't care about unloading or having multiple configs loading in a single image). I then use multiple configs and images to manage clusters of packages that should be managed together (where the configs may have overlapping sets of packages). It's a simple solution that works for my immediate needs given the lack of modularity, namespaces, etc in Smalltalk. Of course, that solution is entirely in-adequate for other purposes (i.e. if you're building a worldwide interconnected object system).
- Stephen
hi Bert
have you experience using "config map" ie instead of using dependencies between packages and having to chanage them all when one deep down change, using one flat structure: one package telling which version of its components to load when it is loaded.
We are experimenting with that kind of flat structure for the dev of SW2 but we do not have enough experience. The dependency approach seems to fail (when we use it for our environment in VW).
Ned told me that we should not nest maps since we may have two maps willing to load two different versions of the same package and get stuck :)
Stef
Your extensions look cool.
Am 27.11.2004 um 18:32 schrieb Marcus Denker:
Am 27.11.2004 um 09:48 schrieb Blake:
-> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.)
Monticello should be very good for managing the code of 4-5 developers. Much better then changesets.
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/000112.html
- Bert -
have you experience using "config map"
Not me personally, but Michael seems quite fond of them ;-)
We have not yet tried to use MC in that way, but we likely will.
- Bert -
Am 28.11.2004 um 15:34 schrieb stéphane ducasse:
hi Bert
have you experience using "config map" ie instead of using dependencies between packages and having to chanage them all when one deep down change, using one flat structure: one package telling which version of its components to load when it is loaded.
We are experimenting with that kind of flat structure for the dev of SW2 but we do not have enough experience. The dependency approach seems to fail (when we use it for our environment in VW).
Ned told me that we should not nest maps since we may have two maps willing to load two different versions of the same package and get stuck :)
Stef
Your extensions look cool.
Am 27.11.2004 um 18:32 schrieb Marcus Denker:
Am 27.11.2004 um 09:48 schrieb Blake:
-> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.)
Monticello should be very good for managing the code of 4-5 developers. Much better then changesets.
Yes, we're using it now in a project of that size. MC is quite usable now. You might want to make many smaller packages without dependencies, otherwise merging is really slow, and you get a lot of useless versions even though only the prerequisites changed. Instead, we just load the newest version of each package, which works fine in a small team where we can immediately sort out any problems.
I posted a couple of enhancements for supporting this style of work to the MC list. In particular, packages are highlighted which have a newer version available in the repository. http://mail.wiresong.ca/pipermail/monticello/2004-November/ 000112.html
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Bert Freudenberg -
Blake -
Marcus Denker -
Stephen Pair -
stéphane ducasse