My Coded Story Game project is just on my mind, so here's some more of that. If my kids are reading this someday in the future (decades from now), this should illustrate the way my brain works. I get on a topic and sort of obsess over it for a while. Then, when I've thoroughly exhausted myself, I can walk away from it.
Not exhausted yet.
I've been thinking about how I'll want to market the CSG. It may seem premature to think about marketing a product before it's even built, but I think now is exactly the tiime to do so. By defining marketing goals, I'll help drive the design of the product itself. It's got to conform to the way I want to sell it.
I occurs to me that the game play I'm envisioning would be just as easy to do for any genre or style of story-telling game. So I'll want to have the base game system, which I'm calling the "Effect System", be generic. That way, I can package as many individual games as I can think of. I can do a classic high fantasy, a sword and sorcery, a space opera, a hard sci-fi, a western, a WWII, a super-hero, horror, and anything else I set my mind on. I can do multiples of each of these, selling each setting/genre/color as its own game.
All of these can be stored in the same database. All I have to do is categorize the effects properly. That way, I can market varying games as their own subscriptions, or bundle them together in package deals.
Wednesday, November 10, 2010
Friday, November 5, 2010
Coded Story Game
I'm a gamer, into the old-fashioned role playing games. Not the computer ones, like World of Warcraft (those are ok, too, I guess), but the cool ones where people get together in a room and tell each other stories and roll funny-looking dice and look stuff up in books.
It's pretty hard to get any gaming done these days. As an adult, it's hard to find the time. I'm not likely to leave the wife and kids and go game once a week. Family time is too precious. Plus, coordinating everyone's schedules is nigh impossible. My old gaming buddies are scattered across the globe, as well, and finding a new group is like starting a new garage rock band. You won't like playing with just anybody. They have to like the same kind of music, at least.
In the last few years, most of my gaming has been done on the road. I gamed in hotel rooms with friends while on business trips. We all figure, hey, we can't be with the family anyway, so might as well make the most of it. To make this convenient, we switched to PDF versions of our books. I even created some simple dice rolling applets.
So there we were with everything we needed to play contained on our laptops. It worked great. At home, on those rare gaming occasions, I still found it easier to use PDFs on a laptop. Furthermore, I altered my little dice applet to handle the peculiarities of the new game system we were using, which made use of multiple dice types, where the highest of exploding pairs was selected. It had a to-hit roll and a separate damage roll, but the to-hit roll could influence the damage roll.
I spent an hour or so and coded these complexities into a little applet (did it on the plane ride, actually). Over several sessions (and more plane rides), I kept adding more detail and refinement to this little software tool. The more I automated the game system, that is, the number-crunching part of it, the more fun we had, the more story we completed, and the better our role-playing became.
The math and bookkeeping called for by this game's rules was easy, but any such stuff requires some share of a gamer's cognative powers. It's distracting, drawing your attention away from envisioning the scene and the actions of your character.
I know that in game design, there's always a trade-off between the versimilitude (call it “realism”, if you want) that you get from the simulation-focused rules and the complexity. In other words, taking into account all the variables makes if feel more “realistic”, but that added complexity makes the game unwieldy and slow. But computers can handle all the complex calculations in milliseconds. Using a computer, you can allow for vast complexity and not pay the price (except during the programming).
How far could I take this, I wondered. So this is my experiment.
I'm actually getting pretty excited by the idea.
I call it a "Coded Story Game".
Getting Specific
There are lots of computer-assisted tools available already. I'm tryiing to create something specific here, and it doesn't fall into some of the established categories.
My coded story game is close to traditional face-to-face pen-and-paper role-playing. I'm only taking the mechanics of the game system and expressing them as computer software tools. And not in the pages of a book that players must learn and master.
Almost everybody uses computers to handle their character sheets, write up notes about adventures, create maps for printing, etc. But mostly, the rolling of dice and the calculation of combat results gets done the old fashioned way. I'm going to provide tools that let the GM and the players click a button and generate results of actions, whether that be an attack on a foe or the use of a lockpicking skill. Furthermore, because the computer can instantly do the math, lookup untold complexities on reference tables, and so forth, those generated results can be more specific and more interesting than simple numbers.
If your character is attacking an orc, for example, the computer can, at the click of a single button, account for a multitude of variables: your strength, your weapon type and its interaction with the orc's armor, the orc's defensive abilities (parry, counter, dodge, etc.), your agility, your skill level, and the orc's, both your health conditions (injuries, stun effects, poison, fatigue, etc.), your combat stance and style vs. that of the orc, and so on. Then it can make your attack roll, the orc's defense roll, compare the two (adjusted for all the variables mentioned), look up the results on tables that store juicy descriptions of the damage possible from such an attack, and present you, the player, with as many of those results as your attack roll qualifies for. You then choose which to read to the GM and game group.
Even better, since the complexities of the game system are contained in the software, players and GMs need not concern themselves with learning it. The player never needs to know what dice to roll, how to calculate damage, how precisely armor absorbs damage, or any such thing.
They simply run the software, make up their character (again, using an automated tool), and click buttons to do things. This frees the GM and the player to concentrate entirely on making decisions about what the charcter should do, what it looks like, how they react, etc., without the distraction of all the math and lookups.
Now I really want to have this thing be a product. I want it to be a database online that people can use to make and store their game worlds, their characters, custom monsters, magic items, spells, etc.
It should cost a subscription fee. Free to casual players, cheap for serious players, More for GMs.
Thinking outside the book
It's important to make this thing different. It must stand out. But without losing what is best about pen-and-paper experiences. Each of the elements of game design: character generation, task resolution, advancement, combat simulation, and such must be done not as per usual, but by leveraging the computer's power.
The computer makes you powerful as game designer. You can do stuff that you can't in a manual game system. Complexity is not a problem, lots of rolls is no problem. Difficult math is no problem. Large numberrs are not problem.
All the stuff you have to abstract becomes fair game again.
1. Complex interactions (armor type vs. weapon type),
2. Detailed injury tracking (blood loss, detailed wounds, disease),
3. Detailed movement and encumbrance rules,
4. Vast and numerous result tables (e.g., wound charts by monster and attack form),
5. Huge arrays of variables, all accounted for (e.g., how strength mitigates encumbrance of armor, for example),
6. Weird, fun, and creative character generation (simulated back stories)
The GM side of things should be pretty cool, too. What if the GM can have a database for designing his world and campaign.
If I properly categorize all the entries on the content tables (say, like monster attack descriptions, and magic effect descriptions, and weapon damage tables), then it should be possible to allow the GM to customize the experience he will provide his players.
There can be "dials" for setting his preferences as far as lethality of combat, the rating of damage descriptions (tame, bloody, or total carnage), language used (allow profanity? how about simulated profanity like "frak"?), what kinds of magic effects are possible, strength of magic, effectiveness of missile weapons like bows, technology levels allowed, monsters allowed, player character generation rules (how many design points, what sort of randomness to allow or demand), and so forth.
I intend to start on a prototype immediately.
It's pretty hard to get any gaming done these days. As an adult, it's hard to find the time. I'm not likely to leave the wife and kids and go game once a week. Family time is too precious. Plus, coordinating everyone's schedules is nigh impossible. My old gaming buddies are scattered across the globe, as well, and finding a new group is like starting a new garage rock band. You won't like playing with just anybody. They have to like the same kind of music, at least.
In the last few years, most of my gaming has been done on the road. I gamed in hotel rooms with friends while on business trips. We all figure, hey, we can't be with the family anyway, so might as well make the most of it. To make this convenient, we switched to PDF versions of our books. I even created some simple dice rolling applets.
So there we were with everything we needed to play contained on our laptops. It worked great. At home, on those rare gaming occasions, I still found it easier to use PDFs on a laptop. Furthermore, I altered my little dice applet to handle the peculiarities of the new game system we were using, which made use of multiple dice types, where the highest of exploding pairs was selected. It had a to-hit roll and a separate damage roll, but the to-hit roll could influence the damage roll.
I spent an hour or so and coded these complexities into a little applet (did it on the plane ride, actually). Over several sessions (and more plane rides), I kept adding more detail and refinement to this little software tool. The more I automated the game system, that is, the number-crunching part of it, the more fun we had, the more story we completed, and the better our role-playing became.
The math and bookkeeping called for by this game's rules was easy, but any such stuff requires some share of a gamer's cognative powers. It's distracting, drawing your attention away from envisioning the scene and the actions of your character.
I know that in game design, there's always a trade-off between the versimilitude (call it “realism”, if you want) that you get from the simulation-focused rules and the complexity. In other words, taking into account all the variables makes if feel more “realistic”, but that added complexity makes the game unwieldy and slow. But computers can handle all the complex calculations in milliseconds. Using a computer, you can allow for vast complexity and not pay the price (except during the programming).
How far could I take this, I wondered. So this is my experiment.
I'm actually getting pretty excited by the idea.
I call it a "Coded Story Game".
Getting Specific
There are lots of computer-assisted tools available already. I'm tryiing to create something specific here, and it doesn't fall into some of the established categories.
My coded story game is close to traditional face-to-face pen-and-paper role-playing. I'm only taking the mechanics of the game system and expressing them as computer software tools. And not in the pages of a book that players must learn and master.
Almost everybody uses computers to handle their character sheets, write up notes about adventures, create maps for printing, etc. But mostly, the rolling of dice and the calculation of combat results gets done the old fashioned way. I'm going to provide tools that let the GM and the players click a button and generate results of actions, whether that be an attack on a foe or the use of a lockpicking skill. Furthermore, because the computer can instantly do the math, lookup untold complexities on reference tables, and so forth, those generated results can be more specific and more interesting than simple numbers.
If your character is attacking an orc, for example, the computer can, at the click of a single button, account for a multitude of variables: your strength, your weapon type and its interaction with the orc's armor, the orc's defensive abilities (parry, counter, dodge, etc.), your agility, your skill level, and the orc's, both your health conditions (injuries, stun effects, poison, fatigue, etc.), your combat stance and style vs. that of the orc, and so on. Then it can make your attack roll, the orc's defense roll, compare the two (adjusted for all the variables mentioned), look up the results on tables that store juicy descriptions of the damage possible from such an attack, and present you, the player, with as many of those results as your attack roll qualifies for. You then choose which to read to the GM and game group.
Even better, since the complexities of the game system are contained in the software, players and GMs need not concern themselves with learning it. The player never needs to know what dice to roll, how to calculate damage, how precisely armor absorbs damage, or any such thing.
They simply run the software, make up their character (again, using an automated tool), and click buttons to do things. This frees the GM and the player to concentrate entirely on making decisions about what the charcter should do, what it looks like, how they react, etc., without the distraction of all the math and lookups.
Now I really want to have this thing be a product. I want it to be a database online that people can use to make and store their game worlds, their characters, custom monsters, magic items, spells, etc.
It should cost a subscription fee. Free to casual players, cheap for serious players, More for GMs.
Thinking outside the book
It's important to make this thing different. It must stand out. But without losing what is best about pen-and-paper experiences. Each of the elements of game design: character generation, task resolution, advancement, combat simulation, and such must be done not as per usual, but by leveraging the computer's power.
The computer makes you powerful as game designer. You can do stuff that you can't in a manual game system. Complexity is not a problem, lots of rolls is no problem. Difficult math is no problem. Large numberrs are not problem.
All the stuff you have to abstract becomes fair game again.
1. Complex interactions (armor type vs. weapon type),
2. Detailed injury tracking (blood loss, detailed wounds, disease),
3. Detailed movement and encumbrance rules,
4. Vast and numerous result tables (e.g., wound charts by monster and attack form),
5. Huge arrays of variables, all accounted for (e.g., how strength mitigates encumbrance of armor, for example),
6. Weird, fun, and creative character generation (simulated back stories)
The GM side of things should be pretty cool, too. What if the GM can have a database for designing his world and campaign.
If I properly categorize all the entries on the content tables (say, like monster attack descriptions, and magic effect descriptions, and weapon damage tables), then it should be possible to allow the GM to customize the experience he will provide his players.
There can be "dials" for setting his preferences as far as lethality of combat, the rating of damage descriptions (tame, bloody, or total carnage), language used (allow profanity? how about simulated profanity like "frak"?), what kinds of magic effects are possible, strength of magic, effectiveness of missile weapons like bows, technology levels allowed, monsters allowed, player character generation rules (how many design points, what sort of randomness to allow or demand), and so forth.
I intend to start on a prototype immediately.
Thursday, November 4, 2010
Simple
So the thing I tell myself, over and over, every day of developing code is this:
Keep It Simple, Stupid.
This little maxim is important for everybody, of course, but for us programmers it's the most important thing there is to remember. You see, programming is hard. Software is hard. It gets complicated really fast. Programmers tend to be really smart people (not like me, I'm just a little smart), but even they cannot handle the kind of complexity that software demands. Not remotely.
Most of what programmers do, in fact, is work out ways to simplify the vast complexity that is their code. We do things like "refactoring", which is a fancy word for re-writing code to make it clearer and simpler.
We have tons of little sayings, maxims, truisms, and so forth to remind us how hard it is and what tricks and disciplines we need to practice to simplify it all. We remind ourselves to DRY (Don't Repeat Yourself). We encapsulate and modularize. We loosen our coupling. We abstract. We hide implementations. We make and use frameworks. We maximize code re-use). We use (and analyze and debate endlessly) best practices.
We have formating standards and naming conventions and color-coded coding and integrated development environments with advanced intellisense and just-in-time compiling and graphical object and data modeling languages that look like complex flow charts (but they're much more complex than they look) and tools that can generate code from those diagrams (but nobody really does that).
We have many languages, each with advantages and drawbacks, each with a religious following and an equally religious opposition. When structured programming (FORTRAN) wasn't good enough anymore, we moved to procedural programming (C). When procedural wasn't good enough, we moved to object-oriented (C++, then C#). Now that's not good enough and we're wondering if we should go to functional programming (F# anyone?). We have low level languages and high level languages and visual languages and database engines and web servers and communications protocols and standards galore. We have debuggers and version controls systems and user interaction conventions and change requests managers and virtual machines and automated test harnesses (that we really should write first, before the thing they'll test). Did I mention the competing methodologies? Waterfall (blech) vs. Iterative Rapid Development vs. Extreme Programming vs.... Oh never mind, it's endless as the accelerating and expanding universe. And that's just the computer stuff, I haven't even touched on the complexities of any given problem (business) domain.
So, I need to simplify.
Here's the best way to write simple code: don't write any code at all. Use your head and figure out a way to do what you need without code. If you utterly fail at that, try again. Try harder.
If you still fail, try even harder to work out a way to accomplish your goal with very little code. Even less than that, if you can. That would be very, very, very little code.
The less code you write, the fewer bugs you'll create.
This is the thing I did today. I went at that Meta-Manager program and figured out a way to do it without writing any code at all. Subsequently, I'm finished. And it's bug-free. It doesn't have some of the features I was dreaming of, but the extra time it'll take to use won't begin to equal a tenth of the time it would take to write and debug the code those features would require.
I'm going to make do, and I'm happy. Because today, I actually managed to keep it simple.
Keep It Simple, Stupid.
This little maxim is important for everybody, of course, but for us programmers it's the most important thing there is to remember. You see, programming is hard. Software is hard. It gets complicated really fast. Programmers tend to be really smart people (not like me, I'm just a little smart), but even they cannot handle the kind of complexity that software demands. Not remotely.
Most of what programmers do, in fact, is work out ways to simplify the vast complexity that is their code. We do things like "refactoring", which is a fancy word for re-writing code to make it clearer and simpler.
We have tons of little sayings, maxims, truisms, and so forth to remind us how hard it is and what tricks and disciplines we need to practice to simplify it all. We remind ourselves to DRY (Don't Repeat Yourself). We encapsulate and modularize. We loosen our coupling. We abstract. We hide implementations. We make and use frameworks. We maximize code re-use). We use (and analyze and debate endlessly) best practices.
We have formating standards and naming conventions and color-coded coding and integrated development environments with advanced intellisense and just-in-time compiling and graphical object and data modeling languages that look like complex flow charts (but they're much more complex than they look) and tools that can generate code from those diagrams (but nobody really does that).
We have many languages, each with advantages and drawbacks, each with a religious following and an equally religious opposition. When structured programming (FORTRAN) wasn't good enough anymore, we moved to procedural programming (C). When procedural wasn't good enough, we moved to object-oriented (C++, then C#). Now that's not good enough and we're wondering if we should go to functional programming (F# anyone?). We have low level languages and high level languages and visual languages and database engines and web servers and communications protocols and standards galore. We have debuggers and version controls systems and user interaction conventions and change requests managers and virtual machines and automated test harnesses (that we really should write first, before the thing they'll test). Did I mention the competing methodologies? Waterfall (blech) vs. Iterative Rapid Development vs. Extreme Programming vs.... Oh never mind, it's endless as the accelerating and expanding universe. And that's just the computer stuff, I haven't even touched on the complexities of any given problem (business) domain.
So, I need to simplify.
Here's the best way to write simple code: don't write any code at all. Use your head and figure out a way to do what you need without code. If you utterly fail at that, try again. Try harder.
If you still fail, try even harder to work out a way to accomplish your goal with very little code. Even less than that, if you can. That would be very, very, very little code.
The less code you write, the fewer bugs you'll create.
This is the thing I did today. I went at that Meta-Manager program and figured out a way to do it without writing any code at all. Subsequently, I'm finished. And it's bug-free. It doesn't have some of the features I was dreaming of, but the extra time it'll take to use won't begin to equal a tenth of the time it would take to write and debug the code those features would require.
I'm going to make do, and I'm happy. Because today, I actually managed to keep it simple.
Tuesday, November 2, 2010
Spoiled
My kids are spoiled and it's my fault.
When we tell them to do something, they don't obey. They argue, they stall, they ignore. Sometimes, they defy.
Not every time, of course. They're not monsters, not Veruca Salt, just, well... they've learned to game the system.
They know that we adults are busy, tired, and limited. We'll be persistent enough to follow through and make them do it much of the time. But sometimes we can be distracted. We might forget, or reconsider, or just be too tired to push it.
And, unlike my wife and me, they are consistent. They wear us down.
Recently, we had a family clean-the-house day. We worked pretty steadily from 10 am to about 5 pm. The kids were given appropriate tasks for their ages, with lots of breaks, lots of supervision and direction, and it was ultimately a successful day. Not a lot of fun, though.
Ethan lost his temper and got dramatic near the end of the day. Elleri whined and pouted pretty consistently all day long. Both needed far more intervention than I think they should have in order to do a decent job. They both worked, ultimately, but they made it hard on everyone, themselves included.
My kids are utterly unused to working. So much so that they feel oppressed and abused when they have to do any work at all.
We've also noticed, recently, that they're spending too much time in front of screens. Computers, video games, movies, and TV. They seem to be under the impression that these screen-based activities are basic and essential rights. They are outraged that any 'abusive' work might interupt or interfer with these screen activities.
So, no more of that stuff for a while. They're grounded from anything with a screen. No computer, no Wii, no TV, no Netflix, no Nintendo DS. Nothing.
They can watch a show with their parents once in a while. That's it. Until further notice.
They'll be doing chores every day after school, and working on their homework. We'll have other activities, like reading, and learning about stuff, and helping mom and dad with all that needs done. And when their behavior has improved significantly, we'll re-introduce screen activities in a careful and controlled fashion. A little bit at a time, until we found a healthy balance.
I explained this to both kids. It felt like a good parenting moment. They seemed to understand and accept this new paradigm. I felt like I had a good plan, and it was already under way. We talked about this stuff for maybe 20 minutes and they really seemed to get it. They were with the program. Maybe they realized that this would mean more direct quality time with their parents, and they instinctively know that's what they need.
"Good," I said. "Now it's time to get ready for bed. Go brush your teeth."
"Uhgg! Daddy, I don't want to. Do we have to brush our teeth now? I'm not even tired." Elleri whined.
"First, I'm going to get some more to eat." Ethan said, and immediately headed for the kitchen.
When we tell them to do something, they don't obey. They argue, they stall, they ignore. Sometimes, they defy.
Not every time, of course. They're not monsters, not Veruca Salt, just, well... they've learned to game the system.
They know that we adults are busy, tired, and limited. We'll be persistent enough to follow through and make them do it much of the time. But sometimes we can be distracted. We might forget, or reconsider, or just be too tired to push it.
And, unlike my wife and me, they are consistent. They wear us down.
Recently, we had a family clean-the-house day. We worked pretty steadily from 10 am to about 5 pm. The kids were given appropriate tasks for their ages, with lots of breaks, lots of supervision and direction, and it was ultimately a successful day. Not a lot of fun, though.
Ethan lost his temper and got dramatic near the end of the day. Elleri whined and pouted pretty consistently all day long. Both needed far more intervention than I think they should have in order to do a decent job. They both worked, ultimately, but they made it hard on everyone, themselves included.
My kids are utterly unused to working. So much so that they feel oppressed and abused when they have to do any work at all.
We've also noticed, recently, that they're spending too much time in front of screens. Computers, video games, movies, and TV. They seem to be under the impression that these screen-based activities are basic and essential rights. They are outraged that any 'abusive' work might interupt or interfer with these screen activities.
So, no more of that stuff for a while. They're grounded from anything with a screen. No computer, no Wii, no TV, no Netflix, no Nintendo DS. Nothing.
They can watch a show with their parents once in a while. That's it. Until further notice.
They'll be doing chores every day after school, and working on their homework. We'll have other activities, like reading, and learning about stuff, and helping mom and dad with all that needs done. And when their behavior has improved significantly, we'll re-introduce screen activities in a careful and controlled fashion. A little bit at a time, until we found a healthy balance.
I explained this to both kids. It felt like a good parenting moment. They seemed to understand and accept this new paradigm. I felt like I had a good plan, and it was already under way. We talked about this stuff for maybe 20 minutes and they really seemed to get it. They were with the program. Maybe they realized that this would mean more direct quality time with their parents, and they instinctively know that's what they need.
"Good," I said. "Now it's time to get ready for bed. Go brush your teeth."
"Uhgg! Daddy, I don't want to. Do we have to brush our teeth now? I'm not even tired." Elleri whined.
"First, I'm going to get some more to eat." Ethan said, and immediately headed for the kitchen.
Meta Manager
Work is on my mind this morning.
Since this blog is about whatever I'm thinking about, I've decided to allow myself to write about my work. If I had any readers, I'd worry about boring them.
That's not yet a problem, and maybe it won't be as boring as I fear.
So here it goes.
I've been writing a database program that is universally useful. Now specifically, it is only the data-entry portion of the application that is universally applicable. It works quite well and I'm starting to deploy it to various offices (customers).
It does this by serving as a data modelling tool that automatically creates tables and relations, and then has a user interface that allows data entry into any of these tables and relations. All the information about what sorts of things will be tracked, and links between those things, is stored as metadata.
Even though I'm still early in the beta (bug stomping) phase, I've already found out that one of the trickiest things for us (the vendors) is keeping track of the metadata as it's needed in each office.
Each office differs, sometimes slightly, sometimes dramatically, in their data needs and interests. As I go from office to office, distributing updates, bug fixes, and so forth, I'm finding that these differences are beginning to step on each other.
Office Alpha needs to track A, B, and C. Office Beta tracks A, B, and D. If alpha improves the way it tracks B, beta wants to benefit from that development, but if alpha stops tracking A, beta doesn't want to lose that ability.
So I need another application, just to keep track of what each office is doing, and to manage what changes to distribute to each office.
This is so important, that it's what I'm devoting myself to for the rest of the week.
Here's how I'm going to do it:
1. The Metadata Manager (MM) will have it's own version of all the user system (USys) tables (that's where I store the metadata in the apps). These MM USys tables will also have an Office column where I'll tag the row with the office that owns it.
A. I've been debating whether to allow a many-to-many relationship between offices and metadata entries. That way, I could indicate that Office Alpha and Office Beta and Office Gamma use Entity Type A, with Traits Ab, Ac, and Ad-f, but only Office Gamma uses Trait Aa. My problem with this is that each metadata row has multiple attributes. Even though several offices may use the same entity type or trait, they may use it in slightly different way (having different data domains, for example, or allowing multiple values at one office and not at another, or having different default values, etc.). So, no. There will be no sharing. Once a metadata item is assigned to an office, it belongs wholly to that office. This may result in some duplication between offices, but it's easier to keep things straight this way.
B. I'll need a way to add new metadata items as sort-of candidates. These are items that have not been deployed to any office, but should be. These items should be tagged for deployment to any number of offices. Once deployed to an office, the item will appear in the offices metadata set, and the candidate entry will be marked as deplooyed to that office. After that, it is managed at the metadata level.
2. The MM must allow me to compare my record of the metadata for a given office with what exists when I visit the office. I travel from place to place, taking the MM with me. Once I use the MM to check the working copy of the app on the client's network, I should immediately see any differences. Metadata at the office can have been changed, deleted, or added. The data in the MM should be marked as changed and archived somehow. It should then be synchronized with what is on the client's network (the production copy).
3. It's becoming obvious to me that I'm really creating a version control system. I should research how that's done in programs like Git and learn what I can.
What I really need is for this to be a quick-and-dirty tool that is easy to create, easy to understand, and easy to manage. I've no time for a lengthy development process, and no time to be distracted from debugging the main app and finishing the reporting tool that goes with it.
Since this blog is about whatever I'm thinking about, I've decided to allow myself to write about my work. If I had any readers, I'd worry about boring them.
That's not yet a problem, and maybe it won't be as boring as I fear.
So here it goes.
I've been writing a database program that is universally useful. Now specifically, it is only the data-entry portion of the application that is universally applicable. It works quite well and I'm starting to deploy it to various offices (customers).
It does this by serving as a data modelling tool that automatically creates tables and relations, and then has a user interface that allows data entry into any of these tables and relations. All the information about what sorts of things will be tracked, and links between those things, is stored as metadata.
Even though I'm still early in the beta (bug stomping) phase, I've already found out that one of the trickiest things for us (the vendors) is keeping track of the metadata as it's needed in each office.
Each office differs, sometimes slightly, sometimes dramatically, in their data needs and interests. As I go from office to office, distributing updates, bug fixes, and so forth, I'm finding that these differences are beginning to step on each other.
Office Alpha needs to track A, B, and C. Office Beta tracks A, B, and D. If alpha improves the way it tracks B, beta wants to benefit from that development, but if alpha stops tracking A, beta doesn't want to lose that ability.
So I need another application, just to keep track of what each office is doing, and to manage what changes to distribute to each office.
This is so important, that it's what I'm devoting myself to for the rest of the week.
Here's how I'm going to do it:
1. The Metadata Manager (MM) will have it's own version of all the user system (USys) tables (that's where I store the metadata in the apps). These MM USys tables will also have an Office column where I'll tag the row with the office that owns it.
A. I've been debating whether to allow a many-to-many relationship between offices and metadata entries. That way, I could indicate that Office Alpha and Office Beta and Office Gamma use Entity Type A, with Traits Ab, Ac, and Ad-f, but only Office Gamma uses Trait Aa. My problem with this is that each metadata row has multiple attributes. Even though several offices may use the same entity type or trait, they may use it in slightly different way (having different data domains, for example, or allowing multiple values at one office and not at another, or having different default values, etc.). So, no. There will be no sharing. Once a metadata item is assigned to an office, it belongs wholly to that office. This may result in some duplication between offices, but it's easier to keep things straight this way.
B. I'll need a way to add new metadata items as sort-of candidates. These are items that have not been deployed to any office, but should be. These items should be tagged for deployment to any number of offices. Once deployed to an office, the item will appear in the offices metadata set, and the candidate entry will be marked as deplooyed to that office. After that, it is managed at the metadata level.
2. The MM must allow me to compare my record of the metadata for a given office with what exists when I visit the office. I travel from place to place, taking the MM with me. Once I use the MM to check the working copy of the app on the client's network, I should immediately see any differences. Metadata at the office can have been changed, deleted, or added. The data in the MM should be marked as changed and archived somehow. It should then be synchronized with what is on the client's network (the production copy).
3. It's becoming obvious to me that I'm really creating a version control system. I should research how that's done in programs like Git and learn what I can.
What I really need is for this to be a quick-and-dirty tool that is easy to create, easy to understand, and easy to manage. I've no time for a lengthy development process, and no time to be distracted from debugging the main app and finishing the reporting tool that goes with it.
Friday, October 29, 2010
Labels
What identifies you? What labels do you apply to yourself? How do others label you?
Here are some labels I wear, in no particular order:
nice man, fat guy, middle age, geek, programmer, writer, good dad, loving husband, sci-fi buff, atheist, role-player, gamer, avid reader, futurist, game designer, data modeler, interaction designer, skilled lover, generous, kind, middle-class, home owner, safe driver, consultant, music lover, humorous, depressed.
Some people think labels are bad, limiting, boxing, stereotyping.
I think they're just convenient abstactions. Quick ways to sum up some of what we are. A list of applicable labels is just a start, but it's a start. There's no way to understand someone without using them. We simply need to keep in mind that no pile of labels can be complete. They can never tell the whole story.
To know someone, we need their history, philosophy, talents, virtues, and flaws. And then we need to meet them, and those whose lives they impact the most. We need to feel their chemistry and gauge the weight of their lives.
The labels that apply at one age are not the ones that apply later in life. My list above would have been quite different when I was 16, rather than now at 46. We grow, change, evolve. We get better, mostly. We get worse, a little.
If you know me, or have met me, think how would you order the list of labels I supplied above. Reflect on whether it'd be anything like how I would order them? What labels would you add? Which did you not know or would not have ever guessed? I wonder what labels I have for you that aren't true. How have I got the emphasis wrong, even for the ones I'm right about?
Maybe you consider your most defining label something like "aging rebellious daughter", while I'd have to guess "physician". It's only because I don't know you well enough. Perhaps you haven't been truthful or open with me, or perhaps I only see you in a single context.
This is nothing new. We all know this. I wonder about it alot, though.
I wonder if someday, maybe through some barely imagined technology, we'll find a way to share our identities with people more efficently. Imagine if everybody had a blog where they actively described themselves, and then some super-smart indexing algorithm (a sort of psychologist-google) could summarize that on your eyeglass's augmented reality display. I'd meet you in church and instantly know that you're an "athletic beach lover cartoonist" or "cheerfully liberal European history buff" or "animal-rights-activist jazz singer".
I wonder if we'd make friends faster, avoid more misunderstandings, and get along better. Or would this really just be a way for marketers to target us.
I wonder if we'd make friends faster, avoid more misunderstandings, and get along better. Or would this really just be a way for marketers to target us.
I suppose we'll find out in a few more years.
Thursday, October 28, 2010
welcome to my blog
The Title
"just a little smart" refers to my persistent feeling that while I can conceptualize and recognize greatness, I'm not quite smart enough to achieve it. Instead of being truly smart, I'm just a little smart.
Who knows? Maybe this blog will help me come closer.
This place is where I'll publicly struggle with and, hopefully, stretch those shortcomings.
Subscribe to:
Posts (Atom)