GemStone code management techniques

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GemStone code management techniques

Gemstone/S mailing list

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin


Check out our new brand campaign: www.ubs.com/together

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
       
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.  The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.  
If verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.

 
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GemStone code management techniques

Gemstone/S mailing list
1)      What tools/editors do you use for writing GS Smalltalk code?
I tend to develop using VisualWorks.  I write my code against the
Sport portabilily library, so my code runs unaltered in GemStone.  My
applications run as a web service within GemStone.

2)      What packaging system do you use for organising your code and
separating out your extensions to core classes from GemTalk Systems'
own code?
I try really hard to not change any shipped code.  So far, I have
never had to modify shipped VW or GS code.  I wrap system code to
achieve what I need (e.g. Sport).

3)      Which version control system do you use, and in what kind of
structure do you store your code (what does one file in your source
code repository represent, if file-based)?  How do you extract a
deployable set of changes from your version control system?
I use Store for my code.  When I deploy I generate one .gs file per package

4)      What mechanism do you use for uploading code to your
production GemStone DB?
I use a GemStone script to file the new code into a new user account
and attach the root of my object model in GS to a name in the name
space of the new user, then I run the code which does any upgrades
needed.


On 4 December 2017 at 14:47, via GemStone-Smalltalk
<[hidden email]> wrote:

> Hi,
>
>
>
> We're interested to know what techniques other GemStone users are using for
> their GS Smalltalk code management and deployment processes, hence a few
> very general questions to anybody inclined to answer:
>
>
>
> 1)      What tools/editors do you use for writing GS Smalltalk code?
>
> 2)      What packaging system do you use for organising your code and
> separating out your extensions to core classes from GemTalk Systems' own
> code?
>
> 3)      Which version control system do you use, and in what kind of
> structure do you store your code (what does one file in your source code
> repository represent, if file-based)?  How do you extract a deployable set
> of changes from your version control system?
>
> 4)      What mechanism do you use for uploading code to your production
> GemStone DB?
>
>
>
> Any feedback much appreciated!
>
>
>
> Thanks and regards,
>
> Martin
>
>
> Check out our new brand campaign: www.ubs.com/together
>
> Visit our website at http://www.ubs.com
>
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mails are not encrypted and cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses.  The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of e-mail transmission.
> If verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities
> or related financial instruments.
>
>
> UBS reserves the right to retain all messages. Messages are protected
> and accessed only in legally justified cases.
> _______________________________________________
> GemStone-Smalltalk mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GemStone code management techniques

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list
Hi,

1) Jade and a little tODE.
2) We add code to GemStone classes as loose methods to GS classes and these loose method belong to Monticello packages.
3) Mostly Github (and Squeak Source (Monticello packages) as backup).
4) GS scripts and/or mcz files.

regards,
bruno

El 04/12/2017 a las 11:47, via GemStone-Smalltalk escribió:

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin



_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk


Libre de virus. www.avast.com

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GemStone code management techniques

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list


On Mon, Dec 4, 2017 at 11:47 AM, via GemStone-Smalltalk <[hidden email]> wrote:

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:



Hi Martin, 

<offtopic>
At Debris Publishing, Inc. (www.DebrisPublishing.com) we have built Quuve, a fully extensible investment management platform that deploys on Gemstone. Authoring is done in the Pharo environment -- please see my inline answers below for more information. Please also check out our Quuve overview video [1] to see more. We are actively seeking a strategic partnership with a firm like UBS — please reach out if you would like to discuss potential partnership opportunities.
</offtopic>

 

 

1)      What tools/editors do you use for writing GS Smalltalk code?


We develop on Pharo and deploy on GemStone. We can even write some GemStone code in Pharo using the MockGemStone compatibility package. 
When we really really need to develop *on* GemStone, we use tODE. 
 

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?


We use Monticello and Metacello. With Metacello we can define different things to be loaded on different Smalltalks (for the things that are different).
For extensions we use a separate package. Actually, we have separate packages for Pharo and from GemStone. We even had separate packages for different Pharo/GemStone versions.
We also have a separate package for "overrides" which are usually fixes to either GemStone/Pharo that are about to be fixed soon in future releases but that for the moment we need it fix it. 
Of course, via Metacello  we can then decide which packages are loaded in which Smalltalk. 
 

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?


Currently we use Monticello, but we want to move soon to git. We will continue using Metacello regardless. 

4)      What mechanism do you use for uploading code to your production GemStone DB?


We have either bash scripts (using Topaz) as well as buttons / links to trigger updates from within the very same running web application. Obviously this button is properly secured, allowed only for admin users, etc etc. 
Sometimes... depending on the update (for example, upgrading to a new GemStone release , or a heavy migration script), we must either shutdown the stone for a while or do a much smarter approach.


If you would like more details, please let me know. 
 
Regards, 






 

Any feedback much appreciated!

 

Thanks and regards,

Martin


Check out our new brand campaign: www.ubs.com/together

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.  The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.


UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk




--

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GemStone code management techniques

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list


Hi Martin,

One solution with a long history is called GemKit. GemKit allows GS/S code to be maintained using the same code repository and development tools as a client dialect of Smalltalk (VisualAge or VisualWorks). GemKit is designed to work in conjunction with GemBuilder for Smalltalk (GBS).

GemKit started as a framework developed by GemStone Consulting at customer sites with updates shared between customers. It was sold as a product for several years and then had several years of abandon. While employed with GemStone/GemTalk I refined it into a product that was released under an open source license for anyone to use. It was originally ENVY/Developer based, so it worked with VisualSmalltalk, VisualWorks, and VisualAge. At that time I had refined it to have a common code base for all three ENVY supported dialects. I ported it to VW Store (with assistance from Joseph Bacanskas) at a Camp Smalltalk event in Colorado. I significantly refined GemKit after my time with GemStone as new employers needed it. Currently there is a GemKit for VisualAge (that I developed at WAMU) and a GemKit for VisualWorks (that I developed at ICE). For both variants I had separately refactored about 90% of the code. There are now easier maintained object models in both, but the models were created at different times and are not the same between VA and VW. GemKit was open source and had also evolved from the original consulting code. There are likely several variants all called "GemKit". David Buck had ported GemKit for VW to a newer version of VW for one of his clients, ICE also uses GemKit for the latest VW but by different effort. I no longer maintain this code and have no idea whether David or ICE would be the best source for updates to that code. Sharing of changes is expected by the open source license, but there is no incentive system to do this and so code just disappears as companies do. Older versions may exist on SourceForge.

Answers to your specific questions:

1) GemKit uses the native code management tools of VA (ENVY) or VW (Store). GS code is maintained through a client image that immediately updates GS if there is an active session. It is possible to manage GS code without a GS session and update GS later either by code comparison tools or by change scripts. All special tools (like code refactoring) are available to GS code through GemKit.

2) GS code is traditionally stored in separate "GS_" prefixed applications/packages. Newer versions of GemKit allowed a package to contain a mix of client and GS code (distinction was at the class level rather than by package). Class extensions are fully supported just as you would expect it to work for client code.

3) I also created version control systems for both WAMU and ICE. That was never part of the original GemKit. The version control system is effectively part of GemKit now. The original GemKit produced GS fileouts. The newer GemKit can also produce fileouts as change sets and that have better support for GS class extension permissions. The release tools were designed to incentivize developers to quickly integrate their working changes to reduce code merge effort and generally reduce bugs from delayed integrations. It was compliant with all the buzzwords expected now, before the buzzwords were thought of. The release tools proved extremely important for team productivity and build quality.

4) Interactive updates can be made by logging into GS and comparing a loaded or specific version of code with what exists in GS. Releases are typically deployed with GS patch files (.gs fileout). A fileout can be produced for all the code of a release or to bring code from any specific version up to a targeted version. GS class extension code (that requires SystemUser or DataCurator login) is in a separate but similarly named "_extensions.gs" patch file. When a class schema is changed then a patch will include all the code of all subclasses too. Class migrations and version-specific update code is traditionally part of the .gs update script. If you create a patch to go from version 1 to 10 and there are several version and that have pre and post migration code then that pre and post code is automatically combined to work as you would hope. At ICE they wanted to separate and customize this code for each upgrade, and so that is possible too.

I have the impression that GemTalk is finding reduced customer demand for GBS. That means that GemKit is less used too. GemTalk now has more emphasis on web clients and code management through Monticello and git. GemKit is an established way of GS code management that is again falling to neglect. GemKit might possibly be the best solution out there but there isn't much of a market to share a specialized tool like this. GemKit became significantly refined over the years but you'll still find some messy code in there. It works well though and has had years of mission-critical utility. In a very real sense, GemKit for VW has such utility that it alone can be a reason to buy licenses for VW and GBS. GemTalk stands behind Monticello, so you might try that solution first to see if it meets your needs.

Paul Baumann

Retired from Software Development



On 12/04/2017 09:47 AM, via GemStone-Smalltalk wrote:

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin



_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk


_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GemStone code management techniques

Gemstone/S mailing list
At Computas, we have VA Smalltalk clients using GemBuilder and parts of the code is shared between the client and the GemStone server.

> 1)      What tools/editors do you use for writing GS Smalltalk code?
We keep our GemStone code together with our client code in VAST/ENVY. We mark each application as "on GemStone" or not, which is used by our tools for picking the right code to push to GemStone.

> 2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?
We have our own custom made tools for extracting changed code for GemStone and creating topaz upgrade scripts.
a) We first had a config-map-diffing approach. It worked quite well.
b) We currently have a more manual system where developers pick individual class definitions and methods. We made this change to make it easier to deliver smaller separate changes.
c) We are planning to go back to the config-map-diffing approach again, but with enhancments to our tools and more frequent GS updates.
And:
- We have a feature/tool where we can store "GS overrides" for individual methods separate from the client implementation. We store the GS overrides as separate methods using a method naming convention which our tools recognize. We try to use this feature as little as possible.
- We have little or no GS code that doesn't compile in the client (we don't use GS indexing and GS indexing special syntax anymore), but the "GS override" feature would be used to handle that.
- We use switches in our code (...isServer ifTrue: [] ifFalse: []) to store client and server specific code in the same method.
- Our GS system class modifications are mainly stored as regular methods on the class in question in VAST/ENVY, an a "on GemStone" application.
- We allow for some methods to have its master implementation reside in GemStone.
- We have a three-way diffing tool which we use for handling our system class modifications when upgrading to new versions of GemStone (we run a diff on an empty GS version X database, an empty version Y database and our GS version X application database and extract our system class modifications and highlight any conflicts between GS changes from version X to Y and our system class modifications).

>3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?
We keep the code in ENVY, and create topaz upgrade scripts.

>4)      What mechanism do you use for uploading code to your production GemStone DB?
We deliver topaz upgrade scripts, which are used by operations to perform the GS upgrade. We use the same scripts to incrementally upgrade our development GemStone servers.

Jonas Bjelkerud
Computas AS

On 12/04/2017 09:47 AM, via GemStone-Smalltalk wrote:

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin



_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk


_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk



_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk