Tsu's registration form Last week (and then again today) I went to Tsu, the new social media hotness, to create an account.  I stopped when I got to this form to the right.  Actually I stopped when I got to the “Gender” drop down, and saw that 1) it’s a drop down, and 2) the only choices under it are “Male” and “Female”.  That’s the point that I closed my browser and forgot about Tsu until I saw someone else mentioning the link and I clicked on it again.

I do like setting things up on new social media, although I don’t use them much or at all (ello…?) But sometimes I just get stymied, and this is one of those times.  I’m probably not the only person who has problems with this form, or with entering data about themselves on a form somewhere.  It’s a personal peeve, and I’ve developed some best practices over the years.  It annoys me when people get this wrong — and I try to teach it to people I mentor.  Also, I just want to remind everyone that I’m a CIS white dude, so I probably don’t know all the ways I can screw up. I know a bunch of them, to help the people who make these kinds of forms do a better job, as most of them are also CIS white dudes.

RULE 1: Almost everything about a person is socially constructed.

I want to say “everything”, but I’ve been a programmer too long to be sure.  

Here’s what you can know for certain about a person who comes to your website: they are a person. (Let’s assume you know they aren’t some sort of automated tool.) It’s a good bed they have a birth date. Since it’s a website they came to, the probably have an email.   Emails, at least, are defined by an Internet RFC, so you’ve got a good chance of knowing what that data should be like.  Pretty much every other identifying piece of information on this screen has problems, and they’re only asking for 3 or 4 pieces!

Let’s start with the Name.  They’re asking for a first name and a last name. Even if someone fills that in, you really don’t know their name. Despite the privacy concerns of giving someone your real name, or full name, what’s a name anyway? Names are socially constructed — their order differs from culture to culture. In some cultures the family name goes first, in others it’s last.  I could go on, but what I know about names is: I don’t know all the ways names are constructed.  You really only have one good choice for names, and that’s to give people a simple text box to type in.  They can enter there what they want you to call them and what they want others to see.

The only reason I ever saw to split up names was so you could call people Mr. Tortuga just say “Joe” to be friendly. But if you don’t know which is the surname and which is familial, that is going to break.  If someone has some sort of complicated long name, what do you do? Text box.  Just let people manage it.  Also make it arbitrarily large. I tend to make it a TEXT even though I’ll never need that much space.  Who knows? Also you need to accept any unicode values into it that are available, and just deal with that as well. It won’t work for everyone, but it’s the best I know how to do.

Next up is Gender, and whooo boy.  If you want to ask someone for their gender the first question you’ve got to ask is: why?

It’s a serious question, why do you need to know that? My 1’s and 0’s are the same as anyone else’s, so why do you care?  Again, the only reason I’ve seen for this is to do market segmentation and prove things to your backers about usage. The thing is, if you’re building a global service then what gender means across cultures also changes. Even within the US there’s not really a consensus about gender.  Among the people I regularly hang out with, some are aggressively one gender or another, or no gender or something else entirely. Again, what I know about gender is that I don’t know enough about gender to make a radio button list or a drop down list for it.  Personally, I even have a problem with “won’t say” or “other” (For the latter, the people who aren’t “Male” or “Female” won’t thank you for reinforcing the Other-ness they get from the rest of society; you don’t need to add to it.)

Again, we’re talking about people, and what you don’t know about them.  When in doubt, it’s time for a text box.  Let people type what they want.  You can figure out the data on the back end (my understanding is it’s not that hard).

The thing is, people with normative genders, those of us who are clear on being “Male” or “Female” won’t ever notice that we had to type it in, and it won’t hurt our feelings (and who cares, we’re pretty privileged that way anyway).  The people who are used to being shut out of services because they ask an unanswerable question will appreciate it, and when  you have an internet service, buzz is good. Good buzz is better.

I don’t know who made this form, but it probably wasn’t given a lot of thought. Marketing people said, “we need this information to do market segmentation.” Or someone just thought this was the sort of stuff we need to know [One of the things that attracts me to TDD is that we don’t add things unless they have a purpose at the end — if we’re not using Gender anywhere, we just won’t even include it.]

Just remember RULE 1.  Everything you think you know about categorizing things, people, types of apples, shades of color: it’s all socially constructed.  You have learned what they are and how to discern them because of the culture you are in or were raised in.  But we live in a multicultural world, and there’s much you don’t know about others.  You don’t have to know everything, you just have to know you don’t know.  And make a text box for people to type in.

Gambit, y'allSo, we were watching Korra last night, and discusing the titles of the different episodes and excited we were by them (for me, specifically “Operation Beifong” had me wanting to watch the show badly.  I mentioned to the daughter that the next episode (there are only 3 left, egad!) is “Kuvira’s Gambit”.

The dotter (who is 12) asked “What’s gambit?”

I really had to supress putting on my deep Southern accent and say, “Now, how can ya’ll not know who Gambit is?”

Instead, of course, I pointed out that she already knew what a gambit was from chess club.

So, when I first started formally learning to write code, and do programming, we were taught the only and true method of it, a method now known as Waterfall.  It doesn’t work, and it causes more problems than it helps with.  I understand why it was done that way at one time, but with the way we use computers now, it doesn’t work at all.  With “waterfall” all the testing was done at the end of the project. There was some expected unit testing by the developer, but they were supported by the supposed safety net of QA at the end. They would do the real testing and go through that cycle.

That worked okay; the real problem with waterfall is that it took too long, the business would change in the interim, and the users’ needs and expectations would drift in the nine months it took to make a waterfall project.  Also, it depended on getting the user requirements right, and that’s actually the hardest part of any project.  Most users don’t know what they want until they see something that’s not quite that. Which, again, takes months in waterfall.

I started learning about Agile methods, which have faster cycles and different methodologies when I worked for a bank in Charlotte.  We were trying to do better, but most of us weren’t properly trained in it. We were never going to do some of the things (like pair programming) and so wound up primarily doing fast cycles and user stories, because we were the most comfortable with that.  As the Agile-guru of our team, I was trying to figure out how to implement it and get it working. I was pretty stoked by this idea about testing, and test-driven code, but I couldn’t wrap my head around it.

Some of it I got, certainly. I’d naturally come to a place where I worked backwards from outputs to inputs. This was mostly laziness, since I didn’t want to write the parts of the program that no one was going to use — let’s start with the end product and build things that make that. [One of the things that frustrates me about the C# development I’m doing at my current job is the amount of what feels like boilerplate and structural code that ‘has’ to exist. It feels like trying to do surgery with a mace.]

But there are things I didn’t get.  How do you start? How do you really test each function? How do you test UI elements (still don’t have a good idea about that.) I couldn’t figure out how to start.  Starting on code was easy, I could focus in on one thing and build it and it worked. Most of my private projects were small and I didn’t need to do much more than that. I probably wasn’t going to finish them anyway.

But with my focus on Making Things this year I want to finish things.  I want to share them, and some of the things — like an IF Parser– should be fairly testable. I mean, I can take a script and pipe it into tads and get the game script out.  At least at some level, that should be completely testable.  So I started up a nodejs project for my parser, Mydas, and set to work.

I knew that I would be having a set of command strings, and I wanted to isolate what were  verbs, direct objects, and prepositions, etc. So I had a parser object, that was going to have some private functions to  parse the syntax. I’d found pos.js which had been ported to Node by Darius Kazemi. I pulled the parts, stopped myself and said, “Wait, don’t I need to write some tests first?”

I started digging around with mocha, and seeing how to write the tests, but I couldn’t figure out how to test my code. I mean, I knew what I was going to call it with, and what I expected out, but it wasn’t working. Part of it, of course, was that I was trying to test a private function. It was private because I know after 20+ years that’s where it’ll wind up, it’s not a public API, it should be a private function.  But you can’t test it.

You can, actually, there’s ways listed on Stack Overflow if you look hard enough.  But you shouldn’t.

Because I was doing it all wrong.

Not completely wrong, of course, my instinct was to focus in on the hardest bit of code and see if I could pound that out, get it working.  But that code won’t exist in a vacuum. It’ll be called from somewhere, with a particular goal in mind.  The truth is, I didn’t know if I was right when I was so certain that I was going to need this f unction, that it was going to be private, etc.  Probably, but I didn’t know.

The only way to know was to start with some use cases/user stories.  What does this thing do, and for whom? Then to slowly back up into writing the needed functions as you moved from the outputs to the inputs.  And that private function? When there’s a test for the public function that calls it, then you can refactor it to a private one, because it will still be tested. Starting with private functions risks code that’s never tested, and that’s decidedly not the goal.

And of course this makes sense. Only write code for the uses that the program will be written for. Figure those out first, and then write the code that does that. And then that because another user of code, which calls back and back until you’ve got the whole processing chain written and tested.  And I realized that I had at least two different kinds of users in Mydas — we’ve got the player who I had been focusing on, but you also have the author who is writing code. All of this has to work for both of them, and what does that mean anyway?

But, again, the advantage of this project is that I can specify the whole thing. I can write the Author’s inputs, and the player’s inputs as text files (perhaps) and input them both to the program, and be completely certain of what the output should be.  And that’s where I should start writing my use cases. And there will be more detailed ones as I go and worry about the how, and the what.

For the first time I feel like I might know what I’m doing with this.  Of course defining the what is turning out to be a harder task than I thought at the time, which makes me glad I started on it.

There’s a deep part of me incredibly fond of text adventures. I remember waiting for my  Uncle’s TRS-80 to load (it took so long — I remember it as hours — to read that tape) and then to play for just a bit. To open the mailbox and see the house on the hill. To have the whole thing crash and have to be reloaded.  I spent several days with them that year and made no progress in the game.  Later, I got Diplomacy for my Apple ][c, and played Hitchhiker’s Guide on a friend’s Commodore.  I wasn’t really a gamer back then, games didn’t fascinate me the way they do now, but there was something about text adventures I liked.

In the past few years, I’ve played a few. I’ve watched the AIF community grow and wane and grow again with different types of “adult interactive fiction” games. I’ve played more point and click adventures in their renaissance than I ever played in their heyday. But while I like them, I don’t really play them. On the other hand I yearn to make them.  This seems contradictory to me, but there’s something about the possibility space of IF that fascinates and challenges me as a story teller.

So maybe it’s a bit of hubris that I think I can write a kind of game I barely play and tell an interesting story.  It’s definitely hubris that I think I can write a parser and make a JavaScript parser game designed to be played in a browser. I’ve done a bit of research and have found some partial projects, but nothing really developed. That probably means I’m the main audience for this as well. The truth is, I’d hoped that TADS3.0’s HTML implementation had been more like Twine’s, but it requires a working server to function.

And speaking of Twine, why not use and extend that?  Twine is pretty awesome, and it offers something really pretty amazing for people to create stories with.  I’ve thought about adapting my stories to that medium (and wrote 2 or 3 games for it last year).  But ultimately, I’m a programmer too, and just as I’m drawn to TADS’s object oriented structure over Inform’s more narrative structure, I’m drawn more to writing JavaScript that editing a wiki.

Inform does have a web-based exporter, IIRC, and it will be simple to find an interpreter for Inform that will run on just about anything.  That’s pretty cool of Inform, and is certainly worth anyone’s time.

So it’s hubris to think that this is needed; it’s hubris to just think I can do it and be successful at it.  But then, hubris is for this very reason one of the traits of a great programmer.

The project will be split into two pieces, much like TADS. One will be the parser/disambiguator (which figures out what verb/command you are giving, and which objects you are referring to. It figures out you are taking or putting and that it’s the red ball not the blue pencil that you are taking. I’m calling it Mydas because it touches every other part of the project, and because it’s the species name for the Green Turtle (Chelonia mydas).  The other part of the project is the library of objects which the parser uses and which authors will instantiate or override as part of their game creation.  It will be called Chelonia, for obvious reasons.

I’ve already started and had some missteps, which will be the subject of future posts.

So, long time readers of the blog may know that I try to do a plan for what I’m doing in the coming year, so that I have some idea of whether I’m doing the things I want to be doing.  Last year at this time, I couldn’t even manage to think about what I might want to do in 2014.  In January and February, I considered writing a post, but never got to it. My March or April, I just forgot about it, and tried to keep moving forward.

Some of this was settling into new work experiences — my job keeps me busier than any job ever before, and I’m learning (and, frankly, hating) C#.  But interspersed with that 70-90% of stuff I don’t like doing, i get to do some interesting JavaScript, HTML, and interactive sites and displays.  There are places in the world where I can stand in front of something I made and say I made this.  I wrote a video game for work; we did kiosks for a museum; we’re working on an iPad app as well.  So, that’s all good — but busy and draining.

I published no work last year. Few if any blog posts, no stories, no games, nothing. (Some of my work software shipped, so it’s not nothing, but it’s not what I want to do.)  Some of that was work related, but a lot of it has to do with some personal stuff that’s no one’s business by my own.  I’m mad about some stuff I can’t do anything about, and I’ve not been willing to let it go or change it so that the stuff I’m upset about goes away.  That sort of locked me into a cycle of non-creation that kept me from even making plans I knew I was going to fail at.

So for the first time in a decade, I’m making some New Year’s Resolutions.  Most people make bad ones, but I’m just committing to two operating principles.  The first is to Deal with My Rage.  I’ve got a lot of it (I always have) and I don’t handle it well.  So part one is to figure out how to manage it better.  Being angry takes energy, and all that energy going to stoke my fires is energy that’s not being put towards my other guiding principle:  Make More Stuff.  And by “Make” I mean, finish, publish, let people see. I’m a writer and I write all the time. I’m a programmer and I program all the time too.  But finishing has always been the problem, and it feels like you never make anything if it’s never actually done.

So, I’ve already started working on the anger stuff. There’s a little therapy. There’s some rebuilding some social groups so I have somewhere to talk about things. There’s this project, because projects are good.

I’m spending the month of December figuring out what sorts of things I want to Make next year.  I’ve got a novel/novella that I wrote some time ago in response to 50 Shades of Grey. The movie’s coming out, it might be good to get that in shape for when it does.  I’ve got a really cool and probably unnecessary JavaScript IF parser project that I really want to work on.  (I love writing in JavaScript. TADS and Inform? Not so much).  I’ve got a couple of game ideas to work on, and an interactive toy that I want to make. Then there’s the games website that needs making which points to the games I actually did make in 2013.  There’s a lot to do, probably more than a year’s worth of stuff.  So December is about working on one of these (because I can’t stop myself) and figuring out what takes priority over the next year.

Because I’m saner if I handle my emotions;  I’m saner if I make things and know I’m adding to the world.

This post is over a year overdue, but like the turtle in the story, we just keep plodding forward doing the best we can.