An example of Java being broken-by-design

Java complaint: java.sql.Timestamp is based upon java.util.Date, so you can pass it to functions expecting a java.util.Date. The difference is that java.util.Date specifies time is millisecond-precise and java.sql.Timestamp specifies time is nanosecond-precise. They can both be assigned a value using using a millisecond-accurate function with the same name. However, if you compare a Date and a Timestamp initialized to the same millisecond-accurate time, they are never equal.

This means that while there is fancy object-oriented code-reuse arm-waving, if you actually try to use these classes in a generic manner things fail mysteriously. This is fundamental breakage in the design. First they "enforce type-safety" then if you actually rely upon type-safey you get bit in the ass.

This is documented (from http://docs.oracle.com/javase/7/docs/api/java/sql/Timestamp.html):

Due to the differences between the Timestamp class and the java.util.Date class mentioned above, it is recommended that code not view Timestamp values generically as an instance of java.util.Date. The inheritance relationship between Timestamp and java.util.Date really denotes implementation inheritance, and not type inheritance.

This gets me in a lather. Clearly being a child of java.util.Date means nothing.

What they should have done was have a Date-like interface specifying the getTime()/setTime(long) functions and defined that they accepted time in milliseconds and their epoch. Then we could use any getTime()/setTime() related function the same without caring about the advanced features it possessed.

As it is there are too many different ways to specify dates and they're all incompatible. It's almost easier to pass time around in milliseconds and convert to the desired type as-needed.

Roguelike development deferred

For now all my roguelike projects are officially deferred for the indefinite future.

The Blacken Java library is on code.google.com. It is currently usable, and I may use it on a 7DRL at some point. There are no immediate plans for a full-scale roguelike.

The Python STEW Roguelike library ran in to trouble with the desire to go to Python 3. It also suffered from repeated redesigns. The dependency on full Unicode support -- while required for my goals -- further complicated things. Add to this many of my goals for it are now met with LibTCOD, and it just isn't high-priority.

The joy I get out of talking about writing projects is just as great as the joy I got out of talking about Roguelikes or my other projects when I managed to talk to someone who "got" it. More than this, the chance of an average person "getting" what I am talking about is so much higher that it is suddenly a joy to talk to complete strangers about my passion projects.

This site will remain the location for my random tech notes. The primary audience here has always only been me.

New writing blog

My writing/fiction work officially has a blog of its own.

S. W. Black, a blog named after my (current) fiction writing moniker.

A reStructuredText template for novel design using the Snowflake Method

This has been moved to my writing blog: http://swblack.blogspot.com/2010/08/why-authors-should-future-proof-their.html

[If you just want the goods, the original reStructuredText (.txt) template is available as well as a rich-text version that was uploaded to Google Docs.]

Why authors should future-proof their notes

This post has been moved to my writing blog: http://swblack.blogspot.com/2010/08/why-authors-should-future-proof-their.html

On the writing project

Until the end of NaNoWriMo 2010 this blog will also cover my writing projects. The success (or failure) of NaNoWriMo will determine whether I should think about having a separate literary blog in addition to this rather technical blog.

This "Projects and pastimes" blog has a history of being project notes, and usually fairly technical (when I'm not just ranting about some technology). If I'm going to pursue writing, it would make sense to keep the two separate. (As my spiritual blog will remain separate.)

At one point this blog was part of a personal blog. I've done the splitting before. I just wanted to warn folks.

My response to Twitter

Well, that's better news than I was suspecting. Once I got to the notes about not favoring automated features, I was concerned that the whole idea would be a wash.

On the plus side, if I'm never going to release it, I'm basically feature complete. All I need to do is add some additional error checking. (It should have some error checking now, but it could use a little more.)

If you're curious, the thing is currently a 140 line BASH script using curl to make the Twitter calls. It took me ~2-3 hours to get all the features I wanted and to verify they all worked. (This would be how I got a fully functional proof-of-concept before I thought to ask about whether such a program would be allowed.) I may try out a show using the current script before I do much more to it. It would be cool to integrate location tracking and timed uploads of photos, but both of those can wait until I rewrite the thing in Python -- and I won't be doing that until I can prove the core idea is moderately successful.

You are correct that there will be no automated account creation. I clearly read the section about scraping the site will cause your account to be terminated. Automating web browser actions in such a manner is functionally the same, and sites can be programmatically scraped in a manner that they look like they're having automated browser actions, so each is really just as bad. The plan has always been for each character to get the account created manually. I am glad that I don't have to worry about limits there. It should be easy enough to stay within reason.

re:other limits. The FAQS or API docs or other site information mention specific limit numbers. That's where I found out such things existed and were enforced. It is easier to just plan for reason and check for error, though, so I'm happy with the answers. To pull this off, the timing on everything needs to look like normal human tweets, so there shouldn't be any problems over-stretching the bounds here.

re: Replying to @people. This wouldn't be at all random. This would be very specific feedback *initiated* by the human. This is really to help keep up the illusion that it is all really happening. If someone asks a specific question about the story, the answer can be presented as if it is just one person replying to another via Twitter. I would expect most people to just watch silently and that would be it, but if someone asks a question directed to a character it only makes sense for that character to respond. In general, the focus will be on the other characters. Randomly including names of followers would -- quite rightly -- be seen as spam.

Since this isn't going to be a distributed project, I'll sketch out an idea, then create a website for the particular show before requesting a "source" identifier. This should make it even easier to identify the tweets as coming from an automated source.

I hope that also clarifies my personal stance on some of the issues you raised.

Thanks!

Steven Black