Please visit tagland.sourceforge.net to check out the source code for tagland. Under current development are some of the ideas sketched out in previous posts. Specifically, I've got a PropertyPage system working which allows you to view and edit Java Bean properties on any java.lang.Object. This will plug into the tagland command-line menu system to edit the Anarchia.us domain objects, similar to how NakedObjects does it, but much, much simpler.
These are baby-steps, but it demonstrates my bottom-up, Managing SimplicityTM, CDC approach. I'd love to hear your comments and contributions. Please feel free to join the sourceforge project here.
Showing posts with label diorama. Show all posts
Showing posts with label diorama. Show all posts
Thursday, November 11, 2010
Friday, August 6, 2010
Nail 2.0
I live in Berkeley. Most of the houses here pre-date me. Almost all are built with wooden frames, which means almost all were built using nails. Imagine, if you haven't already, that the Naitional Nail Authority has issued Nail 2.0. Immediately, however, a bug in the Nail 2.0 implementation causes the underlying Nail 1.0 implementation to AB-END and fail to build. So immediately, of course, all Nail 1.0 and later spec nails cease to exist. So 95% of the houses in Berkely immediately fall over, and the town looks like the last little pig was smart after all, until owning a nice brick home in a town of wooden houses all broken up with gas lines open all over the place starts to seem like a really bad idea.
This kind of Scorched Earth vision was all the rage in the last part of 1999. I was working in Financial Services doing portfolio analytics server-side in Java with a legacy back end of millions of lines of FORTRAN code. So we didn't sweat the Y2K bug at all -- financial analytics really have to be able to go way into the future for Bonds and what-ifs, so the system had always been written to handle Y2K dates. But I remember thinking that if the EastBayMUD servers, which I had toured, and were highly COBOLized, were to crash, then for a few days we might not have water. Though more likely was just an EBMUD water bill for a century's worth of water.
So why don't houses fall down when they issue a new nail? Because objects in the real world are manufactured, and then installed and left there with no dependencies. Having a build system is a luxury deployed by just about every software shop, and so is having developers who use version control, test suites, etc. Yet, when we build software, we don't package everything up and ship appliances. We ship tiny bits of code that depend on lots of other code. And our bits of code were made by the interaction of thousands of other littler bits of code. And we send all our little pieces, with all their dependencies on pieces that we don't ship, out in their little boats. Sorry, lost the house metaphor for a boat reference. But I like the imagery of it.
In the dot-com binge, my brother and I started ToasterWorks.com and designed what is now called Cloud Computing. We designed, coded, networked, prototyped, and documented most of, say, what you can get from Amazon EC2. My brother worked on selling it to Dell, Compaq, and some large ISPs. We got really close, but we got beaten to market by several competitors.
I knew going into it that the ideas I had were the result of being in a computer geek zietgiest that probably included about 2 million really sharp minds. I knew there would be lots of others with identical startups, because appliances had already busted out, and linx had GUI terminal servers, so the concept of provisioning a blade at boot time with a networked version-controlled repository of boot images and large data mounts seemed like the way to go since it was clear that big iron would make some kind of comeback. I was also working then on designing web services so that all our virtualized boxes could have very simple duties and just network their messages back and forth. But like I said, that's no boast--lots of people were all scratching their heads and thinking about the future and how it might be manageable with all these dang Linux boxes stacked in the server room and all these dang software pieces.
So now we have Cloud Computing and we have Web Services. But we are still missing some of the things on my wish list.
Real packaging. You get the immutable bits that will work. All of them.
You can still have a build system for assembling and testing these beasts. But don't expect users to have a build system that can handle your kruft.
Simple communication.
All text communication.
Bi-directional communication supported, and one-way messaging is preferred.
To implement this today, I'm thinking: XML messaging. XML file formats. Use schemae and attach them to the document. These all seem viable and established now.
Real interfaces. Typed, inheriting, globally known, versioned, assembled interfaces. (Possible with things like XML messaging and JSON. But also perhaps with sending objects around.)
Come up with some kind of object that can be sent around the network and stored and versioned and transformed, round-trip, to text and back. Java does this, and it plays well with real object databases. I suspect Javascript could do this well, too, as my brilliant friend Brian hipped me to, but he said he detests blog technology, so I guess I shouldn't link to him. Anyway, he says it's totally doable, and folks are doing it.
But I haven't had too much time to see what is up in the javascript-as-object-nirvana world, since I am happy as a clam since I got the schema for the anarchia.us objects coded in Java and stored in db40 and accessed with the rudiments of Retro (my command-line framework) working on my laptop. Java objects. Simple. Not "Value Objects," but POJOs. Properties, collections, relationships--all store nicely in db40. And I'm not doing any kruft. No annotations, no JAXB, no mapping file, no injection, no nothing.
I'll put up the source very soon, and design docs. For now, please read the other posts in this blog to see where I'm hoping to go.
This kind of Scorched Earth vision was all the rage in the last part of 1999. I was working in Financial Services doing portfolio analytics server-side in Java with a legacy back end of millions of lines of FORTRAN code. So we didn't sweat the Y2K bug at all -- financial analytics really have to be able to go way into the future for Bonds and what-ifs, so the system had always been written to handle Y2K dates. But I remember thinking that if the EastBayMUD servers, which I had toured, and were highly COBOLized, were to crash, then for a few days we might not have water. Though more likely was just an EBMUD water bill for a century's worth of water.
So why don't houses fall down when they issue a new nail? Because objects in the real world are manufactured, and then installed and left there with no dependencies. Having a build system is a luxury deployed by just about every software shop, and so is having developers who use version control, test suites, etc. Yet, when we build software, we don't package everything up and ship appliances. We ship tiny bits of code that depend on lots of other code. And our bits of code were made by the interaction of thousands of other littler bits of code. And we send all our little pieces, with all their dependencies on pieces that we don't ship, out in their little boats. Sorry, lost the house metaphor for a boat reference. But I like the imagery of it.
In the dot-com binge, my brother and I started ToasterWorks.com and designed what is now called Cloud Computing. We designed, coded, networked, prototyped, and documented most of, say, what you can get from Amazon EC2. My brother worked on selling it to Dell, Compaq, and some large ISPs. We got really close, but we got beaten to market by several competitors.
I knew going into it that the ideas I had were the result of being in a computer geek zietgiest that probably included about 2 million really sharp minds. I knew there would be lots of others with identical startups, because appliances had already busted out, and linx had GUI terminal servers, so the concept of provisioning a blade at boot time with a networked version-controlled repository of boot images and large data mounts seemed like the way to go since it was clear that big iron would make some kind of comeback. I was also working then on designing web services so that all our virtualized boxes could have very simple duties and just network their messages back and forth. But like I said, that's no boast--lots of people were all scratching their heads and thinking about the future and how it might be manageable with all these dang Linux boxes stacked in the server room and all these dang software pieces.
So now we have Cloud Computing and we have Web Services. But we are still missing some of the things on my wish list.
Real packaging. You get the immutable bits that will work. All of them.
You can still have a build system for assembling and testing these beasts. But don't expect users to have a build system that can handle your kruft.
Simple communication.
All text communication.
Bi-directional communication supported, and one-way messaging is preferred.
To implement this today, I'm thinking: XML messaging. XML file formats. Use schemae and attach them to the document. These all seem viable and established now.
Real interfaces. Typed, inheriting, globally known, versioned, assembled interfaces. (Possible with things like XML messaging and JSON. But also perhaps with sending objects around.)
Come up with some kind of object that can be sent around the network and stored and versioned and transformed, round-trip, to text and back. Java does this, and it plays well with real object databases. I suspect Javascript could do this well, too, as my brilliant friend Brian hipped me to, but he said he detests blog technology, so I guess I shouldn't link to him. Anyway, he says it's totally doable, and folks are doing it.
But I haven't had too much time to see what is up in the javascript-as-object-nirvana world, since I am happy as a clam since I got the schema for the anarchia.us objects coded in Java and stored in db40 and accessed with the rudiments of Retro (my command-line framework) working on my laptop. Java objects. Simple. Not "Value Objects," but POJOs. Properties, collections, relationships--all store nicely in db40. And I'm not doing any kruft. No annotations, no JAXB, no mapping file, no injection, no nothing.
I'll put up the source very soon, and design docs. For now, please read the other posts in this blog to see where I'm hoping to go.
Sunday, June 13, 2010
Tagonomy Display; features; attributes of tagonomies
See also: Why diorama?
Supposing that we have a definition of a tagonomy (elements, paths, relationships, aliases, semantic meaning versus object storage), then we can display them.
I have two user-interface rules that apply here: 1) information for navigating the system should be accessible and distinguished; 2) the signal-to-noise ratio should be very high.
For visualization, imagine you are wandering around in a world of your favorite zero-information background, and in front of you are high-information tokens, and around you are related token which could be useful if you wish to move towards them. I could see this as a virtual reality walk through a park with some avatars, etc. But for the current proposal, let me have you visualize something a bit more IBM-Gothic.
For Retro, you have a lovely black background, and words in pleasing fonts and readable, gay greens and yellows and whites (or whatever color stylesheet turns you on) get closer and farther away as you get close to them semantically, so that you see the word "eMail" in bright green letters, and it is significant. Or, if you are in the middle of navigation or choosing items from a menu, these are the only objects/words/pictures that are really highlighted and green.
In this space, we are navigating the metadata, the context. We are not storing the objects, we are providing all the information about the objects, the relationships.
- by year
- big font for years
- project inception dates, meeting person dates, most highlighted/visited/priority get biggest font
- by category
- by priority
- by tagonomy and by date as layers
Above a certain size, every object in the space, with its own representation gets its representative node to bump its display size. So each folder in the space has a template or stylesheet that exports size displays.
Displays for an object in a tagonomy:
See also:
Why diorama? Why now? And what is diorama anyway?
Supposing that we have a definition of a tagonomy (elements, paths, relationships, aliases, semantic meaning versus object storage), then we can display them.
I have two user-interface rules that apply here: 1) information for navigating the system should be accessible and distinguished; 2) the signal-to-noise ratio should be very high.
For visualization, imagine you are wandering around in a world of your favorite zero-information background, and in front of you are high-information tokens, and around you are related token which could be useful if you wish to move towards them. I could see this as a virtual reality walk through a park with some avatars, etc. But for the current proposal, let me have you visualize something a bit more IBM-Gothic.
For Retro, you have a lovely black background, and words in pleasing fonts and readable, gay greens and yellows and whites (or whatever color stylesheet turns you on) get closer and farther away as you get close to them semantically, so that you see the word "eMail" in bright green letters, and it is significant. Or, if you are in the middle of navigation or choosing items from a menu, these are the only objects/words/pictures that are really highlighted and green.
In this space, we are navigating the metadata, the context. We are not storing the objects, we are providing all the information about the objects, the relationships.
- by year
- big font for years
- project inception dates, meeting person dates, most highlighted/visited/priority get biggest font
- by category
- by priority
- by tagonomy and by date as layers
Above a certain size, every object in the space, with its own representation gets its representative node to bump its display size. So each folder in the space has a template or stylesheet that exports size displays.
Displays for an object in a tagonomy:
- At very small, it is just a word.
- Next, it is a series of words, and maybe an icon, if icon display layer is on.
- Next, it becomes a description paragraph, extract, abstract, with picture, like an article or summary.
See also:
Why diorama? Why now? And what is diorama anyway?
Subscribe to:
Posts (Atom)