You are currently browsing the category archive for the 'Gemstone' category.

It was just announced that the power to our Beaverton offices will be shutdown Friday afternoon for ‘emergency’ power maintence between 1pm PST and 6pm PST.

I am looking into alternative hosting, but with such short notice, it isn’t likely that we will be able to move GemSource and the rest of the services hosted on seaside.gemstone.com. If you were planning on downloading anything Friday afternoon, you’ll need to change your plans.

gs_share_everything_esug08-poster

I just recently found out that James Robertson had posted a video of my “Share Everything” talk from ESUG 2008 several months ago. I must have missed the announcement:)

An MP4 version of the talk was posted here a month ago.

And here’s a link to the slides.

[1]

That’s a huge platter of fruit de mer sitting in front of me (at the end of the table) and no it wasn’t all mine – there were 5 of us sharing that mound of seafood. The photo nearly says it all about ESUG 2009: a group of Smalltalkers eating seafood and talking shop.

Overall an excellent conference. Good presentations, good food, and good conversations. Congratulations to ESUG and the conference organizers for a job well done.

Follow these links for slides, pictures and videos. Here are some of my highlights

Glamour

Where did all the code go?

If you’ve ever tried to write a browser in Smalltalk you are aware of the amount of code that you must write. OmniBrowser cuts down on the amount of code involved, but you must still wrap your mind around the OB meta model, which is not always easy.

Enter Glamour. The following code produces an Object Explorer (multi-paned object explorer):

| browser |
browser := GLMFinder new.
browser list
	title: 'Collection';
	when: [:each | each isCollection].
browser list
	title: 'Object';
	display:  [ :anObject | 
        anObject class allInstVarNames collect: [:iv | 
            iv -> (anObject instVarNamed: iv) ] ];
	format: [:assoc |
        assoc key asString, ' : ', assoc value printString];
	send: #value.
browser text
	display: [:entity | 'self' ];
	title: 'Evaluator';
	update: #selection 
    on: $o 
    entitled: 'Open (o)' 
    with: [ :text :entity |
	    Compiler 
         evaluate: text selectedText 
         for: entity 
         logged: false ].
^ browser

Philipp Bunge and Tudor Girba have been able to distill window building down to the bare minimum. Very neat work. Oh, did I mention that besides a Morphic mapping, there is a Seaside3.0 mapping too?

Metacello

While I feel comfortable with the core engine of Metacello, I arrived in Brest, keen to get feedback on the spec creation API. Fortunately, I was able to spend the better part of 4 days working closely with Tudor Girba to refine the functionality and spec creation API. Following Doru’s suggestions, I have made some fairly significant changes to improve the overall usability of Metacello. Doru and I will continue working together on refining the things for the beta release of Metacello.

In addition to Doru’s feedback, I was able to talk to a number of different people about Metacello and the problems it is trying to address. All in all very positive feedback.

Seaside 3.0

Julian, Lukas and Philippe announced Seaside 3.0 at the conference and the Seaside Sprint brought Seaside3.0 tantalizingly close to beta.

GemStone will be releasing version 2.4 very soon now. Shortly after the 2.4 release is officially announced, we will make the Seasde3.0 beta available on GLASS.

The online book Dynamic Web Development with Seaside (sponsored by ESUG) was also announced at the conference.

CouchDB for GemStone/S

In the days leading up to ESUG Randall Schwarz visited our offices and piqued my interest in NOSQL databases:

Have you run into limitations with traditional relational databases? Don’t mind trading a query language for scalability?

Sounds like an ad for GemStone/S doesn’t it?

I chatted up the idea that it would a be a no-brainer for GemStone to provide a NOSQL database mapping for GLASS with a number of folks at the conference.

Philippe Marschall thought it was more than a good idea. In a matter of days (or was it hours) he had implemented a CouchDB mapping for GLASS using Seaside3.0. The code is up on GemSource in the CouchDB project.

Summary

There were lots of other conversations and many more interesting projects to discuss like Pharo and a port of Moose to GemStone. Needless to say, I came away from the conference with a todo list as long as your arm (to add to my already long todo list:).

The next few months should be a very interesting time as the seeds sown at this year’s ESUG come to fruition!

—–
[1]Photo by Damien Pollet (Creative Commons).

Ken Treis has post up called Deep SIXX with XMLPullParser about how he and the folks at his company use SIXX to transfer objects between GemStone and Pharo.

Ken ported Antony Blakey’s XMLPullParser from VisualWorks to Squeak in a (successful) attempt to reduce the amount of memory consumed while copying large object graphs using SIXX.

If you are developing in Squeak/Pharo and deploying in GemStone, then you should check out Ken’s work.

Photo by jayhem (Creative Commons).

(c) Rick Harrison

Earlier today, Ramon Leon posted a very good response to a Pat Maddox question How do you handle constraints on persisted collections?:

I’m trying to make the leap from RDBMS/ORM thinking to pure objects,
and am running into some problems. The first is how to handle
constraints on collections, when the objects inside of that collection
are mutable. Quick example, ensuring that only one user exists with a
certain username. It’s trivial to check that a username is available
before adding the user to a UserRepository. If a user can update his
own username though, it’ll bypass any check on the UserRepository and
invalidate that constraint. A couple options…

1. Have a ChangeUsername command that reserves that username in the
repo, tells the user object to change its username, and then tells the
repo to free the original username
2. When user username: is called, publish a UsernameChanged event that
the repository subscribes to. The repo can choose to reject the
change if it would violate the repo’s constraints.

The first is just a bit ugly and procedural. The second requires the
User object to publish events whenever something happens – which is
easy to forget to do, or you’re left with determining which method
calls warrant the publishing of events. Also you’d have to roll back
the change if the event is rejected.

You could handle that stuff by writing some framework code to manage
the tedious stuff…I don’t love either approach though. How do you
guys tackle this sort of problem?

Pat

And I thought that I would reproduce Ramon’s answer here, because I think it helps folks coming from a relational world to start thinking in terms of persistent objects:

The short answer is you don’t.

The longer answer is you’re still thinking relationally; thinking in sets.
OODB’s and RDBM’s are different paradigms and have vastly different strength
and weaknesses. RDBM’s are much better at guaranteeing data integrity
through things such as constraints and keys rather than collections and
pointers, there’s a theoretical foundation for this, but OODB’s have no such
mathematical rigor. This is a weakness of the OODB. There is no one
provable right way to do it.

On the other hand, RDBM’s have to force everything into a single fixed
schema data structure to accomplish this. The problem is this isn’t the
data structure most programs actually use. RDBM’s don’t speak objects, the
primary method programs actually use to model their domain, and every
attempt to bridge that layer by automatically mapping objects to tables
leads to very serious constraints on the object model. It becomes infected
with compromises to performance or compromises to the flexibility of the
model in order to make it fit. Last but not least you’re stuck with a whole
new layer of code to maintain, the mapping layer, that wouldn’t even be
necessary with an OODB and prior to Rails was often more code than the
domain model itself. If you really enjoy programming with objects,
relational databases will never quite fit right, there’s just an impendence
mismatch that as far as I know no one has ever solved cleanly.

So for a query optimizer, declarative constraints and indexing, you have to
do a whole lot more programming. A fair trade to some for the rigor they
require, but for those who choose the OODB, they’re willing to trade the
rigor for the pragmatism of doing a ton less work and actually getting
things done that just work good enough. I can’t tell you how many RDBM’s
I’ve run across that in production that didn’t have a single foreign key in
place or use constraints at all (often for performance reasons) and chug
along just fine making plenty of money for the gold owner. You’re
experienced with Rails, so you’re aware that most Rails apps don’t use
foreign keys at all. Rails treats the db like a big persistent hash table
preferring to keep the logic in the model. This is a very object way of
doing things. It’s not perfect, but it works well enough in practice.

Look at what Rails has to do to try and fake polymorphic collections,
something that is so utterly trivial in an OODBMs that you don’t even
realize it’s anything special to do. Toss a bunch of object into a
collection and commit; done. The flexibility you gain in modeling things
any way you wish using any data structure you want more than makes up for
the things you lose, i.e. simple declarative constraints and a query
optimizer that lets you just slap on indexes after the fact.

With an OODB you have to think more up front and structure you domain in
such a way that your primary use cases are primarily handled by pointer
navigation. If you’re building a blog, you index the posts by the URL in a
dictionary, you put the comments into a collection in the post. Maybe you
hang the posts off the user who wrote them as well. When it’s all setup,
there’s very little if any querying going on. Now OODB’s do support indexed
collections when you need queries but if you’re writing a behavioral app
rather than a reporting engine, more often than not you don’t want queries
you want tree’s of related objects that actually do things.

If you need to use some special high performance custom written collection
to index your model just the way you want it, an OODB lets you, it’s just
another object after all. If you need collections of objects where every
instance could have wildly different data because you allow the user to add
custom fields, the OODB has no problem with this. It doesn’t care about the
structure of your objects. The price you pay for that flexibility is you’re
on your own, no declarative constraints or query optimizer. On the other
hand, you’re not limited in what you want to do. A relational db just can’t
do user generated fields without converting those fields into rows and
losing its queryability and performance.

Sorry, that turned into a longer post than I’d intended and I’m sure you
already know much of if not all of this, but others who are considering
OODBs might find this useful. It’s a different paradigm and requires a
different style of thinking but pragmatically has a lot of benefits if being
productive is the goal.

Anyway, my approach to your particular issue would be to simply make the
name field immutable after being set the first time. A simple guard clause
in the accessor that threw an exception if someone tried to set the field if
it already had a value and the new value was different would protect any
unintended aliasing bugs. After all, an object should encapsulate its own
business rules and if the field were unique I’d have modeled that by hashing
it in a dictionary by that fields value. It’s not the rigorous guarantee
that a constraint on a set is, but objects aren’t about sets, they’re about
instances and in any real program it’s pragmatic enough to get the job done.

Ramon Leon
http://onsmalltalk.com

Norbert Hartl just published Easy remote gemstone, an article outlining the steps for setting up a linux host for remote access by the GemTools. Norbert details the steps for either poking holes in your firewall or using an ssh tunnel.

Photo by extratony (Creative Commons).

[1]

Norm Green has announced open enrollment for the following course:

Course: GemStone Performance and Advanced System Management
Dates: June 8 – 10, 2009
Location: Beaverton, Oregon, USA
Cost: $2300 per student.
Registration: send email to training at gemstone dot com

Description:

This three-day course builds on the concepts introduced in GemStone’s
Fundamentals of GemStone/S course. Students gain an understanding of
advanced concepts and issues associated with the performance and
tuning of GemStone’s object server. The instruction format consists of
lectures and guided explorations through actual examples providing
each student with real-world experience.

You Should Take This Course If You

  • Want to enhance the performance of GemStone with tuning techniques
  • May have some responsibility or interaction with administering a GemStone system
  • Seek a deep understanding of the GemStone object server

Your Recommended Prerequisites For This Course Are

  • “Fundamentals of GemStone/S” course

This Course Will Teach You About

Concepts

  • How a functioning GemStone system behaves
  • Fundamental and advanced concepts of GemStone’s architecture
  • Sophisticated monitoring and troubleshooting techniques
  • How to obtain and apply numerous significant server statistics
  • Tuning a GemStone server for performance

—–
[1] Photo by Jeff Blucher (Creative Commons).

[1]

Andreas Brodbeck has announced Seashell:

Coming from the Rails world, I clearly see that there is yet missing some proven best practices for the hosting of a Gemstone powered seaside application server. Progress on GemTools is moving fast, that’s super fantastic! And I always felt that there should be a bare access to the deployment, a more basic direct access from the shell, too.

In the world of Rails there is a solid tool called capistrano, which you can use as a deployment servant.

Andreas makes a good point, the production deployment and stone management tools for GLASS leave a lot to be desired. Just ask Danie Roux. Not long ago, he blogged about using Rake to manage multiple GemStone database instances.

I haven’t had a chance to look at either of these tools in detail, but I am glad that the community is stepping in to fill a void.

BTW, there are github repositories for both tool sets: Seashell and GemStone Management scripts.

—–
[1] Photo by florriebassingbourn (Creative Commons).

Categories

 

November 2009
M T W T F S S
« Oct    
 1
2345678
9101112131415
16171819202122
23242526272829
30