You don’t want to know. Or maybe you do. I’ve spent 14 to 16 hours a day programming — rearchitecting, in the argot, a project I’m working on. The application tracks resources, for construction companies, in real time, and there were quite a few things to fix. (Note to Cosh: this is what I do for a living.)
Don’t misunderstand: I’m as lazy as the next man, probably lazier. My exertions were mostly geared toward maximum future leisure. The application is in beta now, and very soon it will go into production. The beta users want new features, and the production users will want more new features. Your choice is, fix the server design now to make these features relatively easy to implement, or do ten times as much work down the road. As the FRAM oil filter guy used to say, you can pay me now, or pay me later.
I’m also one of those guys who will work forever if something interests him and idle for weeks otherwise, which makes me, as you might imagine, a less than satisfactory employee. In this case we decided on more or less the server design that I wanted in the first place, so I was forced to work around the clock to prove that I was right. Which I was. And isn’t that what life is really all about?
Microsoft, about which I rarely have a good word to say, certainly earned its keep this week. It turns out that C#, unlike Java, can transparently proxy objects over machine boundaries. This means you can create complex objects on the server with references to their subobjects, pass in a proxy that knows how to construct the subobjects, and then fetch the subobjects dynamically, without the callers having to know a thing about it. The nasty synchronization issues associated with client-side caching disappear, turning event-handling from a nightmare into a breeze. If you understood this, what a thrill, right? If you didn’t, I’ll write about poetry again soon.
I shall return later tonight with an explanation of why David Lee Roth is the world’s most eminent living sociologist. If by some chance I don’t, see above.
"Don’t misunderstand: I’m as lazy as the next man, probably lazier. My exertions were mostly geared toward maximum future leisure."
Here is a pointer: If maximum future leisure is your goal, become rich.
I’m a professional programmer, and even I don’t understand what you just said.
"It turns out that C#, unlike Java, can transparently proxy objects over machine boundaries."
This has been available in Java (via Jini) for years. And you don’t give up the option of running cheap Linux boxes on the backend.
Add PHP4 or Zope (J2EE is too heavyweight for most projects) and you can run the whole mix without paying the Microsoft tax. That should help with Bill Kaplan’s pointer.
I’m still waiting for the poetry.
It’s March, man; time for OPS, Zone Ratings, Win Shares, and RC over replacement value. Davey Concepcion, HOF? Steroids!
Den Beste is back and posting 50,000 words at a time. Put them in a fortune cookie for Johnny Lunchpail.
Stupid people who only read about poetry when you write about it still don’t grasp Winters’s transition from imagism to formalism.
Get in the phone booth, Haspel, don the big block "S" and make the interweb safe for humanity. Or post some cute monkey pictures.
Golden Hacker: My discussion was pretty cursory, as I don’t think most of my readers would understand the details, but I can explain it now with an example. In our system we have objects called jobs projects that the company is working on and to which it allocates resources. We also have objects called resources, of course employees and equipment are among the subtypes and objects called allocations, which represent a block of time that a resource is spending on a particular job. Jobs have managers people who are onsite and responsible for running things and these managers themselves have properties, like addresses, phone numbers, email addresses, and so forth. Allocations, in turn, must refer to the job they’re for, the resource being allocated, and by implication, the manager.
The system must update in real time, so everybody knows what the status of everything is at any point. So your problem is, suppose you update a resource. How do you update all of the allocations involved? Or suppose you update a manager. How do you update all of the jobs, and for that matter, all of the allocations on all of the jobs? And how do you do this without killing performance?
The answer is, you have to cache. But that’s not enough. What you really need to do is return the subproperties dynamically: that is, when you ask an allocation for its resource, it doesn’t store the resource itself, but a reference to the resource, which it fills and returns on demand. This is the only way to keep the cache in synch; otherwise when an object to which many other objects referred changed, you’d have an impossible problem.
To return the subproperties dynamically the objects need to contain another object that knows how to get the subobjects, a sort of factory or service, with methods like getJob( id ), getResource( id ), and so forth. This is the object that C# proxies transparently, meaning that if i create a job on the server side, with a reference to my factory object, and then ship this job to the client, on a different machine, the reference is still valid, and the methods can still be called. So what we do is create and store objects on the server side, ship them to the client, and then the client never knows about the reference: it simply asks a job for its manager, and the job itself does the dirty work. When it’s asked for its manager, it calls a method like service.getManager( id). This goes and fetches the manager object from the server cache, where it is always guaranteed to be current. But to the calling client it’s simple: it asks for a manager object, and it gets a manager object.
Does that help any?
By the way, Norm is right about Java of course, and I was wrong. But I got stuck with C# on this project and was happy to get what I wanted at all.
Umm…could we argue about Pulp Fiction some more?