Imagine being an aspiring DJ, ample musical talent, mixing some tracks left and right, with a slowly growing network of gigs. Add to that a demanding job requiring a considerable time investment. Now suppose a radio station is writing out a competition of re-mixing a certain song... then you know what I did instead of sleeping over the past few days: I just had to send in my version.
So without further ado: David Guetta - Delerious [The Dutchman Sessions].mp3
Wednesday, March 19, 2008
Monday, March 17, 2008
Conflicting spam messages
I'm fighting an inner conflict when looking at my spam inbox. From time to time, i scan through it to make sure my filter isn't too greedy. But I'm not sure what it is these spammers would like me to do to my body: I just can't choose between
[Dave Small] Lose 20 pounds in 3 weeks
or
[Brandy Henderson] Add three inches to yours now
What would three inches weigh?
[Dave Small] Lose 20 pounds in 3 weeks
or
[Brandy Henderson] Add three inches to yours now
What would three inches weigh?
Tuesday, March 11, 2008
Real-time collaborative DSL editing
When being involved with exciting technologies like DSLs, meta-models, dynamic languages but also focus every-day IT issues, the mind tends to wander. I came across an interesting article on a RAM-based database storage approach, which triggered memories of the Naked Objects book and the Prevayler pattern, when put into the perspective of DSLs. This thought adventure has lead to the following train of ideas. for a graphical DSL approach. Bear with me.
A domain-specific language is based on a meta-model. Imagine the meta-model being defined in a dynamic language, so that it need not be fixed, and could be extended even at run-time. Furthermore, say that all mutations on the model shall be performed through a Command pattern: this is part of the Prevailer approach to handling object graph persistence. Basically, we consider the model as a graph of objects, whose classes are allowed to change at runtime, but can be prevayled. But let's extend the Command paradigm, in that a concrete Command has the responsibility of indicating which objects within the model are changed after having executed.
Since the goal is to create a graphical DSL, just a data-defining meta-model is not enough. Visual representations of meta-attributes are needed. Let's introduce an editor concept: an editor binds UI capabilities to a metaclass. Concretely, this means a graphical manifestation, behaviour responding to events, but (this is important) no state information. If an editor needs state information that's not in the meta-class, introduce a meta-class specifically for the symbol that the editor is managing. The behaviour of the editor translates UI events into Command objects, which can update the meta-model.
The magic now is, to put a network (JINI-like) layer between the meta-model and its editors. Access to the meta-model will be a single-threaded queue of Commands. After a command executes, a list of changed objects is broadcasted to all editors across the network, so they may update their visual display accordingly. I reckon some versioning/OOL might me needed to iron out synchronization issues.
Implemented correctly, this might give you:
A domain-specific language is based on a meta-model. Imagine the meta-model being defined in a dynamic language, so that it need not be fixed, and could be extended even at run-time. Furthermore, say that all mutations on the model shall be performed through a Command pattern: this is part of the Prevailer approach to handling object graph persistence. Basically, we consider the model as a graph of objects, whose classes are allowed to change at runtime, but can be prevayled. But let's extend the Command paradigm, in that a concrete Command has the responsibility of indicating which objects within the model are changed after having executed.
Since the goal is to create a graphical DSL, just a data-defining meta-model is not enough. Visual representations of meta-attributes are needed. Let's introduce an editor concept: an editor binds UI capabilities to a metaclass. Concretely, this means a graphical manifestation, behaviour responding to events, but (this is important) no state information. If an editor needs state information that's not in the meta-class, introduce a meta-class specifically for the symbol that the editor is managing. The behaviour of the editor translates UI events into Command objects, which can update the meta-model.
The magic now is, to put a network (JINI-like) layer between the meta-model and its editors. Access to the meta-model will be a single-threaded queue of Commands. After a command executes, a list of changed objects is broadcasted to all editors across the network, so they may update their visual display accordingly. I reckon some versioning/OOL might me needed to iron out synchronization issues.
Implemented correctly, this might give you:
- Real-time collaboration on large models, without direct need for locking. If you're about to change a diagram somebody else is working on, you would see the diagram change in real-time.
- Flexible realization of MDA's marking model concept: just dynamically extend the meta-model, defining metaclasses divided into architectural layers you want to elaborate on. Dynamic methods might assist in filling in default values for the markings.
- Real-time editing of a rule engine: just hook into the server's object model and execute it; clients could dynamically change the rules or even the metamodel of the rules, without ever bring down the system (hmm, we'd have to elaborate on this one ;-)
Concept established... creativity coming
So there you have it. My life's been taking off lately, like a whirlwind through wonderland, blowing leaves, moving trees left and right. Looking over my left shoulder, I see creativity, art, music, photography, video, but language as well... which describes the right shoulder, on which intellect, commitment, IT and abstractions form a complex model.
Both of these forests have been growing dense as of lately. Now what better way of untangling some of those branches, than structuring my thoughts in a blog? Let's roll, and find out how deep the rabbit hole goes!
Both of these forests have been growing dense as of lately. Now what better way of untangling some of those branches, than structuring my thoughts in a blog? Let's roll, and find out how deep the rabbit hole goes!
Subscribe to:
Posts (Atom)